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

From: Brian Raymor <[email-masked]>
Date: Wed, 2 Nov 2016 00:20:04 +0000

See the related issue - https://github.com/core-wg/coap-tcp-tls/issues/70

I plan on removing this section which was more in the spirit of an example in Hannes’s earlier draft.

From: weigengyu [mailto:[email-masked]]
Sent: Friday, October 28, 2016 1:35 AM
To: Jaime Jiménez <[email-masked]>; [email-masked]
Cc: Klaus Hartke <[email-masked]>; [email-masked]; Hannes Tschofenig <[email-masked]>
Subject: Re: [core] 🔔 WGLC on draft-ietf-core-coap-tcp-tls

Hi，

There is one question.

In this draft, it includes “ 2.2. UDP-to-TCP gateways”
This seems to imply that CoAP runs over UDP, then goes through a gateway of “UDP-to-TCP”, and CoAP runs over TCP.
By CoAP request/response semantics,  if a CoAP request goes through the gateway of “UDP-to-TCP”,
the CoAP response will go through  the gateway of “TCP-to-UDP”.
With the gateway of “TCP-to-UDP” CoAP can work at least.

Where is the place of the specitications of “TCP-to-UDP gateway” ?

Regards,

Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications

From: Jaime Jiménez<mailto:[email-masked]>
Sent: Tuesday, October 18, 2016 5:22 PM
To: mailto:[email-masked]
Cc: Klaus Hartke<mailto:[email-masked]> ; [email-masked]<mailto:[email-masked]> ; Hannes Tschofenig<mailto:[email-masked]>
Subject: [core] 🔔 WGLC on draft-ietf-core-coap-tcp-tls

Dear CoRE WG,

The core-coap-tcp-tls draft has gotten to a state that the authors feel is in good shape for WGLC.
We would like to ask the group to start checking this last version and the issues on the Github repository.

https://tools.ietf.org/html/draft-ietf-core-coap-tcp-tls-05

There is at the moment one open issue left in the tracker ( https://github.com/core-wg/coap-tcp-tls/issues/31  ) which is mostly editorial. The issues raised during last IETF - about Observe over reliable transports -  have been closed and new text has been added to the appendix: https://github.com/core-wg/coap-tcp-tls/issues/5

Best Regards,
- - Jaime Jiménez

________________________________
_______________________________________________
core mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/core

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 8 Nov 2016 09:42:49 +0100

So far, we have had one comment on the incompleteness of the TCP/UDP proxy example (Brian intends to remove this text) and a good discussion on how the objective of MTI (and “default-enabled”) security can be achieved (which hasn’t quite completed yet, I think).

What we don’t have is in-depth reviews.  The chairs believe we need at least a few of those before we (Jaime, that is) can declare this draft passed WGLC.

So please do keep those reviews coming.

We really want to use the f2f time we have a week from now to resolve any outstanding issues, so please make sure we have had a chance to digest your review before that meeting.

Grüße, Carsten

PS.: Yes, I’m in for one of those reviews, too.  Sorry for not delivering in time.

> On 18 Oct 2016, at 11:22, Jaime Jiménez <[email-masked]> wrote:
> 
> Dear CoRE WG,
>

---

From: Christian Groves <[email-masked]>
Date: Wed, 9 Nov 2016 06:41:05 +1100

Hello all,

Here are my WGLC comments.

General - It's not clear "how" mandatory the use of the CSM is. Clause 
2.3 on TCP/TLS indicates that the CSM message must be sent at the start 
of the connection. Clause 3.1 on Websockets makes no mention of CSM 
messages. Clause 4.3 indicates that the CSM MUST be sent at the start of 
the connection also and makes no distinction between TCP/TLS and 
Websockets. Clause 2.3 also indicates that the connection must be 
aborted if the CSM is missing or invalid as the first message on the 
connection. Given the discussion about address changes does more 
information need to be provided what start of connection means?

Cl.3 para 1: "The WebSocket connection can be used for any number of 
requests." There's no such comment for TCP/TLS. Is there something 
behind this that this needs to be stated for WebSocket or not TCP/TLS?

Cl.4.2: Should we say here (or in 8.2) that the allocation of option 
numbers follows the conventions of 5.4.6/[RFC7252]?

Cl.4.3: "Both capability and settings options are cumulative. ... An 
option that is sent might override a previous value for the same 
option.  The option defines how to handle this case if needed." The 
options in 4.3.1, 4.3.2 and 4.3.3 don't say if this is possible.

Cl.4.3.1: "(Section 5.10 of [RFC7252]." Missing closing ")".

Cl.4.3.1: For TLS and Websocket I take the comments to mean that the 
Server-Name setting option shouldn't be used, or?

Cl.4.5: "A release message will normally be replied to by the peer by 
closing the TCP/TLS connection." Could "TCP/TLS" be replaced with 
"transport" in order to make the text more generic?

Cl.4.5: Bad-Server-Name - can this be used even in response to 
Server-Name-Option not provided by a CSM?

Cl.4.5/4.6: "; the details are in the options" AND "...can indicate one 
or more..." does this mean that at least one option MUST be included?

Cl.4.5/4.6: The text mentions a "diagnostic payload", is some standard 
envisaged for this or is it implementation dependent?

Cl.6.2: This indicates ABNF is used for the definitions. However clause 
6.1.1 and 6.1.2 make no mention of the ABNF syntax or reference to 
RFC3986. The descriptions of the definitions of the URI schemes in 6.2, 
6.1.1 and 6.1.2 should be harmonised.

Cl.8.2: "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)." The table 2 below isn't correct as it 
includes names not the signal codes from Table 1

Cl. 8.2: The text of 12.2/RFC7252 indicates a number of criteria that 
must be included for registration. The options in the tcp draft don't 
address all the points. Some criteria aren't relevant but if 12.2 is 
referenced then they need to be discussed.

Cl.8.2: I wonder if the first column in Table 3 should be "Applies to"? 
It seems more natural to look up the Signal Code to find the option, 
instead of the options which could have the same number.

Cl.8.5: I think it would be easier for IANA if the coaps+tcp and 
coap+tcp URI schemes were described like the websockets ones in 8.5.1 
and 8.5.2.

Cl.8.5: The section references both [RFC7595] and [RFC4395]. RFC7595 
obsoletes RFC4395.

Appendix B: This could be deleted. Its covers much of the same text as 
bullet 2 / clause 2.4. Or at least the they could be merged into one.

Appendix C: Depending on the outcome of the earlier general comment, a 
CSM message may need to be added between step 2 and 3.

Regards, Christian

On 8/11/2016 7:42 PM, Carsten Bormann wrote:
> [email-masked]

---

From: Brian Raymor <[email-masked]>
Date: Mon, 14 Nov 2016 11:35:09 +0000

Hi Christian-

I appreciate the close reading and the thoughtful feedback.

Feel free to directly open future issues in https://github.com/core-wg/coap-tcp-tls/issues.

Responses inline. I'd request the authors to also review and respond.

> information need to be provided what start of connection means?

The WebSockets cases need to be updated. 
https://github.com/core-wg/coap-tcp-tls/issues/73

> behind this that this needs to be stated for WebSocket or not TCP/TLS?

There is:

https://tools.ietf.org/html/draft-ietf-core-coap-tcp-tls-05#section-2.5

    A CoAP client can send multiple requests without waiting for a response
    and the CoAP server can return responses in any order.

That said, I don't feel strongly about retaining the WebSocket language.

> numbers follows the conventions of 5.4.6/[RFC7252]?

To clarify, do you mean this specific convention:

    https://tools.ietf.org/html/rfc7252#section-5.4.6

   An Option is identified by an option number, which also provides some
   additional semantics information, e.g., odd numbers indicate a
   critical option, while even numbers indicate an elective option.

> options in 4.3.1, 4.3.2 and 4.3.3 don't say if this is possible.

Since the signaling section originated in:

   https://tools.ietf.org/html/draft-bormann-core-coap-sig-02

Carsten - can you clarify your original intentions in this case?

> Cl.4.3.1: "(Section 5.10 of [RFC7252]." Missing closing ")".

This is already addressed in my ongoing WGLC editorial pull request:
   https://github.com/core-wg/coap-tcp-tls/pull/67/commits/7a1d8c3a84b5ff05f846d2618f5bf3b5a5dd76e3

> Server-Name setting option shouldn't be used, or?

Based on the related issue - https://trac.ietf.org/trac/core/ticket/391, my perception was that this feature was
intended for CoAP over TCP.

I did update the use of "initial value":

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

   For Websockets, the initial value for the Server-Name Option is given
   by the HTTP Host header field.

 to "base value":
  https://github.com/core-wg/coap-tcp-tls/pull/67/commits/6ea12a700afe8ed8d909691af4fc456ebefb618e

As noted in https://tools.ietf.org/html/draft-ietf-core-coap-tcp-tls-05#section-4.3:

   Base values are listed below for CSM Options.  These are the values
   for the Capability and Setting before any Capability and Settings
   messages send a modified value.

But I'd also note that https://tools.ietf.org/html/draft-ietf-core-coap-tcp-tls-05#section-7.1 is somewhat
ambiguous about "cannot be used ..."

   o  SNI vs. Server-Name: Any security negotiated in the TLS handshake
      is for the SNI name exchanged in the TLS handshake and checked
      against the certificate provided by the server.  The Server-Name
      Option cannot be used to extend these security properties to the
      additional server name.

Carsten - can you clarify your intentions in this case?

> "transport" in order to make the text more generic?

It would be even simpler to change to "closing the connection"?

> Server-Name-Option not provided by a CSM?

To clarify, you're asking whether the base value for Server-Name can result
in Bad-Server-Name being returned?

> or more..." does this mean that at least one option MUST be included?

No - "can" does not indicate a requirement.

I would propose to delete "the details are in the options" and change:

  Release/Abort messages can indicate one or more reasons using elective options.

to:

  Release/Abort messages MAY indicate one or more reasons using elective options.

> envisaged for this or is it implementation dependent?

This is implementation dependent, although it might be helpful to adapt or 
reference - https://tools.ietf.org/html/rfc7252#section-5.5.2

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

> 6.1.1 and 6.1.2 should be harmonised.

This could be more consistent. Currently, coap+tcp and coaps+tcp rely on
references to coap and coaps in RFC7252:

    The semantics defined in [RFC7252], Section 6.1, apply to this URI
   scheme, with the following changes

and require that the reader is also familiar with https://tools.ietf.org/html/rfc7252#section-6

   The syntax of the "coap" and "coaps" URI schemes is specified in this
   section in Augmented Backus-Naur Form (ABNF) [RFC5234].  The
   definitions of "host", "port", "path-abempty", "query", "segment",
   "IP-literal", "IPv4address", and "reg-name" are adopted from
   [RFC3986].

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

> includes names not the signal codes from Table 1

Nice catch. Looks like "name" was originally used instead of the "code"
perhaps for easier comprehension. 

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

> referenced then they need to be discussed.

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

> instead of the options which could have the same number.

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

> coap+tcp URI schemes were described like the websockets ones in 8.5.1 

Yes - this is another case with a heavy dependency on RFC7252.

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

> Cl.8.5: The section references both [RFC7595] and [RFC4395]. RFC7595 

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

> bullet 2 / clause 2.4. Or at least the they could be merged into one.

See the discussion in https://github.com/core-wg/coap-tcp-tls/issues/20

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 15 Nov 2016 00:56:35 +0900

Below is my (somewhat belated) review of draft-ietf-core-coap-tcp-tls-05.

Everything that is indented by 8 or more spaces is original text, everything that is not indented is comment, and there is a little text that is indented by 3 spaces that is either proposed new text or foreign text.  I hope this survives the E-Mail somewhat.  In case it doesn’t, I have also put the file up at:

https://svn.tools.ietf.org/svn/wg/core/draft-ietf-core-coap-tcp-tls-05-cabo.txt

Grüße, 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.

           [...]
           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.

        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.

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

        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/

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

        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.

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

            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.

        3.  CoAP over WebSockets

           [...]

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

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

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

        4.  Signaling

           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

           [...]

s/initial/base/???

           [...]

        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

        Bormann, et al.          Expires April 14, 2017                [Page 17]
        
        Internet-Draft   TCP/TLS/WebSockets Transports for CoAP     October 2016

           this option being indicated with a certain minimum value will enjoy
           limited interoperability.

(above 1152?)

        6.  CoAP URIs

           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.

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

        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.

           TLS version 1.2 or higher is mandatory-to-implement and MUST be
           enabled by default.  An endpoint MAY immediately abort a CoAP over
           TLS connection that does not meet this requirement (see Section 4.6)
           and SHOULD include a diagnostic payload.

           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.

           [...]

        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?

        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/

        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.

        8.5.1.  coap+ws

           [...]

           URI scheme syntax.
              Defined in Section N of [RFCthis]

s/N/6.2/

           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/

           [...]

           Security Considerations.
              See Section N of [RFCthis]

s/N/7/

        8.5.2.  coap+wss

           [...]

           URI scheme syntax.
              Defined in Section N of [RFCthis]
s/N/6.2/

           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/

           [...]

           Security Considerations.
              See Section N of [RFCthis]

s/N/7/

        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.

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

---

From: Göran Selander <[email-masked]>
Date: Tue, 15 Nov 2016 08:37:30 +0000

On 2016-11-08 09:42, "core on behalf of Carsten Bormann"
<[email-masked] on behalf of [email-masked]> wrote:

>So far, we have had one comment on the incompleteness of the TCP/UDP
>proxy example (Brian intends to remove this text) and a good discussion
>on how the objective of MTI (and “default-enabled”) security can be
>achieved (which hasn’t quite completed yet, I think).

I condensed some of the comments in the recent mail discussion in the
re-opened issue:
https://github.com/core-wg/coap-tcp-tls/issues/11

I hope I captured those statements accurately, please check the mail
threads for the complete conversation.

Göran

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 15 Nov 2016 17:55:22 +0900

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

Thank you for the summary.

Brian: Do you want the submitters of the other reviews to turn these into github issues or do you plan to do that?

Grüße, Carsten

---

From: Brian Raymor <[email-masked]>
Date: Tue, 15 Nov 2016 09:41:41 +0000

> Brian: Do you want the submitters of the other reviews to turn these into github issues or do you plan to do that?

I'm already opening issues for reviews on the mailing list to ensure that we're tracking the conversation and resolution. For example, see my response to Christian.

For minor editorial issues, I'll simply use direct pull requests. The WG is also always welcome to open issues directly - https://github.com/core-wg/coap-tcp-tls/issues - I recommend one topic per issue.

---

From: Göran Selander <[email-masked]>
Date: Wed, 16 Nov 2016 08:05:41 +0000

>Thank you for the summary.

Since the issue wasn’t closed in the WG meeting, here are two more points
I think wasn’t highlighted:

1. This is not a battle between transport vs. application layer security.
The are other layers and security protocols as well. And we need this
flexibility because different security protocols have different
properties, meeting other requirements.

2. This is not about discouraging the implementation of TLS, but allowing
applications that has other security mechanisms available to implement and
use something else. This can e.g. be formulated as "TLS is mandatory to
implement unless . . .”

Göran