Subject: [Roll] Éric Vyncke's Discuss on draft-ietf-roll-useofrplinfo-25: (with DISCUSS and COMMENT)

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Wed, 01 May 2019 23:13:15 -0700

Éric Vyncke 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:
----------------------------------------------------------------------

The document is interesting and is about an interesting twist of behavior in
the light of RFC 8200 new behavior with respect to Hop-by-hop extension header.

But, I am balloting a DISCUSS for two reasons:

1) in section 3.1,  I am failing to understand the link between RFC8200 HbH
behavior and why the RPI code needs to be changed to 0x23.  => a clear
explanation is required on why the option 0x23 is linked to RFC 8200: I fail to
understand the authors' logic. At first sight, with the new RFC8200 HbH
handling, there is no need to change the RPI code from 0x63 as most routers
will ignore HbH anyway.

2) the document deserves a better text as there are too many nits, unexpanded
acronyms, ... the reader has hard time to understand the document.

Again, the content is useful but need some more work.

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

Comments
--------

C1) Section 1, having a date or short description of the interim meeting could
be useful here.

C2) Section 2, the term "Hop-by-hop IPv6-in-IPv6 headers" is confusing at first
reading, what about "Link IPv6-in-IPv6 header" ? or "Single link IPv6-in-IPv6
header" ? Hop-by-hop has a specific meaning in IPv6. This term is not also used
consistenly in the document.

C3) section 3.2 how does a network node would understand / learn that it is in
"0x23 mode" ? It should provide a hint to section 3.3 or swap section 3.2 and
3.3 to make the task easier for the reader.

C4) section 3.3 if the decompression is also to 0x23 or 0x63, then what is the
compressor behavior when receiving the other code?

C5) the introduction to RPL in section 4 after the topology is nice and concise
but it is either too late in the document or useless (I prefer the former, for
example in section 2).

C6) the code 0x23 is assumed everywhere but AFAIK there is no guarantee that
IANA will use this code (even if this is the logical choice)

C7) it is assumed that the Internet has moved to RFC8200 and does not drop
packets with HbH... "will not be discarded" I would prefer to have a disclaimer
on the current sad state of the Internet

C8) section 5, while I am not an expert in RPL, I wonder whether the sentence
"there can be no loops by construction" is true even in transient states ?

C9) section 6, is there any reason why the 'must' and 'root' values are not
specified while 'hop' and others are ?

C10) Section 6.1.1 title is "SM: Example of Flow from RPL-aware-leaf to root"
while SM has NOT been specified only RPL-SM.

C11) Section 7, AFAIK RPL has been designed to be confined in one domain, if I
am not mistaken, then extending RPL to work over the Internet would require
some considerations early in this document (even if IPv6-in-IPv6 should clear
the security issues of RH3 as discussed in the security section).

C12) the 2nd paragraph of section 9 is probably useless as it is a snapshot
taken in 2018/2019 which may not be the case anymore in a couple of years

Nits
----

N1) in section 1, this is a unexpected abbreviation < "RPL option" (RPI) >

N2) in section 2, another unexpected abbreviation < RPL-aware-leaf (Raf) >

N3) section 3.1, inconsistent use of quotes around 01 and 1 in the same section

N4) section 4, acronyms such 6LR are here explained while section 2 referred to
an external document... perhaps worth augmenting section 2 and removing the
description in section 4 ?

N5) section 4, s/in non-storing (RPL-NSM)/in non-storing mode (RPL-NSM)/

N6) section 5 does not use the previously introduced abbreviations... this I-D
looks like a patchwork (different authors -- and I made multiple times the same
'mistake' ;-) )

N7) section 5 s/Extensions may not be added/Extensions Headers may not be added/

N8) section 5 repeat the use of 01 in the option and its explanation => remove
this part

N9) section 5 s/to add to remove/to add and remove/ ?

N10) section 6, s/It indicate/It indicates/

N11) section 6, s/hop by hop/hop-by-hop/

---

From: Ines Robles <[email-masked]>
Date: Fri, 17 May 2019 02:29:32 +0300

Hi Éric,

Many thanks for your review. We have submitted a new document with
corrections. Please find answers in-line below.

<author> New text was added in this section for clarifications purposes
</author>

> acronyms, ... the reader has hard time to understand the document.

<author> Nits and tables were fixed </author>

> Again, the content is useful but need some more work.
<author> that text was removed, new text was added

New Text: The ROLL WG analysized how [RFC2460
<https://tools.ietf.org/html/rfc2460>] rules apply to storing and non-

   storing use of RPL.  The result was 24 data plane use cases.  They
   are exhaustively outlined here in order to be completely unambiguous.
   During the processing of this document, new rules were published as
   [RFC8200 <https://tools.ietf.org/html/rfc8200>], and this document
was updated to reflect the normative
   changes in that document.

</author>

> consistenly in the document.

<author> changed to Hop-by-hop re-encapsulation </author>

> 3.3 to make the task easier for the reader.

<author> sections were swapped </author>

> compressor behavior when receiving the other code?
<author> A node compress the RPL RPI option type that is currently active
</author>

> but it is either too late in the document or useless (I prefer the former,
<author> fixed </author>

> IANA will use this code (even if this is the logical choice)
<author> we got early allocation </author>

> <author>Prior to this document, packets would be dropped.  Someone who
wants to push LLN traffic across the Internet already had to deal with
either configuring RPI to be accepted. Now, they can do that, or deploy
RFC8200. <author>

> "there can be no loops by construction" is true even in transient states ?

<author> loops are detected by RPI header</author>

> specified while 'hop' and others are ?

<author>clarification added</author>

> while SM has NOT been specified only RPL-SM.

<author>fixed</author>

> the security issues of RH3 as discussed in the security section).

<author>RPL can not work across the Internet, it is a routing protocol, and
requires adjacencies. Connecting two networks via IP packets is just
classic “Inter”net.  </author>

> taken in 2018/2019 which may not be the case anymore in a couple of years

<author> paragraph deleted</author>

> N1) in section 1, this is a unexpected abbreviation < "RPL option" (RPI) >

<author>fixed</author>

> N2) in section 2, another unexpected abbreviation < RPL-aware-leaf (Raf) >

 <author> we think that it is a good abbreviation to indicate about leaf,
take the "f" instead of the l  <author>

> N3) section 3.1, inconsistent use of quotes around 01 and 1 in the same

<author> could you please clarify, we dont understand what is wrong with
that. </author>

> description in section 4 ?

 <author> fixed </author>

> N5) section 4, s/in non-storing (RPL-NSM)/in non-storing mode (RPL-NSM)/
 <author> fixed </author>

> looks like a patchwork (different authors -- and I made multiple times the

 <author> fixed </author>

> N7) section 5 s/Extensions may not be added/Extensions Headers may not be

 <author> fixed </author>

> N8) section 5 repeat the use of 01 in the option and its explanation =>

<author> However, unlike [RFC6553], the Hop-by-Hop Option Header used for
the

  RPI artifact has the first two bits set to '00'.  This means that the

  RPI artifact will be ignored when received by a host or router that

  does not understand that option ( Section 4.2 [RFC8200]).

     ⇒ is it this part you want us to remove? </author>

> N9) section 5 s/to add to remove/to add and remove/ ?
 <author> fixed </author>

> N10) section 6, s/It indicate/It indicates/
 <author> fixed </author>

> N11) section 6, s/hop by hop/hop-by-hop/
 <author> fixed </author>

Many Thanks again,

Ines, Michael and Pascal

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Fri, 17 May 2019 06:03:37 +0000

Ines, Michel and Pascal

Thank you for the clarifications and the other changes.

About nits N8), I am suggesting indeed to avoid a 2nd explanation about the drop/no-drop behavior in section 5. So, I suggest to remove 3 paragraphs == all the text from “However, unlike [RFC6553],” to “Security Considerations sections Section 11 for further details.”

Thank you again for this hard work

-éric

From: Ines Robles <[email-masked]>
Date: Friday, 17 May 2019 at 01:29
To: Eric Vyncke <[email-masked]>
Cc: The IESG <[email-masked]>, "[email-masked]" <[email-masked]>, Peter Van der Stok <[email-masked]>, Alvaro Retana <[email-masked]>, roll-chairs <[email-masked]>, roll <[email-masked]>
Subject: Re: Éric Vyncke's Discuss on draft-ietf-roll-useofrplinfo-25: (with DISCUSS and COMMENT)

Hi Éric,

Many thanks for your review. We have submitted a new document with corrections. Please find answers in-line below.

On Thu, May 2, 2019 at 9:13 AM Éric Vyncke via Datatracker <[email-masked]<mailto:[email-masked]>> wrote:
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

<author> New text was added in this section for clarifications purposes </author>

Comments
--------

New Text: The ROLL WG analysized how [RFC2460<https://tools.ietf.org/html/rfc2460>] rules apply to storing and non-

   [RFC8200<https://tools.ietf.org/html/rfc8200>], and this document was updated to reflect the normative

C4) section 3.3 if the decompression is also to 0x23 or 0x63, then what is the
compressor behavior when receiving the other code?
<author> A node compress the RPL RPI option type that is currently active </author>

C7) it is assumed that the Internet has moved to RFC8200 and does not drop
packets with HbH... "will not be discarded" I would prefer to have a disclaimer
on the current sad state of the Internet
<author>Prior to this document, packets would be dropped.  Someone who wants to push LLN traffic across the Internet already had to deal with either configuring RPI to be accepted. Now, they can do that, or deploy RFC8200. <author>

<author>fixed</author>

<author>RPL can not work across the Internet, it is a routing protocol, and requires adjacencies. Connecting two networks via IP packets is just classic “Inter”net.  </author>

Nits
----

<author>fixed</author>

 <author> we think that it is a good abbreviation to indicate about leaf, take the "f" instead of the l  <author>

<author> could you please clarify, we dont understand what is wrong with that. </author>

 <author> fixed </author>

 <author> fixed </author>

 <author> fixed </author>

<author> However, unlike [RFC6553], the Hop-by-Hop Option Header used for the

Many Thanks again,

Ines, Michael and Pascal

---

From: Ines Robles <[email-masked]>
Date: Fri, 17 May 2019 11:57:12 +0300

Hi Eric,

Thank you, we just updated a new version with the suggested changes.

Have a nice day,

Ines, Michael and Pascal

On Fri, May 17, 2019 at 9:03 AM Eric Vyncke (evyncke) <[email-masked]>
wrote:

> About nits N8), I am suggesting indeed to avoid a 2nd explanation about
> the drop/no-drop behavior in section 5. So, I suggest to remove 3
> paragraphs == all the text from “However, unlike [RFC6553],” to “Security
> Considerations sections Section 11 for further details.”
>
>
>
> *From: *Ines Robles <[email-masked]>
> *Date: *Friday, 17 May 2019 at 01:29
> *To: *Eric Vyncke <[email-masked]>
> *Cc: *The IESG <[email-masked]>, "[email-masked]" <
> [email-masked]>, Peter Van der Stok <
> [email-masked]>, Alvaro Retana <[email-masked]>,
> roll-chairs <[email-masked]>, roll <[email-masked]>
> *Subject: *Re: Éric Vyncke's Discuss on draft-ietf-roll-useofrplinfo-25:
> (with DISCUSS and COMMENT)
>
>
>
> Hi Éric,
>
>
>
> On Thu, May 2, 2019 at 9:13 AM Éric Vyncke via Datatracker <
> [email-masked]> wrote:
>
>    [RFC8200 <https://tools.ietf.org/html/rfc8200>], and this document was updated to reflect the normative
>
> <author>RPL can not work across the Internet, it is a routing protocol,
> and requires adjacencies. Connecting two networks via IP packets is just