Discussion:
[core] [Technical Errata Reported] RFC7252 (5284)
RFC Errata System
2018-03-09 09:34:25 UTC
Permalink
The following errata report has been submitted for RFC7252,
"The Constrained Application Protocol (CoAP)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5284

--------------------------------------
Type: Technical
Reported by: Mohamed Boucadair <***@orange.com>

Section: 5.3.1

Original Text
-------------
The client SHOULD generate tokens in such a way that tokens currently
in use for a given source/destination endpoint pair are unique.

Corrected Text
--------------
The client SHOULD generate tokens in such a way that tokens currently
in use for a given source/destination endpoint pair are unique per
request.

Notes
-----
Multiple requests may be active for a given source/destination
endpoint pair. The OLD text is thus broken.

The NEW text is aligned with the definition of the Token:

A token is intended for use as a client-local identifier for
differentiating between concurrent requests (see Section 5.3); it
could have been called a "request ID".

Further, using the same token for a given source/destination endpoint
pair have some implications, for example, for applications which
require the support of multiple observe queries because RFC7641
states the following:

The entry in the list of observers is keyed by the client endpoint
and the token specified by the client in the request. If an entry
with a matching endpoint/token pair is already present in the list
(which, for example, happens when the client wishes to reinforce
its interest in a resource), the server MUST NOT add a new entry
but MUST replace or update the existing one.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC7252 (draft-ietf-core-coap-18)
--------------------------------------
Title : The Constrained Application Protocol (CoAP)
Publication Date : June 2014
Author(s) : Z. Shelby, K. Hartke, C. Bormann
Category : PROPOSED STANDARD
Source : Constrained RESTful Environments APP
Area : Applications
Stream : IETF
Verifying Party : IESG
Kraus Achim (INST/ECS4)
2018-03-14 11:58:51 UTC
Permalink
Hi,

if the current definition "tokens currently in use" is interpreted as for "all pending requests", I can't see, that adding "per request" improves the RFC.
If something is added, I would recommend to precise that also with the time-scope,
e.g. "per simultaneous request".

Mit freundlichen Grüßen / Best regards

Achim Kraus

(INST/ECS4)
Bosch Software Innovations GmbH | Stuttgarter Straße 130 | 71332 Waiblingen | GERMANY | www.bosch-si.com

Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber, Michael Hahn

-----Original Message-----
From: core [mailto:core-***@ietf.org] On Behalf Of RFC Errata System
Sent: Freitag, 9. März 2018 10:34
To: ***@arm.com; ***@tzi.org; ***@tzi.org; ***@nostrum.com; ***@fastmail.fm; ***@nostrum.com; ***@tzi.org; ***@iki.fi
Cc: ***@orange.com; ***@ietf.org; rfc-***@rfc-editor.org
Subject: [core] [Technical Errata Reported] RFC7252 (5284)

The following errata report has been submitted for RFC7252, "The Constrained Application Protocol (CoAP)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5284

--------------------------------------
Type: Technical
Reported by: Mohamed Boucadair <***@orange.com>

Section: 5.3.1

Original Text
-------------
The client SHOULD generate tokens in such a way that tokens currently in use for a given source/destination endpoint pair are unique.

Corrected Text
--------------
The client SHOULD generate tokens in such a way that tokens currently in use for a given source/destination endpoint pair are unique per request.

Notes
-----
Multiple requests may be active for a given source/destination endpoint pair. The OLD text is thus broken.

The NEW text is aligned with the definition of the Token:

A token is intended for use as a client-local identifier for
differentiating between concurrent requests (see Section 5.3); it
could have been called a "request ID".

Further, using the same token for a given source/destination endpoint pair have some implications, for example, for applications which require the support of multiple observe queries because RFC7641 states the following:

The entry in the list of observers is keyed by the client endpoint
and the token specified by the client in the request. If an entry
with a matching endpoint/token pair is already present in the list
(which, for example, happens when the client wishes to reinforce
its interest in a resource), the server MUST NOT add a new entry
but MUST replace or update the existing one.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC7252 (draft-ietf-core-coap-18)
--------------------------------------
Title : The Constrained Application Protocol (CoAP)
Publication Date : June 2014
Author(s) : Z. Shelby, K. Hartke, C. Bormann
Category : PROPOSED STANDARD
Source : Constrained RESTful Environments APP
Area : Applications
Stream : IETF
Verifying Party : IESG
m***@orange.com
2018-03-14 12:23:27 UTC
Permalink
Hi Achim,
(ccing DOTS WG)

Thank you for sharing your thoughts.

I'm personally OK with any wording which makes clear that distinct tokens are generated to differentiate among concurrent requests involving the same source/destination endpoints.

I'm not sure to understand what you meant by "per simultaneous request", though.

Cheers,
Med
-----Message d'origine-----
Envoyé : mercredi 14 mars 2018 12:59
Objet : RE: [core] [Technical Errata Reported] RFC7252 (5284)
Hi,
if the current definition "tokens currently in use" is interpreted as for
"all pending requests", I can't see, that adding "per request" improves the
RFC.
If something is added, I would recommend to precise that also with the time-
scope,
e.g. "per simultaneous request".
Mit freundlichen Grüßen / Best regards
Achim Kraus
(INST/ECS4)
Bosch Software Innovations GmbH | Stuttgarter Straße 130 | 71332 Waiblingen |
GERMANY | www.bosch-si.com
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr.
Stefan Ferber, Michael Hahn
-----Original Message-----
Sent: Freitag, 9. März 2018 10:34
Subject: [core] [Technical Errata Reported] RFC7252 (5284)
The following errata report has been submitted for RFC7252, "The Constrained
Application Protocol (CoAP)".
--------------------------------------
http://www.rfc-editor.org/errata/eid5284
--------------------------------------
Type: Technical
Section: 5.3.1
Original Text
-------------
The client SHOULD generate tokens in such a way that tokens currently in use
for a given source/destination endpoint pair are unique.
Corrected Text
--------------
The client SHOULD generate tokens in such a way that tokens currently in use
for a given source/destination endpoint pair are unique per request.
Notes
-----
Multiple requests may be active for a given source/destination endpoint pair.
The OLD text is thus broken.
A token is intended for use as a client-local identifier for
differentiating between concurrent requests (see Section 5.3); it
could have been called a "request ID".
Further, using the same token for a given source/destination endpoint pair
have some implications, for example, for applications which require the
The entry in the list of observers is keyed by the client endpoint
and the token specified by the client in the request. If an entry
with a matching endpoint/token pair is already present in the list
(which, for example, happens when the client wishes to reinforce
its interest in a resource), the server MUST NOT add a new entry
but MUST replace or update the existing one.
-------------
This erratum is currently posted as "Reported". If necessary, please use
"Reply All" to discuss whether it should be verified or rejected. When a
decision is reached, the verifying party can log in to change the status and
edit the report, if necessary.
--------------------------------------
RFC7252 (draft-ietf-core-coap-18)
--------------------------------------
Title : The Constrained Application Protocol (CoAP)
Publication Date : June 2014
Author(s) : Z. Shelby, K. Hartke, C. Bormann
Category : PROPOSED STANDARD
Source : Constrained RESTful Environments APP
Area : Applications
Stream : IETF
Verifying Party : IESG
_______________________________________________
core mailing list
https://www.ietf.org/mailman/listinfo/core
Göran Selander
2018-03-14 16:23:13 UTC
Permalink
Hello,

Please note there is also a security issue with re-use of tokens. The
following formulation is used in
https://tools.ietf.org/html/draft-ietf-core-echo-request-tag-01#section-5

"When CoAP is used with a security protocol not providing bindings
between requests and responses, the client MUST NOT reuse tokens
until the traffic keys have been replaced. The easiest way to
accomplish this is to implement the Token as a counter, this approach
SHOULD be followed."



Regards
Göran
Post by m***@orange.com
Hi Achim,
(ccing DOTS WG)
Thank you for sharing your thoughts.
I'm personally OK with any wording which makes clear that distinct tokens
are generated to differentiate among concurrent requests involving the
same source/destination endpoints.
I'm not sure to understand what you meant by "per simultaneous request", though.
Cheers,
Med
-----Message d'origine-----
Envoyé : mercredi 14 mars 2018 12:59
Objet : RE: [core] [Technical Errata Reported] RFC7252 (5284)
Hi,
if the current definition "tokens currently in use" is interpreted as for
"all pending requests", I can't see, that adding "per request" improves the
RFC.
If something is added, I would recommend to precise that also with the time-
scope,
e.g. "per simultaneous request".
Mit freundlichen Grüßen / Best regards
Achim Kraus
(INST/ECS4)
Bosch Software Innovations GmbH | Stuttgarter Straße 130 | 71332
Waiblingen |
GERMANY | www.bosch-si.com
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr.
Stefan Ferber, Michael Hahn
-----Original Message-----
Sent: Freitag, 9. März 2018 10:34
Subject: [core] [Technical Errata Reported] RFC7252 (5284)
The following errata report has been submitted for RFC7252, "The Constrained
Application Protocol (CoAP)".
--------------------------------------
http://www.rfc-editor.org/errata/eid5284
--------------------------------------
Type: Technical
Section: 5.3.1
Original Text
-------------
The client SHOULD generate tokens in such a way that tokens currently in use
for a given source/destination endpoint pair are unique.
Corrected Text
--------------
The client SHOULD generate tokens in such a way that tokens currently in use
for a given source/destination endpoint pair are unique per request.
Notes
-----
Multiple requests may be active for a given source/destination endpoint pair.
The OLD text is thus broken.
A token is intended for use as a client-local identifier for
differentiating between concurrent requests (see Section 5.3); it
could have been called a "request ID".
Further, using the same token for a given source/destination endpoint pair
have some implications, for example, for applications which require the
The entry in the list of observers is keyed by the client endpoint
and the token specified by the client in the request. If an entry
with a matching endpoint/token pair is already present in the list
(which, for example, happens when the client wishes to reinforce
its interest in a resource), the server MUST NOT add a new entry
but MUST replace or update the existing one.
-------------
This erratum is currently posted as "Reported". If necessary, please use
"Reply All" to discuss whether it should be verified or rejected. When a
decision is reached, the verifying party can log in to change the status and
edit the report, if necessary.
--------------------------------------
RFC7252 (draft-ietf-core-coap-18)
--------------------------------------
Title : The Constrained Application Protocol (CoAP)
Publication Date : June 2014
Author(s) : Z. Shelby, K. Hartke, C. Bormann
Category : PROPOSED STANDARD
Source : Constrained RESTful Environments APP
Area : Applications
Stream : IETF
Verifying Party : IESG
_______________________________________________
core mailing list
https://www.ietf.org/mailman/listinfo/core
_______________________________________________
core mailing list
https://www.ietf.org/mailman/listinfo/core
Loading...