I appreciate the review. I disagree that it needs a complete rewrite, but I agree that language work would be beneficial. I do believe that the RFC Editor will have an unusual level of changes, due to language issues.
On Feb 21, 2014, at 3:12 AM, Jari Arkko <[email protected]> wrote: > 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 set 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 the 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 >
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
