Minutes for 6TISCH at interim-2016-6tisch-2
minutes-interim-2016-6tisch-2-1

## THIS IS A DRAFT!!! ##

# Minutes, 22 January 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-01-22&sln=15-16
* Webex recording:
https://cisco.webex.com/ciscosales/lsr.php?RCID=67f581ad9b624c5cb98a0d2fe3535db7
* Meeting slides:
https://bitbucket.org/6tisch/meetings/raw/039a65c5a896825ebbc2c71b24aab75b439a379b/160122_webex/slides_160122_webex.ppt

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

1. Thomas Watteyne
1. Pascal Thubert
1. Diego Dujovne
1. Keoma Brun-Laguna
1. Michael Richardson
1. Xavi Vilajosana
1. Simon Duquennoy

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

1. Thomas Watteyne
1. Pascal Thubert
1. C-Y Lee
1. Diego Dujovne
1. Jonathan Munoz
1. Keoma Brun
1. Michael Richardson
1. Pascal Thubert
1. Patrick Wetterwald
1. Qin Wang
1. S.V.R. Anand
1. Sedat Gormus
1. Shahid Raza
1. Simon Duquennoy
1. Simon Duquennoy
1. Sven Akkermans
1. Tengfei Chang
1. Xavi Vilajosana
1. Zhuo Chen

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

1. QIN: will start a discussion on the ML on what we do on information and yang
data model

Agenda
------

* Administrivia _[2min]_
    * Approval agenda
    * Approval minutes last call
    * rechartering news
* 6LoRH  _[20min]_
    * draft(s) status
    * ML issues, proposed formats
* 6top-sublayer  _[10min]_
    * ML Discussion on recommended formats
* Minimal Draft  _[15min]_
    * impacts on main text from intro changes
    * Suresh's issues
    * Next steps
* PlugTest  _[10min]_
    * Walk-through (delta) tests
    * related question about the 6lorh and 6top
* AOB _[1min]_

Minutes
-------

* _[07.04]_ Meeting starts

* _[07.07]_ Administrivia _[2min]_
* Approval agenda

    * no issues raised, agenda approved
    * Approval minutes last call
    * no issues raised, minutes approved
    * rechartering news

        * mcr was asked opinion by IESG about 6tisch recharter, wrt ROLL and
        mcr confirmed it was good. * Xavi: we need some information about the
        layer * Pascal: let's not confuse terms * Xavi: * Thomas: Yang model is
        extensive, should we start from Draft reduce to the security ? *
        Pascal: question from Benoit is confusing a little bit. Where is the
        information model ? * Thomas: data model = interface draft whereas
        information model = sublayer draft * Qin: suggest we discuss in ML *
        Pascal: can you start thread * Qin: OK (ACTION) * Thomas: Can we avoid
        this discussion again ?

* _[07.15]_ 6LoRH (Pascal)  _[20min]_
    * draft(s) status
        * Thomas:
    * Pascal: 6LoRH draft adopted
        * https://tools.ietf.org/html/draft-ietf-6lo-paging-dispatch-01
        * https://tools.ietf.org/html/draft-ietf-6lo-routing-dispatch-03
        * Paging system: two documents now.
    * topic: how do we go certain things, answers tech questions from Tengfei
    and Simon
        * example 1: case where we have a packet from the DODAG toward the Root
        (ICMP and UDP) * In this case we don't need IP-in-IP ??? * Where is the
        RPI ? * slide 9: ICMP example * slide 10: UDP example * 6LoRH goes
        BEFORE the IPHC, this is an important addition of the draft * node
        which wants to add a 6LoRH will NOT have to change the IPHC packet *
        things are reversed: IPHC and IP-in-IP goes at the END of the packet *
        as packet progresses, the addresses in 6LoRH are being removed.
        Different than IPv6. In * in 6LoRH: * routing head is "consumed": size
        of 6loRH is reduced as the packet travels from root into the LLN * the
        next hop is the first address in the 6LoRH, NOT the IPv6 destination
        address (final destination in inner IP-in-IP header) * Thomas: Do we
        have to carry the full IPv6 address in all RHs? * Pascal: "normal" case
        in 6TiSCH: * only 2-byte addresses, remaining 112 bits inferred from
        the source * you know what the source of the packet is * Simon: about
        slide 11 removing addresses as you go is good. But how interoperable
        with RFC6554? all addresses are in RFC6554? Would expect from 6LoRH to
        compress existing 6554 headers. * Pascal: you can reconstruct an RH3
        from 6LoRH, but it will not be the same one as if you * Michael:
        important for efficiency. It's possible to deploy nodes with 6LoRH but
        not turn it on (manageable) * why does it matter? * Simon: in the
        routing header, the addresses are not consumed * Pascal: 6man might
        complain. problem with authentication. * Simon: big problem? * Pascal:
        we have L2 security, we can trust that routing header will not be
        compromised. * Simon: big sec threat. 6LoRH should not impact 6LoWPAN *
        Pascal: do you want to keep the data in the RH? -technical decision *
        Simon: AH (authentication header). In IPv6, you have to replace the
        destination address. * Pascal: Any RPL packet could be attacked the
        same way. But it is not because we have L2 security. If we wanted to
        keep the addresses we could add an index in 6LoRH to ... WG to decide *
        Simon: why couldn't we remove addresses from 6554? * Pascal: probably
        for passing 6man faster. * Thomas: the idea of 6554 is to do a version
        for 6LoWPAN. When we implemented the last plugtest, we realized that we
        could ping 3 hops away * Even if we add an index, we will not pass 6MAN
        if we have an option not to use it ?? * Xavi: 6554 doesn't say anything
        about what happens * the receiver doesn't ... * Thomas: we can specify
        how the AH is calculated * Pascal discusses different use cases with
        the types of the addresses. * the new draft explain the recursive
        process of popping the first address in RH3-6LoRH, asking text review

        * If the packet is fragmented, same fragmentation rule as IPHC
        * discussion about where IP-in-IP header goes. Slide 14 about proposed
        order. * when decoding 6LoRH headers, * Thomas: Why multiple RH3? *
        Pascal: e.g. from one PAN to the next * Xavi: clarifying: fragmentation
        header right after MAC? * Pascal: yes * Pascal: without order, you
        cannot do IP-in-IP-in-IP * Pascal: discussion is about the order of the
        headers, proposal:
            * 1st reason: starting with RH is simpler as it is consumed
            * 2nd reason: need a clear separator
        * Pascal: proposal: reverse all the headers (keep logic as with IPHC
        and 6LoRH) IPHC and 6LoRH are the separators * Pascal: RH3, then RPI,
        then 6LoRH. * Simon feels it adds complexity * the draft is redesigned
        to work on the compressed form * if you don't want that you have to
        rewrite everything * Thomas:  Do we remove addresses of the routing
        header ?
            * What are the arguments to put the header before ?
        * Pascal: the main idea was to make easy to manipulate the header
            * When its compressed its not meant to be read. DO people read in
            the zipped file?

* _[08.09]_ PlugTest  _[10min]_
* Thomas: motes sent to the people
  * dissector available
* Golden version available
* Walk-through (delta) tests

* related question about the 6lorh and 6top
* poipoi
* _[07.??]_ AOB _[1min]_
* poipoi
* _[08.??]_ Meeting ends