CoRE WG @ IETF86 (Orlando) Minutes draft version 1.0. Chairs: Andrew Mcgregor Carsten Bormann Notetakers: Zach Shelby, Esko Dijk, at least one other anonymous note taker -- thanks! From these notes, compiled by Carsten Bormann. [Times/numbers in brackets indicate approximate position in the audio recordings and slide number.] TUESDAY, March 12, 2013 1300-1500 Afternoon Session I Caribbean 2 APP *** core Constrained RESTful Environments WG ietf86-caribbean2-20130312-1300-pm1.mp3 ** Intro, Status etc. Note-Well, Blue Sheets, Scribes, etc. WG Status: - Milestones ** wglc processing draft-ietf-core-coap-13 [7] Objectives: - close remaining issues from 2nd WGLC - Carsten mentions that -14 was almost completed, in the WG SVN, waiting to be published after this meeting. - The objective is to submit -14 for publication to IESG after this WG meeting. - Addresses the comments from the second WGLC, mostly editorial (thanks to Bert and Barry!). - Clarifies that payload sniffing is a last resort for when no Content-Format is supplied. - Clarifies that Safe-to-Forward options in a Valid response update the cache. - Only one technical change: Accept option was made non-repeatable. - Matthias presents the reasoning for this change. - Carsten states that discussion on the list indicates rough consensus for making this change, then confirms in-room consensus on making Accept non-repeatable. No further comments. - Carsten asked if there are any other comments on -14 or IESG submission. No further comments. ** open issues on drafts nearing 2nd WGLC [13:30] draft-ietf-core-observe-08 [10] Objectives: - close remaining issues in preparation of 2nd WGLC Carsten reminds people to use the CoRE ticket system, to also do a review of closed tickets; notifications from the tracker are sent to the list. - Carsten gives quick overview of Changes since -07 presented. - Expanded text on transmitting notifications while a previous one is pending (closes #242); - Changed reordering detection to usa a fixed time span of 128 seconds, decoupled from EXCHANGE_LIFETIME in base spec (#276); - Removed use of the freshness model to determine if the client is still on the list of observers (still in progress). draft-ietf-core-block-10 [11] - Carsten: waiting for an editorial re-write after coap-14 is shipped ** Groupcomm (Presenter - Akbar Rahman) [19:45, 14] draft-ietf-core-groupcom-05 (Background reading: draft-dijk-core-groupcomm-misc-03) Objectives: o Review changes due to the closed tickets (#187, #271, #273, #275, #277) o Review remaining open issues Akbar discusses draft-ietf-core-groupcomm-05: - Two revisions since IETF85 Atlanta (-04 and -05), thanks Peter van der Stok - All the DNS base features are optional - Text on how to handle absence of IP multicast (e.g., RPL in non-storing mode) - Text on security considerations, NoSec mode - Congestion control, prefer link-local multicast - Discussion items (1) - 1. Solution for configuring group membership Zach: Yes, useful, also part of RD (resource directory draft) Carsten: Do we have an example combining RD with this mechanism? Please add an example! (Peter then agreed to help with text for a lighting example) Floris: DNS hostname? Akbar: Optional; use IP literal wherever possible. Matt: How do you handle security inside the group, e.g., removing some member? Akbar: Security is hard with multicast; Out of scope, rely on other mechanisms Zach: Yes, but SHOULD provide access control for group management resource; should discuss this in security considerations. - Open issues (5) - 1. Review groupcom requirements language (#271) Should we be using RFC 2119 requirements language in an informational document (review of the language is next)? - Barry (our AD): It is up to the WG, should be consistent within the WG - Kerry Lynn: keep normative language, as we want this document to be a strong recommendation that helps interop between different implementations. - Carsten: MUST/SHOULD/.. are useful for defining interoperability, in an informational document discussing specific scenarios, there may also be conditions of interoperability in these scenarios. - 2. Add section on multicast via Proxy and its limitations (#274) - Zach: Add explanation about the issues from ticket (not a huge thing) and close it. - 3. Issue of multiple resource directories in use case (#280) - Zach: Complexity of multiple RDs -- peering, hierarchies, etc. -- probably out of scope - 4. Add single-subnet configuration to use case (#278) - Akbar would be happy either way - No comments - 5. Add a use case with controller located on the backbone (#279) - Zach: Worthwhile as main commercial use case - Zach: this is pretty rapidly reaching completion. Can we close the tickets and ship it? - Draft to be updated within a month, do a quick check on the mailing list, and then WGLC ** companion drafts to the WG drafts: [46:45, 26] *** HTTP-CoAP Mapping (Presenter - Salvatore Loreto) draft-castellani-core-http-mapping-07 (Background reading: draft-castellani-core-advanced-http-mapping-01) Objective: o Review updates based on key comments from last IETF including: o Clarification of definition, placement and benefits of HTTP-CoAP Proxy o Updates to HTTP-CoAP URI mapping details Salvatore presents draft-castellani-core-http-mapping-07, no changes intended on specifications, just showing ways to use: - Changes since -06 - Clarifications of HTTP-CoAP proxies - Clarification of HTTP-CoAP URI mapping options - Goal: help implementors create proxies that interoperate with other HTTP/CoAP client/server implementations; and also with other proxy implementations. - Salvatore asked for people to review in particular the response code mappings. - WG document? - Carsten: (asks who has read the document) please send some reviews (need not be big) to the list! - Floris: What about proxies that allow selection of a specific origin server via IPv6 address? - Zach: That is a forward proxy. People want to hide those IPv6 addresses, so we are seeing reverse proxies being more common. - Salvatore: For a forward proxy, it is only possible to configure a single one, so this might not be feasible. - Floris: reuse discovery mechanisms? - Salvatore: Some discussion is also in our other (background) draft. - Carsten: If there is no good reason for reverse proxies to implement specialized access APIs, we should have a convention for the URI mapping (if only for ease of debugging). See also draft-bormann-core-cross-reverse-convention. - Carsten: Further process: wait for one or two reviews to appear on the mailing list (reviewers were appointed?); then request for adoption on the list. This won't need a recharter. *** Alternative Transports [73:20, 40] draft-silverajan-core-coap-alternative-transports-01 (Background reading: draft-becker-core-coap-sms-gprs-03) Objective: - Determine way forward For background, Carsten uses some slides from Markus Becker (who isn't in Orlando) to give a quick review of draft-becker-core-coap-sms-gprs-03: - Alternatives for when IP connectivity is not available (SMS, USSD, ...) - Waking up an IP-outgoing only device (e.g., GPRS) using SMS/USSD - New challenges such as not having an IP address, or data transparency - Split coap+tel into coap+sms and coap+ussd Teemu presents draft-silverajan-core-coap-alternative-transports-01, relatively recent work: - Use cases: TCP (NAT, firewall traversal), DTNs, non-IP low power networks - new URI schemes for transport, RD support - Salvatore: Why included in the URI? SIP for instance does not. The client is configured to make this decision. - Zach: not if client looks up weblink(s) from a directory. URI should define a resource which depends on the transport. (could do this in additional attributes in the link format.) - Carsten: We already have two transport bindings and indicate them by coap: vs. coaps: (yes, that is security...) In HTTP world, they always use DNS, so at least in theory, a DNS SRV lookup could be used to decide which transport. - Jari: More flexible URI scheme appears useful, many use cases. But draft simplifies the issue perhaps too much. - Yosuke: Including transport makes URI more a locator than an identifier. Better call it locator then, not identifier. - Andrew: You can't always depend on DNS SRVs being there! - Transport in scheme, in the Uri-Path (host;transport=xx), or in the query - Zach: in scheme appears much better. - Floris: in scheme best; IANA approval of schemes would help to restrict strange transports. - Carsten: In REST, servers have full authority about the Uri-Path/-Query naming they use for their resources, which conflicts with the second/third proposals. Also, RFC 3986 is not only a full standard but also strongly entrenched in software; should stick to it. Would be good to look at others, how they solved the URI problem. - Andrew: Second/third proposals violate layering. Scheme most logical. - Salvatore: Scheme not the right place, would create different resources for accessing the same resource using different transports. - Barry: (As participant:) Agrees with Andrew. (As AD:) Contact URI people, especially Graham Klyne/Julian Reschke. - Robby: with different schemes, you access different resources. - Carsten recommends to Teemu to get in contact with Markus (prev. draft) to synchronize and possibly merge the drafts. - Robby: Huge piece of work, draft so far generic but might want to end up in one draft per transport. - Teemu: yes - Carsten summarizes: This is highly sought after functionality, we should continue with this subject. *** Sleepy Nodes update [104:55, 65] draft-rahman-core-sleepy-02.txt Objective of presentation: o Review initial experimental results (performance curve): o Of a network: "With and Without CoAP enhanced sleepy node support" o As was requested in the last IETF meeting Akbar reviews draft-rahman-core-sleepy-02: - Question was raised: What is the benefit of this over caching? Sleepy node performance analysis was done to compare. - Floris: considered radio (MAC level) duty cycling to save power? - Akbar: yes, but doesnt affect these results (actually this was measured on 802.15.3 devices). - Matthias -> Akbar: Delay response vs. sending 503. - Matthias: 503 response was only present in middle bars (scenario 2). Why? (Akbar wants to make this more clear.) - Matthias: How much does Observe help here? - Akbar: Comparison is to be done once Observe is fully implemented. - Zach: Something we have solve, but a broader problem about hard to reach nodes, "dont contact me I'll contact you". Zach will highlight the work that has been done on this subject (server queues) within OMA slot at the 2nd CoRE meeting tomorrow. - Andrew: availability on schedule vs. no idea when being back. - Zach: trying to do exact scheduling is difficult in practice. - Jari: It might be better to model a proper communication model (who initiates what) than solving this in the protocol. (Based on our experience.) - Carsten summarizes: there is interest, so let's continue. But no agreement on specific solutions visible at this point in time. --------------------------------- WEDNESDAY, March 13, 2013 1300-1500 Afternoon Session I Caribbean 5 APP *** core Constrained RESTful Environments WG ietf86-caribbean5-20130313-1300-pm1.mp3 ** Intro [96] Carsten reports that coap-14 was submitted the IESG. Barry reports that it is going to IETF last-call now as well. ** related activities Objectives: - explain shortly what the activity does and what was achieved as well as invite constrained network experts to join the relevant mailing lists. *** OMA M2M update (Zach Shelby) [04:30, 98] OMA Lightweight M2M (Zach Shelby) - Complete system for M2M devices. - OMA device management based on XML, HTTP, TCP... - now started with lightweight variant: Reuses work from IETF CoRE, including Observe and certain parts of Resource Directory, also SMS work. - Standard in development is available online, however only members can contribute (Telco vendors, operators; IoT vendors) - Complete, demonstrated and implemented, to be approved in Summer. - Access is REST, defines a resource structure and a simple object model. - Derek Atkins: namespace collisions accross object IDs? And 256 instances too limited for instances? E.g. controlling individual LEDs? Zach: OMA has a naming authority, the object ID space is controlled by them like we use IANA. In the URI, there is no limit -- this is just a specification limitiation. The next version of the spec could simply extend the space. Second question: you could run multiple endpoints. This is a limitation. - Robby: extensibility of objects? What do you do with version 2 of an object ID? Zach: could extend them; but there is no way to ask an object for its version. Or could define new object ID. - Yusuke: Could we define something in this namespace? Zach: split up like we often so, OMA-defined, specs-defined, enterprise-defined. - Carsten: how is device management handled by this standard? Influence on the COMAN non-WG mailing list? Zach: Objects can be used for any kind, including device management. We want to use the same protocols and security associations for management and application data. Is this covering everything? Maybe not, but it is REST, so things that don't conform to this structure can be run along OMA. - Robby: the URIs from OMA resources can collide with other CoRE resources? Zach: yes, link format resource types can help identify OMA resources. Robby: Have you considered using a discoverable OMA-prefix to avoid collision of resource's URIs? Like /foo. Zach: in theory possible. We have the resource types in link-format. Robby: Other specs could be using /integer... - Ulrich: open source implementation available? Zach: Every single CoAP implementation can do that today (e.g., use Matthias' ones). Just comes down to adding new resources to existing implementations, allmost no additional configuration needed. Carsten: in the future, want to give space at CoRE meetings to our customers, i.e. 3rd party users of IETF CoRE drafts, to give update their work. ** new work, continued *** Discovery [25:30, 102] draft-shelby-core-resource-directory-05 Objective: - Does the WG believe this should become WG work? Zach reviews draft-shelby-core-resource-directory-05. - Introduces RD again. "Search Engine". Can be done over HTTP like over CoAP. - Parameter updates only; if you want to change your resources, register again. - Pagination support. - For endpoints (only) change rt -> et (endpoint type) - Group management support: thing with a name; list of endpoints. - Kerry: important to preserve semantic equivalence between DNS-sd and RD searches. We have rt in DNS-sd. Carsten: Do we have a document on that equivalence? Zach: there is a draft about this, [draft-lynn-core-discovery-mapping-02.txt, expiring soon]. - Jari Arkko: thinks it is important that this draft gets adopted by the WG. Argues that a RD is part of the base for applications for IoT. (only talking about RD, not the DNS-SD mapping) - Peter: seconds this request for WG adoption, as well as DNS-SD mapping (Zach: short could be an appendix). - Carsten: asking for WG activity/feel about the draft. Reviewers: Akbar, Matthias, Floris. There seems to be good in-room consensus for adopting this document as WG work (after AD concurrence and validation on mailing list). *** Others? If time permits: draft-greevenbosch-core-profile-description-01 [39:20, 110] Objective: - Gauge interest by WG Bert Greevenbosch presents draft-greevenbosch-core-profile-description-01. - Zach: integration with web links (link format or any other web linking style) looks like a good idea, more general though it could be used with Carsten his json drafts; maybe use profile to signal capabilities of endpoint instead of separate resources? Might need a profile of both endpoints and resources? - Bert: this could be done by inheritance; separate resources might need different information. Zach: So you might need both endpoint and per-resource. - Zach: compare with json-home? Alot of similar work in the applications domain, think about overlap? We should probably do a review of this. - Bert: ...this is focused on CoAP... - Yusuke: I support this approach; need some out-of-band information for EXI encoders; JSON format requires a certain amount of code; link-format syntax is better for this. - Floris: JSON vs. link-format is a valid discussion. Might have to register new link attributes to be able to use link-format? - Zach: There actually isn't any requirement to register new link attributes, so you can make them up like in JSON; but a registry might not be a bad thing. link-format vs. JSON: Do this in web-links, so you can decide to do this as JSON or link-format. We might need a meta-link that allows inheritance. - Fairly good consensus that we should be working on something like this, not great surety that this is a good solution draft-greevenbosch-core-minimum-request-interval-00 [55:40, 118] Objective: - Gauge interest by WG Bert Greevenbosch presents draft-greevenbosch-core-minimum-request-interval-00. - Andrew McGregor: Is it intended to keep track of number of clients? Bert: The draft doesn't say how the server comes up with the values. Just some basic overload control. - Carsten: When I have an option like this, I wonder what value to put in there. Is this the right signal, then? - Zach: As an implementer I'd have a hard time what to do about this. - Carsten: total lifetime energy? Zach: is confused about the use case of this draft? Argues that observe is a viable alternative to rapid polling. --> Bert: says that main use of it was in block transfers. Option allows server to ask client to slow down. - Carsten: idea needs some more consideration/scoping. Take idea to the list to find out (more generic) problem space. draft-bormann-core-links-json [65:00, 123] Objective: - Gauge interest by WG Carsten quickly recaps the reasons for draft-bormann-core-links-json-02. - Kerry: relation to current RFC4627bis work? Carsten doesn't think there is a relation. This uses JSON as is. (We are assuming that there is never semantic information on the sequence of link-format attributes.) - Zach: thinks this should be standardized, maybe not necessarily in CoRE. - Carsten: calls for consensus. 5 have read a version of it. 5 think IETF should do it. 3 think document is a good start for this. 3 willing to review. - Matthias: not sure whether CoRE is the place to work on this in IETF. draft-bormann-core-ipsec-for-coap-00.txt [71:30, 125] Objective: - Discuss disposition by WG draft-bormann-core-ipsec-for-coap-00 - Carsten asks who has implementation experience with IPSEC? (No reply.) - Kerry: Usecase for IPSEC in coap except securing multicast transactions? Do we need more than 1 mandatory security mode? Carsten: IPSEC would be alternative for MTI DTLS. (There is some work going on to secure multicast with (D)TLS.) - Sye Loong: comment about DTLS for securing multicast, presented in TLS WG. However out of scope of that WG, unclear how to go forward. (Key mgt using CoAP could be worked on in CoRE.) - Jari: states that some aspects are missing from the current draft, entirely a placeholder -- some text on algorithms, but everything that is hard, like how to set it up, is missing. - Matthias asks for differences between IPSEC and DTLS. Suggests that LWIG might be the place for this document. - Andrew: cites other related work. [draft-moskowitz-hip-dex-00.txt] HIP diet exchange. - Carsten: currently no energy to complete this spec. Separately, Carsten asks about concensus about Sye Loongs's(?) DTLS multicast security draft draft-keoh-tls-multicast-security. 7 have read; 7 think IETF should work on it; 6 agree this draft is a good approach; 2 willing to review. draft-bormann-core-cross-reverse-convention-00.txt [79:30, 126] Objective: - Discuss disposition by WG draft-bormann-core-cross-reverse-convention-00: - Kerry: questions on square brackets yes/no. - Floris: useful to have a convention; but not convinced by one on slide. consensus: couple of people think a convention would useful. - Carsten: I think we can agree that the specific convention here is *not* a good start. - Akbar: topic already discussed in WG via HTTP/CoAP mapping draft. (Section "Embedded Mapping".) Question is: should we recommend a specific mapping, or not? 3 people think it's good to have a default mapping. Nobody opposes a default mapping. (a few potential re) draft-shelby-core-interfaces-03.txt [86:50, no slides] Objective: - Gauge interest by WG Carsten: this draft received solid attention. Zach says a couple sentences about draft-shelby-core-interfaces: - Zach: Give people some advice on how to design their REST interfaces. Draft is a design paradigm toolkit for constrained RESTful systems. most useful were linked-batch (for groupcomm) and 'binding' concept using weblinking. Informational draft. Consensus: 3 have read; 3 think IETF should work on it; 3 think current doc is a good start; 2 willing to review. draft-bormann-core-cocoa-00.txt [90:25] Objective: - Discuss potential further work in this space Congestion control topic & draft-bormann-cocoa-00: - Carsten: base spec does some congestion control, but not very efficient. This draft was a first shot at a more advanced scheme. Expired, likely other people will have much better ideas. (Question: Some 5 have read, 10 would like the IETF to work on this, 1 would not like to:) - Robby Simpson: argues one should use TCP if one wants advanced congestion control. ** Post-WGLC discussion (chairs, Zach Shelby) [92:50, 130] Objective: What else is needed to make Smart Object Networks work? What of this should the IETF do? What should the CoRE WG do? What should we try to fan out? What is next? Some documents to look at (just a selection): Bootstrapping security: draft-jennings-core-transitive-trust-enrollment-01 draft-sarikaya-core-secure-bootsolution-00 Data representation: draft-jennings-senml-10 Object security: (Is the JOSE work applicable? What do we need?) Last 30 minutes: discuss future direction of WG after finishing the three milestones (core coap, block and observe) Carsten tries to emulate an Agile Retrospective for the WG... - Carsten: what should we stop doing in this working group? Zach: stop adding features to CoAP and start building stuff on top of CoAP only add things to CoAP when we are out of all options. Carsten: presents findings of short brainstorm session [132] - Carsten: what should we continue to do/expand/do more than we have been doing? Akbar: interop events were useful and should continue that Andrew: I'm relatively new to CoRE: one of the most organized WGs, people have running code; try to keep on implementing as much as possible [133] - Carsten: what should we start doing? Matthias: push more into the Web world, start thinking about security model, try to push coap interfacing and this into html5? Carsten: [134] start new, short-lived WGs on specific topics? (Asks Bert to quickly report on his new short-span WG) Zach: multicast DTLS security? Cross-area WG? Barry(AD): highlights the idea of short lived WGs, thinks a cross-area WG is a good idea Carsten: Security: a) don't redo work that has already been done (ZigBee IP network and application keying), look at other scenarios. b) Define REST interfaces for doing security setup/initialization. Sye Loong: Tomorrow at LWIG WG, we'll present some experience. Carsten: Indeed, LWIG already has been doing some work on this. Maybe we should cooperate? (Kerry notes the LWIG/HOMENET conflict. Barry notes that WG scheduling is really hard.) Andrew: Also look at IEEE 802.15 cross-layer keying work (Bob Moskowitz). b) object security (in relation to proxies). We might be collecting some requirements, look at JOSE... Do the actual work elsewhere, maybe. - Re-chartering CoRE by Zach Shelby [111:10, 136] Zach: "Now that we have grown up, what do we want to do next?" - Congestion control: Carsten: The "use TCP" point gives an upper bound for what we might want to do here -- we want to do something simpler. Zach: need aggregate congestion control for entire 6lowpan, instead of end-to-end congestion control from TCP. This seems to be orthogonal from using TCP when you want congestion control. Robby: TCP *is* not a congestion control algorithm, but *has* them (more than one). Andrew: The IETF doesn't have much experience with aggregate congestion control. - New transports for CoAP: Carsten: we need well defined way on how to use CoAP over TCP for the use case of load-balancing in cloud-side backends talking to millions of servers Zach: ... and going through firewalls... Andrew: TCP Minion... - New support for Web links - General application layer solutions (e.g. resource directory, other work: mirror servers, general RESTful advice, ...) Carsten's closing remark: remember that the IETF last call is out for ietf-core-coap-14; find out whether there is still a need to submit comments! See you in Berlin.