Re: [Dime] Comments on draft-ietf-dime-priority-avps-01.txt

ken carlberg <carlberg@g11.org.uk> Thu, 24 June 2010 11:13 UTC

Return-Path: <carlberg@g11.org.uk>
X-Original-To: dime@core3.amsl.com
Delivered-To: dime@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99F1E3A697B for <dime@core3.amsl.com>; Thu, 24 Jun 2010 04:13:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.073
X-Spam-Level:
X-Spam-Status: No, score=-0.073 tagged_above=-999 required=5 tests=[AWL=-0.074, BAYES_50=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24qySmOWhLAX for <dime@core3.amsl.com>; Thu, 24 Jun 2010 04:13:04 -0700 (PDT)
Received: from portland.eukhosting.net (portland.eukhosting.net [92.48.97.5]) by core3.amsl.com (Postfix) with ESMTP id 345703A684D for <dime@ietf.org>; Thu, 24 Jun 2010 04:13:03 -0700 (PDT)
Received: from c-76-111-69-4.hsd1.va.comcast.net ([76.111.69.4]:50812 helo=[192.168.0.20]) by portland.eukhosting.net with esmtpa (Exim 4.69) (envelope-from <carlberg@g11.org.uk>) id 1ORkMm-0001AJ-Of; Thu, 24 Jun 2010 11:13:09 +0000
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset="us-ascii"
From: ken carlberg <carlberg@g11.org.uk>
In-Reply-To: <D109C8C97C15294495117745780657AE0C9CAACD@ftrdmel1>
Date: Thu, 24 Jun 2010 07:13:08 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <320B7A65-ADBC-42BF-8FA2-FAFE4C18CDA0@g11.org.uk>
References: <D109C8C97C15294495117745780657AE0C9CAACD@ftrdmel1>
To: lionel.morand@orange-ftgroup.com
X-Mailer: Apple Mail (2.1081)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - portland.eukhosting.net
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - g11.org.uk
X-Source:
X-Source-Args:
X-Source-Dir:
Cc: dime@ietf.org
Subject: Re: [Dime] Comments on draft-ietf-dime-priority-avps-01.txt
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Jun 2010 11:13:07 -0000

Hi Lionel,

my apologies for the very tardy reply

> Abstract:
> 
>   This document  defines  Attribute-Value  Pair  (AVP)  containers  for
>   various  priority  parameters  for  use  with  Diameter  and  the AAA
>   framework. 
> 
> ==> Acronyms in Abstract should be avoided.

the I-D guidelines only stress that acronyms should be expanded, so I think we are fine here.
http://www.ietf.org/id-info/guidelines.html#anchor11

> *******
> Section 1.  Introduction:
> 
>   This document defines a number of Attribute-Value Pairs  (AVPs)  that
>   can  be  used  within  the  Diameter  protocol  [RFC3588] to convey a
>   specific set of priority parameters.  The parameters  themselves  are
>   specified in other documents, but are described briefly below.
> 
> ==> Should it be for use in Diameter QoS application (RFC5866) instead
> of diameter base protocol (rfc3588)?

You raise a good point.  i think its good to keep a reference in the Introduction to rfc3588, but I should also add in this section that this particular draft also represents an extension to rfc5866

> *******
> Section 3.1.  Dual-Priority AVP
> 
>   The Dual-Priority AVP is a grouped AVP consisting of  two  AVPs;  the
>   Preemption-Priority  and  the Defending-Priority AVP.  These AVPs are
>   derived from  the  corresponding  priority  fields  in  the  Signaled
>   Preemption  Priority Policy Element [RFC3181] of RSVP [RFC2205].  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.
> 
> ==> I think that it would be useful to repeat at the end of this text
> that the use of theses parameters is specified in RFC3181.

that would seem to be a bit redundant within the same paragraph.  If its important for us to use the word "specified" in the text, I can insert it in the second sentence above so that it looks like this:
"These AVPs are derived from the corresponding priority fields specified in the Signaled Preemption Priority Policy Element [RFC3181] of RSVP [RFC2205]."


> *******
> Section 3.3 SIP-RPH AVP
> 
> ==> "RPH" is not defined. If a new version is required, would it be
> simpler to have a explicit name such like "SIP-Resource-Priority"? The
> same comment may also apply for the other AVPs. We would have therefore
> SIP-Resource-Priority-Namespace and SIP-Resource-Priority-Value if
> agreed.

that's fine, I'll expand to name as you suggest.

> *******
> Section 3.3.1.  SIP-Namespace AVP
> 
>   The SIP-RPH-Namespace AVP (AVP Code TBD) is of type UTF8String.
> 
> ==> Inconsistency between name of the AVP in Title and the body.
> Previous comment maybe taken into account.

ok

> ******
> Section 3.4.  App-Level-Resource-Priority AVP
> 
>   The  App-Level-Resource-Priority  (ALRP)  AVP  is   a   grouped   AVP
>   consisting  of two AVPs, the ALRP-Namespace AVP and the ALRP-Priority
>   AVP.
> 
> ==> "App-Level-Resource-Priority" may also be
> "Application-Level-Resource-Priority" as in
> I-D.ietf-tsvwg-emergency-rsvp.

ok

> ==> to ease the mapping with I-D.ietf-tsvwg-emergency-rsvp, the second
> AVP in the grouped AVP should be renamed "ALRP-Value AVP", as the name
> of the field is Application-Level Resource Priority policy element.

ok

> ******
> Section 5.  Security Considerations
> 
>     TBD
> 
> ==> Is there any ongoing discussion on this topic. If there is no
> specific security issue with the introduction of this set of AVP, maybe
> a text like in RFC 5777 would be good enough
> (http://tools.ietf.org/html/rfc5777#section-11):
> 
> 
>   "This document describes the extension of Diameter for conveying
>   Quality of Service information.  The security considerations of the
>   Diameter protocol itself have been discussed in RFC 3588 [RFC3588].
>   Use of the AVPs defined in this document MUST take into consideration
>   the security issues and requirements of the Diameter base protocol."

Sounds fine, I'll add it in.  
Thanks again for your comments.

-ken