Skip to main content

CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets
draft-ietf-core-coap-tcp-tls-11

Revision differences

Document history

Date Rev. By Action
2018-02-08
11 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2018-01-29
11 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2018-01-25
11 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2018-01-03
11 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2018-01-02
11 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2018-01-02
11 (System) IANA Action state changed to In Progress from Waiting on Authors
2017-12-22
11 (System) IANA Action state changed to Waiting on Authors
2017-12-18
11 (System) RFC Editor state changed to EDIT
2017-12-18
11 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2017-12-18
11 (System) Announcement was received by RFC Editor
2017-12-18
11 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2017-12-18
11 Amy Vezza IESG has approved the document
2017-12-18
11 Amy Vezza Closed "Approve" ballot
2017-12-18
11 Amy Vezza IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2017-12-18
11 Alexey Melnikov Ballot approval text was generated
2017-12-18
11 Alexey Melnikov Ballot writeup was changed
2017-12-18
11 Carsten Bormann New version available: draft-ietf-core-coap-tcp-tls-11.txt
2017-12-18
11 (System) New version approved
2017-12-18
11 (System)
Request for posting confirmation emailed to previous authors: core-chairs@ietf.org, Simon Lemay , Carsten Bormann , Bill Silverajan , Hannes Tschofenig , Klaus Hartke , …
Request for posting confirmation emailed to previous authors: core-chairs@ietf.org, Simon Lemay , Carsten Bormann , Bill Silverajan , Hannes Tschofenig , Klaus Hartke , Brian Raymor
2017-12-18
11 Carsten Bormann Uploaded new revision
2017-12-18
10 Mirja Kühlewind [Ballot comment]
Thanks for addressing my discuss with the next upcoming version -11. Happy Holidays!
2017-12-18
10 Mirja Kühlewind [Ballot Position Update] Position for Mirja Kühlewind has been changed to No Objection from Discuss
2017-10-30
10 Carsten Bormann New version available: draft-ietf-core-coap-tcp-tls-10.txt
2017-10-30
10 (System) New version approved
2017-10-30
10 (System)
Request for posting confirmation emailed to previous authors: core-chairs@ietf.org, Simon Lemay , Carsten Bormann , Bill Silverajan , Hannes Tschofenig , Klaus Hartke , …
Request for posting confirmation emailed to previous authors: core-chairs@ietf.org, Simon Lemay , Carsten Bormann , Bill Silverajan , Hannes Tschofenig , Klaus Hartke , Brian Raymor
2017-10-30
10 Carsten Bormann Uploaded new revision
2017-08-31
09 Wesley Eddy Request for Telechat review by TSVART Completed: Almost Ready. Reviewer: Yoshifumi Nishida.
2017-06-09
09 Eric Rescorla [Ballot Position Update] Position for Eric Rescorla has been changed to No Objection from Discuss
2017-05-22
09 Adam Roach
[Ballot comment]
I have removed my DISCUSS, but want to be clear that I remain quite distressed about the design aspects of this document. I …
[Ballot comment]
I have removed my DISCUSS, but want to be clear that I remain quite distressed about the design aspects of this document. I have adjusted my comments below to trim them down to only those issues that remain in -09. Beyond the comments left over from -08, I am perplexed that no concrete mechanism for UDP/TCP failover is provided, nor is any discussion of the management aspects of configuring between them, nor is any discussion of which transport protocol(s) may be considered MTI.

I also wish to highlight the somewhat buried request from my original comments that I believe this document would be vastly improved by splitting it into one document that deals with TCP, and another that deals with WebSockets. They are intended for radically different environments, and a large majority of implementors will care about one but not the other. Combining into a single document just creates more work for them.

General — this is a very bespoke approach to what could have been mostly solved with a single four-byte “length” header; it is complicated on the wire, and in implementation; and the format variations among CoAP over UDP, TLS, and WebSockets are going to make gateways much harder to implement and less efficient (as they will necessarily have to disassemble messages and rebuild them to change between formats). The protocol itself mentions gateways in several places, but does not discuss how they are expected to map among the various flavors of CoAP defined in this document. Some of the changes seem unnecessary, but it could be that I’m missing the motivation for them. Ideally, the introduction would work harder at explaining why CoAP over these transports is as different from CoAP over UDP as it is, focusing in particular on why the complexity of having three syntactically incompatible headers is justified by the benefits provided by such variations.

Additionally, it’s not clear from the introduction what the motivation for using the mechanisms in this document is as compared to the techniques described in section 10 (and its subsections) of RFC 7252. With the exception of subscribing to resource state (which could be added), it seems that such an approach is significantly easier to implement and more clearly defined than what is in this document; and it appears to provide the combined benefits of all four transports discussed in this document. My concern here is that an explosion of transport options makes it less likely that a client and server can find two in common: the limit of the probability of two implementations having a transport in common as the number of transports approaches infinity is zero. Due to this likely decrease in interoperability, I’d expect to see some pretty powerful motivation in here for defining a third, fourth, fifth, and sixth way to carry CoAP when only TCP is available (I count RFC 7252 http and https as the first and second ways in this accounting).

Specific comments follow.

Section 3.3, paragraph 3 says that an initiator may send messages prior to receiving the remote side’s CSM, even though the message may be larger than would be allowed by that CSM.  What should the recipient of an oversized message do in this case? In fact, I don’t see in here what a recipient of a message larger than it allowed for in its CSM is supposed to do in response at *any* stage of the connection. Is it an error? If so, how do you indicate it? Or is the Max-Message-Size option just a suggestion for the other side? This definitely needs clarification. (Aside — it seems odd and somewhat backwards that TCP connections are provided an affordance for fine-grained control over message sizes, while UDP communications are not.)

Section 5 and its subsections define a new set of message types, presumably for use only on connection-oriented protocols, although this is only implied, and never stated. For example, some implementors may see CSM, Ping, and Pong as potentially useful in UDP; and, finding no prohibition in this document against using them, decide to give it a go. Is that intended? If not, I strongly suggest an explicit prohibition against using these in UDP contexts.

Section 5.3.2 says that implementations supporting block-wise transfers SHOULD indicate the Block-wise Transfer Option. I can't figure out why this is anything other than a "MUST". It seems odd that this document would define a way to communicate this, and then choose to leave the communicated options as “YES” and “YOUR GUESS IS AS GOOD AS MINE” rather than the simpler and more useful “YES” and “NO”.

I find the described operation of the Custody Option in the operation of Ping and Pong to be somewhat problematic: it allows the Pong sender to unilaterally decide to set the Custody Option, and consequently quarantine the Pong for an arbitrary amount of time while it processes other operations. This seems impossible to distinguish from a failure-due-to-timeout from the perspective of the Ping sender. Why not limit this behavior only to Ping messages that include the Custody Option?

I am similarly perplexed by the hard-coded “must do ALPN *unless* the designated port takes the magical value 5684” behavior. I don’t think I’ve ever seen a protocol that has such variation based on a hard-coded port number, and it seems unlikely to be deployed correctly (I’m imaging the frustration of: “I changed both the server and the client configuration from the default port of 5684 to 49152, and it just stopped working. Like, literally the *only* way it works is on port 5684. I've checked firewall settings everywhere and don't see any special handling for that port -- I just can't figure this out, and it's driving me crazy.”). Given the nearly universal availability of ALPN in pretty much all modern TLS libraries, it seems much cleaner to just require ALPN support and call it done. Or *don’t* require ALPN at all and call it done. But *changing* protocol behavior based on magic port numbers seems like it’s going to cause a lot of operational heartburn.

[I have removed my comments about section 8.1, as I believe EKR is managing the TLS-related issues for this document]

Although the document clearly expects the use of gateways and proxies between these connection-oriented usages of CoAP and UDP-based CoAP, Appendix A seems to omit discussion or consideration of how this gatewaying can be performed. The following list of problems is illustrative of this larger issue, but likely not exhaustive. (I'll note that all of these issues evaporate if you move to a simpler scheme that merely frames otherwise unmodified UDP CoAP messages)

Section A.1 does not indicate what gateways are supposed to do with out-of-order notifications. The TCP side requires these to be delivered in-order; so, do this mean that gateways observing a gap in sequence numbers need to quarantine the newly received message so that it can deliver the missing one first? Or does it deliver the newly-received message and then discard the “stale” one when it arrives? I don’t think that leaving this up to implementations is particularly advisable.

Section A.3 is a bit more worrisome. I understand the desired optimization here, but where you reduce traffic in one direction, you run the risk of exploding it in the other. For example, consider a coap+tcp client connecting to a gateway that communicates with a CoAP-over-UDP server. When that client wants to check the health of its observations, it can send a Ping and receive a Pong that confirms that they are all alive and well. In order to be able to send a Pong that *means* “all your observations are alive and well,” the gateway has to verify that all the observations are alive and well. A simple implementation of a gateway will likely check on each observed resource individually when it gets a Ping, and then send a Pong after it hears back about all of them. So, as a client, I can set up, let’s say, two dozen observations through this gateway. Then, with each Ping I send, the gateway sends two dozen checks towards the server. This kind of message amplification attack is an awesome way to DoS both the gateway and the server. I believe the document needs a treatment of how UDP/TCP gateways handle notification health checks, along with techniques for mitigating this specific attack.

Section A.4 talks about the rather different ways of dealing with unsubscribing from a resource. Presumably, gateways that get a reset to a notification are expected to synthesize a new GET to deregister on behalf of the client? Or is it okay if they just pass along the reset, and expect the server to know that it means the same thing as a deregistration? Without explicit guidance here, I expect server and gateway implementors to make different choices and end up with a lack of interop.

From i-d nits (this appears to be in reference to Figure 1):
** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72.
2017-05-22
09 Adam Roach [Ballot Position Update] Position for Adam Roach has been changed to No Objection from Discuss
2017-05-22
09 Ben Campbell
[Ballot comment]
Update2: I've cleared my DISCUSS position, since version 09 removed the use of the scheme to select the transport. I would have liked …
[Ballot comment]
Update2: I've cleared my DISCUSS position, since version 09 removed the use of the scheme to select the transport. I would have liked to see a bit more precision from Adam's suggested design in the section on transport selection, but I don't consider that discuss-worthy.

Update: I removed point 1 from my discuss. But I do still think it would be useful to add a paragraph about how COAP reliability features are only hop-by-hop.

Subtantive:

3.2: I agree with Adam that this length scheme seems very complex for the
return

3.3: Since the initiator can start sending messages before receiving a CSM
from the responder, how long should the initiator wait for a CSM before
bailing?

3.4: Can you offer any guidance about how often to send keep-alives? I note
that these keepalives are not necessarily bi-directional. Aren't there some
NAT/FW cases where bi-directional traffic is needed to keep bindings from
timing out?

This and other places explicitly mention that in-flight messages may be lost
when the transport is closed or reset. This creates uncertainty about whether
such messages have been processed or not. Is that really okay?

4: After the discussion resulting from Mark's Art-Art review, I expected to
see more emphasis about WebSocket being intended for browser-based clients.
There's a couple of in-passing mentions of browser-clients buried in the
text; I would have expected something more up front.

4.2: Is it really worth making the framing code behave differently for
WebSocket than for TCP?

5.3: Do I understand correctly that once an option is established, it cannot
be removed unless replaced? (Short of tearing down the connection and
starting over, anyway.)

7.2: The text mentions 443 as a default port, but really seems to make 5684
the default. If 443 is really a default, then this needs  discussion about
why and why it's okay to squat on HTTPS.

The text about whether ALPN is required is confusing. Why not just require
ALPN and move one, rather than special casing it by port choice? (There seems
to be some circular logic about requiring 5685 to support clients that don't
do ALPN, then saying clients MUST do ALPN unless they are using port 5685.)

7.3: I agree with Adam's DISCUSS comment. And even if people decide that the
well-known bit can be specified in CORE, I think it does future users of a
well-known URIs for ws a disservice to make them dig through this spec to
find the update to 6455.  It would be better to pull that into a separate
draft. That's also a material addition post IETF last call, so we should consider
repeating the LC.

10.2: Is the registration policy "analogous to" that of [RFC7252] S12.2, or
"identical to" it. If the answer is not "identical", then the policy
should be detailed here.

Editorial:

Figures 7 and 8: "Payload (if any)" - Can we assume that if one uses either
extended length format, one has a payload?

3.3: Is the guidance about what errors to return if you don't implement a
server any different here than for UDP?

4.3 and 4.4 seem to primarily repeat details that are the same for WS as for
TCP, even though the introduction to the WS part says that it won't do that
:-)

5.3: "One CSM MUST be sent by both endpoints...": s/both/each

7.6: The "updates" in this section are confusing. I understand this to mean
that the procedures for TCP and WS are identical to those for UDP except for
the mentioned steps. But the language of the form of "This step from
[RFC7252] is updated to:" makes it sound like this intends to actually change
the language in 7252 to this new language. If the latter, then that
effectively removes UDP support from 7252 as updated.

This could easily be fixed by changing that to something to the effect of
"When using TCP, this step changes to ..."

Appendix A: Why is this an appendix? Updates to a standards track RFC seem to
warrant a more prominent position in the draft.
2017-05-22
09 Ben Campbell [Ballot Position Update] Position for Ben Campbell has been changed to No Objection from Discuss
2017-05-22
09 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'No Response'
2017-05-18
09 Tero Kivinen Closed request for Last Call review by SECDIR with state 'No Response'
2017-05-16
09 (System) Sub state has been changed to AD Followup from Revised ID Needed
2017-05-16
09 (System) IANA Review state changed to Version Changed - Review Needed from IANA - Not OK
2017-05-16
09 Brian Raymor New version available: draft-ietf-core-coap-tcp-tls-09.txt
2017-05-16
09 (System) New version approved
2017-05-16
09 (System)
Request for posting confirmation emailed to previous authors: Klaus Hartke , Simon Lemay , Carsten Bormann , Hannes Tschofenig , Bill Silverajan , Brian Raymor …
Request for posting confirmation emailed to previous authors: Klaus Hartke , Simon Lemay , Carsten Bormann , Hannes Tschofenig , Bill Silverajan , Brian Raymor , core-chairs@ietf.org
2017-05-16
09 Brian Raymor Uploaded new revision
2017-05-11
08 Ben Campbell
[Ballot discuss]
1) [removed, please see update in comments]

2) It seems problematic to encode the transport choice in the URI scheme.
Section 7 says …
[Ballot discuss]
1) [removed, please see update in comments]

2) It seems problematic to encode the transport choice in the URI scheme.
Section 7 says "They are hosted
in distinct namespaces because each URI scheme implies a distinct origin
server." IIUC, this means any given resource can only be reached over a
specific transport. That seems to break the idea of cross-transport proxies
as discussed in section 7.

It also does not seem to fit with a primary motivation for this draft. That
is, one might want to use TCP because of local NAT/FW issues. But if there is
a resource with a "coap" scheme, I cannot switch to TCP when I'm behind a
problematic middlebox, and have an expectation of reaching the same resource.
2017-05-11
08 Ben Campbell
[Ballot comment]
Update: I removed point 1 from my discuss. But I do still think it would be useful to add a paragraph about how …
[Ballot comment]
Update: I removed point 1 from my discuss. But I do still think it would be useful to add a paragraph about how COAP reliability features are only hop-by-hop.

Subtantive:

3.2: I agree with Adam that this length scheme seems very complex for the
return

3.3: Since the initiator can start sending messages before receiving a CSM
from the responder, how long should the initiator wait for a CSM before
bailing?

3.4: Can you offer any guidance about how often to send keep-alives? I note
that these keepalives are not necessarily bi-directional. Aren't there some
NAT/FW cases where bi-directional traffic is needed to keep bindings from
timing out?

This and other places explicitly mention that in-flight messages may be lost
when the transport is closed or reset. This creates uncertainty about whether
such messages have been processed or not. Is that really okay?

4: After the discussion resulting from Mark's Art-Art review, I expected to
see more emphasis about WebSocket being intended for browser-based clients.
There's a couple of in-passing mentions of browser-clients buried in the
text; I would have expected something more up front.

4.2: Is it really worth making the framing code behave differently for
WebSocket than for TCP?

5.3: Do I understand correctly that once an option is established, it cannot
be removed unless replaced? (Short of tearing down the connection and
starting over, anyway.)

7.2: The text mentions 443 as a default port, but really seems to make 5684
the default. If 443 is really a default, then this needs  discussion about
why and why it's okay to squat on HTTPS.

The text about whether ALPN is required is confusing. Why not just require
ALPN and move one, rather than special casing it by port choice? (There seems
to be some circular logic about requiring 5685 to support clients that don't
do ALPN, then saying clients MUST do ALPN unless they are using port 5685.)

7.3: I agree with Adam's DISCUSS comment. And even if people decide that the
well-known bit can be specified in CORE, I think it does future users of a
well-known URIs for ws a disservice to make them dig through this spec to
find the update to 6455.  It would be better to pull that into a separate
draft. That's also a material addition post IETF last call, so we should consider
repeating the LC.

10.2: Is the registration policy "analogous to" that of [RFC7252] S12.2, or
"identical to" it. If the answer is not "identical", then the policy
should be detailed here.

Editorial:

Figures 7 and 8: "Payload (if any)" - Can we assume that if one uses either
extended length format, one has a payload?

3.3: Is the guidance about what errors to return if you don't implement a
server any different here than for UDP?

4.3 and 4.4 seem to primarily repeat details that are the same for WS as for
TCP, even though the introduction to the WS part says that it won't do that
:-)

5.3: "One CSM MUST be sent by both endpoints...": s/both/each

7.6: The "updates" in this section are confusing. I understand this to mean
that the procedures for TCP and WS are identical to those for UDP except for
the mentioned steps. But the language of the form of "This step from
[RFC7252] is updated to:" makes it sound like this intends to actually change
the language in 7252 to this new language. If the latter, then that
effectively removes UDP support from 7252 as updated.

This could easily be fixed by changing that to something to the effect of
"When using TCP, this step changes to ..."

Appendix A: Why is this an appendix? Updates to a standards track RFC seem to
warrant a more prominent position in the draft.
2017-05-11
08 Ben Campbell Ballot comment and discuss text updated for Ben Campbell
2017-05-11
08 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2017-05-11
08 Alexey Melnikov
[Ballot comment]
I strongly agree with Adam's point about default port for coaps+tcp URI scheme.

Also the following comments from IANA should be looked at: …
[Ballot comment]
I strongly agree with Adam's point about default port for coaps+tcp URI scheme.

Also the following comments from IANA should be looked at:

While we have an approval from the well-known URI expert, we're still waiting for a response from the expert for ALPN Protocol IDs. Also, Graham Klyne, who's traveling, sent the response below to our request for a URI scheme review. When we register this URI scheme, can/should we add the note Graham proposes to the registry, and call it an "IESG Note"?

thanks,

Amanda Baber
Lead IANA Services Specialist

==

I am concerned that these scheme registrations (with multiple schemes for the  same resource accessed using a different protocol) present an "antipattern" that  was controversial when a similar proposal was raised about 18 months ago; e.g. see this earlier comment from Roy Fielding:

https://mailarchive.ietf.org/arch/msg/uri-review/ZXTfNQ7PDxHBSccrqrrbGH5N-Ko ,
specifically this:


[[
A URI scheme should define what it names and how that naming maps to the URI syntax. There is nothing wrong with using separate schemes for different transports if those transports are essential parts of the name (e.g., if something named Fred at TCP:80 is different from something named Fred at UDP:89898).

[...]

In short, I think you need to better document what each URI scheme means from the perspective of a server and then what the client is expected to do with such a URI.
]]


I was hoping that the URI-review list would pick up on this and provide some
further discussion.

I've seen a couple of private messages that seem to express similar concerns.

In summary, I would have responded on the URI review list as an individual if I
had been in a position to do. But if this comes back to me as a registration
request that has passed WG last call, then I see no grounds for refusal, even
though I think the design is misguided (or at least not adequately explained in
the registration templates).

In this situation, I might feel inclined to request adding an "IESG Note" to the
registration along the following lines (if this is deemed acceptable for a
request that has passed an IETF last-call review):

[[
The CoAP protocol registers different URI schemes for accessing CoAP Resources via different protocol. This runs counter to the principle that a URI identifies a resource, and that multiple URIs for identifying the same resources should be avoided. URIs should be used to hide rather than expose the purely technical mechanisms used when accessing a resource.
]]
2017-05-11
08 Alexey Melnikov Ballot comment text updated for Alexey Melnikov
2017-05-11
08 Benoît Claise [Ballot comment]
Watching all discussions
2017-05-11
08 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2017-05-10
08 Suresh Krishnan [Ballot comment]
I share a lot of the concerns raised in the DISCUSSes and I look forward to their resolution.
2017-05-10
08 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2017-05-10
08 Adam Roach
[Ballot discuss]
ISSUE 1: WebSockets and .well-known

- Part of the document is outside the scope of the charter of the WG which requested its …
[Ballot discuss]
ISSUE 1: WebSockets and .well-known

- Part of the document is outside the scope of the charter of the WG which requested its publication

While I understand that this document requires a WebSockets mechanism for .well-known, and that such a mechanism doesn’t yet exist, it seems pretty far out of scope for the CORE working group to take on defining this itself (unless I missed something in its charter, which is entirely possible: it’s quite long). Specifically, I fear that this venue is unlikely to bring such a change to the attention of those people best positioned to comment on whether .well-known is appropriate for WebSockets.

Even if this is in scope for CORE, it really needs to be its own document. If some future document comes along at a later point and wants to make use of its own .well-known path with WebSockets, it would be really quite strange to require it to reference this document in describing .well-known for WS.

==================================================

ISSUE 2: Assignment of port 443 as default

- Widespread deployment would be damaging to the Internet or an enterprise network for reasons of congestion control, scalability, or the like.

I'd like to thank the authors for helping me to understand the intention with the use of port 443 more clearly. Based on their clarifications, I need to move my issue about assigning a default of port 443 to coaps+tcp from my Comment into the Discuss, as it does have implications for the Internet at large that will have long-term damaging effects.

The rationale being offered for the using the already-assigned port 443 as a default is that it tends to go through firewalls that other ports may not, and that doing so is fine because ALPN makes it possible. These arguments, if we accept them, are manifestly true for all future TLS-using protocols. Allowing CoAP to re-use an assigned port on this basis established precedent for pretty much all future protocols to do so, effectively moving the protocol demux point for future protocols from port numbers to ALPN IDs (all over port 443). It is hard to imagine an outcome *other* *than* firewall manufacturers starting to whitelist desired ALPN IDs, which effectively ossifies the available set of IDs to whatever is defined at that moment, destroying the future utility of the mechanism.

There are other issues having to do with software architecture, protocol demultiplexing in user space rather than kernel space, and operational considerations that come into play as well, but they don't technically fall under discuss criteria.
2017-05-10
08 Adam Roach
[Ballot comment]
General — this is a very bespoke approach to what could have been mostly solved with a single four-byte “length” header; it is …
[Ballot comment]
General — this is a very bespoke approach to what could have been mostly solved with a single four-byte “length” header; it is complicated on the wire, and in implementation; and the format variations among CoAP over UDP, coap+tls, and coap+ws are going to make gateways much harder to implement and less efficient (as they will necessarily have to disassemble messages and rebuild them to change between formats). The protocol itself mentions gateways in several places, but does not discuss how they are expected to map among the various flavors of CoAP defined in this document. Some of the changes seem unnecessary, but it could be that I’m missing the motivation for them. Ideally, the introduction would work harder at explaining why CoAP over these transports is as different from CoAP over UDP as it is, focusing in particular on why the complexity of having three syntactically incompatible headers is justified by the benefits provided by such variations.

Additionally, it’s not clear from the introduction what the motivation for using the mechanisms in this document is as compared to the techniques described in section 10 (and its subsections) of RFC 7252. With the exception of subscribing to resource state (which could be added), it seems that such an approach is significantly easier to implement and more clearly defined than what is in this document; and it appears to provide the combined benefits of all four transports discussed in this document. My concern here is that an explosion of transport options makes it less likely that a client and server can find two in common: the limit of the probability of two implementations having a transport in common as the number of transports approaches infinity is zero. Due to this likely decrease in interoperability, I’d expect to see some pretty powerful motivation in here for defining a third, fourth, fifth, and sixth way to carry CoAP when only TCP is available (I count RFC 7252 http and https as the first and second ways in this accounting).

I’m also a bit puzzled that CoAP already has an inherent mechanism for blocking messages off into chunks, which this document circumvents for TCP connections (by allowing Max-Message-Size to be increased), and then is forced to offer remedies for the resultant head-of-line blocking issues. If you didn’t introduce this feature, messages with a two-byte token add six bytes of overhead for every 1024 bytes of content — less than 0.6% size inflation. It seems like a lot of complicated machinery — which has a built-in foot-gun that you have to warn people about misusing — for a very tiny gain. I know it’s relatively late in the process, but if these trade-offs haven't had a lot of discussion yet, it’s probably worth at least giving them some additional thought.

I’ll note that the entire BERT mechanism seems to fall into the same trap of adding extra complexity for virtually nonexistent savings. CoAP headers are, by design, tiny. It seems like a serious over-optimization to try to eliminate them in this fashion. In particular, you’re making the actual implementation code larger to save a trivial number of bits on the wire; I was under the impression that many of the implementation environments CoAP is intended for had some serious on-chip restrictions that would point away from this kind of additional complexity.

Specific comments follow.

Section 3.3, paragraph 3 says that an initiator may send messages prior to receiving the remote side’s CSM, even though the message may be larger than would be allowed by that CSM.  What should the recipient of an oversized message do in this case? In fact, I don’t see in here what a recipient of a message larger than it allowed for in its CSM is supposed to do in response at *any* stage of the connection. Is it an error? If so, how do you indicate it? Or is the Max-Message-Size option just a suggestion for the other side? This definitely needs clarification. (Aside — it seems odd and somewhat backwards that TCP connections are provided an affordance for fine-grained control over message sizes, while UDP communications are not.)

Section 4.4 has a prohibition against using WebSockets keepalives in favor of using CoAP ping/pong. Section 3.4 has no similar prohibition against TCP keepalives, while the rationale would seem to be identical. Is this asymmetry intentional? (I’ll also note that the presence of keepalive mechanisms in both TCP and WebSockets would seem to make the addition of new CoAP primitives for the same purpose unnecessary, but I suspect this has already been debated).

Section 5 and its subsections define a new set of message types, presumably for use only on connection-oriented protocols, although this is only implied, and never stated. For example, some implementors may see CSM, Ping, and Pong as potentially useful in UDP; and, finding no prohibition in this document against using them, decide to give it a go. Is that intended? If not, I strongly suggest an explicit prohibition against using these in UDP contexts.

Section 5.3.2 says that implementations supporting block-wise transfers SHOULD indicate the Block-wise Transfer Option. I can't figure out why this is anything other than a "MUST". It seems odd that this document would define a way to communicate this, and then choose to leave the communicated options as “YES” and “YOUR GUESS IS AS GOOD AS MINE” rather than the simpler and more useful “YES” and “NO”.

I find the described operation of the Custody Option in the operation of Ping and Pong to be somewhat problematic: it allows the Pong sender to unilaterally decide to set the Custody Option, and consequently quarantine the Pong for an arbitrary amount of time while it processes other operations. This seems impossible to distinguish from a failure-due-to-timeout from the perspective of the Ping sender. Why not limit this behavior only to Ping messages that include the Custody Option?

[Moved from Comment to Discuss: I find the unmotivated definition of the default port for “coaps+tcp” to 443 — a port that is already assigned to https — to be surprising, to put it mildly. This definitely needs motivating text, and I suspect it's actually wrong.]

I am similarly perplexed by the hard-coded “must do ALPN *unless* the designated port takes the magical value 5684” behavior. I don’t think I’ve ever seen a protocol that has such variation based on a hard-coded port number, and it seems unlikely to be deployed correctly (I’m imaging the frustration of: “I changed both the server and the client configuration from the default port of 5684 to 49152, and it just stopped working. Like, literally the *only* way it works is on port 5684. I've checked firewall settings everywhere and don't see any special handling for that port -- I just can't figure this out, and it's driving me crazy.”). Given the nearly universal availability of ALPN in pretty much all modern TLS libraries, it seems much cleaner to just require ALPN support and call it done. Or *don’t* require ALPN at all and call it done. But *changing* protocol behavior based on magic port numbers seems like it’s going to cause a lot of operational heartburn.

The final paragraph of section 8.1 is very confusing, making it somewhat unclear which of the three modes must be implemented on a CoAP client, and which must be implemented on a CoAP server. Read naïvely, this sounds like clients are required to do only one (but one of their choosing) of these three, while servers are required to also do only one (again, of their choosing). It seems that the chance of finding devices that could interoperate under such circumstances is going to be relatively low: to work together, you would have to find a client and a server that happened to make the same implementation choice among these three. What I’m used to in these kinds of cases is: (a) server must implement all, client can choose to implement only one (or more), (b) client must implement all, server can choose to implement only one (or more), or (c) client and server must implement a specifically named lowest-common denominator, and can negotiate up from there. Pretty much anything else (aside from strange “everyone must implement two of three” schemes) will end up with interop issues.

Although the document clearly expects the use of gateways and proxies between these connection-oriented usages of CoAP and UDP-based CoAP, Appendix A seems to omit discussion or consideration of how this gatewaying can be performed. The following list of problems is illustrative of this larger issue, but likely not exhaustive. (I'll note that all of these issues evaporate if you move to a simpler scheme that merely frames otherwise unmodified UDP CoAP messages)

Section A.1 does not indicate what gateways are supposed to do with out-of-order notifications. The TCP side requires these to be delivered in-order; so, do this mean that gateways observing a gap in sequence numbers need to quarantine the newly received message so that it can deliver the missing one first? Or does it deliver the newly-received message and then discard the “stale” one when it arrives? I don’t think that leaving this up to implementations is particularly advisable.

Section A.3 is a bit more worrisome. I understand the desired optimization here, but where you reduce traffic in one direction, you run the risk of exploding it in the other. For example, consider a coap+tcp client connecting to a gateway that communicates with a CoAP-over-UDP server. When that client wants to check the health of its observations, it can send a Ping and receive a Pong that confirms that they are all alive and well. In order to be able to send a Pong that *means* “all your observations are alive and well,” the gateway has to verify that all the observations are alive and well. A simple implementation of a gateway will likely check on each observed resource individually when it gets a Ping, and then send a Pong after it hears back about all of them. So, as a client, I can set up, let’s say, two dozen observations through this gateway. Then, with each Ping I send, the gateway sends two dozen checks towards the server. This kind of message amplification attack is an awesome way to DoS both the gateway and the server. I believe the document needs a treatment of how UDP/TCP gateways handle notification health checks, along with techniques for mitigating this specific attack.

Section A.4 talks about the rather different ways of dealing with unsubscribing from a resource. Presumably, gateways that get a reset to a notification are expected to synthesize a new GET to deregister on behalf of the client? Or is it okay if they just pass along the reset, and expect the server to know that it means the same thing as a deregistration? Without explicit guidance here, I expect server and gateway implementors to make different choices and end up with a lack of interop.

From i-d nits (this appears to be in reference to Figure 1):
** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72.
2017-05-10
08 Adam Roach Ballot comment and discuss text updated for Adam Roach
2017-05-10
08 Alissa Cooper [Ballot comment]
Agree with the concerns raised in the DISCUSSes, looking forward to their resolution.
2017-05-10
08 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2017-05-10
08 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2017-05-10
08 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2017-05-10
08 Warren Kumari [Ballot comment]
I have many of the same concerns as others, but see not need to hold a DISCUSS myself.
2017-05-10
08 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2017-05-10
08 Alia Atlas [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas
2017-05-10
08 Mirja Kühlewind
[Ballot discuss]
1) My general concern is that, while I don't necessarily want to block the proposed format, I would like to understand further before …
[Ballot discuss]
1) My general concern is that, while I don't necessarily want to block the proposed format, I would like to understand further before publication why this approach was chosen. Similar to Ben's discuss, I don't understand why the format was chosen so differently. You could just use the format (plus a new length option) as defined for UPD and just never have any retransmission or reordering but be more flexible on the lower layer transport to use. However, if you actually prefer a new format (to save space), than that sounds like a new version for me, while the draft says:
"CoAP is defined in [RFC7252] with a version number of 1.  At this time, there is no known reason to support version numbers different from 1."
However, in this case it could even have made sense to define a new format/version that could be used for both underlying protocols and either have a length option or a message type and IP option.
Further I also don't understand why on the other hand the TCP COAP framing is re-used for websockets because websockets already provides message framing and a length field.

Also inline with Ben's discuss, the use of the Block option for CAOP/TCP is not very clear to me. The draft says:
"a UDP-to-TCP gateway may simply not have the context to convert a
      message with a Block Option into the equivalent exchange without
      any use of a Block Option (it would need to convert the entire
      blockwise exchange from start to end into a single exchange)"
However, given that the COAP/TCP and COAP/UDP format are so different, it's anyway a more complex conversion than just sticking another transport underneath. The argument for HOL blocking due to e.g. upgrades is also not clear to me because you should probably better just use a different TCP connection for that as it really seems to be a different use case.

For me this draft looks like you are defining basically a new protocol version and not just COAP over TCP.

Again, I don't necessarily want to block this but I would like to understand why the proposed approach was chosen.

2) Comments from the tsv-art review needs to be addressed as well (Thanks to Yoshi Nishida for the review!). Here is the review text for your connivence:

"Summary: This document is well-written. It is almost ready to be published
as a PS draft once the following points are addressed.

1: It is not clear how the protocol reacts the errors from transport layers
(e.g. connection failure).
  The protocol will just inform apps of the events and the app will decide
what to do or the protocol itself will do something?

2: There will be situations where the app layer is freezing while the
transport layer is still working. Since transport layers cannot detect this
type of failures, there should be some mechanisms for it somewhere in the
protocol or in the app layer.  The doc needs to address this point. For
example, what will happen when a PONG message is not returned for a certain
amount of time?

3: Since this draft defines new SZX value, I think the doc needs to update
RFC7959. This point should be clarified more in the doc.“

3) And inline with Yoshi's comment, I don't think this part in section 3.3 is well specified; especially I don't understand how these two thing fit together:
"To avoid unnecessary latency, a Connection Initiator MAY send
  additional messages without waiting to receive the Connection
  Acceptor's CSM; ..."
and
  "Endpoints MUST treat a missing or invalid CSM as a connection error
  and abort the connection (see Section 5.6)."
Also how long should I wait until I abort the connection?
2017-05-10
08 Mirja Kühlewind [Ballot Position Update] New position, Discuss, has been recorded for Mirja Kühlewind
2017-05-09
08 Amanda Baber IANA Review state changed to IANA - Not OK from Version Changed - Review Needed
2017-05-09
08 Ben Campbell
[Ballot discuss]
1) This draft removes the reliability and ordering features COAP when used
over reliable transports, under the assumption that the transport will
provide. …
[Ballot discuss]
1) This draft removes the reliability and ordering features COAP when used
over reliable transports, under the assumption that the transport will
provide. But the draft also includes the assumption that COAP proxies exist.
This has the potential for creating a problem, since the transport can only
provide guaranty reliable delivery and ordering to the next hop. Once you
have a proxy in play, you loose that guaranty end to end.

This is further complicated because this draft contemplates cross-transport
proxies, where one side may be over WebSocket (and I assume might be over
TCP) and the other side over UDP. If the client sends via TCP but a proxy
changes it to UDP, the client has no way to specify the reliability
properties to be used on the UDP connection. If one imagines a client that uses
UDP to a forward proxy, which speaks TCP to a reverse-proxy, which then
switches back to UDP, any reliability properties specified by the client will get
lost.

Also, a proxy can potentially reorder messages, even if it uses TCP on both
sides. If one leaves ordering to the transport, then one needs to add rules
about proxies maintaining that order.

2) It seems problematic to encode the transport choice in the URI scheme.
Section 7 says "They are hosted
in distinct namespaces because each URI scheme implies a distinct origin
server." IIUC, this means any given resource can only be reached over a
specific transport. That seems to break the idea of cross-transport proxies
as discussed in section 7.

It also does not seem to fit with a primary motivation for this draft. That
is, one might want to use TCP because of local NAT/FW issues. But if there is
a resource with a "coap" scheme, I cannot switch to TCP when I'm behind a
problematic middlebox, and have an expectation of reaching the same resource.
2017-05-09
08 Ben Campbell Ballot discuss text updated for Ben Campbell
2017-05-09
08 Ben Campbell
[Ballot discuss]
1) This draft removes the reliability and ordering features COAP when used
over reliable transports, under the assumption that the transport will
provide. …
[Ballot discuss]
1) This draft removes the reliability and ordering features COAP when used
over reliable transports, under the assumption that the transport will
provide. But the draft also includes the assumption that COAP proxies exist.
This has the potential for creating a problem, since the transport can only
provide guaranty reliable delivery and ordering to the next hop. Once you
have a proxy in play, you loose that guaranty end to end.

This is further complicated because this draft contemplates cross-transport
proxies, where one side may be over WebSocket (and I assume might be over
TCP) and the other side over UDP. If the client sends via TCP but a proxy
changes it to UDP, the client has no way to specify the reliability
properties to be used on the UDP connection. If one imagines a client that uses
UDP to a forward proxy, which speaks TCP to a reverse-proxy, which then
switches back to UDP, any reliability properties specified by the client will get
lost.

Also, a proxy can potentially reorder messages, even if it uses TCP on both
sides. If one leaves ordering to the transport, then one needs to add rules
about proxies maintaining that order.

2) It seems problematic to encode the transport choice in the URI scheme.
Since the draft specifies that each scheme. Section 7 says "They are hosted
in distinct namespaces because each URI scheme implies a distinct origin
server." IIUC, this means any given resource can only be reached over a
specific transport. That seems to break the idea of cross-transport proxies
as discussed in section 7.

It also does not seem to fit with a primary motivation for this draft. That
is, one might want to use TCP because of local NAT/FW issues. But if there is
a resource with a "coap" scheme, I cannot switch to TCP when I'm behind a
problematic middlebox, and have an expectation of reaching the same resource.
2017-05-09
08 Ben Campbell
[Ballot comment]
Subtantive:

3.2: I agree with Adam that this length scheme seems very complex for the
return

3.3: Since the initiator can start sending …
[Ballot comment]
Subtantive:

3.2: I agree with Adam that this length scheme seems very complex for the
return

3.3: Since the initiator can start sending messages before receiving a CSM
from the responder, how long should the initiator wait for a CSM before
bailing?

3.4: Can you offer any guidance about how often to send keep-alives? I note
that these keepalives are not necessarily bi-directional. Aren't there some
NAT/FW cases where bi-directional traffic is needed to keep bindings from
timing out?

This and other places explicitly mention that in-flight messages may be lost
when the transport is closed or reset. This creates uncertainty about whether
such messages have been processed or not. Is that really okay?

4: After the discussion resulting from Mark's Art-Art review, I expected to
see more emphasis about WebSocket being intended for browser-based clients.
There's a couple of in-passing mentions of browser-clients buried in the
text; I would have expected something more up front.

4.2: Is it really worth making the framing code behave differently for
WebSocket than for TCP?

5.3: Do I understand correctly that once an option is established, it cannot
be removed unless replaced? (Short of tearing down the connection and
starting over, anyway.)

7.2: The text mentions 443 as a default port, but really seems to make 5684
the default. If 443 is really a default, then this needs  discussion about
why and why it's okay to squat on HTTPS.

The text about whether ALPN is required is confusing. Why not just require
ALPN and move one, rather than special casing it by port choice? (There seems
to be some circular logic about requiring 5685 to support clients that don't
do ALPN, then saying clients MUST do ALPN unless they are using port 5685.)

7.3: I agree with Adam's DISCUSS comment. And even if people decide that the
well-known bit can be specified in CORE, I think it does future users of a
well-known URIs for ws a disservice to make them dig through this spec to
find the update to 6455.  It would be better to pull that into a separate
draft. That's also a material addition post IETF last call, so we should consider
repeating the LC.

10.2: Is the registration policy "analogous to" that of [RFC7252] S12.2, or
"identical to" it. If the answer is not "identical", then the policy
should be detailed here.

Editorial:

Figures 7 and 8: "Payload (if any)" - Can we assume that if one uses either
extended length format, one has a payload?

3.3: Is the guidance about what errors to return if you don't implement a
server any different here than for UDP?

4.3 and 4.4 seem to primarily repeat details that are the same for WS as for
TCP, even though the introduction to the WS part says that it won't do that
:-)

5.3: "One CSM MUST be sent by both endpoints...": s/both/each

7.6: The "updates" in this section are confusing. I understand this to mean
that the procedures for TCP and WS are identical to those for UDP except for
the mentioned steps. But the language of the form of "This step from
[RFC7252] is updated to:" makes it sound like this intends to actually change
the language in 7252 to this new language. If the latter, then that
effectively removes UDP support from 7252 as updated.

This could easily be fixed by changing that to something to the effect of
"When using TCP, this step changes to ..."

Appendix A: Why is this an appendix? Updates to a standards track RFC seem to
warrant a more prominent position in the draft.
2017-05-09
08 Ben Campbell [Ballot Position Update] New position, Discuss, has been recorded for Ben Campbell
2017-05-09
08 Terry Manderson [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson
2017-05-09
08 Kathleen Moriarty [Ballot comment]
I agree with EKR's technical comment that MTI cipher suites need to be defined.
2017-05-09
08 Kathleen Moriarty [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty
2017-05-09
08 Martin Stiemerling Request for Telechat review by TSVART is assigned to Yoshifumi Nishida
2017-05-09
08 Martin Stiemerling Request for Telechat review by TSVART is assigned to Yoshifumi Nishida
2017-05-08
08 Adam Roach
[Ballot discuss]
- Part of the document is outside the scope of the charter of the WG which requested its publication

While I understand that …
[Ballot discuss]
- Part of the document is outside the scope of the charter of the WG which requested its publication

While I understand that this document requires a WebSockets mechanism for .well-known, and that such a mechanism doesn’t yet exist, it seems pretty far out of scope for the CORE working group to take on defining this itself (unless I missed something in its charter, which is entirely possible: it’s quite long). Specifically, I fear that this venue is unlikely to bring such a change to the attention of those people best positioned to comment on whether .well-known is appropriate for WebSockets.

Even if this is in scope for CORE, it really needs to be its own document. If some future document comes along at a later point and wants to make use of its own .well-known path with WebSockets, it would be really quite strange to require it to reference this document in describing .well-known for WS.
2017-05-08
08 Adam Roach
[Ballot comment]
General — this is a very bespoke approach to what could have been mostly solved with a single four-byte “length” header; it is …
[Ballot comment]
General — this is a very bespoke approach to what could have been mostly solved with a single four-byte “length” header; it is complicated on the wire, and in implementation; and the format variations among CoAP over UDP, coap+tls, and coap+ws are going to make gateways much harder to implement and less efficient (as they will necessarily have to disassemble messages and rebuild them to change between formats). The protocol itself mentions gateways in several places, but does not discuss how they are expected to map among the various flavors of CoAP defined in this document. Some of the changes seem unnecessary, but it could be that I’m missing the motivation for them. Ideally, the introduction would work harder at explaining why CoAP over these transports is as different from CoAP over UDP as it is, focusing in particular on why the complexity of having three syntactically incompatible headers is justified by the benefits provided by such variations.

Additionally, it’s not clear from the introduction what the motivation for using the mechanisms in this document is as compared to the techniques described in section 10 (and its subsections) of RFC 7252. With the exception of subscribing to resource state (which could be added), it seems that such an approach is significantly easier to implement and more clearly defined than what is in this document; and it appears to provide the combined benefits of all four transports discussed in this document. My concern here is that an explosion of transport options makes it less likely that a client and server can find two in common: the limit of the probability of two implementations having a transport in common as the number of transports approaches infinity is zero. Due to this likely decrease in interoperability, I’d expect to see some pretty powerful motivation in here for defining a third, fourth, fifth, and sixth way to carry CoAP when only TCP is available (I count RFC 7252 http and https as the first and second ways in this accounting).

I’m also a bit puzzled that CoAP already has an inherent mechanism for blocking messages off into chunks, which this document circumvents for TCP connections (by allowing Max-Message-Size to be increased), and then is forced to offer remedies for the resultant head-of-line blocking issues. If you didn’t introduce this feature, messages with a two-byte token add six bytes of overhead for every 1024 bytes of content — less than 0.6% size inflation. It seems like a lot of complicated machinery — which has a built-in foot-gun that you have to warn people about misusing — for a very tiny gain. I know it’s relatively late in the process, but if these trade-offs haven't had a lot of discussion yet, it’s probably worth at least giving them some additional thought.

I’ll note that the entire BERT mechanism seems to fall into the same trap of adding extra complexity for virtually nonexistent savings. CoAP headers are, by design, tiny. It seems like a serious over-optimization to try to eliminate them in this fashion. In particular, you’re making the actual implementation code larger to save a trivial number of bits on the wire; I was under the impression that many of the implementation environments CoAP is intended for had some serious on-chip restrictions that would point away from this kind of additional complexity.

Specific comments follow.

Section 3.3, paragraph 3 says that an initiator may send messages prior to receiving the remote side’s CSM, even though the message may be larger than would be allowed by that CSM.  What should the recipient of an oversized message do in this case? In fact, I don’t see in here what a recipient of a message larger than it allowed for in its CSM is supposed to do in response at *any* stage of the connection. Is it an error? If so, how do you indicate it? Or is the Max-Message-Size option just a suggestion for the other side? This definitely needs clarification. (Aside — it seems odd and somewhat backwards that TCP connections are provided an affordance for fine-grained control over message sizes, while UDP communications are not.)

Section 4.4 has a prohibition against using WebSockets keepalives in favor of using CoAP ping/pong. Section 3.4 has no similar prohibition against TCP keepalives, while the rationale would seem to be identical. Is this asymmetry intentional? (I’ll also note that the presence of keepalive mechanisms in both TCP and WebSockets would seem to make the addition of new CoAP primitives for the same purpose unnecessary, but I suspect this has already been debated).

Section 5 and its subsections define a new set of message types, presumably for use only on connection-oriented protocols, although this is only implied, and never stated. For example, some implementors may see CSM, Ping, and Pong as potentially useful in UDP; and, finding no prohibition in this document against using them, decide to give it a go. Is that intended? If not, I strongly suggest an explicit prohibition against using these in UDP contexts.

Section 5.3.2 says that implementations supporting block-wise transfers SHOULD indicate the Block-wise Transfer Option. I can't figure out why this is anything other than a "MUST". It seems odd that this document would define a way to communicate this, and then choose to leave the communicated options as “YES” and “YOUR GUESS IS AS GOOD AS MINE” rather than the simpler and more useful “YES” and “NO”.

I find the described operation of the Custody Option in the operation of Ping and Pong to be somewhat problematic: it allows the Pong sender to unilaterally decide to set the Custody Option, and consequently quarantine the Pong for an arbitrary amount of time while it processes other operations. This seems impossible to distinguish from a failure-due-to-timeout from the perspective of the Ping sender. Why not limit this behavior only to Ping messages that include the Custody Option?

I find the unmotivated definition of the default port for “coaps+tcp” to 443 — a port that is already assigned to https — to be surprising, to put it mildly. This definitely needs motivating text, and I suspect it's actually wrong.

I am similarly perplexed by the hard-coded “must do ALPN *unless* the designated port takes the magical value 5684” behavior. I don’t think I’ve ever seen a protocol that has such variation based on a hard-coded port number, and it seems unlikely to be deployed correctly (I’m imaging the frustration of: “I changed both the server and the client configuration from the default port of 5684 to 49152, and it just stopped working. Like, literally the *only* way it works is on port 5684. I've checked firewall settings everywhere and don't see any special handling for that port -- I just can't figure this out, and it's driving me crazy.”). Given the nearly universal availability of ALPN in pretty much all modern TLS libraries, it seems much cleaner to just require ALPN support and call it done. Or *don’t* require ALPN at all and call it done. But *changing* protocol behavior based on magic port numbers seems like it’s going to cause a lot of operational heartburn.

The final paragraph of section 8.1 is very confusing, making it somewhat unclear which of the three modes must be implemented on a CoAP client, and which must be implemented on a CoAP server. Read naïvely, this sounds like clients are required to do only one (but one of their choosing) of these three, while servers are required to also do only one (again, of their choosing). It seems that the chance of finding devices that could interoperate under such circumstances is going to be relatively low: to work together, you would have to find a client and a server that happened to make the same implementation choice among these three. What I’m used to in these kinds of cases is: (a) server must implement all, client can choose to implement only one (or more), (b) client must implement all, server can choose to implement only one (or more), or (c) client and server must implement a specifically named lowest-common denominator, and can negotiate up from there. Pretty much anything else (aside from strange “everyone must implement two of three” schemes) will end up with interop issues.

Although the document clearly expects the use of gateways and proxies between these connection-oriented usages of CoAP and UDP-based CoAP, Appendix A seems to omit discussion or consideration of how this gatewaying can be performed. The following list of problems is illustrative of this larger issue, but likely not exhaustive. (I'll note that all of these issues evaporate if you move to a simpler scheme that merely frames otherwise unmodified UDP CoAP messages)

Section A.1 does not indicate what gateways are supposed to do with out-of-order notifications. The TCP side requires these to be delivered in-order; so, do this mean that gateways observing a gap in sequence numbers need to quarantine the newly received message so that it can deliver the missing one first? Or does it deliver the newly-received message and then discard the “stale” one when it arrives? I don’t think that leaving this up to implementations is particularly advisable.

Section A.3 is a bit more worrisome. I understand the desired optimization here, but where you reduce traffic in one direction, you run the risk of exploding it in the other. For example, consider a coap+tcp client connecting to a gateway that communicates with a CoAP-over-UDP server. When that client wants to check the health of its observations, it can send a Ping and receive a Pong that confirms that they are all alive and well. In order to be able to send a Pong that *means* “all your observations are alive and well,” the gateway has to verify that all the observations are alive and well. A simple implementation of a gateway will likely check on each observed resource individually when it gets a Ping, and then send a Pong after it hears back about all of them. So, as a client, I can set up, let’s say, two dozen observations through this gateway. Then, with each Ping I send, the gateway sends two dozen checks towards the server. This kind of message amplification attack is an awesome way to DoS both the gateway and the server. I believe the document needs a treatment of how UDP/TCP gateways handle notification health checks, along with techniques for mitigating this specific attack.

Section A.4 talks about the rather different ways of dealing with unsubscribing from a resource. Presumably, gateways that get a reset to a notification are expected to synthesize a new GET to deregister on behalf of the client? Or is it okay if they just pass along the reset, and expect the server to know that it means the same thing as a deregistration? Without explicit guidance here, I expect server and gateway implementors to make different choices and end up with a lack of interop.

From i-d nits (this appears to be in reference to Figure 1):
** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72.
2017-05-08
08 Adam Roach [Ballot Position Update] New position, Discuss, has been recorded for Adam Roach
2017-05-08
08 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2017-05-06
08 Eric Rescorla [Ballot discuss]
After reading Mark Nottingham's review, I'm persuaded we should at least discuss the relationship of this work to the parallel work in HTTP.
2017-05-06
08 Eric Rescorla [Ballot Position Update] Position for Eric Rescorla has been changed to Discuss from No Objection
2017-05-06
08 Eric Rescorla
[Ballot comment]
Document: draft-ietf-core-coap-tcp-tls-08.txt

TECHNICAL
You need to specify MTI cipher suites. I don't think that the
ones you specified in 7925 are very useful …
[Ballot comment]
Document: draft-ietf-core-coap-tcp-tls-08.txt

TECHNICAL
You need to specify MTI cipher suites. I don't think that the
ones you specified in 7925 are very useful for TLS. Is this really
really what you want?


S 3.2.
Having the lengths offset by 13 bytes is, IMO, pretty silly.  I
realize it avoids duplication, but it also makes the packets hard to
read for not much value. As a practical matter, it expands the
1-byte length for the range 256-268, for a savings of less than
.5% even on those packets and on average far less.


S 4.1.
  The WebSocket client MUST include the subprotocol name "coap" in the
  list of protocols, which indicates support for the protocol defined
  in this document.  Any later, incompatible versions of CoAP or CoAP
  over WebSockets will use a different subprotocol name.

This doesn't make much sense, because you are willing to have incompatible
protocols for TCP, where you use CSM to distinguish them, and you do
the same thing with ALPN.


S 5.5.
These release semantics seem quite problematic. In particular, when
people want an orderly close, they typically want the other side
to process all the outstanding requests and then return them, but
this doesn't seem to do that (note that just because the responses
need to be *delivered* in order doesn't mean they need to be generated
in order). So, for instance, say I have the following sequence of
events:

C                S          DB
GET /a -> 
                  Request A ->     
Release ->
                  FIN
                  <- Response A

It seems like the only difference between Abort and Release is that
the sender is saying "don't expect that I processed any of your
messages", but in at least a lot of scenarios (e.g., where the
initiator is basically just a client), this doesn't actually tell
the server much about sequence because the responses aren't ordered
wrt Release AFAICT.

  Release message by closing the TCP/TLS connection.  Messages may be
  in flight when the sender decides to send a Release message.  The
  general expectation is that these will still be processed.

This is not really useful language.


  For CoAP over reliable transports, the recipient rejects such
  messages by sending an Abort message and otherwise ignoring the
  message.  No specific option has been defined for the Abort message
  in this case, as the details are best left to a diagnostic payload.

I don't understand this text. Abort seems to mean "I'm done", but then
how am I ignoring the message.


S 6.
I found this section pretty confusing. In 7959, when M=0 you need
to stay *under* the block boundary but here you say:

  In descriptive usage, a BERT Option is interpreted in the same way as
  the equivalent Option with SZX == 6, except that the payload is also
  allowed to contain a multiple of 1024 bytes (non-final BERT block) or
  more than 1024 bytes (final BERT block).

And your examples pretty clearly show it being >> 1024. What's the
reasoning here

  In control usage, a BERT option is interpreted in the same way as the
  equivalent Option with SZX == 6, except that it also indicates the
  capability to process BERT blocks.

But:

  Block-wise Transfer Option.  If a Max-Message-Size Option is
  indicated with a value that is greater than 1152 (in the same or a
  different CSM message), the Block-wise Transfer Option also indicates
  support for BERT (see Section 6).  Subsequently, if the Max-Message-

Is this an instruction to set the BTO to be 7? Or redundancy?





EDITORIAL
S 3.2.
      Length (Len):  4-bit unsigned integer.  A value between 0 and 12
      directly indicates the length of the message in bytes starting

I think you want to say "0 and 12 inclusive"


S 5.3.1.
  These are not default values for the option, as defined in
  Section 5.4.4 in [RFC7252].  A default value would mean that an empty
  Capabilities and Settings message would result in the option being
  set to its default value.

This is pretty confusing text. I take it that it means that if
the base values of both A and B are 0, then:

  Start    // A=0, B=0
  CSM[A=1] // A=1, B=0
  CSM[B=2] // A=1, B=2

Whereas if these were default values, then this would be:

  Start    // A=0, B=0
  CSM[A=1] // A=1, B=0
  CSM[B=2] // A=0, B=2  <- A resets to default

If that's so, perhaps you could say:

  These are not default values for the option, as defined in
  Section 5.4.4 in [RFC7252], because default values apply
  on a per-message basis and thus reset when the value is
  not present in a given CSM.
2017-05-06
08 Eric Rescorla [Ballot Position Update] New position, No Objection, has been recorded for Eric Rescorla
2017-05-05
08 Alexey Melnikov IESG state changed to IESG Evaluation from Waiting for Writeup::AD Followup
2017-05-05
08 Alexey Melnikov Placed on agenda for telechat - 2017-05-11
2017-05-05
08 Alexey Melnikov Ballot has been issued
2017-05-05
08 Alexey Melnikov [Ballot Position Update] New position, Yes, has been recorded for Alexey Melnikov
2017-05-05
08 Alexey Melnikov Created "Approve" ballot
2017-05-05
08 Alexey Melnikov Ballot writeup was changed
2017-04-21
08 (System) Sub state has been changed to AD Followup from Revised ID Needed
2017-04-21
08 (System) IANA Review state changed to Version Changed - Review Needed from IANA - Not OK
2017-04-21
08 Brian Raymor New version available: draft-ietf-core-coap-tcp-tls-08.txt
2017-04-21
08 (System) New version approved
2017-04-21
08 (System)
Request for posting confirmation emailed to previous authors: Klaus Hartke , Simon Lemay , Carsten Bormann , Hannes Tschofenig , Bill Silverajan , Brian Raymor …
Request for posting confirmation emailed to previous authors: Klaus Hartke , Simon Lemay , Carsten Bormann , Hannes Tschofenig , Bill Silverajan , Brian Raymor , core-chairs@ietf.org
2017-04-21
08 Brian Raymor Uploaded new revision
2017-04-14
07 Alexey Melnikov New version is needed based on ARTART Directorate review.
2017-04-14
07 Alexey Melnikov IESG state changed to Waiting for Writeup::Revised I-D Needed from Waiting for Writeup
2017-04-13
07 Jean Mahoney Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Meral Shirazipour.
2017-04-11
07 Wesley Eddy Request for Last Call review by TSVART Completed: Almost Ready. Reviewer: Yoshifumi Nishida.
2017-04-09
07 Mark Nottingham Request for Last Call review by ARTART Completed: Not Ready. Reviewer: Mark Nottingham. Sent review to list.
2017-04-09
07 (System) IESG state changed to Waiting for Writeup from In Last Call
2017-04-07
07 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2017-04-07
07 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-core-coap-tcp-tls-07.txt. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-core-coap-tcp-tls-07.txt. If any part of this review is inaccurate, please let us know.

We have a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Services Operator understands that, upon approval of this document, there are seven actions which we must complete.

First, a new registry is to be created called the CoAP Signaling Codes registry. This registry is to be a subregistry of the existing CoAP Codes registry which is a subregistry of the Constrained RESTful Environments (CoRE) Parameters registry located at:

https://www.iana.org/assignments/core-parameters/

The new subregistry is managed by IETF Review or IESG Approval as defined in RFC 5226.

Each entry in the sub-registry must include the Signaling Code in the range 7.00-7.31, its name, and a reference to its documentation.

There are initial entries in the new subregistry as follows:

+------+---------+---------------+
| Code | Name | Reference |
+------+---------+---------------+
| 7.01 | CSM | [ RFC-to-be ] |
| 7.02 | Ping | [ RFC-to-be ] |
| 7.03 | Pong | [ RFC-to-be ] |
| 7.04 | Release | [ RFC-to-be ] |
| 7.05 | Abort | [ RFC-to-be ] |
+------+---------+---------------+

Second, a new registry is to be created called the CoAP Signaling Option Numbers registry. This registry is to be a subregistry of the Constrained RESTful Environments (CoRE) Parameters registry located at:

https://www.iana.org/assignments/core-parameters/

The registration policy for future additions to this sub-registry is split into three tiers as follows. The range of 0..255 is reserved for options defined by the IETF (IETF Review or IESG Approval). The range of 256..2047 is reserved for commonly used options with public specifications (Specification Required). The range of 2048..64999 is for all other options including private or vendor-specific ones, which undergo a Designated Expert review to help ensure that the option semantics are defined correctly. The option numbers between 65000 and 65535 inclusive are reserved for experiments. They are not meant for vendor-specific use of any kind and MUST NOT be used in operational deployments.

There are initial entries in the new registry as follows:

+------------+--------+---------------------+---------------+
| Applies to | Number | Name | Reference |
+------------+--------+---------------------+---------------+
| 7.01 | 2 | Max-Message-Size | [ RFC-to-be ] |
| 7.01 | 4 | Block-wise-Transfer | [ RFC-to-be ] |
| 7.02, 7.03 | 2 | Custody | [ RFC-to-be ] |
| 7.04 | 2 | Alternative-Address | [ RFC-to-be ] |
| 7.04 | 4 | Hold-Off | [ RFC-to-be ] |
| 7.05 | 2 | Bad-CSM-Option | [ RFC-to-be ] |
+------------+--------+---------------------+---------------+

IANA QUESTION --> in the initial registrations above, the value 7.04 appears twice in the registry. Is this intended?

Third, sections 10.3 and 10.4 of the current draft request the registration of service names and port numbers for both 5683 and 5684 for coap+tcp. We note that these registrations are complete.

Fourth, in the Uniform Resource Identifier (URI) Schemes registry located at:

https://www.iana.org/assignments/uri-schemes/

four URI schemes are to be registered as follows:

URI Scheme: coap+tcp
Template: [ TBD-at-registration ]
Description: The scheme is used by CoAP endpoints to access CoAP resources using TCP.
Status: Permanent
Reference: [ RFC-to-be ]

URI Scheme: coaps+tcp
Template: [ TBD-at-registration ]
Description: The scheme is used by CoAP endpoints to access CoAP resources using TLS.
Status: Permanent
Reference: [ RFC-to-be ]

URI Scheme: coap+ws
Template: [ TBD-at-registration ]
Description: The scheme is used by CoAP endpoints to access CoAP resources using the WebSocket protocol.
Status: Permanent
Reference: [ RFC-to-be ]

URI Scheme: coaps+ws
Template: [ TBD-at-registration ]
Description: The scheme is used by CoAP endpoints to access CoAP resources using the WebSocket protocol secured with TLS.
Status: Permanent
Reference: [ RFC-to-be ]

Because this registry requires Expert Review [RFC5226] for registration, we've contacted the IESG-designated expert in a separate ticket to request approval. Expert review should be completed before your document can be approved for publication as an RFC.

Fifth, in the Well-Know URIs registry located at:

https://www.iana.org/assignments/well-known-uris/

a new, well-known URI is to be registered as follows:

URI Suffix: coap
Change Controller: IETF
Reference: [ RFC-to-be ]
Related Information:
Date Registered: [ TBD-at-Registration ]

Because this registry also requires Expert Review [RFC5226] for registration, we've contacted the IESG-designated expert in a separate ticket to request approval. Expert review should be completed before your document can be approved for publication as an RFC.

Sixth, in the Application-Layer Protocol Negotiation (ALPN) Protocol IDs subregistry of the Transport Layer Security (TLS) Extensions registry located at:

https://www.iana.org/assignments/tls-extensiontype-values/

a new ID is to be registered as follows:

Protocol: CoAP
Identification Sequence: 0x63 0x6f 0x61 0x70 ("coap")
Reference: [ RFC-to-be ]

Because this registry also requires Expert Review [RFC5226] for registration, we've contacted the IESG-designated expert in a separate ticket to request approval. Expert review should be completed before your document can be approved for publication as an RFC.

Seventh, in the WebSocket Subprotocol Name Registry in the WebSocket Protocol Registries located at:

https://www.iana.org/assignments/websocket/

a new subprotocol name is to be registered as follows:

Subprotocol Identifier: coap
Subprotocol Common Name: Constrained Application Protocol (CoAP)
Subprotocol Definition: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

The IANA Services Operator understands that these seven actions are the only ones required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI
2017-04-04
07 Wesley Eddy Request for Last Call review by TSVART is assigned to Yoshifumi Nishida
2017-04-04
07 Wesley Eddy Request for Last Call review by TSVART is assigned to Yoshifumi Nishida
2017-03-31
07 Alexey Melnikov Request for Last Call review by ARTART is assigned to Mark Nottingham
2017-03-31
07 Alexey Melnikov Request for Last Call review by ARTART is assigned to Mark Nottingham
2017-03-30
07 Tero Kivinen Request for Last Call review by SECDIR is assigned to Melinda Shore
2017-03-30
07 Tero Kivinen Request for Last Call review by SECDIR is assigned to Melinda Shore
2017-03-27
07 Jean Mahoney Request for Last Call review by GENART is assigned to Meral Shirazipour
2017-03-27
07 Jean Mahoney Request for Last Call review by GENART is assigned to Meral Shirazipour
2017-03-27
07 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Lionel Morand
2017-03-27
07 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Lionel Morand
2017-03-26
07 Cindy Morgan IANA Review state changed to IANA - Review Needed
2017-03-26
07 Cindy Morgan
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC: jaime.jimenez@ericsson.com, core-chairs@ietf.org, draft-ietf-core-coap-tcp-tls@ietf.org, Jaime Jimenez , core@ietf.org, …
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC: jaime.jimenez@ericsson.com, core-chairs@ietf.org, draft-ietf-core-coap-tcp-tls@ietf.org, Jaime Jimenez , core@ietf.org, alexey.melnikov@isode.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets) to Proposed Standard


The IESG has received a request from the Constrained RESTful Environments
WG (core) to consider the following document:
- 'CoAP (Constrained Application Protocol) over TCP, TLS, and
WebSockets'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-04-09. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The Constrained Application Protocol (CoAP), although inspired by
  HTTP, was designed to use UDP instead of TCP.  The message layer of
  the CoAP over UDP protocol includes support for reliable delivery,
  simple congestion control, and flow control.

  Some environments benefit from the availability of CoAP carried over
  reliable transports such as TCP or TLS.  This document outlines the
  changes required to use CoAP over TCP, TLS, and WebSockets
  transports.  It also formally updates [RFC7641] for use with these
  transports.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-core-coap-tcp-tls/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-core-coap-tcp-tls/ballot/


No IPR declarations have been submitted directly on this I-D.




2017-03-26
07 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2017-03-26
07 Alexey Melnikov Last call was requested
2017-03-26
07 Alexey Melnikov Last call announcement was generated
2017-03-26
07 Alexey Melnikov Ballot approval text was generated
2017-03-26
07 Alexey Melnikov Ballot writeup was generated
2017-03-26
07 Alexey Melnikov IESG state changed to Last Call Requested from AD Evaluation
2017-03-26
07 Alexey Melnikov IESG state changed to AD Evaluation from Publication Requested
2017-03-26
07 Alexey Melnikov Changed consensus to Yes from Unknown
2017-03-21
07 Jaime Jimenez
## Shepherd Writeup

Full HTML version can be found at: http://jaimejim.github.io/temp/draft-ietf-core-coap-tcp-tls#shepherd-writeup

###Summary

Document Shepherd: Jaime Jiménez,
Area Director: Alexey Melnikov,

The Constrained Application Protocol (CoAP), …
## Shepherd Writeup

Full HTML version can be found at: http://jaimejim.github.io/temp/draft-ietf-core-coap-tcp-tls#shepherd-writeup

###Summary

Document Shepherd: Jaime Jiménez,
Area Director: Alexey Melnikov,

The Constrained Application Protocol (CoAP), although inspired by HTTP, was designed to use UDP instead of TCP.  The message layer of the CoAP over UDP protocol includes support for reliable delivery, simple congestion control, and flow control.

Some environments benefit from the availability of CoAP carried over reliable transports such as TCP or TLS.  This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets transports.  It also formally updates [RFC7641](https://tools.ietf.org/html/rfc7641)  for use with these transports.

The document is intended as an **Standards Track RFC**.

###Review and Consensus

The document has gone through multiple expert reviews over the years and was last presented on multiple IETF sessions.

###Intellectual Property

Each author has stated that they do not have direct, personal knowledge of any IPR related to this document. I am not aware of any IPR discussion about this document on the CoRE WG.

###Other Points

* The issues solved in the last iteration can be found in the [github repository](https://github.com/core-wg/coap-tcp-tls/issues?q=is%3Aissue+is%3Aclosed+milestone%3Acoap-tcp-tls-06).

* There will be a new submission v08 that will contain minor changes and a small clarification for the "bi-directional" channel part.

###Checklist

* [x] Does the shepherd stand behind the document and think the document is ready for publication?
* [x] Is the correct RFC type indicated in the title page header?
* [x] Is the abstract both brief and sufficient, and does it stand alone as a brief summary?
* [x] Is the intent of the document accurately and adequately explained in the introduction?
* [x] Have all required formal reviews (MIB Doctor, Media Type, URI, etc.) been requested and/or completed?
`URI-Scheme needs to be checked, wellknown-uri-review@ietf.org`
* [x] Has the shepherd performed automated checks -- idnits (see http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist), checks of BNF rules, XML code and schemas, MIB definitions, and so on -- and determined that the document passes the tests?
`There was a typo on the ABNF, corrected on the editor's copy`
* [x] Has each author stated that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79?
* [x] Have all references within this document been identified as either normative or informative, and does the shepherd agree with how they have been classified?
`RFC7959 has to be changed to normative during AD-review`
* [x] Are all normative references made to documents that are ready for advancement and are otherwise in a clear state?
`RFC7959 has to be changed to normative during AD-review`
* [x] If publication of this document changes the status of any existing RFCs, are those RFCs listed on the title page header, and are the changes listed in the abstract and discussed (explained, not just mentioned) in the introduction?
`Yes RFC7641, seems to be sufficient.`
* [x] If this is a "bis" document, have all of the errata been considered?
`Does not apply`

* **IANA** Considerations:

* [x] Are the IANA Considerations clear and complete? Remember that IANA have to understand unambiguously what's being requested, so they can perform the required actions.
`URI-Scheme needs to be checked, wellknown-uri-review@ietf.org
RFC7301 seems not to have a specific contact email. 
RFC5226 First Come First Served IANA registration policy.
RFC6335 IESG can do the update.`

* [x] Are all protocol extensions that the document makes associated with the appropriate reservations in IANA registries?
* [x] Are all IANA registries referred to by their exact names (check them in http://www.iana.org/protocols/ to be sure)?
* [x] Have you checked that any registrations made by this document correctly follow the policies and procedures for the appropriate registries?
* [x] For registrations that require expert review (policies of Expert Review or Specification Required), have you or the working group had any early review done, to make sure the requests are ready for last call?
`in progress`
* [x] For any new registries that this document creates, has the working group actively chosen the allocation procedures and policies and discussed the alternatives?
`Section 10.1 "CoAP Signaling Codes". Same policy as for method codes RFC7252`
* [x]  Have reasonable registry names been chosen (that will not be confused with those of other registries), and have the initial contents and valid value ranges been clearly specified?
2017-03-21
07 Jaime Jimenez IETF WG state changed to Submitted to IESG for Publication from WG Document
2017-03-21
07 Jaime Jimenez IESG state changed to Publication Requested from AD is watching
2017-03-21
07 Jaime Jimenez
## Shepherd Writeup

Full HTML version can be found at: http://jaimejim.github.io/temp/draft-ietf-core-coap-tcp-tls#shepherd-writeup

###Summary

Document Shepherd: Jaime Jiménez,
Area Director: Alexey Melnikov,

The Constrained Application Protocol (CoAP), …
## Shepherd Writeup

Full HTML version can be found at: http://jaimejim.github.io/temp/draft-ietf-core-coap-tcp-tls#shepherd-writeup

###Summary

Document Shepherd: Jaime Jiménez,
Area Director: Alexey Melnikov,

The Constrained Application Protocol (CoAP), although inspired by HTTP, was designed to use UDP instead of TCP.  The message layer of the CoAP over UDP protocol includes support for reliable delivery, simple congestion control, and flow control.

Some environments benefit from the availability of CoAP carried over reliable transports such as TCP or TLS.  This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets transports.  It also formally updates [RFC7641](https://tools.ietf.org/html/rfc7641)  for use with these transports.

The document is intended as an **Standards Track RFC**.

###Review and Consensus

The document has gone through multiple expert reviews over the years and was last presented on multiple IETF sessions.

###Intellectual Property

Each author has stated that they do not have direct, personal knowledge of any IPR related to this document. I am not aware of any IPR discussion about this document on the CoRE WG.

###Other Points

* The issues solved in the last iteration can be found in the [github repository](https://github.com/core-wg/coap-tcp-tls/issues?q=is%3Aissue+is%3Aclosed+milestone%3Acoap-tcp-tls-06).

* There will be a new submission v08 that will contain minor changes and a small clarification for the "bi-directional" channel part.

###Checklist

* [x] Does the shepherd stand behind the document and think the document is ready for publication?
* [x] Is the correct RFC type indicated in the title page header?
* [x] Is the abstract both brief and sufficient, and does it stand alone as a brief summary?
* [x] Is the intent of the document accurately and adequately explained in the introduction?
* [x] Have all required formal reviews (MIB Doctor, Media Type, URI, etc.) been requested and/or completed?
`URI-Scheme needs to be checked, wellknown-uri-review@ietf.org`
* [x] Has the shepherd performed automated checks -- idnits (see http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist), checks of BNF rules, XML code and schemas, MIB definitions, and so on -- and determined that the document passes the tests?
`There was a typo on the ABNF, corrected on the editor's copy`
* [x] Has each author stated that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79?
* [x] Have all references within this document been identified as either normative or informative, and does the shepherd agree with how they have been classified?
`RFC7959 has to be changed to normative during AD-review`
* [x] Are all normative references made to documents that are ready for advancement and are otherwise in a clear state?
`RFC7959 has to be changed to normative during AD-review`
* [x] If publication of this document changes the status of any existing RFCs, are those RFCs listed on the title page header, and are the changes listed in the abstract and discussed (explained, not just mentioned) in the introduction?
`Yes RFC7641, seems to be sufficient.`
* [x] If this is a "bis" document, have all of the errata been considered?
`Does not apply`

* **IANA** Considerations:

* [x] Are the IANA Considerations clear and complete? Remember that IANA have to understand unambiguously what's being requested, so they can perform the required actions.
`URI-Scheme needs to be checked, wellknown-uri-review@ietf.org
RFC7301 seems not to have a specific contact email. 
RFC5226 First Come First Served IANA registration policy.
RFC6335 IESG can do the update.`

* [x] Are all protocol extensions that the document makes associated with the appropriate reservations in IANA registries?
* [x] Are all IANA registries referred to by their exact names (check them in http://www.iana.org/protocols/ to be sure)?
* [x] Have you checked that any registrations made by this document correctly follow the policies and procedures for the appropriate registries?
* [x] For registrations that require expert review (policies of Expert Review or Specification Required), have you or the working group had any early review done, to make sure the requests are ready for last call?
`in progress`
* [x] For any new registries that this document creates, has the working group actively chosen the allocation procedures and policies and discussed the alternatives?
`Section 10.1 "CoAP Signaling Codes". Same policy as for method codes RFC7252`
* [x]  Have reasonable registry names been chosen (that will not be confused with those of other registries), and have the initial contents and valid value ranges been clearly specified?
2017-03-06
07 Brian Raymor New version available: draft-ietf-core-coap-tcp-tls-07.txt
2017-03-06
07 (System) New version approved
2017-03-06
07 (System)
Request for posting confirmation emailed to previous authors: Klaus Hartke , Simon Lemay , Carsten Bormann , Hannes Tschofenig , Bill Silverajan , Brian Raymor …
Request for posting confirmation emailed to previous authors: Klaus Hartke , Simon Lemay , Carsten Bormann , Hannes Tschofenig , Bill Silverajan , Brian Raymor , core-chairs@ietf.org
2017-03-06
07 Brian Raymor Uploaded new revision
2017-02-14
06 Brian Raymor New version available: draft-ietf-core-coap-tcp-tls-06.txt
2017-02-14
06 (System) New version approved
2017-02-14
06 (System)
Request for posting confirmation emailed to previous authors: "Klaus Hartke" , core-chairs@ietf.org, "Brian Raymor" , "Carsten Bormann" , "Simon Lemay" , "Hannes Tschofenig" , …
Request for posting confirmation emailed to previous authors: "Klaus Hartke" , core-chairs@ietf.org, "Brian Raymor" , "Carsten Bormann" , "Simon Lemay" , "Hannes Tschofenig" , "Bill Silverajan"
2017-02-14
06 Brian Raymor Uploaded new revision
2016-10-11
05 Brian Raymor New version available: draft-ietf-core-coap-tcp-tls-05.txt
2016-10-11
05 (System) New version approved
2016-10-11
04 (System)
Request for posting confirmation emailed to previous authors: "Klaus Hartke" , core-chairs@ietf.org, "Brian Raymor" , "Carsten Bormann" , "Simon Lemay" , "Hannes Tschofenig" , …
Request for posting confirmation emailed to previous authors: "Klaus Hartke" , core-chairs@ietf.org, "Brian Raymor" , "Carsten Bormann" , "Simon Lemay" , "Hannes Tschofenig" , "Bill Silverajan"
2016-10-11
04 Brian Raymor Uploaded new revision
2016-08-24
04 Brian Raymor New version available: draft-ietf-core-coap-tcp-tls-04.txt
2016-07-08
03 Carsten Bormann This document now replaces draft-tschofenig-core-coap-tcp-tls, draft-bormann-core-coap-sig, draft-bormann-core-block-bert, draft-savolainen-core-coap-websockets instead of draft-tschofenig-core-coap-tcp-tls
2016-07-08
03 Brian Raymor New version available: draft-ietf-core-coap-tcp-tls-03.txt
2016-06-11
02 Alexey Melnikov Notification list changed to "Jaime Jimenez" <jaime.jimenez@ericsson.com>
2016-06-11
02 Alexey Melnikov Document shepherd changed to Jaime Jimenez
2016-04-23
02 Alexey Melnikov Intended Status changed to Proposed Standard
2016-04-23
02 Alexey Melnikov IESG process started in state AD is watching
2016-04-23
02 (System) Earlier history may be found in the Comment Log for /doc/draft-tschofenig-core-coap-tcp-tls/
2016-04-21
02 Carsten Bormann New version available: draft-ietf-core-coap-tcp-tls-02.txt
2016-04-04
01 Carsten Bormann Added to session: IETF-95: core  Tue-1740
2015-11-19
01 Carsten Bormann New version available: draft-ietf-core-coap-tcp-tls-01.txt
2015-11-18
00 Carsten Bormann This document now replaces draft-tschofenig-core-coap-tcp-tls instead of None
2015-11-18
00 Carsten Bormann New version available: draft-ietf-core-coap-tcp-tls-00.txt