Subject: [manet] Ordering of message components in RFC 5444 format

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 04 Feb 2013 12:22:25 -0800

Hello folks,

Reading through the numerous (and voluminous) emails on this
topic, I've noticed that there is some ambiguity about the matter.

One could imagine some positional significance to any of the
following orderings:
- messages in a packet
- address data (AddrData) in a message (i.e., <addr-block><tlv-block>)
   == unfortunately, I could not find existing terminology for this, and
        the handy term "Address Object" has been already used for some
        other concept in RFFC 5444.  So in this email I use "AddrData"
- address TLVs (AddrTLV) in the TLV block of the address data
- the list of addresses that appear in an Address Block (AddrBlk)

Some of the discussion favoring "positional independence"
actually seems to be arguing for positional independence for
the order of AddrTLVs in the AddrData.

There is no positional dependence of the AddrTLVs specified
in the AODVv2 specification.  I am not aware of any past version
of RFC-5444 compliant versions that made any such specification
for positional dependence of AddrTLVs within the list of address
TLVs following an AddrBlk.

Likewise, there has been no suggestion of imposing ordering
significance on the collection of messages in a packet, and no
requirement for ordering the AddrBlks in messages that might
have multiple AddrBlks.

Up until the current discussion, AODVv2 has attached positional
meaning to the order of addresses in an AddrBlk.  According to
email I sent out on Jan. 21, it is proposed to remove this positional
dependence by creating new AddrTLVs, and this week is likely to
see a new version of the AODVv2 specification incorporating the
new proposal.

Nevertheless, there is certainly still disagreement on whether or
not it is reasonable to assign positional dependence to order of
appearance of addresses in an AddrBlk.  I'll follow up on that
discussion in a later email.

-- 
Regards,
Charlie P.