Re: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03

[Lotte Steenbrink <[e-mail]>]

Hi Christopher,

> Am 15.04.2016 um 19:49 schrieb Christopher Dearlove <[e-mail]>:
> 
> A few immediate comments inline below.
> 
> --  
> Christopher Dearlove
> [e-mail] <mailto:[e-mail]> (iPhone)
> [e-mail] <mailto:[e-mail]> (home)
> 
> On 15 Apr 2016, at 15:18, Lotte Steenbrink <[e-mail] <mailto:[e-mail]>> wrote:
> 
>> Hi all,
>> 
>> sparked by the recently started WGLC, I’ve reviewed the current revision of the draft. I’d like to offer the working group my perspective as someone who doesn’t have decades of protocol and/or packet format design under their belt (i.e. some things might not be obvious to me that are obvious to others), but also as someone who has worked with RFC 5444 when implementing a routing protocol (AODVv2), updating the packet format of a routing protocol (AODVv2 again) and (partially) implementing my own RFC5444 builder/parser.
>> 
>> Overall, I think the document is easy to read and follow. To me, it contains valuable information and guidance and in some cases prevents people from shooting themselves in the foot.
>> I’m really happy this document exists and I’d like it to move forward soon, but I do feel that it is still lacking in some areas, which is why I was a bit surprised to see it go to Last Call all of a sudden.
> 
> Not really. The authors had said what they intended to say, no one was commenting, time for WGLC.

I was kind of still waiting for an answer to my E-Mail from October (see below)...

> 
>> First, some nitpicks and comments:
>> 
>> * from 1.2.1 <https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-03#section-1.2.1>. Packet/Message Format:
>> 
>>       […] a packet
>>       transmission following a successful packet reception is by design
>>       of a new packet that may include all, some, or none of the
>>       received messages [...]
>> 
>> I’m not a native speaker, but that „of“ seems out of place...
> 
> I am a native speaker, and no, it's not. Some would repeat it after each of all, some and none, and I might sometimes. But it really doesn't matter which of the two styles we pick, the RFC Editor may well change to the other.

OK cool, then I learned something new. :) Sorry about the fuss, and thanks for the explanation.

> 
>> * Regarding 4.2 <https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-03#section-4.2>. Packets and Messages:
>> this section talks a lot about how the multiplexer operates, so I think it’d be helpful if its title reflected that. 
> 
> I'm of two opinions on that. On the one hand it is, as its title suggests, about the packet and message level, as opposed to lower levels, and its title contrasts with that if 4.3 for that reason. On the other hand you are right, it does have much about the multiplexer. A title covering all three woukd start getting cumbersome. Will take this one away to think about.
> 
>> * from 4.4 <https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-03#section-4.4>. Addresses Require Attributes:
>> 
>>    An unmodified extension to NHDP would ignore such addresses,
>>    as required, as it does not support that specialized purpose.
>> 
>> At first glance, (to me) this reads as „All addresses that are associated with an unknown TLV are ignored“, which is obviously nonsense (but quite panic-inducing :D). I’d propose to reword it to something along the lines of 
>>    An unmodified extension to NHDP would not consider this
>>    address to be of a neighbor, as it is lacking a LINK_STATUS
>>    or OTHER_NEIGHB TLV.
> 
> I take your point, but I think that if the address ends up with no relevant associated TLVs then it is ignored is also a point. I dare say we can wordsmith something.
> 
>> Also, I don’t quite get where you’re going with the last paragraph of that section (“These restrictions do not, however, mean that added information is
>>    completely ignored for purposes of the base protocol.”)...
> 
> Read on, the rest of the paragraph describes the case where not. But we might telegraph that better in the opening sentence.

I know it does, but I don’t quite see how the paragraph fits into the rest of the section and what exactly it wants to warn users about.

> 
>> * regarding the maps in 4.5 <https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-03#section-4.5>. Information Representation:
>> I’m afraid I just don’t really understand the purpose of this section and the mapping notation. I’m assuming that the maps are supposed to offer a way of describing how a TLV relates to a message or an address? 
>> If so, why does it only mention extension types, but not the basis types?
> 
> It says extended types, meaning the combination of the two. But full type would be better, as almost defined in 5444. In fact I think we should add a comment to the notation section. (5444 uses a symbolic name rather than the phrase.)
> 
>> Or is it supposed to be used something like this:
>> 
>> BASE_TLV
>> 
>> Message: 
>> (base_tlv_extension_type_1) -> (2 octets, "value a when condition x is met")
>> (base_tlv_extension_type_2) -> (2 octets, "value b when condition y is met")
>> 
>> ? Also, I don’t quite get how this would be used in future protocol specifications? Or aid in implementing RFC5444 parsers?
>> An example or a clarification would be very helpful.
> 
> It's a way of looking at things. But not the only one, it goes on to discuss variants. I think it mostly comes under heading of if useful use it, if not skip it.

I get that, I just wanted to point out that at least to me, it isn’t quite obvious if this section would be useful for me, because I don’t get what it’s trying to say. If I’m not the target audience that’s finde, but I thought it may be something to consider otherwise.

> We'll take another look, but I don't think this will ever be elementary.
> 
>> * regarding 4.6 <https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-03#section-4.6>. TLVs:
>> In general, it’s not clear everywhere in the section whether you’re talking to RFC5444 parser/builder implementors or protocol designers. 
>> 
>>    A protocol SHOULD use an efficient
>>    representation, but this is a quality of implementation issue.
>> 
>> I’m not sure where you’re going with the last part of that sentence? I’d reword it to something like „A protocol SHOULD use an efficient representation, avoiding unnecessarily verbose use of TLVs and extension types. However, the final arrangement in a message- or addressTLV block is  a quality of implementation issue“ (in case that’s what you meant).
> 
> No, you're considering the protocol design. This is considering the protocol object that implements the protocol. There isn't a one to one mapping from information to representation, it's up to the implementation to do it efficiently. Different implementations of the same protocol specification may do better or worse here. (Trivial case, an implementation could choose to never compress addresses. Bad idea, but legal.)

In that case, I find the current wording very misleading.

> 
>> And then:
>> 
>>    A
>>    protocol MUST recognize any permitted representation of the
>>    information; even if it chooses to (for example) only use multivalue
>>    TLVs, it MUST recognize single value TLVs (and vice versa).
>> 
>> … I thought protocols weren’t supposed to specify whether a TLV is arranged (for example) as a multivalue TLV?!
> 
> Implementation again, not design.

Misleading wording then, again.

> 
>> And so, since a protocol shouldn't be concerned with multivalue TLVs and the like, wouldn’t it be the *RFC5444 implementation* that MUST recognize any permitted representation?
> 
> You're assuming that there is an RFC 5444 implementation. That's the same way to work if you plan to implement more than one protocol. But nothing says you have to do it that way. The architecture defined by 5498 admits of the multiplexer and protocols, and thus these are rules on the protocol. If protocols delegate all their common work to something (parser/creator) then it inherits those restrictions, but that's not defined, and we can't assume it.

Hmm. But even if a protocol implementation has its own RFC5444 message building code which is not generic and deeply entangled in the rest of the code, the parser checking a message still does this based on RFC5444 specifications, not on the protocol specifications (since the protocol must not know or care about stuff like multivalue TLVs)? So to me, that’d put it into 5444 territory.

I guess what I’d expected from the document is to say “these are the entities involved*, and they have tasks x, y and z, and they talk to each other like so, and while they may not be present as autonomous entities in specific implementations we’ll use them in this draft to describe what should (not) be going on where”. It’s not trivial to figure out the distribution of tasks here (I’m still struggling with it 2 years in and I’m not sure if my intellect is the sole cause of this), and I think it would’ve been helpful if 5444-usage cleared it up a bit.

* probably something like Protocol, RFC5444 message building/parsing component, multiplexer?

> 
>> Or is this paragraph really just a complicated way of saying „as a protocol designer, make sure to not specify/rely on things like (for example) multivalue TLVs, since your messages have to work with *any* representation“? If so, I think that should be done in a less complicated fashion (see below).
>> 
>> * regarding 5 <https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-03#section-5>. Structure:
>> Since this section talks a lot about flags, it’d be nice if its title represented that. Maybe consider renaming it to „Structure and Flags“ or so?
> 
> I mostly don't agree. Structure is the subject, flags are a detail.
> 
>> * from 6.1 <https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-03#section-6.1>. Address Block Compression:
>> 
>>    Compression of addresses in an Address Block considers addresses to
>>    consist of a Head, a Mid, and a Tail, where all addresses in an
>>    Address Block have the same Head and Tail, but different Mids.
>> 
>> 
>> I’d find this sentence easier to read if it started with “Compression of addresses in an Address Block is possible when addresses consist of a Head, a Mid […]”.
> 
> No. That's missing the point and misleading. Addresses are always considered to have the head/mid/tail format. Compression is possible if either the head or tail (or both) is non-empty.

Mh, true.

> 
>> * from 6.1 <https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-03#section-6.1>. Address Block Compression:
>> 
>>    Putting addresses into a message efficiently also has to include:
>> 
>> Why „has to“? I’d think that would be a „may“. Multiple Adress Blocks and/or reordering don’t increase efficiency in all possible cases...
> 
> I think that's the wrong change. Rather "include" should be "consider“.

Sounds good.

> 
>> * from 6.2 <https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-03#section-6.2>. TLVs:
>>       [...] This is even possible if the MPR TLV specified in
>>       OLSRv2 [RFC7181 <https://tools.ietf.org/html/rfc7181>] is added; but it is not possible, in general, if
>>       the LINK_METRIC TLV is also added.
>> 
>> Why is it not possible for the latter? If that could be explained/hinted at in a half sentence, I think it’d be helpful information to have in the draft.
> 
> That's very hard, and not just because it's a negative. It's really an observation that motivates the duscussion. A half sentence would I think confuse more than it enlightens (it's because you have too many constraints to satisfy at once - I doubt that helped).

I think it actually did :)

> 
>>       In a typical case where a
>>       LINK_STATUS TLV uses only the Values HEARD and SYMMETRIC, with
>>       enough addresses, sorted appropriately, two single value TLVs can
>>       be more efficient than one multivalue TLV.
>> 
>> Same thing: why?
> 
> Here I think this should be obvious to anyone who has looked at 5444.

Well, yeah, I get why using multivalue TLVs can be more efficient, what I was getting at was that you’d have to be familiar with  LINK_STATUS TLVs in order for this specific example to be clear. But now that I’m thinking about it that was rubbish. TL;DR: nevermind.

> 
>> * regarding the second paragraph from 6.3 <https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-03#section-6.3>. TLV Values, i.e.
>>    
>>    This approach was specified in [RFC7188 <https://tools.ietf.org/html/rfc7188>], and required for protocols
>>    that extend [RFC6130 <https://tools.ietf.org/html/rfc6130>] and [RFC7181 <https://tools.ietf.org/html/rfc7181>].  It is here RECOMMENDED that
>>    this approach is followed when defining any Address Block TLV that
>>    may be used by a protocol using [RFC5444 <https://tools.ietf.org/html/rfc5444>].
>> 
>> The term „this approach“ confused me, since I initially  thought it meant „the approach is to use UNSPECIFIED in a way that makes sense“ rather than „the approach is to use UNSPECIFIED“. Maybe that could be reworded to something along the lines of 
>> The UNSPECIFIED TLV and its usage was specified in [RFC7188]… 
>> ?
> 
> No. There is no UNSPECIFIED TLV. There is a recommendation to include an UNSPECIFIED value in a TLV. But really, we've described this once in 7188, it's there to read.
> 
>> * regarding 6.3 <https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-03#section-6.3>. TLV Values:
>> The second paragraph is a bit confusing and seems to explaing roghly the same things as the fourth paragraphs. I’d propose to merge the second into the fourth.
> 
> I'm not sure I exactly agree, but the ordering in that section could be improved.

That’d be great.

> 
>> * from 6.4 <https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-03#section-6.4>. Automation:
>> 
>>    The possible gain depends on the efficiency
>>    of the original message creation,
>> 
>> the term „the original message creation“ seems a bit ambiguous– does this refer to the message as created by an RFC5444 message builder implementation?
> 
> Yes.

Okay, thanks :)

> 
>> Additionally, I'm concerned about two things that *aren’t* in the draft:
>> 
>> *  Some of the AODVv2 co-authors and me have asked for a list of „as a protocol, you can set all of these fields of a message, but please leave the rest alone“, which would’ve saved us many hours of discussions (and Henning a lot of time spent explaining these things…). These requests have been met with a refusal to specify a concrete API, as such an effort is dependent on outside factors such as programming language or software architecture. I agree with this notion, but a programming-language dependent API is not what we’ve asked for. I’ve tried to supply a sketch of what I did ask for in [1], but unfortunately I didn’t get an answer (and as far as I can see it, the draft wasn’t changed either). I still think that such a list, in whatever form, would be very helpful for future Internet-Draft authors and I also think this request is in accordance with the intentions stated in 1.1 History and Purpose, and I think it should be included in the document.
> 
> No. There are many reasons why we're just not touching this one.
> 
> One is that language independence is a mirage. How you go about things is completely different in, for example an object oriented language than one that isn't. Section 4.5 shows that there are quite different ways of doing things even given a decision to use a map approach, and there are other approaches than that. It would be wrong and beyond our competence to suggest one of these as "best". There's reasons the IETF doesn't do this, and that's one.

What does this have to do with object orientation? I’m not asking for the draft to contain a recommendation on how to implement  RFC 5444 message building/parsing code.

Kind regards,
Lotte

> 
> Plus, frankly, the work it would take is beyond what we choose to spend.
> 
>> * As the exact rules for using/setting the hop count & hop-limit fields are currently being discussed w/ regard to AODVv2 in another thread [2]– should a definitive answer to that question be part of 5444-usage?
> 
> You don't want that. Because if we did specify that you'd find yourself more constrained than you want to be. There is a design intent described in 5444, but it assumes immutable messages. Which you don't want. Really, we're doing you a favour by not imposing on you.
> 
>> Best regards,
>> Lotte
>> 
>> [1] https://www.ietf.org/mail-archive/web/manet/current/msg18082.html <https://www.ietf.org/mail-archive/web/manet/current/msg18082.html>
>> [2] https://www.ietf.org/mail-archive/web/manet/current/msg18674.html <https://www.ietf.org/mail-archive/web/manet/current/msg18674.html> 
>> 
>> 
>>> Am 06.04.2016 um 19:14 schrieb Justin Dean <[e-mail] <mailto:[e-mail]>>:
>>> 
>>> The chairs agree that a 3 week WGLC is appropriate.  Everyone please read the draft early and get comments in early so that they can be addressed within the last call period.
>>> 
>>> Justin
>>> 
>>> On Wed, Apr 6, 2016 at 7:40 AM, Dearlove, Christopher (UK) <[e-mail] <mailto:[e-mail]>> wrote:
>>> Obviously +1 to the request for WGLC.
>>> 
>>> With regard to what's changed, technically the only significant thing is to make it clear that if a protocol delivers a message to the multiplexer, the multiplexer must pass it on unchanged to the protocol (another instance of, at another router) unchanged. Without that nothing that the protocol itself chooses to do with regard to security makes sense. Though the protocol can alternatively let the multiplexer do the security, 7182 can be implemented in either way. This isn't really new, but it wasn't formally spelled out. It's presented as part of spelling out multiplexer rules more carefully.
>>> 
>>> But what about message optimisation? That's a function of constructing a 5444 message, not the multiplexer, and is down to that 5444 includes two things - packet/message structure (and implicitly, and in pretty much any implementation I would expect to see, a parser and builder for that structure) and the multiplexer. So we took the opportunity to separate out more clearly a discussion of the two, which we think will be helpful.
>>> 
>>> --
>>> Christopher Dearlove
>>> Senior Principal Engineer
>>> BAE Systems Applied Intelligence Laboratories
>>> __________________________________________________________________________
>>> 
>>> T:  [phone] <tel:%2B44%20%280%291245%20242194>  |  E: [e-mail] <mailto:[e-mail]>
>>> 
>>> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
>>> www.baesystems.com/ai <http://www.baesystems.com/ai>
>>> BAE Systems Applied Intelligence Limited
>>> Registered in England & Wales No: 01337451
>>> Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP
>>> 
>>> -----Original Message-----
>>> From: manet [mailto:[e-mail] <mailto:[e-mail]>] On Behalf Of Ulrich Herberg
>>> Sent: 05 April 2016 20:08
>>> To: [e-mail] <mailto:[e-mail]>
>>> Subject: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03
>>> 
>>> ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet.
>>> Consider carefully whether you should click on any links, open any attachments or reply.
>>> Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages.
>>> --------------------------------------------------------
>>> 
>>> *** WARNING ***
>>> EXTERNAL EMAIL -- This message originates from outside our organization.
>>> 
>>> 
>>> Hi,
>>> 
>>> As you have seen, we have submitted a new revision of 5444-usage. The authors feel comfortable that we have addressed all issues by this version, and would like to ask the WG chairs to issue a WGLC on this document. While it is a fairly short document, given that it is IETF week for some, we'd suggest that a 3-4 week WGLC would be appropriate.
>>> 
>>> Best regards
>>> Ulrich
>>> 
>>> _______________________________________________
>>> manet mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/manet <https://www.ietf.org/mailman/listinfo/manet>
>>> 
>>> 
>>> ********************************************************************
>>> This email and any attachments are confidential to the intended
>>> recipient and may also be privileged. If you are not the intended
>>> recipient please delete it from your system and notify the sender.
>>> You should not copy it or use it for any purpose nor disclose or
>>> distribute its contents to any other person.
>>> ********************************************************************
>>> 
>>> _______________________________________________
>>> manet mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/manet <https://www.ietf.org/mailman/listinfo/manet>
>>> 
>>> _______________________________________________
>>> manet mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/manet <https://www.ietf.org/mailman/listinfo/manet>
>> 
>> _______________________________________________
>> manet mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/manet <https://www.ietf.org/mailman/listinfo/manet>