CoRE WG -- IETF 79, Beijing MONDAY, November 8, 2010, 1510-1610 WEDNESDAY, November 10, 2010, 0900-1130 Emerald Room (pretty overcrowded) Scribes: Geoff Mulligan and Shoichi Sakane, with some additions by Carsten Bormann -------------------------------------------- Agenda Monday -- Chair Intro -- CoAP core protocol (Zach Shelby) draft-ietf-core-coap-03.txt -- Slicing (Carsten Bormann) draft-ietf-core-block-00.txt Wednesday -- Chair Intro -- Link format (Zach Shelby) draft-ietf-core-link-format-01.txt -- Observe (Zach Shelby) draft-ietf-core-observe-00.txt -- Quick check on the requirements (Zach Shelby) draft-shelby-core-coap-req -- Security Bootstrapping (Behcet Sarikaya) draft-oflynn-core-bootstrapping -- Group Communications (Akbar Rahman) draft-rahman-core-groupcomm -- Putting the Picture Together (Peter van der Stok) draft-vanderstok-core-bc -- Next steps -------------------------------------------- AB: Anders Brandt ARa: Akbar Rahman ARo: Adam Roach BS: Behcet Sarikaya CB: Carsten Bormann CJ: Cullen Jennings (via Jabber) CO: Colin O'Flynn (draft author) EB: Ed Beroset (via Jabber) ER: Eric Rescorla (via Jabber) GY: Gary Yang JM: Jerry Martocci (via mailing list) KH: Klaus Hartke (draft author) KLi: Kepeng Li KLy: Kerry Lynn (via Jabber) LT: Linyi Tian MT: Martin Thomson OG: Oscar Garcia PB: Peter Bigot (via mailing list) PS: Peter Saint-Andre PT: Pascal Thubert PV: Peter van der Stok RC: Robert Cragie SC: Samita Chakrabarti SS: Shoichi Sakane TK: Tero Kivinen YO: Yoshi Ohba (draft author) ZS: Zach Shelby Ticket numbers are notated #nn. @nn:nn is approximate position in the audio. CORE Part 1: Monday [audio: ietf79-ch1-mon-noon2.mp3] -- Chair Intro @08:00 (Slides 1 to 7.) CB gives the usual introduction (IPR principles, overview of the WG milestones, agenda bashing). CJ is not in Beijing, and PS (responsible Area Director) has graciously agreed to stand in for co-chairing the meeting. Review of Milestones: The first milestone (selecting the WG document) is done; the second milestone (submitting the CoAP spec to the IESG in December) is mostly on track; the third milestone (security bootstrapping document by December) may not be met (slide 3). CB points to the extant requirements document, which is not something the WG is chartered to produce and therefore not an official WG document (slide 4); many people think we have covered them. Slide 5 shows the tools page for the WG, which shows the tickets to be resolved on the WG documents. CB mentions the plugfest on Sunday Nov 7, which (due to the inconvenient timezone) drew mostly newcomers and further increased the number of interoperable implementations of CoAP-03 available (slide 6), with a followup plugfest opportunity on Thursday afternoon. No changes are needed to the agenda (slide 7). -- CoAP core protocol (Zach Shelby) @15:45 draft-ietf-core-coap-03.txt (Slides 8 to 21, with slides 22 to 40 as background.) ZS gives a quick overview over the status of CoAP-03 (slide 10). Progress from Maastricht (which was CoAP-01): move optional features (including link-format) to separate drafts, URI Authority more well-defined, URI scheme option removed -- we may want to add that back in though. In CoAP-03, a token option was added for asynchronous responses; added new error codes beyond those borrowed from HTTP (i.e., CoAP specific ones); added a separate URI Query option to simplify parsing. Most significant addition: security considerations. Base spec has been stable since Maastricht plugfest (still at same protocol version); another plugfest on Sunday identified a few more editorial issues. ZS then goes to the 18 open tickets, editorial first, technical, and then security. 4 editorial tickets first (slide 11), moving in some text from the satellite draft (-observe, #31)), more clearly separate the descriptions of transactions and the request/response model (#51). We now know how differentiate DTLS and CoAP packets arriving on the same UDP port (#56). ZS quickly discusses the "easy" technical tickets (slide 12, @22:37): #30 (zero-byte max-age for value 0), #50 (human readable error responses, text/plain), #52 (how strict to define POST). LT: POST being defined as server dependent functionality, seems not consistent. ZS: This is language from RFC 2616 (HTTP), a bit of a loophole. CB: We started CoAP with Create/Read/Update/Delete; Create obviously was for creating resources. Then we got comments to be more like HTTP. In HTTP, the protocol does not really help you much here -- the semantics of POST are just not really defined. We could do an even more undefined "INVOKE" thing, but so far people have been happy with being like HTTP here. #63 (verify interactions, e.g. avoid having to resend a request without a token in certain cases). (slide 13, #53): ZS chose a very conservative length for the Token, up to two bytes. It may however be useful to be able to put in some cryptographic protection. Upping the limit to 270 bytes may be too much. So what is the right token length? ER (jabber via PS): need cryptographic protection, may not be secure right now; (and another jabber comment later:) The notion of state in tokens not clearly defined in the draft; need a MAC, minimum size by guess probability, at least four bytes will be needed. ER will post more to the list. ZS: agrees that this in resolving this ticket text is needed to clarify that issue. (slide 14, #28): authors seemed to have different ideas on what you send when you retransmit something. Make a request, don't get an ACK, repeat the request -- do you include the snapshot of the first request or do you take a fresh version of the resource representation? Question becomes most interesting in -observe. On the mailing list, we said: in some cases it is more memory efficient to send current state (rather than saving snapshots), so we want to say you MAY include current snapshot. RC: This ties in with the discussion on POST, which is non-idempotent, you have to be careful on how to re-process POST retransmissions with the same TID. CB: This is pretty much what KLy raised on the mailing list; the answer is the same here with a different bias: It's still the server's decision, but we would expect a server to "do once" for POST, while many servers will forget everything about a GET and respond to each retransmission as a new request. ZS: we have a common view here. (slide 15, #45): ticket taken from the -block draft. With -block, we can't handle a POST *resulting* in a large representation (block can do one way, but not two ways). One way to deal with that is, in the response, to send a redirect the client to separately GET the large representation. This works fine, but would require us to support redirect, which so far we don't. Redirect could be dangerous, so the proposal is to support redirect only in a way that is restricted to same-host only redirection for security reasons. LT: Is this between some of the blocks? Why is this specific to -block? ZS: This happens to be something that -block would need in a specific case. (slide 16, #62, @37:20) We removed the Uri-scheme option, but recent discussion has indicated that some people would find Uri-scheme useful for a client to indicate the protocol to proxy to when using a multi-protocol proxy (http, https, ...). We thought that a proxy might simply know what protocol to proxy to, and a client might not care. How much do we want a constrained client implementation to know? (Some other uses could be in redirecting to other protocols, but that seems to be out of scope here.) CB: We are trying to implement RFC 3986 (URI spec); that has a scheme; if we can't express one part of it, that would be a mistake. Look at the specific use cases -- do we need that? CB takes over and continues on with the coap-03 specific security discussion (slide 17, @40:00); leaving the security bootstrapping discussion for Wednesday. #58/#59: So far we have been operating under the assumption that the security we need will come either through session security protocols (IPsec, DTLS) or through object security protocols (we haven't chosen one, but the IETF has just CMS). But you also have to think about the security interactions with the base protocol; e.g., how do you do authorization. The tiny devices are not brainy enough to do lot of authorization, but they have big friends in the network which can do the authorization, and the tiny devices then just trust their friends indefinitely. That may not be the only trust model. ARo has asked for that, and ER has sent a review with a lot of good questions. Is the "small device with big friends" the right model, or do we need more fine-grained authorization. Is it the temperature sensor that decides who gets the information? If it is some proxy, how do we bind that proxy to the sensor. ER (relayed by PS): Can someone explain "small device with big friend"? CB: I can try to do that. A computer with a trackpad won't have much authorization between the CPU and the trackpad -- they are just bound together. In embedded systems, devices may be scattered all over the place, but they may still be tightly bound to a larger device that can make decisions for the small devices. Motivated by not wanting to have policy decision or even policy enforcement capability in a small device with a couple K of RAM. This needs to be discussed in terms of use cases. The HTTP header for authentication, called "Authorization:", that is then used for authorization decisions, was added later. (A related question from ER on the capabilities of small devices.) We can revisit this on Wednesday when we talk about bootstrapping. RC: The trust model between two application peers is often defined implicitly by the application itself. You may need a mechanism to pass that information around, authorization/access control is often implied by things on top of that. CB: What part of that do we have to transport in the protocol? In HTTP we have the "Authorization:" header, or we have cookies. Both we don't have in CoAP. We can add options and some protocol machinery if we know what we are doing. SS: Do you have to describe the trust model and the device capabilities in the coap specification? CB: We have to write security considerations, which must make plausible that we have good security properties, which are hard to talk about when we don't know the security objectives, which may hinge on a trust model. CB goes on to slide 17 with #61: it should be hard to use this protocol to attack other protocols. Need to add text about cross-protocol attacks. Slide 18, #55: many small devices have hardware for AES-CCM; can we make use of that hardware in a good way. The DTLS RFC uses TLS 1.1 which does not support AES CCM, but its successor 4347bis has already passed WGLC and supports AEAD, with suitable ciphersuites coming up also. Two things may need discussion: (1) SHA-256 may not be liked very much by designers of small devices; if that is a problem, we may procure a ciphersuite that does not use SHA-256. (2) We may need to do the same kind of work for IPsec; designers of small devices may not like IKE, but any other mechanism still needs to provide fresh keys for AES-CCM. How to key IPsec for this kind of application? (CB then guesses TK will say "IKE"...) ER (jabber via PS): Is the concern runtime or implementation cost or what. SHA-256 is used only for the PRF. CB: People don't want to have the code for SHA-256 in the device. PS: I don't want a lock on my front-door either :-) RC: I have data that show SHA-256 is not onerous on a constrained device. PS (channeling another jabber comment by ): Where is the data that show the prevalence of CCM-only devices? RC: As this is used by the 802.15.4 MAC, it is implemented in a lot of SoCs (systems on a chip). CB: The security considerations need to explain how to properly use AES-CCM in these applications. RC: Comparing CCM vs. GCM, the two AEAD mechanisms are very similar, so the changes needed in the ciphersuites are minimal. CB: Right, it would be a larger change to change the hash. ER (jabber via PS): I'm arguing for SHA-256. CB goes on with slide 19, #60 (access control, which is the same as authorization). Now we are talking about the big friend: If that has ACLs or some other authorization mechanisms, how do we parametrize that? With HTTP, we can use the HTTP mechanisms (which are not very good), but what about CoAP to CoAP Proxy. Slide 20, #54 IPsec and multicast: This time the answer is not IKE. (MSEC.) May become expensive very quickly. TK: for multicast, object security is more proper than transport security (IPsec, DTLS). CJ (jabber via PS): The issue is A talks CoAP to Proxy B that talks CoAP to C -- how does A authenticate it is talking to C? Not so much access control, but the endpoints. CB: In the tightly bound model, that never happens. If you need end-to-end security, it's hard to do that with session security. Maybe the answer again is use object security CB: Some of these questions don't have easy answers. We are not going to quickly solve all the outstanding problems everybody else is grappling with. We can provide a good security considerations section and provide advice to implementers that avoids them running into the next big security disaster. CB channels ZS with the next steps (slide 21): close the tickets, spend most of the energy on completing the security, submit coap-04 within 3 weeks, then last call, maybe meeting the WG goal to submit to IESG in December. PS: I'm all in favor of meeting the milestones, but let's do this right. CB: Yes, much better to do the security work in the WG than when the document is already in the IESG. -- Slicing (Carsten Bormann) @62:30 draft-ietf-core-block-00.txt (Slides 41 to 49.) CB tries to use the five minutes left in the meeting for discussing -block. Underlying problem: Some resource representations are larger than you *want* to send over UDP. Have something in the protocol that enables client and server to talk about resource representations in terms of blocks/slices. -block defines a very dense option for this (one byte needed for up to 16 blocks.) Block sizes are limited to powers of 2, between 16 and 1024 (theoretically, 2048). Simple option, implemented a lot, works very well for GET. For a resource that is changing, client has to watch Etag, but firmware updates, XML description files don't really change often. For PUT and POST, -block works on the *request* body. This is stable and has been implemented a lot. One new proposal, however, is to use a more semantic approach instead of a the power-of-two blocks. CB: I reused the filename bormann-block for a thought experiment, using variable size messages, and new options for semantic tokens that "link" these messages. There is one specific application that really benefits from this: device enumeration; this is the only use case at this point in time. CB asks for quick feedback: Who has read bormann-block-01? [Not many.] CB apologizes for reusing an individual draft name that was already superseded by a WG draft, as this approach caused the logic of he tools site to malfunction, so this draft was visible only on the main IETF site. ZS: I'm the only one here who read the draft. When this was brought up on the mailing list, motivated by OneWire, I thought this was cool. When I read this draft, I have to say: I don't like this. -block needs just one option, is easily debuggable (Wireshark dissector works beautifully). I only see disadvantages with the semantic approach -- this may not even belong at the transfer protocol layer -- better off doing it with REST. Flexibility is not a good thing with this kind of protocol. Let's not do this. ZS: The one thing that appears useful about this draft is finding out about the size. Either do this as a size estimate/max-size attribute for the link-format, works if the size does not change much. An option could be returned for more up-to-date information CB: Indeed, that is #44. (Time is running out. Meeting ends @72:08.) CORE Part 2: Wednesday [audio: ietf79-ch1-wed-am.mp3] -- Chair Intro @17:00 CB quickly repeats the preliminaries. Agenda changes: Security Bootstrapping is moved up to the beginning, and the -block discussion needs to be completed from Monday. -- Security Bootstrapping (Behcet Sarikaya) @20:23 draft-oflynn-core-bootstrapping (Slides 67 to 71.) BS presents, as neither CO nor YO are present. The draft now describes the overall architecture and evaluates specific protocols such as EAP, PANA, HIP-DEX, 802.1X. SC: Did you consider PANA-Relay? BS: Yes. Draft is covering recent developments in ZigBee. @27:24 GY: Re-commissioning applications; use case so far mostly at home, but for city development, leveraging public transportation, initially, the government will be the service provider, but gradually, the infrastructure will move to commercial operators and the devices will have to be re-commissioned from service provider A to service provider B. BS: We should probably consider that. GY: AAA is kind of a clean solution, moving data from one provider to a different one, new key. ER (jabber via PS): I must say, I'm confused by this draft. Surely this stuff is a *lot* more complicated than the "too complicated" DTLS. BS: DTLS is data plane, we are looking at the security bootstrapping. Data transfer protocols such as IPsec ESP would provide encryption. If DTLS is complicated -- we have two protocols for data transfer, if IPsec ESP is better, I cannot say. RC: This is about bootstrapping, not about securing in-band data -- that's why it is more complex. ER (jabber via PS): That seems to me to be missing the point. Either we're concerned about complexity/code size or not. If we are, then isn't this stuff really complicated? PS: I.e., DTLS code size vs. this. RC: We find that you align authentication protocols with in-band protocols, so you can use the same implementation components for both. Here, we use EAP for initial authentication to get on the network. OG: Operational requirements: In the beginning, systems may not have connectivity. BS: We have some text about that. CB: To the question on the last slide re WG adoption -- we are definitely not there; we are collecting information and structuring it; this is what the draft needs to do next. RC: We can work on use cases forever. We need to have some limit. Otherwise I agree, we need to do some more work. -- Slicing (Carsten Bormann) continued from Monday @37:40 draft-ietf-core-block-00.txt (Slides 41 to 49.) CB continues the discussion from Monday, now about the tickets we have on the WG draft. Editorial tickets (slide 46) need to be done. We had a bit of discussion of size estimates (slide 47, #44), one proposal was to add a new option, the alternative is to add size information as a target attribute to the link-format -- could find out size estimate in discovery, but not necessarily current. In most applications we have seen so far that would work well. For an option, we would need to decide whether this is exact, or a maximum etc., but what are the use cases? Decide on the list. (Slide 48, #45): @41:10 CB notes that use cases include large response bodies for GET and large request bodies for PUT/POST -- do we want to complicate -block by also accommodating large PUT/POST response bodies? Who has an application that needs POST? ZS: There are some uses for POST in firmware update. But you'd need to be doing SOAP to need large response bodies. CJ (jabber, via PS): As an individual, I am in the go simple, no redirects camp; any app that has large bodies, can easily do it a different way. EB (jabber, via PS): Agreed. CB: So the sense of the combined jabber and physical rooms is: Keep it simple. (Slide 49, #46): HTTP codes are not sufficient for -block error conditions. In CoAP-03, we have a new space for CoAP-specific error codes. Maybe that wasn't so bright, as we no longer can use the first digit to understand the class of the error. Design this on the mailing list -- finish the ticket once we understand how to do non-HTTP error codes. LT(?): Do we have to put in some text on how retransmissions work? CB: Indeed, those are more likely in a multi-exchange operation such as a block-wise transfer, so this should be explained. No new mechanism needed, though. -- Link format (Zach Shelby) @47:28 draft-ietf-core-link-format-01.txt (Slides 50 to 57.) ZS acknowledges the help he got from PB. The document seems to be getting simpler going forward, not more complex. (Slide 52.) List of resources the server has. (The example has a cyclical link. This is from a live server.) (Slide 53.) Try to re-use web-linking work for CoAP resource discovery. (Slide 54.) Extending RFC 5988 just a little bit. Link-format is now a separate draft since we decided to keep optional things out of the base CoAP draft. Might also be useful outside CoAP (memento.org request). Now mostly working on clarifications. This has turned out to be useful for debugging in plugfests. Pretty universal in implementations now. (Slide 55.) #41 trivial. #42 which link-extensions do we want? (See slide 56.) #43 please send examples -- we want to know how you actually are using this. #57 write explanation. EB (jabber via PS): With respect to issue #57, should this issue should be mentioned in the security section of the draft? A hostile node could deliberately construct an infinite depth URL. ZS: Yes, this is the idea in #57. #70 fix the filter definition -- filter on any link extension. (Slide 56.) ZS solicits input on which link extensions [target attributes] to retain. sh (Short URL) is not used very much, because URIs already tend to be short. id (Identifier) could be some serial, could be used for indexing. Two new ones proposed: obs (is a resource observable, i.e. do I bother to put in a observation-lifetime in a request?), sz (size maximum or size estimate, cf. -block discussion). KLy (jabber via PS): Is "name" like "type" or "class"? Or is it "instance"? ZS: Example might tell that. Could be type/class. Instance: possibly, could use it like that (certainly not "description"). id might be useful for instance -- same name, different id. PS: So what is "description" then? ZS: More about what is the REST interface to this, e.g. WADL. (URI is just a name here.) CB: My view: "description" is a reference to a piece of formally interpretable information (not really a schema), a type; id is the instance; name is more like a human-readable comment for debugging. ZS: I don't agree. "Time in China" -- nice for humans, but also semantic naming (NASA ontology). PS: That sounds like "description" -- the kind of data. ZS: In one EU project, SENSEI, we have two separate things: WADL description for accessing a sensor resource, the same regardless of kind of sensor; you still need a name for the kind of sensor. CB: You might have two descriptions then (protocol, semantics). MT: names, descriptions, ids. What about rel? Very important. ZS: We need some help from the web linking people here. We have an assumed relation type, unless you put something. Common relation is "on this server". There are some others in the examples, but maybe not perfectly done yet. We also don't want to create a whole bunch of new relationships. LT: "description" -- simple Web page with human-readable information? rel could also be used for the description. LT: Filtering -- can we really use all the parameters here? E.g., short link? ZS: We have a ticket to update the filter list to "any parameter". Not all will be useful to filter on. Description may be very useful if you are looking for a sensor with a specific WADL definition. KLi: Use of id in the filter? Identifier is unique. ZS: If the URI were unique, you would just use the URI. id is just an identifier; you may still want to map a known identifier to its URI. More useful with multicast/a resource directory. PS summarizes jabber input: people like the idea of removing sh; like the idea of max size, but are not so sure about obs, because you always could just try. ZS: obs affects code, so let's take this to the list. PV: I'd like to keep short URL. URLs may get large in the future. ARo: observable -- when a network is configured, someone will be presented with a list of resources; you'll want some sort of automated indication whether a resource is observable. ZS: this starts to be stable, mostly playing with ABNF; so with better examples and a few fixes, this should be ready fairly soon. Go in December with CoAP. CB: re timing: It might be possible to finish in December; which drafts will be synced with that. ZS: This might even come before CoAP. -- Observe (Zach Shelby) @72:45 draft-ietf-core-observe-00.txt (Slides 58 to 65.) ZS standing in for KH. Observe is optional feature: GET with a lifetime; Server will immediately ACK back, echoing the lifetime (this is missing in slide 60) and giving the current state of the resource. Then, under the control of the server, the server can occasionally send a new CON message (new TID), with "200 OK", a new value, and a new lifetime. The client sends an ACK. This continues until the lifetime runs out. Nothing fancy, no redirects, no multicast, no threshold setting. (Slide 61, 62.) Tested in Maastricht. Many small tickets from KH. (Slide 63.) Editorial tickets: #33 fix the naming. This is not publish/subscribe, this is observation. Not competing with pub/sub frameworks (#37: add some text about that point). CB: #40 is not quite editorial; having a node persistently send packets to another node is an important security consideration. ZS: That's why we don't have third-party subscription and multicast. ??: About #64, what is the frequency of notification? CB: That's the substance of #67. (Slide 64.) #35: add text; #66 (URI + IP address/port -- not much state; this is where the Token issue #53 comes in.); #69 ... LT: NON is recommended, CON is allowed; maybe we can allow just the NON because client will be simpler. ZS: Text right now says you can send NON, if the server thinks a loss does not matter (e.g., streaming sensor data); put changing actuator... Server is controlling this. It's not hard to send an ACK to a CON. CB: Semantics: one rule behind most design decisions has been: It is up to the server to obtain the semantics required. Observation requires eventual consistency, i.e. the progress of the communication will ensure that eventually the client will find out about the new state. For a resource changing regularly, NON ensures this. For a resource non changing regularly, you need CON to ensure that. (Slide 65.) Not yet at last call; lots of editorial work needed (although the mechanism is solid). Plugfest servers already support this. -- Quick check on the requirements (Zach Shelby) @88:00 draft-shelby-core-coap-req (Slides 66 and 4.) CB: This is, I hope, the last face-to-face meeting on the base spec -- by Prague this should be done. (Slide 4.) We can add satellite drafts later, but are we done with the base spec -- are all requirements met without having to invent anything major. ZS: draft-shelby-core-coap-req recently resubmitted without changes (to keep it alive). Not fully done editorially on: Caching (REQ4); HTTP mapping (REQ7) -- spec doesn't say much, but we don't want to spend a lot of work on this. Also: Manageability (REQ14); basic concept is using web transfer on embedded devices -- make resources available over CoAP; but there may be other management protocols that have access to things not mapped to resources. PS: IETF has an OPS area -- get cross-area review. There have a draft on operations and management specifications. CB: There have been some discussions about management for small devices. This space is opening up a bit. Two years ago this would have been a discussion about getting SNMP on the devices. Now we have SNMP, netconf/YANG, IPFIX, a fourth one. It might be possible to look at MIBs (e.g., EMAN's), and how a MIB might fit into the CoAP space. CJ (jabber via PS): So what about sleeping nodes? ZS: Wasn't that the next presentation? I don't see a reason why CoAP could not be used by sleeping nodes; it's all in the application. Might define buffering gateways that buffer while nodes are sleeping; but that gets into application state. Maybe have a satellite document on that later. -- Group Communications (Akbar Rahman) @95.55 draft-rahman-core-groupcomm (Slides 72 to 82.) ARa acknowledges input from KLy, PB, PV. (Slide 74:) This draft is a a followup to a previous draft; just a problem statement both on sleeping nodes and multicast; we split this up after Maastricht into two drafts with problems and some solutions. One is group communications, i.e. this draft, and another one will be on sleeping nodes (not yet ready to review). So we'll focus on group communications now. (Slide 75:) Three approaches: (1) IP Multicast at IP layer; (2) Overlay between IP layer and apps, with some functionality on a proxy; (3) pure app level approach, like E-Mail -- taking care of group management at the application layer. (Slide 76:) IP multicast is well known. Would need a multicast-enabled network (with multicast enabled routers, e.g. with the routing protocol PIM sparse mode RFC 4601). Receiver nodes use MLD protocol (RFC 3810) to subscribe to an IP multicast group. Nice, but big Con: IP multicast support not deployed very well in networks. CB: 1) clarification: CoAP doesn't require multicast, it supports it. 2) We had some discussion about data origin authentication in multicast; there used to be an IRTF research group and there still is a long-running IETF WG called MSEC working on some of these issues. ARa: Will include that in draft. (Slide 77:) Infrastructure based on proxies to deliver IP multicast. No longer dependent on PIM etc. ROLL and CoAP draft already "support" MLD (cf. IPv4's IGMP) as a subscription protocol. MLD proxy node. CoAP proxy node would also have to support MLD signalling. Subscribe to CoAP node, which is then responsible for delivering IP multicast. No need to connect to external multicast backbone. (Slide 78:) Con: not obvious that MLD proxy allows this scenario. May need additional behavior in the proxy. PS: there has been discussion in jabber about security points, needing object security, discussion on the list -- please check the Jabber logs. CB: All the things I said about multicast security apply here. And there is another IRTF research group to consider: SAMRG. My main point is about the term proxy. MLD proxies forward packets from one multicast domain to another domain. A CoAP proxy forwards requests and sends back responses. This will be hard to do both at the same time. A CoAP proxy already might support reverse fanout (one observation feeding to multiple clients). This sounds like a proxy that forwards IP multicast packets, that will be interesting. ARa: Upstream interface to routing infrastructure, downstream to the hosts; on the downstream it receives subscription notifications and sends multicast packets; on the upstream, it looks like a host. MLD would fall in the same location we would draw a CoAP proxy. ZS: Two different entities at different layers, might be co-located or not, don't mix them up. CB: CoAP proxy terminates an IP exchange, computes, and starts a new IP exchange. The same thing would happen with multicast. Rather unlikely that it will also forward the IP packets. AB: Example: Light modules may need to be members of multicast groups, they won't be able to join groups -- somebody else has to join them on behalf of them. ARa: Usually, there will be some app triggering the join. (Slide 79:) Add CoAP functions for join and leave; proxy node would be responsible for the group management; nodes will unicast to the proxy. Proxy will explode it out (possible even with multicast). Cf. email group management. Con: higher overhead, need all this functionality in CoAP. PS: Security... Node might have trust in proxy; might use existing security relationship. ARa: Should we go into the details of that in our draft? CB: Don't generate solutions in the security space, but we do have to understand the security requirements -- they are forces that pull on the solution just as with performance, application complexity etc. PT: Just forwarding multicast vs. aggregation etc. ARa: Yes. OG: For security/bootstrapping, make sure that key material is distributed; analyze the security requirements (group key vs. ___ authentication). (Slide 80:) Replicate functionality of existing standard such as BACnet’s Alarm and Event Notification service? Push (PUT, MPUT), pull (GET, MGET -- return all the resources matching a URI). Limit to idempotent methods (PUT/GET/DELETE), e.g. to repeat requests to increase probability of receipt. Needs naming and addressing scheme. Could use DNS. Represent a group as a list of addresses? coapm? (Slide 81:) Need to agree on port and path. EB (jabber via PS): This is good and useful, and shows why security can't be left to later. Consider the command "turn off all lights in Asia." KLi: Group discovery: Can we use link-format to discover a group? Or do we need to add something? ARa: ZS? ZS: I don't know. If you are a server, the links are yours. Somebody could do a multicast GET, and you would answer, but not care about who else is there. Could describe a multicast group as a bunch of links; could use a multicast address as authority. Need to spec that... ??: Fanout -- some devices behind a gateway might not have a public routable address; URI may only be valid within the gateway control. ARa: In HTTP URIs, there is no multicast URI. CB: Summary: Some more work needed. We haven't talked much about state. Where is the state in the system? Before you can do group manipulation, you have to have a group. Where is the state of that group represented? For lights and a light switch -- do the lights know about groups, or the light switches, or some infrastructure? Also, try to switch from the term "multicast" to "group", which is really the important concept here. IP multicast is just a useful optimization. -- Putting the Picture Together (Peter van der Stok) @130:17 draft-vanderstok-core-bc (Slides 83 to 92.) PV enters a plea for having some naming conventions. Using building control; where we have some legacy devices... (Slide 85:) Beyond link-format: discovery of groups; of nodes in a scope; resources with certain characteristics. (Slide 86:) Person getting close to a sensor makes local lights go on. Some lights are wirelessly connected, some are on wires -- local multicast is not sufficient. (Slide 87:) Central servers; DNS-SD -- can put additional information such as URLs into text records. How to do installation while the central server isn't available yet? (Slide 88:) Legacy -- we still have to do this. (Slide 89:) Assume that we will use some legacy standards for device naming. Need standards about attributes and semantics. CoAP nodes might use BACnet or ZigBee standards already defined. (Slide 90:) Plea for standardization... (Slide 91:) This is not about the home (plug and play), but about installer using installation tools; tool can update DNS server. (Slide 92:) So, proposals: use DNS-SD and MDNS; base authority on canonical host name (A/AAAA); define MDNS to DNS-SD transition, and a CoAP gateway to legacy. ZS: DNS-SD is a good idea, but in some Web environments you may not have access to that. (PV: In the home, you won't.) ZS: In web environments, you often also don't. What I don't understand is MDNS; this requires every single device to answer MDNS requests. Maybe that is useful in a backbone. But maybe it easier to just run a DNS server. CB: Same question, different words: The installer runs around and creates state. Where does that state live? In DNS-SD that is in the DNS server. In MDNS, the state is distributed to the devices connected by multicast -- I'm not sure how the installer creates state there. PV: Valid questions, can't answer right now. I'd like an MDNS to DNS transition, but maybe there are better ways to do this. AB: JM might be the right one to ask about buildings. In the weekend you'd want to turn down an entire building -- you would have distributed control to do some of this plus some state centrally. I'm not sure I'd want to have MDNS anywhere. PV: I liked MDNS in a different setting in the past, so this is where this comes from. RC: Re state: there is also the availability of the state with sleeping nodes. ??: Are you saying the naming is application ID or device ID? PV: This is about naming conventions. Need to agree on the naming of physical things. Use later for service discovery. ??: Unique ID PV: Security -- you want to have rules about the access. KLy (jabber via PS): MDNS is concerned with service discovery, so the amount of state transferred is limited; in the web world, URIs are distributed to humans out-of-band; in the m2m world, there needs to be a programmatic equivalent; so we need handles to functional entry points. LT: Somebody is suggesting using the URI as a handle. PV: Yes, I am. CB: In CS, we solve problems by adding another level of indirection. Last paragraph on slide 91 is a form of indirection; find another name for the same thing that is more specific; part of the state that will be set up during the installation process. We need to understand that process much better, including the complexity that comes from not having all components available initially. PV: I agree. We also have to work out the home. -- Next steps @150:31 (Slide 93.) CB: Discuss the next steps. We have made good progress on the core CoAP spec and the directly related satellite documents; all authors have promised relatively quick respins; I tend to think that as soon as we have the drafts and are satisfied with them, we go to WGLC. CB: On the bootstrapping, it is not clear that we will be able to make the milestone Dec 2010. We will have a schedule slip. Naming, setting up state, group communication -- essentially the same issue: building larger systems out of the components we have. Now, in the IETF we never build systems, we create components. It appears clear that we need more components for setting up state and in particular for security bootstrapping. We'll have to spend some time on the issue of "plumbing", setting up relationships, names, group -- that is not called out specifically in our charter yet. Comments? Other things missing in the big picture? KLi: what about the drafts on congestion control, coap-misc? CB: We had a discussion about congestion control in Maastricht; we were satisfied that for unicast we don't have a major congestion control problem. coap-misc is a "Bastelkiste" (sorry, German word), a place where we keep parts that we don't know where to put right now. This is not meant to become a specification. Example: In the early URI work, we came up with a way to compress URIs but decided not to use it here in CoAP -- but yesterday in 6LoWPAN we briefly discussed ASCII compression in the context of 6LoWPAN GHC, so maybe this is now going there. coap-misc is not a list of open issues, but a stash of components lying around that we don't need right now. ZS: About the congestion control -- we should keep working on that after rechartering or maybe start work on the transport level. Some credit system or some other approach. PT: This is really good work. Large blocks; e.g., when you can't stream, you store a large amount of measurements in a device. Re UDP -- the transport area has a good document about how to use UDP. ZS: SOAP DPWS? Guido might present this next IETF in Prague. CB: So, see you in Prague! (Meeting ends @160:55.)