[aodvv2-discuss] Re: Draft 13e

  • From: Charlie Perkins <charles.perkins@xxxxxxxxxxxxx>
  • To: aodvv2-discuss@xxxxxxxxxxxxx
  • Date: Mon, 30 Nov 2015 18:16:06 -0800

Hello folk,

I have just finished two pressing, urgent matters. I will make this review either tonight or tomorrow. Thanks for your patience!

I would appreciated any comments about the RFC 6621 considerations draft (like, should I publish it?) and the cost metric for received signal strength.

Also, I did suggest a proper resolution to the MTU issue by adding an informative sentence to the RFC 5444 considerations section...

Regards,
Charlie P.

On 11/30/2015 2:30 PM, Victoria Mercieca wrote:


Just a small note to add, there was a 13f with some minor changes (I attached a diff when I sent it). Didn't want that to get lost since this thread is for 13e.

Vicky.

On 30 Nov 2015 10:22 pm, "John Dowdell" <john.dowdell486@xxxxxxxxx <mailto:john.dowdell486@xxxxxxxxx>> wrote:

Hi Charlie

Just wondering if you are finished cogitating about the main draft
and if you are happy for us to go to print and request WGLC? I
know there are still one or two outstanding questions from the
usual suspects but we could be here for ever debating them, and
that would stall the whole manet group.

Thanks
John

On 26 Nov 2015, at 09:38, Victoria Mercieca <vmercieca0@xxxxxxxxx
<mailto:vmercieca0@xxxxxxxxx>> wrote:

Same, I gave it the proofread I wanted to, it's time!!

Vicky.

On Thu, Nov 26, 2015 at 9:38 AM, Lotte Steenbrink
<lsteen@xxxxxxxxxxxxxxxxxx <mailto:lsteen@xxxxxxxxxxxxxxxxxx>> wrote:

> John,
>
> No issues here. Let's ask for WGLC.

+1 :)

Regards,
Lotte

>
> Regards,
> Stan
>
>
>> -----Original Message-----
>> From: aodvv2-discuss-bounce@xxxxxxxxxxxxx
<mailto:aodvv2-discuss-bounce@xxxxxxxxxxxxx>
[mailto:aodvv2-discuss- <mailto:aodvv2-discuss->
>> bounce@xxxxxxxxxxxxx <mailto:bounce@xxxxxxxxxxxxx>] On
Behalf Of John Dowdell
>> Sent: Tuesday, November 24, 2015 3:41 PM
>> To: AODVv2 Discuss <aodvv2-discuss@xxxxxxxxxxxxx
<mailto: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 <mailto:lsteen@xxxxxxxxxxxxxxxxxx>>
>> wrote:
>> >
>> > 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
>> different.
>> > We've specified which parts of a RERR MUST be present in
every RERR,
>> > and that should be enough information for the
implementing person,
>> > should they decide to specify any kind of sophisticated
splitting *to
>> their
>> API*.
>> >
>> > 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.
>> >>
>> >
>> >
>> >
>>
>>
>
>
> _____________________________________________________
> This electronic message and any files transmitted with it
contains
> information from iDirect, which may be privileged, proprietary
> and/or confidential. It is intended solely for the use of
the individual
> or entity to whom they are addressed. If you are not the
original
> recipient or the person responsible for delivering the
email to the
> intended recipient, be advised that you have received this
email
> in error, and that any use, dissemination, forwarding,
printing, or
> copying of this email is strictly prohibited. If you
received this email
> in error, please delete it and immediately notify the sender.
> _____________________________________________________
>






Other related posts: