Minutes Webex 10 October 2014, 6TiSCH WG
Note: timestamps in PDT.
- 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
- 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)
- Xavi Vilajosana
- Pascal Thubert
- Thomas Watteyne
- Thomas Watteyne
- Pascal Thubert
- Ariton Xhafa
- Diego Dujovne
- Guillaume Gaillard
- Ines Robles
- James Pylakutty
- Maria Rita Palattella
- Michael Richardson
- Nicola Accettura
- Pat Kinney
- Patrick Wetterwald
- Raghuram Sudhaakar
- Rene Struik
- Sedat Gormus
- Xavi Vilajosana
- 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.
- 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
- [08.05] Meeting starts
- Pascal starts recording
- Proposed Agenda [Thomas]
- TSCH draft
- YANG model format
- Close discussion of flow labels
- 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 firstname.lastname@example.org 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.
- [Thomas] Next meeting scheduled 10/24/2014.
- [09.11] Meeting ends