Remote Authentication Dial In User Service (RADIUS) Protocol Extensions
draft-ietf-radext-radius-extensions-13

[Ballot comment]
RECOMMENDED is an alias for SHOULD. When you say "Discretion is RECOMMENDED when requesting allocation of attributes." you are saying that requests SHOULD show discretion. When would it be ok to _not_ show that discretion. I suggest rewriting this as guidance to authors and not use the 2119 keyword.

[Ballot comment]
2.1, 2.2, 3.1-3.6:

      The Value field is one or more octets.  Implementations not
      supporting this specification SHOULD support the field as
      undistinguished octets.

So are you really expecting implementations not to support this specification but still make changes to treat these fields as undistinguished octets? If so, then I'd reword to:

      The Value field is one or more octets. An implementation that
      does not fully implement the remainder of specification SHOULD
      still treat the field as undistinguished octets.

Or did you mean by "SHOULD support" that "we believe they should be able to support"? It's just a strange sentence.
 
6.4:

  * The "integer64" data type MAY be used in any RADIUS attribute.
    The use of 64-bit integers is NOT RECOMMENDED by [RFC6158], but
    their utility is now evident.

I would avoid the use of NOT RECOMMENDED in there; it is potentially confusing. 6158 said it was not recommended, but you are now changing that requirement.
   
6.6:

There are assorted silly uses of 2119 language throughout the document, and I wish you would go through and review them to make sure they meet the requirements of 2119. That said, this one was especially silly:

  * Discretion is RECOMMENDED when requesting allocation of attributes.
    The new space is much larger than the old one, but it is not
    infinite.

A requirement on discretion seems a bit overdone.

[Ballot comment]
- p9, typo, missing "with" in 2nd last para, should say
"compatible with RADIUS"

- p15, suggest s/Use of non-standard data types SHOULD NOT be
done./Non-standard data types SHOULD NOT be used within TLVs./

- p16, saying multiple TLVs are "a set or list of values" is
maybe a bit misleading, e.g. ASN.1 SETs are unordered lists
whereas SEQUENCE OF are ordered. I don't care which you want or
if you don't want to pick, but saying what you do mean about
ordering would be good.

- p17, I wondered is String values are allowed to be or are
typically null terminated or not.

- p22, seems odd to me that a TLV can contain an invalid
attribute, but itself not be invalid. But I guess you have
reasons. That does seem to create meaningful attributes inside
TLVs with e.g. zero length, so I'm surprised you don't say that
that is now allowed.

- p54, I wondered why you didn't include references to RFC 6614
and 6151 where you talk about MD5 weakness. I think both would
be useful.

[Ballot comment]
I had an excellent set of exchanges with Alan Dekok, in which he sorted out all my issues (reflected in the -11) version.  There remain a couple of minor things we disagree on, but that will happen, and they are minor.  Thanks very much to Alan for the quick turnaround and good work.

Barry found some serious issues regarding this draft.
In other words, it doesn't make sense for the entire IESG to spend his time on this document.
Therefore, I will remove it from the call.
Barry and I will work with the authors.

IANA has reviewed draft-ietf-radext-radius-extensions-08 and has the following comments:

IANA has questions about the management of the new Extended TLV types
and The value zero "TYPE.0".

IANA understands that, upon approval of this document, the RADIUS Attribute Type registry is significantly changed. IANA understands that there are three major actions to be taken.

The Radius Attribute Type registry is in the Radius Types registry located at:

http://www.iana.org/assignments/radius-types/radius-types.xml#radius-types-1

The current RADIUS Attribute Type registry established by RFC3575 records only a value, Description and Reference for each RADIUS type. The range of acceptable values for RFC3575 RADIUS types is 1-255.

First, IANA is will move the following Attribute Type values from "Reserved", to "Allocated", with the corresponding names and References:

Value: 241
Description: Extended-Type-1
Reference: [ RFC-to-be ]

Value: 242
Description: Extended-Type-2
Reference: [ RFC-to-be ]

Value: 243
Description: Extended-Type-3
Reference: [ RFC-to-be ]

Value: 244
Description: Extended-Type-4
Reference: [ RFC-to-be ]

Value: 245
Description: Long-Extended-Type-1
Reference: [ RFC-to-be ]

Value: 246
Description: Long-Extended-Type-2
Reference: [ RFC-to-be ]

Second, IANA will create a tree-structured sub-registry for RADIUS Attribute types with values 241-246.

Allocation of an Attribute Type value for the RADIUS Attribute Types 241-246 using the new Extended type format results in allocation of 255 new Attribute Type values, of format "TYPE.1" through "TYPE.255".

The value zero "TYPE.0" is not used.

Value twenty-six (26) for each one of the Extended type formats is assigned as "Extended-Vendor-Specific-*". These values are for private use.

Values "TYPE.241" through "TYPE.255" for each one of the Extended type formats are marked "Reserved". All other values are "Unassigned" and are available for future assignment.

Allocation of new Extended types among the Reserved entries in the extended space requires Standards Action as defined by RFC5226.

All other allocations in the extended space require IETF Review as defined by RFC5226.

The initial set of Attribute Type values and names assigned by this document is given below (in each case the Reference is to be [ RFC-to-be ]).

* 241 Extended-Attribute-1
* 241.{1-25} Unassigned
* 241.26 Extended-Vendor-Specific-1
* 241.{27-240} Unassigned
* 241.{241-255} Reserved
* 242 Extended-Attribute-2
* 242.{1-25} Unassigned
* 242.26 Extended-Vendor-Specific-2
* 242.{27-240} Unassigned
* 243 Extended-Attribute-3
* 242.{241-255} Reserved
* 243.{1-25} Unassigned
* 243.26 Extended-Vendor-Specific-3
* 243.{27-240} Unassigned
* 243.{241-255} Reserved
* 244 Extended-Attribute-4
* 244.{1-25} Unassigned
* 244.26 Extended-Vendor-Specific-4
* 244.{27-240} Unassigned
* 244.{241-255} Reserved
* 245 Extended-Attribute-5
* 245.{1-25} Unassigned
* 245.26 Extended-Vendor-Specific-5
* 245.{27-240} Unassigned
* 245.{241-255} Reserved
* 246 Extended-Attribute-6
* 246.{1-25} Unassigned
* 245.26 Extended-Vendor-Specific-6
* 246.{27-240} Unassigned
* 246.{241-255} Reserved

Question->The document said that "TYPE.0" is "not used." Can authors
please confirm if the value zero "TYPE.0" should be marked "Reserved"
as per this document in the registry? If "not used" should be used,
please reply to indicate that.

Third, the current document has allocation instructions to IANA for the new Extended Type format for RADIUS Attribute Types. IANA notes these allocation instructions and will document them in the new, Extended Type registry.

Question->Is ICANN required to manage the Extended TLV Types?
And if so, what are the registration procedures? Is section 10.3.4
applied to these Extended Types What information is required to
allocate a new Extended TLV? "Attribute Type value", "Name" and
"Reference"?

IANA understands that these three actions are the only actions that
are required to be completed by IANA 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.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: UPDATED Last Call:  (Remote Authentication Dial In User Service (RADIUS) Protocol Extensions) to Proposed Standard


The IESG has received a request from the RADIUS EXTensions WG (radext) to
consider the following document:
- 'Remote Authentication Dial In User Service (RADIUS) Protocol
  Extensions'
  as Proposed Standard

Note that this document is Standards Track and has normative references
to two Informational documents, RFCs 2866 and 5176.
See http://www.ietf.org/mail-archive/web/radext/current/msg07979.html
for some history on those two RFCs.

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
ietf@ietf.org mailing lists by 2013-01-25. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The Remote Authentication Dial In User Service (RADIUS) protocol is
  nearing exhaustion of its current 8-bit Attribute Type space.  In
  addition, experience shows a growing need for complex grouping, along
  with attributes which can carry more than 253 octets of data.  This
  document defines changes to RADIUS which address all of the above
  problems.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-radext-radius-extensions/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-radext-radius-extensions/ballot/


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

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Remote Authentication Dial In User Service (RADIUS) Protocol Extensions) to Proposed Standard


The IESG has received a request from the RADIUS EXTensions WG (radext) to
consider the following document:
- 'Remote Authentication Dial In User Service (RADIUS) Protocol
  Extensions'
  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
ietf@ietf.org mailing lists by 2013-01-18. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The Remote Authentication Dial In User Service (RADIUS) protocol is
  nearing exhaustion of its current 8-bit Attribute Type space.  In
  addition, experience shows a growing need for complex grouping, along
  with attributes which can carry more than 253 octets of data.  This
  document defines changes to RADIUS which address all of the above
  problems.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-radext-radius-extensions/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-radext-radius-extensions/ballot/


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

Technical Summary:

  draft-ietf-radext-radius-extensions-06 will be a Proposed Standard. The
  I-D adds substantial features to RADIUS protocol that are essential for
  the future of RADIUS and to meet the market demand. These new features
  extend, among other features, the standard attribute type space beyond
  the existing maximum limit of 256. Another remarkable area of
  improvement is the set of generic RADIUS attribute extension including
  long attributes with a value length greater than the current maximum of
  253 octets and standard way of encoding type-length-values with possible
  nesting for creating grouped type attributes.

Working Group Summary:

  Working group spent considerable long time on this document. The
  technical content and selected solutions have been extensively
  discussed in the WG. One of the technical points that faced long
  technical discussion related to concatenation of multiple attributes
  into a one long attribute. The current solution in the I-D reflects
  the WG consensus.

Document Quality:

  There are multiple implementations already available. Also given the
  current I-D is the second incarnation of the design, we can say the
  described solution is mature. For the future support and implementations
  of RADIUS there is no much choice than implement the I-D since current
  RADIUS attribute type space has almost been exhausted.

  AAA Doctors have not reviewed the document yet. There is no need for MIB
  or other doctorate review.

Personnel:

  Jouni Korhonen (jouni.nospam@gmail.com) is the document shepherd.
  Benoit Claise is the responsible AD.


(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

  The document shepherd has reviewed the document after it has concluded the
  WGLC. The document shepherd thinks the document is ready for publication and
  there is no reason to delay the publication anymore, since the solutions
  defined in this document are needed by the industry. The remaining non-technical
  editorial nits can be handled in subsequent revisions of the I-D during the
  publication process.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

  No.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

  The document should be reviewed by AAA Directorate once it goes to IETF LC.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

  The document shepherd has no specific concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

  No IPRs have been declared.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

  No IPRs have been declared.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

  The WG consensus is solid and does not represent only the opinion of
  few individuals.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

  No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

  The ID nits reports three warnings, which all are either bogus or due to
  lack of "NOT RECOMMENDED" in the standard RFC2119 text provided by the
  xml2rfc template.

  The ID nits reports multiple comments on the document abstract (lack of
  "updates RFC xyz" text) but these can be included latest during the document
  edit time.

  Other than the above, the document passes ID nits.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

  The document does not define MIBs, media types, URIs etc.

(13) Have all references within this document been identified as either normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

  No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

  No. however, RFC5226 (BCP) is currently listed as a Normative Reference and
  it is typically been listed as an Informative Reference.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

  Yes. RFCs 2865, 2866, 3575, 5176, 6158 will be updated. These RFCs listed in
  the title page header but not in the abstract or in the introduction. The
  most important updates RFC3575 and RFC6158 are discussed in the main text.

  The missing abstract text is plain editorial and can be added if seen
  necessary.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

  The IANA section is clear and extensive regarding to the new allocation practices.

  The I-D allocates six attributes for the extended types and long extended types.
  Initial assignment for the new style extended attributes is also done. The
  IANA considerations also give detailed instructions how the allocations are to
  be done from the extended type space.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

  There are no new registries per se. However, the I-D describes clearly how
  the new style dotted attribute type tree is to be constructed. It is up to
  IANA to decide how the dotted attribute type tree is arranged in the
  existing RADIUS registry i.e., whether they are placed separately or
  part of the existing Radius Attribute Types registry.

  The existing IANA experts are recommended but they need to get familiar
  with the new style of type tree layout.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

  Checked with ID nits.  There are no additional concerns.