[Roll] Roman Danyliw's Discuss on draft-ietf-roll-useofrplinfo-25: (with DISCUSS and COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-roll-useofrplinfo-25: 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 IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-roll-useofrplinfo/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Per Section 11:
   [RFC2473] suggests that tunnel entry and exit points can be secured,
   via the "Use IPsec".  The suggested solution has all the problems
   that [RFC5406] goes into.  In an LLN such a solution would degenerate
   into every node having a tunnel with every other node.  It would
   provide a small amount of origin address authentication at a very
   high cost; doing BCP38 at every node (linking layer-3 addresses to
   layer-2 addresses, and to already present layer-2 cryptographic
   mechanisms) would be cheaper should RPL be run in an environment
   where hostile nodes are likely to be a part of the LLN.

** I'm having trouble understanding what recommendation this text was making. 
The first sentence seems to suggest IPSec, the second sentence seems to
discount that advice; and the third seems to suggest BCP38 as an alternative. 
Could you please clarify.

** Please be explicit on which challenges in RFC5406 are being cited (e.g.,
which sections)


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(1) Abstract.  Per “Additionally, this document updates RFC 6550 to indicate
about this change …”, this sentence didn’t parse for me in explaining the
relationship with RFC6550.

(2) Section 1.  Typo.  s/implementors/implementers/

(3) Section 2.  Editorial Nit.  s/header refers to:/header refers to/

(4) Section 3.  A few editorial comments on how these updates are presented:

** Inconsistent spacing in Section 3 title:
s/Updates to RFC6553, RFC6550 and RFC 8138/
Updates to RFC6553, RFC6550 and RFC8138/

** Section 3.1 and Section 3.3 open with the motivation for the change. 
Section 3.2 does not.

** Section 3.3 title describes the proposed change.  Section 3.1 and 3.2 simple
state “Updates to RFCxxx”

** Section 3.1 – 3 titles include a space in the RFC names (i.e.,
RFC-space-number).  The Section 3 title does not.

(5) Section 3.1.  Editorial Nit.

** s/[RFC6553] states as shown below/[RFC6553] states as shown in Figure 1/

** Recommend citing the relevant page and section number from RFC6553 too.

(6) Section 3.2.  Please use more explicit language to describe how this
section updates RFC8138.

(7) Section 3.2.  Figure 3 is depicted in this section but not referenced in
the text.

(8) Section 4.  Typo.  s/A RPL Stack is shown in Figure 5/A RPL Stack is shown
in Figure 6/

(9) Section 5.  Editorial Nit. s/these nodes are/These nodes are/

(10) Section 5.  A few editorial recommendations for this paragraph:

The uses cases describe the communication between RPL-aware-nodes,
   with the root (6LBR), and with Internet.  This document also describe
   the communication between nodes acting as leaves that do not
   understand RPL, but are part of the LLN.  these  nodes are named as
   not-RPL-aware-leaf, mentioned previously.  (e.g.  Section 6.1.4 Flow
   from not-RPL-aware-leaf to root) This  document describes also how is
   the communication inside of the LLN when it has the final destination
  addressed outside of the LLN e.g. with destination to Internet.
   (e.g.  Section 6.2.3 Flow from not-RPL-aware-leaf to Internet)
** s/these nodes are/These nodes are/

** The sentence “This document describes also how …” doesn’t parse.

** The use of “(e.g. …)” as a standalone sentence doesn’t parse.

(11) Section 5.  Per “There is some possible security risk when the RPI
information is released on the internet …”, I recommend reframing this text
around the fact that the leak of RPI info would not present an issue. As is,
the impact reads ambiguously to me.

(12) Section 6.  The meaning of “root” in Figure 7 is not explained in the text
above it.

(13) Section 6.1.4.  Typo. s/encapsuladed/encapsulated/

(14) Section 9.  Editorial Nit.
s/ During bootstrapping the node get the DIO with the information of RPL Option
Type/ During bootstrapping the node gets the DIO with the information of RPL
Option Type/

(15) Section 11.  Make BCP38 a reference (i.e., [BCP38])