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

["S.V.R.Anand" <[e-mail]>]

Hi All,

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

Anand

On Monday 04 January 2016 11:17 PM, Pascal Thubert (pthubert) wrote:
> 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:[e-mail]] On Behalf Of Ralph Droms
>> Sent: vendredi 18 décembre 2015 17:24
>> To: 6tisch <[e-mail]>
>> 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)
>> <[e-mail]> 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) <[e-mail]>
>>> Cc: [e-mail]
>>> Subject: Re: Summary of proposed resolution for issue 40 V3
>>>
>>>
>>>> On Dec 14, 2015, at 11:16 AM 12/14/15, Pascal Thubert (pthubert)
>> <[e-mail]> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/6tisch
>> _______________________________________________
>> 6tisch mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/6tisch
> _______________________________________________
> 6tisch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6tisch


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