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