Minutes for 6TISCH at interim-2014-6tisch-5
minutes-interim-2014-6tisch-5-1

# 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
1. Michael Richardson
1. Pascal Thubert
1. Xavi Vilajosana
1. Thomas Watteyne

Present
-------

1. Deji Chen
1. Diego Dujovne
1. Dominique Barthel
1. Kris Pister
1. Malisa Vucinic
1. Michael Richardson
1. Pascal Thubert
1. Pat Kinney
1. Patrick Wetterwald
1. Paul ?
1. Pouria Zand
1. Raghuram Sudhaakar
1. Rene Struik
1. Thomas Watteyne
1. Xavi Vilajosana
1. Yoshihiro Ohba

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

1. **Thomas** to publish new version of draft-ietf-6tisch-tsch adding all
contributors. 1. **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**: 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