Skip to main content

Telechat Review of draft-ietf-opsawg-nat-yang-16

Request Review of draft-ietf-opsawg-nat-yang
Requested revision No specific revision (document currently at 17)
Type Telechat Review
Team Transport Area Review Team (tsvart)
Deadline 2018-09-25
Requested 2018-09-11
Authors Mohamed Boucadair , Senthil Sivakumar , Christian Jacquenet , Suresh Vinapamula , Qin Wu
Draft last updated 2018-09-25
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 Joerg Ott
State Completed
Review review-ietf-opsawg-nat-yang-16-tsvart-telechat-ott-2018-09-25
Reviewed revision 16 (document currently at 17)
Result Ready with Nits
Completed 2018-09-25

I've reviewed this document as part of TSV-ART's ongoing effort to review
key IETF documents. These comments were written primarily for the
transport area directors, but are copied to the document's authors for
their information and to allow them to address any issues raised.  When
done at the time of IETF Last Call, the authors should consider this
review together with any other last-call comments they receive. Please
always CC if you reply to or forward this review. 

Generally, the document is ready to go, but I have one comment/question
and one nit.  See the review below.


draft-ietf-opsawg-nat-yang defines a YANG data model for all flavors
of Network Address Translators.  As a data model, the document does
not define transport layer operation but rather relies on NETCONF or
RESTCONF for data carriage, which in turn use congestion controlled
transports.  The YANG model defines configurable application layer
rate limiting for events generated by the entities implementing the

The model captures the transport protocols defined in the IETF, subsuming,
as NATs do, all UDP-based protocols under UDP; not much more would be
known to the NAT by just inspecting the protocol type field of the IP header.
One question that arises is why SCTP doesn't receive equal treatment as
TCP and UDP do.  Specifically:

p.7, 2nd para reads:
   Future extensions may be needed to cover NAT-related considerations
   that are specific to other transport protocols such as SCTP
   [I-D.ietf-tsvwg-natsupp].  Typically, the mapping entry can be
   extended to record two optional SCTP-specific parameters: Internal
   Verification Tag (Int-VTag) and External Verification Tag (Ext-VTag).

This brings up two questions: 1) What is the sentence beginning with 
"Typically" supposed to convey? 2) Why wouldn't such expected parameters
be defined as part of the model right away rather than being left to an
extension?  Even if those aren't included it may be worthwhile motivating
this.  Also, should there be some more guidance what to include and what
not for future transports so that the model would get extended consistently?


p.4, 1st bullet:
A NAPT may use an extra identifier, in addition to the
five transport tuple, to disambiguate bindings [RFC6619].
A NAPT may use an extra identifier, in addition to the
five tuple used for transport, to disambiguate bindings [RFC6619].