Re: [Dime] AD review of draft-ietf-dime-priority-avps-03.txt

[ken carlberg <[e-mail]>]

Hi Dan,

I'm terribly sorry for the tardy response!

> Hi, 
> 
> Please find below the AD review of draft-ietf-dime-priority-avps-03.txt.
> I would suggest that the issues raised in this review be clarified and
> the necessary edits performed in a revised I-D before progressing this
> document to IETF Last Call. 
> 
> Technical comments are marked by T, and Editorial comments are marked by
> an E. 
> 
> T1. I think that it's better to start using references to RFC 3588bis
> rather than 3588 - as soon (hopefully) 3588 will be obsoleted. 

ok, will do.

> T2. In RFC 3181 the Preemption Priority and Defending Priority fields
> are 16-bit unsigned while here the Preemption-Priority and
> Defending-Priority AVPs are Unsigned32. Also admission priority
> parameter defined in Section 5.1 of [I-D.ietf-tsvwg-emergency-rsvp] is 8
> bit while the Admission-Priority AVP is of type Unsigned32. Should not
> these limits be mentioned in the definitions in sections 3.1 and 3.2? 

The original intention was to provide some additional room for expansion for the defined AVP.  And you're correct, that given that line of thought, we should mention these limitations.  However, I think a cleaner approach will be just to properly align the fields.  So I'll change the AVP to that of a 16-bit unsigned for the preemption-priority AVP and the defending-priority AVP.  
And I'll also change the Admission-Priority AVP to an 8-bit unsigned. 

> T3. Section 3.3.1: 
> 
>   The SIP-Resource-Priority-Namespace AVP (AVP Code TBD) is of type
>   UTF8String. This AVP contains a string that identifies a unique ordered
>   set of priority values as described in [rfc4412].
> 
> Should not this AVP refer here to the priority namespace, rather than
> priority values? 

It actually does refer to the priority namespace by referring to it as a "string" identifying a  "unique ordered set".  Perhaps I can add some clarity by stating the following:

     The SIP-Resource-Priority-Namespace AVP (AVP Code TBD) 
     is of type UTF8String.  This AVP contains a string 
     (i.e., a Namespace entry) that identifies a set of 
     priority values unique to the Namespace.  Examples
     of Namespaces and corresponding sets of priorities
     are found in [rfc4412].

> T4. Section 3.3 - RFC 4412 allows for new namespaces and associated
> ordered value sets to be defined in the future extending the registries
> defined in sections 12.1 and 12.2. The text in the I-D should reflect
> this extensibility. 

you raise a good point.  But I would add that all the protocol fields associated with the AVPs defined in the document allow for additional values beyond what may have already been defined or registered.  So I think i should just make this generic statement earlier in the draft and not confine the extensibility to just those that pertaining to rfc-4412

> T5. In draft-ietf-tsvwg-emergency-rsvp-15.txt ALRP Namespace is codified
> in 16bits and ALRP Value is codified in 8 bits, while ALRP-Namespace AVP
> and ALRP-Value AVP are of type Unsigned32. Should not these limits be
> mentioned in the definitions in sections 3.4.1 and 3.4.2?

same as above.  I'll change the AVPs to 16 bits and 8 bits respectively, instead of the type unsigned32.

> T6. I think that the Security Considerations section should also refer
> to the security considerations in RFC 3181, RFC 4412, and
> draft-ietf-tsvwg-emergency-rsvp which refer to the fields defined in
> those documents that can be carried in the AVPs defined here. 

Here we have a bit of a disagreement.  The security sections in rfc-3181 and rfc-4412 pertain to the particular protocol of RSVP and SIP, respectively.  It seems a bit of a stretch to then fold a reference to them into the security section of this document since they don't have a direct applicability to the Diameter protocol.  

> E1. The document has no exact date - just the month is mentioned.
> 
> E2. Running idnits results in a number of warnings due to exceeding the
> maximum (72) allowed length of a row. 

understood.  And thanks again for the review.

-ken