Hi, Thanks for making this update. Here is a review of this version.
Cheers, Ian Overall The grammar/spelling and readability of the document throughout need to be checked and cleaned up. The terms MAP and S46 are used interchangeably throughout the document. It would be clearer if the term ‘S46’ was used for the general case of referring to all mechanisms and MAP (or MAP-E/MAP-T as appropriate) is used specifically when referring to the MAP mechanisms. Section 3 Figure 1 would be clearer if the different messages in fig 1 were numbered and the supporting text was structured as a numbered list relating to each of the messages. Figure 1 and Figure 2 are essentially the same with the exception of the DHCP solicit/request messages being removed from Fig 2. The intended purpose (from the context) of fig. 2 is to illustrate how the process works without RADIUS authentication. Fig. 2 doesn’t show this. Either fig 2 should show what the differences are to Fig 1, or Fig 2 can be removed and Fig 1 can be referenced. The idea of pre-configured, or caching of RADIUS learnt MAP (S46) configuration: In this situation, how is it possible to propagate updates to client provision made in the RADIUS server to the clients? As softwire mechanism rely on consistency between the BR configuration and client provisioning infrastructure, this makes it more likely that differences will occur which will relate to service outages. I’m also not clear on what the benefit of this caching is. Section 4 RFC7598 provides a table in Section 6 showing the valid combinations of options to be supplied for each softwire mechanism. A similar table for the corresponding RADIUS attributes would be useful. Section 4.3.2 There MUST be at least one S46-BR Sub option….. This is only true for MAP-E and lw4o6 provisioning. MAP-T requires the S46-DMR option. 4.3.4 The fields in the diagram and the descriptions below don’t match. 4.5 The table needs to be updated in line with the new attributes defined in this version. 6 Needs to be updated in line with the new attributes defined in this version. 7. (personal opinion) - I’m not sure that I would define the operator’s ‘closed network’ is inherently safer than other network environments. > On 17 Jun 2016, at 12:02, Yu Fu <f...@cnnic.cn> wrote: > > Hi all, > > As I had a presentation on IETF 94 meeting for > draft-ietf-softwire-map-radius-05, the softwire WG had a conclusion that this > draft should have the radius configuration solutions for MAP-E, MAP-T, > Lightweight4o6 all together in one draft as DHCP does. Please refer to the > minutes of the IETF 94 meeting as below: > https://www.ietf.org/proceedings/94/minutes/minutes-94-softwire > <https://www.ietf.org/proceedings/94/minutes/minutes-94-softwire> > > So we had a discussion with the authors of the > draft-sun-softwire-lw4over6-radext-01. We have merged > draft-ietf-softwire-map-radius-05 and draft-sun-softwire-lw4over6-radext-01 > into draft-ietf-softwire-map-radius-06. > > Your comments are appreciated for us. > Thanks > Yu > ------------------------------------------- > Yu Fu > f...@cnnic.cn <mailto:f...@cnnic.cn> > > > > -----Original Message----- > From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On > Behalf Of internet-dra...@ietf.org > Sent: Friday, June 17, 2016 5:39 PM > To: i-d-annou...@ietf.org > Cc: softwires@ietf.org > Subject: [Softwires] I-D Action: draft-ietf-softwire-map-radius-06.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Softwires of the IETF. > > Title : RADIUS Attribute for MAP > Authors : Sheng Jiang > Yu Fu > Bing Liu > Peter Deacon > Chongfeng Xie > Tianxiang Li > Filename : draft-ietf-softwire-map-radius-06.txt > Pages : 20 > Date : 2016-06-17 > > Abstract: > IPv4-over-IPv6 transition mechanisms provide both IPv4 and IPv6 > connectivity services simultaneously during the IPv4/IPv6 co-existing > period. The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) > options have been defined to configure Customer Edge (CE) in MAP-E, > MAP-T, and Lightweight 4over6. However, in many networks, the > configuration information may be stored in Authentication > Authorization and Accounting (AAA) servers while user configuration > is mainly from Broadband Network Gateway (BNG) through DHCPv6 > protocol. This document defines a Remote Authentication Dial In User > Service (RADIUS) attribute that carries CE configuration information > from AAA server to BNG. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-softwire-map-radius/ > <https://datatracker.ietf.org/doc/draft-ietf-softwire-map-radius/> > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-softwire-map-radius-06 > <https://tools.ietf.org/html/draft-ietf-softwire-map-radius-06> > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-map-radius-06 > <https://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-map-radius-06> > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/> > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org <mailto:Softwires@ietf.org> > https://www.ietf.org/mailman/listinfo/softwires > <https://www.ietf.org/mailman/listinfo/softwires> > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org <mailto:Softwires@ietf.org> > https://www.ietf.org/mailman/listinfo/softwires > <https://www.ietf.org/mailman/listinfo/softwires>
_______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
