Skip to main content

Last Call Review of draft-ietf-i2nsf-registration-interface-dm-23
review-ietf-i2nsf-registration-interface-dm-23-tsvart-lc-trammell-2023-03-15-00

Request Review of draft-ietf-i2nsf-registration-interface-dm
Requested revision No specific revision (document currently at 26)
Type Last Call Review
Team Transport Area Review Team (tsvart)
Deadline 2023-03-16
Requested 2023-03-02
Authors Sangwon Hyun , Jaehoon Paul Jeong , TaeKyun Roh , Sarang Wi , Park Jung-Soo
I-D last updated 2023-03-15
Completed reviews Yangdoctors Last Call review of -08 by Reshad Rahman (diff)
Secdir Early review of -17 by Scott G. Kelly (diff)
Opsdir Early review of -17 by Gyan Mishra (diff)
Tsvart Last Call review of -23 by Brian Trammell (diff)
Secdir Last Call review of -23 by Scott G. Kelly (diff)
Assignment Reviewer Brian Trammell
State Completed
Request Last Call review on draft-ietf-i2nsf-registration-interface-dm by Transport Area Review Team Assigned
Posted at https://mailarchive.ietf.org/arch/msg/tsv-art/3VHpBqsHEKwpwulQgQJuGOd2Q44
Reviewed revision 23 (document currently at 26)
Result Ready
Completed 2023-03-15
review-ietf-i2nsf-registration-interface-dm-23-tsvart-lc-trammell-2023-03-15-00
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.

This document describes a YANG model for registering network security
functions with a security controller. It does not pose any transport-specific
concerns as such, and is ready from a TSV perspective.

The set of capabilities enumerated at the transport layer focuses on selecting
transport protocols by transport protocol name associated with IPv4 Protocol
or IPv6 Next Header fields; this is a very wire-image oriented view of the
protocol stack, which is appropriate within the I2NSF framework.

I note that QUIC is omitted here, but as its wire image is engineered to have
restricted visibility, that omission is fine; any NSF doing e.g. TLS handshake
decoding of QUIC packets would probably handle that as an enumerated capability
over UDP.