Clone wiki

meetings / 141010_webex

Minutes Webex 10 October 2014, 6TiSCH WG

Note: timestamps in PDT.

Connection details

Resources

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 proceedings@ietf.org at most 10 days after call
    • IETF91 (Honolulu, Hawaii, November 9-14, 2014, http://www.ietf.org/meeting/91/)
  • [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

Updated