Thank you, Tengfei and the other authors, for the update! Here are my comments:
[Major] Negotiated RX cell (Section 4.6) https://tools.ietf.org/html/draft-ietf-6tisch-msf-04#section-4.6 If MSF is designed for regular upstream traffic, I don't think we need the negotiated RX cell that is introduced by this new version. I presume the purpose of the negotiated RX cell is, to have a collision-free channel directed from parent to child. The parent may have collisions on the autonomous TX cell to a node since children of the node also use the cell to transmit their frames. However, once the network converges, the children have negotiated TX cells to the node. The parent of the node will be the only one who uses the autonomous TX cell until a topological change happens. I would rather keep unused cells in the slotframe for negotiated TX cells to handle "regular upstream traffic" instead of using some of them for negotiated RX cells (to receive frames from the parent). I'm looking forward to seeing Tengfei's evaluation results, by the way :-) [Minor] AutoTxCell usage (Section 3) https://tools.ietf.org/html/draft-ietf-6tisch-msf-04#section-3 Sorry for bringing this again and again, but *in general*, L2/TSCH layer has no idea about its upper layers. Although you can implement a 6TiSCH stack in which TSCH is aware of upper layer contents of a frame to transmit, that may not be always the case. That is, the second bullet point, starting with "frame is used for...", may not be able to be implemented. In this sense, applying "MUST" to the second bullet point seems too strict. draft> AutoTxCell is not permanent in the schedule but added/deleted on draft> demand when there is a frame to sent. Throughout the network draft> lifetime, nodes MUST maintain the autonomous cells as follows: draft> draft> o Add an AutoTxCell to the layer 2 source address which is indicated draft> in a frame when: draft> draft> * there is no 6P negotiated Tx cell in schedule for that frame to draft> transmit, and draft> * the frame is used for protocol management purposes , such as draft> Join Request/Response, 6P Request/Response and any link-local draft> communication for RPL routing control. [Minor] Unprotected frames on negotiated cells? (Section 5.1) https://tools.ietf.org/html/draft-ietf-6tisch-msf-04#section-5.1 draft> Both NumCellsElapsed and NumCellsUsed counters can be used to draft> negotiated cells with cell option TX=1 or Rx=1. All the frames used draft> for increasing/decreasing the counters MUST be encrypted or draft> decryptable with the key get from joining process. Will we have unprotected frames transmitted on negotiated TX/RX cells, which are expected to be scheduled with *joined* nodes? I'm not sure why the last sentence is necessary... [Minor] Length of CellList (Section 8) https://tools.ietf.org/html/draft-ietf-6tisch-msf-04#section-8 What should a node do when it receives a CellList shorter than 5? Return RC_ERR_CELLLIST? draft> 8. Rules for CellList draft> draft> MSF uses 2-step 6P Transactions exclusively. 6P Transactions are draft> only initiated by a node towards its preferred parent. As a result, draft> the cells to put in the CellList of a 6P ADD command, and in the draft> candidate CellList of a RELOCATE command, are chosen by the node draft> initiating the 6P Transaction. In both cases, the same rules apply: draft> draft> o The CellList SHOULD contain 5 or more cells. [Trivial] Section 3. Autonomous Cells https://tools.ietf.org/html/draft-ietf-6tisch-msf-04#section-3 draft> o The AutoRxCell MUST always remain scheduled. *Always* is ambiguous. A node cannot schedule an AutoRxCell until it's get synchronized, when the length of slotframe 1 is available. [Trivial] nits / editorial - "AutoUpCells" is still there - s/behvaior/behavior/ - s/boostrap/bootstrap/ - s/sheduling/scheduling/ - s/negoitated/negotiated/ - s/neogtiated/negotiated/ - s/transcation/transaction/ - s/calulated/calculated/ That's all! Yatch _______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch