Update discussion of Version Negotiation #4697
Conversation
There was a sentence in this section that seems to be specifying how to handle a version negotiation packet, not how to send one, and as such is out of place.
Attempt to more accurately reflect the expectations of the WG for how version negotiation will be defined and what endpoint behavior should be in the absence of a version negotiation mechanism. In particular, this work is to be done by the IETF, not by arbitrary future versions of QUIC, so we retain control over how it will be developed and deployed. Also accommodate the possibility of new versions of QUIC appearing before version negotiation is defined. Fixes: quicwg#4607
draft-ietf-quic-transport.md
Outdated
| {{version-downgrade}}. New versions of QUIC (including | ||
| non-standards-track versions) might be specified prior to the | ||
| availability of a version negotiation mechanism. Until a version | ||
| negotiation mechanism is available, new versions of QUIC MUST respond to | ||
| Version Negotiation packets as specified above. |
There was a problem hiding this comment.
I don't think that we need to include these last two sentences. While we've definitely strayed into making forward-looking statements (read: predictions) about what we might do, this goes too far in my opinion.
There was a problem hiding this comment.
I concede it was a bit speculative to say that this reflects existing consensus. That said, there is perhaps a spectrum of options, from removing it entirely to "are expected to", "SHOULD", etc. It sounds like you prefer just removing it entirely, to confirm?
There was a problem hiding this comment.
Yes. I don't think that we get much value from saying anything like this, regardless of strength, simply because it is making a prediction about work that might happen in the future.
There was a problem hiding this comment.
Fair enough. I will wait a bit before pushing an update to effectuate that, in case others want to comment.
draft-ietf-quic-transport.md
Outdated
| As a result, the client discards all state for the connection and does not send | ||
| any more packets on the connection. |
There was a problem hiding this comment.
Why remove this? It doesn't seem to be responsive to the concerns that the rest of the change addresses.
There was a problem hiding this comment.
It's an unrelated change and could easily be elided from the PR.
I read through the whole top-level section while working on this PR, and I thought this looked out of place (it's the "Remove a sentence (apparently) about handling version negotiation packets from the section that's supposed to be about sending them."). I could be mistaken about that, though, and we can split it out if that's preferred.
There was a problem hiding this comment.
Please try to focus on targeted fixes. That makes this process a lot easier to manage.
There was a problem hiding this comment.
Before I commit another faux pas, is it preferred to force-push or push a revert commit (or something else)?
There was a problem hiding this comment.
I don't personally mind. In this repo, we have let the commit history reflect the history of the issues. So push as you like.
This reverts commit 9d9dcb5. It's not appropriate for this branch.
|
Pushed fixups for both points raised. |
Co-authored-by: Jana Iyengar <jri.ietf@gmail.com>
martinthomson
added
-transport
editorial
Remove a sentence (apparently) about handling version negotiation packets from the section that's supposed to be about sending them.
Clarify that the handling of version negotiation packets is meant to be specified only by standards-track documents (since it is in some sense a cross-version invariant rather than version-specific behavior). In particular, those documents will not necessarily be specifications for a future version of QUIC.
New versions of QUIC specified prior to the existence of a version negotiation mechanism are to respond to Version Negotiation packets in the same manner as v1.