Subject: [dhcwg] Review/shepherding for draft-ietf-dhc-dhcpv6-radius-opt-09

From: Tomek Mrugalski <[email-masked]>
Date: Tue, 02 Apr 2013 22:07:24 +0200

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

---

From: "Leaf Yeh" <[email-masked]>
Date: Wed, 3 Apr 2013 22:03:29 +0800

Hi Tomek,

Thanks for the co-chair's thoroughly review again. :-)

Tomek - 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?

I am not sure the draft (OPTION_RADIUS) has been reviewed in the ML of
RADEXT-WG yet, though it is always in the ML of AAA-DOCTORS
(http://www.ietf.org/mail-archive/web/aaa-doctors/current/maillist.html  ).
I suppose RADEXT-WG still has the chance to review it in the period of IESG
LC. 

Tomek - 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)

Per the requirement of RFC2119, the text will be updated to be: 
"      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
      "OPTIONAL" in this document are to be interpreted as described in
      RFC 2119." in the ver.-10 of draft (OPTION_RADIUS).

Tomek - 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?

Per the RADIUS registry of IANA
(http://www.iana.org/assignments/radius-types/radius-types.xml ), the table
in section 4 will be updated to be 

   Type Code  Attribute                   Reference
   26         Vendor-Specific             [RFC2865]
   123        Delegated-IPv6-Prefix       [RFC4818]
   144        DS-Lite-Tunnel-Name         [RFC6519]
   168        Framed-IPv6-Address         [I-D.ietf-radext-ipv6-access]
   169        DNS-Server-IPv6-Address     [I-D.ietf-radext-ipv6-access]
   171        Delegated-IPv6-Prefix-Pool  [I-D.ietf-radext-ipv6-access]
   172        Stateful-IPv6-Address-Pool  [I-D.ietf-radext-ipv6-access]

in the ver.-10.

Tomek - 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.

I am fine with the new title of the draft as "RADIUS Option for DHCPv6 Relay
Agent" in the ver.-10.

Tomek - 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. 

The above text will be updated to be "The stateful configuration parameters
include IPv6 address[RFC3315] and IPv6 prefix [RFC3633]." in ver.-10. 

Tomek - 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.

How about to add the following text after the 1st paragraph of section 3: "
The mechanism introduced in this document is a generic mechanism, and might
also be employed in other network scenarios where the DHCPv6 relay agent and
the RADIUS client locate in the same device." ?

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

See the above reply.

Tomek - 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.

How about to denote the NAS as follows:
"          +-------+ 
          |  NAS  | 
          |       | 
          +-------+ 
 RADIUS Client/DHCPv6 Relay Agent" 
in Fig.1 & 2?

Tomek - 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.

I am fine with it, you will get "section 4.1 RADIUS attributes permitted in
DHCPv6 RADIUS option" in ver.-10.  :-)

Tomek - 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.

The RADIUS attributes are included in the OPTION_RADIUS one by one, cause
they are in TLV format.
The note after the table of "RADIUS attributes permitted in DHCPv6 RADIUS
option" is a note for the difference in TLV format defined for RADIUS
attribute with that defined for DHCPv6 option. I meant the DHCPv6 option's
'Length' (option-len) does not include the length of 'Type' and 'Length'
fields, but the RADIUS attribute's 'Length' does. 
The text could be updated to be "Note: The RADIUS attribute's 'Length'
defined in section 5 of RFC2865, includes the length of 'Type' and 'Length'
fields.", OK?

Tomek - 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.

I am fine with it. How about to update the text to be 
"...the relay agent that supports OPTION_RADIUS
   SHOULD include these RADIUS attributes into the
   OPTION_RADIUS one by one." 
for the above 2 questions? 

Tomek - 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.

The text in section 5 will be updated to be 
"When the value in the attributes of 
Delegated-IPv6-Prefix-Pool (171), Stateful-IPv6-Address-Pool
(172),Delegated-IPv6-Prefix (123)
   or Framed-IPv6-Address (168) in the Access-Accept message replied from
   RADIUS server are valid, ..."
in ver.-10, cause we just can get the codes from the RADIUS registry of IANA
(http://www.iana.org/assignments/radius-types/radius-types.xml ) these days.

Tomek - 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.

I am fine with it. The titles of section 5,6 & 7 will be updated to be
"DHCPv6 Relay Agent Behavior", "DHCPv6 Server Behavior" & "DHCPv6 Client
Behavior" in ver.-10.

Tomek - 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.

How about "...the DHCPv6 server that supports OPTION_RADIUS SHOULD..." ?

Tomek - 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.

I am fine with it. The text will be updated to be: "This document requests
to assign a new DHCPv6 option code for OPTION_RADIUS defined in section 4,
and to create a new registry on the same assignment page, which is entitled
as 'RADIUS attributes permitted in DHCPv6 RADIUS option' defined in section
4.1." in the ver.-10.

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

I guess the text associated with RFC4014 has been dropped from the ver.-04
per the comment in the ML
(http://www.ietf.org/mail-archive/web/dhcwg/current/msg13350.html).

Best Regards,
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Tomek Mrugalski
Sent: Wednesday, April 03, 2013 4:07 AM
To: dhcwg
Subject: [dhcwg] Review/shepherding for draft-ietf-dhc-dhcpv6-radius-opt-09

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 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 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
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "Leaf Yeh" <[email-masked]>
Date: Wed, 3 Apr 2013 22:45:39 +0800

Tomek - 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.

The draft (OPTION_RADIUS) has been updated to be ver.-10.
(http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-radius-opt/?include_t
ext=1)
The update from ver.-09 can be check here.
(http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-dhcpv6-radius-opt-10)
The exact wording as RFC2119 suggests is from here.
(http://tools.ietf.org/html/rfc2119)
Some [TBD]s have been updated to be the codes of the newly defined RADIUS
attributes per the registry of IANA.
(http://www.iana.org/assignments/radius-types/radius-types.xml )

Best Regards,
Leaf

-----Original Message-----
From: Leaf Yeh [mailto:[email-masked]] 
Sent: Wednesday, April 03, 2013 10:03 PM
To: 'Tomek Mrugalski'; 'dhcwg'
Cc: [email-masked]'
Subject: RE: [dhcwg] Review/shepherding for
draft-ietf-dhc-dhcpv6-radius-opt-09

Hi Tomek,

in the ver.-10.

See the above reply.

The text in section 5 will be updated to be 
"When the value in the attributes of 
Delegated-IPv6-Prefix-Pool (171), Stateful-IPv6-Address-Pool (172),
Delegated-IPv6-Prefix (123)
   or Framed-IPv6-Address (168) in the Access-Accept message replied from
   RADIUS server are valid, ..."
in ver.-10, cause we just can get the codes from the RADIUS registry of IANA
(http://www.iana.org/assignments/radius-types/radius-types.xml ) these days.

Best Regards,
Leaf

-----Original Message-----

Leaf, Med,

Questions:

Review comments:

Tomek