Subject: [radext] Last Call: <draft-ietf-radext-datatypes-06.txt> (Data Types in the Remote Authentication Dial-In User Service Protocol (RADIUS)) to Proposed Standard

From: The IESG <[email-masked]>
Date: Wed, 03 Aug 2016 11:03:45 -0700

The IESG has received a request from the RADIUS EXTensions WG (radext) to
consider the following document:
- 'Data Types in the Remote Authentication Dial-In User Service Protocol
   (RADIUS)'
  <draft-ietf-radext-datatypes-06.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2016-08-17. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   RADIUS specifications have used data types for two decades without
   defining them as managed entities.  During this time, RADIUS
   implementations have named the data types, and have used them in
   attribute definitions.  This document updates the specifications to
   better follow established practice.  We do this by naming the data
   types defined in RFC 6158, which have been used since at least RFC
   2865.  We provide an IANA registry for the data types, and update the
   RADIUS Attribute Type registry to include a "Data Type" field for
   each attribute.  Finally, we recommend that authors of RADIUS
   specifications use these types in preference to existing practice.
   This document updates RFC 2865, 3162, 6158, and 6572.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-radext-datatypes/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-radext-datatypes/ballot/

No IPR declarations have been submitted directly on this I-D.

The document contains these normative downward references.
See RFC 3967 for additional information: 
    rfc3576: Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS) (Informational - Independent Submission Editor stream)
    rfc5904: RADIUS Attributes for IEEE 802.16 Privacy Key Management Version 1 (PKMv1) Protocol Support (Informational - IETF stream)
    rfc2866: RADIUS Accounting (Informational - IETF stream)
    rfc2867: RADIUS Accounting Modifications for Tunnel Protocol Support (Informational - IETF stream)
Note that some of these references may already be listed in the acceptable Downref Registry.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 18 Aug 2016 10:42:28 +0200

> First, IANA understands that it is to create a new registry called the
> RADIUS Data Type registry. the registration procedure for the new
> registry is to be Standards Action as defined in RFC5226. There are
> three fields in the new registry: Value, Description and Reference.

  Yes.

> IANA QUESTION -> Where should this new registry be located? Is it a new
> registry on the List of all IANA maintained protocol parameter
> registries or is it a subregistry of an existing registry? If it is a
> subregistry of an existing registry, in which registry will it be contained?

  It should be a sub registry of "RADIUS Types".  I will update the draft accordingly.

> Second, the RADIUS Attribute Type subregistry of the Radius Types
> registry located at:
> 
> https://www.iana.org/assignments/radius-types/
> 
> is to be updated. IANA understands that the registration rules for the
> registry are to remain unchanged. A new column is to be inserted between
> the existing "Description" and "Reference" column and titled: "Data Type."

  Yes to all.

> Section 4.2 of the current draft provides a listing of a recent version
> of the registry with the Data Type field inserted. That listing is in
> CSV format.
> 
> IANA Question --> How would the authors like to fill the Data Type
> column for those registrations in the current RADIUS Attribute Type
> registry that are not included in Section 4.2 of the current document?

  I will update this document with any new data types required.  I hope that there are only a small number of new RADIUS Attribute Types registered...

  My suggestion is that I will update the document in AUTH48, and coordinate with IANA to ensure that all RADIUS Attribute Types have a defined data type, prior to publication of this document.

  Hmm... Section 2.1.1 notes that new definitions in the RADIUS Attribute Type MUST specify a data type, but the IANA actions don't have similar text.  I'll fix that by adding some text:

IANA is instructed to require that new allocations in the RADIUS
Attribute Type registry specify a "Data Type" which references one of the
data types defined in the RADIUS Data Type registry.

  I think that should be sufficient.

> IANA understands that the two actions above are the only ones required
> to be completed upon approval of this document.
> 
> Note:  The actions requested in this document will not be completed
> until the document has been approved for publication as an RFC. This
> message is only to confirm what actions will be performed.
> Thank you,
> 
> Sabrina Tanamal
> IANA Specialist
> ICANN
> 
> (END IANA COMMENTS)
> 
> <0x8A39DC66.asc>