Subject: Re: [6tisch] Consensus call on Summary of proposed resolution for issue 40 V3

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 4 Jan 2016 17:47:49 +0000

Dear all:

With my best wishes for a great year 2016, please find a reminder that we have a consensus (last) call running on the abstract and introduction of the minimal draft. 
In order to cope with the Year-End break, the call continues till next Friday. So far, all I've been seeing is consensus with the latest change that Ralph proposed. 
Where we are at now is as below:

--------------
Abstract

BEFORE

This document describes the minimal set of rules to operate an IEEE
802.15.4 Timeslotted Channel Hopping (TSCH) network.  This minimal
mode of operation can be used during network bootstrap, as a fall-
back mode of operation when no dynamic scheduling solution is
available or functioning, or during early interoperability testing
and development.

 ---------------
AFTER

This document describes a minimal mode of operation for a 6TiSCH
Network, to provide IPv6 connectivity over a Non-Broadcast
Multi-Access (NBMA) mesh that is formed of IEEE 802.15.4 Timeslotted
Channel Hopping (TSCH) links.
 
This minimal mode uses a collection of protocols including the 6LoWPAN
framework and RPL to enable interoperable IPv6 connectivity over
IEEE 802.15.4 TSCH with minimal network configuration and infrastructure.

---------------
-------------
-------------
-------------

Intro update:

BEFORE

--------------

1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

2.  Introduction

   The nodes in a IEEE 802.15.4 TSCH network follow a communication
   schedule.  The entity (centralized or decentralized) responsible for
   building and maintaining that schedule has precise control over the
   trade-off between the network's latency, bandwidth, reliability and
   power consumption.  During early interoperability testing and
   development, however, simplicity is more important than efficiency.
   One goal of this document is to define the simplest set of rules for
   building a TSCH-compliant network, at the necessary price of lesser
   efficiency.  Yet, this minimal mode of operation MAY also be used
   during network bootstrap before any schedule is installed into the
   network so nodes can self-organize and the management and
   configuration information be distributed.  In addition, the minimal
   configuration MAY be used as a fall-back mode of operation, ensuring
   connectivity of nodes in case that dynamic scheduling mechanisms fail
   or are not available.  The IEEE 802.15.4 specification provides a
   mechanism whereby the details of slotframe length, timeslot timing,
   and channel hopping pattern are communicated when a node time
   synchronizes to the network [IEEE802154].  This document describes
   specific settings for these parameters.

---------------------------

AFTER

--------------

1.  Introduction

   A 6TiSCH Network provides IPv6 connectivity over a Non-Broadcast
   Multi-Access (NBMA) mesh that is formed of IEEE 802.15.4
   Timeslotted Channel Hopping (TSCH) links.  

   The 6TiSCH [I-D.ietf-6tisch-architecture] architecture requires the
   use of both RPL and the 6LoWPAN adaptation layer framework 
   ([RFC4944], [RFC6282]) as defined over IEEE 802.14.5.
   6LoWPAN Neighbor Discovery [RFC6775] (ND)  is also required to
   exchange Compression Contexts,  form IPv6 addresses and register
   them for the purpose of Duplicate Address Detection, Address
   Resolution and Neighbor Unreachability detection over one
   TSCH link.
    
   Nodes in a IEEE 802.15.4 TSCH network follow a communication
   schedule.  A network using the simple mode of operation uses a
   static schedule.

   This specification defines operational parameters and procedures 
   for a minimal mode of operation to build a 6TiSCH  Network.
  The 802.15.4 TSCH mode, the 6LoWPAN framework, RPL [RFC6550],
   and its Objective Function 0 (OF0) [RFC6552], are used unmodified,
   but  parameters and particular operations of TSCH and RPL are 
   specified  to guarantee interoperability between nodes in a 6TiSCH
   Network. 
   
   More advanced work is expected in the future to complement the
   Minimal Configuration with dynamic operations that can adapt the
   Schedule to the needs of the traffic in run time.

2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

Cheers,

Pascal

> -----Original Message-----
> From: 6tisch [mailto:[email-masked]] On Behalf Of Ralph Droms
> Sent: vendredi 18 décembre 2015 17:24
> To: 6tisch <[email-masked]>
> Subject: Re: [6tisch] Consensus call on Summary of proposed resolution for issue
> 40 V3
> 
> (Moving discussion of the Abstract in "RE: [6tisch] #40 (minimal): Ralph's INT
> AREA review on minimal" to this thread.)
> 
> 
> > On Dec 18, 2015, at 9:13 AM 12/18/15, Pascal Thubert (pthubert)
> <[email-masked]> wrote:
> >
> > Dear all;
> >
> > In order to address Ralph's issues on the minimal draft, we proposed a
> rewording of the abstract and the introduction.
> > This reopens  a 2-weeks period of last call for these particular sections, with
> the text as below.
> > If you disagree with the text, please let us know before January 1st.
> >
> > Cheers,
> >
> > Pascal
> >
> >
> > -----Original Message-----
> > From: Ralph Droms (rdroms)
> > Sent: lundi 14 décembre 2015 19:35
> > To: Pascal Thubert (pthubert) <[email-masked]>
> > Cc: [email-masked]
> > Subject: Re: Summary of proposed resolution for issue 40 V3
> >
> >
> >> On Dec 14, 2015, at 11:16 AM 12/14/15, Pascal Thubert (pthubert)
> <[email-masked]> wrote:
> >>
> >> Hello Ralph:
> >>
> >> If you’re OK with this round, we’ll open a one week call to the WG to check
> consensus.
> >> The proposed replacement for slotted aloha is subject to change again
> >> in that phase J
> >>
> >> Please let us know;
> >
> > Assessing WG consensus is OK with me.
> >
> > - Ralph
> >
> >>
> >> Pascal
> >>
> >> ----------------------------------------------------------------------
> >> -----------
> >>
> >> Abstract update:
> >>
> >> BEFORE
> >>
> >>
> >> --------------
> >> Abstract
> >>
> >>  This document describes the minimal set of rules to operate an IEEE
> >>  802.15.4 Timeslotted Channel Hopping (TSCH) network.  This minimal
> >>  mode of operation can be used during network bootstrap, as a fall-
> >>  back mode of operation when no dynamic scheduling solution is
> >>  available or functioning, or during early interoperability testing
> >>  and development.
> >>
> >> ---------------
> >> AFTER
> >>
> >> ---------------
> >> Abstract
> >>
> >> This document describes a minimal mode of operation for a 6TiSCH
> >> Network, to provide IPv6 connectivity over a Non-Broadcast
> >> Multi-Access (NBMA) mesh that is formed of IEEE 802.15.4 Timeslotted
> Channel Hopping (TSCH) links.
> >> This minimal mode uses a collection of protocols including the 6LoWPAN
> >> framework and RPL to enable shared access operations over a static
> >> TSCH schedule
> 
> I'll reiterate my suggestion to use a higher level description here in the abstract:
> 
> This minimal mode uses a collection of protocols including the 6LoWPAN
> framework and RPL to enable interoperable IPv6 connectivity over
> IEEE 802.15.4 TSCH with minimal network configuration and infrastructure.
> 
> >>
> >> -------------
> >> -------------
> >> -------------
> >>
> >> Intro update:
> >>
> >>
> >>
> >> BEFORE
> >>
> >>
> >> --------------
> >>
> >> 1.  Requirements Language
> >>
> >>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
> >>  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
> this
> >>  document are to be interpreted as described in RFC 2119 [RFC2119].
> >>
> >> 2.  Introduction
> >>
> >>  The nodes in a IEEE 802.15.4 TSCH network follow a communication
> >>  schedule.  The entity (centralized or decentralized) responsible for
> >>  building and maintaining that schedule has precise control over the
> >>  trade-off between the network's latency, bandwidth, reliability and
> >>  power consumption.  During early interoperability testing and
> >>  development, however, simplicity is more important than efficiency.
> >>  One goal of this document is to define the simplest set of rules for
> >>  building a TSCH-compliant network, at the necessary price of lesser
> >>  efficiency.  Yet, this minimal mode of operation MAY also be used
> >>  during network bootstrap before any schedule is installed into the
> >>  network so nodes can self-organize and the management and
> >>  configuration information be distributed.  In addition, the minimal
> >>  configuration MAY be used as a fall-back mode of operation, ensuring
> >>  connectivity of nodes in case that dynamic scheduling mechanisms fail
> >>  or are not available.  The IEEE 802.15.4 specification provides a
> >>  mechanism whereby the details of slotframe length, timeslot timing,
> >>  and channel hopping pattern are communicated when a node time
> >>  synchronizes to the network [IEEE802154].  This document describes
> >>  specific settings for these parameters.
> >>
> >>
> >> ---------------------------
> >>
> >>
> >>
> >>
> >> AFTER
> >>
> >> --------------
> >>
> >>
> >> 1.  Introduction
> >>
> >>  A 6TiSCH Network provides IPv6 connectivity over a Non-Broadcast
> >>  Multi-Access (NBMA) mesh that is formed of IEEE 802.15.4
> >>  Timeslotted Channel Hopping (TSCH) links.
> >>
> >>  The 6TiSCH [I-D.ietf-6tisch-architecture] architecture requires the
> >>  use of both RPL and the 6LoWPAN adaptation layer framework
> >>  ([RFC4944], [RFC6282]) as defined over IEEE 802.14.5.
> >>  6LoWPAN Neighbor Discovery [RFC6775] (ND)  is also required to
> >>  exchange Compression Contexts,  form IPv6 addresses and register
> >>  them for the purpose of Duplicate Address Detection, Address
> >>  Resolution and Neighbor Unreachability detection over one
> >>  TSCH link.
> >>
> >>  Nodes in a IEEE 802.15.4 TSCH network follow a communication
> >>  schedule.  A network using the simple mode of operation uses a
> >>  static schedule.
> >>
> >>  This specification defines an operational parameters and procedures
> 
> s/an//
> 
> >>  for a minimal mode of operation to build a 6TiSCH  Network, using
> >>  the Routing Protocol for LLNs (RPL) and a static TSCH Schedule.
> 
> Either delete ", using the Routing Protocol for LLNs (RPL) and a static TSCH
> Schedule" or mention all the other protocols in use here, as well.
> 
> Do you want to mention the join process?  Security?
> 
> >> The 802.15.4 TSCH mode, the 6LoWPAN framework, RPL [RFC6550],
> >>  and its Objective Function 0 (OF0) [RFC6552], are used unmodified,
> >>  but  parameters and particular operations of TSCH and RPL are
> >>  specified  to guarantee interoperability between nodes in a 6TiSCH
> >>  Network.
> >>
> >>  More advanced work is expected in the future to complement the
> >>  Minimal Configuration with dynamic operations that can adapt the
> >>  Schedule to the needs of the traffic in run time.
> >>
> >>
> >> 2.  Requirements Language
> >>
> >>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
> >>  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
> this
> >>  document are to be interpreted as described in RFC 2119 [RFC2119].
> >>
> >> Pascal
> >
> > <signature.asc>_______________________________________________
> > 6tisch mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/6tisch
> 
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Tue, 5 Jan 2016 08:20:37 +0000

Dear Pascal,

Best wishes to  you and all  6TiSCH folk for 2016!

I support the new version of the abstract and Intro  of the minimal draft.
+1

Best Regards,
Maria Rita

-----Original Message-----
From: 6tisch [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: Monday, January 4, 2016 6:48 PM
To: 6tisch <[email-masked]>
Cc: Ralph Droms <[email-masked]>
Subject: Re: [6tisch] Consensus call on Summary of proposed resolution for issue 40 V3

Dear all:

--------------
Abstract

BEFORE

This document describes the minimal set of rules to operate an IEEE
802.15.4 Timeslotted Channel Hopping (TSCH) network.  This minimal mode of operation can be used during network bootstrap, as a fall- back mode of operation when no dynamic scheduling solution is available or functioning, or during early interoperability testing and development.

 ---------------
AFTER

This document describes a minimal mode of operation for a 6TiSCH Network, to provide IPv6 connectivity over a Non-Broadcast Multi-Access (NBMA) mesh that is formed of IEEE 802.15.4 Timeslotted Channel Hopping (TSCH) links.
 
This minimal mode uses a collection of protocols including the 6LoWPAN framework and RPL to enable interoperable IPv6 connectivity over IEEE 802.15.4 TSCH with minimal network configuration and infrastructure.

---------------
-------------
-------------
-------------

Intro update:

BEFORE

--------------

1.  Requirements Language

2.  Introduction

AFTER

--------------

1.  Introduction

    

2.  Requirements Language

Cheers,

Pascal

> (Moving discussion of the Abstract in "RE: [6tisch] #40 (minimal): 
> Ralph's INT AREA review on minimal" to this thread.)
> 
> 
> >> The proposed replacement for slotted aloha is subject to change 
> >> again in that phase J
> >>
> >> Please let us know;
> >
> >> This minimal mode uses a collection of protocols including the 
> >> 6LoWPAN framework and RPL to enable shared access operations over a 
> >> static TSCH schedule
> 
> framework and RPL to enable interoperable IPv6 connectivity over IEEE 
> 802.15.4 TSCH with minimal network configuration and infrastructure.
> 
> >>
> >> -------------
> >> -------------
> >> -------------
> >>
> >> Intro update:
> >>
> >>
> >>
> >> BEFORE
> >>
> >>
> >> --------------
> >>
> >> 1.  Requirements Language
> >>
> >>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 
> >> NOT",  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 
> >> in
> this
> >> schedule.  The entity (centralized or decentralized) responsible 
> >> for  building and maintaining that schedule has precise control 
> >> over the  trade-off between the network's latency, bandwidth, 
> >> reliability and  power consumption.  During early interoperability 
> >> testing and  development, however, simplicity is more important than efficiency.
> >>  One goal of this document is to define the simplest set of rules 
> >> for  building a TSCH-compliant network, at the necessary price of 
> >> lesser  efficiency.  Yet, this minimal mode of operation MAY also 
> >> be used  during network bootstrap before any schedule is installed 
> >> into the  network so nodes can self-organize and the management and  
> >> configuration MAY be used as a fall-back mode of operation, 
> >> ensuring  connectivity of nodes in case that dynamic scheduling 
> >> mechanisms fail  or are not available.  The IEEE 802.15.4 
> >> specification provides a  mechanism whereby the details of 
> >> slotframe length, timeslot timing,  and channel hopping pattern are 
> >> communicated when a node time  synchronizes to the network 
> >> [IEEE802154].  This document describes  specific settings for these parameters.
> >>
> >>
> >>  The 6TiSCH [I-D.ietf-6tisch-architecture] architecture requires 
> >> the  use of both RPL and the 6LoWPAN adaptation layer framework  
> >> Resolution and Neighbor Unreachability detection over one  TSCH 
> >> link.
> >>
> Either delete ", using the Routing Protocol for LLNs (RPL) and a 
> static TSCH Schedule" or mention all the other protocols in use here, as well.
> 
> >> The 802.15.4 TSCH mode, the 6LoWPAN framework, RPL [RFC6550],  and 
> >> its Objective Function 0 (OF0) [RFC6552], are used unmodified,  but  
> >> parameters and particular operations of TSCH and RPL are  specified  
> >> to guarantee interoperability between nodes in a 6TiSCH  Network.
> >>
> >>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 
> >> NOT",  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 
> >> in
> this

---

From: "S.V.R.Anand" <[email-masked]>
Date: Fri, 8 Jan 2016 18:51:06 +0530

Hi All,

I support the new version of the abstract and introduction of the 
minimal draft.

Anand

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 8 Jan 2016 18:01:57 +0000

Dear all:

We had a final call on this at the interim, and the text below is now adopted.
Xavi: can you please retrofit the text below in the minimal draft?
I created ticket 42 for you
https://trac.tools.ietf.org/wg/6tisch/trac/ticket/42 

Thanks in advance!

Pascal

-----Original Message-----
From: 6tisch [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: lundi 4 janvier 2016 18:48
To: 6tisch <[email-masked]>
Cc: Ralph Droms <[email-masked]>
Subject: Re: [6tisch] Consensus call on Summary of proposed resolution for issue 40 V3

Dear all:

--------------
Abstract

BEFORE

 ---------------
AFTER

---------------
-------------
-------------
-------------

Intro update:

BEFORE

--------------

1.  Requirements Language

2.  Introduction

AFTER

--------------

1.  Introduction

    

2.  Requirements Language

Cheers,

Pascal

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 8 Jan 2016 12:19:33 -0600

There are 2 typos in the "Introduction:
1) change "IEEE 802.14.5” to "IEEE 802.15.4”
2) change "Nodes in a IEEE 802.15.4 TSCH” to "Nodes in an IEEE 802.15.4 TSCH”

I would also suggest a clarification of the following to only refer to one type of a network:
"IEEE 802.15.4 TSCH nodes adhere to a communication schedule.  A 6TiSCH network using the simple mode of operation uses a static schedule."

Pat

On 8, Jan2016, at 12:01, Pascal Thubert (pthubert) <[email-masked]> wrote:

Dear all:

Thanks in advance!

Pascal

-----Original Message-----
From: 6tisch [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: lundi 4 janvier 2016 18:48
To: 6tisch <[email-masked]>
Cc: Ralph Droms <[email-masked]>
Subject: Re: [6tisch] Consensus call on Summary of proposed resolution for issue 40 V3

Dear all:

--------------
Abstract

BEFORE

---------------
AFTER

---------------
-------------
-------------
-------------

Intro update:

BEFORE

--------------

1.  Requirements Language

2.  Introduction

AFTER

--------------

1.  Introduction

2.  Requirements Language

Cheers,

Pascal

---

From: Xavier Vilajosana <[email-masked]>
Date: Sat, 9 Jan 2016 06:46:24 +0100

Dear Pascal, Pat,

I updated the current version of minimal in bitbucket. I addressed issue
#42 and Pat comments (thanks!).

let me know when to publish v14.

regards,
Xavi

2016-01-08 19:19 GMT+01:00 [email-masked] <
[email-masked]>:

> "IEEE 802.15.4 TSCH nodes adhere to a communication schedule.  A 6TiSCH
> network using the simple mode of operation uses a static schedule."
>
> Pat
>
>
> With my best wishes for a great year 2016, please find a reminder that we
> have a consensus (last) call running on the abstract and introduction of
> the minimal draft.
> In order to cope with the Year-End break, the call continues till next
> Friday. So far, all I've been seeing is consensus with the latest change
> that Ralph proposed.
> 802.15.4 Timeslotted Channel Hopping (TSCH) network.  This minimal mode of
> operation can be used during network bootstrap, as a fall- back mode of
> operation when no dynamic scheduling solution is available or functioning,
> or during early interoperability testing and development.
>
> ---------------
> AFTER
>
> This document describes a minimal mode of operation for a 6TiSCH Network,
> to provide IPv6 connectivity over a Non-Broadcast Multi-Access (NBMA) mesh
> that is formed of IEEE 802.15.4 Timeslotted Channel Hopping (TSCH) links.
>