Issues
- 4
- 5
How should endpoints react to differences between long header version and chosen version
#76 opened by DavidSchinazi - 5
AD review : Interaction with 0-RTT packets
#73 opened by zaheduzzaman - 1
AD reveiw : Minor editorial comments
#72 opened by zaheduzzaman - 1
Is the version number going to stay?
#62 opened by DavidSchinazi - 2
Duplicate text
#65 opened by DavidSchinazi - 2
Editorial: cleanup references
#66 opened by DavidSchinazi - 3
- 1
- 1
Editorial: I-D.ietf-dprive-dnsoquic is now RFC9250
#67 opened by rmarx - 1
Consistency between "QUIC version N" and "QUICvN"
#53 opened by LPardue - 1
Use [QUIC-INVARIANTS] instead of [RFC-8999]
#54 opened by LPardue - 1
- 0
- 0
Changes vs diferences
#50 opened by LPardue - 0
Section 3.2 packet type differences grokkability
#51 opened by LPardue - 0
"keys derived from a universally known salt"
#48 opened by LPardue - 1
NEW-TOKEN tokens?
#39 opened by martinduke - 0
Require use of version-info TP
#42 opened by martinduke - 0
DoQ
#44 opened by martinduke - 1
- 8
- 0
Encourage Compatible VN
#35 opened by martinduke - 2
Test vectors
#17 opened by martinthomson - 8
HTTP/3 over QUICv2
#30 opened by DavidSchinazi - 3
Retry and compatible upgrade
#23 opened by martinthomson - 6
MUST fully support VN is too strong
#25 opened by DavidSchinazi - 1
Grease the packet type?
#7 opened by martinduke - 2
Request provisional version number allocation
#20 opened by martinduke - 6
Don't Change Labels
#9 opened by nibanks - 2
Packet injection during Compatible VN
#21 opened by martinduke - 7
Need to specify the update process
#15 opened by huitema - 2
- 0
Applicability of extensions
#10 opened by martinduke - 7
ALPN
#5 opened by martinduke - 2
Different version number
#4 opened by martinduke - 1
Update Labels
#3 opened by martinduke - 0
Retry protection key
#2 opened by huitema - 1
Add a provisional version
#1 opened by martinduke