Subject: [manet] Discussion about whether AODVv2 document editor is "interested" in discussing issues

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 05 Mar 2014 02:49:19 -0800

Hello folks,

Here is the passage referred to in this morning's complaint:

>> A multitude of MANET protocols have been designed to use RFC5444, 
>> including reactive protocols, without any problems.
>>
>> It's extremely easy, even, once one understands RFC5444.
>
> See the above.  If I am challenged to get testimonials to the
> contrary from other people, then I'll have to wait.   I'm not at
> all interested in arguing about it, especially right now!   I will
> at least say that other software developers seem more willing
> to accept feedback.
>

In context, it is clear that I meant that I was not interested in
arguing about whether or not using RFC 5444 was "easy".
Since we are mandated to use RFC 5444, it wasn't (and right
not is still not) very important to argue about whether it is
"easy" to use RFC 5444.

This does not in any way imply that I am uninterested in
discussing issues affecting the AODVv2 specification, and
should never be interpreted that way.

-- 
Regards,
Charlie P.

---

From: Thomas Heide Clausen <[email-masked]>
Date: Wed, 5 Mar 2014 12:17:58 +0100

> On 5 mars 2014, at 11:49, "Charles E. Perkins" <[email-masked]> wrote:
> 
> 
> Hello folks,
> 
>>> A multitude of MANET protocols have been designed to use RFC5444, including reactive protocols, without any problems.
>>> 

Even if that is the case, the fact that the author group has not folded in, or addressed, reviews and comments that have been repeated on the list over and over most certainly can be interpreted in only that way.....

I have reviewed the latest iteration of this specification prior to the London IETF. 

To my disappointment, the issues that I raised during the Maastricht IETF, now many moons ago, and which have been repeated and echoed several times over on the list (by me and others, and even recently) have *still* been neither reflected in the document, nor have they been rebutted by its authors. 

I observe that the same is true for reviews and comments made by others, also.

I note that this was raised as an issue at, at the very least, the two previous IETF meetings, as well as on the list - alas, to no avail.

Respectfully,

Thomas

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 5 Mar 2014 21:23:17 +0100

Hi Charles,

As I suggested in meeting IMHO we get a schedule plan for submission as
long not much clear discussion by the group.

Implementing AODVv2 is not a must (this was discussed before) because
most already practiced its techniques but when tested within the coming two
years it will be better as OLSRv2 taken some years tests after submit.

AB

---

From: Henning Rogge <[email-masked]>
Date: Wed, 5 Mar 2014 20:28:21 +0000

"Implementation is not a most for a standard track document"... that
is an "interesting" point of view.

Henning Rogge

On Wed, Mar 5, 2014 at 8:23 PM, Abdussalam Baryun
<[email-masked]> wrote:
>
> Hi Charles,
>
> As I suggested in meeting IMHO we get a schedule plan for submission as long
> not much clear discussion by the group.
>
> Implementing AODVv2 is not a must (this was discussed before) because most
> already practiced its techniques but when tested within the coming two years
> it will be better as OLSRv2 taken some years tests after submit.
>
> AB
>
>
>
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>

---

From: Thomas Heide Clausen <[email-masked]>
Date: Wed, 5 Mar 2014 21:35:59 +0100

> On 5 mars 2014, at 21:23, Abdussalam Baryun <[email-masked]> wrote:
> 
> 
> Hi Charles,
> 
> As I suggested in meeting IMHO we get a schedule plan for submission as long not much clear discussion by the group. 
> 
> Implementing AODVv2 is not a must (this was discussed before) because most already practiced its techniques but when tested within the coming two years it will be better as OLSRv2 taken some years tests after submit. 
> 

Actually, for OLSRv2, we have had regular interoperability tests since 2004-2005 or so, and (of course) implementations for that long.

Publishing on Standards Track, i.e., prescribing a solution, without having significant experimental and operational experience is, IMO, questionable for an organization to do, and I do very much share the worries of Rick as to the maturity of the current reactive protocol effort.

Thomas

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 5 Mar 2014 22:18:47 +0100

I mean there are implementations and it works, but still under test for new
v2, OLSR and AODV are well known. We don't wait for implementation to
finish then submit for standards as far as I understand standard track ( I
remember once heard that from an AD I think, am I mistaken).

AB

On Wednesday, March 5, 2014, Henning Rogge wrote:

> <[email-masked] <javascript:;>> wrote:
> >
> > Hi Charles,
> >
> most
> > [email-masked] <javascript:;>

---

From: Thomas Heide Clausen <[email-masked]>
Date: Wed, 5 Mar 2014 22:21:55 +0100

> On 5 mars 2014, at 22:18, Abdussalam Baryun <[email-masked]> wrote:
> 
> I mean there are implementations and it works, but still under test for new v2, OLSR and AODV are well known. We don't wait for implementation to finish then submit for standards as far as I understand standard track ( I remember once heard that from an AD I think, am I mistaken). 

Actually, having running code (And, preferably, multiple interoperable implementations) is very very very highly recommended before publishing at std. track.

Actually, I'd submit that *not* having multiple interoperable implementations should be a requirement before std. track publication.

Thomas

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 7 Mar 2014 11:27:52 +0100

Hi Thomas and Henning,

I agree that The point of having standard implementations is very
interesting but not necessary when we have experiment RFC. But we should
not miss important thing Charles decided to do for AODVv2 mentioned in
IETF89 presentation.

 Working on an open source AODVv2 implementation by the standard-author is
very very very most best important, this way the WG and the community can
do more tests and more interoperability in all the world. Usually companies
dislike open sources because competition.

Best,

AB

---

From: Thomas Heide Clausen <[email-masked]>
Date: Fri, 7 Mar 2014 11:34:59 +0100

Dear Abdussalam,

> On 7 mars 2014, at 11:27, Abdussalam Baryun <[email-masked]> wrote:
> 
> Hi Thomas and Henning,
> 
> I agree that The point of having standard implementations is very interesting but not necessary when we have experiment RFC. 

Ah, but IIRC this document intends to be published as Proposed Standard, not as experimental. Hence, the bar is - and should be - a *lot* higher.

> But we should not miss important thing Charles decided to do for AODVv2 mentioned in IETF89 presentation. 
> 
>  Working on an open source AODVv2 implementation by the standard-author is very very very most best important,

At the IETF88, Mr. Perkins informed us that the implementations were undertaken by some students in Germany - and not by himself.

> this way the WG and the community can do more tests and more interoperability in all the world.

In order to be able to do interoperability testing, one needs a stable, unambiguous, complete specification to implement.

> Usually companies dislike open sources because competition. 

Plenty of companies participate in open source projects. 

Heck, as recent as yesterday over lunch, I was talking to two guys from Cisco, spending their entire time developing open source protocol implementations.

Best,

Thomas

---

From: Thomas Heide Clausen <[email-masked]>
Date: Sat, 29 Mar 2014 13:14:09 +0100

Ok now I just read this email, and it reads really weird. Allow me to correct myself...

> On 5 mars 2014, at 22:21, Thomas Heide Clausen <[email-masked]> wrote:
> 
> 

And that is not what I mean, of course.

I of course wanted to say:

> Actually, I'd submit that  *having* multiple interoperable implementations should be a requirement before std. track publication.

Thomas