Skip to main content

Last Call Review of draft-ietf-i2nsf-consumer-facing-interface-dm-26

Request Review of draft-ietf-i2nsf-consumer-facing-interface-dm
Requested revision No specific revision (document currently at 31)
Type Last Call Review
Team Transport Area Review Team (tsvart)
Deadline 2023-03-16
Requested 2023-03-02
Authors Jaehoon Paul Jeong , Chaehong Chung , Tae-Jin Ahn , Rakesh Kumar , Susan Hares
I-D last updated 2023-03-19
Completed reviews Yangdoctors Last Call review of -05 by Jan Lindblad (diff)
Yangdoctors Last Call review of -07 by Jan Lindblad (diff)
Secdir Early review of -20 by Charlie Kaufman (diff)
Genart Last Call review of -26 by Roni Even (diff)
Tsvart Last Call review of -26 by Dr. Joseph D. Touch (diff)
Secdir Last Call review of -26 by Charlie Kaufman (diff)
Intdir Telechat review of -27 by Dirk Von Hugo (diff)
Assignment Reviewer Dr. Joseph D. Touch
State Completed
Request Last Call review on draft-ietf-i2nsf-consumer-facing-interface-dm by Transport Area Review Team Assigned
Posted at
Reviewed revision 26 (document currently at 31)
Result Ready w/issues
Completed 2023-03-19
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 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

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.