Reviewer: Tony Przygienda Review result: Has Issues I have been selected to do a routing directorate “early” review of this draft. https://datatracker.ietf.org/doc/html/draft-ietf-roll-aodv-rpl-16 Document: https://datatracker.ietf.org/doc/html/draft-ietf-roll-aodv-rpl-16 Reviewer: Tony Przygienda Review Date: 03/23 Intended Status: Standards Summary: I have good amount of readability suggestions and some minor doubts on correctness/robustness. Comments The draft made for quite a lot of reading for me since it relies on so many other RFCs & drafts I was only superficially familiar with. No complaint, just observation. Overall readability is pretty good but because it's a dense spec bits of indication of reason/logic for certain parts of the spec would help a lot as well examples in places pointed out below. Generally, introduction section would benefit from 1-2 figures showing the flows of RREQ etc. with flags resulting for symmetric/assymetric case and collisions/multiple downstream RREQ sends & such anomalous cases. _Heavy_ readability suggestions: * Terminology ** "The RPLInstanceID in the RREP message along with the Delta value indicates the associated RREQ-InstanceID." is heavily cryptic and leaves one guessing whether the Orig & Trg RPL Instance IDs are related somehow to 'pair' ? It becomes clear later but either explain in terminology or just say that both InstanceIDs are matched by mechanism explained in "section 6.3.3" to correlate them (or define the term "pair" precisely in terminology). * section 3: "the proper OF" "with 'D' == 0" is _heavily_ cryptic until one -really- knows 6550 intimately. Expand the acronym, flag semantics * "The route discovery process is initiated when an application at the OrigNode has data to be transmitted to the TargNode, but does not have a route that satisfies the Objective Function for the target of the application's data." How is taht possible if e.g. a global grounded DAG that can reach the destination is already in place which would be kind of default 6550 behavior? Readability suggestions: * include RRPE and RREQ in terminology for easier reading. yes, it's in intro & it's really ROLL but nevertheless, I had to go and search for it. * "This reduces the cost to building only one DODAG." Not clear what that means. I think it's "with that the node can build one DODAG for multiple targets" ? * "The upstream neighbor router that transmitted the received RREQ-DIO is selected as the preferred parent." would benefit from clarifying that it's parent only for this DAG Robusntess/Correctness suggestions: * 'H' flag is redundant as information (either vector is there or not and that basically indicates H). This will lead to semantically unclear packets. In case H is set but a vector is sent what to do? what is semantic of H not set and no vector? * L: 2-bit unsigned integer defined as in RREQ option. The lifetime of the RREP-Instance MUST be no greater than the lifetime of the RREQ-Instance to which it is paired. and what if not? * Logic behind Intersection instaed of union in section 6.2.2 is a mystery. Why not only take the newest RREQ based on sequence etc ... Is it because 2 routers can receive 2 RREQ on all-AODV-RPL-nodes in different sequence and the result should be same no matter the order? Also, it would be good to spell out how long all those RREQs have to be kept by a node ? for duration of the DAG? What happens if different RREQs come in with different values for S bit? how is the S-bit joined (maybe I missed it reading) * "stale sequence number" needs defintion earlier instead of popping up in 6.4.3 after being already used * " In this case, the router MAY optionally associate". What does "associate" mean here? Same as "pair"? or simply "it received it before and was in path" * 6.3.3. is cryptic, it is unclear why the Targ cannot just send the delta and still sends its own RPLInstanceID. Examples of collision/no collicion would go a long way here * Secton 7: a sentence is probably missing that a intermediate router MUST generate a G-RREP and send it further upstream after processing a received G-RREP Omissions: * what about multicast? is it specifically excluded? thanks -- tony -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
