[core] CoRE @ IETF106: Summary and Minutes

[Carsten Bormann <[e-mail]>]

We have uploaded draft minutes for the two CoRE meetings at IETF106:

https://datatracker.ietf.org/meeting/106/materials/minutes-106-core

As usual, this starts with a summary of what happened (with fewer technical details), followed by more detailed minutes as collected in Etherpad.

Please send fixes and updates to [e-mail] or to the mailing list, preferably within the next 7 days or at least before you dive into the holidays.

For easier viewing and commenting, the summary part is replicated below.

Grüße, Carsten


# CoRE WG - Summary IETF106

(Constrained RESTful Environments WG, Draft Minutes 0.1)

The core WG held two meetings at IETF 106 in Singapore, both of which are summarized in these minutes.

Videos:
: Wednesday (2019-11-20, 2 h): <https://youtu.be/YIHoiHhz2Ys?t=130>
: Friday (2019-11-22, 1.5 h): <https://youtu.be/OkYDGZz0fGY?t=222>

Slides: <https://datatracker.ietf.org/meeting/106/materials/slides-106-core-consolidated-slides>

Raw minutes:
<https://etherpad.ietf.org/p/notes-ietf-106-core>

Thanks to the note takers Niklas and Ivaylo!

## Working Group Document Status

In RFC-Editor’s Queue:

* draft-ietf-core-multipart-ct-04

In IESG processing:

* draft-ietf-core-hop-limit-07: Alexey explained that the
  "Approved-announcement to be sent::Point Raised - writeup needed"
  status is due to the open question why this cannot be mapped to
  HTTP.  Carsten proposed defining a generic HTTP header field for
  "tunneling" CoAP options, outside this document. (With that, the
  draft has since transitioned to the RFC-Editor's Queue on
  2019-11-26.)

* draft-ietf-core-resource-directory-23: In AD Evaluation, substatus
  "Revised I-D Needed".  As was further discussed in the Friday
  meeting, the main open point is the question whether the reference
  to the much less well-advanced RD-DNS-SD draft needs to be
  normative.  The outcome of the discussion was that the
  resource-directory draft should simply define the small number of
  DNS-SD service types that are needed for resource directory
  discovery, with details to be taken to the list.

* draft-ietf-core-senml-more-units-03: Status "Waiting for Writeup".
  Some need for clarification that the secondary registry SHOULD be
  implemented but the derived units still SHOULD NOT be used, and for
  the designated expert instructions.

  Concerns had been raised about opening up the second registry for
  derived units, making it harder for a SenML application to find out
  whether a unit encountered was actually of interest to it.
  Discussion in the first session resulted in the tentative proposal
  to mark secondary units with an asterisk (as in "*km/h", as opposed
  to unmarked "m/s").  Further discussion in the second session made
  clear that while this makes the use of secondary units stand out, it
  does not really improve the situation of SenML applications that
  want to quickly discard measurements for units they do not care
  about, unless they track the contents of the two registries, which
  would make the asterisks redundant.  There also was some feedback
  the asterisks would make the adoption of the SenML units registry by
  other SDOs more difficult.  The in-room consensus not to go for the
  asterisks, but to include more explanatory text about implementation
  strategies, needs to confirmed on the mailing list.  Also, it was
  brought up that proactively registering remaining SI-based units in
  table 1 now might improve the stability of that table further on;
  this should be done in an independent effort (exercising the
  registry).

* draft-ietf-core-senml-etch-05: IESG Evaluation::Revised I-D Needed.
  Latest changes are on github, a few comments still to be addressed.
  In particular, there may be a need to select for units.  Also, a
  decision needs to be made what happens if the selector in a patch
  record matches multiple records (proposal: error); need to double
  check idempotency, too.

In Post-WGLC processing:

* draft-ietf-core-stateless-03: Authors to update draft from WGLC
  input.  (Done as of 2019-12-06 in draft-ietf-core-stateless-04.)
* draft-ietf-core-echo-request-tag-08: Update made the deadline, now
  needs write-up from shepherd.

Almost at WGLC:

* draft-ietf-core-dev-urn-03: (expired), an ABNF problem needs to be
  fixed and the draft resubmitted before it can go directly into WG
  last-call.

In WG adoption call:

* draft-bormann-core-corr-clar-00: WG adoption call finished with only
  one item of feedback; in-room consensus was good before that; what
  should we do now?

* draft-jarvinen-core-fasor-02: (adoption call runs until 2019-12-03)

## CoRECONF cluster

* draft-ietf-core-yang-cbor-11, draft-ietf-core-yang-library-00,
  draft-ietf-core-comi-08, draft-ietf-core-sid-07: Now ready for WGLC,
  to be sent to CoRE as well as netconf/netmod (with the discussion to
  happen on CoRE).  (One comment on the numeric range of SIDs still to
  be taken care of.)

## Group communication cluster

* draft-ietf-core-oscore-groupcomm-06: Ongoing.  Moving to COSE-bis
  registries, discussing countersignature algorithms, details on key
  rollover.  After this round, might be ready for WGLC; previous
  reviewers please vouch for that.  Might need 7390bis (below) as a
  normative reference.

* draft-tiloca-core-oscore-discovery-04: Reviewer volunteers are asked
  to provide reviews now.  Also: The usual discussion of needing a
  registry for link target attributes (which is now possible according
  to the updated RFC 8288) ensued; Klaus might have a draft soon.

* draft-tiloca-core-observe-multicast-notifications-01: New work first
  presented in Montreal; was revised with a simpler approach, which is
  could be summarized as the server redirecting a client to a
  multicast group by supplying a phantom request for that; this allows
  the server to choose a group and a token.  In-room support, but
  probably needs more work, e.g., in congestion control.  Need more
  reviewers now to make progress on this as a WG.

* draft-dijk-core-groupcomm-bis-02: intended normative successor of
  (and obsoleting) RFC 7390 (dropping the experimental RESTful
  protocol that has not been picked up), with some initial reviews
  already addressed.  In-room consensus to adopt as a WG document; to
  be confirmed on the mailing list.  Then, before WGLC, we should
  ascertain implementation support for the whole breadth of the draft.

## SenML cluster

(See also documents in IESG, above.)

* draft-ietf-core-senml-data-ct-01: updated with feedback from
  IETF105, still grappling with potential conflicts between "ct" and
  "ct_".

* draft-keranen-core-senml-base-prefix-00 (ipr #3662): need to look
  closer at use cases and find out how this is not a practical problem
  in LWM2M usage so far.  This draft could be combined with Hannes'
  draft; more analysis is needed.

## CoRE Applications

Klaus led the group through a review of results from Tuesday's side
meeting.  As a result, the following new draft was published already:

* draft-fossati-core-coap-problem-00: The draft uses custom CBOR, but
  the information could also be mapped to CoRAL.  More discussion
  needed.

With respect code point management (numeric identifiers), we might
want to learn from the CoRECONF SID approach for other code point
spaces, too.  Also, some more thinking is needed about error responses
that encode application results; some of this has been added in
RFC 8132 (FETCH/PATCH): 4.09 ("conflict", i.e., application would
reach unwanted state), 4.22 (unprocessable entity); do we want to add
more?

* draft-ietf-core-coral-01, draft-ietf-core-href-01: small update was
  needed so far.

* draft-ietf-core-coap-pubsub-09: Proposal for update was discussed in
  Montreal; feature parity with existing -09 not yet reached.
  draft-hartke-t2trg-coral-pubsub-00 explores how CoRAL might be used
  for enabling publish/subscribe-style communication over CoAP.

Various other T2TRG drafts make use of CoRAL, e.g.,
draft-hartke-t2trg-coral-reef-03 and draft-hartke-t2trg-data-hub-05,
and should be considered in this context.  It also turns out that
draft-tiloca-ace-oscore-gm-admin-01 is very similar in structure to
pubsub.

Carsten presented a proposed timeline for completing CoRAL: stable at
IETF107, implemented and validated at IETF108, WGLC mid-2020.  Klaus
agreed that a lot of validation has already happened.  Also, a
question came up whether there should be a JSON serialization of CoRAL
(there are two proposals for that now — do we need both?).

## Flextime

Francesca brought up the integration of EDHOC
(draft-selander-lake-edhoc-00) and OSCORE (RFC 8613) — can the third
EDHOC message (maybe 20 bytes) be integrated with the first OSCORE
message?  Two proposals have been made (by Mališa and Jim); this needs
discussion.  Francesca brought up a third approach, where both the
EDHOC and the OSCORE messages are included in the payload.  Christian
pointed out that this would be combining two different REST requests,
and Carsten suggested thinking about piggybacking in a more general
sense.

Carsten promised to come up with a schedule for virtual interim WG
meetings that is a bit lighter than the two-week cadence we had before
IETF106.