Subject: [Dime] Some minor comments on the rfc3588bis draft

From: Jari Arkko <[email-masked]>
Date: Fri, 29 Feb 2008 15:56:53 +0200

The draft should have an "Obsoletes: 3588 (if approved)" header at the
top. Add the appropriate XML2RFC attribute to do that (obsoletes="3588").

> This document deprecates [RFC3588 <http://tools.ietf.org/html/rfc3588>] but is fully backward compatible
>    with that document. 
Obsoletes, not deprecates.

>    In order to allocate a new AVP value for a standards track AVP, a
>    request MUST be sent to IANA [RFC2434], along with an explanation of
>    the new AVP value.  IANA considerations for AVP values are discussed
>    in Section 11.4.

This is not completely correct. IANA records the registrations, but
since the spaces have been defined to be registered via IETF Consensus,
you cannot simply go to IANA and ask for a value. You need to write an
RFC and get it approved via a WG or AD sponsoring. Suggested text:

  ... track AVP, the IETF needs to approve a new RFC that describes the
AVP value. IANA considerations ...

This section does not describe how to allocate values in other AVPs. Are
there informational IETF Diameter AVPs? But there surely are vendor
specific AVPs. I would suggest a reformulation of the entire paragraph
as follows:

   In order to allocate a new AVP value for AVPs defined in the Diameter
Base
   protocol, the IETF needs to approve a new RFC that describes the AVP
value.
   IANA considerations for these AVP values are discussed in Section 11.4.

   The allocation of AVP values for other AVPs is guided by the IANA
considerations
   of the documents that defines those AVPs. Typically, allocation of
new values
   for an AVP defined in an IETF RFC should require IETF Review [2434bis],
   where as values for vendor-specific AVPs can be allocated by the vendor.

Also, I would suggest switching to
draft-narten-iana-considerations-rfc2434bis terminology rather than RFC
2434. It uses "IETF Review" instead of "IETF Consensus".

>    In order to create a new standards track AVP, a request MUST be sent
>    to IANA with a reference to the specification that defines the AVP.
>    IANA considerations for AVPs are discussed in Section 11.1.1.

This has similar issues as from above. Again, the IANA considerations
section is actually more informative than this. There are different
cases, >3 attributes, <3 attributes, what kind of spec you are writing
(ps/inf/otherrfc/othersdo), etc. I would rewrite the above as:

The creation of new AVPs can happen in various ways. The recommended
approach is to define a new general-purpose AVP in a standards track RFC
approved by the IETF. However, as described in Section 11.1.1 there are
also other mechanisms.

>    An implementation MAY add arbitrary non-mandatory AVPs to a command
>    defined in an application, including vendor-specific AVPs without
>    needing to define a new application.  This can be done if the
>    commands ABNF allows for it. 

I am not happy with the last statement. There are some commands which do
not allow any AVP to appear at the end, but I think that is a mistake
and we should fix that bug. If you look at the RADIUS developments, the
ability to add new attributes has been extremely useful.

Jari

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

---

From: Victor Fajardo <[email-masked]>
Date: Fri, 29 Feb 2008 10:24:41 -0500

Hi Jari,

> Obsoletes, not deprecates.

Ok

>    where as values for vendor-specific AVPs can be allocated by the vendor.

This make sense.

> approved by the IETF. However, as described in Section 11.1.1 there are

Ok.

> ability to add new attributes has been extremely useful.

Just to clarify, are we suggesting that we make "* [AVP]" implicit on 
any/all commands ?

regards,
victor

---

From: Jari Arkko <[email-masked]>
Date: Fri, 29 Feb 2008 18:40:51 +0200

Victor,

> Just to clarify, are we suggesting that we make "* [AVP]" implicit on

Just recommend that this be in the ABNF of all commands. And fix the
commands that don't have this right now, DPR, DPA, DWR, and DWA.
Obviously, I don't think we are going to extend these commands but I
think this is a good policy to have.

Jari

---

From: Victor Fajardo <[email-masked]>
Date: Fri, 29 Feb 2008 12:08:00 -0500

Hi Jari,
> think this is a good policy to have.

I see. sounds reasonable.

regards,
victor

---

From: <[email-masked]>
Date: Fri, 29 Feb 2008 18:12:39 +0100

> >>> I am not happy with the last statement. There are some commands 
> >>> which do not allow any AVP to appear at the end, but I 
> think that is 
> >>> a mistake and we should fix that bug. If you look at the RADIUS 
> >>> developments, the ability to add new attributes has been 
> extremely useful.
> >>>   
> >>>       

I agree.

Lionel

---

From: Mark Jones <[email-masked]>
Date: Fri, 29 Feb 2008 13:59:16 -0500

Hi Jari, Victor,

Comments inline...

> think this is a good policy to have.

I agree. Why not extend this recommendation to Grouped AVPs for the same reason?

Regards
Mark