Minutes for LWIG at IETF-89
minutes-89-lwig-1

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!

-----------------------------------------------------------------------------------------------