Subject: Re: [Tsvwg] [NSIS] WG last call on draft-ietf-tsvwg-emergency-rsvp-05

From: Gerald Ash <[email-masked]>
Date: Wed, 5 Mar 2008 12:04:22 -0800 (PST)

All,
   
  Here are some last call comments on draft-ietf-tsvwg-emergency-rsvp-05.
   
  General comments:
   
  1. The emergency-rsvp approach does not prescribe end-to-end cross-domain consistent treatment of admission priority.  As stated in Section 2 (Overview of RSVP extensions and Operations):    
    "As an example of operation across multiple administrative domains, a 
   first domain might decide to provide network layer admission priority 
   to calls of a given Application Level Resource Priority and map it 
   into a high RSVP admission control priority inside the Admission 
   Priority Policy Element; while a second domain may decide to not 
   provide admission priority to calls of this same Application Level 
   Resource Priority and hence map it into a low RSVP admission control 
   priority."
   
  So in this approach an emergency telecommunications service (ETS, e.g., GETS) might *not* get uniformly high admission priority treatment across administrative domains (ADs), depending on how the policy decision points (PDPs) in each AD decide to populate the RSVP Admission Priority element.  
   
    This is in sharp contrast to the approach used in practice today for ETS/GETS, where high admission priority is applied end-to-end across domains.  One reference as to how this approach operates in practice today for ETS/GETS can be found in http://www.amazon.com/Traffic-Engineering-Optimization-Integrated-Networks/dp/0123706254/ (Chapter 9 also presents extensive modeling & simulation analysis/case studies to show how today's end-to-end approach can operate across domains in the Internet).
   
  It would be good to motivate the rationale for the emergency-rsvp approach and why it makes sense to *not* ensure high end-to-end admission priority across domains for ETS/GETS services.
   
  2. Presumably the emergency-rsvp admission priority approach is implemented (or planned to be implemented) in real network applications.  It would be nice to reference such implementations, existing or planned, if possible.
   
  3. The admission priority approach taken in nsis-qspec (http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-19.txt) is consistent with today's practice of providing high admission priority for ETS/GETS end-to-end across administrative domains.  It does this by standardizing the admission priority values for the qspec object in an IANA registry, as specified in Section 7 (IANA considerations):    
    "Admission Priority Parameter (8 bits):
   The following values are allocated by this specification:
   0-2: assigned as specified in Section 6.2.9:
   Admission Priority 0: best-effort priority flow
                      1: normal priority flow
                      2: high priority flow
   The allocation policies for further values are as follows:
   3-63: Standards Action
   64-255: Reserved"

      It has been agreed on the nsis list to rename <Admission Priority> to <Y.2171 Admission Priority> in the qspec draft.  To be consistent with this change, the emergency-rsvp approach should also be renamed (e.g., to <RSVP Admission Priority>) to distinguish it from <Y.2171 Admission Priority>, and so that neither approach should be considered a 'generic' approach.

  Specific comments:
   
  4. Section 3.1 (Admission Priority Policy Element) of emergency-rsvp states:
   
    "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. 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-
   PARAM]. In other words, a given value inside the Admission Priority 
   information element defined in the present document, inside the 
   [NSIS-QSPEC] Admission Priority parameter or inside the [DIME-PARAM] 
   Admission Priority parameter, refers to the same Admission Priority."
   
  The text is very unclear as to what it means that admission priority values are encoded 'using the same value' in the 3 different drafts?  Perhaps an example would help, but in any case it should be clarified.  Further, the text should be updated to note that the <rsvp admission priority> field is not directly comparable to the <Y.2171 Admission Priority> field in the qspec draft so as to avoid confusion.
   
  5. Sections A.1 and A.2 illustrate how the DSTE Maximum Allocation Model (MAM) and the DSTE Russian Dolls Model (RDM) can be used for support of rsvp admission priority.  http://www.amazon.com/Traffic-Engineering-Optimization-Integrated-Networks/dp/0123706254/ presents extensive modeling & simulation analysis/case studies to show how the DSTE maximum allocation with reservation (MAR) model (http://www.ietf.org/rfc/rfc4126.txt?number=4126) performs for ETS/GETS services and how MAR performance compares very favorably to MAM performance.  It would be appropriate to reference MAR as the third DSTE bandwidth constraints model available for consideration and perhaps also to reference the MAR/MAM performance analysis pertinent to emergency services.
   
  Jerry

Magnus Westerlund <[email-masked]> wrote:   This announces the second WG last call on "Resource ReSerVation Protovol 
(RSVP) Extensions for Emergency Services" with the intended status of 
proposed standard:

http://tools.ietf.org/id/draft-ietf-tsvwg-emergency-rsvp-05.txt

This is the second one due to changes and the interaction with documents 
in the NSIS and DIME WG. Please provide any comments on the TSVWG 
mailing list no later than 28th of March. (Yes, it is long but that is 
due to the meeting and that we have several other WG last calls ongoing).

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB | Phone +46 8 4048287
Torshamsgatan 23 | Fax +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

_______________________________________________
nsis mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nsis

---------------------------------
Never miss a thing.   Make Yahoo your homepage.

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Thu, 6 Mar 2008 10:36:43 +0100

Hello Jerry,

Thanks for the comments. Some answers below:

> Here are some last call comments on draft-ietf-tsvwg-emergency- 
<clip>

> It would be good to motivate the rationale for the emergency-rsvp  
> approach and why it makes sense to *not* ensure high end-to-end  
> admission priority across domains for ETS/GETS services.

Let me try clarify one more time.

The approach is the following:
	* the overall requirement for Emergency services is to achieve  
"elevated probability of session establishment"
	* there are multiple mechanisms (Admission Priority, Preemption,  
"Call Queueing") that can be combined in different ways in a given  
network that will ENSURE "elevated probability of session  
establishment" _through that given network_
	* in addition, there is a mechanism allowing each operator to  
identify an emergency session transiting their network and invoke the  
corresponding set of mechanism in that network. As a result, the  
solution allows "elevated probability of session establishment" _end- 
to-end_, which is the real objective.

So, in a nutshell the approach focuses on allowing end-to-end  
"elevated probability of session establishment" but it is felt that  
while this may involve admission priority, this does not necessarily  
dictate end-to-end admission priority.

This was discussed at length in the TSVWG. Some operators pointed out  
that in their region/country Emergency services would use mechanism A  
while others would use mechanism B, while other would use a  
combination of mechanisms. Some pointed out that local regulations  
prevented use of a particular mechanism in a geography while not in  
another. As agreed by the WG, this discussion was captured in  
Appendix B illustrating various combinations that an operator may use  
to achieve "elevated probability of session establishment" .

More generally, I think it was felt that IETF was not chartered to  
mandate a specific combination of mechanisms that MUST be deployed in  
each and every network. Rather, the IETF needs to make available the  
mechanisms that can be combined to achieve the end to end objective.
[an analogy that comes to mind is the Voice QoS space. The IETF has  
defined many QoS mechanisms : Diff-Serv, MPLS Traffic Engineering,  
MPLS FRR, MPLS Diffserv-aware TE, .... However, the IETF does not  
mandate that a very specific combination of those be used in each and  
every network carrying voice.]

My perception is that the above approach is sufficiently described in  
the current draft (section 2, appendix B,..). But if you have  
specific suggestions on how to present it more clearly, we can  
certainly accommodate that.

>
> 3. The admission priority approach taken in nsis-qspec (http:// 
> www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-19.txt) is  
> consistent with today's practice of providing high admission  
> priority for ETS/GETS end-to-end across administrative domains.  It  
> does this by standardizing the admission priority values for the  
> qspec object in an IANA registry, as specified in Section 7 (IANA  
> considerations):
>
> It has been agreed on the nsis list to rename <Admission Priority>  
> to <Y.2171 Admission Priority> in the qspec draft.  To be  
> consistent with this change, the emergency-rsvp approach should  
> also be renamed (e.g., to <RSVP Admission Priority>) to distinguish  
> it from <Y.2171 Admission Priority>, and so that neither approach  
> should be considered a 'generic' approach.

I am not sure why the RSVP Admission is no longer generic (it can be  
used to convey the Y.2171 values if an operator so desires, it can be  
used to carry other values too).

>
> 5. Sections A.1 and A.2 illustrate how the DSTE Maximum Allocation  
> Model (MAM) and the DSTE Russian Dolls Model (RDM) can be used for  
> support of rsvp admission priority.  http://www.amazon.com/Traffic- 
> Engineering-Optimization-Integrated-Networks/dp/0123706254/  
> presents extensive modeling & simulation analysis/case studies to  
> show how the DSTE maximum allocation with reservation (MAR) model  
> (http://www.ietf.org/rfc/rfc4126.txt?number=4126) performs for ETS/ 
> GETS services and how MAR performance compares very favorably to  
> MAM performance.  It would be appropriate to reference MAR as the  
> third DSTE bandwidth constraints model available for consideration  
> and perhaps also to reference the MAR/MAM performance analysis  
> pertinent to emergency services.

Yes. We will add a reference to MAR.

Francois

>
> Jerry
>
>
> Magnus Westerlund <[email-masked]> wrote:
> This announces the second WG last call on "Resource ReSerVation  
> Protovol

---

From: Gerald Ash <[email-masked]>
Date: Thu, 6 Mar 2008 08:57:29 -0800 (PST)

Francois,
   
  A couple more comments.
   
  >> It would be good to motivate the rationale for the emergency-rsvp approach 
>> and why it makes sense to *not* ensure high end-to-end admission priority 
>> across domains for ETS/GETS services.
 
> * the overall requirement for Emergency services is to achieve "elevated 
> probability of session establishment"
> 
> * there are multiple mechanisms (Admission Priority, Preemption, "Call 
> Queueing") that can be combined in different ways in a given network that 
> will ENSURE "elevated probability of session establishment" _through that 
> given network_
> * in addition, there is a mechanism allowing each operator to identify an 
> emergency session transiting their network and invoke the corresponding set 
> of mechanism in that network. As a result, the solution allows "elevated 
> probability of session establishment" _end-to-end_, which is the real 
> objective.
> 
> So, in a nutshell the approach focuses on allowing end-to-end "elevated 
> probability of session establishment" but it is felt that while this may 
> involve admission priority, this does not necessarily dictate end-to-end 
> admission priority.
> 
> This was discussed at length in the TSVWG. Some operators pointed out that 
> in their region/country Emergency services would use mechanism A while 
> others would use mechanism B, while other would use a combination of 
> mechanisms. Some pointed out that local regulations prevented use of a 
> particular mechanism in a geography while not in another. As agreed by the 
> WG, this discussion was captured in Appendix B illustrating various 
> combinations that an operator may use to achieve "elevated probability of 
> session establishment" .
> 
> More generally, I think it was felt that IETF was not chartered to mandate a 
> specific combination of mechanisms that MUST be deployed in each and every 
> network. Rather, the IETF needs to make available the mechanisms that can be 
> combined to achieve the end to end objective.
> [an analogy that comes to mind is the Voice QoS space. The IETF has defined 
> many QoS mechanisms : Diff-Serv, MPLS Traffic Engineering, MPLS FRR, MPLS 
> Diffserv-aware TE, .... However, the IETF does not mandate that a very 
> specific combination of those be used in each and every network carrying 
> voice.]
> 
> My perception is that the above approach is sufficiently described in the 
> current draft (section 2, appendix B,..). But if you have specific 
> suggestions on how to present it more clearly, we can certainly accommodate 
> that.
   
  Thanks for the explanation, it helps to clarify the intent.  However, IMO this intent does not come through in the text (abstract, Section 1, Section 2).  The draft focuses on admission priority, e.g., the abstract says:
   
  "This document specifies RSVP extensions that can be used to support 
   such an admission priority capability at the network layer...
     Other solution components, or other 
   solutions, are outside the scope of this document."
   
  And the example you give in Section 2 leaves one wondering how ETS achieves the elevated probability of session establishment when one domain gives low admission priority:

  Presumably the second domain uses some other mechanism (e.g., call queueing) to achieve elevated probability of call establishment.  IMO this should be mentioned in the example.
   
  More generally, perhaps you can add some of your clarifying words somewhere in Section 1 and/or in the above example and/or perhaps add a sentence to the abstract.  E.g., extracting from your explanation you could add something like the following:
   
  "The overall requirement for ETS is to achieve an elevated probability of session establishment (EPSE) by applying multiple mechanisms (e.g., admission priority, preemption, "call queueing") that can be combined in different ways in a given network to achieve EPSE.  As such, each operator can identify an emergency session transiting their network and invoke the corresponding mechanism(s) in that network to achieve EPSE.  For example, some operators may use mechanism A while others would use mechanism B, while others would use a combination of mechanisms.  Appendix B illustrates various combinations that an operator may use to achieve EPSE."
   
  >> 3. The admission priority approach taken in nsis-qspec 
>> (http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-19.txt) is 
>> consistent with today's practice of providing high admission priority for 
>> ETS/GETS end-to-end across administrative domains.  It does this by 
>> standardizing the admission priority values for the qspec object in an IANA 
>> registry, as specified in Section 7 (IANA considerations):
>> 
>> It has been agreed on the nsis list to rename <Admission Priority> to 
>> <Y.2171 Admission Priority> in the qspec draft.  To be consistent with this 
>> change, the emergency-rsvp approach should also be renamed (e.g., to <RSVP 
>> Admission Priority>) to distinguish it from <Y.2171 Admission Priority>, and 
>> so that neither approach should be considered a 'generic' approach.

  > I am not sure why the RSVP Admission is no longer generic (it can be used to 
> convey the Y.2171 values if an operator so desires, it can be used to carry 
> other values too).
   
  Let me make sure I have this straight.  In the NSIS discussion you insist that we change the name to <Y.2171 Admission Priority> in order to resolve the debate, while the NSIS admission priority approach is in fact as implemented today for ETS and has little to do with Y.2171 other than to populate the initial admission priority values in the registry.  OTOH, the rsvp admission priority approach uses a specific rsvp object, is populated from an rsvp-specific p-type, and AFAIK is not implemented anywhere as yet.  Yet this rsvp-specific admission priority approach is now declared the 'generic' admission priority mechanism?
   
  Hopefully you'll also respond to my comments 2 & 4:

   

  Jerry

---

From: ken carlberg <[email-masked]>
Date: Fri, 7 Mar 2008 12:54:46 -0500

> Let me make sure I have this straight.  In the NSIS discussion you  
> insist that we change the name to <Y.2171 Admission Priority> in  
> order to resolve the debate, while the NSIS admission priority  
> approach is in fact as implemented today for ETS and has little to  
> do with Y.2171 other than to populate the initial admission priority  
> values in the registry.  OTOH, the rsvp admission priority approach  
> uses a specific rsvp object, is populated from an rsvp-specific p- 
> type, and AFAIK is not implemented anywhere as yet.  Yet this rsvp- 
> specific admission priority approach is now declared the 'generic'  
> admission priority mechanism?

yes

> Hopefully you'll also respond to my comments 2 & 4:

I'm not speaking for Francois, but I would ask that if you are  
pointingly asking for responses, then please display the same courtesy  
and respond to at the questions sent to you previously on this  
thread.  if you choose not to, fine, but let's not make this  one way  
street.

> 2. Presumably the emergency-rsvp admission priority approach is  
> implemented (or planned to be implemented) in real network  
> applications.  It would be nice to reference such implementations,  
> existing or planned, if possible.

implementations and deployments in the context you speak of are a rat  
hole.  I'm under several non-disclosure agreements on this general  
topic, and I can imagine that Francois is under similar constraints  
with respect to his customers.  You should be aware of this kind of  
bind.  But, if you are not under the same constraints, I'd be happy to  
openly hear of specific vendor/operator deployments you are aware of.   
Otherwise, let's drop this specific sub-thread.

> The text is very unclear as to what it means that admission priority  
> values are encoded 'using the same value' in the 3 different  
> drafts?  Perhaps an example would help, but in any case it should be  
> clarified.  Further, the text should be updated to note that the  
> <rsvp admission priority> field is not directly comparable to the <Y. 
> 2171 Admission Priority> field in the qspec draft so as to avoid  
> confusion.

The above cited text clearly needs to be re-written depending on the  
outcome of this thread, so attempts at altering the it before any NEW  
consensus is agreed on premature at this point.

-ken

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 18 Mar 2008 13:26:21 +0100

Hi,

There has now been a declaration of consensus in the NSIS WG regarding 
where to go with the admission priority field:

3) Keep Y.2171 admission priority and add admission priority as in 
tsvwg-rsvp-emergency to draft-ietf-nsis-qspec-19.txt.

See thread starting at:
http://www.ietf.org/mail-archive/web/nsis/current/msg08289.html

To my understanding this means there is no need to make a major change 
to this document. However, some clarification may be warranted regarding 
the scope of the parameter that align with the NSIS QSpec updates.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 26 Mar 2008 17:32:06 +0100

Magnus Westerlund skrev:
> This announces the second WG last call on "Resource ReSerVation Protovol 

This is a reminder about the WG last call. Without some comments we 
can't judge consensus on publishing this document. So please provide any 
comments, even if just to say that it is ready to be published.

Cheers

Magnus Westerlund

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Thu, 27 Mar 2008 15:28:15 +0100

Hi Magnus,

There are a couple small items that needs to be fixed:
	- adding a reference to MAR in response to Jerry's Last Call  
comments (as agreed in http://www.ietf.org/mail-archive/web/tsvwg/ 
current/msg08209.html)
	- updating reference text to NSIS Admission Priority in line with  
NSIS WG consensus (as per your message in http://www.ietf.org/mail- 
archive/web/tsvwg/current/msg08231.html)

Other than that, from my perspective, the document is ready for  
publication.

We'll wait a few more days in case there are more belated comments  
from WG Last Call and issue an new version addressing the above two  
minor items.

Thanks

Francois

On 26 Mar 2008, at 17:32, Magnus Westerlund wrote:

> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: ken carlberg <[email-masked]>
Date: Thu, 27 Mar 2008 10:58:31 -0400

Magnus,

> Other than that, from my perspective, the document is ready for  

I concur.  The current version and the subsequent from Francois wrap  
up the loose end from last November of making sure our draft, the  
QSPEC in NSIS, and the QoS Parameters draft from DIME are in synch  
with several common fields.  So any last comments of this last Last  
Call should be aimed at this agreement -- and hopefully, there are  
none :-)

As a side note, I hope there isn't a need to revisit the issue of  
interest in the document.  If needed, I can dig up the comments from  
the past year along with meetings minutes.

cheers,

-ken

---

From: Janet P Gunn <[email-masked]>
Date: Thu, 27 Mar 2008 21:07:28 -0400

Just saying that, from my perspective, "it is ready to be published". And, 
yes I have read it and followed the discussions on the related DIME and 
NSIS documents.

Janet Gunn

Computer Sciences Corporation 
Registered Office: 2100 East Grand Avenue, El Segundo California 90245, 
USA
Registered in USA No: C-489-59

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
This is a PRIVATE message. If you are not the intended recipient, please 
delete without copying and kindly advise us by e-mail of the mistake in 
delivery. 
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to 
any order or other contract unless pursuant to explicit written agreement 
or government initiative expressly permitting the use of e-mail for such 
purpose.
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Protovol

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 31 Mar 2008 15:47:56 +0200

Francois Le Faucheur IMAP skrev:
> comments (as agreed in 
> http://www.ietf.org/mail-archive/web/tsvwg/current/msg08209.html)
> NSIS WG consensus (as per your message in 
> http://www.ietf.org/mail-archive/web/tsvwg/current/msg08231.html)
> 
> We'll wait a few more days in case there are more belated comments from 
> WG Last Call and issue an new version addressing the above two minor items.
> 

The WG last call has now ended. There are a few issues that needs to be 
updated. As there has been some contention around this document I will 
do a short 1-week confirmation call on the updates as soon the new 
version is available.

Cheers

Magnus Westerlund

---

From: "Roy, Radhika R Dr CTR USA USAMC" <[email-masked]>
Date: Mon, 31 Mar 2008 10:37:38 -0400

Hi, Magnus:

There is an important typo in reference to NSIS-QSPEC priority. NSIS-QSPEC is version 19 and resource-priority is in Section 5.2.9 (not Section 6.2.9).

More importantly, this draft needs to reference ONLY to this of part of the resource-priority that is successfully resolved by the NSIS WG in relation to the consensus of the QSPEC draft (e.g. not to specifically mention Y.xxxx resource-priority ONLY, etc. because it will create confusions and distractions about the main technical aspects).

Ken and other members need to look into this as they have taken the lead in resolving the issues related to the QSSPEC draft.

Otherwise, the draft seems to be well-written, and I also agree with Janet other than the above.

Sorry that I missed the last Friday's deadline.

Best regards,
Radhika

PS: For SIP and SIPPING WG members:

RFC 3312 and RFCs related to SIP call flows need to use the latest RFCs of NSIS and TSVWG for taking care of QOS.

----- Original Message -----
From: Janet P Gunn 
Date: Thursday, March 27, 2008 21:09
Subject: Re: [NSIS] WG last call on draft-ietf-tsvwg-emergency-rsvp-05
To: Magnus Westerlund 
Cc: [email-masked], [email-masked], NSIS , tsvwg 

> -------------------------------------------------------------------
> -------------------------------------------------------------------
> -------------------------------------------------------------------
> -------
> -------------------------------------------------------------------
> -------------------------------------------------------------------
> -------------------------------------------------------------------
> -------
> 
> 
> > > due to the meeting and that we have several other WG last 
> calls 
> ongoing).
> > > 
> >

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Tue, 1 Apr 2008 13:45:20 +0200

Hi Magnus,

On 31 Mar 2008, at 15:47, Magnus Westerlund wrote:

>>     - updating reference text to NSIS Admission Priority in line  
>> with NSIS WG consensus (as per your message in http://www.ietf.org/ 
>> mail-archive/web/tsvwg/current/msg08231.html)
>> from WG Last Call and issue an new version addressing the above  
>> two minor items.
>
> The WG last call has now ended. There are a few issues that needs  
> to be updated. As there has been some contention around this  
> document I will do a short 1-week confirmation call on the updates  
> as soon the new version is available.

The new version (draft-ietf-tsvwg-emergency-rsvp-06) is now available.
It addresses the items listed above as well as the comments brought  
up Yesterday by Roy.

Francois

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Tue, 1 Apr 2008 13:48:17 +0200

Hi Roy,

On 31 Mar 2008, at 16:37, Roy, Radhika R Dr CTR USA USAMC wrote:

> Hi, Magnus:
>
> There is an important typo in reference to NSIS-QSPEC priority.  
> NSIS-QSPEC is version 19 and resource-priority is in Section 5.2.9  
> (not Section 6.2.9).

Because I feared a change of section numbering in the next version of  
nsis-qspec I removed the section number (just referred to the section  
title). So this is solve in -06.

>
> More importantly, this draft needs to reference ONLY to this of  
> part of the resource-priority that is successfully resolved by the  
> NSIS WG in relation to the consensus of the QSPEC draft (e.g. not  
> to specifically mention Y.xxxx resource-priority ONLY, etc. because  
> it will create confusions and distractions about the main technical  
> aspects).

Right. -06 only refers to the nsis-qspec "Admission Priority" and not  
to the nsis-qspec "Y.xxx Admission Priority".

Thanks for your review.

Francois

>
> Ken and other members need to look into this as they have taken the  
> lead in resolving the issues related to the QSSPEC draft.
>
> RFC 3312 and RFCs related to SIP call flows need to use the latest  
> RFCs of NSIS and TSVWG for taking care of QOS.
>
>