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

Ines Robles <mariainesrobles@googlemail.com> Fri, 05 November 2021 19:29 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 8BF8F3A0C74; Fri, 5 Nov 2021 12:29:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 vwy0chdXxd-b; Fri, 5 Nov 2021 12:29:03 -0700 (PDT)
Received: from mail-ua1-x936.google.com (mail-ua1-x936.google.com [IPv6:2607:f8b0:4864:20::936]) (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 E8B423A0C75; Fri, 5 Nov 2021 12:29:02 -0700 (PDT)
Received: by mail-ua1-x936.google.com with SMTP id az37so18970073uab.13; Fri, 05 Nov 2021 12:29:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ecolKgRvcHJRxHfkG/F0gQNdG7f4BOEkBpZqfdbA/oU=; b=ZqoLhKxxj24rSPOXBMJef91yDComlDRU7QNje2XIUA9OfwgiaV62QRhvPCc8fzaWFL IQa8atQKBBc6CP7zL3l3gAEvizvkE5Uk70ZbpiidrbEnw99SSMUZXZGNJ8vTwyxUmmPP z6fpLUhT/iLKdaoTpDdeKfsvcvI7E8+r4nrdXgfzV7LPK8HQOrgJb5WzM45dKbuhQx4R Y6ioDiNk9KYXdTEUBp0GegAMC5JAHtw89AyEQiAPkpXjRVR8XDnJtD4sam//clxTxwcj 2m6dQOTcOHKhInpHqXVeb7asHAO/pZ522+Jl/t8BdNd9WYLtWGZL3XGKs7ls7eO75ghn RKpA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ecolKgRvcHJRxHfkG/F0gQNdG7f4BOEkBpZqfdbA/oU=; b=AFvvssLfjC+jbqAOJNeLYdNA6X8YQjipwde3DsV+LWHktTj92ZRZidMpxH4ov4LF+Y HQar6cvkcNzuA3WaNPFvwP9SBjwBWO316TA97wtPs0Z6TUSGK7nyIJOrwbFRnOIq00tc D7sP0W2AU/YR9btBmoVcUZA26tTro6mlS+/JYItEgsdfcGmJW4AV1dIw0jB1NH+Fvh3W Q+BFvoyQ/coTN7tsA0YDVGEKNPMKO29/OD0+oVo8B1xtFnvh2qF6V3mx5yH2aKPbxShP sQgFaHX9fQNhANnQpW6W9T7Iap0JA0dl6qeDKLalAZdy7e0PfndVo4/TkhMXxdYHYcU1 bwkg==
X-Gm-Message-State: AOAM530lxjnYLCwP7Z1znsfIJKjfTRSzS/l/Fq7am+YtCy44ZI07LdPC gkrabnmpDc+bO7kOWhM2esEeE2alOolBQl+IMjpAawgjxts=
X-Google-Smtp-Source: ABdhPJwC8CfymAQ4BFnbsyIMuyLvwadnwItOD1z3iWqf/gxCTeKfn7syEoU4AMeyJTzxzdWlgFgfwywKMf+k4X0Ukhg=
X-Received: by 2002:ab0:3813:: with SMTP id x19mr51048459uav.56.1636140541119; Fri, 05 Nov 2021 12:29:01 -0700 (PDT)
MIME-Version: 1.0
References: <161886431878.23690.10633892549620498188@ietfa.amsl.com> <f80a127b-55a7-9ef6-d7b1-5b6358b1a61d@earthlink.net>
In-Reply-To: <f80a127b-55a7-9ef6-d7b1-5b6358b1a61d@earthlink.net>
From: Ines Robles <mariainesrobles@googlemail.com>
Date: Fri, 5 Nov 2021 21:28:24 +0200
Message-ID: <CAP+sJUfcy0Pn1E5C_Y03r4hxdFAJNvFkHNn1jUAX8xe-HfdM7g@mail.gmail.com>
To: John Scudder via Datatracker <noreply@ietf.org>
Cc: John Scudder <jgs@juniper.net>, Routing Over Low power and Lossy networks <roll@ietf.org>, The IESG <iesg@ietf.org>, roll-chairs <roll-chairs@ietf.org>, draft-ietf-roll-aodv-rpl@ietf.org, Charlie Perkins <charles.perkins@earthlink.net>, Alvaro Retana <aretana.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000c18f0d05d00fa739"
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/_Gj5qibd4iT3mh8EyA72WXfTsjI>
Subject: Re: [Roll] John Scudder's Discuss on draft-ietf-roll-aodv-rpl-10: (with DISCUSS and COMMENT)
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: Fri, 05 Nov 2021 19:29:10 -0000

Hello John,

Thank you for your comments to improve the document. We believe that v11
addresses your DISCUSS points, please let us know.

Please find comments below corresponding to version 11 in [v11]

----------------------------------------------------------------------

DISCUSS:

----------------------------------------------------------------------

A lot of effort has clearly gone into this work, thank you. I do have one
topic

I want to DISCUSS, as it seriously impacted the readability of the document

from my point of view. I don’t anticipate that it will be very difficult to

resolve this DISCUSS as it relates to clarity and not to anything
fundamental.

My chief difficulty with the document is placing it in context. No hints are

given to the reader as to what the expected network environment is. I think
it

would be almost sufficient to say, for example “the network environment is

assumed to be the same as described in RFC 6550, Section 1” for example, but

without that hint and without a strong background in ROLL, I found myself

struggling. Figures 4 and 5 in particular lead me to believe the expected

environment looks similar to a classic ISP network — a collection of nodes

connected by point-to-point links. If this isn’t correct (and I bet it’s
not)

that may have led me into incorrect assumptions, which may be reflected in
my

other comments below.

[v11] Page 3, new text: The network environment that is considered in this

   document is assumed to be the same as described in Section 1 of
<https://datatracker.ietf.org/doc/html/rfc6550#section-1>

   [RFC6550] <https://datatracker.ietf.org/doc/html/rfc6550#section-1>.


Further, it’s not stated anywhere whether AODV-RPL is intended to stand
alone

as its own routing protocol, or to be viewed as an extension of RPL. In the

former case, it seems the document is lacking details that are present in
RFC

6550. I’m assuming the latter is the case, but a clear statement to that
effect

seems indicated.

[v11] Page 3, new text: AODV-RPL reuses and extends the core RPL
functionality to support

   routes with bidirectional asymmetric links



----------------------------------------------------------------------

COMMENT:

----------------------------------------------------------------------

1. Section 1:

   Reply.  AODV-RPL currently omits some features compared to AODV -- in

   particular, flagging Route Errors, blacklisting unidirectional links,

   multihoming, and handling unnumbered interfaces.

Your use of language is entirely up to you, but I feel obliged to point out

that there’s been a lot of discussion in the IETF community recently about
use

of language that raises sensitive points, and about the term “blacklisting”
in

particular. I understand that this is the only place in the document the
term

appears, and since it refers to AODV you can’t just use another term, but

placing it in quotation marks might make it clear that it’s referring
verbatim

to the language of RFC 3561.

[v11] (Page 3), new text:  AODV-RPL currently omits some features compared
to AODV -- in

   particular, flagging Route Errors, "blacklisting" unidirectional

   links ([RFC3561 <https://datatracker.ietf.org/doc/html/rfc3561>]),
multihoming, and handling unnumbered interfaces.


2. Section 1:

  support for storing and non-storing modes.  AODV adds basic messages

  RREQ and RREP as part of RPL DIO (DODAG Information Object) control

Did you mean “AODV-RPL adds”?


[v11] Page 3: It was changed to AODV-RPL adds basic messages


3. Section 2:

   Symmetric route

      The upstream and downstream routes traverse the same routers.

Same routers? Or same links? (Or both, if multi-access links are part of the

mix, as I imagine they may be?)

[v11] Page 5, new text: Symmetric route: The upstream and downstream routes
traverse the same routers and

      over the same links.


4. Section 4.1:

   OrigNode sets its IPv6 address in the DODAGID field of the RREQ-DIO

   message.  A RREQ-DIO message MUST carry exactly one RREQ option,

Should that say “one of its IPv6 addresses"? Is it even necessary to restate

this? RFC 6550 §6.3.1 already has a clearer requirement:

   DODAGID: 128-bit IPv6 address set by a DODAG root that uniquely

         identifies a DODAG.  The DODAGID MUST be a routable IPv6

         address belonging to the DODAG root.

[v11] Page 6-New text: OrigNode selects one of its IPv6 addresses and sets
it in the DODAGID

   field of the RREQ-DIO message.


5. Section S4.1:

  TargNode can join the RREQ instance at a Rank whose integer portion

  is equal to the MaxRank.

Not less than or equal, right? Strict equality to MaxRank is required?

[v11] Page 8, new text: TargNode can join the RREQ instance at a Rank whose
integer portion

   is less than or equal to the MaxRank.


6. Section 4.2:

   TargNode sets its IPv6 address in the DODAGID field of the RREP-DIO

   message.  A RREP-DIO message MUST carry exactly one RREP option,

Same as #4.

[v11] Page 8, new text: TargNode sets one of its IPv6 addresses in the
DODAGID field of the

   RREP-DIO message.


7. Section 4.2:

  Address Vector

     Only present when the H bit is set to 0.  For an asymmetric route,

     the Address Vector represents the IPv6 addresses of the route that

     the RREP-DIO has passed.

The first time I read through this, I didn’t understand it at all. On

re-reading, I think you’re using the word “route” in two different ways in
the

same sentence, the first time to mean “route” in the sense of an object in
the

protocol, the second time in the more casual sense of “a path through the

network”. If that’s right, I suggest rewriting the second instance, as in “…

represents the IPv6 addresses of the path through the network the RREP-DIO
has

Traversed.”

[v11] Page 10, new text: Address Vector

      Only present when the H bit is set to 0.  For an asymmetric route,

      the Address Vector represents the IPv6 addresses of the path

      through the network the RREP-DIO has passed.

Passed was not changed to Traversed.


Also, as in point #4, is it right to say *the* IPv6 addresses? Couldn’t any

given node have various IPv6 addresses? So maybe just lose the definite

article, as in “… represents IPv6 addresses of the path…”?

8. Section 4.3:

  r

     A one-bit reserved field.  This field MUST be initialized to zero

     by the sender and MUST be ignored by the receiver.

The figure doesn’t show an “r” field. I assume the field labeled “X” should
be

relabeled as “r”?

[v11] Page 11: changed to X.

9. Section 5:

   Figure 4.  If an intermediate router sends out RREQ-DIO with the S

   bit set to 1, then all the one-hop links on the route from the

   OrigNode O to this router meet the requirements of route discovery,

On first reading I didn’t understand this. Having read the whole document, I

now get it (I think!). Possibly changing “meet” to “have met” would have
been

enough to get me past my initial befuddlement.

[v11] Page 11: changed to “has met”

10. Section 5:

   The criteria used to determine whether or not each link is symmetric

   is beyond the scope of the document.  For instance, intermediate

Should be “criterion … is beyond", or "criteria … are beyond", depending on

whether you want singular or plural.

[v11] Page12, Not Corrected. [Can this be addressed by the RFC Editor?]



11. Section 5:

  routers can use local information (e.g., bit rate, bandwidth, number

  of cells used in 6tisch)

I wouldn’t have minded a reference for 6tisch.

[v11]Page 12, reference added, new text: ...cells used in 6tisch [RFC9030
<https://datatracker.ietf.org/doc/html/rfc9030>])...


12. Section 5:

   Upon receiving a RREQ-DIO with the S bit set to 1, a node determines

   whether this one-hop link can be used symmetrically, i.e., both the

   two directions meet the requirements of data transmission.  If the

   RREQ-DIO arrives over an interface that is not known to be symmetric,

   or is known to be asymmetric, the S bit is set to 0.  If the S bit

   arrives already set to be '0', it is set to be '0' on retransmission

The term “retransmission” seems misused here. I guess you mean something
like

“when the RREQ-DIO is propagated”.

[v11] Page 12, changed to propagated: ..when the RREQ-DIO is propagated.

13. Section 5:

  Appendix A describes an example method using the upstream Expected

  Number of Transmissions" (ETX) and downstream Received Signal

  Strength Indicator (RSSI) to estimate whether the link is symmetric

  in terms of link quality is given in using an averaging technique.

This sentence needs a rewrite to make it grammatical. It works up until "is

given in using an averaging technique”.

[v11] Page 13, new text: “ Appendix A
<https://datatracker.ietf.org/doc/html/draft-ietf-roll-aodv-rpl-11#appendix-A>
describes an example method using the upstream Expected

   Number of Transmissions (ETX) and downstream Received Signal Strength

   Indicator (RSSI) to estimate whether the link is symmetric in terms

   of link quality using an averaging technique.”

14. Section 6.2.1:

     If the S bit in the received RREQ-DIO is set to 1, the router MUST

     determine whether each direction of the link (by which the RREQ-

     DIO is received) satisfies the Objective Function.  In case that

     the downward (i.e. towards the TargNode) direction of the link

     does not satisfy the Objective Function, the link can't be used

     symmetrically, thus the S bit of the RREQ-DIO to be sent out MUST

     be set as 0.  If the S bit in the received RREQ-DIO is set to 0,

     the router MUST determine into the upward direction (towards the

     OrigNode) of the link.

The last sentence doesn’t make sense.

[v11] Page 14, Step 1 section was re-written, new text:”Step 1:

      The router MUST first determine whether to propagate the RREQ-DIO.

      It does this by determining whether or not the downstream

      direction of the incoming link satisfies the Objective Function

      (OF).  If not the RREQ-DIO MUST be dropped, and the following

      steps are not processed.  Otherwise, the router MUST join the

      RREQ-Instance and prepare to propagate the RREQ-DIO.  The upstream

      neighbor router that transmitted the received RREQ-DIO is selected

      as the preferred parent.”

15. Section 6.2.1:

     If the router is an intermediate router, then it transmits a RREQ-

     DIO via link-local multicast;

On what interface? Routers generally can have multiple interfaces. Again,
this

is a place a clear description of the network environment might have helped.

[v11] Page 15, Step 4 new text as follows: “Step 4:

      The router checks whether one of its addresses is included in one

      of the ART Options.  If so, this router is one of the TargNodes.

      Otherwise, it is an intermediate router.

      If the router is an intermediate router, then it transmits the

      RREQ-DIO via link-local multicast; if the H bit is set to 0, the

      intermediate router MUST include the address of the interface

      receiving the RREQ-DIO into the address vector.  Otherwise, the

      router is TargNode; if it was not already associated with the

      RREQ-Instance, it prepares and transmits a RREP-DIO (Section 6.3
<https://datatracker.ietf.org/doc/html/draft-ietf-roll-aodv-rpl-11#section-6.3>
).

      If, on the other hand, TargNode was already associated with the

      RREQ-Instance, it takes no further action and does not send an

      RREP-DIO.”

16. Section 6.2.2:

  If the OrigNode tries to reach multiple TargNodes in a single RREQ-

  Instance, one of the TargNodes can be an intermediate router to the

  others, therefore it MUST continue sending RREQ-DIO to reach other

  targets.  In this case, before rebroadcasting the RREQ-DIO

The use of the term “broadcast” here confuses me. Is this “broadcast” in
the RF

sense? Again, this is a place a clear description of the network environment

might have helped.

[v11] Page 16, rebroadcasting changed to transmitting, new text states: “
If the OrigNode tries to reach multiple TargNodes in a single RREQ-

   Instance, one of the TargNodes can be an intermediate router to the

   others, therefore it MUST continue sending RREQ-DIO to reach other

   targets.  In this case, before transmitting the RREQ-DIO via link-

   local multicast, a TargNode MUST delete the Target Option

   encapsulating its own address, so that downstream routers with higher

   Rank values do not try to create a route to this TargNode.”

17. Section 6.2.2:

  send out any RREQ-DIO.  For the purposes of determining the

  intersection with previous incoming RREQ-DIOs, the intermediate

  router maintains a record of the targets that have been requested

  associated with the RREQ-Instance.  Any RREQ-DIO message with

  different ART Options coming from a router with higher Rank is

  ignored.

It’s not clear to me if the last sentence goes with the previous and if so,

how. Does it even relate to multiple targets? Also, different from what? If
it

has the same ART Options (same as what?) is it *not* ignored?

[v11] Page 16, new text: “ ...If the intersection is empty, it

   means that all the targets have been reached, and the router MUST NOT

   transmit any RREQ-DIO.  For the purposes of determining the

   intersection with previous incoming RREQ-DIOs, the intermediate

   router maintains a record of the targets that have been requested for

   a given RREQ-Instance.  Any incoming RREQ-DIO message having multiple

   ART Options coming from a router with higher Rank than the Rank of

   the stored targets is ignored.”

18. Section 6.3.1:

  implementation-specific and out of scope.  If the implementation

  selects the symmetric route, and the L bit is not 0, the TargNode MAY

  delay transmitting the RREP-DIO for duration RREP_WAIT_TIME to await

  a symmetric route with a lower Rank.  The value of RREP_WAIT_TIME is

  set by default to 1/4 of the time duration determined by the L bit.

It’s not an L bit though, it’s an L field.

[v11] L bit was changed to L field in the document

19. Section 6.3.2:

  multicast until the OrigNode is reached or MaxRank is exceeded.  The

  TargNode MAY delay transmitting the RREP-DIO for duration

  RREP_WAIT_TIME to await a route with a lower Rank.  The value of

  RREP_WAIT_TIME is set by default to 1/4 of the time duration

  determined by the L bit.

Again, it’s an L field. Also, what if L is zero? Is RREP_WAIT_TIME set to

infinity, as the text implies?

Please do a global search for “L bit”, as there are additional instances I

haven’t called out.

[v11] L bit was changed to L field in the document

20. Section 6.4:

  Step 4:

      If the receiver is the OrigNode, it can start transmitting the

      application data to TargNode along the path as provided in RREP-

      Instance, and processing for the RREP-DIO is complete.  Otherwise,

      in case of an asymmetric route, the intermediate router MUST

      include the address of the interface receiving the RREP-DIO into

      the address vector, and then transmit the RREP-DIO via link-local

      multicast.  In case of a symmetric route, the RREP-DIO message is

As with #15: on what interface(s)?

[v11] Page 19,  Step 4 first paragraph remains the same,

Charlie made a question: “ Are we assuming a single interface?”

----------------------------------------------------------------------

RESPONSE to Comment 20:

----------------------------------------------------------------------

AODV-RPL routers can have multiple router interfaces.  Per-node

configuration of "RREP-DIO transmission interfaces" is an administrative

feature which is beyond the scope of the document.

21. Section 10:

  fake AODV-RPL route discoveries.  In this type of scenario, RPL's

  preinstalled mode of operation, where the key to use for a P2P-RPL

  route discovery is preinstalled, SHOULD be used.

What type of scenario is that?

[V11] Page 22, new text: When rogue routers might be  present, RPL's
preinstalled mode of operation, where the key to use  for route discovery
is preinstalled, SHOULD be used.


22. Appendix A:

s/pakcet/packet/

[V11] Page 25, fixed.

23. General remark:

Although “acknowledgements” isn’t a required section I was a little
surprised

not to encounter it, as it’s usually present. Your call of course.

[v11] Added


Thank you very much,

Ines.

On Fri, May 7, 2021 at 4:58 AM Charlie Perkins <
charles.perkins@earthlink.net> wrote:

> Hello John,
>
> It's taken a while for me to get to this, please excuse the delay. I
> have some followup to your comments interspersed below.
>
> On 4/19/2021 1:31 PM, John Scudder via Datatracker wrote:
> > John Scudder 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:
> > ----------------------------------------------------------------------
> >
> > A lot of effort has clearly gone into this work, thank you. I do have
> one topic
> > I want to DISCUSS, as it seriously impacted the readability of the
> document
> > from my point of view. I don’t anticipate that it will be very difficult
> to
> > resolve this DISCUSS as it relates to clarity and not to anything
> fundamental.
> >
> > My chief difficulty with the document is placing it in context. No hints
> are
> > given to the reader as to what the expected network environment is. I
> think it
> > would be almost sufficient to say, for example “the network environment
> is
> > assumed to be the same as described in RFC 6550, Section 1” for example,
> but
> > without that hint and without a strong background in ROLL, I found myself
> > struggling. Figures 4 and 5 in particular lead me to believe the expected
> > environment looks similar to a classic ISP network — a collection of
> nodes
> > connected by point-to-point links. If this isn’t correct (and I bet it’s
> not)
> > that may have led me into incorrect assumptions, which may be reflected
> in my
> > other comments below.
> >
> > Further, it’s not stated anywhere whether AODV-RPL is intended to stand
> alone
> > as its own routing protocol, or to be viewed as an extension of RPL. In
> the
> > former case, it seems the document is lacking details that are present
> in RFC
> > 6550. I’m assuming the latter is the case, but a clear statement to that
> effect
> > seems indicated.
> How about this text:
>     Routing Protocol for Low-Power and Lossy Networks (RPL) [RFC6550] is
>     an IPv6 distance vector routing protocol designed to support multiple
>     traffic flows through a root-based Destination-Oriented Directed
>     Acyclic Graph (DODAG).  Typically, a router does not have routing
>     information for most other routers.  Consequently, for traffic
>     between routers within the DODAG (i.e., Point-to-Point (P2P) traffic)
>     data packets either have to traverse the root in non-storing mode, or
>     traverse a common ancestor in storing mode.  Such P2P traffic is
>     thereby likely to traverse longer routes and may suffer severe
>     congestion near the root (for more information see [RFC6997],
>     [RFC6998]). The network environment that is considered in this document
>     assumed to be the same as described in Section 1 of [RFC6550].
>
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > 1. Section 1:
> >
> >     Reply.  AODV-RPL currently omits some features compared to AODV -- in
> >     particular, flagging Route Errors, blacklisting unidirectional links,
> >     multihoming, and handling unnumbered interfaces.
> >
> > Your use of language is entirely up to you, but I feel obliged to point
> out
> > that there’s been a lot of discussion in the IETF community recently
> about use
> > of language that raises sensitive points, and about the term
> “blacklisting” in
> > particular. I understand that this is the only place in the document the
> term
> > appears, and since it refers to AODV you can’t just use another term, but
> > placing it in quotation marks might make it clear that it’s referring
> verbatim
> > to the language of RFC 3561.
>
> This is an evolving issue.  I am fine with using quotes but otherwise
> maintaining consistent terminology.  For instance,
>
>      AODV-RPL currently omits some features compared to AODV -- in
>      particular, flagging Route Errors, "blacklisting" unidirectional links
>      [RFC3561], multihoming, and handling unnumbered interfaces.
>
> If there is an official list of terms to search for please let us know.
>
> >
> > 2. Section 1:
> >
> >    support for storing and non-storing modes.  AODV adds basic messages
> >    RREQ and RREP as part of RPL DIO (DODAG Information Object) control
> >
> > Did you mean “AODV-RPL adds”?
> Yes, will fix.
>
> >
> > 3. Section 2:
> >
> >     Symmetric route
> >        The upstream and downstream routes traverse the same routers.
> >
> > Same routers? Or same links? (Or both, if multi-access links are part of
> the
> > mix, as I imagine they may be?)
>
>        The upstream and downstream routes traverse the same routers and
> over
>        the same links.
> > 4. Section 4.1:
> >
> >     OrigNode sets its IPv6 address in the DODAGID field of the RREQ-DIO
> >     message.  A RREQ-DIO message MUST carry exactly one RREQ option,
> >
> > Should that say “one of its IPv6 addresses"? Is it even necessary to
> restate
> > this? RFC 6550 §6.3.1 already has a clearer requirement:
> >
> >     DODAGID: 128-bit IPv6 address set by a DODAG root that uniquely
> >           identifies a DODAG.  The DODAGID MUST be a routable IPv6
> >           address belonging to the DODAG root.
>
> I'm not quite sure what is requested.  Should it be "OrigNode sets the
> DODAGID field", relying on the definition provided in RFC 6550? Should
> it be "OrigNode sets one of its routable IPv6 address in the DODAGID
> field"?
> Honestly, I thought the meaning was clear.  Unless there is an
> objection, I reckon we will use the latter wording.
>
> >
> > 5. Section S4.1:
> >
> >    TargNode can join the RREQ instance at a Rank whose integer portion
> >    is equal to the MaxRank.
> >
> > Not less than or equal, right? Strict equality to MaxRank is required?
> The existing text isn't good.  Instead,
>
>     TargNode can join the RREQ instance at a Rank whose integer portion
>     is less than the MaxRank.
>
>
> > 6. Section 4.2:
> >
> >     TargNode sets its IPv6 address in the DODAGID field of the RREP-DIO
> >     message.  A RREP-DIO message MUST carry exactly one RREP option,
> >
> > Same as #4.
> >
> > 7. Section 4.2:
> >
> >    Address Vector
> >       Only present when the H bit is set to 0.  For an asymmetric route,
> >       the Address Vector represents the IPv6 addresses of the route that
> >       the RREP-DIO has passed.
> >
> > The first time I read through this, I didn’t understand it at all. On
> > re-reading, I think you’re using the word “route” in two different ways
> in the
> > same sentence, the first time to mean “route” in the sense of an object
> in the
> > protocol, the second time in the more casual sense of “a path through the
> > network”. If that’s right, I suggest rewriting the second instance, as
> in “…
> > represents the IPv6 addresses of the path through the network the
> RREP-DIO has
> > traversed.”
> >
> > Also, as in point #4, is it right to say *the* IPv6 addresses? Couldn’t
> any
> > given node have various IPv6 addresses? So maybe just lose the definite
> > article, as in “… represents IPv6 addresses of the path…”?
>
> Good point.  We will use your formulation.
>
> >
> > 8. Section 4.3:
> >
> >    r
> >       A one-bit reserved field.  This field MUST be initialized to zero
> >       by the sender and MUST be ignored by the receiver.
> >
> > The figure doesn’t show an “r” field. I assume the field labeled “X”
> should be
> > relabeled as “r”?
> Actually, the description should refer to an "X" field, not an "r"
> field.  We will update.
>
>
> >
> > 9. Section 5:
> >
> >     Figure 4.  If an intermediate router sends out RREQ-DIO with the S
> >     bit set to 1, then all the one-hop links on the route from the
> >     OrigNode O to this router meet the requirements of route discovery,
> >
> > On first reading I didn’t understand this. Having read the whole
> document, I
> > now get it (I think!). Possibly changing “meet” to “have met” would have
> been
> > enough to get me past my initial befuddlement.
>
> Yes, that's better.
>
> >
> > 10. Section 5:
> >
> >     The criteria used to determine whether or not each link is symmetric
> >     is beyond the scope of the document.  For instance, intermediate
> >
> > Should be “criterion … is beyond", or "criteria … are beyond", depending
> on
> > whether you want singular or plural.
> We will use "criteria … are beyond".
>
> >
> > 11. Section 5:
> >
> >    routers can use local information (e.g., bit rate, bandwidth, number
> >    of cells used in 6tisch)
> >
> > I wouldn’t have minded a reference for 6tisch.
> No problem.
>
> >
> > 12. Section 5:
> >
> >     Upon receiving a RREQ-DIO with the S bit set to 1, a node determines
> >     whether this one-hop link can be used symmetrically, i.e., both the
> >     two directions meet the requirements of data transmission.  If the
> >     RREQ-DIO arrives over an interface that is not known to be symmetric,
> >     or is known to be asymmetric, the S bit is set to 0.  If the S bit
> >     arrives already set to be '0', it is set to be '0' on retransmission
> >
> > The term “retransmission” seems misused here. I guess you mean something
> like
> > “when the RREQ-DIO is propagated”.
> That is better.  We will use that.
>
> >
> > 13. Section 5:
> >
> >    Appendix A describes an example method using the upstream Expected
> >    Number of Transmissions" (ETX) and downstream Received Signal
> >    Strength Indicator (RSSI) to estimate whether the link is symmetric
> >    in terms of link quality is given in using an averaging technique.
> >
> > This sentence needs a rewrite to make it grammatical. It works up until
> "is
> > given in using an averaging technique”.
> How about:
>      Appendix A describes an example method using the upstream Expected
>      Number of Transmissions" (ETX) and downstream Received Signal
>      Strength Indicator (RSSI) to estimate whether the link is symmetric
>      in terms of link quality using an averaging technique.
>
>
> >
> > 14. Section 6.2.1:
> >
> >       If the S bit in the received RREQ-DIO is set to 1, the router MUST
> >       determine whether each direction of the link (by which the RREQ-
> >       DIO is received) satisfies the Objective Function.  In case that
> >       the downward (i.e. towards the TargNode) direction of the link
> >       does not satisfy the Objective Function, the link can't be used
> >       symmetrically, thus the S bit of the RREQ-DIO to be sent out MUST
> >       be set as 0.  If the S bit in the received RREQ-DIO is set to 0,
> >       the router MUST determine into the upward direction (towards the
> >       OrigNode) of the link.
> >
> > The last sentence doesn’t make sense.
> How about:
>                 ...  If the S bit in the received RREQ-DIO is set to 0,
>       the router MUST determine the upward direction (towards the
>       OrigNode) of the link.
> >
> > 15. Section 6.2.1:
> >
> >       If the router is an intermediate router, then it transmits a RREQ-
> >       DIO via link-local multicast;
> >
> > On what interface? Routers generally can have multiple interfaces.
> Again, this
> > is a place a clear description of the network environment might have
> helped.
>
> The link-local multicast should go out over all local interfaces.
>
> >
> > 16. Section 6.2.2:
> >
> >    If the OrigNode tries to reach multiple TargNodes in a single RREQ-
> >    Instance, one of the TargNodes can be an intermediate router to the
> >    others, therefore it MUST continue sending RREQ-DIO to reach other
> >    targets.  In this case, before rebroadcasting the RREQ-DIO
> >
> > The use of the term “broadcast” here confuses me. Is this “broadcast” in
> the RF
> > sense? Again, this is a place a clear description of the network
> environment
> > might have helped.
> This needs to be reformulated to avoid suggesting anything about RF
> broadcast.  TBD.
>
> >
> > 17. Section 6.2.2:
> >
> >    send out any RREQ-DIO.  For the purposes of determining the
> >    intersection with previous incoming RREQ-DIOs, the intermediate
> >    router maintains a record of the targets that have been requested
> >    associated with the RREQ-Instance.  Any RREQ-DIO message with
> >    different ART Options coming from a router with higher Rank is
> >    ignored.
> >
> > It’s not clear to me if the last sentence goes with the previous and if
> so,
> > how. Does it even relate to multiple targets? Also, different from what?
> If it
> > has the same ART Options (same as what?) is it *not* ignored?
> How about:
>                    .....                     For the purposes of
> determining the
>    intersection with previous incoming RREQ-DIOs, the intermediate
>    router maintains a record of the targets that have been requested
>    associated with the RREQ-Instance. Any incoming RREQ-DIO message having
>    multiple ART Options coming from a router with higher Rank than the
> Rank of
>    the stored targets is ignored.
>
> >
> > 18. Section 6.3.1:
> >
> >    implementation-specific and out of scope.  If the implementation
> >    selects the symmetric route, and the L bit is not 0, the TargNode MAY
> >    delay transmitting the RREP-DIO for duration RREP_WAIT_TIME to await
> >    a symmetric route with a lower Rank.  The value of RREP_WAIT_TIME is
> >    set by default to 1/4 of the time duration determined by the L bit.
> >
> > It’s not an L bit though, it’s an L field.
> Good point!
>
> >
> > 19. Section 6.3.2:
> >
> >    multicast until the OrigNode is reached or MaxRank is exceeded.  The
> >    TargNode MAY delay transmitting the RREP-DIO for duration
> >    RREP_WAIT_TIME to await a route with a lower Rank.  The value of
> >    RREP_WAIT_TIME is set by default to 1/4 of the time duration
> >    determined by the L bit.
> >
> > Again, it’s an L field. Also, what if L is zero? Is RREP_WAIT_TIME set to
> > infinity, as the text implies?
> Thanks for pointing this out.  We need to be explicit about it.  I don't
> think the RREP_WAIT_TIME should ever be zero or infinity. But, if it
> were, the implementations would still be interoperable in a sense.  Do
> we really want to get into exactly what wait times make sense in this
> context?
>
>
> >
> > Please do a global search for “L bit”, as there are additional instances
> I
> > haven’t called out.
> >
> > 20. Section 6.4:
> >
> >    Step 4:
> >
> >        If the receiver is the OrigNode, it can start transmitting the
> >        application data to TargNode along the path as provided in RREP-
> >        Instance, and processing for the RREP-DIO is complete.  Otherwise,
> >        in case of an asymmetric route, the intermediate router MUST
> >        include the address of the interface receiving the RREP-DIO into
> >        the address vector, and then transmit the RREP-DIO via link-local
> >        multicast.  In case of a symmetric route, the RREP-DIO message is
> >
> > As with #15: on what interface(s)?
> It should go out to all the neighbors over multiple interfaces if
> necessary.
>
> >
> > 21. Section 10:
> >
> >    fake AODV-RPL route discoveries.  In this type of scenario, RPL's
> >    preinstalled mode of operation, where the key to use for a P2P-RPL
> >    route discovery is preinstalled, SHOULD be used.
> >
> > What type of scenario is that?
>
>   "In this type of scenario" -> "When rogue routers might be present"
>
> >
> > 22. Appendix A:
> >
> > s/pakcet/packet/
> Check.
> >
> > 23. General remark:
> >
> > Although “acknowledgements” isn’t a required section I was a little
> surprised
> > not to encounter it, as it’s usually present. Your call of course.
> Acknowledgements are due to a lot of people - thanks for the reminder!
>
> Naturally Yours,
> Charlie P.
>
>