Minutes interim-2017-6tisch-02: Fri 07:00
minutes-interim-2017-6tisch-02-201701060700-01

Meeting Minutes IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch) WG
Title Minutes interim-2017-6tisch-02: Fri 07:00
State Active
Other versions plain text
Last updated 2017-02-07

Meeting Minutes
minutes-interim-2017-6tisch-02-201701060700

   ## DRAFT ##

# Minutes, 06 January 2017 interim, 6TiSCH WG #

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
1.

Present _(alphabetically)_
--------------------------

1. Thomas Watteyne
1. Pascal Thubert
1. Georgios Papadopoulos
1. Irina ?
1. Jonathan Munoz
1. Marek Gradzki
1. Malisa Vucinic
1. Michael Richardson
1. Pat Kinney
1. Qin Wang
1. Ralph Droms
1. Rashid Sangi
1. S.V.R. Anand
1. Simon Duquennoy
1. Sedat Gormus
1. Yasuyuki Tanaka
1. Diego Dujovne

Action Items
------------

1. poipoi

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]
    * goal: go over the issues, propose resolutions, reach consensus. Thomas
    makes the presentation:

    * 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.
    * Thomas will his ppt application, so as to take notes on the fly

    * 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.

    * 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 bootstap or something * Pascal: we have used
        that name for so long * Michael: minimal provides a way to do the
        bootstap, 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 dicument 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 thta 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 partiular 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? woudl 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 annouced 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

    * 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 discusison 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 supert CRC. New text will rename this as not being a
        key, and detail that inthe security section. Author agree that it was
        badly dicussed 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.