Subject: [6tisch] draft-dujovne-6tisch-on-the-fly-00

From: Thomas Watteyne <[email-masked]>
Date: Thu, 12 Dec 2013 19:33:52 -0800

general:

   - Currently, the 6top draft allows neighbors to negotiate soft cells,
   not bundles. For coherence across documents  I would suggest for the OTF
   draft strictly use the mechanisms that are present in drafts today. The OTF
   draft can contains a "wishlist" at the end, e.g. bundle reservation. Once
   this capability is introduced in 6top, OTF can be updated to take advantage
   of it.
   - I would argue that OTF changes the number of cells in a bundle. I
   don't believe the forwarding mechanism used (i.e. the "more" bit) should
   influence the OTF allocation policy. That is, the pre-allocation and
   post-allocation mechanisms might not needed.
   - The I-D clearly states that multiple algorithms can be used. Is there
   a way to know which algorithm is being used on a particular node?
   - Would it be possible to include a basic algorithm into the I-D?

minor.

   - The abstract talks about varying the number of cells. Are you
   considering this is the same as varying the number of cells *in a bundle*
   ?
   - I believe the statement "a set of them (i.e., a bundle)" is incorrect.
   One could add/remove multiple cells at once on a bundle that already
   exists; that set of cells is not itself a bundle.
   - Please do not use the term "link", which we have established has too
   many different meanings to be precise.
   - "OTF has not been designed for working with a specific scheduling
   algorithm nor with a well-defined set of statistics.". Do you mean "This
   draft is a general framework. The exact scheduling algorithm and set of
   statistics is out of scope of this document."
   - collisions between different pairs of nodes -> collisions between
   different pairs of neighbor nodes

trivial (*a* means add, **a** means delete, please Ctrl+F):

   - different scenario*s*
   - of **the** On-The-Fly (OTF) scheduling
   - satisfy different type*s* of constraints
   - extendible -> extensible
   - I would replace "will" by "is" wherever applicable
   - probability*.* There