Re: Review of draft-ietf-nsis-qspec-18.txt

Hi,

This has been agreed some time back and needs to be fixed. 

Please go ahead with the change.

Thanks,

  Martin

[email protected]   <== NEW ADDRESS

NEC Laboratories Europe - Network Research Division

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014  

> -----Original Message-----
> From: Gerald Ash [mailto:[email protected]] 
> Sent: Wednesday, February 20, 2008 4:58 PM
> To: Francois Le Faucheur IMAP; Martin Stiemerling; nsis
> Cc: Gerald Ash; [email protected]
> Subject: Re: [NSIS] Review of draft-ietf-nsis-qspec-18.txt
> 
> Francois,
>  
> In your "Proposed Resolution" posting to NSIS on 3 December 
> http://www.ietf.org/mail-archive/web/nsis/current/msg08155.htm
> l you say:
>  
> > The Proposed Resolution
> > ===================
> > Co-authors of the three I-Ds as well as WG chairs of the 
> corresponding 
> > WGs converged on the following proposed resolution.
>  
> I saw no discussion of this proposed resolution on the NSIS 
> list.  Who were the QSPEC co-authors who worked with you on 
> the proposed resolution?
>  
> > o Regarding RPH-Priority:
> > * tsvwg-emergency-rsvp will go ahead with its requests to IANA to 
> > provide numerical registry for RPH priority (via extending existing 
> > RPH registry). See IANA Considerations section of 
> > tsvwg-emergency-rsvp.
> > * nsis-qspec (in section 6.2.10) will point to this 
> registry instead 
> > of defining its own values
>  
> OK.
>  
> > o Regarding Admission Priority:
> > * every protocol spec will only indicate that "higher value means 
> > higher priority".
> > * there is no attempt to define what specific values should be used 
> > for what. this is left outside the scope of the protocol specs.
> * each protocol spec will add a statement clarifying that a
> > given Admission Priority is to be encoded with the same 
> value in each 
> > of the three protocol spec. For example, in tsvwg-emergency-rsvp, 
> > under section 3.1. we will add:
> " A given Admission Priority is encoded in this information
> > element using the same value as when encoded in the 
> Admission Priority 
> > parameter defined in section 6.2.9 of [nsis-qspec], or in the 
> > Admission Priority parameter defined in section 4.10 of 
> > [dime-qos-parameters].
> > In other words, a given value in any of the 
> [emergency-rsvp] Admission 
> > Priority information element, the [nsis-qspec] Admission Priority 
> > parameter or the [dime-qos-parameters] Admission Priority 
> parameter, 
> > refers to the same Admission Priority.
> 
> The above proposed paragraph is really unclear.  Which draft 
> is setting up IANA Registries to assign Admission Priority 
> parameters?  The way it reads it sounds like all three drafts 
> are setting up registries but that somehow (magically) all 
> refer "to the same Admission Priority".  How can that be if 
> they assign different values?  Right now emergency-rsvp and 
> nsis-qspec set up registries for Admission Priority and 
> dime-qos-parameters is using the nsis-qspec registry as I recall.
>  
> Please clarify the proposal as to which draft is setting up a 
> registry for Admission Priority.  Also, please provide 
> clearer proposed text to include in the drafts.  
>  
> It would be good to see some discussion of the proposal on 
> the list, to confirm and validate agreement of the WG.
>  
> Jerry
> 
> 
> Francois Le Faucheur IMAP <[email protected]> wrote:
> 
> 	Hello,
> 	
> 	For memory, the next rev of nsis-qspec is also expected 
> to be aligned 
> 	with the Resolution of the issue related to QoS 
> Parameters encoding 
> 	in , & . For 
> 	convenience, I included below the recap on the corresponding 
> 	resolution as announced on NSIS, DIME and TSVWG lists.
> 	
> 	Just to make sure this does not fall through the cracks.
> 	
> 	Cheers
> 	
> 	Francois
> 	
> 	
> 	>
> 	> Begin forwarded message:
> 	>> From: Francois Le Faucheur IMAP 
> 	>> Date: 3 December 2007 12:05:42 GMT+01:00
> 	>> To: [email protected], [email protected], tsvwg tsvwg 
> 	>> Cc: Francois Le Faucheur IMAP , David Oran R 
> 	>> , Hannes Tschofenig , 
> 	>> ken carlberg , Magnus Westerlund 
> 	>> , James Polk , 
> 	>> [email protected], "(IJ/ETH) Báder Attila" 
> 	>> , [email protected], Jukka 
> 	>> Manner MJ , tsvwg chair 
> 	>> [email protected]>, [email protected], dime- 
> 	>> [email protected], "[email protected]>" 
> 	>> 
> 	>> Subject: Resolution of issue QoS Parameters encoding in 
> 	>> parameters>, & 
> 	>>
> 	>> Hello,
> 	>>
> 	>> The Issue:
> 	>> =======
> 	>> Three different documents (dime-qos-parameters, 
> nsis-qos-nslp, 
> 	>> tsvwg-emergency-rsvp) need to convey an overlapping 
> set of QoS 
> 	>> parameters (specifically RPH-Priority and Admission 
> Priority) and 
> 	>> currently do that in an inconsistent manner. This 
> has been brought 
> 	>> up and partially discussed on the WG mailing lists.
> 	>>
> 	>> The Proposed Resolution
> 	>> ===================
> 	>> Co-authors of the three I-Ds as well as WG chairs of the 
> 	>> corresponding WGs converged on the following 
> proposed resolution. 
> 	>> Please let us know if you have an issue/concern with this.
> 	>>
> 	>> o Regarding RPH-Priority:
> 	>> * tsvwg-emergency-rsvp will go ahead with its 
> requests to IANA to 
> 	>> provide numerical registry for RPH priority (via extending 
> 	>> existing RPH registry). See IANA Considerations 
> section of tsvwg- 
> 	>> emergency-rsvp.
> 	>> * nsis-qspec (in section 6.2.10) will point to this registry 
> 	>> instead of defining its own values
> 	>> * dime-qos-parameters (in section 4.11) will point to this 
> 	>> registry instead of defining its own values
> 	>> * tsvwg-emergency-rsvp (in section 3.2) will keep 
> pointing to 
> 	>> this registry.
> 	>>
> 	>> o Regarding Admission Priority:
> 	>> * every protocol spec will only indicate that 
> "higher value means 
> 	>> higher priority".
> 	>> * there is no attempt to define what specific values 
> should be 
> 	>> used for what. this is left outside the scope of the 
> protocol specs.
> 	>> * each protocol spec will add a statement clarifying 
> that a given 
> 	>> Admission Priority is to be encoded with the same 
> value in each of 
> 	>> the three protocol spec. For example, in 
> tsvwg-emergency-rsvp, 
> 	>> under section 3.1. we will add:
> 	>> " A given Admission Priority is encoded in this information 
> 	>> element
> 	>> using the same value as when encoded in the 
> Admission Priority
> 	>> parameter defined in section 6.2.9 of [nsis-qspec], 
> or in the 
> 	>> Admission
> 	>> Priority parameter defined in section 4.10 of [dime-qos- 
> 	>> parameters].
> 	>> In other words, a given value in any of the [emergency-rsvp] 
> 	>> Admission
> 	>> Priority information element, the [nsis-qspec] 
> Admission Priority 
> 	>> parameter
> 	>> or the [dime-qos-parameters] Admission Priority 
> parameter, refers to
> 	>> the same Admission Priority.
> 	>> "
> 	>> * the mirror statement will be added in nsis-qspec (section 
> 	>> 6.2.9) and dime-qos-parameters (section 4.10)
> 	>>
> 	>> Francois
> 	>>
> 	
> 	
> 	
> 	
> 	
> 
> 
> ________________________________
> 
> Looking for last minute shopping deals? Find them fast with 
> Yahoo! Search. 
> <http://us.rd.yahoo.com/evt=51734/*http://tools.search.yahoo.c
> om/newsearch/category.php?category=shopping> 
>