5 ms·

So the only difference is they incremented the version number and changed some other numbers, just to make sure that all software will have to be able to handle

So the only difference is they incremented the version number and changed some other numbers, just to make sure that all software will have to be able to handle the numbers changing going forward, so changing them again won't break things?

sparrish 4y ago
Yep... yawn. Why bother with the time and effort it takes to do this? I don't get it.
- tux3 4y ago
  Because they didn't do that with TLS and HTTP, and then they discovered many networks had become home to middleboxes that shipped ossified out of the box and broke horribly whenever trying to deploy any improvements They're like mold, these middleboxes. Grows easily, doesn't evolve much, likes sitting in the dark, surprisingly hard to kill, and ultimately not very friendly to human life By exercising the fields early and encrypting anything that's not nailed down, they prevent ossification from taking hold before it becomes a problem
  - xxpor 4y ago
    On the other hand, they prevent middleboxes from providing any value as well. I don't mean stupid nonsense like corporate TLS man-in-the-middle, but also.... load balancers.
    - YesThatTom2 4y ago
      That’s the point.
stevewatson301 4y ago
This approach to preventing ossification is interesting, and also rather bad, since it creates cruft RFCs such as this one.
- mort96 4y ago
  The approach has the downside of creating cruft RFCs, yes. But does that make it bad? Ossification is a real problem. What analysis are you doing which forces you to conclude that a few cruft RFCs is worse than the practical problems they solve? Or is there some other mechanism you'd prefer which achieves the same result but without cruft RFCs?
cesarb 4y ago
There seems to be one other new thing: "Any QUIC endpoint that supports QUIC version 2 MUST send, process, and validate the version_information transport parameter specified in [QUIC-VN] to prevent version downgrade attacks.", with that QUIC-VN being another draft which also seems to have been approved for publication at the same time (https://datatracker.ietf.org/doc/draft-ietf-quic-version-negotiation/ https://datatracker.ietf.org/doc/draft-ietf-quic-version-neg...). So if I understood it correctly, what's actually new is the version negotiation mechanism, with QUIC version 2 being its first user.

sparrish 4y ago

Yep... yawn. Why bother with the time and effort it takes to do this? I don't get it.

tux3 4y ago
Because they didn't do that with TLS and HTTP, and then they discovered many networks had become home to middleboxes that shipped ossified out of the box and broke horribly whenever trying to deploy any improvements They're like mold, these middleboxes. Grows easily, doesn't evolve much, likes sitting in the dark, surprisingly hard to kill, and ultimately not very friendly to human life By exercising the fields early and encrypting anything that's not nailed down, they prevent ossification from taking hold before it becomes a problem
- xxpor 4y ago
  On the other hand, they prevent middleboxes from providing any value as well. I don't mean stupid nonsense like corporate TLS man-in-the-middle, but also.... load balancers.
  - YesThatTom2 4y ago
    That’s the point.

stevewatson301 4y ago

This approach to preventing ossification is interesting, and also rather bad, since it creates cruft RFCs such as this one.

mort96 4y ago
The approach has the downside of creating cruft RFCs, yes. But does that make it bad? Ossification is a real problem. What analysis are you doing which forces you to conclude that a few cruft RFCs is worse than the practical problems they solve? Or is there some other mechanism you'd prefer which achieves the same result but without cruft RFCs?

cesarb 4y ago

There seems to be one other new thing: "Any QUIC endpoint that supports QUIC version 2 MUST send, process, and validate the version_information transport parameter specified in [QUIC-VN] to prevent version downgrade attacks.", with that QUIC-VN being another draft which also seems to have been approved for publication at the same time (https://datatracker.ietf.org/doc/draft-ietf-quic-version-negotiation/ https://datatracker.ietf.org/doc/draft-ietf-quic-version-neg...). So if I understood it correctly, what's actually new is the version negotiation mechanism, with QUIC version 2 being its first user.