Subject: [manet] RE: Comments about draft-ietf-manet-packetbb-04

From: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Mon, 14 May 2007 09:33:22 +0100

> A lot of ad hoc networks will be either partially or completely
> populated by nodes with previously assigned addresses.
> They get together, they work, they break apart.  Like
> ad hoc networks do.
> 
> Your perspective seems to assume the existence of a
> centralized address allocation agency, either online or
> offline by preassignment.  That is very worrisome to me.

You have quite misread my comments, which didn't discuss
address allocation at all - in fact actually discussed the
case you are considering. You can have entirely unrelated
addresses, with no address compression possible. You can
still put them in a single address block. That will be 2
octets overhead - not 50%, which would be 2 per address,
and would only happen if you put them in separate address
blocks. So don't do that.

> Well, that doesn't seem to explain anything.  This document
> should not have any normative dependencies on OLSR
> whatsoever, and I don't really see any necessity for any
> informative references either except for historians.

It's not informative, it's normative. It allows some options
using OLSRv1 that would otherwise fail. (A valid OLSRv2 message
with a zero semantics octet is a valid OLSR message.)

> I do not
> claim that PacketBB is terrible, but this is the time to make
> improvements.

I do not claim packetbb is perfect, but now is the time to
publish.

> I reckon the changes could be made in two weeks.

You don't have code to re-write and re-test. And I know
from experience two weeks is too short an estimate even
apart from that. Furthermore other interested parties
(quite independent of me) want to go in the opposite
direction - simplification at the expense of flexibility
and efficiency. I think we have a reasonable compromise.

********************************************************************
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 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 14 May 2007 10:04:50 -0700

Hello Christopher,

More comments below...

ext Dearlove, Christopher (UK) wrote:
> addresses, with no address compression possible.
Good -- yes I did know this was possible.  I am glad that your
comments were not made from the context that I had inferred.
>  You can
Whether or not multiple addresses are collected is dictated by
the meaning of the message, not the desire for a person to save
space according to a parseable bucket of message fields.
I agree that when you can collect multiple addresses, the
more you can get the less percentage overhead will be
incurred for the whole collection.
> with a zero semantics octet is a valid OLSR message.)
I am not following this logic.  Why should PacketBB depend on
OLSR?  All the basic message structure should be defined in
PacketBB, and OLSR should make a normative reference on
PacketBB in order to utilize the structures defined there.
What am I missing?  What would fail?  Is there more text
that needs to be pulled from OLSR and put into PacketBB?
> and efficiency. I think we have a reasonable compromise.
The document can be revised in a way that does not
disable existing code, except that existing code blocks
would need to be encapsulated by some minor bit testing.

Furthermore, it is not enforced that we require
interoperability testing before progressing the document.
I really think you are exaggerating the difficulty for
including the changes I have suggested.  These sorts
of techniques have been used so many times in the
past that there is little doubt they would work.

Do you contend that no changes are possible unless
(a) you have tested the new code, and
(b) the voices of discussion that you hear but are not
       on the mailing list approve?

Regards,
Charlie P.,