+1
Just one comment. Since CLEAR may be useful to several SFs which may be
active, in future,
perhaps a generic or a wildcard CLEAR message that can address
potentially multiple SF
listeners can help in avoiding separate messages going from individual SFs.
Anand
On Tuesday 22 November 2016
+1 much needed
Regards,
Pascal
Le 23 nov. 2016 ? 22:11, Qin Wang
mailto:qinwang6...@yahoo.com>> a ?crit :
+1
Qin
On Tuesday, November 22, 2016 2:17 AM, Thomas Watteyne
mailto:thomas.watte...@inria.fr>> wrote:
In thread "Node Behavior at Boot in SF0"
(https://www.ietf.org/mail-archive/w
+1
Qin
On Tuesday, November 22, 2016 2:17 AM, Thomas Watteyne
wrote:
In thread "Node Behavior at Boot in SF0"
(https://www.ietf.org/mail-archive/web/6tisch/current/msg04883.html), we ended
up discussing the following paragraphÂ
https://tools.ietf.org/html/draft-ietf-6tisch-6top-sf0-0
I agree witb Yatch: On Step 1, keep the original CLEAR command at
boot time.
Step 2 is OK for me:
In fact, the only way SF0 would detect that the node is
no longer available or that RPL has decided a parent change
is that there will be no more effectively used cells towards
that neighbour, so only
Hi all,
Here is my opinion:
step 1: one suggestion to keep the original sentence explaining what
to do in SF0 after the system booting-up or restart. That is,
no change on draft-ietf-6tisch-6top-sf0-02#section-10.
step 2: +1
Thanks!
Yatch
On 2016/11/22 8:16, Thomas Watteyne wr
un...@ietf.org] *On Behalf Of *Thomas
> Watteyne
> *Sent:* 22 November 2016 12:47
> *To:* 6tisch@ietf.org
> *Subject:* [6tisch] [6P+SF0] CALL FOR CONSENSUS: sending a CLEAR request
> to old parents
>
>
>
> In thread "Node Behavior at Boot in SF0" (https://www.
+1
The clear command will be useful at implementation point of view.
Thanks & Regards,
Lijo Thomas
From: 6tisch [mailto:6tisch-boun...@ietf.org] On Behalf Of Thomas Watteyne
Sent: 22 November 2016 12:47
To: 6tisch@ietf.org
Subject: [6tisch] [6P+SF0] CALL FOR CONSENSUS: sen
In thread "Node Behavior at Boot in SF0" (
https://www.ietf.org/mail-archive/web/6tisch/current/msg04883.html), we
ended up discussing the following paragraph
https://tools.ietf.org/html/draft-ietf-6tisch-6top-sf0-02#section-10:
In order to define a known state after the node is restarted, a C
