Re: [6lowapp] Next rev of CoRE Charter

[Kerry Lynn <[e-mail]>]

Hi Zach,

Comments inline...

On Thu, Feb 4, 2010 at 1:23 PM, Zach Shelby <[e-mail]> wrote:
> Kerry,
>
> On Feb 4, 2010, at 16:48 , Kerry Lynn wrote:
>
>> Zach, JP, Cullen,
>>
>> On Thu, Feb 4, 2010 at 3:56 AM, Zach Shelby <[e-mail]> wrote:
>>> 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.
>>>
>> KL> Your comments seem contradictory here - we want a basic mechanism
>> for discovering
>> devices running CoAP, but don't want to use a protocol that already
>> exists for that purpose?
>
> There is a misunderstanding with Device, as you noted below. What I am trying to say is that the bare minimum functionality we need is to be able to query a CoAP service about its resources. This is the equivalent of a standardized /index.html for CoAP. The naming of such resources should definitely be IETF consistent. This is what the charter says currently. Of course being able to make such a query multicast, using a standardized port, and to advertise it, is powerful already if done right.
>
KL>Understood, but I'm saying you need to be able to locate the CoAP
service instance
before you can query it. Thus, I'm saying that both functions are
necessary (or minimal).

> What we heard in Hiroshima (I think you were not present?) was that this WG needs to keep its scope very limited.
KL> I attended remotely.

>If there is a need for general discovery (what devices and services (using which protocols) exist in the first place?), sure you would use/modify an existing protocol like SLP or mDNS. Do we always need this for the kind of discovery in the energy and building automation applications that are the main focus here? As examples, HTTP web services for devices tend to use DPWS and BACnet has built-in naming and discovery. Can we even assume that constrained devices will implement many protocols in the first place?
>
KL> I'm trying to avoid requiring constrained devices to implement
more than one service
discovery protocol, by requiring at least one.  In the case of BACnet,
its discovery
mechanism relies on broadcast and is not IT friendly.  In order to
discover devices off-
net, special devices called BBMDs (BACnet Broadcast Management Devices) are
required.  A new WG, BACnet IT, has just been chartered to facilitate
the convergence
of BAC and IT networks.  Device discovery is one area being discussed.
 Obviously,
the whole industry would need to adopt a common mechanism, as they have now, to
ensure interoperability.
>>>
>>> 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.
>>>
>> KL> IMO, this is equivalent to the security discussion; we aren't
>> chartered to invent a new
>> constrained security protocol, but we do need to specify ONE baseline
>> selection that all
>> CoAP nodes will support, for interoperability.  Common device
>> naming/discovery/resolution
>> is an element necessary for interoperability.
>
> Yep, and CoAP nodes run CoAP. The built-in mechanism should be enough. If it is specified well, then that gives you interoperability without the minimum complexity.
>
>>>>>>>
>>>>>>> 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 bein
>>>  g 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.
>>>
>> KL>  As a thought experiment, remove DNS from the Internet and see
>> where that leaves
>> us.  Or, equivalently, deploy two or three similar mechanisms and let
>> people choose the
>> one they want.  That may work for a PC, but not for a constrained
>> device that will be up in
>> the ceiling for the next 30 years
>
> Exactly, this is why we included this basic mechanism in the protocol.
>
>>>>
>>>> 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?
>>>
>> I agree strongly with JP, as can be inferred from my comments above.
>> BACnet, for
>> example, models devices as collections of objects, objects as
>> collections of properties.
>> Viewed from a scoping perspective, BACnet device identifiers are
>> unique in network
>> scope, object IDs in device scope, property IDs in object scope.  So
>> yes, service
>> primitives for discovering the resources within a device are
>> absolutely within the charter.
>
> I have no problem with that. The charter already comes pretty close here.
>
>> But a separate protocol must be employed to discover those devices in
>> the first place.
>> If the choices for naming and discovery are left to each vendor or
>> industry then there
>> will be no interoperability.
>
> Now we get to the point. A separate protocol should not be *required* to discovery CoAP services in the first place.
>
> CoAP nodes run CoAP, and by simply doing a multicast CoAP READ on /resources using default CoAP UDP port 61626 (just a simplified example) there you go. Different industries will need to customize their interface definitions, and the idea is to allow that by including a URI to an interface description (e.g. WADL).
>
KL> It seems you're assuming a well-known port, which is OK, but it
means we need
some mechanism in the CoAP protocol (other than port) to demultiplex
multiple instances
running on the same host (as in the case of a proxy).  I am also
concerned about the
constraint implied by your comment that devices can only discover other CoAP
instances on the same link.  If CoAP nodes are to discover and communicate with
off-link devices, then I think this requires multicast support or a
name binding service.
If the latter, then let's not invent a new one.
>>
>> A closely related topic is what we mean by "device".  There is wording
>> in the draft
>> that contradicts any assumption about a 1:1 correspondence between "device" and
>> "host";  "Typically a single physical host on the network would have
>> just one Device
>> but a host may represent multiple logical Devices."  As I interpret
>> this, a device is
>> really an instance of the CoAP service (protocol).
>
> Good point, we should update the charter.
>
>> So the
>> naming/discovery choice
>> should be one that is lightweight and purpose-built for service discovery.
>> See draft-cheshire-dnsext-multicastdns-08.txt for an existence proof
>> and draft-cheshire-dnsext-dns-sd-05.txt, its complimentary extension.
>> To get a feeling for what these drafts mean by "service", see the list at
>> http://www.dns-sd.org/ServiceTypes.html
>
> Sure, if you need general service discovery there is nothing stopping you from using these (this was discussed in the BOF). In fact the charter already mentions that any naming for resources should be compatible with e.g. mDNS naming.
>
> What would make you happy here (yet still get us a WG)? We could of course include text saying that we will recommend a service discovery protocol that should be used in addition to CoAP, if such a step is needed. Cullen, do you think that is still compatible with the BOF?
>
KL> That language would make me happy :)

Regards, -K-
> Zach
>
>>
>> Regards, -K-
>>
>>
>>> 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.
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 6lowapp mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/6lowapp
>>>
>
> --
> 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.
>
>
>
>
>