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



>>
>> For example in "tsvwg-emergency-rsvp"  under section 3.1., after :
>> "   Adm. Priority (Admission Priority): 8 bits (unsigned)
>>         The admission control priority of the flow, in terms of  
>> access
>>         to network bandwidth in order to provide higher  
>> probability of
>>         call completion to selected flows. Higher values represent
>>         higher Priority.
>> "
>> we could add something like this:
>> "      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.
>> "
>>
>> Francois
>>
>>
>>> That way, when these protocols are used in combination, you
>> can't get
>>> into priority inversion problems and can resist the
>> temptation to try
>>> to map using a local function.
>>>
>>> DaveO.
>>>
>>>> As a practical example of an issue I see in B, consider the recent
>>>> comment from An Nguyen as part of the WGLC on dime-qos-parameters.
>>>> He explained that ITU-T changed the "recommendation" where they
>>>> define Admission Priority semantic and therefore dime-qos-
>> parameters
>>>> needs to point to that new ITU-T document instead. So what happens
>>>> when ITU change their spec again in 2 years if we go for B.  What
>>>> happens if some other SDO decides to make use of admission
>> priorities
>>>> and define different value sets?
>>>> Approach A completely isolates IETF from any of these
>> external events
>>>> (that should indeed be completely transparent to IETF).
>>>>
>>>> If we can close that one by email, no need to meet face to face in
>>>> Vancouver.
>>>>
>>>> Francois
>>>>
>>>>
>>>>
>>>> From: "Nguyen, An P" <An.P.Nguyen@dhs.gov>
>>>> Date: 16 October 2007 15:20:35 GMT+02:00
>>>> To: "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>,
>> <dime@ietf.org>,
>>>> "radext mailing list" <radiusext@ops.ietf.org>, <nsis@ietf.org>,
>>>> "tsvwg IETF list" <tsvwg@ietf.org>
>>>> Subject: [NSIS] RE: [Tsvwg] WGLC for draft-ietf-dime-qos-
>>>> parameters-01
>>>>
>>>> Hannes,
>>>>
>>>> Just a comment on a reference in Sect 4.10 - Admission Priority
>>>> Parameter:
>>>>
>>>> Change the Y.1571 to Y.2171. The ITU SG-13 changed Y.1571 to Y.
>>>> 2171 ( Admission Control Priority Levels in Next Generation
>> Networks,
>>>> Sept 2006) to reflect the NGN work.
>>>>
>>>> I think you should add Y.2171 to Sect 9.2 - Informative
>> References as
>>>> well.
>>>>
>>>> Regards,
>>>>
>>>> An
>>>>
>>>>
>>>>
>>>>
>>>> On 26 Nov 2007, at 20:49, Francois Le Faucheur IMAP wrote:
>>>>
>>>>>
>>>>> On 26 Nov 2007, at 20:23, <john.loughney@nokia.com> wrote:
>>>>>
>>>>>> So, all three documents are about at the same state.  I think it
>>>>>> makess sense if the tsvwg draft creates the registry, and all of
>>>>>> the other drafts reference it.
>>>>>
>>>>> very well.
>>>>>
>>>>> Since we seem to have agreement across TSWG/NSIS/DIME about the
>>>>> first point (ie use a shared registry for RPH priorities)
>> then let's
>>>>> move to the second point ie. the actual format of that
>>>>> registry:
>>>>> draft-ietf-tsvwg-emergency-rsvp-04.txt proposes to
>> instantiate that
>>>>> registry by extending the existing IANA registry that was created
>>>>> based on RFC4412. See "IANA Considerations" section of
>>>>> draft-ietf-tsvwg-emergency-rsvp-04.txt.
>>>>> Please let us know if you see issues with this proposal.
>>>>>
>>>>> Thanks
>>>>>
>>>>> Francois
>>>>>
>>>>>>
>>>>>> John
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: ext Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
>>>>>>> Sent: 26 November, 2007 11:22
>>>>>>> To: Loughney John (Nokia-NRC/PaloAlto)
>>>>>>> Cc: carlberg@g11.org.uk; magnus.westerlund@ericsson.com;
>>>>>>> flefauch@cisco.com; jmpolk@cisco.com; cornelia.kappler@nsn.com;
>>>>>>> oran@cisco.com; attila.bader@ericsson.com;
>>>>>>> jouni.korhonen@teliasonera.com; jmanner@cs.Helsinki.FI;
>>>>>>> tsvwg-chairs@tools.ietf.org; nsis-chairs@tools.ietf.org;
>>>>>>> dime-chairs@tools.ietf.org
>>>>>>> Subject: Re: QoS Parameters in dime-qos-parameters,
>> nsis-qos-nlsp,
>>>>>>> tsvwg-emeregncy-rsvp
>>>>>>>
>>>>>>> Hi John,
>>>>>>>
>>>>>>>> First off, what is the status of the drafts?  I am
>> going to do a
>>>>>>>> WG Chair write-up on the NSIS QSPEC document.  DiME QoS
>>>>>>> parameters might
>>>>>>>> take a bit longer.
>>>>>>>
>>>>>>> The DIME QoS parameter document has finished WGLC already. The
>>>>>>> only technical issue that has been raised for this document is
>>>>>>> related to the registry.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Ciao
>>>>>>> Hannes
>>>>>>>
>>>>>>>
>>>>>
>>>>
>>


_______________________________________________
nsis mailing list
nsis@ietf.org
https://www1.ietf.org/mailman/listinfo/nsis