[Manet-dt] RE: Minor MANET Generic Message Format Comments

With regard to these points

1 - I think I'd rather keep OLSRv1 compatibility.
2 - On balance is probably a good idea, but I'm open to either way.
However if we are going
     to change I'd like to make the decision as soon as possible (code
depends on it).
3 - I beat Brian to this one (both parts) - see bugtracker (where I also
had other ideas I
    think we won't do). But generally my comments are  as 2, i.e. can
live with decision
    either way as long as quickly. Note that <tail>+ should probably be
<tail>* as we
    have no tails if <head-length> is maximal. (It's even possible in
this case for the
    number of addresses to be >1, provided they have different netmask
lengths.)

Thomas, Justin?

  _____ 

From: Brian Adamson [mailto:adamson@itd.nrl.navy.mil]
Sent: 23 March 2006 20:05
To: Thomas Heide Clausen; Dearlove, Christopher (UK); Joe Macker;
jdean@itd.nrl.navy.mil
Cc: manet-dt@ietf.org; adamson@itd.nrl.navy.mil
Subject: Minor MANET Generic Message Format Comments

*** WARNING ***

This mail has originated outside your organization,
either from an external partner or the Global Internet.
Keep this in mind if you answer this message.

We discussed some of these at the working group meeting.

1)  For <msg-header-info>, it seems the order of the fields should be:

<originator-address>
<msg-seq-number>
<ttl>
<hop-count>

since the presence of <originator-address>/<msg-seq-number> are commonly
determined by bit0 of <msg-semantics>  _and_ the presence of
<ttl>/<hop-count> are commonly determined by bit1 of <msg_semantics>

This makes for more logical message building ...

(BUT, I understand a "backwards compatibility with OLSRv1" issue here
may need to take precedence over this nit-pick?)

Also here, with regards to <ttl> and <hop-count> as discussed, <ttl>
might be better renamed <hop-limit> ... Also if <hop-count> is an
accumulated count of hops traversed, would it be possible to then leave
<hop-limit> fixed (don't decrement) and stop forwarding when incremented
<hop-count> > <hop-limit> ...

Or ... should we leave the use of these fields open in message format
document as perhaps suggested.

2) Similarly, for <tlv>, it seems the field order should be:

<type>
<tlv-semantics>
<index-start>
<index-stop>
<length>
<value>

The reason for this is that in constructing a TLV, particularly a
multi-value TLV it would seem that the choice as to whether (noindex) is
set could be made ahead of setting TLV values and that <length> could be
updated as multiple tlv's are added ...

And also, this seems more logical since <length> does _not_ include the
<index-start> and <index-stop> content, but is the length of the <value>
field that follows ...

3) In the <addr-block>, it also seems cleaner to have <num-tails>
precede <head>, and hey, why not call it <num-addrs> since that is what
it is?  So the new suggested format would be:

<address-block> = <num-addrs>
                  <head-length>
                  <head>
                  <tail>+

Brian
__________________________________
Brian Adamson
<mailto:adamson@itd.nrl.navy.mil>

--
Brian
__________________________________
Brian Adamson
<mailto:adamson@itd.nrl.navy.mil>

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