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 23) | |
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 Secdir Last Call review of -23 by Scott G. Kelly |
|
Assignment | Reviewer | Brian Trammell |
State | Completed | |
Review |
review-ietf-i2nsf-registration-interface-dm-23-tsvart-lc-trammell-2023-03-15
|
|
Posted at | https://mailarchive.ietf.org/arch/msg/tsv-art/3VHpBqsHEKwpwulQgQJuGOd2Q44 | |
Reviewed revision | 23 | |
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.