Re: [6lowapp] Next rev of CoRE Charter

[Zach Shelby <[e-mail]>]

JP, Cullen,

Below are my comments regarding discovery, I agree it is an important feature. Summary: 

After the BOF consensus, what makes the most sense is to include a basic mechanism as part of CoAP which can be used for discovering devices running a CoAP service, and which CoAP resources that service has. This can surely be extended and used for wider purposes by others, here we should define the bare minimum that works and is interoperable.

For the first charter we do not want to define or modify a general service discovery protocol, such as SLP. That is, we don't want to discover printers running IPP. I do agree that there is a need for a constrained general service discovery protocol, and that might be something for re-chartering later or for another WG. 

Comments in-line:

On Feb 3, 2010, at 9:41 , JP Vasseur wrote:

>>> 
>>> 
>>>> 
>>>> 5) A definition of how to use CoAP to advertise about or query for a
>>>> Device's description. This description may include the device name
>>>> and a list of its Resources, each with a URL, an interface
>>>> description URI (pointing e.g. to a WADL document) and an optional
>>>> name. The name taxonomy used for this description will be consistent
>>>> with other IETF work, e.g. draft-cheshire-dnsext-dns-sd.
>>> 
>>> Does that cover the discovery aspects (of both the devices and the services)?
>>> If so, great otherwise i would suggest to clearly spell it out since this is in my
>>> opinion a core components.
>> 
>> It covers the naming aspects of device and services. (More or discover bellow)
>> 

Yes, this can be used for discovery of devices running CoAP and their resources.  Sure, some text making that clear is a good idea.

>>>> 
>>>> The working group will not develop a reliable multicast solution, and
>>>> will not develop a general service discovery solution.
>>> 
>>> That is the part I was a bit worried about ... without service discovery, deployments will
>>> certainly be extremely difficult. We should at least work on the selection of a discovery
>>> protocols, many candidates exist ... and potentially re-charter, should protocol extension
>>> will required.
>> 
>> So I share your concern and was very skeptical of how this could be useful without a Discovery protocol. However, at the BOF, there was a surprisingly strong HUM at the end to throw Discovery under the bus. This sort of freaked me out at first but as I came to talk to more people about it, I realized that people had widely varying views of what Discovery meant. Here's my current understanding of what sort of "Discover" in the scope of this charter and what is out of scope. 
>> 
>> First, a discovery protocol can be decoupled from a data transfer protocol. For example, a printer can be discovered with UPnP, Bonjour, SLP, etc even though one might use IPP to print to it. What we are trying to do here is more the IPP like protocol. Second, the charter has the word " A Device can also publish or be queried about its description." I'll update this a bit but the intention was, if you know the IP address of a Device, you can ask it what resources it supports - basically what's it profile. A device should also decide to publish out to other devices what resources it supports. It could publish them to a multicast group. A device could also sent out to multicast group what resources do you support and get back answers from many devices. Some people think this is discover and many do not. They think it is just a device saying what characteristics it has and consider Discover much more complicated.  The other part in the proposed charter around discover is being consistent with existing naming constraints. The goal here is to make sure that whatever this WG selects around name devices and services, it's got to make sure that this is not impossible for an application to use in some multicast DNS discover protocol. 
>> 
>> That my rough, and perhaps somewhat confused, interpretation of the state of the current charter and given the strong HUMs at the end of the BOF, I don't see how we have this WG take on a full blown discovery effort without re-charting (or re-boffing) which is something I am perfectly happy to delay to do later.

I think you described that nicely Cullen. 

> 
> The objective is clearly not to delay anything on my side, I do believe as many people that the sooner this WG is operational, the better !!!
> But discovery is IMO a central issue. In most use cases, and this was discussed in length in several other WGs and even other SDOs, the lack of discovery is almost a show stopper. Most proprietary solutions have their own discovery solutions, we do have IP protocols that could make the work here with potential adaptation, I do not see how we could leave it out. In most environments (smart cities, smart grid, ..) this is listed as one of the key item. Would it make sense to poll the list on that particular aspect restating what it means not to have a discovery solution for these kind of networks (without re-BOFFING for course) ? Again the idea would not be to redefine a complete solution but to evaluate existing solutions and select one; if extensions are needed this could be done in concert with the WG owning that protocol.

Right, CoAP will support basic discovery of its own services, which is a good starting point. It is the best we can do for this charter. If we want to work on adapting or designing a new protocol for general service discovery (like SLP) then that will need re-chartering. Anyways, 6lowapp is a more general interest area, which may spawn several working groups. So this might be something for interested people to keep working on and then spin off a "Lightweight Service Discovery" LSD ;-) WG?

Zach


-- 
http://www.sensinode.com
http://zachshelby.org - My blog "On the Internet of Things"
http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded Internet"
Mobile: [phone]

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

This e-mail and all attached material are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender and delete the e-mail from your system without producing, distributing or retaining copies thereof.