Hi Tim, Thank you for the review.
Please see inline. Cheers, Med > -----Message d'origine----- > De : Tim Chown [mailto:[email protected]] > Envoyé : lundi 5 février 2018 20:07 > À : [email protected] > Cc : [email protected]; [email protected] > Objet : Opsdir early review of draft-ietf-opsawg-nat-yang-10 > > Reviewer: Tim Chown > Review result: Has Nits > > I have reviewed this document as part of the Operational directorate's > ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written with the intent of improving the operational aspects of > the IETF drafts. Comments that are not addressed in last call may be included > in AD reviews during the IESG review. Document editors and WG chairs should > treat these comments just like any other last call comments. > > This document defines a YANG model for a wide variety of NAT functions, > including NAT44, NAT64, CLAT, SIIT and NPT66. > > The document is generally well written, and structured appropriately. There > are some very minor grammatical errors. Appropriate documentation prefixes > are > used in the Appendix of examples. > > I believe the document is Ready for publication, with Nits. > > Note: I am not a YANG doctor; I see that a separate YANG doctor review was > performed, and I assume that review has covered Section 3. > > General comment: > > This document is targeted to Standards Track, yet defines a YANG model for an > Experimental protocol, NPT66; is that acceptable? (I don't know, but I feel > the question needs to be raised, given also the text of > draft-ietf-v6ops-ula-usage-considerations-02.) [Med] The document defines NPTv6 as a "feature". It does not recommend nor argue against the use of NPTv6 per se. FWIW, I'm aware of one Standards Track RFC which lists NPTv6 as one of its deployment scenarios: RFC6887. == PCP can be used in various deployment scenarios, including: .. o IPv6-to-IPv6 Network Prefix Translation (NPTv6) [RFC6296] == > > Nits: > > p.4 - I think an Internal Host doesn't really "solicit" a NAT capability; > that > implies some messaging between the host and the NAT. Perhaps say "need to > use", > or something else. [Med] Works for me. Thanks. > > Appendix - it would perhaps be easier for the reader if the same > documentation > prefixes were used to refer to internal and external networks throughout the > examples, though this is only a minor style point. [Med] I updated where it makes sense. > > Section A.11 - the ULA prefixes used here are not (or very unlikely to be!) > true ULAs with randomised prefixes. Again, a style point. Perhaps some > documentation ULAs need to be defined elsewhere. [Med] As explicitly stated in titles ("Example of NPTv6 (RFC6296)" and "Connecting two Peer Networks (RFC6296)"), these examples are extracted from RFC6296. We are re-using the same prefixes as those in 6296-examples. _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
