[aodvv2-discuss] Follow-up #2 for proposals made in December
- From: Charlie Perkins <charles.perkins@xxxxxxxxxxxxx>
- To: aodvv2-discuss@xxxxxxxxxxxxx
- Date: Wed, 21 Jan 2015 15:09:55 -0800
Hello folks,
Here is follow-up on the proposed resolutions for AODVv2 open
issues that generated discussion...
============================================================
[manet] #23 (aodvv2): Format of processing algorithms
Still awaiting input from Vicky. However, I can also do this.
It needs more eyes than mine, though, regardless of who writes it.
If nothing is received by end of January, I will write it.
Help is requested.
============================================================
[manet] #32 (aodvv2): Multicast transmission
Stan proposes:
"Implementations are free to choose their own heuristics for
reducing multicast overhead."
Lotte makes a refined proposal:
"Implementations are free to choose their own heuristics, for
reducing multicast overhead. One example for this is [RFC6621]."
Charlie makes a refined proposal:
"Implementations are free to choose their own heuristics for
reducing multicast overhead. Some methods for doing so are
described in [RFC6621]."
If this is O.K., can I make the change and then suggest closure
on the [manet] mailing list?
============================================================
[manet] #34 (aodvv2): Section 13 must be removed
Lotte says:
------------------------------------------------------------
I don't think we should close this yet. In my opinion, Thomas has a point.
At least Section 13.5 needs to be specified way more clearly (I've tried
to write down my comments about that earlier here: [1]). Its
relationship to AckReq needs to be stated clearly, and, in case AckReq
depend on RREP_ACK (which it seems to, judging from some comments that
surfaced after my review on the ML), I wonder if it should be in the
"optional" section at all.
IMHO, we should only close this issue after we've gone through each
point, have possibly improved it and can argue why it should be kept,
and why it is well specified. However, I'd like to ask Thomas what the
"known problems in common deployment topologies" are exactly.
---------------------------------------------------------------
O.K. Can we do this on Friday?
============================================================
[manet] #35 (aodvv2): A constant is constant
Stan says:
-----------------------------------------------------------
I disagree that John Mullins' comment is sufficient. It's not sufficient
because it does not address the question "What happens if
implementations with *different* values of the constants attempt to
communicate with each other?"
Will this (setting of different values of a constant by different
implementations) work? Or, will it fail? It goes to a statement in the
draft along the lines of "Implementations MUST set the same values of
these protocol constants in order to interoperate."... or
"Implementations SHOULD set the same values of these protocol
constants." Or, "Implementers MAY choose different values of these
constants based on... (phase of the moon, size of the tides, fear of odd
numbers, etc)."
-----------------------------------------------------------
Well, of course we can go into more details. As I mentioned
before, this is pretty far down on my list compared to other
open issues, and of course any help is appreciated. But, for
the meanwhile, we'll leave the issue open.
============================================================
Regards,
Charlie P.
Other related posts:
