Hi Vicky, hi all,
Am 14.04.2015 um 19:42 schrieb Victoria Mercieca <vmercieca0@xxxxxxxxx>:
Hi all,Ack. Do you think it makes more sense to add a short explanation, or to remove
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.
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
For RREQ, in the text we say 'set metric = Route[OrigAddr].Metric'. In theI'm a bit confused here– MIN_METRIC doesn't seem to be defined anywhere 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.
The Route.Timed flag - this seems a bit redundant. If a route is not timed,If I understand it correctly, the draft doesn't prevent one from specifying a
its expiration time is MAX_TIME, so cant we use route.ExpirationTime !=
MAX_TIME to check if the route is timed?
Should MessageType be part of each message when we draw the diagrams? Its aAre you referring to the message structure diagrams which can be found in
RFC 5444 message header field, like hop count and hop limit, which we do show
in the diagram.
Should we use ":=" or just "="?Imo := is clearer.
Should we use CurrentTime or Current_Time. Most of our values useGood catch. I think CurrentTime fits better. Speaking of snake_case, what about
ThisNotation rather than This_Notation.
Can we rename OrigAddrMetric and TargAddrMetric to OrigMetric and TargMetricI agree with the one-element List thing. If we want to keep the generic AODVv2
to simplify a little? We already renamed OrigAddrSeqNum and TargAddrSeqNum to
OrigSeqNum and TargSeqNum.
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.
RERR for broken link - I haven't yet changed anything about each metric typeMy fault.. I had another (very long) Hangout with Henning on tuesday and I'm
requiring a separate message. If anyone has suggestions then I welcome them.
RFC5444 section - not yet updated the layout to reflect Lotte's recent email.
Security section
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.
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?
Appendices
Considering renaming "Features of IP needed by AODVv2" to "Features Required
of IP" - any objections?
Considering renaming "Shifting Network Prefix Advertisement Between AODVv2
Routers" to "Router Client Mobility" - any objections?
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.
