Leaf, Med,

I'm writing a shepherding document for
draft-yeh-dhc-dhcpv6-authorization-opt. As part of this process, I
reviewed this document one more time and have a couple of
questions/comments.

Questions:

1. Was this document presented and reviewed in RADEXT? I'm satisfied
with the depth and breadth of reviews this document received in DHC, but
I'm concerned with the reviews from RADIUS perspective. I found only one
post about it to RADEXT wg:
http://www.ietf.org/mail-archive/web/radext/current/msg07717.html. Was
this draft presented in RADEXT meeting? Was it discussed on RADEXT
mailing list? If not, what is the reason?

2. There are 2 warnings reported by idnits:
- lack of boilerplate RFC2119 text (there is a text in section 2, but
you do not use exact wording as RFC2119 suggests, so idnits gets confused)
- missing references in line 265 (some type codes are marked as [TBD],
which confuse idnits as a to be defined references. Removing the
brackets should solve this idnits issue).
Can you please post updated version that solves this?

Review comments:

Title: "RADIUS Option for DHCPv6 Relay Agent on the Broadband Access
Servers"
While the primary usage scenario for this mechanism is NAS, this
mechanism can be used in a generic case on any relay that happens to
also be Radius client. I propose to remove "on the Broadband Access
Servers" from the title. If you want to keep it, please add somewhere in
the Introduction a text that explains that while deploying this
mechanism on NAS is the primary use case, it may be useful in other
deployment types as well. You may compare this with RFC4014 and its title.

Section 1 introduction. Please remove "etc." from "The stateful
configuration parameters include IPv6 address[RFC3315], IPv6 prefix
[RFC3633], etc.". Currently there are no other stateful configuration
parameters. You may add a text here about this being a generic mechanism
and that NAS happen to be the obvious usage scenario. A single sentence
will do the trick.

Section 2: idnits (http://tools.ietf.org/tools/idnits/) reports that the
RFC2119 boilerplate does not include exact expected text. Can you fix it?

Section 3, figure 1 and 2: Can you rename the NAS box to NAS/DHCPv6
relay? Its double function is rather obvious from the types of received
and transmitted messages, but it makes the figure a bit easier to
understand.

Section 4. Can you put the initial list of attributes in a separate
subsection (4.1)? This will make it easier for IANA guys to understand.
Make sure you reference this new 4.1 section from IANA considerations
section.

Section 4 says that the following attributes may be stored in the RADIUS
option, but do not specify clearly how to encode them. There is a text
that references section 5 of RFC2865 and inclusion of length and type
fields, but this is still confusing. The current text is ambiguous if
the type and length are 1 octet wide (Radius style) or 2 octets wide
(DHCPv6 style). This should be clarified. It would also be helpful, if
you could add a section 4.2 that provides a simple example. You may take
a look at RFC6334, section 3.

Section 5 enumerates several message types, DHCPv6 options and Radius
attributes. Some of them are accompanied with values in parentheses and
some of them are not. Please unify this - either mention values for all
or for none.

In section 5 you refer to RADIUS option as container option. Please call
it just OPTION_RADIUS as you do in the rest of the text.

Section 6 is called Server Behavior. Usually this is correct, but in
this context "server" is ambiguous (DHCPv6 server or RADIUS server?).
Please rename it to DHCPv6 Server Behavior. The same applies to sections
5. and 7.

Section 6 has the following text "Upon receipt of the RELAY-FORW (12)
message with OPTION_RADIUS from a relay agent, the DHCPv6 server SHOULD
extract and interpret the RADIUS attributes in the OPTION_RADIUS, and
use that information in selecting configuration parameters for the
requesting client.". I would argue that SHOULD is too strong and MAY
should be used instead. Whether the server uses or not the contents of
RADIUS option is really a matter of server policy which is up to network
administrator, so SHOULD is too strong here.

Section 9 "IANA considerations" requires a small update. You ask IANA to
define a new registry "RADIUS Attributes Permitted in the DHCPv6 RADIUS
option". It is almost good, but you did not specify initial content of
this new registry in the IANA consideration section. Adding a simple
reference to section 4 (or a section 4.1 as suggested earlier in my
mail) should do solve this issue. There's a formal question in IESG
write-up that specifically asks about this and doing it now will save us
a lot of hassles and delays later in the IESG review process.

Why there is no reference to RFC4014 that defines exactly the same
mechanism for DHCPv4?

Once you'll address those comments (or respond that you chose to not
change the text), please upload updated version. I'll then resume my
work on shepherding this document. Make sure this new version do not
have any issues reported by idnits.

Tomek