From cabo@tzi.org Wed Jul 4 12:29:48 2012 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 6BA0E21F86D8 for ; Wed, 4 Jul 2012 12:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.399 X-Spam-Level: X-Spam-Status: No, score=-106.399 tagged_above=-999 required=5 tests=[AWL=-0.150, 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 IgCbxwTAvp5i for ; Wed, 4 Jul 2012 12:29:48 -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 A16F121F8596 for ; Wed, 4 Jul 2012 12:29:47 -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.3/8.14.3) with ESMTP id q64JTpB2022706 for ; Wed, 4 Jul 2012 21:29:51 +0200 (CEST) Received: from [192.168.217.105] (p54893FCE.dip.t-dialin.net [84.137.63.206]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3453AD7E; Wed, 4 Jul 2012 21:29:51 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Jul 2012 21:29:50 +0200 To: "core@ietf.org WG" Message-Id: Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [core] coap.me outage tonight 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, 04 Jul 2012 19:29:48 -0000 Since I've already (about 30 minutes after shutting it down :-) been = asked: The CoAP testing sites http://coap.me and coap://coap.me are down = tonight in preparation for a planned power outage here at TZI. Operation will resume tomorrow morning (CEST). Gr=FC=DFe, Carsten From angelo.castellani@gmail.com Fri Jul 6 05:39:58 2012 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 6449121F8739 for ; Fri, 6 Jul 2012 05:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 EoPekioOUdgV for ; Fri, 6 Jul 2012 05:39:57 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id A35B821F8736 for ; Fri, 6 Jul 2012 05:39:56 -0700 (PDT) Received: by were53 with SMTP id e53so372066wer.31 for ; Fri, 06 Jul 2012 05:40:12 -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:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=8CNn51xRwMAd+NmGe4YgC1G2TLBzii5YFX0CD8+ncJE=; b=dw7qCIexHSKqotm21INxpHFLg25v0Q1EvFyc+1c56XDth5215xRb0d5lfV12oM42BK 1N/jYyNxyj3sfzuie/LOPiZXRjZIrSCoaWyMZ5Y+FntOrA3TcY4JWLR/DL0+OEttNGnU sr51ysUJzRNqBKz7AQUSt6P7JQuClUVLlcPdc4RiE6A74CyiJpODAPhuxBpzpg49yBGj 4Igs3Nl29k4rt4Q257Jo2w6/inCuBaFdZ7s4ON8ZUiatIirPpNZBWfU8r67QQPu80x4N BKiWzwMmltuI9yzlAGcf6ouzVwdDbE2TPcV/9B7cIGgIq4RRQZ45Q3rG5OTwoeCsyyPU 0VOg== Received: by 10.180.94.33 with SMTP id cz1mr2960561wib.21.1341578412374; Fri, 06 Jul 2012 05:40:12 -0700 (PDT) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.216.9.11 with HTTP; Fri, 6 Jul 2012 05:39:57 -0700 (PDT) In-Reply-To: <20120704182418.10131.96251.idtracker@ietfa.amsl.com> References: <20120704182418.10131.96251.idtracker@ietfa.amsl.com> From: "Angelo P. Castellani" Date: Fri, 6 Jul 2012 14:39:57 +0200 X-Google-Sender-Auth: oOShHbfCgDHanate5OK_Q8N-ebI Message-ID: To: core Content-Type: text/plain; charset=UTF-8 Subject: [core] Fwd: New Version Notification for draft-castellani-core-http-mapping-05.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, 06 Jul 2012 12:39:58 -0000 Dear WG, we completed the http-mapping document splitting, required in Paris for adoption of the basic http-mapping part. Now draft-castellani-core-http-mapping-05 contains guidance for common deployment options, e.g., HTTP-CoAP reverse cross proxy, and provides useful considerations regarding proxy implementation, e.g. cache refresh using observe. We have put also all experimental features contained in the previous release in new document, i.e., draft-castellani-core-advanced-http-mapping-00. We wait for more WG interest in them, before proceeding with that work. Best, Angelo ---------- Forwarded message ---------- From: Date: 2012/7/4 Subject: New Version Notification for draft-castellani-core-http-mapping-05.txt To: akbar.rahman@interdigital.com Cc: angelo@castellani.net, salvatore.loreto@ericsson.com, tho@koanlogic.com, esko.dijk@philips.com A new version of I-D, draft-castellani-core-http-mapping-05.txt has been successfully submitted by Akbar Rahman and posted to the IETF repository. Filename: draft-castellani-core-http-mapping Revision: 05 Title: Best Practices for HTTP-CoAP Mapping Implementation Creation date: 2012-07-04 WG ID: Individual Submission Number of pages: 17 URL: http://www.ietf.org/internet-drafts/draft-castellani-core-http-mapping-05.txt Status: http://datatracker.ietf.org/doc/draft-castellani-core-http-mapping Htmlized: http://tools.ietf.org/html/draft-castellani-core-http-mapping-05 Diff: http://tools.ietf.org/rfcdiff?url2=draft-castellani-core-http-mapping-05 Abstract: This draft provides reference information for HTTP-CoAP proxy implementors. It details deployment options, discusses possible approaches for URI mapping, and provides useful considerations related to protocol translation. The IETF Secretariat ---------- Forwarded message ---------- From: Date: 2012/7/4 Subject: New Version Notification for draft-castellani-core-advanced-http-mapping-00.txt To: akbar.rahman@interdigital.com Cc: angelo@castellani.net, salvatore.loreto@ericsson.com, tho@koanlogic.com, esko.dijk@philips.com A new version of I-D, draft-castellani-core-advanced-http-mapping-00.txt has been successfully submitted by Akbar Rahman and posted to the IETF repository. Filename: draft-castellani-core-advanced-http-mapping Revision: 00 Title: Best Practices for HTTP-CoAP Mapping Implementation Creation date: 2012-07-04 WG ID: Individual Submission Number of pages: 30 URL: http://www.ietf.org/internet-drafts/draft-castellani-core-advanced-http-mapping-00.txt Status: http://datatracker.ietf.org/doc/draft-castellani-core-advanced-http-mapping Htmlized: http://tools.ietf.org/html/draft-castellani-core-advanced-http-mapping-00 Abstract: This draft describes advanced features for HTTP-CoAP proxy implementors. It details deployment options, discusses possible approaches for URI mapping, and provides useful considerations related to protocol translation. The IETF Secretariat From Bert.Greevenbosch@huawei.com Sun Jul 8 22:42:43 2012 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 CEC0F11E8073 for ; Sun, 8 Jul 2012 22:42:43 -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=[AWL=-0.000, 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 i5HzE7YOZLlX for ; Sun, 8 Jul 2012 22:42:43 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2B62C11E8079 for ; Sun, 8 Jul 2012 22:42:43 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHO92286; Mon, 09 Jul 2012 01:43:07 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 8 Jul 2012 22:41:19 -0700 Received: from SZXEML421-HUB.china.huawei.com (10.82.67.160) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 8 Jul 2012 22:41:18 -0700 Received: from SZXEML509-MBS.china.huawei.com ([10.82.67.53]) by szxeml421-hub.china.huawei.com ([10.82.67.160]) with mapi id 14.01.0323.003; Mon, 9 Jul 2012 13:41:12 +0800 From: Bert Greevenbosch To: "core@ietf.org" Thread-Topic: Upload of draft for "BlockMinimumTime" option Thread-Index: Ac1dlXIgejAMynRjREWUOXSbOxYSAA== Date: Mon, 9 Jul 2012 05:41:11 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB62905EDFF@szxeml509-mbs> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.110.143] Content-Type: multipart/alternative; boundary="_000_46A1DF3F04371240B504290A071B4DB62905EDFFszxeml509mbs_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [core] Upload of draft for "BlockMinimumTime" option 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, 09 Jul 2012 05:42:44 -0000 --_000_46A1DF3F04371240B504290A071B4DB62905EDFFszxeml509mbs_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello all, I have just upload a draft that defines the "BlockMinimumTime" option: http://datatracker.ietf.org/doc/draft-greevenbosch-core-block-minimum-time The option allows the server and client to negotiate the speed in which the= client sends requests in a block transaction. Comments are welcome! Best regards, Bert --_000_46A1DF3F04371240B504290A071B4DB62905EDFFszxeml509mbs_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello all,

 

I have just upload a draft that defines the "Bl= ockMinimumTime" option:

http://datatracker.ietf.org/doc/draft-greevenbosch-c= ore-block-minimum-time

 

The option allows the server and client to negotiate= the speed in which the client sends requests in a block transaction.<= /o:p>

 

Comments are welcome!

 

Best regards,

Bert

--_000_46A1DF3F04371240B504290A071B4DB62905EDFFszxeml509mbs_-- From cabo@tzi.org Mon Jul 9 00:42:59 2012 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 8363021F86E1 for ; Mon, 9 Jul 2012 00:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.093 X-Spam-Level: X-Spam-Status: No, score=-106.093 tagged_above=-999 required=5 tests=[AWL=-0.444, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_42=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 p3UfxyYtTn6n for ; Mon, 9 Jul 2012 00:42:59 -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 B2E2521F86C6 for ; Mon, 9 Jul 2012 00:42:58 -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.3/8.14.3) with ESMTP id q697h6qM018562; Mon, 9 Jul 2012 09:43:06 +0200 (CEST) Received: from [192.168.217.105] (p54894D96.dip.t-dialin.net [84.137.77.150]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 71A7BCB0; Mon, 9 Jul 2012 09:43:06 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <46A1DF3F04371240B504290A071B4DB62905EDFF@szxeml509-mbs> Date: Mon, 9 Jul 2012 09:43:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <40D15137-3896-4A63-BAA8-ED77D950EB83@tzi.org> References: <46A1DF3F04371240B504290A071B4DB62905EDFF@szxeml509-mbs> To: Bert Greevenbosch X-Mailer: Apple Mail (2.1278) Cc: "core@ietf.org" Subject: Re: [core] Upload of draft for "BlockMinimumTime" option 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, 09 Jul 2012 07:42:59 -0000 Hi Bert, this is interesting. Three observations pop up in my mind: 1) Clock accuracy and units. When we need timers that are shorter than = seconds, milliseconds come to mind. However, many nodes have convenient = clock sources only in power of two fractions. I would propose to always = give the nodes leeway to use either milliseconds or "mibiseconds" = (1/1024 s) as their time base. As we are typically not making any = mandates with respect to clock accuracy, and embedded systems sometimes = use RC oscillators for certain timing functions, that 24000 ppm = deviation is probably allowable anyway. Saying this explicitly may = remove one implementation headache. (Just for today, I'm not going to = add my ceterum censeo about pseudo-floating-point. :-) 2) Why just -block, and a single resource? Background: When e.g. = coap.me crawls a node, it rapidly reads all resources that are = advertised. Would it not be useful to give some pacing akin to your = MinimumBlockTime in a resource directory? 3) (General observation:) A server can already slow down a client by = just not sending responses very quickly. (The client is not supposed to = send a lot of parallel requests; see coap-10 section 4.7 and = draft-bormann-core-congestion-control for more detail.) So when is that = the right strategy and when does the server want to make the client slow = down? There should be some discussion of this in a future version of = this draft. Gr=FC=DFe, Carsten From jari.arkko@piuha.net Mon Jul 9 04:42:59 2012 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 34BA721F8705 for ; Mon, 9 Jul 2012 04:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.725 X-Spam-Level: X-Spam-Status: No, score=-102.725 tagged_above=-999 required=5 tests=[AWL=-0.126, 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 oP5HHVx+580E for ; Mon, 9 Jul 2012 04:42:58 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 636C921F86F7 for ; Mon, 9 Jul 2012 04:42:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 8C7ED2CC5D; Mon, 9 Jul 2012 14:43:22 +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 7G1_xAXeHQE3; Mon, 9 Jul 2012 14:43:21 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 2C1AD2CC44; Mon, 9 Jul 2012 14:43:21 +0300 (EEST) Message-ID: <4FFAC3D8.8090407@piuha.net> Date: Mon, 09 Jul 2012 14:43:20 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: core References: <20120709113756.5118.82222.idtracker@ietfa.amsl.com> In-Reply-To: <20120709113756.5118.82222.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: =?UTF-8?B?QXJpIEtlcsOkbmVu?= , "Anders Eriksson E \(KI/EAB\)" Subject: [core] draft-arkko-core-cellular 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, 09 Jul 2012 11:42:59 -0000 Hi, We have written a draft that talks about how to apply CoAP in smart objects attached to the Internet via the cellular networks. Comments appreciated. Jari On 09.07.2012 14:37, internet-drafts@ietf.org wrote: > A new version of I-D, draft-arkko-core-cellular-00.txt > has been successfully submitted by Jari Arkko and posted to the > IETF repository. > > Filename: draft-arkko-core-cellular > Revision: 00 > Title: Building Power-Efficient CoAP Devices for Cellular Networks > Creation date: 2012-07-09 > WG ID: Individual Submission > Number of pages: 17 > URL: http://www.ietf.org/internet-drafts/draft-arkko-core-cellular-00.txt > Status: http://datatracker.ietf.org/doc/draft-arkko-core-cellular > Htmlized: http://tools.ietf.org/html/draft-arkko-core-cellular-00 > > > Abstract: > This memo discusses the use of the Constrained Application Protocol > (CoAP) protocol in building sensors and other devices that employ > cellular networks as a communications medium. Building communicating > devices that employ these networks is obviously well known, but this > memo focuses specifically on techniques necessary to minimize power > consumption. > > > > > The IETF Secretariat > From trac+core@trac.tools.ietf.org Tue Jul 10 06:53:35 2012 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 14BD821F85F2 for ; Tue, 10 Jul 2012 06:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.152 X-Spam-Level: X-Spam-Status: No, score=-102.152 tagged_above=-999 required=5 tests=[AWL=0.447, 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 jQXa811cCEPk for ; Tue, 10 Jul 2012 06:53:34 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 4FEE221F86EE for ; Tue, 10 Jul 2012 06:53:34 -0700 (PDT) Received: from localhost ([127.0.0.1]:41880 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1Soast-00052Q-Hu; Tue, 10 Jul 2012 15:53:47 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Tue, 10 Jul 2012 13:53:47 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/core/trac/ticket/185#comment:2 Message-ID: <075.a5202cee529d453afe3da2596f9f3a2e@trac.tools.ietf.org> References: <060.aed390b8a1237d4f971337af6cfc7d37@trac.tools.ietf.org> X-Trac-Ticket-ID: 185 In-Reply-To: <060.aed390b8a1237d4f971337af6cfc7d37@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, 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: Resent-Message-Id: <20120710135334.4FEE221F86EE@ietfa.amsl.com> Resent-Date: Tue, 10 Jul 2012 06:53:34 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #185: Add key use cases including discovery 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: Tue, 10 Jul 2012 13:53:35 -0000 #185: Add key use cases including discovery Changes (by esko.dijk@…): * status: new => closed * resolution: => fixed Comment: key use cases added in -02 -- -------------------------+------------------------------------------ Reporter: esko.dijk@… | Owner: draft-ietf-core-groupcomm@… Type: task | Status: closed Priority: major | Milestone: Component: groupcomm | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+------------------------------------------ Ticket URL: core From trac+core@trac.tools.ietf.org Tue Jul 10 06:54:22 2012 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 5831E21F85D3 for ; Tue, 10 Jul 2012 06:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.16 X-Spam-Level: X-Spam-Status: No, score=-102.16 tagged_above=-999 required=5 tests=[AWL=0.439, 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 x0m4Xomt8KYz for ; Tue, 10 Jul 2012 06:54:21 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 9154521F8707 for ; Tue, 10 Jul 2012 06:54:21 -0700 (PDT) Received: from localhost ([127.0.0.1]:41959 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1Soatr-00053m-Ke; Tue, 10 Jul 2012 15:54:47 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Tue, 10 Jul 2012 13:54:47 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/188#comment:1 Message-ID: <075.114e67afd52d2e19961d2664d617c380@trac.tools.ietf.org> References: <060.6fe395be06f6b58e5701326691e6bff7@trac.tools.ietf.org> X-Trac-Ticket-ID: 188 In-Reply-To: <060.6fe395be06f6b58e5701326691e6bff7@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, 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: Resent-Message-Id: <20120710135421.9154521F8707@ietfa.amsl.com> Resent-Date: Tue, 10 Jul 2012 06:54:21 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #188: Update congestion control with recent "Patience" contributions 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: Tue, 10 Jul 2012 13:54:22 -0000 #188: Update congestion control with recent "Patience" contributions Changes (by esko.dijk@…): * status: new => closed * resolution: => fixed Comment: done in version -02 -- -------------------------+------------------------------------------ Reporter: esko.dijk@… | Owner: draft-ietf-core-groupcomm@… Type: task | Status: closed Priority: major | Milestone: Component: groupcomm | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+------------------------------------------ Ticket URL: core From internet-drafts@ietf.org Tue Jul 10 06:59:52 2012 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 D76C421F878A; Tue, 10 Jul 2012 06:59:52 -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 pnvtSLupjoTp; Tue, 10 Jul 2012 06:59:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 659E121F8792; Tue, 10 Jul 2012 06:59:52 -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.30p3 Message-ID: <20120710135952.12030.25664.idtracker@ietfa.amsl.com> Date: Tue, 10 Jul 2012 06:59:52 -0700 Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-groupcomm-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, 10 Jul 2012 13:59:53 -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-02.txt Pages : 25 Date : 2012-07-10 Abstract: CoAP is a RESTful transfer protocol for constrained devices. 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 defines how the CoAP protocol should be used in a group communication context. An approach for using CoAP on top of IP multicast is detailed for both constrained and un-constrained networks. Also, various use causes 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-02 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-groupcomm-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From stokcons@xs4all.nl Tue Jul 10 07:32:41 2012 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 07D4021F878A for ; Tue, 10 Jul 2012 07:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.154 X-Spam-Level: X-Spam-Status: No, score=-0.154 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 45Uk++zgr12w for ; Tue, 10 Jul 2012 07:32:40 -0700 (PDT) Received: from smtp-vbr6.xs4all.nl (smtp-vbr6.xs4all.nl [194.109.24.26]) by ietfa.amsl.com (Postfix) with ESMTP id 30C8C21F86DF for ; Tue, 10 Jul 2012 07:32:40 -0700 (PDT) Received: from roundcube.xs4all.nl (roundcube5.xs4all.net [194.109.20.203]) by smtp-vbr6.xs4all.nl (8.13.8/8.13.8) with ESMTP id q6AEWaEY030620 for ; Tue, 10 Jul 2012 16:32:36 +0200 (CEST) (envelope-from stokcons@xs4all.nl) Received: from AMontpellier-556-1-257-67.w90-0.abo.wanadoo.fr ([90.0.105.67]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 10 Jul 2012 16:32:36 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 10 Jul 2012 16:32:36 +0200 From: peter van der Stok To: Organization: vanderstok consultancy Mail-Reply-To: Message-ID: X-Sender: stokcons@xs4all.nl (hcoyhcUEREdct4cVU92BDLva65E+xGr+) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Subject: [core] new internet draft discovery, naming, addressing 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, 10 Jul 2012 14:32:41 -0000 Dear wg A new draft has been submitted with the following characteristics Document draft-vanderstok-core-dna http://datatracker.ietf.org/doc/draft-vanderstok-core-dna/ Revision 02 WG Individual Submission Document date 2012-07-10 Submission date 2012-07-10 Title CoRE Discovery, Naming, and Addressing Author information Author 1 Peter van der Stok Author 2 Kerry Lynn Author 3 Anders Brandt Abstract This is a working document intended to focus discussion and refine draft language for the CoAP protocol specification (or other proposed standards) in the areas of discovery, naming, and addressing. Requirements on discovery are motivated. Special emphasis is placed on group definition and discovery. Examples show how groups can be represented in CoAP Resource Directories or DNS-SD. Pages 30 File size 69.1 KB -- Peter van der Stok mailto: consultancy@vanderstok.org www: www.vanderstok.org tel NL: +31(0)492474673 F: +33(0)966015248 From sarikaya2012@gmail.com Tue Jul 10 13:14:03 2012 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 2038911E80D9 for ; Tue, 10 Jul 2012 13:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.52 X-Spam-Level: X-Spam-Status: No, score=-3.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 MS-kj45mntuo for ; Tue, 10 Jul 2012 13:13:56 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA8F11E809A for ; Tue, 10 Jul 2012 13:13:56 -0700 (PDT) Received: by ghbg16 with SMTP id g16so460958ghb.31 for ; Tue, 10 Jul 2012 13:14:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=YWPD4SKoTtym8GSf1Wlk+PVydezI5dI1g55hS969w6k=; b=P8SKainjhqwUCl/ZMoiOch8okFYyYHuWkkQAq1zOpGS9sP1ofBQnXn/JNXdaD0fpjK lb6wpZS35/R3ttonb/78DtHufxabKuCB9M3kIYvEHRWEWAA3vy1CwaPcwnh80klwAvSZ L/aV3GGhU8sGVpruqoKhfismM1fZElpSNd7xnku8BpDbBbKMnidn8qmpqdk/WQ9VQvMJ ph73pQPijPVXpVQpX4iqsAf+5phCGytA1rkmIE24o/1m6uAYcrsVkFqKY8OL360xzQpa tE+gqAPWRIavsqSPGaG0EOfNxt2qJ8jNhIlUnw1aY/745UnINP03LwuAwghOAWw2Z1YQ ZaqQ== MIME-Version: 1.0 Received: by 10.50.195.234 with SMTP id ih10mr12696363igc.0.1341951264392; Tue, 10 Jul 2012 13:14:24 -0700 (PDT) Received: by 10.231.118.210 with HTTP; Tue, 10 Jul 2012 13:14:24 -0700 (PDT) In-Reply-To: <20120710201237.25547.42254.idtracker@ietfa.amsl.com> References: <20120710201237.25547.42254.idtracker@ietfa.amsl.com> Date: Tue, 10 Jul 2012 15:14:24 -0500 Message-ID: From: Behcet Sarikaya To: core WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [core] Fwd: New Version Notification for draft-sarikaya-core-sbootstrapping-05.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.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, 10 Jul 2012 20:14:03 -0000 A new version of I-D, draft-sarikaya-core-sbootstrapping-05.txt has been successfully submitted by Behcet Sarikaya and posted to the IETF repository. Filename: draft-sarikaya-core-sbootstrapping Revision: 05 Title: Security Bootstrapping Solution for Resource-Constrained Devices Creation date: 2012-07-10 WG ID: Individual Submission Number of pages: 27 URL: http://www.ietf.org/internet-drafts/draft-sarikaya-core-sbootstrapping-05.txt Status: http://datatracker.ietf.org/doc/draft-sarikaya-core-sbootstrapping Htmlized: http://tools.ietf.org/html/draft-sarikaya-core-sbootstrapping-05 Diff: http://tools.ietf.org/rfcdiff?url2=draft-sarikaya-core-sbootstrapping-05 Abstract: This document describes how to initially configure the network of resource constrained nodes securely, a.k.a., security bootstrapping. Bootstrapping architecture, communication channel and bootstrap security methods are described. System level objectives for security bootstrapping are stated. Bootstrapping solution is based on EAP-TLS authentication with the use of raw public keys as certificates. The IETF Secretariat From hannes.tschofenig@gmx.net Wed Jul 11 03:58:42 2012 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 C4C3321F8665 for ; Wed, 11 Jul 2012 03:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.42 X-Spam-Level: X-Spam-Status: No, score=-102.42 tagged_above=-999 required=5 tests=[AWL=0.179, 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 5tq3cL8OonqI for ; Wed, 11 Jul 2012 03:58:42 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id BA5BD21F856C for ; Wed, 11 Jul 2012 03:58:41 -0700 (PDT) Received: (qmail invoked by alias); 11 Jul 2012 10:59:10 -0000 Received: from unknown (EHLO [10.255.128.232]) [194.251.119.201] by mail.gmx.net (mp072) with SMTP; 11 Jul 2012 12:59:10 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+ZmiAI9RSZbrLa+8mx1c2UBvxVeaPnV4pqORFNsw CkNO9LwOQjAHp5 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Hannes Tschofenig Date: Wed, 11 Jul 2012 13:58:59 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <54CCFFDE-4C7B-4AB7-B992-5516DD0F7773@gmx.net> References: <1CA8C4CB-1FD8-4498-9988-41B6334F58FD@gmx.net> To: IETF CoRE X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [core] Fwd: draft-ietf-tls-oob-pubkey: The Open Issue 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, 11 Jul 2012 10:58:42 -0000 Hi all,=20 I am trying to finish the work on draft-ietf-tls-oob-pubkey, which also = covers smart objects as one use case.=20 Have a look at the example message exchange below and tell me whether = there is something missing here.=20 Thanks.=20 Ciao Hannes Begin forwarded message: > From: Hannes Tschofenig > Date: July 11, 2012 1:56:40 PM GMT+03:00 > To: tls@ietf.org > Cc: Hannes Tschofenig > Subject: draft-ietf-tls-oob-pubkey: The Open Issue >=20 > Hi all,=20 >=20 > draft-ietf-tls-oob-pubkey specifies a new TLS certificate type for = exchanging raw public keys in Transport Layer Security (TLS) and = Datagram Transport Layer Security (DTLS) for use with out-of-band public = key validation. >=20 > Here is the latest draft:=20 > http://tools.ietf.org/html/draft-ietf-tls-oob-pubkey-03 >=20 > I would be great to get your feedback on an open issue that concerns = the semantic of the exchange. I believe there are three use cases we = would like to support with this work. Below, I provide high level = message exchanges to explain those:=20 >=20 > I) Server uses Raw Public Keys (client authentication happens at some = other layer) > (the DANE use case) >=20 > client_hello,=20 > raw-public-key-indicator=3D"Server, when you send me your raw public = key? I support this out-of-band key validation using DANE." -> >=20 > <- server_hello, > raw-public-key=3D"OK. The certificate = structure below contains my raw public key.", > certificate, // with raw public key = inside=20 > server_key_exchange, > server_hello_done >=20 > client_key_exchange, > change_cipher_spec, > finished -> >=20 > <- change_cipher_spec, > finished >=20 > Application Data <-------> Application Data >=20 >=20 > II) Client and Server use Raw Public Keys > (the smart object use case - CORE working group) >=20 > client_hello,=20 > raw-public-key=3D"Server, please send me your raw public key and I = will then send you mine. Are you OK processing my raw public key for = client authentication?" -> >=20 > <- server_hello, > raw-public-key=3D"Below you find my raw = public key and please send me your raw public key for client=20 > = authentication", > certificate, // raw public key > server_key_exchange, > certificate_request, > server_hello_done >=20 > certificate, // with client's raw public key > client_key_exchange, > certificate_verify, > change_cipher_spec, > finished -> >=20 > <- change_cipher_spec, > finished >=20 > Application Data <-------> Application Data >=20 >=20 > II) Hybrid Scenario > (the OAuth Holder-of-the-Key Use case) >=20 > client_hello,=20 > raw-public-key=3D"I would like to use my raw public key for client = authentication with OAuth. I also process X.509 for server-side = authentication." -> >=20 > <- server_hello, > raw-public-key=3D"Please send me your raw = public key. I use X.509 for server-side authentication", > certificate, // with X.509 cert. > server_key_exchange, > certificate_request, > server_hello_done >=20 > certificate, // with client's raw public key > client_key_exchange, > certificate_verify, > change_cipher_spec, > finished -> >=20 > <- change_cipher_spec, > finished >=20 > Application Data <-------> Application Data > -------- >=20 > QUESTION: Are these all the message exchanges we need? Are there some = problems with the exchanges?=20 >=20 > Ciao > Hannes >=20 From zach@sensinode.com Wed Jul 11 04:47:07 2012 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 A756D21F864B for ; Wed, 11 Jul 2012 04:47:07 -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 xGv2XEAVKkeL for ; Wed, 11 Jul 2012 04:47:06 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 7C88C21F8649 for ; Wed, 11 Jul 2012 04:46:59 -0700 (PDT) Received: from [172.20.10.4] (81-197-83-147.elisa-mobile.fi [81.197.83.147]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q6BBlRJD007657 for ; Wed, 11 Jul 2012 14:47:27 +0300 From: Zach Shelby Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Jul 2012 14:47:27 +0300 References: <20120711114256.8289.22566.idtracker@ietfa.amsl.com> To: "core@ietf.org WG" Message-Id: Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [core] Fwd: New Version Notification for draft-shelby-core-interfaces-03.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, 11 Jul 2012 11:47:07 -0000 Matthieu and I have posted a new version of the CoRE Interfaces draft. = This now includes a useful new mechanism to create bindings between = resources on the same or different endpoints. For example for a light = switch to control a light, or to handle just about any interaction = between resources. The draft also updates all resource types and = interface descriptions to the -14 version of CoRE Link Format. Try it out - comments welcome!=20 Zach Begin forwarded message: > From: internet-drafts@ietf.org > Date: July 11, 2012 2:42:56 PM GMT+03:00 > To: zach@sensinode.com > Cc: matthieu.vial@schneider-electric.com > Subject: New Version Notification for = draft-shelby-core-interfaces-03.txt >=20 >=20 > A new version of I-D, draft-shelby-core-interfaces-03.txt > has been successfully submitted by Zach Shelby and posted to the > IETF repository. >=20 > Filename: draft-shelby-core-interfaces > Revision: 03 > Title: CoRE Interfaces > Creation date: 2012-07-11 > WG ID: Individual Submission > Number of pages: 24 > URL: = http://www.ietf.org/internet-drafts/draft-shelby-core-interfaces-03.txt > Status: = http://datatracker.ietf.org/doc/draft-shelby-core-interfaces > Htmlized: = http://tools.ietf.org/html/draft-shelby-core-interfaces-03 > Diff: = http://tools.ietf.org/rfcdiff?url2=3Ddraft-shelby-core-interfaces-03 >=20 > Abstract: > This document defines well-known REST interface descriptions for > Batch, Sensor, Parameter and Actuator types for use in contrained = web > servers using the CoRE Link Format. A short reference is provided > for each type that can be efficiently included in the interface > description attribute of the CoRE Link Format. These descriptions > are intended to be for general use in resource designs or for > inclusion in more specific interface profiles. In addition, this > document defines the concepts of Function Set and Binding. The > former is the basis element to create RESTful profiles and the = latter > helps the configuration of links between resources located on one or > more endpoints. >=20 >=20 >=20 >=20 > The IETF Secretariat --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From Akbar.Rahman@InterDigital.com Wed Jul 11 06:53:54 2012 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 A6FEB21F8562 for ; Wed, 11 Jul 2012 06:53: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 tZrEM1Y6X5bi for ; Wed, 11 Jul 2012 06:53:54 -0700 (PDT) Received: from idcout.InterDigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id E73A621F855D for ; Wed, 11 Jul 2012 06:53:53 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Jul 2012 09:54:23 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 11 Jul 2012 09:54:22 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-ietf-core-groupcomm-02.txt Thread-Index: Ac1epFkEWWNOn5zNT9uG5wCp0J4v3QAx6tkw From: "Rahman, Akbar" To: X-OriginalArrivalTime: 11 Jul 2012 13:54:23.0751 (UTC) FILETIME=[AD9DA970:01CD5F6C] Subject: [core] FW: New Version Notification for draft-ietf-core-groupcomm-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: Wed, 11 Jul 2012 13:53:54 -0000 SGksDQoNCg0KDQpFc2tvIGFuZCBJIGhhdmUgdXBkYXRlZCB0aGUgR3JvdXAgQ29tbXVuaWNhdGlv bnMgSS1ELiAgQW55IGNvbW1lbnRzIGFyZSB3ZWxjb21lLg0KDQoNCmh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtY29yZS1ncm91cGNvbW0tMDINCg0KDQogICBDaGFuZ2VzIGZy b20gaWV0Zi0wMSB0byBpZXRmLTAyOg0KDQogICBvICBSZXdyb3RlIGNvbmdlc3Rpb24gY29udHJv bCBzZWN0aW9uIGJhc2VkIG9uIGxhdGVzdCBDb0FQIHRleHQNCiAgICAgIGluY2x1ZGluZyBMZWlz dXJlIGNvbmNlcHQgKCMxODgpDQoNCiAgIG8gIFVwZGF0ZWQgdGhlIENvQVAvSFRUUCBpbnRlcndv cmtpbmcgc2VjdGlvbiBhbmQgZXhhbXBsZSB1c2UgY2FzZQ0KICAgICAgd2l0aCBtb3JlIGRldGFp bHMgYW5kIHVzZSBvZiBNTEQgZm9yIG11bHRpY2FzdCBncm91cCBqb2luaW5nDQoNCiAgIG8gIEtl eSB1c2UgY2FzZXMgYWRkZWQgKCMxODUpDQoNCiAgIG8gIFJlZmVyZW5jZXMgdG8gW0ktRC52YW5k ZXJzdG9rLWNvcmUtZG5hXSBhbmQNCiAgICAgIFtJLUQuY2FzdGVsbGFuaS1jb3JlLWFkdmFuY2Vk LWh0dHAtbWFwcGluZ10gYWRkZWQNCg0KICAgbyAgTW92ZWQgYmFja2dyb3VuZCBzZWN0aW9ucyBv biAiTUxEIiBhbmQgIkNvQVAtT2JzZXJ2ZSIgdG8NCiAgICAgIEFwcGVuZGljZXMNCg0KICAgbyAg UmVtb3ZlZCByZXF1aXJlbWVudHMgc2VjdGlvbiAoYW5kIG1vdmVkIGl0IHRvDQogICAgICBkcmFm dC1kaWprLWNvcmUtZ3JvdXBjb21tLW1pc2MpDQoNCiAgIG8gIEFkZGVkIGRldGFpbHMgZm9yIElB TkEgcmVxdWVzdCBmb3IgZ3JvdXAgY29tbXVuaWNhdGlvbiBtdWx0aWNhc3QNCiAgICAgIGFkZHJl c3Nlcw0KDQogICBvICBDbGFyaWZpZWQgdGV4dCB0byBkaXN0aW5ndWlzaCBiZXR3ZWVuICJsaW5r IGxvY2FsIiBhbmQgZ2VuZXJhbA0KICAgICAgbXVsdGljYXN0IGNhc2VzDQoNCiAgIG8gIE1vdmVk IGxlbmd0aHkgYmFja2dyb3VuZCBzZWN0aW9uIDUgdG8NCiAgICAgIGRyYWZ0LWRpamstY29yZS1n cm91cGNvbW0tbWlzYyBhbmQgcmVwbGFjZWQgd2l0aCBhIHN1bW1hcnkNCg0KICAgbyAgVmFyaW91 cyBlZGl0b3JpYWwgdXBkYXRlcyBmb3IgaW1wcm92ZWQgcmVhZGliaWxpdHkNCg0KDQoNClNpbmNl cmVseSwNCg0KDQpBa2Jhcg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBp bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmdd IA0KU2VudDogVHVlc2RheSwgSnVseSAxMCwgMjAxMiAxMDowMCBBTQ0KVG86IGVza28uZGlqa0Bw aGlsaXBzLmNvbQ0KQ2M6IFJhaG1hbiwgQWtiYXINClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1jb3JlLWdyb3VwY29tbS0wMi50eHQNCg0KDQpBIG5ldyB2 ZXJzaW9uIG9mIEktRCwgZHJhZnQtaWV0Zi1jb3JlLWdyb3VwY29tbS0wMi50eHQNCmhhcyBiZWVu IHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgRXNrbyBEaWprIGFuZCBwb3N0ZWQgdG8gdGhlDQpJ RVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQtaWV0Zi1jb3JlLWdyb3VwY29tbQ0K UmV2aXNpb246CSAwMg0KVGl0bGU6CQkgR3JvdXAgQ29tbXVuaWNhdGlvbiBmb3IgQ29BUA0KQ3Jl YXRpb24gZGF0ZToJIDIwMTItMDctMTANCldHIElEOgkJIGNvcmUNCk51bWJlciBvZiBwYWdlczog MjUNClVSTDogICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv ZHJhZnQtaWV0Zi1jb3JlLWdyb3VwY29tbS0wMi50eHQNClN0YXR1czogICAgICAgICAgaHR0cDov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWNvcmUtZ3JvdXBjb21tDQpIdG1s aXplZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY29yZS1n cm91cGNvbW0tMDINCkRpZmY6ICAgICAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL3JmY2Rp ZmY/dXJsMj1kcmFmdC1pZXRmLWNvcmUtZ3JvdXBjb21tLTAyDQoNCkFic3RyYWN0Og0KICAgQ29B UCBpcyBhIFJFU1RmdWwgdHJhbnNmZXIgcHJvdG9jb2wgZm9yIGNvbnN0cmFpbmVkIGRldmljZXMu ICBJdCBpcw0KICAgYW50aWNpcGF0ZWQgdGhhdCBjb25zdHJhaW5lZCBkZXZpY2VzIHdpbGwgb2Z0 ZW4gbmF0dXJhbGx5IG9wZXJhdGUgaW4NCiAgIGdyb3VwcyAoZS5nLiBpbiBhIGJ1aWxkaW5nIGF1 dG9tYXRpb24gc2NlbmFyaW8gYWxsIGxpZ2h0cyBpbiBhIGdpdmVuDQogICByb29tIG1heSBuZWVk IHRvIGJlIHN3aXRjaGVkIG9uL29mZiBhcyBhIGdyb3VwKS4gIFRoaXMgZG9jdW1lbnQNCiAgIGRl ZmluZXMgaG93IHRoZSBDb0FQIHByb3RvY29sIHNob3VsZCBiZSB1c2VkIGluIGEgZ3JvdXAgY29t bXVuaWNhdGlvbg0KICAgY29udGV4dC4gIEFuIGFwcHJvYWNoIGZvciB1c2luZyBDb0FQIG9uIHRv cCBvZiBJUCBtdWx0aWNhc3QgaXMNCiAgIGRldGFpbGVkIGZvciBib3RoIGNvbnN0cmFpbmVkIGFu ZCB1bi1jb25zdHJhaW5lZCBuZXR3b3Jrcy4gIEFsc28sDQogICB2YXJpb3VzIHVzZSBjYXVzZXMg YW5kIGNvcnJlc3BvbmRpbmcgcHJvdG9jb2wgZmxvd3MgYXJlIHByb3ZpZGVkIHRvDQogICBpbGx1 c3RyYXRlIGltcG9ydGFudCBjb25jZXB0cy4gIEZpbmFsbHksIGd1aWRhbmNlIGlzIHByb3ZpZGVk IGZvcg0KICAgZGVwbG95bWVudCBpbiB2YXJpb3VzIG5ldHdvcmsgdG9wb2xvZ2llcy4NCg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQo= From kovatsch@inf.ethz.ch Wed Jul 11 09:32:16 2012 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 900D821F861A for ; Wed, 11 Jul 2012 09:32:16 -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 j8AYqXOaRLzL for ; Wed, 11 Jul 2012 09:32:15 -0700 (PDT) Received: from edge10.ethz.ch (edge10.ethz.ch [82.130.75.186]) by ietfa.amsl.com (Postfix) with ESMTP id 1FCB821F8616 for ; Wed, 11 Jul 2012 09:32:13 -0700 (PDT) Received: from CAS10.d.ethz.ch (172.31.38.210) by edge10.ethz.ch (82.130.75.186) with Microsoft SMTP Server (TLS) id 14.2.298.4; Wed, 11 Jul 2012 18:32:43 +0200 Received: from MBX10.d.ethz.ch ([fe80::6d7b:f3da:a5b1:c9e9]) by CAS10.d.ethz.ch ([fe80::cce:fc66:7b56:a06a%10]) with mapi id 14.02.0298.004; Wed, 11 Jul 2012 18:32:43 +0200 From: "Kovatsch Matthias" To: Zach Shelby , "core@ietf.org WG" Thread-Topic: [core] Fwd: New Version Notification for draft-shelby-core-interfaces-03.txt Thread-Index: AQHNX1r/VgqA7Rlb20yzGVI/xgNtrJckRqpQ Date: Wed, 11 Jul 2012 16:32:43 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B5142A259D@MBX10.d.ethz.ch> References: <20120711114256.8289.22566.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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [core] Fwd: New Version Notification for draft-shelby-core-interfaces-03.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, 11 Jul 2012 16:32:16 -0000 Hi guys I am currently reading the new version and I am a bit confused about the bi= nding part. It implies that both ends provide resources, i.e., also Web clients expose = their internal state as resources. This sounds a little odd to me... bindings also exist when a client does no= t have server-functionality. Maybe I am just missing an introduction that says that it is best when clie= nts export their configuration as resources. But, still I feel this mismatch of links between resources versus client-se= rver interaction. Ciao Matthias > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of > Zach Shelby > Sent: Mittwoch, 11. Juli 2012 13:47 > To: core@ietf.org WG > Subject: [core] Fwd: New Version Notification for draft-shelby-core- > interfaces-03.txt >=20 > Matthieu and I have posted a new version of the CoRE Interfaces draft. Th= is > now includes a useful new mechanism to create bindings between resources > on the same or different endpoints. For example for a light switch to con= trol > a light, or to handle just about any interaction between resources. The d= raft > also updates all resource types and interface descriptions to the -14 ver= sion > of CoRE Link Format. >=20 > Try it out - comments welcome! >=20 > Zach >=20 > Begin forwarded message: >=20 > > From: internet-drafts@ietf.org > > Date: July 11, 2012 2:42:56 PM GMT+03:00 > > To: zach@sensinode.com > > Cc: matthieu.vial@schneider-electric.com > > Subject: New Version Notification for > > draft-shelby-core-interfaces-03.txt > > > > > > A new version of I-D, draft-shelby-core-interfaces-03.txt > > has been successfully submitted by Zach Shelby and posted to the IETF > > repository. > > > > Filename: draft-shelby-core-interfaces > > Revision: 03 > > Title: CoRE Interfaces > > Creation date: 2012-07-11 > > WG ID: Individual Submission > > Number of pages: 24 > > URL: http://www.ietf.org/internet-drafts/draft-shelby-core- > interfaces-03.txt > > Status: http://datatracker.ietf.org/doc/draft-shelby-core-inte= rfaces > > Htmlized: http://tools.ietf.org/html/draft-shelby-core-interface= s-03 > > Diff: http://tools.ietf.org/rfcdiff?url2=3Ddraft-shelby-core= -interfaces-03 > > > > Abstract: > > This document defines well-known REST interface descriptions for > > Batch, Sensor, Parameter and Actuator types for use in contrained web > > servers using the CoRE Link Format. A short reference is provided > > for each type that can be efficiently included in the interface > > description attribute of the CoRE Link Format. These descriptions > > are intended to be for general use in resource designs or for > > inclusion in more specific interface profiles. In addition, this > > document defines the concepts of Function Set and Binding. The > > former is the basis element to create RESTful profiles and the latter > > helps the configuration of links between resources located on one or > > more endpoints. > > > > > > > > > > The IETF Secretariat >=20 > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://www.sensinode.com > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From robert.cragie@gridmerge.com Wed Jul 11 10:01:26 2012 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 EC90A11E80EF; Wed, 11 Jul 2012 10:01:26 -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 SZf7CtXPEWkl; Wed, 11 Jul 2012 10:01:26 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by ietfa.amsl.com (Postfix) with ESMTP id 6433211E80C0; Wed, 11 Jul 2012 10:01:25 -0700 (PDT) Received: from client-82-26-85-222.pete-bam-1.adsl.virginmedia.com ([82.26.85.222] helo=[192.168.0.2]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) id 1Sp0IU-0004lP-Ad; Wed, 11 Jul 2012 18:01:54 +0100 Message-ID: <4FFDB24F.8060600@gridmerge.com> Date: Wed, 11 Jul 2012 18:05:19 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: tls@ietf.org, core References: <1CA8C4CB-1FD8-4498-9988-41B6334F58FD@gmx.net> In-Reply-To: <1CA8C4CB-1FD8-4498-9988-41B6334F58FD@gmx.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070204090907070709000705" X-Authenticated-As: robert.cragie@gridmerge.com Subject: Re: [core] [TLS] draft-ietf-tls-oob-pubkey: The Open Issue 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: Wed, 11 Jul 2012 17:01:27 -0000 This is a cryptographically signed message in MIME format. --------------ms070204090907070709000705 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Hannes, I think it would be easier to understand if the actual extensions were=20 specified in the message diagrams. This seems to reveal a problem in the = third use case (hybrid scenario), as it is not possible for the client=20 to use a different certificate type to that selected by the server=20 according to the=20 http://tools.ietf.org/html/draft-ietf-tls-oob-pubkey-03/RFC 6091. Robert I) Server uses Raw Public Keys (client authentication happens at some=20 other layer) (the DANE use case) client_hello, cert-type=3D(RawPublicKey, X.509) -> // (1) <- server_hello, cert-type=3DRawPublicKey, // (2) certificate, // (3) server_key_exchange, server_hello_done // (4) client_key_exchange, change_cipher_spec, finished -> <- change_cipher_spec, finished Application Data <-------> Application Data (1) Client supports both, preferring RawPublicKey. Alternatively,=20 cert-type=3D(RawPublicKey), i.e. client supports onlyRawPublicKey (2) Server supports and chooses RawPublicKey (3) With raw public key (SPKI) inside (4) Server knows OOB that it doesn't need Client certificate so doesn't=20 send certificate_request (security policy for the system) II) Client and Server use Raw Public Keys (the smart object use case -=20 CORE working group) client_hello, cert-type=3D(RawPublicKey) -> // (1) <- server_hello, cert-type=3DRawPublicKey, // (2) certificate, // (3) server_key_exchange, certificate_request, // (4) server_hello_done certificate, // (5) client_key_exchange, certificate_verify, // (6) change_cipher_spec, finished -> <- change_cipher_spec, finished Application Data <-------> Application Data (1) Client supports only RawPublicKey (2) Server supports only RawPublicKey (3) With raw public key (SPKI) inside (4) Server knows OOB that it needs Client certificate so sends=20 certificate_request (security policy for the system) (5) With raw public key (SPKI)inside (6) Implies signing ability of raw public key III) Hybrid Scenario (the OAuth Holder-of-the-Key Use case) client_hello, cert-type=3D(RawPublicKey, X.509) -> // (1) <- server_hello, cert-type=3DX.509 // (2) certificate, // (3) server_key_exchange, certificate_request, // (4) server_hello_done certificate, // (5) client_key_exchange, certificate_verify, // (6) change_cipher_spec, finished -> <- change_cipher_spec, finished Application Data <-------> Application Data (1) Client supports both, preferring RawPublicKey (2) Server supports and chooses X.509 (3) With X.509 cert. (4) Server knows OOB that it needs Client certificate so sends=20 certificate_request(security policy for the system). **** Note it could=20 be possible to request a RawPublicKey at this point. It is not clear=20 that CertificateRequest supports requesting of a SPKI **** (5) With raw public key(SPKI)inside *** This doesn't seem possible as=20 X.509 has been chosen **** (6) Implies signing ability of raw public key On 11/07/2012 11:56 AM, Hannes Tschofenig wrote: > Hi all, > > draft-ietf-tls-oob-pubkey specifies a new TLS certificate type for exch= anging raw public keys in Transport Layer Security (TLS) and Datagram Tra= nsport Layer Security (DTLS) for use with out-of-band public key validati= on. > > Here is the latest draft: > http://tools.ietf.org/html/draft-ietf-tls-oob-pubkey-03 > > I would be great to get your feedback on an open issue that concerns th= e semantic of the exchange. I believe there are three use cases we would = like to support with this work. Below, I provide high level message excha= nges to explain those: > > I) Server uses Raw Public Keys (client authentication happens at some o= ther layer) > (the DANE use case) > > client_hello, > raw-public-key-indicator=3D"Server, when you send me your raw public ke= y? I support this out-of-band key validation using DANE." -> > > <- server_hello, > raw-public-key=3D"OK. The certificate st= ructure below contains my raw public key.", > certificate, // with raw public key insi= de > server_key_exchange, > server_hello_done > > client_key_exchange, > change_cipher_spec, > finished -> > > <- change_cipher_spec, > finished > > Application Data <-------> Application Data > > > II) Client and Server use Raw Public Keys > (the smart object use case - CORE working group) > > client_hello, > raw-public-key=3D"Server, please send me your raw public key and I will= then send you mine. Are you OK processing my raw public key for client a= uthentication?" -> > > <- server_hello, > raw-public-key=3D"Below you find my raw = public key and please send me your raw public key for client > authentication", > certificate, // raw public key > server_key_exchange, > certificate_request, > server_hello_done > > certificate, // with client's raw public key > client_key_exchange, > certificate_verify, > change_cipher_spec, > finished -> > > <- change_cipher_spec, > finished > > Application Data <-------> Application Data > > > II) Hybrid Scenario > (the OAuth Holder-of-the-Key Use case) > > client_hello, > raw-public-key=3D"I would like to use my raw public key for client auth= entication with OAuth. I also process X.509 for server-side authenticatio= n." -> > > <- server_hello, > raw-public-key=3D"Please send me your ra= w public key. I use X.509 for server-side authentication", > certificate, // with X.509 cert. > server_key_exchange, > certificate_request, > server_hello_done > > certificate, // with client's raw public key > client_key_exchange, > certificate_verify, > change_cipher_spec, > finished -> > > <- change_cipher_spec, > finished > > Application Data <-------> Application Data > -------- > > QUESTION: Are these all the message exchanges we need? Are there some p= roblems with the exchanges? > > Ciao > Hannes > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --------------ms070204090907070709000705 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP3jCC BIowggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w NTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMC VVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l dHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVN NRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQy lbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXq vgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6 hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu 9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0G A1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/ BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9BZGRU cnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8ubmV0L0Fk ZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyispgCi 54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0 g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHd WTBK322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftz Mizpm4QkLdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsy XEFs/vVdoOr/0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIFGjCCBAKgAwIBAgIQbRnqpxlPajMi 5iIyeqpx3jANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcw FQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3Jr MSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VS Rmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMTA0MjgwMDAwMDBa Fw0yMDA1MzAxMDQ4MzhaMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5 MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoSEW0tXmNReL4uk4UDIo1NY X2Zl8TJO958yfVXQeExVt0KU4PkncQfFxmmkuTLE8UAakMwnVmJ/F7Vxaa7lIBvky2NeYMqi QfZq4aP/uN8fSG1lQ4wqLitjOHffsReswtqCAtbUMmrUZ28gE49cNfrlVICv2HEKHTcKAlBT bJUdqRAUtJmVWRIx/wmi0kzcUtve4kABW0ho3cVKtODtJB86r3FfB+OsvxQ7sCVxaD30D9YX WEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJkJpFOpZIP/+CxYP0ab2hRmWONGoulzEKbm30i Y9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IBSzCCAUcwHwYDVR0jBBgwFoAUiYJnfcSd JnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MA4GA1UdDwEB /wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0gADBYBgNVHR8E UTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJzdC1DbGll bnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRoMGYwPQYIKwYBBQUH MAKGMWh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENsaWVudF9DQS5jcnQw JQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEFBQAD ggEBAIXWvnhXVW0zf0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtzbj7pJnzmTJjBMCjf y/tCPKElPgp11tA9OYZm0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqTecr+4pEeVnSy+I3T 4ENyG+2P/WA5IEf7i686ZUg8mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPNM1+b0L1garM7/vrU yTo8H+2b/5tJM75CKTmD7jNpLoKdRU2oadqAGx490hpdfEeZpZsIbRKZhtZdVwcbpzC+S0lE uJB+ytF5OOu0M/qgOl0mWJ5hVRi0IdWZ1eBDQEIwvuql55TSsP7zdfl/bucwggYuMIIFFqAD AgECAhBcMVDbxC2oy5hyHl/adO9mMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEb MBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTExMDkwMjAwMDAwMFoXDTE0MDkwMTIzNTk1 OVowggE3MQswCQYDVQQGEwJHQjEQMA4GA1UEERMHV0Y0IDRXQTEXMBUGA1UECBMOV2VzdCBZ b3Jrc2hpcmUxEjAQBgNVBAcTCVdha2VmaWVsZDEUMBIGA1UECRMLR3JhbmdlIE1vb3IxHzAd BgNVBAkTFjg5IEdyZWVuZmllbGQgQ3Jlc2NlbnQxFzAVBgNVBAoTDkdyaWRtZXJnZSBMdGQu MTQwMgYDVQQLEytJc3N1ZWQgdGhyb3VnaCBHcmlkbWVyZ2UgTHRkLiBFLVBLSSBNYW5hZ2Vy MR8wHQYDVQQLExZDb3Jwb3JhdGUgU2VjdXJlIEVtYWlsMRYwFAYDVQQDEw1Sb2JlcnQgQ3Jh Z2llMSowKAYJKoZIhvcNAQkBFhtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtxOGq8t5ZTVDVkmadv7ZRBLA5ApaiTcDUzCTn zYB2/BoBDIEWWI/InSRcmq3A0Ghm+T7dYmvRADllGv4nTHexdWlzFp2iM/Yc3PLWCyAO0gYb yW2hTi+ZfUDwFOU4hRP4+Dyn9tKu7FXS/PQJHyGjaGxHRmLm9T6tAo2ZuC59uRaGVCcwRiOS d6axwtB/DVhnP3S1rrt2g0O6MXLr5fojToemO52AxjHxt2w1LnFUUXC4EDV6o1Ctr7EvOEI5 5f088H/Mrryp02GueLdY9gb0SFK3gPOT7EjP2GPvCtRkhVcNM+xjyptRIFWnCbMjmUIc+DO6 sfU4rtbCCkNKyXmnAgMBAAGjggHVMIIB0TAfBgNVHSMEGDAWgBR6E04AdFvGeGNkJ8Ev4qBb vHnFezAdBgNVHQ4EFgQUEI5c0f6UObxT2DLdvdtG+vG8qCswDgYDVR0PAQH/BAQDAgWgMAwG A1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMEYGA1UdIAQ/MD0w OwYMKwYBBAGyMQECAQMFMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u ZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E T0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEB BHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50 QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMCYGA1UdEQQfMB2BG3JvYmVydC5jcmFnaWVAZ3JpZG1lcmdl LmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAPpv87QuQ9q+RHhmeirGDQB3szd24Obi7N+uVfh5y CrnoJx3B37dNrLPsTB6PfTChUyZMqQD80pFoJ3TBUz3yx4X+hmNco7ujVIfbuKBGcZJaMKhZ ex3AkZ9ltie9wgiGGzEmgI81t5JHsLQ8AUMqw/fGsnIwcyWMgmyhFtm79+dg3IVaH05d/t9g k4aYoMoCFJptQZ+Fju6a9T139hOqjTZDpjMLt3jM80bVrvkC4dIRyF/oZ0qrJwbfwjnL2OUN ph9eymhLc+VM0Ih5k41s5IxmB+2c0RUqr5JbK0WrIb/z53Cmb9rXYox7HknyIfBpQqP77Y7a sAU2MMOpel4RijGCBBkwggQVAgEBMIGoMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0Eg TGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj dXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9mMAkGBSsOAwIaBQCgggJFMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDcxMTE3MDUxOVowIwYJKoZI hvcNAQkEMRYEFJ4S1D5cdqo6XurR1dWZZRIiQga1MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZI AWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZI hvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgbkGCSsGAQQBgjcQBDGBqzCBqDCB kzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMH U2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQXDFQ28QtqMuYch5f 2nTvZjCBuwYLKoZIhvcNAQkQAgsxgauggagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0ECEFwxUNvELajLmHIeX9p072YwDQYJKoZIhvcNAQEBBQAEggEAFoRF OMeJ91l4AYrJANaBPfziTQytmjiReeqS0Ufm7Yc8wGyDuYXXWhC6WeHl2V3fGFYStRdNL+ih ee7D824wSVKv4pcdFCn2El8/Rknk8YjkPbSGxztF+9sMHNi2VS+AE6TZtBQ5z62ure2NucuO 8C5qa6CUVaFX6aMhzc6lqkXboY9/U05Tn4hSGv3yua2Fuoz1SmA2legBkt3IOdOr85Do2//0 Zmj96Up+EHNGsurS+3QWkHk8NeGMPiyVX5wwRHVU3CVw4MNfLfF9fhFLgawAJyrxYfOPCIKN R4TJ+UGqaHWTphZzBkr0fmkyEiCyanBsOGc5aNisoc2BGtbOwgAAAAAAAA== --------------ms070204090907070709000705-- From esko.dijk@philips.com Thu Jul 12 00:46:04 2012 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 5164221F86D4 for ; Thu, 12 Jul 2012 00:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.854 X-Spam-Level: X-Spam-Status: No, score=-2.854 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, HTML_MESSAGE=0.001, 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 SPc4q6GqPiWi for ; Thu, 12 Jul 2012 00:46:03 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id 3871D21F872A for ; Thu, 12 Jul 2012 00:46:03 -0700 (PDT) Received: from mail20-ch1-R.bigfish.com (10.43.68.240) by CH1EHSOBE017.bigfish.com (10.43.70.67) with Microsoft SMTP Server id 14.1.225.23; Thu, 12 Jul 2012 07:46:34 +0000 Received: from mail20-ch1 (localhost [127.0.0.1]) by mail20-ch1-R.bigfish.com (Postfix) with ESMTP id 95251200313; Thu, 12 Jul 2012 07:46:34 +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: -34 X-BigFish: VPS-34(zz217bL15d6O9251Jc85fh14ffIzz1202hzz1033IL8275dhz2dh2a8h668h839hd25hf0ah107ah) Received: from mail20-ch1 (localhost.localdomain [127.0.0.1]) by mail20-ch1 (MessageSwitch) id 1342079192697187_28697; Thu, 12 Jul 2012 07:46:32 +0000 (UTC) Received: from CH1EHSMHS030.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.250]) by mail20-ch1.bigfish.com (Postfix) with ESMTP id 9EA4D4E0047; Thu, 12 Jul 2012 07:46:32 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CH1EHSMHS030.bigfish.com (10.43.70.30) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 12 Jul 2012 07:46:31 +0000 Received: from 011-DB3MPN2-082.MGDPHG.emi.philips.com ([169.254.2.136]) by 011-DB3MMR1-009.MGDPHG.emi.philips.com ([10.128.28.48]) with mapi id 14.01.0355.003; Thu, 12 Jul 2012 08:46:34 +0100 From: "Dijk, Esko" To: Bert Greevenbosch , "core@ietf.org" Thread-Topic: Upload of draft for "BlockMinimumTime" option Thread-Index: Ac1dlXIgejAMynRjREWUOXSbOxYSAACbF9TA Date: Thu, 12 Jul 2012 07:46:34 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618A9D191@011-DB3MPN2-082.MGDPHG.emi.philips.com> References: <46A1DF3F04371240B504290A071B4DB62905EDFF@szxeml509-mbs> In-Reply-To: <46A1DF3F04371240B504290A071B4DB62905EDFF@szxeml509-mbs> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.101] Content-Type: multipart/alternative; boundary="_000_031DD135F9160444ABBE3B0C36CED618A9D191011DB3MPN2082MGDP_" MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: Re: [core] Upload of draft for "BlockMinimumTime" option 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, 12 Jul 2012 07:46:04 -0000 --_000_031DD135F9160444ABBE3B0C36CED618A9D191011DB3MPN2082MGDP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Bert, I miss a motivation (or use cases) in this draft why BlockMinimumTime is ne= eded and why other approaches are not good enough. E.g., the server can just wait 200 or 300 ms (times from Examples section 7= ) before sending its response to the client achieving similar congestion co= ntrol and overload prevention. regards, Esko From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Ber= t Greevenbosch Sent: Monday 9 July 2012 7:41 To: core@ietf.org Subject: [core] Upload of draft for "BlockMinimumTime" option Hello all, I have just upload a draft that defines the "BlockMinimumTime" option: http://datatracker.ietf.org/doc/draft-greevenbosch-core-block-minimum-time The option allows the server and client to negotiate the speed in which the= client sends requests in a block transaction. Comments are welcome! Best regards, Bert ________________________________ 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. --_000_031DD135F9160444ABBE3B0C36CED618A9D191011DB3MPN2082MGDP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Bert,

 

I miss a motivation (o= r use cases) in this draft why BlockMinimumTime is needed and why other approa= ches are not good enough.

E.g., the server can just wait = 200 or 300 ms (times from Examples section 7) before sending its response t= o the client achieving similar congestion control and overload prevention.<= /span>

 

regards,

Esko

 

From: core-b= ounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Bert Greevenbosch
Sent: Monday 9 July 2012 7:41
To: core@ietf.org
Subject: [core] Upload of draft for "BlockMinimumTime" opt= ion

 

Hello all,

 

I have just upload a draft that= defines the "BlockMinimumTime" option:

http://datatracker.ietf.org/doc= /draft-greevenbosch-core-block-minimum-time

 

The option allows the server an= d client to negotiate the speed in which the client sends requests in a blo= ck transaction.

 

Comments are welcome!

 

Best regards,

Bert


The information contained in= this message may be confidential and legally protected under applicable la= w. 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 i= s strictly prohibited and may be unlawful. If you are not the intended reci= pient, please contact the sender by return e-mail and destroy all copies of= the original message.
 --_000_031DD135F9160444ABBE3B0C36CED618A9D191011DB3MPN2082MGDP_-- From hannes.tschofenig@gmx.net Thu Jul 12 00:54:21 2012 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 42FBD21F875E for ; Thu, 12 Jul 2012 00:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.438 X-Spam-Level: X-Spam-Status: No, score=-102.438 tagged_above=-999 required=5 tests=[AWL=0.161, 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 824m11ME5OIx for ; Thu, 12 Jul 2012 00:54:21 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id A835221F8738 for ; Thu, 12 Jul 2012 00:54:18 -0700 (PDT) Received: (qmail invoked by alias); 12 Jul 2012 07:54:49 -0000 Received: from unknown (EHLO [10.255.128.232]) [194.251.119.201] by mail.gmx.net (mp070) with SMTP; 12 Jul 2012 09:54:49 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18netw6/Dsneo97R8OqyhzcBJ8fgqRo00fHbLH39b KjbMRCslVls43p From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Jul 2012 10:54:48 +0300 Message-Id: <213AE838-274D-4809-B841-CCCC51C7B3CD@gmx.net> To: tls@ietf.org, IETF CoRE Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: OAuth WG Subject: [core] draft-ietf-tls-oob-pubkey: My summary 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, 12 Jul 2012 07:54:21 -0000 Hi Erk, Hi Robert, Hi Nikos,=20 thanks for your quick response. Here is an attempt to summarize your = input.=20 -------- I use three types of indications in the message exchange below for = improved clarity, namely:=20 (a) 'cert-receive=3D(value-1, value-2, ..., value-n)' with the meaning: = "I accept certificate of the following types (value-1, ..., value-n) if = you send them to me." The list is ordered by preference.=20 (b) 'cert-send=3D(value-1, value-2, ..., value-n)' with the meaning: "I = could send you certificate of the following types (value-1, ..., = value-n) if you ask." The list is ordered by preference.=20 (c) cert-info=3D(value) with the meaning: "The certificate payload in = this message contains a certificate of the following type".=20 I) Server uses Raw Public Keys (client authentication happens at some = other layer) (the DANE use case) client_hello, cert-receive=3D(Raw, X.509) // (1) cert-send=3D() -> // (2) <- server_hello, cert-info=3D(Raw),// (3) certificate, // (4) server_key_exchange, server_hello_done=20 client_key_exchange, change_cipher_spec, finished -> <- change_cipher_spec, finished Application Data <-------> Application Data Legend:=20 (1) Client accepts to receive two types of certificates, preferring raw = public keys. (2) The client does not have a raw public key nor an X.509 certificate = for client authentication.=20 (3) The server decides to sends his raw public key and indicates this in = the cert-info field.=20 (4) The certificate payload contains the raw public key.=20 II) Client and Server use Raw Public Keys (the smart object use case - = CORE working group) client_hello, cert-receive=3D(Raw) // (1) cert-send=3D(Raw) -> // (2) <- server_hello, cert-info=3D(Raw),// (3) certificate, // (4) certificate_request, // (5) cert-receive=3D(Raw) // (6) server_key_exchange, server_hello_done=20 cert-info=3D(Raw), // (7) certificate, // (8) client_key_exchange, change_cipher_spec, finished -> <- change_cipher_spec, finished Application Data <-------> Application Data Legend:=20 (1) Client accepts to receive raw public keys. (2) The client does have a raw public key for client authentication.=20 (3) The server decides to sends his raw public key and indicates this in = the cert-info field.=20 (4) The certificate payload contains the raw public key.=20 (5) The server wants to use client authentication and and sends a = cert-request.=20 (6) The certificate request asks for a certificate of type 'raw' = (knowing that the client supports it from (2)).=20 (7) The client indicates that the certificate payload contains a raw = public key (8) Here is the payload of the certificate itself.=20 III) Hybrid Scenario (the OAuth Holder-of-the-Key Use case) client_hello, cert-receive=3D(X.509, Raw) // (1) cert-send=3D(Raw) -> // (2) <- server_hello, cert-info=3D(X.509),// (3) certificate, // (4) certificate_request, // (5) cert-receive=3D(Raw) // (6) server_key_exchange, server_hello_done=20 cert-info=3D(Raw), // (7) certificate, // (8) client_key_exchange, change_cipher_spec, finished -> <- change_cipher_spec, finished Application Data <-------> Application Data Legend:=20 (1) Client accepts to receive X.509 certs and raw public keys, in this = order of preference. (Could also be X.509 only in this example) (2) The client does have a raw public key for client authentication.=20 (3) The server decides to sends his X.509 cert and indicates this in the = cert-info field.=20 (4) The certificate payload contains the X.509 cert.=20 (5) The server wants to use client authentication and sends a = cert-request.=20 (6) The certificate request asks for a certificate of type 'raw' = (knowing that the client supports it from (2)).=20 (7) The client indicates that the certificate payload contains a raw = public key. (8) Here is the payload of the certificate itself.=20 =20 -------- Do these indications clarify the semantic? I personally believe so.=20 Ciao Hannes From matthieu.vial@non.schneider-electric.com Thu Jul 12 01:20:59 2012 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 5BA4C21F87A4; Thu, 12 Jul 2012 01:20: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 2R36MzfKyfDj; Thu, 12 Jul 2012 01:20:57 -0700 (PDT) Received: from mailX01.eud.schneider-electric.com (mailx01.eud.schneider-electric.com [205.167.7.35]) by ietfa.amsl.com (Postfix) with ESMTP id A50B721F8709; Thu, 12 Jul 2012 01:20:56 -0700 (PDT) Received: from ateui03.schneider-electric.com ([10.198.21.36]) by mailX01.eud.schneider-electric.com with ESMTP id 2012071210212795-187547 ; Thu, 12 Jul 2012 10:21:27 +0200 In-Reply-To: <55877B3AFB359744BA0F2140E36F52B5142A259D@MBX10.d.ethz.ch> To: "Kovatsch Matthias" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 From: matthieu.vial@non.schneider-electric.com Message-ID: Date: Thu, 12 Jul 2012 10:21:29 +0200 X-MIMETrack: Serialize by Router on ATEUI03.Schneider-Electric.com/T/SVR/Schneider at 12/07/2012 10:21:27, Serialize complete at 12/07/2012 10:21:27, Itemize by SMTP Server on AXEU1OUT.schneider-electric.com/X/SVR/SEIxtra at 12/07/2012 10:21:27, Serialize by Router on AXEU1OUT.schneider-electric.com/X/SVR/SEIxtra at 12/07/2012 10:21:29, Serialize complete at 12/07/2012 10:21:29 Content-Type: text/plain; charset="US-ASCII" Cc: core-bounces@ietf.org, "core@ietf.org WG" Subject: Re: [core] Fwd: New Version Notification for draft-shelby-core-interfaces-03.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: Thu, 12 Jul 2012 08:20:59 -0000 Hi Matthias Thanks for your feedback. See my comments inline. >It implies that both ends provide resources, i.e., also Web clients expose their internal state as resources. We aim at providing a solution to connect sensor resources (or more generally producer resources) with actuator resources (consumers). >This sounds a little odd to me... bindings also exist when a client does not have server-functionality. In that case you need an out-of-band channel to configure bindings on a client-only endpoint from a third-party. And if the client can automatically configure itself using resource/service discovery, you also need an OOB mechanism to publish this configuration. With CoRE bindings you just use the web protocol. If you don't need to publish or configure your bindings then you don't need a binding representation. >Maybe I am just missing an introduction that says that it is best when clients export their configuration as resources. >But, still I feel this mismatch of links between resources versus client-server interaction. Actually I assume that most endpoints are client and server (except sleeping endpoints but in that case a mirror server is client/server on behalf of the SEP). So the client/server role is not so important for the abstract binding concept (it is for a specific binding method). Matthieu From robert.cragie@gridmerge.com Thu Jul 12 05:53:44 2012 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 2273521F87C8; Thu, 12 Jul 2012 05:53:44 -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 GT9ctxycE2uT; Thu, 12 Jul 2012 05:53:43 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by ietfa.amsl.com (Postfix) with ESMTP id 72D4221F8701; Thu, 12 Jul 2012 05:53:42 -0700 (PDT) Received: from client-82-26-85-222.pete-bam-1.adsl.virginmedia.com ([82.26.85.222] helo=[192.168.0.2]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) id 1SpIuJ-0001wS-CB; Thu, 12 Jul 2012 13:54:13 +0100 Message-ID: <4FFEC9C3.8050108@gridmerge.com> Date: Thu, 12 Jul 2012 13:57:39 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: tls@ietf.org, core References: <213AE838-274D-4809-B841-CCCC51C7B3CD@gmx.net> In-Reply-To: <213AE838-274D-4809-B841-CCCC51C7B3CD@gmx.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090709070801060205030409" X-Authenticated-As: robert.cragie@gridmerge.com Subject: Re: [core] [TLS] draft-ietf-tls-oob-pubkey: My summary 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: Thu, 12 Jul 2012 12:53:44 -0000 This is a cryptographically signed message in MIME format. --------------ms090709070801060205030409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Hannes, The only one thing I am not sure about is the necessity for cert-send.=20 This is because traditionally the server makes the decision on whether=20 to request a certificate from the client and would not know a priori=20 whether the client supports it. That's not to say it isn't a good idea=20 though. On that basis, I would modify the exchange slightly - see below. Robert I use three types of indications in the message exchange below for=20 improved clarity, namely: (a) 'cert-receive=3D(value-1, value-2, ..., value-n)' with the meaning: "= I=20 accept certificate of the following types (value-1, ..., value-n) if you = send them to me." The list is ordered by preference. (b) 'cert-info=3Dvalue' with the meaning: "The certificate payload in thi= s=20 message contains a certificate of the following type". I) Server uses Raw Public Keys (client authentication happens at some=20 other layer) (the DANE use case) client_hello, cert-receive=3D(Raw, X.509) -> // (1) <- server_hello, cert-info=3DRaw, // (2) certificate, // (3) server_key_exchange, server_hello_done client_key_exchange, change_cipher_spec, finished -> <- change_cipher_spec, finished Application Data <-------> Application Data Legend: (1) The client accepts reception of X.509 certs and raw public keys,=20 preferring raw public keys. (2) The server decides to sends his raw public key and indicates this in = the cert-info field. (3) The server certificate payload contains the raw public key. II) Client and Server use Raw Public Keys (the smart object use case -=20 CORE working group) client_hello, cert-receive=3D(Raw) -> // (1) <- server_hello, cert-info=3DRaw,// (2) certificate, // (3) certificate_request, // (4) cert-receive=3D(Raw) // (5) server_key_exchange, server_hello_done cert-info=3DRaw, // (6) certificate, // (7) client_key_exchange, change_cipher_spec, finished -> <- change_cipher_spec, finished Application Data <-------> Application Data Legend: (1) The client accepts reception of raw public keys. (2) The server decides to sends his raw public key and indicates this in = the cert-info field. (3) The server certificate payload contains the raw public key. (4) The server wants to use client authentication and and sends a=20 certificate-request. (5) The server accepts reception of raw public keys. (6) The client indicates that the certificate payload contains a raw=20 public key. (7) The client certificate payload contains the raw public key. III) Hybrid Scenario (the OAuth Holder-of-the-Key Use case) client_hello, cert-receive=3D(X.509, Raw) -> // (1) <- server_hello, cert-info=3DX.509,// (2) certificate, // (3) certificate_request, // (4) cert-receive=3D(Raw) // (5) server_key_exchange, server_hello_done cert-info=3DRaw, // (6) certificate, // (7) client_key_exchange, change_cipher_spec, finished -> <- change_cipher_spec, finished Application Data <-------> Application Data Legend: (1) Client accepts to receive X.509 certs and raw public keys,=20 preferring X.509 certs. (Could also be X.509 only in this example) (2) The server decides to sends his X.509 cert and indicates this in the = cert-info field. (3) The server certificate payload contains the X.509 cert. (4) The server wants to use client authentication and sends a=20 certificate-request. (5) The server accepts reception of raw public keys. (6) The client indicates that the certificate payload contains a raw=20 public key. (7) The client certificate payload contains the raw public key. On 12/07/2012 8:54 AM, Hannes Tschofenig wrote: > Hi Erk, Hi Robert, Hi Nikos, > > thanks for your quick response. Here is an attempt to summarize your i= nput. > > -------- > > I use three types of indications in the message exchange below for impr= oved clarity, namely: > > (a) 'cert-receive=3D(value-1, value-2, ..., value-n)' with the meaning:= "I accept certificate of the following types (value-1, ..., value-n) if = you send them to me." The list is ordered by preference. > > (b) 'cert-send=3D(value-1, value-2, ..., value-n)' with the meaning: "I= could send you certificate of the following types (value-1, ..., value-= n) if you ask." The list is ordered by preference. > > (c) cert-info=3D(value) with the meaning: "The certificate payload in t= his message contains a certificate of the following type". > > I) Server uses Raw Public Keys (client authentication happens at some o= ther layer) (the DANE use case) > > client_hello, > cert-receive=3D(Raw, X.509) // (1) > cert-send=3D() -> // (2) > > <- server_hello, > cert-info=3D(Raw),// (3) > certificate, // (4) > server_key_exchange, > server_hello_done > > client_key_exchange, > change_cipher_spec, > finished -> > > <- change_cipher_spec, > finished > > Application Data <-------> Application Data > > Legend: > > (1) Client accepts to receive two types of certificates, preferring raw= public keys. > (2) The client does not have a raw public key nor an X.509 certificate = for client authentication. > (3) The server decides to sends his raw public key and indicates this i= n the cert-info field. > (4) The certificate payload contains the raw public key. > > II) Client and Server use Raw Public Keys (the smart object use case - = CORE working group) > > > client_hello, > cert-receive=3D(Raw) // (1) > cert-send=3D(Raw) -> // (2) > > <- server_hello, > cert-info=3D(Raw),// (3) > certificate, // (4) > certificate_request, // (5) > cert-receive=3D(Raw) // (6) > server_key_exchange, > server_hello_done > > cert-info=3D(Raw), // (7) > certificate, // (8) > client_key_exchange, > change_cipher_spec, > finished -> > > <- change_cipher_spec, > finished > > Application Data <-------> Application Data > > > Legend: > > (1) Client accepts to receive raw public keys. > (2) The client does have a raw public key for client authentication. > (3) The server decides to sends his raw public key and indicates this i= n the cert-info field. > (4) The certificate payload contains the raw public key. > (5) The server wants to use client authentication and and sends a cert-= request. > (6) The certificate request asks for a certificate of type 'raw' (knowi= ng that the client supports it from (2)). > (7) The client indicates that the certificate payload contains a raw pu= blic key > (8) Here is the payload of the certificate itself. > > III) Hybrid Scenario (the OAuth Holder-of-the-Key Use case) > > client_hello, > cert-receive=3D(X.509, Raw) // (1) > cert-send=3D(Raw) -> // (2) > > <- server_hello, > cert-info=3D(X.509),// (3) > certificate, // (4) > certificate_request, // (5) > cert-receive=3D(Raw) // (6) > server_key_exchange, > server_hello_done > > cert-info=3D(Raw), // (7) > certificate, // (8) > client_key_exchange, > change_cipher_spec, > finished -> > > <- change_cipher_spec, > finished > > Application Data <-------> Application Data > > Legend: > > (1) Client accepts to receive X.509 certs and raw public keys, in this = order of preference. (Could also be X.509 only in this example) > (2) The client does have a raw public key for client authentication. > (3) The server decides to sends his X.509 cert and indicates this in th= e cert-info field. > (4) The certificate payload contains the X.509 cert. > (5) The server wants to use client authentication and sends a cert-requ= est. > (6) The certificate request asks for a certificate of type 'raw' (knowi= ng that the client supports it from (2)). > (7) The client indicates that the certificate payload contains a raw pu= blic key. > (8) Here is the payload of the certificate itself. > =20 > -------- > > Do these indications clarify the semantic? > I personally believe so. > > Ciao > Hannes > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --------------ms090709070801060205030409 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP3jCC BIowggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w NTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMC VVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l dHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVN NRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQy lbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXq vgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6 hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu 9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0G A1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/ BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9BZGRU cnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8ubmV0L0Fk ZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyispgCi 54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0 g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHd WTBK322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftz Mizpm4QkLdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsy XEFs/vVdoOr/0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIFGjCCBAKgAwIBAgIQbRnqpxlPajMi 5iIyeqpx3jANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcw FQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3Jr MSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VS Rmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMTA0MjgwMDAwMDBa Fw0yMDA1MzAxMDQ4MzhaMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5 MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoSEW0tXmNReL4uk4UDIo1NY X2Zl8TJO958yfVXQeExVt0KU4PkncQfFxmmkuTLE8UAakMwnVmJ/F7Vxaa7lIBvky2NeYMqi QfZq4aP/uN8fSG1lQ4wqLitjOHffsReswtqCAtbUMmrUZ28gE49cNfrlVICv2HEKHTcKAlBT bJUdqRAUtJmVWRIx/wmi0kzcUtve4kABW0ho3cVKtODtJB86r3FfB+OsvxQ7sCVxaD30D9YX WEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJkJpFOpZIP/+CxYP0ab2hRmWONGoulzEKbm30i Y9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IBSzCCAUcwHwYDVR0jBBgwFoAUiYJnfcSd JnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MA4GA1UdDwEB /wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0gADBYBgNVHR8E UTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJzdC1DbGll bnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRoMGYwPQYIKwYBBQUH MAKGMWh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENsaWVudF9DQS5jcnQw JQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEFBQAD ggEBAIXWvnhXVW0zf0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtzbj7pJnzmTJjBMCjf y/tCPKElPgp11tA9OYZm0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqTecr+4pEeVnSy+I3T 4ENyG+2P/WA5IEf7i686ZUg8mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPNM1+b0L1garM7/vrU yTo8H+2b/5tJM75CKTmD7jNpLoKdRU2oadqAGx490hpdfEeZpZsIbRKZhtZdVwcbpzC+S0lE uJB+ytF5OOu0M/qgOl0mWJ5hVRi0IdWZ1eBDQEIwvuql55TSsP7zdfl/bucwggYuMIIFFqAD AgECAhBcMVDbxC2oy5hyHl/adO9mMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEb MBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTExMDkwMjAwMDAwMFoXDTE0MDkwMTIzNTk1 OVowggE3MQswCQYDVQQGEwJHQjEQMA4GA1UEERMHV0Y0IDRXQTEXMBUGA1UECBMOV2VzdCBZ b3Jrc2hpcmUxEjAQBgNVBAcTCVdha2VmaWVsZDEUMBIGA1UECRMLR3JhbmdlIE1vb3IxHzAd BgNVBAkTFjg5IEdyZWVuZmllbGQgQ3Jlc2NlbnQxFzAVBgNVBAoTDkdyaWRtZXJnZSBMdGQu MTQwMgYDVQQLEytJc3N1ZWQgdGhyb3VnaCBHcmlkbWVyZ2UgTHRkLiBFLVBLSSBNYW5hZ2Vy MR8wHQYDVQQLExZDb3Jwb3JhdGUgU2VjdXJlIEVtYWlsMRYwFAYDVQQDEw1Sb2JlcnQgQ3Jh Z2llMSowKAYJKoZIhvcNAQkBFhtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtxOGq8t5ZTVDVkmadv7ZRBLA5ApaiTcDUzCTn zYB2/BoBDIEWWI/InSRcmq3A0Ghm+T7dYmvRADllGv4nTHexdWlzFp2iM/Yc3PLWCyAO0gYb yW2hTi+ZfUDwFOU4hRP4+Dyn9tKu7FXS/PQJHyGjaGxHRmLm9T6tAo2ZuC59uRaGVCcwRiOS d6axwtB/DVhnP3S1rrt2g0O6MXLr5fojToemO52AxjHxt2w1LnFUUXC4EDV6o1Ctr7EvOEI5 5f088H/Mrryp02GueLdY9gb0SFK3gPOT7EjP2GPvCtRkhVcNM+xjyptRIFWnCbMjmUIc+DO6 sfU4rtbCCkNKyXmnAgMBAAGjggHVMIIB0TAfBgNVHSMEGDAWgBR6E04AdFvGeGNkJ8Ev4qBb vHnFezAdBgNVHQ4EFgQUEI5c0f6UObxT2DLdvdtG+vG8qCswDgYDVR0PAQH/BAQDAgWgMAwG A1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMEYGA1UdIAQ/MD0w OwYMKwYBBAGyMQECAQMFMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u ZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E T0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEB BHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50 QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMCYGA1UdEQQfMB2BG3JvYmVydC5jcmFnaWVAZ3JpZG1lcmdl LmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAPpv87QuQ9q+RHhmeirGDQB3szd24Obi7N+uVfh5y CrnoJx3B37dNrLPsTB6PfTChUyZMqQD80pFoJ3TBUz3yx4X+hmNco7ujVIfbuKBGcZJaMKhZ ex3AkZ9ltie9wgiGGzEmgI81t5JHsLQ8AUMqw/fGsnIwcyWMgmyhFtm79+dg3IVaH05d/t9g k4aYoMoCFJptQZ+Fju6a9T139hOqjTZDpjMLt3jM80bVrvkC4dIRyF/oZ0qrJwbfwjnL2OUN ph9eymhLc+VM0Ih5k41s5IxmB+2c0RUqr5JbK0WrIb/z53Cmb9rXYox7HknyIfBpQqP77Y7a sAU2MMOpel4RijGCBBkwggQVAgEBMIGoMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0Eg TGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj dXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9mMAkGBSsOAwIaBQCgggJFMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDcxMjEyNTczOVowIwYJKoZI hvcNAQkEMRYEFD/EuHzwOCWN4x38Vkzp5R21br4uMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZI AWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZI hvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgbkGCSsGAQQBgjcQBDGBqzCBqDCB kzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMH U2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQXDFQ28QtqMuYch5f 2nTvZjCBuwYLKoZIhvcNAQkQAgsxgauggagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0ECEFwxUNvELajLmHIeX9p072YwDQYJKoZIhvcNAQEBBQAEggEAX6J1 wA9x690zmKy79y7TmTjNTggPmVBqafUanoX16jflpbbKF6qD/F9q/N8RIkeWIAAmcZb8gVIC o23dZEoV/BEjVuviEHsVU9lPigN+l+vBuBC8SA9k3gMlsQPS/XWjW4Sy5hkTd0rHfScQ7MGH X7+J8xzrLVweut7ZHUzUlcoM9eQmWGubiYcZHsfB4YjoZJDtnqTb2Nn9vrO5Gn6JSx0sC/9R Cq9Q7PWBh4oc63JvjZu63wKCnStHZd/y+3tFimDCUfwuxcfTpaS5lPlKjWfmcvSPM5zIoNzo Gs+iT67A1W+Oe7C4KXNPf3ZQ3Tmlson1423BXgMMYdFOg+5YnQAAAAAAAA== --------------ms090709070801060205030409-- From Bert.Greevenbosch@huawei.com Fri Jul 13 00:45:36 2012 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 B2FDF21F86D7 for ; Fri, 13 Jul 2012 00:45:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_42=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 uLdELbAhzBW1 for ; Fri, 13 Jul 2012 00:45:35 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id A089721F8619 for ; Fri, 13 Jul 2012 00:45:35 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHS35180; Fri, 13 Jul 2012 03:46:11 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 13 Jul 2012 00:43:13 -0700 Received: from SZXEML428-HUB.china.huawei.com (10.72.61.36) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 13 Jul 2012 00:43:11 -0700 Received: from SZXEML509-MBS.china.huawei.com ([10.82.67.53]) by szxeml428-hub.china.huawei.com ([10.72.61.36]) with mapi id 14.01.0323.003; Fri, 13 Jul 2012 15:43:04 +0800 From: Bert Greevenbosch To: Carsten Bormann Thread-Topic: [core] Upload of draft for "BlockMinimumTime" option Thread-Index: Ac1dlXIgejAMynRjREWUOXSbOxYSAP//m/MA//xPdnA= Date: Fri, 13 Jul 2012 07:43:05 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB62906E5F3@szxeml509-mbs> References: <46A1DF3F04371240B504290A071B4DB62905EDFF@szxeml509-mbs> <40D15137-3896-4A63-BAA8-ED77D950EB83@tzi.org> In-Reply-To: <40D15137-3896-4A63-BAA8-ED77D950EB83@tzi.org> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.110.143] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "core@ietf.org" Subject: Re: [core] Upload of draft for "BlockMinimumTime" option 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, 13 Jul 2012 07:45:36 -0000 Hi Carsten, Thanks for your comments. I think point (1) is OK, i.e. the unit can be both milliseconds and mibisec= onds. Or maybe it better define the unit to be mibiseconds, as [x milliseco= nds] > [x mibiseconds], i.e. a client using milliseconds will not violate t= he block minimum time. Point (2) is also interesting, the mechanism could also be used for differe= nt requests by the same client. Your example of a client browsing the serve= r is a convincing argument. Point (3) is more tricky. According to coap-10, a message is open until the= related ACK is received. I am not sure though if the client has to wait wi= th issuing the next request until it received an ACK, and if the server sho= uld use the ACK to slow down the client. In my view, the server should send= the ACK as soon as possible, to indicate it received the CON request. If i= t cannot immediately deliver the response, decoupling of ACK and response i= s required, and piggybacking is not used. (Although I think that in the blo= ck GET case, most often the server already has access to the whole resource= when sending the response to the first block request.) I agree with the observation that the client should not open too much conne= ctions at once, i.e. it should avoid something similar to the "abuse of TCP= " discussed in draft-bormann-core-congestion-control. Nevertheless, it is c= urrently not mandatory for the client to wait for an ACK (or CON response i= f there was no piggy-backing as discussed above) before sending the next re= quest. Therefore, the client can do multiple concurrent GETs within the sam= e block transaction, and the "BlockMinimumTime" option can keep that within= limits. Indeed we can add some discussion on point (3) in a future version of the d= raft. Best regards, Bert -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org]=20 Sent: 09 July 2012 15:43 To: Bert Greevenbosch Cc: core@ietf.org Subject: Re: [core] Upload of draft for "BlockMinimumTime" option Hi Bert, this is interesting. Three observations pop up in my mind: 1) Clock accuracy and units. When we need timers that are shorter than sec= onds, milliseconds come to mind. However, many nodes have convenient clock= sources only in power of two fractions. I would propose to always give th= e nodes leeway to use either milliseconds or "mibiseconds" (1/1024 s) as th= eir time base. As we are typically not making any mandates with respect to= clock accuracy, and embedded systems sometimes use RC oscillators for cert= ain timing functions, that 24000 ppm deviation is probably allowable anyway= . Saying this explicitly may remove one implementation headache. (Just for= today, I'm not going to add my ceterum censeo about pseudo-floating-point.= :-) 2) Why just -block, and a single resource? Background: When e.g. coap.me c= rawls a node, it rapidly reads all resources that are advertised. Would it= not be useful to give some pacing akin to your MinimumBlockTime in a resou= rce directory? 3) (General observation:) A server can already slow down a client by just n= ot sending responses very quickly. (The client is not supposed to send a l= ot of parallel requests; see coap-10 section 4.7 and draft-bormann-core-con= gestion-control for more detail.) So when is that the right strategy and w= hen does the server want to make the client slow down? There should be som= e discussion of this in a future version of this draft. Gr=FC=DFe, Carsten From hannes.tschofenig@gmx.net Fri Jul 13 04:44:07 2012 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 8C2FF21F86D0 for ; Fri, 13 Jul 2012 04:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.479 X-Spam-Level: X-Spam-Status: No, score=-102.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 5safaNYsnv2A for ; Fri, 13 Jul 2012 04:44:06 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 05C9D21F86FC for ; Fri, 13 Jul 2012 04:44:05 -0700 (PDT) Received: (qmail invoked by alias); 13 Jul 2012 11:44:40 -0000 Received: from unknown (EHLO [10.255.128.232]) [194.251.119.201] by mail.gmx.net (mp072) with SMTP; 13 Jul 2012 13:44:40 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18IMM1gJ7YINALtu/hncqGOgghcoHq/LGRC6jwcsB QtI0Pj+b1ZqJOr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <4FFEC9C3.8050108@gridmerge.com> Date: Fri, 13 Jul 2012 14:44:29 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <213AE838-274D-4809-B841-CCCC51C7B3CD@gmx.net> <4FFEC9C3.8050108@gridmerge.com> To: robert.cragie@gridmerge.com X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: tls@ietf.org, core Subject: Re: [core] [TLS] draft-ietf-tls-oob-pubkey: My summary 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, 13 Jul 2012 11:44:07 -0000 Hi Robert,=20 I am not changing the paradigm that the server asks the client for a = certificate. It still does.=20 What I had proposed is to include information that allows the server to = ask for something that the client actually has given that we now include = support for different certificate types, a feature that was not = previously available.=20 So, in your example below a client cannot say that he has a raw public = key for client authentication but not an X.509 certificate.=20 Ciao Hannes On Jul 12, 2012, at 3:57 PM, Robert Cragie wrote: > Hi Hannes, >=20 > The only one thing I am not sure about is the necessity for cert-send. = This is because traditionally the server makes the decision on whether = to request a certificate from the client and would not know a priori = whether the client supports it. That's not to say it isn't a good idea = though. >=20 > On that basis, I would modify the exchange slightly - see below. >=20 > Robert >=20 > I use three types of indications in the message exchange below for = improved clarity, namely: >=20 > (a) 'cert-receive=3D(value-1, value-2, ..., value-n)' with the = meaning: "I accept certificate of the following types (value-1, ..., = value-n) if you send them to me." The list is ordered by preference. >=20 > (b) 'cert-info=3Dvalue' with the meaning: "The certificate payload in = this message contains a certificate of the following type". >=20 > I) Server uses Raw Public Keys (client authentication happens at some = other layer) (the DANE use case) >=20 > client_hello, > cert-receive=3D(Raw, X.509) -> // (1) >=20 > <- server_hello, > cert-info=3DRaw, // (2) > certificate, // (3) > server_key_exchange, > server_hello_done >=20 > client_key_exchange, > change_cipher_spec, > finished -> >=20 > <- change_cipher_spec, > finished >=20 > Application Data <-------> Application Data >=20 > Legend: >=20 > (1) The client accepts reception of X.509 certs and raw public keys, = preferring raw public keys. > (2) The server decides to sends his raw public key and indicates this = in the cert-info field. > (3) The server certificate payload contains the raw public key. >=20 > II) Client and Server use Raw Public Keys (the smart object use case - = CORE working group) >=20 >=20 > client_hello, > cert-receive=3D(Raw) -> // (1) >=20 > <- server_hello, > cert-info=3DRaw,// (2) > certificate, // (3) > certificate_request, // (4) > cert-receive=3D(Raw) // (5) > server_key_exchange, > server_hello_done >=20 > cert-info=3DRaw, // (6) > certificate, // (7) > client_key_exchange, > change_cipher_spec, > finished -> >=20 > <- change_cipher_spec, > finished >=20 > Application Data <-------> Application Data >=20 >=20 > Legend: >=20 > (1) The client accepts reception of raw public keys. > (2) The server decides to sends his raw public key and indicates this = in the cert-info field. > (3) The server certificate payload contains the raw public key. > (4) The server wants to use client authentication and and sends a = certificate-request. > (5) The server accepts reception of raw public keys. > (6) The client indicates that the certificate payload contains a raw = public key. > (7) The client certificate payload contains the raw public key. >=20 > III) Hybrid Scenario (the OAuth Holder-of-the-Key Use case) >=20 > client_hello, > cert-receive=3D(X.509, Raw) -> // (1) >=20 > <- server_hello, > cert-info=3DX.509,// (2) > certificate, // (3) > certificate_request, // (4) > cert-receive=3D(Raw) // (5) > server_key_exchange, > server_hello_done >=20 > cert-info=3DRaw, // (6) > certificate, // (7) > client_key_exchange, > change_cipher_spec, > finished -> >=20 > <- change_cipher_spec, > finished >=20 > Application Data <-------> Application Data >=20 > Legend: >=20 > (1) Client accepts to receive X.509 certs and raw public keys, = preferring X.509 certs. (Could also be X.509 only in this example) > (2) The server decides to sends his X.509 cert and indicates this in = the cert-info field. > (3) The server certificate payload contains the X.509 cert. > (4) The server wants to use client authentication and sends a = certificate-request. > (5) The server accepts reception of raw public keys. > (6) The client indicates that the certificate payload contains a raw = public key. > (7) The client certificate payload contains the raw public key. >=20 >=20 >=20 >=20 > On 12/07/2012 8:54 AM, Hannes Tschofenig wrote: >> Hi Erk, Hi Robert, Hi Nikos, >>=20 >> thanks for your quick response. Here is an attempt to summarize your = input. >>=20 >> -------- >>=20 >> I use three types of indications in the message exchange below for = improved clarity, namely: >>=20 >> (a) 'cert-receive=3D(value-1, value-2, ..., value-n)' with the = meaning: "I accept certificate of the following types (value-1, ..., = value-n) if you send them to me." The list is ordered by preference. >>=20 >> (b) 'cert-send=3D(value-1, value-2, ..., value-n)' with the meaning: = "I could send you certificate of the following types (value-1, ..., = value-n) if you ask." The list is ordered by preference. >>=20 >> (c) cert-info=3D(value) with the meaning: "The certificate payload in = this message contains a certificate of the following type". >>=20 >> I) Server uses Raw Public Keys (client authentication happens at some = other layer) (the DANE use case) >>=20 >> client_hello, >> cert-receive=3D(Raw, X.509) // (1) >> cert-send=3D() -> // (2) >>=20 >> <- server_hello, >> cert-info=3D(Raw),// (3) >> certificate, // (4) >> server_key_exchange, >> server_hello_done >>=20 >> client_key_exchange, >> change_cipher_spec, >> finished -> >>=20 >> <- change_cipher_spec, >> finished >>=20 >> Application Data <-------> Application Data >>=20 >> Legend: >>=20 >> (1) Client accepts to receive two types of certificates, preferring = raw public keys. >> (2) The client does not have a raw public key nor an X.509 = certificate for client authentication. >> (3) The server decides to sends his raw public key and indicates this = in the cert-info field. >> (4) The certificate payload contains the raw public key. >>=20 >> II) Client and Server use Raw Public Keys (the smart object use case = - CORE working group) >>=20 >>=20 >> client_hello, >> cert-receive=3D(Raw) // (1) >> cert-send=3D(Raw) -> // (2) >>=20 >> <- server_hello, >> cert-info=3D(Raw),// (3) >> certificate, // (4) >> certificate_request, // (5) >> cert-receive=3D(Raw) // (6) >> server_key_exchange, >> server_hello_done >>=20 >> cert-info=3D(Raw), // (7) >> certificate, // (8) >> client_key_exchange, >> change_cipher_spec, >> finished -> >>=20 >> <- change_cipher_spec, >> finished >>=20 >> Application Data <-------> Application Data >>=20 >>=20 >> Legend: >>=20 >> (1) Client accepts to receive raw public keys. >> (2) The client does have a raw public key for client authentication. >> (3) The server decides to sends his raw public key and indicates this = in the cert-info field. >> (4) The certificate payload contains the raw public key. >> (5) The server wants to use client authentication and and sends a = cert-request. >> (6) The certificate request asks for a certificate of type 'raw' = (knowing that the client supports it from (2)). >> (7) The client indicates that the certificate payload contains a raw = public key >> (8) Here is the payload of the certificate itself. >>=20 >> III) Hybrid Scenario (the OAuth Holder-of-the-Key Use case) >>=20 >> client_hello, >> cert-receive=3D(X.509, Raw) // (1) >> cert-send=3D(Raw) -> // (2) >>=20 >> <- server_hello, >> cert-info=3D(X.509),// (3) >> certificate, // (4) >> certificate_request, // (5) >> cert-receive=3D(Raw) // (6) >> server_key_exchange, >> server_hello_done >>=20 >> cert-info=3D(Raw), // (7) >> certificate, // (8) >> client_key_exchange, >> change_cipher_spec, >> finished -> >>=20 >> <- change_cipher_spec, >> finished >>=20 >> Application Data <-------> Application Data >>=20 >> Legend: >>=20 >> (1) Client accepts to receive X.509 certs and raw public keys, in = this order of preference. (Could also be X.509 only in this example) >> (2) The client does have a raw public key for client authentication. >> (3) The server decides to sends his X.509 cert and indicates this in = the cert-info field. >> (4) The certificate payload contains the X.509 cert. >> (5) The server wants to use client authentication and sends a = cert-request. >> (6) The certificate request asks for a certificate of type 'raw' = (knowing that the client supports it from (2)). >> (7) The client indicates that the certificate payload contains a raw = public key. >> (8) Here is the payload of the certificate itself. >> -------- >>=20 >> Do these indications clarify the semantic? >> I personally believe so. >>=20 >> Ciao >> Hannes >>=20 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >>=20 >=20 >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From robert.cragie@gridmerge.com Fri Jul 13 07:06:05 2012 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 78C0921F8786; Fri, 13 Jul 2012 07:06:05 -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 BtDSo9aCEDLP; Fri, 13 Jul 2012 07:06:04 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by ietfa.amsl.com (Postfix) with ESMTP id B828121F8783; Fri, 13 Jul 2012 07:06:03 -0700 (PDT) Received: from client-86-23-114-225.brhm.adsl.virginmedia.com ([86.23.114.225] helo=[192.168.0.2]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) id 1SpgVx-0005Z3-J8; Fri, 13 Jul 2012 15:06:38 +0100 Message-ID: <50002B6E.6090806@gridmerge.com> Date: Fri, 13 Jul 2012 15:06:38 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Hannes Tschofenig References: <213AE838-274D-4809-B841-CCCC51C7B3CD@gmx.net> <4FFEC9C3.8050108@gridmerge.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090703010805090806080408" X-Authenticated-As: robert.cragie@gridmerge.com Cc: tls@ietf.org, core Subject: Re: [core] [TLS] draft-ietf-tls-oob-pubkey: My summary 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: Fri, 13 Jul 2012 14:06:05 -0000 This is a cryptographically signed message in MIME format. --------------ms090703010805090806080408 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Hannes, Agreed, but you are changing the knowledge the server has prior to the=20 request; I was simply questioning whether this was necessary. The server = can present a list of certificate types it accepts and the client=20 chooses one, so it is the same mechanism as the client uses initially=20 when (implicitly) requesting a certificate from the server (according to = cipher suite) and thus more balanced. Robert On 13/07/2012 12:44 PM, Hannes Tschofenig wrote: > Hi Robert, > > I am not changing the paradigm that the server asks the client for a ce= rtificate. It still does. > > What I had proposed is to include information that allows the server to= ask for something that the client actually has given that we now include= support for different certificate types, a feature that was not previous= ly available. > > So, in your example below a client cannot say that he has a raw public = key for client authentication but not an X.509 certificate. > > Ciao > Hannes > > On Jul 12, 2012, at 3:57 PM, Robert Cragie wrote: > >> Hi Hannes, >> >> The only one thing I am not sure about is the necessity for cert-send.= This is because traditionally the server makes the decision on whether t= o request a certificate from the client and would not know a priori wheth= er the client supports it. That's not to say it isn't a good idea though.= >> >> On that basis, I would modify the exchange slightly - see below. >> >> Robert >> >> I use three types of indications in the message exchange below for imp= roved clarity, namely: >> >> (a) 'cert-receive=3D(value-1, value-2, ..., value-n)' with the meaning= : "I accept certificate of the following types (value-1, ..., value-n) if= you send them to me." The list is ordered by preference. >> >> (b) 'cert-info=3Dvalue' with the meaning: "The certificate payload in = this message contains a certificate of the following type". >> >> I) Server uses Raw Public Keys (client authentication happens at some = other layer) (the DANE use case) >> >> client_hello, >> cert-receive=3D(Raw, X.509) -> // (1) >> >> <- server_hello, >> cert-info=3DRaw, // (2) >> certificate, // (3) >> server_key_exchange, >> server_hello_done >> >> client_key_exchange, >> change_cipher_spec, >> finished -> >> >> <- change_cipher_spec, >> finished >> >> Application Data <-------> Application Data >> >> Legend: >> >> (1) The client accepts reception of X.509 certs and raw public keys, p= referring raw public keys. >> (2) The server decides to sends his raw public key and indicates this = in the cert-info field. >> (3) The server certificate payload contains the raw public key. >> >> II) Client and Server use Raw Public Keys (the smart object use case -= CORE working group) >> >> >> client_hello, >> cert-receive=3D(Raw) -> // (1) >> >> <- server_hello, >> cert-info=3DRaw,// (2) >> certificate, // (3) >> certificate_request, // (4) >> cert-receive=3D(Raw) // (5) >> server_key_exchange, >> server_hello_done >> >> cert-info=3DRaw, // (6) >> certificate, // (7) >> client_key_exchange, >> change_cipher_spec, >> finished -> >> >> <- change_cipher_spec, >> finished >> >> Application Data <-------> Application Data >> >> >> Legend: >> >> (1) The client accepts reception of raw public keys. >> (2) The server decides to sends his raw public key and indicates this = in the cert-info field. >> (3) The server certificate payload contains the raw public key. >> (4) The server wants to use client authentication and and sends a cert= ificate-request. >> (5) The server accepts reception of raw public keys. >> (6) The client indicates that the certificate payload contains a raw p= ublic key. >> (7) The client certificate payload contains the raw public key. >> >> III) Hybrid Scenario (the OAuth Holder-of-the-Key Use case) >> >> client_hello, >> cert-receive=3D(X.509, Raw) -> // (1) >> >> <- server_hello, >> cert-info=3DX.509,// (2) >> certificate, // (3) >> certificate_request, // (4) >> cert-receive=3D(Raw) // (5) >> server_key_exchange, >> server_hello_done >> >> cert-info=3DRaw, // (6) >> certificate, // (7) >> client_key_exchange, >> change_cipher_spec, >> finished -> >> >> <- change_cipher_spec, >> finished >> >> Application Data <-------> Application Data >> >> Legend: >> >> (1) Client accepts to receive X.509 certs and raw public keys, preferr= ing X.509 certs. (Could also be X.509 only in this example) >> (2) The server decides to sends his X.509 cert and indicates this in t= he cert-info field. >> (3) The server certificate payload contains the X.509 cert. >> (4) The server wants to use client authentication and sends a certific= ate-request. >> (5) The server accepts reception of raw public keys. >> (6) The client indicates that the certificate payload contains a raw p= ublic key. >> (7) The client certificate payload contains the raw public key. >> >> >> >> >> On 12/07/2012 8:54 AM, Hannes Tschofenig wrote: >>> Hi Erk, Hi Robert, Hi Nikos, >>> >>> thanks for your quick response. Here is an attempt to summarize your= input. >>> >>> -------- >>> >>> I use three types of indications in the message exchange below for im= proved clarity, namely: >>> >>> (a) 'cert-receive=3D(value-1, value-2, ..., value-n)' with the meanin= g: "I accept certificate of the following types (value-1, ..., value-n) i= f you send them to me." The list is ordered by preference. >>> >>> (b) 'cert-send=3D(value-1, value-2, ..., value-n)' with the meaning: = "I could send you certificate of the following types (value-1, ..., valu= e-n) if you ask." The list is ordered by preference. >>> >>> (c) cert-info=3D(value) with the meaning: "The certificate payload in= this message contains a certificate of the following type". >>> >>> I) Server uses Raw Public Keys (client authentication happens at some= other layer) (the DANE use case) >>> >>> client_hello, >>> cert-receive=3D(Raw, X.509) // (1) >>> cert-send=3D() -> // (2) >>> >>> <- server_hello, >>> cert-info=3D(Raw),// (3) >>> certificate, // (4) >>> server_key_exchange, >>> server_hello_done >>> >>> client_key_exchange, >>> change_cipher_spec, >>> finished -> >>> >>> <- change_cipher_spec, >>> finished >>> >>> Application Data <-------> Application Data >>> >>> Legend: >>> >>> (1) Client accepts to receive two types of certificates, preferring r= aw public keys. >>> (2) The client does not have a raw public key nor an X.509 certificat= e for client authentication. >>> (3) The server decides to sends his raw public key and indicates this= in the cert-info field. >>> (4) The certificate payload contains the raw public key. >>> >>> II) Client and Server use Raw Public Keys (the smart object use case = - CORE working group) >>> >>> >>> client_hello, >>> cert-receive=3D(Raw) // (1) >>> cert-send=3D(Raw) -> // (2) >>> >>> <- server_hello, >>> cert-info=3D(Raw),// (3) >>> certificate, // (4) >>> certificate_request, // (5) >>> cert-receive=3D(Raw) // (6) >>> server_key_exchange, >>> server_hello_done >>> >>> cert-info=3D(Raw), // (7) >>> certificate, // (8) >>> client_key_exchange, >>> change_cipher_spec, >>> finished -> >>> >>> <- change_cipher_spec, >>> finished >>> >>> Application Data <-------> Application Data >>> >>> >>> Legend: >>> >>> (1) Client accepts to receive raw public keys. >>> (2) The client does have a raw public key for client authentication. >>> (3) The server decides to sends his raw public key and indicates this= in the cert-info field. >>> (4) The certificate payload contains the raw public key. >>> (5) The server wants to use client authentication and and sends a cer= t-request. >>> (6) The certificate request asks for a certificate of type 'raw' (kno= wing that the client supports it from (2)). >>> (7) The client indicates that the certificate payload contains a raw = public key >>> (8) Here is the payload of the certificate itself. >>> >>> III) Hybrid Scenario (the OAuth Holder-of-the-Key Use case) >>> >>> client_hello, >>> cert-receive=3D(X.509, Raw) // (1) >>> cert-send=3D(Raw) -> // (2) >>> >>> <- server_hello, >>> cert-info=3D(X.509),// (3) >>> certificate, // (4) >>> certificate_request, // (5) >>> cert-receive=3D(Raw) // (6) >>> server_key_exchange, >>> server_hello_done >>> >>> cert-info=3D(Raw), // (7) >>> certificate, // (8) >>> client_key_exchange, >>> change_cipher_spec, >>> finished -> >>> >>> <- change_cipher_spec, >>> finished >>> >>> Application Data <-------> Application Data >>> >>> Legend: >>> >>> (1) Client accepts to receive X.509 certs and raw public keys, in thi= s order of preference. (Could also be X.509 only in this example) >>> (2) The client does have a raw public key for client authentication. >>> (3) The server decides to sends his X.509 cert and indicates this in = the cert-info field. >>> (4) The certificate payload contains the X.509 cert. >>> (5) The server wants to use client authentication and sends a cert-re= quest. >>> (6) The certificate request asks for a certificate of type 'raw' (kno= wing that the client supports it from (2)). >>> (7) The client indicates that the certificate payload contains a raw = public key. >>> (8) Here is the payload of the certificate itself. >>> -------- >>> >>> Do these indications clarify the semantic? >>> I personally believe so. >>> >>> Ciao >>> Hannes >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > --------------ms090703010805090806080408 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP3jCC BIowggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w NTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMC VVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l dHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVN NRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQy lbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXq vgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6 hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu 9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0G A1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/ BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9BZGRU cnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8ubmV0L0Fk ZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyispgCi 54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0 g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHd WTBK322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftz Mizpm4QkLdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsy XEFs/vVdoOr/0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIFGjCCBAKgAwIBAgIQbRnqpxlPajMi 5iIyeqpx3jANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcw FQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3Jr MSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VS Rmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMTA0MjgwMDAwMDBa Fw0yMDA1MzAxMDQ4MzhaMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5 MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoSEW0tXmNReL4uk4UDIo1NY X2Zl8TJO958yfVXQeExVt0KU4PkncQfFxmmkuTLE8UAakMwnVmJ/F7Vxaa7lIBvky2NeYMqi QfZq4aP/uN8fSG1lQ4wqLitjOHffsReswtqCAtbUMmrUZ28gE49cNfrlVICv2HEKHTcKAlBT bJUdqRAUtJmVWRIx/wmi0kzcUtve4kABW0ho3cVKtODtJB86r3FfB+OsvxQ7sCVxaD30D9YX WEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJkJpFOpZIP/+CxYP0ab2hRmWONGoulzEKbm30i Y9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IBSzCCAUcwHwYDVR0jBBgwFoAUiYJnfcSd JnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MA4GA1UdDwEB /wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0gADBYBgNVHR8E UTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJzdC1DbGll bnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRoMGYwPQYIKwYBBQUH MAKGMWh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENsaWVudF9DQS5jcnQw JQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEFBQAD ggEBAIXWvnhXVW0zf0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtzbj7pJnzmTJjBMCjf y/tCPKElPgp11tA9OYZm0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqTecr+4pEeVnSy+I3T 4ENyG+2P/WA5IEf7i686ZUg8mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPNM1+b0L1garM7/vrU yTo8H+2b/5tJM75CKTmD7jNpLoKdRU2oadqAGx490hpdfEeZpZsIbRKZhtZdVwcbpzC+S0lE uJB+ytF5OOu0M/qgOl0mWJ5hVRi0IdWZ1eBDQEIwvuql55TSsP7zdfl/bucwggYuMIIFFqAD AgECAhBcMVDbxC2oy5hyHl/adO9mMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEb MBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTExMDkwMjAwMDAwMFoXDTE0MDkwMTIzNTk1 OVowggE3MQswCQYDVQQGEwJHQjEQMA4GA1UEERMHV0Y0IDRXQTEXMBUGA1UECBMOV2VzdCBZ b3Jrc2hpcmUxEjAQBgNVBAcTCVdha2VmaWVsZDEUMBIGA1UECRMLR3JhbmdlIE1vb3IxHzAd BgNVBAkTFjg5IEdyZWVuZmllbGQgQ3Jlc2NlbnQxFzAVBgNVBAoTDkdyaWRtZXJnZSBMdGQu MTQwMgYDVQQLEytJc3N1ZWQgdGhyb3VnaCBHcmlkbWVyZ2UgTHRkLiBFLVBLSSBNYW5hZ2Vy MR8wHQYDVQQLExZDb3Jwb3JhdGUgU2VjdXJlIEVtYWlsMRYwFAYDVQQDEw1Sb2JlcnQgQ3Jh Z2llMSowKAYJKoZIhvcNAQkBFhtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtxOGq8t5ZTVDVkmadv7ZRBLA5ApaiTcDUzCTn zYB2/BoBDIEWWI/InSRcmq3A0Ghm+T7dYmvRADllGv4nTHexdWlzFp2iM/Yc3PLWCyAO0gYb yW2hTi+ZfUDwFOU4hRP4+Dyn9tKu7FXS/PQJHyGjaGxHRmLm9T6tAo2ZuC59uRaGVCcwRiOS d6axwtB/DVhnP3S1rrt2g0O6MXLr5fojToemO52AxjHxt2w1LnFUUXC4EDV6o1Ctr7EvOEI5 5f088H/Mrryp02GueLdY9gb0SFK3gPOT7EjP2GPvCtRkhVcNM+xjyptRIFWnCbMjmUIc+DO6 sfU4rtbCCkNKyXmnAgMBAAGjggHVMIIB0TAfBgNVHSMEGDAWgBR6E04AdFvGeGNkJ8Ev4qBb vHnFezAdBgNVHQ4EFgQUEI5c0f6UObxT2DLdvdtG+vG8qCswDgYDVR0PAQH/BAQDAgWgMAwG A1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMEYGA1UdIAQ/MD0w OwYMKwYBBAGyMQECAQMFMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u ZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E T0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEB BHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50 QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMCYGA1UdEQQfMB2BG3JvYmVydC5jcmFnaWVAZ3JpZG1lcmdl LmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAPpv87QuQ9q+RHhmeirGDQB3szd24Obi7N+uVfh5y CrnoJx3B37dNrLPsTB6PfTChUyZMqQD80pFoJ3TBUz3yx4X+hmNco7ujVIfbuKBGcZJaMKhZ ex3AkZ9ltie9wgiGGzEmgI81t5JHsLQ8AUMqw/fGsnIwcyWMgmyhFtm79+dg3IVaH05d/t9g k4aYoMoCFJptQZ+Fju6a9T139hOqjTZDpjMLt3jM80bVrvkC4dIRyF/oZ0qrJwbfwjnL2OUN ph9eymhLc+VM0Ih5k41s5IxmB+2c0RUqr5JbK0WrIb/z53Cmb9rXYox7HknyIfBpQqP77Y7a sAU2MMOpel4RijGCBBkwggQVAgEBMIGoMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0Eg TGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj dXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9mMAkGBSsOAwIaBQCgggJFMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDcxMzE0MDYzOFowIwYJKoZI hvcNAQkEMRYEFGdmep9ouLVOK5OG75h2O+bxZaFeMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZI AWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZI hvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgbkGCSsGAQQBgjcQBDGBqzCBqDCB kzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMH U2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQXDFQ28QtqMuYch5f 2nTvZjCBuwYLKoZIhvcNAQkQAgsxgauggagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0ECEFwxUNvELajLmHIeX9p072YwDQYJKoZIhvcNAQEBBQAEggEAdXqE rDMkXDBVxL4xEzg6okJO+9Bh3yqTzrFlVvbtwPxG8njFOcChV52/PLVGuElFSlWCVRdmGVIZ iqbJNGVM3FO+nNMajSsgtslmTBUmnT1ihgr2AqOtVlZNzz/es9WsXeC7p+L+pPWeL20Lfu9t 9DuM3uznRFboshwdS7pBRIqGfm/ayx28eZuQDH5mAcDl25h9srL4Mq2M5hpfcNj4k3Z9Qpjg Byj4JD2/UcdLbBirC+HpgQFauJJUkeZgD/SCFKDRFH9cyn/hhs8ebtqcL1m2nUEH9968Lfyq oaXS3AoMWf23VoGy1Y6Ef+MAF64T1gFLO4snK8v6sIu51GzgPgAAAAAAAA== --------------ms090703010805090806080408-- From matthieu.vial@non.schneider-electric.com Fri Jul 13 09:22:04 2012 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 4280321F85F2 for ; Fri, 13 Jul 2012 09:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.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 yrN0NxDrSQA2 for ; Fri, 13 Jul 2012 09:22:03 -0700 (PDT) Received: from mailX04.eud.schneider-electric.com (mailx04.eud.schneider-electric.com [205.167.7.39]) by ietfa.amsl.com (Postfix) with ESMTP id 5D5AE21F85EF for ; Fri, 13 Jul 2012 09:22:03 -0700 (PDT) Received: from ateui03.schneider-electric.com ([10.198.21.36]) by mailX04.eud.schneider-electric.com with ESMTP id 2012071318223827-31335 ; Fri, 13 Jul 2012 18:22:38 +0200 To: core@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 From: matthieu.vial@non.schneider-electric.com Message-ID: Date: Fri, 13 Jul 2012 18:22:37 +0200 X-MIMETrack: Serialize by Router on ATEUI03.Schneider-Electric.com/T/SVR/Schneider at 13/07/2012 18:22:38, Serialize complete at 13/07/2012 18:22:38, Itemize by SMTP Server on AXEU4OUT.schneider-electric.com/X/SVR/SEIxtra at 13/07/2012 18:22:38, Serialize by Router on AXEU4OUT.schneider-electric.com/X/SVR/SEIxtra at 13/07/2012 18:22:39, Serialize complete at 13/07/2012 18:22:39 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="ISO-8859-1" Subject: [core] Tr : New Version Notification for draft-vial-core-mirror-proxy-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: Fri, 13 Jul 2012 16:22:04 -0000 Hi all, I have posted a new version of the old mirror proxy draft.=20 The new name is now Mirror Server but I had to stick with mirror proxy for = the filename to keep IDNITS happy. The draft has been completly rewritten but the concept remains the same. As usual all comments are welcome. Matthieu ----- R=E9achemin=E9 par Matthieu Vial/FR/Non/Schneider le 13/07/2012 18:10= =20 ----- internet-drafts@ietf.org=20 13/07/2012 18:09 A Matthieu Vial/FR/Non/Schneider@Europe cc Objet New Version Notification for draft-vial-core-mirror-proxy-01.txt A new version of I-D, draft-vial-core-mirror-proxy-01.txt has been successfully submitted by Matthieu Vial and posted to the IETF repository. Filename: draft-vial-core-mirror-proxy Revision: 01 Title: CoRE Mirror Server Creation date: 2012-07-13 WG ID: Individual Submission Number of pages: 19 URL: =20 http://www.ietf.org/internet-drafts/draft-vial-core-mirror-proxy-01.txt Status: =20 http://datatracker.ietf.org/doc/draft-vial-core-mirror-proxy Htmlized: =20 http://tools.ietf.org/html/draft-vial-core-mirror-proxy-01 Diff: =20 http://tools.ietf.org/rfcdiff?url2=3Ddraft-vial-core-mirror-proxy-01 Abstract: The Constrained RESTful Environments (CoRE) working group aims at realizing the REpresentational State Transfer (REST) architecture in a suitable form for the most constrained nodes. Thanks to the Constrained Application Protocol (CoAP), REST is now applicable to constrained networks. However the most energy-constrained devices may enter sleep mode and disconnect their network link during several minutes to save energy, hence preventing them from acting as traditional web servers. This document describes how a sleeping device can store resource representations in an entity called Mirror Server and participate in a constrained RESTful environment. =20 The IETF Secretariat =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F This email has been scanned by the Symantec Email Security.cloud service. =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F From Bert.Greevenbosch@huawei.com Mon Jul 16 00:21:59 2012 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 6D09311E80CF for ; Mon, 16 Jul 2012 00:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 zJUPPoGOe67Z for ; Mon, 16 Jul 2012 00:21:57 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id C587411E80D3 for ; Mon, 16 Jul 2012 00:21:56 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHU19257; Mon, 16 Jul 2012 03:22:36 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 16 Jul 2012 00:19:48 -0700 Received: from SZXEML417-HUB.china.huawei.com (10.82.67.156) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 16 Jul 2012 00:19:49 -0700 Received: from SZXEML509-MBS.china.huawei.com ([10.82.67.53]) by szxeml417-hub.china.huawei.com ([10.82.67.156]) with mapi id 14.01.0323.003; Mon, 16 Jul 2012 15:19:44 +0800 From: Bert Greevenbosch To: "Dijk, Esko" , "core@ietf.org" Thread-Topic: Upload of draft for "BlockMinimumTime" option Thread-Index: Ac1dlXIgejAMynRjREWUOXSbOxYSAACbF9TAAMc+kbA= Date: Mon, 16 Jul 2012 07:19:44 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB62906EC0C@szxeml509-mbs> References: <46A1DF3F04371240B504290A071B4DB62905EDFF@szxeml509-mbs> <031DD135F9160444ABBE3B0C36CED618A9D191@011-DB3MPN2-082.MGDPHG.emi.philips.com> In-Reply-To: <031DD135F9160444ABBE3B0C36CED618A9D191@011-DB3MPN2-082.MGDPHG.emi.philips.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.110.143] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [core] Upload of draft for "BlockMinimumTime" option 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, 16 Jul 2012 07:21:59 -0000 Hello Esko, Thank you for your comments. > I miss a motivation (or use cases) in this draft why BlockMinimumTime is = needed and why other approaches are not good enough. > E.g., the server can just wait 200 or 300 ms (times from Examples section= 7) before sending its response to the client achieving similar congestion = control and overload prevention. I think the main use case is for the server to be able to control the amoun= t of requests it receives within a time period, thereby achieving better us= age of its internal resources (memory, processor load, message buffers, etc= .) and increasing reliability in responding to requests. I think the server should perform open work as quickly as it can. That mean= s, that if it has a response to a request available, it should send that re= sponse as soon as feasible. Waiting 200 or 300ms to slow down the client re= quires the server to maintain that response for 200 to 300ms, occupying res= ources that could have been used to handle requests from other clients inst= ead. So although the delayed response solution indeed reduces the client's = speed, it only does a partial job in resolving server overload congestion. If however the server can explicitly signal the client's speed, then it doe= s not to keep track of its own minimum time to respond to each request, and= can handle requests as soon as possible, releasing its resources for other= tasks sooner. This will benefit the whole system, as all clients have a be= tter probability that their requests get handled and receive responses, whe= reas the server can fine-tune the requests to optimally use its resources. What do you think? Best regards, Bert From: Dijk, Esko [mailto:esko.dijk@philips.com]=20 Sent: 12 July 2012 15:47 To: Bert Greevenbosch; core@ietf.org Subject: RE: Upload of draft for "BlockMinimumTime" option Hello Bert, =A0 I miss a motivation (or use cases) in this draft why BlockMinimumTime is ne= eded and why other approaches are not good enough. E.g., the server can just wait 200 or 300 ms (times from Examples section 7= ) before sending its response to the client achieving similar congestion co= ntrol and overload prevention. =A0 regards, Esko =A0 From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Ber= t Greevenbosch Sent: Monday 9 July 2012 7:41 To: core@ietf.org Subject: [core] Upload of draft for "BlockMinimumTime" option =A0 Hello all, =A0 I have just upload a draft that defines the "BlockMinimumTime" option: http://datatracker.ietf.org/doc/draft-greevenbosch-core-block-minimum-time =A0 The option allows the server and client to negotiate the speed in which the= client sends requests in a block transaction. =A0 Comments are welcome! =A0 Best regards, Bert ________________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From zach@sensinode.com Mon Jul 16 12:07:17 2012 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 86E7A21F88BC for ; Mon, 16 Jul 2012 12:07:17 -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 dGYr6m37Rm6Q for ; Mon, 16 Jul 2012 12:07:16 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 6989421F88B8 for ; Mon, 16 Jul 2012 12:07:16 -0700 (PDT) Received: from [192.168.1.100] (188-67-182-252.bb.dnainternet.fi [188.67.182.252]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q6GJ7x5K026607 for ; Mon, 16 Jul 2012 22:07:59 +0300 From: Zach Shelby Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 16 Jul 2012 22:07:59 +0300 References: <20120716190510.4095.32465.idtracker@ietfa.amsl.com> To: "core@ietf.org WG" Message-Id: <47C091D5-1289-4A1A-B802-359B9D4D9EB2@sensinode.com> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [core] Fwd: New Version Notification for draft-shelby-core-resource-directory-04.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, 16 Jul 2012 19:07:17 -0000 We have posted a new version of the Resource Directory specification.=20 Changes from -03 to -04: o Added the ins=3D parameter back for the DNS-SD mapping. o Integrated the Simple Directory Discovery from Carsten = (http://tools.ietf.org/id/draft-bormann-core-simple-server-discovery-01.tx= t). o Editorial improvements. o Fixed the use of ETags. Zach Begin forwarded message: > From: internet-drafts@ietf.org > Date: July 16, 2012 10:05:10 PM GMT+03:00 > To: zach@sensinode.com > Cc: srdjan.krco@ericsson.com, cabo@tzi.org > Subject: New Version Notification for = draft-shelby-core-resource-directory-04.txt >=20 >=20 > A new version of I-D, draft-shelby-core-resource-directory-04.txt > has been successfully submitted by Zach Shelby and posted to the > IETF repository. >=20 > Filename: draft-shelby-core-resource-directory > Revision: 04 > Title: CoRE Resource Directory > Creation date: 2012-07-16 > WG ID: Individual Submission > Number of pages: 22 > URL: = http://www.ietf.org/internet-drafts/draft-shelby-core-resource-directory-0= 4.txt > Status: = http://datatracker.ietf.org/doc/draft-shelby-core-resource-directory > Htmlized: = http://tools.ietf.org/html/draft-shelby-core-resource-directory-04 > Diff: = http://tools.ietf.org/rfcdiff?url2=3Ddraft-shelby-core-resource-directory-= 04 >=20 > Abstract: > In many M2M applications, direct discovery of resources is not > practical due to sleeping nodes, disperse networks, or networks = where > multicast traffic is inefficient. These problems can be solved by > employing an entity called a Resource Directory (RD), which hosts > descriptions of resources held on other servers, allowing lookups to > be performed for those resources. This document specifies the web > interfaces that a Resource Directory supports in order for web > servers to discover the RD and to register, maintain, lookup and > remove resources descriptions. Furthermore, new link attributes > useful in conjunction with an RD are defined. >=20 >=20 >=20 >=20 > The IETF Secretariat --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From trac+core@trac.tools.ietf.org Mon Jul 16 13:45:28 2012 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 374F311E80F0 for ; Mon, 16 Jul 2012 13:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.168 X-Spam-Level: X-Spam-Status: No, score=-102.168 tagged_above=-999 required=5 tests=[AWL=0.431, 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 3XC8x2XD0m4T for ; Mon, 16 Jul 2012 13:45:27 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id DC93011E82C2 for ; Mon, 16 Jul 2012 13:45:26 -0700 (PDT) Received: from localhost ([127.0.0.1]:33287 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SqsAw-0006R2-UH; Mon, 16 Jul 2012 22:45:50 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: cabo@tzi.org, angelo@castellani.net, zach@sensinode.com, hartke@tzi.org X-Trac-Project: core Date: Mon, 16 Jul 2012 20:45:50 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/201#comment:9 Message-ID: <066.c36bb3f9d0c12f40b62c1fef9548f66a@trac.tools.ietf.org> References: <051.b90ea2a4caf57d34ab6abdaf3603301a@trac.tools.ietf.org> X-Trac-Ticket-ID: 201 In-Reply-To: <051.b90ea2a4caf57d34ab6abdaf3603301a@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: cabo@tzi.org, angelo@castellani.net, zach@sensinode.com, 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 Cc: core@ietf.org Subject: Re: [core] #201: Clarify use of retransmission window for duplicate detection 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, 16 Jul 2012 20:45:28 -0000 #201: Clarify use of retransmission window for duplicate detection Changes (by cabo@…): * status: new => closed * resolution: => fixed Comment: Fixed in [838]: fix #201 -- -----------------------------+-------------------------- Reporter: cabo@… | Owner: cabo@… Type: editorial | Status: closed Priority: minor | Milestone: post-WGLC-1 Component: coap | Version: coap-09 Severity: In WG Last Call | Resolution: fixed Keywords: | -----------------------------+-------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Mon Jul 16 13:48:33 2012 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 EE92E11E813B for ; Mon, 16 Jul 2012 13:48:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.176 X-Spam-Level: X-Spam-Status: No, score=-102.176 tagged_above=-999 required=5 tests=[AWL=0.423, 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 qhKLvmoZ0sXO for ; Mon, 16 Jul 2012 13:48:33 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 55FC921F867C for ; Mon, 16 Jul 2012 13:48:33 -0700 (PDT) Received: from localhost ([127.0.0.1]:33434 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SqsEC-0004IV-RS; Mon, 16 Jul 2012 22:49:12 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, zach@sensinode.com, fluffy@cisco.com, hartke@tzi.org X-Trac-Project: core Date: Mon, 16 Jul 2012 20:49:12 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/230#comment:7 Message-ID: <068.d894be6582e6a90ccb86443750330772@trac.tools.ietf.org> References: <053.8673136dcb3a579ebc337cc52e97888a@trac.tools.ietf.org> X-Trac-Ticket-ID: 230 In-Reply-To: <053.8673136dcb3a579ebc337cc52e97888a@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, zach@sensinode.com, fluffy@cisco.com, 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: Resent-Message-Id: <20120716204833.55FC921F867C@ietfa.amsl.com> Resent-Date: Mon, 16 Jul 2012 13:48:33 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #230: Multiple Location options need to be processed as a unit 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, 16 Jul 2012 20:48:34 -0000 #230: Multiple Location options need to be processed as a unit Changes (by cabo@…): * status: new => closed * resolution: => fixed Comment: Fixed in coap-10. There was no specific support for reordering the options in order to keep the reserved values earlier. -- -----------------------------+------------------------------------- Reporter: hartke@… | Owner: draft-ietf-core-coap@… Type: protocol defect | Status: closed Priority: minor | Milestone: post-WGLC-1 Component: coap | Version: coap-09 Severity: In WG Last Call | Resolution: fixed Keywords: | -----------------------------+------------------------------------- Ticket URL: core From internet-drafts@ietf.org Mon Jul 16 14:53:14 2012 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 B1D8111E8241; Mon, 16 Jul 2012 14:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.504 X-Spam-Level: X-Spam-Status: No, score=-102.504 tagged_above=-999 required=5 tests=[AWL=0.095, 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 ilNWdrncIq0G; Mon, 16 Jul 2012 14:53:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D406211E819F; Mon, 16 Jul 2012 14:53: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.30p3 Message-ID: <20120716215313.17964.96453.idtracker@ietfa.amsl.com> Date: Mon, 16 Jul 2012 14:53:13 -0700 Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-coap-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: Mon, 16 Jul 2012 21:53: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 : Constrained Application Protocol (CoAP) Author(s) : Zach Shelby Klaus Hartke Carsten Bormann Brian Frank Filename : draft-ietf-core-coap-11.txt Pages : 100 Date : 2012-07-16 Abstract: 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 end-points, supports built-in discovery of services and 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-coap There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-core-coap-11 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-coap-11 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From cabo@tzi.org Mon Jul 16 15:23:21 2012 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 DF16C21F87FC for ; Mon, 16 Jul 2012 15:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.355 X-Spam-Level: X-Spam-Status: No, score=-106.355 tagged_above=-999 required=5 tests=[AWL=-0.106, 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 yAkdJkB+uHkS for ; Mon, 16 Jul 2012 15:23:20 -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 F41C321F87F5 for ; Mon, 16 Jul 2012 15:23:19 -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.3/8.14.3) with ESMTP id q6GMNuC7010290 for ; Tue, 17 Jul 2012 00:23:56 +0200 (CEST) Received: from [192.168.217.117] (p5489335A.dip.t-dialin.net [84.137.51.90]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id C98644A0; Tue, 17 Jul 2012 00:23:56 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <20120716215313.17964.96453.idtracker@ietfa.amsl.com> Date: Tue, 17 Jul 2012 00:23:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <764076BF-AFB6-44AF-BC4C-ABE3F6928ECD@tzi.org> References: <20120716215313.17964.96453.idtracker@ietfa.amsl.com> To: "core@ietf.org WG" X-Mailer: Apple Mail (2.1278) Subject: [core] CoRE @ IETF84: draft-ietf-core-coap-11.txt and some staging documents 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, 16 Jul 2012 22:23:21 -0000 After core-coap-10 made some major rearrangements, core-coap-11 mainly = has the changes to close ticket #201, by moving material from coap-misc = to section 4.8 (Transmission Parameters) and editing it in shape for the = spec. Please read the new text again carefully, as it has a little bit of math = in it that is easy to get wrong. Htmlized: http://tools.ietf.org/html/draft-ietf-core-coap-11 Diff: = http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-coap-11 Most of the other major proposals for ticket resolutions are still in = coap-misc, which also was renewed today: Htmlized: http://tools.ietf.org/html/draft-bormann-coap-misc-19 Diff: = http://tools.ietf.org/rfcdiff?url2=3Ddraft-bormann-coap-misc-19 There is a new section 3.2 that proposes an alternative resolution for = #214 based on the discussion at the virtual interim. Section 5 provides text for resolving -observe tickets #204, #221 IIRC. Finally, a resolution for #215 is being prepared in = core-congestion-control. =09 Htmlized: = http://tools.ietf.org/html/draft-bormann-core-congestion-control-01 Diff: = http://tools.ietf.org/rfcdiff?url2=3Ddraft-bormann-core-congestion-control= -01 The main change from -00 is the addition of a section 6 detailing the = changes planned for Base Specifications=09 While there is a lot of boring detail work remaining, I believe we have = the bulk of the necessary new material now out there. Please read and prepare for IETF84 in Vancouver. =20 Pending major disagreements on the list, the material pointed out should = move into coap-12 and observe-06 by Vancouver. Gr=FC=DFe, Carsten From mab@comnets.uni-bremen.de Tue Jul 17 09:30:11 2012 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 5B09421F8644 for ; Tue, 17 Jul 2012 09:30: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 9mmOi8gvcgST for ; Tue, 17 Jul 2012 09:30:10 -0700 (PDT) Received: from bugs.comnets.uni-bremen.de (bugs.comnets.uni-bremen.de [IPv6:2001:638:708:1155::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C0BD21F862F for ; Tue, 17 Jul 2012 09:30:10 -0700 (PDT) Received: from shelbyville.comnets.uni-bremen.de (unknown [10.8.0.62]) by bugs.comnets.uni-bremen.de (Postfix) with ESMTPS id 9D4A7D43572 for ; Tue, 17 Jul 2012 18:30:55 +0200 (CEST) From: Markus Becker Organization: Comnets, University Bremen To: core@ietf.org Date: Tue, 17 Jul 2012 18:19:36 +0200 User-Agent: KMail/1.13.7 (Linux/3.2.0-2-686-pae; KDE/4.8.4; i686; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201207171819.36885.mab@comnets.uni-bremen.de> Subject: [core] Fwd: New Version Notification for draft-becker-core-coap-sms-gprs-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, 17 Jul 2012 16:30:11 -0000 Hi all, I have posted a new version of the CoAP + SMS/USSD/GPRS draft. Changes from draft-01 to draft-02: o Added security considerations: Transport and Object Security. Section 15 o Reply-To-* changed to Response-To-*. Section 16 and Section 10.1 o Added URI scheme. Section 11 o Added possible CON/NON/ACK interactions. Section 5 o Added possible M2M proxy scenarios. Section 14 o Added reference to bormann-coap-misc for other SMS encoding. Section 7.1 o Updated requirements on Uri-Host and Uri-Port for coap+tel://. Section 10 o Chose CoAP option numbers and updated the option number table to meet draft-ietf-core-coap-10. Table 1 o Added an IANA registration for the URI scheme. Section 16.2 Comments, especially on the section 5 (CON/NON/ACK interactions), 14 (M2M proxy scenarios) and 10 (URI scheme), are very welcome. Markus > A new version of I-D, draft-becker-core-coap-sms-gprs-02.txt > has been successfully submitted by Markus Becker and posted to the > IETF repository. > > Filename: draft-becker-core-coap-sms-gprs > Revision: 02 > Title: Transport of CoAP over SMS, USSD and GPRS > Creation date: 2012-07-13 > WG ID: Individual Submission > Number of pages: 29 > URL: > http://www.ietf.org/internet-drafts/draft-becker-core-coap-sms-gprs-02.txt > Status: > http://datatracker.ietf.org/doc/draft-becker-core-coap-sms-gprs Htmlized: > http://tools.ietf.org/html/draft-becker-core-coap-sms-gprs-02 Diff: > > http://tools.ietf.org/rfcdiff?url2=draft-becker-core-coap-sms-gprs-02 > > Abstract: > The Short Message Service (SMS) and Unstructured Supplementary > Service Data (USSD) of mobile cellular networks is frequently used in > Machine-To-Machine (M2M) communications, such as for telematic > devices. The service offers small packet sizes and high delays just > as other typical low-power and lossy networks (LLNs), i.e. 6LoWPANs. > The design of the Constrained Application Protocol (CoAP), that took > the limitations of LLNs into account, is thus also applicable to > telematic M2M devices. The adaptation of CoAP to the SMS or USSD > transport mechanisms and the combination with IP transported over > cellular networks is described in this document. > > > > > The IETF Secretariat ------------------------------------------------ | Dipl.-Ing. Markus Becker | Communication Networks | TZI - Center for Computing Technologies | University Bremen | Germany ------------------------------------------------ | web: http://www.comnets.uni-bremen.de/~mab/ | mailto: mab@comnets.uni-bremen.de | telephone: +49 421 218 62379 | building: NW1 room: N2260 ------------------------------------------------ From cabo@tzi.org Thu Jul 19 09:11:39 2012 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 538B521F8770 for ; Thu, 19 Jul 2012 09:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.071 X-Spam-Level: X-Spam-Status: No, score=-106.071 tagged_above=-999 required=5 tests=[AWL=0.178, 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 4IBEYx9lpFQN for ; Thu, 19 Jul 2012 09:11:38 -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 7E3AF21F8763 for ; Thu, 19 Jul 2012 09:11:38 -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.3/8.14.3) with ESMTP id q6JGCNqR006456 for ; Thu, 19 Jul 2012 18:12:23 +0200 (CEST) Received: from [10.0.1.2] (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 7CCCEB4B; Thu, 19 Jul 2012 18:12:23 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Thu, 19 Jul 2012 18:12:22 +0200 To: "core@ietf.org WG" Message-Id: Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [core] CoRE @ IETF84: Agenda V1.1 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, 19 Jul 2012 16:11:39 -0000 I have uploaded a slightly more detailed agenda at: http://www.ietf.org/proceedings/84/agenda/agenda-84-core Note that the Friday CoRE slot is moving about as we speak to avoid the = conflict with the late-scheduled ROLL meeting. We may have less time than we planned. (But we can always highjack the = ROLL meeting -- they have a slot about security, too.) (We may also ask for cooperation from the LWIG people to maybe move some = discussion into their slot.) Anyway, if you have a slot request in for the "non-WGLC" part, please do = talk to the authors of the drafts I have put into the same group (or = tell me to fix that grouping) and substantiate your slot requests by = sending us objectives for the slot. If you don't know how these look like, please consult: http://www.ietf.org/proceedings/83/agenda/agenda-83-core Gr=FC=DFe, Carsten From m.pouillot@watteco.com Mon Jul 23 09:17:15 2012 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 5DD2421F866D for ; Mon, 23 Jul 2012 09:17: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=[AWL=0.001, 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 IFATZ+vD5Nq1 for ; Mon, 23 Jul 2012 09:17:14 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe003.messaging.microsoft.com [216.32.180.186]) by ietfa.amsl.com (Postfix) with ESMTP id 24E3E21F8658 for ; Mon, 23 Jul 2012 09:17:14 -0700 (PDT) Received: from mail115-co1-R.bigfish.com (10.243.78.248) by CO1EHSOBE013.bigfish.com (10.243.66.76) with Microsoft SMTP Server id 14.1.225.23; Mon, 23 Jul 2012 16:17:13 +0000 Received: from mail115-co1 (localhost [127.0.0.1]) by mail115-co1-R.bigfish.com (Postfix) with ESMTP id 73B73A80352; Mon, 23 Jul 2012 16:17:13 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.252.37; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0510HT002.eurprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -74 X-BigFish: VPS-74(zf7Iz9371Ic89bh936eI1432I15caKJzz1202hzz8275ch1033IL8275bh8275dhz2dh2a8h668h839hd25hf0ah107ah) Received: from mail115-co1 (localhost.localdomain [127.0.0.1]) by mail115-co1 (MessageSwitch) id 1343060212976496_23930; Mon, 23 Jul 2012 16:16:52 +0000 (UTC) Received: from CO1EHSMHS002.bigfish.com (unknown [10.243.78.228]) by mail115-co1.bigfish.com (Postfix) with ESMTP id 291A02400E0; Mon, 23 Jul 2012 16:16:50 +0000 (UTC) Received: from DB3PRD0510HT002.eurprd05.prod.outlook.com (157.56.252.37) by CO1EHSMHS002.bigfish.com (10.243.66.12) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 23 Jul 2012 16:16:49 +0000 Received: from DB3PRD0510MB393.eurprd05.prod.outlook.com ([169.254.4.177]) by DB3PRD0510HT002.eurprd05.prod.outlook.com ([10.255.46.37]) with mapi id 14.16.0175.005; Mon, 23 Jul 2012 16:16:41 +0000 From: M Pouillot To: Zach Shelby , "core@ietf.org WG" Thread-Topic: [core] Fwd: New Version Notification for draft-shelby-core-interfaces-03.txt Thread-Index: AQHNX1r97Sq+wbOcmU6KSgnoXkjmhpclpvZA Date: Mon, 23 Jul 2012 16:16:41 +0000 Message-ID: <1D0972C5226A7649BBB5E3734FCD593DA55BE4@DB3PRD0510MB393.eurprd05.prod.outlook.com> References: <20120711114256.8289.22566.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.3.4.11] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: watteco.com Subject: Re: [core] Fwd: New Version Notification for draft-shelby-core-interfaces-03.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, 23 Jul 2012 16:17:15 -0000 Hello Zach and Matthieu, Great job on the binding mechanism, I have just little question about the 4= .3. Why a profile should allow only one resource table per endpoint? What = is the issue to have several bindings on one endpoint? More generally, now we have the RD, or the well-known/core to discover the = features of each device. We have the mean to do a bind between several devi= ces... Is there a work to describe how a device can recognize automatically= with others it can make a binding? A generic ressource source "switch/ono= ff" could control a "a/light" actuator but a "a/pwr" actuator too. These tw= o actuators have the same functionalities (on/off/ toggle) but how the sour= ce could know that these specific actuators have the good features. It coul= d be interesting to specify generic features and publish them in the ressou= rce type . example: ;rt=3D"simple.act.led.onoff";if=3D"core.a" regards, Mathieu -----Message d'origine----- De=A0: core-bounces@ietf.org [mailto:core-bounces@ietf.org] De la part de Z= ach Shelby Envoy=E9=A0: mercredi 11 juillet 2012 13:47 =C0=A0: core@ietf.org WG Objet=A0: [core] Fwd: New Version Notification for draft-shelby-core-interf= aces-03.txt Matthieu and I have posted a new version of the CoRE Interfaces draft. This= now includes a useful new mechanism to create bindings between resources o= n the same or different endpoints. For example for a light switch to contro= l a light, or to handle just about any interaction between resources. The d= raft also updates all resource types and interface descriptions to the -14 = version of CoRE Link Format. Try it out - comments welcome!=20 Zach Begin forwarded message: > From: internet-drafts@ietf.org > Date: July 11, 2012 2:42:56 PM GMT+03:00 > To: zach@sensinode.com > Cc: matthieu.vial@schneider-electric.com > Subject: New Version Notification for=20 > draft-shelby-core-interfaces-03.txt >=20 >=20 > A new version of I-D, draft-shelby-core-interfaces-03.txt > has been successfully submitted by Zach Shelby and posted to the IETF=20 > repository. >=20 > Filename: draft-shelby-core-interfaces > Revision: 03 > Title: CoRE Interfaces > Creation date: 2012-07-11 > WG ID: Individual Submission > Number of pages: 24 > URL: http://www.ietf.org/internet-drafts/draft-shelby-core-in= terfaces-03.txt > Status: http://datatracker.ietf.org/doc/draft-shelby-core-interf= aces > Htmlized: http://tools.ietf.org/html/draft-shelby-core-interfaces-= 03 > Diff: http://tools.ietf.org/rfcdiff?url2=3Ddraft-shelby-core-i= nterfaces-03 >=20 > Abstract: > This document defines well-known REST interface descriptions for > Batch, Sensor, Parameter and Actuator types for use in contrained web > servers using the CoRE Link Format. A short reference is provided > for each type that can be efficiently included in the interface > description attribute of the CoRE Link Format. These descriptions > are intended to be for general use in resource designs or for > inclusion in more specific interface profiles. In addition, this > document defines the concepts of Function Set and Binding. The > former is the basis element to create RESTful profiles and the latter > helps the configuration of links between resources located on one or > more endpoints. >=20 >=20 >=20 >=20 > The IETF Secretariat -- Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From stokcons@xs4all.nl Tue Jul 24 01:03:20 2012 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 7DF7221F8652 for ; Tue, 24 Jul 2012 01:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.985 X-Spam-Level: X-Spam-Status: No, score=0.985 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 I--38oWauegI for ; Tue, 24 Jul 2012 01:03:19 -0700 (PDT) Received: from smtp-vbr19.xs4all.nl (smtp-vbr19.xs4all.nl [194.109.24.39]) by ietfa.amsl.com (Postfix) with ESMTP id 7202E21F864F for ; Tue, 24 Jul 2012 01:03:19 -0700 (PDT) Received: from roundcube.xs4all.nl (roundcube3.xs4all.net [194.109.20.199]) by smtp-vbr19.xs4all.nl (8.13.8/8.13.8) with ESMTP id q6O82lG8053553; Tue, 24 Jul 2012 10:02:48 +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, 24 Jul 2012 10:02:47 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 24 Jul 2012 10:02:47 +0200 From: peter van der Stok To: , Organization: vanderstok consultancy Mail-Reply-To: Message-ID: X-Sender: stokcons@xs4all.nl (sbkV/RqviDYv2h7UkFIlP7TSr6Rf/yLg) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Subject: [core] draft mirror server 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, 24 Jul 2012 08:03:20 -0000 Hi Matthieu, the draft has become quite readable and I like your treatment of the correspondence with RD. I seem to understand from the examples that for every new SEP a new path /ms/sep/ is created, called ms/0 in your examples. The relation between SEP and path is not explicitly treated in the draft, although idem-potency is mentioned. Should the draft not prescribe that with every registration by a new SEP a new path should be created in the MS? Or did I miss something? Also is is not clear to me if the term domain in section 4.2 refers to the "d=" link-format attribute. Peter -- Peter van der Stok mailto: consultancy@vanderstok.org www: www.vanderstok.org tel NL: +31(0)492474673 F: +33(0)966015248 From james.huy.nguyen@gmail.com Sat Jul 28 23:33:01 2012 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 EFE6711E809B for ; Sat, 28 Jul 2012 23:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 ILk5BQszZKU9 for ; Sat, 28 Jul 2012 23:33:01 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8417E11E8072 for ; Sat, 28 Jul 2012 23:33:01 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so7925703obb.31 for ; Sat, 28 Jul 2012 23:33:01 -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 :content-type; bh=IoP/wlbRVuiv61mS5mkFbN/jzNv4jMslwFCUwPo8YBA=; b=DcOsL6QpiJGtDcNqsQuQs5/TMNxKnBaA+fcmvph7UGrEylIjE5FxixuoLGTjGogOhb vIwjecOO62EEIv6ozBiSHt/YZpgjAM6i4GhUwwLOLkylcM4UysG+Z9w+Pgge5E6kfEp2 oS2KWPD0sozrIvF9RKubDe3tgNRkNfJrBM54RUP49bAob0UCZsjp4fzQON55/uG16QDq 8IuHN9oO7Ii5ZWj44r0sYX+4/vpjB4pfd3V/EQaU/cu3ipmS7+uOIxlv8A2LPamtpVkB nB/S9tQZ9J3JpTZJ06vV3C1D1/mwNzadXjChQwJAO7vmeqNpIayG0/NKKQ6GKuQjFJ7w T8tQ== MIME-Version: 1.0 Received: by 10.50.12.227 with SMTP id b3mr5655294igc.7.1343543580996; Sat, 28 Jul 2012 23:33:00 -0700 (PDT) Received: by 10.42.171.135 with HTTP; Sat, 28 Jul 2012 23:33:00 -0700 (PDT) In-Reply-To: References: Date: Sun, 29 Jul 2012 02:33:00 -0400 Message-ID: From: James Nguyen To: core@ietf.org Content-Type: multipart/alternative; boundary=14dae93410dbe2b67504c5f21dbe Subject: [core] User guide for jcoap 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, 29 Jul 2012 06:33:02 -0000 --14dae93410dbe2b67504c5f21dbe Content-Type: text/plain; charset=UTF-8 Hi, I'm interested in using jcoap. Does anyone have any document that shows how to use it? Thanks, -- James Nguyen Email: james.huy.nguyen@gmail.com -- James Nguyen Email: james.huy.nguyen@gmail.com -- James Nguyen Email: james.huy.nguyen@gmail.com --14dae93410dbe2b67504c5f21dbe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I'm interested in using jcoap.=C2=A0 = Does anyone have any document that shows how to use it?

Thanks,

--
James Nguyen
Email: jame= s.huy.nguyen@gmail.com



--
James Nguyen
Email:= james.huy.= nguyen@gmail.com



--
James Nguyen
Email: <= a href=3D"mailto:james.huy.nguyen@gmail.com">james.huy.nguyen@gmail.com=
--14dae93410dbe2b67504c5f21dbe-- From zehn.cao@gmail.com Sun Jul 29 00:12:09 2012 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 6BE4F21F8565; Sun, 29 Jul 2012 00:12:09 -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 gX0DUF+sw+D5; Sun, 29 Jul 2012 00:12:08 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id F0FC521F855E; Sun, 29 Jul 2012 00:12:07 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so2661111wgb.13 for ; Sun, 29 Jul 2012 00:12:07 -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:content-transfer-encoding; bh=YtUzDuoJs3dOxkidmbW2i+75oCBbw2O8DNOTg6chGGk=; b=KKim/lpbzSzUs4ijNzugOG2i0F/blN5SCWr0JVywzGD/yLYSVruaVOYenvTmFb7Tkb w2K8uK1AebiGY5VZTHqk1sqHhfjKTg283flrqWRuKj9r0aRFZ2yGyArupYrlpgWJXyzb G4ObrUgc8DosjpSASAIoxtz2X7Tz2cvgKUGgzUMSp4mk+aXxY5fJrmpKgEwsT6PMYvfw ixwZ6f42ktmKhPvaCkVGHxjW00YmNUCZEzg9X1OBBKv39Ac6Xr19byBAHw72MPYksDzg wrK6naqVoFERtFcRATLOTJaL5lw3zwNzYgMXb/Z9mdAmJDimQIlfShjbwYAjhm6kA1Ds JTvw== MIME-Version: 1.0 Received: by 10.180.81.193 with SMTP id c1mr33706195wiy.12.1343545927138; Sun, 29 Jul 2012 00:12:07 -0700 (PDT) Received: by 10.180.4.134 with HTTP; Sun, 29 Jul 2012 00:12:07 -0700 (PDT) In-Reply-To: <4FFAC3D8.8090407@piuha.net> References: <20120709113756.5118.82222.idtracker@ietfa.amsl.com> <4FFAC3D8.8090407@piuha.net> Date: Sun, 29 Jul 2012 00:12:07 -0700 Message-ID: From: Zhen Cao To: Jari Arkko Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: lwip@ietf.org, =?ISO-8859-1?Q?Ari_Ker=E4nen?= , core , "Anders Eriksson E \(KI/EAB\)" Subject: Re: [core] draft-arkko-core-cellular 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, 29 Jul 2012 07:12:10 -0000 Dear Authors I read the draft and found it very interesting and useful for me to understand how to build energy efficient cellular M2M devices, not only CoAP devices. Although the draft is entitled with =93CoAP devices=94, its provided recommendations are generally workable for any M2M devices that provide sensing or actuator service. As what=92s stated in Section 1. The recommendations in this memo should be taken as complementary to device hardware optimization, microelectronics improvements, and further evolution of the underlying link and radio layers. Further gains in power efficiency can certainly be gained on several fronts; the approach that we take in this memo is to do what can be done at the IP, transport, and application layers to provide the best possible power efficiency=85 I like the style of section 3, the analysis of the link layer implications for energy-efficient application development. Some questions and comments are listed separately as below. - Public network. Is it just used as the adverse of =93private network=94? - Point to point link. As analyzed in the draft, this is a normal case for cellular connection, no way and no need to consider third party devices. As to achieve energy efficient is always contradictory of handling multicast/broadcast packets, it is relatively easier to be efficient with PPP link. Or shall we make such recommendations? - Radio technology. Radio proved to be the most energy consuming part, and L2 mechanisms are most efficient in the optimization space. I turned to believe that there is no need to optimize the upper layers before I encounter the idea of message coordination. That is to reduce the frequency of trigger link up by coordinating the send/recv behavior of different protocols. For example, 6LOWPAN-ND advertises sometime and wake the radio, and then radio/MAC layer optimization turns it off before COAP protocol triggers a groupcomm afterwards. If these send/recv of different protocols can be coordinated, I guess the situation will be much better. Section 7 on the =93Real-time reachable device=94. For cellular devices, there is one characterize to utilize: they are always reachable from the circuit-switch side. Take the CoAP protocol as an example, if it is difficult to reach the device (as a CoAP server, or to initiate the observe mode) from the packet side, we can trigger it via a SMS message and let it behave as a client. This is a rather special case for cellular devices that developers can take advantage of. I heard of some usage in this regards. Again, I believe the description and analysis in this document is useful for the cellular M2M devices. Guidelines for CoAP and other IETF protocols can be derived from it. Best regards, CZ On Mon, Jul 9, 2012 at 4:43 AM, Jari Arkko wrote: > Hi, > > We have written a draft that talks about how to apply CoAP in smart objec= ts > attached to the Internet via the cellular networks. > > Comments appreciated. > > Jari > > On 09.07.2012 14:37, internet-drafts@ietf.org wrote: >> >> A new version of I-D, draft-arkko-core-cellular-00.txt >> has been successfully submitted by Jari Arkko and posted to the >> IETF repository. >> >> Filename: draft-arkko-core-cellular >> Revision: 00 >> Title: Building Power-Efficient CoAP Devices for Cellular >> Networks >> Creation date: 2012-07-09 >> WG ID: Individual Submission >> Number of pages: 17 >> URL: >> http://www.ietf.org/internet-drafts/draft-arkko-core-cellular-00.txt >> Status: http://datatracker.ietf.org/doc/draft-arkko-core-cellul= ar >> Htmlized: http://tools.ietf.org/html/draft-arkko-core-cellular-00 >> >> >> Abstract: >> This memo discusses the use of the Constrained Application Protocol >> (CoAP) protocol in building sensors and other devices that employ >> cellular networks as a communications medium. Building communicatin= g >> devices that employ these networks is obviously well known, but this >> memo focuses specifically on techniques necessary to minimize power >> consumption. >> >> >> >> The IETF Secretariat >> > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From prvs=95576F1D24=guido.moritz@uni-rostock.de Sun Jul 29 04:53:20 2012 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 A737521F8670 for ; Sun, 29 Jul 2012 04:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.648 X-Spam-Level: X-Spam-Status: No, score=-2.648 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, 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 ks5d4sdUJnen for ; Sun, 29 Jul 2012 04:53:19 -0700 (PDT) Received: from mailrelay1.uni-rostock.de (mailrelay1.uni-rostock.de [139.30.8.201]) by ietfa.amsl.com (Postfix) with ESMTP id 40BA621F8666 for ; Sun, 29 Jul 2012 04:53:18 -0700 (PDT) From: Guido Moritz To: 'James Nguyen' , References: In-Reply-To: Date: Sun, 29 Jul 2012 13:53:41 +0200 Message-ID: <003901cd6d80$ccf433d0$66dc9b70$@uni-rostock.de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003A_01CD6D91.907E8A70" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG+sQMflhctYjfWeIYuipFguROCTwF9nNH2Ao0TOCaXPUlQAA== Content-Language: de X-Originating-IP: [84.139.177.27] Subject: Re: [core] User guide for jcoap 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, 29 Jul 2012 11:53:20 -0000 ------=_NextPart_000_003A_01CD6D91.907E8A70 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable James, =20 WS4D-jCoAP is an implementation of CoAP and not the result of this WG. = You should refer to the jCoAP project website = http://code.google.com/p/jcoap/ and if you still have questions contact = the WS4D folks directly (http://www.ws4d.org). =20 Best, Guido =20 Von: core-bounces@ietf.org [mailto:core-bounces@ietf.org] Im Auftrag von = James Nguyen Gesendet: Sonntag, 29. Juli 2012 08:33 An: core@ietf.org Betreff: [core] User guide for jcoap =20 =20 Hi, I'm interested in using jcoap. Does anyone have any document that shows = how to use it? Thanks, --=20 James Nguyen Email: james.huy.nguyen@gmail.com --=20 James Nguyen Email: james.huy.nguyen@gmail.com --=20 James Nguyen Email: james.huy.nguyen@gmail.com ------=_NextPart_000_003A_01CD6D91.907E8A70 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

James,

 

WS4D-jCoAP is an implementation of CoAP and not the result of this = WG. You should refer to the jCoAP project website http://code.google.com/p/jcoap/<= /a> and if you still have questions contact the WS4D folks directly (http://www.ws4d.org).<= /p>

 

Best,

Guido

 

Von:<= /b> = core-bounces@ietf.org [mailto:core-bounces@ietf.org] Im Auftrag von = James Nguyen
Gesendet: Sonntag, 29. Juli 2012 = 08:33
An: core@ietf.org
Betreff: [core] User guide = for jcoap

 

 

Hi,

I'm interested in using jcoap.  Does = anyone have any document that shows how to use it?

Thanks,

--
James Nguyen
Email: james.huy.nguyen@gmail.com




--
James = Nguyen
Email: james.huy.nguyen@gmail.com




--
James = Nguyen
Email: james.huy.nguyen@gmail.com=

------=_NextPart_000_003A_01CD6D91.907E8A70-- From zach@sensinode.com Sun Jul 29 22:15:24 2012 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 4F94F11E8088 for ; Sun, 29 Jul 2012 22:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.555 X-Spam-Level: X-Spam-Status: No, score=-3.555 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, 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 p0CE2n7Af+-8 for ; Sun, 29 Jul 2012 22:15:23 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 9E45311E80AD for ; Sun, 29 Jul 2012 22:15:20 -0700 (PDT) Received: from dhcp-4576.meeting.ietf.org (dhcp-4576.meeting.ietf.org [130.129.69.118]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q6U5FGBe009186 for ; Mon, 30 Jul 2012 08:15:17 +0300 From: Zach Shelby Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 29 Jul 2012 21:37:47 -0400 Message-Id: <3902E6E6-9667-44FF-B393-BF5F939EA1F8@sensinode.com> To: "core@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [core] Comments on draft-bormann-core-links-json-01 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, 30 Jul 2012 05:15:24 -0000 Carsten, I reviewed this draft, and definitely find it useful. In addition to = some detailed comments (will send directly to Carsten), I think there is = one meta-issue here. Do we want this JSON format to be a generic = representation of RFC5988 Web Links, or is this something really only = specific to the CoRE Link Format use of Web Linking? I think deciding on = that scope would help close some of the open questions in the draft. = Personally I find the later purpose really nice, but looking at the = bigger picture this should probably be as generic as possible. Definitely think this is something the WG should continue working on. = When communicating these CoRE Links from the constrained world to other = web applications, JSON provides a handy representation that is easy to = work with in high-level programming languages. Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From cabo@tzi.org Sun Jul 29 23:01:01 2012 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 3D45721F852E for ; Sun, 29 Jul 2012 23:01:01 -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 FVS-lw3HIqXN for ; Sun, 29 Jul 2012 23:01:00 -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 AE5FC21F851B for ; Sun, 29 Jul 2012 23:00:59 -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.3/8.14.3) with ESMTP id q6U60m8O024293; Mon, 30 Jul 2012 08:00:48 +0200 (CEST) Received: from dhcp-428c.meeting.ietf.org (unknown [130.129.66.140]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 6658DDC9; Mon, 30 Jul 2012 08:00:47 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <3902E6E6-9667-44FF-B393-BF5F939EA1F8@sensinode.com> Date: Sun, 29 Jul 2012 22:57:42 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3902E6E6-9667-44FF-B393-BF5F939EA1F8@sensinode.com> To: Zach Shelby X-Mailer: Apple Mail (2.1485) Cc: "core@ietf.org WG" Subject: Re: [core] Comments on draft-bormann-core-links-json-01 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, 30 Jul 2012 06:01:01 -0000 On Jul 29, 2012, at 18:37, Zach Shelby wrote: > Do we want this JSON format to be a generic representation of RFC5988 = Web Links, or is this something really only specific to the CoRE Link = Format use of Web Linking? I think deciding on that scope would help = close some of the open questions in the draft. Personally I find the = later purpose really nice, but looking at the bigger picture this should = probably be as generic as possible. I think the guiding principle should (as in most protocol design be): Generality is great if it costs nothing (or very, very little). When generality starts to make things complex or lose some of the = focused goodness of a proposal and it's not quite clear the the = important use cases require this complexity, you are almost always = better off doing the less general thing. http://en.wikipedia.org/wiki/You_ain't_gonna_need_it So, my questions would be: -- Do we know about any complexity that would come from making this a = general RFC5988 representation? (Such complexity may include the need for interfacing with other = groups, which can slow us down unless we know how to do it efficiently.) -- Do we lose something in the process? If we can be reasonably sure both are not the case, we should go for the = whole thing. Gr=FC=DFe, Carsten From matthieu.vi4l@gmail.com Mon Jul 30 00:49:54 2012 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 1FAC021F8610 for ; Mon, 30 Jul 2012 00:49:54 -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 axT9Y05Zq-SX for ; Mon, 30 Jul 2012 00:49:53 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1985D21F85DA for ; Mon, 30 Jul 2012 00:49:53 -0700 (PDT) Received: by yenq13 with SMTP id q13so4872393yen.31 for ; Mon, 30 Jul 2012 00:49:52 -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=0Z11OENUcpwl0jKH7RsppJcF2q8sL+7XpXbykdVZQDM=; b=eKjBeAzO2B1lAfes1YgRG/W1o0BSZfeX5ivUv6HHc7O4L9eu40MDwddHiAYyfpJae6 EZAU66eeLJa9bOHQlDT1dnVrG/SJBk5EoQejlyQ+NgHVsqktLQKxEVdQ2cRloQQcyqEc 3OOtoVX2GJRXfNClH1e7bkW22Q2MRzHyFi+YYKIWfez6ejIiMzoT4PpM+aGh4o3O4lPl TzwLKkkMcm3a1FGdnxzVAHTx76TgGUF6S3o8cledp0F8/MPcParwGpv9zFdufROmt4Ex Nk9REUA+zsqnEhDZmTZs7j88838aQBwUp1KghqY9w5yJOhd93mKq5Nh35tQ1bt3Clgcd UTjQ== MIME-Version: 1.0 Received: by 10.50.237.34 with SMTP id uz2mr10407738igc.19.1343634592505; Mon, 30 Jul 2012 00:49:52 -0700 (PDT) Received: by 10.50.87.230 with HTTP; Mon, 30 Jul 2012 00:49:52 -0700 (PDT) In-Reply-To: <1D0972C5226A7649BBB5E3734FCD593DA55BE4@DB3PRD0510MB393.eurprd05.prod.outlook.com> References: <20120711114256.8289.22566.idtracker@ietfa.amsl.com> <1D0972C5226A7649BBB5E3734FCD593DA55BE4@DB3PRD0510MB393.eurprd05.prod.outlook.com> Date: Mon, 30 Jul 2012 09:49:52 +0200 Message-ID: From: Matthieu Vial To: M Pouillot Content-Type: text/plain; charset=ISO-8859-1 Cc: "core@ietf.org WG" Subject: Re: [core] Fwd: New Version Notification for draft-shelby-core-interfaces-03.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, 30 Jul 2012 07:49:54 -0000 Hi Mathieu, > Great job on the binding mechanism, I have just little question about the 4.3. Why a profile should allow only one resource table per endpoint? What is the issue to have several bindings on one endpoint? In the draft, a binding table contains a list of bindings so it's possible to have several bindings on one endpoint. Also the draft proposes to centralize information about bindings in a unique resource containing the binding table for the endpoint. An alternative would be to derocate all resources with either a query string or a sub-resource to access binding information about the target resource. This solution may conflict with an already defined interface for the resource. Finally the centralized method makes life easier when we need to get all bindings at once. Some advanced servers running multiple virtual devices might need more than one binding table hence the SHOULD instead of a MUST. Matthieu From hannes.tschofenig@gmx.net Mon Jul 30 09:30:59 2012 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 E724711E80D1 for ; Mon, 30 Jul 2012 09:30:59 -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, HTML_MESSAGE=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 iUGpTo6+nUvD for ; Mon, 30 Jul 2012 09:30:59 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id DF45011E80A3 for ; Mon, 30 Jul 2012 09:30:58 -0700 (PDT) Received: (qmail invoked by alias); 30 Jul 2012 16:30:56 -0000 Received: from dhcp-172b.meeting.ietf.org (EHLO dhcp-172b.meeting.ietf.org) [130.129.23.43] by mail.gmx.net (mp032) with SMTP; 30 Jul 2012 18:30:56 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18IcaJdn10IMcSMRjGj4gYZaYTM8dA44vUcHm9vig ryrzmvO3RxdOjq From: Hannes Tschofenig Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-8-286434530 Date: Mon, 30 Jul 2012 09:30:54 -0700 References: <078c01cd68ef$b35643e0$1a02cba0$@iab.org> To: core CoRE Message-Id: X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [core] Fwd: IAB IPv6 privacy survey posted, response requested 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, 30 Jul 2012 16:31:00 -0000 --Apple-Mail-8-286434530 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hey guys,=20 I hope you have seen this request for feedback. It would be great to get = feedback from this community since iPv6 is a relevant protocol for smart = objects.=20 Ciao Hannes Begin forwarded message: > From: "IAB Chair" > Date: July 23, 2012 9:24:56 AM PDT > To: > Subject: IAB IPv6 privacy survey posted, response requested > Reply-To: iab@iab.org >=20 > The IAB is working on =91Privacy Considerations for Internet = Protocols=92. In order to better understand the implementation status = of IPv6 privacy mechanisms in operating system stacks, those familiar = with OS IPv6 implementations are asked to complete a short survey. The = survey responses will be used in a detailed write-up on IPv6 privacy; = privacy reviews of other IETF protocols are available here. > =20 > Please send responses to iab-ipv6-privacy-survey@i1b.org by August 13, = 2012. If you have questions, please send them to = iab-ipv6-privacy-survey@i1b.org. --Apple-Mail-8-286434530 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hey = guys, 

I hope you have seen this request for = feedback. It would be great to get feedback from this community since = iPv6 is a relevant protocol for smart = objects. 

Ciao
Hannes

Begin forwarded message:

From: "IAB Chair" <iab-chair@iab.org>
Date: July 23, 2012 = 9:24:56 AM PDT
To: <ietf-announce@ietf.org>
<= /span>
Subject: IAB IPv6 privacy survey posted, response = requested
Reply-To: iab@iab.org

The IAB is working on =91Privacy Considerations for Internet = Protocols=92.  In order to better understand the implementation = status of IPv6 privacy mechanisms in operating system stacks, those = familiar with OS IPv6 implementations are asked to complete a short = survey.  The survey responses will be used in a detailed = write-up on IPv6 privacy; privacy reviews of other IETF protocols are = available here.
 
=

= --Apple-Mail-8-286434530-- From cabo@tzi.org Tue Jul 31 17:35:55 2012 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 9830121F8863 for ; Tue, 31 Jul 2012 17:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.612 X-Spam-Level: X-Spam-Status: No, score=-106.612 tagged_above=-999 required=5 tests=[AWL=-0.363, 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 MxtRs0nUjDMs for ; Tue, 31 Jul 2012 17:35: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 D628021F8850 for ; Tue, 31 Jul 2012 17:35: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.3/8.14.3) with ESMTP id q710Zjg0021403 for ; Wed, 1 Aug 2012 02:35:45 +0200 (CEST) Received: from dhcp-9069.meeting.ietf.org (dhcp-9069.meeting.ietf.org [130.129.8.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 EB36577D; Wed, 1 Aug 2012 02:35:44 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Tue, 31 Jul 2012 17:35:42 -0700 To: "core@ietf.org WG" Message-Id: <99D7AE4C-C3D2-4BD7-8592-8C9E1CA796EE@tzi.org> Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) X-Mailer: Apple Mail (2.1485) Subject: [core] coap-misc version that addresses #241 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, 01 Aug 2012 00:35:55 -0000 I have just submitted a new version of coap-misc that contains an = attempt to address #241 (enabling protocol evolution in the presence of = proxies, section 7). I believe that is the last really big problem we need to solve. Unfortunately, it also causes one big, breaking change: renumbering all = options. (It also gets rid of fenceposts, which become a bit untenable with the = more complex numbering scheme. It works together with the longjumps that have been proposed in = coap-misc-19 already to solve #214, which have been updated for this, = too, section 3.2.1.) Htmlized: http://tools.ietf.org/html/draft-bormann-coap-misc-20 Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-bormann-coap-misc-20 We will need some time tomorrow to decide whether we need to solve this = problem, and which solution is right. Gr=FC=DFe, Carsten From cabo@tzi.org Tue Jul 31 22:58:17 2012 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 050E321F8564 for ; Tue, 31 Jul 2012 22:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.56 X-Spam-Level: X-Spam-Status: No, score=-106.56 tagged_above=-999 required=5 tests=[AWL=-0.311, 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 1wIxZ4tIuTPL for ; Tue, 31 Jul 2012 22:58:16 -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 38A5C21F8565 for ; Tue, 31 Jul 2012 22:58:15 -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.3/8.14.3) with ESMTP id q715w87V026261 for ; Wed, 1 Aug 2012 07:58:08 +0200 (CEST) Received: from dhcp-45ed.meeting.ietf.org (dhcp-45ed.meeting.ietf.org [130.129.69.237]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id E97297A1; Wed, 1 Aug 2012 07:58:07 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Carsten Bormann In-Reply-To: Date: Tue, 31 Jul 2012 22:58:05 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "core@ietf.org WG" X-Mailer: Apple Mail (2.1485) Subject: Re: [core] CoRE @ IETF84: Agenda V1.4 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, 01 Aug 2012 05:58:17 -0000 I have uploaded the mostly final agenda at: http://www.ietf.org/proceedings/84/agenda/agenda-84-core If your draft isn't on there already, it will be hard to accommodate it. Please check times, draft names etc. If I'm missing your objective for the slot, please tell me. Gr=FC=DFe, Carsten