Dear Georgios, thanks so much for your detailed review. Let me answer inline.
The fixes will appear in a next version of the draft. kind regards Xavi 2018-04-09 11:26 GMT+02:00 Georgios Z. Papadopoulos < [email protected]>: > 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. > XV: I would say now (fixing the traffic) “It is well-known that, for a given network traffic, the smaller the guard time, the smaller the tolerated drift between two nodes, and hence the more precise their synchronization.” > > > > —— > “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. > > XV: What if the network has an inherent mechanism that compensates the drift and hence nodes are always perfectly synchronized? I agree that this may be an edge case and the normal case is that nodes poll periodically the time source. Does it hurt however to have that mechanism as optional? > —— > "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? > > XV: see above. > > —— > “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? > > XV: see above. > > —— > 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," > XV: fixed that.Thx! > > * “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”. > > XV: fixed that.Thx! > * e.g., or e.g. > GP: you may want to uniformalize it > > XV: fixed that.Thx! > Best, > Georgios > > > _______________________________________________ > 6tisch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6tisch > > -- Dr. Xavier Vilajosana Wireless Networks Lab *Internet Interdisciplinary Institute (IN3)Professor* (+34) 646 633 681 [email protected] <[email protected]> http://xvilajosana.org http://wine.rdi.uoc.edu Parc Mediterrani de la Tecnologia Av Carl Friedrich Gauss 5, B3 Building 08860 Castelldefels (Barcelona). Catalonia. Spain [image: Universitat Oberta de Catalunya]
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
