Note: timestamps in PST. Connection details
________________________________ * Webex: https://cisco.webex.com/ciscosales/j.php?MTID=m52db5e679e5629fc43265c638d55546c * Etherpad: http://etherpad.tools.ietf.org:9000/p/6tisch?useMonospaceFont=true * Topic: 6TiSCH Bi-Weekly * Time: 7:00 am, Pacific Daylight Time (San Francisco, GMT-07:00) * Meeting Number: 206 802 913 * Meeting Password: sixtus * CCM: +14085256800x206802913 Resources * Webex recording: https://cisco.webex.com/ciscosales/lsr.php?RCID=d6e67b5ca8944585a16db89dc230de8f * Wiki: https://bitbucket.org/6tisch/meetings/wiki/150424_webex * Slides: https://bitbucket.org/6tisch/meetings/src/master/150424_webex/slides_150424_webex.ppt To Do * Pascal to ask the list about the security text in minimal, should we specify a key. * Pascal to conclude about removing the e on the ML, and discuss about references in the drafts. ________________________________ Minutes takers 1. Diego Duvojne 2. Pascal Thubert 3. Thomas Watteyne Present (alphabetically) 1. Thomas Watteyne 2. Pascal Thubert 3. Chonggang Wang 4. Diego Duvojne 5. Elvis Vogli 6. Geraldine Texier 7. Giuseppe Piro 8. Ismail Hakki Turan 9. Kris Pister 10. Malisa Vucinic 11. Maria Rita Palattella 12. Michael Richardson 13. Michel Veillette 14. Nicola Accettura 15. Pouria Zand 16. Qin Wang 17. Rene Struik 18. S.V.R.Anand 19. Savio Sciancalepore 20. Tamer Elzayyat 21. Xavi Vilajosana 22. Zhuo Chen Agenda * Approval * Agenda * Minutes last call * Updates since last call * Architecture draft last call [Pascal Thubert] [5min] * Minimal Support draft [Xavi Vilajosana] [5min] * IEEE proposed change on join security for 2015 release [5min] * ML Discussion on impact of 15.4:2015 on 6TiSCH [10min] * IEEE references best practices (removing the 'e') [20min] * ETSI plugtest [10min] * AOB Minutes * [07.05] meeting starts * [07.06] Approval * Agenda bashing * Minutes last call * Rene points out some minutes were not approved from security call * Thomas proposes to put them on the Agenda of the next meeting * Rene accepts. * Minutes from Dallas and Last call: Approved * Updates since last call * [07.10] Architecture draft last call [Pascal Thubert] [5min] * PT: All the components should be together on this draft. Ask the * Editor to accept the document in the current state and complete it after. * Shwetha received replies from the commentators for -07 version. * Rene: Asks for more time to review and sends comments * PT: The picture has not changed * KP: People more delay tolerant. Great work, too many comments, still not ready for IESG. * PT: How much work still to do? * KP: Bottom up contribution . * PT: Propose the text. Refine this proposal. * TW: Leave the recommendations for next call (2 weeks time) * KP: OK. * PT: We will need to reopen the last call. Let's check on the proposed changes from KP. * KP: OK. * PT: Clarify document to improve IESG review process. * [07.21] Minimal Support draft [Xavi Vilajosana] [5min] * XV: Security section changes * Call for consensus from Rene's comments. * Proposed text I and II; call for consensus. * Rene: Is this on the ML? * XV: The first text is on the ML, the second is here. * Rene: Was there consensus from Dallas? * XV: K1 discussion from the ML, so new alternative, Candidate Text II * TW: Ask for comments on the call. * TW reads Slide 13. * Rene: May cause potential problems. Minimal does not include any security because it is not finished. Problem on the security policy, still not defined. Why conclusion on the slides? * There is a document I wrote and it was available for 3 months, presented in Dallas. * KP: We need a low level approach too. * TW: Send both Candidate Text to the ML to enable discussion * XV: * MR: Remove bootstrap. It may mean coordinate time. That should mean something else. * TW: There is no security setup at the beginning * PT: Remember this is the minimal. These are high touch? networks. This may confuse people about the complexity of the problem * Rene: I don't understand why the text candidate I has a problem. Given what is written, there should be nothing offensive on it, * TW: Take back the text candidate II? * PT: We should have a K1. * TW: More discussion needed. Xavi: send this on the ML? The Key is spelled out on the Candidate Text II. * Rene: This was discussed before. * PT: Should we provide a default K1? * KP: Add one more sentence only. * TW: Ask to add a default K1, keep candidate 1. * [07.??] IEEE proposed change on join security for 2015 release [5min] skipped. PDF problems. * [07.43] ML Discussion on impact of 15.4:2015 on 6TiSCH [10min] * TW: Discussion, follows three options. * Are we talking on changing the text of the charter or update references on the drafts? * Scope: Slide 78 Dallas: Changing the text on all the I-Ds or the charter? * PT: problem when we need a particular format/api. Keep the most independence from specs is the way to go, there is a loose coupling. For Archie, is loosely coupled, but for Minimal it is tightly coupled. Depends on the I-D: The I-D should need a new version if the IEEE spec changes. * 6LoWPAN has conflicting references in RFC 4944 &nd 6282, which makes them incompatible on paper, and both are outdated. * KP: Take out e from the charter. Different on Minimal, requires changes. * MR: Specific documents, specific references. From the ethernet examples: IEEE tried to make everything look like ethernet when it wasn't. Legacy problems. This has not been a good thing. * PT: Document most vulnerable to changes on 802.15.4: Minimal. * PT: What if we do not date a reference? * then we have an argument against a change things that would break the RFC and can escalate * Conflict is resolve by either an updated RFC or a change at IEEE. * MR: Add a "later than" reference? * PT: Not recommendable. * Rene: Example: 2006 spec does not work 2003 spec. * PT: As long as the RFC works with 2003 and with 2006, we are OK. The standards (eg ZigBee) that adopt an IEEE standard in their stack must guarantee interop by specifying a version if they need to. * We are providing a component that should work on different conditions, not tightly coupled when we can avoid it to IEEE. * TW: Next step? * PT: We have not asked the question clearly enough. From the IETF perspective. Scenarios if the standard becomes broken. * TW: Proposals? Dedicate next call exclusively to this? * PT: Dated reference or not in minimal? I explain on the ML. * TW: Make a proposal. * [08.??] IEEE references best practices (removing the 'e') [20min] skipped * [08.07] ETSI plugtest [10min] * MR: Prepared the Plugfest. Document: Test description. Interop tests, Golden device with Minimal. What will be the features to check, schedule, timeslot time, RPL. First draft with the table. First milestone 24 April for the draft, shared on the ML. Next milestones June 1st. * TW: Shos things out of the minimal draft, send them on the ML. Not change Plugfest scope. Hackathon on the same days. Might invite them to show 6tisch implementations. * [08.??] AOB No other business. Next call May 8th. * [08.??] meeting end Cheers, Pascal
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
