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

[ken carlberg <[e-mail]>]

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