Multiplexing Scheme Updates for QUIC
draft-ietf-avtcore-rfc7983bis-09

Thank you to Rich Salz for the SECDIR review.

Thanks for working on this update.

I don't have any technical comments on this update. However, there is a demand for clarification on QUIC is getting rest of all demux bits and I remember the discussions around it. I think it would be great to document that reasoning in the update.

# Éric Vyncke, INT AD, comments for draft-ietf-avtcore-rfc7983bis-08
CC @evyncke

Thank you for the work put into this document. 

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education) including one about the lack of extensions.

Special thanks to Jonathan Lennox for the shepherd's detailed write-up including the WG consensus **and** the justification of the intended status. 

Other thanks to Bernie Volz, the Internet directorate reviewer (at my request), for this int-dir review:
https://datatracker.ietf.org/doc/review-ietf-avtcore-rfc7983bis-08-intdir-telechat-volz-2023-02-03/

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS

### ZRTP

May I assume that "ZRTP" is not an acronym (based on Zimmerman being an author ?), hence there is no expansion of "ZRTP" in the text ?

### Section 1

Perhaps add the title of RFC 5764 to be consistent with other RFCs having a title/short description ?

### Why not a IANA registry ?

Out of curiosity... The train has left the station of course, but I wonder why the use of the first octet is not specified in a IANA registry rather than in a set of RFCs.

### No extension points ?

The new text specifies actions/protocols for **all** 256 values of the first octet. Are we sure that we can 'burn' all those code points with a vast majority of them for QUIC ? While I trust AVTCORE chair and the responsible AD, I really want to get an answer on this question. To be honest, I was about to raise a DISCUSS.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. 

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

# GEN AD review of draft-ietf-avtcore-rfc7983bis-08

CC @larseggert

Thanks to Meral Shirazipour for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/-TB__xTB9yrK3hmysj7V6N3tpIc).

## Comments

### Boilerplate

Document boilerplate does not seem to indicate the intended RFC status.

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### Section 4, paragraph 3
```
-    derivation could be aversely impacted by a vulnerability in the QUIC
+    derivation could be adversely impacted by a vulnerability in the QUIC
+                         +
```

### Boilerplate

Document still refers to the "Simplified BSD License", which was corrected in
the TLP on September 21, 2021. It should instead refer to the "Revised BSD
License".

### Grammar/style

#### Section 2, paragraph 2
```
binding requests have been sent. Therefore a TURN client receiving packets f
                                 ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Therefore".

#### Section 6.1, paragraph 9
```
/2019/01/rtcquictransport-api> Acknowledgments We would like to thank Martin
                               ^^^^^^^^^^^^^^^
```
Do not mix variants of the same word ("acknowledgment" and "acknowledgement")
within a single text.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

Moderate level comments:

(1) p 0, sec 1.  Introduction

   While the scheme described in this document is compatible with QUIC
   version 2 [I-D.ietf-quic-v2], it is not compatible with QUIC bit
   greasing [RFC9287].  As a result, endpoints that wish to use
   multiplexing on their socket MUST NOT send the grease_quic_bit
   transport parameter.

I'm slightly nervous with the aspect of this document that seemingly relies on the format of the first byte in the QUIC short and long header when my understanding is that isn't actually stable across QUIC versions beyond the first bit.  E.g., RFC 8999, sections 5.1 and 5.2 indicate that the first bit of QUIC headers is invariant across versions, but the next 7 bits are version specific.  As such, I think that it would be helpful for the introduction (and perhaps abstract) to have very clearer text to indicate that this standard is compatible with QUIC versions 1 and 2.  It MAY also be compatible with future versions of QUIC, but those future versions MUST be evaluated to see whether any of the version specific bits in the first byte have changed in such a way that they are incompatible with this demux scheme.



Minor level comments:

(2) p 0, sec 2.  Multiplexing of TURN Channels

   In the absence of QUIC bit greasing, the first octet of a QUIC packet
   (e.g. a short header packet in QUIC v1 or v2) may fall in the range
   64 to 127, thereby overlapping with the allocated range for TURN
   channels of 64 to 79.

I don't know QUIC very well, but it wasn't obvious to me why the text above specifically applies to the short header packet and not also the long header packet.