[Softwires] Comments on draft-hu-softwire-multicast-radius-ext

["[e-mail]" <[e-mail]>]

Dear authors,
 
I have read this document and think it is meaningful to propose a new RADIUS attribute to carry the IPv6 prefixes together with the DHCPv6 option defined in draft-ietf-softwire-multicast-prefix-option-07.
 
Here are some comments about this document.
 
1.       The following paragraph repeats twice (section 3 and section 4) in this document.
If the NAS does not receive the Multicast-Prefixes-64 attribute in the Access-Accept message, it MAY fall back to a pre-configured default Multicast-Prefixes-64, if any.  If the NAS does not have any pre-configured, the delivery of multicast traffic is not supported.
Do you think it is more suitable to remove the repeated one in section 3?
 
2.       The architecture of this document seems not very reasonable. Do you think it could be of a better structure? Here are my suggestions.
a)         The section 4 is intended to specify the new RADIUS attribute, it seems that the most content of the section 4.1 is describing the RADIUS client behavior. Do you think it is appropriate to treat this part as a separate section called the Client Behavior.
b)         And I think the sequence of the sections could be modified to become better organized. The section RADIUS Attribute could be introduced first, then the section Client Behavior would be discussed later. While the Multicast-Prefixes-64 Configuration with RADIUS and DHCPv6 section is more appropriate to locate in the rear of those two sections.
 
3.       The ‘DHCPv6 Advertisement’ in Figure 1,2 could be modified as ‘DHCPv6 Advertise’ in a more standardized way according to the RFC 3315.
 
4.       There seems to be a conflict between the figure 1 and its corresponding description. 
From the Figure 1, we can conclude that the DHCPv6 Advertise message carries the DHCPv6 OPTION_PREFIX64 option. 
However, if we refer to the content, it states that ‘the NAS SHALL use the prefixes returned in the RADIUS Multicast-Prefixes-64 attribute to populate the DHCPv6 OPTION_PREFIX64 option in the DHCPv6 reply message’ in section 3.
Do you think it could be better to keep the consistence between the figure and its description.
 
5.       Could you please explain why the DHCPv6 Request message in the Figure 2 does not carry a DHCPv6 OPTION_PREFIX64?
 
6.       Do you think it is necessary to add a separate paragraph that defines how the NAS will communicate with the AAA server when the mB4 is at its DHCP renew stage to make the document more comprehensive?
 
Best regards,
Linhui Sun
 



[e-mail]