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

Request Review of draft-ietf-opsawg-nat-yang-10
Requested rev. 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
Draft 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
Review review-ietf-opsawg-nat-yang-10-opsdir-early-chown-2018-02-05
Reviewed rev. 10 (document currently at 17)
Review result Has Nits
Review 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 draft-ietf-v6ops-ula-usage-considerations-02.)


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.