2010-08-15 CoRE Webex meeting nominally 15-17 UTC (with some Webex glitches, running later) Chairs: Cullen Jennings and Carsten Bormann Recording massaged into minutes by Carsten Bormann. Agenda (all times are nominal UTC) 15:00 Webex wrangling, Agenda, Status 15:10 1 – core CoAP ZS 15:20 1 – Subscription option (-observe) KH 15:25 1 – Block option (-block) CB 15:35 1 – coap-misc CB 15:55 1 – Sleeping Nodes AR 16:10 2 – Bootstrap approach BS 16:25 1/2 – CoAP Usage PV 16:40 Planning 17:00 End of call At 15:55, people on the conference call were: Carsten Bormann (CB), Akbar Rahman (AR), Angelo Castellani (AC), Behcet Sarikaya (BS), Colin O'Flynn (CO), Dale Seed (DSe), Don Sturek (DSt), Edward Hill (EH), Gilman Tolle (GT), Guang Lu (GL), Jonathan Hui (JH), Kerry Lynn (KL), Klaus Hartke (KH), Markus Becker (MB), Paul Duffy (PD), Peter Bigot (PB), Ralph Droms (RD), Rene Struik (RS), Robert Moskowitz (RGM), Zach Shelby (ZS), Cullen Jennings (CJ) --------------------------------- Slides are at: http://www.ietf.org/proceedings/78/slides/core-1.pdf (Times are nominal UCT:) 15:00 Webex wrangling, Agenda, Status CB welcomes the participants and introduces the agenda (slides 1-5). 15:10 1 – core CoAP ZS While ZS fights with Webex, CB starts introducing the tickets (slide 8). ZS takes over: #6 -- we don't really have a date option, so let's drop that. #18, #19 just some improvements on the text (see ML) #20 -- virtual server capability, little controversy #21 -- ZS to work with Mark Nottingham (who was nice enough to volunteer to help) to write that #22 -- work needed, input expected from RS #23 -- virtual server capability: needs discussion (w/ CB, Peter(?)); accommodate that without forcing all devices to have that capability #24 -- needs discussion; CB suggested solution; finish this on the list. ZS: Summary: We need to work on security, and fix the Uri-Authority. Asks for comments -- none. (Slide 9): ZS: divide functions between core coap (coap-02) and block, observe. Maastricht also had discussion about link-format; Mark suggested to define that as a MIME-type in a separate draft. Makes sense to separate that out as well. Asks for comments and concerns. CB: Summary: Split, and for each of the new documents we'll need to decide whether these become WG documents. Asks for comments about the number of documents. RD: What is the concern -- too many, too few? CB: Avoid a SIP-like situation with hundreds of documents. Separate out things that might change on different time scales. 15:20 1 – Subscription option (-observe) KH (Slides 10...20, not discussed in detail) CB: draft-hartke-coap-observe resubmitted yesterday; cut it down to half the size by removing rationale that probably was excessive. Ready for adoption as WG document? KL: Curious whether there is time pressure to do that now? CB: What do we gain by deferring? KL: More time to digest. CB: We'll verify on the mailing list anyway? KL: So here we decide what to ask online? CB: All decisions in a meeting need to be verified on the ML. CJ: So, should we ask on the ML, should we adopt it? AR: I'm in favor, I think it is ready. ZS: I definitely think is is ready for WG document, some work needs to be done, good start. CJ: Who wants to do substantial work on this document? -> A few people in favor, no objections. Take it to the list. 15:25 1 – Block option (-block) CB (Slides 21...24, not discussed in detail) CB: The other document that was split off: draft-bormann-core-coap-block. More or less required for larger items. We have some interop results. Critical option. No other proposals how to solve this. KL: Concern, not sure whether that is addressed: Non-idempotent requests such as POST; cf. Appletalk Transaction Protocol; I didn't get the promised draft done. CB: More difficult to do for POST; if you want to do a POST, you have to reassemble the whole representation before atomically acting on that; no way around that; needs Token option to disambiguate multiple concurrent POST transactions. The final interaction triggers the non-idempotent work. KL: You would also need to understand at the server end whether the reply is lost, the client would need to retry, and the transaction layer would need to respond with the same reply (and not pass the request to the application layer again). CB: Matter of implementation, but there is a transaction ID to make sure you are not executing the request twice. KL: So my question is: If we want to implement a RESTful protocol; it seems to be necessary for POST to support non-idempotent operations; include that in the main document. CB: This may be a comment on the core document; this may need more text on non-idempotent operations; little intersection with -block. ZS: Kerry, we do need more text in the main document, let's fix that in coap-02. KL: If we have options at the transaction layer; do we have multiple options or do we fit everything into into one? CB: ??? KL: Could support non-idempotent operations by adding a bit; seems wasteful. CB: We have a request code that tells you PUT/POST/GET, so you already know whether this is idempotent. ??: Slightly different option than we had before. KL: Yes CB: Did not see a need to separate out these options; all options are different in some way; that one dimension of difference is maybe not more interesting than the other ones. KL: I'll try to get a draft out, for three issues at the transaction layer: 1) larger than MTU 2) idempotent vs. non-idempotent 3) adjustment of transaction timers CJ: Thanks. When? KL: By Monday. 15:35 1 – coap-misc CB (Time is running late: 3645) CB: coap-misc is next on the agenda. Maybe it is worth discussing KL's point first before we go into details of coap-misc. CB: Except for one: (Introduces proposed Duration Type, slide 27). Feedback from implementers that it may be too complicated, so I provided code that shows it is not complicated at all. PB: Anti-complexity: Not closed under subtraction; the value I get may not be correct. A simple integer is more correct. CB: You still have to round to one second. PB: I'm not concerned with a second; but with the larger rounding errors. CB: Do you have an example where that matters? PB: 0xCF and 0xDF have a two-hour time difference. CB: Round down? PB: Repeatedly asking rounds down each time? CB: You wouldn't do that again on every request -- this is a wire format, not the internal representation. PB: If I ask again, I lose 6 hours. CB: This is for life-times etc., you never will squeeze out the last second. The imprecision is -12.5 %. PB: Variable length integer should be straightforward. CB: Agreed, not much more code. Let's discuss this on the list. (Slide 29..32 not discussed in detail) CB: Some more options in coap-misc that are for the taking if they are needed. Let's move on. 15:55 1 – Sleeping Nodes AR (Slide 34) AR: (Slide 35): Three requirements: Req 3, sleeping nodes; Req 4: caching for sleeping nodes; Req 9: multicast Some more work needs to be done. (Slide 36): use-case with a sleeping node 1; node 1 and proxy will need to exchange sleep schedule. If node 1 asks for data from node 2 (proxied via HTTP), node 1 may sleep while the HTTP transfer happens. Proxy will only send out the response back to node 1 once that wakes up again. This works if node 1 and proxy exchange sleep schedule. (Slide 37): similar case, again useful for a proxy to know the sleep schedule of a node that it is trying to proxy a request to. This would need something like a long-pool or a retry-after on the HTTP side. (Slide 38): In what format should the sleep schedule be, and how should the nodes synchronize? Cf. 802.15.4e. CB: That would be nice because CoAP would not have to do anything -- but proxy and node 1 may not be neighbors, so they don't share an 802.15.4e relationship to share information. There is some cross-layer thing going on; we can't completely solve this in CoAP. AR: Agree. (Slide 39): Multicast. Scenario: HTTP to CoAP proxy; if a single HTTP request is going out per multicast on the CoAP side: (Slide 40): What do the URIs on the HTTP side look like? How to relay back multiple responses to the HTTP side? vs. Congestion Control (Lars' document)? What about sleeping nodes? (Slide 41): Conclusion 1: If the proxy node has an updated schedule, it can optimize by buffering requests/responses. (Slide 42): Conclusion 2: It is not clear how to map a unicast HTTP request to a multicast request/set of responses in CoAP. (Slide 43): If WG agrees, we can move from problem statement to detailed solutions. KL: I was co-author with Peter Vanderstok. Questions that appear separate turn out to be interrelated. Sleeping nodes interact with buffering proxies. Assumption that sleeping nodes wake up on a schedule may not hold. I would prefer to see multicast to move to a separate document; even though multicast interrelates with URIs. AR: Multicast in a separate document makes a lot of sense. Re synchronous assumptions: That was one scenario; sleep schedule could change; we don't want to preclude that; point is valid. KL: Opportunity to look at this in terms of proxying information. Does the proxy ever respond right away? AR: In our draft we have one scenario. KL: We need to resist designing solutions for every single problem before examining how they might be related. E.g., consider the problem deciding which proxy might be able to answer in place for a sleeping node. AR: What documents should be written to handle this. KL: I guess I'm neutral on that. ZS: Most of my comments are in line with Kerry's; we should spend some time to scope what we do want to solve. Multicast: Maybe start with the more basic problems (i.e., between nodes in the same network). AR: OK, two documents, one for multicast, describe problems some more. ZS: Way to explore the different scenarios. We could come up with a huge number of problems that might be nice to solve. CB: When you split off the multicast document, think in terms of group communication and not just multicast -- some group communications requirements might map to multicast, some others to the way proxies work. KL: Even group addressing has implications all the way into REST. There is no concept in REST of a group address... CJ: (Need to wrap up.) AR: Thank, I think I understand all the recommendations. 16:10 2 – Bootstrap approach BS CJ: Time: 20 minutes left -- in the call -- stay another 1/2 hour? (Multiple:) Yes. CJ: Stay relatively in time with the next two items. (Slide 45...) BS: Colin is the main editor (Slide 47:) Overview (Slide 48:) What is bootstrapping: box of nodes to functioning network (Slide 49:) What is it not (service/resource discovery) (Slide 50:) Problems (Slide 51:) Existing Solutions (Slide 52/53/54:) Proposed Architecture; different sequences of key establishment; bootstrap protocol: actual messages for bootstrapping. (Slide 55:) Charter says security bootstrapping, bootstrapping requires input from other layers than just CoAP. (Slide 56:) Next steps: Get input from other groups, e.g. ZigBee. So this should not be a Proposed Standard, but maybe an architecture document (informational). Feedback? CB: back to Slide 45: The charter actually says what we need to do. BS: very relevant to our draft. RS: In the charter it mentions, universal method for joining nodes together, but we also need state transitions during the life cycle; one may need to do bootstrapping more than once during the life cycle. How do we want to fit bootstrapping into the whole CoRE effort? CJ: As a chair, my feeling is that obviously the bootstrapping is somewhat intertwined with the security; these are hard topics that I wish we made more progress on -- long-term impact on our schedule. What do we need to do next to make progress? BS: comment on current draft, direction from chairs CJ: Informational/BCP; I can provide some generic advice when we use these things. An architecture document would typically be informational... BS: We would need to change charter... CJ: change the milestone. If you can't implement the mechanism document without referring to the architecture, the latter needs to be PS. Netconf is the example for that. Figure out what to do and then chairs figure out what to do. Changing milestones is easy, changing substance of charter is much harder. BS: Are we on the right track? CJ: This is mostly a technical question. Process-wise, we are OK, if the technical direction is OK. Any comments -- none. RS: One more note: On the charter it says one mandatory universal method; but this may impose a constraint on the device. In an application domain, people may want to disable it... CJ: BCP 61(?): it is mandatory to implement a reasonably strong security mechanism for an IETF protocol. It would be OK to say "Servers have to do A and B, clients have to do A or B", but the point is that we should be able to interop. CB: We have to move on. 16:25 1/2 – CoAP Usage PV (Slide 58: 9030) KL: Peter couldn't be here; I'll try to speak to the high points. Bring forward some building automation use cases, so we aren't just driven by smart grid. (Slide 59:) Speak to groups of nodes simultaneously; series of unicast messages, but in some applications like lighting control, there is a concept of synchrony. Scheme+URI is involved in service discovery. Naming authority could apply to group of nodes. A or AAAA record could reference a multicast address. (Slide 60:) sending PUT to a number of nodes, reducing number of packets (Slide 61:) group of nodes (Slide 62:) BACnet, LONtalk; could have phased introduction of CoAP: e.g., PUT an application/DALI message to a light. (Slide 63:) Size of URI; Path specifies resource; scheme + authority would represent a CoAP service access point; at the WG meeting last time Stuart Cheshire made a point of service access points potentially supporting multiple services; e.g. a print server with multiple queues; a host with multiple sensors. What is the notion of a device? Is there a one-to-one correspondence between devices and hosts? There could be many virtual devices per physical device. (Slide 64:) Batteryless devices; this is a stake in the ground: Controller nodes should not necessarily be sleeping devices (PUT to sleeping device might be out of scope) (Slide 65:) Peter would like to see something along the line of reliable multicast, but there may be multiple ways to get that. CB: Useful to separate in our mind group addressing from multicast as a mechanism (vs. distributed agreement protocols). Multicast is just a way to get efficient transfer for group addressing. KL: Peter has identified at least one situation where he needs multicast: Simultaneous transfer to a group of nodes. Of course, multicasting is not supported in HTTP. From a REST standpoint, a multicast request is equivalent to multiple unicast requests. Obviously, a lot more discussion is needed. CB: I like that this draft is grounded in real-world applications. We need these reality checks, with actual buildings and actual light switches. Go on designing a system with CoAP in mind and see which features are missing. KL: I am also participating in BACnet/IP working group. We are examining how to move BACnet to a native IP approach (as opposed to tunneling). I want to make them more aware of what CoAP is doing and v.v. -- not saying that they necessarily need to converge. CJ: Would you we willing to write email back and forth to BACnet and to us -- being more aware would be good. KL: Sure. I gave a presentation at last BACnet meeting about CoAP. CJ: Really helpful, thank you. 16:40 Planning CB: Do we want to do this again? (Slide 67:) My proposal ... AR: Very useful, I like the proposal. KL: I agree. How frequently CB: My proposal was approximately once a month. More frequently? Less frequently? KL: Monthly is about right. Three meetings between every WG. ??: One more before Beijing. CJ: Let's check the rules. Try running them monthly. We are heavily biased by just asking everybody who came here :-) PB: one month is good. CB: So, one month it is. The documents progressing in parallel is good way forward; we should see new versions within the next couple of weeks. Anything else re planning? -- no. Thank you for this meeting 17:00 End of call (All times are nominal UTC, actual was about 0.5 h later.)