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

# Minutes Webex 24 October 2014, 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=b4029b074a00492fa1344929ac3cf8fd
* Wiki: https://bitbucket.org/6tisch/meetings/wiki/141024_webex * Slides:
https://bitbucket.org/6tisch/meetings/src/master/141024_webex/slides_141024_webex.ppt

Taking notes _(using Etherpad)_
-------------------------------

1. Pascal Thubert
1. Xavi Vilajosana
1. Thomas Watteyne

Present _(template)_
--------------------

1. Ariton Xhafa
1. Diego Dujovne
1. Guillaume Gaillard
1. Giuseppe Piro
1. Ines Robles
1. Maria Rita Palattella
1. Michael Richardson
1. Nicola Accettura
1. Pascal Thubert
1. Pat Kinney
1. Raghuram Sudhaakar
1. Thomas Watteyne
1. Xavi Vilajosana

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

* **Thomas** to update draft-ietf-6tisch-tsch by cut-off date.
* **Pascal** and **Thomas** to talk to Ted about whether to push for
6TiSCH-specific CoAP draft, or wait for generic constrained management
solution. * **Xavi** to cite draft-thubert-6lo-rpl-nhc-02 in next revision of
draft-ietf-6tisch-minimal * **Michael** to publish a revision of the security
draft with a clear text describing the needs in terms of data representation
elements so the 6top data model can be updated. * **Michael** to publish a
revision of the security draft with a clear text describing the needs in terms
of data representation elements so the 6top data model can be updated.

Agenda
------
* Administrivia _[2min]_
    * Approval agenda
    * Approval minutes last call
* IETF91 _[5min]_
    * meetecho remote presentation
    * draft agenda
* draft-ietf-6tisch-tsch-02 publication _[2min]_
    * please review
* wrapping up draft-ietf-6tisch-minimal _[15min]_
* presentation draft-richardson-6tisch--security-6top-02 _[15min]_
    * RPL option status and update 6lo _[10min]_
* RFC7322: RFC Style Guide _[5min]_
* AOB _[5min]_

Minutes
-------

* _[08.05]_ Meeting starts **[Chairs]**
    * **Pascal** starts recording
    * **Thomas** presents agenda
        * update on IETF91 and draft agenda
        * present 2 draft and its status/evolution
        * **Michael** will present security draft status
        * **Pascal** will present status of RPL option at 6lo
        * if time permits, RF7322 will be introduced.
* _[08.08]_ Administrivia **[Chairs]**
    * Approval agenda
    > No issues raised. Agenda approved.
    * Approval minutes last call
    * No issues raised. Minutes last call approved.
    * **Thomas** There was a security call on Tuesday. Went through
    draft-richardson-6tisch--security-6top-03. It will be presented today.
* _[08.12]_ IETF91 **[Thomas]**
    * IETF91 agenda is final. Meeting is 9am in Hawaii, i.e. 8pm CET time same
    day. * Meetecho available. Remote presentations and remote attendance. *
    Recording and minutes will reflect remote participation. * **Michael**
    Visa's from 104 attendees from China have not been approved yet. *
    **Thomas** First time that every session is in meetecho. * For remote
    presenters, there will be tests to make sure everything works well. * This
    Monday is the cut-off date for draft submission. Authors are called to
    submit their drafts before Monday. * Monday is also cutoff for draft
    agenda. * Initial agenda for 6TiSCH WG meeting.
        * present latest changes on drafts
        * TSCH draft, 6top interface draft, and minimal
        * introduction to plugtest at 93rd IETF meeting, with help of ETSI.
        Renamed from plugfest to plugtest as it related to verification. *
        Rechartering discussion to define next steps (include dynamic
        scheduling, etc.) * Security: Michael will present a revision of his
        draft and then René has remarks > Action: **Thomas** to update
        draft-ietf-6tisch-tsch by cut-off date. * Maria Rita volunteers to
        present TSCH draft * Xavi volunteers to present minimal and 6top
        interface drafts, if necessary * Both presenters will do it remotely.
* _[08.19]_ draft-ietf-6tisch-tsch-02 publication **[Thomas]**
    * version 02 published
    * follows the rewording proposed during the call
    * 3 issues still open:
        * http://tools.ietf.org/wg/6tisch/trac/ticket/25. Rewording proposal.
        Rene did not agree. There is a follow up at the ML. * an issue is
        opened to change mote to node as node is what we agreed. * **Pascal**
        what about term "LLN nodes"? * **Thomas** suggests to use term "LLN
        node" in first occurrence and follow with "node".
    * **Pascal** several draft are going to be sent to the IESG in November.
    The last call will be announced at IETF91 and then we will have an
    evaluation/call for consensus for 2 weeks before submitting. * List of
    drafts considered: TSCH, Minimal, 6top-interface, CoAP. We need to decide
    what we do with them. * **Thomas** what about architecture draft? What is
    the current status and what is the timeline for this draft. * **Thomas**
    Would there be a problem if we recharter without having finalized the
    architecture draft? * **Pascal** I do not see any specific problem. *
    **Thomas** what about the CoAP draft? what should we do? Wait for the COMAN
    activity with constrained RESTCOnf draft? or push for our CoAP draft. *
    **Pascal** we have milestones with the IESG. We can delay the CoAP draft
    after recharter to see what is the progress of the RESTConf, etc. *
    **Raghuram** Agrees to wait. > Action: **Pascal** and **Thomas** to talk to
    Ted about whether to push for 6TiSCH-specific CoAP draft, or wait for
    generic constrained management solution. * **Michael** asks if there is a
    date for the ETSI event. * **Thomas** there is no specific date but it
    might be a couple of days before (or Monday) talking to IETF to see if this
    is possible. Target is July 2015 in Prague right before IETF93 is the
    target. * **Michael** the Contiki people planned to have a conference, hack
    fest right before. This might be a conflict. * **Thomas** the ETSI test
    event is not a long thing it is just a set of schedules of tests and people
    attend to their specific tests. * **Ariton** Regarding the interop. Are
    there going to be a set of scenarios? * **Thomas** yes. The plan is to
    develop the test scenarios and come out with a set of tests (end March) *
    **Ariton** there will not be certification on that event. * **Thomas** not
    sure. We need to check with ETSI. * The point is to make standard better.
    the outcome is to validate to our documents are correct and we are
    "optimal" in their design.
* _[08.xx]_ wrapping up draft-ietf-6tisch-minimal **[Xavi]**
    * change in the CCA option. Reflected in the drawing at the beginning of TX
    slot, timing before CCA. This is a clarification to follow exactly the
    standard * added the missing timing * open questions, need opinion
        * HbH header compression. Agreed last time to go to 6lo. Should not
        limit further extensions even at cost of additional byte? * what should
        minimal specify for security? * asking implementors if IE we are
        sending are enough?
    * **Pascal**: published draft-thubert-6lo-rpl-nhc-02
    * offers 3 possibilities:
        * (greedy) the one from NHC: consume 1/4 of NHC space (64 possibilities
        used) * (conservative) don't change layout at all, enumeration in
        6LoWPAN NHC already, consume new header (but then need full byte after
        it) (1 possibilities used, but extra byte) * (middle) idea from
        Carsten: limit the same to something the same as greedy, but add a byte
        when "error". Consumes 4 bits (~20 possibilities used, 1 extra byte
        when error)
    * **Thomas** what is an "error"?
    * **Pascal** forwarding error (O,F bits)
    * **Pascal** problem is that you might need to change packet length during
    forwarding * **Thomas** agreed that this is the draft to cite in minimal? >
    Action: **Xavi** to cite draft-thubert-6lo-rpl-nhc-02 in next revision of
    draft-ietf-6tisch-minimal. * **[Xavi]** what should
    draft-ietf-6tisch-minimal contain in terms of security? * **Pascal** I do
    not see the need to say anything, RPL has its own security, any security
    that applies to other protocols apply to minimal. * **Michael** similarly,
    there must be L2 security, which we just inherit.
* _[08.57]_ presentation draft-richardson-6tisch--security-6top-02 **[Michael]**
    * Missing text for security pieces in 6top
        * join controller provides a certificate for the node (500 bytes), node
        may issue a cert request. * OR (red line at the bottom) 802.15.9 key
        exchange, per peer keying using group key. Large shared secret like 32
        bytes. Are they mutually exclusive?
    * security pieces for the 6top model. What do we need to configure
    specifically? * the join controller provides the certificate. * the
    security for the DTLS connection needs to be able to identify the used
    certificate and its location. * the certificate will be used by p2p
    exchange. Also there can be a group key shared by all nodes. > Action:
    **Michael** to publish a revision of the security draft with a clear text
    describing the needs in terms of data representation elements so the 6top
    data model can be updated. * With a PCE each node needs to have a secure
    relation with the PCE. * with P2P negotiation and minimal where IEs are
    exchanged, security is more complex as requires to secure this relation. *
    **Ariton** 15.4e includes several security fields that have a particular
    meaning. Would those fields have a different meaning when used in the
    context of 6TiSCH? What would be the impact of using or not using the MAC
    header. * **Thomas** the fields have the same meaning. What 6tisch defines
    is a key management protocol so certificates can be exchanged. This is a
    complement to the architecture and later the use of this security
    certificates is fully aligned with 15.4e std. > Action: **Ariton** to send
    a mail to the ML asking clarification about whether IEEE802.15.4e fields
    have a different meaning when used in the context of 6TiSCH.
* _[09.11]_ RPL option status and update 6lo
    * Done at the previous minimal draft discussion.
* RFC7322: RFC Style Guide
    * No time. Pushed to later call.
* _[09.13]_ Meeting ends
    * Next 6TiSCH call on 11/7, purpose is to go through material for IETF91 WG
    meeting.