Re: [6tsch] minutes webex 5 July 2013

Maria Rita PALATTELLA <maria-rita.palattella@uni.lu> Tue, 09 July 2013 07:59 UTC

Return-Path: <maria-rita.palattella@uni.lu>
X-Original-To: 6tsch@ietfa.amsl.com
Delivered-To: 6tsch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2D821F9F8F for <6tsch@ietfa.amsl.com>; Tue, 9 Jul 2013 00:59:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HLu88vGEZWUS for <6tsch@ietfa.amsl.com>; Tue, 9 Jul 2013 00:59:20 -0700 (PDT)
Received: from hercules.uni.lu (hercules.uni.lu [158.64.76.33]) by ietfa.amsl.com (Postfix) with ESMTP id CE32F21F9DB6 for <6tsch@ietf.org>; Tue, 9 Jul 2013 00:59:18 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="4.87,1026,1363129200"; d="scan'208,217"; a="25295820"
Received: from unknown (HELO REED.uni.lux) ([10.21.2.9]) by hercules.uni.lu with ESMTP; 09 Jul 2013 09:59:18 +0200
Received: from HOSHI.uni.lux ([fe80::499:a33:4e68:4af9]) by REED.uni.lux ([fe80::31bb:b7a3:7abb:813e%10]) with mapi id 14.03.0123.003; Tue, 9 Jul 2013 09:59:16 +0200
From: Maria Rita PALATTELLA <maria-rita.palattella@uni.lu>
To: Thomas Watteyne <watteyne@eecs.berkeley.edu>, "Pascal Thubert (pthubert) (pthubert@cisco.com)" <pthubert@cisco.com>
Thread-Topic: [6tsch] minutes webex 5 July 2013
Thread-Index: AQHOeatlLaVgQYse00GRwTRosM4e7JlZ680AgAIPF8A=
Date: Tue, 09 Jul 2013 07:59:15 +0000
Message-ID: <F085911F642A6847987ADA23E611780D18589011@hoshi.uni.lux>
References: <CADJ9OA-gPTxMnX1SGsJj_xBsHVVKcqLTD7JUCBSxBqqt3UQ5NA@mail.gmail.com> <CADJ9OA8Xa82jtPS+D5xiaOcodb3iRgBe_yQWXH2kA7dV8KmE7Q@mail.gmail.com>
In-Reply-To: <CADJ9OA8Xa82jtPS+D5xiaOcodb3iRgBe_yQWXH2kA7dV8KmE7Q@mail.gmail.com>
Accept-Language: en-US, en-GB
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.91.0.80]
Content-Type: multipart/alternative; boundary="_000_F085911F642A6847987ADA23E611780D18589011hoshiunilux_"
MIME-Version: 1.0
Cc: "6tsch@ietf.org" <6tsch@ietf.org>
Subject: Re: [6tsch] minutes webex 5 July 2013
X-BeenThere: 6tsch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tsch>, <mailto:6tsch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6tsch>
List-Post: <mailto:6tsch@ietf.org>
List-Help: <mailto:6tsch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tsch>, <mailto:6tsch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Jul 2013 07:59:21 -0000

Thomas,  thanks as usual for the minutes. Having missed the call, it allowed me to keep tuned ;)

I have some comments/questions about the BoF in Berlin, in details about  the following points of the last call:
*        >>It would be good if Maria Rita, Xavi, Qin, could present.
*        [MR] I will be glad to present, if you think I am the right one :) According to the suggested agenda (copied below), for sure I could take care of 1.a (and provide an overview of 15.4e TSCH) - and 1.d (if needed).
*        Does this work for you?
****************************************************
1.      problem statement [30min]

     *   what is IEEE802.15.4e TSCH? (a key to deterministism and scalability)    10mn
     *   what is missing? (mostly the cement as opposed to the building blocks)  15mn
     *   Why is this a problem? (multiple proprietary solutions, costly, limited scope) 3mn
     *   Status of 6TSCH group  (drafts, ML audience, calls, tracking with BB ...)  2mn


  1.  discussion of the charter [30min]

     *   background and introduction (existing work demonstrates feasibility) 5mn
     *   description of WG (we have participants skilled in the art)                   5mn
     *   work items (we reuse as much as we can from existing IETF work)    10mn
     *   non-milestone work items (we demonstrate our will to coexist within regulations) 2mn
     *   external work to other WG (6MAN, PCE, ROLL?)  3mn
*        ******************************************************************************
*        >> have a pre-meeting in Berlin, probably Monday afternoon or Tuesday morning.
*        [MR] It will be great if we can  fix ASAP when we want to meet because I  want to make sure I am around when needed. I am planning a 2-days trip (29-30 July).  Unfortunately I cannot stay in Berlin for the whole week.
*        >>Rename 6tus. To 6top? We can have a quick call on the ML 6top seems to be good. We need to do this ASAP.
*        [MR] we need to agree on the name ASAP, because I will have to update also the terminology draft, before publishing the new version.
*
*        Thank you!
*        Maria Rita


From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of Thomas Watteyne
Sent: Monday, July 08, 2013 4:11 AM
To: 6TSCH
Subject: Re: [6tsch] minutes webex 5 July 2013

All,

Please find below an updated version of the minutes of last meeting. Changes are highlighted in blue. Thanks Rene for spotting this!

This new version replaces the previous one, and is also the one archived at https://bitbucket.org/6tsch/meetings/wiki/130705_webex.

Thomas

---

Minutes Webex 05 July 2013, 6TSCH group

Note: timestamps in PDT.

Taking notes (using Etherpad)
1.     Xavi Vilajosana
2.     Thomas Watteyne
Present (alphabetically)
1.     Alfredo Grieco
2.     Guillaume Gaillard
3.     Pascal Thubert
4.     Pouria Zand
5.     Rafa Marin-Lopez
6.     Raghuram Sudhaakar
7.     Rene Struik
8.     Subir Da
9.     Thomas Watteyne
10.  Tina Tsou
11.  Xavi Vilajosana
12.  Yoshihiro Ohba
Recording
*        Webex recording (audio+slides,streaming)
*        https://cisco.webex.com/ciscosales/lsr.php?AT=pb&amp;SP=MC&amp;rID=69696887&amp;rKey=5ee52e950ccc11e9<https://cisco.webex.com/ciscosales/lsr.php?AT=pb&SP=MC&rID=69696887&rKey=5ee52e950ccc11e9> [57min]
Slides
*        slides_130705_webex.ppt<https://bitbucket.org/6tsch/meetings/src/ceaae60071b8d2b0890c629a9fdae867c1f37391/130705_webex/slides_130705_webex.ppt?at=master>: slides shared during the call
Agenda
*        Approval minutes last call [1min]
*        Update presentation esIoT [1min]
*        draft-ohba-6tsch-security-00 [10min]
*        Simulator [10min]
*        Description of PCE [10min]
*        Preparing for the BOF [25min]
*        Re-organization Bitbucket [2min]
*        AOB [1min]
Minutes
*        [08.05] Meeting starts
*        Thomas goes over the agenda.
*        Very full agenda today.
*        [08.08] Approval minutes last call
*        Thomas asks for approval last week's minutes

no major comments. Agenda approved.
*        [08.08] Update presentation esIoT
*        Maria Rita where she presented a paper on 6TSCH at http://www.esiot.com/ in Taiwan on 07/04/2013.
*        Thomas attended through Skype.
*        Maria Rita gave an excellent overview of what 6STCH is doing.
*        Her slides are very good, can be used as a basis for further presentations.
*        [08.10] draft-ohba-6tsch-security-00
*        Yoshihiro presents http://tools.ietf.org/html/draft-ohba-6tsch-security-00.

This is the official presentation of the draft.
*        draft submitted 06/24/2013.
*        Background:
*        ZigBee IP CSMA/CA MAC, has a common network key shared by all nodes in the mesh.
*        TSCH uses a 5-byte ASN counter as part of the CCM* nonce.
*        This draft provides a solution for key management in 6TSCH networks
*        Key Management Framework. 3 Phase currently described in the draft, suggestion to add Phase 0:
*        P0: Commisioning. What to put in a node before deployment?
*        P1: Boostrap. Starts when device is at its final location. (Re)installs credentials used for P2 and P3. Possibly no link layer security with the neighbor node. Authentication server used by each mote. Can be multiple hops away. installs credentials for P2 or P3.
*        P2: Link establishment. Neighbor nodes do two-party authentication and key establishement. No need to contact autentication server.
*        P3: After we study the application layer requirements, we can add more information.
*        Presents example sequence on slide
*        dashed arrows show phase 1. Node 0 is Auth Server.
*        solid arrows show P2 and P3.
*        P1 and P2 KMP requirements. depending on feedback and discussion, we can revise
*        P1 requirements:
*        suport mutual authentication
*        suport stateless authentication
*        secure credential distribution
*        P2 requirements:
*        8 requirements.
*        Yoshihiro presents slide on P2 example phase with certificates
*        each node exchanges its CCM* key
*        candidate KMPs:
*        for P1: PANA, because of several issues presented later
*        for P2: several options
*        assymetric key credentials are used.
*        PANA overview
*        Protocol for Carrying Authentication for Network Access (PANA)
*        http://tools.ietf.org/html/rfc5191
*        Extensible Authentication Protocol(EAP) over UDP
*        two extensions:
*        in ZIP, relay element in defined
*        http://tools.ietf.org/html/rfc6345
*        http://tools.ietf.org/html/rfc6786
*        PANA stateless relay operation.
*        joining node is PaC (PANA Client)
*        parent node is PRE (PANA Relay Element)
*        PANA relay message contains joining node's IP and port, allow stateless relaying of PANA message
*        recent discussion on ML:
*        EB protection
*        Need to be protected to not have attacks by forging EBs.
*        several candidate solutions.
*        multiple profiles:
*        There was a comment that solution might be too heavyweight for very constrained devices. Do we need profiles?
*        Profile A: what we have now in the draft
*        Profile B: common CCM* key. In this case, no device can be compromised. If a node is compromised, all of the keys need to be updated. Only applicable for small sized networks.
*        discussion
*        [Pascal] how are profiles used in ISA100?
*        [Rene] Not sure if remember (must check). Think asymetric and symetric keying in two separate profiles.
*        [Pascal] We want to have a superset of ISA100 does.
*        [Rene] It is important to think about the long-term requirements. We can imagine a case where only one profile is used. Not sure if realistic with the 8kB RAM requirements.
*        [Subir] Suggesting removethe 8kB requirements?
*        [Rene] We have to anticipate use cases on very large network. RAM requirements not that high for crypto. We need to look at the system cost as a whole. Flexibility of deployment might decrease if you require multiple device profiles, where less expensive devices may result in higher deployment cost (e.g., due to human involvement) and, thereby, higher system cost. Not a purely technical discussion.
*        [08.35] Simulator
*        Xavi shares his screen and presents simulator.
*        Open-source, hosted at https://bitbucket.org/6tsch/simulator
*        Added possibility for motes to re-allocate cells when collisions are detected.
*        Shows case with a 50 fully-meshed node network (i.e. neighborhood) with a random number of cells scheduled between motes. Detection is done by selecting bad cell in a bundle, and choose another cell randomly.
*        Network converges rather slowly now, but can be tuned by threshold to detect collision.
*        Measurements we can now make: how long before the schedule is collision-free? How many time we change one cell?
*        The simulator allows you to see the number of collisions for a cell.
*        Implemented different topologies, to study more realistic networks.
*        next step: want do we want to measure with this simulator?
*        discussion
*        [Pascal] we should start multiple thread on the ML. In particular one to discuss the algorithm for a node to detect that there are collision in a cell.
*        [Pascal] Interesting use case: if there are two independent 6TSCH networks in the same radio space, de-synchronized by 5ms, their cells will overlap, causing lots of schedule changes.
*        [Xavi] You're very welcome to play with the simulator and implement more features. Ticketting system (https://bitbucket.org/6tsch/simulator/issues) used to track features to be implemented
*        [Pascal] It would be nice to have a HOWTO
*        [Xavi] Code is commented. Will work on a README.
*        [08.45] Description of PCE

This point will not be addressed during this call.
*        [08.45] Preparing for the BOF
*        Thomas presents 4 slides on http://tools.ietf.org/html/rfc5434
*        Goals of the BOF.
*        demonstrate that we have an agreement on the five points:
*        there is a problem that needs solving
*        IETF is the right place to solve it
*        we have a critical mass of people who can work on it
*        scope is well defined and understood
*        WG has a reasonable probability of having success *Preparing:
*        identify areas of agreement and disagreement
*        come up with consensus charter *Problem statement:
*        we need to go back to the charter. We have to be able to explain the problem.
*        the only goal is to show there is a problem and how we can solved
*        At the BOF
*        Agenda of the BOF has to focus on defending the need of the WG.
*        Present the problem to the public.
*        Audience needs to be convinced. We should not ask too many questions.
*        Avoid discussions about solution.
*        Avoid having too long presentation about solutions.
*        Proposed agenda (we have 1h30)
*        problem statement [30min]
*        what IEEE802.15.4e TSCH?
*        what is missing
*        quick overview of the status of the group
*        charter [30min]
*        we can follow the structure of the charter
*        [Pascal] we need to convince people that there is something that needs to be done. Convince that it can be done. show that this is a problem we can solve in a limited time.
*        drafts
*        idea is to show the activity of the group, not to discuss technical options.
*        TODO list before the BOF:
*        Ask on the ML who will be in Berlin.
*        Agree on ML who is going to talk about what during the BOF.
*        We will be looking for volunteers.
*        It would be good if Maria Rita, Xavi, Qin, could present.
*        Rehearsal at the call next week.
*        have a pre-meeting in Berlin, probably Monday afternoon or Tuesday morning.
*        quick doodle poll for meeting before meeting
*        Rename 6tus.
*        To 6top? We can have a quick call on the ML 6top seems to be good.
*        We need to do this ASAP.
*        JP Vasseur accepted to help on PCE.
*        [09.02] Re-organization Bitbucket
*        merge Orlando repo inside the meetings repo so meetings will end up being webex + ietf meetings.
*        prepare skeleton for berlin meeting.
*        Discussion:
*        [Thomas] Updated "About 6tsch" section of https://www.ietf.org/mailman/listinfo/6tsch to contain link to bitbucket?
*        [Pascal] A month from now we will have a working group page so maybe it is not needed.
*        [09.05] AOB

No additional issues raised.
*        [09.06] Meeting ends

On Fri, Jul 5, 2013 at 11:13 AM, Thomas Watteyne <watteyne@eecs.berkeley.edu<mailto:watteyne@eecs.berkeley.edu>> wrote:
All,

You will find the minutes of the last webex below.

FYI, all the minutes and slides are archived a https://bitbucket.org/6tsch/meetings/.

Thanks to Xavi for taking notes!

As usual, fix anything we might have missed directly in the e-mail and reply.

Thomas

---

Minutes Webex 05 July 2013, 6TSCH group

Note: timestamps in PDT.

Taking notes (using Etherpad)
1.     Xavi Vilajosana
2.     Thomas Watteyne
Present (alphabetically)
1.     Alfredo Grieco
2.     Guillaume Gaillard
3.     Pascal Thubert
4.     Pouria Zand
5.     Rafa Marin-Lopez
6.     Raghuram Sudhaakar
7.     Rene Struik
8.     Subir Da
9.     Thomas Watteyne
10.  Tina Tsou
11.  Xavi Vilajosana
12.  Yoshihiro Ohba
Recording
*        Webex recording (audio+slides,streaming)
*        https://cisco.webex.com/ciscosales/lsr.php?AT=pb&amp;SP=MC&amp;rID=69696887&amp;rKey=5ee52e950ccc11e9<https://cisco.webex.com/ciscosales/lsr.php?AT=pb&SP=MC&rID=69696887&rKey=5ee52e950ccc11e9> [57min]
Slides
*        slides_130705_webex.ppt<https://bitbucket.org/6tsch/meetings/src/ceaae60071b8d2b0890c629a9fdae867c1f37391/130705_webex/slides_130705_webex.ppt?at=master>: slides shared during the call
Agenda
*        Approval minutes last call [1min]
*        Update presentation esIoT [1min]
*        draft-ohba-6tsch-security-00 [10min]
*        Simulator [10min]
*        Description of PCE [10min]
*        Preparing for the BOF [25min]
*        Re-organization Bitbucket [2min]
*        AOB [1min]
Minutes
*        [08.05] Meeting starts
*        Thomas goes over the agenda.
*        Very full agenda today.
*        [08.08] Approval minutes last call
*        Thomas asks for approval last week's minutes

no major comments. Agenda approved.
*        [08.08] Update presentation esIoT
*        Maria Rita where she presented a paper on 6TSCH at http://www.esiot.com/ in Taiwan on 07/04/2013.
*        Thomas attended through Skype.
*        Maria Rita gave an excellent overview of what 6STCH is doing.
*        Her slides are very good, can be used as a basis for further presentations.
*        [08.10] draft-ohba-6tsch-security-00
*        Yoshihiro presents http://tools.ietf.org/html/draft-ohba-6tsch-security-00.

This is the official presentation of the draft.
*        draft submitted 06/24/2013.
*        Background:
*        ZigBee IP CSMA/CA MAC, has a common network key shared by all nodes in the mesh.
*        TSCH uses a 5-byte ASN counter as part of the CCM* nonce.
*        This draft provides a solution for key management in 6TSCH networks
*        Key Management Framework. 3 Phase currently described in the draft, suggestion to add Phase 0:
*        P0: Commisioning. What to put in a node before deployment?
*        P1: Boostrap. Starts when device is at its final location. (Re)installs credentials used for P2 and P3. Possibly no link layer security with the neighbor node. Authentication server used by each mote. Can be multiple hops away. installs credentials for P2 or P3.
*        P2: Link establishment. Neighbor nodes do two-party authentication and key establishement. No need to contact autentication server.
*        P3: After we study the application layer requirements, we can add more information.
*        Presents example sequence on slide
*        dashed arrows show phase 1. Node 0 is Auth Server.
*        solid arrows show P2 and P3.
*        P1 and P2 KMP requirements. depending on feedback and discussion, we can revise
*        P1 requirements:
*        suport mutual authentication
*        suport stateless authentication
*        secure credential distribution
*        P2 requirements:
*        8 requirements.
*        Yoshihiro presents slide on P2 example phase with certificates
*        each node exchanges its CCM* key
*        candidate KMPs:
*        for P1: PANA, because of several issues presented later
*        for P2: several options
*        assymetric key credentials are used.
*        PANA overview
*        Protocol for Carrying Authentication for Network Access (PANA)
*        http://tools.ietf.org/html/rfc5191
*        Extensible Authentication Protocol(EAP) over UDP
*        two extensions:
*        in ZIP, relay element in defined
*        http://tools.ietf.org/html/rfc6345
*        http://tools.ietf.org/html/rfc6786
*        PANA stateless relay operation.
*        joining node is PaC (PANA Client)
*        parent node is PRE (PANA Relay Element)
*        PANA relay message contains joining node's IP and port, allow stateless relaying of PANA message
*        recent discussion on ML:
*        EB protection
*        Need to be protected to not have attacks by forging EBs.
*        several candidate solutions.
*        multiple profiles:
*        There was a comment that solution might be too heavyweight for very constrained devices. Do we need profiles?
*        Profile A: what we have now in the draft
*        Profile B: common CCM* key. In this case, no device can be compromised. If a node is compromised, all of the keys need to be updated. Only applicable for small sized networks.
*        discussion
*        [Pascal] how are profiles used in ISA100?
*        [Rene] Not sure if remember (must check). Think asymetric and symetric keying in two separate profiles.
*        [Pascal] We want to have a superset of ISA100 does.
*        [Rene] It is important to think about the long-term requirements. We can imagine a case where only one profile is used. Not sure if realistic with the 8kB RAM requirements.
*        [Subir] Suggesting removethe 8kB requirements?
*        [Rene] We have to anticipate use cases on very large network. RAM requirements not that high for crypto. We need to lookg at the system cost as a whole. Flexibility of deployment might decrease if you require more expensive devices due to more strict requirements.. Not a purely technical discussion.
*        [08.35] Simulator
*        Xavi shares his screen and presents simulator.
*        Open-source, hosted at https://bitbucket.org/6tsch/simulator
*        Added possibility for motes to re-allocate cells when collisions are detected.
*        Shows case with a 50 fully-meshed node network (i.e. neighborhood) with a random number of cells scheduled between motes. Detection is done by selecting bad cell in a bundle, and choose another cell randomly.
*        Network converges rather slowly now, but can be tuned by threshold to detect collision.
*        Measurements we can now make: how long before the schedule is collision-free? How many time we change one cell?
*        The simulator allows you to see the number of collisions for a cell.
*        Implemented different topologies, to study more realistic networks.
*        next step: want do we want to measure with this simulator?
*        discussion
*        [Pascal] we should start multiple thread on the ML. In particular one to discuss the algorithm for a node to detect that there are collision in a cell.
*        [Pascal] Interesting use case: if there are two independent 6TSCH networks in the same radio space, de-synchronized by 5ms, their cells will overlap, causing lots of schedule changes.
*        [Xavi] You're very welcome to play with the simulator and implement more features. Ticketting system (https://bitbucket.org/6tsch/simulator/issues) used to track features to be implemented
*        [Pascal] It would be nice to have a HOWTO
*        [Xavi] Code is commented. Will work on a README.
*        [08.45] Description of PCE

This point will not be addressed during this call.
*        [08.45] Preparing for the BOF
*        Thomas presents 4 slides on http://tools.ietf.org/html/rfc5434
*        Goals of the BOF.
*        demonstrate that we have an agreement on the five points:
*        there is a problem that needs solving
*        IETF is the right place to solve it
*        we have a critical mass of people who can work on it
*        scope is well defined and understood
*        WG has a reasonable probability of having success *Preparing:
*        identify areas of agreement and disagreement
*        come up with consensus charter *Problem statement:
*        we need to go back to the charter. We have to be able to explain the problem.
*        the only goal is to show there is a problem and how we can solved
*        At the BOF
*        Agenda of the BOF has to focus on defending the need of the WG.
*        Present the problem to the public.
*        Audience needs to be convinced. We should not ask too many questions.
*        Avoid discussions about solution.
*        Avoid having too long presentation about solutions.
*        Proposed agenda (we have 1h30)
*        problem statement [30min]
*        what IEEE802.15.4e TSCH?
*        what is missing
*        quick overview of the status of the group
*        charter [30min]
*        we can follow the structure of the charter
*        [Pascal] we need to convince people that there is something that needs to be done. Convince that it can be done. show that this is a problem we can solve in a limited time.
*        drafts
*        idea is to show the activity of the group, not to discuss technical options.
*        TODO list before the BOF:
*        Ask on the ML who will be in Berlin.
*        Agree on ML who is going to talk about what during the BOF.
*        We will be looking for volunteers.
*        It would be good if Maria Rita, Xavi, Qin, could present.
*        Rehearsal at the call next week.
*        have a pre-meeting in Berlin, probably Monday afternoon or Tuesday morning.
*        quick doodle poll for meeting before meeting
*        Rename 6tus.
*        To 6top? We can have a quick call on the ML 6top seems to be good.
*        We need to do this ASAP.
*        JP Vasseur accepted to help on PCE.
*        [09.02] Re-organization Bitbucket
*        merge Orlando repo inside the meetings repo so meetings will end up being webex + ietf meetings.
*        prepare skeleton for berlin meeting.
*        Discussion:
*        [Thomas] Updated "About 6tsch" section of https://www.ietf.org/mailman/listinfo/6tsch to contain link to bitbucket?
*        [Pascal] A month from now we will have a working group page so maybe it is not needed.
*        [09.05] AOB

No additional issues raised.
*        [09.06] Meeting ends