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

3.3.5.  Listing Cells

   When node B receives a LIST request, the returned CellList in the 6P
   Response contains between 1 and MaxNumCells cells,

Here you say "between 1 and MaxNumCells".

   starting from the
   specified offset.  Node B SHOULD include as many cells as fit in the
   frame.  If the response contains the last cell, Node B MUST set the
   Code field in the response to RC_EOL ("End of List", as per
   Figure 37), indicating to Node A that there no more cells that match
   the request.  Node B MUST return at least one cell, unless the
   specified Offset is beyond the end of B's cell list in its schedule.
   If node B has less than Offset cells that match the request, node B
   returns an empty CellList and a Code field set to RC_EOL.

And here you say that 0 is allowed. You should update the above to say
"between
0 and MaxNumCells".

XV: thanks for this catch. we fixed that. This was a left over from a
previous version.


kind regards
Xavi

2018-04-05 14:03 GMT+02:00 Alexey Melnikov <aamelni...@fastmail.fm>:

> Alexey Melnikov has entered the following ballot position for
> draft-ietf-6tisch-6top-protocol-11: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-6tisch-6top-protocol/
>
>
>
> ----------------------------------------------------------------------
> 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.
>
> 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.
>
> 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)?
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I am agreeing with Benjamin's DISCUSS about versioning. I think you need to
> describe in a bit more details which messages/parts of protocol should
> remain
> unchanged for forward compatibility with future versions.
>
> 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.
>
> 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.
>
> 3.3.5.  Listing Cells
>
>    When node B receives a LIST request, the returned CellList in the 6P
>    Response contains between 1 and MaxNumCells cells,
>
> Here you say "between 1 and MaxNumCells".
>
>    starting from the
>    specified offset.  Node B SHOULD include as many cells as fit in the
>    frame.  If the response contains the last cell, Node B MUST set the
>    Code field in the response to RC_EOL ("End of List", as per
>    Figure 37), indicating to Node A that there no more cells that match
>    the request.  Node B MUST return at least one cell, unless the
>    specified Offset is beyond the end of B's cell list in its schedule.
>    If node B has less than Offset cells that match the request, node B
>    returns an empty CellList and a Code field set to RC_EOL.
>
> And here you say that 0 is allowed. You should update the above to say
> "between
> 0 and MaxNumCells".
>
>
>


-- 
Dr. Xavier Vilajosana
Wireless Networks Lab

*Internet Interdisciplinary Institute (IN3)Professor*
(+34) 646 633 681
xvilajos...@uoc.edu <usu...@uoc.edu>
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
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Reply via email to