Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-map-radius-16.txt

From: [email-masked]
Date: Fri, 14 Sep 2018 10:48:07 +0200

Hi Yu,

Please see inline below.

Thanks,
Ian

> On 17. Aug 2018, at 11:48, Yu Fu <[email-masked]> wrote:
> 
> Hi Ian
> 
>  
> 
> Thanks for your thorough  comments. Please see my reply below:
> 
>  
> 
> BR
> 
> Yu 
> 
>  
> 
> Hi Yu,
> 
> Thanks for the update. I think the changes that you have made have improved the document significantly, but there’s still a few things that need to be addressed. Please see below.
> 
> Also, Jordi asked a question about this draft, which I don’t think has been replied to:
> https://mailarchive.ietf.org/arch/msg/softwires/_7ocUxBwy9i2UqNj2tzqri9p0Gw <https://mailarchive.ietf.org/arch/msg/softwires/_7ocUxBwy9i2UqNj2tzqri9p0Gw>
> [fuyu]: From my side. I am happy to support 464XLAT, but I have made  a tremendous effort to consistent with the different attribute format and writing style after adding the multicast use case. 
> I am not sure that I can do the same work after adding this new function.  Could the Jordi help me to do that work? 

[if -  I’ve emailed the authors separately on this]

>  
> 
> 
> Thanks,
> Ian
> 
> New comments on -16:
> 
> Throughout - the use of 'Sub TLV' and 'Sub-TLV' is not consistent.
> Sub-TLV seems to be the convention in other RFCs (e.g. RFC6929).
> 
> [fuyu] I will check out all through the text for consistent.
> 
> 
> 
> Introduction.
> 
> s/At the Section 4.9/In Section 4.9/
> 
> As the softwire prioritisation funciton of RFC8026 is also
> included, there should be a short paragraph (a cut down version of
> sec 4, para 3) stating that this function is included.
> 
> [fuyu]: Do you think add a sentence as “A new Softwire46-Priority Attribute contains RADIUS information corresponding to OPTION_S46_PRIORITY defined in [RFC8026] is defined in Section 4.8.” will be Ok?
> 
[if - OK]

> 
> 
> 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.
> 
> [if - I can't find any changes in the text for this, or any repsonse
> to the comment.]
> 
> [fuyu]: Do you think a table as following will be help?
> 
> 
>           +-----------------------------------+-----------------------------------------+
> 
>           |      DHCPv6 Option           | RADIUS Attribute/Sub TLV |
> 
>           +-----------------------------------+---------------------------------------+
> 
>           |     OPTION_S46_RULE    |     S46-Rule Sub TLV           |  
> 
>           +---------------------------------+-------------------------------------+
> 
>           |   OPTION_S46_BR       |        S46-BR Sub TLV           |  
> 
>           +-------------------------------+------------------------------------+ 
> 
>           |      ……                            |        ……                                |  
> 
>           +------------------------------+----------------------------------+ 
> 
>    
> 
[if - Yes, that’s what I had in mind]
> 
> ----------------------------
> 
> 
> 3.c)
> The figure is easier to follow if it is space out a bit more and
> clafifies the first step:
> 
>  CE                             BNG                         AAA Server
>  |                               |                               |
>  |-------1.DHCPv6 Solicit------->|                               |
>  |(ORO with unicast and/or m'cast|                               |
>  |    container option code(s))  |                               |
>  |                               |                               |
>  |                               |-------2.Access-Request------->|
>  |                               | (S46-Configuration attribute  |
>  |                               |and/or S46-Multicast attribute)|
>  |                               |                               |
>  |                               |<------3.Access-Accept---------|
>  |                               | (S46-Configuration attribute  |
>  |                               |and/or S46-Multicast attribute)|
>  |                               |                               |
>  |<----4.DHCPv6 Advertisement----|                               |
>  |     (container option(s))     |                               |
>  |                               |                               |
>  |-------5.DHCPv6  Request------>|                               |
>  |     (container Option(s))     |                               |
>  |                               |                               |
>  |<--------6.DHCPv6 Reply--------|                               |
>  |     (container option(s))     |                               |
>  |                               |                               |
>               DHCPv6                         RADIUS
> 
> [if - Old diagram is still present, please use the above figure.]
> [fuyu]: Ok, I have updated it.
> 
> 3.f)
> Replace:
> For the multicast case, OPTION_V6_PREFIX64 should be included for the delivery of multicast
>   services in the context of transition to IPv6.
> with:
> For the multicast case, the the option number for OPTION_V6_PREFIX64 (113)
> should be included in the client's ORO.
> 
> [if - Sorry, I doubled the word 'the' in my suggested text. Please use 'case,
> the option number']
> [fuyu]: Done 
> 
> 
> 3.l)
> Item 3. uses an RFC2119 MUST statement. This is the first time
> in the message flow that any compulsory behaviour is defined. The
> requirements language should be consitent throughout all of the steps
> (either all RFC2119, or none)
> 
> A MUST here is also strange. What if the AAA server doesn't have
> the requested configuration to supply to the client?
> 
> [if - Sorry, I doubled the word 'the' in my suggested text. Please use 'case,
> the option number']
> [fuyu]: Done
> 
> 
> 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.
> 
> [if - I can't find any changes in the text for this, or any repsonse
> to the comment.]
> [fuyu]: Do you think the table described above will make sense?
> 

[if - Yes]

> 
> 3.p)
> "The recommended format of the MAC address is defined as Calling-Station-
> Id (Section 3.20 in [RFC3580] without the SSID (Service Set
> Identifier) portion."
> 
> I don't understand the meaning of this sentence in context of where we
> are in the message flow. What is the MAC address that is needed at
> this stage?
> 
> [if - The addtional text doesn't answer this question. The BNG is constructing
> a DHCPv6 Reply message. Where does a MAC address belong in this message?
> If it's the MAC address that it will source the DHCPv6 reply message from,
> why is it being changed at this stage rather than configured in advance (i.e.
> before the Advertise is sent) so it can be consistent throughout the
> whole DHCP message flow?]
> [fuyu]: This describe sentences is really confusing.  I will delete this sentences. 
> 
> 3.r)
> The paragraph begining "The authorization process could also..." doesn't
> really make sense where it is located. The previous paragraph does
> not follow from the previous para. concerning lw4o6 syncronisation and
> refers to a previous scenario, although it's not really clear what
> that scenario is.
> This could be cleared up by (1) making it clear that section 3 fig 1.
> is describing combined Authentication and Authorisation. (2) Creating
> a sub-section for this paragraph (and the one below it) that detail
> what the changes are from the steps in section 3 (i.e. where additional
> attributes are needed / not needed and what they contain).
> 
> [if - Currently still a problem, please see my general comments on
> this version above.]
> [fuyu]: Do you think adding a sub-section to describe  this authorization process will make it more clear? If yes, I will update a new
> 
> Sub-section here in the next version. 
> 

[if - Yes, but please take my other comments into account]
> 
> 3.s)
> The final 3 paragraphs deal with some error handling conditions. Perhaps
> a sub-section for these would make for a better structure?
> 
> [if - The error handling text is now duplicated, once with
> bullet points and again in the body text. Please fix.]
> [fuyu]: OK, I will simplify it.
> 
> 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).
> 
> [if - I can't find any changes in the text for this, or any repsonse
> to the comment.]
> [fuyu]: The scope of this draft is designing  the format of radius attributes and  describe the Attribute process. 
> 
> So do you think it is really  need to describe the process for the detail of the DHCP options ? or it is out of scope? 
> 

[if - OK, let’s leave it out]