Alvaro Retana has entered the following ballot position for draft-ietf-6tisch-msf-12: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-6tisch-msf/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (1) I support Roman's DISCUSS. (2) The datatracker should point at draft-chang-6tisch-msf being replaced by this document. (3) §2: "MSF RECOMMENDS the use of 3 slotframes." Why isn't this REQUIRED? How does an implementation signal to a neighboring node that a different number of slotframes are being used (or a different length, which is also RECOMMENDED later)? It seems to me that RECOMMENDING may not be enough for an interoperable implementation...but I may also be missing something in 802.15.4 or rfc8180 (or somewhere else). [BTW, the rfc2119 keyword is RECOMMENDED (not RECOMMENDS).] I think the use of RECOMMENDED (vs REQUIRED) may be related to this text a couple of paragraphs before: A node implementing MSF SHOULD implement the Minimal 6TiSCH Configuration [RFC8180], which defines the "minimal cell", a single shared cell providing minimal connectivity between the nodes in the network. The MSF implementation provided in this specification is based on the implementation of the Minimal 6TiSCH Configuration. However, an implementor MAY implement MSF based on other specifications as long as the specification defines a way to advertise the EB/DIO among the network. I understand that a configuration other than rfc8180 is possible, but if this document is based on rfc8180, then it would be clearer if the language was stronger (s/SHOULD/MUST) with the understanding that the specification refers to that case. (4) §4.3: While the exact behavior is implementation-specific, it is RECOMMENDED that after having received the first EB, a node keeps listen for at most MAX_EB_DELAY seconds until it has received EBs from NUM_NEIGHBOURS_TO_WAIT distinct neighbors, which is defined in [RFC8180]. rfc8180/§6.2 says that "after having received the first EB, a node MAY listen for at most MAX_EB_DELAY seconds until it has received EBs from NUM_NEIGHBOURS_TO_WAIT distinct neighbors." The use of RECOMMENDED here is not consistent with the optional nature of the MAY. (5) Nits... s/represents node's preferred parent/represents the node's preferred parent s/no restrictions to go multiple MSF sessions/no restrictions to use (?) multiple MSF sessions s/One of the algorithm met the rule/One of the algorithms that meet the rule s/Alternative behaviors may involved/Alternative behaviors may be involved s/when alternative security/when an alternative security s/node keeps listen/node keeps listening s/pairs of following counters/pairs of the following counters _______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
