Re: [manet] Notifications from the IETF tools Issue Tracker

Charlie,

Inline

On Jan 21, 2013, at 4:03 PM, Charles E. Perkins wrote:

On 1/21/2013 12:37 PM, Thomas Heide Clausen wrote:

On 21 janv. 2013, at 18:33, "Charles E. Perkins" <charliep@computer.org<mailto:charliep@computer.org>> wrote:

Hello Ulrich,

First, let's agree that, all other things being equal, position independence
is better than positional dependence.  Then, it's a matter of trading off
that positive feature versus other potential negatives.  In the extreme,
no one would add a kilobyte to the header just to preserve position
independence.

Reductio ad absurdum.

Usually, the phrase "Reductio ad absurdum." is followed by QED.

Next, please observe that Henning has proposed a change to RteMsg
design that offers positional independence.  I hope to write it up today
for evaluation.

Third, we have lots of experience with positional dependent designs
that are extensible -- not related to [manet].  To me this is almost a
no-brainer, but I also know that the RFC 5444 (and, perhaps more
inclusively, the XML) experts have relevant experience.  Using the same
parser is, in my view, not a factor that should determine the outcome
of this design decision.

That is, then, because you have not been in the business of implementing protocols and multi-protocol MANET routers. It is a HUGE benefit to be able to share parsing code, especially given that 5444 is (if used properly) both flexible, efficient to parse and efficient in encoding messages. It also gives you some nice benefits of running multiple protocols jointly (as is the case with NHDP/OLSRv2/SMF) on the same device.

So you'd rather optimize for parser development time over
battery lifetime?   At the beginning of my earlier email, I
referred to "tradeoffs".  I'll stand by that.  I dispute the notion
that one has trouble using multiple other protocols if one also
uses a protocol with positional AddrBlks, and I'd be interested
to see a specific counter-example.

For me, the issue here is that working group consensus seems to have solidified around positional independence. If fact, Charlie, you seem to be the only one holding the counter position. Based on Adrian's email on the way forward, the specification needs to reflect the consensus of the WG. As of right now, that means it (the spec) needs to change.

To the WG participants: If you are holding other views, now is the time to express them.

Fourth, I think there are some noticeable problems with RFC 5444
that need fixing, but I have avoided making that into part of the
discussion about reactive protocols.

Unless you are willing to make the arguments, please don't spread such misinformation.

O.K.  I'll bookmark your challenge and get back to it next month.

Well, this worries me. At a minimum, I'd like to have the opportunity of understanding the issues you allude to. Because at this point, I don't know how to classify - is this in the "minor irritant" category, the "major pain in the backside" column, or the "no way on Earth this will ever work" type? You can't just lob something like this out and then keep on going, without more information for the rest of us.

Regards,
Stan

For now, the task is to make
RFC 5444 serve the purpose which it is mandated to serve.  That has
proved difficult enough.

This is wrong.

Well, Ian spent a lot of time on it but couldn't do it so "easily".
I don't consider myself a beginner, but I find it at minimum tedious
and at worst error-prone.  But -- I'm getting better at it.

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.

--
Regards,
Charlie P.

_______________________________________________
manet mailing list
manet@ietf.org<mailto:manet@ietf.org>
https://www.ietf.org/mailman/listinfo/manet