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

> BTW, essentially all service providers and equipment vendors belong  
> to and participate in the ITU.  All these service providers and  
> equipment vendors have unanimously agreed to Y.2171.

(i'll bite my tongue a bit).... but of those that do participate in  
the ITU, do they all support Y.2171 and provide it as a contracted  
service?  As written in QSPEC, the Admin Priority field is bound to  
those providers/vendors that offer the Y.2171 service, meaning that  
only those domains that support the 3 defined levels of Y.2171 can  
support the Admission Priority field of the QSPEC.  Also, there is a  
big difference between those that agree on a standard and those that  
support it as a service.

> This is a very different approach to 'admission priority' from what  
> QSPEC is standardizing.  You are introducing policy elements, PDPs  
> doing 'mappings', preemption, and namespaces.  AFAIK preemption  
> priority doesn't have namespaces, are you perhaps referring to RPH  
> namespaces here?

I didn't suggest preemption priority has namespaces, I just said that  
the topic is discussed -- specifically in sections 1.1 and 2.0 of ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-tsvwg-emergency-rsvp-05.txt

> > now, I'll re-ask my question.  if we follow your original approach
> > concerning the Admission Priority field, how do we know what  
> priority set is
> > to be supported if the ITU comes back and updates Y.2171 with a  
> different
> > set of values?  the QSPEC document started with Y.1571, and now we  
> have
> > Y.2171.  Certainly a flag day is not what is expected as a  
> solution to
> > support Y.<next-priority-set>.
>
> There is only Y.2171 and no Y.1571.  If ITU modifies Y.2171 later,  
> say adds more values, IANA tracks those changes into the admission  
> priority registry defined in QSPEC.  This is standard IANA policy;  
> registries do not have to be based *only* on IETF standards, they  
> can be based on standards from other SDOs.  I pointed this out  
> earlier based on my discussion with IANA a while ago.

I believe we are talking past each other at this point.  As I said  
before, I have _no_ qualms about tying the values of a field (and I'll  
explicitly say, a field placed in the IANA registry) to the values set  
by another standards body.  My concern is that you have a taken a  
field representing a (in your own words) "generic concept" (and most  
importantly _shared_ by two other documents) and constrained it to the  
output of another standards body.  Notice that neither I nor Francois  
has said any word about the field in Section 5.2.14 of the QSPEC  
titled "Y.1541 QoS Class".  The name says it all in that it is tied  
directly to Y.1541.

If the name of the field in Section 5.2.9 of the QSPEC is changed to  
"Y.2171 Admission Priority", I'll be more than happy to drop the  
subject altogether, and suggest we'll note in [emergency-rsvp] draft  
that Admission Priority field is not directly comparable with that in  
the QSPEC so as to avoid confusion.

But if the NSIS group and the QSPEC authors choose to keep the name  
Admission Priority as is, I'll beat the dead horse one last time and  
ask what will you do if the ITU updates Y.2171 with a new set of  
values (and IANA registers them) in light on an installed base that  
supports the original set of Y.2171?  Do you not lose the continuity  
in your approach with a flag day change by the installed base?

regards,

-ken