> On 21 Feb 2018, at 21:03, Warren Kumari <war...@kumari.net> wrote:
> 
> 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 :-))

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, 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

_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Reply via email to