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

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 1 Jun 2011 15:35:21 +0200

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. 

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? 

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? 

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. 

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?

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. 

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. 

Thanks and Regards,

Dan

---

From: ken carlberg <[email-masked]>
Date: Tue, 28 Jun 2011 15:50:44 -0400

Hi Dan,

I'm terribly sorry for the tardy response!

> rather than 3588 - as soon (hopefully) 3588 will be obsoleted. 

ok, will do.

> 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. 

>   UTF8String. This AVP contains a string that identifies a unique ordered

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].

> defined in sections 12.1 and 12.2. The text in the I-D should reflect

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

> 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.

> 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.  

> maximum (72) allowed length of a row. 

understood.  And thanks again for the review.

-ken

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 29 Jun 2011 10:16:27 +0200

Hi Ken, 

Thank you for the answer. It looks like we agree on all items with the
exception of T6. I still hold the opinion that as values carried in the
DIME fileds are being defined in other RFCs, the references to the
security considerations sections of these RFCs are appropriate, but I
will not block the document on this. Please go ahead and issue a revised
ID with the changes, so that we can send the document to IETF LC. 

Regards,

Dan 

> -----Original Message-----
> From: ken carlberg [mailto:[email-masked]]
> Sent: Tuesday, June 28, 2011 10:51 PM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]
> Subject: Re: [Dime] AD review of draft-ietf-dime-priority-avps-03.txt
> 
> Hi Dan,
> 
> > Technical comments are marked by T, and Editorial comments are
marked
> by
> 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.
> 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:
> 
> 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
> same as above.  I'll change the AVPs to 16 bits and 8 bits
> respectively, instead of the type unsigned32.
> 
> 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.
>

---

From: <[email-masked]>
Date: Wed, 29 Jun 2011 10:42:36 +0200

Hi Dan, Ken,

I tend to agree with Ken. From the Diameter protocol point of view, there is no additional issue. For the use of the priority parameters, there are already references to the related specifications. From E2E point of view, I think that the security aspects are covered with all the specifications.
Anyway, from the reader point of view, it may not harm to find a reference to the corresponding documents in our security consideration section, at least for information.

Lionel

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Romascanu, Dan (Dan)
Envoyé : mercredi 29 juin 2011 10:16
À : ken carlberg
Cc : [email-masked]
Objet : Re: [Dime] AD review of draft-ietf-dime-priority-avps-03.txt

Hi Ken, 

Regards,

Dan 

marked
think
preemption-priority
some
rfc-
a
> understood.  And thanks again for the review.

_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: ken carlberg <[email-masked]>
Date: Thu, 30 Jun 2011 09:17:10 -0400

ok, I'll issue another version within the next day or so with the changes agreed upon.  And I'll see if there is some general wording I can use to point the reader to other security considerations to keep in mind.

-ken