Subject: [manet] Comment THC#3 AODVv2 I-D structure and implementation (was Re: Regarding the reactive protocol development.)

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 21 Nov 2013 03:22:20 +0100

Hi Charlie,

Just a general comment, I was thinking we are in stage of editing text
of the I-D for better readings and not in stage of changing structure
for better reading. If we discuss new ideas (as changing draft main
ideas) in one thread it will be difficult to read/follow productive
discussion and may make the I-D progress slow. I want to break the
previous discussion in parts because it does not give new edit text
related to draft, but provides many new ideas that need separating
them into discussions or tracker tickets for best progress.

I support that the structure of AODVv2 draft should be similar to
AODVv1 RFC3561 structure. I don't think the draft should
specify/restrict how to implement as in state machines, but specify
what are the AODVv2 procedures, IMHO, usually we are implementing
router procedures not router states. So restructuring I-D for router
states may make it restricted and not flexible/interoperable.

IMO, the optional features should not be separated from each
procedure, because if we separate it for simpler reading it will make
implementation difficult. So if some people say the I-D is difficult
to read, then I say because it is easier to implement, that is a trade
off that we need to consider, so restructure to make it easy to read
may make it difficult to implement.

comments below,

AB

On 11/20/13, Charles E. Perkins <[email-masked]> wrote:
>
> Hello folks,
>
> I'm trying to identify the issues so that we can go about finding
> technical resolutions.  Follow-up below:
>
> On 11/8/2013 11:44 AM, Thomas Heide Clausen wrote:
..
>> 3) The document is extremely unstructured. When I get a message X, then
>> what procedure must I follow? This information is scattered throughout the
>> 60ish pages, and it renders it extremely complicated to even begin to
>> understand how to implement correctly. I've read the document on the way
>> over to Vancouver, and I've read it again this morning. I still can't
>> properly draw the state machines, and there're processing bits that I
>> *think* are not specified (but maybe reading it a 3rd time is required).
>> The point here is, the IETF writes specifications so as to help
>> implementers make correct implementations. This document makes it a lot of
>> work to try to figure out what's supposed to be implemented.
>>
>> 	Note: This issue also was raised in the review cited under point 1.The
>> document must be
>> 	substantially revised to this effect.
>
> There are only the three messages: RREQ, RREP, and RERR.  I don't think
> that state
> machines are the best way to exhibit the simple flow of control for
> these messages,
> but an appendix could be added for this purpose.

I don't think it is necessary it may add confusion, especially for
security considerations.

>
> Since the flow of control is substantially the same as for AODV RFC
> 3561, and people
> had no trouble with that, I know it's quite easy to do.  I am quite open
> to suggestion
> about how to make improvements; text is appreciated.

I had no problem implementing RFC3561

>
> Would you like an introductory session that simply puts in the signaling
> diagrams with no other explanatory material other than cross-references?

I think this session diagram can be done in the appendix which
clarifies for readers more than to implementers.

---

From: Thomas Clausen <[email-masked]>
Date: Thu, 21 Nov 2013 13:18:13 +0100

On 21 Nov 2013, at 03:22, Abdussalam Baryun <[email-masked]> wrote:

> what are the AODVv2 procedures,

State machines do not "restrict how to implement", but they are an unambiguous way to *specify* protocol operations.

Thomas

> IMHO, usually we are implementing