Subject: [quicwg/base-drafts] Strengthen 2119 language around tokens. (#2124)

From: ekr <[email-masked]>
Date: Wed, 12 Dec 2018 06:42:59 -0800

Rationale:

1. We should recommend that people use tokens.
2. Saying "SHOULD" attempt to validate seems weak. Why isn't this a
MUST? This is the weakest of these changes, I think.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/2124

-- Commit Summary --

  * Strengthen 2119 language around tokens.

-- File Changes --

    M draft-ietf-quic-transport.md (4)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/2124.patch
https://github.com/quicwg/base-drafts/pull/2124.diff

-- 
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/2124

---

From: MikkelFJ <[email-masked]>
Date: Wed, 12 Dec 2018 06:51:24 -0800

mikkelfj commented on this pull request.

> @@ -1627,7 +1627,7 @@ interface.  A client needs to start the connection process over if it migrates
 prior to completing the handshake.
 
 When a server receives an Initial packet with an address validation token, it
-SHOULD attempt to validate it, unless it has already completed address
+MUST attempt to validate it, unless it has already completed address

MUST implies that it must fail if it cannot validate. During server cluster upgrades that might not be feasible. It could lead to consistent connection failures as long at the client has a token to try. It is in the servers interest to generally attempt validation so SHOULD seems reasonable to me.

-- 
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/2124#pullrequestreview-184215675

---

From: ekr <[email-masked]>
Date: Wed, 12 Dec 2018 08:34:35 -0800

ekr commented on this pull request.

No that's not correct. The next sentence describes how to handle failures.

-- 
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/2124#discussion_r241089157

---

From: Mike Bishop <[email-masked]>
Date: Wed, 12 Dec 2018 09:45:22 -0800

MikeBishop commented on this pull request.

Let's go back to 2119 definitions:  Are there situations in which a server might choose not to validate?  Will a failure to validate cause an interoperability problem?

-- 
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/2124#discussion_r241117036

---

From: Martin Thomson <[email-masked]>
Date: Wed, 12 Dec 2018 16:16:45 -0800

martinthomson commented on this pull request.

The second change I like.  The first less so.

We also use MUST for security problems.

> @@ -1610,7 +1610,7 @@ A resumption token SHOULD be constructed to be easily distinguishable from
 tokens that are sent in Retry packets as they are carried in the same field.
 
 If the client has a token received in a NEW_TOKEN frame on a previous connection
-to what it believes to be the same server, it can include that value in the
+to what it believes to be the same server, it SHOULD include that value in the

I think that we need text on why it might not.  I suspect that this is a MUST unless (sending from a new address) OR (you don't feel like it).

I think that the "can" is fine here.

-- 
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/2124#pullrequestreview-184454725

---

From: janaiyengar <[email-masked]>
Date: Wed, 12 Dec 2018 18:40:15 -0800

janaiyengar commented on this pull request.

... or it dropped its store of tokens. SHOULD is useful in encouraging clients to do the performant thing -- use tokens unless they really can't.

There's an "unless" clause that captures the cases where a server won't validate, AFAICT. I'm ok with MUST here.

Also, the "it" is ambiguous. I would change the sentence to ".... MUST attempt to validate the token"

-- 
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/2124#discussion_r241254940

---

From: Martin Thomson <[email-masked]>
Date: Wed, 12 Dec 2018 20:00:07 -0800

If we go with SHOULD, then we need to address the reasons that an endpoint might diverge from that.  I realize that it's a cop-out, but "can" is so much easier.

-- 
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/2124#discussion_r241265846