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

[Dave Thaler <[e-mail]>]

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

> -----Original Message-----
> From: core [mailto:[e-mail]] On Behalf Of Carsten Bormann
> Sent: Saturday, June 17, 2017 5:32 AM
> To: Bill Silverajan <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [core] Editors' draft of changes to draft-ietf-core-coap-tcp-tls-08
> after IESG input
> 
> Hi Bill,
> 
> > On Jun 17, 2017, at 12:07, Bill Silverajan <[e-mail]> wrote:
> >
> > Hi,
> >
> >>> 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?
> >
> > 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
> 
> _______________________________________________
> core mailing list
> [e-mail]
> 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