Welcome to Etherpad Lite! Notes taken by dominique.barthel@orange.com>, edited by Michael Richardson . Agenda/admin (Chairs - 5mn) [5] 1) WG Status (Chairs - 10 mn) [15] JP reported on status of current documents, and brought the applicability statement schedules; expressed a hope that we can get significant progress by on them by Atlanda. Anders Brandt reported that the Home Applicability Statement has been revived, and that they in the process of getting this done. 2) Security Framework plan (Chairs - 5m) [20] Michael Richardson explained the situation with the security framework document. The plan to move it forward as posted to the WG mailing list. Security framework will be renamed Threat Analysis, and published without section 7. But, the security mechanism needs to be specified somewhere, so customers know what to procure, implementers know what to implement. This will be done in the applicability statement. A question from jabber from Jabber (Abdussalam) asking if we are we restricted to layer 2 security, or include security at layer 3? The answer being that it's up to the applicability statement to state something. 3) Applicability Statement template (Chairs - 10m) [30] draft=draft-richardson-roll-applicability-template-00 Michael Richardson presented the document, it's just a table of contents. Feedback was asked for by the end of August. Question is: is this enough? Can we commit to working on this, and applying the template to existing applicability statements? Applicability document authors were asked to go through this template and check if your document fits. If possible, including the numbering. Michael Richardson suggested combining powered (electrical) and unpowered (water/gas) metering may be overly broad. The goal is to uncover issues, discuss on the mailing list, then resolve remaining issues at Atlanta. 4) RPL deployment experience in large scale networks (10mn) [40] draft=draft-hui-vasseur-roll-rpl-deployment-01 JP Vasseur presented an overview of some results from a real RPL deployment experience. This was a city-scale network. The network had between 1 and 7 hops (another deployment had up to 19 hops) Carefully looked at stability, control plane overhead. Results will be provided in the next revision. Delivery rate under "stressed conditions" was above 99%. Did a 3D representation of the DAG (2D + time) to look at less stable spots. The slide shows a 2D snapshot, shows only preferred parent. JP reported that Cisco does not own this network, cannot share more information at this time. Another 5000-node single-DAG network will be ready in two months, and another with mixed P1901.2 and RF and cellular. Feedback? Steve: this draft helped understand what ROLL is trying to do. Recommend to add info (pointers) on security. Command you on work that's been done here. Abdussalam on Jabber: why max hop stopped at 5 hops while we have 100 nodes? JPP: this is not a test network, this is a real deployment, we don't choose the number of hops. Thomas Clausen: transmission power? A: 1 W Thomas Clausen: 1/2 of devices are 1-hop, so only 500 are multi-hop. And 64 channels. Not a whole lot of contention; this looks like it argues you picked the right layer 2, does not say so much about RPL. A: even 5 hops away is routing. Thomas: So 1W is "LLN"? So Wifi is suitable link for LLN? Jonathan: 75 kbit/s, 64 channels, 1W instantaneous, but a lot of duty-cyling to meet the average power consumption. Thomas: not enough information to be validatable Richard Kelsey: document is helpful, could be even more if said how ETX is calculated, how you get your ETX. Q: what about loops? JP: Is this useful? (about half of the hands go up) Michael: who would want more details in this document? a dozen. JP: We will share as much as we can 5) Multicast Forwarding Using Trickle [50] draft=draft-ietf-roll-trickle-mcast-0 Jonathan Hui (about 5 have read) this draft allows simple flooding (N times), but also controlled dissemination with low redundancy (by way of Trickle). Key issue is to determine inconsistency. Lars: Caution, suppresion scheme on flooding has lot of IPR Abdussalam on Jabber: SeedID and SeqNo, but what about RPL-router ID? do you include seed and router ID? A: No, only seed ID. Implementations of similar mechanisms are on-going. Zigbee IP. Michael Richardson: do you expect mDNS to be implemented in LLNs? Zigbee experts? Richard Kelsey: yes Tom Herbst: not quite stock Apple mDNS, xmDNS, which uses wider multicast scope and has different timers Carsten Bormann: you said only the simple flodding part is being used? A: "we" (Cisco) are using the trickle version, too. Doesn't this look like a Reliable Multicast protocol? Thomas Clausen: why are we doing multicasting in the wrong area (looks like transport)? Very flimsy knobs for tuning, a little less horrible... There is a lot of scoping in this document, otherwise cannot be used with a lot of additionnal work. This document is way too general as it is. Yoshi Ohba: IP-in-IP, mailing list, description looks good; handling of hop limit? JH: Does not define scope, you get to choose Adrian: Where does this work belong? Depends on what it is targeted to achieve; for general delivery of IPv6 multicast -- Thomas has a point; achieving routing of multicast would have a strong point to be here. JH: 6man said "what are you doing here" Thomas: heard say this is used to carry mDNS, so not for routing. Ralph: mboned certainly wants to look at this. Carsten: question was architectural point. Does it make sense to mesh up transport and routing? Maybe yes, here. JH: currently orthogonal to RPL. Interesting to see if me can make use of RPL control information. 6) Multicast requirements for control over LLN (10mn) [60] draft-draft-vanderstok-roll-mcreq-02" Peter Van der Stok Room lighting: 200ms latency in most cases, for 1-2s in rare cases seems acceptable. Peter would become people repeating his experiments for confirmation. Carsten: would like to get Thomas and Peter into one room to decide if this is works or not? Thomas: you should state clearly in which condition this was found to work. Jonathan: provided suggestions on the mailing list. 7) sbootstrap, core and 802.15.9 [70] Carsten Borman (15min) Carsten: security topic in other working groups. Cross layer issue. Tero Kivinen Key management only 4 bits for Information Element IDs, some reserved. take one code point, add one byte KMP IE header. Not defining a new KMP. Michael: this is happening in 15.9 Abdussalam on Jabber: is there overload by using this, what's the efficiency compared to 15.4? Carsten: now new mechanism to move keys. 15.4, RPL, CoAP/DTLS all need keys. Secure Boorstrapping protocol proposed within Core WG. One way of doing things. Who needs it? Zigbee needs something like that. Discussion on need for security objectives. CORE WG has a hard time processing this submission because busy working on CoAP. Same kinda thing happened in 6LoWPAN, is happening in ROLL. This s cross layer. Need for an architecture. Suggest this work takes place at IRTF Lars (as IRTF chair): expresses interest in receiving a RG proposal. Yososhi: interested in this work. Scenario should not define just a simple case like light bulb. Carsten: please go ahead and suggest others. But focus will help. A Grand CHallenge. Michael: we need to start with one interesting use case. Excited about this, right way to go. JP seconds.