Skip to main content

Supporting Asymmetric Links in Low Power Networks: AODV-RPL
draft-ietf-roll-aodv-rpl-18

Revision differences

Document history

Date Rev. By Action
2024-02-16
18 John Scudder IESG state changed to AD Evaluation from Publication Requested
2024-01-26
18 Gunter Van de Velde Request closed, assignment withdrawn: Susan Hares Last Call OPSDIR review
2024-01-26
18 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'Overtaken by Events': Cleaning up stale OPSDIR queue
2023-08-17
18 Ines Robles
draft-ietf-roll-aodv-rpl - Write Up

Previous state: WG Document
Current state:  Last Call Finished on 04-19
--------------------------------------

1. Summary


* Responsible Area Director: John Scudder
* …
draft-ietf-roll-aodv-rpl - Write Up

Previous state: WG Document
Current state:  Last Call Finished on 04-19
--------------------------------------

1. Summary


* Responsible Area Director: John Scudder
* Document Shepherd: Ines Robles mariainesrobles@googlemail.com

This document specifies a reactive P2P route discovery mechanism for both hop-by-hop routing and source routing: Ad Hoc On-demand Distance Vector Routing (AODV) based RPL protocol.  Paired Instances are used to construct directional paths, in case some of the links between source and target node are asymmetric.

The Intended RFC status is Standards Track.

2. Review and Consensus

This document was reviewed in roll working group. It was submitted to the IESG and returned to the working group for further development on April 2022
The issues were addressed in several iterations of the document. During the last versions including the correction of the
reviews, members were silent, no rejection gotten, currently the document is in version 18.

3. Intellectual Property

Email sent to the Authors asking confirmation: All authors confirmed on May 2023 for version 17.

4. Other points

Checklist for draft 18

Does the shepherd stand behind the document and think the document is ready for
publication? Yes.

Is the correct RFC type indicated in the title page header?  Yes.

Is the abstract both brief and sufficient, and does it stand alone as a brief summary?
Yes

Is the intent of the document accurately and adequately explained in the introduction?
Yes.

Have all required formal reviews (MIB Doctor, Media Type, URI, etc.) been requested
and/or completed? Not apply.



Has the shepherd performed automated checks -- idnits (see ​
http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist), checks of BNF rules,
XML code and schemas, MIB definitions, and so on -- and determined that the
document passes the tests? (In general, nits should be fixed before the document is
sent to the IESG. If there are reasons that some remain (false positives, perhaps, or
abnormal things that are necessary for this particular document), explain them.)

Nits results:

(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)

From https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-roll-aodv-rpl-18.txt
No errors, no nits.

Has each author stated that their direct, personal knowledge of any IPR related to this
document has already been disclosed, in conformance with BCPs 78 and 79?
Yes

Have all references within this document been identified as either normative or
informative, and does the shepherd agree with how they have been classified?
Yes.

Are all normative references made to documents that are ready for advancement and
are otherwise in a clear state?
Yes.

If publication of this document changes the status of any existing RFCs, are those
RFCs listed on the title page header, and are the changes listed in the abstract and
discussed (explained, not just mentioned) in the introduction?  Not apply.

If this is a "bis" document, have all of the errata been considered? Not apply.

IANA Considerations:
Are the IANA Considerations clear and complete? Yes.


Are all protocol extensions that the document makes associated with the appropriate
reservations in IANA registries? Yes.

Are all IANA registries referred to by their exact names (check them in ​
http://www.iana.org/protocols/ to be sure)? Yes.

For any new registries that this document creates, has the working group actively
chosen the allocation procedures and policies and discussed the alternatives? Not apply.

Have reasonable registry names been chosen (that will not be confused with those of
other registries),? and have the initial contents and valid value ranges been clearly specified? Yes.

Issues raised by document shepherd were fixed in version 07.

Version 17 and 18 addressed comments mainly made by routing directorate reviewer and other minors corrections.

Thank you for this document,

Ines.
2023-08-17
18 Ines Robles IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2023-08-17
18 Ines Robles IESG state changed to Publication Requested from AD is watching
2023-08-17
18 (System) Changed action holders to John Scudder (IESG state changed)
2023-08-17
18 Ines Robles
draft-ietf-roll-aodv-rpl - Write Up

Previous state: WG Document
Current state:  Last Call Finished on 04-19
--------------------------------------

1. Summary


* Responsible Area Director: John Scudder
* …
draft-ietf-roll-aodv-rpl - Write Up

Previous state: WG Document
Current state:  Last Call Finished on 04-19
--------------------------------------

1. Summary


* Responsible Area Director: John Scudder
* Document Shepherd: Ines Robles mariainesrobles@googlemail.com

This document specifies a reactive P2P route discovery mechanism for both hop-by-hop routing and source routing: Ad Hoc On-demand Distance Vector Routing (AODV) based RPL protocol.  Paired Instances are used to construct directional paths, in case some of the links between source and target node are asymmetric.

The Intended RFC status is Standards Track.

2. Review and Consensus

This document was reviewed in roll working group. It was submitted to the IESG and returned to the working group for further development on April 2022
The issues were addressed in several iterations of the document. During the last versions including the correction of the
reviews, members were silent, no rejection gotten, currently the document is in version 18.

3. Intellectual Property

Email sent to the Authors asking confirmation: All authors confirmed on May 2023 for version 17.

4. Other points

Checklist for draft 18

Does the shepherd stand behind the document and think the document is ready for
publication? Yes.

Is the correct RFC type indicated in the title page header?  Yes.

Is the abstract both brief and sufficient, and does it stand alone as a brief summary?
Yes

Is the intent of the document accurately and adequately explained in the introduction?
Yes.

Have all required formal reviews (MIB Doctor, Media Type, URI, etc.) been requested
and/or completed? Not apply.



Has the shepherd performed automated checks -- idnits (see ​
http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist), checks of BNF rules,
XML code and schemas, MIB definitions, and so on -- and determined that the
document passes the tests? (In general, nits should be fixed before the document is
sent to the IESG. If there are reasons that some remain (false positives, perhaps, or
abnormal things that are necessary for this particular document), explain them.)

Nits results:

(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)

From https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-roll-aodv-rpl-18.txt
No errors, no nits.

Has each author stated that their direct, personal knowledge of any IPR related to this
document has already been disclosed, in conformance with BCPs 78 and 79?
Yes

Have all references within this document been identified as either normative or
informative, and does the shepherd agree with how they have been classified?
Yes.

Are all normative references made to documents that are ready for advancement and
are otherwise in a clear state?
Yes.

If publication of this document changes the status of any existing RFCs, are those
RFCs listed on the title page header, and are the changes listed in the abstract and
discussed (explained, not just mentioned) in the introduction?  Not apply.

If this is a "bis" document, have all of the errata been considered? Not apply.

IANA Considerations:
Are the IANA Considerations clear and complete? Yes.


Are all protocol extensions that the document makes associated with the appropriate
reservations in IANA registries? Yes.

Are all IANA registries referred to by their exact names (check them in ​
http://www.iana.org/protocols/ to be sure)? Yes.

For any new registries that this document creates, has the working group actively
chosen the allocation procedures and policies and discussed the alternatives? Not apply.

Have reasonable registry names been chosen (that will not be confused with those of
other registries),? and have the initial contents and valid value ranges been clearly specified? Yes.

Issues raised by document shepherd were fixed in version 07.

Version 17 and 18 addressed comments mainly made by routing directorate reviewer and other minors corrections.

Thank you for this document,

Ines.
2023-08-17
18 Charles Perkins New version available: draft-ietf-roll-aodv-rpl-18.txt
2023-08-17
18 Cindy Morgan Secretariat manually posting. Approvals already received
2023-08-17
18 Charles Perkins Uploaded new revision
2023-06-28
17 Ines Robles
draft-ietf-roll-aodv-rpl - Write Up

Previous state: WG Document
Current state:  Last Call Finished on 04-19
--------------------------------------

1. Summary


* Responsible Area Director: John Scudder
* …
draft-ietf-roll-aodv-rpl - Write Up

Previous state: WG Document
Current state:  Last Call Finished on 04-19
--------------------------------------

1. Summary


* Responsible Area Director: John Scudder
* Document Shepherd: Ines Robles mariainesrobles@googlemail.com

This document specifies a reactive P2P route discovery mechanism for both hop-by-hop routing and source routing: Ad Hoc On-demand Distance Vector Routing (AODV) based RPL protocol.  Paired Instances are used to construct directional paths, in case some of the links between source and target node are asymmetric.

The Intended RFC status is Standards Track.

2. Review and Consensus

This document was reviewed in roll working group. It was submitted to the IESG and returned to the working group for further development on April 2022
The issues were addressed in several iterations of the document. During the last versions including the correction of the
reviews, members were silent, no rejection gotten, currently the document is in version 17.

3. Intellectual Property

Email sent to the Authors asking confirmation: All authors confirmed on May 2023 for version 17.

4. Other points

Checklist for draft 17

Does the shepherd stand behind the document and think the document is ready for
publication? Yes.

A minor issue: to change the "associate" word to avoid confussion [https://mailarchive.ietf.org/arch/msg/roll/jaEJ5oLvfAgBoUBELj6MFSMleVE/], this that can be fixed by the Editor,

Is the correct RFC type indicated in the title page header?  Yes.

Is the abstract both brief and sufficient, and does it stand alone as a brief summary?
Yes

Is the intent of the document accurately and adequately explained in the introduction?
Yes.

Have all required formal reviews (MIB Doctor, Media Type, URI, etc.) been requested
and/or completed? Not apply.



Has the shepherd performed automated checks -- idnits (see ​
http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist), checks of BNF rules,
XML code and schemas, MIB definitions, and so on -- and determined that the
document passes the tests? (In general, nits should be fixed before the document is
sent to the IESG. If there are reasons that some remain (false positives, perhaps, or
abnormal things that are necessary for this particular document), explain them.)

Nits results:

(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)

From https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-roll-aodv-rpl-17.txt&submissioncheck=True
Summary: 0 errors (**), 0 flaws (~~), 0 warnings (==), 1 comment (--).

Has each author stated that their direct, personal knowledge of any IPR related to this
document has already been disclosed, in conformance with BCPs 78 and 79?
Yes

Have all references within this document been identified as either normative or
informative, and does the shepherd agree with how they have been classified?
Yes.

Are all normative references made to documents that are ready for advancement and
are otherwise in a clear state?
Yes.

If publication of this document changes the status of any existing RFCs, are those
RFCs listed on the title page header, and are the changes listed in the abstract and
discussed (explained, not just mentioned) in the introduction?  Not apply.

If this is a "bis" document, have all of the errata been considered? Not apply.

IANA Considerations:
Are the IANA Considerations clear and complete? Yes.


Are all protocol extensions that the document makes associated with the appropriate
reservations in IANA registries? Yes.

Are all IANA registries referred to by their exact names (check them in ​
http://www.iana.org/protocols/ to be sure)? Yes.

For any new registries that this document creates, has the working group actively
chosen the allocation procedures and policies and discussed the alternatives? Not apply.

Have reasonable registry names been chosen (that will not be confused with those of
other registries),? and have the initial contents and valid value ranges been clearly specified? Yes.

Issues raised by document shepherd were fixed in version 07.

Version 17 addressed comments mainly made by routing directorate reviewer.

Thank you for this document,

Ines.
2023-06-20
17 Ines Robles
draft-ietf-roll-aodv-rpl - Write Up

Previous state: WG Document
Current state:  Last Call Finished on 04-19
--------------------------------------

1. Summary


* Responsible Area Director: Alvaro Retana
* …
draft-ietf-roll-aodv-rpl - Write Up

Previous state: WG Document
Current state:  Last Call Finished on 04-19
--------------------------------------

1. Summary


* Responsible Area Director: Alvaro Retana
* Document Shepherd: Ines Robles mariainesrobles@googlemail.com

This document specifies a reactive P2P route discovery mechanism for both hop-by-hop routing and source routing: Ad Hoc On-demand Distance Vector Routing (AODV) based RPL protocol.  Paired Instances are used to construct directional paths, in case some of the links between source and target node are asymmetric.

The Intended RFC status is Standards Track.

2. Review and Consensus

During the last call there were comments that were addressed in version 06.

This document was reviewed in roll working group.

3. Intellectual Property

Email sent to the Authors asking confirmation: All authors confirmed on May 2023.

4. Other points

Checklist for draft 06

Does the shepherd stand behind the document and think the document is ready for
publication? Yes.

Is the correct RFC type indicated in the title page header?  Yes.

Is the abstract both brief and sufficient, and does it stand alone as a brief summary?
Yes

Is the intent of the document accurately and adequately explained in the introduction?
Yes.

Have all required formal reviews (MIB Doctor, Media Type, URI, etc.) been requested
and/or completed? Not apply.



Has the shepherd performed automated checks -- idnits (see ​
http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist), checks of BNF rules,
XML code and schemas, MIB definitions, and so on -- and determined that the
document passes the tests? (In general, nits should be fixed before the document is
sent to the IESG. If there are reasons that some remain (false positives, perhaps, or
abnormal things that are necessary for this particular document), explain them.)

Nits results:

(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)

From https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-roll-aodv-rpl-17.txt&submissioncheck=True
Summary: 0 errors (**), 0 flaws (~~), 0 warnings (==), 1 comment (--).

Has each author stated that their direct, personal knowledge of any IPR related to this
document has already been disclosed, in conformance with BCPs 78 and 79?
Yes

Have all references within this document been identified as either normative or
informative, and does the shepherd agree with how they have been classified?
Yes.

Are all normative references made to documents that are ready for advancement and
are otherwise in a clear state?
Yes.

If publication of this document changes the status of any existing RFCs, are those
RFCs listed on the title page header, and are the changes listed in the abstract and
discussed (explained, not just mentioned) in the introduction?  Not apply.

If this is a "bis" document, have all of the errata been considered? Not apply.

IANA Considerations:
Are the IANA Considerations clear and complete? Yes.


Are all protocol extensions that the document makes associated with the appropriate
reservations in IANA registries? Yes.

Are all IANA registries referred to by their exact names (check them in ​
http://www.iana.org/protocols/ to be sure)? Yes.

For any new registries that this document creates, has the working group actively
chosen the allocation procedures and policies and discussed the alternatives? Not apply.

Have reasonable registry names been chosen (that will not be confused with those of
other registries),? and have the initial contents and valid value ranges been clearly specified? Yes.

Issues raised by document shepherd were fixed in version 07.

Version 17 addressed comments made by routing directorate reviewer.

Thank you for this document,

Ines.
2023-05-23
17 Ines Robles Tag Doc Shepherd Follow-up Underway set.
2023-05-23
17 Ines Robles IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document
2023-04-17
17 Charles Perkins New version available: draft-ietf-roll-aodv-rpl-17.txt
2023-04-17
17 (System) New version approved
2023-04-17
17 (System) Request for posting confirmation emailed to previous authors: "S.V.R Anand" , Bing Liu , Charles Perkins , Satish Anamalamudi
2023-04-17
17 Charles Perkins Uploaded new revision
2023-04-02
16 Luc André Burdet Request for Last Call review by RTGDIR Completed: Has Issues. Reviewer: Tony Przygienda. Sent review to list. Submission of review completed at an earlier date.
2023-03-29
16 Amy Vezza Shepherding AD changed to John Scudder
2023-03-18
16 Luc André Burdet Request for Last Call review by RTGDIR Completed: Has Issues. Reviewer: Tony Przygienda.
2023-03-02
16 Luc André Burdet Request for Last Call review by RTGDIR is assigned to Tony Przygienda
2023-02-28
16 Tero Kivinen Closed request for Last Call review by SECDIR with state 'Team Will not Review Version'
2023-02-24
16 Ines Robles Requested Last Call review by RTGDIR
2023-02-24
16 Ines Robles Requested Last Call review by SECDIR
2023-02-08
16 Charles Perkins New version available: draft-ietf-roll-aodv-rpl-16.txt
2023-02-08
16 (System) New version approved
2023-02-08
16 (System) Request for posting confirmation emailed to previous authors: "S.V.R Anand" , Bing Liu , Charles Perkins , Satish Anamalamudi
2023-02-08
16 Charles Perkins Uploaded new revision
2022-09-30
15 Charles Perkins New version available: draft-ietf-roll-aodv-rpl-15.txt
2022-09-30
15 Charles Perkins New version accepted (logged-in submitter: Charles Perkins)
2022-09-30
15 Charles Perkins Uploaded new revision
2022-06-25
14 Charles Perkins New version available: draft-ietf-roll-aodv-rpl-14.txt
2022-06-25
14 (System) New version approved
2022-06-25
14 (System) Request for posting confirmation emailed to previous authors: "S.V.R Anand" , Bing Liu , Charles Perkins , Satish Anamalamudi
2022-06-25
14 Charles Perkins Uploaded new revision
2022-06-24
13 Dominique Barthel Added to session: interim-2022-roll-01
2022-06-02
13 Alvaro Retana Removed all action holders
2022-04-11
13 Alvaro Retana IETF WG state changed to WG Document from Submitted to IESG for Publication
2022-04-11
13 Alvaro Retana
I am returning this document to the WG.  There have been significant issues brought up that require revisions and review by the WG.

[This topic …
I am returning this document to the WG.  There have been significant issues brought up that require revisions and review by the WG.

[This topic was discussed during the roll WG @ IETF 113: https://datatracker.ietf.org/doc/minutes-113-roll/ ]
2022-04-11
13 (System) Changed action holders to Alvaro Retana (IESG state changed)
2022-04-11
13 Alvaro Retana IESG state changed to AD is watching from IESG Evaluation::AD Followup
2022-03-21
13 Benjamin Kaduk
[Ballot comment]
Thanks for the updates in -12 and -13, they're a big help for clarity and
readability.

I'm abstaining because I don't think this …
[Ballot comment]
Thanks for the updates in -12 and -13, they're a big help for clarity and
readability.

I'm abstaining because I don't think this document should be published in
its current form, but cannot supply a concrete path to changes that would
make it suitable.  (I believe that such a path exists, but I cannot provide
a proof by construction.)  I'm also concerned about the level of review this
document has received, with multiple errors having gone uncaught until the
IESG Evaluation stage.

That said, I do have some additional comments to offer in the hope that they
improve the document.

Section 6.4.1 (RREP handling) directs the router's processing to proceed to
§6.2.2 (RREQ handling), which seems like an unfortunate copy/paste error.

I continue to believe that it would be very helpful to depict the 'S bit'
information associated with an RREQ-Instance as a tristate rather than a
single bit.  In essence, this state reflects the contract between adjacent
nodes about how to process the corresponding RREP-DIO, but a given
(intermediate) router needs to know what contract to use both when
processing an incoming RREP-DIO and when emitting an RREP-DIOO (indeed, even
to know whether to emit unicast or multicast), and it's hard to see how a
single bit could cover both incoming and outgoing RREP-DIOs at the point of
transition.

A few other section-by-section notes follow.

Section 4.1

  L
      2-bit unsigned integer determining the length of time that a node
      is able to belong to the RREQ-Instance (a temporary DAG including
      the OrigNode and the TargNode).  Once the time is reached, a node
      MUST leave the RREQ-Instance and stop sending or receiving any
      more DIOs for the RREQ-Instance.  This naturally depends on the
      node's ability to keep track of time.  Once a node leaves an RREQ-
      Instance, it MUST NOT rejoin the same RREQ-Instance.  L is
      independent from the route lifetime, which is defined in the DODAG
      configuration option.

I assume that this "MUST NOT rejoin" would have some timeframe associated
with it (at least for L != 0x00), since the instance-id could eventually be
reused for a different logical instance.

Section 4.2

  L
      2-bit unsigned integer defined as in RREQ option.  The lifetime of
      the RREP-Instance MUST be shorter than the lifetime of the RREQ-
      Instance to which it is paired.

Strictly shorter, or "less than or equal to"?  I think, given the limited
options, strictly shorter would be pretty disruptive.

Section 6.2.4

  Suppose a router has joined the RREQ-Instance, and H=0, and the S-bit
  of the RREQ-Instance is set to 1.  In this case, the router MAY
  optionally associate to the RREQ-Instance, the Address Vector of the
  symmetric route back to OrigNode.  This is useful if the router later
  receives an RREP-DIO that is paired with the RREQ.

I think we should say what happens if I don't do what the MAY says.  Do we
just fail to find a route entirely, or only with degraded performance, or
...?

Section 6.4.2

  The router updates its stored value of the TargNode's sequence number
  according to the value provided in the ART option.  The router next
  checks if one of its addresses is included in the ART Option.  If so,
  this router is the OrigNode of the route discovery.  [...]

This seems to set up a scenario where TargNode learns about its own sequence
number updates by processing the ART Option, which is rather amusing to
think about :)

NITS

Section 6.1

  RPLInstance and a DODAG rooted at itself.  Then it transmits a DIO
  message containing exactly one RREQ option (see Section 4.1) to
  multicast group all-RPL-nodes.  The DIO MUST contain at least one ART

"the multicast group".
2022-03-21
13 Benjamin Kaduk [Ballot Position Update] Position for Benjamin Kaduk has been changed to Abstain from Discuss
2022-03-21
13 Ines Robles Added to session: IETF-113: roll  Wed-1300
2022-03-07
13 Charles Perkins New version available: draft-ietf-roll-aodv-rpl-13.txt
2022-03-07
13 (System) New version approved
2022-03-07
13 (System) Request for posting confirmation emailed to previous authors: "S.V.R Anand" , Bing Liu , Charles Perkins , Satish Anamalamudi
2022-03-07
13 Charles Perkins Uploaded new revision
2022-01-30
12 (System) Changed action holders to Alvaro Retana, Mingui Zhang (IESG state changed)
2022-01-30
12 (System) Sub state has been changed to AD Followup from Revised ID Needed
2022-01-30
12 Charles Perkins New version available: draft-ietf-roll-aodv-rpl-12.txt
2022-01-30
12 (System) New version approved
2022-01-30
12 (System) Request for posting confirmation emailed to previous authors: "S.V.R Anand" , Bing Liu , Charles Perkins , Satish Anamalamudi , roll-chairs@ietf.org
2022-01-30
12 Charles Perkins Uploaded new revision
2021-12-01
11 John Scudder
[Ballot comment]
Thanks for the discussion and updates, I'm clearing my discuss. I trust we'll separately come to a conclusion on the remaining topic Alvaro …
[Ballot comment]
Thanks for the discussion and updates, I'm clearing my discuss. I trust we'll separately come to a conclusion on the remaining topic Alvaro and I have been discussing in email.

---previous DISCUSS for posterity:

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.

---previous comments:

(Note, added point 19.5.)

I support Éric's DISCUSS.

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.


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”?


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?)


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.


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?


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…”?


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”?


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.


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.


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.


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”.


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”.


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.


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.


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.


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?


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.

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.


19.5 Section 6.3.2:

(Adding one I missed earlier.)

  When a RREQ-DIO arrives at a TargNode with the S bit set to 0, the
  TargNode MUST build a DODAG in the RREP-Instance rooted at itself in
  order to discover the downstream route from the OrigNode to the
  TargNode.  The RREP-DIO message MUST be re-transmitted via link-local
  multicast until the OrigNode is reached or MaxRank is exceeded.  The

As in comment 12, the use of the term "re-transmitted" is a little weird here. Do you mean TargNode sends the RREP-DIO again and again, as the text seems to say? (And as with some of my other comments, it's not obvious to me what interface(s) the link-local multicast takes place on.)


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)?


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?


22. Appendix A:

s/pakcet/packet/


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.
2021-12-01
11 John Scudder [Ballot Position Update] Position for John Scudder has been changed to No Objection from Discuss
2021-10-29
11 Benjamin Kaduk
[Ballot discuss]
Thanks for the updates in the -11, they are a bit improvement.

(1) I did make a point of looking into the procedures …
[Ballot discuss]
Thanks for the updates in the -11, they are a bit improvement.

(1) I did make a point of looking into the procedures for determining
whether a route will be symmetric or asymmetric, and I'm running into
trouble for the case where an intermediate router determines that a link
cannot work as part of a symmetric route.

For concreteness, let's consider the following snippet of topology:

  +-------+                  +-------+                  +-------+
  |      |    asymmetric    |      |                  |      |
  |  A  +-------------------+  B  +===================+  C  |
  |      |      L1          |      |      L2          |      |
  +-------+                  +-------+                  +-------+

Suppose that an RREQ-DIO arrives at A with S=1 and H=0.  Per step 3 of
§6.2.1, if the link the RREQ-DIO arrived on satisfies the objective
function, the outgoing RREQ-DIO is also transmitted with S=1.
A also associates state with its RREQ-Instance the value of the S bit
from the transmitted RREQ-DIO, i.e., 1.
That RREQ-DIO arrives at B, who performs the same check and determines
that the L1 cannot satisfy the objective function.  Accordingly, B sends
out a RREQ-DIO to C with S=0 and stores the state S=0.  The RREQ-DIO
continues to through C to TargNode (or maybe C is TargNode; it may not
matter), and TargNode proceeds to follow asymmetric procedures,
initiating an RREP-DIO with an initially empty address vector.  That
RREP-DIO arrives at C, who has stored state S=0, so C joins the DODAG of
the RREP-Instance, adds its address to the address vector (per step 4 of
§6.4), and sends an RREP-DIO to B.  B likewise has stored state S=0,
adds its address to the address vector, and sends an RREP-DIO to A.  But
A has stored state S=1, so in step 4 of §6.4, A is looking for an
address in the address vector to use as the unicast target for A's
outgoing RREP-DIO.  But there is no such entry in the address vector,
becuase up to now the RREP-DIO has been using asymmetric procedures, and
has no data on how to get from A to OrigNode!

Now, it's certainly possible that I've made an error in the above.  But
even if I have, it still seems suggestive that this boundary behavior is
pretty complicated and hard to get right.  It seems like we should have
some similar discussion in the document to cover how this case does
actually work.

(And if I didn't make an error in the above, it seems to still be
salvageable, with B storing a sentinel value of "I changed from S=1 to
S=0" instead of just 1 or 0, and holding on to the (symmetric) address
vector from OrigNode to B.  Then B could perform translation from the
asymmetric to symmetric regime for the RREP and all routers on the path
would be able to install useful route entries.  But there's not anything
in the current text to suggest that B should be doing that.)

(2) I'm putting this in the Discuss section because I think it's
important for the authors/WG to produce an answer.  Since I've been
wrong about it at least once, I do not claim to know the correct answer,
and thus the Discuss point ought to be easy to resolve.

Section 6.3.3 says:

                          Instead, the RPLInstanceID MUST be replaced by
  another value so that the two RREP-instances can be distinguished.
  In RREP-DIO option, the Shift field of the RREP-DIO message(Figure 2)
  indicates the shift to be applied to original RPLInstanceID to obtain
  the replacement RPLInstanceID.  When the new RPLInstanceID after
  shifting exceeds 255, it rolls over starting at 0.  For example, if
  the original RPLInstanceID is 252, and shifted by 6, the new
  RPLInstanceID will be 2. [...]

I know that the use of 255 as the largest value here comes as a result
of my earlier review, but wanted to note that the resulting discussion
thread may not have fully concluded.
In particular, I now see
https://datatracker.ietf.org/doc/html/rfc6550#section-5.1 that does
indicate that only 6 bits of "usable" ID are present for local
RPLInstanceIDs, which seem to be the ones in use here.  Sorry to have
missed that in my initial review; I hope that we can figure out what the
actual correct boundary value is.
2021-10-29
11 Benjamin Kaduk
[Ballot comment]
Some of the text I comment on below is new in the -11, and I would have
hoped that WG review of the …
[Ballot comment]
Some of the text I comment on below is new in the -11, and I would have
hoped that WG review of the changes would have detected more of this
type of thing.  This leaves me uncertain what level of review the WG
actually performed, and I am considering balloting Abstain once my
discuss points are resolved.

Section 3

  to TargNode, and another from TargNode to OrigNode.  When possible,
  AODV-RPL also enables symmetric route discovery along Paired DODAGs
  (see Section 5).

(Modifying a comment I made on the -10) Perhaps we could say "AODV-RPL
also enables discvoery of symmetric routes along Paired DODAGs when
symmetric routes are possible (see Section 5)"?

Section 4.2

  L
      2-bit unsigned integer defined as in RREQ option.

Per the discussion on my previous ballot thread, I suggest adding "The
lifetime of the RREP-Instance MUST be shorter than the lifetime of the
RREQ-Instance it is paired to" (or similar).

Section 4.3

  Target Prefix / Address
      (variable-length field) An IPv6 destination address or prefix.
      The Prefix Length field contains the number of valid leading bits
      in the prefix.  The Target Prefix / Address field contains the
      least number of octets that can represent all of the bits of the
      Prefix, in other words Ceil(Prefix Length/8) octets.  The initial
      bits in the Target Prefix / Address field preceding the prefix
      length (if any) MUST be set to zero on transmission and MUST be
      ignored on receipt.  If Prefix Length is zero, the Address field
      is 128 bits for IPv6 addresses.

This is a change from the -10 about where the target prefix is aligned
for prefix lengths that are not a multiple of 8.
I have no stance on which formulation is best, but it seems very
surprising to change the wire encoding in this manner at such a late
stage in the document lifecycle, without specific compelling reasoning.

Section 6.2.1

  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.
  [...]
  Step 3:

      If the S bit of the incoming RREQ-DIO is 0, then the route cannot
      be symmetric, and the S bit of the RREQ-DIO to be transmitted is
      set to 0.  Otherwise, the router MUST determine whether the
      downward (i.e., towards the TargNode) direction of the incoming
      link satisfies the OF.  If so, the S bit of the RREQ-DIO to be
      transmitted is set to 1.  Otherwise the S bit of the RREQ-DIO to
      be transmitted is set to 0.

The step 1 procedure checks the downstream direction of the incoming
link, and the step 3 procedure also checks the dosntream direction of
the incoming link.  In order to assess whether the link works as a
symmetric link, I think that these checks need to be on different
directions of that link, but am not confident about which step should
check which direction.

section 6.3

                                                              If the
  implementation selects the symmetric route, and the L field is not 0,
  the TargNode MAY delay transmitting the RREP-DIO for duration
  RREP_WAIT_TIME to await a route with a lower Rank.  The value of

In the -10 the text allowing waiting was present in both the section for
the symmetric case and the section for the asymmetric case; is the
conditional "if the implementation selects the symmetric route" correct?

Section 6.3.2

  When a RREQ-DIO arrives at a TargNode with the S bit set to 0, the
  TargNode MUST build a DODAG in the RREP-Instance corresponding to the
  RREQ-DIO, rooted at itself in order to discover the downstream route

nit: this comma is misplaced (and may not be needed at all).

Section 6.4

  Upon receiving a RREP-DIO, a router performs the following steps:

  Step 1:

      If the Objective Function is not satisfied, the router MUST NOT
      join the DODAG; the router MUST discard the RREQ-DIO, and does not

s/RREQ/RREP/?

      If the S-bit of the RREQ-Instance is set to 0, the router MUST
      determine whether the downward direction of the link (towards the
      TargNode) over which the RREP-DIO is received satisfies the
      Objective Function, and the router's Rank would not exceed the
      MaxRank limit.  If so, the router joins the DODAG of the RREP-
      Instance.  The router that transmitted the received RREP-DIO is
      selected as the preferred parent.  Afterwards, other RREP-DIO
      messages can be received.

Please confirm whether "downward direction" is correct.  It seems to me
that in determining whether to join the RREP-Instance, we need to check
whether the "reply path" (from TargNode to OrigNode) is feasible, and
skip joining the instance if it's not a feasible path.  But the text
written here seem to be checking the feasibility of the "request path",
the same direction that was checked in §6.2.1 when deciding whether to
join the RREQ-Instance.

Section 10

Thanks for acting on my previous comment and moving the normative
requirements on nodes to not emit RREPs if they have an address in the
address vector already!  I still think it would be worth some text here
in the security considerations about what goes wrong if those checks are
skipped (I think, a routing loop occurs, but that's something of a
guess).

It seems that if Compr is set too large, there is some risk of a node
failing to check that it shares that many bits of address prefix with
the address in the DODAGID and thus decompression would produce an
incorrect route.

  If a rogue router is able to forge a gratuitous RREP, significant
  damage might result.

Would this damage be in the form of traffic amplification, routing loop,
DoS of certain (key) nodes, ...?
2021-10-29
11 Benjamin Kaduk Ballot comment and discuss text updated for Benjamin Kaduk
2021-10-14
11 Alvaro Retana Update needed related to the MOP value.
2021-10-14
11 (System) Changed action holders to Charles Perkins, Alvaro Retana, Mingui Zhang, Satish Anamalamudi, S.V.R Anand, Bing (Remy) Liu (IESG state changed)
2021-10-14
11 Alvaro Retana IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation::AD Followup
2021-10-07
11 Éric Vyncke
[Ballot comment]
***Thank you for having addressed all my points raised during the IESG ballot of 2021-04-21 with the revised I-D*** (BTW, never hesitate to …
[Ballot comment]
***Thank you for having addressed all my points raised during the IESG ballot of 2021-04-21 with the revised I-D*** (BTW, never hesitate to nudge an AD in the absence of action, I only reacted when processing my pending DISCUSS today :-( ... )

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

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

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

I hope that this helps to improve the document,

Regards,

-éric

== PREVIOUS DISCUSS (for archive) ==

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

== PREVIOUS COMMENTS (for archive) ==

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

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

-- Section 6.1 --
"Each node maintains a sequence number" does it impact constrained nodes ?
2021-10-07
11 Éric Vyncke [Ballot Position Update] Position for Éric Vyncke has been changed to No Objection from Discuss
2021-09-18
11 Roman Danyliw [Ballot comment]
Thank you for addressing my DISCUSS and COMMENT feedback.
2021-09-18
11 Roman Danyliw [Ballot Position Update] Position for Roman Danyliw has been changed to No Objection from Discuss
2021-09-16
11 (System) Changed action holders to Alvaro Retana, Mingui Zhang (IESG state changed)
2021-09-16
11 (System) Sub state has been changed to AD Followup from Revised ID Needed
2021-09-16
11 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2021-09-16
11 Charles Perkins New version available: draft-ietf-roll-aodv-rpl-11.txt
2021-09-16
11 (System) New version approved
2021-09-16
11 (System) Request for posting confirmation emailed to previous authors: "S.V.R Anand" , Bing Liu , Charles Perkins , Mingui Zhang , Satish Anamalamudi , roll-chairs@ietf.org
2021-09-16
11 Charles Perkins Uploaded new revision
2021-06-14
10 Robert Wilton [Ballot Position Update] Position for Robert Wilton has been changed to No Objection from Discuss
2021-04-22
10 Meral Shirazipour Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Meral Shirazipour. Sent review to list.
2021-04-22
10 Benjamin Kaduk
[Ballot discuss]
My apologies for coming in with a late review, but I think there are
some serious internal inconsistencies in this document that leave …
[Ballot discuss]
My apologies for coming in with a late review, but I think there are
some serious internal inconsistencies in this document that leave me
unsure whether the document is in a reviewable form.  It might be
prudent to have the document return to the WG to fix the identified
issues and get additional review.

Specifically, there are several places in the document (most notably
Section 6.4) that provide steps for processing a RREP-DIO that refer to
the value of the "S bit".  There is no S bit in the RREP option as
defined in Section 4.2; indeed, there has never been an S bit in the
RREP option since it was introduced in the -03.  The -02 was proposing
changes directly in the DIO base object, which included an S bit, so in
that version of the document referring to an "S bit" in the reply
processing could have made sense.

There are also a few places that refer to using RREP (reply) processing
to relate to membership in or joining of the RREQ (request) DODAG.  I
assume that these are, in effect, typographical errors that should refer
to the RREP DODAG, but the one character has extreme significance to
protocol operations.

I also think that there is too much ambiguity relating to the processing
of RREPs in the symmetric vs asymmetric case (which returns to the
question of whether there is or should be an S bit in the RREP option).
In particular, the semantics of the Address Vector field (for the
source-routing case only, of course) vary.  In the symmetric case this
field is set by TargNode and propagated unchanged in the RREPs, but for
the asymmetric case each intermediate node needs to add its address in
the Address Vector.  We do cover these different behaviors in Sections
6.3.1 and 6.3.2, but leave it very unclear as to how an intermediate
node tells whether a received RREP is for the symmetric or asymmetric
case.  An explicit S bit would make this easy, of course, though it
seems like it *might* be possible to use whether the RREP was received
over a unicast or multicast address/interface as a stand in.  However,
that technique would be complicated by the presence of gratuitous RREPs,
which are unicast in cases that do not quite align up with symmetric vs
asymmetric.  (Whether the processing behavior should reflect the "append
to address vector" or "propagate address vector unchanged" for the
gratuitous case is also not entirely clear to me.)

On a more minor note, I don't think the description of rollover in
Section 6.3.3 is correct.  More in the COMMENT, but in essence, even
though the shift is capped at 63, the instance ID can go up to 255 and
wrapping should occur at the instance ID boundary, not the shift
boundary.
2021-04-22
10 Benjamin Kaduk
[Ballot comment]
The Abstract and Introduction do not paint a very clear picture of what
is going to happen.  Section 3 helps a fair bit, …
[Ballot comment]
The Abstract and Introduction do not paint a very clear picture of what
is going to happen.  Section 3 helps a fair bit, but I would have
expected the introduction to mention that RREQ/RREP go in separate
(paired) RPL instances, and that instances are created (and destroyed?)
for each route being discovered.  (This would also be a great place to
clarify how AODV-RPL interacts with regular RPL, as was requested by
other ADs already.)

I would like to see a clearer picture of the relationship between the
lifetime of routes discovered using AODV-RPL and the lifetime of the
DODAGs used to build them.  The (non-infinite) DODAG lifetime options
are fairly short, and I would (perhaps naively) expect routes to have a
longer lifetime than that in many cases.  But it seems that the
information stored with a route includes the RPL InstanceID, and if the
route is to outlast the DODAG, then that information would become stale,
and I don't know what value there would be in keeping it around in that
case and risking collisions.  Is it expected that when routes are to be
long-lived, the L value of 0 is to be used?

Section 1

  (DAO) message of RPL.  AODV-RPL specifies a new MOP (Mode of
  Operation) running in a separate instance dedicated to discover P2P
  routes, which may differ from the point-to-multipoint routes
  discoverable by native RPL.  AODV-RPL can be operated whether or not

I don't really understand why we find it useful to make a comparison
between P2P routes and P2MP routes.

Section 2

  RREP-DIO message
      An AODV-RPL MOP DIO message containing the RREP option.  The
      RPLInstanceID in RREP-DIO is typically paired to the one in the

Typically, or actually (noting that §6.3.3 allows for the pairing
process to include a "Shift" count for cases where the value cannot
match exactly)?  Is this an attempt to reflect the symmetric case where
a DODAG is not built for symmetric routes?  If so, it's not clear that
we accurately portray what would be the "typical" case...but even in
that symmetric case we still have to populate the RPLInstance field in
the unicast RREP-DIO, and that still has the pairing logic.  So I'm back
to wondering when these would not be paired.

Section 3

  The routes discovered by AODV-RPL are not constrained to traverse a
  common ancestor.  AODV-RPL can enable asymmetric communication paths
  in networks with bidirectional asymmetric links.  For this purpose,

Can AODV-RPL function in networks with unidirectional links?

  to TargNode, and another from TargNode to OrigNode.  When possible,
  AODV-RPL also enables symmetric route discovery along Paired DODAGs
  (see Section 5).

In what circumstances is it not possible to do so?

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,
  otherwise it MUST be dropped.  (Similarly for RREP in §4.2.)

I suggest clarifying that other options are allowed (required, even).

Who sets the S bit, and can it change as the DODAG is being constructed?
("See Section 5" would be fine.)

  L
      2-bit unsigned integer determining the duration that a node is
      able to belong to the temporary DAG in RREQ-Instance, including
      the OrigNode and the TargNode.  Once the time is reached, a node
      MUST leave the DAG and stop sending or receiving any more DIOs for
      the temporary DODAG.

How do we account for time skew as the DIO propagates?  Each node just
leaves on their own timer?

  Address Vector
      A vector of IPv6 addresses representing the route that the RREQ-
      DIO has passed.  It is only present when the H bit is set to 0.
      The prefix of each address is elided according to the Compr field.

  TargNode can join the RREQ instance at a Rank whose integer portion
  is equal to the MaxRank.  Other nodes MUST NOT join a RREQ instance
  if its own Rank would be equal to or higher than MaxRank.  A router
  MUST discard a received RREQ if the integer part of the advertised
  Rank equals or exceeds the MaxRank limit.

Both of these descriptions might benefit from a bit more detail.  E.g.,
the latter paragraph doesn't say that TargNode can join if the rank is
less than MaxRank, only if it's equal.

Section 4.2

  H
      Requests either source routing (H=0) or hop-by-hop (H=1) for the
      downstream route.  It MUST be set to be the same as the H bit in
      RREQ option.

(editorial) I'd suggest putting the "MUST be the same" requirement as
the first sentence, and then the other sentence could be "determines
whether source routing (H=0) or hop-by-hop (H=1) is used for the
downstream route"

  L
      2-bit unsigned integer defined as in RREQ option.

Does L need to have the same value as in the triggering RREQ option?  If
not, when might TargNode choose a different value?

  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.  For a symmetric route, it is the Address
      Vector when the RREQ-DIO arrives at the TargNode, unchanged during
      the transmission to the OrigNode.

[ed. this was written before I made a discuss point about it, but I'm
leaving the text for the extra detail.  It's okay to just respond to the
discuss point and not here.]
If I understand correctly, the S bit indicating symmetric vs asymmetric
route is present only in the RREQ-DIO, and is not included in-band in
the RREP-DIO.  Does this require all nodes on the path to remember
whether a symmetric route is being constructed on the RREQ-DIO instance,
use the Shift in the RREP-DIO to correlate to the corresponding RREQ-DIO
and 'S' bit status, as part of the processing (to determine whether or
not to append to the Address Vector)?

Section 4.3

  Dest SeqNo

      In RREQ-DIO, if nonzero, it is the last known Sequence Number for
      TargNode for which a route is desired.  In RREP-DIO, it is the
      destination sequence number associated to the route.

The destination sequence number for the downstream route or the upstream
route?

Also, should we say that zero is used if there is no known information about
the sequence number of TargNode (and not otherwise)?

  r
      A one-bit reserved field.  This field MUST be initialized to zero
      by the sender and MUST be ignored by the receiver.

The secdir reviewer noted the mismatch between 'X' in the figure and 'r'
here; please fix.

  Prefix Length
      7-bit unsigned integer.  Number of valid leading bits in the IPv6
      Prefix.  If Prefix Length is 0, then the value in the Target
      Prefix / Address field represents an IPv6 address, not a prefix.

  Target Prefix / Address
      (variable-length field) An IPv6 destination address or prefix.
      The Prefix Length field contains the number of valid leading bits
      in the prefix.  The length of the field is the least number of
      octets that can contain all of the bits of the Prefix, in other
      words Floor((7+(Prefix Length))/8) octets.  The remaining bits in
      the Target Prefix / Address field after the prefix length (if any)
      MUST be set to zero on transmission and MUST be ignored on
      receipt.

Please specify how long the Address field is when Prefix Length is zero
(indicating that the last field is the Address variant).

Section 5

  Links are considered symmetric until additional information is
  collected.  [...]

What kinds of problems will arise if we start taking actions based on
this assumption before the "additional information" is available?
(That is to say, perhaps this is not a useful phrasing, since what we
actually do is get updates about the presence of asymmetric links as we
construct the route.)

  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,

Re "the route", this would presumably be the one recorded in the Address
Vector of the RREQ in question?  (Multiple RREQs for the same route
computation can arrive at a given node with different address vectors,
right?

Also, the way this is written implies that it does not say anything
about "non-one-hop links" on the route, but I don't really know what a
link that's not a one-hop link would be.  Can we just say "all the hops"
or "all the links"?

  and the route can be used symmetrically.

But does that matter for any routers other than TargNode (for any of the
AODV-RPL Target Options)?

  doesn't satisfy the Objective Function.  Based on the S bit received
  in RREQ-DIO, TargNode T determines whether or not the route is
  symmetric before transmitting the RREP-DIO message upstream towards
  the OrigNode O.

Does that determination affect the construction of the RREP-DIO in any
way?  (E.g., if there was an S bit.)

            Figure 5: AODV-RPL with Asymmetric Paired Instances

Some discussion of how the third(? second?) intermediate router detects
the asymmetry and clears the S bit might be appropriate.

Section 6.1

  link-local multicast.  The DIO MUST contain at least one ART Option
  (see Section 4.3).  The S bit in RREQ-DIO sent out by the OrigNode is
  set to 1.

I'd suggest saying that the required ART Option indicates the TargNode.

  OrigNode can maintain different RPLInstances to discover routes with
  different requirements to the same targets.  Using the RPLInstanceID
  pairing mechanism (see Section 6.3.3), route replies (RREP-DIOs) for
  different RPLInstances can be distinguished.

When using different RPLInstances for this purpose, what constitutes
"initiates a route discovery process" across those instances -- is it
permissible to only increment the sequence number once when initiating
multiple discovery processes on different instances?

Section 6.2.1

  Step 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.

      If the upward direction of the link can satisfy the Objective
      Function, and the router's Rank would not exceed the MaxUseRank
      limit, the router joins the DODAG of the RREQ-Instance.  The
      router that transmitted the received RREQ-DIO is selected as the
      preferred parent.  Otherwise, if the Objective Function is not
      satisfied or the MaxUseRank limit is exceeded, the router MUST
      discard the received RREQ-DIO and MUST NOT join the DODAG.

The way this is written is confusing to me.  It seems to say that (1)
you only check the upward direction is the S bit in the received
RREQ-DIO is set to zero, and (2) the only time you join the DODAG is if
you're checking the upward direction.  So, when the received S-bit is 1,
do you just never join the DODAG?  I assume this is not the intent, but
that is how I interpret the words that are on the page.

      Sequence Number.  The Destination Address and the RPLInstanceID
      respectively can be learned from the DODAGID and the RPLInstanceID
      of the RREQ-DIO, and the Source Address is the address used by the
      local router to send data to the OrigNode.  The Next Hop is the

"Source Address is the address used by the local router to send data to
the OrigNode" seems like the definition of the source address in a route
table entry, not a procedure for how to set it.  Should this be the
address used by the local router to send data to the preferred parent?

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.

There is no L *bit* in the RREQ option or the RFC 6550 DIO.  There is a
two-bit L field in the RREQ option, but even if I replace 'bit' with
'field', it's still not clear why having a DODAG with no lifetime limit
implies that delaying the RREP-DIO is not allowed.

Section 6.3.2

  When a RREQ-DIO arrives at a TargNode with the S bit set to 0, the
  TargNode MUST build a DODAG in the RREP-Instance rooted at itself in

I don't understand how the definite article is appropriate for "the
RREP-Instance rooted at itself" -- I thought there were multiple
(paired) instances corresponding to the various RREQ DODAGs that
requested routes to TargNode.

  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.

("L bit" again, and no indication of what to do for L==0.)

  The settings of the fields in RREP option and ART option are the same
  as for the symmetric route, except for the S bit.

There is no S bit in the RREP.  What is this intending to say?

Section 6.3.3

  When preparing the RREP-DIO, a TargNode could find the RPLInstanceID
  to be used for the RREP-Instance is already occupied by another RPL
  Instance from an earlier route discovery operation which is still
  active.  In other words, it might happen that two distinct OrigNodes
  need routes to the same TargNode, and they happen to use the same
  RPLInstanceID for RREQ-Instance.  In this case, the occupied
  RPLInstanceID MUST NOT be used again.  [...]

A reminder might be helpful that the RPLInstanceID is a property of a
DODAG, and a DODAG is identified by the DODAGID, which in this case is
the address of the TargNode.  So that is why we need to avoid reusing
RPLInstanceID in the context of the RREP-DIO, whereas there is no
problem with collisions in RPLInstanceID across RREQ-DIOs (where the
DODAGID is the OrigNode address, that suffices to disambiguate).

  shift to be applied to original RPLInstanceID.  When the new
  RPLInstanceID after shifting exceeds 63, it rolls over starting at 0.

I thought RPLInstanceID was a full 8-bit field (even though Shift is
only six bits); wouldn't rollover happen after 255?

  For example, the original RPLInstanceID is 60, and shifted by 6, the
  new RPLInstanceID will be 2.  Related operations can be found in
  Section 6.4.

(So this example wouldn't actually show rollover.)

Section 6.4

  Upon receiving a RREP-DIO, a router which does not belong to the
  RREQ-Instance goes through the following steps:

Do we care about RREQ-Instance membership or RREP-Instance membership,
for processing the RREP-DIO?

  Step 1:

      If the S bit is set to 1, the router MUST proceed to step 2.

There is no S bit in the RREP option!

      and the destination address is learned from the DODAGID.  The
      lifetime is set according to DODAG configuration (i.e., not the L
      bit) and can be extended when the route is actually used.  The

("L bit" again)

  Upon receiving a RREP-DIO, a router which already belongs to the
  RREQ-Instance SHOULD drop the RREP-DIO.

(RREQ-Instance vs RREP-Instance, again.)

Section 10

It seems like a malicious node that forges a gratuitous RREP could do
significant damage as well, so that might be worth mentioning.

  routing loop.  The TargNode MUST NOT generate a RREP if one of its
  addresses is present in the Address Vector.  An Intermediate Router
  MUST NOT forward a RREP if one of its addresses is present in the
  Address Vector.

These requirements seem important enough that I'd prefer to seem them
imposed in the main body text that covers RREP handling, and the
security considerations mentioned here and referring to those handling
requirements.
2021-04-22
10 Benjamin Kaduk [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk
2021-04-22
10 John Scudder
[Ballot comment]
(Note, added point 19.5.)

I support Éric's DISCUSS.

1. Section 1:

  Reply.  AODV-RPL currently omits some features compared to AODV -- in …
[Ballot comment]
(Note, added point 19.5.)

I support Éric's DISCUSS.

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.


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”?


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?)


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.


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?


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…”?


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”?


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.


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.


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.


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”.


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”.


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.


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.


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.


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?


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.

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.


19.5 Section 6.3.2:

(Adding one I missed earlier.)

  When a RREQ-DIO arrives at a TargNode with the S bit set to 0, the
  TargNode MUST build a DODAG in the RREP-Instance rooted at itself in
  order to discover the downstream route from the OrigNode to the
  TargNode.  The RREP-DIO message MUST be re-transmitted via link-local
  multicast until the OrigNode is reached or MaxRank is exceeded.  The

As in comment 12, the use of the term "re-transmitted" is a little weird here. Do you mean TargNode sends the RREP-DIO again and again, as the text seems to say? (And as with some of my other comments, it's not obvious to me what interface(s) the link-local multicast takes place on.)


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)?


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?


22. Appendix A:

s/pakcet/packet/


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.
2021-04-22
10 John Scudder Ballot comment text updated for John Scudder
2021-04-22
10 (System) Changed action holders to Charles Perkins, Alvaro Retana, Mingui Zhang, Satish Anamalamudi, S.V.R Anand, Bing Liu (IESG state changed)
2021-04-22
10 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2021-04-22
10 Murray Kucherawy
[Ballot comment]
I concur with Roman's DISCUSS, especially around the use of SHOULD.  I'd go further and ask why that's not a MUST, or in …
[Ballot comment]
I concur with Roman's DISCUSS, especially around the use of SHOULD.  I'd go further and ask why that's not a MUST, or in the alternative, suggest that you provide some guidance around why an implementer might legitimately decide against doing what the SHOULD says.

I also support John's DISCUSS.

The document shepherd writeup is more than two years old.

In Section 2, although "AODV-RPL Instance" is defined, it is present nowhere in the document.  Also "ART Option" doesn't seem to be ordered correctly.

In Section 9, I suggest being clear that what you're actually updating are the named sub-registries of the "Routing Protocol for Low Power and Lossy Networks (RPL)" registry.
2021-04-22
10 Murray Kucherawy Ballot comment text updated for Murray Kucherawy
2021-04-22
10 Murray Kucherawy
[Ballot comment]
I concur with Roman's DISCUSS, especially around the use of SHOULD.  I'd go further and ask why that's not a MUST, or in …
[Ballot comment]
I concur with Roman's DISCUSS, especially around the use of SHOULD.  I'd go further and ask why that's not a MUST, or in the alternative, suggest that you provide some guidance around why an implementer might legitimately decide against doing what the SHOULD says.

The document shepherd writeup is more than two years old.

In Section 2, although "AODV-RPL Instance" is defined, it is present nowhere in the document.  Also "ART Option" doesn't seem to be ordered correctly.

In Section 9, I suggest being clear that what you're actually updating are the named sub-registries of the "Routing Protocol for Low Power and Lossy Networks (RPL)" registry.
2021-04-22
10 Murray Kucherawy Ballot comment text updated for Murray Kucherawy
2021-04-22
10 Murray Kucherawy
[Ballot comment]
I concur with Roman's DISCUSS, especially around the use of SHOULD.  I'd go further and ask why that's not a MUST, or in …
[Ballot comment]
I concur with Roman's DISCUSS, especially around the use of SHOULD.  I'd go further and ask why that's not a MUST, or in the alternative, provide some guidance around why an implementer might legitimately decide against doing what the SHOULD said.

The document shepherd writeup is more than two years old.

In Section 2, although "AODV-RPL Instance" is defined, it is present nowhere in the document.  Also "ART Option" doesn't seem to be ordered correctly.

In Section 9, I suggest being clear that what you're actually updating are the named sub-registries of the "Routing Protocol for Low Power and Lossy Networks (RPL)" registry.
2021-04-22
10 Murray Kucherawy [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy
2021-04-21
10 Erik Kline
[Ballot comment]
[[ nits ]]

[ section 4.1 ]

* "sets its IPv6 address" could perhaps be something like
  "sets a selected IPv6 source …
[Ballot comment]
[[ nits ]]

[ section 4.1 ]

* "sets its IPv6 address" could perhaps be something like
  "sets a selected IPv6 source address"

[ section 4.3 ]

* "r" is not depicted in Figure 3?  Probably "X"?  Or update Figure to
  match the field description.
2021-04-21
10 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2021-04-21
10 Roman Danyliw
[Ballot discuss]
** Section 10

If a rogue router knows the key for the Security Configuration in
  use, it can join the secure AODV-RPL …
[Ballot discuss]
** Section 10

If a rogue router knows the key for the Security Configuration in
  use, it can join the secure AODV-RPL route discovery and cause
  various types of damage.  Such a rogue router could advertise false
  information in its DIOs in order to include itself in the discovered
  route(s).  It could generate bogus RREQ-DIO, and RREP-DIO messages
  carrying bad routes or maliciously modify genuine RREP-DIO messages
  it receives.  A rogue router acting as the OrigNode could launch
  denial-of-service attacks against the LLN deployment by initiating
  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.

Can the normative language in the last sentence please be clarified.  The entire paragraph prior is describing the behavior of the attacker.  Is this last sentence is suggesting a particular mode of operation?  If the router is rogue, how is the fact that the key is pre-installed inhibit the behavior of the attacker?
2021-04-21
10 Roman Danyliw
[Ballot comment]
** I support John’s DISUSS.  My feedback are also around clarifying what AODV-RPL inherits from RPL.

** Section 10.  Per “In general, the …
[Ballot comment]
** I support John’s DISUSS.  My feedback are also around clarifying what AODV-RPL inherits from RPL.

** Section 10.  Per “In general, the security considerations for the operation of AODV-RPL are similar to those for the operation of RPL”, to be clear do all of the considerations from RFC6550 apply?  The caveat of “In general …” doesn’t necessarily suggest that to me.

** Section 10.  Unless AODV-RPL is upgrading the requirements of RPL, I believe all of the referenced security framework is optional.  I would recommend being clear on that:

OLD:
Sections 6.1 and 10
  of [RFC6550] describe RPL's security framework, which provides data
  confidentiality, authentication, replay protection, and delay
  protection services.

NEW:
Sections 6.1 and 10 of [RFC6550] describe RPL's optional security framework, which AODV-RPL rely on to provides data confidentiality, authentication, replay protection, and delay protection services.

** Section 10.  Per  “A router can join a temporary DAG … only if it can support the Security Configuration in use, which also specifies the key I use”:

-- Is “Security Configuration” a term of art in RPL to be capitalized?  I'm not sure if this is editorial feedback or a reference to some RPL mechanism.

-- Is this section referring to the processes described in Section 10.2 of RFC6550?  I ask because couldn’t there be an RPL configuration which doesn’t use secure join (i.e., “unsecured mode” per Section 10.1 of RFC6550)?

** Section 10.  This section introduces a new acronym “P2P-RPL” not used in any other part of the document
2021-04-21
10 Roman Danyliw [Ballot Position Update] New position, Discuss, has been recorded for Roman Danyliw
2021-04-21
10 John Scudder
[Ballot comment]
I support Éric's DISCUSS.

1. Section 1:

  Reply.  AODV-RPL currently omits some features compared to AODV -- in
  particular, flagging Route …
[Ballot comment]
I support Éric's DISCUSS.

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.


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”?


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?)


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.


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?


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…”?


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”?


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.


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.


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.


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”.


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”.


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.


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.


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.


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?


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.

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.


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)?


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?


22. Appendix A:

s/pakcet/packet/


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.
2021-04-21
10 John Scudder Ballot comment text updated for John Scudder
2021-04-21
10 Éric Vyncke
[Ballot discuss]
Thank you for the work put into this document. I seems that all cases have been thought of :-) Good job! and having …
[Ballot discuss]
Thank you for the work put into this document. I seems that all cases have been thought of :-) Good job! and having a shorter path between two RPL nodes can be benefitial of course.

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

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

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

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

I hope that this helps to improve the document,

Regards,

-éric

== DISCUSS ==

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

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

Any reason why using …
[Ballot comment]
== COMMENTS ==

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

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

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

== NITS ==

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

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

-- Section 5 --
"R is an intermediate router" or "Rs are intermediate routers" ?
2021-04-21
10 Éric Vyncke [Ballot Position Update] New position, Discuss, has been recorded for Éric Vyncke
2021-04-20
10 Warren Kumari
[Ballot comment]
Firstly, thank you for writing this - I'm really not a ROLL person, but I found it interesting...

I support John and Rob's …
[Ballot comment]
Firstly, thank you for writing this - I'm really not a ROLL person, but I found it interesting...

I support John and Rob's DISCUSSes, but I'll let them carry the heavy load :-)

I have a few nits:
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.'
I could find no 'r'  in Figure 3  - did you mean 'X'?


Section 6.2.1, Step 1:
'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.'
I was unable to parse this. More worryingly, I was also not able to figure out what it should say...

Section 6.3.1:
'default to 1/4 of the time duration determined by the L bit.' - s/L bit/L value'.
This says that the default of 1/4 of the time duration, but I didn't see where /why the default would change. Also, isn't 'time' in 'time duration' unnecessary? Duration implies time.


Appendix A:
'The combination of Received Signal Strength Indication(downstream)  (RSSI) and Expected Number of Transmissions(upstream)" (ETX) ' -- this is a random closing quote without an opening one.
2021-04-20
10 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2021-04-20
10 Robert Wilton
[Ballot discuss]
Hi,

Thank you for your work on this document.

I support John's comment that this document could more clearly state its relationship to …
[Ballot discuss]
Hi,

Thank you for your work on this document.

I support John's comment that this document could more clearly state its relationship to RPL, which may have a bearing on my discuss comment below.

I've balloted discuss on this document because it is not clear to me how this network protocol would be managed.  I.e., this document doesn't seem to have any text related to how the protocol is managed, nor does it define a YANG data model, and I cannot see any YANG data models for this protocol currently in the ROLL WG.

So, the specific questions that I have are:

(1) Are YANG data models and the existing NETCONF/RESTCONF protocols suitable for managing devices running AODV-RPL?

(2) Does this protocol build on RPL, and hence would any YANG data models expect to also build on an RPL YANG data model?

(3) If the answer to 1 or 2 is yes, then a question for the chairs/ADs: Is there a plan for the ROLL WG to develop a YANG data model for this protocol (and RPL if required)?

(4) If the answer to 1 or 2 is no, then what other information can be provided in this document to help implementations create an interoperable management interface for this protocol? 

For clarity, I'm not saying that a YANG data model needs to be provided before this document can progress, but I would like to understand the path to ensuring that this protocol can be managed, which may require additional text depending on the answers to the questions above.

Regards,
Rob
2021-04-20
10 Robert Wilton [Ballot Position Update] New position, Discuss, has been recorded for Robert Wilton
2021-04-19
10 John Scudder
[Ballot discuss]
A lot of effort has clearly gone into this work, thank you. I do have one topic I want to DISCUSS, as it …
[Ballot 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.
2021-04-19
10 John Scudder
[Ballot comment]
1. Section 1:

  Reply.  AODV-RPL currently omits some features compared to AODV -- in
  particular, flagging Route Errors, blacklisting unidirectional links, …
[Ballot 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.


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”?


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?)


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.


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?


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…”?


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”?


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.


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.


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.


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”.


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”.


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.


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.


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.


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?


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.

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.


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)?


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?


22. Appendix A:

s/pakcet/packet/


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.
2021-04-19
10 John Scudder [Ballot Position Update] New position, Discuss, has been recorded for John Scudder
2021-04-19
10 Francesca Palombini
[Ballot comment]
Thank you for the work on this document. I have some minor comments/questions below.

Francesca

1. -----

Section 2.

FP: Thank you for …
[Ballot comment]
Thank you for the work on this document. I have some minor comments/questions below.

Francesca

1. -----

Section 2.

FP: Thank you for this very extensive (and useful) terminology section. I would suggest to add a sentence to say that the reader is expected to be familiar with RFC 6550 terminology. Alternatively, it might be good to add terms defined there and used in this document, such as DODAG and DODAGID, into this section as well. It also might improve readability to add references to documents when appropriate (for example, DIO could reference RFC 6550).

2. -----

  to OrigNode.  Intermediate routers join the Paired DODAGs based on
  the Rank as calculated from the DIO message.  Henceforth in this

FP: Please add a reference to where Rank is first defined, and/or add it to the terminology.

3. -----

  Target Prefix / Address
      (variable-length field) An IPv6 destination address or prefix.
      The Prefix Length field contains the number of valid leading bits
      in the prefix.  The length of the field is the least number of
      octets that can contain all of the bits of the Prefix, in other
      words Floor((7+(Prefix Length))/8) octets.  The remaining bits in

FP: "Floor((7+(Prefix Length))/8)" I am not sure where the "7+" comes from. Noting that the Prefix Length is 7-bit long, I am tempted to say that the number of octets calculated here also includes Prefix Length, however that is not clear from the sentence above ("The length of the field" - I assume the field refers to the Target Prefix / Address only). I think some clarification is necessary.
2021-04-19
10 Francesca Palombini [Ballot Position Update] New position, No Objection, has been recorded for Francesca Palombini
2021-04-16
10 (System) IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2021-04-15
10 Ines Robles Request closed, assignment withdrawn: Peter Van der Stok Telechat IOTDIR review
2021-04-15
10 Ines Robles Closed request for Telechat review by IOTDIR with state 'Withdrawn': Duplicated Entry
2021-04-15
10 Peter Van der Stok Request for Telechat review by IOTDIR Completed: Ready with Nits. Reviewer: Peter Van der Stok. Sent review to list.
2021-04-14
10 Lars Eggert
[Ballot comment]
Section 2, paragraph 1, comment:
> 2.  Terminology

Is there some logic as to which terms are capitalized and which are not? (Also …
[Ballot comment]
Section 2, paragraph 1, comment:
> 2.  Terminology

Is there some logic as to which terms are capitalized and which are not? (Also
in the text.)

-------------------------------------------------------------------------------
All comments below are very minor change suggestions that you may choose to
incorporate in some way (or ignore), as you see fit. There is no need to let me
know what you did with these suggestions.

Section 4.1, paragraph 10, nit:
>    X
>      Reserved.

Any recommendation what this should be set to on send?

Section 4.2, paragraph 9, nit:
>    X
>      Reserved.

Any recommendation what this should be set to on send?

Section 4.2, paragraph 13, nit:
>    Rsv
>      MUST be initialized to zero and ignored upon reception.

I guess these bits are reserved? Could you not just mark them X?

Section 4.3, paragraph 6, nit:
>                Figure 3: ART Option format for AODV-RPL MOP

X is missing from the description of the fields.

Section 1, paragraph 4, nit:
-    functionality to support routes with birectional asymmetric links.
+    functionality to support routes with bidirectional asymmetric links.
+                                          ++

Section 5, paragraph 7, nit:
-    of cells used in 6tisch), a priori knowledge (e.g. link quality
+    of cells used in 6tisch), a priori knowledge (e.g., link quality
+                                                      +

Section 5, paragraph 7, nit:
-    for evaluating link state (see([RFC7548], [RFC7276], [co-ioam]) MAY
-                                  ^
+    for evaluating link state (see [RFC7548], [RFC7276], [co-ioam]) MAY
+                                  ^

Section 6.2.1, paragraph 4, nit:
-      the downward (i.e. towards the TargNode) direction of the link
+      the downward (i.e., towards the TargNode) direction of the link
+                        +

Section 6.3.1, paragraph 2, nit:
-    symmetric route along which both directions satisfy the Objective
-                    ------------
+    symmetric route both of whose directions satisfy the Objective
+                        +++++++++

Section 6.3.1, paragraph 2, nit:
-    routes (i.e.  S=0).  Selection between a qualified symmetric route
-                ^
+    routes (i.e., S=0).  Selection between a qualified symmetric route
+                ^
2021-04-14
10 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert
2021-04-12
10 Ines Robles Request for Telechat review by IOTDIR is assigned to Peter Van der Stok
2021-04-12
10 Ines Robles Request for Telechat review by IOTDIR is assigned to Peter Van der Stok
2021-04-12
10 Ines Robles Request for Telechat review by IOTDIR is assigned to Peter Van der Stok
2021-04-12
10 Ines Robles Request for Telechat review by IOTDIR is assigned to Peter Van der Stok
2021-04-12
10 Ines Robles Assignment of request for Telechat review by IOTDIR to Loganaden Velvindron was rejected
2021-04-12
10 Ines Robles Request for Telechat review by IOTDIR is assigned to Loganaden Velvindron
2021-04-12
10 Ines Robles Request for Telechat review by IOTDIR is assigned to Loganaden Velvindron
2021-04-12
10 Ines Robles Assignment of request for Telechat review by IOTDIR to Toerless Eckert was rejected
2021-04-12
10 Tero Kivinen Request for Telechat review by SECDIR Completed: Has Nits. Reviewer: Tero Kivinen. Sent review to list.
2021-04-11
10 Ines Robles Request for Telechat review by IOTDIR is assigned to Toerless Eckert
2021-04-11
10 Ines Robles Request for Telechat review by IOTDIR is assigned to Toerless Eckert
2021-04-11
10 Éric Vyncke Requested Telechat review by IOTDIR
2021-04-08
10 Éric Vyncke Requested Telechat review by IOTDIR
2021-04-08
10 Tero Kivinen Request for Telechat review by SECDIR is assigned to Tero Kivinen
2021-04-08
10 Tero Kivinen Request for Telechat review by SECDIR is assigned to Tero Kivinen
2021-04-07
10 Amy Vezza Placed on agenda for telechat - 2021-04-22
2021-04-07
10 Alvaro Retana Ballot has been issued
2021-04-07
10 Alvaro Retana [Ballot Position Update] New position, Yes, has been recorded for Alvaro Retana
2021-04-07
10 Alvaro Retana Created "Approve" ballot
2021-04-07
10 (System) Changed action holders to Alvaro Retana (IESG state changed)
2021-04-07
10 Alvaro Retana IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup
2021-04-04
10 (System) Sub state has been changed to AD Followup from Revised ID Needed
2021-04-04
10 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2021-04-04
10 Charles Perkins New version available: draft-ietf-roll-aodv-rpl-10.txt
2021-04-04
10 (System) New version approved
2021-04-04
10 (System) Request for posting confirmation emailed to previous authors: "S.V.R Anand" , Bing Liu , Charles Perkins , Mingui Zhang , Satish Anamalamudi
2021-04-04
10 Charles Perkins Uploaded new revision
2021-03-31
09 (System) Changed action holders to Charles Perkins, Alvaro Retana, Mingui Zhang, Satish Anamalamudi, S.V.R Anand, Bing Liu (IESG state changed)
2021-03-31
09 Alvaro Retana IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for Writeup
2021-03-31
09 Alvaro Retana Ballot writeup was changed
2021-03-31
09 (System) IESG state changed to Waiting for Writeup from In Last Call
2021-03-30
09 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2021-03-30
09 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-roll-aodv-rpl-09. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-roll-aodv-rpl-09. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the Mode of Operation registry on the Routing Protocol for Low Power and Lossy Networks (RPL) registry page located at:

https://www.iana.org/assignments/rpl/

a new registration will be made as follows:

Value: [ TBD-at-Registration ]
Description: AODV-RPL
Reference: [ RFC-to-be ]

IANA notes that the authors have suggested a value of 5 for this registration.

Second, in the RPL Control Message Options registry also on the Routing Protocol for Low Power and Lossy Networks (RPL) registry page located at:

https://www.iana.org/assignments/rpl/

three new registrations will be made as follows:

Value: [ TBD-at-Registration ]
Meaning: RREQ Option
Reference: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Meaning: RREP Option
Reference: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Meaning: ART Option
Reference: [ RFC-to-be ]

IANA notes that the authors have suggested the values 0x0B, 0x0C, and 0x0D for these registrations.

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Please note that specific values cannot be reserved. However, early allocation is available for some types of registrations. For more information, please see RFC 7120.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2021-03-22
09 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Tero Kivinen. Sent review to list.
2021-03-19
09 Jean Mahoney Request for Last Call review by GENART is assigned to Meral Shirazipour
2021-03-19
09 Jean Mahoney Request for Last Call review by GENART is assigned to Meral Shirazipour
2021-03-19
09 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Susan Hares
2021-03-19
09 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Susan Hares
2021-03-18
09 Tero Kivinen Request for Last Call review by SECDIR is assigned to Tero Kivinen
2021-03-18
09 Tero Kivinen Request for Last Call review by SECDIR is assigned to Tero Kivinen
2021-03-16
09 Cindy Morgan IANA Review state changed to IANA - Review Needed
2021-03-16
09 Cindy Morgan
The following Last Call announcement was sent out (ends 2021-03-31):

From: The IESG
To: IETF-Announce
CC: Ines Robles , aretana.ietf@gmail.com, draft-ietf-roll-aodv-rpl@ietf.org, mariainesrobles@googlemail.com, …
The following Last Call announcement was sent out (ends 2021-03-31):

From: The IESG
To: IETF-Announce
CC: Ines Robles , aretana.ietf@gmail.com, draft-ietf-roll-aodv-rpl@ietf.org, mariainesrobles@googlemail.com, roll-chairs@ietf.org, roll@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (AODV based RPL Extensions for Supporting Asymmetric P2P Links in Low-Power and Lossy Networks) to Proposed Standard


The IESG has received a request from the Routing Over Low power and Lossy
networks WG (roll) to consider the following document: - 'AODV based RPL
Extensions for Supporting Asymmetric P2P Links in Low-
  Power and Lossy Networks'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-03-31. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  Route discovery for symmetric and asymmetric Point-to-Point (P2P)
  traffic flows is a desirable feature in Low power and Lossy Networks
  (LLNs).  For that purpose, this document specifies a reactive P2P
  route discovery mechanism for both hop-by-hop routing and source
  routing: Ad Hoc On-demand Distance Vector Routing (AODV) based RPL
  protocol (AODV-RPL).  Paired Instances are used to construct
  directional paths, in case some of the links between source and
  target node are asymmetric.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-roll-aodv-rpl/



No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references, which will be removed in the next revision.
See RFC 3967 for additional information:
    rfc7416: A Security Threat Analysis for the Routing Protocol for Low-Power and Lossy Networks (RPLs) (Informational - Internent Engineering Task Force (IETF))
    rfc6998: A Mechanism to Measure the Routing Metrics along a Point-to-Point Route in a Low-Power and Lossy Network (Experimental - Internent Engineering Task Force (IETF))



2021-03-16
09 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2021-03-16
09 Alvaro Retana Last call was requested
2021-03-16
09 Alvaro Retana Ballot approval text was generated
2021-03-16
09 Alvaro Retana Ballot writeup was generated
2021-03-16
09 (System) Changed action holders to Alvaro Retana (IESG state changed)
2021-03-16
09 Alvaro Retana IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2021-03-16
09 Alvaro Retana Last call announcement was changed
2021-03-16
09 Alvaro Retana Last call announcement was generated
2021-02-02
09 (System) Sub state has been changed to AD Followup from Revised ID Needed
2021-02-02
09 Charles Perkins New version available: draft-ietf-roll-aodv-rpl-09.txt
2021-02-02
09 (System) New version approved
2021-02-02
09 (System) Request for posting confirmation emailed to previous authors: "S.V.R Anand" , Bing Liu , Charles Perkins , Mingui Zhang , Satish Anamalamudi , roll-chairs@ietf.org
2021-02-02
09 Charles Perkins Uploaded new revision
2020-06-16
08 Alvaro Retana IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup
2020-05-07
08 (System) Sub state has been changed to AD Followup from Revised ID Needed
2020-05-07
08 Charles Perkins New version available: draft-ietf-roll-aodv-rpl-08.txt
2020-05-07
08 (System) New version approved
2020-05-07
08 (System) Request for posting confirmation emailed to previous authors: "S.V.R Anand" , Bing Liu , Charles Perkins , Satish Anamalamudi , Mingui Zhang
2020-05-07
08 Charles Perkins Uploaded new revision
2019-08-01
07 Alvaro Retana === AD Review of draft-ietf-roll-aodv-rpl-07 ===
https://mailarchive.ietf.org/arch/msg/roll/XXaPFyhqiUS_bpYSJT45UaLyeec
2019-08-01
07 Alvaro Retana IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2019-06-21
07 Alvaro Retana Notification list changed to Ines Robles <mariainesrobles@googlemail.com>, aretana.ietf@gmail.com from Ines Robles <mariainesrobles@googlemail.com>
2019-06-21
07 Alvaro Retana IESG state changed to AD Evaluation from Publication Requested
2019-04-15
07 Ines Robles
draft-ietf-roll-aodv-rpl - Write Up

Previous state: WG Document
Current state:  Last Call Finished on 04-19
--------------------------------------

1. Summary


* Responsible Area Director: Alvaro Retana
* …
draft-ietf-roll-aodv-rpl - Write Up

Previous state: WG Document
Current state:  Last Call Finished on 04-19
--------------------------------------

1. Summary


* Responsible Area Director: Alvaro Retana
* Document Shepherd: Ines Robles mariainesrobles@googlemail.com

This document specifies a reactive P2P route discovery mechanism for both hop-by-hop routing and source routing: Ad Hoc On-demand Distance Vector Routing (AODV) based RPL protocol.  Paired Instances are used to construct directional paths, in case some of the links between source and target node are asymmetric.

The Intended RFC status is Standards Track.

2. Review and Consensus

During the last call there were comments that were addressed in version 06.

This document was reviewed in roll working group.

3. Intellectual Property

Email sent to the Authors asking confirmation: All authors confirmed.


4. Other points

Checklist for draft 06

Does the shepherd stand behind the document and think the document is ready for
publication? Yes.

Is the correct RFC type indicated in the title page header?  Yes.

Is the abstract both brief and sufficient, and does it stand alone as a brief summary?
Yes

Is the intent of the document accurately and adequately explained in the introduction?
Yes.

Have all required formal reviews (MIB Doctor, Media Type, URI, etc.) been requested
and/or completed? Not apply.



Has the shepherd performed automated checks -- idnits (see ​
http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist), checks of BNF rules,
XML code and schemas, MIB definitions, and so on -- and determined that the
document passes the tests? (In general, nits should be fixed before the document is
sent to the IESG. If there are reasons that some remain (false positives, perhaps, or
abnormal things that are necessary for this particular document), explain them.)

Nits results:

(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)

** Downref: Normative reference to an Experimental RFC: RFC 3561

** Downref: Normative reference to an Experimental RFC: RFC 6998


Summary: 2 errors (**), 0 flaws (~~), 0 warnings (==), 1 comment (--).




Has each author stated that their direct, personal knowledge of any IPR related to this
document has already been disclosed, in conformance with BCPs 78 and 79?
Yes

Have all references within this document been identified as either normative or
informative, and does the shepherd agree with how they have been classified?
Yes.

Are all normative references made to documents that are ready for advancement and
are otherwise in a clear state?
Yes.

If publication of this document changes the status of any existing RFCs, are those
RFCs listed on the title page header, and are the changes listed in the abstract and
discussed (explained, not just mentioned) in the introduction?  Not apply.

If this is a "bis" document, have all of the errata been considered? Not apply.

IANA Considerations:
Are the IANA Considerations clear and complete? Yes.


Are all protocol extensions that the document makes associated with the appropriate
reservations in IANA registries? Yes.

Are all IANA registries referred to by their exact names (check them in ​
http://www.iana.org/protocols/ to be sure)? Yes.

For any new registries that this document creates, has the working group actively
chosen the allocation procedures and policies and discussed the alternatives? Not apply.

Have reasonable registry names been chosen (that will not be confused with those of
other registries),? and have the initial contents and valid value ranges been clearly specified? Yes.

Issues raised by document shepherd were fixed in version 07

Thank you for this document,

Ines.
2019-04-15
07 Ines Robles Responsible AD changed to Alvaro Retana
2019-04-15
07 Ines Robles IETF WG state changed to Submitted to IESG for Publication from In WG Last Call
2019-04-15
07 Ines Robles IESG state changed to Publication Requested from I-D Exists
2019-04-15
07 Ines Robles IESG process started in state Publication Requested
2019-04-15
07 Ines Robles Changed consensus to Yes from Unknown
2019-04-15
07 Ines Robles Intended Status changed to Proposed Standard from None
2019-04-15
07 Ines Robles Tag Revised I-D Needed - Issue raised by WGLC cleared.
2019-04-15
07 Ines Robles
draft-ietf-roll-aodv-rpl - Write Up

Previous state: WG Document
Current state:  Last Call Finished on 04-19
--------------------------------------

1. Summary


* Responsible Area Director: Alvaro Retana
* …
draft-ietf-roll-aodv-rpl - Write Up

Previous state: WG Document
Current state:  Last Call Finished on 04-19
--------------------------------------

1. Summary


* Responsible Area Director: Alvaro Retana
* Document Shepherd: Ines Robles mariainesrobles@googlemail.com

This document specifies a reactive P2P route discovery mechanism for both hop-by-hop routing and source routing: Ad Hoc On-demand Distance Vector Routing (AODV) based RPL protocol.  Paired Instances are used to construct directional paths, in case some of the links between source and target node are asymmetric.

The Intended RFC status is Standards Track.

2. Review and Consensus

During the last call there were comments that were addressed in version 06.

This document was reviewed in roll working group.

3. Intellectual Property

Email sent to the Authors asking confirmation: All authors confirmed.


4. Other points

Checklist for draft 06

Does the shepherd stand behind the document and think the document is ready for
publication? Yes.

Is the correct RFC type indicated in the title page header?  Yes.

Is the abstract both brief and sufficient, and does it stand alone as a brief summary?
Yes

Is the intent of the document accurately and adequately explained in the introduction?
Yes.

Have all required formal reviews (MIB Doctor, Media Type, URI, etc.) been requested
and/or completed? Not apply.



Has the shepherd performed automated checks -- idnits (see ​
http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist), checks of BNF rules,
XML code and schemas, MIB definitions, and so on -- and determined that the
document passes the tests? (In general, nits should be fixed before the document is
sent to the IESG. If there are reasons that some remain (false positives, perhaps, or
abnormal things that are necessary for this particular document), explain them.)

Nits results:

(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)

** Downref: Normative reference to an Experimental RFC: RFC 3561

** Downref: Normative reference to an Experimental RFC: RFC 6998


Summary: 2 errors (**), 0 flaws (~~), 0 warnings (==), 1 comment (--).




Has each author stated that their direct, personal knowledge of any IPR related to this
document has already been disclosed, in conformance with BCPs 78 and 79?
Yes

Have all references within this document been identified as either normative or
informative, and does the shepherd agree with how they have been classified?
Yes.

Are all normative references made to documents that are ready for advancement and
are otherwise in a clear state?
Yes.

If publication of this document changes the status of any existing RFCs, are those
RFCs listed on the title page header, and are the changes listed in the abstract and
discussed (explained, not just mentioned) in the introduction?  Not apply.

If this is a "bis" document, have all of the errata been considered? Not apply.

IANA Considerations:
Are the IANA Considerations clear and complete? Yes.


Are all protocol extensions that the document makes associated with the appropriate
reservations in IANA registries? Yes.

Are all IANA registries referred to by their exact names (check them in ​
http://www.iana.org/protocols/ to be sure)? Yes.

For any new registries that this document creates, has the working group actively
chosen the allocation procedures and policies and discussed the alternatives? Not apply.

Have reasonable registry names been chosen (that will not be confused with those of
other registries),? and have the initial contents and valid value ranges been clearly specified? Yes.

Issues raised by document shepherd were fixed in version 07

Thank you for this document,

Ines.
2019-04-12
07 Charles Perkins New version available: draft-ietf-roll-aodv-rpl-07.txt
2019-04-12
07 (System) New version approved
2019-04-12
07 (System) Request for posting confirmation emailed to previous authors: "S.V.R Anand" , Satish Anamalamudi , Bing Liu , Charles Perkins , Mingui Zhang
2019-04-12
07 Charles Perkins Uploaded new revision
2019-04-10
06 Ines Robles Notification list changed to Ines Robles <mariainesrobles@googlemail.com>
2019-04-10
06 Ines Robles Document shepherd changed to Ines Robles
2019-04-10
06 Ines Robles
draft-ietf-roll-aodv-rpl - Write Up

Previous state: WG Document
Current state:  Last Call Finished on 04-19
--------------------------------------

1. Summary


* Responsible Area Director: Alvaro Retana
* …
draft-ietf-roll-aodv-rpl - Write Up

Previous state: WG Document
Current state:  Last Call Finished on 04-19
--------------------------------------

1. Summary


* Responsible Area Director: Alvaro Retana
* Document Shepherd: Ines Robles mariainesrobles@googlemail.com

This document specifies a reactive P2P route discovery mechanism for both hop-by-hop routing and source routing: Ad Hoc On-demand Distance Vector Routing (AODV) based RPL protocol.  Paired Instances are used to construct directional paths, in case some of the links between source and target node are asymmetric.

The Intended RFC status is Standards Track.

2. Review and Consensus

During the last call there were comments that were addressed in version 06.

This document was reviewed in roll working group.

3. Intellectual Property

Email sent to the Authors asking confirmation: All authors confirmed.


4. Other points

Checklist for draft 06

Does the shepherd stand behind the document and think the document is ready for
publication? Yes.

Is the correct RFC type indicated in the title page header?  Yes.

Is the abstract both brief and sufficient, and does it stand alone as a brief summary?
Yes

Is the intent of the document accurately and adequately explained in the introduction?
Yes.

Have all required formal reviews (MIB Doctor, Media Type, URI, etc.) been requested
and/or completed? Not apply.



Has the shepherd performed automated checks -- idnits (see ​
http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist), checks of BNF rules,
XML code and schemas, MIB definitions, and so on -- and determined that the
document passes the tests? (In general, nits should be fixed before the document is
sent to the IESG. If there are reasons that some remain (false positives, perhaps, or
abnormal things that are necessary for this particular document), explain them.)

Nits results:

(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)

** Downref: Normative reference to an Experimental RFC: RFC 3561

** Downref: Normative reference to an Experimental RFC: RFC 6998


Summary: 2 errors (**), 0 flaws (~~), 0 warnings (==), 1 comment (--).




Has each author stated that their direct, personal knowledge of any IPR related to this
document has already been disclosed, in conformance with BCPs 78 and 79?
Yes

Have all references within this document been identified as either normative or
informative, and does the shepherd agree with how they have been classified?
Yes.

Are all normative references made to documents that are ready for advancement and
are otherwise in a clear state?
Yes.

If publication of this document changes the status of any existing RFCs, are those
RFCs listed on the title page header, and are the changes listed in the abstract and
discussed (explained, not just mentioned) in the introduction?  Not apply.

If this is a "bis" document, have all of the errata been considered? Not apply.

IANA Considerations:
Are the IANA Considerations clear and complete? Yes.


Are all protocol extensions that the document makes associated with the appropriate
reservations in IANA registries? Yes.

Are all IANA registries referred to by their exact names (check them in ​
http://www.iana.org/protocols/ to be sure)? Yes.

For any new registries that this document creates, has the working group actively
chosen the allocation procedures and policies and discussed the alternatives? Not apply.

Have reasonable registry names been chosen (that will not be confused with those of
other registries),? and have the initial contents and valid value ranges been clearly specified? Yes.

--- Minor Issues ---

- Terminology section should add the reference of RFC8174

- Section 4.3 only explain two fields of Figure 3: Target option format for AODV-RPL MoP, it would be nice if you could explain the other fields also.

Thank you for this document,

Ines.
2019-03-12
06 Ines Robles Added to session: IETF-104: roll  Mon-1610
2019-03-07
06 Charles Perkins New version available: draft-ietf-roll-aodv-rpl-06.txt
2019-03-07
06 (System) New version approved
2019-03-07
06 (System) Request for posting confirmation emailed to previous authors: "S.V.R Anand" , Satish Anamalamudi , Bing Liu , Charles Perkins , Mingui Zhang
2019-03-07
06 Charles Perkins Uploaded new revision
2018-11-02
05 Ines Robles Added to session: IETF-103: roll  Mon-0900
2018-10-18
05 Bing (Remy) Liu New version available: draft-ietf-roll-aodv-rpl-05.txt
2018-10-18
05 (System) New version approved
2018-10-18
05 (System)
Request for posting confirmation emailed to previous authors: "S.V.R Anand" , Charles Perkins , Mingui Zhang , roll-chairs@ietf.org, Satish Anamalamudi , Bing Liu , …
Request for posting confirmation emailed to previous authors: "S.V.R Anand" , Charles Perkins , Mingui Zhang , roll-chairs@ietf.org, Satish Anamalamudi , Bing Liu , Abdur Sangi
2018-10-18
05 Bing (Remy) Liu Uploaded new revision
2018-08-29
04 Ines Robles Tag Revised I-D Needed - Issue raised by WGLC set. Tag Revised I-D Needed - Issue raised by WG cleared.
2018-08-29
04 Ines Robles Tag Revised I-D Needed - Issue raised by WG set.
2018-08-29
04 Ines Robles IETF WG state changed to In WG Last Call from WG Document
2018-07-14
04 Ines Robles Added to session: IETF-102: roll  Tue-0930
2018-07-02
04 Charles Perkins New version available: draft-ietf-roll-aodv-rpl-04.txt
2018-07-02
04 (System) New version approved
2018-07-02
04 (System) Request for posting confirmation emailed to previous authors: "S.V.R Anand" , Charles Perkins , Mingui Zhang , Satish Anamalamudi , Bing Liu , Abdur Sangi
2018-07-02
04 Charles Perkins Uploaded new revision
2018-03-21
03 Ines Robles Removed from session: IETF-101: roll  Thu-0930
2018-03-21
03 Ines Robles Added to session: IETF-101: roll  Fri-0930
2018-03-21
03 Ines Robles Added to session: IETF-101: roll  Thu-0930
2018-03-05
03 Charles Perkins New version available: draft-ietf-roll-aodv-rpl-03.txt
2018-03-05
03 (System) New version approved
2018-03-05
03 (System) Request for posting confirmation emailed to previous authors: "S.V.R Anand" , Charles Perkins , Mingui Zhang , roll-chairs@ietf.org, Satish Anamalamudi , Abdur Sangi
2018-03-05
03 Charles Perkins Uploaded new revision
2017-09-09
02 Charles Perkins New version available: draft-ietf-roll-aodv-rpl-02.txt
2017-09-09
02 (System) New version approved
2017-09-09
02 (System) Request for posting confirmation emailed to previous authors: "S.V.R Anand" , Satish Anamalamudi , Abdur Sangi , Charles Perkins , Mingui Zhang
2017-09-09
02 Charles Perkins Uploaded new revision
2017-07-04
01 Ines Robles Added to session: IETF-99: roll  Thu-1330
2017-03-30
01 Ines Robles Added to session: IETF-98: roll  Thu-1740
2017-03-12
01 Satish Anamalamudi New version available: draft-ietf-roll-aodv-rpl-01.txt
2017-03-12
01 (System) New version approved
2017-03-12
01 (System) Request for posting confirmation emailed to previous authors: "S.V.R Anand" , Charles Perkins , Mingui Zhang , roll-chairs@ietf.org, Abdur Sangi , Satish Anamalamudi
2017-03-12
01 Satish Anamalamudi Uploaded new revision
2016-12-07
00 Peter Van der Stok This document now replaces draft-satish-roll-aodv-rpl instead of None
2016-12-07
00 Abdur Sangi New version available: draft-ietf-roll-aodv-rpl-00.txt
2016-12-07
00 (System) WG -00 approved
2016-12-07
00 Abdur Sangi Set submitter to "Abdur Rashid Sangi ", replaces to draft-satish-roll-aodv-rpl and sent approval email to group chairs: roll-chairs@ietf.org
2016-12-07
00 Abdur Sangi Uploaded new revision