Reviewer: Joerg Ott Review result: Ready with Nits Hi, 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 tsv-art@xxxxxxxx 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. Joerg 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 model. 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? Nits: p.4, 1st bullet: OLD: A NAPT may use an extra identifier, in addition to the five transport tuple, to disambiguate bindings [RFC6619]. NEW: A NAPT may use an extra identifier, in addition to the five tuple used for transport, to disambiguate bindings [RFC6619].
