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

傅瑜 <fuyu@cnnic.cn> Wed, 18 April 2018 07:27 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 225D112D810; Wed, 18 Apr 2018 00:27:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.921
X-Spam-Level:
X-Spam-Status: No, score=-0.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 ASugfqV_UuLG; Wed, 18 Apr 2018 00:27:23 -0700 (PDT)
Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 57D041270AE; Wed, 18 Apr 2018 00:27:20 -0700 (PDT)
Received: by ajax-webmail-ocmail02.zx.nicx.cn (Coremail) ; Wed, 18 Apr 2018 15:27:11 +0800 (GMT+08:00)
X-Originating-IP: [159.226.7.2]
Date: Wed, 18 Apr 2018 15:27:11 +0800
X-CM-HeaderCharset: UTF-8
From: 傅瑜 <fuyu@cnnic.cn>
To: ianfarrer@gmx.com
Cc: softwires@ietf.org, draft-ietf-softwire-map-radius@ietf.org
X-Priority: 3
X-Mailer: Coremail Webmail Server Version XT3.0.8 dev build 20171117(fcd8b4ed) Copyright (c) 2002-2018 www.mailtech.cn cnnic
X-SendMailWithSms: false
Content-Type: multipart/alternative; boundary="----=_Part_3255_1685458041.1524036431446"
MIME-Version: 1.0
Message-ID: <5c520d17.386.162d7a66e56.Coremail.fuyu@cnnic.cn>
X-Coremail-Locale: zh_CN
X-CM-TRANSID: AQAAf0BJUNxP89Za1dLsAA--.8289W
X-CM-SenderInfo: pix13q5fqqxugofq/1tbiAQATDiVCN3V+KwACsu
X-Coremail-Antispam: 1Ur529EdanIXcx71UUUUU7IcSsGvfJ3iIAIbVAYjsxI4VW3Jw CS07vEb4IE77IF4wCS07vE1I0E4x80FVAKz4kxMIAIbVAFxVCaYxvI4VCIwcAKzIAtYxBI daVFxhVjvjDU=
Archived-At: <https://mailarchive.ietf.org/arch/msg/softwires/A7FncziF3z2B2hcy4rUX5kUqbP4>
Subject: Re: [Softwires] WGLC on draft-ietf-softwire-map-radius-14 - 1 of 2
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 18 Apr 2018 07:27:26 -0000

Hi Ian,

 

Thank you for your reply. Please see below

 

Thanks

Yu

 

From: ianfarrer@gmx.com [mailto:ianfarrer@gmx.com]
Sent: Tuesday, April 17, 2018 2:52 PM
To:傅瑜
Cc: Softwires WG; draft-ietf-softwire-map-radius@ietf.org
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.