Re: [6tsch] minutes webex 5 July 2013

[Thomas Watteyne <[e-mail]>]

Maria Rita,

Thank you for the quick reply, and offering to cover 1.a, and maybe 1.d.

As for the pre-meeting, I agree, let's wrap up the date ASAP, certainly by
this week's call.

Finally, let me send a final call for the rename of 6tus to TOP to the ML.

Hello from the Paris airport,
Thomas



On Tue, Jul 9, 2013 at 9:59 AM, Maria Rita PALATTELLA <
[e-mail]> wrote:

>  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 J 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] ****
>
>     1. what is IEEE802.15.4e TSCH? (a key to deterministism and
>       scalability)    10mn****
>       2. what is missing? (mostly the cement as opposed to the building
>       blocks)  15mn****
>       3. Why is this a problem? (multiple proprietary solutions, costly,
>       limited scope) 3mn****
>       4. Status of 6TSCH group  (drafts, ML audience, calls, tracking
>       with BB …)  2mn ****
>
>   ****
>
>    1. discussion of the charter [30min] ****
>
>
>     1. background and introduction (existing work demonstrates
>       feasibility) 5mn****
>       2. description of WG (we have participants skilled in the
>       art)                   5mn****
>       3. work items (we reuse as much as we can from existing IETF
>       work)    10mn****
>       4. non-milestone work items (we demonstrate our will to coexist
>       within regulations) 2mn****
>       5. 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:* [e-mail] [mailto:[e-mail]] *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 <
> [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/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****
>
> ** **
>
> _______________________________________________
> 6tsch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6tsch
>
>