Minutes interim-2020-core-02: Thu 15:00
minutes-interim-2020-core-02-202004161500-00

# Thursday, April 16, 2020

13:00-14:30 UTC

Note takers: Thomas, Marco, Jaime
Jabber scribe: Jaime, Marco
Queue manager: Jaime, Marco

Numbers in parentheses are minutes of time allocated.

## Intro (5)

## Other (Carsten, Christian) (15):

* draft-bormann-t2trg-rel-impl-01 (10) --- Carsten 13:05

   Objectives:
     * Relation-only vs. add a media-type or two as well?
     * Ready for WGA?

Carsten: diagnostic information about running implementation in a discoverable
way. Thecking that we have enough energy to do this. It's not about returning
the actual information but a link to it, then we need a link relation type. The
document defines this link relation type, not media types (yet), and gives
security considerations (also a bit on DDoS mitigation).

Carsten: Possibly related with the controversial proposal
draft-foudil-securitytxt , intended for reporting vulnerability. Should this
document cover this too? Michael R: great idea, security should be covered, I'm
concerned of HTML (don't want to have the ability to inject JS) Christian: if
CoAP is used for DDoS, this can be used to pin down the implementations that
need upgrading/fixing Christian: fine with all media types, further discussion
can be there Klaus: if I run a libcoap server, I assume the link would point to
the libcoap homepage? does this help with discovering who's responsible for
enabling the amplification attack? Christian: At least it's some information;
expect that a CoAP library's "libcoap/version" would be set to something
application specific in most cases. Klaus: it's interesting and useful to
discuss Jaime: on the security part, it's just a list of emails about the
persons responsible for security. is this something to be provided by companies
and manufacturers of devices? Carsten: it's about implementation information,
not deployment Jaime: for the security part, you have pointers to persons
aware/related to security reporting Carsten: I'd like to separate
implementation info and deployment info (e.g. firewall configuration), for now
I don't think we can go that far with the latter. Carsten to Michael: What is
the relationship between this an MUD? Michael R: even if you can't retrieve,
you may examine and know who built it Michael R: I'd discourage putting *only*
libcoap in there: we want to know who uses the library, not the library itself
Carsten: if we agree that we don't have to go for media types now, I ask for
adoption Jaime: let's not do adoption call right now, move it to the list (mcr
and ca in favor from the Jabber)

(I don't object to libcoap/x.y.z, I just don't want that to be *all* that there
is. I don't mind of libcoap tries to determine ARGV[0], if this was Unix of the
program, or also utsname)

* draft-bormann-core-responses-00 (5) --- Christian 13:21

    Objectives:

    * Warm-up the draft again, in the light of the latest discussions on the
    list about blockwise transfer with unsolicited responses.

Christian: different applications have come up with the need for unsolicited
responses, not strictly triggered by a request. Sometimes these responses are
even considered over multicast for observe notifications. The rationale for the
server is: I send you this responses as if I had if you have sent a request to
me. This involves also having some kind of agreement between client and server
on the Token to use, through out-of-band agrement or new options. I think this
work should continue at this level too, rather than leaving individual your
cases to find their way. It's mostly about responses to (not really happened)
GET and FETCH requests. What should we do about this? Jaime: what is the state?
 Expired right? Christian: yes, since 1 year Carsten: there's an alternative as
a lo-hanging fruit. it's not about defining the protocol, but the model and the
vision here. Happy to re-open the discussion again and improve the document.
Christian: recent mail from DOTS, on particular usage of Block2. This may be a
way to help. Göran: how does this relate to the work on multicast notification?
Carsten: this is part of the discussion. multicast notification relies on
having a token space agreed for that, it's more efficient. We are discussing
contexts and usages that we have in mind, we may end up concluding that the
multicast notification is the most useful to focus on. On the block2, if we
need something working under attack, waht DOTS people need, we may want to
craft something specific for that use case, so probably this cannot be of
general use. Christian: congestion control use, message semantic and token
space are three orthogonal problems all related to this. Carsten: let's
continue on the list and identify the 2-3 use cases -- they won't necessarily
fit in the same solution

## Resource Directory Discussion (Christian) (10) 13:30

* draft-ietf-core-resource-directory-24 (5) -- Christian

     Objectives:

     - Discuss RD GENART comments.

Christian: version -24 comprises points discussed at previous meetings. We got
two reviews, i.e. Secdir and Genart. The simple things are fixed. On DDoS it
should be sufficient to point at recommendations from RFC 7252. Need more sec
cons on simple registration coming from a fake sender. Carsten: from a
procedural pov so we don't create a dependency, it is sufficient to point to
the relevant section in 7252 -- even though it's a bit inefficient, it works.
Christian: need guidance on ramdomly generated endpoint names, e.g. discussing
their size. Jaime: is endpoint name or the security context that is used for
identification? Jaime: also dev URN draft provides a possible solution to the
problem of picking unique endpoint names Christian: need for feedback/guidance
about what can actually be used from a certificate Jim (on Jabber):  I could
provide some of this help Alexey (on Jabber): I can help with X.509 related
stuff [Also MCR] Carsten: I think it's misguided to have anything in this
document talking about certificates. Not happy of having a separate later
document, though maybe there's a reason. The RD is a protocol usable by
different applications, with different authorization requirements. Those
applications should not be defined in this document. We have ACE as a possible
thing to use, but the RD document should be free from this stuff. Jim (on
Jabber): +1 on not making it specific on how to do the authorization policy and
naming in it Christian: personally I'd be happy to get rid of all that, but
there's the question about the authorisation model that we still need to
answer; maybe this is for the application to define Jaime: maybe worth adding a
short paragraph with guidance, e.g. on relevant documents/approaches that can
me considered. Specific things can happen in other documents and groups.
Alexey: need to re-read the current text, I will do in a couple of days Berry:
just following the discussion and waiting for results Jim (on Jabber): one or
two Informational documents on some *ways* might be valuable. Alexey (on
Jabber): Yes, at least one way has to be defined. If the model is "any device
can just be unauthenticated and can modify settings for any other", then it is
not going to work

* draft-amsuess-core-resource-directory-extensions-03 (5)  --- Christian 13:43

    Objectives:

    - Ask which parts WG is interested in.

Christian: the docuemnt describes things that are possible to do with the RD,
as additional features and extensions, also to not slow down the main RD
document, e.g. reverse proxy, lifetime age for RD replication (see slides). 
The doc contains a bunch of suggestions that might be of interest to the
working group. I'd like for people to read it and tell me whether there's
shared interest to do/continue work on one or more topic. Some things/features
are not strictly in this document (outside the bag), e.g. RD-DNS-SD, CoRAL
reef, RD replication, group membership and protocol negotiation. Jaime: some of
the points there will be discussed later in the session.  Complex queries for
the lookup interface would be something that I'd be interested in, but I'm not
sure it is in your doc.   Other topics of interest for me are the multicast
ones.   Maybe something to talk through in the upcoming interim meetings.

## CoRE Applications (Christian, Klaus, Thomas, Jim) (45) 13:50

* IANA registries clarification + link attribute registry (5) --- Klaus

    Objectives:

    - Check status and plan on document about parameter registration.

Klaus: there's no draft about this yet, but the topic was discussed before.
This is about link format and link attributes. Jaime started to collect link
attributes on a HackMD. We don't have any IANA registry for them, but we do for
other things. I plan to write a new draft already discussed at interims, also
to clarify expert review rules for what we have already, but also to create the
registry for the link attributes. No draft text yet due to lack of time. Jaime:
I find this useful, it's a recurring problem. Klaus: yes, useful but not
urgent, that's why going slow. Jaime: this doc status would be? Klaus:
informative Jaime: Any negative opinion on this? Klaus: it was discussed
before, it's really about having a document written to be considered for
adoption Alexey (on Jabber): the direction sounds sensible so far Jaime: so we
can have it for the next IETF Klaus: yes, that'd be nice

* draft-ietf-core-coral, draft-ietf-core-href  (10) --- Klaus 13:55

    Objectives:

    - Updates on coral and href latest versions.

Klaus: since last IETF, 2 revisions of the draft. Lots of clarifications and
details added. It might be useful if people could take a look now.  Need one
more revision before we can do an implementation draft and do interop in an
interim. Klaus: one experience overhead with respect to URIs, especially due to
":" and "/", it's just necessary overhead. Presenting idea for reducing the
overhead. Carsten: I wonder if it is actually worth adding more
encoding/decoding processing than one already has in CBOR; we shouldn't
introduce a third encoding: either stick to CBOR or reuse 7252 option encoding

* draft-xxx-app , draft-hartke-core-apps-08 and draft-schaad-core-reef: (Jim,
Klaus, Christian) (20)  14:08

    Objectives:

    - Discuss ways of representing RD in CoRAL; Christian vs. Jim vs. Klaus

Jim: i'm trying to understand how the structure of these apps should look like.
Klaus would like to have machine-readable descriptions from documents. Two main
approaches may be followed. One is link-based, as HTML does. The second is more
object-oriented, like the equivalent programming. If you go for the link way,
you leverage relations and you know what to do a link, e.g. this is related to
a collection. Thinking in an object way, you more of items with properties that
you can access and delete. Jim: we have three main applications to address now:
1) the pub-sub broker; 2) reef, essentially on how to use the RD; and 3) in the
ACE working group, the Administrator client for the OSCORE Group Manager. There
are lot of common points, that should be defined and documented once, to be
reused. Comments? Preferred ways? Michael Koster: are there other patterns?
Jim: maybe, happy to listen to more ways Michael Koster: how do you want to
deal with the high-level resource represented at the collection? Jaime: good to
have some common guidance, especially to better move towards CoRAL Thomas:
could you elaborate on diffences/similarities, also in terms of open API? Jim:
no, I don't know them well enough Klaus: with open API ???, with hypermedia we
discover anything else from server responses Jim: there's also the reef content
type schema as possible additional point, these things can go on the list
Michael Koster: I agree to come with some common thing Jaime: it will be also
become clear after the interims

* draft-fossati-core-coap-problem-02 (10) --- Thomas 14:19

    - Is this ready for WG adoption?

    Objectives:

    - TBD

Thomas: presented also at a side-meeting in Singapore, now thinking more
broadly of next steps. The goal is to standardize error reporting format for
CoAP. Two different spaces/categories, i.e. global and local. Identify the
error and common fields to support, then per-namespace extensions. Codepoints
can be public or private, renumbering can happen smoothly when/if the API goes
public. Thomas: open issues on localization (default language, language tags),
private-to-public migration plan. One more open point on having the diagnostic
payload under the problem structure. is this as usage pattern common enough and
needed enough? Thomas: do we need to standardize this? ready for adoption?
CoRAL or not CoRAL? Jaime: impressions on who read the draft and would support
adoption? Will bring this on the list --- 4+authors read it and 3 supporting
adoption

## SenML (Carsten) (15)

* draft-bormann-core-senml-versions-01 (7.5) --- Carsten 14:29

    Objectives:

    - Checkpoint and way forward

Carsten: can we start adoption on this?
Jaime: how many have read the draft? --- 2 on webex and 4 on jabber are fine
with adoption Jaime: anyone against adoption? --- none against
 six for adoption
Jaime: will raise call for adoption on the list

* draft-ietf-core-senml-data-ct-01 (7.5) --- Carsten

    Objectives:

    - Solutions for the challenges with mixing mandatory-to-understand
    safe-to-ignore SenML fields.

Not discussed today, will be at interims.

## Flextime (0)

Σ 90