Re: Admission field in QSPEC -- was RE: Review ofdraft-ietf-nsis-qspec-18.txt

> It wasn't my proposal, it was Ken's proposal who said that if  
> adopted he would "be more than happy to drop the subject  
> altogether."  However, it seems now that this agreement wasn't  
> enough to drop the subject altogether after all.

my frustration with your input in the matter has made it all too  
tempting to wash my hands of the matter. however, I will not disregard  
input from calmer third parties.

> > However, there current approach elimantes the idea of
> > having an object understood by all participating partners
> > (RSVP, NSIS, etc) in terms of the admission priority.
> >
> > The updated QSPEC will solely have the "Y.2171 Admission
> > Priority" but no general purpose admission priority (as in
> > draft-ietf-tsvwg-emergency-rsvp).
>
> Note that the emergency-rsvp folks would prefer to call the rsvp  
> admission priority "generic admission priority" (GAP).  The object  
> used for GAP is as follows (see Section 3.1 of  http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-emergency-rsvp-05.txt) 
> :

this has now gotten silly.  in a previous email you asked that we  
change the field to the "rsvp admission priority" and now you are  
asking that we change it to the "generic admission priority".  this  
really smells too much of If-I-have-to-change-it-so-you-have-to-change- 
it.  I stated quite clearly that the suggested name change stems from  
your explicitly tying the field to the Y.2171 document.  Which is  
consistent with what you did later in your document in Section 5.2.14  
concerning the Y.1541 QoS.  So please stop this tit-for-tat argument.

> > How about having the "Y.2171 Admission Priority" and the
> > general purpose admission priority in the QSPEC?
>
> A possible approach would be to add an L bit in the NSIS admission  
> priority object, as follows (see Section 5.2.9 in http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-19.txt) 
> :

well, one constructive thing would have been to start with a response  
why you feel Martin's idea above is not acceptable.  As for an "L"  
bit, I'll discuss this with James and Francois.  However, any reliance  
or dependency on Y.2171 as an exclusive authoritative source for  
values is probably not acceptable for RSVP draft.  I won't repeat why  
since that can be seen in the archives.


> 5.2.9 <Admission Priority> Parameter [Y.2171]
>
>    The coding for the <Admission Priority> parameter is as follows:
>
> 0                   1                   2                   3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |M|E|N|r|           9           |r|r|r|r|          1            |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Admis.Priority|L|                (Reserved)                   |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>    High priority flows, normal priority flows, and best-effort  
> priority
>    flows can have access to resources depending on their admission
>    priority value, as described in [Y.2171], as follows:
>
>    Admission Priority:
>
>    0 - best-effort priority flow
>    1 - normal priority flow
>    2 - high priority flow
>
>    L bit:
>
>    0 - admission priority field has end-to-end significance
>        (above admission priority values in IANA registry apply)
>    1 - admission priority field has local significance only
>        (admission priority values set by local domain administrator)

just for old times sake, I'll still be thrilled to hear what you will  
do if the ITU updates Y.2171 with a non-backwards compatible set of  
values.

> It would be good to get some other opinions here, besides the 4 or 5  
> of us who have discussed this so far.

indeed.  I'd be quite interested to hear from the other co-authors of  
the QSPEC have to say.  I spoke briefly with James Polk about the  
matter and he is not in favor of tying the Admission Priority field in  
the RSVP draft to any output from the ITU.  (James is not on the NSIS  
list, hence his lack of direct input).

-ken

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