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. > 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? > > > ----------------------------------------------------------------------> > 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? > > 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. > > 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.> " Best Regards, Alexey
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
