Thanks for the review, Elwyn. Joel, Fred, authors, any comments on this? Jari
On Jan 29, 2014, at 12:25 AM, 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. > > Document: draft-ietf-v6ops-nat64-experience-09.txt > Reviewer: Elwyn Davies > Review Date: 28 January 2014 > IETF LC End Date: 28 January 2014 > IESG Telechat date: (if known) - > > Summary: > Not ready. This document needs a serious rewrite with the assistance of a > mother tongue English speaker. I started doing some of this getting as far > as s3.1.4, however I came to the conclusion that significant parts of the > language were sufficiently unclear that I was unable to determine the > intended meaning. Accordingly I have abandoned the review and will have > another go assuming a rewrite is done. Please consider whether the title > should be modified as noted below. > > Major issues: > > Minor issues: > Title: The title is rather misleading since it the document actually > documents two suggested ways of deploying NAT64 as well as experience of > deploying these solutions. Maybe 'NAT64 Deployment Options and Experience'. > > s1: A reference to explain what PDP context etc means in an LTE environment > would be useful. > > s3.1.3: It is stated that placing the NAT64 (middlebox) in a centralized > location would 'reduce the diversity of log format'. I guess what is > possibly being said that is that the network should preferentially use just > one NAT64 box centrally placed rather than several (smaller) boxes at various > edge locations. I think this needs to be explained more clearly (assuming I > have it right). OTOH I would rather expect that most network owners would go > for a single species of NAT64 box so the diversity of log formats is really a > side issue. > > s5.2: The problem here is not specifically geo-location - and since we > normally don't have any mapping between topology and location this seems > inappropriate - but doing host identification (which is what RFC 6967 is > about. Shouldn't this section just be about host identification? > > s8, para 2: >> We configure ULAs as NAT64 prefixes on a NAT64-CGN. > So.. is this a mandatory requirement or just a possibility? > > Nits/editorial comments: > > s1, para 1: s/Internet/the Internet/ > > s1, para 2: s/simplify networks provisioning/simplify the provisioning of > networks/, s/confers some benefits to/confers some benefits on/, s/such > mobile/such a mobile/, s/if Long Term/if a Long Term/ > > s3.1.1: s/can be seen with better transparency features/can offer improved > transparency to <state who or what is offered the improved transparency> / > > s3.1.1: Expand A+P abbreviation. > > s3.3.1: s/IPv4 shortage/IPv4 address shortage/ > > ss3.1.2, 3.1.3 and 3.1.4: These are very long paragraphs. It would be good > to separate the various discussion points into separate paragraphs. > > s3.1.2: "..to enable access of IPv4 only applications" Presumably this is > access to applications running on the IPv4 side from applications on the IPV6 > side... Suggest > "to allow applications running on the IPv6 network to interact with > applications that can only use IPv4 communications or IPv6 applications that > need to communicate using literal IPv4 addresses." > > s3.1.2: s/discover NAT64 prefix/discover the NAT64 prefix/ > > s3.1.2: need a reference for BIND. > > s3.1.2: s/...(BIND) software supports the function./The ... (BIND) > implementation of NAT64 supports this discovery function./ > > s3.1.2:s/Operators should not/Users should not/ perhaps. > > s3.1.2: s/going to IPv4-only service/going to IPv4-only services/ > > s3.1.2: s/restrains NAT uses/restrains NAT usage/ > > s3.1.2: s/all traffic flows have to be traversed and translated./all traffic > flows have to traverse the NAT44 middlebox and be translated there./ > > s3.1.2: s/may serve a double roles, i.e. a translator and IPv6 forwarder./may > serve a dual role acting as both translator and IPv6 forwarder./ > > s3.1.2: s/Therefore, both IPv6 and IPv6 > > s3.1.2: > OLD: > In some sense, it encourages IPv6 transmission and restrains NAT uses > compared to NAT44(if used), on which all traffic flows have to be traversed > and translated. In some cases, NAT64-CGN may serve double roles, i.e. a > translator and IPv6 forwarder. In mobile networks, NAT64 is likely deployed > as the default gateway serving for all the IPv6 traffic. The traffic heading > to a dual-stack server is only forwarded on the NAT64. Therefore, both IPv6 > and IPv4 are suggested to be configured on the Internet faced interfaces of > NAT64. We tested on Top100 websites (referring to [Alexa] statistics). 43% of > websites are connected and forwarded on the NAT64 since those websites have > both AAAA and A records. With expansion of IPv6 supports, the translation > process on NAT64 will likely be faded. In addition, it should be noted the > DNS64-DNSSEC Interaction[RFC6147] may impact the DNS64 process. For example, > DNS64 will not work with the case, where there is a DNS query with the > "DNSSEC OK" (DO) bit s et and the "Checking Disabled" (CD) bit set received. > NEW: > In some sense, it encourages IPv6 transmission and restrains NAT usage > compared to system using NAT44 (if used), on which all traffic flows have to > traverse the NAT44 middlebox and be translated in passing. In some cases, > NAT64-CGN may serve a dual role as both translator and IPv6 forwarder. In > mobile networks, NAT64 is likely deployed as the default gateway serving all > the IPv6 traffic. The traffic heading to a dual-stack server is only > forwarded via the NAT64. Therefore, it is suggested [or may be RECOMMENDED] > that both IPv6 and IPv4 are configured on the Internet facing interfaces of > NAT64 middleboxes. We tested the configuration of the Top100 websites (as > identified in the [Alexa] statistics). 43% of websites are [Should this be > "would be"] connected and forwarded via NAT64 since those websites have both > AAAA and A records. With the expansion of IPv6 support, the need for the > translation process on NAT64 middleboxes will likely diminish. In addition, > it should be noted that t he interaction of DNS64 and DNSSEC [RFC6147] may impact the DNS64 process. For example, DNS64 will not work in the case where a DNS query is received that has the "DNSSEC OK" (DO) bit set and the "Checking Disabled" (CD) bit set. > > > s3.1.3: s/is problematic from multiple-vendor's equipment due to inconsistent > formats of log records./obtained from equipment supplied by multiple vendors > may be problematic due to inconsistent log formats./ > > s3.1.3: This gave me a bit of a laugh... So having got over my unstable user > experience (probably due to excessive consumption of beer..) > OLD: > Since the topology on each > path is different, it may cause unstable user experiences and some > degradation of Quality of Experience (QoE) when fallback to the other > protocol is not powerful enough. > NEW: > Since the routes taken by the two traffic sets may be different, user > experiences > may be inconsistent and there may be some > degradation of Quality of Experience (QoE) when fallback to the other > protocol is not sufficiently rapid. [or does this mean that the alternative > route > doesn't have enough capacity] > > Please clarify. > > [I gave up on language corrections at this point as it essentially needs a > serious rewrite.] > > s4.1, last para: Specifying 91.21% of traffic seems inappropriately exact. > > s6.1: It may well be that NAT64-CGN have an FTP ALG .. given the general > view that FTP shouldn't be used it seems peculiar that this is the only > default implementation! > Perhaps a comment about this (and maybe even TURNING OFF the FTP ALG) seems > like an option. > > > > > _______________________________________________ > 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
