Minutes interim-2017-6tisch-03: Fri 07:00
minutes-interim-2017-6tisch-03-201701200700-01

Meeting Minutes IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch) WG
Title Minutes interim-2017-6tisch-03: Fri 07:00
State Active
Other versions plain text
Last updated 2017-02-07

Meeting Minutes
minutes-interim-2017-6tisch-03-201701200700

   ## DRAFT ##

# Minutes, 20 January 2017 interim, 6TiSCH WG #

Note: timestamps in PDT.

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

* Date: 7-8am Pacific:
http://www.worldtimebuddy.com/?qm=1&lid=100,12,5392171,1850147&h=100&date=2017-01-20&sln=15-16
* Webex link:
https://cisco.webex.com/ciscosales/j.php?MTID=mcdbbe3a4e38d97d986b507ec12a1f9b1
    * Meeting number (access code): 203 224 694
    * Meeting password: sixtus (749887 from phones)
* Webex Recording:
https://cisco.webex.com/ciscosales/lsr.php?RCID=c7982f580bb34ca28d0ddd5869eb0cbc
    * Password: Recording password: 8pUGcmKu

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

1. Xavier Vilajosana
1. Thomas Watteyne
1. Pascal Thubert

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

1. Aidan
1. Anna Yankova
1. John Rubis
1. Christian Navarro
1. Diego Dujovne
1. Deborah Klovsky
1. Dayane Kavanagh
1. Dominique Barthel
1. Erika ???
1. Esteban Municio
1. Gabriella ???
1. Jonathan Munoz
1. John Rubis
1. John Poe
1. Luke ??
1. Malisa Vucinic
1. Mary Knight
1. Michael Richardson
1. Pascal Thubert
1. Patrick ???
1. Qin Wang
1. Rashid Sangi
1. Ruben Hernandez
1. S.V.R. Anand
1. Sedat Gormus
1. Tatyanna Dillinger
1. Tengfei Chang
1. Tero Kivinen
1. Thomas Watteyne
1. Xavi Vilajosana
1. Yasuyuki Tanaka

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

1. Xavi to check that minimal draft 18 says that the minimal slot frame should
be 0

Agenda
------

* Administrivia [2min]
    * Approval agenda
    * Approval minutes last call
* draft-ietf-6tisch-minimal [25min]

    * goal: go over the issues, propose resolutions, reach consensus
    * comments by Brian Carpenter
    > https://www.ietf.org/mail-archive/web/6tisch/current/msg05064.html
    * comments by Ralph Droms
    > https://www.ietf.org/mail-archive/web/6tisch/current/msg05101.html
    * comments by Tero Kivinen
    > https://www.ietf.org/mail-archive/web/6tisch/current/msg05094.html
* draft-ietf-6tisch-6top-protocol [25min]
* AOB [3min]

Minutes
-------

* Administrivia [2min]
    * Approval agenda
    * Approval minutes last call
* draft-ietf-6tisch-minimal [25min]
    * Xavi presenting:
        * Published version 18 answering the points in the mailing list
        * Contains all the answers wrapped up

    * TW: A week to respond to the reviewers?
        * Pascal: We will wait for the answers from them. Chairs will ping them
        to answers if there is no response in few days. * Tero: Will answer in
        1 week.

    * Tero's issues
        * missing security consideration added
        * discussion about K1

    * Kris and Xavi came up with new text

        * Malisa: a well known key is equivalent to secret key during the join
        process. the difference is during network operation whether we can use
        beacons or not. * Tero insists that the EBs are used after the join, so
        cannot be protected by a well known key * Thomas summarizes that the
        draft says not to use Extended Beacons after the join, so attacks
        against EBs are impossible * Tero says it's a bad idea to duplicate the
        mechansims in EB in another protocol * Thomas: Is your problem that EBs
        cannot be used after join * Tero: yes, all uses of EBs are now blocked,
        it does many things, eg have specific EBs that say it's a 6TiSCH
        network * Thomas: asking the group if all understand the problem the
        same * Tero: using the beacon with new information element is richer
        than just a K1. You may say this is a 6TiSHC network, you may provide
        other information such as version * Tero: will be in PTO next week, pls
        do not expect  answers to mail

    * Brian's issues

        * added parts to respong to Brian, text in intro etc...

* draft-ietf-6tisch-6top-protocol

    * Thomas presents the 6P protocol update
    * list of things to be done to move to the next version
    * recommendation for which cells to use for 6p signaling traffic
    * Thomas: relocate command; not in the draft yet

        * in 2 way transaction, propose to use a cell list where the first
        element there is the cell to be move and the rest are candidate
        locations. * Thomas: Proposal: 1st entry is cell to be oved abd second
        entry is where it is going. Issues with that? * Tengfei: how many cells
        to relocate per command? only one? can be a list of cells to be
        relocated? * Qin Wang: can be useful to express more than one. *
        Thomas: in the request we need to add the number of cells to be
        relocated. The first set of cells (fitting the number requested) are
        the ones to be relocated. The rest of the cell list is the candadites.
        * Slotframe priority is encoded in the number in the standard, no need
        to specify that * Xavi: Simon proposes to use a slotframe at mean
        priority as opposed to the highest * Thomas: what happens to create a
        new cell: I need to pick a cell in minimal. if minimal can be starved
        then the node is stuck * Michael: relates to ethernet capture:
              *
              https://web.archive.org/web/19981206060527/http://wwwhost.ots.utexas.edu/ethernet/enet-misc/load/vanj-enet-posting
              or * https://www.wired.com/2012/05/van-jacobson/ but, I can't
              find the post I wanted to point at.
        * Tero: since there is only one timeslot in minimal, looks OK to leave
        it as highest priority * Thomas: action item for Xavi check that
        minimal uses slotframe 0 for minimal * Thomas: you can still have
        payload if code is not success to suggest cells. The typo I think is in
        the error code text saying not success * Xavi: yes, we should bhave a
        different code, not error * Thomas: seems strange to switch from 2 step
        to 3 steps. The text on suggestion is too high in the draft, that
        should be a section later for an exotic capability * Thomas: can be
        more than one SF, SF ID indicated. No way to loop through the SF to
        know which cells you have. * Yasuyuki's suggestion to have SF ID 0xFF
        to mean all. Does that look odd? * Yasuyuki: complexity, suggest not to
        do it at this time because use case for STATUS request with 0xFF (all
        SFs) is unclear.

    * about short vs. long L2 address

        * Tero: security section state machine implies that you know both
        addresses, short and long. We need both 16bit and 64bit addresses in
        the nodes. * when sending we can use the short address. There is a case
        in 15.4 to use short address in the nonce. * Thomas: how does the node
        learn both addresses? * Tero: there must be a resolver
               *
               https://mentor.ieee.org/802.15/dcn/15/15-15-0106-07-0mag-security-section-pictures.pdf
               contains pictures of the 802.15.4 security PIB. * Table 9-14 has
               both short (can be unknown) and long address (must be known),
               and it is needed so node can receive anything from anybody.

        * Michael: cannot use IPv6 ND since it is multiple hops away
        * Tero: the problem is L2, one hop away, so yes ND could help
        * Start the document that describes the RA-IE where information can be
        exchanged. * MR: putting there the dodagid. Also add other aspects of
        an RA.