Dear Mirja, today we published a new version of the draft including the changes mentioned in our responses.
thanks for your reviews. Xavi 2018-04-06 18:55 GMT+02:00 Mirja Kuehlewind (IETF) <[email protected]>: > Thanks. Looks good! > > > Am 06.04.2018 um 18:24 schrieb Xavi Vilajosana Guillen < > [email protected]>: > > > > 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] > > 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 > > > > -- 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
