Alexey Melnikov has entered the following ballot position for draft-ietf-6tisch-6top-protocol-11: No Record
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-6top-protocol/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I haven't finished reading the document, so I am sending the comments I've accumulated so far. I am agreeing with Benjamin's DISCUSS about versioning. Additionally: 3.2.2. Generic 6P Message Format 6P Version (Version): The version of the 6P protocol. Only version 0 is defined in this document. Future specifications MAY define further versions of the 6P protocol. Use of MAY in the last sentence doesn't seem correct, as there is no way to test conformance to it. I suggest you just change it to lowercase "may" and add boilerplate to reference RFC 8174 in addition to RFC 2119. 3.3.2. Deleting Cells o If the CellList in the 6P Request is empty, the SF on the receiving node SHOULD delete any cell from the sender, as long as Did you mean "all" instead of "any"? it matches the CellOptions field. o The CellList in a 6P Request (2-step transaction) or 6P Response (3-step transaction) MUST either be empty, contain exactly NumCells cells, or more than NumCells cells. What is the meaning of "more than NumCells cells" in case of DELETE? The case where the CellList is not empty but contains less than NumCells cells is not supported. 3.3.5. Listing Cells When node B receives a LIST request, the returned CellList in the 6P Response contains between 1 and MaxNumCells cells, Here you say "between 1 and MaxNumCells". starting from the specified offset. Node B SHOULD include as many cells as fit in the frame. If the response contains the last cell, Node B MUST set the Code field in the response to RC_EOL ("End of List", as per Figure 37), indicating to Node A that there no more cells that match the request. Node B MUST return at least one cell, unless the specified Offset is beyond the end of B's cell list in its schedule. If node B has less than Offset cells that match the request, node B returns an empty CellList and a Code field set to RC_EOL. And here you say that 0 is allowed. You should update the above to say "between 0 and MaxNumCells". _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
