Re: sketchy laugh test: device discovery BOF

["James Kempf" <kempf@docomolabs-usa.com>]

> >The reason why I am somewhat suspicious on this is because the Bluetooth
> >SIG
> >essentially took SLP and put it into Layer 2, making their specification
> >lots more complicated than it needed to be.
>
> Haven't read this closely. Did they include filtered queries too?
>

It has been a while since I looked at the Bluetooth spec, but I believe they
did.

> >From the looks of it, the purpose is more to propose an alternative that
> runs over IP.  However there are important implications of running such a
> protocol over IP -- such as the fact that it might not be usable for
> discovery on links that aren't authenticated if dynamic addressing is
> required. Currently LLDP doesn't support use over unauthenticated links,
but
> in the next revision, it might.
>

I'm not sure I follow. It is certainly possible that host authentication may
not
be done at level 2 if IP discovery were done, but then that's also true for
level 2 discovery as well, isn't it? It seems to me that whether or not the
host is required to perform some kind of authentication to enter the network
is independent of the discovery protocol. Or am I missing something?

Of course, there is also the issue of authentication for the discovery
protocol itself, but that seems, to me, to be more easily handled at layer
3.

> I'm not entirely clear that the IEEE 802.1ab problem statement is clear
> enough, let alone the DDP one.  For example, neither LLDP nor DDP include
> support for request/response, yet I'm told that IEEE is looking at
creating
> yet another discovery protocol to handle the probe request/response
> functionality.
> Logically, it would appear to me that the addition of request/response
> should not require design of a completely new protocol, just perhaps
> addition of an opcode.  So I'm looking for signs of coherent architecture
> here, but not finding them so far.
>

Yes, I agree.

> I have to admit that I do like aspects of the DDP design though -- such as
> the extensibility and separation of data from protocol. One could see for
> example, how additional opcodes could be added for request/response, or
how
> the protocol could be extended for different purposes so as to satisfy
> multiple link technologies.  So it might be a contribution toward a more
> coherent approach.
>
> Then again, given the past history of duplication of effort between IEEE
and
> IETF, I'm probably just dreaming :)
>

Right, it would be helpful if we could get this straight.

            jak