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

From: Alexey Melnikov <[email-masked]>
Date: Thu, 05 Apr 2018 05:03:45 -0700

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