Subject: [Manet-dt] PacketBB comments.

From: "Justin Dean" <[email-masked]>
Date: Mon, 30 Oct 2006 17:47:03 -0500

First I would like to comment on the question about private use type/tlv
space.  I like Chris would be willing to change this to a smaller amount,
but should this arbitrary distinction even be in this document?  To me this
is more of a namespacing issue and could be better dealt with in a namespace
document.  We could add a namespace section for message types and tlv types
in this document but my personal opinion is that it would be better dealt
with in a different document.  

Related to this is the reservation of OLSR (v1) message and tlv types.
Should this be in the document as well.  I understand how it's a bad thing
if any OLSR (v1) packet is received by a packetbb designed protocol but it
seems cleaner to me to mandate they run on different ports.  The
port/multicast address/type namespace/tlv namespace issue is one which we
need to discuss but I will come back to that.

The third issue is more mundane and easier to fix but the security section
seems to me out of sync with the rest of the document.  I think that parts
should be moved over to NHDP/DYMO/OLSRv2 as packetbb is not a protocol and
doesn't really have any framework to define what a good security
should/could be.  More of a disclaimer like ...

"This specification does not describe a protocol or the methods suitable for
securing protocols built on this specification.  Protocols designed from
this specification MAY want to take into consideration: Packets are designed
to be transmitted only one hop, messages at each hop MAY be forwarded and/or
processed."

Namespace and protocol interoperation thoughts.

We have gone though a lot of work revamping and unifying the packet format.
This has value in a couple of different ways.  It allows for protocols to
refer to the same spec and not reinvent the wheel as it were.  It can help
enable lower overhead when running multiple MANET protocols on the same
network (NHDP with SMF and OLSRv2.) Hopefully it will also allow for easier
integration between the various protocols.  The first value has already been
obtained IMO the second and third are getting there but need work with
namespacing.  It is important that both OLSRv2 and SMF or SMF and SMF
(running a differing CDS algorithm) can use the same NHDP protocol for
communication and still work.  Currently it doesn't.  If a node receives an
NHDP message it assumes the sending node is running OLSRv2 and can try and
tell the node to be an MPR.  If the sending node is not running OLSRv2 it
will break OLSRv2.  The same can happen to SMF assuming all NHDP neighbors
are SMF enabled.  This needs to be worked out.  Namespacing types and TLVs
may be a solution or at least a mitigating factor for this, Brian has some
more thoughts here.  We could also introduce (globally or NHDP scoped)
message tlv which includes which protocols are enabled on the sending node.
A packet TLV could also work.  This tlv could either be a bitmask of known
packetbb protocols or a tlv per protocol.  A bitmask TLV would essentially
function in a similar manor that a network ID tlv would work, which Ian had
brought up, but would confer information allowing interoperation and
non-hostile behaviors at the same time.  A network ID used for this purpose
would only allow non-hostile behaviors.

Justin Dean

-----Original Message-----
From: Dearlove, Christopher (UK) [mailto:[email-masked]] 
Sent: Monday, September 25, 2006 4:16 AM
To: Ian Chakeres; [email-masked]
Subject: RE: [Manet-dt] PacketBB IANA Registry Private Use Space

> PacketBB authors, is there a reason behind allocating half the type 
> space to private use?

Two parts to that. First, I think that it's clear we need some private use
type space, that's pretty universal with such things.

Second, why half? First, it's convenient, and I don't think we're the first
to suggest such a split. Second, with a protocol specific and general split
I think we have enough space to permit this. But it's not fundamental.

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

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