Re: [quicwg/base-drafts] Rewrite text about Version Negotiation (#1039)

[Mike Bishop <[e-mail]>]

MikeBishop approved this pull request.

Looks good.  Technically, I have no objections.  Minor editorial stuff.

> +connection IDs if they do not meet both of these criteria.
+
+
+### Client-Specific Behaviors {#client-specific-behaviors}
+
+If a client receives a packet with an unknown connection ID, and it matches
+the tuple of a connection with no received packets, it is a reply to an
+Initial packet with a server-generated connection ID and will be processed
+accordingly. Clients SHOULD discard any packets with new connection IDs that
+do not meet these criteria.
+
+Note that a successfully associated packet may be a Version Negotiation
+packet, which is handled in accordance with {{handle-vn}}. 
+
+Due to packet reordering or loss, clients might receive packets associated
+with a connection for which it does not yet have the keys to decrypt it.

This sentence is awkward.  Maybe "packets encrypted with a key which the client has not yet computed."?

> +accordingly. Clients SHOULD discard any packets with new connection IDs that
+do not meet these criteria.
+
+Note that a successfully associated packet may be a Version Negotiation
+packet, which is handled in accordance with {{handle-vn}}. 
+
+Due to packet reordering or loss, clients might receive packets associated
+with a connection for which it does not yet have the keys to decrypt it.
+Clients MAY drop these packets, or MAY buffer them in anticipation of
+later packets that allow it to compute the key.
+
+
+### Server-Specific Behaviors {#server-specific-behaviors}
+
+If a server receives a packet with an unknown connection ID, an unsupported
+version, and is long enough to be an Initial packet for some version

"If a server receives a packet with... is long enough...." doesn't parse.

"...a packet which has an unknown connection ID, an unsupported version, and a sufficient length....", maybe?

> +Due to packet reordering or loss, clients might receive packets associated
+with a connection for which it does not yet have the keys to decrypt it.
+Clients MAY drop these packets, or MAY buffer them in anticipation of
+later packets that allow it to compute the key.
+
+
+### Server-Specific Behaviors {#server-specific-behaviors}
+
+If a server receives a packet with an unknown connection ID, an unsupported
+version, and is long enough to be an Initial packet for some version
+supported by the server, it SHOULD send a Version Negotiation packet as
+described in {{send-vn}}.
+
+Servers MUST drop other packets that contain unsupported versions.
+
+If the packet is a supported version, and an Initial Packet fully

Lower-case "packet" for consistency, I think.

> +with a connection for which it does not yet have the keys to decrypt it.
+Clients MAY drop these packets, or MAY buffer them in anticipation of
+later packets that allow it to compute the key.
+
+
+### Server-Specific Behaviors {#server-specific-behaviors}
+
+If a server receives a packet with an unknown connection ID, an unsupported
+version, and is long enough to be an Initial packet for some version
+supported by the server, it SHOULD send a Version Negotiation packet as
+described in {{send-vn}}.
+
+Servers MUST drop other packets that contain unsupported versions.
+
+If the packet is a supported version, and an Initial Packet fully
+conforming with the specification, the server MUST proceed with the

I think you want a different phrasing here.  The server is never obligated to proceed with the connection or the handshake; it can abort at any time.  Perhaps we should just ignore the normative language and say that the server proceeds?

> +
+### Server-Specific Behaviors {#server-specific-behaviors}
+
+If a server receives a packet with an unknown connection ID, an unsupported
+version, and is long enough to be an Initial packet for some version
+supported by the server, it SHOULD send a Version Negotiation packet as
+described in {{send-vn}}.
+
+Servers MUST drop other packets that contain unsupported versions.
+
+If the packet is a supported version, and an Initial Packet fully
+conforming with the specification, the server MUST proceed with the
+handshake ({{handshake}}).  This commits the server to the version that the
+client selected.
+
+If the packet is a supported version, and a Handshake or 0RTT packet, the

"0-RTT" is used elsewhere, I think.

> +If a server receives a packet with an unknown connection ID, an unsupported
+version, and is long enough to be an Initial packet for some version
+supported by the server, it SHOULD send a Version Negotiation packet as
+described in {{send-vn}}.
+
+Servers MUST drop other packets that contain unsupported versions.
+
+If the packet is a supported version, and an Initial Packet fully
+conforming with the specification, the server MUST proceed with the
+handshake ({{handshake}}).  This commits the server to the version that the
+client selected.
+
+If the packet is a supported version, and a Handshake or 0RTT packet, the
+server MAY buffer a limited number of these packets in anticipation of
+a late-arriving Initial Packet. In the event the server later generates
+a RETRY packet, this buffer should be purged. Servers MUST NOT send packets

We haven't all-capsed packet types elsewhere.  Also, is this really a "should", or is it a "MUST"?  Finally, the "MUST NOT send packets" seems superfluous, since the server doesn't have the context *to* respond without the contents of the Initial.  "cannot" might be sufficient.

>  
 ### Sending Version Negotiation Packets {#send-vn}
 
 If the version selected by the client is not acceptable to the server, the
 server responds with a Version Negotiation packet ({{packet-version}}).  This
 includes a list of versions that the server will accept.
 
-A server sends a Version Negotiation packet for any packet with an unacceptable
-version if that packet could create a new connection.  This allows a server to
-process packets with unsupported versions without retaining state.  Though
-either the Client Initial packet or the version negotiation packet that is sent
-in response could be lost, the client will send new packets until it
-successfully receives a response or it abandons the connection attempt.
+This system allows a server to process packets with unsupported versions without
+retaining state.  Though either the Initial packet or the version negotiation

Capitalize "Version Negotiation", since that's a packet type.  Also, since we're talking about a hypothetical unknown version of QUIC here, we don't actually know that the packet which provokes version negotiation is of type "Initial" -- it might be worth lower-casing that (and maybe just saying "the client's packet" so someone else doesn't try to get you to capitalize it another time!).

> +handshake ({{handshake}}).  This commits the server to the version that the
+client selected.
+
+If the packet is a supported version, and a Handshake or 0RTT packet, the
+server MAY buffer a limited number of these packets in anticipation of
+a late-arriving Initial Packet. In the event the server later generates
+a RETRY packet, this buffer should be purged. Servers MUST NOT send packets
+in response to these buffered packets until the Initial packet arrives.
+
+Servers MUST drop incoming packets under all other circumstances.
+
+## Version Negotiation
+
+Version negotiation ensures that client and server agree to a QUIC version
+that is mutually supported. A server sends a Version Negotiation packet in
+response to a packet that might initiate a new connection, see

The point this text was making in the old location might be clearer if you say "in response to **each** packet", i.e. if the client sends six packets in its first flight, it will get 1 < N <= 6 VN packets back.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1039#pullrequestreview-96024240