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: [email protected] > [mailto:[email protected]] On Behalf Of Alan DeKok > Sent: Tuesday, November 16, 2010 4:51 PM > To: Sheng Jiang > Cc: 'Bernard Aboba'; [email protected]; [email protected] > 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 > [email protected] with the word 'unsubscribe' in > a single line as the message text body. > archive: <http://psg.com/lists/radiusext/> _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
