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

[Dave Thaler <[e-mail]>]

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:[e-mail]] On Behalf Of Carsten Bormann
Sent: Monday, May 15, 2017 8:45 AM
To: Kraus Achim (INST/ECS4) <[e-mail]>
Cc: [e-mail]
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) <[e-mail]<mailto:[e-mail]>> 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:[e-mail]] On Behalf Of Carsten Bormann
Sent: Montag, 15. Mai 2017 16:32
To: core <[e-mail]<mailto:[e-mail]>>
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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/core
_______________________________________________
core mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/core