Subject: [manet] AODVv2 Decision

From: Justin Dean <[email-masked]>
Date: Wed, 4 May 2016 23:49:07 -0400

Working Group,

I will not be passing AODVv2 out of the working group and to the IESG.
This was not an easy decision, nor one made lightly. However, despite many
attempts to draft this email otherwise, I found I could not justify
AODVv2’s release. AODVv2 is released to the document editors. The following
is the rationale for my decision.

There is insufficient consensus within MANET to make the passage
appropriate.  More importantly, perhaps, is that this lack of consensus is
justified by the significance of the outstanding issues.  These issues
include: security, metrics, multiple interface operation with shared ip
addresses, possible looping, non-symmetric links, ordering of processing
operations, lack of jitter specification, removal of timeouts, and gateway
limitations.  Many of these issues have been discussed at length, and have
apparent consensus solutions proposed and written up.  In fact, the
progress within the past month has been impressive.  Yet, to address these
issues, the underlying protocol specification operation has changed within
the last call and I do not believe the document is without error.  The lack
of reference implementation or analysis, in simulation or otherwise,
reinforces this concern.

Despite these flaws, I continue to believe AODVv2 is better specified in
many ways than AODV, as it acknowledges and attempts to solve issues AODV
does not even mention such as: multiple interfaces (beyond a passing
sentence), designed with security in mind, extendable with the use of
RFC5444, metric based routing built in, gateway support (although limited),
bi-directional link checking.  There is value in this draft and it is my
hope that it can be published in some form. I am personally willing to help
make that happen.

To the editors who worked so hard, you were given an impossible task: to
address WG concerns, form consensus and provide verifiable fixes within the
timeframe provided.  When issuing the last call and doing my review I was
not sure that it was impossible, and held out hope until the very moment of
this decision that it wasn’t.  I am sorry that I was mistaken.

The amount of work produced in the last month has been impressive but at
this time I’m not willing to pass it out of the working group.

Justin

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 5 May 2016 08:57:09 +0200

Hi Justin, and All,

I think the main reason of AODVv2 delay or WG long-argument, is due to the
design of packet before designing the protocol. I was against designing the
packet before the protocol but the WG continued. It worked for OLSRv2
because the authors of rfc5444 are authoring that proactive-protocol and
that the both designs worked in parallel for that protocol completion, but
AODVv2 did not work in parallel, and part of the WG argued to follow the
packet design. However, I will suggest that the draft of using the rfc5444
should not go and leave it after recharter, because there are many issues
not discussed/agreed in using rfc5444 for reactive protocols.

AB

On Thu, May 5, 2016 at 5:49 AM, Justin Dean <[email-masked]> wrote:

> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 6 May 2016 13:35:18 +0100

Hi Justin,
 
I have been largely outside MANET since stepping down as AD, but I want to thank you for the clarity of this decision and the time I know you have put in to making it the right decision.
 
As you say, the team working on AODVv2, and Charlie in particular, cannot be faulted for the long hours of technical work they have put in over the years. The challenge was formidable, and the support in the working group somewhat light. And I agree with you that AODVv2 as it stands is a big step forward from AODV. 
 
I don't see the current situation as a failure and I would urge the authors to discuss with the AD how best to convert this work into an RFC (perhaps as an Experimental document that is AD sponsored or published through the ISE). That would represent a stake in the ground and a reference point for future work. It would also allow everyone (WG and authors) to move on.
 
Again, Justin, thanks for your leadership.
 
Adrian
 
From: manet [mailto:[email-masked]] On Behalf Of Justin Dean
Sent: 05 May 2016 04:49
To: [email-masked]
Subject: [manet] AODVv2 Decision
 
Working Group,

I will not be passing AODVv2 out of the working group and to the IESG.  This was not an easy decision, nor one made lightly. However, despite many attempts to draft this email otherwise, I found I could not justify AODVv2’s release. AODVv2 is released to the document editors. The following is the rationale for my decision.

There is insufficient consensus within MANET to make the passage appropriate.  More importantly, perhaps, is that this lack of consensus is justified by the significance of the outstanding issues.  These issues include: security, metrics, multiple interface operation with shared ip addresses, possible looping, non-symmetric links, ordering of processing operations, lack of jitter specification, removal of timeouts, and gateway limitations.  Many of these issues have been discussed at length, and have apparent consensus solutions proposed and written up.  In fact, the progress within the past month has been impressive.  Yet, to address these issues, the underlying protocol specification operation has changed within the last call and I do not believe the document is without error.  The lack of reference implementation or analysis, in simulation or otherwise, reinforces this concern.  

Despite these flaws, I continue to believe AODVv2 is better specified in many ways than AODV, as it acknowledges and attempts to solve issues AODV does not even mention such as: multiple interfaces (beyond a passing sentence), designed with security in mind, extendable with the use of RFC5444, metric based routing built in, gateway support (although limited), bi-directional link checking.  There is value in this draft and it is my hope that it can be published in some form. I am personally willing to help make that happen.

To the editors who worked so hard, you were given an impossible task: to address WG concerns, form consensus and provide verifiable fixes within the timeframe provided.  When issuing the last call and doing my review I was not sure that it was impossible, and held out hope until the very moment of this decision that it wasn’t.  I am sorry that I was mistaken.

The amount of work produced in the last month has been impressive but at this time I’m not willing to pass it out of the working group.

Justin

---

From: [email-masked]
Date: Fri, 6 May 2016 19:03:21 +0200

Adrian,

I cannot let you get away with saying that there "the support in the working group [has been] somewhat light” — that's simply not true, given the numerous, frequent, detailed, massive, and constructive reviews that have been offered over the years by Ulrich, Jiazi, Chris, Justin, and others (including myself).

These reviews largely have gone unanswered by the authors for months, years, even decades at length — for which you can fault the authors, or the WG chairs (and the rest of the leadership) for not holding the authors feet to the fire.

…but you do not get to pass blame off to the WG here. As Mr. Dean has reported, the work on this specification has largely happened outside, and detached from, the WG.

Best,

Thomas

> On 06 May 2016, at 14:35, Adrian Farrel <[email-masked]> wrote:
> 
> Hi Justin,
>

---

From: Abdussalam Baryun <[email-masked]>
Date: Sun, 8 May 2016 12:08:58 +0200

Hi Adrian,

Thanks for your suggestion, I support that this work needs to be used in
IETF as RFC, because the authors can take it to another standard
organisation but I think it is better if they complete it with IETF.
However, it is the authors decision that I hope they submit on this list so
we can know the direction or we can follow up.

AB

On Fri, May 6, 2016 at 2:35 PM, Adrian Farrel <[email-masked]> wrote:

> Hi Justin,
>
>
>
> I have been largely outside MANET since stepping down as AD, but I want to
> thank you for the clarity of this decision and the time I know you have put
> in to making it the right decision.
>
>
>
> As you say, the team working on AODVv2, and Charlie in particular, cannot
> be faulted for the long hours of technical work they have put in over the
> years. The challenge was formidable, and the support in the working group
> somewhat light. And I agree with you that AODVv2 as it stands is a big step
> forward from AODV.
>
>
>
> I don't see the current situation as a failure and I would urge the
> authors to discuss with the AD how best to convert this work into an RFC
> (perhaps as an Experimental document that is AD sponsored or published
> through the ISE). That would represent a stake in the ground and a
> reference point for future work. It would also allow everyone (WG and
> authors) to move on.
>
>
>
> *From:* manet [mailto:[email-masked]] *On Behalf Of *Justin Dean
> *Sent:* 05 May 2016 04:49
> *To:* [email-masked]
> *Subject:* [manet] AODVv2 Decision
>
>
>
> Working Group,
>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 9 May 2016 10:46:06 +0000

I am of the view that this underestimates the WG contribution, and also that of the more recent members of the AODVv2 team, who I think really helped push it from definitely unpublishable to getting there (Experimental), but not there yet. But I’m not going to dig into what should or should not have happened.

More importantly, going forward, I think that a bad approach to there being a good specification of a reactive routing protocol as an RFC would be if  the AODVv2 authors (current or modified group) decided that AODvv2 should be that protocol but that they no longer needed - or just no longer got - the inputs that others (up to now, through the WG) have provided, especially recently. There’s no suggestion been made that I’ve seen that this is the plan, but without the WG as a structure for that, I’m not sure how outside input should/will happen. I note that detailed comments from Justin, Thomas, Ulrich and Jiazi, and some observations from others (including me) are largely focussed on the same areas, which Justin highlighted in his recent decision.

On AODVv2 being an advance on AODV, a summary of the improvements wouldn’t go amiss, presented somewhere.

--
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
__________________________________________________________________________

T:  +44 (0)1245 242194  |  E: [email-masked]<mailto:[email-masked]>

BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai<http://www.baesystems.com/ai>
BAE Systems Applied Intelligence Limited
Registered in England & Wales No: 01337451
Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP

From: manet [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: 06 May 2016 13:35
To: 'Justin Dean'
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [manet] AODVv2 Decision

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.

*** WARNING ***
This message originates from outside our organisation, either from an external partner or the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
For information regarding Red Flags that you can look out for in emails you receive, click here<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.
If you feel the email is suspicious, please follow this process<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.
Hi Justin,

Adrian

From: manet [mailto:[email-masked]] On Behalf Of Justin Dean
Sent: 05 May 2016 04:49
To: [email-masked]<mailto:[email-masked]>
Subject: [manet] AODVv2 Decision

Working Group,

Justin
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************