[6tisch] draft Minutes, 06 January 2017 interim, 6TiSCH WG

["Pascal Thubert (pthubert)" <[e-mail]>]

Note: timestamps in PDT.

Connection details

  *   Date: 7-8am Pacific: http://www.worldtimebuddy.com/?qm=1&lid=100,12,5392171,1850147&h=100&date=2017-01-06&sln=15-16
  *   Webex link: https://cisco.webex.com/ciscosales/j.php?MTID=mcdbbe3a4e38d97d986b507ec12a1f9b1
  *   Webex Recording: https://cisco.webex.com/ciscosales/lsr.php?RCID=fa73c99b14374da3b294293165343e0b
     *   Recording password: bPAxMQh2

Taking notes (using Etherpad)

  1.  Thomas Watteyne
  2.  Pascal Thubert
  3.  Michael Richardson

Present (alphabetically)

  1.  Thomas Watteyne
  2.  Pascal Thubert
  3.  Georgios Papadopoulos
  4.  Irina ?
  5.  Jonathan Munoz
  6.  Marek Gradzki
  7.  Malisa Vucinic
  8.  Michael Richardson
  9.  Pat Kinney
  10. Qin Wang
  11. Ralph Droms
  12. Rashid Sangi
  13. S.V.R. Anand
  14. Simon Duquennoy
  15. Sedat Gormus
  16. Yasuyuki Tanaka
  17. Diego Dujovne

Agenda

  *   Administrivia [2min]
     *   Approval agenda
     *   Approval minutes last call
  *   draft-ietf-6tisch-minimal [25min]
     *   goal: go over the issues, propose resolutions, reach consensus
     *   comments by Brian Carpenter

https://www.ietf.org/mail-archive/web/6tisch/current/msg05064.html

     *   comments by Ralph Droms

https://www.ietf.org/mail-archive/web/6tisch/current/msg05101.html

     *   comments by Tero Kivinen

https://www.ietf.org/mail-archive/web/6tisch/current/msg05094.html

  *   draft-ietf-6tisch-6top-protocol [25min]
  *   AOB [3min]

Minutes

*        Administrivia [2min]

     *   Approval approval

Proposal to focus the whole call on Minimal and delay the 6P discussion: no objection raised

     *   Approval minutes last call

No remark raised, minutes adopted

*        draft-ietf-6tisch-minimal [25min]

o   goal: go over the issues, propose resolutions, reach consensus. Thomas makes the presentation:

o   4 very thorough reviews. Many editorial, suggestions accepted fr one.

     *   For the 3 others, prepared answers to discuss today, more below.
     *   asked authrs to publish -18 by end of next week.

o   Thomas will his ppt application, so as to take notes on the fly

o   comments by Brian Carpenter

https://www.ietf.org/mail-archive/web/6tisch/current/msg05064.html

        *   last call review, 3 major issues, and nits. Thomas going one by one.
        *   Major comment 1 asked about what the 6Lowpan framework is. Answer is to list RFCs, including 6LoRH. Resolution shown, and accepted by the WG at the call.
        *   Major comment 2 says abstract is confusing, replace by 6TiSCH
        *   Major comment 3 missing security section. A complete rewrite is now being done based on Tero's comments. The suggested text will be presented on the ML later.
        *   Minor comment 1: used of 'exactly' is improper, word is removed.
        *   Minor comment 2: title is wrong, it's content not format that can vary
        *   Brian agreed with minor and editorial proposed resolutions.
        *   Minor comment 3: text in v17 said "should" indicate source address. Resolution: this is not an IETF decision, it is an IEEE thing, so we should drop these sentences and indicate which frame versions are used, whihc in turn reflect the packet formats.
        *   Minor comment 4: relates to Tero's review, let's delay that discussion to the answers to Tero's review.
        *   Nits should be no problem.

o   comments by Ralph Droms

     *   Summary was that the role/scope of the draft was unclear and that the draft was not ready for publication. Ralph misted several points.
        *   [Pascal] point 2 and 3 are important, using 2 only looses some value.
        *   Thomas: we are not defining a new protocol. We are defining the simplest way of using it.
        *   Pascal: yes, it's a best practice.
        *   Michael: could we call it bootstrap or something
        *   Pascal: we have used that name for so long
        *   Michael: minimal provides a way to do the bootstrap, needed for the secured bootstrap. That explains why the security of minimal is low.
        *   (Ralph joins at this point): This doc could say what it uses and also document what it does not use and why. Obviously you cannot list all the 9000 RFCs that are not used here, but at least comment on what could be expected to be there, e.g. IPv6 ND. Only the protocols that have an effect on 802.15.4 are discussed here.
        *   Thomas: yes, this doc stays at the edge of 6LoWPAN and IEEE. Action item for the authors, include text on the scope and goal.
        *   Ralph: suggestion to add that the document describes the specific IETF protocols that are the interface of the IEEE and the IETF pieces.
        *   Pascal: CC'ing the link on the etherpad to Ralph on the webex chat, asking Ralph to review/ fix the notes as they are being taken.
        *   Thomas: asking clarification on major issue 2.
        *   Ralph: initial confusion reading the draft. doc say that minimum mode of operation uses a particular slot schedules and says that a node learns the schedule as it joins. Initially unclear how the node learns the schedule. Q: what's the point of describing that particular schedule if the standard allows a node to learn on any schedule. What does a node do if it sees a different not minimal schedule?
        *   Thomas: what you described is correct. A node listens to EBs and learns a schedule. No specific minimal format. What if something different? would be fine, but we expect other protocols (6P) to negotiate that
        *   Ralph a sentence to the effect of saying that this is a recommended starting point.
        *   Pascal: we are also saying that we do not ask to support everything that could be announced by IEEE std 802.15.4 EBs, but every 6TiSCH node should support at least this fixed schedule.
        *   Ralph: 2 different ETX, the latter cumulative. Is text clear about that or is it me being confused? ETX metric in the reliability object is cumulative all the way to destination, whereas there is a hop by hop ETX for a hop that gets accumulated along a path. Is there text ?
        *   Michael: pls reword the question [thank you]
        *   Thomas: Q is whether RFC 6551 and 6719 are clear enough on ETX computation and accumulation, or if more text is needed. Action item to the authors and WG to validate that.

https://www.ietf.org/mail-archive/web/6tisch/current/msg05101.html

o   comments by Tero Kivinen, presented by Thomas

https://www.ietf.org/mail-archive/web/6tisch/current/msg05094.html

        *   Major point 1: missing security section; this is being addressed.

?  Major point 2: endless discussion on K1 and K2. K1 being given away. K1 is a key used in CCM*but not a a security thing. We use it to check that and EB comes from a 6TiSCH network and the EB could be sent completely in the clear. With K1, we get a better MIC but no security. Trouble it looks like we are doing something secure because there's a key. It is just a super CRC. New text will rename this as not being a key, and detail that in the security section. Author agree that it was badly discussed and that the security section was really missing to explain that.

?  Pascal: this is not just the authors preference, this is the WG consensus

        *   Thomas: true, text was crafted over multiple WG meetings.
        *

*        draft-ietf-6tisch-6top-protocol [25min]

     *   skipped
     *
  *   AOB [3min]
     *   Pascal: We need to prepare fo rthe next meetin. How much time (2H?) and which incompatibilities?
     *   Thomas: yes, we probaly need 2H this time.