Subject: Re: [6tisch] Alexey Melnikov's Discuss on draft-ietf-6tisch-6top-protocol-11: (with DISCUSS and COMMENT)

From: Xavi Vilajosana Guillen <[email-masked]>
Date: Thu, 21 Jun 2018 12:44:40 +0200

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-masked]>:

> Hi Alexey,
>
> Please see inline.
>
> Thanks
> Qin
>
>
> -----原始邮件-----
> *发件人:*"Alexey Melnikov" <[email-masked]>
> *发送时间:*2018-04-20 18:48:55 (星期五)
> *收件人:* "Qin Wang" <[email-masked]>, "Xavi Vilajosana Guillen" <
> [email-masked]>
> *抄送:* tisch <[email-masked]>, "Pascal Thubert" <[email-masked]>,
> [email-masked], "The IESG" <[email-masked]>,
> [email-masked]
> *主题:* 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-masked]> 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-masked] <[email-masked]>
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