[6tisch] MSF Shepherd review

["Pascal Thubert (pthubert)" <[e-mail]>]

Dear all

Please find some comments below:




Please migrate to XML2RFC v3. This will save time in the future.



   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?





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.







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.




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.




   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.




   After selected a preferred parent, the joined node MUST generate a 6P

Grammar: "After selecting" or "once it has selected" sound better.




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.




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.



Cell installed at initial


Not sure this is correct. Maybe "at init time"





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?




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?



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?



Voila!

Pascal as shepherd.