Hi Lotte,
Thanks for getting back to me!
On Thu, Apr 16, 2015 at 2:58 PM, Lotte Steenbrink <
lotte.steenbrink@xxxxxxxxxxxx> wrote:
Hi Vicky, hi all,
Am 14.04.2015 um 19:42 schrieb Victoria Mercieca <vmercieca0@xxxxxxxxx>:
Hi all,
While going through the draft I've come up with a load of questions and
notes. Addressing these will make the draft more complete and resolve some
of the ambiguity which might affect an implementation.
I'm going to divide these into a number of emails so that it should be
easier to follow each discussion, and you can pick and choose which to look
at if you dont have much time!
This email is the miscellaneous comments.
1. Buffering - we state that there are positive and negative effects -
should we make this statement if we aren't going to explain it? We already
had one comment about this from Chris Dearlove
Ack. Do you think it makes more sense to add a short explanation, or to
remove the sentence “Buffering of data packets can have both positive
and negative effects (albeit usually positive).”?
1. For RREQ, in the text we say 'set metric = Route[OrigAddr].Metric'.
In the Appendix we say 'set to zero by default, or MIN_METRIC[MetricType]'.
Should we change one, or the other, or explain that Route[OrigAddr].Metric
is in fact zero or MIN_METRIC, since the OrigAddr is on one of the router's
interfaces? Same for TargAddr in RREP.
I'm a bit confused here– MIN_METRIC doesn't seem to be defined anywhere in
the draft. If we use it in the pseudocode, I think it should be noted what
it means.
1. The Route.Timed flag - this seems a bit redundant. If a route isIf MAXTIME is the maximum expressible clock time, I think that no
not timed, its expiration time is MAX_TIME, so cant we use
route.ExpirationTime != MAX_TIME to check if the route is timed?
If I understand it correctly, the draft doesn't prevent one from
specifying a ValidityTime bigger than MAX_TIME, does it? If so, that would
make this check fail...
Also, I noticed that Timed is sometimes written as “timed” in your current
version... I'm not sure if that's on purpose?
1. Should MessageType be part of each message when we draw the
diagrams? Its a RFC 5444 message header field, like hop count and hop
limit, which we do show in the diagram.
Are you referring to the message structure diagrams which can be found in
sections such as 7.1. Route Request (RREQ) Message? If so, I wouldn't make
this decision based on RFC 5444, because afaik these diagrams are not
supposed to be coupled to 5444, iirc... Still, I think that's a good idea,
in case somebody uses these diagrams as sort of a “check list”. But we'd
also have to add the Message Type to the Data Types explanations below,
right?
1. Should we use ":=" or just "="?
Imo := is clearer.
1. Should we use CurrentTime or Current_Time. Most of our values use
ThisNotation rather than This_Notation.
Good catch. I think CurrentTime fits better. Speaking of snake_case, what
about RREP_Gen and RREQ_Gen?
1. Can we rename OrigAddrMetric and TargAddrMetric to OrigMetric and
TargMetric to simplify a little? We already renamed OrigAddrSeqNum and
TargAddrSeqNum to OrigSeqNum and TargSeqNum.
2. Can we try to avoid using "List" when there's only one thing in it?
PrefixLengthList, SeqNumList, MetricList, ValidityTimeList in RREQ and
RREP. Lotte's notation might be useful to try to work in (e.g. add this
address with these TLVs, next address with these TLVs) - definitely needs
some thought.
I agree with the one-element List thing. If we want to keep the generic
AODVv2 message notation separated from RFC 5444, I'd be careful to add any
relationship-style notation (other than in section 10.. I'm working on it!
;)), but I'm sure we'll find a nice notation nonetheless. if you want to
bounce ideas back and forth, let me know! :)
1. RERR for broken link - I haven't yet changed anything about each
metric type requiring a separate message. If anyone has suggestions then I
welcome them.
2. RFC5444 section - not yet updated the layout to reflect Lotte's
recent email.
My fault.. I had another (very long) Hangout with Henning on tuesday and
I'm currently busy putting together the table layout we came up with and
translating all my notes into a readable form (and double-checking if you
already fixed the things we found :)). I'll get back to you by the end of
this week.
Fantastic, looking forward to it!
Lotte
1. Security section
1. Changes to the security section will impact the Overview and the
Applicability sections (and maybe more). We need to be careful that we
dont
end up with any conflicting statements.
2. Contemplating moving this section to flow nicely from the rest
of the text - before the IANA section and maybe before the
"configuration
parameters" section, maybe even before Optional Features? Any
objections?
2. Appendices
1. Considering renaming "Features of IP needed by AODVv2" to "Features
Required of IP" - any objections?
2. Considering renaming "Shifting Network Prefix Advertisement
Between AODVv2 Routers" to "Router Client Mobility" - any objections?
3. Did we reach a decision on Addresses without TLVs attached? Lotte's
conversation with Henning pointed out that we should not identify an
Address by the lack of a certain TLV associated with it. So should we
always add both OrigSeqNum TLV and TargSeqNum TLV in all RteMsgs? When we
put TargSeqNum TLV in in RREQ we can give it no value to save on a little
bit of message length.
That's all for now, I'll get some more out tomorrow.
Regards,
Vicky.
