Subject: Re: [core] Editors' draft of changes to draft-ietf-core-coap-tcp-tls-08 after IESG input

From: Dave Thaler <[email-masked]>
Date: Thu, 15 Jun 2017 18:08:18 +0000

I haven’t seen any response to my WG post about resource directory so I’ll add onto Carsten’s response here which I agree with.
Specifically draft -09 says:
7.1<https://tools.ietf.org/html/draft-ietf-core-coap-tcp-tls-09#section-7.1>.  Use of the "coap" URI scheme with TCP

   The "coap" URI scheme defined in Section 6.1 of [RFC7252]<https://tools.ietf.org/html/rfc7252#section-6.1> can also be

   used to identify CoAP resources that are intended to be accessible

   using CoAP over TCP.

   The syntax defined in Section 6.1 of [RFC7252]<https://tools.ietf.org/html/rfc7252#section-6.1> applies to this

   transport, with the following change:

   o  The port subcomponent indicates the TCP port at which the CoAP

      server is located.  (If it is empty or not given, then the default
      port 5683 is assumed, as with UDP.)

The problem I have with the above text is that it makes the meaning of the port in the URI be ambiguous, which is problematic.
You cannot assume (since no such requirement is stated in the doc) that the UDP port number and TCP port number are the same.
So let’s say the server uses ephemeral ports for a given resource that is accessible over both UDP and TCP, and it got given
UDP port 50000 and TCP port 51000.   Does it have two URIs for that resource?  i.e.
                coap://hostname:50000/resource/path
                coap://hostname:51000/resource/path

If a client gets either or both of those, it has no idea whether the port number is a UDP or a TCP port number, and if it guesses wrong,
it’s a completely different resource (e.g., /resource/path on UDP port 51000 might be a different app with a different resource).
As such, there is no guarantee of interoperability.  Indeed an RFC 7252 compliant client will treat both as UDP port numbers,
and can end up accessing the wrong resource as a result.   That breaks backwards compatibility.

Hence unless someone can explain why this doesn’t break backwards compatibility, I think section 7.1 in draft-09 is broken.

Dave

From: core [mailto:[email-masked]] On Behalf Of Carsten Bormann
Sent: Monday, May 15, 2017 8:45 AM
To: Kraus Achim (INST/ECS4) <[email-masked]>
Cc: [email-masked]
Subject: Re: [core] Editors' draft of changes to draft-ietf-core-coap-tcp-tls-08 after IESG input

Well, I just tried to realize what the IESG thought was right. But I can't fail to notice that the existing solution didn't really address the situation very well either, except where the server (or other entity supplying the link) knew exactly what the client should be doing. Section 7.8 is trying to give some guidance, but it will hardly ever be good enough to propose solutions for all possible situations.

Sent from mobile

On 15. May 2017, at 16:52, Kraus Achim (INST/ECS4) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Carsten,

IESG members have asked us to stop proliferating URI schemes, and as a result the draft remains with coap:// and coaps:// for all new transports.

Assuming a system, which supports CoAP over UDP and over TCP, how should such a system select, if UDP or TCP is intended to be used for a given destination?

Mit freundlichen Grüßen / Best regards

Achim Kraus

(INST/ECS4)
Bosch Software Innovations GmbH | Stuttgarter Straße 130 | 71332 Waiblingen | GERMANY | www.bosch-si.com<http://www.bosch-si.com>

Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Geschäftsführung: Dr.-Ing. Rainer Kallenbach, Michael Hahn

-----Original Message-----
From: core [mailto:[email-masked]] On Behalf Of Carsten Bormann
Sent: Montag, 15. Mai 2017 16:32
To: core <[email-masked]<mailto:[email-masked]>>
Subject: [core] Editors' draft of changes to draft-ietf-core-coap-tcp-tls-08 after IESG input

I have generate a first editors’ draft of what might become draft-ietf-core-coap-tcp-tls-09, addressing IESG input on the draft.
(This draft addresses DISCUSSes, but almost no COMMENTS; see https://github.com/core-wg/coap-tcp-tls/issues for an overview what else needs to be done.)

This has a bit of Brownian motion (default ports etc.), but also one important change:

IESG members have asked us to stop proliferating URI schemes, and as a result the draft remains with coap:// and coaps:// for all new transports.

Please see:

https://tools.ietf.org/rfcdiff?url1=draft-ietf-core-coap-tcp-tls&url2=https://raw.githubusercontent.com/core-wg/coap-tcp-tls/gh-pages/iesg/draft-ietf-core-coap-tcp-tls.txt

for the changes from -08, and

https://core-wg.github.io/coap-tcp-tls/iesg/

for a full document.

For example,

https://core-wg.github.io/coap-tcp-tls/iesg/#rfc.section.7.8

is a new section, but many other sections concerned with URIs and URI schemes have received changes.

It is important if the WG can live with this change, or whether we need to incur further delay pushing back on this change.
Please let us know!

Grüße, Carsten

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

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Fri, 16 Jun 2017 20:49:09 +0000

Hi all

To me it feels, we need a special session for this during IETF 99. It is really hard to follow the arguments in the e-mails, as there are so many unspoken assumptions, solutions-in-mind, and misunderstandings. I would guess, I am not the only one who cannot get a clear picture of the (assumed) problem, implications, and possible solutions.

It would be good to know what “what URI schemes actually mean” means.
To me, it defines the syntax and semantics of the rest of the URI. Important semantics would be if the port is a UDP or a TCP port.

It would be good to know how the mess of HTTP 1.x, SPDY1, SPDY2, SPDY3, H2, and QUIC is actually solved.
To my understanding in particular SPDY and QUIC are solved by out-of-band info patched into the browser (~Chrome knew what gmail.com speaks…~).

It would be good to know what the actual assumptions are.
CoAP clients do trial-and-error until they get a response?
All CoAP endpoints are expected to implement all transport and the pick of transport is just because of the middlebox baggage?
Web Linking will always include transport hints in the future?
It is just a hint even when the publisher of a link knows for sure what transports are implemented in the origin server?
…

How come we still need https and http?

Ciao,
Matthias

From: core [mailto:[email-masked]] On Behalf Of Dave Thaler
Sent: Thursday, 15 June 2017 20:08
To: Carsten Bormann <[email-masked]>; Kraus Achim (INST/ECS4) <[email-masked]>
Cc: [email-masked]
Subject: Re: [core] Editors' draft of changes to draft-ietf-core-coap-tcp-tls-08 after IESG input

   using CoAP over TCP.

Dave

From: core [mailto:[email-masked]] On Behalf Of Carsten Bormann
Sent: Monday, May 15, 2017 8:45 AM
To: Kraus Achim (INST/ECS4) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [core] Editors' draft of changes to draft-ietf-core-coap-tcp-tls-08 after IESG input

Sent from mobile

Achim Kraus

(INST/ECS4)

-----Original Message-----
From: core [mailto:[email-masked]] On Behalf Of Carsten Bormann
Sent: Montag, 15. Mai 2017 16:32
To: core <[email-masked]<mailto:[email-masked]>>
Subject: [core] Editors' draft of changes to draft-ietf-core-coap-tcp-tls-08 after IESG input

Please see:

for a full document.

For example,

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 16 Jun 2017 23:25:37 +0200

> How come we still need https and http?

Right.

I believe we had the best possible solution for this “Gemengelage” (untranslatable German word for a situation where a number of unrelated issues collide and create something utterly complicated to resolve) in -07.

The IESG has a number of people who have the scars from SIP, which ran into a superficially similar, but actually mostly unrelated issue and resolved it by attaching a transport hint to an otherwise identical URI.  We cannot do this as easily as SIP could, but got stuck with the idea that we have to use the same URI scheme for the different transports.

http:// and https:// have the same problem, but
1 — it was resolved that the resources under these two schemes are unrelated,
2 — people got used to the pain caused by this.

(We are mirroring this with coap:// and coaps://, and I don’t think this is controversial — it really does make a semantic difference whether there are transport security expectations bound to the resolution of that URI or not.)

With respect to the UDP/TCP/WS decision, we tried to do (1) in -07, but did not have (2), obviously.
(I believe (1) is not so bright for UDP coap vs. TCP coap, so if (1) doesn’t help getting acceptance then we shouldn’t do it.)

The consensus document governing registration of URI schemes is RFC 7595.  I believe we were in full compliance with that with -07.  I don’t want to run process arguments before we have completed the technical discussion, but I actually believe e.g. section 3.3 of that document is less clearly satisfied by -09 than it was by -07.  More importantly than those process issues, my problem is that the issues the IESG members have in mind appear to be undocumented, so I can’t learn about them from a document that exposes them in a detailed manner.

Coap-tcp of course also was done in the knowledge that there are other transports waiting, such as webrtc-dc, SMS or even slipmux.  It seems unlikely these can be done with a URI-Scheme that is common with the IP-address based ones.

We cannot really learn much from the way HTTP solves its transport vagaries because those solutions are based on the ability to put a lot of complexity into implementations.  For HTTP, the URI has a much more user-visible role, and it is likely appropriate to incur this complexity to keep up the fiction that there is only one HTTP.  CoAP is meant to be direct and to the point, without relying on tons of pre-configuration, learning, or indirection, so any happy eyeball style approaches are grossly suboptimal.
(They may still be necessary in certain not so nice cases; cf. the work on Thin ICE.)

Given that URI-Schemes are a dime a dozen (with provisional registrations being easy), I’m not sure that implementers (or downstream SDOs) won’t go the way of registering (or even squatting on) their own transport-specific URI-Schemes to return to sanity.

Having a meeting about the URI-Scheme issue might indeed be the only way forward remaining.  
It is also a slow way forward.

Grüße, Carsten

---

From: Bill Silverajan <[email-masked]>
Date: Sat, 17 Jun 2017 13:07:53 +0300

Hi,

>> All CoAP endpoints are expected to implement all transport and the pick of transport is just because of the middlebox baggage?

In discouraging the use of several URI schemes for CoAP, one review 
recommended a series of steps, in which CoAP over UDP is MTI: Always try 
UDP first, and if no response is forthcoming, to then resort to TCP. 
Port 80/443 would always default to CoAP over ws or wss without needing 
to engage UDP initially. Obviously this has repercussions regarding 
protocol and application logic.
>> It is just a hint even when the publisher of a link knows for sure what transports are implemented in the origin server?
I think it is important to have mechanisms to allow transport hints, 
regardless [1].
> The IESG has a number of people who have the scars from SIP, which ran into a superficially similar, but actually mostly unrelated issue and resolved it by attaching a transport hint to an otherwis…
What we learnt from the CoAP Alternative Transport URI work [2] is:

A) Embedding the transport hint in the URI path, fragment or query 
component is a bad idea
B) Placing it in the host in the URI authority component can become 
easily complicated. Moreover, RFC 7320 forbids this.
> Given that URI-Schemes are a dime a dozen (with provisional registrations being easy), I’m not sure that implementers (or downstream SDOs) won’t go the way of registering (or even squatting on) the…
This is correct. Extending the CoAP application logic instead to support 
a new transport, without using a new URI format, would be more complex. 
It also complicates RD registrations and lookups.

Conversely, it must also be recognised that right now, some mechanisms 
are bound to the "coap" and "coaps" URI schemes, such as using 
".well-known/". Minting new CoAP URI schemes would also require 
extending this to support them.

Regards,
Bill

[1] 
https://datatracker.ietf.org/doc/draft-silverajan-core-coap-protocol-negotiation/
[2] 
https://tools.ietf.org/html/draft-silverajan-core-coap-alternative-transports-09#appendix-A

---

From: "weigengyu" <[email-masked]>
Date: Sat, 17 Jun 2017 20:16:34 +0800

Hi,

> The IESG has a number of people who have the scars from SIP, which ran 
> into a superficially similar,
> but actually mostly unrelated issue and resolved it by attaching a 
> transport hint to an otherwise identical URI.
> We cannot do this as easily as SIP could, but got stuck with the idea that 
> we have to use the same URI scheme for the different transports.

As the problem described, the upper layer protocol (application layer, http 
or DNS) generally adopts
the lower layer protcoal(transport layer, TCP or UDP) by default or by 
manually configuration
to bind the selected protocols when deliver messages.

Could the upper layer protocol to define an explicit attribute to indicatie 
a selected lower layer protocol
when there are some lower layer protocols to choose?
It is expected that CoAP will be tranferred over UDP, TCP, SMS, or WS.
So, for CoAP protocol and the stacks, besides defining a URL sheme to 
indicate a selected transport protocol,
is it required or possible to define some CoAP facility, such as a CoAP 
option, to inform this indication?

Regards,

Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications
-----原始邮件----- 
From: Carsten Bormann
Sent: Saturday, June 17, 2017 5:25 AM
To: Kovatsch Matthias
Cc: [email-masked]
Subject: Re: [core] Editors' draft of changes to 
draft-ietf-core-coap-tcp-tls-08 after IESG input

On Jun 16, 2017, at 22:49, Kovatsch Matthias <[email-masked]> wrote:
>
> Hi all
>
> To me it feels, we need a special session for this during IETF 99. It is 
> really hard to follow the arguments in the e-mails, as there are so many 
> unspoken assumptions, solutions-in-mind, and misunderstandings. I would 
> guess, I am not the only one who cannot get a clear picture of the 
> (assumed) problem, implications, and possible solutions.
>
> To me, it defines the syntax and semantics of the rest of the URI. 
> Important semantics would be if the port is a UDP or a TCP port.
>
> To my understanding in particular SPDY and QUIC are solved by out-of-band 
> info patched into the browser (~Chrome knew what gmail.com speaks…~).
>
> All CoAP endpoints are expected to implement all transport and the pick of 
> transport is just because of the middlebox baggage?
> It is just a hint even when the publisher of a link knows for sure what 
> transports are implemented in the origin server?
> …
>

Right.

I believe we had the best possible solution for this “Gemengelage” 
(untranslatable German word for a situation where a number of unrelated 
issues collide and create something utterly complicated to resolve) in -07.

The IESG has a number of people who have the scars from SIP, which ran into 
a superficially similar, but actually mostly unrelated issue and resolved it 
by attaching a transport hint to an otherwise identical URI.  We cannot do 
this as easily as SIP could, but got stuck with the idea that we have to use 
the same URI scheme for the different transports.

http:// and https:// have the same problem, but
1 — it was resolved that the resources under these two schemes are 
unrelated,
2 — people got used to the pain caused by this.

(We are mirroring this with coap:// and coaps://, and I don’t think this is 
controversial — it really does make a semantic difference whether there are 
transport security expectations bound to the resolution of that URI or not.)

With respect to the UDP/TCP/WS decision, we tried to do (1) in -07, but did 
not have (2), obviously.
(I believe (1) is not so bright for UDP coap vs. TCP coap, so if (1) doesn’t 
help getting acceptance then we shouldn’t do it.)

The consensus document governing registration of URI schemes is RFC 7595.  I 
believe we were in full compliance with that with -07.  I don’t want to run 
process arguments before we have completed the technical discussion, but I 
actually believe e.g. section 3.3 of that document is less clearly satisfied 
by -09 than it was by -07.  More importantly than those process issues, my 
problem is that the issues the IESG members have in mind appear to be 
undocumented, so I can’t learn about them from a document that exposes them 
in a detailed manner.

Coap-tcp of course also was done in the knowledge that there are other 
transports waiting, such as webrtc-dc, SMS or even slipmux.  It seems 
unlikely these can be done with a URI-Scheme that is common with the 
IP-address based ones.

We cannot really learn much from the way HTTP solves its transport vagaries 
because those solutions are based on the ability to put a lot of complexity 
into implementations.  For HTTP, the URI has a much more user-visible role, 
and it is likely appropriate to incur this complexity to keep up the fiction 
that there is only one HTTP.  CoAP is meant to be direct and to the point, 
without relying on tons of pre-configuration, learning, or indirection, so 
any happy eyeball style approaches are grossly suboptimal.
(They may still be necessary in certain not so nice cases; cf. the work on 
Thin ICE.)

Given that URI-Schemes are a dime a dozen (with provisional registrations 
being easy), I’m not sure that implementers (or downstream SDOs) won’t go 
the way of registering (or even squatting on) their own transport-specific 
URI-Schemes to return to sanity.

Having a meeting about the URI-Scheme issue might indeed be the only way 
forward remaining.
It is also a slow way forward.

Grüße, Carsten

[email-masked]

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 17 Jun 2017 14:32:13 +0200

Hi Bill,

> On Jun 17, 2017, at 12:07, Bill Silverajan <[email-masked]> wrote:
> 
> Hi,
> 
> In discouraging the use of several URI schemes for CoAP, one review recommended a series of steps, in which CoAP over UDP is MTI: Always try UDP first, and if no response is forthcoming, to then resort to TCP. Port 80/443 would always default to CoAP over ws or wss without needing to engage UDP initially. Obviously this has repercussions regarding protocol and application logic.

Right.  It also does not work for one of the main applications of CoAP-TCP: traversal of NATs with short UDP binding lifetimes.  The probe will always work through such a NAT, but then the observation relationships won’t, because the UDP binding is gone by the time the notification needs to be transferred.

(Of course, a server can work around this issue by providing a URI with an IP address that listens on TCP only, so the UDP probe fails.  This likely outcome is wrong on so many levels…)

[…]

> Conversely, it must also be recognised that right now, some mechanisms are bound to the "coap" and "coaps" URI schemes, such as using ".well-known/". Minting new CoAP URI schemes would also require extending this to support them.

Not sure I get this point.  We did add well-known support for the new URI schemes in -07.

Grüße, Carsten

---

From: Dave Thaler <[email-masked]>
Date: Sat, 17 Jun 2017 19:49:37 +0000

Agree with Carsten.  Also, Adam Roach pointed out that some protocols solve the port number 
discovery problem by using SRV record lookups.   So I can see a couple possible ways forward
that could work, with different tradeoffs:

1) Use separate URI schemes, as draft -07 did, and simply accept the fact that two URIs 
    (e.g., coap: and coap+tcp: URIs) might refer to the same resource.  Indeed RFC 3986 section 6.1
     explicitly discusses this point as allowed:
	>   Even though it is possible to determine that two URIs are equivalent,
	>   URI comparison is not sufficient to determine whether two URIs
	>   identify different resources.  For example, an owner of two different
	>   domain names could decide to serve the same resource from both,
	>   resulting in two different URIs.  Therefore, comparison methods are
	>   designed to minimize false negatives while strictly avoiding false
	>   positives.

2) Specify that the port number in a coap URI, if present, is specifically a UDP port number.
     Port numbers for any other transports must be resolved using SRV record lookups,
     and the choice of transport protocol must be done by some algorithm by which the 
     client can try various ones until one works.   The downside is extra complexity in the
     client, and extra traffic on the network (both of which might be significant downsides
     in a constrained network or a constrained client).

3) Specify a mechanism whereby lower-layer identifiers (e.g., transport specific URIs like the 
    wss: URI shown in the coap-tcp draft -09) can be resolved for a given coap URI.  E.g., via a
    resource directory or similar functionality built into a server.   The downside is extra
    complexity in both clients and servers, and extra specification work for the WG that the
    coap-tcp draft would be blocked on before it would be usable.  This also requires a way
    to discovery TCP endpoint information either by defining a URI format or by making the
    discovery mechanism be capable of passing something other than URIs.

Obviously I'm in favor of approach #1 (which is also the approach OCF already took for its
standard), but any of the above would be possible.  Maybe there's other variations too.
But I think we have to pick one before coap-tcp is usable.

Also to Carsten's point about the IETF's issues with #1 not being in any document, I agree.
As the editor of RFC 7595, I am willing to co-edit a (not coap-specific) document on this general
topic to ensure it's fair and applicable to a wide variety of scenarios including our constrained
node/network scenarios.

Dave

> Sent: Saturday, June 17, 2017 5:32 AM
> To: Bill Silverajan <[email-masked]>
> Cc: [email-masked]
> >>> All CoAP endpoints are expected to implement all transport and the pick
> of transport is just because of the middlebox baggage?
> >
> UDP first, and if no response is forthcoming, to then resort to TCP. Port
> 80/443 would always default to CoAP over ws or wss without needing to
> engage UDP initially. Obviously this has repercussions regarding protocol and
> application logic.
> 
> Right.  It also does not work for one of the main applications of CoAP-TCP:
> traversal of NATs with short UDP binding lifetimes.  The probe will always
> work through such a NAT, but then the observation relationships won’t,
> because the UDP binding is gone by the time the notification needs to be
> transferred.
> 
> (Of course, a server can work around this issue by providing a URI with an IP
> address that listens on TCP only, so the UDP probe fails.  This likely outcome
> is wrong on so many levels…)
> 
> […]
> 
> are bound to the "coap" and "coaps" URI schemes, such as using ".well-
> known/". Minting new CoAP URI schemes would also require extending this
> to support them.
> 
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i
> etf.org%2Fmailman%2Flistinfo%2Fcore&data=02%7C01%7Cdthaler%40micro
> soft.com%7C1ad8529c19f343d5017908d4b57ce883%7C72f988bf86f141af91ab
> 2d7cd011db47%7C1%7C0%7C636332995469085604&sdata=6rpivhUTBq5mJ2C
> biutiISXwkLW3g9FLQfboOq5zj5g%3D&reserved=0

---

From: Bill Silverajan <[email-masked]>
Date: Sat, 17 Jun 2017 23:06:55 +0300

Hi Carsten,

> (Of course, a server can work around this issue by providing a URI with an IP address that listens on TCP only, so the UDP probe fails.  This likely outcome is wrong on so many levels…)
As a sort of last-resort measure, I can envisage working out a 
server-initiated protocol negotiation mechanism requiring the client to 
switch transports, or to a lesser extent, presenting a preference order 
for the alternate transport that should be subsequently used.
> Not sure I get this point.  We did add well-known support for the new URI schemes in -07.
Yes, -07 did support it. My (fairly trivial) point was aimed at possible 
provisional registrations made by implementers for convenience.

Regards,
Bill