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:[email protected]] > Envoyé : mardi 6 février 2018 11:17 > À : BOUCADAIR Mohamed IMT/OLN > Cc : [email protected]; [email protected]; > [email protected] > Objet : Re: Opsdir early review of draft-ietf-opsawg-nat-yang-10 > > Hi, > > > On 6 Feb 2018, at 10:13, [email protected] wrote: > > > > 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? > > 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 [email protected] https://www.ietf.org/mailman/listinfo/opsawg
