Authors, you have a draft that will expire in a few weeks, as well as one or more substantive reviews to address. Please push a revision, and then we will do an adoption call so that we can discuss it further as a WG draft during the meeting in honolulu.
Thanks, Wes On 8/13/14, 7:38 AM, "Tom Taylor" <[email protected]> wrote: >Lee, thank you for the time you put into this. I won't be able to deal >with a lot of it personally because it requires my co-authors' >knowledge. However, based on the IPR discussion at the meeting, I think >we will split out deterministic CGN and let it go on its way as an >individual draft. I can do that step and respond to as much of your >review as I can. My co-authors can take the next step or advise me on >the remaining issues. > >Tom Taylor > >On 24/07/2014 4:02 PM, Lee Howard wrote: >> Doing my homework before the WG meeting this afternoon (and re-sending >>from >> the correct email address). . . >> >> This document needs significant work and reorganization. >> >> 1. Introduction >> You say: >> provide transparent routing to end hosts >> I think it should say: >> provide connectivity to end hosts >> >> Is it worth adding a sentence that these methods are only useful for >>address >> sharing methods, not NPT, and not encapsulation mechanisms? It may not >>be >> necessary. >> But, for instance, this sentence: >> The CGN may not do Network Address Port Translation (NAPT), but only >> Network Address Translation (NAT) [RFC3022 >> <http://tools.ietf.org/html/rfc3022> ]. >> >> THat's not an rfc2119 "may not," it's a description of one scenario. I >>had >> to read it four times to figure that out; maybe it would be clearer as: >>> The CGN might do Network Address Port Translation >>> (NAPT) without Network Address Translation (NAT) [RFC3022 >>> <http://tools.ietf.org/html/rfc3022> ]. In >>> this scenario, there is no concern about port assignment. When >>>NAPT is >>> involved, Š >> Then you can enumerate the "does" and "does not" cases. >> >> independently of the particular flavour should be independent of the >> particular flavour >> Section 2.1 Port Consumption on NAT64 >> >> This editorializing is unnecessary: >>> Thanks to its simplicity and efficiency, NAT64 will likely be >>> deployed widely. >> >> Also, >> That is, a NAT44 will be deployed in an >> IPv4-only environment. >> NAT44 + Native IPv6 is a perfectly reasonable and likely scenario, so >>this >> is untrue. But this whole paragraph reads like a sales pitch for >>NAT64: cut >> it out. >> Second paragraph: >> One of the authors did a test comparison of port consumption on NAT64 >> and NAT44. >> Can you just cite the study? Can you say, "A study of port consumption >> [portstudy]. . ." Though again, this whole study is only true to a >>point in >> time (though what version of the Alexa100 includes 43 sites with AAAA I >> don't know). >> >> NAT64 "provides everyone with incentives to use IPv6," >> What incentives? Does it buy ice cream for everyone who uses IPv6? >>Either >> explain, or, since defending the use of NAT64 is out of place in this >> document, remove. >> >> [as v6 transition progresses,] it will be possible to relax the >> multiplexing ratio of IPv4 address sharing. >> This is a good point. >> >> change of IPv4 address will cause >> renumbering of IPv6 addresses. >> I don't see how. But again, I don't think this is intended as a NAT >> discussion document, I thought it was just evaluating port allocation >> methods. Clean up that paragraph. >> >> It has been learned from subscribers' >> behaviors that the average number of sessions consumed by one >> user's device is around 200 to 300 ports. Several devices >>may >> appear behind a CPE. Administrators may configure a range >> with 1000 ports to each CPE in fixed networks. >> Avoid the passive voice. Can you cite the 200-300 number? Is that >>true in >> 2014, or for as long as this document is intended to be useful? Yes, >> administators may configure 1000 ports. Or 1001. Or 999. Maybe what >>you >> mean is: >> 1000 ports per subscriber household will provide enough room for >>multiple >> active users. Administrators should monitor usage to adjust this >>number if >> users are being limited by this number, or if usage is so low that fewer >> ports would be sufficient. >> >> non-contiguous port range for the >> sake of attack defense. >> I think you explain this later in the document, but a reference to what >>you >> mean here would help. >> A+P style [citation needed] >> >> 2.3.1 Use of the word "older" sounds perjorative. Do you mean to imply >> that NAT64 is obsolete? Both in the title and text. >> Stepping outside >> the boundaries of NAT64 for the moment, DS-Lite [RFC6333 >> <http://tools.ietf.org/html/rfc6333> ] refers to >> the cautions in [RFC6269 <http://tools.ietf.org/html/rfc6269> ] but >>does >> not specify any port allocation >> method. >> First, that's pretty informal language. Second, why point to DS-Lite >> pointing to RFC6269; why not just point to RFC6269? >> 2.3.2 Current Work on Stateless Transition Technologies >> The proposals made in Section 3 >> >><http://tools.ietf.org/html/draft-chen-sunset4-cgn-port-allocation-04#sec >>tio >> n-3> and Section 4 >> >><http://tools.ietf.org/html/draft-chen-sunset4-cgn-port-allocation-04#sec >>tio >> n-4> do not apply >> to the current work in progress because that work has gone in >>another >> direction. That work includes: >> Do we need to enumerate protocols that this work doesn't apply to? If >>so, >> then I think this document is making normative references to those >>protocols >> (since their port allocation methods could, potentially, change until >>they >> are published), which will delay publication until lw4over6, MAP-T, >>MAP-E, >> 4rd have all been published. Having said that, this may be a useful >> comparison of possible methods, but I would try to limit it to that. >> Sections 2.4.1 and 2.4.2 are excellent. >> 2.4.3 s/alllocation/allocation >> 3.1 US means U.S.? Americans have higher traffic profiles? >> 3.2 Remove sentence "Here is how dynamic allocation of port-ranges would >> work in greater detail. " >> 3.3 Section 11 of RFC6269 refers to fragmentation; you mean section 12. >> Is >> this section supposed to be a privacy considerations section? >> Discoverability? I think in the era of Pervasive Surveillance, >>reference to >> other IETF work is needed. Also, please refer to RFC6302. >> I'm not sure, though, that the discussion of server port logging is >> appropriate in a document about how to allocate ports in CGN. A >>mention of >> it makes sense, but evaluating the capability of different web servers, >>with >> a config guide, seems out of place. >> These "traceability" issues apply equally to all port allocation >>methods, >> right? Maybe a Privacy Considerations section at the end. >> I didn't review section 4, because I've reviewed it before. And I ran >>out >> of time. >> 5. Security Considerations needs a rewrite‹it completely ignores >>Section 4. >> That's all I have on this round. >> Lee >> >> >> >> >> >> >> _______________________________________________ >> sunset4 mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/sunset4 >> > >_______________________________________________ >sunset4 mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/sunset4 This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. _______________________________________________ sunset4 mailing list [email protected] https://www.ietf.org/mailman/listinfo/sunset4
