Minutes for 6TISCH at interim-2015-6tisch-12

Meeting Minutes IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch) WG
Title Minutes for 6TISCH at interim-2015-6tisch-12
State Active
Other versions plain text
Last updated 2015-09-04

Meeting Minutes


* Administrivia _[2mn]_
    * Approval agenda
    * Approval minutes last call

* Post Mortem ETSI PlugTest  _[15mn]_

* WG activities till Yokohama  _[15mn]_

* New charter bashing  _[20mn]_

* AOB _[1min]_


* Webex recording:
* Wiki: https://bitbucket.org/6tisch/meetings/wiki/150904_webex
* Slides:

Taking notes _(using Etherpad)_
1. Xavi Vilajosana
1. Pascal Thubert

Action Items

ACTION: Xavi to add to minimal how the ASN is written in nonce (Byte order).
ACTION: Pascal to initiate discussion on chunks in minimal.

Present _(alphabetically)_

1. Pascal Thubert
1. Diego Dujovne
1. Giuseppe Piro
1. Malisa Vucinic
1. Maria Rita Palattella
1. Pat Kinney
1. Paventhan
1. Pouria Zand
1. Qin Wang
1. Savio Sciancalepore
1. Tengfei Chang
1. Thomas Watteyne
1. Tom Phinney
1. Xavi Vilajosana
1. Zhuo Chen


* Administrivia _[2mn]_
    * Approval agenda
    * Approval minutes last call
* Post Mortem ETSI PlugTest  _[15mn]_
* WG activities till Yokohama  _[15mn]_
* New charter bashing  _[20mn]_

Minutes (all times in Pacific Time)

* _[07.07]_ Meeting starts

* _[07.07]_ Agenda
  * review of IETF meeting and plugtest
  * roadmap to yokohama -* plan

      * Agenda is approved
      * Minutes of the Prague meeting are approved.

* _[07.08]_ Prague review
   * Etsi plugtest

      * Thomas goes through report, thanking ETSI for organization
      * Thanks to openmote to help organize

   * hackathon around 6tisch.

       * Some prizes were given to best developments related to 6tisch
       technology * again thanks to openmote

* _[07.11]_ 6TiSCH Action Plan

   * Minimal almost ready to publish
   * We need a plan to reach the 2nd plugtest with solid things to implement
   * Action Plan

       * standardize necessary piece for a scenario presented
       * running OTF
       * Security driven by a JCR
       * JCE is in the network. A node when joins needs to authenticate to the
       network. There is a key K1 that enables to authenticate the node. * A
       nodes uses the JA to forward the JCE authentication * We use COSE to
       protect with a small footprint the packet (overhead smaller than 10B) *
       JCE tells to the JN the one or multiple K2s that are used to participate
       in the network. * JCE can install a key for every neighbor of a node. *
       Giuseppe: the network has 2 Keys. When a joining node communicates for
       the first time only knows a key (K1). * Whatever H sends to F is the
       payload that F has to forward to the JCE * Malisa: we need to define a
       mechanism for the JA to forward the message of the joining node to the
       JCE. * We need a mechanism in F to determine if the packet is malicious
       or wants to Deny service. * Can the joining node once it has joined
       establish communication to other nodes in the network?. * Thomas: we
       need to support any case. * Thomas: install a master key and derive the
       keys from there. * the PSK is pre-established. The PSK is only used to
       authenticate. THen the JCE distributes a K2 which is used to secure. *
       Pascal: find the minimal set of mechanism so we can secure the network.
       * Requirements: Lean overhead of COSE * 6top interface: very complete
       but at the same time every single item in there can trigger lots of
       discussion. Would be good to take the minimal approach and try to
       identify the essential pieces. * We need the interfaces to enable the
       JCE to install the key. As a todo, we need to simplify the interfaces
       for the JCE to be able to install the keys. * Xavi: mechanism to add and
       remove cells are needed. * Xavi: supports keeping only the minimal *
       Qin: asking confirmation of understanding; then about OTF, need soft
       cell negotiation * Qin: Soft cell negotiation is also needed. Should
       this be included in the draft? * Thomas: eventually will be needed. The
       way is done we still do not know. We need to work on that. * Qin:
       suggests to move the negotiation of in the interface draft. * Thomas,
       efficient solution to negotiate for cells. Encoding of the information
       that goes over the air. We are putting OTF at the end of a very long
       chain, interface, coap, comi, etc.. then we can start playing with OTF
       as we need all the rest.  This is blocking OTF until everything is done.
       * Pascal T: IEEE is aiming new for to define LLC, they will probbaly not
       want negotiation mechanism that has dependencies on CoAP etc... * Pat
       Kinney: IEEE effectively considering to define a mechanism for LLC to
       take care of cell negotiation and key management.  come up with a single
       entity that simplifies the development. * Thomas: lets make sure that we
       work together on that and we do not repeat everything. * Pat: we do not
       want to duplicate!! we want to turn into standard inside the LLC we are
       going to make it standard instead of a recommendation. OTF is a little
       algorithm that decides when to add or remove a cell. There will be
       always people that will not like or fit into it that algorithm. So we
       need to make sure that nodes can discover what is the algorithm that is
       being used. * PT: supports that, and compares it to RPL. The Objective
       function is similar case. * Thomas: The MOP is announced, is the OF
       announced? * Pascal: No, it is administratively enforced.

* AOB:

       * Pascal AOB?  Next meeting September 25

* _[08.02]_ Meeting ends