CoRE WG @ IETF93 (Prague) Minutes draft version 0.1 (raw). Chairs: Andrew Mcgregor Carsten Bormann Thanks to the notetakers: Brian Rosen Ari Keränen Thomas Fossati IETF 93 core Tuesday minutes by Brian Rosen & Ari Keränen RFC-Editor's Queue: draft-ietf-core-observe-16 Waiting for shepherd write-up: draft-ietf-core-block-17 Charter proposal https://svn.tools.ietf.org/svn/wg/core/charter-ietf-core.txt Discussion on the wording of how TLS is described. Will update text. Hannes: Why was this not sent to ADs already Chairs: There were some changes Akbar: Does the charter mention extensions to RD? Is such needed? Chairs: Offline discussion CoAP over reliable transports (40) -- finishing the TCP and TLS mapping: draft-tschofenig-core-coap-tcp-tls-04 Chairs: Who read the draft? --about 10 -- Chairs: Who has an opinion (on shim)? --a few, including Carsten Chairs: Who has needs for TCP? -- several hands raised, both servers and clients Chairs: who has implemented CoAP over TCP? -- two independent implementations; mbed and californium. Interoperate. ?Jabber: How do we handle confirmations? -discussion of interaction between TCP and application level confirmations Carsten: TCP has been around for a while, what is missing? -- Application level confirmations needed Jabber: header definitions needed for all transports J Paul: In our switch implementations with mixed TCP and UDP, CON means it worked end to end -- with TCP proxy, use always CON when cross over UDP Klaus H: Confusion on what CON means: retransmission not needed because message has been received. There is no further semantics on CON except no need for re-trans after ACK. Chair discussion of merging with websockets draft. Hannes and Benjamin (jabber) disagreed on the need to merge. draft-carey-core-std-msg-vs-trans-adapt-00 *) : People have proposed ideas that misuse NON/CON even with UDP. : Dealing with any reliable transport is needed. Ben: Not about NON/CON, it's about clear primitives : Need more clarity in drafts, happening in TCP, leads towards merge of websockets. Benjamin (jabber): the primitive is the same in both those cases. This is exactly Tim's point. define the primitives and how each transport provides them Andrew: the ACK hack may be the de-facto way to do that Carsten: 99% of cases don't do custody transfer. Big burden to many applications. Tim: if app does not want custody, can use NON Carsten: but may need only message reliability, but no stability Tim: with UDP; the application layer buffer has received the message. No more semantics needed. Simon: don't see use case for ACK with TCP. Tim: not referring to same custody. Can be failures between socket and app layer. Transfer from TCP buffer to app layer is not 100% reliable. Simon: but lack of response will tell you that. Ari: if you want real reliability, you should use response codes. Even if ACK is sent, the app may still not act on it (e.g., can crash, run out of resources, ...). Only after response know for sure. So still need to use response codes. Relying just on ACK does not buy anything. Resource directory (25) draft-rahman-core-advanced-rd-features-00 Michael K: group function is already supported for HTTP. Michael K: no need for mirror proxy, just caching proxy. Klaus H: with proxy no one knows you need to go through that proxy to get data Michael: need to register with context option. Already supported. Peter: large parts of MS information in the sleepy nodes draft. Bill S: indication of transport good idea. Check out the drafts. : If you return full URLs, you get the scheme Olaf: there is bug in libcoap Matthias: NON/CON issue popped up in plugtest. Server decides how to notify clients. Should be independent from observe request. Maybe publisher should decide. Topic/resource decides. Klaus: can't have max age in PUT/POST; not defined yet Carsten: with block, how about updating one block of data. Would like to maybe send that, but should here advice against. Re-assembly always. Carsten: need to be careful with term QoS Chairs: How many people have read a recent draft == about 5 -- Chairs: How many people will review? -- more -- Tim: mentioned MQTT couple of times, have done full feature comparison? Michael: not yet, might be good idea. Darshak: origin and security; might be cases where I want broker to host data but have it encrypted. Carsten/Michael: need to clarify in the draft that it's doable with object security IETF 93 core Friday minutes by Thomas * CoMI (Peter) - clash resolution: assume that within the same module there is no clash, on clash add module name - notification: keep it simple, i.e. one slot buffer. to get the whole stream the client need to Observe - select and keys parameters syntax - TODO: (Fill in lost part from audio) Peter: next step is call for WG adoption AP: appreciation for this important piece of work CB: small issue: the item has been added to the new charter, which needs a couple of weeks to be approved Barry: no need to wait for the new charter to be approved: clear for call for adoption now CB: this is important: it'll influence the way we handle complicated resources HT: we are creating a competitor model for LWM2M, which could create more interop problems and more code CB: next is to call for adoption on the mailing list * PATCH (Peter) - PATCH idempotent? CB: HTTP PATCH is not idempotent, if we want a non-idempotent PATCH we should name it differently (IPATCH has been proposed). produce examples, gain more experience (suggest to continue the discussion on this on the mailing list) Peter: atomicity and sequencing is a complex topic CB: suggest who is interested in the topic to look at one (or more) specific content formats of choice and see how that would work with an idempotent PATCH. Once we collect more information we can take an informed decision. CB: who has read the document (about 5) * Simon reports on reliable transports hallway discussion Simon will write a document to document the semantics of each message type so that it can be reviewed and we eventually all agree on the semantics Main points of the breakout session: 1. Message type as defined in RFC 7252 shoud keep the same meaning regardless on what transport they are used 2. Some want to add a new feature in regard to what was discuss (the need for an appplicaiton layer confirmation) 3. The need or a message layer API needs to be evaluated CB: who has an opinion on the length issue? 3-4 hands raised Simon: main point to consider 1. what is the max length that the framing offers 2. what is the format of the framing Simon: question for the chairs: where are we as to adoption? Also, merging reliable transports (TCP and websockets) in one doc is deferred CB: polls the room for who do/don't want to merge 2 wants to merge, 2 don't want to merge CB: the length issue must be solved before call for adoption CB: people with an option need to meet to solve the issue * Alternative Transports (Bill) - -08, shibboleth: streamline! - scheme hosts the transport information (done by London); do we need guidelines on how to use the namespace? just a set of recommendations or should we establish formal rules? CB: there seems to be some kind of confusion, some kind of guidelines is needed JP: suggests {coap,coaps}+ over coap+{,s}, this is what they do at the moment BL: have you talked with Graham Klyne (designated expert who reviews these things)? BS: yes, and we also spoke with Dave Thaler about the registry BL: good to hear that these discussions have been done CB: what is the next step for the document? BS: authors feel it's ready for adoption CB: is there any dependency of this on the TCP doc Simon: (Fill in from audio) CB: about time for call for adoption some nodding noted CB: will move the poll to the mailing list Bill continues discussion on the URI-aliasing issue * to be solved via Protocol negotiation (Bill again) three people read the draft. no one in the room thinks this is not important * HTTP mapping draft (Carsten) - all tickets closed - ready for WGLC - who's going to review it? Michael K., Klaus, Darshak raise their hands - three thorough reviews should be enough. we are going for WGLC and hope to finish it off soon. * CoRE interfaces (Michael K.) - illustrates the high level concepts (Overview slide) - goes through the recent updates to the document (Update slide) - should we move it to standards track? Michael thinks so. - could the WADL be substituted by hypermedia controls? Klaus has hartke-core-apps-01 that is starting to looking into this same space quite a few people in the room seem to be familiar with the draft CB: this has been dormant for a while, it has still informed a lot of work in other SDOs. the discussion in the research group about how to do this thing in a proper way shouldn't stop us for doing an RFC out of this. JP: we are willing to use the bindings AK: this document describes one way to do these things in a specific scenario; the research group is going to carry the general discussion CB: we don't have to take any decision at this point HT: back to the "Open Issues" slide: says "NO" re: standards track; "YES" re: this is the way we recommend people to use CoAP; "YES" re: hypermedia controls * Object Security (Goran) - wrap a CoAP message into an auth-encrypted COSE message - two modes: COAP (include header, options and payload), PAYL (payload only) - current version is -02: include block options use COSE profile provides overhead figures - next steps: improve blockwise support uniform treatment re: encryption and integrity protection for options GS: use cases? MK: pubsub LWM2M would use this instead of DTLS transport GS: what to do regarding size optimization? (refers to a related presentation done in COSE WG) HT: no strong opinion on this. I want to raise the point that no one stepped up for cached-info option in TLS CB: TLS is difficult to schedule for many here (agenda conflicts) CB: I will speak up in COSE to make that useful for CoAP Raza: anything below 100 bytes overhead that is encrypted/integrity protected is fine CB and RC discuss whether it's possible or not to compare DTLS overhead with object security overhead. * SenML (Ari) - goes through the current version of the draft (see slides) AK: is it ok to have base values at the beginning? CB: who has read the draft in one of its incarnations? 20 people raise their hands CB: who has implemented it? 5-7 people John: we use a streaming parser (ordering matters there, plus other nits). will bring the discussion on the mailing list. AK: is the proposal broken? HT: incompatibility with the security modes that we are considering? AK: let's think about this more JA: it's not always a small set of data, could be aggregate measurements and therefore very big Matthias: CBOR preserve order? CB: CBOR is the same as JSON AMG: the proposed way supports google use case with big amount of data AK: asks people to call for external parties using SenML to ask them whether the proposed approach would break horribly. if not, I think we should be doing this way John: multiple bases are a good thing for our use cases AK: will continue on the proposed "Location of base values" and "Multiple bases" then * HTTP/2 for IoT (Gabriel) MK: is working on a binding of LWM2M to HTTP/2, and it's promising AMG: notes that QUIC is not proprietary Homeworks: read link formats (JSON, CBOR) and bring the discussion to the ML meeting adjourned