Subject: [6tsch] Finalized charter

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sun, 4 Aug 2013 17:14:39 +0000

Dear all:

We now have a clear consensus on the ML for the new charter text. We'll be proposing this text to Ted to request the formation of a 6TSCH WG.
Please find the final version in the repo at: https://bitbucket.org/6tsch/charter-ietf-6tsch/src/master/charter-ietf-6tsch-00.txt

Thanks a bunch for the hard work and the focus on this work!

Thomas & Pascal

---

From: Marc Blanchet <[email-masked]>
Date: Sun, 4 Aug 2013 13:25:19 -0400

Le 2013-08-04 à 13:14, "Pascal Thubert (pthubert)" <[email-masked]> a écrit :

> Dear all:
>  
> We now have a clear consensus on the ML for the new charter text. We‘ll be proposing this text to Ted to request the formation of a 6TSCH WG.

I have followed the charter discussion on the mailing list and I support this version.

Marc.

---

From: Marc Blanchet <[email-masked]>
Date: Sun, 4 Aug 2013 13:29:23 -0400

minor comment (please throw it away if people don't agree): I (and others I think) just have problems pronounciating the wg-to-be keyword (6tsch). This is obviously not the important part of this, but you might want to think about it before it is too late, because it will stick "forever". (and I would suggest not spend much time on this comment)...

marc.

---

From: Ted Lemon <[email-masked]>
Date: Sun, 4 Aug 2013 18:04:13 +0000

> minor comment (please throw it away if people don't agree): I (and others I think) just have problems pronounciating the wg-to-be keyword (6tsch). This is obviously not the important part of this,…

I would put this a little more strongly.   The normal pronunciation of this acronym at least in German is just asking for trouble, and I think the better part of valor is to choose a different acronym.   I took some flak at in the post-meeting wrapup because of this, and I wouldn't want anyone else to have to face that.

How about 6chants (IPv6 over Channel Hopping ANd Time Sliced links)?

---

From: "JP Vasseur (jvasseur)" <[email-masked]>
Date: Sun, 4 Aug 2013 18:20:45 +0000

Hi Pascal and all,

I think that the charter an excellent and I strongly support it !

I have two minor comments though:

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).

JP> Very minor comment ... replace BBR by LBR and we will be using the same terminology than ROLL.

The WG will interface with other IETF WGs, potentially including ROLL, 6Lo,
CoRE, 6MAN, LWIG, and other appropriate groups in the IETF Internet, Routing
and Security areas.

JP> I would make the following changes:

The WG will interface with other IETF WGs, including ROLL, 6Lo, PCE
CoRE, 6MAN, LWIG, and other appropriate groups in the IETF Internet, Routing
and Security areas.

Thanks !

JP.

On Aug 4, 2013, at 10:14 AM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:

Dear all:

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

---

From: Pieter De Mil <[email-masked]>
Date: Sun, 4 Aug 2013 20:40:52 +0200

I don't have a problem with 6tsch, but what about:

IPv6 over Time-slotted Channel hopping Slots

6TiCS

Think about a ticking clock.

Best,
Pieter

Op 4-aug.-2013 om 20:04 heeft Ted Lemon <[email-masked]> het volgende geschreven:

> [email-masked]

---

From: Marc Blanchet <[email-masked]>
Date: Sun, 4 Aug 2013 14:49:06 -0400

> Think about a ticking clock.

+1. (it sounds also like "sixties" which makes an interesting side-effect... can see all the proponents coming to the meeting in "sixties" clothes... ;-)

back to the regular technical channel...

Marc.

---

From: Pascal Thubert <[email-masked]>
Date: Sun, 4 Aug 2013 23:04:06 +0200

Neat ...

Others please jump in and propose names!

There is no real emergency but a little fun will not hurt after the dense week we had with the IETF 😊

I'll propose  WiNOT: Wireless Networks for Operational Technology...
Pascal

---

From: Pascal Thubert <[email-masked]>
Date: Sun, 4 Aug 2013 23:09:28 +0200

Dear JP and all

I'm fine with the second change though the actual work with PCE will really happen after the recharter.

For the BBR, it is actually a functional set that encompasses LBR as well as other functionalities that we have to debate, in particular some ND proxy and PCE location. We will need to name that set but will that be LBR?

Cheers,

Pascal

Le 4 août 2013 à 20:20, "JP Vasseur (jvasseur)" <[email-masked]> a écrit :

> On Aug 4, 2013, at 10:14 AM, Pascal Thubert (pthubert) <[email-masked]> wrote:
> 
>> Dear all:
>>

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 5 Aug 2013 10:54:26 +0200

On Aug 4, 2013, at 20:04, Ted Lemon <[email-masked]> wrote:

> The normal pronunciation of this acronym at least in German

For a German: TSCH = Tisch = "tish".
Add "six" (english pronunciation), and it's "sixtish".
Not too hard.

On the charter itself: I was rather skeptical about the version we discussed in Berlin, and I'm now less worried.

I don't quite understand the text for work item 1.  Why is this about querying (which I would have expected in a garden variety management protocol) and not about setting up?  Maybe I don't understand the relationship between 1 and 2.

Work item 2: s/hard-coded/pre-configured/?

I would probably stick with the "LBR" terminology as others have said.

We may need to discuss how the multi-LBR technology in 6TSCH (ND-proxy?) relates to that potentially addressed by 6Lo.  Since I don't think we will fully understand the relationship before the charters get finalized, maybe just note that in the charter.  (Maybe it is also worth highlighting any working relationship with ROLL, if that is required.  Is RPL being modified by 6TSCH?)

The charter currently does not discuss security or management, and I would prefer a clear statement whether that is in scope (re management, see comment about work item 1 above; security for bootstrapping a network is a complex issue where it would surprise me if people think this is in scope).

Grüße, Carsten

---

From: "Mani, Mehdi" <[email-masked]>
Date: Mon, 5 Aug 2013 14:05:05 +0000

I like this name if the charter becomes consequently broad and addresses Synchronized time-slotted communications instead of being limited to 802.15.4e.
-Mehdi 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Pieter De Mil
Sent: dimanche 4 août 2013 20:41
To: Ted Lemon
Cc: 6TSCH; Marc Blanchet; Erik Nordmark (nordmark); Pascal Thubert (pthubert); Adrian Farrel ([email-masked])
Subject: [6tsch] New name

6TiCS

Best,
Pieter

---

From: "Mani, Mehdi" <[email-masked]>
Date: Mon, 5 Aug 2013 14:08:27 +0000

I suggest 6tis = TIme sloted Synchronized

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Pascal Thubert
Sent: dimanche 4 août 2013 23:04
To: Pieter De Mil
Cc: Pascal Thubert (pthubert); Erik Nordmark (nordmark); Marc Blanchet; 6TSCH; Ted Lemon; Adrian Farrel ([email-masked])
Subject: Re: [6tsch] New name

Neat ...

---

From: "JP Vasseur (jvasseur)" <[email-masked]>
Date: Tue, 6 Aug 2013 00:18:40 +0000

Agree with Carsten and Pascal, I would stick to LBR and mention PCE specifically

---

From: Thomas Watteyne <[email-masked]>
Date: Tue, 6 Aug 2013 13:08:30 -0700

JP, Carsten,

Thanks for the very valuable input on the charter. Let me try to summarize
your comments and provide an answer to the issues you raise below.

*BBR->LBR*

*Suggestion from JP. Changing BBR to LBR would align terminology with the
ROLL WG.*

For reference, here are the definitions in the latest versions of the
drafts:

   - *LBR* (draft-ietf-roll-terminology-12): Low power and Lossy Network
   Border Router.  The LBR is a device that connects the Low power and Lossy
   Network to another routing domain such as a Local Area Network (LAN), Wide
   Area Network (WAN) or the Internet where a possibly different routing
   protocol is in operation.  The LBR acts as a routing device and may
   possibly host other functions such as data collector or aggregator.

   - *BBR* (draft-thubert-6lowpan-backbone-router-03): An IPv6 router that
   federates the LLN using a Backbone link as a backbone. A BBR acts as a
   6LoWPAN Border Routers (6LBR) and an Energy Aware Default Router (NEAR).

These are indeed very close terms. Whatever the name, I believe we are
talking about an entity which plays several roles, including handling
downstream routes where applicable (RPL), compacting 6LoWPAN header
(6LoWPAN), and federating several LLNs under one prefix (ND). As usual,
these functions can be co-located in the same box.

While I don't have a strong opinion on this, I tend to agree that LBR is a
more established term than BBR, and maybe a bit more generic according to
the definitions above.

Yet, we have already sent the proposed charter to the ADs for review. What
I have done is filing
https://bitbucket.org/6tsch/charter-ietf-6tsch/issue/5/bbr-lbr, to keep
track of your suggestion. We can integrate it if requested during future
discussion about the charter with the IESG.

*Add PCE to WG to interact with*

*Suggestion from JP. The idea is to list PCE as a WG to interact with.*

The reason we did not include it in the text is because the definition of
the node<->PCE interaction is not within scope of this charter. Work item 1
covers the format of the payload (e.g. the bits and bytes to describe a
cell), but not the exact transport solution or interaction.

That being said, this is absolutely what we tend towards, and when we
explicitly work on that, we will be interacting with the PCE WG. I
understand you are suggesting to list PCE right away. I have filed
https://bitbucket.org/6tsch/charter-ietf-6tsch/issue/6/add-pce-to-wg-to-interact-with
 to cover this.

*Interaction between Work Item 1 and 2*

*Clarifying question from Carsten.*

The goal of work item 1 is to describe a format for the PCE to be able to
send commands to the nodes, and for the nodes to send statistics and
topological information to the PCE. In this version of the charter, we
assume that the schedule is static, i.e. we do not address the PCE->nodes
traffic yet. That being said, statistics and topological information can
flow from node to PCE in a network resulting from work item 2. This for
example allows for close monitoring of the health of the network.

That being said, the scope of work item 1 is very clear and very "atomic".
Management includes setup, update, tear down, as well as getting reports.
The scope of work item 1 is not to focus on "network management" as a
whole, only to produce formats and methods that can be used by all points
of command, including PCE, node configuration, network management, etc.

*hard-coded -> pre-configured*

*Suggestion from Carsten.*

The term "pre-configured" is indeed more elegant than the term
"hard-coded". Would you agree, however, that both terms end up expressing
the same idea? I have filed
https://bitbucket.org/6tsch/charter-ietf-6tsch/issue/7/hard-coded-pre-configured
to
track and remember this suggestion.

Note that there is an intent that we provide a basic schedule that would
operate without any configuration. Then through the methods in item 1 we
propose to optionally set up an initial schedule that the node will use
instead.

*changing RPL?*

*Clarifying question from Carsten.*

The goal of the work at 6TSCH is absolutely not to change RPL, just to
describe how RPL can be be used on these time slotted networks. This is
probably going to be the biggest piece of the work done in work item 2.
What we might do is define some metrics and maybe even an OF, but NOT to
request any changes to RPL itself.

I would argue that, if the goal were to change RPL, this would appear
clearly in the charter text. In the absence of the statement "we want to
change RPL", we assume that the reader understands that the goal is to not
change RPL. We may study objective functions and new options, in particular
to transport a schedule, but we are not chartering to standardize work
there.

*security in scope?*

*Clarifying question from Carsten.*

We have had numerous discussion about this last week, including in-person
with Yoshihiro, Subir, Rafa, and by e-mail with Rene. I believe we had a
very similar discussion with Rene, which you can find at
http://www.ietf.org/mail-archive/web/6tsch/current/msg00985.html. Rene
agreed with the discussion.

In very short, work on security and management is welcome but we do not
charter a work item for this round.

I hope this answers your questions.

Thomas

On Mon, Aug 5, 2013 at 5:18 PM, JP Vasseur (jvasseur) <[email-masked]>wrote:

> > On the charter itself: I was rather skeptical about the version we
> discussed in Berlin, and I'm now less worried.
> >
> > I don't quite understand the text for work item 1.  Why is this about
> querying (which I would have expected in a garden variety management
> protocol) and not about setting up?  Maybe I don't understand the
> relationship between 1 and 2.
> >
> > We may need to discuss how the multi-LBR technology in 6TSCH (ND-proxy?)
> relates to that potentially addressed by 6Lo.  Since I don't think we will
> fully understand the relationship before the charters get finalized, maybe
> just note that in the charter.  (Maybe it is also worth highlighting any
> working relationship with ROLL, if that is required.  Is RPL being modified
> by 6TSCH?)
> >
> > The charter currently does not discuss security or management, and I
> would prefer a clear statement whether that is in scope (re management, see
> comment about work item 1 above; security for bootstrapping a network is a
> complex issue where it would surprise me if people think this is in scope).
> >
> > Grüße, Carsten
> >

---

From: "JP Vasseur (jvasseur)" <[email-masked]>
Date: Wed, 7 Aug 2013 00:45:21 +0000

Hi Thomas,

On Aug 6, 2013, at 1:08 PM, Thomas Watteyne <[email-masked]<mailto:[email-masked]>> wrote:

JP, Carsten,

Thanks for the very valuable input on the charter. Let me try to summarize your comments and provide an answer to the issues you raise below.

BBR->LBR

Suggestion from JP. Changing BBR to LBR would align terminology with the ROLL WG.

For reference, here are the definitions in the latest versions of the drafts:

  *   LBR (draft-ietf-roll-terminology-12): Low power and Lossy Network Border Router.  The LBR is a device that connects the Low power and Lossy Network to another routing domain such as a Local Area Network (LAN), Wide Area Network (WAN) or the Internet where a possibly different routing protocol is in operation.  The LBR acts as a routing device and may possibly host other functions such as data collector or aggregator.

  *   BBR (draft-thubert-6lowpan-backbone-router-03): An IPv6 router that federates the LLN using a Backbone link as a backbone. A BBR acts as a 6LoWPAN Border Routers (6LBR) and an Energy Aware Default Router (NEAR).

These are indeed very close terms. Whatever the name, I believe we are talking about an entity which plays several roles, including handling downstream routes where applicable (RPL), compacting 6LoWPAN header (6LoWPAN), and federating several LLNs under one prefix (ND). As usual, these functions can be co-located in the same box.

While I don't have a strong opinion on this, I tend to agree that LBR is a more established term than BBR, and maybe a bit more generic according to the definitions above.

Yet, we have already sent the proposed charter to the ADs for review. What I have done is filing https://bitbucket.org/6tsch/charter-ietf-6tsch/issue/5/bbr-lbr, to keep track of your suggestion. We can integrate it if requested during future discussion about the charter with the IESG.

JP> Perfect.

Add PCE to WG to interact with

Suggestion from JP. The idea is to list PCE as a WG to interact with.

The reason we did not include it in the text is because the definition of the node<->PCE interaction is not within scope of this charter. Work item 1 covers the format of the payload (e.g. the bits and bytes to describe a cell), but not the exact transport solution or interaction.

That being said, this is absolutely what we tend towards, and when we explicitly work on that, we will be interacting with the PCE WG. I understand you are suggesting to list PCE right away. I have filed https://bitbucket.org/6tsch/charter-ietf-6tsch/issue/6/add-pce-to-wg-to-interact-with to cover this.

JP> Thanks because even if the node<->PCE interaction is not yet in the charter, and the same applies to
PCE discovery, ... the fundamental notion of PCE is part of the architecture. I understand that for now the
schedule is static but we still make use of some PCE architecture, that will unavoidably evolve to more
dynamic scenarios.

Interaction between Work Item 1 and 2

Clarifying question from Carsten.

The goal of work item 1 is to describe a format for the PCE to be able to send commands to the nodes, and for the nodes to send statistics and topological information to the PCE. In this version of the charter, we assume that the schedule is static, i.e. we do not address the PCE->nodes traffic yet. That being said, statistics and topological information can flow from node to PCE in a network resulting from work item 2. This for example allows for close monitoring of the health of the network.

That being said, the scope of work item 1 is very clear and very "atomic". Management includes setup, update, tear down, as well as getting reports. The scope of work item 1 is not to focus on "network management" as a whole, only to produce formats and methods that can be used by all points of command, including PCE, node configuration, network management, etc.

JP> On that end, the ability for the PCE to "push" states (setup, update, ...) has been part of our rechartering
exercise with statefull PCE.

hard-coded -> pre-configured

Suggestion from Carsten.

The term "pre-configured" is indeed more elegant than the term "hard-coded". Would you agree, however, that both terms end up expressing the same idea? I have filed https://bitbucket.org/6tsch/charter-ietf-6tsch/issue/7/hard-coded-pre-configured to track and remember this suggestion.

Note that there is an intent that we provide a basic schedule that would operate without any configuration. Then through the methods in item 1 we propose to optionally set up an initial schedule that the node will use instead.

changing RPL?

Clarifying question from Carsten.

The goal of the work at 6TSCH is absolutely not to change RPL, just to describe how RPL can be be used on these time slotted networks. This is probably going to be the biggest piece of the work done in work item 2. What we might do is define some metrics and maybe even an OF, but NOT to request any changes to RPL itself.

I would argue that, if the goal were to change RPL, this would appear clearly in the charter text. In the absence of the statement "we want to change RPL", we assume that the reader understands that the goal is to not change RPL. We may study objective functions and new options, in particular to transport a schedule, but we are not chartering to standardize work there.

JP> And this is perfectly fine; we could discuss of where such extensions could be discussed, I would be perfectly
happy with both WG reviews, as long as these items do not "impact" the protocol, in which case I'd rather see the
work in ROLL, reviewed by 6TSCH. But again, I do not see that as an issue, risk of overlap, ...

security in scope?

Clarifying question from Carsten.

We have had numerous discussion about this last week, including in-person with Yoshihiro, Subir, Rafa, and by e-mail with Rene. I believe we had a very similar discussion with Rene, which you can find at http://www.ietf.org/mail-archive/web/6tsch/current/msg00985.html. Rene agreed with the discussion.

In very short, work on security and management is welcome but we do not charter a work item for this round.

JP> As far as I am concerned, it does answer the questions, I am VERY supportive !

Thanks.

JP.

Thomas

On Mon, Aug 5, 2013 at 5:18 PM, JP Vasseur (jvasseur) <[email-masked]<mailto:[email-masked]>> wrote:
Agree with Carsten and Pascal, I would stick to LBR and mention PCE specifically

On Aug 5, 2013, at 1:54 AM, Carsten Bormann <[email-masked]<mailto:[email-masked]>> wrote:

> On Aug 4, 2013, at 20:04, Ted Lemon <[email-masked]<mailto:[email-masked]>> wrote:
>
> [email-masked]<mailto:[email-masked]>

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

---

From: Thomas Watteyne <[email-masked]>
Date: Tue, 6 Aug 2013 17:47:03 -0700

JP,
Wonderful, thanks for the quick answer and support.
Thomas

On Tue, Aug 6, 2013 at 5:45 PM, JP Vasseur (jvasseur) <[email-masked]>wrote:

>  Hi Thomas,
>
>  On Aug 6, 2013, at 1:08 PM, Thomas Watteyne <[email-masked]>
> wrote:
>
>   JP, Carsten,
>
>  Thanks for the very valuable input on the charter. Let me try to
> summarize your comments and provide an answer to the issues you raise below.
>
>  *BBR->LBR*
>
>  *Suggestion from JP. Changing BBR to LBR would align terminology with
> the ROLL WG.*
>
>    - *BBR* (draft-thubert-6lowpan-backbone-router-03): An IPv6 router
>    that federates the LLN using a Backbone link as a backbone. A BBR acts as a
>  While I don't have a strong opinion on this, I tend to agree that LBR is
> a more established term than BBR, and maybe a bit more generic according to
> the definitions above.
>
>  Yet, we have already sent the proposed charter to the ADs for review.
> What I have done is filing
>  The reason we did not include it in the text is because the definition
> of the node<->PCE interaction is not within scope of this charter. Work
> item 1 covers the format of the payload (e.g. the bits and bytes to
> describe a cell), but not the exact transport solution or interaction.
>
> PCE discovery, ... the fundamental notion of PCE is part of the
> architecture. I understand that for now the
>  The goal of work item 1 is to describe a format for the PCE to be able
> to send commands to the nodes, and for the nodes to send statistics and
>  That being said, the scope of work item 1 is very clear and very
> "atomic". Management includes setup, update, tear down, as well as getting
> reports. The scope of work item 1 is not to focus on "network management"
> as a whole, only to produce formats and methods that can be used by all
> points of command, including PCE, node configuration, network management,
> etc.
>
>
>  JP> On that end, the ability for the PCE to "push" states (setup,
> update, ...) has been part of our rechartering
> https://bitbucket.org/6tsch/charter-ietf-6tsch/issue/7/hard-coded-pre-configured to
>  JP> And this is perfectly fine; we could discuss of where such
> extensions could be discussed, I would be perfectly
> happy with both WG reviews, as long as these items do not "impact" the
> protocol, in which case I'd rather see the
>  We have had numerous discussion about this last week, including
> in-person with Yoshihiro, Subir, Rafa, and by e-mail with Rene. I believe
> we had a very similar discussion with Rene, which you can find at
>> > We may need to discuss how the multi-LBR technology in 6TSCH
>> (ND-proxy?) relates to that potentially addressed by 6Lo.  Since I don't
>> think we will fully understand the relationship before the charters get
>> finalized, maybe just note that in the charter.  (Maybe it is also worth
>> highlighting any working relationship with ROLL, if that is required.  Is
>> RPL being modified by 6TSCH?)
>> >