Subject: [AAA-WG]: Issue 370: Diameter IANA Considerations Issues

From: Bernard Aboba <[email-masked]>
Date: Sat, 5 Oct 2002 10:06:53 -0700 (PDT)

Issue 370: IANA considerations issues
Submitter name: Scott Bradner
Submitter email address: [email-masked]
Date first submitted: October 5, 2002
Reference:
Document: Base
Comment type: T
Priority: S
Section: 11
Rationale/Explanation of issue

This issue covers IESG concerns about Diameter IANA considerations.

Date: Sat, 5 Oct 2002 12:53:38 -0400 (EDT)
From: Scott Bradner <[email-masked]>
Subject: Diameter IANA Considerations Issues

I do not like ad-hoc assignments if that can lead to non-interoperable
implementations so I like to require at least a public specification.

I'd rather that the public spec be an RFC so that there is some
additional sanity check when the IESG takes a pre-publication look
but a Designated Expert is not too bad.

one nit on the IPS wording - it does not require that a reject notice
comes along with a reason and, where possible, suggestions on
how to make the request acceptable.

Scott

Proposed changes to deal with this concern:

Section 11:

Change:
"   Diameter is not intended as a general purpose protocol, and
   allocations SHOULD NOT be made for purposes unrelated to
   authentication, authorization or accounting. For registration
   requests where a Designated Expert should be consulted, the
   responsible IESG area director should appoint the Designated Expert.

   For registration requests requiring Expert Review, the AAA mailing
   list should be consulted.  For registration requests requiring Expert
   Review, the AAA mailing list should be consulted; if the AAA WG is
   disbanded, and the mailing list is no longer available, then the Area
   Director may appoint a Designated Expert."

To:

   "Diameter is not intended as a general purpose protocol, and
   allocations SHOULD NOT be made for purposes unrelated to
   authentication, authorization or accounting.

   For registration requests where a Designated Expert should be
   consulted, the responsible IESG area director should appoint the
   Designated Expert. For Designated Expert with Specification Required,
   the request is posted to the AAA WG mailing list (or, if it has been
   disbanded, a successor designated by the Area Director) for comment
   and review, and MUST include a point to a public specification. After a
   period of 30 days has passed, the Designated Expert will either approve
   or deny the registration request. A denial notice must be justified by
   an explanation and, in the cases where it is possible, concrete
   suggestions on how the request can be modified so as to become
   acceptable."

Section 11.1.1

Change:

" The AVP Code namespace is used to identify attributes. When the
Vendor ID value is set to zero (0), IANA will maintain a registry of
assigned AVP codes and in some cases also their values. AVP Codes
0-254 are managed separtely as RADIUS Attribute Types [RADTYPE],
while the remaining namespace is available for assignmetn via Expert
Review with Specification Required [IANA].

Vendor-Specific AVP Codes, where the Vendor-Id field in the AVP
header is set to a non-zero value, are for Private Use.

This document defines the AVP Codes 257-274, 276-285, 287, 291-299,
480, 483 and 485-486. See section 4.6 for the assignment of the
namespace in this specification."

To:

" The AVP Code namespace is used to identify attributes. When the
Vendor ID value is set to zero (0), IANA will maintain a registry of
assigned AVP codes and in some cases also their values.

AVP Codes 0-254 are managed separately as RADIUS Attribute Types
[RADTYPE]. This document defines the AVP Codes 257-274, 276-285, 287,
291-299, 480, 483 and 485-486. See section 4.6 for the assignment of the
namespace in this specification.

AVPs may be allocated following Designated Expert with Specification
Required [IANA]. Release of blocks of AVPs (more than 3 at a time
for a given purpose) should require IETF Consensus.

Note that Diameter defines a mechanism for Vendor-Specific AVPs, where
the Vendor-Id field in the AVP header is set to a non-zero value.
Vendor-Specific AVPs codes are for Private Use and should be encouraged
instead of allocation of global attribute types, for functions specific
only to one vendor's implementation of Diameter, where no interoperability
is deemed useful."

Section 11.4 - 11.9, 11.11 - 11.16

I'd suggest that these sections be put under a single section entitled
"AVP values". As part of this, we need a general policy for AVP values,
other than the ones specified. In RADIUS this is first come first served.
Here is suggested text for Diameter:

11.3

Change:

   "Assignment of standards-track application IDs are by Expert Review
   with Specification Required [IANA]."

To:

"   Assignment of standards-track application IDs are by Designated Expert
   with Specification Required [IANA]."

11.4 AVP Values

Certain AVPs in Diameter define a list of values with various meanings.
For attributes other than those specified in this section, addition of
values can be done on a First Come, First Served basis by the IANA.

---

From: "Glen Zorn" <[email-masked]>
Date: Sat, 5 Oct 2002 12:30:57 -0700

Bernard Aboba [mailto:[email-masked]] writes:

Just a couple of comments.

...

>    or deny the registration request.

This does not appear to put a time limit on the approve/deny decision.
Suggestion: change "After a
period of 30 days has passed, the Designated Expert will either approve or
deny the registration request." to "Before a period of 30 days has passed,
the Designated Expert will either approve or deny the registration request
and publish a notice of the decision."

>    A denial notice must be justified by

This begs the obvious question of _who_ 'deems interoperability useful'.  An
example can be found in the vendor-specific RADIUS attributes defined in
section 2.4 of RFC 2548: the IESG has not deemed these attributes useful
enough for standardization, but many vendors apparently disaggree.  I
suggest that the text be modified to reflect the requirement for standard
allocation if a Vendor-Specific AVP is implemented by more than one vendor.

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 5 Oct 2002 11:43:25 -0700 (PDT)

> and publish a notice of the decision."

Done.

> allocation if a Vendor-Specific AVP is implemented by more than one vendor.

How about this?

"Note that Diameter defines a mechanism for Vendor-Specific AVPs, where
the Vendor-Id field in the AVP header is set to a non-zero value.
Vendor-Specific AVPs codes are for Private Use and should be encouraged
instead of allocation of global attribute types, for functions specific
only to one vendor's implementation of Diameter, where no interoperability
is deemed useful. Where a Vendor-Specific AVP is implemented by more than
one vendor, use of a standard AVP is recommended."

---

From: Randy Bush <[email-masked]>
Date: Sat, 05 Oct 2002 15:55:03 -0700

>> and publish a notice of the decision."

the designated expert advises the iana function.  i suspect we do not wish
to imbue the role with formal process.  iana should announce any decision
it makes.

>> This begs the obvious question of _who_ 'deems interoperability useful'.
>> An example can be found in the vendor-specific RADIUS attributes defined
>> in section 2.4 of RFC 2548: the IESG has not deemed these attributes
>> useful enough for standardization, but many vendors apparently disaggree.
>> I suggest that the text be modified to reflect the requirement for
>> standard allocation if a Vendor-Specific AVP is implemented by more than
>> one vendor.
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
standard AVP documentation and process should be used instead.

randy

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 5 Oct 2002 18:49:48 -0700 (PDT)

Done.

---

From: Jari Arkko <[email-masked]>
Date: Sun, 06 Oct 2002 11:17:03 +0300

And then Bernard changed the wording to:

> one vendor, standard AVP documentation and process should be used instead."

Now, let's see what would have happened if this text had been applied
to RADIUS at time of RFC 2548. Obviously, the IESG would still have had
the same opinion. Since there were many vendors who actually did use
the Microsoft VSAs, the text above would have dictated *standard* AVP
documention and process. Conclusion: there would not have been a
standard RFC (IESG blocks it) and Microsoft could not have published
their document in IETF, because the text dictates a standard process.
Glen, did you really ask for this?!

But note that the text in the first part of the AVP allocation rules

 > for a given purpose) should require IETF Consensus.

So my suggestion is that if multiple vendors implement an AVP, this
shouldn't be changed to Standards Action! So, my suggestion is to
change Bernard's wording to the following:

   "Note that Diameter defines a mechanism for Vendor-Specific AVPs, where
   the Vendor-Id field in the AVP header is set to a non-zero value.
   Vendor-Specific AVPs codes are for Private Use and should be encouraged
   instead of allocation of global attribute types, for functions specific
   only to one vendor's implementation of Diameter, where no interoperability
   is deemed useful. Where an AVP is implemented by more than one vendor,
   an allocation of global attribute types should be encouraged instead."

Jari

---

From: "Subrata Goswami" <[email-masked]>
Date: Wed, 9 Oct 2002 08:40:37 -0700

The following AVP's appear to be redundant in the AMR as they 
appear to be  all ready contained in { MIP-Reg-Request }.

{ Origin-Host }
{ MIP-MN-AAA-Auth }
[ Destination-Host ]
[ MIP-Mobile-Node-Address ]
[ MIP-Home-Agent-Address ]

      <AA-Mobile-Node-Request> ::= < Diameter Header: 260, REQ, PXY >
                                   < Session-ID >
                                   { Auth-Application-Id }
                                   { User-Name }
                                   { Destination-Realm }
                                   { Origin-Host }
                                   { Origin-Realm }
                                   { MIP-Reg-Request }
                                   { MIP-MN-AAA-Auth }
                                   [ Acct-Multi-Session-Id ]
                                   [ Destination-Host ]
                                   [ Origin-State-Id ]
                                   [ MIP-Mobile-Node-Address ]
                                   [ MIP-Home-Agent-Address ]
                                   [ MIP-Feature-Vector ]
                                   [ MIP-Originating-Foreign-AAA ]
                                   [ Authorization-Lifetime ]
                                   [ Auth-Session-State ]
                                   [ MIP-FA-Challenge ]
                                   [ MIP-Candidate-Home-Agent-Host ]
                                 * [ Proxy-Info ]
                                 * [ Route-Record ]
                                 * [ AVP ]
Subrata

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Bernard Aboba
Sent: Saturday, October 05, 2002 10:07 AM
To: [email-masked]
Subject: [AAA-WG]: Issue 370: Diameter IANA Considerations Issues

Scott

Section 11:

Change:

To:

   For registration requests where a Designated Expert should be
   consulted, the responsible IESG area director should appoint the
   Designated Expert. For Designated Expert with Specification Required,
   the request is posted to the AAA WG mailing list (or, if it has been
   disbanded, a successor designated by the Area Director) for comment
   and review, and MUST include a point to a public specification. After
a
   period of 30 days has passed, the Designated Expert will either
approve
   or deny the registration request. A denial notice must be justified
by
   an explanation and, in the cases where it is possible, concrete
   suggestions on how the request can be modified so as to become
   acceptable."

Section 11.1.1

Change:

To:

only to one vendor's implementation of Diameter, where no
interoperability
is deemed useful."

I'd suggest that these sections be put under a single section entitled
"AVP values". As part of this, we need a general policy for AVP values,
other than the ones specified. In RADIUS this is first come first
served.
Here is suggested text for Diameter:

11.3

Change:

To:

"   Assignment of standards-track application IDs are by Designated
Expert
   with Specification Required [IANA]."

11.4 AVP Values

---

From: "Fredrik Johansson" <[email-masked]>
Date: Wed, 9 Oct 2002 17:45:21 +0200

the information might be redundant but the AVPs are put in the AMR since the
AAA-server doesn't know how to parse the MIP registration request.

/fredrik

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Subrata Goswami
> Sent: den 9 oktober 2002 17:41
> To: [email-masked]
> Subject: [AAA-WG]: Redundant AVP's ?
>
>
>