Minutes for 6TISCH at interim-2016-6tisch-5
minutes-interim-2016-6tisch-5-3

    ## THIS IS A DRAFT!!! ##

# Minutes, 11 March 2016 interim, 6TiSCH WG #

Note: timestamps in PST.

Connection details
------------------

* Date: 7-8AM Pacific:
http://www.worldtimebuddy.com/?qm=1&lid=100,12,5392171,1850147&h=100&date=2016-03-11&sln=15-16
* Webex
recording:https://cisco.webex.com/ciscosales/ldr.php?RCID=8dabef427d86849b5a91b0a138fafbd1
* Meeting Slides:
https://bitbucket.org/6tisch/meetings/raw/be4f76125c8db0d80556b5f651a30e567eff7039/160311_webex/slides_160311_webex.ppt

Taking notes _(using Etherpad)_
-------------------------------

1. Michael Richardson
1. Pascal Thubert
1. Thomas Watteyne
1. Xavi Vilajosana

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

1. C-Y Lee
1. Diego Dujovne
1. Dominique Barthel
1. Jonathan Munoz
1. Lijo Thomas
1. Maria Rita Palattella
1. Michael Richardson
1. Michel Weillette
1. Nicola Accettura
1. Pascal Thubert
1. Pat Kinney Kinney
1. Qin Wang
1. Rene Struik
1. S.V.R. Anand
1. Shalu R
1. Tengfei Chang
1. Thomas Watteyne
1. Xavi Vilajosana
1. Zhuo Chen

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

1. Pascal to progress on the 6p encoding with Pat and 6T IG
2. Diego to publish refresh prior to cut off

Agenda
------

* Administrivia _[2min]_
    * Approval agenda
    * Approval minutes last call
* Misc and Charter news  _[5mn]_
* Preparing IETF 95 _[10mn]_
    * agenda, who’s coming?,
    * other WG of interest & interaction)
* ANA and IANA needs and status _[10mn]_
* 6p and Sf0 issues _[QSP]_
* AOB _[1min]_

Minutes
-------

* _[07.04]_ Meeting starts
    *
    *
* _[07.0x]_ Administrivia _[2min]_
    * Approval agenda
       * agenda is approved. No issues raised
    * Approval minutes last call
    * last call minutes are approved. No issues raised.

* _[07.xx]_ Misc and Charter news  _[5mn]_
    * There is a new charter, congrats.
    * aim to produde SF0
    * provide requirements for detnet
    * keep working on the architecture
    * YANG data models left to later phases.
    * secure 6tisch neThomas Wattteyneork bootstrap.

* _[07.xx]_ Preparing IETF 95 _[10mn]_

    * agenda, who’s coming?,
       * Monday 4th 14 to 15.30 (6pm to 7:30pm in CET)
       * preliminary agenda
       * draft cut off date in 10 days.
       * objectives:
            - update sf0 draft (diego)
            - update and rename 6top sublayer to 6top protocol.
            - terminalogy draft to be clean up and publish
            - call for adoption for 6p and sf0
            - report the PT and talk about the Berlin Plugtest

       * Pascal: would like to see a status on where we are with the security
       work, which has been interrupted for a long time. * Michael Richardson:
       can produce 2 slides to position the work and see where we are. Willing
       to speak but remotely since not attending Buenos Aires.

    * other WG of interest & interaction)

* _[07.15]_ANA and IANA needs and status _[10mn]_

    * Pat Kinney outlined different choices for the IETF IE
    * Pat Kinney: 6TiSCH should ask for a OUI
    * Pat Kinney: there are 3 options. they are exclusive.
        * Vendor specific ID is in the standard and can be used. the Vendor
        Specific ID requires us to use an OUI but we cannot do that. * a second
        choice is to get an ID in IANA. There is a procedure. We need a formal
        request from an IETF representative. * Final option is ESDU IE meant to
        use for an upper layer, the MAC layer passes it to the upper layer
        without checking it.

    * Pascal: This will still require a dispatch type but handled by IEEE.
    Could the 6T IG discuss that in Macau next week? * Pat Kinney: will be
    presenting this to the interest group that will look into this as an
    standardization group whereas we see it more as a user group. * Thomas
    Watteyne: option 2, IETF will produce an RFC that will tell IANA explaining
    how this ID is managed. * Thomas Watteyne: how do we proceed? do we have
    this discussion in the ML? do we have a volunteer to read and see what are
    the pros and cons of it. * Pascal volunteers to evaluate the options.
       * Pat> on the ESDU case the 6top can come with the format.
       * Pat Kinney to send a msg to the reflector indicating what is the
       discussion and the resolutions.
    * Michael: does the wg prefer the option 2?
    * IEEE allocates one of these payload IE group IDs to the IETF. The IANA is
    the registry for the IETF value. * Choice 2 is 2 byte shorter. * Pascal:
    No: we will need some dispatch with the OUI as well as there are few of
    these. * Pat Kinney: why not a header IE. Do we need a header IE? * Thomas
    Watteyne: 6top packets will be transported in the payload IEs. So no header
    IEs are needed as far as we can tell now.

* _[07.31]_6p and Sf0 issues _[QSP]_
    * proposal to indicate what the 6p protocol adds a requirement to the SF so
    it indicates the metrics and statistical operations used to operate. * Xavi
    proposed a text. * Diego agrees with the text * The requirement from 6p is
    a SHOULD. * Pat Kinney are there any statistics mandatory? would we assume
    defualts?

    * Thomas Watteyne: Algorithm made from many types of statistics. No need to
    list the collected ones. MUST can be empty, since we may not use always
    statistics.
Default metrics?
    * Thomas Watteyne: Default metrics, we do not know if we can default
    something at that moment * Pat Kinney: should indicates me that I do not
    have to provide it. * Thomas Watteyne: proposes MUST provide ..., if use by
    the algorithm. ACTiON: Diego to propose the reworded text. * add 8bit token
    field to the 6P header. * match a request to a response.
          - do we really need a token?  -- consensus is yes. It is needed, not
          only because it enables to support concurrent transactions but also
          because it enables to differentiate one request to the previous one.
          - Diego: what about the timeout. Could we use the timeout. Qin: Do we
          need 8 bits for the token? as this is for a pair of nodes. - PT:
          reduce it to less bits and use a sequence number. - can we use the
          ack?    -- clarification: referring to l2 ack. The ack does not tell
          that the packet has been processed but only received. It is useless
          in terms of semantics of the protocol.    -- - can a child ask more
          cells before receiving an ack?   -- in the 3 phase negotiation the
          3rd message is like a 6top ack message who confirms and closes the
          transaction. the 6top layer ack in that case is similar to the MAC
          layer ACK.  -- - starting 6p transaction from receiver. - if B is the
          parent and B has granted the cells to A. Is there a mechanism to
          reclaim that cells. - Pat Kinney: use lease ? - Xavi: use Delete
          request
    * Zhuo: do we have a timeout scheme for expiration in case that a node is
    disconnected from the network?
          - Pascal: In case of a disconnect and reconnect we need to resync the
          state

          - Proposal on the ML was ti use a bitmap instead of specific cells.
          Let a node when joins get a bundle and then use a bitmap to decide
          what cells of that bundle are active. - to be further discussed.

* _[08.10]_AOB _[1min]_
    * Authors need to have a working session to work SF0 and 6P before cutoff
    *  we need to have a call the 25th March?
    *  PT: If not we coudl have a security discussion? can propose to the ML to
    recap on security...

* _[08.xx]_ Meeting ends
    * poipoi