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. _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
