Subject: RE: [manet] packetbb constraints

From: "Teco Boot" <[email-masked]>
Date: Mon, 17 Sep 2007 19:12:48 +0200

I am amazed that some spend an incredible amount of time on what is IMHO a
minor subject.

My personal opinion is that a requirement for ordering or duplicate TLV
types makes the specification less generic. I expect the Generalized MANET
Packet/Message Format to permit whatever a protocol requires.
Example, to be supported:
> Protocol requires ordering, say header, body and trailer TLVs
> Header is assigned 20, body 21 to 25 and trailer 26.
> New header type is requested and assigned 44, this replaces TLV type 20.
> TLV ordering in packet is mandated as [44, (21..25, any order), 26] or
[20, (21..25, any order), 26] for backwards compatibility.
> The Generalized MANET Packet/Message Format shall support this
requirement.

Let me repeat my remark that the type numberspace is extremely limited and
we should evaluate the idea about extended TLV types (instead of subtypes),
for example signaled by the first bit (types 1 to 127 are 1 octet, types
32768 to 65535 are two octets. This provides a number space of 32894 types
without any hierarchy. Delegation of types 1 to 127 shall be restricted to
<unknown yet>. Using a signal bit (bit-0, hassubtype -> extendedtypefield)
is also OK for me, this supports even more types (65535, excluding type zero
and two formats for values 1 to 255)

Teco.

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

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 17 Sep 2007 11:46:39 -0700

Hello Teco,

> I am amazed that some spend an incredible amount of time on what is IMHO a
 
 For me it is not minor, because the constraints as proposed
cause difficulty for the kind of slimmed-down neighborhood
discovery packet format I have proposed.
 
> Packet/Message Format to permit whatever a protocol requires.

 I agree with this, within the boundaries of good protocol
engineering that I reckon you would agree with.

Regards,
Charlie P.

---

From: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Tue, 18 Sep 2007 09:25:55 +0100

> discovery packet format I have proposed.

As I understand it, your proposal (which I strongly oppose but
that's not the point here) is to use message TLVs. That means
the constraints have no impact on your proposal, as message
TLVs may be duplicated. They have to be sorted, but as Justin
points out, that imposes no constraints on your processing.

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