RADIUS Delegated-IPv6-Prefix Attribute
draft-ietf-radext-delegated-prefix-05

[Ballot discuss]
Placeholder DISCUSS for IANA:

From: Yoshiko Chong via RT
Subject: [IANA #8783] RE: Last Call: 'RADIUS Delegated-IPv6-Prefix             
        Attribute' to Proposed Standard

The IANA has reviewed the following Internet-Draft which is in Last           
Call: draft-ietf-radext-delegated-prefix-01.txt, and has the following         
comments/questions                                                             
with regards to the publication of this document:                             
                                                                               
The document says: "IANA is requested to assign a Type value, TBD, for this   
attribute from the RADIUS Types registry." However, there are two separate     
RADIUS Types registries at: http://www.iana.org/assignments/radius-types       
                                                                               
Is the requested Type value a RADIUS Attribute Type or is it to be a RADIUS   
Packet Type?                                                                   
                                                                               
IANA Consideration section needs more detail.                                 
                                                                               
Thank you.                                                                     
                                                                               
Yoshiko Chong                                                                 
(on behalf of IANA)

[Ballot discuss]
The Abstract says: "This attribute is usable within either RADIUS
  or Diameter."  However, the Security Considerations only deal with
  RADIUS.  Please expand the Security Considerations to address both
  protocol environments.

[Ballot comment]
Similar considerations apply to this document that were raised
for the -vlan document. But Mark already has a discuss on the
section in question, so I'm not raising the issue again.

IANA Comments:

IANA is not okay.

The document says: "IANA is requested to assign a Type value, TBD, for this
attribute from the RADIUS Types registry." However, there are two separate
RADIUS Types registries at: http://www.iana.org/assignments/radius-types

Is the requested Type value a RADIUS Attribute Type or is it to be a RADIUS
Packet Type?

IANA Consideration Section needs more detailed information

[Ballot comment]
In addition to the sections noted by Dan and Mark, the Security considerations section appears to be specific to Radius.  If DIAMETER is also covered, it may need an update.

[Ballot discuss]
It's not clear to me what the text below is saying. Is there need for another document for Diameter? Is the definition already in [5] and/or [6]?

4.  Diameter Considerations

  A definition is needed for an identical attribute with the same Type
  value for Diameter [4].  The attribute should be available as part of
  the NASREQ application [5], as well as the Diameter EAP application
  [6].

[Ballot comment]
1. The Abstract Section says:

  This document defines a RADIUS (Remote Authentication Dial In User
  Service) attribute that carries an IPv6 prefix that is to be
  delegated to the user.  This attribute is usable within either RADIUS
  or Diameter.

while the Diameter Considerations sectin says:

  A definition is needed for an identical attribute with the same Type
  value for Diameter [4].  The attribute should be available as part of
  the NASREQ application [5], as well as the Diameter EAP application
  [6].

These seem to be slightly contradictory, and I suggest that the text clarifies whet ere there is a need to define something for Diameter as section 4 says, or the definition in this document applies for both as says the Abstract

2. Section 7 (Change Log) needs to be eventually taken out.

PROTO write-up:

Title:  RADIUS Delegated-IPv6-Prefix Attribute
I-D:
http://www.ietf.org/internet-drafts/draft-ietf-radext-delegated-prefix-01.txt

Status: Proposed Standard

Response to template:

1) Have the chairs personally reviewed this version of the ID and do
  they believe this ID is sufficiently baked to forward to the IESG
  for publication?

Yes.

2) Has the document had adequate review from both key WG members and
  key non-WG members? Do you have any concerns about the depth or
  breadth of the reviews that have been performed?

Yes. The ID has been through RADEXT WG last call.

3) Do you have concerns that the document needs more review from a
  particular (broader) perspective (e.g., security, operational
  complexity, someone familiar with AAA, etc.)?

No concerns.  The document has been reviewed by the RADEXT working group,
as well as members of the DHC WG.

4) Do you have any specific concerns/issues with this document that
  you believe the ADs and/or IESG should be aware of? For example,
  perhaps you are uncomfortable with certain parts of the document,
  or whether there really is a need for it, etc., but at the same
  time these issues have been discussed in the WG and the WG has
  indicated it wishes to advance the document anyway.

No.

5) 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?

There is consensus behind this document.  10 people reviewed the document
in WG last call.  Two issues, both editorial, were raised
(185 & 188).  The issues, available for inspection at
http://www.drizzle.com/~aboba/RADEXT/, were resolved in the -01
version of the document.

6) Has anyone threatened an appeal or otherwise indicated extreme
  discontent?  If so, please summarize what are they upset about.

No.

7) Have the chairs verified that the document adheres to _all_ of the
  ID nits?  (see http://www.ietf.org/ID-nits.html).

Yes. An output of the run on this revision of the ID by the online nits
checker:

idnits 1.98

tmp/draft-ietf-radext-delegated-prefix-01.txt:

  Checking nits according to http://www.ietf.org/ID-Checklist.html:

    Checking conformance with RFC 3978/3979 boilerplate...

    the boilerplate looks good.

    No nits found.

  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
    Nothing found here (but these checks do not cover all of
    1id-guidelines.txt yet).

  Experimental warnings:
    None.

    No nits found.

8) Does the document a) split references into normative/informative,
  and b) are there normative references to IDs, where the IDs are not
  also ready for advancement or are otherwise in an unclear state?
  (Note: the RFC editor will not publish an RFC with normative
  references to IDs, it will delay publication until all such IDs are
  also ready for publication as RFCs.)

The document does split references into normative and informative ones.
There are no normative references to IDs.

9) For Standards Track and BCP documents, the IESG approval
  announcement includes a writeup section with the following
  sections:

  - Technical Summary

This document describes a RADIUS attribute that enables assignment
of an IPv6 prefix for delegation by the Network Access Server.  The need
for this attribute was discovered during IPv6 deployments using prefix
delegation.  The document uses an attribute format similar to that used
for the Framed-IPv6-Prefix attribute in RFC 3162, so that support for the
attribute can be added to the dictionary in several existing RADIUS
servers without requiring code changes.

  - Working Group Summary

This document has been through RADEXT WG last call.  Discussion focused
on aspects of the attribute format, RFC 3162 deployment models, and
editorial issues.