Re: [6lowapp] Newbie questions

Hi Kerry,

Here is the big problem we keep coming up against in service discovery:
1)   Most agent based solutions are deeply unpopular by HAN device
manufacturers.

Here is why:
1)  Many different vendors contribute to devices in the home area network
(HAN)
2)  No vendor of device "X" wants to have to increase their storage and
computing capacity to become the repository of service information for all
other devices in the network.
3)  HANs are not managed networks where some owning entity would place
infrastructure devices

Note what I wrote above is for the home area network (HAN).  Building
automation is another story as there is certainly a building control system
in place there.

The simplest solution for this for the HAN:  Allow individual devices to
hold their own service information and provide a unicast/multicast query
system to allow for self description of service information.  Allow for
individual devices on the HAN to form their own queries and get direct
responses back from devices matching those service requests.

For the I-D I turned in for service discovery, I did use the SLP DA
(Directory Agent, I believe) to hold the strings (URI plus service) and had
the DA responsible for substituting those for tokens upon request.  However,
I had in mind that would be all the DA would do and all service discovery
was UA (User Agent) based.

For a building controls solution (commercial or industrial), the DA could be
fully populated an used on the building control system......

Don

-----Original Message-----
From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf
Of Kerry Lynn
Sent: Monday, November 02, 2009 5:32 AM
To: 6lowapp@ietf.org
Subject: [6lowapp] Newbie questions

Greetings,

My name is Kerry Lynn and I hope to contribute to this effort remotely.  I
am an independent contractor working in the area of building automation
and have worked previously in Cisco and Apple network engineering in
addition to supporting university research into constrained devices.  I
hope you will bear with what may be foolish questions as I come up to
speed:

I tried to access the audio stream and jabber feed from yesterday's
meeting but was unable to do so.  Is IETF registration necessary?

Is it the consensus of the group to support peer-to-peer as well as
server-based configurations?  The first is what I'd term the "one light,
one switch" scenario while the latter would include DHCP, DNS, etc.
and perhaps application proxy support.

Has anyone considered something like T/TCP as a candidate for
transaction support?  I know it has been traditionally implemented
as a superset of TCP but I suspect it could be much simpler than
full TCP if used in a controlled environment such as local
communication with a full TCP/HTTP/REST proxy.  The security
concerns could be addressed simultaneously.

Has anyone proposed mDNS/DNS-SD as an alternative to SLP?
Does anyone have a feeling for how one client implementation
compares to the other in terms if complexity?

Thanks, -K-
_______________________________________________
6lowapp mailing list
6lowapp@ietf.org
https://www.ietf.org/mailman/listinfo/6lowapp