Hi Ian,
Thank you for your reply. Please see below Thanks Yu From: [email protected] [mailto:[email protected]] Sent: Tuesday, April 17, 2018 2:52 PM To:傅瑜 Cc: Softwires WG; [email protected] Subject: Re: [Softwires] WGLC on draft-ietf-softwire-map-radius-14 - 1 of 2 Hi, I only saw comments on the first part of my review. Have you also seen the second part? [fuyu] Sorry, I have missed this email, a feedback will be replied later. 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.] [fuyu] Ok, I will try to draw a table to describe it. 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. [fuyu] Ok, I will reword it in the nest version. 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.] [fuyu] Ok 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? [fuyu] If steps 1-4 complete, but the BNG never receives a request message from the client, the BNG will also send the resources to the client by some policy. It is based on the implementation by the device company.
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
