Clone wiki

meetings / 141219_webex

Minutes, 19 December 2014 interim, 6TiSCH WG

Note: timestamps in PDT.

Connection details


Taking notes (using Etherpad)

  1. Dominique Barthel
  2. Michael Richardson
  3. Pascal Thubert
  4. Xavi Vilajosana
  5. Thomas Watteyne


  1. Deji Chen
  2. Diego Dujovne
  3. Dominique Barthel
  4. Kris Pister
  5. Malisa Vucinic
  6. Michael Richardson
  7. Pascal Thubert
  8. Pat Kinney
  9. Patrick Wetterwald
  10. Paul ?
  11. Pouria Zand
  12. Raghuram Sudhaakar
  13. Rene Struik
  14. Thomas Watteyne
  15. Xavi Vilajosana
  16. Yoshihiro Ohba

Action Items

  1. Thomas to publish new version of draft-ietf-6tisch-tsch adding all contributors.
  2. Pascal to push draft-ietf-6tisch-tsch to the IESG early January 2015.


  • Administrivia [2min]
  • status draft-ietf-6tisch-tsch [5min]
  • last call draft-ietf-6tisch-minimal [5min]
  • last call draft-ietf-6tisch-coap [5min]
  • preparation for draft-ietf-6tisch-terminology last call [10min]
  • preparation for draft-ietf-6tisch-architecture last call [10min]
  • open mike rechartering [10min]
  • summary of security discussions [10min]
  • AOB [3min]


  • [08.04] Administrivia [Chairs]
    • Pascal starts recording
    • Thomas invites people to join the Etherpad
    • Approval agenda

      No issues raised. Agenda approved.

    • Approval minutes last call

      No issues raised. Minutes last call approved.

  • status draft-ietf-6tisch-tsch [Thomas Watteyne]
    • status. issued last call 20 November.
    • 3 open issues opened
    • 3 tickets have been closed.
    • Clarify use of join priority
    • Cleaner text for multihop topology
    • Clarify meaning of these. Replace these by cells.
    • Added thanks to some authors and collaborators.

      Action item: Thomas to publish new version of draft-ietf-6tisch-tsch adding all contributors.

    • Pascal: will push to IESG early january

      Action item: Pascal to push draft-ietf-6tisch-tsch to the IESG early January 2015.

  • last call draft-ietf-6tisch-minimal [Xavi Vilajosana]
    • Pascal: how does security impact the minimal draft? Minimal starts when you have a key (real shared key or any other mechanism). No join process is needed.
    • Xavi: second point is that EB not used for synchronization.
    • Michael: also the case for not "minimal"?
    • Thomas: yes, this is a feature of 15.4e, so applies to minimal and all uses of 15.4e.
    • Michael: this then needs to be said at the architecture as well: make clear that EBs are not used for synchronization in any 15.4e network.

      Action item: Pascal to specify in architecture draft that EBs are not used for synchronization.

    • Pascal: minimal is supposed to explain how RPL is used on top of TSCH. Different options available. Flow label solution is one, but discussions about this at 6man never converges. Never reached consensus.
    • Pascal proposed to move to the default. In parallel he is trying to have 6lo do something. Pascal triggered the chairs of these groups.
    • Pascal asks if we can continue with the submission to the IESG and review that particular thing later? Brian answered that if this is an interop requirement this MUST be in the document. They propose to implement and test to see what works best. Delay Minimal submission after the interop.
    • Thomas confused. does that mean we need to implement all the possible ways of doing HC?
      • RFC6553 HC
      • FlowLabel
      • 6554-HC
      • (6553-HC + 6554-HC)
    • Pascal: currently being discussed between AD's.
    • Michael: re-inventing HC particular for this is probably a 3 IETF cycle/meeting process. Part of the problem is that nobody said this 9 month ago and this had not started until now.
    • Thomas: lots of push back to the flow label solution.
    • Michael: no exactly: absence of opinion, not push back.
    • Pascal: suggestion is to do FlowLabel so we can have something by June at the Interop.
    • Thomas: This is an interop. There are a set of rules and we cannot use them to test different things. We want something that is the final solution the best thing we can do. If we will not adopt flow label as final solution, we should not have that in the interop. In the worst case, we can use regular HbH routing header, rather than having people implement something different.
    • Kris: +1
    • Pascal: whole bunch of other stuff that would still benefit from testing.
    • Michael: right.
  • [08.33] last call draft-ietf-6tisch-coap

    Technical glitch: webex does shows the slide as blank, although has text in locally downloaded version. Thomas paraphrases the contents of the slide.

    • Thomas to avoid two last calls at the same time, we proposed to have the last call at the beginning of Jan.
    • Raghuram (authors) agree.
  • [08.35] preparation for draft-ietf-6tisch-terminology last call
    • Thomas new terms emerged from the 6tisch security work. Michael suggested some terms that are captured in issue. Pascal proposed some rewording.
    • Rene It is too early to talk about this. Some on the terms depend on the protocol details. Some non-stable terms there. Last call is not recommended. Concerns about several terms (unique join key, relay, etc).
    • Michael: please propose other terms or other protocols if you don't like those in place.
    • Kris: we have a list of definitions. They will end up on the security specs. Adding to the set of definitions is in the scope. It seems reasonable to discuss about some terms. It is not the time to think that terms are pointing to specific mechanisms to be used. The terms are considered to be neutral.
    • Rene: do think that definitions are neutral, do not imply protocols to be used.
    • Kris: Do we have a proposal for the definitions that should change?
    • Pat: I did not see what needs to be changed in your mail.
    • Rene: Example of joining node: may be just unwrapped, but have been around for long time and just changing network. All listed in email to the list
    • Thomas: since this is in a e-mail that we haven't had time to read, let's move discussion to the ML.
  • [08.44] preparation for draft-ietf-6tisch-architecture last call
    • Pascal. We are missing security text, so the last call is adjourned. Comments needed.
  • [08.46] open mike rechartering
    • Questions: should the charter and the I-Ds specify IEEE802.15.4e-2012 or IEEE802.15.4-2015
    • Pat: 4e-2012 is an amendment, those amendments disappear. So I recommend to keep 4e for now and switch to 15.4-2015 when published. poipoipoipoi
    • Thomas: opinion similar to Pat's. I understand IEEE802.15.4e-2012 is temporary, but so is our charter. I suggest to keep IEEE802.15.4e-2012 in the charter and switch over to IEEE802.15.4-2015 at first opportunity after it's published.
    • Michael: charter is not a document. Documents cannot point to ref that doesn't exist yet.
    • Michael: we should take the changes in -2015 into consideration when the standard is published.
    • Thomas: what about the charter?
    • Pat: You can simply specify IEEE802.15.4, with the understand that you mean its most current embodiment. This would tramslate into 15.4e-2012, 15.4-2015 is published. If you keep 15.4 right now your are fine.
    • Rene: 6TiSCH hold up to its own policy. We can build only on stable specifications. 15.4 is a moving target so it is better to state the particular revision.
    • Pat: 15.4e-2012 is an amendment of 15.4-2011. Is not standalone. Do you want to include all of 15.4-2011 terminology as well?
    • Rene: read 15.4e spec, already refers to -2011. We don't have any influence on future documents by IEEE. It's not correct that spec will automatically vanish. Only vanishes if IEEE decides so. Otherwise, becomes available for free at most 5 years after it's published.
    • Deji: A lot of effort was spent checking if WirelessHART conforms to 2006, and in the end WirelessHART was based on 2003 but does not violate 2006.
    • Rene: all security was rewritten. Cannot expect that everything works unchanged with newer revision.
    • Pat: WirelessHART handles security at a higher layer than IEEE802.15.4, so changes to the security section from 15.4-2003 to 15.4-2006 didn't matter for WirelessHART.
    • Pascal: One important point is that 15.4-2015 comes with the ETSI compliance, want to be able to state that 6TiSCH is also compliant to ETSI recommendations.
    • Rene: last sec calls did not make progress because no clear idea on how the MAC operates (wrt security?)
    • Pascal: IEEE 6TiSCH Interest Group there to help us. Any question or requirement can we forwarded to there. Also to Pat Kinney. Is chair of the interest group and co-chair of the 15.4.
    • Pat: chair of <missed>, vice-chair of <missed>, can absolutely help the 6TiSCH WG get the word across to the IEEE.
    • Rene: doesn't guarantee issues taken with high level of priority.
    • Pat: is there a defined consensus that needs to be relayed to 15.4?
    • Rene: no visibility on that process.
    • Pat: Decide what you want to say to 15.4
    • Rene: unclear how to communicate. History of problems four years ago.
    • Pat: put things down in writing.
    • Pascal: without writing, not actionable.
    • Pascal: we are late on our drafts.
      • the new schedule that has to be announced to the ADs.
      • TSCH and CoAP on Jan.
      • Minimal: we need to agree a default action. If we do not compress anything we can move to the IESG.
      • Security: nothing before Feb.
    • Pascal: Talk to Ted and have a new schedule.
    • Pascal: Suggest from now and March we talk about recharter. First item for me would be Join Process
    • Thomas: We need to dedicate a next call to that discussion (9th Jan)
  • [09.02] summary of security discussions

    Because of the lack of time, this discussion is moved to the next call.

  • [09.08] AOB
    • Thomas: next call on 9 January.

      No other business raised.

  • [09.09] Call ends