Original text:
(ECN) in the first packets it sends, as described in ecn-validation. The CRYPTO frame can be sent in different packet number spaces <del> (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. </del>  Endpoints MUST explicitly negotiate an application protocol.  This avoids situations where there is a disagreement about the protocol Handshake packets. This enforces cryptographic separation between the data sent in the <del> 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. </del>  0-RTT and 1-RTT data exist in the same packet number space to make loss recovery algorithms easier to implement between the two packet

Reviewer comments:
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 "Seqno" 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.
NAME 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: The mention of sequence number in relation to CRYPTO frames is a mistake. This should be "offset". Packet numbers are just packet numbers. Yes, it is a sequence number, but we don't use "sequence" here anywhere else, so that one instance is just a mistake. Sequence 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 isn'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.

Revised text:
(ECN) in the first packets it sends, as described in ecn-validation. The CRYPTO frame can be sent in different packet number spaces  <ins> (packet-numbers).  The offsets used by CRYPTO frames to ensure ordered delivery of cryptographic handshake data start from zero in each packet number space. </ins> Endpoints MUST explicitly negotiate an application protocol.  This avoids situations where there is a disagreement about the protocol Handshake packets. This enforces cryptographic separation between the data sent in the  <ins> 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. </ins> 0-RTT and 1-RTT data exist in the same packet number space to make loss recovery algorithms easier to implement between the two packet