Hello Xavi and co-authors,

Many thanks for such draft. It is indeed something that we were missing here.
I found some time to go through, and below you will find my comments/questions:


—— 
“It is well-known that the smaller the guard time, the smaller the tolerated 
drift between two nodes, and hence the more precise their synchronization.”

GP: the last part of this sentence (“and hence the more precise their 
synchronization.") is not always true, isn’t it?
It is true when you are having very frequent Keep Alive and EB transmissions, 
otherwise, the smaller the guard time, the higher the probability of 
desynchronization between the two devices.


—— 
“Optionally, periodic refresh messages can be issued by the 6TiSCH node to the 
node that acts as global time source, through a provided CoAP URI exposing the 
time service.”

GP: I am wondering whether such periodic refresh message should be Optional or 
Default to cope with potential drifts.


—— 
"An optional gt_lease value in days indicating the mandatory refresh period MAY 
be present."

GP: again, considering the potential drifts, do you think the refresh period 
should be Optional and not included by Default?


—— 
“If this value is 0, a node does not refresh the global time information.”

GP: any use-case where a node does not need to refresh?


——
Some minor typos: 

"This time is relative to the moment the network started or reset and hence 
cannot be used to compare tagged events from different networks.”
GP: "and hence" I would assume, it would need a comma : —> "and, hence,"

* “The global time reference is a a mapping between the ASN of the network and 
the global time at the moment of processing the Join Response.”
GP: remove the extra “a”.

* e.g., or e.g.
GP: you may want to uniformalize it.


Best,
Georgios

_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Reply via email to