CoRE @ IETF95, Minutes Draft 0.1 Chairs: * Andrew Mcgregor * Carsten Bormann Thanks to the notetakers! * Ari Keränen * Jaime Jimenez * Matthias Kovatsch # Summary CoRE met Tuesday and Friday. On Tuesday: * Andrew indicated that he plans to step down as a WG chair and that the ADs are looking for a replacement. * As periodically, the AD is changing; this time from a graybeard (Barry) to a blackbeard (Alexey). * The chairs apologize for the infrequently updated milestones; fixing them is up next. * draft-ietf-core-block–19 is in IESG Evaluation, telechat date is 2016–04–21. * heads-up for new individual drafts: draft-kivinen-802-15-ie and draft-bormann-6lo-coap-802-15-ie. * CoAP over TCP received extensive discussion. Results (all to be confirmed on the mailing list): * #396: We revert the decision in Yokohama and go with alternative L3. Procedurally, the pain of this reversal is balanced by the reduced pain of not having to convince OCF to change their specification. Technically, L3 is more open to evolving ideas about message sizes. In any case, there is no intent to modify or revoke section 4.6 of RFC 7252 at this time. * We will need to examine the various proposals to add signaling to the TCP connection (settings, ping/pong, release/abort). Signaling messages (7.xx) is one possible mechanism for doing that. * #387 (ALPN): We really need to make a decision here. * Websockets: For merging the websockets draft into the TCP/TLS WG document (with the websockets specific parts going to an appendix), the authors of both drafts will discuss the merge. * Multi-hop Security: Initial discussion of draft-hartke-core-e2e-security-reqs. * It is more well-defined what is being protected in a request-response that spans a proxy than with a pub-sub broker. * The current set of scenarios does not include the case that security services are being performed by the intermediary. Many such scenarios are conceivable; which ones have serious use cases? * Multicast (or, more generally, group communication) is not yet being considered. * Data Formats: WG to adopt SenML (to be confirmed on the mailing list). After a bit of Brownian motion, the WG is now happy with the way the data is formatted in -06 (base record with data, zero or more records with more data). The addition of links in the data is to be done by registering a senml label in core-links-json ("reversing the arrow of dependency"). On Friday: * Handoff of the Baton: Barry Leiba gave his farewall as CoRE's responsible AD; great applause of the WG. * For the resource directory (RD) and related documents, we are aiming at WGLC before July 1st so we can discuss the outcome in Berlin and ship soon after. There are quite a few things to do, many of which are on the editorial level (see slides, but also Akbar's "advanced RD" document; we will not try to put mirror server/pubsub support in the RD document now, though). The issues will managed on the WG tracker. * There was in-room consensus to adopt draft-vanderstok-core-etch-00 as a WG document. This is needed to keep PATCH in the RD, but also for the management work (below). To be verified on the mailing list. * core-links-json also is in the same cluster (WGLC before July 1st). Hannes would like to see the RFC7390 parts separated out from the RFC6690 part that we are about for RD. The TODOs in the document need to be ticked off/trackerized. * There will be a 2nd WGLC for core-http-mapping after the comments are incorporated (-10). * core-interfaces may have been adopted too early and requires a major overhaul, separating out the more speculative material (some of which is T2TRG material). It should be made very clear that this describes one way of using CoAP (which has indeed been picked up in various ways by other SDOs), not the prescribed way. Matthias will help Michael to do the separation. * The work on management of constrained devices has converged ("COMI with COOL"). The yang-cbor draft is ready for an adoption call, but not enough people had read it yet to do an in-room adoption check. The other drafts will undergo merger/restructuring work based on this week's discussions and should then become ready for adoption. This work is explicitly covered by our charter (which also calls out LWM2M management as a related approach that we will continue to support as needed), and we will implicate NETMOD/NETCONF into every step we are taking. The author team invites the WG to its bi-weekly phone meetings (to be announced on core mailing list). * The work on Object Security for COAP (OSCOAP) is progressing nicely. A complete draft can be expected for Berlin. # Detailed notes below. TUESDAY, April 5, 2016 1740–1910 Afternoon Session III Buen Ayre B ART *** core Constrained RESTful Environments WG ## Chairs’ Intro (10) - Agenda bash (Carsten) - no comments - Re-chartering finished: new charter approved yesterday. Formal announcement coming. - Andrew stepping down as co-chair. Looking for new co-chair. - New responsible area director: Alexey Melnikov (now has a beard) - Milestones are in disarray. We have to get on track with them. draft-ietf-core-block status Will be discussed in telechat draft-ietf-core-block–19 2016–04–21 IESG Evaluation - T. Kivinen working on CoAP over 802.15.4 information elements. https://tools.ietf.org/html/draft-kivinen-802-15-ie-00 ## WG documents CoAP over TCP (Hannes) (25) draft-ietf-core-coap-tcp-tls–01 2015–11–19 Objective: Move forward decisions on open issues related drafts draft-bormann-core-block-bert–00 2015–11–27 draft-savolainen-core-coap-websockets–06 2016–03–19 - Issue #396: L1 (16-bit length field) vs L3 (variable length field) - WG picked L1 - Meeting with OCF, who picked L3 - Use case: firmware updates and hence large payload - Question to group: Revisit discussion, should recomend diff protocol (HTTP) or slower firmware update? - Info about size estimations: - RFC7252: stay around 1152 B max (cf. 6LoWPAN) - L1: already 64 KiB max - L3: 4 GiB max - Block: 1 KiB max, even when using CoAP-over-TCP with L1 - BERT extension for Block to use larger blocks (SZX=7 -> use payload size provided) - Should we re-visit L1 decision? Mohit: can't probably ask to use HTTP(/2) for FW updates. Hannes: have implementions of L1/L3. Didn't envision using CoAP in the way used now. Didn't look what would happen with this big sizes. Akbar: We should try to align with OCF; we are still early in the process Alex: With TCP we are not on a low-power wireless environment anymore, so we could go for larger sizes Christian: Why not? (?) Ari: There were no strong arguments either way when originally discussed. Now experience from implementations. Makes sense to follow that. Matthias: We chose L1 because we cannot predict how resource-constrained devices will work together with CoAP devices sending around megabytes. We have no experience with gateways that need to convert between CoAP-over-TCP and CoAP-over-UDP. L1 is the conservative choice to ensure constrained devices can be part of the same ecosystem. At least, we now have a use case for L3. Carsten (as individual): Mechanism and policy different in protocol design. Mistake to code policy into mechanism. IPv6 cheksum mechanism as example. 1kB restriction from CoAP protocol RFC has not been suggested to be changed. (As chair) Who could not live with reverting the decision and go from L1 to L3 (no one). Who could not live with sticking to L1 (no one). - Shim header itself is insufficient -> do we need a signaling protocol? Carsten: Danger that this signling protocol becomes way more complex than CoAP. How about if we add signaling funtionality to CoAP. No need to use the shim layer for that. Hannes: An alternative is to assume always TLS, which can provide most of what is required. Christian G: WebRTC datachannel has already mechanisms. Need to consider other CoAP over foos too. Ekl(?): have implemented CoAP over TCP. Feel need for this kind of mechanis. Especially pings and release. Carsten: way forward is looking at the four items and see if we want to have them. Have not seen other proposal yet. Check items on mailing list. Issue #387 ("ALPN always required" at tracker) has been around long. Need to make decision. - Looking at issue tracker (slide 11) Hannes: When running multiple application on the same port, the multiplexing information is particularly of interest. Carsten: what about websockets (slide 18). Use case: application running on browser and wants to talk to CoAP device. People are doing that. It is an encouragement for reusing software components. WebSocket-specific part could go into an appendix. My proposal: merge the documents. Would make WebSockets WG item in the process. Hannes summarizing: will switch to option L3; signaling: solicit alternatives with signaling message examples. WebSockets: consider merging. # Security (15) (Make some progress on the security requirements part on the Friday agenda while the security people can be here.) Object Security (Göran Selander) draft-hartke-core-e2e-security-reqs–00 2016–03–19 draft-selander-ace-object-security–04 2016–03–21 - We need end-to-end security (that traverses intermediaries) - DTLS needs to terminate at proxies (which allow for scalability), so they can perform required operations on the messages - Application level (object) security can help by only protecting the right parts of the messages Akbar: if forward proxy; some sort of security association needed between client and proxy? Göran: no need for security association but client asks proxy to perform function. Thomas F: end-to-end SA exists and mechanism for that? Göran: yes, worked at ACE Thomas: are there solutions that would work with CoAP only? Like certificate or RPK. Proposed Connect method for CoAP for that long time ago. Göran: let's have that discussion off-line Carsten: DTLS over CoAP would be simplest way. Carsten: Scope picture showing two things. First, need to protect CoAP exchange and semantics preserved even if FW proxy is attacker. Not clear if same situation in lower part (with broker) since there are two CoAP exchanges. Need to understand semantics of interactions with the broker. More pictures of this kind probably needed. Jim Schaad: Understand the semantics pretty well. Just store and forward. Göran: doing pub/sub in two ways: CoAP semantics directly where publisher is server. And pub/sub with client. Requirements very similar. And yes, missing scenarios; input welcome. - Methodology relevant when coming up with scenarios - 5 scenarios so far (abstract message exchanges) - CoAP not designed for this end-to-end security (with proxies etc). Jim S: Are there also multicast cases in your scenarios? Göran: No, no multicast considered yet. Planning to add HTTP and reverse proxy cases. We will need a good understanding of the senarios. - This will require multiple solutions, but not one per scenario. - More discussion on Friday Carsten: important to think about security requirements in different scenarios with proxies and pub/sub servers. Some examples in the mailing list archives. Good to dig them and rephrase for this. Hannes: would like to see not abstract boxes but specific scenarios people are working on. Experience from OAauth: easy on paper. Practical problems with intermediaries and platforms for implementations. Seems we are guessing here. Jim S: what level of detail wanted for real-world cases? Actual or probable cases? Hannes: want to hear what people are really working on. Not probable cases. Would be nice to have those people explaining. Göran: People are working with DTLS, but they always trust the proxy. What to you mean by "working with it"? Hannes: specific proxy use cases and people work with proxies. We have cloud based service that proxies to other web services. HTTP to browsers and mobile handsets. This stuff does not seem to be applicable. The home proxy people for instance; unfortunately not here. Jim: ? Hannes: I don't know where these use cases came from. There were bad examples in the past, e.g., smart grid. Ari: The document is abstract, yes. But they very easily apply to many real uses cases, for instance the one you mentioned earlier. Hannes: Some people want to do big data analysis; they have other interests. Göran: For the CoAP-HTTP proxy aggregation is not neccessary, it is sometimes just a mapping. That's the setting we are addressing here. Hannes: There were no implementations by the authors of the HTTP mapping either. There is a lack of getting things done. Göran: What is the first step? Carsten: Need to take it offline, to stick to th agenda ## Data formats (has to be first meeting because of a conflict) SenML (20) draft-jennings-core-senml–06 2016–04–04 Objective: Review readiness; accelerate now? - Progress in Yokohama, many version bumps - Old: Base Values can appear in any SenML Record. Problem: Need to be reading SenML Records sequentially. - Tried to simplify: Ruled out some proposals and decided for mixed records: first may have base values and regular values. Ari: Anyone against this? -> no comments - No links in SenML, but defined in core-links-json. Uses a base value and escaping if complex structure needed. Ari: Michael had use cases for links. Not there. Any comments? Alex: CBOR tags? Ari: Yes, this is only JSON. In CBOR we use negative and unsigned to distinguish base and normal values. Alex: There is extra CBOR funcionality. Might it be useful, since it allows to go much further with the encoding, e.g., for compression? Ari: We do have CBOR tags for the labels defined for JSON. - Privacy issures with long-term stable unique identifiers have been addressed. Cullen: We had MAC addresses and other critical IDs and removed them. But for management we really need these stable identifiers. What should we do? Carsten: There is an example in the slides (urn) Cullen: Management wants that a replugged sensor has the same identifier. Hannes: Reason for discussion is document predates the time when we had actual use cases. We should look at specific deployments for the different scenarios (e.g. beacons, industrial cases,...). Ari: We are still trying to solve the issue. We should check in which cases we really need IDs and in which we do not. We need more thinking. - Other updates, e.g., CDDL, label registry, ... Carsten: Next step would be to go for WG adoption. Anyone against? (charter allows us now) Some shows of hands for (counted about 10), none against Carsten: links-json now pointing to SenML, because links-json depends on RD, which will not be shipped soon. Anyone a problem with this? (none) # Friday FRIDAY, April 8, 2016 1000–1200 Morning Session I Buen Ayre B ART *** core Constrained RESTful Environments WG Intro (5) WG documents (Overflow from Tuesday on RD) - Handoff of the Baton (beer for Barry) CoRE Resource Directory (20) draft-ietf-core-resource-directory–07 2016–03–21 Objective: Review completion status related drafts draft-rahman-core-advanced-rd-features–02 2016–03–18 draft-ietf-core-links-json–04 2015–11–02 draft-vanderstok-core-etch–00 2016–03–21 - Becoming the de facto "resource discovery" mechanism (e.g. OCF, OMA, W3C...) Tim Carry: What is RD doing on OMA LWM2M. RD doesn't seem to have been in OMA 1.0. Is it in 1.1? Michael: Devices register on the LWM2M Server which is using the only the registration interface of the RD. Hannes: V1 didn't have a ready RD, it uses the concept but does not refer to it. V1.1 has a cleaner representation, hopefully the current text (in OMA spec) will refer to the IETF RD document. There is also text copied from the DTLS Profile, because it was not finalized back then. Going forward it should be references. Michael: Agreed. - Updates: resource catalogs, added ct to hyperlink example, require support for app/lnk format. - Pending updates due to new questions coming up in implementations. Hannes: Long list of items. To be added to issue tracker. Would like to see WGLC the latest by Berlin IETF (96). Michael: Yes, want to update issue tracker. Most of it is clean-up. Hannes: Can you add the items to the tracker today? And make a proposal and clarify; not enough details in the slide. Need to trigger the discussion ASAP. Michael: Anyone else is welcomed to contribute too. I will go ahead and do these changes, it's going to be around 5 new issues on the tracker. - Roadmap: Have updated draft by end of April. Late binding decission to include PATCH. Schedule for WG Last Call? Carsten: We need a WGLC with the results ready to be used in Berlin Michael: Yes Hannes: Status of PATCH? Michael: Don't know Carsten: Observation is that OMA used PUT to do PATCH. How to use PATCH is clear, but can we ship it in the same cluster as RD? draft-vanderstok-core-etch-00 Peter vDS: goes to explain PATCH. - Complex HTTP URI's are a problem. POST allows for sending paramenters on payload. FETCH mostly equivalent to HTTP SEARCH - CoAP PATCH similar to HTTP PATCH iPATCH for indempotent operations - Questions? Alex: We really need PATCH. Peter vDS: Yes, I had several people asking the same. HUM1: YES for ready for adoption? (Show of hands=12 YES + 4 jabber) HUM2: Should it not (NONE) Quiet humm for adoptions Unclear, switch to show of hands: About 12 hands for adoptions None against Jabber room: 4 humms for adoption. It's up Consensus for taking adoption to the list Core-Links-JSON draft-bormann-core-links-json-02 Carsten: 1. Do we want to provide a way for putting extended information into the links-json document that goes beyond what you could put into a plain-text link-format document? Michael: Links need to be flattable and ?; appears to be doable Carsten: Add issue to issue tracker Carsten: 2. Is it actually a good idea to do 7390 in the same document as 6690? Hannes: I would separate it or work on 7390 and incorporate. From maturity point of view the stuff on 6690 is more advanced than group communication. Who is in charge of moving forward the doc. Carsten: there are several authors. Hannes: Someone has to lead. This should also be finish very soon. Carsten: I am going to make sure it gets done. All of these documents need to be last call before July 1st. Carsten: Add TBDs to issue tracker Advanced RD Features draft-rahman-core-advanced-rd-features-02 - Proposed Features Explicit HTTP interfaces. Example, HTTP has HTTP Link Header, is it used in CoAP? Hannes: This would be useful feedback for the RD document. RD says it works for CoAP and HTTP, and I did not see any indications it wouldn't. Need feedback where it might be confusing. Akbar: RD was updated in the meantime. More a problem in the CoRE Link Format: Will it work in the HTTP header. Michael: I agree with the use of RFC6690 proposed (?) Hannes: Is this a dependency to be waited on? Darshak: Proposed for 5988 HTTPbis it proposes the creation of a registry with link attributes. - Mirror Server. Assumes new type of RD that also stores representations (for sleepy nodes). Peter vDS: We will incorporate parts of the PubSub draft. Hannes: There is no roadmap on Pubsub/mirror Server/ etc. It is more important to finish RD first. Akbar: There is progress as OMA adopted some of it. Hannes: No progress for our WG (not an WG item etc.) Akbar no objection to finishing RD first - RD Redirection. - URI Ranking. (details will follow on the list) - Privacy Model Guidance seems insufficient. Hannes: Rising awareness is impotant. What would be sufficient towards the registration. Akbar: Use case Hospital devices with multiple users, departments. Who has access? Discussion on the list. Matthias: These are valid use cases but not something to be solved on RD, it is application specific. Question should be if there is something missing on RD and other building blocks done in the IETF. This should be formulated as concrete requirements for the building blocks (e.g., is something missing in RD?). Akbar: Privacy model should be discussed on RD. Carsten: We are ambitious with the WGLC but this is important. Question is if various parties using RD have the possibility to even structure the RD to support policies. Michael: Yes we should have it for discussion but unlinkely before LC. Akbar: Will send to mailing list. Carsten: Decision to be validated on mailing list. HTTP Mapping (15) Thomas Fossati (Akbar is the backup) draft-ietf-core-http-mapping–08 2016–03–19 Objective: Review updates to address the WGLC comments from Klaus Hartke Hannes: IESG provided comments? Carsten: No, finished WGLC, not IESG processing. - Included Klaus's comments Clarify that case is mostly Reverse proxy - Next Steps: Q1: Change focus to Reverse proxy? Q2: IANA contact for registration. New link format "hct". Hannes: Focusing on reverse proxy would be more clear. Distinction between proxies is confusing. Matthias: Discovery of Reverse Proxy to identify it as such is unnecesary. The point of the Reverse Proxy is that it looks like the origin server in the first place. Carsten: Let's take this one to the list. Akbar: Do we register attributes? Carsten: No registry to Link format attributes. Might be good to think about it as it is useful and comes often. Michael: There is a resource type "registry" on IANA. Carsten: We were talking about attribute registry, not "rt" and "if" values. Michael: I assumed it'd be the same reg. Agreed. Carsten: Wait for discussion and do WGLC. Reusable Interface Definitions for Constrained RESTful Environments (15) draft-ietf-core-interfaces–04 2015–10–19 Objective: Review completion status Carsten: Cut down time to a few minutes. Hannes: This document is in a big mess and we should spend more time on it. - CoRE Interfaces has too many things on it. OCF is using it. Suggest to do a split document. Also to clean it up. Hannes: There was the plan to split up in multiple chunks. Adoption was too quick before doc was ready. Many things have changed like Matthias' preso on HATEOAS. Not many people have read it. Matthias: Work on T2TRG is research oriented work. The solutions there do not require to be added now. We might be adding too many things to Core Interfaces just because they ar "nice". Darshak: Core Interfaces is used by OCF but not in the way CoRE Interfaces describes it. Right now focuses on the link format. Michael: Agreed. ???. The important thing is the "if" link attribute. Hannes: OCF uses only interfaces and collections? Darshak: OCF does not use the notion of function sets. It also has notions that are not part of the draft (mutiple interfaces support). Hannes: Should we replace some of the text from OCF on the Core Interfaces. Darshak: That'd be a bad idea. Michael: W3C is using Collections as well. Having a collection type makes sense. Matthias: This document should not give the impression that this is the way CoAP is used. CoRE came with the notion for this mechanisms. I never figured out how "if" is useful and people use it in diff way. They should explained better, we should STOP to add new stuff (i.e., remove all experimental issues). Carsten: can volunteer Matthias and Michael to work on those? Matthias: Yes I will, Klaus should also cause he has good input. Hannes: Show of hands to split Observe attributes? ... Matthias: This is use in OMA LWM2M. This is something I'd consider to have it there. Hannes: It is not a bad thing but it has a different style, therefore split. Matthias: It is a small thing used by LWM2M, no point on separating (?) Michael: Overlap with bindings idea which is an experimental concept too. Carsten: Suggested people (Michael, Matthias, Klaus) should add an issue that describes the way forward. Christian Amsüss (Jabber): will (one of) the split documents still contain batches / other collections? i've found them handy in atomic access. Michael: Yes. Idea is to have "collections" and "attributes" in two different drafts. Management (45) Discussion leaders: Andy Bierman Peter van der Stok COMI and COOL draft-vanderstok-core-comi–09 2016–03–07 draft-veillette-core-yang-cbor-mapping–00 2016–03–11 draft-bierman-core-yang-hash–00 2016–02–10 draft-turner-core-cool-problem-statement–00 2016–03–11 draft-veillette-core-cool–01 2016–03–11 draft-somaraju-core-sid–00 2016–03–11 related drafts draft-pelov-core-cosol–01 2016–02–17 - NETCONF, NETMOD, YANG, RESTCONF history. Hannes: Which of the existing modules can actully be used for the IoT? Alex: TCP + XML + long identifiers are problematic, so there are not IoT modules; chicken egg problem. Hannes: NETCONF has issues and mapping to CBOR or others. It is not so useful, not so much to reuse for OCF, OMA. Alex: Continue preso, answer coming. - CoMI: Several iterations. YANG has 5 byte identifiers, requires registry. - CoOL - Now have a registry - New from IETF94:YANG-CBOR mapping draft, problem statement draft, hashing draft, function set draft. - Future Work: merging and consolidating (cool, comi, yang-hash). CBOR Mapping completed (draft-veillette-core-yang-cbor-mapping-00). Hannes: Where can I find an example of objects/modules and the message exchange. Would lik to compare to LWM2M. Alex: This is the next step, since we now have everything in place. Michel: we have now github registry. Peter working on YANG module. 6lo MIBs could be converted to YANG. There's bunch we're currently using. Hannes: So examples on github? Michel & Alex: yes, on github. Alex: Not having YANG there would be bad strategy. Tim Carry: Concerned about the usefullness. Do I need to register every object? Andy Bierman: YANG-CBOR mapping contains examples. CoAP is suposed to work for sontrained networks and nodes. Networks have (constrained) routers and we want to manage them with the same tools. Hannes: We need examples that the work is actually useful.On LWM2M the complexity was smaller thus we didn't see the ammount of requirements found by this work (CoMI+Cool). Tim: Worried of the message we're sending to broader community. Do we need all this? Is it valid and important use case we have here. Alex: Two use cases 6tish will use CoMI and Cool for the >netwmanagement [Wifi-problems; some comments missing] Yong Geuun: Submitted paper on IAB workshop working on similar stuff. Hannes: They use YANG in a different way though. For Low Power networks we are also working on it in LWM2M. The YANG-CBOR mapping examples could use an scenario to express configuration, access control, adding credentials, etc. Alex: There won't be a single management protocol out there. Hannes: yes you are adding one. Carsten: It is the combination of several decades of work. A lot of the complexity is pushed to compile time. I am relatively happy with this approach and with moving YANG towards constrained devices. Peter vDS: YANG is a development that is ongoing. Andy Biermann: YANG has the advantage that it accepts more complex cases. The stuff that is online is very efficient, specially when handling metadata. - Next steps. IANA registry Open Source Biweekly meetings. Carsten: Who has read the drafts raise hands? (The authors and a few) Carsten: The most requested work from the outside is this kind of work. We would need to read the work and if there is no major problem we will go for WG adoption. Tim: Why is this in CoRE and not in NETCONF? Carsten: We discussed it and it was a good approach. NETCONF has too much focus on SDN. Tim: To me in NETCONF it would make more sense, as it is a YANG encoding. Hannes: Does the charter cover that type of work? Hannes: LwM2M 1.1 adding support for NB-IoT. Can use stuff with not many changes. Carsten (as ind): important at IETF is to select a way how to do management. Result of 2 decades of work. Can either ignore or get to the problem. Not sure can achieve what aiming here. Nodes have little of the complexity inherent in YANG. Chair hat on: need to finish this some point. Peter vdS: YANG is ongoing development. Thanks to all these tools can do in low-power environment. Andy B: YANG may be overweight to model lightbulb. But if things will be more complex, then might want modelling language up to the task. Putting all in one string doesn't help automation and understanding. CoOL is very efficient on wire. Carsten: work that is most request from outside is CBOR mapping. Will be going for WG adoption pretty soon. Tim: why at CoRE? Carsten: discussed and found out CoRE is good place. People who care about this are in the WG Tim: Both CoRE and NETMOD busy now. NETMOD would be more natural place. Hannes: does the new charter cover this kind of work? No milestones for this work. Carsten: need to work on milestones. Hannes: Would you do a call for adoption on the mailing list? Carsten: Yes. When we adopt YANG-CBOR we will inform the NETMOD group that we are doing that. Hannes: Will you update the milestones? Carsten: yes. ## Security (40) OSCOAP draft-selander-ace-object-security-04 - Restructuring. Fully combined with COSE draft. - Examples added. All options -except the ones needed to be changed by proxy- are encrypted. - Duplicate Options: one instance for the node, one for the proxy - next steps: mailing list, Blockwise, implementations to be open sourced. Akbar: Multicast support? Francesca: Not for this. It is used when the response is bound to a particular request, not for multicast. There is another protocol for that (~OSCON? content...) - Blockwise: Plan to use duplicate options. Two new independent block options, "inner" and "outer". - Comments? Carsten: Nice progress. When could this be ready for WG adoption? Francesca: Next IETF we will include all the new things. Carsten: So complete version for next IETF (96)? Francesca: Yes.