Hi Ian, Many thanks for the comprehensive response - I've extracted [1], [2] and [7] for further attention here - your proposals for all of the other items and nits are fine with me. I think the only open topic is [7], and I can live w/your proposed rephrasing for that even though I'd like to see a sentence of rationale added. > >[1] There are a number of places where SHOULD is used to refer to > > requirements in another RFC, e.g., the following text in section 5.1: [... snip ...] > [if] OK with the above proposals. I supplied new text for 5.1 - please also make the corresponding changes in 5.2.1 (twice) and 8.2, plus check whether this "SHOULD" problem occurs elsewhere. > >[2] Section 4. Lightweight 4over6 Architecture > > > > The consequence of this architecture is that the information > > maintained by the provisioning mechanism and the one maintained by > > the lwAFTR MUST be synchronized (See figure 2). The details of this > > synchronization depend on the exact provisioning mechanism and will > > be discussed in a companion document. > > > >I believe that this "companion document" needs to be cited as a > >normative reference. The above text's vague allusion to the specification > >of how to implement a "MUST" requirement is insufficient. > > [if] The synch mechanism is really down to how an operator has deployed > the service, the specific provisioning protocols in use etc. What about > the following wording change?: > > The consequence of this architecture is that the information maintained by > the provisioning mechanism and the one maintained by the lwAFTR MUST be > synchronized (See figure 2). The details of this synchronization depend > on the exact provisioning mechanism and protocols that are in use by the > operator. If no automated process for this synchronisation is in use, then > information in the provisioning systems and the lwAFTR MUST be > synchronised manually, e.g. by copying aligned configuration files to each > of the elements. That wording change is fine, and I prefer it to Ted's subsequent suggestion of shorter "out of scope" language. My primary concern was the reference to a "companion document" which lead to an obvious "where is that???" question. The new wording removes that reference and provides some useful information on how the required synchronization could be accomplished. > >[7] Also in Section 5.1 > > > > Unless an lwB4 is being allocated a full IPv4 address, it is > > RECOMMENDED that PSIDs containing the well-known ports (0-1023) are > > not allocated to lwB4s. > > > >Please explain why. Also, "well-known ports" is not the right term; > >I believe those are the "system ports", e.g., see: > > > >http://www.iana.org/assignments/service-names-port-numbers/service-names-p > >ort-numbers.xhtml > > [if] Reworded: > > Unless an lwB4 is being allocated a full IPv4 address, it is > RECOMMENDED that PSIDs containing the system ports (0-1023) are > not allocated to lwB4s. Why? Please add a sentence to explain, although I'll be ok if all that is done is the rewording. Thanks, --David > -----Original Message----- > From: ian.farrer@xxxxxxxxxx [mailto:ian.farrer@xxxxxxxxxx] > Sent: Wednesday, October 15, 2014 1:06 PM > To: Black, David; yong@xxxxxxxxxxxxxxxxxxxxxxxxx; sunqiong@xxxxxxxxxxxx; > mohamed.boucadair@xxxxxxxxxx; tena@xxxxxxxxxx; yiu_lee@xxxxxxxxxxxxxxxxx; gen- > art@xxxxxxxx; ops-dir@xxxxxxxx > Cc: ietf@xxxxxxxx; softwires@xxxxxxxx > Subject: Re: Gen-ART and OPS-Dir review of draft-ietf-softwire-lw4over6-10 > > Hi David, > > Many thanks for the review. Please see comments inline. > > Cheers, > Ian > > > > On 12/10/2014 00:30, "Black, David" <david.black@xxxxxxx> wrote: > > >This is a combined Gen-ART and OPS-DIR review. Boilerplate for both > >follows, > >and I apologize for it being a day late - United Airlines got me back to > >Boston after midnight last night on a plane w/o working WiFi. > > > >I am the assigned Gen-ART reviewer for this draft. For background on > >Gen-ART, please see the FAQ at: > > > ><http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > > >Please resolve these comments along with any other Last Call comments you may receive. > > > >I have reviewed this document as part of the Operational directorate's ongoing > >effort to review all IETF documents being processed by the IESG. These comments > >were written primarily for the benefit of the operational area directors. > >Document editors and WG chairs should treat these comments just like any other > >last call comments. > > > >Document: draft-ietf-softwire-lw4over6-10 > >Reviewer: David Black > >Review Date: October 10, 2014 > >IETF LC End Date: October 10, 2014 > >IESG Telechat date: October 16, 2014 > > > >Summary: This draft is on the right track, but has open issues > > described in the review. > > > >This draft describes an extension to Dual-Stack Lite that relocates the NAPT > >functionality from the centralized tunnel concentrator to the DS-Lite client > >- doing so has significant scalability benefits. The draft is generally > >readable although understanding why some of the processing needs to be done > >in the manner specified requires strong familiarity with both DS-Lite and NAPT. > > > >The draft is generally in good shape - I found three issues that I consider > >to be significant, the most important of which are sloppiness in use of > >RFC 2119 keywords, particularly in Section 5.1, and omission of what > >appears to be a necessary normative reference. > > > >Major issues (2): > > > >[1] There are a number of places where SHOULD is used to refer to requirement > >in another RFC, e.g., the following text in section 5.1: > > > > The DNS considerations described in Section 5.5 and Section 6.4 of > > [RFC6333] SHOULD be followed. > > > >This has the side effect of weakening any MUST requirement in the referenced > >RFC(s) to a SHOULD, which was probably not intended, and needs to be explicitly > >stated if it was intended. Here's a possible rephrasing: > > > > The DNS considerations described in Section 5.5 and Section 6.4 of > > [RFC6333] apply to Lightweight 4over6; lw4o6 implementations MUST > > comply with all requirements stated there. > > > >The additional places where this occurs are: > > > >- Section 5.2.1 (twice): > > > > For TCP and UDP traffic the NAPT44 implemented in the lwB4 SHOULD > > conform with the behaviour and best current practices documented in > > [RFC4787], [RFC5508], and [RFC5382]. If the lwB4 supports DCCP, then > > the requirements in [RFC5597] SHOULD be implemented. > > > >- Section 8.2: > > > > The lwB4 SHOULD implement the requirements defined in [RFC5508] for > > ICMP forwarding. > > [if] OK with the above proposals. > > > > > >[2] Section 4. Lightweight 4over6 Architecture > > > > The consequence of this architecture is that the information > > maintained by the provisioning mechanism and the one maintained by > > the lwAFTR MUST be synchronized (See figure 2). The details of this > > synchronization depend on the exact provisioning mechanism and will > > be discussed in a companion document. > > > >I believe that this "companion document" needs to be cited as a > >normative reference. The above text's vague allusion to the specification > >of how to implement a "MUST" requirement is insufficient. > > [if] The synch mechanism is really down to how an operator has deployed > the service, the specific provisioning protocols in use etc. What about > the following wording change?: > > The consequence of this architecture is that the information maintained by > the provisioning mechanism and the one maintained by the lwAFTR MUST be > synchronized (See figure 2). The details of this synchronization depend > on the exact provisioning mechanism and protocols that are in use by the > operator. If no automated process for this synchronisation is in use, then > information in the provisioning systems and the lwAFTR MUST be > synchronised manually, e.g. by copying aligned configuration files to each > of the elements. > > > > > >Minor issues (7): > > > >[3] The lack of discussion of management information is an > >omission. See A.2.2 below in the OPS-Dir review section of this email > >and the discussion in Section 3.2 of RFC 5706. A sentence pointing > >at an applicable MIB and/or YANG draft or drafts would suffice. > > [if] There is a draft for a softwire YANG model which is due to be > published shortly. We'll add an informative reference to this. > > > > >[4] Section 4. Lightweight 4over6 Architecture > > > > The solution specified in this document allows the assignment of > > either a full or a shared IPv4 address requesting CPEs. [RFC7040] > > provides a mechanism for assigning a full IPv4 address only. > > > >Please explain what entities would share the IPv4 address. For example, > >this is needed as a foundation for the statement in Section 8 that > >"ICMPv4 does not work in an address sharing environment without > >special handling [RFC6269]." > > [if] OK. Reworded version: > > The solution specified in this document allows the assignment of > either a full IPv4 address for a CPE, or a single IPv4 address which is > shared between multiple CPEs. [RFC7040] > provides a mechanism for assigning a full IPv4 address only. > > > > > >[5] Section 5.1. Lightweight B4 Provisioning with DHCPv6 > > > > For DHCPv6 based configuration of these parameters, the lwB4 SHOULD > > implement OPTION_S46_CONT_LW > > > >What are the consequences of not doing that? The could be addressed > >by changing that "SHOULD" to a "MUST", although I suspect that what's > >wanted here is a forward reference to the alternatives discussed in > >Section 7. > > [if] Rewording with: > > To configure these parameters using DHCPv6, the lwB4 MUST implement > OPTION_S46_CONT_LW. > > > > > >[6] Also in Section 5.1 > > > > If stateful IPv4 configuration or additional IPv4 configuration > > information is required, DHCPv4 [RFC2131] must be used. > > > >"must" -> "MUST" > > > > In the event that the lwB4's encapsulation source address is changed > > for any reason (such as the DHCPv6 lease expiring), the lwB4's > > dynamic provisioning process must be re-initiated. > > > >"must" -> "MUST" > > [if] OK > > > > >[7] Also in Section 5.1 > > > > Unless an lwB4 is being allocated a full IPv4 address, it is > > RECOMMENDED that PSIDs containing the well-known ports (0-1023) are > > not allocated to lwB4s. > > > >Please explain why. Also, "well-known ports" is not the right term; > >I believe those are the "system ports", e.g., see: > > > >http://www.iana.org/assignments/service-names-port-numbers/service-names-p > >ort-numbers.xhtml > > [if] Reworded: > > Unless an lwB4 is being allocated a full IPv4 address, it is > RECOMMENDED that PSIDs containing the system ports (0-1023) are > not allocated to lwB4s. > > > > > > > >[8] Still in Section 5.1 > > > > In the event that the lwB4 receives an ICMPv6 error message (type 1, > > code 5) originating from the lwAFTR, the lwB4 SHOULD interpret this > > to mean that no matching entry in the lwAFTR's binding table has been > > found. The lwB4 MAY then re-initiate the dynamic port-restricted > > provisioning process. The lwB4's re-initiation policy SHOULD be > > configurable. > > > >What happens if the lwB4 ignores the first "SHOULD"? > > > [if] Reword: > ...the lwB4 interprets this to mean that no matching entry in the lwAFTR's > binding table has been found, so the IPv4 payload is not being forwarded > by the lwAFTR. > > > > > > >[9] Section 8.1. ICMPv4 Processing by the lwAFTR > > > >This describes two approaches to ICMPv4 processing. Are there any others? > >If so, please add some text about them, otherwise, I suggest this change: > > > >OLD > > Additionally, the lwAFTR MAY implement: > > > > o Discarding of all inbound ICMP messages. > >NEW > > Otherwise the lwAFTR MUST discard all inbound ICMPv4 messages. > > [if] OK > > > > > > >Nits/editorial comments: > > > >-- Section 1. Introduction > > > > Basic Bridging BroadBand element: A B4 element is a function > > implemented on a dual-stack capable > > node, either a directly connected > > device or a CPE, that creates a > > tunnel to an AFTR. > > > >I suggest changing "a tunnel to an AFTR" to "an IPv4-in-IPv6 tunnel > >to an AFTR" for consistency with the AFTR definition. > > [if] OK > > > > >-- Section 5.2. Lightweight B4 Data Plane Behavior > > > > Internally connected hosts source IPv4 packets with an [RFC1918] > > address. > > [if] Reword with: > > Hosts connected to the customer's network behind the lwB4 source IPv4 > packets with an [RFC1918] address. > > > > > >Internal to what? Please explain. > > > >-- Section 6.2. lwAFTR Data Plane Behavior > > > > The lwAFTR MUST support hairpinning of traffic between two lwB4s, by > > performing de-capsulation and re-encapsulation of packets. The > > hairpinning policy MUST be configurable. > > > >Please explain "hairpinning" - it should suffice to add "from one lwB4 > >that need to be sent to another lwB4 associated with the same AFTR" > >after "de-capsulation and re-encapsulation of packets". > > [if] OK with the suggested wording. > > > > >-- Section 7. Additional IPv4 address and Port Set Provisioning > >Mechanisms > > > > In a Lightweight 4over6 domain, the binding information MUST be > > aligned between the lwB4s, the lwAFTRs and the provisioning server. > > > >"aligned between" -> "synchronized across" for consistency with use > >of forms of "synchronize" elsewhere in this draft. > > [if] OK > > > > >idnits found a few things to complain about: > > > >- The use of "the well-known range 192.0.0.0/29" in Section 5.1. This is > >ok, > > as it's describing DS-Lite use of that range that is documented > > elsewhere. If lw4o6 is using that range, an explanation ought to be > > added to Section 5.1. > > [if] lw4o6 doesn¹t use these > > > > >- Three references have been updated: > > > > == Outdated reference: A later version (-09) exists of > > draft-ietf-softwire-map-dhcp-07 > > > > == Outdated reference: draft-ietf-dhc-dhcpv4-over-dhcpv6 has been > >published > > as RFC 7341 > > > > == Outdated reference: A later version (-06) exists of > > draft-ietf-pcp-port-set-05 > > [if] All should now be fixed in v11 (posted earlier today) > > > > >--- Selected RFC 5706 Appendix A Q&A for OPS-Dir review --- > > > >A.1.1. Has deployment been discussed? > > > > Yes, this protocol is intended to improve scalability over the existing > > DS-Lite mechanism. > > > >A.1.2. Has installation and initial setup been discussed? > > > > No, there are vague references to a provisioning mechanism and > > synchronization functionality that need to be set up. See > > major open issue [2] above which calls out a missing normative > > reference that should address these topics. > > > >A.1.3. Has the migration path been discussed? > > > > No, but I suspect that this concern is inapplicable, as I think > > a carrier would not migrate from DS-Lite to lw4o6, but would > > deploy lw4o6 instead of DS-Lite. > > > >A.1.4. Have the Requirements on other protocols and functional > > components been discussed? > > > > Yes, but major open issue [1] is effectively in this area. > > > >A.1.6. Have suggestions for verifying correct operation been discussed? > > > > No, and they probably should be, as this protocol requires state > > synchronization among the lwB4, lwAFTR and the provisioning system, > > and is likely to exhibit problematic behavior if the relevant state > > information gets out of sync. > > > >A.1.9. Is configuration discussed? > > > > Yes, the draft does a good job of discussing what needs to be > > configured to set up the protocol (aside from state synchronization) > > and calling out protocol behavior aspects that should be configurable. > > > >A.2 Management > > > > This is really not discussed, and in particular the lack of discussion > > of management information is notable because this protocol has a > > different operational structure than DS-Lite. So, specifically: > > > > A.2.2. Is management information discussed? > > > > No, this is minor open issue [3]. A sentence pointing to applicable > > MIB and/or YANG draft(s) would suffice to address this. > > > >A.2.4. Is configuration management discussed? > > > > Yes - the discussion is ok, even though specific configuration mechanisms > > are not discussed. > > > >A.3. Documentation > > > > The protocol does have significant operational impacts on the Internet. > > > > The shepherd's writeup indicates that multiple implementations exist > > among which interoperability has been tested. > > > >Thanks, > >--David > >---------------------------------------------------- > >David L. Black, Distinguished Engineer > >EMC Corporation, 176 South St., Hopkinton, MA 01748 > >+1 (508) 293-7953 FAX: +1 (508) 293-7786 > >david.black@xxxxxxx Mobile: +1 (978) 394-7754 > >---------------------------------------------------- > >