CoRE @ IETF91 Chairs: Andrew Mcgregor Carsten Bormann Structured minutes: TO DO ______ Raw notes follow: Notes taken by (insert your name here): - Matthias Kovatsch - René Hummen - Andrew McGregor - Dominique Barthel also (browser crashed) - Michael Koster TUESDAY, November 11, 2014 1520-1720 Afternoon Session II Coral 2 APP *** core Constrained RESTful Environments WG ** Intro, Status etc. (3 min) 15:20-15:30 Intro Note-Well, Blue Sheets, Scribes, etc. Agenda bashing WG Status: - Published: RFC 7390 (was draft-ietf-core-groupcomm-25) - @IESG (AD evaluation): draft-ietf-core-observe-15 - Last Call to do: draft-ietf-core-block-16 - Charter work needed to resume draft-ietf-core-resource-directory - Milestones ** WG docs: HTTP-CoAP Mapping (Presenter: Akbar) 15:30-15:45 HTTP mapping draft-ietf-core-http-mapping-05 (15 min) - since IETF90, addressed Tickets #366, #375 and comment from Yusuke - Focus on reverse cross-proxy - Ticket #366 -> CoRE Link Format: By default no payload mapping; mapped Link Format could be provided at the proxy's /.well-known/core resource - Ticket #375 -> Diagnostic messages: ? - Comments: Transcoding might lose schema inlined in EXI/XML Q&A: Carsten: Link mapping is hard and not new Specific problem: Content-Type/-Encoding string vs Content-Format ID can become a problem when endpoints evolve but proxy does not Klaus has ongoing experiment where he automatically scans IANA registry and generates CF IDs; maybe IANA can do this in the future? What about new media types? 10000 media types already out there what do we do with them? Could define X-coap mappings Need a round on the mailing list to discuss this Running experiment to scal new mediatypes and build content-format registry Can we ask IANA to run a tool or maintain translations? Matthias: yes a mapping database would be useful (Background reading: draft-castellani-core-advanced-http-mapping-04 (0 min)) Objective: · Review solutions to Tickets #366, #375 and comment from Yusuke (check) · Are we ready for WGLC? (still some open issues(?)) Didn't I hear Carsten say "one more iteration on the mailing list"? ** not yet WG docs: Resource Directory (Presenter: Zach Shelby) 15:45-16:25 Resource Directory (ZS) draft-ietf-core-resource-directory-02* (40 min) -- this draft missed the deadline -- this draft is a WG document but outside the charter Objective: - Review -02 updates, in particular DNS-SD integration - DNS-SD mapping is done - several tickets closed - Hypercat hypermedia catalog use case by Koster - DDOS considerations added - need advanced examples from the WG like storing other types - Fixed registration update mechanism: Getting more RESTlike with link registration and update (refresh) - Binding EP names to certs - missing 4.04 responses added for missing resources - Change 63 byte EP name max to SHOULD in draft - Using POST instead of PUT for registration update/refresh and allowing link updates on refresh - Future work: Advanced examples will be contributed by Matthias, Peter - need >= 3 expert reviewers, at least one from OMA (Tim?) Q&A: Kepeng Li: EP identifier unique? Zach: For RD, EP name is bound to the security identifier; independent from IP, even protocol (HTTP/CoAP) Doesn't solve the problem of response coming from different protocol binding vs. request Kepeng: How to deal with conflicts? Zach: If you are authorized, identity belongs to you and all new registrations (not re-reg.) replace the existing registration without security, you can't even detect that multiple devices use same EP ID - Future work: Collection interface to manage the link collection (per endpoint registered) GET, add a link, replace a link, remove a link Could use the management location returned in the registration response as the collection resource Don't invent a PATCH mechanism for CoAP in this draft, stick to the goal at hand, collection of links (separate draft but try to avoid needing it) Matthias: Conflict error message 4.09 in OMA LWM2M, but recommend not define 4.09 in -rd Zach: way behind on IANA registration of codes, terms and media types Peter VanDerStok: How do we do this charter upgrade? Carsten: Create a new charter wait for tomorrow management meeting Bert Greevenbosch: Synchronization with OMA? they only implement part of RD Zach: this discussion is not part of that question OMA used an early version, put into LWM2M 1.x Zach: OMA spec diverges and defines a lot of stuff needed to be registered w/IANA for example urn:oma:XXXX Should help this along Akbar R: Recharter - include alt transports and other stuff Carsten: need to discuss before making the proposal. CoAP over TCP, SMS, other priorities Akbar: agree, we need to look at the overall set of for the recharter Tim Carey: Building OneM2M to OMA LWM2M interworking, may need to make sure there is backward compatible operation to not break this interworking Look closely at what the gaps are to insure a close integration. May need to take into account in this draft, change things if needed Mathias K: how many implementations already out there ? Zach: would say around 10. Mathias: not sure all correct, were some mistakes in 1.0, already into backward compatibility Zach: Bring comments to OMA Get all the input and do a full review Carsten: could have deprecated features Matthias: One implementation replaced links with PUT, which could recur if it's left in the spec as an option Discussion about compatibility issues. is it already in production? Zach states yes. Volunteers to review : Hannes T, Yong-Geun Hong, Matthias K., Bert G., Akbar R., Simon Lemay ** related: "ACE for resource directory" (presenter: Bert Greevenbosch) 16:25-16:45 Resource Directory (BG) draft-greevenbosch-ace-resource-directory-00 (20 min) Objective: - Discuss how security could work for the RD - Possibly derive input for ACE The draft considers issues with auth access to RD and distills Review of RD functionality registers links from resource servers Architecture slide showing registration and discovery RD is also a CoAP server and endpoints are client role Q&A: Zach: What is the problem we're trying to solve? There is already a way to authorize EP for registration ACE doesn't try to solve that problem Is it used to auth access after rd-lookup operation discovers resource? Zach: Is this solving the unsolved device-to-device resource access authorization problem after look-up in RD? Bert: generic problem is auth a coap client to a coap server, Ace solves this, could apply to RD operations as well as resources themselves Bert: ACE can do the authorization to register with an RD. Goal is to find out if ACE will work for RD as well. However, RD is not constrained and could do authentication on its on. Zach: Rd is a server but has some unique propertiesand may have a different auth Hannes: Thought RD would be treated as classic client/server interaction with an existing security relationship, would it first interact with Akbar: RD has unique properties, maybe like a search engine. Does everyone who wants to use it need authorization? Bert: Depends on the type of RD: open, public ones or closed, e.g. building-specific RD. ACE can help to define who may use the RD. Requirements 5-7 for registration including delegating clients REQ 8-10 for querying Rules and auth for part of the endpoint collection to be authorized to some clients, not others René Hummen: Is this still about registration or about look-up? Should ACE authorize queries to RD or be used to authorize device-to-device communication subsequent to look-up? Zach: Problem is that this problem is very generic. We need to understand how ACE works first. This could also be done with ACLs. Keep in mind that RDs can also support HTTP clients, which their own world ot authentication. For example, resources may be auth as a group in some enterprise envs Bert: ACE does not have a ready solution but we can start to figure out how it could work, basically as a use case. Zach: More important to figure out how (to authorize) accessing the resource will work after the look-up. Carsten: My fault that this was presented here (as it is an ACE use case), but this should be closely followed in this WG. Thinking about the different kinds of authorization that are required could help defining the RD itself. Need to think about this clearly and build a clear model of how auth works in these different situations around RD Zach: Yes, but a lot of this is implementation-specific (e.g., domain-based, endpoint-based). It goes too far to say "you MUST use this to implement RD." Keping Li: Interesting use case as a constrained client contacts an unconstrained resource server (so far not considered in ACE). Dave Robin: Interesting use case as ACE matures, say 2 devices need to communicate and have auth already, this RD should understand what they already negotiated through a separate entity and allow registration based on pre established trust Dave Robin: Interesting for registering devices that the RD has never seen before. E.g., via bearer token from ACE telling RD, "you can trust this device" Zach: Enterprise environments often have the need for AAA servers, but there are many solutions and it is a bit early to define something in this WG. Tim Carey: there needs to be some way an EP can say who can use it's resources and how, i.e. the authority may be with the EP The point is threat the framework for this ought to be in the draft. So implementations can use the framework. Zach: this could take 4 years to specify, could be a rat hole that takes a long time to sort out more sophisticated auth patterns and methods. Could for example specify use of ACLs that specify which clients can access a resource, but maybe not the discovery process itself. Should specify that RD is responsible for managing resource Access but maybe not it's own internal resources. Dave Robin: maybe the rathole can be shallow. Ex, one concept could be scope, could be obtained before attempting access as in Oauth2. THe RD could give auth hints about scope, realm, etc. that could prequalify a client. Zach: OK, but... RFC6690 has link extension that anyone could define, so it could be done in link relations Matthias: It's also about device identity framework for the RD registration interfaces (just pointers, not solutions) Carsten: Don't want to forward RD draft until these issues are resolved, need to understand basic reqs for RD auth before going forward ** WG docs: Links-JSON (Chairs) 16:45-16:47 Links-JSON (chairs) draft-ietf-core-links-json-02 (2 min) -- we tabled this waiting for implementation experience. Objective: - Are we there yet? Andrew: Is there any implementation experience. Zach: Some but not specifically with this version. Don't see any problems, since it is only a format. We have an implementation but uses a different mapping Bert:(missed the comment) Barry Leiba channeling David via Jabber: questions about what resource directory provides link quality, timeout Zach: timestamp? there is a timeout (Koster: lifetime) but not timestamps Carsten (hat off): Why is the content-format (ct) a string and not a number? is the only discussion we have ever had about this. Can we have a last call? Hum in favor ** WG docs: Core-Interfaces (chairs) 16:47-16:49 Core-Interfaces (chairs) draft-ietf-core-interfaces-01 (2 min) -- this draft is expired -- reason? Objective: - Status check Carsten: What is needed? is it stable or does it need updating? Zach: Lower priority draft, needs a little more work. LWM2M URI template should be added as an alt resource design, removing pmin, pmax Carsten: who would review (5 incl. Carsten) who would edit? Koster would add OMW LWM2M template Zach low priority but things keep coming up Carsten: not discarding, not accelerating, want to see an improvement ** Alternative Transports (Hannes Tschofenig) (due to OAuth conflict on Wednesday) 16:49-17:04 draft-fossati-dtls-over-gsm-sms (15 min) Hannes: Use case is secure CoAP messaging over SMS in M2M deployments (requirement for end-to-end security pointed out in STIR WG) Challenges are latency and fragmentation (140 Byte payload size) losing one TPDU requires retransmission of all in the flight. Timers need to be properly set, too short breaks and too long adds latency Work in progress: PSK works with 4-6 T-PDUs (one per flight), X.509 rarely works, takes minutes when it does Need feedback where this work would fit best. It is not changing DTLS, only guidance. Carsten: Good, needed work. Should be done in DICE. How does CoRE represent the fact that DTLS is used over SMS -- UI design! Kepeng: CoAP-over-SMS solves security as well (should go in there)? Best align this work ?: Why does X.509 rarely complete? Transmission or computation time? Hannes: No problem of computation. Transmission timers need to be cranked up, which creates the minutes delay. It seems to be the result of losing TPDUs and having to retransmit flights Derek Atkins: Have you considered OpenPGP? Hannes: ? ...caching... problem is that 20 SMS are needed for a handshake Akbar: What did the test do? SIM enabled? Hannes: Sending from device to server, SIM card enabled Andrew McG (co-chair hat off): X.509 Latency is not fatal, not completing is. Can it be fixed through better timer settings? Hannes: Yes... Good thing is that once the process completes, the result is cached and can be reused for resumption. PSK works fine, X.509 didn't, PGP may be a good solution ** CoAP-PubSub (Michael Koster) 17:04-17:20 draft-koster-core-coap-pubsub-00 Moved to Wednesday: did not fit in the session time. WEDNESDAY, November 12, 2014 0900-1130 Morning Session I Kahili 1/2 APP *** core Constrained RESTful Environments WG ** Intro (3 min) 09:00-09:03 ** 6TiSCH network management with CoAP (Thomas Watteyne) Thomas provides quick intro to 6TiSCH. Communication between meshed nodes occurs using a time/frequency schedule. This scheduling needs to be installed in the network. There usually is a PCE that computes the schedule and needs to talk to each node to install it. We want to use a REST interface, CoAP seems like a good choice. We want the nodes to report on changing link quality of other event, so restore will be convenient. Not everybody should be allowed to mess with the schedule, so ACE is of interest too. One 6Tisch describes the features that need to be managed. Another draft describes the resource structure. Right now have defined our own structure (using /6t path root), but might use something already standardized elsewhere if appropriate. Seeking advice on that. Zach: The resource design here is like what was recommended in coap-resources, for ad-hoc. Where that doesn't work is for widespread interoperability; in that case you need a very well-understood format, because this will have to tie into network management systems, etc. Leaves two options: comi, or OMA object formats. Thomas: For sure, we'll look into this, we were doing this because comi wasn't ready. ** CoRE Management: CoMI (Presenter: Peter Vanderstok) 09:02-09:45 CoMI (PV) draft-vanderstok-core-comi-05 Objective: - Is this starting to be viable? - Decide on way forward - use CoAP for management instead of SNMP to save on stack size for devices already implementing CoAP - replace from XML/EXI to JSON/CBOR (done last IETF) - automated tranlation from SMI/YANG to RESTconf possible - alignment with RESTconf - Security via DTLS Ari: relationship between CoMI and OMA Lightweight? Zach: OMA Lightweight about device management not for network management. Different purpose. Tim: Concern -> need for two agents (device and network management). However, main difference only in resources. Zach: Very similar. Much code overlap for the two agents. Similar encoding, security, etc. Ari: subtle differences. Make them explicit in the draft! Carsten: Need for modularity to cater to different scenarios. - Designed for small resource names (hash of name string to number) -> descriptions can be retrieved via /Moduri indirection - Possibility to only query sub-hierarchies in YANG module - Rehashing with different prefix in case of hash collision for different resources on same device -> notify client about added prefix during discovery Zach: Don't try to support all encoding schemes possible. - Discovery via /.well-known/core Carsten: Need to extend charter to take on CoMI. Who has read? -> 12 Who wants to review? -> 8 Who wants to implement? -> 6 Against? -> None => Consider draft in next charter update 6TiSCH-CoAP informal meeting in Rainbow 3pm this afternoon. ** Alternative Transports, continued 09:45-10:15 draft-silverajan-core-coap-alternative-transports-06 draft-savolainen-core-coap-websockets-02 draft-bormann-core-coap-tcp-01 draft-tschofenig-core-coap-tcp-tls-01 draft-becker-core-coap-sms-gprs-05 Objective: - Decision making on TCP bikesheds - Decide on way forward Carsten presents the connection model, CoAP over TCP. one assumption is that "observe" will only work over one same TCP connection. Zach: might be an issue to rely on a connection staying open for days/weeks, pretty much renders this useless. Carsten: ok, maybe negotiate first TCP connection, and have connection identifier that re-identifies the CoAP session for subsequent TCP connections. Zach: actually TLS session might help. Numbers of ways to do delimiting. But implementers comfortable with fixed length. Efficient, makes delimiting independent from parsing. Discussed length of Length field. Picked 2 bytes, like UDP. Zach: is 64KiB enough for everyone? What about 256KiB Flash device and need to do firmware update? Carsten/Zach: why not do block transfer? Does not want to. Andrew: what are the practical use cases right now? block solves the pb for extra uses Carsten: Agrees that more discussion is required for length field size. Using CoAP over UDP, just want to do the same thing over TCP. Take home point. Last discussion was how to handle 4-byte header. No more there. Saves 2 bits in bit filed. 2 bits could be used to indicate 4-byte vs. 2-byte length field. Two options for message encoding are shown. Could not come up with convincing argument for either one over the other. Zach: no strong opinion, but option b might confuse people. It "feels like CoAP" but isn't CoAP. Carsten: sounds like pretty good argument for option a. Rendez-vous, URI: uri protocol would be coap+tcp, opinion?. On TLS, uri would be coaps+tcp, not coap+tls. Keep in mind TCP connections fully pipelined, implementation has to handle the case of multiple requests in flight. René: Close connection instead of RST in case of error would have the same semantics as closing a TCP connection for long-term CoAP connections. Next step is to write this up and get feedback on the mailing list. Since we had this discussion multiple times, we should be able to fast-track this. Remote presentation from Teemu/Bill (coap-alternative transports) handled by Carsten Globally all other transports. Agreed on coap+xxx// format. Not a standards track document, merely informational for people inside the WG working on alternative transport for CoAP. Who has read a recent version? 2. Of which, who thinks ready for adoption? no hand Who willing to review? 5 people (but I don't know them by name) Kepeng : need to add to the charter first, like CoMI? Carsten objects, thinks it's in the charter. Zach: opinion that CoAP/transport is in charter. Carsten: ok, will do charter check. Andrew: TCP is in charter, not sure about others. Barry: I think you can consider other transports in charter, nobody is going to argue. Carsten: will now ask for adoption on mailing list and proceed Kepeng CoAP/SMS presents changes from -03. asks for adoption Carsten: who wants this at all? do we have the parts to glue this together? Carsten: would like that DTLS over SMS and CoAP over SMS use similar mechanisms. Have you had discussion with Hannes? Kepeng: Not yet. Zach: we need a binding in the spec. Because OMA does this, we need a document that describes it. Carsten: seems best thing would be to research this a little more. SMS expertise concentrated in this WG, nice. Work closely with DICE. Zach (DICE chair): DICE not chartered to do this. Carsten: could do the encoding here, and profile in DICE. Zach: could be acceptable to specify a profile saying don't use X.509 because it will never finish. (René: Talked to Hannes after DICE meeting. X.509 most probably didn't finish because of inappropriate timer values. Could potentially be fixed. Needs further investigation.) Carsten: WGLC went out yesterday at DICE. Catch it. Before WG adoption here, need to define profile work in DICE. ** Avoiding responses to POST and PUT (Presenter: Abhijan Bhattacharyya) 10:15-10:25 No-Response (AB) draft-tcs-coap-no-response-option-07 Objectives: · With the modifications in the most recent draft, is the proposed option now the right way to solve the problem(s)? - no new technical comments since Toronto meeting - resolved token-reuse issue Carsten: Who has read? 2 Who wants to review in WGLC? 2 ** endpoint IDs (Presenter: Oliver Kleine) 10:25-10:45 draft-kleine-core-coap-endpoint-id-01 draft-li-core-coap-node-id-option-01 - problem: update notifications to observation request cannot be correlated if server IP address has changed - especially problematic for multicast Akbar: so far not possible to combine observe with multicast Ari: would DTLS help? Oliver: NoSec mode used. Zach: Safe to assume that security is used in a real-world scenario. CoAP explicitly recommends DTLS with raw public keys. You can assume existence of cryptographic binding. Oliver: Use case -> tracking of postal package does not require security. Kepeng: But there is NoSec mode. Zach: NoSec mode is isolated scenarios with L2 sec. Ari: Only applicable to NoSec scenarios? Oliver: Yes. - presents stateless as well as stateful solutions (introduce stable end-point ID) Carsten: What happens if client ID changes? Especially, if both client and server change their IP address simultaneously (e.g., network renumbering) Oliver: Solution focuses only on server IP changes. draft-hong-core-coap-endpoint-unit-id-01 (presenter: Yong-Geun Hong) - didn't really get it. ?enable querying of multiple resources in one CoAP message? Carsten: Who has read any of the end-point drafts? 8 Who willing to review? 6 ** patience (Kepeng Li) 10:45-10:55 draft-li-core-coap-patience-option-05 - presents patience option Carsten: Read? 4 Review in WGLC? (Didn't hear) Need this? 5 Carsten: What are the use cases? ?: Would like to see use cases as well. No time information available. Kepeng: Already some considerations in the draft. ** CoAP Congestion Control (Presenter: Carles Gomez) 10:55-11:15 draft-bormann-core-cocoa-02 (20 min) Objective: · Discuss additional measurements · Gauge progress - presents experiment results of different RTO mechanisms for GPRS links - CoCoA now publicly available for Californium Matthias: You can try different RTO mechanisms in Californium. - back to experiments Carsten: important question for CC: does it break anything? Ari: where are clients in eval scenarios? Carles: behind GPRS link. Ari: More complex if mixed scenario (also more CoAP end-points on Ethernet network). Needs further investigation. - shows that all algorithms improve RTO in uncongested scenario compared to default CoAP and similarly increase RTO in case of congestions - Results - CoCoA typically improves on default CoAP - too simplistic RTT-based approaches underperform - TCP-oriented RTO approaches also outperform default CoAP - CoCoA performs similar if slightly better than TCP-oriented RTO approaches - Call for implementation and evaluation + feedback for IETF 92 Zach: Important to get timeouts right. also across different transports. Zach: how about constrained routers? server load? e.g. LWM2M servers? how much better is this wrt standard CoAP. Zach: supportive of this work. This is something this WG needs to do. Ari: Important work. What about mixed scenarios with CoCoA and default CoAP? Carles: Not yet considered. Ari: What about footprint and run-time memory consumption of the different solutions? Carles: will send implementation info (mem footprint, ...) to the mailing list. Kepeng: in last IETF, some transport experts recommended to look at existing work. How is this reflected in your draft? Carles: this RTO algorithms response to these comments. Evaluated Linux ROT and Peak Hopper wrt Basic RTO. They are considered state of the art. Cocoa is performing at least as well as these. Carles: At next IETF, will show similar results for 15.4 multi-hop networks, if possible. Carsten: let's do the measurements and come back. Carsten: Clarification -> Other algorithms will not be included in the draft as they seemingly do not bring any extra benefit over CoCoA to the table. ** CoAP PubSub (Michael Koster) used to be CoAP-MQ. support for battery powered nodes, sleepy nodes, etc. Work in progress is to simplify and clarify document. uses Resource Directory to register PubSub endpoints, new attributes. Topic creation is separate from endpoint registration. Next steps: update draft to reflect consensus on the changes, work on security model and considerations. Carsten: Read: (Carsten didn't say)I saw maybe 8-10 Review: 6 Against: 0 ?: Where is sleeping information kept? Michael: Not stored anywhere. Maybe need to be managed. Probably in the RD. Carsten: don't want to enter into discussion of sleepy node mechanism again here. Bring this to the mailing list. ?: terminology conflict. Producer/Consumer, not PubSub Tim: Allow for topics? Michael: topic are registered at endpoints (René: thought he said that registration of topics was unclear how to do) ** Flextime 11:15-11:30 Flextime · Open Mike Carsten: CoRE WG backlog? Zach: compiled backlog list in wiki. Weights (level of interest to WG) and goals (time to IESG). Some of this is obvious, like some WG documents. Next, CoAP/TCP and RD, even though not WG documents. Comi, JSON, senml need work. co-authors of senml too busy, would need co-authors No point in adding other low priority items to the list, there are already many. What do people think? Is this useful? Other way of doing it? Then we can talk about content. Akbar: I find it useful, but no single team, different team. Works with that as well? Zach: We have WG. So believes could work. Ari: Good to make priorities explicit. Roughly agrees with the current items. Zach: This is just a brain exercise. No commitment. Matthias: good .. to get running code... implementation experience... (how does this relates to backlog ????) Kepeng: Add a generic "options" draft as low priority item. Carsten: Zach: we are now at the deployment phase. Multiple implementations needed. High priority items should be deployed or at the verge of being deployed. We don't need to wait for this to become RFC to implement. Zahch: will see how to maintain this list. Help from the WG chairs? Carsten: no official tool for the WG chair, but useful. Carsten: Backlog is useful thing to have, but not binding as initiated by chairs (at this point?). Still, good to have for overview. 11:36 adjourns