Punt on new transport connection specifics #562
Conversation
draft-ietf-tls-esni.md
Outdated
| when establishing the new transport connection or they can choose to use a | ||
| different IP address if provided with options from DNS. ECH does not mandate | ||
| any specific implementation choices when establishing this new connection.) | ||
| The retry configurations may only be applied to the retry connection. The |
There was a problem hiding this comment.
Is this a "MUST only"?
| different IP address if provided with options from DNS. ECH does not mandate | ||
| any specific implementation choices when establishing this new connection.) | ||
| The retry configurations may only be applied to the retry connection. The | ||
| client MUST NOT use retry configurations for connections beyond the retry. |
There was a problem hiding this comment.
Unrelated to this change, but if a client is making multiple connections (hello HTTP/1.1), can it use the retry configuration it learns from its first connection to guide all connections in that pool?
Let's say that the client is making these connections within the same context and so has no concerns about the connection attempts being correlated (maybe it was going to send the same cookies in all of them). Should the client only use the retry configuration for a single connection, even knowing that it will be forced to retry multiple times, or can it propagate that information immediately?
I like that this text largely avoids 2119 language (questionable lowercase "may" and "should" usage notwithstanding), but this one comes with a "MUST NOT" that seems misguided.
There was a problem hiding this comment.
Indeed -- unrelated, since this is existing text. I filed this issue to track resolution separately.
Co-authored-by: Martin Thomson <[email protected]>
|
@davidben @dennisjackson, can you please review? |
Closes #524
As always, happy to take suggestions or alternative PRs.
cc @dennisjackson, @davidben, @martinthomson