On Wed, Feb 21, 2018 at 12:27 PM, Benoit Claise <bcla...@cisco.com> wrote: > Dear all, > > I'm not the responsible AD for draft-ietf-opsawg-nat-yang but let me share > my view from a YANG point of view. > Do we really believe that the intended status of Standards Track of > Experimental will influence whether a YANG module is implemented? This > module will be implemented if it solves a business issue, full stop. The > indented status is not even relayed into YANG module. I mean: once extracted > from the RFC, the YANG module is not flagged as experimental because the > feature to be managed is experimental. > > From the 20000 foot view, going through the extra hurdle of splitting the > document because one of the managed features is experimental seems to me > like a distraction to me.
I fully agree with Benoit. While I'm technically the responsible AD, Benoit is the SME (and also happens to be right :-)) W > > My two cents. > > Now, if you really want to split the doc., please publish both at the same > time. > > Regards, Benoit >> >> On 2/7/18 03:14, mohamed.boucad...@orange.com wrote: >>> >>> 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? >> >> My preference would be a WG document for the reasons you state, but let >> me check with Warren and Ignas. >> >> Joe >> >>> Cheers, >>> Med >>> >>>> -----Message d'origine----- >>>> De : Joe Clarke [mailto:jcla...@cisco.com] >>>> Envoyé : mardi 6 février 2018 17:59 >>>> À : BOUCADAIR Mohamed IMT/OLN; 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 >>>> >>>> On 2/6/18 05:48, mohamed.boucad...@orange.com 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: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 >> >> . >> > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
