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

Jerry,

 > Right, there is no issue in having an IETF spec tied to an ITU  
spec.  If ITU modifies their
 > spec, IANA will make the corresponding changes in the IETF IANA  
assignments.  E.g., if
 > ITU later standardizes more priority levels, say in "Y.2171.bis',  
IANA will change the
 > admission priority registry accordingly.  I checked that out with  
IANA a while ago, IANA can
 > tie into ITU specs in this way.

if the Admission field in the QSPEC is to be so entwined with Y.1541  
values (and possibly Y.2171.bis), then perhaps the Admission field in  
QSPEC should be renamed as ITU-Admission?  Or possibly one could  
define a new field called ITU-admission that supports the Y.1541 pre- 
defined values.  It would also seem helpful to add another related  
field that indicates which Y.xxxx standard is being used since there  
may be some domains that only support Y.1541, others supporting Y. 
2171.bis, and whatever future iteration is defined by the ITU.  I  
assume  folks are not relying on a flag day change in support of new  
updates generated by the ITU?

and as far as the current values set by Y.1541, I wish there was  
support for Scavenger Service, which is considered less than Best  
Effort (already defined as "0" in Y.1541).  Since I'm not a member of  
the ITU, I can't advocate this position nor accomplish it if the  
Admission field of all three drafts <emergency-rsvp>, <dime-qos- 
parameters> and <nsis-qspec> are subject to values defined by the ITU.

and please note, I'm not saying that a field cannot reflect efforts  
put forth by the ITU, but rather if the need must exist, then I'd  
prefer that the QSPEC authors rename or create a new field for Y.1541  
or Y.2171.bis

regards,

-ken

_______________________________________________
nsis mailing list
[email protected]
http://www.ietf.org/mailman/listinfo/nsis