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

From: <[email-masked]>
Date: Tue, 15 Jun 2010 12:11:24 +0200

In addition to the previous comments, here is my feedback on this draft.

***************

Section 3.1.

   The Defending-Priority is set when the  reservation  has  been
admitted.
   The  Preemption-Priority of a newly requested reservation is compared
   with the Defending Priority  of  a  previously  admitted  flow.   The
   actions taken based upon the result of this comparison are a function
   of local policy.

Here we are describing how to set and use the value conatined in the
AVPs and not the AVP itself. Would a simple reference to RFC3181 be
enough to know to use this information? This would avoid any possible
misalignment...

********************

Section 3.3/section 3.4

ALRP is just another namespace defined in the same Registry. Moreover,
there are additional namespace defined in RFC 5478. Would it be simpler
to rely on the same AVP to convey the same kind of information.

Here is a proposal:

	The SIP-Resource-Priority AVP is of type Grouped. It provides
the Resource-Priority namespace and the Resource-Priority value
contained in a SIP Resource-Priority header as defined in [RFC4412].

	SIP-Resource-Priority ::= < AVP Header: TBD >
      	                { SIP-Resource-Priority-Namespace }
            	          { SIP-Resource-Priority-Value }

	The SIP-Resource-Priority-Namespace AVP is of type Grouped. It
contains a unique string and the associated numerical value
identifying the namespace.

	SIP-Resource-Priority-Namespace ::= < AVP Header: TBD >
                               { SIP-Resource-Priority-Namespace-String
}
                               { SIP-Resource-Priority-Namespace-Value }

	The SIP-Resource-Priority-Namespace-String AVP (AVP Code TBD) is
of type UTF8String.

	The SIP-Resource-Priority-Namespace-Value AVP (AVP Code TBD) is
of type Unsigned32.

	The SIP-Resource-Priority-Value AVP (AVP Code TBD) is of type
Unsigned32.

Would it be acceptable?

regards

Lionel Morand

---

From: Janet P Gunn <[email-masked]>
Date: Tue, 15 Jun 2010 08:21:24 -0400

I do not understand your statement that   "ALRP is just another namespace 
defined in the same Registry." 

As I understand it, the reason for supporting both RPH and ALRP (even 
though they contain the same information) is for ease in mapping to or 
from protocols that use RPH (e.g., SIP) as well as protocols that use ALRP 
(e.g., RSVP) without having to go through a mapping from text to digits, 
or vice versa. 

 Your proposal, if I am reading it correctly, would require mapping from 
the text priority value (e.g., routine, priority, immediate, flash, 
flash-override) to numerical values.
It would also require  mapping from the RPH (text) namespace to the  ALRP 
(numerical) namespace (or vice versa) in order to include both.

  If you are going to go through that mapping , you might as well map the 
entire RPH into ALRP and be done with it.

If you want to avoid the need to map back and forth between text and 
digits (which I thought was the point), you need to support both RPH (all 
text) and ALRP (all digits) independently.

Janet

[email-masked] wrote on 06/15/2010 06:11:24 AM:

> [image removed] 
> 
> [Dime] Additional comments on draft-ietf-dime-priority-avps-00.txt
> 
> lionel.morand 
> 
> to:
> 
> dime
> 
> 06/15/2010 06:16 AM
> 
> Sent by:
> 
> [email-masked]
> 
> Cc:
> 
> tom.taylor
> 
...
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: <[email-masked]>
Date: Tue, 15 Jun 2010 15:07:11 +0200

Hi Janet,

Please see below.

Regards,

Lionel

________________________________

	De : Janet P Gunn [mailto:[email-masked]] 
	Envoyé : mardi 15 juin 2010 14:21
	À : MORAND Lionel RD-CORE-ISS
	Cc : [email-masked]; [email-masked]; [email-masked]
	Objet : Re: [Dime] Additional comments on draft-ietf-dime-priority-avps-00.txt

	I do not understand your statement that   "ALRP is just another namespace defined in the same Registry."   
	
[Lionel Morand] My mistake! ;) 
	
	As I understand it, the reason for supporting both RPH and ALRP (even though they contain the same information) is for ease in mapping to or from protocols that use RPH (e.g., SIP) as well as protocols that use ALRP (e.g., RSVP) without having to go through a mapping from text to digits, or vice versa. 
	
	 Your proposal, if I am reading it correctly, would require mapping from the text priority value (e.g., routine, priority, immediate, flash, flash-override) to numerical values. 
	It would also require  mapping from the RPH (text) namespace to the  ALRP (numerical) namespace (or vice versa) in order to include both. 
	
	  If you are going to go through that mapping , you might as well map the entire RPH into ALRP and be done with it. 
	
	If you want to avoid the need to map back and forth between text and digits (which I thought was the point), you need to support both RPH (all text) and ALRP (all digits) independently. 
	
[Lionel Morand] I was assuming that this mapping was provided, considering the text in IANA considerations in http://tools.ietf.org/html/draft-ietf-tsvwg-emergency-rsvp-15#section-7 and the updated version of http://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?

Please forgive me if I misunderstood something...

Lionel
	
	Janet

	...
	> https://www.ietf.org/mailman/listinfo/dime <https://www.ietf.org/mailman/listinfo/dime>

---

From: ken carlberg <[email-masked]>
Date: Tue, 15 Jun 2010 09:28:36 -0400

Hi Lionel,

> enough to know to use this information? This would avoid any possible

I have a preference to leave the description of the defending and preemption priority as is.  Its consistent with the other subsections in that each provides a brief description of the AVP, along with a reference of where more in-depth information may be found.  And unfortunately, most folks are not as diligent and careful as you are to follow all the references thoroughly :-), and thus they'll ask why we have various AVPs that seemingly deal with the same priority (not knowing that priority comes in various flavors).

Having said that, please let me know if you feel my description in 3.1 is not as accurate as it should be with respect to rfc-3181.

I'll respond to your other points in a subsequent email.

-ken

---

From: Janet P Gunn <[email-masked]>
Date: Tue, 15 Jun 2010 09:53:34 -0400

Lionel,

Yes, there is a one-to-one mapping between RPH (text namespace, text 
priority) and ALRP (numerical namespace, numerical priority)

But if you want to convert from one to the other (or from either to your 
proposed approach) you need to go and look up that mapping, which is extra 
work for the processor.

My understanding is that  the authors wanted to avoid that extra work- so 
if you receive  a message with RPH, you just blindly copy the text values 
into the its AVP, if you receive ALRP, you blindly copy the numerical 
values into its AVP, no need to go look up the one-to-one mapping. 

Janet

From:
<[email-masked]>
To:
Janet P Gunn/USA/CSC@CSC
Cc:
<[email-masked]>, <[email-masked]>, <[email-masked]>
Date:
06/15/2010 09:11 AM
Subject:
RE: [Dime] Additional comments on draft-ietf-dime-priority-avps-00.txt

Hi Janet,

Please see below.

Regards,

Lionel

                 De : Janet P Gunn [mailto:[email-masked]] 
                 Envoyé : mardi 15 juin 2010 14:21
                 À : MORAND Lionel RD-CORE-ISS
                 Cc : [email-masked]; [email-masked]; 
[email-masked]
                 Objet : Re: [Dime] Additional comments on 
draft-ietf-dime-priority-avps-00.txt

                 I do not understand your statement that   "ALRP is just 
another namespace defined in the same Registry." 

                 As I understand it, the reason for supporting both RPH 
and ALRP (even though they contain the same information) is for ease in 
mapping to or from protocols that use RPH (e.g., SIP) as well as protocols 
that use ALRP (e.g., RSVP) without having to go through a mapping from 
text to digits, or vice versa. 
 
                  Your proposal, if I am reading it correctly, would 
require mapping from the text priority value (e.g., routine, priority, 
immediate, flash, flash-override) to numerical values. 
                 It would also require  mapping from the RPH (text) 
namespace to the  ALRP (numerical) namespace (or vice versa) in order to 
include both. 
 
                   If you are going to go through that mapping , you might 
as well map the entire RPH into ALRP and be done with it. 
 
                 If you want to avoid the need to map back and forth 
between text and digits (which I thought was the point), you need to 
support both RPH (all text) and ALRP (all digits) independently. 
 
[Lionel Morand] I was assuming that this mapping was provided, considering 
the text in IANA considerations in 
http://tools.ietf.org/html/draft-ietf-tsvwg-emergency-rsvp-15#section-7 
and the updated version of http://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?

Lionel
 
                 Janet

                 ...
                 > https://www.ietf.org/mailman/listinfo/dime <
https://www.ietf.org/mailman/listinfo/dime>

---

From: ken carlberg <[email-masked]>
Date: Tue, 15 Jun 2010 09:58:36 -0400

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-15#section-7 and the updated version ofhttp://www.iana.org/assignments/sip-parameters. 

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!

---

From: <[email-masked]>
Date: Tue, 15 Jun 2010 22:53:53 +0200

got it ;)
 
Thank you!
 
Lionel

	De : Janet P Gunn [mailto:[email-masked]] 
	Envoyé : mardi 15 juin 2010 15:54
	À : MORAND Lionel RD-CORE-ISS
	Cc : [email-masked]; [email-masked]; [email-masked]
	Objet : RE: [Dime] Additional comments on draft-ietf-dime-priority-avps-00.txt

	Lionel, 
	
	Yes, there is a one-to-one mapping between RPH (text namespace, text priority) and ALRP (numerical namespace, numerical priority) 
	
	But if you want to convert from one to the other (or from either to your proposed approach) you need to go and look up that mapping, which is extra work for the processor. 
	
	My understanding is that  the authors wanted to avoid that extra work- so if you receive  a message with RPH, you just blindly copy the text values into the its AVP, if you receive ALRP, you blindly copy the numerical values into its AVP, no need to go look up the one-to-one mapping. 
	
	Janet

From: 	<[email-masked]> 
To: 	Janet P Gunn/USA/CSC@CSC 
Cc: 	<[email-masked]>, <[email-masked]>, <[email-masked]> 
Date: 	06/15/2010 09:11 AM 
Subject: 	RE: [Dime] Additional comments on draft-ietf-dime-priority-avps-00.txt

	Hi Janet,
	
	Please see below.
	
	Regards,
	
	Lionel

	                De : Janet P Gunn [mailto:[email-masked] <mailto:[email-masked]> ] 

	                

	                

	[Lionel Morand] I was assuming that this mapping was provided, considering the text in IANA considerations in http://tools.ietf.org/html/draft-ietf-tsvwg-emergency-rsvp-15#section-7 <http://tools.ietf.org/html/draft-ietf-tsvwg-emergency-rsvp-15#section-7>  and the updated version of http://www.iana.org/assignments/sip-parameters <http://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?

	Lionel
	                
	                Janet

	                ...
	                > https://www.ietf.org/mailman/listinfo/dime <https://www.ietf.org/mailman/listinfo/dime>  <https://www.ietf.org/mailman/listinfo/dime <https://www.ietf.org/mailman/listinfo/dime> >

---

From: <[email-masked]>
Date: Tue, 15 Jun 2010 22:56:21 +0200

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:[email-masked]] 
> Envoyé : mardi 15 juin 2010 15:59
> Cc : Janet Gunn; [email-masked]; Tom Taylor; James Polk; 
> Francois Le Faucheur
> > [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 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
>