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

From: Brian Raymor <[email-masked]>
Date: Tue, 20 Dec 2016 01:24:24 +0000

Thanks for the feedback, Carsten.

>         1.  Introduction

>            [...] Although HTTP/2

>            could also potentially address these requirements, there would be

>            additional costs and delays introduced by such a transition.

>            Currently, there are also fewer HTTP/2 implementations available for

>            constrained devices in comparison to CoAP.

> These sentences are lame; I still don't understand why they are needed.

> The main point here is that HTTP/2 is a complexity fest compared to CoAP.

> Also, HTTP/2 has not yet been extended by important concepts such as

> Observe.

The context is in in https://github.com/core-wg/coap-tcp-tls/issues/50.

My understanding is that Dave Thaler and you reviewed during IETF 97.

I have no plans to re-open at this time.

>            [...]

>           In addition, some corporate networks only allow Internet access via a

>           HTTP proxy.  In this case, the best transport for CoAP would be the

>           WebSocket Protocol [RFC6455].  The WebSocket protocol provides two-

> Well, an HTTP proxy won't necessarily allow WebSockets through.

Do you have a suggestion? Perhaps “might be” rather than “would be”?

>        1.1.  Terminology

>           [...]

>          This document assumes that readers are familiar with the terms and

>           concepts that are used in [RFC6455], [RFC7252], and [RFC7641].

> and RFC 7959.

https://github.com/core-wg/coap-tcp-tls/issues/84

>           The term "reliable transport" only refers to stream-based transport

>           protocols such as TCP.

>s/only refers/is used only to refer/

>(We could say more explicitly: sequenced/order-preserving, reliable...

>Stream might be byte stream or message stream.)

https://github.com/core-wg/coap-tcp-tls/issues/49

>         2.1.  Messaging Model

>            Conceptually, CoAP over TCP replaces most of the CoAP over UDP

>            message layer with a framing mechanism on top of the byte stream

>            provided by TCP/TLS, conveying the length information for each

>            message that on datagram transports is provided by the UDP/DTLS

>            datagram layer.

> s/CoAP over UDP message layer/message layer of CoAP over UDP/

https://github.com/core-wg/coap-tcp-tls/issues/85

>               Figure 2: Comparison between CoAP over unreliable and reliable

>                                         transport.

> Captions are not sentences and therefore don't end in periods (see

> Figure 1). (Comment not repeated further down.)

https://github.com/core-wg/coap-tcp-tls/issues/86

>         2.3.  Opening Handshake

>           [...]

>            Clients and servers MUST treat a missing or invalid CSM as a

>            connection error and abort the connection (see Section 4.6).

> This is probably the right thing to do, but it does mean that we are now

> incompatible again with the OCF 1.0 version of CoAP over TCP.

> We could define an OCF 1.0 compatibility mode.

The question about OCF feedback was discussed at IETF 97. My expectation is that OCF

members will directly bring issues to the WG. In addition, if there was a compatibility mode,

it would be in the framework rather than the protocol draft.

>         2.4.  Message Format

>           [...]

>            o  In a stream oriented transport protocol such as TCP, a form of

> s/stream/byte stream/

> (We probably should review the entire terminology about "reliable",

> sequence-preserving, byte/message streams once more.)

https://github.com/core-wg/coap-tcp-tls/issues/49

>            0                   1                   2                   3

>             0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

>            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

>            |Len=13 |  TKL  |Extended Length|      Code     | TKL bytes ...

>            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

>            |  Options (if any) ...

>            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

>            |1 1 1 1 1 1 1 1|    Payload (if any) ...

>            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

>                   Figure 4: CoAP frame with 8-bit Extended Length field.

> This (and neither does the text) does not make clear that the payload

> marker is sent only if there is a non-zero-length payload.  (Same for

> other below.)

> Please cf. text from Section 3 of RFC 7252:

>    Following the header, token, and options, if any, comes the optional

>    payload.  If present and of non-zero length, it is prefixed by a

>    fixed, one-byte Payload Marker (0xFF), which indicates the end of

>    options and the start of the payload.  The payload data extends from

>    after the marker to the end of the UDP datagram, i.e., the Payload

>    Length is calculated from the datagram size.  The absence of the

>    Payload Marker denotes a zero-length payload.  The presence of a

>    marker followed by a zero-length payload MUST be processed as a

>    message format error.

https://github.com/core-wg/coap-tcp-tls/issues/87

>         3.  CoAP over WebSockets

Unless otherwise noted below, the feedback for Section 3 is captured

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

>            [...]

> Hmm, why is the following done here for WS and not above for TCP?

> Seems redundant with 6.2?  Oh, the point here is to derive the ws[s]

> URI used for setting up the WS?

>            Section 6.2 defines a new "coap+ws" URI scheme that identifies both a

>            WebSocket endpoint and a resource within that endpoint as follows:

>                      coap+ws://example.org/sensors/temperature?u=Cel

>                           \______  ______/\___________  ___________/

>                                  \/                   \/

>                                                     Uri-Path: "sensors"

>                ws://example.org/.well-known/coap    Uri-Path: "temperature"

>                                                     Uri-Query: "u=Cel"

>                             Figure 10: The "coap+ws" URI Scheme

It appears that you answered your own question.

> The following now seems unrelated:

>            Another possible configuration is to set up a CoAP forward proxy at

>            the WebSocket endpoint.  Depending on what transports are available

>            [...]

>              Figure 12: CoAP Client (UDP client) accesses sleepy CoAP Server

>             (WebSocket client) via a CoAP proxy (UDP server/WebSocket server)

> s/sleepy//

> (There is no mention of sleepiness here.)

>            [...]

>            CoAP over WebSockets is intentionally very similar to CoAP over UDP.

>            Therefore, instead of presenting CoAP over WebSockets as a new

>            protocol, this document specifies it as a series of deltas from

>            [RFC7252].

> Probably best to delete that paragraph -- it is true not only for WS,

> but also for TCP.  So why only here?

>         3.1.  Opening Handshake

> Hmm, the title is confusing.  WS also uses the same opening handshake as 2.3.

> The parts that relate to both TCP/TLS and WS/S need to be factored out.

>         3.2.  Message Format

>            [...]

>            The message format shown in Figure 14 is the same as the CoAP over

>            TCP message format (see Section 2.4) with one restriction.  The

>            Length (Len) field MUST be set to zero because the WebSockets frame

>            already contains the length.

> s/restriction/change/.

>            [...]

>                0                   1                   2                   3

>               0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

>              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

>              |   Len |  TKL  |      Code     |    Token (TKL bytes) ...

>              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

>              |   Options (if any) ...

>              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

>              |1 1 1 1 1 1 1 1|    Payload (if any) ...

>              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

>                       Figure 14: CoAP Message Format over WebSockets

> Maybe show 0, not Len here.

> (This also does not make clear that the payload marker is sent only if

> there is a non-zero-length payload.)

Added to https://github.com/core-wg/coap-tcp-tls/issues/87

>            The CoAP over TCP message format eliminates the Version field defined

>            in CoAP over UDP.  If CoAP version negotiation is required in the

>            future, CoAP over WebSockets can address the requirement by the

>           definition of a new subprotocol identifier that is negotiated during

>           the opening handshake.

> This paragraph is a bit weird.  Maybe:

>    As with CoAP over TCP, the message format for CoAP over Websockets

>    eliminates the Version field defined in CoAP over UDP.  If CoAP [...]

>            [...]

>            Empty messages (Code 0.00) MUST be ignored by the recipient (see also

>            Section 4.4).

> Why are we saying this here and not in Section 2?

> Factor out.

>         3.3.  Message Transmission

>            [...]

> Similar as with CoAP over TCP,

>            Retransmission and deduplication of messages is provided by the

>            WebSocket protocol.  CoAP over WebSockets therefore does not make a

>            distinction between Confirmable or Non-Confirmable messages, and does

>            not provide Acknowledgement or Reset messages.

>         3.4.  Connection Health

>           [...]

>            There is no way to retransmit a request without creating a new one.

>            Re-registering interest in a resource is permitted, but entirely

>            unnecessary.

> (See the discussion we already had.)

The discussion is in https://github.com/core-wg/coap-tcp-tls/issues/71

>         4.  Signaling

Unless otherwise noted below, the feedback for Section 4 is captured

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

>            Signaling messages are introduced to allow peers to:

>            o  Share characteristics such as maximum message size for the connection

> s/Share/Relate/

> (the nodes do not "share these characteristics")

>            o  Shutdown the connection in an ordered fashion

> Shut down

> s/Ordered/Orderly/

>            o  Terminate the connection in response to a serious error condition

> Provide diagnostic information when terminating a connection in ...

>         4.3.  Capability and Settings Messages (CSM)

> Hmm, should this be "Capabilities and Settings Messages"?

> (Need to change throughout.)

>            Capability and Settings messages (CSM) are used for two purposes:

>            o  Each capability option advertises one capability of the sender to

>               the recipient.

>            o  Setting options indicate a setting that will be applied by the

>               sender.

> s/A/One/

> s/Capability and Settings message/CSM/

>            A Capability and Settings message MUST be sent by both endpoints at

>           the start of the connection and MAY be sent at any other time by

> s/and/. Further CSM/

>            either endpoint over the lifetime of the connection.

>            Both capability and settings options are cumulative.  A Capability

> s/settings/setting/

>            and Settings message does not invalidate a previously sent capability

>            indication or setting even if it is not repeated.  A capability

>            message without any option is a no-operation (and can be used as

>            such).  An option that is sent might override a previous value for

>        4.3.1.  Server-Name Setting Option

>           [...]

>            For TLS, the initial value for the Server-Name Option is given by the

>            SNI value.

> s/initial/base/???

This is already addressed in my pending pull request - https://github.com/core-wg/coap-tcp-tls/pull/67/commits/6ea12a700afe8ed8d909691af4fc456ebefb618e

>         4.3.2.  Max-Message-Size Capability Option

>            As per Section 4.6 of [RFC7252], the base value (and the value used

>            when this option is not implemented) is 1152.  A peer that relies on

>            this option being indicated with a certain minimum value will enjoy

>            limited interoperability.

> (above 1152?)

> 6.  CoAP URIs

Unless otherwise noted below, the feedback for Section 6 is captured

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

>            CoAP over UDP [RFC7252] defines the "coap" and "coaps" URI schemes

>            for identifying CoAP resources and providing a means of locating the

>            resource.

> In this section, the terms "client" and "server" are used WRT the TCP

> connection, not WRT CoAP, and that may be very confusing.  Maybe use

> different terms here (initiator/responder)?

>         6.1.  CoAP over TCP and TLS URIs

>            [RFC7252], Section 8 (Multicast CoAP) is not applicable to these schemes.

> Not sure this belongs here, but it also should apply to 6.2, so maybe

> move it up to 6.

>            Resources made available via one of the "coap+tcp" or "coaps+tcp"

>            schemes have no shared identity with the other scheme or with the

>            "coap" or "coaps" scheme, even if their resource identifiers indicate

>            the same authority (the same host listening to the same port).  The

>            schemes constitute distinct namespaces and, in combination with the

>            authority, are considered to be distinct origin servers.

> Ditto.

>         6.2.  CoAP over WebSockets URIs

>            For the first configuration discussed in Section 3, this document

>           defines two new URIs schemes that can be used for identifying CoAP

>           resources and providing a means of locating these resources:

>           "coap+ws" and "coap+wss".

> coap+wss is the only coaps scheme that doesn't have coaps in the name.

> I continue to believe that this is a mistake.

> s/coap+wss/coaps+ws/g.

This is the bikeshed - http://bikeshed.com/ - which was discussed at IETF 96 with no

consensus and raised again at the informal CoRE meeting at IETF 97 with no opinions

expressed from the participants.

Our preferences are both noted in - https://github.com/core-wg/coap-tcp-tls/issues/12.

I’d defer to the chair for coap-tcp-tls (Jaime) on how he’d like to proceed.

>            Similar to the "coap" and "coaps" schemes, the "coap+ws" and

>            "coap+wss" schemes organize resources hierarchically under a CoAP

>            origin server.  The key difference is that the server is potentially

>            reachable on a WebSocket endpoint instead of a UDP endpoint.

> s/potentially reachable/intended to be reached/

>            The WebSocket endpoint is identified by a "ws" or "wss" URI that is

>            composed of the authority part of the "coap+ws" or "coap+wss" URI,

>            respectively, and the well-known path "/.well-known/coap" [RFC5785].

>            The path and query parts of a "coap+ws" or "coap+wss" URI identify a

>            resource within the specified endpoint which can be operated on by

>           the methods defined by CoAP.

> The following paragraph applies to 6.1.1, 6.1.2, and this subsection.

> (Move up to 6.)

>            The syntax of the "coap+ws" and "coap+wss" URI schemes is specified

>            below in Augmented Backus-Naur Form (ABNF) [RFC5234].  The

>            definitions of "host", "port", "path-abempty" and "query" are the

>            same as in [RFC3986].

>              coap-ws-URI =

>                 "coap+ws:" "//" host [ ":" port ] path-abempty [ "?" query ]

>              coap-wss-URI =

>                "coap+wss:" "//" host [ ":" port ] path-abempty [ "?" query ]

>            The port component is OPTIONAL; the default for "coap+ws" is port 80,

>            while the default for "coap+wss" is port 443.

>            Fragment identifiers are not part of the request URI and thus MUST

>            NOT be transmitted in a WebSocket handshake or in the URI options of

>            a CoAP request.

> (They can't be in a CoAP request; not sure what the MUST NOT means.

> But again, this also applies to the TCP/TLS case.)

This is duplicated from https://tools.ietf.org/html/draft-savolainen-core-coap-websockets-07#section-3.

Any comments from the original authors on their intent?

>         6.2.1.  Decomposing and Composing URIs

>            o  A Uri-Host Option MUST only be included in a request when the

>               <host> component does not equal the uri-host component in the Host

>               header field in the WebSocket handshake.

> Wrong use of MUST.  (MUST it be included or is this a MUST NOT if equal?)

>            o  A Uri-Port Option MUST only be included in a request if |port|

>               does not equal the port component in the Host header field in the

>               WebSocket handshake.

> Ditto.

>            The steps to construct a URI from a request's options are changed

>            accordingly.

>         7.  Security Considerations

>            The security considerations of [RFC7252] apply.

> We SHOULD NOT be using RFC 2119 language in the security

> considerations.  If there are mandates, they SHOULD be in the sections

> defining the protocol.  Possible security considerations arising from

> those mandates then are discussed here.

<snip>

>           The TLS usage guidance in [RFC7925] SHOULD be followed.

> There are several MUSTs in that document.  Do we want to turn them

> into SHOULDs?  No. ->

>    The TLS usage guidance in [RFC7925] applies.

Added to https://github.com/core-wg/coap-tcp-tls/issues/11

I’m adding a Securing CoAP section like RFC7252. We’re reviewing the outline in the

“small group” before bringing the pull request to the WG.

>         8.1.  Signaling Codes

>            Each entry in the sub-registry must include the Signaling Code in the

>            range 7.01-7.31, its name, and a reference to its documentation.

> Is 7.00 reserved?

Good catch. https://github.com/core-wg/coap-tcp-tls/issues/90

>         8.2.  CoAP Signaling Option Numbers Registry

>            IANA is requested to create a sub-registry for signaling options

>            similar to the CoAP Option Numbers Registry (Section 12.2 of

>            [RFC7252]), with the single change that a fourth column is added to

>            the sub-registry that is one of the codes in the Signaling Codes

>            subregistry (Section 8.1).

> s/one/one or more/

Added to https://github.com/core-wg/coap-tcp-tls/issues/76

>         8.5.  URI Scheme Registration

> This section needs to get symmetric between the four URI schemes defined.

>            IANA is requested to add these new URI schemes to the registry

>            established with [RFC7595].

> We need to fill in the template.  See above comment.

Added to https://github.com/core-wg/coap-tcp-tls/issues/78

>         8.5.1.  coap+ws

>            URI scheme syntax.

>              Defined in Section N of [RFCthis]

> s/N/6.2/

https://github.com/core-wg/coap-tcp-tls/issues/91

>            URI scheme semantics.

>               The "coap+ws" URI scheme provides a way to identify resources that

>               are potentially accessible over the Constrained Application

>               Protocol (CoAP) using the WebSocket protocol.

> s/are potentially accessible/are intended to be accessible/

Added to https://github.com/core-wg/coap-tcp-tls/issues/78 - with a note

that similar language exists for coap+wss.

>            Security Considerations.

>               See Section N of [RFCthis]

> s/N/7/

https://github.com/core-wg/coap-tcp-tls/issues/91

>         8.5.2.  coap+wss

>            URI scheme syntax.

>               Defined in Section N of [RFCthis]

> s/N/6.2/

https://github.com/core-wg/coap-tcp-tls/issues/91

>            URI scheme semantics.

>               The "coap+ws" URI scheme provides a way to identify resources that

>               are potentially accessible over the Constrained Application

>               Protocol (CoAP) using the WebSocket protocol secured with

>               Transport Layer Security (TLS).

> s/coap+ws/coaps+ws/

See bikeshed comment above.

>            Security Considerations.

>               See Section N of [RFCthis]

> s/N/7/

https://github.com/core-wg/coap-tcp-tls/issues/91

>         Appendix A.  Updates to RFC7641 Observing Resources in the Constrained

>                      Application Protocol (CoAP)

> This needs to be referenced from the main body in some form.

Added to https://github.com/core-wg/coap-tcp-tls/issues/83

>         Appendix B.  Negotiating Protocol Versions

>            In contrast to the message layer for UDP and DTLS, the CoAP over TCP

>            message format does not include a version number.  If version

>            negotiation needs to be addressed in the future, then Capability and

>            Settings have been specifically designed to enable such a potential

>            feature.

> s/Capability and Settings/Capabilities and Settings Messages (CSM)/

Added to https://github.com/core-wg/coap-tcp-tls/issues/89