Hi Alexey,
Please see inline. Thanks Qin -----原始邮件----- 发件人:"Alexey Melnikov" <[email protected]> 发送时间:2018-04-20 18:48:55 (星期五) 收件人: "Qin Wang" <[email protected]>, "Xavi Vilajosana Guillen" <[email protected]> 抄送: tisch <[email protected]>, "Pascal Thubert" <[email protected]>, [email protected], "The IESG" <[email protected]>, [email protected] 主题: Re: [6tisch] Alexey Melnikov's Discuss on draft-ietf-6tisch-6top-protocol-11: (with DISCUSS and COMMENT) Hi Qin, On Thu, Apr 19, 2018, at 9:51 PM, Qin Wang wrote: Hi Alexey, Thank you for your further comments. Please see inline. Qin On Thursday, April 12, 2018, 1:20:01 PM EDT, Alexey Melnikov <[email protected]> wrote: Hi Xavi, On Fri, Apr 6, 2018, at 4:39 PM, Xavi Vilajosana Guillen wrote: Dear Alexey, We are answering here the two emails we received from you. We want to thank you very much for the provided constructive review. Please, see inline our responses (prepended with XV:). The proposed changes will be published in v12 of the draft after addressing all received reviews. thanks again, Xavi ---------------------------------------------------------------------- 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. XV: See below please (what follows is your previous email) I am lost the context for this. But I can double check when a new revision is published. 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. XV: Thanks, we agree on the proposal. We propose the following text: "... Similarly, a node sending a 6P Response or a 6P Confirmation with an error code MUST NOT add, delete, relocate any cells as part of that 6P Transaction. If a node receives an unrecognized Response Code the 6P Transaction MUST be considered as failed. In a 3-step 6P Transaction, a 6P Confirmation with an unrecognized Response Code MUST be responded with a 6P Confirmation with RC_ERR return code and consider the transaction as failed. I am not entirely certain on a value in responding to an unrecognized error with another error (most other protocols just ignore that), but the rest seems good. Qin: RC_ERR is generic error code. An unrecognized Return Code should be considered as a kind of error. What do you think? I am just concerned that in the 3-step transaction you are adding 4th step just to convey to the sender that the last error code was not supported. An unrecognized error should already be treated as an error, so the transaction already failed at this point. Qin: I see your point. We update the paragraph as follows. “If a node receives an unrecognized return code the 6P Transaction MUST be considered as failed. In particular, in a 3 step 6P Transaction, a 6P Response with an unrecognized return code MUST be responded with a 6P Confirmation with return code RC_ERR and consider the transaction as failed. Defining what to do after an error has occurred is out of scope of this document. The SF defines what to do after an error has occurred.” What do you think? Defining what to do after an error has occurred is out of scope of this document. The SF defines what to do after an error has occurred. " 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)? XV: 6P Messages are filtered by SFID, this is, a receiver will process (and not respond RC_ERR_SFID) if it can match the SFID in the 6P header of the received message. If two nodes executing a transaction do not implement the same SF they will not be able to interop. We foresee future SFs that redefine the default format of these fields as presented by the current document. This however would not involve as far as we can understand any problem of interoperability as the changes will be self-contained in the particular SF. But a generic parser for these fields wouldn't be able to do that, unless it knows the format. I thought that is the point of defining their format. Maybe you can point me to an example on how such SF format might look like. Is there a draft/proposal in works already? Qin: For these fields, a parser is always associated with a specific SF. Some of SFs may use the default format defined in this document, while others may re-define the format of these fields. For example, a SF re-define the format of CellList. Instead of a list of (slotOffset, channelOffset), the format could be as follows. (StartCell, NumberOfCell, SlotIncrement, ChannelIncrement). For example, ((2,2), 3, 2,1), means the 3 cells (2,2), (4,3) (6,4) I think you need to make this very clear early in the document that this is your intent. I don't think this is wise, but this is just my (non blocking) preference. Qin: Add sentences in 3.2.3 and 3.2.4 to clarify. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [snip] 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. XV: We mean that NumCells cells will be deleted, any can be chosen. We rephrased the sentence as: "If the CellList in the 6P Request is empty, the SF on the receiving node SHOULD delete any NumCells cells from the sender, as long as they match the CellOptions field." My question is: if the implementation decides to follow the SHOULD, can it ignore arbitrary cells, even if they have the matching CellOptions field? Qin: See the updated paragraph at bottom 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? XV: this is to provide flexibility to node B. that is A proposes some cells (>NumCells) that can be deleted. Then B deletes exactly NumCells from the candidate set. I didn't think this was useful functionality, but if you think it is, I suggest you mention this in the document. Qin: See the updated paragraph at bottom The case where the CellList is not empty but contains less than NumCells cells is not supported. XV: We updated this text as well covering other reviewer comments. " 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. The case where the CellList is not empty but contains less than NumCells cells is not supported. RC_ERR_CELLLIST code MUST be returned when the CellList contains less than NumCells cells. " Qin: to address the two problems above, we rephrase as follows “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. The case where the CellList is not empty but contains fewer than NumCells cells is not supported. RC_ERR_CELLLIST code MUST be returned when the CellList contains fewer than NumCells cells. If the CellList is empty, the SF on the receiving node SHOULD choose any NumCells cells with the sender from its schedule, which match the CellOption field, and delete them. If the CellList contains more than NumCells cells, the SF on the receiving node has flexibility to choose exactly NumCells cells from the CellList to delete.” What do you think? This is much better. Thank you!
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
