Lotte
Utterly brilliant, thank you. I have a copy of the draft to read on my travels
and will make some comments in a few days.
Regards
John
-----Original Message-----
From: "Lotte Steenbrink" <lotte.steenbrink@xxxxxxxxxxxx>
Sent: 08/06/2015 17:29
To: "aodvv2-discuss@xxxxxxxxxxxxx" <aodvv2-discuss@xxxxxxxxxxxxx>
Subject: [aodvv2-discuss] FYI: 5444 usage (informal) review
Hi all,
just FYI: the following text is the one we talked about earlier today. I'll
sleep another night on it and will probably send it it to the MANET list
tomorrow.
------------------
Hi,
first of all, thank you so much for publishing this much-needed draft. I'm also
in favor of WG adoption. While reading through the document, I wrote down some
nitpicks and suggestions that I'd like to share.
(Just in case my writing sounds harsh, I fear that's due to language/cultural
differences. I'm really happy about this document and would like to see it
flourish.)
== General notes ==
- If I didn’t misunderstand it, the document addresses two groups of people:
Those who want to design RFC5444 messages for their protocol, and those wo want
to implement a RCF 5444 builder/parser. Imo, The former group needs more of an
outside view (i.e. what can/should I put where), while the latter needs the
inside vie (i.e. how do I arrange and process everything efficiently). To my
mind, these are two very different goals, but while reading the document, it
wasn’t always instantly clear to me which bit addresses which group… I realize
the two can’t always be separated completely, but would it be possible to make
it more clear which group is addressed currently? Maybe the document could be
organized into two big sections (one for each group), or there could be a
recurring pattern of “first outside then inside view” for each (sub)section?
- A lot of the examples are very NHDP/OLSR-specific. While I think it’s great
to have pointers to where a certain technique has already been used, from an
outsider’s perspective, the examples don’t always help me understand the
technique that’s being illustrated, since I have to familiarize myself with the
details referenced first… I’m wondering if it would be possible to keep the
examples which illustrate a point more generic, and then briefly point to
existing instances of this situation in case the reader wants to follow up on
that?
== Section by section ==
Section 1.2., Page 4:
“A packet is designed to as travel […]” I think the “as” doesn’t belong
here.
Section 4.2., Page 8:
“Outgoing messages MAY be created by owning protocol” I think there’s a
“the” missing.
Section 4.3., Page 8:
If I understand it correctly, the last paragraph on this page is talking
about multi-value TLVs without actually saying “multi-value TLV”. Maybe that
could be stated explicitly for clarity and in case somebody’s searching for
advice by this keyword?
Section 4.4., Page 9/10:
The last paragraph on page and the first two on page 10, more specifically
these parts:
Such an example already exists (but within the basic specification,
rather
than as an extension) in the use of LOST values in the LINK_STATUS
and OTHER_NEIGHB TLVs to report that an address is of a router known
not to be a neighbor. A future example might be to list an address
to be added to a "blacklist" of addresses not to be used.
This example can be taken further. NHDP must also not reject a HELLO
message because it contains an unrecognized TLV. This also applies
to unrecognized TLV values, where a TLV supports only a limited set
of values.
were a bit hard to read for me. Imho, the example is very specific and
contains details which aren’t necessary to understand the issue at hand (such
as the fact that this extension is technically not a completely independent
extension, or possible future other extensions). It took me about 4 re-reads to
really grasp what’s going on there...
Also, I would’ve expected the last paragraph of this section to clearly
state that relying on address order *will* break your messages if you don’t
have control over all 5444 builders that are used to implement your protocol
ever.
Section 4.5.:
I'm assuming that this is the response to our (the AODVv2 Author team and
possibly others) complaints that RFC5444 lacks a clear "API" which tells it
what we can and cannot set manually in an RFC 5444 packet, and that there's no
(at the risk of sounding really pretentious now) "visual language" to describe
the contents of a 5444 message and their relationship to each other. To be
honest, I'm a bit puzzled by this section.... The mapping that is presented is
a bit vague and introduced very promptly. And while I strongly agree with the
statement that writing down an actual API is too language- and
implementation-specific to belong in a document like this, it would be really
helpful to have a comprehensive "these are the things that your protocol can
set in a RFC5444 message. Your packet builder/parser will figure out the rest."
List in this section rather than some examples.
Along with these lists, it would be great to have a clear specification on how
to specify which Addresses and TLVs a specific message has, and how their
relationship to each other are. (i.e. how to make clear which address TLVs are
associated with which addresses). I don’t care if this ends up being a very
visual approach (like the debugging output of Henning’s oonf API [1]), or the
tables that OLSRv2 uses, or something completely different, but it would be
helpful to be able to read and write messages down in a way that is clear to
everyone.
Section 4.6:
“[…] and MUST NOT remove such TLVs or values”
A question I’ve been wanting to ask for a while now: Does this rule also
apply for message regeneration? AODVv2 regenerates all messages per hop. Should
implementations keep track which unknown TLVs of a message are associated with
which addresses, and put them back in their place when regenerating the message?
Section 6.1.:
(I’m not terribly familiar with compression, so my questions are probably
very naive, but maybe they can help clear things up)
Would this very straightforward to implement compression algorithm still
produce interoperable messages? The rest of the section reads as if the
“compression algorithm” mentioned in the introduction is mainly a way to
cleverly arrange addresses so that they are still understood by all parsers,
but take up a minimal amount of space. I think that’s a very good tip in
itself, but is that really all there is to compression? Would it make sense to
say “Here’s how you should arrange addresses cleverly, you can also implement a
more elaborate compression algorithm, but that’s out of the scope of this
document”?
Also, any mention of the word “straightforward” makes me very suspicious, but
that might just be me.
Section 6.1.:
“RECOMMNDED” in the first paragraph is missing an E.
Regards,
Lotte
[1] Random one pulled out of my logfiles for illustration:
,------------------
| PACKET
|------------------
| * Packet version: 0
| * Packet flags: 0x0
| ,-------------------
| | MESSAGE
| |-------------------
| | * Message type: 11
| | * Message flags: 0x40
| | * Address length: 16
| | * Hop limit: 20
| | ,-------------------
| | | Address: fe80::ff:fe00:1719
| | | | - TLV
| | | | Flags = 0x50
| | | | Type = 0
| | | | Value length: 2
| | | | 0000: 0100
| | `-------------------
| | ,-------------------
| | | Address: fe80::ff:fe00:16fe
| | | | - TLV
| | | | Flags = 0x50
| | | | Type = 1
| | | | Value length: 2
| | | | 0000: 0100
| | | | - TLV
| | | | Flags = 0xd0
| | | | Type = 3; Type ext. = 3
| | | | Value length: 1
| | | | 0000: 00
| | `-------------------
| `-------------------
`------------------
