Change:
This is a reduction of to the important (and accurate) piece.
I started a thread on the mailing list URL And the general sense of it was that this text was insufficiently clear about the normative requirements it was creating. I believe this issue is editorial.
I agree that this is editorial, but I think that we should say something that is subtly different. There are two parts to your PR. One part that attempts to describe what is normative in the document. The other part attempts to more clearly describe the intent of the document: basically that anyone who looks at QUIC from the outside can only see and use this much of the protocol. For the "normative" piece, we can probably say something less concrete but more principled. That is: a protocol that follows the requirements in this document may call itself QUIC. And that any attempt to treat QUIC generically MUST be limited to using the characteristics that are included in this definition. For the intent part, I would say that the goal is to carve out a space for endpoints to communicate without interference from others. The goal is to design a protocol where participation by others only occurs with the express permission of endpoints. (I think we should be careful not to say whether this is just one or both endpoints granting permission here, because QUICv1 is a little inconsistent on this point itself.) That's somewhat stronger than the position you take. Leaving "others" unspecified here is good. I see that you have tried to define those others, but I don't think that's helpful. The nice thing about this approach is that it requires far less text. Your PR doubles the size of the draft. BTW, I do like the MUST regarding treatment of unknown versions. That is, if an entity doesn't understand what is going on then it can only apply generic treatment. But we all know that's RFC 6919 language.
NAME thanks for your thoughts. I tried to avoid language like "The QUIC WG MUST observe these invariants in future versions of QUIC". It seemed futile to have the WG constrain its future self in this way, while requirements for intermediaries would at least be actionable. I will add a recommendation for explicit cooperation; this is a good idea. Though I think there are cases, like measurement, where it isn't necessary. I think illustrative examples are helpful, but I'll revise to make it clear that the are non-exclusive examples, while leaving the exemption for proxies. I'm not sure what to do with this comment; I think it's important that we make it crystal clear who this document is written for and what people are supposed to do with it. It's not long. Revision is in flight.
After discussing this a little more, I have come to realize that most of what you are proposing is covered already - in excruciating detail - in . Maybe the words and framing are different, and it might be less direct than what you propose, but the important concepts exist there. What you propose here takes a small step toward moving that into invariants and I don't think that fits with my conception of the document. The primary function for me is that of a commitment regarding the shape of future versions of QUIC. That's a commitment that the IETF makes, and given what I know about how good we are at keeping those commitments, that's not worth a lot. But if we accept the credibility of that commitment, it has value if it successfully constrains future QUIC versions. Why we do that is in the hope that intermediaries will choose to respect the boundaries we set. So you are right in calling out the fact that this is the line of tape dividing the apartment in two and the effect that has on curtailing the movements of both parties. However, I don't want to say much about intermediaries (though some discussion exists in security considerations). If anything, I would prefer to leave this at something less targeted and more concise. Maybe the following as a new Section 4 "Scope": After that, I think we're into either increasing the scope or taking material from the manageability draft, neither of which I think make this document better.
Good catch on manageability, though that's an Informational draft, and the thread that spawned all this was a desire for normative text. This sounds like an informational purpose to me. Your proposed text is fine. As for my PR, I thought we'd gathered rough consensus that something to that effect was desirable, but I'm not going to lie down in the road over it.
My take on the invariants draft is the same as NAME That is really about what future protocol versions of QUIC need to adhere to. I don't think we should be specifying what we are making available to intermediaries. That is merely a side-effect, and I don't think we should be changing the scope of the document. These bits were not made available so intermediaries could use them. They were made available for the endpoints to pivot around, for the receiver to find the necessary information so that it could decrypt or reject the packet. The bits that are visible to third parties is a consequence, and this consequence is equally useful to intermediaries and sniffing tools. NAME : FWIW, I think the second paragraph in the proposed text is adequate. The first and third explicitly state things that don't really belong in the invariants draft IMO. The only RFC 2119 keywords in this document are related to Version Negotiation packets, and I suspect these requirements might best be in the quic-transport draft. (At the very least, the quic-transport draft should refer to these normative VN requirements hidden in quic-invariants). If there are really no normative requirements on future versions of QUIC with respect to long and short headers, etc, than this really is an informational draft to help middleboxes understand the current IETF consensus about future versions of QUIC. I would much prefer that either: This draft becomes fully normative on future versions of QUIC ("Future versions of QUIC MUST NOT mess with this format..."), or We pull the VN normative text out of -invariants and make this purely Informational. What do others think?

Discussion:
The primary goal of this document is to ensure that it is possible to deploy new versions of QUIC.  By documenting the properties that <del> can't change, this document aims to preserve the ability to change any other aspect of the protocol.  Thus, unless specifically described in this document, any aspect of the protocol can change between different versions. </del> <ins> can't change, this document aims to preserve the ability for QUIC endpoints to negotiate changes to any other aspect of the protocol. As a consequence, this also guarantees a minimal amount of information that is made available to entities other than endpoints. Unless specifically prohibited in this document, any aspect of the protocol can change between different versions. </ins> bad-assumptions is a non-exhaustive list of some incorrect assumptions that might be made based on knowledge of QUIC version 1;