I am the assigned Gen-ART reviewer for draft-ietf-v6ops-nap-02.txt. For background on Gen-ART, please see the FAQ located at:
<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>. Please wait for direction from your document shepherd or AD before posting a new version of the draft. The document shepherd for this draft is David Kessens <[EMAIL PROTECTED]>. The version of this draft that I reviewed can be found at: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-nap-02.txt This document does not appear to me to be ready to publish at this point. My comments, questions and nits are below... COMMENTS: ======== A few general comments (ranging from good to bad) and one, more specific, comment: -------------------------------------------------------------------- In general, I felt that this document will be very useful as a compendium of "NAT replacement techniques" for use with IPv6. The content is very good, generally, and it forms a very strong basis for a later BCP that describes what actually gets done in real IPv6 networks - especially including the real solutions it identifies as needed in section 6 ("IPv6 Gap Analysis"). I want to thank the authors for taking on this work. ==================================================================== At some point, we will probably have to have one or more BCPs to complete the task that this document sets. I believe this is already either stated, or implied, in section 6. ==================================================================== As a general observation, I find that the pronounced tendency to "assign blame" for current NAT use to "marketing departments", "marketing pronouncements", "marketing campaigns" and "messages", references to "marketed benefits", hype coming out of "product marketing", etc. - leaves a distinctly metallic after-taste in my digestive aparatus. In fact, it is unecessarily antagonistic and offensive. "Market acceptance" and "market perceived benefits" are fair and reasonable observations about the industry, and do not attempt to "assign blame" for the observed behaviors. It is often difficult to determine whether market perceptions are being driven by marketing campaigns, or driving them. In the case of NAT usage in the Internet, however, I think it is at least fair to speculate that market perceptions may have initially driven the "marketing pronouncements", given that NAT has been around since well before the Internet became important enough to attract much in the way of "marketing campaigns". In any case, however, I can imagine no useful purpose that might be served by including these apparent accusations. I suggest that a sweep should be made of the document to remove all such statements, or - at least - reduce the degree to which they seem to have been made unecessarily, and offensively, vituperative. As an example, the "Security Considerations" section refers to "the misleading nature" of claims the same section attributes to product marketing departments as having been previously documented in RFCs 2663 and 2993. In a cursory look at both of those RFCs, I find RFC 2993 to contain a couple of references to "market" but neither of these RFCs makes any references to "marketing", or to "misleading" statements. I strongly suspect that what was good enough for those existing RFCs is good enough for this proposed one. ==================================================================== Section 2.2 can be substantially reduced, if text that is unrelated to describing the use of NAT and IPv4 for the purpose indicated in the section title, is simply removed. For example, generalizations about the effectiveness of firewalls in providing security, comments (or observations) about distributed security mechanisms and even the effectiveness of address translation in the degenerate case may have something to do with weakening the case for using NAT, but they have nothing much to do with perceived benefits of actually using NAT. Statements that make generalization and judgements about the utility of NAT in achieving perceived benefits, are strangely out of place in a section labeled "Perceived Benefits of NAT and its Impact on IPv4". Perhaps these should be included in a different section (for example, similar text is already included in section 4.2 - "IPv6 and Simple Security"). QUESTIONS: ========= In the second paragraph of section 2.5 (only sentence), a little punctuation (and an article or two) may be needed to help with parsing. For example, I believe what you tried to say was: "Another benefit is<,> due to the usage of independent addresses on <a> majority of the network infrastructure<,> there is an increased ability to change provider<s> with less operational difficulties." (<text/characters> were added to your existing text) Is this, in fact, what you were trying to say? ==================================================================== A similar problem exists with a sentence in section 2.6 (bottom of page 9 and top of page 10) - to wit: Forced into this limiting situation<,> such customers can rightly claim that <-> despite the optimistic predictions of mathematical models <-> the global pool of IPv4 addresses is effectively already exhausted, especially for larger enterprises. (again, <text/characters> were added to your existing text) Is this - also - a correct interpretation of what you're saying? ==================================================================== Strictly as an observation, I am reasonably comfortable in saying that using ULAs within a private network to communicate with hosts that need to generate external traffic (e.g. - proxy devices), that maintain both an ULA and one or more global addresses - is likely to be indistinguishable, in practice, from NAT. Yet this is what the draft appears to recommend in the paragraph at the top of page 16. Is this not true (i.e. - either that the distinction is small, or that this is what is recommended in the indicated paragraph)? ==================================================================== Have the authors considered that the use of time-based 'Untraceable' IPv6 addresses might have some impact on the ability of enterprises to monitor the behavior of users within their own network? This ought to be a consideration, for instance, in section 5.1 ("Medium / large private networks") in the case studies section (5). If the enterprises are unlikely to find this practicable, then it is not very likely to be used in this case. ==================================================================== In the SOHO network case, how do you envision that the use of either (or both) DHCPv6-PD or a statically assigned IPv6 address range will work with a business providing content (via a file server and one or more proxy devices) where the content storage is to be kept private and access to it is via high-speed proxies (perhaps providing secure access to clients)? Does the SOHO user need to define external name-service mappings to the ISP, or do you anticipate that the ISP will allow the SOHO to update the ISP's DNS entries directly? ==================================================================== As in section 5.1, how likely is it that an ISP will allow a single user to "enable IPv6 privacy extensions"? That is, given potential for ISP liability for untraceable user behavior, isn't it likely an ISP will explicitly disallow this usage (refering to section 5.3)? ==================================================================== NITS: ==== First paragraph of section 1 ("Introduction") contains the following partial statement "... driven a perception hat some connectivity ..." - "hat" should be "that"? ==================================================================== In the last paragraph of section 4.1, the sentence beginning "In the very simple case there is ..." should be either "In a very simple case, there is ..." or "In the simplest case, there is ..." - unless you are sure that there is only one "very simple case" and that it is not the "simplest case". ==================================================================== First sentence in the paragraph at the bottom of page 14, and top of page 15, "... a given set configuration rules ..." - should this be "... a given set <of> configuration rules ..."? ==================================================================== I believe the convention for including very large numbers in text would result in the paragraph in section 4.6 starting as follows: "IPv6 provides sufficient space to completely avoid the need for overlapping address space, i.e. - 340,282,366,920,938,463,463,374,607,431,768,211,456 - or about 3.4*10^38 total possible addresses." For similar (readability) reasons, this number should be taken out of the table on page 5. ==================================================================== I recommend the following changes to the first two sentences in the second paragraph of section 4.7 (last paragraph on page 17): "The IPv6 address space allocated by the ISP will be dependent upon the connecting Service <P>rovider. This may result in a renumbering effort if the network changes from <one> Service Provider <to another>." ==================================================================== First sentence, section 5 ("Case Studies") - change "... categories of network ..." to "... categories of network<s> ..." Second sentence, same paragraph, change "... each of these category of networks ..." to "... each of these categories of networks ..." ==================================================================== Second paragraph in section 5.4 ("ISP/Carrier Customer Networks" - beginning "When IPv6 NAP is ...") - for readability, this paragraph should be broken into three different paragraphs, one for each of the three domains. (The RFC Editor would probably fix this) ==================================================================== First sentence, second paragraph - "As an alternative, some work <is being done / could be done?> in Mobile IP to define a policy message where a mobile node would learn from the Home Agent." _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
