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

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 <dime-qos-parameters>, <nsis-qspec> & <tsvwg-emeregncy-rsvp>. 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 <[email protected]>
>> Date: 3 December 2007 12:05:42 GMT+01:00
>> To: [email protected], [email protected], tsvwg tsvwg <[email protected]>
>> Cc: Francois Le Faucheur IMAP <[email protected]>, David Oran R  
>> <[email protected]>, Hannes Tschofenig <[email protected]>,  
>> ken carlberg <[email protected]>, Magnus Westerlund  
>> <[email protected]>, James Polk <[email protected]>,  
>> [email protected], "(IJ/ETH) Báder Attila"  
>> <[email protected]>, [email protected], Jukka  
>> Manner MJ <[email protected]>, tsvwg chair <tsvwg- 
>> [email protected]>, [email protected], dime- 
>> [email protected], "[email protected]>"  
>> <[email protected]>
>> Subject: Resolution of issue QoS Parameters encoding in <dime-qos- 
>> parameters>, <nsis-qspec> & <tsvwg-emeregncy-rsvp>
>>
>> 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
>>