Thanks. Looks good! > Am 06.04.2018 um 18:24 schrieb Xavi Vilajosana Guillen <xvilajos...@uoc.edu>: > > 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 <i...@kuehlewind.net>: > 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 > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > > > > -- > Dr. Xavier Vilajosana > Wireless Networks Lab > Internet Interdisciplinary Institute (IN3) > Professor > (+34) 646 633 681 > xvilajos...@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 >
_______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
