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: Thu, 21 Jun 2018 12:43:22 +0200

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

> 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:)..
> >
> > ----------------------------------------------------------------------
> > 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]
> > 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-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