[6tsch] minutes webex 4 October 2013

Thomas Watteyne <watteyne@eecs.berkeley.edu> Fri, 04 October 2013 18:04 UTC

Return-Path: <twatteyne@gmail.com>
X-Original-To: 6tsch@ietfa.amsl.com
Delivered-To: 6tsch@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 72D1221F9D92 for <6tsch@ietfa.amsl.com>; Fri, 4 Oct 2013 11:04:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 6vDGMsn80MQX for <6tsch@ietfa.amsl.com>; Fri, 4 Oct 2013 11:04:31 -0700 (PDT)
Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id D8EA221F9C6A for <6tsch@ietf.org>; Fri, 4 Oct 2013 11:04:28 -0700 (PDT)
Received: by mail-pa0-f46.google.com with SMTP id fa1so4479770pad.19 for <6tsch@ietf.org>; Fri, 04 Oct 2013 11:04:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=AowsAxleWJJPhkBYJ5iZxzFIgv/jHA8dWfTCQZl1XDQ=; b=o924ItKKPXaEY8jCnZQXmk41HWnagfHCeC8lX1BM6K8Tb9HizkzRg4PSDsS/GdkhLQ GblVDuSL127ih5gBtXITGdoxQqxAJRfb5sqFfS6ntw6ErmqZ6MzBDptXaelIWIsWS3C1 y01jqq6yOcnlC0TNaRiRH9Q4TlG5ePwgjEQiqxBHsSPE6Igp52TSL+RNJJMaeAJTQ8hx SByP0oSYg+/xFzVjdklvOiwZ4D8sf6uumCnrpweIyX/TxnTuQ3SfCxazN32uI8+wWAom fCD7eA21R87HPKHUNVy0EppZVqNxmU1l7RUdvNibyXyH6zAmYcOuOWuU83SqAiJppwVb uehw==
X-Received: by with SMTP id i1mr15903576pbw.37.1380909867543; Fri, 04 Oct 2013 11:04:27 -0700 (PDT)
MIME-Version: 1.0
Sender: twatteyne@gmail.com
Received: by with HTTP; Fri, 4 Oct 2013 11:04:06 -0700 (PDT)
From: Thomas Watteyne <watteyne@eecs.berkeley.edu>
Date: Fri, 4 Oct 2013 11:04:06 -0700
X-Google-Sender-Auth: 9vacumROkuPsKfUDKPTMXm1C_3Q
Message-ID: <CADJ9OA_=oKGtjaFWTNj9JV7kJDFGJazE3c_nO2f7hq1XhHzC_Q@mail.gmail.com>
To: 6TSCH <6tsch@ietf.org>
Content-Type: multipart/alternative; boundary=e89a8f923c641f359904e7ee22a9
Subject: [6tsch] minutes webex 4 October 2013
X-BeenThere: 6tsch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tsch>, <mailto:6tsch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6tsch>
List-Post: <mailto:6tsch@ietf.org>
List-Help: <mailto:6tsch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tsch>, <mailto:6tsch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Oct 2013 18:04:33 -0000


You will find the minutes of this week's webex below.

FYI, all the minutes and slides are archived a

Thanks to Xavi and Pascal for taking notes!

As usual, please fix anything we might have missed directly in the e-mail
and reply. We will approve and adopt the minutes at the beginning of the
next call.



Minutes Webex 4 October 2013, 6TiSCH group

Note: timestamps in PDT.
Taking notes *(using Etherpad)*

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

Present *(alphabetically)*

   1. Thomas Watteyne
   2. Pascal Thubert
   3. Diego Dujovne
   4. Geraldine Texier
   5. Guillaume Gaillard
   6. Ken Bannister
   7. Maria Rita Palattella
   8. Nicola Accettura
   9. Patrick Wetterwald
   10. Pouria Zand
   11. Qin Wang
   12. R. Nabati
   13. Raghuram Sudhaakar
   14. Tom Phinney
   15. Xavi Vilajosana


   - Webex recording (audio+slides,streaming)


   - slides_131004_webex.ppt<https://bitbucket.org/6tsch/meetings/src/master/131004_webex/slides_131004_webex.ppt>pt>:
   slides shared during the call


   - Administrivia *[3min]*
      - Approval agenda
      - Approval minutes last call
      - IETF88: preliminary agenda
   - minimal draft *[5min]*
      - join priority width
      - comments/changes
   - update models draft *[35min]*
      - summary Tuesday discussion
      - proposed ToC
         - separate payload format from CoAP resource mapping?
      - 6lo thread on monitoring
         - "[6lo] [coman] WG Review: IPv6 over Networks of
         Resource-constrained Nodes (6lo)"
         - YANG/NETCONF vs. SMIv2/SNMP
         - information model in English, turned into YANG?
      - communication paradigms
         - 5-6 communication paradigms in architecture draft?
         - terminology: interaction model and communication paradigm
      - On-the-fly scheduling *[15min]*
      - overview
      - discussion
         - implementation
         - hysteresis
         - TASA
         - queue size vs. bundle usage
         - bit
         - separating algorithm from mechanism
      - goals and next steps?
   - AOB *[2min]*


   - *[08.04]* Meeting starts
   - *[08.05]* Administrivia
      - Approval agenda

      No issues raised. Agenda approved.

      - Approval minutes last call

      No issues raised. Minutes approved.

      - IETF88: preliminary agenda
         - IETF preliminary agenda has been delayed 1 day. Should appear
         today at http://www.ietf.org/meeting/88/.
         - Until Monday to request a change in meeting schedule (hopefully
         don't need to).
         - Final agenda published 11 October.
         - Cut-off date for draft submission (including -00) is 21 October.
      - minimal draft
      - join priority width
         - range of join priority is defined as 0x3f
         - answer from IEEE802.15.4e editor is that 0x3f might be an error
         and the byte is intended to be used as a complete byte.
         - this most probably means that using 0x00-0xff as the range
         (rather than 0x00-0x3f) is OK.
         - *[Qin]* This is good news.
      - comments/changes
         - Thanks to *Xavi* for incorporating all the changes!
         - *[Xavi]* Will incorporate Maria Rita's comments today.
      - update models draft
      - summary Tuesday discussion *[Raghuram]*
      - discuss contents of the data model draft
      - great input (including from Dan Romascanu) on how we can be
      consistent with the terminology to fit a data model as RFC3444 defines.
      - include:
         - naming convention to URI
         - mapping of URI to 6top resources
         - Message formats
         - Extensible resources
            - profile based definition?
            - how do we discover the profile, i.e. what messages will be
            exchange for that discovery methods?
            - custom uri to send back messages when event is detected
            - profile based definitions
            - including set of extensible resources e.g. PCE could install
            a profile that it needs for its computation
         - *Raghuram* to push current version on bitbucket repository today.
      - see https://bitbucket.org/6tsch/draft-sudhaakar-6tisch-coap
      - Discussion
         - *[Xavi]* The data model should be reused. Draft seems to bind it
         with CoAP. Should be separated for use e.g. by RSVP to be described in
         another draft?
         - *[Raghuram]* agreed. But there is limited time.
         - *[Pascal]* why is the content so tightly bound to CoAP?
         - *[Raghuram]* define the data model to be reusable in different
         - *[Pouria]* presents 6TiSCH MIB.
         - *[Qin]* Indicate for fields that can be read what observable
         trigger can be used.
         - *[Thomas]* Are there any fields which can be read for not
         - *[Qin]* Having that option might enable a better handling of
         registration to observe, triggers, etc.
      - 6lo thread on monitoring
         - *[Thomas]* 6lo discusses the proposed charter of 6lo. Related
         MIB modules, they are looking for a way to monitor the state of a
         6lo/6LowPAN network.
         - YANG/NETCONF vs. SMIv2/SNMP
         - Encourage editors of this draft to follow the 6lo discussion.
         - *[Thomas]* Clarifying question: NVP vs TLV?
         - *[Raghuram]* Name Value Pair: human readable ASCII format.
      - communication paradigms *[Pascal]*
         - ISA100 has 3 comm paradigms.
            - client/server
            - pub/sub
            - source/sink
         - abstract concept.
            - *[Tom]* based on IEC61158
         - we have similar approach, but more options
            - point to point model (CoAP REST model)
            - At L3, multihop along track (RSVP-like)
            - At l2, single hop (6top)
         - Mapping of comm paradigm to protocol:
            - *[Thomas]* why SNMP?
            - *[Pascal]* way to implement Client/server. Just examples of
            protocols that can be used to implement the communication paradigms.
         - what document is the right place:
            - informational model: high level overview.
            - data model: YANG seems the direction to define the data model.
            - implement the data model in different data formats (CBOR,
            NVP, TLV, etc.)
            - data and command do not need to be tightly bound.
         - *[Raghuram]* in terms of CoAP cannot separate payload than URI
         and method, so the implementation is tight to the communication model.
         - *[Thomas]* do not see source/sink model as needed per-see. CoAP
         provides the observe and notifications.
         - *[Tom]* Source/sink is a application communication paradigm and
         there is no reason that it needs to be modelled that way in the
         communication layers. Most people end up with wireless
running alerts to a
         single device (e.g. gateway, BBR). n-to-1 at the low layers.
         applies to the application, and how you model it in the lower
layers is
         really the responsibility of the implementers.
      - *[08.56]* on-the-fly scheduling
      - overview *[Diego]*
         - Idea is to adapt the number of cells according to the traffic
         constrains (queue size, etc.) on the fly.
         - This is a distributed approach.
      - discussion
         - implementation
            - run on top of 6top
            - define statistics and interface, algorithm is independent
         - hysteresis
            - map queue sizes to link requirements.
            - reaction time to avoid hysteresis
            - handle collisions with other neighbors scheduling same cell
            (not a global picture)
         - TASA
            - Distributed TASA?
         - IPR Cisco:
            - *[Diego]* what is covered?
            - *[Pascal]* Ciscp IPR does not matter as it covers many
            aspects, also in RPL.
            - *[Pascal]* Mentioning the IPR is mandatory, mentioned it in
            ML for that reason.
         - goals and next steps?
         - *[Thomas]* Good exercise to detect missing aspects on 6top as it
         is a use case on top of 6top.
         - *[Diego]* Yes, will do.
      - *[09.07]* AOB

   No other business raised.

   - *[09.08]* Meeting ends