Re: [Roll] Éric Vyncke's Discuss on draft-ietf-roll-aodv-rpl-10: (with DISCUSS and COMMENT)

[Charlie Perkins <[e-mail]>]

Hello Éric,

Please excuse the unusually long delay it has taken for us to respond to 
your comments.

Regarding the following:

 >  Éric Vyncke Discuss
 > Discuss (2021-04-21)

 > Thank you for the work put into this document. I seems that all cases
 > have been thought of :-) Good job! and having a shorter path between
 > two RPL nodes can be benefitial of course.

 > Please find below one blocking (but probably trivial to fix) DISCUSS
 > point, some non-blocking COMMENT points (but replies would be
 > appreciated), and some nits.

 > Special thanks to Peter Van der Stock for the IoT directorate review:
 > 
https://datatracker.ietf.org/doc/review-ietf-roll-aodv-rpl-10-iotdir-telechat-van-der-stok-2021-04-15/

 > To be honest, the lack of reply to Peter's review by the authors or
 > by the WG a little bit suprising (thank you to the RTG AD though).

Please excuse the delay.  It has been on my radar for the last couple of
months in a very crowded field.

 > Minor regret on the age of the document shepherd's write-up dated
 > 2 years ago and about the -06 version. Little is said about the WG
 > consensus. But, I am trusting the responsible AD on the consensus.

 > I hope that this helps to improve the document,

 > Regards,

 > -éric

 > == DISCUSS ==

 > A very trivial to fix but I do want to have a justification of using
 > "point-to-point" (typically used over the two sides of a single link)
 > vs. "peer-to-peer" (typically used over multiple links). Is it 
intentional
 > by the ROLL WG ? Did I fail to understand the purpose of this document ?
 > (quite possible of course!). I am afraid that many people will interpret
 > the "point-to-point" like me.

I think there has been discussion about this in previous commentary, so I
will count this comment as having been resolved.  Please lt me know if there
is disagreement and more resolution is needed.  I am happy to change all
instances of P2P to mean peer-to-peer.  However, both terms do not 
explicitly
bring to mind the main point -- which is that the tree root does NOT have to
be in the route.


 > Comment (2021-04-21)

 > == COMMENTS ==

 > -- Section 4.3 --
 > Figure 3 has a 'X' while the text has a 'r' ;)

Fixed.

 > Any reason why using "Floor((7+(Prefix Length))/8) octets" rather
 > than the simple "Ceil(Prefix Length/8)" ?

Thanks for this suggestion.  I don't remember why we didn't use that 
instead,
nobody seems to have thought of it!


 > -- Section 6.1 --
 > "Each node maintains a sequence number" does it impact constrained 
nodes ?

Yes, to the extent that it requires 16 bits of memory and the amount of 
power
to maintain that memory.  Should we mention that?


 > == NITS ==

 > -- Abstract --
 > "the links between source and target node are asymmetric" should this 
be "nodes" (plural) ?

Fixed.


 > -- section 1 (and possibly others) --
 > I believe that the usual way to introduce acronyms is to first write
 > the expansion than the acronym itself. So " RPL (Routing Protocol for
 > Low-Power and Lossy Networks)" does not seem to fit ;)

Fixed.


 > -- Section 5 --
 > "R is an intermediate router" or "Rs are intermediate routers" ?

How about "Each R is an intermediate router"?

Regards,
Charlie P.


On 4/21/2021 2:44 AM, Éric Vyncke via Datatracker wrote:
> Éric Vyncke has entered the following ballot position for
> draft-ietf-roll-aodv-rpl-10: Discuss
>
> 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 DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-roll-aodv-rpl/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> Thank you for the work put into this document. I seems that all cases have been
> thought of :-) Good job! and having a shorter path between two RPL nodes can be
> benefitial of course.
>
> Please find below one blocking (but probably trivial to fix) DISCUSS point,
> some non-blocking COMMENT points (but replies would be appreciated), and some
> nits.
>
> Special thanks to Peter Van der Stock for the IoT directorate review:
> https://datatracker.ietf.org/doc/review-ietf-roll-aodv-rpl-10-iotdir-telechat-van-der-stok-2021-04-15/
>
> To be honest, the lack of reply to Peter's review by the authors or by the WG a
> little bit suprising (thank you to the RTG AD though).
>
> Minor regret on the age of the document shepherd's write-up dated 2 years ago
> and about the -06 version. Little is said about the WG consensus. But, I am
> trusting the responsible AD on the consensus.
>
> I hope that this helps to improve the document,
>
> Regards,
>
> -éric
>
> == DISCUSS ==
>
> A very trivial to fix but I do want to have a justification of using
> "point-to-point" (typically used over the two sides of a single link) vs.
> "peer-to-peer" (typically used over multiple links). Is it intentional by the
> ROLL WG ? Did I fail to understand the purpose of this document ? (quite
> possible of course!). I am afraid that many people will interpret the
> "point-to-point" like me.
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> == COMMENTS ==
>
> -- Section 4.3 --
> Figure 3 has a 'X' while the text has a 'r' ;)
>
> Any reason why using "Floor((7+(Prefix Length))/8) octets" rather than the
> simple "Ceil(Prefix Length/8)" ?
>
> -- Section 6.1 --
> "Each node maintains a sequence number" does it impact constrained nodes ?
>
> == NITS ==
>
> -- Abstract --
> "the links between source and target node are asymmetric" should this be
> "nodes" (plural) ?
>
> -- section 1 (and possibly others) --
> I believe that the usual way to introduce acronyms is to first write the
> expansion than the acronym itself. So " RPL (Routing Protocol for Low-Power and
> Lossy Networks)" does not seem to fit ;)
>
> -- Section 5 --
> "R is an intermediate router" or "Rs are intermediate routers" ?
>
>
>