Re: [core] Ben Campbell's Discuss on draft-ietf-core-coap-tcp-tls-08: (with DISCUSS and COMMENT)

[Ben Campbell <[e-mail]>]

> On May 10, 2017, at 1:54 PM, Carsten Bormann <[e-mail]> wrote:
> 
> 
>> On May 10, 2017, at 18:56, Ben Campbell <[e-mail]> wrote:
>> 
>>> 
>>> On May 10, 2017, at 3:20 AM, Carsten Bormann <[e-mail]> wrote:
>>> 
>>> Hi Ben,
>>> 
>>> thank your for your review.
>>> 
>>> Before I start working on it in more detail, let me pick this one DISCUSS out because I think it is the most momentous issue that needs to be discussed:
>>> 
>>>> On May 10, 2017, at 04:27, Ben Campbell <[e-mail]> wrote:
>>>> 
>>>> 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.
>>> 
>>> 
>>> I would rephrase the issue as:
>>> URIs don’t have a good place to put in transport hints.
>>> 
>>> (The definition of a transport hint in a URI would be information that lets me set up specific transports without creating a separate resource each time the values of that transport hint differ.)
>>> 
>>> Note that the main use case for the document at hand is one where the client may not be able to reach the server on the “main” transport (CoAP over UDP), so negotiation/upgrade(*) mechanisms are not solving the problem.
>> 
>> That’s exactly what I mean by “a primary motivation”. As defined, the name of a resource declares the transport. So if I have a “coap” scheme resource that I cannot reach over UDP, I cannot simply switch to TCP and reach that same resource, even if the server supports both UDP and TCP. I suppose the server could treat the two resources as aliases, but the client cannot know that without some out-of-band agreement. (but see next comment)
>> 
>> So is it expected that people have to decide in advance which transport will be use for any given resource? The middlebox-traversal use case would seem to favor approaches where the client gets to decide what transport to use on the fly.
> 
> The way this is set up right now: Yes, the link tells you which transport to use.

I’m confused at how this mechanism addresses the middlebox problem it purports to solve. Is the server expected to know in advance whether all of the clients are behind UDP-eating middleboxes? What if a client moves back and forth from behind such a middlebox? 

And how are the cross-transport proxies described in this draft supposed to work at all, if a resource can only be reached over one transport?

> 
>>> The solutions that people are talking about in our domain are about carrying transport alternatives around together.
>>> E.g., see draft-silverajan-core-coap-protocol-negotiation-05.txt, which provides a way to find out about links from a set of links (the resource directory) while specifying a transport type. [It may be instructive to go through previous versions of this document just to see what we also have tried to do.]
>> 
>> So from an admittedly very quick scan, am I correct to assume that the directory described in that draft could be as “out-of-band” mechanism to declare resource aliases as I mentioned above?
> 
> Well, you go from a directory search to a set of links, not as a way to go from one link to another.
> Other sources of links (hypermedia documents) would also need to provide alternatives whenever they are needed.

But do I understand correctly that with the transport negotiation draft, a server could advertise in such a directory that it was reachable over alternative transports? Wouldn’t that effectively mean that all of it’s resources are aliased for that alternative transport?


> 
>> So why not use that sort of mechanism to advertise the available transports for an authority, and at least allow the transport selection to be completely decoupled from the scheme?
> 
> We weren’t sure whether we wanted to support the trend “to use this URI, you need this ancillary information”.
> It would be nice if we could keep the URL property for our URIs.
> 
>> If people really want to bind transport selection to the resource name, then some such mechanism seems to be a requirement to make the solution in this draft fit for purpose. But the transport-negotiation draft is not yet adopted by CORE. Does it make sense to publish this before that is well on it’s way to ready?
> 
> Generally, we already know how to ship around sets of links.  What the transport-negotiation draft addresses is some additional functionality facilitating the bundling of these links in directories.  So coap-tcp-tls will be useful today for OMA and OCF, but we’d like to have the bundling available for the future.
> 
>>> What we have right now in draft-ietf-core-coap-tcp-tls is what we think is the least ugly way to solve the problem.
>>> The WG is well aware about its problems.
>>> We’d rather have a mechanism like transport hints, but we did not find a solution that would not need to update the web architecture.
>> 
>> At least some other protocols do this with DNS NAPTR records. I realize that may not be realistic for constrained devices (and I gather the protocol-negotiation draft attacks that same problem.) SIP, for example, can specify the transport with a URI parameter, which allows a URI to either specify a transport or to be transport-independent (by leaving off the parameter.)
> 
> Adding a level of indirection is not that useful in the constrained space — URIs are better if they are ready to use (many CoAP applications do not even use DNS).  Shipping around URIs that need additional lookup to use them is not so useful.  Having a multiple-transport URI that is compatible with (caches the same as) any of the single-transport ones would be great.  I’m not sure SIP transport parameters to that.

For SIP URIs, two URIs with explicit transport parameters with different values do not match. But a SIP URI with a transport parameter matches an otherwise identical one with no transport parameter.

Thanks,

Ben.