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

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:core-bounces@ietf.org] On Behalf Of Dave Thaler
Sent: Thursday, 15 June 2017 20:08
To: Carsten Bormann <cabo@tzi.org>; Kraus Achim (INST/ECS4) <Achim.Kraus@bosch-si.com>
Cc: core@ietf.org
Subject: Re: [core] Editors' draft of changes to draft-ietf-core-coap-tcp-tls-08 after IESG input

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