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

[Lotte Steenbrink <[e-mail]>]

Hi all,
I realize vacation season and/or other circumstances have slowed most of us down at one point or another, but I was wondering if one of the authors could give us a very brief update on how the work on this draft is doing? 

I'm particularly interested in an answer to my earlier question concerning section 4.6., i.e.: if a message needs to be regenerated to be forwarded, and this message contains TLVs that the regenerating 5444 parser/builder doesn't recognize, should it add the unknown TLVs to the message (which would mean that “MUST NOT remove suchTLVs or values” applies, which should imo be clarified in the draft) or should the unknown TLVs be discarded (which would need clarification too, imo)?

If the answer is “we're working on it, hold on for a few more days”, that's completely fine, I'd just like to know if/when I can find out how to do this correctly. :)

Regards,
Lotte

Am 09.06.2015 um 16:26 schrieb Lotte Steenbrink <[e-mail]>:

> Hi Ulrich, Thomas, Chris and Henning,
> 
> Am 31.05.2015 um 13:33 schrieb Ulrich Herberg <[e-mail]>:
> 
>> 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.
> 
> 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: [e-mail]
>>> Date: May 28, 2015 at 11:12:35 GMT+3
>>> To: "Christopher Dearlove" <[e-mail]>, "Henning Rogge" <[e-mail]>, "Thomas Clausen" <[e-mail]>, "Henning Rogge" <[e-mail]>, "Ulrich Herberg" <[e-mail]>, "Thomas H. Clausen" <[e-mail]>, "Christopher Dearlove" <[e-mail]>, "Ulrich Herberg" <[e-mail]>
>>> 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.
>>> 
>>> The IETF Secretariat
>>> 
>> _______________________________________________
>> manet mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/manet
> 
> _______________________________________________
> manet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/manet