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

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 : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de Romascanu, Dan (Dan)
Envoyé : mercredi 29 juin 2011 10:16
À : ken carlberg
Cc : dime@ietf.org
Objet : Re: [Dime] AD review of draft-ietf-dime-priority-avps-03.txt

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:carlberg@g11.org.uk]
> Sent: Tuesday, June 28, 2011 10:51 PM
> To: Romascanu, Dan (Dan)
> Cc: dime@ietf.org
> Subject: Re: [Dime] AD review of draft-ietf-dime-priority-avps-03.txt
> 
> 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

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime