Thank you Elwyn very much for this review. I'm basing my IESG approval recommendation on this and my own review. (This is one of the documents that I have read due to personal interest in all of its detail, although I often rely mostly on the Gen-ART reviews.)
Elwyn: you also bring up some points that have been raised by other ADs in their IESG reviews. Do not be surprised if my IESG review does not raise all your issues. Jari On May 25, 2013, at 12:38 PM, Elwyn Davies <[email protected]> wrote: > 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. > > This is an updated version of the review which went out yesterday > without the summary and some belated thoughts on the connection to > DS-Lite. Apologies for the finger trouble. > > Document: draft-ietf-softwire-public-4over6-09 > Reviewer: Elwyn Davies > Review Date: 23 May 2013 > IETF LC End Date: 24 May 2013 > IESG Telechat date: 30 May 2013 > > Summary: Nearly ready for the IESG but there are a lot of nits and two > interelated significant issues that need to be resolved: > 1. Ensuring that it is clear that this is a historical description > of a mechanism that has been superseded; this should probably be > reflected in the status of the document being Historical rather than > Informational. > 2. The discussion of the use of DS-Lite as a fallback mechanism and/or > the mechanims being 'backwards compatible' with DS-Lite. Given that > this mechanism is not recommended for future deployments, the > discussion of DS-Lite is either documentation of what was actually > done in existing deployments or irrelevant complication/speculation > that is not needed in what is effectively a historical document. It > needs to be either made clear that DS-Lite is actually used in this > way or the whole matter can be removed. > > Major(ish) issues: > Purpose of the document: We only find out that this document > is a description of existing practice in CERNET2 in para 2 of section 1 > (OK that is quite close to the front). It is not recommended for future > deployments that should use the Unified CPE mechanism instead. At the > very least this should be repeated in the Abstract and be right up > front in the Introduction. Arguably this document should be classified > as Historical rather than Informational. > > Relation to DS-Lite: In s3 DS-Lite is mentioned as an alternative to > Public 4over6 in situations where IPv4 addresses are in short supply. > This is either irrelevant (as this mechanism is now deprecated) or > a statement of how it has actually been used. It should be made clear > which is the case. In s5 DS-Lite is suggested as a fallback mechanism > in case of certain failures. Again, is this dcoumentation of what has > actually happened or speculation on how it could be used? Finally, > ss7 and 8 claim that the DS-Lite RFC 6333 fragmentation and DNS > considerations apply. This may well be the case, but it seems > possibly anachronistic: does Public 4over6 pre- or post-date DS-Lite? > More interesting would be documentation of what was actually done in > CERNET2 to meet these considerations. > > Minor issues: > It would be desirable to emphasize that (I assume) 'public' is used as a > synonym for 'globally routable' or 'globally unique'. Looking closely at > RFC 1918, the term 'public address' is not used as an antonym for > 'private address' (as opposed to 'private host' and 'public host'). RFC > 1918 states that public hosts are expected to use 'globally unique' (and > hence 'globally routable') addresses. > > Abstract, last sentence: > s/the allocation of full IPv4 address over IPv6 network/the allocation > and distribution of globally routable IPv4 addresses over the provider's > IPv6 network/ > > Subsequent to writing this I see from s1, para 3/4 that 'full IPv4 > address' is being used as a 'term of art' meaning that the user is free > to use the address with any port number (as opposed to a > 'port-restricted address'). The reader of the abstract would not > understand this implication I think. Suggest making the substitution: > NEW: > the allocation and distribution over the provider's IPv6 network of > globally routable IPv4 addresses that can be used with any port number > > Since the term 'full (IPv4) address' is used several times in the > document it needs to be defined. Perhaps I could suggest using > 'unrestricted' instead of 'full' ('full' seems to imply the whole 32 > bits rather than just a prefix which I don't think is the intention of > the term). > > s7/s8: RFC 6333 talks about B4 and AFTR elements: How does this map > into the elements in this draft? In particular referring to s5.5 of RFC > 6333, do both CE and BR need DNS proxies? I am not sure that just > referencing RFC 6333 is sufficient here, but with the mapping explained > it may be adequate. > > s10: This section should probably refer to the security considerations > of RFC 6333 in the case of fallback to DS-lite. > > s10: Some variant of the RFC 6333 logging issue is probably needed since > the IPv4 addresses mare allocated to CEs and I suspect that there needs > to be a tie between the DHCP logging and the bindings. > > s10: Is there any way for a bad actor to 'steal' a CE IPv4 address? > > Does this document need a (brief) section on routing for the IPv4 > addresses? (Not sure if this is really needed). > > > Nits/editorial comments: > General: s/hub and spokes/hub and spoke/ (is traditional I think) > > Abstract: s/When the service provider networks/When service providers' > networks/ > s/uses IPv4-over-IPv6 tunnel as basic method to traverse/uses an > IPv4-over-IPv6 tunnel as the basic method for traversing/ > > > Abstract, last sentence: Expand ICP acronym. > > s1: Be consistent in use of 'user-side' or 'user side' (2 instance of > each currently). [I think the RFC Editor will probably prefer > 'user-side'.] > > s1: There ought to be a reference to RFC 2473 regarding IPV4-in-IPv6 > tunnelling. > > s1, para 1: s/still a functionality required/still required/ > s/IPv4-only/the IPv4-only/ > s/this type of IPv4 services./this type of IPv4 service./ > > s1, para 2: Probably s/Binding approach/binding approach/ - it is only > capitalized at the start of sentences in the bmk draft. > > s1, para 3: Expand ISP acronym. > > s1, para 3, last sentence: > OLD: > as well as save the IPv4 address resource > from being assigned all over the network > NEW: > as well as avoiding the need to deploy scarce IPv4 address resources > throughout the network. > > s1, para 4, sentence 1: s/are developed/have been developed/ > > s1. para 4, sentence 3: s/Further more/Furthermore/ > > s1, para 4, sentence 4: > OLD: > operating system could support the mechanism smoothly, while > transparency on upper-layer applications is guaranteed. > NEW: > in general, operating systems are able to support the mechanism > natively, while > transparency is guaranteed for upper-layer applications. > > s1, para 4, sentence 5: s/which/that/ > > s1, para 5: s/operation/operational/, s/other: end user IPv4/other; the > end user's IPv4/ (note semi-colon instead of colon), s/in on-demand > style/in an on-demand style/, s/in the way of/being/ > > s1, para 6: s/IPv4-over-IPv6 tunnel/IPv4-over-IPv6 tunnelling/ > > s1, last para: s/are maintained/is maintained/ > > s2, Public 4over6: > OLD: > Public 4over6 > supports bidirectional communication between IPv4 Internet and IPv4 > hosts or customer networks in IPv6 access network, by leveraging > IPv4-in-IPv6 tunnel and public IPv4 address allocation over IPv6. > NEW: > Public 4over6 > supports bidirectional communication between the global IPv4 > Internet and IPv4 > hosts or customer networks via an IPv6 access network, by leveraging > IPv4-in-IPv6 tunnelling [RFC2473] and public IPv4 address allocation > over IPv6. > > s2, border relay: > OLD: > 4over6 Border Relay (BR): A router functioning as the border relay > in > Public 4over6 environment. 4over6 BR is the IPv4-in-IPv6 tunnel > concentrator located in IPv6 ISP network. It is a dual-stack router > which connects to both the IPv6 ISP network and IPv4 Internet. The > 4over6 BR also works as a DHCPv4 over IPv6 > [I-D.ietf-dhc-dhcpv4-over-ipv6] server/relay for assigning public > IPv4 address to 4over6 CEs. > > NEW: > 4over6 Border Relay (BR): A router functioning as the border relay > in > the Public 4over6 environment. A 4over6 BR is the IPv4-in-IPv6 > tunnel > concentrator located in the IPv6 ISP network. It is a dual-stack > router > which connects to both the IPv6 ISP network and the IPv4 Internet. > The > 4over6 BR also works as a DHCPv4 over IPv6 > [I-D.ietf-dhc-dhcpv4-over-ipv6] server/relay for assigning and > distributing a public > IPv4 address to 4over6 CEs. > > s3, para 1: Are the customer networks necessarily LANs? 'private' might > be a better term? > Expand acronym LAN (whether or not as it appears in 'home LAN'). > Comment also applies to > Figure 1. > > s3, para 1: s/connected to IPv4 Internet/connected to the IPv4 Internet/ > > s3, para 1: s/border relays/Border Relays/ (or use acronym BR that you > defined). > > Figure 1: Would be a little clearer if the height of the BR box was > expanded to > 7 lines so the connections to the CEs were not at the corners of the > box. > > s3, para 2: Explicitly associate DS-Lite acronym with Dual-Stack Lite. > > s3, para 2: s/which switches/that switches/ > > s3, para 2: Might be good to emphasise that you are talking about > globally > routable IPv4 address resource. > > s3, para 2: s/so much/so many/ > > s3, para 2: Expand acronym CGN. > > s3, para 2: > OLD: > A > typical case of the high-end users that could use Public 4over6 is > IPv4 application server. Full, public IPv4 address brings > significant convenience in this case, which is important to IPv6 > transition for ICPs. The DNS registration can be direct using > dedicated address; the access of the application service can be > straightforward, with no translation involved; there will be no need > to provide NAT traversal mechanisms for incoming traffic, and no > special handling is required for well-known ports. > NEW: > A > typical use case for high-end users that could use Public 4over6 is > an IPv4 application server. Using a full (unrestricted), public > IPv4 address brings > significant advantages in this case, which is important for > transitioning > ICPs to IPv: > - The DNS registration can be direct using a dedicated address; > - Access for clients of the application service can be > straightforward, > with no translation involved; > - There will be no need to provide NAT traversal mechanisms for > incoming traffic, and no special handling is required for > well-known ports. > > s4.1, bullet 1: s/the information of/knowledge of/, s/by DHCPv6/using > DHCPv6/ (possibly) > > s4.2, para 2: s/enables DHCPv4 message/allows DHCPv4 messages/, > s/between BR and CE/between the BR and the relevant CE/, > s/to support that/needed to support this operation/ > > s4.2, last para: > OLD: > While regular users would probably take DHCPv4 over IPv6, the manual > configuration is usually seen in two cases: application server, > which > requires a stable IPv4 address, and enterprise network, which > usually > requires an IPv4 prefix rather than one single address (Note that > DHCPv4 does not support prefix allocation). > > NEW: > While regular users would probably opt for DHCPv4 over IPv6, the > static > configuration is particularly applicable in two cases: for > application servers, which > require a stable IPv4 address, and for enterprise networks, which > usually > require an IPv4 prefix rather than one single address (Note that > DHCPv4 does not support prefix allocation). > > s5, para 1: s/or DHCPv6 option/or via a DHCPv6 option/ > > s5, para 2: > OLD: > The CE regards the BR as DHCPv4-over-IPv6 > server/relay for public IPv4 address allocation, whose IPv6 address > is learned by the CE as described above. > NEW: > The CE regards the BR as its DHCPv4-over-IPv6 > server/relay, which is used to obtain its public IPv4 address > allocation; its IPv6 address > is learned by the CE as described above. > > s5, para 3: s/DHCPv4 over IPv6/DHCPv4-over-IPv6/ (I think). > > s5, para 4: > OLD: > The decapsulation on 4over6 CE is simple. When receiving > an IPv4-in-IPv6 packet, the CE just removes the IPv6 header, and > either hands it to upper layer or forward it to customer network > according to the IPv4 destination address. > NEW: > The decapsulation on the 4over6 CE is simple. When receiving > an IPv4-in-IPv6 packet, the CE just removes the IPv6 header, and > either hands it to a local upper layer or forwards it to the > customer network > according to the IPv4 destination address. > > s5, para 5: Expand NAPT acronym. > > s5, para 6: s/necessarily/necessary/ > > s5, para 7: s/4over6 CE supports/The 4over6 CE supports/, > s/employ Well-Known/employ the Well-Known/, > Expand B4 acronym, > s/for instance, the DHCPv4 over IPv6/for instance, if the > DHCPv4-over-IPv6/ > > s6, para 1: s/4over6 BR/The 4over6 BR/, > s/to provide correct/to provide the correct/, > s/validate/validating/ > > s6, bullet 1: s/collocated/co-located/ or 'colocated', > s/delete/deletes/ > > s6, bullet 2: Expand TRA acronym > > s12: This section would normally be called 'Contributors'. > > s13: I think I-D.ietf-dhc-dhcpv4-over-ipv6 is a normative reference. > > s13.1: Requires a reference to RFC 2473. RFCs 4925, 4966, 5549, and > 5565 are not referenced currently. > > > _______________________________________________ > Gen-art mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
