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

"Yu Fu" <fuyu@cnnic.cn> Fri, 17 August 2018 09:49 UTC

Return-Path: <fuyu@cnnic.cn>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF51130E3A; Fri, 17 Aug 2018 02:49:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bYvwJ--7bZQY; Fri, 17 Aug 2018 02:49:04 -0700 (PDT)
Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF64126BED; Fri, 17 Aug 2018 02:48:56 -0700 (PDT)
Received: from LIUXD (unknown [218.241.103.63]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0BpcPwFmnZbOkYJAA--.24929S3; Fri, 17 Aug 2018 17:48:53 +0800 (CST)
From: Yu Fu <fuyu@cnnic.cn>
To: 'Ian Farrer' <ifarrer@me.com>
Cc: 'Softwires WG' <softwires@ietf.org>, draft-ietf-softwire-map-radius@ietf.org
References: <5A379DA9-A6C1-4E07-A517-6477D8DE5BEF@me.com> <77C785B6-E868-46A0-BF95-2853F4E940F5@me.com>
In-Reply-To: <77C785B6-E868-46A0-BF95-2853F4E940F5@me.com>
Date: Fri, 17 Aug 2018 17:48:32 +0800
Message-ID: <000001d4360f$759c64a0$60d52de0$@cn>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01D43652.83BFA4A0"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AdQfZsAQgCor2UQVScOPhgZyTjoP5QVvPaAA
Content-Language: zh-cn
X-CM-TRANSID: AQAAf0BpcPwFmnZbOkYJAA--.24929S3
X-Coremail-Antispam: 1UD129KBjvJXoW3AFy7ArW5ur17tFyxXFWfAFb_yoWfuw4Upr WfGr17GryDJr1xGw1kJw48XFyrArs5Gw1UJFyUtF18Zwn8Crn2qryFq34FgFyUJrW8Xw1j vr1Utr1Uur1UZrJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUPqb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Gr0_Xr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVW0oVCq3wA2z4x0Y4vEx4 A2jsIEc7CjxVAFwI0_GcCE3s1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG67k08I80 eVW8JVW5JwAqx4xG6c804VAFz4xC04v7Mc02F40Ew4AK048IF2xKxVWUJVW8JwAqx4xG6x AIxVCFxsxG0wAv7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S 6xCaFVCjc4AY6r1j6r4UM4x0Y48IcxkI7VAKI48JMx8GjcxK6IxK0xIIj40E5I8CrwCY02 Avz4vE14v_GFWl42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAq x4xG67AKxVWUGVWUWwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1Y6r 17MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF 7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rVWrZr1j6s0DMIIF0xvEx4A2jsIE14 v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Gr0_Gr1UYxBIdaVFxhVjvjDU0xZFpf9x 07boUDXUUUUU=
X-CM-SenderInfo: pix13q5fqqxugofq/
Archived-At: <https://mailarchive.ietf.org/arch/msg/softwires/YAehPhJZHYnCQ_zyqGBruNKduBE>
Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-map-radius-16.txt
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/softwires/>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Aug 2018 09:49:09 -0000

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

[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? 
 



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?

Section 3, point 6.

In the diagram, you show a simple reply message being sent
to the client, but the accompanying text describes a number
of other communication flows and updates that can potentially
need to happen.

Really, the whole of this section is not really well constructed
in it's current form. The purpose of the numbered points is to
describe what is in the flows in the diagram, but point 6. goes
on to included a further page and a half of options and
considerations. Can point 6 not be ended after the sentance ending
...enumerated in the ORO.? and the remaining text in section 3
be put into relevantly named sub-sections.



[fuyu]: Yes, I will update it as the point 6 will be ended by “enumerated in the ORO” and a sub-sections will be added


4.4.2 S46-BR Sub TLV
S46-Lightweight--4over6 TLV - please remove duplicate '-'.
[fuyu]: Done


4.5 Sub-TLVs for S46-Rule Sub TLV
Given the RFC2119 language used in the requirements for the
other options, suggest the following:
s/It should appear for once and only once./It MUST appear
exactly once./
[fuyu]:Done
4.6.2 The Bind-IPv6-Prefix Sub-TLV

s/The bind-ipv6-prefix field specified in this field/The bind-ipv6-prefix specified in this field/
[fuyu]: Done
---------

Updated comments from my previous review:


1.f)
After the sentence "A DHCPv6 server function is
  assumed to be embedded in the BNG that allows it to locally handle
  any DHCPv6 requests initiated by hosts." it would be
  worth adding that the term BNG is used througout the document
  to describe a device which functions as both the AAA client
  and DHCPv6 server.

[if - New version is better, but a suggested rewording for these two sentances:
A DHCPv6 server function is assumed to be embedded in the BNG
that allows it to locally handle DHCPv6 requests initiated by
hosts.  The abbrieviation BNG is used in this document to describe a device
which functions as both the AAA client and DHCPv6 sever.]
[fuyu]: The new sentences is updated 

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           |  

          +-------------------------------+------------------------------------+ 

          |      ……                            |        ……                                |  

          +------------------------------+----------------------------------+ 

   


----------------------------


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?

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. 


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?