Hi John,
again, apologies for not answering sooner.
Am 04.04.2016 um 22:34 schrieb John Dowdell <john.dowdell486@xxxxxxxxx>:
Yes, post to show progress :)
OK looking at some TODOs now
1. The ones in the definitions; is it worth linking from the definition to
where the explanatory text is?
2. Applicability statement. Sigh. Wireless networks. We discussed keeping
that rabbit hole shut, and I’d rather not open it again. Yes it is very
likely that AODVv2 will be used on wireless networks, but given that a very
high proportion of mesh and point to point wireless networks operate some
proprietary or closed standard protocol (apart from the usual 802.11 and .15
ones), I’d really rather not get into a protracted discussion of what could
and could not be done here.
3. Page 9: yes there is an issue with hop-by-hop trust. Correct. Does anyone
know how to fix that yet? No. We kicked it around again in DTN this morning
and still no nearer a workable solution. IMO best left as an exercise for the
reader, or text to that effect. If I was building such a network today, I
would probably pre-load key material into each node with a lifetime of the
mission plus a bit, maybe with a spare set of keys in case of compromise. In
the future when technology has moved on to be able to properly negotiate
trust without reference to a central PKI server, I would do something fancier.
4. Page 17, maximum single hop metric value. The current IETF favourite
appears to be two bytes worth, think this is the same in DLEP (Stan can you
confirm please?). Can we go with that?
5. RREP_Ack timeout. I’d expect to get an Ack back pretty quickly since it’s
only coming from one hop away. Is there a short time value we can re-use from
somewhere else in this spec?
6. Check RREP_Ack in MRMT. Why isn’t this the right place, thought this wasHe’s asking the following to be removed:
now the working space for routes before they go live into the kernel?
7. (What does this mean? How would one determine a link to a neighbor to be
broken….suggest removing it JWD TODO) need some clarification. We do discuss
how to detect links are broken, and what is it that he is asking to be
removed?
8. Page 24 sect 6.6 the table for waiting routes is the MRMT, is it not?
That’s all for now. Lotte, you are owed a very significant number of beers.
Cheers
John
On 4 Apr 2016, at 20:59, Ratliff, Stanley <sratliff@xxxxxxxxxxx> wrote:
Go!
Regards,
Stan
Sent from my iPhone
On Apr 4, 2016, at 4:56 PM, Lotte Steenbrink
<lotte.steenbrink@xxxxxxxxxxxx<mailto:lotte.steenbrink@xxxxxxxxxxxx>> wrote:
Hi all,
since we're allowed to submit Drafts again now (I think) and we decided to
publish asap, I thought I'd give you a quick status update and wait for your
Go/"Wait a minute, let's fix this first" signals.
DONE:
----
* All JWD!s are resolved now
* out of 90 JWD and JWD! comments, 64 are done (I've attached my copy of
Justin's review if you want to look for the remaining 26 TODOs, it's the
file called "draft-ietf-manet-aodvv2-13 (2).txt")
* added revised security considerations
TO DO:
----
* Most notable of the 26 JWDs that are yet to be resolved:
+ (is there some table that lists routes that are being waited on? JWD) We
decided to add a separate
RREP table that lists them and I've volunteered to write text for
that, but every time I set out to do that,
I got more confused... I'm starting to worry about the amount of
tables AODVv2 needs by now, and
I've been picking Vickys brain on how to achieve storing that info
without having to add another table,
but it's an ongoing process.
+ the approaching the limit thing we're currently discussing in
"[aodvv2-discuss] Re: Justin's review"
* some TODOs in security considerations (see github)
* still waiting for Chris' feedback regarding the revised 5444 multiplexer
wording, so that hasn't changed yet
* Make it more clear that AODVv2 currently doesn't support RREQs for
prefixes to make Thomas happy (I'm planning to do that tomorrow afternoon)
What do you think?
Regards,
Lotte
<draft-ietf-manet-aodvv2-13 (2).txt>
<draft-ietf-manet-aodvv2-14d-from-c.diff.html>
<draft-ietf-manet-aodvv2-14d.txt>
_____________________________________________________
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.
_____________________________________________________
