Subject: Re: [Dime] Diameter QoS Parameter -- DECISION TO MAKE

From: "Hannes Tschofenig" <[email-masked]>
Date: Sun, 1 Mar 2009 17:18:18 +0200

Hi all, 

I just had a chat with Dan and he came up with the following alternative
proposal. 

Instead of referencing draft-ietf-tsvwg-emergency-rsvp-11 normatively we
reference it informatively. How can we make such a simple change? Well. We
really only need a part of the registry in
draft-ietf-tsvwg-emergency-rsvp-11.
Then, we copy the text from the IANA consideration section that creates the
numerical registry corresponding to the registry created by RFC 4412. 

Here are the necessary text changes: 

----------

3.5.  Admission-Priority AVP

   The Admission-Priority AVP (AVP Code TBD) is of type Unsigned32.

OLD: 

   The admission control priority of the flow, in terms of access to
   network bandwidth in order to provide higher probability of call
   completion to selected flows.  Higher values represent higher
   priority.  Section 3.1 of
   [I-D.ietf-tsvwg-emergency-rsvp] (Admission Priority parameter)
   illustrates how these values are carried in RSVP. 

NEW: 

   The admission control priority of the flow, in terms of access to
   network bandwidth in order to provide higher probability of call
   completion to selected flows.  Higher values represent higher
   priority.  A given admission priority is encoded in this information
   element using the same value as when encoded in the Admission-
   Priority AVP defined in Section 3.1 of
   [I-D.ietf-tsvwg-emergency-rsvp] (Admission Priority parameter).

3.6.  ALRP AVP

   The Application-Level Resource Priority (ALRP) AVP is a grouped AVP
   consisting of two AVPs, the ALRP-Namespace and the ALRP-Priority AVP.

OLD:

   A description of the semantic of the parameter values can be found in
   [RFC4412] and in [I-D.ietf-tsvwg-emergency-rsvp].  The coding for
   parameter is as follows:

NEW: 

   A description of the semantic of the parameter values can be found in
   [RFC4412]. A description on how to carry the valus within RSVP is 
   provided in [I-D.ietf-tsvwg-emergency-rsvp].  The coding for
   parameter is as follows:

                       ALRP  ::= < AVP Header: TBD >
                                 { ALRP-Namespace }
                                 { ALRP-Priority }

3.6.1.  ALRP-Namespace AVP

   The ALRP-Namespace AVP (AVP Code TBD) is of type Unsigned32.

3.6.2.  ALRP-Priority AVP

   The ALRP-Priority AVP (AVP Code TBD) is of type Unsigned32.

OLD:

   [RFC4412] defines a resource priority header and established the
   initial registry.  That registry was later extended by
   [I-D.ietf-tsvwg-emergency-rsvp].

NEW: 

   [RFC4412] defines a resource priority header and established the
   corresponding registry.  That registry was later converted 
   to allow priorities to be expressed via numerical values by
   [I-D.ietf-tsvwg-emergency-rsvp].

----------

ADD to the IANA consideration section: 

----------

ALRP Namespace

   IANA already maintains the
   Resource-Priority Namespaces registry (under the SIP Parameters)
   listing all such namespace.  However, that registry does not
   currently allocate a numerical value to each namespace.  Hence, this
   document requests the IANA to extend the Resource-Priority Namespace
   registry in the following ways:

   o  a new column should be added to the registry

   o  the title of the new column should be "Namespace Numerical Value
      *"

   o  in the Legend, add a line saying "Namespace Numerical Value = the
      unique numerical value identifying the namespace"

   o  add a line at the bottom of the registry stating the following "*
      : [RFCXXX] " where XXX is the RFC number of the present document

   o  allocate an actual numerical value to each namespace in the
      registry and state that value in the new "Namespace numerical
      Value *" column.

   A numerical value should be allocated immediately by IANA to all
   existing namespace.  Then, in the future, IANA should automatically
   allocate a numerical value to any new namespace added to the
   registry.

ALRP Priority

   IANA already maintains the Resource-Priority
   Priority-values registry (under the SIP Parameters) listing all such
   priorities.  However, that registry does not currently allocate a
   numerical value to each priority-value.  Hence, this document
   requests the IANA to extend the Resource-Priority Priority-Values
   registry in the following ways:

   o  for each namespace, the registry should be structured with two
      columns

   o  the title of the first column should read "Priority Values (least
      to greatest)"

   o  the first column should list all the values currently defined in
      the registry (e.g. for the drsn namespace: "routine", "priority",
      "immediate", "flash", "flash-override", "flash-override-override"
      for the drsn namespace)

   o  the title of the second column should read "Priority Numerical
      Value *"

   o  At the bottom of the registry, add a "Legend" with a line saying
      "Priority Numerical Value = the unique numerical value identifying
      the priority within a namespace"

   o  add a line at the bottom of the registry stating the following "*
      : [RFCXXX] " where XXX is the RFC number of the present document

   o  allocate an actual numerical value to each and state that value in
      the new "Priority Numerical Value *" column.

   A numerical value should be allocated immediately by IANA to all
   existing priority.  Then, in the future, IANA should automatically
   allocate a numerical value to any new namespace added to the
   registry.  The numerical value must be unique within each namespace.
   For the initial allocation, within each namespace, values should be
   allocated in decreasing order ending with 0 (so that the greatest
   priority is always allocated value 0).  For example, in the drsn
   namespace, "routine" would be allocated numerical value 5 and "flash-
   override-override" would be allocated numerical value 0.

-----

Ciao
Hannes

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of Hannes Tschofenig
>Sent: 28 February, 2009 11:25
>To: [email-masked]
>Subject: [Dime] Diameter QoS Parameter -- DECISION TO MAKE
>
>Hi all, 
>
>we have a normative reference in the Diameter QoS parameter 
>draft 
>http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-paramet
>ers-09.txt
>pointing to 
>http://tools.ietf.org/html/draft-ietf-tsvwg-emergency-rsvp-11
>
>Yesterday, Magnus posted a mail to the TSVWG list that 
>draft-ietf-tsvwg-emergency-rsvp-11.txt is having a lot of 
>problems getting through the IESG and the document bounced 
>back to the working group. The mail can be found here: 
>http://www.ietf.org/mail-archive/web/tsvwg/current/msg09070.html
>
>Now, there is the risk of considerable delay in publication of 
>our Diameter QoS parameter document as it will be blocked (for 
>potentially a long time).
>Since the Diameter QoS attribute and the Diameter QoS 
>application document normatively depend on the QoS parameter 
>document they will be blocked as well. 
>
>So, I have been thinking of what we could do to deal with this 
>issue and here is a proposal to the group. 
>
>***************
>My proposal is to move the priority parameters (Priority AVP, 
>Admission-Priority AVP, and ALRP AVP) into a separate document 
>and to progress them independently to get the main part of the 
>Diameter QoS parameters document finalized. 
>***************
>
>Please let me know if you find this idea acceptable. Please 
>respond as quickly as possible!
>
>Ciao
>Hannes
>
>PS: We would have to find an editor and authors for that the 
>new document that contains the priority parameters but we can 
>worry about that part larter. 
>
>_______________________________________________
>DiME mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dime
>

---

From: Fortune HUANG <[email-masked]>
Date: Mon, 02 Mar 2009 09:06:50 +0800

Hi Hannes,

I basically support your proposal of referencing referencing
draft-ietf-tsvwg-emergency-rsvp-11 informatively in stead of normatively.
My further question for clarification is: can we just provide a complete and
precise definition to each AVP (e.g. at least what the AVP indicates) in the
section where it is defined, without  redirecting the reader to another
document to get his own version of the definition? 

Best Regards,
Fortune

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hannes Tschofenig
Sent: Sunday, March 01, 2009 11:18 PM
To: [email-masked]; [email-masked]; 'Romascanu, Dan (Dan)'
Subject: Re: [Dime] Diameter QoS Parameter -- DECISION TO MAKE

Hi all, 

----------

OLD: 

NEW: 

3.6.  ALRP AVP

OLD:

NEW: 

3.6.2.  ALRP-Priority AVP

OLD:

NEW: 

----------

----------

ALRP Namespace

ALRP Priority

-----

Ciao
Hannes

>From: [email-masked] [mailto:[email-masked]] On Behalf Of 
>Hannes Tschofenig
>we have a normative reference in the Diameter QoS parameter draft 
>draft-ietf-tsvwg-emergency-rsvp-11.txt is having a lot of problems 
>getting through the IESG and the document bounced back to the working 
>group. The mail can be found here:
>Now, there is the risk of considerable delay in publication of our 
>Diameter QoS parameter document as it will be blocked (for potentially 
>a long time).
>Since the Diameter QoS attribute and the Diameter QoS application 
>document normatively depend on the QoS parameter document they will be 
>blocked as well.
>
>So, I have been thinking of what we could do to deal with this issue 
>and here is a proposal to the group.
>
>***************
>Admission-Priority AVP, and ALRP AVP) into a separate document and to 
>progress them independently to get the main part of the Diameter QoS 
>parameters document finalized.
>***************
>
>Please let me know if you find this idea acceptable. Please respond as 
>quickly as possible!
>
>Ciao
>Hannes
>
>PS: We would have to find an editor and authors for that the new 
>document that contains the priority parameters but we can worry about 
>that part larter.
>

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 3 Mar 2009 07:47:35 +0200

Hi Fortune, 

>draft-ietf-tsvwg-emergency-rsvp-11 informatively in stead of 

Thanks for your feedback. 

>My further question for clarification is: can we just provide 
>a complete and precise definition to each AVP (e.g. at least 
>what the AVP indicates) in the section where it is defined, 
>without  redirecting the reader to another document to get his 
>own version of the definition? 
I am very reluctant to copy-and-paste text from other RFCs into this
document just to avoid having the reader to fetch other documents. So
far, in all our documents, we have tried to avoid duplication as much as
possible. 

Ciao
Hannes

>I just had a chat with Dan and he came up with the following 
>alternative proposal. 
>
>Instead of referencing draft-ietf-tsvwg-emergency-rsvp-11 
>normatively we reference it informatively. How can we make 
>such a simple change? Well. We really only need a part of the 
>registry in draft-ietf-tsvwg-emergency-rsvp-11.
>Then, we copy the text from the IANA consideration section 
>that creates the numerical registry corresponding to the 
>registry created by RFC 4412. 
>

---

From: jouni korhonen <[email-masked]>
Date: Tue, 3 Mar 2009 10:07:58 +0200

Hi all,

I would support removing as well. Be done with it and move on with the  
QoS parameter document. Those features that were in the tsvwg document  
can be documented later in a separate document, when and if needed.

Cheers,
	Jouni

On Feb 28, 2009, at 11:25 AM, Hannes Tschofenig wrote:

> http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-parameters-09.txt
> pointing to http://tools.ietf.org/html/draft-ietf-tsvwg-emergency-rsvp-11
>
> getting
> through the IESG and the document bounced back to the working group.  
> The
> mail can be found here:
> Diameter
> QoS parameter document as it will be blocked (for potentially a long  
> time).
> document
> normatively depend on the QoS parameter document they will be  
> blocked as
> well.
>
> document
> that contains the priority parameters but we can worry about that part
> larter.
>

---

From: Fortune HUANG <[email-masked]>
Date: Tue, 03 Mar 2009 16:22:12 +0800

Hi Hannes,

But I still think at least we should provide a brief statement about what
the AVP indicates. And I also would like to have the detailed location of
the relevant reference in this draft because it would be painful to go over
another RFC just for the meaning of one AVP.

Best Regards,
Fortune

-----Original Message-----
From: Tschofenig, Hannes (NSN - FI/Espoo) [mailto:[email-masked]]

Sent: Tuesday, March 03, 2009 1:48 PM
To: ext Fortune HUANG; Hannes Tschofenig; [email-masked];
[email-masked]; Romascanu,Dan (Dan)
Subject: RE: [Dime] Diameter QoS Parameter -- DECISION TO MAKE

Hi Fortune, 

>My further question for clarification is: can we just provide a 
>complete and precise definition to each AVP (e.g. at least what the AVP 
>indicates) in the section where it is defined, without  redirecting the 
>reader to another document to get his own version of the definition?
I am very reluctant to copy-and-paste text from other RFCs into this
document just to avoid having the reader to fetch other documents. So far,
in all our documents, we have tried to avoid duplication as much as
possible. 

Ciao
Hannes

>normatively we reference it informatively. How can we make such a 
>simple change? Well. We really only need a part of the registry in 
>Then, we copy the text from the IANA consideration section that creates 
>the numerical registry corresponding to the registry created by RFC 
>4412.
>

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 3 Mar 2009 10:29:11 +0200

Hi Fortune, 

>Hi Hannes,
>
>But I still think at least we should provide a brief statement 
>about what the AVP indicates.

There is a brief statement about the AVPs in the beginning of the
document. 

>And I also would like to have 
>the detailed location of the relevant reference in this draft 
>because it would be painful to go over another RFC just for 
>the meaning of one AVP.

Well. This is somewhat difficult. Think about DiffServ Code Points. 
Which part of what document would provide you the information you would
like to know?

Ciao
Hannes

PS: If we follow Jouni's suggestion then the reader has fewer documents
to look at. 

>I am very reluctant to copy-and-paste text from other RFCs 
>into this document just to avoid having the reader to fetch 
>other documents. So far, in all our documents, we have tried 
>to avoid duplication as much as possible. 
>
>Ciao
>Hannes
>
>>Best Regards,
>>Fortune
>>
>that creates

---

From: Victor Fajardo <[email-masked]>
Date: Mon, 02 Mar 2009 17:47:51 -0500

I agree.

>> through the IESG and the document bounced back to the working group. The
>> mail can be found here:
>> normatively depend on the QoS parameter document they will be blocked as
>> well.
>>
>> So, I have been thinking of what we could do to deal with this issue and
>> here is a proposal to the group.
>>
>> ***************

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 3 Mar 2009 15:24:17 +0100

> Sent: Tuesday, March 03, 2009 10:29 AM
> [email-masked]; Romascanu, Dan (Dan)
> >But I still think at least we should provide a brief statement about 
> >what the AVP indicates.
> 
> There is a brief statement about the AVPs in the beginning of 
> the document. 
> 
> >the detailed location of the relevant reference in this 
> draft because 
> >it would be painful to go over another RFC just for the 
> meaning of one 
> >AVP.
> 
> Which part of what document would provide you the information 
> you would like to know?
> 

Actually I agree with Fortune on this. If I understand him well he is
asking for a more exact pointer to the section in the referred documents
(e.g. Section 7.3 in [RFC xxxx] instead of [RFC xxxx]). This is good
practice and is possible in the majority of the cases. Even in the case
of DSCP we can point to the section where the term is defined of first
introduced. 

Dan
(speaking as a contributor)

---

From: Mark Jones <[email-masked]>
Date: Wed, 4 Mar 2009 13:18:30 -0500

I also support removing these parameters in order to move forward with the QoS drafts. The Diameter QoS parameters draft is defining one possible QoS template but the QoS attributes draft allows a set of supported QoS profiles to be negotiated. So a new QoS profile template can be defined later for the tsvwg parameters when they are stable. 

Regards
Mark

> Behalf Of Victor Fajardo
> Sent: March 2, 2009 17:48
> To: jouni korhonen
> Cc: [email-masked]

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Tue, 10 Mar 2009 17:10:30 +0200

Hi Dan, 
Hi Fortune, 

Normally, I would have said "Please provide text". :-)

But we have tried to provide more specific references with the latest
document update. I hope you both are happy now. 
Here is the updated document: 
http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-parameters-10.txt

Ciao
Hannes

>From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
>Sent: 03 March, 2009 16:24
>To: Tschofenig, Hannes (NSN - FI/Espoo); ext Fortune HUANG; 
>Hannes Tschofenig; [email-masked]; [email-masked]
>> Which part of what document would provide you the information you 
>> would like to know?
>> 
>
>Actually I agree with Fortune on this. If I understand him 
>well he is asking for a more exact pointer to the section in 
>the referred documents (e.g. Section 7.3 in [RFC xxxx] instead 
>of [RFC xxxx]). This is good practice and is possible in the 
>majority of the cases. Even in the case of DSCP we can point 
>to the section where the term is defined of first introduced. 
>
>Dan