Welcome to Etherpad! This pad text is synchronized as you type, so that everyone viewing this page sees the same text. This allows you to collaborate seamlessly on documents! Get involved with Etherpad at http://etherpad.org Zhen presents WG status slides. Zhen asks plan about draft-ietf-lwig-tls-minimal which is about to expire Hannes: not quite sure what to provide in the document to provide useful guidelines. Could e.g. take the profile document in DICE and provide very specific implementation info? Matthias: numbers and so on are really good things (how much memory, time, messages). Good to provide that to DICE. Brian: if the WG going to DICE is the right way to go, I have no problem with that. Hannes: Brian: this WG (LWIG) needs to decide what is specific to LWIG and what is specific to DICE (what needs to be done in LWIG?) Hannes: numbers will not be there tomorrow. If someone is interested to work with me/us, talk to me. Zhen: do implementers find this info useful? Matthias: this area (security) was a new aspect, and this is very useful work. Hannes: few years back the draft served well, but today it is more just an introductory text Zhen asks about LWIG guidance document Carsten: I would like to revive it and maybe add some comment to the abstract like "this is a collection of bricks and not the full house" Carsten: it's pretty clear we're not going to publish it in this form. It's still a repository that has received some attention from the WG Ari: (about draft-ietf-lwig-cellular) we did a minor update. Zhen: any question on the agenda? -No question- -------------------------------- Matthias presents CoAP implementation guidance Matthias: I didn't get much feedback. Would be great to see if the draft is useful, questions to the authors, feedback, etc. Zhen: any comments to the three items before asking opinions Matthias: is there anyone running CoAP over IPv4? (a few raise hands) Ari: Carsten: my implementation simply assumes large MTUs. I don't see a particular problem. Zhen: I think those questions (three items in last slide) can be solved after this can be made a WG document. Zhen: do you think we can adopt this document? (Many hands in favor, no one against) Zhen: consensus is pretty clear. will confirm on the list. -------------------------------- Daniel and Tobias present Minimal ESP (and a second presentation) Daniel: does it make sense we use CCM instead of CTR? Carsten: CCM contains CTR. We use CCM because it saves complexity Hannes: it's not fixed, it depends on the application, you cannot assume it is perfectly aligned with the size of a block. Hannes: aligning with the size of the block cipher will be difficult Samita: I think your solution may be applicable to 6LoWPAN Matthias: is this targetting normal IPv6 packets? How does this relate to 6LoWPAN? There is some work on that, are you aware of that? Daniel: this just shows how you can build the ESP and then you can put it in 6LoWPAN, no problem Tero: you can use time as a sequence number without any problem ----2nd presentation Tobias: we would like to discuss this offline Daniel: we have defined kind of context how to compress the fields Zhen: suggestion to talk to Tero Daniel: the main motivation is to move to the hybrid mode ----------------------------------- Mohit presents Generic Bootstrapping Architecture Carsten: Hannes: bootsrapping here refers to key distribution Mohit: [..] it's a question of whether we can use [...] for this kind of brokering (after presentation) Carsten: memory consumption seems large Mohit: did not optimize them Ari: interested in seeing more on this Robert: Hannes: people assume devices will have SIM cards. Beyond that, it's similar to Kerberos Zhen: Mohit: it's a question of supporting more libraries Hannes: the problem is chicken-and-egg. Why should a server implement it if no client has it? Mohit: we have sensors which will have SIM cards. -------------------------------------- Yong. presents Sleep mode control mechanism for Constrained networks Hannes: how would the router on the left know the address of the router on the right? Y: we assume there is communication... Hannes: I think the router does not have some application knowledge (it would be a proxy). A router just forwards packets. Akbar: we also have some drafts in CoRe that discuss sleepy nodes. Your flows are at IP level, a complementary approach could be at CoAP level (by means of a proxy). Someone (Daniel Popa?): slide 6. What happens if you try to reach the sleepy node? What happens with the packet? Y: the packet will be dropped by the router on the left. Someone (Daniel Popa?): did you thing about buffering in the router? Hannes: potential attack... Did you think about it? Y: not yet. -------------------------------------- Zhen: we want to discuss about future of this WG. We must first clear the things on the table smoothly. We still have a lot of things to do in the charter not solved, and without proposals... Hannes: could you show charter text? Zhen: we talk about 6LoWPAN, etc. but for management, etc. parts, we have not seen experience documents yet. Hannes: for the IPSec, in 6LoWPAN there is not much to say, right? Carsten: it's in the guidance document. Hannes: there's a document written by Corinna Carsten: we have the 6lo WG which covers now other radios (BT-LE, Z-Wave, etc.). Would be good to get experience on these other adaptation layers. Corinna Schmitt: Hannes referred to the draft entitled "Compressed IPFIX for smart meters in constrained networks" (2011) - draft-braun-core-compressed-ipfix-03 Zhen: not many security experts here. Carsten: I'm actually not unhappy with the amount of security documents we have here Robert: it's worth keeping the numbers document for the implementation side (LWIG) Zhen: any more questions? (No more questions) Zhen: thank you! -----------------------------------------------------------------------------------------------