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.

Note that this review focuses on transport issues. The document's content has not been otherwise reviewed.

Overall, there is little transport-related content in this document. As a YANG model, there are no transport issues. 

The model itself does refer to transport protocols by name. The list is sufficiently complete.

The only key issue is the reference to ways of blocking protocols. The "identity reject" entry below describes a variety of ways of blocking transport protocols, buthese examples have issues. It is important that this document be updated to give correct advice, even if in such examples.

	  ...For example, a TCP packet is rejected with
          TCP RST response or a UDP packet may be rejected with an
          ICMPv4 response message with Type 3 Code 3 or ICMPv6 response
          message Type 1 Code 4 (i.e., Destination Unreachable:
          Destination port unreachable)."

It is not entirely clear from the rest of the context of this document, but if this filtering occurs anywhere other than the destination IP address of these packets then ICMP messages from routers should be used, not those from hosts. I.e., if the issue is packets to/from a NFV service, then host errors are appropriate, but if the issue is packets relayed through an NFV service, then router errors should be used instead.

Additionally, assuming host errors are intended, the entry mentions ICMPv4 Type 3 Code 3 (Destination port unreachable) and ICMPv6 Type 1 Code 4 (also Destination port unreachable), where it appears that ICMPv4 Type 3 Code 10 and ICMPv6 Type 1 Code 1 (both “administratively prohibited”) seems more appropriate. 

That entry also incorrectly refers to use of TCP RST. TCP RST should be reserved for actions of the receiver TCP protocol engine based on state errors, and emitting that message requires that endpoint’s TCP to enter TIME-WAIT for that socket pair (RFC 9293, Note 3 in Sec 3.3). It should never be issued by a third party that might not be in a position to maintain those TIME-WAIT states. It is also not clear it is appropriate to reject connections using this technique, i.e., as a substitute for host ICMPs.