Subject: [manet] PacketBB Status

From: "Ian Chakeres" <[email-masked]>
Date: Fri, 21 Sep 2007 13:58:57 +0530

Joe and I recently had a discussion with the PacketBB authors about
the constraints being discussed on-list. After talking through the
issues, I believe the constraints are advantageous and not harmful.
Unfortunately, the existing document and on-list discussion have shown
that the advantages are not well understood. Perhaps equally relevant
are certain misconceptions about the effect of these constraints.

I've asked the PacketBB authors to update the document and to provide
some educational material on-list.

I think the following areas are particularly misunderstood:

1) The difference between encoding, parsing/decoding, processing, and
message forwarding.

2) How ordering interacts with #1, as well as why and when it is
useful. I think particular attention needs to be paid to clearing up
many misconceptions.

3) Why multivalue address TLVs demand that multiple values (not to be
confused with multivalue TLV) are not allowed for address TLVs.

4) Some reasons for choosing a specific order and IANA number
assignment that are different from the existing document were also
brought up.

I look forward to resolving our differences so we can move the
PacketBB document forward.

Thank you,
Ian Chakeres

_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: Russ White <[email-masked]>
Date: Fri, 21 Sep 2007 11:39:28 -0400

> 1) The difference between encoding, parsing/decoding, processing, and

I'm not certain why the proposal to have an "in order" section, and an
"out of order" section isn't acceptable to the authors....

:-)

Russ

- --
[email-masked] CCIE <>< Grace Alone

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 21 Sep 2007 13:23:46 -0700

Hello Ian,

> are certain misconceptions about the effect of these constraints.
Can you explain why it is, that the advantages you perceive
have not been discovered by any other working groups?
> 1) The difference between encoding, parsing/decoding, processing, and

 The last one is distinctly different.  Parsing depends strongly on
encoding, although they are, of course, different.  Processing is a
very general term which "could" mean any of the others.  I would
suggest that it should be avoided because it will inevitably lead
to ambiguities.

Besides that, as a general rule IETF protocols only deal with
what is on the wire.  They do not dictate how internal processing
is done.
> useful. I think particular attention needs to be paid to clearing up

 I think it is a misconception that all address TLVs will need
such ordering.  I think that this misconception is based on a
belief held by the packetBB authors that they have a good
handle on the way that addresses need to be described by
the TLVs that are subordinate to the address TLVs.

The multivalue TLV construction was a useful add-on to
help with some previous complaints about packetBB's
relative inflexibility (or, flexibility at the cost of greatly
expanded packet size).   It is a good addition to the
specification, but not sufficient justification for imposing
these constraints.

Generally, I believe that this misconception is based on a
view that all such multivalue TLVs will be able to enumerate
enough "address descriptors" so that only one such multivalue
TLV will be needed for an address TLV.  This will probably
at least cause an explosion in the number of descriptors that
are needed (for instance, we would need different values
to distinguish "blue and greasy" from "blue and fluffy", and
so on).  But even this approach fails almost completely if
we wanted to construct structured descriptors for
addresses (or address ranges).

> PacketBB document forward.

I don't think the document authors have gotten very close
to answering the many objections that have been raised
(including mine).  However, even if there were some answers
(I am skeptical about this) I really cannot imagine why
these conditions have to be imposed for all future manet
protocols.  It would be so easy and helpful to just let each
individual protocol document specify whether the constraints
make sense.

After all, if the constraints are so advantageous, any sensible
protocol designer would happily accept them and make that
part of the specification.  This business of cramming unwanted
constraints into every future protocol, especially when so
many complaints have been registered, does not seem right
to me.  It does not at all promote interoperability, and certainly
does not conform to my sense of IETF-ness.

Regards,
Charlie P.