Tim, I started to implement your comments.
Please check the diff at: https://github.com/boucadair/draft-ietf-opsawg-nat-yang/blob/master/wdiff%20draft-ietf-opsawg-nat-yang-10.txt%20draft-ietf-opsawg-nat-yang-11-snptv6.pdf The content of the dedicated NPTv6 "informative section"/document would look like: https://github.com/boucadair/draft-ietf-opsawg-nat-yang/blob/master/nptv6-yang-00.txt Will proceed with one of the two once we hear back from the chairs. Cheers, Med > -----Message d'origine----- > De : mohamed.boucad...@orange.com [mailto:mohamed.boucad...@orange.com] > Envoyé : mardi 6 février 2018 11:49 > À : Tim Chown > Cc : ops-...@ietf.org; draft-ietf-opsawg-nat-yang....@ietf.org; > opsawg@ietf.org > Objet : RE: Opsdir early review of draft-ietf-opsawg-nat-yang-10 > > Re-, > > Either ways are easy to handle. I do a have a preference (dedicated > informative section). > > I will wait for instructions from the chairs about how to proceed. > > Thank you. > > Cheers, > Med > > > -----Message d'origine----- > > De : Tim Chown [mailto:tim.ch...@jisc.ac.uk] > > Envoyé : mardi 6 février 2018 11:17 > > À : BOUCADAIR Mohamed IMT/OLN > > Cc : ops-...@ietf.org; draft-ietf-opsawg-nat-yang....@ietf.org; > > opsawg@ietf.org > > Objet : Re: Opsdir early review of draft-ietf-opsawg-nat-yang-10 > > > > Hi, > > > > > On 6 Feb 2018, at 10:13, mohamed.boucad...@orange.com wrote: > > > > > > Re-, > > > > > > Please see inline. > > > > > > Cheers, > > > Med > > > > > >> -----Message d'origine----- > > >> De : Tim Chown [mailto:tim.ch...@jisc.ac.uk] > > >> Envoyé : mardi 6 février 2018 10:38 > > >> À : BOUCADAIR Mohamed IMT/OLN > > >> Cc : ops-...@ietf.org; draft-ietf-opsawg-nat-yang....@ietf.org; > > >> opsawg@ietf.org > > >> Objet : Re: Opsdir early review of draft-ietf-opsawg-nat-yang-10 > > >> > > >> Hi Med, > > >> > > >>> On 6 Feb 2018, at 09:02, mohamed.boucad...@orange.com wrote: > > >>> > > >>> Hi Tim, > > >>> > > >>> Thank you for the review. > > >>> > > >>> Please see inline. > > >>> > > >>> Cheers, > > >>> Med > > >>> > > >>>> -----Message d'origine----- > > >>>> De : Tim Chown [mailto:tim.ch...@jisc.ac.uk] > > >>>> Envoyé : lundi 5 février 2018 20:07 > > >>>> À : ops-...@ietf.org > > >>>> Cc : draft-ietf-opsawg-nat-yang....@ietf.org; opsawg@ietf.org > > >>>> 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? > > > > Either would be an improvement. My preference would be for the first one, > > given I recall you also have other complementary documents to the main one > > (and I think the YANG doctor originally asked whether there should be a > high > > level NAT model and then one model per NAT type). > > > > >>>> 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 > > > > > > > Regards, > > Tim _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
