Re: Call for consensu on admission priority changes in QSPEC

Option 3 negates the main spirit of the IETF QSPEC draft. It implies, as if, ITU-T Yxxxx QOS mechanisms have been the primarily objectives of the draft (indirectly). Is it NOT true?

In this case, the OLD spirit of going backward becomes the primary QOS mechanisms indirectly - that is, non-IETF-specific NGN-centric QOS schemes are getting the primary recognition (indiectly).

Has this been the primary objective of NSIS WG while QSPEC draft was accepted as the working draft? 

Can the authors of this draft do the better job by modifying the write-up focusing the IETF QOS model has been the primary objectives as the NSIS WG has been working on without making the ITU-T QOS models as the primary objectives directly as well as indirectly?

Who is gaining most from this approach # 3 if the draft is not modified?

Best regards,
Radhika

BR/Radhika

----- Original Message -----
From: [email protected]
Date: Thursday, March 13, 2008 14:53
Subject: Re: [NSIS] Call for consensu on admission priority changes in QSPEC
To: [email protected], [email protected]

> WG chair hat off, I support 3.
> 
> John 
> 
> >-----Original Message-----
> >From: [email protected] [mailto:[email protected]] On 
> >Behalf Of ext Martin Stiemerling
> >Sent: 13 March, 2008 17:42
> >To: nsis
> >Subject: [NSIS] Call for consensu on admission priority 
> >changes in QSPEC
> >
> >Hi all,
> >
> >There have been discussions with respect to QoS NSLP QSPEC 
> >Template (draft-ietf-nsis-qspec-19.txt) on the nsis mailing 
> >list, offline between involved parties, and also during the 
> >NSIS session here at the IETF#71 in the NSIS session (see minutes).
> >
> >The QSPEC document shares the IANA registries for RPH priority 
> >and the admission priority with these drafts out of the DIME and 
> TSVWG:>- draft-ietf-dime-qos- parameters
> >- draft-ietf-tsvwg-emergency-rsvp
> >
> >While the IANA registry for the RPH priority has not been 
> >disputed, the admission priority has been. 
> >
> >Therefore we run a call for consensus on these three choices 
> >for the admission priority in the QSPEC. Note well, that the 
> >decision of this can have an impact to the still running IETF 
> >last call for draft-ietf-tsvwg-emergency-rsvp.
> >
> >
> >
> >Please hum on the NSIS list for one of the three options 
> >listed below until Monday, March 17th, 12pm UCT. This is to 
> >confirm the humming of the NSIS WG during the NSIS session at 
> >the IETF meeting.
> >
> >1) Keep Y.2171 admission prioty in draft-ietf-nsis-qspec-19.txt 
> as is:
> >
> >2) Change in draft-ietf-nsis-qspec-19.txt to admission 
> >priority as in draft-ietf-tsvwg-emergency-rsvp-05.txt and 
> >remove Y.2171 admission prioty;
> >
> >3) Keep Y.2171 admission priority and add admission priority 
> >as in tsvwg-rsvp-emergency to draft-ietf-nsis-qspec-19.txt. 
> >
> >
> >
> >
> >For choice 3) these changes are currenlty proposed:
> >
> >1) the emergency-RSVP draft should pretty much stay the same. 
> >There is no "L" bit addition, and its "Admission Priority" 
> >field has local significance within a domain, and no 
> >pre-existing values are defined for it, nor is there any 
> >associated IANA registry assigned to it.
> >
> >2) The QSPEC draft will have a similar "Admission Priority" 
> >field with the same characteristics as that defined above in (1).
> >
> >3) The QSPEC draft will add a new field, titled "Y.2171 
> >Admission Priority", that will be associated with the current 
> >3 values defined in the Y.2171. This field is considered 
> >globally significant on an end- to-end basis. Note that the 
> >emergency-RSVP document will NOT have this additional field.
> >
> >4) Given the presence of two admin priority fields for the 
> >QSPEC, additional rules are added to clarify their application 
> >and usage for NSIS domains.
> >
> >4.1) if the source domain does NOT support Y.2171, then it 
> >sets a locally significant value in the "Admission Priority" 
> >field, and places all "1"s in the "Y.2171 Admission Priority" 
> >to indicate that this field is to be ignored. Downstream 
> >domains MUST NOT alter the value of the "Y.2171 Admission 
> >Priority" field.
> >
> >4.2) if the source domain DOES support Y.2171, then a value 
> >(eg, 0, 1, or 2) is placed in the "Y.2171 Admission Priority" 
> >field AND the "Admission Priority" field. Downstream NSIS 
> >domains MUST NOT change the value in the "Y.2171 Admission 
> >Priority" field so that end-to-end consistency is maintained. 
> >Downstream routers act upon the value placed in the "Admission 
> >Priority" field.
> >
> >4.2.1) Furthermore, if a downstream NSIS domain does not support 
> Y. 
> >2171, it MAY place a locally significant different value in 
> >the "Admission Priority" field, which is used by downstream 
> >routers within its domain. Subsequent downstream domains that 
> >do support Y.2171 make sure that the "Admission Priority" 
> >field contains the same value as the "Y.2171 Admission Priority" 
> field.>
> >
> >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 
> >_______________________________________________
> >nsis mailing list
> >[email protected]
> >https://www.ietf.org/mailman/listinfo/nsis
> >
> _______________________________________________
> nsis mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/nsis
>