Draft: draft-ietf-quic-transport

Commentary: There were two cases where we used " sequence number " when we really meant something else . 
 Reading version -27 of the transport draft , I was surprised to see something called " sequence numbers " , until I understood that it had nothing to do with either TCP sequence numbers or QUIC packet numbers . This is an unfortunate choice of words for two reasons : 1 ) people familiar with TCP may initially interpret " sequence numbers " in the TCP sense , causing confusion ; 2 ) " packet numbers " and " sequence numbers " are too easily confused . For instance , I found a single instance in the draft where " sequence numbers " is used to actually mean " packet numbers " : And another instance which uses a mix of both expressions : These instances can be easily fixed , but it would be beneficial to eliminate any source of confusion by renaming " sequence numbers " to something else . A simple suggestion : " connection ID counter " . Babel ( RFC6126 ) has a similar notion of " sequence number " , and it uses the unambiguous abbreviation "  " throughout the text : this may be an alternative solution . 
 " Packet sequence number " is the full name , but " packet number " is the shorter term used throughout the documents . I think we need to fix section 7 or anywhere else we use " sequence number " . I 'm ok with us using " packet sequence number " , but I think " packet number " is preferable . I really do not want to rename packet number to something else . 
 I agree that " packet number " should not be renamed , it 's a central concept of the protocol . I was suggesting renaming " sequence numbers " instead ( as used to track connection IDs ) 
 Sorry for my confusion . I agree it 'd be nice to rename " sequence numbers " in regards to CIDs as well . Maybe " Connection ID Index " ? 
 So there are three things here : mention of sequence number in relation to CRYPTO frames is a mistake . This should be " offset " . numbers are just packet numbers . Yes , it is a sequence number , but we do n't use " sequence " here anywhere else , so that one instance is just a mistake . numbers for connection IDs . I 'm not inclined to change these . Using index / indices would be fine , but the risk involved in making a change is n't worth it in my opinion . As this is sufficiently distinct from the TCP usage , I see no real risk of confusion either . 
 +1 . I agree that they are sufficiently distinct . Also , I do not think we 'd want to go down the path of changing the terms that are used in TCP to something else . To give an example , " FIN " in QUIC is different than that in TCP . Do we need to look for such cases and change all the names ? I think making such changes could cause more confusion . 
 Agreed . This is just wrong . trying to submit edits to ( D)TLS and QUIC .
Paragraph (version A):
The CRYPTO frame can be sent in different packet number spaces
(packet-numbers).  The sequence numbers used by CRYPTO frames to
ensure ordered delivery of cryptographic handshake data start from
zero in each packet number space.
Paragraph (version B):
The CRYPTO frame can be sent in different packet number spaces
(packet-numbers).  The offsets used by CRYPTO frames to ensure
ordered delivery of cryptographic handshake data start from zero in
each packet number space.
Paragraph (version A):
This enforces cryptographic separation between the data sent in the
different packet sequence number spaces.  Packet numbers in each
space start at packet number 0.  Subsequent packets sent in the same
packet number space MUST increase the packet number by at least one.
Paragraph (version B):
This enforces cryptographic separation between the data sent in the
different packet number spaces.  Packet numbers in each space start
at packet number 0.  Subsequent packets sent in the same packet
number space MUST increase the packet number by at least one.