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

[Sheng Jiang <shengjiang@huawei.com>]

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)."

Many thanks and best regards,

Sheng + Dayong

> -----Original Message-----
> From: owner-radiusext@ops.ietf.org 
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Alan DeKok
> Sent: Tuesday, November 16, 2010 4:51 PM
> To: Sheng Jiang
> Cc: 'Bernard Aboba'; radiusext@ops.ietf.org; softwires@ietf.org
> Subject: Re: Reviewing is needed, FW: New Version 
> Notification for draft-ietf-softwire-6rd-radius-attrib-00
> 
> Sheng Jiang wrote:
> > 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
> 
>    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.
> 
> --
> to unsubscribe send a message to 
> radiusext-request@ops.ietf.org with the word 'unsubscribe' in 
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>