This document has been reviewed as part of the transport area review team'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 and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@ietf.org if you reply to or forward this review.

The document defines two YANG modules with augmentations of the Interfaces data model. I have read -17 as TSV-ART reviewer. 

In the document, there are no specific issues related to transport protocols. Yet, I believe that there are some general minor issues and nits.

# Minor issues:

- The security considerations for write access are generic. Specifically, I wonder if it makes sense to mention the security implications of changing the MAC address (e.g., ARP spoofing). Other writeable parameters can also have security implications, e.g., if the MTU gets affected.

- All examples are in JSON encoding. Is XML encoding for NETCONF really already dead?

# Nits:

- I got a bit confused by the abstract that mentions the MTU, while the YANG module actually defines a maximum frame size.

- Several acronyms such as "MTU", "QOS", "OTN", "DWDM", ... are not expanded. Some may be obvious, but, for instance, I am not sure if all network engineers know OTN. And, BTW, I often see the spelling "QoS" for Quality-of-Service.

- [RFCAAA] in Section 9 should probably be [RFC8407]

Thanks

Michael