[Roll] aodv-rpl review

Peter van der Stok <stokcons@bbhmail.nl> Wed, 28 November 2018 09:06 UTC

MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_d5512b484225a806588a9e436e2cb0bd"
Date: Wed, 28 Nov 2018 10:06:32 +0100
From: Peter van der Stok <stokcons@bbhmail.nl>
To: Roll <roll@ietf.org>, Draft-ietf-roll-aodv-rpl <draft-ietf-roll-aodv-rpl@ietf.org>
Organization: vanderstok consultancy
Reply-To: consultancy@vanderstok.org
Mail-Reply-To: consultancy@vanderstok.org
Message-ID: <7e90f9a49be79a88261a3e77bc6e27f7@bbhmail.nl>
User-Agent: Roundcube Webmail/1.2.7
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/5BarvR4kROWzFhLJRQW3eyz8zDw>
Subject: [Roll] aodv-rpl review
Precedence: list

Hi aodv-rpl co-authors,

I promised to do a quick review of the document before passing it to the
shepherd.

The document reads rather smoothly, and seems to be complete.
Question: are there any implementations, and has there been an interop?
I vaguely remember the subject being mentioned, but do not remember the
answer.

I like the appendix A, it helps enormously to understand the
bidirectional asymmetric link concept.

Major question: what is the relation with 6997 P2P-RPL. 
Does this document replace RFC 6997. To me it seems that in the case of
symmetric links only, AODV-RPL degrades to P2P-RPL. Probably not in an
interoperable way given the different MOP etc.
May be you can explain your ideas in this respect. 
RFC 6997 is "experimental" to go to STD when more experience was gained.
Does that also apply to this document, or is there an operational direct
need identified.

Should 5548, 5673, 5826, 5867 not go to informational; you don't need
them to implement the spec.

Last but not least: section 10 security Considerations is more than
terse; I am afraid that the security review will judge this inadequate.
You can look what has been done in the npdao draft; but I cannot
guarantee that this is sufficient.
The MANET WG has been active in describing threats in RFC 7985; may be
you can find inspiration there to categorize the problems and identify
the ones applying to AODV-RPL.

Some minor syntactical things that hit my eye.

You never write out RPL, although the other acronyms have been honored
as such.
In section 1 the term TargNode appears all of the sudden; suggest to use
Target Node in section 1.
You use application-specific routing and P2P routing; what is the
difference?
section 3: s/established are/are established/
section 6.1: s/increse/increase/
s/previous/previously/
s/increased number/sequence number/

Greetings, 
and thanks for the work,

Peter 
-- 
Peter van der Stok
vanderstok consultancy
mailto: consultancy@vanderstok.org, stokcons@bbhmail.nl
www: www.vanderstok.org [1]
tel NL: +31(0)492474673     F: +33(0)966015248 

Links:
------
[1] http://www.vanderstok.org

[Roll] aodv-rpl review Peter van der Stok
Re: [Roll] aodv-rpl review Charlie Perkins