Subject: [6tisch] Mirja Kühlewind's No Objection on draft-ietf-6tisch-6top-protocol-11: (with COMMENT)

From: Mirja Kühlewind <[email-masked]>
Date: Wed, 04 Apr 2018 10:07:34 -0700

Mirja Kühlewind has entered the following ballot position for
draft-ietf-6tisch-6top-protocol-11: No Objection

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/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for the well-written and easy to read document. Only section 3.2.3. is a
bot confusing as TX, RX, and S show up in the table but are not really
explained at all (besides in the IANA considerations at the very end).

Some more, mostly editorial comment:

1) sec 3.2.3: "The CellOptions is an opaque set of bits, sent unmodified to the
SF.
   The SF MAY redefine the format and meaning of the CellOptions field."
   Not sure you can say that the celloptions bits are opaque given you define
   them in this section...

2) In sec 3.3.1:
"NumCandidate MUST be larger or equal to NumCells."
What happens if that is not the case. Should node B assign the requested cells
anyway, or send an error, or both?

and also in section 3.3.2:
"The case where the CellList is not empty but contains less than NumCells cells
is not supported." What does that mean? Should an error be sent or the message
just ignored?

3) Not sure if the "6P Version Numbers" registry is really needed at this point
of time. I guess if many new versions show up, it would still be time to create
this registry with the next version.