Discussion:
[core] CoRE@IETF100: Summary
Carsten Bormann
2017-11-17 05:45:59 UTC
Permalink
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

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.
Hannes Tschofenig
2017-11-20 12:55:04 UTC
Permalink
Hi Carsten, Hi Jaime,
Post by Carsten Bormann
## 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].
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
Post by Carsten Bormann
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.
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
Carsten Bormann
2017-11-20 14:34:24 UTC
Permalink
Post by Hannes Tschofenig
Hi Carsten, Hi Jaime,
Post by Carsten Bormann
## 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].
It is unfortunate that she went on vacation without clearing her DISCUSS
during the IETF week,
It is, but then ADs are not superhuman and need vacations, too.
Post by Hannes Tschofenig
which means that we will not be able to finalize
IETF#100.
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).
Post by Hannes Tschofenig
The first interop on Saturday had 2.5
Post by Carsten Bormann
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.
Is there a write-up about the interop testing available? What exactly
was tested?
Mostly framing, connection setup with initial CSM exchange, and a simple GET.
Post by Hannes Tschofenig
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.
Post by Hannes Tschofenig
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.)
Post by Hannes Tschofenig
I guess the 2.5 implementations refer to two client & server
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
Jaime Jiménez
2017-11-24 09:43:50 UTC
Permalink
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


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.)
Carsten Bormann
2017-11-24 09:47:11 UTC
Permalink
Post by Jaime Jiménez
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.
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
Post by Jaime Jiménez
Ciao!
- - Jaime Jiménez
Post by Carsten Bormann
Post by Hannes Tschofenig
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.)
Loading...