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

From: Ulrich Herberg <[email-masked]>
Date: Tue, 5 Apr 2016 12:07:41 -0700

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

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 6 Apr 2016 11:40:23 +0000

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:  +44 (0)1245 242194  |  E: [email-masked]

BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
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:[email-masked]] On Behalf Of Ulrich Herberg
Sent: 05 April 2016 20:08
To: [email-masked]
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
[email-masked]
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.
********************************************************************

---

From: Thomas Clausen <[email-masked]>
Date: Wed, 6 Apr 2016 16:26:39 +0200

> On 06 Apr 2016, at 13:40, Dearlove, Christopher (UK) <[email-masked]> wrote:
> 

Obviously also +1 from me.

Thomas

---

From: Justin Dean <[email-masked]>
Date: Wed, 6 Apr 2016 13:14:44 -0400

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) <
[email-masked]> wrote:

> 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
> ----------------------! WARNING ! ---------------------- This message
> originates from outside our organisation, either from an external partner
> or from the internet.
> 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
>

---

From: John Dowdell <[email-masked]>
Date: Thu, 7 Apr 2016 22:50:07 +0100

Justin

Just to be clear, when did the last call period start and when does it finish?

Regards
John

> On 6 Apr 2016, at 18:14, Justin Dean <[email-masked]> wrote:
> 
> 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) <[email-masked] <mailto:[email-masked]>> wrote:
> T:  +44 (0)1245 242194 <tel:%2B44%20%280%291245%20242194>  |  E: [email-masked] <mailto:[email-masked]>
> 
> www.baesystems.com/ai <http://www.baesystems.com/ai>
> From: manet [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Ulrich Herberg
> To: [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/manet <https://www.ietf.org/mailman/listinfo/manet>
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/manet <https://www.ietf.org/mailman/listinfo/manet>
>

---

From: Justin Dean <[email-masked]>
Date: Thu, 7 Apr 2016 20:26:40 -0400

Last call started on the 6th of Apr and will finish on the 27th of Apr.

Justin

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 8 Apr 2016 09:15:03 +0000

Thanks for that Justin.

Here’s a convenient place to note that Fred Baker appears to be running a script that emails all draft authors if the draft doesn’t include IPv6 examples. (It’s a script that needs improvement, as the email suggests that the authors just haven’t considered IPv6, which is rather unlikely when IPv6 is explicitly mentioned.)

This draft has an IPv4, but not an IPv6 example, though the paragraph it’s in also discusses IPv6. Personally I don’t think that adding an IPv6 example helps with the point that was being made, but we responded to Fred saying we’d consider his comment (or his script’s comment) as part of WGLC (hence this posting, as otherwise it is only known to the authors, chairs etc.) and see if the WG felt an IPv6 example was needed.

I would suggest reading the context of the example before taking a view. The authors will of course follow any rough consensus.

T:  +44 (0)1245 242194  |  E: [email-masked]<mailto:[email-masked]>

www.baesystems.com/ai<http://www.baesystems.com/ai>

From: manet [mailto:[email-masked]] On Behalf Of Justin Dean
Sent: 08 April 2016 01:27
To: John Dowdell
Cc: [email-masked]
Subject: Re: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03

*** WARNING ***
This message originates from outside our organisation, either from an external partner or the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
For information regarding Red Flags that you can look out for in emails you receive, click here<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.
If you feel the email is suspicious, please follow this process<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.
*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.

On Thu, Apr 7, 2016 at 5:50 PM, John Dowdell <[email-masked]<mailto:[email-masked]>> wrote:
Justin

Regards
John

On 6 Apr 2016, at 18:14, Justin Dean <[email-masked]<mailto:[email-masked]>> wrote:

Justin

On Wed, Apr 6, 2016 at 7:40 AM, Dearlove, Christopher (UK) <[email-masked]<mailto:[email-masked]>> wrote:
Obviously +1 to the request for WGLC.

T:  +44 (0)1245 242194<tel:%2B44%20%280%291245%20242194>  |  E: [email-masked]<mailto:[email-masked]>

www.baesystems.com/ai<http://www.baesystems.com/ai>

-----Original Message-----
From: manet [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Ulrich Herberg
Sent: 05 April 2016 20:08
To: [email-masked]<mailto:[email-masked]>
Subject: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03

*** WARNING ***

Hi,

Best regards
Ulrich

_______________________________________________
manet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/manet

---

From: Jiazi YI <[email-masked]>
Date: Sat, 9 Apr 2016 00:58:53 +0200

The only IPv4-specific example that I found is the one in "6.1.  Address
Block Compression" section (please indicate if I missed any other points).

In my personal opinion, it's quite straightforward and not necessarily
adding an IPv6-specific one.
Well, of course, if there were people who really care, adding one won't
hurt either :)

regards

Jiazi

On Fri, Apr 8, 2016 at 11:15 AM, Dearlove, Christopher (UK) <
[email-masked]> wrote:

> Thanks for that Justin.
>
>
>
> Here’s a convenient place to note that Fred Baker appears to be running a
> script that emails all draft authors if the draft doesn’t include IPv6
> examples. (It’s a script that needs improvement, as the email suggests that
> the authors just haven’t considered IPv6, which is rather unlikely when
> IPv6 is explicitly mentioned.)
>
>
>
> This draft has an IPv4, but not an IPv6 example, though the paragraph it’s
> in also discusses IPv6. Personally I don’t think that adding an IPv6
> example helps with the point that was being made, but we responded to Fred
> saying we’d consider his comment (or his script’s comment) as part of WGLC
> (hence this posting, as otherwise it is only known to the authors, chairs
> etc.) and see if the WG felt an IPv6 example was needed.
>
>
>
> I would suggest reading the context of the example before taking a view.
> The authors will of course follow any rough consensus.
>
>
>
> *-- *
>
>
>
>
> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
> Intelligence Laboratories *
> *__________________________________________________________________________
> *
> *T*:  +44 (0)1245 242194  |  *E: [email-masked]
>
> *From:* manet [mailto:[email-masked]] *On Behalf Of *Justin Dean
> *Sent:* 08 April 2016 01:27
> *To:* John Dowdell
> *Cc:* [email-masked]
> *Subject:* Re: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03
>
>
>
>
>
> **** WARNING ****
>
> *This message originates from outside our organisation, either from an
> external partner or the internet.*
>
> * Consider carefully whether you should click on any links, open any
> attachments or reply. For information regarding **Red Flags** that you
> can look out for in emails you receive, click here
> <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.*
> * If you feel the email is suspicious, please follow this process
> <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.*
>
> **** **WARNING ******

---

From: Lotte Steenbrink <[email-masked]>
Date: Fri, 15 Apr 2016 16:18:58 +0200

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.

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...

* 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. 

* 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.

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.”)...

* 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? 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.

* 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).

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?! 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? 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?

* 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 […]”.

* 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...

* 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.

      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?

* 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]… 
?

* 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.

* 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?

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.  

* 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?

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 

> Am 06.04.2016 um 19:14 schrieb Justin Dean <[email-masked]>:
>

---

From: Christopher Dearlove <[email-masked]>
Date: Fri, 15 Apr 2016 18:49:54 +0100

A few immediate comments inline below.

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

> On 15 Apr 2016, at 15:18, Lotte Steenbrink <[email-masked]> wrote:
> 
> Hi all,
> 

Not really. The authors had said what they intended to say, no one was commenting, time for WGLC.

> * from 1.2.1. Packet/Message Format:
> 
>       […] a packet

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.

> * Regarding 4.2. Packets and Messages:

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. Addresses Require Attributes:
> 

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.

>    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.

> * regarding the maps in 4.5. Information Representation:
> 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: 

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. We'll take another look, but I don't think this will ever be elementary.

> * regarding 4.6. TLVs:

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.)

> … I thought protocols weren’t supposed to specify whether a TLV is arranged (for example) as a multivalue TLV?!

Implementation again, not design.

> 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.

> 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. Structure:

I mostly don't agree. Structure is the subject, flags are a detail.

> * from 6.1. Address Block Compression:
> 

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.

> * from 6.1. Address Block Compression:
> 

I think that's the wrong change. Rather "include" should be "consider".

> * from 6.2. TLVs:
>       OLSRv2 [RFC7181] is added; but it is not possible, in general, if

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).

>       be more efficient than one multivalue TLV.

Here I think this should be obvious to anyone who has looked at 5444.

> * regarding the second paragraph from 6.3. TLV Values, i.e.
>    
>    This approach was specified in [RFC7188], and required for protocols
>    that extend [RFC6130] and [RFC7181].  It is here RECOMMENDED that
>    may be used by a protocol using [RFC5444].
> 

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. TLV Values:

I'm not sure I exactly agree, but the ordering in that section could be improved.

> * from 6.4. Automation:

Yes.

> *  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 o…

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.

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…

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
>>> On Wed, Apr 6, 2016 at 7:40 AM, Dearlove, Christopher (UK) <[email-masked]> wrote:

---

From: Stan Ratliff <[email-masked]>
Date: Fri, 15 Apr 2016 14:37:09 -0400

My main concern addressed inline...

On Fri, Apr 15, 2016 at 1:49 PM, Christopher Dearlove <
[email-masked]> wrote:

> 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.
>
>
> * from 1.2.1
> <https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-03#section-1.2.1>.
> Packet/Message Format:
>
>       […] a packet
>
> 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.
>
> * 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:
>
> 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
>
> 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
>
> Read on, the rest of the paragraph describes the case where not. But we
> might telegraph that better in the opening sentence.
>
> * 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?
> 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.)
>
> *BASE_TLV*
> ? Also, I don’t quite get how this would be used in future protocol
> specifications? Or aid in implementing RFC5444 parsers?
> 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. 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.
>
> 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.)
>
> And then:
>
>    A
> … I thought protocols weren’t supposed to specify whether a TLV is
> arranged (for example) as a multivalue TLV?!
>
>
> 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.
>
> 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?
>
>
> * from 6.1
> <https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-03#section-6.1>.
> Address Block Compression:
>
> 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.
>
> * from 6.1
> <https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-03#section-6.1>.
> Address Block Compression:
>
>
> 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...
>
>
> * from 6.2
> <https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-03#section-6.2>.
> TLVs:
>
> 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).
>
> * 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.
>
>
>
> 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
> 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.
>
>
> * from 6.4
> <https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-03#section-6.4>.
> Automation:
>
> 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.
>
> *  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.
>
>
> 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.
>

<Speaking as a WG Participant>

I'm confused (which is an altogether too common occurrence these days). I
get that we don't want to specify an API. But I think the discussion about
fields a protocol can and can't touch in a messages is a good thing - and
it's one spot where I, too, find the document wanting.

To paraphrase something I've said before, I believe that RFC 5444 changes
the relationship that a routing protocol has with an "interface". I'm not
commenting on whether or not that's a good thing, or a bad thing - just
that it does change the relationship. This change has been at the root of
some of the long-running discussions as to whether protocols under
development were RFC 5444 compliant or not. The goal of this document being
to eliminate (it's a goal, probably not reachable) those discussions, I'd
like to see that information in the document in some form.

I'm interested in seeing this document progress, and eventually be
published. I think it will help future protocol designers to better use RFC
5444. But I would like to see *something* along the lines of what Lotte is
requesting, as I think it will improve the doc.

Regards,
Stan

>
> * 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
>

---

From: Christopher Dearlove <[email-masked]>
Date: Fri, 15 Apr 2016 21:11:20 +0100

I don't understand what you mean by the concept of "fields the protocol can and can't touch".

When a protocol creates a message from scratch it's not constrained in any way I'd describe in such terms. So I assume you mean when it receives a message and then sends a similar message.

There are two cases there. Unchanged (with the special exceptions for hop count and limit) and not unchanged. The former is better, and there's really nothing more to say.

So let's consider the latter. Really it's not the same message, it's a brand new message. That's a useful way to look at it from a security perspective, because it tells you that end to end authentication isn't going to work. And what are the restrictions on brand new messages? The same as on any new message.

OK, you might say, true but does that mean I can add this, remove that, change the hop data? Yes. But is that a good idea? No. But maybe you are forced into it. But that it's inherently not good suggests the corollary that if you must, do the minimum and make it trackable. But that's not a 5444 requirement, just good practice. It does break 7182 message ICVs, so don't use them.

We could, hypothetically, have someone create an extension or alternative to 7182 that defined aggregated signatures. Then we'd have rules on what you could change. But that would belong there. If you think those would be good, then again you would want make minimal changes, and mainly only of certain types. What types? There I can't help you as I don't have a candidate.

The summary? Don't change if you don't have to. That's recommended. If you must change you're on your own (with the same restrictions as new messages). Advice like "as little as possible" is good, but that's not actually 5444 advice. And don't use 7182 message ICVs.

> On 15 Apr 2016, at 19:37, Stan Ratliff <[email-masked]> wrote:
> 
>> On Fri, Apr 15, 2016 at 1:49 PM, Christopher Dearlove <[email-masked]> wrote:
> I'm confused (which is an altogether too common occurrence these days). I get that we don't want to specify an API. But I think the discussion about fields a protocol can and can't touch in a messages is a good thing - and it's one spot where I, too, find the document wanting. 
> 
> To paraphrase something I've said before, I believe that RFC 5444 changes the relationship that a routing protocol has with an "interface". I'm not commenting on whether or not that's a good thing, or a bad thing - just that it does change the relationship. This change has been at the root of some of the long-running discussions as to whether protocols under development were RFC 5444 compliant or not. The goal of this document being to eliminate (it's a goal, probably not reachable) those discussions, I'd like to see that information in the document in some form. 
> 
> I'm interested in seeing this document progress, and eventually be published. I think it will help future protocol designers to better use RFC 5444. But I would like to see *something* along the lines of what Lotte is requesting, as I think it will improve the doc. 
> 
> Regards,
> Stan
> 
>  
>>

---

From: Stan Ratliff <[email-masked]>
Date: Sat, 16 Apr 2016 14:08:37 -0400

> I don't understand what you mean by the concept of "fields the protocol

CAVEAT: I am speaking here as a Working Group participant. With that
understood:

TTL is a great example, since that discussion blew the mailing list up a
few months ago. I'm *not* saying manipulating TTL is a good thing for a
protocol to try - in truth, I think it's pretty "hacky". But the notion was
floated, and in the context of that discussion, it may will have worked.
The opposition on-list was fast, and pretty forceful.

I've said before - 5444, especially with the multiplexer, changes the
relationship between a routing protocol and an interface. I think the
document should have some type of "overview" section which discusses these
differences, in order to frame the issue for someone coming along who
hasn't been a part of the 5444 mail discussion.

I'm talking about the type of overview that goes something like this:

"Use of RFC 5444 with the multiplexer feature imposes design requirements
on the protocol. The actual transport mechanism is abstracted from the
protocol. For example, routing protocols are not aware of precisely when a
message is sent. A good example of operation in this model is [BGP],
utilizing the [TCP] transport. This is opposed to a protocol such as
[OSPF], which is capable of sending traffic with its own IP type. Since the
transport is abstracted, protocols are not presented with "packets", and
are not capable of manipulating data items in packet headers (e.g. data
items at the IP and/or MAC layers)."

As Lou Berger put it to me in the context of DLEP - "You want an engineer
to be able to pick up this document, with no prior exposure to the topic,
and code an interoperable implementation."  I think this type of an
overview, setting basic ground rules, would help.

I've also contended for a while now that 5444, with the mux, effectively
forces an architecture on implementers - in the Linux world, that
architecture is a 5444 parser as an independent process, with IPC
mechanisms to the routing protocol(s) it is servicing. The 5444 parser
itself "owns" the transport (the socket). The usage document *strongly
infers* that. I believe we should concretely state it, so we don't have to
answer the question over and over again.

Regards,
Stan

>
> When a protocol creates a message from scratch it's not constrained in any
> way I'd describe in such terms. So I assume you mean when it receives a
> message and then sends a similar message.
>
> There are two cases there. Unchanged (with the special exceptions for hop
> count and limit) and not unchanged. The former is better, and there's
> really nothing more to say.
>
> So let's consider the latter. Really it's not the same message, it's a
> brand new message. That's a useful way to look at it from a security
> perspective, because it tells you that end to end authentication isn't
> going to work. And what are the restrictions on brand new messages? The
> same as on any new message.
>
> OK, you might say, true but does that mean I can add this, remove that,
> change the hop data? Yes. But is that a good idea? No. But maybe you are
> forced into it. But that it's inherently not good suggests the corollary
> that if you must, do the minimum and make it trackable. But that's not a
> 5444 requirement, just good practice. It does break 7182 message ICVs, so
> don't use them.
>
> We could, hypothetically, have someone create an extension or alternative
> to 7182 that defined aggregated signatures. Then we'd have rules on what
> you could change. But that would belong there. If you think those would be
> good, then again you would want make minimal changes, and mainly only of
> certain types. What types? There I can't help you as I don't have a
> candidate.
>
> The summary? Don't change if you don't have to. That's recommended. If you
> must change you're on your own (with the same restrictions as new
> messages). Advice like "as little as possible" is good, but that's not
> actually 5444 advice. And don't use 7182 message ICVs.
>
> --
> Christopher Dearlove
>> 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
>>> Follow the 'Report Suspicious Emails' link on IT matters for
>>> instructions on reporting suspicious email messages.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 18 Apr 2016 08:52:41 +0000

I don’t believe we can or should suggest an implementation. That’s not what the IETF does, and it would be a hard, probably impossible, sell, to the IESG. That the obvious implementation employs an independent parser is already said - it may be appropriate to strengthen the words, but this second I’m not sure if that’s needed (not got time to check current wording).

From: manet [mailto:[email-masked]] On Behalf Of Stan Ratliff
Sent: 16 April 2016 19:09
To: Christopher Dearlove
Cc: [email-masked]; Christopher Dearlove
Subject: Re: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03

*** WARNING ***

On Fri, Apr 15, 2016 at 3:27 PM, Christopher Dearlove <[email-masked]<mailto:[email-masked]>> wrote:
I don't understand what you mean by the concept of "fields the protocol can and can't touch".

CAVEAT: I am speaking here as a Working Group participant. With that understood:

TTL is a great example, since that discussion blew the mailing list up a few months ago. I'm *not* saying manipulating TTL is a good thing for a protocol to try - in truth, I think it's pretty "hacky". But the notion was floated, and in the context of that discussion, it may will have worked. The opposition on-list was fast, and pretty forceful.
I've said before - 5444, especially with the multiplexer, changes the relationship between a routing protocol and an interface. I think the document should have some type of "overview" section which discusses these differences, in order to frame the issue for someone coming along who hasn't been a part of the 5444 mail discussion.
I'm talking about the type of overview that goes something like this:
"Use of RFC 5444 with the multiplexer feature imposes design requirements on the protocol. The actual transport mechanism is abstracted from the protocol. For example, routing protocols are not aware of precisely when a message is sent. A good example of operation in this model is [BGP], utilizing the [TCP] transport. This is opposed to a protocol such as [OSPF], which is capable of sending traffic with its own IP type. Since the transport is abstracted, protocols are not presented with "packets", and are not capable of manipulating data items in packet headers (e.g. data items at the IP and/or MAC layers)."

As Lou Berger put it to me in the context of DLEP - "You want an engineer to be able to pick up this document, with no prior exposure to the topic, and code an interoperable implementation."  I think this type of an overview, setting basic ground rules, would help.
I've also contended for a while now that 5444, with the mux, effectively forces an architecture on implementers - in the Linux world, that architecture is a 5444 parser as an independent process, with IPC mechanisms to the routing protocol(s) it is servicing. The 5444 parser itself "owns" the transport (the socket). The usage document *strongly infers* that. I believe we should concretely state it, so we don't have to answer the question over and over again.
Regards,
Stan

--
Christopher Dearlove
[email-masked]<mailto:[email-masked]> (iPhone)
[email-masked]<mailto:[email-masked]> (home)

On 15 Apr 2016, at 19:37, Stan Ratliff <[email-masked]<mailto:[email-masked]>> wrote:
My main concern addressed inline...

On Fri, Apr 15, 2016 at 1:49 PM, Christopher Dearlove <[email-masked]<mailto:[email-masked]>> wrote:
A few immediate comments inline below.

--
Christopher Dearlove
[email-masked]<mailto:[email-masked]> (iPhone)
[email-masked]<mailto:[email-masked]> (home)

On 15 Apr 2016, at 15:18, Lotte Steenbrink <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

* from 1.2.1<https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-03#section-1.2.1>. Packet/Message Format:

      […] a packet

      received messages [...]

* 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.

* from 4.4<https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-03#section-4.4>. Addresses Require Attributes:

   or OTHER_NEIGHB TLV.

* 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?

BASE_TLV

Message:

* 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.

And then:

   A

* 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?

* from 6.1<https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-03#section-6.1>. Address Block Compression:

* from 6.1<https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-03#section-6.1>. Address Block Compression:

* from 6.2<https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-03#section-6.2>. TLVs:

      OLSRv2 [RFC7181<https://tools.ietf.org/html/rfc7181>] is added; but it is not possible, in general, if

Same thing: why?

* 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

   may be used by a protocol using [RFC5444<https://tools.ietf.org/html/rfc5444>].

* 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.

* from 6.4<https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-03#section-6.4>. Automation:

Yes.

Regards,
Stan

Best regards,
Lotte

Am 06.04.2016 um 19:14 schrieb Justin Dean <[email-masked]<mailto:[email-masked]>>:

Justin

-----Original Message-----
From: manet [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Ulrich Herberg
Sent: 05 April 2016 20:08
To: [email-masked]<mailto:[email-masked]>
Subject: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03

*** WARNING ***

Hi,

Best regards
Ulrich

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 18 Apr 2016 11:21:29 +0200

Hi Chris,

IMO the use of 5444 is for implementation purpose or information. So, I
agree with Stan's comment, that this draft is important to progress, but
would nice to add in the draft some examples of use cases of OLSRv2 and
AODVv2 both routing-protocols, or examples of implementation. This will
help the use of 5444 because I think these protocols use 5444 differently
because they have different purposes/advantages. Thanks,

AB

On Mon, Apr 18, 2016 at 10:52 AM, Dearlove, Christopher (UK) <
[email-masked]> wrote:

> I don’t believe we can or should suggest an implementation. That’s not
> what the IETF does, and it would be a hard, probably impossible, sell, to
> the IESG. That the obvious implementation employs an independent parser is
> already said - it may be appropriate to strengthen the words, but this
> second I’m not sure if that’s needed (not got time to check current
> wording).
>
>
>
> *-- *
>
>
>
>
> *From:* manet [mailto:[email-masked]] *On Behalf Of *Stan Ratliff
> *Sent:* 16 April 2016 19:09
> *To:* Christopher Dearlove
> *Cc:* [email-masked]; Christopher Dearlove
> * from *1.2.1*
> <https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-03#section-1.2.1>*.
> Packet/Message Format*:
>
>
>
>       […] a packet
>
> * Regarding *4.2*
> <https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-03#section-4.2>*.
> Packets and Messages:*
>
> * from *4.4*
> <https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-03#section-4.4>*.
> Addresses Require Attributes:*
>
>
>
> 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
>
> * regarding the maps in *4.5*
> <https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-03#section-4.5>*.
> Information Representation:*
>
> * regarding *4.6*
> <https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-03#section-4.6>*.
> TLVs:*
>
> * regarding *5*
> <https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-03#section-5>*.
> Structure:*
>
> represented that. Maybe consider renaming it to „Structure and Flags“ or so?
>
>
>
> * from *6.1*
> <https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-03#section-6.1>*.
> Address Block Compression:*
>
>
>
> * from *6.1*
> <https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-03#section-6.1>*.
> Address Block Compression:*
>
>
>
> * from *6.2*
> <https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-03#section-6.2>*.
> TLVs:*
>
> * 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.
>
>
>
> * regarding *6.3*
> <https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-03#section-6.3>*.
> TLV Values:*
>
> same things as the fourth paragraphs. I’d propose to merge the second into
> the fourth.
>
>
>
> * from *6.4*
> <https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-03#section-6.4>*.
> Automation:*
>
>
>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 18 Apr 2016 09:37:06 +0000

Use cases of routing protocols aren’t the point, this is about the layer they use.

Use cases of that, we have some very fully worked out examples - RFC 6130, RFC 6621, RFC 7181, and, if you want a reactive example, what’s quoted as [G9903] in the draft.

But what’s wanted here is of course to use those to make specific points. Which we do in various places.

From: Abdussalam Baryun [mailto:[email-masked]]
Sent: 18 April 2016 10:21
To: Dearlove, Christopher (UK)
Cc: Stan Ratliff; Christopher Dearlove; Christopher Dearlove; [email-masked]
Subject: Re: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03

*** WARNING ***
IMO the use of 5444 is for implementation purpose or information. So, I agree with Stan's comment, that this draft is important to progress, but would nice to add in the draft some examples of use cases of OLSRv2 and AODVv2 both routing-protocols, or examples of implementation. This will help the use of 5444 because I think these protocols use 5444 differently because they have different purposes/advantages. Thanks,
AB

On Mon, Apr 18, 2016 at 10:52 AM, Dearlove, Christopher (UK) <[email-masked]<mailto:[email-masked]>> wrote:
I don’t believe we can or should suggest an implementation. That’s not what the IETF does, and it would be a hard, probably impossible, sell, to the IESG. That the obvious implementation employs an independent parser is already said - it may be appropriate to strengthen the words, but this second I’m not sure if that’s needed (not got time to check current wording).

From: manet [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Stan Ratliff
Sent: 16 April 2016 19:09
To: Christopher Dearlove
Cc: [email-masked]<mailto:[email-masked]>; Christopher Dearlove
Subject: Re: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03

*** WARNING ***

      […] a packet

      received messages [...]

   or OTHER_NEIGHB TLV.

BASE_TLV

Message:

And then:

   A

Same thing: why?

Yes.

Regards,
Stan

Best regards,
Lotte

Justin

-----Original Message-----
From: manet [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Ulrich Herberg
Sent: 05 April 2016 20:08
To: [email-masked]<mailto:[email-masked]>
Subject: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03

*** WARNING ***

Hi,

Best regards
Ulrich

---

From: Stan Ratliff <[email-masked]>
Date: Mon, 18 Apr 2016 09:08:46 -0400

> second I’m not sure if that’s needed (not got time to check current

(Again, with my Working Group Participant hat on) -

I don't mean to suggest an implementation. At least to me, this is an
architecture (that of an independent parser, with a reliable communications
mechanism to said parser, that deals with logical messages instead of
packets. Is sequencing guaranteed? I'm not sure, to be honest. But once the
independent parser is assumed, engineers also MUST assume that the
transport (and it's the transport for control plane traffic, but not for
data plane traffic), is "owned" by the independent parser.

Which leads me to the other point I'm trying to make (perhaps badly):
 Abstracting the transport away from the control plane *can* effect
protocol design.

I believe both of these points should be addressed in the usage document.

Regards,
Stan

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 18 Apr 2016 13:13:33 +0000

As has been pointed out to me, some implementations don’t do this. If you are building an implementation in a constrained environment, you can build a constrained implementation. And some people have.

So no, it’s not appropriate to specify an independent parser, or require one. Rather you need to design so that when people do, it can be efficient. Which is what we have been doing.

Or in other words, I don’t think this sort of change is appropriate. Quite the contrary.

The key point is that what’s mandated is a multiplexer and a format. But not an independent parser.

From: Stan Ratliff [mailto:[email-masked]]
Sent: 18 April 2016 14:09
To: Dearlove, Christopher (UK)
Cc: Christopher Dearlove; [email-masked]; Christopher Dearlove
Subject: Re: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03

*** WARNING ***

On Mon, Apr 18, 2016 at 4:52 AM, Dearlove, Christopher (UK) <[email-masked]<mailto:[email-masked]>> wrote:
I don’t believe we can or should suggest an implementation. That’s not what the IETF does, and it would be a hard, probably impossible, sell, to the IESG. That the obvious implementation employs an independent parser is already said - it may be appropriate to strengthen the words, but this second I’m not sure if that’s needed (not got time to check current wording).

I don't mean to suggest an implementation. At least to me, this is an architecture (that of an independent parser, with a reliable communications mechanism to said parser, that deals with logical messages instead of packets. Is sequencing guaranteed? I'm not sure, to be honest. But once the independent parser is assumed, engineers also MUST assume that the transport (and it's the transport for control plane traffic, but not for data plane traffic), is "owned" by the independent parser.

Which leads me to the other point I'm trying to make (perhaps badly):  Abstracting the transport away from the control plane *can* effect protocol design.

Regards,
Stan

*** WARNING ***

      […] a packet

      received messages [...]

   or OTHER_NEIGHB TLV.

BASE_TLV

Message:

And then:

   A

Same thing: why?

Yes.

Regards,
Stan

Best regards,
Lotte

Justin

-----Original Message-----
From: manet [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Ulrich Herberg
Sent: 05 April 2016 20:08
To: [email-masked]<mailto:[email-masked]>
Subject: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03

*** WARNING ***

Hi,

Best regards
Ulrich

---

From: Stan Ratliff <[email-masked]>
Date: Mon, 18 Apr 2016 09:17:40 -0400

On Mon, Apr 18, 2016 at 9:13 AM, Dearlove, Christopher (UK) <
[email-masked]> wrote:

> As has been pointed out to me, some implementations don’t do this. If you
> are building an implementation in a constrained environment, you can build
> a constrained implementation. And some people have.
>
>
>
> So no, it’s not appropriate to specify an independent parser, or require
> one. Rather you need to design so that when people do, it can be efficient.
> Which is what we have been doing.
>
>
>

Well, we disagree. This has been a fundamental point of contention for some
of the follow-on protocols attempting to use 5444. and IMO, this has to be
addressed.

> not an independent parser.

How can you mandate a multiplexer, but not an independent parser? This
makes no sense.

Stan

> *From:* Stan Ratliff [mailto:[email-masked]]
> *Sent:* 18 April 2016 14:09
> *To:* Dearlove, Christopher (UK)
> *Cc:* Christopher Dearlove; [email-masked]; Christopher Dearlove

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 18 Apr 2016 15:23:33 +0000

Of course it makes sense - because it’s been done as I noted.

The multiplexer doesn’t actually have to parse messages, it needs to group them into packets. It needs to be able to parse a packet down to “here are the messages” and deliver them. The messages can be simple blobs. For that it needs the message type - conveniently placed up front in the message header to be read - and the message length - ditto. The parsing of the messages is a protocol problem. If just implementing one protocol it could incorporate the parser. If implementing multiple protocols you can create an independent parser. Or you may do the latter even in the former case.

And even if we all implemented independent parsers they can be quite different. As indeed the ones that exist are. Not just merely in API. For example I could turn a message into a set of objects. Or I could provide pointers into the data block that represents the message.  And other approaches.

Sent: 18 April 2016 14:18

*** WARNING ***

On Mon, Apr 18, 2016 at 9:13 AM, Dearlove, Christopher (UK) <[email-masked]<mailto:[email-masked]>> wrote:
As has been pointed out to me, some implementations don’t do this. If you are building an implementation in a constrained environment, you can build a constrained implementation. And some people have.

Well, we disagree. This has been a fundamental point of contention for some of the follow-on protocols attempting to use 5444. and IMO, this has to be addressed.

How can you mandate a multiplexer, but not an independent parser? This makes no sense.

Stan

From: Stan Ratliff [mailto:[email-masked]<mailto:[email-masked]>]
Sent: 18 April 2016 14:09
To: Dearlove, Christopher (UK)
Cc: Christopher Dearlove; [email-masked]<mailto:[email-masked]>; Christopher Dearlove
Subject: Re: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03

*** WARNING ***

Regards,
Stan

*** WARNING ***

      […] a packet

      received messages [...]

   or OTHER_NEIGHB TLV.

BASE_TLV

Message:

And then:

   A

Same thing: why?

Yes.

Regards,
Stan

Best regards,
Lotte

Justin

-----Original Message-----
From: manet [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Ulrich Herberg
Sent: 05 April 2016 20:08
To: [email-masked]<mailto:[email-masked]>
Subject: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03

*** WARNING ***

Hi,

Best regards
Ulrich

---

From: Stan Ratliff <[email-masked]>
Date: Mon, 18 Apr 2016 19:06:04 -0400

> Of course it makes sense - because it’s been done as I noted.

(*Still* speaking as a WG participant):

OK, I get that. It's only minimally interesting (IMO), but I get it.

>
>
> The multiplexer doesn’t actually have to parse messages, it needs to group
> them into packets. It needs to be able to parse a packet down to “here are
> the messages” and deliver them. The messages can be simple blobs. For that
> it needs the message type - conveniently placed up front in the message
> header to be read - and the message length - ditto. The parsing of the
> messages is a protocol problem. If just implementing one protocol it could
> incorporate the parser. If implementing multiple protocols you can create
> an independent parser. Or you may do the latter even in the former case.
>
>
>
> And even if we all implemented independent parsers they can be quite
> different. As indeed the ones that exist are. Not just merely in API. For
> example I could turn a message into a set of objects. Or I could provide
> pointers into the data block that represents the message.  And other
> approaches.
>

And I think we've drifted from my initial ask - that the usage document
better describe the usage of 5444. There's been a lot coming out of the
various threads on this topic - how 5444 changes the relationship between
protocol and interface, whether a parser is implemented or not, etc. The
whole discussion (all of these different threads put together) *begs* for
some additional clarity in the document. I've been (politely) turned away
thus far, but speaking as a WG participant, but - again I stress that this
is interesting, important information, and needs to be addressed in this
document.

Regards,
Stan

> *Sent:* 18 April 2016 14:18
> Well, we disagree. This has been a fundamental point of contention for
> some of the follow-on protocols attempting to use 5444. and IMO, this has
> to be addressed.
>
>
>
>
>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 19 Apr 2016 09:02:32 +0000

I’m afraid I’m not getting the ask here.

We have a whole section 1 on describing the usage of 5444.  In some detail.

What, specifically, is missing - just “explain better” is not helpful.

(I’ve spent much of my time explaining that there is no mandated parser. A few words on that are something that we can add.)

Sent: 19 April 2016 00:06

*** WARNING ***

On Mon, Apr 18, 2016 at 11:23 AM, Dearlove, Christopher (UK) <[email-masked]<mailto:[email-masked]>> wrote:
Of course it makes sense - because it’s been done as I noted.

And I think we've drifted from my initial ask - that the usage document better describe the usage of 5444. There's been a lot coming out of the various threads on this topic - how 5444 changes the relationship between protocol and interface, whether a parser is implemented or not, etc. The whole discussion (all of these different threads put together) *begs* for some additional clarity in the document. I've been (politely) turned away thus far, but speaking as a WG participant, but - again I stress that this is interesting, important information, and needs to be addressed in this document.
Regards,
Stan

*** WARNING ***

Stan

*** WARNING ***

Regards,
Stan

*** WARNING ***

      […] a packet

      received messages [...]

   or OTHER_NEIGHB TLV.

BASE_TLV

Message:

And then:

   A

Same thing: why?

Yes.

Regards,
Stan

Best regards,
Lotte

Justin

-----Original Message-----
From: manet [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Ulrich Herberg
Sent: 05 April 2016 20:08
To: [email-masked]<mailto:[email-masked]>
Subject: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03

*** WARNING ***

Hi,

Best regards
Ulrich

---

From: Lotte Steenbrink <[email-masked]>
Date: Sun, 24 Apr 2016 18:10:44 +0200

Hi Christopher,

> Am 15.04.2016 um 19:49 schrieb Christopher Dearlove <[email-masked]>:
> 
> [email-masked] <mailto:[email-masked]> (iPhone)
> [email-masked] <mailto:[email-masked]> (home)
> 
> On 15 Apr 2016, at 15:18, Lotte Steenbrink <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> Hi all,
>> 

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

> 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 m…

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

> 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.

> 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.
> 

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

> Implementation again, not design.

Misleading wording then, again.

> 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…

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?

> 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.

> I think that's the wrong change. Rather "include" should be "consider“.

Sounds good.

> 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 hav…

I think it actually did :)

> 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.

> I'm not sure I exactly agree, but the ordering in that section could be improved.

That’d be great.

>> the term „the original message creation“ seems a bit ambiguous– does this refer to the message as created by an RFC5444 message builder implementation?

Okay, thanks :)

> 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 quit…

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

>> [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 <[email-masked] <mailto:[email-masked]>>:
>>>