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

From: Carsten Bormann <[email-masked]>
Date: Mon, 15 May 2017 16:32:19 +0200

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

---

From: "Kraus Achim (INST/ECS4)" <[email-masked]>
Date: Mon, 15 May 2017 14:52:37 +0000

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

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]>
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

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

---

From: Klaus Hartke <[email-masked]>
Date: Mon, 15 May 2017 17:15:42 +0200

> 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?

This one is even more fun:

    coap://2259499800/path/to/resource

Is this CoAP over UDP or TCP to a server with IP address 134.173.59.24
(there are URI parsers that accept "dotless" IPv4 addresses) or CoAP
over SMS to a server with phone number +225-949-9800?

Klaus

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 15 May 2017 17:44:59 +0200

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]> wrote:
> 
> Hi Carsten,
>

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 15 May 2017 17:45:55 +0200

And the flip answer is "happy bearing balls" (we don't have eyeballs in things)...

Sent from mobile

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 16 May 2017 13:53:26 +0200

> On May 15, 2017, at 17:15, Klaus Hartke <[email-masked]> wrote:
> 

Answer: No.  RFC 3986 says:

   IPv4address   = dec-octet "." dec-octet "." dec-octet "." dec-octet

   dec-octet     = DIGIT                 ; 0-9
                 / %x31-39 DIGIT         ; 10-99
                 / "1" 2DIGIT            ; 100-199
                 / "2" %x30-34 DIGIT     ; 200-249
                 / "25" %x30-35          ; 250-255

> (there are URI parsers that accept "dotless" IPv4 addresses)

That may have been an amusing quirk for a while, but is not supported by the URI standard.  
I hope people don’t start doing in the CoAP space what has been deprecated in the HTTP space for a long time...

> or CoAP over SMS to a server with phone number +225-949-9800?

I don’t think we will be able to address CoAP over SMS with the same Authority (RFC 3986) construct that we use for CoAP over IP-based transports.  The latter all are based on IP addresses and port numbers (even if the port numbers may be for different transport protocols).  But the CoAP over SMS document is not before the IESG at this point in time.  By the way, we are still looking for reviews for the latter (https://tools.ietf.org/html/draft-becker-core-coap-sms-gprs-06) so we can adopt it as a WG document.

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 16 May 2017 15:58:08 +0200

I just pushed a couple more commits, this time addressing some input from the IESG that the ADs downgraded from DISCUSS to COMMENT.

In particular the text I generated on cipher suites needs attention from implementers and TLS experts.
(The gist is that CoAP over WebSockets should use what is available in browsers and secure [JavaScript code may not have a lot of influence on the cipher suites anyway], while CoAP over TLS should use what is available in constrained devices, i.e. the cipher suites recommended in RFC 7925 — even though any back-end usage of CoAP over TLS may want to use RFC 7525 cipher suites instead.)

Please use the links below, which now include the changes for these last two commits.

Grüße, Carsten

> On May 15, 2017, at 16:32, Carsten Bormann <[email-masked]> wrote:
>