Hi, Thanks, let's see what the chairs say. Obviously happy to go with their advice/decision.
Tim > On 6 Feb 2018, at 13:20, [email protected] wrote: > > Tim, > > I started to implement your comments. > > Please check the diff at: > https://github.com/boucadair/draft-ietf-opsawg-nat-yang/blob/master/wdiff%20draft-ietf-opsawg-nat-yang-10.txt%20draft-ietf-opsawg-nat-yang-11-snptv6.pdf > > > The content of the dedicated NPTv6 "informative section"/document would look > like: > https://github.com/boucadair/draft-ietf-opsawg-nat-yang/blob/master/nptv6-yang-00.txt > > > Will proceed with one of the two once we hear back from the chairs. > > Cheers, > Med > >> -----Message d'origine----- >> De : [email protected] [mailto:[email protected]] >> Envoyé : mardi 6 février 2018 11:49 >> À : Tim Chown >> Cc : [email protected]; [email protected]; >> [email protected] >> Objet : RE: Opsdir early review of draft-ietf-opsawg-nat-yang-10 >> >> 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
