Re: [Roll] Datatracker State Update Notice: <draft-ietf-roll-useofrplinfo-23.txt>

Ines Robles <mariainesrobles@googlemail.com> Wed, 23 January 2019 22:06 UTC

Return-Path: <mariainesrobles@googlemail.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3222130F3B for <roll@ietfa.amsl.com>; Wed, 23 Jan 2019 14:06:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JFEaL_w8w-MV for <roll@ietfa.amsl.com>; Wed, 23 Jan 2019 14:06:26 -0800 (PST)
Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6998130F39 for <roll@ietf.org>; Wed, 23 Jan 2019 14:06:25 -0800 (PST)
Received: by mail-ed1-x52f.google.com with SMTP id h50so2969009ede.5 for <roll@ietf.org>; Wed, 23 Jan 2019 14:06:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6S6R0iI51yyYsrKZIGcoe9a+YbwZwc/kyeDwY1+4B1U=; b=lJ8UoTMGML7KCdNJPgMxFGwF6hxxopYyfWZXhFU3OwBrUSVIfN8Jm+cqTNtM8CyW+t RzEd8zmMSz4sgoew/pLX7gFSFQkFkVLOjJ96RjY1hTz93J7U7JxKcunXYdipAU/dAxox 9uJKtmVuXGsQRCL2y/54vGBuJVfq/QjSX4Vior7dNs1+gcFnqwdXF2ies2w3JiFs1lP0 f7Q/R1VMM4NIpyveeVRuI0IQDuPXO0a+l5wf6ZzfdiVbVIhuL4Og/5cgC501ZqQGeTDB JianpLG2HVoWII+3wmEpH4/MdhyS8F+iTK/l/4fxwtC87CO+PqrrrAgg5mMHfWk2IpKB ZuRA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6S6R0iI51yyYsrKZIGcoe9a+YbwZwc/kyeDwY1+4B1U=; b=CapJ+xuOuSTetO970Kscrh5UQlxpSq1jq1HtfgyYTa9Z18uyKN9+VbHx23+Gfc8BA1 lbODN+8dnUtvVwT+kgfo2qI15o7eo8Q14MAkraswOzk3wE5Z8djxQxl3ZqDLoBCkxOHm Lb7oSOkvXRFRgxRmWP7TGpr78azqMVTepr3JZajDnKhLZB3ICR8N3WLm2ekWWph3hbGw stf/6EdIY1w6KqhMBUpjxKEzTMVGHEjYCji17x5Us0h1FrhNjt3NDEKq3UfASS+U7NmR WxO5DyndqotXHi5VcEfp68kdjeiJA/vctUh/BOdUh1PFAwC7nEJAzNr6t2e7EwcN47Y5 S7Mg==
X-Gm-Message-State: AJcUukfeh8nffa58YYRuZrdaqamSU84fzppNRm4SjhMcfyRfm9TBHz+e lCgSM7MhCaBC8s+T0/MJa88B7SejYkzw3CR3IMqz9av+
X-Google-Smtp-Source: ALg8bN6yK4VohyRMK3lSUqE2t5Ju/7qIRAZyafqd6rp3HtDG1Zt/WgcMi/J57exf/G+GcjQvYaowy0d+gAOC9U2sVlk=
X-Received: by 2002:a05:6402:1347:: with SMTP id y7mr4232549edw.114.1548281183576; Wed, 23 Jan 2019 14:06:23 -0800 (PST)
MIME-Version: 1.0
References: <153427390944.27108.4373520532151309638.idtracker@ietfa.amsl.com>
In-Reply-To: <153427390944.27108.4373520532151309638.idtracker@ietfa.amsl.com>
From: Ines Robles <mariainesrobles@googlemail.com>
Date: Thu, 24 Jan 2019 00:06:11 +0200
Message-ID: <CAP+sJUfzkW9X1je_EetpPsUeRN3+spkuVCSr+LyaScum7SbSbg@mail.gmail.com>
To: Alvaro Retana <aretana.ietf@gmail.com>, roll <roll@ietf.org>
Cc: alvaro.retana@huawei.com
Content-Type: multipart/alternative; boundary="000000000000f5a7fa0580274d67"
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/uKy7ScLmGa7vdMxNiz_cieWKcjo>
Subject: Re: [Roll] Datatracker State Update Notice: <draft-ietf-roll-useofrplinfo-23.txt>
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Jan 2019 22:06:35 -0000

Dear Alvaro,

Many thanks for your review.

BIG Apologizes for the delay. Please find the answers in-line as [authors].

Best regards,

Michael, Pascal, Ines.

On Tue, Aug 14, 2018 at 10:11 PM IETF Secretariat <
ietf-secretariat-reply@ietf.org> wrote:

> IESG state changed:
>
> New State: AD Evaluation::Revised I-D Needed
>
> (The previous state was AD Evaluation::AD Followup)
>
> === AD Review of draft-ietf-roll-useofrplinfo-23 ===
>
>
> Dear authors:
>
> I have (finally!) finished reading this document.  Thanks for all the work
> and time put into working out all the details.
>
> I have several concerns.  I'm listing some of the Major (and
> document-wide) ones up front.  I also put more comments and questions
> inline below.
>
> (1) [major] Where is the specification of the data-plane behavior?
>
> This document does a couple of things: it Updates several other RFCs, and
> presents a list of *example* flows where the expected behavior is
> illustrated.  The Updates are mostly about the new RPI value (0x23), but
> not about the behavior of the nodes.
>
> Most of the examples are worded such that they describe actions
> (encapsulate, remove, etc.)...and some even include rfc2119 Normative
> Keywords.  But they are called examples!  So...my questions are: is the
> behavior illustrated in §6 and §7 intended to be Normative?



[authors]The examples are intended to illustrate the result of the
normative language in RFC8200 and RFC6553.
So the examples are intended to be normative explanation of the results of
executing that language.



> IOW, do these sections include both examples and specify the behavior
> expected in the LLN?  Is the behavior already specified somewhere else (and
> this document is just illustrating)?


[authors]The normative language is in RFC8200 (ipv6bis) section 4.2 and
section 4, “The Hop-by-Hop Options…”
Combined with the desired results of  RFC6553, we conclude that we have to
change the option value in order to make things work.


>   [I am asking that last question just-in-case, because the Introduction
> says that "this document clarifies what is the correct and the incorrect
> behaviour."]


[authors] It says that because the use of RPL in the mentioned cases was
not clear to the WG.
Thus, we have interoperability issues.

>
> §8 seems to attempt to summarize "observations about the cases", but (if
> it is intended to be *the* Normative text about the behavior) it is general
> and short.
>

[authors] It tends to be a summary about the most important findings in the
use cases

>
> [Some of my comments below ask about Normative language... Please take
> those in context with the answers here.]
>
>
> (2) [major] Operational Considerations
>
> Non-storing mode networks don't need the change to 0x23 (§8.2)...but
> making the change creates a flag day, and even then, implementations should
> still process both values (§3.1).  I would really like to see text about
> the operational considerations of introducing 0x23.  It concerns me that a
> significant change that most[*] networks don't need is being introduced.
> Please take a look at rfc5706 (Guidelines for Considering Operations and
> Management of New Protocols and Protocol Extensions), specially §2.
>
> [*] Most deployed networks work in non-storing mode, right?
>

[authors]following our understanding, mostly yes.
but, e.g. Anima network in storing mode. Not having loop detection.
https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-18#section-6.11.1.3


>
>
> (3) [minor] >= ??
>

[authors] Fixed. corrected to 1 <= i <= n

>
> There are several (25!) instances of text like this:
>
>    6LR_i are the intermediate routers from source to destination.  In
>    this case, "1 <= i >= n", n is the number of routers (6LR) that the
>    packet go through from source (6LN) to destination (6LBR).
>
> Maybe it's just me, but I don't understand why (or how!) i could ever be
> >= n.  The text says that i are the "intermediate routers from source to
> destination", while n is "the number of routers...from source (6LN) to
> destination (6LBR)".  Isn't that the same thing?  What am I missing?
>
>
> (4) Style nit: the document uses "we"...a third person style would be
> preferable.  For example: s/In this section we are going to
> describe.../This section describes...
>

[authors] Fixed.

>
>
> I will wait for the major points to be addressed before starting the IETF
> LC.
>
> Thanks!!
>
> Alvaro.
>
>
>
> [Note: the numbers came from the idnits output.]
>
> ...
> 10              When to use RFC 6553, 6554 and IPv6-in-IPv6
> 11                    draft-ietf-roll-useofrplinfo-23
>
> [minor] Can we come up with a more descriptive tittle?  Also, the
> "shorthand" version ("Useof6553") could be improved.
>

[authors] Fixed. Useof6553 =>  RPL-data-plane

>
>
> ...
> 130 1.  Introduction
> ...
> 156   The related document A Routing Header Dispatch for 6LoWPAN (6LoRH)
> 157   [RFC8138] defines a method to compress RPL Option information and
> 158   Routing Header type 3 [RFC6554], an efficient IP-in-IP technique, and
> 159   use cases proposed for the [Second6TischPlugtest] involving 6loRH.
>
> [nit] I'm having trouble parsing this last paragraph.  It sounds like
> rfc8138 (also) defines the use cases, but I don't remember seeing anything
> like that in there.  Is that what you meant?
>

[authors]rewritten. RFC8138" defines a mechanism for compressing RPL Option
 information and Routing Header type 3, as well as an efficient IP-in-IP
technique.

>
> [nit] I think the Introduction would benefit from an overview of the
> document; something like "section X talks about abc, section Y presents
> examples, etc.".
>

[authors]added

>
> 161 2.  Terminology and Requirements Language
>
> 163   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
> 164   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
> 165   document are to be interpreted as described in RFC 2119 [RFC2119].
>
> [major] Please use the RFC8174 template.
>
[authors]added

>
> ...
> 170   RPL-node: A device which implements RPL, thus we can say that the
> 171   device is RPL-capable or RPL-aware.  Please note that the device can
> 172   be found inside the LLN or outside LLN.  In this document a RPL-node
> 173   which is a leaf of a DODAG is called RPL-aware-leaf.
>
> [nit] RPL-capable is not used anywhere else.
>
[authors]fixed. removed

>
> ...
> 180   pledge: a new device which seeks admission to a network. (from
> 181   [I-D.ietf-anima-bootstrapping-keyinfra])
>
> 183   Join Registrar and Coordinator (JRC): a device which brings new nodes
> 184   (pledges) into a network. (from
> 185   [I-D.ietf-anima-bootstrapping-keyinfra])
>
> [minor] Do these two terms need to be defined in this document?  They are
> only used once, and with a reference to
> I-D.ietf-anima-bootstrapping-keyinfra next to them.  Also, and more
> important, the definition here doesn't match the one in that other draft.
> Please take out the definitions and just make reference later on...
>
[authors]fixed. removed

>
> 187   Flag day: A "flag day" is a procedure in which the network, or a part
> 188   of it, is changed during a planned outage, or suddenly, causing an
> 189   outage while the network recovers [RFC4192]
>
> [nit] rfc4192 seems like an odd place to pull a reference to "flag day" --
> specially as it is being defined as "a procedure" and not the effect it
> causes, which seems to be how it is used in the text: "creates a flag day",
> "will experience a flag day", "avoid a flag day".  This is not a big issue
> -- if it was up to me, I would either make my own definition, or just not
> define it at all: I think it is a well known term...
>

[authors]fixed. rewritten

>
> 191 2.1.  hop-by-hop IPv6-in-IPv6 headers
>
> 193   The term "hop-by-hop IPv6-in-IPv6" header refers to: adding a header
> 194   that originates from a node to an adjacent node, using the addresses
> 195   (usually the GUA or ULA, but could use the link-local addresses) of
> 196   each node.  If the packet must traverse multiple hops, then it must
> 197   be decapsulated at each hop, and then re-encapsulated again in a
> 198   similar fashion.
>
> [minor] That term is not used anywhere...but "hop-by-hop IP-in-IP" is.
>

[authors]fixed. IP-in-IP replaced by IPv6-in-IPv6

>
> IPv6-in-IPv6 and IP-in-IP are used interchangeably throughout the
> document.  This use is not wrong, but it is inconsistent.  Adding a note
> about it (even though it may be obvious to many readers that the terms
> refer to the same thing) would be nice...being consistent even nicer.
>
> Later on, "IPIP" is also used...
>
>
> [nit] Why is this definition in its own sub-section?
>
[authors]fixed. It is included in the section instead.

>
> 200 3.  Updates to RFC6553, RFC6550 and RFC 8138
>
> 202 3.1.  Updates to RFC 6553
>
> ...
> 209   [RFC6553] states as showed below, that in the Option Type field of
> 210   the RPL Option header, the two high order bits MUST be set to '01'
> 211   and the third bit is equal to '1'.  The first two bits indicate that
> 212   the IPv6 node MUST discard the packet if it doesn't recognize the
> 213   option type, and the third bit indicates that the Option Data may
> 214   change en route.  The remaining bits serve as the option type.
>
> s/showed/shown
>
> [major] The 2 MUSTs used above are used paraphrasing rfc6553, and don't
> define Normative behavior in this document.  Please either use a direct
> quote, or use non-normative language.
>
[authors]fixed to non-normative language.

>
> ...
> 223   Recent changes in [RFC8200] (section 4, page 8), states: "it is now
> 224   expected that nodes along a packet's delivery path only examine and
> 225   process the Hop-by-Hop Options header if explicitly configured to do
> 226   so".  Processing of the Hop-by-Hop Options header (by IPv6
> 227   intermediate nodes) is now optional, but if they are configured to
> 228   process the header, and if such nodes encounter an option with the
> 229   first two bits set to 01, they will drop the packet (if they conform
> 230   to [RFC8200]).  Host systems should do the same, irrespective of the
> 231   configuration.
>
> [minor] The description above seems to be missing "...if the option is not
> recognized".
>
> 233   Based on That, if an IPv6 (intermediate) node (RPL-not-capable)
> 234   receives a packet with an RPL Option, it should ignore the HBH RPL
> 235   option (skip over this option and continue processing the header).
>
> s/That/that
>
> ...
> 266   When forwarding packets, implementations SHOULD use the same value as
> 267   it was received (This is required because, RPI type code can not be
> 268   changed by [RFC8200]).  It allows to the network to be incrementally
> 269   upgraded, and for the DODAG root to know which parts of the network
> 270   are upgraded.
>
> [major] There seems to be a contradiction above: "SHOULD use the same
> value...this is required..."   If required by rfc8200, why not use MUST?
>
[authors]rewritten

>
> 272   When originating new packets, implementations SHOULD have an option
> 273   to determine which value to originate with, this option is controlled
> 274   by the DIO option described below.
>
> [minor] §3.3 defines the option...but it doesn't explicitly say what the
> receivers should do with it.  It may be obvious, but it should be explicit
> for completeness.
>
[authors]rewritten

>
> [major] It seems to me that the paragraph above may be out of place,
> doesn't say much, may be wrong...or maybe all 3.  The text says that the
> originating value is controlled by the option in §3.3 (again, but that
> section doesn't explicitly say what should be done)...but it also says
> (with the SHOULD) that an implementation may have valid reasons to not pay
> attention to the option -- what are those??
>

[authors]rewritten to
"In the cases where a forwarding node is forwarding traffic that is not
           addressed directly to it (such as when the outer IPv6-in-IPv6
header is not a Link-Local address),
           then RFC8200 forbids changing the RPI type code when forwarding.

           When forwarding traffic that is wrapped in Link-Local
IPv6-in-IPv6 headers,
           the forwarding node is in effect originating new packets,
           and it MAY make a choice as to whether to use the old (0x63) RPI
Type code,
           or the new (0x23) RPI Type code. In that situation,
implementations SHOULD
           use the same value as was received.  This allows to the network
to be incrementally upgraded,
           and in some cases may allow the DODAG root to know which parts
of the network are upgraded."

>
>
> ...
> 281 3.2.  Updates to RFC 8138
>
> 283   RPI-6LoRH header provides a compressed form for the RPL RPI
> 284   [RFC8138].  It should be considered when the Option Type in RPL
> 285   Option is decompressed, should take the value of 0x23 instead of
> 286   0x63.
>
> [major] AFAICT, the compression specified in rfc8138 doesn't include the
> RPI option type...but the use of the 6LoRH Type 5 implies the RPI.  If I
> got that right, then how would the decompressing node know which RPI type
> was in use when first compressed?  Given that both types may be used in a
> network (§3.1), how would one know unless the 6LoRH type was also changed?
> Or are you suggesting that the decompression should always use 0x23?  In
> any case, I think that stronger language might be needed.
>

[auhtors] Yes, we are suggesting that if the network is in 0x23 mode (by
DIO option),
then it should be decompressed to 0x23.
RPI-6LoRH header provides a compressed form for the RPL RPI in section 6.
A node that is decompressing this header MUST decompress using the RPL RPI
option type
that is currently active: that is, a choice between 0x23 (new) and 0x63
(old).
The node will know which to use based upon the presence of the DODAG
Configuration
Option described in the next section.

>
>
> 288 3.3.  Updates to RFC 6550: Indicating the new RPI in the DODAG
> 289      Configuration Option Flag.
>
> 291   In order to avoid a flag day caused by lack of interoperation between
> 292   new RPI (0x23) and old RPI (0x63) nodes, when there is a mix of new
> 293   nodes and old nodes, the new nodes may be put into a compatibility
> 294   mode until all of the old nodes are replaced or upgraded.
>
> 296   This can be done via a DODAG Configuration Option flag which will
> 297   propogate through the network.  Failure to receive this information
> 298   will cause new nodes to remain in compatibility mode, and originate
> 299   traffic with the old-RPI (0x63) value.
>
> s/propogate/propagate
>
> [major] "compatibility mode"


> What is "compatibility mode"?  Initially I thought that it was maybe the
> ability of new nodes to use both RPI values...but the end of the second
> paragraph suggests using only 0x63.
>
> The text suggests that "compatibility mode" can be enabled via "via a
> DODAG Configuration Option flag" -- that flag is not defined anywhere...but
> "failure to receive this information will cause new nodes to remain in
> compatibility mode".  So...would it be enabled using a flag, or is it the
> default?
>
> Why wouldn't the default be the new RPI?  I can see how most of the
> networks will support the old RPI, but that will eventually be the
> exception...
>
[authors]rewritten to
<t>
      In order to avoid a Flag Day caused by lack of interoperation
      between new RPI (0x23) and old RPI (0x63) nodes, this section
      defines a flag in the DIO Configuration Option, to indicate when
      then new RPI value can be safely used. Without this, there could
      be a mix of new nodes (which understand 0x23 and 0x63), and old
      nodes (which understand 0x63 only).  A new node would not know
      if it was safe to use 0x23.
    </t>
    <t>
      This is  done via a DODAG Configuration Option flag which will
propagate through the network.  If the flag is received with a
value zero (which is the default), then new nodes will remain in
      RFC6553 Compatible Mode; originating traffic with the old-RPI (0x63)
value.
    </t>

>
> 301   As stated in [RFC6550] the DODAG Configuration option is present in
> 302   DIO messages.  The DODAG Configuration option distributes
> 303   configuration information.  It is generally static, and does not
> 304   change within the DODAG.  This information is configured at the DODAG
> 305   root and distributed throughout the DODAG with the DODAG
> 306   Configuration option.  Nodes other than the DODAG root do not modify
> 307   this information when propagating the DODAG Configuration option.
>
> 309   The DODAG Configuration Option has a Flags field which is modified by
> 310   this document.  Currently, the DODAG Configuration Option in
> 311   [RFC6550] is as follows. .
>
> 313   Flags: The 4-bits remaining unused in the Flags field are reserved
> 314   for flags.  The field MUST be initialized to zero by the sender and
> 315   MUST be ignored by the receiver.
>
> 317 0                       1                    2                     3
> 318 +-----------------+---------------------------------------------------+
> 319 |  Type = 0x04    |  Opt Length = 14| Flags  | A | PCS| DIOIntDoubl.  |
> 320 +---------------------------------------------------------------------+
> 321 | DIOIntMin.      |  DIORedund.     |  MaxRankIncrease                |
> 322 +-----------------+---------------------------------------------------+
> 323 |  MinHopRankIncrease               |            OCP                  |
> 324 +-----------------+---------------------------------------------------+
> 325 |Reserved         | Def. Lifetime   |         Lifetime Unit           |
> 326 +-----------------+-----------------+---------------------------------+
>
> 328                   Figure 3: DODAG Configuration Option.
>
> [minor] Suggestion: instead of copying (and not quoting the Normative
> language) the text from rfc6550 above, just indicate what the Update is:
> "the unused bits MUST...".  Also, I think that Figure 3 is not needed.
>
[authors]fixed.

>
>
> ...
> 342   In case of rebooting, the node does not remember the flag.  Thus, the
> 343   DIO is sent with flag indicating the new RPI value.
>
> [minor] By "the node", which node are you referring to?  The root?  If it
> doesn't remember, it means that it needs to be configured -- how does that
> happen?  Why isn't the configuration persistent at the root?
>

[authors]fixed. 6LN or 6LR added.

>
> 345 4.  Sample/reference topology
>
> 347   A RPL network in general is composed of a 6LBR (6LoWPAN Border
> 348   Router), Backbone Router (6BBR), 6LR (6LoWPAN Router) and 6LN
> 349   (6LoWPAN Node) as leaf logically organized in a DODAG structure.
> 350   (Destination Oriented Directed Acyclic Graph).
>
> [minor] The 6BBR doesn't appear in the Figure.
>
[authors] clarification added

>
> [nit] BTW, it might be better to put the topology diagram right after this
> first paragraph.
>
[authors] done

>
> [nit] The DODAG expansion should be on first use.
>
[authors] done

>
> 352   RPL defines the RPL Control messages (control plane), a new ICMPv6
> 353   [RFC4443]  message with Type 155.  DIS (DODAG Information
> 354   Solicitation), DIO (DODAG Information Object) and DAO (Destination
> 355   Advertisement Object) messages are all RPL Control messages but with
> 356   different Code values.  A RPL Stack is showed in Figure 5.
>
> [minor] Not exactly sure what this paragraph has to do with the reference
> topology (yet), but (same comment as above) it might be good to put the
> figure right after the text.
>
> s/showed/shown
>

[authors] done

>
>
> ...
> 428                    Figure 6: A reference RPL Topology.
>
> 430   Figure 2 shows the reference RPL Topology for this document.  The
> 431   letters above the nodes are there so that they may be referenced in
> 432   subsequent sections.  In the figure, 6LR represents a full router
> 433   node.  The 6LN is a RPL aware router, or host.
>
> s/Figure 2/Figure 6
>
[authors] done

>
> [minor] The 6LN is defined in the first paragraph as a node (not a
> router).  BTW, what is the difference between a "full router" and (just) a
> "router" (6LR vs 6LN)?
>
[authors] follows rfc 6775:

"6LoWPAN Node (6LN):
      A 6LoWPAN node is any host or router participating in a LoWPAN.
      This term is used when referring to situations in which either a
      host or router can play the role described.

   6LoWPAN Router (6LR):
      An intermediate router in the LoWPAN that is able to send and
      receive Router Advertisements (RAs) and Router Solicitations (RSs)
      as well as forward and route IPv6 packets.  6LoWPAN routers are
      present only in route-over topologies."

In our document a 6LN represents a leaf, following the behaviour of
https://tools.ietf.org/html/rfc6550#section-8.5

>
> [minor] 6LN is characterized above as "RPL aware", but (below) the "Raf"
> mark is also used for that -- so it seems that "~Raf 6LN" would be a
> "not-RPL aware leaf...RPL aware router, or host".
>
> Some terminology clean up is needed.
>
[authors] we added clarifications in the terminology section. referring
rfc6775

>
> 435   But, the 6LN leaves (Raf - "RPL aware leaf"-) marked as (F, H and I)
> 436   are RPL nodes with no children hosts.
>
> [minor] Is there a relevance to the "children hosts" existing?  Can it be
> concluded that ~Raf nodes have children hosts?
>
[authors] It could be that a ~Raf have children hosts, but they are not
part of the RPL domain and no
packets are going to be delivered to them, but for the ~Raf.

>
>
> ...
> 446 5.  Use cases
> ...
> 507   This means that when the no-drop RPI option code 0x23 is used, a
> 508   packet that leaves the RPL domain of an LLN (or that leaves the LLN
> 509   entirely) will not be discarded when it contains the [RFC6553] RPL
> 510   Hop-by-Hop option known as RPI.  Thus, the RPI Hop-by-Hop option MAY
> 511   be left in place even if the end host does not understand it.
>
> [minor] If the last RPL-aware node knows that the host doesn't understand
> the RPI, why would it not remove it (if it can)?  IOW, I understand how it
> causes no harm (leading to the optional behavior above), but just because
> it can be done doesn't mean that it should.  Are there cases where it can
> be used for something?
>

[authors] we understand that the RPI is useful only in the RPL domain, not
outside of it.

>
> If the RPI can't be removed because the border is not the destination,
> then the MAY above is insignificant: no one can strip it, so there's no
> real option.
>
[authors] fixed.

>
> 513   NOTE: There is some possible security risk when the RPI information
> 514   is released to the Internet.  At this point this is a theoretical
> 515   situation; no clear attack has been described.  At worst, it is clear
> 516   that the RPI option would waste some network bandwidth when it
> 517   escapes.  This is traded off against the savings in the LLN by not
> 518   having to encapsulate the packet in order to remove the artifact.
>
> [major] AFAICT, leaking the RPI means leaking the RPLInstanceID and the
> SenderRank.  The Security Considerations already mentions what an attacker
> could do if it knows the RPLInstanceID...but it doesn't say anything about
> the SenderRank.
>
> I'm thinking that the SenderRank may help an attacker to have an idea of
> the topology of the LLN, right?  I don't know what an attacker can do with
> that information, but the fact that could be used for that (and it could be
> a privacy issue) should be mentioned in the Security Considerations section.
>
[authors] paragraph added.

>
> ...
> 526   A corollory is that an SHR3 or RPI Option can only be removed by an
> 527   intermediate router if it is placed in an encapsulating IPv6 Header,
> 528   which is addressed TO the intermediate router.  When it does so, the
> 529   whole encapsulating header must be removed.  (A replacement may be
> 530   added).  This sometimes can result in outer IP headers being
> 531   addressed to the next hop router using link-local addresses.
>
> s/corollory/corollary
>
[authors]fixed.

>
>
> ...
> 541   RPI should be present in every single RPL data packet.  There is one
> 542   exception in non-storing mode: when a packet is going down from the
> 543   root.  In a downward non-storing mode, the entire route is written,
> 544   so there can be no loops by construction, nor any confusion about
> 545   which forwarding table to use (as the root has already made all
> 546   routing decisions).  However, there are still cases, such as in
> 547   6tisch, where the instanceID portion of the RPI header may still be
> 548   needed to pick an appropriate priority or channel at each hop.
>
> [major] So...does that mean: in all cases, except downward non-storing
> mode if 6tisch is not used, the RPI SHOULD be present?  Note that some of
> the examples in §7 actually say that the RPI is optional...
>

[authors]: Yes, the RPI is optional in non-storing going downwards. The
paragraph is updated as follows:
"           <t>
            RPI MUST [[NOTE:  we increase this to MUST??]] be present in
every single RPL data packet. There is one
            exception in non-storing mode: when a packet is going down from
the
            root the RPI MAY be omitted.
            The rational is that in a downward non-storing mode, the entire
            route is written, so there can be no loops by construction, nor
any
            confusion about which forwarding table to use (as the root has
            already made all routing decisions).  However, there are still
            cases, such as in 6tisch, where the instanceID portion of the
RPI
            header may still be needed [6tisch-minimal draft] to pick an
appropriate priority or
            channel at each hop.
          </t>

>
> 550   In the tables present in this document, the term "RPL aware leaf" is
> 551   has been shortened to "Raf", and "not-RPL aware leaf" has been
> 552   shortened to "~Raf" to make the table fit in available space.
>
> s/is has been/has been
>
> [nit] There's some repetition; Raf, for example, was already introduced
> earlier in this section.
>
[authros]fixed. It is mentioned in the terminology section

>
> ...
> 557 6.  Storing mode
>
> 559   In storing mode (fully stateful), the sender can determine if the
> 560   destination is inside the LLN by looking if the destination address
> 561   is matched by the DIO's PIO option.
>
> [nit] Please expand PIO...
>
[authors]fixed.

>
> 563   The following table itemizes which headers are needed in the
> 564   following scenarios, and indicates if the IP-in-IP header must be
> 565   inserted on a hop-by-hop basis, or when it can target the destination
> 566   node directly.  There are these possible situations: hop-by-hop
> 567   necessary (indicated by "hop"), or destination address possible
> 568   (indicated by "dst").  In all cases hop by hop MAY be used.
>
> [major] Should there be something else Normative in this paragraph?  Maybe
> a MUST to indicate the need for "hop", as in "the IP-in-IP header MUST be
> inserted on a hop-by-hop basis"?
>
[authors]fixed.

>
> [minor] I'm confused by the nomenclature.  The description above seems to
> indicate that "hop" and "dst" are mutually exclusive...but the table shows
> a column with a title using "dst" and specific rows containing "hop".  What
> does that mean?
>
[authors]fixed. the nomenclature changed to target and clarification added.
<t>
  The following table itemizes which headers are needed in each
  of the following scenarios. It indicate if an IPv6-in-IPv6 header MUST
  be inserted, and whether the destination address of the IPv6-in-IPv6
  header is the next hop, or the final target address. There are
  these possible situations: hop-by-hop necessary (indicated by
  "hop"), or final target address possible (indicated by "tgt").  In
  all cases hop by hop MAY be used rather than the final target
  address.
</t>

>
> 570   In cases where no IP-in-IP header is needed, the column is left
> 571   blank.
>
> [minor] In Figure 7, there are "blank" columns (containing "--"), but
> there are also entries that say "No".  Are they meant to indicate the same
> thing?
>
[authors]Yes, fixed.

>
> 573   In all cases the RPI headers are needed, since it identifies
> 574   inconsistencies (loops) in the routing topology.  In all cases the
> 575   RH3 is not needed because we do not indicate the route in storing
> 576   mode.
>
> 578   In each case, 6LR_i are the intermediate routers from source to
> 579   destination.  "1 <= i >= n", n is the number of routers (6LR) that
> 580   the packet go through from source (6LN) to destination.
>
> 582   The leaf can be a router 6LR or a host, both indicated as 6LN (see
> 583   Figure 6).
>
> 585   +---------------------+--------------+----------+--------------+
> 586   | Interaction between |   Use Case   | IP-in-IP | IP-in-IP dst |
> 587   +---------------------+--------------+----------+--------------+
> 588   |                     |  Raf to root |    No    |      --      |
> 589   +                     +--------------+----------+--------------+
> 590   |     Leaf - Root     |  root to Raf |    No    |      --      |
> 591   +                     +--------------+----------+--------------+
> 592   |                     | root to ~Raf |    No    |      --      |
> 593   +                     +--------------+----------+--------------+
> 594   |                     | ~Raf to root |    Yes   |     root     |
> 595   +---------------------+--------------+----------+--------------+
> 596   |                     |  Raf to Int  |    No    |      --      |
> 597   +                     +--------------+----------+--------------+
> 598   |   Leaf - Internet   |  Int to Raf  |   Yes    |      Raf     |
> 599   +                     +--------------+----------+--------------+
> 600   |                     |  ~Raf to Int |    Yes   |     root     |
> 601   +                     +--------------+----------+--------------+
> 602   |                     |  Int to ~Raf |    Yes   |      hop     |
> 603   +---------------------+--------------+----------+--------------+
> 604   |                     |  Raf to Raf  |    No    |      --      |
> 605   +                     +--------------+----------+--------------+
> 606   |                     |  Raf to ~Raf |    No    |      --      |
> 607   +     Leaf - Leaf     +--------------+----------+--------------+
> 608   |                     |  ~Raf to Raf |    Yes   |      dst     |
> 609   +                     +--------------+----------+--------------+
> 610   |                     | ~Raf to ~Raf |    Yes   |      hop     |
> 611   +---------------------+--------------+----------+--------------+
>
> 613             Figure 7: IP-in-IP encapsulation in Storing mode.
>
> ...
> 726 6.1.4.  SM: Example of Flow from not-RPL-aware-leaf to root
>
> 728   In this case the flow comprises:
>
> 730   not-RPL-aware-leaf (IPv6) --> 6LR_1 --> 6LR_i --> root (6LBR)
>
> 732   For example, a communication flow could be: Node G --> Node E -->
> 733   Node B --> Node A root(6LBR)
>
> 735   When the packet arrives from IPv6 node (Node G) to 6LR_1 (Node E),
> 736   the 6LR_1 will insert a RPI header, encapsuladed in a IPv6-in-IPv6
> 737   header.  The IPv6-in-IPv6 header can be addressed to the next hop
> 738   (Node B), or to the root (Node A).  The root removes the header and
> 739   processes the packet.
>
> [minor] The table below doesn't reflect the case where the IPv6-in-IPv6
> header is addressed to the next hop.
>
[authors] fixed.

>
> 741   +------------+------+---------------+---------------+---------------+
> 742   | Header     | IPv6 | 6LR_1         | 6LR_i         | 6LBR          |
> 743   +------------+------+---------------+---------------+---------------+
> 744   | Inserted   | --   | IP-in-IP(RPI) | --            | --            |
> 745   | headers    |      |               |               |               |
> 746   | Removed    | --   | --            | --            | IP-in-IP(RPI) |
> 747   | headers    |      |               |               |               |
> 748   | Re-added   | --   | --            | --            | --            |
> 749   | headers    |      |               |               |               |
> 750   | Modified   | --   | --            | IP-in-IP(RPI) | --            |
> 751   | headers    |      |               |               |               |
> 752   | Untouched  | --   | --            | --            | --            |
> 753   | headers    |      |               |               |               |
> 754   +------------+------+---------------+---------------+---------------+
>
> 756     Storing: Summary of the use of headers from not-RPL-aware-leaf to
> 757                                   root
>
> ...
> 772 6.2.1.  SM: Example of Flow from RPL-aware-leaf to Internet
>
> 774   RPL information from RFC 6553 MAY go out to Internet as it will be
> 775   ignored by nodes which have not been configured to be RPI aware.
>
> [major] The "MAY" (Normative) is out of place as the sentence above is
> stating a fact, not specifying a behavior. s/MAY/may
>
[authors] fixed.

>
> ...
> 835 6.2.3.  SM: Example of Flow from not-RPL-aware-leaf to Internet
>
> 837   In this case the flow comprises:
>
> 839   not-RPL-aware-leaf (IPv6) --> 6LR_1 --> 6LR_i -->root (6LBR) -->
> 840   Internet
>
> 842   For example, a communication flow could be: Node G --> Node E -->
> 843   Node B --> Node A root(6LBR) --> Internet
>
> 845   The 6LR_1 (i=1) node will add an IP-in-IP(RPI) header addressed
> 846   either to the root, or hop-by-hop such that the root can remove the
> 847   RPI header before passing upwards.  The IP-in-IP addressed to the
> 848   root cause less processing overhead.  On the other hand, with hop-by-
> 849   hop the intermediate routers can check the routing tables for a
> 850   better routing path, thus it could be more efficient and faster.
> 851   Implementation should decide wich approach to take.
>
> s/wich/which
>
> [minor] The hop-by-hop option is not reflected in the table.
>
[authors] fixed.

>
>
> 853   The originating node will ideally leave the IPv6 flow label as zero
> 854   so that the packet can be better compressed through the LLN.  The
> 855   6LBR will set the flow label of the packet to a non-zero value when
> 856   sending to the Internet.
>
> 858   +---------+-----+-------------+-------------+-------------+---------+
> 859   | Header  | IPv | 6LR_1       | 6LR_i       | 6LBR        | Interne |
> 860   |         | 6   |             | [i=2,..,n]_ |             | t       |
> 861   +---------+-----+-------------+-------------+-------------+---------+
> 862   | Inserte | --  | IP-in-      | --          | --          | --      |
> 863   | d       |     | IP(RPI)     |             |             |         |
> 864   | headers |     |             |             |             |         |
> 865   | Removed | --  | --          | --          | IP-in-      | --      |
> 866   | headers |     |             |             | IP(RPI)     |         |
> 867   | Re-     | --  | --          | --          | --          | --      |
> 868   | added   |     |             |             |             |         |
> 869   | headers |     |             |             |             |         |
> 870   | Modifie | --  | --          | IP-in-      | --          | --      |
> 871   | d       |     |             | IP(RPI)     |             |         |
> 872   | headers |     |             |             |             |         |
> 873   | Untouch | --  | --          | --          | --          | --      |
> 874   | ed      |     |             |             |             |         |
> 875   | headers |     |             |             |             |         |
> 876   +---------+-----+-------------+-------------+-------------+---------+
>
> 878     Storing: Summary of the use of headers from not-RPL-aware-leaf to
> 879                                 Internet
>
> 881 6.2.4.  SM: Example of Flow from Internet to non-RPL-aware-leaf
>
> 883   In this case the flow comprises:
>
> 885   Internet --> root (6LBR) --> 6LR_i --> not-RPL-aware-leaf (IPv6)
>
> 887   For example, a communication flow could be: Internet --> Node A
> 888   root(6LBR) --> Node B --> Node E --> Node G
>
> 890   The 6LBR will have to add an RPI header within an IP-in-IP header.
> 891   The IP-in-IP is addressed to the not-RPL-aware-leaf, leaving the RPI
> 892   inside.
>
> [minor] The table below seems to be missing the not-RPL-aware-leaf
> removing the IP-in-IP header.
>
[authors] fixed.

>
> 894   Note that there is a requirement that the final node be able to
> 895   remove one or more IP-in-IP headers which are all addressed to it,
> 896   mentioned in [I-D.thubert-roll-unaware-leaves] :
>
> 898   "RPL data packets are often encapsulated using IP in IP.  The 6LN
> 899   MUST be able to decapsulate a packet when it is the destination of
> 900   the outer header and process correctly the inner header."
>
> [major] I realize that we're not reviewing I-D.thubert-roll-unaware-leaves
> at this point, but how can a requirement be placed on a not-RPL-aware-leaf
> if, by definition, it is not aware of RPL??   ...and I don't think we can
> assume it is aware of any other requirement...
>
[authors] We understand that the requirements are placed on the 6LR that
accepts the 6LN
   registration and also inject the relevant routing information on its
behalf.

>
> If this document depends on the requirement in
> I-D.thubert-roll-unaware-leaves, then the reference should be Normative (it
> is now listed as Informative).
>
[authors]fixed

>
> ...
> 935 6.3.1.  SM: Example of Flow from RPL-aware-leaf to RPL-aware-leaf
> ...
> 959   It is assume that the two nodes are in the same RPL Domain (that they
> 960   share the same DODAG root).  At the common parent (Node B), the
> 961   direction of RPI is changed (from increasing to decreasing the rank).
>
> s/assume/assumed
>
[authors]fixed

>
>
> ...
> 1079 6.3.4.  SM: Example of Flow from not-RPL-aware-leaf to not-RPL-aware-
> 1080        leaf
> ...
> 1102   The 6LR_1 (Node E) receives the packet from the the IPv6 node (Node
> 1103   G) and inserts the RPI header (RPIa), encapsulated in an
> IPv6-in-IPv6
> 1104   header.  The IPv6-in-IPv6 header is addressed to the final
> 1105   destination.
>
> [minor] As in 6.2.4, which node removes the IP-in-IP header?  For
> completion, it seems like the table is missing the fact that the "IPv6 dst"
> node ignores the RPI.
>
[authors]fixed. The not-RPL-aware leaf which is the destination removes the
IP-in-IP

>
> 1107
>  +----------+-----+-------------+--------------+--------------+------+
> 1108   | Header   | IPv | 6LR_1       | 6LR_ia       | 6LR_m        | IPv6
> |
> 1109   |          | 6   |             |              |              | dst
> |
> 1110   |          | src |             |              |              |
> |
> 1111
>  +----------+-----+-------------+--------------+--------------+------+
> 1112   | Inserted | --  | IP-in-      | --           | --           | --
>  |
> 1113   | headers  |     | IP(RPI)     |              |              |
> |
> 1114   | Removed  | --  | --          | --           | --           | --
>  |
> 1115   | headers  |     |             |              |              |
> |
> 1116   | Re-added | --  | --          | --           | --           | --
>  |
> 1117   | headers  |     |             |              |              |
> |
> 1118   | Modified | --  | --          | IP-in-       | IP-in-       | --
>  |
> 1119   | headers  |     |             | IP(RPI)      | IP(RPI)      |
> |
> 1120   | Untouche | --  | --          | --           | --           | --
>  |
> 1121   | d        |     |             |              |              |
> |
> 1122   | headers  |     |             |              |              |
> |
> 1123
>  +----------+-----+-------------+--------------+--------------+------+
>
> 1125     Storing: Summary of the use of headers from not-RPL-aware-leaf to
> 1126                            non-RPL-aware-leaf
>
> 1128 7.  Non Storing mode
> ...
> 1147   +-----------------+--------------+-----+-----+----------+----------+
> 1148   |   Interaction   |   Use Case   | RPI | RH3 | IP-in-IP | IP-in-IP |
> 1149   |      between    |              |     |     |          |    dst   |
> 1150   +-----------------+--------------+-----+-----+----------+----------+
> 1151   |                 |  Raf to root | Yes | No  |    No    |    --    |
> 1152   +                 +--------------+-----+-----+----------+----------+
> 1153   |   Leaf - Root   |  root to Raf | Opt | Yes |    No    |    --    |
> 1154   +                 +--------------+-----+-----+----------+----------+
> 1155   |                 | root to ~Raf |no(1)| Yes |    Yes   |    6LR   |
> 1156   +                 +--------------+-----+-----+----------+----------+
> 1157   |                 | ~Raf to root | Yes | No  |    Yes   |   root   |
> 1158   +-----------------+--------------+-----+-----+----------+----------+
> 1159   |                 |  Raf to Int  | Yes | No  |    Yes   |   root   |
> 1160   +                 +--------------+-----+-----+----------+----------+
> 1161   | Leaf - Internet |  Int to Raf  |no(1)| Yes |   Yes    |    dst   |
> 1162   +                 +--------------+-----+-----+----------+----------+
> 1163   |                 |  ~Raf to Int | Yes | No  |    Yes   |   root   |
> 1164   +                 +--------------+-----+-----+----------+----------+
> 1165   |                 |  Int to ~Raf |no(1)| Yes |    Yes   |    6LR   |
> 1166   +-----------------+--------------+-----+-----+----------+----------+
> 1167   |                 |  Raf to Raf  | Yes | Yes |    Yes   | root/dst |
> 1168   +                 +--------------+-----+-----+----------+----------+
> 1169   |                 |  Raf to ~Raf | Yes | Yes |    Yes   | root/6LR |
> 1170   +   Leaf - Leaf   +--------------+-----+-----+----------+----------+
> 1171   |                 |  ~Raf to Raf | Yes | Yes |    Yes   | root/6LN |
> 1172   +                 +--------------+-----+-----+----------+----------+
> 1173   |                 | ~Raf to ~Raf | Yes | Yes |    Yes   | root/6LR |
> 1174   +-----------------+--------------+-----+-----+----------+----------+
>
> 1176   (1)-6tisch networks may need the RPI information.
>
> [major] When?  What are the conditions when it is needed?
>
[authors] fixed.
<t>
  The leaf can be a router 6LR or a host, both indicated as 6LN (Figure 3).
In the Figure they
  (1) indicates a 6tisch case <xref target="RFC8180"/>, where the
  instanceID portion of the RPI header may still be needed to
  pick an appropriate priority or channel at each hop.
</t>

>
> 1178     Figure 8: Headers needed in Non-Storing mode: RPI, RH3, IP-in-IP
> 1179                              encapsulation.
> ...
> 1194 7.1.1.  Non-SM: Example of Flow from RPL-aware-leaf to root
>
> 1196   In non-storing mode the leaf node uses default routing to send
> 1197   traffic to the root.  The RPI header must be included to
> avoid/detect
> 1198   loops.
>
> [major] Should that "must" be Normative?
>
[authors] fixed.

>
> ...
> 1224 7.1.2.  Non-SM: Example of Flow from root to RPL-aware-leaf
> ...
> 1236   The 6LBR will insert an RH3, and may optionally insert an RPI
> header.
>
> [major] Under which conditions should the RPI header be inserted?  Or is
> it the case where it is not necessary, but it causes no harm if it's
> there?  Are there benefits?  It would be nice to be precise in the
> specification to achieve consistent behavior.
>
[authors]rewritten.

>
> ...
> 1254 7.1.3.  Non-SM: Example of Flow from root to not-RPL-aware-leaf
> ...
> 1267   In 6LBR the RH3 is added, it is modified at each intermediate 6LR
> 1268   (6LR_1 and so on) and it is fully consumed in the last 6LR (6LR_n),
> 1269   but left there.  If RPI is left present, the IPv6 node which does
> not
> 1270   understand it will ignore it (following RFC8200), thus encapsulation
> 1271   is not necesary.  Due the complete knowledge of the topology at the
> 1272   root, the 6LBR may optionally address the IP-in-IP header to the
> last
> 1273   6LR, such that it is removed prior to the IPv6 node.
>
> s/necesary/necessary
>
> [major] So...encapsulation is not needed, but an IP-in-IP header is
> optional.  When?  Are there advantages, disadvantages?   Same questions
> about the RPI.
>
[authors]rewritten.

>
> 1275
>  +---------------+-------------+---------------+--------------+------+
> 1276   | Header        | 6LBR        | 6LR_i(i=1)    | 6LR_n(i=n)   | IPv6
> |
> 1277
>  +---------------+-------------+---------------+--------------+------+
> 1278   | Inserted      | (opt: RPI), | --            | --           | --
>  |
> 1279   | headers       | RH3         |               |              |
> |
> 1280   | Removed       | --          | RH3           | --           | --
>  |
> 1281   | headers       |             |               |              |
> |
> 1282   | Re-added      | --          | --            | --           | --
>  |
> 1283   | headers       |             |               |              |
> |
> 1284   | Modified      | --          | (opt: RPI),   | (opt: RPI),  | --
>  |
> 1285   | headers       |             | RH3           | RH3          |
> |
> 1286   | Untouched     | --          | --            | --           | RPI
> |
> 1287   | headers       |             |               |              |
> |
> 1288
>  +---------------+-------------+---------------+--------------+------+
>
> [minor] In this case, the destination node would also leave the RH3 header
> untouched, right?
>
[authors]table fixed. the RH3 is consumed by the 6LRn

>
> 1290     Non Storing: Summary of the use of headers from root to not-RPL-
> 1291                                aware-leaf
>
> [minor] This table (and several others) have no name/number.
>
[authors]table fixed.

>
> ...
> 1375 7.2.2.  Non-SM: Example of Flow from Internet to RPL-aware-leaf
> ...
> 1393   The RPI may be added or not as required by networks such as 6tisch.
>
> [major] When would that be?  Is there a reference?
>
[authors] removed.

>
> 1394   The RPI is unnecessary for loop detection.
>
> [major] Yet the Table shows it...when would it be used, why, etc.?
>
[authors] fixed.

>
> 1396
>  +----------+---------+--------------+---------------+---------------+
> 1397   | Header   | Interne | 6LBR         | 6LR_i         | 6LN
>  |
> 1398   |          | t       |              |               |
>  |
> 1399
>  +----------+---------+--------------+---------------+---------------+
> 1400   | Inserted | --      | IP-in-IP (RH | --            | --
> |
> 1401   | headers  |         | 3,opt:RPI)   |               |
>  |
> 1402   | Removed  | --      | --           | --            | IP-in-IP
> |
> 1403   | headers  |         |              |               | (RH3,opt:RPI)
> |
> 1404   | Re-added | --      | --           | --            | --
> |
> 1405   | headers  |         |              |               |
>  |
> 1406   | Modified | --      | --           | IP-in-IP      | --
> |
> 1407   | headers  |         |              | (RH3,opt:RPI) |
>  |
> 1408   | Untouche | --      | --           | --            | --
> |
> 1409   | d        |         |              |               |
>  |
> 1410   | headers  |         |              |               |
>  |
> 1411
>  +----------+---------+--------------+---------------+---------------+
>
> 1413     Non Storing: Summary of the use of headers from Internet to RPL-
> 1414                                aware-leaf
>
> ...
> 1566 7.3.2.  Non-SM: Example of Flow from RPL-aware-leaf to not-RPL-aware-
> 1567        leaf
> ...
> 1583   As in the previous case, the 6LN will insert an RPI (RPI_1) header
> 1584   which MUST be in an IP-in-IP header addressed to the root so that
> the
> 1585   6LBR can remove this RPI.  The 6LBR will then insert an RH3 inside a
> 1586   new IP-in-IP header addressed to the 6LN destination node.  The RPI
> 1587   is optional from 6LBR to 6LR_id (RPI_2).
>
> [minor] The text says that the "new IP-in-IP header [is] addressed to the
> 6LN destination node", but the Table below shows the 6LR_id removing it.
>
[authors] fixed.

>
> 1589
>  +-----------+----------+----------+------------+------------+-------+
> 1590   | Header    | 6LN      | 6LR_1    | 6LBR       | 6LR_id     | IPv6
> |
> 1591
>  +-----------+----------+----------+------------+------------+-------+
> 1592   | Inserted  | IP-in-IP | --       | IP-in-IP   | --         | --
> |
> 1593   | headers   | (RPI1)   |          | (RH3, opt  |            |
>  |
> 1594   |           |          |          | RPI_2)     |            |
>  |
> 1595   | Removed   | --       | --       | IP-in-IP   | IP-in-IP   | --
> |
> 1596   | headers   |          |          | (RPI_1)    | (RH3, opt  |
>  |
> 1597   |           |          |          |            | RPI_2)     |
>  |
> 1598   | Re-added  | --       | --       | --         | --         | --
> |
> 1599   | headers   |          |          |            |            |
>  |
> 1600   | Modified  | --       | IP-in-IP | --         | IP-in-IP   | --
> |
> 1601   | headers   |          | (RPI_1)  |            | (RH3, opt  |
>  |
> 1602   |           |          |          |            | RPI_2)     |
>  |
> 1603   | Untouched | --       | --       | --         | --         | opt
>  |
> 1604   | headers   |          |          |            |            | RPI_2
> |
> 1605
>  +-----------+----------+----------+------------+------------+-------+
>
> 1607     Non Storing: Summary of the use of headers from RPL-aware-leaf to
> 1608                            not-RPL-aware-leaf
>
> ...
> 1654 7.3.4.  Non-SM: Example of Flow from not-RPL-aware-leaf to not-RPL-
> 1655        aware-leaf
> ...
> 1674
>  +------------+-------+-----------+------------+-------------+-------+
> 1675   | Header     | IPv6  | 6LR_1     | 6LBR       | 6LR_id      | IPv6
> |
> 1676   |            | src   |           |            |             | dst
>  |
> 1677
>  +------------+-------+-----------+------------+-------------+-------+
> 1678   | Inserted   | --    | IP-in-IP  | IP-in-IP   | --          | --
> |
> 1679   | headers    |       | (RPI_1)   | (RH3)      |             |
>  |
> 1680   | Removed    | --    | --        | IP-in-IP   | IP-in-IP    | --
> |
> 1681   | headers    |       |           | (RPI_1)    | (RH3, opt   |
>  |
> 1682   |            |       |           |            | RPI_2)      |
>  |
> 1683   | Re-added   | --    | --        | --         | --          | --
> |
> 1684   | headers    |       |           |            |             |
>  |
> 1685   | Modified   | --    | --        | --         | --          | --
> |
> 1686   | headers    |       |           |            |             |
>  |
> 1687   | Untouched  | --    | --        | --         | --          | --
> |
> 1688   | headers    |       |           |            |             |
>  |
> 1689
>  +------------+-------+-----------+------------+-------------+-------+
>
> [minor] The optional RPI_2 is not indicated in the 6LBR column.
>
[authors] fixed.

>
>
> ...
> 1696 8.1.  Storing mode
> ...
> 1705   Thanks to the change of the RPI option type from 0x63 to 0x23, there
> 1706   is no longer any uncertainty about when to use an IP-in-IP header in
> 1707   the storing mode.  A Hop-by-Hop Options Header containing the RPI
> 1708   option SHOULD always be added when 6LRs originate packets (without
> 1709   IP-in-IP headers), and IP-in-IP headers should always be added
> 1710   (addressed to the root when on the way up, to the end-host when on
> 1711   the way down) when a 6LR find that it needs to insert a Hop-by-Hop
> 1712   Options Header containing the RPI option.
>
> [major] This paragraph starts by saying that "there is no longer any
> uncertainty about when to use an IP-in-IP header".  However, the
> specification is a "SHOULD", which means that there are cases when the
> action may not be performed.  It sounds like a contradiction to me.  In any
> case, what are the cases that make it a "SHOULD" and not a "MUST"?
>

[authors]rewritten.
<t>
  The change of RPI option type from 0x63 to 0x23, makes all
  <xref target="RFC8200"/> Section 4.2 compliant nodes tolerant of the RPL
artifacts.  There
  is therefore no longer a necessity to remove the artifacts when
  sending traffic to the Internet.  This change clarifies when
  to use an IPv6-in-IPv6 header, and how to address them:
  The Hop-by-Hop Options Header containing the RPI option SHOULD always
  be added when 6LRs originate packets (without IPv6-in-IPv6
  headers), and IPv6-in-IPv6 headers SHOULD always be added
  when a 6LR find that it needs to insert a Hop-by-Hop Options Header
  containing the RPI option.  The IPv6-in-IPv6 header is to
  be addressed to the
  RPL root when on the way up, and to the end-host when on the way down.
</t>

>
> [major] Should this text include a "SHOULD" as well: "and IP-in-IP headers
> should always be added..."?
>

[authors]It’s SHOULD so that non-LLN uses of RPL can change this.

>
> ...
> 1731 9.  6LoRH Compression cases
>
> 1733   The [RFC8138] proposes a compression method for RPI, RH3 and
> IPv6-in-
> 1734   IPv6.
>
> 1736   In Storing Mode, for the examples of Flow from RPL-aware-leaf to
> non-
> 1737   RPL-aware-leaf and non-RPL-aware-leaf to non-RPL-aware-leaf comprise
> 1738   an IP-in-IP and RPI compression headers.  The type of this case is
> 1739   critical since IP-in-IP is encapsulating a RPI header.
>
> 1741
>  +--+-----+---+--------------+-----------+-------------+-------------+
> 1742   |1 | 0|0 |TSE| 6LoRH Type 6 | Hop Limit | RPI - 6LoRH | LOWPAN IPHC
> |
> 1743
>  +--+-----+---+--------------+-----------+-------------+-------------+
>
> 1745                    Figure 9: Critical IP-in-IP (RPI).
>
> [major] Shouldn't this section also be an Update to rfc8138?
>
> [major] 6LoRH Type 6 is defined in rfc8138 as an elective type, but it is
> introduced as Critical here.  The header must then be completely specified
> in this document and the appropriate registry must be updated (in the IANA
> Consideration section).
>
> Specifically...referring to rfc8138...
>    - the meaning of the TSE depends on the Type (§4.2),
>    - the Hop Limit is defined in §7, should it have the same
> behavior/meaning here?
>    - does the "RPI - 6LoRH" field correspond to the RPI-6LoRH header
> (§6.3)?
>    - I'm assuming that the "LOWPAN IPHC" field refers to LOWPAN_IPHC
> (rfc6282).
>

[authors] we think that the confusion is because we wrote: “The type of
this case”...
which sounds like we are changing 8138, when what we mean is that use of
this elective type is a MUST for RPL.
Type 6 (compressed RPI) is elective in 8138 because non-RPL uses of 6lowpan
do not
need to support (compressed) RPI headers, but this document makes it a MUST
because
RPL uses of 6lowpan need it. Is there text that we need to update?

>
> ...
> 1774 11.  Security Considerations
>
> 1776   The security considerations covering of [RFC6553] and [RFC6554]
> apply
> 1777   when the packets get into RPL Domain.
>
> s/covering of/covered in
>
> [minor] Do you mean "are in the RPL Domain" instead of "get into" it?  Or
> are you talking about when a packet comes into the domain from a
> non-RPL-aware node (like a non-RPL-aware-leaf)?  I ask because it seems to
> me that those RFCs only talk about packets that are inside the domain (and
> not about them getting in).
>
[authors] fixed.

>
> 1779   The IPIP mechanism described in this document is much more limited
> 1780   than the general mechanism described in [RFC2473].  The willingness
> 1781   of each node in the LLN to decapsulate packets and forward them
> could
> 1782   be exploited by nodes to disguise the origin of an attack.
>
> 1784   Nodes outside of the LLN will need to pass IPIP traffic through the
> 1785   RPL root to perform this attack.  To counter, the RPL root SHOULD
> 1786   either restrict ingress of IPIP packets (the simpler solution), or
> it
> 1787   SHOULD do a deep packet inspection wherein it walks the IP header
> 1788   extension chain until it can inspect the upper-layer-payload as
> 1789   described in [RFC7045].  In particular, the RPL root SHOULD do BCP38
> 1790   ([RFC2827]) processing on the source addresses of all IP headers
> that
> 1791   it examines in both directions.
>
> [major] For all 3 SHOULDs above...  Why are they not a MUST?  IOW, when
> (if countering) would the actions not be performed?  Are there other
> mechanisms that the root could consider?
>

[authors]We are being conservative in writing SHOULD, because it these
mechanism
 are not externally visible, an implementer could do something different
(better?
  Faster? cheaper?) if it had the same effect.  For instance, an upstream
firewall
   could do the BCP38 filtering or IPIP filtering. Deep Packet Inspection is
   distasteful, but only necessary if there is a need to accept some IPIP
headers.

>
> 1793   Note: there are some situations where a prefix will spread across
> 1794   multiple LLNs via mechanisms such as described in
> 1795   [I-D.ietf-6lo-backbone-router].  In this case the BCP38 filtering
> 1796   needs to take this into account.
>
> s/such as described/such as the one described
>
> [major] The text above sounds like the root needs to get some type of
> routing information from the other LLN, is that true?  What are the
> security implications of that?
>
> I took a very quick look at I-D.ietf-6lo-backbone-router and it seems to
> me that there are probably other considerations to be included related to
> that mechanism in the context of this document.  Given the "in passing"
> nature of the note above, and the fact that I-D.ietf-6lo-backbone-router is
> still in process in 6lo, I suggest you take the text/reference out.
>

[authors]Discussion on the list.

>
> 1798   Nodes with the LLN can use the IPIP mechanism to mount an attack on
> 1799   another part of the LLN, while disguising the origin of the attack.
> 1800   The mechanism can even be abused to make it appear that the attack
> is
> 1801   coming from outside the LLN, and unless countered, this could be
> used
> 1802   to mount a Distributed Denial Of Service attack upon nodes elsewhere
> 1803   in the Internet.  See [DDOS-KREBS] for an example of such attacks
> 1804   already seen in the real world.
>
> s/Nodes with the LLN/Nodes within the LLN
>
> [major] Is there any possible mitigation to this inside-the-LLN attack?
> It seems to me that this issue is not something introduced by this
> document, right?  Would authentication help -- is it even possible? Is
> there a discussion of this in the main spec?
>

[authors]Discussion on the list.

>
> 1806   While a typical LLN may be a very poor origin for attack traffic (as
> 1807   the networks tend to be very slow, and the nodes often have very low
> 1808   duty cycles) given enough nodes, they could still have a significant
> 1809   impact, particularly if the attack was on another LLN!
> Additionally,
> 1810   some uses of RPL involve large backbone ISP scale equipment
> 1811   [I-D.ietf-anima-autonomic-control-plane], which may be equipped with
> 1812   multiple 100Gb/s interfaces.
>
> [nit] Suggestion: reorder the paragraphs so that the discussion of the
> internal threats starts in the third paragraph.  It should improve
> readability and may avoid some repetition.
>
[authors]fixed.

>
> 1814   Blocking or careful filtering of IPIP traffic entering the LLN as
> 1815   described above will make sure that any attack that is mounted must
> 1816   originate compromised nodes within the LLN.  The use of BCP38
> 1817   filtering at the RPL root on egress traffic will both alert the
> 1818   operator to the existence of the attack, as well as drop the attack
> 1819   traffic.  As the RPL network is typically numbered from a single
> 1820   prefix, which is itself assigned by RPL, BCP38 filtering involves a
> 1821   single prefix comparison and should be trivial to automatically
> 1822   configure.
>
> s/originate compromised/originate from compromised
>
> [major] Yes, BCP38 will stop an attack, but only if the source addresses
> are spoofed.  What if they're not?  Given that the attack may be hidden,
> and assuming that nodes are compromised across multiple LLNs, an attacker
> may not care enough to spoof the origins.
>
[authors]To be disscussed on list

>
> 1824   There are some scenarios where IPIP traffic SHOULD be allowed to
> pass
> 1825   through the RPL root, such as the IPIP mediated communications
> 1826   between a new Pledge and the Join Registrar/Coordinator (JRC) when
> 1827   using [I-D.ietf-anima-bootstrapping-keyinfra] and
> 1828   [I-D.ietf-6tisch-dtsecurity-secure-join].  This is the case for the
> 1829   RPL root to do careful filtering: it occurs only when the Join
> 1830   Coordinator is not co-located inside the RPL root.
>
> [major] Because of the "SHOULD", both references should be Normative.  The
> second ID is Informational.  Does that really need to be a "SHOULD"??  It
> seems to me that "should" would be enough in this case.
>
[authors]fixed.

>
> [minor] I'm having trouble parsing the last sentence.  What are you trying
> to suggest?
>
[authors] when an entity called Join coordinator is not included inside the
root,
the root should allow the IPIP traffic.

>
> 1832   With the above precautions, an attack using IPIP tunnels will be by
> a
> 1833   node within the LLN on another node within the LLN.  Such an attack
> 1834   could, of course, be done directly.  An attack of this kind is
> 1835   meaningful only if the source addresses are either fake or if the
> 1836   point is to amplify return traffic.  Such an attack, could also be
> 1837   done without the use of IPIP headers using forged source addresses.
>
> 1839   If the attack requires bi-directional communication, then IPIP
> 1840   provides no advantages.
>
> 1842   [RFC2473] suggests that tunnel entry and exit points can be secured,
> 1843   via the "Use IPsec".  This solution has all the problems that
>
> [minor] "This solution"...which one?  The rfc2473 suggestion or the one
> described in this document?
>

[authors]rewritten

>
> 1844   [RFC5406] goes into.  In an LLN such a solution would degenerate
> into
> 1845   every node having a tunnel with every other node.  It would provide
> a
> 1846   small amount of origin address authentication at a very high cost;
> 1847   doing BCP38 at every node (linking layer-3 addresses to layer-2
> 1848   addresses, and to already present layer-2 cryptographic mechanisms)
> 1849   would be cheaper should RPL be run in an environment where hostile
> 1850   nodes are likely to be a part of the LLN.
>
> 1852   The RH3 header usage described here can be abused in equivalent ways
> 1853   with an IPIP header to add the needed RH3 header.  As such, the
> 1854   attacker's RH3 header will not be seen by the network until it
> 1855   reaches the end host, which will decapsulate it.  An end-host SHOULD
> 1856   be suspicious about a RH3 header which has additional hops which
> have
> 1857   not yet been processed, and SHOULD ignore such a second RH3 header.
>
> [nit] Hmmm...it seems like these threats should have been identified in
> rfc6554...
>
> [major] What does "SHOULD be suspicious" mean?  How is that a Normative
> behavior?  Would being suspicious include dropping the packet or some other
> similar action?  When would the router *not* be suspicious?  Why is that
> not a "MUST"?
>

[authors]The presence of the second RH3 means that there is a configuration
 mistake somewhere else in the network.  It would be reasonable to increment
  a counter in a MIB (if we had a MIB) when this occurs.  Based upon the
Postel
   doctrine, ignoring the extra header (not acting on it), is the best
policy.
    An RH3 header was not completely consumed is discussed in RFC

https://tools.ietf.org/html/rfc6554#section-4.2 says that an RH3 header with
 additional “non-zero Segments Left value, if the IPv6 Destination Address
is
  not on-link” should be dropped.  In this case, the RH3 header is *inside*
  the outer IPv6-in-IPv6 header, which has then been forwarded.
We think that this header should simply be ignored in processing the packet.
 To do otherwise (such as forwarding) would permit external attackers to
send
 traffic that appears to originate inside the LLN.

 To be discussed on list

>
> [major] When should a second RH3 header not be ignored?  Why is "MUST" not
> used?
>

 [authors]Unsure of whether there are uses in the future for this kind of
thing.

>
> 1859   In addition, the LLN will likely use [RFC8138] to compress the IPIP
> 1860   and RH3 headers.  As such, the compressor at the RPL-root will see
> 1861   the second RH3 header and MAY choose to discard the packet if the
> RH3
> 1862   header has not been completely consumed.  A consumed (inert) RH3
>
> [major] It seems to me that the optional action of the root of discarding
> the packet is is contradiction with the "SHOULD ignore such a second RH3
> header" above.  Is the subtle difference that we're talking about the root
> here, and the end-host above?  Why wouldn't the actions be the same if in
> both cases the second RH3 header may indicate some type of attack, or at
> least something anomalous??
>

[authors] If the root ALWAYS discards such packets, then if someone comes up
 with a use for them, then they need to adjust two systems to make it work,
  creating a flag day situation for that new feature.  By saying MAY, we are
   suggesting that a knob is probably appropriate.

>
> 1863   header could be present in a packet that flows from one LLN, crosses
> 1864   the Internet, and enters another LLN.  As per the discussion in this
> 1865   document, such headers do not need to be removed.  However, there is
> 1866   no case described in this document where an RH3 is inserted in a
> non-
> 1867   storing network on traffic that is leaving the LLN, but this
> document
> 1868   SHOULD NOT preclude such a future innovation.  It should just be
> 1869   noted that an incoming RH3 must be fully consumed, or very carefully
> 1870   inspected.
>
> [major] The "SHOULD NOT" seems out of place as there is nothing Normative
> in the statement.
>
[authors]fixed.

>
> [major] What does "very carefully inspected" mean?  Are there actions
> resulting from that?
>

[authors]Subject to extensive Access Control Lists, if permitted.

>
> 1872   The RPI header, if permitted to enter the LLN, could be used by an
> 1873   attacker to change the priority of a packet by selecting a different
> 1874   RPL instanceID, perhaps one with a higher energy cost, for instance.
>
> s/RPL instanceID/RPLinstanceID
>
[authors]fixed.

>
> ...
> 1911 13.1.  Normative References
>
> [minor] I think that the following references can be made Informative:
> RFC2473, RFC5406
>
[authors]fixed.

>
> ...
> 1965 13.2.  Informative References
>
> [nit] I-D.ietf-6man-rfc6434-bis is not referenced in the text.
>
[authors]fixed.

Many thanks again Alvaro!!!

>
> Datatracker URL:
> https://datatracker.ietf.org/doc/draft-ietf-roll-useofrplinfo/
>
>