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 >>> > _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
