Subject: Re: [manet] Fwd: New Version Notification for draft-clausen-manet-rfc5444-usage-00.txt

From: John Dowdell <[email-masked]>
Date: Mon, 01 Jun 2015 11:28:35 +0100

Ulrich and team

Many thanks for producing this. The AODVv2 team will be taking a close 
look, and I for one will be supporting WG adoption.

Best regards
John

On 31/05/15 12:33, Ulrich Herberg wrote:
> As we announced previously, we have been working on a document 
> specifying rules for how to use RFC5444 in MANET protocols. Well, here 
> it is (at least in a -00 version).
> We'd appreciate reviews and will soon ask for WG adoption.
>
> Best regards
> Ulrich
>
> Begin forwarded message:
>
>> *From:* [email-masked] <mailto:[email-masked]>
>> *Date:* May 28, 2015 at 11:12:35 GMT+3
>> *To:* "Christopher Dearlove" <[email-masked] 
>> <mailto:[email-masked]>>, "Henning Rogge" 
>> <[email-masked] 
>> <mailto:[email-masked]>>, "Thomas Clausen" 
>> <[email-masked] <mailto:[email-masked]>>, "Henning 
>> Rogge" <[email-masked] 
>> <mailto:[email-masked]>>, "Ulrich Herberg" 
>> <[email-masked] <mailto:[email-masked]>>, "Thomas H. 
>> Clausen" <[email-masked] <mailto:[email-masked]>>, 
>> "Christopher Dearlove" <[email-masked] 
>> <mailto:[email-masked]>>, "Ulrich Herberg" 
>> <[email-masked] <mailto:[email-masked]>>
>> *Subject:* *New Version Notification for 
>> draft-clausen-manet-rfc5444-usage-00.txt*
>>
>>
>> A new version of I-D, draft-clausen-manet-rfc5444-usage-00.txt
>> has been successfully submitted by Thomas Clausen and posted to the
>> IETF repository.
>>
>> Name:        draft-clausen-manet-rfc5444-usage
>> Revision:    00
>> Title:        Rules For Designing Protocols Using the RFC5444 
>> Generalized Packet/ Message Format
>> Document date:    2015-05-28
>> Group:        Individual Submission
>> Pages:        17
>> URL: 
>> https://www.ietf.org/internet-drafts/draft-clausen-manet-rfc5444-usage-00.txt
>> Status: 
>> https://datatracker.ietf.org/doc/draft-clausen-manet-rfc5444-usage/
>> Htmlized: 
>> https://tools.ietf.org/html/draft-clausen-manet-rfc5444-usage-00
>>
>>
>> Abstract:
>>   This document updates the generalized MANET packet/message format,
>>   specified in RFC5444, by providing prescriptive guidelines for how
>>   protocols can use that packet/message format.  In particular, these
>>   mandatory guidelines prohibit a number of uses of RFC5444 that have
>>   been suggested in various proposals, and which would have lead to
>>   interoperability problems, to impediment of protocol extension
>>   development, and to inability to use generic RFC5444 parsers.
>>
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of 
>> submission
>> until the htmlized version and diff are available at tools.ietf.org 
>> <http://tools.ietf.org>.
>>
>> The IETF Secretariat
>>
>
>
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: Lotte Steenbrink <[email-masked]>
Date: Tue, 9 Jun 2015 16:26:04 +0200

Hi Ulrich, Thomas, Chris and Henning,

Am 31.05.2015 um 13:33 schrieb Ulrich Herberg <[email-masked]>:

> As we announced previously, we have been working on a document specifying rules for how to use RFC5444 in MANET protocols. Well, here it is (at least in a -00 version). 

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 view (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 this list, 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
     |    |    `-------------------
     |    `-------------------
     `------------------

> 
> Best regards
> Ulrich 
> 
> Begin forwarded message:
> 
>> From: [email-masked]
>> Date: May 28, 2015 at 11:12:35 GMT+3
>> To: "Christopher Dearlove" <[email-masked]>, "Henning Rogge" <[email-masked]>, "Thomas Clausen" <[email-masked]>, "Henning Rogge" <[email-masked]>, "Ulrich Herberg" <[email-masked]>, "Thomas H. Clausen" <[email-masked]>, "Christopher Dearlove" <[email-masked]>, "Ulrich Herberg" <[email-masked]>
>> Subject: New Version Notification for draft-clausen-manet-rfc5444-usage-00.txt
>> 
>> 
>> Title:        Rules For Designing Protocols Using the RFC5444 Generalized Packet/ Message Format
>> URL:            https://www.ietf.org/internet-drafts/draft-clausen-manet-rfc5444-usage-00.txt
>> Status:         https://datatracker.ietf.org/doc/draft-clausen-manet-rfc5444-usage/
>> Htmlized:       https://tools.ietf.org/html/draft-clausen-manet-rfc5444-usage-00
>> 
>> 
>> Abstract:
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>> 
>> The IETF Secretariat
>>

---

From: Henning Rogge <[email-masked]>
Date: Tue, 9 Jun 2015 17:00:23 +0200

On Tue, Jun 9, 2015 at 4:26 PM, Lotte Steenbrink
<[email-masked]> wrote:
>      (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”?

Every parser for RFC5444 should be able to parse everything decribed
in RFC5444. So you are free to implement any kind of address
compression strategy...

Address compression can be split into only two questions:
- what is the best order for the addresses for compression
- how do you split them into address blocks

The combination of these two choices will force the distribution of
addressblock-tlvs, because you have to keep the same mapping between
addresses and the attached TLV and their values.

That is (among other things) why demanding a special order of
addresses (or a special split of address blocks) is a BAD idea for a
protocol. It might prevent you from doing a good address compression.

Henning Rogge

---

From: Christopher Dearlove <[email-masked]>
Date: Tue, 9 Jun 2015 16:42:07 +0100

Not sure what went wrong there. I was saying I just saw constructive criticism, always appropriate, but as I'm recuperating from (successful, relatively minor) surgery I'll let my co-authors address this first.

(Except examples are as they are as it's much better/easier to base on RFCs than IDs.)

--  
Christopher Dearlove
[email-masked] (iPhone)
[email-masked] (home)

> On 9 Jun 2015, at 15:50, Christopher Dearlove <[email-masked]> wrote:
> 
>

---

From: Henning Rogge <[email-masked]>
Date: Wed, 10 Jun 2015 07:51:25 +0200

> protocol. It might prevent you from doing a good address compression.

But I will have a look at the address compression section, I think we
can still improve it.

Henning Rogge