John,
No issues here. Let's ask for WGLC.
Regards,
Stan
-----Original Message-----
From: aodvv2-discuss-bounce@xxxxxxxxxxxxx [mailto:aodvv2-discuss-
bounce@xxxxxxxxxxxxx] On Behalf Of John Dowdell
Sent: Tuesday, November 24, 2015 3:41 PM
To: AODVv2 Discuss <aodvv2-discuss@xxxxxxxxxxxxx>
Subject: [aodvv2-discuss] Re: Draft 13e
Ladies and Gents
I’d like to take the feel of us all here and ask if we have any outstanding
worries now that urgently need to be resolved.
We have a reason to want to move forwards, publish the draft and ask for
WGLC. The reason (as Alvaro said to me in Yokohama when I asked him why
manet was not meeting) is that the passing of AODVv2 and DLEP through
WGLC and into the IESG is blocking any further business in the manet group.
I’d like to get at least one of those and preferably both done real soon, but
this list is about only one, so let’s not concern ourselves with DLEP here.
Therefore if we’re all comfortable with what we have now, its publish time
again.
If not, please state below, briefly in one bullet per issue, what you are not
comfortable with, and I’ll split that out into one issue per email thread so
we
can discuss the issue fully and get things to consensus. No big explanations
please, save that for the other threads, if you have things that really won’t
wait until last call.
Best regards
John
On 24 Nov 2015, at 13:06, Lotte Steenbrink <lsteen@xxxxxxxxxxxxxxxxxx>wrote:
different.
Hi all,
following up on the MTU discussion: I just talked to Henning and he
confirmed our assumptions. AODVv2 should not be concerned with the
MTU, and the RFC5444 packet creator will fragment any messages that
are too big. They way in which this fragmentation is conducted is up
to the
RFC5444 implementation:
It might take an educated guess and keep the message TLVs in all
message fragments, spreading out obnly the addresses across several
messages, or it might let the protocol constructing the message
specify which TLVs
*must* be kept in every fragment, should the message be fragmented
(which is what Henning's oonf API does), or something completely
We've specified which parts of a RERR MUST be present in every RERR,API*.
and that should be enough information for the implementing person,
should they decide to specify any kind of sophisticated splitting *to their
Thanks for making this change Vicky :)
Regards,
Lotte
Hi all,
Made a little mistake in the last one, in that I hadnt completely
removed all the MTU stuff!
Vicky.