Dear Alexey, today we published a new version of the draft including the changes mentioned in our responses.
thanks for the provided reviews. Xavi 2018-04-20 17:48 GMT+02:00 王沁 <[email protected]>: > 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! > > -- Dr. Xavier Vilajosana Wireless Networks Lab *Internet Interdisciplinary Institute (IN3)Professor* (+34) 646 633 681 [email protected] <[email protected]> http://xvilajosana.org http://wine.rdi.uoc.edu Parc Mediterrani de la Tecnologia Av Carl Friedrich Gauss 5, B3 Building 08860 Castelldefels (Barcelona). Catalonia. Spain [image: Universitat Oberta de Catalunya]
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
