Sent from my iPhone
On Apr 4, 2016, at 6:17 PM, Charlie Perkins
<charles.perkins@xxxxxxxxxxxxx<mailto:charles.perkins@xxxxxxxxxxxxx>> wrote:
Hello Lotte,
I'm definitely O.K. with publishing ASAP. Some of the text in my responses
below would be quite simple to include (e.g., about whether RREQ has Message
TLVs...).
A possibly good resolution is better than nothing, unless it is contentious
amongst ourselves, because I am worried that it will look like we aren't able
to make the resolution... and Stan points out that there is a lot of impatience.
So I would ask for people to comment on my proposed resolutions. It's not very
much text.
Regards,
Charlie P.
On 4/4/2016 1:29 PM, Lotte Steenbrink wrote:
Hi Charlie,
Am 04.04.2016 um 22:23 schrieb Charlie Perkins
<charles.perkins@xxxxxxxxxxxxx<mailto:charles.perkins@xxxxxxxxxxxxx>>:
Hello Lotte,
Thanks for getting this ready. For the TODOs, partial resolutions are O.K.,
right? A bit of follow-up...
I think it’s better to fully resolve them in one go :) Also, I don’t think we
have to resolve all of them in order to publish. Let’s get what we have out the
door asap and then tackle the rest. I’ll thoroughly go through your E-Mail
tomorrow, I’ve got to log off now :/
Valid route
A route that can be used for forwarding. (the deleted part should be
defined in Route Error Generation section JWD TODO: why there? If you hink it's
a bit too verbose at that place, Local Route Set {#rte} has an in-depth
definition what a valid route is and isn't )
I'm O.K. with the cross-reference. What else is needed?
Unreachable Address
An address reported in a Route Error message. (the deleted part should be
defined in Route Error Generation section JWD TODO)
Actually, I don't think anything more is really needed. This can be left as is.
(consider adding a maximum single hop value JWD TODO)
This would be a bad idea
Why?
Stan
RREQ_Gen awaits reception of a Route Reply message (RREP) containing
a route toward TargAddr. (is there some table that lists routes that are
being waited on? JWD TODO)
I don't see the need for such a table. If the RREP arrives, the route is good.
Otherwise, the discovery times out and presumably a retry happens up to a
certain limit, after which ICMP Destination Unreachable happens.
(There is no defined behavior here. Approaching the limit? Section 6.5 outlines
which messages are more important but now how to decide to allow them to be
transmitted or not. JWD TODO)
As I understand it, we decided on queueing things, limiting transmission to
{1/CONTROL_TRAFFIC_LIMIT}, and discarding messages when the queue was full. Is
there more to be done?
(this again doesn’t describe a defined behaivor. approaching athe limit? and
6.5 doesn’t disalow anything JWD TODO)
Similarly as the last comment, right?
There might be a problem with very short validity times on very low metric
routes in that they will be selected regardless of the time. Not a problem but
something that could cause issues. Perhaps some minimum time should be
mandated. JWD TODO)
I do not see what issues could be caused. Under some metrics, we absolutely DO
want to pick the smallest metric even if just for long enough to send a few
bytes. This is application dependent, not in the bailiwick of AODVv2.
Unless you would like to start defining a socket interface for dynamic AODVv2
parameterization.
(same as before JWD TODO)
so shouldn't be counted as increasing the total...
(THere needs to be some sort of table which is updated with timer associated
with this AckReq JWD TODO)
What is the current status of this? Has anything been written? Is it
something I should do?
(this ins’t mandatory, right? Just AODVv2 doesn’t define any message TLVs
for use with RREQ JWD TODO?)
"AODVv2 does not define any Message TLVs for an RREQ message"... is this O.K.?
An RREP contains no Message TLVs.
(This isn’t mandatory is it? just none are defined by AODVv2. JWD TODO?)
Similarly, "AODVv2 does not define any Message TLVs for an RREP message"... is
this O.K.?
An RREP_Ack contains no Message TLVs.
(Mandatory or just not defined? JWD TODO?)
Similarly, "AODVv2 does not define any Message TLVs for an RREP_Ack message"...
is this O.K.?
An RREP_Ack contains no Address Block.
(Mandatory or just not defined? Guessing mandatory on this one. JWD TODO)
8.3.4. Address Block TLV Block
An RREP_Ack contains no Address Block TLV Block.
(Mandatory or just not defined? Guessing mandatory on this one. JWD TODO)
Aren't these the same? Isn't the same resolution? Someone could write such a
TLV block in the future.
Regards,
Charlie P.
On 4/4/2016 12:54 PM, Lotte Steenbrink 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
_____________________________________________________
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.
_____________________________________________________
