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

[Alan DeKok <aland@deployingradius.com>]

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/>