Tuesday 4 March - 9:00-11:30 Minute Taker: - Corinna Schmitt - Thomas Fossati - Bert Greevenbosch - Esko Dijk * Chair's intro Coap protocol specification has been submitted to the IESG (is in RFC editor queue waiting for one referenced doc) Block protocol - after interop testing this weekend, do a 2nd working group last call. Groupcomm is finished and needs chairs' write-up to be finally submitted to IESG CoAP interop this weekend in London, including -block, -observe and DTLS. Possibility to test OMA LwM2M. Announcement of ACE BOF for tomorrow morning * Agenda bashing Zach Shelby: no RD nor CoRE interfaces on the agenda. RD not a problem, CoRE interfaces need more eyeballs (call for co-authors). * Klaus Hartke on Observe - "optimised" transmission is no more MTI - cancellation is difficult because it is an interaction that cannot be easily mapped to the usual REST model. Identified mechanisms: - overloading GET as we do for registration. Has funny side-effects (e.g. on proxies) as it changes GET semantics. - new protocol element. 7.31 allocated as a "Control" code Klaus: Question: Can we agree to use 7.0-7.31 for Control or is there another solution? - Zach Shelby: make a new draft with this topics and close OBSERVE. 7.31 would be a hack in implementation. Not nice. Look on response code for solution. - Bert Greevenbosch: Move it out of OBSERVE to close it. Can use PUT or POST (with Observe option) as well - similar to OMA LWM2M. - Matthias Kovatsch: All solutions have problems; control messages might be the worst, as they might turn CoAP into something unRESTful and they need changes in the core of implementations (Observe is nothing optional anymore). - Tim Carey: we need the feature. in old solution it was a clear CANCEL. - Akbar Rahman: Prefer to overload GET ; seems messy to introduce a new class of codes this way in -observe. - Klaus: when transporting CoAP over Web Sockets, there is no RST, ACK, CON, NON etc. because this reliability layer is not needed. We need a solution that doesn't use these. - Ed Beroset JABBER comment: place it in PUT - Zach Shelby: Think about it and come back on Friday. if no good solution skip it. - Carsten B.: Describes what is existing and defines terms; token matching. - Zach Shelby: Implementation exist for token ??? and goes to the right place. It is just important to establish the correct semantics. (discussion about Token re-use issues) - Klaus: if we spin out cancellation to a separate draft, we should also include cancel of running requests (eg. expensive POST with response that hasn't come yet) - Mathias: put on the mailing list and "vote". If we decide for ejection of the explicit cancellation, then we could revive the liveliness I-D by Klaus * Thomas Fossati - HTTP-CoAP Mapping - status update about changes from Vancouver version (slide 22) - Main change is ticket #364 - Zach Shelby: the scheme seems 'kind of' removed in current wording. Why not choose one solution? Optional removal is ok, but wording should be better i.e. a default mode of operation. - slide 25 shows example of non-default URI mapping. - Zach Shelby: who wants to discover the proxy in CoAP? - Thomas: we have a use case for that, when mobile device is at home it uses CoAP to discover, when away from home it uses HTTP to access home sensors. - Thomas: Discovery over HTTP (slide 26) is the typical case. - Scheme suppression (slide 28) example shown. This was all for ticket #364. - Work for next iteration (slide 30) - Ticket #366, issue was raised by Klaus in Vancouver. Payload of a Link Format doc may become 'broken' when translated by HC Proxy to HTTP. - Zach: on 'hct' link parameter - could be more widely usable concept. URI templates are more general, so perhaps not define just for this I-D context? Could be in a separate draft, or in a separate section that can be easily referenced from other docs. * Thomas Fossati - a Link-format attribute for Locating Things (normally scheduled for Friday session) (slide 59) - Definition of GEO - Listing of use-cases - Geo-info (slide 64) you get for free (no extra code) - Bounding box (slides 65/66) is cheap but not free. - Zach Shelby: in what way is the bounding box query an extension of RFC 6690? - Zach Shelby: is geo-location an attribute of link format, or a resource of an endpoint rather? In OMA it's an object i.e. resource - Kepeng Li: geo location can change frequently. Maybe link format is not appropriate to signal such information. - Tim Carey: in LwM2M and OneM2M we treat location as a resource, since it is more complex than an attribute. There seems to be interest on the topic (review/implement). Zach volunteers to co-author. * Abhijan Bhattacharyya - no-response proposal (slide 31) - listing updates in current version; section 5 is new - we have made an implementation for vehicle tracking (slide 35) - Issue on conditional suppression (slide 37) i.e. the granularity feature -> no decision yet; comments are welcome. BG: it is useful to have something that suppresses the responses (to save energy); AR: support it: very useful for the multicast case CB: not knowing whether the response is coming or not creates an implementation problem which needs some adjusting to the request/response state machine, maybe Mathias can write some guidelines on tokens in LWIG document. KH: what happens when two clients want to update the same resource? CB: there seems to be interest in this but still some open discussions that we should try to address possibly during the meeting * Bill Silverajan - CoAP Transport URIs embed transport information into the URI classify devices based on the number of transports they may have (also including the notion of "sleepy transport") Main slide is 42 - comparison of 3 options in the draft, against requirements. CB: likes the classification; there is an asymmetry: URI is selected by the server, so encoding the transport selection that the client wants into the URI is a problem: how could we solve the problem? ZS: no strong opinion, hard to solve. Nevertheless, such transport issues need proper consideration. What we need now is CoAP over TCP done. CB: maybe we want to use meeting time to make progress on this * Carles Gomez - advanced CoAP congestion control promising initial experiments further experiments have found underperformance of CoCoA-00 vs basic congestion control in CoAP * sensible to MAC layer reliability * slow to settle after after bursts which has lead to improvements over the initial spec: CoCOA-01 * BEB adjustments (make it variable) Further optimisations have been envisaged, CoCoA+, and experimented under different scenarios (topology, traffic patterns and loads, MAC reliability on/off). In general CoCoA+ has same or better performances than CoAP ZS: experiment not only with 15.4 but also with cellular, satellite, highly loaded cloud servers, etc. AMcG: ... Matt Gillmore: (questions on the simulations) Carles: COOJA was used MK: Adapted transmission parameters (e.g., back-off) also interesting for user experience (e.g., minimize delay within a deployment) CB: how to get more feedback from implementers on this? ZS: may come later KH: currently working on implementing a RTT estimator and UDP congestion control guidance based on RFC 5405 MK: currently working on integration of CoCoA-01 (or CoCoA+?) into Californium AMcG: on the cloud server side, very accurate timing is possible. Helps with reducing buffer space. ZS: ... Carsten: work on it more, mark it as a draft about implementation. Then perhaps adopt it. * Peter Van Der Stok - CoAP Management Interfaces Provide a RESTful frontend to MIBs, without requiring SNMP code in the device. Differences of CoMI and SNMP: * access information via both SNMP OIDs and descriptors (in the URI) * serialisation format is CBOR (more space efficient) or JSON instead of ASN.1/BER * leverage on CoAP GET/PUT/Observe/Block features to interact with the MIB * a number of URI query attributes are used to define the context, row number, modules, etc. ZS: (slide 86 example) consider doing text/plain when returned data is flat Carsten: new JSON spec not restricted to emit containers (i.e. arrays/objects) only. It allows sending all basic types (e.g. a single integer value) Klaus: links are missing; wondering if solution is RESTful; paths are hardcoded Kepeng Li: ... ZS: very good work; not worring about RESTful. Payload inside the GET request is a bit weird (). TF: payload within a GET request has no defined semantics in HTTP: concerned about the request going through an HTTP-CoAP proxy (it could just drop it -- either the payload or the whole request) Peter: this is done to keep things tidy (not many fields crammed into URI). Thomas W.: simple URI; is it possible to preload it on the mote? TC: why are we developing a management protocol in CoAP? CB: need more discussion about why we need CoMI in CoAP Barry Leiba: how much this has been socialised with the operations area? Suggest to go and talk with them not to conflict with their scope. Friday 7 March - 11:50-13:20 Agenda bashing Akbar Rahman: can we find time for the sleepy device use-case since this has been pushed out from agenda already twice? Constrained Management discussion - Coman work completing in OPSAWG - IETF moving from MIB-2 to NETCONF - MIB-2 is optimised for Hannes: how all this fits together? how this interwork with OMA LW device management, firmware update management? Zach: COMAN + COMI is OK to start with. Tim Carey: if we expect devices to have more than one configuration interface we are in trouble Zach: don't want a general solution but having a minimal subset of interfaces is OK; the REST model provides an effective set of mechanisms for layering slightly different management interfaces Peter Van Der Stok: [sorry could not hear] Carsten: Next steps? Should we continue doing this? Hannes - ACE BOF Summary - strongly participated (~120 folks, with a 10% interested in writing documents) - recap BOF topics (use cases, requirements, architecture design choices, etc.) - charter discussion, main topic to be resolved: should we assume CoAP on DTLS only? mailing list discussion already started. chair proposal is to initial focus on CoAP/DTLS, but allow for other bindings (e.g. DTLS over SMS) Klaus - Observe discussion time to make a decision, possibly today here, and then come back to the list for confirmation how to express cancellation in our messages? - overload existing protocol elements - create new protocol elements discussion going on during the whole week list of pros and cons (have been circulated on the mailing list) [missed discussion] Alternative transport updates Akbar - Sleepy devices in CoRE - there is interest to tackle this argument in CoRE? - there have been various I-Ds explicitly targeted at sleepy nodes - pulse was taken on the mailing list which highlight strong interest Zach - we are working on an update to the Mirror server Zach - RESTful queueing in OMA that could be potentially reused - Do we want to bring work on sleepy in CoRE? Mirror server revival possibly available in the next 4/6 weeks