Hi Joe, all, Thanks. Lets' then go that path.
A new version which addresses the comments from Tim (remove the NPTv6 part + some minor edits) is available at: https://datatracker.ietf.org/doc/draft-ietf-opsawg-nat-yang/?include_text=1 Tim, thank you for identifying this issue at this stage of the publication process. One logistic question for the NPTv6 document, though: Should it be published (1) as draft-ietf-ospawg-* given that its content was part of the document that was accepted by the WG and that passed the WGLC or (2) as an individual document that will be handed to the AD together with draft-ietf-opsawg-nat-yang? Cheers, Med > -----Message d'origine----- > De : Joe Clarke [mailto:[email protected]] > Envoyé : mardi 6 février 2018 17:59 > À : BOUCADAIR Mohamed IMT/OLN; Tim Chown > Cc : [email protected]; [email protected]; > [email protected] > Objet : Re: Opsdir early review of draft-ietf-opsawg-nat-yang-10 > > On 2/6/18 05:48, [email protected] wrote: > > 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. > > I do not have a strong preference, but I do think there will be > additional augmentations the NAT module, and so I lean more towards > another document as not to conflate the work. > > Joe > > > > > 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
