Re: [6tisch] Minutes webex 23 May 2014

[Thomas Watteyne <[e-mail]>]

All,
Below an updated version with a fixed attendee list.
https://bitbucket.org/6tisch/meetings/wiki/140523_webex has been updated
also.
Thomas

---

Minutes Webex 23 May 2014, 6TiSCH WG

Note: timestamps in PDT.
Connection details

   - Webex Link
   <https://ciscosales.webex.com/ciscosales/j.php?ED=219615007&UID=481905242&PW=NZTRkNDAwOTE1&RT=MiMyMw%3D%3D>
   - Live etherpad for minutes
   <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: [phone]x206802913

Resources

   - Webex recording
   <https://cisco.webex.com/ciscosales/lsr.php?RCID=4e8d1bb9edb04f3081d679c5f80805d8>
    [69min]
   - Wiki <https://bitbucket.org/6tisch/meetings/wiki/140523_webex>: wiki
   page for this meeting
   - slides
   <https://bitbucket.org/6tisch/meetings/src/master/140523_webex/slides_140523_webex.ppt>:
   slides shared during the call

Attendance *(alphabetically)*

   1. Diego Dujovne
   2. Giuseppe Piro
   3. Ines Robles
   4. James Pylakutty
   5. Kazushi Muraoka
   6. Kris Pister
   7. Maria Rita Palattella
   8. Michael Richardson
   9. Nicola Accettura
   10. Pascal Thubert
   11. Pat Kinney
   12. Patrick Wetterwald
   13. Pouria Zand
   14. Rouhollah Nabati
   15. Sedat Gormus
   16. Thomas Watteyne
   17. Tom Phinney
   18. Xavi Vilajosana

Action items

   - *chairs* to contact IETF to ask if it is possible to do the plugfest
   on Sunday.
   - *[Xavi]* and *[Thomas]* to look at issue 7 of minimal draft
   - *Pascal* to send an email to the ML with the proposal of adding part
   of draft-piro to the draft-tsch.
   - *Thomas* to review/clean use of terminology in draft-tsch
   - *Patrick* to send remarks by e-mail to ML.
   - *Pascal* to propose an ad-hoc meeting next Friday dedicated to
   terminology.
   - *Pat* to detail regulatory limits about slotted aloha on ML.

Agenda

   - Administrivia *[10min]*
      - Approval agenda
      - Approval minutes last call
      - plugfest: date
      - architecture draft issues:
         - http://trac.tools.ietf.org/wg/6tisch/trac/ticket/7
         - http://trac.tools.ietf.org/wg/6tisch/trac/ticket/8
         - http://trac.tools.ietf.org/wg/6tisch/trac/ticket/9
      - reviewers needed for draft-piro-6tisch-security-issues
   - Terminology *[15min]*
   - updates minimal draft *[15min]*
      - overview bitbucket changes
      - requirements
   - EB control bits proposal *[15min]*

Minutes

   - *[08:04]* Meeting starts
   - *[08:04]* Administrivia
      - Approval agenda

      No issues raised. Agenda approved.

      - Approval minutes last call

      No issues raised. Minutes approved.

      - plugfest: date
         - plugfest
            - conflict with registration
            - possible problem with rooms available and insurances

            Action item: *chairs* to contact IETF to ask if it is possible
            to do the plugfest on Sunday.

            - *[Xavi]* Need to present tools and techno and we can learn
            from everyone
            - *[Thomas]* need a clear set of goals, something more
            constructive, show outcomes, working demo.
            - *[Xavi]* for 6TiSCH last time objectives apply again
         - architecture draft issues:
         - *[Pascal]* use tickets and resolution mechanism

         Action item: *[Xavi]* and *[Thomas]* to look at issue 7 of minimal
         draft

         - Issue 9 is a clarification.
         - http://trac.tools.ietf.org/wg/6tisch/trac/ticket/7

         In section 7.2, I might read that broadcast DIO and DAO are not
         contained in ICMPv6 messages In section 7.2, I might read
that broadcast
         DIO and DAO are not contained in ICMPv6 messages, but rather that the
         payload is put into a "Data Packet" without an IPv6 header and ICMPv6
         header. Is that intended? [PT] There is an ICMP header; let
me reword that.
         What about: " To broadcast ICMPv6 control messages used by
RPL such as DIO
         or DAO, 6top uses the payload of a Data frames. The message
is inserted
         into the queue associated with the cells which LinkType? is set to
         ADVERTISING. Then, taking advantage of the broadcast cell feature
         established with FrameAndLinkIE (as described above), the RPL control
         message can be received by neighbors, which enables the
maintenance of RPL
         DODAGs. " yes, works for me.

         - http://trac.tools.ietf.org/wg/6tisch/trac/ticket/8

         section 7.5 seems jumbled... maybe just not done yet. [PT] Yes, we
         need to raise an issue on this

         - http://trac.tools.ietf.org/wg/6tisch/trac/ticket/9

         Clarify that a TSCH Schedule is a *set* of 2D matrices Please
         clarify that a TSCH Schedule is a *set* of 2D matrices. Each
         matrices is [slotOffset,channelOffset] sized slotframe, and
determines how
         a particular node assigns the chunks. [PT] Yes, there can be multiple
         matrices formatted globally in chunks that are later
appropriated by devices

         - reviewers needed for draft-piro-6tisch-security-issues
         - *[Michael]* draft-piro explains what 15.4 proposes for security,
         good stuff there. Goes on to add command frames for P2P key
management. On
         that part, we need to decide what we do but grain of salt.
Missing how join
         a new network.
         - *[Pascal]* can part of this draft be included in the tsch draft
         as a solution review?
         - *[Michael]* The draft is a solution document. Having the draft
         it is interesting as it contains information that is relevant and very
         descriptive.

         Action item: *Pascal* to send an email to the ML with the proposal
         of adding part of draft-piro to the draft-tsch.

         - *[08:30]* Terminology
      - *[Patrick]* on terminology: would be great to keep or enhance the
      definition
      - *[Maria Rita]* good suggestion, try to have the same meaning with
      maybe a richer explanation
      - *[Patrick]* ok. examples are timeslot schedule link linktype.

      Action item: *Thomas* to review/clean use of terminology in draft-tsch

      - *[Pascal]* link must be defined the IETF way so we can explain
      - *[Patrick]* terminology should be in one document, right now there
      are multiple definitions e.g. draft-tsch Annex A
      - *[Thomas]* could you send a list of what you found?
      - *[Patrick]* yes will send remarks through email

      Action item: *Patrick* to send remarks by e-mail to ML.

      - *[Patrick]* cell vs. timeslots is unclear. e.g. a track is a suite
      of cell not timeslots
      - *[Patrick]* in terminology it says that the broadcast cell has a
      mac address. Cell is referencing a slotframe handle

      Action item: *Pascal* to propose an ad-hoc meeting next Friday
      dedicated to terminology.

      - *[08:44]* minimal draft
      - *[Thomas]* going though the questions in the scope draft
      - *[Thomas]* Can we agree that, when ONLY minimal is running:
         - all nodes in the network have the same schedule
         - the schedule never changes
      - *[Pat]* shouldn't the schedule change when new nodes are admitted
      - *[Xavi]* running minimal does not prevent other mechanisms on top
      - *[Kris]* not here we're just doing slotted aloha
      - *[Pat]* maybe regulatory issues with slotted aloha, let us discuss
      on the reflector

      Action item: *Pat* to detail regulatory limits about slotted aloha on
      ML.

      - *[Kris]* DAGroot to be able to set the links in the EB. The only
      think that changes the slotframe length.
      - *[??]* what happen if there are potentially 2 DAGroots?
      - *[Kris]* if this is the case then 2 networks will be form
      - *[Kris]* The simplest thing is to put TXRX slots in the beginning
      of the slotframe. You have a variable length of the slotframe.
      - *[Kris]* slotframe provides a trade-off between bandwidth and
      energy consumption. That is what determines how the network behaves.
      - *[Thomas]* do we prevent the EB to use frame and link IE and keep
      that minimal pre-configured slotframe?
      - *[Kris]* We need to be compliant to IEEE802.15.4e.
      - *[Thomas]* So must be there which implies that hardcoded minimal is
      not useful.
      - *[Kris]* Maybe we could poll the WG about whether they have the
      minimal schedule hardcoded in their implementation.
      - *[Michael]* In the EB, is there a flag that says to turn on/off
      minimal, or is the schedule described in the EB.
      - *[Thomas]* The latter.
      - *[Michael]* In general, it's better to think about what the
      receiver does when receiving something it doesn't understand, rather than
      focusing on what the transmitter is allowed to do.
   - EB control bits proposal

   No time.

   - *[09.14]* Meeting ends



On Fri, May 23, 2014 at 11:59 AM, Thomas Watteyne <
[e-mail]> wrote:

> All,
>
> You will find the minutes of the last webex below.
>
> FYI, all the minutes and slides are archived a
> https://bitbucket.org/6tisch/meetings/.
>
> Thanks to Xavi and Pascal for taking notes!
>
> As usual, please fix anything we might have missed directly in the e-mail
> and reply.
>
> Thomas
>
>  ---
>
> Minutes Webex 23 May 2014, 6TiSCH WG
>
> Note: timestamps in PDT.
> Connection details
>
>    - Webex Link
>    <https://ciscosales.webex.com/ciscosales/j.php?ED=219615007&UID=481905242&PW=NZTRkNDAwOTE1&RT=MiMyMw%3D%3D>
>    - Live etherpad for minutes
>    <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: [phone]x206802913
>
> Resources
>
>    - Webex recording
>    <https://cisco.webex.com/ciscosales/lsr.php?RCID=4e8d1bb9edb04f3081d679c5f80805d8>
>     [69min]
>    - Wiki <https://bitbucket.org/6tisch/meetings/wiki/140523_webex>: wiki
>    page for this meeting
>    - slides
>    <https://bitbucket.org/6tisch/meetings/src/master/140523_webex/slides_140523_webex.ppt>:
>    slides shared during the call
>
> Attendance *(alphabetically)*
>
>    1. Diego Dujovne
>    2. Giuseppe Piro
>    3. Ines Robles
>    4. James Pylakutty
>    5. Kazushi Muraoka
>    6. Kris Pister
>    7. Michael Richardson
>    8. Nicola Accettura
>    9. Pascal Thubert
>    10. Pat Kinney
>    11. Patrick Wetterwald
>    12. Pouria Zand
>    13. Rouhollah Nabati
>    14. Sedat Gormus
>    15. Thomas Watteyne
>    16. Tom Phinney
>    17. Xavi Vilajosana
>
> Action items
>
>    - *chairs* to contact IETF to ask if it is possible to do the plugfest
>    on Sunday.
>    - *[Xavi]* and *[Thomas]* to look at issue 7 of minimal draft
>    - *Pascal* to send an email to the ML with the proposal of adding part
>    of draft-piro to the draft-tsch.
>    - *Thomas* to review/clean use of terminology in draft-tsch
>    - *Patrick* to send remarks by e-mail to ML.
>    - *Pascal* to propose an ad-hoc meeting next Friday dedicated to
>    terminology.
>    - *Pat* to detail regulatory limits about slotted aloha on ML.
>
> Agenda
>
>    - Administrivia *[10min]*
>       - Approval agenda
>       - Approval minutes last call
>       - plugfest: date
>       - architecture draft issues:
>          - http://trac.tools.ietf.org/wg/6tisch/trac/ticket/7
>          - http://trac.tools.ietf.org/wg/6tisch/trac/ticket/8
>          - http://trac.tools.ietf.org/wg/6tisch/trac/ticket/9
>       - reviewers needed for draft-piro-6tisch-security-issues
>    - Terminology *[15min]*
>    - updates minimal draft *[15min]*
>       - overview bitbucket changes
>       - requirements
>    - EB control bits proposal *[15min]*
>
> Minutes
>
>    - *[08:04]* Meeting starts
>    - *[08:04]* Administrivia
>       - Approval agenda
>
>       No issues raised. Agenda approved.
>
>       - Approval minutes last call
>
>       No issues raised. Minutes approved.
>
>       - plugfest: date
>          - plugfest
>             - conflict with registration
>             - possible problem with rooms available and insurances
>
>             Action item: *chairs* to contact IETF to ask if it is
>             possible to do the plugfest on Sunday.
>
>             - *[Xavi]* Need to present tools and techno and we can learn
>             from everyone
>             - *[Thomas]* need a clear set of goals, something more
>             constructive, show outcomes, working demo.
>             - *[Xavi]* for 6TiSCH last time objectives apply again
>          - architecture draft issues:
>          - *[Pascal]* use tickets and resolution mechanism
>
>          Action item: *[Xavi]* and *[Thomas]* to look at issue 7 of
>          minimal draft
>
>          - Issue 9 is a clarification.
>          - http://trac.tools.ietf.org/wg/6tisch/trac/ticket/7
>
>          In section 7.2, I might read that broadcast DIO and DAO are not
>          contained in ICMPv6 messages In section 7.2, I might read that broadcast
>          DIO and DAO are not contained in ICMPv6 messages, but rather that the
>          payload is put into a "Data Packet" without an IPv6 header and ICMPv6
>          header. Is that intended? [PT] There is an ICMP header; let me reword that.
>          What about: " To broadcast ICMPv6 control messages used by RPL such as DIO
>          or DAO, 6top uses the payload of a Data frames. The message is inserted
>          into the queue associated with the cells which LinkType? is set to
>          ADVERTISING. Then, taking advantage of the broadcast cell feature
>          established with FrameAndLinkIE (as described above), the RPL control
>          message can be received by neighbors, which enables the maintenance of RPL
>          DODAGs. " yes, works for me.
>
>          - http://trac.tools.ietf.org/wg/6tisch/trac/ticket/8
>
>          section 7.5 seems jumbled... maybe just not done yet. [PT] Yes,
>          we need to raise an issue on this
>
>          - http://trac.tools.ietf.org/wg/6tisch/trac/ticket/9
>
>          Clarify that a TSCH Schedule is a *set* of 2D matrices Please
>          clarify that a TSCH Schedule is a *set* of 2D matrices. Each
>          matrices is [slotOffset,channelOffset] sized slotframe, and determines how
>          a particular node assigns the chunks. [PT] Yes, there can be multiple
>          matrices formatted globally in chunks that are later appropriated by devices
>
>          - reviewers needed for draft-piro-6tisch-security-issues
>          - *[Michael]* draft-piro explains what 15.4 proposes for
>          security, good stuff there. Goes on to add command frames for P2P key
>          management. On that part, we need to decide what we do but grain of salt.
>          Missing how join a new network.
>          - *[Pascal]* can part of this draft be included in the tsch
>          draft as a solution review?
>          - *[Michael]* The draft is a solution document. Having the draft
>          it is interesting as it contains information that is relevant and very
>          descriptive.
>
>          Action item: *Pascal* to send an email to the ML with the
>          proposal of adding part of draft-piro to the draft-tsch.
>
>          - *[08:30]* Terminology
>       - *[Patrick]* on terminology: would be great to keep or enhance the
>       definition
>       - *[Maria Rita]* good suggestion, try to have the same meaning with
>       maybe a richer explanation
>       - *[Patrick]* ok. examples are timeslot schedule link linktype.
>
>       Action item: *Thomas* to review/clean use of terminology in
>       draft-tsch
>
>       - *[Pascal]* link must be defined the IETF way so we can explain
>       - *[Patrick]* terminology should be in one document, right now
>       there are multiple definitions e.g. draft-tsch Annex A
>       - *[Thomas]* could you send a list of what you found?
>       - *[Patrick]* yes will send remarks through email
>
>       Action item: *Patrick* to send remarks by e-mail to ML.
>
>       - *[Patrick]* cell vs. timeslots is unclear. e.g. a track is a
>       suite of cell not timeslots
>       - *[Patrick]* in terminology it says that the broadcast cell has a
>       mac address. Cell is referencing a slotframe handle
>
>       Action item: *Pascal* to propose an ad-hoc meeting next Friday
>       dedicated to terminology.
>
>       - *[08:44]* minimal draft
>       - *[Thomas]* going though the questions in the scope draft
>       - *[Thomas]* Can we agree that, when ONLY minimal is running:
>          - all nodes in the network have the same schedule
>          - the schedule never changes
>       - *[Pat]* shouldn't the schedule change when new nodes are admitted
>       - *[Xavi]* running minimal does not prevent other mechanisms on top
>       - *[Kris]* not here we're just doing slotted aloha
>       - *[Pat]* maybe regulatory issues with slotted aloha, let us
>       discuss on the reflector
>
>       Action item: *Pat* to detail regulatory limits about slotted aloha
>       on ML.
>
>       - *[Kris]* DAGroot to be able to set the links in the EB. The only
>       think that changes the slotframe length.
>       - *[??]* what happen if there are potentially 2 DAGroots?
>       - *[Kris]* if this is the case then 2 networks will be form
>       - *[Kris]* The simplest thing is to put TXRX slots in the beginning
>       of the slotframe. You have a variable length of the slotframe.
>       - *[Kris]* slotframe provides a trade-off between bandwidth and
>       energy consumption. That is what determines how the network behaves.
>       - *[Thomas]* do we prevent the EB to use frame and link IE and keep
>       that minimal pre-configured slotframe?
>       - *[Kris]* We need to be compliant to IEEE802.15.4e.
>       - *[Thomas]* So must be there which implies that hardcoded minimal
>       is not useful.
>       - *[Kris]* Maybe we could poll the WG about whether they have the
>       minimal schedule hardcoded in their implementation.
>       - *[Michael]* In the EB, is there a flag that says to turn on/off
>       minimal, or is the schedule described in the EB.
>       - *[Thomas]* The latter.
>       - *[Michael]* In general, it's better to think about what the
>       receiver does when receiving something it doesn't understand, rather than
>       focusing on what the transmitter is allowed to do.
>    - EB control bits proposal
>
>    No time.
>
>    - *[09.14]* Meeting ends
>
>
>