Hi, I only saw comments on the first part of my review. Have you also seen the second part?
Please see below. Thanks, Ian > > > 1.i) > Last paragraph: It would also be worth saying how the structure of the > DHCP options and field namings are preserved so they can > easily be mapped between DHCP and RADIUS. > > [fuyu] Do you mean to describe device implementation in more detail? > [if - The contents of the sub-options defined in this draft have a 1:1 mapping into the fields of the various DHCP options In RFC7598 and RFC8115. A table which gives the DHCP option and field name and matches this to the RADIUS Attribute/option would make this easier to do.] > > A MUST here is also strange. What if the AAA server doesn't have > the requested configuration to supply to the client? > [fuyu] In the section 4.2 of RFC 2865, it also describes that “If all > Attribute values received in an > Access-Request are acceptable then the RADIUS implementation MUST > transmit a packet with the Code field set to 2 (Access-Accept).” > So I think a MUST should be here. [if - The RFC2865 text is saying the same as I am - 'if the attributes are acceptable’ i.e. if there is configuration available and policy in place to supply it. .. The current draft text says: "If the authentication request is approved by the AAA server, an Access-Accept message MUST be acknowledged with the corresponding Softwire46-Configuration Attribute…” The authentication request being approved isn’t the same thing as having Softwire configuration available and The policy to supply it to that customer. A suggested re-word: 3. If the authentication request is approved by the AAA server, and suitable confguration is available, an Access-Accept message MUST be acknowledged with the corresponding Softwire46-Configuration Attribute or Softwire46-Multicast Attribute. > > > 3.m) > In the DHCPv6 Advertisement message, there needs to be the > corresponding DHCPv6 option holding the correct information > from the RADIUS message. This means that we need to map the > fields from the attributes to the options. A table showing > how this mapping is done would be very useful. > > [fuyu] Do you mean giving a table to describe DHCPv6 option and corresponding > attribute? > > [i [if - Yes. The table needs to show each DHCP option and the name of the fields in the option and map them to the corresponding RADIUS attribute/sub-option.] > > 3.s) > The final 3 paragraphs deal with some error handling conditions. Perhaps > a sub-section for these would make for a better structure? > [fuyu] Ok, I will make a sub-section. > 3.t) > What happens if steps 1-4 complete, but the BNG never receives a > request message from the client? In this case, the AAA has allocated > resources, but they are not actually in use. Is there a way that > the BNG can invalidate the request after a timeout, or is there > another error handling mechanism that should be used? > > 3.u) > There's no text on what happens when the client send a DHCPv6 Release, > Decline, or an associtated DHCPv6 lease expires (invalidating any > options supplied with that lease). > > [fuyu] I think the key point in the document is to define RADIUS attribute. > Shall we need to define this > DHCPv6 scenarios? I think it may be the text which RFC 7598 should include? [if - I’ve just checked a few other DHCP/RADIUS RFCs and it seems that the convention is not to specify releasing attribute. Comment withdrawn.]
_______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
