RE: [Manet-dt] PacketBB comments.

["Dearlove, Christopher \(UK\)" <[e-mail]>]

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

The most important thing, in my view, is that the reservation is made.
I can see some point to your suggestion, but I also want packetbb to be
complete and finalised/published as soon as possible, and this is
important to it. See the last two sentences below.

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

Making this reservation makes it possible to run OLSRv2 on the already
allocated port 698. This seems a reasonable option (not necessarily the
only
one to be supported). It also allows the potential for a form of
OLSRv1/v2
interworking. But for these it's necessary to prevent overlap, which is
what this does. Of course there's no OLSRv1 TLV allocation, only the
four
message types. It's worth noting that this is not just arbitrary, we for
example have an implementation of what we call OLSRv1.5 (a subset of
OLSRv2
with single interfaces and no gateways) that uses this capability. (It's
a
rapid proof of concept of packetbb to implement part of OLSRv2 as an
extension to OLSRv1. I believe others have done something similar.)

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

I think pointing out how this format facilitates security, without in
any
way specifying/mandating it, is entirely appropriate. I think the
current
text does that, and usefully points out the minor issues of hop
limit/count.
Consequently I definitely disagree withg you here.

>Namespace and protocol interoperation thoughts.

I'm not going to reply to this bit here, as I need to read what you've
written more carefully, and think how it ties in with my thoughts. But
I think the key issue is architectural. TCP/UDP ports work because the
protocol stack has them built in, essentially there's a mapping, this
number means go and run that code (protocol). This is built in to every
TCP/IP stack on the planet (or off it). We have something new here, more
than one protocol to see information and use it, and something that's
not built in to any stack, let alone all of them. I need a picture of
how this is organised in order to see what is sensible here. But this
also ties in with the allowing OLSRv2 to work on port 698 as a
standalone,
whatever multi-protocol architecture is devised, it will be too much
for some people, who'll want just to run OLSRv2 (or something else with
the same issues).

Of course I may have some specific comments, but if so I'll do them in
a later message. I'd like to sit down and discuss this in San Diego.
Unfortunately as I won't be in San Diego, this will be tricky.

Christopher Dearlove


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