Charlie,
I'm going to have to pick through these one at a time. For now, for no
particular reason, I've descended on Issue #35:
IMO (FWIW): Closing this as "won't fix" is going to be seen as
counter-productive. In looking at the email trail, I think this is a
classic example of a pile of "poo" thrown at the wall to incite a riot
- but a pile of "poo" that actually has a point worth further
exploration (and maybe some additional text). Specifically, I think
the point worth discussing is expressed in the following snippet of
email text:
"...interesting part here is actually not that bit [the bit that
constants are constants]...but rather, what happens *if* these are not
set to the values that are indicated? Or, if different implementations
use different values for these?"
That last question - what happens if, for some odd reason, competing
implementations of AODVv2 use *different* values for the listed
protocol constants? Like some of the other people on the list, I
assume these will be implemented at compile time (say, via #define
statements). But what if I decide that I don't like, or have a better
idea, for one of those "default values" you list? Can my
implementation still interoperate with yours? I think that's actually
a reasonable question.
regards,
Stan
On Wed, Dec 31, 2014 at 10:54 AM, Charlie Perkins
<charles.perkins@xxxxxxxxxxxxx <mailto:charles.perkins@xxxxxxxxxxxxx>>
wrote:
Hello folks,
Here are some proposed resolutions for AODVv2 open issues.
Let's have another teleconference as soon as people are back from
holiday revelry.
============================================================
[manet] #2: Terminology for reactive protocol document
I propose to close this issue with a request for more specific
comments
about particular terms or definitions.
Alternatively we could request more specific comments but leave the
issue open.
============================================================
[manet] #10: Reporting multiple broken routes whose metric types
are different
The simplest thing to do would be to simply require multiple RERR
messages.
If that's not sufficient, then additional functionality could be
added in the future.
My guess is that metrics for anything other than hop-count would
essentially
trigger unicast RERR messages anyway and there would be little
gain from the
aggregation.
This would mean "rejecting" the proposal suggested in the issue
text, and
closing the issue.
============================================================
[manet] #16: The Reactive Protocol Duplicate Suppression Table
It is quite easy to put RREPs into the duplicate suppression table
as well.
In fact, it should be done for any AODVv2 message regardless of
type, as
best I can tell.
The change is easy, but involves replacing "RREQ" with "AODVv2
message"
in a number of places.
============================================================
[manet] #23 (aodvv2): Format of processing algorithms
Proposal was to await input from Vicky. However, I can also do this.
It needs more eyes than mine, though, regardless of who writes it.
============================================================
[manet] #24 (aodvv2): Ordering of processing instructions
Close the issue after resolving issue #23. Or close it now, with
a request for
people to append relevant comments to issue #23 instead of this issue.
============================================================
[manet] #27 (aodvv2): Processing AckReq
Recent drafts have included the requested clarification.
To avoid repeated failure of Route Discovery, an AODVv2 router
(HandlingRtr) handling a RREP message MUST attempt to verify
connectivity towards RREQ_Gen. This MAY be done by including the
Acknowledgement Request (AckReq) data element in the RREP. In
reply
to an AckReq, an RREP_ACK message message MUST be sent.
With this clarification, the issue may reasonably be considered to
be resolved.
I updated the issue tracker with the above text, but did not yet
close the
issue. I propose to go ahead and close the issue after a week or
two have
gone by, but leave it open for now in case anyone has more comments.
============================================================
[manet] #30 (aodvv2): Use of word "node"
I updated the issue tracker with the discussion from various people.
This is mainly an idiotic issue. I have refrained from comment
because
I just get so aggravated.
For example, RFC 4294. Anyone who claims that "node" is mysterious
terminology is either unqualified to be in the IETF or else just
being a
(well, the proper word does not fit in polite email).
I have checked on uses of "node" in the document, and many were
changed
to "addr" instead as noted in previous emails. More specific
terminology
has been used where appropriate.
I think we can close the issue.
============================================================
[manet] #31 (aodvv2): Suitability for implementation on commodity OS
I propose to close this issue contingent upon proper resolution of
issue #46.
============================================================
[manet] #32 (aodvv2): Multicast transmission
I updated the issue tracker with some discussion from Abdussalam.
We should ask Adrian if we can close this issue.
============================================================
[manet] #34 (aodvv2): Section 13 must be removed
I updated the issue tracker with the discussion from Abdussalam.
I propose to review the suggested section and close the issue. But we
should definitely discuss this.
============================================================
[manet] #35 (aodvv2): A constant is constant
I updated the issue tracker but did not yet close the
issue. I propose to go ahead and close the issue after a week or
two have
gone by, but leave it open for now in case anyone has more comments.
This would amount to essentially rejecting the proposed issue
("wontfix").
============================================================
#46 (aodvv2): What is needed from IP and ICMP
Write an appendix with the following text:
AODVv2 needs the following:
* information that IP routes are requested
* information that packets are flowing
* the ability to queue packets.
Tautologically, a reactive protocol reacts when a route is
needed. One might say that a route is requested when an
application tries to send a packet. The fundamental concept of
reactive routing is to avoid creating routes that are not needed,
and the way that has been used to know whether a route is needed
is when an application tries to send a packet.
If an application tries to send a packet, and the route is
available, the packet has to wait until the route is available.
============================================================
