Skip to main content

Last Call Review of draft-ietf-avtcore-rfc7983bis-07
review-ietf-avtcore-rfc7983bis-07-tsvart-lc-nishida-2023-01-15-00

Request Review of draft-ietf-avtcore-rfc7983bis
Requested revision No specific revision (document currently at 09)
Type Last Call Review
Team Transport Area Review Team (tsvart)
Deadline 2023-01-17
Requested 2023-01-03
Authors Dr. Bernard D. Aboba , Gonzalo Salgueiro , Colin Perkins
I-D last updated 2023-01-15
Completed reviews Opsdir Last Call review of -07 by Dan Romascanu (diff)
Genart Last Call review of -07 by Meral Shirazipour (diff)
Tsvart Last Call review of -07 by Yoshifumi Nishida (diff)
Artart Last Call review of -07 by Marc Blanchet (diff)
Secdir Last Call review of -07 by Rich Salz (diff)
Intdir Telechat review of -08 by Bernie Volz (diff)
Assignment Reviewer Yoshifumi Nishida
State Completed
Request Last Call review on draft-ietf-avtcore-rfc7983bis by Transport Area Review Team Assigned
Posted at https://mailarchive.ietf.org/arch/msg/tsv-art/8pPwIHNf3twGmsM1xGa3G2SECP4
Reviewed revision 07 (document currently at 09)
Result Ready w/nits
Completed 2023-01-15
review-ietf-avtcore-rfc7983bis-07-tsvart-lc-nishida-2023-01-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.

Summary: I think this document is almost ready for publication, but I would be
grateful if the following points are clarified.

1: Is there any possibility that we will have other protocols for
demultiplexing in the future? It seems that QUIC consumes most of all remaining
byte ranges, which seems to affect the future extensions of the scheme.

2: "The solution discussed in this document could potentially introduce
   some additional security considerations beyond those detailed in
   [RFC7983]."

   -> Wouldn't it be better if we can describe a bit more about which part of
   the solution could have potential concern? It seems that this sentence looks
   less informational.

3: I probably might miss something, but I am wondering why we will publish
another RFC for updating multiplexing scheme. Wouldn't it simpler to create a
new doc to replace RFC7983 rather having two docs? If we will need to update
the multiplexing scheme in the future, will we have 3 docs?

Thanks,
--
Yoshi