Minutes for CORE at IETF-95
minutes-95-core-1

CoRE @ IETF95, Minutes Draft 0.1

Chairs:

* Andrew Mcgregor <andrewmcgr@google.com>
* Carsten Bormann <cabo@tzi.org>

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.<GITHUB REGISTRY URL??> 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.