Dear Mirja, thanks so much for your detailed review. We proceeded to address your remarks as commented below (XV:).
---------------------------------------------------------------------- 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). XV: thanks for this comment. We tried to improve the explanation for these elements as follow in section 3.2.3: "The contents of the 6P CellOptions bitmap apply to all elements in the CellList field. The possible values of the 6P CellOptions as per this specification include: TX = 1 (or 0) referring to a macTxType = TRUE (or macTxType = FALSE, repectively), in the macLinkTable as per IEEE 802.15.4 standard [IEEE802154]. RX = 1 (or 0) referring to a macRxType = TRUE (or macRxType = FALSE, repectively), in the macLinkTable as per IEEE 802.15.4 standard [IEEE802154]. S = 1 (or 0) referring to a macSharedType = TRUE (or macSharedType = FALSE, repectively), in the macLinkTable as per IEEE 802.15.4 standard [IEEE802154]. " 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... XV: thanks for this comment, we propose to rephrase the sentence as: "The CellOptions is sent unmodified to the ..." 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? XV: B Should send RC_ERR_CELLLIST. We clarified this in the text as follows: "If this is not the case, a Response with code RC_ERR is returned. If the cells in the received CellList in node B is smaller than NumCells, Node B MUST return a 6P Response with RC_ERR_CELLLIST code. Otherwise, node B's SF verifies which of the cells in the CellList it can install in node B's schedule, following the specified CellOptions field." 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? XV: As per another received review we updated the text as follows: "...RC_ERR_CELLLIST code MUST be returned when the CellList contains less than NumCells cells." 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 XV: We do not see any problem on having it here, but we are open to any consensus is taken regarding this registry. 2018-04-04 19:07 GMT+02:00 Mirja Kühlewind <[email protected]>: > 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 > -- Dr. Xavier Vilajosana Wireless Networks Lab *Internet Interdisciplinary Institute (IN3)Professor* (+34) 646 633 681 [email protected] <[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/6tisch
