Re-, Please see inline.
Cheers, Med > -----Message d'origine----- > De : Tim Chown [mailto:[email protected]] > Envoyé : mardi 6 février 2018 10:38 > À : BOUCADAIR Mohamed IMT/OLN > Cc : [email protected]; [email protected]; > [email protected] > Objet : Re: Opsdir early review of draft-ietf-opsawg-nat-yang-10 > > Hi Med, > > > On 6 Feb 2018, at 09:02, [email protected] wrote: > > > > 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] > > == > > Well, I raise the question for consideration by the IESG [Med] Your initial comment was fair, Tim. ; while there's a > precedent here - and probably elsewhere - it feels odd having a Standards > Track document supporting an Experimental one. > > Could the NPTv6 definitions be extracted to a separate RFC, as you have done > with some other elements, or are they shared with Standards Track mechanisms? > [Med] NPTv6 part can be published in a separate document as an augment to draft-ietf-opsawg-nat-yang. That is indeed one possibility. Registering an entry in the IETF XML Registry assumes "Specification is Required" and adding a name in the "YANG Module Names" registry is based on "RFC Required". So having an experimental YANG document for NPTv6 would be OK. Another approach would be to remove the NPTv6 part from the main YANG module, but define the nptv6 augment in a dedicated section and make it clear that section is not normative. This will be easy to handle. Any preference? > >> 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. > > Again, it feels odd though looking at them. The alternative is to use a true > ULA prefix (roll the dice!). > [Med] Deal! > Tim _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
