Subject: [manet] Partial comments to draft-ietf-manet-aodvv2-11

From: Thomas Clausen <[email-masked]>
Date: Wed, 5 Aug 2015 21:04:10 +0200

[Apparently, the list reflector considered the original mail with a pdf of about 300kB to be too big — zip resulted in something <200kB, here’s to hoping that that'll make it through]

All,

An AD suggested that it would be a good idea if I did a review of the latest draft-ietf-manet-aodvv2-11, and that I posted the review on the list. So, I did a review on a dead-tree version, and am in the process of typing up my comments; here’s the first batch in the attached PDF.

I’d first like to Echo Chris’ general review comment, since I am of the same opinion as him on that matter:

	"What’s not reviewed? Pretty much all of the actual algorithmic part of the 
	 protocol. Not because I’m suggesting that doesn’t need review, quite the 
	 contrary, but one thing at a time. Not yet ready for Last Call.”

[Well, except that I did try to review some of the algorithmic parts also, but I do definitely not claim to have been complete here yet — one thing at a time.]

Some overall remarks to the document:

	o	The document has improved since my last review; most notably, it seems to be
		using RFC5444 correctly. Thank you for that effort. Also, the description of the
		algorithms is more readable than some past versions that I’ve reviewed.

	o	I second Chris’ comments in that there is a need for a solid editorial pass, notably
		on normative language, but generally there’s a need for some “editing for clarity”
		through-and-through in the document.

	o	“Multiple interfaces” and “multiple addresses per interface” — it is murky in the document
		if the latter are supported, and I am not convinced that what is written about the support
		for the former is correct and complete. There are some subtleties that are hard to
		get right with multiple interfaces, and this is something that needs to be worked through.

	o	On the previous point, the terms “Router Client” and “Node” and the like actually
		make it tedious/impossible to work through if the specification supports multiple 
		interfaces/addresses.

		For example, a phrase “the IP address of a node” used in a processing description is 
		not precise enough (I think): interpreted literally it implies “a single IP Address is supported
		per ’node'”. Interpreted generously, it means “any IP Address of the node” which would 
		make the protocol break in at least one instance. Interpreted in a way which would not
		“break the protocol in that instance” is not supported by the signalling as described (at least,
		according to my understanding).

	o	The interaction “routing process”—“forwarding process” needs to be called out very
		carefully, much more rigorously than in Appendix A, and not in an appendix.

	o	Appendix D must go. I am less lenient than Chris here, since IMO having two different
		descriptions of the same processing and signalling in the same document is bound to
		(given that it’s human to err) be a source of inconsistencies.

	o	I strongly think that the security considerations will not fly past the SEC-ADs, and I think
		that they’d be right in not letting it. I’ve got some detailed comments that will follow as I 
		get through typing them all up, but this is a heads up that I consider this to be a major 
		undertaking still to be done.

Anyways, without further ado, comments up to and including section 4 in the below. I’ll do my best to type up my comments to the rest without too much of a delay

Best,

Thomas