Last Call Review of draft-ietf-opsawg-nat-yang-14
review-ietf-opsawg-nat-yang-14-secdir-lc-farrell-2018-06-17-00

Request Review of draft-ietf-opsawg-nat-yang
Requested rev. no specific revision (document currently at 17)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2018-06-28
Requested 2018-06-14
Other 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)
Tsvart Telechat review of -16 by Joerg Ott (diff)
Review State Completed
Reviewer Stephen Farrell
Review review-ietf-opsawg-nat-yang-14-secdir-lc-farrell-2018-06-17
Posted at https://mailarchive.ietf.org/arch/msg/secdir/b1hOVzy9Uk8rR1zK5DyKtVoSEDo
Reviewed rev. 14 (document currently at 17)
Review result Has Issues
Draft last updated 2018-06-17
Review completed: 2018-06-17

Review
review-ietf-opsawg-nat-yang-14-secdir-lc-farrell-2018-06-17

I see one major issue:

2.1: Logging in NATs and esp. CGNs is clearly sensitive in various ways. I
think it'd be ok if logging was really out of scope, however, there is a
logging-enable feature, I think under-specified,  (on page 63) so the statement
in 2.1 seems contradictory to me - if logging is out of scope why is
logging-enable a flag?.  Presumably if logging-enable transitions from F->T
then you turn on (some undefined kind of) logging. If this transitions from
T->F then what is the implementer supposed to do? I think that illustrates the
under-specification here. The simplest thing might be to really make logging
out of scope here by deleting the logging-enable thing entirely. (I can imagine
that reaching consensus on a logging control interface would be non-trivial,
hence the suggestion to really put it out of scope rather than try specify it 
fully.)

Just one nit:

The abstract could do with a bit of re-wording as it reads awkwardly.  I'd say
maybe just delete the 1st sentence.