Subject: [OPSAWG] Opsdir early review of draft-ietf-opsawg-nat-yang-10

From: Tim Chown <[email-masked]>
Date: Mon, 05 Feb 2018 11:07:06 -0800

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.)

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.

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.

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.

---

From: <[email-masked]>
Date: Tue, 6 Feb 2018 09:02:30 +0000

Hi Tim, 

Thank you for the review. 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Tim Chown [mailto:[email-masked]]
> Envoyé : lundi 5 février 2018 20:07
> À : [email-masked]
> Cc : [email-masked]; [email-masked]
> Objet : Opsdir early review of draft-ietf-opsawg-nat-yang-10
> 
> Reviewer: Tim Chown
> Review result: Has Nits
> 

[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]
==

> implies some messaging between the host and the NAT. Perhaps say "need to

[Med] Works for me. Thanks.

> examples, though this is only a minor style point.

[Med] I updated where it makes sense. 

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

---

From: Tim Chown <[email-masked]>
Date: Tue, 6 Feb 2018 09:38:11 +0000

Hi Med,

> On 6 Feb 2018, at 09:02, [email-masked] wrote:
> 
> Hi Tim, 
> 

Well, I raise the question for consideration by the IESG; 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] 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 tho…

Again, it feels odd though looking at them. The alternative is to use a true ULA prefix (roll the dice!).  

Tim

---

From: <[email-masked]>
Date: Tue, 6 Feb 2018 10:13:48 +0000

Re-,

Please see inline.

Cheers,
Med

> De : Tim Chown [mailto:[email-masked]]
> Envoyé : mardi 6 février 2018 10:38
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : [email-masked]; [email-masked];
> [email-masked]
> Objet : Re: Opsdir early review of draft-ietf-opsawg-nat-yang-10
> 
> Hi Med,
> 
> 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? 

> > [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.
> 

[Med] Deal!

---

From: Tim Chown <[email-masked]>
Date: Tue, 6 Feb 2018 10:17:10 +0000

Hi,

> On 6 Feb 2018, at 10:13, [email-masked] wrote:
> 
> Re-,
> 
> Please see inline.
> 
> Cheers,
> Med
> 

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).  

>> ULA prefix (roll the dice!).

Regards,
Tim

---

From: <[email-masked]>
Date: Tue, 6 Feb 2018 10:48:41 +0000

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

> Envoyé : mardi 6 février 2018 11:17
> >>>> comments were written with the intent of improving the operational
> aspects
> >> of
> >>>> are some very minor grammatical errors. Appropriate documentation
> prefixes
> >>>> are
> >>>> This document is targeted to Standards Track, yet defines a YANG model
> for
> >> an
> >>> [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.
> >>>
> >>> ==
> > [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.
> >>>
> >> 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

---

From: <[email-masked]>
Date: Tue, 6 Feb 2018 13:20:38 +0000

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

> De : [email-masked] [mailto:[email-masked]]
> Envoyé : mardi 6 février 2018 11:49
> À : Tim Chown
> Objet : RE: Opsdir early review of draft-ietf-opsawg-nat-yang-10
> 
> Re-,
> 
> > >>>> Experimental protocol, NPT66; is that acceptable?  (I don't know, but
> I
> > >> feel
> > >>>> prefixes were used to refer to internal and external networks
> throughout
> > >> the

---

From: Tim Chown <[email-masked]>
Date: Tue, 6 Feb 2018 13:31:23 +0000

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-masked] wrote:
> 
> Tim,
>

---

From: Joe Clarke <[email-masked]>
Date: Tue, 6 Feb 2018 11:59:11 -0500

> 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

---

From: <[email-masked]>
Date: Wed, 7 Feb 2018 08:14:30 +0000

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?

Cheers,
Med

> De : Joe Clarke [mailto:[email-masked]]
> Envoyé : mardi 6 février 2018 17:59
> À : BOUCADAIR Mohamed IMT/OLN; Tim Chown

---

From: "t.petch" <[email-masked]>
Date: Wed, 7 Feb 2018 12:00:39 -0000

While you are at it, you might like to note

s1.1
/ A NAPT my use /A NAPT may use /

  feature siit {
  description
    ......
       The translator must support the stateless address mapping
       algorithm defined in RFC6052, which is the default behavior.";
    reference
      "RFC 7915: IP/ICMP Translation Algorithm";

If the algorithm in RFC6052 must be supported, I would expect this to
appear in the Reference clause

 list nat64-prefixes {
.....
            Destination-based Pref64::/n is discussed in
            Section 5.1 of [RFC7050]). For example:
            192.0.2.0/24 is mapped to 2001:db8:122:300::/56.
            198.51.100.0/24 is mapped to 2001:db8:122::/48.";
         reference
           "Section 5.1 of RFC7050.";

I see no RFC7050 in the Reference section of the I-D

        leaf logging-enable {
....
          reference
            "Section 2.3 of RFC 6908 and REQ-12 of RFC6888.";
        }

I see no RFC6908 in the Reference section of the I-D

Tom Petch

----- Original Message -----
From: <[email-masked]>
To: "Joe Clarke" <[email-masked]>; "Tim Chown" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Wednesday, February 07, 2018 8:14 AM
Subject: Re: [OPSAWG] Opsdir early review of
draft-ietf-opsawg-nat-yang-10

> 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_tex
t=1
> 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?

---

From: <[email-masked]>
Date: Wed, 7 Feb 2018 12:35:10 +0000

Hi Tom, 

Thank you for the careful review. 

Please see inline. 

Cheers,
Med

> De : t.petch [mailto:[email-masked]]
> Envoyé : mercredi 7 février 2018 13:01
> Objet : Re: [OPSAWG] Opsdir early review of draft-ietf-opsawg-nat-yang-10
> 

[Med] Fixed.

> appear in the Reference clause

[Med] RFC6052 is not cited because it is already listed as a normative reference in "RFC 7915: IP/ICMP Translation Algorithm". I thought this is redundant. No?

> I see no RFC7050 in the Reference section of the I-D

[Med] Fixed. 

What is strange, is that when I run idnits, I do have this error:  

  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

  == Unused Reference: 'RFC7050' is defined on line 3585, but no explicit
     reference was found in the text
     '[RFC7050]  Savolainen, T., Korhonen, J., and D. Wing, "Discovery of...' 

It seems that idnits does not look at the citations in the YANG module.

I made this change to cite that RFC outside the YANG module: 

OLD: 
   o  Stateful NAT64

NEW: 
   o  Stateful NAT64 (including with destination-based Pref64::/n
      RFC7050])

> I see no RFC6908 in the Reference section of the I-D

[Med] Fixed. Thanks. 

Idem as above. I made this change to make idnits happy:

OLD: 
   This YANG module allows to instruct a NAT function to enable the
   logging feature.

NEW:
   This YANG module allows to instruct a NAT function to enable the
   logging feature (Section 2.3 of [RFC6908] and REQ-12 of [RFC6888]).

---

From: Joe Clarke <[email-masked]>
Date: Wed, 7 Feb 2018 10:45:27 -0500

> 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 t…

My preference would be a WG document for the reasons you state, but let
me check with Warren and Ignas.

Joe

---

From: "t.petch" <[email-masked]>
Date: Wed, 7 Feb 2018 16:47:49 -0000

Med

Looks good.  Two loose ends.

On RFC6052 being a Normative reference from RFC7915 and so not needing
further citing, well yes, I suppose so:-)

On idnits and RFC7050, you cannot have an RFC style reference such as
[RFCnnnn] in the YANG module, with the underlying <a href= ... > in the
html version, because the YANG module must be capable of existing
outside the RFC, in plain text and not in HTML.  This is what
" Section 5.1 of [RFC7050]).  "
looks like to me, an attempt to create an HTML anchor that cannot exist
in  plain text YANG module.  I do not know if idnits is clever enough to
recognise a YANG (or MIB or ... ) module and know that RFC style
references cannot appear in it, although the character string 'RFC nnnn'
or 'RFCnnnn' can do so.

So if you have RFC nnnn in Normative or Informative References, you must
have [RFCnnnn] somewhere in the text of the RFC outside the YANG module;
and vice versa.

Tom Petch

----- Original Message -----
From: <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Wednesday, February 07, 2018 12:35 PM
Subject: RE: [OPSAWG] Opsdir early review of

> [Med] RFC6052 is not cited because it is already listed as a normative
reference in "RFC 7915: IP/ICMP Translation Algorithm". I thought this
is redundant. No?

---

From: <[email-masked]>
Date: Thu, 8 Feb 2018 06:43:17 +0000

Hi Tom, 

I submitted a new revision of the draft which addresses your comments. Thank you.

Cheers,
Med

> Envoyé : mercredi 7 février 2018 17:48

---

From: "t.petch" <[email-masked]>
Date: Tue, 13 Feb 2018 16:50:23 -0000

----- Original Message -----
From: <[email-masked]>
Sent: Thursday, February 08, 2018 6:43 AM

> I submitted a new revision of the draft which addresses your comments.
Thank you.

Med,

Yes, looks good,

Tom Petch

> > > > If the algorithm in RFC6052 must be supported, I would expect
this
> > >   Checking references for intended status: Proposed Standard
  --------------------------------------------------------------------
> > --------
> > >      '[RFC7050]  Savolainen, T., Korhonen, J., and D. Wing,
"Discovery
> > of...'
> > > > Cc: <[email-masked]>;
<[email-masked]>;
> > > > > A new version which addresses the comments from Tim (remove
the
> > NPTv6
> > > > 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)

---

From: Benoit Claise <[email-masked]>
Date: Wed, 21 Feb 2018 12:27:23 -0500

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.

My two cents.

Now, if you really want to split the doc., please publish both at the 
same time.

Regards, Benoit
> .

---

From: Warren Kumari <[email-masked]>
Date: Wed, 21 Feb 2018 16:03:08 -0500

On Wed, Feb 21, 2018 at 12:27 PM, Benoit Claise <[email-masked]> 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.
> 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 :-))
W

>
> My two cents.
>
> Now, if you really want to split the doc., please publish both at the same
> time.
>
> Regards, Benoit
>>
>>> 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
>>>>> Either ways are easy to handle. I do a have a preference (dedicated
>>>>
>>>> informative section).
>>>>>
>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>> This document defines a YANG model for a wide variety of NAT
>>>>
>>>> functions,
>>>>>>>>>>
>>>>>>>>>> The document is generally well written, and structured
>>>>>>>>>> appropriately.
>>>>>>>>
>>>>>>>> There
>>>>>>>>>>
>>>>>>>>>> Note: I am not a YANG doctor; I see that a separate YANG doctor
>>>>>>>>>> review
>>>>>>
>>>>>> was
>>>>>>>>>>
>>>>>>>> precedent here - and probably elsewhere - it feels odd having a
>>>>
>>>> Standards
>>>>>>>>
>>>>>>>> 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?
>>>>>>>
>>>>>> entry in the IETF XML Registry assumes "Specification is Required" and
>>>>
>>>> adding
>>>>>>
>>>>>> module, but define the nptv6 augment in a dedicated section and make
>>>>>> it
>>>>
>>>> clear
>>>>>>
>>>>>> (and I think the YANG doctor originally asked whether there should be
>>>>>> a
>>>>
>>>> high
>>>>>>
>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>> "Connecting two Peer Networks (RFC6296)"), these examples are
>>>>>>>> extracted
>>>>>>
>>>>>> from
>>>>>>>>

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

---

From: Tim Chown <[email-masked]>
Date: Thu, 22 Feb 2018 10:14:57 +0000

> On 21 Feb 2018, at 21:03, Warren Kumari <[email-masked]> wrote:
> 

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

> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

---

From: Benoit Claise <[email-masked]>
Date: Thu, 22 Feb 2018 07:17:14 -0500

Hi Tim,
> I don't personally have a strong view either way, but felt obliged to point out the discrepancy
And you can be sure that this is much appreciated. Thanks for your feedback.

Regards, Benoit