Subject: Reviewing is needed, FW: New Version Notification for draft-ietf-softwire-6rd-radius-attrib-00

From: Sheng Jiang <[email-masked]>
Date: Tue, 16 Nov 2010 08:56:30 +0800

Hi, Radext WG,

The softwire WG has juest approved a WG document, draft-ietf-softwire-6rd-radius-attrib, which
defines a RADIUS attribute that carries 6rd configuration information from AAA server to BNG.

We would like to get reviewing from Radext WG to make sure the compatibility between this draft and
RADIUS protocol. Any comments are welcome.

Many thanks and best regards,

Sheng

> -----Original Message-----
> From: IETF I-D Submission Tool [mailto:[email-masked]] 
> Sent: Tuesday, November 16, 2010 2:26 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: New Version Notification for 
> draft-ietf-softwire-6rd-radius-attrib-00
> 
> 
> A new version of I-D, 
> draft-ietf-softwire-6rd-radius-attrib-00.txt has been 
> successfully submitted by Sheng Jiang and posted to the IETF 
> repository.
> 
> Filename:	 draft-ietf-softwire-6rd-radius-attrib
> Revision:	 00
> Title:		 RADIUS Attribute for 6rd
> Creation_date:	 2010-11-15
> WG ID:		 softwire
> Number_of_pages: 8
> 
> Abstract:
> 6rd is One of the most popular methods to provide both IPv4 
> and IPv6 connectivity services simultaneously during the 
> IPv4/IPv6 co-existing period. The DHCP 6rd option has been 
> defined to configure 6rd CPE. 
> But in many networks, the configuration information may be 
> stored in AAA servers while user configuration is mainly from 
> Broadband Network Gateway (BNG) through DHC protocol. This 
> document defines a RADIUS attribute that carries 6rd 
> configuration information from AAA server to BNG.
>                                                               
>                     
> 
> 
> The IETF Secretariat.
> 
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 15 Nov 2010 20:14:53 -0800

The RADIUS Design Guidelines document specifies guidelines for the design of RADIUS attributes as well
as compatibility with the RADIUS protocol:
http://tools.ietf.org/html/draft-ietf-radext-design

Please have a look at the document.  In particular, it is expected that prior to requesting review, that documents 
will have examined their compatibility with the checklist contained in Appendix A. 

> Date: Tue, 16 Nov 2010 08:56:30 +0800
> From: [email-masked]
> Subject: Reviewing is needed, FW: New Version Notification for draft-ietf-softwire-6rd-radius-attrib-00
> To: [email-masked]; [email-masked]
> 
> Hi, Radext WG,
>

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 16 Nov 2010 15:52:35 +0800

Thanks, Bernard. We were aware the Design Guidelines document. We have followed the guidelines,
also refer to exist radius RFCs. We still like to get reviews by RADIUS experts in case, we have
missed any thing.

Regards,

Sheng

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Tuesday, November 16, 2010 12:15 PM
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: Reviewing is needed, FW: New Version 
> Notification for draft-ietf-softwire-6rd-radius-attrib-00
> 
> The RADIUS Design Guidelines document specifies guidelines 
> for the design of RADIUS attributes as well as compatibility 
> with the RADIUS protocol:
> Please have a look at the document.  In particular, it is 
> expected that prior to requesting review, that documents will 
> have examined their compatibility with the checklist 
> contained in Appendix A. 
> 
> > The softwire WG has juest approved a WG document, 
> > draft-ietf-softwire-6rd-radius-attrib, which defines a 
> RADIUS attribute that carries 6rd configuration information 
> from AAA server to BNG.
> > 
> > We would like to get reviewing from Radext WG to make sure the 
> > compatibility between this draft and RADIUS protocol. Any 
> comments are welcome.
> > 
> successfully 
> > > submitted by Sheng Jiang and posted to the IETF repository.
> > > 
> > > 6rd is One of the most popular methods to provide both 
> IPv4 and IPv6 
> > > connectivity services simultaneously during the
> > > IPv4/IPv6 co-existing period. The DHCP 6rd option has 
> been defined 
> > > to configure 6rd CPE.
> > > But in many networks, the configuration information may 
> be stored in 
> > > AAA servers while user configuration is mainly from Broadband 
> > > Network Gateway (BNG) through DHC protocol. This document 
> defines a 
> > > RADIUS attribute that carries 6rd configuration 
> information from AAA 
> > > server to BNG.
> > > 
> > > 
> > > 
> > > 
> > > The IETF Secretariat.
> > > 
> > > 
> > 
> > 
> > --

---

From: Alan DeKok <[email-masked]>
Date: Tue, 16 Nov 2010 09:50:52 +0100

> also refer to exist radius RFCs. We still like to get reviews by RADIUS experts in case, we have

  Editorial:

* Section 3

   The below Figure 1 illustrates how the RADIUS protocol and DHCP are
   cooperated to provide users/hosts with 6rd configuration.
   ...

  English nit: "are cooperated" is not correct English.  I suggest
replacing that phrase with the word "cooperate".

  Other minor grammatical issues are seen through the document, but do
not affect readability.

* Section 4.1

  ...
4.1. 6rd Attribute
  ...

  The attribute needs to be given a unique name, as is done with the
attributes in RFC 2865, etc.  See Section 5.1, 5.2, and following of RFC
2865.

  I suggest a name like "IPv6-RD-Configuration".  Other names are possible.

* Section 4.1

      ...
      Type        TBD
      ...

  The fields should be described in a similar manner to previous RFCs:

	FIELD

	   DESCRIPTION

  Also, the "Type" field should use the name of the attribute.  See RFC
2865 Section 5.1 for an example.

* Section 4.1
      ...
      Length       the length of the DHCP option in octets (22 octets
                     with one BR IPv4 address).
       ...

  It is not a DHCP option.  I suggest deleting that entire sentence.

  The length should be given in the same manner as the previous RFCs:

   Length

      >= 22

* Section 4.1

       ...
       6rdBRIPv4Address    One or more IPv4 addresses of the 6rd Border
                     Relay(s) for a given 6rd domain.
       ...

  It would be good to not that there is a limit on the number of IPv4
addresses.  The maximum RADIUS Attribute length of 255 octets results in
a limit of 59 IPv4 addresses.  While this may not be a limitation in
practice, it should be noted in the document.

* Section 4.2

   Request Accept Reject Challenge Accounting  #  Attribute
                                    Request
    0+      0+     0      0         0+        TBD  6rd

  Again, giving the attribute a useful name is critical.  "6rd" is not
an acceptable name.

* Section 7

   This document requires the assignment of two new RADIUS Attribute
   ...

  The document defines only one attribute.  Other text in this section
talks about attributeS, also.

  The attribute uses a non-standard format, without explaining why this
format was chosen.  The Guidelines document (Section 1.3, third
paragraph) suggests such explanations.  Some possible text is:

  The specification requires that multiple IPv4 addresses are associated
  strongly with one IPv6 prefix.  Given that RADIUS currently has no
recommended way of grouping multiple attributes, the current design
appears to be a reasonable compromise.

  If there was a TLV data type in RADIUS, these attributes would best be
placed inside of an encapsulating TLV.

  Alan DeKok.

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 16 Nov 2010 17:33:43 +0800

Hi, Alan,

Thanks so much for your valuable comments. Most of them are addressed in the next version. A couple
of explanation is below. 

We rename the attribute "6rd-Configuration". 6rd is a term for "IPv6 rapid deployment mechanism".
It cannot be replaced by other name.

We have edited the length description like below, hope it is ok.

"20 + n*4 (the length of the entire attribute in octets; n stands the number of BR IPv4 addresses,
minimum n is 1)."

Sheng + Dayong

> [mailto:[email-masked]] On Behalf Of Alan DeKok
> Sent: Tuesday, November 16, 2010 4:51 PM
> To: Sheng Jiang
> Cc: 'Bernard Aboba'; [email-masked]; [email-masked]
> Subject: Re: Reviewing is needed, FW: New Version 
> > Thanks, Bernard. We were aware the Design Guidelines 
> document. We have 
> > followed the guidelines, also refer to exist radius RFCs. We still 
> > like to get reviews by RADIUS experts in case, we have 
> missed any thing.
> 
>   Editorial:
> 
> * Section 3
> 
>   English nit: "are cooperated" is not correct English.  I 
> suggest replacing that phrase with the word "cooperate".
> 
>   Other minor grammatical issues are seen through the 
> document, but do not affect readability.
> 
> 
> * Section 4.1
> 
>   ...
> 4.1. 6rd Attribute
>   ...
> 
>   The attribute needs to be given a unique name, as is done 
> with the attributes in RFC 2865, etc.  See Section 5.1, 5.2, 
> and following of RFC 2865.
> 
>   It would be good to not that there is a limit on the number 
> of IPv4 addresses.  The maximum RADIUS Attribute length of 
> 255 octets results in a limit of 59 IPv4 addresses.  While 
> this may not be a limitation in practice, it should be noted 
> in the document.
> 
> 
> 
> * Section 4.2
> 
>   Again, giving the attribute a useful name is critical.  
> "6rd" is not an acceptable name.
> 
> 
> 
> * Section 7
> 
>   The document defines only one attribute.  Other text in 
> this section talks about attributeS, also.
> 
> 
> 
>   The attribute uses a non-standard format, without 
> explaining why this format was chosen.  The Guidelines 
> document (Section 1.3, third
>   strongly with one IPv6 prefix.  Given that RADIUS currently 
> has no recommended way of grouping multiple attributes, the 
> current design appears to be a reasonable compromise.
> 
>   If there was a TLV data type in RADIUS, these attributes 
> would best be placed inside of an encapsulating TLV.
> 
>   Alan DeKok.
> 
> --
> to unsubscribe send a message to 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 16 Nov 2010 11:29:09 +0100

> It cannot be replaced by other name.

  That makes no sense.  The name has *no* impact on the protocol.  It
could be named "XYZ-Foo", and still have the same functionality.

  The name *does* have impact on administrators of RADIUS systems, and
implementors of RADIUS specifications.  Using a name that follows
existing RADIUS naming practices is a good idea.  The above name does
*not* follow existing RADIUS naming practices.

  Again, using a name such as "IPv6-RD-Configuration", or
"IPv6-6rd-Configuration" *would* follow existing RADIUS naming
practices, with no loss of functionality or clarity.

> "20 + n*4 (the length of the entire attribute in octets; n stands the number of BR IPv4 addresses,

  That's fine.

  Alan DeKok.

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 17 Nov 2010 11:00:01 +0800

Hi, Alan,

"IPv6-6rd-Configuration" sounds good for us. We will use it in the next version.

Thanks and best regards,

Sheng

> From: Alan DeKok [mailto:[email-masked]] 
> Sent: Tuesday, November 16, 2010 6:29 PM
> To: Sheng Jiang
> > Thanks so much for your valuable comments. Most of them are 
> addressed 
> > in the next version. A couple of explanation is below.
> > 
>   That makes no sense.  The name has *no* impact on the 
> protocol.  It could be named "XYZ-Foo", and still have the 
> same functionality.
> 
>   The name *does* have impact on administrators of RADIUS 
> systems, and implementors of RADIUS specifications.  Using a 
> name that follows existing RADIUS naming practices is a good 
> idea.  The above name does
> "IPv6-6rd-Configuration" *would* follow existing RADIUS 
> naming practices, with no loss of functionality or clarity.
> 
> > "20 + n*4 (the length of the entire attribute in octets; n 
> stands the 
> > number of BR IPv4 addresses, minimum n is 1)."
> 
>   That's fine.
> 
>   Alan DeKok.