# 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