Subject: [core] TOKEN option clarification

From: Paul Duffy <[email-masked]>
Date: Wed, 04 May 2011 11:00:29 -0400

Folks,

I'm not quite able to get to clarity re: normative requirements of the 
TOKEN option.  There seems no MUST or SHOULD language about its 
inclusion in requests.  My concern is that a client does not have prior 
knowledge if a request will result in a separate response, thus no 
guidance re: when it needs to  include a TOKEN option.

?

Feel free to point me to old threads

Cheers

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 4 May 2011 17:20:06 +0200

On May 4, 2011, at 17:00, Paul Duffy wrote:

> Folks,
> 
> I'm not quite able to get to clarity re: normative requirements of the TOKEN option.  There seems no MUST or SHOULD language about its inclusion in requests.  My concern is that a client does not have prior knowledge if a request will result in a separate response, thus no guidance re: when it needs to  include a TOKEN option.

5.3.  Request/Response Matching

   [...]

   The client SHOULD generate tokens in a way that tokens currently in
   use for a given source/destination pair are unique.  (Note that a
   client can use the same token for any request if it uses a different
   source port number each time.)

Some more text about this should be written; this could e.g. go into the LWIG Guidance document.
See slide 6 of http://www.ietf.org/proceedings/80/slides/lwig-1.pdf for what this should cover.

Gruesse, Carsten

---

From: Paul Duffy <[email-masked]>
Date: Wed, 04 May 2011 11:27:56 -0400

Thanks Carsten,

I reviewed the deck, still not clear,

Seems a few normative statement re: TOKEN usage in requests and 
responses is needed.

---

From: Peter Bigot <[email-masked]>
Date: Wed, 4 May 2011 10:36:21 -0500

You might find material of interest in
http://www.ietf.org/mail-archive/web/core/current/msg01603.html and
related discussion.

Peter

On Wed, May 4, 2011 at 10:00 AM, Paul Duffy <[email-masked]> wrote:
> Folks,
>
> I'm not quite able to get to clarity re: normative requirements of the TOKEN
> option.  There seems no MUST or SHOULD language about its inclusion in
> requests.  My concern is that a client does not have prior knowledge if a
> request will result in a separate response, thus no guidance re: when it
> needs to  include a TOKEN option.
>
> ?
>
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 4 May 2011 17:37:51 +0200

On May 4, 2011, at 17:27, Paul Duffy wrote:

> Seems a few normative statement re: TOKEN usage in requests and responses is needed.

But that's right there in the section of 5.3 I cited (see also 5.10.1).
What am I missing?

Note that Token has a default value, so indeed you don't have to include it if the actual value matches the default value.

The additional text that I think might be useful would explain implementation strategies.

Gruesse, Carsten

---

From: Paul Duffy <[email-masked]>
Date: Wed, 04 May 2011 11:54:46 -0400

> But that's right there in the section of 5.3 I cited (see also 5.10.1).

I see it now.  But let me suggest a change.  Second line of 5.10.1

"Every request MUST contain a client-generated token ..."

> Note that Token has a default value, so indeed you don't have to include it if the actual value matches the default value.

Non inclusion and default TOKEN value smells like trouble.  It opens up 
the possibility of multiple outstanding requests getting incorrectly 
matched up to responses sharing the same default TOKEN value.

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 4 May 2011 18:49:21 +0200

> "Every request MUST contain a client-generated token ..."

It is impossible not to include a Token as that option has a default value.
So independent of whether you include the actual option, you do have a Token.

> Non inclusion and default TOKEN value smells like trouble.  It opens up the possibility of multiple outstanding requests getting incorrectly matched up to responses sharing the same default TOKEN value.

If that bothers you :-), don't have multiple requests outstanding with the same Token on the same socketpair (pair of IP address/port number pairs), i.e., vary the source port number, the Token, or both.
(Note that if the requests are exactly the same, you may not even care -- that is clearly the less likely case, but that is why the language in 5.3 is a SHOULD.)

Gruesse, Carsten

---

From: Paul Duffy <[email-masked]>
Date: Wed, 04 May 2011 13:05:49 -0400

> (Note that if the requests are exactly the same, you may not even care -- that is clearly the less likely case, but that is why the language in 5.3 is a SHOULD.)

Recommend then adding normative requirement prohibiting multiple 
outstanding requests w/ same TOKEN on same socket  (accommodating 
conflicting default TOKENs) OR simply require explicit TOKEN per request 
(seems the simpler way to go).

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 4 May 2011 22:14:28 +0200

> Recommend then adding normative requirement prohibiting multiple outstanding requests w/ same TOKEN on same socket  (accommodating conflicting default TOKENs)

Yes.

That's why 5.3 says:

and 5.10.1 concurs:

   A token is intended for use as a client-local identifier for
   differentiating between concurrent requests.  A client SHOULD
   generate tokens in a way that tokens currently in use for a given
   source/destination pair are unique.  An end-point receiving a token
   MUST treat it as opaque and make no assumptions about its format.

Anything else we need to do?
(Except maybe remove the redundancy, but I don't think that single-sentence repetition hurts here.)

> OR simply require explicit TOKEN per request (seems the simpler way to go).

If you mean explicit Token Option:
That would be wrong, as many clients don't ever need anything but the default value.

Gruesse, Carsten

---

From: Paul Duffy <[email-masked]>
Date: Wed, 04 May 2011 16:48:52 -0400

Recommend addition of an explicit warning that the the default TOKEN 
value violates the normative requirements you cite below.

Also, 5.3 SHOULD seems better stated as a MUST.  Same for the SHOULD in 
5.10.1

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 4 May 2011 23:20:15 +0200

On May 4, 2011, at 22:48, Paul Duffy wrote:

> Recommend addition of an explicit warning that the the default TOKEN value violates the normative requirements you cite below.

Whether it does or not depends on how many outstanding requests you have per socketpair, that's why the existing text hinges on that number instead of whether the value happens to be the default one.
But yes, it probably doesn't hurt to add more explanatory text.
(Except that we are already at 80 pages for a protocol that you can implement in an afternoon.)

> Also, 5.3 SHOULD seems better stated as a MUST.  Same for the SHOULD in 5.10.1

I don't have a strong opinion on that.
(The servers don't break if clients don't actually do that.  
So if the client has some other way to disambiguate...)

RFC2119 defines SHOULD rather strongly already:
3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

Gruesse, Carsten

---

From: Paul Duffy <[email-masked]>
Date: Wed, 04 May 2011 17:27:43 -0400

Keep it simple, understandable, and explicit.

In the general case, IMO default TOKEN value is a problem.