Subject: [6tsch] minutes webex 9 August 2013

From: Thomas Watteyne <[email-masked]>
Date: Fri, 9 Aug 2013 10:45:21 -0700

All,

You will find the minutes of today's webex below.

FYI, all the minutes and slides are archived a
https://bitbucket.org/6tsch/meetings/.

Thanks to Xavi for taking notes!

As usual, fix anything we might have missed directly in the e-mail and
reply.

Thomas

-----

Minutes Webex 09 August 2013, 6TSCH group

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

   1. Xavier Vilajosana
   2. Thomas Watteyne

Present *(alphabetically)*

   1. Diego Dujovne
   2. Guillaume Gaillard
   3. Kris Pister
   4. Pascal Thubert
   5. Pouria Zand
   6. Qin Wang
   7. Raghuram Sudhaakar
   8. Thomas Watteyne
   9. Tom Phinney
   10. Xavi Vilajosana

Recording

   - Webex recording (audio+slides,streaming)
   -
   https://cisco.webex.com/ciscosales/lsr.php?AT=pb&amp;SP=MC&amp;rID=70524612&amp;rKey=5bbefc20bc163741<https://cisco.webex.com/ciscosales/lsr.php?AT=pb&SP=MC&rID=70524612&rKey=5bbefc20bc163741>
    *[60min]*

Slides

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

Agenda

   - debrief Berlin *[2min]*
      - pre-BoF (minutes & outcome)
      - BoF (minutes & outcome)
   - revamped charter *[3min]*
      - overview of updates
      - new work items
      - discussions and open issues
   - "master plan" next steps *[10min]*
      - "Timeslot Management Methods and Formats"
         - what is it about?
         - what is it not about?
      - "minimal 6TSCH configuration"
         - rename draft and title?
         - work on RPL
         - relationship with TS mgt
         - towards demo/simulation/interop
         - we will ask for contributors and reviewers
      - 6TSCH architecture
         - distinguish current/future work wrt charter or remove future?
      - Technical discussion on "Timeslot Management Methods and Formats" *
   [25min]*
      - type of flows (push? pull?)
      - format (binary JSON? custom?)
      - reporting requirements (e.g. TS performance, alarms)
   - Technical discussion on "minimal 6TSCH configuration" *[10min]*
      - transport mechanism (CoAP?)
   - renaming group *[5min]*
      - statistics so far
      - next steps?
   - AOB *[2min]*

Minutes

   - Pre-discussion:
      - *[Thomas,Qin]* OT vs IT and the term "convergence of IT and OT".
      Similar terms used in smart grid.
      - *[Raghuram]* Naming, what do we do?
   - *[08:03]* Agenda
      - wrap up what happen in Berlin
      - technical discussions at second half
      - end: renaming the group discussion
      - administrative:
         - cleaning minutes of pre-BoF and BoF
         - Do not formally approved today, but do it next week as they've
         been published recently.
         - Will be uploaded at the proceedings of IETF87
      - debrief Berlin
      - pre-BoF (minutes & outcome)
      - BoF (minutes & outcome)
      - Next call to be approved.
      - Outcomes of the BoF:
         - clarity of goals was main concern.
      - highlight the changes done to the charter:
         - scope too big
         - identify first steps and focus the charter on that
         - charter reduced by half
         - from 7 to 3 work items
         - does not change what we want the solution to look like at the
         end.
         - IESG has no problem with WGs re-chartering, this is common
         procedure
      - revamped charter
      - new work items:
         - timeslot management methods and formats
         - minimal 6TSCH configuration
         - 6TSCH architecture (version 1):
            - will go to informal RFC, at each recharter a new RFC will be
            created.
         - Open Items:
         - hard-coded -> pre-configured
         - add PCE a WG to interact with.
         - rename BBR -> LBR. Sefinitions are very close. Suggestion is to
         use LBR so it is aligned to ROLL work.
         - *[Pascal]* pre-configured is not the same as hard-coded.
         Pre-configured has more complexity.
      - "master plan" next steps *[10min]*
      - How the different documents interact.
      - "Timeslot Management Methods and Formats"
         - what is it about?
            - how to format commands from the PCE to the note and
            information sent from the mote to the PCE (statistics,
alarms, etc.).
            - identify the flow of what is moving on the network
            - bits and bytes of commands. What does the payload contain?
         - what is it not about?
            - NOT addressing the transport protocol
            - NOT the policy (when, etc..)
            - NOT a network management document (architecture)
         - *[Pascal]* PCE is not the right term. Better to refer to an
         "entity".
         - This is a new document not based on minimal configuration.
         - *[Qin]* does this work need to support both static and dynamic
         cases?
         - *[Thomas]* These formats will also be used in static case. This
         document will define the formats, this is in part preparatory
work for the
         next charter which will address dynamic scheduling, where
these formats
         then will be used for dynamic scheduling.
         - *[Guillaume]* Are we focusing on centralized cases?
         - *[Pascal]* The schedule is what is pushed at the beginning of
         the network and we run with it. Routing is dynamic,
scheduling is static.
      - "minimal 6TSCH configuration"
         - rename draft and title?
            - Basic vs. minimal - make sure the title and filename are
            aligned.
            - At the end of the document, expose the need for a CoAP
            service where a schedule can be isntalled.
            - *[Qin]* the charter includes only static so the CoAP service
            is kind of dynamic. So address that on that dynamic.
               - not necessary to include that in the document.
            - *[Pascal]* we need a little bit of dynamism to cope with
            interop - more interesting cases.
            - *[Thomas]* Non-milestone items "interoperability guide", add
            the CoAP service there as a tool to support better interop testing.
            - *[Pascal]* There is windows to be able to modify the
            schedule, support the case of having a personalized
schedule at each node.
            - *[Thomas]* In my mind, static schedule is synonymous to
            shared medium, no complete determinims, but you have
connectivity on shared
            slots. Have RPL running and later have PCE working on the network.
            - *[Kris]* The idea is to have the minimum configuration to
            enable interop.
         - Work on RPL.
         - Relationship with timeslot management.
         - Towards demo/simulation/interop.
         - We will ask for contributors and reviewers.
      - "6TSCH architecture"
         - Do we distinguish what the current work to the future work?
         (future == real solution at the end of our work)
         - Have new revisions in RFCs that update the old ones.
         - In current architecture document, should we differentiate that?
         - Support centralized / distributed -- Keep it in the documents.
         It is a vision so we should keep it and highlit what goes to
the charter.
         - Distinguish current/future work wrt charter or remove future?
      - *[08:41]* Introducing Diego
Dujovne<http://eit.udp.cl/academico/ddujovne>,
   new participant to calls. Has been following 6TSCH ML, was in Berlin.
   - *[08:42]* Technical discussion on "Timeslot Management Methods and
   Formats"
      - Types of control flow (push? pull?)
         - be able to give the commands to say: this config is for a time
         slot or for a bundle of time slots
         - define size of bundles.
         - Be able to install directly at each node, no 6top interaction.
         - How is the control flow (pull? push?). The devices waits? or the
         device pulls? need to be defined.
         - *[Thomas]* 3 flows: Management to node (inform), node to
         Management (report/inform), Node to management (alarm).
         - List the flows we need to support.
      - Format (binary JSON? custom?)
         - to look at bson (http://bsonspec.org/#/specification)
      - reporting requirements (e.g. timeslot performance, alarms)
         - what are the reporting requirements?
      - Technical discussion on "minimal 6TSCH configuration" *[10min]*
      - transport mechanism (CoAP?)
         - For now we will consider this into the interop document and not
         in the minimal draft.
         - related that to other WGs.
      - *[08:54]* Renaming group
      - Discussion probably came from fact that we need to stress more that
      "sixtus" is the pronunciation.
      - Lot's of pushing on the ML to keep the name 6TSCH.
      - *[Tom]* we can write "(sixtus)" after 6TSCH, a least during some
      time.
      -
      - Action item: *Pascal* to write e-mail to IESG about keeping acronym
      but writing "(sixtus)" right after.
   - *[09:00]* AOB

   No other business raised.

   - *[09:02]* meeting ends