Minutes for CORE at IETF-94
Constrained RESTful Environments
||Minutes for CORE at IETF-94
CoRE @ IETF94, Minutes Draft 0.1
Thanks to the notetakers!
CoRE met Tuesday and Friday.
* We finally reached in-room consensus on the message length field for
CoAP over TCP and issued a WG document adoption call on
* 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
* 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.
* 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
* 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
# Detailed notes below.
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
-- 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)
- 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
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
- 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
- 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
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
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
- 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
- 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
- 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
-Should this moved to standards track? (to get normative references from
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
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
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
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.
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
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
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 
* Security implications of delay attacks (20) John Matsson
* 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
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
* Object Security: OSCOAP, OSCON, DCAF-COSE (30)
* 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?
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
* Where does the request payload come from (form relations...)?
### Pub-sub (10)
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
* 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)
## Flextime (15)