From behcetsarikaya@yahoo.com Mon Feb 1 12:26:12 2010 Return-Path: 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 A2EC53A6981 for <6lowapp@core3.amsl.com>; Mon, 1 Feb 2010 12:26:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 cxLwRD2vDHlS for <6lowapp@core3.amsl.com>; Mon, 1 Feb 2010 12:26:11 -0800 (PST) Received: from web111413.mail.gq1.yahoo.com (web111413.mail.gq1.yahoo.com [67.195.15.204]) by core3.amsl.com (Postfix) with SMTP id A091D3A67EF for <6lowapp@ietf.org>; Mon, 1 Feb 2010 12:26:11 -0800 (PST) Received: (qmail 27850 invoked by uid 60001); 1 Feb 2010 20:26:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1265056004; bh=vauAKn3mXjlEU4B8tPcem/h6ATaLi+CLN5onJ0iGFeM=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=lKOdmjEagUcOl/OKTlW2NkLByrKmCGEZKaFJlldYkNXJmGXpwlVb5jdcqUlv4LFBinHol32R7MWK/Zuj/H2rc8u46BmJQklf+YTcsTmyoVFDQALCHUJlrwUIBBb8bIxtbjwtiAFP9wcJbXMUIa1GrzBVPCaknAOgFVd4ZsJIyjo= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=NyeZwr4AZk1MXVqduMRgOkrt80AOXDEYtT2SOtvAshaELyphZwNeCRUIqRfvBL0NxdYW/J2JytAqRcBaAwxI7iiq0xH2daerWLNmOu1qLTpKEwSPjB6hR4AsdQ0U6PLFYVnkLd3R36KiHYjO4MR08zQWaH8Cjd0cBgW60q4Vols=; Message-ID: <237883.27408.qm@web111413.mail.gq1.yahoo.com> X-YMail-OSG: qM_R.QoVM1kiPOp.dDC.68PoILzGW8Geb1lJz7D5zOSFFp2ScWLeQbo8eG2rLQLHz6AcXyL32OzEu.WvtaqhPGiC9odpwL.0KWu3wNzY_0mohwWtlUEauitACC_FNA21KIMfdPTvt6ZD9eU8v9u1wPo0LEKcnrjR7a2ZZrZfovHE4YvYT66TVw1wBzUNEH2TMhiI12CYl8fr6qLDWgcfO1gLR0mo2IM1b3OeOGM.AiLqzw_BoSPHcGg_UrTNsC.X9nAZI9x0TP1PIhbKpCQOvtwQlWm0okRRFd1uL9N3Hm2RvyGzmn4XwdeVlOmImAP_TLy9fOQ_1B9FgYWYHoFhSCb8KCtV6vCuyp1w6uH0WFRRr_xeKq2nXA-- Received: from [206.16.17.212] by web111413.mail.gq1.yahoo.com via HTTP; Mon, 01 Feb 2010 12:26:44 PST X-Mailer: YahooMailRC/272.7 YahooMailWebService/0.8.100.260964 References: <2A7B1CDC-5B99-47E8-9331-039D5997E1CC@cisco.com> Date: Mon, 1 Feb 2010 12:26:44 -0800 (PST) From: Behcet Sarikaya To: Cullen Jennings , 6lowapp@ietf.org In-Reply-To: <2A7B1CDC-5B99-47E8-9331-039D5997E1CC@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [6lowapp] Next rev of CoRE Charter X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2010 20:26:12 -0000 Hi Cullen,=0A=A0 I have a few minor corrections on the charter:=0A=0A=0A=0A= ----- Original Message ----=0A> From: Cullen Jennings =0A= > To: 6lowapp@ietf.org=0A> Sent: Sat, January 30, 2010 12:16:14 PM=0A> Subj= ect: [6lowapp] Next rev of CoRE Charter=0A> =0A> CoRE (Constrained RESTful = Environments)=0A> =0A> CoRE is providing a framework for resource-oriented = applications=0A> intended to run on constrained IP networks.=A0 A constrain= ed IP network=0A> has limited packet sizes, may exhibit a high degree of pa= cket loss, and=0A> may have a substantial number of devices that may be pow= ered off at any=0A> point in time but periodically "wake up" for brief peri= ods of time.=0A> These networks and the nodes within them are characterized= by severe=0A> limits on throughput, available power, and particularly on t= he=0A> complexity that can be supported with limited code size and limited = RAM=0A> per node.=A0 More generally, we speak of constrained networks whene= ver at=0A> least some of the nodes and networks involved exhibit these=0A> = characteristics.=A0 Low-Power Wireless Personal Area Networks (LoWPANs)=0A>= are an example of this type of network. LoWPANs are part of home and=0A> b= uilding automation, energy management, and the Internet of Things.=0A> =0A>= The CoRE working group will define a framework for a limited class of=0A> = applications: those that deal with the manipulation of simple resources=0A>= on constrained networks. This includes applications to monitor simple=0A> = sensors (e.g. temperature sensors, light switches, and power meters), to=0A= > control actuators (e.g. light switches, heating controllers, and door=0A>= locks), and to manage devices.=0A> =0A> The general architecture consists = of nodes on the constrained network,=0A> called Devices, that are responsib= le for one or more Resources that may=0A> represent sensors, actuators, com= binations of values or other=0A> information.=A0 Devices send messages to c= hange and query resources on=0A> other Devices. Devices can send notificati= ons about changed resource=0A> values to Devices that have subscribed to re= ceive notification about=0A> changes. A Device can also publish or be queri= ed about its=0A=0A>=A0description. =0A=0Aresources.=0A=0A>Typically a singl= e physical host on the network would have=0A> just one Device but a host ma= y represent multiple logical Devices. As=0A> part of the framework for buil= ding these applications, the WG will=0A> define a Constrained Application P= rotocol (CoAP) for the manipulation of=0A> Resources on a Device.=0A> =0A> = CoAP will be designed for use between Devices on the same constrained=0A> n= etwork, between Devices and general nodes on the Internet, and between=0A> = Devices on different constrained networks both joined by an=0A> internet. C= oAP targets the type of operating environments defined in the=0A> ROLL and = 6LOWPAN working groups which have additional constraints=0A> compared to no= rmal IP networks, but the CoAP protocol will also operate=0A> over traditio= nal IP networks.=0A> =0A> There also may be translators that interconnect b= etween other Internet=0A> protocols and the Devices using the CoAP protocol= .=A0 The WG will define a=0A> mapping from CoAP to an HTTP REST API; this m= apping will not depend on a=0A> specific application. It is worth noting th= at translation does not have=0A> to occur at the boundary between the const= rained network and the more=0A> general network, but can be deployed at var= ious locations in the=0A> unconstrained network.=0A> =0A> CoAP will support= various forms of "caching".=A0 For example, if a=0A> temperature sensor is= normally asleep but wakes up every five minutes=0A> and sends the current = temperature to a translator that has subscribed,=0A> when the translator re= ceives a request over HTTP for that temperature=0A> resource, it can respon= d with the last seen value instead of trying to=0A> query the Device which = is currently asleep.=0A> =0A> The initial work item of the WG is to define = a protocol specification=0A> for CoAP that includes:=0A> =0A> 1) The abilit= y to create, read, update and delete a Resource on a=0A> =A0 Device.=0A> = =0A> 2) The ability to allow a Device to publish a value or event to anothe= r=0A> =A0 Device that has subscribed to be notified of changes, as well as = the=0A> =A0 way for a Device to subscribe to receive publishes from another= =0A> =A0 Device.=0A> =0A> 3) The ability to support a non-reliable multicas= t message to be sent to=0A> =A0 a group of Devices to manipulate a resource= on all the =0A>Devices .=0A=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ^=0A=0A= add : in the group=0A=0A=0A> =0A> 4) The core CoAP functionality MUST opera= te well over UDP and UDP MUST=0A> =A0 be implemented on CoAP Devices.=A0 Th= ere may be OPTIONAL functions in=0A> =A0 CoAP (e.g. delivery of larger chun= ks of data) which if implemented=0A> =A0 are implemented over TCP. Applicat= ions which require the optional TCP=0A> =A0 features will limit themselves = to a narrower subset of deployment=0A> =A0 cases.=0A> =0A> 5) A definition = of how to use CoAP to advertise about or query for a=0A> =A0 Device's descr= iption. This description may include the device name=0A> =A0 and a list of = its Resources, each with a URL, an interface=0A> =A0 description URI (point= ing e.g. to a =0A=0A>WADL=0AWeb Application Description Language (WADL)=0A= =0A=0A>=A0document) and an optional=0A> =A0 name. The name taxonomy used fo= r this description will be consistent=0A> =A0 with other IETF work, e.g. = =0A=0A>draft-cheshire-dnsext-dns-sd.=0A=0AThis document expired years ago?= =0A=0ARegards,=0A=0ABehcet=0A=0A=0A From jvasseur@cisco.com Tue Feb 2 01:26:20 2010 Return-Path: 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 B3DFF28C231 for <6lowapp@core3.amsl.com>; Tue, 2 Feb 2010 01:26:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.914 X-Spam-Level: X-Spam-Status: No, score=-9.914 tagged_above=-999 required=5 tests=[AWL=0.685, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 AWrSof83MgGk for <6lowapp@core3.amsl.com>; Tue, 2 Feb 2010 01:26:19 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 1430F28C22A for <6lowapp@ietf.org>; Tue, 2 Feb 2010 01:26:19 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEALJ+Z0utJV2a/2dsb2JhbAC/Updugj2CCAQ X-IronPort-AV: E=Sophos;i="4.49,389,1262563200"; d="scan'208";a="294888584" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by sj-iport-1.cisco.com with ESMTP; 02 Feb 2010 09:26:56 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id o129QrmX017727 for <6lowapp@ietf.org>; Tue, 2 Feb 2010 09:26:56 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Feb 2010 10:26:43 +0100 Received: from dhcp-lyon-144-254-54-125.cisco.com ([144.254.54.125]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Feb 2010 10:26:42 +0100 Message-Id: From: JP Vasseur To: Cullen Jennings In-Reply-To: <2A7B1CDC-5B99-47E8-9331-039D5997E1CC@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 2 Feb 2010 08:57:54 +0100 References: <2A7B1CDC-5B99-47E8-9331-039D5997E1CC@cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 02 Feb 2010 09:26:42.0981 (UTC) FILETIME=[D5012550:01CAA3E9] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.000.1038-17168.004 X-TM-AS-Result: No--38.968200-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2010 09:26:20 -0000 Hi Cullen, First comment is that I fully support the charter, and look forward to seeing an active WG, lots of items that we need to work on :-) Comments below, On Jan 30, 2010, at 7:16 PM, Cullen Jennings wrote: > > Thanks to all the great comments form people and the work from Zach, > Carsten, and Lisa for this this version. This version clarified a > bunch of issues and also removed a bunch of text that did really > need to be in the charter. Documents tend to have words added over > time and every so often they need to go on a diet :-) I'm really > happy with this version and my view is that it is probably close > enough to send to the IESG. Just to let everyone on the list know > the process here, what happens next is: > > 1) See if there are any last minute screams on the email list about > this version of the charter > > 2) Send it to the AD (Lisa). She might have some changes before she > moves it forward to the IESG but Lisa's been very involved along the > way here so no expecting any huge surprises at that pint > > 3) Lisa puts in an schedule for IESG call and IAB and EISG look at > it. Some change might happen. > > 4) The IESG sends it out to the whole community for and IETF Last > Call. Anyone including folks on this list can send comment. LIkely > some changes. > > 5) It gets put back on an IESG call for formal approval as a WG > > There's variants of how things can happen but the above is roughly > what I expect to happen for this charter. > > I've attached the charter below. If you see something in it you > really can't live with, yell. If you see typos, things that need > better wording, or so on, send proposed text changes. > > One chug was we removed the word CoGII and instead just talked about > translators. Another word we could that was suggested was "proxy" or > just talk about things that provide a "mapping function". I really > don't much of an opinion about which of these words, or others, > would be best but if people have thoughts, Speak up. > > Thanks, Cullen > > ------------------------------------------------------------ > > > CoRE (Constrained RESTful Environments) > > CoRE is providing a framework for resource-oriented applications > intended to run on constrained IP networks. A constrained IP network > has limited packet sizes, may exhibit a high degree of packet loss, > and > may have a substantial number of devices that may be powered off at > any > point in time but periodically "wake up" for brief periods of time. JP> 1) I would suggest to first try to adopt a common "language" across Working Groups. In ROLL, we use the term LLN to refer to Low power and Lossy Networks. Using similar terminology could help. 2) I'd slightly reword to say that LLN are characterized by constrained environments in terms of devices (CPU, Memory, power) interconnected by low speed lossy links. > These networks and the nodes within them are characterized by severe > limits on throughput, available power, and particularly on the > complexity that can be supported with limited code size and limited > RAM > per node. More generally, we speak of constrained networks whenever > at > least some of the nodes and networks involved exhibit these > characteristics. Low-Power Wireless Personal Area Networks (LoWPANs) > are an example of this type of network. LoWPANs are part of home and > building automation, energy management, and the Internet of Things. JP> I would definitely suggest to remove that last sentence ... We've been struggling with the term 6lowpan, trying to explain that "The Internet Of Things" refers to the use of IPv6 in LLNs. 6LoWPAN is one instantiation for IPv6 in IEEE 802.15.4 but there are many other low power link layers, and this is one of the beauty of IP to be able to support those. The Internet of things will (and is already) made of such low power link layers. That looks like a cosmetic terminology comment but it will avoid a ton of confusion. > > The CoRE working group will define a framework for a limited class of > applications: those that deal with the manipulation of simple > resources > on constrained networks. This includes applications to monitor simple > sensors (e.g. temperature sensors, light switches, and power > meters), to > control actuators (e.g. light switches, heating controllers, and door > locks), and to manage devices. > > The general architecture consists of nodes on the constrained network, > called Devices, that are responsible for one or more Resources that > may > represent sensors, actuators, combinations of values or other > information. Devices send messages to change and query resources on > other Devices. Devices can send notifications about changed resource > values to Devices that have subscribed to receive notification about > changes. A Device can also publish or be queried about its > description. Typically a single physical host on the network would > have > just one Device but a host may represent multiple logical Devices. As > part of the framework for building these applications, the WG will > define a Constrained Application Protocol (CoAP) for the > manipulation of > Resources on a Device. > > CoAP will be designed for use between Devices on the same constrained > network, between Devices and general nodes on the Internet, and > between > Devices on different constrained networks both joined by an > internet. CoAP targets the type of operating environments defined in > the > ROLL and 6LOWPAN working groups which have additional constraints > compared to normal IP networks, but the CoAP protocol will also > operate > over traditional IP networks. > > There also may be translators that interconnect between other Internet > protocols and the Devices using the CoAP protocol. The WG will > define a > mapping from CoAP to an HTTP REST API; this mapping will not depend > on a > specific application. It is worth noting that translation does not > have > to occur at the boundary between the constrained network and the more > general network, but can be deployed at various locations in the > unconstrained network. It might be worth clearly spelling out that such "Translators" are not protocol translation gateways but sensor, devices, ... are IPv6 enabled devices. > > CoAP will support various forms of "caching". For example, if a > temperature sensor is normally asleep but wakes up every five minutes > and sends the current temperature to a translator that has subscribed, > when the translator receives a request over HTTP for that temperature > resource, it can respond with the last seen value instead of trying to > query the Device which is currently asleep. Completely in line with that architecture. Just note that nothing prevent an end device with enough resource to natively support HTTP though. > > The initial work item of the WG is to define a protocol specification > for CoAP that includes: > > 1) The ability to create, read, update and delete a Resource on a > Device. > > 2) The ability to allow a Device to publish a value or event to > another > Device that has subscribed to be notified of changes, as well as the > way for a Device to subscribe to receive publishes from another > Device. > > 3) The ability to support a non-reliable multicast message to be > sent to > a group of Devices to manipulate a resource on all the Devices. > > 4) The core CoAP functionality MUST operate well over UDP and UDP MUST > be implemented on CoAP Devices. There may be OPTIONAL functions in > CoAP (e.g. delivery of larger chunks of data) which if implemented > are implemented over TCP. Applications which require the optional > TCP > features will limit themselves to a narrower subset of deployment > cases. I would suggest to delete the last sentence though. > > 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. > > 6) Specification for the HTTP REST based API and translation to > communicate with Devices. Translation should make use of Device > description information and should not need code updates to deal > with > new Devices. > > 7) Consider operational and manageability aspects of the protocol > and at > a minimum provide a way to tell if a Device is powered on or not. That is a really a "minimum" ... do we need to be so restrictive ? > > 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. > > Security, particularly keying of new Devices, is very challenging for > these applications. The WG will work to select approaches to security > bootstrapping which are realistic given the constraints and > requirements > of the network. To ensure that any two nodes can join together, all > nodes must implement at least one universal bootstrapping method. > > Security can be achieved using either session security or object > security. For both object and session security, the WG will work with > the security area to select appropriate security framework and > protocol > as well as selecting a minimal required to implement cipher suite. > CoAP > will initially look at CMS (RFC 5652), TLS/DTLS, and EAP. > > The WG will coordinate on requirements from many organizations > including > OpenSG/NIST, ZigBee/HomePlug, IPSO Alliance, OASIS, SENSEI, > ASHRAE/BACnet; other SDOs and organizations. The WG will closely > coordinate with other IETF WGs including ROLL, 6LoWPAN, and > appropriate > groups in the IETF OPS and Security areas. > > Milestones: > > Apr 2010 - Select WG document for basis of the CoAP protocol > > Dec 2010 - CoAP protocol specification with mapping to HTTP Rest API > submitted to IESG as PS > > Dec 2010 - Constrained security bootstrapping specification > submitted to > IESG as PS > > Jan 2011 - Recharter to add things reduced out of initial scope > > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp From fluffy@cisco.com Tue Feb 2 12:42:39 2010 Return-Path: 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 7445E3A6B56 for <6lowapp@core3.amsl.com>; Tue, 2 Feb 2010 12:42:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.475 X-Spam-Level: X-Spam-Status: No, score=-110.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 jqR8NDCKEVYh for <6lowapp@core3.amsl.com>; Tue, 2 Feb 2010 12:42:38 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id B04D93A6B3F for <6lowapp@ietf.org>; Tue, 2 Feb 2010 12:42:34 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEALUcaEurR7H+/2dsb2JhbADBGZgxhEUE X-IronPort-AV: E=Sophos;i="4.49,393,1262563200"; d="scan'208";a="210567689" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 02 Feb 2010 20:43:14 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o12KhDCC007145; Tue, 2 Feb 2010 20:43:14 GMT Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <237883.27408.qm@web111413.mail.gq1.yahoo.com> Date: Tue, 2 Feb 2010 13:43:12 -0700 Content-Transfer-Encoding: 7bit Message-Id: <9E9EA361-BA8F-41D8-8842-5BD2608B6F8E@cisco.com> References: <2A7B1CDC-5B99-47E8-9331-039D5997E1CC@cisco.com> <237883.27408.qm@web111413.mail.gq1.yahoo.com> To: Behcet Sarikaya X-Mailer: Apple Mail (2.1077) 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2010 20:42:39 -0000 thank - I put theses in the next version... On Feb 1, 2010, at 1:26 PM, Behcet Sarikaya wrote: > Hi Cullen, > I have a few minor corrections on the charter: > From fluffy@cisco.com Tue Feb 2 13:50:17 2010 Return-Path: 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 8964A3A680D for <6lowapp@core3.amsl.com>; Tue, 2 Feb 2010 13:50:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.404 X-Spam-Level: X-Spam-Status: No, score=-109.404 tagged_above=-999 required=5 tests=[AWL=-0.959, BAYES_00=-2.599, FRT_BELOW2=2.154, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 ibVSUtzVH30N for <6lowapp@core3.amsl.com>; Tue, 2 Feb 2010 13:50:15 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 391B63A6B2E for <6lowapp@ietf.org>; Tue, 2 Feb 2010 13:50:15 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.49,393,1262563200"; d="scan'208";a="295167170" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 02 Feb 2010 21:50:55 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o12Lorpo001345; Tue, 2 Feb 2010 21:50:54 GMT Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: Date: Tue, 2 Feb 2010 14:50:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2A7B1CDC-5B99-47E8-9331-039D5997E1CC@cisco.com> To: JP Vasseur X-Mailer: Apple Mail (2.1077) 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2010 21:50:17 -0000 Hi JP,=20 Thanks for comments. Some questions inline before I figure out how to = integrate these. If this email makes no sense, drop me a note and I'll = give you a phone call and figure out to sort it out.=20 Cullen On Feb 2, 2010, at 12:57 AM, JP Vasseur wrote: > Hi Cullen, >=20 > First comment is that I fully support the charter, and look forward to = seeing an active WG, lots of > items that we need to work on :-) >=20 > Comments below, >=20 > On Jan 30, 2010, at 7:16 PM, Cullen Jennings wrote: >=20 >>=20 >> Thanks to all the great comments form people and the work from Zach, = Carsten, and Lisa for this this version. This version clarified a bunch = of issues and also removed a bunch of text that did really need to be in = the charter. Documents tend to have words added over time and every so = often they need to go on a diet :-) I'm really happy with this version = and my view is that it is probably close enough to send to the IESG. = Just to let everyone on the list know the process here, what happens = next is: >>=20 >> 1) See if there are any last minute screams on the email list about = this version of the charter >>=20 >> 2) Send it to the AD (Lisa). She might have some changes before she = moves it forward to the IESG but Lisa's been very involved along the way = here so no expecting any huge surprises at that pint >>=20 >> 3) Lisa puts in an schedule for IESG call and IAB and EISG look at = it. Some change might happen. >>=20 >> 4) The IESG sends it out to the whole community for and IETF Last = Call. Anyone including folks on this list can send comment. LIkely some = changes. >>=20 >> 5) It gets put back on an IESG call for formal approval as a WG >>=20 >> There's variants of how things can happen but the above is roughly = what I expect to happen for this charter. >>=20 >> I've attached the charter below. If you see something in it you = really can't live with, yell. If you see typos, things that need better = wording, or so on, send proposed text changes. >>=20 >> One chug was we removed the word CoGII and instead just talked about = translators. Another word we could that was suggested was "proxy" or = just talk about things that provide a "mapping function". I really don't = much of an opinion about which of these words, or others, would be best = but if people have thoughts, Speak up. >>=20 >> Thanks, Cullen >>=20 >> ------------------------------------------------------------ >>=20 >>=20 >> CoRE (Constrained RESTful Environments) >>=20 >> CoRE is providing a framework for resource-oriented applications >> intended to run on constrained IP networks. A constrained IP network >> has limited packet sizes, may exhibit a high degree of packet loss, = and >> may have a substantial number of devices that may be powered off at = any >> point in time but periodically "wake up" for brief periods of time. >=20 > JP> > 1) I would suggest to first try to adopt a common "language" across = Working > Groups. In ROLL, we use the term LLN to refer to Low power and Lossy = Networks. > Using similar terminology could help. Agree with common language in general but in some earlier but in earlier = discussion I understood from people and LLN was a description about the = network and not so much the constraints of the hosts that ran on it. (I = may have totally misunderstood what they were saying) It seemed like = what people were trying to say here was a related to but not the same as = LLN. Can you point at the best definition of LLN over in ROLL and = perhaps I can try and sort this out.=20 > 2) I'd slightly reword to say that LLN are characterized by = constrained environments > in terms of devices (CPU, Memory, power) interconnected by low speed = lossy links. >=20 >> These networks and the nodes within them are characterized by severe >> limits on throughput, available power, and particularly on the >> complexity that can be supported with limited code size and limited = RAM >> per node. More generally, we speak of constrained networks whenever = at >> least some of the nodes and networks involved exhibit these >> characteristics. Low-Power Wireless Personal Area Networks (LoWPANs) >> are an example of this type of network. LoWPANs are part of home and >> building automation, energy management, and the Internet of Things. >=20 > JP> I would definitely suggest to remove that last sentence ... We've = been struggling > with the term 6lowpan, trying to explain that "The Internet Of Things" = refers to the > use of IPv6 in LLNs. 6LoWPAN is one instantiation for IPv6 in IEEE = 802.15.4 but > there are many other low power link layers, and this is one of the = beauty of IP to > be able to support those. The Internet of things will (and is already) = made of such > low power link layers. That looks like a cosmetic terminology comment = but it will > avoid a ton of confusion. I think that was my mistake - Thanks for catching. What I was trying to = do is motivate they type of places that might be able to use the output = of the CoRE WG. What I was trying to say is "Constrained networks can = occur as part of home and building automation, energy management, and = the Internet of Things."=20 >=20 >>=20 >> The CoRE working group will define a framework for a limited class of >> applications: those that deal with the manipulation of simple = resources >> on constrained networks. This includes applications to monitor simple >> sensors (e.g. temperature sensors, light switches, and power meters), = to >> control actuators (e.g. light switches, heating controllers, and door >> locks), and to manage devices. >>=20 >> The general architecture consists of nodes on the constrained = network, >> called Devices, that are responsible for one or more Resources that = may >> represent sensors, actuators, combinations of values or other >> information. Devices send messages to change and query resources on >> other Devices. Devices can send notifications about changed resource >> values to Devices that have subscribed to receive notification about >> changes. A Device can also publish or be queried about its >> description. Typically a single physical host on the network would = have >> just one Device but a host may represent multiple logical Devices. As >> part of the framework for building these applications, the WG will >> define a Constrained Application Protocol (CoAP) for the manipulation = of >> Resources on a Device. >>=20 >> CoAP will be designed for use between Devices on the same constrained >> network, between Devices and general nodes on the Internet, and = between >> Devices on different constrained networks both joined by an >> internet. CoAP targets the type of operating environments defined in = the >> ROLL and 6LOWPAN working groups which have additional constraints >> compared to normal IP networks, but the CoAP protocol will also = operate >> over traditional IP networks. >>=20 >> There also may be translators that interconnect between other = Internet >> protocols and the Devices using the CoAP protocol. The WG will = define a >> mapping from CoAP to an HTTP REST API; this mapping will not depend = on a >> specific application. It is worth noting that translation does not = have >> to occur at the boundary between the constrained network and the more >> general network, but can be deployed at various locations in the >> unconstrained network. >=20 > It might be worth clearly spelling out that such "Translators" are not = protocol > translation gateways but sensor, devices, ... are IPv6 enabled = devices. I might not be understanding what point you are getting at here. Uh, I = think we have had pretty clear input the CoRE application level could be = running over v4 or v6. The charters tried to be pretty explicit that it = is not v6 specific. I'm trying to reflect the consensus here and the = actually consensus call would be up to Lisa as the AD but I did get a = fair amount of input on topic and it all seemed to go towards the = direction of, yes this definitely has to work on v6, but to make = something that is above layer 3 be only for v6 would encourage layer = violations of the worst kind and there was no need for that. I think the = general approach for IETF application layer protocols is to work on both = v4 and v6 unless there is some really good reason they can't.=20 >=20 >>=20 >> CoAP will support various forms of "caching". For example, if a >> temperature sensor is normally asleep but wakes up every five minutes >> and sends the current temperature to a translator that has = subscribed, >> when the translator receives a request over HTTP for that temperature >> resource, it can respond with the last seen value instead of trying = to >> query the Device which is currently asleep. >=20 > Completely in line with that architecture. Just note that nothing = prevent an end > device with enough resource to natively support HTTP though. Yep - agree. But do we need to say anything about that here? I'm just = not sure what words to put in. Clearly we can do HTTP/Rest API over IP = today without any new standardization. Nothing here would be saying = don't do that.=20 >=20 >>=20 >> The initial work item of the WG is to define a protocol specification >> for CoAP that includes: >>=20 >> 1) The ability to create, read, update and delete a Resource on a >> Device. >>=20 >> 2) The ability to allow a Device to publish a value or event to = another >> Device that has subscribed to be notified of changes, as well as the >> way for a Device to subscribe to receive publishes from another >> Device. >>=20 >> 3) The ability to support a non-reliable multicast message to be sent = to >> a group of Devices to manipulate a resource on all the Devices. >>=20 >> 4) The core CoAP functionality MUST operate well over UDP and UDP = MUST >> be implemented on CoAP Devices. There may be OPTIONAL functions in >> CoAP (e.g. delivery of larger chunks of data) which if implemented >> are implemented over TCP. Applications which require the optional = TCP >> features will limit themselves to a narrower subset of deployment >> cases. >=20 > I would suggest to delete the last sentence though. There as a lot of discussion leading to this sentence and I'm cautions = to open the can worms. The issues of taking it out is the following. = Clearly some people think that TCP won't meet all the needs or we would = probably not bother to do UDP at all. But given you are doing UDP, why = would you bother with TCP, and the answer is there are probably good = reasons to use it in some cases. Then the questions comes up, so OK what = about when you don't have it. We end of with this circular argument = about the everything that works over UDP must work over TCP and visa = versa so why have both. This sentence in the charter tries to break that = argument by pointing out the obvious which is some stuff is just not = going to be work as well, if at all, over UDP and also TCP is not going = to be available 100% of the time. I realize this paragraph makes almost = no sense but I hope you can figure out what I am getting at if not, glad = to give you a call and get to the point where I can explain well enough = to fix this email >=20 >>=20 >> 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. >=20 > 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) >=20 >>=20 >> 6) Specification for the HTTP REST based API and translation to >> communicate with Devices. Translation should make use of Device >> description information and should not need code updates to deal = with >> new Devices. >>=20 >> 7) Consider operational and manageability aspects of the protocol and = at >> a minimum provide a way to tell if a Device is powered on or not. >=20 > That is a really a "minimum" ... do we need to be so restrictive ? It's definitely a pretty minimal minimum. The question is what do we add = beyond that and do we need to do it in the charter. Note this bullet = does not stop the WG from doing more, just sets a minimum bar. Honestly, = this bar is so low but every time I tried to raise the bar, I failed. = Ideas welcome. I pretty much expect that folks would have a way of = finding out things like firmware version and such but do to the privacy = aspects of some of that, people have argued that would be one of the = "Resources" defined which you can access via the CoRE protocol and not = part of the CoRE protocol itself. I'm working with Dan Romascanu (Ops = AD) has been following this charter and I know he is has sent me some = emails that I have not got to yet so I expect to be able to improve this = point a bit but doubt we can figure out any really significant changes = that can get widespread agreement.=20 >=20 >>=20 >> The working group will not develop a reliable multicast solution, and >> will not develop a general service discovery solution. >=20 > 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.=20 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.=20 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. >> description.=20 >=20 >>=20 >> Security, particularly keying of new Devices, is very challenging for >> these applications. The WG will work to select approaches to security >> bootstrapping which are realistic given the constraints and = requirements >> of the network. To ensure that any two nodes can join together, all >> nodes must implement at least one universal bootstrapping method. >>=20 >> Security can be achieved using either session security or object >> security. For both object and session security, the WG will work = with >> the security area to select appropriate security framework and = protocol >> as well as selecting a minimal required to implement cipher suite. = CoAP >> will initially look at CMS (RFC 5652), TLS/DTLS, and EAP. >>=20 >> The WG will coordinate on requirements from many organizations = including >> OpenSG/NIST, ZigBee/HomePlug, IPSO Alliance, OASIS, SENSEI, >> ASHRAE/BACnet; other SDOs and organizations. The WG will closely >> coordinate with other IETF WGs including ROLL, 6LoWPAN, and = appropriate >> groups in the IETF OPS and Security areas. >>=20 >> Milestones: >>=20 >> Apr 2010 - Select WG document for basis of the CoAP protocol >>=20 >> Dec 2010 - CoAP protocol specification with mapping to HTTP Rest API >> submitted to IESG as PS >>=20 >> Dec 2010 - Constrained security bootstrapping specification submitted = to >> IESG as PS >>=20 >> Jan 2011 - Recharter to add things reduced out of initial scope >>=20 >>=20 >> _______________________________________________ >> 6lowapp mailing list >> 6lowapp@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowapp >=20 From behcetsarikaya@yahoo.com Tue Feb 2 14:08:39 2010 Return-Path: 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 2FE813A68D5 for <6lowapp@core3.amsl.com>; Tue, 2 Feb 2010 14:08:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.188 X-Spam-Level: X-Spam-Status: No, score=-1.188 tagged_above=-999 required=5 tests=[AWL=-1.077, BAYES_00=-2.599, FRT_BELOW2=2.154, IP_NOT_FRIENDLY=0.334] 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 AtolAvS6W+cW for <6lowapp@core3.amsl.com>; Tue, 2 Feb 2010 14:08:37 -0800 (PST) Received: from web111410.mail.gq1.yahoo.com (web111410.mail.gq1.yahoo.com [67.195.15.186]) by core3.amsl.com (Postfix) with SMTP id A00FC3A67A6 for <6lowapp@ietf.org>; Tue, 2 Feb 2010 14:08:28 -0800 (PST) Received: (qmail 34276 invoked by uid 60001); 2 Feb 2010 22:09:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1265148546; bh=Sa1769HOSlSfC4ujnYzHZTaMUzOYJ0P6BLsJlPSBP0A=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=0f8OqxZmUyQRLtZJytqu9fKiVtv6dwVVICpnv9KfCra2WSWpQNdS9X2XL9RBlfuYec2dCJuBTcEimMk3xIJ3brH2Fj8s9yZ9Mik5WzOiNKi+B89+xyKL7HPDt4tl5U5Sv7nNGdVfGJDWnfFNA2p71evq4+VmO/m6gpVRpWawBuM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=L7PaKi006Q80ikVMZxBb6DPJhrj+yKud/JGbhz4CqDxSiLzXDGMFQtaWP5HIm5VPQPoAomywlJHgW/0VFMa6BeGCfZN3uNsEihmcNWXsHcGIG8ZAu1mEYPBo1u0hvKCGQ7Y4THqwVG6ifKR6NNOAc/+00e7D0t9dXhNn8PMiMx8=; Message-ID: <8512.34105.qm@web111410.mail.gq1.yahoo.com> X-YMail-OSG: MU.qphgVM1mpP2PGyPjfx_y1RnUtdIREvA0i6wrE0aT4rCzte4cJ.vYehaOsrMAmqYc.J4JbwLmKqLam0frohMZ07jkhgfiyWH54nxiR8PYLSeVYoWqR6Fu1I5HJwEQQBg8YFVwzu5svdPGFP94L8P9GkYgWpTponDwLMdcu34uSUVszCQBuh6FhKR5eqKarw5SfpL5.c0hHP1w6q.qcJmcPqmhaOeBIL6cpZxnnifg.9SSMb7TKiBJ_JpfQekfnPuSKPgLpRqCJcpkONOvDIFDlhHmzzTB7L4.6HH0RmPgJjsC8oytvVjnN9.fXBw4slPTIoZtBiIBLtUJ4FZfFIP7Eg5IlWsQLUHZDe6Hk Received: from [206.16.17.212] by web111410.mail.gq1.yahoo.com via HTTP; Tue, 02 Feb 2010 14:09:00 PST X-Mailer: YahooMailRC/272.7 YahooMailWebService/0.8.100.260964 References: <2A7B1CDC-5B99-47E8-9331-039D5997E1CC@cisco.com> Date: Tue, 2 Feb 2010 14:09:00 -0800 (PST) From: Behcet Sarikaya To: Cullen Jennings , JP Vasseur In-Reply-To: MIME-Version: 1.0 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 Reply-To: Behcet Sarikaya List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2010 22:08:39 -0000 Instead of removing LoWPAN how about =0ALow-Power Wireless Personal Area Ne= tworks (LoWPANs) =0A=0Aadd here =0Awith=A0IEEE 802.15.4 or many other low p= ower link layers.=0A=0AThat would require less changes.=0A=0AMy 2 cents.=0A= =0ABehcet=0A=0A=0A=0A=0A----- Original Message ----=0A> From: Cullen Jennin= gs =0A> To: JP Vasseur =0A> Cc: 6lowa= pp@ietf.org=0A> Sent: Tue, February 2, 2010 3:50:52 PM=0A> Subject: Re: [6l= owapp] Next rev of CoRE Charter=0A> =0A> =0A> Hi JP, =0A> =0A> Thanks for c= omments. Some questions inline before I figure out how to integrate =0A> th= ese.=A0 If this email makes no sense, drop me a note and I'll give you a ph= one =0A> call and figure out to sort it out. =0A> =0A> Cullen=0A> =0A> =0A>= On Feb 2, 2010, at 12:57 AM, JP Vasseur wrote:=0A> =0A> > Hi Cullen,=0A> >= =0A> > First comment is that I fully support the charter, and look forward= to seeing =0A> an active WG, lots of=0A> > items that we need to work on := -)=0A> > =0A> > Comments below,=0A> > =0A> > On Jan 30, 2010, at 7:16 PM, C= ullen Jennings wrote:=0A> > =0A> >> =0A> >> Thanks to all the great comment= s form people and the work from Zach, Carsten, =0A> and Lisa for this this = version. This version clarified a bunch of issues and =0A> also removed a b= unch of text that did really need to be in the charter. =0A> Documents tend= to have words added over time and every so often they need to go =0A> on a= diet :-) I'm really happy with this version and my view is that it is =0A>= probably close enough to send to the IESG. Just to let everyone on the lis= t know =0A> the process here, what happens next is:=0A> >> =0A> >> 1) See i= f there are any last minute screams on the email list about this =0A> versi= on of the charter=0A> >> =0A> >> 2) Send it to the AD (Lisa). She might hav= e some changes before she moves it =0A> forward to the IESG but Lisa's been= very involved along the way here so no =0A> expecting any huge surprises a= t that pint=0A> >> =0A> >> 3) Lisa puts in an schedule for IESG call and IA= B and EISG look at it. Some =0A> change might happen.=0A> >> =0A> >> 4) The= IESG sends it out to the whole community for and IETF Last Call. =0A> Anyo= ne including folks on this list can send comment. LIkely some changes.=0A> = >> =0A> >> 5) It gets put back on an IESG call for formal approval as a WG= =0A> >> =0A> >> There's variants of how things can happen but the above is = roughly what I =0A> expect to happen for this charter.=0A> >> =0A> >> I've = attached the charter below. If you see something in it you really can't =0A= > live with, yell. If you see typos, things that need better wording, or so= on, =0A> send proposed text changes.=0A> >> =0A> >> One chug was we remove= d the word CoGII and instead just talked about =0A> translators. Another wo= rd we could that was suggested was "proxy" or just talk =0A> about things t= hat provide a "mapping function". I really don't much of an =0A> opinion ab= out which of these words, or others, would be best but if people have =0A> = thoughts, Speak up.=0A> >> =0A> >> Thanks, Cullen=0A> >> =0A> >> ----------= --------------------------------------------------=0A> >> =0A> >> =0A> >> C= oRE (Constrained RESTful Environments)=0A> >> =0A> >> CoRE is providing a f= ramework for resource-oriented applications=0A> >> intended to run on const= rained IP networks.=A0 A constrained IP network=0A> >> has limited packet s= izes, may exhibit a high degree of packet loss, and=0A> >> may have a subst= antial number of devices that may be powered off at any=0A> >> point in tim= e but periodically "wake up" for brief periods of time.=0A> > =0A> > JP>=0A= > > 1) I would suggest to first try to adopt a common "language" across Wor= king=0A> > Groups. In ROLL, we use the term LLN to refer to Low power and L= ossy Networks.=0A> > Using similar terminology could help.=0A> =0A> Agree w= ith common language in general but in some earlier but in earlier =0A> disc= ussion I understood from people and LLN was a description about the network= =0A> and not so much the constraints of the hosts that ran on it. (I may h= ave totally =0A> misunderstood what they were saying) It seemed like what p= eople were trying to =0A> say here was a related to but not the same as LLN= . Can you point at the best =0A> definition of LLN over in ROLL and perhaps= I can try and sort this out. =0A> =0A> > 2) I'd slightly reword to say tha= t LLN are characterized by constrained =0A> environments=0A> > in terms of = devices (CPU, Memory, power) interconnected by low speed lossy =0A> links.= =0A> =0A> > =0A> >> These networks and the nodes within them are characteri= zed by severe=0A> >> limits on throughput, available power, and particularl= y on the=0A> >> complexity that can be supported with limited code size and= limited RAM=0A> >> per node.=A0 More generally, we speak of constrained ne= tworks whenever at=0A> >> least some of the nodes and networks involved exh= ibit these=0A> >> characteristics.=A0 Low-Power Wireless Personal Area Netw= orks (LoWPANs)=0A> >> are an example of this type of network. LoWPANs are p= art of home and=0A> >> building automation, energy management, and the Inte= rnet of Things.=0A> > =0A> > JP> I would definitely suggest to remove that = last sentence ... We've been =0A> struggling=0A> > with the term 6lowpan, t= rying to explain that "The Internet Of Things" refers =0A> to the=0A> > use= of IPv6 in LLNs. 6LoWPAN is one instantiation for IPv6 in IEEE 802.15.4 = =0A> but=0A> > there are many other low power link layers, and this is one = of the beauty of =0A> IP to=0A> > be able to support those. The Internet of= things will (and is already) made of =0A> such=0A> > low power link layers= . That looks like a cosmetic terminology comment but it =0A> will=0A> > avo= id a ton of confusion.=0A> =0A> I think that was my mistake - Thanks for ca= tching. What I was trying to do is =0A> motivate they type of places that m= ight be able to use the output of the CoRE =0A> WG. What I was trying to sa= y is "Constrained networks can occur as part of home =0A> and building auto= mation, energy management, and the Internet of Things." =0A> =0A> > =0A> >>= =0A> >> The CoRE working group will define a framework for a limited class= of=0A> >> applications: those that deal with the manipulation of simple re= sources=0A> >> on constrained networks. This includes applications to monit= or simple=0A> >> sensors (e.g. temperature sensors, light switches, and pow= er meters), to=0A> >> control actuators (e.g. light switches, heating contr= ollers, and door=0A> >> locks), and to manage devices.=0A> >> =0A> >> The g= eneral architecture consists of nodes on the constrained network,=0A> >> ca= lled Devices, that are responsible for one or more Resources that may=0A> >= > represent sensors, actuators, combinations of values or other=0A> >> info= rmation.=A0 Devices send messages to change and query resources on=0A> >> o= ther Devices. Devices can send notifications about changed resource=0A> >> = values to Devices that have subscribed to receive notification about=0A> >>= changes. A Device can also publish or be queried about its=0A> >> descript= ion. Typically a single physical host on the network would have=0A> >> just= one Device but a host may represent multiple logical Devices. As=0A> >> pa= rt of the framework for building these applications, the WG will=0A> >> def= ine a Constrained Application Protocol (CoAP) for the manipulation of=0A> >= > Resources on a Device.=0A> >> =0A> >> CoAP will be designed for use betwe= en Devices on the same constrained=0A> >> network, between Devices and gene= ral nodes on the Internet, and between=0A> >> Devices on different constrai= ned networks both joined by an=0A> >> internet. CoAP targets the type of op= erating environments defined in the=0A> >> ROLL and 6LOWPAN working groups = which have additional constraints=0A> >> compared to normal IP networks, bu= t the CoAP protocol will also operate=0A> >> over traditional IP networks.= =0A> >> =0A> >> There also may be translators that interconnect between oth= er Internet=0A> >> protocols and the Devices using the CoAP protocol.=A0 Th= e WG will define a=0A> >> mapping from CoAP to an HTTP REST API; this mappi= ng will not depend on a=0A> >> specific application. It is worth noting tha= t translation does not have=0A> >> to occur at the boundary between the con= strained network and the more=0A> >> general network, but can be deployed a= t various locations in the=0A> >> unconstrained network.=0A> > =0A> > It mi= ght be worth clearly spelling out that such "Translators" are not =0A> prot= ocol=0A> > translation gateways but sensor, devices, ... are IPv6 enabled d= evices.=0A> =0A> I might not be understanding what point you are getting at= here. Uh, I think we =0A> have had pretty clear input the CoRE application= level could be running over v4 =0A> or v6. The charters tried to be pretty= explicit that it is not v6 specific. I'm =0A> trying to reflect the consen= sus here and the actually consensus call would be up =0A> to Lisa as the AD= but I did get a fair amount of input on topic and it all =0A> seemed to go= towards the direction of, yes this definitely has to work on v6, =0A> but = to make something that is above layer 3 be only for v6 would encourage laye= r =0A> violations of the worst kind and there was no need for that. I think= the general =0A> approach for IETF application layer protocols is to work = on both v4 and v6 =0A> unless there is some really good reason they can't. = =0A> =0A> > =0A> >> =0A> >> CoAP will support various forms of "caching".= =A0 For example, if a=0A> >> temperature sensor is normally asleep but wake= s up every five minutes=0A> >> and sends the current temperature to a trans= lator that has subscribed,=0A> >> when the translator receives a request ov= er HTTP for that temperature=0A> >> resource, it can respond with the last = seen value instead of trying to=0A> >> query the Device which is currently = asleep.=0A> > =0A> > Completely in line with that architecture. Just note t= hat nothing prevent an =0A> end=0A> > device with enough resource to native= ly support HTTP though.=0A> =0A> Yep - agree. But do we need to say anythin= g about that here? I'm just not sure =0A> what words to put in. Clearly we = can do HTTP/Rest API over IP today without any =0A> new standardization. No= thing here would be saying don't do that. =0A> =0A> =0A> > =0A> >> =0A> >> = The initial work item of the WG is to define a protocol specification=0A> >= > for CoAP that includes:=0A> >> =0A> >> 1) The ability to create, read, up= date and delete a Resource on a=0A> >>=A0 Device.=0A> >> =0A> >> 2) The abi= lity to allow a Device to publish a value or event to another=0A> >>=A0 Dev= ice that has subscribed to be notified of changes, as well as the=0A> >>=A0= way for a Device to subscribe to receive publishes from another=0A> >>=A0 = Device.=0A> >> =0A> >> 3) The ability to support a non-reliable multicast m= essage to be sent to=0A> >>=A0 a group of Devices to manipulate a resource = on all the Devices.=0A> >> =0A> >> 4) The core CoAP functionality MUST oper= ate well over UDP and UDP MUST=0A> >>=A0 be implemented on CoAP Devices.=A0= There may be OPTIONAL functions in=0A> >>=A0 CoAP (e.g. delivery of larger= chunks of data) which if implemented=0A> >>=A0 are implemented over TCP. A= pplications which require the optional TCP=0A> >>=A0 features will limit th= emselves to a narrower subset of deployment=0A> >>=A0 cases.=0A> > =0A> > I= would suggest to delete the last sentence though.=0A> =0A> There as a lot = of discussion leading to this sentence and I'm cautions to open =0A> the ca= n worms. The issues of taking it out is the following. Clearly some people = =0A> think that TCP won't meet all the needs or we would probably not bothe= r to do =0A> UDP at all. But given you are doing UDP, why would you bother = with TCP, and the =0A> answer is there are probably good reasons to use it = in some cases. Then the =0A> questions comes up, so OK what about when you = don't have it. We end of with this =0A> circular argument about the everyth= ing that works over UDP must work over TCP =0A> and visa versa so why have = both. This sentence in the charter tries to break =0A> that argument by poi= nting out the obvious which is some stuff is just not going =0A> to be work= as well, if at all, over UDP and also TCP is not going to be =0A> availabl= e 100% of the time. I realize this paragraph makes almost no sense but I = =0A> hope you can figure out what I am getting at if not, glad to give you = a call and =0A> get to the point where I can explain well enou=0A> gh to fi= x this email=0A> =0A> > =0A> >> =0A> >> 5) A definition of how to use CoAP = to advertise about or query for a=0A> >>=A0 Device's description. This desc= ription may include the device name=0A> >>=A0 and a list of its Resources, = each with a URL, an interface=0A> >>=A0 description URI (pointing e.g. to a= WADL document) and an optional=0A> >>=A0 name. The name taxonomy used for = this description will be consistent=0A> >>=A0 with other IETF work, e.g. dr= aft-cheshire-dnsext-dns-sd.=0A> > =0A> > Does that cover the discovery aspe= cts (of both the devices and the services)?=0A> > If so, great otherwise i = would suggest to clearly spell it out since this is =0A> in my=0A> > opinio= n a core components.=0A> =0A> It covers the naming aspects of device and se= rvices. (More or discover bellow)=0A> =0A> > =0A> >> =0A> >> 6) Specificati= on for the HTTP REST based API and translation to=0A> >>=A0 communicate wit= h Devices. Translation should make use of Device=0A> >>=A0 description info= rmation and should not need code updates to deal with=0A> >>=A0 new Devices= .=0A> >> =0A> >> 7) Consider operational and manageability aspects of the p= rotocol and at=0A> >>=A0 a minimum provide a way to tell if a Device is pow= ered on or not.=0A> > =0A> > That is a really a "minimum" ... do we need to= be so restrictive ?=0A> =0A> It's definitely a pretty minimal minimum. The= question is what do we add beyond =0A> that and do we need to do it in the= charter. Note this bullet does not stop the =0A> WG from doing more, just = sets a minimum bar. Honestly, this bar is so low but =0A> every time I trie= d to raise the bar, I failed. Ideas welcome. I pretty much =0A> expect that= folks would have a way of finding out things like firmware version =0A> an= d such but do to the privacy aspects of some of that, people have argued th= at =0A> would be one of the "Resources" defined which you can access via th= e CoRE =0A> protocol and not part of the CoRE protocol itself. I'm working = with Dan =0A> Romascanu (Ops AD) has been following this charter and I know= he is has sent me =0A> some emails that I have not got to yet so I expect = to be able to improve this =0A> point=A0 a bit but doubt we can figure out = any really significant changes that can =0A> get widespread agreement. =0A>= =0A> > =0A> >> =0A> >> The working group will not develop a reliable multi= cast solution, and=0A> >> will not develop a general service discovery solu= tion.=0A> > =0A> > That is the part I was a bit worried about ... without s= ervice discovery, =0A> deployments will=0A> > certainly be extremely diffic= ult. We should at least work on the selection of =0A> a discovery=0A> > pro= tocols, many candidates exist ... and potentially re-charter, should =0A> p= rotocol extension=0A> > will required.=0A> =0A> So I share your concern and= was very skeptical of how this could be useful =0A> without a Discovery pr= otocol. However, at the BOF, there was a surprisingly =0A> strong HUM at th= e end to throw Discovery under the bus. This sort of freaked me =0A> out at= first but as I came to talk to more people about it, I realized that =0A> = people had widely varying views of what Discovery meant. Here's my current = =0A> understanding of what sort of "Discover" in the scope of this charter = and what =0A> is out of scope. =0A> =0A> First, a discovery protocol can be= decoupled from a data transfer protocol. For =0A> example, a printer can b= e discovered with UPnP, Bonjour, SLP, etc even though =0A> one might use IP= P to print to it. What we are trying to do here is more the IPP =0A> like p= rotocol. Second, the charter has the word " A Device can also publish or = =0A> be queried about its description." I'll update this a bit but the inte= ntion was, =0A> if you know the IP address of a Device, you can ask it what= resources it =0A> supports - basically what's it profile. A device should = also decide to publish =0A> out to other devices what resources it supports= . It could publish them to a =0A> multicast group. A device could also sent= out to multicast group what resources =0A> do you support and get back ans= wers from many devices. Some people think this is =0A> discover and many do= not. They think it is just a device saying what =0A> characteristics it ha= s and consider Discover much more complicated.=A0 The other =0A> part in th= e proposed charter around discover is being c=0A> onsistent with existing n= aming constraints. The goal here is to make sure that =0A> whatever this WG= selects around name devices and services, it's got to make sure =0A> that = this is not impossible for an application to use in some multicast DNS =0A>= discover protocol. =0A> =0A> That my rough, and perhaps somewhat confused,= interpretation of the state of the =0A> current charter and given the stro= ng HUMs at the end of the BOF, I don't see how =0A> we have this WG take on= a full blown discovery effort without re-charting (or =0A> re-boffing) whi= ch is something I am perfectly happy to delay to do later.=0A> =0A> =0A> >>= description. =0A> > =0A> >> =0A> >> Security, particularly keying of new D= evices, is very challenging for=0A> >> these applications. The WG will work= to select approaches to security=0A> >> bootstrapping which are realistic = given the constraints and requirements=0A> >> of the network.=A0 To ensure = that any two nodes can join together, all=0A> >> nodes must implement at le= ast one universal bootstrapping method.=0A> >> =0A> >> Security can be achi= eved using either session security or object=0A> >> security.=A0 For both o= bject and session security, the WG will work with=0A> >> the security area = to select appropriate security framework and protocol=0A> >> as well as sel= ecting a minimal required to implement cipher suite. CoAP=0A> >> will initi= ally look at CMS (RFC 5652), TLS/DTLS, and EAP.=0A> >> =0A> >> The WG will = coordinate on requirements from many organizations including=0A> >> OpenSG/= NIST, ZigBee/HomePlug, IPSO Alliance, OASIS, SENSEI,=0A> >> ASHRAE/BACnet; = other SDOs and organizations. The WG will closely=0A> >> coordinate with ot= her IETF WGs including ROLL, 6LoWPAN, and appropriate=0A> >> groups in the = IETF OPS and Security areas.=0A> >> =0A> >> Milestones:=0A> >> =0A> >> Apr = 2010 - Select WG document for basis of the CoAP protocol=0A> >> =0A> >> Dec= 2010 - CoAP protocol specification with mapping to HTTP Rest API=0A> >>=A0= =A0 =A0 =A0 =A0 submitted to IESG as PS=0A> >> =0A> >> Dec 2010 - Constrai= ned security bootstrapping specification submitted to=0A> >>=A0 =A0 =A0 =A0= =A0 IESG as PS=0A> >> =0A> >> Jan 2011 - Recharter to add things reduced o= ut of initial scope=0A> >> =0A> >> =0A> >> ________________________________= _______________=0A> >> 6lowapp mailing list=0A> >> 6lowapp@ietf.org=0A> >> = https://www.ietf.org/mailman/listinfo/6lowapp=0A> > =0A> =0A> _____________= __________________________________=0A> 6lowapp mailing list=0A> 6lowapp@iet= f.org=0A> https://www.ietf.org/mailman/listinfo/6lowapp=0A=0A=0A=0A From cabo@tzi.org Tue Feb 2 22:58:01 2010 Return-Path: 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 3266F3A697D for <6lowapp@core3.amsl.com>; Tue, 2 Feb 2010 22:58:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] 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 FFEQ+wtW-cSM for <6lowapp@core3.amsl.com>; Tue, 2 Feb 2010 22:58:00 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 20F3E3A68AC for <6lowapp@ietf.org>; Tue, 2 Feb 2010 22:57:59 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o136wTJJ023402; Wed, 3 Feb 2010 07:58:29 +0100 (CET) Received: from [192.168.217.101] (p5489D8AE.dip.t-dialin.net [84.137.216.174]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 81651D452; Wed, 3 Feb 2010 07:58:27 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Wed, 3 Feb 2010 07:58:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <75CED471-D0E5-46B0-AC6B-D67349007E9B@tzi.org> References: <2A7B1CDC-5B99-47E8-9331-039D5997E1CC@cisco.com> To: 6lowapp@ietf.org X-Mailer: Apple Mail (2.1077) 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2010 06:58:01 -0000 > 1) I would suggest to first try to adopt a common "language" across = Working > Groups. In ROLL, we use the term LLN to refer to Low power and Lossy = Networks. > Using similar terminology could help. While LLN are one class of a constrained network, I believe the focus of = CoRE should be a bit wider and narrower at the same time. E.g., there = may be little reason not to run CoAP on simple nodes connected by = RS-485-style networks, even if we don't have a single standard way to = map IP onto them right now. On the other hand, some nodes on an LLN way = be able to run HTTP with good results. In other words: I'm all for harmonization of terms, except where that = muddies the waters. Let's keep the three terms 6LoWPAN (a specific LLN = where we do expect to have some highly constrained nodes), LLN, and = constrained nodes/networks separate for now. Yes, they all fit together = in the region where they overlap, but, no, they aren't the same. Gruesse, Carsten From jvasseur@cisco.com Tue Feb 2 23:41:06 2010 Return-Path: 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 EF28C3A6899 for <6lowapp@core3.amsl.com>; Tue, 2 Feb 2010 23:41:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.715 X-Spam-Level: X-Spam-Status: No, score=-4.715 tagged_above=-999 required=5 tests=[AWL=-4.271, BAYES_00=-2.599, FRT_BELOW2=2.154, HTML_MESSAGE=0.001] 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 jcdmPnbWgtZf for <6lowapp@core3.amsl.com>; Tue, 2 Feb 2010 23:41:03 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 99EA73A686E for <6lowapp@ietf.org>; Tue, 2 Feb 2010 23:41:01 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggBABm4aEuQ/uCWe2dsb2JhbACbQQEBFiQGpG+KEY4hgj2CCAQ X-IronPort-AV: E=Sophos;i="4.49,397,1262563200"; d="scan'208,217";a="3015791" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 03 Feb 2010 07:11:10 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o137ffal018690 for <6lowapp@ietf.org>; Wed, 3 Feb 2010 07:41:41 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Feb 2010 08:41:41 +0100 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Feb 2010 08:41:39 +0100 Message-Id: From: JP Vasseur To: Cullen Jennings In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-326--887109660 Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 3 Feb 2010 08:41:38 +0100 References: <2A7B1CDC-5B99-47E8-9331-039D5997E1CC@cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 03 Feb 2010 07:41:40.0043 (UTC) FILETIME=[5292E1B0:01CAA4A4] 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2010 07:41:07 -0000 --Apple-Mail-326--887109660 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Cullen, On Feb 2, 2010, at 10:50 PM, Cullen Jennings wrote: > > Hi JP, > > Thanks for comments. Some questions inline before I figure out how > to integrate these. If this email makes no sense, drop me a note > and I'll give you a phone call and figure out to sort it out. > > Cullen > > > On Feb 2, 2010, at 12:57 AM, JP Vasseur wrote: > >> Hi Cullen, >> >> First comment is that I fully support the charter, and look forward >> to seeing an active WG, lots of >> items that we need to work on :-) >> >> Comments below, >> >> On Jan 30, 2010, at 7:16 PM, Cullen Jennings wrote: >> >>> >>> Thanks to all the great comments form people and the work from >>> Zach, Carsten, and Lisa for this this version. This version >>> clarified a bunch of issues and also removed a bunch of text that >>> did really need to be in the charter. Documents tend to have words >>> added over time and every so often they need to go on a diet :-) >>> I'm really happy with this version and my view is that it is >>> probably close enough to send to the IESG. Just to let everyone on >>> the list know the process here, what happens next is: >>> >>> 1) See if there are any last minute screams on the email list >>> about this version of the charter >>> >>> 2) Send it to the AD (Lisa). She might have some changes before >>> she moves it forward to the IESG but Lisa's been very involved >>> along the way here so no expecting any huge surprises at that pint >>> >>> 3) Lisa puts in an schedule for IESG call and IAB and EISG look at >>> it. Some change might happen. >>> >>> 4) The IESG sends it out to the whole community for and IETF Last >>> Call. Anyone including folks on this list can send comment. LIkely >>> some changes. >>> >>> 5) It gets put back on an IESG call for formal approval as a WG >>> >>> There's variants of how things can happen but the above is roughly >>> what I expect to happen for this charter. >>> >>> I've attached the charter below. If you see something in it you >>> really can't live with, yell. If you see typos, things that need >>> better wording, or so on, send proposed text changes. >>> >>> One chug was we removed the word CoGII and instead just talked >>> about translators. Another word we could that was suggested was >>> "proxy" or just talk about things that provide a "mapping >>> function". I really don't much of an opinion about which of these >>> words, or others, would be best but if people have thoughts, Speak >>> up. >>> >>> Thanks, Cullen >>> >>> ------------------------------------------------------------ >>> >>> >>> CoRE (Constrained RESTful Environments) >>> >>> CoRE is providing a framework for resource-oriented applications >>> intended to run on constrained IP networks. A constrained IP >>> network >>> has limited packet sizes, may exhibit a high degree of packet >>> loss, and >>> may have a substantial number of devices that may be powered off >>> at any >>> point in time but periodically "wake up" for brief periods of time. >> >> JP> >> 1) I would suggest to first try to adopt a common "language" across >> Working >> Groups. In ROLL, we use the term LLN to refer to Low power and >> Lossy Networks. >> Using similar terminology could help. > > Agree with common language in general but in some earlier but in > earlier discussion I understood from people and LLN was a > description about the network and not so much the constraints of the > hosts that ran on it. It does apply to both (see below) > (I may have totally misunderstood what they were saying) It seemed > like what people were trying to say here was a related to but not > the same as LLN. Can you point at the best definition of LLN over in > ROLL and perhaps I can try and sort this out. Sure. We had that discussion when we formed ROLL, trying to find a generic term that would apply to these envrionments. In http://www.ietf.org/id/draft-ietf-roll-terminology-02.txt , we define LLNs as: LLN: Low power and Lossy networks (LLNs) are typically composed of many embedded devices with limited power, memory, and processing resources interconnected by a variety of links, such as IEEE 802.15.4 or Low Power WiFi. There is a wide scope of application areas for LLNs, including industrial monitoring, building automation (HVAC, lighting, access control, fire), connected home, healthcare, environmental monitoring, urban sensor networks, energy management, assets tracking and refrigeration.. As you can see this quite generic and *OF COURSE* we can change/adapt this terminology to make it use by all WG working on ... LLNs ... > >> 2) I'd slightly reword to say that LLN are characterized by >> constrained environments >> in terms of devices (CPU, Memory, power) interconnected by low >> speed lossy links. > >> >>> These networks and the nodes within them are characterized by severe >>> limits on throughput, available power, and particularly on the >>> complexity that can be supported with limited code size and >>> limited RAM >>> per node. More generally, we speak of constrained networks >>> whenever at >>> least some of the nodes and networks involved exhibit these >>> characteristics. Low-Power Wireless Personal Area Networks >>> (LoWPANs) >>> are an example of this type of network. LoWPANs are part of home and >>> building automation, energy management, and the Internet of Things. >> >> JP> I would definitely suggest to remove that last sentence ... >> We've been struggling >> with the term 6lowpan, trying to explain that "The Internet Of >> Things" refers to the >> use of IPv6 in LLNs. 6LoWPAN is one instantiation for IPv6 in IEEE >> 802.15.4 but >> there are many other low power link layers, and this is one of the >> beauty of IP to >> be able to support those. The Internet of things will (and is >> already) made of such >> low power link layers. That looks like a cosmetic terminology >> comment but it will >> avoid a ton of confusion. > > I think that was my mistake - Thanks for catching. What I was trying > to do is motivate they type of places that might be able to use the > output of the CoRE WG. What I was trying to say is "Constrained > networks can occur as part of home and building automation, energy > management, and the Internet of Things." OK great, thanks. > >> >>> >>> The CoRE working group will define a framework for a limited class >>> of >>> applications: those that deal with the manipulation of simple >>> resources >>> on constrained networks. This includes applications to monitor >>> simple >>> sensors (e.g. temperature sensors, light switches, and power >>> meters), to >>> control actuators (e.g. light switches, heating controllers, and >>> door >>> locks), and to manage devices. >>> >>> The general architecture consists of nodes on the constrained >>> network, >>> called Devices, that are responsible for one or more Resources >>> that may >>> represent sensors, actuators, combinations of values or other >>> information. Devices send messages to change and query resources on >>> other Devices. Devices can send notifications about changed resource >>> values to Devices that have subscribed to receive notification about >>> changes. A Device can also publish or be queried about its >>> description. Typically a single physical host on the network would >>> have >>> just one Device but a host may represent multiple logical Devices. >>> As >>> part of the framework for building these applications, the WG will >>> define a Constrained Application Protocol (CoAP) for the >>> manipulation of >>> Resources on a Device. >>> >>> CoAP will be designed for use between Devices on the same >>> constrained >>> network, between Devices and general nodes on the Internet, and >>> between >>> Devices on different constrained networks both joined by an >>> internet. CoAP targets the type of operating environments defined >>> in the >>> ROLL and 6LOWPAN working groups which have additional constraints >>> compared to normal IP networks, but the CoAP protocol will also >>> operate >>> over traditional IP networks. >>> >>> There also may be translators that interconnect between other >>> Internet >>> protocols and the Devices using the CoAP protocol. The WG will >>> define a >>> mapping from CoAP to an HTTP REST API; this mapping will not >>> depend on a >>> specific application. It is worth noting that translation does not >>> have >>> to occur at the boundary between the constrained network and the >>> more >>> general network, but can be deployed at various locations in the >>> unconstrained network. >> >> It might be worth clearly spelling out that such "Translators" are >> not protocol >> translation gateways but sensor, devices, ... are IPv6 enabled >> devices. > > I might not be understanding what point you are getting at here. Uh, > I think we have had pretty clear input the CoRE application level > could be running over v4 or v6. The charters tried to be pretty > explicit that it is not v6 specific. I'm trying to reflect the > consensus here and the actually consensus call would be up to Lisa > as the AD but I did get a fair amount of input on topic and it all > seemed to go towards the direction of, yes this definitely has to > work on v6, but to make something that is above layer 3 be only for > v6 would encourage layer violations of the worst kind and there was > no need for that. I think the general approach for IETF application > layer protocols is to work on both v4 and v6 unless there is some > really good reason they can't. Totally agree. I was in fact trying to say two things here: 1) You have a point. Anything above layer 3, could be for v4 or v6. But still ... and up to the IESG of course but we need to remember that we had a similar discussion with 6lowpan and ROLL: the idea was to pass a clear message toward the use of v6 for these kind of environments for the number of reasons that we all know. For example RPL is v6 only, which is a decision made on purpose. 2) The first point is I think pretty important. As you know, the technology approaches were to say the least extremely fragmented not so long ago. After tons of effort, we managed to get a momentum toward the use of IP, explaining that protocol translation gateways is not the best approach compared to a true IP end-to-end architecture (no need to enumerate the number of reason here) ... so I was just a bit cautious on introducing a term that would make people think that this is what we are proposing here ... "translator" may be a dangerous term to use. > >> >>> >>> CoAP will support various forms of "caching". For example, if a >>> temperature sensor is normally asleep but wakes up every five >>> minutes >>> and sends the current temperature to a translator that has >>> subscribed, >>> when the translator receives a request over HTTP for that >>> temperature >>> resource, it can respond with the last seen value instead of >>> trying to >>> query the Device which is currently asleep. >> >> Completely in line with that architecture. Just note that nothing >> prevent an end >> device with enough resource to natively support HTTP though. > > Yep - agree. But do we need to say anything about that here? I'm > just not sure what words to put in. Clearly we can do HTTP/Rest API > over IP today without any new standardization. Nothing here would be > saying don't do that. Just something like ... "For the constrained device not supporting HTTP natively, ...." > > >> >>> >>> The initial work item of the WG is to define a protocol >>> specification >>> for CoAP that includes: >>> >>> 1) The ability to create, read, update and delete a Resource on a >>> Device. >>> >>> 2) The ability to allow a Device to publish a value or event to >>> another >>> Device that has subscribed to be notified of changes, as well as the >>> way for a Device to subscribe to receive publishes from another >>> Device. >>> >>> 3) The ability to support a non-reliable multicast message to be >>> sent to >>> a group of Devices to manipulate a resource on all the Devices. >>> >>> 4) The core CoAP functionality MUST operate well over UDP and UDP >>> MUST >>> be implemented on CoAP Devices. There may be OPTIONAL functions in >>> CoAP (e.g. delivery of larger chunks of data) which if implemented >>> are implemented over TCP. Applications which require the optional >>> TCP >>> features will limit themselves to a narrower subset of deployment >>> cases. >> >> I would suggest to delete the last sentence though. > > There as a lot of discussion leading to this sentence and I'm > cautions to open the can worms. The issues of taking it out is the > following. Clearly some people think that TCP won't meet all the > needs or we would probably not bother to do UDP at all. But given > you are doing UDP, why would you bother with TCP, and the answer is > there are probably good reasons to use it in some cases. Then the > questions comes up, so OK what about when you don't have it. We end > of with this circular argument about the everything that works over > UDP must work over TCP and visa versa so why have both. This > sentence in the charter tries to break that argument by pointing out > the obvious which is some stuff is just not going to be work as > well, if at all, over UDP and also TCP is not going to be available > 100% of the time. I realize this paragraph makes almost no sense but > I hope you can figure out what I am getting at if not, glad to give > you a call and get to the point where I can explain well enough to > fix this email Clear explanation, thanks, I now see where it is coming from. The sentence does not hurt too much, I just found it weird and with little "sense". And we do not want to re-open the can worms indeed. The proposal to delete was just to not limit ourselves. But no big deal here. > >> >>> >>> 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) > >> >>> >>> 6) Specification for the HTTP REST based API and translation to >>> communicate with Devices. Translation should make use of Device >>> description information and should not need code updates to deal >>> with >>> new Devices. >>> >>> 7) Consider operational and manageability aspects of the protocol >>> and at >>> a minimum provide a way to tell if a Device is powered on or not. >> >> That is a really a "minimum" ... do we need to be so restrictive ? > > It's definitely a pretty minimal minimum. The question is what do we > add beyond that and do we need to do it in the charter. Note this > bullet does not stop the WG from doing more, just sets a minimum > bar. Honestly, this bar is so low but every time I tried to raise > the bar, I failed. Ideas welcome. I pretty much expect that folks > would have a way of finding out things like firmware version and > such but do to the privacy aspects of some of that, people have > argued that would be one of the "Resources" defined which you can > access via the CoRE protocol and not part of the CoRE protocol > itself. I'm working with Dan Romascanu (Ops AD) has been following > this charter and I know he is has sent me some emails that I have > not got to yet so I expect to be able to improve this point a bit > but doubt we can figure out any really significant changes that can > get widespread agreement. I guess that we could slightly reword: Delete "a minimum .... " since the bar is so low that it does make little sense. You would not do anything with that sole information anyway. There might be a way to make it a bit more generic: 7) Consider operational and manageability aspects of the protocol (e.g. tell if a Device is powered on or not, retrieve management information related to errors, traffic, ....). > >> >>> >>> 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. 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. Thanks! JP. > > >>> description. >> >>> >>> Security, particularly keying of new Devices, is very challenging >>> for >>> these applications. The WG will work to select approaches to >>> security >>> bootstrapping which are realistic given the constraints and >>> requirements >>> of the network. To ensure that any two nodes can join together, all >>> nodes must implement at least one universal bootstrapping method. >>> >>> Security can be achieved using either session security or object >>> security. For both object and session security, the WG will work >>> with >>> the security area to select appropriate security framework and >>> protocol >>> as well as selecting a minimal required to implement cipher suite. >>> CoAP >>> will initially look at CMS (RFC 5652), TLS/DTLS, and EAP. >>> >>> The WG will coordinate on requirements from many organizations >>> including >>> OpenSG/NIST, ZigBee/HomePlug, IPSO Alliance, OASIS, SENSEI, >>> ASHRAE/BACnet; other SDOs and organizations. The WG will closely >>> coordinate with other IETF WGs including ROLL, 6LoWPAN, and >>> appropriate >>> groups in the IETF OPS and Security areas. >>> >>> Milestones: >>> >>> Apr 2010 - Select WG document for basis of the CoAP protocol >>> >>> Dec 2010 - CoAP protocol specification with mapping to HTTP Rest API >>> submitted to IESG as PS >>> >>> Dec 2010 - Constrained security bootstrapping specification >>> submitted to >>> IESG as PS >>> >>> Jan 2011 - Recharter to add things reduced out of initial scope >>> >>> >>> _______________________________________________ >>> 6lowapp mailing list >>> 6lowapp@ietf.org >>> https://www.ietf.org/mailman/listinfo/6lowapp >> > --Apple-Mail-326--887109660 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Cullen,

On = Feb 2, 2010, at 10:50 PM, Cullen Jennings wrote:


Hi = JP,

Thanks for comments. Some questions inline before I figure = out how to integrate these.  If this email makes no sense, drop me = a note and I'll give you a phone call and figure out to sort it out. =

Cullen


On Feb 2, 2010, at 12:57 AM, JP Vasseur = wrote:

Hi = Cullen,

First comment = is that I fully support the charter, and look forward to seeing an = active WG, lots of
items that = we need to work on :-)

Comments = below,

On Jan 30, = 2010, at 7:16 PM, Cullen Jennings wrote:


Thanks to all the great comments = form people and the work from Zach, Carsten, and Lisa for this this = version. This version clarified a bunch of issues and also removed a = bunch of text that did really need to be in the charter. Documents tend = to have words added over time and every so often they need to go on a = diet :-) I'm really happy with this version and my view is that it is = probably close enough to send to the IESG. Just to let everyone on the = list know the process here, what happens next = is:

1) See if there are any last = minute screams on the email list about this version of the = charter

2) Send it to the AD (Lisa). She = might have some changes before she moves it forward to the IESG but = Lisa's been very involved along the way here so no expecting any huge = surprises at that pint

3) Lisa puts in an schedule for = IESG call and IAB and EISG look at it. Some change might = happen.

4) The IESG sends it out to the = whole community for and IETF Last Call. Anyone including folks on this = list can send comment. LIkely some = changes.

5) It gets put back on an IESG = call for formal approval as a = WG

There's variants of how things = can happen but the above is roughly what I expect to happen for this = charter.

I've attached the charter below. = If you see something in it you really can't live with, yell. If you see = typos, things that need better wording, or so on, send proposed text = changes.

One chug was we removed the word = CoGII and instead just talked about translators. Another word we could = that was suggested was "proxy" or just talk about things that provide a = "mapping function". I really don't much of an opinion about which of = these words, or others, would be best but if people have thoughts, Speak = up.

Thanks, = Cullen

------------------------------------------------------------=


CoRE (Constrained RESTful = Environments)

CoRE is providing a framework = for resource-oriented = applications
intended to run on constrained = IP networks.  A constrained IP = network
has limited packet sizes, may exhibit a high degree of = packet loss, and
may have a substantial number of = devices that may be powered off at = any
point in time but periodically "wake up" for brief periods = of time.

JP>
1) I = would suggest to first try to adopt a common "language" across = Working
Groups. In ROLL, we = use the term LLN to refer to Low power and Lossy = Networks.
Using similar = terminology could help.

Agree with common language = in general but in some earlier but in earlier discussion I understood = from people and LLN was a description about the network and not so much = the constraints of the hosts that ran on it. =

It does apply to both (see = below)

(I may have totally = misunderstood what they were saying) It seemed like what people were = trying to say here was a related to but not the same as LLN. Can you = point at the best definition of LLN over in ROLL and perhaps I can try = and sort this out.

Sure. We = had that discussion when we formed ROLL, trying to find a generic term = that would apply to these envrionments. In http://= www.ietf.org/id/draft-ietf-roll-terminology-02.txt, we define LLNs = as:

2) I'd slightly reword to say that LLN are characterized =
by constrained environments
in =
terms of devices (CPU, Memory, power) interconnected by low speed lossy =
links.


These networks and the nodes within them are characterized =
by severe
limits on throughput, available =
power, and particularly on the
complexity that can be supported =
with limited code size and limited =
RAM
per node.  More generally, we speak of constrained =
networks whenever at
least some of the nodes and =
networks involved exhibit these
characteristics.  Low-Power =
Wireless Personal Area Networks =
(LoWPANs)
are an example of this type of =
network. LoWPANs are part of home =
and
building automation, energy management, and the Internet =
of Things.

JP> I would =
definitely suggest to remove that last sentence ... We've been =
struggling
with the term =
6lowpan, trying to explain that "The Internet Of Things" refers to =
the
use of IPv6 in LLNs. =
6LoWPAN is one instantiation for IPv6 in IEEE 802.15.4 =
but
there are many other low =
power link layers, and this is one of the beauty of IP =
to
be able to support those. =
The Internet of things will (and is already) made of =
such
low power link layers. =
That looks like a cosmetic terminology comment but it =
will
avoid a ton of =
confusion.

I think that was my mistake - Thanks for =
catching. What I was trying to do is motivate they type of places that =
might be able to use the output of the CoRE WG. What I was trying to say =
is "Constrained networks can occur as part of home and building =
automation, energy management, and the Internet of Things." =


OK great, =
thanks.




The CoRE working group will =
define a framework for a limited class =
of
applications: those that deal with the manipulation of =
simple resources
on constrained networks. This =
includes applications to monitor =
simple
sensors (e.g. temperature sensors, light switches, and =
power meters), to
control actuators (e.g. light =
switches, heating controllers, and =
door
locks), and to manage =
devices.

The general architecture =
consists of nodes on the constrained =
network,
called Devices, that are =
responsible for one or more Resources that =
may
represent sensors, actuators, combinations of values or =
other
information.  Devices send messages to change and =
query resources on
other Devices. Devices can send =
notifications about changed =
resource
values to Devices that have =
subscribed to receive notification =
about
changes. A Device can also publish or be queried about =
its
description. Typically a single physical host on the =
network would have
just one Device but a host may =
represent multiple logical Devices. =
As
part of the framework for building these applications, the =
WG will
define a Constrained Application Protocol (CoAP) for the =
manipulation of
Resources on a =
Device.

CoAP will be designed for use =
between Devices on the same =
constrained
network, between Devices and =
general nodes on the Internet, and =
between
Devices on different constrained networks both joined by =
an
internet. CoAP targets the type of operating environments =
defined in the
ROLL and 6LOWPAN working groups =
which have additional =
constraints
compared to normal IP networks, =
but the CoAP protocol will also =
operate
over traditional IP =
networks.

There also may be translators =
that interconnect between other =
Internet
protocols and the Devices using =
the CoAP protocol.  The WG will define =
a
mapping from CoAP to an HTTP REST API; this mapping will =
not depend on a
specific application. It is =
worth noting that translation does not =
have
to occur at the boundary between the constrained network =
and the more
general network, but can be =
deployed at various locations in =
the
unconstrained =
network.

It might be =
worth clearly spelling out that such "Translators" are not =
protocol
translation gateways =
but sensor, devices, ... are IPv6 enabled devices.

I =
might not be understanding what point you are getting at here. Uh, I =
think we have had pretty clear input the CoRE application level could be =
running over v4 or v6. The charters tried to be pretty explicit that it =
is not v6 specific. I'm trying to reflect the consensus here and the =
actually consensus call would be up to Lisa as the AD but I did get a =
fair amount of input on topic and it all seemed to go towards the =
direction of, yes this definitely has to work on v6, but to make =
something that is above layer 3 be only for v6 would encourage layer =
violations of the worst kind and there was no need for that. I think the =
general approach for IETF application layer protocols is to work on both =
v4 and v6 unless there is some really good reason they can't. =

Totally agree. I was in fact = trying to say two things here:
1) You have a point. Anything = above layer 3, could be for v4 or v6. But still ... and up to the IESG = of course but we need to remember that we had a similar discussion with = 6lowpan and ROLL: the idea was to pass a clear message toward the use of = v6 for these kind of environments for the number of reasons that we all = know. For example RPL is v6 only, which is a decision made on = purpose.
2) The first point is I think pretty important. As you = know, the technology approaches were to say the least extremely = fragmented not so long ago. After tons of effort, we managed to get a = momentum toward the use of IP, explaining that protocol translation = gateways is not the best approach compared to a true IP end-to-end = architecture (no need to enumerate the number of reason here) ... so I = was just a bit cautious on introducing a term that would make people = think that this is what we are proposing here ... "translator" may be a = dangerous term to use.




CoAP will support various forms = of "caching".  For example, if = a
temperature sensor is normally asleep but wakes up every = five minutes
and sends the current = temperature to a translator that has = subscribed,
when the translator receives a = request over HTTP for that = temperature
resource, it can respond with = the last seen value instead of trying = to
query the Device which is currently = asleep.

Completely in = line with that architecture. Just note that nothing prevent an = end
device with enough = resource to natively support HTTP though.

Yep - = agree. But do we need to say anything about that here? I'm just not sure = what words to put in. Clearly we can do HTTP/Rest API over IP today = without any new standardization. Nothing here would be saying don't do = that.

Just something like ... = "For the constrained device not supporting HTTP natively, = ...."





The initial work item of the WG = is to define a protocol = specification
for CoAP that = includes:

1) The ability to create, read, = update and delete a Resource on = a
Device.

2) The ability to allow a Device = to publish a value or event to = another
Device that has subscribed to be notified of changes, as = well as the
way for a Device to subscribe = to receive publishes from = another
Device.

3) The ability to support a = non-reliable multicast message to be sent = to
a group of Devices to manipulate a resource on all the = Devices.

4) The core CoAP functionality = MUST operate well over UDP and UDP = MUST
be implemented on CoAP Devices.  There may be = OPTIONAL functions in
CoAP (e.g. delivery of larger = chunks of data) which if = implemented
are implemented over TCP. = Applications which require the optional = TCP
features will limit themselves to a narrower subset of = deployment
= cases.

I would suggest = to delete the last sentence though.

There as a lot = of discussion leading to this sentence and I'm cautions to open the can = worms. The issues of taking it out is the following. Clearly some people = think that TCP won't meet all the needs or we would probably not bother = to do UDP at all. But given you are doing UDP, why would you bother with = TCP, and the answer is there are probably good reasons to use it in some = cases. Then the questions comes up, so OK what about when you don't have = it. We end of with this circular argument about the everything that = works over UDP must work over TCP and visa versa so why have both. This = sentence in the charter tries to break that argument by pointing out the = obvious which is some stuff is just not going to be work as well, if at = all, over UDP and also TCP is not going to be available 100% of the = time. I realize this paragraph makes almost no sense but I hope you can = figure out what I am getting at if not, glad to give you a call and get = to the point where I can explain well enough to fix this = email

Clear explanation, = thanks, I now see where it is coming from. The sentence does not hurt = too much, I just found it weird and with little "sense". And we do not = want to re-open the can worms indeed. The proposal to delete was just to = not limit ourselves. But no big deal here.




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)



6) Specification for the HTTP = REST based API and translation = to
communicate with Devices. Translation should make use of = Device
description information and should not need code updates = to deal with
new = Devices.

7) Consider operational and = manageability aspects of the protocol and = at
a minimum provide a way to tell if a Device is powered on = or not.

That is a = really a "minimum" ... do we need to be so restrictive = ?

It's definitely a pretty minimal minimum. The = question is what do we add beyond that and do we need to do it in the = charter. Note this bullet does not stop the WG from doing more, just = sets a minimum bar. Honestly, this bar is so low but every time I tried = to raise the bar, I failed. Ideas welcome. I pretty much expect that = folks would have a way of finding out things like firmware version and = such but do to the privacy aspects of some of that, people have argued = that would be one of the "Resources" defined which you can access via = the CoRE protocol and not part of the CoRE protocol itself. I'm working = with Dan Romascanu (Ops AD) has been following this charter and I know = he is has sent me some emails that I have not got to yet so I expect to = be able to improve this point  a bit but doubt we can figure out = any really significant changes that can get widespread agreement. =

I guess that we could = slightly reword:

Delete "a minimum .... " since = the bar is so low that it does make little sense. You would not do = anything with that sole information anyway. There might be a way to make = it a bit more generic:

7) Consider operational = and manageability aspects of the protocol (e.g. tell if a Device is = powered on or not, retrieve management information related to errors, = traffic, ....).




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.

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.

Thanks!

JP.


description. =


Security, particularly keying of = new Devices, is very challenging = for
these applications. The WG will work to select approaches = to security
bootstrapping which are = realistic given the constraints and = requirements
of the network.  To ensure = that any two nodes can join together, = all
nodes must implement at least one universal bootstrapping = method.

Security can be achieved using = either session security or = object
security.  For both object and session security, the = WG will work with
the security area to select = appropriate security framework and = protocol
as well as selecting a minimal = required to implement cipher suite. = CoAP
will initially look at CMS (RFC 5652), TLS/DTLS, and = EAP.

The WG will coordinate on = requirements from many organizations = including
OpenSG/NIST, ZigBee/HomePlug, = IPSO Alliance, OASIS, SENSEI,
ASHRAE/BACnet; other SDOs and = organizations. The WG will = closely
coordinate with other IETF WGs including ROLL, 6LoWPAN, = and appropriate
groups in the IETF OPS and = Security areas.

Milestones:

Apr 2010 - Select WG document = for basis of the CoAP protocol

Dec 2010 - CoAP protocol = specification with mapping to HTTP Rest = API
        submitted = to IESG as PS

Dec 2010 - Constrained security = bootstrapping specification submitted = to
        IESG as = PS

Jan 2011 - Recharter to add = things reduced out of initial = scope


_______________________________________________
6lowapp mailing = list
6lowapp@ietf.org
https://www.ietf.or= g/mailman/listinfo/6lowapp



= --Apple-Mail-326--887109660-- From jvasseur@cisco.com Tue Feb 2 23:41:20 2010 Return-Path: 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 93F563A686E for <6lowapp@core3.amsl.com>; Tue, 2 Feb 2010 23:41:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.541 X-Spam-Level: X-Spam-Status: No, score=-9.541 tagged_above=-999 required=5 tests=[AWL=1.058, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 ZFq1OpjHkZo3 for <6lowapp@core3.amsl.com>; Tue, 2 Feb 2010 23:41:19 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 674FB3A68B5 for <6lowapp@ietf.org>; Tue, 2 Feb 2010 23:41:19 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAGa3aEtAZnwN/2dsb2JhbADAbZgyhEUE X-IronPort-AV: E=Sophos;i="4.49,397,1262563200"; d="scan'208";a="83690560" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 03 Feb 2010 07:42:00 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o137fx3G009194; Wed, 3 Feb 2010 07:41:59 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Feb 2010 08:41:58 +0100 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Feb 2010 08:41:58 +0100 Message-Id: <42445BF6-C0A7-489D-AFD0-26B5685850DA@cisco.com> From: JP Vasseur To: Carsten Bormann In-Reply-To: <75CED471-D0E5-46B0-AC6B-D67349007E9B@tzi.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 3 Feb 2010 08:41:58 +0100 References: <2A7B1CDC-5B99-47E8-9331-039D5997E1CC@cisco.com> <75CED471-D0E5-46B0-AC6B-D67349007E9B@tzi.org> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 03 Feb 2010 07:41:58.0997 (UTC) FILETIME=[5DDF0850:01CAA4A4] 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2010 07:41:20 -0000 Hi Carsten, On Feb 3, 2010, at 7:58 AM, Carsten Bormann wrote: >> 1) I would suggest to first try to adopt a common "language" across >> Working >> Groups. In ROLL, we use the term LLN to refer to Low power and >> Lossy Networks. >> Using similar terminology could help. > > While LLN are one class of a constrained network, I believe the > focus of CoRE should be a bit wider and narrower at the same time. > E.g., there may be little reason not to run CoAP on simple nodes > connected by RS-485-style networks, even if we don't have a single > standard way to map IP onto them right now. On the other hand, some > nodes on an LLN way be able to run HTTP with good results. > > In other words: I'm all for harmonization of terms, except where > that muddies the waters. Let's keep the three terms 6LoWPAN (a > specific LLN where we do expect to have some highly constrained > nodes), LLN, and constrained nodes/networks separate for now. Yes, > they all fit together in the region where they overlap, but, no, > they aren't the same. > We know that terminology can be discussed for years ;-) I am not particularly pushy for the use of one term or another but what I definitely noticed is that people and the industry can rightly be confused by all these terms. I cannot count the number of times I had this question ... what is the difference between 6lowpan, WSN, IP sensor networks, .... etc. I would personally prefer a slightly more generic term that cover them all and harmonized the terminology across all WGs. Just replied to Cullen about LLN. Does that make sense ? > Gruesse, Carsten > From robert.cragie@gridmerge.com Wed Feb 3 04:31:28 2010 Return-Path: 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 84FA43A6904 for <6lowapp@core3.amsl.com>; Wed, 3 Feb 2010 04:31:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 1R2kyCGz-uzb for <6lowapp@core3.amsl.com>; Wed, 3 Feb 2010 04:31:27 -0800 (PST) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id B00073A691E for <6lowapp@ietf.org>; Wed, 3 Feb 2010 04:31:26 -0800 (PST) Received: from client-86-29-35-162.glfd.adsl.virginmedia.com ([86.29.35.162] helo=[192.168.1.68]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.70) id 1NceOp-0005w4-Ka; Wed, 03 Feb 2010 12:32:06 +0000 Message-ID: <4B696CC3.2080609@gridmerge.com> Date: Wed, 03 Feb 2010 12:32:03 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Carsten Bormann References: <2A7B1CDC-5B99-47E8-9331-039D5997E1CC@cisco.com> <75CED471-D0E5-46B0-AC6B-D67349007E9B@tzi.org> In-Reply-To: <75CED471-D0E5-46B0-AC6B-D67349007E9B@tzi.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000609050605090204080804" 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 Reply-To: robert.cragie@gridmerge.com List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2010 12:31:28 -0000 This is a cryptographically signed message in MIME format. --------------ms000609050605090204080804 Content-Type: multipart/alternative; boundary="------------000901020807040208010009" This is a multi-part message in MIME format. --------------000901020807040208010009 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit +1. The taxonomy of terms is not entirely clear nor defined so trying to classify at this stage is difficult. If you are going to pick a general term, I think constrained nodes/network works well, as I see LLN as a specialisation of a constrained nodes/network. Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 (0) 1924 910888 http://www.gridmerge.com Carsten Bormann wrote: >> 1) I would suggest to first try to adopt a common "language" across Working >> Groups. In ROLL, we use the term LLN to refer to Low power and Lossy Networks. >> Using similar terminology could help. >> > > While LLN are one class of a constrained network, I believe the focus of CoRE should be a bit wider and narrower at the same time. E.g., there may be little reason not to run CoAP on simple nodes connected by RS-485-style networks, even if we don't have a single standard way to map IP onto them right now. On the other hand, some nodes on an LLN way be able to run HTTP with good results. > > In other words: I'm all for harmonization of terms, except where that muddies the waters. Let's keep the three terms 6LoWPAN (a specific LLN where we do expect to have some highly constrained nodes), LLN, and constrained nodes/networks separate for now. Yes, they all fit together in the region where they overlap, but, no, they aren't the same. > > Gruesse, Carsten > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp > > --------------000901020807040208010009 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit +1. The taxonomy of terms is not entirely clear nor defined so trying to classify at this stage is difficult. If you are going to pick a general term, I think constrained nodes/network works well, as I see LLN as a specialisation of a constrained nodes/network.

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com



Carsten Bormann wrote: 
1) I would suggest to first try to adopt a common "language" across Working
Groups. In ROLL, we use the term LLN to refer to Low power and Lossy Networks.
Using similar terminology could help.
    

While LLN are one class of a constrained network, I believe the focus of CoRE should be a bit wider and narrower at the same time.  E.g., there may be little reason not to run CoAP on simple nodes connected by RS-485-style networks, even if we don't have a single standard way to map IP onto them right now.  On the other hand, some nodes on an LLN way be able to run HTTP with good results.

In other words:  I'm all for harmonization of terms, except where that muddies the waters.  Let's keep the three terms 6LoWPAN (a specific LLN where we do expect to have some highly constrained nodes), LLN, and constrained nodes/networks separate for now.  Yes, they all fit together in the region where they overlap, but, no, they aren't the same.

Gruesse, Carsten

_______________________________________________
6lowapp mailing list
6lowapp@ietf.org
https://www.ietf.org/mailman/listinfo/6lowapp
--------------000901020807040208010009-- --------------ms000609050605090204080804 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJKzCC AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5 CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35 90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5 CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35 90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQdBWGHEaYIBO/4g+d746QHzAJBgUrDgMC GgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDAy MDMxMjMyMDNaMCMGCSqGSIb3DQEJBDEWBBSECab0PrEASO2oMdEf2EPARdyeGDBfBgkqhkiG 9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpgg E7/iD53vjpAfMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpggE7/iD53vjpAfMA0GCSqGSIb3DQEBAQUA BIIBAE4JFRGMCptN38YDULLlJJYC3loIEA4XhdZ4PIKURh5QQr1VJdP1dI5LHhGq0Zo7E829 uCwW7jGcrhn/OrYI2y65i8AnKPNJ16kq756J1DnEA5gPBW4yvQ9rUPq/F0V6z0k6Wnc9Soyw hm1NBjlrrS1qp+A2gqv2/9cbJzWmo6XVbwgmu1KhWYXb+DTQFU7Vr13Y94cykpS9X0mO0ajV K7koOASwV7NzLD7Ugt/+7GCRJHozpKpS2T9ASa2CglDLa/iIdKBGlemj8QDP6NVUHjMJJVWd CyPOG15AffKlsdknMc/nNQt7jmKcl+u4cl9J2OUfL9Or9HLcEWHBs86vFVQAAAAAAAA= --------------ms000609050605090204080804-- From robert.cragie@gridmerge.com Wed Feb 3 04:45:36 2010 Return-Path: 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 0B3B33A691E for <6lowapp@core3.amsl.com>; Wed, 3 Feb 2010 04:45:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 HMElB0ibKlZc for <6lowapp@core3.amsl.com>; Wed, 3 Feb 2010 04:45:33 -0800 (PST) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id 3FBF23A68FF for <6lowapp@ietf.org>; Wed, 3 Feb 2010 04:45:33 -0800 (PST) Received: from client-86-29-35-162.glfd.adsl.virginmedia.com ([86.29.35.162] helo=[192.168.1.68]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.70) id 1NcecU-0001Xt-HO; Wed, 03 Feb 2010 12:46:14 +0000 Message-ID: <4B697011.3090403@gridmerge.com> Date: Wed, 03 Feb 2010 12:46:09 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Cullen Jennings References: <2A7B1CDC-5B99-47E8-9331-039D5997E1CC@cisco.com> In-Reply-To: <2A7B1CDC-5B99-47E8-9331-039D5997E1CC@cisco.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040102040700040300010901" 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 Reply-To: robert.cragie@gridmerge.com List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2010 12:45:36 -0000 This is a cryptographically signed message in MIME format. --------------ms040102040700040300010901 Content-Type: multipart/alternative; boundary="------------010509050001050506040808" This is a multi-part message in MIME format. --------------010509050001050506040808 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Just a couple of minor comments inline. Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 (0) 1924 910888 http://www.gridmerge.com Cullen Jennings wrote: > Thanks to all the great comments form people and the work from Zach, Carsten, and Lisa for this this version. This version clarified a bunch of issues and also removed a bunch of text that did really need to be in the charter. Documents tend to have words added over time and every so often they need to go on a diet :-) I'm really happy with this version and my view is that it is probably close enough to send to the IESG. Just to let everyone on the list know the process here, what happens next is: > > 1) See if there are any last minute screams on the email list about this version of the charter > > 2) Send it to the AD (Lisa). She might have some changes before she moves it forward to the IESG but Lisa's been very involved along the way here so no expecting any huge surprises at that pint > > 3) Lisa puts in an schedule for IESG call and IAB and EISG look at it. Some change might happen. > > 4) The IESG sends it out to the whole community for and IETF Last Call. Anyone including folks on this list can send comment. LIkely some changes. > > 5) It gets put back on an IESG call for formal approval as a WG > > There's variants of how things can happen but the above is roughly what I expect to happen for this charter. > > I've attached the charter below. If you see something in it you really can't live with, yell. If you see typos, things that need better wording, or so on, send proposed text changes. > > One chug was we removed the word CoGII and instead just talked about translators. Another word we could that was suggested was "proxy" or just talk about things that provide a "mapping function". I really don't much of an opinion about which of these words, or others, would be best but if people have thoughts, Speak up. > > Thanks, Cullen > > ------------------------------------------------------------ > > > CoRE (Constrained RESTful Environments) > > CoRE is providing a framework for resource-oriented applications > intended to run on constrained IP networks. A constrained IP network > has limited packet sizes, may exhibit a high degree of packet loss, and > may have a substantial number of devices that may be powered off at any > point in time but periodically "wake up" for brief periods of time. > These networks and the nodes within them are characterized by severe > limits on throughput, available power, and particularly on the > complexity that can be supported with limited code size and limited RAM > per node. More generally, we speak of constrained networks whenever at > least some of the nodes and networks involved exhibit these > characteristics. Low-Power Wireless Personal Area Networks (LoWPANs) > are an example of this type of network. LoWPANs are part of home and > building automation, energy management, and the Internet of Things. > > The CoRE working group will define a framework for a limited class of > applications: those that deal with the manipulation of simple resources > on constrained networks. This includes applications to monitor simple > sensors (e.g. temperature sensors, light switches, and power meters), to > control actuators (e.g. light switches, heating controllers, and door > locks), and to manage devices. > > The general architecture consists of nodes on the constrained network, > called Devices, that are responsible for one or more Resources that may > represent sensors, actuators, combinations of values or other > information. Devices send messages to change and query resources on > other Devices. Devices can send notifications about changed resource > values to Devices that have subscribed to receive notification about > changes. A Device can also publish or be queried about its > description. Typically a single physical host on the network would have > just one Device but a host may represent multiple logical Devices. As > part of the framework for building these applications, the WG will > define a Constrained Application Protocol (CoAP) for the manipulation of > Resources on a Device. > > CoAP will be designed for use between Devices on the same constrained > network, between Devices and general nodes on the Internet, and between > Devices on different constrained networks both joined by an > internet. CoAP targets the type of operating environments defined in the > ROLL and 6LOWPAN working groups which have additional constraints > compared to normal IP networks, but the CoAP protocol will also operate > over traditional IP networks. > > There also may be translators that interconnect between other Internet > protocols and the Devices using the CoAP protocol. The WG will define a > mapping from CoAP to an HTTP REST API; this mapping will not depend on a > specific application. It is worth noting that translation does not have > to occur at the boundary between the constrained network and the more > general network, but can be deployed at various locations in the > unconstrained network. > > CoAP will support various forms of "caching". For example, if a > temperature sensor is normally asleep but wakes up every five minutes > and sends the current temperature to a translator that has subscribed, > when the translator receives a request over HTTP for that temperature > resource, it can respond with the last seen value instead of trying to > query the Device which is currently asleep. > This seems to imply that only a 'translator' can be a cache? This does have implications for the way the protocol is designed, i.e. it could be simpler if this is the case. On the other hand, it would be more flexible to allow caching in intermediate nodes which are not necessarily 'translators'. What is the intention here? > The initial work item of the WG is to define a protocol specification > for CoAP that includes: > > 1) The ability to create, read, update and delete a Resource on a > Device. > > 2) The ability to allow a Device to publish a value or event to another > Device that has subscribed to be notified of changes, as well as the > way for a Device to subscribe to receive publishes from another > Device. > > 3) The ability to support a non-reliable multicast message to be sent to > a group of Devices to manipulate a resource on all the Devices. > > 4) The core CoAP functionality MUST operate well over UDP and UDP MUST > be implemented on CoAP Devices. There may be OPTIONAL functions in > CoAP (e.g. delivery of larger chunks of data) which if implemented > are implemented over TCP. Applications which require the optional TCP > features will limit themselves to a narrower subset of deployment > cases. > Still not entirely happy with this language but can live with it - see earlier comments posted on January 26th. > 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. > > 6) Specification for the HTTP REST based API and translation to > communicate with Devices. Translation should make use of Device > description information and should not need code updates to deal with > new Devices. > > 7) Consider operational and manageability aspects of the protocol and at > a minimum provide a way to tell if a Device is powered on or not. > > The working group will not develop a reliable multicast solution, and > will not develop a general service discovery solution. > > Security, particularly keying of new Devices, is very challenging for > these applications. The WG will work to select approaches to security > bootstrapping which are realistic given the constraints and requirements > of the network. To ensure that any two nodes can join together, all > nodes must implement at least one universal bootstrapping method. > > Security can be achieved using either session security or object > security. For both object and session security, the WG will work with > the security area to select appropriate security framework and protocol > as well as selecting a minimal required to implement cipher suite. CoAP > will initially look at CMS (RFC 5652), TLS/DTLS, and EAP. > > The WG will coordinate on requirements from many organizations including > OpenSG/NIST, ZigBee/HomePlug, IPSO Alliance, OASIS, SENSEI, > ASHRAE/BACnet; other SDOs and organizations. The WG will closely > coordinate with other IETF WGs including ROLL, 6LoWPAN, and appropriate > groups in the IETF OPS and Security areas. > > Milestones: > > Apr 2010 - Select WG document for basis of the CoAP protocol > > Dec 2010 - CoAP protocol specification with mapping to HTTP Rest API > submitted to IESG as PS > > Dec 2010 - Constrained security bootstrapping specification submitted to > IESG as PS > > Jan 2011 - Recharter to add things reduced out of initial scope > > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp > > --------------010509050001050506040808 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Just a couple of minor comments inline.

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com



Cullen Jennings wrote: 
Thanks to all the great comments form people and the work from Zach, Carsten, and Lisa for this this version. This version clarified a bunch of issues and also removed a bunch of text that did really need to be in the charter. Documents tend to have words added over time and every so often they need to go on a diet :-) I'm really happy with this version and my view is that it is probably close enough to send to the IESG. Just to let everyone on the list know the process here, what happens next is:

1) See if there are any last minute screams on the email list about this version of the charter

2) Send it to the AD (Lisa). She might have some changes before she moves it forward to the IESG but Lisa's been very involved along the way here so no expecting any huge surprises at that pint

3) Lisa puts in an schedule for IESG call and IAB and EISG look at it. Some change might happen. 

4) The IESG sends it out to the whole community for and IETF Last Call. Anyone including folks on this list can send comment. LIkely some changes. 

5) It gets put back on an IESG call for formal approval as a WG 

There's variants of how things can happen but the above is roughly what I expect to happen for this charter.

I've attached the charter below. If you see something in it you really can't live with, yell. If you see typos, things that need better wording, or so on, send proposed text changes. 

One chug was we removed the word CoGII and instead just talked about translators. Another word we could that was suggested was "proxy" or just talk about things that provide a "mapping function". I really don't much of an opinion about which of these words, or others, would be best but if people have thoughts, Speak up. 

Thanks, Cullen 

------------------------------------------------------------


CoRE (Constrained RESTful Environments)

CoRE is providing a framework for resource-oriented applications
intended to run on constrained IP networks.  A constrained IP network
has limited packet sizes, may exhibit a high degree of packet loss, and
may have a substantial number of devices that may be powered off at any
point in time but periodically "wake up" for brief periods of time.
These networks and the nodes within them are characterized by severe
limits on throughput, available power, and particularly on the
complexity that can be supported with limited code size and limited RAM
per node.  More generally, we speak of constrained networks whenever at
least some of the nodes and networks involved exhibit these
characteristics.  Low-Power Wireless Personal Area Networks (LoWPANs)
are an example of this type of network. LoWPANs are part of home and
building automation, energy management, and the Internet of Things.

The CoRE working group will define a framework for a limited class of
applications: those that deal with the manipulation of simple resources
on constrained networks. This includes applications to monitor simple
sensors (e.g. temperature sensors, light switches, and power meters), to
control actuators (e.g. light switches, heating controllers, and door
locks), and to manage devices.

The general architecture consists of nodes on the constrained network,
called Devices, that are responsible for one or more Resources that may
represent sensors, actuators, combinations of values or other
information.  Devices send messages to change and query resources on
other Devices. Devices can send notifications about changed resource
values to Devices that have subscribed to receive notification about
changes. A Device can also publish or be queried about its
description. Typically a single physical host on the network would have
just one Device but a host may represent multiple logical Devices. As
part of the framework for building these applications, the WG will
define a Constrained Application Protocol (CoAP) for the manipulation of
Resources on a Device.

CoAP will be designed for use between Devices on the same constrained
network, between Devices and general nodes on the Internet, and between
Devices on different constrained networks both joined by an
internet. CoAP targets the type of operating environments defined in the
ROLL and 6LOWPAN working groups which have additional constraints
compared to normal IP networks, but the CoAP protocol will also operate
over traditional IP networks.

There also may be translators that interconnect between other Internet
protocols and the Devices using the CoAP protocol.  The WG will define a
mapping from CoAP to an HTTP REST API; this mapping will not depend on a
specific application. It is worth noting that translation does not have
to occur at the boundary between the constrained network and the more
general network, but can be deployed at various locations in the
unconstrained network.

CoAP will support various forms of "caching".  For example, if a
temperature sensor is normally asleep but wakes up every five minutes
and sends the current temperature to a translator that has subscribed,
when the translator receives a request over HTTP for that temperature
resource, it can respond with the last seen value instead of trying to
query the Device which is currently asleep.
<RCC>This seems to imply that only a 'translator' can be a cache? This does have implications for the way the protocol is designed, i.e. it could be simpler if this is the case. On the other hand, it would be more flexible to allow caching in intermediate nodes which are not necessarily 'translators'. What is the intention here?</RCC>
The initial work item of the WG is to define a protocol specification
for CoAP that includes:

1) The ability to create, read, update and delete a Resource on a
   Device.

2) The ability to allow a Device to publish a value or event to another
   Device that has subscribed to be notified of changes, as well as the
   way for a Device to subscribe to receive publishes from another
   Device.

3) The ability to support a non-reliable multicast message to be sent to
   a group of Devices to manipulate a resource on all the Devices.

4) The core CoAP functionality MUST operate well over UDP and UDP MUST
   be implemented on CoAP Devices.  There may be OPTIONAL functions in
   CoAP (e.g. delivery of larger chunks of data) which if implemented
   are implemented over TCP. Applications which require the optional TCP
   features will limit themselves to a narrower subset of deployment
   cases.
<RCC>Still not entirely happy with this language but can live with it - see earlier comments posted on January 26th.</RCC>
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.

6) Specification for the HTTP REST based API and translation to
   communicate with Devices. Translation should make use of Device
   description information and should not need code updates to deal with
   new Devices.

7) Consider operational and manageability aspects of the protocol and at
   a minimum provide a way to tell if a Device is powered on or not.

The working group will not develop a reliable multicast solution, and
will not develop a general service discovery solution.

Security, particularly keying of new Devices, is very challenging for
these applications. The WG will work to select approaches to security
bootstrapping which are realistic given the constraints and requirements
of the network.  To ensure that any two nodes can join together, all
nodes must implement at least one universal bootstrapping method.

Security can be achieved using either session security or object
security.  For both object and session security, the WG will work with
the security area to select appropriate security framework and protocol
as well as selecting a minimal required to implement cipher suite. CoAP
will initially look at CMS (RFC 5652), TLS/DTLS, and EAP.

The WG will coordinate on requirements from many organizations including
OpenSG/NIST, ZigBee/HomePlug, IPSO Alliance, OASIS, SENSEI,
ASHRAE/BACnet; other SDOs and organizations. The WG will closely
coordinate with other IETF WGs including ROLL, 6LoWPAN, and appropriate
groups in the IETF OPS and Security areas.

Milestones:

Apr 2010 - Select WG document for basis of the CoAP protocol

Dec 2010 - CoAP protocol specification with mapping to HTTP Rest API
           submitted to IESG as PS

Dec 2010 - Constrained security bootstrapping specification submitted to
           IESG as PS

Jan 2011 - Recharter to add things reduced out of initial scope


_______________________________________________
6lowapp mailing list
6lowapp@ietf.org
https://www.ietf.org/mailman/listinfo/6lowapp
--------------010509050001050506040808-- --------------ms040102040700040300010901 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJKzCC AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5 CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35 90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5 CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35 90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQdBWGHEaYIBO/4g+d746QHzAJBgUrDgMC GgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDAy MDMxMjQ2MDlaMCMGCSqGSIb3DQEJBDEWBBR4pq/VDrPyJvAqhgg8Wmo2TqwbVzBfBgkqhkiG 9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpgg E7/iD53vjpAfMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpggE7/iD53vjpAfMA0GCSqGSIb3DQEBAQUA BIIBADRNKhwTeYAdQOO8RpIWQRA/VK/mAigfj6G/veMv/OQ4P8+hM6X/Urje2qVMf9iH9/us 3dwrz/dq9PmF0NPLGj1+GQMfz2W3g6DnUFWO0NpKWH+f1Bh0XTapd6ekO1xybgW6bTu5z/sb Xz7FfMshpK1XxwY9iUBHnL66X5wEpkIBMVT6u92k6Eb+r8begiEPoTboU7MyD/Oqg7RSW4IM m39YN2zD0KMiGbAqyxGixxcPpchc+VmRiVTvtGk7QXwU/kKUcaFvGlwLI4RT5yLxdII7h7Xj kxVe2d9muBQe0G4zMCUSjzCMDdsKGtdCpdJQkDz6y5KFsrfdEaK3D0Z5vagAAAAAAAA= --------------ms040102040700040300010901-- From zach@sensinode.com Thu Feb 4 00:55:31 2010 Return-Path: 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 75C223A6A6A for <6lowapp@core3.amsl.com>; Thu, 4 Feb 2010 00:55:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=-1.077, BAYES_00=-2.599, FRT_BELOW2=2.154, RCVD_IN_DNSWL_LOW=-1] 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 RfleokU4j6yZ for <6lowapp@core3.amsl.com>; Thu, 4 Feb 2010 00:55:30 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id D17563A6A66 for <6lowapp@ietf.org>; Thu, 4 Feb 2010 00:55:28 -0800 (PST) Received: from [62.145.172.51] ([62.145.172.51]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o148u4wg023753 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 4 Feb 2010 10:56:06 +0200 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: Date: Thu, 4 Feb 2010 10:56:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <48FC8D18-9377-41C0-A0EF-39B9D8B6F646@sensinode.com> References: <2A7B1CDC-5B99-47E8-9331-039D5997E1CC@cisco.com> To: JP Vasseur X-Mailer: Apple Mail (2.1077) 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 08:55:31 -0000 JP, Cullen, Below are my comments regarding discovery, I agree it is an important = feature. Summary:=20 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.=20 Comments in-line: On Feb 3, 2010, at 9:41 , JP Vasseur wrote: >>>=20 >>>=20 >>>>=20 >>>> 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. >>>=20 >>> 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. >>=20 >> It covers the naming aspects of device and services. (More or = discover bellow) >>=20 Yes, this can be used for discovery of devices running CoAP and their = resources. Sure, some text making that clear is a good idea. >>>>=20 >>>> The working group will not develop a reliable multicast solution, = and >>>> will not develop a general service discovery solution. >>>=20 >>> 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. >>=20 >> 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.=20 >>=20 >> 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.=20 >>=20 >> 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.=20 >=20 > 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 --=20 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.=20 From kerlyn2001@gmail.com Thu Feb 4 06:48:14 2010 Return-Path: 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> <48FC8D18-9377-41C0-A0EF-39B9D8B6F646@sensinode.com> Date: Thu, 4 Feb 2010 09:48:54 -0500 Message-ID: <3fe58b591002040648j389b0090p93a69f7ae4f7f46e@mail.gmail.com> From: Kerry Lynn To: Zach Shelby 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: , List-Archive: List-Post: List-Help: List-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 wrote: > JP, Cullen, > > Below are my comments regarding discovery, I agree it is an important fea= ture. 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 t= he bare minimum that works and is interoperable. > > For the first charter we do not want to define or modify a general servic= e discovery protocol, such as SLP. That is, we don't want to discover print= ers 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 l= ater 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 ser= vices)? >>>> If so, great otherwise i would suggest to clearly spell it out since t= his 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 res= ources. =A0Sure, 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 discove= ry, deployments will >>>> certainly be extremely difficult. We should at least work on the selec= tion of a discovery >>>> protocols, many candidates exist ... and potentially re-charter, shoul= d protocol extension >>>> will required. >>> >>> So I share your concern and was very skeptical of how this could be use= ful without a Discovery protocol. However, at the BOF, there was a surprisi= ngly strong HUM at the end to throw Discovery under the bus. This sort of f= reaked me out at first but as I came to talk to more people about it, I rea= lized 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 ch= arter and what is out of scope. >>> >>> First, a discovery protocol can be decoupled from a data transfer proto= col. 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 s= hould also decide to publish out to other devices what resources it support= s. 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 thi= nk it is just a device saying what characteristics it has and consider Disc= over much more complicated. =A0The other part in the proposed charter aroun= d discover is bein > =A0g consistent with existing naming constraints. The goal here is to mak= e 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 sta= te 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 witho= ut re-charting (or re-boffing) which is something I am perfectly happy to d= elay 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 di= scussed in length in several other WGs and even other SDOs, the lack of dis= covery 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 ke= y item. Would it make sense to poll the list on that particular aspect rest= ating what it means not to have a discovery solution for these kind of netw= orks (without re-BOFFING for course) ? Again the idea would not be to redef= ine 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 t= hat 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 discove= ry (like SLP) then that will need re-chartering. Anyways, 6lowapp is a more= general interest area, which may spawn several working groups. So this mig= ht 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 le= gally privileged information. If you are not the intended recipient, please= contact the sender and delete the e-mail from your system without producin= g, distributing or retaining copies thereof. > > > > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp > From zach@sensinode.com Thu Feb 4 10:23:13 2010 Return-Path: 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 C692428C16E for <6lowapp@core3.amsl.com>; Thu, 4 Feb 2010 10:23:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=-1.077, BAYES_00=-2.599, FRT_BELOW2=2.154, RCVD_IN_DNSWL_LOW=-1] 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 L-CMpXWYU7BL for <6lowapp@core3.amsl.com>; Thu, 4 Feb 2010 10:23:12 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 5707328C170 for <6lowapp@ietf.org>; Thu, 4 Feb 2010 10:23:10 -0800 (PST) Received: from [192.168.1.3] (line-4974.dyn.kponet.fi [85.29.65.192]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o14INkXc022993 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 4 Feb 2010 20:23:47 +0200 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <3fe58b591002040648j389b0090p93a69f7ae4f7f46e@mail.gmail.com> Date: Thu, 4 Feb 2010 20:23:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2A7B1CDC-5B99-47E8-9331-039D5997E1CC@cisco.com> <48FC8D18-9377-41C0-A0EF-39B9D8B6F646@sensinode.com> <3fe58b591002040648j389b0090p93a69f7ae4f7f46e@mail.gmail.com> To: Kerry Lynn X-Mailer: Apple Mail (2.1077) 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 18:23:13 -0000 Kerry, On Feb 4, 2010, at 16:48 , Kerry Lynn wrote: > Zach, JP, Cullen, >=20 > On Thu, Feb 4, 2010 at 3:56 AM, Zach Shelby = wrote: >> JP, Cullen, >>=20 >> Below are my comments regarding discovery, I agree it is an important = feature. Summary: >>=20 >> 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. >>=20 >> 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. >>=20 > 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. =20 What we heard in Hiroshima (I think you were not present?) was that this = WG needs to keep its scope very limited. 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? >>=20 >> Comments in-line: >>=20 >> On Feb 3, 2010, at 9:41 , JP Vasseur wrote: >>=20 >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> 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. >>>>>=20 >>>>> 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. >>>>=20 >>>> It covers the naming aspects of device and services. (More or = discover bellow) >>>>=20 >>=20 >> Yes, this can be used for discovery of devices running CoAP and their = resources. Sure, some text making that clear is a good idea. >>=20 > 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. >>>>>>=20 >>>>>> The working group will not develop a reliable multicast solution, = and >>>>>> will not develop a general service discovery solution. >>>>>=20 >>>>> 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. >>>>=20 >>>> 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. >>>>=20 >>>> 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. >>>>=20 >>>> 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. >>=20 >> I think you described that nicely Cullen. >>=20 > 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.=20= >>>=20 >>> 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. >>=20 >> 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? >>=20 > 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).=20 >=20 > 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). =20 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.=20 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?=20 Zach >=20 > Regards, -K- >=20 >=20 >> Zach >>=20 >>=20 >> -- >> 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 >>=20 >> Zach Shelby >> Head of Research >> Sensinode Ltd. >> Kidekuja 2 >> 88610 Vuokatti, FINLAND >>=20 >> 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. >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> 6lowapp mailing list >> 6lowapp@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowapp >>=20 --=20 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.=20 From kerlyn2001@gmail.com Thu Feb 4 11:26:54 2010 Return-Path: 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 81CBA28C1B7 for <6lowapp@core3.amsl.com>; Thu, 4 Feb 2010 11:26:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.155 X-Spam-Level: X-Spam-Status: No, score=0.155 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_BELOW2=2.154, J_CHICKENPOX_210=0.6] 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 oIqWL00qwQTH for <6lowapp@core3.amsl.com>; Thu, 4 Feb 2010 11:26:52 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id 3FB2C28C1AA for <6lowapp@ietf.org>; Thu, 4 Feb 2010 11:26:52 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 22so739254eye.51 for <6lowapp@ietf.org>; Thu, 04 Feb 2010 11:27:35 -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=6v9B6Q78ygw24ezWN0jBIMxxcFJq2ACyev4zss8wbDQ=; b=We+td9hFK+Z1aPiJuUaCbmazwKsYhw9a4nTwplljIugn/BXUP4TK5g2MmSSU8EEN3R QNqBvrNlrSNVMaddY4ozt755OW+Bpmlahe0SQzJoKlkqhrsGwBUwfFDQYSWinW5W1xQL xjS4ghrNyy+hYvYdlsGxzbGtTcrVvBuM6hXAw= 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=kFXs4NBRT7TMnGuc04ylVtaWGfiSzGSs4DqC/q2OiBuaKNs/lncf5iEkhtH1kx5Md5 ilTMC2jElBH5A3WAZ8jMAjLhP0PiBUm8Ewc6e0x8tRmKbgfcm/bkaQXIbe3vAvB62eko SmCKpC7MTpzFZ8mh7e39MRPK4irnj7ViL/Xm0= MIME-Version: 1.0 Received: by 10.216.87.140 with SMTP id y12mr62895wee.4.1265311654809; Thu, 04 Feb 2010 11:27:34 -0800 (PST) In-Reply-To: References: <2A7B1CDC-5B99-47E8-9331-039D5997E1CC@cisco.com> <48FC8D18-9377-41C0-A0EF-39B9D8B6F646@sensinode.com> <3fe58b591002040648j389b0090p93a69f7ae4f7f46e@mail.gmail.com> Date: Thu, 4 Feb 2010 14:27:34 -0500 Message-ID: <3fe58b591002041127v680b1dfu487f5b2fdf503b26@mail.gmail.com> From: Kerry Lynn To: Zach Shelby 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 19:26:54 -0000 Hi Zach, Comments inline... On Thu, Feb 4, 2010 at 1:23 PM, Zach Shelby 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 wrote: >>> JP, Cullen, >>> >>> Below are my comments regarding discovery, I agree it is an important f= eature. Summary: >>> >>> After the BOF consensus, what makes the most sense is to include a basi= c mechanism as part of CoAP which can be used for discovering devices runni= ng a CoAP service, and which CoAP resources that service has. This can sure= ly 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 serv= ice discovery protocol, such as SLP. That is, we don't want to discover pri= nters running IPP. I do agree that there is a need for a constrained genera= l 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 tr= ying 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 stan= dardized /index.html for CoAP. The naming of such resources should definite= ly be IETF consistent. This is what the charter says currently. Of course b= eing 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 m= ain 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 cons= trained 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 consisten= t >>>>>>> with other IETF work, e.g. draft-cheshire-dnsext-dns-sd. >>>>>> >>>>>> Does that cover the discovery aspects (of both the devices and the s= ervices)? >>>>>> 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 discove= r bellow) >>>>> >>> >>> Yes, this can be used for discovery of devices running CoAP and their r= esources. =A0Sure, 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. =A0Common 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 min= imum complexity. > >>>>>>> >>>>>>> The working group will not develop a reliable multicast solution, a= nd >>>>>>> will not develop a general service discovery solution. >>>>>> >>>>>> That is the part I was a bit worried about ... without service disco= very, deployments will >>>>>> certainly be extremely difficult. We should at least work on the sel= ection of a discovery >>>>>> protocols, many candidates exist ... and potentially re-charter, sho= uld protocol extension >>>>>> will required. >>>>> >>>>> So I share your concern and was very skeptical of how this could be u= seful without a Discovery protocol. However, at the BOF, there was a surpri= singly 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 r= ealized 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 pro= tocol. For example, a printer can be discovered with UPnP, Bonjour, SLP, et= c even though one might use IPP to print to it. What we are trying to do he= re is more the IPP like protocol. Second, the charter has the word " A Devi= ce 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 ca= n 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 suppo= rts. It could publish them to a multicast group. A device could also sent o= ut to multicast group what resources do you support and get back answers fr= om many devices. Some people think this is discover and many do not. They t= hink it is just a device saying what characteristics it has and consider Di= scover much more complicated. =A0The other part in the proposed charter aro= und discover is bein >>> =A0g consistent with existing naming constraints. The goal here is to m= ake 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 i= n some multicast DNS discover protocol. >>>>> >>>>> That my rough, and perhaps somewhat confused, interpretation of the s= tate 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 wit= hout 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> =A0As a thought experiment, remove DNS from the Internet and see >> where that leaves >> us. =A0Or, equivalently, deploy two or three similar mechanisms and let >> people choose the >> one they want. =A0That 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 believ= e 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 d= iscovery is almost a show stopper. Most proprietary solutions have their ow= n discovery solutions, we do have IP protocols that could make the work her= e with potential adaptation, I do not see how we could leave it out. In mos= t 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 re= stating what it means not to have a discovery solution for these kind of ne= tworks (without re-BOFFING for course) ? Again the idea would not be to red= efine 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 wan= t to work on adapting or designing a new protocol for general service disco= very (like SLP) then that will need re-chartering. Anyways, 6lowapp is a mo= re general interest area, which may spawn several working groups. So this m= ight be something for interested people to keep working on and then spin of= f 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. =A0So >> 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 /resour= ces using default CoAP UDP port 61626 (just a simplified example) there you= go. Different industries will need to customize their interface definition= s, and the idea is to allow that by including a URI to an interface descrip= tion (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 CoA= P 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". =A0There is wording >> in the draft >> that contradicts any assumption about a 1:1 correspondence between "devi= ce" and >> "host"; =A0"Typically a single physical host on the network would have >> just one Device >> but a host may represent multiple logical Devices." =A0As 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 discover= y. >> 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 a= t >> 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 alre= ady mentions that any naming for resources should be compatible with e.g. m= DNS naming. > > What would make you happy here (yet still get us a WG)? We could of cours= e include text saying that we will recommend a service discovery protocol t= hat should be used in addition to CoAP, if such a step is needed. Cullen, d= o 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 Interne= t" >>> 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, plea= se contact the sender and delete the e-mail from your system without produc= ing, distributing or retaining copies thereof. >>> >>> >>> >>> >>> _______________________________________________ >>> 6lowapp mailing list >>> 6lowapp@ietf.org >>> 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: +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 le= gally privileged information. If you are not the intended recipient, please= contact the sender and delete the e-mail from your system without producin= g, distributing or retaining copies thereof. > > > > > From jvasseur@cisco.com Thu Feb 4 12:06:49 2010 Return-Path: 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 8455E3A6E1A for <6lowapp@core3.amsl.com>; Thu, 4 Feb 2010 12:06:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.652 X-Spam-Level: X-Spam-Status: No, score=-9.652 tagged_above=-999 required=5 tests=[AWL=0.946, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 dEkhWrVfUZCJ for <6lowapp@core3.amsl.com>; Thu, 4 Feb 2010 12:06:48 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id D20533A6CD5 for <6lowapp@ietf.org>; Thu, 4 Feb 2010 12:06:47 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AloFAIe3aktAZnwM/2dsb2JhbACPVq9ymAOETAQ X-IronPort-AV: E=Sophos;i="4.49,406,1262563200"; d="scan'208,217";a="84093121" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 04 Feb 2010 20:07:34 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o14K7YWU002334; Thu, 4 Feb 2010 20:07:34 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Feb 2010 21:07:34 +0100 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Feb 2010 21:07:32 +0100 Message-Id: From: JP Vasseur To: Kerry Lynn , Zach Shelby In-Reply-To: <3fe58b591002041127v680b1dfu487f5b2fdf503b26@mail.gmail.com> Content-Type: multipart/alternative; boundary=Apple-Mail-514--755956805 Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 4 Feb 2010 21:07:31 +0100 References: <2A7B1CDC-5B99-47E8-9331-039D5997E1CC@cisco.com> <48FC8D18-9377-41C0-A0EF-39B9D8B6F646@sensinode.com> <3fe58b591002040648j389b0090p93a69f7ae4f7f46e@mail.gmail.com> <3fe58b591002041127v680b1dfu487f5b2fdf503b26@mail.gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 04 Feb 2010 20:07:32.0870 (UTC) FILETIME=[AFC01A60:01CAA5D5] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.000.1038-17174.001 X-TM-AS-Result: No--22.375900-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 20:06:49 -0000 --Apple-Mail-514--755956805 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit >> >>> 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 :) > Me too. Cheers. JP. > 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: +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 >>>> >> >> -- >> 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. >> >> >> >> >> --Apple-Mail-514--755956805 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable

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/Ser= viceTypes.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 = :)


Me = too.

Cheers.

JP.
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: = +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.or= g/mailman/listinfo/6lowapp
<= blockquote type=3D"cite">


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






= --Apple-Mail-514--755956805-- From scholza@in.tum.de Mon Feb 8 09:46:58 2010 Return-Path: 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 9088F28C12C for <6lowapp@core3.amsl.com>; Mon, 8 Feb 2010 09:46:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 mnSg3iL8xdw6 for <6lowapp@core3.amsl.com>; Mon, 8 Feb 2010 09:46:57 -0800 (PST) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id 92A9928C0DE for <6lowapp@ietf.org>; Mon, 8 Feb 2010 09:46:57 -0800 (PST) Received: from [131.159.16.116] (notekemper16.informatik.tu-muenchen.de [131.159.16.116]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.in.tum.de (Postfix) with ESMTP id D42CFBE36 for <6lowapp@ietf.org>; Mon, 8 Feb 2010 18:47:57 +0100 (CET) Message-ID: <4B704E48.4030000@in.tum.de> Date: Mon, 08 Feb 2010 18:47:52 +0100 From: Andreas Scholz User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: 6lowapp@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: [6lowapp] Reliability Requirements in draft-shelby-6lowapp-coap-00 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 17:46:58 -0000 As a short introduction: I am writing my Ph.D. thesis in the area of constrained networks for control and automation. So I have a rather automation-oriented point of view on the requirements for an application protocol. I have a remark regarding REQ10 in the CoAP draft. It states "Reliability must be provided for application layer messages". I am not sure that really all application layer messages have to be transmitted reliably. Consider for example a temperature sensor that provides readings on a frequent basis, e.g., every second. Based on the application that uses this data, a loss of a single packet (or even a bursty loss of multiple messages) may be tolerable. I am thinking of an application that controls a heater, or a monitoring application. In fact a retransmission of lost messages might even be a problem if this delays the transmission of the newly acquired data values. On the other hand there a plenty of messages that have to be transmitted reliably. I think it is very difficult to find a general set of such requirements (and other QoS requirements such as latency etc) that is suitable for all applications running in a resource constained network. Because QoS requirements are typically application specific, the subscriptions could be a good location for specifiying such requirements. I am thinking about a subscription mechanism that allows a subscriber to not only specify the resource he is interested in, but also additional parameters such as reliability. This could also be an interesting way for switching between UDP and TCP based communication; a subscriber could specify that the data should be delivered via TCP instead of the default transmission via UDP. Based on such a subscription mechanism, a node would also be able to reject subscriptions based on the specified non-functional parameters. For example because it possesses no protocol that supports reliable message transmission, or because it has not enough free memory to support an additional reliable connection (which requires storing sent messages). Best regards Andreas -- Andreas Scholz Lehrstuhl Informatik III Tel. +49 89 289-17292 TU München, Zimmer 02.11.037 FMI andreas.scholz@in.tum.de Boltzmannstr. 3, 85748 Garching From zach@sensinode.com Fri Feb 12 03:25:35 2010 Return-Path: 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 B830328C1A9 for <6lowapp@core3.amsl.com>; Fri, 12 Feb 2010 03:25:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 7PwI9oRI0K6L for <6lowapp@core3.amsl.com>; Fri, 12 Feb 2010 03:25:34 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 1CF4028C19B for <6lowapp@ietf.org>; Fri, 12 Feb 2010 03:25:33 -0800 (PST) Received: from [192.168.48.25] (93-63-160-186.ip28.fastwebnet.it [93.63.160.186]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o1CBQjDB012080 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 12 Feb 2010 13:26:46 +0200 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: Zach Shelby In-Reply-To: <4B704E48.4030000@in.tum.de> Date: Fri, 12 Feb 2010 12:26:46 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <105CAD44-328B-497F-BBFE-DDFD692FEB58@sensinode.com> References: <4B704E48.4030000@in.tum.de> To: Andreas Scholz X-Mailer: Apple Mail (2.1077) Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Reliability Requirements in draft-shelby-6lowapp-coap-00 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2010 11:25:35 -0000 Andreas, On Feb 8, 2010, at 18:47 , Andreas Scholz wrote: > As a short introduction: I am writing my Ph.D. thesis in the area of = constrained networks for control and automation. So I have a rather = automation-oriented point of view on the requirements for an application = protocol. >=20 > I have a remark regarding REQ10 in the CoAP draft. It states = "Reliability must be provided for application layer messages". I am not = sure that really all application layer messages have to be transmitted = reliably. Consider for example a temperature sensor that provides = readings on a frequent basis, e.g., every second. Based on the = application that uses this data, a loss of a single packet (or even a = bursty loss of multiple messages) may be tolerable. I am thinking of an = application that controls a heater, or a monitoring application. In fact = a retransmission of lost messages might even be a problem if this delays = the transmission of the newly acquired data values. On the other hand = there a plenty of messages that have to be transmitted reliably. Good point. My own assumption is that the reliability feature over UDP = can be shut off when not needed.=20 >=20 > I think it is very difficult to find a general set of such = requirements (and other QoS requirements such as latency etc) that is = suitable for all applications running in a resource constained network. = Because QoS requirements are typically application specific, the = subscriptions could be a good location for specifiying such = requirements. I am thinking about a subscription mechanism that allows a = subscriber to not only specify the resource he is interested in, but = also additional parameters such as reliability. This could also be an = interesting way for switching between UDP and TCP based communication; a = subscriber could specify that the data should be delivered via TCP = instead of the default transmission via UDP. This is something to consider wrt subscription, I could add some text = about that to draft-shelby-6lowapp-coap. >=20 > Based on such a subscription mechanism, a node would also be able to = reject subscriptions based on the specified non-functional parameters. = For example because it possesses no protocol that supports reliable = message transmission, or because it has not enough free memory to = support an additional reliable connection (which requires storing sent = messages). Definitely!=20 Zach >=20 >=20 > Best regards >=20 > Andreas >=20 > --=20 > Andreas Scholz Lehrstuhl Informatik III > Tel. +49 89 289-17292 TU M=FCnchen, Zimmer 02.11.037 FMI > andreas.scholz@in.tum.de Boltzmannstr. 3, 85748 Garching >=20 > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp --=20 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.=20 From gc355804@ohio.edu Fri Feb 12 14:37:11 2010 Return-Path: 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 0690E28C169 for <6lowapp@core3.amsl.com>; Fri, 12 Feb 2010 14:37:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.178 X-Spam-Level: X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[AWL=0.422, BAYES_00=-2.599] 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 z4jmM1NkH9GD for <6lowapp@core3.amsl.com>; Fri, 12 Feb 2010 14:37:09 -0800 (PST) Received: from mx4.oit.ohio.edu (mx4.oit.ohio.edu [132.235.250.54]) by core3.amsl.com (Postfix) with ESMTP id BA12A28C14B for <6lowapp@ietf.org>; Fri, 12 Feb 2010 14:37:09 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAFJndUuE6wiX/2dsb2JhbACbf7IDDoQgiFWCTIIMBIMT X-IronPort-AV: E=Sophos;i="4.49,463,1262581200"; d="scan'208";a="29304836" Received: from oak3a.cats.ohiou.edu (HELO oak.cats.ohiou.edu) ([132.235.8.151]) by smtpout4.oit.ohio.edu with ESMTP; 12 Feb 2010 17:38:29 -0500 Received: from wrath.cs.ohiou.edu (wrath.cs.ohiou.edu [132.235.3.135]) (authenticated bits=0) by oak.cats.ohiou.edu (8.13.1/8.13.1) with ESMTP id o1CMbZaF1937322 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Feb 2010 17:37:40 -0500 (EST) Message-ID: <4B75D82F.6060508@ohio.edu> Date: Fri, 12 Feb 2010 17:37:35 -0500 From: "G. Clark" User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Zach Shelby References: <4B704E48.4030000@in.tum.de> <105CAD44-328B-497F-BBFE-DDFD692FEB58@sensinode.com> In-Reply-To: <105CAD44-328B-497F-BBFE-DDFD692FEB58@sensinode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Reliability Requirements in draft-shelby-6lowapp-coap-00 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2010 22:37:11 -0000 Hi: A quick question / comment: Zach Shelby wrote: > Andreas, > > On Feb 8, 2010, at 18:47 , Andreas Scholz wrote: > > >> As a short introduction: I am writing my Ph.D. thesis in the area of constrained networks for control and automation. So I have a rather automation-oriented point of view on the requirements for an application protocol. >> >> I have a remark regarding REQ10 in the CoAP draft. It states "Reliability must be provided for application layer messages". I am not sure that really all application layer messages have to be transmitted reliably. Consider for example a temperature sensor that provides readings on a frequent basis, e.g., every second. Based on the application that uses this data, a loss of a single packet (or even a bursty loss of multiple messages) may be tolerable. I am thinking of an application that controls a heater, or a monitoring application. In fact a retransmission of lost messages might even be a problem if this delays the transmission of the newly acquired data values. On the other hand there a plenty of messages that have to be transmitted reliably. >> > > Good point. My own assumption is that the reliability feature over UDP can be shut off when not needed. > > I did notice that in section 2.8.1 (wrt UDP transport), the draft said: "Stop-and-wait would be sufficient for reliability. A simple response message itself would suffice as an acknowledgement with retransmission support. Not all requests require reliability, thus this should be optional." I found this to be a bit confusing, though: how do we meet REQ10 without enforcing reliability in requests? >> I think it is very difficult to find a general set of such requirements (and other QoS requirements such as latency etc) that is suitable for all applications running in a resource constained network. Because QoS requirements are typically application specific, the subscriptions could be a good location for specifiying such requirements. I am thinking about a subscription mechanism that allows a subscriber to not only specify the resource he is interested in, but also additional parameters such as reliability. This could also be an interesting way for switching between UDP and TCP based communication; a subscriber could specify that the data should be delivered via TCP instead of the default transmission via UDP. >> > > This is something to consider wrt subscription, I could add some text about that to draft-shelby-6lowapp-coap. > Instead of including TCP / UDP in the subscription request, would it be a bad plan to encode reliability in a service's URL? e.g. coap[s]://my.device/reliable/service. In this way, you could also mirror services (coap[s]://my.device/xyz, coap[s]://my.device/reliable/xyz) pretty easily. This does have the downside of introducing more overhead, and it wouldn't be practical for multiple options to be encoded this way. This approach would move the decision for reliable / non-reliable transport to the application layer. >> Based on such a subscription mechanism, a node would also be able to reject subscriptions based on the specified non-functional parameters. For example because it possesses no protocol that supports reliable message transmission, or because it has not enough free memory to support an additional reliable connection (which requires storing sent messages). >> > > Definitely! > > Zach > > Regards, Gilbert Clark Grad Student Ohio University >> Best regards >> >> Andreas >> >> -- >> Andreas Scholz Lehrstuhl Informatik III >> Tel. +49 89 289-17292 TU München, Zimmer 02.11.037 FMI >> andreas.scholz@in.tum.de Boltzmannstr. 3, 85748 Garching >> >> _______________________________________________ >> 6lowapp mailing list >> 6lowapp@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowapp >> > > From fluffy@cisco.com Fri Feb 12 16:54:03 2010 Return-Path: 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 DDBF83A792D for <6lowapp@core3.amsl.com>; Fri, 12 Feb 2010 16:54:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.492 X-Spam-Level: X-Spam-Status: No, score=-110.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 d7KDZZzRrc0u for <6lowapp@core3.amsl.com>; Fri, 12 Feb 2010 16:54:02 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 2BCA43A792A for <6lowapp@ietf.org>; Fri, 12 Feb 2010 16:54:02 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPeGdUurR7Ht/2dsb2JhbACbDnSmWZdQhFgEgxM X-IronPort-AV: E=Sophos;i="4.49,464,1262563200"; d="scan'208";a="298879940" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 13 Feb 2010 00:55:22 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o1D0tL6Q012840 for <6lowapp@ietf.org>; Sat, 13 Feb 2010 00:55:22 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1077) Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings Date: Fri, 12 Feb 2010 17:55:20 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6DFD7877-9E5A-4E08-906E-90859608473D@cisco.com> References: To: 6lowapp@ietf.org X-Mailer: Apple Mail (2.1077) Subject: [6lowapp] CORE charter sent for IESG review 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2010 00:54:04 -0000 Lisa sent the following charter to the IESG for review. That review will = likely happen next thursday. The IESG may have some comments and/or = changes then they will send it out for IETF Last Call. At that point, = folks on this list and everyone else can suggest any final changes they = think are critical to make. After that it will go back to the IESG and = the IESG will make a decision about approving the WG or not. (I think = this is highly likely to be approved, it's more an issue in what changes = might be needed before it is approved). Thanks everyone for all work on this charter.=20 Cullen Begin forwarded message: >=20 > CoRE (Constrained RESTful Environments) >=20 > CoRE is providing a framework for resource-oriented applications > intended to run on constrained IP networks. A constrained IP network > has limited packet sizes, may exhibit a high degree of packet loss, = and > may have a substantial number of devices that may be powered off at = any > point in time but periodically "wake up" for brief periods of time. > These networks and the nodes within them are characterized by severe > limits on throughput, available power, and particularly on the > complexity that can be supported with limited code size and limited = RAM > per node. More generally, we speak of constrained networks whenever = at > least some of the nodes and networks involved exhibit these > characteristics. Low-Power Wireless Personal Area Networks (LoWPANs) > are an example of this type of network. Constrained networks can = occur > as part of home and building automation, energy management, and the > Internet of Things. >=20 > The CoRE working group will define a framework for a limited class of > applications: those that deal with the manipulation of simple = resources > on constrained networks. This includes applications to monitor simple > sensors (e.g. temperature sensors, light switches, and power meters), = to > control actuators (e.g. light switches, heating controllers, and door > locks), and to manage devices. >=20 > The general architecture consists of nodes on the constrained network, > called Devices, that are responsible for one or more Resources that = may > represent sensors, actuators, combinations of values or other > information. Devices send messages to change and query resources on > other Devices. Devices can send notifications about changed resource > values to Devices that have subscribed to receive notification about > changes. A Device can also publish or be queried about its > resources. (Typically a single physical host on the network would have > just one Device but a host might represent multiple logical Devices. > The specific terminology to be used here is to be decided by the WG.) > As part of the framework for building these applications, the WG will > define a Constrained Application Protocol (CoAP) for the manipulation = of > Resources on a Device. >=20 > CoAP will be designed for use between Devices on the same constrained > network, between Devices and general nodes on the Internet, and = between > Devices on different constrained networks both joined by an > internet. CoAP targets the type of operating environments defined in = the > ROLL and 6LOWPAN working groups which have additional constraints > compared to normal IP networks, but the CoAP protocol will also = operate > over traditional IP networks. >=20 > There also may be proxies that interconnect between other Internet > protocols and the Devices using the CoAP protocol. The WG will define = a > mapping from CoAP to an HTTP REST API; this mapping will not depend on = a > specific application. It is worth noting that proxy does not have to > occur at the boundary between the constrained network and the more > general network, but can be deployed at various locations in the > unconstrained network. >=20 > CoAP will support various forms of "caching". For example, if a > temperature sensor is normally asleep but wakes up every five minutes > and sends the current temperature to a proxy that has subscribed, when > the proxy receives a request over HTTP for that temperature resource, = it > can respond with the last seen value instead of trying to query the > Device which is currently asleep. >=20 > The initial work item of the WG is to define a protocol specification > for CoAP that includes: >=20 > 1) The ability to create, read, update and delete a Resource on a > Device. >=20 > 2) The ability to allow a Device to publish a value or event to = another > Device that has subscribed to be notified of changes, as well as the > way for a Device to subscribe to receive publishes from another > Device. >=20 > 3) The ability to support a non-reliable multicast message to be sent = to > a group of Devices to manipulate a resource on all the Devices in = the > group. >=20 > 4) The core CoAP functionality MUST operate well over UDP and UDP MUST > be implemented on CoAP Devices. There may be OPTIONAL functions in > CoAP (e.g. delivery of larger chunks of data) which if implemented = are > implemented over TCP. Applications which require the optional TCP > features will limit themselves to a narrower subset of deployment > cases. >=20 > 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 Web Application Description Language (WADL) > document) and an optional name or identifier. The name taxonomy = used > for this description will be consistent with other IETF work, > e.g. draft-cheshire-dnsext-dns-sd. >=20 > 6) Specification for the HTTP REST based API and translation to > communicate with Devices. Translation should make use of Device > description information and should not need code updates to deal = with > new Devices. >=20 > 7) Consider operational and manageability aspects of the protocol and = at > a minimum provide a way to tell if a Device is powered on or not. >=20 > The working group will not develop a reliable multicast solution, and > will not develop a general service discovery solution. There is a = desire > for discovery and configuration features, but the working group has = not > yet closed in on an specific approach. Thus, the WG may explore these > topics and adopt drafts that define requirements or set problem > statements, but will not adopt implementable specifications without a > recharter. >=20 > Security, particularly keying of new Devices, is very challenging for > these applications. The WG will work to select approaches to security > bootstrapping which are realistic given the constraints and = requirements > of the network. To ensure that any two nodes can join together, all > nodes must implement at least one universal bootstrapping method. >=20 > Security can be achieved using either session security or object > security. For both object and session security, the WG will work with > the security area to select appropriate security framework and = protocol > as well as selecting a minimal required to implement cipher suite. = CoAP > will initially look at CMS (RFC 5652), TLS/DTLS, and EAP. >=20 > The WG will coordinate on requirements from many organizations = including > OpenSG/NIST, ZigBee/HomePlug, IPSO Alliance, OASIS, SENSEI, > ASHRAE/BACnet; other SDOs and organizations. The WG will closely > coordinate with other IETF WGs including ROLL, 6LoWPAN, and = appropriate > groups in the IETF OPS and Security areas. >=20 > Milestones: >=20 > Apr 2010 - Select WG document for basis of the CoAP protocol >=20 > Dec 2010 - CoAP protocol specification with mapping to HTTP Rest API > submitted to IESG as PS >=20 > Dec 2010 - Constrained security bootstrapping specification submitted = to > IESG as PS >=20 > Jan 2011 - Recharter to add things reduced out of initial scope Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From zach@sensinode.com Mon Feb 15 02:34:11 2010 Return-Path: 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 BD3B93A7B40 for <6lowapp@core3.amsl.com>; Mon, 15 Feb 2010 02:34:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.509 X-Spam-Level: X-Spam-Status: No, score=-3.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 26TG9lNZFXcd for <6lowapp@core3.amsl.com>; Mon, 15 Feb 2010 02:34:10 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id EA9133A69F3 for <6lowapp@ietf.org>; Mon, 15 Feb 2010 02:34:09 -0800 (PST) Received: from [62.145.172.51] ([62.145.172.51]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o1FAZWwa018770 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 15 Feb 2010 12:35:32 +0200 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <6DFD7877-9E5A-4E08-906E-90859608473D@cisco.com> Date: Mon, 15 Feb 2010 12:35:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <89491867-CB97-4E82-96CB-B95C69419CA8@sensinode.com> References: <6DFD7877-9E5A-4E08-906E-90859608473D@cisco.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1077) Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] CORE charter sent for IESG review 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 10:34:11 -0000 I updated the Wiki with the updated charter text: http://trac.tools.ietf.org/area/app/trac/wiki/6LowApp Zach On Feb 13, 2010, at 2:55 , Cullen Jennings wrote: >=20 > Lisa sent the following charter to the IESG for review. That review = will likely happen next thursday. The IESG may have some comments and/or = changes then they will send it out for IETF Last Call. At that point, = folks on this list and everyone else can suggest any final changes they = think are critical to make. After that it will go back to the IESG and = the IESG will make a decision about approving the WG or not. (I think = this is highly likely to be approved, it's more an issue in what changes = might be needed before it is approved). >=20 > Thanks everyone for all work on this charter.=20 >=20 > Cullen >=20 >=20 > Begin forwarded message: >=20 >>=20 >> CoRE (Constrained RESTful Environments) >>=20 >> CoRE is providing a framework for resource-oriented applications >> intended to run on constrained IP networks. A constrained IP network >> has limited packet sizes, may exhibit a high degree of packet loss, = and >> may have a substantial number of devices that may be powered off at = any >> point in time but periodically "wake up" for brief periods of time. >> These networks and the nodes within them are characterized by severe >> limits on throughput, available power, and particularly on the >> complexity that can be supported with limited code size and limited = RAM >> per node. More generally, we speak of constrained networks whenever = at >> least some of the nodes and networks involved exhibit these >> characteristics. Low-Power Wireless Personal Area Networks (LoWPANs) >> are an example of this type of network. Constrained networks can = occur >> as part of home and building automation, energy management, and the >> Internet of Things. >>=20 >> The CoRE working group will define a framework for a limited class of >> applications: those that deal with the manipulation of simple = resources >> on constrained networks. This includes applications to monitor simple >> sensors (e.g. temperature sensors, light switches, and power meters), = to >> control actuators (e.g. light switches, heating controllers, and door >> locks), and to manage devices. >>=20 >> The general architecture consists of nodes on the constrained = network, >> called Devices, that are responsible for one or more Resources that = may >> represent sensors, actuators, combinations of values or other >> information. Devices send messages to change and query resources on >> other Devices. Devices can send notifications about changed resource >> values to Devices that have subscribed to receive notification about >> changes. A Device can also publish or be queried about its >> resources. (Typically a single physical host on the network would = have >> just one Device but a host might represent multiple logical Devices. >> The specific terminology to be used here is to be decided by the WG.) >> As part of the framework for building these applications, the WG will >> define a Constrained Application Protocol (CoAP) for the manipulation = of >> Resources on a Device. >>=20 >> CoAP will be designed for use between Devices on the same constrained >> network, between Devices and general nodes on the Internet, and = between >> Devices on different constrained networks both joined by an >> internet. CoAP targets the type of operating environments defined in = the >> ROLL and 6LOWPAN working groups which have additional constraints >> compared to normal IP networks, but the CoAP protocol will also = operate >> over traditional IP networks. >>=20 >> There also may be proxies that interconnect between other Internet >> protocols and the Devices using the CoAP protocol. The WG will = define a >> mapping from CoAP to an HTTP REST API; this mapping will not depend = on a >> specific application. It is worth noting that proxy does not have to >> occur at the boundary between the constrained network and the more >> general network, but can be deployed at various locations in the >> unconstrained network. >>=20 >> CoAP will support various forms of "caching". For example, if a >> temperature sensor is normally asleep but wakes up every five minutes >> and sends the current temperature to a proxy that has subscribed, = when >> the proxy receives a request over HTTP for that temperature resource, = it >> can respond with the last seen value instead of trying to query the >> Device which is currently asleep. >>=20 >> The initial work item of the WG is to define a protocol specification >> for CoAP that includes: >>=20 >> 1) The ability to create, read, update and delete a Resource on a >> Device. >>=20 >> 2) The ability to allow a Device to publish a value or event to = another >> Device that has subscribed to be notified of changes, as well as the >> way for a Device to subscribe to receive publishes from another >> Device. >>=20 >> 3) The ability to support a non-reliable multicast message to be sent = to >> a group of Devices to manipulate a resource on all the Devices in = the >> group. >>=20 >> 4) The core CoAP functionality MUST operate well over UDP and UDP = MUST >> be implemented on CoAP Devices. There may be OPTIONAL functions in >> CoAP (e.g. delivery of larger chunks of data) which if implemented = are >> implemented over TCP. Applications which require the optional TCP >> features will limit themselves to a narrower subset of deployment >> cases. >>=20 >> 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 Web Application Description Language (WADL) >> document) and an optional name or identifier. The name taxonomy = used >> for this description will be consistent with other IETF work, >> e.g. draft-cheshire-dnsext-dns-sd. >>=20 >> 6) Specification for the HTTP REST based API and translation to >> communicate with Devices. Translation should make use of Device >> description information and should not need code updates to deal = with >> new Devices. >>=20 >> 7) Consider operational and manageability aspects of the protocol and = at >> a minimum provide a way to tell if a Device is powered on or not. >>=20 >> The working group will not develop a reliable multicast solution, and >> will not develop a general service discovery solution. There is a = desire >> for discovery and configuration features, but the working group has = not >> yet closed in on an specific approach. Thus, the WG may explore these >> topics and adopt drafts that define requirements or set problem >> statements, but will not adopt implementable specifications without a >> recharter. >>=20 >> Security, particularly keying of new Devices, is very challenging for >> these applications. The WG will work to select approaches to security >> bootstrapping which are realistic given the constraints and = requirements >> of the network. To ensure that any two nodes can join together, all >> nodes must implement at least one universal bootstrapping method. >>=20 >> Security can be achieved using either session security or object >> security. For both object and session security, the WG will work = with >> the security area to select appropriate security framework and = protocol >> as well as selecting a minimal required to implement cipher suite. = CoAP >> will initially look at CMS (RFC 5652), TLS/DTLS, and EAP. >>=20 >> The WG will coordinate on requirements from many organizations = including >> OpenSG/NIST, ZigBee/HomePlug, IPSO Alliance, OASIS, SENSEI, >> ASHRAE/BACnet; other SDOs and organizations. The WG will closely >> coordinate with other IETF WGs including ROLL, 6LoWPAN, and = appropriate >> groups in the IETF OPS and Security areas. >>=20 >> Milestones: >>=20 >> Apr 2010 - Select WG document for basis of the CoAP protocol >>=20 >> Dec 2010 - CoAP protocol specification with mapping to HTTP Rest API >> submitted to IESG as PS >>=20 >> Dec 2010 - Constrained security bootstrapping specification submitted = to >> IESG as PS >>=20 >> Jan 2011 - Recharter to add things reduced out of initial scope >=20 >=20 > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html >=20 >=20 >=20 > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp --=20 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.=20 From zach@sensinode.com Mon Feb 15 02:46:29 2010 Return-Path: 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 3D49528C114 for <6lowapp@core3.amsl.com>; Mon, 15 Feb 2010 02:46:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.516 X-Spam-Level: X-Spam-Status: No, score=-3.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 4vJ7pUJbA7QF for <6lowapp@core3.amsl.com>; Mon, 15 Feb 2010 02:46:28 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id D08B73A7B42 for <6lowapp@ietf.org>; Mon, 15 Feb 2010 02:46:27 -0800 (PST) Received: from [62.145.172.51] ([62.145.172.51]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o1FAlpZm020016 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 15 Feb 2010 12:47:52 +0200 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: Zach Shelby In-Reply-To: <4B75D82F.6060508@ohio.edu> Date: Mon, 15 Feb 2010 12:47:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B704E48.4030000@in.tum.de> <105CAD44-328B-497F-BBFE-DDFD692FEB58@sensinode.com> <4B75D82F.6060508@ohio.edu> To: "G. Clark" X-Mailer: Apple Mail (2.1077) Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Reliability Requirements in draft-shelby-6lowapp-coap-00 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 10:46:29 -0000 Gilbert, On Feb 13, 2010, at 0:37 , G. Clark wrote: >>=20 >> Good point. My own assumption is that the reliability feature over = UDP can be shut off when not needed.=20 >> =20 > I did notice that in section 2.8.1 (wrt UDP transport), the draft = said: "Stop-and-wait would be sufficient for reliability. A simple = response message itself would suffice as an acknowledgement with = retransmission support. Not all requests require reliability, thus this = should be optional." I found this to be a bit confusing, though: how do = we meet REQ10 without enforcing reliability in requests? The Section 2.8.1 text is correct. It is REQ10 that is a bit misleading. = The protocol is required to have a reliability feature, but the = application isn't required to use it ;-) I'll update that in the -01 = spin (coming this week). >>> I think it is very difficult to find a general set of such = requirements (and other QoS requirements such as latency etc) that is = suitable for all applications running in a resource constained network. = Because QoS requirements are typically application specific, the = subscriptions could be a good location for specifiying such = requirements. I am thinking about a subscription mechanism that allows a = subscriber to not only specify the resource he is interested in, but = also additional parameters such as reliability. This could also be an = interesting way for switching between UDP and TCP based communication; a = subscriber could specify that the data should be delivered via TCP = instead of the default transmission via UDP. >>> =20 >>=20 >> This is something to consider wrt subscription, I could add some text = about that to draft-shelby-6lowapp-coap. >> =20 > Instead of including TCP / UDP in the subscription request, would it = be a bad plan to encode reliability in a service's URL? e.g. = coap[s]://my.device/reliable/service. In this way, you could also = mirror services (coap[s]://my.device/xyz, = coap[s]://my.device/reliable/xyz) pretty easily. This does have the = downside of introducing more overhead, and it wouldn't be practical for = multiple options to be encoded this way.=20 > This approach would move the decision for reliable / non-reliable = transport to the application layer. Reliability should be controlled by the application layer originating a = message. For TCP/UDP this is simply done with a Socket API. For the UDP = reliability feature, this can be a flag in the header of the message, = for example an "ACK ME" flag. In that way a resource (URL) is not = dependent on the protocol features used to access it. Makes sense?=20 Zach >>=20 >>=20 >> =20 > Regards, > Gilbert Clark > Grad Student > Ohio University >>> Best regards >>>=20 >>> Andreas >>>=20 >>> --=20 >>> Andreas Scholz Lehrstuhl Informatik III >>> Tel. +49 89 289-17292 TU M=FCnchen, Zimmer 02.11.037 FMI >>> andreas.scholz@in.tum.de Boltzmannstr. 3, 85748 Garching >>>=20 >>> _______________________________________________ >>> 6lowapp mailing list >>> 6lowapp@ietf.org >>> https://www.ietf.org/mailman/listinfo/6lowapp >>> =20 >>=20 >> =20 >=20 --=20 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.=20 From gc355804@ohio.edu Mon Feb 15 05:04:35 2010 Return-Path: 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 B2F7F3A7649 for <6lowapp@core3.amsl.com>; Mon, 15 Feb 2010 05:04:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 0jGBlxY8XhVs for <6lowapp@core3.amsl.com>; Mon, 15 Feb 2010 05:04:34 -0800 (PST) Received: from mx2.oit.ohio.edu (mx2.oit.ohio.edu [132.235.51.19]) by core3.amsl.com (Postfix) with ESMTP id 940403A7530 for <6lowapp@ietf.org>; Mon, 15 Feb 2010 05:04:34 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAA/VeEuE6wiX/2dsb2JhbACcEK9eDoM5iFWCTYIOBIMU X-IronPort-AV: E=Sophos;i="4.49,476,1262581200"; d="scan'208";a="30366349" Received: from oak3a.cats.ohiou.edu (HELO oak.cats.ohiou.edu) ([132.235.8.151]) by smtpout2.oit.ohio.edu with ESMTP; 15 Feb 2010 08:06:04 -0500 Received: from [10.1.42.187] (cpe-75-180-9-158.columbus.res.rr.com [75.180.9.158]) (authenticated bits=0) by oak.cats.ohiou.edu (8.13.1/8.13.1) with ESMTP id o1FD5EGe1779517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Feb 2010 08:05:15 -0500 (EST) Message-ID: <4B794690.7080100@ohio.edu> Date: Mon, 15 Feb 2010 08:05:20 -0500 From: "G. Clark" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Zach Shelby References: <4B704E48.4030000@in.tum.de> <105CAD44-328B-497F-BBFE-DDFD692FEB58@sensinode.com> <4B75D82F.6060508@ohio.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Reliability Requirements in draft-shelby-6lowapp-coap-00 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 13:04:35 -0000 Zach Shelby wrote: > Gilbert, > > On Feb 13, 2010, at 0:37 , G. Clark wrote: > > >>> Good point. My own assumption is that the reliability feature over UDP can be shut off when not needed. >>> >>> >> I did notice that in section 2.8.1 (wrt UDP transport), the draft said: "Stop-and-wait would be sufficient for reliability. A simple response message itself would suffice as an acknowledgement with retransmission support. Not all requests require reliability, thus this should be optional." I found this to be a bit confusing, though: how do we meet REQ10 without enforcing reliability in requests? >> > > The Section 2.8.1 text is correct. It is REQ10 that is a bit misleading. The protocol is required to have a reliability feature, but the application isn't required to use it ;-) I'll update that in the -01 spin (coming this week). > > Ah hah! Got it; thanks. >>>> I think it is very difficult to find a general set of such requirements (and other QoS requirements such as latency etc) that is suitable for all applications running in a resource constained network. Because QoS requirements are typically application specific, the subscriptions could be a good location for specifiying such requirements. I am thinking about a subscription mechanism that allows a subscriber to not only specify the resource he is interested in, but also additional parameters such as reliability. This could also be an interesting way for switching between UDP and TCP based communication; a subscriber could specify that the data should be delivered via TCP instead of the default transmission via UDP. >>>> >>>> >>> This is something to consider wrt subscription, I could add some text about that to draft-shelby-6lowapp-coap. >>> >>> >> Instead of including TCP / UDP in the subscription request, would it be a bad plan to encode reliability in a service's URL? e.g. coap[s]://my.device/reliable/service. In this way, you could also mirror services (coap[s]://my.device/xyz, coap[s]://my.device/reliable/xyz) pretty easily. This does have the downside of introducing more overhead, and it wouldn't be practical for multiple options to be encoded this way. >> This approach would move the decision for reliable / non-reliable transport to the application layer. >> > > Reliability should be controlled by the application layer originating a message. For TCP/UDP this is simply done with a Socket API. For the UDP reliability feature, this can be a flag in the header of the message, for example an "ACK ME" flag. In that way a resource (URL) is not dependent on the protocol features used to access it. Makes sense? > It does; thanks! I'm not sure I completely understand here, though; mind clarifying why don't we want a resource to be dependent on protocol features? I can think of a few cases where I'd only want to offer access to a service over UDP as opposed to TCP, for example. > Zach > Thanks, Gilbert From adam@sics.se Wed Feb 17 12:38:24 2010 Return-Path: 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 D0F753A7F18; Wed, 17 Feb 2010 12:38:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_INVITATION=-2, HELO_EQ_SE=0.35] 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 Mjn+GheK3YLF; Wed, 17 Feb 2010 12:38:23 -0800 (PST) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id 84C703A7F14; Wed, 17 Feb 2010 12:38:23 -0800 (PST) Received: from [10.1.1.143] (unknown [10.1.1.143]) by letter.sics.se (Postfix) with ESMTPS id C801440103; Wed, 17 Feb 2010 21:40:01 +0100 (CET) Message-ID: <4B7C534B.1050404@sics.se> Date: Wed, 17 Feb 2010 21:36:27 +0100 From: Adam Dunkels User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: ROLL WG , 6lowpan <6lowpan@ietf.org>, 6lowapp@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: [6lowapp] ACM HotEmNets: deadline extended, paper submission open 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2010 20:38:24 -0000 The paper submission deadline for HotEmNets 2010 has been extended due to several requests: New deadline: 1 March 2010 Paper submission is now open: https://www.easychair.org/login.cgi?conf=hotemnets2010 HotEMNETS 2010 - 6th Workshop on Hot Topics in Embedded Networked Sensors http://www.hotemnets2010.org/ The Sixth Workshop on Hot Topics in Embedded Networked Sensors (HotEmNets 2010) brings together wireless sensor network researchers from academic and industrial backgrounds to present groundbreaking results that will shed light on present and future research challenges. The workshop emphasizes results from experiments or deployments that quantify the challenges in the wireless sensor systems of today as well as early results from new ideas that introduce promising approaches that will define the challenges in the wireless sensor systems of tomorrow. We especially welcome papers reporting on results that refute common assumptions, deployment experiences, novel and original approaches, and, more generally, papers that will help inform and guide research. Attendance to HotEmNets 2010 will be by invitation only, but everyone is encouraged to submit papers. Authors of accepted papers, TPC and SC members as well as other distinguished members of the community will be invited to enable a focused and productive discussion. Topics of interest include, but are not limited to: * Validation/refutation of prior results * Applications beyond data collection * Application experiences: measurements, lessons learned * Future applications: requirements and challenges * Integration of sensor networks and IP networks * Hardware platforms, tradeoffs, and trends * Data and network storage * Delay-tolerant networking * Management, debugging, and troubleshooting * Network and software reliability * Network and system architectures * Software bug detection and tools * Energy sources, scavenging, and low-power operation * Human-Computer interfaces for sensor nets Important Dates DEADLINE EXTENDED: March 1, 2010 Notification: April 15, 2010 Camera Ready: May 10, 2010 Conference: June 28-29, 2010 Workshop Venue Killarney, Ireland General Chair: Dirk Pesch, Cork Institute of Technology Program Co-Chairs: Adam Dunkels, SICS Akos Ledeczi, Vanderbilt University Publications Chair: Antonio Ruzzelli, University College Dublin TPC: Philippe Bonnet, IT University of Copenhagen, Denmark Niru Bulusu, Portland State University, USA Prabal Dutta, University of Michigan, USA Mary Ann Ingram, Georgia Tech, USA Utz Rödig, Lancaster University, UK Kay Römer, University of Lübeck, Germany Janos Sallai, Vanderbilt University, USA Andreas Terzis, Johns Hopkins University, USA Roberto Verdone, University of Bologna, Italy Kamin Whitehouse, University of Virginia, USA Feng Zhao, Microsoft Research, China Steering Committee: Sanjay Jha (chair), UNSW Cormac Sreenan, Uni. College Cork John Heidemann, USC/ISI Andrew Campbell, Dartmouth College Nirupama Bulusu, PSU -- Adam Dunkels | +46 70 7731614 | http://www.sics.se/~adam/ Book: Interconnecting Smart Objects with IP - http://TheNextInternet.org From zach@sensinode.com Thu Feb 18 07:24:43 2010 Return-Path: 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 9BEC83A7CE1 for <6lowapp@core3.amsl.com>; Thu, 18 Feb 2010 07:24:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.527 X-Spam-Level: X-Spam-Status: No, score=-3.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 nimY91J277zo for <6lowapp@core3.amsl.com>; Thu, 18 Feb 2010 07:24:42 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 314663A7B6A for <6lowapp@ietf.org>; Thu, 18 Feb 2010 07:24:41 -0800 (PST) Received: from [62.145.172.51] ([62.145.172.51]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o1IFQJWh000997 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <6lowapp@ietf.org>; Thu, 18 Feb 2010 17:26:19 +0200 From: Zach Shelby Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 18 Feb 2010 17:26:21 +0200 References: <20100218152028.9453E28C0E8@core3.amsl.com> To: 6LoWAPP <6lowapp@ietf.org> Message-Id: Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Subject: [6lowapp] Fwd: New Version Notification for draft-shelby-core-coap-req-00 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2010 15:24:43 -0000 Hi, http://www.ietf.org/id/draft-shelby-core-coap-req-00.txt I updated draft-shelby-6lowapp-core-00 with all the comments = (hopefully!) from the list, and renamed it to match the new CoRE WG and = a more descriptive title. This now should be in alignment with the = latest charter proposal, and the thoughts on the mailing list. If there = are sufficient comments, I'm happy to spin another version before the = Anaheim deadline. We'll now be working on an initial CoAP protocol specification draft = before the -00 submission deadline, at least a very initial version, to = discuss in Anaheim. So any input/ideas on protocol design welcome on the = list also a-priori as the cutoff is Mar 1st already!=20 Regards, Zach Begin forwarded message: > From: IETF I-D Submission Tool > Date: February 18, 2010 17:20:28 GMT+02:00 > To: zach@sensinode.com > Cc: = Michael.Stuber@itron.com,d.sturek@att.net,brian.tridium@gmail.com,richard.= kelsey@ember.com > Subject: New Version Notification for draft-shelby-core-coap-req-00=20 >=20 >=20 > A new version of I-D, draft-shelby-core-coap-req-00.txt has been = successfuly submitted by Zach Shelby and posted to the IETF repository. >=20 > Filename: draft-shelby-core-coap-req > Revision: 00 > Title: CoAP Requirements and Features > Creation_date: 2010-02-18 > WG ID: Independent Submission > Number_of_pages: 18 >=20 > Abstract: > This document considers the requirements and resulting features > needed for the design of the Constrained Application Protocol (CoAP). > Starting from requirements for energy and building automation > applications, the basic features are identified along with an > analysis of possible realizations. The goal of the document is to > provide a basis for protocol design and related discussion. >=20 >=20 >=20 > The IETF Secretariat. >=20 >=20 --=20 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.=20 From fluffy@cisco.com Thu Feb 18 12:53:29 2010 Return-Path: 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 AB6F53A7EEE for <6lowapp@core3.amsl.com>; Thu, 18 Feb 2010 12:53:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.459 X-Spam-Level: X-Spam-Status: No, score=-110.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 ENnfL9-25707 for <6lowapp@core3.amsl.com>; Thu, 18 Feb 2010 12:53:28 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id BE9033A7FE9 for <6lowapp@ietf.org>; Thu, 18 Feb 2010 12:53:28 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArINALc3fUurR7H+/2dsb2JhbACTQodGdKVAmAOEZwSDFQ X-IronPort-AV: E=Sophos;i="4.49,499,1262563200"; d="scan'208";a="485139705" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 18 Feb 2010 20:55:12 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o1IKtCLU022266 for <6lowapp@ietf.org>; Thu, 18 Feb 2010 20:55:12 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Impp: xmpp:cullenfluffyjennings@jabber.org Date: Thu, 18 Feb 2010 13:55:11 -0700 Message-Id: <6CAAB166-03D7-4D72-940B-C9BFB62A66A9@cisco.com> To: 6lowapp@ietf.org Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Subject: [6lowapp] Update on chartering progress 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2010 20:53:29 -0000 Just as FYI the IESG approved the charter to go out for IESG review so = next week some time it should go out for IETF LC. Cullen Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From jvasseur@cisco.com Fri Feb 19 02:38:44 2010 Return-Path: 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 00B3B3A8129 for <6lowapp@core3.amsl.com>; Fri, 19 Feb 2010 02:38:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.635 X-Spam-Level: X-Spam-Status: No, score=-9.635 tagged_above=-999 required=5 tests=[AWL=0.964, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 q7b9cm0rfhBe for <6lowapp@core3.amsl.com>; Fri, 19 Feb 2010 02:38:43 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 1FEAE3A8128 for <6lowapp@ietf.org>; Fri, 19 Feb 2010 02:38:43 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAE/5fUtAZnwM/2dsb2JhbACbB3SkQJd7hGcE X-IronPort-AV: E=Sophos;i="4.49,502,1262563200"; d="scan'208";a="241097374" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by sj-iport-2.cisco.com with ESMTP; 19 Feb 2010 10:40:28 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o1JAeRo5026324 for <6lowapp@ietf.org>; Fri, 19 Feb 2010 10:40:28 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Feb 2010 11:40:23 +0100 Received: from ams-jvasseur-8714.cisco.com ([10.55.201.133]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Feb 2010 11:40:23 +0100 Message-Id: From: JP Vasseur To: Cullen Jennings In-Reply-To: <6CAAB166-03D7-4D72-940B-C9BFB62A66A9@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 19 Feb 2010 11:40:22 +0100 References: <6CAAB166-03D7-4D72-940B-C9BFB62A66A9@cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 19 Feb 2010 10:40:23.0300 (UTC) FILETIME=[F0BE0C40:01CAB14F] Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Update on chartering progress 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 10:38:44 -0000 Excellent news ! Thanks. JP. On Feb 18, 2010, at 9:55 PM, Cullen Jennings wrote: > > Just as FYI the IESG approved the charter to go out for IESG review > so next week some time it should go out for IETF LC. > > > Cullen > > > > > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp From zach@sensinode.com Mon Feb 22 03:54:23 2010 Return-Path: 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 3686F28C1BA for <6lowapp@core3.amsl.com>; Mon, 22 Feb 2010 03:54:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.532 X-Spam-Level: X-Spam-Status: No, score=-3.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 hF0Gr53n89pd for <6lowapp@core3.amsl.com>; Mon, 22 Feb 2010 03:54:22 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id D291C28C1C2 for <6lowapp@ietf.org>; Mon, 22 Feb 2010 03:54:21 -0800 (PST) Received: from [62.145.172.51] ([62.145.172.51]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o1MBuDPN005176 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <6lowapp@ietf.org>; Mon, 22 Feb 2010 13:56:15 +0200 From: Zach Shelby Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 22 Feb 2010 13:56:15 +0200 Message-Id: <353C9E09-4294-48A3-9E23-1BACE59D3CE0@sensinode.com> To: 6LoWAPP <6lowapp@ietf.org> Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Subject: [6lowapp] Agenda in Anaheim 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2010 11:54:23 -0000 Hi, Just a heads up. On the preliminary agenda 6lowapp (or CoRE after the WG = is approved) got a time slot on Thursday morning (final agenda on Feb = 26th). Let's hope this will be our first official WG meeting of CoRE ;-)=20= THURSDAY, March 25, 2010 Pacific AB 0900-1130 Morning Session I California C APP 6lowapp = Application Protocols for Low-power V6 Networks BOF Hey chairs, I would like to request a time-slot for CoAP of about 45 = minutes including discussion (to cover 2 drafts). =20 Zach --=20 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.=20 From cabo@tzi.org Mon Feb 22 06:08:57 2010 Return-Path: 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 E54B228C1D7 for <6lowapp@core3.amsl.com>; Mon, 22 Feb 2010 06:08:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] 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 TRoNSaQSnQV0 for <6lowapp@core3.amsl.com>; Mon, 22 Feb 2010 06:08:57 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id BB30028C136 for <6lowapp@ietf.org>; Mon, 22 Feb 2010 06:08:52 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o1MEAh1Y004184 for <6lowapp@ietf.org>; Mon, 22 Feb 2010 15:10:43 +0100 (CET) Received: from [134.102.2.131] (unknown [134.102.2.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 26E9DE6A0; Mon, 22 Feb 2010 15:10:43 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: <353C9E09-4294-48A3-9E23-1BACE59D3CE0@sensinode.com> Date: Mon, 22 Feb 2010 15:10:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <389E6F46-C901-4FFC-A7F7-4E84812277CE@tzi.org> References: <353C9E09-4294-48A3-9E23-1BACE59D3CE0@sensinode.com> To: 6LoWAPP <6lowapp@ietf.org> X-Mailer: Apple Mail (2.1077) Subject: Re: [6lowapp] Agenda in Anaheim 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2010 14:08:58 -0000 On Feb 22, 2010, at 12:56, Zach Shelby wrote: > time slot on Thursday morning (final agenda on Feb 26th). Just to be painfully, redundantly clear here: The slot we have right now could move around any time up to (and = actually, with less likelihood, even after) the final IETF agenda. = Don't plan your travel based on this information (and you would be = missing 6lowpan and roll, currently planned for Monday). 6lowapp is scheduled as a BOF, but it is still possible that the WG will = be created before Anaheim, so this will then be a WG meeting. This = depends on the feedback we get during the impending IETF community = review of the WG and its charter. I would like to take the opportunity to ask for other agenda items/time = slots people want to have. Please send your requests this week. = Requests should point to Internet-Drafts already submitted or to be = submitted (see below). I'd also like to point out the following cut-offs: =95 2010-03-01 (Monday): Internet Draft Cut-off for initial document = (-00) submission by 17:00 PST. =95 2010-03-08 (Monday): Internet Draft final submission cut-off by = 17:00 PST. So if you are writing a new draft now, that is due next Monday, while = updated versions of existing drafts could wait till Monday 8th (but = don't have to!). Gruesse, Carsten From scholza@in.tum.de Wed Feb 24 07:07:21 2010 Return-Path: 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 C6C553A82F0 for <6lowapp@core3.amsl.com>; Wed, 24 Feb 2010 07:07:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 De3imAC7Z9rO for <6lowapp@core3.amsl.com>; Wed, 24 Feb 2010 07:07:20 -0800 (PST) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id B3F9A3A6CA1 for <6lowapp@ietf.org>; Wed, 24 Feb 2010 07:07:17 -0800 (PST) Received: from [131.159.16.116] (notekemper16.informatik.tu-muenchen.de [131.159.16.116]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.in.tum.de (Postfix) with ESMTP id A5981DAA1 for <6lowapp@ietf.org>; Wed, 24 Feb 2010 16:09:22 +0100 (CET) Message-ID: <4B854118.2060904@in.tum.de> Date: Wed, 24 Feb 2010 16:09:12 +0100 From: Andreas Scholz User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: 6lowapp@ietf.org References: <20100218152028.9453E28C0E8@core3.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [6lowapp] Fwd: New Version Notification for draft-shelby-core-coap-req-00 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 15:07:21 -0000 Hi Zach, I have an input w.r.t. the performance/message size issues outlined in the draft. I think one has to distinguish between two kinds of interactions in a constrained network: subscription based interactions and ad-hoc interactions. In the (building) automation scenarios I can think of, ad-hoc interactions occur only very rarely. Instead most of the network messages stem from the control applications, which use dedicated communication partners. A good way to decrease the message overhead is to support these subscription based interactions as efficient as possible. The idea used by EXI to reduce the size of messages is to exploit common knowledge on both ends of the communication channel. If both partners have agreed upon a message scheme, defined as XML Schema document, all the information contained in the schema can be omitted during transmission. I think a similar approach can be used to support the efficient transmission of subscription based messages. When a subscriber and a remote endpoint set up a subscription, a lot of the information contained in a typical message header will already be defined in the subscription. The content type of incoming messages, the encoding type, even the source and target endpoint are all known from the subscription. By applying the technique used in EXI to the protocol header, all these fields could be replaced by a single subscription identifier. On the client side this information can be reconstructed (if needed) based on the subscription definition. An interesting property of this mechanism is, that the information regarding encoding, content-type etc is only transmitted when the subscription is established. A "verbose" format is therefore not a big problem. Of course this mechanism is not applicable for ad-hoc requests. The question is how frequent these ad-hoc interactions are and how much effort should be invested to reduce the message size of ad-hoc requests and responses. Of course the application protocol should still be efficient. But given a mechanism like the one mentioned above, the question is how much flexibility should be traded for performance if the actual savings influence only a small part of the transmitted messages. Anyway, I think a header format that allows omitting information that is known a priori (e.g. from a subscription) is a promising approach for reducing message overheads. Best regards Andreas Zach Shelby schrieb: > Hi, > > http://www.ietf.org/id/draft-shelby-core-coap-req-00.txt > > I updated draft-shelby-6lowapp-core-00 with all the comments (hopefully!) from the list, and renamed it to match the new CoRE WG and a more descriptive title. This now should be in alignment with the latest charter proposal, and the thoughts on the mailing list. If there are sufficient comments, I'm happy to spin another version before the Anaheim deadline. > > We'll now be working on an initial CoAP protocol specification draft before the -00 submission deadline, at least a very initial version, to discuss in Anaheim. So any input/ideas on protocol design welcome on the list also a-priori as the cutoff is Mar 1st already! > > Regards, > Zach > > Begin forwarded message: > > >> From: IETF I-D Submission Tool >> Date: February 18, 2010 17:20:28 GMT+02:00 >> To: zach@sensinode.com >> Cc: Michael.Stuber@itron.com,d.sturek@att.net,brian.tridium@gmail.com,richard.kelsey@ember.com >> Subject: New Version Notification for draft-shelby-core-coap-req-00 >> >> >> A new version of I-D, draft-shelby-core-coap-req-00.txt has been successfuly submitted by Zach Shelby and posted to the IETF repository. >> >> Filename: draft-shelby-core-coap-req >> Revision: 00 >> Title: CoAP Requirements and Features >> Creation_date: 2010-02-18 >> WG ID: Independent Submission >> Number_of_pages: 18 >> >> Abstract: >> This document considers the requirements and resulting features >> needed for the design of the Constrained Application Protocol (CoAP). >> Starting from requirements for energy and building automation >> applications, the basic features are identified along with an >> analysis of possible realizations. The goal of the document is to >> provide a basis for protocol design and related discussion. >> >> >> >> The IETF Secretariat. >> >> >> > > -- Andreas Scholz Lehrstuhl Informatik III Tel. +49 89 289-17292 TU München, Zimmer 02.11.037 FMI andreas.scholz@in.tum.de Boltzmannstr. 3, 85748 Garching From charles.palmer@onzo.com Thu Feb 25 15:32:07 2010 Return-Path: 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 BE65828C492 for <6lowapp@core3.amsl.com>; Thu, 25 Feb 2010 15:32:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 tIduUXcpg8tL for <6lowapp@core3.amsl.com>; Thu, 25 Feb 2010 15:32:06 -0800 (PST) Received: from service38.mimecast.com (service38.mimecast.com [212.2.3.166]) by core3.amsl.com (Postfix) with SMTP id EAAA528C1FD for <6lowapp@ietf.org>; Thu, 25 Feb 2010 15:32:02 -0800 (PST) Received: from onzosbs2k3.ONZO.local (217.138.5.2 [217.138.5.2]) by service38.mimecast.com; Thu, 25 Feb 2010 23:34:13 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 25 Feb 2010 23:34:05 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowapp] Fwd: New Version Notificationfordraft-shelby-core-coap-req-00 Thread-Index: Acq2cwTbs+BWKC4+QPKnjy7IJX7HUA== References: <20100218152028.9453E28C0E8@core3.amsl.com> <4B854118.2060904@in.tum.de> From: "Charles Palmer" To: "Andreas Scholz" , <6lowapp@ietf.org> X-MC-Unique: 110022523341300202 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [6lowapp] Fwd: New Version Notificationfordraft-shelby-core-coap-req-00 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 23:32:07 -0000 Dear 6lowapp team Andreas suggests that knowledge shared by both parties can allow much reduced message sizes: "I think a header format that allows omitting information that is known a priori (e.g. from a subscription) is a promising approach for reducing message overheads." Has anyone looked at the approach adopted by the IEEE 11073 standards for exchange of messages between Personal Health Devices and their "Managers"? This transport-agnostic set of standards is designed to connect a wide variety of wireless personal health devices and assisted living devices - so far using Bluetooth and ZigBee but (who knows) maybe 6lowpan in the future. When I have time I will finish this Wikipedia introduction article: http://en.wikipedia.org/wiki/User:Acutetech/ISO/IEEE_11073_Personal_Heal th_Data_%28PHD%29_Devices IMHO the IEEE 11073 standards for Personal Health Devices could easily be generalised to support any class of M2M device. The IEEE 11073-20601 standard uses several techniques to reduce message size, and to simplify "discovery" - these might be worth considering for 6lowapp. (The terminology is different but the problems are the same). Two techniques are: 1=09A personal health device ("Agent" in IEEE11073 parlance) may either implement one or more standard configurations, or may implement an extended (custom) configuration. When an Agent first associates with a PC, smart phone etc ("Manager" in IEEE 11073 parlance) it states its configuration code. Usually the Manager will already have knowledge of the object model of Agents with this configuration code - either because it was given this knowledge at birth, or because it has previously associated with this Agent and has already learnt its object model. If the Manager does not have knowledge of this configuration it asks the Agent to describe its characteristics (by listing its objects). The use of standard configurations, and the exchange of object models when an Agent with a new configuration appears for the first time, significantly reduces the exchange of data required when an Agent associates with a Manager. 2=09During this configuration phase the Agent and Manager also agree one or more "attribute-value-maps". These pre-define the format of subsequent data exchanges. The standard says this: "The fixed format event report is optimized by defining the message format in the Attribute-Value-Map of the object in a previous configuration message before transfer commences. When an agent transmits data in a fixed format event report, it shall report the object handle and the attribute values in the same order and size as specified in the Attribute-Value-Map. In this way, the overhead of sending attribute identification and length in each event report is avoided. On receipt of a fixed format event report, the manager uses the object handle to retrieve the Attribute-Value-Map previously given at configuration time to know how to extract the data." Also - I don't know if it is too late to suggest that 6lowapp reconsiders the merits of ASN.1 rather than EXI. IEEE 11073 has adopted ASN.1 to encode messages for transmission. This allows for very simple "canned" messages from constrained devices, in which the variable data is inserted at defined offsets into fixed-format ASN.1 binary message strings. ASN.1 is also used by DLMS - one of the smart meter standards. A challenge: write practical implementations of EXI and ASN.1 encoding and decoding routines in C, then compare the size and complexity of the code, and of the message strings.=20 Regards - Charles Palmer=20 Onzo Limited (Project Hydra Project Manager)=20 Woodthorpe, Calver Road, Baslow, Derbyshire, DE45 1RR, United Kingdom=20 Ph: +44 (0)1246 582 220, Mob: +44 (0)7977 577 627=20 Email: charles.palmer@onzo.com Skype: Acutetech -------------------------------- Onzo is a limited company number 06097997 registered in England & Wales. Th= e =20 registered office is 6 Great Newport Street, London, WC2H 7JB, United Kingd= om. This email message may contain confidential and/or privileged information, = and is intended solely for the addressee(s). If you have received this email in= =20 error, please notify Onzo immediately. Unauthorised copying, disclosure or= =20 distribution of the material in this email is forbidden. -------------------------------- From adam@sics.se Fri Feb 26 07:48:03 2010 Return-Path: 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 1983C3A8695; Fri, 26 Feb 2010 07:48:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.416 X-Spam-Level: X-Spam-Status: No, score=-2.416 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, HELO_EQ_SE=0.35] 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 dNYdt1K0zhOv; Fri, 26 Feb 2010 07:48:02 -0800 (PST) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id 621283A840C; Fri, 26 Feb 2010 07:48:01 -0800 (PST) Received: from [10.1.1.153] (unknown [10.1.1.153]) by letter.sics.se (Postfix) with ESMTPS id 27F8740356; Fri, 26 Feb 2010 16:50:15 +0100 (CET) Message-ID: <4B87EDB5.6070906@sics.se> Date: Fri, 26 Feb 2010 16:50:13 +0100 From: Adam Dunkels User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: ROLL WG , 6lowpan <6lowpan@ietf.org>, 6lowapp@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: [6lowapp] ACM HotEmNets 2010 - only a few days left! 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 15:48:03 -0000 There are only a few days left to submit papers to ACM HotEmNets! Paper deadline is Monday, March 1 2010. Papers are 5 pages, double-column format. All submissions will be peer reviewed by the program committee. Accepted papers will be published in the ACM digital library. Paper submission is now open: https://www.easychair.org/login.cgi?conf=hotemnets2010 HotEMNETS 2010 - 6th Workshop on Hot Topics in Embedded Networked Sensors http://www.hotemnets2010.org/ The Sixth Workshop on Hot Topics in Embedded Networked Sensors (HotEmNets 2010) brings together wireless sensor network researchers from academic and industrial backgrounds to present groundbreaking results that will shed light on present and future research challenges. The workshop emphasizes results from experiments or deployments that quantify the challenges in the wireless sensor systems of today as well as early results from new ideas that introduce promising approaches that will define the challenges in the wireless sensor systems of tomorrow. We especially welcome papers reporting on results that refute common assumptions, deployment experiences, novel and original approaches, and, more generally, papers that will help inform and guide research. Topics of interest include, but are not limited to: * Validation/refutation of prior results * Applications beyond data collection * Application experiences: measurements, lessons learned * Future applications: requirements and challenges * Integration of sensor networks and IP networks * Hardware platforms, tradeoffs, and trends * Data and network storage * Delay-tolerant networking * Management, debugging, and troubleshooting * Network and software reliability * Network and system architectures * Software bug detection and tools * Energy sources, scavenging, and low-power operation * Human-Computer interfaces for sensor nets Important Dates DEADLINE EXTENDED: March 1, 2010 Notification: April 15, 2010 Camera Ready: May 10, 2010 Conference: June 28-29, 2010 Workshop Venue Killarney, Ireland General Chair: Dirk Pesch, Cork Institute of Technology Program Co-Chairs: Adam Dunkels, SICS Akos Ledeczi, Vanderbilt University Publications Chair: Antonio Ruzzelli, University College Dublin TPC: Philippe Bonnet, IT University of Copenhagen, Denmark Niru Bulusu, Portland State University, USA Prabal Dutta, University of Michigan, USA Mary Ann Ingram, Georgia Tech, USA Utz Rödig, Lancaster University, UK Kay Römer, University of Lübeck, Germany Janos Sallai, Vanderbilt University, USA Andreas Terzis, Johns Hopkins University, USA Roberto Verdone, University of Bologna, Italy Kamin Whitehouse, University of Virginia, USA Feng Zhao, Microsoft Research, China Steering Committee: Sanjay Jha (chair), UNSW Cormac Sreenan, Uni. College Cork John Heidemann, USC/ISI Andrew Campbell, Dartmouth College Nirupama Bulusu, PSU -- Adam Dunkels | +46 70 7731614 | http://www.sics.se/~adam/ Book: Interconnecting Smart Objects with IP - http://TheNextInternet.org From zach@sensinode.com Fri Feb 26 09:54:40 2010 Return-Path: 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 9F42428C2CA for <6lowapp@core3.amsl.com>; Fri, 26 Feb 2010 09:54:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.442 X-Spam-Level: X-Spam-Status: No, score=-3.442 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_LOW=-1] 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 TJoSjPEH5Ee0 for <6lowapp@core3.amsl.com>; Fri, 26 Feb 2010 09:54:39 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 08BFB28C22B for <6lowapp@ietf.org>; Fri, 26 Feb 2010 09:54:38 -0800 (PST) Received: from [192.168.1.3] (line-6490.dyn.kponet.fi [85.29.71.178]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o1QHuTPw025130 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 26 Feb 2010 19:56:49 +0200 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: Zach Shelby In-Reply-To: <4B854118.2060904@in.tum.de> Date: Fri, 26 Feb 2010 15:30:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100218152028.9453E28C0E8@core3.amsl.com> <4B854118.2060904@in.tum.de> To: Andreas Scholz X-Mailer: Apple Mail (2.1077) Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Fwd: New Version Notification for draft-shelby-core-coap-req-00 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 17:54:40 -0000 Hi Andreas, On Feb 24, 2010, at 17:09 , Andreas Scholz wrote: > Hi Zach, >=20 > I have an input w.r.t. the performance/message size issues outlined in = the draft. >=20 > I think one has to distinguish between two kinds of interactions in a = constrained network: subscription based interactions and ad-hoc = interactions. In the (building) automation scenarios I can think of, = ad-hoc interactions occur only very rarely. Instead most of the network = messages stem from the control applications, which use dedicated = communication partners. A good way to decrease the message overhead is = to support these subscription based interactions as efficient as = possible. I am not sure I understand the difference between these types of = interactions. I agree that most interactions in the scenarios that I = work with tend to be "subscription based". >=20 > The idea used by EXI to reduce the size of messages is to exploit = common knowledge on both ends of the communication channel. If both = partners have agreed upon a message scheme, defined as XML Schema = document, all the information contained in the schema can be omitted = during transmission. I think a similar approach can be used to support = the efficient transmission of subscription based messages. When a = subscriber and a remote endpoint set up a subscription, a lot of the = information contained in a typical message header will already be = defined in the subscription. The content type of incoming messages, the = encoding type, even the source and target endpoint are all known from = the subscription. By applying the technique used in EXI to the protocol = header, all these fields could be replaced by a single subscription = identifier. On the client side this information can be reconstructed (if = needed) based on the subscription definition. An interesting property of = this mechanism is, that the information regarding encoding, content-type = etc is only transmitted when the subscription is established. A = "verbose" format is therefore not a big problem. I see where you are going. In addition to the state setup when making a = subscription, the resource discovery feature also offers some = out-of-band information. For example, we can assign an 8-bit integer to = each URL to avoid sending string URLs.=20 Now when doing this, we must be careful not to break e.g. caching by an = intermediate. In the case of a cache, it would be a good idea to include = enough information in the notification sent as a result of subscriptions = so that it can refresh the cached resource. If the notification would = just include a subscription ID, that requires the cache to also store = that state. Is that a problem? >=20 > Of course this mechanism is not applicable for ad-hoc requests. The = question is how frequent these ad-hoc interactions are and how much = effort should be invested to reduce the message size of ad-hoc requests = and responses. Of course the application protocol should still be = efficient. But given a mechanism like the one mentioned above, the = question is how much flexibility should be traded for performance if the = actual savings influence only a small part of the transmitted messages. By ad-hoc I think you are referring to a Req/Res style READ or WRITE = message using CoAP? In that case you are right, there isn't a = subscription setup. As I mentioned above, even in that case we can = encode the URL as an integer.=20 >=20 > Anyway, I think a header format that allows omitting information that = is known a priori (e.g. from a subscription) is a promising approach for = reducing message overheads. Agreed. Let's see what we can get into the first draft of CoAP which I'm = trying to finish for the March 1st deadline. Thanks, Zach >=20 >=20 > Best regards >=20 > Andreas >=20 >=20 > Zach Shelby schrieb: >> Hi, >>=20 >> http://www.ietf.org/id/draft-shelby-core-coap-req-00.txt >>=20 >> I updated draft-shelby-6lowapp-core-00 with all the comments = (hopefully!) from the list, and renamed it to match the new CoRE WG and = a more descriptive title. This now should be in alignment with the = latest charter proposal, and the thoughts on the mailing list. If there = are sufficient comments, I'm happy to spin another version before the = Anaheim deadline. >>=20 >> We'll now be working on an initial CoAP protocol specification draft = before the -00 submission deadline, at least a very initial version, to = discuss in Anaheim. So any input/ideas on protocol design welcome on the = list also a-priori as the cutoff is Mar 1st already!=20 >> Regards, >> Zach >>=20 >> Begin forwarded message: >>=20 >> =20 >>> From: IETF I-D Submission Tool >>> Date: February 18, 2010 17:20:28 GMT+02:00 >>> To: zach@sensinode.com >>> Cc: = Michael.Stuber@itron.com,d.sturek@att.net,brian.tridium@gmail.com,richard.= kelsey@ember.com >>> Subject: New Version Notification for draft-shelby-core-coap-req-00=20= >>>=20 >>> A new version of I-D, draft-shelby-core-coap-req-00.txt has been = successfuly submitted by Zach Shelby and posted to the IETF repository. >>>=20 >>> Filename: draft-shelby-core-coap-req >>> Revision: 00 >>> Title: CoAP Requirements and Features >>> Creation_date: 2010-02-18 >>> WG ID: Independent Submission >>> Number_of_pages: 18 >>>=20 >>> Abstract: >>> This document considers the requirements and resulting features >>> needed for the design of the Constrained Application Protocol = (CoAP). >>> Starting from requirements for energy and building automation >>> applications, the basic features are identified along with an >>> analysis of possible realizations. The goal of the document is to >>> provide a basis for protocol design and related discussion. >>>=20 >>>=20 >>>=20 >>> The IETF Secretariat. >>>=20 >>>=20 >>> =20 >>=20 >> =20 >=20 > --=20 > Andreas Scholz Lehrstuhl Informatik III > Tel. +49 89 289-17292 TU M=FCnchen, Zimmer 02.11.037 FMI > andreas.scholz@in.tum.de Boltzmannstr. 3, 85748 Garching >=20 > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp --=20 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.=20