Minutes for 6TISCH at interim-2014-6tisch-1
minutes-interim-2014-6tisch-1-1

# Minutes Webex 10 October 2014, 6TiSCH WG #

Note: timestamps in PDT.

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

* Webex:
https://ciscosales.webex.com/ciscosales/j.php?ED=219615007&UID=481905242&PW=NZTRkNDAwOTE1&RT=MiMyMw%3D%3D
* Etherpad: http://etherpad.tools.ietf.org:9000/p/6tisch?useMonospaceFont=true
* Topic: 6TiSCH Weekly * Time: 8:00 am, Pacific Daylight Time (San Francisco,
GMT-07:00) * Meeting Number: 206 802 913 * Meeting Password: sixtus * CCM:
+14085256800x206802913

Resources
---------

* Webex recording:
https://cisco.webex.com/ciscosales/lsr.php?RCID=36a3b7df06694258a3ac65bfc519212f
* Wiki: https://bitbucket.org/6tisch/meetings/wiki/141010_webex * Slides:
https://bitbucket.org/6tisch/meetings/src/master/141010_webex/slides_141010_webex.ppt

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

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

Present
-------

1. Thomas Watteyne
1. Pascal Thubert
1. Ariton Xhafa
1. Diego Dujovne
1. Guillaume Gaillard
1. Ines Robles
1. James Pylakutty
1. Maria Rita Palattella
1. Michael Richardson
1. Nicola Accettura
1. Pat Kinney
1. Patrick Wetterwald
1. Raghuram Sudhaakar
1. Rene Struik
1. Sedat Gormus
1. Xavi Vilajosana

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

* **Pat** to look into the 15.4e specs and send e-mail to ML about whether a
node is required to join the node which advertises the lowest priority. *
**Thomas** to publish new version draft-ietf-6tisch-tsch based on discussion. *
**WG** to review completeness of YANG interface in
draft-ietf-6tisch-6top-interface * **Xavi** to update
draft-ietf-6tisch-6top-interface and replace "IEEE802.15.4e" by "IEEE802.15.4"
* **Xavi** to publish current version of draft-ietf-6tisch-6top-interface *
**WG** to participate in 6lo and push for the HBH compression draft. *
**Pascal** to send email to 6TiSCH ML to get consensus on going with compressed
RPL option within 6lo.

Agenda
------

* Administrivia _[3min]_
    * Approval agenda
    * Approval minutes last call
    * update format of calls
    * IETF91 6TiSCH WG meeting
* Wrapping up draft-ietf-6tisch-tsch _[15min]_
* YANG model _[15min]_
    * updates to format
    * is interface complete?
* Closing discussion on use of flow labels _[15min]_
* RFC7322: RFC Style Guide _[5min]_
* AOB _[2min]_
    * reminder next calls

Minutes
-------

* _[08.05]_ Meeting starts
  * Administrivia _[3min]_
    *  **Pascal** starts recording
    * Proposed Agenda **[Thomas]**
        * TSCH draft
        * YANG model format
        * Close discussion of flow labels
        * RFC7322
    * Call for approval Agenda **[Thomas]**
    > No issues raised. Agenda is approved.
    * Call for approval minutes last call **[Thomas]**
    > No issues raised. Minutes last call approved.
    * Update on interop eveny **[Thomas]**
        * ongoing discussions with ETSI to organize 6TiSCH interop during
        IETF93 (Prague, Czech Republic, July 19-24, 2015) * companies
        implementing 6TiSCH, mark your calendars * ETSI will participate in
        defining interop tests and associated framework * **[Pascal]** idea is
        to push minimal draft to IESG end of November * **[Michael]** Results
        from interop may trigger updating the RFC * **[Pascal]** absolutely

    * Format of the calls have changed **[Thomas]**
        * we haven't been following the IESG guidance on interim meetings
        (https://www.ietf.org/iesg/statement/interim-meetings.html) * has been
        corrected now. New procedure:
            * calls announced to 6TiSCH ML and ietf-announce at least 2 weeks
            before * agenda sent to 6TiSCH ML at least 1 week before * minutes
            and attendance published on 6TiSCH ML, CC proceedings@ietf.org at
            most 10 days after call
    * IETF91 (Honolulu, Hawaii, November 9-14, 2014,
    http://www.ietf.org/meeting/91/)
        * 90min session requested, early in the day for remote presentations
        through meetecho * preliminary agenda to be published today at
        https://datatracker.ietf.org/meeting/91/agenda.html

  * _[08:13]_ wrapping up draft-ietf-6tisch-tsch **[Thomas]**

    > **Thomas** goes over slides to recap the changes suggested in
    http://www.ietf.org/mail-archive/web/6tisch/current/msg02547.html

    * **[Maria Rita]** Answered e-mail with typos fixed.
    * **[Pascal]** Same, answered e-mail with typos fixed.
    * **[Ines]** About issues she raised, agrees with the rewording.
    * **[Thomas]** We need to discuss if we want to put lots of text about join
    priority in this draft. * **[Rene]** Are we going to use this join priority
    in the 6TiSCH work? * **[Thomas]** yes. * **[Rene]** Not sure why we should
    use this, as only one parameter a mote can use to choose a node to attach
    to * **[Pat]** the join priority is intended for a device to select which
    beacon to respond to in case it receives more than one. It is not mandatory
    to join the one with lowest priority, is only information a mote can use. *
    **[Rene]** I think that the spec indicates to join the node with lowest
    priority. * **[Pat]** yes, but which node a new node joins depends on what
    the device decides is important. * **[Thomas]** In the end, a node can join
    whichever node it wants. * **[Pascal]** We do not want to describe how
    6TiSCH uses the join priority in draft-ietf-6tisch-tsch, this draft is
    about information and context. > Action item: **Pat** to look into the
    15.4e specs and send e-mail to ML about whether a node is required to join
    the node which advertises the lowest priority. * **[Rene]** checks if this
    is mandatory, the text just indicates that a node selects a node according
    to the join priority. * **[Thomas]** the text indicates "preference" so
    this is not mandatory. * **[Pat]** if you want to change you can change it
    * **[Rene]** we are discussing if this is a 6TiSCH issue. * **[Pat]** for
    me is an implementer issue. This discussion is beyond the scope of the
    standard. This is part of the implementer's decision. * **[Thomas]** Lets
    continue discussion on ML. * **[Rene]** I need technical arguments. >
    Action item: **Thomas** to publish new version draft-ietf-6tisch-tsch based
    on discussion.

  * _[08:30]_ YANG model in draft-ietf-6tisch-6top-interface **[Xavi]**
    * goal of today's presentation: explain what was done in the draft, and
    call for reviews * YANG doctor Carl Moberg helped Xavi and Qin fine-tune
    the syntax of the YANG model. Did NOT touch semantics of it. * Xavi believe
    the YANG model is complete, with maybe some very minor syntactic changes. *
    Xavi calls for the WG to review the contents of the model. This model is
    one of the important outputs of 6TiSCH. We need a deep look into it . >
    Action item: **WG** to review completeness of YANG interface in
    draft-ietf-6tisch-6top-interface * YANG model divided into 6top MIB and
    15.4 PIB * status for 6top MIB: model present in draft. Carl Moberg did
    syntactic review only (only grammar, not semantics) > Xavi shares screen to
    show table corresponding to YANG model in draft * **[Thomas]** What changes
    did Carl Moberg suggest? * **[Xavi]** When expressing the target node
    address, can be of two types (2B or 8B). Expressing in YANG is complicated.
    Doctor helped, created a group (~type) * **[Thomas]** Similar to an enum? *
    **[Xavi]** Yes, similar. * **[Pat]** IEEE802.15.4e is part of the
    IEEE802.15.4 standard. You can drop the "e" in the descriptions. > Action
    item: **Xavi** to update draft-ietf-6tisch-6top-interface and replace
    "IEEE802.15.4e" by "IEEE802.15.4" * Xavi describes the different sections
    in the MIB. Xavi asks people to go through elements, and list what is
    missing. * **[Thomas]** We are chartered to define this set of elements.
    This is a critical contribution in this charter. Let us take a couple of
    weeks to fully review that data model. * 15.4 MIB was discussed at IETF90.
    Will provide a single interface to access 15.4 interface. * next steps:
    review functionality, easy since only mapping PIB * one thing is left open:
    security. We don't offer a YAHG model for the security elements in 15.4.
    Open until security architecture. * **[Thomas]** worries about dependency
    on security architecture * **[Thomas]** Michael and Rene, let's make sure
    we progress on security architecture. * Xavi asks to send comments to the
    ML. * **[Thomas]** is the draft published in its current form? * **[Xavi]**
    No, only in Bitbucket. * **[Thomas]** suggest to publish what we have and
    refresh later for semantics * **[Xavi]** agreed > Action item: **Xavi** to
    publish current version of draft-ietf-6tisch-6top-interface

  * _[08:41]_ compression of RPL option

    > **[Pascal]** recaps the discussions about the RPL option. The 6TiSCH WG
    needs to make a decision as of what to do, since we need to send
    draft-ietf-6tisch-minimal to IESG. Plan is to send it to IESG in November.

    * **[Pascal]** should minimal say anything about the RPL option? If we do
    not say anything, we might be forced to use the HBH as defined in 6553 *
    **[Michael]** if we define a compressed RPL option, will any node have to
    also accept the (then legacy) RPL option as defined in RFC6553? *
    **[Michael]** I prefer the flow label option as this is simpler. *
    **[Michael]** A node needs to support both the HBH option compressed and
    not so if a node supports that will be compliant and will be able to
    interoperate. * **[Michael]** The flow label is a re-implementation of the
    HBH option. The compression of the HBH is a lossless compression. *
    **[Pascal]** We need minimal draft to point to a solution for that problem.
    This means that the draft will contain a normative reference to an RFC
    which still needs to be finalized. This will stall publication of
    draft-ietf-6tisch-minimal. * **[Michael]** Yes, but
    draft-ietf-6tisch-minimal can sit in editors queue while waiting. Sitting
    in queue sends the message that the document is stable. * **[Pascal]**
    Agreed, perfect. > Action: **WG** to participate in 6lo and push for the
    HBH compression draft. * **[Pascal]** Consensus on call is to opt for the
    compressed RPL option within 6lo. > Action: **Pascal** to send email to
    6TiSCH ML to get consensus on going with compressed RPL option within 6lo.

  * _[09.10]_ AOB
    * **[Thomas]** Next meeting scheduled 10/24/2014.
* _[09.11]_ Meeting ends