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
