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 |