Subject: [core] CoRE@IETF100: Summary

From: Carsten Bormann <[email-masked]>
Date: Fri, 17 Nov 2017 13:45:59 +0800

Below is the chairs’ summary of what happened in CoRE at IETF100.
Corrections (and additions that keep the summary form) appreciated.
Detailed minutes are being prepared; see link to raw minutes below.

Grüße, Carsten

CoRE WG - Summary IETF100
=========================

* Video Recordings: [Sessopn 1](https://youtu.be/wd_kXam1lIw),
  Session 2 not yet available (?)

* [Slides](https://datatracker.ietf.org/meeting/100/materials/slides-100-core-consolidated-slides/)

* [Raw minutes](https://etherpad.tools.ietf.org/p/notes-ietf-100-core)

## In IESG processing

* draft-ietf-core-coap-tcp-tls is in IESG processing, waiting for
  Mirja's DISCUSS to clear [it is now clear that this will be in
  December after her vacation].  The first interop on Saturday had 2.5
  implementations (libcoap, augustcellars, and coap.me), with a CoAP
  GET performed on /.well-known/core (which exercises a lot of the
  machinery already).  Editorial input from the interop should lead to
  a -11 soon.

* [draft-ietf-core-links-json was not discussed at the meeting.  It is
  in IESG processing, with a few DISCUSSes.  Resolving these was
  delayed as technical questions needed to be addressed, including the
  fact that with RFC 8288 replacing RFC 5988, the ground on which RFC
  6690 was built is shifting a bit (and this draft essentially
  complements RFC 6690).  Some good input was provided by OCF at the
  2017-11-10 OCF/T2TRG meeting, which will now enable these changes to
  be made.  Another WGLC should then follow.]

## WGLC completed

* draft-ietf-core-senml finished WGLC and needs some remaining minor
  updates, to be submitted to IESG in November.

## WGLC ongoing

* draft-ietf-core-cocoa: WGLC has been started after the meeting, also
  soliciting feedback from ICCRG and TCPM.  Dec 14 is the extended
  deadline.

## WGLC impending

* draft-ietf-core-object-security will be ready for WGLC with some
  impending minor fixes in the next version.

* draft-ietf-core-echo-request-tag requires some editorial work
  (restructuring) and could be ready for WGLC after that.

* draft-ietf-core-yang-cbor is stable, but hadn't had enough interop
  testing to enable a WGLC.  Initial testing happened during the
  IETF100 hackathon now.  After another round (and any attendant
  fixes), this will go for WGLC.

* draft-ietf-core-comi and draft-ietf-core-sid need some more
  finishing touches, also probably with fixes coming from the interops
  (bi-weekly meetings to be continued).  There was some discussion
  about cutting the plethora of request types in basic COMI down to
  just FETCH and PATCH (possbly with GET added), to be continued on
  the list.  Completion expected quite soon. Tools to turn delta-SIDs
  and SIDs into human-readable strings would be necessary.

* draft-ietf-core-resource-directory has seen quite a lot of progress
  in the last few months.  Developers now should start updating their
  implementations as interops are coming up.  Work over multiple
  transports (new URI-schemes) still to be done. The increased impetus
  needs to transfer to sister document draft-ietf-core-rd-dns-sd
  now. We expect to pass WGLC by IETF101.

## Working group drafts

* draft-ietf-core-coap-pubsub is sailing along and could get ready for
  WGLC with the next version.  Implementation status to be collected.
  Early adoption of the new 4.29 response code (as requested by
  implementers of the OCF specification) was non-controversial;
  discussion centered around the best way to add response codes (a
  short draft for 4.29 could also include some other new response
  codes, if they are as non-controversial).

* draft-ietf-core-dynlink and draft-ietf-core-interfaces had been in
  limbo for a while.  With a new editor, the remaining editorial
  issues can be fixed.  The documents are best kept separate.

## New Adoptions

* draft-tiloca-core-multicast-oscoap had in-room consensus for
  adoption as a WG document in Prague already; this was newly
  confirmed; validation of the adoption decision on the mailing list
  is next.

* draft-arkko-core-dev-urn had in-room consensus for WG adption, to be
  confirmed on the mailing list.

## New work

* draft-birkholz-yang-push-coap-problemstatement was presented; the WG
  now needs to have a look into how YANG Push and telemetry
  requirements are going to relate to COMI and CoAP Observe.

* draft-vanderstok-ace-coap-est poses a problem that
  draft-hartke-core-pending solves by proposing a new response code.
  Discussion centered around ways that a combination of existing
  response codes could be used instead (5.03 and 2.02), possibly with
  defining semantics for the Retry-After option for the access to a
  Location-* provided with a 2.02 -- this would avoid adding another
  "success" response code.

* draft-hope-bailie-http-payments was presented as a heads-up; several
  participants stressed the relationship of the subject matter to ACE
  work.

* draft-liu-core-coap-delay-attacks proposes a time-based approach to
  the freshness problem solved with a nonce in
  draft-ietf-core-echo-request-tag; there was some good discussion
  that the authors were encouraged to use for a next version.  More
  information about use cases that benefit from time-based freshness
  would be good.

* draft-becker-core-coap-sms-gprs hadn't reached the threshold for WG
  adoption earlier; there is now some renewed interest. Coordination
  with LWM2M work will be needed.

* draft-wang-core-opcua-transmission was presented as a way to map
  OPC/UA on CoAP.  Discussion touched the issue whether OPC should be
  doing this or the IETF.  In any case, the authors were encouraged to
  continue the work, talk to OPC as well and keep IETF involved.

* draft-toutain-core-time-scale was presented, with some discussion on
  whether this should be per-request information or whether there
  could be some state.  Hannes has a slide deck on how LWM2M handles
  sleeping nodes, which pose similar problems.  Laurent promised to
  continue the work.

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 20 Nov 2017 13:55:04 +0100

Hi Carsten, Hi Jaime,

On 11/17/2017 06:45 AM, Carsten Bormann wrote:
>   December after her vacation]. 

It is unfortunate that she went on vacation without clearing her DISCUSS
during the IETF week, which means that we will not be able to finalize
the document before xmas as anticipated during the CORE WG session @
IETF#100.

 The first interop on Saturday had 2.5
>   machinery already).  Editorial input from the interop should lead to

Is there a write-up about the interop testing available? What exactly
was tested? Is the code available as open source, maybe in a dedicated
branch? Could we plan to do another online test in December?

I guess the 2.5 implementations refer to two client & server
implementations plus one client or server implementation? Is that correct?

Ciao
Hannes

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 20 Nov 2017 15:34:24 +0100

On Nov 20, 2017, at 13:55, Hannes Tschofenig <[email-masked]> wrote:
> during the IETF week,

It is, but then ADs are not superhuman and need vacations, too.

> which means that we will not be able to finalize

I’m not sure how that follows, although indeed it will require a bit more attention to achieve this.

The formal steps are:
— Mirja clears her DISCUSS;
— The responsible AD (Alexey) verifies that we handled all the COMMENTs reasonably;
— The document is approved;
— We will ask Alexey to then request expedited processing from the RFC editor.

Step 2 can be parallelized with Step 1.
If all stars align we could have an approved document on, say, Klaasohm, er, Itsenäisyyspäivä (Dec 6).

> was tested?

Mostly framing, connection setup with initial CSM exchange, and a simple GET.

> Is the code available as open source, maybe in a dedicated
> branch?

The code for libcoap is already mainline (branch “develop”); please see https://github.com/obgm/libcoap/pull/113
The code for both augustcellar and coap.me is evolving and AFAIK not yet in a public repo.

> Could we plan to do another online test in December?

Absolutely!

We need to set a date for that — please indicate when it would be convenient for you.
We also should work on testcases (the only one so far was a GET on /.well-known/core).
See https://github.com/cabo/td-coap4 for an example of how to do this.
(We probably don’t need as many test cases as for UDP CoAP, but could simply port some of them over and should at some point have at least one for each feature of CoAP-TCP.)

> implementations plus one client or server implementation? Is that correct?

Both libcoap (C) and augustcellar (.NET) are client and server.
coap.me (Ruby) isn’t quite there yet; we only tested the client code in Singapore.

Grüße, Carsten

---

From: Jaime Jiménez <[email-masked]>
Date: Fri, 24 Nov 2017 09:43:50 +0000

Hi,

If we do an interop for CoAP+TCP we might want to involve those implementing LWM2M as some might support TCP already and would be interested in attending.

Ciao!
- - Jaime Jiménez

Absolutely!

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 24 Nov 2017 10:47:11 +0100

> If we do an interop for CoAP+TCP we might want to involve those implementing LWM2M as some might support TCP already and would be interested in attending.

Right.  I think we should try for one 2-hour slot in CW49; we don’t need to have a lot of people there but of course more implementations gives us more input.  The we should do another one right away, possibly after publicity about what happened in that first slot.

How do we reach LWM2M implementers?
What should our proposed date for CW49 be?

Grüße, Carsten