Alexey Melnikov has entered the following ballot position for draft-ietf-6tisch-6top-protocol-11: Discuss
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/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thank you for a well written document. I have a small list of questions/comments, which I would like to discuss before recommending approval of this document: 1) 3.3.2. Deleting Cells 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. 2) 3.4.7. Handling Error Responses How should unrecognized error codes be treated by recipients? For example if one of the nodes is implementing an extension and the other node doesn't support such extension. I think adding some text to this section would help. 3) 4.2. Requirements for an SF o MAY redefine the format of the CellList field. o MAY redefine the format of the CellOptions field. o MAY redefine the meaning of the CellOptions field. I am a concerned about interoperability problems that might result from these requirements. Can you elaborate on what kind of format changes you are expecting? Wouldn't such changes require some sort of extension (e.g. use of a new extended ADD command)? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I am agreeing with Benjamin's DISCUSS about versioning. I think you need to describe in a bit more details which messages/parts of protocol should remain unchanged for forward compatibility with future versions. 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. 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
