Re: [Softwires] WGLC on draft-ietf-softwire-map-radius-14 - 1 of 2

[[e-mail]]

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.]