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.
- [Softwires] WGLC on draft-ietf-softwire-map-radiu… Yong Cui
- Re: [Softwires] WGLC on draft-ietf-softwire-map-r… ianfarrer
- Re: [Softwires] WGLC on draft-ietf-softwire-map-r… ianfarrer
- Re: [Softwires] WGLC on draft-ietf-softwire-map-r… Sheng Jiang
- Re: [Softwires] WGLC on draft-ietf-softwire-map-r… Liubing (Leo)
- [Softwires] Fw: RE: WGLC on draft-ietf-softwire-m… 傅瑜
- Re: [Softwires] WGLC on draft-ietf-softwire-map-r… xiechf.bri@chinatelecom.cn
- Re: [Softwires] WGLC on draft-ietf-softwire-map-r… maohaiyan (A)
- Re: [Softwires] WGLC on draft-ietf-softwire-map-r… Rajiv Asati (rajiva)
- Re: [Softwires] WGLC on draft-ietf-softwire-map-r… Peter Li
- Re: [Softwires] WGLC on draft-ietf-softwire-map-r… ianfarrer
- Re: [Softwires] WGLC on draft-ietf-softwire-map-r… 傅瑜
- Re: [Softwires] WGLC on draft-ietf-softwire-map-r… 傅瑜