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

2018-06-21 Thread Xavi Vilajosana Guillen 
 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) :

> 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 :
> > 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

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

2018-04-06 Thread Mirja Kuehlewind (IETF) 
Thanks. Looks good!

> Am 06.04.2018 um 18:24 schrieb Xavi Vilajosana Guillen :
> 
> 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 :
> 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