Thanks a lot for the reviewing, I responded inline: On Mon, Nov 25, 2019 at 6:42 PM Pascal Thubert (pthubert) < pthub...@cisco.com> wrote:
> Dear all > > > > Please find some comments below: > > > > > > > > > > Please migrate to XML2RFC v3. This will save time in the future. > TC: got it! Will used in version 9. > > > > > > > However, an implementor MAY implement MSF without implementing > > Minimal 6TiSCH Configuration. > > > > > > This is not helpful without explanations. What is the tradeoff? How does > the network operates in that case? > TC: Yes, the sentence is misleading. What we try to say is MSF can work with other specifications protocols, rather then minimal 6TiSCH configuration, as long as the protocols gives a way to communicate the EB and DIO among the network. > > > > > > > > > For example, a Trickle Timer defined in > > [RFC6550 <https://tools.ietf.org/html/rfc6550>] MAY be applied on DIOs. > However, this behavior is > > implementation-specific which is out of the scope of MSF. > > > > > > This is not for this spec to define. RPL already mandates trickle. > Suggestion: > > > > For example, the Trickle operation defined in [RFC6206] > > is applied on DIO Messages [RFC6550 <https://tools.ietf.org/html/rfc6550>]. > This behavior is > > out of the scope of MSF. > > > > TC: agreed! > > > > > > > > > MSF RECOMMENDS the use of 3 slotframes. > > > > Discussion on slotframes and cells comes without an introduction to TSCH. > > I’d suggest you add a few words on RFC 7554 appendix A and 6TiSCH > architecture section 4.3.5. to introduce those concepts. > > They should probably be normative references. > TC: I added the following text at beginning of section 2: In a TSCH network, time is sliced up into time slots. The time slots are grouped as one of more slotframes which repeat over time. The TSCH schedule instructs a node what to do at each time slots, such as transmit, receive or sleep <xref target="RFC7554"/>. In case of a slot to transmit or receive, a channel is assigned to the time slot. The tuple (slot, channel) is indicated as a cell of TSCH schedule. MSF is one of the policies defining how to manage the TSCH schedule. > > > > > > > > > Section 4 has numerous SHOULD. Trouble is, when SHOULD is used, the author > SHOULD explain the alternate, what if the SHOULD is not followed. > > Sometimes it’s quite obvious, like when using random in 4.2. But SHOULD > use minimal is less obvious. Please consider adding text after the SHOULDs. > TC: agreed! I have resolved this SHOULD issues in a new version. either the unnecessaries are removed or alternative explanation is added > > > > > > > field it contains, the presence and contents of the IE defined in > > [I-D.richardson-6tisch-join-enhanced-beacon > <https://tools.ietf.org/html/draft-ietf-6tisch-msf-08#ref-I-D.richardson-6tisch-join-enhanced-beacon>], > or the key used to > > authenticate it. > > > > The reference is now draft-ietf.. I agree that it should be normative; no > worries the draft is already submitted for publication. > > More important: Please move the reference to > 6tisch-dtsecurity-zerotouch-join to informational. This is a DOWNREF today > and your draft may be stuck in MISSREF in the future. > TC: I have updated *richardson-6tisch-join-enhanced-beacon* to * ietf-6tisch-enrollment-enhanced-beacon.* I didn't get it how "*move the reference to 6tisch-dtsecurity-zerotouch-join to informational*" is done in the draft? > > > > > > After selected a preferred parent, the joined node MUST generate a 6P > > > > Grammar: “After selecting” or “once it has selected” sound better. > > > TC: the latter sounds better! Thanks! > > > > > Section Section 8 > <https://tools.ietf.org/html/draft-ietf-6tisch-msf-08#section-8> > > > > The <xref …> already generates the word “section”.. If you write it too, it > becomes duplicated as above. > TC: agreed! > > > > > > > For a node, this translates into > > monitoring the current usage of the cells it has to its preferred > > parent: > > > > This is disturbing. MSF should not be used only with preferred parents. > The whole game of doing a DODAG is to have and possibly use multiple > parents. > > A node can for instance send a NSM DAO with multiple transit options to > the root. Also, it could be good to clarify that the child manages both > directions. > > Proposal: > > > > For a node, this translates into > > monitoring the current usage of the cells it has to the parents it uses > > at this point of time for sending and receiving traffic: > > > > Later there a numerous references to “preferred parent” => I’d suggest you > use just “selected parent” or “active parent” or something in that vein. > TC: I think "preferred parent" is same with "selected parent". it indicates one preferred parent out of multiple. Isn't it right? > > > > > > Cell installed at initial > > > > Not sure this is correct. Maybe “at init time” > TC: Applied! > > > > > > > > > It is recommended to set MAX_NUMCELLS value at > > least 4 times than the maximum link traffic load of the network in > > packets per slotframe. > > > > > > This does not parse. Can you please rephrase? > TC: it's rephrased as "*It is recommended to set MAX_NUMCELLS value at least 4x of the maximum link traffic load of the network with unit of packets per slotframe*." > > > > > > > > > Section 8 does not try to avoid collisions with autocells. But it’s easy > to compute the slot offset of autocells for self and parent and avoids > those. Why not do that? > TC: agreed! Will apply in the next version. > > > > > > > Section 16 will require more attention, either now or during secdir > review, probably both. You should start now. Think, say, what if an > attacker claims many cells to all its neighbors? Can it attack someone’s > autocells to block him? > TC: That's a good question! It may have a chance to do so. We need discuss internally on this section. Thanks for belling ahead! > > > > > > > Voila! > > > > Pascal as shepherd. > > > > > > > > > > > > > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > -- —————————————————————————————————————— Dr. Tengfei, Chang Postdoctoral Research Engineer, Inria www.tchang.org/ ——————————————————————————————————————
_______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
