Skip to main content

Early Review of draft-ietf-opsawg-nat-yang-10

Request Review of draft-ietf-opsawg-nat-yang-10
Requested revision 10 (document currently at 17)
Type Early Review
Team Ops Directorate (opsdir)
Deadline 2018-02-06
Requested 2018-01-25
Requested by Joe Clarke
Authors Mohamed Boucadair , Senthil Sivakumar , Christian Jacquenet , Suresh Vinapamula , Qin Wu
I-D last updated 2018-02-05
Completed reviews Yangdoctors Early review of -06 by Jürgen Schönwälder (diff)
Genart Early review of -09 by Roni Even (diff)
Rtgdir Early review of -09 by Mach Chen (diff)
Opsdir Early review of -10 by Tim Chown (diff)
Genart Last Call review of -14 by Roni Even (diff)
Secdir Last Call review of -14 by Stephen Farrell (diff)
Tsvart Telechat review of -16 by Joerg Ott (diff)
Assignment Reviewer Tim Chown
State Completed Snapshot
Review review-ietf-opsawg-nat-yang-10-opsdir-early-chown-2018-02-05
Reviewed revision 10 (document currently at 17)
Result Has Nits
Completed 2018-02-05
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


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.