[core] 🔔 WGLC draft-ietf-core-coap-tcp-tls

[Jaime Jiménez]

Dear CoRE WG,

There has been quite some work on the "CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets” draft (draft-ietf-core-coap-tcp-tls) since the last WGLC.
BIG thanks to Brian for the time and effort dedicated as Editor. It now seems a good time for a final WGLC to get the last comments from the group in order to move the specification forward.

In particular there has not been much discussion on securing CoAP over WebSockets (https://github.com/core-wg/coap-tcp-tls/issues/102) as well as the Default URI host (https://github.com/core-wg/coap-tcp-tls/issues/108) feedback would be very much welcomed. Please go ahead and check the discussions on the other issues of this version: https://github.com/core-wg/coap-tcp-tls/milestone/4?closed=1 and on the changelog summary. In addition to that, I would like to ask the group to let me know their current implementation status of the draft for the shepherd writeup, especially Open Source implementations of the draft.

latest version: https://tools.ietf.org/html/draft-ietf-core-coap-tcp-tls-06
diff: https://tools.ietf.org/rfcdiff?url2=draft-ietf-core-coap-tcp-tls-06.txt
changelog: https://tools.ietf.org/html/draft-ietf-core-coap-tcp-tls-06#appendix-C.4

The WGLC will last one week, until 2017-02-22 .

Thanks!
Jaime Jiménez

[Dijk, Esko]

Dear WG & authors,

Below my review of the draft. Overall, I find it a useful extension to the overall 'CoAP protocol suite'. On the discussed tickets I have no further input.

** Questions
• The bi-directionality of connections is mentioned in the draft. Now suppose a CoAP client on host 1 opens a TCP connection (as a TCP client) to a TCP server on host 2, in order to send a CoAP request to it. Now the TCP server (host 2) at some point suddenly sends a CoAP request (acting itself as a CoAP client) to the TCP client (host 1). However, there is no CoAP server hosted on host 1. What should happen now? E.g. is the request simply ignored or is some kind of error message returned?
• Same question as above can be stated for TLS and Websockets. Is the behavior the same in these cases?
• Following the above, should the CSM message have an option to indicate a capability of "being a CoAP server" … ?
• Page 20: Alternative-Address Option - the semantics of including multiple of these options is not defined. Can the receiver pick any of the addresses? Or does it need to try the first address first? And then keep trying all alternatives until one succeeds, or not?
• Page 28, Section 6.5: is it correct to conclude that, for Websocket connections, the default Uri-Port value will be 80 if using "coap+ws" scheme with its default TCP port, and 443 if using "coaps+ws" scheme with its default TCP port? Just for my understanding.
• Appendix A: Why is the update of Observe [RFC7641] done in the Appendix and not in a main section? There must have been a good reason to place it there; but it looks strange since it formally updates RFC 7641.

** Review comments / proposed corrections
• Page 10, Figure 8: the first pipe (|) character on the second row of fields should be removed, i.e. the Extended Length field should then become 4 bytes instead of 3.
• Page 11: "provided by the TCP/TLS protocol." -> "provided by the TCP/TLS protocols." ? I assume the intention here is to refer to both protocols as done for all other occurrences of the string "TCP/TLS" in the document.
• Page 12: "[RFC6454]" - it is unclear what aspect or section of RFC 6454 is referred to here. That RFC hardly mentions WebSockets.
• Page 15, Section 4, first bullet: "Related characteristics" -> "Learn relevant characteristics" ? The verb is missing in the sentence.
• Page 16: "as adapted to the specific transport." -> bit unclear what this means or intends to say. Maybe it intends "which is adapted to specific reliable transports in Sections 2.2 and 3.2 of this document." ?
• Page 16: "Setting options indicate a setting that will be applied by the sender" -> "Each setting option indicates a setting that will be applied by the sender" ?
• Page 19: Could clarify the sentence below to say this is about handling a Ping with Custody Option only, so not in general for every Ping message:
"The receiver SHOULD delay its Pong message until it finishes processing all the request/
response messages received prior to the Ping message on the current connection."
->
"In that case, the receiver SHOULD delay its Pong message until it finishes processing all the request/
response messages received prior to that Ping message on the current connection."
• Page 22:
"contain a multiple of 1024 bytes (non-final BERT block) or more than 1024 bytes (final BERT block)"
-> Why can't the final block be 1024 bytes? I assume a final BERT block of 1024 bytes is allowed; it would be strange to switch back to SZX=6 for that purpose. What about below text ->
"contain a multiple of 1024 bytes (non-final BERT block) or more than 1023 bytes (final BERT block)"
• Page 23: "block size exponent (2**(SZX+4))" -> "block size (2**(SZX+4))" (Since the exponent is not shown in the notation, rather the resulting size value)
• Page 25: "They are distinct namespaces and are considered to be distinct origin servers" -> Assuming that 'they' refers to the resources. Shouldn't we rather say "They are hosted in distinct namespaces, because each URI scheme implies a distinct origin server."
It seems strange to say that a resource is considered to be namespace, and a resource is considered to be an origin server. Which is what the current text states :)

** Nits
• Page 5: Section 1.1 might add a short note that "TCP/TLS" means "TCP or TLS" in this document, and not "TLS over TCP" or so. But perhaps it's obvious to most people.
• Page 9: "modeled on CoAP Options" -> "modeled on the Option Length field in CoAP Options" ?
• Page 13: "Reverse Proxy" -> "reverse-proxy" (to comply with RFC 7252 terminology)
• Page 18: "equal or less" -> "equal to or less"
• Page 27, Figure 19: first accolade should extend slightly to the right, second accolade should move slightly to the right.
• Page 28, Section 6.6: the changes indicated could improve in readability a bit by having a form of "old/new indication".
• Page 31, Section 8.1: list bullet can be removed
• Global: s/port component/port subcomponent/
• Page 43: "[2001:DB8::1]" -> "[2001:db8::1]"

best regards,
Esko Dijk
---

From: core [mailto:core-***@ietf.org] On Behalf Of Jaime Jiménez
Sent: Wednesday, February 15, 2017 13:17
To: ***@ietf.org WG <***@ietf.org>
Cc: draft-ietf-core-coap-tcp-***@ietf.org
Subject: [core] 🔔 WGLC draft-ietf-core-coap-tcp-tls

Dear CoRE WG,

There has been quite some work on the "CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets” draft (draft-ietf-core-coap-tcp-tls) since the last WGLC.
BIG thanks to Brian for the time and effort dedicated as Editor. It now seems a good time for a final WGLC to get the last comments from the group in order to move the specification forward.

In particular there has not been much discussion on securing CoAP over WebSockets (https://github.com/core-wg/coap-tcp-tls/issues/102) as well as the Default URI host (https://github.com/core-wg/coap-tcp-tls/issues/108) feedback would be very much welcomed. Please go ahead and check the discussions on the other issues of this version: https://github.com/core-wg/coap-tcp-tls/milestone/4?closed=1 and on the changelog summary. In addition to that, I would like to ask the group to let me know their current implementation status of the draft for the shepherd writeup, especially Open Source implementations of the draft.

latest version: https://tools.ietf.org/html/draft-ietf-core-coap-tcp-tls-06
diff: https://tools.ietf.org/rfcdiff?url2=draft-ietf-core-coap-tcp-tls-06.txt
changelog: https://tools.ietf.org/html/draft-ietf-core-coap-tcp-tls-06#appendix-C.4

The WGLC will last one week, until 2017-02-22 .

Thanks!
Jaime Jiménez

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

[Hannes Tschofenig]

Thanks for your detailed review, Esko.

I started to address some of your comments. More later.


** Review comments / proposed corrections
• Page 10, Figure 8: the first pipe (|) character on the second row of
fields should be removed, i.e. the Extended Length field should then
become 4 bytes instead of 3.

Fixed.

• Page 11: "provided by the TCP/TLS protocol." -> "provided by the
TCP/TLS protocols." ? I assume the intention here is to refer to both
protocols as done for all other occurrences of the string "TCP/TLS" in
the document.

Since this section only talks about TCP and not TLS I removed TLS.

• Page 12: "[RFC6454]" - it is unclear what aspect or section of RFC
6454 is referred to here. That RFC hardly mentions WebSockets.

I removed the sentence since it does not add any value right now.

• Page 15, Section 4, first bullet: "Related characteristics" -> "Learn
relevant characteristics" ? The verb is missing in the sentence.

Fixed.

• Page 16: "as adapted to the specific transport." -> bit unclear what
this means or intends to say. Maybe it intends "which is adapted to
specific reliable transports in Sections 2.2 and 3.2 of this document." ?

I simplified the sentence saying "See Section 3 of CoAP for the overall
structure of the message format, option format, and option value format."

• Page 16: "Setting options indicate a setting that will be applied by
the sender" -> "Each setting option indicates a setting that will be
applied by the sender" ?

Sounds like a good proposal.

** Nits
• Page 5: Section 1.1 might add a short note that "TCP/TLS" means "TCP
or TLS" in this document, and not "TLS over TCP" or so. But perhaps it's
obvious to most people.

OK. Clarified.

• Page 9: "modeled on CoAP Options" -> "modeled on the Option Length
field in CoAP Options" ?

I changed it to "The encoding of the Length field is modeled after the
Option Length field of the CoAP Options."

• Page 13: "Reverse Proxy" -> "reverse-proxy" (to comply with RFC 7252
terminology)

OK.

• Page 18: "equal or less" -> "equal to or less"

OK.

• Page 27, Figure 19: first accolade should extend slightly to the
right, second accolade should move slightly to the right.

OK.

• Page 28, Section 6.6: the changes indicated could improve in
readability a bit by having a form of "old/new indication".
• Page 31, Section 8.1: list bullet can be removed

OK.

• Global: s/port component/port subcomponent/

OK.


• Page 43: "[2001:DB8::1]" -> "[2001:db8::1]"

OK.

Ciao
Hannes

Post by Dijk, Esko
Dear WG & authors,
Below my review of the draft. Overall, I find it a useful extension to the overall 'CoAP protocol suite'. On the discussed tickets I have no further input.
** Questions
• The bi-directionality of connections is mentioned in the draft. Now suppose a CoAP client on host 1 opens a TCP connection (as a TCP client) to a TCP server on host 2, in order to send a CoAP request to it. Now the TCP server (host 2) at some point suddenly sends a CoAP request (acting itself as a CoAP client) to the TCP client (host 1). However, there is no CoAP server hosted on host 1. What should happen now? E.g. is the request simply ignored or is some kind of error message returned?
• Same question as above can be stated for TLS and Websockets. Is the behavior the same in these cases?
• Following the above, should the CSM message have an option to indicate a capability of "being a CoAP server" 
 ?
• Page 20: Alternative-Address Option - the semantics of including multiple of these options is not defined. Can the receiver pick any of the addresses? Or does it need to try the first address first? And then keep trying all alternatives until one succeeds, or not?
• Page 28, Section 6.5: is it correct to conclude that, for Websocket connections, the default Uri-Port value will be 80 if using "coap+ws" scheme with its default TCP port, and 443 if using "coaps+ws" scheme with its default TCP port? Just for my understanding.
• Appendix A: Why is the update of Observe [RFC7641] done in the Appendix and not in a main section? There must have been a good reason to place it there; but it looks strange since it formally updates RFC 7641.
** Review comments / proposed corrections
• Page 10, Figure 8: the first pipe (|) character on the second row of fields should be removed, i.e. the Extended Length field should then become 4 bytes instead of 3.
• Page 11: "provided by the TCP/TLS protocol." -> "provided by the TCP/TLS protocols." ? I assume the intention here is to refer to both protocols as done for all other occurrences of the string "TCP/TLS" in the document.
• Page 12: "[RFC6454]" - it is unclear what aspect or section of RFC 6454 is referred to here. That RFC hardly mentions WebSockets.
• Page 15, Section 4, first bullet: "Related characteristics" -> "Learn relevant characteristics" ? The verb is missing in the sentence.
• Page 16: "as adapted to the specific transport." -> bit unclear what this means or intends to say. Maybe it intends "which is adapted to specific reliable transports in Sections 2.2 and 3.2 of this document." ?
• Page 16: "Setting options indicate a setting that will be applied by the sender" -> "Each setting option indicates a setting that will be applied by the sender" ?
"The receiver SHOULD delay its Pong message until it finishes processing all the request/
response messages received prior to the Ping message on the current connection."
->
"In that case, the receiver SHOULD delay its Pong message until it finishes processing all the request/
response messages received prior to that Ping message on the current connection."
"contain a multiple of 1024 bytes (non-final BERT block) or more than 1024 bytes (final BERT block)"
-> Why can't the final block be 1024 bytes? I assume a final BERT block of 1024 bytes is allowed; it would be strange to switch back to SZX=6 for that purpose. What about below text ->
"contain a multiple of 1024 bytes (non-final BERT block) or more than 1023 bytes (final BERT block)"
• Page 23: "block size exponent (2**(SZX+4))" -> "block size (2**(SZX+4))" (Since the exponent is not shown in the notation, rather the resulting size value)
• Page 25: "They are distinct namespaces and are considered to be distinct origin servers" -> Assuming that 'they' refers to the resources. Shouldn't we rather say "They are hosted in distinct namespaces, because each URI scheme implies a distinct origin server."
It seems strange to say that a resource is considered to be namespace, and a resource is considered to be an origin server. Which is what the current text states :)
** Nits
• Page 5: Section 1.1 might add a short note that "TCP/TLS" means "TCP or TLS" in this document, and not "TLS over TCP" or so. But perhaps it's obvious to most people.
• Page 9: "modeled on CoAP Options" -> "modeled on the Option Length field in CoAP Options" ?
• Page 13: "Reverse Proxy" -> "reverse-proxy" (to comply with RFC 7252 terminology)
• Page 18: "equal or less" -> "equal to or less"
• Page 27, Figure 19: first accolade should extend slightly to the right, second accolade should move slightly to the right.
• Page 28, Section 6.6: the changes indicated could improve in readability a bit by having a form of "old/new indication".
• Page 31, Section 8.1: list bullet can be removed
• Global: s/port component/port subcomponent/
• Page 43: "[2001:DB8::1]" -> "[2001:db8::1]"
best regards,
Esko Dijk
---
Sent: Wednesday, February 15, 2017 13:17
Subject: [core] 🔔 WGLC draft-ietf-core-coap-tcp-tls
Dear CoRE WG,
There has been quite some work on the "CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets” draft (draft-ietf-core-coap-tcp-tls) since the last WGLC.
BIG thanks to Brian for the time and effort dedicated as Editor. It now seems a good time for a final WGLC to get the last comments from the group in order to move the specification forward.
In particular there has not been much discussion on securing CoAP over WebSockets (https://github.com/core-wg/coap-tcp-tls/issues/102) as well as the Default URI host (https://github.com/core-wg/coap-tcp-tls/issues/108) feedback would be very much welcomed. Please go ahead and check the discussions on the other issues of this version: https://github.com/core-wg/coap-tcp-tls/milestone/4?closed=1 and on the changelog summary. In addition to that, I would like to ask the group to let me know their current implementation status of the draft for the shepherd writeup, especially Open Source implementations of the draft.
latest version: https://tools.ietf.org/html/draft-ietf-core-coap-tcp-tls-06
diff: https://tools.ietf.org/rfcdiff?url2=draft-ietf-core-coap-tcp-tls-06.txt
changelog: https://tools.ietf.org/html/draft-ietf-core-coap-tcp-tls-06#appendix-C.4
The WGLC will last one week, until 2017-02-22 .
Thanks!
Jaime Jiménez
________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.
_______________________________________________
core mailing list
https://www.ietf.org/mailman/listinfo/core

[Brian Raymor]

Thanks to Hannes for addressing some of the editorial comments.

Post by Hannes Tschofenig

• Page 12: "[RFC6454]" - it is unclear what aspect or section of RFC6454
is referred to here. That RFC hardly mentions WebSockets.

I removed the sentence since it does not add any value right now.

I removed the unused reference to RFC6454.

Post by Hannes Tschofenig

• Page 19: Could clarify the sentence below to say this is about handling a Ping
"The receiver SHOULD delay its Pong message until it finishes processing all the request/
response messages received prior to the Ping message on the current connection."
->
"In that case, the receiver SHOULD delay its Pong message until it finishes processing all the request/
response messages received prior to that Ping message on the current connection."

OK.

Post by Hannes Tschofenig

"contain a multiple of 1024 bytes (non-final BERT block) or more than 1024 bytes (final BERT block)"
-> Why can't the final block be 1024 bytes? I assume a final BERT block of 1024 bytes is allowed;
it would be strange to switch back to SZX=6 for that purpose. What about below text ->
"contain a multiple of 1024 bytes (non-final BERT block) or more than 1023 bytes (final BERT block)"

Assigned - https://github.com/core-wg/coap-tcp-tls/issues/116 - to Carsten for a quick review as the draft-bormann-core-block-bert-01 author.

Post by Hannes Tschofenig

• Page 23: "block size exponent (2**(SZX+4))" -> "block size (2**(SZX+4))"
(Since the exponent is not shown in the notation, rather the resulting size value)

OK.

Post by Hannes Tschofenig

• Page 25: "They are distinct namespaces and are considered to be distinct origin servers"
-> Assuming that 'they' refers to the >> resources. Shouldn't we rather say "They are hosted in distinct namespaces,
because each URI scheme implies a distinct origin server."
It seems strange to say that a resource is considered to be namespace, and a resource
is considered to be an origin server. Which is what the current text states :)

OK.

Post by Hannes Tschofenig

• Page 28, Section 6.6: the changes indicated could improve in readability a bit by having a form of "old/new indication".
• Page 31, Section 8.1: list bullet can be removed

OK.

I didn't see the proposed changes completed in Section 6.6. I'll update and also make similar changes to Section 6.7 for symmetry.

-----Original Message-----
From: Hannes Tschofenig [mailto:***@gmx.net]
Sent: Tuesday, February 21, 2017 6:04 AM
To: Dijk, Esko <***@philips.com>; ***@ietf.org WG <***@ietf.org>
Cc: draft-ietf-core-coap-tcp-***@ietf.org
Subject: Re: [core] 🔔 WGLC draft-ietf-core-coap-tcp-tls

Thanks for your detailed review, Esko.

I started to address some of your comments. More later.


** Review comments / proposed corrections • Page 10, Figure 8: the first pipe (|) character on the second row of fields should be removed, i.e. the Extended Length field should then become 4 bytes instead of 3.

Fixed.

• Page 11: "provided by the TCP/TLS protocol." -> "provided by the TCP/TLS protocols." ? I assume the intention here is to refer to both protocols as done for all other occurrences of the string "TCP/TLS" in the document.

Since this section only talks about TCP and not TLS I removed TLS.

• Page 12: "[RFC6454]" - it is unclear what aspect or section of RFC
6454 is referred to here. That RFC hardly mentions WebSockets.

I removed the sentence since it does not add any value right now.

• Page 15, Section 4, first bullet: "Related characteristics" -> "Learn relevant characteristics" ? The verb is missing in the sentence.

Fixed.

• Page 16: "as adapted to the specific transport." -> bit unclear what this means or intends to say. Maybe it intends "which is adapted to specific reliable transports in Sections 2.2 and 3.2 of this document." ?

I simplified the sentence saying "See Section 3 of CoAP for the overall structure of the message format, option format, and option value format."

• Page 16: "Setting options indicate a setting that will be applied by the sender" -> "Each setting option indicates a setting that will be applied by the sender" ?

Sounds like a good proposal.

** Nits
• Page 5: Section 1.1 might add a short note that "TCP/TLS" means "TCP or TLS" in this document, and not "TLS over TCP" or so. But perhaps it's obvious to most people.

OK. Clarified.

• Page 9: "modeled on CoAP Options" -> "modeled on the Option Length field in CoAP Options" ?

I changed it to "The encoding of the Length field is modeled after the Option Length field of the CoAP Options."

• Page 13: "Reverse Proxy" -> "reverse-proxy" (to comply with RFC 7252
terminology)

OK.

• Page 18: "equal or less" -> "equal to or less"

OK.

• Page 27, Figure 19: first accolade should extend slightly to the right, second accolade should move slightly to the right.

OK.

• Page 28, Section 6.6: the changes indicated could improve in readability a bit by having a form of "old/new indication".
• Page 31, Section 8.1: list bullet can be removed

OK.

• Global: s/port component/port subcomponent/

OK.


• Page 43: "[2001:DB8::1]" -> "[2001:db8::1]"

OK.

Ciao
Hannes

Post by Hannes Tschofenig
Dear WG & authors,
Below my review of the draft. Overall, I find it a useful extension to the overall 'CoAP protocol suite'. On the discussed tickets I have no further input.
** Questions
• The bi-directionality of connections is mentioned in the draft. Now suppose a CoAP client on host 1 opens a TCP connection (as a TCP client) to a TCP server on host 2, in order to send a CoAP request to it. Now the TCP server (host 2) at some point suddenly sends a CoAP request (acting itself as a CoAP client) to the TCP client (host 1). However, there is no CoAP server hosted on host 1. What should happen now? E.g. is the request simply ignored or is some kind of error message returned?
• Same question as above can be stated for TLS and Websockets. Is the behavior the same in these cases?
• Following the above, should the CSM message have an option to indicate a capability of "being a CoAP server" … ?
• Page 20: Alternative-Address Option - the semantics of including multiple of these options is not defined. Can the receiver pick any of the addresses? Or does it need to try the first address first? And then keep trying all alternatives until one succeeds, or not?
• Page 28, Section 6.5: is it correct to conclude that, for Websocket connections, the default Uri-Port value will be 80 if using "coap+ws" scheme with its default TCP port, and 443 if using "coaps+ws" scheme with its default TCP port? Just for my understanding.
• Appendix A: Why is the update of Observe [RFC7641] done in the Appendix and not in a main section? There must have been a good reason to place it there; but it looks strange since it formally updates RFC 7641.
** Review comments / proposed corrections • Page 10, Figure 8: the
first pipe (|) character on the second row of fields should be removed, i.e. the Extended Length field should then become 4 bytes instead of 3.
• Page 11: "provided by the TCP/TLS protocol." -> "provided by the TCP/TLS protocols." ? I assume the intention here is to refer to both protocols as done for all other occurrences of the string "TCP/TLS" in the document.
• Page 12: "[RFC6454]" - it is unclear what aspect or section of RFC 6454 is referred to here. That RFC hardly mentions WebSockets.
• Page 15, Section 4, first bullet: "Related characteristics" -> "Learn relevant characteristics" ? The verb is missing in the sentence.
• Page 16: "as adapted to the specific transport." -> bit unclear what this means or intends to say. Maybe it intends "which is adapted to specific reliable transports in Sections 2.2 and 3.2 of this document." ?
• Page 16: "Setting options indicate a setting that will be applied by the sender" -> "Each setting option indicates a setting that will be applied by the sender" ?
"The receiver SHOULD delay its Pong message until it finishes processing all the request/
response messages received prior to the Ping message on the current connection."
->
"In that case, the receiver SHOULD delay its Pong message until it finishes processing all the request/
response messages received prior to that Ping message on the current connection."
"contain a multiple of 1024 bytes (non-final BERT block) or more than 1024 bytes (final BERT block)"
-> Why can't the final block be 1024 bytes? I assume a final BERT block of 1024 bytes is allowed; it would be strange to switch back to SZX=6 for that purpose. What about below text ->
"contain a multiple of 1024 bytes (non-final BERT block) or more than 1023 bytes (final BERT block)"
• Page 23: "block size exponent (2**(SZX+4))" -> "block size (2**(SZX+4))" (Since the exponent is not shown in the notation, rather the resulting size value)
• Page 25: "They are distinct namespaces and are considered to be distinct origin servers" -> Assuming that 'they' refers to the resources. Shouldn't we rather say "They are hosted in distinct namespaces, because each URI scheme implies a distinct origin server."
It seems strange to say that a resource is considered to be namespace,
and a resource is considered to be an origin server. Which is what the
current text states :)
** Nits
• Page 5: Section 1.1 might add a short note that "TCP/TLS" means "TCP or TLS" in this document, and not "TLS over TCP" or so. But perhaps it's obvious to most people.
• Page 9: "modeled on CoAP Options" -> "modeled on the Option Length field in CoAP Options" ?
• Page 13: "Reverse Proxy" -> "reverse-proxy" (to comply with RFC
7252 terminology) • Page 18: "equal or less" -> "equal to or less"
• Page 27, Figure 19: first accolade should extend slightly to the right, second accolade should move slightly to the right.
• Page 28, Section 6.6: the changes indicated could improve in readability a bit by having a form of "old/new indication".
• Page 31, Section 8.1: list bullet can be removed • Global: s/port
component/port subcomponent/ • Page 43: "[2001:DB8::1]" ->
"[2001:db8::1]"
best regards,
Esko Dijk
---
Sent: Wednesday, February 15, 2017 13:17
Subject: [core] 🔔 WGLC draft-ietf-core-coap-tcp-tls
Dear CoRE WG,
There has been quite some work on the "CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets” draft (draft-ietf-core-coap-tcp-tls) since the last WGLC.
BIG thanks to Brian for the time and effort dedicated as Editor. It now seems a good time for a final WGLC to get the last comments from the group in order to move the specification forward.
In particular there has not been much discussion on securing CoAP over WebSockets (https://github.com/core-wg/coap-tcp-tls/issues/102) as well as the Default URI host (https://github.com/core-wg/coap-tcp-tls/issues/108) feedback would be very much welcomed. Please go ahead and check the discussions on the other issues of this version: https://github.com/core-wg/coap-tcp-tls/milestone/4?closed=1 and on the changelog summary. In addition to that, I would like to ask the group to let me know their current implementation status of the draft for the shepherd writeup, especially Open Source implementations of the draft.
https://tools.ietf.org/html/draft-ietf-core-coap-tcp-tls-06
https://tools.ietf.org/rfcdiff?url2=draft-ietf-core-coap-tcp-tls-06.tx
t
https://tools.ietf.org/html/draft-ietf-core-coap-tcp-tls-06#appendix-C
.4
The WGLC will last one week, until 2017-02-22 .
Thanks!
Jaime Jiménez
________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.
_______________________________________________
core mailing list
https://www.ietf.org/mailman/listinfo/core

[Brian Raymor]

Thanks for the questions and feedback. Partial responses below.



** Questions

Post by Dijk, Esko
• The bi-directionality of connections is mentioned in the draft. Now suppose a CoAP client on host 1 opens a TCP connection
(as a TCP client) to a TCP server on host 2, in order to send a CoAP request to it. Now the TCP server (host 2) at some point suddenly
sends a CoAP request (acting itself as a CoAP client) to the TCP client (host 1). However, there is no CoAP server hosted on host 1.
What should happen now? E.g. is the request simply ignored or is some kind of error message returned?
• Same question as above can be stated for TLS and Websockets. Is the behavior the same in these cases?
• Following the above, should the CSM message have an option to indicate a capability of "being a CoAP server" 
 ?

Carsten's suggestion on a private thread addresses this set of questions:

"The intention is for the transport to be bidirectional. If there is a CoAP client, it is easy to have a CoAP server that 4.04s every request. Yes, that is worth making explicit."

Post by Dijk, Esko
• Page 20: Alternative-Address Option - the semantics of including multiple of these options is not defined. Can the receiver pick any of the addresses?
Or does it need to try the first address first? And then keep trying all alternatives until one succeeds, or not?

Unless Carsten or Hannes (authors of draft-bormann-core-coap-sig-02) have a preference, I would suggest that the addresses are unordered (pick any).

Tracked in https://github.com/core-wg/coap-tcp-tls/issues/115

Post by Dijk, Esko
• Page 28, Section 6.5: is it correct to conclude that, for Websocket connections, the default Uri-Port value will be 80 if using "coap+ws" scheme
with its default TCP port, and 443 if using "coaps+ws" scheme with its default TCP port? Just for my understanding.

It depends on the direction. As stated "The default value of the Uri-Port Option is the destination TCP port."

Post by Dijk, Esko
• Appendix A: Why is the update of Observe [RFC7641] done in the Appendix and not in a main section?
There must have been a good reason to place it there; but it looks strange since it formally updates RFC 7641.

There was a desire to have a clean separation between the transport itself and the updates to RFC 7641. Carsten suggested

collecting the changes in an Appendix which was adopted. My original preference was to separately update RFC 7641.

[Jaime Jiménez]

Dear CoRE WG,

we have extended a bit the call as there were few issues left. At this point there aren’t any other issues we will close this call and move the document forward.
Latest version: https://tools.ietf.org/html/draft-ietf-core-coap-tcp-tls-07

Thanks!!
Jaime Jiménez

On 15 Feb 2017, at 14.17, Jaime Jiménez <***@ericsson.com<mailto:***@ericsson.com>> wrote:

Dear CoRE WG,

There has been quite some work on the "CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets” draft (draft-ietf-core-coap-tcp-tls) since the last WGLC.
BIG thanks to Brian for the time and effort dedicated as Editor. It now seems a good time for a final WGLC to get the last comments from the group in order to move the specification forward.

In particular there has not been much discussion on securing CoAP over WebSockets (https://github.com/core-wg/coap-tcp-tls/issues/102) as well as the Default URI host (https://github.com/core-wg/coap-tcp-tls/issues/108) feedback would be very much welcomed. Please go ahead and check the discussions on the other issues of this version: https://github.com/core-wg/coap-tcp-tls/milestone/4?closed=1 and on the changelog summary. In addition to that, I would like to ask the group to let me know their current implementation status of the draft for the shepherd writeup, especially Open Source implementations of the draft.

latest version: https://tools.ietf.org/html/draft-ietf-core-coap-tcp-tls-06
diff: https://tools.ietf.org/rfcdiff?url2=draft-ietf-core-coap-tcp-tls-06.txt
changelog: https://tools.ietf.org/html/draft-ietf-core-coap-tcp-tls-06#appendix-C.4

The WGLC will last one week, until 2017-02-22 .

Thanks!
Jaime Jiménez

[Dijk, Esko]

Jaime & authors,

looking at the recent changes I see only one issue left: the defined behavior of a CoAP endpoint that doesn't implement a CoAP server. The new text states:


If one side does not implement a

CoAP server, an appropriate error response such as 4.04 (Not Found)

or 5.01 (Not Implemented) MUST be returned for all CoAP requests from

the other side.

Requiring with MUST something that's vaguely defined ("such as X or Y") seems a bad idea to me. Besides, when the endpoint would start returning 4.04 then it actually *is* a CoAP server albeit one without any resources. Still it is expected to behave like a CoAP server then – e.g. return 4.02 if an unknown critical option is found in the request, etcetera. To avoid all these issues and to really make clear there is no server at all – i.e. it isn't able to process or validate any request – the following would be much better:


If one side does not implement a

CoAP server, an error response 5.01 (Not Implemented) MUST be

returned for all CoAP requests from the other side.



5.01 in this case means the endpoint hasn't implemented any CoAP methods so it clearly signals that there is no CoAP server. And if there is a CoAP server without resources it can start sending 4.04, but that is to me a different case!



best regards

Esko

From: core [mailto:core-***@ietf.org] On Behalf Of Jaime Jiménez
Sent: Monday, March 13, 2017 15:02
To: ***@ietf.org WG <***@ietf.org>
Cc: draft-ietf-core-coap-tcp-***@ietf.org
Subject: Re: [core] 🔔 WGLC draft-ietf-core-coap-tcp-tls

Dear CoRE WG,

we have extended a bit the call as there were few issues left. At this point there aren’t any other issues we will close this call and move the document forward.
Latest version: https://tools.ietf.org/html/draft-ietf-core-coap-tcp-tls-07

Thanks!!
Jaime Jiménez

On 15 Feb 2017, at 14.17, Jaime Jiménez <***@ericsson.com<mailto:***@ericsson.com>> wrote:

Dear CoRE WG,

There has been quite some work on the "CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets” draft (draft-ietf-core-coap-tcp-tls) since the last WGLC.
BIG thanks to Brian for the time and effort dedicated as Editor. It now seems a good time for a final WGLC to get the last comments from the group in order to move the specification forward.

In particular there has not been much discussion on securing CoAP over WebSockets (https://github.com/core-wg/coap-tcp-tls/issues/102) as well as the Default URI host (https://github.com/core-wg/coap-tcp-tls/issues/108) feedback would be very much welcomed. Please go ahead and check the discussions on the other issues of this version: https://github.com/core-wg/coap-tcp-tls/milestone/4?closed=1 and on the changelog summary. In addition to that, I would like to ask the group to let me know their current implementation status of the draft for the shepherd writeup, especially Open Source implementations of the draft.

latest version: https://tools.ietf.org/html/draft-ietf-core-coap-tcp-tls-06
diff: https://tools.ietf.org/rfcdiff?url2=draft-ietf-core-coap-tcp-tls-06.txt
changelog: https://tools.ietf.org/html/draft-ietf-core-coap-tcp-tls-06#appendix-C.4

The WGLC will last one week, until 2017-02-22 .

Thanks!
Jaime Jiménez


________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

[Carsten Bormann]

Hi Esko,

we didn’t quite feel that we should be restricting the behavior too much.

You are right that

Post by Dijk, Esko
If one side does not implement a
CoAP server, an appropriate error response such as 4.04 (Not Found)
or 5.01 (Not Implemented) MUST be returned for all CoAP requests from
the other side.

is somewhat self-defeating, because as soon as it sends 4.04s it *does* implement a server, so the MUST no longer applies :-)

Post by Dijk, Esko
If one side does not implement a
CoAP server, an error response 5.01 (Not Implemented) MUST be
returned for all CoAP requests from the other side.

And I agree that without the alternatives this is much easier to follow as guidance.

Post by Dijk, Esko
If one side does not implement a
CoAP server, an error response MUST be
returned for all CoAP requests from the other side.
The simplest way to do this is to always return 5.01 (Not Implemented);
a more elaborate mock server could also return 4.xx responses
such as 4.04 or 4.02 where appropriate.

(A mock server that returns 4.02 still has to implement the option parsing for the requests, but that is the same as for the responses and the signaling messages — maybe we should document the minimal behavior for a mock server with 4.02 etc., here or in the newly resurrected lwig-coap draft.)

Grüße, Carsten

[Dijk, Esko]

Hello Carsten,

agree - this separation makes it more clear. And the MUST requirement is also specific now.

Esko

-----Original Message-----
From: Carsten Bormann [mailto:***@tzi.org]
Sent: Tuesday, March 14, 2017 10:03
To: Dijk, Esko <***@philips.com>
Cc: Jaime Jiménez <***@ericsson.com>; draft-ietf-core-coap-tcp-***@ietf.org; ***@ietf.org WG <***@ietf.org>
Subject: Re: [core] 🔔 WGLC draft-ietf-core-coap-tcp-tls

Hi Esko,

we didn’t quite feel that we should be restricting the behavior too much.

You are right that

Post by Dijk, Esko
If one side does not implement a
CoAP server, an appropriate error response such as 4.04 (Not Found)
or 5.01 (Not Implemented) MUST be returned for all CoAP requests from
the other side.

is somewhat self-defeating, because as soon as it sends 4.04s it *does* implement a server, so the MUST no longer applies :-)

Post by Dijk, Esko
If one side does not implement a
CoAP server, an error response 5.01 (Not Implemented) MUST be
returned for all CoAP requests from the other side.

And I agree that without the alternatives this is much easier to follow as guidance.

Post by Dijk, Esko
If one side does not implement a
CoAP server, an error response MUST be
returned for all CoAP requests from the other side.
The simplest way to do this is to always return 5.01 (Not
Implemented); a more elaborate mock server could also return 4.xx
responses such as 4.04 or 4.02 where appropriate.

(A mock server that returns 4.02 still has to implement the option parsing for the requests, but that is the same as for the responses and the signaling messages — maybe we should document the minimal behavior for a mock server with 4.02 etc., here or in the newly resurrected lwig-coap draft.)

Grüße, Carsten


________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

[Brian Raymor]

Captured Carsten's update in https://github.com/core-wg/coap-tcp-tls/pull/123


-----Original Message-----
From: Dijk, Esko [mailto:***@philips.com]
Sent: Tuesday, March 14, 2017 2:16 AM
To: Carsten Bormann <***@tzi.org>
Cc: Jaime Jiménez <***@ericsson.com>; draft-ietf-core-coap-tcp-***@ietf.org; ***@ietf.org WG <***@ietf.org>
Subject: RE: [core] 🔔 WGLC draft-ietf-core-coap-tcp-tls

Hello Carsten,

agree - this separation makes it more clear. And the MUST requirement is also specific now.

Esko

-----Original Message-----
From: Carsten Bormann [mailto:***@tzi.org]
Sent: Tuesday, March 14, 2017 10:03
To: Dijk, Esko <***@philips.com>
Cc: Jaime Jiménez <***@ericsson.com>; draft-ietf-core-coap-tcp-***@ietf.org; ***@ietf.org WG <***@ietf.org>
Subject: Re: [core] 🔔 WGLC draft-ietf-core-coap-tcp-tls

Hi Esko,

we didn’t quite feel that we should be restricting the behavior too much.

You are right that

Post by Dijk, Esko
If one side does not implement a
CoAP server, an appropriate error response such as 4.04 (Not Found)
or 5.01 (Not Implemented) MUST be returned for all CoAP requests from
the other side.

is somewhat self-defeating, because as soon as it sends 4.04s it *does* implement a server, so the MUST no longer applies :-)

Post by Dijk, Esko
If one side does not implement a
CoAP server, an error response 5.01 (Not Implemented) MUST be
returned for all CoAP requests from the other side.

And I agree that without the alternatives this is much easier to follow as guidance.

Post by Dijk, Esko
If one side does not implement a
CoAP server, an error response MUST be
returned for all CoAP requests from the other side.
The simplest way to do this is to always return 5.01 (Not
Implemented); a more elaborate mock server could also return 4.xx
responses such as 4.04 or 4.02 where appropriate.

(A mock server that returns 4.02 still has to implement the option parsing for the requests, but that is the same as for the responses and the signaling messages — maybe we should document the minimal behavior for a mock server with 4.02 etc., here or in the newly resurrected lwig-coap draft.)

Grüße, Carsten


________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

[Robert Quattlebaum]

Hello Everyone,

I had an observation about the implications to observation that the
current text of draft-ietf-core-coap-tcp-tls appendix A seems to have.
I fully realize that I am way too late in this observation, as WGLC
has already come and gone, but I figure it can't hurt to bring it up
and see what others think.

I've got several smart light switches in my house. They all speak CoAP
and can be configured to observe the state of each other. This allows
for a "two-way" switch (called "three-way" in the US) to be
implemented without changing wiring, which I've found to be rather
convenient.

A slightly different scenario I have implemented is where I have one
switch (Switch-A) that, when turned on or off, will turn on (or off)
several other lights (Switch-B) which are all on dimmers. I can then
walk over to those lights and control them individually (perhaps
turning them off, or by adjusting the dimmer) to suit my needs at the
time. When leaving the room I can turn them all off by controlling the
light switch at the entrance to the room.

To implement this, I have Switch-B observe the value of Switch-A.
However, to allow local changes, Switch-B keeps track of the observe
counter to determine if the value has been updated or not.

Now, you might say that I should use ETags for this. But Etags only
tell me if the value is the same as the last time I retrieved (or
observed) a resource, it doesn't necessarily tell me if the resource
had changed in the mean time. A resource could have changed to a
different value and then changed back. Also, ETags are optional. If
you are observing a resource, Observe counters are (or at least were)
required.

My own (ab)use of the Observe counter aside, the current language in
section A.1 of draft-ietf-core-coap-tcp-tls also makes the life of a
CoAP non-caching proxy/bridge more difficult by requiring additional
state to keep track of. Imagine a CoAP UDP-only node (Node-A) which is
observing a resource on another device (Node-B, TLS-only) via a CoAP
proxy. If the proxy connects to Node-B using TLS or WebSockets, then
Node-B may opt to leave the value on the Observe option empty. That
means the CoAP proxy must now keep track of what observations are
occurring, regenerating an index and populating the observe header
before sending the observe packet to Node-A. Even if Node-B did
include an Observe count, the current language says the proxy MUST
ignore it.

Section A.3 also seems to have similar problems in the proxy case. If
Node-B is trying to observe a resource on Node-A and it follows the
guidance in section A.3, it is going to be checking for the health of
the connection to the proxy rather than sending individual GET
requests. This means that the proxy is going to have to send its own
GET requests to Node-A to ensure liveliness.

Again, I fully realize that I missed the boat when it comes to this
sort of feedback, but nonetheless I wanted to go ahead and put this
out there to see what others thought.

- -\- RQ

[Michael Koster]

Hi,

It seems that we have inadvertently removed some signaling functionality that is not solely related to the persistence of the TLS connection.

The observe option is more than simply a sequence number. It also a signal used by the server to indicate to the client that it is unwilling to send or to continue to send notifications. Making it optional and requiring it to be ignored removes the ability for the server to gracefully end or limit observe/notify operations.


When included in a response, the Observe Option identifies the
message as a notification. This implies that a matching entry exists
in the list of observers and that the server will notify the client
of changes to the resource state.


A server that is unable or unwilling to add a new entry to the list
of observers of a resource MAY silently ignore the registration
request and process the GET request as usual. The resulting response
MUST NOT include an Observe Option, the absence of which signals to
the client that it will not be notified of changes to the resource
and, e.g., needs to poll the resource for its state instead.


Best regards,

Michael

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hello Everyone,
I had an observation about the implications to observation that the
current text of draft-ietf-core-coap-tcp-tls appendix A seems to have.
I fully realize that I am way too late in this observation, as WGLC
has already come and gone, but I figure it can't hurt to bring it up
and see what others think.
I've got several smart light switches in my house. They all speak CoAP
and can be configured to observe the state of each other. This allows
for a "two-way" switch (called "three-way" in the US) to be
implemented without changing wiring, which I've found to be rather
convenient.
A slightly different scenario I have implemented is where I have one
switch (Switch-A) that, when turned on or off, will turn on (or off)
several other lights (Switch-B) which are all on dimmers. I can then
walk over to those lights and control them individually (perhaps
turning them off, or by adjusting the dimmer) to suit my needs at the
time. When leaving the room I can turn them all off by controlling the
light switch at the entrance to the room.
To implement this, I have Switch-B observe the value of Switch-A.
However, to allow local changes, Switch-B keeps track of the observe
counter to determine if the value has been updated or not.
Now, you might say that I should use ETags for this. But Etags only
tell me if the value is the same as the last time I retrieved (or
observed) a resource, it doesn't necessarily tell me if the resource
had changed in the mean time. A resource could have changed to a
different value and then changed back. Also, ETags are optional. If
you are observing a resource, Observe counters are (or at least were)
required.
My own (ab)use of the Observe counter aside, the current language in
section A.1 of draft-ietf-core-coap-tcp-tls also makes the life of a
CoAP non-caching proxy/bridge more difficult by requiring additional
state to keep track of. Imagine a CoAP UDP-only node (Node-A) which is
observing a resource on another device (Node-B, TLS-only) via a CoAP
proxy. If the proxy connects to Node-B using TLS or WebSockets, then
Node-B may opt to leave the value on the Observe option empty. That
means the CoAP proxy must now keep track of what observations are
occurring, regenerating an index and populating the observe header
before sending the observe packet to Node-A. Even if Node-B did
include an Observe count, the current language says the proxy MUST
ignore it.
Section A.3 also seems to have similar problems in the proxy case. If
Node-B is trying to observe a resource on Node-A and it follows the
guidance in section A.3, it is going to be checking for the health of
the connection to the proxy rather than sending individual GET
requests. This means that the proxy is going to have to send its own
GET requests to Node-A to ensure liveliness.
Again, I fully realize that I missed the boat when it comes to this
sort of feedback, but nonetheless I wanted to go ahead and put this
out there to see what others thought.
- -\- RQ
-----BEGIN PGP SIGNATURE-----
iQEcBAEBCAAGBQJY4seZAAoJEE6OLsxF2Ko6s+QH/jhkaA19Mp9Ub02yfyUzkKa3
xaWtEIhAUxHFe0TXv9sbwJUi8V4q4Qb+VZRYWJqZB/u6SdLayTledcKKXYHId6ZB
EqcKyFb29k3oFZs1hvtZxBtowekAlpV7efLxLNB+DFkioOl8AYEhibmAeQunJTZP
KTpPhZiImsrZVScOSGT12wZ5/ogzjYTHOv9kM6DN4B/hrqt2ylxW/FS/7oxfr/My
7iRYof+dJvoD1Yz1xtJoNphQk1wja4eDyNuwAYkFlhdCPxpokG1BekLYmjGIQxHc
h0k8buaj4uXdFE9RiAIDNCUx5zu+1Ur1Q2my37zbHzznPC8NgwCRSw7oMxt/ukY=
=G/G9
-----END PGP SIGNATURE-----
_______________________________________________
core mailing list
https://www.ietf.org/mailman/listinfo/core

[Klaus Hartke]

Post by Michael Koster
The observe option is more than simply a sequence number. It also a signal
used by the server to indicate to the client that it is unwilling to send or
to continue to send notifications. Making it optional and requiring it to be
ignored removes the ability for the server to gracefully end or limit
observe/notify operations.

draft-ietf-core-coap-tcp-tls doesn't make the Observe option optional.
The presence of the option still signals if the client is in the list
of observers or not. But since TCP already deals with reordering, the
sequence number inside the Observe in notifications is not needed any
more.

Klaus

[Michael Koster]

I see it now; the observe option must be included but may be empty. The value must be ignored.

Thanks!

Michael

Post by Klaus Hartke

Post by Michael Koster
The observe option is more than simply a sequence number. It also a signal
used by the server to indicate to the client that it is unwilling to send or
to continue to send notifications. Making it optional and requiring it to be
ignored removes the ability for the server to gracefully end or limit
observe/notify operations.

draft-ietf-core-coap-tcp-tls doesn't make the Observe option optional.
The presence of the option still signals if the client is in the list
of observers or not. But since TCP already deals with reordering, the
sequence number inside the Observe in notifications is not needed any
more.
Klaus

[Carsten Bormann]

Post by Michael Koster
I see it now; the observe option must be included but may be empty. The value must be ignored.

Add “in a 2.xx response that indicates an ongoing observation interest”, and you are almost right (for an option of uint format, being “empty” just means the number is 0; maybe we should have said that in A.1).

Grüße, Carsten

[Michael Koster]

Ah, of course, the value will still be relevant when it indicates cancellation.

I think a little more text or a little more thought would have helped me.

Best regards,

Michael

Post by Carsten Bormann

Post by Michael Koster
I see it now; the observe option must be included but may be empty. The value must be ignored.

Add “in a 2.xx response that indicates an ongoing observation interest”, and you are almost right (for an option of uint format, being “empty” just means the number is 0; maybe we should have said that in A.1).
Grüße, Carsten

[Jim Schaad]

This would indicate to me that there needs to be some text in the document about dealing with transitions from TCP->UDP and the other direction. If the value is "unneeded" and "ignored" then you might end up with problems if a proxy going between these two different transports does not do the right thing in terms of putting in "good" values for the observe option.

Are there other places where the fact that TCP has reliable deliver that are going to cause problems for proxies? For example, should a UDP->TCP proxy always ack a request since it is going from unreliable to reliable delivery?

Jim

Post by Brian Raymor
-----Original Message-----
Sent: Tuesday, April 4, 2017 7:21 AM
Subject: Re: [core] 🔔 WGLC draft-ietf-core-coap-tcp-tls

Post by Michael Koster
The observe option is more than simply a sequence number. It also a
signal used by the server to indicate to the client that it is
unwilling to send or to continue to send notifications. Making it
optional and requiring it to be ignored removes the ability for the
server to gracefully end or limit observe/notify operations.

draft-ietf-core-coap-tcp-tls doesn't make the Observe option optional.
The presence of the option still signals if the client is in the list of observers or
not. But since TCP already deals with reordering, the sequence number inside
the Observe in notifications is not needed any more.
Klaus
_______________________________________________
core mailing list
https://www.ietf.org/mailman/listinfo/core

[Carsten Bormann]

Post by Jim Schaad
This would indicate to me that there needs to be some text in the document about dealing with transitions from TCP->UDP and the other direction. If the value is "unneeded" and "ignored" then you might end up with problems if a proxy going between these two different transports does not do the right thing in terms of putting in "good" values for the observe option.

The Observe value in a response is not meant to be end-to-end (it cannot be, as observations are hop-by-hop).

RFC 7641 may be slightly opaque here, but Section 5 does say:

Each hop MUST generate
its own values for the Observe Option in notifications

See also Figure 8 in RFC 7641 for an example of how that looks like.

Post by Jim Schaad
Are there other places where the fact that TCP has reliable deliver that are going to cause problems for proxies? For example, should a UDP->TCP proxy always ack a request since it is going from unreliable to reliable delivery?

Any UDP CoAP in a proxy will send ACKs right away (maybe with a little piggyback timeout), independent of whether the request then goes out via TCP or UDP. So this is not a new thing.

Grüße, Carsten

[Klaus Hartke]

Post by Jim Schaad
This would indicate to me that there needs to be some text in the document about dealing with transitions from TCP->UDP and the other direction. If the value is "unneeded" and "ignored" then you might end up with problems if a proxy going between these two different transports does not do the right thing in terms of putting in "good" values for the observe option.

Section 5 of RFC 7641 [1] contains some text that explains how
intermediaries work in the context of resource observation. In short,
resource observation is a hop-by-hop feature: In a
client--proxy--server chain, the Proxy generates the notifications and
sequence numbers for the client; and the server generates the
notifications and sequence numbers for the proxy. A TCP<->UDP
transition does not change that.

Post by Jim Schaad
Are there other places where the fact that TCP has reliable deliver that are going to cause problems for proxies? For example, should a UDP->TCP proxy always ack a request since it is going from unreliable to reliable delivery?

Acknowledgements in CoAP-over-UDP are a hop-by-hop feature as well: In
a client--proxy--server chain, the proxy acknowledges the confirmable
messages from the client; and the server acknowledges the confirmable
messages from the proxy. An acknowledgement in CoAP has no meaning
other than "I have received your confirmable message; you can stop
retransmitting it now." Over TCP, TCP does the retransmission and
acknowledgement, so the messaging layer of CoAP-over-UDP is not
needed.

I can see some problems if someone tries to implement a CoAP proxy by
rewriting UDP datagrams into TCP segments. But that's not how CoAP
proxies are intended to work.

Klaus

[1] https://tools.ietf.org/html/rfc7641#section-5

[Robert Quattlebaum]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

That ACKs are hop-by-hop makes total intuitive sense to me. That CoAP
observations are hop-by-hop makes considerably less intuitive sense to
me. That being said, it's hard to argue with the text from RFC7641

Each hop MUST generate its own values for the Observe Option in
notifications

This seems baffling to me, as it requires each "hop" to be aware of
observations when it wouldn't necessarily otherwise be required for
the feature to work¹. Even when the proxy is aggregating observations
(as it ideally should be), reusing the same numbers from the origin
seems like it would have been a good idea, were it not for this text.
But RFC7641 is cooked, so it is what it is. This text from RFC7641
does appear to make section A.1 from draft-ietf-core-coap-tcp-tls more
consistent.

An unfortunate consequence of this design is that it implies momentary
changes in the value of an observed resource cannot be reliably
detected across a "hop", but in the grand scheme of things I suppose
it isn't that big of a deal.

- -\- RQ

¹ I realize that this is technically incorrect, because for that to
work resets would need to be propagated across "hops", too. I think
it is rather unfortunate that resets are not propagated across
hops, since it would have allowed for relatively dumb proxies. But
seeing that apparently well-established consensus is that resets
are not intended to propagate across hops I won't press the issue
further.


-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJY49ulAAoJEE6OLsxF2Ko6dBUH+QEga+qDxbg0jgXZOx/bE8Uo
WJtatgpXZIXKmmyePG2hNf+DZWBWnoo4n4N/NumLM3GD+vHSdDuWjNaWmCFSLnxx
keKfuMpuppyV8k3ZIAeCJVsJw6+irysOzUb1t/izRwmvu+AZdmtH4VbnKy1WgOPf
kTl55I74FEG/duy0jzL7rpOSJiUKrgazWHM4xTSgRZvQqj4/yOtOvx2AZAhNdXbn
ENy4yVYZUsvJgDMfHXWHx9comRUTMaff202MjBompFiWyiyfB73kyjTsStLjYlDb
D/6P0lWXh35lA2VIsANptr8Dl4f29bo9SwSrPwhcrMRn4VquRizFd6wnl8nVynY=
=T675
-----END PGP SIGNATURE-----

Post by Jim Schaad
This would indicate to me that there needs to be some text in the document about dealing with transitions from TCP->UDP and the other direction. If the value is "unneeded" and "ignored" then you might end up with problems if a proxy going between these two different transports does not do the right thing in terms of putting in "good" values for the observe option.

Section 5 of RFC 7641 [1] contains some text that explains how
intermediaries work in the context of resource observation. In short,
resource observation is a hop-by-hop feature: In a
client--proxy--server chain, the Proxy generates the notifications and
sequence numbers for the client; and the server generates the
notifications and sequence numbers for the proxy. A TCP<->UDP
transition does not change that.

Post by Jim Schaad
Are there other places where the fact that TCP has reliable deliver that are going to cause problems for proxies? For example, should a UDP->TCP proxy always ack a request since it is going from unreliable to reliable delivery?

Acknowledgements in CoAP-over-UDP are a hop-by-hop feature as well: In
a client--proxy--server chain, the proxy acknowledges the confirmable
messages from the client; and the server acknowledges the confirmable
messages from the proxy. An acknowledgement in CoAP has no meaning
other than "I have received your confirmable message; you can stop
retransmitting it now." Over TCP, TCP does the retransmission and
acknowledgement, so the messaging layer of CoAP-over-UDP is not
needed.
I can see some problems if someone tries to implement a CoAP proxy by
rewriting UDP datagrams into TCP segments. But that's not how CoAP
proxies are intended to work.
Klaus
[1] https://tools.ietf.org/html/rfc7641#section-5
_______________________________________________
core mailing list
https://www.ietf.org/mailman/listinfo/core

[Jim Schaad]

That ACKs are hop-by-hop does not make total intuitive sense to me, because the proxies that I have dealt with are much more stateless and therefore are far more likely to let the retransmission be largely invisible to them. This is the model that I am far more used to from protocols such as RADIUS where we are trying to deal with the questions of how re-tries are done when moving from UDP to TCP and back. If you ACK back from the proxy, then the client may never know that the server is down or is not going to respond. Does a proxy know that it needs to fail some way if it later times out? Really lightweight proxies are not going to do this.

Jim

Post by Brian Raymor
-----Original Message-----
Sent: Tuesday, April 4, 2017 10:49 AM
Subject: Re: [core] 🔔 WGLC draft-ietf-core-coap-tcp-tls
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
That ACKs are hop-by-hop makes total intuitive sense to me. That CoAP
observations are hop-by-hop makes considerably less intuitive sense to me.
That being said, it's hard to argue with the text from RFC7641 that Carsten

Each hop MUST generate its own values for the Observe Option in
notifications

This seems baffling to me, as it requires each "hop" to be aware of
observations when it wouldn't necessarily otherwise be required for the
feature to work¹. Even when the proxy is aggregating observations (as it ideally
should be), reusing the same numbers from the origin seems like it would
have been a good idea, were it not for this text.
But RFC7641 is cooked, so it is what it is. This text from RFC7641 does appear
to make section A.1 from draft-ietf-core-coap-tcp-tls more consistent.
An unfortunate consequence of this design is that it implies momentary
changes in the value of an observed resource cannot be reliably detected
across a "hop", but in the grand scheme of things I suppose it isn't that big of a
deal.
- -\- RQ
¹ I realize that this is technically incorrect, because for that to
work resets would need to be propagated across "hops", too. I think
it is rather unfortunate that resets are not propagated across
hops, since it would have allowed for relatively dumb proxies. But
seeing that apparently well-established consensus is that resets
are not intended to propagate across hops I won't press the issue
further.
-----BEGIN PGP SIGNATURE-----
iQEcBAEBCAAGBQJY49ulAAoJEE6OLsxF2Ko6dBUH+QEga+qDxbg0jgXZOx/bE8U
o
WJtatgpXZIXKmmyePG2hNf+DZWBWnoo4n4N/NumLM3GD+vHSdDuWjNaWm
CFSLnxx
keKfuMpuppyV8k3ZIAeCJVsJw6+irysOzUb1t/izRwmvu+AZdmtH4VbnKy1WgOP
f
kTl55I74FEG/duy0jzL7rpOSJiUKrgazWHM4xTSgRZvQqj4/yOtOvx2AZAhNdXbn
ENy4yVYZUsvJgDMfHXWHx9comRUTMaff202MjBompFiWyiyfB73kyjTsStLjYlDb
D/6P0lWXh35lA2VIsANptr8Dl4f29bo9SwSrPwhcrMRn4VquRizFd6wnl8nVynY=
=T675
-----END PGP SIGNATURE-----

Post by Jim Schaad
This would indicate to me that there needs to be some text in the

document about dealing with transitions from TCP->UDP and the other
direction. If the value is "unneeded" and "ignored" then you might end up
with problems if a proxy going between these two different transports does
not do the right thing in terms of putting in "good" values for the observe
option.

Section 5 of RFC 7641 [1] contains some text that explains how
intermediaries work in the context of resource observation. In short,
resource observation is a hop-by-hop feature: In a
client--proxy--server chain, the Proxy generates the notifications and
sequence numbers for the client; and the server generates the
notifications and sequence numbers for the proxy. A TCP<->UDP
transition does not change that.

Post by Jim Schaad
Are there other places where the fact that TCP has reliable deliver that are

going to cause problems for proxies? For example, should a UDP->TCP proxy
always ack a request since it is going from unreliable to reliable delivery?

Acknowledgements in CoAP-over-UDP are a hop-by-hop feature as well: In
a client--proxy--server chain, the proxy acknowledges the confirmable
messages from the client; and the server acknowledges the confirmable
messages from the proxy. An acknowledgement in CoAP has no meaning
other than "I have received your confirmable message; you can stop
retransmitting it now." Over TCP, TCP does the retransmission and
acknowledgement, so the messaging layer of CoAP-over-UDP is not
needed.
I can see some problems if someone tries to implement a CoAP proxy by
rewriting UDP datagrams into TCP segments. But that's not how CoAP
proxies are intended to work.
Klaus
[1] https://tools.ietf.org/html/rfc7641#section-5
_______________________________________________
core mailing list
https://www.ietf.org/mailman/listinfo/core

[Michael Koster]

Hi,

My reading of how Etags work in both HTTP and CoAP implies that the Etag changes value every time a resource state update occurs. In a practical sense, if a resource changes value and then back to some previously held value, the Etag should change to a new unique value. I don't imagine an implementation trying to re-use an Etag when the resource value matches some previous value. But I could be missing something.

Is this a reasonable interpretation?

Best regards,

Michael

Post by Robert Quattlebaum
Now, you might say that I should use ETags for this. But Etags only
tell me if the value is the same as the last time I retrieved (or
observed) a resource, it doesn't necessarily tell me if the resource
had changed in the mean time. A resource could have changed to a
different value and then changed back. Also, ETags are optional. If
you are observing a resource, Observe counters are (or at least were)
required.

[Klaus Hartke]

Post by Michael Koster
My reading of how Etags work in both HTTP and CoAP implies that the Etag
changes value every time a resource state update occurs. In a practical
sense, if a resource changes value and then back to some previously held
value, the Etag should change to a new unique value. I don't imagine an
implementation trying to re-use an Etag when the resource value matches some
previous value. But I could be missing something.

The point of caches is to reuse earlier responses as often as
possible. So, if a resource changes back to some earlier state, it
would be beneficial if the response describing that state could be
reused. Using a different Etag for the same response would be
counterproductive.

Klaus

[Carsten Bormann]

Post by Michael Koster
I don't imagine an implementation trying to re-use an Etag when the resource value matches some previous value.

In many implementations the ETag is simply a hash over the representation.

(There is a lot of discussion about ETags on the Web; e.g., see https://www.mnot.net/blog/2007/08/07/etags .)

Grüße, Carsten

[Michael Koster]

OK, thanks for the clarifications. That makes sense, especially for enumerations.

Michael

Post by Carsten Bormann

Post by Michael Koster
I don't imagine an implementation trying to re-use an Etag when the resource value matches some previous value.

In many implementations the ETag is simply a hash over the representation.
(There is a lot of discussion about ETags on the Web; e.g., see https://www.mnot.net/blog/2007/08/07/etags .)
Grüße, Carsten