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

CoRE @ IETF94, Minutes Draft 0.1

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

Thanks to the notetakers!

# Summary

CoRE met Tuesday and Friday.

On Tuesday:

* We finally reached in-room consensus on the message length field for
  CoAP over TCP and issued a WG document adoption call on
  draft-tschofenig-core-coap-tcp-tls-04.
* A post WGLC check on draft-ietf-core-http-mapping-07 revealed
  remaining outstanding comments.
* draft-ietf-core-resource-directory-05 is nearing completion (seven
  reviewers were identified); defining a CoAP PATCH method is
  desirable.
* draft-ietf-core-interfaces-04 is a new version with significant
  updates and a lot of renewed interest; this might move from
  informational to standards-track.  The SenML version used there
  needs to be aligned with the SenML draft.
* draft-jennings-core-senml-02 updates the format to account for the
  lack of ordering in JSON objects/CBOR maps; the main structure is
  now an array.  Discussion reconfirmed the structured, nested array
  structure defined in the draft.  There was in-room consensus that
  this should be a WG document, to be confirmed on the mailing list.
* Efforts are underway to consider and possibly merge in ideas from
  draft-veillette-core-cool-00 into draft-vanderstok-core-comi-08.

On Friday:

* draft-mattsson-core-coap-actuators-00 describes some problems that
  may need to be solved in CoAP applications, proposes one new option
  that can be used for a simple challenge-response approach for that.
  It also highlights that the proper management of Tokens is security
  relevant over secure connections, which may not be evident to
  implementers from RFC 7252.
* draft-selander-ace-object-security-03 is ongoing.  Some wider
  collaboration is anticipated; draft expected at IETF 95.
* New methods: both draft-vanderstok-core-patch-02 and
  draft-bormann-core-coap-fetch-00 were discussed favorably.  A
  conclusion is needed on whether both PATCH and iPATCH are needed, as
  well as a better name for iPATCH.  Clients need to find out what
  formats are acceptable for the request payloads (form relations?).
* There is good interest in the work on
  draft-koster-core-coap-pubsub-03.
* More results are available on draft-bormann-core-cocoa-03, some
  quite favorable, but also some indication that the complexity can be
  further reduced for some areas of application.  Discussion is
  ongoing.

# Detailed notes below.

# Tuesday

TUESDAY, November 3, 2015

0900-1130  Morning Session I
Rm 301          ART *** core    Constrained RESTful Environments WG

Minutes of CoRE at IETF 94 Session Tue 9:00-11:30

No changes to the agenda

## Chairs' Intro (10)

- RFC 7641 published (Observe)
- recharter progress (need to respond to the comment)
- draft-ietf-core-block status (got lost in datatracker, but now in AD to clear)
- draft-ietf-core-http-mapping (completed WGLC)
- draft-ietf-core-links-json (needs to be aligned with other work, e.g., RD)
- draft-ietf-core-resource-directory (charter work needed)
- option 284 (draft-tcs-coap-no-response-option-12.txt) (should become part of
our toolset)
            registry:
            -- content-format procedure
            Cabo: Talk to the author if you have comments

## CoAP Maintenance

### 0911-0931 CoAP over TCP (draft-tschofenig-core-coap-tcp-tls-04.txt)

- Report
  - Still 3 length encoding alternatives
  - interim canceled due to lack of participants
  - Call for adoption
- Closing the length shim discussion
  - L2 option removed from the choices
  - L1 implemented twice
  - L3 implemented once
  - L1 requires new block size larger than 1024
  - Need a Proxy implementation to understand the consequences of the draft to
  proxying (to HTTP) Cabo: Block work needs to be done for either L1 or L3
  Cabo: do you forsee any surprises with a proxy implementation? Example from
  Simon Lemay: what do you do if you recieve a CON/NON on the TCP side, do you
  keep it on the UDP part? Cabo: OlafB has expressed a mild preference for L1,
  because it's more easy to implement. Matthias: also slight prefernce for L1.
  Easy to implement, version field preserved. Forces interleaving. L3 could
  block the channel for quite a while.
    Spoke to people of IoTivity they implemented L3 mainly to be flexible in
    size and because blockwise transfers are less performant (1k chunks assumed)
  Hannes: Prefers L1 as well.
  Robert Cragie: Prefers L1 as well.
  Cabo: Hannes would it be a big problem to move to a ?? bit Len(?) field
  Hannes: Don't think so
  Simon Lemay: Favors L1 as well
  Gabriel: Question about reliable transport. Is scenario of traversing the
  internet with proxies etc. been considered? What happens when you have NATs,
  blocked ports, etc.? UDP reachability vs TCP traversal of middle boxes.
    Cabo: running CoAP over Websockets is considered by some people to be a
    potential solution, but is still to be discussed?
 Hannes: When can we expect a stable/finalized document (question from e.g.
 OMA) considering the charter changes? What is the timeline to adopt the
 document?
     Cabo: if it is up to me, it would be before Christmass.
     Hannes: it would be easy to make the L1/L2 option changes and resubmit
     rapidly the document.

## 0931- WG documents

### 0931-0933 HTTP Mapping (draft-ietf-core-http-mapping-07.txt)

-Authors not here due to force-majeure
- Some outstanding comments, Klaus did a review, so far no response

### 0933-1002 CoRE Resource Directory
(draft-ietf-core-resource-directory-05.txt)

- General description of what Resource Directory is
- Deltas to previous versions
  - HTTP mapping and examples - how to implement RD on HTTP
    - M-cast-based discovery is not yet described in HTTP
    - All other HTTP mappings are done
    - Added support for maintaining and updating the links
  - Using PATCH to update collections of links
    - Problem: it was difficult to update links based on their content
      Solution: Use query filters to select links and then use PATCH to update
      them Use of RFC 7396 JSON Merge Patch on selected links - assumes a JSON
      Links representation Depends on JSON Link-Format in order for Merge Patch
      to work
    - Cabo: is the way you implement Merge PATCH idempotent?
    Michael: Need to think about this, believe yes
    Cabo: We hope for a result where different requests can be executed in
    different orders and still get same result Michael: Good point. That's not
    something they've thought about. Out of the top of his head, he doesn't
    think this will be a problem, but this requires more in-depth analysis.
Cabo: Work seems to be nearing completion

    Kenny Smith: There is also Hypercat. There is also W3C WebLinks. And
    DNS-sd. Is there an effort to harmonize with that? Michael: Is looking at
    Hypercat and W3C Thing-Description (TD). There are differences how the
    links work, but mainly in terms of vocabulary. Could be harmonized.
          W3C has not finalized their format, favoring WebLinks There may be
          some content-format/media type conversion.
    Zach (via Jabber): +1 to Michael
    Ari: Is the link management maybe something general and should be moved to
    a separate document? Michael: ???. Make sure it makes sense in all contexts
    Yong-Geun Hong (ETRI): When implementing PubSub there is a strong
    relationship to RD. Draft does not talk about this. RD is defined as
    optional in PubSub draft. Michael: Topics should be registered as
    resources. Haven't seen any need to modify RD. In most practical cases one
    would use RD along with PubSub Zach (via Jabber): Should not have a
    dependency on CoRE-PubSub. Core-interfaces could be a general home for such
    things. Cabo: Who has read a recent version of RD? Hannes: Do you mean
    ready for WGLC? Cabo: No wider review, but could do this as WGLC Hannes: It
    would be good to finalize the document, lots of consumers are waiting for
    this Ari: +1 (get it done). If new functionality delays the document, maybe
    do it somewhere else. Cabo: Could do it in a separate document. Hannes: Get
    a stable version sooner instead of trying to align with changing parallel
    approaches

    Cabo: The road ahead could be to work on the PATCH functionality.
    Zach (via Jabber): WRT adding PATCH, lets have a WG decision about adding
    or moving to separate document Tim Cary: I didn't know that OMA is looking
    at the draft. Is this an official position? Michael: The reason there are
    no official references is that it is not an RFC. Waiting to become one, so
    that OMA can reference it.
    ...
    Michael: LWM2M indicate that you can create/delete resources, but they
    don't indicate how(?) to do it. Michael has a proposal how to do it. If you
    don't do it (nicely), you need to deregister and re-register whenever you
    change the links. Tim: The specific question is on PATCH - (is PATCH going
    to LWM2M ?)
   Zach (via Jabber): In practice OMA is referencing the RD spec similar to
   SenML.
    Tim: In LWM2M you don't want to do full updates. PATCH will be really nice
    to have, and they are only waiting for PATCH to be standardized to accept
    it. Cabo: Argument is: do the patch work along the same timeline. Hannes:
    Is charter update finalized? Will that affect the document? Need to
    indicate when we want to finish this! Barry: Still comments unaddressed for
    the charter, but they will not change the general goal. Barry: Reasonable
    request to the chairs: please, keep the milestones in the charter as
    up-to-date as possible. Zach (via Jabber): We need to do whatever gets this
    docuemnt done the fastest.

Reviewers: Hannes, Tim, Robert, Alex, Ari, Jaime, Mohit

### 1002-1036 Reusable Interface Definitions for Constrained RESTful
Environments (draft-ietf-core-interfaces-04.txt)

- General description of the idea behind interface types
 - Whole concept of ??? not so well defined
 - Definition of observe attributes, such as pmin, pmax, st, lt, gt - set on a
 resource using query parameters - Concept of link bindings to resources, which
 synchronize the state of resources in different endpoints
- Updates
  - POST changed from toggle to POST
  - conent-type -> conent-format
  - more descriptive abstract and intro
  - Added description of collections (how to use them, different types of
  collections - batch collections, etc.). This was references from an OIC
  document. - Added group actions (update, actuation), add dynamic item
  creation with link (related to the batch type). This new content form is more
  hypermedia-friendly. - Changes related to moving from URI path navigation to
  link discovery, i.e. enabling hypermedia-oriented applications - Embedding
  link processing controls. Useful for machine interfaces.
    - a URI points to a collection, then you perform actions on the items in
    this collection (batch/individual updates, inserts, deletes, etc.).
  -SenML example of batch collection representation

  Ari: This is the old format of SenML, new root element is array and hence you
  will not have the "l" member. But can be serialized in a different way. Will
  be discussed in mode detail at SenML slot. Cabo: the rest of this morning
  will be filled with ways to work on collections, so that is a pattern on
  which we should probably work on Darshak: Is this just an example how to do
  it or the way it is defined and needs to be used? For instance, there is also
  the OIC way. Michael: If a client understands the content format, it could
  work together (?). This is just (a representation) an example, but the point
  is (?)

  - Example of hypermedia interaction. Somewhere in the middle of the exchange.
  A Get on a resource GET /light/?rt=brightness . The result is a description
  of the next resource that will be obtained, with the resource type (rt) that
  can be obtained. The example continues with a form, that indicates to the
  client the way to invoke a given method (e.g. like webforms). How to
  construct a request

-Open Issues
  -Should this moved to standards track? (to get normative references from
  other standards)
Cabo: Are all elements of the current doc at the same level of maturity?
Cabo: a related question is - are there any dependencies on these concepts?
What are the depencencies? should we split some of them in different drafts?

Michael: the functions are not at the same level of maturity (e.g. collections
are much more mature). Probably separate functions, move on with the
collections. Tim: Should we continue to progress the draft or wait for the
needs of OIC? Hannes: We shouldn't second-guess what OIC likes or not, just do
what we think is right Darshak: Make sure people do not diverge too much from
what is done here Zach (via Jabber): Goal should be to be generic, don't need
to be perfect match for OIC, OMA or IPSO, others can extend later to match
their requirements Cabo: count of hands - who has read the most recent version
- 1-2 hands. Cabo: this is a new version of the document, take a look at it
once again if you've gave up before. (Hannes suggests it is much more readable)
Cabo: is this standards-track document? Hannes thinks so. Zach (via Jabber):
Should be standards-track, more useful like that Cabo: the goal is clear - you
should read the document. Who is planning to read it? Ari planning to review,
some more willing (Matthias, Alex, Jaime ...)

Kevin Smith: Indeed, RESTful would imply a starting bookmark and then
interaction driven by link relationships. As long as the resource
representations (including any extensions) are specified (also via a link
relationship) then that should suffice.

## Data formats

### 1036-1108 SenML (draft-jennings-core-senml-02.txt)

Location of base values: Array root, base first
- Discussion on the ML
  - Proposal to allow all UTF-8 charset without Surrogates or Noncharacters
    (exclude all control characters). Question to audience: Is that a good idea
  Martin Durst: Surrogates don't exist in UTF-8
    Cabo: we know that. But not all do; should be explicit.
  Cabo: the problem with UTF-8 is that you need language tags.There may be the
  need to add something like that - is it Chinese or Japanese characters that
  you have? Question: is the language of a document set once, or should there
  be some way to encode the language for each string? (how do you differentiate
  a text in French, English, Italian)?
Ari: 7-bit ASCII was too simple, UTF-8 seems right?
Martin: Things looking much better with language tags for Chinese and Japanse,
but not unreadable without Hannes: Information in the JSON structure not
presented to the user as such, this is machine-readable, why need for language
tags? Andrew: There are reasonable use cases for language tags Hannes: Though
there would be another intermediate layer that maps to user representation
Andrew: Need free-form text Matthias: The example would be - some metadata
about the device - manufacturer, etc.

How about control chars?
Cabo: Allow everything is easiest. We don't have to define what they mean, just
transport them Cabo: Taking quotes out can make life easier for JSON Barry: No
matter what you do someone is not going to like it, just specify clearly
Matthias: Make it a SHOULD Ari: could recommend to avoid quotes to allow faster
processing, but be preraped to receive one

Name attribute, restrict more, not allow full UTF-8
Martin: Real names actually need non-ASCII chars, I don't see reason for this
restricting Barry: These are protocol names, no need for UTF-8 Keep as simple
as possible

Base value for value

  Current: base name, unit, and time
  Proposal: Add base/default value

  Who is for/against?
  (very little audience response)
  Go with that proposal (since no one is objecting)

Location of base values

  Alexander: Like this proposal, but use a more generic solution (use
  Deterministic Multimaps) Cabo: Good idea when combining it with other ???,
  looks simple on a napkin, but difficult to implement -> prefer the previous
  solution Cabo: What do you do if they (Base value objects) are mixed? Ari:
  Make it a MUST that they are not. Mohit: Was this done to make it faster?
  Ari: Not necessarily, but looks simpler -- which may not be a good argument
  Andrew: Being more explicit better

New value type: binary blob

  Mohit: Makes sense, but keep string type
  Matthias: There is already use for this
  Andrew: string is a distrinct type, needs some restrictions
  Zach: Not too excited about adding everything in-line with the data, that is
  why we have RFC6690.

Who read the document:
4 most recent version
10 a version

Who thinks this should be a WG doc:
    8 + 3 (on jabber) for 0 against

## Management (45 minutes)

### 1108-1134 COMI (draft-vanderstok-core-comi-08.txt)

- Presentation of changes from version 07
  - Rehashed object hashes have bit 31 set to 1
  - Apendixes on hash clash probability

-Rehash error
-YANG lists
-RPC addition
  Do we want to add this?
  PRO: Part of YANG, Modelling use, Use of IN and OUT params
  CONTRA: Not REST

Ari: The idea of using RPC in a RESTful way is being discussed at the T2TRG for
the "RESTful Design for IoT" draft. We should make sure our recommendations
there and what we propose here are aligned. Your input for this discussion is
very welcome.

Cabo: Objective is to benefit from entire YANG, so we need to support RPC, YANG
modules for CoRE should not make liberal use of RPC. We are now exploring in
T2TRG good ways to do "action like" interactions and have learned quite a bit.
Alexander: ??? Matthias: Do we need that on the wire or can it be solved in the
tools (RPC API that produces REST CoMI messages sent to devices) Ladislaw: ???
Alexander: relating to Matthias remarks: Describe everything the same way, just
have ?? As Carsten said, for IoT specific objects we should avoid RPC.

Way forward
  Balanced functionality?
  WG acceptance?

Alex: hashes look good on paper but add complexity. Something that need to be
discussed. Michel Veillette (via Jabber): RPC in not the only feature of YANG
not suppported by CoMI. Data types identityref, instance-identifier and leafref
are also not supported. Tim: Haven't read CoMi yet, need to do this. But
comparison to LwM2M seemed unfair. Not sure how the YANG modules are really
used. Bierman (via Jabber): WRT Michel: Those datatypes are supported, do not
need special processing.  rpc-stmt and user-ordered lists are excluded now
Alex: Identifier always need space, no way to compress

Cabo: Discussion needs to be moved to next slot (time's up). Need to nail down
the design goals. Simple things should be simple, difficult things should be
possible. Often we want to merge multiple proposals to one before adopting as
WG items.

Document split
  Suggestions that current doc is too large. Suggested split:
      1. CoMI function spec
      2. Hashing spec
   3. CBOR content format

Alex: Half similar (to ???) half different
Hannes: If we want to reuse YANG models, which are useful for Iot? Haven't seen
any yet.

# Friday
Carsten: Agenda presentation
(https://tools.ietf.org/wg/core/agenda?item=agenda-94-core.html) Pushing in
discussion on PATCH, FETCH and PubSub (around 10 min each).

## Issues spilling over from T2TRG [1]

          * Security implications of delay attacks (20) John Matsson

              draft-mattsson-core-coap-actuators-00.txt

              * an attack and a mitigation when CoAP is used to control
                actuators (Section 2.2 and 3)
              * an attack and a mitigation when CoAP is protected with DTLS
                (Section 2.3)
John Matsson: Security for CoAP (Actuators). HTTPS provides more security
properties than CoAP over DTLS, surprisingly CoAP+DTLS is vulnerable to
mismatch attacks. Fixable by making the client not reuse the same token used by
the server. Some question is whether it is fixable in DTLS or in CoAP, CoAP
more likely to happen. Carsten: Surprisingly using with UDP instread of TCP has
implications on other drafts. The PubSub draft does not have any precautions
when writting on topics. Have you analyze it to the point that you know that
there aren't other issues? John M: If we agree that the ERRATA is the way to
go, then let's discuss on the mailing list and analyze there if there ar e more
problems. Jim?: TLS has more credit that it deserves, cause it's going to have
the same problems. TLS would have the same problem. John M: But in HTTP1 you
have only one request and in HTTP2, even you have multiple streams, you have
one request per stream. The problem is the combination of DTLS with certain
protocols. Carsten: In HTTPS responses cannot get lost. So this kind of
situation (CoAP+DTLS insecurity) cannot happen. Sandeep: I think it might be an
implementation issue? "You would be waiting until you get a response?" Jay?:
Same situation we had in HTTP RG, security should be based on the whole system
... Carsten: (Summary) ... remember not to take DTLS or security for granted.
John: Agreed... Darshak: Agreed... John M: Presents Request Delay Attack. The
attacker can delay a repsonse and control the replay window, thus an actuator
would actuate at the wrong time. Fixable if the server verifies the fresheness,
possibly with a new CoAP option. Sadeep: Another possibility is to have a new
handshake to ensure it is fresh. Carsten: Problem is that the application is
relying.... how do we add the temporal component. Web frameworks have some
token placed in the HTML form. So basically it is done by the applicaiton and
not as a feature of the protocol. Of course TCP helps, we don't have that here.
The main point is that the server has to maintain the validity of the
information. John: Agreed, placing it in the payload is an option. Robert
Cragie: DTLS sequence number captures this right? John: DTLS replay windows is
usually around 64 packets. If the client send more than 64 messages the
attacker could also block them all and hence replay window does not help. John:
(Presentation) Repeat Option, Time Option. Carsten: The interesting thing here
is that the fresheness token can also be transported by other app mechanism.
John: Agreed Darshak: In that case the attacker can block the response... John:
If the attacker blocks the response you cannot control the actuator.  More
analysis required.

## Security

          * Object Security: OSCOAP, OSCON, DCAF-COSE (30)

              draft-selander-ace-object-security-03
              draft-bergmann-ace-dcaf-cose-00

              * what CoAP features do we want to protect end-to-end?
              * what transformations should proxies be allowed to perform?

Goran Selander: Presenting Object Security in CoAP. Intro: With DTLS hop-by-hop
DTLS does not help to ensure E2E security, since DTLS sessions terminate at the
proxy. Still you would like to enable proxies in some cases and they need to
read the CoAP messages. Thus OSCoAP. Presenting updates on OSCoAP. Proposal of
a new separate draft on required end-to-end security properties and waht part
of the CoAP messages needs t be protected. Gabriel Montenegro: Where you in
SAAG yesterday? Protecting selectively some parts of the message is usually
problematic. Message was "Don't do that, protect everything". Goran: This is a
different topic, not an optimitation. This is requred for proxies. Gabriel:
make sure the proxy functionality as defined is OK. Göran: agreed, need to
review the funcionality.

Sumit(?): will proxy select encryption?
Göran: for proxy to work, you need to terminate DTLS there.
Sumit: does the client know the proxy does this? Since the client knows it's
proxy, it's OK. Maybe appropriate to clarify this. There is no good way to
selectively protect messages. Göran: OAuth discussed selective encryption of
HTTP headers; different but related. Sumit: header maybe OK to play around,
payload full encryption Jaime: I was at SAAG. The specific case was different
than here. If you use DTLS e2e you can't do what is proposed here. Hence this
is needed. For example something like this would be needed in the PubSub Broker
case. Carsten: key here is that we do want certain services from the proxy.
Should look closer into the services we want. Goran: Agreed. We want to support
certain properties from the proxy. Timeline is to have a draft for next meeting.

### PATCH (draft-vanderstok-core-patch-02.txt)

              * confirm outcome on error code 4.09
              * PATCH vs. IPATCH -- do we need this?
              * Atomicity

Peter V: Presenting. Question on use case for atomicity for Patch request.
Carsten: Generally we expect the request to be done.
Peter V: Like HTTP Patch, CoAP Patch is not idempotent.
Matthias: I agree it should match HTTP. We should maybe use conditional-request
but not a new method please. If there is really a use case for having it in a
method. Two Patch methods might create confusion. Carsten: Do we need to make
CoAP PATCH like HTTP PATCH? Peter V: No strong opinion. It is true that it may
make people confused. I am in favor on having both though. I do not know of
other issues of this draft. Others are referring to it so should it be OK for a
WG adoption. Carsten: There has been a reluctance to take this work, cause we
don't want to add more methods, but the use cases are there. Let's have a
discussion on it.

### FETCH, COOL (draft-bormann-core-coap-fetch-00.txt,
draft-veillette-core-cool  -- missed deadline)

Carsten: Problem with URI sizes, web applicaitons tend to have large ones
(Google Maps example). In HTTP there is discussion on how to replace POST
method for others (SEARCH, ...). CoAP FETCH could be like HTTP SEARCH but it
would be cacheable. FETCH could be used for getting collections, and use a
selector for selecting. Caveat is that FECTH would need more informaiton than
just the linnk to form the payload. We will end up having GET&FETCH,
POST&PATCH, PUT&iPATCH. Should we do it? Alex: I like FETCH and it maps well
with CoOL draft. Ari: Couple of concerns, functionality wise is ok however it
increases the weight of CoAP. FETCH vs SEARCH we might be diverging from the
semantics used with the HTTP SEARCH, maybe we should look how to allign with
them? Darshak: I think it will depend on the semantics. Carsten: Calling it
SEARCH and having differnet semantics would be bad. Answering Ari, if an
application doe snot need this it doe snot have to implement the method. Robert
C: There is a fundamental difference ... Carsten: I would expect this to be a
four way exchange... at the end I expect this to be on the metadata. Ari's
input should be taken as another goal for the group to collaborate with HTTPbis
and influence there. Peter V: We should maybe develop FETCH and PATCH with the
applicaitons that actually use them. Carsten: OK Alex: ... ... Carsten: ... ...
We should on the remaining open questions with CoOL.

Alexander Pelov: In RESTCONF and YANG you have very long identifiers. To enable
compatibility with constrained devices we should shorten them. CoOL IDs are
constrained and still can use CBOR. Makes use of a registry (IANA action)
instead of hashes. Next steps, deterministic multimaps, Pubsub, variable
datastores and distributed transactions. Carsten: two main components,
efficient selector that would work well with FETCH and other fields. Second one
is more problematic, wich is about managing IDs not just YANG modules but also
Media Types. We really need an infrastructure that gives the ids when they are
registered. YANG modules should have that sort of registry. Tim Carry: Same
concern. On LWM2M we had identifiers for Objects and had to be registered with
OMA but some did and some didn't. Data Plane (service plane) was using the same
concepts. As a thing provider i am doing two things offering management and
offering data plane. Also different interactions in different planes (CBOR,
JSON, YANG...). Managed IDs are difficult to work if you don't count for people
sometimes not registering their IDs. Alex: Agree completely. We would like to
do both on CoOL or CoMI. Tim C: In LWM2M we tried to have consistency btw
management and data planes. Alex: We need to discuss with the YANG people. Tim
C: You can have an efficient way to do this but you need to enable client and
server without providing an external registration mechanism. Ari: LWM2M uses
the same machinery for management and application. Here in this case it seems
more difficult, I don't see me using YANG models for that. Alex: We take how
RPC's work and transpond them to CoOL, it is in the YANG model definitions and
is a way to express the reasoning in the YANg module case. Ari: So mapping
would be 1-1. Alex: Yes. Carsten: If you don't want to support CBOR and JSON
....  I think what we have to achieve is that the management of resources
should be the same way. The question is where do you get the identifiers? In
this case we are trying to compress the identifiers. YANG Identifier could be
attached to a Thing Description to reuse for applications. Hannes: The
assumption seems to be that YANG models are great and I would like to
challenege that. The devices I have seen there isn't much to manage and there
are very few objects needed. We should look at the initial problems we are
trying to solve and reach those people that have devices. Alex: there are some
examples, for example with ZigBee. Hannes: Maybe it'd be good to document it. I
see all this different variants that would create more interoperability
problems. Tim C: In organizations associated with M2M there aren't that many
things you want to manage. So it'd be good to first define what is exactly what
you want to manage, just get few things and see what can you do with YANG.
Alex: We have some cases for 6tisch Robert Cragy: ZigBee is considering CoOL
and COMI but they are going to remain close for now. Hannes: It is good not to
refer to othe rgroups because for example 6tisch is also very niche. Peter V:
RESTCONF uses YANG and COMI. If you wanna support YANG then you should apply it
to RESCONF, that'd be the best way to use CoOL. Andrew: You also have the
option to register or not register YANG models, you could use the hash in some
cases and CoOL in others. ... Alex: I agree, this should be the way it should
be done... Carsten: Reflect. Next steps for COMI? Peter: We should discuss more
on the details. Alex: We should continue this way and maybe prepare for the
next IETF more informaiton on how to cover full YANG models and how to work on
this identifiers. Carsten: It seems that there is a way forward. Peter: We
agree on the principles but need to work on the details. Carsten: Then maybe
they need to see how to work together.

              * Besides PATCH/iPATCH -- is this proliferation of proposed CoAP
                methods healthy?
              * Where does the request payload come from (form relations...)?

## Pub-sub

### Pub-sub (10)

              draft-koster-core-coap-pubsub-03

Ari: Presenting (PubSub). Clients can subscribe, create, delete topics. Broker
becomes origin server for the resources. We clarified some operations, keeping
in mind that the broker should be simple. For more elaborated methods maybe
other documents could be done. Last minute updates on the CON/NON/ACK
(removed). Topic Discovery uses .well-known for the topics. Sub-topics could be
created on the /ps/MainTopic path . There are some open issues. Should the
broker maintain an internal representationor does it buffer payloads? Should it
convert ot other content formats? POST vs PUT for publish? Default Max-Age of
the topic? DiMagio: This does look a lot like MQTT. The scenario is not clear
from the draft. If it does not do queuing then it makes it not very intuitive
for other Pub/Sub brokers. CON/NON/ACK right now I can process that ack so with
this I lose reliability. The fact that I have receive it. With CoAP over TCP it
would be different then for UDP and TCP. Ari: There was a discussion in Prague
and the conclusion was that the application should provide more information,
the CON/NON does not guarantee that the aplication has received the message.
DiMagio: It should be supported. Ari: We just removed the MUST for this part,
but the application can decide to use it. Regarding MQTT, one of the original
goals was to have message queuing and it could be added in some cases. Darshak
: This assumes that the broker is trusted? Ari: You can use OSCOAP (PAYL mode)
Darshak : ... Ari: ... Tim Carey: There are security concerns for Message
Queing. Could be used for DoS. Matthias: I would like to see this as close to a
proxy as possible. Clients that don't know about it should be able to learn
about how to use it. Broker being broker is good. Some proxies could understand
the payload and do stuff with it others could be transparent. Another commment
with queuing, in the long term restfull way for pubsub interaction. Ari:
Agreed, it could be more complex. We could do an extension. Without queuing is
more simple. Matthias: You cannot just concatenate payload, you need to
understand time series and is not that simple. Ari: Agreed. Mohit: Security
implications of advertising alternative content formats. Ari: True maybe we
should add it to the security considerations... Matthias: It is useful to see
the content format in the link and for the broker to provide that
functionality. Darshak: I would like the broker to be opaque to the data. Ari:
some data can be also opaque even if translation is done for other data

          ## CoAP Maintenance

          * CoCoA (15) Carles Gomez, Markku Kojo/Ilpo Järvinen

              draft-bormann-core-cocoa-03.txt

              * Emulation results of CoCoA on NONs
              * Are the new controls for aggregate congestion useful?

              * Quick overview of results from cs.helsinki.fi

Carles: Presenting CoCoA. Questions to WG but run out of time. Next version
(04) will enhance the congestion control mechanisms. Ilpo: Presenting
Evaluation of CoAP, COCOA and TCP congestion control.

          ## If time permits (10)

                  draft-zotti-core-sleepy-nodes-04 2015-09-30

          ## Flextime (15)