CoRE @ IETF94, Minutes Draft 0.1 Chairs: Andrew Mcgregor Carsten Bormann 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)