Subject: [manet] packetbb update idea

From: Justin Dean <[email-masked]>
Date: Mon, 3 Jul 2017 13:29:13 -0400

So while trying to encode some information using packetbb for the elastic
multicast stuff we have been working on I've run into a short coming.
RFC5444 allows one to efficiently encode information about addresses and
even pairs of addresses (as long as one of those addresses is the Oaddr)
with the TLV structure and the address block.  It does not allow for easy
encoding about pairs of addresses of which neither is the Oaddr.  After
some thinking on it I think most of what I'd like to be able to do could be
solved by using the RESERVED tlv flag bit number 6 to indicate inclusion of
a single index field <index-opt> which would specify a single address in
the address block.
So the tlv definition would change from
<tlv> := <tlv-type>

                <tlv-flags>
                <tlv-type-ext>?
                (<index-start><index-stop>?)?
                (<length><value>?)?

to

<tlv> := <tlv-type>
                <tlv-flags>
                <tlv-type-ext>?

                <index-opt>?
                (<index-start><index-stop>?)?
                (<length><value>?)?

This would allow one to specify information about pairs of addresses in a
compact way.  In the case of elastic multicast source/destination flow
pairs. Thoughts welcome.

Justin

---

From: Henning Rogge <[email-masked]>
Date: Mon, 3 Jul 2017 19:41:46 +0200

On Mon, Jul 3, 2017 at 7:29 PM, Justin Dean <[email-masked]> wrote:
> encoding about pairs of addresses of which neither is the Oaddr.  After some
> thinking on it I think most of what I'd like to be able to do could be
> a single index field <index-opt> which would specify a single address in the
> address block.

You mean for things like source-specific routing (having a source- and
destination prefix for an attached network)?

I remember I did a rough sketch for this (I have implemented in my
Olsrd2-Implementation) and I was forced to put one of the addresses
uncompressed into a data TLV.

> compact way.  In the case of elastic multicast source/destination flow

IF (not sure it is worth) we add something to RFC5444, I would also
like to suggest an option in the address block TLVs to refer to the
originator address as the prefix/postfix part.

Henning

---

From: Justin Dean <[email-masked]>
Date: Mon, 3 Jul 2017 14:36:46 -0400

On Mon, Jul 3, 2017 at 1:41 PM, Henning Rogge <[email-masked]> wrote:

> some
> the
> Yes it could work for that.  I did the same thing when I started to sketch
out a layout that worked with RFC5444.  Having the extra index instead of
including the full address saves a bunch of space when transmitting a lot
of pairwise information. 1 byte instead of 16 when working with ipv6.

> originator address as the prefix/postfix part.

Hmm.  I could see how that might reduce some overhead although the
originator being optional may make that a little bit tricky.  I'm open to
the idea.

One other thing I think might be nice is an address block block.  It would
be a simple container (or an implied container but I think that could get
ugly) for address blocks so different similar addresses could be compressed
but share an indexing scheme.

---

From: Henning Rogge <[email-masked]>
Date: Mon, 3 Jul 2017 20:56:13 +0200

On Mon, Jul 3, 2017 at 8:36 PM, Justin Dean <[email-masked]> wrote:
> including the full address saves a bunch of space when transmitting a lot of
> pairwise information. 1 byte instead of 16 when working with ipv6.

why not add a single TLV with 1 byte (multivalue) for all addresses?
This would give you the second index with just a constant overhead (2
bytes? 3?) per address block.

> but share an indexing scheme.

Hmm...

Henning

---

From: Christopher Dearlove <[email-masked]>
Date: Mon, 3 Jul 2017 20:51:46 +0100

I'm strongly in favour of doing what you can with what you've got unless the need is critical, because of all the upgrade, compatibility and specification issues that a change entails. Particularly as the last posting we just saw was two compatible implementations being discussed/announced.

My first thoughts run along Henning's lines, but before I get to that, what's the use case? What would we want to apply to two addresses? If two why not three? Or more. You can signal source/destination with a TLV with values source, destination, unspecified. Which is improved in efficiency if the addresses are close to each other. And that allows all sorts of generalisations.

--  
Christopher Dearlove
[email-masked]

> On 3 Jul 2017, at 19:56, Henning Rogge <[email-masked]> wrote:
> 
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: Justin Dean <[email-masked]>
Date: Mon, 3 Jul 2017 15:59:24 -0400

> bytes? 3?) per address block.

Not sure I'm understanding what your suggesting or I'm not clearly
expressing myself.  An example.  I want to encode a graph structure in
RFC5444.
I have 4 addresses in the following configuration.

A-----B
|    /|
|   / |
|  /  |
| /   |
|/    |
C-----D

With current RFC5444 assuming I'm 1 I could do something like.
address block <B,C,D>
originator address A
TLV (link to oAddr) index B,C.  This would indicate A-B, A-C
TLV (link to address in the value field)  index addresses B,C with TLV
value field of address D.  This would indicate B-D and C-D.
TLV (link to address in the value field) index address B with TLV value
field of address C.  this would indicate B-C
This wouldn't be so bad except that the value field has to include the full
address D and C instead of just indexing them.  It also makes the value
field encoding messy if you start adding metric values to the links.

With the optional address using included (using bit 6) it would allow for
TLV association between two addresses without actually fully including one
of those addresses in the value field.

This is just an example but there we have both encountered encoding
problems in which we wanted to associate addresses in the address block
somehow, often with a metric or value associated with it.  This is a way
that would allow us to do so cleanly.  Their may be other ways too.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 4 Jul 2017 08:51:07 +0000

As you indicate, that takes multiple TLVs. You can do it with a single TLV (and even indicate directionality, should you want to) by using a multivalue TLV with a bit vector single value. That’s a definite saving in that case.

Really, theirs is a major overhead in introducing a change, it’s a lot more than simply updating 5444. For a start the existing protocols reference version 0. But if the update is to be of any application, do they need updating? And then we have compatibility issues over existing implementations - and we just had a report of an interoperability case. And more. It really has to be a compelling case, and this wouldn’t be that even if the alternative were slightly more inefficient. But it’s not - it’s more efficient.

--
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
__________________________________________________________________________

T:  +44 3300 467500  |  E: [email-masked]<mailto:[email-masked]>

BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai<http://www.baesystems.com/ai>
BAE Systems Applied Intelligence Limited
Registered in England & Wales No: 01337451
Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP

From: manet [mailto:[email-masked]] On Behalf Of Justin Dean
Sent: 03 July 2017 20:59
To: Henning Rogge
Cc: [email-masked]
Subject: Re: [manet] packetbb update idea

*** 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://ws-sites.ent.baesystems.com/sites/HOSECStdsLibrary/StandardsLibrary/Everyone/Red%20Flags.pdf>.
If you feel the email is suspicious, please follow this process<http://ws-sites.ent.baesystems.com/sites/HOSECStdsLibrary/StandardsLibrary/Everyone/Dealing%20With%20Suspicious%20Emails.pdf>.
*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.

On Mon, Jul 3, 2017 at 2:56 PM, Henning Rogge <[email-masked]<mailto:[email-masked]>> wrote:

Not sure I'm understanding what your suggesting or I'm not clearly expressing myself.  An example.  I want to encode a graph structure in RFC5444.
I have 4 addresses in the following configuration.

A-----B
|    /|
|   / |
|  /  |
| /   |
|/    |
C-----D

With current RFC5444 assuming I'm 1 I could do something like.
address block <B,C,D>
originator address A
TLV (link to oAddr) index B,C.  This would indicate A-B, A-C
TLV (link to address in the value field)  index addresses B,C with TLV value field of address D.  This would indicate B-D and C-D.
TLV (link to address in the value field) index address B with TLV value field of address C.  this would indicate B-C
This wouldn't be so bad except that the value field has to include the full address D and C instead of just indexing them.  It also makes the value field encoding messy if you start adding metric values to the links.

With the optional address using included (using bit 6) it would allow for TLV association between two addresses without actually fully including one of those addresses in the value field.

This is just an example but there we have both encountered encoding problems in which we wanted to associate addresses in the address block somehow, often with a metric or value associated with it.  This is a way that would allow us to do so cleanly.  Their may be other ways too.
********************************************************************
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: Justin Dean <[email-masked]>
Date: Wed, 5 Jul 2017 16:09:17 -0400

I don't see how having a bit field would work as the order of the addresses
in the address block are not guaranteed to be in any specific order.  My
example was meant to be a simple illustration what we are working on
contains possibly many more addresses and many more associations.

In terms of the headache of updating the specification I agree it's not
trivial but I don't think protocols which have been developed and specify
version 0 would have to be updated.  The only reason they would need to be
updated is if they were using an extension which specified use of version
1.  New protocols could specify version 0 or version 1 depending on
protocol requirements.  I also don't think we should update it right away
though as their may be more changes that might be helpful (like the chained
address blocks for example), but I'm against shooting it down outright
because it would cause difficulties due to versioning.  The version number
is there for a reason, it just shouldn't be abused.

If at all possible I'd like to focus this specific discussion on the merits
(or lack of) of the proposed change.  If people would find it useful then
we can have a discussion on if it's worth a version update, or add it to a
list of nice things to have in a later/future version update.

Justin

On Tue, Jul 4, 2017 at 4:51 AM, Dearlove, Christopher (UK) <
[email-masked]> wrote:

> As you indicate, that takes multiple TLVs. You can do it with a single TLV
> (and even indicate directionality, should you want to) by using a
> multivalue TLV with a bit vector single value. That’s a definite saving in
> that case.
>
>
>
> Really, theirs is a major overhead in introducing a change, it’s a lot
> more than simply updating 5444. For a start the existing protocols
> reference version 0. But if the update is to be of any application, do they
> need updating? And then we have compatibility issues over existing
> implementations - and we just had a report of an interoperability case. And
> more. It really has to be a compelling case, and this wouldn’t be that even
> if the alternative were slightly more inefficient. But it’s not - it’s more
> efficient.
>
>
>
> *-- *
>
>
>
>
> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
> Intelligence Laboratories *
> *__________________________________________________________________________
> *
> *T*:  +44 3300 467500 <+44%20330%20046%207500>  |  *E: *
> [email-masked]
>
> www.baesystems.com/ai
> *From:* manet [mailto:[email-masked]] *On Behalf Of *Justin Dean
> *Sent:* 03 July 2017 20:59
> *To:* Henning Rogge
> *Cc:* [email-masked]
> *Subject:* Re: [manet] packetbb update idea
>
>
>
>
>
> **** 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://ws-sites.ent.baesystems.com/sites/HOSECStdsLibrary/StandardsLibrary/Everyone/Red%20Flags.pdf>.*
> * If you feel the email is suspicious, please follow this process
> <http://ws-sites.ent.baesystems.com/sites/HOSECStdsLibrary/StandardsLibrary/Everyone/Dealing%20With%20Suspicious%20Emails.pdf>.*
>
> **** **WARNING ******
> This wouldn't be so bad except that the value field has to include the
> full address D and C instead of just indexing them.  It also makes the
> value field encoding messy if you start adding metric values to the links.
>
>
>

---

From: Christopher Dearlove <[email-masked]>
Date: Wed, 5 Jul 2017 21:59:18 +0100

The demerits of a change are major, so there has to be a very solid reason. It's easy to think of things that might have some value, I could give you half a dozen.

And the use case is easily solved with a bit field. Yes, reordering the addresses changes the bit patterns. So what? Nothing disallows that. We already use the index numbers.

I really, definitely see this as introducing serious problems for no demonstrated gain. I'll be opposing this as strongly as I can.

> On 5 Jul 2017, at 21:09, Justin Dean <[email-masked]> wrote:
> 
> I don't see how having a bit field would work as the order of the addresses in the address block are not guaranteed to be in any specific order.  My example was meant to be a simple illustration what we are working on contains possibly many more addresses and many more associations.  
> 
> In terms of the headache of updating the specification I agree it's not trivial but I don't think protocols which have been developed and specify version 0 would have to be updated.  The only reason they would need to be updated is if they were using an extension which specified use of version 1.  New protocols could specify version 0 or version 1 depending on protocol requirements.  I also don't think we should update it right away though as their may be more changes that might be helpful (like the chained address blocks for example), but I'm against shooting it down outright because it would cause difficulties due to versioning.  The version number is there for a reason, it just shouldn't be abused.
> 
> If at all possible I'd like to focus this specific discussion on the merits (or lack of) of the proposed change.  If people would find it useful then we can have a discussion on if it's worth a version update, or add it to a list of nice things to have in a later/future version update.
> 
> Justin
> 
>> On Tue, Jul 4, 2017 at 4:51 AM, Dearlove, Christopher (UK) <[email-masked]> wrote:
>> T:  +44 3300 467500  |  E: [email-masked]
>> 
>> 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.
>> 
>> *** WARNING ***

---

From: Thomas Clausen <[email-masked]>
Date: Wed, 5 Jul 2017 23:10:21 +0200

+1 to Chris' points

Sent from my iPad

> On 5 Jul 2017, at 22:59, Christopher Dearlove <[email-masked]> wrote:
>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 6 Jul 2017 09:28:25 +0000

Just to nail this one down.

Justin:
> I don't see how having a bit field would work as the order of the addresses in the address block are not guaranteed to be in any specific order.

As I indicated, that’s not a problem. We don’t assign meaning to positions, but we can use positions. As we do every time an Address Block TLV has an index or two indices.

So considering

A-----B
|    /|
|   / |
|  /  |
| /   |
|/    |
C-----D

Let’s assume the addresses are in order A, B, C, D. (If they change, we change TLV values. Which we potentially have to do any time the order changes anyway.)

I’m going to assume LSB = bit zero indexing because it’s easier to follow. 5444 actually uses MSB = bit zero, to fit network byte order. If we ever get that far we can have a Lilliputian argument.

So with bidirectional links, we simply have a TLV that sets the single-length to 1 (i.e. length to 4) and has values 6, 13, 11, 6. Even better we can do directionality. Let’s assume A to B but not B to A, the rest remaining bidirectional, and let’s assign bits by source (another case where there are two options, and we’d pick what we think is the better one). Now the values are 6, 12, 11, 6.

> My example was meant to be a simple illustration what we are working on contains possibly many more addresses and many more associations.

Even bigger win for the bit vector. The single value size goes up by one for each 8 nodes. But otherwise we need one TLV, not one TLV per connection. You’d have to have a very big, very sparse network to even challenge the bit vector. And then we can use another trick, to partition the network up and use more than one bit vector TLV. We should of course use the bit vector positions within the span of the TLV, so if we have a TLV covering, say, indices 3 to 6, bit 0 (whether LSB or MSB) is address 3, bit 1 is address 4 etc.

Incidentally, wanting to carry a topology isn’t a use case, it’s a consequence of a use case.

---

From: Justin Dean <[email-masked]>
Date: Thu, 6 Jul 2017 12:31:14 -0400

On Thu, Jul 6, 2017 at 5:28 AM, Dearlove, Christopher (UK) <
[email-masked]> wrote:

> > I don't see how having a bit field would work as the order of the
> addresses in the address block are not guaranteed to be in any specific
> order.
>
>
>
> As I indicated, that’s not a problem. We don’t assign meaning to
> positions, but we can use positions. As we do every time an Address Block
> TLV has an index or two indices.
>
>
>
> So considering
>
>
>
> A-----B
>
> |    /|
>
> |   / |
>
> |  /  |
>
> | /   |
>
> |/    |
>
> C-----D
>
>
>
> Let’s assume the addresses are in order A, B, C, D. (If they change, we
> change TLV values. Which we potentially have to do any time the order
> changes anyway.)
>
>
>
Changing the value of a TLV based on the order of the addresses in the
addresss block seems CRAZY to me.  The way my code is organized is that
TLVs are assigned to addresses and then all addresses with associated TLVs
are given to the packetbb "compiler" that builds the RFC5444 packet in the
most efficient way it can, address compression, TLV groupings, multi
indexed, all indexed, etc.  That bit of code doesn't know anything about
the values of the TLVs other than that they are associated with the
address.  The reverse is also an issue in that the bit of code that cares
about TLV values doesn't care at all what index the address is.  To say
that order doesn't matter and we can't enforce order (like we argued
against in assigning meaning to addresses with AODVv2) and then say that
order can matter in this case because we could just assign a TLV value
after the order is assigned seems arbitrary to me.

The bit field would work but it gets much less efficient when there are
values you want to include in the association.  One could append them at
the end of the TLV bit field but that doesn't really work as the TLV size
would me messed up.  The efficiency is only there when there are boolean
associations.

I could be into the idea of an indirect that RFC5444 would be aware of and
provide those associations to the protocols.  I thought about that first as
it has the advantages that a single extra address doesn't (like larger than
pairwise associations and random) but stopped as it would be horribly
complex to shoehorn it in and the single address would be sufficient for
90%.

You mentioned you had a bunch of ideas on how you might improve the
format.  I'd love to hear some of them.

---

From: Christopher Dearlove <[email-masked]>
Date: Thu, 6 Jul 2017 17:50:13 +0100

No, I'm not going to describe my ideas for improvement because they miss the point that the gains are minor, everything can be done in another way, and the costs are serious - every implementation out there has to either change or no longer guarantee backward compatibility. And the cases of mine and yours are a step or more away from a real use case. By which I mean "we could carry this sort of data" is not a use case of value. I want to create a protocol to do this for this reason might be. (I want to solve this problem is even better.)

--  
Christopher Dearlove
[email-masked]
[email-masked] is dead

> On 6 Jul 2017, at 17:31, Justin Dean <[email-masked]> wrote:
> 
> 
> 
>> On Thu, Jul 6, 2017 at 5:28 AM, Dearlove, Christopher (UK) <[email-masked]> wrote:
> Changing the value of a TLV based on the order of the addresses in the addresss block seems CRAZY to me.  The way my code is organized is that TLVs are assigned to addresses and then all addresses with associated TLVs are given to the packetbb "compiler" that builds the RFC5444 packet in the most efficient way it can, address compression, TLV groupings, multi indexed, all indexed, etc.  That bit of code doesn't know anything about the values of the TLVs other than that they are associated with the address.  The reverse is also an issue in that the bit of code that cares about TLV values doesn't care at all what index the address is.  To say that order doesn't matter and we can't enforce order (like we argued against in assigning meaning to addresses with AODVv2) and then say that order can matter in this case because we could just assign a TLV value after the order is assigned seems arbitrary to me.  
> 
> The bit field would work but it gets much less efficient when there are values you want to include in the association.  One could append them at the end of the TLV bit field but that doesn't really work as the TLV size would me messed up.  The efficiency is only there when there are boolean associations.
> 
> I could be into the idea of an indirect that RFC5444 would be aware of and provide those associations to the protocols.  I thought about that first as it has the advantages that a single extra address doesn't (like larger than pairwise associations and random) but stopped as it would be horribly complex to shoehorn it in and the single address would be sufficient for 90%.
> 
> You mentioned you had a bunch of ideas on how you might improve the format.  I'd love to hear some of them.

---

From: Justin Dean <[email-masked]>
Date: Fri, 07 Jul 2017 00:28:45 +0000

Your point on wanting to create a protocol that it's needed for is valid.
I'm not wanting to shove this through;  I'd just like some
positive/constructive debate on list.

On Thu, Jul 6, 2017, 12:50 PM Christopher Dearlove <
[email-masked]> wrote:

> No, I'm not going to describe my ideas for improvement because they miss
> the point that the gains are minor, everything can be done in another way,
> and the costs are serious - every implementation out there has to either
> change or no longer guarantee backward compatibility. And the cases of mine
> and yours are a step or more away from a real use case. By which I mean "we
> could carry this sort of data" is not a use case of value. I want to create
> a protocol to do this for this reason might be. (I want to solve this
> problem is even better.)
>
> --
> Christopher Dearlove

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 7 Jul 2017 08:38:59 +0000

Unfortunately, you can’t build a TLV-unaware optimum 5444 message constructor, because of different unspecified values. Using the UNSPECIFIED value introduced in 5198 can significantly improve efficiency, but the real winner (for OLSRv2 at least) is the (different) equivalent for LINK_METRIC. (Or, you can manage without the latter and then UNSPECIFIED becomes the winner.)

It’s not ideal, but it’s got less impact on other people (note that phrase) than modifying 5444.

From: Justin Dean [mailto:[email-masked]]
Sent: 06 July 2017 17:31
To: Dearlove, Christopher (UK)
Cc: Henning Rogge; [email-masked]
Subject: Re: [manet] packetbb update idea

*** WARNING ***

On Thu, Jul 6, 2017 at 5:28 AM, Dearlove, Christopher (UK) <[email-masked]<mailto:[email-masked]>> wrote:
Just to nail this one down.

So considering

A-----B
|    /|
|   / |
|  /  |
| /   |
|/    |
C-----D

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 7 Jul 2017 12:56:17 +0200

Hi Justin,

I thank you for this issue, yes we need to look into more issues of
manet-routing specially multicast. In MANET we done only simple multicast
using packetbb, but does packetbb solve most problems of Multicast Routing
in MANETs? IMO it needs update for that.

AB

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 7 Jul 2017 11:05:57 +0000

Having protocols (other than SMF) is a possible area for future work. But has absolutely nothing to do with any updates to RFC 5444.

From: manet [mailto:[email-masked]] On Behalf Of Abdussalam Baryun
Sent: 07 July 2017 11:56
To: Justin Dean
Cc: [email-masked]
Subject: Re: [manet] packetbb update idea

*** WARNING ***

Hi Justin,

I thank you for this issue, yes we need to look into more issues of manet-routing specially multicast. In MANET we done only simple multicast using packetbb, but does packetbb solve most problems of Multicast Routing in MANETs? IMO it needs update for that.

AB

On Mon, Jul 3, 2017 at 7:29 PM, Justin Dean <[email-masked]<mailto:[email-masked]>> wrote:
So while trying to encode some information using packetbb for the elastic multicast stuff we have been working on I've run into a short coming.  RFC5444 allows one to efficiently encode information about addresses and even pairs of addresses (as long as one of those addresses is the Oaddr) with the TLV structure and the address block.  It does not allow for easy encoding about pairs of addresses of which neither is the Oaddr.  After some thinking on it I think most of what I'd like to be able to do could be solved by using the RESERVED tlv flag bit number 6 to indicate inclusion of a single index field <index-opt> which would specify a single address in the address block.
So the tlv definition would change from
<tlv> := <tlv-type>

                <tlv-flags>

                <tlv-type-ext>?

                (<length><value>?)?
to

<tlv> := <tlv-type>

                <tlv-flags>

                <tlv-type-ext>?

                <index-opt>?

                (<length><value>?)?

This would allow one to specify information about pairs of addresses in a compact way.  In the case of elastic multicast source/destination flow pairs. Thoughts welcome.

Justin

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

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 10 Jul 2017 13:38:09 +0200

Hi Chris,

It is just a FORMAT, nothing else, it is very simple but can
create/make/solve problems.

It is very important to update any standard that is DEPENDENT, usually the
strategy is we design protocols for solving-problem then the messages, but
our group done a standard to focus our protocols but we never
said/discussed we don't update only if there is a BIG reason for that. IMO
it is not correct strategy to not update RFC5444 which is general. I agree
it was a problem done by this group to make a standard for packet/message,
so now you are not finding easy ways to update (we designed not flexible
standard-format maybe!!!). If flexible format it should be able to be
updated easily.

You said:

> I really, definitely see this as introducing serious problems for no
demonstrated gain. I'll be opposing this as strongly as I can.

I disagree with not updating strategy, and we need to not make roles of not
updating only if ''getting major gains''.

the point that the gains are minor, everything can be done in another way,
and the costs are serious - every implementation out there has to either
change or no longer guarantee backward compatibility.

The point was to discuss solutions and updating is one solution by Justin,
and/or discussing other solutions with not updating is your approach, so
you can describe your ideas.

Few in MANET WG  had the idea of better gain in the past was that we
publish reactive and proactive standards before doing their used general
packet format (packetbb idea), but while we done the packet first we can
update. However, now we have 5444 and only one routing standard, so we may
need to discuss ideas/solutions and then update for design-flexibility any
incorrect idea or format or strategy.

AB

On Fri, Jul 7, 2017 at 1:05 PM, Dearlove, Christopher (UK) <
[email-masked]> wrote:

> Having protocols (other than SMF) is a possible area for future work. But
> has absolutely nothing to do with any updates to RFC 5444.
>
>
>
> *-- *
>
>
>
>
> *From:* manet [mailto:[email-masked]] *On Behalf Of *Abdussalam
> Baryun
> *Sent:* 07 July 2017 11:56
> *To:* Justin Dean
> *Cc:* [email-masked]