Reviewer: Alexander Pelov Review result: Ready with Issues Hello all, This is the review for the IoT Directorate. Document: draft-ietf-6tisch-6top-protocol-09 Reviewer: Alexander Pelov Date: 22 February 2018 The general feeling of the reviewer is that the document is a solid work. Multiple examples are given and the document is easy to understand as a whole. There are some nits, and some text that need to be clarifier. The general feeling of the reviewer is that the document relies heavily on the definition of an external Scheduling Function (SF). The recommended values seem very reasonable to the reviewer and it is not clear what is the benefit of anticipating that an SF can override the semantics of most of the fields. For example, most of the fields are opaque to the 6P sublayer and only make sense to the SF : CellOptions, Metadata, CellList. For one, in Wireshark, there will be the need for separate disector for each SF. A final point here is that there seem to be no readily available polished SF that would help in the understanding of the concepts beyond what is already on the 6P draft. For example, the SF0 draft (draft-ietf-6tisch-6top-sfx-00) redefines quite heavily the behavior of CellList introducing notion of WhiteList and BlackList of cells. The reviewer is aware that these are distinct works, but it feels that there should be a minimum level of interoperability, where an upper layer does not completely redefine what is happening on lower layers. Having extension mechanisms may seem like a better way to solve richness of proposals if this is necessary. One point which remained unclear is how do the Minimal 6TiSCH and 6P interact? It could be useful to provide a description on the bootstrap of 6P interaction (how does a sender A initiate the first 6P Request - over Minimal 6TiSCH-managed cell?). How do they enter in play in case of de-synchronisation ? (e.g. A rescheduling all 6P cells, but B not getting the final L2 ACK, which puts A's 6P cells on a completely different schedule than B's.. so B can't signal back transaction rollback / CLEAR). Is this solved by 6TiSCH minimal or through a different mechanism? The Security section could be enriched. A notable example is the handling of resource reservation, which could lead to DOS attacks. - - - - - - - - - - - - - - - Section 3.2.3: 6P CellOptions - ends with the statement that it is an "Opaque set of bits", which MAY be redefined by the SF (format, meaning). As pointed out earlier, if there is a need to redefine this for each SF, maybe there are other ways of defining such flexibility (e.g. TLVs). The table in Figure 7 provides the recommended meaning of the bitmap for 6P COUNT and 6P LIST. What is the recommended meaning for 6P ADD/DELETE/RELOCATE? Nits: there seems to be errors in Figure 7: examples of "all cells are marked as RX" and "all cells are marked as TX" seem inverted (same for TX=1,RX=0,S=1 and TX=0,RX=1,S=1). - - - - - - - - - - - - - - - Section 3.3.1: How does the sender/receiver know the size of CellList? (infer from packet size?) The candidate cells (a total of NumCandidate) are presumably provided by the SF. However, it is up to 6P to handle the case when they do not fit in the packet size. The text specifies that this should be handled in more than one 6P ADD requests - which is OK on the conceptual level, but seems underspecified for an implementation. What if NumCells is smaller than the number of candidate cells that can fit in a single transaction - should they be also split in two transactions? What happens if the first 6P ADD is successful, but the second one fails? Should the sender 6P DELETE the successfully added first batch of cells? Can allocation of 0 cells be considered as partial success? NOALLOC return code is not defined. - - - - - - - - - - - - - - - Section 3.3.3. Figure 17 - it seems counterintuitive to have RC_SUCCESS on failed relocation. Could NOALLOC be used in this case? In both Relocation and Allocation 3-step 6P transaction there is the risk of a security attack. If a malicious node constantly renews 3-step requests and never acknowledges, the neighboring node will be keeping the proposed cells as "reserved" and not allocate them to other nodes, thus provoding a DOS attack. Probably a way to limit repeated requests could be useful for this case. - - - - - - - - - - - - - - - Section 3.3.5. "To retrieve the list of scheduled cells at B" - all cells scheduled at B? Or the cells scheduled for A? (could be clarified) Nits: Node B MAY returns -> Node B MAY return - - - - - - - - - - - - - - - Section 3.3.6. There may be two parallel transactions: 1) A->B and 2) B->A. If a 6P CLEAR is issued on one, how does this affect the other? (presumably clear both?) How does this affect separate SF? If there is a state kept by each SF, are all SFs cleared? Are statistics also cleared for SFs? (probably SF-dependent, out of the scope) - - - - - - - - - - - - - - - Section 3.4.6. Figure 27: "Clear or Reset" - Reset could be ambiguous (device has restarted vs transaction failed, RC_RESET) - - - - - - - - - - - - - - - Section 6.2.5. Consider having Specification required for the range SFID 128-255. - - - - - - - - - - - - - - - Section 6.2.4. It would have seem more readable to have RC_ERR_ prefix for errors. It may not be outright evident that RC_CELLLIST or RC_VERSION is an error. - - - - - - - - - - - - - - - Overall a rich document, with probably some minor changes to be made. Best, Alexander
