> On 21 Feb 2018, at 21:03, Warren Kumari <[email protected]> wrote: > > On Wed, Feb 21, 2018 at 12:27 PM, Benoit Claise <[email protected]> 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 :-))
I raised the question in my ops-dir review on whether it was OK for a Standards Track document (draft-ietf-opsawg-nat-yang) to include definitions for an Experimental Track mechanism (NPT66). I don't personally have a strong view either way, but felt obliged to point out the discrepancy so we could get 'higher' advice on whether that was OK. It seems we now have that :) Tim > > >> >> 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, [email protected] 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:[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 >>> >>> . >>> >> > > > > -- > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/opsawg _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
