Re: [Dime] Additional comments on draft-ietf-dime-priority-avps-00.txt

[<[e-mail]>]

Thank you for the clarification.
I may have additional minor comments but I will post them in a different mail.

Cheers,

Lionel

> -----Message d'origine-----
> De : ken carlberg [mailto:[e-mail]] 
> Envoyé : mardi 15 juin 2010 15:59
> À : MORAND Lionel RD-CORE-ISS
> Cc : Janet Gunn; [e-mail]; Tom Taylor; James Polk; 
> Francois Le Faucheur
> Objet : Re: [Dime] Additional comments on 
> draft-ietf-dime-priority-avps-00.txt
> 
> Lionel,
> 
> > [Lionel Morand] I was assuming that this mapping was 
> provided, considering the text in IANA considerations 
> inhttp://tools.ietf.org/html/draft-ietf-tsvwg-emergency-rsvp-1
> 5#section-7 and the updated version 
> ofhttp://www.iana.org/assignments/sip-parameters. 
> > If I'm wrong, please ignore my comment.
> > If I'm correct, there is a one-to-one mapping between any 
> namespace in string format and associated numerical value. It 
> is therefore possible to rely on one single AVP to convey 
> name space and priority value, for SIP of RSVP or whatever... Right?
> 
> the mapping described in the IANA considerations of the 
> tsvwg-emergency-rsvp draft was designed to help ensure 
> interoperability concerning a priority value that could be 
> found from different protocols -- namely SIP (with its 
> alphanumeric representation, and RSVP (with its numeric only 
> representation).  We specifically wanted to avoid two 
> different registries because even with the most careful of 
> individuals, there would eventually be a mistake in trying to 
> make sure that different representations of the same priority 
> value would be misaligned.
> 
> At first glance, your proposal of a single group AVP versus 
> two distinct AVPs has an appeal because of its potential 
> simplicity through reduction/subtraction.  However, taking 
> this one step further in terms of the scenarios that these 
> AVPs could be applied would seem to add more complexity than 
> originally intended.  For example, if a policy decision point 
> received an RSVP message with an ALRP policy element (but 
> whose packet payload did *not* contain a SIP message with an 
> RPH header), then it would have the information for the 
> SIP-Resource-Priority-Namespace-Value but nothing for the 
> SIP-Resource-Priority-Namespace-String.  Do we then require a 
> null entry for the latter?
> 
> In addition, your suggested format in the previous email is 
> incomplete because we would still need a group entry defining 
> a string and numeric entry for the Value portion of the RPH tuple.
> 
> As such, I have a preference to keep the defined AVPs as is.  
> If there is still some concern or confusion, we can discuss 
> this offline or in person at the July IETF meeting.
> 
> cheers,
> 
> -ken
> 
> ps, James and Francois, I cc'ed you just to make sure you 
> were in the loop.
> 
> pps, Lionel, thanks a lot for the additional review and 
> thoughts on the topic!
> 
>