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

From: Jaime Jiménez <[email-masked]>
Date: Wed, 15 Feb 2017 12:17:00 +0000

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

---

From: "Dijk, Esko" <[email-masked]>
Date: Mon, 20 Feb 2017 15:18:30 +0000

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:[email-masked]] On Behalf Of Jaime Jiménez
Sent: Wednesday, February 15, 2017 13:17
To: [email-masked] WG <[email-masked]>
Cc: [email-masked]
Subject: [core] 🔔 WGLC draft-ietf-core-coap-tcp-tls

Dear CoRE WG,

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.

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 21 Feb 2017 15:04:04 +0100

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.

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.

OK.

OK.

Ciao
Hannes

On 02/20/2017 04:18 PM, Dijk, Esko wrote:
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>

---

From: Brian Raymor <[email-masked]>
Date: Tue, 28 Feb 2017 01:39:50 +0000

Thanks for the questions and feedback. Partial responses below.

** 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?

> • 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."

> • 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

> • 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."

> • 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.

---

From: Brian Raymor <[email-masked]>
Date: Tue, 28 Feb 2017 21:19:40 +0000

Thanks to Hannes for addressing some of the editorial comments.

I made a second pass on the remaining comments:

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

I removed the unused reference to RFC6454.

>> • 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:

OK.

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

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.

>>• 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.

>> • 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.

>> • Page 31, Section 8.1: list bullet can be removed

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:[email-masked]] 
Sent: Tuesday, February 21, 2017 6:04 AM
To: Dijk, Esko <[email-masked]>; [email-masked] WG <[email-masked]>
Cc: [email-masked]
Subject: Re: [core] 🔔 WGLC draft-ietf-core-coap-tcp-tls

** 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.

Fixed.

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

** Nits

OK. Clarified.

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

OK.

OK.

OK.

OK.

OK.

OK.

Ciao
Hannes

On 02/20/2017 04:18 PM, Dijk, Esko wrote:
> ** 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.
> 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 13: "Reverse Proxy" -> "reverse-proxy"  (to comply with RFC 
> 7252 terminology) • Page 18: "equal or less" -> "equal to or less"
> • 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
> ---
> 
> 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.tx
> t
> changelog: 
> https://tools.ietf.org/html/draft-ietf-core-coap-tcp-tls-06#appendix-C
> .4
>