Hello Xavi: I’m not asking for any change change but editorials. In particular I do not see a need to say that minimal could be disabled. Anything can be disabled, it’s always an admin decision to implement a protocol. The important thing is that minimal does not preclude the use of other TSCH traffic on other timeslots.
As I reread the draft, I have some editorial suggestions, feel free to pick or not: “bitmap in the active cell indicate that a node” -> indicates? “This results in ‘’Slotted Aloha’’ behavior” -> This results in a behavior that is similar to that of ‘’Slotted Aloha’’. “acknowledgement” -> acknowledgment “neighbour” -> neighbor “EBs MUST NOT be used for time” -> EBs are not used for time “rank” -> Rank (when talking about RPL’s Rank) “Routing extension headers such as RPI and SRH and inner IP headers MUST be compressed according to [RFC6282], [I-D.ietf-6lo-routing-dispatch] and [I-D.ietf-6lo-paging-dispatch].” -> “ Routing extension headers such as RPI [RFC6550] and SRH [RFC6554], and outer IP headers in case on encapsulation MUST be compressed according to [I-D.ietf-6lo-routing-dispatch] and [I-D.ietf-6lo-paging-dispatch]. “ Also: [I-D.ietf-6lo-routing-dispatch] and [I-D.ietf-6lo-paging-dispatch] should be normative references. Should not delay minimal if we last call soon. Take care, Pascal
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
