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. > >> 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. >> >> --------------------------------------------------------------- >> ------->> 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
