Subject: [6tisch] draft minutes webex 10 October 2014, 48h review period

From: Thomas Watteyne <[email-masked]>
Date: Tue, 14 Oct 2014 13:30:56 -0700

All,

You will find the draft minutes of the last call below (also at
https://bitbucket.org/6tisch/meetings/).

Reply with comments/suggestions in the next 48h; we will send the final
version to IETF proceedings on Friday 17 October.

Thomas

---

Minutes Webex 10 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=36a3b7df06694258a3ac65bfc519212f
   - Wiki: https://bitbucket.org/6tisch/meetings/wiki/141010_webex
   - Slides:
   https://bitbucket.org/6tisch/meetings/src/master/141010_webex/slides_141010_webex.ppt

Taking notes *(using Etherpad)*

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

Present

   1. Thomas Watteyne
   2. Pascal Thubert
   3. Ariton Xhafa
   4. Diego Dujovne
   5. Guillaume Gaillard
   6. Ines Robles
   7. James Pylakutty
   8. Maria Rita Palattella
   9. Michael Richardson
   10. Nicola Accettura
   11. Pat Kinney
   12. Patrick Wetterwald
   13. Raghuram Sudhaakar
   14. Rene Struik
   15. Sedat Gormus
   16. Xavi Vilajosana

Action Items

   - *Pat* to look into the 15.4e specs and send e-mail to ML about whether
   a node is required to join the node which advertises the lowest priority.
   - *Thomas* to publish new version draft-ietf-6tisch-tsch based on
   discussion.
   - *WG* to review completeness of YANG interface in
   draft-ietf-6tisch-6top-interface
   - *Xavi* to update draft-ietf-6tisch-6top-interface and replace
   "IEEE802.15.4e" by "IEEE802.15.4"
   - *Xavi* to publish current version of draft-ietf-6tisch-6top-interface
   - *WG* to participate in 6lo and push for the HBH compression draft.
   - *Pascal* to send email to 6TiSCH ML to get consensus on going with
   compressed RPL option within 6lo.

Agenda

   - Administrivia *[3min]*
      - Approval agenda
      - Approval minutes last call
      - update format of calls
      - IETF91 6TiSCH WG meeting
   - Wrapping up draft-ietf-6tisch-tsch *[15min]*
   - YANG model *[15min]*
      - updates to format
      - is interface complete?
   - Closing discussion on use of flow labels *[15min]*
   - RFC7322: RFC Style Guide *[5min]*
   - AOB *[2min]*
      - reminder next calls

Minutes

   - *[08.05]* Meeting starts
   -

   Administrivia *[3min]*
   - *Pascal* starts recording
      - Proposed Agenda *[Thomas]*
         - TSCH draft
         - YANG model format
         - Close discussion of flow labels
         - RFC7322
      - Call for approval Agenda *[Thomas]*

      No issues raised. Agenda is approved.

      - Call for approval minutes last call *[Thomas]*

      No issues raised. Minutes last call approved.

      -

      Update on interop eveny *[Thomas]*
      - ongoing discussions with ETSI to organize 6TiSCH interop during
         IETF93 (Prague, Czech Republic, July 19-24, 2015)
         - companies implementing 6TiSCH, mark your calendars
         - ETSI will participate in defining interop tests and associated
         framework
         - *[Pascal]* idea is to push minimal draft to IESG end of November
         - *[Michael]* Results from interop may trigger updating the RFC
         - *[Pascal]* absolutely
      -

      Format of the calls have changed *[Thomas]*
      - we haven't been following the IESG guidance on interim meetings (
         https://www.ietf.org/iesg/statement/interim-meetings.html)
         - has been corrected now. New procedure:
            - calls announced to 6TiSCH ML and ietf-announce at least 2
            weeks before
            - agenda sent to 6TiSCH ML at least 1 week before
            - minutes and attendance published on 6TiSCH ML, CC
            [email-masked] at most 10 days after call
         - IETF91 (Honolulu, Hawaii, November 9-14, 2014,
      http://www.ietf.org/meeting/91/)
         - 90min session requested, early in the day for remote
         presentations through meetecho
         - preliminary agenda to be published today at
         https://datatracker.ietf.org/meeting/91/agenda.html
      -

   *[08:13]* wrapping up draft-ietf-6tisch-tsch *[Thomas]*

   *Thomas* goes over slides to recap the changes suggested in
   http://www.ietf.org/mail-archive/web/6tisch/current/msg02547.html

   - *[Maria Rita]* Answered e-mail with typos fixed.
      - *[Pascal]* Same, answered e-mail with typos fixed.
      - *[Ines]* About issues she raised, agrees with the rewording.
      - *[Thomas]* We need to discuss if we want to put lots of text about
      join priority in this draft.
      - *[Rene]* Are we going to use this join priority in the 6TiSCH work?
      - *[Thomas]* yes.
      - *[Rene]* Not sure why we should use this, as only one parameter a
      mote can use to choose a node to attach to
      - *[Pat]* the join priority is intended for a device to select which
      beacon to respond to in case it receives more than one. It is
not mandatory
      to join the one with lowest priority, is only information a mote can use.
      - *[Rene]* I think that the spec indicates to join the node with
      lowest priority.
      - *[Pat]* yes, but which node a new node joins depends on what the
      device decides is important.
      - *[Thomas]* In the end, a node can join whichever node it wants.
      - *[Pascal]* We do not want to describe how 6TiSCH uses the join
      priority in draft-ietf-6tisch-tsch, this draft is about information and
      context.

      Action item: *Pat* to look into the 15.4e specs and send e-mail to ML
      about whether a node is required to join the node which advertises the
      lowest priority.

      - *[Rene]* checks if this is mandatory, the text just indicates that
      a node selects a node according to the join priority.
      - *[Thomas]* the text indicates "preference" so this is not mandatory.
      - *[Pat]* if you want to change you can change it
      - *[Rene]* we are discussing if this is a 6TiSCH issue.
      - *[Pat]* for me is an implementer issue. This discussion is beyond
      the scope of the standard. This is part of the implementer's decision.
      - *[Thomas]* Lets continue discussion on ML.
      - *[Rene]* I need technical arguments.

      Action item: *Thomas* to publish new version draft-ietf-6tisch-tsch
      based on discussion.

      -

   *[08:30]* YANG model in draft-ietf-6tisch-6top-interface *[Xavi]*
   - goal of today's presentation: explain what was done in the draft, and
      call for reviews
      - YANG doctor Carl Moberg helped Xavi and Qin fine-tune the syntax of
      the YANG model. Did NOT touch semantics of it.
      - Xavi believe the YANG model is complete, with maybe some very minor
      syntactic changes.
      - Xavi calls for the WG to review the contents of the model. This
      model is one of the important outputs of 6TiSCH. We need a deep look into
      it .

      Action item: *WG* to review completeness of YANG interface in
      draft-ietf-6tisch-6top-interface

      - YANG model divided into 6top MIB and 15.4 PIB
      - status for 6top MIB: model present in draft. Carl Moberg did
      syntactic review only (only grammar, not semantics)

      Xavi shares screen to show table corresponding to YANG model in draft

      - *[Thomas]* What changes did Carl Moberg suggest?
      - *[Xavi]* When expressing the target node address, can be of two
      types (2B or 8B). Expressing in YANG is complicated. Doctor
helped, created
      a group (~type)
      - *[Thomas]* Similar to an enum?
      - *[Xavi]* Yes, similar.
      - *[Pat]* IEEE802.15.4e is part of the IEEE802.15.4 standard. You can
      drop the "e" in the descriptions.

      Action item: *Xavi* to update draft-ietf-6tisch-6top-interface and
      replace "IEEE802.15.4e" by "IEEE802.15.4"

      - Xavi describes the different sections in the MIB. Xavi asks people
      to go through elements, and list what is missing.
      - *[Thomas]* We are chartered to define this set of elements. This is
      a critical contribution in this charter. Let us take a couple of weeks to
      fully review that data model.
      - 15.4 MIB was discussed at IETF90. Will provide a single interface
      to access 15.4 interface.
      - next steps: review functionality, easy since only mapping PIB
      - one thing is left open: security. We don't offer a YAHG model for
      the security elements in 15.4. Open until security architecture.
      - *[Thomas]* worries about dependency on security architecture
      - *[Thomas]* Michael and Rene, let's make sure we progress on
      security architecture.
      - Xavi asks to send comments to the ML.
      - *[Thomas]* is the draft published in its current form?
      - *[Xavi]* No, only in Bitbucket.
      - *[Thomas]* suggest to publish what we have and refresh later for
      semantics
      - *[Xavi]* agreed

      Action item: *Xavi* to publish current version of
      draft-ietf-6tisch-6top-interface

      -

   *[08:41]* compression of RPL option

   *[Pascal]* recaps the discussions about the RPL option. The 6TiSCH WG
   needs to make a decision as of what to do, since we need to send
   draft-ietf-6tisch-minimal to IESG. Plan is to send it to IESG in November.

   - *[Pascal]* should minimal say anything about the RPL option? If we do
      not say anything, we might be forced to use the HBH as defined in 6553
      - *[Michael]* if we define a compressed RPL option, will any node
      have to also accept the (then legacy) RPL option as defined in RFC6553?
      - *[Michael]* I prefer the flow label option as this is simpler.
      - *[Michael]* A node needs to support both the HBH option compressed
      and not so if a node supports that will be compliant and will be able to
      interoperate.
      - *[Michael]* The flow label is a re-implementation of the HBH
      option. The compression of the HBH is a lossless compression.
      - *[Pascal]* We need minimal draft to point to a solution for that
      problem. This means that the draft will contain a normative
reference to an
      RFC which still needs to be finalized. This will stall publication of
      draft-ietf-6tisch-minimal.
      - *[Michael]* Yes, but draft-ietf-6tisch-minimal can sit in editors
      queue while waiting. Sitting in queue sends the message that the document
      is stable.
      - *[Pascal]* Agreed, perfect.

      Action: *WG* to participate in 6lo and push for the HBH compression
      draft.

      - *[Pascal]* Consensus on call is to opt for the compressed RPL
      option within 6lo.

      Action: *Pascal* to send email to 6TiSCH ML to get consensus on going
      with compressed RPL option within 6lo.

      -

   *[09.10]* AOB
   - *[Thomas]* Next meeting scheduled 10/24/2014.
   - *[09.11]* Meeting ends