Re: [6tisch] Alexey Melnikov's Discuss on draft-ietf-6tisch-6top-protocol-11: (with DISCUSS and COMMENT)
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 王沁 : > Hi Alexey, > > Please see inline. > > Thanks > Qin > > > -原始邮件- > *发件人:*"Alexey Melnikov" > *发送时间:*2018-04-20 18:48:55 (星期五) > *收件人:* "Qin Wang" , "Xavi Vilajosana Guillen" < > xvilajos...@uoc.edu> > *抄送:* tisch <6tisch@ietf.org>, "Pascal Thubert" , > 6tisch-cha...@ietf.org, "The IESG" , > draft-ietf-6tisch-6top-proto...@ietf.org > *主题:* 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 < > aamelni...@fastmail.fm> 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 CellOptio
Re: [6tisch] Alexey Melnikov's Discuss on draft-ietf-6tisch-6top-protocol-11: (with DISCUSS and COMMENT)
Hi Alexey, Please see inline. Thanks Qin -原始邮件- 发件人:"Alexey Melnikov" 发送时间:2018-04-20 18:48:55 (星期五) 收件人: "Qin Wang" , "Xavi Vilajosana Guillen" 抄送: tisch <6tisch@ietf.org>, "Pascal Thubert" , 6tisch-cha...@ietf.org, "The IESG" , draft-ietf-6tisch-6top-proto...@ietf.org 主题: 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 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 c
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 > 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,
Re: [6tisch] Alexey Melnikov's Discuss on draft-ietf-6tisch-6top-protocol-11: (with DISCUSS and COMMENT)
Hi Alexey, Thank you for your further comments. Please see inline. Qin On Thursday, April 12, 2018, 1:20:01 PM EDT, Alexey Melnikov 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? 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 thesefields, a parser is always associated with a specific SF. Some of SFs may usethe default format defined in this document, while others may re-define theformat of these fields. For example, a SF re-define the format of CellList.Instead of a list of (slotOffset, channelOffset), the format could be asfollows. (StartCell, NumberOfCell,SlotIncrement, ChannelIncrement). For example, ((2,2), 3, 2,1), means the 3 cells (2,2), (4,3)(6,4) -- 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 NumCell
Re: [6tisch] Alexey Melnikov's Discuss on draft-ietf-6tisch-6top-protocol-11: (with DISCUSS and COMMENT)
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 prov
Re: [6tisch] Alexey Melnikov's Discuss on draft-ietf-6tisch-6top-protocol-11: (with DISCUSS and COMMENT)
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) 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. 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. -- COMMENT: -- 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. XV: thanks for this comment. We have changed the MAY to may as suggested. We agree with your point. 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." 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. 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
