Re: [6lowapp] Next rev of CoRE Charter

Kerry Lynn <kerlyn2001@gmail.com> Thu, 04 February 2010 14:48 UTC

Return-Path: <kerlyn2001@gmail.com>
X-Original-To: 6lowapp@core3.amsl.com
Delivered-To: 6lowapp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8475A3A6DCC for <6lowapp@core3.amsl.com>; Thu, 4 Feb 2010 06:48:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.522
X-Spam-Level:
X-Spam-Status: No, score=-1.522 tagged_above=-999 required=5 tests=[AWL=-1.077, BAYES_00=-2.599, FRT_BELOW2=2.154]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id plQFf0e8valr for <6lowapp@core3.amsl.com>; Thu, 4 Feb 2010 06:48:13 -0800 (PST)
Received: from mail-fx0-f225.google.com (mail-fx0-f225.google.com [209.85.220.225]) by core3.amsl.com (Postfix) with ESMTP id 4F8E03A6DCB for <6lowapp@ietf.org>; Thu, 4 Feb 2010 06:48:12 -0800 (PST)
Received: by fxm25 with SMTP id 25so568480fxm.14 for <6lowapp@ietf.org>; Thu, 04 Feb 2010 06:48:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=DaMFLT7Xy3heajhhzSzdig9nDRCWve62Tk8nMjOIAeU=; b=MUWLNc6xa7JQUnJzR84Lh0ZyrwHnoAMvtsvV1U2Mx0mg5SDw51FYnVZplyxL5+9Q/Z 9hqGCznKMEwvRbjZsJjHA8Py3CUnrBOnK3mtUnsdi6jbiYGFguvg1FeLvxqB8BD78GDE pfD69ta93V8G99P7yTqmeEMbAaYDzuHmsvkXA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=PCEolzFxsZSAAVD3kPAdPzhjS9VedTHlUERC0nHKyKRtp/4nDrOEWKphAUESx1U5M6 xCChw66zPWO0jRf5UDcGslTQyffwvvwNg8ISOvxykpXPFOB/jpPH+Muy0UoWDNe2AoZp X39lj1ezz0Ltmh80WMxLajR3TYHd7MT8qTjgA=
MIME-Version: 1.0
Received: by 10.216.89.209 with SMTP id c59mr648314wef.181.1265294934360; Thu, 04 Feb 2010 06:48:54 -0800 (PST)
In-Reply-To: <48FC8D18-9377-41C0-A0EF-39B9D8B6F646@sensinode.com>
References: <2A7B1CDC-5B99-47E8-9331-039D5997E1CC@cisco.com> <DFC50C8B-D84B-43E6-9691-503CC840ED5B@cisco.com> <EDB52132-2F9A-4201-BDB3-35B550428FEC@cisco.com> <A69482D3-B85B-4E28-A574-BCD9E17743B6@cisco.com> <48FC8D18-9377-41C0-A0EF-39B9D8B6F646@sensinode.com>
Date: Thu, 04 Feb 2010 09:48:54 -0500
Message-ID: <3fe58b591002040648j389b0090p93a69f7ae4f7f46e@mail.gmail.com>
From: Kerry Lynn <kerlyn2001@gmail.com>
To: Zach Shelby <zach@sensinode.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: 6lowapp@ietf.org
Subject: Re: [6lowapp] Next rev of CoRE Charter
X-BeenThere: 6lowapp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/6lowapp>, <mailto:6lowapp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6lowapp>
List-Post: <mailto:6lowapp@ietf.org>
List-Help: <mailto:6lowapp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lowapp>, <mailto:6lowapp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Feb 2010 14:48:14 -0000

Zach, JP, Cullen,

On Thu, Feb 4, 2010 at 3:56 AM, Zach Shelby <zach@sensinode.com> 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?
>
> 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.
>>>>>
>>>>> 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
>>
>> 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.
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.

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

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: +358 40 7796297
>
> 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
> 6lowapp@ietf.org
> https://www.ietf.org/mailman/listinfo/6lowapp
>