Hi Yu, Please see inline below.
Thanks, Ian > On 17. Aug 2018, at 11:48, Yu Fu <f...@cnnic.cn> 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]
_______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
