Subject: [6tisch] Minutes, 20 January 2017 interim, 6TiSCH WG

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 20 Jan 2017 16:50:28 +0000

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
  2.  Thomas Watteyne
  3.  Pascal Thubert

Present (alphabetically)

  1.  Aidan
  2.  Anna Yankova
  3.  John Rubis
  4.  Christian Navarro
  5.  Diego Dujovne
  6.  Deborah Klovsky
  7.  Dayane Kavanagh
  8.  Dominique Barthel
  9.  Erika ???
  10. Esteban Municio
  11. Gabriella ???
  12. Jonathan Munoz
  13. John Rubis
  14. John Poe
  15. Luke ??
  16. Malisa Vucinic
  17. Mary Knight
  18. Michael Richardson
  19. Pascal Thubert
  20. Patrick ???
  21. Qin Wang
  22. Rashid Sangi
  23. Ruben Hernandez
  24. S.V.R. Anand
  25. Sedat Gormus
  26. Tatyanna Dillinger
  27. Tengfei Chang
  28. Tero Kivinen
  29. Thomas Watteyne
  30. Xavi Vilajosana
  31. 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]

o    Xavi presenting:

        *   Published version 18 answering the points in the mailing list
        *   Contains all the answers wrapped up

o    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.

o    Tero's issues

        *   missing security consideration added
        *   discussion about K1

o    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 mechanisms 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, e.g. 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, please do not expect answers to mail

o    Brian's issues

        *   added parts to respond 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

o    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 and 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 candidates.
        *   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<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.

o    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.
        *   Pascal: suggestion to put a compressed RA in beacons, adding