Cisco Vendor-Specific RADIUS Attributes for the Delivery of Keying Material
draft-zorn-radius-keywrap-18

IANA Evaluation Comments:

IANA has a question about this document.

The IANA understands that, upon approval of this
document, IANA will take the following actions:

In the Radius Types registry located at -
http://www.iana.org/assignments/radius-types

three new RADIUS Attribute Types will be registered:

VALUE DESCRIPTION
------ -----------
tbd Keying-Material
tbd MAC-Randomizer
tbd Message-Authentication-Code

However, it appears that a registry may be needed
for the:

- Enc Type field of the Keying-Material attribute;
- MAC Type field of the Message-Authentication-Code
  attribute; and,
- App ID field of the Keying-Material attribute.

Section 3.1 establishes a single value for the Enc Type
field of the Keying-Material attribute. Section 3.1 also
establishes two values for the App ID field of the
Keying-Material attribute. Section 3.3 establishes six
values for the MAC Type field of the Message-Authentication-Code attribute.

The IANA would like to know if registries should be created
for these three attributes?

[Ballot discuss]
The following input was received from AAA Doctor Bernard Aboba. I believe the points he is raising are correct. The solution seems to be not to approve the document and ask that it's re-submitted as AD-sponsored to allow for proper community review.

---------

I do not think this document is eligible for publication as an Independent Submission, since it requests IANA to allocate parameters (RADIUS
attributes) that require "IETF Consensus" under RFC 3575.  RFC 2434 defines IETF consensus as follows:

          IETF Consensus - New values are assigned through the IETF
          consensus process. Specifically, new assignments are made via
          RFCs approved by the IESG. Typically, the IESG will seek
          input on prospective assignments from appropriate persons
          (e.g., a relevant Working Group if one exists).

Therefore I do not believe that this document can be published without at least going through IETF last call.

In addition, the document updates a Draft Track RFC (RFC 2865).

-------------

[Ballot discuss]
The following input was received from AAA Doctor Bernard Aboba. I believe the points he is raising are correct. The solution seems to be not to approve the document and ask that it's re-submitted as AD-sponsored to allow for proper community review.

---------

I do not think this document is eligible for publication as an Independent Submission, since it requests IANA to allocate parameters (RADIUS
attributes) that require "IETF Consensus" under RFC 3575.  RFC 2434 defines IETF consensus as follows:

          IETF Consensus - New values are assigned through the IETF
          consensus process. Specifically, new assignments are made via
          RFCs approved by the IESG. Typically, the IESG will seek
          input on prospective assignments from appropriate persons
          (e.g., a relevant Working Group if one exists).

Therefore I do not believe that this document can be published without at least going through IETF last call.

In addition, the document updates a Draft Track RFC (RFC 2865).

-------------

[Ballot discuss]
I am unclear how this document can come to the IESG via the RFC Editor
  since it updates standards track documents.  I believe that such a
  document must be sponsored by an AD and it must go through IETF Last
  Call.  Thus, I believe we need to ask the RFC Editor to not publish
  this document.