Skip to main content

Last Call Review of draft-ietf-roll-aodv-rpl-09
review-ietf-roll-aodv-rpl-09-secdir-lc-kivinen-2021-03-22-00

Request Review of draft-ietf-roll-aodv-rpl
Requested revision No specific revision (document currently at 14)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2021-03-31
Requested 2021-03-16
Authors Charles E. Perkins , S.V.R Anand , Satish Anamalamudi , Bing (Remy) Liu
Draft last updated 2021-03-22
Completed reviews Secdir Last Call review of -09 by Tero Kivinen (diff)
Genart Last Call review of -10 by Meral Shirazipour (diff)
Secdir Telechat review of -10 by Tero Kivinen (diff)
Iotdir Telechat review of -10 by Peter Van der Stok (diff)
Assignment Reviewer Tero Kivinen
State Completed
Review review-ietf-roll-aodv-rpl-09-secdir-lc-kivinen-2021-03-22
Posted at https://mailarchive.ietf.org/arch/msg/secdir/AQ4AmsHzH-qAkJggRGCRWbkUR2I
Reviewed revision 09 (document currently at 14)
Result Has Nits
Completed 2021-03-22
review-ietf-roll-aodv-rpl-09-secdir-lc-kivinen-2021-03-22-00
I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area directors.
 Document editors and WG chairs should treat these comments just like any other
last call comments.

The title of the draft has some acronyms which are not expanded (AODV, P2P) and
if you expand them the title comes way too long. I would propose a usable
title, which might not need to use all possible acronyms, but would better
explain what this document is trying to do.

This draft defines a new mode of operation to the allow peer to peer on demand
routing in low power and lossy networks. I have not enough knowledge of RPL to
really know how the new mode differs from the old methods. The security
considerations section points to the RFC6550, and then explains that if rogue
router has key it can do all kind of things.

Nits:

In section 1 the text "RPL [RFC6550] (Routing Protocol for Low-Power and Lossy
Networks)" defines acronyms differently than what is used everywhere else. In
all other cases the document uses format where the acronym is in parenthesis
after the full text, i.e. "Routing Protocol for Low-Power and Lossy Networks
(RPL) [RFC6550]" format. I would propose using the same format also for here.

In section 1 there is acronym DAG which is not expanded, expand it on first
use. Also there are unexpanded acronyms DAO, P2MP, which are not used anywhere
else, perhaps just expand them here. In same paragraph there is also acronym
MOP which is not expanded here on its first use, but it is expanded later.
Expand it here on its first use.

What is the difference between different reserve bits X and r in sections
4.1/4.2 and 4.3?

Period missing from the end of sentence of the Option Length description in
Section 4.3.

In the IANA considerations section I propose add a note to RFC editor saying
that the sentences saying " The parenthesized numbers are only suggestions."
needs to be removed prior publication.