From jvasseur@cisco.com Wed Jan 6 05:23:41 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 D04D53A68D1; Wed, 6 Jan 2010 05:23:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 Y81dMfd4uHlw; Wed, 6 Jan 2010 05:23:41 -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 D042B3A685E; Wed, 6 Jan 2010 05:23:39 -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: ApoEAEcdREtAZnwN/2dsb2JhbAC+TJNahDAE X-IronPort-AV: E=Sophos;i="4.49,229,1262563200"; d="scan'208";a="78629929" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 06 Jan 2010 13:23:38 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o06DNbrk004315; Wed, 6 Jan 2010 13:23:37 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Jan 2010 14:23:37 +0100 Received: from dhcp-lyon-144-254-54-120.cisco.com ([144.254.54.120]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Jan 2010 14:23:36 +0100 Message-Id: <5B8E5879-683D-448F-9DD1-4278B7047B38@cisco.com> From: JP Vasseur To: Jon Smirl In-Reply-To: <9e4733910912300911m513f7826uc29d2b6e2abc132e@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 6 Jan 2010 12:39:27 +0100 References: <9e4733910912300911m513f7826uc29d2b6e2abc132e@mail.gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 06 Jan 2010 13:23:36.0767 (UTC) FILETIME=[73ED84F0:01CA8ED3] Cc: ROLL WG , 6lowapp@ietf.org Subject: Re: [6lowapp] Reference implementation 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, 06 Jan 2010 13:23:41 -0000 Hi, On Dec 30, 2009, at 6:11 PM, Jon Smirl wrote: > What are the plans for a 6lowapp reference implementation? > > For example there is a 6lowpan implementation in Contiki, but nobody > is updating it to track the current proposals. > Does a ROLL reference implementation exist? The IETF does not produce "reference implementation" but protocol specifications and applicability statement. For ROLL we have plans to work on such documents that will provide guidance on how to use RPL in different environments. Is this what you had in mind ? Thanks. JP. > > -- > Jon Smirl > jonsmirl@gmail.com > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp From jonsmirl@gmail.com Wed Jan 6 07:44: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 25AA63A67AE; Wed, 6 Jan 2010 07:44:06 -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 3DAgqJT1ShFF; Wed, 6 Jan 2010 07:44:05 -0800 (PST) Received: from mail-px0-f186.google.com (mail-px0-f186.google.com [209.85.216.186]) by core3.amsl.com (Postfix) with ESMTP id 627363A63C9; Wed, 6 Jan 2010 07:44:05 -0800 (PST) Received: by pxi16 with SMTP id 16so3504776pxi.29 for ; Wed, 06 Jan 2010 07:44:01 -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; bh=oxJZtZFczbZToM33sCY6MPOoqca0fcKx9WpyHptm65c=; b=qhNhEcImm67LRLtOcGVz0B9O555bd1+9DYYhN+7qQbJuxutTHuHOmA2/NTIFh56Vmg STA23l1yIF55dp99ypcItK9zD5PV39w0eI3xGdp1iExlrC55ImmLpyaHnv1QyhrPaS1h hcCdvuFTb467Aocs88G8p5mST+pQPKLcUgkt4= 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; b=UNYbawvpaGhEUUyl2HIskjutDnCGLizIh2AYeJn5t99x4ZEV+MflqYwOotkL5EYgCV 7KITxPseREavYmO2qjS54HlizBH6UoA61aXEYdJtOxNa6/nmrYdLf/hlasXWr7PN1GqU fZA62VkTpNPSNk3blSRuaJdVMbG+g5MaXG/rg= MIME-Version: 1.0 Received: by 10.143.20.39 with SMTP id x39mr16513020wfi.213.1262792641431; Wed, 06 Jan 2010 07:44:01 -0800 (PST) In-Reply-To: <5B8E5879-683D-448F-9DD1-4278B7047B38@cisco.com> References: <9e4733910912300911m513f7826uc29d2b6e2abc132e@mail.gmail.com> <5B8E5879-683D-448F-9DD1-4278B7047B38@cisco.com> Date: Wed, 6 Jan 2010 10:44:01 -0500 Message-ID: <9e4733911001060744p2c9cd27bm473eafb775fcbf39@mail.gmail.com> From: Jon Smirl To: JP Vasseur Content-Type: text/plain; charset=ISO-8859-1 Cc: ROLL WG , 6lowapp@ietf.org Subject: Re: [6lowapp] Reference implementation 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, 06 Jan 2010 15:44:06 -0000 On Wed, Jan 6, 2010 at 6:39 AM, JP Vasseur wrote: > Hi, > > On Dec 30, 2009, at 6:11 PM, Jon Smirl wrote: > >> What are the plans for a 6lowapp reference implementation? >> >> For example there is a 6lowpan implementation in Contiki, but nobody >> is updating it to track the current proposals. >> Does a ROLL reference implementation exist? > > The IETF does not produce "reference implementation" but protocol > specifications and applicability statement. For ROLL we have plans to > work on such documents that will provide guidance on how to use > RPL in different environments. Is this what you had in mind ? Standards often have problem with specifying behavior in mainstream cases and leaving the corner cases ambiguous. Nobody knows about these corner case problems until some kind of interop event occurs. Another method for achieving conforming standards implementations is to produce an open source implementation of the spec that everyone can use and contribute to. Then all of the people with private implementations can test against the public one. Since the reference code base was produced as a joint effort from all people involved it becomes the arbiter for behavior in the corner cases. > > Thanks. > > JP. > >> >> -- >> Jon Smirl >> jonsmirl@gmail.com >> _______________________________________________ >> 6lowapp mailing list >> 6lowapp@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowapp > > -- Jon Smirl jonsmirl@gmail.com From jmamodio@gmail.com Wed Jan 6 08:19:19 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 CC5843A688C; Wed, 6 Jan 2010 08:19:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 6AJxXVa0O++B; Wed, 6 Jan 2010 08:19:19 -0800 (PST) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id B7E1F3A684F; Wed, 6 Jan 2010 08:19:18 -0800 (PST) Received: by pwi20 with SMTP id 20so12086095pwi.29 for ; Wed, 06 Jan 2010 08:19:12 -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; bh=vyAzoQIJ1WRt8mrXp+GIbWDy/4XxGpmUCRKeM23IQhI=; b=GVQMReC+kO6c0/ONKQXS5SZcos5go3Yu0lz4NXwys9uuPcESu683RamQ7slbeu+1tq ZRSizYqLVxN7v7Y9xy44pweO5JDAiAuoOxT3tpvYliX3eVnoE8KBiY6kJg+XVo0zukWP 7+kIdZ5PtS/2teLD3C4KyAj9BfGZK7rmSPgWg= 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; b=AEna4aAadhflj0+7orNtmZ9+CeyYRG1Wrdsv+KXSuxtLxsoCdZH+RqiB+AmPUEBvcT QGWrMqWdFXuPjKab3oJSH6Dxyw8me3ByzKLsVRM3ogLr7udBjcJxLiXtN1USl8skbNx3 hWQO7cnWyJ4bSih7w63B/c6wQvfEi99dnl6sc= MIME-Version: 1.0 Received: by 10.142.6.1 with SMTP id 1mr15435308wff.224.1262794752713; Wed, 06 Jan 2010 08:19:12 -0800 (PST) In-Reply-To: <5B8E5879-683D-448F-9DD1-4278B7047B38@cisco.com> References: <9e4733910912300911m513f7826uc29d2b6e2abc132e@mail.gmail.com> <5B8E5879-683D-448F-9DD1-4278B7047B38@cisco.com> Date: Wed, 6 Jan 2010 10:19:12 -0600 Message-ID: <202705b1001060819t3ef909a4sf86a405d6b996152@mail.gmail.com> From: Jorge Amodio To: JP Vasseur Content-Type: text/plain; charset=ISO-8859-1 Cc: ROLL WG , 6lowapp@ietf.org Subject: Re: [6lowapp] Reference implementation 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, 06 Jan 2010 16:19:19 -0000 >> What are the plans for a 6lowapp reference implementation? >> >> For example there is a 6lowpan implementation in Contiki, but nobody >> is updating it to track the current proposals. >> Does a ROLL reference implementation exist? > > The IETF does not produce "reference implementation" but protocol > specifications and applicability statement. For ROLL we have plans to > work on such documents that will provide guidance on how to use > RPL in different environments. Is this what you had in mind ? Yes you are right the IETF does not produce "reference implementation" but the original question I believe was not directed to the IETF but to the individuals interested in 6LoWPAN (I'm one among them) and as you probably know there is an old standing and still current mantra clearly expressed for years in the Tao of IETF (RFC4677): ""We reject kings, presidents and voting. We believe in rough consensus and running code" So no harm, and nothing wrong for somebody to ask for "running code" ... On the other hand, while the formal specification of a protocol can be expressed in a RFC, there is nothing better than pseudo-code or running code to clearly show how the protocol should be or must be implemented. My .02 Regards Jorge From jvasseur@cisco.com Wed Jan 6 10:14: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 449EB3A693A; Wed, 6 Jan 2010 10:14:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 WOCjcAzmYySU; Wed, 6 Jan 2010 10:14:30 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id B24763A6937; Wed, 6 Jan 2010 10:14:29 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEADliREtAZnwM/2dsb2JhbAC/DZNghDAE X-IronPort-AV: E=Sophos;i="4.49,230,1262563200"; d="scan'208";a="78583601" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 06 Jan 2010 18:14:27 +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 o06IEL9V011172; Wed, 6 Jan 2010 18:14:27 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); Wed, 6 Jan 2010 19:14:21 +0100 Received: from dhcp-lyon-144-254-54-120.cisco.com ([144.254.54.120]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Jan 2010 19:14:20 +0100 Message-Id: <21BFCBB5-1497-4FF9-9653-65170EE1D281@cisco.com> From: JP Vasseur To: Jorge Amodio In-Reply-To: <202705b1001060819t3ef909a4sf86a405d6b996152@mail.gmail.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: Wed, 6 Jan 2010 19:14:18 +0100 References: <9e4733910912300911m513f7826uc29d2b6e2abc132e@mail.gmail.com> <5B8E5879-683D-448F-9DD1-4278B7047B38@cisco.com> <202705b1001060819t3ef909a4sf86a405d6b996152@mail.gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 06 Jan 2010 18:14:20.0851 (UTC) FILETIME=[11698030:01CA8EFC] Cc: ROLL WG , 6lowapp@ietf.org Subject: Re: [6lowapp] Reference implementation 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, 06 Jan 2010 18:14:31 -0000 On Jan 6, 2010, at 5:19 PM, Jorge Amodio wrote: >>> What are the plans for a 6lowapp reference implementation? >>> >>> For example there is a 6lowpan implementation in Contiki, but nobody >>> is updating it to track the current proposals. >>> Does a ROLL reference implementation exist? >> >> The IETF does not produce "reference implementation" but protocol >> specifications and applicability statement. For ROLL we have plans to >> work on such documents that will provide guidance on how to use >> RPL in different environments. Is this what you had in mind ? > > Yes you are right the IETF does not produce "reference implementation" > but the original question I believe was not directed to the IETF but > to the individuals interested in 6LoWPAN (I'm one among them) and as > you probably know there is an old standing and still current mantra > clearly expressed for years in the Tao of IETF (RFC4677): > > ""We reject kings, presidents and voting. We believe in rough > consensus and running code" > > So no harm, and nothing wrong for somebody to ask for "running > code" ... Oh we're strongly agreeing here, I was trying to understand what you were requesting, that's all. > > On the other hand, while the formal specification of a protocol can be > expressed in a RFC, there is nothing better than pseudo-code or > running code to clearly show how the protocol should be or must be > implemented. But still ... could you tell us what you would like to get ? Thanks. JP. > > My .02 > Regards > Jorge From pal@cs.stanford.edu Wed Jan 6 12:49:05 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 4921E3A6938; Wed, 6 Jan 2010 12:49:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 fge+nti7eF0i; Wed, 6 Jan 2010 12:49:04 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 983EF3A689F; Wed, 6 Jan 2010 12:49:04 -0800 (PST) Received: from [76.14.71.8] (helo=[192.168.1.103]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1NScoQ-0004eS-UF; Wed, 06 Jan 2010 12:49:03 -0800 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <9e4733911001060744p2c9cd27bm473eafb775fcbf39@mail.gmail.com> Date: Wed, 6 Jan 2010 12:49:01 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <8A858A30-14AC-4F78-B1ED-4004328F831D@cs.stanford.edu> References: <9e4733910912300911m513f7826uc29d2b6e2abc132e@mail.gmail.com> <5B8E5879-683D-448F-9DD1-4278B7047B38@cisco.com> <9e4733911001060744p2c9cd27bm473eafb775fcbf39@mail.gmail.com> To: Jon Smirl X-Mailer: Apple Mail (2.1077) X-Scan-Signature: 3acef658708772c1d00935e7d4d752c5 X-Mailman-Approved-At: Wed, 06 Jan 2010 12:57:36 -0800 Cc: ROLL WG , 6lowapp@ietf.org Subject: Re: [6lowapp] [Roll] Reference implementation 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, 06 Jan 2010 20:49:05 -0000 On Jan 6, 2010, at 7:44 AM, Jon Smirl wrote: > On Wed, Jan 6, 2010 at 6:39 AM, JP Vasseur wrote: >> Hi, >>=20 >> On Dec 30, 2009, at 6:11 PM, Jon Smirl wrote: >>=20 >>> What are the plans for a 6lowapp reference implementation? >>>=20 >>> For example there is a 6lowpan implementation in Contiki, but nobody >>> is updating it to track the current proposals. >>> Does a ROLL reference implementation exist? >>=20 >> The IETF does not produce "reference implementation" but protocol >> specifications and applicability statement. For ROLL we have plans to >> work on such documents that will provide guidance on how to use >> RPL in different environments. Is this what you had in mind ? >=20 > Standards often have problem with specifying behavior in mainstream > cases and leaving the corner cases ambiguous. Nobody knows about these > corner case problems until some kind of interop event occurs. Another > method for achieving conforming standards implementations is to > produce an open source implementation of the spec that everyone can > use and contribute to. Then all of the people with private > implementations can test against the public one. Since the reference > code base was produced as a joint effort from all people involved it > becomes the arbiter for behavior in the corner cases. Well, that sounds like an excellent reason for you to go implement it! = :) There's an open-source implementation in TinyOS. It's currently behind = the drafts, but that's going to change in the next month or so. Phil= From jonsmirl@gmail.com Wed Jan 6 16:54:47 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 C368E3A6960; Wed, 6 Jan 2010 16:54:47 -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 Dghnu4rNlYdW; Wed, 6 Jan 2010 16:54:46 -0800 (PST) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id D9E173A695F; Wed, 6 Jan 2010 16:54:46 -0800 (PST) Received: by pwi20 with SMTP id 20so12464523pwi.29 for ; Wed, 06 Jan 2010 16:54:42 -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=NP9IT6Jv/mkp7coSlraYdfIIO/kOJWWZym43KhCsW0Y=; b=H53GNXOZV1nJSgsRhdCY0/kabRnkhFQD4WdUltKHcsLTzzKmcAWhDjfDvMcEzlbvsn BZTK3groFiaQ/BfKpkFmaYNEPo3Lk4bJU2vKfC6b07FmB4iI4fxwuHf66Bf9xRg7ybs8 gVkR9Et/NcxaiuoXGgy7aBGTS0uzRaWjke5aA= 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=VaU6nwCa1zlHCx4+m/d2ccSzcQnKv1iWWiHvr+3XSUeBDscpb9CqQ++z1HsAOdFXwb GbKXfZpob+aPjKKplixm2i8suDS62YdKR2HScY/bbTZdFEYYZftprJ9FjRavSke5HKgR JF0gLqAs2r1FWefadesdwBgTwaTXUWh8v9BOM= MIME-Version: 1.0 Received: by 10.143.20.37 with SMTP id x37mr3511618wfi.208.1262825682732; Wed, 06 Jan 2010 16:54:42 -0800 (PST) In-Reply-To: <8A858A30-14AC-4F78-B1ED-4004328F831D@cs.stanford.edu> References: <9e4733910912300911m513f7826uc29d2b6e2abc132e@mail.gmail.com> <5B8E5879-683D-448F-9DD1-4278B7047B38@cisco.com> <9e4733911001060744p2c9cd27bm473eafb775fcbf39@mail.gmail.com> <8A858A30-14AC-4F78-B1ED-4004328F831D@cs.stanford.edu> Date: Wed, 6 Jan 2010 19:54:42 -0500 Message-ID: <9e4733911001061654s5a11d327vd997062820999804@mail.gmail.com> From: Jon Smirl To: Philip Levis Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ROLL WG , 6lowapp@ietf.org Subject: Re: [6lowapp] [Roll] Reference implementation 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, 07 Jan 2010 00:54:47 -0000 On Wed, Jan 6, 2010 at 3:49 PM, Philip Levis wrote: > > On Jan 6, 2010, at 7:44 AM, Jon Smirl wrote: > >> On Wed, Jan 6, 2010 at 6:39 AM, JP Vasseur wrote: >>> Hi, >>> >>> On Dec 30, 2009, at 6:11 PM, Jon Smirl wrote: >>> >>>> What are the plans for a 6lowapp reference implementation? >>>> >>>> For example there is a 6lowpan implementation in Contiki, but nobody >>>> is updating it to track the current proposals. >>>> Does a ROLL reference implementation exist? >>> >>> The IETF does not produce "reference implementation" but protocol >>> specifications and applicability statement. For ROLL we have plans to >>> work on such documents that will provide guidance on how to use >>> RPL in different environments. Is this what you had in mind ? >> >> Standards often have problem with specifying behavior in mainstream >> cases and leaving the corner cases ambiguous. Nobody knows about these >> corner case problems until some kind of interop event occurs. =A0Another >> method for achieving conforming standards implementations is to >> produce an open source implementation of the spec that everyone can >> use and contribute to. =A0Then all of the people with private >> implementations can test against the public one. Since the reference >> code base was produced as a joint effort from all people involved it >> becomes the arbiter for behavior in the corner cases. > > Well, that sounds like an excellent reason for you to go implement it! :) I've already released open source support for IPv6 with 6lowpan on the mc13224. I have used it to implement a web server. It is based on the Atmel Raven support already in Contiki. I'm also working on serial support for the mc13224 to get it working with the internal Linux 802.15.4 implementation by Seimens. > > There's an open-source implementation in TinyOS. It's currently behind th= e drafts, but that's going to change in the next month or so. I'll check it out. Maybe I can move my mc13224 radio driver into TinyOS or pull the ROLL code into Contiki. Working together on BSD licensed code means everyone can pull it back into their proprietary products if they choose. The BSD code could also be pulled into the Linux kernel, but not the other way. > > Phil --=20 Jon Smirl jonsmirl@gmail.com From adam@sics.se Sat Jan 9 01:54: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 E6F623A6970; Sat, 9 Jan 2010 01:54:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.835 X-Spam-Level: X-Spam-Status: No, score=-3.835 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, GB_I_INVITATION=-2, GB_I_LETTER=-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 EMAUD-fCRwXG; Sat, 9 Jan 2010 01:54:57 -0800 (PST) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id B98373A67E4; Sat, 9 Jan 2010 01:54:57 -0800 (PST) Received: from [10.1.1.90] (unknown [10.1.1.90]) by letter.sics.se (Postfix) with ESMTPS id 831F140328; Sat, 9 Jan 2010 10:54:54 +0100 (CET) Message-ID: <4B485117.3090004@sics.se> Date: Sat, 09 Jan 2010 10:49:11 +0100 From: Adam Dunkels User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: 6lowapp@ietf.org, 6lowpan <6lowpan@ietf.org>, roll@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [6lowapp] CFP HotEmNets 2010 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, 09 Jan 2010 09:54:59 -0000 HotEMNETS 2010 6th Workshop on Hot Topics in Embedded Networked Sensors June 28-29, 2010 http://www.hotemnets2010.org/ Call for Papers Important Dates * Papers Due: February 22, 2010 * Notification: April 15, 2010 * Camera Ready: May 10, 2010 * Conference: June 28-29, 2010 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. HotEmNets 2010 will by invitation only. 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 Submission Guidelines: Papers should be submitted in Adobe PDF format. No longer than five pages in US letter or A4 paper size Two column formatting. One-inch margins on all sides. Minimum 10-point font size (smaller fonts are acceptable for footnotes, references, and figure captions). Organizing Committee 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 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 Colin.OFlynn@atmel.com Sat Jan 16 01:37:45 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 3282E3A68F8 for <6lowapp@core3.amsl.com>; Sat, 16 Jan 2010 01:37:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 jYJ5yGpP4G6G for <6lowapp@core3.amsl.com>; Sat, 16 Jan 2010 01:37:44 -0800 (PST) Received: from sjogate2.atmel.com (newsmtp5.atmel.com [204.2.163.5]) by core3.amsl.com (Postfix) with ESMTP id 0B52D3A67F3 for <6lowapp@ietf.org>; Sat, 16 Jan 2010 01:37:43 -0800 (PST) Received: from csomb01.corp.atmel.com ([10.95.30.150]) by sjogate2.atmel.com (8.13.6/8.13.6) with ESMTP id o0G9ZB5R014264; Sat, 16 Jan 2010 01:35:15 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA968F.6F58D4B8" Date: Sat, 16 Jan 2010 02:36:52 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed Charter Changes Thread-Index: AcqWjnxHirqjc1hIQNe5Jc07/HZBRQ== From: "Oflynn, Colin" To: "Carsten Bormann" , "Cullen Jennings" , "Zach Shelby" Cc: 6lowapp@ietf.org Subject: [6lowapp] Proposed Charter Changes 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, 16 Jan 2010 09:37:45 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA968F.6F58D4B8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, Zach and I have been working on charter updates, to support a new = I-Draft we have coming (next week hopefully). Essentially it is designed = to make the charter more flexible with respect to methods of configuring = the initial network. Also note we use the term 'security bootstrapping' as in = draft-struik-6lowapp-security-considerations. It was felt that = 'bootstrapping' is more in-line with the operating we are performing, = since it requires setting up a network without any prior communication = between nodes.=20 Suggest changes are removal of lines: -This WG will support three commissioning methodologies: ... Inclusive to ... -Modes 1 and 2 are mandatory to implement but mode 3 is optional. -In all modes, once Device A and Device B have formed a secure = connection=20 -with Device C, Device C can be used to transitively introduce A and B = so now=20 -A and B have a secure connection with C. This transitive trust = introduction=20 -can be used during commissioning even if A and B do not yet have = network=20 -connectivity to each other.=20 And addition of lines + The WG will work to support methods of security bootstrapping which = are=20 + realistic given the constraints and requirements of the network. These = + methods are not specific to any communication layer. Instead the = methods=20 + could run across any layer, including IP. Requirements considered = include: +=20 + 1) Suitable for use on resource constrained nodes. This includes = power,=20 + cost, size, and computational constraints. +=20 + 2) Capable of possessing sufficient security for the application = space. +=20 + 3) Realistically guarantee any two nodes can join together. This = includes=20 + nodes which are already on separate networks, but a user wishes to = have those + two networks merge together. +=20 + 4) Additional requirements for each application space, such as urban = or=20 + commercial environments which deploy large networks compared to = residential + environments. + + To ensure that any two nodes can join together, all nodes must = implement at + least one universal method. In additional several other methods will = be + specified which take advantage of the application space. In commercial + applications for instance bootstrapping can take advantage of the fact + that networks are typically managed from a central authority, and a = method + optimized for residential usage might take advantage of the fact that = nodes + are in close proximity. + + Methods which will be considered include: + + 1) Out of Band Key or Certificate. In this mode a key (either = symmetric or + asymmetric) is distributed with the product, such as a 2D barcode = printed on + the node. The user can scan this key with a computer and give access = to this + node. Typically might be found in industrial, commercial, or urban = environments + with a central authority. + + 2) Push Button Protocol. In this mode two nodes only require = pushbuttons and LEDs, + and the user simply pushes the button on each node. Due to the = simplicity this + might be found in home installations. + + 3) Out of Band Wireless Communication Link. This could include IrDA or = NFC + (Near Field Communication) type technologies. Due to the extra = hardware requirements + this may be found on higher performance nodes. However medical = applications may + make use of optical communication techniques due to other = requirements. + + 4) Out of Band Physical Communication Link. The simplest example of = this is the + programming interface which a node uses to download firmware. As all = nodes already + have this hardware present, this may be the simplest interface to = implement. + + This list should not be considered exhaustive, and methods may be = removed or added + as additional application spaces and requirements are found. The list = gives examples + of the types of methods to be investigated.=20 Any comments, suggestions, or questions would be appreciated. Regards, -Colin O'Flynn ------_=_NextPart_001_01CA968F.6F58D4B8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Proposed Charter Changes

Hello,

Zach and I have been working on charter updates, to support a new = I-Draft we have coming (next week hopefully). Essentially it is designed = to make the charter more flexible with respect to methods of configuring = the initial network.

Also note we use the term 'security bootstrapping' as in = draft-struik-6lowapp-security-considerations. It was felt that = 'bootstrapping' is more in-line with the operating we are performing, = since it requires setting up a network without any prior communication = between nodes.

Suggest changes are removal of lines:

-This WG will support three commissioning methodologies:
... Inclusive to ...
-Modes 1 and 2 are mandatory to implement but mode 3 is optional.
-In all modes, once Device A and Device B have formed a secure = connection
-with Device C, Device C can be used to transitively introduce A and B = so now
-A and B have a secure connection with C. This transitive trust = introduction
-can be used during commissioning even if A and B do not yet have = network
-connectivity to each other.

And addition of lines


+ The WG will work to support methods of security bootstrapping which = are
+ realistic given the constraints and requirements of the network. = These
+ methods are not specific to any communication layer. Instead the = methods
+ could run across any layer, including IP. Requirements considered = include:
+
+ 1) Suitable for use on resource constrained nodes. This includes = power,
+ cost, size, and computational constraints.
+
+ 2) Capable of possessing sufficient security for the application = space.
+
+ 3) Realistically guarantee any two nodes can join together. This = includes
+ nodes which are already on separate networks, but a user wishes to = have those
+ two networks merge together.
+
+ 4) Additional requirements for each application space, such as urban = or
+ commercial environments which deploy large networks compared to = residential
+ environments.
+
+ To ensure that any two nodes can join together, all nodes must = implement at
+ least one universal method. In additional several other methods will = be
+ specified which take advantage of the application space. In = commercial
+ applications for instance bootstrapping can take advantage of the = fact
+ that networks are typically managed from a central authority, and a = method
+ optimized for residential usage might take advantage of the fact that = nodes
+ are in close proximity.
+
+ Methods which will be considered include:
+
+ 1) Out of Band Key or Certificate. In this mode a key (either = symmetric or
+ asymmetric) is distributed with the product, such as a 2D barcode = printed on
+ the node. The user can scan this key with a computer and give access = to this
+ node. Typically might be found in industrial, commercial, or urban = environments
+ with a central authority.
+
+ 2) Push Button Protocol. In this mode two nodes only require = pushbuttons and LEDs,
+ and the user simply pushes the button on each node. Due to the = simplicity this
+ might be found in home installations.
+
+ 3) Out of Band Wireless Communication Link. This could include IrDA or = NFC
+ (Near Field Communication) type technologies. Due to the extra = hardware requirements
+ this may be found on higher performance nodes. However medical = applications may
+ make use of optical communication techniques due to other = requirements.
+
+ 4) Out of Band Physical Communication Link. The simplest example of = this is the
+ programming interface which a node uses to download firmware. As all = nodes already
+ have this hardware present, this may be the simplest interface to = implement.
+
+ This list should not be considered exhaustive, and methods may be = removed or added
+ as additional application spaces and requirements are found. The list = gives examples
+ of the types of methods to be investigated.

Any comments, suggestions, or questions would be appreciated.

Regards,

  -Colin O'Flynn

------_=_NextPart_001_01CA968F.6F58D4B8-- From jvasseur@cisco.com Sun Jan 17 01:25:56 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 7A3873A68F9 for <6lowapp@core3.amsl.com>; Sun, 17 Jan 2010 01:25:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.887 X-Spam-Level: X-Spam-Status: No, score=-9.887 tagged_above=-999 required=5 tests=[AWL=0.711, 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 uvsj8pUHtK4Q for <6lowapp@core3.amsl.com>; Sun, 17 Jan 2010 01:25:55 -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 2F5973A680A for <6lowapp@ietf.org>; Sun, 17 Jan 2010 01:25:55 -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: ApoEADpmUkutJV2Y/2dsb2JhbADAYJNhhDIE X-IronPort-AV: E=Sophos;i="4.49,291,1262563200"; d="scan'208,217";a="468222949" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by sj-iport-6.cisco.com with ESMTP; 17 Jan 2010 09:25:51 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id o0H9PoK9012198; Sun, 17 Jan 2010 09:25:51 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); Sun, 17 Jan 2010 10:25:50 +0100 Received: from ams-jvasseur-8714.cisco.com ([10.55.201.133]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 17 Jan 2010 10:25:49 +0100 Message-Id: <39A9217F-9F8A-4DA6-8855-84167B4701A0@cisco.com> From: JP Vasseur To: "Oflynn, Colin" In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-47--202176216 Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 17 Jan 2010 10:25:48 +0100 References: X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 17 Jan 2010 09:25:49.0677 (UTC) FILETIME=[0E9F99D0:01CA9757] Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Proposed Charter Changes 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: Sun, 17 Jan 2010 09:25:56 -0000 --Apple-Mail-47--202176216 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Colin, One quick general comment is that I would propose not to specify any specific media (no reference to wireless, all mechanisms should also apply to different PHY/MAC such as PLC). I do not think that you need in the charter to already specify methods, but just working group items. Thanks. JP. On Jan 16, 2010, at 10:36 AM, Oflynn, Colin wrote: > Hello, > > Zach and I have been working on charter updates, to support a new I- > Draft we have coming (next week hopefully). Essentially it is > designed to make the charter more flexible with respect to methods > of configuring the initial network. > > Also note we use the term 'security bootstrapping' as in draft- > struik-6lowapp-security-considerations. It was felt that > 'bootstrapping' is more in-line with the operating we are > performing, since it requires setting up a network without any prior > communication between nodes. > > Suggest changes are removal of lines: > > -This WG will support three commissioning methodologies: > ... Inclusive to ... > -Modes 1 and 2 are mandatory to implement but mode 3 is optional. > -In all modes, once Device A and Device B have formed a secure > connection > -with Device C, Device C can be used to transitively introduce A and > B so now > -A and B have a secure connection with C. This transitive trust > introduction > -can be used during commissioning even if A and B do not yet have > network > -connectivity to each other. > > And addition of lines > > > + The WG will work to support methods of security bootstrapping > which are > + realistic given the constraints and requirements of the network. > These > + methods are not specific to any communication layer. Instead the > methods > + could run across any layer, including IP. Requirements considered > include: > + > + 1) Suitable for use on resource constrained nodes. This includes > power, > + cost, size, and computational constraints. > + > + 2) Capable of possessing sufficient security for the application > space. > + > + 3) Realistically guarantee any two nodes can join together. This > includes > + nodes which are already on separate networks, but a user wishes to > have those > + two networks merge together. > + > + 4) Additional requirements for each application space, such as > urban or > + commercial environments which deploy large networks compared to > residential > + environments. > + > + To ensure that any two nodes can join together, all nodes must > implement at > + least one universal method. In additional several other methods > will be > + specified which take advantage of the application space. In > commercial > + applications for instance bootstrapping can take advantage of the > fact > + that networks are typically managed from a central authority, and > a method > + optimized for residential usage might take advantage of the fact > that nodes > + are in close proximity. > + > + Methods which will be considered include: > + > + 1) Out of Band Key or Certificate. In this mode a key (either > symmetric or > + asymmetric) is distributed with the product, such as a 2D barcode > printed on > + the node. The user can scan this key with a computer and give > access to this > + node. Typically might be found in industrial, commercial, or urban > environments > + with a central authority. > + > + 2) Push Button Protocol. In this mode two nodes only require > pushbuttons and LEDs, > + and the user simply pushes the button on each node. Due to the > simplicity this > + might be found in home installations. > + > + 3) Out of Band Wireless Communication Link. This could include > IrDA or NFC > + (Near Field Communication) type technologies. Due to the extra > hardware requirements > + this may be found on higher performance nodes. However medical > applications may > + make use of optical communication techniques due to other > requirements. > + > + 4) Out of Band Physical Communication Link. The simplest example > of this is the > + programming interface which a node uses to download firmware. As > all nodes already > + have this hardware present, this may be the simplest interface to > implement. > + > + This list should not be considered exhaustive, and methods may be > removed or added > + as additional application spaces and requirements are found. The > list gives examples > + of the types of methods to be investigated. > > Any comments, suggestions, or questions would be appreciated. > > Regards, > > -Colin O'Flynn > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp --Apple-Mail-47--202176216 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi = Colin,

One quick general comment is that I would = propose not to specify any specific media (no reference to wireless, all = mechanisms should also apply to different PHY/MAC such as = PLC).
I do not think that you need in the charter to already = specify methods, but just working group = items.

Thanks.

JP.
=

On Jan 16, 2010, at 10:36 AM, Oflynn, Colin = wrote:

Hello,

Zach and I have been working on charter = updates, to support a new I-Draft we have coming (next week hopefully). = Essentially it is designed to make the charter more flexible with = respect to methods of configuring the initial network.

Also = note we use the term 'security bootstrapping' as in = draft-struik-6lowapp-security-considerations. It was felt that = 'bootstrapping' is more in-line with the operating we are performing, = since it requires setting up a network without any prior communication = between nodes.

Suggest changes are removal of lines:

= -This WG will support three commissioning methodologies:
... = Inclusive to ...
-Modes 1 and 2 are mandatory to implement but mode = 3 is optional.
-In all modes, once Device A and Device B have formed = a secure connection
-with Device C, Device C can be used to = transitively introduce A and B so now
-A and B have a secure = connection with C. This transitive trust introduction
-can be used = during commissioning even if A and B do not yet have network
= -connectivity to each other.

And addition of lines

=
+ The WG will work to support methods of security bootstrapping = which are
+ realistic given the constraints and requirements of the = network. These
+ methods are not specific to any communication = layer. Instead the methods
+ could run across any layer, including = IP. Requirements considered include:
+
+ 1) Suitable for use on = resource constrained nodes. This includes power,
+ cost, size, and = computational constraints.
+
+ 2) Capable of possessing = sufficient security for the application space.
+
+ 3) = Realistically guarantee any two nodes can join together. This = includes
+ nodes which are already on separate networks, but a user = wishes to have those
+ two networks merge together.
+
+ 4) = Additional requirements for each application space, such as urban or
= + commercial environments which deploy large networks compared to = residential
+ environments.
+
+ To ensure that any two nodes = can join together, all nodes must implement at
+ least one universal = method. In additional several other methods will be
+ specified = which take advantage of the application space. In commercial
+ = applications for instance bootstrapping can take advantage of the = fact
+ that networks are typically managed from a central authority, = and a method
+ optimized for residential usage might take advantage = of the fact that nodes
+ are in close proximity.
+
+ Methods = which will be considered include:
+
+ 1) Out of Band Key or = Certificate. In this mode a key (either symmetric or
+ asymmetric) = is distributed with the product, such as a 2D barcode printed on
+ = the node. The user can scan this key with a computer and give access to = this
+ node. Typically might be found in industrial, commercial, or = urban environments
+ with a central authority.
+
+ 2) Push = Button Protocol. In this mode two nodes only require pushbuttons and = LEDs,
+ and the user simply pushes the button on each node. Due to = the simplicity this
+ might be found in home installations.
= +
+ 3) Out of Band Wireless Communication Link. This could include = IrDA or NFC
+ (Near Field Communication) type technologies. Due to = the extra hardware requirements
+ this may be found on higher = performance nodes. However medical applications may
+ make use of = optical communication techniques due to other requirements.
+
+ = 4) Out of Band Physical Communication Link. The simplest example of this = is the
+ programming interface which a node uses to download = firmware. As all nodes already
+ have this hardware present, this = may be the simplest interface to implement.
+
+ This list should = not be considered exhaustive, and methods may be removed or added
+ = as additional application spaces and requirements are found. The list = gives examples
+ of the types of methods to be investigated.
=
Any comments, suggestions, or questions would be appreciated.
=
Regards,

  -Colin O'Flynn

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

= --Apple-Mail-47--202176216-- From zach@sensinode.com Tue Jan 19 04:37: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 AEED628B797 for <6lowapp@core3.amsl.com>; Tue, 19 Jan 2010 04:37:20 -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 MvBnFD8hb6nq for <6lowapp@core3.amsl.com>; Tue, 19 Jan 2010 04:37:18 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id B8B7F28C0CE for <6lowapp@ietf.org>; Tue, 19 Jan 2010 04:37:16 -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 o0JCamaD008462 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 19 Jan 2010 14:36:49 +0200 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <39A9217F-9F8A-4DA6-8855-84167B4701A0@cisco.com> Date: Tue, 19 Jan 2010 14:36:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <39A9217F-9F8A-4DA6-8855-84167B4701A0@cisco.com> To: JP Vasseur X-Mailer: Apple Mail (2.1077) Cc: "Oflynn, Colin" , 6lowapp@ietf.org Subject: Re: [6lowapp] Proposed Charter Changes 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, 19 Jan 2010 12:37:20 -0000 On Jan 17, 2010, at 11:25 , JP Vasseur wrote: > Hi Colin, >=20 > One quick general comment is that I would propose not to specify any = specific media (no reference to wireless, all mechanisms should also = apply to different PHY/MAC such as PLC). Good point.=20 > I do not think that you need in the charter to already specify = methods, but just working group items. Right, Cullen included a list of possible methods in the = http://trac.tools.ietf.org/area/app/trac/wiki/6LowApp charter proposal. = The idea here was to make them more generic so that the work can be done = in the WG. You are suggesting that we leave the "Methods which will be = considered include:" text away, I would be OK with that. Regarding the work item, the message from Hiroshima was that we need to = reduce the number of work items as much as possible, possibly even just = a single work item (CoAP). However considering that this security = bootstrapping work will have wider application in these environments I = suggest that it should be a separate work item. Currently in = http://trac.tools.ietf.org/area/app/trac/wiki/6LowApp there are 4 work = items. I suggest that we reduce that to 2: 1. CoAP including discovery and HTTP mapping. PS 2. Security bootstrapping. PS Regards, Zach >=20 > Thanks. >=20 > JP. >=20 > On Jan 16, 2010, at 10:36 AM, Oflynn, Colin wrote: >=20 >> Hello, >>=20 >> Zach and I have been working on charter updates, to support a new = I-Draft we have coming (next week hopefully). Essentially it is designed = to make the charter more flexible with respect to methods of configuring = the initial network. >>=20 >> Also note we use the term 'security bootstrapping' as in = draft-struik-6lowapp-security-considerations. It was felt that = 'bootstrapping' is more in-line with the operating we are performing, = since it requires setting up a network without any prior communication = between nodes. >>=20 >> Suggest changes are removal of lines: >>=20 >> -This WG will support three commissioning methodologies: >> ... Inclusive to ... >> -Modes 1 and 2 are mandatory to implement but mode 3 is optional. >> -In all modes, once Device A and Device B have formed a secure = connection >> -with Device C, Device C can be used to transitively introduce A and = B so now >> -A and B have a secure connection with C. This transitive trust = introduction >> -can be used during commissioning even if A and B do not yet have = network >> -connectivity to each other. >>=20 >> And addition of lines >>=20 >>=20 >> + The WG will work to support methods of security bootstrapping which = are >> + realistic given the constraints and requirements of the network. = These >> + methods are not specific to any communication layer. Instead the = methods >> + could run across any layer, including IP. Requirements considered = include: >> + >> + 1) Suitable for use on resource constrained nodes. This includes = power, >> + cost, size, and computational constraints. >> + >> + 2) Capable of possessing sufficient security for the application = space. >> + >> + 3) Realistically guarantee any two nodes can join together. This = includes >> + nodes which are already on separate networks, but a user wishes to = have those >> + two networks merge together. >> + >> + 4) Additional requirements for each application space, such as = urban or >> + commercial environments which deploy large networks compared to = residential >> + environments. >> + >> + To ensure that any two nodes can join together, all nodes must = implement at >> + least one universal method. In additional several other methods = will be >> + specified which take advantage of the application space. In = commercial >> + applications for instance bootstrapping can take advantage of the = fact >> + that networks are typically managed from a central authority, and a = method >> + optimized for residential usage might take advantage of the fact = that nodes >> + are in close proximity. >> + >> + Methods which will be considered include: >> + >> + 1) Out of Band Key or Certificate. In this mode a key (either = symmetric or >> + asymmetric) is distributed with the product, such as a 2D barcode = printed on >> + the node. The user can scan this key with a computer and give = access to this >> + node. Typically might be found in industrial, commercial, or urban = environments >> + with a central authority. >> + >> + 2) Push Button Protocol. In this mode two nodes only require = pushbuttons and LEDs, >> + and the user simply pushes the button on each node. Due to the = simplicity this >> + might be found in home installations. >> + >> + 3) Out of Band Wireless Communication Link. This could include IrDA = or NFC >> + (Near Field Communication) type technologies. Due to the extra = hardware requirements >> + this may be found on higher performance nodes. However medical = applications may >> + make use of optical communication techniques due to other = requirements. >> + >> + 4) Out of Band Physical Communication Link. The simplest example of = this is the >> + programming interface which a node uses to download firmware. As = all nodes already >> + have this hardware present, this may be the simplest interface to = implement. >> + >> + This list should not be considered exhaustive, and methods may be = removed or added >> + as additional application spaces and requirements are found. The = list gives examples >> + of the types of methods to be investigated. >>=20 >> Any comments, suggestions, or questions would be appreciated. >>=20 >> Regards, >>=20 >> -Colin O'Flynn >>=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 zach@sensinode.com Tue Jan 19 05:36:59 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 7889B3A6971 for <6lowapp@core3.amsl.com>; Tue, 19 Jan 2010 05:36:59 -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 pTR4ByulwPbv for <6lowapp@core3.amsl.com>; Tue, 19 Jan 2010 05:36:58 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id EE5BC3A691B for <6lowapp@ietf.org>; Tue, 19 Jan 2010 05:36:57 -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 o0JDan6W015749 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <6lowapp@ietf.org>; Tue, 19 Jan 2010 15:36:50 +0200 From: Zach Shelby Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 19 Jan 2010 15:36:51 +0200 Message-Id: <0B3D3615-F1AB-4067-B758-0A988C10CD98@sensinode.com> To: 6LoWAPP <6lowapp@ietf.org> Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Subject: [6lowapp] 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: Tue, 19 Jan 2010 13:36:59 -0000 Does anyone have comments/ideas regarding = http://www.ietf.org/id/draft-shelby-6lowapp-coap-00.txt that we = submitted before the holidays? We would like to start some design work, = so any feedback would be really useful. I've identified some areas where = we need input/discussion on the list: 1. Content-type encoding (Section 2.4). Any ideas or suggestions on how = to encode this and what is enough space? How should such an encoding be = managed, ask IANA to do that? Any pointers to a similar encoding done = elsewhere? 2. Caching (Section 2.6). Should we go towards an in-band or an = out-of-band discovery approach? Personally I think an in-band approach = is by far the simplest, although it requires some header space when = present. 3. Subscribe/Notify (Section 2.7). This is an area that definitely needs = discussion. The current proposal is to use a REST interface to create = subscriptions and which are then sent using a NOTIFY message to a = call-back URL. How to format the body o the subscription (URL to = subscribe to, URL call-back, parameters?).=20 4. Resource Discovery (Section 2.9). The proposal is to use a new = DISCOVER method which can be sent either unicast or multicast. The only = difficult part there is the format of the list of resources (URLs) which = would be returned in such a response. This is a little bit like = index.html. We had some discussions in Hiroshima that XMPP has developed = some ways of coding lists of URLs and that could be re-used. Does = someone have a pointer for us on that?=20 Thanks, 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 jmamodio@gmail.com Tue Jan 19 05:58: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 D42A43A6846 for <6lowapp@core3.amsl.com>; Tue, 19 Jan 2010 05:58:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 AubDZRVuP3Zh for <6lowapp@core3.amsl.com>; Tue, 19 Jan 2010 05:58:57 -0800 (PST) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id C92613A659B for <6lowapp@ietf.org>; Tue, 19 Jan 2010 05:58:57 -0800 (PST) Received: by pwi20 with SMTP id 20so2592939pwi.29 for <6lowapp@ietf.org>; Tue, 19 Jan 2010 05:58:51 -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=KI6BdE181W2UC7y0YX+W0Z6NC/3f2tkhAqsIsT0bf3Y=; b=RAhgLskwu4uo5lsK5kQm7iKxhT8eJfeaUixVv7+neCWHisUzBuMjVFIvYtjTv3uO8m boF7Eob+YtGrw9d8k+pUg1yfL4wu/isTZugkSOJPp4RpC/b9Ti83S+cDX9zndmnYTRzS 9w+DxqqDM41iWw92QODBKjVqnkhvEd2GRjq4U= 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=rkP+Rqzn7mxVxrS8pFKLBfd3wvV3pKP6S9jiGv3NDm6DrFVWGeU+XBteir2Hp0PtMV +9DgArYuP7WH3xuj+w9MB40bmcEGj6pkLdAMKn19IKfRlr4OctVmI7MyFgjkrrBXTmT+ qBcmTVxKKTF9U7Oqg2McO6yPmpSFXgZqTmayM= MIME-Version: 1.0 Received: by 10.142.248.22 with SMTP id v22mr949721wfh.180.1263909530914; Tue, 19 Jan 2010 05:58:50 -0800 (PST) In-Reply-To: <0B3D3615-F1AB-4067-B758-0A988C10CD98@sensinode.com> References: <0B3D3615-F1AB-4067-B758-0A988C10CD98@sensinode.com> Date: Tue, 19 Jan 2010 07:58:50 -0600 Message-ID: <202705b1001190558v4197c99fk906efd2ab6ea82d1@mail.gmail.com> From: Jorge Amodio To: Zach Shelby Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: 6LoWAPP <6lowapp@ietf.org> Subject: Re: [6lowapp] 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: Tue, 19 Jan 2010 13:58:58 -0000 It would be nice if in section 8 you include some references to REST and somewhere in the document you use "Representational state transfer (REST)" instead of just the acronym. My .02 Jorge On Tue, Jan 19, 2010 at 7:36 AM, Zach Shelby wrote: > Does anyone have comments/ideas regarding http://www.ietf.org/id/draft-sh= elby-6lowapp-coap-00.txt that we submitted before the holidays? We would li= ke to start some design work, so any feedback would be really useful. I've = identified some areas where we need input/discussion on the list: > > 1. Content-type encoding (Section 2.4). Any ideas or suggestions on how t= o encode this and what is enough space? How should such an encoding be mana= ged, ask IANA to do that? Any pointers to a similar encoding done elsewhere= ? > > 2. Caching (Section 2.6). Should we go towards an in-band or an out-of-ba= nd discovery approach? Personally I think an in-band approach is by far the= simplest, although it requires some header space when present. > > 3. Subscribe/Notify (Section 2.7). This is an area that definitely needs = discussion. The current proposal is to use a REST interface to create subsc= riptions and which are then sent using a NOTIFY message to a call-back URL.= How to format the body o the subscription (URL to subscribe to, URL call-b= ack, parameters?). > > 4. Resource Discovery (Section 2.9). The proposal is to use a new DISCOVE= R method which can be sent either unicast or multicast. The only difficult = part there is the format of the list of resources (URLs) which would be ret= urned in such a response. This is a little bit like index.html. We had some= discussions in Hiroshima that XMPP has developed some ways of coding lists= of URLs and that could be re-used. Does someone have a pointer for us on t= hat? > > Thanks, > 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 From jmamodio@gmail.com Tue Jan 19 07:00:19 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 86E803A6A80 for <6lowapp@core3.amsl.com>; Tue, 19 Jan 2010 07:00:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 EccpMh6JXFai for <6lowapp@core3.amsl.com>; Tue, 19 Jan 2010 07:00:19 -0800 (PST) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id E26B228B797 for <6lowapp@ietf.org>; Tue, 19 Jan 2010 07:00:18 -0800 (PST) Received: by pwi20 with SMTP id 20so2630341pwi.29 for <6lowapp@ietf.org>; Tue, 19 Jan 2010 07:00:12 -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; bh=KyGNBoa6jGCk4gCkkuo+9DB3+Vd0esiP29sixhrCzJc=; b=b9qPQ155gI1ENMVZ+s2fT4VeCg9VRqURrRhUdVYcLXmz+oGaOUBvuEnW5XCqr/i3eT Fz+vU83P6mxfAoLG440egv6yhUk2HYHLrQZlWD+3WnH8lTE9yAHTCZTe1KcDD9wFEKJr c/1nNUURDBJ3sQF51Enk4skXb4YWldiFmH0aw= 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; b=jtORP6NfsaGLZOjlVzCjGWqGd+m0MD8wvIiujMjy0iM4q44tJEsDI6LKHCebB8zvNO rEL0msi/qs1N98290JSu6lvGNVaAUWlNwp0gwW2rz/HblBwAvNlwosJ6HfBA2ET3aXKP XHqibQeBf0KHwsynRkQ5X9YhPIw5MwvDWaK3Q= MIME-Version: 1.0 Received: by 10.142.7.16 with SMTP id 16mr1341636wfg.117.1263913212425; Tue, 19 Jan 2010 07:00:12 -0800 (PST) In-Reply-To: <39A9217F-9F8A-4DA6-8855-84167B4701A0@cisco.com> References: <39A9217F-9F8A-4DA6-8855-84167B4701A0@cisco.com> Date: Tue, 19 Jan 2010 09:00:12 -0600 Message-ID: <202705b1001190700t798991b3wb06ad3ba78ccdbce@mail.gmail.com> From: Jorge Amodio To: JP Vasseur Content-Type: text/plain; charset=ISO-8859-1 Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Proposed Charter Changes 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, 19 Jan 2010 15:00:19 -0000 > One quick general comment is that I would propose not to specify any > specific media (no reference to wireless, all mechanisms should also apply > to different PHY/MAC such as PLC). +1 Regads Jorge From guido.moritz@uni-rostock.de Thu Jan 21 06:45: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 B63333A697E for <6lowapp@core3.amsl.com>; Thu, 21 Jan 2010 06:45:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, MSGID_MULTIPLE_AT=1.449, 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 FJ7Sipqjd-ip for <6lowapp@core3.amsl.com>; Thu, 21 Jan 2010 06:45:13 -0800 (PST) Received: from mailrelay1.uni-rostock.de (mailrelay1.uni-rostock.de [139.30.8.201]) by core3.amsl.com (Postfix) with ESMTP id 092483A693B for <6lowapp@ietf.org>; Thu, 21 Jan 2010 06:45:13 -0800 (PST) Received: from email2.uni-rostock.de (139.30.8.209) by edge01.uni-rostock.de (139.30.8.159) with Microsoft SMTP Server (TLS) id 8.2.213.0; Thu, 21 Jan 2010 15:45:07 +0100 Received: from Schlappi (139.30.201.173) by email2.uni-rostock.de (139.30.8.210) with Microsoft SMTP Server (TLS) id 8.2.213.0; Thu, 21 Jan 2010 15:45:07 +0100 From: Guido Moritz To: 6LoWAPP <6lowapp@ietf.org> References: <0B3D3615-F1AB-4067-B758-0A988C10CD98@sensinode.com> In-Reply-To: <0B3D3615-F1AB-4067-B758-0A988C10CD98@sensinode.com> Date: Thu, 21 Jan 2010 15:45:11 +0100 Message-ID: <004201ca9aa8$55d02cd0$01708670$@moritz@uni-rostock.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqZDHoOT3M8skpgSYKQIqzdJjwnigBlF4vQ Content-Language: de Subject: Re: [6lowapp] 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: Thu, 21 Jan 2010 14:45:14 -0000 Dear Zach, personally I am quite familiar with DPWS (see my I-D in 6LoWAPP), but I = may have some more commends on this. I would like to propose to have look on DPWS, WS-Discovery, and SOAP-over-UDP specs at OASIS. They might point = to some conceptual solutions useful for COAP. Please find more comments = below in the text. Regards, Guido > -----Urspr=FCngliche Nachricht----- > Von: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] Im > Auftrag von Zach Shelby > Gesendet: Dienstag, 19. Januar 2010 14:37 > An: 6LoWAPP > Betreff: [6lowapp] draft-shelby-6lowapp-coap-00 >=20 > Does anyone have comments/ideas regarding = http://www.ietf.org/id/draft- > shelby-6lowapp-coap-00.txt that we submitted before the holidays? We > would like to start some design work, so any feedback would be really > useful. I've identified some areas where we need input/discussion on > the list: >=20 > 1. Content-type encoding (Section 2.4). Any ideas or suggestions on = how > to encode this and what is enough space? How should such an encoding = be > managed, ask IANA to do that? Any pointers to a similar encoding done > elsewhere? Encoding in the COAP header might be most efficient way, especially = focusing parsing incoming headers/messages. But extensibility is quite important = and a core feature of REST. XML send via HTTP uses "magic bytes". = SOAP-over-UDP (XML SOAP envelopes send via UDP without HTTP header) binding implementations can use these magic bytes for data format = identification. COAP should include same features to allow own or not prior defined data formats. >=20 > 2. Caching (Section 2.6). Should we go towards an in-band or an = out-of- > band discovery approach? Personally I think an in-band approach is by > far the simplest, although it requires some header space when present. Out-of-band discovery might imply overlapping with other specs (mDNS, WS-Discovery,..). Thus, comprehensive in-band discovery seems a proper approach. Header space should not be a problem because methods/actions/operations of COAP are very limited. Additional = information to be included in the header for discovery purposes would have to be included for out-of-band approaches as well but would require additional efforts to work on "two separated tracks". >=20 > 3. Subscribe/Notify (Section 2.7). This is an area that definitely > needs discussion. The current proposal is to use a REST interface to > create subscriptions and which are then sent using a NOTIFY message to > a call-back URL. How to format the body o the subscription (URL to > subscribe to, URL call-back, parameters?). Similar features are included in DPWS by using WS-Eventing. In subscriptions, a client includes an endpoint for event delivery. This is = a transport specific address including protocol and address. But additional features might be required for a complete eventing = concept. This includes lease management concepts and filtering concepts (e.g. set limits/thresholds for a temperature value). Furthermore, a data = distribution model is required. WS-Eventing uses by default unicast messages to the clients (sinks of event). This requires one message to every subscriber. XMPP instead needs, due to its architecture, only one message to the = server which distributes data to all subscribed clients without need for = multiple sendings of the originator. >=20 > 4. Resource Discovery (Section 2.9). The proposal is to use a new > DISCOVER method which can be sent either unicast or multicast. The = only > difficult part there is the format of the list of resources (URLs) > which would be returned in such a response. This is a little bit like > index.html. We had some discussions in Hiroshima that XMPP has > developed some ways of coding lists of URLs and that could be re-used. > Does someone have a pointer for us on that? WS-Discovery specification goes one step further and combines metadata exchange for devices and service descriptions. In the first step, a = device itself is discovered which is a ensemble of "Hosted Services" (services = or in COAP single resource). A single service itself provides also metadata (methods/operations of service) which can be queried.=20 The new Bluetooth Low Energy Attribute Protocol uses a similar approach = to request either all services of a attribute server or specific attributes = of a service. To sum up, I am not sure which functionalities the discovery of COAP has = to provide, but it might require more efforts then just to define how to = encode a set of URLs. >=20 Some more comments: -REQ2 seems quite hard. Without knowledge about design/architecture to define a header size. -REQ3: Is it useful to make sleeping nodes to an application layer requirement? 6LoWPAN allows seamless integration into existing networks. = To deal with sleeping nodes always requires caching intermediates and thus = does not permit for ad-hoc connectivity, because external endpoints cannot be aware of this. Sleeping nodes should be solved on link layer, without = design requirements for application layer? > Thanks, > 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 >=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 From fluffy@cisco.com Sun Jan 24 15:25:05 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 109493A69BB for <6lowapp@core3.amsl.com>; Sun, 24 Jan 2010 15:25:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.999 X-Spam-Level: X-Spam-Status: No, score=-107.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 FnzfVbP8WOhU for <6lowapp@core3.amsl.com>; Sun, 24 Jan 2010 15:25:03 -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 C15BB3A69A9 for <6lowapp@ietf.org>; Sun, 24 Jan 2010 15:25:03 -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: ApoEAOtlXEurR7H+/2dsb2JhbAC/CZU4hDsE X-IronPort-AV: E=Sophos;i="4.49,336,1262563200"; d="scan'208";a="472107544" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 24 Jan 2010 23:25:07 +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 o0ONP6Jp001400 for <6lowapp@ietf.org>; Sun, 24 Jan 2010 23:25:06 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Impp: xmpp:cullenfluffyjennings@jabber.org Date: Sun, 24 Jan 2010 16:25:05 -0700 Message-Id: <0C0AF10C-85F8-4401-BFB0-441CD08F067E@cisco.com> To: 6lowapp@ietf.org Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Subject: [6lowapp] Revised Charter Proposal 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: Sun, 24 Jan 2010 23:25:05 -0000 I tired to incorporate the discussion on the list and the discussion = from he BOF into a revised charter proposal. I'd like to see if there = were any feedback early this week then, if things look like this charter = is close, send this to Lisa (our AD) and see if this can make it on the = next IESG call.=20 Cullen ---------------------- CoRE Applications are being developed for IP networks that have very limited packet sizes, exhibit a high degree of packet loss, and have 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 applications 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. These networks are becoming increasing important for applications such as home and building automation, energy management, and the Internet of Things. This working group will define a framework for a limited class of applications that deal with the manipulation of simple resources on constrained devices. This includes applications to monitor simple sensors (e.g. temperature sensors, light switches, and power meters) and control actuators (e.g. light switches, heating controllers, and door locks). The general architecture consists of nodes on the constrained network, called Devices, that have one or more Resources that may represent sensors, actuators, or other values. 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. As part of the framework for building these applications, the WG will define a Constrained-node/network Application Protocol (CoAP) for the manipulation of Resources on a Device. The framework will also specify a way to define new interface profiles that vendors and other standards bodies can use to define the particular Resources on a Device and what manipulations are possible. CoAP will be designed to be used between Devices on the same constrained network, between Devices and general nodes on the internet, and between devices on different constrained networks both joined to the internet. There also may be nodes called Constrained-to-General-Internet Intermediaries (CoGII) that interconnect between other protocols typically used by applications on the internet and the Devices using the CoAP protocol. The WG will define a mapping on the CoGII from CoAP to an HTTP REST API; this mapping will not depend on a specific application. Each interface profile will define the Resources on the Device that applications can manipulate and what manipulations are possible. This will determine, in a mechanical translation way, the HTTP REST APIs on the CoGIIs and the CoAP protocol encoding to manipulate the Resources on the Device; it will also specify an XML MIME type for each class of Device that can be used to describe the Resource state in the body of HTTP REST messages. It is worth noting that the CoGII does not have to be deployed at the boundary of the constrained network and the more general network but can be deployed at various locations in the unconstrained network. CoGIIs can provide 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 CoGII that has subscribed, when the CoGII 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. The CoGIIs may also provide support for discovering Devices that may not be currently responding as they are temporarily asleep. The initial work items of the WG is to define a protocol specification for CoAP that includes: 1) A way to define the "interface profile" that specifies the Resources for a Device and implies the REST API that can be used 2) The ability to set and query a resource on a Device. 3) 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. 4) 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 simultaneously. The goals would be delivery of messages roughly within 50 ms of each other for closely located Devices on suitable networks to meet the use case of several lights appearing to turn on at the same time to a human observer. 5) Default operation of the protocol will be over UDP; it may optionally use TCP or other reliable transports. =20 6) A definition of how to use CoAP to discover Devices on the constrained network, and to interrogate them to find out which interface profiles they support. The name taxonomy used for discovery will be consistent with the approach defined in draft-cheshire-dnsext-dns-sd. 7) An ability for Devices to provide a pointer to the general schema information so that a CoGII does not need any code changes to support new Device classes. 8) Specification for the HTTP REST based API and mapping on the CoGII to communicate with Devices. The working group will not develop a reliable multicast solution. Security, particularly keying of new Devices, is very challenging for these applications. On one hand this needs to support models in which an end user can introduce onto their network a new Device that may have no display or input capabilities. On the other hand, this protocol may transport information about alarm systems or controlling door locks over a wireless network. The WG will work to support methods of security bootstrapping which are realistic given the constraints and requirements of the network. These methods are not specific to any communication layer. Instead the methods could run across any layer, including IP. Requirements considered include: 1) The methods need to be suitable for use on resource constrained nodes. These constraints include power, cost, size, and computational capacity. [[ Note: the WG realizes the vagueness of this constraint but does not currently have consensus on a more quantitative metric of these constraints ]] 2) The methods need to provide sufficient security for the application space. 3) The methods must guarantee that any two nodes can join together. This includes nodes which are already on separate networks which a user wishes to merge together. 4) There may be additional requirements for each application space, such as urban or commercial environments which deploy large networks, compared to residential environments. To ensure that any two nodes can join together, all nodes must implement at least one universal method. In additional several other methods will be specified which take advantage of the application space. In commercial applications, for instance, bootstrapping can take advantage of the fact that networks are typically managed from a central authority, and a method optimized for residential usage might take advantage of the fact that nodes are in close proximity. Methods which will be considered include: 1) Out of Band Key or Certificate: In this mode a key (either symmetric or asymmetric) is distributed with the product, such as a 2D barcode printed on the node. The user can scan this key with a computer to give access to this node. 2) Physical Button Protocol: In this mode two nodes only require pushbuttons and LEDs, and the user simply pushes the button on each node within a narrow time window to join them together. 3) Out of Band Communication Link: This could include IrDA or NFC (Near Field Communication) type technologies to allow a device to join another device that is physically nearby. 4) Out of Band Configuration: A simple example of this would be using the programming interface which a node uses to download firmware. This list should not be considered exhaustive, and methods may be removed or added as additional application spaces and requirements are found. The list gives examples of the types of methods to be investigated. Security can be achieved using other session security or object security. For session security, the WG will work with the security area to select cipher suites most useful for constrained network. For object security, CoAP will initially look at CMS (RFC 5652). The WG will coordinate on requirements from many organizations including OpenSG/NIST, ZigBee/HomePlug, IPSO Alliance, OASIS, SENSEI; 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: Mar 2010 - Select WG document for basis of CoAP protocol Dec 2010 - CoAP protocol specification with mapping to HTTP Rest API submitted to IESG as PS Jan 2011 - Recharter to add things reduced out of initial scope From hgs@cs.columbia.edu Sun Jan 24 16:14: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 845E93A67B1 for <6lowapp@core3.amsl.com>; Sun, 24 Jan 2010 16:14:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 OmWqOHBQn+FL for <6lowapp@core3.amsl.com>; Sun, 24 Jan 2010 16:14:19 -0800 (PST) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id D72FC3A677C for <6lowapp@ietf.org>; Sun, 24 Jan 2010 16:14:15 -0800 (PST) Received: from upstairs.home (pool-173-54-225-147.nwrknj.fios.verizon.net [173.54.225.147]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id o0P0DoFN007652 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 24 Jan 2010 19:13:51 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=windows-1252 From: Henning Schulzrinne In-Reply-To: <0C0AF10C-85F8-4401-BFB0-441CD08F067E@cisco.com> Date: Sun, 24 Jan 2010 19:13:49 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <777549F2-4155-4CCF-8246-D394480D49F1@cs.columbia.edu> References: <0C0AF10C-85F8-4401-BFB0-441CD08F067E@cisco.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1077) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.8 Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Revised Charter Proposal 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, 25 Jan 2010 00:14:20 -0000 For the configuration part, there is significant existing work, as part = of the Wi-Fi Protected Setup=99 ("Facilitates easy set-up of security = features using a Personal Identification Number (PIN) or other defined = methods within the Wi-Fi device"). Not sure this needs to be called out = explicitly, but somebody may want to make sure we don't rule out = reasonable mechanisms that seem to have widespread support in a similar = scenario elsewhere. Henning On Jan 24, 2010, at 6:25 PM, Cullen Jennings wrote: >=20 > I tired to incorporate the discussion on the list and the discussion = from he BOF into a revised charter proposal. I'd like to see if there = were any feedback early this week then, if things look like this charter = is close, send this to Lisa (our AD) and see if this can make it on the = next IESG call.=20 >=20 > Cullen >=20 > ---------------------- >=20 >=20 > CoRE >=20 > Applications are being developed for IP networks that have very = limited > packet sizes, exhibit a high degree of packet loss, and have = 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 applications whenever at least some > of the nodes and networks involved exhibit these characteristics. >=20 > Low-Power Wireless Personal Area Networks (LoWPANs) are an example of > this type of network. These networks are becoming increasing important > for applications such as home and building automation, energy > management, and the Internet of Things. This working group will define = a > framework for a limited class of applications that deal with the > manipulation of simple resources on constrained devices. This includes > applications to monitor simple sensors (e.g. temperature sensors, = light > switches, and power meters) and control actuators (e.g. light = switches, > heating controllers, and door locks). >=20 > The general architecture consists of nodes on the constrained network, > called Devices, that have one or more Resources that may represent > sensors, actuators, or other values. 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. As part of the framework for building = these > applications, the WG will define a Constrained-node/network = Application > Protocol (CoAP) for the manipulation of Resources on a Device. The > framework will also specify a way to define new interface profiles = that > vendors and other standards bodies can use to define the particular > Resources on a Device and what manipulations are possible. >=20 > CoAP will be designed to be used between Devices on the same = constrained > network, between Devices and general nodes on the internet, and = between > devices on different constrained networks both joined to the internet. >=20 > There also may be nodes called Constrained-to-General-Internet > Intermediaries (CoGII) that interconnect between other protocols > typically used by applications on the internet and the Devices using = the > CoAP protocol. The WG will define a mapping on the CoGII from CoAP to > an HTTP REST API; this mapping will not depend on a specific > application. Each interface profile will define the Resources on the > Device that applications can manipulate and what manipulations are > possible. This will determine, in a mechanical translation way, the > HTTP REST APIs on the CoGIIs and the CoAP protocol encoding to > manipulate the Resources on the Device; it will also specify an XML = MIME > type for each class of Device that can be used to describe the = Resource > state in the body of HTTP REST messages. It is worth noting that the > CoGII does not have to be deployed at the boundary of the constrained > network and the more general network but can be deployed at various > locations in the unconstrained network. >=20 > CoGIIs can provide 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 CoGII that has subscribed, when > the CoGII 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. The CoGIIs may also provide support > for discovering Devices that may not be currently responding as they = are > temporarily asleep. >=20 > The initial work items of the WG is to define a protocol specification > for CoAP that includes: >=20 > 1) A way to define the "interface profile" that specifies the = Resources > for a Device and implies the REST API that can be used >=20 > 2) The ability to set and query a resource on a Device. >=20 > 3) 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 > 4) 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 > simultaneously. The goals would be delivery of messages roughly > within 50 ms of each other for closely located Devices on suitable > networks to meet the use case of several lights appearing to turn on > at the same time to a human observer. >=20 > 5) Default operation of the protocol will be over UDP; it may = optionally > use TCP or other reliable transports. >=20 > 6) A definition of how to use CoAP to discover Devices on the > constrained network, and to interrogate them to find out which > interface profiles they support. The name taxonomy used for > discovery will be consistent with the approach defined in > draft-cheshire-dnsext-dns-sd. >=20 > 7) An ability for Devices to provide a pointer to the general schema > information so that a CoGII does not need any code changes to = support > new Device classes. >=20 > 8) Specification for the HTTP REST based API and mapping on the CoGII = to > communicate with Devices. >=20 > The working group will not develop a reliable multicast solution. >=20 > Security, particularly keying of new Devices, is very challenging for > these applications. On one hand this needs to support models in which = an > end user can introduce onto their network a new Device that may have = no > display or input capabilities. On the other hand, this protocol may > transport information about alarm systems or controlling door locks = over > a wireless network. >=20 > The WG will work to support methods of security bootstrapping which = are > realistic given the constraints and requirements of the network. These > methods are not specific to any communication layer. Instead the = methods > could run across any layer, including IP. Requirements considered > include: >=20 > 1) The methods need to be suitable for use on resource constrained > nodes. These constraints include power, cost, size, and = computational > capacity. [[ Note: the WG realizes the vagueness of this constraint > but does not currently have consensus on a more quantitative metric > of these constraints ]] >=20 > 2) The methods need to provide sufficient security for the application > space. >=20 > 3) The methods must guarantee that any two nodes can join together. = This > includes nodes which are already on separate networks which a user > wishes to merge together. >=20 > 4) There may be additional requirements for each application space, = such > as urban or commercial environments which deploy large networks, > compared to residential environments. >=20 > To ensure that any two nodes can join together, all nodes must = implement > at least one universal method. In additional several other methods = will > be specified which take advantage of the application space. In > commercial applications, for instance, bootstrapping can take = advantage > of the fact that networks are typically managed from a central > authority, and a method optimized for residential usage might take > advantage of the fact that nodes are in close proximity. >=20 > Methods which will be considered include: >=20 > 1) Out of Band Key or Certificate: In this mode a key (either = symmetric > or asymmetric) is distributed with the product, such as a 2D barcode > printed on the node. The user can scan this key with a computer to > give access to this node. >=20 > 2) Physical Button Protocol: In this mode two nodes only require > pushbuttons and LEDs, and the user simply pushes the button on each > node within a narrow time window to join them together. >=20 > 3) Out of Band Communication Link: This could include IrDA or NFC = (Near > Field Communication) type technologies to allow a device to join > another device that is physically nearby. >=20 > 4) Out of Band Configuration: A simple example of this would be using > the programming interface which a node uses to download firmware. >=20 > This list should not be considered exhaustive, and methods may be > removed or added as additional application spaces and requirements are > found. The list gives examples of the types of methods to be > investigated. >=20 > Security can be achieved using other session security or object > security. For session security, the WG will work with the security = area > to select cipher suites most useful for constrained network. For = object > security, CoAP will initially look at CMS (RFC 5652). >=20 > The WG will coordinate on requirements from many organizations = including > OpenSG/NIST, ZigBee/HomePlug, IPSO Alliance, OASIS, SENSEI; 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 > Mar 2010 - Select WG document for basis of CoAP protocol >=20 > Dec 2010 - CoAP protocol specification with mapping to HTTP Rest API > 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 lars.eggert@nokia.com Sun Jan 24 23:27:15 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 4BE263A67F6 for <6lowapp@core3.amsl.com>; Sun, 24 Jan 2010 23:27:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 RmqDnBXSYN03 for <6lowapp@core3.amsl.com>; Sun, 24 Jan 2010 23:27:14 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 58B253A6767 for <6lowapp@ietf.org>; Sun, 24 Jan 2010 23:27:14 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0P7QZlU012083; Mon, 25 Jan 2010 01:27:08 -0600 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Jan 2010 09:27:02 +0200 Received: from mgw-sa02.ext.nokia.com ([147.243.1.48]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Jan 2010 09:27:02 +0200 Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa02.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0P7R0ab025357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Jan 2010 09:27:00 +0200 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.95.3 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/signed; boundary=Apple-Mail-6-481887902; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <0C0AF10C-85F8-4401-BFB0-441CD08F067E@cisco.com> Date: Mon, 25 Jan 2010 08:26:52 +0100 Message-Id: References: <0C0AF10C-85F8-4401-BFB0-441CD08F067E@cisco.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1077) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [0.0.0.0]); Mon, 25 Jan 2010 09:26:54 +0200 (EET) X-OriginalArrivalTime: 25 Jan 2010 07:27:02.0356 (UTC) FILETIME=[C9B6B940:01CA9D8F] X-Nokia-AV: Clean Cc: "6lowapp@ietf.org" <6lowapp@ietf.org> Subject: Re: [6lowapp] Revised Charter Proposal 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, 25 Jan 2010 07:27:15 -0000 --Apple-Mail-6-481887902 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, looks pretty good. A few comments:=20 In general, I'm missing a statement that this will use the 6LOWPAN and = ROLL way of doing IPv6 over these links rather than some other way, or - = even worse - IPv4. (The coordination text has some words about 6LOWPAN = and ROLL, but nothing that I read as "6LOWPAN will use their stuff.) On 2010-1-25, at 0:25, Cullen Jennings wrote: > 4) 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 > simultaneously. The goals would be delivery of messages roughly > within 50 ms of each other for closely located Devices on suitable > networks to meet the use case of several lights appearing to turn on > at the same time to a human observer. Doesn't apply this magic 50ms number also to unicast traffic? More = importantly though, there is not much that CoAP can do in guaranteeing = that delay; it seems to be almost entirely dependent on the underlying = routing, radio and sensor technologies. > 5) Default operation of the protocol will be over UDP; it may = optionally > use TCP or other reliable transports. I think we need to rephrase this bullet. I don't think you mean = "optionally, TCP can be used in stead of UDP" when you say "it may = optionally...", but it can be misread in this way. Also, while folks have demonstrated that you can run TCP at acceptable = performance in some deployments, I believe that these deployments have = been very controlled in terms of their topology, radio configuration, = routing setup, etc. *In such cases* CoAP could optionally partially use = TCP for some operations, but in most deployments (esp. "unmanaged" home = deployments) this will simply not work very well. All the essential = functions of CoAP must IMO therefore run over UDP. > 4) There may be additional requirements for each application space, = such > as urban or commercial environments which deploy large networks, > compared to residential environments. Must CoAP support these application spaces from the beginning? If some = of the yet-unstated requirements for these app spaces are conflicting, = it's really easy for the WG to wedge itself, because the design space = for the solution becomes the empty set. Or is the paragraph above still about bootstrapping methods? Segway: I = think you should explicitly say "bootstrapping method" in almost all = places where you currently say "method" to make it clear whether that is = what you mean. And if not, use a different word :-) > Security can be achieved using other session security or object > security. For session security, the WG will work with the security = area > to select cipher suites most useful for constrained network. For = object > security, CoAP will initially look at CMS (RFC 5652). For session security, you not only need ciphers, you also need a = protocol. Is the intent that you'd use TLS/DTLS? Then please say so. Lars --Apple-Mail-6-481887902 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTEwMDEyNTA3MjY1M1owIwYJKoZIhvcNAQkEMRYEFL5NLSCm3oJeurUwiMGvmdCcJWu5MIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQCSz6P7qpA8X5BhpQC4tHJWVAEk5Rt2YGj+KKRFaThYyzMz4f4k5k0EN4OgHN7MojOpz3eH 3fVJJEMfr+REdPGbs+WNhOLzMfnaBdPlOuYmcqg7oQSeLZCQpCCN8LGKwFXIQmSu7RqntJvTtkkN ZisTTMbw2F5n6UG8hwkFcfP9+QWPSMXnp8p86rWD7v3hqRYGGp7SOCrSY1fRZlhFVvUW0K2nelAW NgduUZhiBSHgJUPUhXVnxQGjg62gFF5/rrqVNHlktW7Zc+bfsSqDOUrze5O/xttWCMxl6JhcihHX S4rAlxc93iNJ6dMEL93Y5d0F0KCEXj+NHTbCfsdXS9kuAAAAAAAA --Apple-Mail-6-481887902-- From Colin.OFlynn@atmel.com Mon Jan 25 00:31:56 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 1EBE43A67EB for <6lowapp@core3.amsl.com>; Mon, 25 Jan 2010 00:31:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 91ZDAkHybJNn for <6lowapp@core3.amsl.com>; Mon, 25 Jan 2010 00:31:48 -0800 (PST) Received: from sjogate2.atmel.com (newsmtp5.atmel.com [204.2.163.5]) by core3.amsl.com (Postfix) with ESMTP id 0DA093A6767 for <6lowapp@ietf.org>; Mon, 25 Jan 2010 00:31:47 -0800 (PST) Received: from csomb01.corp.atmel.com ([10.95.30.150]) by sjogate2.atmel.com (8.13.6/8.13.6) with ESMTP id o0P8TeWl025468; Mon, 25 Jan 2010 00:29:42 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA9D98.C55DAC29" Date: Mon, 25 Jan 2010 01:31:20 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowapp] Revised Charter Proposal Thread-Index: AcqdU2Sl+aQ1ySs3RF63DVjl0YhkJgARJqnv References: <0C0AF10C-85F8-4401-BFB0-441CD08F067E@cisco.com> <777549F2-4155-4CCF-8246-D394480D49F1@cs.columbia.edu> From: "Oflynn, Colin" To: "Henning Schulzrinne" , "Cullen Jennings" Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Revised Charter Proposal 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, 25 Jan 2010 08:31:56 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA9D98.C55DAC29 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Cullen, Those methods are a good starting point, but I don't feel entirely = suitable. I've put a number of thoughts in a document at = http://www.newae.com/tiki-download_wiki_attachment.php?attId=3D5 There should shortly be an RFC with details on breaking down the exact = requirements & solutions as well. Shorlty as in days.... Regards, -Colin -----Original Message----- From: 6lowapp-bounces@ietf.org on behalf of Henning Schulzrinne Sent: Mon 25/01/2010 00:13 To: Cullen Jennings Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Revised Charter Proposal =20 For the configuration part, there is significant existing work, as part = of the Wi-Fi Protected SetupT ("Facilitates easy set-up of security = features using a Personal Identification Number (PIN) or other defined = methods within the Wi-Fi device"). Not sure this needs to be called out = explicitly, but somebody may want to make sure we don't rule out = reasonable mechanisms that seem to have widespread support in a similar = scenario elsewhere. Henning On Jan 24, 2010, at 6:25 PM, Cullen Jennings wrote: >=20 > I tired to incorporate the discussion on the list and the discussion = from he BOF into a revised charter proposal. I'd like to see if there = were any feedback early this week then, if things look like this charter = is close, send this to Lisa (our AD) and see if this can make it on the = next IESG call.=20 >=20 > Cullen >=20 > ---------------------- >=20 >=20 > CoRE >=20 > Applications are being developed for IP networks that have very = limited > packet sizes, exhibit a high degree of packet loss, and have = 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 applications whenever at least some > of the nodes and networks involved exhibit these characteristics. >=20 > Low-Power Wireless Personal Area Networks (LoWPANs) are an example of > this type of network. These networks are becoming increasing important > for applications such as home and building automation, energy > management, and the Internet of Things. This working group will define = a > framework for a limited class of applications that deal with the > manipulation of simple resources on constrained devices. This includes > applications to monitor simple sensors (e.g. temperature sensors, = light > switches, and power meters) and control actuators (e.g. light = switches, > heating controllers, and door locks). >=20 > The general architecture consists of nodes on the constrained network, > called Devices, that have one or more Resources that may represent > sensors, actuators, or other values. 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. As part of the framework for building = these > applications, the WG will define a Constrained-node/network = Application > Protocol (CoAP) for the manipulation of Resources on a Device. The > framework will also specify a way to define new interface profiles = that > vendors and other standards bodies can use to define the particular > Resources on a Device and what manipulations are possible. >=20 > CoAP will be designed to be used between Devices on the same = constrained > network, between Devices and general nodes on the internet, and = between > devices on different constrained networks both joined to the internet. >=20 > There also may be nodes called Constrained-to-General-Internet > Intermediaries (CoGII) that interconnect between other protocols > typically used by applications on the internet and the Devices using = the > CoAP protocol. The WG will define a mapping on the CoGII from CoAP to > an HTTP REST API; this mapping will not depend on a specific > application. Each interface profile will define the Resources on the > Device that applications can manipulate and what manipulations are > possible. This will determine, in a mechanical translation way, the > HTTP REST APIs on the CoGIIs and the CoAP protocol encoding to > manipulate the Resources on the Device; it will also specify an XML = MIME > type for each class of Device that can be used to describe the = Resource > state in the body of HTTP REST messages. It is worth noting that the > CoGII does not have to be deployed at the boundary of the constrained > network and the more general network but can be deployed at various > locations in the unconstrained network. >=20 > CoGIIs can provide 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 CoGII that has subscribed, when > the CoGII 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. The CoGIIs may also provide support > for discovering Devices that may not be currently responding as they = are > temporarily asleep. >=20 > The initial work items of the WG is to define a protocol specification > for CoAP that includes: >=20 > 1) A way to define the "interface profile" that specifies the = Resources > for a Device and implies the REST API that can be used >=20 > 2) The ability to set and query a resource on a Device. >=20 > 3) 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 > 4) 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 > simultaneously. The goals would be delivery of messages roughly > within 50 ms of each other for closely located Devices on suitable > networks to meet the use case of several lights appearing to turn on > at the same time to a human observer. >=20 > 5) Default operation of the protocol will be over UDP; it may = optionally > use TCP or other reliable transports. >=20 > 6) A definition of how to use CoAP to discover Devices on the > constrained network, and to interrogate them to find out which > interface profiles they support. The name taxonomy used for > discovery will be consistent with the approach defined in > draft-cheshire-dnsext-dns-sd. >=20 > 7) An ability for Devices to provide a pointer to the general schema > information so that a CoGII does not need any code changes to = support > new Device classes. >=20 > 8) Specification for the HTTP REST based API and mapping on the CoGII = to > communicate with Devices. >=20 > The working group will not develop a reliable multicast solution. >=20 > Security, particularly keying of new Devices, is very challenging for > these applications. On one hand this needs to support models in which = an > end user can introduce onto their network a new Device that may have = no > display or input capabilities. On the other hand, this protocol may > transport information about alarm systems or controlling door locks = over > a wireless network. >=20 > The WG will work to support methods of security bootstrapping which = are > realistic given the constraints and requirements of the network. These > methods are not specific to any communication layer. Instead the = methods > could run across any layer, including IP. Requirements considered > include: >=20 > 1) The methods need to be suitable for use on resource constrained > nodes. These constraints include power, cost, size, and = computational > capacity. [[ Note: the WG realizes the vagueness of this constraint > but does not currently have consensus on a more quantitative metric > of these constraints ]] >=20 > 2) The methods need to provide sufficient security for the application > space. >=20 > 3) The methods must guarantee that any two nodes can join together. = This > includes nodes which are already on separate networks which a user > wishes to merge together. >=20 > 4) There may be additional requirements for each application space, = such > as urban or commercial environments which deploy large networks, > compared to residential environments. >=20 > To ensure that any two nodes can join together, all nodes must = implement > at least one universal method. In additional several other methods = will > be specified which take advantage of the application space. In > commercial applications, for instance, bootstrapping can take = advantage > of the fact that networks are typically managed from a central > authority, and a method optimized for residential usage might take > advantage of the fact that nodes are in close proximity. >=20 > Methods which will be considered include: >=20 > 1) Out of Band Key or Certificate: In this mode a key (either = symmetric > or asymmetric) is distributed with the product, such as a 2D barcode > printed on the node. The user can scan this key with a computer to > give access to this node. >=20 > 2) Physical Button Protocol: In this mode two nodes only require > pushbuttons and LEDs, and the user simply pushes the button on each > node within a narrow time window to join them together. >=20 > 3) Out of Band Communication Link: This could include IrDA or NFC = (Near > Field Communication) type technologies to allow a device to join > another device that is physically nearby. >=20 > 4) Out of Band Configuration: A simple example of this would be using > the programming interface which a node uses to download firmware. >=20 > This list should not be considered exhaustive, and methods may be > removed or added as additional application spaces and requirements are > found. The list gives examples of the types of methods to be > investigated. >=20 > Security can be achieved using other session security or object > security. For session security, the WG will work with the security = area > to select cipher suites most useful for constrained network. For = object > security, CoAP will initially look at CMS (RFC 5652). >=20 > The WG will coordinate on requirements from many organizations = including > OpenSG/NIST, ZigBee/HomePlug, IPSO Alliance, OASIS, SENSEI; 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 > Mar 2010 - Select WG document for basis of CoAP protocol >=20 > Dec 2010 - CoAP protocol specification with mapping to HTTP Rest API > 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 _______________________________________________ 6lowapp mailing list 6lowapp@ietf.org https://www.ietf.org/mailman/listinfo/6lowapp ------_=_NextPart_001_01CA9D98.C55DAC29 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [6lowapp] Revised Charter Proposal

Hi Cullen,

Those methods are a good starting point, but I don't feel entirely = suitable. I've put a number of thoughts in a document at http://www.newae.com/tiki-download_wiki_attachment.php?attId=3D5
=
There should shortly be an RFC with details on breaking down the exact = requirements & solutions as well. Shorlty as in days....

Regards,

  -Colin


-----Original Message-----
From: 6lowapp-bounces@ietf.org on behalf of Henning Schulzrinne
Sent: Mon 25/01/2010 00:13
To: Cullen Jennings
Cc: 6lowapp@ietf.org
Subject: Re: [6lowapp] Revised Charter Proposal

For the configuration part, there is significant existing work, as part = of the Wi-Fi Protected SetupT ("Facilitates easy set-up of security = features using a Personal Identification Number (PIN) or other defined = methods within the Wi-Fi device"). Not sure this needs to be called = out explicitly, but somebody may want to make sure we don't rule out = reasonable mechanisms that seem to have widespread support in a similar = scenario elsewhere.

Henning

On Jan 24, 2010, at 6:25 PM, Cullen Jennings wrote:

>
> I tired to incorporate the discussion on the list and the = discussion from he BOF into a revised charter proposal. I'd like to see = if there were any feedback early this week then, if things look like = this charter is close, send this to Lisa (our AD) and see if this can = make it on the next IESG call.
>
> Cullen
>
> ----------------------
>
>
> CoRE
>
> Applications are being developed for IP networks that have very = limited
> packet sizes, exhibit a high degree of packet loss, and have = 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 applications 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. These networks are becoming increasing = important
> for applications such as home and building automation, energy
> management, and the Internet of Things. This working group will = define a
> framework for a limited class of applications that deal with = the
> manipulation of simple resources on constrained devices. This = includes
> applications to monitor simple sensors (e.g.  temperature = sensors, light
> switches, and power meters) and control actuators (e.g. light = switches,
> heating controllers, and door locks).
>
> The general architecture consists of nodes on the constrained = network,
> called Devices, that have one or more Resources that may = represent
> sensors, actuators, or other values. 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. As part of the framework for building = these
> applications, the WG will define a Constrained-node/network = Application
> Protocol (CoAP) for the manipulation of Resources on a Device. = The
> framework will also specify a way to define new interface profiles = that
> vendors and other standards bodies can use to define the = particular
> Resources on a Device and what manipulations are possible.
>
> CoAP will be designed to be used between Devices on the same = constrained
> network, between Devices and general nodes on the internet, and = between
> devices on different constrained networks both joined to the = internet.
>
> There also may be nodes called Constrained-to-General-Internet
> Intermediaries (CoGII) that interconnect between other = protocols
> typically used by applications on the internet and the Devices = using the
> CoAP protocol.  The WG will define a mapping on the CoGII from = CoAP to
> an HTTP REST API; this mapping will not depend on a specific
> application.  Each interface profile will define the Resources = on the
> Device that applications can manipulate and what manipulations = are
> possible.  This will determine, in a mechanical translation = way, the
> HTTP REST APIs on the CoGIIs and the CoAP protocol encoding to
> manipulate the Resources on the Device; it will also specify an XML = MIME
> type for each class of Device that can be used to describe the = Resource
> state in the body of HTTP REST messages. It is worth noting that = the
> CoGII does not have to be deployed at the boundary of the = constrained
> network and the more general network but can be deployed at = various
> locations in the unconstrained network.
>
> CoGIIs can provide 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 CoGII that has subscribed, = when
> the CoGII 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. The CoGIIs may also provide = support
> for discovering Devices that may not be currently responding as = they are
> temporarily asleep.
>
> The initial work items of the WG is to define a protocol = specification
> for CoAP that includes:
>
> 1) A way to define the "interface profile" that specifies = the Resources
>   for a Device and implies the REST API that can be = used
>
> 2) The ability to set and query a resource on a Device.
>
> 3) 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.
>
> 4) 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
>   simultaneously.  The goals would be delivery of = messages roughly
>   within 50 ms of each other for closely located Devices = on suitable
>   networks to meet the use case of several lights = appearing to turn on
>   at the same time to a human observer.
>
> 5) Default operation of the protocol will be over UDP; it may = optionally
>   use TCP or other reliable transports.
>
> 6) A definition of how to use CoAP to discover Devices on the
>   constrained network, and to interrogate them to find = out which
>   interface profiles they support.  The name = taxonomy used for
>   discovery will be consistent with the approach defined = in
>   draft-cheshire-dnsext-dns-sd.
>
> 7) An ability for Devices to provide a pointer to the general = schema
>   information so that a CoGII does not need any code = changes to support
>   new Device classes.
>
> 8) Specification for the HTTP REST based API and mapping on the = CoGII to
>   communicate with Devices.
>
> The working group will not develop a reliable multicast = solution.
>
> Security, particularly keying of new Devices, is very challenging = for
> these applications. On one hand this needs to support models in = which an
> end user can introduce onto their network a new Device that may = have no
> display or input capabilities. On the other hand, this protocol = may
> transport information about alarm systems or controlling door locks = over
> a wireless network.
>
> The WG will work to support methods of security bootstrapping which = are
> realistic given the constraints and requirements of the network. = These
> methods are not specific to any communication layer. Instead the = methods
> could run across any layer, including IP. Requirements = considered
> include:
>
> 1) The methods need to be suitable for use on resource = constrained
>   nodes. These constraints include power, cost, size, and = computational
>   capacity. [[ Note: the WG realizes the vagueness of = this constraint
>   but does not currently have consensus on a more = quantitative metric
>   of these constraints ]]
>
> 2) The methods need to provide sufficient security for the = application
>   space.
>
> 3) The methods must guarantee that any two nodes can join together. = This
>   includes nodes which are already on separate networks = which a user
>   wishes to merge together.
>
> 4) There may be additional requirements for each application space, = such
>   as urban or commercial environments which deploy large = networks,
>   compared to residential environments.
>
> To ensure that any two nodes can join together, all nodes must = implement
> at least one universal method. In additional several other methods = will
> be specified which take advantage of the application space. In
> commercial applications, for instance, bootstrapping can take = advantage
> of the fact that networks are typically managed from a central
> authority, and a method optimized for residential usage might = take
> advantage of the fact that nodes are in close proximity.
>
> Methods which will be considered include:
>
> 1) Out of Band Key or Certificate: In this mode a key (either = symmetric
>   or asymmetric) is distributed with the product, such as = a 2D barcode
>   printed on the node. The user can scan this key with a = computer to
>   give access to this node.
>
> 2) Physical Button Protocol: In this mode two nodes only = require
>   pushbuttons and LEDs, and the user simply pushes the = button on each
>   node within a narrow time window to join them = together.
>
> 3) Out of Band Communication Link: This could include IrDA or NFC = (Near
>   Field Communication) type technologies to allow a = device to join
>   another device that is physically nearby.
>
> 4) Out of Band Configuration: A simple example of this would be = using
>   the programming interface which a node uses to download = firmware.
>
> This list should not be considered exhaustive, and methods may = be
> removed or added as additional application spaces and requirements = are
> found. The list gives examples of the types of methods to be
> investigated.
>
> Security can be achieved using other session security or object
> security.  For session security, the WG will work with the = security area
> to select cipher suites most useful for constrained network.  = For object
> security, CoAP will initially look at CMS (RFC 5652).
>
> The WG will coordinate on requirements from many organizations = including
> OpenSG/NIST, ZigBee/HomePlug, IPSO Alliance, OASIS, SENSEI; 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:
>
> Mar 2010 - Select WG document for basis of CoAP protocol
>
> Dec 2010 - CoAP protocol specification with mapping to HTTP Rest = API
>           = 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.o= rg/mailman/listinfo/6lowapp
>

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

------_=_NextPart_001_01CA9D98.C55DAC29-- From dromasca@avaya.com Mon Jan 25 01:45: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 0063A3A696E for <6lowapp@core3.amsl.com>; Mon, 25 Jan 2010 01:45:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.700, 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 ADxWX0Dat1zY for <6lowapp@core3.amsl.com>; Mon, 25 Jan 2010 01:45:37 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id EE89E3A694A for <6lowapp@ietf.org>; Mon, 25 Jan 2010 01:45:36 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,338,1262581200"; d="scan'208";a="173738411" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 25 Jan 2010 04:45:38 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 25 Jan 2010 04:44:58 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Jan 2010 10:44:53 +0100 Message-ID: In-Reply-To: <0C0AF10C-85F8-4401-BFB0-441CD08F067E@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowapp] Revised Charter Proposal Thread-Index: AcqdTHo2oX3iDip4SR6qBKWFz7UkjAAVIvOg References: <0C0AF10C-85F8-4401-BFB0-441CD08F067E@cisco.com> From: "Romascanu, Dan (Dan)" To: "Cullen Jennings" , <6lowapp@ietf.org> Subject: Re: [6lowapp] Revised Charter Proposal 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, 25 Jan 2010 09:45:39 -0000 Cullen, Good start, I have a few observations:=20 - there is a lot of standardization activity in this area. Beyond what is already mentioned in the charter I know about IEEE P802.3az doing significant work in the Energy-Efficient Ethernet Task Force, Henning mentioned WiFi. We need to understand what 'The WG will coordinate on requirements' means. If something is developped by another SDO do we need to replicate the work in the IETF? Maybe yes in some cases, if the work is for example layer 2 specific.=20 - The milestone 'Mar 2010 - Select WG document for basis of CoAP protocol' is completely unrealistic taking onto account that the charter is not yet in IESG review - The operational and manageability aspects are not mentioned, excepting firmware updates. They are implied in some of the capabilities like querying resources, but I think that observability of device presence and operational status query should be mentioned explicitly.=20 Dan > -----Original Message----- > From: 6lowapp-bounces@ietf.org=20 > [mailto:6lowapp-bounces@ietf.org] On Behalf Of Cullen Jennings > Sent: Monday, January 25, 2010 1:25 AM > To: 6lowapp@ietf.org > Subject: [6lowapp] Revised Charter Proposal >=20 >=20 > I tired to incorporate the discussion on the list and the=20 > discussion from he BOF into a revised charter proposal. I'd=20 > like to see if there were any feedback early this week then,=20 > if things look like this charter is close, send this to Lisa=20 > (our AD) and see if this can make it on the next IESG call.=20 >=20 > Cullen >=20 > ---------------------- >=20 >=20 > CoRE >=20 > Applications are being developed for IP networks that have=20 > very limited packet sizes, exhibit a high degree of packet=20 > loss, and have substantial number of devices that may be=20 > powered off at any point in time but periodically "wake up"=20 > for brief periods of time. These networks, and the nodes=20 > within them are characterized by severe limits on throughput,=20 > available power, and particularly on the complexity that can=20 > be supported with limited code size and limited RAM per node.=20 > More generally, we speak of constrained applications=20 > whenever at least some of the nodes and networks involved=20 > exhibit these characteristics. >=20 > Low-Power Wireless Personal Area Networks (LoWPANs) are an=20 > example of this type of network. These networks are becoming=20 > increasing important for applications such as home and=20 > building automation, energy management, and the Internet of=20 > Things. This working group will define a framework for a=20 > limited class of applications that deal with the manipulation=20 > of simple resources on constrained devices. This includes=20 > applications to monitor simple sensors (e.g. temperature=20 > sensors, light switches, and power meters) and control=20 > actuators (e.g. light switches, heating controllers, and door locks). >=20 > The general architecture consists of nodes on the constrained=20 > network, called Devices, that have one or more Resources that=20 > may represent sensors, actuators, or other values. Devices=20 > send messages to change and query resources on other Devices.=20 > Devices can send notifications about changed resource values=20 > to Devices that have subscribed to receive notification about=20 > changes. As part of the framework for building these=20 > applications, the WG will define a Constrained-node/network=20 > Application Protocol (CoAP) for the manipulation of Resources=20 > on a Device. The framework will also specify a way to define=20 > new interface profiles that vendors and other standards=20 > bodies can use to define the particular Resources on a Device=20 > and what manipulations are possible. >=20 > CoAP will be designed to be used between Devices on the same=20 > constrained network, between Devices and general nodes on the=20 > internet, and between devices on different constrained=20 > networks both joined to the internet. >=20 > There also may be nodes called=20 > Constrained-to-General-Internet Intermediaries (CoGII) that=20 > interconnect between other protocols typically used by=20 > applications on the internet and the Devices using the CoAP=20 > protocol. The WG will define a mapping on the CoGII from=20 > CoAP to an HTTP REST API; this mapping will not depend on a=20 > specific application. Each interface profile will define the=20 > Resources on the Device that applications can manipulate and=20 > what manipulations are possible. This will determine, in a=20 > mechanical translation way, the HTTP REST APIs on the CoGIIs=20 > and the CoAP protocol encoding to manipulate the Resources on=20 > the Device; it will also specify an XML MIME type for each=20 > class of Device that can be used to describe the Resource=20 > state in the body of HTTP REST messages. It is worth noting=20 > that the CoGII does not have to be deployed at the boundary=20 > of the constrained network and the more general network but=20 > can be deployed at various locations in the unconstrained network. >=20 > CoGIIs can provide various forms of "caching". For example,=20 > if a temperature sensor is normally asleep but wakes up every=20 > five minutes and sends the current temperature to a CoGII=20 > that has subscribed, when the CoGII receives a request over=20 > HTTP for that temperature resource, it can respond with the=20 > last seen value instead of trying to query the Device which=20 > is currently asleep. The CoGIIs may also provide support for=20 > discovering Devices that may not be currently responding as=20 > they are temporarily asleep. >=20 > The initial work items of the WG is to define a protocol=20 > specification for CoAP that includes: >=20 > 1) A way to define the "interface profile" that specifies the=20 > Resources > for a Device and implies the REST API that can be used >=20 > 2) The ability to set and query a resource on a Device. >=20 > 3) The ability to allow a Device to publish a value or event=20 > to another > Device that has subscribed to be notified of changes, as=20 > well as the > way for a Device to subscribe to receive publishes from another > Device. >=20 > 4) The ability to support a non-reliable multicast message to=20 > be sent to > a group of Devices to manipulate a resource on all the Devices > simultaneously. The goals would be delivery of messages roughly > within 50 ms of each other for closely located Devices on suitable > networks to meet the use case of several lights appearing=20 > to turn on > at the same time to a human observer. >=20 > 5) Default operation of the protocol will be over UDP; it may=20 > optionally > use TCP or other reliable transports. > =20 > 6) A definition of how to use CoAP to discover Devices on the > constrained network, and to interrogate them to find out which > interface profiles they support. The name taxonomy used for > discovery will be consistent with the approach defined in > draft-cheshire-dnsext-dns-sd. >=20 > 7) An ability for Devices to provide a pointer to the general schema > information so that a CoGII does not need any code changes=20 > to support > new Device classes. >=20 > 8) Specification for the HTTP REST based API and mapping on=20 > the CoGII to > communicate with Devices. >=20 > The working group will not develop a reliable multicast solution. >=20 > Security, particularly keying of new Devices, is very=20 > challenging for these applications. On one hand this needs to=20 > support models in which an end user can introduce onto their=20 > network a new Device that may have no display or input=20 > capabilities. On the other hand, this protocol may transport=20 > information about alarm systems or controlling door locks=20 > over a wireless network. >=20 > The WG will work to support methods of security bootstrapping=20 > which are realistic given the constraints and requirements of=20 > the network. These methods are not specific to any=20 > communication layer. Instead the methods could run across any=20 > layer, including IP. Requirements considered > include: >=20 > 1) The methods need to be suitable for use on resource constrained > nodes. These constraints include power, cost, size, and=20 > computational > capacity. [[ Note: the WG realizes the vagueness of this constraint > but does not currently have consensus on a more quantitative metric > of these constraints ]] >=20 > 2) The methods need to provide sufficient security for the application > space. >=20 > 3) The methods must guarantee that any two nodes can join=20 > together. This > includes nodes which are already on separate networks which a user > wishes to merge together. >=20 > 4) There may be additional requirements for each application=20 > space, such > as urban or commercial environments which deploy large networks, > compared to residential environments. >=20 > To ensure that any two nodes can join together, all nodes=20 > must implement at least one universal method. In additional=20 > several other methods will be specified which take advantage=20 > of the application space. In commercial applications, for=20 > instance, bootstrapping can take advantage of the fact that=20 > networks are typically managed from a central authority, and=20 > a method optimized for residential usage might take advantage=20 > of the fact that nodes are in close proximity. >=20 > Methods which will be considered include: >=20 > 1) Out of Band Key or Certificate: In this mode a key (either=20 > symmetric > or asymmetric) is distributed with the product, such as a=20 > 2D barcode > printed on the node. The user can scan this key with a computer to > give access to this node. >=20 > 2) Physical Button Protocol: In this mode two nodes only require > pushbuttons and LEDs, and the user simply pushes the button on each > node within a narrow time window to join them together. >=20 > 3) Out of Band Communication Link: This could include IrDA or=20 > NFC (Near > Field Communication) type technologies to allow a device to join > another device that is physically nearby. >=20 > 4) Out of Band Configuration: A simple example of this would be using > the programming interface which a node uses to download firmware. >=20 > This list should not be considered exhaustive, and methods=20 > may be removed or added as additional application spaces and=20 > requirements are found. The list gives examples of the types=20 > of methods to be investigated. >=20 > Security can be achieved using other session security or=20 > object security. For session security, the WG will work with=20 > the security area to select cipher suites most useful for=20 > constrained network. For object security, CoAP will=20 > initially look at CMS (RFC 5652). >=20 > The WG will coordinate on requirements from many=20 > organizations including OpenSG/NIST, ZigBee/HomePlug, IPSO=20 > Alliance, OASIS, SENSEI; other SDOs and organizations. The WG=20 > will closely coordinate with other IETF WGs including ROLL,=20 > 6LoWPAN, and appropriate groups in the IETF OPS and Security areas. >=20 > Milestones: >=20 > Mar 2010 - Select WG document for basis of CoAP protocol >=20 > Dec 2010 - CoAP protocol specification with mapping to HTTP Rest API > 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 fluffy@cisco.com Mon Jan 25 09:38: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 595C33A67E7 for <6lowapp@core3.amsl.com>; Mon, 25 Jan 2010 09:38:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.299 X-Spam-Level: X-Spam-Status: No, score=-109.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 NYaDmzcuz1Vd for <6lowapp@core3.amsl.com>; Mon, 25 Jan 2010 09:38:02 -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 025F13A6407 for <6lowapp@ietf.org>; Mon, 25 Jan 2010 09:38:02 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.49,340,1262563200"; d="scan'208";a="235222151" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 25 Jan 2010 17:38:08 +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 o0PHc7so001768; Mon, 25 Jan 2010 17:38:08 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: <0C0AF10C-85F8-4401-BFB0-441CD08F067E@cisco.com> Date: Mon, 25 Jan 2010 10:38:06 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8CFA798E-123D-4A10-8961-8D47B3EE3A34@cisco.com> References: <0C0AF10C-85F8-4401-BFB0-441CD08F067E@cisco.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1077) Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Revised Charter Proposal 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, 25 Jan 2010 17:38:03 -0000 I think I made one (or at least one) big mistake in this charter update. = At the end of the BOF, there was clear consensus to make the initial = charter thorough out everything but the minimal approach. (Basically Ted = Hardie's proposal). I thought I had done this but realize in going back = and listening to the BOF recording that this included leaving the = discovery stuff to a later time. I think I need to update the charter to = move the discovery work to not be in the initial scope of work.=20 On Jan 24, 2010, at 4:25 PM, Cullen Jennings wrote: >=20 > I tired to incorporate the discussion on the list and the discussion = from he BOF into a revised charter proposal. I'd like to see if there = were any feedback early this week then, if things look like this charter = is close, send this to Lisa (our AD) and see if this can make it on the = next IESG call.=20 >=20 > Cullen >=20 > ---------------------- >=20 >=20 > CoRE >=20 > Applications are being developed for IP networks that have very = limited > packet sizes, exhibit a high degree of packet loss, and have = 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 applications whenever at least some > of the nodes and networks involved exhibit these characteristics. >=20 > Low-Power Wireless Personal Area Networks (LoWPANs) are an example of > this type of network. These networks are becoming increasing important > for applications such as home and building automation, energy > management, and the Internet of Things. This working group will define = a > framework for a limited class of applications that deal with the > manipulation of simple resources on constrained devices. This includes > applications to monitor simple sensors (e.g. temperature sensors, = light > switches, and power meters) and control actuators (e.g. light = switches, > heating controllers, and door locks). >=20 > The general architecture consists of nodes on the constrained network, > called Devices, that have one or more Resources that may represent > sensors, actuators, or other values. 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. As part of the framework for building = these > applications, the WG will define a Constrained-node/network = Application > Protocol (CoAP) for the manipulation of Resources on a Device. The > framework will also specify a way to define new interface profiles = that > vendors and other standards bodies can use to define the particular > Resources on a Device and what manipulations are possible. >=20 > CoAP will be designed to be used between Devices on the same = constrained > network, between Devices and general nodes on the internet, and = between > devices on different constrained networks both joined to the internet. >=20 > There also may be nodes called Constrained-to-General-Internet > Intermediaries (CoGII) that interconnect between other protocols > typically used by applications on the internet and the Devices using = the > CoAP protocol. The WG will define a mapping on the CoGII from CoAP to > an HTTP REST API; this mapping will not depend on a specific > application. Each interface profile will define the Resources on the > Device that applications can manipulate and what manipulations are > possible. This will determine, in a mechanical translation way, the > HTTP REST APIs on the CoGIIs and the CoAP protocol encoding to > manipulate the Resources on the Device; it will also specify an XML = MIME > type for each class of Device that can be used to describe the = Resource > state in the body of HTTP REST messages. It is worth noting that the > CoGII does not have to be deployed at the boundary of the constrained > network and the more general network but can be deployed at various > locations in the unconstrained network. >=20 > CoGIIs can provide 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 CoGII that has subscribed, when > the CoGII 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. The CoGIIs may also provide support > for discovering Devices that may not be currently responding as they = are > temporarily asleep. >=20 > The initial work items of the WG is to define a protocol specification > for CoAP that includes: >=20 > 1) A way to define the "interface profile" that specifies the = Resources > for a Device and implies the REST API that can be used >=20 > 2) The ability to set and query a resource on a Device. >=20 > 3) 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 > 4) 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 > simultaneously. The goals would be delivery of messages roughly > within 50 ms of each other for closely located Devices on suitable > networks to meet the use case of several lights appearing to turn on > at the same time to a human observer. >=20 > 5) Default operation of the protocol will be over UDP; it may = optionally > use TCP or other reliable transports. >=20 > 6) A definition of how to use CoAP to discover Devices on the > constrained network, and to interrogate them to find out which > interface profiles they support. The name taxonomy used for > discovery will be consistent with the approach defined in > draft-cheshire-dnsext-dns-sd. >=20 > 7) An ability for Devices to provide a pointer to the general schema > information so that a CoGII does not need any code changes to = support > new Device classes. >=20 > 8) Specification for the HTTP REST based API and mapping on the CoGII = to > communicate with Devices. >=20 > The working group will not develop a reliable multicast solution. >=20 > Security, particularly keying of new Devices, is very challenging for > these applications. On one hand this needs to support models in which = an > end user can introduce onto their network a new Device that may have = no > display or input capabilities. On the other hand, this protocol may > transport information about alarm systems or controlling door locks = over > a wireless network. >=20 > The WG will work to support methods of security bootstrapping which = are > realistic given the constraints and requirements of the network. These > methods are not specific to any communication layer. Instead the = methods > could run across any layer, including IP. Requirements considered > include: >=20 > 1) The methods need to be suitable for use on resource constrained > nodes. These constraints include power, cost, size, and = computational > capacity. [[ Note: the WG realizes the vagueness of this constraint > but does not currently have consensus on a more quantitative metric > of these constraints ]] >=20 > 2) The methods need to provide sufficient security for the application > space. >=20 > 3) The methods must guarantee that any two nodes can join together. = This > includes nodes which are already on separate networks which a user > wishes to merge together. >=20 > 4) There may be additional requirements for each application space, = such > as urban or commercial environments which deploy large networks, > compared to residential environments. >=20 > To ensure that any two nodes can join together, all nodes must = implement > at least one universal method. In additional several other methods = will > be specified which take advantage of the application space. In > commercial applications, for instance, bootstrapping can take = advantage > of the fact that networks are typically managed from a central > authority, and a method optimized for residential usage might take > advantage of the fact that nodes are in close proximity. >=20 > Methods which will be considered include: >=20 > 1) Out of Band Key or Certificate: In this mode a key (either = symmetric > or asymmetric) is distributed with the product, such as a 2D barcode > printed on the node. The user can scan this key with a computer to > give access to this node. >=20 > 2) Physical Button Protocol: In this mode two nodes only require > pushbuttons and LEDs, and the user simply pushes the button on each > node within a narrow time window to join them together. >=20 > 3) Out of Band Communication Link: This could include IrDA or NFC = (Near > Field Communication) type technologies to allow a device to join > another device that is physically nearby. >=20 > 4) Out of Band Configuration: A simple example of this would be using > the programming interface which a node uses to download firmware. >=20 > This list should not be considered exhaustive, and methods may be > removed or added as additional application spaces and requirements are > found. The list gives examples of the types of methods to be > investigated. >=20 > Security can be achieved using other session security or object > security. For session security, the WG will work with the security = area > to select cipher suites most useful for constrained network. For = object > security, CoAP will initially look at CMS (RFC 5652). >=20 > The WG will coordinate on requirements from many organizations = including > OpenSG/NIST, ZigBee/HomePlug, IPSO Alliance, OASIS, SENSEI; 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 > Mar 2010 - Select WG document for basis of CoAP protocol >=20 > Dec 2010 - CoAP protocol specification with mapping to HTTP Rest API > 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 From fluffy@cisco.com Mon Jan 25 09:39:33 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 C29AD3A6774 for <6lowapp@core3.amsl.com>; Mon, 25 Jan 2010 09:39:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.732 X-Spam-Level: X-Spam-Status: No, score=-109.732 tagged_above=-999 required=5 tests=[AWL=0.867, 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 ltowELYQm4pQ for <6lowapp@core3.amsl.com>; Mon, 25 Jan 2010 09:39:33 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 20C603A6407 for <6lowapp@ietf.org>; Mon, 25 Jan 2010 09:39:33 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAMdlXUurR7Ht/2dsb2JhbADFPJVxhDsEjWI X-IronPort-AV: E=Sophos;i="4.49,340,1262563200"; d="scan'208";a="78826407" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 25 Jan 2010 17:39:40 +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 o0PHddML003624; Mon, 25 Jan 2010 17:39:39 GMT Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=windows-1252 Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <777549F2-4155-4CCF-8246-D394480D49F1@cs.columbia.edu> Date: Mon, 25 Jan 2010 10:39:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <306E6BB7-91D0-4108-BAE1-DFE5B4A73D88@cisco.com> References: <0C0AF10C-85F8-4401-BFB0-441CD08F067E@cisco.com> <777549F2-4155-4CCF-8246-D394480D49F1@cs.columbia.edu> To: Henning Schulzrinne X-Mailer: Apple Mail (2.1077) Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Revised Charter Proposal 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, 25 Jan 2010 17:39:33 -0000 Makes sense - do you want to propose another bullet point for this one = or a modification of one of the existing bullet points to cover it ? On Jan 24, 2010, at 5:13 PM, Henning Schulzrinne wrote: > For the configuration part, there is significant existing work, as = part of the Wi-Fi Protected Setup=99 ("Facilitates easy set-up of = security features using a Personal Identification Number (PIN) or other = defined methods within the Wi-Fi device"). Not sure this needs to be = called out explicitly, but somebody may want to make sure we don't rule = out reasonable mechanisms that seem to have widespread support in a = similar scenario elsewhere. From fluffy@cisco.com Mon Jan 25 10:14:37 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 282803A6857 for <6lowapp@core3.amsl.com>; Mon, 25 Jan 2010 10:14:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.949 X-Spam-Level: X-Spam-Status: No, score=-109.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 AmSeGgSbuvjy for <6lowapp@core3.amsl.com>; Mon, 25 Jan 2010 10:14:34 -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 AC7403A686C for <6lowapp@ietf.org>; Mon, 25 Jan 2010 10:14:34 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.49,340,1262563200"; d="scan'208";a="235235525" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 25 Jan 2010 18:14:41 +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 o0PIEevo006290; Mon, 25 Jan 2010 18:14:40 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: <0C0AF10C-85F8-4401-BFB0-441CD08F067E@cisco.com> Date: Mon, 25 Jan 2010 11:14:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <65471FC2-C8CE-4208-86D9-6D710E09FA89@cisco.com> References: <0C0AF10C-85F8-4401-BFB0-441CD08F067E@cisco.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1077) Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Revised Charter Proposal - Security 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, 25 Jan 2010 18:14:37 -0000 Some comments on Security section rewrite ideas inline .... On Jan 24, 2010, at 4:25 PM, Cullen Jennings wrote: > Security, particularly keying of new Devices, is very challenging for > these applications. On one hand this needs to support models in which = an > end user can introduce onto their network a new Device that may have = no > display or input capabilities. On the other hand, this protocol may > transport information about alarm systems or controlling door locks = over > a wireless network. >=20 > The WG will work to support methods of security bootstrapping which = are > realistic given the constraints and requirements of the network. These > methods are not specific to any communication layer. Instead the = methods > could run across any layer, including IP. Requirements considered > include: >=20 > 1) The methods need to be suitable for use on resource constrained > nodes. These constraints include power, cost, size, and = computational > capacity. [[ Note: the WG realizes the vagueness of this constraint > but does not currently have consensus on a more quantitative metric > of these constraints ]] thought this is true, hard to see how it constrains the WG or specifies = what needs to happen.=20 >=20 > 2) The methods need to provide sufficient security for the application > space. This does not really mean much - clearly true.=20 >=20 > 3) The methods must guarantee that any two nodes can join together. = This > includes nodes which are already on separate networks which a user > wishes to merge together. Could we just say it as there much be a security mandatory to implement = way security mechanism. As far as I can tell, all we are saying is we = will follow rules of BCP 61 here.=20 >=20 > 4) There may be additional requirements for each application space, = such > as urban or commercial environments which deploy large networks, > compared to residential environments. Not sure what this implies to work in the WG. Agree it is true, but what = do we need to say in the charter.=20 >=20 > To ensure that any two nodes can join together, all nodes must = implement > at least one universal method. In additional several other methods = will > be specified which take advantage of the application space. In > commercial applications, for instance, bootstrapping can take = advantage > of the fact that networks are typically managed from a central > authority, and a method optimized for residential usage might take > advantage of the fact that nodes are in close proximity. >=20 > Methods which will be considered include: >=20 > 1) Out of Band Key or Certificate: In this mode a key (either = symmetric > or asymmetric) is distributed with the product, such as a 2D barcode > printed on the node. The user can scan this key with a computer to > give access to this node. >=20 > 2) Physical Button Protocol: In this mode two nodes only require > pushbuttons and LEDs, and the user simply pushes the button on each > node within a narrow time window to join them together. >=20 > 3) Out of Band Communication Link: This could include IrDA or NFC = (Near > Field Communication) type technologies to allow a device to join > another device that is physically nearby. >=20 > 4) Out of Band Configuration: A simple example of this would be using > the programming interface which a node uses to download firmware. >=20 > This list should not be considered exhaustive, and methods may be > removed or added as additional application spaces and requirements are > found. The list gives examples of the types of methods to be > investigated. >=20 > Security can be achieved using other session security or object > security. For session security, the WG will work with the security = area > to select cipher suites most useful for constrained network. For = object > security, CoAP will initially look at CMS (RFC 5652). From fluffy@cisco.com Mon Jan 25 10:15:37 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 1296A28C0D7 for <6lowapp@core3.amsl.com>; Mon, 25 Jan 2010 10:15:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.079 X-Spam-Level: X-Spam-Status: No, score=-110.079 tagged_above=-999 required=5 tests=[AWL=0.520, 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 qPQtiK71NpcU for <6lowapp@core3.amsl.com>; Mon, 25 Jan 2010 10:15:36 -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 D1AE33A688D for <6lowapp@ietf.org>; Mon, 25 Jan 2010 10:15:35 -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: ApoEAK9uXUurR7H+/2dsb2JhbADFHpVyhDsE X-IronPort-AV: E=Sophos;i="4.49,340,1262563200"; d="scan'208";a="472526782" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 25 Jan 2010 18:15:42 +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 o0PIEevp006290; Mon, 25 Jan 2010 18:15:41 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: Mon, 25 Jan 2010 11:15:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0C0AF10C-85F8-4401-BFB0-441CD08F067E@cisco.com> To: Lars Eggert X-Mailer: Apple Mail (2.1077) Cc: "6lowapp@ietf.org" <6lowapp@ietf.org> Subject: Re: [6lowapp] Revised Charter Proposal 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, 25 Jan 2010 18:15:37 -0000 Thanks Lars, few comments inline .... On Jan 25, 2010, at 12:26 AM, Lars Eggert wrote: > Hi, >=20 > looks pretty good. A few comments:=20 >=20 > In general, I'm missing a statement that this will use the 6LOWPAN and = ROLL way of doing IPv6 over these links rather than some other way, or - = even worse - IPv4. (The coordination text has some words about 6LOWPAN = and ROLL, but nothing that I read as "6LOWPAN will use their stuff.) Everything I have heard in every so far about what people want to = develop here is just it will run on an IP network. That would include = IPv4, IPv6, and a 6LowPAN network and other networks where UDP, TCP, or = whatever transport we use would work. I'm not sure how to phrase that in = the charter but can you come up with some words that reflect that?=20 >=20 > On 2010-1-25, at 0:25, Cullen Jennings wrote: >> 4) 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 >> simultaneously. The goals would be delivery of messages roughly >> within 50 ms of each other for closely located Devices on suitable >> networks to meet the use case of several lights appearing to turn on >> at the same time to a human observer. >=20 > Doesn't apply this magic 50ms number also to unicast traffic? More = importantly though, there is not much that CoAP can do in guaranteeing = that delay; it seems to be almost entirely dependent on the underlying = routing, radio and sensor technologies. Yep, I've received multiple comments that amount to IP guarantees = nothing about making anything happened in 50 ms. I think we should = remove this but I'd like to figure out some way of saying it's a goal to = be able to use this as part of an overall system that can get things to = happen "simultaneously" from human point of view. Take RTP for example. = Clearly RTP can be deployed on many IP networks and have a realtime = experience that is "same time" from human point of view (i.e., audio = with less than 150 ms of latency). I'm no sure how to phrase that type = of goal. Ideas ? >=20 >> 5) Default operation of the protocol will be over UDP; it may = optionally >> use TCP or other reliable transports. >=20 > I think we need to rephrase this bullet. I don't think you mean = "optionally, TCP can be used in stead of UDP" when you say "it may = optionally...", but it can be misread in this way. >=20 > Also, while folks have demonstrated that you can run TCP at acceptable = performance in some deployments, I believe that these deployments have = been very controlled in terms of their topology, radio configuration, = routing setup, etc. *In such cases* CoAP could optionally partially use = TCP for some operations, but in most deployments (esp. "unmanaged" home = deployments) this will simply not work very well. All the essential = functions of CoAP must IMO therefore run over UDP. I think most people agree with what you are saying here. Help me get the = text to be very clear about what we intended to do. How about something = like=20 5) The mandatory to implement transport for the protocol will be UDP. = The WG may choose to specific additional transport protocols.=20 Anyone else willing to write some replacement text here ? >=20 >> 4) There may be additional requirements for each application space, = such >> as urban or commercial environments which deploy large networks, >> compared to residential environments. >=20 > Must CoAP support these application spaces from the beginning? If some = of the yet-unstated requirements for these app spaces are conflicting, = it's really easy for the WG to wedge itself, because the design space = for the solution becomes the empty set. >=20 > Or is the paragraph above still about bootstrapping methods? Segway: I = think you should explicitly say "bootstrapping method" in almost all = places where you currently say "method" to make it clear whether that is = what you mean. And if not, use a different word :-) >=20 >> Security can be achieved using other session security or object >> security. For session security, the WG will work with the security = area >> to select cipher suites most useful for constrained network. For = object >> security, CoAP will initially look at CMS (RFC 5652). >=20 > For session security, you not only need ciphers, you also need a = protocol. Is the intent that you'd use TLS/DTLS? Then please say so. So my two cents an individual contributor ... The WG is definitely not = proposing to invent anything new. It would select something like = TLS/DTLS and/or CMS and then also say a set of mandatory to implement = ciphers. This would likely be a very minimal set. The more I look at = this, and the fact that it needs to gateway from CoAP to HTTP, the more = I become convinced that the value of session based security is somewhat = limited and we really need object based security here but I don't know = that many folks agree with me on that. I had pushed the previous text a = bit that was very constraining on what we would do for security as a way = to speed things up. People proposed text on the list (which I = paraphrased roughly into the current charter) that was much less = constraining and more like exploitative of things that could be tried. = My read of folks involved is that something like current text is what = most people could live wish but clearly we need to tighten this up a = bunch.=20 >=20 > Lars >=20 From fluffy@cisco.com Mon Jan 25 10:31:51 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 B315328C0EA for <6lowapp@core3.amsl.com>; Mon, 25 Jan 2010 10:31:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.166 X-Spam-Level: X-Spam-Status: No, score=-110.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 OYaoG+weKDAu for <6lowapp@core3.amsl.com>; Mon, 25 Jan 2010 10:31:50 -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 C4ED228C0CE for <6lowapp@ietf.org>; Mon, 25 Jan 2010 10:31:50 -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: ApoEAD1yXUurR7H+/2dsb2JhbADFIolVCIw5giYeCIFvBA X-IronPort-AV: E=Sophos;i="4.49,340,1262563200"; d="scan'208";a="292062452" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 25 Jan 2010 18:31:57 +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 o0PIVuc7022626; Mon, 25 Jan 2010 18:31:57 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: Mon, 25 Jan 2010 11:31:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0C0AF10C-85F8-4401-BFB0-441CD08F067E@cisco.com> To: "Romascanu, Dan (Dan)" X-Mailer: Apple Mail (2.1077) Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Revised Charter Proposal 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, 25 Jan 2010 18:31:51 -0000 On Jan 25, 2010, at 2:44 AM, Romascanu, Dan (Dan) wrote: > Cullen, >=20 > Good start, I have a few observations:=20 >=20 > - there is a lot of standardization activity in this area. Beyond what > is already mentioned in the charter I know about IEEE P802.3az doing > significant work in the Energy-Efficient Ethernet Task Force, Henning > mentioned WiFi. We need to understand what 'The WG will coordinate on > requirements' means. If something is developped by another SDO do we > need to replicate the work in the IETF? Maybe yes in some cases, if = the > work is for example layer 2 specific.=20 Yah, my experience with the words "coordinate" in charters has not = exactly been good. Lets get specific about what you think this WG should = do. It would definitely not be developing any layer 2 or 3. I'm not = seeing how this has much to do with the P802.3az stuff (other than it = very well may be running on a network using that). I think the WiFi = comment was more about lets not reinvent a enrollment model if we can = just use the technique developed by some people that put a huge amount = of time into. I totally agree with Henning on that so I expect to update = text a bit.=20 One really good thing about coordination, I know that both Henning and = Zack are going to closely follow this work and they are both on the = Smart Grid Directorate that will help coordinate with other SDOs so I am = confident things will not slip through the cracks.=20 > - The milestone 'Mar 2010 - Select WG document for basis of CoAP > protocol' is completely unrealistic taking onto account that the = charter > is not yet in IESG review I don't believe in dates in charters :-) but yes, agree. It seems that = we might be abel to do this shortly after the March meeting depending on = how that meeting goes. What date do people want to put in? makes no = difference to me.=20 > - The operational and manageability aspects are not mentioned, = excepting > firmware updates. They are implied in some of the capabilities like > querying resources, but I think that observability of device presence > and operational status query should be mentioned explicitly.=20 OK. Let me make an analogy of this work is a bit like we are defining a = protocol like http here and not the protocol one would necessarily use = to to manger a web server system. Agree we need to say more around ops = and management but not sure what to say. Can you help me figure out what = to say. Given the discussion in the BOF, we need to make sure what = whatever we add it does not require Devices to be powered on at all = times and we need to be sure that it does not require a way to enumerate = all the Devices on the system as that is a discovery problem that is = explicitly out of scope for now.=20 >=20 > Dan From fluffy@cisco.com Mon Jan 25 10:37:27 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 389923A6878 for <6lowapp@core3.amsl.com>; Mon, 25 Jan 2010 10:37:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.228 X-Spam-Level: X-Spam-Status: No, score=-110.228 tagged_above=-999 required=5 tests=[AWL=0.371, 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 E3HIQTryMviT for <6lowapp@core3.amsl.com>; Mon, 25 Jan 2010 10:37:26 -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 94A7D3A67E9 for <6lowapp@ietf.org>; Mon, 25 Jan 2010 10:37:26 -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: ApoEAF5zXUurR7Ht/2dsb2JhbADFKpYWhDsE X-IronPort-AV: E=Sophos;i="4.49,340,1262563200"; d="scan'208";a="292065104" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 25 Jan 2010 18:37:33 +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 o0PIbXRS028383 for <6lowapp@ietf.org>; Mon, 25 Jan 2010 18:37:33 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: <0C0AF10C-85F8-4401-BFB0-441CD08F067E@cisco.com> Date: Mon, 25 Jan 2010 11:37:32 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0C0AF10C-85F8-4401-BFB0-441CD08F067E@cisco.com> To: 6lowapp@ietf.org X-Mailer: Apple Mail (2.1077) Subject: Re: [6lowapp] Revised Charter Proposal - CoGII 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, 25 Jan 2010 18:37:27 -0000 Other request for ideas on charter improvement .... Can someone come up with abetter name than CoGII. It's causing confusion = and hard to pronounce or remember.=20 From kerlyn2001@gmail.com Mon Jan 25 10:42: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 0CF7428C0FE for <6lowapp@core3.amsl.com>; Mon, 25 Jan 2010 10:42:54 -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 FM7gNqxRrrf9 for <6lowapp@core3.amsl.com>; Mon, 25 Jan 2010 10:42:53 -0800 (PST) Received: from mail-ew0-f216.google.com (mail-ew0-f216.google.com [209.85.219.216]) by core3.amsl.com (Postfix) with ESMTP id 0D63028C0FC for <6lowapp@ietf.org>; Mon, 25 Jan 2010 10:42:52 -0800 (PST) Received: by ewy8 with SMTP id 8so4513377ewy.29 for <6lowapp@ietf.org>; Mon, 25 Jan 2010 10:42:56 -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=hJ1qsLS2fls/SMIDh+EZsOzcAQwk7HxKfupiRW6yRWg=; b=Rkxjsj8TWoYvWBUbQQLfxTijRJXy010QlrKj2QOqHsGtaPzZdbuMJbSW5kgHqpziBw PA3BWBePQ7lZhRP26MIartlXHjKjbiFFGbhX9gPMcJ7SARuNZ29xIIf9eh0Gnk4nLLnc buidaiL/QQt1mA+HyceJA4ng1vnGXBBqyMoEE= 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=ht+qoS7K9pB3NCT9BUwefHHym21o490qKY7NZ6YqKcZn+HK9QcjimmsupuucfqHPr2 PEF68Y5Wm8ZzBYYUjxTUlZR7YKHE/kkkCkDWM9Tq8ST9NEpF6oiUaXOcIuexG+2ehf2i rQT1BqwsMXjg9bytfvaxQNcYhF/KvZBgywuS8= MIME-Version: 1.0 Received: by 10.216.86.3 with SMTP id v3mr137377wee.165.1264444976402; Mon, 25 Jan 2010 10:42:56 -0800 (PST) In-Reply-To: <8CFA798E-123D-4A10-8961-8D47B3EE3A34@cisco.com> References: <0C0AF10C-85F8-4401-BFB0-441CD08F067E@cisco.com> <8CFA798E-123D-4A10-8961-8D47B3EE3A34@cisco.com> Date: Mon, 25 Jan 2010 13:42:56 -0500 Message-ID: <3fe58b591001251042h3c8ef221hdb1716405fd10d91@mail.gmail.com> From: Kerry Lynn To: Cullen Jennings Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Revised Charter Proposal 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, 25 Jan 2010 18:42:54 -0000 Cullen, I, for one, am nervous about deferring a naming and discovery approach and feel that this is important to interoperable implementations. Not sure I see the value of creating a framework for defining new profiles and interface objects, if there's no consistent way to name and discover them. Regards, -K- On Mon, Jan 25, 2010 at 12:38 PM, Cullen Jennings wrote: > > I think I made one (or at least one) big mistake in this charter update. = At the end of the BOF, there was clear consensus to make the initial charte= r thorough out everything but the minimal approach. (Basically Ted Hardie's= proposal). I thought I had done this but realize in going back and listeni= ng to the BOF recording that this included leaving the discovery stuff to a= later time. I think I need to update the charter to move the discovery wor= k to not be in the initial scope of work. > From lars.eggert@nokia.com Mon Jan 25 10:44: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 5A43C3A67F2 for <6lowapp@core3.amsl.com>; Mon, 25 Jan 2010 10:44:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 2YICgVaqMR5K for <6lowapp@core3.amsl.com>; Mon, 25 Jan 2010 10:44:05 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 08AFE3A67F0 for <6lowapp@ietf.org>; Mon, 25 Jan 2010 10:44:04 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0PIhEJR024691; Mon, 25 Jan 2010 12:43:30 -0600 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Jan 2010 20:43:28 +0200 Received: from mgw-sa01.ext.nokia.com ([147.243.1.47]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Jan 2010 20:43:29 +0200 Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa01.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0PIhRd9028986 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Jan 2010 20:43:27 +0200 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.95.3 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/signed; boundary=Apple-Mail-15-522469533; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: Date: Mon, 25 Jan 2010 19:43:14 +0100 Message-Id: References: <0C0AF10C-85F8-4401-BFB0-441CD08F067E@cisco.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1077) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [0.0.0.0]); Mon, 25 Jan 2010 20:43:21 +0200 (EET) X-OriginalArrivalTime: 25 Jan 2010 18:43:29.0362 (UTC) FILETIME=[49745B20:01CA9DEE] X-Nokia-AV: Clean Cc: "6lowapp@ietf.org" <6lowapp@ietf.org> Subject: Re: [6lowapp] Revised Charter Proposal 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, 25 Jan 2010 18:44:06 -0000 --Apple-Mail-15-522469533 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2010-1-25, at 19:15, Cullen Jennings wrote: > On Jan 25, 2010, at 12:26 AM, Lars Eggert wrote: >> In general, I'm missing a statement that this will use the 6LOWPAN = and ROLL way of doing IPv6 over these links rather than some other way, = or - even worse - IPv4. (The coordination text has some words about = 6LOWPAN and ROLL, but nothing that I read as "6LOWPAN will use their = stuff.) >=20 > Everything I have heard in every so far about what people want to = develop here is just it will run on an IP network. That would include = IPv4, IPv6, and a 6LowPAN network and other networks where UDP, TCP, or = whatever transport we use would work. I'm not sure how to phrase that in = the charter but can you come up with some words that reflect that?=20 maybe the charter should simply say that 6LOWAPP targets a ROLL/6LOWPAN = environment with all its additional constraints compared to normal IP = networks, but that it is expected that the resulting CoAP protocol = should also operate over traditional IP networks? >> On 2010-1-25, at 0:25, Cullen Jennings wrote: >>> 4) 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 >>> simultaneously. The goals would be delivery of messages roughly >>> within 50 ms of each other for closely located Devices on suitable >>> networks to meet the use case of several lights appearing to turn on >>> at the same time to a human observer. >>=20 >> Doesn't apply this magic 50ms number also to unicast traffic? More = importantly though, there is not much that CoAP can do in guaranteeing = that delay; it seems to be almost entirely dependent on the underlying = routing, radio and sensor technologies. >=20 > Yep, I've received multiple comments that amount to IP guarantees = nothing about making anything happened in 50 ms. I think we should = remove this but I'd like to figure out some way of saying it's a goal to = be able to use this as part of an overall system that can get things to = happen "simultaneously" from human point of view. Take RTP for example. = Clearly RTP can be deployed on many IP networks and have a realtime = experience that is "same time" from human point of view (i.e., audio = with less than 150 ms of latency). I'm no sure how to phrase that type = of goal. Ideas ? You could say something like "non-reliable multicast delivery of CoAP = messages should have a performance that is close to the IP multicast = delivery performance achievable over the underlying IP topology?" (In = other words, CoAP is not a significant source of additional latency.) >>> 5) Default operation of the protocol will be over UDP; it may = optionally >>> use TCP or other reliable transports. >>=20 >> I think we need to rephrase this bullet. I don't think you mean = "optionally, TCP can be used in stead of UDP" when you say "it may = optionally...", but it can be misread in this way. >>=20 >> Also, while folks have demonstrated that you can run TCP at = acceptable performance in some deployments, I believe that these = deployments have been very controlled in terms of their topology, radio = configuration, routing setup, etc. *In such cases* CoAP could optionally = partially use TCP for some operations, but in most deployments (esp. = "unmanaged" home deployments) this will simply not work very well. All = the essential functions of CoAP must IMO therefore run over UDP. >=20 > I think most people agree with what you are saying here. Help me get = the text to be very clear about what we intended to do. How about = something like=20 >=20 > 5) The mandatory to implement transport for the protocol will be UDP. = The WG may choose to specific additional transport protocols. I'm not sure that this captures all of it. If UDP is mandatory to = implement and works well, there's really not a huge need to even use = other transports. I thought the main motivation for TCP was that some = operations (such as reliable delivery of a chunk of data larger than the = MTU) are difficult and/or slow over UDP. If that's the case, maybe we should say that the core CoAP functionality = MUST be operate well over UDP and that it MUST be implemented over UDP, = but that there are OPTIONAL functions in CoAP (e.g. delivery of larger = chunks of data) which if implemented are implemented over TCP. And then = point out that these functions are only expected to work under very = specific deployment scenarios and that hence applications needing those = OPTIONAL functions limit themselves to a narrow subset of deployment = cases. > Anyone else willing to write some replacement text here ? Yes, please bash this text. >>> 4) There may be additional requirements for each application space, = such >>> as urban or commercial environments which deploy large networks, >>> compared to residential environments. >>=20 >> Must CoAP support these application spaces from the beginning? If = some of the yet-unstated requirements for these app spaces are = conflicting, it's really easy for the WG to wedge itself, because the = design space for the solution becomes the empty set. >>=20 >> Or is the paragraph above still about bootstrapping methods? Segway: = I think you should explicitly say "bootstrapping method" in almost all = places where you currently say "method" to make it clear whether that is = what you mean. And if not, use a different word :-) The comment above is separate from the next one below. You might have = missed that and skipped over it - although minor, I want to make sure = that this doesn't fall through the cracks :-) >>> Security can be achieved using other session security or object >>> security. For session security, the WG will work with the security = area >>> to select cipher suites most useful for constrained network. For = object >>> security, CoAP will initially look at CMS (RFC 5652). >>=20 >> For session security, you not only need ciphers, you also need a = protocol. Is the intent that you'd use TLS/DTLS? Then please say so. >=20 > So my two cents an individual contributor ... The WG is definitely not = proposing to invent anything new. It would select something like = TLS/DTLS and/or CMS and then also say a set of mandatory to implement = ciphers. This would likely be a very minimal set. The more I look at = this, and the fact that it needs to gateway from CoAP to HTTP, the more = I become convinced that the value of session based security is somewhat = limited and we really need object based security here but I don't know = that many folks agree with me on that. I had pushed the previous text a = bit that was very constraining on what we would do for security as a way = to speed things up. People proposed text on the list (which I = paraphrased roughly into the current charter) that was much less = constraining and more like exploitative of things that could be tried. = My read of folks involved is that something like current text is what = most people could live wish but clearly we need to tighten this up a = bunch.=20 All makes sense. My main point is that security for CoAP will need not = only agreed on ciphers, but also a MUST-implement session- and/or = object-security *protocol*. Lars= --Apple-Mail-15-522469533 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTEwMDEyNTE4NDMxNVowIwYJKoZIhvcNAQkEMRYEFDeft/1IxBdCQaxKCOGXRDQSs9ZOMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQBMYSIXTvhkJDLTriuG1UVF9EtuV2XOsGxGOfm5nhTLabYdPKiJr02G9WNoBaHBAzuwr6DD ABp5+KeQqLfI+C5cklJUkaEkhoSId67qy8e2lzOlFKcXSiCicWTnBAtGobdvOmQ4sFkZr1M+PiLD AjBBhGlB8gPINDw8rcRMDKLaiqm4NifgVePfZDFubqThZfF+D713Ulemyr1xZWpl3vGew3S41DZG /0KaLUaGsHFutLY++vSbiCHAXXgzPplDuBKWC6Qy5HyLOwaj40BCmuB335UGF+exArYf7122H2Ac aVR3fpnbZzshz1FjueBp5SdNm8G4oxRrvlM5Zskp8dF5AAAAAAAA --Apple-Mail-15-522469533-- From zach@sensinode.com Mon Jan 25 12:20:25 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 765813A68F6 for <6lowapp@core3.amsl.com>; Mon, 25 Jan 2010 12:20:25 -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 DaeVQWpQToSm for <6lowapp@core3.amsl.com>; Mon, 25 Jan 2010 12:20:23 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id CC3043A67F0 for <6lowapp@ietf.org>; Mon, 25 Jan 2010 12:20:22 -0800 (PST) Received: from [192.168.1.3] (line-4832.dyn.kponet.fi [85.29.65.50]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o0PKKHPm018949 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 25 Jan 2010 22:20:18 +0200 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <8CFA798E-123D-4A10-8961-8D47B3EE3A34@cisco.com> Date: Mon, 25 Jan 2010 22:20:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <630AB01C-4590-4099-8D13-31F65032F809@sensinode.com> References: <0C0AF10C-85F8-4401-BFB0-441CD08F067E@cisco.com> <8CFA798E-123D-4A10-8961-8D47B3EE3A34@cisco.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1077) Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Revised Charter Proposal 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, 25 Jan 2010 20:20:25 -0000 On Jan 25, 2010, at 19:38 , Cullen Jennings wrote: >=20 > I think I made one (or at least one) big mistake in this charter = update. At the end of the BOF, there was clear consensus to make the = initial charter thorough out everything but the minimal approach. = (Basically Ted Hardie's proposal). I thought I had done this but realize = in going back and listening to the BOF recording that this included = leaving the discovery stuff to a later time. I think I need to update = the charter to move the discovery work to not be in the initial scope of = work.=20 Yep, the BOF message was definitely to keep the scope focused on CoAP = and reduce the number of work items. I would say that CoAP needs to have = a basic discovery mechanism which can then be used by others (SE 2.0, = DPWS etc.) or later by us to define the details. Thus we could leave out = the definition of profiles and how to use the discovery mechanism in my = opinion. Zach >=20 >=20 > On Jan 24, 2010, at 4:25 PM, Cullen Jennings wrote: >=20 >>=20 >> I tired to incorporate the discussion on the list and the discussion = from he BOF into a revised charter proposal. I'd like to see if there = were any feedback early this week then, if things look like this charter = is close, send this to Lisa (our AD) and see if this can make it on the = next IESG call.=20 >>=20 >> Cullen >>=20 >> ---------------------- >>=20 >>=20 >> CoRE >>=20 >> Applications are being developed for IP networks that have very = limited >> packet sizes, exhibit a high degree of packet loss, and have = 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 applications whenever at least = some >> of the nodes and networks involved exhibit these characteristics. >>=20 >> Low-Power Wireless Personal Area Networks (LoWPANs) are an example of >> this type of network. These networks are becoming increasing = important >> for applications such as home and building automation, energy >> management, and the Internet of Things. This working group will = define a >> framework for a limited class of applications that deal with the >> manipulation of simple resources on constrained devices. This = includes >> applications to monitor simple sensors (e.g. temperature sensors, = light >> switches, and power meters) and control actuators (e.g. light = switches, >> heating controllers, and door locks). >>=20 >> The general architecture consists of nodes on the constrained = network, >> called Devices, that have one or more Resources that may represent >> sensors, actuators, or other values. 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. As part of the framework for building = these >> applications, the WG will define a Constrained-node/network = Application >> Protocol (CoAP) for the manipulation of Resources on a Device. The >> framework will also specify a way to define new interface profiles = that >> vendors and other standards bodies can use to define the particular >> Resources on a Device and what manipulations are possible. >>=20 >> CoAP will be designed to be used between Devices on the same = constrained >> network, between Devices and general nodes on the internet, and = between >> devices on different constrained networks both joined to the = internet. >>=20 >> There also may be nodes called Constrained-to-General-Internet >> Intermediaries (CoGII) that interconnect between other protocols >> typically used by applications on the internet and the Devices using = the >> CoAP protocol. The WG will define a mapping on the CoGII from CoAP = to >> an HTTP REST API; this mapping will not depend on a specific >> application. Each interface profile will define the Resources on the >> Device that applications can manipulate and what manipulations are >> possible. This will determine, in a mechanical translation way, the >> HTTP REST APIs on the CoGIIs and the CoAP protocol encoding to >> manipulate the Resources on the Device; it will also specify an XML = MIME >> type for each class of Device that can be used to describe the = Resource >> state in the body of HTTP REST messages. It is worth noting that the >> CoGII does not have to be deployed at the boundary of the constrained >> network and the more general network but can be deployed at various >> locations in the unconstrained network. >>=20 >> CoGIIs can provide 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 CoGII that has subscribed, = when >> the CoGII 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. The CoGIIs may also provide support >> for discovering Devices that may not be currently responding as they = are >> temporarily asleep. >>=20 >> The initial work items of the WG is to define a protocol = specification >> for CoAP that includes: >>=20 >> 1) A way to define the "interface profile" that specifies the = Resources >> for a Device and implies the REST API that can be used >>=20 >> 2) The ability to set and query a resource on a Device. >>=20 >> 3) 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 >> 4) 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 >> simultaneously. The goals would be delivery of messages roughly >> within 50 ms of each other for closely located Devices on suitable >> networks to meet the use case of several lights appearing to turn on >> at the same time to a human observer. >>=20 >> 5) Default operation of the protocol will be over UDP; it may = optionally >> use TCP or other reliable transports. >>=20 >> 6) A definition of how to use CoAP to discover Devices on the >> constrained network, and to interrogate them to find out which >> interface profiles they support. The name taxonomy used for >> discovery will be consistent with the approach defined in >> draft-cheshire-dnsext-dns-sd. >>=20 >> 7) An ability for Devices to provide a pointer to the general schema >> information so that a CoGII does not need any code changes to = support >> new Device classes. >>=20 >> 8) Specification for the HTTP REST based API and mapping on the CoGII = to >> communicate with Devices. >>=20 >> The working group will not develop a reliable multicast solution. >>=20 >> Security, particularly keying of new Devices, is very challenging for >> these applications. On one hand this needs to support models in which = an >> end user can introduce onto their network a new Device that may have = no >> display or input capabilities. On the other hand, this protocol may >> transport information about alarm systems or controlling door locks = over >> a wireless network. >>=20 >> The WG will work to support methods of security bootstrapping which = are >> realistic given the constraints and requirements of the network. = These >> methods are not specific to any communication layer. Instead the = methods >> could run across any layer, including IP. Requirements considered >> include: >>=20 >> 1) The methods need to be suitable for use on resource constrained >> nodes. These constraints include power, cost, size, and = computational >> capacity. [[ Note: the WG realizes the vagueness of this constraint >> but does not currently have consensus on a more quantitative metric >> of these constraints ]] >>=20 >> 2) The methods need to provide sufficient security for the = application >> space. >>=20 >> 3) The methods must guarantee that any two nodes can join together. = This >> includes nodes which are already on separate networks which a user >> wishes to merge together. >>=20 >> 4) There may be additional requirements for each application space, = such >> as urban or commercial environments which deploy large networks, >> compared to residential environments. >>=20 >> To ensure that any two nodes can join together, all nodes must = implement >> at least one universal method. In additional several other methods = will >> be specified which take advantage of the application space. In >> commercial applications, for instance, bootstrapping can take = advantage >> of the fact that networks are typically managed from a central >> authority, and a method optimized for residential usage might take >> advantage of the fact that nodes are in close proximity. >>=20 >> Methods which will be considered include: >>=20 >> 1) Out of Band Key or Certificate: In this mode a key (either = symmetric >> or asymmetric) is distributed with the product, such as a 2D barcode >> printed on the node. The user can scan this key with a computer to >> give access to this node. >>=20 >> 2) Physical Button Protocol: In this mode two nodes only require >> pushbuttons and LEDs, and the user simply pushes the button on each >> node within a narrow time window to join them together. >>=20 >> 3) Out of Band Communication Link: This could include IrDA or NFC = (Near >> Field Communication) type technologies to allow a device to join >> another device that is physically nearby. >>=20 >> 4) Out of Band Configuration: A simple example of this would be using >> the programming interface which a node uses to download firmware. >>=20 >> This list should not be considered exhaustive, and methods may be >> removed or added as additional application spaces and requirements = are >> found. The list gives examples of the types of methods to be >> investigated. >>=20 >> Security can be achieved using other session security or object >> security. For session security, the WG will work with the security = area >> to select cipher suites most useful for constrained network. For = object >> security, CoAP will initially look at CMS (RFC 5652). >>=20 >> The WG will coordinate on requirements from many organizations = including >> OpenSG/NIST, ZigBee/HomePlug, IPSO Alliance, OASIS, SENSEI; 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 >> Mar 2010 - Select WG document for basis of CoAP protocol >>=20 >> Dec 2010 - CoAP protocol specification with mapping to HTTP Rest API >> 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 > _______________________________________________ > 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 Jan 25 12:22:55 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 DDFB83A68F6 for <6lowapp@core3.amsl.com>; Mon, 25 Jan 2010 12:22:55 -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 J8ESOP+s4cKI for <6lowapp@core3.amsl.com>; Mon, 25 Jan 2010 12:22:55 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 887FB3A68C0 for <6lowapp@ietf.org>; Mon, 25 Jan 2010 12:22:54 -0800 (PST) Received: from [192.168.1.3] (line-4832.dyn.kponet.fi [85.29.65.50]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o0PKMWRj018999 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 25 Jan 2010 22:22:33 +0200 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: Date: Mon, 25 Jan 2010 22:22:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2626D320-C47A-4EFC-BF5F-5CFD6C435BE8@sensinode.com> References: <0C0AF10C-85F8-4401-BFB0-441CD08F067E@cisco.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1077) Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Revised Charter Proposal - CoGII 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, 25 Jan 2010 20:22:56 -0000 On Jan 25, 2010, at 20:37 , Cullen Jennings wrote: >=20 > Other request for ideas on charter improvement .... >=20 > Can someone come up with abetter name than CoGII. It's causing = confusion and hard to pronounce or remember.=20 Forget about CoGIIs all together. We are only defining an HTTP mapping, = we don't have to define the entity where that is performed.=20 Zach >=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 Jan 25 12:31:50 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 6C4C03A691C for <6lowapp@core3.amsl.com>; Mon, 25 Jan 2010 12:31:50 -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 Frbvoj2+3bnh for <6lowapp@core3.amsl.com>; Mon, 25 Jan 2010 12:31:49 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 6AEC93A67D7 for <6lowapp@ietf.org>; Mon, 25 Jan 2010 12:31:48 -0800 (PST) Received: from [192.168.1.3] (line-4832.dyn.kponet.fi [85.29.65.50]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o0PKVjCb019214 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 25 Jan 2010 22:31:46 +0200 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: Date: Mon, 25 Jan 2010 22:31:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1B4D7C55-5021-4731-9C18-633846744AF7@sensinode.com> References: <0C0AF10C-85F8-4401-BFB0-441CD08F067E@cisco.com> To: Lars Eggert X-Mailer: Apple Mail (2.1077) Cc: "6lowapp@ietf.org" <6lowapp@ietf.org> Subject: Re: [6lowapp] Revised Charter Proposal 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, 25 Jan 2010 20:31:50 -0000 On Jan 25, 2010, at 20:43 , Lars Eggert wrote: > Hi, >=20 > On 2010-1-25, at 19:15, Cullen Jennings wrote: >> On Jan 25, 2010, at 12:26 AM, Lars Eggert wrote: >>> In general, I'm missing a statement that this will use the 6LOWPAN = and ROLL way of doing IPv6 over these links rather than some other way, = or - even worse - IPv4. (The coordination text has some words about = 6LOWPAN and ROLL, but nothing that I read as "6LOWPAN will use their = stuff.) >>=20 >> Everything I have heard in every so far about what people want to = develop here is just it will run on an IP network. That would include = IPv4, IPv6, and a 6LowPAN network and other networks where UDP, TCP, or = whatever transport we use would work. I'm not sure how to phrase that in = the charter but can you come up with some words that reflect that?=20 >=20 > maybe the charter should simply say that 6LOWAPP targets a = ROLL/6LOWPAN environment with all its additional constraints compared to = normal IP networks, but that it is expected that the resulting CoAP = protocol should also operate over traditional IP networks? This is good.=20 >=20 >>> On 2010-1-25, at 0:25, Cullen Jennings wrote: >>>> 4) 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 >>>> simultaneously. The goals would be delivery of messages roughly >>>> within 50 ms of each other for closely located Devices on suitable >>>> networks to meet the use case of several lights appearing to turn = on >>>> at the same time to a human observer. >>>=20 >>> Doesn't apply this magic 50ms number also to unicast traffic? More = importantly though, there is not much that CoAP can do in guaranteeing = that delay; it seems to be almost entirely dependent on the underlying = routing, radio and sensor technologies. >>=20 >> Yep, I've received multiple comments that amount to IP guarantees = nothing about making anything happened in 50 ms. I think we should = remove this but I'd like to figure out some way of saying it's a goal to = be able to use this as part of an overall system that can get things to = happen "simultaneously" from human point of view. Take RTP for example. = Clearly RTP can be deployed on many IP networks and have a realtime = experience that is "same time" from human point of view (i.e., audio = with less than 150 ms of latency). I'm no sure how to phrase that type = of goal. Ideas ? >=20 > You could say something like "non-reliable multicast delivery of CoAP = messages should have a performance that is close to the IP multicast = delivery performance achievable over the underlying IP topology?" (In = other words, CoAP is not a significant source of additional latency.) This too, good text. >=20 >>>> 5) Default operation of the protocol will be over UDP; it may = optionally >>>> use TCP or other reliable transports. >>>=20 >>> I think we need to rephrase this bullet. I don't think you mean = "optionally, TCP can be used in stead of UDP" when you say "it may = optionally...", but it can be misread in this way. >>>=20 >>> Also, while folks have demonstrated that you can run TCP at = acceptable performance in some deployments, I believe that these = deployments have been very controlled in terms of their topology, radio = configuration, routing setup, etc. *In such cases* CoAP could optionally = partially use TCP for some operations, but in most deployments (esp. = "unmanaged" home deployments) this will simply not work very well. All = the essential functions of CoAP must IMO therefore run over UDP. >>=20 >> I think most people agree with what you are saying here. Help me get = the text to be very clear about what we intended to do. How about = something like=20 >>=20 >> 5) The mandatory to implement transport for the protocol will be UDP. = The WG may choose to specific additional transport protocols. >=20 > I'm not sure that this captures all of it. If UDP is mandatory to = implement and works well, there's really not a huge need to even use = other transports. I thought the main motivation for TCP was that some = operations (such as reliable delivery of a chunk of data larger than the = MTU) are difficult and/or slow over UDP. That is the main purpose. What about the use of CoAP over the larger = Internet?=20 >=20 > If that's the case, maybe we should say that the core CoAP = functionality MUST be operate well over UDP and that it MUST be = implemented over UDP, but that there are OPTIONAL functions in CoAP = (e.g. delivery of larger chunks of data) which if implemented are = implemented over TCP. And then point out that these functions are only = expected to work under very specific deployment scenarios and that hence = applications needing those OPTIONAL functions limit themselves to a = narrow subset of deployment cases. I am OK with this, especially as it makes implementation more = straightforward (having to listen on both UDP and TCP sockets for the = same functionality would be a pain).=20 >=20 >> Anyone else willing to write some replacement text here ? >=20 > Yes, please bash this text. >=20 >>>> 4) There may be additional requirements for each application space, = such >>>> as urban or commercial environments which deploy large networks, >>>> compared to residential environments. >>>=20 >>> Must CoAP support these application spaces from the beginning? If = some of the yet-unstated requirements for these app spaces are = conflicting, it's really easy for the WG to wedge itself, because the = design space for the solution becomes the empty set. >>>=20 >>> Or is the paragraph above still about bootstrapping methods? Segway: = I think you should explicitly say "bootstrapping method" in almost all = places where you currently say "method" to make it clear whether that is = what you mean. And if not, use a different word :-) >=20 > The comment above is separate from the next one below. You might have = missed that and skipped over it - although minor, I want to make sure = that this doesn't fall through the cracks :-) The reference above is only regarding security bootstrapping. The target = applications in smart energy and building automation both have urban and = commercial environments, each with very different security requirements. = That is the reason for bringing this up. It could also be mentioned that = "urban and commercial" are not new application areas for the WG.=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 zach@sensinode.com Mon Jan 25 12:50:51 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 314713A6930 for <6lowapp@core3.amsl.com>; Mon, 25 Jan 2010 12:50:51 -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 9yP3cAsCS64A for <6lowapp@core3.amsl.com>; Mon, 25 Jan 2010 12:50:49 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id A1B1D3A68D7 for <6lowapp@ietf.org>; Mon, 25 Jan 2010 12:50:48 -0800 (PST) Received: from [192.168.1.3] (line-4832.dyn.kponet.fi [85.29.65.50]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o0PKofiJ019648 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 25 Jan 2010 22:50:42 +0200 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <0C0AF10C-85F8-4401-BFB0-441CD08F067E@cisco.com> Date: Mon, 25 Jan 2010 22:50:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4095EBD3-A20F-472D-8D3F-7A1742F55299@sensinode.com> References: <0C0AF10C-85F8-4401-BFB0-441CD08F067E@cisco.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1077) Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Revised Charter Proposal 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, 25 Jan 2010 20:50:51 -0000 More comments in-line:=20 On Jan 25, 2010, at 1:25 , Cullen Jennings wrote: >=20 > I tired to incorporate the discussion on the list and the discussion = from he BOF into a revised charter proposal. I'd like to see if there = were any feedback early this week then, if things look like this charter = is close, send this to Lisa (our AD) and see if this can make it on the = next IESG call.=20 >=20 > Cullen >=20 > ---------------------- >=20 >=20 > CoRE >=20 > Applications are being developed for IP networks that have very = limited > packet sizes, exhibit a high degree of packet loss, and have = 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 applications whenever at least some > of the nodes and networks involved exhibit these characteristics. >=20 > Low-Power Wireless Personal Area Networks (LoWPANs) are an example of > this type of network. These networks are becoming increasing important > for applications such as home and building automation, energy > management, and the Internet of Things. This working group will define = a > framework for a limited class of applications that deal with the > manipulation of simple resources on constrained devices. This includes > applications to monitor simple sensors (e.g. temperature sensors, = light > switches, and power meters) and control actuators (e.g. light = switches, > heating controllers, and door locks). >=20 > The general architecture consists of nodes on the constrained network, > called Devices, that have one or more Resources that may represent > sensors, actuators, or other values. 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. As part of the framework for building = these > applications, the WG will define a Constrained-node/network = Application > Protocol (CoAP) for the manipulation of Resources on a Device. > The > framework will also specify a way to define new interface profiles = that > vendors and other standards bodies can use to define the particular > Resources on a Device and what manipulations are possible. Remove the above sentence.=20 >=20 > CoAP will be designed to be used between Devices on the same = constrained > network, between Devices and general nodes on the internet, and = between > devices on different constrained networks both joined to the internet. >=20 > There also may be nodes called Constrained-to-General-Internet > Intermediaries (CoGII) that interconnect between other protocols > typically used by applications on the internet and the Devices using = the > CoAP protocol. =20 Remove this sentence (see, no more CoGIIs). > The WG will define a mapping on the CoGII from CoAP to > an HTTP REST API; this mapping will not depend on a specific > application. Remove CoGII. Combine with some paragraph above. Add "It is worth noting = that this mapping does not have to be deployed at the boundary of the = constrained network and the more general network but can be deployed at = various locations in the unconstrained network." > Each interface profile will define the Resources on the > Device that applications can manipulate and what manipulations are > possible. This will determine, in a mechanical translation way, the > HTTP REST APIs on the CoGIIs and the CoAP protocol encoding to > manipulate the Resources on the Device; it will also specify an XML = MIME > type for each class of Device that can be used to describe the = Resource > state in the body of HTTP REST messages. It is worth noting that the > CoGII does not have to be deployed at the boundary of the constrained > network and the more general network but can be deployed at various > locations in the unconstrained network. Remove all this stuff, this has to do with profiles etc.=20 >=20 > CoGIIs can provide 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 CoGII that has subscribed, when > the CoGII 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. The CoGIIs may also provide support > for discovering Devices that may not be currently responding as they = are > temporarily asleep. Replace with something like this: CoAP can be cached in various ways. For example, if a temperature sensor=20= is normally asleep but wakes up every five minutes and sends the current=20= temperature to an intermediate subscriber, when the intermediate = receives=20 a request over HTTP for that temperature resource, it can respond with = the=20 last seen value instead of trying to query the Device which is currently = asleep. >=20 > The initial work items of the WG is to define a protocol specification > for CoAP that includes: >=20 > 1) A way to define the "interface profile" that specifies the = Resources > for a Device and implies the REST API that can be used Remove. >=20 > 2) The ability to set and query a resource on a Device. >=20 > 3) 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 > 4) 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 > simultaneously. The goals would be delivery of messages roughly > within 50 ms of each other for closely located Devices on suitable > networks to meet the use case of several lights appearing to turn on > at the same time to a human observer. Update a la Lars >=20 > 5) Default operation of the protocol will be over UDP; it may = optionally > use TCP or other reliable transports. >=20 Update a la Lars > 6) A definition of how to use CoAP to discover Devices on the > constrained network, and to interrogate them to find out which > interface profiles they support. The name taxonomy used for > discovery will be consistent with the approach defined in > draft-cheshire-dnsext-dns-sd. Update to something like: The ability for CoAP to be used for the discovery of Devices and = resource on=20 the constrained network. The details of discovery and profile formats = are out of scope. They may be defined by applications using CoAP or by the WG at a = later time if=20 necessary. >=20 > 7) An ability for Devices to provide a pointer to the general schema > information so that a CoGII does not need any code changes to = support > new Device classes. Remove. >=20 > 8) Specification for the HTTP REST based API and mapping on the CoGII = to > communicate with Devices. Remove CoGII. >=20 > The working group will not develop a reliable multicast solution. >=20 > Security, particularly keying of new Devices, is very challenging for > these applications. On one hand this needs to support models in which = an > end user can introduce onto their network a new Device that may have = no > display or input capabilities. On the other hand, this protocol may > transport information about alarm systems or controlling door locks = over > a wireless network. >=20 > The WG will work to support methods of security bootstrapping which = are > realistic given the constraints and requirements of the network. These > methods are not specific to any communication layer. Instead the = methods > could run across any layer, including IP. Requirements considered > include: >=20 > 1) The methods need to be suitable for use on resource constrained > nodes. These constraints include power, cost, size, and = computational > capacity. [[ Note: the WG realizes the vagueness of this constraint > but does not currently have consensus on a more quantitative metric > of these constraints ]] >=20 > 2) The methods need to provide sufficient security for the application > space. >=20 > 3) The methods must guarantee that any two nodes can join together. = This > includes nodes which are already on separate networks which a user > wishes to merge together. >=20 > 4) There may be additional requirements for each application space, = such > as urban or commercial environments which deploy large networks, > compared to residential environments. >=20 > To ensure that any two nodes can join together, all nodes must = implement > at least one universal method. In additional several other methods = will > be specified which take advantage of the application space. In > commercial applications, for instance, bootstrapping can take = advantage > of the fact that networks are typically managed from a central > authority, and a method optimized for residential usage might take > advantage of the fact that nodes are in close proximity. >=20 > Methods which will be considered include: >=20 > 1) Out of Band Key or Certificate: In this mode a key (either = symmetric > or asymmetric) is distributed with the product, such as a 2D barcode > printed on the node. The user can scan this key with a computer to > give access to this node. >=20 > 2) Physical Button Protocol: In this mode two nodes only require > pushbuttons and LEDs, and the user simply pushes the button on each > node within a narrow time window to join them together. >=20 > 3) Out of Band Communication Link: This could include IrDA or NFC = (Near > Field Communication) type technologies to allow a device to join > another device that is physically nearby. >=20 > 4) Out of Band Configuration: A simple example of this would be using > the programming interface which a node uses to download firmware. >=20 One comment is that it might not be necessary to descibe these in such = detail in the charter, instead it might be enough to shortly list these.=20= > This list should not be considered exhaustive, and methods may be > removed or added as additional application spaces and requirements are > found. The list gives examples of the types of methods to be > investigated. It should be explicitly said that the goal of the WG with regard to = security bootstrapping is not to develop any new protocols. Instead = these methods recommend how to use existing protocols in a constrained = configuration. >=20 > Security can be achieved using other session security or object > security. For session security, the WG will work with the security = area > to select cipher suites most useful for constrained network. For = object > security, CoAP will initially look at CMS (RFC 5652). Mentioning TLS/DTLS would be a good idea. >=20 > The WG will coordinate on requirements from many organizations = including > OpenSG/NIST, ZigBee/HomePlug, IPSO Alliance, OASIS, SENSEI; 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 > Mar 2010 - Select WG document for basis of CoAP protocol I don't see this as a problem. There has been a lot of work going on = already in December and January, the chartering process is going on in = parallel. As SE 2.0 has a real need to be able to point at a document - = this is a necessary milestone.=20 >=20 > Dec 2010 - CoAP protocol specification with mapping to HTTP Rest API > submitted to IESG as PS Does this really need to be a separate RFC? =46rom the BOF I had a = feeling we should integrate this mapping with the main CoAP protocol = document. Instead, I would find it much more valuable to have the = security bootstrapping as its own RFC.=20 Zach >=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 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 Tue Jan 26 02:56: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 82FF03A68FF for <6lowapp@core3.amsl.com>; Tue, 26 Jan 2010 02:56:17 -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 vUcE3Pe6qoGW for <6lowapp@core3.amsl.com>; Tue, 26 Jan 2010 02:56:16 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 771453A683E for <6lowapp@ietf.org>; Tue, 26 Jan 2010 02:56:14 -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 o0QAuJ2w010541 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 26 Jan 2010 12:56:19 +0200 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: Zach Shelby In-Reply-To: <004201ca9aa8$55d02cd0$01708670$@moritz@uni-rostock.de> Date: Tue, 26 Jan 2010 12:56:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0B3D3615-F1AB-4067-B758-0A988C10CD98@sensinode.com> <004201ca9aa8$55d02cd0$01708670$@moritz@uni-rostock.de> To: Guido Moritz X-Mailer: Apple Mail (2.1077) Cc: 6LoWAPP <6lowapp@ietf.org> Subject: Re: [6lowapp] 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: Tue, 26 Jan 2010 10:56:17 -0000 On Jan 21, 2010, at 16:45 , Guido Moritz wrote: > Dear Zach, >=20 > personally I am quite familiar with DPWS (see my I-D in 6LoWAPP), but = I may > have some more commends on this. I would like to propose to have look = on > DPWS, WS-Discovery, and SOAP-over-UDP specs at OASIS. They might point = to > some conceptual solutions useful for COAP. Please find more comments = below > in the text. >=20 Yes, I do agree with this approach. We would be happy to explore that in = the text of http://www.ietf.org/id/draft-shelby-6lowapp-coap-00.txt.=20 In my opinion a goal of this new WG should be to cooperate with OASIS to = explore how a future extension to the DPWS paradigm (DPWS for CoAP?) = could make use of CoAP in these environments. CoAP should only provide = the basic protocol mechanism... just as DPWS makes use of HTTP and = SOAP-over-UDP today.=20 > Regards, > Guido >=20 >> -----Urspr=FCngliche Nachricht----- >> Von: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] Im >> Auftrag von Zach Shelby >> Gesendet: Dienstag, 19. Januar 2010 14:37 >> An: 6LoWAPP >> Betreff: [6lowapp] draft-shelby-6lowapp-coap-00 >>=20 >> Does anyone have comments/ideas regarding = http://www.ietf.org/id/draft- >> shelby-6lowapp-coap-00.txt that we submitted before the holidays? We >> would like to start some design work, so any feedback would be really >> useful. I've identified some areas where we need input/discussion on >> the list: >>=20 >> 1. Content-type encoding (Section 2.4). Any ideas or suggestions on = how >> to encode this and what is enough space? How should such an encoding = be >> managed, ask IANA to do that? Any pointers to a similar encoding done >> elsewhere? > Encoding in the COAP header might be most efficient way, especially = focusing > parsing incoming headers/messages. But extensibility is quite = important and > a core feature of REST. XML send via HTTP uses "magic bytes". = SOAP-over-UDP > (XML SOAP envelopes send via UDP without HTTP header) binding > implementations can use these magic bytes for data format = identification. > COAP should include same features to allow own or not prior defined = data > formats. >=20 Agreed. That could be done by reserving a range of codes for private = use, or by having a code that says something like "look at the magic = bytes in the payload"? >>=20 >> 2. Caching (Section 2.6). Should we go towards an in-band or an = out-of- >> band discovery approach? Personally I think an in-band approach is by >> far the simplest, although it requires some header space when = present. > Out-of-band discovery might imply overlapping with other specs (mDNS, > WS-Discovery,..). Thus, comprehensive in-band discovery seems a proper > approach. Header space should not be a problem because > methods/actions/operations of COAP are very limited. Additional = information > to be included in the header for discovery purposes would have to be > included for out-of-band approaches as well but would require = additional > efforts to work on "two separated tracks". Good point. >=20 >>=20 >> 3. Subscribe/Notify (Section 2.7). This is an area that definitely >> needs discussion. The current proposal is to use a REST interface to >> create subscriptions and which are then sent using a NOTIFY message = to >> a call-back URL. How to format the body o the subscription (URL to >> subscribe to, URL call-back, parameters?). > Similar features are included in DPWS by using WS-Eventing. In > subscriptions, a client includes an endpoint for event delivery. This = is a > transport specific address including protocol and address. > But additional features might be required for a complete eventing = concept. > This includes lease management concepts and filtering concepts (e.g. = set > limits/thresholds for a temperature value). Furthermore, a data = distribution > model is required. WS-Eventing uses by default unicast messages to the > clients (sinks of event). This requires one message to every = subscriber. > XMPP instead needs, due to its architecture, only one message to the = server > which distributes data to all subscribed clients without need for = multiple > sendings of the originator. We should look at both in more detail. We don't have a server = architecture as in XMPP,=20 however there may a proxy (HTTP-CoAP mapping e.g.) that aggregates = subscriptions on behalf of nodes. Therefore the paradigm would probably = be similar to the WS-Eventing (unicast). I think the question here is, = is there an existing payload format for including the URL call-back and = other needed subscription management parameters that we could just point = at? This would need to be simple to parse with a reasonable payload = size.=20 >=20 >>=20 >> 4. Resource Discovery (Section 2.9). The proposal is to use a new >> DISCOVER method which can be sent either unicast or multicast. The = only >> difficult part there is the format of the list of resources (URLs) >> which would be returned in such a response. This is a little bit like >> index.html. We had some discussions in Hiroshima that XMPP has >> developed some ways of coding lists of URLs and that could be = re-used. >> Does someone have a pointer for us on that? > WS-Discovery specification goes one step further and combines metadata > exchange for devices and service descriptions. In the first step, a = device > itself is discovered which is a ensemble of "Hosted Services" = (services or > in COAP single resource). A single service itself provides also = metadata > (methods/operations of service) which can be queried.=20 > The new Bluetooth Low Energy Attribute Protocol uses a similar = approach to > request either all services of a attribute server or specific = attributes of > a service. > To sum up, I am not sure which functionalities the discovery of COAP = has to > provide, but it might require more efforts then just to define how to = encode > a set of URLs. The new charter update will help us here... It seems like defining the = format of these messages might be out of scope for the WG's first = charter, although the original idea was also to define a basic URL list = (do we still do that?). It may be enough to point at other formats or = paradigms that could use this method for discovery. If there is interest = and the need to define one at the IETF later, then we could be = re-chartered for that?=20 >=20 >>=20 >=20 > Some more comments: > -REQ2 seems quite hard. Without knowledge about design/architecture to > define a header size. This is from the charter, and it comes from the 6LoWPAN network = architecture and IEEE 802.15.4 frame sizes. I don't find it to be that = difficult to meet, from experience designing similar protocols. >=20 > -REQ3: Is it useful to make sleeping nodes to an application layer > requirement? 6LoWPAN allows seamless integration into existing = networks. To > deal with sleeping nodes always requires caching intermediates and = thus does > not permit for ad-hoc connectivity, because external endpoints cannot = be > aware of this. Sleeping nodes should be solved on link layer, without = design > requirements for application layer? Locally sleeping nodes *might* very well be dealt with at the link layer = in an ad-hoc setting, but we can't make such an assumption about all = link-layers (many don't) at the IETF. REQ3 does not force sleeping nodes = to be dealt with at the application layer (so your ad-hoc case will = work), but that it *can* be used to deal with sleeping nodes (e.g. = caching in an HTTP-CoAP proxy) when appropriate. It is common that nodes = sleep for long periods of time in sensor networks, for endpoints = somewhere on the Internet, this can be dealt with by a caching = intermediate. I think the requirement is good to keep in mind what = caching will sometimes be used for here. Zach >=20 >> Thanks, >> 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 >>=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 > _______________________________________________ > 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 peter.van.der.stok@philips.com Tue Jan 26 03:08: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 6C71E3A67F5 for <6lowapp@core3.amsl.com>; Tue, 26 Jan 2010 03:08:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 eJqi4+uQWzwF for <6lowapp@core3.amsl.com>; Tue, 26 Jan 2010 03:08:22 -0800 (PST) Received: from smtpx.philips.com (smtpx.philips.com [168.87.56.20]) by core3.amsl.com (Postfix) with ESMTP id F18443A63EC for <6lowapp@ietf.org>; Tue, 26 Jan 2010 03:08:21 -0800 (PST) Received: from nlamsexh03.connect1.local (172.16.153.24) by connect1.philips.com (172.16.156.42) with Microsoft SMTP Server (TLS) id 8.1.393.1; Tue, 26 Jan 2010 12:08:33 +0100 Received: from NLCLUEXM03.connect1.local ([172.16.157.42]) by nlamsexh03.connect1.local ([172.16.152.24]) with mapi; Tue, 26 Jan 2010 12:08:28 +0100 From: "Van Der Stok, Peter" To: Zach Shelby , Cullen Jennings Date: Tue, 26 Jan 2010 12:08:20 +0100 Thread-Topic: [6lowapp] CoAp feature analysis Thread-Index: AcqeAB01s3ejednmQWu58GxmmFlCpgAcXR8A Message-ID: References: <0C0AF10C-85F8-4401-BFB0-441CD08F067E@cisco.com> <4095EBD3-A20F-472D-8D3F-7A1742F55299@sensinode.com> In-Reply-To: <4095EBD3-A20F-472D-8D3F-7A1742F55299@sensinode.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "6lowapp@ietf.org" <6lowapp@ietf.org> Subject: Re: [6lowapp] CoAp feature analysis 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, 26 Jan 2010 11:08:23 -0000 Dear Zach, I want to send some comments on the CoAP feature analysis draft from a buil= ding control point of view. A picture emerges where a request on general Internet is generated and sent= down to the low resources network, which necessitates a translation of HTT= P commands to less resource demanding RESTful commands. I like to point out= that for building control many (most?) communication originates inside the= low resources network and will remain inside that network. However, some c= ommands may remain within the building passing from one low resource networ= k to another, and a smaller fraction will probably generate from outside th= e building in the general internet network. Efficiency inside the low resou= rces network is more important than efficient translations. My remark does = not very much influence the text in the document, but it may have impact on= later implementation decisions. In addition to REQ4 and in conjunction with REQ10, it will be necessary to = interrogate on the state of the cached request. A simple statement like: th= e application is able to check the arrival of the cached request/command wi= ll be welcome. How to implement it is a second concern, but when the respon= sibility is delegated to the application, there remains the problem of wait= ing for the arrival of the status request by the application. REQ5. The possibility to subscribe to published data can be made very compl= ex with lots of additional conditions and time constraints within the reque= st. I would suggest that a device can advertise the publication of a fixed = set of data with a fixed set of repetition settings (probably a multiple of= the sleep interval). Any other sophistication is optional. REQ8. Although the cited 50ms would be fantastic, their guarantee depends o= n too many additional operational conditions. A possible phrase is: the mul= ticast results should be delivered in a time comparable to the delivery of = the broadcast service provided by the supporting link. Another point is the scope. Sometimes multicast should be limited to the lo= w resource network limited by the edge router, or should encompass a set of= low resource networks (the whole building) possibly identified by a set of= prefixes. REQ10. I don't believe in limiting the reliability to given numbers. The sa= me problem occurs as with response time. The reliability depends on too man= y other factors. I would be happy with the possibility that the arrival or = non-arrival of a message can be tested. Provision of TCP. When would I use TCP? (1) reliability: it can tell me whether data arrived (it may say no, althou= gh it is yes, but when is says yes, it is yes) (2) large messages (multiple packets): however the header overhead is such = that UDP is preferred at the moment. Large messages can be interesting when= descriptions are dumped into a low resource node. (3) my application on a notebook attached to the building network uses TCP. In section 2.6 I think to have a slight preference for cache description in= the device description. The latter info can be used by the proxy. Difficul= t to see al consequences though. I hope this helps a bit. Peter Peter van der Stok Philips Research Laboratories Eindhoven, High Tech Campus, HTC 34 (WB) 6-051 5656 AA Eindhoven, The Netherlands Phone: +31 40 2749657 , Fax: +31 40 2746321 Mailto: Peter.van.der.Stok@ philips.com The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From dromasca@avaya.com Tue Jan 26 04:15: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 BB6843A694A for <6lowapp@core3.amsl.com>; Tue, 26 Jan 2010 04:15:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.125 X-Spam-Level: X-Spam-Status: No, score=-2.125 tagged_above=-999 required=5 tests=[AWL=0.474, 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 xOBeMKtyD76O for <6lowapp@core3.amsl.com>; Tue, 26 Jan 2010 04:15:28 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 4B7783A693F for <6lowapp@ietf.org>; Tue, 26 Jan 2010 04:15:28 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,346,1262581200"; d="scan'208";a="173943426" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 26 Jan 2010 07:15:36 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.11]) by co300216-co-erhwest-out.avaya.com with ESMTP; 26 Jan 2010 07:15:35 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Jan 2010 13:15:21 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowapp] Revised Charter Proposal Thread-Index: Acqd7LQ6eAuif8F/Q/+t3pI63K7M+AAjoHog References: <0C0AF10C-85F8-4401-BFB0-441CD08F067E@cisco.com> From: "Romascanu, Dan (Dan)" To: "Cullen Jennings" Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Revised Charter Proposal 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, 26 Jan 2010 12:15:29 -0000 =20 > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com]=20 >=20 > > - The operational and manageability aspects are not mentioned,=20 > > excepting firmware updates. They are implied in some of the=20 > > capabilities like querying resources, but I think that=20 > observability=20 > > of device presence and operational status query should be=20 > mentioned explicitly. >=20 > OK. Let me make an analogy of this work is a bit like we are=20 > defining a protocol like http here and not the protocol one=20 > would necessarily use to to manger a web server system. Agree=20 > we need to say more around ops and management but not sure=20 > what to say. Can you help me figure out what to say. Given=20 > the discussion in the BOF, we need to make sure what whatever=20 > we add it does not require Devices to be powered on at all=20 > times and we need to be sure that it does not require a way=20 > to enumerate all the Devices on the system as that is a=20 > discovery problem that is explicitly out of scope for now.=20 >=20 At a minimum I think an operator would need to know which devices are at a given moment in time powered and which are not. The IEEE actually dealt with this problem by using linkDown / linkUp notifications on a link - they operate at link level, and power down dormant links to save energy.=20 Dan From guido.moritz@uni-rostock.de Tue Jan 26 04:25: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 6580C3A6900 for <6lowapp@core3.amsl.com>; Tue, 26 Jan 2010 04:25:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, MSGID_MULTIPLE_AT=1.449, 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 mhxTTrzIdITy for <6lowapp@core3.amsl.com>; Tue, 26 Jan 2010 04:25:38 -0800 (PST) Received: from mailrelay1.uni-rostock.de (mailrelay1.uni-rostock.de [139.30.8.201]) by core3.amsl.com (Postfix) with ESMTP id 185353A689A for <6lowapp@ietf.org>; Tue, 26 Jan 2010 04:25:37 -0800 (PST) Received: from email2.uni-rostock.de (139.30.8.209) by edge01.uni-rostock.de (139.30.8.159) with Microsoft SMTP Server (TLS) id 8.2.213.0; Tue, 26 Jan 2010 13:25:46 +0100 Received: from Schlappi (139.30.201.173) by email2.uni-rostock.de (139.30.8.210) with Microsoft SMTP Server (TLS) id 8.2.213.0; Tue, 26 Jan 2010 13:25:45 +0100 From: Guido Moritz To: 'Zach Shelby' References: <0B3D3615-F1AB-4067-B758-0A988C10CD98@sensinode.com> <004201ca9aa8$55d02cd0$01708670$@moritz@uni-rostock.de> In-Reply-To: Date: Tue, 26 Jan 2010 13:25:47 +0100 Message-ID: <002001ca9e82$b077f8b0$1167ea10$@moritz@uni-rostock.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqedjYx4F4E1p2NQemm40+gBrgxXQABq7Gw Content-Language: de Cc: 6LoWAPP <6lowapp@ietf.org> Subject: Re: [6lowapp] 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: Tue, 26 Jan 2010 12:25:40 -0000 Find comments below inline. > -----Urspr=FCngliche Nachricht----- > Von: Zach Shelby [mailto:zach@sensinode.com] > Gesendet: Dienstag, 26. Januar 2010 11:56 > An: Guido Moritz > Cc: 6LoWAPP > Betreff: Re: [6lowapp] draft-shelby-6lowapp-coap-00 >=20 >=20 > On Jan 21, 2010, at 16:45 , Guido Moritz wrote: >=20 > > Dear Zach, > > > > personally I am quite familiar with DPWS (see my I-D in 6LoWAPP), = but > I may > > have some more commends on this. I would like to propose to have = look > on > > DPWS, WS-Discovery, and SOAP-over-UDP specs at OASIS. They might > point to > > some conceptual solutions useful for COAP. Please find more comments > below > > in the text. > > >=20 > Yes, I do agree with this approach. We would be happy to explore that > in the text of = http://www.ietf.org/id/draft-shelby-6lowapp-coap-00.txt. >=20 > In my opinion a goal of this new WG should be to cooperate with OASIS > to explore how a future extension to the DPWS paradigm (DPWS for = CoAP?) > could make use of CoAP in these environments. CoAP should only provide > the basic protocol mechanism... just as DPWS makes use of HTTP and > SOAP-over-UDP today. Carefully agreed. Core question: Will COAP reuse = paradigms/concepts/methods of DPWS or vice versa ('DPWS over COAP' vs. 'COAP over DPWS')? Both = sounds quite interesting! Nevertheless, DPWS defines most features (also most required by COAP) and bases on transport layer. In a paper we currently preparing for final submission, we also investigate on benefit of HTTP binding for DPWS, which is only used for compatibility reasons with = existing SOAP Web services. But I will follow up if COAP is a adequate = replacement candidate for constraint SOAP binding. Sounds good! >=20 > > Regards, > > Guido > > > >> -----Urspr=FCngliche Nachricht----- > >> Von: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] Im > >> Auftrag von Zach Shelby > >> Gesendet: Dienstag, 19. Januar 2010 14:37 > >> An: 6LoWAPP > >> Betreff: [6lowapp] draft-shelby-6lowapp-coap-00 > >> > >> Does anyone have comments/ideas regarding > http://www.ietf.org/id/draft- > >> shelby-6lowapp-coap-00.txt that we submitted before the holidays? = We > >> would like to start some design work, so any feedback would be > really > >> useful. I've identified some areas where we need input/discussion = on > >> the list: > >> > >> 1. Content-type encoding (Section 2.4). Any ideas or suggestions on > how > >> to encode this and what is enough space? How should such an = encoding > be > >> managed, ask IANA to do that? Any pointers to a similar encoding > done > >> elsewhere? > > Encoding in the COAP header might be most efficient way, especially > focusing > > parsing incoming headers/messages. But extensibility is quite > important and > > a core feature of REST. XML send via HTTP uses "magic bytes". SOAP- > over-UDP > > (XML SOAP envelopes send via UDP without HTTP header) binding > > implementations can use these magic bytes for data format > identification. > > COAP should include same features to allow own or not prior defined > data > > formats. > > >=20 > Agreed. That could be done by reserving a range of codes for private > use, or by having a code that says something like "look at the magic > bytes in the payload"? Agreed. >=20 > >> > >> 2. Caching (Section 2.6). Should we go towards an in-band or an = out- > of- > >> band discovery approach? Personally I think an in-band approach is > by > >> far the simplest, although it requires some header space when > present. > > Out-of-band discovery might imply overlapping with other specs = (mDNS, > > WS-Discovery,..). Thus, comprehensive in-band discovery seems a > proper > > approach. Header space should not be a problem because > > methods/actions/operations of COAP are very limited. Additional > information > > to be included in the header for discovery purposes would have to be > > included for out-of-band approaches as well but would require > additional > > efforts to work on "two separated tracks". >=20 > Good point. >=20 > > > >> > >> 3. Subscribe/Notify (Section 2.7). This is an area that definitely > >> needs discussion. The current proposal is to use a REST interface = to > >> create subscriptions and which are then sent using a NOTIFY message > to > >> a call-back URL. How to format the body o the subscription (URL to > >> subscribe to, URL call-back, parameters?). > > Similar features are included in DPWS by using WS-Eventing. In > > subscriptions, a client includes an endpoint for event delivery. = This > is a > > transport specific address including protocol and address. > > But additional features might be required for a complete eventing > concept. > > This includes lease management concepts and filtering concepts (e.g. > set > > limits/thresholds for a temperature value). Furthermore, a data > distribution > > model is required. WS-Eventing uses by default unicast messages to > the > > clients (sinks of event). This requires one message to every > subscriber. > > XMPP instead needs, due to its architecture, only one message to the > server > > which distributes data to all subscribed clients without need for > multiple > > sendings of the originator. >=20 > We should look at both in more detail. We don't have a server > architecture as in XMPP, > however there may a proxy (HTTP-CoAP mapping e.g.) that aggregates > subscriptions on behalf of nodes. Therefore the paradigm would = probably > be similar to the WS-Eventing (unicast). I think the question here is, > is there an existing payload format for including the URL call-back = and > other needed subscription management parameters that we could just > point at? This would need to be simple to parse with a reasonable > payload size. For payload format WS-Eventing defines an own format (see http://www.w3.org/Submission/WS-Eventing/#Subscribe as example). XMPP = reuses originator addresses already included in the XMPP stanza (I am not sure = if there is an additional mechanism for negotiation, might be corrected if = I am wrong). A nice feature of XMPP is that the originator address is always stamped by the server in the message itself and must not be transmitted = by the sender to the next server (this may also have security reasons).=20 Nevertheless, I would go a step further and first ask first: what about = data dissemination and transport negotiation. Is there a central point which sends events out to all subscribes and thus the event source only has to transmit data ones to this central point? If yes, does the subscriber include the 'call back URL' in the subscription. If yes, how does the subscriber discovers this central point? Or is the event source aware of this central point and tells the subscriber in a response were to pick = up the events? Is the whole design aware of optional presence of such a = central point, like DPWS has concept for differentiating between ad-hoc mode and managed mode and both can work in coexistence? To sum up, before trying to find a proper payload format for endpoint = and filter negotiation, the requirements and protocol design should be = clearer. (Up to now I have no idea about such core design principals of COAP.) >=20 > > > >> > >> 4. Resource Discovery (Section 2.9). The proposal is to use a new > >> DISCOVER method which can be sent either unicast or multicast. The > only > >> difficult part there is the format of the list of resources (URLs) > >> which would be returned in such a response. This is a little bit > like > >> index.html. We had some discussions in Hiroshima that XMPP has > >> developed some ways of coding lists of URLs and that could be re- > used. > >> Does someone have a pointer for us on that? > > WS-Discovery specification goes one step further and combines > metadata > > exchange for devices and service descriptions. In the first step, a > device > > itself is discovered which is a ensemble of "Hosted Services" > (services or > > in COAP single resource). A single service itself provides also > metadata > > (methods/operations of service) which can be queried. > > The new Bluetooth Low Energy Attribute Protocol uses a similar > approach to > > request either all services of a attribute server or specific > attributes of > > a service. > > To sum up, I am not sure which functionalities the discovery of COAP > has to > > provide, but it might require more efforts then just to define how = to > encode > > a set of URLs. >=20 > The new charter update will help us here... It seems like defining the > format of these messages might be out of scope for the WG's first > charter, although the original idea was also to define a basic URL = list > (do we still do that?). It may be enough to point at other formats or > paradigms that could use this method for discovery. If there is > interest and the need to define one at the IETF later, then we could = be > re-chartered for that? >=20 > > > >> > > > > Some more comments: > > -REQ2 seems quite hard. Without knowledge about design/architecture > to > > define a header size. >=20 > This is from the charter, and it comes from the 6LoWPAN network > architecture and IEEE 802.15.4 frame sizes. I don't find it to be that > difficult to meet, from experience designing similar protocols. What I wanted to say is, that there are questions which first might be discussed first. E.g.: Do we prepare for separation of 'device/resource (e.g. human readable URI)' address and 'transport (IP)' address like = DPWS does by including WS-Addressing? Or does COAP always derives addresses = from transport layer? Otherwise these addresses might be included in the = header. Are these information header fields? The 'call back' addresses discussed = for eventing purposes discussed above, is this a header or a payload field? Might this be derived from transport layer or included in the layer = above or both? SOAP also separated between SOAP header and SOAP body, but with = clear definition what difference between both parts is. I hope I could make = clear what I am thinking about. So until the design is not clear about which information are required to = be carried within the header, definition about its size should not be a = core requirement. Nevertheless, as you mentioned there is a frame size = limitation and thus there might be a requirement to fit a complete COAP frame in = one 15.4 frame. But not the definition about limitation a header size = which's content is not clear. >=20 > > > > -REQ3: Is it useful to make sleeping nodes to an application layer > > requirement? 6LoWPAN allows seamless integration into existing > networks. To > > deal with sleeping nodes always requires caching intermediates and > thus does > > not permit for ad-hoc connectivity, because external endpoints = cannot > be > > aware of this. Sleeping nodes should be solved on link layer, = without > design > > requirements for application layer? >=20 > Locally sleeping nodes *might* very well be dealt with at the link > layer in an ad-hoc setting, but we can't make such an assumption about > all link-layers (many don't) at the IETF. REQ3 does not force sleeping > nodes to be dealt with at the application layer (so your ad-hoc case > will work), but that it *can* be used to deal with sleeping nodes = (e.g. > caching in an HTTP-CoAP proxy) when appropriate. It is common that > nodes sleep for long periods of time in sensor networks, for endpoints > somewhere on the Internet, this can be dealt with by a caching > intermediate. I think the requirement is good to keep in mind what > caching will sometimes be used for here. Should be made clearer that sleeping nodes are transparent to external networks by using caching intermediates to enable sleeping states for = nodes. >=20 > Zach >=20 Your welcome, Guido > > > >> Thanks, > >> 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 > > > > _______________________________________________ > > 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 >=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 From robert.cragie@gridmerge.com Tue Jan 26 04:36:38 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 2DA373A695B for <6lowapp@core3.amsl.com>; Tue, 26 Jan 2010 04:36:38 -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 t1VuOG1Inpkn for <6lowapp@core3.amsl.com>; Tue, 26 Jan 2010 04:36:35 -0800 (PST) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id 847D93A6826 for <6lowapp@ietf.org>; Tue, 26 Jan 2010 04:36:34 -0800 (PST) Received: from client-86-31-52-97.nrth.adsl.virginmedia.com ([86.31.52.97] helo=[192.168.1.68]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.70) id 1NZkev-0005qh-2l; Tue, 26 Jan 2010 12:36:42 +0000 Message-ID: <4B5EE1D6.2080705@gridmerge.com> Date: Tue, 26 Jan 2010 12:36:38 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Zach Shelby References: <0C0AF10C-85F8-4401-BFB0-441CD08F067E@cisco.com> <4095EBD3-A20F-472D-8D3F-7A1742F55299@sensinode.com> In-Reply-To: <4095EBD3-A20F-472D-8D3F-7A1742F55299@sensinode.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020900000109090104030508" Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Revised Charter Proposal 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: Tue, 26 Jan 2010 12:36:38 -0000 This is a cryptographically signed message in MIME format. --------------ms020900000109090104030508 Content-Type: multipart/alternative; boundary="------------030106050302050205050405" This is a multi-part message in MIME format. --------------030106050302050205050405 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Some comments below bracketed by . I generally agree with Zach's comments unless stated. Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 (0) 1924 910888 http://www.gridmerge.com Zach Shelby wrote: > More comments in-line: > > On Jan 25, 2010, at 1:25 , Cullen Jennings wrote: > > >> I tired to incorporate the discussion on the list and the discussion from he BOF into a revised charter proposal. I'd like to see if there were any feedback early this week then, if things look like this charter is close, send this to Lisa (our AD) and see if this can make it on the next IESG call. >> >> Cullen >> >> ---------------------- >> >> >> CoRE >> >> Applications are being developed for IP networks that have very limited >> packet sizes, exhibit a high degree of packet loss, and have 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 applications 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. These networks are becoming increasing important >> for applications such as home and building automation, energy >> management, and the Internet of Things. This working group will define a >> framework for a limited class of applications that deal with the >> manipulation of simple resources on constrained devices. This includes >> applications to monitor simple sensors (e.g. temperature sensors, light >> switches, and power meters) and control actuators (e.g. light switches, >> heating controllers, and door locks). >> >> The general architecture consists of nodes on the constrained network, >> called Devices, that have one or more Resources that may represent >> sensors, actuators, or other values. 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. As part of the framework for building these >> applications, the WG will define a Constrained-node/network Application >> Protocol (CoAP) for the manipulation of Resources on a Device. >> > > > >> The >> framework will also specify a way to define new interface profiles that >> vendors and other standards bodies can use to define the particular >> Resources on a Device and what manipulations are possible. >> > > Remove the above sentence. > > >> CoAP will be designed to be used between Devices on the same constrained >> network, between Devices and general nodes on the internet, and between >> devices on different constrained networks both joined to the internet. >> >> There also may be nodes called Constrained-to-General-Internet >> Intermediaries (CoGII) that interconnect between other protocols >> typically used by applications on the internet and the Devices using the >> CoAP protocol. >> > > Remove this sentence (see, no more CoGIIs). > > > >> The WG will define a mapping on the CoGII from CoAP to >> an HTTP REST API; this mapping will not depend on a specific >> application. >> > > Remove CoGII. Combine with some paragraph above. Add "It is worth noting that this mapping does not have to be deployed at the boundary of the constrained network and the more general network but can be deployed at various locations in the unconstrained network." > I don't think you need to say anything about deployment - it's a mapping. > > >> Each interface profile will define the Resources on the >> Device that applications can manipulate and what manipulations are >> possible. This will determine, in a mechanical translation way, the >> HTTP REST APIs on the CoGIIs and the CoAP protocol encoding to >> manipulate the Resources on the Device; it will also specify an XML MIME >> type for each class of Device that can be used to describe the Resource >> state in the body of HTTP REST messages. It is worth noting that the >> CoGII does not have to be deployed at the boundary of the constrained >> network and the more general network but can be deployed at various >> locations in the unconstrained network. >> > > Remove all this stuff, this has to do with profiles etc. > I agree, it's unnecessarily specific > >> CoGIIs can provide 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 CoGII that has subscribed, when >> the CoGII 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. The CoGIIs may also provide support >> for discovering Devices that may not be currently responding as they are >> temporarily asleep. >> > > Replace with something like this: > > CoAP can be cached in various ways. For example, if a temperature sensor > is normally asleep but wakes up every five minutes and sends the current > temperature to an intermediate subscriber, when the intermediate 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. > I don't think you can get away with removing the concept of a CoGII. It's all gone a bit hand-wavy now going on about caching at 'intermediate subscriber' (aka CoGII?) nodes. In my experience, managing data for sleeping nodes is one of the more complex and overlooked aspects of sensor networks and needs to be focused on not dissolved away like this. > >> The initial work items of the WG is to define a protocol specification >> for CoAP that includes: >> >> 1) A way to define the "interface profile" that specifies the Resources >> for a Device and implies the REST API that can be used >> > > Remove. > > >> 2) The ability to set and query a resource on a Device. >> >> 3) 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. >> >> 4) 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 >> simultaneously. The goals would be delivery of messages roughly >> within 50 ms of each other for closely located Devices on suitable >> networks to meet the use case of several lights appearing to turn on >> at the same time to a human observer. >> > > Update a la Lars > I think the original statement is fine if you just remove "roughly within 50ms of each other" > >> 5) Default operation of the protocol will be over UDP; it may optionally >> use TCP or other reliable transports. >> >> > > Update a la Lars > I think the original statement is almost OK. I would perhaps reword as follows: "Default operation of the protocol will be over UDP, however it will not be precluded from operating over TCP or other reliable transports". This would address the 'wider internet' concern. I don't particularly see the point in having options only suitable for TCP, for example - this goes against the whole point of CoAP. > >> 6) A definition of how to use CoAP to discover Devices on the >> constrained network, and to interrogate them to find out which >> interface profiles they support. The name taxonomy used for >> discovery will be consistent with the approach defined in >> draft-cheshire-dnsext-dns-sd. >> > > Update to something like: > > The ability for CoAP to be used for the discovery of Devices and resource on > the constrained network. The details of discovery and profile formats are out of > scope. They may be defined by applications using CoAP or by the WG at a later time if > necessary. > > > >> 7) An ability for Devices to provide a pointer to the general schema >> information so that a CoGII does not need any code changes to support >> new Device classes. >> > > Remove. > > >> 8) Specification for the HTTP REST based API and mapping on the CoGII to >> communicate with Devices. >> > > Remove CoGII. > > >> The working group will not develop a reliable multicast solution. >> >> Security, particularly keying of new Devices, is very challenging for >> these applications. On one hand this needs to support models in which an >> end user can introduce onto their network a new Device that may have no >> display or input capabilities. On the other hand, this protocol may >> transport information about alarm systems or controlling door locks over >> a wireless network. >> Security is always 'very challenging' ;-). The 'on one hand/on the other hand' statement implies opposites but the statements are not logically related. I would perhaps rephrase something like the following: "There are two main aspects of security which need special consideration in these applications. There must be support for introduction of Devices that may have no display or input capabilities onto the network. Also, support for high security is essential as this protocol may transport information about alarm systems or controlling door locks over a wireless network." >> The WG will work to support methods of security bootstrapping which are >> realistic given the constraints and requirements of the network. These >> methods are not specific to any communication layer. Instead the methods >> could run across any layer, including IP. Requirements considered >> include: >> Remove "Instead the methods could run across any layer, including IP" >> 1) The methods need to be suitable for use on resource constrained >> nodes. These constraints include power, cost, size, and computational >> capacity. [[ Note: the WG realizes the vagueness of this constraint >> but does not currently have consensus on a more quantitative metric >> of these constraints ]] >> I think we have already defined constrained node/network so I don't see the need to repeat it here. The only additional property specifically relevant for security called out above is computational capacity; maybe this could be incorporated in the original definition. >> 2) The methods need to provide sufficient security for the application >> space. >> I think the statement is rather vague. Perhaps something like "the methods need to support a wide range of security requirements coming from the application space" >> 3) The methods must guarantee that any two nodes can join together. This >> includes nodes which are already on separate networks which a user >> wishes to merge together. >> There are two things here: 1) It would always be a policy decision whether two nodes can join together, so I would rephrase as "the methods must support the joining of two nodes" 2) You have opened up a large can of worms when talking about merging networks. This has many implications beyond joining two nodes >> 4) There may be additional requirements for each application space, such >> as urban or commercial environments which deploy large networks, >> compared to residential environments. >> >> To ensure that any two nodes can join together, all nodes must implement >> at least one universal method. In additional several other methods will >> be specified which take advantage of the application space. In >> commercial applications, for instance, bootstrapping can take advantage >> of the fact that networks are typically managed from a central >> authority, and a method optimized for residential usage might take >> advantage of the fact that nodes are in close proximity. >> >> Methods which will be considered include: >> >> 1) Out of Band Key or Certificate: In this mode a key (either symmetric >> or asymmetric) is distributed with the product, such as a 2D barcode >> printed on the node. The user can scan this key with a computer to >> give access to this node. >> There are also polynomial-based key distribution methods which may be appropriate. Perhaps the statement above should be less specific. >> 2) Physical Button Protocol: In this mode two nodes only require >> pushbuttons and LEDs, and the user simply pushes the button on each >> node within a narrow time window to join them together. >> >> 3) Out of Band Communication Link: This could include IrDA or NFC (Near >> Field Communication) type technologies to allow a device to join >> another device that is physically nearby. >> >> 4) Out of Band Configuration: A simple example of this would be using >> the programming interface which a node uses to download firmware. >> >> > > One comment is that it might not be necessary to descibe these in such detail in the charter, instead it might be enough to shortly list these. > > >> This list should not be considered exhaustive, and methods may be >> removed or added as additional application spaces and requirements are >> found. The list gives examples of the types of methods to be >> investigated. >> > > It should be explicitly said that the goal of the WG with regard to security bootstrapping is not to develop any new protocols. Instead these methods recommend how to use existing protocols in a constrained configuration. > > >> Security can be achieved using other session security or object >> security. For session security, the WG will work with the security area >> to select cipher suites most useful for constrained network. For object >> security, CoAP will initially look at CMS (RFC 5652). >> > > Mentioning TLS/DTLS would be a good idea. > ..and EAP. Perhaps again this needs to be less specific and "the WG will work with the security area to select cipher suites and protocols most suitable for constrained networks" might be sufficient. I wouldn't call out CMS either at this stage. > >> The WG will coordinate on requirements from many organizations including >> OpenSG/NIST, ZigBee/HomePlug, IPSO Alliance, OASIS, SENSEI; 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: >> >> Mar 2010 - Select WG document for basis of CoAP protocol >> > > I don't see this as a problem. There has been a lot of work going on already in December and January, the chartering process is going on in parallel. As SE 2.0 has a real need to be able to point at a document - this is a necessary milestone. > > >> Dec 2010 - CoAP protocol specification with mapping to HTTP Rest API >> submitted to IESG as PS >> > > Does this really need to be a separate RFC? From the BOF I had a feeling we should integrate this mapping with the main CoAP protocol document. Instead, I would find it much more valuable to have the security bootstrapping as its own RFC. > > Zach > > > >> Jan 2011 - Recharter to add things reduced out of initial scope >> >> >> _______________________________________________ >> 6lowapp mailing list >> 6lowapp@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowapp >> > > --------------030106050302050205050405 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Some comments below bracketed by <RCC></RCC>. I generally agree with Zach's comments unless stated.

Robert

Robert Cragie (Pacific Gas & Electric)

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



Zach Shelby wrote: 
More comments in-line: 

On Jan 25, 2010, at 1:25 , Cullen Jennings wrote:

  
I tired to incorporate the discussion on the list and the discussion from he BOF into a revised charter proposal. I'd like to see if there were any feedback early this week then, if things look like this charter is close, send this to Lisa (our AD) and see if this can make it on the next IESG call. 

Cullen

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


CoRE

Applications are being developed for IP networks that have very limited
packet sizes, exhibit a high degree of packet loss, and have 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 applications 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. These networks are becoming increasing important
for applications such as home and building automation, energy
management, and the Internet of Things. This working group will define a
framework for a limited class of applications that deal with the
manipulation of simple resources on constrained devices. This includes
applications to monitor simple sensors (e.g.  temperature sensors, light
switches, and power meters) and control actuators (e.g. light switches,
heating controllers, and door locks).

The general architecture consists of nodes on the constrained network,
called Devices, that have one or more Resources that may represent
sensors, actuators, or other values. 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. As part of the framework for building these
applications, the WG will define a Constrained-node/network Application
Protocol (CoAP) for the manipulation of Resources on a Device.
    


  
The
framework will also specify a way to define new interface profiles that
vendors and other standards bodies can use to define the particular
Resources on a Device and what manipulations are possible.
    

Remove the above sentence. 

  
CoAP will be designed to be used between Devices on the same constrained
network, between Devices and general nodes on the internet, and between
devices on different constrained networks both joined to the internet.

There also may be nodes called Constrained-to-General-Internet
Intermediaries (CoGII) that interconnect between other protocols
typically used by applications on the internet and the Devices using the
CoAP protocol.  
    

Remove this sentence (see, no more CoGIIs).


  
The WG will define a mapping on the CoGII from CoAP to
an HTTP REST API; this mapping will not depend on a specific
application.
    

Remove CoGII. Combine with some paragraph above. Add "It is worth noting that this mapping does not have to be deployed at the boundary of the constrained network and the more general network but can be deployed at various locations in the unconstrained network."
<RCC>I don't think you need to say anything about deployment - it's a mapping.</RCC>

  
 Each interface profile will define the Resources on the
Device that applications can manipulate and what manipulations are
possible.  This will determine, in a mechanical translation way, the
HTTP REST APIs on the CoGIIs and the CoAP protocol encoding to
manipulate the Resources on the Device; it will also specify an XML MIME
type for each class of Device that can be used to describe the Resource
state in the body of HTTP REST messages. It is worth noting that the
CoGII does not have to be deployed at the boundary of the constrained
network and the more general network but can be deployed at various
locations in the unconstrained network.
    

Remove all this stuff, this has to do with profiles etc.
<RCC>I agree, it's unnecessarily specific</RCC>
  
CoGIIs can provide 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 CoGII that has subscribed, when
the CoGII 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. The CoGIIs may also provide support
for discovering Devices that may not be currently responding as they are
temporarily asleep.
    

Replace with something like this:

CoAP can be cached in various ways. For example, if a temperature sensor 
is normally asleep but wakes up every five minutes and sends the current 
temperature to an intermediate subscriber, when the intermediate 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>I don't think you can get away with removing the concept of a CoGII. It's all gone a bit hand-wavy now going on about caching at 'intermediate subscriber' (aka CoGII?) nodes. In my experience, managing data for sleeping nodes is one of the more complex and overlooked aspects of sensor networks and needs to be focused on not dissolved away like this.</RCC> 
  
The initial work items of the WG is to define a protocol specification
for CoAP that includes:

1) A way to define the "interface profile" that specifies the Resources
  for a Device and implies the REST API that can be used
    

Remove.

  
2) The ability to set and query a resource on a Device.

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

4) 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
  simultaneously.  The goals would be delivery of messages roughly
  within 50 ms of each other for closely located Devices on suitable
  networks to meet the use case of several lights appearing to turn on
  at the same time to a human observer.
    

Update a la Lars
<RCC>I think the original statement is fine if you just remove "roughly within 50ms of each other"</RCC>
  
5) Default operation of the protocol will be over UDP; it may optionally
  use TCP or other reliable transports.

    

Update a la Lars
<RCC>I think the original statement is almost OK. I would perhaps reword as follows: "Default operation of the protocol will be over UDP, however it will not be precluded from operating over TCP or other reliable transports". This would address the 'wider internet' concern. I don't particularly see the point in having options only suitable for TCP, for example - this goes against the whole point of CoAP.</RCC>
 
  
6) A definition of how to use CoAP to discover Devices on the
  constrained network, and to interrogate them to find out which
  interface profiles they support.  The name taxonomy used for
  discovery will be consistent with the approach defined in
  draft-cheshire-dnsext-dns-sd.
    

Update to something like:

The ability for CoAP to be used for the discovery of Devices and resource on 
the constrained network. The details of discovery and profile formats are out of
scope. They may be defined by applications using CoAP or by the WG at a later time if 
necessary.


  
7) An ability for Devices to provide a pointer to the general schema
  information so that a CoGII does not need any code changes to support
  new Device classes.
    

Remove.

  
8) Specification for the HTTP REST based API and mapping on the CoGII to
  communicate with Devices.
    

Remove CoGII.

  
The working group will not develop a reliable multicast solution.

Security, particularly keying of new Devices, is very challenging for
these applications. On one hand this needs to support models in which an
end user can introduce onto their network a new Device that may have no
display or input capabilities. On the other hand, this protocol may
transport information about alarm systems or controlling door locks over
a wireless network.
<RCC>
Security is always 'very challenging' ;-). The 'on one hand/on the other hand' statement implies opposites but the statements are not logically related. I would perhaps rephrase something like the following:

"There are two main aspects of security which need special consideration in these applications. There must be support for introduction of Devices that may have no display or input capabilities onto the network. Also, support for high security is essential as this protocol may transport information about alarm systems or controlling door locks over a wireless network."
</RCC>
The WG will work to support methods of security bootstrapping which are
realistic given the constraints and requirements of the network. These
methods are not specific to any communication layer. Instead the methods
could run across any layer, including IP. Requirements considered
include:
<RCC>Remove "Instead the methods could run across any layer, including IP"</RCC>
1) The methods need to be suitable for use on resource constrained
  nodes. These constraints include power, cost, size, and computational
  capacity. [[ Note: the WG realizes the vagueness of this constraint
  but does not currently have consensus on a more quantitative metric
  of these constraints ]]
<RCC>I think we have already defined constrained node/network so I don't see the need to repeat it here. The only additional property specifically relevant for security called out above is computational capacity; maybe this could be incorporated in the original definition.</RCC>
2) The methods need to provide sufficient security for the application
  space.
<RCC>I think the statement is rather vague. Perhaps something like "the methods need to support a wide range of security requirements coming from the application space"</RCC>
3) The methods must guarantee that any two nodes can join together. This
  includes nodes which are already on separate networks which a user
  wishes to merge together.
<RCC>
There are two things here:

1) It would always be a policy decision whether two nodes can join together, so I would rephrase as "the methods must support the joining of two nodes"
2) You have opened up a large can of worms when talking about merging networks. This has many implications beyond joining two nodes
</RCC>

4) There may be additional requirements for each application space, such
  as urban or commercial environments which deploy large networks,
  compared to residential environments.

To ensure that any two nodes can join together, all nodes must implement
at least one universal method. In additional several other methods will
be specified which take advantage of the application space. In
commercial applications, for instance, bootstrapping can take advantage
of the fact that networks are typically managed from a central
authority, and a method optimized for residential usage might take
advantage of the fact that nodes are in close proximity.

Methods which will be considered include:

1) Out of Band Key or Certificate: In this mode a key (either symmetric
  or asymmetric) is distributed with the product, such as a 2D barcode
  printed on the node. The user can scan this key with a computer to
  give access to this node.
<RCC>There are also polynomial-based key distribution methods which may be appropriate. Perhaps the statement above should be less specific.</RCC>
2) Physical Button Protocol: In this mode two nodes only require
  pushbuttons and LEDs, and the user simply pushes the button on each
  node within a narrow time window to join them together.

3) Out of Band Communication Link: This could include IrDA or NFC (Near
  Field Communication) type technologies to allow a device to join
  another device that is physically nearby.

4) Out of Band Configuration: A simple example of this would be using
  the programming interface which a node uses to download firmware.

    

One comment is that it might not be necessary to descibe these in such detail in the charter, instead it might be enough to shortly list these. 

  
This list should not be considered exhaustive, and methods may be
removed or added as additional application spaces and requirements are
found. The list gives examples of the types of methods to be
investigated.
    

It should be explicitly said that the goal of the WG with regard to security bootstrapping is not to develop any new protocols. Instead these methods recommend how to use existing protocols in a constrained configuration.

  
Security can be achieved using other session security or object
security.  For session security, the WG will work with the security area
to select cipher suites most useful for constrained network.  For object
security, CoAP will initially look at CMS (RFC 5652).
    

Mentioning TLS/DTLS would be a good idea.
<RCC>..and EAP. Perhaps again this needs to be less specific and "the WG will work with the security area to select cipher suites and protocols most suitable for constrained networks" might be sufficient. I wouldn't call out CMS either at this stage.</RCC>
  
The WG will coordinate on requirements from many organizations including
OpenSG/NIST, ZigBee/HomePlug, IPSO Alliance, OASIS, SENSEI; 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:

Mar 2010 - Select WG document for basis of CoAP protocol
    

I don't see this as a problem. There has been a lot of work going on already in December and January, the chartering process is going on in parallel. As SE 2.0 has a real need to be able to point at a document - this is a necessary milestone. 

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

Does this really need to be a separate RFC? From the BOF I had a feeling we should integrate this mapping with the main CoAP protocol document. Instead, I would find it much more valuable to have the security bootstrapping as its own RFC. 

Zach


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


_______________________________________________
6lowapp mailing list
6lowapp@ietf.org
https://www.ietf.org/mailman/listinfo/6lowapp
--------------030106050302050205050405-- --------------ms020900000109090104030508 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 GgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDAx MjYxMjM2MzhaMCMGCSqGSIb3DQEJBDEWBBQzV7rlo1aXRdrVAtRnWTK8++RQMDBfBgkqhkiG 9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpgg E7/iD53vjpAfMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpggE7/iD53vjpAfMA0GCSqGSIb3DQEBAQUA BIIBALCqB1ic62OdLQL4xO/YADaOsGOX3Wqc5YJxJJiLC9eYr/ynMLolWxRIdCvW35UYXDE9 7yneb8fbS57GmBgUI+HPQzGHHJs1tfcdt2+WeS1Xqs3sAkuMMs9pS2CHLVTVz3I7ypATNiKB Ho6o++oeGwMrIDJXTZFfblvCIyjBPBwk2DFRzPfzGbNjU/tvnkDxvDuk7WyOBxthzaIJWrST ALrobBw8hrNbN4/b3JrGVwZ6FLMJ2tqskFZove55WI0RwbK7Vu/lxtA4O61Th0XRtIO4P5S6 XvHRssLleYU1lgHPoU+vBTN5Tz1Vee8e34O4MmmVDL930MeMybKTPbRT9UgAAAAAAAA= --------------ms020900000109090104030508-- From d.sturek@att.net Tue Jan 26 05:43:53 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 923653A685A for <6lowapp@core3.amsl.com>; Tue, 26 Jan 2010 05:43:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=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 ng-Fq9MPWz8P for <6lowapp@core3.amsl.com>; Tue, 26 Jan 2010 05:43:52 -0800 (PST) Received: from smtp108.sbc.mail.mud.yahoo.com (smtp108.sbc.mail.mud.yahoo.com [68.142.198.106]) by core3.amsl.com (Postfix) with SMTP id E620F3A6822 for <6lowapp@ietf.org>; Tue, 26 Jan 2010 05:43:51 -0800 (PST) Received: (qmail 71216 invoked from network); 26 Jan 2010 13:43:59 -0000 Received: from adsl-69-224-191-28.dsl.sndg02.pacbell.net (d.sturek@69.224.191.28 with login) by smtp108.sbc.mail.mud.yahoo.com with SMTP; 26 Jan 2010 05:43:58 -0800 PST X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: B9DUoYQVM1lRjaDwTFpp8qCWwUZUIRLxxTcuf_3OHXPsHXDw4Z3txyWrxBP2ihID1YVBbvM6GOPrn1UcLoU0lTOZm_x7GtyuGfx6o31ZubMxsoib0Y6KWGajmUhBVhMcw65bedAshyJH3icnM6hsTYHwZ05LKarV8lplRhd_bqGTvPvFNn__3bcTC6fxedBkxGgBIVVhx25dGVxnsvubR._DzFIJcjnhtUQb6QddlfMVTweLEzfK9eYnj9PtzTLN7ayJHfwQ8rK_k0GEOuUEB71ChPaTp_3DD6SkwlEC8QUKwGrg4sh8jbyhxyVC3jbmkSoy2jupHz0nOV4La92ffnxtxAME0HLt7rGqT3yqsufA57.bGcG1oC.u_RQhSYP6iS5qjuyh0jg2p0sRzWODS0Ry3Osio5CVDLu63d_LnveTGpX5KBq2zCxVOeXMP9SnmxJLwYpQQsQIZkk- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Zach Shelby'" , "'Guido Moritz'" References: <0B3D3615-F1AB-4067-B758-0A988C10CD98@sensinode.com> <004201ca9aa8$55d02cd0$01708670$@moritz@uni-rostock.de> In-Reply-To: Date: Tue, 26 Jan 2010 05:43:53 -0800 Message-ID: <007601ca9e8d$9a3a9bb0$ceafd310$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqedjZux8US2eACQHGVTAD7wkEgdgAFuzpQ Content-Language: en-us Cc: '6LoWAPP' <6lowapp@ietf.org> Subject: Re: [6lowapp] draft-shelby-6lowapp-coap-00 X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net 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, 26 Jan 2010 13:43:53 -0000 Hi Zach, I agree we need to keep CoAp a simple REST implementation. Reviewing = DPWS and other OASIS protocols is fine as long as we keep CoAp simple. =20 We have done our job correctly if something like DPWS over CoAp becomes = a reality and we haven't if we find CoAp now is an annex of the OASIS WS specifications. Don -----Original Message----- From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On = Behalf Of Zach Shelby Sent: Tuesday, January 26, 2010 2:56 AM To: Guido Moritz Cc: 6LoWAPP Subject: Re: [6lowapp] draft-shelby-6lowapp-coap-00 On Jan 21, 2010, at 16:45 , Guido Moritz wrote: > Dear Zach, >=20 > personally I am quite familiar with DPWS (see my I-D in 6LoWAPP), but = I may > have some more commends on this. I would like to propose to have look = on > DPWS, WS-Discovery, and SOAP-over-UDP specs at OASIS. They might point = to > some conceptual solutions useful for COAP. Please find more comments = below > in the text. >=20 Yes, I do agree with this approach. We would be happy to explore that in = the text of http://www.ietf.org/id/draft-shelby-6lowapp-coap-00.txt.=20 In my opinion a goal of this new WG should be to cooperate with OASIS to explore how a future extension to the DPWS paradigm (DPWS for CoAP?) = could make use of CoAP in these environments. CoAP should only provide the = basic protocol mechanism... just as DPWS makes use of HTTP and SOAP-over-UDP today.=20 > Regards, > Guido >=20 >> -----Urspr=FCngliche Nachricht----- >> Von: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] Im >> Auftrag von Zach Shelby >> Gesendet: Dienstag, 19. Januar 2010 14:37 >> An: 6LoWAPP >> Betreff: [6lowapp] draft-shelby-6lowapp-coap-00 >>=20 >> Does anyone have comments/ideas regarding = http://www.ietf.org/id/draft- >> shelby-6lowapp-coap-00.txt that we submitted before the holidays? We >> would like to start some design work, so any feedback would be really >> useful. I've identified some areas where we need input/discussion on >> the list: >>=20 >> 1. Content-type encoding (Section 2.4). Any ideas or suggestions on = how >> to encode this and what is enough space? How should such an encoding = be >> managed, ask IANA to do that? Any pointers to a similar encoding done >> elsewhere? > Encoding in the COAP header might be most efficient way, especially focusing > parsing incoming headers/messages. But extensibility is quite = important and > a core feature of REST. XML send via HTTP uses "magic bytes". SOAP-over-UDP > (XML SOAP envelopes send via UDP without HTTP header) binding > implementations can use these magic bytes for data format = identification. > COAP should include same features to allow own or not prior defined = data > formats. >=20 Agreed. That could be done by reserving a range of codes for private = use, or by having a code that says something like "look at the magic bytes in = the payload"? >>=20 >> 2. Caching (Section 2.6). Should we go towards an in-band or an = out-of- >> band discovery approach? Personally I think an in-band approach is by >> far the simplest, although it requires some header space when = present. > Out-of-band discovery might imply overlapping with other specs (mDNS, > WS-Discovery,..). Thus, comprehensive in-band discovery seems a proper > approach. Header space should not be a problem because > methods/actions/operations of COAP are very limited. Additional information > to be included in the header for discovery purposes would have to be > included for out-of-band approaches as well but would require = additional > efforts to work on "two separated tracks". Good point. >=20 >>=20 >> 3. Subscribe/Notify (Section 2.7). This is an area that definitely >> needs discussion. The current proposal is to use a REST interface to >> create subscriptions and which are then sent using a NOTIFY message = to >> a call-back URL. How to format the body o the subscription (URL to >> subscribe to, URL call-back, parameters?). > Similar features are included in DPWS by using WS-Eventing. In > subscriptions, a client includes an endpoint for event delivery. This = is a > transport specific address including protocol and address. > But additional features might be required for a complete eventing = concept. > This includes lease management concepts and filtering concepts (e.g. = set > limits/thresholds for a temperature value). Furthermore, a data distribution > model is required. WS-Eventing uses by default unicast messages to the > clients (sinks of event). This requires one message to every = subscriber. > XMPP instead needs, due to its architecture, only one message to the server > which distributes data to all subscribed clients without need for = multiple > sendings of the originator. We should look at both in more detail. We don't have a server = architecture as in XMPP,=20 however there may a proxy (HTTP-CoAP mapping e.g.) that aggregates subscriptions on behalf of nodes. Therefore the paradigm would probably = be similar to the WS-Eventing (unicast). I think the question here is, is = there an existing payload format for including the URL call-back and other = needed subscription management parameters that we could just point at? This = would need to be simple to parse with a reasonable payload size.=20 >=20 >>=20 >> 4. Resource Discovery (Section 2.9). The proposal is to use a new >> DISCOVER method which can be sent either unicast or multicast. The = only >> difficult part there is the format of the list of resources (URLs) >> which would be returned in such a response. This is a little bit like >> index.html. We had some discussions in Hiroshima that XMPP has >> developed some ways of coding lists of URLs and that could be = re-used. >> Does someone have a pointer for us on that? > WS-Discovery specification goes one step further and combines metadata > exchange for devices and service descriptions. In the first step, a = device > itself is discovered which is a ensemble of "Hosted Services" = (services or > in COAP single resource). A single service itself provides also = metadata > (methods/operations of service) which can be queried.=20 > The new Bluetooth Low Energy Attribute Protocol uses a similar = approach to > request either all services of a attribute server or specific = attributes of > a service. > To sum up, I am not sure which functionalities the discovery of COAP = has to > provide, but it might require more efforts then just to define how to encode > a set of URLs. The new charter update will help us here... It seems like defining the format of these messages might be out of scope for the WG's first = charter, although the original idea was also to define a basic URL list (do we = still do that?). It may be enough to point at other formats or paradigms that could use this method for discovery. If there is interest and the need = to define one at the IETF later, then we could be re-chartered for that?=20 >=20 >>=20 >=20 > Some more comments: > -REQ2 seems quite hard. Without knowledge about design/architecture to > define a header size. This is from the charter, and it comes from the 6LoWPAN network = architecture and IEEE 802.15.4 frame sizes. I don't find it to be that difficult to = meet, from experience designing similar protocols. >=20 > -REQ3: Is it useful to make sleeping nodes to an application layer > requirement? 6LoWPAN allows seamless integration into existing = networks. To > deal with sleeping nodes always requires caching intermediates and = thus does > not permit for ad-hoc connectivity, because external endpoints cannot = be > aware of this. Sleeping nodes should be solved on link layer, without design > requirements for application layer? Locally sleeping nodes *might* very well be dealt with at the link layer = in an ad-hoc setting, but we can't make such an assumption about all link-layers (many don't) at the IETF. REQ3 does not force sleeping nodes = to be dealt with at the application layer (so your ad-hoc case will work), = but that it *can* be used to deal with sleeping nodes (e.g. caching in an HTTP-CoAP proxy) when appropriate. It is common that nodes sleep for = long periods of time in sensor networks, for endpoints somewhere on the = Internet, this can be dealt with by a caching intermediate. I think the = requirement is good to keep in mind what caching will sometimes be used for here. Zach >=20 >> Thanks, >> 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 >>=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 > _______________________________________________ > 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 _______________________________________________ 6lowapp mailing list 6lowapp@ietf.org https://www.ietf.org/mailman/listinfo/6lowapp From zach@sensinode.com Tue Jan 26 06:46: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 15DCA3A6894 for <6lowapp@core3.amsl.com>; Tue, 26 Jan 2010 06:46:28 -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 0eWR2tN9c03n for <6lowapp@core3.amsl.com>; Tue, 26 Jan 2010 06:46:26 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id CDCDF3A688B for <6lowapp@ietf.org>; Tue, 26 Jan 2010 06:46:25 -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 o0QEkS9U006484 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 26 Jan 2010 16:46:29 +0200 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: Zach Shelby In-Reply-To: <007601ca9e8d$9a3a9bb0$ceafd310$@sturek@att.net> Date: Tue, 26 Jan 2010 16:46:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3023E891-6F3F-4F35-8490-7F5400BC5153@sensinode.com> References: <0B3D3615-F1AB-4067-B758-0A988C10CD98@sensinode.com> <004201ca9aa8$55d02cd0$01708670$@moritz@uni-rostock.de> <007601ca9e8d$9a3a9bb0$ceafd310$@sturek@att.net> To: X-Mailer: Apple Mail (2.1077) Cc: '6LoWAPP' <6lowapp@ietf.org> Subject: Re: [6lowapp] 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: Tue, 26 Jan 2010 14:46:28 -0000 On Jan 26, 2010, at 15:43 , Don Sturek wrote: > Hi Zach, >=20 > I agree we need to keep CoAp a simple REST implementation. Reviewing = DPWS > and other OASIS protocols is fine as long as we keep CoAp simple. =20 >=20 > We have done our job correctly if something like DPWS over CoAp = becomes a > reality and we haven't if we find CoAp now is an annex of the OASIS WS > specifications. Exactly. CoAP's goal is to support very light-weight RESTful = interactions for constrained device environments. Just as HTTP can be = used for WS purposes, CoAP should also be useful. There are a bunch of = shortcomings in HTTP such as the lack of multicast and subscribe/notify = - by fixing those in CoAP will enable simple REST applications, which = also benefits use for e.g. DPWS or other WS-* if they so wish to bind to = CoAP. Zach >=20 > Don >=20 >=20 > -----Original Message----- > From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On = Behalf > Of Zach Shelby > Sent: Tuesday, January 26, 2010 2:56 AM > To: Guido Moritz > Cc: 6LoWAPP > Subject: Re: [6lowapp] draft-shelby-6lowapp-coap-00 >=20 >=20 > On Jan 21, 2010, at 16:45 , Guido Moritz wrote: >=20 >> Dear Zach, >>=20 >> personally I am quite familiar with DPWS (see my I-D in 6LoWAPP), but = I > may >> have some more commends on this. I would like to propose to have look = on >> DPWS, WS-Discovery, and SOAP-over-UDP specs at OASIS. They might = point to >> some conceptual solutions useful for COAP. Please find more comments = below >> in the text. >>=20 >=20 > Yes, I do agree with this approach. We would be happy to explore that = in the > text of http://www.ietf.org/id/draft-shelby-6lowapp-coap-00.txt.=20 >=20 > In my opinion a goal of this new WG should be to cooperate with OASIS = to > explore how a future extension to the DPWS paradigm (DPWS for CoAP?) = could > make use of CoAP in these environments. CoAP should only provide the = basic > protocol mechanism... just as DPWS makes use of HTTP and SOAP-over-UDP > today.=20 >=20 >> Regards, >> Guido >>=20 >>> -----Urspr=FCngliche Nachricht----- >>> Von: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] Im >>> Auftrag von Zach Shelby >>> Gesendet: Dienstag, 19. Januar 2010 14:37 >>> An: 6LoWAPP >>> Betreff: [6lowapp] draft-shelby-6lowapp-coap-00 >>>=20 >>> Does anyone have comments/ideas regarding = http://www.ietf.org/id/draft- >>> shelby-6lowapp-coap-00.txt that we submitted before the holidays? We >>> would like to start some design work, so any feedback would be = really >>> useful. I've identified some areas where we need input/discussion on >>> the list: >>>=20 >>> 1. Content-type encoding (Section 2.4). Any ideas or suggestions on = how >>> to encode this and what is enough space? How should such an encoding = be >>> managed, ask IANA to do that? Any pointers to a similar encoding = done >>> elsewhere? >> Encoding in the COAP header might be most efficient way, especially > focusing >> parsing incoming headers/messages. But extensibility is quite = important > and >> a core feature of REST. XML send via HTTP uses "magic bytes". > SOAP-over-UDP >> (XML SOAP envelopes send via UDP without HTTP header) binding >> implementations can use these magic bytes for data format = identification. >> COAP should include same features to allow own or not prior defined = data >> formats. >>=20 >=20 > Agreed. That could be done by reserving a range of codes for private = use, or > by having a code that says something like "look at the magic bytes in = the > payload"? >=20 >>>=20 >>> 2. Caching (Section 2.6). Should we go towards an in-band or an = out-of- >>> band discovery approach? Personally I think an in-band approach is = by >>> far the simplest, although it requires some header space when = present. >> Out-of-band discovery might imply overlapping with other specs (mDNS, >> WS-Discovery,..). Thus, comprehensive in-band discovery seems a = proper >> approach. Header space should not be a problem because >> methods/actions/operations of COAP are very limited. Additional > information >> to be included in the header for discovery purposes would have to be >> included for out-of-band approaches as well but would require = additional >> efforts to work on "two separated tracks". >=20 > Good point. >=20 >>=20 >>>=20 >>> 3. Subscribe/Notify (Section 2.7). This is an area that definitely >>> needs discussion. The current proposal is to use a REST interface to >>> create subscriptions and which are then sent using a NOTIFY message = to >>> a call-back URL. How to format the body o the subscription (URL to >>> subscribe to, URL call-back, parameters?). >> Similar features are included in DPWS by using WS-Eventing. In >> subscriptions, a client includes an endpoint for event delivery. This = is a >> transport specific address including protocol and address. >> But additional features might be required for a complete eventing = concept. >> This includes lease management concepts and filtering concepts (e.g. = set >> limits/thresholds for a temperature value). Furthermore, a data > distribution >> model is required. WS-Eventing uses by default unicast messages to = the >> clients (sinks of event). This requires one message to every = subscriber. >> XMPP instead needs, due to its architecture, only one message to the > server >> which distributes data to all subscribed clients without need for = multiple >> sendings of the originator. >=20 > We should look at both in more detail. We don't have a server = architecture > as in XMPP,=20 > however there may a proxy (HTTP-CoAP mapping e.g.) that aggregates > subscriptions on behalf of nodes. Therefore the paradigm would = probably be > similar to the WS-Eventing (unicast). I think the question here is, is = there > an existing payload format for including the URL call-back and other = needed > subscription management parameters that we could just point at? This = would > need to be simple to parse with a reasonable payload size.=20 >=20 >>=20 >>>=20 >>> 4. Resource Discovery (Section 2.9). The proposal is to use a new >>> DISCOVER method which can be sent either unicast or multicast. The = only >>> difficult part there is the format of the list of resources (URLs) >>> which would be returned in such a response. This is a little bit = like >>> index.html. We had some discussions in Hiroshima that XMPP has >>> developed some ways of coding lists of URLs and that could be = re-used. >>> Does someone have a pointer for us on that? >> WS-Discovery specification goes one step further and combines = metadata >> exchange for devices and service descriptions. In the first step, a = device >> itself is discovered which is a ensemble of "Hosted Services" = (services or >> in COAP single resource). A single service itself provides also = metadata >> (methods/operations of service) which can be queried.=20 >> The new Bluetooth Low Energy Attribute Protocol uses a similar = approach to >> request either all services of a attribute server or specific = attributes > of >> a service. >> To sum up, I am not sure which functionalities the discovery of COAP = has > to >> provide, but it might require more efforts then just to define how to > encode >> a set of URLs. >=20 > The new charter update will help us here... It seems like defining the > format of these messages might be out of scope for the WG's first = charter, > although the original idea was also to define a basic URL list (do we = still > do that?). It may be enough to point at other formats or paradigms = that > could use this method for discovery. If there is interest and the need = to > define one at the IETF later, then we could be re-chartered for that?=20= >=20 >>=20 >>>=20 >>=20 >> Some more comments: >> -REQ2 seems quite hard. Without knowledge about design/architecture = to >> define a header size. >=20 > This is from the charter, and it comes from the 6LoWPAN network = architecture > and IEEE 802.15.4 frame sizes. I don't find it to be that difficult to = meet, > from experience designing similar protocols. >=20 >>=20 >> -REQ3: Is it useful to make sleeping nodes to an application layer >> requirement? 6LoWPAN allows seamless integration into existing = networks. > To >> deal with sleeping nodes always requires caching intermediates and = thus > does >> not permit for ad-hoc connectivity, because external endpoints cannot = be >> aware of this. Sleeping nodes should be solved on link layer, without > design >> requirements for application layer? >=20 > Locally sleeping nodes *might* very well be dealt with at the link = layer in > an ad-hoc setting, but we can't make such an assumption about all > link-layers (many don't) at the IETF. REQ3 does not force sleeping = nodes to > be dealt with at the application layer (so your ad-hoc case will = work), but > that it *can* be used to deal with sleeping nodes (e.g. caching in an > HTTP-CoAP proxy) when appropriate. It is common that nodes sleep for = long > periods of time in sensor networks, for endpoints somewhere on the = Internet, > this can be dealt with by a caching intermediate. I think the = requirement is > good to keep in mind what caching will sometimes be used for here. >=20 > Zach >=20 >>=20 >>> Thanks, >>> 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 >>>=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 >> _______________________________________________ >> 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 >=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 >=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 apezzuto@cisco.com Tue Jan 26 09:57:09 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 58F083A6876 for <6lowapp@core3.amsl.com>; Tue, 26 Jan 2010 09:57:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 IzSjA8eyJ5cx for <6lowapp@core3.amsl.com>; Tue, 26 Jan 2010 09:57:08 -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 2CF583A67E7 for <6lowapp@ietf.org>; Tue, 26 Jan 2010 09:57:08 -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: ApoEAIm7XkutJV2d/2dsb2JhbADDeZclhDkE X-IronPort-AV: E=Sophos;i="4.49,347,1262563200"; d="scan'208";a="473182953" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by sj-iport-6.cisco.com with ESMTP; 26 Jan 2010 17:57:18 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id o0QHvDO9004810; Tue, 26 Jan 2010 17:57:18 GMT Received: from xmb-ams-106.cisco.com ([144.254.74.81]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Jan 2010 18:56:21 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Jan 2010 18:56:21 +0100 Message-ID: <0D212BD466921646B58854FB79092CEC011D9BCE@XMB-AMS-106.cisco.com> In-Reply-To: <0B3D3615-F1AB-4067-B758-0A988C10CD98@sensinode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowapp] draft-shelby-6lowapp-coap-00 Thread-Index: AcqZDH2lsm4FrsCuR0ChKdEEIp3j7AFjloOw References: <0B3D3615-F1AB-4067-B758-0A988C10CD98@sensinode.com> From: "Adriano Pezzuto (apezzuto)" To: "Zach Shelby" X-OriginalArrivalTime: 26 Jan 2010 17:56:21.0595 (UTC) FILETIME=[DE631AB0:01CA9EB0] Cc: 6LoWAPP <6lowapp@ietf.org> Subject: Re: [6lowapp] 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: Tue, 26 Jan 2010 17:57:09 -0000 Hi Zach, I would to give a bit regarding CoAP/HTTP mapping and notification = messages from constrained devices to wider Internet and vice versa. Basically, the issue here is that HTTP has a synchronous = request-response model where a NOTIFY is an asynch event. Searching on = the REST literature, there is cute way to handle asynch tasks within a = synch model. Let to split the asynch operation into more synchronous = requests. The first request spawns the operation, and the other requests = let the client to be informed about the status of the operation. Let to consider a client node on the internet subscribing to a server = node for a data event notification (e.g. temperature crossing a = threshold). The server node is in the constrained environment and a = CoAP/HTTP interworking function is running between client and server. The client node makes its subscribe request by sending a POST message to = the server node. The server node accepts the request, creates a new resource representing = the event and put it in a queue. Instead of keeping the client node waiting until the event happens, the = server sends to the client (by CoAP/HTTP IWF) an HTTP 202 Accepted and = gives it a new URL that represents the new created resource. Then the client can make GET requests to that URL until the event = happens. Once the client has 'consumed' the event it can DELETE the event = resource from the server queue. Better ways exist to accomplish the same task but hope this can help. Regards, Adriano -----Original Message----- From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On = Behalf Of Zach Shelby Sent: marted=EC 19 gennaio 2010 14.37 To: 6LoWAPP Subject: [6lowapp] draft-shelby-6lowapp-coap-00 Does anyone have comments/ideas regarding = http://www.ietf.org/id/draft-shelby-6lowapp-coap-00.txt that we = submitted before the holidays? We would like to start some design work, = so any feedback would be really useful. I've identified some areas where = we need input/discussion on the list: 1. Content-type encoding (Section 2.4). Any ideas or suggestions on how = to encode this and what is enough space? How should such an encoding be = managed, ask IANA to do that? Any pointers to a similar encoding done = elsewhere? 2. Caching (Section 2.6). Should we go towards an in-band or an = out-of-band discovery approach? Personally I think an in-band approach = is by far the simplest, although it requires some header space when = present. 3. Subscribe/Notify (Section 2.7). This is an area that definitely needs = discussion. The current proposal is to use a REST interface to create = subscriptions and which are then sent using a NOTIFY message to a = call-back URL. How to format the body o the subscription (URL to = subscribe to, URL call-back, parameters?).=20 4. Resource Discovery (Section 2.9). The proposal is to use a new = DISCOVER method which can be sent either unicast or multicast. The only = difficult part there is the format of the list of resources (URLs) which = would be returned in such a response. This is a little bit like = index.html. We had some discussions in Hiroshima that XMPP has developed = some ways of coding lists of URLs and that could be re-used. Does = someone have a pointer for us on that?=20 Thanks, 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 _______________________________________________ 6lowapp mailing list 6lowapp@ietf.org https://www.ietf.org/mailman/listinfo/6lowapp From behcetsarikaya@yahoo.com Tue Jan 26 11:22:51 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 A80943A6998 for <6lowapp@core3.amsl.com>; Tue, 26 Jan 2010 11:22:51 -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 EWtD6YJ+C8y4 for <6lowapp@core3.amsl.com>; Tue, 26 Jan 2010 11:22:51 -0800 (PST) Received: from web111414.mail.gq1.yahoo.com (web111414.mail.gq1.yahoo.com [67.195.15.210]) by core3.amsl.com (Postfix) with SMTP id C8DD93A67FC for <6lowapp@ietf.org>; Tue, 26 Jan 2010 11:22:50 -0800 (PST) Received: (qmail 65432 invoked by uid 60001); 26 Jan 2010 19:22:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1264533779; bh=gi3ZI5l30Q9ECz9KE/7wI6NXoCa50+/Gx81ywonBOBg=; 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=gvcLI+Dyx1KTePqvD+w8MmFLa3tRenpstcQ/e2SMaruJiZRYYIgz8ZEjFsiMuyVj6LsHFfX+2CwkRguorhebXL7cVQFUjxKV+qvkcNMBCjj+E8kInSYMKoOcJkzg0/q5XUBaiD2d432eUHUcZRvZ1eIaEkIZHdO5tZ/XCF/f8fU= 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=s0jZr4hcsJrM69IjhStCxbfC/9tpNLqIzDGp4DWl5HYqFGjhz9m+ubnIiqn+ZY38tiwS32iAcu74ikJEokUh4bEVjGQtIhH4i9HTz+YmKMCwpcbywrCys9wMvXfFQWAvnqDs2hesDynXvb473OMPDUEXZ25y7Pe5BB7WKkt62SU=; Message-ID: <367793.55279.qm@web111414.mail.gq1.yahoo.com> X-YMail-OSG: ePp3VAkVM1lidgRSf5RSHWjoJTrDfNqaLLzqYeYRVRXc4BcrT6.E5OuTYHMmjWzqogIXqx_MueViV4.bKIyWGXUDfnfHN5E2hwBy7tcS6HOxbqGvIEJk0VchI38ZiZ6JPwKEVxA4QA1zCej8QiM6XPepbWvLe0O8VEFaCoVh6faMWMSaA2gxucCYp6ITtpQG7fNfe8F2JeDAxIpj4zXpgXgscLdn.NLog_q231F8PBuzRcuIaC3IyTO.plhCLaLp82mi8RcorSGOL6IqDOLw34TcQPUeHqu.rP8IMk8gZgBU7Uj.nBbSLW2khwGonklRRgxHjHY0XRCNR8jiaguHpbEx_42N1tZ6hV7Ilk0- Received: from [206.16.17.212] by web111414.mail.gq1.yahoo.com via HTTP; Tue, 26 Jan 2010 11:22:59 PST X-Mailer: YahooMailRC/272.7 YahooMailWebService/0.8.100.260964 References: <0B3D3615-F1AB-4067-B758-0A988C10CD98@sensinode.com> <004201ca9aa8$55d02cd0$01708670$@moritz@uni-rostock.de> <007601ca9e8d$9a3a9bb0$ceafd310$@sturek@att.net> <3023E891-6F3F-4F35-8490-7F5400BC5153@sensinode.com> Date: Tue, 26 Jan 2010 11:22:59 -0800 (PST) From: Behcet Sarikaya To: Zach Shelby , d.sturek@att.net In-Reply-To: <3023E891-6F3F-4F35-8490-7F5400BC5153@sensinode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: 6LoWAPP <6lowapp@ietf.org> Subject: Re: [6lowapp] draft-shelby-6lowapp-coap-00 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, 26 Jan 2010 19:22:51 -0000 =0A=0A=0A=0A----- Original Message ----=0A> From: Zach Shelby =0A> To: d.sturek@att.net=0A> Cc: 6LoWAPP <6lowapp@ietf.org>=0A> Sen= t: Tue, January 26, 2010 8:46:31 AM=0A> Subject: Re: [6lowapp] draft-shelby= -6lowapp-coap-00=0A> =0A> =0A> On Jan 26, 2010, at 15:43 , Don Sturek wrote= :=0A> =0A> > Hi Zach,=0A> > =0A> > I agree we need to keep CoAp a simple RE= ST implementation.=A0 Reviewing DPWS=0A> > and other OASIS protocols is fin= e as long as we keep CoAp simple.=A0 =0A> > =0A> > We have done our job cor= rectly if something like DPWS over CoAp becomes a=0A> > reality and we have= n't if we find CoAp now is an annex of the OASIS WS=0A> > specifications.= =0A> =0A> Exactly. CoAP's goal is to support very light-weight RESTful inte= ractions for =0A> constrained device environments. Just as HTTP can be used= for WS purposes, CoAP =0A> should also be useful. There are a bunch of sho= rtcomings in HTTP such as the =0A> lack of multicast and subscribe/notify -= by fixing those in CoAP will enable =0A> simple REST applications, which a= lso benefits use for e.g. DPWS or other WS-* if =0A> they so wish to bind t= o CoAP.=0A=0AI agree that application layer multicast is better for constra= ined device environments as IP multicast would be too costly.=0A=0ARegards,= =0A=0ABehcet=0A=0A=0A From lisa.dusseault@gmail.com Tue Jan 26 11: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 6FB9928C0FB for <6lowapp@core3.amsl.com>; Tue, 26 Jan 2010 11:42:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=0.900, 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 uGVDfGX0tAYL for <6lowapp@core3.amsl.com>; Tue, 26 Jan 2010 11:42:38 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by core3.amsl.com (Postfix) with ESMTP id ED1F328C0F2 for <6lowapp@ietf.org>; Tue, 26 Jan 2010 11:42:37 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 9so295559qwb.31 for <6lowapp@ietf.org>; Tue, 26 Jan 2010 11:42:46 -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=kvVCpPoy7sXsBhMqLjHBjZg2F5GC1thXMeysEzBso8c=; b=dbBelhdv6ubL8jlaovlxCZmyuAZCTC+jSOcv0DHx2Ry7ppOHHrN9O5iHHgKLi+3C9d PccjqUbGoNN0GvoUP+KPKU/dfvCK+4mAz3CamMUHlRtf+FRROJT8ZgP4Ut2spMAQcnlS D8Z4Wki80piqpYDZ4iyPCrk5MZRI1Z0m8JdUI= 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=m/xGX0vX9CXOnh2/oJmfc/cmQpT5ndwFfYp44bszzP/y6pewwzOMyv2jWTJ9ATW+Ze yXFJF79QYjLBPmjnSr6asMi6BpSxSZHIAD4eBCpxJT0+lPl/eu9fFUC5x/O0zTSp+ufq sgFUtl8Fb3uJ2fpW98vTnIuGewxRwYlb4sw7I= MIME-Version: 1.0 Received: by 10.220.125.104 with SMTP id x40mr1962828vcr.93.1264534966109; Tue, 26 Jan 2010 11:42:46 -0800 (PST) In-Reply-To: <0D212BD466921646B58854FB79092CEC011D9BCE@XMB-AMS-106.cisco.com> References: <0B3D3615-F1AB-4067-B758-0A988C10CD98@sensinode.com> <0D212BD466921646B58854FB79092CEC011D9BCE@XMB-AMS-106.cisco.com> Date: Tue, 26 Jan 2010 11:42:45 -0800 Message-ID: From: Lisa Dusseault To: "Adriano Pezzuto (apezzuto)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: 6LoWAPP <6lowapp@ietf.org> Subject: Re: [6lowapp] 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: Tue, 26 Jan 2010 19:42:39 -0000 Hi, The recently approved HYBI WG will be taking on use cases very like this. The BOF discussed documenting the "long poll" approach (a request that the client understands will not receive a response until event or timeout occurs), long-body approach (not recommending) as replacements to expensive repeated polling approaches. That ended up not being a required output of the WG according to its charter, but that WG does have expertise in how clients know when to poll or ask for a notification and how servers know that the client knows what to expect. Lisa On Tue, Jan 26, 2010 at 9:56 AM, Adriano Pezzuto (apezzuto) wrote: > Hi Zach, > I would to give a bit regarding CoAP/HTTP mapping and notification messag= es from constrained devices to wider Internet and vice versa. > > Basically, the issue here is that HTTP has a synchronous request-response= model where a NOTIFY is an asynch event. Searching on the REST literature,= there is cute way to handle asynch tasks within a synch model. Let to spli= t the asynch operation into more synchronous requests. The first request sp= awns the operation, and the other requests let the client to be informed ab= out the status of the operation. > > Let to consider a client node on the internet subscribing to a server nod= e for a data event notification (e.g. temperature crossing a threshold). Th= e server node is in the constrained environment and a CoAP/HTTP interworkin= g function is running between client and server. > > The client node makes its subscribe request by sending a POST message to = the server node. > The server node accepts the request, creates a new resource representing = the event and put it in a queue. > Instead of keeping the client node waiting until the event happens, the s= erver sends to the client (by CoAP/HTTP IWF) an HTTP 202 Accepted and gives= it a new URL that represents the new created resource. > Then the client can make GET requests to that URL until the event happens= . > Once the client has 'consumed' the event it can DELETE the event resource= from the server queue. > > Better ways exist to accomplish the same task but hope this can help. > > Regards, > Adriano > > > -----Original Message----- > From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behal= f Of Zach Shelby > Sent: marted=EC 19 gennaio 2010 14.37 > To: 6LoWAPP > Subject: [6lowapp] draft-shelby-6lowapp-coap-00 > > Does anyone have comments/ideas regarding http://www.ietf.org/id/draft-sh= elby-6lowapp-coap-00.txt that we submitted before the holidays? We would li= ke to start some design work, so any feedback would be really useful. I've = identified some areas where we need input/discussion on the list: > > 1. Content-type encoding (Section 2.4). Any ideas or suggestions on how t= o encode this and what is enough space? How should such an encoding be mana= ged, ask IANA to do that? Any pointers to a similar encoding done elsewhere= ? > > 2. Caching (Section 2.6). Should we go towards an in-band or an out-of-ba= nd discovery approach? Personally I think an in-band approach is by far the= simplest, although it requires some header space when present. > > 3. Subscribe/Notify (Section 2.7). This is an area that definitely needs = discussion. The current proposal is to use a REST interface to create subsc= riptions and which are then sent using a NOTIFY message to a call-back URL.= How to format the body o the subscription (URL to subscribe to, URL call-b= ack, parameters?). > > 4. Resource Discovery (Section 2.9). The proposal is to use a new DISCOVE= R method which can be sent either unicast or multicast. The only difficult = part there is the format of the list of resources (URLs) which would be ret= urned in such a response. This is a little bit like index.html. We had some= discussions in Hiroshima that XMPP has developed some ways of coding lists= of URLs and that could be re-used. Does someone have a pointer for us on t= hat? > > Thanks, > 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 > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp > From paduffy@cisco.com Tue Jan 26 11:45: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 D902E3A69A2 for <6lowapp@core3.amsl.com>; Tue, 26 Jan 2010 11:45:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 mtb1Wb6WIcZS for <6lowapp@core3.amsl.com>; Tue, 26 Jan 2010 11:45:39 -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 B020C28C0FB for <6lowapp@ietf.org>; Tue, 26 Jan 2010 11:45:39 -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: ApoEAAvVXkutJV2c/2dsb2JhbADCdIElCAGVd4Q5BA X-IronPort-AV: E=Sophos;i="4.49,347,1262563200"; d="scan'208";a="82254425" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rtp-iport-2.cisco.com with ESMTP; 26 Jan 2010 19:45:50 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id o0QJjnLY026038 for <6lowapp@ietf.org>; Tue, 26 Jan 2010 19:45:49 GMT Received: from xfe-rcd-102.cisco.com ([72.163.62.137]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Jan 2010 13:45:50 -0600 Received: from [10.86.254.48] ([10.86.254.48]) by xfe-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Jan 2010 13:45:49 -0600 Message-ID: <4B5F466A.2060400@cisco.com> Date: Tue, 26 Jan 2010 14:45:46 -0500 From: Paul Duffy Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: 6lowapp@ietf.org References: <0B3D3615-F1AB-4067-B758-0A988C10CD98@sensinode.com> <0D212BD466921646B58854FB79092CEC011D9BCE@XMB-AMS-106.cisco.com> In-Reply-To: <0D212BD466921646B58854FB79092CEC011D9BCE@XMB-AMS-106.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 26 Jan 2010 19:45:49.0479 (UTC) FILETIME=[2926AB70:01CA9EC0] Subject: Re: [6lowapp] draft-shelby-6lowapp-coap-00 X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: paduffy@cisco.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: Tue, 26 Jan 2010 19:45:40 -0000 Hi Adriano, Given the constraints of REST's messaging patterns, the method described below is essentially polling on an event object. Any concerns with lots of this occurring in a BW limited environment and/or battery consumption issues? On 1/26/2010 12:56 PM, Adriano Pezzuto (apezzuto) wrote: > Hi Zach, > I would to give a bit regarding CoAP/HTTP mapping and notification messages from constrained devices to wider Internet and vice versa. > > Basically, the issue here is that HTTP has a synchronous request-response model where a NOTIFY is an asynch event. Searching on the REST literature, there is cute way to handle asynch tasks within a synch model. Let to split the asynch operation into more synchronous requests. The first request spawns the operation, and the other requests let the client to be informed about the status of the operation. > > Let to consider a client node on the internet subscribing to a server node for a data event notification (e.g. temperature crossing a threshold). The server node is in the constrained environment and a CoAP/HTTP interworking function is running between client and server. > > The client node makes its subscribe request by sending a POST message to the server node. > The server node accepts the request, creates a new resource representing the event and put it in a queue. > Instead of keeping the client node waiting until the event happens, the server sends to the client (by CoAP/HTTP IWF) an HTTP 202 Accepted and gives it a new URL that represents the new created resource. > Then the client can make GET requests to that URL until the event happens. > Once the client has 'consumed' the event it can DELETE the event resource from the server queue. > > Better ways exist to accomplish the same task but hope this can help. > > Regards, > Adriano > > > -----Original Message----- > From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf Of Zach Shelby > Sent: martedì 19 gennaio 2010 14.37 > To: 6LoWAPP > Subject: [6lowapp] draft-shelby-6lowapp-coap-00 > > Does anyone have comments/ideas regarding http://www.ietf.org/id/draft-shelby-6lowapp-coap-00.txt that we submitted before the holidays? We would like to start some design work, so any feedback would be really useful. I've identified some areas where we need input/discussion on the list: > > 1. Content-type encoding (Section 2.4). Any ideas or suggestions on how to encode this and what is enough space? How should such an encoding be managed, ask IANA to do that? Any pointers to a similar encoding done elsewhere? > > 2. Caching (Section 2.6). Should we go towards an in-band or an out-of-band discovery approach? Personally I think an in-band approach is by far the simplest, although it requires some header space when present. > > 3. Subscribe/Notify (Section 2.7). This is an area that definitely needs discussion. The current proposal is to use a REST interface to create subscriptions and which are then sent using a NOTIFY message to a call-back URL. How to format the body o the subscription (URL to subscribe to, URL call-back, parameters?). > > 4. Resource Discovery (Section 2.9). The proposal is to use a new DISCOVER method which can be sent either unicast or multicast. The only difficult part there is the format of the list of resources (URLs) which would be returned in such a response. This is a little bit like index.html. We had some discussions in Hiroshima that XMPP has developed some ways of coding lists of URLs and that could be re-used. Does someone have a pointer for us on that? > > Thanks, > Zach > > From behcetsarikaya@yahoo.com Tue Jan 26 12:37: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 5123528C0F2 for <6lowapp@core3.amsl.com>; Tue, 26 Jan 2010 12:37:13 -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 xx7rjizONYpH for <6lowapp@core3.amsl.com>; Tue, 26 Jan 2010 12:37:12 -0800 (PST) Received: from web111409.mail.gq1.yahoo.com (web111409.mail.gq1.yahoo.com [67.195.15.180]) by core3.amsl.com (Postfix) with SMTP id 710643A68C5 for <6lowapp@ietf.org>; Tue, 26 Jan 2010 12:37:12 -0800 (PST) Received: (qmail 19506 invoked by uid 60001); 26 Jan 2010 20:37:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1264538241; bh=sZZnXeF9hlsI7++Ww0V97/cjrObpZcfA9jCYJ3+1HA4=; 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=geITNy+WjtvbytWt1VgcTsvz9ohbjpEt6DS/nuLvKNXZqeXRq/FgIHkEXNPY3Rp58hgaPNA3PIF/SJ+nHGYJvfiGUINIPyY1BDEpc1hhvW5/ufCdPRTbuUNwbA3R1KgkrtoQe6L1VhsJro1rXm2B/RKLBJREAic30wJ/dP4As4k= 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=ZjwaX2+rlU37l1P57uwNncGv3XLesj7aGuE7HFiAA34II2XoFC/pCmK3VnivLRncLk5o1tmo/d6u3qo+9ciPeJX+GUqFDYzHGvtHU79z4ki5auLPw85Y/4bpbxtlBQcneQF6ayTnNFBMZNauPdxHsJHAIHw3C2y+3tPvaww+8rs=; Message-ID: <297190.19419.qm@web111409.mail.gq1.yahoo.com> X-YMail-OSG: RpyFU2kVM1nr7MUB1UsEfRNrPIEJOb047mZyJyaUMWQCVexFkeWU2vj.CxRiCFA.zCcDtCQfL4SLtP0Mm3X2MUBxd.xvlpClDbxRFvC6epO9JrYp8uHZYfcYwGXX7Vk.52VNVLODMR5aqn7kTyOFJ3bqkh_vqM7x5ORY82dWsYH83ldWQmNv9xNbZlzsvMyVmZXDrko5cbhibJgpcl29KWju_u0mNu39E5_iHiCPZAKFUZ7W8._diiOM9WsRnpwtxkLzTJ07RW.A_j53LWpU8sMHmn20roPYw4uymSS1nDeZ_q90EAbqRN7NOt0Io9_9agvfEsnGkGrG5oHvlF2au0odDqq5cfTNp__5T7lAZq3VECFuT8H9 Received: from [206.16.17.212] by web111409.mail.gq1.yahoo.com via HTTP; Tue, 26 Jan 2010 12:37:21 PST X-Mailer: YahooMailRC/272.7 YahooMailWebService/0.8.100.260964 References: <0B3D3615-F1AB-4067-B758-0A988C10CD98@sensinode.com> <004201ca9aa8$55d02cd0$01708670$@moritz@uni-rostock.de> <007601ca9e8d$9a3a9bb0$ceafd310$@sturek@att.net> <3023E891-6F3F-4F35-8490-7F5400BC5153@sensinode.com> <367793.55279.qm@web111414.mail.gq1.yahoo.com> Date: Tue, 26 Jan 2010 12:37:21 -0800 (PST) From: Behcet Sarikaya To: 6LoWAPP <6lowapp@ietf.org> In-Reply-To: <367793.55279.qm@web111414.mail.gq1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [6lowapp] Multicast support in CoAP 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, 26 Jan 2010 20:37:13 -0000 Forwarding Guido's question to the list.=0A=0A=0A=0A----- Forwarded Message= ----=0A> From: Guido Moritz =0A> To: Behcet S= arikaya =0A> Sent: Tue, January 26, 2010 2:20:08 PM=0A> = Subject: AW: [6lowapp] draft-shelby-6lowapp-coap-00=0A> =0A> Please can you= go more into detail why IP layer multicast is too=0A> expensive/more expen= sive than application layer multicast?=0A> =0A> IP layer implies further ef= forts for group membership management and=0A> multicast routing. But if IP = layer routing is used, it is the most energy=0A> efficient way for data dis= semination for the overall sensor network. Indeed,=0A> problem is group man= agement through routers.=0A> =0A> In contrast, application layer multicast = needs single unicast connections to=0A> every endpoint. This has a signific= ant influence on energy consumption of=0A> the originator and even for 'rou= ting' intermediate nodes in scenarios with=0A> many endpoints. However, app= lication layer multicast requires group=0A> membership managements as well,= but require no specific routing effort=0A> because only unicast messages a= re assumed.=0A> =0A> Thank you for clarification in advance,=0A> Guido=0A> = =0A> > -----Urspr=FCngliche Nachricht-----=0A> > Von: 6lowapp-bounces@ietf.= org [mailto:6lowapp-bounces@ietf.org] Im=0A> > Auftrag von Behcet Sarikaya= =0A> > Gesendet: Dienstag, 26. Januar 2010 20:23=0A> > An: Zach Shelby; d.s= turek@att.net=0A> > Cc: 6LoWAPP=0A> > Betreff: Re: [6lowapp] draft-shelby-6= lowapp-coap-00=0A> > =0A> > =0A> > =0A> > =0A> > =0A> > ----- Original Mess= age ----=0A> > > From: Zach Shelby =0A> > > To: d.sturek@att.net=0A> > > Cc= : 6LoWAPP <6lowapp@ietf.org>=0A> > > Sent: Tue, January 26, 2010 8:46:31 AM= =0A> > > Subject: Re: [6lowapp] draft-shelby-6lowapp-coap-00=0A> > >=0A> > = >=0A> > > On Jan 26, 2010, at 15:43 , Don Sturek wrote:=0A> > >=0A> > > > H= i Zach,=0A> > > >=0A> > > > I agree we need to keep CoAp a simple REST impl= ementation.=0A> > Reviewing DPWS=0A> > > > and other OASIS protocols is fin= e as long as we keep CoAp simple.=0A> > > >=0A> > > > We have done our job = correctly if something like DPWS over CoAp=0A> > becomes a=0A> > > > realit= y and we haven't if we find CoAp now is an annex of the OASIS=0A> > WS=0A> = > > > specifications.=0A> > >=0A> > > Exactly. CoAP's goal is to support ve= ry light-weight RESTful=0A> > interactions for=0A> > > constrained device e= nvironments. Just as HTTP can be used for WS=0A> > purposes, CoAP=0A> > > s= hould also be useful. There are a bunch of shortcomings in HTTP such=0A> > = as the=0A> > > lack of multicast and subscribe/notify - by fixing those in = CoAP will=0A> > enable=0A> > > simple REST applications, which also benefit= s use for e.g. DPWS or=0A> > other WS-* if=0A> > > they so wish to bind to = CoAP.=0A> > =0A> > I agree that application layer multicast is better for c= onstrained=0A> > device environments as IP multicast would be too costly.= =0A> > =0A> > Regards,=0A> > =0A> > Behcet=0A> > =0A> > =0A> > =0A> > _____= __________________________________________=0A> > 6lowapp mailing list=0A> >= 6lowapp@ietf.org=0A> > https://www.ietf.org/mailman/listinfo/6lowapp=0A=0A= =0A=0A From d.sturek@att.net Tue Jan 26 12:43:08 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 ACADD28C0EC for <6lowapp@core3.amsl.com>; Tue, 26 Jan 2010 12:43:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.134 X-Spam-Level: * X-Spam-Status: No, score=1.134 tagged_above=-999 required=5 tests=[AWL=1.950, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=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 6xlrAf8nyg70 for <6lowapp@core3.amsl.com>; Tue, 26 Jan 2010 12:43:07 -0800 (PST) Received: from smtp105.sbc.mail.gq1.yahoo.com (smtp105.sbc.mail.gq1.yahoo.com [67.195.14.108]) by core3.amsl.com (Postfix) with SMTP id 91CF63A69B7 for <6lowapp@ietf.org>; Tue, 26 Jan 2010 12:43:07 -0800 (PST) Received: (qmail 66991 invoked from network); 26 Jan 2010 20:43:19 -0000 Received: from adsl-69-224-191-28.dsl.sndg02.pacbell.net (d.sturek@69.224.191.28 with login) by smtp105.sbc.mail.gq1.yahoo.com with SMTP; 26 Jan 2010 12:43:18 -0800 PST X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: bHWpvjEVM1kJurNqMEd43SQuhX2KuXKG5A83DZnsqb3kut19a4KhTND6iUO4fmW.4jixnKSyACf9RHHSCxCOxdgH_ztOFtEXOIX906D5gTmKDiu1bBfN6QIR0GPlSpD8KP26HP2ns_UBhRmhodUjdnxBS5DAofCUX2u2qhFR_Euc2AU50lv49_FfXHY42xnpJe1O66xw4aC.ICwXiYfhV6yW6tjunOCEmymhdgMdMMRV7Q8WT73fRF7c0VoWab7xivuY3yGtC0TW1oP.LcqkDbxf7HLgtmzchcSy4z_OT5bDj1gSIUQ- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: , <6lowapp@ietf.org> References: <0B3D3615-F1AB-4067-B758-0A988C10CD98@sensinode.com> <0D212BD466921646B58854FB79092CEC011D9BCE@XMB-AMS-106.cisco.com> <4B5F466A.2060400@cisco.com> In-Reply-To: <4B5F466A.2060400@cisco.com> Date: Tue, 26 Jan 2010 12:43:13 -0800 Message-ID: <028801ca9ec8$2e5439c0$8afcad40$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqewC0JV7tgnD3hQJadnv62w4UwAgAB9Ddw Content-Language: en-us Subject: Re: [6lowapp] draft-shelby-6lowapp-coap-00 X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net 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, 26 Jan 2010 20:43:08 -0000 We should try to avoid polling. A publish/subscribe mechanism where = devices opt in for notification and then are updated asynchronously is best. Don -----Original Message----- From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On = Behalf Of Paul Duffy Sent: Tuesday, January 26, 2010 11:46 AM To: 6lowapp@ietf.org Subject: Re: [6lowapp] draft-shelby-6lowapp-coap-00 Hi Adriano, Given the constraints of REST's messaging patterns, the method=20 described below is essentially polling on an event object. Any concerns = with lots of this occurring in a BW limited environment and/or battery=20 consumption issues? On 1/26/2010 12:56 PM, Adriano Pezzuto (apezzuto) wrote: > Hi Zach, > I would to give a bit regarding CoAP/HTTP mapping and notification messages from constrained devices to wider Internet and vice versa. > > Basically, the issue here is that HTTP has a synchronous = request-response model where a NOTIFY is an asynch event. Searching on the REST = literature, there is cute way to handle asynch tasks within a synch model. Let to = split the asynch operation into more synchronous requests. The first request spawns the operation, and the other requests let the client to be = informed about the status of the operation. > > Let to consider a client node on the internet subscribing to a server = node for a data event notification (e.g. temperature crossing a threshold). = The server node is in the constrained environment and a CoAP/HTTP = interworking function is running between client and server. > > The client node makes its subscribe request by sending a POST message = to the server node. > The server node accepts the request, creates a new resource = representing the event and put it in a queue. > Instead of keeping the client node waiting until the event happens, = the server sends to the client (by CoAP/HTTP IWF) an HTTP 202 Accepted and = gives it a new URL that represents the new created resource. > Then the client can make GET requests to that URL until the event = happens. > Once the client has 'consumed' the event it can DELETE the event = resource from the server queue. > > Better ways exist to accomplish the same task but hope this can help. > > Regards, > Adriano > > > -----Original Message----- > From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On = Behalf Of Zach Shelby > Sent: marted=EC 19 gennaio 2010 14.37 > To: 6LoWAPP > Subject: [6lowapp] draft-shelby-6lowapp-coap-00 > > Does anyone have comments/ideas regarding http://www.ietf.org/id/draft-shelby-6lowapp-coap-00.txt that we = submitted before the holidays? We would like to start some design work, so any feedback would be really useful. I've identified some areas where we = need input/discussion on the list: > > 1. Content-type encoding (Section 2.4). Any ideas or suggestions on = how to encode this and what is enough space? How should such an encoding be managed, ask IANA to do that? Any pointers to a similar encoding done elsewhere? > > 2. Caching (Section 2.6). Should we go towards an in-band or an out-of-band discovery approach? Personally I think an in-band approach = is by far the simplest, although it requires some header space when present. > > 3. Subscribe/Notify (Section 2.7). This is an area that definitely = needs discussion. The current proposal is to use a REST interface to create subscriptions and which are then sent using a NOTIFY message to a = call-back URL. How to format the body o the subscription (URL to subscribe to, URL call-back, parameters?). > > 4. Resource Discovery (Section 2.9). The proposal is to use a new = DISCOVER method which can be sent either unicast or multicast. The only difficult part there is the format of the list of resources (URLs) which would be returned in such a response. This is a little bit like index.html. We = had some discussions in Hiroshima that XMPP has developed some ways of = coding lists of URLs and that could be re-used. Does someone have a pointer for = us on that? > > Thanks, > Zach > > =20 _______________________________________________ 6lowapp mailing list 6lowapp@ietf.org https://www.ietf.org/mailman/listinfo/6lowapp From peter.van.der.stok@philips.com Tue Jan 26 23:53:50 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 123A63A68B0 for <6lowapp@core3.amsl.com>; Tue, 26 Jan 2010 23:53:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 vJApd3+ejLfX for <6lowapp@core3.amsl.com>; Tue, 26 Jan 2010 23:53:48 -0800 (PST) Received: from smtpx.philips.com (smtpx.philips.com [168.87.56.21]) by core3.amsl.com (Postfix) with ESMTP id 881E03A6820 for <6lowapp@ietf.org>; Tue, 26 Jan 2010 23:53:48 -0800 (PST) Received: from nlamsexh03.connect1.local (172.16.153.24) by connect1.philips.com (172.16.156.151) with Microsoft SMTP Server (TLS) id 8.1.393.1; Wed, 27 Jan 2010 08:53:37 +0100 Received: from NLCLUEXM03.connect1.local ([172.16.157.42]) by nlamsexh03.connect1.local ([172.16.152.24]) with mapi; Wed, 27 Jan 2010 08:53:57 +0100 From: "Van Der Stok, Peter" To: "Adriano Pezzuto (apezzuto)" , Zach Shelby Date: Wed, 27 Jan 2010 08:53:51 +0100 Thread-Topic: [6lowapp] draft-shelby-6lowapp-coap-00 Thread-Index: AcqZDH2lsm4FrsCuR0ChKdEEIp3j7AFjloOwACK4E+A= Message-ID: References: <0B3D3615-F1AB-4067-B758-0A988C10CD98@sensinode.com> <0D212BD466921646B58854FB79092CEC011D9BCE@XMB-AMS-106.cisco.com> In-Reply-To: <0D212BD466921646B58854FB79092CEC011D9BCE@XMB-AMS-106.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 6LoWAPP <6lowapp@ietf.org> Subject: Re: [6lowapp] 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: Wed, 27 Jan 2010 07:53:50 -0000 Hi Zach, Adriano, I would not be too happy about polling a sleeping device. It kind of beats = the original purpose of having a subscription. Peter -----Original Message----- From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf = Of Adriano Pezzuto (apezzuto) Sent: Tuesday 26 January 2010 18:56 To: Zach Shelby Cc: 6LoWAPP Subject: Re: [6lowapp] draft-shelby-6lowapp-coap-00 Hi Zach, I would to give a bit regarding CoAP/HTTP mapping and notification messages= from constrained devices to wider Internet and vice versa. Basically, the issue here is that HTTP has a synchronous request-response m= odel where a NOTIFY is an asynch event. Searching on the REST literature, t= here is cute way to handle asynch tasks within a synch model. Let to split = the asynch operation into more synchronous requests. The first request spaw= ns the operation, and the other requests let the client to be informed abou= t the status of the operation. Let to consider a client node on the internet subscribing to a server node = for a data event notification (e.g. temperature crossing a threshold). The = server node is in the constrained environment and a CoAP/HTTP interworking = function is running between client and server. The client node makes its subscribe request by sending a POST message to th= e server node. The server node accepts the request, creates a new resource representing th= e event and put it in a queue. Instead of keeping the client node waiting until the event happens, the ser= ver sends to the client (by CoAP/HTTP IWF) an HTTP 202 Accepted and gives i= t a new URL that represents the new created resource. Then the client can make GET requests to that URL until the event happens. Once the client has 'consumed' the event it can DELETE the event resource f= rom the server queue. Better ways exist to accomplish the same task but hope this can help. Regards, Adriano -----Original Message----- From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf = Of Zach Shelby Sent: marted=EC 19 gennaio 2010 14.37 To: 6LoWAPP Subject: [6lowapp] draft-shelby-6lowapp-coap-00 Does anyone have comments/ideas regarding http://www.ietf.org/id/draft-shel= by-6lowapp-coap-00.txt that we submitted before the holidays? We would like= to start some design work, so any feedback would be really useful. I've id= entified some areas where we need input/discussion on the list: 1. Content-type encoding (Section 2.4). Any ideas or suggestions on how to = encode this and what is enough space? How should such an encoding be manage= d, ask IANA to do that? Any pointers to a similar encoding done elsewhere? 2. Caching (Section 2.6). Should we go towards an in-band or an out-of-band= discovery approach? Personally I think an in-band approach is by far the s= implest, although it requires some header space when present. 3. Subscribe/Notify (Section 2.7). This is an area that definitely needs di= scussion. The current proposal is to use a REST interface to create subscri= ptions and which are then sent using a NOTIFY message to a call-back URL. H= ow to format the body o the subscription (URL to subscribe to, URL call-bac= k, parameters?). 4. Resource Discovery (Section 2.9). The proposal is to use a new DISCOVER = method which can be sent either unicast or multicast. The only difficult pa= rt there is the format of the list of resources (URLs) which would be retur= ned in such a response. This is a little bit like index.html. We had some d= iscussions in Hiroshima that XMPP has developed some ways of coding lists o= f URLs and that could be re-used. Does someone have a pointer for us on tha= t? Thanks, 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 lega= lly privileged information. If you are not the intended recipient, please c= ontact 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 _______________________________________________ 6lowapp mailing list 6lowapp@ietf.org https://www.ietf.org/mailman/listinfo/6lowapp The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From zach@sensinode.com Wed Jan 27 00:00:18 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 7A3E83A68B0 for <6lowapp@core3.amsl.com>; Wed, 27 Jan 2010 00:00:18 -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 kikmkwB9rNLj for <6lowapp@core3.amsl.com>; Wed, 27 Jan 2010 00:00:17 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 196A03A67E1 for <6lowapp@ietf.org>; Wed, 27 Jan 2010 00:00:16 -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 o0R80NJs004640 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Jan 2010 10:00:24 +0200 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: Zach Shelby In-Reply-To: Date: Wed, 27 Jan 2010 10:00:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <49617D19-49D0-4EAB-9740-5B1926C05D9E@sensinode.com> References: <0B3D3615-F1AB-4067-B758-0A988C10CD98@sensinode.com> <0D212BD466921646B58854FB79092CEC011D9BCE@XMB-AMS-106.cisco.com> To: "Van Der Stok, Peter" X-Mailer: Apple Mail (2.1077) Cc: 6LoWAPP <6lowapp@ietf.org> Subject: Re: [6lowapp] 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: Wed, 27 Jan 2010 08:00:18 -0000 I think there is a misunderstanding there. Adriano was describing what = technique could be used on the HTTP side to realize the mapping with the = CoAP subscribe/notify feature. Obviously the CoAP side would use = asynchronous notifications sent by the sensor node, no problem there. = When a proxy (server node below) maps that to HTTP, you need to use some = kind of long pull technique between the proxy and the HTTP subscriber. = Lisa gave a good pointer that the new HYBI working group is chartered to = develop a long pull approach for HTTP - which we may be able to make use = of. Did I summarize that right Adriano? Zach On Jan 27, 2010, at 9:53 , Van Der Stok, Peter wrote: > Hi Zach, Adriano, >=20 > I would not be too happy about polling a sleeping device. It kind of = beats the original purpose of having a subscription. >=20 > Peter >=20 > -----Original Message----- > From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On = Behalf Of Adriano Pezzuto (apezzuto) > Sent: Tuesday 26 January 2010 18:56 > To: Zach Shelby > Cc: 6LoWAPP > Subject: Re: [6lowapp] draft-shelby-6lowapp-coap-00 >=20 > Hi Zach, > I would to give a bit regarding CoAP/HTTP mapping and notification = messages from constrained devices to wider Internet and vice versa. >=20 > Basically, the issue here is that HTTP has a synchronous = request-response model where a NOTIFY is an asynch event. Searching on = the REST literature, there is cute way to handle asynch tasks within a = synch model. Let to split the asynch operation into more synchronous = requests. The first request spawns the operation, and the other requests = let the client to be informed about the status of the operation. >=20 > Let to consider a client node on the internet subscribing to a server = node for a data event notification (e.g. temperature crossing a = threshold). The server node is in the constrained environment and a = CoAP/HTTP interworking function is running between client and server. >=20 > The client node makes its subscribe request by sending a POST message = to the server node. > The server node accepts the request, creates a new resource = representing the event and put it in a queue. > Instead of keeping the client node waiting until the event happens, = the server sends to the client (by CoAP/HTTP IWF) an HTTP 202 Accepted = and gives it a new URL that represents the new created resource. > Then the client can make GET requests to that URL until the event = happens. > Once the client has 'consumed' the event it can DELETE the event = resource from the server queue. >=20 > Better ways exist to accomplish the same task but hope this can help. >=20 > Regards, > Adriano >=20 >=20 > -----Original Message----- > From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On = Behalf Of Zach Shelby > Sent: marted=EC 19 gennaio 2010 14.37 > To: 6LoWAPP > Subject: [6lowapp] draft-shelby-6lowapp-coap-00 >=20 > Does anyone have comments/ideas regarding = http://www.ietf.org/id/draft-shelby-6lowapp-coap-00.txt that we = submitted before the holidays? We would like to start some design work, = so any feedback would be really useful. I've identified some areas where = we need input/discussion on the list: >=20 > 1. Content-type encoding (Section 2.4). Any ideas or suggestions on = how to encode this and what is enough space? How should such an encoding = be managed, ask IANA to do that? Any pointers to a similar encoding done = elsewhere? >=20 > 2. Caching (Section 2.6). Should we go towards an in-band or an = out-of-band discovery approach? Personally I think an in-band approach = is by far the simplest, although it requires some header space when = present. >=20 > 3. Subscribe/Notify (Section 2.7). This is an area that definitely = needs discussion. The current proposal is to use a REST interface to = create subscriptions and which are then sent using a NOTIFY message to a = call-back URL. How to format the body o the subscription (URL to = subscribe to, URL call-back, parameters?). >=20 > 4. Resource Discovery (Section 2.9). The proposal is to use a new = DISCOVER method which can be sent either unicast or multicast. The only = difficult part there is the format of the list of resources (URLs) which = would be returned in such a response. This is a little bit like = index.html. We had some discussions in Hiroshima that XMPP has developed = some ways of coding lists of URLs and that could be re-used. Does = someone have a pointer for us on that? >=20 > Thanks, > 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 >=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 > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp >=20 > The information contained in this message may be confidential and = legally protected under applicable law. The message is intended solely = for the addressee(s). If you are not the intended recipient, you are = hereby notified that any use, forwarding, dissemination, or reproduction = of this message is strictly prohibited and may be unlawful. If you are = not the intended recipient, please contact the sender by return e-mail = and destroy all copies of the original message. --=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 dromasca@avaya.com Wed Jan 27 00:04:52 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 77DD63A67E1 for <6lowapp@core3.amsl.com>; Wed, 27 Jan 2010 00:04:52 -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.421, 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 Pjqckaa6BZgM for <6lowapp@core3.amsl.com>; Wed, 27 Jan 2010 00:04:51 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id D703E3A63D3 for <6lowapp@ietf.org>; Wed, 27 Jan 2010 00:04:50 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,352,1262581200"; d="scan'208";a="174105514" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 27 Jan 2010 03:05:02 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.11]) by co300216-co-erhwest-out.avaya.com with ESMTP; 27 Jan 2010 03:05:01 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 Jan 2010 09:04:54 +0100 Message-ID: In-Reply-To: <028801ca9ec8$2e5439c0$8afcad40$@sturek@att.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowapp] draft-shelby-6lowapp-coap-00 Thread-Index: AcqewC0JV7tgnD3hQJadnv62w4UwAgAB9DdwABeqgaA= References: <0B3D3615-F1AB-4067-B758-0A988C10CD98@sensinode.com> <0D212BD466921646B58854FB79092CEC011D9BCE@XMB-AMS-106.cisco.com><4B5F466A.2060400@cisco.com> <028801ca9ec8$2e5439c0$8afcad40$@sturek@att.net> From: "Romascanu, Dan (Dan)" To: , , <6lowapp@ietf.org> Subject: Re: [6lowapp] 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: Wed, 27 Jan 2010 08:04:52 -0000 I would agree that asynchronous notifications as a default are a better = model in a resource constrained environment. Polling could be used as an = option when resources allow. The architecture and philosophy is similar = to the one used in network management where devices send notifications = at boot time (coldStart) or when an application initializes (warmStart), = while a management application (typically not powered constrained) may = poll periodically the devices to make sure notifications were not lost.=20 Dan > -----Original Message----- > From: 6lowapp-bounces@ietf.org=20 > [mailto:6lowapp-bounces@ietf.org] On Behalf Of Don Sturek > Sent: Tuesday, January 26, 2010 10:43 PM > To: paduffy@cisco.com; 6lowapp@ietf.org > Subject: Re: [6lowapp] draft-shelby-6lowapp-coap-00 >=20 > We should try to avoid polling. A publish/subscribe=20 > mechanism where devices opt in for notification and then are=20 > updated asynchronously is best. >=20 > Don >=20 >=20 > -----Original Message----- > From: 6lowapp-bounces@ietf.org=20 > [mailto:6lowapp-bounces@ietf.org] On Behalf Of Paul Duffy > Sent: Tuesday, January 26, 2010 11:46 AM > To: 6lowapp@ietf.org > Subject: Re: [6lowapp] draft-shelby-6lowapp-coap-00 >=20 > Hi Adriano, >=20 > Given the constraints of REST's messaging patterns, the=20 > method described below is essentially polling on an event=20 > object. Any concerns with lots of this occurring in a BW=20 > limited environment and/or battery consumption issues? >=20 >=20 > On 1/26/2010 12:56 PM, Adriano Pezzuto (apezzuto) wrote: > > Hi Zach, > > I would to give a bit regarding CoAP/HTTP mapping and notification > messages from constrained devices to wider Internet and vice versa. > > > > Basically, the issue here is that HTTP has a synchronous=20 > > request-response > model where a NOTIFY is an asynch event. Searching on the=20 > REST literature, there is cute way to handle asynch tasks=20 > within a synch model. Let to split the asynch operation into=20 > more synchronous requests. The first request spawns the=20 > operation, and the other requests let the client to be=20 > informed about the status of the operation. > > > > Let to consider a client node on the internet subscribing=20 > to a server=20 > > node > for a data event notification (e.g. temperature crossing a=20 > threshold). The server node is in the constrained environment=20 > and a CoAP/HTTP interworking function is running between=20 > client and server. > > > > The client node makes its subscribe request by sending a=20 > POST message=20 > > to > the server node. > > The server node accepts the request, creates a new resource=20 > > representing > the event and put it in a queue. > > Instead of keeping the client node waiting until the event happens,=20 > > the > server sends to the client (by CoAP/HTTP IWF) an HTTP 202=20 > Accepted and gives it a new URL that represents the new=20 > created resource. > > Then the client can make GET requests to that URL until the=20 > event happens. > > Once the client has 'consumed' the event it can DELETE the event=20 > > resource > from the server queue. > > > > Better ways exist to accomplish the same task but hope this=20 > can help. > > > > Regards, > > Adriano > > > > > > -----Original Message----- > > From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On=20 > > Behalf > Of Zach Shelby > > Sent: marted=EC 19 gennaio 2010 14.37 > > To: 6LoWAPP > > Subject: [6lowapp] draft-shelby-6lowapp-coap-00 > > > > Does anyone have comments/ideas regarding > http://www.ietf.org/id/draft-shelby-6lowapp-coap-00.txt that=20 > we submitted before the holidays? We would like to start some=20 > design work, so any feedback would be really useful. I've=20 > identified some areas where we need input/discussion on the list: > > > > 1. Content-type encoding (Section 2.4). Any ideas or suggestions on=20 > > how to > encode this and what is enough space? How should such an=20 > encoding be managed, ask IANA to do that? Any pointers to a=20 > similar encoding done elsewhere? > > > > 2. Caching (Section 2.6). Should we go towards an in-band or an > out-of-band discovery approach? Personally I think an in-band=20 > approach is by far the simplest, although it requires some=20 > header space when present. > > > > 3. Subscribe/Notify (Section 2.7). This is an area that definitely=20 > > needs > discussion. The current proposal is to use a REST interface=20 > to create subscriptions and which are then sent using a=20 > NOTIFY message to a call-back URL. How to format the body o=20 > the subscription (URL to subscribe to, URL call-back, parameters?). > > > > 4. Resource Discovery (Section 2.9). The proposal is to use a new=20 > > DISCOVER > method which can be sent either unicast or multicast. The=20 > only difficult part there is the format of the list of=20 > resources (URLs) which would be returned in such a response.=20 > This is a little bit like index.html. We had some discussions=20 > in Hiroshima that XMPP has developed some ways of coding=20 > lists of URLs and that could be re-used. Does someone have a=20 > pointer for us on that? > > > > Thanks, > > Zach > > > > =20 >=20 > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp >=20 > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp >=20 From zach@sensinode.com Wed Jan 27 00:14: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 963DE3A681F for <6lowapp@core3.amsl.com>; Wed, 27 Jan 2010 00:14:23 -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 6a6a85xdxbKU for <6lowapp@core3.amsl.com>; Wed, 27 Jan 2010 00:14: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 3B6FE3A63D3 for <6lowapp@ietf.org>; Wed, 27 Jan 2010 00:14:20 -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 o0R8EUA2006324 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Jan 2010 10:14:31 +0200 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: Zach Shelby In-Reply-To: <49617D19-49D0-4EAB-9740-5B1926C05D9E@sensinode.com> Date: Wed, 27 Jan 2010 10:14:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0648E2DF-B4A0-4BB8-9E63-BB34765945CA@sensinode.com> References: <0B3D3615-F1AB-4067-B758-0A988C10CD98@sensinode.com> <0D212BD466921646B58854FB79092CEC011D9BCE@XMB-AMS-106.cisco.com> <49617D19-49D0-4EAB-9740-5B1926C05D9E@sensinode.com> To: Zach Shelby X-Mailer: Apple Mail (2.1077) Cc: 6LoWAPP <6lowapp@ietf.org> Subject: Re: [6lowapp] 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: Wed, 27 Jan 2010 08:14:23 -0000 And a figure may help, this is what using a long poll would look like: Sensor <--------- coap ---------> Proxy <---------- http -----------> = Client =20 CREATE subscribe /temp <<< POST subscribe /temp OK >>> OK = (/sub1) =20 * = LONG GET /sub1 = GET stays open.... */temp changes* =09 NOTIFY /temp >>> OK (/temp) OK On Jan 27, 2010, at 10:00 , Zach Shelby wrote: > I think there is a misunderstanding there. Adriano was describing what = technique could be used on the HTTP side to realize the mapping with the = CoAP subscribe/notify feature. Obviously the CoAP side would use = asynchronous notifications sent by the sensor node, no problem there. = When a proxy (server node below) maps that to HTTP, you need to use some = kind of long pull technique between the proxy and the HTTP subscriber. = Lisa gave a good pointer that the new HYBI working group is chartered to = develop a long pull approach for HTTP - which we may be able to make use = of. >=20 > Did I summarize that right Adriano? >=20 > Zach >=20 > On Jan 27, 2010, at 9:53 , Van Der Stok, Peter wrote: >=20 >> Hi Zach, Adriano, >>=20 >> I would not be too happy about polling a sleeping device. It kind of = beats the original purpose of having a subscription. >>=20 >> Peter >>=20 >> -----Original Message----- >> From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On = Behalf Of Adriano Pezzuto (apezzuto) >> Sent: Tuesday 26 January 2010 18:56 >> To: Zach Shelby >> Cc: 6LoWAPP >> Subject: Re: [6lowapp] draft-shelby-6lowapp-coap-00 >>=20 >> Hi Zach, >> I would to give a bit regarding CoAP/HTTP mapping and notification = messages from constrained devices to wider Internet and vice versa. >>=20 >> Basically, the issue here is that HTTP has a synchronous = request-response model where a NOTIFY is an asynch event. Searching on = the REST literature, there is cute way to handle asynch tasks within a = synch model. Let to split the asynch operation into more synchronous = requests. The first request spawns the operation, and the other requests = let the client to be informed about the status of the operation. >>=20 >> Let to consider a client node on the internet subscribing to a server = node for a data event notification (e.g. temperature crossing a = threshold). The server node is in the constrained environment and a = CoAP/HTTP interworking function is running between client and server. >>=20 >> The client node makes its subscribe request by sending a POST message = to the server node. >> The server node accepts the request, creates a new resource = representing the event and put it in a queue. >> Instead of keeping the client node waiting until the event happens, = the server sends to the client (by CoAP/HTTP IWF) an HTTP 202 Accepted = and gives it a new URL that represents the new created resource. >> Then the client can make GET requests to that URL until the event = happens. >> Once the client has 'consumed' the event it can DELETE the event = resource from the server queue. >>=20 >> Better ways exist to accomplish the same task but hope this can help. >>=20 >> Regards, >> Adriano >>=20 >>=20 >> -----Original Message----- >> From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On = Behalf Of Zach Shelby >> Sent: marted=EC 19 gennaio 2010 14.37 >> To: 6LoWAPP >> Subject: [6lowapp] draft-shelby-6lowapp-coap-00 >>=20 >> Does anyone have comments/ideas regarding = http://www.ietf.org/id/draft-shelby-6lowapp-coap-00.txt that we = submitted before the holidays? We would like to start some design work, = so any feedback would be really useful. I've identified some areas where = we need input/discussion on the list: >>=20 >> 1. Content-type encoding (Section 2.4). Any ideas or suggestions on = how to encode this and what is enough space? How should such an encoding = be managed, ask IANA to do that? Any pointers to a similar encoding done = elsewhere? >>=20 >> 2. Caching (Section 2.6). Should we go towards an in-band or an = out-of-band discovery approach? Personally I think an in-band approach = is by far the simplest, although it requires some header space when = present. >>=20 >> 3. Subscribe/Notify (Section 2.7). This is an area that definitely = needs discussion. The current proposal is to use a REST interface to = create subscriptions and which are then sent using a NOTIFY message to a = call-back URL. How to format the body o the subscription (URL to = subscribe to, URL call-back, parameters?). >>=20 >> 4. Resource Discovery (Section 2.9). The proposal is to use a new = DISCOVER method which can be sent either unicast or multicast. The only = difficult part there is the format of the list of resources (URLs) which = would be returned in such a response. This is a little bit like = index.html. We had some discussions in Hiroshima that XMPP has developed = some ways of coding lists of URLs and that could be re-used. Does = someone have a pointer for us on that? >>=20 >> Thanks, >> 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 >>=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 >> _______________________________________________ >> 6lowapp mailing list >> 6lowapp@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowapp >>=20 >> The information contained in this message may be confidential and = legally protected under applicable law. The message is intended solely = for the addressee(s). If you are not the intended recipient, you are = hereby notified that any use, forwarding, dissemination, or reproduction = of this message is strictly prohibited and may be unlawful. If you are = not the intended recipient, please contact the sender by return e-mail = and destroy all copies of the original message. >=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 >=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 peter.van.der.stok@philips.com Wed Jan 27 00:21: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 854203A6A18 for <6lowapp@core3.amsl.com>; Wed, 27 Jan 2010 00:21:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Clb7xNlW1fRs for <6lowapp@core3.amsl.com>; Wed, 27 Jan 2010 00:21:38 -0800 (PST) Received: from smtpx.philips.com (smtpx.philips.com [168.87.56.21]) by core3.amsl.com (Postfix) with ESMTP id A8AD83A68FC for <6lowapp@ietf.org>; Wed, 27 Jan 2010 00:21:37 -0800 (PST) Received: from nlamsexh01.connect1.local (172.16.153.11) by connect1.philips.com (172.16.156.160) with Microsoft SMTP Server (TLS) id 8.1.393.1; Wed, 27 Jan 2010 09:21:54 +0100 Received: from NLCLUEXM03.connect1.local ([172.16.157.42]) by nlamsexh01.connect1.local ([172.16.153.11]) with mapi; Wed, 27 Jan 2010 09:21:47 +0100 From: "Van Der Stok, Peter" To: Zach Shelby Date: Wed, 27 Jan 2010 09:21:44 +0100 Thread-Topic: [6lowapp] draft-shelby-6lowapp-coap-00 Thread-Index: AcqfKMZdykNO2Qv6Qfa8kFhRcyBRlAAAE8Dw Message-ID: References: <0B3D3615-F1AB-4067-B758-0A988C10CD98@sensinode.com> <0D212BD466921646B58854FB79092CEC011D9BCE@XMB-AMS-106.cisco.com> <49617D19-49D0-4EAB-9740-5B1926C05D9E@sensinode.com> <0648E2DF-B4A0-4BB8-9E63-BB34765945CA@sensinode.com> In-Reply-To: <0648E2DF-B4A0-4BB8-9E63-BB34765945CA@sensinode.com> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, nl-NL Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 6LoWAPP <6lowapp@ietf.org> Subject: Re: [6lowapp] 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: Wed, 27 Jan 2010 08:21:39 -0000 Zach, thanks for the explanation. I am quite happy about the shown construct, in the expectation that the not= ify to the proxy aggregates the accesses from/to the outside Internet, thus= reducing the impact of outside requests on the low-resource network. Greetings, peter -----Original Message----- From: Zach Shelby [mailto:zach@sensinode.com]=20 Sent: Wednesday 27 January 2010 9:15 To: Zach Shelby Cc: Van Der Stok, Peter; 6LoWAPP Subject: Re: [6lowapp] draft-shelby-6lowapp-coap-00 And a figure may help, this is what using a long poll would look like: Sensor <--------- coap ---------> Proxy <---------- http -----------> Cl= ient =20 CREATE subscribe /temp <<< POST subscribe /temp OK >>> OK (/sub1) =20 * LONG GET /sub1 GET stays open.... */temp changes* =09 NOTIFY /temp >>> OK (/temp) OK On Jan 27, 2010, at 10:00 , Zach Shelby wrote: > I think there is a misunderstanding there. Adriano was describing what te= chnique could be used on the HTTP side to realize the mapping with the CoAP= subscribe/notify feature. Obviously the CoAP side would use asynchronous n= otifications sent by the sensor node, no problem there. When a proxy (serve= r node below) maps that to HTTP, you need to use some kind of long pull tec= hnique between the proxy and the HTTP subscriber. Lisa gave a good pointer = that the new HYBI working group is chartered to develop a long pull approac= h for HTTP - which we may be able to make use of. >=20 > Did I summarize that right Adriano? >=20 > Zach >=20 > On Jan 27, 2010, at 9:53 , Van Der Stok, Peter wrote: >=20 >> Hi Zach, Adriano, >>=20 >> I would not be too happy about polling a sleeping device. It kind of bea= ts the original purpose of having a subscription. >>=20 >> Peter >>=20 >> -----Original Message----- >> From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Beha= lf Of Adriano Pezzuto (apezzuto) >> Sent: Tuesday 26 January 2010 18:56 >> To: Zach Shelby >> Cc: 6LoWAPP >> Subject: Re: [6lowapp] draft-shelby-6lowapp-coap-00 >>=20 >> Hi Zach, >> I would to give a bit regarding CoAP/HTTP mapping and notification messa= ges from constrained devices to wider Internet and vice versa. >>=20 >> Basically, the issue here is that HTTP has a synchronous request-respons= e model where a NOTIFY is an asynch event. Searching on the REST literature= , there is cute way to handle asynch tasks within a synch model. Let to spl= it the asynch operation into more synchronous requests. The first request s= pawns the operation, and the other requests let the client to be informed a= bout the status of the operation. >>=20 >> Let to consider a client node on the internet subscribing to a server no= de for a data event notification (e.g. temperature crossing a threshold). T= he server node is in the constrained environment and a CoAP/HTTP interworki= ng function is running between client and server. >>=20 >> The client node makes its subscribe request by sending a POST message to= the server node. >> The server node accepts the request, creates a new resource representing= the event and put it in a queue. >> Instead of keeping the client node waiting until the event happens, the = server sends to the client (by CoAP/HTTP IWF) an HTTP 202 Accepted and give= s it a new URL that represents the new created resource. >> Then the client can make GET requests to that URL until the event happen= s. >> Once the client has 'consumed' the event it can DELETE the event resourc= e from the server queue. >>=20 >> Better ways exist to accomplish the same task but hope this can help. >>=20 >> Regards, >> Adriano >>=20 >>=20 >> -----Original Message----- >> From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Beha= lf Of Zach Shelby >> Sent: marted=EC 19 gennaio 2010 14.37 >> To: 6LoWAPP >> Subject: [6lowapp] draft-shelby-6lowapp-coap-00 >>=20 >> Does anyone have comments/ideas regarding http://www.ietf.org/id/draft-s= helby-6lowapp-coap-00.txt that we submitted before the holidays? We would l= ike to start some design work, so any feedback would be really useful. I've= identified some areas where we need input/discussion on the list: >>=20 >> 1. Content-type encoding (Section 2.4). Any ideas or suggestions on how = to encode this and what is enough space? How should such an encoding be man= aged, ask IANA to do that? Any pointers to a similar encoding done elsewher= e? >>=20 >> 2. Caching (Section 2.6). Should we go towards an in-band or an out-of-b= and discovery approach? Personally I think an in-band approach is by far th= e simplest, although it requires some header space when present. >>=20 >> 3. Subscribe/Notify (Section 2.7). This is an area that definitely needs= discussion. The current proposal is to use a REST interface to create subs= criptions and which are then sent using a NOTIFY message to a call-back URL= . How to format the body o the subscription (URL to subscribe to, URL call-= back, parameters?). >>=20 >> 4. Resource Discovery (Section 2.9). The proposal is to use a new DISCOV= ER method which can be sent either unicast or multicast. The only difficult= part there is the format of the list of resources (URLs) which would be re= turned in such a response. This is a little bit like index.html. We had som= e discussions in Hiroshima that XMPP has developed some ways of coding list= s of URLs and that could be re-used. Does someone have a pointer for us on = that? >>=20 >> Thanks, >> 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 >>=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 l= egally privileged information. If you are not the intended recipient, pleas= e contact the sender and delete the e-mail from your system without produci= ng, distributing or retaining copies thereof. >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> 6lowapp mailing list >> 6lowapp@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowapp >> _______________________________________________ >> 6lowapp mailing list >> 6lowapp@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowapp >>=20 >> The information contained in this message may be confidential and legall= y protected under applicable law. The message is intended solely for the ad= dressee(s). If you are not the intended recipient, you are hereby notified = that any use, forwarding, dissemination, or reproduction of this message is= strictly prohibited and may be unlawful. If you are not the intended recip= ient, please contact the sender by return e-mail and destroy all copies of = the original message. >=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 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.=20 >=20 >=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 lega= lly privileged information. If you are not the intended recipient, please c= ontact the sender and delete the e-mail from your system without producing,= distributing or retaining copies thereof.=20 From apezzuto@cisco.com Wed Jan 27 00:50: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 8A6D53A6A28 for <6lowapp@core3.amsl.com>; Wed, 27 Jan 2010 00:50:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 9301KmcigEBU for <6lowapp@core3.amsl.com>; Wed, 27 Jan 2010 00:50:53 -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 B09A63A6A26 for <6lowapp@ietf.org>; Wed, 27 Jan 2010 00:50:52 -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: ApoEAAaNX0tAZnwN/2dsb2JhbADBRJcThDgE X-IronPort-AV: E=Sophos;i="4.49,352,1262563200"; d="scan'208";a="82405588" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 27 Jan 2010 08:51:02 +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 o0R8oxu1029022; Wed, 27 Jan 2010 08:51:02 GMT Received: from xmb-ams-106.cisco.com ([144.254.74.81]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Jan 2010 09:50:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 Jan 2010 09:50:53 +0100 Message-ID: <0D212BD466921646B58854FB79092CEC01248F48@XMB-AMS-106.cisco.com> In-Reply-To: <0648E2DF-B4A0-4BB8-9E63-BB34765945CA@sensinode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowapp] draft-shelby-6lowapp-coap-00 Thread-Index: AcqfKMcc/8b8XF7cTIGcKtwlYvM7xwAA6dqg References: <0B3D3615-F1AB-4067-B758-0A988C10CD98@sensinode.com><0D212BD466921646B58854FB79092CEC011D9BCE@XMB-AMS-106.cisco.com><49617D19-49D0-4EAB-9740-5B1926C05D9E@sensinode.com> <0648E2DF-B4A0-4BB8-9E63-BB34765945CA@sensinode.com> From: "Adriano Pezzuto (apezzuto)" To: "Zach Shelby" , X-OriginalArrivalTime: 27 Jan 2010 08:50:54.0291 (UTC) FILETIME=[D5CE9230:01CA9F2D] Cc: 6LoWAPP <6lowapp@ietf.org> Subject: Re: [6lowapp] 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: Wed, 27 Jan 2010 08:50:54 -0000 Thanks Zach for summarize, it's fine. Also the long poll approach suggested by Lisa, sounds better than the = expensive repeated polling approach. Adriano -----Original Message----- From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On = Behalf Of Zach Shelby Sent: mercoled=EC 27 gennaio 2010 9.15 To: Zach Shelby Cc: 6LoWAPP Subject: Re: [6lowapp] draft-shelby-6lowapp-coap-00 And a figure may help, this is what using a long poll would look like: Sensor <--------- coap ---------> Proxy <---------- http -----------> = Client =20 CREATE subscribe /temp <<< POST subscribe /temp OK >>> OK (/sub1) =20 * LONG GET /sub1 GET stays open.... */temp changes* =09 NOTIFY /temp >>> OK (/temp) OK On Jan 27, 2010, at 10:00 , Zach Shelby wrote: > I think there is a misunderstanding there. Adriano was describing what = technique could be used on the HTTP side to realize the mapping with the = CoAP subscribe/notify feature. Obviously the CoAP side would use = asynchronous notifications sent by the sensor node, no problem there. = When a proxy (server node below) maps that to HTTP, you need to use some = kind of long pull technique between the proxy and the HTTP subscriber. = Lisa gave a good pointer that the new HYBI working group is chartered to = develop a long pull approach for HTTP - which we may be able to make use = of. >=20 > Did I summarize that right Adriano? >=20 > Zach >=20 > On Jan 27, 2010, at 9:53 , Van Der Stok, Peter wrote: >=20 >> Hi Zach, Adriano, >>=20 >> I would not be too happy about polling a sleeping device. It kind of = beats the original purpose of having a subscription. >>=20 >> Peter >>=20 >> -----Original Message----- >> From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On = Behalf Of Adriano Pezzuto (apezzuto) >> Sent: Tuesday 26 January 2010 18:56 >> To: Zach Shelby >> Cc: 6LoWAPP >> Subject: Re: [6lowapp] draft-shelby-6lowapp-coap-00 >>=20 >> Hi Zach, >> I would to give a bit regarding CoAP/HTTP mapping and notification = messages from constrained devices to wider Internet and vice versa. >>=20 >> Basically, the issue here is that HTTP has a synchronous = request-response model where a NOTIFY is an asynch event. Searching on = the REST literature, there is cute way to handle asynch tasks within a = synch model. Let to split the asynch operation into more synchronous = requests. The first request spawns the operation, and the other requests = let the client to be informed about the status of the operation. >>=20 >> Let to consider a client node on the internet subscribing to a server = node for a data event notification (e.g. temperature crossing a = threshold). The server node is in the constrained environment and a = CoAP/HTTP interworking function is running between client and server. >>=20 >> The client node makes its subscribe request by sending a POST message = to the server node. >> The server node accepts the request, creates a new resource = representing the event and put it in a queue. >> Instead of keeping the client node waiting until the event happens, = the server sends to the client (by CoAP/HTTP IWF) an HTTP 202 Accepted = and gives it a new URL that represents the new created resource. >> Then the client can make GET requests to that URL until the event = happens. >> Once the client has 'consumed' the event it can DELETE the event = resource from the server queue. >>=20 >> Better ways exist to accomplish the same task but hope this can help. >>=20 >> Regards, >> Adriano >>=20 >>=20 >> -----Original Message----- >> From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On = Behalf Of Zach Shelby >> Sent: marted=EC 19 gennaio 2010 14.37 >> To: 6LoWAPP >> Subject: [6lowapp] draft-shelby-6lowapp-coap-00 >>=20 >> Does anyone have comments/ideas regarding = http://www.ietf.org/id/draft-shelby-6lowapp-coap-00.txt that we = submitted before the holidays? We would like to start some design work, = so any feedback would be really useful. I've identified some areas where = we need input/discussion on the list: >>=20 >> 1. Content-type encoding (Section 2.4). Any ideas or suggestions on = how to encode this and what is enough space? How should such an encoding = be managed, ask IANA to do that? Any pointers to a similar encoding done = elsewhere? >>=20 >> 2. Caching (Section 2.6). Should we go towards an in-band or an = out-of-band discovery approach? Personally I think an in-band approach = is by far the simplest, although it requires some header space when = present. >>=20 >> 3. Subscribe/Notify (Section 2.7). This is an area that definitely = needs discussion. The current proposal is to use a REST interface to = create subscriptions and which are then sent using a NOTIFY message to a = call-back URL. How to format the body o the subscription (URL to = subscribe to, URL call-back, parameters?). >>=20 >> 4. Resource Discovery (Section 2.9). The proposal is to use a new = DISCOVER method which can be sent either unicast or multicast. The only = difficult part there is the format of the list of resources (URLs) which = would be returned in such a response. This is a little bit like = index.html. We had some discussions in Hiroshima that XMPP has developed = some ways of coding lists of URLs and that could be re-used. Does = someone have a pointer for us on that? >>=20 >> Thanks, >> 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 >>=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 >> _______________________________________________ >> 6lowapp mailing list >> 6lowapp@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowapp >>=20 >> The information contained in this message may be confidential and = legally protected under applicable law. The message is intended solely = for the addressee(s). If you are not the intended recipient, you are = hereby notified that any use, forwarding, dissemination, or reproduction = of this message is strictly prohibited and may be unlawful. If you are = not the intended recipient, please contact the sender by return e-mail = and destroy all copies of the original message. >=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 >=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 _______________________________________________ 6lowapp mailing list 6lowapp@ietf.org https://www.ietf.org/mailman/listinfo/6lowapp From robert.cragie@gridmerge.com Wed Jan 27 00:57:42 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 327223A68FC for <6lowapp@core3.amsl.com>; Wed, 27 Jan 2010 00:57:42 -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 pj49XXuUUX5L for <6lowapp@core3.amsl.com>; Wed, 27 Jan 2010 00:57:40 -0800 (PST) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id 7CCDD3A681F for <6lowapp@ietf.org>; Wed, 27 Jan 2010 00:57:40 -0800 (PST) Received: from client-86-31-52-97.nrth.adsl.virginmedia.com ([86.31.52.97] helo=[192.168.1.64]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.70) id 1Na3ii-0004aY-1a; Wed, 27 Jan 2010 08:57:52 +0000 Message-ID: <4B60000D.5010802@gridmerge.com> Date: Wed, 27 Jan 2010 08:57:49 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Zach Shelby References: <0B3D3615-F1AB-4067-B758-0A988C10CD98@sensinode.com> In-Reply-To: <0B3D3615-F1AB-4067-B758-0A988C10CD98@sensinode.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080505050807070201020703" Cc: 6LoWAPP <6lowapp@ietf.org> Subject: Re: [6lowapp] draft-shelby-6lowapp-coap-00 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, 27 Jan 2010 08:57:42 -0000 This is a cryptographically signed message in MIME format. --------------ms080505050807070201020703 Content-Type: multipart/alternative; boundary="------------070101050207090708080903" This is a multi-part message in MIME format. --------------070101050207090708080903 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Regarding subscribe/notify: I came across RestMS (http://www.restms.org/article:introduction-to-restms) a while ago and whilst it is not aimed at CoAP environments, I think some of the models are applicable. Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 (0) 1924 910888 http://www.gridmerge.com Zach Shelby wrote: > Does anyone have comments/ideas regarding http://www.ietf.org/id/draft-shelby-6lowapp-coap-00.txt that we submitted before the holidays? We would like to start some design work, so any feedback would be really useful. I've identified some areas where we need input/discussion on the list: > > 1. Content-type encoding (Section 2.4). Any ideas or suggestions on how to encode this and what is enough space? How should such an encoding be managed, ask IANA to do that? Any pointers to a similar encoding done elsewhere? > > 2. Caching (Section 2.6). Should we go towards an in-band or an out-of-band discovery approach? Personally I think an in-band approach is by far the simplest, although it requires some header space when present. > > 3. Subscribe/Notify (Section 2.7). This is an area that definitely needs discussion. The current proposal is to use a REST interface to create subscriptions and which are then sent using a NOTIFY message to a call-back URL. How to format the body o the subscription (URL to subscribe to, URL call-back, parameters?). > > 4. Resource Discovery (Section 2.9). The proposal is to use a new DISCOVER method which can be sent either unicast or multicast. The only difficult part there is the format of the list of resources (URLs) which would be returned in such a response. This is a little bit like index.html. We had some discussions in Hiroshima that XMPP has developed some ways of coding lists of URLs and that could be re-used. Does someone have a pointer for us on that? > > Thanks, > Zach > > --------------070101050207090708080903 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Regarding subscribe/notify: I came across RestMS (http://www.restms.org/article:introduction-to-restms) a while ago and whilst it is not aimed at CoAP environments, I think some of the models are applicable.

Robert

Robert Cragie (Pacific Gas & Electric)

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



Zach Shelby wrote: 
Does anyone have comments/ideas regarding http://www.ietf.org/id/draft-shelby-6lowapp-coap-00.txt that we submitted before the holidays? We would like to start some design work, so any feedback would be really useful. I've identified some areas where we need input/discussion on the list:

1. Content-type encoding (Section 2.4). Any ideas or suggestions on how to encode this and what is enough space? How should such an encoding be managed, ask IANA to do that? Any pointers to a similar encoding done elsewhere?

2. Caching (Section 2.6). Should we go towards an in-band or an out-of-band discovery approach? Personally I think an in-band approach is by far the simplest, although it requires some header space when present.

3. Subscribe/Notify (Section 2.7). This is an area that definitely needs discussion. The current proposal is to use a REST interface to create subscriptions and which are then sent using a NOTIFY message to a call-back URL. How to format the body o the subscription (URL to subscribe to, URL call-back, parameters?). 

4. Resource Discovery (Section 2.9). The proposal is to use a new DISCOVER method which can be sent either unicast or multicast. The only difficult part there is the format of the list of resources (URLs) which would be returned in such a response. This is a little bit like index.html. We had some discussions in Hiroshima that XMPP has developed some ways of coding lists of URLs and that could be re-used. Does someone have a pointer for us on that? 

Thanks,
Zach
--------------070101050207090708080903-- --------------ms080505050807070201020703 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 GgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDAx MjcwODU3NDlaMCMGCSqGSIb3DQEJBDEWBBQOaDr/bh0F0+8NNbMvCm9qhqn3TzBfBgkqhkiG 9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpgg E7/iD53vjpAfMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpggE7/iD53vjpAfMA0GCSqGSIb3DQEBAQUA BIIBAK9ecrGyLx8oQXeUV1afUlCnCj0aXpPW0tgxZ2puAGa7BWPrjNQCSRAx9/EjrQnK3tms jcTWXw1Z2Ip/+Sx68SeQfI9lhtchobC4VOExWNqVZyIUbqtnWbpYSe3yiNrlFU0seHGxU0FP TwuD5Zb5eG4QSRly8H+f7H2fW+3OO5cHDyy9FAKfEyjEe9GOD/Ds2br36JwTnwPiFvm8ZFuL jxOVSID47//+e0quXGV+Bz5X7bdnz2qAFMRbW8Q8uWoyrEk1veX29PMLABAg1jm8S7iLpAYn 9RIlDtJ3I79z+51oX1r6h1jnZkDIid/dVAVhPQz8swnUwq5slVz1pV9EsIYAAAAAAAA= --------------ms080505050807070201020703-- From Colin.OFlynn@atmel.com Wed Jan 27 01: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 9C52C3A6910; Wed, 27 Jan 2010 01:08:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 0h5tN0uc46qN; Wed, 27 Jan 2010 01:08:56 -0800 (PST) Received: from sjogate2.atmel.com (newsmtp5.atmel.com [204.2.163.5]) by core3.amsl.com (Postfix) with ESMTP id A9FA63A676A; Wed, 27 Jan 2010 01:08:56 -0800 (PST) Received: from csomb01.corp.atmel.com ([10.95.30.150]) by sjogate2.atmel.com (8.13.6/8.13.6) with ESMTP id o0R97AAe013516; Wed, 27 Jan 2010 01:07:12 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA9F30.55F28C1C" Date: Wed, 27 Jan 2010 02:08:48 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New I-D: Initial Configuration of Resource-Constrained Devices (aka: Bootstrapping / Commissioning) Thread-Index: AcqfMFUGiM4FQx7DRXyVqVMSu0K1+w== From: "Oflynn, Colin" To: <6lowapp@ietf.org> Cc: 6lowpan@ietf.org Subject: [6lowapp] New I-D: Initial Configuration of Resource-Constrained Devices (aka: Bootstrapping / Commissioning) 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, 27 Jan 2010 09:08:57 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA9F30.55F28C1C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, Cross-posted to both 6lowpan and 6lowapp, as of interest to both. = However please try and keep discussion on 6lowapp mailing list to avoid = further cross-posting / splintering of discussion. This I-D is a first-pass at identifying some of the problems and = proposing some solutions. It overlaps some existing protocols a little, = but I expect this I-D to undergo some pretty radical changes. It's a = huge problem with a lot of different aspects, and not all of those are = yet captured in this document. Regards, =20 -Colin O'Flynn *************************************************************************= ****** A New Internet-Draft is available from the on-line Internet-Drafts = directories. Title : Initial Configuration of Resource-Constrained Devices Author(s) : C. O'Flynn Filename : draft-oflynn-6lowapp-bootstrapping-00.txt Pages : 27 Date : 2010-01-27 he Internet of Things is marching it's way towards completition. Nodes can use standards from the 6LoWPAN and ROLL WG to achieve IP connectivity. IEEE Standards ensure connectivity at lower layers for resource-constrained devices. Yet a central problem remains at a more basic layer without a suitable answer: how to initially configure the network. Without configuration the network never advances beyond a large box of nodes. Current solutions tend to be specific to a certain vendor, node type, or application. This document outlines exactly what problems are faced in solving this problem. General problems faced in any low-power wireless network are outlined first; followed by how these apply to bootstrapping. A selection of currently proposed techniques is presented. From these a more generic approach is presented, which can solve the problem for a wide range of situations. An emphasis is on performing this bootstrapping in a secure manner. This document does not cover operationg of the network securely. This document does provide the basis for allowing the network to operate securely however, by providing standard methods for key exchanges and authentication. A URL for this Internet-Draft is: http://www.ietf.org/id/draft-oflynn-6lowapp-bootstrapping-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01CA9F30.55F28C1C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable New I-D: Initial Configuration of Resource-Constrained Devices = (aka: Bootstrapping / Commissioning)

Hello,

Cross-posted to both 6lowpan and 6lowapp, as of interest to both. = However please try and keep discussion on 6lowapp mailing list to avoid = further cross-posting / splintering of discussion.

This I-D is a first-pass at identifying some of the problems and = proposing some solutions. It overlaps some existing protocols a little, = but I expect this I-D to undergo some pretty radical changes. It's a = huge problem with a lot of different aspects, and not all of those are = yet captured in this document.

Regards,
 
  -Colin O'Flynn

*************************************************************************= ******

A New Internet-Draft is available from the on-line Internet-Drafts = directories.

        = Title           : = Initial Configuration of Resource-Constrained Devices
        = Author(s)       : C. O'Flynn
        = Filename        : = draft-oflynn-6lowapp-bootstrapping-00.txt
        = Pages           : = 27
        = Date            : = 2010-01-27

he Internet of Things is marching it's way towards completition.
Nodes can use standards from the 6LoWPAN and ROLL WG to achieve IP
connectivity.  IEEE Standards ensure connectivity at lower layers = for
resource-constrained devices.  Yet a central problem remains at = a
more basic layer without a suitable answer: how to initially
configure the network.  Without configuration the network never
advances beyond a large box of nodes.  Current solutions tend to = be
specific to a certain vendor, node type, or application.

This document outlines exactly what problems are faced in solving
this problem.  General problems faced in any low-power wireless
network are outlined first; followed by how these apply to
bootstrapping.  A selection of currently proposed techniques is
presented.  From these a more generic approach is presented, = which
can solve the problem for a wide range of situations.

An emphasis is on performing this bootstrapping in a secure manner.
This document does not cover operationg of the network securely.
This document does provide the basis for allowing the network to
operate securely however, by providing standard methods for key
exchanges and authentication.

A URL for this Internet-Draft is:
http://www.ietf.org/id/draft-oflynn-6lowapp-bootstrapping-00.txt
=
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-= drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

<ftp://ftp.ietf.org/internet-drafts/draft-oflynn-6lowapp-boot= strapping-00.txt>

------_=_NextPart_001_01CA9F30.55F28C1C-- From j.schoenwaelder@jacobs-university.de Wed Jan 27 02:07:05 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 3368A3A6A36 for <6lowapp@core3.amsl.com>; Wed, 27 Jan 2010 02:07:05 -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 TClmUCAz695P for <6lowapp@core3.amsl.com>; Wed, 27 Jan 2010 02:07:04 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id D98623A6A3C for <6lowapp@ietf.org>; Wed, 27 Jan 2010 02:07:03 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 15C32C003E; Wed, 27 Jan 2010 11:07:16 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id lgXiJBxSz-+S; Wed, 27 Jan 2010 11:07:15 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CC850C0007; Wed, 27 Jan 2010 11:07:14 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 0706A101CC47; Wed, 27 Jan 2010 11:07:04 +0100 (CET) Date: Wed, 27 Jan 2010 11:07:04 +0100 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20100127100704.GC89790@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , "d.sturek@att.net" , "paduffy@cisco.com" , "6lowapp@ietf.org" <6lowapp@ietf.org> References: <0B3D3615-F1AB-4067-B758-0A988C10CD98@sensinode.com> <0D212BD466921646B58854FB79092CEC011D9BCE@XMB-AMS-106.cisco.com> <4B5F466A.2060400@cisco.com> <028801ca9ec8$2e5439c0$8afcad40$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "6lowapp@ietf.org" <6lowapp@ietf.org> Subject: Re: [6lowapp] draft-shelby-6lowapp-coap-00 X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder 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, 27 Jan 2010 10:07:05 -0000 On Wed, Jan 27, 2010 at 09:04:54AM +0100, Romascanu, Dan (Dan) wrote: > I would agree that asynchronous notifications as a default are a > better model in a resource constrained environment. Polling could be > used as an option when resources allow. The architecture and > philosophy is similar to the one used in network management where > devices send notifications at boot time (coldStart) or when an > application initializes (warmStart), while a management application > (typically not powered constrained) may poll periodically the > devices to make sure notifications were not lost. And from network management protocol experience, we know that it is important that data is carrying sufficient 'meta data' to be able to detect discontinuities, to determine the precision of data and to identify the time when a value was measured and the frequency with which it is updated. It is also important to detect "stale" subscriptions since pushing data to non-interested receivers is not particularly useful. Related to this, it is often useful to filter the data a receiver is really interested in the subscription. But there are of course trade offs with all that related to the complexity you get on the device - so the usual approach is to allow devices to implement different feature sets, depending on their capabilities. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From apezzuto@cisco.com Wed Jan 27 02:30:18 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 6D3253A6916 for <6lowapp@core3.amsl.com>; Wed, 27 Jan 2010 02:30:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 hv8UBicM9kYf for <6lowapp@core3.amsl.com>; Wed, 27 Jan 2010 02:30:16 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 96BFC3A68FC for <6lowapp@ietf.org>; Wed, 27 Jan 2010 02:30:16 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEADukX0utJV2Y/2dsb2JhbADBCJcShDgE X-IronPort-AV: E=Sophos;i="4.49,352,1262563200"; d="scan'208";a="82287138" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rtp-iport-1.cisco.com with ESMTP; 27 Jan 2010 10:30:29 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id o0RAUPR9023703; Wed, 27 Jan 2010 10:30:28 GMT Received: from xmb-ams-106.cisco.com ([144.254.74.81]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Jan 2010 11:30:12 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 Jan 2010 11:30:11 +0100 Message-ID: <0D212BD466921646B58854FB79092CEC0124903D@XMB-AMS-106.cisco.com> In-Reply-To: <0D212BD466921646B58854FB79092CEC01248F48@XMB-AMS-106.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowapp] draft-shelby-6lowapp-coap-00 Thread-Index: AcqfKMcc/8b8XF7cTIGcKtwlYvM7xwAA6dqgAALW0LA= References: <0B3D3615-F1AB-4067-B758-0A988C10CD98@sensinode.com><0D212BD466921646B58854FB79092CEC011D9BCE@XMB-AMS-106.cisco.com><49617D19-49D0-4EAB-9740-5B1926C05D9E@sensinode.com><0648E2DF-B4A0-4BB8-9E63-BB34765945CA@sensinode.com> <0D212BD466921646B58854FB79092CEC01248F48@XMB-AMS-106.cisco.com> From: "Adriano Pezzuto (apezzuto)" To: "Zach Shelby" X-OriginalArrivalTime: 27 Jan 2010 10:30:12.0060 (UTC) FILETIME=[B4E9F9C0:01CA9F3B] Cc: 6LoWAPP <6lowapp@ietf.org> Subject: Re: [6lowapp] 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: Wed, 27 Jan 2010 10:30:18 -0000 Hi Zach, let's to see the opposite case when a CoAP node subscribes to an HTTP = server placed on Internet. Consider a CoAP device in a home application switching off some low = priority appliances when the price of energy crosses a threshold. The = price of energy is a realtime data provided by Energy provider on its = web server. I do not know how realistic this scenario is. Please, consider it only = as an example.=20 A figure may help: Actuator <--------- coap ---------> Proxy <---------- http = -----------> Server =20 CREATE subscribe /price >>> POST subscribe /price OK <<< OK (/sub1) =20 LONG GET /sub1 GET stays open.... */energy price changes* NOTIFY /price <<< OK (/sub1) OK */switch off appliances* Adriano -----Original Message----- From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On = Behalf Of Adriano Pezzuto (apezzuto) Sent: mercoled=EC 27 gennaio 2010 9.51 To: Zach Shelby; lisa.dusseault@gmail.com Cc: 6LoWAPP Subject: Re: [6lowapp] draft-shelby-6lowapp-coap-00 Thanks Zach for summarize, it's fine. Also the long poll approach suggested by Lisa, sounds better than the = expensive repeated polling approach. Adriano -----Original Message----- From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On = Behalf Of Zach Shelby Sent: mercoled=EC 27 gennaio 2010 9.15 To: Zach Shelby Cc: 6LoWAPP Subject: Re: [6lowapp] draft-shelby-6lowapp-coap-00 And a figure may help, this is what using a long poll would look like: Sensor <--------- coap ---------> Proxy <---------- http -----------> = Client =20 CREATE subscribe /temp <<< POST subscribe /temp OK >>> OK (/sub1) =20 * LONG GET /sub1 GET stays open.... */temp changes* =09 NOTIFY /temp >>> OK (/temp) OK On Jan 27, 2010, at 10:00 , Zach Shelby wrote: > I think there is a misunderstanding there. Adriano was describing what = technique could be used on the HTTP side to realize the mapping with the = CoAP subscribe/notify feature. Obviously the CoAP side would use = asynchronous notifications sent by the sensor node, no problem there. = When a proxy (server node below) maps that to HTTP, you need to use some = kind of long pull technique between the proxy and the HTTP subscriber. = Lisa gave a good pointer that the new HYBI working group is chartered to = develop a long pull approach for HTTP - which we may be able to make use = of. >=20 > Did I summarize that right Adriano? >=20 > Zach >=20 > On Jan 27, 2010, at 9:53 , Van Der Stok, Peter wrote: >=20 >> Hi Zach, Adriano, >>=20 >> I would not be too happy about polling a sleeping device. It kind of = beats the original purpose of having a subscription. >>=20 >> Peter >>=20 >> -----Original Message----- >> From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On = Behalf Of Adriano Pezzuto (apezzuto) >> Sent: Tuesday 26 January 2010 18:56 >> To: Zach Shelby >> Cc: 6LoWAPP >> Subject: Re: [6lowapp] draft-shelby-6lowapp-coap-00 >>=20 >> Hi Zach, >> I would to give a bit regarding CoAP/HTTP mapping and notification = messages from constrained devices to wider Internet and vice versa. >>=20 >> Basically, the issue here is that HTTP has a synchronous = request-response model where a NOTIFY is an asynch event. Searching on = the REST literature, there is cute way to handle asynch tasks within a = synch model. Let to split the asynch operation into more synchronous = requests. The first request spawns the operation, and the other requests = let the client to be informed about the status of the operation. >>=20 >> Let to consider a client node on the internet subscribing to a server = node for a data event notification (e.g. temperature crossing a = threshold). The server node is in the constrained environment and a = CoAP/HTTP interworking function is running between client and server. >>=20 >> The client node makes its subscribe request by sending a POST message = to the server node. >> The server node accepts the request, creates a new resource = representing the event and put it in a queue. >> Instead of keeping the client node waiting until the event happens, = the server sends to the client (by CoAP/HTTP IWF) an HTTP 202 Accepted = and gives it a new URL that represents the new created resource. >> Then the client can make GET requests to that URL until the event = happens. >> Once the client has 'consumed' the event it can DELETE the event = resource from the server queue. >>=20 >> Better ways exist to accomplish the same task but hope this can help. >>=20 >> Regards, >> Adriano >>=20 >>=20 >> -----Original Message----- >> From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On = Behalf Of Zach Shelby >> Sent: marted=EC 19 gennaio 2010 14.37 >> To: 6LoWAPP >> Subject: [6lowapp] draft-shelby-6lowapp-coap-00 >>=20 >> Does anyone have comments/ideas regarding = http://www.ietf.org/id/draft-shelby-6lowapp-coap-00.txt that we = submitted before the holidays? We would like to start some design work, = so any feedback would be really useful. I've identified some areas where = we need input/discussion on the list: >>=20 >> 1. Content-type encoding (Section 2.4). Any ideas or suggestions on = how to encode this and what is enough space? How should such an encoding = be managed, ask IANA to do that? Any pointers to a similar encoding done = elsewhere? >>=20 >> 2. Caching (Section 2.6). Should we go towards an in-band or an = out-of-band discovery approach? Personally I think an in-band approach = is by far the simplest, although it requires some header space when = present. >>=20 >> 3. Subscribe/Notify (Section 2.7). This is an area that definitely = needs discussion. The current proposal is to use a REST interface to = create subscriptions and which are then sent using a NOTIFY message to a = call-back URL. How to format the body o the subscription (URL to = subscribe to, URL call-back, parameters?). >>=20 >> 4. Resource Discovery (Section 2.9). The proposal is to use a new = DISCOVER method which can be sent either unicast or multicast. The only = difficult part there is the format of the list of resources (URLs) which = would be returned in such a response. This is a little bit like = index.html. We had some discussions in Hiroshima that XMPP has developed = some ways of coding lists of URLs and that could be re-used. Does = someone have a pointer for us on that? >>=20 >> Thanks, >> 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 >>=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 >> _______________________________________________ >> 6lowapp mailing list >> 6lowapp@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowapp >>=20 >> The information contained in this message may be confidential and = legally protected under applicable law. The message is intended solely = for the addressee(s). If you are not the intended recipient, you are = hereby notified that any use, forwarding, dissemination, or reproduction = of this message is strictly prohibited and may be unlawful. If you are = not the intended recipient, please contact the sender by return e-mail = and destroy all copies of the original message. >=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 >=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 _______________________________________________ 6lowapp mailing list 6lowapp@ietf.org https://www.ietf.org/mailman/listinfo/6lowapp _______________________________________________ 6lowapp mailing list 6lowapp@ietf.org https://www.ietf.org/mailman/listinfo/6lowapp From paduffy@cisco.com Wed Jan 27 05:47:59 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 0EDA13A6A74 for <6lowapp@core3.amsl.com>; Wed, 27 Jan 2010 05:47:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 MnR6PpeFXKBn for <6lowapp@core3.amsl.com>; Wed, 27 Jan 2010 05:47:57 -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 891DF3A6940 for <6lowapp@ietf.org>; Wed, 27 Jan 2010 05:47:57 -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: ApoEABrTX0utJV2Y/2dsb2JhbADAE4ElCAGVZ4Q4BA X-IronPort-AV: E=Sophos;i="4.49,353,1262563200"; d="scan'208";a="209573382" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by sj-iport-3.cisco.com with ESMTP; 27 Jan 2010 13:48:11 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id o0RDmBcW027964 for <6lowapp@ietf.org>; Wed, 27 Jan 2010 13:48:11 GMT Received: from xfe-rcd-102.cisco.com ([72.163.62.137]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Jan 2010 07:48:11 -0600 Received: from [10.86.244.81] ([10.86.244.81]) by xfe-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Jan 2010 07:48:10 -0600 Message-ID: <4B60441A.70302@cisco.com> Date: Wed, 27 Jan 2010 08:48:10 -0500 From: Paul Duffy Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: 6lowapp@ietf.org References: <0B3D3615-F1AB-4067-B758-0A988C10CD98@sensinode.com> <0D212BD466921646B58854FB79092CEC011D9BCE@XMB-AMS-106.cisco.com> <49617D19-49D0-4EAB-9740-5B1926C05D9E@sensinode.com> <0648E2DF-B4A0-4BB8-9E63-BB34765945CA@sensinode.com> In-Reply-To: <0648E2DF-B4A0-4BB8-9E63-BB34765945CA@sensinode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 27 Jan 2010 13:48:11.0038 (UTC) FILETIME=[5D562BE0:01CA9F57] Subject: Re: [6lowapp] draft-shelby-6lowapp-coap-00 X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: paduffy@cisco.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, 27 Jan 2010 13:47:59 -0000 Couple related points... - the proxy is slowing creeping away from a simple COAP to HTTP translator. I expect it will further creep as time progresses. - XMPP supports a pub/sub messaging pattern as well as request/response. And presence can be used to report device status. Please excuse as I've been ducking in and out of this conversation. What was the verdict re: applicability of an XMPP-like protocol in this space? On 1/27/2010 3:14 AM, Zach Shelby wrote: > And a figure may help, this is what using a long poll would look like: > > Sensor<--------- coap ---------> Proxy<---------- http -----------> Client > > CREATE subscribe /temp <<< POST subscribe /temp > OK >>> OK (/sub1) > * LONG GET /sub1 > GET stays open.... > */temp changes* > NOTIFY /temp >>> OK (/temp) > OK > > > On Jan 27, 2010, at 10:00 , Zach Shelby wrote: > > >> I think there is a misunderstanding there. Adriano was describing what technique could be used on the HTTP side to realize the mapping with the CoAP subscribe/notify feature. Obviously the CoAP side would use asynchronous notifications sent by the sensor node, no problem there. When a proxy (server node below) maps that to HTTP, you need to use some kind of long pull technique between the proxy and the HTTP subscriber. Lisa gave a good pointer that the new HYBI working group is chartered to develop a long pull approach for HTTP - which we may be able to make use of. >> >> Did I summarize that right Adriano? >> >> Zach >> >> On Jan 27, 2010, at 9:53 , Van Der Stok, Peter wrote: >> >> >>> Hi Zach, Adriano, >>> >>> I would not be too happy about polling a sleeping device. It kind of beats the original purpose of having a subscription. >>> >>> Peter >>> >>> -----Original Message----- >>> From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf Of Adriano Pezzuto (apezzuto) >>> Sent: Tuesday 26 January 2010 18:56 >>> To: Zach Shelby >>> Cc: 6LoWAPP >>> Subject: Re: [6lowapp] draft-shelby-6lowapp-coap-00 >>> >>> Hi Zach, >>> I would to give a bit regarding CoAP/HTTP mapping and notification messages from constrained devices to wider Internet and vice versa. >>> >>> Basically, the issue here is that HTTP has a synchronous request-response model where a NOTIFY is an asynch event. Searching on the REST literature, there is cute way to handle asynch tasks within a synch model. Let to split the asynch operation into more synchronous requests. The first request spawns the operation, and the other requests let the client to be informed about the status of the operation. >>> >>> Let to consider a client node on the internet subscribing to a server node for a data event notification (e.g. temperature crossing a threshold). The server node is in the constrained environment and a CoAP/HTTP interworking function is running between client and server. >>> >>> The client node makes its subscribe request by sending a POST message to the server node. >>> The server node accepts the request, creates a new resource representing the event and put it in a queue. >>> Instead of keeping the client node waiting until the event happens, the server sends to the client (by CoAP/HTTP IWF) an HTTP 202 Accepted and gives it a new URL that represents the new created resource. >>> Then the client can make GET requests to that URL until the event happens. >>> Once the client has 'consumed' the event it can DELETE the event resource from the server queue. >>> >>> Better ways exist to accomplish the same task but hope this can help. >>> >>> Regards, >>> Adriano >>> >>> >>> -----Original Message----- >>> From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf Of Zach Shelby >>> Sent: martedì 19 gennaio 2010 14.37 >>> To: 6LoWAPP >>> Subject: [6lowapp] draft-shelby-6lowapp-coap-00 >>> >>> Does anyone have comments/ideas regarding http://www.ietf.org/id/draft-shelby-6lowapp-coap-00.txt that we submitted before the holidays? We would like to start some design work, so any feedback would be really useful. I've identified some areas where we need input/discussion on the list: >>> >>> 1. Content-type encoding (Section 2.4). Any ideas or suggestions on how to encode this and what is enough space? How should such an encoding be managed, ask IANA to do that? Any pointers to a similar encoding done elsewhere? >>> >>> 2. Caching (Section 2.6). Should we go towards an in-band or an out-of-band discovery approach? Personally I think an in-band approach is by far the simplest, although it requires some header space when present. >>> >>> 3. Subscribe/Notify (Section 2.7). This is an area that definitely needs discussion. The current proposal is to use a REST interface to create subscriptions and which are then sent using a NOTIFY message to a call-back URL. How to format the body o the subscription (URL to subscribe to, URL call-back, parameters?). >>> >>> 4. Resource Discovery (Section 2.9). The proposal is to use a new DISCOVER method which can be sent either unicast or multicast. The only difficult part there is the format of the list of resources (URLs) which would be returned in such a response. This is a little bit like index.html. We had some discussions in Hiroshima that XMPP has developed some ways of coding lists of URLs and that could be re-used. Does someone have a pointer for us on that? >>> >>> Thanks, >>> 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 >>> _______________________________________________ >>> 6lowapp mailing list >>> 6lowapp@ietf.org >>> https://www.ietf.org/mailman/listinfo/6lowapp >>> >>> The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. >>> >> -- >> 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 >> > From guido.moritz@uni-rostock.de Wed Jan 27 06:09:38 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 9C0A23A6952 for <6lowapp@core3.amsl.com>; Wed, 27 Jan 2010 06:09:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, MSGID_MULTIPLE_AT=1.449, 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 vgJHwae5RcFP for <6lowapp@core3.amsl.com>; Wed, 27 Jan 2010 06:09:37 -0800 (PST) Received: from mailrelay1.uni-rostock.de (mailrelay1.uni-rostock.de [139.30.8.201]) by core3.amsl.com (Postfix) with ESMTP id 8C38C3A693A for <6lowapp@ietf.org>; Wed, 27 Jan 2010 06:09:36 -0800 (PST) Received: from email2.uni-rostock.de (139.30.8.209) by edge01.uni-rostock.de (139.30.8.159) with Microsoft SMTP Server (TLS) id 8.2.213.0; Wed, 27 Jan 2010 15:09:49 +0100 Received: from Schlappi (139.30.201.173) by email2.uni-rostock.de (139.30.8.210) with Microsoft SMTP Server (TLS) id 8.2.213.0; Wed, 27 Jan 2010 15:09:49 +0100 From: Guido Moritz To: References: <0B3D3615-F1AB-4067-B758-0A988C10CD98@sensinode.com> <0D212BD466921646B58854FB79092CEC011D9BCE@XMB-AMS-106.cisco.com> <49617D19-49D0-4EAB-9740-5B1926C05D9E@sensinode.com> <0648E2DF-B4A0-4BB8-9E63-BB34765945CA@sensinode.com> <4B60441A.70302@cisco.com> In-Reply-To: <4B60441A.70302@cisco.com> Date: Wed, 27 Jan 2010 15:09:52 +0100 Message-ID: <002201ca9f5a$64fbb150$2ef313f0$@moritz@uni-rostock.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqfV2M0bNMmjRj8RsiD/StbF+5tDgAANa4w Content-Language: de Cc: 6LoWAPP <6lowapp@ietf.org> Subject: Re: [6lowapp] 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: Wed, 27 Jan 2010 14:09:38 -0000 The XMPP pub/sub messaging patterns benefits from endpoint/server = structure. Each client is connected to a server with a long live TCP connection. = Ifs subscribed, the server is responsible for data dissemination to the corresponding clients via the existing TCP connection. This seems = similar to the COAP proxy approach with a central point for event/data = dissemination. But XMPP of course is a bit more powerful because of server-to-server communication, server clustering, ... There is also a ad-hoc mode for XMPP without this server based on mDNS service discovery. Clients are also connected by long lived TCP = connections, but this time directly without intermediate server. However, this ad-hoc mode would require 'application layer multicast', which is not a proper solution due to multiple unicast connections to the endpoints for at = least one event (see my further mail(s)). > -----Urspr=FCngliche Nachricht----- > Von: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] Im > Auftrag von Paul Duffy > Gesendet: Mittwoch, 27. Januar 2010 14:48 > An: 6lowapp@ietf.org > Betreff: Re: [6lowapp] draft-shelby-6lowapp-coap-00 >=20 > Couple related points... >=20 > - the proxy is slowing creeping away from a simple COAP to HTTP > translator. I expect it will further creep as time progresses. >=20 > - XMPP supports a pub/sub messaging pattern as well as > request/response. And presence can be used to report device status. > Please excuse as I've been ducking in and out of this conversation. > What was the verdict re: applicability of an XMPP-like protocol in = this > space? >=20 >=20 >=20 > On 1/27/2010 3:14 AM, Zach Shelby wrote: > > And a figure may help, this is what using a long poll would look > like: > > > > Sensor<--------- coap ---------> Proxy<---------- http = ----------- > > Client > > > > CREATE subscribe /temp <<< POST subscribe /temp > > OK >>> OK (/sub1) > > * LONG GET > /sub1 > > GET stays > open.... > > */temp changes* > > NOTIFY /temp >>> OK (/temp) > > OK > > > > > > On Jan 27, 2010, at 10:00 , Zach Shelby wrote: > > > > > >> I think there is a misunderstanding there. Adriano was describing > what technique could be used on the HTTP side to realize the mapping > with the CoAP subscribe/notify feature. Obviously the CoAP side would > use asynchronous notifications sent by the sensor node, no problem > there. When a proxy (server node below) maps that to HTTP, you need to > use some kind of long pull technique between the proxy and the HTTP > subscriber. Lisa gave a good pointer that the new HYBI working group = is > chartered to develop a long pull approach for HTTP - which we may be > able to make use of. > >> > >> Did I summarize that right Adriano? > >> > >> Zach > >> > >> On Jan 27, 2010, at 9:53 , Van Der Stok, Peter wrote: > >> > >> > >>> Hi Zach, Adriano, > >>> > >>> I would not be too happy about polling a sleeping device. It kind > of beats the original purpose of having a subscription. > >>> > >>> Peter > >>> > >>> -----Original Message----- > >>> From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] = On > Behalf Of Adriano Pezzuto (apezzuto) > >>> Sent: Tuesday 26 January 2010 18:56 > >>> To: Zach Shelby > >>> Cc: 6LoWAPP > >>> Subject: Re: [6lowapp] draft-shelby-6lowapp-coap-00 > >>> > >>> Hi Zach, > >>> I would to give a bit regarding CoAP/HTTP mapping and notification > messages from constrained devices to wider Internet and vice versa. > >>> > >>> Basically, the issue here is that HTTP has a synchronous request- > response model where a NOTIFY is an asynch event. Searching on the = REST > literature, there is cute way to handle asynch tasks within a synch > model. Let to split the asynch operation into more synchronous > requests. The first request spawns the operation, and the other > requests let the client to be informed about the status of the > operation. > >>> > >>> Let to consider a client node on the internet subscribing to a > server node for a data event notification (e.g. temperature crossing a > threshold). The server node is in the constrained environment and a > CoAP/HTTP interworking function is running between client and server. > >>> > >>> The client node makes its subscribe request by sending a POST > message to the server node. > >>> The server node accepts the request, creates a new resource > representing the event and put it in a queue. > >>> Instead of keeping the client node waiting until the event = happens, > the server sends to the client (by CoAP/HTTP IWF) an HTTP 202 Accepted > and gives it a new URL that represents the new created resource. > >>> Then the client can make GET requests to that URL until the event > happens. > >>> Once the client has 'consumed' the event it can DELETE the event > resource from the server queue. > >>> > >>> Better ways exist to accomplish the same task but hope this can > help. > >>> > >>> Regards, > >>> Adriano > >>> > >>> > >>> -----Original Message----- > >>> From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] = On > Behalf Of Zach Shelby > >>> Sent: marted=EC 19 gennaio 2010 14.37 > >>> To: 6LoWAPP > >>> Subject: [6lowapp] draft-shelby-6lowapp-coap-00 > >>> > >>> Does anyone have comments/ideas regarding > http://www.ietf.org/id/draft-shelby-6lowapp-coap-00.txt that we > submitted before the holidays? We would like to start some design = work, > so any feedback would be really useful. I've identified some areas > where we need input/discussion on the list: > >>> > >>> 1. Content-type encoding (Section 2.4). Any ideas or suggestions = on > how to encode this and what is enough space? How should such an > encoding be managed, ask IANA to do that? Any pointers to a similar > encoding done elsewhere? > >>> > >>> 2. Caching (Section 2.6). Should we go towards an in-band or an > out-of-band discovery approach? Personally I think an in-band approach > is by far the simplest, although it requires some header space when > present. > >>> > >>> 3. Subscribe/Notify (Section 2.7). This is an area that definitely > needs discussion. The current proposal is to use a REST interface to > create subscriptions and which are then sent using a NOTIFY message to > a call-back URL. How to format the body o the subscription (URL to > subscribe to, URL call-back, parameters?). > >>> > >>> 4. Resource Discovery (Section 2.9). The proposal is to use a new > DISCOVER method which can be sent either unicast or multicast. The = only > difficult part there is the format of the list of resources (URLs) > which would be returned in such a response. This is a little bit like > index.html. We had some discussions in Hiroshima that XMPP has > developed some ways of coding lists of URLs and that could be re-used. > Does someone have a pointer for us on that? > >>> > >>> Thanks, > >>> 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 > >>> _______________________________________________ > >>> 6lowapp mailing list > >>> 6lowapp@ietf.org > >>> https://www.ietf.org/mailman/listinfo/6lowapp > >>> > >>> The information contained in this message may be confidential and > legally protected under applicable law. The message is intended solely > for the addressee(s). If you are not the intended recipient, you are > hereby notified that any use, forwarding, dissemination, or > reproduction of this message is strictly prohibited and may be > unlawful. If you are not the intended recipient, please contact the > sender by return e-mail and destroy all copies of the original = message. > >>> > >> -- > >> 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 > >> > > >=20 > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp From Michael.Stuber@itron.com Wed Jan 27 09:58: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 64ECB3A6869 for <6lowapp@core3.amsl.com>; Wed, 27 Jan 2010 09:58:20 -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 poZawTRc1fDc for <6lowapp@core3.amsl.com>; Wed, 27 Jan 2010 09:58:19 -0800 (PST) Received: from mailer-1.itron.com (mailer-1.itron.com [198.182.8.123]) by core3.amsl.com (Postfix) with ESMTP id 968283A690D for <6lowapp@ietf.org>; Wed, 27 Jan 2010 09:58:19 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 Jan 2010 09:58:33 -0800 Message-ID: <05C6A38D732F1144A8C4016BA4416BFE02759CFB@SPO-EXVS-02.itron.com> In-Reply-To: <3fe58b591001251042h3c8ef221hdb1716405fd10d91@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowapp] Revised Charter Proposal Thread-Index: Acqd7jqy9+83l3hbRCmbFtQ4zKGQKQBjA8zA References: <0C0AF10C-85F8-4401-BFB0-441CD08F067E@cisco.com><8CFA798E-123D-4A10-8961-8D47B3EE3A34@cisco.com> <3fe58b591001251042h3c8ef221hdb1716405fd10d91@mail.gmail.com> From: "Stuber, Michael" To: <6lowapp@ietf.org> Subject: Re: [6lowapp] Revised Charter Proposal 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, 27 Jan 2010 17:58:20 -0000 Absolutely agree. +1 -----Original Message----- From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf Of Kerry Lynn Sent: Monday, January 25, 2010 10:43 AM To: Cullen Jennings Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Revised Charter Proposal Cullen, I, for one, am nervous about deferring a naming and discovery approach and feel that this is important to interoperable implementations. Not sure I see the value of creating a framework for defining new profiles and interface objects, if there's no consistent way to name and discover them. Regards, -K- On Mon, Jan 25, 2010 at 12:38 PM, Cullen Jennings wrote: > > I think I made one (or at least one) big mistake in this charter update. At the end of the BOF, there was clear consensus to make the initial charter thorough out everything but the minimal approach. (Basically Ted Hardie's proposal). I thought I had done this but realize in going back and listening to the BOF recording that this included leaving the discovery stuff to a later time. I think I need to update the charter to move the discovery work to not be in the initial scope of work. > _______________________________________________ 6lowapp mailing list 6lowapp@ietf.org https://www.ietf.org/mailman/listinfo/6lowapp From fluffy@cisco.com Wed Jan 27 15:36:18 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 3FC2A3A69F6 for <6lowapp@core3.amsl.com>; Wed, 27 Jan 2010 15:36:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.437 X-Spam-Level: X-Spam-Status: No, score=-110.437 tagged_above=-999 required=5 tests=[AWL=0.163, 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 xsm1z9elA-sw for <6lowapp@core3.amsl.com>; Wed, 27 Jan 2010 15:36:17 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 9850E3A69E0 for <6lowapp@ietf.org>; Wed, 27 Jan 2010 15:36:17 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEADFdYEurR7H+/2dsb2JhbADBHZcphDkE X-IronPort-AV: E=Sophos;i="4.49,356,1262563200"; d="scan'208";a="80044525" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 27 Jan 2010 23:36:33 +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 o0RNaWLG001480 for <6lowapp@ietf.org>; Wed, 27 Jan 2010 23:36:33 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Impp: xmpp:cullenfluffyjennings@jabber.org Date: Wed, 27 Jan 2010 16:36:32 -0700 Message-Id: <6DA80C26-7C3B-4063-8D5E-A2C1E24DC97A@cisco.com> To: 6lowapp@ietf.org Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Subject: [6lowapp] charter status ... 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, 27 Jan 2010 23:36:18 -0000 I'm working on integrating all the comments I got back into the charter = but I wanted to talk to the Security ADs, Apps ADs, and OPs AD. = Hopefully I will have an update to the list by the end of the week. = Thanks to everyone for the good comments. From salvatore.loreto@ericsson.com Thu Jan 28 08:25: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 A5CA03A6960 for <6lowapp@core3.amsl.com>; Thu, 28 Jan 2010 08:25:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_63=0.6, 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 jtJBBsAct9Ky for <6lowapp@core3.amsl.com>; Thu, 28 Jan 2010 08:25:13 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id AB51C3A6A2A for <6lowapp@ietf.org>; Thu, 28 Jan 2010 08:25:12 -0800 (PST) X-AuditID: c1b4fb24-b7c64ae000005cb7-4c-4b61ba78dd66 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 38.1F.23735.87AB16B4; Thu, 28 Jan 2010 17:25:28 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 Jan 2010 17:25:05 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 Jan 2010 17:25:05 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 426D62468 for <6lowapp@ietf.org>; Thu, 28 Jan 2010 18:25:05 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 0E23821A39 for <6lowapp@ietf.org>; Thu, 28 Jan 2010 18:25:05 +0200 (EET) Received: from [IPv6:::1] (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id AFE40219CE for <6lowapp@ietf.org>; Thu, 28 Jan 2010 18:25:04 +0200 (EET) Message-ID: <4B61BA60.6080500@ericsson.com> Date: Thu, 28 Jan 2010 18:25:04 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.7) Gecko/20100120 Fedora/3.0.1-1.fc12 Thunderbird/3.0.1 MIME-Version: 1.0 To: 6lowapp@ietf.org References: <0B3D3615-F1AB-4067-B758-0A988C10CD98@sensinode.com><0D212BD466921646B58854FB79092CEC011D9BCE@XMB-AMS-106.cisco.com><49617D19-49D0-4EAB-9740-5B1926C05D9E@sensinode.com> <0648E2DF-B4A0-4BB8-9E63-BB34765945CA@sensinode.com> <0D212BD466921646B58854FB79092CEC01248F48@XMB-AMS-106.cisco.com> In-Reply-To: <0D212BD466921646B58854FB79092CEC01248F48@XMB-AMS-106.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 28 Jan 2010 16:25:05.0824 (UTC) FILETIME=[73664200:01CAA036] X-Brightmail-Tracker: AAAAAA== Subject: Re: [6lowapp] 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: Thu, 28 Jan 2010 16:25:14 -0000 here a pointer to the draft Lisa was referring to: http://www.ietf.org/id/draft-loreto-http-bidirectional-01.txt we authors are still working on (as personal submission) and also continuing to discuss in the HyBi ml even if it was not accepted as an output of the HyBi wg a bunch of us are also trying to define a request header to determine the timeout for a long poll request so to let the client notify the Server(the proxy in your scenario) the right timeout value it is going to wait for an answer if the event does not happen before. cheers Sal On 01/27/2010 10:50 AM, Adriano Pezzuto (apezzuto) wrote: > Thanks Zach for summarize, it's fine. > Also the long poll approach suggested by Lisa, sounds better than the expensive repeated polling approach. > > Adriano > > > -----Original Message----- > From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf Of Zach Shelby > Sent: mercoledì 27 gennaio 2010 9.15 > To: Zach Shelby > Cc: 6LoWAPP > Subject: Re: [6lowapp] draft-shelby-6lowapp-coap-00 > > And a figure may help, this is what using a long poll would look like: > > Sensor<--------- coap ---------> Proxy<---------- http -----------> Client > > CREATE subscribe /temp <<< POST subscribe /temp > OK >>> OK (/sub1) > * LONG GET /sub1 > GET stays open.... > */temp changes* > NOTIFY /temp >>> OK (/temp) > OK > > > On Jan 27, 2010, at 10:00 , Zach Shelby wrote: > > >> I think there is a misunderstanding there. Adriano was describing what technique could be used on the HTTP side to realize the mapping with the CoAP subscribe/notify feature. Obviously the CoAP side would use asynchronous notifications sent by the sensor node, no problem there. When a proxy (server node below) maps that to HTTP, you need to use some kind of long pull technique between the proxy and the HTTP subscriber. Lisa gave a good pointer that the new HYBI working group is chartered to develop a long pull approach for HTTP - which we may be able to make use of. >> >> Did I summarize that right Adriano? >> >> Zach >> >> On Jan 27, 2010, at 9:53 , Van Der Stok, Peter wrote: >> >> >>> Hi Zach, Adriano, >>> >>> I would not be too happy about polling a sleeping device. It kind of beats the original purpose of having a subscription. >>> >>> Peter >>> >>> -----Original Message----- >>> From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf Of Adriano Pezzuto (apezzuto) >>> Sent: Tuesday 26 January 2010 18:56 >>> To: Zach Shelby >>> Cc: 6LoWAPP >>> Subject: Re: [6lowapp] draft-shelby-6lowapp-coap-00 >>> >>> Hi Zach, >>> I would to give a bit regarding CoAP/HTTP mapping and notification messages from constrained devices to wider Internet and vice versa. >>> >>> Basically, the issue here is that HTTP has a synchronous request-response model where a NOTIFY is an asynch event. Searching on the REST literature, there is cute way to handle asynch tasks within a synch model. Let to split the asynch operation into more synchronous requests. The first request spawns the operation, and the other requests let the client to be informed about the status of the operation. >>> >>> Let to consider a client node on the internet subscribing to a server node for a data event notification (e.g. temperature crossing a threshold). The server node is in the constrained environment and a CoAP/HTTP interworking function is running between client and server. >>> >>> The client node makes its subscribe request by sending a POST message to the server node. >>> The server node accepts the request, creates a new resource representing the event and put it in a queue. >>> Instead of keeping the client node waiting until the event happens, the server sends to the client (by CoAP/HTTP IWF) an HTTP 202 Accepted and gives it a new URL that represents the new created resource. >>> Then the client can make GET requests to that URL until the event happens. >>> Once the client has 'consumed' the event it can DELETE the event resource from the server queue. >>> >>> Better ways exist to accomplish the same task but hope this can help. >>> >>> Regards, >>> Adriano >>> >>> >>> -----Original Message----- >>> From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf Of Zach Shelby >>> Sent: martedì 19 gennaio 2010 14.37 >>> To: 6LoWAPP >>> Subject: [6lowapp] draft-shelby-6lowapp-coap-00 >>> >>> Does anyone have comments/ideas regarding http://www.ietf.org/id/draft-shelby-6lowapp-coap-00.txt that we submitted before the holidays? We would like to start some design work, so any feedback would be really useful. I've identified some areas where we need input/discussion on the list: >>> >>> 1. Content-type encoding (Section 2.4). Any ideas or suggestions on how to encode this and what is enough space? How should such an encoding be managed, ask IANA to do that? Any pointers to a similar encoding done elsewhere? >>> >>> 2. Caching (Section 2.6). Should we go towards an in-band or an out-of-band discovery approach? Personally I think an in-band approach is by far the simplest, although it requires some header space when present. >>> >>> 3. Subscribe/Notify (Section 2.7). This is an area that definitely needs discussion. The current proposal is to use a REST interface to create subscriptions and which are then sent using a NOTIFY message to a call-back URL. How to format the body o the subscription (URL to subscribe to, URL call-back, parameters?). >>> >>> 4. Resource Discovery (Section 2.9). The proposal is to use a new DISCOVER method which can be sent either unicast or multicast. The only difficult part there is the format of the list of resources (URLs) which would be returned in such a response. This is a little bit like index.html. We had some discussions in Hiroshima that XMPP has developed some ways of coding lists of URLs and that could be re-used. Does someone have a pointer for us on that? >>> >>> Thanks, >>> 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 >>> _______________________________________________ >>> 6lowapp mailing list >>> 6lowapp@ietf.org >>> https://www.ietf.org/mailman/listinfo/6lowapp >>> >>> The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. >>> >> -- >> 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 >> > From fluffy@cisco.com Sat Jan 30 10:15:51 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 EC3913A672F for <6lowapp@core3.amsl.com>; Sat, 30 Jan 2010 10:15:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[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 4BsQ4t9WmYLM for <6lowapp@core3.amsl.com>; Sat, 30 Jan 2010 10:15:49 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 5E2BA3A63D3 for <6lowapp@ietf.org>; Sat, 30 Jan 2010 10:15:49 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEALcFZEurRN+J/2dsb2JhbADBX5c8hEUE X-IronPort-AV: E=Sophos;i="4.49,375,1262563200"; d="scan'208";a="142686560" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 30 Jan 2010 18:16:15 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o0UIGE0E023663 for <6lowapp@ietf.org>; Sat, 30 Jan 2010 18:16:14 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Impp: xmpp:cullenfluffyjennings@jabber.org Date: Sat, 30 Jan 2010 11:16:14 -0700 Message-Id: <2A7B1CDC-5B99-47E8-9331-039D5997E1CC@cisco.com> To: 6lowapp@ietf.org Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Subject: [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: Sat, 30 Jan 2010 18:15:51 -0000 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.=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. 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 ------------------------------------------------------------ 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. 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. 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