Chair opened the session. Gabriel Montenegro wants to make sure we know HTTPbis is having a meeting on Thursday. Note well Recharter needed for security (deliverable 2) Good shape on deliverable no 1. Link format went in IETF last call on 14 February, ended and is now going to IESG. Slide 5: CORE COAP, BLOCK, OBSERVE are in WG last call until 16 April. Chair requested the group to review these drafts. Chair requests to send issues to the list. The WG is requested to declare IPR. Also request for implementers to provide feedback on the mailing list. Slide 6: New WG draft: groupcomm Quite some individual drafts to be discussed. hartke-core-codtls will be in lwig WG on Thursday. Slide 24: Agenda Presentation from Smart Object Security Workshop possibly on Friday. Rescheduling might be needed on short notice. Peter St. Andre: TLS wg is meeting this week (Wednesday), might be interesting concerning the CoAP security discussions. Hannes: Jari will give a presentation on the implementations. Cabo: recommends attending saag WG on Thursday Cabo: quickly reports on Smart Object Security Workshop (SOSW): Smart Object Lifecycle Architecture Slide 7: Report on ETSI IoT CoAP plugfest During the weekend, CoAP was tested in the first ETSI COAP PlugTest. Interoperability between implementations was performed. Skipping slides 8-9: Slide 10: Slide 11: Slide 12: ETSI sponsored the plugfest, lots of tools created: PCAP analyzer, lossy gateway. Slide 13: 15 companies, 20 implementations, 50 participants. Slide 14: Participating company list Slide 15: Most work was on CoRE, also tests on Link Format, Observe and Block. Slide 16-18: Good results, over 90% of performed tests were passed. Observe was only implemented by about 60% of participants. Some issues with Block1 option, which was added rather late in the process. Slide 19: Token option may need more clarification, as there were some issues on the plugtest. Send CoAP responses from the same IP address/port where you are receiving the requests. Slide 20: Carsten mentioned that it was a well-organized event, both from ETSI and the participants. Pre-testing infrastructure helped in getting the implementations into a good shape. ETSI believes the main specification is mature. Slide 22: Another testfest is planned to take place in Q4 2012, place and scope is to be defined. More "exotic" features are supposed to be tested there. Slide 25: Not too many people will not be available on Friday -> Keep the schedule mostly as is. Slide 26: Zach Shelby: link-format-11 Slide 28: Summary of status. Reviews are completed. IANA is OK, no objections to ".well-known/core". .well-known/core has no objections 2 Reviews in progress: media type and link relation host. Slide 29: Security Review, GenArt review, App Review Lists of tickets, Zach requests input on closing the issues. Associated changes must be made by RFC editor. Security review by Richard Barnes Tickets# are on tools.ietf.org... Discussion on #189(?): Salvadore Loreto: question on security of Link Format. Zach: first ticket is about this. Better provide only links relevant to requester, which should be authenticated. Richard Barnes: Change content on who is asking. Jari: coap/coaps, v4/v6 address: same content? Does the current draft discuss this? Zach: Read the draft and tell me. Carsten: think about how to deal with multiple links to the same resource. Rest of the tickets are general comments. Recommendation to use origin definition from RFC6454. Slide 30: Gen-Art review from Joel Halpern About registration of "rt=" and "if=" values from the Link Format. May use Link Relation Registry. Carsten@mic: Of all the tickets, this is a big technical change, as a registry formalises the formats. Zach: .. Barry: Think about the right policies for the registration process, don't just select one that is always used. Text (1/2 sentences) about the reason for the choice should be included in the draft. Peter: AD hat is given to Barry. App Review: Julian Reschke #197: Upgrade to RFC5234 for ABNF is needed. (RFC5234 is the new version of ABNF) Barry?: Be careful about changing ABNF. Add support for token as well as quoted-string. "uri" to be changed to "href" Ray: Did you consider new RFC xxx Zach: Carsten: We are using this at discovery time. Multicast is an issue. Value in violating REST. Cullen: we don't have a specification on URI templates that works. Zach: resource types Slide 31: IESG Discussions: Russ Housley, same comment about "rt=" and "if=" Jari Arkko: ABNF improvement suggestions. Salvatore: relative link or absolute URI? Zach: ... Slide 32: WGLC documents: Slide 33: changes in -09: Slide 34: limit on no. of options piggybacking should be used when possible Carsten: Matthias proposed solution to 15 OC limit and 270 option length limit. Any variable length creates problems with one-pass encoders. Changes are only ~7 lines. You don't want to backpatch necause the first parts of the packet might have been sent already. Bert: if/then is used to spare one byte. Carsten: if you don't want to spare the byte, you don't need to implement: Bert: is it worth it? Carsten: Yes, for e.g. 5 to 8 byte packets with BTLE. It makes sense for low option counts. Zach: It is for a cornercase, but worth fixing. Bert: On the server-side you don't necessarily need this if you know that you have few options. Slide 35: Thanks to TLS WG for tls-oob-pubkey. What to do with the identifier. Options: Remove, define new hash in the draft or other draft. Discussion on Raw Public Key. Eric Rescorla: how can the identifiers be used. First options are fine. Ari Keranen: prefers appendix D, but a separate draft may be more sensible. Rob Moskovitz: Look into admission control. Recommends option #3 (separate draft). There is a broad need for this. Börje Ohlman: Carsten: This is identifiying devices, .., or what? Ohlman: Yes, any type of information. Cullen Jennings(individual): in favour of hash => gives nice fixed length IDs, indepedent of key size. Zach: You are proposing option 3 without 1? Cullen: Yes. Make a normative reference to the new draft. ??: Cullen: ... Eric: Cullen: Forward compatibility issues -> We should define it now and not leave it to the implementers. Zach: Number 3 seems to be the most preferred option. Multiple people.... Richard: PKCS may be a good candidate. Slide 36: Klaus Hartke: CoRE Observation Slide 37/38: -03 to -04 to -05: RST handling Max-OFE replaced by new notification by server. Slide 39: About time after MaxAge, i.e. if the client hasn't received an observe update wihtin the time frame that the previous update is valid. Solves 80% of cases. 20% solved by Pledge/Patience? Carsten: Light switch problem. Return to this on Friday. Slide 40/41: block option Hasn't changed much in the last years. Transfer more data > MTU. Last technical change split into Block1/Block2 (client/server). Interop showed some implementation difficulties with block1. Bert: block1/block2 is a bit complicated. in the example first block1. is that defined in the text or only the example. Carsten: example shows only 1 way to do it. Bert: synchronisation of short/long block1/block2. NON possible? Carsten: you get all the problems of fragmentation with NON. not disallowed, but i would not do it. Carsten: somewhere you need to store the state. constrain the combinations that are allowed. Bert: there is no text on it ATM. Mathias Kovatsch: Plugtest: different source ports. constrain it? Carsten: fix the bug? text on issues from the plugtest. Mathias: high frequency changes of the resource on server. how about client. Carsten: Token. Mathias: Carsten: no good way to abort a transfer. client should change token. Mathias: has to trust all the servers out there. Carsten: it's like FTP, if client 1 puts there and client 2 puts there, there are problems. Zach: seconds Carsten. Carsten: anything else on WGLC? Cullen: not enogh time for WGLC? speak up. Slide 42/43: Interfaces Slide 44: draft-shelby-core-interfaces-02 Salvadore: It is true that IETF does not do much on top of HTTP. Cullen: application layer things are done here. interest and expertise: yes, is needed. Zach: is happy to bring the discussion to the ietf lists as well. Not Coap specific, applies to other RESTful interfaces too. Slide 46/47: Web Linking used to link together resources on an end-point. Slide 48: Have a look at SenML at the Application Area. SenML not so useful with an individual reading, but with batch. Slide 49: Only parts in well-known/core, then go to link list. Tom: WG item? Zach: not in charter. for the future, if we want to do it. inside this WG or another one. Kepeng Li: /s is not a resource anymore? Zach: /s is a resource, a batch resource. Kepeng Li: special resource Zach: yes Robert: interop with obeserve? Zach: helps with observe with min... problems with cache. Sumanth: i think it is useful. ..? Zach: text/plain must be implemented, senml is optional. Sumanth: how much interest is there? what is the next step? Cullen: chairs need to know if the group is interested to work on it, if so, where in IETF? Should the answer be "CoRE", then rechartering is needed. It is fine to discuss it already on the CoRE mailing list. Jeroen: linked batch on intermediate devices, link to other devices? Zach: yes. not thought through. e.g. resource directories. possibly security issues with this. Zach: you could observe this "/s" resource. That means, if something changes, observing clients will be notified. Markus Somaki: supports this. useful. Li Kepeng: maybe use options instead. Zach: let's discuss on the list. Slide 50: this is IPSO stuff. not yet in IETF, but not opposed to it. Slide 51: IPSO developed a "profile", specifying how devices can interop. Multi-vendor demonstration will take place on 3/4 April in Paris. http://www.ipso-alliance.org/technical-information contains the IPSO spec. Slide 52: Several function sets have been defined, i.e. devices, sensors, messages, location... Data formats need to move to IETF. Slide 53: Open up copper in Firefox and point it to the address. Slide 54: There are currently no plans on pushing this further. Slide 55: groupcomm (Akbar Rahman) Slide 56/57: Slide 58: CoAP group communication is built on top of IP multicast. No changes in IP multicast needed. But needs to make sure CoAP can be used for that. Slide 59/60/61: DNS AAAA is configured by something like Kerry Lynn's/Peter van der Stok's draft. Slide 62/63/64/65: Slide 66/67: Discussion on use-case using IP multicast with CoAP. The use-case consists of a conference room and mutliple lights, which are controlled over CoAP. The lights have to be registered through IP multicast registration. CON responses of the lights are collected by a central entity, which forwards a single CON to the light switch. Slide 68: (1) Multicast only for GET. Slide 69: (2) Multicast only for GET, PUT, DELETE. Slide 70: (3) Multicast for GET, PUT, DELETE, POST. Salvadore: You should also include security aspects. Akbar: Are you recommending only GET? Salvadore: ATM only GET. Cullen: We cannot authenticate over Multicast. Robert: Group Key. Safe != Secure. Akbar: Group Keys are not very well deployed. Cullen closes the mic line. Martin: ?? No POST. Akbar: Prefers option (2). Rob Moskovitz: There is multicast security. Even group security is challenging. Chairs remind about blue sheets and close session. --------------------------------- 30 March 2012 (Core) Chair would like to quickly visit 4 of the items in WGLC. Carsten introduced a new ticket 201 - editorial (clarify use of retransmission window for duplicate detection. Very few people had read. Ticket 202 - remove the 270 byte artifical limit Chair asked whether to address this or ignore the problem? Zach - may do it in a more sane way. Think about it and post something to the list. Ticket 203 - restrict the potential combinations of block1 and block2 most people have not read the proposal. Ticket 204 - introduce a minimal version of pledge Chair: would only make sense if people believe this is the way forward. Kepeng Li - to prefer it to be a separate draft. Sal - don't think it's a good thing to do Zach - keeping this separate, it's a great mechanism. Jeroen Hoebeke - clarify the text how to deal with non cacheable resources angelo - discuss as separate draft from observe. Jari - Agree with Sal, it works only for some people not for everyone. Chair - not going forward for now. Group 4 - DNA Markus Isomaki - Constrained Application AutoConfiguration 02 version is more concrete than 00 version submitted in taipei Basically this draft describes how to configure the application layer once you've purchased the devices from the shop. Requires the use of username and password (minimal) to bootstrap itself. Some options for configurations: there is a web server running in the device or hardcode an address for a configuration website. Focus of this draft is to have some kind of configuration discovery based on CoAP. Some assumptions: devices support CoAP, and user has a CoAP configuration server in the local domain. Discovery request can be sent to a multicast address or the default gateway. Device includes in the request its service type and device ID. User can configure the device, by manually enter the config on the server (eg, a phone that has a UI). or use other means e.g, HTTP GET or OMA to get the configuration. Minimum content of the configuration may include address, and credentials. the proposal is standardize the baseline of the configuration parameters. Security concerns: configuration client and server must authenticate and authorize each other and the configuration parameters must be protected in terms of confidentiality and integrity. 2 main options : DTLS or layer 2 security between devices. Boils down to the pairing issues and device association/ device bootstrapping. Should this problem be solved in IETF? Lei Zhu - is it possible to define L2 and L3 security in this Group Markus - doesn't sound like this is the place to address it. (Jabber comments:) - what's the link to the problems that the HomeNet WG is solving? Is there overlap? Kerry - going to BCP or standard track? might be for LWIG? most probably no for LWIG. Generally difficult to provision application level security. Cullen - if people in this room think it's worth doing, then we decide what to do with it. Jari - this approach maybe a bit narrow. configuration might be pushed to the server as an option. Sal - worth pursuing this work. Another proposal to show that security is really needed. Zach - one way might be to describe ways of bootstrapping in different scenarioss. Another way is to integrate this with resource directory. Alternatively build this into the IPSO profile. Robert - there are a couple of drafts about security bootstrapping. Suggest to consolidate these drafts together. Cullen - anyone is interested in writing a document about this? Carsten - already writing one. There is a new draft called CoRE roadmap. Jari - good idea to integrate this with the resource directory. Sumanth - SIP, and effort outside IETF, maybe we can borrow things from there. Naming things with hashes - Ari Keranen A draft from Steven Farrell about Naming and how to use identifier is relevant. A simple identifier format encourage the audience to read the draft. Peter van der Stok - CoAP Utilization for building control Devices need to know where are the services in the building, and how to address group command/multicast. Need to discover, name/resource device, multicast group/end point/function set and function set collection. Zach - thought function set collection is now a profile. Can make this draft less DNS centric? Peter - to look at different concepts, and worked out examples using DNS context. example use case - detect presence of people and switch on lights. Only to switch on a set of lights, using the domain concept. Possible solution is DNS-SD using PTR to identify function sets. Able to do query to the DNS. devices need to be grouped independently of domain, possibly in conjunction with multicast group. Define the group of devices via commissioning. PIR and lamps can query to which groups they belong, group names are returned and multicast address. address two aspect, which group you belong, and who are the members of the group. Extension of existing reverse address resolution to multicat address Eric - what if when you ask which group you belong to, a wrong answer is given. then you send commands to the wrong group. This is not desirable, security is not addressed yet. Carsten - relates to group communication draft, and use of rpl for secure multicat in ROLL wG. It was mentioned there that multicast for discovery is different than multicast for other purposes (e.g. sending control message). Eric - Michael Richardson - there maybe a guy who is responsible for installing and commission these light bulbs. Maybe leave the security question. Eric - L2 security may not work. michael - there is a key in each lightbulb and they do peer-to-peer security. Kerry - function set is something that you might want to discover. Carsten - group management issues, this is one of the hardest distributed system problem. If we want to do group addressing, we need to address group management. Peter - need to consider the trade-off between security and device capabilities/functionality. Carsten - there are many ways to do security, and need to check which way is best applied to our environment. Mathias Vial - Sleepy nodes Devices sleep to save batteries and improve energy balance for harvester. 2 sleeping modes - link sleep state (radio duty cycle) and link disconnected node (radio off). Berta - why the server model is inefficient? There can be buffering at L2 (MAC) and neighbor nodes will buffer a request on behalf of sleepy node. Mathias - need to process incoming request at any point in time Zach - depends on the application scenario, different models work for different applications. Sal - agrees that client model is most efficient. Hannes - look at the whole system. OS and radio are outside IETF. Jari - move forward with this discussion. network does change, may need a different observer. The need to address sleepy node is important. Angelo - there is a draft on observer model. Eric - radio control is the lower layer issue. Jari - what can we do more? Tom - radio technique is done Rodolfo - this should not be done at application layer. Anders - second Tom comment. Sleeping endpoint is client only and delegates resource hosting to proxy, allowing for resoruces to be available when SEP is asleep. based on reverse proxy and caching proxy technique, the proxy stores resources of the sleeping devices. reuse standard resource directory to discover mirror proxy. SEP resoures is the sub-resouces of Mirror Proxy. resources hosted on MP, MP can export to RD if present with a separate RD entry. RD and MP interfaces need clarifications. Sal - difference with mirror proxy, devices can only go to sleep if MP is available. in thomas's proposal, passing the state information to another sensor using PUT. Eric - MP seems to be a server, not a proxy. Zach - fit nicely into RD. "Mirror Server" would be an option for the name. For the corner case, this is great Jari - likes the draft. 2 implementations for the client and the server (MP). Client part is small 4K. plan to have that code open source. Thomas - we've defined a new protocol primitive compared to mathias's proposal. Cullen - there are 3 proposals, this is not to decide which one, just want to find out interest in the group. quite many have read the draft and would like to contribute to the draft. Sal - may be extend solve, want to have something more general, not application specific. Should not require RD to operate sleepy devices. Should not use POST here. Jeroen - have a problem with the POST approach. Jari - whether to completely delegate to the MP should be discussed. Information should be accessible via both CoAP and HTTP. Robert - already have mechanism, may not need new primitives. Design a guideline. Carsten - we want to do this work. Best practice for HTTP-CoAP mapping implementation - Angelo Castellani URI mapping (HTTP - CoAP) target Reverse proxy use case call for feedback and implementation experiences. Carsten - Sal - 2 open source implementations and there are many other commercial (closed) implementations Kerry - extremely important to have HTTP-CoAP, SEP2.0 might be relevant. Sal - current charter says that we have to work on this workitem. Zach - do we have a best practice document for HTTP? only security best practise is available. 95% of deployment would be using reverse proxy. Suggest to skim it down to just discuss reverse proxy. Angelo - if the WG is only interested in specific case, then the draft can reduce its scope. Carsten - split doc into two. 1 is best practice Sal - ask consensus whether to have this document as WG document. Cullen - need to assess the technical content of this draft before we talk about whether to split this document. Need to know whether this is the right document? Zach - current state of the document is too large, and not recommended as WG document. Cullen - how to skim down the document? Zach - a WG document would just describe 2 things; 1) how to make forward proxy work (described in base draft) and 2) how to make reverse proxy work Sal - suggests Zach to write a draft. Akbar - focus on the reverse proxy. Cullen - let people highlight what should be the scope in the document, maybe post the document to the google doc, or a phone conference call. Sal/Cullen - can call for adoption in the mailing list. Cullen - but not if only 5 people have read it. Need more input before. Markus becker - CoAP over SMS A few people have read the draft, and want to contribute to the draft. out of time.