IETF-88 lwig Minutes Note takers: (Put your name here) - Matthias Kovatsch - Dominique Barthel - Carsten Bormann - Zhen Cao ** Introduction, Agenda Bashing and Document Status - Jabber: Rick Taylor Since last IETF meeting - Terminology document : has 2 Discusses, - tls-minimal adopted - liwg cellular adopted - ikev2-minimal WGLC Four individual drafts ** Update of lwig-minimal-ikev2 after WGLC (Tero Kivinen) chnaged since -00: added note that RPK is also included working copy: removed DSS into WG version: RWA RSA public key -> Raw public key will publish -02 with latest changes. If anything to change, speak now. Suggestion by Zhen: Add description for implementations (current running code written in Perl) ** IESG review update of lwig-terminology (Carsten Bormann) received many (good) comments by IESG. Find out how to deal with comments here. Fight for our views or accept their changes ? - Is the document only terminology or more a concept discussion? --> No, only terminology Kerry Lynn: Important work to define the words we are using - What does "constrained" mean? Kerry Lynn: Include what is the minimal set of security --> We mean relative to the state of the art Specifically, we target Class 1 / Class 2 devices. We consider smartphones and even Rasberry Pi "powerful" We described "constrained" by contrast to more mundane devices in 2013. - Absolute numbers will not stand --> Classes are actually quite stable (held since 2004) and more evolve in power-efficiency or size - Rooted in 2013 --> Things usually depend on the time of writing, so include this reference - Take text from 6lo charter to illustrate more Opinion of the group? Peter: Pricing could be used as the constant Zhen: Could we have clarification in the text regarding CNN vs LLN? --> next bullet Sandeep: - "constrained networks" We are mostly interested in networks where constraints are introduced by the contrained nodes. Not by physical environment, e.g. We should make clearer that we mention other terms not to define them, but to relate them to our terminology: LLN, LoWPAN, 6LoWPAN. Could totally strike out this section. CB believes is still useful. Should keep it in. --> keep it Not about "challenged" networks, which are networks with very intermittent connectivity. CB recommends to make sure the distinction is clear. Brian ?? how to make the point that this is a terminology document? This document doesn't seem to be in the charter of this WG, may be perceived as stepping on other WG's ground. E.g., Adrian sees the overlap with ROLL's terminology document. This document should be more general Rick Taylor: challenged networks: will you bring them back into scope later? -> CB: this document does not scope the charter for this WG Brian: Terms broken out of guidance document. It should be about what LWIG needs to define. How not to relate this to ROLL etc.? Zhen: All these terms are used in the guidance documents. Brian: Use descriptive text from the charter to explain terms. Charter is reference for scope. - Energy usage classification --> Use something different from E0..3 - Always off Slightly provocative. Any better term? Relate to "sleepy" nodes used in other WGs. Brian: do you care distinguishing a node that sleeps 23 hours/day wrt. 8h/day? Carsten: Main point is whether timers have to be re-initialized ("where am I?") Brian: This document does not be that specific about the sleeping behavior and probably cannot be; the guidance documents will do that. Definitions need to be common between different WGs, even "wishy-washy" okay. Kerry Lynn: Terminology around duty cycling? Distinguish only sending, only receiving, and both --> yes to duty-cycling, see later. Re only sending, we haven't talk about those; IP seems to imply bidirect. Matthias/Dominique: Duty-cycling is about providing a "always-on" abstraction to the upper layers despite sleeping. "Sleepy" is when illusion of always-on is no longer maintained wrt to upper layers. Rick: Make it about the normal state, e.g., normally off instead of always-off - Write down the security characteristics Matthias K: classes of devices were defined according to whether they can connect directly to the internet in the first place. At least was distinguishing feature for Class0. Rick Taylor: don't try to define devices by the security they implement. Because what they implement depends on what resources they have. Sandeep: Not feasible to cover something meaningful in this document CB: Shall we keep the 50 billion Kerry Lynn:keep it Should we be using the "IoT" term? Kerry Lynn: widely used term, has been around for years, distinguishes from today's Internet. --> keep it ** Energy Efficient Implementation of IETF Constrained Protocol Suite (Zhen Cao) History -00 version in IETF86, viewed as reverse-RFC3819, deemed useful -01 version merged more content, asked for consensus at IETF87, positive but will confirm on the list Current -02, editorial changes. Carsten: merged with -coap document? Matthias: had content about duty-cycling. Youg-Geun Hong: Why is the RDC layer where it is in the document? Zhen: Reference is Contiki-OS, which has implementations for an RDC-enabled stack. ** Constrained Group Authentication Problem Statement (Minpeng Qi) not in the Group's charter. Presented here to discuss relationship with this group and see if things this group should work on. Smart meters, 1M connections to devices, up to 500 nodes per access point. Unicast to these devices is an issue. Reportedly, smart meters will report data, therefore authenticate themselves, all at the same time. Another case is taxi line at airport. High density of devices and periodic report lead to network overload. Requirement to find efficient way for connection to server. Group authentication. Glen Whiley: The numbers of the problem statement look like the usual scaling exercise of such systems. Minpeng: bottleneck in this case is the network, not the server. Matt Gilmore: At iTRON, well-known and solved in smart metering. Rick Taylor: seems you're trying to find a cryptographic solution to congestion. This is a topology problem. Interesting work anyway, but doesn't seem to be an LWIG problem. See AD's for pointers. Meeting closed 14:29