Original text:
than those considered in RFC7983.  Second, this feature of the wire image is not invariant QUIC-INVARIANTS and may change in future versions of the protocol, or even be negotiated during the handshake <del> via the use of an extension. </del>  Even though transport parameters transmitted in the client's Initial packet are observable by the network, they cannot be modified by the

Reviewer comments:
addresses
NAME started this discussion in the mailing list (URL), which made me think that the distinguishable QUIC version number practice should be written in the applicability draft. would like to know what others think about it.
I don't think that it needs consideration. We haven't talked about sharing ports before, so while QUIC gives us that option under certain narrow conditions, those are special enough that burning text on it is wasteful.
We already have this text in manageability: and
The point about the 1 bit is probably most pertinent to NAME question. And I think that it is sufficient.
Yes, there are some text in the manageability doc but I was asking if we should include some text in the applicability draft as well. The applicability draft is more towards the designer and developers of the applications on top of QUIC which I believe the case for DoQ. "As wire image is not invariant, demuxing based on that ( for example 1 bit for version QUIC 1) will make a deployment very version dependent and that need to be taken into consideration" - saying something like - would be helpful I think. I also see the mailing list discussions are deviating from what is we are saying in the manageability document - coexisting of UDP based protocols on the same port.
I'm not sure we need any additional discussion in the applicability draft. RFC900 has this: I don't think there is anything else that we could say in the applicability draft. For manageability, I create a PR with a reference to draft-ietf-quic-bit-grease
on a second thought, I think we are fine here. Thanks. Hello QUIC, DNS-over-QUIC just requested UDP Port 843, where it would coexist with DNS-over-DTLS. As long as the DNS server is running QUICv1 without greasing the QUIC bit, that should work out just fine. This does lead me to think about how QUIC versions will interact with the port over which they are intended to operate. In RFC 9000, designed explicitly for HTTP/443, we took care to make sure the signature was distinguishable from other things that run there. So, if someone wanted to deploy QUIC over some other UDP port, we might have to roll a new version simply to create a signature that doesn't clash with the protocols already operating over that port. For any given QUIC application, there is therefore a choice between (1) Picking an existing port and making sure that either (a) the other UDP application isn't present, or (b) using only QUIC versions that are distinguishable, or (2) Requesting a new port A few questions: Is my analysis correct? Are we comfortable with having to take up these new versions when they arise (which may not be that often)? Would it be preferable to have a less balkanized QUIC version space and more port allocations? I would like to start thinking through this issue and perhaps issue guidance to the ports team. Martin

Revised text:
than those considered in RFC7983.  Second, this feature of the wire image is not invariant QUIC-INVARIANTS and may change in future versions of the protocol, or even be negotiated during the handshake  <ins> via the use of an extension QUIC-GREASE. </ins> Even though transport parameters transmitted in the client's Initial packet are observable by the network, they cannot be modified by the