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

Hello Jerry,

On 20 Feb 2008, at 16:58, Gerald Ash wrote:

> Francois,
>
> In your "Proposed Resolution" posting to NSIS on 3 December http:// 
> www.ietf.org/mail-archive/web/nsis/current/msg08155.html you say:
>
> > The Proposed Resolution
> > ===================
> > Co-authors of the three I-Ds as well as WG chairs of the
> > corresponding WGs converged on the following proposed
> > resolution.
>
> I saw no discussion of this proposed resolution on the NSIS list.

which is why we've been assuming there was no issue with it.


> Who were the QSPEC co-authors who worked with you on the proposed  
> resolution?

Attila, Cornelia and Dave Oran (+ NSIS WG chairs).


>
> > o Regarding RPH-Priority:
> > * tsvwg-emergency-rsvp will go ahead with its requests to
> > IANA to provide numerical registry for RPH priority (via
> > extending existing RPH registry). See IANA Considerations
> > section of tsvwg-emergency-rsvp.
> > * nsis-qspec (in section 6.2.10) will point to this registry
> > instead of defining its own values
>
> OK.
>
> > o Regarding Admission Priority:
> > * every protocol spec will only indicate that "higher value
> > means higher priority".
> > * there is no attempt to define what specific values should
> > be used for what. this is left outside the scope of the
> > protocol specs.
> * each protocol spec will add a statement clarifying that a
> > given Admission Priority is to be encoded with the same
> > value in each of the three protocol spec. For example, in
> > tsvwg-emergency-rsvp, under section 3.1. we will add:
> " 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-qos-parameters].
> > In other words, a given value in any of the
> > [emergency-rsvp] Admission Priority information element,
> > the [nsis-qspec] Admission Priority parameter or the
> > [dime-qos-parameters] Admission Priority parameter,
> > refers to the same Admission Priority.
> The above proposed paragraph is really unclear.  Which draft is  
> setting up IANA Registries to assign Admission Priority  
> parameters?  The way it reads it sounds like all three drafts are  
> setting up registries but that somehow (magically) all refer "to  
> the same Admission Priority".  How can that be if they assign  
> different values?  Right now emergency-rsvp and nsis-qspec set up  
> registries for Admission Priority and dime-qos-parameters is using  
> the nsis-qspec registry as I recall.
>
> Please clarify the proposal as to which draft is setting up a  
> registry for Admission Priority.

No registry is setup.
It is up to a network administrator to decide how many/which  
admission priority gets used for what. This is similar to how  
Preemption is used (ie each network administrator may decide to use  
it or not, may decide to use 2,3,4,...128,.. levels...).
The statement above only says that the the same value of admission  
priority should be used in the three protocols to refer to same level  
of admission priority.

Cheers

Francois


> Also, please provide clearer proposed text to include in the drafts.
>
> It would be good to see some discussion of the proposal on the  
> list, to confirm and validate agreement of the WG.
>
> Jerry
>
>
> Francois Le Faucheur IMAP <[email protected]> wrote:
> Hello,
>
> For memory, the next rev of nsis-qspec is also expected to be aligned
> with the Resolution of the issue related to QoS Parameters encoding
> in , & . For
> convenience, I included below the recap on the corresponding
> resolution as announced on NSIS, DIME and TSVWG lists.
>
> Just to make sure this does not fall through the cracks.
>
> Cheers
>
> Francois
>
>
> >
> > Begin forwarded message:
> >> From: Francois Le Faucheur IMAP
> >> Date: 3 December 2007 12:05:42 GMT+01:00
> >> To: [email protected], [email protected], tsvwg tsvwg
> >> Cc: Francois Le Faucheur IMAP , David Oran R
> >> , Hannes Tschofenig ,
> >> ken carlberg , Magnus Westerlund
> >> , James Polk ,
> >> [email protected], "(IJ/ETH) Báder Attila"
> >> , [email protected], Jukka
> >> Manner MJ , tsvwg chair
> >> [email protected]>, [email protected], dime-
> >> [email protected], "[email protected]>"
> >>
> >> Subject: Resolution of issue QoS Parameters encoding in
> >> parameters>, &
> >>
> >> Hello,
> >>
> >> The Issue:
> >> =======
> >> Three different documents (dime-qos-parameters, nsis-qos-nslp,
> >> tsvwg-emergency-rsvp) need to convey an overlapping set of QoS
> >> parameters (specifically RPH-Priority and Admission Priority) and
> >> currently do that in an inconsistent manner. This has been brought
> >> up and partially discussed on the WG mailing lists.
> >>
> >> The Proposed Resolution
> >> ===================
> >> Co-authors of the three I-Ds as well as WG chairs of the
> >> corresponding WGs converged on the following proposed resolution.
> >> Please let us know if you have an issue/concern with this.
> >>
> >> o Regarding RPH-Priority:
> >> * tsvwg-emergency-rsvp will go ahead with its requests to IANA to
> >> provide numerical registry for RPH priority (via extending
> >> existing RPH registry). See IANA Considerations section of tsvwg-
> >> emergency-rsvp.
> >> * nsis-qspec (in section 6.2.10) will point to this registry
> >> instead of defining its own values
> >> * dime-qos-parameters (in section 4.11) will point to this
> >> registry instead of defining its own values
> >> * tsvwg-emergency-rsvp (in section 3.2) will keep pointing to
> >> this registry.
> >>
> >> o Regarding Admission Priority:
> >> * every protocol spec will only indicate that "higher value means
> >> higher priority".
> >> * there is no attempt to define what specific values should be
> >> used for what. this is left outside the scope of the protocol  
> specs.
> >> * each protocol spec will add a statement clarifying that a given
> >> Admission Priority is to be encoded with the same value in each of
> >> the three protocol spec. For example, in tsvwg-emergency-rsvp,
> >> under section 3.1. we will add:
> >> " 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-qos-
> >> parameters].
> >> In other words, a given value in any of the [emergency-rsvp]
> >> Admission
> >> Priority information element, the [nsis-qspec] Admission Priority
> >> parameter
> >> or the [dime-qos-parameters] Admission Priority parameter,  
> refers to
> >> the same Admission Priority.
> >> "
> >> * the mirror statement will be added in nsis-qspec (section
> >> 6.2.9) and dime-qos-parameters (section 4.10)
> >>
> >> Francois
> >>
>
>
>
>
>
>
> Looking for last minute shopping deals? Find them fast with Yahoo!  
> Search.

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