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

From: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Tue, 15 May 2007 09:35:37 +0100

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

You should design your protocol using packetbb to use it
efficiently. There are generally several solutions to
each problem. For example if you want to separate addresses
into groups then one way is to put them in separate address
blocks. Another way uses address TLVs. There are doubtless
others.

>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?

OLSR, i.e. OLSRv1, not OLSRv2. It's hardly possible to change
the former.

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

If you change the document, you change the code. You are
talking about adding options, so that's adding options to
the code. (I'm referring to mine - at least one of my
co-authors also has code.)

> 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?

Changes are always possible. But not necessarily desirable.
My position is that there are pressures in various directions,
and where we are is the best balance of those pressures based
on proposals I've seen.

As for (a) - yes, there may not be an interoperability
requirement, but I want some running code, and (b) yes,
all discussion should be on the list - but this list
has been pretty much useless over most of my time with
the IETF, it's really only been the last few months that
it's approached being a more usual IETF list. People
have got in the habit of bypassing it, and I can't make
them post here. Actually they tend to communicate directly
with Thomas rather than me.

********************************************************************
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: Tue, 15 May 2007 08:42:45 -0700

Hello Chris,

> blocks. Another way uses address TLVs. There are doubtless

All of my suggestions have been made with the goal
of being able to use PacketBB efficiently.

I had presumed that one would like to have addresses
collected together in an address TLV to have some
relationship to each other.  Your suggestion seems to
encourage people to put as many addresses as can
be done into the same TLV in order to make use of
the PacketBB as efficiently as possible.

It does not have to be that way!  My proposal for
an alternate form of address representation is not
all that hard to do -- a lot easier, in fact, than spending
this much time looking for reasons not to do it.

> OLSR, i.e. OLSRv1, not OLSRv2. It's hardly possible to change

Nor was such an un-RFC-like thing suggested.  The main reference to
OLSR provides guidance to IANA to avoid allocating message types 1-4.
Of course, OLSRv1 implementors won't be able to consult the IANA
PacketBB table solely on the information provided in the OLSRv1 spec.

So it seems more informative than normative to me.

> and where we are is the best balance of those pressures based
Didn't you say the best was the enemy of the good?

> requirement, but I want some running code,

Yes.  Running code is an asset.  However, it is not the determining
factor, as you well know.  I am sure you have seen similar arguments
before in other working groups.

>  and (b) yes,
> it's approached being a more usual IETF list.

I'm on a lot of IETF lists, and there does not seem to be
only one style or flavor of lists.  But I hardly thought that
the MANET mailing list was dysfunctional.  I can skim past
and disregard irrelevant messages as well as anyone else.

>  People

I just cannot endorse a condemnation of the mailing list
as justification for avoiding even the discussion of my
proposals for improvement.

I guess you really didn't mean this.

Regards,
Charlie P.