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

From: Xavi Vilajosana Guillen <[email-masked]>
Date: Fri, 6 Apr 2018 18:24:21 +0200

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

> 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-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>

-- 
Dr. Xavier Vilajosana
Wireless Networks Lab

*Internet Interdisciplinary Institute (IN3)Professor*
(+34) 646 633 681
[email-masked] <[email-masked]>
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

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Fri, 6 Apr 2018 18:55:07 +0200

Thanks. Looks good!

> Am 06.04.2018 um 18:24 schrieb Xavi Vilajosana Guillen <[email-masked]>:
> 
> Dear Mirja,
> 
> thanks so much for your detailed review. We proceeded to address your remarks as commented below (XV:)..
> 
> Thanks for the well-written and easy to read document. Only section 3.2.3. is a
> 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.
> 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].
> "                    
> 
> 1) sec 3.2.3: "The CellOptions is an opaque set of bits, sent unmodified to the
> SF.
>    Not sure you can say that the celloptions bits are opaque given you define
>    them in this section...
> 
> What happens if that is not the case. Should node B assign the requested cells
> "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."
> 
> "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?
> 
> "...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
> XV: We do not see any problem on having it here, but we are open to any consensus is taken regarding this registry. 
> 
> 
> Thanks for the well-written and easy to read document. Only section 3.2.3. is a
> 1) sec 3.2.3: "The CellOptions is an opaque set of bits, sent unmodified to the
> SF.
>    Not sure you can say that the celloptions bits are opaque given you define
>    them in this section...
> 
> 2) In sec 3.3.1:
> What happens if that is not the case. Should node B assign the requested cells
> "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
> Internet Interdisciplinary Institute (IN3)
> Professor
> (+34) 646 633 681
> [email-masked]
> http://xvilajosana.org
> http://wine.rdi.uoc..edu