Re: [QUIC] Early Editorial Review Comment draft-hamilton-quic-transport-protocol-01

[Jana Iyengar <[e-mail]>]

Thanks much for the review, Patrick! I'm leaving out most editorial
comments, with the intention of addressing them after adoption. A couple of
responses in the meanwhile though:

0] *There is really very little talk about addressing.* In TCP, this was
> obvious - the 5 tuple identifies the connection and binds the addressing
> into the transport. Not much to say. But quic awesomely separates the
> connection identifier without really talking about how addressing has to
> work. There is a TODO about rebinding that is obviously part of this
> (github issue!), but even the original binding is underspecified (e.g.
> where is the server side of the client handshake addressed to?). Its also
> not clear how the STK applies to this, and that goes into security
> considerations etc, etc.. There are some intuitive answers to these
> questions, but we ought to document.
>

Good point. I've been thinking about perhaps separate out a discussion of
the Connection ID, since I also expect there to be discussion around the
current design of it being entirely client-chosen. Use of connection ID is
currently in various parts of the doc, but given its novelty, I wonder if a
separate "QUIC Addressing" overview section makes sense, which would point
to the various places in the doc that consider addressing.

FWIW, the STK records the IP address, since it's a proof of IP ownership,
similar to the TFO cookie. Using the connection ID is largely useless here,
since the STK is meant to be  it for a new connection (with a new
connection ID.)


> 1] *Draft Intended Status is listed as experimenta*l. What's up with
> that? Standards Track I would hope, or I'm going home now :)
>

:-) I don't think this matters, since the status should change with
adoption.

- jana