1. 6tisch Avatar 6tisch
  2. admin
  3. meetings

Wiki

Clone wiki

meetings / 130809_webex

View History

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

Slides

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, 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?)
    • 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

Updated