Subject: [6tisch] Minutes 6TiSCH WG Interim Call 19 December 2014

From: Thomas Watteyne <[email-masked]>
Date: Sun, 21 Dec 2014 18:32:07 +0100

All,

You will find the minutes of the last 6TiSCH interim call below (also at
https://bitbucket.org/6tisch/meetings/ and
https://www.ietf.org/meeting/interim/proceedings.html).

Reply with comments/suggestions. We will approve these minutes at the next
6TiSCH interim call.

Next 6TiSCH interim call is scheduled on 9 January 2015 (already announced).

Thomas

---

Minutes, 19 December 2014 interim, 6TiSCH WG

Note: timestamps in PDT.
Connection details

   - Webex:
   https://ciscosales.webex.com/ciscosales/j.php?ED=219615007&UID=481905242&PW=NZTRkNDAwOTE1&RT=MiMyMw%3D%3D
   - Etherpad:
   http://etherpad.tools.ietf.org:9000/p/6tisch?useMonospaceFont=true
   - Topic: 6TiSCH Weekly
   - Time: 8:00 am, Pacific Daylight Time (San Francisco, GMT-07:00)
   - Meeting Number: 206 802 913
   - Meeting Password: sixtus
   - CCM: +14085256800x206802913

Resources

   - Webex recording:
   https://cisco.webex.com/ciscosales/lsr.php?RCID=66563316a83a4b99b09715002f93ad96
   - Wiki: https://bitbucket.org/6tisch/meetings/wiki/141219_webex
   - Slides:
   https://bitbucket.org/6tisch/meetings/src/master/141219_webex/slides_141219_webex.ppt

Taking notes *(using Etherpad)*

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

Present

   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.

Agenda

   - 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]*

Minutes

   - *[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*: WirelessHART was first based on 15.4-2003; then -2006 come
      out. Some of the designs were related to 2003 and 2006 revision changed
      them and some things did not work
      - *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

---

From: Thomas Watteyne <[email-masked]>
Date: Mon, 22 Dec 2014 12:19:25 +0100

Deji,

Thanks you for clarify this point!

The draft minutes are precisely published on the mailing list for people to
comment on (as you did). At the next call, a format step is to validate
last call's minutes, leaving each of us some weeks to proof-read the text.
Following your e-mail, I have updated the minutes at
https://bitbucket.org/6tisch/meetings/wiki/141219_webex. During the call,
minutes are taken on a public Etherpad instance so you can follow what is
being written down.

Thanks again for reading the draft minutes closely, and don't hesitate if
you see anything else that you believe is not correct. In case, the full
recording is also made available.

Thomas

On Mon, Dec 22, 2014 at 11:56 AM, <[email-masked]> wrote:

> All,
>
> I want to clarify the comment attributed to me. I did not say "Some of the
> designs were related to 2003 and 2006 revision changed them and some things
> did not work". I said 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.
>
> I have to be careful in the future, just spoke once so far and got
> misquoted :(
>
> Deji
>
>
> -----原始邮件-----
> *发件人:* "Thomas Watteyne" <[email-masked]>
> *发送时间:* 2014-12-22 01:32:07 (星期一)
> *收件人:* "[email-masked]" <[email-masked]>
> *抄送:*
> *主题:* [6tisch] Minutes 6TiSCH WG Interim Call 19 December 2014
>
>
> All,
>
>    1. *Thomas* to publish new version of draft-ietf-6tisch-tsch adding
>    all contributors.
>       - *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.
>
>       - *Pascal*: minimal is supposed to explain how RPL is used on top
>       of TSCH. Different options available. Flow label solution is one, but
>       - *Pascal* proposed to move to the default. In parallel he is
>       trying to have 6lo do something. Pascal triggered the chairs of these
>       groups.
>       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.
>       - *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.
>       - *Pascal*: suggestion is to do FlowLabel so we can have something
>       by June at the Interop.
>       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.
>    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.
>       - *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).
>       security specs. Adding to the set of definitions is in the scope. It seems
>       been around for long time and just changing network. All listed in email to
>       the list
>       - *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.
>       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
>       - *Deji*: WirelessHART was first based on 15.4-2003; then -2006
>       come out. Some of the designs were related to 2003 and 2006 revision
>       changed them and some things did not work
>       - *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.
>       - *Rene*: unclear how to communicate. History of problems four
>       years ago.
>       - *Pascal*: Suggest from now and March we talk about recharter.
>       First item for me would be Join Process