CoRE WG IETF 85 Notetakers: Dominique Barthel, Zach Shelby -- thanks! From these notes, compiled by Carsten Bormann TUESDAY, November 6, 2012 Please also consult the audio recording: http://www.ietf.org/audio/ietf85/ietf85-grandballroomc-20121106-1300-pm1.mp3 1300-1500 Afternoon Session I Grand C APP *** core Constrained RESTful Environments WG ** Intro, Status etc. (10 min) Note-Well, Blue Sheets, Scribes, etc. Carsten profusely thanks outgoing co-chair, Cullen Jennings, and welcomes new one, Andrew McGregor. WG Status: - RFC 6690 Published. - Milestones Document status: Constrained security bootstrapping in on hold, we need to find what we want to do with that. Several WGs (ROLL, 6lowpan, CoRE, ...) have dangling secure bootstrapping issues, initial plan to collect those in one place. See Solace mailing list. Terminology that we want to make common to constrained devices/networks cluster is currently in lwig-guidance, will be pulled out into a separate doc. coap-12: following Vancouver, changed option number interpretation, led to the Great Renumbering. observe-07: Still needs to clarify optimism about observe relationships. block-10: Initiative issue to solve. Overview of tickets. Around 2/3 done; 1/3 still tbd. Other info about technical status: ETSI plugfest at 28-30 November (Zach) Open for all with CoAP implementations Expect 20 implementations. Scope wider than last time. Additions include IPSO application framework, security issues, proxy caching. Basic implementations are welcome too. - Work in waithood: draft-becker-core-coap-sms-gprs ** wglc-processing (110 min) draft-ietf-core-coap-12 Objectives: - close remaining issues from 1st WGLC - identify issues in the way before 2nd WGLC Zach reviews the tickets issued. If you have a comment, reply to the ticket mail, the tool will keep track of your comment, makes editors' job easier. -10 and -11 are not drafts for implementation any longer, -12 is the one to update your implementation to. Goal is to ship -13 in December. Tickets closed in -12: - Option masking for proxies, caused renumbering and incompatibility - Jump mechanism (enable larger option numbers) - IANA option number registry - Basic congestion control Planned to close in -13: - Security issues - Proxy MUST implement ... - Multicast - HTTP-CoAP - SHOULDs Multicast IANA allocation: Cullen: Internet Control Block is too big, Local Network Control is too small. If too big, can be blocked at firewall. Zach: there is Ad-Hoc Control Block, but meaning not well understood. Cullen: we have use cases bigger than Local Network. Zach: action is to check with IANA about adhoc blocks, but who will manage them? #255: quoted sentence on slide (from the draft) is not what we want to do that. Will be removed. Cullen: Zach: IP address is unstable. Cullen: DNS is the stable reference. The change you want to do amounts to adding DNS. Cullen: need mapping between Authoritative part of the URI and the identifier we want to use. Cullen: agree that this sentence is wrong, but we need to have a big discussion about this. Carsten: security is not one thing. Depends on whom you are talking to. Big problem today in the Web, Security is one bit! Authority part is not necessarily a good indication of who you talk to. Carsten: document out-of-band info that is needed. Cullen: no. Basic security requirements, including Authentication. What does out-of-band mean? Zach: we could define a few Authority names and mapping. Tom Herbst: don't assume we don't have DNS, some systems do. Don't fix DTLS in CoAP. Zach: Robert Cragie: certificate / public key uniquely identifies device. Zach: cases where static addresses could be used (servers). Serial number, app identifier. Salvatore: effort to change/review URI spec (?). Please come to IRI meeting in the last session today. Zach: Summary that we should support the following in Authority Name - Domain Name, IP Address, Public Key Identity (NI), Application Specific Identifier (a string) IANA policy: Carsten: several objectives. Avoid immediate depletion. That's why we have created high barriers around allocating some blocks of codes/numbers. We encourage people to use the same numbers for the same things. Third objective is to have an easy process. Carsten: would be good to carve out an Experimental space in the Option number space. Cullen: make 25% of Option numbers and Content Format reserved just in case. Allocate only one or two Content Format as Experimental. Zach: suggest to make 256 Experimental, both for Option Number and Content Format. Carsten: Take Option masking into account for experimental. *** the content-format issue (Presenters: Carsten Bormann (1), Yusuke Doi (2/3)) draft-doi-core-parameter-option (10 min) Objectives: 1) sanity check: Is what we are doing with Content-Format (coap-12's name for what was Content-Type earlier) the right thing for the majority of CoAP applications? 2) requirements: What are the applications we can't cover with Content-Format? What use-cases are behind them? 3) solution: is draft-doi-core-parameter-option the right solution for these (some of these) use-cases? Yusuke DOI, Content Parameter Option. Exposes 5 possible choices. Zach: doesn't recommend to put in the base spec now. Hope Option 1 does not indeed preclude from using EXI. If only 5 versions, reserve the numbers. Other applications that require this? Only for versions? Other parameters? Yusuke: chicken-egg problem. If good mechanism available, will allow applications to use it. Not just version numbers Carsten: several levels. Made decision couple of years ago we could enumerate content type. Increased to 16 bit. Then opened up IANA registration mechanism. Problem already solved for a handful of option by making registration open. Wouldn't work for video codecs, however. In summary, believe we have solved problem for the time being, and have a path forward for future extension. Kerry Lynn: support this work, carry forward. EXI is going to be used Carsten: your projection of number of version of schemas? hundreds, tens, one? Kerry: Cullen: EXI is important. Number of versions is going to be more than a handful. Devise option now. Default is Option 5 (in Yusuke's list). Robert Cragie: support this work. Can't underestimate complexity of EXI versions. Zach: others uses for EXI? First time I've seen this level of complexity. Most simple applications of EXI a single schema. Robert Cragie: maybe right. However, potential complexity in versioning, might as well handle as well. Carsten: signal that this is interesting work, but not getting signal that we wan't to change the base spec. Back to: draft-ietf-core-block-10 draft-ietf-core-observe-07 Carsten: Block and Observe tickets Who has implemented Block? a handful. Problems? Matthias: constrained implementation: random order makes it difficult at receive end. Kepeng Li: seem to remember we have decided in the past to move Pledge to a different draft. *** Groupcomm (Presenter - Akbar Rahman) draft-ietf-core-groupcom-03 (9 min) (Background reading: draft-dijk-core-groupcomm-misc-02 (0 min)) Objectives: - Review updates to address tickets #251, #250, #249, #248, #186, and summary of other changes - Request 3 volunteer reviewers to prepare document for WGLC Akbar on Groupcomm tickets. There are 4 volunteers to review this draft. (Time's up, continue on Friday.) Salvatore: will read sleep and proxy drafts in preparation to Friday's meeting --------------------------------- FRIDAY, November 9, 2012 Please also consult the audio recordings: http://www.ietf.org/audio/ietf85/ietf85-salone-20121109-1120-am1.mp3 http://www.ietf.org/audio/ietf85/ietf85-salone-20121109-1230-pm1.mp3 1120-1330 Afternoon Session I/II Salon E APP *** core Constrained RESTful Environments WG *** COMAN (Presenter -- Mehmet Ersü) (5 min) Background reading: draft-ersue-constrained-mgmt, draft-schoenw-6lowpan-mib mailing list: coman@ietf.org Announcement from Mehmet Ersue: New activity in COMAN about requirements, expert reviews welcome. New terminology draft. Discussion on coman@ietf.org. *** Groupcomm (Presenter - Akbar Rahman) draft-ietf-core-groupcom-03 (9 min) (Background reading: draft-dijk-core-groupcomm-misc-02 (0 min)) Objectives: - Review updates to address tickets #251, #250, #249, #248, #186, and summary of other changes - Request 3 volunteer reviewers to prepare document for WGLC Akbar, core-groupcom-03: Light use case example for IP multicast. All lights join the group via MLD Report, switch turns on lights through proxy, which sends multicast. Problem: One light fails with 5.00, but cannot be identified from the responses alone. Zach: Why not send multicast directly from the light switch? Akbar: DNS needs only be supported at the proxy Zach: Two models with different (dis)advantages, choose what fits best Carsten: Good example to reveal gap in main spec; DNS name even hides that it is a multicast; the proxy also does not know when last response might arrive. Carsten: Watch terminology; Sye Loong has draft for NoSec multicast issue in TLS. Cullen: Look at SIP for how NOT to solve the problem. ??: What happens when packets are dropped? Akbar: Light will not be switched, but this is not a protocol error Andrew: Akbar: Collect reviews on the mailing list ** companion drafts to the WG drafts: *** HTTP-CoAP Mapping (Presenter - Salvatore Loreto) draft-castellani-core-http-mapping-06 (15 min) (Background reading: draft-castellani-core-advanced-http-mapping-00 (0 min)) Objectives: - Review summary of updates from Peter Van Der Stok's review, and summary of other changes - Define next steps for the document Salvatore, core-http-mapping-06: Comments on draft mainly by Peter Van der Stok The goals are giving guidelines but also create proxy interoperability. Security translation is still a problem, especially with multicast. Cross-proxy recommended to be placed close to the LoWPAN as reverse proxy. The response code mapping will still be extended. Should the draft be adopted by the WG as informational? Carsten asked who implemented a CoAP-HTTP proxy. Some hands went up. Afterwards Carsten asked who have used the draft for it, less hands went up. (More hands would be strange. :-) ) Cullen: Passing a CoAP URI through the HTTP system does not work. Carsten: Reverse proxies are feasible, forward proxies more complex. The problem is the expectation to the proxy. Zach: Narrow it down instead of exploring every option. Table 1 (where to place the proxy) must be cleaned up, if included at all as it depends on the application. TCP/UDP performance claim should be removed. Carsten: We have to agree on how to pass the CoAP URI in the HTTP request. Carsten: Request for adoption should be sent to the chairs. *** Congestion Control (Presenter: Carsten Bormann) draft-bormann-core-cocoa (5 min) (background reading: draft-bormann-core-congestion-control (0 min)) discussion (10 min) Objectives: - Check whether we are on the right track with keeping only basic congestion control in the base spec and doing something like this as one or more separate specs. - Get some initial feedback on this specific spec. Carsten: Congestion issues coap-12 allows only 1 outstanding exchange with binary exponential backoff What advanced CC schemes are there? bormann-cocoa-00: Combine BEBO with RTO, did not work right in first implementations though. Carsten asserts that it should be possible to make it work, as the client receives the same data as a TCP client would. Lars: Continue evaluating to find something that prevents overload and provides some kind of fairness. Andrew: It is clear that CoAP does provide enough information to provide a decent CC, but this doesn't demonstrate that this is done; need one algorithm that works. Lars: 1) avoid network overload; 2) get some sort of "fairness", minimal goal that one doesn't just starve the other. Carsten: Optimize with different advanced schemes. Lars: Different schemes should still work together. Carsten: Issues in base draft are addressed. Review needed. Gorry Fairhurst: I'm not on CORE list but will do a review. *** CoRE Roadmap (Presenter: Carsten Bormann) draft-bormann-core-roadmap (5 min) Objectives: - is this useful? - what can be improved? Carsten: Roadmap gives overview to the many individual drafts Also used for corrections and clarifiations. Gorry: What will be the endpoint of this document? Barry: Maybe convert into wiki page. Carsten: One goal was to describe in a similar way, which is hard in a wiki. Barry: Use wiki only as input for the document. ** new work: *** SOLACE (Presenter -- Carsten Bormann) (10 min) Background reading: draft-garcia-core-security, draft-jennings-core-transitive-trust-enrollment, draft-sarikaya-core-sbootstrapping mailing list: solace@ietf.org Objectives: - see "activities" above, and: - what is the WG position on the milestone "Constrained security bootstrapping specification submitted to IESG"? Carsten: SOLACE 1/4 were at SAAG meeting. We need to solve key management to authenticate, authorize, etc. How to put security objectives of applications into the system? Define an architecture for common terminology and technology pieces. Start this work in the IRTF as it was bounced around IETF WGs for half a decade now. Cullen: Respect the CoRE charter about this work. The charter includes development of secure bootstrapping applicable to all nodes. Zach: We went for public keys which vendors are happy with. Cullen: The whole lifecycle is still not addressed. Carsten: Collect contributions that fully spec out the lifecycle and then extract. Cullen: We should do this work in CoRE not in IRTF and we had solutions in the workshop. Andrew: Consider what happened with HIP. Cullen: We have to pick one. Zach: Define the problem we need to solve better. What can we do? Maybe write a document that scopes the problem? Robert: We need an architecture and CoRE is not the right place, as we miss a lot. Hannes: Agrees with Cullen, but you cannot simply pick one solution in constrained environments and there is no single architecture. Carsten: Let us do the SOLACE work, but do not stop in CoRE. Submit proposals. Alper Yegin: Also have a look at the ETSI M2M spec. Cullen: Do the engineering work here so vendors can build devices. Robert: There should be no dependency to SOLACE. *** Sleepy Devices - Problem Statement (Presenter - Salvatore Loreto) draft-rahman-core-sleepy-problem-statement-01 (15 min) Objectives: - Review proposed characteristics of sleepy nodes and objectives for CoAP protocol design and get WG feedback Salvatore: Sleepy devices problem statement Sleeping End Points can cut the power to unneeded subsystems, but also have reduced CoAP protocol operation. Resources should still be available although devices are sleeping. This needs secure delegation while retaining ownership. Kostas Pentikousis: This is interesting; I'm interested in reviewing this. Client-server model is still very much applicable for intermittent presence with the right implementation. Gorry: Is there light vs deep sleep? Kostas: It is not that binary. Hannes: There is very little we can do in the IETF as many features are in hardware. Lars: Was sleeping not core to CoRE? Sleeping has also impact on the network. Carsten: Some devices can abstract away sleeping, others cannot. We need features for the latter. Robert: There should not be any changes to the protocols. Andrew: We would need an active observe on resources of sleepy devices. Proxies can play an important role here. Lars: Sleeping not different from other cases where a node disappears. Matthias: No need to care about radio-duty-cycled devices, they abstract away their sleepiness. "Real" sleepy devices need active support by additional features. *** Enhanced Sleepy Node Support (Presenter - Akbar Rahman) draft-rahman-core-sleepy-01 (5 min) Objectives: - Get initial feedback from WG on pros/cons of this solution approach Akbar: RD-based Sleep Tracking Lars: Over-engineered as other unreachable cases already have to be covered. Carsten: A first in this WG: There is IPR on this. Akbar has declared it and has handled this by the book. Robert: Sleepy devices are also often asynchronous. Lars: The resources are mostly cached. This is only required for unpopular resources that are not in the cache yet. Akbar: How should we continue? Lars: Drafts are good, the more real-life (simulated, running code) the better. Time is up.