Subject: [6tsch] updated charter per BoF suggestion: thoughts?

From: Thomas Watteyne <[email-masked]>
Date: Thu, 1 Aug 2013 15:12:45 +0200

All,

Thanks to all for for the effort of putting together the BoF on Tuesday!
One of the suggestions was to simplify the charter, in particular by
reducing the number of work items.

After discussion and suggestions from numerous 6TSCH and other people here
at the IETF, the chairs have created a new, simplified version of the
draft, which we have uploaded in the repo at:
https://bitbucket.org/6tsch/charter-ietf-6tsch/src/master/charter-ietf-6tsch-00.txt

This e-mail is to start a discussion on the ML about this revamped charter.
Please send comments directly to this thread. Ideally, we would like to
converge within a couple of days, so let's start the discussion right now.

Pascal & Thomas

---

From: Alfredo Grieco <[email-masked]>
Date: Thu, 1 Aug 2013 16:58:09 +0200

Hi all,

Like very much this new charter: it is now much more clear what the WG is
going to do.

Thanks a lot for having reworked it.

Cheers

Al

On Thursday, August 1, 2013, Thomas Watteyne wrote:

> This e-mail is to start a discussion on the ML about this revamped
> charter. Please send comments directly to this thread. Ideally, we would
> like to converge within a couple of days, so let's start the discussion
> right now.
>
> Pascal & Thomas
>

---

From: Emmanuel Baccelli <[email-masked]>
Date: Thu, 1 Aug 2013 17:40:26 +0200

Hi Thomas, Hi Pascal,

thanks for the revamped charter. The timeline is explicit and the scope is
now much more focused, while not blocking the horizon for non-yet-chartered
work awaiting us next, down the line. So it looks good to me.

This is just my personal opinion, and I don't know if this is the right
place/time to say this, but I also wanted to mention that I don't see a
real need for a second BOF if there's a consensus on a revamped charter
proposal.

Best,
Emmanuel

On Thu, Aug 1, 2013 at 4:31 PM, Thomas Watteyne
<[email-masked]>wrote:

> _______________________________________________
> 6tsch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tsch
>
>

---

From: <[email-masked]>
Date: Thu, 1 Aug 2013 17:01:51 +0000

Woww, now this is very focused. This should give us a clear framework to start our work, and hopefully expand later.
Overall, I believe the current Work Items description could elaborate a bit more.
Specifically, please find below my questions, followed by other minor remarks/suggested changes.

Dominique

---------

Questions
« Produce "Timeslot Management Methods and Formats" to describe how an entity can manage the TSCH schedule on a 6TSCH node". The schedule is somewhere described as being static. In this sentence, the schedule can be "managed" by an "entity". What prevents the so-called entity to "manage" the schedule, i.e. allocate slots, based on some information such as traffic requirements? In which case, what does "static" mean? Probably "imposed upon the 6top layer" (if such notion still exists) by some external mechanism.

"or learnt by a node when joining the network, possibly in a format as defined by work item 1."
Do you mean the description of the schedule would be provided "in-band" to the joining node (through EB's or similar mechanism). This does not seem to fit the description of work item 1, where the "entity" is an upper layer. Or do you mean as a payload transported on a default cell/link between upper layer entities ?

"3. Produce "6TSCH architecture" to describe the design and implementation of 6TSCH networks. This document will highlight the different architectural blocks and signaling flows, including the operation of the network in the presence of multiple BBRs."
Does this include any form of multi-hop ND? In light of the discussion at 6lo BoF on this topic, how will compare to 6lowpan-ND?

Sentences unclear to me
"A dynamic schedule for traffic that is switched at the timeslot level may for example be computed centrally by an entity located on the backbone."  This sentence is complex and unclear to me overall. Consider rephrasing?
"Produce "Timeslot Management Methods and Formats" to describe how an entity can manage the TSCH schedule on a 6TSCH node". Is it assumed that everybody knows what "entity" is supposed to mean in this context?

Minor changes
s/in front of interference/in front of narrow-band interference
s/- implementers guide, collecting/ - implementers guide: this document will collect/
s/- coexistence guide, providing/- coexistence guide: this document will provide/

English writing
s/and ISA100.11a, and/and ISA100.11a, while/
s/Initially the document/Initially, the document
s/be adapted dynamically/be dynamically adapted/

De : [email-masked] [mailto:[email-masked]] De la part de Thomas Watteyne
Envoyé : jeudi 1 août 2013 15:13
À : 6TSCH; Ted Lemon ([email-masked]); Adrian Farrel ([email-masked]); Marc Blanchet
Objet : [6tsch] updated charter per BoF suggestion: thoughts?

All,

Thanks to all for for the effort of putting together the BoF on Tuesday! One of the suggestions was to simplify the charter, in particular by reducing the number of work items.

After discussion and suggestions from numerous 6TSCH and other people here at the IETF, the chairs have created a new, simplified version of the draft, which we have uploaded in the repo at:
https://bitbucket.org/6tsch/charter-ietf-6tsch/src/master/charter-ietf-6tsch-00.txt

This e-mail is to start a discussion on the ML about this revamped charter. Please send comments directly to this thread. Ideally, we would like to converge within a couple of days, so let's start the discussion right now.

Pascal & Thomas

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 1 Aug 2013 19:16:52 +0000

On Aug 1, 2013, at 5:40 PM, Emmanuel Baccelli <[email-masked]> wrote:
> This is just my personal opinion, and I don't know if this is the right place/time to say this, but I also wanted to mention that I don't see a real need for a second BOF if there's a consensus on a revamped charter proposal.

If you guys can agree on a charter before the next IETF, it is clear to me that there is support in the IETF for doing this work, and energy in the working group for doing it, so I will be happy to put forward the charter as a proposed working group.   You could also ask Brian Haberman, since there's a decent chance he will wind up as responsible AD if a working group is formed.   AFAIK either way is fine.

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Thu, 1 Aug 2013 19:23:24 +0000

Pascal, Thomas,

Many thanks for this new version of the charter. It is pretty much simplified, and at the same time it still keeps all the key work-items that we have been targeting so far. Well done!

I have few minor comments:

1)      The first sentence sound a bit strange:

"The Working Group will focus on enabling IPv6 over the TSCH mode of the IEEE802.15.4e standard. The scope of the WG includes one or more LLNs, each one

connected to a backbone through one or more BackBone Routers (BBRs)."

What about this slightly different version:
        "The Working Group will focus on enabling IPv6 over IEEE802.15.4e TSCH networks, including one or more LLNs, each one
        connected to a backbone through one or more BackBone Routers (BBRs)."

2)      Why in "Description of Working Group" session and  "Work Items" session, we talk in term of timeslot, instead of cells? A single element of the schedule is actually a cell, given by (timeslot offset, channeloffset)?

Maria Rita

From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Watteyne
Sent: Thursday, August 01, 2013 3:13 PM
To: 6TSCH; Ted Lemon ([email-masked]); Adrian Farrel ([email-masked]); Marc Blanchet
Subject: [6tsch] updated charter per BoF suggestion: thoughts?

All,

Pascal & Thomas

---

From: Qin Wang <[email-masked]>
Date: Fri, 2 Aug 2013 04:05:43 +0800

Hi all,

Regarding to the first work item:

************************************************************

1. Produce "Timeslot Management Methods and Formats" to describe how an
entity can manage the TSCH schedule on a 6TSCH node, and query timeslot
information from that node. Metrics such as timeslot quality reports are in
scope, but the actual bindings to transport operation are not.

***********************************************************

My suggestion and comment is as follows.

(1) Name: "Multichannel Timeslot Management Methods and Messages". The
reason for the modification is:

     a) not only "TS" but also "CH" have to be managed;

     b) "Messages" includes both exchange time sequence and format, which
need to be described.

(2) replace "timeslot" in the paragraph with "multichannel timeslots"

(3) It is not clear where the entity is. Should we clarify?

Thanks

Qin

---

From: Qin Wang <[email-masked]>
Date: Fri, 2 Aug 2013 05:10:54 +0800

Hi Thomas, Pascal and All,

Regarding to the scope, i.e. "Description of Working Group", I would like
to clarify my understanding on "static schedule", and "dynamic schedule"
firstly.

Actually, there are two parameters related to establishing and maintaining
a TSCH schedule, one is about "who", which values are (centralized,
decentralized); another one is about change over time, which values are
(static, dynamic). In the current version of 6top, the two parameters are
associated with each other (but not have to), i.e. "centralized" is
associated with "static", because it is assumed that centralized can
optimize resource and avoid collision; and "decentralized" is associated
with "dynamic", because it is assumed collision can not avoided completely
by local negotiation.

The Charter says  "Initially, the WG will define a framework to install a
static schedule and

run the Routing Protocol for LLNs (RPL) over that schedule. If successful,
the intent is to recharter to allow for dynamic schedules......".
It means:
step-1: we define methods and messages for establishing TSCH schedule in
the way of (centralized, static);
step-2: we define  methods and messages for establishing TSCH schedule in
the way of (centralized, dynamic) and  (decentralized, dynamic) ;

Correct?

Based one above, how do you think the combination (decentralized, dynamic)?
For example, allow establishing schedule locally, but do not allow change,
or in another word, change must be instructed by upper layer, instead of by
the sublayer.

Thanks
Qin

---

From: Rafa Marin Lopez <[email-masked]>
Date: Thu, 1 Aug 2013 23:11:04 +0200

Dear Chairs:

Thanks for this new charter. Evidently, it is more condensed and simplified, which is good, taking into account the comments received during the BOF. 

I have also noticed that security part has been completely removed. Although my interest was specially based on that part, I understand that these aspects could be covered in the future, when the current work for this charter is finished.

Best Regards. 

> This e-mail is to start a discussion on the ML about this revamped charter. Please send comments directly to this thread. Ideally, we would like to converge within a couple of days, so let's start…

-------------------------------------------------------
Rafael Marin Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: [email-masked]
-------------------------------------------------------

---

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Thu, 1 Aug 2013 23:11:32 +0200

I accept the charter as it is stated on charter-ietf-6tsch-00.txt

Diego Dujovne

2013/8/1 Thomas Watteyne <[email-masked]>:
> All,
>
> Thanks to all for for the effort of putting together the BoF on Tuesday! One
> of the suggestions was to simplify the charter, in particular by reducing
> the number of work items.
>
> at the IETF, the chairs have created a new, simplified version of the draft,
> which we have uploaded in the repo at:

-- 
DIEGO DUJOVNE
Académico Escuela de Ingeniería en Informática y Telecomunicaciones
Facultad de Ingeniería UDP
www.ingenieria.udp.cl
(56 2) 676 8125

---

From: Xavier Vilajosana Guillen <[email-masked]>
Date: Fri, 2 Aug 2013 06:34:51 +0200

Great work. Nothing else to add! my vote on it!
X

On Thu, Aug 1, 2013 at 11:11 PM, Prof. Diego Dujovne <
[email-masked]> wrote:

> One
> charter.

---

From: Pieter De Mil <[email-masked]>
Date: Fri, 2 Aug 2013 06:48:27 +0200

Hi all,

I support the charter.

Do we have to add milestones?

Best,
Pieter

---

From: <[email-masked]>
Date: Fri, 2 Aug 2013 06:06:19 +0000

I agree on the revised charter.  This is really a reasonable set of works to focus in the next few F2F meeting cycles.

Yoshihiro Ohba

From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Watteyne
Sent: Thursday, August 01, 2013 10:13 PM
To: 6TSCH; Ted Lemon ([email-masked]); Adrian Farrel ([email-masked]); Marc Blanchet
Subject: [6tsch] updated charter per BoF suggestion: thoughts?

All,

Pascal & Thomas

---

From: "Raghuram Sudhaakar (rsudhaak)" <[email-masked]>
Date: Fri, 2 Aug 2013 06:10:29 +0000

Thomas, Pascal,
This looks very focussed now. I have a few things that we need to address -

  1.  The statement "Initially, the WG will define a framework to install a static schedule and run the Routing Protocol for LLNs (RPL) over that schedule" in the description of the working group and work item 1 seem to be in conflict. We say we will work on static schedules which means that L3 (RPL) can only query cell/link quality info from TSCH. Work item 1 explicitly states - "to describe how an entity can manage the TSCH schedule on a 6TSCH node". I feel it is better to remove this statement from the work item.
  2.  In this context, The current work item 1 could possibly be renamed to , "Query methods and formats for timeslot/cell parameters"??
  3.  Also, it may be better to flip the order of work items 1,2 (i.e) have "minimal 6TSCH config" as first work item and "Query methods and formats for timeslot/cell parameters" as work item 1 to reflect the statements made in the description of the working group.
  4.  I second the point about elaborating on "entity" in the current work item 1 raised by Dominique and Qin. We could say, "route management entity"?

We may also reword the second paragraph of Description of working group as follows -
Initially, the WG will define a framework to install a static schedule on a 6TSCH network and run the Routing Protocol for LLNs (RPL) over that schedule. We will also define methods for RPL to query parameters and states from the 6TSCH network.

In the third paragraph of the description of WG, this statement -

A dynamic schedule for traffic that is switched at the timeslot level may for example be computed centrally by an entity located on the backbone.

can be reworded as -

The TSCH schedule may be computed by a central entity located in the backbone (or co-located with the 6TSCH network gateway), with out without information from the routing protocol. (Im not sure we need to get into more detail here, since this is just the description of the WG).

IMO, this gives general flow like - 1) Get RPL working with TSCH using standardized formats. 2) Allow L3 to influence TSCH schedule to fully extract benefits of L3 features and capabilities.

-raghuram

From: <[email-masked]<mailto:[email-masked]>>
Date: Thursday, August 1, 2013 7:01 PM
To: Thomas Watteyne <[email-masked]<mailto:[email-masked]>>, 6TSCH <[email-masked]<mailto:[email-masked]>>
Subject: Re: [6tsch] updated charter per BoF suggestion: thoughts?

Dominique

---------

Questions
« Produce "Timeslot Management Methods and Formats" to describe how an entity can manage the TSCH schedule on a 6TSCH node”. The schedule is somewhere described as being static. In this sentence, the schedule can be “managed” by an “entity”. What prevents the so-called entity to “manage” the schedule, i.e. allocate slots, based on some information such as traffic requirements? In which case, what does “static” mean? Probably “imposed upon the 6top layer” (if such notion still exists) by some external mechanism.

“or learnt by a node when joining the network, possibly in a format as defined by work item 1.”
Do you mean the description of the schedule would be provided “in-band” to the joining node (through EB’s or similar mechanism). This does not seem to fit the description of work item 1, where the “entity” is an upper layer. Or do you mean as a payload transported on a default cell/link between upper layer entities ?

“3. Produce "6TSCH architecture" to describe the design and implementation of 6TSCH networks. This document will highlight the different architectural blocks and signaling flows, including the operation of the network in the presence of multiple BBRs.”
Does this include any form of multi-hop ND? In light of the discussion at 6lo BoF on this topic, how will compare to 6lowpan-ND?

Sentences unclear to me
“A dynamic schedule for traffic that is switched at the timeslot level may for example be computed centrally by an entity located on the backbone.”  This sentence is complex and unclear to me overall. Consider rephrasing?
“Produce "Timeslot Management Methods and Formats" to describe how an entity can manage the TSCH schedule on a 6TSCH node”. Is it assumed that everybody knows what “entity” is supposed to mean in this context?

Minor changes
s/in front of interference/in front of narrow-band interference
s/- implementers guide, collecting/- implementers guide: this document will collect/
s/- coexistence guide, providing/- coexistence guide: this document will provide/

English writing

De : [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] De la part de Thomas Watteyne
Envoyé : jeudi 1 août 2013 15:13
À : 6TSCH; Ted Lemon ([email-masked]<mailto:[email-masked]>); Adrian Farrel ([email-masked]<mailto:[email-masked]>); Marc Blanchet
Objet : [6tsch] updated charter per BoF suggestion: thoughts?

All,

Pascal & Thomas

---

From: Gennaro Boggia <[email-masked]>
Date: Fri, 2 Aug 2013 09:57:30 +0200

Great!!

I think that now all is more clear and better explained.

Thank you very much for this work

Gennaro

Il giorno venerdì 2 agosto 2013, Xavier Vilajosana Guillen ha scritto:

> [email-masked] <javascript:_e({}, 'cvml',
> [email-masked]');>> wrote:
>
>> 2013/8/1 Thomas Watteyne <[email-masked] <javascript:_e({},
>> 'cvml', [email-masked]');>>:
>> > All,
>> >
>> > [email-masked] <javascript:_e({}, 'cvml', [email-masked]');>
>> [email-masked] <javascript:_e({}, 'cvml', [email-masked]');>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 2 Aug 2013 08:56:34 +0000

Certainly Rafa;

It is fine that some documents stay personal submissions for a while.
We know we need to continue the work that has started on security and expand it.
And hopefully we'll progress the initial items efficiently and re-charter soon to take more of the required work on board.

On security: we probably want to separate the analysis of the particular issues with in one hand:
- issues with this MAC,
- the potential scale of a 6TSCH network,
- the various deployment types (need for profiles?),

And in the other:
- applicability statements such as PANA
- return from experience (ISA100.11a, Wireless HART)

The quality and coverage of the work will be a good incentive to make sure that it can progress in a proper way.

Cheers,

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of Rafa Marin Lopez
Sent: jeudi 1 août 2013 23:11
To: Thomas Watteyne
Cc: Adrian Farrel ([email-masked]); 6TSCH; Ted Lemon ([email-masked]); Marc Blanchet
Subject: Re: [6tsch] updated charter per BoF suggestion: thoughts?

Dear Chairs:

Best Regards.

All,

Pascal & Thomas
_______________________________________________
6tsch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tsch

-------------------------------------------------------
Rafael Marin Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: [email-masked]<mailto:[email-masked]>
-------------------------------------------------------

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 2 Aug 2013 11:06:22 +0000

Hello Qin:

Thanks for the comments!

With this version of the charter<https://bitbucket.org/6tsch/charter-ietf-6tsch/src/master/charter-ietf-6tsch-00.txt>, 6top is a thin layer that enables the operation in the basic operation as described in Xavi's draft<http://tools.ietf.org/html/draft-vilajosana-6tsch-basic> and that's it.
The bare minimum for 6top is a schedule that provides base links for RPL operations.
Within charter, each node boots with a default schedule, may get an update at join time and from then on it lives with it. This is what we call static.

The more complex pieces of 6top which required standardization:
- dynamic negotiation between peers to allocate timeslots for routed traffic (your dynamic)
- track allocation for switched traffic (your static?)
- track switching operation (G-MPLS)
are delayed till be have standardized the basic mechanisms to manage the schedule in the first place.
So we do not consider either distributed or centralized schedule recomputation.

The focus is on which primitives are needed from / to the device to manage a schedule regardless of which entity is doing the management.
The draft charter is voluntarily agnostic of what that abstract entity is because the control primitives should be open enough regardless of:
- the type of peer entity (a CNM engine, a PCE, an SDN controller...)
- the transport to which the primitive is bound

If the basic operation document becomes the solution for our item1, it will probably propose a simple method (e.g. CoAP based) to inject a schedule in every node so we can test interop. The complexity in the scheduling may not require standardization but may still be discussed in the first architecture draft.

This is probably enough work for a first round, wouldn't you think?

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of Qin Wang
Sent: jeudi 1 août 2013 23:11
To: Thomas Watteyne
Cc: Adrian Farrel ([email-masked]); 6TSCH; Ted Lemon ([email-masked]); Marc Blanchet
Subject: Re: [6tsch] updated charter per BoF suggestion: thoughts?

Regarding to the scope, i.e. "Description of Working Group", I would like to clarify my understanding on "static schedule", and "dynamic schedule" firstly.

Actually, there are two parameters related to establishing and maintaining a TSCH schedule, one is about "who", which values are (centralized, decentralized); another one is about change over time, which values are (static, dynamic). In the current version of 6top, the two parameters are associated with each other (but not have to), i.e. "centralized" is associated with "static", because it is assumed that centralized can optimize resource and avoid collision; and "decentralized" is associated with "dynamic", because it is assumed collision can not avoided completely by local negotiation.

The Charter says  "Initially, the WG will define a framework to install a static schedule and
run the Routing Protocol for LLNs (RPL) over that schedule. If successful, the intent is to recharter to allow for dynamic schedules......".
It means:
step-1: we define methods and messages for establishing TSCH schedule in the way of (centralized, static);
step-2: we define  methods and messages for establishing TSCH schedule in the way of (centralized, dynamic) and  (decentralized, dynamic) ;

Correct?

Based one above, how do you think the combination (decentralized, dynamic)? For example, allow establishing schedule locally, but do not allow change, or in another word, change must be instructed by upper layer, instead of by the sublayer.

Thanks
Qin

On Thu, Aug 1, 2013 at 9:12 PM, Thomas Watteyne <[email-masked]<mailto:[email-masked]>> wrote:
All,

Pascal & Thomas

---

From: Gennaro Boggia <[email-masked]>
Date: Fri, 2 Aug 2013 13:08:56 +0200

Great!!!

Cheers

Gennaro

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 2 Aug 2013 11:30:41 +0000

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of Raghuram Sudhaakar (rsudhaak)
Sent: vendredi 2 août 2013 08:10
To: [email-masked]; Thomas Watteyne; 6TSCH
Subject: Re: [6tsch] updated charter per BoF suggestion: thoughts?

Hello Raghu

Thomas, Pascal,

  1.  The statement "Initially, the WG will define a framework to install a static schedule and
  2.  run the Routing Protocol for LLNs (RPL) over that schedule" in the description of the working group and work item 1 seem to be in conflict. We say we will work on static schedules which means
  3.  that L3 (RPL) can only query cell/link quality info from TSCH. Work item 1 explicitly states - "to describe how an entity
  4.  can manage the TSCH schedule on a 6TSCH node". I feel it is better to remove this statement from the work item.
  5.  In this context, The current work item 1 could possibly be renamed to ,
  6.  "Query methods and formats for timeslot/cell parameters"??
  7.  Also, it may be better to flip the order of work items 1,2 (i.e) have "minimal 6TSCH config" as first work item and
  8.  "Query methods and formats for timeslot/cell parameters"
  9.  as work item 1 to reflect the statements made in the description of the working group.
  10.
  11. I second the point about elaborating on "entity" in the current work item 1 raised by Dominique and Qin. We could say, "route management entity"?

[] Hum. I talked to Benoit, and we concluded that we should consider network management from day 1, just like we consider security from day 1.
Day 1 for the schedule control primitives being now, we need to allow for more general entities than just routing.
So we are including the capability to report timeslot statistics, which may or may or may not be used for centralized routing computation in next iteration of the charter, but will be required for network management activities anyway.

We may also reword the second paragraph of Description of working group as follows -
Initially, the WG will define a framework to install a static schedule on a 6TSCH network and run the Routing
Protocol for LLNs (RPL) over that schedule. We will also define methods for RPL to query parameters and states from the 6TSCH network.

[] You are proposing to add the last sentence above. Tis is actually opening a Pandora bow that I'd rather leave close for the time being. RPL may obtain link layer stats and there is nothing new there; but we are voluntarily hiding the TSCH aspect at the 6top layer. We are shooting for simple in the first iteration. To be honest, I'm not sure that in the future, RPL should influence the schedule other than indirectly, that is by causing more or less traffic to be routed via particular next hops, thus influencing 6top to modify the size of a bundle. Whether I'm right or wrong there, we are delaying this item thus leaving the necessary time for this discussion.

can be reworded as -

[] this is a secondary piece that opens for the next iterations. What we want to indicate is that the track operation is in future scope, kind of locking this work to this WG even if it is not in scope now. We voluntarily use the terms "routed" and "switched" for the reasons I evoked in my answer to Qin. Switched == track, whether installed by PCE or RSVP type of operation, and comes prior to the traffic. Routed operation starts with an initial schedule as covered by this charter, but in the next iteration, the 6top layer in this node will need to interact with its peers in the neighbors to dynamically adapt the bundles to the traffic.

Does this make sense?

Cheers,

Pascal

Dominique

---------

Questions

Sentences unclear to me

Minor changes

English writing

All,

Pascal & Thomas

Thank you.

---

From: Qin Wang <[email-masked]>
Date: Fri, 2 Aug 2013 19:34:30 +0800

Hi Pascal,

I agree with it. Thanks!

Qin

On Fri, Aug 2, 2013 at 7:06 PM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

>  Hello Qin:****
>
> ** **
>
> Thanks for the comments!****
>
> ** **
>
> With this version of the charter<https://bitbucket.org/6tsch/charter-ietf-6tsch/src/master/charter-ietf-6tsch-00.txt>,
> 6top is a thin layer that enables the operation in the basic operation as
> described in Xavi’s draft<http://tools.ietf.org/html/draft-vilajosana-6tsch-basic>and that’s it.
> ****
>
> The bare minimum for 6top is a schedule that provides base links for RPL
> operations. ****
>
> Within charter, each node boots with a default schedule, may get an update
> at join time and from then on it lives with it. This is what we call static.
> ****
>
> ** **
>
> The more complex pieces of 6top which required standardization:****
>
> - dynamic negotiation between peers to allocate timeslots for routed
> traffic (your dynamic)****
>
> - track allocation for switched traffic (your static?)****
>
> - track switching operation (G-MPLS)****
>
> are delayed till be have standardized the basic mechanisms to manage the
> schedule in the first place.****
>
> So we do not consider either distributed or centralized schedule
> recomputation. ****
>
> ** **
>
> The focus is on which primitives are needed from / to the device to manage
> a schedule regardless of which entity is doing the management.****
>
> The draft charter is voluntarily agnostic of what that abstract entity is
> because the control primitives should be open enough regardless of:****
>
> - the type of peer entity (a CNM engine, a PCE, an SDN controller...) ****
>
> - the transport to which the primitive is bound****
>
> ** **
>
> If the basic operation document becomes the solution for our item1, it
> will probably propose a simple method (e.g. CoAP based) to inject a
> schedule in every node so we can test interop. The complexity in the
> scheduling may not require standardization but may still be discussed in
> the first architecture draft.****
>
> ** **
>
> This is probably enough work for a first round, wouldn’t you think?****
>
> ** **
>
> Pascal****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Qin Wang
>
> *Sent:* jeudi 1 août 2013 23:11
> *To:* Thomas Watteyne
> *Cc:* Adrian Farrel ([email-masked]); 6TSCH; Ted Lemon (
> [email-masked]); Marc Blanchet
> *Subject:* Re: [6tsch] updated charter per BoF suggestion: thoughts?****
>
> ** **
>
> Hi Thomas, Pascal and All,****
>
> ** **
>
> firstly. ****
> ** **
> by local negotiation.****
>
> ** **
>
> static schedule and ****
> the intent is to recharter to allow for dynamic schedules......".  ****
>
> It means: ****
>
> the way of (centralized, static); ****
>
> the way of (centralized, dynamic) and  (decentralized, dynamic) ; ****
>
> ** **
>
> Correct?****
>
> ** **
>
> Based one above, how do you think the combination (decentralized,
> dynamic)? For example, allow establishing schedule locally, but do not
> allow change, or in another word, change must be instructed by upper layer,
> instead of by the sublayer.****
>
> ** **
>
> Thanks****
>
> Qin****
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> On Thu, Aug 1, 2013 at 9:12 PM, Thomas Watteyne <
> [email-masked]> wrote:****
>
> All,****
>
> ** **
>
> reducing the number of work items.****
>
> ** **
>
> draft, which we have uploaded in the repo at:****
>
>
> ****
> ** **
> right now.****
> ** **
> Pascal & Thomas****
> https://www.ietf.org/mailman/listinfo/6tsch****
>
> ** **
>

---

From: <[email-masked]>
Date: Fri, 2 Aug 2013 11:49:14 +0000

Thomas and Pascal,
Many thanks for answering Qin and Raghuram's questions. It makes it more clear.
I support this charter.
Best Wishes,
Pouria

All,

Pascal & Thomas

---

From: Rafa Marin Lopez <[email-masked]>
Date: Fri, 2 Aug 2013 13:48:25 +0200

Thanks Pascal for the clarifications. Completely agree with that (and, of course, with the new charter)

Enviado desde mi iPhone

El 02/08/2013, a las 10:56, "Pascal Thubert (pthubert)" <[email-masked]> escribió:

> And hopefully we’ll progress the initial items efficiently and re-charter soon to take more of the required work on board.
>

---

From: Thomas Watteyne <[email-masked]>
Date: Fri, 2 Aug 2013 16:47:14 +0200

Dominique,
Great comments, thanks a million! Please see the answers inline.
Thomas

On Thu, Aug 1, 2013 at 7:01 PM, <[email-masked]> wrote:

>  Woww, now this is very focused. This should give us a clear framework to
> start our work, and hopefully expand later.****
>
> Overall, I believe the current Work Items description could elaborate a
> bit more.****
>
> Specifically, please find below my questions, followed by other minor
> remarks/suggested changes.****
>
> ** **
>
> Dominique****
>
> ** **
>
> ---------****
>
> ** **
>
> Questions****
>
> « Produce "Timeslot Management Methods and Formats" to describe how an
> entity can manage the TSCH schedule on a 6TSCH node”. The schedule is
> somewhere described as being static. In this sentence, the schedule can be
> “managed” by an “entity”. What prevents the so-called entity to “manage”
> the schedule, i.e. allocate slots, based on some information such as
> traffic requirements? In which case, what does “static” mean? Probably
> “imposed upon the 6top layer” (if such notion still exists) by some
> external mechanism.
>

I believe we are perfectly in sync. Work item 1 is about the bits-and-bytes
to describe the schedule and timeslot information. I makes no assumption on
when/how it will be used. As you point out, it can be used (1) in the
static schedule case to learn about the health of the network, and (2) to
manage the schedule at run-time from an external entity such as a PCE. This
second point is out of scope for the moment.

 ****
>
> ** “or learnt by a node when joining the network, possibly in a format as
> defined by work item 1.”
>
> Do you mean the description of the schedule would be provided “in-band” to
> the joining node (through EB’s or similar mechanism). This does not seem to
> fit the description of work item 1, where the “entity” is an upper layer.
> Or do you mean as a payload transported on a default cell/link between
> upper layer entities ?
>

The latter is absolutely possible, as detailed in
http://www.ietf.org/mail-archive/web/6tsch/current/msg00973.html.

> ****
>
> “3. Produce "6TSCH architecture" to describe the design and implementation
> of 6TSCH networks. This document will highlight the different architectural
> blocks and signaling flows, including the operation of the network in the
> presence of multiple BBRs.”
>
> Does this include any form of multi-hop ND? In light of the discussion at
> 6lo BoF on this topic, how will compare to 6lowpan-ND?
>
We want the architecture to describe all the contextual information for the
reader to get the whole picture, in order to this document to be a good
entrypoint into t e work at 6TSCH. It will therefore describe the IPv6
stack and the backbone operation, but the focus will largely be on RPL
operation over TSCH networks.

> ****
>
> ** Sentences unclear to me
>
> “A dynamic schedule for traffic that is switched at the timeslot level may
> for example be computed centrally by an entity located on the backbone.”
>  This sentence is complex and unclear to me overall. Consider rephrasing?
>
Good catch, we reworded the sentence to:
For example, an entity located on the backbone can be centrally compute a
dynamic schedule for traffic to be switched by the timeslot sublayer.
This does not change the meaning of the sentence.

> ****
>
> “Produce "Timeslot Management Methods and Formats" to describe how an
> entity can manage the TSCH schedule on a 6TSCH node”. Is it assumed that
> everybody knows what “entity” is supposed to mean in this context?
>
I believe that there are several types of entities that may benefit from
this format, so we'd like to stay agnostic to the exact nature of the
entity in the charter language. This is discuss in
http://www.ietf.org/mail-archive/web/6tsch/current/msg00973.html and
http://www.ietf.org/mail-archive/web/6tsch/current/msg00975.html.

> ** Minor changes
Done, thanks!

> s/- implementers guide, collecting/ - implementers guide: this document

Done, thanks!

> s/- coexistence guide, providing/- coexistence guide: this document will
Done, thanks!

> ** English writing
Done, thanks!

> s/Initially the document/Initially, the document
Done, thanks!

> s/be adapted dynamically/be dynamically adapted/
I'm not sure about that. When reading the sentence, having the qualifier
"dynamically" after stresses it. I hope you agree.

> *De :* [email-masked] [mailto:[email-masked]] *De la part
> de* Thomas Watteyne
> *Envoyé :* jeudi 1 août 2013 15:13
> *À :* 6TSCH; Ted Lemon ([email-masked]); Adrian Farrel (
> [email-masked]); Marc Blanchet
> *Objet :* [6tsch] updated charter per BoF suggestion: thoughts?****
>
> ** **
>
> All,****
>
> ** **
>

---

From: Thomas Watteyne <[email-masked]>
Date: Fri, 2 Aug 2013 16:51:30 +0200

All,

We have slighted refined the language of the proposed charter following the
discussions in this thread. We feel the text is now ready, please let us
know in the next 48h is you notice a major issue with the finalized text.

The URL of the latest version has not changed, you can find it at:
https://bitbucket.org/6tsch/charter-ietf-6tsch/src/master/charter-ietf-6tsch-00.txt

Pascal & Thomas

On Fri, Aug 2, 2013 at 4:47 PM, Thomas Watteyne
<[email-masked]>wrote:

>>  Woww, now this is very focused. This should give us a clear framework
>> to start our work, and hopefully expand later.****
>>
> I believe we are perfectly in sync. Work item 1 is about the
> bits-and-bytes to describe the schedule and timeslot information. I makes
> no assumption on when/how it will be used. As you point out, it can be used
> (1) in the static schedule case to learn about the health of the network,
> and (2) to manage the schedule at run-time from an external entity such as
> a PCE. This second point is out of scope for the moment.
>
>  ****
>>
>> ** “or learnt by a node when joining the network, possibly in a format
>> as defined by work item 1.”
>>
>> Do you mean the description of the schedule would be provided “in-band”
>> to the joining node (through EB’s or similar mechanism). This does not seem
>> to fit the description of work item 1, where the “entity” is an upper
>> layer. Or do you mean as a payload transported on a default cell/link
>> between upper layer entities ?
>>
>
>> “3. Produce "6TSCH architecture" to describe the design and
>> implementation of 6TSCH networks. This document will highlight the
>> different architectural blocks and signaling flows, including the operation
>> of the network in the presence of multiple BBRs.”
>>
> We want the architecture to describe all the contextual information for
> the reader to get the whole picture, in order to this document to be a good
>> “A dynamic schedule for traffic that is switched at the timeslot level
>> may for example be computed centrally by an entity located on the
>> backbone.”  This sentence is complex and unclear to me overall. Consider
>> rephrasing?
>>
>> *De :* [email-masked] [mailto:[email-masked]] *De la
>> part de* Thomas Watteyne
>> After discussion and suggestions from numerous 6TSCH and other people
>> here at the IETF, the chairs have created a new, simplified version of the

---

From: Rene Struik <[email-masked]>
Date: Fri, 02 Aug 2013 11:12:42 -0400

Hi Thomas, Pascal:

Is the intention to leave security out of the present charter and 
potentially consider as follow-up item with rechartering, or is this 
somehow captured implicitly under work item #2 (given "learnt when 
joining the network" language). I would suggest to make this more explicit.

I have one question re Description of the Working Group:
the text suggests a static schedule "once the network is formed". What 
if one has a network that may change in composition (e.g., one first 
only has a PAN coordinator and adds devices along the way, or has to 
add/remove devices while in operation). Wouldn't this potentially have 
an impact on scheduling? (otherwise, wouldn't one have to be clairvoyant 
as to which devices will be on the network and when?)

Best regards, Rene

Description of Working Group:
-----------------------------

Initially, the WG will define a framework to install a static schedule that
remains unchanged once the network is formed, and to run the Routing Protocol
for LLNs (RPL) over that schedule.

If successful, the intent is to recharter to allow for dynamic schedules.

Work Items:
-----------

The group will:

1. Produce "Timeslot Management Methods and Formats" to describe how an entity
can manage the TSCH schedule on a 6TSCH node, and query timeslot information
from that node. Metrics such as timeslot quality reports are in scope, but
the actual bindings to transport operation are not.

2. Produce "Minimal 6TSCH Configuration" to define how to build a 6TSCH network
using the Routing Protocol for LLNs (RPL). This document will assume a static
TSCH schedule, which can be either hardcoded, or learnt by a node when joining
the network, possibly in a format as defined by work item 1.

3. Produce "6TSCH architecture" to describe the design and implementation of
6TSCH networks. This document will highlight the different architectural blocks
and signaling flows, including the operation of the network in the presence of
multiple BBRs. Initially, the document will focus on distributed routing
operation over a static TSCH schedule.

On 8/2/2013 10:51 AM, Thomas Watteyne wrote:
> All,
>
> We have slighted refined the language of the proposed charter 
> following the discussions in this thread. We feel the text is now 
> ready, please let us know in the next 48h is you notice a major issue 
> with the finalized text.
>
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Dominique,
>     On Thu, Aug 1, 2013 at 7:01 PM, <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>         Woww, now this is very focused. This should give us a clear
>         framework to start our work, and hopefully expand later.
>
>         « Produce "Timeslot Management Methods and Formats" to
>         describe how an entity can manage the TSCH schedule on a 6TSCH
>         node". The schedule is somewhere described as being static. In
>         this sentence, the schedule can be "managed" by an "entity".
>         What prevents the so-called entity to "manage" the schedule,
>         i.e. allocate slots, based on some information such as traffic
>         requirements? In which case, what does "static" mean? Probably
>         "imposed upon the 6top layer" (if such notion still exists) by
>         some external mechanism.
>
>
>     bits-and-bytes to describe the schedule and timeslot information.
>     I makes no assumption on when/how it will be used. As you point
>     out, it can be used (1) in the static schedule case to learn about
>     the health of the network, and (2) to manage the schedule at
>     run-time from an external entity such as a PCE. This second point
>     is out of scope for the moment.
>
>         Do you mean the description of the schedule would be provided
>         "in-band" to the joining node (through EB's or similar
>         mechanism). This does not seem to fit the description of work
>         item 1, where the "entity" is an upper layer. Or do you mean
>         as a payload transported on a default cell/link between upper
>         layer entities ?
>
>
>         "3. Produce "6TSCH architecture" to describe the design and
>         implementation of 6TSCH networks. This document will highlight
>         the different architectural blocks and signaling flows,
>         including the operation of the network in the presence of
>         multiple BBRs."
>
>         Does this include any form of multi-hop ND? In light of the
>         discussion at 6lo BoF on this topic, how will compare to
>         6lowpan-ND?
>
>     We want the architecture to describe all the contextual
>     information for the reader to get the whole picture, in order to
>     this document to be a good entrypoint into t e work at 6TSCH. It
>     will therefore describe the IPv6 stack and the backbone operation,
>     but the focus will largely be on RPL operation over TSCH networks.
>
>         Sentences unclear to me
>
>         "A dynamic schedule for traffic that is switched at the
>         timeslot level may for example be computed centrally by an
>         entity located on the backbone."  This sentence is complex and
>         unclear to me overall. Consider rephrasing?
>
>     For example, an entity located on the backbone can be centrally
>     compute a dynamic schedule for traffic to be switched by the
>     timeslot sublayer.
>         "Produce "Timeslot Management Methods and Formats" to describe
>         how an entity can manage the TSCH schedule on a 6TSCH node".
>         Is it assumed that everybody knows what "entity" is supposed
>         to mean in this context?
>
>     I believe that there are several types of entities that may
>     benefit from this format, so we'd like to stay agnostic to the
>     exact nature of the entity in the charter language. This is
>     discuss in
>     I'm not sure about that. When reading the sentence, having the
>     qualifier "dynamically" after stresses it. I hope you agree.
>
>         *De :[email-masked] <mailto:[email-masked]>
>         [mailto:[email-masked]
>         <mailto:[email-masked]>] *De la part de* Thomas Watteyne
>         *À :* 6TSCH; Ted Lemon ([email-masked]
>         <mailto:[email-masked]>); Adrian Farrel
>         ([email-masked] <mailto:[email-masked]>); Marc Blanchet
>         *Objet :* [6tsch] updated charter per BoF suggestion: thoughts?
>
>         All,
>
>         Thanks to all for for the effort of putting together the BoF
>         on Tuesday! One of the suggestions was to simplify the
>         charter, in particular by reducing the number of work items.
>
>         After discussion and suggestions from numerous 6TSCH and other
>         people here at the IETF, the chairs have created a new,
>         simplified version of the draft, which we have uploaded in the
>         repo at:
>
>         This e-mail is to start a discussion on the ML about this
>         revamped charter. Please send comments directly to this
>         thread. Ideally, we would like to converge within a couple of
>         days, so let's start the discussion right now.
>
>         Pascal & Thomas
>

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: Thomas Watteyne <[email-masked]>
Date: Fri, 2 Aug 2013 18:53:49 +0200

Rene,

The feedback we got both from the BoF and the discussions afterwards was
that we needed to reduce the scope of the charter, especially the work
items. Essentially, we needed to more clearly highlight the order of the
work that needs to be done, and identify the first steps. The proposed
charter is therefore not saying "this is the solution we want to build",
but rather "these are the first steps towards that solution". As a
consequence, what was removed during the revamping process are not things
we do not want to do, but rather what we don't want to do right now. As
stated in the charter, if we are successful, the intent is to recharter to
proceed to the next steps.

The result is that the draft charter contains only the very first steps. We
believe that the completed work items will form a solid basis on which to
build the next steps. We need to start with something very simple, and
throughout the discussion we had at the IETF, it became clear that the
simplest case is one where the schedule is static, i.e. once a node has
joined a network, its schedule does no change. Obviously, this does not
exploit all the possibilities of a TSCH network, but allows us to work on
the interaction between TSCH and RPL for example. Once we have that, we can
start working on dynamically allocating timeslots.

To answer your question, while work item 2 can certainly contain a minimal
security recommendations, the real work on security will happen when we
start to deal with dynamic allocation of time slots, for example the
establishment of a secure session between the nodes and the PCE. As you
pointed out, it is premature to talk about a security solution; the first
step is to define the requirements, then come up with a general
architecture. This can only happen once we introduce new element, such as
the PCE.

About your second remark, I agree that the text is ambiguous. I have
modified the language and committed.

Initially, the WG will consider a framework to install a static schedule. In
this case, a node's schedule remains unchanged after it is done joining the
network. The Routing Protocol for LLNs (RPL) is used on the resulting
network.

Thomas

On Fri, Aug 2, 2013 at 5:12 PM, Rene Struik <[email-masked]> wrote:

> somehow captured implicitly under work item #2 (given "learnt when joining
> the network" language). I would suggest to make this more explicit.
>
> the text suggests a static schedule "once the network is formed". What if
> one has a network that may change in composition (e.g., one first only has
> a PAN coordinator and adds devices along the way, or has to add/remove
> devices while in operation). Wouldn't this potentially have an impact on
> scheduling? (otherwise, wouldn't one have to be clairvoyant as to which
> devices will be on the network and when?)
>
> Best regards, Rene
>
>
> Description of Working Group:-----------------------------
>
>
>
> Initially, the WG will define a framework to install a static schedule thatremains unchanged once the network is formed, and to run the Routing Protocol
> Work Items:-----------The group will:1. Produce "Timeslot Management Methods and Formats" to describe how an entity
> can manage the TSCH schedule on a 6TSCH node, and query timeslot informationfrom that node. Metrics such as timeslot quality reports are in scope, butthe actual bindings to transport operation are not.
> 2. Produce "Minimal 6TSCH Configuration" to define how to build a 6TSCH networkusing the Routing Protocol for LLNs (RPL). This document will assume a staticTSCH schedule, which can be either hardcoded, or learnt by a node when joining
> 3. Produce "6TSCH architecture" to describe the design and implementation of6TSCH networks. This document will highlight the different architectural blocksand signaling flows, including the operation of the network in the presence of
> multiple BBRs. Initially, the document will focus on distributed routingoperation over a static TSCH schedule.
>
>
>
>  We have slighted refined the language of the proposed charter following
> the discussions in this thread. We feel the text is now ready, please let
> us know in the next 48h is you notice a major issue with the finalized text.
>
> On Fri, Aug 2, 2013 at 4:47 PM, Thomas Watteyne <
> [email-masked]> wrote:
>
>> Dominique,
>>> to start our work, and hopefully expand later.
>>>
>>> bit more.
>>> remarks/suggested changes.
>>>
>>>
>>>
>>> Dominique
>>>
>>>
>>>
>>> ---------
>>>
>>>
>>>
>>> Questions
>>>
>>> Does this include any form of multi-hop ND? In light of the discussion
>>> at 6lo BoF on this topic, how will compare to 6lowpan-ND?
>>>
>>  For example, an entity located on the backbone can be centrally compute
>> a dynamic schedule for traffic to be switched by the timeslot sublayer.
>>  I believe that there are several types of entities that may benefit
>> from this format, so we'd like to stay agnostic to the exact nature of the
> 6tsch mailing [email-masked]://www.ietf.org/mailman/listinfo/6tsch
>
>
>
> --

---

From: "Raghuram Sudhaakar (rsudhaak)" <[email-masked]>
Date: Fri, 2 Aug 2013 17:13:34 +0000

Pascal,
Thanks for the clarifications. The charter looks good now. I support it.

-raghuram

From: "Pascal Thubert (pthubert)" <[email-masked]<mailto:[email-masked]>>
Date: Friday, August 2, 2013 1:30 PM
To: raghuram sudhaakar <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Thomas Watteyne <[email-masked]<mailto:[email-masked]>>, 6TSCH <[email-masked]<mailto:[email-masked]>>, "Benoit Claise (bclaise)" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [6tsch] updated charter per BoF suggestion: thoughts?

Pascal

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Raghuram Sudhaakar (rsudhaak)
Sent: vendredi 2 août 2013 08:10
To: [email-masked]<mailto:[email-masked]>; Thomas Watteyne; 6TSCH
Subject: Re: [6tsch] updated charter per BoF suggestion: thoughts?

Hello Raghu

Thomas, Pascal,

[] You are proposing to add the last sentence above. Tis is actually opening a Pandora bow that I’d rather leave close for the time being. RPL may obtain link layer stats and there is nothing new there; but we are voluntarily hiding the TSCH aspect at the 6top layer. We are shooting for simple in the first iteration. To be honest, I’m not sure that in the future, RPL should influence the schedule other than indirectly, that is by causing more or less traffic to be routed via particular next hops, thus influencing 6top to modify the size of a bundle. Whether I’m right or wrong there, we are delaying this item thus leaving the necessary time for this discussion.

can be reworded as -

[] this is a secondary piece that opens for the next iterations. What we want to indicate is that the track operation is in future scope, kind of locking this work to this WG even if it is not in scope now. We voluntarily use the terms “routed” and “switched” for the reasons I evoked in my answer to Qin. Switched == track, whether installed by PCE or RSVP type of operation, and comes prior to the traffic. Routed operation starts with an initial schedule as covered by this charter, but in the next iteration, the 6top layer in this node will need to interact with its peers in the neighbors to dynamically adapt the bundles to the traffic.

Does this make sense?

Cheers,

Pascal

Dominique

---------

Questions

Sentences unclear to me

Minor changes

English writing

De :[email-masked]<mailto:[email-masked]> [mailto:[email-masked]] De la part de Thomas Watteyne
Envoyé : jeudi 1 août 2013 15:13
À : 6TSCH; Ted Lemon ([email-masked]<mailto:[email-masked]>); Adrian Farrel ([email-masked]<mailto:[email-masked]>); Marc Blanchet
Objet : [6tsch] updated charter per BoF suggestion: thoughts?

All,

Pascal & Thomas

Thank you.

---

From: Rene Struik <[email-masked]>
Date: Fri, 02 Aug 2013 13:17:34 -0400

Hi:

Thanks for the quick feedback. Perfectly fine now.

Rene

On 8/2/2013 12:53 PM, Thomas Watteyne wrote:
> Rene,
>
> The feedback we got both from the BoF and the discussions afterwards 
> was that we needed to reduce the scope of the charter, especially the 
> work items. Essentially, we needed to more clearly highlight the order 
> of the work that needs to be done, and identify the first steps. The 
> proposed charter is therefore not saying "this is the solution we want 
> to build", but rather "these are the first steps towards that 
> solution". As a consequence, what was removed during the revamping 
> process are not things we do not want to do, but rather what we don't 
> want to do right now. As stated in the charter, if we are successful, 
> the intent is to recharter to proceed to the next steps.
>
> The result is that the draft charter contains only the very first 
> steps. We believe that the completed work items will form a solid 
> basis on which to build the next steps. We need to start with 
> something very simple, and throughout the discussion we had at the 
> IETF, it became clear that the simplest case is one where the schedule 
> is static, i.e. once a node has joined a network, its schedule does no 
> change. Obviously, this does not exploit all the possibilities of a 
> TSCH network, but allows us to work on the interaction between TSCH 
> and RPL for example. Once we have that, we can start working 
> on dynamically allocating timeslots.
>
> To answer your question, while work item 2 can certainly contain a 
> minimal security recommendations, the real work on security will 
> happen when we start to deal with dynamic allocation of time slots, 
> for example the establishment of a secure session between the nodes 
> and the PCE. As you pointed out, it is premature to talk about a 
> security solution; the first step is to define the requirements, then 
> come up with a general architecture. This can only happen once we 
> introduce new element, such as the PCE.
>
> On Fri, Aug 2, 2013 at 5:12 PM, Rene Struik <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Thomas, Pascal:
>
>     potentially consider as follow-up item with rechartering, or is
>     this somehow captured implicitly under work item #2 (given "learnt
>     when joining the network" language). I would suggest to make this
>     more explicit.
>
>     the text suggests a static schedule "once the network is formed".
>     What if one has a network that may change in composition (e.g.,
>     one first only has a PAN coordinator and adds devices along the
>     way, or has to add/remove devices while in operation). Wouldn't
>     this potentially have an impact on scheduling? (otherwise,
>     wouldn't one have to be clairvoyant as to which devices will be on
>     the network and when?)
>
>     Best regards, Rene
>
>     for LLNs (RPL) over that schedule. If successful, the intent is to
>     recharter to allow for dynamic schedules.
>
>
>     Work Items:
>     -----------
>
>     The group will:
>
>     can manage the TSCH schedule on a 6TSCH node, and query timeslot
>     information from that node. Metrics such as timeslot quality
>     reports are in scope, but the actual bindings to transport
>     operation are not.
>     3. Produce "6TSCH architecture" to describe the design and
>     different architectural blocks and signaling flows, including the
>     operation of the network in the presence of
>>     ready, please let us know in the next 48h is you notice a major
>>     issue with the finalized text.
>>
>>             Woww, now this is very focused. This should give us a
>>             clear framework to start our work, and hopefully expand
>>             later.
>>
>>             describe how an entity can manage the TSCH schedule on a
>>             6TSCH node". The schedule is somewhere described as being
>>             static. In this sentence, the schedule can be "managed"
>>             by an "entity". What prevents the so-called entity to
>>             "manage" the schedule, i.e. allocate slots, based on some
>>             information such as traffic requirements? In which case,
>>             what does "static" mean? Probably "imposed upon the 6top
>>             layer" (if such notion still exists) by some external
>>             mechanism.
>>
>>
>>         bits-and-bytes to describe the schedule and timeslot
>>         information. I makes no assumption on when/how it will be
>>         used. As you point out, it can be used (1) in the static
>>         schedule case to learn about the health of the network, and
>>         (2) to manage the schedule at run-time from an external
>>         entity such as a PCE. This second point is out of scope for
>>         the moment.
>>
>>             Do you mean the description of the schedule would be
>>             provided "in-band" to the joining node (through EB's or
>>             similar mechanism). This does not seem to fit the
>>             description of work item 1, where the "entity" is an
>>             upper layer. Or do you mean as a payload transported on a
>>             default cell/link between upper layer entities ?
>>
>>
>>             "3. Produce "6TSCH architecture" to describe the design
>>             and implementation of 6TSCH networks. This document will
>>             highlight the different architectural blocks and
>>             signaling flows, including the operation of the network
>>             in the presence of multiple BBRs."
>>
>>             Does this include any form of multi-hop ND? In light of
>>             the discussion at 6lo BoF on this topic, how will compare
>>             to 6lowpan-ND?
>>
>>         information for the reader to get the whole picture, in order
>>         to this document to be a good entrypoint into t e work at
>>         6TSCH. It will therefore describe the IPv6 stack and the
>>         backbone operation, but the focus will largely be on RPL
>>             timeslot level may for example be computed centrally by
>>             an entity located on the backbone."  This sentence is
>>             complex and unclear to me overall. Consider rephrasing?
>>
>>         For example, an entity located on the backbone can be
>>         centrally compute a dynamic schedule for traffic to be
>>         switched by the timeslot sublayer.
>>             "Produce "Timeslot Management Methods and Formats" to
>>             describe how an entity can manage the TSCH schedule on a
>>             6TSCH node". Is it assumed that everybody knows what
>>             "entity" is supposed to mean in this context?
>>
>>         benefit from this format, so we'd like to stay agnostic to
>>         the exact nature of the entity in the charter language. This
>>         is discuss in
>>         I'm not sure about that. When reading the sentence, having
>>         the qualifier "dynamically" after stresses it. I hope you agree.
>>
>>             Thanks to all for for the effort of putting together the
>>             BoF on Tuesday! One of the suggestions was to simplify
>>             the charter, in particular by reducing the number of work
>>             items.
>>
>>             After discussion and suggestions from numerous 6TSCH and
>>             other people here at the IETF, the chairs have created a
>>             new, simplified version of the draft, which we have
>>             uploaded in the repo at:
>>
>>             thread. Ideally, we would like to converge within a
>>             couple of days, so let's start the discussion right now.
>>
>>             Pascal & Thomas
>>
>>     [email-masked]  <mailto:[email-masked]>
>     email:[email-masked]  <mailto:[email-masked]>  | Skype: rstruik
>     cell:+1 (647) 867-5658  <tel:%2B1%20%28647%29%20867-5658>  | US:+1 (415) 690-7363  <tel:%2B1%20%28415%29%20690-7363>
>
>
>
>

---

From: <[email-masked]>
Date: Sat, 3 Aug 2013 17:12:47 +0000

Hello Thomas, Pascal,

Thanks for your detailed answers to my questions and comments.
This new charter addresses them all.
I support it.
Cheers,

Dominique

De : [email-masked] [mailto:[email-masked]] De la part de Thomas Watteyne
Envoyé : vendredi 2 août 2013 16:52
À : 6TSCH
Objet : Re: [6tsch] updated charter per BoF suggestion: thoughts?

All,

We have slighted refined the language of the proposed charter following the discussions in this thread. We feel the text is now ready, please let us know in the next 48h is you notice a major issue with the finalized text.

Pascal & Thomas

On Fri, Aug 2, 2013 at 4:47 PM, Thomas Watteyne <[email-masked]<mailto:[email-masked]>> wrote:
Dominique,
Great comments, thanks a million! Please see the answers inline.
Thomas

On Thu, Aug 1, 2013 at 7:01 PM, <[email-masked]<mailto:[email-masked]>> wrote:

Dominique

---------

Questions

I believe we are perfectly in sync. Work item 1 is about the bits-and-bytes to describe the schedule and timeslot information. I makes no assumption on when/how it will be used. As you point out, it can be used (1) in the static schedule case to learn about the health of the network, and (2) to manage the schedule at run-time from an external entity such as a PCE. This second point is out of scope for the moment.

The latter is absolutely possible, as detailed in http://www.ietf.org/mail-archive/web/6tsch/current/msg00973.html.

Does this include any form of multi-hop ND? In light of the discussion at 6lo BoF on this topic, how will compare to 6lowpan-ND?
We want the architecture to describe all the contextual information for the reader to get the whole picture, in order to this document to be a good entrypoint into t e work at 6TSCH. It will therefore describe the IPv6 stack and the backbone operation, but the focus will largely be on RPL operation over TSCH networks.

 Sentences unclear to me

"A dynamic schedule for traffic that is switched at the timeslot level may for example be computed centrally by an entity located on the backbone."  This sentence is complex and unclear to me overall. Consider rephrasing?
Good catch, we reworded the sentence to:
For example, an entity located on the backbone can be centrally compute a dynamic schedule for traffic to be switched by the timeslot sublayer.
This does not change the meaning of the sentence.

"Produce "Timeslot Management Methods and Formats" to describe how an entity can manage the TSCH schedule on a 6TSCH node". Is it assumed that everybody knows what "entity" is supposed to mean in this context?
I believe that there are several types of entities that may benefit from this format, so we'd like to stay agnostic to the exact nature of the entity in the charter language. This is discuss in http://www.ietf.org/mail-archive/web/6tsch/current/msg00973.html and http://www.ietf.org/mail-archive/web/6tsch/current/msg00975.html.

 Minor changes

Done, thanks!

 English writing

s/be adapted dynamically/be dynamically adapted/
I'm not sure about that. When reading the sentence, having the qualifier "dynamically" after stresses it. I hope you agree.

De : [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] De la part de Thomas Watteyne
Envoyé : jeudi 1 août 2013 15:13
À : 6TSCH; Ted Lemon ([email-masked]<mailto:[email-masked]>); Adrian Farrel ([email-masked]<mailto:[email-masked]>); Marc Blanchet
Objet : [6tsch] updated charter per BoF suggestion: thoughts?

All,

Pascal & Thomas

Thank you.

---

From: Michael Richardson <[email-masked]>
Date: Sat, 17 Aug 2013 16:30:19 -0400

This email is directed at IESG types, as this requires an IESG action.

>>>>> "Thomas" == Thomas Watteyne <[email-masked]> writes:
    Thomas> After discussion and suggestions from numerous 6TSCH and
    Thomas> other people here at the IETF, the chairs have created a
    Thomas> new, simplified version of the draft, which we have uploaded
    Thomas> in the repo at:
    Thomas> https://bitbucket.org/6tsch/charter-ietf-6tsch/src/master/charter-ietf-6tsch-00.txt

Foolishly, I didn't copy this to my laptop before leaving for the
cottage, where I am now catching up on some mailing lists using DTN
protocols, as no network, so I haven't read the above. 

In the last version that I read the question of what, if anything, to do
with draft-ietf-roll-rpl-industrial-applicability was unresolved.

To recap, the options are:

1) nothing. Leave it in ROLL. It may progress as is, or it may reference sixtus
   work non-norminatively.
   A second document (-bis) might reference sixtus normatively in the future.

2) leave it in ROLL, have it reference sixtus work normatively, and
   have this document stalled until sixtus progresses.

3) move this document to sixtus, where I think it will get significantly
   more review and energy.

There are perhaps other options, which I would like to add to a list,
and then make a WG consensus call (in ROLL) about what feedback ROLL
would like the IESG to hear.

(You can perhaps see which one I prefer)

-- 
Michael Richardson
-at the cottage-

---

From: Michael Richardson <[email-masked]>
Date: Sun, 18 Aug 2013 18:37:20 -0400

please see inline.

>>>>> "mcr" == Michael Richardson <[email-masked]> writes:
    Thomas> in the repo at:

    mcr> Foolishly, I didn't copy this to my laptop before leaving for
    mcr> the cottage, where I am now catching up on some mailing lists
    mcr> using DTN protocols, as no network, so I haven't read the
    mcr> above.

I have re-read this final version.

Applicability statements are not included in the current charter, nor is
it clear to me if the industrial uses envisioned by the ROLL
industrial applicability statement knows if it needs static of dynamic 
schedules.

    mcr> In the last version that I read the question of what, if
    mcr> anything, to do with
    mcr> draft-ietf-roll-rpl-industrial-applicability was unresolved.

    mcr> To recap, the options are:

    mcr> 1) nothing. Leave it in ROLL. It may progress as is, or it may
    mcr> reference sixtus work non-norminatively.  A second document
    mcr> (-bis) might reference sixtus normatively in the future.

    mcr> 2) leave it in ROLL, have it reference sixtus work normatively,
    mcr> and have this document stalled until sixtus progresses.

    mcr> 3) move this document to sixtus, where I think it will get
    mcr> significantly more review and energy.

    mcr> There are perhaps other options, which I would like to add to a

I am now of the opinion that proceeding with (1), as things are, might
be the best way forward for now, but that a -bis document in some group
would be appropriate.  

My message to IESG-types is that the industrial applicability
statement-bis is required.

My uncertainty is that I don't not know if the non-bis applicability
statement will have any practical use in industry at all.  It might not
be worth the 16-bits to store the RFC#.   I look to those better
connected to that industry to say.

-- 
Michael Richardson
-at the cottage-

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 19 Aug 2013 12:45:21 +0100

Hi Michael,

Thanks for thinking about this.

I believe I read the bottom line as "Steady as she goes,"  but with the
intention of looking back at this from time to time.

And yes, Ted, should sixtus also have a milestone for some form of applicability
statement?

Cheers,
Adrian

---

From: Ted Lemon <[email-masked]>
Date: Mon, 19 Aug 2013 12:17:27 +0000

> And yes, Ted, should sixtus also have a milestone for some form of applicability

Do you mean in the form of a draft?

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 19 Aug 2013 13:22:52 +0100

Yup (with the intention of publication as an RFC :-)

> -----Original Message-----
> From: Ted Lemon [mailto:[email-masked]]
> Sent: 19 August 2013 13:17
> To: <[email-masked]>
> Cc: Michael Richardson; 6TSCH; <[email-masked]>;
<draft-ietf-roll-rpl-industrial-
> [email-masked]>
> Subject: Re: should 6tsch adopt draft-ietf-roll-rpl-industrial-applicability?
>