From martin.stiemerling@neclab.eu Mon Jul 1 05:55:59 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7832021F9BC8; Mon, 1 Jul 2013 05:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6+91Yqhgjstx; Mon, 1 Jul 2013 05:55:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 893F811E8404; Mon, 1 Jul 2013 05:48:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Martin Stiemerling" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130701124846.19324.38630.idtracker@ietfa.amsl.com> Date: Mon, 01 Jul 2013 05:48:46 -0700 Cc: draft-ietf-core-coap@tools.ietf.org, core-chairs@tools.ietf.org, core@ietf.org Subject: [core] Martin Stiemerling's No Objection on draft-ietf-core-coap-18: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 12:55:59 -0000 Martin Stiemerling has entered the following ballot position for draft-ietf-core-coap-18: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- -18 addresses all of my concerns and thank you for addressing them! From barryleiba@gmail.com Mon Jul 1 07:00:53 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEDDD11E815A; Mon, 1 Jul 2013 07:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.924 X-Spam-Level: X-Spam-Status: No, score=-101.924 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PzdQEOcKgDU5; Mon, 1 Jul 2013 07:00:53 -0700 (PDT) Received: from mail-qa0-x235.google.com (mail-qa0-x235.google.com [IPv6:2607:f8b0:400d:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD3711E8112; Mon, 1 Jul 2013 07:00:53 -0700 (PDT) Received: by mail-qa0-f53.google.com with SMTP id g10so2073305qah.12 for ; Mon, 01 Jul 2013 07:00:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Eo2CN84Cih0sGWE7INq9pSGA8Kala6Aypj73U4RArCE=; b=tLPHOrz3d53VHRmdGeLcV5eudAqLFNOoMK2UDKVTNLlIA39nCG2/8R874moZdoFvAz MEWFIkSbN+HIFMmcKwEfFuvawSyKYu09vX6wm88aLVZYqL6Pd4ThotwtKHPYYsUbw0rG G8j6ZUIQbWKXDJwvNqfAkU+fJMfSxfcQaLNi5FKXrbZQt+R4i1uVmbkhDqirPdi14qIv aYwt+iIWimdXFGiF/8ftGlv4XkyE3E5TFdPIh343qusTW6ArHxbJooHzT0imGDGkZS5v pHVHklbtKbvmcyGxr/XiKiAdQEmuSEtRLnpJjfuWIH4DDLuo9A8/o3kUROJvS0Lq6BgV 7QTA== MIME-Version: 1.0 X-Received: by 10.49.35.34 with SMTP id e2mr31909092qej.67.1372687252547; Mon, 01 Jul 2013 07:00:52 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.224.216.201 with HTTP; Mon, 1 Jul 2013 07:00:52 -0700 (PDT) In-Reply-To: <519BC621.4070403@ieca.com> References: <20130516062941.27229.92525.idtracker@ietfa.amsl.com> <519BC621.4070403@ieca.com> Date: Mon, 1 Jul 2013 10:00:52 -0400 X-Google-Sender-Auth: PXuHZmFVWWIJttT8ZhyZHp1LdVM Message-ID: From: Barry Leiba To: Sean Turner Content-Type: multipart/alternative; boundary=047d7b6dd1721371a204e073a8ea Cc: "draft-ietf-core-coap@tools.ietf.org" , "core-chairs@tools.ietf.org" , The IESG , "core@ietf.org" Subject: Re: [core] Sean Turner's Discuss on draft-ietf-core-coap-16: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 14:00:54 -0000 --047d7b6dd1721371a204e073a8ea Content-Type: text/plain; charset=ISO-8859-1 Sean, you're the one who's left: will you check the -18 version and see if you're OK with it? Other ADs, please also have a look at -18 in light of your non-blocking comments, and let us know if there are any important points that you'd like to ask for another look at. Handy link: https://datatracker.ietf.org/doc/draft-ietf-core-coap/ Thanks, Barry --047d7b6dd1721371a204e073a8ea Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sean, you're the one who's left: will you check the -18 version and= see if you're OK with it?

Other ADs, please also ha= ve a look at -18 in light of your non-blocking comments, and let us know if= there are any important points that you'd like to ask for another look= at.


Thanks,
Barry --047d7b6dd1721371a204e073a8ea-- From turners@ieca.com Tue Jul 2 02:58:40 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFB3F11E846B for ; Tue, 2 Jul 2013 02:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.046 X-Spam-Level: X-Spam-Status: No, score=-102.046 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mttZd6DkjrgU for ; Tue, 2 Jul 2013 02:58:35 -0700 (PDT) Received: from gateway05.websitewelcome.com (gateway05.websitewelcome.com [67.18.144.2]) by ietfa.amsl.com (Postfix) with ESMTP id E157F11E8452 for ; Tue, 2 Jul 2013 02:58:35 -0700 (PDT) Received: by gateway05.websitewelcome.com (Postfix, from userid 5007) id 6F33FB69090D3; Tue, 2 Jul 2013 04:58:35 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway05.websitewelcome.com (Postfix) with ESMTP id 45B71B6909083 for ; Tue, 2 Jul 2013 04:58:35 -0500 (CDT) Received: from [173.73.135.86] (port=56746 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UtxM2-0003oU-Kd; Tue, 02 Jul 2013 04:58:34 -0500 Message-ID: <51D2A449.1090801@ieca.com> Date: Tue, 02 Jul 2013 05:58:33 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Barry Leiba References: <20130516062941.27229.92525.idtracker@ietfa.amsl.com> <519BC621.4070403@ieca.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [173.73.135.86]:56746 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 3 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: "draft-ietf-core-coap@tools.ietf.org" , "core-chairs@tools.ietf.org" , The IESG , "core@ietf.org" Subject: Re: [core] Sean Turner's Discuss on draft-ietf-core-coap-16: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 09:58:41 -0000 I plan to get it to it this week hopefully tomorrow if not today. spt On 7/1/13 10:00 AM, Barry Leiba wrote: > Sean, you're the one who's left: will you check the -18 version and see > if you're OK with it? > > Other ADs, please also have a look at -18 in light of your non-blocking > comments, and let us know if there are any important points that you'd > like to ask for another look at. > > Handy link: https://datatracker.ietf.org/doc/draft-ietf-core-coap/ > > Thanks, > Barry From internet-drafts@ietf.org Wed Jul 3 06:57:02 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5038311E81B3; Wed, 3 Jul 2013 06:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.483 X-Spam-Level: X-Spam-Status: No, score=-102.483 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RGvX3sfpwA+F; Wed, 3 Jul 2013 06:57:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C3BFD11E81B2; Wed, 3 Jul 2013 06:56:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130703135659.32571.88749.idtracker@ietfa.amsl.com> Date: Wed, 03 Jul 2013 06:56:59 -0700 Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-http-mapping-01.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 13:57:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Constrained RESTful Environments Working = Group of the IETF. Title : Best Practices for HTTP-CoAP Mapping Implementation Author(s) : Angelo P. Castellani Salvatore Loreto Akbar Rahman Thomas Fossati Esko Dijk Filename : draft-ietf-core-http-mapping-01.txt Pages : 21 Date : 2013-07-03 Abstract: This draft provides reference information for HTTP-CoAP protocol translation proxy implementors, focusing primarily on the reverse proxy case. It details deployment options, discusses possible approaches for URI mapping, and provides a set of guidelines and considerations related to protocol translation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-http-mapping There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-core-http-mapping-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-http-mapping-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From trac+core@trac.tools.ietf.org Wed Jul 3 07:22:16 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8226421F9C2A for ; Wed, 3 Jul 2013 07:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YbprGODeCeJ6 for ; Wed, 3 Jul 2013 07:22:15 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 84D8021F9C1E for ; Wed, 3 Jul 2013 07:22:12 -0700 (PDT) Received: from localhost ([127.0.0.1]:35013 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UuNwN-0004VS-45; Wed, 03 Jul 2013 16:21:51 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-http-mapping@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Wed, 03 Jul 2013 14:21:51 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/core/trac/ticket/330#comment:1 Message-ID: <075.5bcba19c7f9779deb137ae91699118e7@trac.tools.ietf.org> References: <060.1ddf0f9d1715d9905182676da2f0559f@trac.tools.ietf.org> X-Trac-Ticket-ID: 330 In-Reply-To: <060.1ddf0f9d1715d9905182676da2f0559f@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-http-mapping@tools.ietf.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, angelo@castellani.net, esko.dijk@philips.com, salvatore.loreto@ericsson.com, tho@koanlogic.com Resent-Message-Id: <20130703142212.84D8021F9C1E@ietfa.amsl.com> Resent-Date: Wed, 3 Jul 2013 07:22:12 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #330: Include HTTP-CoAP URI mapping proposals sent to WG list X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 14:22:16 -0000 #330: Include HTTP-CoAP URI mapping proposals sent to WG list Changes (by esko.dijk@philips.com): * status: new => closed * resolution: => fixed Comment: Done in -01 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-http- esko.dijk@philips.com | mapping@tools.ietf.org Type: protocol | Status: closed defect | Milestone: Priority: major | Version: Component: http- | Resolution: fixed mapping | Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From cabo@tzi.org Thu Jul 4 12:50:29 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80F1711E81A1; Thu, 4 Jul 2013 12:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.949 X-Spam-Level: X-Spam-Status: No, score=-105.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TvpV2ZL70Ah3; Thu, 4 Jul 2013 12:50:24 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 48BBB11E81A3; Thu, 4 Jul 2013 12:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r64JoKMG027779; Thu, 4 Jul 2013 21:50:20 +0200 (CEST) Received: from [192.168.217.105] (p548940C7.dip0.t-ipconnect.de [84.137.64.199]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id E20393FA1; Thu, 4 Jul 2013 21:50:18 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Thu, 4 Jul 2013 21:50:15 +0200 To: "lwip@ietf.org" , "core@ietf.org WG" , roll WG , "6lowpan@ietf.org" <6lowpan@ietf.org>, dice@ietf.org, "6lo@ietf.org" <6lo@ietf.org>, IETF 6TSCH <6tsch@ietf.org> Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [core] Constrained Node/Network Cluster @ IETF87 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 19:50:29 -0000 Here is my usual eclectic condensed agenda. All times are CEST = (UTC+0200). Note that there is no ROLL meeting in Berlin (and, as usual, no 6lowpan = meeting, but indeed a 6lo BOF). Note that the times can still change in the course of conflict = resolution. The CoRE/saag conflict is unfortunate, but because of the overful agenda = there is little chance in fixing it. We probably should do all security-related CoRE work on Monday. Let me also take the opportunity to point to the colocated ETSI 6lowpan = plugtest on July 27/28. You can still register (and thanks to EC support, there is no charge)! http://www.etsi.org/news-events/events/663-2013-6lowpan-plugtests Gr=FC=DFe, Carsten MONDAY, July 29, 2013 0900-1130 Morning Session I Charl_burg 2/3 APP appsawg Applications Area Working Group WG - = Combined with APPAREA Potsdam 1 INT homenet Home Networking WG Schoeneberg 1/2 OPS eman Energy Management WG - 0900-1000 Potsdam 2 TSV tsvwg Transport Area Working Group WG 1300-1500 Afternoon Session I Potsdam 3 APP *** core Constrained RESTful Environments WG 1510-1610 Afternoon Session II Bellevue INT 6man IPv6 Maintenance WG Charl_burg 2/3 TSV tsvwg Transport Area Working Group WG 1620-1720 Afternoon Session III Bellevue INT 6man IPv6 Maintenance WG TUESDAY, July 30, 2013 1300-1500 Afternoon Session I Potsdam 1 OPS v6ops IPv6 Operations WG Potsdam 3 RTG rtgarea Routing Area Open Meeting Charl_burg 2/3 SEC jose Javascript Object Signing and Encryption = WG 1520-1650 Afternoon Session II Bellevue INT *** 6tsch Deterministic IPv6 over IEEE802.15.4e = Timeslotted Channel Hopping BOF WEDNESDAY, July 31, 2013 0900-1130 Morning Session I Potsdam 1 OPS v6ops IPv6 Operations WG Tiergarten 1/2 SEC oauth Web Authorization Protocol WG 1300-1500 Afternoon Session I Potsdam 3 INT *** lwig Light-Weight Implementation Guidance WG Potsdam 2 SEC httpauth Hypertext Transfer Protocol = Authentication WG 1510-1610 Afternoon Session II Potsdam 2 APP httpbis Hypertext Transfer Protocol Bis WG Potsdam 3 SEC *** dice DTLS In Constrained Environments BOF 1620-1720 Afternoon Session III Potsdam 2 APP httpbis Hypertext Transfer Protocol Bis WG THURSDAY, August 1, 2013 0900-1020 Morning Session I Potsdam 2 APP json JavaScript Object Notation WG Potsdam 3 TSV tsvarea Transport Area Open Meeting 1030-1130 Morning Session II Potsdam 3 TSV tsvarea Transport Area Open Meeting 1300-1500 Afternoon Session I Bellevue APP *** core Constrained RESTful Environments WG Potsdam 1 SEC saag Security Area Open Meeting Charl_burg 2/3 TSV rmcat RTP Media Congestion Avoidance = Techniques WG 1700-1830 Afternoon Session III Bellevue INT *** 6lo IPv6 over networks of = resource-constrained nodes BOF FRIDAY, August 2, 2013 0900-1100 Morning Session I Bellevue APP httpbis Hypertext Transfer Protocol Bis WG Potsdam 3 INT dnssdext DNS-SD Extensions BOF Charl_burg 1 SEC tls Transport Layer Security WG 1120-1220 Afternoon Session I Potsdam 3 INT intarea Internet Area Working Group WG 1230-1330 Afternoon Session II Potsdam 3 INT intarea Internet Area Working Group WG From denglingli@gmail.com Thu Jul 4 19:38:39 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2F3311E8109 for ; Thu, 4 Jul 2013 19:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.074 X-Spam-Level: * X-Spam-Status: No, score=1.074 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9i0F0w1PGQ2T for ; Thu, 4 Jul 2013 19:38:38 -0700 (PDT) Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id D648F11E80D9 for ; Thu, 4 Jul 2013 19:38:37 -0700 (PDT) Received: by mail-vc0-f181.google.com with SMTP id lf11so1296520vcb.12 for ; Thu, 04 Jul 2013 19:38:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=v5X8sLuD/SQBmUL8PK3EHiw70eNMkEGxRHQb76KJ4aM=; b=vv7NvN/eupO6QqpjqHd2nIBiaZPw8N7oehuCQlO02D0fgVBsxZGBartyIiYs7fe2Vg GYGKaWMoDfE6Fw+sRHrO8pI0Jd/JazfGlst7jlNfiVv0OSbrkR2/gWupXaIPQ1Mt3nNX 9dCDHYmu0/CVICU6BA9Lz/sPdVlizkNUk7RULs+lKt68+JsLlmeShtm4YtDA8I8r/ieD 3/6dHOVRpQ94riy2/mAEzSWGiU+wdorVJwgZtYkj82sqyk/0gSMP878f1SwLACDyGj3D Lt/JZi341nVFAfe0ihg4rCHE9Nn/F1X3EshUBgbqAFzkXrTffZNtOSu/MCe35Hdv9uca WkwA== MIME-Version: 1.0 X-Received: by 10.58.155.37 with SMTP id vt5mr5089646veb.41.1372991917153; Thu, 04 Jul 2013 19:38:37 -0700 (PDT) Received: by 10.58.18.240 with HTTP; Thu, 4 Jul 2013 19:38:37 -0700 (PDT) In-Reply-To: <002b01ce7713$2073b160$615b1420$@com> References: <002b01ce7713$2073b160$615b1420$@com> Date: Fri, 5 Jul 2013 10:38:37 +0800 Message-ID: From: lingli deng To: qiminpeng Content-Type: multipart/mixed; boundary=047d7b67239a80725c04e0ba97d1 Cc: core@ietf.org Subject: [core] Fwd: FW: New Version Notification for draft-zhu-core-groupauth-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 02:38:40 -0000 --047d7b67239a80725c04e0ba97d1 Content-Type: multipart/alternative; boundary=047d7b67239a80725804e0ba97cf --047d7b67239a80725804e0ba97cf Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi Minpeng, I think you have raised an interesting question on how to do nodes' authentication efficiently. Good way to go! However, as a security layman, it is a little troublesome for me to understand your proposal's advantages over the current two-layer solution you mentioned in the first part of the draft. In particulr, I have the following questions: 1) In terms of the proposed group authentication scheme, is the group agent assumed to be trustworthy? 2) Is it fair to say that the group agent is comparable to the agent in the current two-layer soluton? 3) How can one conclude that the proposal is a better solution in face of "a untrustworthy agent" as described in the requirement statement section? BR Lingli > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: core-bounces@ietf.org [mailto:core-bounces@ietf.org] = =B4=FA=B1=ED =C6=EB=95F=C5=F4 > =B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA6=D4=C224=C8=D5 11:10 > =CA=D5=BC=FE=C8=CB: core@ietf.org > =D6=F7=CC=E2: [core] FW: New Version Notification for draft-zhu-core-grou= pauth-00.txt > > Hi everyone, > > The authors have submit a new draft for the group authentication. We will > appreciate if you have a look and give us any comment or suggestion. The > link is as below. > > Here is a problem that for group communication there is only uni-cast > authentication instead of group authentication method can be used. This > draft wants to analyze the problem, to summarize group authentication > requirement and to provide a framework of solutions. > > BRs, > Minpeng > > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: internet-drafts@ietf.org [mailto:internet-drafts@ietf= .org] > =B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA6=D4=C224=C8=D5 10:19 > =CA=D5=BC=FE=C8=CB: Ye Tian; Minpeng Qi; Judy Zhu > =D6=F7=CC=E2: New Version Notification for draft-zhu-core-groupauth-00.tx= t > > > A new version of I-D, draft-zhu-core-groupauth-00.txt > has been successfully submitted by Judy Zhu and posted to the > IETF repository. > > Filename: draft-zhu-core-groupauth > Revision: 00 > Title: Group Authentication > Creation date: 2013-06-24 > Group: Individual Submission > Number of pages: 10 > URL: > http://www.ietf.org/internet-drafts/draft-zhu-core-groupauth-00.txt > Status: http://datatracker.ietf.org/doc/draft-zhu-core-groupauth > Htmlized: http://tools.ietf.org/html/draft-zhu-core-groupauth-00 > > > Abstract: > The group communication is designed for the communication of Internet > of Things. A threat is identified in [I-D.ietf-core-groupcomm] that > current DTLS based approach is unicast oriented and there is no > supporting on group authentication feature. Unicast oriented > authentication will causing serious burden when a large number of > terminal nodes will be involved inevitably. In another aspect, some > terminals will own the same characteristics, such as owning same > features, in the same place, working in the same time, etc. With this > mechanism, all terminals can be authenticated together with little > signaling and calculation at the same time. It will reduce the > network burden and save time. This draft describes the security of > group authentication and an group authentication implementation > method for the Internet of things. > > > > > The IETF Secretariat > > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --047d7b67239a80725804e0ba97cf Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable

Hi Minpeng,
 
I think you have ra= ised an interesting question on how to do nodes' authentication efficie= ntly. Good way to go!
 
However, = as a security layman, it is a little troublesome for me to understand = your proposal's advantages over the current two-layer solution you ment= ioned in the first part of the draft.
 
In partic= ulr, I have the following questions:
 =
1) In terms of the proposed group authenti= cation scheme, is the group agent assumed to be trustworthy?
 
2) Is it = fair to say that the group agent is comparable to the agent in the current = two-layer soluton?
 
3) How can one conclude that the proposal is a better solution in face of &= quot;a untrustworthy agent" as described in the requirement statement = section?
 
 
BR
L= ingli

 

-----=D3=CA=BC=FE=D4=AD=BC=FE-----
=B7=A2=BC=FE=C8=CB: core-bounces@i= etf.org [mailto:core-bounces@i= etf.org] =B4=FA=B1=ED =C6=EB=95F=C5=F4
=B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA6=D4=C224=C8=D5 11:10
=CA=D5=BC=FE=C8=CB: core@ietf.org
=D6=F7=CC=E2: [core] FW: New Version Notification for draft-zhu-core-groupa= uth-00.txt

Hi everyone,

The authors have submit a new draft for the group authentication. We will a= ppreciate if you have a look and give us any comment or suggestion. The lin= k is as below.

Here is a problem that for group communication there is only uni-cast authe= ntication instead of group authentication method can be used. This draft wa= nts to analyze the problem, to summarize group authentication requirement a= nd to provide a framework of solutions.

BRs,
Minpeng

-----=D3=CA=BC=FE=D4=AD=BC=FE-----
=B7=A2=BC=FE=C8=CB: internet-dr= afts@ietf.org [mailto:inter= net-drafts@ietf.org]
=B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA6=D4=C224=C8=D5 10:19
=CA=D5=BC=FE=C8=CB: Ye Tian; Minpeng Qi; Judy Zhu
=D6=F7=CC=E2: New Version Notification for draft-zhu-core-groupauth-00.txt<= br>

A new version of I-D, draft-zhu-core-groupauth-00.txt
has been successfully submitted by Judy Zhu and posted to the
IETF repository.

Filename:        draft-zhu-core-groupauth
Revision:        00
Title:           Group Authentication
Creation date:   2013-06-24
Group:           Individual Submission
Number of pages: 10
URL:             http:= //www.ietf.org/internet-drafts/draft-zhu-core-groupauth-00.txt
Status:          http://datatracker.ie= tf.org/doc/draft-zhu-core-groupauth
Htmlized:        http://tools.ietf.org/html/d= raft-zhu-core-groupauth-00


Abstract:
   The group communication is designed for the communication of I= nternet
   of Things. A threat is identified in [I-D.ietf-core-groupcomm]= that
   current DTLS based approach is unicast oriented and there is n= o
   supporting on group authentication feature. Unicast oriented    authentication will causing serious burden when a large number= of
   terminal nodes will be involved inevitably. In another aspect,= some
   terminals will own the same characteristics, such as owning sa= me
   features, in the same place, working in the same time, etc. Wi= th this
   mechanism, all terminals can be authenticated together with li= ttle
   signaling and calculation at the same time. It will reduce the=
   network burden and save time. This draft describes the securit= y of
   group authentication and an group authentication implementatio= n
   method for the Internet of things.




The IETF Secretariat




_______________________________________________
core mailing list
core@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/core

--047d7b67239a80725804e0ba97cf-- --047d7b67239a80725c04e0ba97d1 Content-Type: text/plain; charset=US-ASCII; name="draft-zhu-core-groupauth-00.txt" Content-Disposition: attachment; filename="draft-zhu-core-groupauth-00.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: b44f0ab63ae9e509_0.1 Q29yZSBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBKLiBaaHUNCkludGVybmV0IERyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIE0uIFFpDQpJbnRlbmRlZCBzdGF0dXM6IEluZm9ybWF0 aW9uYWwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgWS4gVGlhbg0KRXhwaXJlczpE ZWNlbWJlciAyNCwgMjAxMyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBDaGluYSBN b2JpbGUNCgkJICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEp1biAy NCwgMjAxMw0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgR3JvdXAgQXV0aGVudGljYXRp b24NCiAgICAgICAgICAgICAgICAgICAgICBkcmFmdC16aHUtY29yZS1ncm91cGF1dGgtMDANCg0K QWJzdHJhY3QNCiAgIFRoZSBncm91cCBjb21tdW5pY2F0aW9uIGlzIGRlc2lnbmVkIGZvciB0aGUg Y29tbXVuaWNhdGlvbiBvZiBJbnRlcm5ldA0KICAgb2YgVGhpbmdzLiBBIHRocmVhdCBpcyBpZGVu dGlmaWVkIGluIFtJLUQuaWV0Zi1jb3JlLWdyb3VwY29tbV0gdGhhdCANCiAgIGN1cnJlbnQgRFRM UyBiYXNlZCBhcHByb2FjaCBpcyB1bmljYXN0IG9yaWVudGVkIGFuZCB0aGVyZSBpcyBubyANCiAg IHN1cHBvcnRpbmcgb24gZ3JvdXAgYXV0aGVudGljYXRpb24gZmVhdHVyZS4gVW5pY2FzdCBvcmll bnRlZCANCiAgIGF1dGhlbnRpY2F0aW9uIHdpbGwgY2F1c2luZyBzZXJpb3VzIGJ1cmRlbiB3aGVu IGEgbGFyZ2UgbnVtYmVyIG9mIA0KICAgdGVybWluYWwgbm9kZXMgd2lsbCBiZSBpbnZvbHZlZCBp bmV2aXRhYmx5LiBJbiBhbm90aGVyIGFzcGVjdCwgc29tZSANCiAgIHRlcm1pbmFscyB3aWxsIG93 biB0aGUgc2FtZSBjaGFyYWN0ZXJpc3RpY3MsIHN1Y2ggYXMgb3duaW5nIHNhbWUgDQogICBmZWF0 dXJlcywgaW4gdGhlIHNhbWUgcGxhY2UsIHdvcmtpbmcgaW4gdGhlIHNhbWUgdGltZSwgZXRjLiBX aXRoIHRoaXMgDQogICBtZWNoYW5pc20sIGFsbCB0ZXJtaW5hbHMgY2FuIGJlIGF1dGhlbnRpY2F0 ZWQgdG9nZXRoZXIgd2l0aCBsaXR0bGUgDQogICBzaWduYWxpbmcgYW5kIGNhbGN1bGF0aW9uIGF0 IHRoZSBzYW1lIHRpbWUuIEl0IHdpbGwgcmVkdWNlIHRoZSANCiAgIG5ldHdvcmsgYnVyZGVuIGFu ZCBzYXZlIHRpbWUuIFRoaXMgZHJhZnQgZGVzY3JpYmVzIHRoZSBzZWN1cml0eSBvZiANCiAgIGdy b3VwIGF1dGhlbnRpY2F0aW9uIGFuZCBhbiBncm91cCBhdXRoZW50aWNhdGlvbiBpbXBsZW1lbnRh dGlvbiANCiAgIG1ldGhvZCBmb3IgdGhlIEludGVybmV0IG9mIHRoaW5ncy4NCg0KU3RhdHVzIG9m IHRoaXMgTWVtbw0KICAgVGhpcyBJbnRlcm5ldC1EcmFmdCBpcyBzdWJtaXR0ZWQgaW4gZnVsbCBj b25mb3JtYW5jZSB3aXRoIHRoZSANCiAgIHByb3Zpc2lvbnMgb2YgQkNQIDc4IGFuZCBCQ1AgNzku DQoNCiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVy bmV0IEVuZ2luZWVyaW5nDQogICBUYXNrIEZvcmNlIChJRVRGKSwgaXRzIGFyZWFzLCBhbmQgaXRz IHdvcmtpbmcgZ3JvdXBzLiAgTm90ZSB0aGF0DQogICBvdGhlciBncm91cHMgbWF5IGFsc28gZGlz dHJpYnV0ZSB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC0NCiAgIERyYWZ0cy4NCg0KICAg SW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBv ZiBzaXggbW9udGhzDQogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0 ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQ0KICAgdGltZS4gIEl0IGlzIGluYXBwcm9wcmlh dGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UNCiAgIG1hdGVyaWFsIG9yIHRv IGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiINCg0KICAgVGhlIGxp c3Qgb2YgY3VycmVudCBJbnRlcm5ldC1EcmFmdHMgY2FuIGJlIGFjY2Vzc2VkIGF0DQogICBodHRw Oi8vd3d3LmlldGYub3JnL2lldGYvMWlkLWFic3RyYWN0cy50eHQNCg0KDQpKdWR5ICAgICAgICAg ICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMjQsIDIwMTMgICAgICAgICAgICAgICAgICAgW1BhZ2Ug MV0NCg0KSW50ZXJuZXQtRHJhZnQgICAgICAgICBHcm91cCBBdXRoZW50aWNhdGlvbiAgICAgICAg ICAgICAgICAgICAgIEp1biAyMDEzDQoNCiAgIFRoZSBsaXN0IG9mIEludGVybmV0LURyYWZ0IFNo YWRvdyBEaXJlY3RvcmllcyBjYW4gYmUgYWNjZXNzZWQgYXQNCiAgIGh0dHA6Ly93d3cuaWV0Zi5v cmcvc2hhZG93Lmh0bWwNCg0KICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBE ZWNlbWJlciAyNCwgMjAxMy4NCg0KQ29weXJpZ2h0IE5vdGljZQ0KICAgQ29weXJpZ2h0IChjKSAy MDEzIElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMgdGhlIA0KICAgZG9j dW1lbnQgYXV0aG9ycy4gQWxsIHJpZ2h0cyByZXNlcnZlZC4NCiAgIA0KICAgVGhpcyBkb2N1bWVu dCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQgdGhlIElFVEYgVHJ1c3QncyBMZWdhbCBQcm92aXNp b25zDQogICBSZWxhdGluZyB0byBJRVRGIERvY3VtZW50cyAoaHR0cDovL3RydXN0ZWUuaWV0Zi5v cmcvbGljZW5zZS1pbmZvKSANCiAgIGluIGVmZmVjdCBvbiB0aGUgZGF0ZSBvZiBwdWJsaWNhdGlv biBvZiB0aGlzIGRvY3VtZW50LiAgUGxlYXNlDQogICByZXZpZXcgdGhlc2UgZG9jdW1lbnRzIGNh cmVmdWxseSwgYXMgdGhleSBkZXNjcmliZSB5b3VyIHJpZ2h0cyANCiAgIGFuZCByZXN0cmljdGlv bnMgd2l0aCByZXNwZWN0IHRvIHRoaXMgZG9jdW1lbnQuIA0KICAgDQpUYWJsZSBvZiBDb250ZW50 cw0KDQogICAxLiBJbnRyb2R1Y3Rpb24gLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLjINCiAgIDIuIENvbnZlbnRpb25zIHVzZWQgaW4gdGhpcyBkb2N1 bWVudCAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMw0KICAgMy4gUHJvYmxlbSBTdGF0 ZW1lbnQgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4zDQog ICAzLjEuIFVzZSBjYXNlcyAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLjMNCiAgIDMuMi4gUHJvYmxlbSBzdGF0ZW1lbnQgLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNA0KICAgNC4gUmVxdWlyZW1lbnQgLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi41DQogICA1LiBH cm91cCBBdXRoZW50aWNhdGlvbiBTb2x1dGlvbiAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLjYNCiAgIDUuMS4gSW50cm9kdWN0aW9uIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNg0KICAgNS4yLiBEZXRhaWxlZCBncm91cCBzY2VuYXJp byBkZXNjcmlwdGlvbiAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi42DQogICA1LjMuIEdyb3Vw IHNjZW5hcmlvIHByb2NlZHVyZSAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u LjgNCiAgIDYuIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uOQ0KICAgNy4gSUFOQSBDb25zaWRlcmF0aW9ucyAuLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi45DQogICA4LiBDb25jbHVzaW9ucyAu Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTANCiAg IDkuIFJlZmVyZW5jZXMgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4xMA0KICAgOS4xLiBOb3JtYXRpdmUgUmVmZXJlbmNlcyAuLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjEwDQogICA5LjIuIEluZm9ybWF0aXZlIFJlZmVy ZW5jZXMgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTANCg0KMS4gSW50 cm9kdWN0aW9uDQoNCiAgIFdpdGggdGhlIGRldmVsb3BtZW50IG9mIEludGVybmV0IG9mIFRoaW5n cywgYSBsYXJnZSBudW1iZXIgb2YgDQogICB0ZXJtaW5hbCBub2RlcyB3aWxsIGJlIGludm9sdmVk IGluZXZpdGFibHkuIFRoZSB1bmljYXN0IA0KICAgYXV0aGVudGljYXRpb24gY29tbXVuaWNhdGlv biBmcm9tIGJpZyBhbW91bnQgdGVybWluYWxzIHdpbGwgbWVyZ2UgDQogICB0b2dldGhlciBpbiB0 aGUgbmV0d29yaywgYW5kIGNhdXNpbmcgc2VyaW91cyBidXJkZW4gdG8gdGhlIHNlcnZlci4gDQog ICBBbHRob3VnaCBJUCBtdWx0aWNhc3QgdGVjaG5pY2FsIGlzIGludHJvZHVjZWQgZm9yIGdyb3Vw IGNvbW11bmljYXRpb24gDQogICBpbiBbSS1ELmlldGYtY29yZS1ncm91cGNvbW1dLCBJUCBtdWx0 aWNhc3QgcmVsaWVzIG9uIHRoZSB1bmljYXN0IA0KICAgYXV0aGVudGljYXRpb24gYXQgaW5pdGlh bCBzdGFnZS4gSW4gYW5vdGhlciBhc3BlY3QsIHNvbWUgdGVybWluYWxzIA0KICAgd2lsbCBvd24g dGhlIHNhbWUgY2hhcmFjdGVyaXN0aWNzLCBzdWNoIGFzIG93bmluZyBzYW1lIGZlYXR1cmVzLCBp biANCg0KDQpKdWR5ICAgICAgICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMjQsIDIwMTMgICAg ICAgICAgICAgICAgICAgW1BhZ2UgMl0NCg0KSW50ZXJuZXQtRHJhZnQgICAgICAgICBHcm91cCBB dXRoZW50aWNhdGlvbiAgICAgICAgICAgICAgICAgICAgIE1heSAyMDEzDQoNCiAgIHRoZSBzYW1l IHBsYWNlLCB3b3JraW5nIGluIHRoZSBzYW1lIHRpbWUsIGV0Yy4gV2l0aCB0aGlzIG1lY2hhbmlz bSwgDQogICBhbGwgdGVybWluYWxzIGNhbiBiZSBhdXRoZW50aWNhdGVkIHdpdGggbGl0dGxlIHNp Z25hbGluZyBhbmQgDQogICBjYWxjdWxhdGlvbiBhdCB0aGUgc2FtZSB0aW1lLiBJdCB3aWxsIHJl ZHVjZSB0aGUgbmV0d29yayBidXJkZW4gYW5kIA0KICAgc2F2ZSB0aW1lLiANCg0KICAgVGhpcyBk cmFmdCBkZXNjcmliZXMgdGhlIHNlY3VyaXR5IG9mIGdyb3VwIGF1dGhlbnRpY2F0aW9uIGFuZCBh biANCiAgIGdyb3VwIGF1dGhlbnRpY2F0aW9uIGltcGxlbWVudGF0aW9uIG1ldGhvZCBmb3IgdGhl IEludGVybmV0IG9mIHRoaW5ncy4NCg0KMi4gQ29udmVudGlvbnMgdXNlZCBpbiB0aGlzIGRvY3Vt ZW50DQoNCiAgIFRoZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAi U0hBTEwiLCAiU0hBTEwgTk9UIiwgDQogICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01N RU5ERUQiLCAiTUFZIiwgYW5kICJPUFRJT05BTCIgaW4gdGhpcyANCiAgIGRvY3VtZW50IGFyZSB0 byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gUkZDLTIxMTkgW1JGQzIxMTldLiANCg0K ICAgSW4gdGhpcyBkb2N1bWVudCwgdGhlc2Ugd29yZHMgd2lsbCBhcHBlYXIgd2l0aCB0aGF0IGlu dGVycHJldGF0aW9uICAgDQogICBvbmx5IHdoZW4gaW4gQUxMIENBUFMuIExvd2VyIGNhc2UgdXNl cyBvZiB0aGVzZSB3b3JkcyBhcmUgbm90IHRvIGJlICAgIA0KICAgaW50ZXJwcmV0ZWQgYXMgY2Fy cnlpbmcgUkZDLTIxMTkgc2lnbmlmaWNhbmNlLg0KDQozLiBQcm9ibGVtIFN0YXRlbWVudA0KDQoz LjEuIFVzZSBjYXNlcw0KICAgTm93YWRheXMgdGhlIG5vcm1hbCBhdXRoZW50aWNhdGlvbiBtZWNo YW5pc20gaW4gbmV0d29yayBpcyBhIA0KICAgdHJhZGl0aW9uYWwgdW5pY2FzdCBhdXRoZW50aWNh dGlvbiBtZXRob2QgYmV0d2VlbiBhIHNpbmdsZSB0ZXJtaW5hbCANCiAgIGFuZCBhIHNpbmdsZSBu ZXR3b3JrIGVudGl0eS4gVGhlIGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbSB3aWxsIGJlIA0KICAg ZmluaXNoZWQgYmFzZWQgb25lIDEtMiByb3VuZCBvZiBjaGFsbGVuZ2UtcmVzcG9uc2UgY29udmVy c2F0aW9uLiBCdXQgDQogICBmb3Igc29tZSBNMk0gc2VydmljZSwgaXQgbWF5IGJlIGEgbGFyZ2Ug YW1vdW50IG9mIHRlcm1pbmFsIHVzZWQgZm9yIA0KICAgYW4gTTJNIHNlcnZpY2UuIFRoZXNlIHRl cm1pbmFscyBhcmUgcGxhY2VkIGluIHRoZSBzYW1lIGxvY2F0aW9uLCB3aWxsIA0KICAgYmUgdXNl ZCBmb3IgdGhlIHNhbWUgcHVycG9zZSwgYW5kIG93biBzYW1lIGJlaGF2aW9yLiBUaGVzZSB0ZXJt aW5hbHMgDQogICBjYW4gYmUgd29ya2VkIHRvZ2V0aGVyIGFzIGEgZ3JvdXAuIA0KDQogICBJbiB0 aGVzZSBzY2VuYXJpb3MsIHRoZSBleGlzdGluZyBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc20gaXMg bm8gDQogICBsb25nZXIgYXBwcm9wcmlhdGUuIFdoZW4gYSBsYXJnZSBudW1iZXIgb2YgdGVybWlu YWxzIHdhbnQgdG8gYWNjZXNzIA0KICAgbmV0d29yayBzZXJ2ZXIsIGh1Z2UgbnVtYmVyIG9mIGF1 dGhlbnRpY2F0aW9uIHNpZ25hbGluZyB3aWxsIGJlIA0KICAgZ2VuZXJhdGVkIGJ5IHRoZSB1bmlj YXN0IGF1dGhlbnRpY2F0aW9uIG1ldGhvZC4gV2hhdCBpcyBtb3JlLCBpdCB3aWxsIA0KICAgY2F1 c2UgbmV0d29yayBjb25nZXN0aW9uIGFuZCBsZWFkIHRvIERvUyBhdHRhY2suIEZvciBzb21lIHRl cm1pbmFsIA0KICAgZGV2aWNlcyB3aGljaCBpcyByZXN0cmljdGVkIHdpdGggbGltaXRlZCBjb21w dXRpbmcgY2FwYWJpbGl0eSBhbmQgDQogICBwb3dlciwgdGhlIHRyYWRpdGlvbmFsIHVuaWNhc3Qg YXV0aGVudGljYXRpb24gd2lsbCBpbmNyZWFzZSB0aGUgDQogICBjb21wdXRhdGlvbmFsIGJ1cmRl biBvZiB0aGVzZSB0ZXJtaW5hbHMgYW5kIGRyYWluIHRoZWlyIHBvb3IgYmF0dGVyeS4NCg0KICAg VGhlIGZvbGxvd2luZyB1c2UgY2FzZXMgYXJlIGlkZW50aWZpZWQgYXQgdGhpcyBwb2ludDoNCg0K DQpKdWR5ICAgICAgICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMjQsIDIwMTMgICAgICAgICAg ICAgICAgICAgW1BhZ2UgM10NCg0KSW50ZXJuZXQtRHJhZnQgICAgICAgICBHcm91cCBBdXRoZW50 aWNhdGlvbiAgICAgICAgICAgICAgICAgICAgIE1heSAyMDEzDQoNCiAgIFNtYXJ0IE1ldGVyaW5n OiBTbWFydCBtZXRlciBpbiBhIGJsb2NrIHdpbGwgdXBsb2FkIG1ldGVyIG51bWJlciANCiAgIHJl cG9ydCBhdCB0aGUgc2FtZSB0aW1lLCBvciB0aGUgc21hcnQgbWV0ZXIgc2VydmVyIG5lZWQgdG8g cmUtDQogICBjb25maWd1cmUgYWxsIHNtYXJ0IG1ldGVycyBhdCB0aGUgc2FtZSB0aW1lLg0KDQog ICBSZW1vdGUgVmVoaWNsZSBNYW5hZ2VtZW50OiBTb21lIHNwZWNpYWwgVmVoaWNsZXMgc3VjaCBh cyBUYXhpIHdpbGwgDQogICBnYXRoZXIgaW4gYSBzbWFsbCBwbGFjZSBsaWtlIGFpcnBvcnQsIHRy YWluIHN0YXRpb24sIGV0Yy4gDQoNCiAgIEludGVsbGlnZW50IGhvbWU6IHZhcmlvdXMgc2Vuc29y cyBlcXVpcHBlZCB3aXRoIGNvbW11bmljYXRpb24gbW9kdWxlcyANCiAgIGFyZSBkZXBsb3llZCBp biBhIGhvdXNlIHRvIG1vbml0b3IgaG91c2UgY29uZGl0aW9ucyBhbmQgbWFrZSBhIA0KICAgY29u dHJvbCB3aGVuIG5lY2Vzc2FyeS4gVGhlc2Ugc2Vuc29ycyBjb2xsZWN0IGFuZCByZXBvcnQgaG91 c2UgDQogICByZWxhdGVkIGluZm9ybWF0aW9uIHRvIGl0cyBvd25lciB0aHJvdWdoIGEgbmV0d29y aywgYW5kIHRha2UgYWN0aW9ucyANCiAgIGJ5IGZvbGxvd2luZyB0aGUgcmVndWxhdGluZyBpbnN0 cnVjdGlvbnMgc2VuZCBieSB0aGUgb3duZXIuDQoNCjMuMi4gUHJvYmxlbSBzdGF0ZW1lbnQNCg0K ICAgSW4gdGhlIGN1cnJlbnQgc21hcnQgbWV0ZXJpbmcgc2VydmljZSB1c2UgY2FzZXMsIGEgbGFy Z2UgYW1vdW50IG9mIA0KICAgc21hcnQgcG93ZXIgbWV0ZXIgdGVybWluYWxzIGFyZSBkZXBsb3ll ZCBpbiBhIGJsb2NrLiBUaGUgc21hcnQgbWV0ZXIgDQogICB1cGxvYWRzIG1ldGVyIHJlcG9ydCBm cmVxdWVudGx5IHRocm91Z2ggdGhlIG5ldHdvcmsgdG8gc21hcnQgbWV0ZXIgDQogICBzZXJ2ZXIu IFdoYXQgaXMgbW9yZSwgc21hcnQgbWV0ZXIgc2VydmVyIHF1ZXJpZXMgYWxsIHRlcm1pbmFscyAN CiAgIHBlcmlvZGljYWxseSB0byBjaGVjayB3aGV0aGVyIHRoZSB0ZXJtaW5hbCBpcyB3b3JrYWJs ZSBvciBub3QuIA0KICAgVGhlcmVmb3JlLCB0aGUgbWV0ZXIgcmVxdWlyZXMgZnJlcXVlbnQgYW5k IG5ldHdvcmsgY29tbXVuaWNhdGlvbi4NCg0KICAgSW4gc3VjaCB1c2UgY2FzZXMsIHdoZW4gYWxs IHRoZSBtZXRlcnMgYWNjZXNzIG5ldHdvcmsgcGFyYWxsZWwgYXQgdGhlIA0KICAgc2FtZSB0aW1l LCBvciB3aGVuIHRoZSBzZXJ2ZXIgc2VuZHMgbWVzc2FnZSB0byBhbGwgbWV0ZXJzLCB0aGUgDQog ICB0ZXJtaW5hbHMgd2lsbCBjb25uZWN0IHRvIHRoZSBuZXR3b3JrIGluIGEgc2hvcnQgdGltZSBw ZXJpb2QgKDFzZWMgfiANCiAgIDFtaW4pLiBBc3N1bWUgdGhlcmUgYXJlIDE5IGJ1aWxkaW5ncyBp biB0aGUgYmxvY2ssIGFuZCBlYWNoIGJ1aWxkaW5nIA0KICAgaGFzIDI1IGZsb29ycyBvbiBhdmVy YWdlIHdpdGggMTAgYXBhcnRtZW50cyBpbiBlYWNoIGZsb29yLiBJZiBlYWNoIA0KICAgYXBhcnRt ZW50IGlzIGVxdWlwcGVkIHdpdGggMSBzbWFydCBwb3dlciBtZXRlciwgdGhlbiA0NzYwIG1ldGVy cyB3aWxsIA0KICAgYmUgZGVwbG95ZWQgaW4gdG90YWwgaW4gdGhlIGJsb2NrLiBUaGlzIHdpbGwg Y2F1c2UgcHJlc3N1cmUgdG8gdGhlIA0KICAgbmV0d29yay4NCg0KICAgU28gYW4gYWdlbnQgbm9k ZSBoYXMgYmVlbiBpbnRyb2R1Y2VkIHRvIGFnZ3JlZ2F0ZSB0aGUgbWVzc2FnZSBmcm9tIA0KICAg dGhlc2UgbWV0ZXJzIGFuZCB0aGVuIHNlbmQgb3V0IHRoZXNlIG1ldGVycyBkYXRhIHRvIHRoZSBz ZXJ2ZXIgDQogICB0b2dldGhlci4gQWZ0ZXIgdGhlIGFnZW50IGlzIGludHJvZHVjZWQsIHRoZSBj b25uZWN0aW9uIGJldHdlZW4gDQogICBtZXRlcnMgYW5kIHNlcnZlcnMgaXMgc3BsaXQgaW50byB0 d28gcGFydHM6IG9uZSBpcyB0aGUgY29ubmVjdGlvbiANCiAgIGJldHdlZW4gbWV0ZXJzLCB0aGUg b3RoZXIgaXMgYW5kIHRoZSBvbmUgYmV0d2VlbiBhZ2VudCBhbmQgc2VydmVyLiANCiAgIFVzdWFs bHkgdGhlIGFnZW50IGlzIHJlc3BvbnNpYmxlIGZvciB0aGUgYXV0aGVudGljYXRpb24gb2YgdGhl IG1ldGVycy4gDQogICBUaGUgc2VydmVyIGlzIHJlc3BvbnNpYmxlIGZvciB0aGUgYXV0aGVudGlj YXRpb24gb2YgdGhlIGFnZW50IG9ubHkgDQogICBhbmQgZ2V0cyBhbGwgaW5mb3JtYXRpb24gYWJv dXQgbWV0ZXJzIHN1Y2ggYXMgSUQsIGRhdGEsIGZyb20gYWdlbnQuIA0KDQogICBUaGUgY3VycmVu dCBzZWN1cml0eSBtZWNoYW5pc20gaXM6IA0KDQoNCkp1ZHkgICAgICAgICAgICAgICAgRXhwaXJl cyBEZWNlbWJlciAyNCwgMjAxMyAgICAgICAgICAgICAgICAgICBbUGFnZSA0XQ0KDQpJbnRlcm5l dC1EcmFmdCAgICAgICAgIEdyb3VwIEF1dGhlbnRpY2F0aW9uICAgICAgICAgICAgICAgICAgICAg TWF5IDIwMTMNCg0KICAgMS4gRWFjaCBtZXRlciBpcyBhdXRoZW50aWNhdGVkIHdpdGggdGhlIGFn ZW50LiBBZ2VudCB3aWxsDQogICAgICBhdXRoZW50aWNhdGUgdGhlIG1ldGVyIG9uZSBieSBvbmUu IEFmdGVyIHRoYXQsIGFnZW50IHNob3VsZCBtYWtlIA0KICAgICAgbXV0dWFsIGF1dGhlbnRpY2F0 aW9uIHdpdGggc2VydmVyLiBUaGVuIHNlcnZlciBjYW4gY29uZmlybSBhZ2VudCANCiAgICAgIGlk ZW50aXR5Lg0KDQogICAyLiBNZXRlciB3aWxsIHNldCB1cCBzZWN1cml0eSBjb25uZWN0aW9uIHdp dGggYWdlbnQsIGFuZCBhZ2VudCB3aWxsIA0KICAgICAgYWxzbyBzZXQgdXAgc2VjdXJpdHkgY29u bmVjdGlvbiB3aXRoIHNlcnZlci4gV2hlbiBhIG1ldGVyIHdhbnRzIHRvIA0KICAgICAgc2VuZCBk YXRhIHRvIHNlcnZlci4gSXQgc2hvdWxkIHNlbmQgdGhlIGRhdGEgY29uZmlkZW50aWFsIA0KICAg ICAgcHJvdGVjdGVkIHRvIGFnZW50IGZpcnN0LiBBZ2VudCB3aWxsIGRlY3J5cHQgdGhlIGRhdGEg YW5kIHRyYW5zZmVyIA0KICAgICAgaXQgdG8gc2VydmVyIGJ5IHVzaW5nIHRoZSBzZWN1cml0eSBw cm90ZWN0aW9uIG1lY2hhbmlzbSBiZXR3ZWVuIA0KICAgICAgYWdlbnQgYW5kIHNlcnZlci4NCg0K ICAgSG93ZXZlciwgdGhpcyBwcm9jZWR1cmUgaGFzIHRoZSBmb2xsb3dpbmcgc2VjdXJpdHkgcHJv YmxlbXM6DQogICAxLiBTaW5jZSBhbGwgbWV0ZXJzIGFyZSBhdXRoZW50aWNhdGVkIGJ5IHRoZSBh Z2VudCBhbmQgbm8gZGlyZWN0IA0KICAgICAgYXV0aGVudGljYXRpb24gZnJvbSBzZXJ2ZXIgdG8g bWV0ZXIuIFRoZSBzZXJ2ZXIgY2FuIGdldCBtZXRlcidzIElEIA0KICAgICAgYW5kIGRhdGEgb25s eSB0aHJvdWdoIGFnZW50LiBTbyB0aGUgYWdlbnQgRHVlIHRvIHRoZSBrZXkgcG9zaXRpb24gDQog ICAgICBpbiB0aGUgYXV0aGVudGljYXRpb24sIHRoZSBzZWN1cml0eSBwcm90ZWN0aW9uIGFib3V0 IGFnZW50IGlzIHZlcnkgDQogICAgICBpbXBvcnRhbnQuIFNlcnZlciBjb3VsZCBub3QgYXV0aGVu dGljYXRlIG1ldGVycyBkaXJlY3RseS4gSXQgY2FuIA0KICAgICAgb25seSByZWx5IG9uIHRoZSBh Z2VudC4gSG93ZXZlciwgdGhlIGFnZW50IHdvdWxkIGJlIHBsYWNlZCBpbiANCiAgICAgIHVuc2Vj dXJlIHBsYWNlIG9yIG93bmVkIGJ5IGRpZmZlcmVudCB1c2VyIHJhdGhlciB0aGFuIHRoZSBzZXJ2 ZXIgDQogICAgICBvd25lci4gSWYgdGhlIGFnZW50IGlzIGNvbXByb21pc2VkIG9yIGxheSB0byBz ZXJ2ZXIsIGFnZW50IGNhbiBhY3QgDQogICAgICBhcyBhIG1pZGRsZSBhdHRhY2tlciB0aGF0IG1h a2VzIGZha2UgYXV0aGVudGljYXRpb24gdG8gbWV0ZXJzIGFuZCANCiAgICAgIHJlcG9ydCBmYWtl IElEIHRvIHNlcnZlcnMuIA0KICAgMi4gQW5vdGhlciBzZWN1cml0eSBwcm9ibGVtIGlzIHJlbGF0 ZWQgd2l0aCBhZ2VudCBhbmQgc2VydmVyLiBVbmRlciANCiAgICAgIHRoaXMgc2NlbmFyaW8sIGFs bCBpbmZvcm1hdGlvbiBmcm9tIG1ldGVycyB3aWxsIGJlIHRyYW5zZmVycmVkIA0KICAgICAgdGhy b3VnaCBhZ2VudC4gU28gYWdlbnQgd2lsbCBrbm93IGFsbCBpbmZvcm1hdGlvbiBnZW5lcmF0ZWQg YnkgDQogICAgICBtZXRlcnMuIEhvd2V2ZXIsIHVuZGVyIHNvbWUgc2NlbmFyaW8sIGFnZW50IHdv dWxkIGJlIG93bmVkIGFuZCANCiAgICAgIHVzZWQgYnkgZGlmZmVyZW50IHVzZXIgb3RoZXIgdGhh biB0aGUgbWV0ZXJzJyBhbmQgc2VydmVycycgb3duZXIuIA0KICAgICAgU28gdW5kZXIgdGhpcyBh c3N1bXB0aW9uLCB0aGUgYWdlbnQgc2hvdWxkIG5vdCBnZXQgdGhlIG1lc3NhZ2UgDQogICAgICBm cm9tIG1ldGVyIHRvIHNlcnZlci4gU28gbWV0ZXJzIHNob3VsZCBzZXQgdXAgYW4gc2VjdXJlIGVu ZC10by1lbmQgDQogICAgICB0dW5uZWwgd2l0aCBzZXJ2ZXIuIEl0IHNob3VsZCByZXF1ZXN0IGFu b3RoZXIgYXV0aGVudGljYXRpb24gYW5kIA0KICAgICAga2V5IGdlbmVyYXRpb24gcHJvY2VkdXJl IGluIGFkZGl0aW9uIHRvIGF1dGhlbnRpY2F0ZSB3aXRoIGFnZW50LiANCiAgICAgIFRoaXMgd2ls bCBicmluZyBjb21wbGV4aXR5IGFuZCBvdmVyaGVhZCB0byB0aGUgc3lzdGVtLg0KDQo0LiBSZXF1 aXJlbWVudA0KDQogICBJbiBvcmRlciB0byByZWR1Y2UgdGhlIGNvc3QgYW5kIHNpbXBsaWZ5IGEg bG90IG9mIG92ZXJoZWFkIHdpdGggdGhlIA0KICAgc2FtZSBjaGFyYWN0ZXJpc3RpY3Mgb2YgdGhl c2UgZ3JvdXBzIG9mIG1ldGVyIG9yIHNlbnNvciBub2RlIGdyb3VwLQ0KICAgYmFzZWQgb3BlcmF0 aW9ucywgaXQgaXMgbmVlZGVkIHRvIHByb3ZpZGUgZ3JvdXAgYXV0aGVudGljYXRpb24uIEZvciAN CiAgIGV4YW1wbGUsIHdoZW4gc21hcnQgbWV0ZXJzIHBlcmZvcm0gYnVsayBjb25maWd1cmF0aW9u IGluZm9ybWF0aW9uIA0KICAgdXBkYXRlcywgaXQgaXMgbmVlZGVkIHRvIGVuc3VyZSB0aGF0IHRo ZSBjb3JyZWN0IGlkZW50aXR5IG9mIHRoZSB1c2VyIA0KICAgbm9kZSB3aXRoaW4gdGhlIGdyb3Vw LCB0byBwcmV2ZW50IHRoZSBjb25maWd1cmF0aW9uIGluZm9ybWF0aW9uIGlzIA0KICAgd3Jvbmcg bm9kZSByZWNlaXZlcy4gSW4gYWRkaXRpb24sIHdoZW4gc21hcnQgbWV0ZXJzIHJlcG9ydCBtZXRl ciANCg0KSnVkeSAgICAgICAgICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDI0LCAyMDEzICAgICAg ICAgICAgICAgICAgIFtQYWdlIDVdDQoNCkludGVybmV0LURyYWZ0ICAgICAgICAgR3JvdXAgQXV0 aGVudGljYXRpb24gICAgICAgICAgICAgICAgICAgICBNYXkgMjAxMw0KDQogICByZWFkaW5ncyB0 byB0aGUgZWxlY3RyaWNpdHkgc3lzdGVtIHBsYXRmb3JtLCBpdCBpcyBhbHNvIG5lZWRlZCB0byBi ZSANCiAgIGFibGUgdG8gcHJvdmUgdGhlIGNvcnJlY3RuZXNzIG9mIHRoZSBpZGVudGl0eSBvZiBz bWFydCBtZXRlcnMsIHRvIA0KICAgcHJldmVudCBtYWxpY2lvdXMgbm9kZSByZXBvcnRpbmcgZmFs c2UgcmVhZGluZ3MuDQoNCjUuIEdyb3VwIEF1dGhlbnRpY2F0aW9uIFNvbHV0aW9uDQo1LjEuIElu dHJvZHVjdGlvbg0KDQogICBHcm91cCBhdXRoZW50aWNhdGlvbiBpcyBhIGtpbmQgb2YgYXV0aGVu dGljYXRpb24gdGVjaG5vbG9naWVzIHRoYXQgYSANCiAgIGdyb3VwIG9mIHVzZXJzIG9yIHRlcm1p bmFscyBjYW4gYmUgYXV0aGVudGljYXRlZCB0b2dldGhlciBhdCB0aGUgc2FtZSANCiAgIHRpbWUu IEluc3RlYWQgb2YgYXV0aGVudGljYXRpbmcgYSBudW1iZXIgb2YgdGVybWluYWxzIG9mIGEgZ3Jv dXAgb25lIA0KICAgYnkgb25lLCBncm91cCBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc20gdHJlYXRz IHRoZXNlIHRlcm1pbmFscyBpbiB0aGUgDQogICBncm91cCBhcyBhIHdob2xlLCBhbmQgYXV0aGVu dGljYXRlcyB0aGVtIHRvZ2V0aGVyLiBFYWNoIGdyb3VwIGhhcyBhIA0KICAgdW5pcXVlIGlkZW50 aWZpZXIsIGFuZCBhbiBhZ2VudCwgd2hpY2ggY2FuIGJlIGNhbGxlZCBhcyBncm91cCBhZ2VudCwg DQogICBncm91cCBnYXRld2F5LCBldGMuDQoNCiAgIEdyb3VwIGF1dGhlbnRpY2F0aW9uIGNvbXBy aXNlcyBmb2xsb3dpbmcgdHdvIHBoYXNlcyBhcyBmb2xsb3dpbmc6DQoNCiAgIDEuIFRoZSBmaXJz dCBwaGFzZSBpcyB0aGF0IHVzZXIvdGVybWluYWwgc2hvdWxkIGJlIGF1dGhlbnRpY2F0ZWQgDQog ICAgICB3aGV0aGVyIGl0IGJlbG9uZ3MgdG8gYSBnaXZlbiBncm91cC4gVGhpcyBjYW4gYmUgaW1w bGVtZW50ZWQgDQogICAgICB0aHJvdWdoIHRoZSBwcm9wcmlldGFyeSBhdXRoZW50aWNhdGlvbiB0 ZWNobm9sb2d5IGluIGEgZ3JvdXAsIHN1Y2ggDQogICAgICBhcyBaaWdiZWUgb3IgYW55IG90aGVy cy4NCg0KICAgMi4gVGhlIHNlY29uZCBwaGFzZSBpcyB0aGF0IG11dHVhbCBhdXRoZW50aWNhdGlv biBzaG91bGQgYmUgbWFkZSANCiAgICAgIGJldHdlZW4gYSBnaXZlbiBuZXR3b3JrIGVudGl0eSwg YW5kIGEgZ3JvdXAgYWdlbnQgd2hvIGlzIA0KICAgICAgcmVzcG9uc2libGUgdG8gZGVsZWdhdGUg YWxsIHRlcm1pbmFscyBpbiB0aGUgZ3JvdXAuIA0KDQogICAgICBBZnRlciB0aGUgYXV0aGVudGlj YXRpb24sIHRlcm1pbmFscyBhbmQgbmV0d29yayBlbnRpdHkgY2FuIA0KICAgICAgZ2VuZXJhdGUg c2VwYXJhdGVkIHNlc3Npb24ga2V5cyBpbmRpdmlkdWFsbHkgaWYgdGhlcmUgaXMgc29tZSANCiAg ICAgIGRlbWFuZCB0byBtYWtlIGluZGl2aWR1YWwgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIG5ldHdv cmsgZW50aXR5IGFuZCANCiAgICAgIGVhY2ggdGVybWluYWwuDQoNCjUuMi4gRGV0YWlsZWQgZ3Jv dXAgc2NlbmFyaW8gZGVzY3JpcHRpb24NCg0KICAgRm9yIGdyb3VwIGF1dGhlbnRpY2F0aW9uLCB0 aGVyZSBpcyBkZXRhaWxlZCBuZXR3b3JrIGRlc2NyaXB0aW9uIGFzIA0KICAgZm9sbG93aW5nLiBU aGVyZSBhcmUgNSBub2RlcyBpbnNpZGUgYSBnaXZlbiBncm91cC4gVGhleSBhcmUgQTEsIEEyLCAN CiAgIEEzLCBBNCwgYW5kIEE1IHdoaWNoIGlzIGdyb3VwIGFnZW50LiBBbmQgdGhlIGdpdmVuIGdy b3VwIGNhbiBiZSBuYW1lZCANCiAgIGFzIGdyb3VwIEEuIEFsbCBub2RlcyBpbiBncm91cCBBIGNh biBjb21tdW5pY2F0ZSB3aXRoIGVhY2ggb3RoZXIuIA0KICAgV2hhdCBpcyBtb3JlLCBBNSBpcyBh YmxlIHRvIGNvbW11bmljYXRlIHdpdGggbmV0d29yayBlbnRpdHkgZGlyZWN0bHkuICANCiAgIE5l dHdvcmsgZW50aXR5IHdpbGwgc3RvcmUgdGhlIGdyb3VwIGluZm9ybWF0aW9uLCBzdWNoIGFzIGlk ZW50aWZpZXJzLCANCiAgIHJvb3Qga2V5cyB1c2VkIGZvciBhbGwgbm9kZXMgaW5zaWRlIHRoZSBn cm91cC4gTmV0d29yayBlbnRpdHkgaXMgYWxzbyANCiAgIHJlc3BvbnNpYmxlIGZvciBnZW5lcmF0 aW5nIGdyb3VwIGF1dGhlbnRpY2F0aW9uIHZlY3Rvci4gVGhlIHNjZW5hcmlvIA0KICAgaXMgc2hv d24gYXMgYmVsb3cuDQoNCkp1ZHkgICAgICAgICAgICAgICAgRXhwaXJlcyBEZWNlbWJlciAyNCwg MjAxMyAgICAgICAgICAgICAgICAgICBbUGFnZSA2XQ0KDQpJbnRlcm5ldC1EcmFmdCAgICAgICAg IEdyb3VwIEF1dGhlbnRpY2F0aW9uICAgICAgICAgICAgICAgICAgICAgTWF5IDIwMTMNCg0KICAg Ky0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0r DQogICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwNCiAgIHwgKy0tLS0tLS0rICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfA0KICAgfCB8ICBBMSAgIHw8LS0tLS0tLS0tKyAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8DQogICB8ICstLS0tLS0tKyAgICAgICAgICB8ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwNCiAgIHwgIF4gICBeICAgICAgICAgICAgIHwgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgfCAgfCAgIHwgICAgICAgICAgICAgfCAgICAg ICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tKyB8DQogICB8ICB8ICAgfCAgICAgICAgICAgICB8 ICAgICAgICAgfCBOZXR3b3JrIEFWIGdlbmVyYXRvciB8IHwNCiAgIHwgIHwgICB8ICAgICAgICAg ICAgIHwgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsgfA0KICAgfCAgfCAgIHwgICAg ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgIF4gICAgICAgICAgICB8DQogICB8ICB8ICAg fCAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgIHwNCiAgIHwg IHwgICBWICAgICAgICAgICAgIFYgICAgICAgICAgICAgICAgICAgICBWICAgICAgICAgICAgfA0K ICAgfCAgfCArLS0tLSsgICAgICAgKy0tLS0tKyAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0t KyB8DQogICB8ICB8IHwgQTIgfDwtLS0tLT58IEE1ICB8PD09PT0+fE5ldHdvcmsgYXV0aGVudGlj YXRvciB8IHwNCiAgIHwgIHwgKy0tLS0rICAgICAgICstLS0tLSsgICAgICArLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSsgfA0KICAgfCAgfCAgfCAgICAgICAgICAgXiAgXiAgXiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB8DQogICB8ICB8ICB8ICArLS0tLS0tLS0rICB8ICArLS0tKyAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwNCiAgIHwgIHwgIHwgIHwgICAgICAgICAgIHwgICAgICBW ICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgfCAgfCAgfCAgfCAgICAgICAgICAgfCAg ICstLS0tKyAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICB8ICB8ICB8ICB8ICAgICAgICAg ICB8ICAgfCBBNCB8ICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgIHwgIFYgIFYgIFYgICAg ICAgICAgIHwgICArLS0tLSsgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgfCAgKy0tLS0t LSsgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICB8ICB8 ICBBMyAgfDwtLS0tLS0tLS0rICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAg IHwgICstLS0tLS0rICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg fA0KICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0rDQpGaWd1cmUgMSBHcm91cCBBdXRoZW50aWNhdGlvbiBBcmNoaXRlY3R1cmUNCiAgIG8g IEE1IChncm91cCBhZ2VudCkgY29tbXVuaWNhdGVzIHdpdGggb3RoZXIgbm9kZXMsIGkuZS4gQTEs IEEyLCBBMywgDQogICAgICBBNCBieSBpbm5lciBncm91cCBwcm90b2NvbC4gIEFsbCBub2RlcyBz aG91bGQgY29udGFpbiBzdWNoIG1vZGVscyANCiAgICAgIGFzIGlubmVyIGdyb3VwIGNvbW11bmlj YXRpb24gbW9kZWwsIGdyb3VwIGF1dGhlbnRpY2F0aW9uIG1vZGUuIA0KICAgICAgSW5uZXIgZ3Jv dXAgY29tbXVuaWNhdGlvbiBtb2RlbCBjYW4gYmUgdXNlZCB0byBzZW5kaW5nL3JlY2VpdmluZyAN CiAgICAgIHRoZSBncm91cCBhdXRoZW50aWNhdGlvbiBtZXNzYWdlLiBHcm91cCBhdXRoZW50aWNh dGlvbiBtb2RlbCBjYW4gDQogICAgICBiZSB1c2VkIHRvIGdlbmVyYXRlIGF1dGhlbnRpY2F0aW9u IHZlY3RvcnMvcmVzcG9uc2UgYW5kIHRvIA0KICAgICAgYXV0aGVudGljYXRlIHBlZXJzLg0KICAg byAgR3JvdXAgYWdlbnQgd2lsbCBtYWtlIG11dHVhbCBhdXRoZW50aWNhdGlvbiB3aXRoIG5ldHdv cmsgZW50aXRpZXMuIA0KICAgICAgVGhlcmUgYXJlIHR3byBraW5kcyBvZiBuZXR3b3JrIGVudGl0 aWVzLiBOZXR3b3JrIGF1dGhlbnRpY2F0b3IgaXMgDQogICAgICByZXNwb25zaWJsZSBmb3IgbXV0 dWFsIGF1dGhlbnRpY2F0aW9uIGFjdGlvbiB3aXRoIGdyb3VwIGFnZW50LiBBbmQgDQogICAgICBO ZXR3b3JrIEFWIGdlbmVyYXRvciBpcyByZXNwb25zaWJsZSBmb3IgZ3JvdXAgYXV0aGVudGljYXRp b24gDQogICAgICB2ZWN0b3IgZ2VuZXJhdGlvbiBhbmQgZm9yd2FyZGluZyBBViB0byBuZXR3b3Jr IGF1dGhlbnRpY2F0b3IuIA0KICAgICAgQWZ0ZXIgdGhlIGF1dGhlbnRpY2F0aW9uLCB0ZXJtaW5h bHMgYW5kIG5ldHdvcmsgZW50aXR5IGNhbiANCiAgICAgIGdlbmVyYXRlIHNlcGFyYXRlZCBzZXNz aW9uIGtleXMgaW5kaXZpZHVhbGx5IGlmIHRoZXJlIGlzIHNvbWUgDQogICAgICBkZW1hbmQgdG8g bWFrZSBpbmRpdmlkdWFsIGNvbW11bmljYXRpb24gYmV0d2VlbiBuZXR3b3JrIGVudGl0eSBhbmQg DQogICAgICBlYWNoIHRlcm1pbmFscy4NCg0KDQpKdWR5ICAgICAgICAgICAgICAgIEV4cGlyZXMg RGVjZW1iZXIgMjQsIDIwMTMgICAgICAgICAgICAgICAgICAgW1BhZ2UgN10NCkludGVybmV0LURy YWZ0ICAgICAgICAgR3JvdXAgQXV0aGVudGljYXRpb24gICAgICAgICAgICAgICAgICAgICBNYXkg MjAxMw0KDQogICBvICBHcm91cCBhZ2VudCB3aG8gcmVwcmVzZW50cyB0aGUgd2hvbGUgZ3JvdXAs IGNvbW11bmljYXRlcyB3aXRoIA0KICAgICAgbmV0d29yayBlbnRpdHksIGFuZCBnZW5lcmF0ZSBn cm91cCBzZXNzaW9uIGtleSB0aHJvdWdoIA0KICAgICAgYXV0aGVudGljYXRpb24gd2l0aCB0aGUg bmV0d29yayBhdXRoZW50aWNhdG9yLiANCiAgIG8gIFByZS1jb25maWd1cmUgb2YgdGhlIGdyb3Vw DQogICBBbGwgdGhlIGdyb3VwIG5vZGVzIHNob3VsZCBiZSBjb25maWd1cmVkIHdpdGggc3ViIGtl eSBrXzEsIGtfMiwga18zLCANCiAgIGtfNCwga19nLCB3aGljaCB3aWxsIGJlIHVzZWQgZm9yIG11 dHVhbCBhdXRoZW50aWNhdGlvbiBpbiB0aGUgZ3JvdXAgDQogICBhbmQgc2VwYXJhdGVkIGNvbW11 bmljYXRpb24uDQoNCjUuMy4gR3JvdXAgc2NlbmFyaW8gcHJvY2VkdXJlDQoNCiAgIEFzIG1lbnRp b25lZCBhYm92ZSwgZ3JvdXAgYXV0aGVudGljYXRpb24gY2FuIGJlIGRpdmlkZWQgaW50byB0d28g DQogICBwaGFzZXMuIA0KDQogICBJbiB0aGUgZmlyc3QgcGhhc2UsIGdyb3VwIG1lbWJlciwgc2F5 IEFpLCBzZW5kcyBhdXRoZW50aWNhdGlvbiANCiAgIHJlcXVlc3QgdG8gZ3JvdXAgYWdlbnQgYXQg Zmlyc3QgYXMgZm9sbG93aW5nLiANCiAgIDEuIEdyb3VwIG1lbWJlciBBaSBzZW5kcyBtZXNzYWdl IHRvIHRyaWdnZXIgYXV0aGVudGljYXRpb24gYXQgZmlyc3QuIA0KICAgMi4gR3JvdXAgYWdlbnQg c2VuZHMgYXV0aGVudGljYXRpb24gcmVxdWVzdCB0byBlYWNoIGdyb3VwIG1lbWJlci4NCiAgIDMu IEdyb3VwIG1lbWJlciBBaSB2ZXJpZmllcyBncm91cCBhZ2VudCBhdCBmaXJzdC4gSWYgc3VjY2Vz cywgQWkgd2lsbCANCiAgICAgIGdlbmVyYXRlIHNlc3Npb24ga2V5IGZvciB0aGUgY29tbXVuaWNh dGlvbiB3aXRoIGdyb3VwIGFnZW50LCBhbmQgDQogICAgICBzZW5kcyByZXNwb25zZSBjb250YWlu aW5nIHN1Y2ggc2Vzc2lvbiBrZXkgYmFjayB0byBncm91cCBhZ2VudC4gSWYgDQogICAgICBub3Qg c3VjY2VzcywgdGhlIGF1dGhlbnRpY2F0aW9uIGlzIGZhaWxlZCBhbmQgZ3JvdXAgYXV0aGVudGlj YXRpb24gDQogICAgICBwcm9jZWR1cmUgd2lsbCBiZSBhYm9ydC4NCiAgIDQuIEdyb3VwIGFnZW50 IGF1dGhlbnRpY2F0ZXMgZWFjaCBncm91cCBtZW1iZXIgQWkgdGhyb3VnaCB0aGUgDQogICAgICBy ZXNwb25zZSBtZXNzYWdlIGFuZCByZWNvcmQgdGhlIGF1dGhlbnRpY2F0aW9uIHJlc3VsdCBpbiBh IG1hcHBpbmcgDQogICAgICB0YWJsZS4NCiAgIEFmdGVyIHRoZSBpbm5lciBncm91cCBhdXRoZW50 aWNhdGlvbiwgYWxsIG9mIGdyb3VwIG1lbWJlcnMgYXJlIA0KICAgYXV0aGVudGljYXRlZCBieSBn cm91cCBhZ2VudCwgYW5kIHNlY29uZCBwaGFzZSBjYW4gYmUgcGVyZm9ybWVkLg0KDQogICA1LiBH cm91cCBhZ2VudCBzZW5kcyBtZXNzYWdlIHRvIG5ldHdvcmsgYXV0aGVudGljYXRvciB0byB0cmln Z2VyIHRoZSANCiAgICAgIGF1dGhlbnRpY2F0aW9uIG91dHNpZGUgdGhlIGdyb3VwLg0KDQogICA2 LiBHcm91cCBhdXRoZW50aWNhdG9yIHNlbmQgYXV0aGVudGljYXRpb24gdmVjdG9yIHJlcXVlc3Qg dG8gbmV0d29yayANCiAgICAgIEFWIGdlbmVyYXRvciB3aXRoIGdyb3VwIGFnZW50IGlkZW50aXR5 Lg0KDQpKdWR5ICAgICAgICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMjQsIDIwMTMgICAgICAg ICAgICAgICAgICAgW1BhZ2UgOF0NCg0KSW50ZXJuZXQtRHJhZnQgICAgICAgICBHcm91cCBBdXRo ZW50aWNhdGlvbiAgICAgICAgICAgICAgICAgICAgIE1heSAyMDEzDQoNCiAgIDcuIE5ldHdvcmsg QVYgZ2VuZXJhdG9yIHdpbGwgZ2VuZXJhdGUgYXV0aGVudGljYXRpb24gdmVjdG9yIA0KICAgICAg YWNjb3JkaW5nIHRvIGdyb3VwIGFnZW50IGlkZW50aXR5Lg0KICAgOC4gV2hhdCBpcyBtb3JlLCBu ZXR3b3JrIEFWIGdlbmVyYXRvciBzaG91bGQgYmUgYWJsZSB0byByZWNvZ25pemUgDQogICAgICB0 aGF0IGlzIGEgZ3JvdXAgYXV0aGVudGljYXRpb24gaXMgcGVyZm9ybWVkIGJhc2VkIG9uIGdyb3Vw IGFnZW50IA0KICAgICAgaWRlbnRpdHkuIE5ldHdvcmsgQVYgZ2VuZXJhdG9yIHdpbGwgZ2VuZXJh dGUgc2Vzc2lvbiBrZXkgZm9yIGVhY2ggDQogICAgICBncm91cCBtZW1iZXJzIGJ5IHVzaW5nIHBy ZS1jb25maWd1cmVkIGdyb3VwIG1lbWJlciBpbmZvcm1hdGlvbiBhbmQgDQogICAgICB0aGUgc2Ft ZSBrZXlpbmcgbWF0ZXJpYWwgaW4gYWJvdmUgc3RlcC4NCiAgIDkuIE5ldHdvcmsgQVYgZ2VuZXJh dG9yIHdpbGwgc2VuZCBzdWNoIGF1dGhlbnRpY2F0aW9uIHZlY3RvciBhbmQgDQogICAgICBzZXNz aW9uIGtleXMgdG9nZXRoZXIgYmFjayB0byBuZXR3b3JrICBhdXRoZW50aWNhdG9yLg0KICAgMTAu TmV0d29yayBhdXRoZW50aWNhdG9yIHdpbGwgcGVyZm9ybSBtdXR1YWwgYXV0aGVudGljYXRpb24g d2l0aCANCiAgICAgIGdyb3VwIGFnZW50Lg0KICAgMTEuR3JvdXAgYWdlbnQgYXV0aGVudGljYXRl IGdyb3VwIGFnZW50IGFuZCBzZW5kIGF1dGhlbnRpY2F0aW9uIA0KICAgICAgcmVzcG9uc2UgYmFj ayB0byBuZXR3b3JrIGF1dGhlbnRpY2F0b3IuDQogICAxMi5OZXR3b3JrIGF1dGhlbnRpY2F0aW9u IGF1dGhlbnRpY2F0ZSBncm91cCBhZ2VudC4gSWYgc3VjY2VzcywgaXQgDQogICAgICBjYW4gYmUg Y29uc2lkZXJlZCB0aGF0IGdyb3VwIGFnZW50IGFuZCBhbGwgZ3JvdXAgdGVybWluYWxzIGlzIA0K ICAgICAgYXV0aGVudGljYXRlZCBzdWNjZXNzZnVsbHkuDQogICAxMy5Hcm91cCBhZ2VudCB3aWxs IGNvbW11bmljYXRlIHdpdGggbmV0d29yayBhdXRoZW50aWNhdG9yIHRvIGNob29zZSANCiAgICAg IHRoZSBjb25maWRlbnRpYWwgYW5kIGludGVncml0eSBwcm90ZWN0aW9uIGFsZ29yaXRobXMuIA0K ICAgMTQuQWZ0ZXIgdGhhdCwgZ3JvdXAgYWdlbnQgd2lsbCBzZW5kIGtleWluZyBtYXRlcmlhbCwg c2VsZWN0ZWQgDQogICAgICBhbGdvcml0aG1zIHRvIGVhY2ggZ3JvdXAgbWVtYmVyLg0KICAgMTUu IEdyb3VwIG1lbWJlciB3aWxsIGdlbmVyYXRlIHNlc3Npb24ga2V5cy4NCg0KICAgQWZ0ZXIgdGhl c2UgdHdvIHBoYXNlcywgZWFjaCB0ZXJtaW5hbCBpcyBhdXRoZW50aWNhdGVkIHdpdGggbmV0d29y ayANCiAgIGF1dGhlbnRpY2F0b3IgYW5kIGdlbmVyYXRlIGluZGVwZW5kZW50bHkgc2Vzc2lvbiBr ZXkgd2l0aCBuZXR3b3JrIA0KICAgYXV0aGVudGljYXRvci4NCg0KNi4gU2VjdXJpdHkgQ29uc2lk ZXJhdGlvbnMNCg0KICAgVGhpcyBtZW1vIGNvbnNpZGVycyB0aGUgc2VjdXJpdHkgYXV0aGVudGlj YXRpb24gZm9yIGdyb3VwLiBTbyBpdCANCiAgIHdvdWxkIG5vdCBpbnRyb2R1Y2UgYW55IGFkZGl0 aW9uYWwgc2VjdXJpdHkgcHJvYmxlbXMuDQoNCjcuIElBTkEgQ29uc2lkZXJhdGlvbnMNCg0KICAg VGhlcmUgYXJlIG5vIElBTkEgY29uc2lkZXJhdGlvbnMgYXNzb2NpYXRlZCB0byB0aGlzIG1lbW8u DQoNCg0KSnVkeSAgICAgICAgICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDI0LCAyMDEzICAgICAg ICAgICAgICAgICAgIFtQYWdlIDldDQoNCkludGVybmV0LURyYWZ0ICAgICAgICAgR3JvdXAgQXV0 aGVudGljYXRpb24gICAgICAgICAgICAgICAgICAgICBNYXkgMjAxMw0KDQogICA4LiBDb25jbHVz aW9ucw0KDQogICAgICBUaGlzIG1lbW8gZGVzY3JpYmVzIHRoZSBwcm9ibGVtIHJhaXNlZCBieSB1 c2luZyBvbmUtdG8tb25lIA0KICAgICAgYXV0aGVudGljYXRpb24gZm9yIGh1Z2UgbnVtYmVyIG9m IEludGVybmV0IG9mIFRoaW5ncyB0ZXJtaW5hbHMuIEFmdGVyIA0KICAgICAgdGhhdCwgZ3JvdXAg YXV0aGVudGljYXRpb24gcmVxdWlyZW1lbnQgaXMgcmFpc2VkIGFuZCBhIGdyb3VwIA0KICAgICAg YXV0aGVudGljYXRpb24gbWVjaGFuaXNtIGlzIHByb3Bvc2VkDQoNCiAgIDkuIFJlZmVyZW5jZXMN CiAgIDkuMS4gTm9ybWF0aXZlIFJlZmVyZW5jZXMNCiAgIDkuMi4gSW5mb3JtYXRpdmUgUmVmZXJl bmNlcw0KDQpBdXRob3JzJyBBZGRyZXNzZXMNCiAgIEp1ZHkgWmh1DQogICBDaGluYSBNb2JpbGUN CiAgIFVuaXQgMiwgMzIgWHVhbnd1bWVueGkgQXZlLA0KICAgWGljaGVuZyBEaXN0cmljdCwNCiAg IEJlaWppbmcgMTAwMDUzLCBDaGluYQkNCiAgIEVtYWlsOiB6aHVob25ncnVAY2hpbmFtb2JpbGUu Y29tDQoNCiAgIE1pbnBlbmcgUWkNCiAgIENoaW5hIE1vYmlsZQ0KICAgVW5pdCAyLCAzMiBYdWFu d3VtZW54aSBBdmUsDQogICBYaWNoZW5nIERpc3RyaWN0LA0KICAgQmVpamluZyAxMDAwNTMsIENo aW5hDQogICBFbWFpbDogcWltaW5wZW5nQGNoaW5hbW9iaWxlLmNvbQ0KDQogICBZZSBUaWFuDQog ICBDaGluYSBNb2JpbGUNCiAgIFVuaXQgMiwgMzIgWHVhbnd1bWVueGkgQXZlLA0KICAgWGljaGVu ZyBEaXN0cmljdCwNCiAgIEJlaWppbmcgMTAwMDUzLCBDaGluYQkNCiAgIEVtYWlsOiB0aWFueWVA Y2hpbmFtb2JpbGUuY29tDQoNCg0KSnVkeSAgICAgICAgICAgICAgICBFeHBpcmVzIERlY2VtYmVy IDI0LCAyMDEzICAgICAgICAgICAgICAgICAgW1BhZ2UgMTBd --047d7b67239a80725c04e0ba97d1-- From ludwig@sics.se Fri Jul 5 04:42:50 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBF1411E82AC for ; Fri, 5 Jul 2013 04:42:50 -0700 (PDT) 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_SE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5F9aAj386Xg7 for ; Fri, 5 Jul 2013 04:42:46 -0700 (PDT) Received: from fsmsg2.sics.se (fsmsg2.sics.se [IPv6:2001:6b0:3a:1:250:56ff:fea9:52ad]) by ietfa.amsl.com (Postfix) with ESMTP id 12FD311E82A4 for ; Fri, 5 Jul 2013 04:42:45 -0700 (PDT) Received: from pps.filterd (fsmsg2 [127.0.0.1]) by fsmsg2.sics.se (8.14.5/8.14.5) with SMTP id r65BcrYl017618 for ; Fri, 5 Jul 2013 13:42:44 +0200 Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by fsmsg2.sics.se with ESMTP id 1dcswctgdu-1 for ; Fri, 05 Jul 2013 13:42:44 +0200 Received: from [192.168.0.103] (unknown [85.235.11.178]) (Authenticated sender: ludwig@sics.se) by letter.sics.se (Postfix) with ESMTPSA id 92B0F40114 for ; Fri, 5 Jul 2013 13:42:44 +0200 (CEST) Message-ID: <1373024564.5556.13.camel@ubuntu.ubuntu-domain> From: Ludwig Seitz To: core@ietf.org Date: Fri, 05 Jul 2013 13:42:44 +0200 Organization: SICS AB Content-Type: multipart/signed; micalg="sha256"; protocol="application/x-pkcs7-signature"; boundary="=-djJL9izfxwKNArvMJSk0" X-Mailer: Evolution 3.2.3-0ubuntu6 Mime-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-07-05_05:2013-07-05, 2013-07-05, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=15 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1307050059 Subject: [core] [Fwd: New Version Notification for draft-selander-core-access-control-00.txt] X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 11:42:51 -0000 --=-djJL9izfxwKNArvMJSk0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear all, I have just submitted a draft on access control for constrained environments. Hopefully some of you will find this an interesting basis for further discussion. The main author, G=C3=B6ran Selander will be available for face-to-face discussions at WG meeting in Berlin. Regards, Ludwig Seitz -------- Forwarded Message -------- > From: internet-drafts@ietf.org > To: Ludwig Seitz , Goeran Selander > , Mohit Sethi > , Goran Selander > > Subject: New Version Notification for > draft-selander-core-access-control-00.txt > Date: Fri, 05 Jul 2013 04:23:41 -0700 >=20 > A new version of I-D, draft-selander-core-access-control-00.txt > has been successfully submitted by Goeran Selander and posted to the > IETF repository. >=20 > Filename: draft-selander-core-access-control > Revision: 00 > Title: Access Control Framework for Constrained Environments > Creation date: 2013-07-05 > Group: Individual Submission > Number of pages: 37 > URL: http://www.ietf.org/internet-drafts/draft-selander-core-= access-control-00.txt > Status: http://datatracker.ietf.org/doc/draft-selander-core-acce= ss-control > Htmlized: http://tools.ietf.org/html/draft-selander-core-access-co= ntrol-00 >=20 >=20 > Abstract: > The Constrained Application Protocol (CoAP) is a light-weight web > transfer protocol designed to be used in constrained nodes and > constrained networks. Communication security support for CoAP, > including authentication, encryption, integrity protection, is well > understood and a DTLS binding for CoAP is specified, but > authorization and access control are not described in detail. >=20 > This document describes a generic and dynamic access control > framework suitable for constrained environments using CoAP. The > framework builds on standards and well known paradigms for access > control, externalizing authorization decision making to unconstrained > nodes while performing authorization decision enforcement and > verification of local conditions in constrained devices. >=20 > In addition, this document provides alternative or complementary key > management to the CoAP security modes. >=20 >=20 > = =20 >=20 >=20 > The IETF Secretariat >=20 --=20 Ludwig Seitz, PhD SICS Swedish ICT AB Ideon Science Park Building Beta 2=20 Scheelev=C3=A4gen 17=20 SE-223 70 Lund Phone +46(0)70-349 92 51 http://www.sics.se --=-djJL9izfxwKNArvMJSk0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEnAw ggYYMIIFAKADAgECAgMFtYswDQYJKoZIhvcNAQELBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQTAeFw0xMzAxMTUwMjA1MDZaFw0xNDAxMTUxNDM3NDhaMDgxFzAVBgNVBAMMDmx1ZHdpZ0Bz aWNzLnNlMR0wGwYJKoZIhvcNAQkBFg5sdWR3aWdAc2ljcy5zZTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAKpuRavr2swCQsYS7KxOsmeBXI39thxAjIYaB0AFVjLpOtVJxQMYoip7Bm9o ka8PXxQ9mWT/lVSoqI7jGjc5Z8q1C4fOFMCYZpJugG9qJS0OMV2ajQ7xXu3YzLTDIKg/BK39+Vri vJq0Y6hz1/4pgxMOFG+l7y+fq54QSkKMwpuRaCBznKJeRxGwDvheF2QN6YEBclFqVhpciDGd52vX 5AgbKbqVmevMrcrcYAdKaKm6iTEmbYHum5D/4GaOnnZ2wMnY5EpKhxxm6SszCVSNdk8iZSUze9GY PzheBDIHMDdLZib6zaoR96F5ZCpE1pPeKIz/DCd3kL+nXpe5gdbSXLsCAwEAAaOCAtQwggLQMAkG A1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQUwDv6gyc7uSHK/QBVIZiN86hjKW4wHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4 UYIwGQYDVR0RBBIwEIEObHVkd2lnQHNpY3Muc2UwggFMBgNVHSAEggFDMIIBPzCCATsGCysGAQQB gbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBk ZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIB ARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhlIENsYXNzIDEg VmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeSwgcmVsaWFu Y2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVs eWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFy dHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZo dHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYD VR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBCwUAA4IBAQA4bagj yL3PLei2tbMELKOVOxRdyLObcVq0Fj83LbSTMj6NS83TU/4xxChfd5zqoipudDSEpgxZAUsSjk02 DxSeLYYBXE2X/iue7nL8S/3PjC49z5ZgjDZrXIgmvIMaZXWM+GqG+wk9NikGb1/shlJjk3R5KC3f RWsUatHouNxAMYxiLFO75YmgKCgkjtKUbHbUqzmDVd30nWQesXfCgYwCbAvD/0NgX3jE+fnyT71+ aX4/IfqshpCQj8dkR4ZH+bUiK5zgKGJL61GRZNSScR/r9Sq19kEQrt38ey/Q90tUDUgg93d5w3DN rF3bRoOvyspwbcN9TuGKkFoFPV0KfjaGMIIGGDCCBQCgAwIBAgIDBbWLMA0GCSqGSIb3DQEBCwUA MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJl IERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQ cmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTMwMTE1MDIwNTA2WhcNMTQwMTE1MTQz NzQ4WjA4MRcwFQYDVQQDDA5sdWR3aWdAc2ljcy5zZTEdMBsGCSqGSIb3DQEJARYObHVkd2lnQHNp Y3Muc2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCqbkWr69rMAkLGEuysTrJngVyN /bYcQIyGGgdABVYy6TrVScUDGKIqewZvaJGvD18UPZlk/5VUqKiO4xo3OWfKtQuHzhTAmGaSboBv aiUtDjFdmo0O8V7t2My0wyCoPwSt/fla4ryatGOoc9f+KYMTDhRvpe8vn6ueEEpCjMKbkWggc5yi XkcRsA74XhdkDemBAXJRalYaXIgxnedr1+QIGym6lZnrzK3K3GAHSmipuokxJm2B7puQ/+Bmjp52 dsDJ2ORKSoccZukrMwlUjXZPImUlM3vRmD84XgQyBzA3S2Ym+s2qEfeheWQqRNaT3iiM/wwnd5C/ p16XuYHW0ly7AgMBAAGjggLUMIIC0DAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAU BggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFMA7+oMnO7khyv0AVSGYjfOoYyluMB8GA1Ud IwQYMBaAFFNy7ZKc4NrLAVx8fpY1TvLUuFGCMBkGA1UdEQQSMBCBDmx1ZHdpZ0BzaWNzLnNlMIIB TAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQg YWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBT dGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3Nl IGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQv MC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUF BwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3Mx L2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3Vi LmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29t LzANBgkqhkiG9w0BAQsFAAOCAQEAOG2oI8i9zy3otrWzBCyjlTsUXcizm3FatBY/Ny20kzI+jUvN 01P+McQoX3ec6qIqbnQ0hKYMWQFLEo5NNg8Uni2GAVxNl/4rnu5y/Ev9z4wuPc+WYIw2a1yIJryD GmV1jPhqhvsJPTYpBm9f7IZSY5N0eSgt30VrFGrR6LjcQDGMYixTu+WJoCgoJI7SlGx21Ks5g1Xd 9J1kHrF3woGMAmwLw/9DYF94xPn58k+9fml+PyH6rIaQkI/HZEeGR/m1Iiuc4ChiS+tRkWTUknEf 6/UqtfZBEK7d/Hsv0PdLVA1IIPd3ecNwzaxd20aDr8rKcG3DfU7hipBaBT1dCn42hjCCBjQwggQc oAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNV BAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoXDTE3 MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENv bSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xC GhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P 3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2Ub FqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2 JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGp MA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6W NU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgw JwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0 cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3Rh cnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywGXLhj jF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXltUfO4 n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+RHxkU CTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktvsv6h xHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+ssS5X MEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq+n6b 1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLp XDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/p Ny8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOg SF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMYIDfzCCA3sCAQEw gZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1 cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAx IFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBbWLMA0GCWCGSAFlAwQCAQUAoIIBuzAY BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA3MDUxMTQyNDRaMC8G CSqGSIb3DQEJBDEiBCA2gIcBS/maLIGUlDtRQ45mhyiM5C8OZ88x/A8cTWj+ojCBpQYJKwYBBAGC NxAEMYGXMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwW1izCBpwYLKoZIhvcNAQkQ AgsxgZeggZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBbWLMA0GCSqGSIb3DQEBAQUA BIIBAJI2/bWfE7sjlBjTvtPoT9Z5cg7QECdkgyl1Y013DL95gv444l3oGEAXn4UI5s4/NsbWq9Gx MwliYO63sy2kIJidZxZNzzBcP8ZNKimYGQPFOfoyQE6aWIn1F04Fm9GoTgtHSjPul2k4PEBD9i36 Hxhohe8d75RNZ0QQ88uvCLgxg7rlxtqzOw3gy625ZIcELtN8wALf+c/SHB+dThbecE9qxcBMcCZQ HExSwa3AXLUJktalLKn3woZSg5rGcnZhaAblOvNmhpcTAldkn5cBC9kMGx9T7dvAuLHF/MPccqJD alUm6KlaZhKMEQ7hETIb9Mk0SQdGHiKO+Y3erVbU6XEAAAAAAAA= --=-djJL9izfxwKNArvMJSk0-- From trac+core@trac.tools.ietf.org Mon Jul 8 04:51:02 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5704821F99C6 for ; Mon, 8 Jul 2013 04:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kpu3iHbrVOp1 for ; Mon, 8 Jul 2013 04:51:01 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id CD59721F9C2C for ; Mon, 8 Jul 2013 04:50:57 -0700 (PDT) Received: from localhost ([127.0.0.1]:54709 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Uw9xy-0000Dy-Qf; Mon, 08 Jul 2013 13:50:50 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Mon, 08 Jul 2013 11:50:50 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/332 Message-ID: <060.ecb6d7b2bd30e58cb7593a44933af6ca@trac.tools.ietf.org> X-Trac-Ticket-ID: 332 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, esko.dijk@philips.com Resent-Message-Id: <20130708115057.CD59721F9C2C@ietfa.amsl.com> Resent-Date: Mon, 8 Jul 2013 04:50:57 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #332: Remove advice for use of blockwise on "/.well-known/core" ? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 11:51:02 -0000 #332: Remove advice for use of blockwise on "/.well-known/core" ? Groupcomm: suggest to remove text in section 3.8 "Alternatively a server can also minimize the payload length of a response to a multicast GET (e.g., on "/.well-known/core") using CoAP blockwise transfers [I-D.ietf-core-block], returning only aa first block of the link format description." Reason: a client that does not know core-block can't use the response. It seems unwise to assume the client knows core-block on such a key resource for discovery. Besides, an alternative solution is available in the form of hierarchically structured link format document. Any opinions on this are welcome! Plan is to remove in next version. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | groupcomm@tools.ietf.org Type: protocol | Status: new defect | Milestone: Priority: major | Version: Component: groupcomm | Keywords: Severity: - | -------------------------+------------------------------------------------- Ticket URL: core From cabo@tzi.org Mon Jul 8 05:32:51 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86A9C11E81D1 for ; Mon, 8 Jul 2013 05:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.174 X-Spam-Level: X-Spam-Status: No, score=-106.174 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nm4PJEXW5oIo for ; Mon, 8 Jul 2013 05:32:45 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 1E29911E81D6 for ; Mon, 8 Jul 2013 05:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r68CWVA2024285; Mon, 8 Jul 2013 14:32:32 +0200 (CEST) Received: from [192.168.217.105] (p54894869.dip0.t-ipconnect.de [84.137.72.105]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id E631E3A97; Mon, 8 Jul 2013 14:32:30 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <060.ecb6d7b2bd30e58cb7593a44933af6ca@trac.tools.ietf.org> Date: Mon, 8 Jul 2013 14:32:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <768D84B8-E67D-4D2A-B005-C93F56B8FF56@tzi.org> References: <060.ecb6d7b2bd30e58cb7593a44933af6ca@trac.tools.ietf.org> To: trac+core@grenache.tools.ietf.org X-Mailer: Apple Mail (2.1508) Cc: draft-ietf-core-groupcomm@tools.ietf.org, core@ietf.org Subject: Re: [core] #332: Remove advice for use of blockwise on "/.well-known/core" ? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 12:32:51 -0000 Well, there are a number of problems here. > Reason: a client that does not know core-block can't use the response. That is not really a problem, because clients that want to make use of = /.well-known/core should do core-block (whether they use multicast or = not). > It > seems unwise to assume the client knows core-block on such a key = resource > for discovery. To me, it seems unwise to build a system that wants to make use of = link-format resources and doesn't do (the client side of) core-block. (The implementation of the client side of core-block is really, really = small.) > Besides, an alternative solution is available in the form > of hierarchically structured link format document. That would mean that the link-format document has to be artificially = structure to fit into the block size most appropriate for the server. = I'd prefer if these considerations weren't spilling over into the format = of resources. (Note that there is only one /.well-known/core, whether requested by = multicast or by unicast.) Gr=FC=DFe, Carsten From turners@ieca.com Mon Jul 8 07:35:29 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4372E21F9B16; Mon, 8 Jul 2013 07:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gxylzsNrtFmQ; Mon, 8 Jul 2013 07:35:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E3CE121F8A03; Mon, 8 Jul 2013 07:35:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Sean Turner" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130708143528.16659.18103.idtracker@ietfa.amsl.com> Date: Mon, 08 Jul 2013 07:35:28 -0700 Cc: draft-ietf-core-coap@tools.ietf.org, core-chairs@tools.ietf.org, core@ietf.org Subject: [core] Sean Turner's Yes on draft-ietf-core-coap-18: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 14:35:29 -0000 Sean Turner has entered the following ballot position for draft-ietf-core-coap-18: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hey thanks for doing an excellent job addressing my comments. Looking forward to progressing this one down the standards track ;) From turners@ieca.com Mon Jul 8 07:36:49 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFDBF21F9B9D for ; Mon, 8 Jul 2013 07:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.433 X-Spam-Level: X-Spam-Status: No, score=-102.433 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 84LrNq+yrRxK for ; Mon, 8 Jul 2013 07:36:43 -0700 (PDT) Received: from gateway01.websitewelcome.com (gateway01.websitewelcome.com [69.56.212.19]) by ietfa.amsl.com (Postfix) with ESMTP id 905E121F9B16 for ; Mon, 8 Jul 2013 07:36:43 -0700 (PDT) Received: by gateway01.websitewelcome.com (Postfix, from userid 5007) id 6FCF562DFC83C; Mon, 8 Jul 2013 09:36:42 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway01.websitewelcome.com (Postfix) with ESMTP id 57FBF62DFC7B6 for ; Mon, 8 Jul 2013 09:36:42 -0500 (CDT) Received: from [74.96.0.204] (port=49519 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UwCYR-0003co-2O; Mon, 08 Jul 2013 09:36:39 -0500 Message-ID: <51DACE76.1000705@ieca.com> Date: Mon, 08 Jul 2013 10:36:38 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Barry Leiba References: <20130516062941.27229.92525.idtracker@ietfa.amsl.com> <519BC621.4070403@ieca.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [74.96.0.204]:49519 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: "draft-ietf-core-coap@tools.ietf.org" , "core-chairs@tools.ietf.org" , The IESG , "core@ietf.org" Subject: Re: [core] Sean Turner's Discuss on draft-ietf-core-coap-16: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 14:36:49 -0000 I have changed my ballot position to yes. You're cleared for launch! Thanks for addressing all my issues! spt On 7/1/13 10:00 AM, Barry Leiba wrote: > Sean, you're the one who's left: will you check the -18 version and see > if you're OK with it? > > Other ADs, please also have a look at -18 in light of your non-blocking > comments, and let us know if there are any important points that you'd > like to ask for another look at. > > Handy link: https://datatracker.ietf.org/doc/draft-ietf-core-coap/ > > Thanks, > Barry From ietf-secretariat-reply@ietf.org Mon Jul 8 07:45:00 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02B8821F9CE3 for ; Mon, 8 Jul 2013 07:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id amTrGivwIx-F; Mon, 8 Jul 2013 07:44:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 676F921F9CE1; Mon, 8 Jul 2013 07:44:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: core-chairs@tools.ietf.org, draft-ietf-core-coap@tools.ietf.org, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130708144459.30155.73497.idtracker@ietfa.amsl.com> Date: Mon, 08 Jul 2013 07:44:59 -0700 From: IETF Secretariat Subject: [core] ID Tracker State Update Notice: X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 14:45:00 -0000 State changed to IESG Evaluation from IESG Evaluation - Defer::AD Followup ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-core-coap/ From esko.dijk@philips.com Mon Jul 8 08:08:04 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93EBD21F9DA0 for ; Mon, 8 Jul 2013 08:08:04 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8if52rKVEnZj for ; Mon, 8 Jul 2013 08:07:58 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id 2E08621F9DA2 for ; Mon, 8 Jul 2013 08:07:58 -0700 (PDT) Received: from mail189-ch1-R.bigfish.com (10.43.68.249) by CH1EHSOBE007.bigfish.com (10.43.70.57) with Microsoft SMTP Server id 14.1.225.22; Mon, 8 Jul 2013 15:07:56 +0000 Received: from mail189-ch1 (localhost [127.0.0.1]) by mail189-ch1-R.bigfish.com (Postfix) with ESMTP id B689D440109; Mon, 8 Jul 2013 15:07:56 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -6 X-BigFish: VPS-6(zz15d6O9251I217bIdd85kzz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzzz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1155h) Received: from mail189-ch1 (localhost.localdomain [127.0.0.1]) by mail189-ch1 (MessageSwitch) id 1373296075446666_4187; Mon, 8 Jul 2013 15:07:55 +0000 (UTC) Received: from CH1EHSMHS035.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.230]) by mail189-ch1.bigfish.com (Postfix) with ESMTP id 697ED60053; Mon, 8 Jul 2013 15:07:55 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CH1EHSMHS035.bigfish.com (10.43.70.35) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 8 Jul 2013 15:07:53 +0000 Received: from 011-DB3MMR1-016.MGDPHG.emi.philips.com (10.128.28.100) by 011-DB3MMR1-008.MGDPHG.emi.philips.com (10.128.28.47) with Microsoft SMTP Server (TLS) id 14.3.136.1; Mon, 8 Jul 2013 15:07:00 +0000 Received: from 011-DB3MPN2-083.MGDPHG.emi.philips.com ([169.254.3.190]) by 011-DB3MMR1-016.MGDPHG.emi.philips.com ([10.128.28.100]) with mapi id 14.03.0136.001; Mon, 8 Jul 2013 15:07:51 +0000 From: "Dijk, Esko" To: Carsten Bormann , "trac+core@grenache.tools.ietf.org" Thread-Topic: [core] #332: Remove advice for use of blockwise on "/.well-known/core" ? Thread-Index: AQHOe9FJPfWauOjAAkeqVdWhuxCqAZlatsiAgAAox2A= Date: Mon, 8 Jul 2013 15:07:51 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618C9A3C4@011-DB3MPN2-083.MGDPHG.emi.philips.com> References: <060.ecb6d7b2bd30e58cb7593a44933af6ca@trac.tools.ietf.org> <768D84B8-E67D-4D2A-B005-C93F56B8FF56@tzi.org> In-Reply-To: <768D84B8-E67D-4D2A-B005-C93F56B8FF56@tzi.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [83.83.116.101] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: "draft-ietf-core-groupcomm@tools.ietf.org" , "core@ietf.org" Subject: Re: [core] #332: Remove advice for use of blockwise on "/.well-known/core" ? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 15:08:04 -0000 > because clients that want to make use of /.well-known/core should do core= -block (whether they use multicast or not). That is a possible solution indeed, but then this requirement has to be rec= orded somewhere in core-coap isn't it? (Or should that be in RFC 6690? Or c= ore-groupcomm -> but that is informational so does not solve it.) Otherwise many implementers will do the 'unwise thing' and interoperabilit= y suffers. And secondly, core-block will have to be updated (I would expect) with a de= scription on how to use it together with IP multicast. That does not have t= o be defined for all use cases, only for the use case of multicast GET for = a resource where some servers decide to return only the first block. Or may= be this explanation can go into core-groupcomm? regards, Esko ________________________________ 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 cabo@tzi.org Mon Jul 8 11:02:14 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24BD621F9C0B for ; Mon, 8 Jul 2013 11:02:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.182 X-Spam-Level: X-Spam-Status: No, score=-106.182 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jY6y3bikzzwc for ; Mon, 8 Jul 2013 11:02:08 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 05B2121F9ADE for ; Mon, 8 Jul 2013 11:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r68I234p007324; Mon, 8 Jul 2013 20:02:03 +0200 (CEST) Received: from [192.168.217.105] (p54894869.dip0.t-ipconnect.de [84.137.72.105]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id BF2A43CDA; Mon, 8 Jul 2013 20:02:02 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <031DD135F9160444ABBE3B0C36CED618C9A3C4@011-DB3MPN2-083.MGDPHG.emi.philips.com> Date: Mon, 8 Jul 2013 20:02:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5C63ACF7-11C5-4703-919A-824028BA4BC5@tzi.org> References: <060.ecb6d7b2bd30e58cb7593a44933af6ca@trac.tools.ietf.org> <768D84B8-E67D-4D2A-B005-C93F56B8FF56@tzi.org> <031DD135F9160444ABBE3B0C36CED618C9A3C4@011-DB3MPN2-083.MGDPHG.emi.philips.com> To: "Dijk, Esko" X-Mailer: Apple Mail (2.1508) Cc: "trac+core@grenache.tools.ietf.org" , "draft-ietf-core-groupcomm@tools.ietf.org" , "core@ietf.org" Subject: Re: [core] #332: Remove advice for use of blockwise on "/.well-known/core" ? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 18:02:14 -0000 On Jul 8, 2013, at 17:07, "Dijk, Esko" wrote: >> because clients that want to make use of /.well-known/core should do = core-block (whether they use multicast or not). > That is a possible solution indeed, but then this requirement has to = be recorded somewhere in core-coap isn't it? Well, it is not a protocol requirement, it is just a real-world = requirement. If it doesn't fit, you have to do something. core-coap does mention "... move to block-wise transfers [I-D.ietf-core-block] when approaching three- digit message sizes." > (Or should that be in RFC 6690? RFC 6690 is pretty much oblivious to how the information is transported. (It does actually mention multicast, though.) > Or core-groupcomm -> but that is informational so does not solve it.) groupcomm mentioning it is exactly the right thing, I'd say. > Otherwise many implementers will do the 'unwise thing' and = interoperability suffers. In interops so far, few implementations have had problems with this = (with unicast, though). (I expect the "culture" of using CoAP to be set in interops as much as = by the standard.) > And secondly, core-block will have to be updated (I would expect) with = a description on how to use it together with IP multicast. That does not = have to be defined for all use cases, only for the use case of multicast = GET for a resource where some servers decide to return only the first = block. Good point. -block is currently mute about continuing forward using unicast requests = from a response to a multicast request. > Or maybe this explanation can go into core-groupcomm? Possibly as well. Gr=FC=DFe, Carsten From denglingli@gmail.com Mon Jul 8 23:36:34 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E804921F9EEE for ; Mon, 8 Jul 2013 23:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.074 X-Spam-Level: * X-Spam-Status: No, score=1.074 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2S+M7X6Kdt2 for ; Mon, 8 Jul 2013 23:36:33 -0700 (PDT) Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id B3B9F21F9829 for ; Mon, 8 Jul 2013 23:36:32 -0700 (PDT) Received: by mail-vc0-f181.google.com with SMTP id lf11so3944187vcb.26 for ; Mon, 08 Jul 2013 23:36:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dHCHpOgsEJQmNsyt7M6rASNSHC6M5LJ3w881m+7fM7Y=; b=A3hlIExL/V6k27QzkxlTCT06bTeabeeS5U4GZtQYuLu6xC7p1cuAv8jdiaxMyuwEXa kAOvdI7sZ4M1UL6GxKenLcb8BRq0n7OLY0wOrbdcZryKInqT3/RAGPpVCEE5xbTP+Z9F i1sgUJu7cxXtw/OOxBjg+P/eUDhqJ1NrAJyW87cO053ZqES4etyMV7epxPNoY2xWfLf4 z10AXYhbPdJa+LZMmJxIHZE4Kw3CmTDKQrvqfAWFKNSo3PgTi3q6QxGHLy5C405Imldg hO88g+gL3KccII9NBh+iOrLXV5xpfvWhuPldmTy9sZOu2++om+T00J7VGr1R3YQGSUQ5 nl2w== MIME-Version: 1.0 X-Received: by 10.220.123.195 with SMTP id q3mr15335369vcr.64.1373351791052; Mon, 08 Jul 2013 23:36:31 -0700 (PDT) Received: by 10.58.18.240 with HTTP; Mon, 8 Jul 2013 23:36:30 -0700 (PDT) In-Reply-To: References: <002b01ce7713$2073b160$615b1420$@com> Date: Tue, 9 Jul 2013 14:36:30 +0800 Message-ID: From: lingli deng To: qiminpeng Content-Type: multipart/mixed; boundary=089e013cb728a84dc704e10e61ba Cc: core@ietf.org Subject: [core] Fwd: FW: New Version Notification for draft-zhu-core-groupauth-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 06:36:35 -0000 --089e013cb728a84dc704e10e61ba Content-Type: multipart/alternative; boundary=089e013cb728a84dc304e10e61b8 --089e013cb728a84dc304e10e61b8 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi Minpeng, I think you have raised an interesting question on how to do nodes' authentication efficiently. Good way to go! However, as a security layman, it is a little troublesome for me to understand your proposal's advantages over the current two-layer solution you mentioned in the first part of the draft. In particulr, I have the following questions: 1) In terms of the proposed group authentication scheme, is the group agent assumed to be trustworthy? 2) Is it fair to say that the group agent is comparable to the agent in the current two-layer soluton? 3) How can one conclude that the proposal is a better solution in face of "a untrustworthy agent" as described in the requirement statement section? BR Lingli > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: core-bounces@ietf.org [mailto:core-bounces@ietf.org] = =B4=FA=B1=ED =C6=EB=95F=C5=F4 > =B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA6=D4=C224=C8=D5 11:10 > =CA=D5=BC=FE=C8=CB: core@ietf.org > =D6=F7=CC=E2: [core] FW: New Version Notification for draft-zhu-core-grou= pauth-00.txt > > Hi everyone, > > The authors have submit a new draft for the group authentication. We will > appreciate if you have a look and give us any comment or suggestion. The > link is as below. > > Here is a problem that for group communication there is only uni-cast > authentication instead of group authentication method can be used. This > draft wants to analyze the problem, to summarize group authentication > requirement and to provide a framework of solutions. > > BRs, > Minpeng > > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: internet-drafts@ietf.org [mailto:internet-drafts@ietf= .org] > =B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA6=D4=C224=C8=D5 10:19 > =CA=D5=BC=FE=C8=CB: Ye Tian; Minpeng Qi; Judy Zhu > =D6=F7=CC=E2: New Version Notification for draft-zhu-core-groupauth-00.tx= t > > > A new version of I-D, draft-zhu-core-groupauth-00.txt > has been successfully submitted by Judy Zhu and posted to the > IETF repository. > > Filename: draft-zhu-core-groupauth > Revision: 00 > Title: Group Authentication > Creation date: 2013-06-24 > Group: Individual Submission > Number of pages: 10 > URL: > http://www.ietf.org/internet-drafts/draft-zhu-core-groupauth-00.txt > Status: http://datatracker.ietf.org/doc/draft-zhu-core-groupauth > Htmlized: http://tools.ietf.org/html/draft-zhu-core-groupauth-00 > > > Abstract: > The group communication is designed for the communication of Internet > of Things. A threat is identified in [I-D.ietf-core-groupcomm] that > current DTLS based approach is unicast oriented and there is no > supporting on group authentication feature. Unicast oriented > authentication will causing serious burden when a large number of > terminal nodes will be involved inevitably. In another aspect, some > terminals will own the same characteristics, such as owning same > features, in the same place, working in the same time, etc. With this > mechanism, all terminals can be authenticated together with little > signaling and calculation at the same time. It will reduce the > network burden and save time. This draft describes the security of > group authentication and an group authentication implementation > method for the Internet of things. > > > > > The IETF Secretariat > > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --089e013cb728a84dc304e10e61b8 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
Hi Minpeng,
 
I think you have raised an interesting question on how= to do nodes' authentication efficiently. Good way to go!
 
However, = as a security layman, it is a little troublesome for me to understand = your proposal's advantages over the current two-layer solution you ment= ioned in the first part of the draft.
 
In partic= ulr, I have the following questions:
 =
1) In terms of the proposed group authenti= cation scheme, is the group agent assumed to be trustworthy?
 
2) Is it = fair to say that the group agent is comparable to the agent in the current = two-layer soluton?
 
3) How can one conclude that the proposal is a better solution in face of &= quot;a untrustworthy agent" as described in the requirement statement = section?
 
 
BR
Lingli

 

-----=D3=CA=BC=FE=D4=AD=BC=FE-----
=B7=A2=BC=FE=C8=CB: core-bounces@ietf.org [mailto:core-bounces@ietf.org] =B4=FA=B1=ED =C6=EB=95F=C5= =F4
=B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA6=D4=C224=C8=D5 11:10
=CA=D5=BC=FE=C8=CB: core= @ietf.org
=D6=F7=CC=E2: [core] FW: New Version Notification for draft-zhu-core-groupa= uth-00.txt

Hi everyone,

The authors have submit a new draft for the group authentication. We will a= ppreciate if you have a look and give us any comment or suggestion. The lin= k is as below.

Here is a problem that for group communication there is only uni-cast authe= ntication instead of group authentication method can be used. This draft wa= nts to analyze the problem, to summarize group authentication requirement a= nd to provide a framework of solutions.

BRs,
Minpeng

-----=D3=CA=BC=FE=D4=AD=BC=FE-----
=B7=A2=BC=FE=C8=CB: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
=B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA6=D4=C224=C8=D5 10:19
=CA=D5=BC=FE=C8=CB: Ye Tian; Minpeng Qi; Judy Zhu
=D6=F7=CC=E2: New Version Notification for draft-zhu-core-groupauth-00.txt<= br>

A new version of I-D, draft-zhu-core-groupauth-00.txt
has been successfully submitted by Judy Zhu and posted to the
IETF repository.

Filename:        draft-zhu-core-groupauth
Revision:        00
Title:           Group Authentication
Creation date:   2013-06-24
Group:           Individual Submission
Number of pages: 10
URL:             http:= //www.ietf.org/internet-drafts/draft-zhu-core-groupauth-00.txt
Status:          http://datatracker.ie= tf.org/doc/draft-zhu-core-groupauth
Htmlized:        http://tools.ietf.org/html/d= raft-zhu-core-groupauth-00


Abstract:
   The group communication is designed for the communication of I= nternet
   of Things. A threat is identified in [I-D.ietf-core-groupcomm]= that
   current DTLS based approach is unicast oriented and there is n= o
   supporting on group authentication feature. Unicast oriented    authentication will causing serious burden when a large number= of
   terminal nodes will be involved inevitably. In another aspect,= some
   terminals will own the same characteristics, such as owning sa= me
   features, in the same place, working in the same time, etc. Wi= th this
   mechanism, all terminals can be authenticated together with li= ttle
   signaling and calculation at the same time. It will reduce the=
   network burden and save time. This draft describes the securit= y of
   group authentication and an group authentication implementatio= n
   method for the Internet of things.




The IETF Secretariat




_______________________________________________
core mailing list
core@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/core
--089e013cb728a84dc304e10e61b8-- --089e013cb728a84dc704e10e61ba Content-Type: text/plain; charset=US-ASCII; name="draft-zhu-core-groupauth-00.txt" Content-Disposition: attachment; filename="draft-zhu-core-groupauth-00.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: b44f0ab63ae9e509_0.1 Q29yZSBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBKLiBaaHUNCkludGVybmV0IERyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIE0uIFFpDQpJbnRlbmRlZCBzdGF0dXM6IEluZm9ybWF0 aW9uYWwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgWS4gVGlhbg0KRXhwaXJlczpE ZWNlbWJlciAyNCwgMjAxMyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBDaGluYSBN b2JpbGUNCgkJICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEp1biAy NCwgMjAxMw0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgR3JvdXAgQXV0aGVudGljYXRp b24NCiAgICAgICAgICAgICAgICAgICAgICBkcmFmdC16aHUtY29yZS1ncm91cGF1dGgtMDANCg0K QWJzdHJhY3QNCiAgIFRoZSBncm91cCBjb21tdW5pY2F0aW9uIGlzIGRlc2lnbmVkIGZvciB0aGUg Y29tbXVuaWNhdGlvbiBvZiBJbnRlcm5ldA0KICAgb2YgVGhpbmdzLiBBIHRocmVhdCBpcyBpZGVu dGlmaWVkIGluIFtJLUQuaWV0Zi1jb3JlLWdyb3VwY29tbV0gdGhhdCANCiAgIGN1cnJlbnQgRFRM UyBiYXNlZCBhcHByb2FjaCBpcyB1bmljYXN0IG9yaWVudGVkIGFuZCB0aGVyZSBpcyBubyANCiAg IHN1cHBvcnRpbmcgb24gZ3JvdXAgYXV0aGVudGljYXRpb24gZmVhdHVyZS4gVW5pY2FzdCBvcmll bnRlZCANCiAgIGF1dGhlbnRpY2F0aW9uIHdpbGwgY2F1c2luZyBzZXJpb3VzIGJ1cmRlbiB3aGVu IGEgbGFyZ2UgbnVtYmVyIG9mIA0KICAgdGVybWluYWwgbm9kZXMgd2lsbCBiZSBpbnZvbHZlZCBp bmV2aXRhYmx5LiBJbiBhbm90aGVyIGFzcGVjdCwgc29tZSANCiAgIHRlcm1pbmFscyB3aWxsIG93 biB0aGUgc2FtZSBjaGFyYWN0ZXJpc3RpY3MsIHN1Y2ggYXMgb3duaW5nIHNhbWUgDQogICBmZWF0 dXJlcywgaW4gdGhlIHNhbWUgcGxhY2UsIHdvcmtpbmcgaW4gdGhlIHNhbWUgdGltZSwgZXRjLiBX aXRoIHRoaXMgDQogICBtZWNoYW5pc20sIGFsbCB0ZXJtaW5hbHMgY2FuIGJlIGF1dGhlbnRpY2F0 ZWQgdG9nZXRoZXIgd2l0aCBsaXR0bGUgDQogICBzaWduYWxpbmcgYW5kIGNhbGN1bGF0aW9uIGF0 IHRoZSBzYW1lIHRpbWUuIEl0IHdpbGwgcmVkdWNlIHRoZSANCiAgIG5ldHdvcmsgYnVyZGVuIGFu ZCBzYXZlIHRpbWUuIFRoaXMgZHJhZnQgZGVzY3JpYmVzIHRoZSBzZWN1cml0eSBvZiANCiAgIGdy b3VwIGF1dGhlbnRpY2F0aW9uIGFuZCBhbiBncm91cCBhdXRoZW50aWNhdGlvbiBpbXBsZW1lbnRh dGlvbiANCiAgIG1ldGhvZCBmb3IgdGhlIEludGVybmV0IG9mIHRoaW5ncy4NCg0KU3RhdHVzIG9m IHRoaXMgTWVtbw0KICAgVGhpcyBJbnRlcm5ldC1EcmFmdCBpcyBzdWJtaXR0ZWQgaW4gZnVsbCBj b25mb3JtYW5jZSB3aXRoIHRoZSANCiAgIHByb3Zpc2lvbnMgb2YgQkNQIDc4IGFuZCBCQ1AgNzku DQoNCiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVy bmV0IEVuZ2luZWVyaW5nDQogICBUYXNrIEZvcmNlIChJRVRGKSwgaXRzIGFyZWFzLCBhbmQgaXRz IHdvcmtpbmcgZ3JvdXBzLiAgTm90ZSB0aGF0DQogICBvdGhlciBncm91cHMgbWF5IGFsc28gZGlz dHJpYnV0ZSB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC0NCiAgIERyYWZ0cy4NCg0KICAg SW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBv ZiBzaXggbW9udGhzDQogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0 ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQ0KICAgdGltZS4gIEl0IGlzIGluYXBwcm9wcmlh dGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UNCiAgIG1hdGVyaWFsIG9yIHRv IGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiINCg0KICAgVGhlIGxp c3Qgb2YgY3VycmVudCBJbnRlcm5ldC1EcmFmdHMgY2FuIGJlIGFjY2Vzc2VkIGF0DQogICBodHRw Oi8vd3d3LmlldGYub3JnL2lldGYvMWlkLWFic3RyYWN0cy50eHQNCg0KDQpKdWR5ICAgICAgICAg ICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMjQsIDIwMTMgICAgICAgICAgICAgICAgICAgW1BhZ2Ug MV0NCg0KSW50ZXJuZXQtRHJhZnQgICAgICAgICBHcm91cCBBdXRoZW50aWNhdGlvbiAgICAgICAg ICAgICAgICAgICAgIEp1biAyMDEzDQoNCiAgIFRoZSBsaXN0IG9mIEludGVybmV0LURyYWZ0IFNo YWRvdyBEaXJlY3RvcmllcyBjYW4gYmUgYWNjZXNzZWQgYXQNCiAgIGh0dHA6Ly93d3cuaWV0Zi5v cmcvc2hhZG93Lmh0bWwNCg0KICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBE ZWNlbWJlciAyNCwgMjAxMy4NCg0KQ29weXJpZ2h0IE5vdGljZQ0KICAgQ29weXJpZ2h0IChjKSAy MDEzIElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMgdGhlIA0KICAgZG9j dW1lbnQgYXV0aG9ycy4gQWxsIHJpZ2h0cyByZXNlcnZlZC4NCiAgIA0KICAgVGhpcyBkb2N1bWVu dCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQgdGhlIElFVEYgVHJ1c3QncyBMZWdhbCBQcm92aXNp b25zDQogICBSZWxhdGluZyB0byBJRVRGIERvY3VtZW50cyAoaHR0cDovL3RydXN0ZWUuaWV0Zi5v cmcvbGljZW5zZS1pbmZvKSANCiAgIGluIGVmZmVjdCBvbiB0aGUgZGF0ZSBvZiBwdWJsaWNhdGlv biBvZiB0aGlzIGRvY3VtZW50LiAgUGxlYXNlDQogICByZXZpZXcgdGhlc2UgZG9jdW1lbnRzIGNh cmVmdWxseSwgYXMgdGhleSBkZXNjcmliZSB5b3VyIHJpZ2h0cyANCiAgIGFuZCByZXN0cmljdGlv bnMgd2l0aCByZXNwZWN0IHRvIHRoaXMgZG9jdW1lbnQuIA0KICAgDQpUYWJsZSBvZiBDb250ZW50 cw0KDQogICAxLiBJbnRyb2R1Y3Rpb24gLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLjINCiAgIDIuIENvbnZlbnRpb25zIHVzZWQgaW4gdGhpcyBkb2N1 bWVudCAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMw0KICAgMy4gUHJvYmxlbSBTdGF0 ZW1lbnQgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4zDQog ICAzLjEuIFVzZSBjYXNlcyAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLjMNCiAgIDMuMi4gUHJvYmxlbSBzdGF0ZW1lbnQgLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNA0KICAgNC4gUmVxdWlyZW1lbnQgLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi41DQogICA1LiBH cm91cCBBdXRoZW50aWNhdGlvbiBTb2x1dGlvbiAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLjYNCiAgIDUuMS4gSW50cm9kdWN0aW9uIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNg0KICAgNS4yLiBEZXRhaWxlZCBncm91cCBzY2VuYXJp byBkZXNjcmlwdGlvbiAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi42DQogICA1LjMuIEdyb3Vw IHNjZW5hcmlvIHByb2NlZHVyZSAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u LjgNCiAgIDYuIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uOQ0KICAgNy4gSUFOQSBDb25zaWRlcmF0aW9ucyAuLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi45DQogICA4LiBDb25jbHVzaW9ucyAu Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTANCiAg IDkuIFJlZmVyZW5jZXMgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4xMA0KICAgOS4xLiBOb3JtYXRpdmUgUmVmZXJlbmNlcyAuLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjEwDQogICA5LjIuIEluZm9ybWF0aXZlIFJlZmVy ZW5jZXMgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTANCg0KMS4gSW50 cm9kdWN0aW9uDQoNCiAgIFdpdGggdGhlIGRldmVsb3BtZW50IG9mIEludGVybmV0IG9mIFRoaW5n cywgYSBsYXJnZSBudW1iZXIgb2YgDQogICB0ZXJtaW5hbCBub2RlcyB3aWxsIGJlIGludm9sdmVk IGluZXZpdGFibHkuIFRoZSB1bmljYXN0IA0KICAgYXV0aGVudGljYXRpb24gY29tbXVuaWNhdGlv biBmcm9tIGJpZyBhbW91bnQgdGVybWluYWxzIHdpbGwgbWVyZ2UgDQogICB0b2dldGhlciBpbiB0 aGUgbmV0d29yaywgYW5kIGNhdXNpbmcgc2VyaW91cyBidXJkZW4gdG8gdGhlIHNlcnZlci4gDQog ICBBbHRob3VnaCBJUCBtdWx0aWNhc3QgdGVjaG5pY2FsIGlzIGludHJvZHVjZWQgZm9yIGdyb3Vw IGNvbW11bmljYXRpb24gDQogICBpbiBbSS1ELmlldGYtY29yZS1ncm91cGNvbW1dLCBJUCBtdWx0 aWNhc3QgcmVsaWVzIG9uIHRoZSB1bmljYXN0IA0KICAgYXV0aGVudGljYXRpb24gYXQgaW5pdGlh bCBzdGFnZS4gSW4gYW5vdGhlciBhc3BlY3QsIHNvbWUgdGVybWluYWxzIA0KICAgd2lsbCBvd24g dGhlIHNhbWUgY2hhcmFjdGVyaXN0aWNzLCBzdWNoIGFzIG93bmluZyBzYW1lIGZlYXR1cmVzLCBp biANCg0KDQpKdWR5ICAgICAgICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMjQsIDIwMTMgICAg ICAgICAgICAgICAgICAgW1BhZ2UgMl0NCg0KSW50ZXJuZXQtRHJhZnQgICAgICAgICBHcm91cCBB dXRoZW50aWNhdGlvbiAgICAgICAgICAgICAgICAgICAgIE1heSAyMDEzDQoNCiAgIHRoZSBzYW1l IHBsYWNlLCB3b3JraW5nIGluIHRoZSBzYW1lIHRpbWUsIGV0Yy4gV2l0aCB0aGlzIG1lY2hhbmlz bSwgDQogICBhbGwgdGVybWluYWxzIGNhbiBiZSBhdXRoZW50aWNhdGVkIHdpdGggbGl0dGxlIHNp Z25hbGluZyBhbmQgDQogICBjYWxjdWxhdGlvbiBhdCB0aGUgc2FtZSB0aW1lLiBJdCB3aWxsIHJl ZHVjZSB0aGUgbmV0d29yayBidXJkZW4gYW5kIA0KICAgc2F2ZSB0aW1lLiANCg0KICAgVGhpcyBk cmFmdCBkZXNjcmliZXMgdGhlIHNlY3VyaXR5IG9mIGdyb3VwIGF1dGhlbnRpY2F0aW9uIGFuZCBh biANCiAgIGdyb3VwIGF1dGhlbnRpY2F0aW9uIGltcGxlbWVudGF0aW9uIG1ldGhvZCBmb3IgdGhl IEludGVybmV0IG9mIHRoaW5ncy4NCg0KMi4gQ29udmVudGlvbnMgdXNlZCBpbiB0aGlzIGRvY3Vt ZW50DQoNCiAgIFRoZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAi U0hBTEwiLCAiU0hBTEwgTk9UIiwgDQogICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01N RU5ERUQiLCAiTUFZIiwgYW5kICJPUFRJT05BTCIgaW4gdGhpcyANCiAgIGRvY3VtZW50IGFyZSB0 byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gUkZDLTIxMTkgW1JGQzIxMTldLiANCg0K ICAgSW4gdGhpcyBkb2N1bWVudCwgdGhlc2Ugd29yZHMgd2lsbCBhcHBlYXIgd2l0aCB0aGF0IGlu dGVycHJldGF0aW9uICAgDQogICBvbmx5IHdoZW4gaW4gQUxMIENBUFMuIExvd2VyIGNhc2UgdXNl cyBvZiB0aGVzZSB3b3JkcyBhcmUgbm90IHRvIGJlICAgIA0KICAgaW50ZXJwcmV0ZWQgYXMgY2Fy cnlpbmcgUkZDLTIxMTkgc2lnbmlmaWNhbmNlLg0KDQozLiBQcm9ibGVtIFN0YXRlbWVudA0KDQoz LjEuIFVzZSBjYXNlcw0KICAgTm93YWRheXMgdGhlIG5vcm1hbCBhdXRoZW50aWNhdGlvbiBtZWNo YW5pc20gaW4gbmV0d29yayBpcyBhIA0KICAgdHJhZGl0aW9uYWwgdW5pY2FzdCBhdXRoZW50aWNh dGlvbiBtZXRob2QgYmV0d2VlbiBhIHNpbmdsZSB0ZXJtaW5hbCANCiAgIGFuZCBhIHNpbmdsZSBu ZXR3b3JrIGVudGl0eS4gVGhlIGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbSB3aWxsIGJlIA0KICAg ZmluaXNoZWQgYmFzZWQgb25lIDEtMiByb3VuZCBvZiBjaGFsbGVuZ2UtcmVzcG9uc2UgY29udmVy c2F0aW9uLiBCdXQgDQogICBmb3Igc29tZSBNMk0gc2VydmljZSwgaXQgbWF5IGJlIGEgbGFyZ2Ug YW1vdW50IG9mIHRlcm1pbmFsIHVzZWQgZm9yIA0KICAgYW4gTTJNIHNlcnZpY2UuIFRoZXNlIHRl cm1pbmFscyBhcmUgcGxhY2VkIGluIHRoZSBzYW1lIGxvY2F0aW9uLCB3aWxsIA0KICAgYmUgdXNl ZCBmb3IgdGhlIHNhbWUgcHVycG9zZSwgYW5kIG93biBzYW1lIGJlaGF2aW9yLiBUaGVzZSB0ZXJt aW5hbHMgDQogICBjYW4gYmUgd29ya2VkIHRvZ2V0aGVyIGFzIGEgZ3JvdXAuIA0KDQogICBJbiB0 aGVzZSBzY2VuYXJpb3MsIHRoZSBleGlzdGluZyBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc20gaXMg bm8gDQogICBsb25nZXIgYXBwcm9wcmlhdGUuIFdoZW4gYSBsYXJnZSBudW1iZXIgb2YgdGVybWlu YWxzIHdhbnQgdG8gYWNjZXNzIA0KICAgbmV0d29yayBzZXJ2ZXIsIGh1Z2UgbnVtYmVyIG9mIGF1 dGhlbnRpY2F0aW9uIHNpZ25hbGluZyB3aWxsIGJlIA0KICAgZ2VuZXJhdGVkIGJ5IHRoZSB1bmlj YXN0IGF1dGhlbnRpY2F0aW9uIG1ldGhvZC4gV2hhdCBpcyBtb3JlLCBpdCB3aWxsIA0KICAgY2F1 c2UgbmV0d29yayBjb25nZXN0aW9uIGFuZCBsZWFkIHRvIERvUyBhdHRhY2suIEZvciBzb21lIHRl cm1pbmFsIA0KICAgZGV2aWNlcyB3aGljaCBpcyByZXN0cmljdGVkIHdpdGggbGltaXRlZCBjb21w dXRpbmcgY2FwYWJpbGl0eSBhbmQgDQogICBwb3dlciwgdGhlIHRyYWRpdGlvbmFsIHVuaWNhc3Qg YXV0aGVudGljYXRpb24gd2lsbCBpbmNyZWFzZSB0aGUgDQogICBjb21wdXRhdGlvbmFsIGJ1cmRl biBvZiB0aGVzZSB0ZXJtaW5hbHMgYW5kIGRyYWluIHRoZWlyIHBvb3IgYmF0dGVyeS4NCg0KICAg VGhlIGZvbGxvd2luZyB1c2UgY2FzZXMgYXJlIGlkZW50aWZpZWQgYXQgdGhpcyBwb2ludDoNCg0K DQpKdWR5ICAgICAgICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMjQsIDIwMTMgICAgICAgICAg ICAgICAgICAgW1BhZ2UgM10NCg0KSW50ZXJuZXQtRHJhZnQgICAgICAgICBHcm91cCBBdXRoZW50 aWNhdGlvbiAgICAgICAgICAgICAgICAgICAgIE1heSAyMDEzDQoNCiAgIFNtYXJ0IE1ldGVyaW5n OiBTbWFydCBtZXRlciBpbiBhIGJsb2NrIHdpbGwgdXBsb2FkIG1ldGVyIG51bWJlciANCiAgIHJl cG9ydCBhdCB0aGUgc2FtZSB0aW1lLCBvciB0aGUgc21hcnQgbWV0ZXIgc2VydmVyIG5lZWQgdG8g cmUtDQogICBjb25maWd1cmUgYWxsIHNtYXJ0IG1ldGVycyBhdCB0aGUgc2FtZSB0aW1lLg0KDQog ICBSZW1vdGUgVmVoaWNsZSBNYW5hZ2VtZW50OiBTb21lIHNwZWNpYWwgVmVoaWNsZXMgc3VjaCBh cyBUYXhpIHdpbGwgDQogICBnYXRoZXIgaW4gYSBzbWFsbCBwbGFjZSBsaWtlIGFpcnBvcnQsIHRy YWluIHN0YXRpb24sIGV0Yy4gDQoNCiAgIEludGVsbGlnZW50IGhvbWU6IHZhcmlvdXMgc2Vuc29y cyBlcXVpcHBlZCB3aXRoIGNvbW11bmljYXRpb24gbW9kdWxlcyANCiAgIGFyZSBkZXBsb3llZCBp biBhIGhvdXNlIHRvIG1vbml0b3IgaG91c2UgY29uZGl0aW9ucyBhbmQgbWFrZSBhIA0KICAgY29u dHJvbCB3aGVuIG5lY2Vzc2FyeS4gVGhlc2Ugc2Vuc29ycyBjb2xsZWN0IGFuZCByZXBvcnQgaG91 c2UgDQogICByZWxhdGVkIGluZm9ybWF0aW9uIHRvIGl0cyBvd25lciB0aHJvdWdoIGEgbmV0d29y aywgYW5kIHRha2UgYWN0aW9ucyANCiAgIGJ5IGZvbGxvd2luZyB0aGUgcmVndWxhdGluZyBpbnN0 cnVjdGlvbnMgc2VuZCBieSB0aGUgb3duZXIuDQoNCjMuMi4gUHJvYmxlbSBzdGF0ZW1lbnQNCg0K ICAgSW4gdGhlIGN1cnJlbnQgc21hcnQgbWV0ZXJpbmcgc2VydmljZSB1c2UgY2FzZXMsIGEgbGFy Z2UgYW1vdW50IG9mIA0KICAgc21hcnQgcG93ZXIgbWV0ZXIgdGVybWluYWxzIGFyZSBkZXBsb3ll ZCBpbiBhIGJsb2NrLiBUaGUgc21hcnQgbWV0ZXIgDQogICB1cGxvYWRzIG1ldGVyIHJlcG9ydCBm cmVxdWVudGx5IHRocm91Z2ggdGhlIG5ldHdvcmsgdG8gc21hcnQgbWV0ZXIgDQogICBzZXJ2ZXIu IFdoYXQgaXMgbW9yZSwgc21hcnQgbWV0ZXIgc2VydmVyIHF1ZXJpZXMgYWxsIHRlcm1pbmFscyAN CiAgIHBlcmlvZGljYWxseSB0byBjaGVjayB3aGV0aGVyIHRoZSB0ZXJtaW5hbCBpcyB3b3JrYWJs ZSBvciBub3QuIA0KICAgVGhlcmVmb3JlLCB0aGUgbWV0ZXIgcmVxdWlyZXMgZnJlcXVlbnQgYW5k IG5ldHdvcmsgY29tbXVuaWNhdGlvbi4NCg0KICAgSW4gc3VjaCB1c2UgY2FzZXMsIHdoZW4gYWxs IHRoZSBtZXRlcnMgYWNjZXNzIG5ldHdvcmsgcGFyYWxsZWwgYXQgdGhlIA0KICAgc2FtZSB0aW1l LCBvciB3aGVuIHRoZSBzZXJ2ZXIgc2VuZHMgbWVzc2FnZSB0byBhbGwgbWV0ZXJzLCB0aGUgDQog ICB0ZXJtaW5hbHMgd2lsbCBjb25uZWN0IHRvIHRoZSBuZXR3b3JrIGluIGEgc2hvcnQgdGltZSBw ZXJpb2QgKDFzZWMgfiANCiAgIDFtaW4pLiBBc3N1bWUgdGhlcmUgYXJlIDE5IGJ1aWxkaW5ncyBp biB0aGUgYmxvY2ssIGFuZCBlYWNoIGJ1aWxkaW5nIA0KICAgaGFzIDI1IGZsb29ycyBvbiBhdmVy YWdlIHdpdGggMTAgYXBhcnRtZW50cyBpbiBlYWNoIGZsb29yLiBJZiBlYWNoIA0KICAgYXBhcnRt ZW50IGlzIGVxdWlwcGVkIHdpdGggMSBzbWFydCBwb3dlciBtZXRlciwgdGhlbiA0NzYwIG1ldGVy cyB3aWxsIA0KICAgYmUgZGVwbG95ZWQgaW4gdG90YWwgaW4gdGhlIGJsb2NrLiBUaGlzIHdpbGwg Y2F1c2UgcHJlc3N1cmUgdG8gdGhlIA0KICAgbmV0d29yay4NCg0KICAgU28gYW4gYWdlbnQgbm9k ZSBoYXMgYmVlbiBpbnRyb2R1Y2VkIHRvIGFnZ3JlZ2F0ZSB0aGUgbWVzc2FnZSBmcm9tIA0KICAg dGhlc2UgbWV0ZXJzIGFuZCB0aGVuIHNlbmQgb3V0IHRoZXNlIG1ldGVycyBkYXRhIHRvIHRoZSBz ZXJ2ZXIgDQogICB0b2dldGhlci4gQWZ0ZXIgdGhlIGFnZW50IGlzIGludHJvZHVjZWQsIHRoZSBj b25uZWN0aW9uIGJldHdlZW4gDQogICBtZXRlcnMgYW5kIHNlcnZlcnMgaXMgc3BsaXQgaW50byB0 d28gcGFydHM6IG9uZSBpcyB0aGUgY29ubmVjdGlvbiANCiAgIGJldHdlZW4gbWV0ZXJzLCB0aGUg b3RoZXIgaXMgYW5kIHRoZSBvbmUgYmV0d2VlbiBhZ2VudCBhbmQgc2VydmVyLiANCiAgIFVzdWFs bHkgdGhlIGFnZW50IGlzIHJlc3BvbnNpYmxlIGZvciB0aGUgYXV0aGVudGljYXRpb24gb2YgdGhl IG1ldGVycy4gDQogICBUaGUgc2VydmVyIGlzIHJlc3BvbnNpYmxlIGZvciB0aGUgYXV0aGVudGlj YXRpb24gb2YgdGhlIGFnZW50IG9ubHkgDQogICBhbmQgZ2V0cyBhbGwgaW5mb3JtYXRpb24gYWJv dXQgbWV0ZXJzIHN1Y2ggYXMgSUQsIGRhdGEsIGZyb20gYWdlbnQuIA0KDQogICBUaGUgY3VycmVu dCBzZWN1cml0eSBtZWNoYW5pc20gaXM6IA0KDQoNCkp1ZHkgICAgICAgICAgICAgICAgRXhwaXJl cyBEZWNlbWJlciAyNCwgMjAxMyAgICAgICAgICAgICAgICAgICBbUGFnZSA0XQ0KDQpJbnRlcm5l dC1EcmFmdCAgICAgICAgIEdyb3VwIEF1dGhlbnRpY2F0aW9uICAgICAgICAgICAgICAgICAgICAg TWF5IDIwMTMNCg0KICAgMS4gRWFjaCBtZXRlciBpcyBhdXRoZW50aWNhdGVkIHdpdGggdGhlIGFn ZW50LiBBZ2VudCB3aWxsDQogICAgICBhdXRoZW50aWNhdGUgdGhlIG1ldGVyIG9uZSBieSBvbmUu IEFmdGVyIHRoYXQsIGFnZW50IHNob3VsZCBtYWtlIA0KICAgICAgbXV0dWFsIGF1dGhlbnRpY2F0 aW9uIHdpdGggc2VydmVyLiBUaGVuIHNlcnZlciBjYW4gY29uZmlybSBhZ2VudCANCiAgICAgIGlk ZW50aXR5Lg0KDQogICAyLiBNZXRlciB3aWxsIHNldCB1cCBzZWN1cml0eSBjb25uZWN0aW9uIHdp dGggYWdlbnQsIGFuZCBhZ2VudCB3aWxsIA0KICAgICAgYWxzbyBzZXQgdXAgc2VjdXJpdHkgY29u bmVjdGlvbiB3aXRoIHNlcnZlci4gV2hlbiBhIG1ldGVyIHdhbnRzIHRvIA0KICAgICAgc2VuZCBk YXRhIHRvIHNlcnZlci4gSXQgc2hvdWxkIHNlbmQgdGhlIGRhdGEgY29uZmlkZW50aWFsIA0KICAg ICAgcHJvdGVjdGVkIHRvIGFnZW50IGZpcnN0LiBBZ2VudCB3aWxsIGRlY3J5cHQgdGhlIGRhdGEg YW5kIHRyYW5zZmVyIA0KICAgICAgaXQgdG8gc2VydmVyIGJ5IHVzaW5nIHRoZSBzZWN1cml0eSBw cm90ZWN0aW9uIG1lY2hhbmlzbSBiZXR3ZWVuIA0KICAgICAgYWdlbnQgYW5kIHNlcnZlci4NCg0K ICAgSG93ZXZlciwgdGhpcyBwcm9jZWR1cmUgaGFzIHRoZSBmb2xsb3dpbmcgc2VjdXJpdHkgcHJv YmxlbXM6DQogICAxLiBTaW5jZSBhbGwgbWV0ZXJzIGFyZSBhdXRoZW50aWNhdGVkIGJ5IHRoZSBh Z2VudCBhbmQgbm8gZGlyZWN0IA0KICAgICAgYXV0aGVudGljYXRpb24gZnJvbSBzZXJ2ZXIgdG8g bWV0ZXIuIFRoZSBzZXJ2ZXIgY2FuIGdldCBtZXRlcidzIElEIA0KICAgICAgYW5kIGRhdGEgb25s eSB0aHJvdWdoIGFnZW50LiBTbyB0aGUgYWdlbnQgRHVlIHRvIHRoZSBrZXkgcG9zaXRpb24gDQog ICAgICBpbiB0aGUgYXV0aGVudGljYXRpb24sIHRoZSBzZWN1cml0eSBwcm90ZWN0aW9uIGFib3V0 IGFnZW50IGlzIHZlcnkgDQogICAgICBpbXBvcnRhbnQuIFNlcnZlciBjb3VsZCBub3QgYXV0aGVu dGljYXRlIG1ldGVycyBkaXJlY3RseS4gSXQgY2FuIA0KICAgICAgb25seSByZWx5IG9uIHRoZSBh Z2VudC4gSG93ZXZlciwgdGhlIGFnZW50IHdvdWxkIGJlIHBsYWNlZCBpbiANCiAgICAgIHVuc2Vj dXJlIHBsYWNlIG9yIG93bmVkIGJ5IGRpZmZlcmVudCB1c2VyIHJhdGhlciB0aGFuIHRoZSBzZXJ2 ZXIgDQogICAgICBvd25lci4gSWYgdGhlIGFnZW50IGlzIGNvbXByb21pc2VkIG9yIGxheSB0byBz ZXJ2ZXIsIGFnZW50IGNhbiBhY3QgDQogICAgICBhcyBhIG1pZGRsZSBhdHRhY2tlciB0aGF0IG1h a2VzIGZha2UgYXV0aGVudGljYXRpb24gdG8gbWV0ZXJzIGFuZCANCiAgICAgIHJlcG9ydCBmYWtl IElEIHRvIHNlcnZlcnMuIA0KICAgMi4gQW5vdGhlciBzZWN1cml0eSBwcm9ibGVtIGlzIHJlbGF0 ZWQgd2l0aCBhZ2VudCBhbmQgc2VydmVyLiBVbmRlciANCiAgICAgIHRoaXMgc2NlbmFyaW8sIGFs bCBpbmZvcm1hdGlvbiBmcm9tIG1ldGVycyB3aWxsIGJlIHRyYW5zZmVycmVkIA0KICAgICAgdGhy b3VnaCBhZ2VudC4gU28gYWdlbnQgd2lsbCBrbm93IGFsbCBpbmZvcm1hdGlvbiBnZW5lcmF0ZWQg YnkgDQogICAgICBtZXRlcnMuIEhvd2V2ZXIsIHVuZGVyIHNvbWUgc2NlbmFyaW8sIGFnZW50IHdv dWxkIGJlIG93bmVkIGFuZCANCiAgICAgIHVzZWQgYnkgZGlmZmVyZW50IHVzZXIgb3RoZXIgdGhh biB0aGUgbWV0ZXJzJyBhbmQgc2VydmVycycgb3duZXIuIA0KICAgICAgU28gdW5kZXIgdGhpcyBh c3N1bXB0aW9uLCB0aGUgYWdlbnQgc2hvdWxkIG5vdCBnZXQgdGhlIG1lc3NhZ2UgDQogICAgICBm cm9tIG1ldGVyIHRvIHNlcnZlci4gU28gbWV0ZXJzIHNob3VsZCBzZXQgdXAgYW4gc2VjdXJlIGVu ZC10by1lbmQgDQogICAgICB0dW5uZWwgd2l0aCBzZXJ2ZXIuIEl0IHNob3VsZCByZXF1ZXN0IGFu b3RoZXIgYXV0aGVudGljYXRpb24gYW5kIA0KICAgICAga2V5IGdlbmVyYXRpb24gcHJvY2VkdXJl IGluIGFkZGl0aW9uIHRvIGF1dGhlbnRpY2F0ZSB3aXRoIGFnZW50LiANCiAgICAgIFRoaXMgd2ls bCBicmluZyBjb21wbGV4aXR5IGFuZCBvdmVyaGVhZCB0byB0aGUgc3lzdGVtLg0KDQo0LiBSZXF1 aXJlbWVudA0KDQogICBJbiBvcmRlciB0byByZWR1Y2UgdGhlIGNvc3QgYW5kIHNpbXBsaWZ5IGEg bG90IG9mIG92ZXJoZWFkIHdpdGggdGhlIA0KICAgc2FtZSBjaGFyYWN0ZXJpc3RpY3Mgb2YgdGhl c2UgZ3JvdXBzIG9mIG1ldGVyIG9yIHNlbnNvciBub2RlIGdyb3VwLQ0KICAgYmFzZWQgb3BlcmF0 aW9ucywgaXQgaXMgbmVlZGVkIHRvIHByb3ZpZGUgZ3JvdXAgYXV0aGVudGljYXRpb24uIEZvciAN CiAgIGV4YW1wbGUsIHdoZW4gc21hcnQgbWV0ZXJzIHBlcmZvcm0gYnVsayBjb25maWd1cmF0aW9u IGluZm9ybWF0aW9uIA0KICAgdXBkYXRlcywgaXQgaXMgbmVlZGVkIHRvIGVuc3VyZSB0aGF0IHRo ZSBjb3JyZWN0IGlkZW50aXR5IG9mIHRoZSB1c2VyIA0KICAgbm9kZSB3aXRoaW4gdGhlIGdyb3Vw LCB0byBwcmV2ZW50IHRoZSBjb25maWd1cmF0aW9uIGluZm9ybWF0aW9uIGlzIA0KICAgd3Jvbmcg bm9kZSByZWNlaXZlcy4gSW4gYWRkaXRpb24sIHdoZW4gc21hcnQgbWV0ZXJzIHJlcG9ydCBtZXRl ciANCg0KSnVkeSAgICAgICAgICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDI0LCAyMDEzICAgICAg ICAgICAgICAgICAgIFtQYWdlIDVdDQoNCkludGVybmV0LURyYWZ0ICAgICAgICAgR3JvdXAgQXV0 aGVudGljYXRpb24gICAgICAgICAgICAgICAgICAgICBNYXkgMjAxMw0KDQogICByZWFkaW5ncyB0 byB0aGUgZWxlY3RyaWNpdHkgc3lzdGVtIHBsYXRmb3JtLCBpdCBpcyBhbHNvIG5lZWRlZCB0byBi ZSANCiAgIGFibGUgdG8gcHJvdmUgdGhlIGNvcnJlY3RuZXNzIG9mIHRoZSBpZGVudGl0eSBvZiBz bWFydCBtZXRlcnMsIHRvIA0KICAgcHJldmVudCBtYWxpY2lvdXMgbm9kZSByZXBvcnRpbmcgZmFs c2UgcmVhZGluZ3MuDQoNCjUuIEdyb3VwIEF1dGhlbnRpY2F0aW9uIFNvbHV0aW9uDQo1LjEuIElu dHJvZHVjdGlvbg0KDQogICBHcm91cCBhdXRoZW50aWNhdGlvbiBpcyBhIGtpbmQgb2YgYXV0aGVu dGljYXRpb24gdGVjaG5vbG9naWVzIHRoYXQgYSANCiAgIGdyb3VwIG9mIHVzZXJzIG9yIHRlcm1p bmFscyBjYW4gYmUgYXV0aGVudGljYXRlZCB0b2dldGhlciBhdCB0aGUgc2FtZSANCiAgIHRpbWUu IEluc3RlYWQgb2YgYXV0aGVudGljYXRpbmcgYSBudW1iZXIgb2YgdGVybWluYWxzIG9mIGEgZ3Jv dXAgb25lIA0KICAgYnkgb25lLCBncm91cCBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc20gdHJlYXRz IHRoZXNlIHRlcm1pbmFscyBpbiB0aGUgDQogICBncm91cCBhcyBhIHdob2xlLCBhbmQgYXV0aGVu dGljYXRlcyB0aGVtIHRvZ2V0aGVyLiBFYWNoIGdyb3VwIGhhcyBhIA0KICAgdW5pcXVlIGlkZW50 aWZpZXIsIGFuZCBhbiBhZ2VudCwgd2hpY2ggY2FuIGJlIGNhbGxlZCBhcyBncm91cCBhZ2VudCwg DQogICBncm91cCBnYXRld2F5LCBldGMuDQoNCiAgIEdyb3VwIGF1dGhlbnRpY2F0aW9uIGNvbXBy aXNlcyBmb2xsb3dpbmcgdHdvIHBoYXNlcyBhcyBmb2xsb3dpbmc6DQoNCiAgIDEuIFRoZSBmaXJz dCBwaGFzZSBpcyB0aGF0IHVzZXIvdGVybWluYWwgc2hvdWxkIGJlIGF1dGhlbnRpY2F0ZWQgDQog ICAgICB3aGV0aGVyIGl0IGJlbG9uZ3MgdG8gYSBnaXZlbiBncm91cC4gVGhpcyBjYW4gYmUgaW1w bGVtZW50ZWQgDQogICAgICB0aHJvdWdoIHRoZSBwcm9wcmlldGFyeSBhdXRoZW50aWNhdGlvbiB0 ZWNobm9sb2d5IGluIGEgZ3JvdXAsIHN1Y2ggDQogICAgICBhcyBaaWdiZWUgb3IgYW55IG90aGVy cy4NCg0KICAgMi4gVGhlIHNlY29uZCBwaGFzZSBpcyB0aGF0IG11dHVhbCBhdXRoZW50aWNhdGlv biBzaG91bGQgYmUgbWFkZSANCiAgICAgIGJldHdlZW4gYSBnaXZlbiBuZXR3b3JrIGVudGl0eSwg YW5kIGEgZ3JvdXAgYWdlbnQgd2hvIGlzIA0KICAgICAgcmVzcG9uc2libGUgdG8gZGVsZWdhdGUg YWxsIHRlcm1pbmFscyBpbiB0aGUgZ3JvdXAuIA0KDQogICAgICBBZnRlciB0aGUgYXV0aGVudGlj YXRpb24sIHRlcm1pbmFscyBhbmQgbmV0d29yayBlbnRpdHkgY2FuIA0KICAgICAgZ2VuZXJhdGUg c2VwYXJhdGVkIHNlc3Npb24ga2V5cyBpbmRpdmlkdWFsbHkgaWYgdGhlcmUgaXMgc29tZSANCiAg ICAgIGRlbWFuZCB0byBtYWtlIGluZGl2aWR1YWwgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIG5ldHdv cmsgZW50aXR5IGFuZCANCiAgICAgIGVhY2ggdGVybWluYWwuDQoNCjUuMi4gRGV0YWlsZWQgZ3Jv dXAgc2NlbmFyaW8gZGVzY3JpcHRpb24NCg0KICAgRm9yIGdyb3VwIGF1dGhlbnRpY2F0aW9uLCB0 aGVyZSBpcyBkZXRhaWxlZCBuZXR3b3JrIGRlc2NyaXB0aW9uIGFzIA0KICAgZm9sbG93aW5nLiBU aGVyZSBhcmUgNSBub2RlcyBpbnNpZGUgYSBnaXZlbiBncm91cC4gVGhleSBhcmUgQTEsIEEyLCAN CiAgIEEzLCBBNCwgYW5kIEE1IHdoaWNoIGlzIGdyb3VwIGFnZW50LiBBbmQgdGhlIGdpdmVuIGdy b3VwIGNhbiBiZSBuYW1lZCANCiAgIGFzIGdyb3VwIEEuIEFsbCBub2RlcyBpbiBncm91cCBBIGNh biBjb21tdW5pY2F0ZSB3aXRoIGVhY2ggb3RoZXIuIA0KICAgV2hhdCBpcyBtb3JlLCBBNSBpcyBh YmxlIHRvIGNvbW11bmljYXRlIHdpdGggbmV0d29yayBlbnRpdHkgZGlyZWN0bHkuICANCiAgIE5l dHdvcmsgZW50aXR5IHdpbGwgc3RvcmUgdGhlIGdyb3VwIGluZm9ybWF0aW9uLCBzdWNoIGFzIGlk ZW50aWZpZXJzLCANCiAgIHJvb3Qga2V5cyB1c2VkIGZvciBhbGwgbm9kZXMgaW5zaWRlIHRoZSBn cm91cC4gTmV0d29yayBlbnRpdHkgaXMgYWxzbyANCiAgIHJlc3BvbnNpYmxlIGZvciBnZW5lcmF0 aW5nIGdyb3VwIGF1dGhlbnRpY2F0aW9uIHZlY3Rvci4gVGhlIHNjZW5hcmlvIA0KICAgaXMgc2hv d24gYXMgYmVsb3cuDQoNCkp1ZHkgICAgICAgICAgICAgICAgRXhwaXJlcyBEZWNlbWJlciAyNCwg MjAxMyAgICAgICAgICAgICAgICAgICBbUGFnZSA2XQ0KDQpJbnRlcm5ldC1EcmFmdCAgICAgICAg IEdyb3VwIEF1dGhlbnRpY2F0aW9uICAgICAgICAgICAgICAgICAgICAgTWF5IDIwMTMNCg0KICAg Ky0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0r DQogICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwNCiAgIHwgKy0tLS0tLS0rICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfA0KICAgfCB8ICBBMSAgIHw8LS0tLS0tLS0tKyAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8DQogICB8ICstLS0tLS0tKyAgICAgICAgICB8ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwNCiAgIHwgIF4gICBeICAgICAgICAgICAgIHwgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgfCAgfCAgIHwgICAgICAgICAgICAgfCAgICAg ICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tKyB8DQogICB8ICB8ICAgfCAgICAgICAgICAgICB8 ICAgICAgICAgfCBOZXR3b3JrIEFWIGdlbmVyYXRvciB8IHwNCiAgIHwgIHwgICB8ICAgICAgICAg ICAgIHwgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsgfA0KICAgfCAgfCAgIHwgICAg ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgIF4gICAgICAgICAgICB8DQogICB8ICB8ICAg fCAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgIHwNCiAgIHwg IHwgICBWICAgICAgICAgICAgIFYgICAgICAgICAgICAgICAgICAgICBWICAgICAgICAgICAgfA0K ICAgfCAgfCArLS0tLSsgICAgICAgKy0tLS0tKyAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0t KyB8DQogICB8ICB8IHwgQTIgfDwtLS0tLT58IEE1ICB8PD09PT0+fE5ldHdvcmsgYXV0aGVudGlj YXRvciB8IHwNCiAgIHwgIHwgKy0tLS0rICAgICAgICstLS0tLSsgICAgICArLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSsgfA0KICAgfCAgfCAgfCAgICAgICAgICAgXiAgXiAgXiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB8DQogICB8ICB8ICB8ICArLS0tLS0tLS0rICB8ICArLS0tKyAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwNCiAgIHwgIHwgIHwgIHwgICAgICAgICAgIHwgICAgICBW ICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgfCAgfCAgfCAgfCAgICAgICAgICAgfCAg ICstLS0tKyAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICB8ICB8ICB8ICB8ICAgICAgICAg ICB8ICAgfCBBNCB8ICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgIHwgIFYgIFYgIFYgICAg ICAgICAgIHwgICArLS0tLSsgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgfCAgKy0tLS0t LSsgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICB8ICB8 ICBBMyAgfDwtLS0tLS0tLS0rICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAg IHwgICstLS0tLS0rICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg fA0KICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0rDQpGaWd1cmUgMSBHcm91cCBBdXRoZW50aWNhdGlvbiBBcmNoaXRlY3R1cmUNCiAgIG8g IEE1IChncm91cCBhZ2VudCkgY29tbXVuaWNhdGVzIHdpdGggb3RoZXIgbm9kZXMsIGkuZS4gQTEs IEEyLCBBMywgDQogICAgICBBNCBieSBpbm5lciBncm91cCBwcm90b2NvbC4gIEFsbCBub2RlcyBz aG91bGQgY29udGFpbiBzdWNoIG1vZGVscyANCiAgICAgIGFzIGlubmVyIGdyb3VwIGNvbW11bmlj YXRpb24gbW9kZWwsIGdyb3VwIGF1dGhlbnRpY2F0aW9uIG1vZGUuIA0KICAgICAgSW5uZXIgZ3Jv dXAgY29tbXVuaWNhdGlvbiBtb2RlbCBjYW4gYmUgdXNlZCB0byBzZW5kaW5nL3JlY2VpdmluZyAN CiAgICAgIHRoZSBncm91cCBhdXRoZW50aWNhdGlvbiBtZXNzYWdlLiBHcm91cCBhdXRoZW50aWNh dGlvbiBtb2RlbCBjYW4gDQogICAgICBiZSB1c2VkIHRvIGdlbmVyYXRlIGF1dGhlbnRpY2F0aW9u IHZlY3RvcnMvcmVzcG9uc2UgYW5kIHRvIA0KICAgICAgYXV0aGVudGljYXRlIHBlZXJzLg0KICAg byAgR3JvdXAgYWdlbnQgd2lsbCBtYWtlIG11dHVhbCBhdXRoZW50aWNhdGlvbiB3aXRoIG5ldHdv cmsgZW50aXRpZXMuIA0KICAgICAgVGhlcmUgYXJlIHR3byBraW5kcyBvZiBuZXR3b3JrIGVudGl0 aWVzLiBOZXR3b3JrIGF1dGhlbnRpY2F0b3IgaXMgDQogICAgICByZXNwb25zaWJsZSBmb3IgbXV0 dWFsIGF1dGhlbnRpY2F0aW9uIGFjdGlvbiB3aXRoIGdyb3VwIGFnZW50LiBBbmQgDQogICAgICBO ZXR3b3JrIEFWIGdlbmVyYXRvciBpcyByZXNwb25zaWJsZSBmb3IgZ3JvdXAgYXV0aGVudGljYXRp b24gDQogICAgICB2ZWN0b3IgZ2VuZXJhdGlvbiBhbmQgZm9yd2FyZGluZyBBViB0byBuZXR3b3Jr IGF1dGhlbnRpY2F0b3IuIA0KICAgICAgQWZ0ZXIgdGhlIGF1dGhlbnRpY2F0aW9uLCB0ZXJtaW5h bHMgYW5kIG5ldHdvcmsgZW50aXR5IGNhbiANCiAgICAgIGdlbmVyYXRlIHNlcGFyYXRlZCBzZXNz aW9uIGtleXMgaW5kaXZpZHVhbGx5IGlmIHRoZXJlIGlzIHNvbWUgDQogICAgICBkZW1hbmQgdG8g bWFrZSBpbmRpdmlkdWFsIGNvbW11bmljYXRpb24gYmV0d2VlbiBuZXR3b3JrIGVudGl0eSBhbmQg DQogICAgICBlYWNoIHRlcm1pbmFscy4NCg0KDQpKdWR5ICAgICAgICAgICAgICAgIEV4cGlyZXMg RGVjZW1iZXIgMjQsIDIwMTMgICAgICAgICAgICAgICAgICAgW1BhZ2UgN10NCkludGVybmV0LURy YWZ0ICAgICAgICAgR3JvdXAgQXV0aGVudGljYXRpb24gICAgICAgICAgICAgICAgICAgICBNYXkg MjAxMw0KDQogICBvICBHcm91cCBhZ2VudCB3aG8gcmVwcmVzZW50cyB0aGUgd2hvbGUgZ3JvdXAs IGNvbW11bmljYXRlcyB3aXRoIA0KICAgICAgbmV0d29yayBlbnRpdHksIGFuZCBnZW5lcmF0ZSBn cm91cCBzZXNzaW9uIGtleSB0aHJvdWdoIA0KICAgICAgYXV0aGVudGljYXRpb24gd2l0aCB0aGUg bmV0d29yayBhdXRoZW50aWNhdG9yLiANCiAgIG8gIFByZS1jb25maWd1cmUgb2YgdGhlIGdyb3Vw DQogICBBbGwgdGhlIGdyb3VwIG5vZGVzIHNob3VsZCBiZSBjb25maWd1cmVkIHdpdGggc3ViIGtl eSBrXzEsIGtfMiwga18zLCANCiAgIGtfNCwga19nLCB3aGljaCB3aWxsIGJlIHVzZWQgZm9yIG11 dHVhbCBhdXRoZW50aWNhdGlvbiBpbiB0aGUgZ3JvdXAgDQogICBhbmQgc2VwYXJhdGVkIGNvbW11 bmljYXRpb24uDQoNCjUuMy4gR3JvdXAgc2NlbmFyaW8gcHJvY2VkdXJlDQoNCiAgIEFzIG1lbnRp b25lZCBhYm92ZSwgZ3JvdXAgYXV0aGVudGljYXRpb24gY2FuIGJlIGRpdmlkZWQgaW50byB0d28g DQogICBwaGFzZXMuIA0KDQogICBJbiB0aGUgZmlyc3QgcGhhc2UsIGdyb3VwIG1lbWJlciwgc2F5 IEFpLCBzZW5kcyBhdXRoZW50aWNhdGlvbiANCiAgIHJlcXVlc3QgdG8gZ3JvdXAgYWdlbnQgYXQg Zmlyc3QgYXMgZm9sbG93aW5nLiANCiAgIDEuIEdyb3VwIG1lbWJlciBBaSBzZW5kcyBtZXNzYWdl IHRvIHRyaWdnZXIgYXV0aGVudGljYXRpb24gYXQgZmlyc3QuIA0KICAgMi4gR3JvdXAgYWdlbnQg c2VuZHMgYXV0aGVudGljYXRpb24gcmVxdWVzdCB0byBlYWNoIGdyb3VwIG1lbWJlci4NCiAgIDMu IEdyb3VwIG1lbWJlciBBaSB2ZXJpZmllcyBncm91cCBhZ2VudCBhdCBmaXJzdC4gSWYgc3VjY2Vz cywgQWkgd2lsbCANCiAgICAgIGdlbmVyYXRlIHNlc3Npb24ga2V5IGZvciB0aGUgY29tbXVuaWNh dGlvbiB3aXRoIGdyb3VwIGFnZW50LCBhbmQgDQogICAgICBzZW5kcyByZXNwb25zZSBjb250YWlu aW5nIHN1Y2ggc2Vzc2lvbiBrZXkgYmFjayB0byBncm91cCBhZ2VudC4gSWYgDQogICAgICBub3Qg c3VjY2VzcywgdGhlIGF1dGhlbnRpY2F0aW9uIGlzIGZhaWxlZCBhbmQgZ3JvdXAgYXV0aGVudGlj YXRpb24gDQogICAgICBwcm9jZWR1cmUgd2lsbCBiZSBhYm9ydC4NCiAgIDQuIEdyb3VwIGFnZW50 IGF1dGhlbnRpY2F0ZXMgZWFjaCBncm91cCBtZW1iZXIgQWkgdGhyb3VnaCB0aGUgDQogICAgICBy ZXNwb25zZSBtZXNzYWdlIGFuZCByZWNvcmQgdGhlIGF1dGhlbnRpY2F0aW9uIHJlc3VsdCBpbiBh IG1hcHBpbmcgDQogICAgICB0YWJsZS4NCiAgIEFmdGVyIHRoZSBpbm5lciBncm91cCBhdXRoZW50 aWNhdGlvbiwgYWxsIG9mIGdyb3VwIG1lbWJlcnMgYXJlIA0KICAgYXV0aGVudGljYXRlZCBieSBn cm91cCBhZ2VudCwgYW5kIHNlY29uZCBwaGFzZSBjYW4gYmUgcGVyZm9ybWVkLg0KDQogICA1LiBH cm91cCBhZ2VudCBzZW5kcyBtZXNzYWdlIHRvIG5ldHdvcmsgYXV0aGVudGljYXRvciB0byB0cmln Z2VyIHRoZSANCiAgICAgIGF1dGhlbnRpY2F0aW9uIG91dHNpZGUgdGhlIGdyb3VwLg0KDQogICA2 LiBHcm91cCBhdXRoZW50aWNhdG9yIHNlbmQgYXV0aGVudGljYXRpb24gdmVjdG9yIHJlcXVlc3Qg dG8gbmV0d29yayANCiAgICAgIEFWIGdlbmVyYXRvciB3aXRoIGdyb3VwIGFnZW50IGlkZW50aXR5 Lg0KDQpKdWR5ICAgICAgICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMjQsIDIwMTMgICAgICAg ICAgICAgICAgICAgW1BhZ2UgOF0NCg0KSW50ZXJuZXQtRHJhZnQgICAgICAgICBHcm91cCBBdXRo ZW50aWNhdGlvbiAgICAgICAgICAgICAgICAgICAgIE1heSAyMDEzDQoNCiAgIDcuIE5ldHdvcmsg QVYgZ2VuZXJhdG9yIHdpbGwgZ2VuZXJhdGUgYXV0aGVudGljYXRpb24gdmVjdG9yIA0KICAgICAg YWNjb3JkaW5nIHRvIGdyb3VwIGFnZW50IGlkZW50aXR5Lg0KICAgOC4gV2hhdCBpcyBtb3JlLCBu ZXR3b3JrIEFWIGdlbmVyYXRvciBzaG91bGQgYmUgYWJsZSB0byByZWNvZ25pemUgDQogICAgICB0 aGF0IGlzIGEgZ3JvdXAgYXV0aGVudGljYXRpb24gaXMgcGVyZm9ybWVkIGJhc2VkIG9uIGdyb3Vw IGFnZW50IA0KICAgICAgaWRlbnRpdHkuIE5ldHdvcmsgQVYgZ2VuZXJhdG9yIHdpbGwgZ2VuZXJh dGUgc2Vzc2lvbiBrZXkgZm9yIGVhY2ggDQogICAgICBncm91cCBtZW1iZXJzIGJ5IHVzaW5nIHBy ZS1jb25maWd1cmVkIGdyb3VwIG1lbWJlciBpbmZvcm1hdGlvbiBhbmQgDQogICAgICB0aGUgc2Ft ZSBrZXlpbmcgbWF0ZXJpYWwgaW4gYWJvdmUgc3RlcC4NCiAgIDkuIE5ldHdvcmsgQVYgZ2VuZXJh dG9yIHdpbGwgc2VuZCBzdWNoIGF1dGhlbnRpY2F0aW9uIHZlY3RvciBhbmQgDQogICAgICBzZXNz aW9uIGtleXMgdG9nZXRoZXIgYmFjayB0byBuZXR3b3JrICBhdXRoZW50aWNhdG9yLg0KICAgMTAu TmV0d29yayBhdXRoZW50aWNhdG9yIHdpbGwgcGVyZm9ybSBtdXR1YWwgYXV0aGVudGljYXRpb24g d2l0aCANCiAgICAgIGdyb3VwIGFnZW50Lg0KICAgMTEuR3JvdXAgYWdlbnQgYXV0aGVudGljYXRl IGdyb3VwIGFnZW50IGFuZCBzZW5kIGF1dGhlbnRpY2F0aW9uIA0KICAgICAgcmVzcG9uc2UgYmFj ayB0byBuZXR3b3JrIGF1dGhlbnRpY2F0b3IuDQogICAxMi5OZXR3b3JrIGF1dGhlbnRpY2F0aW9u IGF1dGhlbnRpY2F0ZSBncm91cCBhZ2VudC4gSWYgc3VjY2VzcywgaXQgDQogICAgICBjYW4gYmUg Y29uc2lkZXJlZCB0aGF0IGdyb3VwIGFnZW50IGFuZCBhbGwgZ3JvdXAgdGVybWluYWxzIGlzIA0K ICAgICAgYXV0aGVudGljYXRlZCBzdWNjZXNzZnVsbHkuDQogICAxMy5Hcm91cCBhZ2VudCB3aWxs IGNvbW11bmljYXRlIHdpdGggbmV0d29yayBhdXRoZW50aWNhdG9yIHRvIGNob29zZSANCiAgICAg IHRoZSBjb25maWRlbnRpYWwgYW5kIGludGVncml0eSBwcm90ZWN0aW9uIGFsZ29yaXRobXMuIA0K ICAgMTQuQWZ0ZXIgdGhhdCwgZ3JvdXAgYWdlbnQgd2lsbCBzZW5kIGtleWluZyBtYXRlcmlhbCwg c2VsZWN0ZWQgDQogICAgICBhbGdvcml0aG1zIHRvIGVhY2ggZ3JvdXAgbWVtYmVyLg0KICAgMTUu IEdyb3VwIG1lbWJlciB3aWxsIGdlbmVyYXRlIHNlc3Npb24ga2V5cy4NCg0KICAgQWZ0ZXIgdGhl c2UgdHdvIHBoYXNlcywgZWFjaCB0ZXJtaW5hbCBpcyBhdXRoZW50aWNhdGVkIHdpdGggbmV0d29y ayANCiAgIGF1dGhlbnRpY2F0b3IgYW5kIGdlbmVyYXRlIGluZGVwZW5kZW50bHkgc2Vzc2lvbiBr ZXkgd2l0aCBuZXR3b3JrIA0KICAgYXV0aGVudGljYXRvci4NCg0KNi4gU2VjdXJpdHkgQ29uc2lk ZXJhdGlvbnMNCg0KICAgVGhpcyBtZW1vIGNvbnNpZGVycyB0aGUgc2VjdXJpdHkgYXV0aGVudGlj YXRpb24gZm9yIGdyb3VwLiBTbyBpdCANCiAgIHdvdWxkIG5vdCBpbnRyb2R1Y2UgYW55IGFkZGl0 aW9uYWwgc2VjdXJpdHkgcHJvYmxlbXMuDQoNCjcuIElBTkEgQ29uc2lkZXJhdGlvbnMNCg0KICAg VGhlcmUgYXJlIG5vIElBTkEgY29uc2lkZXJhdGlvbnMgYXNzb2NpYXRlZCB0byB0aGlzIG1lbW8u DQoNCg0KSnVkeSAgICAgICAgICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDI0LCAyMDEzICAgICAg ICAgICAgICAgICAgIFtQYWdlIDldDQoNCkludGVybmV0LURyYWZ0ICAgICAgICAgR3JvdXAgQXV0 aGVudGljYXRpb24gICAgICAgICAgICAgICAgICAgICBNYXkgMjAxMw0KDQogICA4LiBDb25jbHVz aW9ucw0KDQogICAgICBUaGlzIG1lbW8gZGVzY3JpYmVzIHRoZSBwcm9ibGVtIHJhaXNlZCBieSB1 c2luZyBvbmUtdG8tb25lIA0KICAgICAgYXV0aGVudGljYXRpb24gZm9yIGh1Z2UgbnVtYmVyIG9m IEludGVybmV0IG9mIFRoaW5ncyB0ZXJtaW5hbHMuIEFmdGVyIA0KICAgICAgdGhhdCwgZ3JvdXAg YXV0aGVudGljYXRpb24gcmVxdWlyZW1lbnQgaXMgcmFpc2VkIGFuZCBhIGdyb3VwIA0KICAgICAg YXV0aGVudGljYXRpb24gbWVjaGFuaXNtIGlzIHByb3Bvc2VkDQoNCiAgIDkuIFJlZmVyZW5jZXMN CiAgIDkuMS4gTm9ybWF0aXZlIFJlZmVyZW5jZXMNCiAgIDkuMi4gSW5mb3JtYXRpdmUgUmVmZXJl bmNlcw0KDQpBdXRob3JzJyBBZGRyZXNzZXMNCiAgIEp1ZHkgWmh1DQogICBDaGluYSBNb2JpbGUN CiAgIFVuaXQgMiwgMzIgWHVhbnd1bWVueGkgQXZlLA0KICAgWGljaGVuZyBEaXN0cmljdCwNCiAg IEJlaWppbmcgMTAwMDUzLCBDaGluYQkNCiAgIEVtYWlsOiB6aHVob25ncnVAY2hpbmFtb2JpbGUu Y29tDQoNCiAgIE1pbnBlbmcgUWkNCiAgIENoaW5hIE1vYmlsZQ0KICAgVW5pdCAyLCAzMiBYdWFu d3VtZW54aSBBdmUsDQogICBYaWNoZW5nIERpc3RyaWN0LA0KICAgQmVpamluZyAxMDAwNTMsIENo aW5hDQogICBFbWFpbDogcWltaW5wZW5nQGNoaW5hbW9iaWxlLmNvbQ0KDQogICBZZSBUaWFuDQog ICBDaGluYSBNb2JpbGUNCiAgIFVuaXQgMiwgMzIgWHVhbnd1bWVueGkgQXZlLA0KICAgWGljaGVu ZyBEaXN0cmljdCwNCiAgIEJlaWppbmcgMTAwMDUzLCBDaGluYQkNCiAgIEVtYWlsOiB0aWFueWVA Y2hpbmFtb2JpbGUuY29tDQoNCg0KSnVkeSAgICAgICAgICAgICAgICBFeHBpcmVzIERlY2VtYmVy IDI0LCAyMDEzICAgICAgICAgICAgICAgICAgW1BhZ2UgMTBd --089e013cb728a84dc704e10e61ba-- From internet-drafts@ietf.org Tue Jul 9 06:19:26 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A853411E8111; Tue, 9 Jul 2013 06:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ACFs6W3NElu; Tue, 9 Jul 2013 06:19:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B9E8111E8138; Tue, 9 Jul 2013 06:19:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130709131921.23684.43685.idtracker@ietfa.amsl.com> Date: Tue, 09 Jul 2013 06:19:21 -0700 Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-groupcomm-10.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 13:19:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Constrained RESTful Environments Working = Group of the IETF. Title : Group Communication for CoAP Author(s) : Akbar Rahman Esko Dijk Filename : draft-ietf-core-groupcomm-10.txt Pages : 38 Date : 2013-07-09 Abstract: CoAP is a RESTful transfer protocol for constrained devices and constrained networks. It is anticipated that constrained devices will often naturally operate in groups (e.g., in a building automation scenario all lights in a given room may need to be switched on/off as a group). This document provides guidance for how the CoAP protocol should be used in a group communication context. An approach for using CoAP on top of IP multicast is detailed. Also, various use cases and corresponding protocol flows are provided to illustrate important concepts. Finally, guidance is provided for deployment in various network topologies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-groupcomm There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-core-groupcomm-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-groupcomm-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From esko.dijk@philips.com Tue Jul 9 07:53:23 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D53B21F961F for ; Tue, 9 Jul 2013 07:53:23 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oRn5jilnNj10 for ; Tue, 9 Jul 2013 07:53:18 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe005.messaging.microsoft.com [216.32.180.188]) by ietfa.amsl.com (Postfix) with ESMTP id 57EA721F9AF5 for ; Tue, 9 Jul 2013 07:53:07 -0700 (PDT) Received: from mail157-co1-R.bigfish.com (10.243.78.247) by CO1EHSOBE030.bigfish.com (10.243.66.95) with Microsoft SMTP Server id 14.1.225.22; Tue, 9 Jul 2013 14:53:06 +0000 Received: from mail157-co1 (localhost [127.0.0.1]) by mail157-co1-R.bigfish.com (Postfix) with ESMTP id A1DE4360136 for ; Tue, 9 Jul 2013 14:53:06 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -29 X-BigFish: VPS-29(zz15d6O936eI154dI542I9251I217bIdd85kzz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275dhz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1155h) Received: from mail157-co1 (localhost.localdomain [127.0.0.1]) by mail157-co1 (MessageSwitch) id 1373381584749884_29023; Tue, 9 Jul 2013 14:53:04 +0000 (UTC) Received: from CO1EHSMHS016.bigfish.com (unknown [10.243.78.243]) by mail157-co1.bigfish.com (Postfix) with ESMTP id B06D954004E; Tue, 9 Jul 2013 14:53:04 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CO1EHSMHS016.bigfish.com (10.243.66.26) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 9 Jul 2013 14:53:03 +0000 Received: from 011-DB3MPN2-083.MGDPHG.emi.philips.com ([169.254.3.190]) by 011-DB3MMR1-004.MGDPHG.emi.philips.com ([10.128.28.54]) with mapi id 14.03.0136.001; Tue, 9 Jul 2013 14:53:01 +0000 From: "Dijk, Esko" To: "core (core@ietf.org)" Thread-Topic: Update to draft-ietf-core-groupcomm-10 Thread-Index: Ac58s8ND7/tKu4jjTAaZFatU/d1z4w== Date: Tue, 9 Jul 2013 14:53:01 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618C9A81D@011-DB3MPN2-083.MGDPHG.emi.philips.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.103] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: [core] Update to draft-ietf-core-groupcomm-10 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 14:53:23 -0000 Dear all, This update contains various editorial changes. See below changelog for ref= erence. Html: http://tools.ietf.org/html/draft-ietf-core-groupcomm-10 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-groupcomm-10 regards, Esko & Akbar Changes from ietf-09 to ietf-10: o Various editorial updates including: o Added a fourth option in section 3.3 on ways to obtain the URI path for a group request. o Clarified use of content format in GET/PUT requests for Configuring Group Membership in Endpoints (in section 3.6). o Changed reference "draft-shelby-core-resource-directory" to "draft-ietf-core-resource-directory". o Clarified (in section 3.7) that ACKs are never used for a multicast request (from #296). o Clarified (in section 5.2/5.2.3) that MPL does not support group membership advertisement. o Adding introductory paragraph to Scope (section 2.2). o Wrote out fully the URIs in table section 3.2. o Reworded security text in section 7.2 (New Internet Media Type) to make it consistent with section 3.6 (Configuring Group Membership). o Fixed formatting of hyperlinks in sections 6.3 and 7.2. -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of int= ernet-drafts@ietf.org Sent: Tuesday, July 09, 2013 15:19 To: i-d-announce@ietf.org Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-groupcomm-10.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Constrained RESTful Environments Working = Group of the IETF. Title : Group Communication for CoAP Author(s) : Akbar Rahman Esko Dijk Filename : draft-ietf-core-groupcomm-10.txt Pages : 38 Date : 2013-07-09 Abstract: CoAP is a RESTful transfer protocol for constrained devices and constrained networks. It is anticipated that constrained devices will often naturally operate in groups (e.g., in a building automation scenario all lights in a given room may need to be switched on/off as a group). This document provides guidance for how the CoAP protocol should be used in a group communication context. An approach for using CoAP on top of IP multicast is detailed. Also, various use cases and corresponding protocol flows are provided to illustrate important concepts. Finally, guidance is provided for deployment in various network topologies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-groupcomm There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-core-groupcomm-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-groupcomm-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ________________________________ 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 pporamba@ee.oulu.fi Tue Jul 9 18:31:02 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A303311E80BA for ; Tue, 9 Jul 2013 18:31:02 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hzzafROLiO5j for ; Tue, 9 Jul 2013 18:30:58 -0700 (PDT) Received: from ee.oulu.fi (ee.oulu.fi [130.231.61.23]) by ietfa.amsl.com (Postfix) with ESMTP id 898B911E80E6 for ; Tue, 9 Jul 2013 18:30:57 -0700 (PDT) Received: from www.ee.oulu.fi (ees7.oulu.fi [130.231.61.28]) (authenticated bits=0) by ee.oulu.fi (8.14.4/8.14.4) with ESMTP id r6A1Uuau017075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 10 Jul 2013 04:30:56 +0300 X-Mailer: Hastymail2 1.1 To: From: "pporamba" Date: Tue, 09 Jul 2013 20:30:56 -0500 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: Content-Transfer-Encoding: 8bit Subject: [core] Fw: New Version Notification for draft-pporamba-dtls-certkey-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 01:31:02 -0000 Dear CORE members, Please, find below the announcement of our submission dealing with first ideas to bring dtls-based secure key establishment for IoT. Regards, Pawani Original Message ---------------- Subject: New Version Notification for draft-pporamba-dtls-certkey-00.txt From: internet-drafts@ietf.org Date: Sun, 23 Jun 2013 07:51:50 -0700 A new version of I-D, draft-pporamba-dtls-certkey-00.txt has been successfully submitted by Pawani Porambage and posted to the IETF repository. Filename: draft-pporamba-dtls-certkey Revision: 00 Title: Certificate based keying scheme for DTLS secured IoT Creation date: 2013-06-23 Group: Individual Submission Number of pages: 14 URL: http://www.ietf.org/internet-drafts/draft-pporamba-dtls-certkey-00.txt Status: http://datatracker.ietf.org/doc/draft-pporamba-dtls-certkey Htmlized: http://tools.ietf.org/html/draft-pporamba-dtls-certkey-00 Abstract: The IP-based Internet of Things (IoT) stands for the universal interconnection of smart objects and back end users with the help of IP protocols. Secure key management among the smart objects is an important aspect of IoT security. Due to the high levels of resource constraints of the devices in terms of memory, battery capacity and CPU power, and other network characteristics such as mobility, scalability, heterogeneity and limited bandwidth, the conventional security protocols cannot be directly deployed in IoT networks in their raw formats. We propose a lightweight DTLS-based keying mechanism for CoAP IoT smart objects which supports the scalability of the network and node mobility. The protocol consumes less device resources and minimum network bandwidth by incurring low message overhead. The smart objects can securely access the network and obtain certificates after an initial configuration irrespective of the manufacturer standards. The IETF Secretariat From esko.dijk@philips.com Thu Jul 11 04:21:00 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4022F21F9655 for ; Thu, 11 Jul 2013 04:21:00 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W1baAGypWtTb for ; Thu, 11 Jul 2013 04:20:54 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe003.messaging.microsoft.com [213.199.154.206]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB8E21F8F00 for ; Thu, 11 Jul 2013 04:20:53 -0700 (PDT) Received: from mail91-am1-R.bigfish.com (10.3.201.241) by AM1EHSOBE017.bigfish.com (10.3.207.139) with Microsoft SMTP Server id 14.1.225.22; Thu, 11 Jul 2013 11:20:52 +0000 Received: from mail91-am1 (localhost [127.0.0.1]) by mail91-am1-R.bigfish.com (Postfix) with ESMTP id 8442822015C; Thu, 11 Jul 2013 11:20:52 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -28 X-BigFish: VPS-28(zz98dI15d6Oc89bh542I9251I217bIdd85kzz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1033IL8275bh8275dhz2dh2a8h668h839h947hd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1155h) Received: from mail91-am1 (localhost.localdomain [127.0.0.1]) by mail91-am1 (MessageSwitch) id 1373541649770502_22681; Thu, 11 Jul 2013 11:20:49 +0000 (UTC) Received: from AM1EHSMHS005.bigfish.com (unknown [10.3.201.226]) by mail91-am1.bigfish.com (Postfix) with ESMTP id B8801200046; Thu, 11 Jul 2013 11:20:49 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by AM1EHSMHS005.bigfish.com (10.3.207.105) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 11 Jul 2013 11:20:49 +0000 Received: from 011-DB3MMR1-012.MGDPHG.emi.philips.com (10.128.28.96) by 011-DB3MMR1-008.MGDPHG.emi.philips.com (10.128.28.47) with Microsoft SMTP Server (TLS) id 14.3.136.1; Thu, 11 Jul 2013 11:19:49 +0000 Received: from 011-DB3MPN2-082.MGDPHG.emi.philips.com ([169.254.2.231]) by 011-DB3MMR1-012.MGDPHG.emi.philips.com ([10.128.28.96]) with mapi id 14.03.0136.001; Thu, 11 Jul 2013 11:19:49 +0000 From: "Dijk, Esko" To: Carsten Bormann Thread-Topic: [core] #332: Remove advice for use of blockwise on "/.well-known/core" ? Thread-Index: AQHOe9FJPfWauOjAAkeqVdWhuxCqAZlatsiAgAAox2CAADNLgIACrKMQ Date: Thu, 11 Jul 2013 11:19:48 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618CAA120@011-DB3MPN2-082.MGDPHG.emi.philips.com> References: <060.ecb6d7b2bd30e58cb7593a44933af6ca@trac.tools.ietf.org> <768D84B8-E67D-4D2A-B005-C93F56B8FF56@tzi.org> <031DD135F9160444ABBE3B0C36CED618C9A3C4@011-DB3MPN2-083.MGDPHG.emi.philips.com> <5C63ACF7-11C5-4703-919A-824028BA4BC5@tzi.org> In-Reply-To: <5C63ACF7-11C5-4703-919A-824028BA4BC5@tzi.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.103] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "trac+core@grenache.tools.ietf.org" , "draft-ietf-core-groupcomm@tools.ietf.org" , "core@ietf.org" Subject: Re: [core] #332: Remove advice for use of blockwise on "/.well-known/core" ? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 11:21:00 -0000 > Well, it is not a protocol requirement, it is just a real-world requireme= nt. > ... > groupcomm mentioning it is exactly the right thing, I'd say. In this light, we should add an implementation guidance for this case in gr= oupcomm, then. Something like "... For this reason a CoAP client sending a multicast CoAP request to /= .well-known/core SHOULD support core-block; with the exception case being n= etworks where it is a-priori (by design) known that no CoAP server would ev= er respond with blockwise CoAP to a request to /.well-known/core." We could even detail support of core-block to mean support of Block2 option= in a response to a GET request. (In case partial adherence to the core-blo= ck spec is allowed!) thanks Esko -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org] Sent: Monday, July 08, 2013 20:02 To: Dijk, Esko Cc: trac+core@grenache.tools.ietf.org; draft-ietf-core-groupcomm@tools.ietf= .org; core@ietf.org Subject: Re: [core] #332: Remove advice for use of blockwise on "/.well-kno= wn/core" ? On Jul 8, 2013, at 17:07, "Dijk, Esko" wrote: >> because clients that want to make use of /.well-known/core should do cor= e-block (whether they use multicast or not). > That is a possible solution indeed, but then this requirement has to be r= ecorded somewhere in core-coap isn't it? Well, it is not a protocol requirement, it is just a real-world requirement= . If it doesn't fit, you have to do something. core-coap does mention "... move to block-wise transfers [I-D.ietf-core-block] when approaching three- digit message sizes." > (Or should that be in RFC 6690? RFC 6690 is pretty much oblivious to how the information is transported. (It does actually mention multicast, though.) > Or core-groupcomm -> but that is informational so does not solve it.) groupcomm mentioning it is exactly the right thing, I'd say. > Otherwise many implementers will do the 'unwise thing' and interoperabil= ity suffers. In interops so far, few implementations have had problems with this (with u= nicast, though). (I expect the "culture" of using CoAP to be set in interops as much as by t= he standard.) > And secondly, core-block will have to be updated (I would expect) with a = description on how to use it together with IP multicast. That does not have= to be defined for all use cases, only for the use case of multicast GET fo= r a resource where some servers decide to return only the first block. Good point. -block is currently mute about continuing forward using unicast requests fr= om a response to a multicast request. > Or maybe this explanation can go into core-groupcomm? Possibly as well. Gr=FC=DFe, Carsten ________________________________ 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 ietf-secretariat-reply@ietf.org Thu Jul 11 10:15:09 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6155D21F9B0E for ; Thu, 11 Jul 2013 10:15:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GpWs-Do0Qmzq; Thu, 11 Jul 2013 10:15:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A07321F9F6D; Thu, 11 Jul 2013 10:15:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: core-chairs@tools.ietf.org, draft-ietf-core-coap@tools.ietf.org, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130711171505.4937.41733.idtracker@ietfa.amsl.com> Date: Thu, 11 Jul 2013 10:15:05 -0700 From: IETF Secretariat Subject: [core] ID Tracker State Update Notice: X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 17:15:09 -0000 State changed to Approved-announcement to be sent from IESG Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-core-coap/ From Akbar.Rahman@InterDigital.com Thu Jul 11 10:33:27 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3012921F9E1A for ; Thu, 11 Jul 2013 10:33:27 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Ocx8kYyWZMb for ; Thu, 11 Jul 2013 10:33:20 -0700 (PDT) Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 7F8A921F9EAE for ; Thu, 11 Jul 2013 10:33:20 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 11 Jul 2013 13:33:19 -0400 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: Thu, 11 Jul 2013 13:33:19 -0400 Message-ID: In-Reply-To: <031DD135F9160444ABBE3B0C36CED618CAA120@011-DB3MPN2-082.MGDPHG.emi.philips.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] #332: Remove advice for use of blockwise on "/.well-known/core" ? Thread-Index: AQHOe9FJPfWauOjAAkeqVdWhuxCqAZlatsiAgAAox2CAADNLgIACrKMQgAIAr0A= References: <060.ecb6d7b2bd30e58cb7593a44933af6ca@trac.tools.ietf.org> <768D84B8-E67D-4D2A-B005-C93F56B8FF56@tzi.org> <031DD135F9160444ABBE3B0C36CED618C9A3C4@011-DB3MPN2-083.MGDPHG.emi.philips.com> <5C63ACF7-11C5-4703-919A-824028BA4BC5@tzi.org> <031DD135F9160444ABBE3B0C36CED618CAA120@011-DB3MPN2-082.MGDPHG.emi.philips.com> From: "Rahman, Akbar" To: "Dijk, Esko" X-OriginalArrivalTime: 11 Jul 2013 17:33:19.0610 (UTC) FILETIME=[BBF96DA0:01CE7E5C] Cc: trac+core@grenache.tools.ietf.org, draft-ietf-core-groupcomm@tools.ietf.org, core@ietf.org Subject: Re: [core] #332: Remove advice for use of blockwise on "/.well-known/core" ? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 17:33:27 -0000 Hi Esko, My vote would be just to add the first part of your suggestion to = Groupcomm I-D. That is: "... For this reason a CoAP client sending a multicast CoAP request to = /.well-known/core SHOULD support core-block" The other parts of your text below are exceptions and I don't think we = need to be exhaustive in covering these (i.e. I guess there are others = as well that people can always think up and we cannot cover them all). Best Regards, Akbar -----Original Message----- From: Dijk, Esko [mailto:esko.dijk@philips.com]=20 Sent: Thursday, July 11, 2013 7:20 AM To: Carsten Bormann Cc: trac+core@grenache.tools.ietf.org; = draft-ietf-core-groupcomm@tools.ietf.org; core@ietf.org Subject: RE: [core] #332: Remove advice for use of blockwise on = "/.well-known/core" ? > Well, it is not a protocol requirement, it is just a real-world = requirement. > ... > groupcomm mentioning it is exactly the right thing, I'd say. In this light, we should add an implementation guidance for this case in = groupcomm, then. Something like "... For this reason a CoAP client sending a multicast CoAP request = to /.well-known/core SHOULD support core-block; with the exception case = being networks where it is a-priori (by design) known that no CoAP = server would ever respond with blockwise CoAP to a request to = /.well-known/core." We could even detail support of core-block to mean support of Block2 = option in a response to a GET request. (In case partial adherence to the = core-block spec is allowed!) thanks Esko -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org] Sent: Monday, July 08, 2013 20:02 To: Dijk, Esko Cc: trac+core@grenache.tools.ietf.org; = draft-ietf-core-groupcomm@tools.ietf.org; core@ietf.org Subject: Re: [core] #332: Remove advice for use of blockwise on = "/.well-known/core" ? On Jul 8, 2013, at 17:07, "Dijk, Esko" wrote: >> because clients that want to make use of /.well-known/core should do = core-block (whether they use multicast or not). > That is a possible solution indeed, but then this requirement has to = be recorded somewhere in core-coap isn't it? Well, it is not a protocol requirement, it is just a real-world = requirement. If it doesn't fit, you have to do something. core-coap does mention "... move to block-wise transfers [I-D.ietf-core-block] when approaching three- digit message sizes." > (Or should that be in RFC 6690? RFC 6690 is pretty much oblivious to how the information is transported. (It does actually mention multicast, though.) > Or core-groupcomm -> but that is informational so does not solve it.) groupcomm mentioning it is exactly the right thing, I'd say. > Otherwise many implementers will do the 'unwise thing' and = interoperability suffers. In interops so far, few implementations have had problems with this = (with unicast, though). (I expect the "culture" of using CoAP to be set in interops as much as = by the standard.) > And secondly, core-block will have to be updated (I would expect) with = a description on how to use it together with IP multicast. That does not = have to be defined for all use cases, only for the use case of multicast = GET for a resource where some servers decide to return only the first = block. Good point. -block is currently mute about continuing forward using unicast requests = from a response to a multicast request. > Or maybe this explanation can go into core-groupcomm? Possibly as well. Gr=FC=DFe, Carsten ________________________________ 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. From barryleiba.mailing.lists@gmail.com Thu Jul 11 10:37:27 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F24F21F9A95 for ; Thu, 11 Jul 2013 10:37:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.987 X-Spam-Level: X-Spam-Status: No, score=-101.987 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uyvVYwtMthKq for ; Thu, 11 Jul 2013 10:37:26 -0700 (PDT) Received: from mail-vb0-x231.google.com (mail-vb0-x231.google.com [IPv6:2607:f8b0:400c:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 320C121F91CC for ; Thu, 11 Jul 2013 10:37:17 -0700 (PDT) Received: by mail-vb0-f49.google.com with SMTP id 12so774935vbf.8 for ; Thu, 11 Jul 2013 10:37:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=fQbaadZ8X91iy8GV3D/JWwi2oBnTnc48kCZmXadJAL4=; b=SPW6xqIJv9oDQz114tC4Zc08aUUjtkzTTaIwQH0nclbcBxrLbrEESfJbUZPqOjOph7 gu+qTebUXXNFSM3M4G2h92ldW8Kstrk36f/RKwn3gdL5xPerRmmEVtAovBYNib8OFHMf JjIUDSxanrNg+ky3aql5JC94xQCBMR38nrh9e/P6OT6h9ldND0zh4qByzmnp47wppe8k 9DjDfkbbZtw1ZzEVar5Jb/J2tlNvZlmquhDAq73S6NitAvIdVfmaQN1OATCGn4rs8i5R tHpGf2L6BVBrbZ8xwRQbVUbWnKt1HP2DptGSqK2atfUvpWcQoUICtCfgtNvZhnONoU/x 5Ltw== MIME-Version: 1.0 X-Received: by 10.220.181.69 with SMTP id bx5mr5145348vcb.71.1373564236516; Thu, 11 Jul 2013 10:37:16 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.137.227 with HTTP; Thu, 11 Jul 2013 10:37:16 -0700 (PDT) Date: Thu, 11 Jul 2013 13:37:16 -0400 X-Google-Sender-Auth: K-7lZj8ogEdwpfdGyR1BmT2X6IE Message-ID: From: Barry Leiba To: "core@ietf.org WG" Content-Type: text/plain; charset=ISO-8859-1 Cc: "draft-ietf-core-coap@tools.ietf.org" , core-chairs@tools.ietf.org Subject: [core] draft-ietf-core-coap-18 was approved today X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 17:37:27 -0000 As you can see: > State changed to Approved-announcement to be sent from IESG Evaluation > ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-core-coap/ ...the coap document was approved on today's IESG telechat. The official Protocol Action announcement should be posted to ietf-announce early next week. Thanks very much, everyone, for the good work on this document and for being responsive in addressing the IESG comments. If you look at the ballot: https://datatracker.ietf.org/doc/draft-ietf-core-coap/ballot/ ...you'll see that the document has, in addition to verbal praise for it in the comments, *eight* "Yes" ballots from the IESG (and seven "No Objection"). That is extremely unusual -- only one "Yes" is required, most documents are approved with one or two "Yes" and fourteen or thirteen "No Objection", and more than three or four "Yes" ballots is rare. That's by way of saying that the IESG as a whole considers this to be both an important and well done document. The working group and the editors should be proud of it. Barry, Applications AD From Akbar.Rahman@InterDigital.com Thu Jul 11 21:13:17 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 731EB11E80F7 for ; Thu, 11 Jul 2013 21:13:17 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CCiaIZ83RUaU for ; Thu, 11 Jul 2013 21:13:13 -0700 (PDT) Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 353B411E80A2 for ; Thu, 11 Jul 2013 21:13:13 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 12 Jul 2013 00:13:12 -0400 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: Fri, 12 Jul 2013 00:13:05 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] draft-ietf-core-coap-18 was approved today Thread-Index: Ac5+XYdoDS7G34bnSgm7DALN0GxMSgAWDIcQ References: From: "Rahman, Akbar" To: "Barry Leiba" , X-OriginalArrivalTime: 12 Jul 2013 04:13:12.0098 (UTC) FILETIME=[1FAE3020:01CE7EB6] Subject: Re: [core] draft-ietf-core-coap-18 was approved today X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 04:13:17 -0000 That's really good news! Good job by the Editors (Zach, Carsten, Klaus). Carsten - Does that mean you are going to buy us all a beer/coffee in Berlin after the WG session? :) Best Regards, Akbar -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Barry Leiba Sent: Thursday, July 11, 2013 1:37 PM To: core@ietf.org WG Cc: draft-ietf-core-coap@tools.ietf.org; core-chairs@tools.ietf.org Subject: [core] draft-ietf-core-coap-18 was approved today As you can see: > State changed to Approved-announcement to be sent from IESG Evaluation > ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-core-coap/ ...the coap document was approved on today's IESG telechat. The official Protocol Action announcement should be posted to ietf-announce early next week. Thanks very much, everyone, for the good work on this document and for being responsive in addressing the IESG comments. If you look at the ballot: https://datatracker.ietf.org/doc/draft-ietf-core-coap/ballot/ ...you'll see that the document has, in addition to verbal praise for it in the comments, *eight* "Yes" ballots from the IESG (and seven "No Objection"). That is extremely unusual -- only one "Yes" is required, most documents are approved with one or two "Yes" and fourteen or thirteen "No Objection", and more than three or four "Yes" ballots is rare. That's by way of saying that the IESG as a whole considers this to be both an important and well done document. The working group and the editors should be proud of it. Barry, Applications AD _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From rick.bullotta@thingworx.com Fri Jul 12 03:05:15 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD9B221F9D9C for ; Fri, 12 Jul 2013 03:05:15 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zcf7xUl+563h for ; Fri, 12 Jul 2013 03:05:11 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0206.outbound.protection.outlook.com [207.46.163.206]) by ietfa.amsl.com (Postfix) with ESMTP id 9A51D21F9DB8 for ; Fri, 12 Jul 2013 03:05:09 -0700 (PDT) Received: from BLUPR06MB001.namprd06.prod.outlook.com (10.242.190.139) by BLUPR06MB003.namprd06.prod.outlook.com (10.242.190.149) with Microsoft SMTP Server (TLS) id 15.0.702.21; Fri, 12 Jul 2013 10:00:56 +0000 Received: from BLUPR06MB001.namprd06.prod.outlook.com ([169.254.1.125]) by BLUPR06MB001.namprd06.prod.outlook.com ([169.254.1.125]) with mapi id 15.00.0702.005; Fri, 12 Jul 2013 10:00:56 +0000 From: Rick Bullotta To: "Rahman, Akbar" Thread-Topic: [core] draft-ietf-core-coap-18 was approved today Thread-Index: Ac5+XYdoDS7G34bnSgm7DALN0GxMSgAWDIcQAAw+hsI= Date: Fri, 12 Jul 2013 10:00:56 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.59.9.6] x-forefront-prvs: 0905A6B2C7 x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(189002)(51704005)(13464003)(24454002)(54164003)(377454003)(76796001)(69226001)(54356001)(33656001)(77096001)(74662001)(16406001)(56816003)(15202345003)(63696002)(47446002)(56776001)(74502001)(59766001)(77982001)(65816001)(76786001)(47736001)(31966008)(49866001)(76482001)(81542001)(4396001)(46102001)(54316002)(80022001)(81342001)(74366001)(53806001)(74706001)(79102001)(83072001)(51856001)(74876001)(47976001)(36756003)(66066001)(50986001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR06MB003; H:BLUPR06MB001.namprd06.prod.outlook.com; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: thingworx.com Cc: Barry Leiba , "core@ietf.org" Subject: Re: [core] draft-ietf-core-coap-18 was approved today X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 10:05:15 -0000 Congratulations and thanks to all of you for your hard work! Rick ThingWorx On Jul 12, 2013, at 12:13 AM, "Rahman, Akbar" wrote: > That's really good news! Good job by the Editors (Zach, Carsten, > Klaus). >=20 > Carsten - Does that mean you are going to buy us all a beer/coffee in > Berlin after the WG session? :) >=20 >=20 >=20 > Best Regards, >=20 >=20 > Akbar >=20 > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of > Barry Leiba > Sent: Thursday, July 11, 2013 1:37 PM > To: core@ietf.org WG > Cc: draft-ietf-core-coap@tools.ietf.org; core-chairs@tools.ietf.org > Subject: [core] draft-ietf-core-coap-18 was approved today >=20 > As you can see: >=20 >> State changed to Approved-announcement to be sent from IESG Evaluation >=20 >> ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-core-coap/ >=20 > ...the coap document was approved on today's IESG telechat. The > official Protocol Action announcement should be posted to ietf-announce > early next week. Thanks very much, everyone, for the good work on this > document and for being responsive in addressing the IESG comments. >=20 > If you look at the ballot: > https://datatracker.ietf.org/doc/draft-ietf-core-coap/ballot/ > ...you'll see that the document has, in addition to verbal praise for it > in the comments, *eight* "Yes" ballots from the IESG (and seven "No > Objection"). That is extremely unusual -- only one "Yes" is required, > most documents are approved with one or two "Yes" and fourteen or > thirteen "No Objection", and more than three or four "Yes" ballots is > rare. >=20 > That's by way of saying that the IESG as a whole considers this to be > both an important and well done document. The working group and the > editors should be proud of it. >=20 > Barry, Applications AD > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From internet-drafts@ietf.org Sun Jul 14 08:41:09 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA0D821F9929; Sun, 14 Jul 2013 08:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qf7pATlTLwm1; Sun, 14 Jul 2013 08:41:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5064821F9963; Sun, 14 Jul 2013 08:41:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130714154109.355.51016.idtracker@ietfa.amsl.com> Date: Sun, 14 Jul 2013 08:41:09 -0700 Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-groupcomm-11.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 15:41:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Constrained RESTful Environments Working = Group of the IETF. Title : Group Communication for CoAP Author(s) : Akbar Rahman Esko Dijk Filename : draft-ietf-core-groupcomm-11.txt Pages : 38 Date : 2013-07-14 Abstract: CoAP is a RESTful transfer protocol for constrained devices and constrained networks. It is anticipated that constrained devices will often naturally operate in groups (e.g., in a building automation scenario all lights in a given room may need to be switched on/off as a group). This document provides guidance for how the CoAP protocol should be used in a group communication context. An approach for using CoAP on top of IP multicast is detailed. Also, various use cases and corresponding protocol flows are provided to illustrate important concepts. Finally, guidance is provided for deployment in various network topologies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-groupcomm There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-core-groupcomm-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-groupcomm-11 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Akbar.Rahman@InterDigital.com Sun Jul 14 08:46:54 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76C9821F9C0B for ; Sun, 14 Jul 2013 08:46:54 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QpKque3BqVmo for ; Sun, 14 Jul 2013 08:46:50 -0700 (PDT) Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 3433D21F99A2 for ; Sun, 14 Jul 2013 08:46:50 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 14 Jul 2013 11:46:49 -0400 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: Sun, 14 Jul 2013 11:46:47 -0400 Message-ID: In-Reply-To: <20130714154109.355.51016.idtracker@ietfa.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] I-D Action: draft-ietf-core-groupcomm-11.txt Thread-Index: Ac6AqMsCbwP20RxoRBKHCINV2dY/LQAAAk0Q References: <20130714154109.355.51016.idtracker@ietfa.amsl.com> From: "Rahman, Akbar" To: X-OriginalArrivalTime: 14 Jul 2013 15:46:49.0102 (UTC) FILETIME=[5A2C8AE0:01CE80A9] Subject: Re: [core] I-D Action: draft-ietf-core-groupcomm-11.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 15:46:54 -0000 Hi, We have updated the Groupcomm I-D to address ticket #332 as follows: o Added text to section 3.8 (Congestion Control) to clarify that a "CoAP client sending a multicast CoAP request to /.well-known/core SHOULD support core-block" (#332). Best Regards, Akbar & Esko -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Sunday, July 14, 2013 11:41 AM To: i-d-announce@ietf.org Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-groupcomm-11.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments Working Group of the IETF. Title : Group Communication for CoAP Author(s) : Akbar Rahman Esko Dijk Filename : draft-ietf-core-groupcomm-11.txt Pages : 38 Date : 2013-07-14 Abstract: CoAP is a RESTful transfer protocol for constrained devices and constrained networks. It is anticipated that constrained devices will often naturally operate in groups (e.g., in a building automation scenario all lights in a given room may need to be switched on/off as a group). This document provides guidance for how the CoAP protocol should be used in a group communication context. An approach for using CoAP on top of IP multicast is detailed. Also, various use cases and corresponding protocol flows are provided to illustrate important concepts. Finally, guidance is provided for deployment in various network topologies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-groupcomm There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-core-groupcomm-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-groupcomm-11 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From trac+core@trac.tools.ietf.org Mon Jul 15 00:58:02 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 072AC21F93F8 for ; Mon, 15 Jul 2013 00:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UaWdCvNXPTug for ; Mon, 15 Jul 2013 00:58:01 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 1A3B321F84AA for ; Mon, 15 Jul 2013 00:56:12 -0700 (PDT) Received: from localhost ([127.0.0.1]:46990 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UyddH-0000H0-0G; Mon, 15 Jul 2013 09:55:43 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-groupcomm@tools.ietf.org, cabo@tzi.org, esko.dijk@philips.com X-Trac-Project: core Date: Mon, 15 Jul 2013 07:55:42 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/332#comment:5 Message-ID: <075.4eeb4e1cc62e0a89f0cbd218675252e8@trac.tools.ietf.org> References: <060.ecb6d7b2bd30e58cb7593a44933af6ca@trac.tools.ietf.org> X-Trac-Ticket-ID: 332 In-Reply-To: <060.ecb6d7b2bd30e58cb7593a44933af6ca@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@tools.ietf.org, cabo@tzi.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, esko.dijk@philips.com Resent-Message-Id: <20130715075613.1A3B321F84AA@ietfa.amsl.com> Resent-Date: Mon, 15 Jul 2013 00:56:12 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #332: Remove advice for use of blockwise on "/.well-known/core" ? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 07:58:02 -0000 #332: Remove advice for use of blockwise on "/.well-known/core" ? Changes (by esko.dijk@philips.com): * status: new => closed * resolution: => fixed Comment: Resolved in groupcomm-11 by the text: "CoAP client sending a multicast CoAP request to /.well-known/core SHOULD support core-block." -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | groupcomm@tools.ietf.org Type: protocol | Status: closed defect | Milestone: Priority: major | Version: Component: groupcomm | Resolution: fixed Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From esko.dijk@philips.com Mon Jul 15 03:49:30 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B601721F9FE5 for ; Mon, 15 Jul 2013 03:49:30 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rNBJQoPNVQUF for ; Mon, 15 Jul 2013 03:49:25 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id 83EBF21F940D for ; Mon, 15 Jul 2013 03:49:25 -0700 (PDT) Received: from mail80-ch1-R.bigfish.com (10.43.68.252) by CH1EHSOBE017.bigfish.com (10.43.70.67) with Microsoft SMTP Server id 14.1.225.22; Mon, 15 Jul 2013 10:49:24 +0000 Received: from mail80-ch1 (localhost [127.0.0.1]) by mail80-ch1-R.bigfish.com (Postfix) with ESMTP id 4A0D73400BD; Mon, 15 Jul 2013 10:49:24 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -30 X-BigFish: VPS-30(zz15d6Oc89bh936eI542I9251I168aJ217bIdd85kzz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1033IL8275dhz2dh2a8h668h839h947hd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1155h) Received: from mail80-ch1 (localhost.localdomain [127.0.0.1]) by mail80-ch1 (MessageSwitch) id 1373885362468598_11006; Mon, 15 Jul 2013 10:49:22 +0000 (UTC) Received: from CH1EHSMHS025.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.244]) by mail80-ch1.bigfish.com (Postfix) with ESMTP id 634706004A; Mon, 15 Jul 2013 10:49:22 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CH1EHSMHS025.bigfish.com (10.43.70.25) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 15 Jul 2013 10:49:22 +0000 Received: from 011-DB3MMR1-014.MGDPHG.emi.philips.com (10.128.28.98) by 011-DB3MMR1-005.MGDPHG.emi.philips.com (10.128.28.55) with Microsoft SMTP Server (TLS) id 14.3.136.1; Mon, 15 Jul 2013 10:48:24 +0000 Received: from 011-DB3MPN2-082.MGDPHG.emi.philips.com ([169.254.2.231]) by 011-DB3MMR1-014.MGDPHG.emi.philips.com ([10.128.28.98]) with mapi id 14.03.0136.001; Mon, 15 Jul 2013 10:48:24 +0000 From: "Dijk, Esko" To: Carsten Bormann , "Andrew McGregor (andrewmcgr@google.com)" Thread-Topic: Milestones changed for core WG / new milestones needed? Thread-Index: Ac6BSGFBsLVEkyvxRMi0kkog4GLCkA== Date: Mon, 15 Jul 2013 10:48:24 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618CAF81A@011-DB3MPN2-082.MGDPHG.emi.philips.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.103] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "core@ietf.org \(core@ietf.org\)" Subject: Re: [core] Milestones changed for core WG / new milestones needed? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 10:49:30 -0000 Seeing the updated milestones, I wonder whether the WG needs milestones rel= ated to the following WG drafts: draft-ietf-core-http-mapping draft-ietf-core-interfaces draft-ietf-core-links-json draft-ietf-core-resource-directory since these are not related to current 'open' milestones. In addition, there is the open topic of "sleepy devices" which is in the ch= arter (for which there's no WG document yet). Could we add this topic to th= e milestones also? (Or do we need to go through some topic-selection process, to identify what= are other possible topics for the WG and then select based on people's pre= ferences?) regards, Esko -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Car= sten Bormann Sent: Tuesday, May 21, 2013 01:47 To: core@ietf.org (core@ietf.org) Subject: Re: [core] Milestones changed for core WG Since the timing of this E-Mail may be confusing, a little bit of explanati= on: I just tried out the new datatracker functionality that now allows the WG c= hairs to tick off charter milestones via the Web interface. Of course, the submission (and thus fulfillment of the milestone) already h= appened on 2013-03-13; we just never ticked off the item in the charter. Gr=FC=DFe, Carsten _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ________________________________ 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 girum.ketema@intec.ugent.be Mon Jul 15 06:13:37 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 139AC21F9B07 for ; Mon, 15 Jul 2013 06:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fW2+SVU12F9P for ; Mon, 15 Jul 2013 06:13:32 -0700 (PDT) Received: from smtp3.ugent.be (smtp3.ugent.be [157.193.49.127]) by ietfa.amsl.com (Postfix) with ESMTP id 54E1E21F9ADA for ; Mon, 15 Jul 2013 06:13:32 -0700 (PDT) Received: from localhost (mcheck2.ugent.be [157.193.49.249]) by smtp3.ugent.be (Postfix) with ESMTP id 4E397C262 for ; Mon, 15 Jul 2013 15:13:31 +0200 (CEST) X-Virus-Scanned: by UGent DICT Received: from smtp3.ugent.be ([157.193.49.127]) by localhost (mcheck2.UGent.be [157.193.43.11]) (amavisd-new, port 10024) with ESMTP id g1HOzDG4-2AL for ; Mon, 15 Jul 2013 15:13:30 +0200 (CEST) Received: from mail2.intec.ugent.be (mail2.intec.ugent.be [157.193.214.245]) by smtp3.ugent.be (Postfix) with ESMTP id C11A3C296 for ; Mon, 15 Jul 2013 15:13:30 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail2.intec.ugent.be (Postfix) with ESMTP id E13D622; Mon, 15 Jul 2013 15:13:30 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at intec.ugent.be Received: from mail2.intec.ugent.be ([127.0.0.1]) by localhost (mail2.intec.ugent.be [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O42QDg5wODLn; Mon, 15 Jul 2013 15:13:30 +0200 (CEST) Received: from [157.193.135.192] (dhcp-zdpt-192.intec.ugent.be [157.193.135.192]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gketema) by mail2.intec.ugent.be (Postfix) with ESMTPSA id C866321; Mon, 15 Jul 2013 15:13:30 +0200 (CEST) Message-ID: <51E3F57A.8070301@intec.ugent.be> Date: Mon, 15 Jul 2013 15:13:30 +0200 From: Girum Ketema User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: core@ietf.org Content-Type: multipart/alternative; boundary="------------070101050905040302030502" X-Miltered: at jchkm1 with ID 51E3F57A.005 by Joe's j-chkmail (http://helpdesk.ugent.be/email/)! X-j-chkmail-Enveloppe: 51E3F57A.005 from mail2.intec.ugent.be/mail2.intec.ugent.be/157.193.214.245/mail2.intec.ugent.be/ X-j-chkmail-Score: MSGID : 51E3F57A.005 on smtp3.ugent.be : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Subject: [core] Conditional Observation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 13:13:37 -0000 This is a multi-part message in MIME format. --------------070101050905040302030502 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear All, Conditional Observation is an extension to CoAP Observe and is described in [ID: draft-li-conditional-observe-04]. According to this Internet draft, clients may specify notification criteria when they make an observation request. As a result, the server only sends state changes that are of interest to the client, avoiding unnecessary packet transmissions. Details of conditional observation, its implementation, experimental results, and mathematical analysis are discussed in the journal paper "Facilitating the creation of IoT applications through conditional observations in CoAP" (http://jwcn.eurasipjournals.com/content/2013/1/177). The implementation code, which is the extension of Erbium - the CoAP implementation of Contiki, can be downloaded from github ( https://github.com/girumk/contiki/tree/condobs). With Best Regards, Girum ======================================================= Girum Ketema Teklemariam Researcher Department of Information Technology Internet Based Communication Networks and Services (IBCN) Ghent University - iMinds Gaston Crommenlaan 8 (Box 201) B-9050 Ghent, Belgium T: +32 9 33 14946 T: +32 9 33 14900 (Secr.) F: +32 9 33 14899 E: girum.ketema@intec.ugent.be W:http://www.ibcn.intec.UGent.be ;http://www.iMinds.be ======================================================= --------------070101050905040302030502 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear All,

Conditional Observation is an extension to CoAP Observe and is described in [ID: draft-li-conditional-observe-04]. According to this Internet draft, clients may specify notification criteria when they make an observation request. As a result, the server only sends state changes that are of interest to the client, avoiding unnecessary packet transmissions. Details of conditional observation, its implementation, experimental results, and mathematical analysis are discussed in the journal paper "Facilitating the creation of IoT applications through conditional observations in CoAP" (http://jwcn.eurasipjournals.com/content/2013/1/177).

The implementation code, which is the extension of Erbium - the CoAP implementation of Contiki, can be downloaded from github ( https://github.com/girumk/contiki/tree/condobs).

With Best Regards,


Girum

=======================================================
Girum Ketema Teklemariam
Researcher

Department of Information Technology
Internet Based Communication Networks and Services  (IBCN)
Ghent University - iMinds
Gaston Crommenlaan 8 (Box 201)
B-9050 Ghent, Belgium

T: +32 9 33 14946
T: +32 9 33 14900 (Secr.)   
F: +32 9 33 14899
E: girum.ketema@intec.ugent.be
W:http://www.ibcn.intec.UGent.be  ;http://www.iMinds.be
=======================================================
--------------070101050905040302030502-- From jari.arkko@piuha.net Mon Jul 15 08:31:36 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB7811E8100 for ; Mon, 15 Jul 2013 08:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lasP2BpCMx6C for ; Mon, 15 Jul 2013 08:31:32 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 20A4811E80FB for ; Mon, 15 Jul 2013 08:31:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id A97032CC51 for ; Mon, 15 Jul 2013 18:31:30 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id du_awQjxvQxb for ; Mon, 15 Jul 2013 18:31:30 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 7791A2CC3C for ; Mon, 15 Jul 2013 18:31:29 +0300 (EEST) From: Jari Arkko Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <591574B1-BC5A-41EB-8386-FBE561008A3A@piuha.net> Date: Mon, 15 Jul 2013 17:31:28 +0200 To: core@ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [core] blog article on Web of Things X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 15:31:36 -0000 FYI - I wrote an article about the Web of Things, i.e., using the web = technologies to build Internet of Things applications and devices. = Here's the blog: http://www.ietf.org/blog/2013/07/the-web-of-things/ Thoughts, comments? I suppose the people in this working group believe = in this model, if anyone :-) But I'd be interested also in thoughts on = how we can make our technologies (such as CoAP as a part of the Web of = Things framework) more widely known and understood. I personally believe = it is very exciting technology, and worth more attention... Jari From d.sturek@att.net Mon Jul 15 09:41:38 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A10E11E8113 for ; Mon, 15 Jul 2013 09:41:38 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNTh1wXE894R for ; Mon, 15 Jul 2013 09:41:33 -0700 (PDT) Received: from nm12-vm4.access.bullet.mail.gq1.yahoo.com (nm12-vm4.access.bullet.mail.gq1.yahoo.com [216.39.63.100]) by ietfa.amsl.com (Postfix) with ESMTP id 2A3A211E8108 for ; Mon, 15 Jul 2013 09:41:26 -0700 (PDT) Received: from [216.39.60.175] by nm12.access.bullet.mail.gq1.yahoo.com with NNFMP; 15 Jul 2013 16:41:25 -0000 Received: from [98.138.84.173] by tm11.access.bullet.mail.gq1.yahoo.com with NNFMP; 15 Jul 2013 16:41:25 -0000 Received: from [127.0.0.1] by smtp107.sbc.mail.ne1.yahoo.com with NNFMP; 15 Jul 2013 16:41:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1373906485; bh=LvRbPbTTYVDhLjC/W1/c+iqPVKG92Etf+CEbdJVg07M=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=AQ425S7m4Qam+oM6R7I/ZkT7uZhLRHiuADg694743bKyU1krGjOGu4PH0ZlP06GMiOLQ+42msb+ownC1etR4GBP8gP7ueDMgfIrOQyAiOQpEZ2TrHuGM9GVEoPuC16HJL0wuXIvuimviOO4aOb8z+OFPCu3zS5kzirxeAvcY72o= X-Yahoo-Newman-Id: 448090.96913.bm@smtp107.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 5CeyRyAVM1lKXzah5hrbGG.2ipRCpAF0wOkdKsW7rqNV5O. 79qo9ziMqVY9iF7AgVWam9KtBBABN2L3aiiTHWnnY.Q4KrMbxkAv3Fm6w3jY EA.K8zVKfLzNg.RwNRbudb1xEEX3dfOIX8lTvWRB8JjUdkpfTNgsuqYnIWoz dqCe3G86GWDFYvg0kfL4vnlb5y6NuTDO8B4Vtg7HkWtyge7kTcGsPwiIHmC6 VbE5FvH7p3SUon92R7R7ChKrWjNf46aBrfGL3rYX519N6xCWFk6uGDpjbvF9 5nezttuJUF4XgMImOC5VAxJnOlG7grz9E.6S.SjhzyKVyCY8Dk7pQMc4qgiL q1oxHjSqqkIjtgotMMF_DsWHy9g8AaPpbwb.38NfI2LT_CbFMUi.s77npqhy 8toiveon56Rln2kfwJ3PH7lzCNpwVhUYEiJcfuFLOtVpje6O2c1KaleuVsHq tSazY0zzjF61fpFEzVd1Xn.xDwKoNqa5yABiAlulDgzVNl2M3PtHyvEhVUHe seTugsyiUZYKj4EZoig-- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-Rocket-Received: from [10.0.0.4] (d.sturek@67.124.200.36 with login) by smtp107.sbc.mail.ne1.yahoo.com with SMTP; 15 Jul 2013 09:41:25 -0700 PDT User-Agent: Microsoft-MacOutlook/14.3.5.130515 Date: Mon, 15 Jul 2013 09:41:22 -0700 From: Don Sturek To: Jari Arkko , Message-ID: Thread-Topic: [core] blog article on Web of Things In-Reply-To: <591574B1-BC5A-41EB-8386-FBE561008A3A@piuha.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [core] blog article on Web of Things X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 16:41:38 -0000 Hi Jari, Many great points in your blog. I especially agree on having outside commercial groups (eg, ZigBee, Z-Wave, IPSO) creating profiles using IETF standards and drafts (including Core). Any thoughts on how these commercial standards groups can report on missing (needed) features or additions within the IETF? One of the biggest challenges is knowing what group in IETF should be the target of such requests (or even if a BOF is needed if there is not group). I can see some additional features being needed for a full Core deployment (part of which can be addressed in the DICE group but I am also thinking of work on forwarding to multicast groups where message distribution does not use flooding.....) Don On 7/15/13 8:31 AM, "Jari Arkko" wrote: >FYI - I wrote an article about the Web of Things, i.e., using the web >technologies to build Internet of Things applications and devices. Here's >the blog: > >http://www.ietf.org/blog/2013/07/the-web-of-things/ > >Thoughts, comments? I suppose the people in this working group believe in >this model, if anyone :-) But I'd be interested also in thoughts on how >we can make our technologies (such as CoAP as a part of the Web of Things >framework) more widely known and understood. I personally believe it is >very exciting technology, and worth more attention... > >Jari > >_______________________________________________ >core mailing list >core@ietf.org >https://www.ietf.org/mailman/listinfo/core From ietf-secretariat-reply@ietf.org Mon Jul 15 09:51:11 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 307BC21E80E0 for ; Mon, 15 Jul 2013 09:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AqkvyUd213Ea; Mon, 15 Jul 2013 09:51:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D25AD21E8129; Mon, 15 Jul 2013 09:50:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: core-chairs@tools.ietf.org, draft-ietf-core-coap@tools.ietf.org, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130715165035.31594.81489.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 09:50:35 -0700 From: IETF Secretariat Subject: [core] ID Tracker State Update Notice: X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 16:51:11 -0000 IESG has approved the document and state has been changed to Approved-annou= ncement sent ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-core-coap/ From iesg-secretary@ietf.org Mon Jul 15 09:51:13 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7AE621E810A; Mon, 15 Jul 2013 09:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.495 X-Spam-Level: X-Spam-Status: No, score=-102.495 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ORqtWJWUvbu3; Mon, 15 Jul 2013 09:51:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A474B21E8111; Mon, 15 Jul 2013 09:50:36 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130715165036.31594.95110.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 09:50:36 -0700 Cc: core chair , core mailing list , RFC Editor Subject: [core] Protocol Action: 'Constrained Application Protocol (CoAP)' to Proposed Standard (draft-ietf-core-coap-18.txt) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 16:51:13 -0000 The IESG has approved the following document: - 'Constrained Application Protocol (CoAP)' (draft-ietf-core-coap-18.txt) as Proposed Standard This document is the product of the Constrained RESTful Environments Working Group. The IESG contact persons are Barry Leiba and Pete Resnick. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-core-coap/ Technical Summary The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as 6LoWPAN often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine-to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP easily interfaces with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead and simplicity for constrained environments. Working Group Summary WG review has been intense, with input from many participants beyond the document authors, and particularly input from implementers. There are no particular controversies to note. Document Quality There have been multiple expert reviews, from security, applications (once a general review, and once specifically on the URI schema), and transport areas. All the reviews produced useful input, that resulted in significant changes to the specification. All review feedback is now incorporated in the final document. There are at least 15 publically disclosed implementations, both commercial and open-source. There have been several interoperability events, and a high level of interoperability has been reported from those events. Personnel Document Shepherd is Andrew McGregor Responsible Area Director is Barry Leiba Zach Shelby is suggested as the designated expert for the IANA registries defined in Sections 12.2 and 12.3. From ietf-secretariat-reply@ietf.org Mon Jul 15 11:37:58 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99BEE11E817C for ; Mon, 15 Jul 2013 11:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.457 X-Spam-Level: X-Spam-Status: No, score=-101.457 tagged_above=-999 required=5 tests=[AWL=-1.076, BAYES_00=-2.599, NO_RELAYS=-0.001, TVD_SPACE_RATIO=2.219, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DiXePWc58fIn; Mon, 15 Jul 2013 11:37:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 40D7F11E81A7; Mon, 15 Jul 2013 11:37:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: core-chairs@tools.ietf.org, draft-ietf-core-coap@tools.ietf.org, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130715183757.8088.14098.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 11:37:57 -0700 From: IETF Secretariat Subject: [core] ID Tracker State Update Notice: X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 18:37:58 -0000 IANA action state changed to In Progress ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-core-coap/ From teemu.savolainen@nokia.com Mon Jul 15 12:15:25 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B8D811E8177 for ; Mon, 15 Jul 2013 12:15:25 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5pqdWjdZ0orN for ; Mon, 15 Jul 2013 12:15:20 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id D853521E8133 for ; Mon, 15 Jul 2013 12:15:16 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (in-mx.nokia.com [10.160.244.23]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r6FJF1xN016768 for ; Mon, 15 Jul 2013 22:15:16 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.60]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 15 Jul 2013 22:15:14 +0300 Received: from 008-AM1MPN1-052.mgdnok.nokia.com ([169.254.2.249]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.02.0328.011; Mon, 15 Jul 2013 19:15:14 +0000 From: To: Thread-Topic: CoAP over WebSockets version -00 published Thread-Index: Ac6Bjxyhi6T8vJFtQm63K6kAMA7Lqw== Date: Mon, 15 Jul 2013 19:15:13 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962047E35F4@008-AM1MPN1-052.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.163.164.187] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 15 Jul 2013 19:15:14.0640 (UTC) FILETIME=[A277F500:01CE818F] X-Nokia-AV: Clean Subject: [core] CoAP over WebSockets version -00 published X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 19:15:25 -0000 Hi all, We have published draft-savolainen-core-coap-websockets-00 (http://www.ietf= .org/internet-drafts/draft-savolainen-core-coap-websockets-00.txt) that des= cribes how to retrieve and update CoAP resources using CoAP requests and re= sponses over the WebSocket Protocol. Please see the draft for details - we discuss there, for example, the scena= rios where we envision this to be useful, and technical details required fo= r handshaking WebSocket connection for CoAP and for actually transporting C= oAP messages within WebSocket framing. Of course not forgetting "coap+ws" U= RI scheme for identifying both the WebSocket endpoint and CoAP resource wit= hin that endpoint. All comments welcome. Best regards, Teemu From internet-drafts@ietf.org Mon Jul 15 12:19:15 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2B0F11E8177; Mon, 15 Jul 2013 12:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1wvw6iAw6rW4; Mon, 15 Jul 2013 12:19:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B0D211E8228; Mon, 15 Jul 2013 12:19:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130715191913.10424.80790.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 12:19:13 -0700 Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-observe-09.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 19:19:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Constrained RESTful Environments Working = Group of the IETF. Title : Observing Resources in CoAP Author(s) : Klaus Hartke Filename : draft-ietf-core-observe-09.txt Pages : 29 Date : 2013-07-15 Abstract: CoAP is a RESTful application protocol for constrained nodes and networks. The state of a resource on a CoAP server can change over time. This document specifies a simple protocol extension for CoAP that enables CoAP clients to "observe" resources, i.e., to retrieve a representation of a resource and keep this representation updated by the server over a period of time. The protocol follows a best- effort approach for sending new representations to clients, and provides eventual consistency between the state observed by each client and the actual resource state at the server. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-observe There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-core-observe-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-observe-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From gerdes@tzi.de Mon Jul 15 15:48:17 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F23DD11E822A for ; Mon, 15 Jul 2013 15:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CtZgoyK2tRE9 for ; Mon, 15 Jul 2013 15:48:12 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 0458911E815E for ; Mon, 15 Jul 2013 15:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r6FMm56J006044 for ; Tue, 16 Jul 2013 00:48:05 +0200 (CEST) Received: from [192.168.1.146] (p4FE67B52.dip0.t-ipconnect.de [79.230.123.82]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 55F24A39 for ; Tue, 16 Jul 2013 00:48:05 +0200 (CEST) Message-ID: <51E47C1E.9090201@tzi.de> Date: Tue, 16 Jul 2013 00:47:58 +0200 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: core@ietf.org References: <20130715222555.5674.65024.idtracker@ietfa.amsl.com> In-Reply-To: <20130715222555.5674.65024.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.1 X-Forwarded-Message-Id: <20130715222555.5674.65024.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [core] Fwd: I-D Action: draft-gerdes-core-dcaf-authorize-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 22:48:17 -0000 Dear all, please find below the announcement of our draft submission. The draft introduces authorization servers which conduct authentication and authorization for constrained nodes and provide keying material for the establishment of a DTLS channel using only symmetric cryptography on the constrained devices. Best regards, Steffi -------- Original Message -------- Subject: I-D Action: draft-gerdes-core-dcaf-authorize-00.txt Date: Mon, 15 Jul 2013 15:25:55 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Delegated CoAP Authorization Function (DCAF) Author(s) : Stefanie Gerdes Olaf Bergmann Carsten Bormann Filename : draft-gerdes-core-dcaf-authorize-00.txt Pages : 35 Date : 2013-07-15 Abstract: This specification defines a protocol for delegating client authentication and authorization in a constrained environment for establishing a Datagram Transport Layer Security (DTLS) channel between resource-constrained nodes. The protocol relies on DTLS to transfer authorization information and shared secrets for symmetric cryptography between entities in a constrained network. A resource- constrained node can use this protocol to delegate authentication of communication peers and management of authorization information to a trusted host with less limitations regarding processing power and memory. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-gerdes-core-dcaf-authorize There's also a htmlized version available at: http://tools.ietf.org/html/draft-gerdes-core-dcaf-authorize-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From yusuke.doi@toshiba.co.jp Mon Jul 15 17:25:29 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1370C21F9F59 for ; Mon, 15 Jul 2013 17:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.09 X-Spam-Level: X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0wgMdUxbzOQ2 for ; Mon, 15 Jul 2013 17:25:23 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id 6755721F9E28 for ; Mon, 15 Jul 2013 17:25:23 -0700 (PDT) Received: from tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp ([133.199.200.50]) by imx2.toshiba.co.jp with ESMTP id r6G0PK44015098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 16 Jul 2013 09:25:20 +0900 (JST) Received: from tsbmgw-mgw02 (localhost [127.0.0.1]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r6G0PK5W013871 for ; Tue, 16 Jul 2013 09:25:20 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw02 (JAMES SMTP Server 2.3.1) with SMTP ID 552 for ; Tue, 16 Jul 2013 09:25:20 +0900 (JST) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r6G0PKP0013865 for ; Tue, 16 Jul 2013 09:25:20 +0900 Received: (from root@localhost) by arc1.toshiba.co.jp id r6G0PKo6003348 for core@ietf.org; Tue, 16 Jul 2013 09:25:20 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id KAA03346; Tue, 16 Jul 2013 09:25:20 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id r6G0PKHB018030 for ; Tue, 16 Jul 2013 09:25:20 +0900 (JST) Received: by toshiba.co.jp id r6G0PGbK020605; Tue, 16 Jul 2013 09:25:16 +0900 (JST) Date: Tue, 16 Jul 2013 09:25:15 +0900 (JST) Message-Id: <201307160025.r6G0PGbK020605@toshiba.co.jp> To: core@ietf.org From: DOI Yusuke X-Mailer: Mew version 6.3 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Tue_Jul_16_09_25_15_2013_110)--" Content-Transfer-Encoding: 7bit Cc: Kerry Lynn Subject: [core] Fw: I-D Action: draft-doi-core-parameter-option-02.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 00:25:29 -0000 ----Next_Part(Tue_Jul_16_09_25_15_2013_110)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear core WG members, We've just submitted revised draft of core-parameter option. Updates: - Some clarification on why CoAP need this. - in short, an URI/resource may have multiple representations. - HTTP does server-side content negotiation to find a good representation on a resource. CoAP should have a way to simulate it. - Added some use cases. - Removed CT-Parameter, because it is not strictly required for server-side content negotiation. - Removed index (idx) from Accept-CT-Parameter, because Accept header is not-repeatable. Comments are welcome. I'll be in Berlin and I'm happy if I can have a chance to discuss on it (sorry for late submission). Regards, Yusuke ----Next_Part(Tue_Jul_16_09_25_15_2013_110)-- Content-Type: Message/Rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Return-Path: X-Original-To: ydoi@tsbgw.wide.toshiba.co.jp Delivered-To: ydoi@tsbgw.wide.toshiba.co.jp Received: from localhost (localhost [127.0.0.1]) by tsbgw.wide.toshiba.co.jp (Postfix) with ESMTP id 5EB2C27CB0 for ; Tue, 16 Jul 2013 08:52:04 +0900 (JST) Received: from tsbgw.wide.toshiba.co.jp ([127.0.0.1]) by localhost (tsbgw.wide.toshiba.co.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EmDHnxeRLHh5 for ; Tue, 16 Jul 2013 08:52:04 +0900 (JST) Received: from malteseout.wide.toshiba.co.jp (maltese.wide.toshiba.co.jp [202.249.10.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tsbgw.wide.toshiba.co.jp (Postfix) with ESMTPS id 36F0227CAB for ; Tue, 16 Jul 2013 08:52:04 +0900 (JST) Received: from maltesein.wide.toshiba.co.jp (maltese.wide.toshiba.co.jp [202.249.10.100]) by malteseout.wide.toshiba.co.jp (8.13.8/8.9.1) with ESMTP id r6FNq4pU023231 for ; Tue, 16 Jul 2013 08:52:04 +0900 Received: from snazzy.isl.rdc.toshiba.co.jp (snazzy.isl.rdc.toshiba.co.jp [133.196.1.10]) by maltesein.wide.toshiba.co.jp (8.13.8/8.9.1) with ESMTP id r6FNq4cZ015164 for ; Tue, 16 Jul 2013 08:52:04 +0900 Received: from spiffy21.isl.rdc.toshiba.co.jp (spiffy21.isl.rdc.toshiba.co.jp [133.196.64.158]) by snazzy.isl.rdc.toshiba.co.jp (Postfix) with ESMTP id A92F050097 for ; Tue, 16 Jul 2013 08:52:03 +0900 (JST) Received: by spiffy21.isl.rdc.toshiba.co.jp (Postfix) id 9ED0E97D71; Tue, 16 Jul 2013 08:52:03 +0900 (JST) Delivered-To: ydoi@isl.rdc.toshiba.co.jp Received: from mx11.toshiba.co.jp (mx11.toshiba.co.jp [133.199.90.141]) by spiffy21.isl.rdc.toshiba.co.jp (Postfix) with ESMTP id 7F7F697D47 for ; Tue, 16 Jul 2013 08:52:03 +0900 (JST) Received: from ivp11.toshiba.co.jp by toshiba.co.jp id r6FNq2Fw020134; Tue, 16 Jul 2013 08:52:02 +0900 (JST) Received: from imx11.toshiba.co.jp by ivp11.toshiba.co.jp with ESMTP id r6FNq2hR005230 for ; Tue, 16 Jul 2013 08:52:02 +0900 (JST) Received: from mdi1400.tsb.2iij.net (mdi1400.tsb.2iij.net [210.149.48.206]) by imx11.toshiba.co.jp with ESMTP id r6FNq1B2022325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 16 Jul 2013 08:52:01 +0900 (JST) Received: TSB TSB-MDI1400 id r6FNq1Kk009696; Tue, 16 Jul 2013 08:52:01 +0900 Received: from unknown [172.23.208.172] (EHLO mi1402.tsb.2iij.net) by mas1500.tsb.2iij.net(mxl_mta-6.15.0-6) with ESMTP id 12b84e15.0.168228.00-2339.310650.mas1500.tsb.2iij.net (envelope-from ); Tue, 16 Jul 2013 08:52:01 +0900 (JST) Authentication-Results: spf.tis.toshiba.co.jp; spf=pass smtp.mailfrom=i-d-announce-bounces@ietf.org; dkim=pass (test mode) header.i=@ietf.org; dkim-adsp=none header.From=internet-drafts@ietf.org Received: TSB TSB-MI1402 from mail.ietf.org (mail.ietf.org [12.22.58.30]) id r6FNq08Y012193; Tue, 16 Jul 2013 08:52:00 +0900 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7484821E819B; Mon, 15 Jul 2013 16:51:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1373932302; bh=Iujqc6miyHLHabBUxuussZLANKpb2EpeZ+bJoZxBZs8=; h=MIME-Version:From:To:Subject:Message-ID:Date:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=zLzgZUost7i82eEhsBnAszdMuSLwPpy+62R3dgmB5edROYCDJzGHYHdgfUVUVM+5E sJX1Tfs+aw1Nnt2Og4OiVg/YBH6GVPQSDFyEH5hnbeM/nr/snvVyMcUjmtgcwWdTIR V4lXghVBR4RvjOzNLxAEE6GtPLuRV1GRg0uAvTRU= X-Original-To: i-d-announce@ietfa.amsl.com Delivered-To: i-d-announce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E257211E8285 for ; Mon, 15 Jul 2013 16:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HfGKyNxzQxT5 for ; Mon, 15 Jul 2013 16:51:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D68CF11E826A for ; Mon, 15 Jul 2013 16:51:32 -0700 (PDT) MIME-Version: 1.0 From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-doi-core-parameter-option-02.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130715235132.18008.51295.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 16:51:32 -0700 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: Internet Draft Announcements only List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: i-d-announce-bounces@ietf.org Errors-To: i-d-announce-bounces@ietf.org X-Spam: [F=0.6000000000; STSI=0.500(-49); STSM=0.500(-49); CM=0.500; MH=0.600(2013071522); spf=0.500; SC=none] X-MAIL-FROM: X-SOURCE-IP: [172.23.208.172] X-AnalysisOut: [v=2.0 cv=O6eOSmBW c=1 sm=1 a=GU4rwa5YvsQnE15YQEkOQw==:17 a] X-AnalysisOut: [=h-pQPC3gNJUA:10 a=LSVET5z0puwA:10 a=M0ekKXdxTI4A:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=wPDyFdB5xvgA:10 a=kj9zAlcOel0A:10 a=xqWC_Br] X-AnalysisOut: [6kY4A:10 a=48vgC7mUAAAA:8 a=jGqiy6jZAAAA:8 a=-EqVfPlfihcA:] X-AnalysisOut: [10 a=HrHSf-QKzTrm6Vw5tP8A:9 a=CjuIK1q_8ugA:10 a=jM_x9b4JT8] X-AnalysisOut: [QA:10 a=lZB815dzVvQA:10] Received-SPF: Pass (mas1500.tsb.2iij.net: domain of ietf.org designates 12.22.58.30 as permitted sender) X-TM-AS-MML: No A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : CoAP Content-Type Parameter Option Author(s) : Yusuke Doi Kerry Lynn Filename : draft-doi-core-parameter-option-02.txt Pages : 9 Date : 2013-07-15 Abstract: Content-Types may have 'parameter' to make fine-grained description of contents. The CoAP Accept Content-Type Parameter Option (Accept- CT-Parameter Option) is CoAP options to add a parameter to a content type specified in CoAP Accept Options. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-doi-core-parameter-option There's also a htmlized version available at: http://tools.ietf.org/html/draft-doi-core-parameter-option-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-doi-core-parameter-option-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ----Next_Part(Tue_Jul_16_09_25_15_2013_110)---- From floris.vandenabeele@intec.ugent.be Tue Jul 16 02:00:02 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 964F311E826B for ; Tue, 16 Jul 2013 02:00:02 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ye51hHlN1tBQ for ; Tue, 16 Jul 2013 01:59:57 -0700 (PDT) Received: from smtp1.ugent.be (smtp1.ugent.be [157.193.71.182]) by ietfa.amsl.com (Postfix) with ESMTP id CF9DD11E826C for ; Tue, 16 Jul 2013 01:59:56 -0700 (PDT) Received: from localhost (mcheck2.ugent.be [157.193.49.249]) by smtp1.ugent.be (Postfix) with ESMTP id C421980A7; Tue, 16 Jul 2013 10:59:55 +0200 (CEST) X-Virus-Scanned: by UGent DICT Received: from smtp1.ugent.be ([157.193.71.182]) by localhost (mcheck2.UGent.be [157.193.43.11]) (amavisd-new, port 10024) with ESMTP id UwbGJ_JusliA; Tue, 16 Jul 2013 10:59:55 +0200 (CEST) Received: from mail2.intec.ugent.be (mail2.intec.ugent.be [157.193.214.245]) by smtp1.ugent.be (Postfix) with ESMTP id 24A9080A5; Tue, 16 Jul 2013 10:59:55 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail2.intec.ugent.be (Postfix) with ESMTP id 4971421; Tue, 16 Jul 2013 10:59:55 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at intec.ugent.be Received: from mail2.intec.ugent.be ([127.0.0.1]) by localhost (mail2.intec.ugent.be [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKlieZE9qaKK; Tue, 16 Jul 2013 10:59:55 +0200 (CEST) Received: from [157.193.135.242] (dhcp-zdpt-242.intec.ugent.be [157.193.135.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: fvdabeele) by mail2.intec.ugent.be (Postfix) with ESMTPSA id 3A3D920; Tue, 16 Jul 2013 10:59:55 +0200 (CEST) Message-ID: <51E50B8A.5070300@intec.ugent.be> Date: Tue, 16 Jul 2013 10:59:54 +0200 From: Floris Van den Abeele User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: teemu.savolainen@nokia.com References: <916CE6CF87173740BC8A2CE443096962047E35F4@008-AM1MPN1-052.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE443096962047E35F4@008-AM1MPN1-052.mgdnok.nokia.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at jchkm3 with ID 51E50B8B.000 by Joe's j-chkmail (http://helpdesk.ugent.be/email/)! X-j-chkmail-Enveloppe: 51E50B8B.000 from mail2.intec.ugent.be/mail2.intec.ugent.be/157.193.214.245/mail2.intec.ugent.be/ X-j-chkmail-Score: MSGID : 51E50B8B.000 on smtp1.ugent.be : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Cc: core@ietf.org Subject: Re: [core] CoAP over WebSockets version -00 published X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 09:00:02 -0000 Considering websockets as an other transport protocol for CoAP seems to be a valid approach. Personally I hadn't considered the use-case yet, but it looks interesting. One remark I have is that - in the CoAP proxy use-case - the WS Client can't inform the CoAP proxy which message type (NON/CON) it should use to contact the CoAP UDP Server. When talking CoAP over UDP on both ends of the proxy I would imagine that a proxy would just re-use the CoAP message-type of the incoming request? This remark isn't specific to the WebSockets transport though, it applies to all transports that provide reliability. Do the authors (or the list) know of any guidelines for this remark (or should we help define these)? Finally, out of curiosity do the i-d authors have any running code implementing this draft? Cheers, Floris Op ma 15 jul 2013 21:15:13 CEST, teemu.savolainen@nokia.com schreef: > > Hi all, > > We have published draft-savolainen-core-coap-websockets-00 > (http://www.ietf.org/internet-drafts/draft-savolainen-core-coap-websockets-00.txt) > that describes how to retrieve and update CoAP resources using CoAP > requests and responses over the WebSocket Protocol. > > Please see the draft for details - we discuss there, for example, the > scenarios where we envision this to be useful, and technical details > required for handshaking WebSocket connection for CoAP and for > actually transporting CoAP messages within WebSocket framing. Of > course not forgetting "coap+ws" URI scheme for identifying both the > WebSocket endpoint and CoAP resource within that endpoint. > > All comments welcome. > > Best regards, > > Teemu > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From hartke@tzi.org Tue Jul 16 05:50:56 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21A3E11E80E0 for ; Tue, 16 Jul 2013 05:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0+1tcl6d7cFB for ; Tue, 16 Jul 2013 05:50:51 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 065AE11E80E3 for ; Tue, 16 Jul 2013 05:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r6GCoi1t000468 for ; Tue, 16 Jul 2013 14:50:44 +0200 (CEST) Received: from mail-ve0-f174.google.com (mail-ve0-f174.google.com [209.85.128.174]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id D4109E80 for ; Tue, 16 Jul 2013 14:50:43 +0200 (CEST) Received: by mail-ve0-f174.google.com with SMTP id oz10so451148veb.33 for ; Tue, 16 Jul 2013 05:50:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=4tAmMdq7kG68AqVM9jSuZjKROHvMD5/29MRIqUF6Lto=; b=WIPBq4FMUCn4b6c/8ZLiyAPT1qb8zi2WZ7fP1TwNywigmKL7ue2Qkr3VQ4rvAeAhNa miFQdcUdVc+H3A4tAexfBSGAyLtWaGL1zKGsqCu5/c5Pqp7jp80Mul0sE9psBw9A9vlO 8u945vqZHPmVFsEWiFxFQABO6+M093t015BtqnL69bSEh57rIGT43wp+80JlZNTE5iSv I5d0d3p445WiUsMobuhaXT7Q9OW14Jc3567wxLBqgQaFgftq9CULrJbSLxaaprOX9SIQ TdZezfZcbfnQn+Sse8BU6O9sM6HOp/bfiWNU5EsZMYW2F4IovZWW9Q9PSgqh0Bt0UTYk vF+w== X-Received: by 10.58.181.225 with SMTP id dz1mr371030vec.95.1373979042536; Tue, 16 Jul 2013 05:50:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.76.163 with HTTP; Tue, 16 Jul 2013 05:50:02 -0700 (PDT) In-Reply-To: <20130715191913.10424.80790.idtracker@ietfa.amsl.com> References: <20130715191913.10424.80790.idtracker@ietfa.amsl.com> From: Klaus Hartke Date: Tue, 16 Jul 2013 15:50:02 +0300 Message-ID: To: core@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [core] I-D Action: draft-ietf-core-observe-09.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 12:50:56 -0000 > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Constrained RESTful Environments Working Group of the IETF. > > Title : Observing Resources in CoAP > Author(s) : Klaus Hartke > Filename : draft-ietf-core-observe-09.txt > Pages : 29 > Date : 2013-07-15 > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-core-observe > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-core-observe-09 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-core-observe-09 Following the discussion we had in February, the major change of this revision is that a GET request no longer can have side-effects on other requests, and that every GET requests adds a new entry to the list of observers. Please take a look at the draft and let me know what you think. observe-09 concludes the big round of changes that started with the WGLC for observe-05 in March, 2012, except for the following two remaining issues: * How can a client detect that it is no longer in the list of observers when it has successfully registered? * How can a client cancel an observation more eagerly than by rejecting the next confirmable notification? There have been a few proposals over the time that are related to these issues. These include - the original Lifetime Option [1], - the Pledge Option [2][3], - the Patience Option [4], - the Next-Notification-At-Latest Option [5], - the new Liveliness check with Pings [6], and - the Condition Option with type Cancellation [7], - the new Cancellation Message [8]. All of them have some advantages and disadvantages, and I currently do not favor any proposal over another. Note that not all proposals have been updated to observe-09 yet. We should soon find consensus on which one we want to use. I propose we do that based on running code. If you like a proposal (or come up another one), 1. please implement both the client-side and the server-side, 2. publish the code somewhere or send me a copy by mail, 3. post a short summary of your implementation experience to the mailing list. It would be great to have at least some feedback before the IETF meeting in Berlin, so we can have a good discussion at the CoRE meeting on Monday. I plan to bring an implementation of observe-09 to Berlin. If anyone is interested in some informal interop testing, drop me a line. Best regards, Klaus [1] http://tools.ietf.org/html/draft-ietf-core-observe-01#section-3 [2] http://tools.ietf.org/html/draft-bormann-coap-misc-25#appendix-B.4.3 [3] http://tools.ietf.org/html/draft-li-core-conditional-observe-04#section-6.2 [4] http://tools.ietf.org/html/draft-li-core-coap-patience-option-02#section-2.2.3 [5] http://tools.ietf.org/html/draft-bormann-coap-misc-25#section-2 [6] http://tools.ietf.org/html/draft-hartke-core-coap-liveliness-00#section-2 [7] http://tools.ietf.org/html/draft-li-core-conditional-observe-04#section-6.1 [8] http://tools.ietf.org/html/draft-hartke-core-coap-liveliness-00#section-3 From erkkih@ee.oulu.fi Tue Jul 16 02:22:30 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C528E21F848E for ; Tue, 16 Jul 2013 02:22:30 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3n+2ZBBj-I9F for ; Tue, 16 Jul 2013 02:22:21 -0700 (PDT) Received: from ee.oulu.fi (ee.oulu.fi [130.231.61.23]) by ietfa.amsl.com (Postfix) with ESMTP id 6300121F85B4 for ; Tue, 16 Jul 2013 02:22:20 -0700 (PDT) Received: from [IPv6:::1] (paju.oulu.fi [130.231.240.20]) (authenticated bits=0) by ee.oulu.fi (8.14.4/8.14.4) with ESMTP id r6G9MI4N006459 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 16 Jul 2013 12:22:19 +0300 Message-ID: <51E51108.3090907@ee.oulu.fi> Date: Tue, 16 Jul 2013 12:23:20 +0300 From: Erkki Harjula User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: core@ietf.org References: <20130715142119.31073.38929.idtracker@ietfa.amsl.com> In-Reply-To: <20130715142119.31073.38929.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------030804080800000301010108" X-Mailman-Approved-At: Tue, 16 Jul 2013 10:03:33 -0700 Subject: [core] Fwd: New Version Notification for draft-jimenez-distributed-resource-directory-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 09:22:30 -0000 This is a multi-part message in MIME format. --------------030804080800000301010108 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Dear CORE members, In some M2M scenarios, it is convenient to offer non-centralized alternatives for discovery and rendezvous. We have submitted a new draft that defines a Distributed Resource Directory for CoAP: http://www.ietf.org/internet-drafts/draft-jimenez-distributed-resource-directory-00.txt The draft proposes a mechanism where DHT-based P2P overlay provides discovery, rendezvous and caching services for CoAP Endpoints, as well as HTTP proxy service for Web clients. Your comments and improvement ideas are very welcome! -Erkki -------- Original Message -------- Subject: New Version Notification for draft-jimenez-distributed-resource-directory-00.txt Date: Mon, 15 Jul 2013 07:21:19 -0700 From: internet-drafts@ietf.org To: Erkki Harjula , Meirong Liu , Jaime Jimenez A new version of I-D, draft-jimenez-distributed-resource-directory-00.txt has been successfully submitted by Jaime Jimenez and posted to the IETF repository. Filename: draft-jimenez-distributed-resource-directory Revision: 00 Title: A Distributed Resource Directory (DRD) Creation date: 2013-07-15 Group: Individual Submission Number of pages: 11 URL:http://www.ietf.org/internet-drafts/draft-jimenez-distributed-resource-directory-00.txt Status:http://datatracker.ietf.org/doc/draft-jimenez-distributed-resource-directory Htmlized:http://tools.ietf.org/html/draft-jimenez-distributed-resource-directory-00 Abstract: In some M2M scenarios, it is convenient to offer non-centralized alternatives for discovery and rendezvous. This document defines a Distributed Resource Directory (DRD) for Constrained Application Protocol (CoAP). Distribution is achieved by means of a structured Peer-to-Peer (P2P) overlay. The DHT-based P2P overlay provides discovery, rendezvous and caching services for CoAP End-points as well as HTTP proxy service for Web clients. The IETF Secretariat --------------030804080800000301010108 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Dear CORE members,

In some M2M scenarios, it is convenient to offer non-centralized alternatives for discovery and rendezvous.  We have submitted a new draft that defines a Distributed Resource Directory for CoAP: http://www.ietf.org/internet-drafts/draft-jimenez-distributed-resource-directory-00.txt

The draft proposes a mechanism where DHT-based P2P overlay provides discovery, rendezvous and caching services for CoAP Endpoints, as well as HTTP proxy service for Web clients.

Your comments and improvement ideas are very welcome!

-Erkki



-------- Original Message --------
Subject: New Version Notification for draft-jimenez-distributed-resource-directory-00.txt
Date: Mon, 15 Jul 2013 07:21:19 -0700
From: internet-drafts@ietf.org
To: Erkki Harjula <erkki.harjula@ee.oulu.fi>, Meirong Liu <meiliu@ee.oulu.fi>, Jaime Jimenez <jaime.j.jimenez@ericsson.com> 


A new version of I-D, draft-jimenez-distributed-resource-directory-00.txt
has been successfully submitted by Jaime Jimenez and posted to the
IETF repository.

Filename:	 draft-jimenez-distributed-resource-directory
Revision:	 00
Title:		 A Distributed Resource Directory (DRD)
Creation date:	 2013-07-15
Group:		 Individual Submission
Number of pages: 11
URL:             http://www.ietf.org/internet-drafts/draft-jimenez-distributed-resource-directory-00.txt
Status:          http://datatracker.ietf.org/doc/draft-jimenez-distributed-resource-directory
Htmlized:        http://tools.ietf.org/html/draft-jimenez-distributed-resource-directory-00


Abstract:
   In some M2M scenarios, it is convenient to offer non-centralized
   alternatives for discovery and rendezvous.  This document defines a
   Distributed Resource Directory (DRD) for Constrained Application
   Protocol (CoAP).  Distribution is achieved by means of a structured
   Peer-to-Peer (P2P) overlay.  The DHT-based P2P overlay provides
   discovery, rendezvous and caching services for CoAP End-points as
   well as HTTP proxy service for Web clients.

                                                                                  


The IETF Secretariat


--------------030804080800000301010108-- From kovatsch@inf.ethz.ch Wed Jul 17 00:59:51 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B2E821F9306 for ; Wed, 17 Jul 2013 00:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.448 X-Spam-Level: X-Spam-Status: No, score=-7.448 tagged_above=-999 required=5 tests=[AWL=3.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uyxGOmqMApod for ; Wed, 17 Jul 2013 00:59:45 -0700 (PDT) Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) by ietfa.amsl.com (Postfix) with ESMTP id ADFC721F909A for ; Wed, 17 Jul 2013 00:59:43 -0700 (PDT) Received: from CAS11.d.ethz.ch (172.31.38.211) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.2.298.4; Wed, 17 Jul 2013 09:59:35 +0200 Received: from MBX110.d.ethz.ch ([fe80::9d9a:a7f2:c282:5f6a]) by CAS11.d.ethz.ch ([fe80::ecc9:4e2d:b26b:1614%10]) with mapi id 14.02.0298.004; Wed, 17 Jul 2013 09:59:41 +0200 From: "Kovatsch Matthias" To: Klaus Hartke , "core@ietf.org" Thread-Topic: [core] I-D Action: draft-ietf-core-observe-09.txt Thread-Index: AQHOgZBSUdx8tGFD6USkk0plrJkryplnIVEAgAFGUrA= Date: Wed, 17 Jul 2013 07:59:40 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B514FDC9CA@MBX110.d.ethz.ch> References: <20130715191913.10424.80790.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.132.130.253] Content-Type: multipart/alternative; boundary="_000_55877B3AFB359744BA0F2140E36F52B514FDC9CAMBX110dethzch_" MIME-Version: 1.0 Subject: Re: [core] I-D Action: draft-ietf-core-observe-09.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 07:59:51 -0000 --_000_55877B3AFB359744BA0F2140E36F52B514FDC9CAMBX110dethzch_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > * How can a client detect that it is no longer in the list of observers w= hen it > has successfully registered? When the client really wants to figure out if the server is still there and= if it is still on the list of observers, it cannot without communicating w= ith the server. Thus I like the Liveliness check with Pings, which keeps th= e additional communication to a minimum (as no representation is transmitte= d). By default, however, the observer should be optimistic and wait for a s= pecific time before acting. This should be at least Max-Age, but at this po= int I think a combination of Pledge and Stubbornness(tm) by sharing the sam= e time span would be useful. In critical cases (e.g., an intrusion detectio= n application checking window sensors), a Ping might be issued earlier, tho= ugh. As notifications partake in caching, which can be used without Observing, w= e cannot re-use the Max-Age option for the Pledge/Stubbornness indication. > * How can a client cancel an observation more eagerly than by rejecting t= he > next confirmable notification? I would say we use the mechanism we had before: a GET request without Obser= ve option. Because of the Token multiplexing, there will be no accidental c= ancellation, as the client should not use a Token that he is already using. (The draft says that there is no side-effect whatsoever between different G= ET requests, but what if the client sends a new GET request with a Token al= ready in use? It will collide with the Observe relationship entry at the se= rver, which will probably be overwritten. So why not use this?) Something that should be clarified is the impact of NSTART on -observe. If = an active observe relationship is considered an outstanding interaction, cl= ients could only observe one resource. This is really bad and we would need= some kind of batch mechanism in the draft. With the first notification hav= ing arrived, however, the client has heard from the server and I would not = considers this an _outstanding_ interaction anymore. But then we still have= a problem at the server: if a single client observes multiple resources, t= heir notifications are influencing each other. If one resource is currently= transmitting a Confirmable notification, others cannot and must wait for t= his transmission to be acknowledged. Or do the congestion control rules not= apply here because it says "Clients" in coap-18? Ciao Matthias P.S.: I was thinking about an alternative to Liveliness check with Pings: A= n observe validation that uses an Observe value in the request. Pro: An observer can also check whether it has the latest representation wi= thout additional ETag options Con: Not as generic as Liveliness check with Pings (so, is it worth to have= this observe-specific additional code...?) CLIENT SERVER | | +----->| Header: GET | GET | Token: 0x0c | | Uri-Path: obs | | Observe: (empty) | | |<-----+ Header: 2.05 | 2.05 | Token: 0x0c | | Observe: 23 | | Max-Age: 300 | | Payload: [x bytes] | | ... | | |<-----+ Header: 2.05 | 2.05 | Token: 0x0c | | Observe: 24 | | Max-Age: 300 | | Payload: [x bytes] | | ... ... | | +----->| Header: GET | GET | Token: 0x0c | | Uri-Path: obs | | Observe: 24 (note that the request has a value for Obs= erve) | | |<-----+ Header: 2.03 | 2.03 | Token: 0x0b | | Max-Age: 120 | | Observe: 24 Or in case Notifications were lost: |<-----+ Header: 2.05 | 2.05 | Token: 0x0b | | Max-Age: 300 | | Observe: 27 | | Payload: [x bytes] The validation check at the server would also need to deal with wrap-around= s lke the reordering process. I am also not sure how to deal with the Obser= ve sequence number of zero, which is basically an empty Observe option. --_000_55877B3AFB359744BA0F2140E36F52B514FDC9CAMBX110dethzch_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

> * How can a client detect that it is no long= er in the list of observers when it

> has successfully registered?

 

When the client really wants to figure out if the= server is still there and if it is still on the list of observers, it cann= ot without communicating with the server. Thus I like the Liveliness check = with Pings, which keeps the additional communication to a minimum (as no representation is transmitted). By defau= lt, however, the observer should be optimistic and wait for a specific time= before acting. This should be at least Max-Age, but at this point I think = a combination of Pledge and Stubbornness™ by sharing the same time span would be useful. In critical cases (e.g., an= intrusion detection application checking window sensors), a Ping might be = issued earlier, though.

 

As notifications partake in caching, which can be= used without Observing, we cannot re-use the Max-Age option for the Pledge= /Stubbornness indication.

 

> * How can a client cancel an observation mor= e eagerly than by rejecting the

> next confirmable notification?

 

I would say we use the mechanism we had before: a= GET request without Observe option. Because of the Token multiplexing, the= re will be no accidental cancellation, as the client should not use a Token= that he is already using.

(The draft says that there is no side-effect what= soever between different GET requests, but what if the client sends a new G= ET request with a Token already in use? It will collide with the Observe re= lationship entry at the server, which will probably be overwritten. So why not use this?)

 

 

Something that should be clarified is the impact = of NSTART on -observe. If an active observe relationship is considered an o= utstanding interaction, clients could only observe one resource. This is re= ally bad and we would need some kind of batch mechanism in the draft. With the first notification having arrive= d, however, the client has heard from the server and I would not considers = this an _outstanding_ interaction anymore. But then we still have a problem= at the server: if a single client observes multiple resources, their notifications are influencing each othe= r. If one resource is currently transmitting a Confirmable notification, ot= hers cannot and must wait for this transmission to be acknowledged. Or do t= he congestion control rules not apply here because it says "Clients" in coap-18?

 

Ciao

Matthias

 

 

P.S.: I was thinking about an alternative to Live= liness check with Pings: An observe validation that uses an Observe value i= n the request.

 

Pro: An observer can also check whether it has th= e latest representation without additional ETag options

Con: Not as generic as Liveliness check with Ping= s (so, is it worth to have this observe-specific additional code…?)

 

       CLIENT  SERVER

         | &nbs= p;    |

         +-----&= gt;|     Header: GET

         | GET = |      Token: 0x0c

         | &nbs= p;    |   Uri-Path: obs

         | &nbs= p;    |    Observe: (empty)=

         | &nbs= p;    |

         |<-----&= #43;     Header: 2.05

         | 2.05 |&nb= sp;     Token: 0x0c

         | &nbs= p;    |    Observe: 23

         | &nbs= p;    |    Max-Age: 300

         | &nbs= p;    |    Payload: [x bytes]

         | &nbs= p;    |

          = ...

         | &nbs= p;    |

         |<-----&= #43;     Header: 2.05

         | 2.05 |&nb= sp;     Token: 0x0c

         | &nbs= p;    |    Observe: 24

         | &nbs= p;    |    Max-Age: 300

         | &nbs= p;    |    Payload: [x bytes]

         | = ;     |

          = ...

          =  ...

         | &nbs= p;    |

         +-----&= gt;|     Header: GET

         | GET = |      Token: 0x0c

         | &nbs= p;    |   Uri-Path: obs

         | &nbs= p;    |    Observe: 24 (note that the request= has a value for Observe)

         | &nbs= p;    |

         |<-----&= #43;     Header: 2.03

         | 2.03 |&nb= sp;     Token: 0x0b

         | &nbs= p;    |    Max-Age: 120

         | &nbs= p;    |    Observe: 24

 

Or in case Notifications were lost:

 

         |<-----&= #43;     Header: 2.05

         | 2.05 |&nb= sp;     Token: 0x0b

         | &nbs= p;    |    Max-Age: 300

         | &nbs= p;    |    Observe: 27

         | &nbs= p;    |    Payload: [x bytes]

 

The validation check = at the server would also need to deal with wrap-arounds lke the reordering = process. I am also not sure how to deal with the Observe sequence number of= zero, which is basically an empty Observe option.

 

--_000_55877B3AFB359744BA0F2140E36F52B514FDC9CAMBX110dethzch_-- From Mehdi.Mani@itron.com Wed Jul 17 08:10:36 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D4CA21E8086 for ; Wed, 17 Jul 2013 08:10:36 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zCk1OQx5JMKB for ; Wed, 17 Jul 2013 08:10:31 -0700 (PDT) Received: from mail.itron.com (mail.itron.com [198.182.8.115]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE0921E808C for ; Wed, 17 Jul 2013 08:10:30 -0700 (PDT) Received: from ITR-EXMBXVS-1.itron.com ([192.168.9.112]) by spo-exchcn-1.itron.com ([192.168.9.115]) with mapi; Wed, 17 Jul 2013 08:10:30 -0700 From: "Mani, Mehdi" To: "core@ietf.org" Date: Wed, 17 Jul 2013 08:10:29 -0700 Thread-Topic: COAP and DHCP Thread-Index: Ac6C/8YeJUVKgCkzQ/ugbvCVa1ja3g== Message-ID: <10F62A0D440ACA41A85C7CB02936A1DB5B440A278F@ITR-EXMBXVS-1.itron.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: multipart/alternative; boundary="_000_10F62A0D440ACA41A85C7CB02936A1DB5B440A278FITREXMBXVS1it_" MIME-Version: 1.0 Subject: [core] COAP and DHCP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 15:10:36 -0000 --_000_10F62A0D440ACA41A85C7CB02936A1DB5B440A278FITREXMBXVS1it_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm wondering if in Core WG there has ever been a discussion about obtainin= g IPv6 address using COAP instead of using DHCP. In LLN, if we consider that COAP is used as management protocol which confi= gure end-points, why not using that for configuring a node for its IP addre= ss. This could be especially interesting to reduce the registration transac= tions for LLN end-points. Looking forward to hearing the interesting comments. Thanks -Mehdi --_000_10F62A0D440ACA41A85C7CB02936A1DB5B440A278FITREXMBXVS1it_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m wondering if in Core WG there has ever been a discussion about o= btaining IPv6 address using COAP instead of using DHCP.

In LLN, if we consider that COAP = is used as management protocol which configure end-points, why not using th= at for configuring a node for its IP address. This could be especially inte= resting to reduce the registration transactions for LLN end-points.

 

Looking forward to hearing t= he interesting comments.

Thanks

-Mehdi

= --_000_10F62A0D440ACA41A85C7CB02936A1DB5B440A278FITREXMBXVS1it_-- From d.sturek@att.net Wed Jul 17 09:39:43 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A7FB21F995B for ; Wed, 17 Jul 2013 09:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.287 X-Spam-Level: X-Spam-Status: No, score=0.287 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9L3lI3AtTo1N for ; Wed, 17 Jul 2013 09:39:38 -0700 (PDT) Received: from nm23-vm9.access.bullet.mail.bf1.yahoo.com (nm23-vm9.access.bullet.mail.bf1.yahoo.com [216.109.115.168]) by ietfa.amsl.com (Postfix) with ESMTP id AFFA021F9B0D for ; Wed, 17 Jul 2013 09:39:26 -0700 (PDT) Received: from [66.196.81.164] by nm23.access.bullet.mail.bf1.yahoo.com with NNFMP; 17 Jul 2013 16:39:24 -0000 Received: from [98.139.221.50] by tm10.access.bullet.mail.bf1.yahoo.com with NNFMP; 17 Jul 2013 16:39:24 -0000 Received: from [127.0.0.1] by smtp103.sbc.mail.bf1.yahoo.com with NNFMP; 17 Jul 2013 16:39:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1374079164; bh=yTksaYPZrlHiCM3cJDfugeledKZzTKMjUKO3Ak/gv1E=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type; b=PWS7GxPVZJJfSBmc/Ng+WmFXavoviDIMPvuujmtp+2v98KdMWnsuLXkp3jyke45U0F5yC9AnjK9257bJQgKwFOkUP1ShDJ48cH8vLX/nyd534Oyt5lHxIQSntICK3hg8PKNOqnPflLvn70UGthj8VZoibmpylzl+qUZv+XZbkoY= X-Yahoo-Newman-Id: 905945.38738.bm@smtp103.sbc.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: sMl0OCsVM1k1rB_JTTCCwzuWNaC.cEE0vuEh.xyJfphD5XY rvZJVmM7nyNmx.d1osnARJRt8bwH9EQWcW_.G7xC.OijqKCvdgti9qmWr0mM Lp9ZjlkIUr9d4jhobOGIPYHSR1ArC7yhFWLSoWUwtSPoRPTK_isTXIhbHMZo DKHyPez1_xDJH.qCPfRjbWp4itsxeBDHeW45m3Y6RLu56V1esJvvUikuXELb HvraeprIzMjsen3fe_FHyvgrkvg8DXkDecYTtJSbWDZ_qwcdnu1_yYfSLrCW Y2crAJ0C8kd_zye6FjIBys.obn6mZQRlUidBqs8kHO.Zl4XdFkTL5ggmOmPA LmJn8dK.p9M81deueqivbbaa_IoMB7jAe.CzBqtoxP7eWh1Xbyea50XeieuE sJ_NinUY5SU4MBPltGTmH0PR3iSq7hCriZwDiHhZ680awses47qPpkQ.6oWc c6Kp0EZBsZrYdKjIpc30KMehqyr6NIPh3NqftzLlSE1uGmu3kmUTeKLN48C_ DbuPbnL7Ok87Z6RuM X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-Rocket-Received: from [10.1.1.129] (d.sturek@66.27.60.174 with login) by smtp103.sbc.mail.bf1.yahoo.com with SMTP; 17 Jul 2013 09:39:24 -0700 PDT User-Agent: Microsoft-MacOutlook/14.3.6.130613 Date: Wed, 17 Jul 2013 09:32:58 -0700 From: Don Sturek To: "Mani, Mehdi" , "core@ietf.org" Message-ID: Thread-Topic: [core] COAP and DHCP In-Reply-To: <10F62A0D440ACA41A85C7CB02936A1DB5B440A278F@ITR-EXMBXVS-1.itron.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3456898764_45772" Subject: Re: [core] COAP and DHCP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 16:39:43 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3456898764_45772 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Mehdi, In lieu of DHCP, why wouldn't a device simply use SLAAC? Don From: "Mani, Mehdi" Date: Wednesday, July 17, 2013 8:10 AM To: "core@ietf.org" Subject: [core] COAP and DHCP I=B9m wondering if in Core WG there has ever been a discussion about obtainin= g IPv6 address using COAP instead of using DHCP. In LLN, if we consider that COAP is used as management protocol which configure end-points, why not using that for configuring a node for its IP address. This could be especially interesting to reduce the registration transactions for LLN end-points. =20 Looking forward to hearing the interesting comments. Thanks -Mehdi _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core --B_3456898764_45772 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Hi Mehdi,

In lieu of DHCP, why wouldn't a device simply use SLAAC?
=
Don


From: "Mani, Mehdi" <= Mehdi.Mani@itron.com>
Date: = Wednesday, July 17, 2013 8:10 AM
To: "core@ietf.org" <core@ietf.org>
Subjec= t: [core] COAP and DHCP

I’m= wondering if in Core WG there has ever been a discussion about obtaining IP= v6 address using COAP instead of using DHCP.

In LLN, if we consider that COAP is used as ma= nagement protocol which configure end-points, why not using that for configu= ring a node for its IP address. This could be especially interesting to redu= ce the registration transactions for LLN end-points.

 

Looking forward to hearing the interesting com= ments.

Thanks

-Mehdi

______________________________________________= _ core mailing list core@ietf.org https://www.ietf.org/m= ailman/listinfo/core --B_3456898764_45772-- From kovatsch@inf.ethz.ch Thu Jul 18 05:57:58 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1774F21F9A43 for ; Thu, 18 Jul 2013 05:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.024 X-Spam-Level: X-Spam-Status: No, score=-9.024 tagged_above=-999 required=5 tests=[AWL=1.575, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFOc4efKGhZk for ; Thu, 18 Jul 2013 05:57:53 -0700 (PDT) Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) by ietfa.amsl.com (Postfix) with ESMTP id E96BD21F8517 for ; Thu, 18 Jul 2013 05:57:52 -0700 (PDT) Received: from CAS22.d.ethz.ch (172.31.51.112) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.2.298.4; Thu, 18 Jul 2013 14:57:41 +0200 Received: from MBX210.d.ethz.ch ([fe80::ed77:7d47:9467:69a9]) by CAS22.d.ethz.ch ([fe80::dd0e:466a:b055:c090%10]) with mapi id 14.02.0298.004; Thu, 18 Jul 2013 14:57:50 +0200 From: "Kovatsch Matthias" To: Don Sturek , Jari Arkko , "core@ietf.org" Thread-Topic: [core] blog article on Web of Things Thread-Index: AQHOgXBuZ7a4VLClTkWdVuzpCzrZWpllz94AgASXKcA= Date: Thu, 18 Jul 2013 12:57:49 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B514FF0345@MBX210.d.ethz.ch> References: <591574B1-BC5A-41EB-8386-FBE561008A3A@piuha.net> In-Reply-To: Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.132.130.253] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [core] blog article on Web of Things X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 12:57:58 -0000 Hey there I am aware that this is about standardization work, but I just want to add = that we should not forget about a very central idea of the Web of Things: p= hysical mashups. It is about light-weight scripting that can connect any-th= ing to any-thing, also those which were not designed to go together. This l= eaves the world of device profiles with cryptic identifiers and adds the re= quirement for self-descriptive, easy-to-use APIs. Another aspect that was missing---probably because it is still far from com= mercialization---is semantic descriptions such as RESTdesc. There is a lot = of work going on to enable M2M without the traditional, predefined device p= rofiles. Ciao Matthias > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of > Don Sturek > Sent: Montag, 15. Juli 2013 18:41 > To: Jari Arkko; core@ietf.org > Subject: Re: [core] blog article on Web of Things >=20 > Hi Jari, >=20 > Many great points in your blog. I especially agree on having outside > commercial groups (eg, ZigBee, Z-Wave, IPSO) creating profiles using IETF > standards and drafts (including Core). >=20 > Any thoughts on how these commercial standards groups can report on > missing (needed) features or additions within the IETF? One of the > biggest challenges is knowing what group in IETF should be the target of = such > requests (or even if a BOF is needed if there is not group). I can see s= ome > additional features being needed for a full Core deployment (part of whic= h > can be addressed in the DICE group but I am also thinking of work on > forwarding to multicast groups where message distribution does not use > flooding.....) >=20 > Don >=20 >=20 > On 7/15/13 8:31 AM, "Jari Arkko" wrote: >=20 > >FYI - I wrote an article about the Web of Things, i.e., using the web > >technologies to build Internet of Things applications and devices. > >Here's the blog: > > > >http://www.ietf.org/blog/2013/07/the-web-of-things/ > > > >Thoughts, comments? I suppose the people in this working group believe > >in this model, if anyone :-) But I'd be interested also in thoughts on > >how we can make our technologies (such as CoAP as a part of the Web of > >Things > >framework) more widely known and understood. I personally believe it is > >very exciting technology, and worth more attention... > > > >Jari > > > >_______________________________________________ > >core mailing list > >core@ietf.org > >https://www.ietf.org/mailman/listinfo/core >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From hartke@tzi.org Thu Jul 18 09:36:57 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC98411E818E for ; Thu, 18 Jul 2013 09:36:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JEQfJrQqvc-v for ; Thu, 18 Jul 2013 09:36:52 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id BD80211E8173 for ; Thu, 18 Jul 2013 09:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r6IGan28028793 for ; Thu, 18 Jul 2013 18:36:49 +0200 (CEST) Received: from mail-vb0-f50.google.com (mail-vb0-f50.google.com [209.85.212.50]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 50AAAC04 for ; Thu, 18 Jul 2013 18:36:49 +0200 (CEST) Received: by mail-vb0-f50.google.com with SMTP id w16so2495353vbb.23 for ; Thu, 18 Jul 2013 09:36:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=kXomotruDxMYHnvZShVqK9i7KN5fPmSQ4AGmWKZey0A=; b=LD1vQTFdk7rBINgfuDdyV20eZpnsoI+OsaKTs/xbBSNKkQDsadoYwdX33bm+5clfZL dcBcN408/JrmYQeWyqhBiuoe7Ew7AI9qyMT8eyL6D7DeKZ3ofqbzZrx+uXIH+DTb4OyA zZmzlxCPgUDn+7mRJMopPY6J9MOTalUeA+hM03hGd0RH69+k9QmeeOnoLOtsgtssZxvk UPEWOaJuk5KwBB4fRuV0dBfFy1q2JlkK1zTLY5NFd7sJXYPUOQsRkhqbyhEG0Ueey1zA 3cXEhmjCPDwxiyWokQZMVe2FkjA0K+r0yoSf7ayf/oI064huheZ9NwfN4Ped7sg5307b ryIg== X-Received: by 10.58.181.225 with SMTP id dz1mr4336293vec.95.1374165407961; Thu, 18 Jul 2013 09:36:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.76.163 with HTTP; Thu, 18 Jul 2013 09:36:07 -0700 (PDT) From: Klaus Hartke Date: Thu, 18 Jul 2013 19:36:07 +0300 Message-ID: To: Floris Van den Abeele Content-Type: text/plain; charset=ISO-8859-1 Cc: core@ietf.org Subject: [core] Message type across proxies (was: CoAP over WebSockets version -00 published) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 16:36:58 -0000 Hi Floris, > One remark I have is that - in the CoAP proxy use-case - the WS Client can't > inform the CoAP proxy which message type (NON/CON) it should use to contact > the CoAP UDP Server. When talking CoAP over UDP on both ends of the proxy I > would imagine that a proxy would just re-use the CoAP message-type of the > incoming request? This remark isn't specific to the WebSockets transport > though, it applies to all transports that provide reliability. Do the > authors (or the list) know of any guidelines for this remark (or should we > help define these)? This is indeed not specific to the WebSockets transport. 'Confirmable' solely means that the recipient is required to return an acknowledgement for the message. It's not an requirement that the message is forwarded by an intermediary as confirmable as well. The communication between each pair of hops is independent. An intermediary is free to satisfy a request as it sees fit. The text in coap-18 suggests that the response to a confirmable request should be piggy-backed or separate, and the response to a non-confirmable request should be non-confirmable. But there are indeed no explicit guidelines on the message type used for forwarding messages by intermediaries. My implementation currently uses confirmable messages for all requests it sends. If there is a need for an end-to-end quality-of-service indication (like "I really want a response" or "I don't care if the request or response is lost on the way") then I'd say we need a new CoAP option. Klaus From paduffy@cisco.com Thu Jul 18 10:31:11 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64D1E11E8162 for ; Thu, 18 Jul 2013 10:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9wuDow794qT for ; Thu, 18 Jul 2013 10:31:06 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 507BF21F9C06 for ; Thu, 18 Jul 2013 10:31:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4801; q=dns/txt; s=iport; t=1374168666; x=1375378266; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to; bh=qrT6CdbQWZ0qGPrlP7m0Jqyw8THJUULsl3Axh9AhDjI=; b=ZdR19VrDopfzfIHEMj/D/LgUhgONUKkNg5Lin/PBQwFC5wX9ZbVY0koy I8opTLgZF6goyjjaSitKkm99MjR4/zsWVTgpEYraOoRaH60SYqgST43SG aEPhb5FI7FIekH8KflnnYLHjafYVFLHMog3+OdXACB2I6h4G9rx6cJJhq 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkFAPUk6FGtJV2b/2dsb2JhbABagkJENYkzt2CBEhZ0giQBAQEBAwEBASpBChELGAkWDwkDAgECARUwEwYCAQGIDAy2LASQFhaDZgOXXYYjiyqDLg X-IronPort-AV: E=Sophos;i="4.89,695,1367971200"; d="scan'208,217";a="236352887" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 18 Jul 2013 17:31:05 +0000 Received: from [161.44.68.178] ([161.44.68.178]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6IHV4wW002390 for ; Thu, 18 Jul 2013 17:31:04 GMT Message-ID: <51E82658.1030405@cisco.com> Date: Thu, 18 Jul 2013 13:31:04 -0400 From: Paul Duffy Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: core@ietf.org References: <10F62A0D440ACA41A85C7CB02936A1DB5B440A278F@ITR-EXMBXVS-1.itron.com> In-Reply-To: <10F62A0D440ACA41A85C7CB02936A1DB5B440A278F@ITR-EXMBXVS-1.itron.com> Content-Type: multipart/alternative; boundary="------------050402020305090705090503" Subject: Re: [core] COAP and DHCP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: paduffy@cisco.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 17:31:11 -0000 This is a multi-part message in MIME format. --------------050402020305090705090503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Medhi What specific advantages do you see in using CoAP versus DHCP for address management? On 7/17/2013 11:10 AM, Mani, Mehdi wrote: > > I'm wondering if in Core WG there has ever been a discussion about > obtaining IPv6 address using COAP instead of using DHCP. > > In LLN, if we consider that COAP is used as management protocol which > configure end-points, why not using that for configuring a node for > its IP address. This could be especially interesting to reduce the > registration transactions for LLN end-points. > > Looking forward to hearing the interesting comments. > > Thanks > > -Mehdi > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --------------050402020305090705090503 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Medhi

What specific advantages do you see in using CoAP versus DHCP for address management?


On 7/17/2013 11:10 AM, Mani, Mehdi wrote:

I’m wondering if in Core WG there has ever been a discussion about obtaining IPv6 address using COAP instead of using DHCP.

In LLN, if we consider that COAP is used as management protocol which configure end-points, why not using that for configuring a node for its IP address. This could be especially interesting to reduce the registration transactions for LLN end-points.

 

Looking forward to hearing the interesting comments.

Thanks

-Mehdi



_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core

--------------050402020305090705090503-- From sylvain.cherrier@univ-paris-est.fr Fri Jul 19 00:33:34 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9723821E80C2 for ; Fri, 19 Jul 2013 00:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T483e9X4VXOF for ; Fri, 19 Jul 2013 00:33:33 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 48EA821E80B5 for ; Fri, 19 Jul 2013 00:33:31 -0700 (PDT) Received: from [IPv6:2a01:e34:ef30:a340:221:85ff:fe61:26f4] (unknown [IPv6:2a01:e34:ef30:a340:221:85ff:fe61:26f4]) (Authenticated sender: sylvain.cherrier) by smtp1-g21.free.fr (Postfix) with ESMTPSA id 848429401C4 for ; Fri, 19 Jul 2013 09:33:26 +0200 (CEST) Message-ID: <51E8EBC5.8090500@univ-paris-est.fr> Date: Fri, 19 Jul 2013 09:33:25 +0200 From: sylvain Cherrier User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: core@ietf.org References: <591574B1-BC5A-41EB-8386-FBE561008A3A@piuha.net> In-Reply-To: <591574B1-BC5A-41EB-8386-FBE561008A3A@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [core] blog article on Web of Things X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 07:50:37 -0000 Hello, we are very interested in your blog because we are working on the same kind of solutions. Maybe you could take a look at our platform http://bec3.univ-mlv.fr/ ? We are still working on our framework, but I think that we are in the same kind of vision. We would be pleased to have some comments on it, or some advices. Sylvain Cherrier PhD. Student Université de Marne la Vallée France Le 15/07/2013 17:31, Jari Arkko a écrit : > FYI - I wrote an article about the Web of Things, i.e., using the web technologies to build Internet of Things applications and devices. Here's the blog: > > http://www.ietf.org/blog/2013/07/the-web-of-things/ > > Thoughts, comments? I suppose the people in this working group believe in this model, if anyone :-) But I'd be interested also in thoughts on how we can make our technologies (such as CoAP as a part of the Web of Things framework) more widely known and understood. I personally believe it is very exciting technology, and worth more attention... > > Jari > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From Mehdi.Mani@itron.com Fri Jul 19 07:37:18 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4481611E82BA for ; Fri, 19 Jul 2013 07:37:18 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rlym3Dq+aeIt for ; Fri, 19 Jul 2013 07:37:14 -0700 (PDT) Received: from mail.itron.com (mail.itron.com [198.182.8.115]) by ietfa.amsl.com (Postfix) with ESMTP id 3164711E82BB for ; Fri, 19 Jul 2013 07:37:07 -0700 (PDT) Received: from ITR-EXMBXVS-1.itron.com ([192.168.9.112]) by spo-exchcn-1.itron.com ([192.168.9.115]) with mapi; Fri, 19 Jul 2013 07:36:59 -0700 From: "Mani, Mehdi" To: Don Sturek , "core@ietf.org" Date: Fri, 19 Jul 2013 07:36:58 -0700 Thread-Topic: [core] COAP and DHCP Thread-Index: Ac6DDDdJb4OX6bwzR9SSV1MmPBKldQBgQbkg Message-ID: <10F62A0D440ACA41A85C7CB02936A1DB5B44115483@ITR-EXMBXVS-1.itron.com> References: <10F62A0D440ACA41A85C7CB02936A1DB5B440A278F@ITR-EXMBXVS-1.itron.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: multipart/alternative; boundary="_000_10F62A0D440ACA41A85C7CB02936A1DB5B44115483ITREXMBXVS1it_" MIME-Version: 1.0 Subject: Re: [core] COAP and DHCP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 14:37:18 -0000 --_000_10F62A0D440ACA41A85C7CB02936A1DB5B44115483ITREXMBXVS1it_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Don, SLAAC is not efficient in meshed LLNs. First you have to broadcast your nei= ghbor discovery message. Second you have to go through DAD process. -Mehdi From: Don Sturek [mailto:d.sturek@att.net] Sent: mercredi 17 juillet 2013 18:33 To: Mani, Mehdi; core@ietf.org Subject: Re: [core] COAP and DHCP Hi Mehdi, In lieu of DHCP, why wouldn't a device simply use SLAAC? Don From: "Mani, Mehdi" > Date: Wednesday, July 17, 2013 8:10 AM To: "core@ietf.org" > Subject: [core] COAP and DHCP I'm wondering if in Core WG there has ever been a discussion about obtainin= g IPv6 address using COAP instead of using DHCP. In LLN, if we consider that COAP is used as management protocol which confi= gure end-points, why not using that for configuring a node for its IP addre= ss. This could be especially interesting to reduce the registration transac= tions for LLN end-points. Looking forward to hearing the interesting comments. Thanks -Mehdi _______________________________________________ core mailing list core@ietf= .org https://www.ietf.org/mailman/listinfo/core --_000_10F62A0D440ACA41A85C7CB02936A1DB5B44115483ITREXMBXVS1it_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Don,

 

SLAAC is not efficient in meshed LLNs. Fir= st you have to broadcast your neighbor discovery message. Second you have t= o go through DAD process.

-Mehdi

 

From: D= on Sturek [mailto:d.sturek@att.net]
Sent: mercredi 17 juillet 20= 13 18:33
To: Mani, Mehdi; core@ietf.org
Subject: Re: [c= ore] COAP and DHCP

 

Hi Mehdi,

 

In lieu of DHCP, why wouldn't a device = simply use SLAAC?

 

Don

 =

 

From: = "Mani, Mehdi" <Mehdi.Mani@itron.com>
Date: <= /b>Wednesday, July 17, 2013 8:10 AM
To: "core@ietf.org" <= core@ietf.org>
Subject: [core] COAP and DHCP

 

<= /div>

I’m wondering if in Core WG there has ever been a discussion about = obtaining IPv6 address using COAP instead of using DHCP.

In LLN, if we consider that COAP is used as manag= ement protocol which configure end-points, why not using that for configuri= ng a node for its IP address. This could be especially interesting to reduc= e the registration transactions for LLN end-points.

 

Looki= ng forward to hearing the interesting comments.

Thanks

-Mehdi

_______________________________________________ core mai= ling list core@ietf.org https://www.ietf.org/mailman/listi= nfo/core

= --_000_10F62A0D440ACA41A85C7CB02936A1DB5B44115483ITREXMBXVS1it_-- From Mehdi.Mani@itron.com Fri Jul 19 07:44:23 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D680121F9D7E for ; Fri, 19 Jul 2013 07:44:23 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6YssZHt8Hpwd for ; Fri, 19 Jul 2013 07:44:19 -0700 (PDT) Received: from mail.itron.com (mail.itron.com [198.182.8.116]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA9921E80B8 for ; Fri, 19 Jul 2013 07:44:19 -0700 (PDT) Received: from ITR-EXMBXVS-1.itron.com ([192.168.9.112]) by spo-exchcn-2.itron.com ([192.168.9.116]) with mapi; Fri, 19 Jul 2013 07:44:15 -0700 From: "Mani, Mehdi" To: "paduffy@cisco.com" , "core@ietf.org" Date: Fri, 19 Jul 2013 07:44:13 -0700 Thread-Topic: [core] COAP and DHCP Thread-Index: Ac6D3J3aNabVNpvfRnCSr3n1SuoTkAAsPN7g Message-ID: <10F62A0D440ACA41A85C7CB02936A1DB5B4417C45A@ITR-EXMBXVS-1.itron.com> References: <10F62A0D440ACA41A85C7CB02936A1DB5B440A278F@ITR-EXMBXVS-1.itron.com> <51E82658.1030405@cisco.com> In-Reply-To: <51E82658.1030405@cisco.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: multipart/alternative; boundary="_000_10F62A0D440ACA41A85C7CB02936A1DB5B4417C45AITREXMBXVS1it_" MIME-Version: 1.0 Subject: Re: [core] COAP and DHCP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 14:44:24 -0000 --_000_10F62A0D440ACA41A85C7CB02936A1DB5B4417C45AITREXMBXVS1it_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Paul, To answer to your question let's look at the whole process a node should go= through to be registered with a meshed LLN: 1) First it should go through link discovery 2) Authentication (802.1x) 3) Route establishment (for instance RPL) 4) DHCPv6 5) Register with network management system (COAP) to obtain configurat= ion parameters etc. I'm looking at these steps and see that IPv6 assignment is as well a kind o= f configuration why not doing that via COAP and skip one step; keeping in m= ind that each of these 5 step transactions need message exchange which is a= burden on LLN node and network. -Mehdi From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Pau= l Duffy Sent: jeudi 18 juillet 2013 19:31 To: core@ietf.org Subject: Re: [core] COAP and DHCP Hi Medhi What specific advantages do you see in using CoAP versus DHCP for address m= anagement? On 7/17/2013 11:10 AM, Mani, Mehdi wrote: I'm wondering if in Core WG there has ever been a discussion about obtainin= g IPv6 address using COAP instead of using DHCP. In LLN, if we consider that COAP is used as management protocol which confi= gure end-points, why not using that for configuring a node for its IP addre= ss. This could be especially interesting to reduce the registration transac= tions for LLN end-points. Looking forward to hearing the interesting comments. Thanks -Mehdi _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core --_000_10F62A0D440ACA41A85C7CB02936A1DB5B4417C45AITREXMBXVS1it_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Paul,

To answer to your q= uestion let’s look at the whole process a node should go through to b= e registered with a meshed LLN:

1)   &nbs= p;  First it should go through link discovery<= o:p>

2)      = Authentication (802.1x)

<= span lang=3DEN-US style=3D'color:#1F497D'>3= )     = ; Route establishment (for instance RPL)

4)      DHCPv6

5)      Registe= r with network management system (COAP) to obtain configuration parameters = etc.

 

I’m looking at these steps and see t= hat IPv6 assignment is as well a kind of configuration why not doing that v= ia COAP and skip one step; keeping in mind that each of these 5 step transa= ctions need message exchange which is a burden on LLN node and network.

-Mehdi

 

From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of = Paul Duffy
Sent: jeudi 18 juillet 2013 19:31
To: core@i= etf.org
Subject: Re: [core] COAP and DHCP

 

Hi Medhi

What specific advantages do you see in using CoAP versus= DHCP for address management?


On 7/17/2013 11:10 AM, Mani, Mehdi= wrote:

I’m wondering if = in Core WG there has ever been a discussion about obtaining IPv6 address us= ing COAP instead of using DHCP.

<= span lang=3DEN-US>In LLN, if we consider that COAP is used as management pr= otocol which configure end-points, why not using that for configuring a nod= e for its IP address. This could be especially interesting to reduce the re= gistration transactions for LLN end-points.

 

Looking forward to hearing the interesting comment= s.

Thanks

-Mehdi= 




_________=
______________________________________
core mailing li=
st
core@ietf.org<=
o:p>
https://www.ietf.org/mailman/listinfo/core

 

= --_000_10F62A0D440ACA41A85C7CB02936A1DB5B4417C45AITREXMBXVS1it_-- From d.sturek@att.net Fri Jul 19 07:47:53 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0EA911E82B0 for ; Fri, 19 Jul 2013 07:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JyqYjKsf2Xdx for ; Fri, 19 Jul 2013 07:47:48 -0700 (PDT) Received: from nm5.access.bullet.mail.gq1.yahoo.com (nm5.access.bullet.mail.gq1.yahoo.com [216.39.62.36]) by ietfa.amsl.com (Postfix) with ESMTP id AA39411E8205 for ; Fri, 19 Jul 2013 07:47:48 -0700 (PDT) Received: from [216.39.60.169] by nm5.access.bullet.mail.gq1.yahoo.com with NNFMP; 19 Jul 2013 14:47:47 -0000 Received: from [98.138.84.183] by tm5.access.bullet.mail.gq1.yahoo.com with NNFMP; 19 Jul 2013 14:47:47 -0000 Received: from [127.0.0.1] by smtp105.sbc.mail.ne1.yahoo.com with NNFMP; 19 Jul 2013 14:47:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1374245267; bh=GW/Ypl7tolyL1yvDKoK5QN0JuxNze0iUcHurzEVvumY=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type; b=TumYwZRBu6GKXr6LU4mmQbVyTleceUHADbSUKozNWSnRHrdmdAFWppANqzHjk37PZJg572LRFnUgPXzR7L3I2THtMKTaGVWkmbYS0FS8CfjI4cJ0fJv86hBfxEriDOwN51quZyNIBIeBCrOz4cNPptCCeW57gtPuFGeGJb6FOjQ= X-Yahoo-Newman-Id: 174907.51927.bm@smtp105.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: jaQAopMVM1mtvSDmFm5xorMyMaD4fm8zkGwmTfb12.RvqX7 23mLUVaoa1v9Dsl5545.B_Uhc0dWN3mdt0J0uq.5fke9FcU8FZy.eEM1hk7F skOpNmGMDs_6ZJqRMwuFssKu7p0hBZgWjSV7p.Uxb6lBY0XN1OrFYFC_2ZTn JsTVBMYIWxi8E4ccjPMShU4AzQlcjCLF1wxubEYgW0z63LLTPFOSR6B2v5Bs jD24goBOhc.IqF7b5Ycz3r1fYAetsYK3sdDovBNQpu.aUySgdwl0hQCRLI2r .6fZQMIxr3.xLx6CnBpXf.10iljv05iaukLi2JiNP47ojDLNClSCN8FFPY1j J6YSjsCQCrmEh2lyHpKqCEFYhGZ0vIW8ZOU1Evw2iMCck1U_a4ui5Kd1Lg6l q9XKQ5t9ZQm7C24DDk6rEesQJ_c8ZkrrHI2_lNUkEfm7y7cUKnrUkh9oVwCM e6SQ.ukaiYxRZbilAH_uONTu1FefVaJqxGDuB022COhyHhUTtsK0fkskeRjl _eoDeP1ICwhjwuAQswA-- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-Rocket-Received: from [10.0.0.4] (d.sturek@69.108.48.182 with login) by smtp105.sbc.mail.ne1.yahoo.com with SMTP; 19 Jul 2013 14:47:47 +0000 UTC User-Agent: Microsoft-MacOutlook/14.3.6.130613 Date: Fri, 19 Jul 2013 07:45:15 -0700 From: Don Sturek To: "Mani, Mehdi" , "core@ietf.org" Message-ID: Thread-Topic: [core] COAP and DHCP In-Reply-To: <10F62A0D440ACA41A85C7CB02936A1DB5B44115483@ITR-EXMBXVS-1.itron.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3457064865_321077" Subject: Re: [core] COAP and DHCP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 14:47:54 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3457064865_321077 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Mehdi, We used SLAAC for ZigBee IP and did not find it "inefficient". First, the neighbor advertisements are 1 hop broadcasts. The DAD process was not an issue since you form your proposed address and send it to the border router which either approves/disapproves of the address (failure means you try again). I don't see how CoAP would make this process more efficient Don From: "Mani, Mehdi" Date: Friday, July 19, 2013 7:36 AM To: Don Sturek , "core@ietf.org" Subject: RE: [core] COAP and DHCP Don, =20 SLAAC is not efficient in meshed LLNs. First you have to broadcast your neighbor discovery message. Second you have to go through DAD process. -Mehdi =20 From: Don Sturek [mailto:d.sturek@att.net] Sent: mercredi 17 juillet 2013 18:33 To: Mani, Mehdi; core@ietf.org Subject: Re: [core] COAP and DHCP =20 Hi Mehdi, =20 In lieu of DHCP, why wouldn't a device simply use SLAAC? =20 Don =20 =20 From: "Mani, Mehdi" Date: Wednesday, July 17, 2013 8:10 AM To: "core@ietf.org" Subject: [core] COAP and DHCP =20 I=B9m wondering if in Core WG there has ever been a discussion about obtainin= g IPv6 address using COAP instead of using DHCP. In LLN, if we consider that COAP is used as management protocol which configure end-points, why not using that for configuring a node for its IP address. This could be especially interesting to reduce the registration transactions for LLN end-points. =20 Looking forward to hearing the interesting comments. Thanks -Mehdi _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core --B_3457064865_321077 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Hi Mehdi,

We used SLAAC for ZigBee IP and did not find it "inefficient". &nbs= p; First, the neighbor advertisements are 1 hop broadcasts.   The DAD p= rocess was not an issue since you form your proposed address and send it to = the border router which either approves/disapproves of the address (failure = means you try again).

I don't see how CoAP would ma= ke this process more efficient

Don


From: "Mani, Mehdi" &= lt;Mehdi.Mani@itron.com>
Date: Friday, July 19, 2013 7:36 AM
<= span style=3D"font-weight:bold">To: Don Sturek <d.sturek@att.net>, "cor= e@ietf.org" <core@ietf.org>
= Subject: RE: [core] COAP and DHCP
=

= Don,

<= o:p> 

SLAAC is not efficient in meshed LLNs. First you have to broadc= ast your neighbor discovery message. Second you have to go through DAD proce= ss.

-Mehdi

 

From: Don Sturek [mailto:d.sturek@att.net]
Sent: mercredi 17 juillet 2013 1= 8:33
To: Mani, Mehdi; core@ietf.org=
Subject: Re: [core] COAP and DHCP

=

 

=  

In lieu of DHCP,= why wouldn't a device simply use SLAAC?

 

Don

 

 

From: "Mani, Mehdi" <Mehdi.Mani@itron.com>
Date: Wednesd= ay, July 17, 2013 8:10 AM
To: "core= @ietf.org" <core@ietf.org>
<= b>Subject: [core] COAP and DHCP

 

I’m wondering if in Core= WG there has ever been a discussion about obtaining IPv6 address using COAP= instead of using DHCP.

In LLN, if we = consider that COAP is used as management protocol which configure end-points= , why not using that for configuring a node for its IP address. This could b= e especially interesting to reduce the registration transactions for LLN end= -points.

 

Looking forward to hearing the interesting comments.<= span style=3D"color:black">

Thanks<= /o:p>

= -Mehdi

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

--B_3457064865_321077-- From paduffy@cisco.com Fri Jul 19 08:06:21 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E82DD21E8106 for ; Fri, 19 Jul 2013 08:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 484Xov+QH8r0 for ; Fri, 19 Jul 2013 08:06:17 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 24F6821E80F2 for ; Fri, 19 Jul 2013 08:06:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13520; q=dns/txt; s=iport; t=1374246373; x=1375455973; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=Fu/Mfm7Y+1ej+KwrZlpsBK+yD5w6XQoF6nAlpbXNRtI=; b=eBHbnIkXyNIzJG0AAKSDPdRzbix18K8yoCUvLl2K3meeA49QjaH9peQK Oux3dJHLQumQahDXm19b78EayV3l8xViUbB9XimZ1n0G96EuDy03xX90u xNEhxLsyk87588ZMytUzdhyq9s/uVPAIOtqlHygRj5HI1hpC2zScM6Ykc I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAIVU6VGtJXG+/2dsb2JhbABbgkJENYk0t2OBDxZ0giQBAQEEAQEBKkEKARALEQQBAQEJFggHCQMCAQIBFR8JCAYNAQUCAQGIDAy3EgSOWIE3BgEGg3gDl12GI4sqgy6BTQ X-IronPort-AV: E=Sophos;i="4.89,702,1367971200"; d="scan'208,217";a="236984695" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 19 Jul 2013 15:06:12 +0000 Received: from [161.44.68.178] ([161.44.68.178]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6JF6B7u009836; Fri, 19 Jul 2013 15:06:11 GMT Message-ID: <51E955E3.9000209@cisco.com> Date: Fri, 19 Jul 2013 11:06:11 -0400 From: Paul Duffy Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Mani, Mehdi" References: <10F62A0D440ACA41A85C7CB02936A1DB5B440A278F@ITR-EXMBXVS-1.itron.com> <51E82658.1030405@cisco.com> <10F62A0D440ACA41A85C7CB02936A1DB5B4417C45A@ITR-EXMBXVS-1.itron.com> In-Reply-To: <10F62A0D440ACA41A85C7CB02936A1DB5B4417C45A@ITR-EXMBXVS-1.itron.com> Content-Type: multipart/alternative; boundary="------------040607010602060309010808" Cc: "core@ietf.org" Subject: Re: [core] COAP and DHCP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: paduffy@cisco.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 15:06:22 -0000 This is a multi-part message in MIME format. --------------040607010602060309010808 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Of the entire example flow you have described, the DHCPv6 overhead is but a small piece. Its a binary encoding moved over UDP, and Rapid Commit will usually limit the exchange to a single request/response. DHCP is often further used to provide other bootstrap details to the device ... like the address of the management system. Cheers On 7/19/2013 10:44 AM, Mani, Mehdi wrote: > > Paul, > > To answer to your question let's look at the whole process a node > should go through to be registered with a meshed LLN: > > 1)First it should go through link discovery > > 2)Authentication (802.1x) > > 3)Route establishment (for instance RPL) > > 4)DHCPv6 > > 5)Register with network management system (COAP) to obtain > configuration parameters etc. > > I'm looking at these steps and see that IPv6 assignment is as well a > kind of configuration why not doing that via COAP and skip one step; > keeping in mind that each of these 5 step transactions need message > exchange which is a burden on LLN node and network. > > -Mehdi > > *From:*core-bounces@ietf.org [mailto:core-bounces@ietf.org] *On Behalf > Of *Paul Duffy > *Sent:* jeudi 18 juillet 2013 19:31 > *To:* core@ietf.org > *Subject:* Re: [core] COAP and DHCP > > Hi Medhi > > What specific advantages do you see in using CoAP versus DHCP for > address management? > > > On 7/17/2013 11:10 AM, Mani, Mehdi wrote: > > I'm wondering if in Core WG there has ever been a discussion about > obtaining IPv6 address using COAP instead of using DHCP. > > In LLN, if we consider that COAP is used as management protocol > which configure end-points, why not using that for configuring a > node for its IP address. This could be especially interesting to > reduce the registration transactions for LLN end-points. > > Looking forward to hearing the interesting comments. > > Thanks > > -Mehdi > > > > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core > --------------040607010602060309010808 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Of the entire example flow you have described, the DHCPv6 overhead is but a small piece.  Its a binary encoding moved over UDP, and Rapid Commit will usually limit the exchange to a single request/response.  DHCP is often further used to provide other bootstrap details to the device ... like the address of the management system.

Cheers


On 7/19/2013 10:44 AM, Mani, Mehdi wrote:

Paul,

To answer to your question let’s look at the whole process a node should go through to be registered with a meshed LLN:

1)      First it should go through link discovery

2)      Authentication (802.1x)

3)      Route establishment (for instance RPL)

4)      DHCPv6

5)      Register with network management system (COAP) to obtain configuration parameters etc.

 

I’m looking at these steps and see that IPv6 assignment is as well a kind of configuration why not doing that via COAP and skip one step; keeping in mind that each of these 5 step transactions need message exchange which is a burden on LLN node and network.

-Mehdi

 

From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Paul Duffy
Sent: jeudi 18 juillet 2013 19:31
To: core@ietf.org
Subject: Re: [core] COAP and DHCP

 

Hi Medhi

What specific advantages do you see in using CoAP versus DHCP for address management?


On 7/17/2013 11:10 AM, Mani, Mehdi wrote:

I’m wondering if in Core WG there has ever been a discussion about obtaining IPv6 address using COAP instead of using DHCP.

In LLN, if we consider that COAP is used as management protocol which configure end-points, why not using that for configuring a node for its IP address. This could be especially interesting to reduce the registration transactions for LLN end-points.

 

Looking forward to hearing the interesting comments.

Thanks

-Mehdi




_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core

 


--------------040607010602060309010808-- From thp@comnets.uni-bremen.de Fri Jul 19 12:31:03 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 299D721F9A50 for ; Fri, 19 Jul 2013 12:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o0PN-SB0jeuv for ; Fri, 19 Jul 2013 12:30:59 -0700 (PDT) Received: from bugs.comnets.uni-bremen.de (bugs.comnets.uni-bremen.de [134.102.186.10]) by ietfa.amsl.com (Postfix) with ESMTP id EB97021F9A26 for ; Fri, 19 Jul 2013 12:30:58 -0700 (PDT) Received: from lloret.localnet (unknown [10.8.0.122]) by bugs.comnets.uni-bremen.de (Postfix) with ESMTPS id 85100D402B9 for ; Fri, 19 Jul 2013 21:30:51 +0200 (CEST) From: Thomas =?iso-8859-1?q?P=F6tsch?= To: core@ietf.org Date: Fri, 19 Jul 2013 21:30:46 +0200 User-Agent: KMail/1.13.7 (Linux/3.2.0-2-amd64; KDE/4.8.4; x86_64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201307192130.46855.thp@comnets.uni-bremen.de> Subject: [core] Fwd: New Version Notification for draft-becker-core-transport-scenarios-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 19:31:03 -0000 > A new version of I-D, draft-becker-core-transport-scenarios-00.txt > has been successfully submitted by Markus Becker and posted to the > IETF repository. > > Filename: draft-becker-core-transport-scenarios > Revision: 00 > Title: Scenarios for CoAP on non-UDP Transports > Creation date: 2013-07-15 > Group: Individual Submission > Number of pages: 13 > URL: > http://www.ietf.org/internet-drafts/draft-becker-core-transport-scenarios- > 00.txt Status: > http://datatracker.ietf.org/doc/draft-becker-core-transport-scenarios > Htmlized: > http://tools.ietf.org/html/draft-becker-core-transport-scenarios-00 > > > Abstract: > Several drafts in the CoRE WG are discussing the usage of CoAP on > non-UDP/IP transports already. There are various use cases for non- > UDP/IP transports. In order to structure the discussion, this draft > introduces new terminology and transport scenarios. > > > > > The IETF Secretariat From trac+core@trac.tools.ietf.org Sat Jul 20 09:57:12 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3974E11E810F for ; Sat, 20 Jul 2013 09:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YP2q+ip7WsJB for ; Sat, 20 Jul 2013 09:57:11 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 938CC11E80A5 for ; Sat, 20 Jul 2013 09:57:11 -0700 (PDT) Received: from localhost ([127.0.0.1]:48542 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1V0aT0-0007RC-Gh; Sat, 20 Jul 2013 18:57:10 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-observe@tools.ietf.org, hartke@tzi.org X-Trac-Project: core Date: Sat, 20 Jul 2013 16:57:10 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/333 Message-ID: <053.eaebf2584c86124636dd01b28b3dcfbc@trac.tools.ietf.org> X-Trac-Ticket-ID: 333 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-observe@tools.ietf.org, hartke@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: hartke@tzi.org Resent-Message-Id: <20130720165711.938CC11E80A5@ietfa.amsl.com> Resent-Date: Sat, 20 Jul 2013 09:57:11 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #333: Consistent sequence numbers across requests X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2013 16:57:12 -0000 #333: Consistent sequence numbers across requests observe-09 requires: The client MUST specify a token in its GET request that is currently not in use for the client/server pair, as the sequence numbers provide an order only among the notifications resulting from the same request. This requirement is not implementable if we assume that a client can reboot anytime and thereby forget which tokens were in use up to this point. If the client is still interested in a resource after a reboot, it will register again, potentially reusing a token that is still in use by the server. The problem can be solved by requiring that sequence numbers do not only provide an order among the notifications resulting from one request, but among all notifications resulting from all requests of one client for the same resource. Of course, a server can reboot anytime and thereby forget the state of its sequence number generator. When a server cannot provide consistent sequence numbers between two notifications, these notifications need to be at least 128 seconds apart. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- hartke@tzi.org | observe@tools.ietf.org Type: protocol | Status: new defect | Milestone: post-WGLC-1 Priority: minor | Version: Component: observe | Keywords: Severity: In WG Last | Call | -------------------------+------------------------------------------------- Ticket URL: core From Mehdi.Mani@itron.com Mon Jul 22 03:39:20 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D62A21E80F6 for ; Mon, 22 Jul 2013 03:39:20 -0700 (PDT) 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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pz1drXV-Splg for ; Mon, 22 Jul 2013 03:39:15 -0700 (PDT) Received: from mail.itron.com (mail.itron.com [198.182.8.115]) by ietfa.amsl.com (Postfix) with ESMTP id 6BAFF21E80A1 for ; Mon, 22 Jul 2013 03:26:59 -0700 (PDT) Received: from ITR-EXMBXVS-1.itron.com ([192.168.9.112]) by spo-exchcn-1.itron.com ([192.168.9.115]) with mapi; Mon, 22 Jul 2013 03:26:49 -0700 From: "Mani, Mehdi" To: Don Sturek , "core@ietf.org" Date: Mon, 22 Jul 2013 03:26:48 -0700 Thread-Topic: [core] COAP and DHCP Thread-Index: Ac6EjvAfnECw/dSpSKekMkf7xx7nxwCM0A5Q Message-ID: <10F62A0D440ACA41A85C7CB02936A1DB5B4417CA82@ITR-EXMBXVS-1.itron.com> References: <10F62A0D440ACA41A85C7CB02936A1DB5B44115483@ITR-EXMBXVS-1.itron.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: multipart/alternative; boundary="_000_10F62A0D440ACA41A85C7CB02936A1DB5B4417CA82ITREXMBXVS1it_" MIME-Version: 1.0 Subject: Re: [core] COAP and DHCP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 10:39:20 -0000 --_000_10F62A0D440ACA41A85C7CB02936A1DB5B4417CA82ITREXMBXVS1it_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Don, It really is a matter of size of the network and the application. There are= scenarios with limited number of nodes in a network where SLAAC can work b= ut in the populated meshed LLNs, DAD process is really inefficient and it i= s preferable that a server assigns the IP addresses to the nodes since the= probability of address conflict in SLAAC is high. Moreover the server can = assign the addresses which can be compressed more efficiently by 6LowPan. W= hat I'm saying is that if COAP is going to be standardized as a protocol fo= r managing/configuring LLNs and has the ability of service/resource discove= ry, why not using that as well for address assignment. -Mehdi From: Don Sturek [mailto:d.sturek@att.net] Sent: vendredi 19 juillet 2013 16:45 To: Mani, Mehdi; core@ietf.org Subject: Re: [core] COAP and DHCP Hi Mehdi, We used SLAAC for ZigBee IP and did not find it "inefficient". First, the= neighbor advertisements are 1 hop broadcasts. The DAD process was not an= issue since you form your proposed address and send it to the border route= r which either approves/disapproves of the address (failure means you try a= gain). I don't see how CoAP would make this process more efficient Don From: "Mani, Mehdi" > Date: Friday, July 19, 2013 7:36 AM To: Don Sturek >, "core@ietf.org<= mailto:core@ietf.org>" > Subject: RE: [core] COAP and DHCP Don, SLAAC is not efficient in meshed LLNs. First you have to broadcast your nei= ghbor discovery message. Second you have to go through DAD process. -Mehdi From: Don Sturek [mailto:d.sturek@att.net] Sent: mercredi 17 juillet 2013 18:33 To: Mani, Mehdi; core@ietf.org Subject: Re: [core] COAP and DHCP Hi Mehdi, In lieu of DHCP, why wouldn't a device simply use SLAAC? Don From: "Mani, Mehdi" > Date: Wednesday, July 17, 2013 8:10 AM To: "core@ietf.org" > Subject: [core] COAP and DHCP I'm wondering if in Core WG there has ever been a discussion about obtainin= g IPv6 address using COAP instead of using DHCP. In LLN, if we consider that COAP is used as management protocol which confi= gure end-points, why not using that for configuring a node for its IP addre= ss. This could be especially interesting to reduce the registration transac= tions for LLN end-points. Looking forward to hearing the interesting comments. Thanks -Mehdi _______________________________________________ core mailing list core@ietf= .org https://www.ietf.org/mailman/listinfo/core --_000_10F62A0D440ACA41A85C7CB02936A1DB5B4417CA82ITREXMBXVS1it_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Don,

 

It really is a matter of size of the ne= twork and the application. There are scenarios with limited number of nodes= in a network where SLAAC can work but in the populated meshed LLNs, DAD pr= ocess is really inefficient and it is  preferable that a server assign= s the IP addresses to the nodes since the probability of address conflict i= n SLAAC is high. Moreover the server can assign the addresses which can be = compressed more efficiently by 6LowPan. What I’m saying is that if CO= AP is going to be standardized as a protocol for managing/configuring LLNs = and has the ability of service/resource discovery, why not using that as we= ll for address assignment.

 

-Mehdi

 

From:= Don Sturek [mailto:d.sturek@att.net]
Sent: vend= redi 19 juillet 2013 16:45
To: Mani, Mehdi; core@ietf.org
S= ubject: Re: [core] COAP and DHCP

 

Hi Me= hdi,

 =

We used SLAAC for Zi= gBee IP and did not find it "inefficient".   First, the neig= hbor advertisements are 1 hop broadcasts.   The DAD process was not an= issue since you form your proposed address and send it to the border route= r which either approves/disapproves of the address (failure means you try a= gain).

&nbs= p;

I don't see how Co= AP would make this process more efficient

<= p class=3DMsoNormal> 

Don

 

 

From: "Mani, = Mehdi" <Mehdi.Mani@itron.co= m>
Date: Friday, July 19, 2013 7:36 AM
To: Don S= turek <d.sturek@att.net>, &qu= ot;core@ietf.org" <core@ietf.org>
Subject: RE: [core] C= OAP and DHCP

 

Don,

 

SLAAC is not efficient in meshed LLNs. Fir= st you have to broadcast your neighbor discovery message. Second you have t= o go through DAD process.

-Me= hdi

 

<= b>From: Don Sturek [mailto:d.sturek@att.net]
Sent: mer= credi 17 juillet 2013 18:33
To: Mani, Mehdi; core@ietf.org
Subject: Re: [core] COAP and DHCP<= /span>

 

=

Hi Mehdi,

 

In lieu of DHCP, why wouldn't a device simply use SLAAC?

 

Don

 

 

From: "Mani, Mehdi" <Mehdi.Mani@itron.com>
Date: Wedn= esday, July 17, 2013 8:10 AM
To: "core@ietf.org" <core@ie= tf.org>
Subject: [core] COAP and DHCP

 

I’m wondering if in Core WG there has = ever been a discussion about obtaining IPv6 address using COAP instead of u= sing DHCP.

In LLN, if we conside= r that COAP is used as management protocol which configure end-points, why = not using that for configuring a node for its IP address. This could be esp= ecially interesting to reduce the registration transactions for LLN end-poi= nts.

 

Looking forward to hearing the interesting comments.=

Thanks

-Mehdi

_____________________________= __________________ core mailing list core@= ietf.org https:/= /www.ietf.org/mailman/listinfo/core =

= --_000_10F62A0D440ACA41A85C7CB02936A1DB5B4417CA82ITREXMBXVS1it_-- From yusuke.doi@toshiba.co.jp Mon Jul 22 04:05:03 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A36421F9970 for ; Mon, 22 Jul 2013 04:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.089 X-Spam-Level: X-Spam-Status: No, score=-6.089 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0hXD-3rFXbtR for ; Mon, 22 Jul 2013 04:04:57 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id 30DD621F8F67 for ; Mon, 22 Jul 2013 04:04:56 -0700 (PDT) Received: from tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp ([133.199.200.50]) by imx2.toshiba.co.jp with ESMTP id r6MB3qDO019626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 22 Jul 2013 20:03:52 +0900 (JST) Received: from tsbmgw-mgw02 (localhost [127.0.0.1]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r6MB3q2n029828 for ; Mon, 22 Jul 2013 20:03:52 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw02 (JAMES SMTP Server 2.3.1) with SMTP ID 252 for ; Mon, 22 Jul 2013 20:03:52 +0900 (JST) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r6MB3plE029822 for ; Mon, 22 Jul 2013 20:03:51 +0900 Received: (from root@localhost) by arc1.toshiba.co.jp id r6MB3pZM017867 for core@ietf.org; Mon, 22 Jul 2013 20:03:51 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id WAA17865; Mon, 22 Jul 2013 20:03:51 +0900 Received: from mx12.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id r6MB3p1I025397 for ; Mon, 22 Jul 2013 20:03:51 +0900 (JST) Received: from spiffy21.isl.rdc.toshiba.co.jp by toshiba.co.jp id r6MB3pOY014981; Mon, 22 Jul 2013 20:03:51 +0900 (JST) Received: from [133.196.16.88] (ncg-dhcp88.isl.rdc.toshiba.co.jp [133.196.16.88]) by spiffy21.isl.rdc.toshiba.co.jp (Postfix) with ESMTPS id 17D6997D43; Mon, 22 Jul 2013 20:03:51 +0900 (JST) Message-ID: <51ED1196.2010202@toshiba.co.jp> Date: Mon, 22 Jul 2013 20:03:50 +0900 From: Yusuke DOI User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Mani, Mehdi" References: <10F62A0D440ACA41A85C7CB02936A1DB5B440A278F@ITR-EXMBXVS-1.itron.com> In-Reply-To: <10F62A0D440ACA41A85C7CB02936A1DB5B440A278F@ITR-EXMBXVS-1.itron.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp id r6MB3plE029822 Cc: "core@ietf.org" Subject: Re: [core] COAP and DHCP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 11:05:04 -0000 Dear Mehdi, I think if LLN nodes require some 'rich system-wide configuration' (an ex= ample is MPL parameter), something like CoAP resource binding to DHCPv6 o= ption settings may work as replacement of stateless DHCPv6 (to get rid of= stateless DHCP code from CoAP-based LLN devices). However, I have no ide= a on how to let clients know default CoAP server address to send 'Informa= tion-request' messages to. Regards, Yusuke (2013-07-18 00:10), Mani, Mehdi wrote: > I=92m wondering if in Core WG there has ever been a discussion about ob= taining IPv6 address using COAP instead of using DHCP. > > In LLN, if we consider that COAP is used as management protocol which c= onfigure end-points, why not using that for configuring a node for its IP= address. This could be especially interesting to reduce the registration= transactions for LLN end-points. > > Looking forward to hearing the interesting comments. > > Thanks > > -Mehdi > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From Mehdi.Mani@itron.com Mon Jul 22 06:19:14 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 366C021E80AA for ; Mon, 22 Jul 2013 06:19:14 -0700 (PDT) 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=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0tKgvbDO4JFx for ; Mon, 22 Jul 2013 06:19:10 -0700 (PDT) Received: from mail.itron.com (mail.itron.com [198.182.8.116]) by ietfa.amsl.com (Postfix) with ESMTP id 0345C11E8108 for ; Mon, 22 Jul 2013 06:19:09 -0700 (PDT) Received: from ITR-EXMBXVS-1.itron.com ([192.168.9.112]) by spo-exchcn-2.itron.com ([192.168.9.116]) with mapi; Mon, 22 Jul 2013 06:19:05 -0700 From: "Mani, Mehdi" To: Yusuke DOI Date: Mon, 22 Jul 2013 06:19:03 -0700 Thread-Topic: [core] COAP and DHCP Thread-Index: Ac6GyzuURDTI0564SRS7rAWvUwXPewAEDIrQ Message-ID: <10F62A0D440ACA41A85C7CB02936A1DB5B4417CD26@ITR-EXMBXVS-1.itron.com> References: <10F62A0D440ACA41A85C7CB02936A1DB5B440A278F@ITR-EXMBXVS-1.itron.com> <51ED1196.2010202@toshiba.co.jp> In-Reply-To: <51ED1196.2010202@toshiba.co.jp> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "core@ietf.org" Subject: Re: [core] COAP and DHCP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 13:19:14 -0000 Hi Yusuke, It is in fact one of the advantages to get rid of DHCP codes on LLN end-poi= nt. I don't know either if COAP is able to provide a kind of autonomous ser= vice discovery for LLN devices but it could be one of the interesting aspec= ts that can be added to COAP feature; especially that COAP is supposed to h= elp the end-points with their resource and service discovery. Thanks -Mehdi -----Original Message----- From: Yusuke DOI [mailto:yusuke.doi@toshiba.co.jp]=20 Sent: lundi 22 juillet 2013 13:04 To: Mani, Mehdi Cc: core@ietf.org Subject: Re: [core] COAP and DHCP Dear Mehdi, I think if LLN nodes require some 'rich system-wide configuration' (an exam= ple is MPL parameter), something like CoAP resource binding to DHCPv6 optio= n settings may work as replacement of stateless DHCPv6 (to get rid of state= less DHCP code from CoAP-based LLN devices). However, I have no idea on how= to let clients know default CoAP server address to send 'Information-reque= st' messages to. Regards, Yusuke (2013-07-18 00:10), Mani, Mehdi wrote: > I'm wondering if in Core WG there has ever been a discussion about obtain= ing IPv6 address using COAP instead of using DHCP. > > In LLN, if we consider that COAP is used as management protocol which con= figure end-points, why not using that for configuring a node for its IP add= ress. This could be especially interesting to reduce the registration trans= actions for LLN end-points. > > Looking forward to hearing the interesting comments. > > Thanks > > -Mehdi > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From lars@netapp.com Mon Jul 22 06:51:58 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31BA221F8F4F; Mon, 22 Jul 2013 06:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.08 X-Spam-Level: X-Spam-Status: No, score=-5.08 tagged_above=-999 required=5 tests=[AWL=-2.481, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SpkXUs8ldk4B; Mon, 22 Jul 2013 06:51:47 -0700 (PDT) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id 9103B11E8109; Mon, 22 Jul 2013 06:51:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,719,1367996400"; d="scan'208";a="35553587" Received: from vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) by mx11-out.netapp.com with ESMTP; 22 Jul 2013 06:51:22 -0700 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.240]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.03.0123.003; Mon, 22 Jul 2013 06:51:21 -0700 From: "Eggert, Lars" To: "core@ietf.org" , "roll@ietf.org" Thread-Topic: IETF Mentor Program Thread-Index: AQHOdpL426xbQQmM6keWdRwN12iKdA== Date: Mon, 22 Jul 2013 13:51:21 +0000 Message-ID: <285EAD53-1801-461E-813F-D0C250DDE03E@netapp.com> References: <20130701193936.10181.90437.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: text/plain; charset="us-ascii" Content-ID: <8C64DFD8A925C3448F010A88BED7303C@hq.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 22 Jul 2013 06:56:31 -0700 Subject: [core] Fwd: IETF Mentor Program X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 13:52:01 -0000 Hi, I'm one of the folks matching up mentors and newcomers. We have a few newco= mers that are interested in IoT, but VERY few IoT folks volunteering to be = mentors. Please step up! And soon! Lars Begin forwarded message: > From: IETF Chair > Subject: IETF Mentor Program > Date: July 1, 2013 21:39:36 GMT+02:00 > To: IETF Announcement List > Reply-To: >=20 > Hi all, >=20 > Based on discussions during IETF 86, we are trialing an IETF mentoring = program. During this trial period, we would like to pair newcomers (people= who have attended 3 or fewer meetings or have registered as students) with= existing IETF participants. The goal is to provide a resource for the new= comer who can assist them with integrating into the IETF community. Mentor= s and newcomers will be paired prior to IETF 87. >=20 > What we need is for people to volunteer to be mentors. As a mentor, we = would ask that you be willing to assist your mentoring participant before, = during, and (hopefully) after IETF 87. The actual level of interaction wil= l be driven by an agreement between the mentor and the mentoring participan= t. Additionally, we would need a brief description of your areas of experti= se, technical interests, and conversational languages. >=20 > A description of the Mentor Program (including a FAQ describing > how to volunteer to be a mentor) is available: >=20 > http://www.ietf.org/resources/mentoring-program.html. >=20 > Anyone interested in being a mentor should follow the sign-up > instructions contained in the above URL. The more volunteers we have, > the stronger the program will be! >=20 > Regards, > IETF Chair From d.sturek@att.net Mon Jul 22 07:13:03 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1B8911E8112 for ; Mon, 22 Jul 2013 07:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ML5Bm8b1S+T3 for ; Mon, 22 Jul 2013 07:12:58 -0700 (PDT) Received: from nm20-vm5.access.bullet.mail.bf1.yahoo.com (nm20-vm5.access.bullet.mail.bf1.yahoo.com [216.109.115.116]) by ietfa.amsl.com (Postfix) with ESMTP id 652AE11E8101 for ; Mon, 22 Jul 2013 07:12:58 -0700 (PDT) Received: from [66.196.81.159] by nm20.access.bullet.mail.bf1.yahoo.com with NNFMP; 22 Jul 2013 14:12:56 -0000 Received: from [98.138.84.183] by tm5.access.bullet.mail.bf1.yahoo.com with NNFMP; 22 Jul 2013 14:12:56 -0000 Received: from [127.0.0.1] by smtp105.sbc.mail.ne1.yahoo.com with NNFMP; 22 Jul 2013 14:12:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1374502376; bh=6fFJe2NnrwXaYKXy+8Upv70nmk2Tw/W1IKOY/3CROKo=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=LOroELuTwUFl1RXvVy1NaK83qq2uw04uB0OHDa0a6ws1USqhYAiyvyiWtNXadc0RaNSy/odymhvH5ZVM/58LybqDiHluKlqP0F+PRefbGLHCe0sfvgsM/fTxMfs0I/DOmQcINqZ/C7+o5Ou2468z4OrzQaMwXoUpRFam5XGOdPw= X-Yahoo-Newman-Id: 731692.96816.bm@smtp105.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: zHQqnggVM1lKNO65YRbSIPoldFLMR5Uovp85s.qLDrNU32_ J5DxwmP7KrhZ8fCDoQkxRm48TQ0LmBsA38qQXXOaDrstb1xmem7xu4u1GOvR Uw9z_rZ1AYP3dGQd8bUKAHpZc4pU09C5Sj9mmAXA1FJhwcfTXPburyRKbe5s qmMyw3TwT_qx04aah.yBiBFcw0L87IPihGrzZjGbANEak8_wUL3DZFpTWLVH bwHRcAGINU..BJMoY.IjO7aVAfc2K6FQso82HMaPmLjgnyucN5evi._xioIo GiK8MuEL7bmjBg3f0oHwVdy0V12GLZoFYAQGdqbejXQs6ds4l345bS37Lq57 ECr9VsTqZmUmQ.CFVugV9eAkwu4TrDawBueWLz5iVHg7DYDWmr1JL8pPcuYn bDppKVk.0SoUrlj07QEUufLOjlQXELH_8fotudRpqfl_0ewuuY4UvcK3xzas wfGH5LpopZ6.GXR8dey2JMNfc32ZT9myVfT3rhgaaGWLNGyNHhEtok6PP5R. pDzvVIYFF.20eBgWRUtc- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-Rocket-Received: from [10.0.0.4] (d.sturek@67.124.200.231 with login) by smtp105.sbc.mail.ne1.yahoo.com with SMTP; 22 Jul 2013 14:12:56 +0000 UTC User-Agent: Microsoft-MacOutlook/14.3.6.130613 Date: Mon, 22 Jul 2013 07:05:48 -0700 From: Don Sturek To: "Eggert, Lars" , "core@ietf.org" , "roll@ietf.org" Message-ID: Thread-Topic: [core] Fwd: IETF Mentor Program In-Reply-To: <285EAD53-1801-461E-813F-D0C250DDE03E@netapp.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [core] Fwd: IETF Mentor Program X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 14:13:04 -0000 Hi Lars, My name is Don Sturek and I would be interested in signing up as a mentor. I spent a good deal of time working in the IETF on a variety of drafts around IoT as part of ZigBee IP (plus added drafts to 6MAN which formed part of the problem statement for Homenet and also participated in a barBOF in Stockholm which provided some requirements for Core.....) Don On 7/22/13 6:51 AM, "Eggert, Lars" wrote: >Hi, > >I'm one of the folks matching up mentors and newcomers. We have a few >newcomers that are interested in IoT, but VERY few IoT folks volunteering >to be mentors. Please step up! And soon! > >Lars > >Begin forwarded message: > >> From: IETF Chair >> Subject: IETF Mentor Program >> Date: July 1, 2013 21:39:36 GMT+02:00 >> To: IETF Announcement List >> Reply-To: >> >> Hi all, >> >> Based on discussions during IETF 86, we are trialing an IETF >>mentoring program. During this trial period, we would like to pair >>newcomers (people who have attended 3 or fewer meetings or have >>registered as students) with existing IETF participants. The goal is to >>provide a resource for the newcomer who can assist them with integrating >>into the IETF community. Mentors and newcomers will be paired prior to >>IETF 87. >> >> What we need is for people to volunteer to be mentors. As a mentor, >>we would ask that you be willing to assist your mentoring participant >>before, during, and (hopefully) after IETF 87. The actual level of >>interaction will be driven by an agreement between the mentor and the >>mentoring participant. Additionally, we would need a brief description >>of your areas of expertise, technical interests, and conversational >>languages. >> >> A description of the Mentor Program (including a FAQ describing >> how to volunteer to be a mentor) is available: >> >> http://www.ietf.org/resources/mentoring-program.html. >> >> Anyone interested in being a mentor should follow the sign-up >> instructions contained in the above URL. The more volunteers we have, >> the stronger the program will be! >> >> Regards, >> IETF Chair > >_______________________________________________ >core mailing list >core@ietf.org >https://www.ietf.org/mailman/listinfo/core From d.sturek@att.net Mon Jul 22 07:13:09 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0767B11E8115 for ; Mon, 22 Jul 2013 07:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.459 X-Spam-Level: X-Spam-Status: No, score=-2.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lq-wzhUTP8P0 for ; Mon, 22 Jul 2013 07:13:03 -0700 (PDT) Received: from nm26-vm6.access.bullet.mail.bf1.yahoo.com (nm26-vm6.access.bullet.mail.bf1.yahoo.com [216.109.115.213]) by ietfa.amsl.com (Postfix) with ESMTP id 293BF11E8111 for ; Mon, 22 Jul 2013 07:12:59 -0700 (PDT) Received: from [66.196.81.157] by nm26.access.bullet.mail.bf1.yahoo.com with NNFMP; 22 Jul 2013 14:12:58 -0000 Received: from [98.138.84.183] by tm3.access.bullet.mail.bf1.yahoo.com with NNFMP; 22 Jul 2013 14:12:58 -0000 Received: from [127.0.0.1] by smtp105.sbc.mail.ne1.yahoo.com with NNFMP; 22 Jul 2013 14:12:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1374502378; bh=G1B4B0wdt5hAh1Y/jpckeFa7YpLpgBmCV+16gj4ojyI=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=npVeZEz4G7JvHYt4u3HoiHDnMKvD3pwQKr1DlhWR+2I2d0Kj++I2pCkN4GXwiWJy2bGrxuJE5TgohNlHhj9YxFhEhzorKbj4g5tqvo0DnWG0z4A6hRVaJ+0eyALphjjwPKQFX4VLhIQcqUL5j+en4vRqIfIACFRYeFZ35nMtqIE= X-Yahoo-Newman-Id: 77729.96816.bm@smtp105.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: EAtHJBgVM1kNZn8CJ2tIvm1RiE1LS0zzbthbIIgjK7z5wrU HUIp7JKRLPz4Oj_oVPcIfSwR7wshC2hxlFmzxQboxfLkm.UKltAzYT45squ_ twZBWqo24VtOxE2sSokT46FW_oHrkGXG.hZljEWE_hbks1d2PQskqEoq_S89 zlYLlt3XXeJ.4ViCQtbDGD31LQIqGYDM.LwfXqkB5EKsugy9NKXGdRDy477V tYxeuZoIRbBF9HQd2WTDyYJS_f7QsL.K_fDt7uxIaJRzipK9tJ44vOPqcOFP jH2XJR1adZzR3tVJtH6vH7_XJIa0ok_DbnSnbjKuJoikfr.bxrQ2jQH6BP.d kysk5eZiqajnL3KdXQ6dMD1eMBu6oo0gHvQY0OhAtneJuuB6IVNLqHIOh7Fb Ix0QTIQTRETCMqMsk5CRHQfbTj.I474IAAJ6f.G5PqlffnEtvydBu4SSyqrH 3c3Nw_SH3z45UBzgD5sVz2x.dlOiZMUidE.3ygf8a6vYMkCho8YPmShSFclz 7Cr5ezgMngWm88HHIOvc- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-Rocket-Received: from [10.0.0.4] (d.sturek@67.124.200.231 with login) by smtp105.sbc.mail.ne1.yahoo.com with SMTP; 22 Jul 2013 14:12:58 +0000 UTC User-Agent: Microsoft-MacOutlook/14.3.6.130613 Date: Mon, 22 Jul 2013 07:11:46 -0700 From: Don Sturek To: "Mani, Mehdi" , Yusuke DOI Message-ID: Thread-Topic: [core] COAP and DHCP In-Reply-To: <10F62A0D440ACA41A85C7CB02936A1DB5B4417CD26@ITR-EXMBXVS-1.itron.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "core@ietf.org" Subject: Re: [core] COAP and DHCP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 14:13:09 -0000 Hi Mehdi, I did see your earlier post regarding address assignment via CoAP..... I have to say, I think it is not wise to overload address assignment on CoAP (which is really an application support protocol). CoAP does support service discovery on ".well-known" (sorry if I got the syntax wrong, this is from memory). If a richer service discovery is wanted/needed, we should consider adding in a different standard rather than try to add those features directly into CoAP. Don On 7/22/13 6:19 AM, "Mani, Mehdi" wrote: >Hi Yusuke, > >It is in fact one of the advantages to get rid of DHCP codes on LLN >end-point. I don't know either if COAP is able to provide a kind of >autonomous service discovery for LLN devices but it could be one of the >interesting aspects that can be added to COAP feature; especially that >COAP is supposed to help the end-points with their resource and service >discovery. > >Thanks >-Mehdi > > >-----Original Message----- >From: Yusuke DOI [mailto:yusuke.doi@toshiba.co.jp] >Sent: lundi 22 juillet 2013 13:04 >To: Mani, Mehdi >Cc: core@ietf.org >Subject: Re: [core] COAP and DHCP > >Dear Mehdi, > >I think if LLN nodes require some 'rich system-wide configuration' (an >example is MPL parameter), something like CoAP resource binding to DHCPv6 >option settings may work as replacement of stateless DHCPv6 (to get rid >of stateless DHCP code from CoAP-based LLN devices). However, I have no >idea on how to let clients know default CoAP server address to send >'Information-request' messages to. > >Regards, > >Yusuke > >(2013-07-18 00:10), Mani, Mehdi wrote: >> I'm wondering if in Core WG there has ever been a discussion about >>obtaining IPv6 address using COAP instead of using DHCP. >> >> In LLN, if we consider that COAP is used as management protocol which >>configure end-points, why not using that for configuring a node for its >>IP address. This could be especially interesting to reduce the >>registration transactions for LLN end-points. >> >> Looking forward to hearing the interesting comments. >> >> Thanks >> >> -Mehdi >> >> >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> > > >_______________________________________________ >core mailing list >core@ietf.org >https://www.ietf.org/mailman/listinfo/core From zach@sensinode.com Mon Jul 22 07:43:00 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46F2E11E80E7 for ; Mon, 22 Jul 2013 07:43:00 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lyo9BtrEgEVx for ; Mon, 22 Jul 2013 07:42:54 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 798DB11E80AE for ; Mon, 22 Jul 2013 07:42:53 -0700 (PDT) Received: from [192.168.1.103] (87-95-138-34.bb.dnainternet.fi [87.95.138.34]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id r6MEgeMr015756 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 22 Jul 2013 17:42:46 +0300 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Zach Shelby In-Reply-To: Date: Mon, 22 Jul 2013 17:42:38 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <6CA497E5-0C06-48AF-AD7B-93C387E1F5A1@sensinode.com> References: To: Don Sturek X-Mailer: Apple Mail (2.1503) Cc: "core@ietf.org" Subject: Re: [core] COAP and DHCP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 14:43:00 -0000 Mehdi, I agree with Don here, it is not a great idea to mix basic IP network = configuration services over a generic web protocol like CoAP. We can't = really depend on having CoAP available to do something basic like = address assignment. That needs to work even when no application layer is = present, e.g. in a pure router. That said, we surely can manage a = device, e.g. perform firmware updates, update application configuration = parameters etc. over CoAP. For example the OMA Lightweight M2M standard = does exactly this over CoAP using Object definitions (like a MIB). That = works great for things that are independent of the IP network. The discovery built into CoAP is meant to be used for resource = discovery, i.e. discovering what web resources a CoAP server has = available. It was not designed to be used as a generic service discovery = mechanism. If you don't even know what protocol to use for your service, = then you probably need something like DNS-SD first. Regards, Zach On Jul 22, 2013, at 5:11 PM, Don Sturek wrote: > Hi Mehdi, >=20 > I did see your earlier post regarding address assignment via CoAP..... >=20 > I have to say, I think it is not wise to overload address assignment = on > CoAP (which is really an application support protocol). CoAP does > support service discovery on ".well-known" (sorry if I got the syntax > wrong, this is from memory). If a richer service discovery is > wanted/needed, we should consider adding in a different standard = rather > than try to add those features directly into CoAP. >=20 > Don >=20 >=20 >=20 > On 7/22/13 6:19 AM, "Mani, Mehdi" wrote: >=20 >> Hi Yusuke, >>=20 >> It is in fact one of the advantages to get rid of DHCP codes on LLN >> end-point. I don't know either if COAP is able to provide a kind of >> autonomous service discovery for LLN devices but it could be one of = the >> interesting aspects that can be added to COAP feature; especially = that >> COAP is supposed to help the end-points with their resource and = service >> discovery. >>=20 >> Thanks >> -Mehdi >>=20 >>=20 >> -----Original Message----- >> From: Yusuke DOI [mailto:yusuke.doi@toshiba.co.jp] >> Sent: lundi 22 juillet 2013 13:04 >> To: Mani, Mehdi >> Cc: core@ietf.org >> Subject: Re: [core] COAP and DHCP >>=20 >> Dear Mehdi, >>=20 >> I think if LLN nodes require some 'rich system-wide configuration' = (an >> example is MPL parameter), something like CoAP resource binding to = DHCPv6 >> option settings may work as replacement of stateless DHCPv6 (to get = rid >> of stateless DHCP code from CoAP-based LLN devices). However, I have = no >> idea on how to let clients know default CoAP server address to send >> 'Information-request' messages to. >>=20 >> Regards, >>=20 >> Yusuke >>=20 >> (2013-07-18 00:10), Mani, Mehdi wrote: >>> I'm wondering if in Core WG there has ever been a discussion about >>> obtaining IPv6 address using COAP instead of using DHCP. >>>=20 >>> In LLN, if we consider that COAP is used as management protocol = which >>> configure end-points, why not using that for configuring a node for = its >>> IP address. This could be especially interesting to reduce the >>> registration transactions for LLN end-points. >>>=20 >>> Looking forward to hearing the interesting comments. >>>=20 >>> Thanks >>>=20 >>> -Mehdi >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>>=20 >>=20 >>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com @SensinodeIoT Mobile: +358 40 7796297 Twitter: @zach_shelby LinkedIn: http://fi.linkedin.com/in/zachshelby 6LoWPAN Book: http://6lowpan.net From yusuke.doi@toshiba.co.jp Mon Jul 22 09:06:16 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D2E311E80D9 for ; Mon, 22 Jul 2013 09:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.09 X-Spam-Level: X-Spam-Status: No, score=-6.09 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qIy38iWeRWFD for ; Mon, 22 Jul 2013 09:06:11 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by ietfa.amsl.com (Postfix) with ESMTP id 7205D21E80A8 for ; Mon, 22 Jul 2013 09:06:11 -0700 (PDT) Received: from tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp ([133.199.232.103]) by imx12.toshiba.co.jp with ESMTP id r6MG6ATr026650 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 23 Jul 2013 01:06:10 +0900 (JST) Received: from tsbmgw-mgw01 (localhost [127.0.0.1]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r6MG6A1M024426 for ; Tue, 23 Jul 2013 01:06:10 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw01 (JAMES SMTP Server 2.3.1) with SMTP ID 167 for ; Tue, 23 Jul 2013 01:06:10 +0900 (JST) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r6MG6AIg024420 for ; Tue, 23 Jul 2013 01:06:10 +0900 Received: (from root@localhost) by arc11.toshiba.co.jp id r6MG6AaR000718 for core@ietf.org; Tue, 23 Jul 2013 01:06:10 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id BAA00716; Tue, 23 Jul 2013 01:06:10 +0900 Received: from mx11.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id r6MG69ce027817 for ; Tue, 23 Jul 2013 01:06:09 +0900 (JST) Received: by toshiba.co.jp id r6MG69jw017794; Tue, 23 Jul 2013 01:06:09 +0900 (JST) Date: Tue, 23 Jul 2013 01:06:08 +0900 (JST) Message-Id: <201307221606.r6MG69jw017794@toshiba.co.jp> To: zach@sensinode.com From: DOI Yusuke In-Reply-To: <6CA497E5-0C06-48AF-AD7B-93C387E1F5A1@sensinode.com> References: <6CA497E5-0C06-48AF-AD7B-93C387E1F5A1@sensinode.com> X-Mailer: Mew version 6.3 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: core@ietf.org Subject: Re: [core] COAP and DHCP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 16:06:16 -0000 Dear Zach, Don, I also agree it would be not a good idea to do address configuration over CoAP. But I think, especially for SLAAC-based LLNs, we don't have a handy channel to distribute non-essential configurations, such as DNS server address or MPL parameters to be used in the network. DNS-SD could not be a good choice for, to say, 1000 nodes of LLN with 5 hops or more. The choice in my mind is to deploy DHCP-relay over nodes and to use stateless DHCP to distribute such configuration parameters. It should work well and I'm okay with it (so far, not tried to implement it yet). At the same time I wonder if there is other choices such as Stateless-DHCP-Option-to-CoAP-Resource mapping. Regards, Yusuke From: Zach Shelby Subject: Re: [core] COAP and DHCP Date: Mon, 22 Jul 2013 17:42:38 +0300 > Mehdi, > > I agree with Don here, it is not a great idea to mix basic IP network configuration services over a generic web protocol like CoAP. We can't really depend on having CoAP available to do something basic like address assignment. That needs to work even when no application layer is present, e.g. in a pure router. That said, we surely can manage a device, e.g. perform firmware updates, update application configuration parameters etc. over CoAP. For example the OMA Lightweight M2M standard does exactly this over CoAP using Object definitions (like a MIB). That works great for things that are independent of the IP network. > > The discovery built into CoAP is meant to be used for resource discovery, i.e. discovering what web resources a CoAP server has available. It was not designed to be used as a generic service discovery mechanism. If you don't even know what protocol to use for your service, then you probably need something like DNS-SD first. > > Regards, > Zach > > On Jul 22, 2013, at 5:11 PM, Don Sturek wrote: > >> Hi Mehdi, >> >> I did see your earlier post regarding address assignment via CoAP..... >> >> I have to say, I think it is not wise to overload address assignment on >> CoAP (which is really an application support protocol). CoAP does >> support service discovery on ".well-known" (sorry if I got the syntax >> wrong, this is from memory). If a richer service discovery is >> wanted/needed, we should consider adding in a different standard rather >> than try to add those features directly into CoAP. >> >> Don >> >> >> >> On 7/22/13 6:19 AM, "Mani, Mehdi" wrote: >> >>> Hi Yusuke, >>> >>> It is in fact one of the advantages to get rid of DHCP codes on LLN >>> end-point. I don't know either if COAP is able to provide a kind of >>> autonomous service discovery for LLN devices but it could be one of the >>> interesting aspects that can be added to COAP feature; especially that >>> COAP is supposed to help the end-points with their resource and service >>> discovery. >>> >>> Thanks >>> -Mehdi >>> >>> >>> -----Original Message----- >>> From: Yusuke DOI [mailto:yusuke.doi@toshiba.co.jp] >>> Sent: lundi 22 juillet 2013 13:04 >>> To: Mani, Mehdi >>> Cc: core@ietf.org >>> Subject: Re: [core] COAP and DHCP >>> >>> Dear Mehdi, >>> >>> I think if LLN nodes require some 'rich system-wide configuration' (an >>> example is MPL parameter), something like CoAP resource binding to DHCPv6 >>> option settings may work as replacement of stateless DHCPv6 (to get rid >>> of stateless DHCP code from CoAP-based LLN devices). However, I have no >>> idea on how to let clients know default CoAP server address to send >>> 'Information-request' messages to. >>> >>> Regards, >>> >>> Yusuke >>> >>> (2013-07-18 00:10), Mani, Mehdi wrote: >>>> I'm wondering if in Core WG there has ever been a discussion about >>>> obtaining IPv6 address using COAP instead of using DHCP. >>>> >>>> In LLN, if we consider that COAP is used as management protocol which >>>> configure end-points, why not using that for configuring a node for its >>>> IP address. This could be especially interesting to reduce the >>>> registration transactions for LLN end-points. >>>> >>>> Looking forward to hearing the interesting comments. >>>> >>>> Thanks >>>> >>>> -Mehdi >>>> >>>> >>>> >>>> _______________________________________________ >>>> core mailing list >>>> core@ietf.org >>>> https://www.ietf.org/mailman/listinfo/core >>>> >>> >>> >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >> >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core > > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://www.sensinode.com @SensinodeIoT > Mobile: +358 40 7796297 > Twitter: @zach_shelby > LinkedIn: http://fi.linkedin.com/in/zachshelby > 6LoWPAN Book: http://6lowpan.net > > > > From Mehdi.Mani@itron.com Mon Jul 22 09:11:34 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0617021E8093 for ; Mon, 22 Jul 2013 09:11:34 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s+GGyW1T9pUz for ; Mon, 22 Jul 2013 09:11:30 -0700 (PDT) Received: from mail.itron.com (mail.itron.com [198.182.8.115]) by ietfa.amsl.com (Postfix) with ESMTP id 13C3911E80FB for ; Mon, 22 Jul 2013 09:11:29 -0700 (PDT) Received: from ITR-EXMBXVS-1.itron.com ([192.168.9.112]) by spo-exchcn-1.itron.com ([192.168.9.115]) with mapi; Mon, 22 Jul 2013 09:11:29 -0700 From: "Mani, Mehdi" To: Zach Shelby , Don Sturek Date: Mon, 22 Jul 2013 09:11:27 -0700 Thread-Topic: [core] COAP and DHCP Thread-Index: Ac6G6gWCH8i8KnSNQWinDNK0YA46aQACT9SQ Message-ID: <10F62A0D440ACA41A85C7CB02936A1DB5B4417CFC0@ITR-EXMBXVS-1.itron.com> References: <6CA497E5-0C06-48AF-AD7B-93C387E1F5A1@sensinode.com> In-Reply-To: <6CA497E5-0C06-48AF-AD7B-93C387E1F5A1@sensinode.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "core@ietf.org" Subject: Re: [core] COAP and DHCP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 16:11:34 -0000 Zach, I also agree that we should not depend only on a generic web protocol like = COAP for the basic network configuration services; but we may have such opt= ion to use or not to use. I think the process of network discovery and addr= ess acquisition in IoT and LLN should be more efficient than what it is tod= ay defined for conventional IPv6 networks and end-points. Maybe Core and CO= AP is not the right place to address this issue.=20 The other thing about OMA Lightweight M2M that I didn't get is that you men= tioned it is great for things that are independent of IP; but isn't COAP de= fined to work on IP? Regards, -Mehdi -----Original Message----- From: Zach Shelby [mailto:zach@sensinode.com]=20 Sent: lundi 22 juillet 2013 16:43 To: Don Sturek Cc: Mani, Mehdi; Yusuke DOI; core@ietf.org Subject: Re: [core] COAP and DHCP Mehdi, I agree with Don here, it is not a great idea to mix basic IP network confi= guration services over a generic web protocol like CoAP. We can't really d= epend on having CoAP available to do something basic like address assignmen= t. That needs to work even when no application layer is present, e.g. in a = pure router. That said, we surely can manage a device, e.g. perform firmwar= e updates, update application configuration parameters etc. over CoAP. For = example the OMA Lightweight M2M standard does exactly this over CoAP using = Object definitions (like a MIB). That works great for things that are indep= endent of the IP network. The discovery built into CoAP is meant to be used for resource discovery, i= .e. discovering what web resources a CoAP server has available. It was not = designed to be used as a generic service discovery mechanism. If you don't = even know what protocol to use for your service, then you probably need som= ething like DNS-SD first. Regards, Zach On Jul 22, 2013, at 5:11 PM, Don Sturek wrote: > Hi Mehdi, >=20 > I did see your earlier post regarding address assignment via CoAP..... >=20 > I have to say, I think it is not wise to overload address assignment on > CoAP (which is really an application support protocol). CoAP does > support service discovery on ".well-known" (sorry if I got the syntax > wrong, this is from memory). If a richer service discovery is > wanted/needed, we should consider adding in a different standard=20 > rather than try to add those features directly into CoAP. >=20 > Don >=20 >=20 >=20 > On 7/22/13 6:19 AM, "Mani, Mehdi" wrote: >=20 >> Hi Yusuke, >>=20 >> It is in fact one of the advantages to get rid of DHCP codes on LLN=20 >> end-point. I don't know either if COAP is able to provide a kind of=20 >> autonomous service discovery for LLN devices but it could be one of=20 >> the interesting aspects that can be added to COAP feature; especially=20 >> that COAP is supposed to help the end-points with their resource and=20 >> service discovery. >>=20 >> Thanks >> -Mehdi >>=20 >>=20 >> -----Original Message----- >> From: Yusuke DOI [mailto:yusuke.doi@toshiba.co.jp] >> Sent: lundi 22 juillet 2013 13:04 >> To: Mani, Mehdi >> Cc: core@ietf.org >> Subject: Re: [core] COAP and DHCP >>=20 >> Dear Mehdi, >>=20 >> I think if LLN nodes require some 'rich system-wide configuration'=20 >> (an example is MPL parameter), something like CoAP resource binding=20 >> to DHCPv6 option settings may work as replacement of stateless DHCPv6=20 >> (to get rid of stateless DHCP code from CoAP-based LLN devices).=20 >> However, I have no idea on how to let clients know default CoAP=20 >> server address to send 'Information-request' messages to. >>=20 >> Regards, >>=20 >> Yusuke >>=20 >> (2013-07-18 00:10), Mani, Mehdi wrote: >>> I'm wondering if in Core WG there has ever been a discussion about=20 >>> obtaining IPv6 address using COAP instead of using DHCP. >>>=20 >>> In LLN, if we consider that COAP is used as management protocol=20 >>> which configure end-points, why not using that for configuring a=20 >>> node for its IP address. This could be especially interesting to=20 >>> reduce the registration transactions for LLN end-points. >>>=20 >>> Looking forward to hearing the interesting comments. >>>=20 >>> Thanks >>>=20 >>> -Mehdi >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>>=20 >>=20 >>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core -- Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com @SensinodeIoT Mobile: +358 40 7796297 Twitter: @zach_shelby LinkedIn: http://fi.linkedin.com/in/zachshelby 6LoWPAN Book: http://6lowpan.net From zach@sensinode.com Mon Jul 22 11:52:43 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25B5D21F99FB for ; Mon, 22 Jul 2013 11:52:43 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mbiEM-Dm1E8Y for ; Mon, 22 Jul 2013 11:52:39 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id C5A1C11E80A2 for ; Mon, 22 Jul 2013 11:52:38 -0700 (PDT) Received: from [192.168.1.103] (87-95-138-34.bb.dnainternet.fi [87.95.138.34]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id r6MIqUTM021365 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 22 Jul 2013 21:52:32 +0300 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Zach Shelby In-Reply-To: <10F62A0D440ACA41A85C7CB02936A1DB5B4417CFC0@ITR-EXMBXVS-1.itron.com> Date: Mon, 22 Jul 2013 21:52:30 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6CA497E5-0C06-48AF-AD7B-93C387E1F5A1@sensinode.com> <10F62A0D440ACA41A85C7CB02936A1DB5B4417CFC0@ITR-EXMBXVS-1.itron.com> To: "Mani, Mehdi" X-Mailer: Apple Mail (2.1503) Cc: "core@ietf.org WG" Subject: Re: [core] COAP and DHCP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 18:52:43 -0000 On Jul 22, 2013, at 7:11 PM, "Mani, Mehdi" wrote: > Zach, >=20 > I also agree that we should not depend only on a generic web protocol = like COAP for the basic network configuration services; but we may have = such option to use or not to use. I think the process of network = discovery and address acquisition in IoT and LLN should be more = efficient than what it is today defined for conventional IPv6 networks = and end-points. Maybe Core and COAP is not the right place to address = this issue.=20 Exactly. I think we all agree that network bootstrapping can be = improved, but CoRE is not the right place. This would be something to = bring up in upcoming 6LO WG for example? Do come to Berlin and support = that BOF. > The other thing about OMA Lightweight M2M that I didn't get is that = you mentioned it is great for things that are independent of IP; but = isn't COAP defined to work on IP? Sorry, I wasn't clear enough. You are right, OMA Lightweight uses IP and = CoAP for communication of course (although it does support CoAP over SMS = too=85).The point is that a device management solution over CoAP is = great for managing devices and application parameters, and even for = monitoring networks. However it isn't a solution for network = bootstrapping. Even the deployment scenario is wrong, typically the = Lightweight M2M Server is located in a backend server several IP = networks removed from the endpoint.=20 Regards, Zach > Regards, > -Mehdi >=20 > -----Original Message----- > From: Zach Shelby [mailto:zach@sensinode.com]=20 > Sent: lundi 22 juillet 2013 16:43 > To: Don Sturek > Cc: Mani, Mehdi; Yusuke DOI; core@ietf.org > Subject: Re: [core] COAP and DHCP >=20 > Mehdi, >=20 > I agree with Don here, it is not a great idea to mix basic IP network = configuration services over a generic web protocol like CoAP. We can't = really depend on having CoAP available to do something basic like = address assignment. That needs to work even when no application layer is = present, e.g. in a pure router. That said, we surely can manage a = device, e.g. perform firmware updates, update application configuration = parameters etc. over CoAP. For example the OMA Lightweight M2M standard = does exactly this over CoAP using Object definitions (like a MIB). That = works great for things that are independent of the IP network. >=20 > The discovery built into CoAP is meant to be used for resource = discovery, i.e. discovering what web resources a CoAP server has = available. It was not designed to be used as a generic service discovery = mechanism. If you don't even know what protocol to use for your service, = then you probably need something like DNS-SD first. >=20 > Regards, > Zach >=20 > On Jul 22, 2013, at 5:11 PM, Don Sturek wrote: >=20 >> Hi Mehdi, >>=20 >> I did see your earlier post regarding address assignment via = CoAP..... >>=20 >> I have to say, I think it is not wise to overload address assignment = on >> CoAP (which is really an application support protocol). CoAP does >> support service discovery on ".well-known" (sorry if I got the syntax >> wrong, this is from memory). If a richer service discovery is >> wanted/needed, we should consider adding in a different standard=20 >> rather than try to add those features directly into CoAP. >>=20 >> Don >>=20 >>=20 >>=20 >> On 7/22/13 6:19 AM, "Mani, Mehdi" wrote: >>=20 >>> Hi Yusuke, >>>=20 >>> It is in fact one of the advantages to get rid of DHCP codes on LLN=20= >>> end-point. I don't know either if COAP is able to provide a kind of=20= >>> autonomous service discovery for LLN devices but it could be one of=20= >>> the interesting aspects that can be added to COAP feature; = especially=20 >>> that COAP is supposed to help the end-points with their resource and=20= >>> service discovery. >>>=20 >>> Thanks >>> -Mehdi >>>=20 >>>=20 >>> -----Original Message----- >>> From: Yusuke DOI [mailto:yusuke.doi@toshiba.co.jp] >>> Sent: lundi 22 juillet 2013 13:04 >>> To: Mani, Mehdi >>> Cc: core@ietf.org >>> Subject: Re: [core] COAP and DHCP >>>=20 >>> Dear Mehdi, >>>=20 >>> I think if LLN nodes require some 'rich system-wide configuration'=20= >>> (an example is MPL parameter), something like CoAP resource binding=20= >>> to DHCPv6 option settings may work as replacement of stateless = DHCPv6=20 >>> (to get rid of stateless DHCP code from CoAP-based LLN devices).=20 >>> However, I have no idea on how to let clients know default CoAP=20 >>> server address to send 'Information-request' messages to. >>>=20 >>> Regards, >>>=20 >>> Yusuke >>>=20 >>> (2013-07-18 00:10), Mani, Mehdi wrote: >>>> I'm wondering if in Core WG there has ever been a discussion about=20= >>>> obtaining IPv6 address using COAP instead of using DHCP. >>>>=20 >>>> In LLN, if we consider that COAP is used as management protocol=20 >>>> which configure end-points, why not using that for configuring a=20 >>>> node for its IP address. This could be especially interesting to=20 >>>> reduce the registration transactions for LLN end-points. >>>>=20 >>>> Looking forward to hearing the interesting comments. >>>>=20 >>>> Thanks >>>>=20 >>>> -Mehdi >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> core mailing list >>>> core@ietf.org >>>> https://www.ietf.org/mailman/listinfo/core >>>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>=20 >>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >=20 > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://www.sensinode.com @SensinodeIoT > Mobile: +358 40 7796297 > Twitter: @zach_shelby > LinkedIn: http://fi.linkedin.com/in/zachshelby > 6LoWPAN Book: http://6lowpan.net >=20 >=20 >=20 >=20 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com @SensinodeIoT Mobile: +358 40 7796297 Twitter: @zach_shelby LinkedIn: http://fi.linkedin.com/in/zachshelby 6LoWPAN Book: http://6lowpan.net From rick.bullotta@thingworx.com Mon Jul 22 11:56:52 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0360F11E80DE for ; Mon, 22 Jul 2013 11:56:52 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1EsKTVc5R5VP for ; Mon, 22 Jul 2013 11:56:41 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0205.outbound.protection.outlook.com [207.46.163.205]) by ietfa.amsl.com (Postfix) with ESMTP id DDED111E80D5 for ; Mon, 22 Jul 2013 11:56:36 -0700 (PDT) Received: from BLUPR06MB001.namprd06.prod.outlook.com (10.242.190.139) by BLUPR06MB001.namprd06.prod.outlook.com (10.242.190.139) with Microsoft SMTP Server (TLS) id 15.0.731.16; Mon, 22 Jul 2013 18:56:35 +0000 Received: from BLUPR06MB001.namprd06.prod.outlook.com ([169.254.1.231]) by BLUPR06MB001.namprd06.prod.outlook.com ([169.254.1.81]) with mapi id 15.00.0731.000; Mon, 22 Jul 2013 18:56:35 +0000 From: Rick Bullotta To: Don Sturek , "Eggert, Lars" , "core@ietf.org" Thread-Topic: [core] Fwd: IETF Mentor Program Thread-Index: AQHOdpL426xbQQmM6keWdRwN12iKdJlw2/sAgABQyhA= Date: Mon, 22 Jul 2013 18:56:34 +0000 Message-ID: References: <285EAD53-1801-461E-813F-D0C250DDE03E@netapp.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [96.245.114.98] x-forefront-prvs: 0915875B28 x-forefront-antispam-report: SFV:NSPM; SFS:(24454002)(199002)(51704005)(189002)(2473001)(13464003)(53754006)(377454003)(479174003)(52254002)(46102001)(555904002)(63696002)(47446002)(74502001)(83322001)(74366001)(74316001)(54356001)(81542001)(65816001)(51856001)(56776001)(31966008)(19580385001)(74706001)(81342001)(16406001)(79102001)(76786001)(59766001)(56816003)(19580405001)(53806001)(77982001)(76796001)(4396001)(50986001)(47976001)(74662001)(33646001)(80022001)(49866001)(74876001)(47736001)(77096001)(19580395003)(83072001)(66066001)(69226001)(15202345003)(76482001)(76576001)(54316002)(24704002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR06MB001; H:BLUPR06MB001.namprd06.prod.outlook.com; CLIP:96.245.114.98; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: thingworx.com Subject: Re: [core] Fwd: IETF Mentor Program X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 18:56:52 -0000 I'm coming at it from the other side - I'm a noob to the IETF but a long hi= story in technology stuff & some standards work, mostly in the M2M and auto= mation space. I suppose I'd be a candidate for mentoring? Long past being= a student, but would like to get up to speed quickly on the IETF processes= and Core/COAP specifically. Any volunteers? Rick Bullotta CTO/Co-Founder ThingWorx -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Don= Sturek Sent: Monday, July 22, 2013 10:06 AM To: Eggert, Lars; core@ietf.org; roll@ietf.org Subject: Re: [core] Fwd: IETF Mentor Program Hi Lars, My name is Don Sturek and I would be interested in signing up as a mentor. I spent a good deal of time working in the IETF on a variety of drafts arou= nd IoT as part of ZigBee IP (plus added drafts to 6MAN which formed part of= the problem statement for Homenet and also participated in a barBOF in Sto= ckholm which provided some requirements for Core.....) Don On 7/22/13 6:51 AM, "Eggert, Lars" wrote: >Hi, > >I'm one of the folks matching up mentors and newcomers. We have a few=20 >newcomers that are interested in IoT, but VERY few IoT folks=20 >volunteering to be mentors. Please step up! And soon! > >Lars > >Begin forwarded message: > >> From: IETF Chair >> Subject: IETF Mentor Program >> Date: July 1, 2013 21:39:36 GMT+02:00 >> To: IETF Announcement List >> Reply-To: >>=20 >> Hi all, >>=20 >> Based on discussions during IETF 86, we are trialing an IETF=20 >>mentoring program. During this trial period, we would like to pair=20 >>newcomers (people who have attended 3 or fewer meetings or have=20 >>registered as students) with existing IETF participants. The goal is=20 >>to provide a resource for the newcomer who can assist them with=20 >>integrating into the IETF community. Mentors and newcomers will be=20 >>paired prior to IETF 87. >>=20 >> What we need is for people to volunteer to be mentors. As a mentor,=20 >>we would ask that you be willing to assist your mentoring participant=20 >>before, during, and (hopefully) after IETF 87. The actual level of=20 >>interaction will be driven by an agreement between the mentor and the=20 >>mentoring participant. Additionally, we would need a brief description=20 >>of your areas of expertise, technical interests, and conversational=20 >>languages. >>=20 >> A description of the Mentor Program (including a FAQ describing how=20 >> to volunteer to be a mentor) is available: >>=20 >> http://www.ietf.org/resources/mentoring-program.html. >>=20 >> Anyone interested in being a mentor should follow the sign-up=20 >> instructions contained in the above URL. The more volunteers we=20 >> have, the stronger the program will be! >>=20 >> Regards, >> IETF Chair > >_______________________________________________ >core mailing list >core@ietf.org >https://www.ietf.org/mailman/listinfo/core _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From d.sturek@att.net Mon Jul 22 12:03:11 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 221D811E80C5 for ; Mon, 22 Jul 2013 12:03:11 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LG6+FB2TOOR1 for ; Mon, 22 Jul 2013 12:03:06 -0700 (PDT) Received: from nm6-vm5.access.bullet.mail.gq1.yahoo.com (nm6-vm5.access.bullet.mail.gq1.yahoo.com [216.39.63.124]) by ietfa.amsl.com (Postfix) with ESMTP id 92B0121F96A8 for ; Mon, 22 Jul 2013 12:03:05 -0700 (PDT) Received: from [216.39.60.176] by nm6.access.bullet.mail.gq1.yahoo.com with NNFMP; 22 Jul 2013 19:03:03 -0000 Received: from [67.195.23.144] by tm12.access.bullet.mail.gq1.yahoo.com with NNFMP; 22 Jul 2013 19:03:03 -0000 Received: from [127.0.0.1] by smtp116.sbc.mail.gq1.yahoo.com with NNFMP; 22 Jul 2013 19:03:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1374519783; bh=ecjm0cqVbUNY6aVpDlOpS0o8eQSpcPx9LDyjkci5mwU=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=htXnzdPSwilKLo7Rm9UZcyJXu7FjVfRddfX2mdAXo8TBUo0XFvYEBJj0tj1GBViXd7rbGe/qbAmclOcJ85W9qmrUoCvuT+ekP7cOLXESnFMMpg9a3oh09wawzJkbWuZpkRynAHJw2U61MN4SOki7vicMEDLPLwbuoZwAjD0mFGA= X-Yahoo-Newman-Id: 540268.37869.bm@smtp116.sbc.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: sSRXtPoVM1nD42o0DWvbl.K8lYdE8pbPLfYq_CWzgI0MyXN NFrrVQEquxzoV4QNO0oDCbFxAiTyT7_yE_sNvrP9pghZP9WJXHHLxnEsjOeW Oe.p2OMY4SA9xfr.nuzal92wKMymHQDaWuIKhXtbo43ED2M0AWlXUpAi5WLq yvNTpvaVqMaY6Piwn0lSyTGFaJZXUOcGesQJfcQ_WKBR7hA0jInYrEwzo8HD JVc3wvSG9sJaj7zjQriqqO89bEfd1IUdlhsLfnACuk2lM7PGJHmFon0cnyRh p59X_knbWAuLrWXfx6wduZN6vMQZNPHJF4Z0C98iY3b.dGg29z1IRFu3mY3_ ekF.s4ykyxueEqU292Y09A5nnbst8Bo0RL4jrn_5cKZ7ICK3tS64DOfF.QeB 1R618FVoJNiD3zYzcrO.InqrbgwUXe6XZ5HHZYGKPmiTO70hhRjdYO4yvhjI iW9sDrZDIQiVUZVFz8Q6Kzo0.SR4ekj0JfxjR4ev6IbsqarWefmTrLnMVK.G hfGsR13ceSNQeFrR7QrrjOaiLGQUsVjPvWd8hs1HL64dWLt5rxCdfv45R1Ke 4vQSvdEK4JwHp6MCaSmZYdV_qTPrrw4fx4XV4CSotP9M74k5cs_O_rX6_qc4 ._tE8xE_IsQXXU7iDY61iEJVfY1zQYP5GcgAZLIHePw5YqzGL8vBWsb3J9mg o07uGCMBQBoKh5r0- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-Rocket-Received: from [10.1.1.129] (d.sturek@66.27.60.174 with login) by smtp116.sbc.mail.gq1.yahoo.com with SMTP; 22 Jul 2013 19:03:03 +0000 UTC User-Agent: Microsoft-MacOutlook/14.3.6.130613 Date: Mon, 22 Jul 2013 12:03:00 -0700 From: Don Sturek To: Zach Shelby , "Mani, Mehdi" Message-ID: Thread-Topic: [core] COAP and DHCP In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: "core@ietf.org WG" Subject: Re: [core] COAP and DHCP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 19:03:11 -0000 Hi Mehdi (and Zach), In addition to the 6LO BOF that Zach mentioned, there is this draft in 6MAN: http://datatracker.ietf.org/doc/draft-chakrabarti-nordmark-6man-efficient-n d/ Participating in evolving the above draft on efficient ND within 6MAN might also be an avenue towards simplifying network bootstrapping (including address assignment) Don On 7/22/13 11:52 AM, "Zach Shelby" wrote: >On Jul 22, 2013, at 7:11 PM, "Mani, Mehdi" wrote: > >> Zach, >>=20 >> I also agree that we should not depend only on a generic web protocol >>like COAP for the basic network configuration services; but we may have >>such option to use or not to use. I think the process of network >>discovery and address acquisition in IoT and LLN should be more >>efficient than what it is today defined for conventional IPv6 networks >>and end-points. Maybe Core and COAP is not the right place to address >>this issue.=20 > >Exactly. I think we all agree that network bootstrapping can be improved, >but CoRE is not the right place. This would be something to bring up in >upcoming 6LO WG for example? Do come to Berlin and support that BOF. > >> The other thing about OMA Lightweight M2M that I didn't get is that you >>mentioned it is great for things that are independent of IP; but isn't >>COAP defined to work on IP? > >Sorry, I wasn't clear enough. You are right, OMA Lightweight uses IP and >CoAP for communication of course (although it does support CoAP over SMS >too=8A).The point is that a device management solution over CoAP is great >for managing devices and application parameters, and even for monitoring >networks. However it isn't a solution for network bootstrapping. Even the >deployment scenario is wrong, typically the Lightweight M2M Server is >located in a backend server several IP networks removed from the >endpoint.=20 > >Regards, >Zach > >> Regards, >> -Mehdi >>=20 >> -----Original Message----- >> From: Zach Shelby [mailto:zach@sensinode.com] >> Sent: lundi 22 juillet 2013 16:43 >> To: Don Sturek >> Cc: Mani, Mehdi; Yusuke DOI; core@ietf.org >> Subject: Re: [core] COAP and DHCP >>=20 >> Mehdi, >>=20 >> I agree with Don here, it is not a great idea to mix basic IP network >>configuration services over a generic web protocol like CoAP. We can't >>really depend on having CoAP available to do something basic like >>address assignment. That needs to work even when no application layer is >>present, e.g. in a pure router. That said, we surely can manage a >>device, e.g. perform firmware updates, update application configuration >>parameters etc. over CoAP. For example the OMA Lightweight M2M standard >>does exactly this over CoAP using Object definitions (like a MIB). That >>works great for things that are independent of the IP network. >>=20 >> The discovery built into CoAP is meant to be used for resource >>discovery, i.e. discovering what web resources a CoAP server has >>available. It was not designed to be used as a generic service discovery >>mechanism. If you don't even know what protocol to use for your service, >>then you probably need something like DNS-SD first. >>=20 >> Regards, >> Zach >>=20 >> On Jul 22, 2013, at 5:11 PM, Don Sturek wrote: >>=20 >>> Hi Mehdi, >>>=20 >>> I did see your earlier post regarding address assignment via CoAP..... >>>=20 >>> I have to say, I think it is not wise to overload address assignment on >>> CoAP (which is really an application support protocol). CoAP does >>> support service discovery on ".well-known" (sorry if I got the syntax >>> wrong, this is from memory). If a richer service discovery is >>> wanted/needed, we should consider adding in a different standard >>> rather than try to add those features directly into CoAP. >>>=20 >>> Don >>>=20 >>>=20 >>>=20 >>> On 7/22/13 6:19 AM, "Mani, Mehdi" wrote: >>>=20 >>>> Hi Yusuke, >>>>=20 >>>> It is in fact one of the advantages to get rid of DHCP codes on LLN >>>> end-point. I don't know either if COAP is able to provide a kind of >>>> autonomous service discovery for LLN devices but it could be one of >>>> the interesting aspects that can be added to COAP feature; especially >>>> that COAP is supposed to help the end-points with their resource and >>>> service discovery. >>>>=20 >>>> Thanks >>>> -Mehdi >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: Yusuke DOI [mailto:yusuke.doi@toshiba.co.jp] >>>> Sent: lundi 22 juillet 2013 13:04 >>>> To: Mani, Mehdi >>>> Cc: core@ietf.org >>>> Subject: Re: [core] COAP and DHCP >>>>=20 >>>> Dear Mehdi, >>>>=20 >>>> I think if LLN nodes require some 'rich system-wide configuration' >>>> (an example is MPL parameter), something like CoAP resource binding >>>> to DHCPv6 option settings may work as replacement of stateless DHCPv6 >>>> (to get rid of stateless DHCP code from CoAP-based LLN devices). >>>> However, I have no idea on how to let clients know default CoAP >>>> server address to send 'Information-request' messages to. >>>>=20 >>>> Regards, >>>>=20 >>>> Yusuke >>>>=20 >>>> (2013-07-18 00:10), Mani, Mehdi wrote: >>>>> I'm wondering if in Core WG there has ever been a discussion about >>>>> obtaining IPv6 address using COAP instead of using DHCP. >>>>>=20 >>>>> In LLN, if we consider that COAP is used as management protocol >>>>> which configure end-points, why not using that for configuring a >>>>> node for its IP address. This could be especially interesting to >>>>> reduce the registration transactions for LLN end-points. >>>>>=20 >>>>> Looking forward to hearing the interesting comments. >>>>>=20 >>>>> Thanks >>>>>=20 >>>>> -Mehdi >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> core mailing list >>>>> core@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/core >>>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> core mailing list >>>> core@ietf.org >>>> https://www.ietf.org/mailman/listinfo/core >>>=20 >>>=20 >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>=20 >> -- >> Zach Shelby, Chief Nerd, Sensinode Ltd. >> http://www.sensinode.com @SensinodeIoT >> Mobile: +358 40 7796297 >> Twitter: @zach_shelby >> LinkedIn: http://fi.linkedin.com/in/zachshelby >> 6LoWPAN Book: http://6lowpan.net >>=20 >>=20 >>=20 >>=20 > >--=20 >Zach Shelby, Chief Nerd, Sensinode Ltd. >http://www.sensinode.com @SensinodeIoT >Mobile: +358 40 7796297 >Twitter: @zach_shelby >LinkedIn: http://fi.linkedin.com/in/zachshelby >6LoWPAN Book: http://6lowpan.net > > > > >_______________________________________________ >core mailing list >core@ietf.org >https://www.ietf.org/mailman/listinfo/core From stokcons@xs4all.nl Tue Jul 23 00:07:20 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC09C11E80D1 for ; Tue, 23 Jul 2013 00:07:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TN60Wj37OOy0 for ; Tue, 23 Jul 2013 00:07:16 -0700 (PDT) Received: from smtp-vbr7.xs4all.nl (smtp-vbr7.xs4all.nl [194.109.24.27]) by ietfa.amsl.com (Postfix) with ESMTP id 3F14411E8137 for ; Tue, 23 Jul 2013 00:07:13 -0700 (PDT) Received: from roundcube.xs4all.nl (roundcube6.xs4all.net [194.109.20.204]) by smtp-vbr7.xs4all.nl (8.13.8/8.13.8) with ESMTP id r6N773MO032447 for ; Tue, 23 Jul 2013 09:07:09 +0200 (CEST) (envelope-from stokcons@xs4all.nl) Received: from a82-95-140-48.adsl.xs4all.nl ([82.95.140.48]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 23 Jul 2013 09:07:03 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 23 Jul 2013 09:07:03 +0200 From: peter van der Stok To: core@ietf.org Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <201307221606.r6MG69jw017794@toshiba.co.jp> References: <6CA497E5-0C06-48AF-AD7B-93C387E1F5A1@sensinode.com> <201307221606.r6MG69jw017794@toshiba.co.jp> Message-ID: X-Sender: stokcons@xs4all.nl (Jofk5fsGhf+ZiHOK6A91SciQeSbLEw51) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Subject: Re: [core] COAP and DHCP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 07:07:21 -0000 Hi all, I do agree that for interoperability, we should stick to those generally accepted standards which are around, proven, and involve the basic IP network infrastructure. In my opinion ND, DNS, DHCP, ..... are part of this infrastructure. However, things are different when we talk management of devices. Here it concerns interoperability between some, possibly private, tool and and the nodes belonging to a given management organisation, like the campus IT department. Currently, we do have SNMP and MIBs, where the standardized naming in the MIB provides interoperability between nodes from different manufacturers and SNMP provides standardized protocol between client and servers. For coap devices, the disadvantage of SNMP, IMO, is that it doubles the security handling protocol of CoAP. Providing a CoAP interface for management, including a coap interface to MIBs, will probably reduce the code size on the restricted nodes and profits from much available work on MIBs. New MIBs for MPL, RPL intialization can be standardized and look sufficient for these purposes. A CoAP interface instead of the SNMP interface will help making these management data more accessible within the context of the security architecture of CoAP. My draft draft-vanderstok-core-comi-00 discusses two CoAP approaches for access to MIBs and future management data, of which one approach should be selected. Concerning service discovery and resource discovery, I am much interested in the work that will relate the RD to DNS-SD and the proposals coming from the DNSSDext proposed BoF. It is clear that for service discovery we need a naming scheme that is interoperable between devices from different manufacturers, and the DNS-SD repository of service names looks like a good starting point. Do we want a discussion during coap on these standardization aspects concerning the operation, setting-up, initialization, maintenance, and commissioning of these LLN devices? Possibly we could come to some agreement which aspects are typically within the responsibility of IETF. Peter DOI Yusuke schreef op 2013-07-22 18:06: > Dear Zach, Don, > > I also agree it would be not a good idea to do address configuration > over CoAP. But I think, especially for SLAAC-based LLNs, we don't have > a handy channel to distribute non-essential configurations, such as > DNS server address or MPL parameters to be used in the network. DNS-SD > could not be a good choice for, to say, 1000 nodes of LLN with 5 hops > or more. > > The choice in my mind is to deploy DHCP-relay over nodes and to use > stateless DHCP to distribute such configuration parameters. It should > work well and I'm okay with it (so far, not tried to implement it > yet). At the same time I wonder if there is other choices such as > Stateless-DHCP-Option-to-CoAP-Resource mapping. > > Regards, > > Yusuke > > > > From: Zach Shelby > Subject: Re: [core] COAP and DHCP > Date: Mon, 22 Jul 2013 17:42:38 +0300 > > Mehdi, > > I agree with Don here, it is not a great idea to mix basic IP network > configuration services over a generic web protocol like CoAP. We can't > really depend on having CoAP available to do something basic like > address assignment. That needs to work even when no application layer > is present, e.g. in a pure router. That said, we surely can manage a > device, e.g. perform firmware updates, update application configuration > parameters etc. over CoAP. For example the OMA Lightweight M2M standard > does exactly this over CoAP using Object definitions (like a MIB). That > works great for things that are independent of the IP network. > > The discovery built into CoAP is meant to be used for resource > discovery, i.e. discovering what web resources a CoAP server has > available. It was not designed to be used as a generic service > discovery mechanism. If you don't even know what protocol to use for > your service, then you probably need something like DNS-SD first. > > Regards, > Zach > > On Jul 22, 2013, at 5:11 PM, Don Sturek wrote: > > Hi Mehdi, > > I did see your earlier post regarding address assignment via CoAP..... > > I have to say, I think it is not wise to overload address assignment on > CoAP (which is really an application support protocol). CoAP does > support service discovery on ".well-known" (sorry if I got the syntax > wrong, this is from memory). If a richer service discovery is > wanted/needed, we should consider adding in a different standard rather > than try to add those features directly into CoAP. > > Don > > > > On 7/22/13 6:19 AM, "Mani, Mehdi" wrote: > > Hi Yusuke, > > It is in fact one of the advantages to get rid of DHCP codes on LLN > end-point. I don't know either if COAP is able to provide a kind of > autonomous service discovery for LLN devices but it could be one of the > interesting aspects that can be added to COAP feature; especially that > COAP is supposed to help the end-points with their resource and service > discovery. > > Thanks > -Mehdi > > > -----Original Message----- > From: Yusuke DOI [mailto:yusuke.doi@toshiba.co.jp] > Sent: lundi 22 juillet 2013 13:04 > To: Mani, Mehdi > Cc: core@ietf.org > Subject: Re: [core] COAP and DHCP > > Dear Mehdi, > > I think if LLN nodes require some 'rich system-wide configuration' (an > example is MPL parameter), something like CoAP resource binding to > DHCPv6 > option settings may work as replacement of stateless DHCPv6 (to get rid > of stateless DHCP code from CoAP-based LLN devices). However, I have no > idea on how to let clients know default CoAP server address to send > 'Information-request' messages to. > > Regards, > > Yusuke > > (2013-07-18 00:10), Mani, Mehdi wrote: > I'm wondering if in Core WG there has ever been a discussion about > obtaining IPv6 address using COAP instead of using DHCP. > > In LLN, if we consider that COAP is used as management protocol which > configure end-points, why not using that for configuring a node for its > IP address. This could be especially interesting to reduce the > registration transactions for LLN end-points. > > Looking forward to hearing the interesting comments. > > Thanks > > -Mehdi > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://www.sensinode.com @SensinodeIoT > Mobile: +358 40 7796297 > Twitter: @zach_shelby > LinkedIn: http://fi.linkedin.com/in/zachshelby > 6LoWPAN Book: http://6lowpan.net > > > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From j.schoenwaelder@jacobs-university.de Tue Jul 23 00:15:53 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97B9A11E80D1 for ; Tue, 23 Jul 2013 00:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ARXp+OFthGi for ; Tue, 23 Jul 2013 00:15:48 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 667DA11E8118 for ; Tue, 23 Jul 2013 00:15:46 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6007520BD5; Tue, 23 Jul 2013 09:15:45 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ouCGwMTaq0WC; Tue, 23 Jul 2013 09:15:45 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9479E20BCD; Tue, 23 Jul 2013 09:15:44 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6E582274CF59; Tue, 23 Jul 2013 09:15:41 +0200 (CEST) Date: Tue, 23 Jul 2013 09:15:41 +0200 From: Juergen Schoenwaelder To: consultancy@vanderstok.org Message-ID: <20130723071541.GB3003@elstar.local> Mail-Followup-To: consultancy@vanderstok.org, core@ietf.org References: <6CA497E5-0C06-48AF-AD7B-93C387E1F5A1@sensinode.com> <201307221606.r6MG69jw017794@toshiba.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: core@ietf.org Subject: Re: [core] COAP and DHCP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 07:15:53 -0000 On Tue, Jul 23, 2013 at 09:07:03AM +0200, peter van der Stok wrote: > > For coap devices, the disadvantage of SNMP, IMO, is that it doubles > the security handling protocol of CoAP. RFC 5953 details how to run SNMPv3 over DTLS. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From jari.arkko@piuha.net Tue Jul 23 04:00:41 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B69CF11E820E for ; Tue, 23 Jul 2013 04:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S38dMJRBCxtl for ; Tue, 23 Jul 2013 04:00:36 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 58B7621E8090 for ; Tue, 23 Jul 2013 04:00:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 4BFF42CC48; Tue, 23 Jul 2013 14:00:35 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdD9Td0ghaPS; Tue, 23 Jul 2013 14:00:34 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 946232CC3C; Tue, 23 Jul 2013 14:00:34 +0300 (EEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jari Arkko In-Reply-To: Date: Tue, 23 Jul 2013 14:00:34 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Don Sturek X-Mailer: Apple Mail (2.1508) Cc: core@ietf.org Subject: Re: [core] blog article on Web of Things X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 11:00:41 -0000 Don, > Any thoughts on how these commercial standards groups can report on > missing (needed) features or additions within the IETF? One of the > biggest challenges is knowing what group in IETF should be the target = of > such requests (or even if a BOF is needed if there is not group). I = can > see some additional features being needed for a full Core deployment = (part > of which can be addressed in the DICE group but I am also thinking of = work > on forwarding to multicast groups where message distribution does not = use > flooding.....) Good question. I think the standard answer is that first of all, this is not going to = happen without some joint participation. So I think it is up to you and = others who attend multiple forums to tell us what is missing and make a = case for it in the IETF. And talk to your WG chairs and ADs about what = is needed. As we were completing CoAP we've been quite careful about adding new = things, both in CORE and elsewhere. Perhaps it is time to do an effort = to analyse what if anything is needed in this space, and then add those = items to the relevant working groups? It would also be useful to talk to = the W3C group, as they are making analysis of what is missing as well. = I'd love to see someone write a draft on what the Web of Things still = needs! Any takers? Jari From rick.bullotta@thingworx.com Tue Jul 23 04:22:45 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FB5211E820B for ; Tue, 23 Jul 2013 04:22:45 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7IW9TGSazNy9 for ; Tue, 23 Jul 2013 04:22:40 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0210.outbound.protection.outlook.com [207.46.163.210]) by ietfa.amsl.com (Postfix) with ESMTP id A814511E821C for ; Tue, 23 Jul 2013 04:22:06 -0700 (PDT) Received: from BLUPR06MB001.namprd06.prod.outlook.com (10.242.190.139) by BLUPR06MB003.namprd06.prod.outlook.com (10.242.190.149) with Microsoft SMTP Server (TLS) id 15.0.731.16; Tue, 23 Jul 2013 11:06:46 +0000 Received: from BLUPR06MB001.namprd06.prod.outlook.com ([169.254.1.231]) by BLUPR06MB001.namprd06.prod.outlook.com ([169.254.1.81]) with mapi id 15.00.0731.000; Tue, 23 Jul 2013 11:06:45 +0000 From: Rick Bullotta To: Jari Arkko Thread-Topic: [core] blog article on Web of Things Thread-Index: AQHOgXBqf9BOedZnokOD+Iv9ybxjwpll8WUAgAwzbwCAAAG6Qg== Date: Tue, 23 Jul 2013 11:06:44 +0000 Message-ID: <831CBD43-9586-457A-98BF-D01100CDE7B1@thingworx.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.59.9.6] x-forefront-prvs: 0916FC3A18 x-forefront-antispam-report: SFV:NSPM; SFS:(377454003)(189002)(199002)(51704005)(24454002)(23363001)(74876001)(81542001)(47446002)(56776001)(69226001)(46102001)(33656001)(81342001)(76482001)(77096001)(56816003)(53806001)(54356001)(54316002)(76796001)(76786001)(47976001)(50986001)(65816001)(83072001)(47736001)(49866001)(19580395003)(80022001)(74662001)(19580385001)(19580405001)(83322001)(74502001)(66066001)(31966008)(16406001)(74706001)(74366001)(4396001)(36756003)(63696002)(77982001)(59766001)(79102001)(51856001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR06MB003; H:BLUPR06MB001.namprd06.prod.outlook.com; CLIP:173.59.9.6; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: thingworx.com Cc: "core@ietf.org" Subject: Re: [core] blog article on Web of Things X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 11:22:45 -0000 I think the first step is a presentation/document that describes Core/COAP = at a high level but provides a comprehensive overview of the capabilities, = but isn't quite as technical as the specs themselves. =20 I would be very happy to provide some functional feedback/gap analysis from= a commercial platform perspective.=20 Cheers, Rick Bullotta ThingWorx On Jul 23, 2013, at 7:00 AM, "Jari Arkko" wrote: > Don, >=20 >> Any thoughts on how these commercial standards groups can report on >> missing (needed) features or additions within the IETF? One of the >> biggest challenges is knowing what group in IETF should be the target of >> such requests (or even if a BOF is needed if there is not group). I can >> see some additional features being needed for a full Core deployment (pa= rt >> of which can be addressed in the DICE group but I am also thinking of wo= rk >> on forwarding to multicast groups where message distribution does not us= e >> flooding.....) >=20 > Good question. >=20 > I think the standard answer is that first of all, this is not going to ha= ppen without some joint participation. So I think it is up to you and other= s who attend multiple forums to tell us what is missing and make a case for= it in the IETF. And talk to your WG chairs and ADs about what is needed. >=20 > As we were completing CoAP we've been quite careful about adding new thin= gs, both in CORE and elsewhere. Perhaps it is time to do an effort to analy= se what if anything is needed in this space, and then add those items to th= e relevant working groups? It would also be useful to talk to the W3C group= , as they are making analysis of what is missing as well. I'd love to see s= omeone write a draft on what the Web of Things still needs! Any takers? >=20 > Jari >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From cabo@tzi.org Tue Jul 23 04:30:40 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E77311E819E for ; Tue, 23 Jul 2013 04:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WiqInF8cA5NR for ; Tue, 23 Jul 2013 04:30:36 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id E031111E8180 for ; Tue, 23 Jul 2013 04:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r6NBUR7M025890; Tue, 23 Jul 2013 13:30:27 +0200 (CEST) Received: from [10.0.1.4] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 6C3F59B6; Tue, 23 Jul 2013 13:30:27 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: <831CBD43-9586-457A-98BF-D01100CDE7B1@thingworx.com> Date: Tue, 23 Jul 2013 13:30:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <79903459-432B-4355-807A-4096D7AADBEC@tzi.org> References: , <831CBD43-9586-457A-98BF-D01100CDE7B1@thingworx.com> To: Rick Bullotta X-Mailer: Apple Mail (2.1508) Cc: "core@ietf.org" Subject: Re: [core] blog article on Web of Things X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 11:30:40 -0000 On Jul 23, 2013, at 13:06, Rick Bullotta = wrote: > a presentation/document that describes Core/COAP at a high level but = provides a comprehensive overview of the capabilities, but isn't quite = as technical as the specs themselves. =20 Yes, we (as a community, not necessarily as a WG) have to work on more = accessible documents. One such document is = http://doi.ieeecomputersociety.org/10.1109/MIC.2012.29 =97 = unfortunately, it is behind the IEEE paywall, but many technical = organizations do have access. Another document that provides some overview (but unfortunately less = technical content) is = http://tools.ietf.org/html/draft-bormann-core-roadmap-04 =97 this is due = for an update as soon as the Internet-Draft moratorium ends. Gr=FC=DFe, Carsten From cabo@tzi.org Tue Jul 23 04:39:45 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 028F711E8180 for ; Tue, 23 Jul 2013 04:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVBaF2RVJZ-y for ; Tue, 23 Jul 2013 04:39:40 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 4C49911E8204 for ; Tue, 23 Jul 2013 04:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r6NBdVUZ010845; Tue, 23 Jul 2013 13:39:31 +0200 (CEST) Received: from [10.0.1.4] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 988BE9CF; Tue, 23 Jul 2013 13:39:31 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Tue, 23 Jul 2013 13:39:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Don Sturek X-Mailer: Apple Mail (2.1508) Cc: "core@ietf.org WG" Subject: [core] Next steps (Re: blog article on Web of Things) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 11:39:45 -0000 On Jul 23, 2013, at 13:00, Jari Arkko wrote: > [...] tell us what is missing and make a case for it in the IETF. I (donning WG chair hat) see little problem in using the CoRE WG mailing = list for some requirements discussion, even if it is not clear whether = the resulting work will fall into the purview of CoRE or other IETF WGs = in the Internet-of-Things cluster. > And talk to your WG chairs and ADs about what is needed. Absolutely! On a short-term timescale, I also would like to hear what additional = requirements need to go into the 6LO and DICE BOFs next week. The current version of the proposed 6LO charter is at: = https://github.com/6lo/charter DICE has its current charter proposal at: http://goo.gl/pSiLc Gr=FC=DFe, Carsten From robert.cragie@gridmerge.com Tue Jul 23 05:52:24 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 935CE11E8133 for ; Tue, 23 Jul 2013 05:52:24 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KRKwIhtGklwc for ; Tue, 23 Jul 2013 05:52:20 -0700 (PDT) Received: from mail41.extendcp.co.uk (mail41.extendcp.co.uk [79.170.44.41]) by ietfa.amsl.com (Postfix) with ESMTP id C560411E80F7 for ; Tue, 23 Jul 2013 05:52:12 -0700 (PDT) Received: from [94.116.234.145] (helo=[10.38.244.130]) by mail41.extendcp.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) id 1V1c4R-0005kU-1Y for core@ietf.org; Tue, 23 Jul 2013 13:52:03 +0100 Message-ID: <51EE7C72.5050009@gridmerge.com> Date: Tue, 23 Jul 2013 13:52:02 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: core@ietf.org References: <6CA497E5-0C06-48AF-AD7B-93C387E1F5A1@sensinode.com> <201307221606.r6MG69jw017794@toshiba.co.jp> In-Reply-To: <201307221606.r6MG69jw017794@toshiba.co.jp> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030703040605050602000807" X-Authenticated-As: robert.cragie@gridmerge.com Subject: Re: [core] COAP and DHCP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 12:52:24 -0000 This is a cryptographically signed message in MIME format. --------------ms030703040605050602000807 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable One of the issues is that each protocol which exists for its own reason=20 has its own set of configuration information which nodes need to perform = a function using that protocol. In some respects, other protocols could=20 be used to distribute configuration information as they may provide a=20 more appropriate vehicle. There were two occasions which I recall when we were working on ZigBee=20 IP where it did seem to make sense to consider using other protocols to=20 distribute certain configuration information: 1) Use of PANA to distribute 802.15.4 MAC short address configuration=20 information 2) Use of RPL DIO to distribute information typically disseminated using = RA In the case of (1), it seems logical as at the point of authentication,=20 a secure delivery mechanism can also be deployed. Therefore, a "blob" of = configuration information can be easily and securely delivered to a node = which is being bootstrapped. We even worked through a case whereby the=20 802.15.4 MAC short address was delivered using this mechanism and then=20 SLAAC used to form the IPv6 address. DAD was not needed due to=20 centralised allocation and indeed 6lowpan DAR/DAC was not needed.=20 However, this was not adopted primarily for the reason that it was=20 considered to be overloading the purpose of PANA and PANA relay to=20 provide authentication and to deliver a network key. Whilst that can't=20 be disputed, it did demonstrate that the authentication mechanism is a=20 logical place for a trusted server to deliver bootstrapping=20 configuration information to an authenticated client in a controlled=20 manner. Note something like 802.1X/RADIUS could also be used instead -=20 it is more the general model of point-to-point of untrusted node to=20 enforcement point, then through network to authentication server model.=20 As DHCP has the relay model as well, it would also seem appropriate to=20 use DHCP. It may even make sense to consider extending DHCP to carry=20 authentication traffic, although that may be considered heresy :-). In the case of (2), the way DIOs are disseminated using the DODAG=20 provide a logical way to disseminate information from a root to all=20 RPL-aware nodes. Therefore it seemed logical to use RPL to disseminate=20 this information throughout the routers in the mesh. Then traditional RA = could be used between router and host. Note that neither mechanism was adopted in ZigBee IP because it was=20 considered to be overloading the primary purpose of the protocol=20 messages. However, it may be worth considering these ideas again=20 especially in constrained environments where to some extent any=20 reduction in the amount of code and complexity would help. However, in=20 both cases, IMHO it is more important to consider the way it is=20 delivering or disseminating information than the actual protocol itself=20 and to tie that to the configuration data. With regard to CoAP, I tend to agree with other comments here that it is = more appropriate for distributing application-layer configuration - and=20 that doesn't mean address assignment. Robert On 22/07/2013 17:06, DOI Yusuke wrote: > Dear Zach, Don, > > I also agree it would be not a good idea to do address configuration ov= er CoAP. But I think, especially for SLAAC-based LLNs, we don't have a ha= ndy channel to distribute non-essential configurations, such as DNS serve= r address or MPL parameters to be used in the network. DNS-SD could not b= e a good choice for, to say, 1000 nodes of LLN with 5 hops or more. > > The choice in my mind is to deploy DHCP-relay over nodes and to use sta= teless DHCP to distribute such configuration parameters. It should work w= ell and I'm okay with it (so far, not tried to implement it yet). At the = same time I wonder if there is other choices such as Stateless-DHCP-Optio= n-to-CoAP-Resource mapping. > > Regards, > > Yusuke > > > > From: Zach Shelby > Subject: Re: [core] COAP and DHCP > Date: Mon, 22 Jul 2013 17:42:38 +0300 > >> Mehdi, >> >> I agree with Don here, it is not a great idea to mix basic IP network = configuration services over a generic web protocol like CoAP. We can't r= eally depend on having CoAP available to do something basic like address = assignment. That needs to work even when no application layer is present,= e.g. in a pure router. That said, we surely can manage a device, e.g. pe= rform firmware updates, update application configuration parameters etc. = over CoAP. For example the OMA Lightweight M2M standard does exactly this= over CoAP using Object definitions (like a MIB). That works great for th= ings that are independent of the IP network. >> >> The discovery built into CoAP is meant to be used for resource discove= ry, i.e. discovering what web resources a CoAP server has available. It w= as not designed to be used as a generic service discovery mechanism. If y= ou don't even know what protocol to use for your service, then you probab= ly need something like DNS-SD first. >> >> Regards, >> Zach >> >> On Jul 22, 2013, at 5:11 PM, Don Sturek wrote: >> >>> Hi Mehdi, >>> >>> I did see your earlier post regarding address assignment via CoAP....= =2E >>> >>> I have to say, I think it is not wise to overload address assignment = on >>> CoAP (which is really an application support protocol). CoAP does >>> support service discovery on ".well-known" (sorry if I got the syntax= >>> wrong, this is from memory). If a richer service discovery is >>> wanted/needed, we should consider adding in a different standard rath= er >>> than try to add those features directly into CoAP. >>> >>> Don >>> >>> >>> >>> On 7/22/13 6:19 AM, "Mani, Mehdi" wrote: >>> >>>> Hi Yusuke, >>>> >>>> It is in fact one of the advantages to get rid of DHCP codes on LLN >>>> end-point. I don't know either if COAP is able to provide a kind of >>>> autonomous service discovery for LLN devices but it could be one of = the >>>> interesting aspects that can be added to COAP feature; especially th= at >>>> COAP is supposed to help the end-points with their resource and serv= ice >>>> discovery. >>>> >>>> Thanks >>>> -Mehdi >>>> >>>> >>>> -----Original Message----- >>>> From: Yusuke DOI [mailto:yusuke.doi@toshiba.co.jp] >>>> Sent: lundi 22 juillet 2013 13:04 >>>> To: Mani, Mehdi >>>> Cc: core@ietf.org >>>> Subject: Re: [core] COAP and DHCP >>>> >>>> Dear Mehdi, >>>> >>>> I think if LLN nodes require some 'rich system-wide configuration' (= an >>>> example is MPL parameter), something like CoAP resource binding to D= HCPv6 >>>> option settings may work as replacement of stateless DHCPv6 (to get = rid >>>> of stateless DHCP code from CoAP-based LLN devices). However, I have= no >>>> idea on how to let clients know default CoAP server address to send >>>> 'Information-request' messages to. >>>> >>>> Regards, >>>> >>>> Yusuke >>>> >>>> (2013-07-18 00:10), Mani, Mehdi wrote: >>>>> I'm wondering if in Core WG there has ever been a discussion about >>>>> obtaining IPv6 address using COAP instead of using DHCP. >>>>> >>>>> In LLN, if we consider that COAP is used as management protocol whi= ch >>>>> configure end-points, why not using that for configuring a node for= its >>>>> IP address. This could be especially interesting to reduce the >>>>> registration transactions for LLN end-points. >>>>> >>>>> Looking forward to hearing the interesting comments. >>>>> >>>>> Thanks >>>>> >>>>> -Mehdi >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> core mailing list >>>>> core@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/core >>>>> >>>> >>>> _______________________________________________ >>>> core mailing list >>>> core@ietf.org >>>> https://www.ietf.org/mailman/listinfo/core >>> >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >> --=20 >> Zach Shelby, Chief Nerd, Sensinode Ltd. >> http://www.sensinode.com @SensinodeIoT >> Mobile: +358 40 7796297 >> Twitter: @zach_shelby >> LinkedIn: http://fi.linkedin.com/in/zachshelby >> 6LoWPAN Book: http://6lowpan.net >> >> >> >> > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --------------ms030703040605050602000807 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUDCC BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq 1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg 7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1 c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo 2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q peeU0rD+83X5f27nMIIGLjCCBRagAwIBAgIQXDFQ28QtqMuYch5f2nTvZjANBgkqhkiG9w0B AQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMTA5 MDIwMDAwMDBaFw0xNDA5MDEyMzU5NTlaMIIBNzELMAkGA1UEBhMCR0IxEDAOBgNVBBETB1dG NCA0V0ExFzAVBgNVBAgTDldlc3QgWW9ya3NoaXJlMRIwEAYDVQQHEwlXYWtlZmllbGQxFDAS BgNVBAkTC0dyYW5nZSBNb29yMR8wHQYDVQQJExY4OSBHcmVlbmZpZWxkIENyZXNjZW50MRcw FQYDVQQKEw5HcmlkbWVyZ2UgTHRkLjE0MDIGA1UECxMrSXNzdWVkIHRocm91Z2ggR3JpZG1l cmdlIEx0ZC4gRS1QS0kgTWFuYWdlcjEfMB0GA1UECxMWQ29ycG9yYXRlIFNlY3VyZSBFbWFp bDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdp ZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArcThqvLe WU1Q1ZJmnb+2UQSwOQKWok3A1Mwk582AdvwaAQyBFliPyJ0kXJqtwNBoZvk+3WJr0QA5ZRr+ J0x3sXVpcxadojP2HNzy1gsgDtIGG8ltoU4vmX1A8BTlOIUT+Pg8p/bSruxV0vz0CR8ho2hs R0Zi5vU+rQKNmbgufbkWhlQnMEYjknemscLQfw1YZz90ta67doNDujFy6+X6I06HpjudgMYx 8bdsNS5xVFFwuBA1eqNQra+xLzhCOeX9PPB/zK68qdNhrni3WPYG9EhSt4Dzk+xIz9hj7wrU ZIVXDTPsY8qbUSBVpwmzI5lCHPgzurH1OK7WwgpDSsl5pwIDAQABo4IB1TCCAdEwHwYDVR0j BBgwFoAUehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFBCOXNH+lDm8U9gy3b3bRvrx vKgrMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEDBTArMCkGCCsGAQUFBwIBFh1o dHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8v Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVt YWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29t b2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5j cnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRty b2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBAD6b/O0LkPav kR4Znoqxg0Ad7M3duDm4uzfrlX4ecgq56Ccdwd+3Tayz7Ewej30woVMmTKkA/NKRaCd0wVM9 8seF/oZjXKO7o1SH27igRnGSWjCoWXsdwJGfZbYnvcIIhhsxJoCPNbeSR7C0PAFDKsP3xrJy MHMljIJsoRbZu/fnYNyFWh9OXf7fYJOGmKDKAhSabUGfhY7umvU9d/YTqo02Q6YzC7d4zPNG 1a75AuHSEchf6GdKqycG38I5y9jlDaYfXspoS3PlTNCIeZONbOSMZgftnNEVKq+SWytFqyG/ 8+dwpm/a12KMex5J8iHwaUKj++2O2rAFNjDDqXpeEYoxggQZMIIEFQIBATCBqDCBkzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQXDFQ28QtqMuYch5f2nTvZjAJ BgUrDgMCGgUAoIICRTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzA3MjMxMjUyMDJaMCMGCSqGSIb3DQEJBDEWBBRb+GOJQdn5j0Nknq9KcmTfUVl26DBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEFwxUNvELajLmHIeX9p072YwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9m MA0GCSqGSIb3DQEBAQUABIIBADG58v6twK7s6v5zP0l/nR/9KczRUihWqHWp17aYNOOMFzUK e6UJJP3/mWQQQF/3mlXgBqX+f+NBK5syl7Z+PHBnoRkweQEQBw0h8gLlWzRW/54UooRG5q77 Q4xEY1mV4b5n+AyXdzZtRsgZrtxZxbn9tMwVaznarZH3NinDQvcG3Q/ZbCuwH9ubavfcfuwp 1KgtklUneTbfXUKjNbrJjj/G9EDEYauum2la9kL0f6Cmn+a1Ogp3hPzjiatXcRLuBJTa6nFf 2ArBvAJXDGVPvrjLknC96ukrMmSnEXMIX+1k1jj29xXDj1G4oKr1LuOFB/XsOqgUU9myhm2m sYEkN8gAAAAAAAA= --------------ms030703040605050602000807-- From Mehdi.Mani@itron.com Tue Jul 23 07:01:30 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C310D11E8125 for ; Tue, 23 Jul 2013 07:01:30 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJXKNXxeLLMt for ; Tue, 23 Jul 2013 07:01:27 -0700 (PDT) Received: from mail.itron.com (mail.itron.com [198.182.8.115]) by ietfa.amsl.com (Postfix) with ESMTP id 0A2F621F8319 for ; Tue, 23 Jul 2013 07:01:27 -0700 (PDT) Received: from ITR-EXMBXVS-1.itron.com ([192.168.9.112]) by spo-exchcn-1.itron.com ([192.168.9.115]) with mapi; Tue, 23 Jul 2013 07:01:22 -0700 From: "Mani, Mehdi" To: "robert.cragie@gridmerge.com" , "core@ietf.org" Date: Tue, 23 Jul 2013 07:01:20 -0700 Thread-Topic: [core] COAP and DHCP Thread-Index: Ac6Ho4DFOqX/YbZaQyOYg2HJDL/VKQABZl5A Message-ID: <10F62A0D440ACA41A85C7CB02936A1DB5B441F1638@ITR-EXMBXVS-1.itron.com> References: <6CA497E5-0C06-48AF-AD7B-93C387E1F5A1@sensinode.com> <201307221606.r6MG69jw017794@toshiba.co.jp> <51EE7C72.5050009@gridmerge.com> In-Reply-To: <51EE7C72.5050009@gridmerge.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [core] COAP and DHCP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 14:01:30 -0000 Robert, It's interesting what you describe. I also think it is a great idea to get = some basic bootstrapping configuration information in the time of authentic= ation. In DHCP you have an authentication option which can be used.=20 Finally I hope we find the right place to address bootstrapping process for= LLNs and IoT in IETF. -Mehdi=20 -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Rob= ert Cragie Sent: mardi 23 juillet 2013 14:52 To: core@ietf.org Subject: Re: [core] COAP and DHCP One of the issues is that each protocol which exists for its own reason has= its own set of configuration information which nodes need to perform a fun= ction using that protocol. In some respects, other protocols could be used = to distribute configuration information as they may provide a more appropri= ate vehicle. There were two occasions which I recall when we were working on ZigBee IP w= here it did seem to make sense to consider using other protocols to distrib= ute certain configuration information: 1) Use of PANA to distribute 802.15.4 MAC short address configuration infor= mation 2) Use of RPL DIO to distribute information typically disseminated using RA In the case of (1), it seems logical as at the point of authentication, a s= ecure delivery mechanism can also be deployed. Therefore, a "blob" of confi= guration information can be easily and securely delivered to a node which i= s being bootstrapped. We even worked through a case whereby the 802.15.4 MAC short address was delivered using this mechanism and then SLAA= C used to form the IPv6 address. DAD was not needed due to centralised allo= cation and indeed 6lowpan DAR/DAC was not needed.=20 However, this was not adopted primarily for the reason that it was consider= ed to be overloading the purpose of PANA and PANA relay to provide authenti= cation and to deliver a network key. Whilst that can't be disputed, it did = demonstrate that the authentication mechanism is a logical place for a trus= ted server to deliver bootstrapping configuration information to an authent= icated client in a controlled manner. Note something like 802.1X/RADIUS cou= ld also be used instead - it is more the general model of point-to-point of= untrusted node to enforcement point, then through network to authenticatio= n server model.=20 As DHCP has the relay model as well, it would also seem appropriate to use = DHCP. It may even make sense to consider extending DHCP to carry authentica= tion traffic, although that may be considered heresy :-). In the case of (2), the way DIOs are disseminated using the DODAG provide a= logical way to disseminate information from a root to all RPL-aware nodes.= Therefore it seemed logical to use RPL to disseminate this information thr= oughout the routers in the mesh. Then traditional RA could be used between = router and host. Note that neither mechanism was adopted in ZigBee IP because it was conside= red to be overloading the primary purpose of the protocol messages. However= , it may be worth considering these ideas again especially in constrained e= nvironments where to some extent any reduction in the amount of code and co= mplexity would help. However, in both cases, IMHO it is more important to c= onsider the way it is delivering or disseminating information than the actu= al protocol itself and to tie that to the configuration data. With regard to CoAP, I tend to agree with other comments here that it is mo= re appropriate for distributing application-layer configuration - and that = doesn't mean address assignment. Robert On 22/07/2013 17:06, DOI Yusuke wrote: > Dear Zach, Don, > > I also agree it would be not a good idea to do address configuration over= CoAP. But I think, especially for SLAAC-based LLNs, we don't have a handy = channel to distribute non-essential configurations, such as DNS server addr= ess or MPL parameters to be used in the network. DNS-SD could not be a good= choice for, to say, 1000 nodes of LLN with 5 hops or more. > > The choice in my mind is to deploy DHCP-relay over nodes and to use state= less DHCP to distribute such configuration parameters. It should work well = and I'm okay with it (so far, not tried to implement it yet). At the same t= ime I wonder if there is other choices such as Stateless-DHCP-Option-to-CoA= P-Resource mapping. > > Regards, > > Yusuke > > > > From: Zach Shelby > Subject: Re: [core] COAP and DHCP > Date: Mon, 22 Jul 2013 17:42:38 +0300 > >> Mehdi, >> >> I agree with Don here, it is not a great idea to mix basic IP network co= nfiguration services over a generic web protocol like CoAP. We can't reall= y depend on having CoAP available to do something basic like address assign= ment. That needs to work even when no application layer is present, e.g. in= a pure router. That said, we surely can manage a device, e.g. perform firm= ware updates, update application configuration parameters etc. over CoAP. F= or example the OMA Lightweight M2M standard does exactly this over CoAP usi= ng Object definitions (like a MIB). That works great for things that are in= dependent of the IP network. >> >> The discovery built into CoAP is meant to be used for resource discovery= , i.e. discovering what web resources a CoAP server has available. It was n= ot designed to be used as a generic service discovery mechanism. If you don= 't even know what protocol to use for your service, then you probably need = something like DNS-SD first. >> >> Regards, >> Zach >> >> On Jul 22, 2013, at 5:11 PM, Don Sturek wrote: >> >>> Hi Mehdi, >>> >>> I did see your earlier post regarding address assignment via CoAP..... >>> >>> I have to say, I think it is not wise to overload address assignment on >>> CoAP (which is really an application support protocol). CoAP does >>> support service discovery on ".well-known" (sorry if I got the syntax >>> wrong, this is from memory). If a richer service discovery is >>> wanted/needed, we should consider adding in a different standard=20 >>> rather than try to add those features directly into CoAP. >>> >>> Don >>> >>> >>> >>> On 7/22/13 6:19 AM, "Mani, Mehdi" wrote: >>> >>>> Hi Yusuke, >>>> >>>> It is in fact one of the advantages to get rid of DHCP codes on LLN=20 >>>> end-point. I don't know either if COAP is able to provide a kind of=20 >>>> autonomous service discovery for LLN devices but it could be one of=20 >>>> the interesting aspects that can be added to COAP feature;=20 >>>> especially that COAP is supposed to help the end-points with their=20 >>>> resource and service discovery. >>>> >>>> Thanks >>>> -Mehdi >>>> >>>> >>>> -----Original Message----- >>>> From: Yusuke DOI [mailto:yusuke.doi@toshiba.co.jp] >>>> Sent: lundi 22 juillet 2013 13:04 >>>> To: Mani, Mehdi >>>> Cc: core@ietf.org >>>> Subject: Re: [core] COAP and DHCP >>>> >>>> Dear Mehdi, >>>> >>>> I think if LLN nodes require some 'rich system-wide configuration'=20 >>>> (an example is MPL parameter), something like CoAP resource binding=20 >>>> to DHCPv6 option settings may work as replacement of stateless=20 >>>> DHCPv6 (to get rid of stateless DHCP code from CoAP-based LLN=20 >>>> devices). However, I have no idea on how to let clients know=20 >>>> default CoAP server address to send 'Information-request' messages to. >>>> >>>> Regards, >>>> >>>> Yusuke >>>> >>>> (2013-07-18 00:10), Mani, Mehdi wrote: >>>>> I'm wondering if in Core WG there has ever been a discussion about=20 >>>>> obtaining IPv6 address using COAP instead of using DHCP. >>>>> >>>>> In LLN, if we consider that COAP is used as management protocol=20 >>>>> which configure end-points, why not using that for configuring a=20 >>>>> node for its IP address. This could be especially interesting to=20 >>>>> reduce the registration transactions for LLN end-points. >>>>> >>>>> Looking forward to hearing the interesting comments. >>>>> >>>>> Thanks >>>>> >>>>> -Mehdi >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> core mailing list >>>>> core@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/core >>>>> >>>> >>>> _______________________________________________ >>>> core mailing list >>>> core@ietf.org >>>> https://www.ietf.org/mailman/listinfo/core >>> >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >> -- >> Zach Shelby, Chief Nerd, Sensinode Ltd. >> http://www.sensinode.com @SensinodeIoT >> Mobile: +358 40 7796297 >> Twitter: @zach_shelby >> LinkedIn: http://fi.linkedin.com/in/zachshelby >> 6LoWPAN Book: http://6lowpan.net >> >> >> >> > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From Mehdi.Mani@itron.com Tue Jul 23 07:03:33 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20A4521E8083 for ; Tue, 23 Jul 2013 07:03:33 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0E0SLiQisMv for ; Tue, 23 Jul 2013 07:03:29 -0700 (PDT) Received: from mail.itron.com (mail.itron.com [198.182.8.116]) by ietfa.amsl.com (Postfix) with ESMTP id 317DD21E804B for ; Tue, 23 Jul 2013 07:03:29 -0700 (PDT) Received: from ITR-EXMBXVS-1.itron.com ([192.168.9.112]) by spo-exchcn-2.itron.com ([192.168.9.116]) with mapi; Tue, 23 Jul 2013 07:03:24 -0700 From: "Mani, Mehdi" To: Zach Shelby Date: Tue, 23 Jul 2013 07:03:22 -0700 Thread-Topic: [core] COAP and DHCP Thread-Index: Ac6HDK0Ysqpk+iXoQ++DhWSpdEVBAgAoIe5w Message-ID: <10F62A0D440ACA41A85C7CB02936A1DB5B441F1640@ITR-EXMBXVS-1.itron.com> References: <6CA497E5-0C06-48AF-AD7B-93C387E1F5A1@sensinode.com> <10F62A0D440ACA41A85C7CB02936A1DB5B4417CFC0@ITR-EXMBXVS-1.itron.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "core@ietf.org WG" Subject: Re: [core] COAP and DHCP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 14:03:33 -0000 -----Original Message----- From: Zach Shelby [mailto:zach@sensinode.com]=20 Sent: lundi 22 juillet 2013 20:53 To: Mani, Mehdi Cc: core@ietf.org WG Subject: Re: [core] COAP and DHCP On Jul 22, 2013, at 7:11 PM, "Mani, Mehdi" wrote: > Zach, >=20 > I also agree that we should not depend only on a generic web protocol lik= e COAP for the basic network configuration services; but we may have such o= ption to use or not to use. I think the process of network discovery and ad= dress acquisition in IoT and LLN should be more efficient than what it is t= oday defined for conventional IPv6 networks and end-points. Maybe Core and = COAP is not the right place to address this issue.=20 Exactly. I think we all agree that network bootstrapping can be improved, b= ut CoRE is not the right place. This would be something to bring up in upco= ming 6LO WG for example? Do come to Berlin and support that BOF. I'll be in Berlin and if necessary I can raise this point in 6LO WG. > The other thing about OMA Lightweight M2M that I didn't get is that you m= entioned it is great for things that are independent of IP; but isn't COAP = defined to work on IP? Sorry, I wasn't clear enough. You are right, OMA Lightweight uses IP and Co= AP for communication of course (although it does support CoAP over SMS too.= ..).The point is that a device management solution over CoAP is great for m= anaging devices and application parameters, and even for monitoring network= s. However it isn't a solution for network bootstrapping. Even the deployme= nt scenario is wrong, typically the Lightweight M2M Server is located in a = backend server several IP networks removed from the endpoint.=20 Regards, Zach > Regards, > -Mehdi >=20 > -----Original Message----- > From: Zach Shelby [mailto:zach@sensinode.com] > Sent: lundi 22 juillet 2013 16:43 > To: Don Sturek > Cc: Mani, Mehdi; Yusuke DOI; core@ietf.org > Subject: Re: [core] COAP and DHCP >=20 > Mehdi, >=20 > I agree with Don here, it is not a great idea to mix basic IP network con= figuration services over a generic web protocol like CoAP. We can't really= depend on having CoAP available to do something basic like address assignm= ent. That needs to work even when no application layer is present, e.g. in = a pure router. That said, we surely can manage a device, e.g. perform firmw= are updates, update application configuration parameters etc. over CoAP. Fo= r example the OMA Lightweight M2M standard does exactly this over CoAP usin= g Object definitions (like a MIB). That works great for things that are ind= ependent of the IP network. >=20 > The discovery built into CoAP is meant to be used for resource discovery,= i.e. discovering what web resources a CoAP server has available. It was no= t designed to be used as a generic service discovery mechanism. If you don'= t even know what protocol to use for your service, then you probably need s= omething like DNS-SD first. >=20 > Regards, > Zach >=20 > On Jul 22, 2013, at 5:11 PM, Don Sturek wrote: >=20 >> Hi Mehdi, >>=20 >> I did see your earlier post regarding address assignment via CoAP..... >>=20 >> I have to say, I think it is not wise to overload address assignment on >> CoAP (which is really an application support protocol). CoAP does >> support service discovery on ".well-known" (sorry if I got the syntax >> wrong, this is from memory). If a richer service discovery is >> wanted/needed, we should consider adding in a different standard=20 >> rather than try to add those features directly into CoAP. >>=20 >> Don >>=20 >>=20 >>=20 >> On 7/22/13 6:19 AM, "Mani, Mehdi" wrote: >>=20 >>> Hi Yusuke, >>>=20 >>> It is in fact one of the advantages to get rid of DHCP codes on LLN=20 >>> end-point. I don't know either if COAP is able to provide a kind of=20 >>> autonomous service discovery for LLN devices but it could be one of=20 >>> the interesting aspects that can be added to COAP feature;=20 >>> especially that COAP is supposed to help the end-points with their=20 >>> resource and service discovery. >>>=20 >>> Thanks >>> -Mehdi >>>=20 >>>=20 >>> -----Original Message----- >>> From: Yusuke DOI [mailto:yusuke.doi@toshiba.co.jp] >>> Sent: lundi 22 juillet 2013 13:04 >>> To: Mani, Mehdi >>> Cc: core@ietf.org >>> Subject: Re: [core] COAP and DHCP >>>=20 >>> Dear Mehdi, >>>=20 >>> I think if LLN nodes require some 'rich system-wide configuration'=20 >>> (an example is MPL parameter), something like CoAP resource binding=20 >>> to DHCPv6 option settings may work as replacement of stateless=20 >>> DHCPv6 (to get rid of stateless DHCP code from CoAP-based LLN devices). >>> However, I have no idea on how to let clients know default CoAP=20 >>> server address to send 'Information-request' messages to. >>>=20 >>> Regards, >>>=20 >>> Yusuke >>>=20 >>> (2013-07-18 00:10), Mani, Mehdi wrote: >>>> I'm wondering if in Core WG there has ever been a discussion about=20 >>>> obtaining IPv6 address using COAP instead of using DHCP. >>>>=20 >>>> In LLN, if we consider that COAP is used as management protocol=20 >>>> which configure end-points, why not using that for configuring a=20 >>>> node for its IP address. This could be especially interesting to=20 >>>> reduce the registration transactions for LLN end-points. >>>>=20 >>>> Looking forward to hearing the interesting comments. >>>>=20 >>>> Thanks >>>>=20 >>>> -Mehdi >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> core mailing list >>>> core@ietf.org >>>> https://www.ietf.org/mailman/listinfo/core >>>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>=20 >>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >=20 > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://www.sensinode.com @SensinodeIoT > Mobile: +358 40 7796297 > Twitter: @zach_shelby > LinkedIn: http://fi.linkedin.com/in/zachshelby > 6LoWPAN Book: http://6lowpan.net >=20 >=20 >=20 >=20 -- Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com @SensinodeIoT Mobile: +358 40 7796297 Twitter: @zach_shelby LinkedIn: http://fi.linkedin.com/in/zachshelby 6LoWPAN Book: http://6lowpan.net From wasilak@gmail.com Thu Jul 25 03:36:52 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0FC721F89A6 for ; Thu, 25 Jul 2013 03:36:52 -0700 (PDT) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8u+KYJdISPm for ; Thu, 25 Jul 2013 03:36:51 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 63F4221F85C9 for ; Thu, 25 Jul 2013 03:36:50 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id hj3so5427957wib.10 for ; Thu, 25 Jul 2013 03:36:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gjuha5jro8wyDDn6KxXXX5ElUBOSoi/xP1EjQTH6NwM=; b=XQ9xvbUXg4yZZF1cLarYXclOoGyvd/JzcjmtywYubeJZEluyesJY0tkvZByfIAggi6 ujPMc0cnEcBArPhcV/7bygZrXQSfaDJd3unVtzveiRLvGEvvvhQY9EpBM4utTjwKOmIR IBzmPl5pznSWduo3c9bdtJ9vkEEZOqRxzXG4+E3KjCTKUCBnmyd0k1/AkmEJoU7BtAWS feumrWLuyG4q2mMUwXxG3nHN9YZOgbhP+xrkQCLMMAt+S5sOu1DvYTMuTukq0mLvwfEH Nn/Cmi1UMEz+KOFW8zzEYLPEsddriK4ZDjcTGcsLzk7uyLOPFjZrnndnsX0jSJSjwwa6 mWbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gjuha5jro8wyDDn6KxXXX5ElUBOSoi/xP1EjQTH6NwM=; b=XkfAw6+I0vBZOs1f07jqdw1ur5FG4b/sgi52xRCAvOy7U9Yuloi1+WG2Q4vX4QvPQX 2KXJQPX5HpbpCWaQ2BDngs8ssTa7pSE+ozgNdCTvVG7Xt2cLRBqvv7/teh9yGUQIHMmq krh9V1Q6686igdr3QFmAAJKuBU/wCoyoenxaaSJDJZjCewc/iPFmX2SUfwD2+bvKsoqC rMj4/EckuGzP32ayHEltVrQBDCYsnZOKWGMjPTUiedVt3Co1czrIBWL3msw+vGcl5ERu x70J/w4PP0AgQnj/VBL0kBHfd/2v2E4Fd/V3tovicCa2beFGG3xgjplLJgaiKtyXViGn kCbw== MIME-Version: 1.0 X-Received: by 10.180.198.146 with SMTP id jc18mr1514964wic.61.1374748609413; Thu, 25 Jul 2013 03:36:49 -0700 (PDT) Received: by 10.216.52.200 with HTTP; Thu, 25 Jul 2013 03:36:49 -0700 (PDT) In-Reply-To: <10F62A0D440ACA41A85C7CB02936A1DB5B441F1640@ITR-EXMBXVS-1.itron.com> References: <6CA497E5-0C06-48AF-AD7B-93C387E1F5A1@sensinode.com> <10F62A0D440ACA41A85C7CB02936A1DB5B4417CFC0@ITR-EXMBXVS-1.itron.com> <10F62A0D440ACA41A85C7CB02936A1DB5B441F1640@ITR-EXMBXVS-1.itron.com> Date: Thu, 25 Jul 2013 12:36:49 +0200 Message-ID: From: Maciej Wasilak To: "Mani, Mehdi" Content-Type: multipart/alternative; boundary=047d7b6226ca85098a04e2539add Cc: "core@ietf.org WG" Subject: Re: [core] COAP and DHCP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 10:36:52 -0000 --047d7b6226ca85098a04e2539add Content-Type: text/plain; charset=UTF-8 Hello Everyone, I think if we want CoAP to become popular for network device management and configuration we should market it as "Linux approach". In Linux there is one big directory tree: /etc -> device configuration /home -> user data /dev -> device status It is easy to mimic this approach with CoAP: there is one resource tree, and both application resources and device configuration resources are on it. And every Linux programmer in the world immediately understands what it's all about. Best Regards Maciek 2013/7/23 Mani, Mehdi > > > -----Original Message----- > From: Zach Shelby [mailto:zach@sensinode.com] > Sent: lundi 22 juillet 2013 20:53 > To: Mani, Mehdi > Cc: core@ietf.org WG > Subject: Re: [core] COAP and DHCP > > On Jul 22, 2013, at 7:11 PM, "Mani, Mehdi" wrote: > > > Zach, > > > > I also agree that we should not depend only on a generic web protocol > like COAP for the basic network configuration services; but we may have > such option to use or not to use. I think the process of network discovery > and address acquisition in IoT and LLN should be more efficient than what > it is today defined for conventional IPv6 networks and end-points. Maybe > Core and COAP is not the right place to address this issue. > > Exactly. I think we all agree that network bootstrapping can be improved, > but CoRE is not the right place. This would be something to bring up in > upcoming 6LO WG for example? Do come to Berlin and support that BOF. > > I'll be in Berlin and if necessary I can raise this point in 6LO WG. > > > The other thing about OMA Lightweight M2M that I didn't get is that you > mentioned it is great for things that are independent of IP; but isn't COAP > defined to work on IP? > > Sorry, I wasn't clear enough. You are right, OMA Lightweight uses IP and > CoAP for communication of course (although it does support CoAP over SMS > too...).The point is that a device management solution over CoAP is great > for managing devices and application parameters, and even for monitoring > networks. However it isn't a solution for network bootstrapping. Even the > deployment scenario is wrong, typically the Lightweight M2M Server is > located in a backend server several IP networks removed from the endpoint. > > Regards, > Zach > > > Regards, > > -Mehdi > > > > -----Original Message----- > > From: Zach Shelby [mailto:zach@sensinode.com] > > Sent: lundi 22 juillet 2013 16:43 > > To: Don Sturek > > Cc: Mani, Mehdi; Yusuke DOI; core@ietf.org > > Subject: Re: [core] COAP and DHCP > > > > Mehdi, > > > > I agree with Don here, it is not a great idea to mix basic IP network > configuration services over a generic web protocol like CoAP. We can't > really depend on having CoAP available to do something basic like address > assignment. That needs to work even when no application layer is present, > e.g. in a pure router. That said, we surely can manage a device, e.g. > perform firmware updates, update application configuration parameters etc. > over CoAP. For example the OMA Lightweight M2M standard does exactly this > over CoAP using Object definitions (like a MIB). That works great for > things that are independent of the IP network. > > > > The discovery built into CoAP is meant to be used for resource > discovery, i.e. discovering what web resources a CoAP server has available. > It was not designed to be used as a generic service discovery mechanism. If > you don't even know what protocol to use for your service, then you > probably need something like DNS-SD first. > > > > Regards, > > Zach > > > > On Jul 22, 2013, at 5:11 PM, Don Sturek wrote: > > > >> Hi Mehdi, > >> > >> I did see your earlier post regarding address assignment via CoAP..... > >> > >> I have to say, I think it is not wise to overload address assignment on > >> CoAP (which is really an application support protocol). CoAP does > >> support service discovery on ".well-known" (sorry if I got the syntax > >> wrong, this is from memory). If a richer service discovery is > >> wanted/needed, we should consider adding in a different standard > >> rather than try to add those features directly into CoAP. > >> > >> Don > >> > >> > >> > >> On 7/22/13 6:19 AM, "Mani, Mehdi" wrote: > >> > >>> Hi Yusuke, > >>> > >>> It is in fact one of the advantages to get rid of DHCP codes on LLN > >>> end-point. I don't know either if COAP is able to provide a kind of > >>> autonomous service discovery for LLN devices but it could be one of > >>> the interesting aspects that can be added to COAP feature; > >>> especially that COAP is supposed to help the end-points with their > >>> resource and service discovery. > >>> > >>> Thanks > >>> -Mehdi > >>> > >>> > >>> -----Original Message----- > >>> From: Yusuke DOI [mailto:yusuke.doi@toshiba.co.jp] > >>> Sent: lundi 22 juillet 2013 13:04 > >>> To: Mani, Mehdi > >>> Cc: core@ietf.org > >>> Subject: Re: [core] COAP and DHCP > >>> > >>> Dear Mehdi, > >>> > >>> I think if LLN nodes require some 'rich system-wide configuration' > >>> (an example is MPL parameter), something like CoAP resource binding > >>> to DHCPv6 option settings may work as replacement of stateless > >>> DHCPv6 (to get rid of stateless DHCP code from CoAP-based LLN devices). > >>> However, I have no idea on how to let clients know default CoAP > >>> server address to send 'Information-request' messages to. > >>> > >>> Regards, > >>> > >>> Yusuke > >>> > >>> (2013-07-18 00:10), Mani, Mehdi wrote: > >>>> I'm wondering if in Core WG there has ever been a discussion about > >>>> obtaining IPv6 address using COAP instead of using DHCP. > >>>> > >>>> In LLN, if we consider that COAP is used as management protocol > >>>> which configure end-points, why not using that for configuring a > >>>> node for its IP address. This could be especially interesting to > >>>> reduce the registration transactions for LLN end-points. > >>>> > >>>> Looking forward to hearing the interesting comments. > >>>> > >>>> Thanks > >>>> > >>>> -Mehdi > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> core mailing list > >>>> core@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/core > >>>> > >>> > >>> > >>> _______________________________________________ > >>> core mailing list > >>> core@ietf.org > >>> https://www.ietf.org/mailman/listinfo/core > >> > >> > >> _______________________________________________ > >> core mailing list > >> core@ietf.org > >> https://www.ietf.org/mailman/listinfo/core > > > > -- > > Zach Shelby, Chief Nerd, Sensinode Ltd. > > http://www.sensinode.com @SensinodeIoT > > Mobile: +358 40 7796297 > > Twitter: @zach_shelby > > LinkedIn: http://fi.linkedin.com/in/zachshelby > > 6LoWPAN Book: http://6lowpan.net > > > > > > > > > > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://www.sensinode.com @SensinodeIoT > Mobile: +358 40 7796297 > Twitter: @zach_shelby > LinkedIn: http://fi.linkedin.com/in/zachshelby > 6LoWPAN Book: http://6lowpan.net > > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --047d7b6226ca85098a04e2539add Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Everyone,

=
I think if we want CoAP to become popular for network device manageme= nt and configuration we should market it as "Linux approach". In = Linux there is one big directory tree:

/etc -> device configuration
/home -> user data
/dev -> device status

It is easy to mimic this appro= ach with CoAP: there is one resource tree, and both application resources a= nd device configuration resources are on it. And every Linux programmer in = the world immediately understands what it's all about.

Best Regards
Maciek
=

2013/7/23 Mani, Mehdi = <Mehdi.Mani@it= ron.com>


-----Original Message-----
From: Zach Shelby [mailto:zach@sensin= ode.com]
Sent: lundi 22 juillet 2013 20:53
To: Mani, Mehdi
Cc: core@ietf.org<= /a> WG
Subject: Re: [core] COAP and DHCP

On Jul 22, 2013, at 7:11 PM, "Mani, Mehdi"= ; <Mehdi.Mani@itron.com> = wrote:

> Zach,
>
> I also agree that we should not depend only on a generic web protocol = like COAP for the basic network configuration services; but we may have suc= h option to use or not to use. I think the process of network discovery and= address acquisition in IoT and LLN should be more efficient than what it i= s today defined for conventional IPv6 networks and end-points. Maybe Core a= nd COAP is not the right place to address this issue.

Exactly. I think we all agree that network bootstrapping can be improved, b= ut CoRE is not the right place. This would be something to bring up in upco= ming 6LO WG for example? Do come to Berlin and support that BOF.

I'll be in Berlin and if necessary I can raise this point in 6LO = WG.

> The other thing about OMA Lightweight M2M that I didn't get is tha= t you mentioned it is great for things that are independent of IP; but isn&= #39;t COAP defined to work on IP?

Sorry, I wasn't clear enough. You are right, OMA Lightweight uses= IP and CoAP for communication of course (although it does support CoAP ove= r SMS too...).The point is that a device management solution over CoAP is g= reat for managing devices and application parameters, and even for monitori= ng networks. However it isn't a solution for network bootstrapping. Eve= n the deployment scenario is wrong, typically the Lightweight M2M Server is= located in a backend server several IP networks removed from the endpoint.=

Regards,
Zach

> Regards,
> -Mehdi
>
> -----Original Message-----
> From: Zach Shelby [mailto:zach@s= ensinode.com]
> Sent: lundi 22 juillet 2013 16:43
> To: Don Sturek
> Cc: Mani, Mehdi; Yusuke DOI; core@iet= f.org
> Subject: Re: [core] COAP and DHCP
>
> Mehdi,
>
> I agree with Don here, it is not a great idea to mix basic IP network = configuration services over a generic web protocol like CoAP. =C2=A0We can&= #39;t really depend on having CoAP available to do something basic like add= ress assignment. That needs to work even when no application layer is prese= nt, e.g. in a pure router. That said, we surely can manage a device, e.g. p= erform firmware updates, update application configuration parameters etc. o= ver CoAP. For example the OMA Lightweight M2M standard does exactly this ov= er CoAP using Object definitions (like a MIB). That works great for things = that are independent of the IP network.
>
> The discovery built into CoAP is meant to be used for resource discove= ry, i.e. discovering what web resources a CoAP server has available. It was= not designed to be used as a generic service discovery mechanism. If you d= on't even know what protocol to use for your service, then you probably= need something like DNS-SD first.
>
> Regards,
> Zach
>
> On Jul 22, 2013, at 5:11 PM, Don Sturek <d.sturek@att.net> wrote:
>
>> Hi Mehdi,
>>
>> I did see your earlier post regarding address assignment via CoAP.= ....
>>
>> I have to say, I think it is not wise to overload address assignme= nt on
>> CoAP (which is really an application support protocol). =C2=A0 CoA= P does
>> support service discovery on ".well-known" (sorry if I g= ot the syntax
>> wrong, this is from memory). =C2=A0 If a richer service discovery = is
>> wanted/needed, we should consider adding in a different standard >> rather than try to add those features directly into CoAP.
>>
>> Don
>>
>>
>>
>> On 7/22/13 6:19 AM, "Mani, Mehdi" <Mehdi.Mani@itron.com> wrote:
>>
>>> Hi Yusuke,
>>>
>>> It is in fact one of the advantages to get rid of DHCP codes o= n LLN
>>> end-point. I don't know either if COAP is able to provide = a kind of
>>> autonomous service discovery for LLN devices but it could be o= ne of
>>> the interesting aspects that can be added to COAP feature;
>>> especially that COAP is supposed to help the end-points with t= heir
>>> resource and service discovery.
>>>
>>> Thanks
>>> -Mehdi
>>>
>>>
>>> -----Original Message-----
>>> From: Yusuke DOI [mailto:yusuke.doi@toshiba.co.jp]
>>> Sent: lundi 22 juillet 2013 13:04
>>> To: Mani, Mehdi
>>> Cc: core@ietf.org
>>> Subject: Re: [core] COAP and DHCP
>>>
>>> Dear Mehdi,
>>>
>>> I think if LLN nodes require some 'rich system-wide config= uration'
>>> (an example is MPL parameter), something like CoAP resource bi= nding
>>> to DHCPv6 option settings may work as replacement of stateless=
>>> DHCPv6 (to get rid of stateless DHCP code from CoAP-based LLN = devices).
>>> However, I have no idea on how to let clients know default CoA= P
>>> server address to send 'Information-request' messages = to.
>>>
>>> Regards,
>>>
>>> Yusuke
>>>
>>> (2013-07-18 00:10), Mani, Mehdi wrote:
>>>> I'm wondering if in Core WG there has ever been a disc= ussion about
>>>> obtaining IPv6 address using COAP instead of using DHCP. >>>>
>>>> In LLN, if we consider that COAP is used as management pro= tocol
>>>> which configure end-points, why not using that for configu= ring a
>>>> node for its IP address. This could be especially interest= ing to
>>>> reduce the registration transactions for LLN end-points. >>>>
>>>> Looking forward to hearing the interesting comments.
>>>>
>>>> Thanks
>>>>
>>>> -Mehdi
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> core mailing list
>>>> core@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/core
>>>>
>>>
>>>
>>> _______________________________________________
>>> core mailing list
>>> core@ietf.org
>>> https://www.ietf.org/mailman/listinfo/core
>>
>>
>> _______________________________________________
>> core mailing list
>> core@ietf.org
>> https://www.ietf.org/mailman/listinfo/core
>
> --
> Zach Shelby, Chief Nerd, Sensinode Ltd.
> http://www.sens= inode.com @SensinodeIoT
> Mobile: = +358 40 7796297
> Twitter: @zach_shelby
> LinkedIn: http://fi.linkedin.com/in/zachshelby
> 6LoWPAN Book: http://= 6lowpan.net
>
>
>
>

--
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode= .com @SensinodeIoT
Mobile: +358 = 40 7796297
Twitter: @zach_shelby
LinkedIn: http://fi.linkedin.com/in/zachshelby
6LoWPAN Book: http://6lowp= an.net




_______________________________________________
core mailing list
core@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/core

--047d7b6226ca85098a04e2539add-- From j.schoenwaelder@jacobs-university.de Thu Jul 25 07:39:08 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9296C21F9477 for ; Thu, 25 Jul 2013 07:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJow95Xt1XgK for ; Thu, 25 Jul 2013 07:39:03 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 02E0721F8C9D for ; Thu, 25 Jul 2013 07:39:02 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6BEDC20D45; Thu, 25 Jul 2013 16:39:01 +0200 (CEST) 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 9eMTXsX6qfIU; Thu, 25 Jul 2013 16:39:01 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C5EE220D3C; Thu, 25 Jul 2013 16:39:00 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1C2A827797D2; Thu, 25 Jul 2013 16:38:56 +0200 (CEST) Date: Thu, 25 Jul 2013 16:38:55 +0200 From: Juergen Schoenwaelder To: Maciej Wasilak Message-ID: <20130725143855.GC42280@elstar.local> Mail-Followup-To: Maciej Wasilak , "Mani, Mehdi" , "core@ietf.org WG" References: <6CA497E5-0C06-48AF-AD7B-93C387E1F5A1@sensinode.com> <10F62A0D440ACA41A85C7CB02936A1DB5B4417CFC0@ITR-EXMBXVS-1.itron.com> <10F62A0D440ACA41A85C7CB02936A1DB5B441F1640@ITR-EXMBXVS-1.itron.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "core@ietf.org WG" Subject: Re: [core] COAP and DHCP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 14:39:08 -0000 On Thu, Jul 25, 2013 at 12:36:49PM +0200, Maciej Wasilak wrote: > Hello Everyone, > > I think if we want CoAP to become popular for network device management and > configuration we should market it as "Linux approach". In Linux there is > one big directory tree: > > /etc -> device configuration > /home -> user data > /dev -> device status > /dev is not 'device status'. That said, if CoAP people want to reinvent network management as well, you may want to take a look at other stuff done in the past - perhaps there is something to learn from it (e.g. the notion of separation of config state from operational state). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From cabo@tzi.org Thu Jul 25 08:32:25 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6919A21F9AFE for ; Thu, 25 Jul 2013 08:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJWJD1ZlEmDN for ; Thu, 25 Jul 2013 08:32:19 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 62B0F21F9AEB for ; Thu, 25 Jul 2013 08:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r6PFWBtL013161; Thu, 25 Jul 2013 17:32:11 +0200 (CEST) Received: from [192.168.217.105] (p54894526.dip0.t-ipconnect.de [84.137.69.38]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 13C8C41B; Thu, 25 Jul 2013 17:32:11 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <20130725143855.GC42280@elstar.local> Date: Thu, 25 Jul 2013 17:32:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1A93DBA2-4674-41BE-AAC0-AA49268F5C07@tzi.org> References: <6CA497E5-0C06-48AF-AD7B-93C387E1F5A1@sensinode.com> <10F62A0D440ACA41A85C7CB02936A1DB5B4417CFC0@ITR-EXMBXVS-1.itron.com> <10F62A0D440ACA41A85C7CB02936A1DB5B441F1640@ITR-EXMBXVS-1.itron.com> <20130725143855.GC42280@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1508) Cc: "core@ietf.org WG" Subject: Re: [core] COAP and DHCP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 15:32:25 -0000 On Jul 25, 2013, at 16:38, Juergen Schoenwaelder = wrote: > /dev is not 'device status'. No. And the analogy also lacks because in a REST world, clients are = discovering URIs, while in a UNIX file system, the file system structure = is pretty much a given. > That said, if CoAP people want to > reinvent network management as well, you may want to take a look at > other stuff done in the past - perhaps there is something to learn > from it (e.g. the notion of separation of config state from > operational state). I don't know all "CoAP people", but I hope we don't re-invent as much as = we simplify. Just as CoAP was a radically simplifying, but in the end conservative = revisit of the principles of HTTP and the Web, maybe we can do something = as radically conservative for network management. If the CoAP protocol = itself turns out to be useful for that, that is great, but it should not = be the driving consideration. Gr=FC=DFe, Carsten From d.sturek@att.net Thu Jul 25 08:45:41 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DEE221F9AE3 for ; Thu, 25 Jul 2013 08:45:41 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ogjb-cOuhNQW for ; Thu, 25 Jul 2013 08:45:33 -0700 (PDT) Received: from nm15-vm5.access.bullet.mail.bf1.yahoo.com (nm15-vm5.access.bullet.mail.bf1.yahoo.com [216.109.115.36]) by ietfa.amsl.com (Postfix) with ESMTP id 50C2A21F9814 for ; Thu, 25 Jul 2013 08:45:28 -0700 (PDT) Received: from [66.196.81.166] by nm15.access.bullet.mail.bf1.yahoo.com with NNFMP; 25 Jul 2013 15:45:25 -0000 Received: from [98.138.84.212] by tm12.access.bullet.mail.bf1.yahoo.com with NNFMP; 25 Jul 2013 15:45:25 -0000 Received: from [127.0.0.1] by smtp101.sbc.mail.ne1.yahoo.com with NNFMP; 25 Jul 2013 15:45:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1374767125; bh=ZAz7rdiCqzgBoJHq+SJCxpjgbFNv3uFnZQVlgREaLng=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=xlTsQ1JlLKZoB8nbTCgQ6nlLhb8p+mbjLSa3MiOH/0faT5iE6hIWXEYC4qExhQggg6cnzeiTjN0C3YDQ0aDxPM+8BEEF4t05MQN/ortqUMjbgTulg7gOrt23/nc/NHOI74i2TqWx69jT/q2GQk6WALnXnmYVBYOjFyo/wc0r4Hk= X-Yahoo-Newman-Id: 839861.89509.bm@smtp101.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: CaGfZu8VM1lGDtrF4Kg.S8aP7u071ybhT_cnqd6kKNDNJee FG4uAAfexlhfCaY3oeX0aoxnvcqF59WlXVLy1H.fUvs0aEFPEU_KR3YteB0W F3NLu9csEigASt0O5Q1R_.cgtfgmSm8xDgca.PEj6Vj2O.rre4STCy2g8rIo eHAxBwxp6QybP3D_ZZLywLNDaGYsaAge_mQnzzIykONXQr.n49PituDP.6B_ je0wNPt26ktFppzcsQw7SQE3lWxme3H73hdyw3I4AdYIfgE0OMGdolS9gJZX xykeSLyhFw2DpxU5tcNS3PtZwsZl3KCUCkZ9bodTnirGDORoz6J7tLsq58MJ g2M8NBUb08_7Tf16kyscg9h0St2swscoODQyDLPUQJCuvRqK3lAEso.jfN7u ekITKLjyVVlNXYfrtAxCN5oU8h8PnvUENcp7TpHkKWm3lWSodGSJMle7D18v 7oQyckprSoPyWxZwwruw7jP_S6YI.XcHMMklx_C1SMl0mlqsRLlHC3XJBfbT Rzs4pxI8.DSXKrZOPYvY- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-Rocket-Received: from [10.0.0.4] (d.sturek@67.124.200.231 with login) by smtp101.sbc.mail.ne1.yahoo.com with SMTP; 25 Jul 2013 08:45:25 -0700 PDT User-Agent: Microsoft-MacOutlook/14.3.6.130613 Date: Thu, 25 Jul 2013 08:42:55 -0700 From: Don Sturek To: Carsten Bormann , Juergen Schoenwaelder Message-ID: Thread-Topic: [core] COAP and DHCP In-Reply-To: <1A93DBA2-4674-41BE-AAC0-AA49268F5C07@tzi.org> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: "core@ietf.org WG" Subject: Re: [core] COAP and DHCP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 15:45:42 -0000 Hi Carsten, +1 on "Just as CoAP was a radically simplifying, but in the end conservative revisit of the principles of HTTP and the Web, maybe we can do something as radically conservative for network management". I realize that CORE is maybe not the place for this, however, I believe for IoT that an analagous simplication of SNMP is needed (much like what CoAP did for HTTP). Where could these proposals take place? My fear is that implementers will stretch CoAP to address network management which will be the wrong thing to do. Don On 7/25/13 8:32 AM, "Carsten Bormann" wrote: >On Jul 25, 2013, at 16:38, Juergen Schoenwaelder > wrote: > >> /dev is not 'device status'. > >No. And the analogy also lacks because in a REST world, clients are >discovering URIs, while in a UNIX file system, the file system structure >is pretty much a given. > >> That said, if CoAP people want to >> reinvent network management as well, you may want to take a look at >> other stuff done in the past - perhaps there is something to learn >> from it (e.g. the notion of separation of config state from >> operational state). > >I don't know all "CoAP people", but I hope we don't re-invent as much as >we simplify. >Just as CoAP was a radically simplifying, but in the end conservative >revisit of the principles of HTTP and the Web, maybe we can do something >as radically conservative for network management. If the CoAP protocol >itself turns out to be useful for that, that is great, but it should not >be the driving consideration. > >Gr=FC=DFe, Carsten > >_______________________________________________ >core mailing list >core@ietf.org >https://www.ietf.org/mailman/listinfo/core From zach@sensinode.com Thu Jul 25 09:15:39 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 660D221F997D for ; Thu, 25 Jul 2013 09:15:39 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TG-Vtab-S0Dx for ; Thu, 25 Jul 2013 09:15:35 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 815C221F9971 for ; Thu, 25 Jul 2013 09:15:32 -0700 (PDT) Received: from [192.168.1.100] (188-67-182-132.bb.dnainternet.fi [188.67.182.132]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id r6PGFPkW015658 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 25 Jul 2013 19:15:26 +0300 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Zach Shelby In-Reply-To: Date: Thu, 25 Jul 2013 19:15:24 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Don Sturek X-Mailer: Apple Mail (2.1503) Cc: "core@ietf.org WG" Subject: Re: [core] COAP and DHCP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 16:15:39 -0000 On Jul 25, 2013, at 6:42 PM, Don Sturek wrote: > +1 on "Just as CoAP was a radically simplifying, but in the end > conservative revisit of the principles of HTTP and the Web, maybe we = can > do something as radically conservative for network management". >=20 > I realize that CORE is maybe not the place for this, however, I = believe > for IoT that an analagous simplication of SNMP is needed (much like = what > CoAP did for HTTP). >=20 > Where could these proposals take place? My fear is that implementers = will > stretch CoAP to address network management which will be the wrong = thing > to do. CoAP is great for doing general device management (app configuration, = location monitoring, firmware updates, security management etc.), as = that is usually an integral function of the same application on a = contained device being used for application specific purposes (e.g. a = street light). OMA Lightweight M2M enables this kind of functionality = using Objects over CoAP. It would not make any sense to deploy yet = another protocol on a constrained device for that purpose. What are the network management needs on a constrained device really? If = you only need to do some simple network status monitoring, then by all = means just add one more Object to your CoAP endpoint and you are done. = There is already a nice Connectivity Monitoring Object defined by OMA = that can be used for that purpose. However I agree with Don for complex network management, e.g. getting = into border routers and deep troubleshooting and configuration of = multiple protocols, you might need a specialised protocol. But at the = same time, running SNMP in a border router is no problem. When do we = really need complex network management on a constrained device?=20 This thread started with address configuration, and now we're treading = on the COMAN discussion. But since we're there... In my opinion there = will not be a one-size-fits-all protocol solution for network management = on the Internet of Things. For network infrastructure SNMP works just = fine, for many Web based devices HTTP is already in use, and yes, for = simple constrained devices folks can just use CoAP. What we need is a = common way to express a MIB and then easily use that over any of these = protocols. That makes network management protocol independent as it = should be - and would be a very worthwhile output from the IETF. CORE is = not the right place to do that obviously. Zach=20 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com @SensinodeIoT Mobile: +358 40 7796297 Twitter: @zach_shelby LinkedIn: http://fi.linkedin.com/in/zachshelby 6LoWPAN Book: http://6lowpan.net From d.sturek@att.net Thu Jul 25 09:29:23 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4683021F965B for ; Thu, 25 Jul 2013 09:29:22 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rsFKdcjhe0L6 for ; Thu, 25 Jul 2013 09:29:15 -0700 (PDT) Received: from nm14-vm8.access.bullet.mail.gq1.yahoo.com (nm14-vm8.access.bullet.mail.gq1.yahoo.com [216.39.63.222]) by ietfa.amsl.com (Postfix) with ESMTP id 3506721F98AD for ; Thu, 25 Jul 2013 09:29:00 -0700 (PDT) Received: from [216.39.60.175] by nm14.access.bullet.mail.gq1.yahoo.com with NNFMP; 25 Jul 2013 16:28:59 -0000 Received: from [98.138.84.212] by tm11.access.bullet.mail.gq1.yahoo.com with NNFMP; 25 Jul 2013 16:28:59 -0000 Received: from [127.0.0.1] by smtp101.sbc.mail.ne1.yahoo.com with NNFMP; 25 Jul 2013 16:28:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1374769738; bh=nNyELs8znvsKAKphlTNChxxwj9rVHAwKzCedcI0LIXM=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=4fJyKElZ/RFxeISv9yYRZm4eMa1WCd2pDxsaPZp7jRXgdwuKqGcTH9d0WBAdJ1weRZHLOY/+7oUnC60chF6inSwE+PH6qzT2CmYygFv/e10+Pmg39foHzahhxyvHhc4HD+Fx2oMh0eFEr89BLv4mLDSPZopaaCR/ezIOzV/UlQ4= X-Yahoo-Newman-Id: 981503.97935.bm@smtp101.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 79CytrAVM1nATGL8EqgTgIq9ugbv9fhq70vrU84ngbbofPh KXXxHwkJg2_QVAjW2LpZoQb.RfUoSZ5pTkZnrow0qLcMPpunm0NZi6tECROR ddw7T6VxKwN7Ncmbs6iT.a3PakshveoxSDo3RC5L2rUyuJb3NNi4KrGvF9jc NuufZGPB4lpMVKZ4H_NexcTtN6DDrp0F0wOVgvrG8DC4BLEjpfAVU.bPEp6m lHyxch_9lct0ADmKMYW4vHGpkK2c02uAcKj_3o_tGFFBDBCMz8mmL.vgW3PV 17BO3zI8kETGDBVPtmv1O2ZLRtTY.niGeY1qWKu0cedrpd5tWft.lDV8SSsA 685WW5MtJgbiNNOwXCv3bqjOaQERm67k.nmLI_SAY1VUiBGyx..BFo9nogkX f6Lcepsif4mKI8ItKa1ZZooCTB_Fsv3bXV13V8CHBTHknoD9uxx7h99yzTkV qUZ8Gt1j35bnaXJYwEekdOcWxI3Ef3Lv_XR.i3cxWEJK7nfIt0XqpghzyJ4A ydILNYjYWPGLta1RbaVdB4bBxXnVsdcpaS2FIC3zewkQDY.M7a2JyI.Fs.TS f6IgmjSsCc0EronVfP0.rk5GVVFqLZWU7xUVaGphGA6wWH5z2Ug49MWwdOrR dWxSx9kKJANUuv_9EalWjNSsuimb7Pm7M2vBLVJ7GsPWIaSPh1flyYjl95qw C6ESgaiAYzR3H X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-Rocket-Received: from [10.0.0.4] (d.sturek@67.124.200.231 with login) by smtp101.sbc.mail.ne1.yahoo.com with SMTP; 25 Jul 2013 09:28:58 -0700 PDT User-Agent: Microsoft-MacOutlook/14.3.6.130613 Date: Thu, 25 Jul 2013 09:26:27 -0700 From: Don Sturek To: Zach Shelby Message-ID: Thread-Topic: [core] COAP and DHCP In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "core@ietf.org WG" Subject: Re: [core] COAP and DHCP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 16:29:23 -0000 Hi Zach, Agree that CoAP works well for general device management. What I was thinking of is a network of sensors (say on an oil pipleline) where it would be useful to treat these sensor devices much as you would as a managed set of devices using SNMP. Things like alarms (eg, low battery, etc.), status collection, etc. For the lower end of device complexity, it would seem that SNMP might be a bit of overkill....... Don On 7/25/13 9:15 AM, "Zach Shelby" wrote: >On Jul 25, 2013, at 6:42 PM, Don Sturek wrote: > >> +1 on "Just as CoAP was a radically simplifying, but in the end >> conservative revisit of the principles of HTTP and the Web, maybe we can >> do something as radically conservative for network management". >> >> I realize that CORE is maybe not the place for this, however, I believe >> for IoT that an analagous simplication of SNMP is needed (much like what >> CoAP did for HTTP). >> >> Where could these proposals take place? My fear is that implementers >>will >> stretch CoAP to address network management which will be the wrong thing >> to do. > >CoAP is great for doing general device management (app configuration, >location monitoring, firmware updates, security management etc.), as that >is usually an integral function of the same application on a contained >device being used for application specific purposes (e.g. a street >light). OMA Lightweight M2M enables this kind of functionality using >Objects over CoAP. It would not make any sense to deploy yet another >protocol on a constrained device for that purpose. > >What are the network management needs on a constrained device really? If >you only need to do some simple network status monitoring, then by all >means just add one more Object to your CoAP endpoint and you are done. >There is already a nice Connectivity Monitoring Object defined by OMA >that can be used for that purpose. > >However I agree with Don for complex network management, e.g. getting >into border routers and deep troubleshooting and configuration of >multiple protocols, you might need a specialised protocol. But at the >same time, running SNMP in a border router is no problem. When do we >really need complex network management on a constrained device? > >This thread started with address configuration, and now we're treading on >the COMAN discussion. But since we're there... In my opinion there will >not be a one-size-fits-all protocol solution for network management on >the Internet of Things. For network infrastructure SNMP works just fine, >for many Web based devices HTTP is already in use, and yes, for simple >constrained devices folks can just use CoAP. What we need is a common way >to express a MIB and then easily use that over any of these protocols. >That makes network management protocol independent as it should be - and >would be a very worthwhile output from the IETF. CORE is not the right >place to do that obviously. > >Zach > >-- >Zach Shelby, Chief Nerd, Sensinode Ltd. >http://www.sensinode.com @SensinodeIoT >Mobile: +358 40 7796297 >Twitter: @zach_shelby >LinkedIn: http://fi.linkedin.com/in/zachshelby >6LoWPAN Book: http://6lowpan.net > > > > From stokcons@xs4all.nl Thu Jul 25 23:58:36 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76C8C11E80E1 for ; Thu, 25 Jul 2013 23:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.479 X-Spam-Level: X-Spam-Status: No, score=-0.479 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tm9ILWbnjGTu for ; Thu, 25 Jul 2013 23:58:32 -0700 (PDT) Received: from smtp-vbr4.xs4all.nl (smtp-vbr4.xs4all.nl [194.109.24.24]) by ietfa.amsl.com (Postfix) with ESMTP id 0134311E80A2 for ; Thu, 25 Jul 2013 23:58:31 -0700 (PDT) Received: from roundcube.xs4all.nl (roundcube8.xs4all.net [194.109.20.206]) by smtp-vbr4.xs4all.nl (8.13.8/8.13.8) with ESMTP id r6Q6wUnb001997 for ; Fri, 26 Jul 2013 08:58:30 +0200 (CEST) (envelope-from stokcons@xs4all.nl) Received: from a82-95-140-48.adsl.xs4all.nl ([82.95.140.48]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Fri, 26 Jul 2013 08:58:30 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 26 Jul 2013 08:58:30 +0200 From: peter van der Stok To: core@ietf.org Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: Message-ID: <30a774271b70a25f3b360e645afd5813@xs4all.nl> X-Sender: stokcons@xs4all.nl (2iZJ6NU3VMNv86d47NYO/Gp87+QS1LaI) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Subject: Re: [core] COAP and DHCP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 06:58:36 -0000 Hi Zach, I agree with the phrase: > What > we need is a common way to express parts of > a MIB and then easily use that over > any of these protocols. That makes network management protocol > independent as it should be - and would be a very worthwhile output > from the IETF. CORE is not the right place to do that obviously. What is an obvious place to do this? Coman? Peter Zach Shelby schreef op 2013-07-25 18:15: > On Jul 25, 2013, at 6:42 PM, Don Sturek wrote: > > +1 on "Just as CoAP was a radically simplifying, but in the end > conservative revisit of the principles of HTTP and the Web, maybe we > can > do something as radically conservative for network management". > > I realize that CORE is maybe not the place for this, however, I believe > for IoT that an analagous simplication of SNMP is needed (much like > what > CoAP did for HTTP). > > Where could these proposals take place? My fear is that implementers > will > stretch CoAP to address network management which will be the wrong > thing > to do. > > CoAP is great for doing general device management (app configuration, > location monitoring, firmware updates, security management etc.), as > that is usually an integral function of the same application on a > contained device being used for application specific purposes (e.g. a > street light). OMA Lightweight M2M enables this kind of functionality > using Objects over CoAP. It would not make any sense to deploy yet > another protocol on a constrained device for that purpose. > > What are the network management needs on a constrained device really? > If you only need to do some simple network status monitoring, then by > all means just add one more Object to your CoAP endpoint and you are > done. There is already a nice Connectivity Monitoring Object defined > by OMA that can be used for that purpose. > > However I agree with Don for complex network management, e.g. getting > into border routers and deep troubleshooting and configuration of > multiple protocols, you might need a specialised protocol. But at the > same time, running SNMP in a border router is no problem. When do we > really need complex network management on a constrained device? > > This thread started with address configuration, and now we're treading > on the COMAN discussion. But since we're there... In my opinion there > will not be a one-size-fits-all protocol solution for network > management on the Internet of Things. For network infrastructure SNMP > works just fine, for many Web based devices HTTP is already in use, > and yes, for simple constrained devices folks can just use CoAP. What > we need is a common way to express a MIB and then easily use that over > any of these protocols. That makes network management protocol > independent as it should be - and would be a very worthwhile output > from the IETF. CORE is not the right place to do that obviously. > > Zach > > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://www.sensinode.com @SensinodeIoT > Mobile: +358 40 7796297 > Twitter: @zach_shelby > LinkedIn: http://fi.linkedin.com/in/zachshelby > 6LoWPAN Book: http://6lowpan.net > > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From zach@sensinode.com Fri Jul 26 01:01:34 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3873821F8A53 for ; Fri, 26 Jul 2013 01:01:34 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TIocD-byiTyO for ; Fri, 26 Jul 2013 01:01:30 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 6363D21F8F2E for ; Fri, 26 Jul 2013 01:01:29 -0700 (PDT) Received: from [192.168.1.100] (188-67-182-132.bb.dnainternet.fi [188.67.182.132]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id r6Q816XS032308 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 26 Jul 2013 11:01:20 +0300 X-Authenticated-User: sensinodecom Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Zach Shelby In-Reply-To: <30a774271b70a25f3b360e645afd5813@xs4all.nl> Date: Fri, 26 Jul 2013 11:01:04 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <4CB9DEF4-E0A5-4A03-88E3-69FC4BB5D1EF@sensinode.com> References: <30a774271b70a25f3b360e645afd5813@xs4all.nl> To: consultancy@vanderstok.org X-Mailer: Apple Mail (2.1503) Cc: core@ietf.org Subject: Re: [core] COAP and DHCP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 08:01:34 -0000 On Jul 26, 2013, at 9:58 AM, peter van der Stok = wrote: > I agree with the phrase: >=20 >> What >> we need is a common way to express > parts of >> a MIB and then easily use that over >> any of these protocols. That makes network management protocol >> independent as it should be - and would be a very worthwhile output >> from the IETF. CORE is not the right place to do that obviously. >=20 > What is an obvious place to do this? Coman? The OPS Area sounds like the right place. Coman really isn't a place = yet, as it has been an e-mail discussion so far. Could either be an = existing working group (is there a suitable one?), or a new working = group with a narrow scope. The thing that worries me about a new WG is = that we have the tendency at the IETF to invent a new protocol every = time we do that :-)=20 Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com @SensinodeIoT Mobile: +358 40 7796297 Twitter: @zach_shelby LinkedIn: http://fi.linkedin.com/in/zachshelby 6LoWPAN Book: http://6lowpan.net From stokcons@xs4all.nl Fri Jul 26 01:38:14 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 823F121F85E8 for ; Fri, 26 Jul 2013 01:38:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.485 X-Spam-Level: X-Spam-Status: No, score=-0.485 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dMyAm6wJjugP for ; Fri, 26 Jul 2013 01:38:08 -0700 (PDT) Received: from smtp-vbr15.xs4all.nl (smtp-vbr15.xs4all.nl [194.109.24.35]) by ietfa.amsl.com (Postfix) with ESMTP id 0332021F854E for ; Fri, 26 Jul 2013 01:38:07 -0700 (PDT) Received: from roundcube.xs4all.nl (roundcube8.xs4all.net [194.109.20.206]) by smtp-vbr15.xs4all.nl (8.13.8/8.13.8) with ESMTP id r6Q8c6FF003299; Fri, 26 Jul 2013 10:38:06 +0200 (CEST) (envelope-from stokcons@xs4all.nl) Received: from a82-95-140-48.adsl.xs4all.nl ([82.95.140.48]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Fri, 26 Jul 2013 10:38:06 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 26 Jul 2013 10:38:06 +0200 From: peter van der Stok To: Zach Shelby Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <4CB9DEF4-E0A5-4A03-88E3-69FC4BB5D1EF@sensinode.com> References: <30a774271b70a25f3b360e645afd5813@xs4all.nl> <4CB9DEF4-E0A5-4A03-88E3-69FC4BB5D1EF@sensinode.com> Message-ID: <6c25912e87280549659e2d3b599353f9@xs4all.nl> X-Sender: stokcons@xs4all.nl (lboH34wJYqvoEDlW/1sdilH+kS3DLBdJ) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Cc: core@ietf.org Subject: Re: [core] COAP and DHCP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 08:38:14 -0000 Zach Shelby schreef op 2013-07-26 10:01: I share your worry. However, just a few things need to be standardized here: a naming convention, a path, a discovery procedure, different viable encodings and their spec,.. It is more about choices between existing solutions and how to specify them in the requests over the network, and ..... making sure that it is extensible, usable for other organisations. Having written that, an existing wg is fine with me, and netconf looks the closest to the subject. Peter > On Jul 26, 2013, at 9:58 AM, peter van der Stok > wrote: > > I agree with the phrase: > > What > we need is a common way to express > parts of > a MIB and then easily use that over > any of these protocols. That makes network management protocol > independent as it should be - and would be a very worthwhile output > from the IETF. CORE is not the right place to do that obviously. > > What is an obvious place to do this? Coman? > > The OPS Area sounds like the right place. Coman really isn't a place > yet, as it has been an e-mail discussion so far. Could either be an > existing working group (is there a suitable one?), or a new working > group with a narrow scope. The thing that worries me about a new WG is > that we have the tendency at the IETF to invent a new protocol every > time we do that :-) > > Zach From Mehdi.Mani@itron.com Fri Jul 26 05:40:34 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B61C221F9344 for ; Fri, 26 Jul 2013 05:40:34 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CiBWb+3hZQ6c for ; Fri, 26 Jul 2013 05:40:30 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0238.outbound.protection.outlook.com [207.46.163.238]) by ietfa.amsl.com (Postfix) with ESMTP id 8A29521F8EE6 for ; Fri, 26 Jul 2013 05:40:30 -0700 (PDT) Received: from BL2PR04MB082.namprd04.prod.outlook.com (10.255.231.149) by BL2PR04MB083.namprd04.prod.outlook.com (10.255.231.151) with Microsoft SMTP Server (TLS) id 15.0.731.12; Fri, 26 Jul 2013 12:40:27 +0000 Received: from BL2PR04MB082.namprd04.prod.outlook.com ([169.254.1.91]) by BL2PR04MB082.namprd04.prod.outlook.com ([169.254.1.91]) with mapi id 15.00.0731.000; Fri, 26 Jul 2013 12:40:26 +0000 From: "Mani, Mehdi" To: Zach Shelby , Don Sturek Thread-Topic: [core] COAP and DHCP Thread-Index: Ac6HDK0Ysqpk+iXoQ++DhWSpdEVBAgAoIe5wAF1qWIAACHSLgAAB2/GAAABgQ4AAASJtAAApQyQg Date: Fri, 26 Jul 2013 12:40:26 +0000 Message-ID: <4b3418d932cc45a7b5c7e21e645bd818@BL2PR04MB082.namprd04.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [85.115.60.180] x-forefront-prvs: 091949432C x-forefront-antispam-report: SFV:NSPM; SFS:(24454002)(51704005)(189002)(199002)(377454003)(13464003)(16601075003)(561944002)(51856001)(56776001)(76482001)(54356001)(53806001)(54316002)(59766001)(77982001)(74316001)(46102001)(74366001)(69226001)(4396001)(81542001)(74706001)(74876001)(81342001)(50986001)(47976001)(56816003)(83072001)(47736001)(15202345003)(49866001)(77096001)(80022001)(65816001)(66066001)(76576001)(76796001)(76786001)(74662001)(31966008)(19580405001)(19580395003)(63696002)(47446002)(16406001)(19580385001)(79102001)(74502001)(33646001)(83322001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR04MB083; H:BL2PR04MB082.namprd04.prod.outlook.com; CLIP:85.115.60.180; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: itron.com Cc: "core@ietf.org WG" Subject: Re: [core] COAP and DHCP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 12:40:34 -0000 Zach, I share your opinion. LLN and IoT are fuzzy concepts. The constraints and p= riorities in one use case scenario and application could be very different = from others; so it is not useful (and even harmful) to define a "one-size-f= its-all" network management protocol. Defining MIBs which cover essential n= eeds can help or at least alleviate network management issues. However, as = you mentioned we started the discussion from address assignment and basic c= onfiguration processes a node need to go through to be connected to the net= work and not network management. I believe there are two issues here for LL= Ns: 1) network protocol with light message exchange which tolerates delay a= nd packet loss. We are almost good for this issue in IETF; however the prob= lem is that for each step of bootstrapping there is a specific protocol (wh= ich is optimized by itself if we look at it alone) and you cannot use one p= rotocol to carry the information that you were supposed to get in next step= . This comes from the fact that each protocol says I'm not designed for thi= s purpose and hence this takes us to the second issue: 2) node stack compl= exity: that being said, today a node needs to have the codes of different a= pplication modules (designed for a specific purpose) installed on it to be = able to connect to the network and discover the services. For instance in m= any scenarios LLN node with constrained resources just need to have the add= ress of one server to get rid of DHCP code but it cannot. I believe what is lacking is a document that recommends protocols/options/c= onfigurations that are scattered in different WGs (which are not necessary = IoT WGs) and says this is IETF protocol solutions that cover A to Z steps a= LLN node need to go through to be functional. Once we do so, we can see wh= at is missing which WGs need to be involved... I personally am volunteer to= start such activity but I hope I get help of some IETF mentors. Regards -Mehdi -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Zac= h Shelby Sent: jeudi 25 juillet 2013 18:15 To: Don Sturek Cc: core@ietf.org WG Subject: Re: [core] COAP and DHCP On Jul 25, 2013, at 6:42 PM, Don Sturek wrote: > +1 on "Just as CoAP was a radically simplifying, but in the end > conservative revisit of the principles of HTTP and the Web, maybe we=20 > can do something as radically conservative for network management". >=20 > I realize that CORE is maybe not the place for this, however, I=20 > believe for IoT that an analagous simplication of SNMP is needed (much=20 > like what CoAP did for HTTP). >=20 > Where could these proposals take place? My fear is that implementers=20 > will stretch CoAP to address network management which will be the=20 > wrong thing to do. CoAP is great for doing general device management (app configuration, locat= ion monitoring, firmware updates, security management etc.), as that is usu= ally an integral function of the same application on a contained device bei= ng used for application specific purposes (e.g. a street light). OMA Lightw= eight M2M enables this kind of functionality using Objects over CoAP. It wo= uld not make any sense to deploy yet another protocol on a constrained devi= ce for that purpose. What are the network management needs on a constrained device really? If yo= u only need to do some simple network status monitoring, then by all means = just add one more Object to your CoAP endpoint and you are done. There is a= lready a nice Connectivity Monitoring Object defined by OMA that can be use= d for that purpose. However I agree with Don for complex network management, e.g. getting into = border routers and deep troubleshooting and configuration of multiple proto= cols, you might need a specialised protocol. But at the same time, running = SNMP in a border router is no problem. When do we really need complex netwo= rk management on a constrained device?=20 This thread started with address configuration, and now we're treading on t= he COMAN discussion. But since we're there... In my opinion there will not = be a one-size-fits-all protocol solution for network management on the Inte= rnet of Things. For network infrastructure SNMP works just fine, for many W= eb based devices HTTP is already in use, and yes, for simple constrained de= vices folks can just use CoAP. What we need is a common way to express a MI= B and then easily use that over any of these protocols. That makes network = management protocol independent as it should be - and would be a very worth= while output from the IETF. CORE is not the right place to do that obviousl= y. Zach=20 -- Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com @SensinodeIoT Mobile: +358 40 7796297 Twitter: @zach_shelby LinkedIn: http://fi.linkedin.com/in/zachshelby 6LoWPAN Book: http://6lowpan.net _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From cabo@tzi.org Fri Jul 26 08:22:15 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A199721F99A4 for ; Fri, 26 Jul 2013 08:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6oD7gaEoEkpl for ; Fri, 26 Jul 2013 08:22:11 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id DADB321F99BE for ; Fri, 26 Jul 2013 08:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r6QFLn1V012375 for ; Fri, 26 Jul 2013 17:21:49 +0200 (CEST) Received: from [172.27.14.151] (unknown [195.37.142.72]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 905D57BE; Fri, 26 Jul 2013 17:21:49 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Fri, 26 Jul 2013 17:21:49 +0200 To: "core@ietf.org WG" Message-Id: <0E70CA43-B9C0-4A8E-AABC-11DE5C45913F@tzi.org> Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [core] CoRE Agenda X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 15:22:15 -0000 I just uploaded the agenda for the IETF87 CoRE meetings to http://www.ietf.org/proceedings/87/agenda/agenda-87-core If you requested a slot and don't find yourself in there, please tell us = quickly. If you do have a slot, please check whether the time allocation and the = objectives are right. I also need your slides by Sunday. Gr=FC=DFe, Carsten From thp@comnets.uni-bremen.de Sat Jul 27 06:43:23 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36BE121F8D6D for ; Sat, 27 Jul 2013 06:43:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lnxAZm5O4mCh for ; Sat, 27 Jul 2013 06:43:18 -0700 (PDT) Received: from bugs.comnets.uni-bremen.de (bugs.comnets.uni-bremen.de [134.102.186.10]) by ietfa.amsl.com (Postfix) with ESMTP id 381BE21F8C66 for ; Sat, 27 Jul 2013 06:43:18 -0700 (PDT) Received: from lloret.localnet (unknown [10.8.0.122]) by bugs.comnets.uni-bremen.de (Postfix) with ESMTPS id 93636D4521F for ; Sat, 27 Jul 2013 15:43:16 +0200 (CEST) From: Thomas =?iso-8859-1?q?P=F6tsch?= To: core@ietf.org Date: Sat, 27 Jul 2013 15:43:13 +0200 User-Agent: KMail/1.13.7 (Linux/3.2.0-2-amd64; KDE/4.8.4; x86_64; ; ) MIME-Version: 1.0 Message-Id: <201307271543.13891.thp@comnets.uni-bremen.de> Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [core] Call for pre-discussions on Alternative Transports X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jul 2013 13:43:24 -0000 Dear all In the core session on Thursday (13:00 -15:00), we will have a 40 minute=20 timeslot to discuss alternative transports for CoAP. As listed in the agend= a,=20 there are six drafts available on this topic: draft-becker-core-coap-sms-gprs-03 draft-becker-core-transport-scenarios-00 draft-silverajan-core-coap-alternative-transports-02 draft-softgear-core-coapa-00 draft-savolainen-core-coap-websockets-00 draft-ikpark-core-shim-00 As already discussed with Carsten, it might be a good idea to shedule a=20 meeting in advance to structure the 40 minutes. Therefore, I would suggest = to=20 meet with all affected authors and those who are interested in it right aft= er=20 the core session on Monday. Viele Gr=FC=DFe, Thomas P=F6tsch =2D----------------------------------------------- Thomas P=F6tsch, M.Sc. Ph.D Student Communication Networks Group - FB 1 University of Bremen Otto-Hahn-Allee 1 28359 Bremen Germany Tel.: +49 421 218 62376 =46ax: +49 421 218 62750 E-Mail: thp@comnets.uni-bremen.de Web: http://www.comnets.uni-bremen.de/~thp Building: NW1 Room: N2260 From rick.bullotta@thingworx.com Sat Jul 27 06:48:53 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC4221F8904 for ; Sat, 27 Jul 2013 06:48:53 -0700 (PDT) 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=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id llWl5aSNiSMW for ; Sat, 27 Jul 2013 06:48:49 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0206.outbound.protection.outlook.com [207.46.163.206]) by ietfa.amsl.com (Postfix) with ESMTP id EB40621F89A6 for ; Sat, 27 Jul 2013 06:48:48 -0700 (PDT) Received: from BLUPR06MB001.namprd06.prod.outlook.com (10.242.190.139) by BLUPR06MB002.namprd06.prod.outlook.com (10.242.190.142) with Microsoft SMTP Server (TLS) id 15.0.731.16; Sat, 27 Jul 2013 13:48:46 +0000 Received: from BLUPR06MB001.namprd06.prod.outlook.com ([169.254.1.81]) by BLUPR06MB001.namprd06.prod.outlook.com ([169.254.1.98]) with mapi id 15.00.0731.000; Sat, 27 Jul 2013 13:48:45 +0000 From: Rick Bullotta To: =?iso-8859-1?Q?Thomas_P=F6tsch?= Thread-Topic: [core] Call for pre-discussions on Alternative Transports Thread-Index: AQHOis9JX9Zfbrkc3UavfobTyIE3aZl4imeo Date: Sat, 27 Jul 2013 13:48:45 +0000 Message-ID: <57C92B16-BDCC-48CC-8F9D-E524A6097E11@thingworx.com> References: <201307271543.13891.thp@comnets.uni-bremen.de> In-Reply-To: <201307271543.13891.thp@comnets.uni-bremen.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [72.23.57.127] x-forefront-prvs: 0920602B08 x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(189002)(51704005)(377454003)(252514010)(24454002)(16406001)(4396001)(49866001)(69226001)(56816003)(50986001)(15202345003)(47976001)(46102001)(81342001)(76482001)(54356001)(83072001)(47736001)(54316002)(77096001)(51856001)(74876001)(33656001)(76796001)(53806001)(76786001)(19580395003)(74366001)(59766001)(74502001)(47446002)(66066001)(79102001)(63696002)(31966008)(74706001)(80022001)(36756003)(65816001)(74662001)(81542001)(77982001)(56776001)(19580385001)(83322001)(19580405001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR06MB002; H:BLUPR06MB001.namprd06.prod.outlook.com; CLIP:72.23.57.127; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: thingworx.com Cc: "core@ietf.org" Subject: Re: [core] Call for pre-discussions on Alternative Transports X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jul 2013 13:48:53 -0000 Are any of these sessions being live streamed? On Jul 27, 2013, at 9:43 AM, "Thomas P=F6tsch" = wrote: > Dear all >=20 > In the core session on Thursday (13:00 -15:00), we will have a 40 minute= =20 > timeslot to discuss alternative transports for CoAP. As listed in the age= nda,=20 > there are six drafts available on this topic: >=20 > draft-becker-core-coap-sms-gprs-03 > draft-becker-core-transport-scenarios-00 > draft-silverajan-core-coap-alternative-transports-02 > draft-softgear-core-coapa-00 > draft-savolainen-core-coap-websockets-00 > draft-ikpark-core-shim-00 >=20 > As already discussed with Carsten, it might be a good idea to shedule a=20 > meeting in advance to structure the 40 minutes. Therefore, I would sugges= t to=20 > meet with all affected authors and those who are interested in it right a= fter=20 > the core session on Monday. >=20 > Viele Gr=FC=DFe, > Thomas P=F6tsch >=20 > ------------------------------------------------ > Thomas P=F6tsch, M.Sc. > Ph.D Student >=20 > Communication Networks Group - FB 1 > University of Bremen > Otto-Hahn-Allee 1 > 28359 Bremen > Germany >=20 > Tel.: +49 421 218 62376 > Fax: +49 421 218 62750 > E-Mail: thp@comnets.uni-bremen.de > Web: http://www.comnets.uni-bremen.de/~thp > Building: NW1 Room: N2260 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From hartke@tzi.org Sat Jul 27 07:18:00 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0154621F9A30 for ; Sat, 27 Jul 2013 07:18:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id se4hGqOLPLGw for ; Sat, 27 Jul 2013 07:17:55 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 47C4421F9A2A for ; Sat, 27 Jul 2013 07:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r6REHmm0029342 for ; Sat, 27 Jul 2013 16:17:48 +0200 (CEST) Received: from mail-vb0-f48.google.com (mail-vb0-f48.google.com [209.85.212.48]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id D81D48B5 for ; Sat, 27 Jul 2013 16:17:47 +0200 (CEST) Received: by mail-vb0-f48.google.com with SMTP id w15so1905356vbf.35 for ; Sat, 27 Jul 2013 07:17:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uwdVyTyAg+4WYPUgtDnEKmHDvIpSfIRpcguY390Aafk=; b=M0wWyKW6sQfjMPYZrAxYc0fIYhikY76Sz0vB5dERIZfnNwfF2Zs1MRSIuvDxL19mq7 sqE3PfoFrT27xuDNUyn5Sfpry+zTFxj5WqPhylVoCHl71NM875NLos9U9+QgG9TNXj7c viccTSh/+o8It3qaNiiTQ0SfD9BcxFR0Ah96FULmDId+DpGPtVy+MHhQ7f3h/82uo+Be PHpOqltJ6ghNo56WzwnCjyu+0omGbV+hwOGmhFv0DopJ2kQF0F22u5B26jdWD9VK0s5v sR1AMDhHYI95woVDAlOBJYs5Mw+HzuJLkJ49kWIxLQ2w3cT0OZ4wC5Ywg3FNU2RYJ7SD tujw== MIME-Version: 1.0 X-Received: by 10.58.97.199 with SMTP id ec7mr23120359veb.72.1374934666732; Sat, 27 Jul 2013 07:17:46 -0700 (PDT) Received: by 10.52.76.163 with HTTP; Sat, 27 Jul 2013 07:17:46 -0700 (PDT) In-Reply-To: <57C92B16-BDCC-48CC-8F9D-E524A6097E11@thingworx.com> References: <201307271543.13891.thp@comnets.uni-bremen.de> <57C92B16-BDCC-48CC-8F9D-E524A6097E11@thingworx.com> Date: Sat, 27 Jul 2013 17:17:46 +0300 Message-ID: From: Klaus Hartke To: Rick Bullotta Content-Type: multipart/alternative; boundary=089e013a0696666dc304e27eec60 Cc: "core@ietf.org" Subject: Re: [core] Call for pre-discussions on Alternative Transports X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jul 2013 14:18:00 -0000 --089e013a0696666dc304e27eec60 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The meetings of the CoRE working group on Monday and Thursday are live streamed. You can find links to the audio streams here: < http://tools.ietf.org/agenda/87/>. Hallway discussions such as the one proposed by Thomas are not live streamed. Klaus On Saturday, 27 July 2013, Rick Bullotta wrote: > Are any of these sessions being live streamed? > > On Jul 27, 2013, at 9:43 AM, "Thomas P=F6tsch" > > wrote: > > > Dear all > > > > In the core session on Thursday (13:00 -15:00), we will have a 40 minut= e > > timeslot to discuss alternative transports for CoAP. As listed in the > agenda, > > there are six drafts available on this topic: > > > > draft-becker-core-coap-sms-gprs-03 > > draft-becker-core-transport-scenarios-00 > > draft-silverajan-core-coap-alternative-transports-02 > > draft-softgear-core-coapa-00 > > draft-savolainen-core-coap-websockets-00 > > draft-ikpark-core-shim-00 > > > > As already discussed with Carsten, it might be a good idea to shedule a > > meeting in advance to structure the 40 minutes. Therefore, I would > suggest to > > meet with all affected authors and those who are interested in it right > after > > the core session on Monday. > > > > Viele Gr=FC=DFe, > > Thomas P=F6tsch > > > > ------------------------------------------------ > > Thomas P=F6tsch, M.Sc. > > Ph.D Student > > > > Communication Networks Group - FB 1 > > University of Bremen > > Otto-Hahn-Allee 1 > > 28359 Bremen > > Germany > > > > Tel.: +49 421 218 62376 > > Fax: +49 421 218 62750 > > E-Mail: thp@comnets.uni-bremen.de > > Web: http://www.comnets.uni-bremen.de/~thp > > Building: NW1 Room: N2260 > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --089e013a0696666dc304e27eec60 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The meetings of the CoRE working group on Monday and Thursday are live stre= amed. You can find=A0links to the audio=A0streams here: <http://tools.ietf.org/agenda/87/= >.=A0Hallway discussions such as the one proposed by Thoma= s are not live streamed.

Klaus


On Saturday, 27 July 2013, Rick Bullotta wrote:
Are any of these sessions being live streamed?

On Jul 27, 2013, at 9:43 AM, "Thomas P=F6tsch" <thp@comnets.uni-bremen.de> wrote:

> Dear all
>
> In the core session on Thursday (13:00 -15:00), we will have a 40 minu= te
> timeslot to discuss alternative transports for CoAP. As listed in the = agenda,
> there are six drafts available on this topic:
>
> =A0 =A0 =A0 =A0draft-becker-core-coap-sms-gprs-03
> =A0 =A0 =A0 =A0draft-becker-core-transport-scenarios-00
> =A0 =A0 =A0 =A0draft-silverajan-core-coap-alternative-transports-02 > =A0 =A0 =A0 =A0draft-softgear-core-coapa-00
> =A0 =A0 =A0 =A0draft-savolainen-core-coap-websockets-00
> =A0 =A0 =A0 =A0draft-ikpark-core-shim-00
>
> As already discussed with Carsten, it might be a good idea to shedule = a
> meeting in advance to structure the 40 minutes. Therefore, I would sug= gest to
> meet with all affected authors and those who are interested in it righ= t after
> the core session on Monday.
>
> Viele Gr=FC=DFe,
> Thomas P=F6tsch
>
> ------------------------------------------------
> Thomas P=F6tsch, M.Sc.
> Ph.D Student
>
> Communication Networks Group - FB 1
> University of Bremen
> Otto-Hahn-Allee 1
> 28359 Bremen
> Germany
>
> Tel.: +49 421 218 62376
> Fax: +49 421 218 62750
> E-Mail: thp@comnets.uni-bremen.de
> Web: http://www.comnets.uni-bremen.de/~thp
> Building: NW1 Room: N2260
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
_______________________________________________
core mailing list
core@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/core
--089e013a0696666dc304e27eec60-- From j.schoenwaelder@jacobs-university.de Sat Jul 27 11:09:35 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87F2611E80DF for ; Sat, 27 Jul 2013 11:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07Q1B2OCeJOG for ; Sat, 27 Jul 2013 11:09:31 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 2054311E80DE for ; Sat, 27 Jul 2013 11:09:31 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 33F7920BED; Sat, 27 Jul 2013 20:09:30 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 6t5yCn9RSJIH; Sat, 27 Jul 2013 20:09:30 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 835B720BEB; Sat, 27 Jul 2013 20:09:29 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id AC40D278F172; Sat, 27 Jul 2013 20:09:26 +0200 (CEST) Date: Sat, 27 Jul 2013 20:09:26 +0200 From: Juergen Schoenwaelder To: consultancy@vanderstok.org Message-ID: <20130727180926.GA3152@elstar.local> Mail-Followup-To: consultancy@vanderstok.org, Zach Shelby , core@ietf.org References: <30a774271b70a25f3b360e645afd5813@xs4all.nl> <4CB9DEF4-E0A5-4A03-88E3-69FC4BB5D1EF@sensinode.com> <6c25912e87280549659e2d3b599353f9@xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6c25912e87280549659e2d3b599353f9@xs4all.nl> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: core@ietf.org Subject: Re: [core] COAP and DHCP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jul 2013 18:09:35 -0000 On Fri, Jul 26, 2013 at 10:38:06AM +0200, peter van der Stok wrote: > Zach Shelby schreef op 2013-07-26 10:01: > > I share your worry. > However, just a few things need to be standardized here: > a naming convention, a path, a discovery procedure, different viable > encodings and their spec,.. > This is roughly the plan for another network management protocol plus data model. If the notion of constrained devices causes us to reinvent everything, then we are not talking about the Internet of Things but instead about Another Internet of Things. I hope we can avoid AIoT in favour of an IoT. (And contrary to some of you here, I believe that there will be many "things" in the future that use some form of 802.11 link layer instead of this severly limited 802.15.4 link layer and which will afford systems-on-a-ship capable to run embedded Linux systems, take the Belkin WeMo as an example. If we go down the path of reinventing everything for the AIoT, then by the time we are done, the constrained nodes may have disappeared. But hey, this is probably a bar talk topic. ;-) For many monitoring and trouble-shooting purposes, SMIv2 MIB modules have worked fine and if needed it is possible to carry the data in other formats over other protocols via automatic translations. The key of many MIB modules is to find agreement which counters need to be instrumented and on the precise semantics of the counters (e.g., how they all relate to each other). I would prefer if people concentrate on getting the instrumentation specification right instead of going off inventing a new network management framework or a new protocol independent data modeling language (there even was a WG once upon a time to do just that and people learned that it is much harder than you think). For those with access to IEEE xplore, you can read [1] or search for SMIng in the RFC index. /js [1] http://dx.doi.org/10.1109/MCOM.2008.4511663 -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From rick.bullotta@thingworx.com Sat Jul 27 11:20:51 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CA5E21F995A for ; Sat, 27 Jul 2013 11:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id klUyFKzDdJ2v for ; Sat, 27 Jul 2013 11:20:46 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0243.outbound.protection.outlook.com [207.46.163.243]) by ietfa.amsl.com (Postfix) with ESMTP id 846D721F9962 for ; Sat, 27 Jul 2013 11:20:36 -0700 (PDT) Received: from BLUPR06MB001.namprd06.prod.outlook.com (10.242.190.139) by BLUPR06MB002.namprd06.prod.outlook.com (10.242.190.142) with Microsoft SMTP Server (TLS) id 15.0.731.16; Sat, 27 Jul 2013 18:20:29 +0000 Received: from BLUPR06MB001.namprd06.prod.outlook.com ([169.254.1.81]) by BLUPR06MB001.namprd06.prod.outlook.com ([169.254.1.98]) with mapi id 15.00.0731.000; Sat, 27 Jul 2013 18:20:29 +0000 From: Rick Bullotta To: Juergen Schoenwaelder Thread-Topic: [core] COAP and DHCP Thread-Index: AQHOiUwgb4OX6bwzR9SSV1MmPBKldZl1iKqAgAAJEwCAAPa8AIAAEXsAgAAKWQCAAjH2AIAAAxc6 Date: Sat, 27 Jul 2013 18:20:29 +0000 Message-ID: <7A38E0BD-05B7-41B2-B4D5-DEF5140D99D8@thingworx.com> References: <30a774271b70a25f3b360e645afd5813@xs4all.nl> <4CB9DEF4-E0A5-4A03-88E3-69FC4BB5D1EF@sensinode.com> <6c25912e87280549659e2d3b599353f9@xs4all.nl>, <20130727180926.GA3152@elstar.local> In-Reply-To: <20130727180926.GA3152@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [72.23.57.127] x-forefront-prvs: 0920602B08 x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(189002)(51704005)(377424004)(24454002)(377454003)(4396001)(16406001)(49866001)(69226001)(47736001)(56816003)(50986001)(15202345003)(47976001)(46102001)(81342001)(76482001)(83072001)(54356001)(54316002)(77096001)(51856001)(74876001)(76786001)(33656001)(76796001)(53806001)(65816001)(31966008)(19580395003)(74366001)(74502001)(66066001)(63696002)(47446002)(74706001)(80022001)(36756003)(79102001)(74662001)(81542001)(59766001)(77982001)(56776001)(19580385001)(83322001)(19580405001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR06MB002; H:BLUPR06MB001.namprd06.prod.outlook.com; CLIP:72.23.57.127; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: thingworx.com Cc: "core@ietf.org" Subject: Re: [core] COAP and DHCP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jul 2013 18:20:51 -0000 +1 "Constrained" is a relative and ever changing term.=20 On Jul 27, 2013, at 2:09 PM, "Juergen Schoenwaelder" wrote: > On Fri, Jul 26, 2013 at 10:38:06AM +0200, peter van der Stok wrote: >> Zach Shelby schreef op 2013-07-26 10:01: >>=20 >> I share your worry. >> However, just a few things need to be standardized here: >> a naming convention, a path, a discovery procedure, different viable >> encodings and their spec,.. >=20 > This is roughly the plan for another network management protocol plus > data model. If the notion of constrained devices causes us to reinvent > everything, then we are not talking about the Internet of Things but > instead about Another Internet of Things. I hope we can avoid AIoT in > favour of an IoT. (And contrary to some of you here, I believe that > there will be many "things" in the future that use some form of 802.11 > link layer instead of this severly limited 802.15.4 link layer and > which will afford systems-on-a-ship capable to run embedded Linux > systems, take the Belkin WeMo as an example. If we go down the path of > reinventing everything for the AIoT, then by the time we are done, the > constrained nodes may have disappeared. But hey, this is probably a > bar talk topic. ;-) >=20 > For many monitoring and trouble-shooting purposes, SMIv2 MIB modules > have worked fine and if needed it is possible to carry the data in > other formats over other protocols via automatic translations. The key > of many MIB modules is to find agreement which counters need to be > instrumented and on the precise semantics of the counters (e.g., how > they all relate to each other).=20 >=20 > I would prefer if people concentrate on getting the instrumentation > specification right instead of going off inventing a new network > management framework or a new protocol independent data modeling > language (there even was a WG once upon a time to do just that and > people learned that it is much harder than you think). For those with > access to IEEE xplore, you can read [1] or search for SMIng in the > RFC index. >=20 > /js >=20 > [1] http://dx.doi.org/10.1109/MCOM.2008.4511663 >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From bilhanan.silverajan@tut.fi Sat Jul 27 13:44:59 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F305011E80F7 for ; Sat, 27 Jul 2013 13:44:58 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OHcj9xfJLM2A for ; Sat, 27 Jul 2013 13:44:54 -0700 (PDT) Received: from mail.cs.tut.fi (mail.cs.tut.fi [130.230.4.42]) by ietfa.amsl.com (Postfix) with SMTP id 9EA6011E80FD for ; Sat, 27 Jul 2013 13:44:52 -0700 (PDT) Received: from amavis2.cs.tut.fi (amavis2.cs.tut.fi [130.230.4.70]) by mail.cs.tut.fi (Postfix) with ESMTP id 3F78C9F4; Sat, 27 Jul 2013 23:44:51 +0300 (EEST) Received: from mail.cs.tut.fi ([130.230.4.42]) by amavis2.cs.tut.fi (amavis2.cs.tut.fi [130.230.4.70]) (amavisd-maia, port 10024) with ESMTP id 28645-02; Sat, 27 Jul 2013 23:44:50 +0300 (EEST) Received: from [192.168.252.246] (a91-155-218-185.elisa-laajakaista.fi [91.155.218.185]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.tut.fi (Postfix) with ESMTP id 596159F2; Sat, 27 Jul 2013 23:44:45 +0300 (EEST) Message-ID: <51F4313B.4020707@tut.fi> Date: Sat, 27 Jul 2013 23:44:43 +0300 From: Bill Silverajan User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: core@ietf.org, teemu.savolainen@nokia.com References: <201307271543.13891.thp@comnets.uni-bremen.de> In-Reply-To: <201307271543.13891.thp@comnets.uni-bremen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Virus-Scanned: Maia Mailguard 1.0.2 Content-Transfer-Encoding: quoted-printable Subject: Re: [core] Call for pre-discussions on Alternative Transports X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jul 2013 20:44:59 -0000 Hi Thomas, This sounds like a good idea to me, and I'll participate. Regards, Bill On 27/7/2013 4:43 PM, Thomas P=F6tsch wrote: > Dear all > > In the core session on Thursday (13:00 -15:00), we will have a 40 minut= e > timeslot to discuss alternative transports for CoAP. As listed in the a= genda, > there are six drafts available on this topic: > > draft-becker-core-coap-sms-gprs-03 > draft-becker-core-transport-scenarios-00 > draft-silverajan-core-coap-alternative-transports-02 > draft-softgear-core-coapa-00 > draft-savolainen-core-coap-websockets-00 > draft-ikpark-core-shim-00 > > As already discussed with Carsten, it might be a good idea to shedule a > meeting in advance to structure the 40 minutes. Therefore, I would sugg= est to > meet with all affected authors and those who are interested in it right= after > the core session on Monday. > > Viele Gr=FC=DFe, > Thomas P=F6tsch > > ------------------------------------------------ > Thomas P=F6tsch, M.Sc. > Ph.D Student > > Communication Networks Group - FB 1 > University of Bremen > Otto-Hahn-Allee 1 > 28359 Bremen > Germany > > Tel.: +49 421 218 62376 > Fax: +49 421 218 62750 > E-Mail: thp@comnets.uni-bremen.de > Web: http://www.comnets.uni-bremen.de/~thp > Building: NW1 Room: N2260 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --=20 | Bilhanan Silverajan Tel: +358 (0)40 849 0757 | | Tampere University of Technology, Finland | From teemu.savolainen@nokia.com Sun Jul 28 13:08:35 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23B4121F99E9 for ; Sun, 28 Jul 2013 13:08:35 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id npYriGUuWG0z for ; Sun, 28 Jul 2013 13:08:26 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id B46D521F8A67 for ; Sun, 28 Jul 2013 13:08:26 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r6SK8MeI026759; Sun, 28 Jul 2013 23:08:23 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.59]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sun, 28 Jul 2013 23:08:22 +0300 Received: from 008-AM1MPN1-053.mgdnok.nokia.com ([169.254.3.140]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.03.0136.001; Sun, 28 Jul 2013 20:08:21 +0000 From: To: , Thread-Topic: [core] Call for pre-discussions on Alternative Transports Thread-Index: AQHOis9JMa8fPgeI1EC0nqXXwGYtY5l4/p+AgAGIFmA= Date: Sun, 28 Jul 2013 20:08:21 +0000 Message-ID: <916CE6CF87173740BC8A2CE4430969620481557E@008-AM1MPN1-053.mgdnok.nokia.com> References: <201307271543.13891.thp@comnets.uni-bremen.de> <51F4313B.4020707@tut.fi> In-Reply-To: <51F4313B.4020707@tut.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.163.62.237] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 28 Jul 2013 20:08:22.0395 (UTC) FILETIME=[35E384B0:01CE8BCE] X-Nokia-AV: Clean Subject: Re: [core] Call for pre-discussions on Alternative Transports X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 20:08:35 -0000 Count me in as well, Teemu -----Original Message----- From: ext Bill Silverajan [mailto:bilhanan.silverajan@tut.fi]=20 Sent: 27. hein=E4kuuta 2013 22.45 To: core@ietf.org; Savolainen Teemu (Nokia-NRC/Tampere) Subject: Re: [core] Call for pre-discussions on Alternative Transports Hi Thomas, This sounds like a good idea to me, and I'll participate. Regards, Bill On 27/7/2013 4:43 PM, Thomas P=F6tsch wrote: > Dear all > > In the core session on Thursday (13:00 -15:00), we will have a 40=20 > minute timeslot to discuss alternative transports for CoAP. As listed=20 > in the agenda, there are six drafts available on this topic: > > draft-becker-core-coap-sms-gprs-03 > draft-becker-core-transport-scenarios-00 > draft-silverajan-core-coap-alternative-transports-02 > draft-softgear-core-coapa-00 > draft-savolainen-core-coap-websockets-00 > draft-ikpark-core-shim-00 > > As already discussed with Carsten, it might be a good idea to shedule=20 > a meeting in advance to structure the 40 minutes. Therefore, I would=20 > suggest to meet with all affected authors and those who are interested=20 > in it right after the core session on Monday. > > Viele Gr=FC=DFe, > Thomas P=F6tsch > > ------------------------------------------------ > Thomas P=F6tsch, M.Sc. > Ph.D Student > > Communication Networks Group - FB 1 > University of Bremen > Otto-Hahn-Allee 1 > 28359 Bremen > Germany > > Tel.: +49 421 218 62376 > Fax: +49 421 218 62750 > E-Mail: thp@comnets.uni-bremen.de > Web: http://www.comnets.uni-bremen.de/~thp > Building: NW1 Room: N2260 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --=20 | Bilhanan Silverajan Tel: +358 (0)40 849 0757 | | Tampere University of Technology, Finland | From cabo@tzi.org Mon Jul 29 01:52:22 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1C2C21E8054 for ; Mon, 29 Jul 2013 01:52:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.599 X-Spam-Level: X-Spam-Status: No, score=-105.599 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KVauuMv1RTAm for ; Mon, 29 Jul 2013 01:52:18 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 556FA21F918F for ; Mon, 29 Jul 2013 01:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r6T8qBKS009571 for ; Mon, 29 Jul 2013 10:52:11 +0200 (CEST) Received: from dhcp-5557.meeting.ietf.org (dhcp-5557.meeting.ietf.org [130.129.85.87]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 118E8BDD; Mon, 29 Jul 2013 10:52:11 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Mon, 29 Jul 2013 10:52:10 +0200 To: "core@ietf.org WG" Message-Id: <8D154B01-5D5A-46E2-BB57-97A0BD56AF37@tzi.org> Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [core] Agenda updated and slide set uploaded X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 08:52:22 -0000 For the 13:00 meeting today, please enjoy: http://www.ietf.org/proceedings/87/agenda/agenda-87-core http://www.ietf.org/proceedings/87/slides/slides-87-core-0.pdf Presenters: please check that I didn't destroy your slides. Gr=FC=DFe, Carsten From zach@sensinode.com Mon Jul 29 02:25:32 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF9A21F9FC8 for ; Mon, 29 Jul 2013 02:25:32 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VDMNU47uxrLu for ; Mon, 29 Jul 2013 02:25:28 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 8E48421F9C59 for ; Mon, 29 Jul 2013 02:24:57 -0700 (PDT) Received: from dhcp-1722.meeting.ietf.org (dhcp-1722.meeting.ietf.org [130.129.23.34]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id r6T9OrPq031331 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 29 Jul 2013 12:24:54 +0300 X-Authenticated-User: sensinodecom From: Zach Shelby Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Mon, 29 Jul 2013 11:24:53 +0200 To: "core@ietf.org WG" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Subject: [core] Comment on draft-ietf-core-groupcomm-11 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 09:25:32 -0000 Doing a review of draft-ietf-core-groupcomm-11, I noticed something we = should probably change. The section 3.5 "Group Member Discovery" is specifying the use of blind = CoAP pinging (in practice flooding your network) in order to discover = your group membership. The rationale for this made sense earlier, as we = didn't have a mechanism to do this. However now that we have the group = membership and lookup defined in RD, and that is now a WG document, I = would suggest removing this ping mechanism and instead just referencing = the RD specification as a way to manage and lookup group membership. Thanks, Zach=20 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com @SensinodeIoT Mobile: +358 40 7796297 Twitter: @zach_shelby LinkedIn: http://fi.linkedin.com/in/zachshelby 6LoWPAN Book: http://6lowpan.net From zach@sensinode.com Mon Jul 29 02:31:16 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 224E121F9A2B for ; Mon, 29 Jul 2013 02:31:01 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BzwVw4i+dXk7 for ; Mon, 29 Jul 2013 02:30:24 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 9F9B321E804E for ; Mon, 29 Jul 2013 02:30:22 -0700 (PDT) Received: from dhcp-1722.meeting.ietf.org (dhcp-1722.meeting.ietf.org [130.129.23.34]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id r6T9U0Ne032666 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 29 Jul 2013 12:30:01 +0300 X-Authenticated-User: sensinodecom From: Zach Shelby Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <3A22A9C8-88E8-40E4-98B3-1696574859EF@sensinode.com> Date: Mon, 29 Jul 2013 11:29:59 +0200 To: "core@ietf.org WG" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Subject: [core] CBOR in Group Comm? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 09:31:17 -0000 Looking at our current multicast address configuration REST interface in = draft-ietf-core-groupcomm-11, would implementor feel more comfortable = with using CBOR instead of JSON for this interface? And now the comment = that came up this morning in Apps Area WG regarding tags for IP = addresses becomes more relevant :-)=20 Req: GET /gp Res: 2.05 Content (Content-Format: application/coap-group+json) [ { "n": "Room-A-Lights.floor1.west.bldg6.example.com", "ip": "ff15::4200:f7fe:ed37:14ca" } ]=20 Obviously the name won't get any smaller, but if the IP address would = already be in a binary form that would save space and avoid the need for = conversion in the node.=20 But we should only do this a) if it is clear CBOR is going forward = smoothly, and b) there is some real benefit from doing so. Thoughts? Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com @SensinodeIoT Mobile: +358 40 7796297 Twitter: @zach_shelby LinkedIn: http://fi.linkedin.com/in/zachshelby 6LoWPAN Book: http://6lowpan.net From teemu.savolainen@nokia.com Mon Jul 29 04:21:04 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7E2221F9AD2 for ; Mon, 29 Jul 2013 04:21:03 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7wD1SQVimZtx for ; Mon, 29 Jul 2013 04:20:58 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 286DA21F9FE5 for ; Mon, 29 Jul 2013 04:20:44 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (in-mx.nokia.com [10.160.244.22]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r6TBKeOJ018375; Mon, 29 Jul 2013 14:20:40 +0300 Received: from vaebh106.NOE.Nokia.com ([10.160.244.32]) by vaebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 29 Jul 2013 14:20:39 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.49]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 29 Jul 2013 14:20:39 +0300 Received: from 008-AM1MPN1-053.mgdnok.nokia.com ([169.254.3.140]) by 008-AM1MMR2-015.mgdnok.nokia.com ([65.54.30.49]) with mapi id 14.03.0136.001; Mon, 29 Jul 2013 11:20:38 +0000 From: To: Thread-Topic: [core] CoAP over WebSockets version -00 published Thread-Index: Ac6Bjxyhi6T8vJFtQm63K6kAMA7LqwAc7nUAApKMYdA= Date: Mon, 29 Jul 2013 11:20:38 +0000 Message-ID: <916CE6CF87173740BC8A2CE4430969620481607F@008-AM1MPN1-053.mgdnok.nokia.com> References: <916CE6CF87173740BC8A2CE443096962047E35F4@008-AM1MPN1-052.mgdnok.nokia.com> <51E50B8A.5070300@intec.ugent.be> In-Reply-To: <51E50B8A.5070300@intec.ugent.be> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.163.57.17] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 29 Jul 2013 11:20:39.0638 (UTC) FILETIME=[A7D3F760:01CE8C4D] X-Nokia-AV: Clean Cc: core@ietf.org Subject: Re: [core] CoAP over WebSockets version -00 published X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 11:21:04 -0000 PkZpbmFsbHksIG91dCBvZiBjdXJpb3NpdHkgZG8gdGhlIGktZCBhdXRob3JzIGhhdmUgYW55IHJ1 bm5pbmcgY29kZSBpbXBsZW1lbnRpbmcgdGhpcyBkcmFmdD8NCg0KV2Ugbm93IGhhdmUgYSBxdWlj ayBpbXBsZW1lbnRhdGlvbiBydW5uaW5nOiBqYXZhc2NyaXB0IGNvZGUgcnVubmluZyBpbiBhIHdl YiBicm93c2VyIHRoYXQgaXMgYWJsZSB0byBzZW5kIENvQVAgcmVxdWVzdHMgb3ZlciBXZWJTb2Nr ZXQgdG8gYSBzZXJ2ZXIsIHdoaWNoIGhhcyBub2RlLmpzIGNvZGUgYWJsZSB0byByZXBseSB3aXRo IENvQVAgcmVzcG9uc2VzIG92ZXIgV2ViU29ja2V0IDopDQoNClRlZW11DQo= From zach@sensinode.com Mon Jul 29 04:44:00 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D09121F9C40 for ; Mon, 29 Jul 2013 04:44:00 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGvPqNWDxngf for ; Mon, 29 Jul 2013 04:43:56 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 59C2421F84E3 for ; Mon, 29 Jul 2013 04:43:56 -0700 (PDT) Received: from dhcp-1722.meeting.ietf.org (dhcp-1722.meeting.ietf.org [130.129.23.34]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id r6TBhrIU001862 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 29 Jul 2013 14:43:54 +0300 X-Authenticated-User: sensinodecom Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Zach Shelby In-Reply-To: <916CE6CF87173740BC8A2CE443096962047E35F4@008-AM1MPN1-052.mgdnok.nokia.com> Date: Mon, 29 Jul 2013 13:43:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2F0CFCA5-8232-445F-BEF8-4AE8E5B062D2@sensinode.com> References: <916CE6CF87173740BC8A2CE443096962047E35F4@008-AM1MPN1-052.mgdnok.nokia.com> To: teemu.savolainen@nokia.com X-Mailer: Apple Mail (2.1503) Cc: core@ietf.org Subject: Re: [core] CoAP over WebSockets version -00 published X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 11:44:00 -0000 Teemu, Just seeing the title of this made my eyes hurt - and reading the draft, = my eyes don't hurt any less. WebSockets may turn out to be one of the = most mis-used protocols the IETF has produced lately, and this doesn't = make that any better.=20 First, I really can't figure out the use case for this. I mean, I could = figure out a use case for doing bi-directional REST between a browser = and web server using CoAP over WebSockets as otherwise the payload = inside is in practice proprietary (which was the whole point). But that = has nothing to do with constrained devices or networks, so we probably = shouldn't be solving that problem here.=20 What you really want to do here is CoAP over TCP, and we are already = doing this for limited use cases in deployments. Why do CoAP over = WebSockets over TCP, plus the associated handshake overhead? Also the = URI mapping is a messy complication. Zach=20 On Jul 15, 2013, at 9:15 PM, teemu.savolainen@nokia.com wrote: > Hi all, >=20 > We have published draft-savolainen-core-coap-websockets-00 = (http://www.ietf.org/internet-drafts/draft-savolainen-core-coap-websockets= -00.txt) that describes how to retrieve and update CoAP resources using = CoAP requests and responses over the WebSocket Protocol. >=20 > Please see the draft for details - we discuss there, for example, the = scenarios where we envision this to be useful, and technical details = required for handshaking WebSocket connection for CoAP and for actually = transporting CoAP messages within WebSocket framing. Of course not = forgetting "coap+ws" URI scheme for identifying both the WebSocket = endpoint and CoAP resource within that endpoint. >=20 > All comments welcome. >=20 > Best regards, >=20 > Teemu > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com @SensinodeIoT Mobile: +358 40 7796297 Twitter: @zach_shelby LinkedIn: http://fi.linkedin.com/in/zachshelby 6LoWPAN Book: http://6lowpan.net From rick.bullotta@thingworx.com Mon Jul 29 05:09:40 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD70B21F9E31 for ; Mon, 29 Jul 2013 05:09:39 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T0kpFW4J4DKB for ; Mon, 29 Jul 2013 05:09:33 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0207.outbound.protection.outlook.com [207.46.163.207]) by ietfa.amsl.com (Postfix) with ESMTP id 4A83521F9E02 for ; Mon, 29 Jul 2013 05:09:28 -0700 (PDT) Received: from BLUPR06MB001.namprd06.prod.outlook.com (10.242.190.139) by BLUPR06MB002.namprd06.prod.outlook.com (10.242.190.142) with Microsoft SMTP Server (TLS) id 15.0.731.16; Mon, 29 Jul 2013 12:09:18 +0000 Received: from BLUPR06MB001.namprd06.prod.outlook.com ([169.254.1.81]) by BLUPR06MB001.namprd06.prod.outlook.com ([169.254.1.98]) with mapi id 15.00.0731.000; Mon, 29 Jul 2013 12:09:18 +0000 From: Rick Bullotta To: Zach Shelby , "teemu.savolainen@nokia.com" Thread-Topic: [core] CoAP over WebSockets version -00 published Thread-Index: Ac6Bjxyhi6T8vJFtQm63K6kAMA7LqwKwckcAAABL0yA= Date: Mon, 29 Jul 2013 12:09:17 +0000 Message-ID: <3a0de816601e4434b99aa31d1d732fd3@BLUPR06MB001.namprd06.prod.outlook.com> References: <916CE6CF87173740BC8A2CE443096962047E35F4@008-AM1MPN1-052.mgdnok.nokia.com> <2F0CFCA5-8232-445F-BEF8-4AE8E5B062D2@sensinode.com> In-Reply-To: <2F0CFCA5-8232-445F-BEF8-4AE8E5B062D2@sensinode.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.59.9.6] x-forefront-prvs: 09222B39F5 x-forefront-antispam-report: SFV:NSPM; SFS:(377454003)(13464003)(53754006)(24454002)(51704005)(199002)(189002)(74662001)(83322001)(47446002)(74502001)(63696002)(80022001)(66066001)(19580395003)(74706001)(31966008)(74366001)(56776001)(49866001)(79102001)(19580405001)(19580385001)(65816001)(80976001)(77982001)(59766001)(81542001)(47976001)(50986001)(15202345003)(16406001)(76576001)(76786001)(69226001)(4396001)(33646001)(74876001)(51856001)(81342001)(54356001)(53806001)(16601075003)(76796001)(83072001)(74316001)(77096001)(76482001)(46102001)(56816003)(47736001)(54316002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR06MB002; H:BLUPR06MB001.namprd06.prod.outlook.com; CLIP:173.59.9.6; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: thingworx.com Cc: "core@ietf.org" Subject: Re: [core] CoAP over WebSockets version -00 published X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 12:09:40 -0000 Aren't people/browsers/HTTP consumers part of the "internet of things"? On= e primary reason why this is valuable =3D it enables the protocol to be con= sumable from a browser, allowing low-latency notifications/events to be pus= hed to the consumer with minimal routing, firewall or proxy issues. The sa= me transport could also be used for a binary or textual encoding of a proto= col (which makes debugging significantly easier if implemented properly). = Traditional REST over HTTP doesn't work for this. HTTP callbacks and long = polling are messy hacks. For that matter, I'd love to see a standardized J= SON (or other human readable) representation of the COAP protocol. Not eve= ry user wants to be hacking hex codes and bits debugging M2M/IoT apps. Als= o, once the WS upgrade is negotiated (which is of course once per connectio= n, which are generally long-lived), the framing overhead is very minimal. Any protocol's ultimate applicability (and adoption) needs to consider more= than just the technical merits. It needs to consider the consumers and us= ers and the breadth and variety of possible applications. To me, it would = seem that a higher level binding (e.g. WS/JSON) that automatically maps/rou= tes to a lower level binding (TCP/COAP binary) would make a lot of sense. = Along with a really high level binding via an HTTP REST API. That would em= power a broad audience of providers and consumers to leverage it. -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Zac= h Shelby Sent: Monday, July 29, 2013 7:44 AM To: teemu.savolainen@nokia.com Cc: core@ietf.org Subject: Re: [core] CoAP over WebSockets version -00 published Teemu, Just seeing the title of this made my eyes hurt - and reading the draft, my= eyes don't hurt any less. WebSockets may turn out to be one of the most mi= s-used protocols the IETF has produced lately, and this doesn't make that a= ny better.=20 First, I really can't figure out the use case for this. I mean, I could fig= ure out a use case for doing bi-directional REST between a browser and web = server using CoAP over WebSockets as otherwise the payload inside is in pra= ctice proprietary (which was the whole point). But that has nothing to do w= ith constrained devices or networks, so we probably shouldn't be solving th= at problem here.=20 What you really want to do here is CoAP over TCP, and we are already doing = this for limited use cases in deployments. Why do CoAP over WebSockets over= TCP, plus the associated handshake overhead? Also the URI mapping is a mes= sy complication. Zach=20 On Jul 15, 2013, at 9:15 PM, teemu.savolainen@nokia.com wrote: > Hi all, >=20 > We have published draft-savolainen-core-coap-websockets-00 (http://www.ie= tf.org/internet-drafts/draft-savolainen-core-coap-websockets-00.txt) that d= escribes how to retrieve and update CoAP resources using CoAP requests and = responses over the WebSocket Protocol. >=20 > Please see the draft for details - we discuss there, for example, the sce= narios where we envision this to be useful, and technical details required = for handshaking WebSocket connection for CoAP and for actually transporting= CoAP messages within WebSocket framing. Of course not forgetting "coap+ws"= URI scheme for identifying both the WebSocket endpoint and CoAP resource w= ithin that endpoint. >=20 > All comments welcome. >=20 > Best regards, >=20 > Teemu > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com @SensinodeIoT Mobile: +358 40 7796297 Twitter: @zach_shelby LinkedIn: http://fi.linkedin.com/in/zachshelby 6LoWPAN Book: http://6lowpan.net _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From zach@sensinode.com Mon Jul 29 05:27:43 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3A3D21F9C0A for ; Mon, 29 Jul 2013 05:27:42 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqrLesATtqkS for ; Mon, 29 Jul 2013 05:27:35 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 68E6221F9E1E for ; Mon, 29 Jul 2013 05:27:06 -0700 (PDT) Received: from dhcp-1722.meeting.ietf.org (dhcp-1722.meeting.ietf.org [130.129.23.34]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id r6TCQri4012523 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 29 Jul 2013 15:26:55 +0300 X-Authenticated-User: sensinodecom Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Zach Shelby In-Reply-To: <3a0de816601e4434b99aa31d1d732fd3@BLUPR06MB001.namprd06.prod.outlook.com> Date: Mon, 29 Jul 2013 14:26:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8292F6E1-791C-4AC5-81C2-3ACF2E1366B0@sensinode.com> References: <916CE6CF87173740BC8A2CE443096962047E35F4@008-AM1MPN1-052.mgdnok.nokia.com> <2F0CFCA5-8232-445F-BEF8-4AE8E5B062D2@sensinode.com> <3a0de816601e4434b99aa31d1d732fd3@BLUPR06MB001.namprd06.prod.outlook.com> To: Rick Bullotta X-Mailer: Apple Mail (2.1503) Cc: "core@ietf.org" Subject: Re: [core] CoAP over WebSockets version -00 published X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 12:27:43 -0000 Rick, Now when we talk about a high-level WS/JSON binding for web server/proxy = to browser communication, that starts to make more sense. But again, = that really isn't in the scope of constrained device communication, that = is a browser/UI issue. That also does not require CoAP over WS, it = requires a mapping from CoAP over TCP to WebSockets running something = appropriate (e.g. JSON) for the application.=20 Zach On Jul 29, 2013, at 2:09 PM, Rick Bullotta = wrote: > Aren't people/browsers/HTTP consumers part of the "internet of = things"? One primary reason why this is valuable =3D it enables the = protocol to be consumable from a browser, allowing low-latency = notifications/events to be pushed to the consumer with minimal routing, = firewall or proxy issues. The same transport could also be used for a = binary or textual encoding of a protocol (which makes debugging = significantly easier if implemented properly). Traditional REST over = HTTP doesn't work for this. HTTP callbacks and long polling are messy = hacks. For that matter, I'd love to see a standardized JSON (or other = human readable) representation of the COAP protocol. Not every user = wants to be hacking hex codes and bits debugging M2M/IoT apps. Also, = once the WS upgrade is negotiated (which is of course once per = connection, which are generally long-lived), the framing overhead is = very minimal. >=20 > Any protocol's ultimate applicability (and adoption) needs to consider = more than just the technical merits. It needs to consider the consumers = and users and the breadth and variety of possible applications. To me, = it would seem that a higher level binding (e.g. WS/JSON) that = automatically maps/routes to a lower level binding (TCP/COAP binary) = would make a lot of sense. Along with a really high level binding via = an HTTP REST API. That would empower a broad audience of providers and = consumers to leverage it. >=20 > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf = Of Zach Shelby > Sent: Monday, July 29, 2013 7:44 AM > To: teemu.savolainen@nokia.com > Cc: core@ietf.org > Subject: Re: [core] CoAP over WebSockets version -00 published >=20 > Teemu, >=20 > Just seeing the title of this made my eyes hurt - and reading the = draft, my eyes don't hurt any less. WebSockets may turn out to be one of = the most mis-used protocols the IETF has produced lately, and this = doesn't make that any better.=20 >=20 > First, I really can't figure out the use case for this. I mean, I = could figure out a use case for doing bi-directional REST between a = browser and web server using CoAP over WebSockets as otherwise the = payload inside is in practice proprietary (which was the whole point). = But that has nothing to do with constrained devices or networks, so we = probably shouldn't be solving that problem here.=20 >=20 > What you really want to do here is CoAP over TCP, and we are already = doing this for limited use cases in deployments. Why do CoAP over = WebSockets over TCP, plus the associated handshake overhead? Also the = URI mapping is a messy complication. >=20 > Zach=20 >=20 > On Jul 15, 2013, at 9:15 PM, teemu.savolainen@nokia.com wrote: >=20 >> Hi all, >>=20 >> We have published draft-savolainen-core-coap-websockets-00 = (http://www.ietf.org/internet-drafts/draft-savolainen-core-coap-websockets= -00.txt) that describes how to retrieve and update CoAP resources using = CoAP requests and responses over the WebSocket Protocol. >>=20 >> Please see the draft for details - we discuss there, for example, the = scenarios where we envision this to be useful, and technical details = required for handshaking WebSocket connection for CoAP and for actually = transporting CoAP messages within WebSocket framing. Of course not = forgetting "coap+ws" URI scheme for identifying both the WebSocket = endpoint and CoAP resource within that endpoint. >>=20 >> All comments welcome. >>=20 >> Best regards, >>=20 >> Teemu >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >=20 > --=20 > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://www.sensinode.com @SensinodeIoT > Mobile: +358 40 7796297 > Twitter: @zach_shelby > LinkedIn: http://fi.linkedin.com/in/zachshelby > 6LoWPAN Book: http://6lowpan.net >=20 >=20 >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com @SensinodeIoT Mobile: +358 40 7796297 Twitter: @zach_shelby LinkedIn: http://fi.linkedin.com/in/zachshelby 6LoWPAN Book: http://6lowpan.net From likepeng@huawei.com Mon Jul 29 05:32:40 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 980B121F9EDF for ; Mon, 29 Jul 2013 05:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.396 X-Spam-Level: X-Spam-Status: No, score=-2.396 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQNoy1eZfY7f for ; Mon, 29 Jul 2013 05:32:30 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id AFAC621F9E15 for ; Mon, 29 Jul 2013 05:32:03 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVN41330; Mon, 29 Jul 2013 12:31:56 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 29 Jul 2013 13:31:45 +0100 Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 29 Jul 2013 13:31:34 +0100 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.111]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.01.0323.007; Mon, 29 Jul 2013 20:31:25 +0800 From: Likepeng To: Zach Shelby , Rick Bullotta Thread-Topic: [core] CoAP over WebSockets version -00 published Thread-Index: AQHOjFDli6T8vJFtQm63K6kAMA7Lq5l7CieAgAAE6gCAAIcZ2A== Date: Mon, 29 Jul 2013 12:31:22 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F2442B1ADA@szxeml525-mbs.china.huawei.com> References: <916CE6CF87173740BC8A2CE443096962047E35F4@008-AM1MPN1-052.mgdnok.nokia.com> <2F0CFCA5-8232-445F-BEF8-4AE8E5B062D2@sensinode.com> <3a0de816601e4434b99aa31d1d732fd3@BLUPR06MB001.namprd06.prod.outlook.com>, <8292F6E1-791C-4AC5-81C2-3ACF2E1366B0@sensinode.com> In-Reply-To: <8292F6E1-791C-4AC5-81C2-3ACF2E1366B0@sensinode.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.141.102] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "core@ietf.org" Subject: Re: [core] CoAP over WebSockets version -00 published X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 12:32:41 -0000 PlRoYXQgYWxzbyBkb2VzIG5vdCByZXF1aXJlIENvQVAgb3ZlciBXUy4NCg0KKzEuIENvQVAgb3Zl ciBXUyBpcyBub3Qgc3VpdGFibGUgZm9yIGNvbnN0YWluZWQgZGV2aWNlcy4NCg0KS2VwZW5nDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IGNvcmUtYm91 bmNlc0BpZXRmLm9yZyBbY29yZS1ib3VuY2VzQGlldGYub3JnXSC0+rHtIFphY2ggU2hlbGJ5IFt6 YWNoQHNlbnNpbm9kZS5jb21dDQq3osvNyrG85DogMjAxM8TqN9TCMjnI1SAyMDoyNg0Ktb06IFJp Y2sgQnVsbG90dGENCkNjOiBjb3JlQGlldGYub3JnDQrW98ziOiBSZTogW2NvcmVdIENvQVAgb3Zl ciBXZWJTb2NrZXRzIHZlcnNpb24gLTAwIHB1Ymxpc2hlZA0KDQpSaWNrLA0KDQpOb3cgd2hlbiB3 ZSB0YWxrIGFib3V0IGEgaGlnaC1sZXZlbCBXUy9KU09OIGJpbmRpbmcgZm9yIHdlYiBzZXJ2ZXIv cHJveHkgdG8gYnJvd3NlciBjb21tdW5pY2F0aW9uLCB0aGF0IHN0YXJ0cyB0byBtYWtlIG1vcmUg c2Vuc2UuIEJ1dCBhZ2FpbiwgdGhhdCByZWFsbHkgaXNuJ3QgaW4gdGhlIHNjb3BlIG9mIGNvbnN0 cmFpbmVkIGRldmljZSBjb21tdW5pY2F0aW9uLCB0aGF0IGlzIGEgYnJvd3Nlci9VSSBpc3N1ZS4g VGhhdCBhbHNvIGRvZXMgbm90IHJlcXVpcmUgQ29BUCBvdmVyIFdTLCBpdCByZXF1aXJlcyBhIG1h cHBpbmcgZnJvbSBDb0FQIG92ZXIgVENQIHRvIFdlYlNvY2tldHMgcnVubmluZyBzb21ldGhpbmcg YXBwcm9wcmlhdGUgKGUuZy4gSlNPTikgZm9yIHRoZSBhcHBsaWNhdGlvbi4NCg0KWmFjaA0KDQpP biBKdWwgMjksIDIwMTMsIGF0IDI6MDkgUE0sIFJpY2sgQnVsbG90dGEgPHJpY2suYnVsbG90dGFA dGhpbmd3b3J4LmNvbT4gd3JvdGU6DQoNCj4gQXJlbid0IHBlb3BsZS9icm93c2Vycy9IVFRQIGNv bnN1bWVycyBwYXJ0IG9mIHRoZSAiaW50ZXJuZXQgb2YgdGhpbmdzIj8gIE9uZSBwcmltYXJ5IHJl YXNvbiB3aHkgdGhpcyBpcyB2YWx1YWJsZSA9IGl0IGVuYWJsZXMgdGhlIHByb3RvY29sIHRvIGJl IGNvbnN1bWFibGUgZnJvbSBhIGJyb3dzZXIsIGFsbG93aW5nIGxvdy1sYXRlbmN5IG5vdGlmaWNh dGlvbnMvZXZlbnRzIHRvIGJlIHB1c2hlZCB0byB0aGUgY29uc3VtZXIgd2l0aCBtaW5pbWFsIHJv dXRpbmcsIGZpcmV3YWxsIG9yIHByb3h5IGlzc3Vlcy4gIFRoZSBzYW1lIHRyYW5zcG9ydCBjb3Vs ZCBhbHNvIGJlIHVzZWQgZm9yIGEgYmluYXJ5IG9yIHRleHR1YWwgZW5jb2Rpbmcgb2YgYSBwcm90 b2NvbCAod2hpY2ggbWFrZXMgZGVidWdnaW5nIHNpZ25pZmljYW50bHkgZWFzaWVyIGlmIGltcGxl bWVudGVkIHByb3Blcmx5KS4gIFRyYWRpdGlvbmFsIFJFU1Qgb3ZlciBIVFRQIGRvZXNuJ3Qgd29y ayBmb3IgdGhpcy4gIEhUVFAgY2FsbGJhY2tzIGFuZCBsb25nIHBvbGxpbmcgYXJlIG1lc3N5IGhh Y2tzLiAgRm9yIHRoYXQgbWF0dGVyLCBJJ2QgbG92ZSB0byBzZWUgYSBzdGFuZGFyZGl6ZWQgSlNP TiAob3Igb3RoZXIgaHVtYW4gcmVhZGFibGUpIHJlcHJlc2VudGF0aW9uIG9mIHRoZSBDT0FQIHBy b3RvY29sLiAgTm90IGV2ZXJ5IHVzZXIgd2FudHMgdG8gYmUgaGFja2luZyBoZXggY29kZXMgYW5k IGJpdHMgZGVidWdnaW5nIE0yTS9Jb1QgYXBwcy4gIEFsc28sIG9uY2UgdGhlIFdTIHVwZ3JhZGUg aXMgbmVnb3RpYXRlZCAod2hpY2ggaXMgb2YgY291cnNlIG9uY2UgcGVyIGNvbm5lY3Rpb24sIHdo aWNoIGFyZSBnZW5lcmFsbHkgbG9uZy1saXZlZCksIHRoZSBmcmFtaW5nIG92ZXJoZWFkIGlzIHZl cnkgbWluaW1hbC4NCj4NCj4gQW55IHByb3RvY29sJ3MgdWx0aW1hdGUgYXBwbGljYWJpbGl0eSAo YW5kIGFkb3B0aW9uKSBuZWVkcyB0byBjb25zaWRlciBtb3JlIHRoYW4ganVzdCB0aGUgdGVjaG5p Y2FsIG1lcml0cy4gIEl0IG5lZWRzIHRvIGNvbnNpZGVyIHRoZSBjb25zdW1lcnMgYW5kIHVzZXJz IGFuZCB0aGUgYnJlYWR0aCBhbmQgdmFyaWV0eSBvZiBwb3NzaWJsZSBhcHBsaWNhdGlvbnMuICBU byBtZSwgaXQgd291bGQgc2VlbSB0aGF0IGEgaGlnaGVyIGxldmVsIGJpbmRpbmcgKGUuZy4gV1Mv SlNPTikgdGhhdCBhdXRvbWF0aWNhbGx5IG1hcHMvcm91dGVzIHRvIGEgbG93ZXIgbGV2ZWwgYmlu ZGluZyAoVENQL0NPQVAgYmluYXJ5KSB3b3VsZCBtYWtlIGEgbG90IG9mIHNlbnNlLiAgQWxvbmcg d2l0aCBhIHJlYWxseSBoaWdoIGxldmVsIGJpbmRpbmcgdmlhIGFuIEhUVFAgUkVTVCBBUEkuICBU aGF0IHdvdWxkIGVtcG93ZXIgYSBicm9hZCBhdWRpZW5jZSBvZiBwcm92aWRlcnMgYW5kIGNvbnN1 bWVycyB0byBsZXZlcmFnZSBpdC4NCj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g RnJvbTogY29yZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Y29yZS1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgWmFjaCBTaGVsYnkNCj4gU2VudDogTW9uZGF5LCBKdWx5IDI5LCAyMDEz IDc6NDQgQU0NCj4gVG86IHRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tDQo+IENjOiBjb3JlQGll dGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbY29yZV0gQ29BUCBvdmVyIFdlYlNvY2tldHMgdmVyc2lv biAtMDAgcHVibGlzaGVkDQo+DQo+IFRlZW11LA0KPg0KPiBKdXN0IHNlZWluZyB0aGUgdGl0bGUg b2YgdGhpcyBtYWRlIG15IGV5ZXMgaHVydCAtIGFuZCByZWFkaW5nIHRoZSBkcmFmdCwgbXkgZXll cyBkb24ndCBodXJ0IGFueSBsZXNzLiBXZWJTb2NrZXRzIG1heSB0dXJuIG91dCB0byBiZSBvbmUg b2YgdGhlIG1vc3QgbWlzLXVzZWQgcHJvdG9jb2xzIHRoZSBJRVRGIGhhcyBwcm9kdWNlZCBsYXRl bHksIGFuZCB0aGlzIGRvZXNuJ3QgbWFrZSB0aGF0IGFueSBiZXR0ZXIuDQo+DQo+IEZpcnN0LCBJ IHJlYWxseSBjYW4ndCBmaWd1cmUgb3V0IHRoZSB1c2UgY2FzZSBmb3IgdGhpcy4gSSBtZWFuLCBJ IGNvdWxkIGZpZ3VyZSBvdXQgYSB1c2UgY2FzZSBmb3IgZG9pbmcgYmktZGlyZWN0aW9uYWwgUkVT VCBiZXR3ZWVuIGEgYnJvd3NlciBhbmQgd2ViIHNlcnZlciB1c2luZyBDb0FQIG92ZXIgV2ViU29j a2V0cyBhcyBvdGhlcndpc2UgdGhlIHBheWxvYWQgaW5zaWRlIGlzIGluIHByYWN0aWNlIHByb3By aWV0YXJ5ICh3aGljaCB3YXMgdGhlIHdob2xlIHBvaW50KS4gQnV0IHRoYXQgaGFzIG5vdGhpbmcg dG8gZG8gd2l0aCBjb25zdHJhaW5lZCBkZXZpY2VzIG9yIG5ldHdvcmtzLCBzbyB3ZSBwcm9iYWJs eSBzaG91bGRuJ3QgYmUgc29sdmluZyB0aGF0IHByb2JsZW0gaGVyZS4NCj4NCj4gV2hhdCB5b3Ug cmVhbGx5IHdhbnQgdG8gZG8gaGVyZSBpcyBDb0FQIG92ZXIgVENQLCBhbmQgd2UgYXJlIGFscmVh ZHkgZG9pbmcgdGhpcyBmb3IgbGltaXRlZCB1c2UgY2FzZXMgaW4gZGVwbG95bWVudHMuIFdoeSBk byBDb0FQIG92ZXIgV2ViU29ja2V0cyBvdmVyIFRDUCwgcGx1cyB0aGUgYXNzb2NpYXRlZCBoYW5k c2hha2Ugb3ZlcmhlYWQ/IEFsc28gdGhlIFVSSSBtYXBwaW5nIGlzIGEgbWVzc3kgY29tcGxpY2F0 aW9uLg0KPg0KPiBaYWNoDQo+DQo+IE9uIEp1bCAxNSwgMjAxMywgYXQgOToxNSBQTSwgdGVlbXUu c2F2b2xhaW5lbkBub2tpYS5jb20gd3JvdGU6DQo+DQo+PiBIaSBhbGwsDQo+Pg0KPj4gV2UgaGF2 ZSBwdWJsaXNoZWQgZHJhZnQtc2F2b2xhaW5lbi1jb3JlLWNvYXAtd2Vic29ja2V0cy0wMCAoaHR0 cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtc2F2b2xhaW5lbi1jb3JlLWNv YXAtd2Vic29ja2V0cy0wMC50eHQpIHRoYXQgZGVzY3JpYmVzIGhvdyB0byByZXRyaWV2ZSBhbmQg dXBkYXRlIENvQVAgcmVzb3VyY2VzIHVzaW5nIENvQVAgcmVxdWVzdHMgYW5kIHJlc3BvbnNlcyBv dmVyIHRoZSBXZWJTb2NrZXQgUHJvdG9jb2wuDQo+Pg0KPj4gUGxlYXNlIHNlZSB0aGUgZHJhZnQg Zm9yIGRldGFpbHMgLSB3ZSBkaXNjdXNzIHRoZXJlLCBmb3IgZXhhbXBsZSwgdGhlIHNjZW5hcmlv cyB3aGVyZSB3ZSBlbnZpc2lvbiB0aGlzIHRvIGJlIHVzZWZ1bCwgYW5kIHRlY2huaWNhbCBkZXRh aWxzIHJlcXVpcmVkIGZvciBoYW5kc2hha2luZyBXZWJTb2NrZXQgY29ubmVjdGlvbiBmb3IgQ29B UCBhbmQgZm9yIGFjdHVhbGx5IHRyYW5zcG9ydGluZyBDb0FQIG1lc3NhZ2VzIHdpdGhpbiBXZWJT b2NrZXQgZnJhbWluZy4gT2YgY291cnNlIG5vdCBmb3JnZXR0aW5nICJjb2FwK3dzIiBVUkkgc2No ZW1lIGZvciBpZGVudGlmeWluZyBib3RoIHRoZSBXZWJTb2NrZXQgZW5kcG9pbnQgYW5kIENvQVAg cmVzb3VyY2Ugd2l0aGluIHRoYXQgZW5kcG9pbnQuDQo+Pg0KPj4gQWxsIGNvbW1lbnRzIHdlbGNv bWUuDQo+Pg0KPj4gQmVzdCByZWdhcmRzLA0KPj4NCj4+ICAgICAgVGVlbXUNCj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBjb3JlIG1haWxpbmcg bGlzdA0KPj4gY29yZUBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9jb3JlDQo+DQo+IC0tDQo+IFphY2ggU2hlbGJ5LCBDaGllZiBOZXJkLCBTZW5zaW5v ZGUgTHRkLg0KPiBodHRwOi8vd3d3LnNlbnNpbm9kZS5jb20gQFNlbnNpbm9kZUlvVA0KPiBNb2Jp bGU6ICszNTggNDAgNzc5NjI5Nw0KPiBUd2l0dGVyOiBAemFjaF9zaGVsYnkNCj4gTGlua2VkSW46 IGh0dHA6Ly9maS5saW5rZWRpbi5jb20vaW4vemFjaHNoZWxieQ0KPiA2TG9XUEFOIEJvb2s6IGh0 dHA6Ly82bG93cGFuLm5ldA0KPg0KPg0KPg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiBjb3JlIG1haWxpbmcgbGlzdA0KPiBjb3JlQGlldGYu b3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZQ0KDQotLQ0K WmFjaCBTaGVsYnksIENoaWVmIE5lcmQsIFNlbnNpbm9kZSBMdGQuDQpodHRwOi8vd3d3LnNlbnNp bm9kZS5jb20gQFNlbnNpbm9kZUlvVA0KTW9iaWxlOiArMzU4IDQwIDc3OTYyOTcNClR3aXR0ZXI6 IEB6YWNoX3NoZWxieQ0KTGlua2VkSW46IGh0dHA6Ly9maS5saW5rZWRpbi5jb20vaW4vemFjaHNo ZWxieQ0KNkxvV1BBTiBCb29rOiBodHRwOi8vNmxvd3Bhbi5uZXQNCg0KDQoNCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmNvcmUgbWFpbGluZyBsaXN0 DQpjb3JlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nv cmU= From zehn.cao@gmail.com Mon Jul 29 05:57:44 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0758221F9D56 for ; Mon, 29 Jul 2013 05:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.146 X-Spam-Level: X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[AWL=0.454, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-Q66TZTcqlC for ; Mon, 29 Jul 2013 05:57:43 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 3E59821F9D52 for ; Mon, 29 Jul 2013 05:57:42 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id j13so4771358wgh.2 for ; Mon, 29 Jul 2013 05:57:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=MG5lY5qEwM375d4tM2uTIaoSZ0evBJVEMDMipUhcsqc=; b=OlAK3wn/bh0yf4Gnz1FX2VUY3yUCBBl03OcvlwD8XeZaIXVUWBW/5Tgf94g3i7c6GE VfOUsUb6KeBTiMQ7CVUQo81F1ovnyJQe/1lrmCzSfdHVtb0lI38hT7Yhl3Aw/cnik2j+ 8OZ6x+o1/EMTZc2ZLO7YUuPn7kXnkERPfC8s7NU8iQ8FXmiy5hJVSdePVeJ/jeVIE59v 6w9IB2EY2GMT8r+eFfLw5zN/9FYnHE9BuI/L/HtgchcHXlIOdWatEJb+AySeid1DQ3wQ FKH3qPDyMKcUv7wGGFyfhQ/FjZmVsEecTLfEVj0l8N/ZiIZzkzi6KFXnQFalhGJiOuvr Cilw== MIME-Version: 1.0 X-Received: by 10.180.20.228 with SMTP id q4mr7072564wie.60.1375102661376; Mon, 29 Jul 2013 05:57:41 -0700 (PDT) Received: by 10.216.90.135 with HTTP; Mon, 29 Jul 2013 05:57:41 -0700 (PDT) Date: Mon, 29 Jul 2013 14:57:41 +0200 Message-ID: From: "Cao,Zhen" To: core@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [core] Question to draft-gerdes-core-dcaf-authorize-00 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 12:57:44 -0000 Hello Authors, Thanks for the awesome draft. I notice the tickets and AS usage in the draft, which recall me about the Kerberos work in IETF. Are they relevant? Thanks, -z From gerdes@tzi.de Mon Jul 29 11:28:43 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40BB621F9AA1 for ; Mon, 29 Jul 2013 11:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.649 X-Spam-Level: X-Spam-Status: No, score=-5.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z6wSXi8B7-mb for ; Mon, 29 Jul 2013 11:28:34 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 1288D21F9A37 for ; Mon, 29 Jul 2013 11:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r6TISVLl008378; Mon, 29 Jul 2013 20:28:31 +0200 (CEST) Received: from [10.122.157.145] (unknown [217.9.101.140]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 56068FDB; Mon, 29 Jul 2013 20:28:31 +0200 (CEST) Message-ID: <51F6B448.5070905@tzi.de> Date: Mon, 29 Jul 2013 20:28:24 +0200 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: zehn.cao@gmail.com References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: core@ietf.org Subject: Re: [core] Question to draft-gerdes-core-dcaf-authorize-00 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 18:28:43 -0000 Hallo Zhen, On 07/29/2013 02:57 PM, Cao,Zhen wrote: > I notice the tickets and AS usage in the draft, which recall me about > the Kerberos work in IETF. Are they relevant? We actually had Kerberos in mind when we started thinking about using access tickets in DCAF. Our requirements are a bit different however, because most of our messages are transmitted using DTLS which provides us with some security features, e.g. replay attack prevention. Additionally, we want to allow for various revocation mechanisms and for that reason have a lifetime in our ticket face which is optional. I'm not quite sure if there is still so much similarity to Kerberos or if it would rather be confusing if we mention it in our draft. Best regards, Steffi From hartke@tzi.org Tue Jul 30 00:19:36 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 940DA21F99E1 for ; Tue, 30 Jul 2013 00:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fMrej+AJAQCg for ; Tue, 30 Jul 2013 00:19:30 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 29DB321F9AD2 for ; Tue, 30 Jul 2013 00:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r6U7JME1015479 for ; Tue, 30 Jul 2013 09:19:22 +0200 (CEST) Received: from mail-vc0-f177.google.com (mail-vc0-f177.google.com [209.85.220.177]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 0396E9E for ; Tue, 30 Jul 2013 09:19:21 +0200 (CEST) Received: by mail-vc0-f177.google.com with SMTP id gf12so2761500vcb.22 for ; Tue, 30 Jul 2013 00:19:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=um+lxDckdgjraRu/GkvSswR4xJkKpcMjM3OGxOcu96g=; b=TgOJ5Tg6Kes+pDQe8YOPwHqqfJprwf8Ru5DbMyxOa7QmhCgTt783x7WjUhFK9rte68 1puW6zpwPcV+rROL1sCo8w0oCuN0/ymfl5ZHQbaMLFa1PqxjZOTQ89YEVTgOJkWFAQ01 e9+FYwU+/tiC3E/DrOdkbpFC9ZzmSs1A20+g/6dmr6gV5f/fFJXgBi6hLEuOVym1u+2W xwnw+2MwkOSFEbxAtJ7Yg1EliLzuS33rLEkDXn1eMbnwnP2xHqXlnhEJnGQR+zrM8kmP p4lcvPsuF5VyJVut5F3RAPlPu+hnTXphFxgMuLF/w1tZ6LwOlvIvcG5bRbNiCxijECbP dNyg== MIME-Version: 1.0 X-Received: by 10.58.200.73 with SMTP id jq9mr26982127vec.53.1375168760888; Tue, 30 Jul 2013 00:19:20 -0700 (PDT) Received: by 10.52.76.163 with HTTP; Tue, 30 Jul 2013 00:19:20 -0700 (PDT) Date: Tue, 30 Jul 2013 09:19:20 +0200 Message-ID: From: Klaus Hartke To: "core@ietf.org WG" Content-Type: multipart/alternative; boundary=047d7bd6b9007fc3f904e2b56d6d Subject: [core] -observe at ietf87 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 07:19:36 -0000 --047d7bd6b9007fc3f904e2b56d6d Content-Type: text/plain; charset=ISO-8859-1 If you're interested in discussing draft-ietf-core-observe, there's a small meeting at the terminal room (Koepenick 1/2) starting in a few minutes. Klaus --047d7bd6b9007fc3f904e2b56d6d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If you're interested in discussing draft-ietf-core-observe, there's= =A0a small meeting=A0at=A0the terminal room (Koepenick 1/2) starting in a f= ew minutes.

Klaus
--047d7bd6b9007fc3f904e2b56d6d-- From teemu.savolainen@nokia.com Tue Jul 30 01:08:09 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D888E21E80CC for ; Tue, 30 Jul 2013 01:08:08 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xv2RWeECRneU for ; Tue, 30 Jul 2013 01:08:04 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id E613D21E80BD for ; Tue, 30 Jul 2013 01:07:58 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (in-mx.nokia.com [10.160.244.23]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r6U87pNN028211; Tue, 30 Jul 2013 11:07:54 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.25]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 30 Jul 2013 11:07:52 +0300 Received: from 008-AM1MPN1-053.mgdnok.nokia.com ([169.254.3.140]) by 008-AM1MMR1-009.mgdnok.nokia.com ([65.54.30.25]) with mapi id 14.03.0136.001; Tue, 30 Jul 2013 08:07:51 +0000 From: To: , Thread-Topic: [core] CoAP over WebSockets version -00 published Thread-Index: Ac6Bjxyhi6T8vJFtQm63K6kAMA7LqwKx+9rRACieq/A= Date: Tue, 30 Jul 2013 08:07:51 +0000 Message-ID: <916CE6CF87173740BC8A2CE44309696204816D9A@008-AM1MPN1-053.mgdnok.nokia.com> References: <916CE6CF87173740BC8A2CE443096962047E35F4@008-AM1MPN1-052.mgdnok.nokia.com> <2F0CFCA5-8232-445F-BEF8-4AE8E5B062D2@sensinode.com> <3a0de816601e4434b99aa31d1d732fd3@BLUPR06MB001.namprd06.prod.outlook.com> <8292F6E1-791C-4AC5-81C2-3ACF2E1366B0@sensinode.com> In-Reply-To: <8292F6E1-791C-4AC5-81C2-3ACF2E1366B0@sensinode.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.163.62.38] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 30 Jul 2013 08:07:52.0127 (UTC) FILETIME=[E3779CF0:01CE8CFB] X-Nokia-AV: Clean Cc: core@ietf.org Subject: Re: [core] CoAP over WebSockets version -00 published X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 08:08:10 -0000 Zach, Rick, We have also thought about JSON representation of CoAP messages as a possib= ility for browser/web server (that is acting as CoAP proxy) communications,= but not written down anything on the topic at least yet.=20 Did I understood you Zach right yesterday in that we should clarify in the = draft that the intended use-case is a distributed CoAP application running = in both web browser and web server. And this application is preferring CoAP= communication all the way rather than going through HTTP/CoAP translation = (e.g. to allow new CoAP options with minimal to no changes to proxy).=20 Best regards, Teemu -----Original Message----- From: ext Zach Shelby [mailto:zach@sensinode.com]=20 Sent: 29. hein=E4kuuta 2013 14.27 To: Rick Bullotta Cc: Savolainen Teemu (Nokia-NRC/Tampere); core@ietf.org Subject: Re: [core] CoAP over WebSockets version -00 published Rick, Now when we talk about a high-level WS/JSON binding for web server/proxy to= browser communication, that starts to make more sense. But again, that rea= lly isn't in the scope of constrained device communication, that is a brows= er/UI issue. That also does not require CoAP over WS, it requires a mapping= from CoAP over TCP to WebSockets running something appropriate (e.g. JSON)= for the application.=20 Zach On Jul 29, 2013, at 2:09 PM, Rick Bullotta wr= ote: > Aren't people/browsers/HTTP consumers part of the "internet of things"? = One primary reason why this is valuable =3D it enables the protocol to be c= onsumable from a browser, allowing low-latency notifications/events to be p= ushed to the consumer with minimal routing, firewall or proxy issues. The = same transport could also be used for a binary or textual encoding of a pro= tocol (which makes debugging significantly easier if implemented properly).= Traditional REST over HTTP doesn't work for this. HTTP callbacks and lon= g polling are messy hacks. For that matter, I'd love to see a standardized= JSON (or other human readable) representation of the COAP protocol. Not e= very user wants to be hacking hex codes and bits debugging M2M/IoT apps. A= lso, once the WS upgrade is negotiated (which is of course once per connect= ion, which are generally long-lived), the framing overhead is very minimal. >=20 > Any protocol's ultimate applicability (and adoption) needs to consider mo= re than just the technical merits. It needs to consider the consumers and = users and the breadth and variety of possible applications. To me, it woul= d seem that a higher level binding (e.g. WS/JSON) that automatically maps/r= outes to a lower level binding (TCP/COAP binary) would make a lot of sense.= Along with a really high level binding via an HTTP REST API. That would = empower a broad audience of providers and consumers to leverage it. >=20 > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Z= ach Shelby > Sent: Monday, July 29, 2013 7:44 AM > To: teemu.savolainen@nokia.com > Cc: core@ietf.org > Subject: Re: [core] CoAP over WebSockets version -00 published >=20 > Teemu, >=20 > Just seeing the title of this made my eyes hurt - and reading the draft, = my eyes don't hurt any less. WebSockets may turn out to be one of the most = mis-used protocols the IETF has produced lately, and this doesn't make that= any better.=20 >=20 > First, I really can't figure out the use case for this. I mean, I could f= igure out a use case for doing bi-directional REST between a browser and we= b server using CoAP over WebSockets as otherwise the payload inside is in p= ractice proprietary (which was the whole point). But that has nothing to do= with constrained devices or networks, so we probably shouldn't be solving = that problem here.=20 >=20 > What you really want to do here is CoAP over TCP, and we are already doin= g this for limited use cases in deployments. Why do CoAP over WebSockets ov= er TCP, plus the associated handshake overhead? Also the URI mapping is a m= essy complication. >=20 > Zach=20 >=20 > On Jul 15, 2013, at 9:15 PM, teemu.savolainen@nokia.com wrote: >=20 >> Hi all, >>=20 >> We have published draft-savolainen-core-coap-websockets-00 (http://www.i= etf.org/internet-drafts/draft-savolainen-core-coap-websockets-00.txt) that = describes how to retrieve and update CoAP resources using CoAP requests and= responses over the WebSocket Protocol. >>=20 >> Please see the draft for details - we discuss there, for example, the sc= enarios where we envision this to be useful, and technical details required= for handshaking WebSocket connection for CoAP and for actually transportin= g CoAP messages within WebSocket framing. Of course not forgetting "coap+ws= " URI scheme for identifying both the WebSocket endpoint and CoAP resource = within that endpoint. >>=20 >> All comments welcome. >>=20 >> Best regards, >>=20 >> Teemu >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >=20 > --=20 > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://www.sensinode.com @SensinodeIoT > Mobile: +358 40 7796297 > Twitter: @zach_shelby > LinkedIn: http://fi.linkedin.com/in/zachshelby > 6LoWPAN Book: http://6lowpan.net >=20 >=20 >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com @SensinodeIoT Mobile: +358 40 7796297 Twitter: @zach_shelby LinkedIn: http://fi.linkedin.com/in/zachshelby 6LoWPAN Book: http://6lowpan.net From zach@sensinode.com Tue Jul 30 02:25:04 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A1AE11E81CB; Tue, 30 Jul 2013 02:25:00 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s47w5vMFXBA8; Tue, 30 Jul 2013 02:24:54 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 1A05411E81DE; Tue, 30 Jul 2013 02:22:58 -0700 (PDT) Received: from dhcp-1722.meeting.ietf.org (dhcp-1722.meeting.ietf.org [130.129.23.34]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id r6U9MjMM016174 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 30 Jul 2013 12:22:45 +0300 X-Authenticated-User: sensinodecom Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Zach Shelby In-Reply-To: <87fvuwe9wj.fsf@tzi.org> Date: Tue, 30 Jul 2013 11:22:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6C306372-9817-46E6-AD5B-6059E302BFCC@sensinode.com> <51F74C30.30905@ifi.uzh.ch> <053A4975-F6BD-4B4B-BC07-D869F00F4DF8@sensinode.com> <87fvuwe9wj.fsf@tzi.org> To: Olaf Bergmann X-Mailer: Apple Mail (2.1503) Cc: Corinna Schmitt , dtls-iot@ietf.org, "core@ietf.org WG" Subject: Re: [core] Where to work on AA/revocation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 09:25:04 -0000 (sorry for the cross-mailing list traffic) Olaf, This is the first IETF where this cluster of new AA proposals have come = out of the woodwork, so be patient finding a home for it. DICE is really = about optimising the use of DTLS in IoT, and we're keeping that focus = for at least the first charter as we have a couple very focused problems = to solve. Regarding the AA presentations that were given in CoRE yesterday. Yes I = do agree that the IETF should work in this area, but it was also clear = yesterday in CoRE that we don't all understand the set of requirements = that need to be solved. We are still living in the solution looking for = a problem phase. In addition to that there are also revocation proposals = that have been submitted recently, and a clear need for ACL management.=20= The nice thing about the IETF, is that even if you don't have a home for = work yet, you can still work on it. I would encourage the authors doing = AA and revocation related work to get together, figure out what the = actual problems to be solved are (talk to industry too) and then combine = solutions. CoRE is still probably a good mailing list to do that on for = now. As more people are agreeing about the problem space and are = interested to work on the (same) problem, we can find/make a home. Zach On Jul 30, 2013, at 10:20 AM, Olaf Bergmann wrote: > Zach Shelby writes: >=20 >> Hi Corinna, >>=20 >> On Jul 30, 2013, at 7:16 AM, Corinna Schmitt = wrote: >>=20 >>> Just for information concerning our draft >>> = http://tools.ietf.org/html/draft-schmitt-two-way-authentication-for-iot-00= : >>> We already started to implemented a solution and evaluated a little >>> bit. So we would be glad if our draft will be approved and stay in >>> DICE. >>=20 >> Your draft was actually discussed yesterday in the CoRE WG meeting in >> the scope of general authentication and authorisation in CoRE. This >> subject will be out of scope for the first DICE charter as we already >> have a couple concrete problems to solve. It is not clear where the >> "AA" work will end up, probably in some other new working group, or >> maybe in some future re-chartering of DICE. >=20 > The discussion yesterday was a bit low on the guidance level how to > proceed. Even if this topic is not the most pressing for DICE, I = highly > recommend to work on this space *now*. >=20 > Corinna, maybe we could team up with the other authors of the relevant > drafts to find out what the next steps are? We had a quick talk with > G=F6ran yesterday, and he also had the impression that the WG could = have > been more active in giving feedback on these drafts. --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com @SensinodeIoT Mobile: +358 40 7796297 Twitter: @zach_shelby LinkedIn: http://fi.linkedin.com/in/zachshelby 6LoWPAN Book: http://6lowpan.net From chrysn@fsfe.org Tue Jul 30 05:25:37 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA84621F944C for ; Tue, 30 Jul 2013 05:25:37 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGtQuZmMEhko for ; Tue, 30 Jul 2013 05:25:37 -0700 (PDT) Received: from prometheus.amsuess.com (prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::2]) by ietfa.amsl.com (Postfix) with ESMTP id 69DB521E80C3 for ; Tue, 30 Jul 2013 05:25:25 -0700 (PDT) Received: from mail.amsuess.com (unknown [IPv6:2001:15c0:6765:1:a800:ff:fe57:ab1e]) by prometheus.amsuess.com (Postfix) with ESMTPS id 588DC415C5; Tue, 30 Jul 2013 14:25:23 +0200 (CEST) Received: from hephaistos.amsuess.com (poseidon-stable [10.13.14.225]) by mail.amsuess.com (Postfix) with SMTP id 9D4ED4C120; Tue, 30 Jul 2013 14:25:22 +0200 (CEST) Received: (nullmailer pid 16530 invoked by uid 1000); Tue, 30 Jul 2013 12:05:20 -0000 Date: Tue, 30 Jul 2013 14:05:17 +0200 From: chrysn To: core@ietf.org Message-ID: <20130730120516.GB20501@hephaistos.amsuess.com> References: <916CE6CF87173740BC8A2CE443096962047E35F4@008-AM1MPN1-052.mgdnok.nokia.com> <2F0CFCA5-8232-445F-BEF8-4AE8E5B062D2@sensinode.com> <3a0de816601e4434b99aa31d1d732fd3@BLUPR06MB001.namprd06.prod.outlook.com> <8292F6E1-791C-4AC5-81C2-3ACF2E1366B0@sensinode.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RASg3xLB4tUQ4RcS" Content-Disposition: inline In-Reply-To: <8292F6E1-791C-4AC5-81C2-3ACF2E1366B0@sensinode.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [core] CoAP over WebSockets version -00 published X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 12:25:37 -0000 --RASg3xLB4tUQ4RcS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 29, 2013 at 02:26:52PM +0200, Zach Shelby wrote: > Now when we talk about a high-level WS/JSON binding for web > server/proxy to browser communication, that starts to make more sense. > But again, that really isn't in the scope of constrained device > communication, that is a browser/UI issue. a websocket transport for coap is as much in the scope of constrained device communication as is the coap http mapping. > That also does not require CoAP over WS, it requires a mapping from > CoAP over TCP to WebSockets running something appropriate (e.g. JSON) > for the application.=20 coap over tcp would not cover the imo most important application of this: web applications can not directly access tcp, while they can open websocket connections. i've experimented with coap over websockets; the most important use case for it from my point of view is complementing a coap-http proxy to expose those features of coap that can't be mapped to http directly (observations in my use case, and multicast). On Mon, 29 Jul 2013 12:09:17 +0000, Rick Bullotta wrote: > To me, it would seem that a higher level binding (e.g. WS/JSON) that > automatically maps/routes to a lower level binding (TCP/COAP binary) > would make a lot of sense. Along with a really high level binding via > an HTTP REST API. That would empower a broad audience of providers and > consumers to leverage it. concerning high level bindings, i suggest to get matthias kovatsch involved (cc'ing in case you're not on the list). his copper implementation might be leading the way to a dom-level coap api (i'm thinking CoAPRequest a la XMLHttpRequest), and until browsers can offer that natively (which i doubt will be widespread), coap over websockets could be the proxy tunnel a fallback js library could utilize. best regards chrysn --=20 I shouldn't have written all those tank programs. -- Kevin Flynn --RASg3xLB4tUQ4RcS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iQIbBAEBAgAGBQJR96v4AAoJEDmNERLTpL3hUUYP9ArbZ4NpfFq3VsT221gKgrvt +G2ant+lhdbTzI3Qlz7UlqgiiMarSj7CV6DBbTQ1wLJrctq4uDa+UF1IXv6f5HE8 /fTlfnpPn22MYmdtaAsX8sxjuVoUDzAV5y22QFge/ftiO+iwK6vndmGUgi/wkojT rJ3xdvZ4mlRgqJ9UhMhZTc7BEVTgZ3RzPGDrrVkzWfZjHpiGjmAssCT6D492yTKV 89RWDlZthPwQvi7c1bkiNKDOfCYH3CzUs+CySThBTyVpxdTvYABWBzCviIhfnhvi Sf+sAW6oaTKKYk8hf/oKPS6+fGBhL3b8MxdVGBQgM/IsKpvcA21agd6ocSe8OJVQ K+axU/+oQ65VuLaprG/32rGyi3wtZHgzS4XD+fPFm7vQDS8cC6RfIXjhjE48wzDQ cQMqzeWbvI9sKpfzUrdU+Lpahl/QzUGEjZ4jGI8XwKo9eA3GXAobErC/Uu1hh+Bb lyB3MOm0pmeSuiwkhKDBAdpsomhTwhbfEeXAHd4tjLakK4NVectanqz7iM9E7IVz 63SobxSnp4qo79Ue0Hq3yvpTKkqbsfRUbdeCvBf1G4VuOd2cbXpCRaUls4BoQ3S/ VSLoOWlPZGzBIcSNAiReOsIVomYnjB+q6TY+WurkiJLquei7izU+fz6Uau4+DZ00 uKNpRGydOPN6suETiJM= =ZVFQ -----END PGP SIGNATURE----- --RASg3xLB4tUQ4RcS-- From cabo@tzi.org Tue Jul 30 05:34:50 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC22E21F8FD8 for ; Tue, 30 Jul 2013 05:34:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.924 X-Spam-Level: X-Spam-Status: No, score=-105.924 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZK8LBJMbzb5 for ; Tue, 30 Jul 2013 05:34:40 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 28E4D21F9E3A for ; Tue, 30 Jul 2013 05:34:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r6UCYY3d023393 for ; Tue, 30 Jul 2013 14:34:34 +0200 (CEST) Received: from dhcp-90f8.meeting.ietf.org (dhcp-90f8.meeting.ietf.org [130.129.8.248]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 79ABD2FC; Tue, 30 Jul 2013 14:34:34 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Tue, 30 Jul 2013 14:34:34 +0200 To: "core@ietf.org WG" Message-Id: <43DEBBFF-EF81-4B89-B911-46853BE7308B@tzi.org> Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [core] CoAP over TCP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 12:34:50 -0000 It may seem obvious how to transport CoAP over TCP for the specific use = cases that might benefit from that. I have written up a small draft = that discusses a couple more options than may come to mind immediately. = I wrote this up some time ago, but it might be useful as additional = background material for Thursday's "Alternate Transports" segment. Gr=FC=DFe, Carsten Htmlized: = http://tools.ietf.org/html/draft-bormann-core-coap-tcp-00 Abstract: CoAP is defined to be transported over datagram transports such as UDP or DTLS. For a number of applications, it may be useful to channel CoAP messages in a TCP connection. This draft discusses different ways to do that. From zach@sensinode.com Tue Jul 30 05:36:08 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF9A711E81E1 for ; Tue, 30 Jul 2013 05:36:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.582 X-Spam-Level: X-Spam-Status: No, score=-3.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xBrw6ma1WDht for ; Tue, 30 Jul 2013 05:36:04 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 9177021E80C5 for ; Tue, 30 Jul 2013 05:36:01 -0700 (PDT) Received: from dhcp-1722.meeting.ietf.org (dhcp-1722.meeting.ietf.org [130.129.23.34]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id r6UCZrQr003650 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 30 Jul 2013 15:35:54 +0300 X-Authenticated-User: sensinodecom Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Zach Shelby In-Reply-To: <20130730120516.GB20501@hephaistos.amsuess.com> Date: Tue, 30 Jul 2013 14:35:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <916CE6CF87173740BC8A2CE443096962047E35F4@008-AM1MPN1-052.mgdnok.nokia.com> <2F0CFCA5-8232-445F-BEF8-4AE8E5B062D2@sensinode.com> <3a0de816601e4434b99aa31d1d732fd3@BLUPR06MB001.namprd06.prod.outlook.com> <8292F6E1-791C-4AC5-81C2-3ACF2E1366B0@sensinode.com> <20130730120516.GB20501@hephaistos.amsuess.com> To: chrysn X-Mailer: Apple Mail (2.1503) Cc: core@ietf.org Subject: Re: [core] CoAP over WebSockets version -00 published X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 12:36:09 -0000 Hi, Yes, I agree you could use CoAP over WebSockets for a Browser to = communicate with a CoAP-WebSocket proxy. As long as we're clear CoAP = over WebSockets is not a sane way to communicate with constrained = devices end-to-end. Could we title this CoAP-WebSocket proxying instead?=20= But instead of a duck-tape solution just because HTML5 doesn't expose = UDP or TCP support, why don't we lobby the HTML5 folks and major = browsers to add CoAP (over UDP or TCP, or even WebSockets) API.=20 Zach On Jul 30, 2013, at 2:05 PM, chrysn wrote: > On Mon, Jul 29, 2013 at 02:26:52PM +0200, Zach Shelby wrote: >> Now when we talk about a high-level WS/JSON binding for web >> server/proxy to browser communication, that starts to make more = sense. >> But again, that really isn't in the scope of constrained device >> communication, that is a browser/UI issue. >=20 > a websocket transport for coap is as much in the scope of constrained > device communication as is the coap http mapping. >=20 >> That also does not require CoAP over WS, it requires a mapping from >> CoAP over TCP to WebSockets running something appropriate (e.g. JSON) >> for the application.=20 >=20 > coap over tcp would not cover the imo most important application of > this: web applications can not directly access tcp, while they can = open > websocket connections. >=20 >=20 > i've experimented with coap over websockets; the most important use = case > for it from my point of view is complementing a coap-http proxy to > expose those features of coap that can't be mapped to http directly > (observations in my use case, and multicast). >=20 >=20 > On Mon, 29 Jul 2013 12:09:17 +0000, Rick Bullotta wrote: >> To me, it would seem that a higher level binding (e.g. WS/JSON) that >> automatically maps/routes to a lower level binding (TCP/COAP binary) >> would make a lot of sense. Along with a really high level binding via >> an HTTP REST API. That would empower a broad audience of providers = and >> consumers to leverage it. >=20 > concerning high level bindings, i suggest to get matthias kovatsch > involved (cc'ing in case you're not on the list). his copper > implementation might be leading the way to a dom-level coap api (i'm > thinking CoAPRequest a la XMLHttpRequest), and until browsers can = offer > that natively (which i doubt will be widespread), coap over websockets > could be the proxy tunnel a fallback js library could utilize. >=20 > best regards > chrysn >=20 > --=20 > I shouldn't have written all those tank programs. > -- Kevin Flynn > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com @SensinodeIoT Mobile: +358 40 7796297 Twitter: @zach_shelby LinkedIn: http://fi.linkedin.com/in/zachshelby 6LoWPAN Book: http://6lowpan.net From chrysn@fsfe.org Tue Jul 30 06:10:49 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC0421E80DF for ; Tue, 30 Jul 2013 06:10:49 -0700 (PDT) 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, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xtpv711g9MK4 for ; Tue, 30 Jul 2013 06:10:48 -0700 (PDT) Received: from prometheus.amsuess.com (prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::2]) by ietfa.amsl.com (Postfix) with ESMTP id D08E021E80C6 for ; Tue, 30 Jul 2013 06:10:47 -0700 (PDT) Received: from mail.amsuess.com (unknown [IPv6:2001:15c0:6765:1:a800:ff:fe57:ab1e]) by prometheus.amsuess.com (Postfix) with ESMTPS id F25A2415B4; Tue, 30 Jul 2013 15:10:45 +0200 (CEST) Received: from hephaistos.amsuess.com (poseidon-stable [10.13.14.225]) by mail.amsuess.com (Postfix) with SMTP id DE3874C120; Tue, 30 Jul 2013 15:10:41 +0200 (CEST) Received: (nullmailer pid 24581 invoked by uid 1000); Tue, 30 Jul 2013 13:10:41 -0000 Date: Tue, 30 Jul 2013 15:10:41 +0200 From: chrysn To: Zach Shelby Message-ID: <20130730131041.GA8183@hephaistos.amsuess.com> References: <916CE6CF87173740BC8A2CE443096962047E35F4@008-AM1MPN1-052.mgdnok.nokia.com> <2F0CFCA5-8232-445F-BEF8-4AE8E5B062D2@sensinode.com> <3a0de816601e4434b99aa31d1d732fd3@BLUPR06MB001.namprd06.prod.outlook.com> <8292F6E1-791C-4AC5-81C2-3ACF2E1366B0@sensinode.com> <20130730120516.GB20501@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IS0zKkzwUGydFO0o" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: core@ietf.org Subject: Re: [core] CoAP over WebSockets version -00 published X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 13:10:49 -0000 --IS0zKkzwUGydFO0o Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 30, 2013 at 02:35:53PM +0200, Zach Shelby wrote: > But instead of a duck-tape solution just because HTML5 doesn't expose > UDP or TCP support, why don't we lobby the HTML5 folks and major > browsers to add CoAP (over UDP or TCP, or even WebSockets) API.=20 the issue here is security. web sites are usually allowed to cause the client to fetch other resources, and whoever operates a web service inside a LAN should be aware of that, and of how the browser finds out whether it may do something or not. for exposing coap via udp in the browser, we'd have to work out something similar to cors for http. (but similar to how coap moved the http link header into a distinct resource, i'd say the same should be done with the cors headers -- a la ;if=3D"core.a";cors.allow-methods=3D"get" though given the devices we work with, it needs to be simple. a ;ct=3D40;cors.see-also providing the same information might be reasonable in many cases.) if we have both an api and a security model, i assume there is a chance to get that into browsers (matthias might have more information there), but even then, that'll take years to become widespread, and i doubt it'll achieve the coverage needed for end users. having an extension to the http proxying that makes all of coap available (like would a core-ws-mapping based on core-coap-websockets) would serve both as an early usable solution as well as as a fallback path that can be provided by a proxy; plus, we can take our time to develop the api atop of that (or, in parallel, based on copper). best regards chrysn --=20 A beginning is the time for taking the most delicate care that the balances are correct. -- Princess Irulan, Manual of Muad'Dib --IS0zKkzwUGydFO0o Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iQIcBAEBAgAGBQJR97tOAAoJEDmNERLTpL3h3HcQAMY/D6XvNq/MFV+Yg2F0/1Qh VHptqk0rP+X0aCyk/eXtKeWGi6LMbF/fChZs48U4TdN5dAmykT2K2JLG/n70T2kd w5wZIpYFX2/z9D/oAZjGW9QB/h4QRCiQG3eedmchyPjDlEic0GQqz4fYq/E2eQSs 71t153g9Dij1A+VMdYsTBVUzn/QR7EZWEk2/1UDaCmKD9hdQgEb7z/3gWJ+u03Y0 6ZrkvN2rhaQjQ1/ISVDG/Es48YpGykUKmYA/nlBUUULnyXx+dNE4WUHYNwyLmd07 tzjuXh9WnrTatIUBueSZt6xSXKozbtQaQAsuELhIQVB6tGd2Cp3yocoIbSdlFbnO 9s3oVCryx8PwbYIsZIyq1AWncO+zd9kGMJ9x/2oWpGz95T3R+GOrbBd3YdO7tcLH E+/oC0M82h3YZj1SZh0rbnGhJkOLjXM36lSw6MWYmB6lii2X7Y0pIP6DqrPBVgNW ypXXlTzsctqXi3kRdTv+gv51TJWj/VTXo0FzWp82nmD8N07+S/nJJeNn8lFM6CG6 alTi752OKHWXfz4pU7STfvBvO5DVP7aXniZbqxjwwDG3jkVUU+nhStc/Kp/FQbfq YX/rhaQtcqzgPbmsav8Of2kQnEaX8d3DiVh10hBrNar9KabJ2jsLGEwMx2yrwKMh 6VYPzNg6aAW6NVkDust/ =8yOS -----END PGP SIGNATURE----- --IS0zKkzwUGydFO0o-- From rick.bullotta@thingworx.com Tue Jul 30 09:05:03 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41E4A21F9D93 for ; Tue, 30 Jul 2013 09:05:03 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HKE1Nt1U5CsL for ; Tue, 30 Jul 2013 09:04:59 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0240.outbound.protection.outlook.com [207.46.163.240]) by ietfa.amsl.com (Postfix) with ESMTP id 6345E11E822C for ; Tue, 30 Jul 2013 09:01:54 -0700 (PDT) Received: from BLUPR06MB001.namprd06.prod.outlook.com (10.242.190.139) by BLUPR06MB003.namprd06.prod.outlook.com (10.242.190.149) with Microsoft SMTP Server (TLS) id 15.0.731.16; Tue, 30 Jul 2013 16:01:42 +0000 Received: from BLUPR06MB001.namprd06.prod.outlook.com ([169.254.1.81]) by BLUPR06MB001.namprd06.prod.outlook.com ([169.254.1.98]) with mapi id 15.00.0731.000; Tue, 30 Jul 2013 16:01:41 +0000 From: Rick Bullotta To: Zach Shelby , chrysn Thread-Topic: [core] CoAP over WebSockets version -00 published Thread-Index: Ac6Bjxyhi6T8vJFtQm63K6kAMA7LqwKwckcAAABL0yAAATSgAAAxiaKAAAERloAABywaAA== Date: Tue, 30 Jul 2013 16:01:41 +0000 Message-ID: <7d598d239e5c41ebab38266e7acef3b3@BLUPR06MB001.namprd06.prod.outlook.com> References: <916CE6CF87173740BC8A2CE443096962047E35F4@008-AM1MPN1-052.mgdnok.nokia.com> <2F0CFCA5-8232-445F-BEF8-4AE8E5B062D2@sensinode.com> <3a0de816601e4434b99aa31d1d732fd3@BLUPR06MB001.namprd06.prod.outlook.com> <8292F6E1-791C-4AC5-81C2-3ACF2E1366B0@sensinode.com> <20130730120516.GB20501@hephaistos.amsuess.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.59.9.6] x-forefront-prvs: 0923977CCA x-forefront-antispam-report: SFV:NSPM; SFS:(24454002)(377454003)(13464003)(189002)(199002)(51704005)(19580385001)(83322001)(19580405001)(19580395003)(74706001)(74316001)(83072001)(77096001)(56816003)(63696002)(76576001)(66066001)(47446002)(76786001)(76796001)(77982001)(65816001)(54316002)(47736001)(51856001)(4396001)(15202345003)(49866001)(47976001)(79102001)(50986001)(56776001)(81542001)(33646001)(59766001)(80022001)(53806001)(31966008)(16601075003)(81342001)(74366001)(69226001)(74876001)(16406001)(76482001)(74502001)(74662001)(54356001)(80976001)(46102001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR06MB003; H:BLUPR06MB001.namprd06.prod.outlook.com; CLIP:173.59.9.6; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: thingworx.com Cc: "core@ietf.org" Subject: Re: [core] CoAP over WebSockets version -00 published X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 16:05:03 -0000 Never happen. At least not in a ubiquitous or timely way. No technical re= asons, just practical ones. -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Zac= h Shelby Sent: Tuesday, July 30, 2013 8:36 AM To: chrysn Cc: core@ietf.org Subject: Re: [core] CoAP over WebSockets version -00 published Hi, Yes, I agree you could use CoAP over WebSockets for a Browser to communicat= e with a CoAP-WebSocket proxy. As long as we're clear CoAP over WebSockets = is not a sane way to communicate with constrained devices end-to-end. Could= we title this CoAP-WebSocket proxying instead?=20 But instead of a duck-tape solution just because HTML5 doesn't expose UDP o= r TCP support, why don't we lobby the HTML5 folks and major browsers to add= CoAP (over UDP or TCP, or even WebSockets) API.=20 Zach On Jul 30, 2013, at 2:05 PM, chrysn wrote: > On Mon, Jul 29, 2013 at 02:26:52PM +0200, Zach Shelby wrote: >> Now when we talk about a high-level WS/JSON binding for web=20 >> server/proxy to browser communication, that starts to make more sense. >> But again, that really isn't in the scope of constrained device=20 >> communication, that is a browser/UI issue. >=20 > a websocket transport for coap is as much in the scope of constrained=20 > device communication as is the coap http mapping. >=20 >> That also does not require CoAP over WS, it requires a mapping from=20 >> CoAP over TCP to WebSockets running something appropriate (e.g. JSON)=20 >> for the application. >=20 > coap over tcp would not cover the imo most important application of > this: web applications can not directly access tcp, while they can=20 > open websocket connections. >=20 >=20 > i've experimented with coap over websockets; the most important use=20 > case for it from my point of view is complementing a coap-http proxy=20 > to expose those features of coap that can't be mapped to http directly=20 > (observations in my use case, and multicast). >=20 >=20 > On Mon, 29 Jul 2013 12:09:17 +0000, Rick Bullotta wrote: >> To me, it would seem that a higher level binding (e.g. WS/JSON) that=20 >> automatically maps/routes to a lower level binding (TCP/COAP binary)=20 >> would make a lot of sense. Along with a really high level binding via=20 >> an HTTP REST API. That would empower a broad audience of providers=20 >> and consumers to leverage it. >=20 > concerning high level bindings, i suggest to get matthias kovatsch=20 > involved (cc'ing in case you're not on the list). his copper=20 > implementation might be leading the way to a dom-level coap api (i'm=20 > thinking CoAPRequest a la XMLHttpRequest), and until browsers can=20 > offer that natively (which i doubt will be widespread), coap over=20 > websockets could be the proxy tunnel a fallback js library could utilize. >=20 > best regards > chrysn >=20 > -- > I shouldn't have written all those tank programs. > -- Kevin Flynn > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core -- Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com @SensinodeIoT Mobile: +358 40 7796297 Twitter: @zach_shelby LinkedIn: http://fi.linkedin.com/in/zachshelby 6LoWPAN Book: http://6lowpan.net _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From internet-drafts@ietf.org Tue Jul 30 09:47:43 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87BF921F9BC1; Tue, 30 Jul 2013 09:47:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.545 X-Spam-Level: X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dj52kqBu-X00; Tue, 30 Jul 2013 09:47:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C24F11E8230; Tue, 30 Jul 2013 09:45:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.60p1 Message-ID: <20130730164533.29451.76036.idtracker@ietfa.amsl.com> Date: Tue, 30 Jul 2013 09:45:33 -0700 Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-groupcomm-12.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 16:47:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Constrained RESTful Environments Working = Group of the IETF. Title : Group Communication for CoAP Author(s) : Akbar Rahman Esko Dijk Filename : draft-ietf-core-groupcomm-12.txt Pages : 39 Date : 2013-07-30 Abstract: CoAP is a RESTful transfer protocol for constrained devices and constrained networks. It is anticipated that constrained devices will often naturally operate in groups (e.g., in a building automation scenario all lights in a given room may need to be switched on/off as a group). This document provides guidance for how the CoAP protocol should be used in a group communication context. An approach for using CoAP on top of IP multicast is detailed. Also, various use cases and corresponding protocol flows are provided to illustrate important concepts. Finally, guidance is provided for deployment in various network topologies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-groupcomm There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-core-groupcomm-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-groupcomm-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Akbar.Rahman@InterDigital.com Tue Jul 30 09:54:38 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1403221E80EC for ; Tue, 30 Jul 2013 09:54:32 -0700 (PDT) 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=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1kyUzkjpEiSN for ; Tue, 30 Jul 2013 09:54:26 -0700 (PDT) Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 7A74E21E80EA for ; Tue, 30 Jul 2013 09:54:06 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 30 Jul 2013 12:54:05 -0400 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, 30 Jul 2013 12:54:04 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] I-D Action: draft-ietf-core-groupcomm-12.txt Thread-Index: Ac6NRNiBe9HubWTdT467h0qMshJawAAAEzqw From: "Rahman, Akbar" To: X-OriginalArrivalTime: 30 Jul 2013 16:54:05.0828 (UTC) FILETIME=[66DC0C40:01CE8D45] Cc: core@ietf.org Subject: [core] FW: I-D Action: draft-ietf-core-groupcomm-12.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 16:54:38 -0000 Hi Carsten, We have updated the Groupcomm draft to address the issue raised by Zach at the Monday IETF-Berlin as below. Please start your personal final review and/or call the WGLC as per your discretion. Thanks, Akbar =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D Changes from ietf-11 to ietf-12: o Removed reference to "CoAP Ping" in Section 3.5 (Group Member Discovery) and replaced it with the more efficient support of discovery of groups and group members via the CORE RD as suggested by Zach Shelby. o Various editorial updates for improved readability =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Tuesday, July 30, 2013 12:46 PM To: i-d-announce@ietf.org Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-groupcomm-12.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments Working Group of the IETF. Title : Group Communication for CoAP Author(s) : Akbar Rahman Esko Dijk Filename : draft-ietf-core-groupcomm-12.txt Pages : 39 Date : 2013-07-30 Abstract: CoAP is a RESTful transfer protocol for constrained devices and constrained networks. It is anticipated that constrained devices will often naturally operate in groups (e.g., in a building automation scenario all lights in a given room may need to be switched on/off as a group). This document provides guidance for how the CoAP protocol should be used in a group communication context. An approach for using CoAP on top of IP multicast is detailed. Also, various use cases and corresponding protocol flows are provided to illustrate important concepts. Finally, guidance is provided for deployment in various network topologies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-groupcomm There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-core-groupcomm-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-groupcomm-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From bergmann@tzi.org Wed Jul 31 02:46:29 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB9E021F9A40 for ; Wed, 31 Jul 2013 02:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.174 X-Spam-Level: X-Spam-Status: No, score=-6.174 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7XuVhGSPe9hY for ; Wed, 31 Jul 2013 02:46:15 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 66D9021F9702 for ; Wed, 31 Jul 2013 02:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r6V9i3qk018682 for ; Wed, 31 Jul 2013 11:44:03 +0200 (CEST) Received: from aung.tzi.org (dhcp-90b5.meeting.ietf.org [130.129.8.181]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 6C8E66BB for ; Wed, 31 Jul 2013 11:44:03 +0200 (CEST) From: Olaf Bergmann To: core@ietf.org Date: Wed, 31 Jul 2013 11:44:02 +0200 Message-ID: <87ob9jgj31.fsf@tzi.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Subject: [core] Lunch Meeting AA discussion now at Wintergarten X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 09:46:29 -0000 If you are interested in the Authentication/Authorization topics brought up on Monday please feel free to join us at the round table in Wintergarten. (scheduled time: 11:35 to 13:00 CEST) Gruesse Olaf From stokcons@xs4all.nl Wed Jul 31 04:54:38 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D59DA21E8135 for ; Wed, 31 Jul 2013 04:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.91 X-Spam-Level: * X-Spam-Status: No, score=1.91 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uj3jyHFsCztv for ; Wed, 31 Jul 2013 04:54:31 -0700 (PDT) Received: from smtp-vbr11.xs4all.nl (smtp-vbr11.xs4all.nl [194.109.24.31]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA6121E80D3 for ; Wed, 31 Jul 2013 04:54:22 -0700 (PDT) Received: from roundcube.xs4all.nl (roundcube1.xs4all.net [194.109.20.195]) by smtp-vbr11.xs4all.nl (8.13.8/8.13.8) with ESMTP id r6VBsIFt067994; Wed, 31 Jul 2013 13:54:18 +0200 (CEST) (envelope-from stokcons@xs4all.nl) Received: from dhcp-54b7.meeting.ietf.org ([130.129.84.183]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 31 Jul 2013 13:54:17 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 31 Jul 2013 13:54:17 +0200 From: peter van der Stok To: carsten bormann , Core Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org Message-ID: <474bfcc6bc03b2cef5eab95f883c7830@xs4all.nl> X-Sender: stokcons@xs4all.nl (e4ewxr2TYTfJxUmksNx2a+aByia9Ysrc) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Subject: [core] draft-bormann-core-coap-tcp X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 11:54:38 -0000 Hi Carsten, I read your coap-tcp draft but I missed any text on TCP header size reduction. Is that intentional, or still forth coming? Peter -- Peter van der Stok mailto: consultancy@vanderstok.org From zehn.cao@gmail.com Wed Jul 31 06:18:55 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7A4921F9D98 for ; Wed, 31 Jul 2013 06:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.241 X-Spam-Level: X-Spam-Status: No, score=-2.241 tagged_above=-999 required=5 tests=[AWL=0.359, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GfDAAxxKolep for ; Wed, 31 Jul 2013 06:18:53 -0700 (PDT) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 648A521F9D9A for ; Wed, 31 Jul 2013 06:18:48 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id t57so580830wes.24 for ; Wed, 31 Jul 2013 06:18:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2tLLmknk1avUDnOzPJIvbqLXYH34hPTTJbz7kgrLIYY=; b=TM+oHyQwwxGTBDaRax7tWk5tUqbAxZCAmxZtyQnG6kAQakUBYsFHJoNYzNMjtZMbEg +qU6Ohe5N6dIPATHmeXG+dUlIa9k+PG2N2TXSZ8QPfwejr6BuHPswjCruJRonmfbYxZ/ ybVXf0IIJN6QQNGD9q5MCmfdkBbrgBll65wDIVbdGp3ZiXX4E/RimOWCgXyu3MpD2Uoo bNYuMqYSJzA7yHbsyv48gEFRqOR/zj5ZhR0erfLur0KmhW0Z4mcHD6ZwL5xm1s3XNC9P rGJLFK2PSq1I4j2GDEFARq+sGIDq2WUskwh1K9a2Sta8VybHPN3cYUjsToyVvCqSVXjj vaYg== MIME-Version: 1.0 X-Received: by 10.180.101.170 with SMTP id fh10mr4305835wib.22.1375276727524; Wed, 31 Jul 2013 06:18:47 -0700 (PDT) Received: by 10.216.90.135 with HTTP; Wed, 31 Jul 2013 06:18:47 -0700 (PDT) In-Reply-To: <51F6B448.5070905@tzi.de> References: <51F6B448.5070905@tzi.de> Date: Wed, 31 Jul 2013 15:18:47 +0200 Message-ID: From: "Cao,Zhen" To: Stefanie Gerdes Content-Type: text/plain; charset=ISO-8859-1 Cc: core@ietf.org Subject: Re: [core] Question to draft-gerdes-core-dcaf-authorize-00 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 13:18:55 -0000 >> I notice the tickets and AS usage in the draft, which recall me about >> the Kerberos work in IETF. Are they relevant? > > We actually had Kerberos in mind when we started thinking about using > access tickets in DCAF. Our requirements are a bit different however, > because most of our messages are transmitted using DTLS which provides > us with some security features, e.g. replay attack prevention. > Additionally, we want to allow for various revocation mechanisms and for > that reason have a lifetime in our ticket face which is optional. > > I'm not quite sure if there is still so much similarity to Kerberos or > if it would rather be confusing if we mention it in our draft. Understand, thanks for help clarification. Best regards, -z