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 | |
|---|---|---|
| Date and time | 2017-01-20 15:00 | |
| Title | Minutes interim-2017-6tisch-03: Fri 07:00 | |
| State | Active | |
| Other versions | plain text | |
| Last updated | 2017-02-07 |
minutes-interim-2017-6tisch-03-201701200700-01
## 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.