Hi Charlie,
for some reason I discovered your e-mail only just now, sorry for the late
answer.
Am 22.04.2015 um 03:24 schrieb Charlie Perkins <charles.perkins@xxxxxxxxxxxxx>:
Hello folks,
On 4/21/2015 1:28 PM, Lotte Steenbrink wrote:
Hi all,
so here are most of the remarks that were not directly connected to the 5444
representation but still came up during the April 15 hangout with Henning,
along with some proposals for changes. There are four remarks left that I'll
have to think about some more.
All section numbers are the ones from revision -08.
General stuff
=============
- why is msg_hop_limit decreased with each retransmission? We'd initially
expected it to be a constant which would be used to see if the hop_count of
a message has reached its max (Henning told me that this is the idea of how
5444's <msg_hop_limit> should be used). (I recall being confused by this
during implementation too, but I can't remember how I resolved it...)
Revision -8 has conflicting advices if msg_hop_count is optional, which has
been fixed by Victoria's -9c. I'm assuming that the idea is that if we stop
at msg_hop_limit == 0 rather than comparing msg_hop_limit and msg_hop_count,
we'd save on packet size. Is this correct? And if so, why do we keep
msg_hop_count? If I'm reading the draft correctly, we're never actually
using the value.
I think this is O.K. In the past there was some snarky commentary about it
and I tried
to do what they told me. If the story is different now, that's also fine
with me.
- It puzzled Henning that prefixes are cleanly separated from the addresses
they refer to (since they are put in their own list)
I thought that each prefix was always associated with a particular address.
Otherwise how could it make sense?
The prefix length is supposed to be a part of the Address Block, not a
separate list. See RFC 5444.
- Why does RREP_Ack have a hoplimit? The draft says that it is never
regenerated, and RREP_Acks should never travel farther than one (or should
they?).
They should never be forwarded. They should have TTL=255. Oh well.
Terminology
===========
- the PktSource explanation from Table 1: Data Elements suggests that
PktSource concerns all data packets, while it is only used in RERRs. This is
a bit confusing, especially since it doesn't match up with the PktSource
definition from the Terminology section:
PktSource
The source address of a packet sent to an unreachable address.
I'd suggest removing PktSource from the Terminology section since it seems
to be used as a data element, and update the description in the Data
Elements table with the one that can be found later in “RERR Data Elements”,
namely
The source IP address of the packet triggering a RERR.
This is fine with me. Maybe even:
PktSource
The source address of a packet sent to an unreachable address,
triggering a RERR.
- Router Interface is defined in the terminology section, but never used in
the draft in this wording. Should we remove this empty or change our wording
(in sections 4.1., 4.4., 6.3.)?
Less terminology is fine with me.
- Why is SeqNumList defined in the Terminology section, but AddressList
isn't?
It's fine with me to define AddressList there, even if it seems intuitively
obvious.
- The Type-Length-Value structure (TLV) definition is redundant, since it
has already been defined in RFC 5444, and we're saying “In addition, this
document uses terminology from [RFC5444],”. Can we remove this?
Fine with me.
- ValidityTime seems to be always referred to as a Data Element; yet it has
its own Terminology Entry, too. Could this be removed?
I think it's OK to have the same name for a Data Element and a Terminology
entry, but any simplifications are fine with me.
- why do RREQ_Gen and RREP_Gen have their own terminology entry, but
RERR_Gen doesn't?
Probably because nobody commented about it before :-)
Data elements
=============
- Section 3 explains Data elements without explaining what a Data Element
actually is. Maybe the introductory sentence could be extended to reflect
the fact that these data Elements contain the message data, and ultimately
make up the AODVv2 messages? (I tried, but I fear my english isn't good
enough.)
I'll be happy to wordsmith whatever you have to start with.
- That the Sequence Numbers of broken routes were called “SeqNum” instead of
“ErrorSeqNum” or something similar was the cause of quite some confusion.
I've already mentioned this in an earlier E-Mail (“[aodvv2-discuss] Re:
RFC5444 feedback pt. 1”, 1:28 PM CET):
I don't understand why it's confusing.
I would greatly prefer to keep SeqNumList as a generic
data element as far as is possible. The only reason for the other related
data elements is
because of RFC 5444 constraints, not any naming issue.
The name “SeqNumList” suggests that it is a container for all kinds of
SeqNums, but it is really just for SeqNums in a RERR.
This isn't quite true. It could be the container for SeqNums in any future
extension,
and it
was the container for SeqNums for the Additional Node Address Block back when
we had
that.
The same with “SeqNum” itself: It is not only used as an abbreviation for
“Sequence Number”, but also as the identifier for any Sequence Number in a
RERR. Henning and I struggled with this too; maybe Renaming “SeqNumList” to
“ErrorSeqNumList” and “SeqNum” to “ErrorSeqNum” or something similar could
make the document more clear about this?
I strongly hope to avoid ErrorSeqNum*
Section 9.1.*
=============
- (regarding the explanation in 9.1.) The description of ValidityTimeList
sounds a bit like the sender will refuse to offer a route after
ValidityTime. But isn't it more like “the sender can only guarantee that
they can offer a route for ValidityTime”?
Yes, the latter interpretation is correct.
- RREQ.TargSeqNum seems to be set, but never used. Did we miss something?
It's useful for Intermediate RREP.
Regards,
Charlie P.
