Minutes for 6TISCH at interim-2015-6tisch-17
minutes-interim-2015-6tisch-17-1

## THIS IS A DRAFT!!! ##

# Minutes, 11 December 2015 interim, 6TiSCH WG #

Note: timestamps in PST.

Connection details
------------------

* Date: Dec 11th, 7-8AM Pacific:
http://www.worldtimebuddy.com/?qm=1&lid=100,12,5392171,1850147&h=100&date=2015-12-11&sln=15-16
* Webex link:
https://cisco.webex.com/ciscosales/j.php?MTID=md64a0958ae4154c0553f056bf42b756a
* Webex recording:
https://cisco.webex.com/ciscosales/lsr.php?RCID=2fa6cfa8f6f942f58323be0b3bb3ac09
* Wiki: https://bitbucket.org/6tisch/meetings/wiki/151211_webex * Slides:
https://bitbucket.org/6tisch/meetings/src/master/151211_webex/slides_151211_webex.ppt

Agenda
------

* Administrivia _[2min]_
    * Approval agenda
    * Approval minutes last call
* Charter Update _[5min]_
* 802.15.4: status _[5min]_
* 6lo drafts (BBR and 6LoRH) _[10min]_
* PlugTest Scope  _[15min]_
* 6top drafts (next steps) _[20min]_
* AOB [1min]

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

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

Present _(alphabetically)_
--------------------------

1. Thomas Watteyne
1. Diego Dujovne (Etherpad only)
1. Pascal Thubert
1. Benoit Claise
1. Lavanya  H M
1. Maria Rita Palattella
1. Pat Kinney
1. Qin Wang
1. S.V.R. Anand
1. Sebastian Schildt
1. Tengfei Chang
1. Xavi Vilajosana
1. Zhuo Chang

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

1. Thomas to poll the ML on the text that Ralph and Pascal put together for
minimal abstract and intro 1. Thomas to poll the ML on whether 6LoRH is a MUST
for minimal and if so, whether we deprecate other forms of RH / IP in IP / RPI
compressed encodings

Minutes
-------

* _[07.05]_ Meeting starts
    * Thomas makes the intro, usual BCP announcements about IPR etc...
* _[07.07]_ Administrivia
    * Approval agenda
    * Approval minutes last call
    * bashing: asking confirm about minutes of last meeting and agenda. Both
    are approved. * Benoit Claise will speak about the 6top interface * Benoit
    shares screen and will update the etherpad * Benoit screens all the YANG
    models and publishes them all on his site where he publishes compilation
    errors at http://www.claise.be/IETFYANGPageCompilation.html * important
    because of dependency model (http://www.claise.be/modules.png). Our Yang
    model cannot be extracted. It is missing <CODE BEGINS> and <CODE ENDS>. *
    The extraction errors are
        * xym.py *6tisch*
        * ERROR: 'draft-ietf-6tisch-6top-interface-04.txt', Line 423 - Yang
        module 'ietf-6top' with no <CODE BEGINS> and not starting with
        'example-'

    * And the compilation errors are:

         * ietf-6top.yang:18: error: keyword "organization" not in canonical
         order, (See RFC 6020, Section 12) * ietf-6top.yang:72: error: keyword
         "mandatory" not in canonical order,expected "type", (See RFC 6020,
         Section 12) * ietf-6top.yang:73: error: keyword "type" not in
         canonical order, (See RFC 6020, Section 12) * ietf-6top.yang:83:
         error: keyword "unique" not in canonical order, (See RFC 6020, Section
         12) * ietf-6top.yang:120: warning: RFC 6087: 4.10,4.12: statement
         "bit" should have a "description" substatement * ietf-6top.yang:123:
         warning: RFC 6087: 4.10,4.12: statement "bit" should have a
         "description" substatement * ietf-6top.yang:126: warning: RFC 6087:
         4.10,4.12: statement "bit" should have a "description" substatement *
         ietf-6top.yang:129: warning: RFC 6087: 4.10,4.12: statement "bit"
         should have a "description" substatement * ietf-6top.yang:140:
         warning: RFC 6087: 4.10,4.12: statement "enum" should have a
         "description" substatement * ietf-6top.yang:141: warning: RFC 6087:
         4.10,4.12: statement "enum" should have a "description" substatement *
         ietf-6top.yang:150: warning: RFC 6087: 4.10,4.12: statement "enum"
         should have a "description" substatement * ietf-6top.yang:151:
         warning: RFC 6087: 4.10,4.12: statement "enum" should have a
         "description" substatement * ietf-6top.yang:177: error: keyword
         "mandatory" not in canonical order,expected "type", (See RFC 6020,
         Section 12) * ietf-6top.yang:178: error: keyword "type" not in
         canonical order, (See RFC 6020, Section 12) * ietf-6top.yang:208:
         error: keyword "unique" not in canonical order, (See RFC 6020, Section
         12) * ietf-6top.yang:237: warning: RFC 6087: 4.10,4.12: statement
         "enum" should have a "description" substatement * ietf-6top.yang:238:
         warning: RFC 6087: 4.10,4.12: statement "enum" should have a
         "description" substatement * ietf-6top.yang:239: warning: RFC 6087:
         4.10,4.12: statement "enum" should have a "description" substatement *
         ietf-6top.yang:240: warning: RFC 6087: 4.10,4.12: statement "enum"
         should have a "description" substatement * ietf-6top.yang:263: error:
         keyword "must" not in canonical order, (See RFC 6020, Section 12) *
         ietf-6top.yang:287: error: keyword "unique" not in canonical order,
         (See RFC 6020, Section 12) * ietf-6top.yang:329: warning: RFC 6087:
         4.10,4.12: statement "enum" should have a "description" substatement *
         ietf-6top.yang:330: warning: RFC 6087: 4.10,4.12: statement "enum"
         should have a "description" substatement * ietf-6top.yang:331:
         warning: RFC 6087: 4.10,4.12: statement "enum" should have a
         "description" substatement * ietf-6top.yang:332: warning: RFC 6087:
         4.10,4.12: statement "enum" should have a "description" substatement *
         ietf-6top.yang:333: warning: RFC 6087: 4.10,4.12: statement "enum"
         should have a "description" substatement * ietf-6top.yang:334:
         warning: RFC 6087: 4.10,4.12: statement "enum" should have a
         "description" substatement * ietf-6top.yang:335: warning: RFC 6087:
         4.10,4.12: statement "enum" should have a "description" substatement *
         ietf-6top.yang:336: warning: RFC 6087: 4.10,4.12: statement "enum"
         should have a "description" substatement * ietf-6top.yang:337:
         warning: RFC 6087: 4.10,4.12: statement "enum" should have a
         "description" substatement * ietf-6top.yang:338: warning: RFC 6087:
         4.10,4.12: statement "enum" should have a "description" substatement *
         ietf-6top.yang:339: warning: RFC 6087: 4.10,4.12: statement "enum"
         should have a "description" substatement * ietf-6top.yang:340:
         warning: RFC 6087: 4.10,4.12: statement "enum" should have a
         "description" substatement * ietf-6top.yang:341: warning: RFC 6087:
         4.10,4.12: statement "enum" should have a "description" substatement *
         ietf-6top.yang:342: warning: RFC 6087: 4.10,4.12: statement "enum"
         should have a "description" substatement * ietf-6top.yang:356:
         warning: RFC 6087: 4.10,4.12: statement "enum" should have a
         "description" substatement * ietf-6top.yang:357: warning: RFC 6087:
         4.10,4.12: statement "enum" should have a "description" substatement *
         ietf-6top.yang:390: warning: RFC 6087: 4.10,4.12: statement "enum"
         should have a "description" substatement * ietf-6top.yang:391:
         warning: RFC 6087: 4.10,4.12: statement "enum" should have a
         "description" substatement * ietf-6top.yang:412: warning: RFC 6087:
         4.10,4.12: statement "enum" should have a "description" substatement *
         ietf-6top.yang:413: warning: RFC 6087: 4.10,4.12: statement "enum"
         should have a "description" substatement * ietf-6top.yang:414:
         warning: RFC 6087: 4.10,4.12: statement "enum" should have a
         "description" substatement * ietf-6top.yang:680: warning: RFC 6087:
         4.10,4.12: statement "enum" should have a "description" substatement *
         ietf-6top.yang:681: warning: RFC 6087: 4.10,4.12: statement "enum"
         should have a "description" substatement * ietf-6top.yang:692: error:
         keyword "unique" not in canonical order, (See RFC 6020, Section 12) *
         ietf-6top.yang:797: warning: RFC 6087: 4.10,4.12: statement "enum"
         should have a "description" substatement * ietf-6top.yang:798:
         warning: RFC 6087: 4.10,4.12: statement "enum" should have a
         "description" substatement * ietf-6top.yang:848: warning: RFC 6087:
         4.10,4.12: statement "enum" should have a "description" substatement *
         ietf-6top.yang:849: warning: RFC 6087: 4.10,4.12: statement "enum"
         should have a "description" substatement * ietf-6top.yang:1022:
         warning: RFC 6087: 4.3: statement "config" is given with its default
         value "true" * ietf-6top.yang:1032: warning: RFC 6087: 4.10,4.12:
         statement "enum" should have a "description" substatement *
         ietf-6top.yang:1033: warning: RFC 6087: 4.10,4.12: statement "enum"
         should have a "description" substatement * ietf-6top.yang:1052: error:
         keyword "config" not in canonical order, (See RFC 6020, Section 12) *
         ietf-6top.yang:1059: warning: RFC 6087: 4.10,4.12: statement "enum"
         should have a "description" substatement * ietf-6top.yang:1060:
         warning: RFC 6087: 4.10,4.12: statement "enum" should have a
         "description" substatement * ietf-6top.yang:1061: warning: RFC 6087:
         4.10,4.12: statement "enum" should have a "description" substatement *
         ietf-6top.yang:1062: warning: RFC 6087: 4.10,4.12: statement "enum"
         should have a "description" substatement * ietf-6top.yang:1063:
         warning: RFC 6087: 4.10,4.12: statement "enum" should have a
         "description" substatement * ietf-6top.yang:1064: warning: RFC 6087:
         4.10,4.12: statement "enum" should have a "description" substatement *
         ietf-6top.yang:1065: warning: RFC 6087: 4.10,4.12: statement "enum"
         should have a "description" substatement * ietf-6top.yang:1066:
         warning: RFC 6087: 4.10,4.12: statement "enum" should have a
         "description" substatement

    * Xavi: Pushed in bitbucket a partial solutions. Will address the problem.
    Working on it. * Benoit: there is a YangValidator
    (http://www.yangvalidator.com/) that will extract the YANG data models out
    of drafts and compile them * Thomas: Is that the same tool for your website
    * Benoit: mainly yes. But you can send me the txt file before posting to
    check with the latest compiler * Thomas: what do you mean compiling *
    Benoit: we have a pyang syntax checker * Xavi: aware, we will solve this *
    Benoit shows curves and the green curve of compiling models rising at
    http://claise.be/IETFYANGPageCompilation.png

* _[07.10]_ Charter Update
    * Brian asked us to add the YANG model back into the proposed charter
    * TW: so administrative mostly, OK if we don't address this right away
    * PT: Brian asked is to indicate that there are dependencies
* _[07.??]_ 802.15.4: status
    * presented by Pat Kinney
    * new happening in 802.15
    * new regulatory PHY, to address India high power, too
    * high rate 2MBps PHY backward compatible with 256Kbps in 2.4GHz band
    * KPM ongoing
    * L2R in letter ballot
    * ULI study group
    * 802.15.4t approved PAR. Adapt 15.4 to a new frequency band
    * changes needed in 15.4g, hopefully added in 4t
    * 802.15.4u approved PAR. New PHY backwards compatible to 250kbps, will be
    MFK, 2Mbps data-rate. 8 times faster. more users in the same channel. for
    the same duration of a message, over 1kB of frame size. Very important and
    would help 802.15.4 and 6TiSCH. * PT: in 15.4g, usual need for IPv6 is
    1500, 1280 minimal MAX MTU. We must guarantee 1280 on any IPv6 link. * Pat:
    hopes that open up than 4g, i.e. 2000 bytes. But that would be 9ms of
    duration. Not sure whether would be possible with 6TiSCH. * PT: 6LoWPAN
    says that we need to send 1280, not more. With 1280, we're happy. * TW: is
    802.15.4u same as 802.15.4 without DSSS? * Pat: u means that we will add on
    to it. In the past we had a lot of amendments. We will be having n and q as
    well. * Pat: in this case, will be MSK * Pat: draft PAR for 802.12.12.
    Approval in March time frame in Macau, China. Upper layer interface. We
    want to integrate L2 functionalities into a standard upper layer interface.
    Right now, fragmentation can be done KMP or 6LoWPAN, etc. Lost of overlap
    and confusion. We need one standard to do what we want to do in a
    consistent manner. We want to take 6top and integrate into 802.15.12 so we
    can do new IEs as it is part ot 802.15 group. Purpose: integrate and
    harmonize. Example: fragmentation. Network configuration, power control,
    modulation encoding. More capabilities than LLC. * Pat: Questions? * Pat:
    sent out e-mail indicating that 802.15.4-2015 approved. Will be published
    in Q1 2016. 6 months after that, will be in get802 program. You can now buy
    the draft now. When published, you can buy on the IEEE SA site now. Late
    2016, in the 802 program. * Pat: sent recommendation for using sub-ID IE.
    We'll see what 6TiSCH wants to do. * Pat: the 802.15.4-2015 solves the
    PANID confusion. We issued a dedicated doc. * Pat: went back to 4-octet
    frame counter. * Thomas: asking confirm that the ASN for security is still
    5 octets * Pat: Yes. And there is a byte for security. And teh nonce for
    TSCH is the 5 octets ASN * Pat: questions? * Thomas: need to reflect on the
    slide and come back on the mailing list * Pat: questions?
* Pascal coordinates with lavanyahm to get full name for minutes
* _[07.??]_ 6lo drafts (BBR and 6LoRH)
    * 6lo-routing-dispatch
        * adopted in 6lo
        * draft will be split in 2 drafts: one for RPL, one for Paging
        * plugtest in Berlin?
        * TW: This will be done in Paris. Since we tried to do IP in IP, we
        broke working interoperation. Goal is to restore interop based on this
        draft * PT: great, the feedback from the plutest will be very important
        for the draft. If the IP in IP is a nightmare we can come back to 6MAN.
    * 6lo-backbone-router
        * pending adoption
        * Berlin
        * XV: we discussed this, and we think this is more a 6lo thing, related
        to the BB. For the plugtest, will test * PT: 6LoWPAN registration from
        6lowpan node to 6LR. We will be registering the target address, not the
        source address. * PT: The RA is changed to indicate that teh 6LR
        supports this. The the mote that acts as a RPL root must register on
        behalf of the motes that are in its 6TiSCH network. BB router is not a
        mote, but found 2-3 people who want to implement. The change is in the
        NA. Capability to send registration (NS+ARO) option. Code * TW: The
        piece in the motes is easy to implement and I'm not concerned there.
        I'm more concerned by the interaction between the motes over the
        backbone, dissectors etc * PT Yes, we now carry the ARO option in ND
        messages over the backbone. That needs to be dissected, but that is a
        small addition. Probably people doing the openWRT will do it. DIego has
        a stucdent I think who is working on it.
* _[07.??]_ PlugTest Scope
    * MR: we had a call for scope
    * in Paris, in Inria, 2-4 Feb, we still have to decide whether full 3 days
    * technical: we want to keep the test that we did last time, keep for
    example multi-hop scenario. We need to add as well the 6top draft.
    Discussion on whether we add SF0 as well. Given the timeline, will be too
    short, so we just want to focus on the basic 6P interaction. We also
    probably include the 6loRH. Draft spec by 18 Dec. Final version 22 Jan. *
    thanks to OpenMote, each participant will get Golden Device. We plan to
    have an updated version of the dissector. * invitation has been sent by
    ETSI. we expect people to register. * TW: very cool, after the plugtest we
    will have the minimal implementation + 6lo routing dispatch which has set
    the address in RH3 to 2 bytes. After that, depending on the minimal
    configuration, we will have distributed scheduling which will determine
    which cells will be removed and re-allocated. * PT: should minimal then
    point to 6loRH * PT: right before the meeting, published summary to the ML.
    To answer Ralph, we need to insist that we support 6LoWPAN. Xavi, please
    review the summary. Then we will work with Brian to see if this answers his
    concerns. * Thomas: do we make the 6LoRH a MUST in minimal * Pascal: looks
    like the right thing to do but then do we deprecate calssical IP in IP / RH
    / RPI ? * Pascal: We need to poll the ML on this
* _[07.??]_ 6top drafts (next steps)
    * Xavi: drafts stable in the recent month. Presenting a summary of issues.
    Addressed in the ML and current version. * Xavi: Need to process item 2
    about sequence numbers. I think we'll use a token * Pascal: that is fine,
    as long as we can transactionally ensure that both sides agree on the cell
    attribution * Thomas: There was also a 3-way question * Pascal: Yes, the
    parent always allocates the cells in both directions. If the child is in
    need, then it can request an allocation and provide a black list of times
    that it can not accept. Then the parent comes with a cell list that avoids
    those times. Then the child selects a cell, that's 3 messages total. *
    Thomas: how long we wait fro retry is out of the scope of 6top. That's part
    of the scheduling function (SF). * Xavi: use existing IEs vs. agree with
    IEEE. This is ongoing and need to sync with Pat * Pascal: please cc the
    IEEE interest group when we discuss this
* _[08:07]_ AOB next call is after the YE break

* _[08.10]_ Meeting ends