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

Just chiming in.

#1) Chris (and others), how about switching the bits (bit0 and bit1)
then the fields stay in the same place and I think everyone is happy.

Ian

On 3/28/06, Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> wrote:
>
>
> 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.
>  ********************************************************************
>
>
> _______________________________________________
> Manet-dt mailing list
> Manet-dt@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet-dt
>
>
>

_______________________________________________
Manet-dt mailing list
Manet-dt@ietf.org
https://www1.ietf.org/mailman/listinfo/manet-dt