Subject: [6tisch] Minutes webex 24 January 2014

From: Thomas Watteyne <[email-masked]>
Date: Fri, 24 Jan 2014 10:50:30 -0800

All,

You will find the minutes of the last webex below.

FYI, all the minutes and slides are archived a
https://bitbucket.org/6tisch/meetings/.

Thanks to Xavi and Pascal for taking notes!

As usual, please fix anything we might have missed directly in the e-mail
and reply.

Thomas

-----

Minutes Webex 24 January 2014, 6TiSCH WG

Note: timestamps in PST.
Taking notes *(using Etherpad)*

   1. Xavi Vilajosana
   2. Pascal Thubert
   3. Thomas Watteyne

Present *(alphabetically)*

   1. Alaeddine Weslati
   2. Diego Dujovne
   3. Giuseppe Piro
   4. Kuor Hsin Chang
   5. Maria Rita Palattella
   6. Michael Behringer
   7. Michael Richardson
   8. Nicola Accettura
   9. Pascal Thubert
   10. Pat Kinney
   11. Patrick Wetterwald
   12. Pouria Zand
   13. Qin Wang
   14. Raghuram Sudhaakar
   15. Rene Struik
   16. Rouhollah Nabati
   17. Sedat Gormus
   18. Thomas Watteyne
   19. Xavi Vilajosana
   20. Yoshihiro Ohba

Recording

   - Webex recording (audio+slides,streaming)
   -
   https://cisco.webex.com/ciscosales/lsr.php?AT=pb&amp;SP=MC&amp;rID=74557167&amp;rKey=136ff125f3e0c638<https://cisco.webex.com/ciscosales/lsr.php?AT=pb&SP=MC&rID=74557167&rKey=136ff125f3e0c638>
    *[64min]*

Slides

   - slides_140124_webex.ppt<https://bitbucket.org/6tisch/meetings/src/master/140124_webex/slides_140124_webex.ppt>:
   slides shared during the call

Action Items

   - *Qin* to check whether YANG supports a composite key. Maybe by using a
   new container type.

Agenda

   - Administrivia *[2min]*
      - Approval agenda
      - Approval minutes last call
   - cellID and chunk discussion *[5min]*
   - draft-dujovne-6tisch-on-the-fly *[10min]* *[Diego Dujovne]*
   - plugfest: overview participants *[10min]* *[Xavi Vilajosana]*
   - draft-pritikin-bootstrapping-keyinfrastructures *[20min]* *[Michael
   Behringer]*
   - AOB *[1min]*

Minutes

   - *[08.05]* Meeting starts
   - *[08.06]* Administrivia *[Thomas Watteyne]*
      - Approval agenda

      No issues raised. Agenda approved.

      - Approval minutes last call

      No issues raised. Minutes approved.

      - *[08.08]* cellID and chunk discussion *[Qin Wang]*
      - In the CellList, every cell has a cell id
      - A chunk includes multiple cells, should cellID be the foreign key
      to related CellList and list of cells that form a chunk?
      - *[Pascal]* What is the cellID used for?
      - *[Qin]* Local index to reduce the the size of (index, slotOffset.
      channelOffset, ASN) composite key
      - *[Qin]* Just and ID, not sure if necessary to detail how is created?
      - *[Xavi]* Why not use (slotOffset, channelOffset) as composite ID?
      - *[Qin]* Too many bytes.
      - *[Thomas]* Can we really use cellID if not unique in chunkcells?
      - *[Qin]* The list of chunk cells contains all cells to that chunk
      they are static but have different states (used, not used, etc)
      - *[Thomas]* Might be useful to have a chunk cell status as
      attribute, but identify cells only by (slotOffset,channelOffset).

      Action item: *Qin* to check whether YANG supports a composite key.
      Maybe by using a new container type.

      - *[08.19]* draft-dujovne-6tisch-on-the-fly *[Diego Dujovne]*
      - We agreed to put some order in the issues about the draft. Issues
      on the bitbucket issues tracker.
         - See
         https://bitbucket.org/6tisch/draft-dujovne-6tisch-on-the-fly/issues
      - Solved most of them. Whenever new issue raised on the ML, put in
      the tracker.
      - Improved the allocation policy, explained why one method might be
      better than another.
      - Allocation policy: we are doing pre-allocation, estimated bandwidth
      to parent.
      - Policy means preallocation based on estimates; allocation method is
      implementations.
      - *[Maria Rita]* The different of policy and methodology is clear. It
      looks like single allocation policy can be seen as the single cell
      allocation method and the group allocation policy can be seen as
the bundle
      allocation policy. Both policies seem to overlap.
      - Diego picked Prof. Pister's contribution as the default algorithm,
      if disagree please discuss on ML.
      - How to pass direct commands, how OTF talks to other modules, how
      OTF is called?
      - API from MIBs to get current allocations?
      - Parametrization of the algorithm and other configurations to OTF,
      how to do it?
      - How to obtain BW request?
      - *[Thomas]* Format of extra IEs send by 6top is part of the 6top
      draft.
      - *[Qin]* To answer how to obtain the BW, this can be done by reading
      bundle list.
      - *[Thomas]* The interface internal to a node between OTF and 6top is
      conceptual only, and far less critical than the communication between
      distant nodes over the air. We can define the interface for informational
      purposes, but the important part is what goes over the air.
   - *[08.34]* plugfest: overview participants *[Xavi Vilajosana]*
      - Started to organize agenda for plugfest.
      - Identified 6 groups, although still open.
      - Organization:
         - Focus 1: overview of the platforms and groups (short)
         - Focus 2: Interoperability testing (minimal draft)
         - Focus 3: test minimal RPL implementation see if people could
         implement based on draft.
         - Focus 4: scheduling approaches (centralized and distributed
         approaches). See if there is any implem of OTF
         - Focus 5: Tools (e.g. analyzers, wireshark)
         - Focus 6: Future improvements
      - Confirmed participants:
         - Linear Technology, Dust Networks (US)
            - Thomas Watteyne
         - Cisco (France/US)
            - Pascal Thubert
         - Universitat Oberta de Catalunya (Spain)
            - Xavi Vilajosana
            - Pere Tuset
         - UC Berkeley (USA)
            - Tengfei Chang?
            - Qin Wang?
         - University of Bari (Italy)
            - Niccola Accettura
            - Gennaro Boggia
            - Alfredo Grieco
         - INRIA (France)
            - Alaeddine Weslati
            - Cedric Adjih
         - Ghent University (Belgium)
            - Pieter de Mil?
         - *[Thomas]* Can we have some time for "demo" activities?
      - *[Xavi]* Yes, will add.
   - *[08.42]* draft-pritikin-bootstrapping-keyinfrastructures *[Michael
   Behringer]*
      - Fundamental idea is quite easy to describe. Defined with
      routers/switches in mind thus looking for feedback for 6TiSCH specific
      issues.
      - Comes from autonomic networking project where networks configure
      themselves with no human intervention.
      - Here we use domain certificates, each device will have a device to
      assert that the device belongs to the network. The rest can be made
      autonomic.
      - Question: how can we get that domain certificate. Resource
      consuming but there are stripped down versions of the proposal; in the
      draft we have many variations.
      - Michael is looking for help to adapt this in a 6TiSCH environment.
      - A new device has some authentication material pre-provisonned, e.g.
      802.1AR VENDOR certificates. We use the installed key material at
      manufacturing to bootstrap a second certificate that is a local DOMAIN
      certificate.
      - Until after join the node can not access anything (only layer 2
      connectivity).
      - Domain certificate boostrap?
      - Registrar forwards the client ID to the device factory (VENDOR)
      service. We can prevent the device to join until the VENDOR has
validated.
      Then, the VENDOR can keep a record so next time we know that
this device is
      not brand new and may have been tempered with.
      - Back from the VENDOR, the registrar may decide to accept the device
      or not. For example, policy acceptance if there is an authorization token
      and the device was brand new;
      - Then, the device can make a decision to proceed to joining the
      network based on the content of the authorization token signed by the
      factory (VENDOR). If needed, the VENDOR can control that the device can
      only join the network for which it was sold.
      - The device need only Link local connectivity to join. It cannot
      reach Internet until joined. Without 802.1AR certificate, any device can
      pretend to be some VENDOR. 802.1AR protects against brand/serial
usurpation.
      - The proxy does not need outside connectivity; can be deployed in a
      factory floor. Registrar does need outside connectivity, which can be
      through additional security layer.
      - *[Pascal]* The proxy will be a one-hop device, it can be any
      device. The proxy can be a device that joined the network before.
      - *[Thomas]* If the proxy is transparent, a mote can be flooding the
      network as the messages will be routed to the registrar. Is
there a way to
      have some gate-keeping at the proxy?
      - *[Michael B.]* Yes. Several straightforward method, e.g. throttling.
      - *[Rene]* How to build the authorization token?
      - *[Michael B.]* The cloud service has a mapping between customers
      and node IDs, then the token is generated on the server side.
      - *[Michael B.]* Without that token, the device may join any network
      it likes, this is what the authorization token protects
      - There can be different modes of operation depending on how much
      control the vendor will have vs. knowledge about the deployment
      - *[Rene]* Need evidence of the cryptographic operations and
      associated cost.
      - *[Michael B.]* Normal certificate cryptography, TBD if that fits in
      a sensor. Smart cards have that facility on board.
      - *[Thomas]* is draft intended for a particular WG?
      - *[Michael B.]* Started in Homenet as bootstrap mechanism, was a lot
      more high level. Found that the problem is more generic and would work in
      many WGs.
      - *[Michael B.]* Planning to take through various WG and security
      area. Lots will happen at next IETF.
   - *[09.09]* AOB *[1min]*

   No other business raised.

   - *[09.09]* Meeting ends