Subject: [manet] #45 (aodvv2): RFC 5498 non-compliance (submitted for Chris Dearlove)

From: "manet issue tracker" <[email-masked]>
Date: Mon, 21 Jul 2014 03:40:17 -0000

#45: RFC 5498 non-compliance (submitted for Chris Dearlove)

 The document is completely noncompliant with the RFC 5444 multiplexing
 mechanism, mandated by RFC 5498 (on the manet port/protocol). It does
 many things that are not within its competence.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-manet-
  [email-masked]  |  [email-masked]
     Type:  defect       |     Status:  new
 Priority:  minor        |  Milestone:
Component:  aodvv2       |    Version:
 Severity:  Active WG    |   Keywords:  RFC 5498
  Document               |
-------------------------+-------------------------------------------------

Ticket URL: <https://tools.ietf.org/wg/manet/trac/ticket/45>
manet <http://tools.ietf.org/manet/>

---

From: "Charles E. Perkins" <[email-masked]>
Date: Sun, 20 Jul 2014 21:32:45 -0700

Hello Chris,

The document states:

>    In its default mode of operation, AODVv2 sends messages using the
>    parameters for port number and IP protocol specified in [RFC5498] to
>    carry protocol packets.  By default, AODVv2 messages are sent with
>    the IP destination address set to the link-local multicast address
>    LL-MANET-Routers [RFC5498] unless otherwise specified. Therefore,
>    all AODVv2 routers MUST subscribe to LL-MANET-Routers [RFC5498] to
>    receiving AODVv2 messages.

So, I suspect the problem lies elsewhere.  Could you point to the
noncompliant part of the AODVv2 specification, and the protocol
mandate for which the AODVv2 specification is noncompliant?

-- 
Regards,
Charlie P.

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 22 Jul 2014 13:02:11 +0200

IMHO The problem is that RFC5444 still does not have a multiplexing
standard in IETF. The way of multiplexing is still just implemented by
OLSRv2 experts but I dont find any standard for multiplexing yet. The
RFC5498 is not for multipexing as I understand it. We already discussed
once that multiplexing is not specified for all RFC5444 formats because it
is general format but RFC5498 is not general.

If I am wrong please point me to an RFC.
AB
On Mon, Jul 21, 2014 at 5:40 AM, manet issue tracker <
[email-masked]> wrote:

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

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 22 Jul 2014 12:24:33 +0000

RFC5444 describes a multiplexing process. It is not required purely in its own terms. But RFC 5498 make it mandatory for any protocol using the port/protocol allocated by that RFC. And the WG has agreed that all routing protocols developed have to be able (at least) to use that port/protocol.

--
Christopher Dearlove
Senior Principal Engineer, Information Assurance Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
[email-masked]<mailto:[email-masked]> | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

From: manet [mailto:[email-masked]] On Behalf Of Abdussalam Baryun
Sent: 22 July 2014 12:02
To: [email-masked]
Cc: [email-masked]
Subject: Re: [manet] #45 (aodvv2): RFC 5498 non-compliance (submitted for Chris Dearlove)

*** 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>.
IMHO The problem is that RFC5444 still does not have a multiplexing standard in IETF. The way of multiplexing is still just implemented by OLSRv2 experts but I dont find any standard for multiplexing yet. The RFC5498 is not for multipexing as I understand it. We already discussed once that multiplexing is not specified for all RFC5444 formats because it is general format but RFC5498 is not general.

If I am wrong please point me to an RFC.
AB
On Mon, Jul 21, 2014 at 5:40 AM, manet issue tracker <[email-masked]<mailto:[email-masked]>> wrote:
#45: RFC 5498 non-compliance (submitted for Chris Dearlove)

  [email-masked]<mailto:[email-masked]>  |  [email-masked]<mailto:[email-masked]>

_______________________________________________
manet mailing list
[email-masked]<mailto:[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: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 22 Jul 2014 12:34:22 +0000

The quoted text is irrelevant to this point.

As has been said many times, packets belong to the multiplexer, messages to the protocol. There are many pieces of text specifying things about packets that are out of the competence of the protocol. I'm afraid I stopped marking them on my copy.

(For exactly how the protocol can interact with packets, see 5444.)

[email-masked] | http://www.baesystems.com

-----Original Message-----
From: Charles E. Perkins [mailto:[email-masked]] 
Sent: 21 July 2014 05:33
To: [email-masked]; [email-masked]; Dearlove, Christopher (UK)
Subject: Re: [manet] #45 (aodvv2): RFC 5498 non-compliance (submitted for Chris Dearlove)

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

Hello Chris,

>    receiving AODVv2 messages.

So, I suspect the problem lies elsewhere.  Could you point to the noncompliant part of the AODVv2 specification, and the protocol mandate for which the AODVv2 specification is noncompliant?

--
Regards,
Charlie P.

---

From: Thomas Heide Clausen <[email-masked]>
Date: Tue, 22 Jul 2014 15:08:28 +0200

I am still, with reference to this document, dismayed to see that there remain abundant references to positional information in address blocks in RFC5444 messages. 

As has been pointed out numerous times, this is inappropriate, positional information cannot be assumed assured and preserved by generic 5444 message generation and parsing code. The first instance of this offense is in Table 1 ...

This has been requested fixed for years now. When will it be fixed?

> On 22 Jul 2014, at 14:24 , Dearlove, Christopher (UK) <[email-masked]> wrote:
> 
> For information regarding Red Flags that you can look out for in emails you receive, click here.
> If you feel the email is suspicious, please follow this process.
> 
> On Mon, Jul 21, 2014 at 5:40 AM, manet issue tracker <[email-masked]> wrote:

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 22 Jul 2014 13:45:33 +0000

Actually, I think there has been some improvement here, but could be improved further. This is at the level of comment I didn't attempt to make, I concentrated on what I considered the most major issues.

IIRC, two TLVs are suggested, one to say "this is A", one to say "this is B". It's assumed there are two addresses, and the one that's not A is B, and vice versal.

Better is to have a single TLV with a  value for A or B. Why? First, it avoids wasting a TLV code point. Second, you can flag A and B with a single multivalue TLV more efficiently than marking A and B. And it's a good idea to mark A and B, because that way you can add additional addresses in an extension, without introducing any problems as to which is A or B with a single TLV. In addition, the practice we introduced in TLV extensions of having a null value (255 UNSPECIFIED is what we used) can help there as well.

One of those things the authors of 5444 etc. would like to do - when they can find some extra hours in a week - is to set out this sort of good practice for 5444 that has been found to be valuable. In this case we have the two principles of (a) always attack a TLV to indicate information, as just doing so from a non-TLVed address precludes various extensions, and (b) when attaching information, null values are good - T:LV extensions discusses why, a lot comes down to that you can't order for more than one or two TLVs at once.

From: Thomas Heide Clausen [mailto:[email-masked]]
Sent: 22 July 2014 14:08
To: Dearlove, Christopher (UK)
Cc: [email-masked]; [email-masked]; manet-ads
Subject: Not just 5498 but also 5444 compliance (was: Re: [manet] #45 (aodvv2): RFC 5498 non-compliance (submitted for Chris Dearlove))

*** WARNING ***

On 22 Jul 2014, at 14:24 , Dearlove, Christopher (UK) <[email-masked]<mailto:[email-masked]>> wrote:

[email-masked]<mailto:[email-masked]> | http://www.baesystems.com<http://www.baesystems.com/>

From: manet [mailto:[email-masked]] On Behalf Of Abdussalam Baryun
Sent: 22 July 2014 12:02
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [manet] #45 (aodvv2): RFC 5498 non-compliance (submitted for Chris Dearlove)

*** WARNING ***

---

From: Thomas Heide Clausen <[email-masked]>
Date: Tue, 22 Jul 2014 15:51:43 +0200

> On 22 Jul 2014, at 15:45 , Dearlove, Christopher (UK) <[email-masked]> wrote:
> 
> Actually, I think there has been some improvement here, but could be improved further. This is at the level of comment I didn’t attempt to make, I concentrated on what I considered the most major issues.

Improvement, I agree, but still *quite* far from to the point where it’s correct.

> IIRC, two TLVs are suggested, one to say “this is A”, one to say “this is B”. It’s assumed there are two addresses, and the one that’s not A is B, and vice versal.
>  
> Better is to have a single TLV with a  value for A or B. Why? First, it avoids wasting a TLV code point. Second, you can flag A and B with a single multivalue TLV more efficiently than marking A and B. And it’s a good idea to mark A and B, because that way you can add additional addresses in an extension, without introducing any problems as to which is A or B with a single TLV. In addition, the practice we introduced in TLV extensions of having a null value (255 UNSPECIFIED is what we used) can help there as well.

Yes, and while important, the above is a design detail that is relatively easy to hammer out, when all else is completed.
 
> One of those things the authors of 5444 etc. would like to do – when they can find some extra hours in a week – is to set out this sort of good practice for 5444 that has been found to be valuable. In this case we have the two principles of (a) always attack a TLV to indicate information, as just doing so from a non-TLVed address precludes various extensions, and (b) when attaching information, null values are good – T:LV extensions discusses why, a lot comes down to that you can’t order for more than one or two TLVs at once.

Yes, and with the caveat that one of the 5444 authors is trying to find some hours this week for that, so that may be forthcoming soon.

(See, Chris, now you made me go public with this, so I’m kinda on the hook for producing something….)

Thomas

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 22 Jul 2014 13:56:26 +0000

I think we’ve said something like that before.

But just to make Thomas’s workload even greater, there are many details of 5444, NHDP and OLSRV2 that the authors would like to provide rationale material for. We’ve done it once, for metrics. But it really is something that’s hard to find time to do, because it’s just a good idea, rather than being essential.

From: Thomas Heide Clausen [mailto:[email-masked]]
Sent: 22 July 2014 14:52
To: Dearlove, Christopher (UK)
Cc: [email-masked]; manet-ads; [email-masked]
Subject: Re: [manet] Not just 5498 but also 5444 compliance (was: Re: #45 (aodvv2): RFC 5498 non-compliance (submitted for Chris Dearlove))

*** WARNING ***

On 22 Jul 2014, at 15:45 , Dearlove, Christopher (UK) <[email-masked]<mailto:[email-masked]>> wrote:

Thomas

From: Thomas Heide Clausen [mailto:[email-masked]]
Sent: 22 July 2014 14:08
To: Dearlove, Christopher (UK)
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; manet-ads
Subject: Not just 5498 but also 5444 compliance (was: Re: [manet] #45 (aodvv2): RFC 5498 non-compliance (submitted for Chris Dearlove))

*** WARNING ***

*** WARNING ***

---

From: Thomas Heide Clausen <[email-masked]>
Date: Tue, 22 Jul 2014 15:59:18 +0200

> On 22 Jul 2014, at 15:56 , Dearlove, Christopher (UK) <[email-masked]> wrote:
> 
> But just to make Thomas’s workload even greater,

Oh, sure, I didn’t plan on sleeping, or having a social life, anyways ;)

Thomas

---

From: Henning Rogge <[email-masked]>
Date: Tue, 22 Jul 2014 16:05:24 +0200

On 07/22/2014 03:51 PM, Thomas Heide Clausen wrote:
>> One of those things the authors of 5444 etc. would like to do – when
>> they can find some extra hours in a week – is to set out this sort of
>> good practice for 5444 that has been found to be valuable. In this
>> case we have the two principles of (a) always attack a TLV to indicate
>> information, as just doing so from a non-TLVed address precludes
>> various extensions, and (b) when attaching information, null values
>> are good – T:LV extensions discusses why, a lot comes down to that you
>> can’t order for more than one or two TLVs at once.
> 
> Yes, and with the caveat that one of the 5444 authors is trying to find
> some hours this week for that, so that may be forthcoming soon.
> 

I would also be interested in doing this, mostly because a lot of these
assumptions (how to do RFC5444) have been put into the design of my
RFC5444 parser/generator API.

The generator API supports that multiple parts of the program are
multiplexing data into the same message, so there is no reliable way to
guarantee the position of addresses and TLVs within the message.

Documenting these 'best practices' would be helpful for further protocol
designers.

Henning Rogge

-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Fraunhofer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:[email-masked] http://www.fkie.fraunhofer.de

---

From: Thomas Heide Clausen <[email-masked]>
Date: Tue, 22 Jul 2014 16:08:41 +0200

> On 22 Jul 2014, at 16:05 , Henning Rogge <[email-masked]> wrote:
> 

Absolutely, and we (well, at least, I) count on looping you in on this process.

Cheers,

Thomas

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 22 Jul 2014 14:25:36 +0000

I'm expecting to be contributing as an author here, and your input will be valuable here.

I'm not sure how far this document will get (it's effort limited as has been said). If we get to an abstract representation of 5444 information (we may or may not) then I'm aware of at least two approaches with advantages or disadvantages. Roughly speaking, one is iterator based, one is map based, with different tradeoffs (and preserving slightly different information). However I don't think we should specify an API here. Publication of an API separately (ID or software documentation) could well be useful. 

-----Original Message-----
From: manet [mailto:[email-masked]] On Behalf Of Thomas Heide Clausen
Sent: 22 July 2014 15:09
To: Henning Rogge
Cc: [email-masked]
Subject: Re: [manet] Not just 5498 but also 5444 compliance

>>> One of those things the authors of 5444 etc. would like to do - when 
>>> they can find some extra hours in a week - is to set out this sort 
>>> of good practice for 5444 that has been found to be valuable. In 
>>> this case we have the two principles of (a) always attack a TLV to 
>>> indicate information, as just doing so from a non-TLVed address 
>>> precludes various extensions, and (b) when attaching information, 
>>> null values are good - T:LV extensions discusses why, a lot comes 
>>> down to that you can't order for more than one or two TLVs at once.
>> 
>> Yes, and with the caveat that one of the 5444 authors is trying to 
>> find some hours this week for that, so that may be forthcoming soon.
>> 
>> (See, Chris, now you made me go public with this, so I'm kinda on the 
>> hook for producing something..)
> 
> I would also be interested in doing this, mostly because a lot of 
> these assumptions (how to do RFC5444) have been put into the design of 
> my
> multiplexing data into the same message, so there is no reliable way 
> to guarantee the position of addresses and TLVs within the message.
> 
> Documenting these 'best practices' would be helpful for further 
> protocol designers.
> 

Cheers,

Thomas

> Kommunikationssysteme (KOM) Fraunhofer Straße 20, 53343 Wachtberg, 
> Germany

---

From: Thomas Heide Clausen <[email-masked]>
Date: Tue, 22 Jul 2014 16:40:07 +0200

> On 22 Jul 2014, at 16:25 , Dearlove, Christopher (UK) <[email-masked]> wrote:
> 

And I’m sitting here with Ulrich, and in part hammering ideas out for these, and we’re all in agreement also.  
Y’all have been implementing 5444 parser/generators, and so that seems exactly the experience necessary for these efforts.

> I'm not sure how far this document will get (it's effort limited as has been said). If we get to an abstract representation of 5444 information (we may or may not) then I'm aware of at least two ap…

Absolutely. Right now, as I said, we’re just hammering out ideas — any thoughts like these (or others) from folks having built 5444 parsers/generators appreciated

Thomas

---

From: Henning Rogge <[email-masked]>
Date: Tue, 22 Jul 2014 17:25:26 +0200

On Tue, Jul 22, 2014 at 4:25 PM, Dearlove, Christopher (UK)
<[email-masked]> wrote:
> I'm not sure how far this document will get (it's effort limited as has been said). If we get to an abstract representation of 5444 information (we may or may not) then I'm aware of at least two approaches with advantages or disadvantages.

fun fact about my parser API... there are TWO ways to get TLVs (and
the attached context) with my API.

One is similar to a XML SAX parser... you get a callback for each
hierarchy that opens/closes and one for each object inside. This is
useful for parsing incoming data without knowing the structure.
The other one uses a predefined array of TLVs (for either packet,
message or address level) your code is interested in . With this
method you get all the relevant TLVs at once instead of one by one.

> Roughly speaking, one is iterator based, one is map based, with different tradeoffs (and preserving slightly different information). However I don't think we should specify an API here. Publication of an API separately (ID or software documentation) could well be useful.

I agree, specifying a fixed API sounds bad... and before I would
consider publishing "my" API as an ID I would really need some review
of it.

Henning Rogge

---

From: Justin Dean <[email-masked]>
Date: Tue, 22 Jul 2014 11:30:16 -0400

Count me in on the effort as well.  We should take note that it isn't just
about how best to compact a packetbb message with multiple tlv values of
different protocol types (and there are different ways and tradeoffs).  It
should also be about the design of the format and best practices for
designing messages, tlvs, and assigning values.  Having a what not to do
and why section would also be helpful.

Justin

On Tue, Jul 22, 2014 at 10:40 AM, Thomas Heide Clausen <
[email-masked]> wrote:

> Y’all have been implementing 5444 parser/generators, and so that seems
> exactly the experience necessary for these efforts.
>
> > I'm not sure how far this document will get (it's effort limited as has
> been said). If we get to an abstract representation of 5444 information (we
> may or may not) then I'm aware of at least two approaches with advantages
> or disadvantages. Roughly speaking, one is iterator based, one is map
> based, with different tradeoffs (and preserving slightly different
> information). However I don't think we should specify an API here.
> Publication of an API separately (ID or software documentation) could well
> be useful.
>
> Absolutely. Right now, as I said, we’re just hammering out ideas — any
> thoughts like these (or others) from folks having built 5444
> parsers/generators appreciated
>
> Thomas
>
> >
> > --
> > Christopher Dearlove
> > ----------------------! WARNING ! ---------------------- This message
> originates from outside our organisation, either from an external partner
> or from the internet.
> > Follow the 'Report Suspicious Emails' link on IT matters for
> instructions on reporting suspicious email messages.

---

From: Thomas Heide Clausen <[email-masked]>
Date: Tue, 22 Jul 2014 17:34:39 +0200

> On 22 Jul 2014, at 17:30 , Justin Dean <[email-masked]> wrote:
> 
> Count me in on the effort as well.  We should take note that it isn't just about how best to compact a packetbb message with multiple tlv values of different protocol types (and there are different ways and tradeoffs).  It should also be about the design of the format and best practices for designing messages, tlvs, and assigning values.  Having a what not to do and why section would also be helpful.
> 

Actually, it is not at all about how to best compact a 5444-message. That’s interesting, but for a different I-D (which I hope that someone will write).

This effort is about the design of the format, how to use it in ways that enable generic parsing and generation machinery, and — as you say — best practices (including for managing the code-point spaces).

I’m actually starting to think that there’re two documents here, a 5444-rationale, and a 5444-usage — different, but probably both very interesting.

Thomas

> Justin
> 
> 
> On Tue, Jul 22, 2014 at 10:40 AM, Thomas Heide Clausen <[email-masked]> wrote:
>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 22 Jul 2014 15:51:09 +0000

I think principles are what should be considered first. There are some principles that do have a non-zero overhead, but make various other things possible and thus are wanted.

For efficiency, this is hard – and also quality of implementation here could be a selling point. But TLV extensions contains some features that should (effort permitting) be called out and exampled (if that’s a word).

From: Justin Dean [mailto:[email-masked]]
Sent: 22 July 2014 16:30
To: Thomas Heide Clausen
Cc: Dearlove, Christopher (UK); [email-masked]
Subject: Re: [manet] Not just 5498 but also 5444 compliance

*** WARNING ***

Justin

On Tue, Jul 22, 2014 at 10:40 AM, Thomas Heide Clausen <[email-masked]<mailto:[email-masked]>> wrote:

> On 22 Jul 2014, at 16:25 , Dearlove, Christopher (UK) <[email-masked]<mailto:[email-masked]>> wrote:
>

Thomas

> Tel: +44 1245 242194<tel:%2B44%201245%20242194> |  Fax: +44 1245 242124<tel:%2B44%201245%20242124>
> From: manet [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Thomas Heide Clausen
> Sent: 22 July 2014 15:09
> To: Henning Rogge
> Cc: [email-masked]<mailto:[email-masked]>
>> On 22 Jul 2014, at 16:05 , Henning Rogge <[email-masked]<mailto:[email-masked]>> wrote:
>>
>> Telefon +49 228 9435-961<tel:%2B49%20228%209435-961>,   Fax +49 228 9435 685<tel:%2B49%20228%209435%20685>
>> mailto:[email-masked]<mailto:[email-masked]> http://www.fkie.fraunhofer.de
>>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 22 Jul 2014 15:55:00 +0000

I think there’s some overlap. For example the principle that if you create an address block TLV whose values enumerate meanings that an unspecified value is a good thing to have (RFC 7188) is for efficiency reasons. Explaining why gets you a bit into 5444 compaction.

Sent: 22 July 2014 16:35
To: Justin Dean

*** WARNING ***

On 22 Jul 2014, at 17:30 , Justin Dean <[email-masked]<mailto:[email-masked]>> wrote:

Thomas

Justin

Thomas

>> mailto:[email-masked]<mailto:[email-masked]> http://www.fkie.fraunhofer.de<http://www.fkie.fraunhofer.de/>
>>

---

From: Charlie Perkins <[email-masked]>
Date: Tue, 22 Jul 2014 09:09:00 -0700

Hello Chris,

While RFC 5444 is mandated for [manet], and thus AODVv2 must be
in compliance, it is my experience that RFC 5444 was not at all designed
for reactive protocols.  If there is going to be a new RFC 5444, it should
also include some consideration about how to fix this problem.

To restrict other protocols on the basis of something clever about
a supposedly "better" packet format's parser is putting the cart before
the horse.

In the meantime, it would exacerbate an already unfortunate situation
to place additional RFC 5444 mandates without consideration of the
needs of non-proactive protocols.  RFC 5444 seems to be all about how
to condense the representation of otherwise interchangeable IP
addresses. It has been made more difficult to include attach information
to specific IP addresses because that makes them non-interchangeable
in the AddrBlks.  This point of view becomes more or less irrelevant
(even counterproductive) when there are only one or two addresses in
the AddrBlks.

Given the number of comments made regarding issues with AODVv2,
I don't think I can be much help with the process of reconsidering
RFC 5444 right now, but in the future I would be very happy to do so.

Also, please note that this *should* *not* be construed to mean that I
do not intend AODVv2 to be conformant to RFC 5444.  However, if all of
a sudden there were recognition within the working group that RFC 5444
does place very significant (and, I think, undesirable) design constraints
on protocol design, I would be very happy to go back to the way things
were before.  Right now I do not have time to take up that cause.
//
Regards,
Charlie P.

On 7/22/2014 6:45 AM, Dearlove, Christopher (UK) wrote:
>
> Actually, I think there has been some improvement here, but could be 
> improved further. This is at the level of comment I didn't attempt to 
> make, I concentrated on what I considered the most major issues.
>
> IIRC, two TLVs are suggested, one to say "this is A", one to say "this 
> is B". It's assumed there are two addresses, and the one that's not A 
> is B, and vice versal.
>
> Better is to have a single TLV with a  value for A or B. Why? First, 
> it avoids wasting a TLV code point. Second, you can flag A and B with 
> a single multivalue TLV more efficiently than marking A and B. And 
> it's a good idea to mark A and B, because that way you can add 
> additional addresses in an extension, without introducing any problems 
> as to which is A or B with a single TLV. In addition, the practice we 
> introduced in TLV extensions of having a null value (255 UNSPECIFIED 
> is what we used) can help there as well.
>
> One of those things the authors of 5444 etc. would like to do -- when 
> they can find some extra hours in a week -- is to set out this sort of 
> are good -- T:LV extensions discusses why, a lot comes down to that 
> you can't order for more than one or two TLVs at once.
>
> -- 
>
> Christopher Dearlove
>
> [email-masked] <mailto:[email-masked]> | 
> http://www.baesystems.com
>
> *From:*Thomas Heide Clausen [mailto:[email-masked]]
> *Sent:* 22 July 2014 14:08
> *To:* Dearlove, Christopher (UK)
> *Cc:* [email-masked]; [email-masked]; manet-ads
> *Subject:* Not just 5498 but also 5444 compliance (was: Re: [manet] 
> #45 (aodvv2): RFC 5498 non-compliance (submitted for Chris Dearlove))
>
> **** 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>.//
>
> I am still, with reference to this document, dismayed to see that 
> there remain abundant references to positional information in address 
> blocks in RFC5444 messages.
>
> As has been pointed out numerous times, this is inappropriate, 
> positional information cannot be assumed assured and preserved by 
> generic 5444 message generation and parsing code. The first instance 
> of this offense is in Table 1 ...
>
>     On 22 Jul 2014, at 14:24 , Dearlove, Christopher (UK)
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>     RFC5444 describes a multiplexing process. It is not required
>     purely in its own terms. But RFC 5498 make it mandatory for any
>     protocol using the port/protocol allocated by that RFC. And the WG
>     has agreed that all routing protocols developed have to be able
>     (at least) to use that port/protocol.
>
>     --
>
>     Christopher Dearlove
>
>     [email-masked]
>     <mailto:[email-masked]>|http://www.baesystems.com
>     <http://www.baesystems.com/>
>
>     *From:*manet [mailto:[email-masked]]*On Behalf
>     Of*Abdussalam Baryun
>     *Sent:*22 July 2014 12:02
>     *To:[email-masked] <mailto:[email-masked]>
>     *Cc:[email-masked]
>     <mailto:[email-masked]>
>     *Subject:*Re: [manet] #45 (aodvv2): RFC 5498 non-compliance
>     (submitted for Chris Dearlove)
>
>     **** 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>.//
>
>     IMHO The problem is that RFC5444 still does not have a
>     multiplexing standard in IETF. The way of multiplexing is still
>     just implemented by OLSRv2 experts but I dont find any standard
>     for multiplexing yet. The RFC5498 is not for multipexing as I
>     understand it. We already discussed once that multiplexing is not
>     specified for all RFC5444 formats because it is general format but
>     RFC5498 is not general.
>
>     On Mon, Jul 21, 2014 at 5:40 AM, manet issue tracker
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>     [email-masked] <mailto:[email-masked]> |
>     [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 22 Jul 2014 16:27:58 +0000

This is a WG document, not just your private document, and I'm pointing out how it can be better. And not at a significant efficiency cost. But you will note this wasn't on my list of major issues, this was on the list I haven't got to. I only mentioned it as relevant to someone else's point.

As for your last point, that's implying a totally unacceptable option.

It has been agreed by the WG, and defined in Proposed Standards, that
- MANET WG routing protocols shall be able to use the manet port/protocol.
- RFC 5498 mandates that anything using that port/protocol shall use not just RFC 5444, but the RFC 5444 multiplexer.
- The separation out of the RFC 5444 format as not just for OLSRv2 (including the also then not split out NHDP) was also a WG imposed requirement.

On that last point, given that RFC 5498 was (inexplicably to me) accepted before RFC 5444, the IESG insisted that RFC 5444 contain a specification of the multiplexing mechanism that RFC 5498 had imposed on it. And RFC 5498 was authored by your then DYMO co-author. He obviously didn't feel it couldn't cope with reactive protocols.

As for there being too many issues with AODVv2, yes, there are too many issues with AODVv2. That's the problem. The solution is not to ignore them, but to fix them (the WG having taken the decision not to restart from a document with fewer issues).

As for the only two addresses, you're imposing a restriction on any future extension that might want to report an address for another reason. I don't think that is a good idea.

From: Charlie Perkins [mailto:[email-masked]] 
Sent: 22 July 2014 17:09
To: Dearlove, Christopher (UK)
Cc: [email-masked]; manet-ads
Subject: Please, no more RFC 5444 mandates right now...

*** WARNING ***

Hello Chris,

Regards,
Charlie P.

 

 

*** WARNING ***

 

 

*** WARNING ***

---

From: Thomas Clausen <[email-masked]>
Date: Tue, 22 Jul 2014 12:32:07 -0400

> On 22 Jul 2014, at 12:09, Charlie Perkins <[email-masked]> wrote:
> 
> 
> Hello Chris,
> 
> for reactive protocols. 

The above is a glaringly incorrect statement.

When RFC5444 was designed, it was with substantial input from Ian Chakeres and Charlie E. Perkins, so as to ensure that it was suitable also for their reactive protocol designs. 

Furthermore, I actually have co-designed a fairly successful (as in: deployed very widely) reactive protocol, using RFC5444 -- and that, without the slightest of problems.

> If there is going to be a new RFC 5444, it should

There is no problem with RFC5444.

There may be a problem with how you are using RFC5444, or how you are understanding RFC5444.

That problem-of-using and problem-of-understanding is what these documents are intended to address,

> a supposedly "better" packet format's parser is putting the cart before

In which way? 

> in the AddrBlks. 

This is a good example of how you are misunderstanding RFC5444. Attributes associated with addresses is indeed possible, and greatly facilitated in RFC5444, by that association being by way of TLVs.

It is even easier to come up with a new protocol since if you already have an RFC5444 packet generator/parser, then you can reuse it unmodified.

That greatly simplifies making protocol extensions, or making new protocols.

It would be a radically unfortunate situation to *not* support modularity and generic components.

> This point of view becomes more or less irrelevant

No, not really.

> RFC 5444 right now, but in the future I would be very happy to do so.

There are no plans for reconsidering RFC5444.

> were before. 

I think that you are profoundly misunderstanding things here.

The "constraints" that you talk about serve - successfully - to ensure modularity, extensibility, flexibility and reuse -- between multiple different protocols.

As indicated, I have co-designed reactive protocols using RFC5444, and not only was it possible, it was simple and efficient.

And, by re-using the 5444-parser from my OLSRv2 implementation without modifications, it allowed extremely snappy development of prototype -- and later running -- code,

Thomas

> Right now I do not have time to take up that cause.
> 
> Regards,
> Charlie P.
> 
> 
>

---

From: Thomas Clausen <[email-masked]>
Date: Tue, 22 Jul 2014 12:43:37 -0400

Couple of comments...

> On 22 Jul 2014, at 12:27, "Dearlove, Christopher (UK)" <[email-masked]> wrote:
> 

It's just worth recalling that reviews to the reactive protocol have been posted on the mailing list since the Maastricht IETF, and that these largely have gone unanswered and unaddressed by the authors -- even to this day.

> As for your last point, that's implying a totally unacceptable option.

Agreed.

> - The separation out of the RFC 5444 format as not just for OLSRv2 (including the also then not split out NHDP) was also a WG imposed requirement.

Yes.

> On that last point, given that RFC 5498 was (inexplicably to me) accepted before RFC 5444, the IESG insisted that RFC 5444 contain a specification of the multiplexing mechanism that RFC 5498 had im…

To this point, one of the ideas of these new documents that we're working on is also to clarify that slight oddity which the "reverse order" of 5498 and 5444 caused -- but not to obsolete or update 5444 or 5498.

> As for there being too many issues with AODVv2, yes, there are too many issues with AODVv2. That's the problem. The solution is not to ignore them, but to fix them (the WG having taken the decision…

A frustrating bit here is, though, that even though issues have been pointed out "many draft revisions ago", they still appear in the current version.

Another frustrating bit here is, that the current revision introduces sizable new text, which introduces a good deal of new issues, while not resolving any of those having been raised previously.

Thomas

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 22 Jul 2014 18:44:40 +0200

So I understand from your message that there is no mandate of multiplexing
method or specific format method. 5498 defines port/protocol for such
format.

Usually messages, formats, packets, and multiplex, are not more important
than the AODVv2 protocol function, so usually we set function then the
messaging and then multiplexing. IMHO it was not right that this WG spend
lot of effort and years to do RFC5444 before completing its two basic
standards (reactive and proactive), but it is ok if we make priority to
the standards function.

AB

On Tuesday, July 22, 2014, Dearlove, Christopher (UK) wrote:

>  RFC5444 describes a multiplexing process. It is not required purely in
> its own terms. But RFC 5498 make it mandatory for any protocol using the
> port/protocol allocated by that RFC. And the WG has agreed that all routing
> protocols developed have to be able (at least) to use that port/protocol.
>
>
>
> --
>
> Christopher Dearlove
>
> <javascript:_e(%7B%7D,'cvml',[email-masked]');> |
> *From:* manet [mailto:[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>] *On Behalf Of *Abdussalam
> Baryun
> *Sent:* 22 July 2014 12:02
> *To:* [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
> *Cc:* [email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>
> *Subject:* Re: [manet] #45 (aodvv2): RFC 5498 non-compliance (submitted
> for Chris Dearlove)
>
>
>
>
>
> **** 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>.*
>
> [email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
>   [email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>  |
> [email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>
> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>

---

From: Thomas Clausen <[email-masked]>
Date: Tue, 22 Jul 2014 12:45:16 -0400

And, one very specific comment...

> On 22 Jul 2014, at 12:27, "Dearlove, Christopher (UK)" <[email-masked]> wrote:
<SNIP>

> As for the only two addresses, you're imposing a restriction on any future extension that might want to report an address for another reason. I don't think that is a good idea.

Also, I haste to point out, there are good uses for -- in a reactive protocol with multiple addresses on multiple interfaces -- being able to include more than two addresses in the various messages.

This, even, before starting to think about extensions -- where, obviously, this is very true as Chris state.

Thomas

---

From: Thomas Clausen <[email-masked]>
Date: Tue, 22 Jul 2014 12:49:39 -0400

> On 22 Jul 2014, at 11:25, Henning Rogge <[email-masked]> wrote:
> 

With that being said....at some point, it would be fun to get you to come to an IETF, and present not a protocol, but exactly your parser/generator. Running code, and all that...

Thomas

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 22 Jul 2014 16:51:18 +0000

You have managed to read the exact opposite of what I wrote. I suggest reading the RFCs.

From: manet [mailto:[email-masked]] On Behalf Of Abdussalam Baryun
Sent: 22 July 2014 17:45
To: Dearlove, Christopher (UK)
Cc: [email-masked]; [email-masked]
Subject: Re: [manet] #45 (aodvv2): RFC 5498 non-compliance (submitted for Chris Dearlove)

*** WARNING ***
So I understand from your message that there is no mandate of multiplexing method or specific format method. 5498 defines port/protocol for such format.

Usually messages, formats, packets, and multiplex, are not more important than the AODVv2 protocol function, so usually we set function then the messaging and then multiplexing. IMHO it was not right that this WG spend lot of effort and years to do RFC5444 before completing its two basic standards (reactive and proactive), but it is ok if we make priority to the standards function.

AB

[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');> | http://www.baesystems.com

From: manet [mailto:[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>] On Behalf Of Abdussalam Baryun
Sent: 22 July 2014 12:02
To: [email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>
Cc: [email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>
Subject: Re: [manet] #45 (aodvv2): RFC 5498 non-compliance (submitted for Chris Dearlove)

*** WARNING ***

If I am wrong please point me to an RFC.
AB
On Mon, Jul 21, 2014 at 5:40 AM, manet issue tracker <[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
#45: RFC 5498 non-compliance (submitted for Chris Dearlove)

  [email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>  |  [email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>

_______________________________________________
manet mailing list
[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>
https://www.ietf.org/mailman/listinfo/manet

---

From: Charlie Perkins <[email-masked]>
Date: Tue, 22 Jul 2014 10:18:55 -0700

Hello Chris,

> - RFC 5498 mandates that anything using that port/protocol shall use not just RFC 5444, but the RFC 5444 multiplexer.

As I have agreed many times, you have correctly characterized the world
in which [manet] participants find themselves.

> On that last point, given that RFC 5498 was (inexplicably to me) accepted before RFC 5444, the IESG insisted that RFC 5444 contain a specification of the multiplexing mechanism that RFC 5498 had im…

Well, his RFC 5444 co-existence design was quite thoroughly
disparaged by RFC 5444 proponents.  It seems that he didn't
really understood all the implications of his participation in that.

> As for there being too many issues with AODVv2, yes, there are too many issues with AODVv2. That's the problem. The solution is not to ignore them, but to fix them (the WG having taken the decision…

This is twisting my words.  I have a lot of issues to address.  You may
say that even one single issue is "too many".  You certainly should not
make any implication that I have been ignoring them.

> As for the only two addresses, you're imposing a restriction on any future extension that might want to report an address for another reason. I don't think that is a good idea.

Hmm... well let me see.  We need the IP address of a router *wanting* a 
route
to a destination, and we need the IP address of that destination. That's 
what is
needed for route discovery.  Do you see the need for more addresses here?

As a contrasting example, RERR can have many IP addresses, and they are
to some degree interchangeable.  The RFC 5444 model is suitable for that.

> This is a WG document, not just your private document,

Chris: this is not constructive, and in no way do I consider this
document as my private document.

Regards,
Charlie P.

---

From: "manet issue tracker" <[email-masked]>
Date: Tue, 22 Jul 2014 18:09:58 -0000

Changes (by [email-masked]):

 * owner:  [email-masked] => [email-masked]

-- 
-----------------------------------+------------------------------------
 Reporter:  [email-masked]  |       Owner:  [email-masked]
     Type:  defect                 |      Status:  new
 Priority:  minor                  |   Milestone:
Component:  aodvv2                 |     Version:
 Severity:  Active WG Document     |  Resolution:
 Keywords:  RFC 5498               |
-----------------------------------+------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/manet/trac/ticket/45#comment:1>
manet <http://tools.ietf.org/manet/>

---

From: Christopher Dearlove <[email-masked]>
Date: Tue, 22 Jul 2014 19:52:59 +0100

> in which [manet] participants find themselves.

Chose to be in, not "find themselves". And which AODVv2 does not match.

> really understood all the implications of his participation in that.

I don't recall things the way you do.

> make any implication that I have been ignoring them.

See the subject line of this email.

> Hmm... well let me see.  We need the IP address of a router *wanting* a route
> to a destination, and we need the IP address of that destination. That's what is

Planning any intermediate replies? Completely ruled out any route accumulation? No possibiity of including blacklisting information? Thought of every possibility someone else might?

> document as my private document.

I'd like too see more from your co-authors, it is appearing as a one person process.

---

From: Henning Rogge <[email-masked]>
Date: Wed, 23 Jul 2014 13:03:47 +0200

> With that being said....at some point, it would be fun to get you to come to an IETF, and present not a protocol, but exactly your parser/generator. Running code, and all that...

The only thing I am sure about this is that it would not fit into a
timeslot of the MANET WG meeting... *G*

Henning Rogge