[aodvv2-discuss] Re: Follow-up #2 for proposals made in December
- From: Lotte Steenbrink <lotte.steenbrink@xxxxxxxxxxxx>
- To: aodvv2-discuss@xxxxxxxxxxxxx
- Date: Thu, 22 Jan 2015 11:43:26 +0100
Hi all,
Am 22.01.2015 um 00:09 schrieb Charlie Perkins <charles.perkins@xxxxxxxxxxxxx>:
>
>
> 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?
Sounds good to me.
>
> ============================================================
>
> [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?
Yes, please! :)
>
>
> ============================================================
>
> [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: