From cabo@tzi.org Tue Nov 1 15:49:06 2011 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 322C411E815F for ; Tue, 1 Nov 2011 15:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.174 X-Spam-Level: X-Spam-Status: No, score=-106.174 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wQ9nDPdH-wmd for ; Tue, 1 Nov 2011 15:49:05 -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 4CF0611E815A for ; Tue, 1 Nov 2011 15:49:04 -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 pA1MmuGD004819 for ; Tue, 1 Nov 2011 23:48:56 +0100 (CET) Received: from [192.168.217.112] (p5489BB31.dip.t-dialin.net [84.137.187.49]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id B763F2E; Tue, 1 Nov 2011 23:48:52 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Tue, 1 Nov 2011 23:48:48 +0100 To: core WG Message-Id: <97F83FD9-93AC-4E44-9EFA-73D0C154EF82@tzi.org> Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Subject: [core] IETF82 CoRE agenda X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 22:49:06 -0000 I have uploaded a drafty agenda at: http://www.ietf.org/proceedings/82/agenda/core.txt I mainly tried to cover the drafts we should be looking at -- did I miss = any? The resulting shopping list is still short on objectives for most agenda = items. Those who want to achieve progress on specific drafts -- please send me = the objectives for the slot I have put your draft under, and please tell = me who will be presenting/leading the discussion. The agenda is way too full, and I probably even missed a lot of things = we also need to do, so we won't keep slots that don't have very = specific, credible objectives for this meeting. I plan to have a v2 agenda out 24 h from now. Gr=FC=DFe, Carsten From kerlyn2001@gmail.com Wed Nov 2 16:22:46 2011 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 919CF11E80AB for ; Wed, 2 Nov 2011 16:22:46 -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=[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 QhLG1fDhCeO7 for ; Wed, 2 Nov 2011 16:22:41 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id D69A711E8091 for ; Wed, 2 Nov 2011 16:22:39 -0700 (PDT) Received: by eyg24 with SMTP id 24so691540eyg.31 for ; Wed, 02 Nov 2011 16:22:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OTlhJ1iTDzGqB7bMFY1T48bCLGZ0Ti3CoWJQ88naaWQ=; b=f5omqdV9ft6DQ5W2CcYNLiNMb3OpRVLMz2jMUlCv9LL2OYeMy4U17Qs526RoajQW+h z6DcL2HCAgYLT9l7pCicorbg5KiJlamaq7QdA3Ja+3jmkrDsCTa2RORzibGZVGY07ZxN AK0mi9MLD1LGluRi0QL9fV8/RJ48wKa6oE70s= MIME-Version: 1.0 Received: by 10.14.17.84 with SMTP id i60mr607765eei.190.1320276157905; Wed, 02 Nov 2011 16:22:37 -0700 (PDT) Received: by 10.14.96.13 with HTTP; Wed, 2 Nov 2011 16:22:37 -0700 (PDT) In-Reply-To: <97F83FD9-93AC-4E44-9EFA-73D0C154EF82@tzi.org> References: <97F83FD9-93AC-4E44-9EFA-73D0C154EF82@tzi.org> Date: Wed, 2 Nov 2011 19:22:37 -0400 Message-ID: From: Kerry Lynn To: Carsten Bormann Content-Type: multipart/alternative; boundary=0016e65aefde65ba5504b0c8bf24 Cc: core WG Subject: Re: [core] IETF82 CoRE agenda X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 23:22:46 -0000 --0016e65aefde65ba5504b0c8bf24 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Carsten, I will be presenting the slides for draft-vanderstok-core-bc-05 on Peter's behalf and feel it would be better placed adjacent to the Naming and Discovery discussions on Friday. Thanks, -K- On Tue, Nov 1, 2011 at 6:48 PM, Carsten Bormann wrote: > I have uploaded a drafty agenda at: > > http://www.ietf.org/proceedings/82/agenda/core.txt > > I mainly tried to cover the drafts we should be looking at -- did I miss > any? > The resulting shopping list is still short on objectives for most agenda > items. > > Those who want to achieve progress on specific drafts -- please send me > the objectives for the slot I have put your draft under, and please tell = me > who will be presenting/leading the discussion. > > The agenda is way too full, and I probably even missed a lot of things we > also need to do, so we won't keep slots that don't have very specific, > credible objectives for this meeting. > > I plan to have a v2 agenda out 24 h from now. > > Gr=FC=DFe, Carsten > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --0016e65aefde65ba5504b0c8bf24 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Carsten,

I will be presenting the slides for draft-va= nderstok-core-bc-05 on Peter's
behalf and feel it would be be= tter placed adjacent to the Naming and
Discovery discussions on F= riday.

Thanks, -K-


On Tue, Nov 1, 2011 at 6:48 PM, Carsten Bormann <cabo@tzi.org> wrote:
I have uploaded a drafty agenda at:

=A0 =A0 =A0 =A0http://www.ietf.org/proceedings/82/agenda/core.txt

I mainly tried to cover the drafts we should be looking at -- did I miss an= y?
The resulting shopping list is still short on objectives for most agenda it= ems.

Those who want to achieve progress on specific drafts -- please send me the= objectives for the slot I have put your draft under, and please tell me wh= o will be presenting/leading the discussion.

The agenda is way too full, and I probably even missed a lot of things we a= lso need to do, so we won't keep slots that don't have very specifi= c, credible objectives for this meeting.

I plan to have a v2 agenda out 24 h from now.

Gr=FC=DFe, Carsten

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

--0016e65aefde65ba5504b0c8bf24-- From kerlyn2001@gmail.com Wed Nov 2 16:49:18 2011 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 8E3C211E80AB for ; Wed, 2 Nov 2011 16:49:18 -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=[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 wCFMdwzCws+F for ; Wed, 2 Nov 2011 16:49:18 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id D839311E8073 for ; Wed, 2 Nov 2011 16:49:17 -0700 (PDT) Received: by eyg24 with SMTP id 24so716333eyg.31 for ; Wed, 02 Nov 2011 16:49:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=5Jq9NSLPJ3joz5sTi3UEErQ5npdQU1/UgRfv3I5DRjU=; b=NR75qoo4P3bFW1vOwcywQ2TyjWEw11cVcHeEvkKyMAr9m3zQMYNYtpNqnh8JEooBIk Dzu6yaee+nGNjdDWEzgo3UvtKqp0LFSr49xO+HUFllpWZUMzOOG0IyHs62eCqXg3A22a 40jazS8u15OKbCExwa5eGC3ga14pHpV3kBB90= MIME-Version: 1.0 Received: by 10.14.9.225 with SMTP id 73mr637892eet.62.1320277756974; Wed, 02 Nov 2011 16:49:16 -0700 (PDT) Received: by 10.14.96.13 with HTTP; Wed, 2 Nov 2011 16:49:16 -0700 (PDT) Date: Wed, 2 Nov 2011 19:49:16 -0400 Message-ID: From: Kerry Lynn To: Jari Arkko Content-Type: multipart/alternative; boundary=0016364c629fb5964904b0c91e74 Cc: core Subject: Re: [core] draft-arkko-core-dev-urn-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: Wed, 02 Nov 2011 23:49:18 -0000 --0016364c629fb5964904b0c91e74 Content-Type: text/plain; charset=ISO-8859-1 Hi Jari, May I assume that you mean "device" in the conventional sense (a.k.a host, node, etc.) as the physical object that embodies functionality like server? If so, do you intend that there should be a 1:1 correspondence between device and DEV URN? I am thinking about devices that may have more than one i/f, and hence more than one MAC address. Would this device be known variously by more than one DEV URN, or is there a canonical way to select one from possibly many equivalent intrinsic identifiers? Thanks, -K- --0016364c629fb5964904b0c91e74 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Jari,

May I assume that you mean "device" i= n the conventional sense (a.k.a
host, node, etc.) as the physical= object that embodies functionality like
server? =A0If so, do you= intend that there should be a 1:1 correspondence
between device and DEV URN? =A0I am thinking about devices that may
have more than one i/f, and hence more than one MAC address. =A0Wou= ld
this device be known variously by more than one DEV URN, or is= there
a canonical way to select one from possibly many equivalent intrinsic<= /div>
identifiers?

Thanks, -K-
--0016364c629fb5964904b0c91e74-- From alper.yegin@yegin.org Thu Nov 3 06:49:35 2011 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 4B8FF11E808E for ; Thu, 3 Nov 2011 06:49:35 -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 Zoc-fkuXDJYl for ; Thu, 3 Nov 2011 06:49:34 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id C0A3911E8087 for ; Thu, 3 Nov 2011 06:49:34 -0700 (PDT) Received: from [10.187.138.253] ([38.127.222.254]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0MEG5w-1RAyF237LU-00FrZV; Thu, 03 Nov 2011 09:49:34 -0400 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1244.3) From: Alper Yegin In-Reply-To: <97F83FD9-93AC-4E44-9EFA-73D0C154EF82@tzi.org> Date: Thu, 3 Nov 2011 15:49:40 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <97F83FD9-93AC-4E44-9EFA-73D0C154EF82@tzi.org> To: core WG X-Mailer: Apple Mail (2.1244.3) X-Provags-ID: V02:K0:g1ZQj9UM2NqFyKgSjwT2nzldh3/ky30g8tzlznDMSCm /x57HFLOc5UiHRFtYfF6mGbh0EP9Kr7rbt9etbhBlEcUYJLCZ8 5yfS/smtFmsbShV9cV0Pk0JFMFypaS6h8cZT8j2EHDhB55N+Zk k1+40NDrQIQbdaFGHvpcOq54FdYOiBrV/7BIHI7FL8uqckb53x n3V1X6GrvssrGSIzGKZsMvIvSinjtuaKXTy+z2EPZSywQPDBEH Ofcx2xW1PK858CEHgIVCOERRCx7gb0+KVEDb/R66G1IPAQIqQ4 XjRevKpTkBbcjPGBJVBJ7RkqDnOnHImIlBy/PRR/99C40qMB5S YssEFzv70SH5Y+JlHbFsUbUKVn7IXQtRckBbNpU6CXkcwEfE/J ccQlrbvqWh/0w== Subject: [core] draft-yegin-coap-security 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, 03 Nov 2011 13:49:35 -0000 Folks, Please note the draft Zach and I produced for securing CoAP. http://tools.ietf.org/html/draft-yegin-coap-security-options-00 Comments are very welcome. Alper From cabo@tzi.org Thu Nov 3 08:59:07 2011 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 75F7A11E80D8 for ; Thu, 3 Nov 2011 08:59:06 -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=[AWL=-0.000, 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 RsCBouCLLsok for ; Thu, 3 Nov 2011 08:59:06 -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 9576211E80FC for ; Thu, 3 Nov 2011 08:59:05 -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 pA3FwuH4025870 for ; Thu, 3 Nov 2011 16:58:56 +0100 (CET) Received: from [192.168.217.112] (p5B3E6F9B.dip.t-dialin.net [91.62.111.155]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 6F41DE28; Thu, 3 Nov 2011 16:58:56 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <97F83FD9-93AC-4E44-9EFA-73D0C154EF82@tzi.org> Date: Thu, 3 Nov 2011 16:58:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <97F83FD9-93AC-4E44-9EFA-73D0C154EF82@tzi.org> To: core WG X-Mailer: Apple Mail (2.1251.1) Subject: Re: [core] IETF82 CoRE agenda X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 15:59:07 -0000 On Nov 1, 2011, at 23:48, Carsten Bormann wrote: > http://www.ietf.org/proceedings/82/agenda/core.txt >=20 > I plan to have a v2 agenda out 24 h from now. Updated with the info I received so far. If your draft is listed, but there are no objectives and/or no presenter = listed, please get that info to me now, because for v3 I'll have to = clean up some drafts from the Friday to make that meeting a bit more = realistic schedulewise. Gr=FC=DFe, Carsten From esko.dijk@philips.com Fri Nov 4 04:00:37 2011 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 37CD321F8C17 for ; Fri, 4 Nov 2011 04:00:37 -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 bASnDKpmM+ws for ; Fri, 4 Nov 2011 04:00:36 -0700 (PDT) Received: from AM1EHSOBE003.bigfish.com (am1ehsobe003.messaging.microsoft.com [213.199.154.206]) by ietfa.amsl.com (Postfix) with ESMTP id DCAF921F8C11 for ; Fri, 4 Nov 2011 04:00:35 -0700 (PDT) Received: from mail115-am1-R.bigfish.com (10.3.201.252) by AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id 14.1.225.22; Fri, 4 Nov 2011 11:00:17 +0000 Received: from mail115-am1 (localhost.localdomain [127.0.0.1]) by mail115-am1-R.bigfish.com (Postfix) with ESMTP id 74F4FF8838D; Fri, 4 Nov 2011 11:00:27 +0000 (UTC) X-SpamScore: -49 X-BigFish: VPS-49(zz217bL15d6O9251J1447M542M1432Nzz1202hzz1033IL8275dhz2dh2a8h668h839h944h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPVD:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-FB-SS: 0, Received: from mail115-am1 (localhost.localdomain [127.0.0.1]) by mail115-am1 (MessageSwitch) id 1320404427145735_13148; Fri, 4 Nov 2011 11:00:27 +0000 (UTC) Received: from AM1EHSMHS005.bigfish.com (unknown [10.3.201.251]) by mail115-am1.bigfish.com (Postfix) with ESMTP id 1A78E48004F; Fri, 4 Nov 2011 11:00:27 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by AM1EHSMHS005.bigfish.com (10.3.207.105) with Microsoft SMTP Server (TLS) id 14.1.225.22; Fri, 4 Nov 2011 11:00:16 +0000 Received: from 011-DB3MPN1-013.MGDPHG.emi.philips.com ([169.254.3.171]) by 011-DB3MMR1-001.MGDPHG.emi.philips.com ([10.128.28.51]) with mapi id 14.01.0339.002; Fri, 4 Nov 2011 11:00:33 +0000 From: "Dijk, Esko" To: "Kovatsch Matthias" , Likepeng Thread-Topic: [core] Status of Blockwise Transfers Thread-Index: AcyTA1LLgF2apeWtTByzRREkH8/sygEtchlQAA/NDpQAAOAYEAC2ZLlg Date: Fri, 4 Nov 2011 11:00:32 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618E387@011-DB3MPN1-013.MGDPHG.emi.philips.com> References: <55877B3AFB359744BA0F2140E36F52B51382ED5E@MBX10.d.ethz.ch> <031DD135F9160444ABBE3B0C36CED618D50B@011-DB3MPN1-013.MGDPHG.emi.philips.com> <34966E97BE8AD64EAE9D3D6E4DEE36F2CF8815@szxeml525-mbs.china.huawei.com> <55877B3AFB359744BA0F2140E36F52B513833019@MBX10.d.ethz.ch> In-Reply-To: <55877B3AFB359744BA0F2140E36F52B513833019@MBX10.d.ethz.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.101] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: "core@ietf.org" Subject: Re: [core] Status of Blockwise Transfers 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, 04 Nov 2011 11:00:37 -0000 Thank you both for your comments. > The author of the server implementations will just arbitrarily pick a sta= tus code, which still has no meaning. > A badly written client then might misinterpret that intermediate status. = I think, it only creates a source of errors. Still, it's not "arbitrarily pick a status code". Even though the intermedi= ate per-block status codes are not the status for the final operation, they= 're still needed. E.g. if the Nth block of a blockwise PUT returns 4.13 or = 5.00 the client knows to stop sending further blocks. We could look at it in another way: in essence the 2.01 and 2.04 codes from= core-coap are re-used by core-block as per-block status codes slightly dif= ferent meanings: 2.01 Will Be Created after successfully completing this blockwise = operation, Please Continue 2.04 Will Be Changed after successfully completing this blockwis= e operation, Please Continue at least for atomic blockwise PUT/POST. So the codes have some flavour of H= TTP 100 Continue as well and an early indication of what would happen. regards, Esko -----Original Message----- From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch] Sent: Monday 31 October 2011 20:24 To: Likepeng; Dijk, Esko; core@ietf.org Subject: RE: [core] Status of Blockwise Transfers Thanks for the responses! > > The current spec seems to already take this "most likely to happen" mea= ning > > for the status code in the examples, e.g. blockwise PUT returns 2.04 ea= ch > > time but if a block is missing the final result could still be 2.04 or = 4.00 or 4.08. > > POST could do the same? But what is most likely to happen? The author of the server implementations will just arbitrarily pick a statu= s code, which still has no meaning. A badly written client then might misinterpret that intermediate status. I = think, it only creates a source of errors. > > On your first point, concurrent Block1/Block2 usage, that seems only ap= plicable to POST or doesn't it? > From the spec, only concurrent POST is mentioned. Yes, that is how I understand it as well. A successful PUT would always res= ults in resource state, i.e., no payload in the response. > In the Size extension draft, I proposed to get the resource size by the S= ize option, and use concurrent GET for blocks. > http://www.ietf.org/id/draft-li-core-coap-size-option-02.txt I would say an upper bound (sz attribute) is enough. Embedded devices usual= ly avoid dynamic memory allocation and those which use it probably have ple= nty of memory from a CoRE point of view. For the concurrent GETs, one should be careful not to re-invent/implement T= CP (sliding window for messages in flight), I guess. If it is required, the= devices should rather switch to another protocol, shouldn't they? I also saw that even for the server it can be hard to know the exact size i= n advance. With content-negotiation, the representation is created on-the-f= ly from some variables. When including on-demand sensor readings, the serve= r cannot even do a "dry run" to pre-cache the sizes for each content-type. Best regards Matthias ________________________________ 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 salvatore.loreto@ericsson.com Fri Nov 4 10:21:56 2011 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 B9D481F0C3C for ; Fri, 4 Nov 2011 10:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 0Y-14afNpLI1 for ; Fri, 4 Nov 2011 10:21:55 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 65DE01F0C34 for ; Fri, 4 Nov 2011 10:21:55 -0700 (PDT) X-AuditID: c1b4fb39-b7b3eae00000252a-79-4eb41f32e021 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id A3.05.09514.23F14BE4; Fri, 4 Nov 2011 18:21:54 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Fri, 4 Nov 2011 18:21:53 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id B070D230A for ; Fri, 4 Nov 2011 19:21:53 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 6FCA551A67 for ; Fri, 4 Nov 2011 19:21:53 +0200 (EET) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id EC1D7519DC for ; Fri, 4 Nov 2011 19:21:52 +0200 (EET) Message-ID: <4EB41F30.3000108@ericsson.com> Date: Fri, 4 Nov 2011 18:21:52 +0100 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: core@ietf.org References: <20111031113719.3103.79998.idtracker@ietfa.amsl.com> In-Reply-To: <20111031113719.3103.79998.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------020604020209090006020500" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: Re: [core] I-D Action: draft-ietf-core-observe-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: Fri, 04 Nov 2011 17:21:56 -0000 --------------020604020209090006020500 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Hi, I have read the document, it is really in a good shape some comments: -in Section 1.1. Background I don't think the comparison with WebSocket is appropriate as COAP, differently from HTTP, has already natively the two-way communication between clients and servers; in CoAP each element can act as client/server So I would remove the last sentence in the last paragraph of the section: or to enable general two-way communication between clients and servers [I-D.ietf-hybi-thewebsocketprotocol ]. -in Section 1.3 Design Philosophy I don't agree on the similitude inserted in bracket of the first paragraph: (A server needs to keep track of the observers though, similar to how HTTP servers need to keep track of the TCP connections from their clients.) - more the last version of the draft introduces the Max-OFE, I don't recall that the concept has been discussed in the mailing list before, but most likely I have missed it. It is not clear to me the advantage of introducing a Max-OFE value versus to include directly the "optimistic freshness extension" time directly in the Max-Age: instead of having Max-Age of 60seconds and a MAX-OFE of 10seconds assigning directly to Max-Age a value of 70seconds cheers Salvatore -- Salvatore Loreto www.sloreto.com On 10/31/11 12:37 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments Working Group of the IETF. > > Title : Observing Resources in CoAP > Author(s) : Klaus Hartke > Zach Shelby > Filename : draft-ietf-core-observe-03.txt > Pages : 27 > Date : 2011-10-31 > > CoAP is a RESTful application protocol for constrained nodes and > networks. The state of a resource on a CoAP server can change over > time. This document specifies a simple protocol extension for CoAP > that gives clients the ability to observe such changes. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-core-observe-03.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-core-observe-03.txt > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --------------020604020209090006020500 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Hi,

I have read the document, it is really in a good shape
some comments:

-in Section 1.1. Background

I don't think the comparison with WebSocket is appropriate
as COAP, differently from HTTP, has already natively the two-way communication between
clients and servers; in CoAP each element can act as client/server
So I would remove the last sentence in the last paragraph of the section:
or to enable general two-way communication between clients
   and servers [I-D.ietf-hybi-thewebsocketprotocol].


-in Section 1.3 Design Philosophy

I don't agree on the similitude inserted in bracket of the first paragraph:

(A server needs to keep track of the observers
   though, similar to how HTTP servers need to keep track of the TCP
   connections from their clients.)

 - more the last version of the draft introduces the Max-OFE,
I don't recall that the concept has been discussed in the mailing list before,
but most likely I have missed it.
It is not clear to me the advantage of introducing a Max-OFE value
versus to include directly the "optimistic freshness extension" time directly in the Max-Age:
instead of having Max-Age of 60seconds and a MAX-OFE of 10seconds
assigning directly to Max-Age a value of 70seconds


cheers
Salvatore

-- 
Salvatore Loreto
www.sloreto.com



On 10/31/11 12:37 PM, internet-drafts@ietf.org wrote: 
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments Working Group of the IETF.

	Title           : Observing Resources in CoAP
	Author(s)       : Klaus Hartke
                          Zach Shelby
	Filename        : draft-ietf-core-observe-03.txt
	Pages           : 27
	Date            : 2011-10-31

   CoAP is a RESTful application protocol for constrained nodes and
   networks.  The state of a resource on a CoAP server can change over
   time.  This document specifies a simple protocol extension for CoAP
   that gives clients the ability to observe such changes.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-core-observe-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-core-observe-03.txt
_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core




  


--------------020604020209090006020500--

From cabo@tzi.org  Fri Nov  4 10:58:27 2011
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 1AC2D11E808B for ; Fri,  4 Nov 2011 10:58:27 -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 NSanNhqGfWaG for ; Fri,  4 Nov 2011 10:58:26 -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 4476E11E8085 for ; Fri,  4 Nov 2011 10:58:25 -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 pA4HwGBK004457; Fri, 4 Nov 2011 18:58:16 +0100 (CET)
Received: from [10.0.1.3] (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 6AD774A3; Fri,  4 Nov 2011 18:58:16 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann 
In-Reply-To: <4EB41F30.3000108@ericsson.com>
Date: Fri, 4 Nov 2011 18:58:16 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <515E0BF2-4FF0-49E4-B857-842749305380@tzi.org>
References: <20111031113719.3103.79998.idtracker@ietfa.amsl.com> <4EB41F30.3000108@ericsson.com>
To: Salvatore Loreto 
X-Mailer: Apple Mail (2.1251.1)
Cc: core@ietf.org
Subject: Re: [core] I-D Action: draft-ietf-core-observe-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: Fri, 04 Nov 2011 17:58:27 -0000

> I have read the document, it is really in a good shape

After doing my review, I agree.

> I don't think the comparison with WebSocket is appropriate
> as COAP, differently from HTTP, has already natively the two-way =
communication between
> clients and servers; in CoAP each element can act as client/server
> So I would remove the last sentence in the last paragraph of the =
section:
> or to enable general two-way communication between clients
>    and servers [
> I-D.ietf-hybi-thewebsocketprotocol].

I agree that this text is not essential.

> -in Section 1.3 Design Philosophy=20
>=20
> I don't agree on the similitude inserted in bracket of the first =
paragraph:
>=20
> (A server needs to keep track of the observers
>    though, similar to how HTTP servers need to keep track of the TCP
>    connections from their clients.)

I think this point is important, as people who think that HTTP is =
stateless always conveniently forget that e.g., for a long-poll, =
connection state has to be kept for a long time at the server.  An =
observation relationship is rather similar to this connection state, =
once you disregard the different layers.

So where do you see the limitations of that allegory?

>  - more the last version of the draft introduces the Max-OFE,
> I don't recall that the concept has been discussed in the mailing list =
before,
> but most likely I have missed it.
> It is not clear to me the advantage of introducing a Max-OFE value=20
> versus to include directly the "optimistic freshness extension" time =
directly in the Max-Age:
> instead of having Max-Age of 60seconds and a MAX-OFE of 10seconds=20
> assigning directly to Max-Age a value of 70seconds

I thought that, too, for a while.
One reason why it is useful to have both max-age and max-ofe is that, =
with a single value, there is no indication when it would be a good time =
to start trying to get a new value -- at a time when the existing value =
can still be used.
See RFC5861 (the, somewhat more complex, HTTP version of this concept) =
for more background.

Gr=FC=DFe, Carsten


From salvatore.loreto@ericsson.com  Fri Nov  4 12:28:49 2011
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 14BCC21F8AB8 for ; Fri,  4 Nov 2011 12:28:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.298
X-Spam-Level: 
X-Spam-Status: No, score=-106.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_48=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 f4fGRy9ew-0W for ; Fri,  4 Nov 2011 12:28:48 -0700 (PDT)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id A717A21F8663 for ; Fri,  4 Nov 2011 12:28:47 -0700 (PDT)
X-AuditID: c1b4fb39-b7b3eae00000252a-de-4eb43cee9566
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id DE.8B.09514.EEC34BE4; Fri,  4 Nov 2011 20:28:46 +0100 (CET)
Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Fri, 4 Nov 2011 20:28:46 +0100
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id 5627C2308; Fri,  4 Nov 2011 21:28:46 +0200 (EET)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 05DE6519D0; Fri,  4 Nov 2011 21:28:46 +0200 (EET)
Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 4AA235123D; Fri,  4 Nov 2011 21:28:45 +0200 (EET)
Message-ID: <4EB43CEC.3050402@ericsson.com>
Date: Fri, 4 Nov 2011 20:28:44 +0100
From: Salvatore Loreto 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Carsten Bormann 
References: <20111031113719.3103.79998.idtracker@ietfa.amsl.com> <4EB41F30.3000108@ericsson.com> <515E0BF2-4FF0-49E4-B857-842749305380@tzi.org>
In-Reply-To: <515E0BF2-4FF0-49E4-B857-842749305380@tzi.org>
Content-Type: multipart/alternative; boundary="------------070702060505070408020705"
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: AAAAAA==
Cc: "core@ietf.org" 
Subject: Re: [core] I-D Action: draft-ietf-core-observe-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: Fri, 04 Nov 2011 19:28:49 -0000

--------------070702060505070408020705
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit

Hi Carsten,

see in line

On 11/4/11 6:58 PM, Carsten Bormann wrote:
>> >  -in Section 1.3 Design Philosophy
>> >  
>> >  I don't agree on the similitude inserted in bracket of the first paragraph:
>> >  
>> >  (A server needs to keep track of the observers
>> >      though, similar to how HTTP servers need to keep track of the TCP
>> >      connections from their clients.)
> I think this point is important, as people who think that HTTP is stateless always conveniently forget that e.g., for a long-poll, connection state has to be kept for a long time at the server.  An observation relationship is rather similar to this connection state, once you disregard the different layers.
>
> So where do you see the limitations of that allegory?
now that you mentioned long-poll, the allegory starts to make some sense 
to me

as I said it is not clear from the context that the allegory is with 
HTTP long-poll mechanism;
while reading I understood the allegory was with the generic HTTP 
"persistent connections" independently
if they were or not at moment monopolized by long-polling requests

More in some sense the HTTP servers do not need to keep track of the 
connections used
by long-poll as they are monopolized by the long-poll requests

>> >    - more the last version of the draft introduces the Max-OFE,
>> >  I don't recall that the concept has been discussed in the mailing list before,
>> >  but most likely I have missed it.
>> >  It is not clear to me the advantage of introducing a Max-OFE value
>> >  versus to include directly the "optimistic freshness extension" time directly in the Max-Age:
>> >  instead of having Max-Age of 60seconds and a MAX-OFE of 10seconds
>> >  assigning directly to Max-Age a value of 70seconds
> I thought that, too, for a while.
> One reason why it is useful to have both max-age and max-ofe is that, with a single value, there is no indication when it would be a good time to start trying to get a new value -- at a time when the existing value can still be used.
> See RFC5861 (the, somewhat more complex, HTTP version of this concept) for more background.
thanks for the pointer, I didn't have it on the top of my mind..

I see the usefulness of the indication of trying to get a new value 
while still using the existing value,
and even more the need to issue a new GET request to re-register (if the 
client does not receive a new
notification before Max-Age+Max-OFE ends)interest.

however the current observe draft should specify a little deeply the 
usage of it by caches ...
if a client receive a stale value from the cache (through the issue of a 
plain GET) it does not become aware
of the fact that the value is a stale one,
RFC5861 states that

    Note that "stale" implies that the response will have a non-zero Age
        header and a warning header, as per HTTP's requirements.



Ciao
Salvatore

-- 
Salvatore Loreto
www.sloreto.com


>
> Grüße, Carsten
>


--------------070702060505070408020705
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit


  
    
  
  
    Hi Carsten,

    

    see in line

    

    On 11/4/11 6:58 PM, Carsten Bormann wrote:
    

      

        
> -in Section 1.3 Design Philosophy 
> 
> I don't agree on the similitude inserted in bracket of the first paragraph:
> 
> (A server needs to keep track of the observers
>    though, similar to how HTTP servers need to keep track of the TCP
>    connections from their clients.)


      

      
I think this point is important, as people who think that HTTP is stateless always conveniently forget that e.g., for a long-poll, connection state has to be kept for a long time at the server.  An observation relationship is rather similar to this connection state, once you disregard the different layers.

So where do you see the limitations of that allegory?

    

    now that you mentioned long-poll, the allegory starts to make some
    sense to me

    

    as I said it is not clear from the context that the allegory is with
    HTTP long-poll mechanism;

    while reading I understood the allegory was with the generic HTTP
    "persistent connections" independently

    if they were or not at moment monopolized by long-polling requests

    

    More in some sense the HTTP servers do not need to keep track of the
    connections used

    by long-poll as they are monopolized by the long-poll requests

    
    

    

      

      

        
>  - more the last version of the draft introduces the Max-OFE,
> I don't recall that the concept has been discussed in the mailing list before,
> but most likely I have missed it.
> It is not clear to me the advantage of introducing a Max-OFE value 
> versus to include directly the "optimistic freshness extension" time directly in the Max-Age:
> instead of having Max-Age of 60seconds and a MAX-OFE of 10seconds 
> assigning directly to Max-Age a value of 70seconds


      

      
I thought that, too, for a while.
One reason why it is useful to have both max-age and max-ofe is that, with a single value, there is no indication when it would be a good time to start trying to get a new value -- at a time when the existing value can still be used.
See RFC5861 (the, somewhat more complex, HTTP version of this concept) for more background.

    

    thanks for the pointer, I didn't have it on the top of my mind..

    

    I see the usefulness of the indication of trying to get a new value
    while still using the existing value,

    and even more the need to issue a new GET request to re-register (if
    the client does not receive a new

    notification before Max-Age+Max-OFE ends)interest.

    

    however the current observe draft should specify a little deeply the
    usage of it by caches ...

    if a client receive a stale value from the cache (through the issue
    of a plain GET) it does not become aware

    of the fact that the value is a stale one,

    RFC5861 states that

    
    

      
Note that "stale" implies that the response will have a non-zero Age
   header and a warning header, as per HTTP's requirements.

    

    

    

    Ciao

    Salvatore

    
-- 
Salvatore Loreto
www.sloreto.com

    

    

      

Grüße, Carsten



    

    

  


--------------070702060505070408020705--

From salvatore.loreto@ericsson.com  Sat Nov  5 11:41:10 2011
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 89E5121F86EC for ; Sat,  5 Nov 2011 11:41:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.538
X-Spam-Level: 
X-Spam-Status: No, score=-106.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 SCNZLYGdxbz6 for ; Sat,  5 Nov 2011 11:41:09 -0700 (PDT)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 5895E21F85A4 for ; Sat,  5 Nov 2011 11:41:09 -0700 (PDT)
X-AuditID: c1b4fb3d-b7c26ae0000035b9-2c-4eb5834283d5
Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id CF.5F.13753.24385BE4; Sat,  5 Nov 2011 19:41:06 +0100 (CET)
Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Sat, 5 Nov 2011 19:41:05 +0100
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id D3C7A230B; Sat,  5 Nov 2011 20:41:05 +0200 (EET)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 950E651A67; Sat,  5 Nov 2011 20:41:05 +0200 (EET)
Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 9AAD0515DF; Sat,  5 Nov 2011 20:41:00 +0200 (EET)
Message-ID: <4EB58338.3080609@ericsson.com>
Date: Sat, 5 Nov 2011 19:40:56 +0100
From: Salvatore Loreto 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: "core@ietf.org" ,  draft-li-core-coap-size-option@tools.ietf.org
Content-Type: multipart/alternative; boundary="------------090703040307000309040806"
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: AAAAAA==
Subject: [core] draft coap-size
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 05 Nov 2011 18:41:10 -0000

--------------090703040307000309040806
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

Hi there

I have read the 02 version of the draft
and I support the definition of the Size option as I think it is a 
useful option to be used in conjunction with Block.
About the inclusion/merge of it in Block draft I don't care.

some comments on the draft:

1) In section 2.2

    The GET request including Size=0 is treated as a request to get the
    size of the resource representation (but not the resource payload).

this is a duplication as you can already obtain the size of the resource 
using the Link Forma "sz" attribute.

more the above paragraph is not fully consistent with the sentence in 
Section 4.2

    For a GET request, if it includes an empty Size option, the Size
    option MUST be included in the response.


the above sentence does not specify if the response include the actual 
resource representation or not.


2) the following two paragraphs in Section 2.2 are not completely clear 
at least to me:

    If the Size option is specified it SHOULD be accurate at that time,
    and SHOULD NOT be an estimate.


    But due to the dynamic change of the resource data, the Size may not
    be accurate.  If the value of Size option is not the same as the
    actual transmitted data, the recipient MUST take the size of the
    actual transmitted data as accurate, and ignore the Size option.  In
    case that the recipient gets all the data but it is still smaller
    than the announced Size, the recipient SHOULD stop the transmission.
    If the recipient finds out the transmitted data reaches the Size
    limit, and there's more data left, the recipient SHOULD continue to
    transmit the remaining data.


cheers
Salvatore

-- 
Salvatore Loreto
www.sloreto.com


--------------090703040307000309040806
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit


  

    
  
  
    Hi there

    

    I have read the 02 version of the draft 

    and I support the definition of the Size option as I think it is a
    useful option to be used in conjunction with Block.

    About the inclusion/merge of it in Block draft I don't care.

    

    some comments on the draft:

    

    1) In section 2.2 

    

    
    
   The GET request including Size=0 is treated as a request to get the
   size of the resource representation (but not the resource payload).


    this is a duplication as you can already obtain the size of the
    resource using the Link Forma "sz" attribute.

    

    more the above paragraph is not fully consistent with the sentence
    in Section 4.2

    

    
    
   For a GET request, if it includes an empty Size option, the Size
   option MUST be included in the response.

    

    the above sentence does not specify if the response include the
    actual resource representation or not.

    

    

    2) the following two paragraphs in Section 2.2 are not completely
    clear at least to me:

    

    
    
   If the Size option is specified it SHOULD be accurate at that time,
   and SHOULD NOT be an estimate.


   But due to the dynamic change of the resource data, the Size may not
   be accurate.  If the value of Size option is not the same as the
   actual transmitted data, the recipient MUST take the size of the
   actual transmitted data as accurate, and ignore the Size option.  In
   case that the recipient gets all the data but it is still smaller
   than the announced Size, the recipient SHOULD stop the transmission.
   If the recipient finds out the transmitted data reaches the Size
   limit, and there's more data left, the recipient SHOULD continue to
   transmit the remaining data.

     

    cheers

    Salvatore

    
-- 
Salvatore Loreto
www.sloreto.com

  


--------------090703040307000309040806--

From likepeng@huawei.com  Sat Nov  5 13:29:00 2011
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 E32D721F8753 for ; Sat,  5 Nov 2011 13:29:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.708
X-Spam-Level: ***
X-Spam-Status: No, score=3.708 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553,  MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.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 CYmhvUKqAD79 for ; Sat,  5 Nov 2011 13:29:00 -0700 (PDT)
Received: from szxga03-in.huawei.com (unknown [58.251.152.66]) by ietfa.amsl.com (Postfix) with ESMTP id C6E3521F8726 for ; Sat,  5 Nov 2011 13:28:59 -0700 (PDT)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LU700DOXFK105@szxga03-in.huawei.com> for core@ietf.org; Sun, 06 Nov 2011 04:28:49 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LU700I3GFK1K6@szxga03-in.huawei.com> for core@ietf.org; Sun, 06 Nov 2011 04:28:49 +0800 (CST)
Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AEU01932; Sun, 06 Nov 2011 04:28:46 +0800
Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Sun, 06 Nov 2011 04:28:45 +0800
Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.177]) by szxeml403-hub.china.huawei.com ([10.82.67.35]) with mapi id 14.01.0270.001; Sun, 06 Nov 2011 04:28:36 +0800
Date: Sat, 05 Nov 2011 20:28:36 +0000
From: Likepeng 
In-reply-to: <4EB58338.3080609@ericsson.com>
X-Originating-IP: [172.24.2.41]
To: Salvatore Loreto , "core@ietf.org" 
Message-id: <34966E97BE8AD64EAE9D3D6E4DEE36F2D08EF8@szxeml525-mbs.china.huawei.com>
MIME-version: 1.0
Content-type: text/plain; charset=gb2312
Content-language: zh-CN
Content-transfer-encoding: base64
Accept-Language: zh-CN, en-US
Thread-topic: [core] draft coap-size
Thread-index: AQHMm+qB3mvH55N6pUWVHEWVt7gb15WesXUX
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References: <4EB58338.3080609@ericsson.com>
Subject: Re: [core] draft coap-size
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 05 Nov 2011 20:29:01 -0000

SGVsbG8gU2FsdmF0b3JlLA0KDQo+IEkgc3VwcG9ydCB0aGUgZGVmaW5pdGlvbiBvZiB0aGUgU2l6
ZSBvcHRpb24gYXMgSSB0aGluayBpdCBpcyBhIHVzZWZ1bCBvcHRpb24gdG8gYmUgdXNlZCBpbiBj
b25qdW5jdGlvbiB3aXRoIEJsb2NrLiANCj4gQWJvdXQgdGhlIGluY2x1c2lvbi9tZXJnZSBvZiBp
dCBpbiBCbG9jayBkcmFmdCBJIGRvbid0IGNhcmUuDQoNClRoYW5rcyBmb3IgdGhlIHJldmlldyBh
bmQgdGhlIHN1cHBvcnQuIA0KSSB3b3VsZCBwcmVmZXIgdG8gYmUgbWVyZ2VkIHdpdGggQmxvY2sg
ZHJhZnQsIGJ1dCBpZiB0aGUgV0cgZGVjaWRlcyB0byBiZSBzZXBhcmF0ZSwgdGhhdCBpcyBhbHNv
IGZpbmUgdG8gbWUuDQoNCj4xKSBJbiBzZWN0aW9uIDIuMiANCj4gICBUaGUgR0VUIHJlcXVlc3Qg
aW5jbHVkaW5nIFNpemU9MCBpcyB0cmVhdGVkIGFzIGEgcmVxdWVzdCB0byBnZXQgdGhlDQo+ICAg
c2l6ZSBvZiB0aGUgcmVzb3VyY2UgcmVwcmVzZW50YXRpb24gKGJ1dCBub3QgdGhlIHJlc291cmNl
IHBheWxvYWQpLg0KPnRoaXMgaXMgYSBkdXBsaWNhdGlvbiBhcyB5b3UgY2FuIGFscmVhZHkgb2J0
YWluIHRoZSBzaXplIG9mIHRoZSByZXNvdXJjZSB1c2luZyB0aGUgTGluayBGb3JtYSAic3oiIGF0
dHJpYnV0ZS4NCg0KWWVzLCBidXQgdGhlIHJlc291cmNlIHNpemUgZ290IGZyb20gInN6IiBhdHRy
aWJ1dGUgaXMgbm90IGFjY3VyYXRlLg0KDQo+bW9yZSB0aGUgYWJvdmUgcGFyYWdyYXBoIGlzIG5v
dCBmdWxseSBjb25zaXN0ZW50IHdpdGggdGhlIHNlbnRlbmNlIGluIFNlY3Rpb24gNC4yDQo+ICAg
Rm9yIGEgR0VUIHJlcXVlc3QsIGlmIGl0IGluY2x1ZGVzIGFuIGVtcHR5IFNpemUgb3B0aW9uLCB0
aGUgU2l6ZQ0KPiAgIG9wdGlvbiBNVVNUIGJlIGluY2x1ZGVkIGluIHRoZSByZXNwb25zZS4NCj50
aGUgYWJvdmUgc2VudGVuY2UgZG9lcyBub3Qgc3BlY2lmeSBpZiB0aGUgcmVzcG9uc2UgaW5jbHVk
ZSB0aGUgYWN0dWFsIHJlc291cmNlIHJlcHJlc2VudGF0aW9uIG9yIG5vdC4NCg0KVGhlIHJlc3Bv
bnNlIG5lZWRzIHRvIGluY2x1ZGUgdGhlIGFjdHVhbCByZXNvdXJjZSByZXByZXNlbnRhdGlvbiBm
b3IgdGhlIGluZGljYXRlZCBibG9jayBudW1iZXIuDQpJIHdpbGwgZml4IHRoZSB0ZXh0LiANCg0K
PjIpIHRoZSBmb2xsb3dpbmcgdHdvIHBhcmFncmFwaHMgaW4gU2VjdGlvbiAyLjIgYXJlIG5vdCBj
b21wbGV0ZWx5IGNsZWFyIGF0IGxlYXN0IHRvIG1lOg0KDQo+ICAgSWYgdGhlIFNpemUgb3B0aW9u
IGlzIHNwZWNpZmllZCBpdCBTSE9VTEQgYmUgYWNjdXJhdGUgYXQgdGhhdCB0aW1lLA0KPiAgIGFu
ZCBTSE9VTEQgTk9UIGJlIGFuIGVzdGltYXRlLg0KDQo+ICAgQnV0IGR1ZSB0byB0aGUgZHluYW1p
YyBjaGFuZ2Ugb2YgdGhlIHJlc291cmNlIGRhdGEsIHRoZSBTaXplIG1heSBub3QNCj4gICBiZSBh
Y2N1cmF0ZS4gIElmIHRoZSB2YWx1ZSBvZiBTaXplIG9wdGlvbiBpcyBub3QgdGhlIHNhbWUgYXMg
dGhlDQo+ICAgYWN0dWFsIHRyYW5zbWl0dGVkIGRhdGEsIHRoZSByZWNpcGllbnQgTVVTVCB0YWtl
IHRoZSBzaXplIG9mIHRoZQ0KPiAgIGFjdHVhbCB0cmFuc21pdHRlZCBkYXRhIGFzIGFjY3VyYXRl
LCBhbmQgaWdub3JlIHRoZSBTaXplIG9wdGlvbi4gIEluDQo+ICAgY2FzZSB0aGF0IHRoZSByZWNp
cGllbnQgZ2V0cyBhbGwgdGhlIGRhdGEgYnV0IGl0IGlzIHN0aWxsIHNtYWxsZXINCj4gICB0aGFu
IHRoZSBhbm5vdW5jZWQgU2l6ZSwgdGhlIHJlY2lwaWVudCBTSE9VTEQgc3RvcCB0aGUgdHJhbnNt
aXNzaW9uLg0KPiAgIElmIHRoZSByZWNpcGllbnQgZmluZHMgb3V0IHRoZSB0cmFuc21pdHRlZCBk
YXRhIHJlYWNoZXMgdGhlIFNpemUNCj4gICBsaW1pdCwgYW5kIHRoZXJlJ3MgbW9yZSBkYXRhIGxl
ZnQsIHRoZSByZWNpcGllbnQgU0hPVUxEIGNvbnRpbnVlIHRvDQo+ICB0cmFuc21pdCB0aGUgcmVt
YWluaW5nIGRhdGEuDQoNCkkgbWVhbiwgZm9yIHRoZSBkeW5hbWljIGRhdGEsIGR1cmluZyB0aGUg
dHJhbnNtaXNzaW9uLCB0aGUgcmVzb3VyY2Ugc2l6ZSBtYXkgYmUgY2hhbmdlZC4NCg0KSSBjYW4g
cmV2aXNlIHRoZSB0ZXh0IHRvIHNheToNCklmIHRoZSBTaXplIG9wdGlvbiBpcyBzcGVjaWZpZWQs
IGl0IE1VU1QgYmUgYWNjdXJhdGUgYXQgdGhhdCB0aW1lLg0KDQpBbmQgcmVtb3ZlIHRoZSBzZWNv
bmQgcGFyYWdyYXBoLCBiZWNhdXNlIGl0IGlzIG1vcmUgbGlrZSB0aGUgaW1wbGVtZW50YXRpb24g
cmVjb21tZW5kYXRpb24gb3Igc3RyYXRlZ3kuDQoNCktpbmQgUmVnYXJkcw0KS2VwZW5nDQoNCrei
vP7IyzogY29yZS1ib3VuY2VzQGlldGYub3JnIFtjb3JlLWJvdW5jZXNAaWV0Zi5vcmddILT6se0g
U2FsdmF0b3JlIExvcmV0byBbc2FsdmF0b3JlLmxvcmV0b0Blcmljc3Nvbi5jb21dDQq3osvNyrG8
5DogMjAxMcTqMTHUwjbI1SAyOjQwDQq1vTogY29yZUBpZXRmLm9yZzsgZHJhZnQtbGktY29yZS1j
b2FwLXNpemUtb3B0aW9uQHRvb2xzLmlldGYub3JnDQrW98ziOiBbY29yZV0gZHJhZnQgY29hcC1z
aXplDQoNCg0KSGkgdGhlcmUNCg0KSSBoYXZlIHJlYWQgdGhlIDAyIHZlcnNpb24gb2YgdGhlIGRy
YWZ0IA0KYW5kIEkgc3VwcG9ydCB0aGUgZGVmaW5pdGlvbiBvZiB0aGUgU2l6ZSBvcHRpb24gYXMg
SSB0aGluayBpdCBpcyBhIHVzZWZ1bCBvcHRpb24gdG8gYmUgdXNlZCBpbiBjb25qdW5jdGlvbiB3
aXRoIEJsb2NrLg0KQWJvdXQgdGhlIGluY2x1c2lvbi9tZXJnZSBvZiBpdCBpbiBCbG9jayBkcmFm
dCBJIGRvbid0IGNhcmUuDQoNCnNvbWUgY29tbWVudHMgb24gdGhlIGRyYWZ0Og0KDQoxKSBJbiBz
ZWN0aW9uIDIuMiANCg0KDQogICBUaGUgR0VUIHJlcXVlc3QgaW5jbHVkaW5nIFNpemU9MCBpcyB0
cmVhdGVkIGFzIGEgcmVxdWVzdCB0byBnZXQgdGhlDQogICBzaXplIG9mIHRoZSByZXNvdXJjZSBy
ZXByZXNlbnRhdGlvbiAoYnV0IG5vdCB0aGUgcmVzb3VyY2UgcGF5bG9hZCkuDQoNCnRoaXMgaXMg
YSBkdXBsaWNhdGlvbiBhcyB5b3UgY2FuIGFscmVhZHkgb2J0YWluIHRoZSBzaXplIG9mIHRoZSBy
ZXNvdXJjZSB1c2luZyB0aGUgTGluayBGb3JtYSAic3oiIGF0dHJpYnV0ZS4NCg0KbW9yZSB0aGUg
YWJvdmUgcGFyYWdyYXBoIGlzIG5vdCBmdWxseSBjb25zaXN0ZW50IHdpdGggdGhlIHNlbnRlbmNl
IGluIFNlY3Rpb24gNC4yDQoNCg0KICAgRm9yIGEgR0VUIHJlcXVlc3QsIGlmIGl0IGluY2x1ZGVz
IGFuIGVtcHR5IFNpemUgb3B0aW9uLCB0aGUgU2l6ZQ0KICAgb3B0aW9uIE1VU1QgYmUgaW5jbHVk
ZWQgaW4gdGhlIHJlc3BvbnNlLg0KDQp0aGUgYWJvdmUgc2VudGVuY2UgZG9lcyBub3Qgc3BlY2lm
eSBpZiB0aGUgcmVzcG9uc2UgaW5jbHVkZSB0aGUgYWN0dWFsIHJlc291cmNlIHJlcHJlc2VudGF0
aW9uIG9yIG5vdC4NCg0KDQoyKSB0aGUgZm9sbG93aW5nIHR3byBwYXJhZ3JhcGhzIGluIFNlY3Rp
b24gMi4yIGFyZSBub3QgY29tcGxldGVseSBjbGVhciBhdCBsZWFzdCB0byBtZToNCg0KDQogICBJ
ZiB0aGUgU2l6ZSBvcHRpb24gaXMgc3BlY2lmaWVkIGl0IFNIT1VMRCBiZSBhY2N1cmF0ZSBhdCB0
aGF0IHRpbWUsDQogICBhbmQgU0hPVUxEIE5PVCBiZSBhbiBlc3RpbWF0ZS4NCg0KDQogICBCdXQg
ZHVlIHRvIHRoZSBkeW5hbWljIGNoYW5nZSBvZiB0aGUgcmVzb3VyY2UgZGF0YSwgdGhlIFNpemUg
bWF5IG5vdA0KICAgYmUgYWNjdXJhdGUuICBJZiB0aGUgdmFsdWUgb2YgU2l6ZSBvcHRpb24gaXMg
bm90IHRoZSBzYW1lIGFzIHRoZQ0KICAgYWN0dWFsIHRyYW5zbWl0dGVkIGRhdGEsIHRoZSByZWNp
cGllbnQgTVVTVCB0YWtlIHRoZSBzaXplIG9mIHRoZQ0KICAgYWN0dWFsIHRyYW5zbWl0dGVkIGRh
dGEgYXMgYWNjdXJhdGUsIGFuZCBpZ25vcmUgdGhlIFNpemUgb3B0aW9uLiAgSW4NCiAgIGNhc2Ug
dGhhdCB0aGUgcmVjaXBpZW50IGdldHMgYWxsIHRoZSBkYXRhIGJ1dCBpdCBpcyBzdGlsbCBzbWFs
bGVyDQogICB0aGFuIHRoZSBhbm5vdW5jZWQgU2l6ZSwgdGhlIHJlY2lwaWVudCBTSE9VTEQgc3Rv
cCB0aGUgdHJhbnNtaXNzaW9uLg0KICAgSWYgdGhlIHJlY2lwaWVudCBmaW5kcyBvdXQgdGhlIHRy
YW5zbWl0dGVkIGRhdGEgcmVhY2hlcyB0aGUgU2l6ZQ0KICAgbGltaXQsIGFuZCB0aGVyZSdzIG1v
cmUgZGF0YSBsZWZ0LCB0aGUgcmVjaXBpZW50IFNIT1VMRCBjb250aW51ZSB0bw0KICAgdHJhbnNt
aXQgdGhlIHJlbWFpbmluZyBkYXRhLg0KIA0KY2hlZXJzDQpTYWx2YXRvcmUNCg0KLS0gDQpTYWx2
YXRvcmUgTG9yZXRvDQp3d3cuc2xvcmV0by5jb20=

From likepeng@huawei.com  Sat Nov  5 13:45:57 2011
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 0BFAA1F0C3C for ; Sat,  5 Nov 2011 13:45:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.357
X-Spam-Level: 
X-Spam-Status: No, score=-3.357 tagged_above=-999 required=5 tests=[AWL=-0.961, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c+W94MIFYEE8 for ; Sat,  5 Nov 2011 13:45:55 -0700 (PDT)
Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 5B8851F0C34 for ; Sat,  5 Nov 2011 13:45:55 -0700 (PDT)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LU700B6IGCIVC@szxga03-in.huawei.com> for core@ietf.org; Sun, 06 Nov 2011 04:45:54 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LU7008IGGCIC0@szxga03-in.huawei.com> for core@ietf.org; Sun, 06 Nov 2011 04:45:54 +0800 (CST)
Received: from szxeml206-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AEW45946; Sun, 06 Nov 2011 04:45:53 +0800
Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Sun, 06 Nov 2011 04:45:52 +0800
Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.177]) by szxeml411-hub.china.huawei.com ([10.82.67.138]) with mapi id 14.01.0270.001; Sun, 06 Nov 2011 04:45:46 +0800
Date: Sat, 05 Nov 2011 20:45:46 +0000
From: Likepeng 
In-reply-to: <55877B3AFB359744BA0F2140E36F52B513833019@MBX10.d.ethz.ch>
X-Originating-IP: [172.24.2.41]
To: Kovatsch Matthias , "Dijk, Esko" , "core@ietf.org" 
Message-id: <34966E97BE8AD64EAE9D3D6E4DEE36F2D09F16@szxeml525-mbs.china.huawei.com>
MIME-version: 1.0
Content-type: text/plain; charset=gb2312
Content-language: zh-CN
Content-transfer-encoding: base64
Accept-Language: zh-CN, en-US
Thread-topic: [core] Status of Blockwise Transfers
Thread-index: AcyTA1LLgF2apeWtTByzRREkH8/sygEtchlQAA/NDpQAAOAYEAD/fWmn
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References: <55877B3AFB359744BA0F2140E36F52B51382ED5E@MBX10.d.ethz.ch> <031DD135F9160444ABBE3B0C36CED618D50B@011-DB3MPN1-013.MGDPHG.emi.philips.com> <34966E97BE8AD64EAE9D3D6E4DEE36F2CF8815@szxeml525-mbs.china.huawei.com> <55877B3AFB359744BA0F2140E36F52B513833019@MBX10.d.ethz.ch>
Subject: Re: [core] Status of Blockwise Transfers
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 05 Nov 2011 20:45:57 -0000

SGVsbG8gTWF0dGhpYXMsDQoNCj4gSSB3b3VsZCBzYXkgYW4gdXBwZXIgYm91bmQgKHN6IGF0dHJp
YnV0ZSkgaXMgZW5vdWdoLiBFbWJlZGRlZCBkZXZpY2VzIHVzdWFsbHkgYXZvaWQgZHluYW1pYyBt
ZW1vcnkgYWxsb2NhdGlvbiBhbmQgdGhvc2Ugd2hpY2ggdXNlIGl0IHByb2JhYmx5IGhhdmUgcGxl
bnR5IG9mIG1lbW9yeSBmcm9tIGEgQ29SRSBwb2ludCBvZiB2aWV3Lg0KDQpTb21ldGltZXMsIHRo
ZSByZXNvdXJjZSB3aWxsIGJlIGNoYW5nZWQgYSBsb3QgYWZ0ZXIgdGhlIHJlc291cmNlIGRpc2Nv
dmVyeS4NCg0KPiBGb3IgdGhlIGNvbmN1cnJlbnQgR0VUcywgb25lIHNob3VsZCBiZSBjYXJlZnVs
IG5vdCB0byByZS1pbnZlbnQvaW1wbGVtZW50IFRDUCAoc2xpZGluZyB3aW5kb3cgZm9yIG1lc3Nh
Z2VzIGluIGZsaWdodCksIEkgZ3Vlc3MuIElmIGl0IGlzIHJlcXVpcmVkLCB0aGUgZGV2aWNlcyBz
aG91bGQgcmF0aGVyIHN3aXRjaCB0byBhbm90aGVyIHByb3RvY29sLCANCj4gc2hvdWxkbid0IHRo
ZXk/DQoNCkFncmVlLiBXZSBkb24ndCB3YW50IHRvIHJlLWludmVudC9pbXBsZW1lbnQgVENQIHNs
aWRpbmcgd2luZG93LiBJIGhhdmUgbm8gaW50ZW50aW9uIHRvIHByb3Bvc2UgdG8gYWRkIHRoZSBj
b25jdXJyZW50IEdFVCBmdW5jdGlvbiwganVzdCB0byBzYXksIGlmIHBlb3BsZSB3YW50IHRvIGlt
cGxlbWVudCB0aGlzIGZlYXR1cmUsIGhlcmUgaXMgc29tZXRoaW5nIHRoYXQgd291bGQgYmUgdXNl
ZnVsLg0KDQo+SSBhbHNvIHNhdyB0aGF0IGV2ZW4gZm9yIHRoZSBzZXJ2ZXIgaXQgY2FuIGJlIGhh
cmQgdG8ga25vdyB0aGUgZXhhY3Qgc2l6ZSBpbiBhZHZhbmNlLiBXaXRoIGNvbnRlbnQtbmVnb3Rp
YXRpb24sIHRoZSByZXByZXNlbnRhdGlvbiBpcyBjcmVhdGVkIG9uLXRoZS1mbHkgZnJvbSBzb21l
IHZhcmlhYmxlcy4gV2hlbiBpbmNsdWRpbmcgb24tZGVtYW5kID5zZW5zb3IgcmVhZGluZ3MsIHRo
ZSBzZXJ2ZXIgY2Fubm90IGV2ZW4gZG8gYSAiZHJ5IHJ1biIgdG8gcHJlLWNhY2hlIHRoZSBzaXpl
cyBmb3IgZWFjaCBjb250ZW50LXR5cGUuDQoNCkkgYWdyZWUgdGhhdCBzb21ldGltZXMgaXQgaXMg
ZGlmZmljdWx0IHRvIGtub3cgdGhlIHNpemUgaW4gYWR2YW5jZSwgYnV0IGluIG1vc3Qgb2YgdGhl
IGNhc2VzLCBpdCBjYW4gYmUga25vd24uDQoNClRoYW5rcywNCktpbmQgUmVnYXJkcw0KS2VwZW5n
DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IEtvdmF0
c2NoICBNYXR0aGlhcyBba292YXRzY2hAaW5mLmV0aHouY2hdDQq3osvNyrG85DogMjAxMcTqMTHU
wjHI1SAzOjI0DQq1vTogTGlrZXBlbmc7IERpamssIEVza287IGNvcmVAaWV0Zi5vcmcNCtb3zOI6
IFJFOiBbY29yZV0gU3RhdHVzIG9mIEJsb2Nrd2lzZSBUcmFuc2ZlcnMNCg0KVGhhbmtzIGZvciB0
aGUgcmVzcG9uc2VzIQ0KDQo+ID4gVGhlIGN1cnJlbnQgc3BlYyBzZWVtcyB0byBhbHJlYWR5IHRh
a2UgdGhpcyAibW9zdCBsaWtlbHkgdG8gaGFwcGVuIiBtZWFuaW5nDQo+ID4gZm9yIHRoZSBzdGF0
dXMgY29kZSBpbiB0aGUgZXhhbXBsZXMsIGUuZy4gYmxvY2t3aXNlIFBVVCByZXR1cm5zIDIuMDQg
ZWFjaA0KPiA+IHRpbWUgYnV0IGlmIGEgYmxvY2sgaXMgbWlzc2luZyB0aGUgZmluYWwgcmVzdWx0
IGNvdWxkIHN0aWxsIGJlIDIuMDQgb3IgNC4wMCBvciA0LjA4Lg0KPiA+IFBPU1QgY291bGQgZG8g
dGhlIHNhbWU/DQoNCkJ1dCB3aGF0IGlzIG1vc3QgbGlrZWx5IHRvIGhhcHBlbj8NClRoZSBhdXRo
b3Igb2YgdGhlIHNlcnZlciBpbXBsZW1lbnRhdGlvbnMgd2lsbCBqdXN0IGFyYml0cmFyaWx5IHBp
Y2sgYSBzdGF0dXMgY29kZSwgd2hpY2ggc3RpbGwgaGFzIG5vIG1lYW5pbmcuDQpBIGJhZGx5IHdy
aXR0ZW4gY2xpZW50IHRoZW4gbWlnaHQgbWlzaW50ZXJwcmV0IHRoYXQgaW50ZXJtZWRpYXRlIHN0
YXR1cy4gSSB0aGluaywgaXQgb25seSBjcmVhdGVzIGEgc291cmNlIG9mIGVycm9ycy4NCg0KPiA+
IE9uIHlvdXIgZmlyc3QgcG9pbnQsIGNvbmN1cnJlbnQgQmxvY2sxL0Jsb2NrMiB1c2FnZSwgdGhh
dCBzZWVtcyBvbmx5IGFwcGxpY2FibGUgdG8gUE9TVCBvciBkb2Vzbid0IGl0Pw0KPiBGcm9tIHRo
ZSBzcGVjLCBvbmx5IGNvbmN1cnJlbnQgUE9TVCBpcyBtZW50aW9uZWQuDQoNClllcywgdGhhdCBp
cyBob3cgSSB1bmRlcnN0YW5kIGl0IGFzIHdlbGwuIEEgc3VjY2Vzc2Z1bCBQVVQgd291bGQgYWx3
YXlzIHJlc3VsdHMgaW4gcmVzb3VyY2Ugc3RhdGUsIGkuZS4sIG5vIHBheWxvYWQgaW4gdGhlIHJl
c3BvbnNlLg0KDQo+IEluIHRoZSBTaXplIGV4dGVuc2lvbiBkcmFmdCwgSSBwcm9wb3NlZCB0byBn
ZXQgdGhlIHJlc291cmNlIHNpemUgYnkgdGhlIFNpemUgb3B0aW9uLCBhbmQgdXNlIGNvbmN1cnJl
bnQgR0VUIGZvciBibG9ja3MuDQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtbGktY29y
ZS1jb2FwLXNpemUtb3B0aW9uLTAyLnR4dA0KDQpJIHdvdWxkIHNheSBhbiB1cHBlciBib3VuZCAo
c3ogYXR0cmlidXRlKSBpcyBlbm91Z2guIEVtYmVkZGVkIGRldmljZXMgdXN1YWxseSBhdm9pZCBk
eW5hbWljIG1lbW9yeSBhbGxvY2F0aW9uIGFuZCB0aG9zZSB3aGljaCB1c2UgaXQgcHJvYmFibHkg
aGF2ZSBwbGVudHkgb2YgbWVtb3J5IGZyb20gYSBDb1JFIHBvaW50IG9mIHZpZXcuDQpGb3IgdGhl
IGNvbmN1cnJlbnQgR0VUcywgb25lIHNob3VsZCBiZSBjYXJlZnVsIG5vdCB0byByZS1pbnZlbnQv
aW1wbGVtZW50IFRDUCAoc2xpZGluZyB3aW5kb3cgZm9yIG1lc3NhZ2VzIGluIGZsaWdodCksIEkg
Z3Vlc3MuIElmIGl0IGlzIHJlcXVpcmVkLCB0aGUgZGV2aWNlcyBzaG91bGQgcmF0aGVyIHN3aXRj
aCB0byBhbm90aGVyIHByb3RvY29sLCBzaG91bGRuJ3QgdGhleT8NCkkgYWxzbyBzYXcgdGhhdCBl
dmVuIGZvciB0aGUgc2VydmVyIGl0IGNhbiBiZSBoYXJkIHRvIGtub3cgdGhlIGV4YWN0IHNpemUg
aW4gYWR2YW5jZS4gV2l0aCBjb250ZW50LW5lZ290aWF0aW9uLCB0aGUgcmVwcmVzZW50YXRpb24g
aXMgY3JlYXRlZCBvbi10aGUtZmx5IGZyb20gc29tZSB2YXJpYWJsZXMuIFdoZW4gaW5jbHVkaW5n
IG9uLWRlbWFuZCBzZW5zb3IgcmVhZGluZ3MsIHRoZSBzZXJ2ZXIgY2Fubm90IGV2ZW4gZG8gYSAi
ZHJ5IHJ1biIgdG8gcHJlLWNhY2hlIHRoZSBzaXplcyBmb3IgZWFjaCBjb250ZW50LXR5cGUuDQoN
CkJlc3QgcmVnYXJkcw0KTWF0dGhpYXM=

From salvatore.loreto@ericsson.com  Sun Nov  6 03:09:00 2011
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 5F71421F848D for ; Sun,  6 Nov 2011 03:09:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.324
X-Spam-Level: 
X-Spam-Status: No, score=-105.324 tagged_above=-999 required=5 tests=[AWL=-1.175, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, 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 w8df3hLvWLUW for ; Sun,  6 Nov 2011 03:08:59 -0800 (PST)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 124FC21F845D for ; Sun,  6 Nov 2011 03:08:58 -0800 (PST)
X-AuditID: c1b4fb39-b7b3eae00000252a-70-4eb66ac93035
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 75.61.09514.9CA66BE4; Sun,  6 Nov 2011 12:08:57 +0100 (CET)
Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Sun, 6 Nov 2011 12:08:57 +0100
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id 41076230D; Sun,  6 Nov 2011 13:08:57 +0200 (EET)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id D7AC051A0D; Sun,  6 Nov 2011 13:08:56 +0200 (EET)
Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 47AD6515DF; Sun,  6 Nov 2011 13:08:56 +0200 (EET)
Message-ID: <4EB66AC7.1090700@ericsson.com>
Date: Sun, 6 Nov 2011 12:08:55 +0100
From: Salvatore Loreto 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Likepeng 
References: <4EB58338.3080609@ericsson.com> <34966E97BE8AD64EAE9D3D6E4DEE36F2D08EF8@szxeml525-mbs.china.huawei.com>
In-Reply-To: <34966E97BE8AD64EAE9D3D6E4DEE36F2D08EF8@szxeml525-mbs.china.huawei.com>
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: AAAAAA==
Cc: "core@ietf.org" 
Subject: Re: [core] draft coap-size
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, 06 Nov 2011 11:09:00 -0000

Hi,

thanks for answering my questions, see more in line below

cheers

-- 
Salvatore Loreto
www.sloreto.com



On 11/5/11 9:28 PM, Likepeng wrote:
> Hello Salvatore,
>
>> I support the definition of the Size option as I think it is a useful option to be used in conjunction with Block. 
>> About the inclusion/merge of it in Block draft I don't care.
> Thanks for the review and the support. 
> I would prefer to be merged with Block draft, but if the WG decides to be separate, that is also fine to me.
>
>> 1) In section 2.2 
>>   The GET request including Size=0 is treated as a request to get the
>>   size of the resource representation (but not the resource payload).
>> this is a duplication as you can already obtain the size of the resource using the Link Forma "sz" attribute.
> Yes, but the resource size got from "sz" attribute is not accurate.
>
>> more the above paragraph is not fully consistent with the sentence in Section 4.2
>>   For a GET request, if it includes an empty Size option, the Size
>>   option MUST be included in the response.
>> the above sentence does not specify if the response include the actual resource representation or not.
> The response needs to include the actual resource representation for the indicated block number.
> I will fix the text. 

so you mean that a GET request including an empty Size option (or a
Size=0) will always include some payload
(i.e. the first block of the resource representation) or what...

I am OK with whatever you decide, but that should be clear in the text
and consistent in all the spec

>
>> 2) the following two paragraphs in Section 2.2 are not completely clear at least to me:
>>   If the Size option is specified it SHOULD be accurate at that time,
>>   and SHOULD NOT be an estimate.
>>   But due to the dynamic change of the resource data, the Size may not
>>   be accurate.  If the value of Size option is not the same as the
>>   actual transmitted data, the recipient MUST take the size of the
>>   actual transmitted data as accurate, and ignore the Size option.  In
>>   case that the recipient gets all the data but it is still smaller
>>   than the announced Size, the recipient SHOULD stop the transmission.
>>   If the recipient finds out the transmitted data reaches the Size
>>   limit, and there's more data left, the recipient SHOULD continue to
>>  transmit the remaining data.
> I mean, for the dynamic data, during the transmission, the resource size may be changed.
>
> I can revise the text to say:
> If the Size option is specified, it MUST be accurate at that time.
>
> And remove the second paragraph, because it is more like the implementation recommendation or strategy.

I don't think is an implementation recommendation,
IMO it should completely clear what happens when the Size changes during
a transfer (i.e. GET request)
for example the server could include in one of the answer transferring
one of the blocks the new Size...
however it is not clear when the Size changes if the changes in the
resource are only at the end of it...
it can also happen that the changes have effected some of the blocks
already transmitted
so what would be the behavior in this case


Cheers
/Sal

>
> Kind Regards
> Kepeng
>
> ·¢¼þÈË: core-bounces@ietf.org [core-bounces@ietf.org] ´ú±í Salvatore Loreto [salvatore.loreto@ericsson.com]
> ·¢ËÍʱ¼ä: 2011Äê11ÔÂ6ÈÕ 2:40
> µ½: core@ietf.org; draft-li-core-coap-size-option@tools.ietf.org
> Ö÷Ìâ: [core] draft coap-size
>
>
> Hi there
>
> I have read the 02 version of the draft 
> and I support the definition of the Size option as I think it is a useful option to be used in conjunction with Block.
> About the inclusion/merge of it in Block draft I don't care.
>
> some comments on the draft:
>
> 1) In section 2.2 
>
>
>    The GET request including Size=0 is treated as a request to get the
>    size of the resource representation (but not the resource payload).
>
> this is a duplication as you can already obtain the size of the resource using the Link Forma "sz" attribute.
>
> more the above paragraph is not fully consistent with the sentence in Section 4.2
>
>
>    For a GET request, if it includes an empty Size option, the Size
>    option MUST be included in the response.
>
> the above sentence does not specify if the response include the actual resource representation or not.
>
>
> 2) the following two paragraphs in Section 2.2 are not completely clear at least to me:
>
>
>    If the Size option is specified it SHOULD be accurate at that time,
>    and SHOULD NOT be an estimate.
>
>
>    But due to the dynamic change of the resource data, the Size may not
>    be accurate.  If the value of Size option is not the same as the
>    actual transmitted data, the recipient MUST take the size of the
>    actual transmitted data as accurate, and ignore the Size option.  In
>    case that the recipient gets all the data but it is still smaller
>    than the announced Size, the recipient SHOULD stop the transmission.
>    If the recipient finds out the transmitted data reaches the Size
>    limit, and there's more data left, the recipient SHOULD continue to
>    transmit the remaining data.
>  
> cheers
> Salvatore
>


From salvatore.loreto@ericsson.com  Sun Nov  6 03:34:16 2011
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 5D56A21F848B for ; Sun,  6 Nov 2011 03:34:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.381
X-Spam-Level: 
X-Spam-Status: No, score=-106.381 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, 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 BeOg0D4MOEvf for ; Sun,  6 Nov 2011 03:34:15 -0800 (PST)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 52BFA21F847F for ; Sun,  6 Nov 2011 03:34:15 -0800 (PST)
X-AuditID: c1b4fb3d-b7c26ae0000035b9-19-4eb670b67969
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id D0.86.13753.6B076BE4; Sun,  6 Nov 2011 12:34:14 +0100 (CET)
Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Sun, 6 Nov 2011 12:34:13 +0100
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id D2F47230D; Sun,  6 Nov 2011 13:34:13 +0200 (EET)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 7755D51A0D; Sun,  6 Nov 2011 13:34:13 +0200 (EET)
Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id E35F6515DF; Sun,  6 Nov 2011 13:34:12 +0200 (EET)
Message-ID: <4EB670B4.8070006@ericsson.com>
Date: Sun, 6 Nov 2011 12:34:12 +0100
From: Salvatore Loreto 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: draft-cao-core-pd@tools.ietf.org, "core@ietf.org" 
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: AAAAAA==
Subject: [core] about draft-cao-core-pd
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, 06 Nov 2011 11:34:16 -0000

Hi there,

how a CoAP client dynamically discovers a proxy to access the HTTP 
server is an interesting question

the mechanism you proposed in the draft is to use a multicast GET 
request to /.well-known-core
with a 'rt' parameter with the value "core-pd" is interesting

about this proposal it is not clear to me why you mandate that the 
address of the proxy is carried
within the Content payload;
why is it not enough for the sensor reading the source address of the 
answer?


thinking more about the issue,
I am wondering if instead of sending a multicast GET request to 
/.well-known/core
not would be more convenient and straightforward sending directly a 
multicast HTTP GET request
and doing so discover intrinsically the IP address of the proxy?

cheers
Salvatore

-- 
Salvatore Loreto
www.sloreto.com


From tianlinyi@huawei.com  Sun Nov  6 05:33:37 2011
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 AA89D21F847C for ; Sun,  6 Nov 2011 05:33:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.449
X-Spam-Level: **
X-Spam-Status: No, score=2.449 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345]
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 WJPurcBY09pM for ; Sun,  6 Nov 2011 05:33:36 -0800 (PST)
Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 819E021F8467 for ; Sun,  6 Nov 2011 05:33:36 -0800 (PST)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LU8000Q4QZYLS@szxga04-in.huawei.com> for core@ietf.org; Sun, 06 Nov 2011 21:33:34 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LU800814QZX2R@szxga04-in.huawei.com> for core@ietf.org; Sun, 06 Nov 2011 21:33:34 +0800 (CST)
Received: from szxeml208-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AEW50567; Sun, 06 Nov 2011 21:31:53 +0800
Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Sun, 06 Nov 2011 21:31:52 +0800
Received: from SZXEML513-MBX.china.huawei.com ([169.254.8.59]) by szxeml403-hub.china.huawei.com ([10.82.67.35]) with mapi id 14.01.0270.001; Sun, 06 Nov 2011 21:31:41 +0800
Date: Sun, 06 Nov 2011 13:31:41 +0000
From: TianLinyi 
In-reply-to: <4EB66AC7.1090700@ericsson.com>
X-Originating-IP: [172.24.2.40]
To: Salvatore Loreto , Likepeng 
Message-id: <3615F3CCD55F054395A882F51C6E5FDA181FB2AB@szxeml513-mbx.china.huawei.com>
MIME-version: 1.0
Content-type: text/plain; charset=gb2312
Content-language: zh-CN
Content-transfer-encoding: base64
Accept-Language: zh-CN, en-US
Thread-topic: [core] draft coap-size
Thread-index: AQHMm+qCfVZCBQs9iECFLaXIH+dEaZWeNQsAgAD19oCAAKzmzQ==
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References: <4EB58338.3080609@ericsson.com> <34966E97BE8AD64EAE9D3D6E4DEE36F2D08EF8@szxeml525-mbs.china.huawei.com> <4EB66AC7.1090700@ericsson.com>
Cc: "core@ietf.org" 
Subject: [core] =?gb2312?b?tPC4tDogIGRyYWZ0IGNvYXAtc2l6ZQ==?=
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, 06 Nov 2011 13:33:37 -0000

SGksIGFsbA0KDQpJIGJlbGlldmUgdGhlIHNpemUgb3B0aW9uIHNob3VsZCBiZSB1c2VkIGluIGNh
c2UgdGhlIGRhdGEgaXMgbm90IGNoYW5naW5nIGR1cmluZyB0aGUgd2hvbGUgdHJhbnNhY3Rpb24u
IElmIGl0IGNoYW5nZXMsIHRoZSBwcmV2aW91c2x5IHRyYW5zZmVycmVkIGJsb2NrIG1heSBiZSB1
c2VsZXNzLiBUaGlzIGhhcHBlbnMgcmVnYXJkaW5nbGVzcyB3aGV0aGVyIHRoZSBzaXplIG9wdGlv
biBpcyBhY2N1cmF0ZSBvciBub3QuIA0KDQpGb3IgZXhhbXBsZSwgaWYgdGhlIGNvYXAgc2VydmVy
IGlzIGNhcHR1cmluZyBhIHZpZGVvIHdoZW4geW91IGluaXRpYWwgdGhlIGJsb2NrIHRyYW5mZXIg
YXQgMTg6MDAgR01UIHlvdSBnZXQgYSB2aWRlbyB1bnRpbCB0aGF0IHRpbWUuIEV2ZW4gdGhvdWdo
IHRoZSB2aWRlbyBpcyBncm93aW5nIHlvdSB3aWxsIG9ubHkgZ2V0IHRoYXQgc25hcHNob3QuIFdo
ZW4geW91IGluaXRpYWwgYSBuZXcgYmxvY2sgdHJhbnNmZXIgeW91IHdpbGwgZ2V0IGEgbmV3IG9u
ZS4gDQoNCldlIG1heSBuZWVkIGEgbmV3IG1lY2hhbmlzbSB0byBpbmRpY2F0ZSB0aGUgY3VycmVu
dCB0cmFuc2ZlcnJlZCBibG9jayBpcyBubyBsb25nZXIgdmFsaWQgYSBuZXcgdHJhbnNhY3Rpb24g
aXMgbmVlZGVkLiANCg0KQ2hlZXJzLA0KTGlueWkNCg0KX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXw0Kt6K8/sjLOiBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcgW2NvcmUtYm91
bmNlc0BpZXRmLm9yZ10gtPqx7SBTYWx2YXRvcmUgTG9yZXRvIFtzYWx2YXRvcmUubG9yZXRvQGVy
aWNzc29uLmNvbV0NCreiy83KsbzkOiAyMDExxOoxMdTCNsjVIDE5OjA4DQq1vTogTGlrZXBlbmcN
CkNjOiBjb3JlQGlldGYub3JnDQrW98ziOiBSZTogW2NvcmVdIGRyYWZ0IGNvYXAtc2l6ZQ0KDQpI
aSwNCg0KdGhhbmtzIGZvciBhbnN3ZXJpbmcgbXkgcXVlc3Rpb25zLCBzZWUgbW9yZSBpbiBsaW5l
IGJlbG93DQoNCmNoZWVycw0KDQotLQ0KU2FsdmF0b3JlIExvcmV0bw0Kd3d3LnNsb3JldG8uY29t
DQoNCg0KDQpPbiAxMS81LzExIDk6MjggUE0sIExpa2VwZW5nIHdyb3RlOg0KPiBIZWxsbyBTYWx2
YXRvcmUsDQo+DQo+PiBJIHN1cHBvcnQgdGhlIGRlZmluaXRpb24gb2YgdGhlIFNpemUgb3B0aW9u
IGFzIEkgdGhpbmsgaXQgaXMgYSB1c2VmdWwgb3B0aW9uIHRvIGJlIHVzZWQgaW4gY29uanVuY3Rp
b24gd2l0aCBCbG9jay4NCj4+IEFib3V0IHRoZSBpbmNsdXNpb24vbWVyZ2Ugb2YgaXQgaW4gQmxv
Y2sgZHJhZnQgSSBkb24ndCBjYXJlLg0KPiBUaGFua3MgZm9yIHRoZSByZXZpZXcgYW5kIHRoZSBz
dXBwb3J0Lg0KPiBJIHdvdWxkIHByZWZlciB0byBiZSBtZXJnZWQgd2l0aCBCbG9jayBkcmFmdCwg
YnV0IGlmIHRoZSBXRyBkZWNpZGVzIHRvIGJlIHNlcGFyYXRlLCB0aGF0IGlzIGFsc28gZmluZSB0
byBtZS4NCj4NCj4+IDEpIEluIHNlY3Rpb24gMi4yDQo+PiAgIFRoZSBHRVQgcmVxdWVzdCBpbmNs
dWRpbmcgU2l6ZT0wIGlzIHRyZWF0ZWQgYXMgYSByZXF1ZXN0IHRvIGdldCB0aGUNCj4+ICAgc2l6
ZSBvZiB0aGUgcmVzb3VyY2UgcmVwcmVzZW50YXRpb24gKGJ1dCBub3QgdGhlIHJlc291cmNlIHBh
eWxvYWQpLg0KPj4gdGhpcyBpcyBhIGR1cGxpY2F0aW9uIGFzIHlvdSBjYW4gYWxyZWFkeSBvYnRh
aW4gdGhlIHNpemUgb2YgdGhlIHJlc291cmNlIHVzaW5nIHRoZSBMaW5rIEZvcm1hICJzeiIgYXR0
cmlidXRlLg0KPiBZZXMsIGJ1dCB0aGUgcmVzb3VyY2Ugc2l6ZSBnb3QgZnJvbSAic3oiIGF0dHJp
YnV0ZSBpcyBub3QgYWNjdXJhdGUuDQo+DQo+PiBtb3JlIHRoZSBhYm92ZSBwYXJhZ3JhcGggaXMg
bm90IGZ1bGx5IGNvbnNpc3RlbnQgd2l0aCB0aGUgc2VudGVuY2UgaW4gU2VjdGlvbiA0LjINCj4+
ICAgRm9yIGEgR0VUIHJlcXVlc3QsIGlmIGl0IGluY2x1ZGVzIGFuIGVtcHR5IFNpemUgb3B0aW9u
LCB0aGUgU2l6ZQ0KPj4gICBvcHRpb24gTVVTVCBiZSBpbmNsdWRlZCBpbiB0aGUgcmVzcG9uc2Uu
DQo+PiB0aGUgYWJvdmUgc2VudGVuY2UgZG9lcyBub3Qgc3BlY2lmeSBpZiB0aGUgcmVzcG9uc2Ug
aW5jbHVkZSB0aGUgYWN0dWFsIHJlc291cmNlIHJlcHJlc2VudGF0aW9uIG9yIG5vdC4NCj4gVGhl
IHJlc3BvbnNlIG5lZWRzIHRvIGluY2x1ZGUgdGhlIGFjdHVhbCByZXNvdXJjZSByZXByZXNlbnRh
dGlvbiBmb3IgdGhlIGluZGljYXRlZCBibG9jayBudW1iZXIuDQo+IEkgd2lsbCBmaXggdGhlIHRl
eHQuDQoNCnNvIHlvdSBtZWFuIHRoYXQgYSBHRVQgcmVxdWVzdCBpbmNsdWRpbmcgYW4gZW1wdHkg
U2l6ZSBvcHRpb24gKG9yIGENClNpemU9MCkgd2lsbCBhbHdheXMgaW5jbHVkZSBzb21lIHBheWxv
YWQNCihpLmUuIHRoZSBmaXJzdCBibG9jayBvZiB0aGUgcmVzb3VyY2UgcmVwcmVzZW50YXRpb24p
IG9yIHdoYXQuLi4NCg0KSSBhbSBPSyB3aXRoIHdoYXRldmVyIHlvdSBkZWNpZGUsIGJ1dCB0aGF0
IHNob3VsZCBiZSBjbGVhciBpbiB0aGUgdGV4dA0KYW5kIGNvbnNpc3RlbnQgaW4gYWxsIHRoZSBz
cGVjDQoNCj4NCj4+IDIpIHRoZSBmb2xsb3dpbmcgdHdvIHBhcmFncmFwaHMgaW4gU2VjdGlvbiAy
LjIgYXJlIG5vdCBjb21wbGV0ZWx5IGNsZWFyIGF0IGxlYXN0IHRvIG1lOg0KPj4gICBJZiB0aGUg
U2l6ZSBvcHRpb24gaXMgc3BlY2lmaWVkIGl0IFNIT1VMRCBiZSBhY2N1cmF0ZSBhdCB0aGF0IHRp
bWUsDQo+PiAgIGFuZCBTSE9VTEQgTk9UIGJlIGFuIGVzdGltYXRlLg0KPj4gICBCdXQgZHVlIHRv
IHRoZSBkeW5hbWljIGNoYW5nZSBvZiB0aGUgcmVzb3VyY2UgZGF0YSwgdGhlIFNpemUgbWF5IG5v
dA0KPj4gICBiZSBhY2N1cmF0ZS4gIElmIHRoZSB2YWx1ZSBvZiBTaXplIG9wdGlvbiBpcyBub3Qg
dGhlIHNhbWUgYXMgdGhlDQo+PiAgIGFjdHVhbCB0cmFuc21pdHRlZCBkYXRhLCB0aGUgcmVjaXBp
ZW50IE1VU1QgdGFrZSB0aGUgc2l6ZSBvZiB0aGUNCj4+ICAgYWN0dWFsIHRyYW5zbWl0dGVkIGRh
dGEgYXMgYWNjdXJhdGUsIGFuZCBpZ25vcmUgdGhlIFNpemUgb3B0aW9uLiAgSW4NCj4+ICAgY2Fz
ZSB0aGF0IHRoZSByZWNpcGllbnQgZ2V0cyBhbGwgdGhlIGRhdGEgYnV0IGl0IGlzIHN0aWxsIHNt
YWxsZXINCj4+ICAgdGhhbiB0aGUgYW5ub3VuY2VkIFNpemUsIHRoZSByZWNpcGllbnQgU0hPVUxE
IHN0b3AgdGhlIHRyYW5zbWlzc2lvbi4NCj4+ICAgSWYgdGhlIHJlY2lwaWVudCBmaW5kcyBvdXQg
dGhlIHRyYW5zbWl0dGVkIGRhdGEgcmVhY2hlcyB0aGUgU2l6ZQ0KPj4gICBsaW1pdCwgYW5kIHRo
ZXJlJ3MgbW9yZSBkYXRhIGxlZnQsIHRoZSByZWNpcGllbnQgU0hPVUxEIGNvbnRpbnVlIHRvDQo+
PiAgdHJhbnNtaXQgdGhlIHJlbWFpbmluZyBkYXRhLg0KPiBJIG1lYW4sIGZvciB0aGUgZHluYW1p
YyBkYXRhLCBkdXJpbmcgdGhlIHRyYW5zbWlzc2lvbiwgdGhlIHJlc291cmNlIHNpemUgbWF5IGJl
IGNoYW5nZWQuDQo+DQo+IEkgY2FuIHJldmlzZSB0aGUgdGV4dCB0byBzYXk6DQo+IElmIHRoZSBT
aXplIG9wdGlvbiBpcyBzcGVjaWZpZWQsIGl0IE1VU1QgYmUgYWNjdXJhdGUgYXQgdGhhdCB0aW1l
Lg0KPg0KPiBBbmQgcmVtb3ZlIHRoZSBzZWNvbmQgcGFyYWdyYXBoLCBiZWNhdXNlIGl0IGlzIG1v
cmUgbGlrZSB0aGUgaW1wbGVtZW50YXRpb24gcmVjb21tZW5kYXRpb24gb3Igc3RyYXRlZ3kuDQoN
CkkgZG9uJ3QgdGhpbmsgaXMgYW4gaW1wbGVtZW50YXRpb24gcmVjb21tZW5kYXRpb24sDQpJTU8g
aXQgc2hvdWxkIGNvbXBsZXRlbHkgY2xlYXIgd2hhdCBoYXBwZW5zIHdoZW4gdGhlIFNpemUgY2hh
bmdlcyBkdXJpbmcNCmEgdHJhbnNmZXIgKGkuZS4gR0VUIHJlcXVlc3QpDQpmb3IgZXhhbXBsZSB0
aGUgc2VydmVyIGNvdWxkIGluY2x1ZGUgaW4gb25lIG9mIHRoZSBhbnN3ZXIgdHJhbnNmZXJyaW5n
DQpvbmUgb2YgdGhlIGJsb2NrcyB0aGUgbmV3IFNpemUuLi4NCmhvd2V2ZXIgaXQgaXMgbm90IGNs
ZWFyIHdoZW4gdGhlIFNpemUgY2hhbmdlcyBpZiB0aGUgY2hhbmdlcyBpbiB0aGUNCnJlc291cmNl
IGFyZSBvbmx5IGF0IHRoZSBlbmQgb2YgaXQuLi4NCml0IGNhbiBhbHNvIGhhcHBlbiB0aGF0IHRo
ZSBjaGFuZ2VzIGhhdmUgZWZmZWN0ZWQgc29tZSBvZiB0aGUgYmxvY2tzDQphbHJlYWR5IHRyYW5z
bWl0dGVkDQpzbyB3aGF0IHdvdWxkIGJlIHRoZSBiZWhhdmlvciBpbiB0aGlzIGNhc2UNCg0KDQpD
aGVlcnMNCi9TYWwNCg0KPg0KPiBLaW5kIFJlZ2FyZHMNCj4gS2VwZW5nDQo+DQo+ILeivP7Iyzog
Y29yZS1ib3VuY2VzQGlldGYub3JnIFtjb3JlLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gU2FsdmF0
b3JlIExvcmV0byBbc2FsdmF0b3JlLmxvcmV0b0Blcmljc3Nvbi5jb21dDQo+ILeiy83KsbzkOiAy
MDExxOoxMdTCNsjVIDI6NDANCj4gtb06IGNvcmVAaWV0Zi5vcmc7IGRyYWZ0LWxpLWNvcmUtY29h
cC1zaXplLW9wdGlvbkB0b29scy5pZXRmLm9yZw0KPiDW98ziOiBbY29yZV0gZHJhZnQgY29hcC1z
aXplDQo+DQo+DQo+IEhpIHRoZXJlDQo+DQo+IEkgaGF2ZSByZWFkIHRoZSAwMiB2ZXJzaW9uIG9m
IHRoZSBkcmFmdA0KPiBhbmQgSSBzdXBwb3J0IHRoZSBkZWZpbml0aW9uIG9mIHRoZSBTaXplIG9w
dGlvbiBhcyBJIHRoaW5rIGl0IGlzIGEgdXNlZnVsIG9wdGlvbiB0byBiZSB1c2VkIGluIGNvbmp1
bmN0aW9uIHdpdGggQmxvY2suDQo+IEFib3V0IHRoZSBpbmNsdXNpb24vbWVyZ2Ugb2YgaXQgaW4g
QmxvY2sgZHJhZnQgSSBkb24ndCBjYXJlLg0KPg0KPiBzb21lIGNvbW1lbnRzIG9uIHRoZSBkcmFm
dDoNCj4NCj4gMSkgSW4gc2VjdGlvbiAyLjINCj4NCj4NCj4gICAgVGhlIEdFVCByZXF1ZXN0IGlu
Y2x1ZGluZyBTaXplPTAgaXMgdHJlYXRlZCBhcyBhIHJlcXVlc3QgdG8gZ2V0IHRoZQ0KPiAgICBz
aXplIG9mIHRoZSByZXNvdXJjZSByZXByZXNlbnRhdGlvbiAoYnV0IG5vdCB0aGUgcmVzb3VyY2Ug
cGF5bG9hZCkuDQo+DQo+IHRoaXMgaXMgYSBkdXBsaWNhdGlvbiBhcyB5b3UgY2FuIGFscmVhZHkg
b2J0YWluIHRoZSBzaXplIG9mIHRoZSByZXNvdXJjZSB1c2luZyB0aGUgTGluayBGb3JtYSAic3oi
IGF0dHJpYnV0ZS4NCj4NCj4gbW9yZSB0aGUgYWJvdmUgcGFyYWdyYXBoIGlzIG5vdCBmdWxseSBj
b25zaXN0ZW50IHdpdGggdGhlIHNlbnRlbmNlIGluIFNlY3Rpb24gNC4yDQo+DQo+DQo+ICAgIEZv
ciBhIEdFVCByZXF1ZXN0LCBpZiBpdCBpbmNsdWRlcyBhbiBlbXB0eSBTaXplIG9wdGlvbiwgdGhl
IFNpemUNCj4gICAgb3B0aW9uIE1VU1QgYmUgaW5jbHVkZWQgaW4gdGhlIHJlc3BvbnNlLg0KPg0K
PiB0aGUgYWJvdmUgc2VudGVuY2UgZG9lcyBub3Qgc3BlY2lmeSBpZiB0aGUgcmVzcG9uc2UgaW5j
bHVkZSB0aGUgYWN0dWFsIHJlc291cmNlIHJlcHJlc2VudGF0aW9uIG9yIG5vdC4NCj4NCj4NCj4g
MikgdGhlIGZvbGxvd2luZyB0d28gcGFyYWdyYXBocyBpbiBTZWN0aW9uIDIuMiBhcmUgbm90IGNv
bXBsZXRlbHkgY2xlYXIgYXQgbGVhc3QgdG8gbWU6DQo+DQo+DQo+ICAgIElmIHRoZSBTaXplIG9w
dGlvbiBpcyBzcGVjaWZpZWQgaXQgU0hPVUxEIGJlIGFjY3VyYXRlIGF0IHRoYXQgdGltZSwNCj4g
ICAgYW5kIFNIT1VMRCBOT1QgYmUgYW4gZXN0aW1hdGUuDQo+DQo+DQo+ICAgIEJ1dCBkdWUgdG8g
dGhlIGR5bmFtaWMgY2hhbmdlIG9mIHRoZSByZXNvdXJjZSBkYXRhLCB0aGUgU2l6ZSBtYXkgbm90
DQo+ICAgIGJlIGFjY3VyYXRlLiAgSWYgdGhlIHZhbHVlIG9mIFNpemUgb3B0aW9uIGlzIG5vdCB0
aGUgc2FtZSBhcyB0aGUNCj4gICAgYWN0dWFsIHRyYW5zbWl0dGVkIGRhdGEsIHRoZSByZWNpcGll
bnQgTVVTVCB0YWtlIHRoZSBzaXplIG9mIHRoZQ0KPiAgICBhY3R1YWwgdHJhbnNtaXR0ZWQgZGF0
YSBhcyBhY2N1cmF0ZSwgYW5kIGlnbm9yZSB0aGUgU2l6ZSBvcHRpb24uICBJbg0KPiAgICBjYXNl
IHRoYXQgdGhlIHJlY2lwaWVudCBnZXRzIGFsbCB0aGUgZGF0YSBidXQgaXQgaXMgc3RpbGwgc21h
bGxlcg0KPiAgICB0aGFuIHRoZSBhbm5vdW5jZWQgU2l6ZSwgdGhlIHJlY2lwaWVudCBTSE9VTEQg
c3RvcCB0aGUgdHJhbnNtaXNzaW9uLg0KPiAgICBJZiB0aGUgcmVjaXBpZW50IGZpbmRzIG91dCB0
aGUgdHJhbnNtaXR0ZWQgZGF0YSByZWFjaGVzIHRoZSBTaXplDQo+ICAgIGxpbWl0LCBhbmQgdGhl
cmUncyBtb3JlIGRhdGEgbGVmdCwgdGhlIHJlY2lwaWVudCBTSE9VTEQgY29udGludWUgdG8NCj4g
ICAgdHJhbnNtaXQgdGhlIHJlbWFpbmluZyBkYXRhLg0KPg0KPiBjaGVlcnMNCj4gU2FsdmF0b3Jl
DQo+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpj
b3JlIG1haWxpbmcgbGlzdA0KY29yZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9jb3Jl

From trac+core@trac.tools.ietf.org  Sun Nov  6 08:39:07 2011
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 EEC6521F84FC for ; Sun,  6 Nov 2011 08:39:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.544
X-Spam-Level: 
X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 GlQ9W5lTiK55 for ; Sun,  6 Nov 2011 08:39:07 -0800 (PST)
Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 6A89221F84F8 for ; Sun,  6 Nov 2011 08:39:07 -0800 (PST)
Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RN5kB-0008Ud-Jk; Sun, 06 Nov 2011 11:38:51 -0500
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
X-Trac-Project: core
Date: Sun, 06 Nov 2011 16:38:51 -0000
X-URL: http://tools.ietf.org/core/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/177
Message-ID: <051.f2c70308ab0d71f7798afa515a549f6b@trac.tools.ietf.org>
X-Trac-Ticket-ID: 177
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: 
Resent-Message-Id: <20111106163907.6A89221F84F8@ietfa.amsl.com>
Resent-Date: Sun,  6 Nov 2011 08:39:07 -0800 (PST)
Resent-From: trac+core@trac.tools.ietf.org
Cc: core@ietf.org
Subject: [core]  #177: Response suppression for multicast not defined
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: Sun, 06 Nov 2011 16:39:08 -0000

#177: Response suppression for multicast not defined

 Matthieu Vial reports:


 In section 4.1 multicast of coap 03 there is a proposition to eliminate
 responses with an error code

 This text has been removed in 07 and the text "SHOULD be a Non-confirmable
 request" is now a "MUST be Non-confirmable request".
 But as I understand coap 07 it is possible to send a response with an
 error code to a NON request as a NON response.
 So I think the text in coap 03 is now missing to avoid response floods.

 Carsten Bormann replies:

 indeed, as we fixed the layering here, we lost this functionality.

 So what the text in 07 says is that multicast needs to be NON, not CON.
 This is at the reliability layer.

 The error code becomes visible at the request/response layer.
 Independent of whether the request is a NON or a CON, if it does arrive,
 the server normally will send a response.
 1) It is up to the server to decide whether the response is sent in a CON,
 piggy-backed in an ACK (only applicable to CON requests, which we just
 excluded), or in a NON.
 2) We need to describe what the expectations are when a server does not
 send a response at all.  I think the server should always send a response
 for a request that arrived via a CON.  However, for a NON-request, it
 might as well pretend it never got the request.  This is a bit of a layer
 violation, as the reliability layer would indicate to the request/response
 layer wether the request was a NON and whether it came in by multicast.

 So yes, I think there should be new text in 4.4 that says the reliability
 layer does indicate to the r/r layer that this was a multicast.  There
 also should be text, probably in 5.2.3, that restores some form of silent
 behavior for requests that are "not applicable".  This needs to be defined
 a bit better, I think (even an empty 2.04 might qualify for a "not
 applicable" here, say in a link-format request with a query.  Note that
 section 4.1 of draft-ietf-core-link-format-07.txt also has something to
 say about multicast.

-- 
--------------------------------+------------------------------------
 Reporter:  cabo@…              |      Owner:  draft-ietf-core-coap@…
     Type:  protocol defect     |     Status:  new
 Priority:  major               |  Milestone:
Component:  coap                |    Version:
 Severity:  Active WG Document  |   Keywords:
--------------------------------+------------------------------------

Ticket URL: 
core 


From cabo@tzi.org  Sun Nov  6 08:41:02 2011
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 A87F521F851F for ; Sun,  6 Nov 2011 08:41:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.189
X-Spam-Level: 
X-Spam-Status: No, score=-106.189 tagged_above=-999 required=5 tests=[AWL=0.060, 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 rsMwQIAcGIzL for ; Sun,  6 Nov 2011 08:41:02 -0800 (PST)
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 BBEAD21F84FC for ; Sun,  6 Nov 2011 08:41:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id pA6GeqJR003744; Sun, 6 Nov 2011 17:40:52 +0100 (CET)
Received: from [192.168.217.110] (p5489B1B9.dip.t-dialin.net [84.137.177.185]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id AD9D870B; Sun,  6 Nov 2011 17:40:52 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann 
In-Reply-To: 
Date: Sun, 6 Nov 2011 17:40:51 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <8D33552E-1030-424C-A886-C55F85AD631A@tzi.org>
References: 
To: matthieu.vial@non.schneider-electric.com
X-Mailer: Apple Mail (2.1251.1)
Cc: core@ietf.org
Subject: Re: [core] Multicast and error codes
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, 06 Nov 2011 16:41:02 -0000

Matthieu,

thanks for reporting this; I have opened ticket #177 for this:

	http://trac.tools.ietf.org/wg/core/trac/ticket/177

Please see my work-in-progress response there.

Gr=FC=DFe, Carsten


On Oct 25, 2011, at 18:08, matthieu.vial@non.schneider-electric.com =
wrote:

> Hi all,
>=20
> In section 4.1 multicast of coap 03 there is a proposition to =
eliminate=20
> responses with an error code
>=20
> This text has been removed in 07 and the text "SHOULD be a =
Non-confirmable=20
> request" is now a "MUST be Non-confirmable request".
> But as I understand coap 07 it is possible to send a response with an=20=

> error code to a NON request as a NON response.
> So I think the text in coap 03 is now missing to avoid response =
floods.
> What do you think?
>=20
> Matthieu
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core


From salvatore.loreto@ericsson.com  Sun Nov  6 08:59:20 2011
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 4B41721F853B for ; Sun,  6 Nov 2011 08:59:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.108
X-Spam-Level: 
X-Spam-Status: No, score=-106.108 tagged_above=-999 required=5 tests=[AWL=-0.109, BAYES_00=-2.599, J_CHICKENPOX_33=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 k6bp+gqhnHT3 for ; Sun,  6 Nov 2011 08:59:19 -0800 (PST)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC4721F851F for ; Sun,  6 Nov 2011 08:59:19 -0800 (PST)
X-AuditID: c1b4fb3d-b7c26ae0000035b9-d7-4eb6bce66338
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id E1.4D.13753.6ECB6BE4; Sun,  6 Nov 2011 17:59:18 +0100 (CET)
Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Sun, 6 Nov 2011 17:59:17 +0100
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id B2413230D; Sun,  6 Nov 2011 18:59:17 +0200 (EET)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 5A8EA51A0D; Sun,  6 Nov 2011 18:59:17 +0200 (EET)
Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id C7D67515DF; Sun,  6 Nov 2011 18:59:16 +0200 (EET)
Message-ID: <4EB6BCE4.2050406@ericsson.com>
Date: Sun, 6 Nov 2011 17:59:16 +0100
From: Salvatore Loreto 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: draft-he-core-energy-aware-pd@tools.ietf.org,  "core@ietf.org" 
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: AAAAAA==
Subject: [core] draft-he-core-energy-aware-pd
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, 06 Nov 2011 16:59:20 -0000

Hi there,

the idea is interesting,
and it is quite similar to what I have proposed (with the necessary 
modifications) in my previous comment on draft core-pd-00:
i.e.the usage of a direct multicast request etc.etc.

however the section 3.2. Example is not correct or consistent with what 
you have stated before in the
draft indeed you there is no lifetime in the POST request
but the response is 2.01 Created and not 4.00 "Bad Request"

btw I would suggest that the absence of lifetime would not generate a 
4.00 "Bad Request" but instead
assume a default lifetime (e.g. 3600 seconds)

cheers
Salvatore

-- 
Salvatore Loreto
www.sloreto.com


From zehn.cao@gmail.com  Sun Nov  6 17:07:49 2011
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 8F2EF11E808A for ; Sun,  6 Nov 2011 17:07:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.824
X-Spam-Level: 
X-Spam-Status: No, score=-2.824 tagged_above=-999 required=5 tests=[AWL=0.775,  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 XlinQP1aZTO8 for ; Sun,  6 Nov 2011 17:07:49 -0800 (PST)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id DA49C11E8088 for ; Sun,  6 Nov 2011 17:07:48 -0800 (PST)
Received: by iaeo4 with SMTP id o4so6709346iae.31 for ; Sun, 06 Nov 2011 17:07:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=umkJs/jiT/UuCG6SDomviYuMAJATOm8RSS4AA+Evf14=; b=fWrIwI7R0rw70JmyQ3qdMX24zGixUX5rTLKPtCQPpatrgdZvK8zroRpgS5DCKfAFaD BEDpOn2Ui7Gqs9c7kzbicCF8qVgFZrZURSWCnmUypE3JTBnl9HECTN6Husfl3rasEh1r VdFJqjovyu8s8M4R58nAw9bYbn2l34zb1bsvo=
MIME-Version: 1.0
Received: by 10.42.158.9 with SMTP id f9mr41455818icx.31.1320628064379; Sun, 06 Nov 2011 17:07:44 -0800 (PST)
Received: by 10.42.164.133 with HTTP; Sun, 6 Nov 2011 17:07:44 -0800 (PST)
In-Reply-To: <4EB670B4.8070006@ericsson.com>
References: <4EB670B4.8070006@ericsson.com>
Date: Mon, 7 Nov 2011 09:07:44 +0800
Message-ID: 
From: Zhen Cao 
To: Salvatore Loreto 
Content-Type: text/plain; charset=ISO-8859-1
Cc: draft-cao-core-pd@tools.ietf.org, "core@ietf.org" 
Subject: Re: [core] about draft-cao-core-pd
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, 07 Nov 2011 01:07:49 -0000

Hi Salvatore,

Thanks for your comments.  See inline.

On Sun, Nov 6, 2011 at 7:34 PM, Salvatore Loreto
 wrote:
> Hi there,
>
> how a CoAP client dynamically discovers a proxy to access the HTTP server is
> an interesting question
>
> the mechanism you proposed in the draft is to use a multicast GET request to
> /.well-known-core
> with a 'rt' parameter with the value "core-pd" is interesting
>
> about this proposal it is not clear to me why you mandate that the address
> of the proxy is carried
> within the Content payload;
> why is it not enough for the sensor reading the source address of the
> answer?

We thought carrying the address in the payload could be used for
delegated case. But this should be discussed further.

>
>
> thinking more about the issue,
> I am wondering if instead of sending a multicast GET request to
> /.well-known/core
> not would be more convenient and straightforward sending directly a
> multicast HTTP GET request
> and doing so discover intrinsically the IP address of the proxy?

Are you saying that the sensor use HTTP GET ? But I think the
assumption is that the sensor is only CoAP capable, not HTTP capable.

For HTTP, I do not know if it has well known address that can be used
for discovery.

>
> cheers
> Salvatore
>
> --
> Salvatore Loreto
> www.sloreto.com
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>



-- 
Best regards,
Zhen

From matthieu.vial@non.schneider-electric.com  Mon Nov  7 01:16:27 2011
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 69D5A21F847A for ; Mon,  7 Nov 2011 01:16:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2QTbSRWFy2E for ; Mon,  7 Nov 2011 01:16:27 -0800 (PST)
Received: from mailX02.eud.schneider-electric.com (mailx02.eud.schneider-electric.com [205.167.7.38]) by ietfa.amsl.com (Postfix) with ESMTP id DA6EF21F845A for ; Mon,  7 Nov 2011 01:16:26 -0800 (PST)
Received: from ateui02.Schneider-Electric.com ([10.198.14.10]) by mailX02.eud.schneider-electric.com with ESMTP id 2011110709573057-181212 ; Mon, 7 Nov 2011 09:57:30 +0100 
In-Reply-To: <8D33552E-1030-424C-A886-C55F85AD631A@tzi.org>
To: Carsten Bormann 
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: Mon, 7 Nov 2011 10:16:21 +0100
X-MIMETrack: Serialize by Router on ATEUI02.Schneider-Electric.com/T/SVR/Schneider at 07/11/2011 10:16:24, Serialize complete at 07/11/2011 10:16:24, Itemize by SMTP Server on AXEU2OUT.schneider-electric.com/X/SVR/SEIxtra at 07/11/2011 09:57:30, Serialize by Router on AXEU2OUT.schneider-electric.com/X/SVR/SEIxtra at 07/11/2011 09:57:33, Serialize complete at 07/11/2011 09:57:33
Content-Type: text/plain; charset="US-ASCII"
Cc: core@ietf.org
Subject: Re: [core] Multicast and error codes
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, 07 Nov 2011 09:16:27 -0000

Hi Carsten,

>This needs to be defined
> a bit better, I think (even an empty 2.04 might qualify for a "not
> applicable" here, say in a link-format request with a query. 

I agree the term error code is rather restrictive. The "not applicable" 
flag may be relevant for success codes too.
Typically any response without payload has little value for a multicast 
request. But this condition might be simplistic as the options might 
provide useful information too. For example the location option in a "2.01 
Created" response to a POST or any new fancy option that may come later as 
an extension to the core spec. Anyway do you think that sending a 
non-idempotent multicast request is something wise?

> Note that
> section 4.1 of draft-ietf-core-link-format-07.txt also has something to
> say about multicast.
I agree that draft-ietf-core-link-format-07.txt should probably avoid 
empty responses to a multicast request.

Regards,
Matthieu

From likepeng@huawei.com  Mon Nov  7 02:04:10 2011
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 B404B21F8ABD for ; Mon,  7 Nov 2011 02:04:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.196
X-Spam-Level: 
X-Spam-Status: No, score=-3.196 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J4Zi3oIivdLg for ; Mon,  7 Nov 2011 02:04:09 -0800 (PST)
Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 98FC921F8ACE for ; Mon,  7 Nov 2011 02:04:09 -0800 (PST)
Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUA00FLEBW23W@szxga05-in.huawei.com> for core@ietf.org; Mon, 07 Nov 2011 18:02:26 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUA001P3BVTXP@szxga05-in.huawei.com> for core@ietf.org; Mon, 07 Nov 2011 18:02:26 +0800 (CST)
Received: from szxeml207-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AEU56299; Mon, 07 Nov 2011 18:02:25 +0800
Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 07 Nov 2011 18:02:24 +0800
Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.177]) by szxeml411-hub.china.huawei.com ([10.82.67.138]) with mapi id 14.01.0270.001; Mon, 07 Nov 2011 18:02:16 +0800
Date: Mon, 07 Nov 2011 10:02:15 +0000
From: Likepeng 
In-reply-to: <4EB66AC7.1090700@ericsson.com>
X-Originating-IP: [172.24.2.40]
To: Salvatore Loreto 
Message-id: <34966E97BE8AD64EAE9D3D6E4DEE36F2D0CB9E@szxeml525-mbs.china.huawei.com>
MIME-version: 1.0
Content-type: text/plain; charset=gb2312
Content-language: zh-CN
Content-transfer-encoding: base64
Accept-Language: zh-CN, en-US
Thread-topic: [core] draft coap-size
Thread-index: AQHMm+qB3mvH55N6pUWVHEWVt7gb15WesXUXgAB5jICAAgPPVw==
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References: <4EB58338.3080609@ericsson.com> <34966E97BE8AD64EAE9D3D6E4DEE36F2D08EF8@szxeml525-mbs.china.huawei.com> <4EB66AC7.1090700@ericsson.com>
Cc: "core@ietf.org" 
Subject: Re: [core] draft coap-size
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, 07 Nov 2011 10:04:10 -0000

SGkgU2FsdmF0b3JlLA0KDQo+c28geW91IG1lYW4gdGhhdCBhIEdFVCByZXF1ZXN0IGluY2x1ZGlu
ZyBhbiBlbXB0eSBTaXplIG9wdGlvbiAob3IgYQ0KPlNpemU9MCkgd2lsbCBhbHdheXMgaW5jbHVk
ZSBzb21lIHBheWxvYWQNCj4oaS5lLiB0aGUgZmlyc3QgYmxvY2sgb2YgdGhlIHJlc291cmNlIHJl
cHJlc2VudGF0aW9uKSBvciB3aGF0Li4uDQoNCklmIHRoZSBHRVQgcmVxdWVzdCBvbmx5IGluY2x1
ZGVzIEJsb2NrIG9wdGlvbiwgc2VydmVyIHdpbGwgcmV0dXJuIHRoZSBpbmRpY2F0ZWQgQmxvY2su
DQoNCklmIHRoZSBHRVQgcmVxdWVzdCBpbmNsdWRlcyBCbG9jayBvcHRpb24gYW5kIGFuIGVtcHR5
IFNpemUgb3B0aW9uIChvciBTaXplPTApLCB0aGUNCnNlcnZlciB3aWxsIHJldHVybiB0aGUgU2l6
ZSBvZiB0aGUgd2hvbGUgcmVzb3VyY2UgYW5kIHRoZSByZXF1ZXN0ZWQgQmxvY2suIFVzdWFsbHkg
dGhlDQpTaXplIG9wdGlvbiB3aWxsIGJlIHNlbnQgaW4gdGhlIGZpcnN0IGJsb2NrIHJlcXVlc3Qu
DQoNClNvLCBpbiB0aGlzIHdheSwgdGhlIGFkZGVkIFNpemUgb3B0aW9uIHdpbGwgbm90IGFmZmFj
dCB0aGUgbm9ybWFsIGJsb2NrIGJlaGF2aW9yLg0KDQpJZiB0aGlzIHNvdW5kcyByZWFzb25hYmxl
LCBJIHdpbGwgcmV2aXNlIHRoZSBkcmFmdCB0byBtYWtlIGl0IGNsZWFyLg0KDQo+SSBhbSBPSyB3
aXRoIHdoYXRldmVyIHlvdSBkZWNpZGUsIGJ1dCB0aGF0IHNob3VsZCBiZSBjbGVhciBpbiB0aGUg
dGV4dA0KPmFuZCBjb25zaXN0ZW50IGluIGFsbCB0aGUgc3BlYy4NCg0KU3VyZS4NCg0KVGhhbmtz
LA0KS2luZCBSZWdhcmRzDQpLZXBlbmcNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18NCreivP7IyzogU2FsdmF0b3JlIExvcmV0byBbc2FsdmF0b3JlLmxvcmV0b0Blcmlj
c3Nvbi5jb21dDQq3osvNyrG85DogMjAxMcTqMTHUwjbI1SAxOTowOA0Ktb06IExpa2VwZW5nDQpD
YzogY29yZUBpZXRmLm9yZw0K1vfM4jogUmU6IFtjb3JlXSBkcmFmdCBjb2FwLXNpemUNCg0KSGks
DQoNCnRoYW5rcyBmb3IgYW5zd2VyaW5nIG15IHF1ZXN0aW9ucywgc2VlIG1vcmUgaW4gbGluZSBi
ZWxvdw0KDQpjaGVlcnMNCg0KLS0NClNhbHZhdG9yZSBMb3JldG8NCnd3dy5zbG9yZXRvLmNvbQ0K
DQoNCg0KT24gMTEvNS8xMSA5OjI4IFBNLCBMaWtlcGVuZyB3cm90ZToNCj4gSGVsbG8gU2FsdmF0
b3JlLA0KPg0KPj4gSSBzdXBwb3J0IHRoZSBkZWZpbml0aW9uIG9mIHRoZSBTaXplIG9wdGlvbiBh
cyBJIHRoaW5rIGl0IGlzIGEgdXNlZnVsIG9wdGlvbiB0byBiZSB1c2VkIGluIGNvbmp1bmN0aW9u
IHdpdGggQmxvY2suDQo+PiBBYm91dCB0aGUgaW5jbHVzaW9uL21lcmdlIG9mIGl0IGluIEJsb2Nr
IGRyYWZ0IEkgZG9uJ3QgY2FyZS4NCj4gVGhhbmtzIGZvciB0aGUgcmV2aWV3IGFuZCB0aGUgc3Vw
cG9ydC4NCj4gSSB3b3VsZCBwcmVmZXIgdG8gYmUgbWVyZ2VkIHdpdGggQmxvY2sgZHJhZnQsIGJ1
dCBpZiB0aGUgV0cgZGVjaWRlcyB0byBiZSBzZXBhcmF0ZSwgdGhhdCBpcyBhbHNvIGZpbmUgdG8g
bWUuDQo+DQo+PiAxKSBJbiBzZWN0aW9uIDIuMg0KPj4gICBUaGUgR0VUIHJlcXVlc3QgaW5jbHVk
aW5nIFNpemU9MCBpcyB0cmVhdGVkIGFzIGEgcmVxdWVzdCB0byBnZXQgdGhlDQo+PiAgIHNpemUg
b2YgdGhlIHJlc291cmNlIHJlcHJlc2VudGF0aW9uIChidXQgbm90IHRoZSByZXNvdXJjZSBwYXls
b2FkKS4NCj4+IHRoaXMgaXMgYSBkdXBsaWNhdGlvbiBhcyB5b3UgY2FuIGFscmVhZHkgb2J0YWlu
IHRoZSBzaXplIG9mIHRoZSByZXNvdXJjZSB1c2luZyB0aGUgTGluayBGb3JtYSAic3oiIGF0dHJp
YnV0ZS4NCj4gWWVzLCBidXQgdGhlIHJlc291cmNlIHNpemUgZ290IGZyb20gInN6IiBhdHRyaWJ1
dGUgaXMgbm90IGFjY3VyYXRlLg0KPg0KPj4gbW9yZSB0aGUgYWJvdmUgcGFyYWdyYXBoIGlzIG5v
dCBmdWxseSBjb25zaXN0ZW50IHdpdGggdGhlIHNlbnRlbmNlIGluIFNlY3Rpb24gNC4yDQo+PiAg
IEZvciBhIEdFVCByZXF1ZXN0LCBpZiBpdCBpbmNsdWRlcyBhbiBlbXB0eSBTaXplIG9wdGlvbiwg
dGhlIFNpemUNCj4+ICAgb3B0aW9uIE1VU1QgYmUgaW5jbHVkZWQgaW4gdGhlIHJlc3BvbnNlLg0K
Pj4gdGhlIGFib3ZlIHNlbnRlbmNlIGRvZXMgbm90IHNwZWNpZnkgaWYgdGhlIHJlc3BvbnNlIGlu
Y2x1ZGUgdGhlIGFjdHVhbCByZXNvdXJjZSByZXByZXNlbnRhdGlvbiBvciBub3QuDQo+IFRoZSBy
ZXNwb25zZSBuZWVkcyB0byBpbmNsdWRlIHRoZSBhY3R1YWwgcmVzb3VyY2UgcmVwcmVzZW50YXRp
b24gZm9yIHRoZSBpbmRpY2F0ZWQgYmxvY2sgbnVtYmVyLg0KPiBJIHdpbGwgZml4IHRoZSB0ZXh0
Lg0KDQpzbyB5b3UgbWVhbiB0aGF0IGEgR0VUIHJlcXVlc3QgaW5jbHVkaW5nIGFuIGVtcHR5IFNp
emUgb3B0aW9uIChvciBhDQpTaXplPTApIHdpbGwgYWx3YXlzIGluY2x1ZGUgc29tZSBwYXlsb2Fk
DQooaS5lLiB0aGUgZmlyc3QgYmxvY2sgb2YgdGhlIHJlc291cmNlIHJlcHJlc2VudGF0aW9uKSBv
ciB3aGF0Li4uDQoNCkkgYW0gT0sgd2l0aCB3aGF0ZXZlciB5b3UgZGVjaWRlLCBidXQgdGhhdCBz
aG91bGQgYmUgY2xlYXIgaW4gdGhlIHRleHQNCmFuZCBjb25zaXN0ZW50IGluIGFsbCB0aGUgc3Bl
Yw0KDQo+DQo+PiAyKSB0aGUgZm9sbG93aW5nIHR3byBwYXJhZ3JhcGhzIGluIFNlY3Rpb24gMi4y
IGFyZSBub3QgY29tcGxldGVseSBjbGVhciBhdCBsZWFzdCB0byBtZToNCj4+ICAgSWYgdGhlIFNp
emUgb3B0aW9uIGlzIHNwZWNpZmllZCBpdCBTSE9VTEQgYmUgYWNjdXJhdGUgYXQgdGhhdCB0aW1l
LA0KPj4gICBhbmQgU0hPVUxEIE5PVCBiZSBhbiBlc3RpbWF0ZS4NCj4+ICAgQnV0IGR1ZSB0byB0
aGUgZHluYW1pYyBjaGFuZ2Ugb2YgdGhlIHJlc291cmNlIGRhdGEsIHRoZSBTaXplIG1heSBub3QN
Cj4+ICAgYmUgYWNjdXJhdGUuICBJZiB0aGUgdmFsdWUgb2YgU2l6ZSBvcHRpb24gaXMgbm90IHRo
ZSBzYW1lIGFzIHRoZQ0KPj4gICBhY3R1YWwgdHJhbnNtaXR0ZWQgZGF0YSwgdGhlIHJlY2lwaWVu
dCBNVVNUIHRha2UgdGhlIHNpemUgb2YgdGhlDQo+PiAgIGFjdHVhbCB0cmFuc21pdHRlZCBkYXRh
IGFzIGFjY3VyYXRlLCBhbmQgaWdub3JlIHRoZSBTaXplIG9wdGlvbi4gIEluDQo+PiAgIGNhc2Ug
dGhhdCB0aGUgcmVjaXBpZW50IGdldHMgYWxsIHRoZSBkYXRhIGJ1dCBpdCBpcyBzdGlsbCBzbWFs
bGVyDQo+PiAgIHRoYW4gdGhlIGFubm91bmNlZCBTaXplLCB0aGUgcmVjaXBpZW50IFNIT1VMRCBz
dG9wIHRoZSB0cmFuc21pc3Npb24uDQo+PiAgIElmIHRoZSByZWNpcGllbnQgZmluZHMgb3V0IHRo
ZSB0cmFuc21pdHRlZCBkYXRhIHJlYWNoZXMgdGhlIFNpemUNCj4+ICAgbGltaXQsIGFuZCB0aGVy
ZSdzIG1vcmUgZGF0YSBsZWZ0LCB0aGUgcmVjaXBpZW50IFNIT1VMRCBjb250aW51ZSB0bw0KPj4g
IHRyYW5zbWl0IHRoZSByZW1haW5pbmcgZGF0YS4NCj4gSSBtZWFuLCBmb3IgdGhlIGR5bmFtaWMg
ZGF0YSwgZHVyaW5nIHRoZSB0cmFuc21pc3Npb24sIHRoZSByZXNvdXJjZSBzaXplIG1heSBiZSBj
aGFuZ2VkLg0KPg0KPiBJIGNhbiByZXZpc2UgdGhlIHRleHQgdG8gc2F5Og0KPiBJZiB0aGUgU2l6
ZSBvcHRpb24gaXMgc3BlY2lmaWVkLCBpdCBNVVNUIGJlIGFjY3VyYXRlIGF0IHRoYXQgdGltZS4N
Cj4NCj4gQW5kIHJlbW92ZSB0aGUgc2Vjb25kIHBhcmFncmFwaCwgYmVjYXVzZSBpdCBpcyBtb3Jl
IGxpa2UgdGhlIGltcGxlbWVudGF0aW9uIHJlY29tbWVuZGF0aW9uIG9yIHN0cmF0ZWd5Lg0KDQpJ
IGRvbid0IHRoaW5rIGlzIGFuIGltcGxlbWVudGF0aW9uIHJlY29tbWVuZGF0aW9uLA0KSU1PIGl0
IHNob3VsZCBjb21wbGV0ZWx5IGNsZWFyIHdoYXQgaGFwcGVucyB3aGVuIHRoZSBTaXplIGNoYW5n
ZXMgZHVyaW5nDQphIHRyYW5zZmVyIChpLmUuIEdFVCByZXF1ZXN0KQ0KZm9yIGV4YW1wbGUgdGhl
IHNlcnZlciBjb3VsZCBpbmNsdWRlIGluIG9uZSBvZiB0aGUgYW5zd2VyIHRyYW5zZmVycmluZw0K
b25lIG9mIHRoZSBibG9ja3MgdGhlIG5ldyBTaXplLi4uDQpob3dldmVyIGl0IGlzIG5vdCBjbGVh
ciB3aGVuIHRoZSBTaXplIGNoYW5nZXMgaWYgdGhlIGNoYW5nZXMgaW4gdGhlDQpyZXNvdXJjZSBh
cmUgb25seSBhdCB0aGUgZW5kIG9mIGl0Li4uDQppdCBjYW4gYWxzbyBoYXBwZW4gdGhhdCB0aGUg
Y2hhbmdlcyBoYXZlIGVmZmVjdGVkIHNvbWUgb2YgdGhlIGJsb2Nrcw0KYWxyZWFkeSB0cmFuc21p
dHRlZA0Kc28gd2hhdCB3b3VsZCBiZSB0aGUgYmVoYXZpb3IgaW4gdGhpcyBjYXNlDQoNCg0KQ2hl
ZXJzDQovU2FsDQoNCj4NCj4gS2luZCBSZWdhcmRzDQo+IEtlcGVuZw0KPg0KPiC3orz+yMs6IGNv
cmUtYm91bmNlc0BpZXRmLm9yZyBbY29yZS1ib3VuY2VzQGlldGYub3JnXSC0+rHtIFNhbHZhdG9y
ZSBMb3JldG8gW3NhbHZhdG9yZS5sb3JldG9AZXJpY3Nzb24uY29tXQ0KPiC3osvNyrG85DogMjAx
McTqMTHUwjbI1SAyOjQwDQo+ILW9OiBjb3JlQGlldGYub3JnOyBkcmFmdC1saS1jb3JlLWNvYXAt
c2l6ZS1vcHRpb25AdG9vbHMuaWV0Zi5vcmcNCj4g1vfM4jogW2NvcmVdIGRyYWZ0IGNvYXAtc2l6
ZQ0KPg0KPg0KPiBIaSB0aGVyZQ0KPg0KPiBJIGhhdmUgcmVhZCB0aGUgMDIgdmVyc2lvbiBvZiB0
aGUgZHJhZnQNCj4gYW5kIEkgc3VwcG9ydCB0aGUgZGVmaW5pdGlvbiBvZiB0aGUgU2l6ZSBvcHRp
b24gYXMgSSB0aGluayBpdCBpcyBhIHVzZWZ1bCBvcHRpb24gdG8gYmUgdXNlZCBpbiBjb25qdW5j
dGlvbiB3aXRoIEJsb2NrLg0KPiBBYm91dCB0aGUgaW5jbHVzaW9uL21lcmdlIG9mIGl0IGluIEJs
b2NrIGRyYWZ0IEkgZG9uJ3QgY2FyZS4NCj4NCj4gc29tZSBjb21tZW50cyBvbiB0aGUgZHJhZnQ6
DQo+DQo+IDEpIEluIHNlY3Rpb24gMi4yDQo+DQo+DQo+ICAgIFRoZSBHRVQgcmVxdWVzdCBpbmNs
dWRpbmcgU2l6ZT0wIGlzIHRyZWF0ZWQgYXMgYSByZXF1ZXN0IHRvIGdldCB0aGUNCj4gICAgc2l6
ZSBvZiB0aGUgcmVzb3VyY2UgcmVwcmVzZW50YXRpb24gKGJ1dCBub3QgdGhlIHJlc291cmNlIHBh
eWxvYWQpLg0KPg0KPiB0aGlzIGlzIGEgZHVwbGljYXRpb24gYXMgeW91IGNhbiBhbHJlYWR5IG9i
dGFpbiB0aGUgc2l6ZSBvZiB0aGUgcmVzb3VyY2UgdXNpbmcgdGhlIExpbmsgRm9ybWEgInN6IiBh
dHRyaWJ1dGUuDQo+DQo+IG1vcmUgdGhlIGFib3ZlIHBhcmFncmFwaCBpcyBub3QgZnVsbHkgY29u
c2lzdGVudCB3aXRoIHRoZSBzZW50ZW5jZSBpbiBTZWN0aW9uIDQuMg0KPg0KPg0KPiAgICBGb3Ig
YSBHRVQgcmVxdWVzdCwgaWYgaXQgaW5jbHVkZXMgYW4gZW1wdHkgU2l6ZSBvcHRpb24sIHRoZSBT
aXplDQo+ICAgIG9wdGlvbiBNVVNUIGJlIGluY2x1ZGVkIGluIHRoZSByZXNwb25zZS4NCj4NCj4g
dGhlIGFib3ZlIHNlbnRlbmNlIGRvZXMgbm90IHNwZWNpZnkgaWYgdGhlIHJlc3BvbnNlIGluY2x1
ZGUgdGhlIGFjdHVhbCByZXNvdXJjZSByZXByZXNlbnRhdGlvbiBvciBub3QuDQo+DQo+DQo+IDIp
IHRoZSBmb2xsb3dpbmcgdHdvIHBhcmFncmFwaHMgaW4gU2VjdGlvbiAyLjIgYXJlIG5vdCBjb21w
bGV0ZWx5IGNsZWFyIGF0IGxlYXN0IHRvIG1lOg0KPg0KPg0KPiAgICBJZiB0aGUgU2l6ZSBvcHRp
b24gaXMgc3BlY2lmaWVkIGl0IFNIT1VMRCBiZSBhY2N1cmF0ZSBhdCB0aGF0IHRpbWUsDQo+ICAg
IGFuZCBTSE9VTEQgTk9UIGJlIGFuIGVzdGltYXRlLg0KPg0KPg0KPiAgICBCdXQgZHVlIHRvIHRo
ZSBkeW5hbWljIGNoYW5nZSBvZiB0aGUgcmVzb3VyY2UgZGF0YSwgdGhlIFNpemUgbWF5IG5vdA0K
PiAgICBiZSBhY2N1cmF0ZS4gIElmIHRoZSB2YWx1ZSBvZiBTaXplIG9wdGlvbiBpcyBub3QgdGhl
IHNhbWUgYXMgdGhlDQo+ICAgIGFjdHVhbCB0cmFuc21pdHRlZCBkYXRhLCB0aGUgcmVjaXBpZW50
IE1VU1QgdGFrZSB0aGUgc2l6ZSBvZiB0aGUNCj4gICAgYWN0dWFsIHRyYW5zbWl0dGVkIGRhdGEg
YXMgYWNjdXJhdGUsIGFuZCBpZ25vcmUgdGhlIFNpemUgb3B0aW9uLiAgSW4NCj4gICAgY2FzZSB0
aGF0IHRoZSByZWNpcGllbnQgZ2V0cyBhbGwgdGhlIGRhdGEgYnV0IGl0IGlzIHN0aWxsIHNtYWxs
ZXINCj4gICAgdGhhbiB0aGUgYW5ub3VuY2VkIFNpemUsIHRoZSByZWNpcGllbnQgU0hPVUxEIHN0
b3AgdGhlIHRyYW5zbWlzc2lvbi4NCj4gICAgSWYgdGhlIHJlY2lwaWVudCBmaW5kcyBvdXQgdGhl
IHRyYW5zbWl0dGVkIGRhdGEgcmVhY2hlcyB0aGUgU2l6ZQ0KPiAgICBsaW1pdCwgYW5kIHRoZXJl
J3MgbW9yZSBkYXRhIGxlZnQsIHRoZSByZWNpcGllbnQgU0hPVUxEIGNvbnRpbnVlIHRvDQo+ICAg
IHRyYW5zbWl0IHRoZSByZW1haW5pbmcgZGF0YS4NCj4NCj4gY2hlZXJzDQo+IFNhbHZhdG9yZQ0K
Pg==

From trac+core@trac.tools.ietf.org  Mon Nov  7 04:56:04 2011
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 88D0821F8B4F for ; Mon,  7 Nov 2011 04:56:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.549
X-Spam-Level: 
X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 o0VlOi9aVSNV for ; Mon,  7 Nov 2011 04:56:00 -0800 (PST)
Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id AC85B21F8B32 for ; Mon,  7 Nov 2011 04:55:58 -0800 (PST)
Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RNOk1-00020K-26; Mon, 07 Nov 2011 07:55:57 -0500
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: zach@sensinode.com
X-Trac-Project: core
Date: Mon, 07 Nov 2011 12:55:57 -0000
X-URL: http://tools.ietf.org/core/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/176#comment:2
Message-ID: <072.1208e00a2d7abbc687cfad840d59199c@trac.tools.ietf.org>
References: <057.1e9c9b555be0e4f1e7b8069f00a990a7@trac.tools.ietf.org>
X-Trac-Ticket-ID: 176
In-Reply-To: <057.1e9c9b555be0e4f1e7b8069f00a990a7@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false
Cc: core@ietf.org
Subject: Re: [core] #176: Uri-Path and Uri-Query
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, 07 Nov 2011 12:56:04 -0000

#176: Uri-Path and Uri-Query


Comment (by zach@…):

 It was pointed out by Carsten on the list, that this approach of moving a
 non-segmented Uri-Path or -Query option breaks when used with UTF-8 for
 representing the URI over the air, and thus simplifying end-points by
 working with purely normalized URIs.

 Therefore, this ticket should now concentrate on fixing the maximum 15
 option limitation in CoAP. Some initial approaches are defined in draft-
 bormann-coap-misc-09.

-- 
----------------------------------+---------------------
 Reporter:  zach@…                |       Owner:  zach@…
     Type:  protocol enhancement  |      Status:  new
 Priority:  minor                 |   Milestone:
Component:  coap                  |     Version:
 Severity:  -                     |  Resolution:
 Keywords:                        |
----------------------------------+---------------------

Ticket URL: 
core 


From salvatore.loreto@ericsson.com  Mon Nov  7 06:49:02 2011
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 EF08B21F8B38 for ; Mon,  7 Nov 2011 06:49:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.396
X-Spam-Level: 
X-Spam-Status: No, score=-106.396 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, 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 1S5xlOcTLafh for ; Mon,  7 Nov 2011 06:49:02 -0800 (PST)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 3554F21F8B16 for ; Mon,  7 Nov 2011 06:49:02 -0800 (PST)
X-AuditID: c1b4fb3d-b7c26ae0000035b9-05-4eb7efdda3cd
Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 1D.72.13753.DDFE7BE4; Mon,  7 Nov 2011 15:49:01 +0100 (CET)
Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.137.0; Mon, 7 Nov 2011 15:49:01 +0100
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id DA027230F; Mon,  7 Nov 2011 16:49:00 +0200 (EET)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 9384E51AA0; Mon,  7 Nov 2011 16:49:00 +0200 (EET)
Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id E42D251365; Mon,  7 Nov 2011 16:48:59 +0200 (EET)
Message-ID: <4EB7EFDB.5070505@ericsson.com>
Date: Mon, 7 Nov 2011 15:48:59 +0100
From: Salvatore Loreto 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Zhen Cao 
References: <4EB670B4.8070006@ericsson.com> 
In-Reply-To: 
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: AAAAAA==
Cc: "draft-cao-core-pd@tools.ietf.org" , "core@ietf.org" 
Subject: Re: [core] about draft-cao-core-pd
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, 07 Nov 2011 14:49:03 -0000

On 11/7/11 2:07 AM, Zhen Cao wrote:
> Hi Salvatore,
>
> Thanks for your comments.  See inline.
>
> On Sun, Nov 6, 2011 at 7:34 PM, Salvatore Loreto
>   wrote:
>> Hi there,
>>
>> how a CoAP client dynamically discovers a proxy to access the HTTP server is
>> an interesting question
>>
>> the mechanism you proposed in the draft is to use a multicast GET request to
>> /.well-known-core
>> with a 'rt' parameter with the value "core-pd" is interesting
>>
>> about this proposal it is not clear to me why you mandate that the address
>> of the proxy is carried
>> within the Content payload;
>> why is it not enough for the sensor reading the source address of the
>> answer?
> We thought carrying the address in the payload could be used for
> delegated case. But this should be discussed further.
>
>>
>> thinking more about the issue,
>> I am wondering if instead of sending a multicast GET request to
>> /.well-known/core
>> not would be more convenient and straightforward sending directly a
>> multicast HTTP GET request
>> and doing so discover intrinsically the IP address of the proxy?
> Are you saying that the sensor use HTTP GET ? But I think the
> assumption is that the sensor is only CoAP capable, not HTTP capable.
no I am saying that a sensor can issue a multicast CoAP GET with an HTTP URI
>
> For HTTP, I do not know if it has well known address that can be used
> for discovery.
the idea I had in mind was that the CoAP/HTTP proxy would be able to listen
to this multicast CoAP GET request and translate it directly in the HTTP 
world
and then translate back the HTTP response it gets, in a CoAP response,
to the CoAP sensor

/Sal

From salvatore.loreto@ericsson.com  Mon Nov  7 06:53:04 2011
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 A347E21F8B62 for ; Mon,  7 Nov 2011 06:53:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.416
X-Spam-Level: 
X-Spam-Status: No, score=-106.416 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, 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 xNEa0xsbvPDi for ; Mon,  7 Nov 2011 06:53:00 -0800 (PST)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 616F121F8B61 for ; Mon,  7 Nov 2011 06:53:00 -0800 (PST)
X-AuditID: c1b4fb39-b7b3eae00000252a-d6-4eb7f0cb189e
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 69.73.09514.BC0F7BE4; Mon,  7 Nov 2011 15:52:59 +0100 (CET)
Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Mon, 7 Nov 2011 15:52:59 +0100
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id 0F9C4230D; Mon,  7 Nov 2011 16:52:59 +0200 (EET)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id CA16A51AA0; Mon,  7 Nov 2011 16:52:58 +0200 (EET)
Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 45BF551365; Mon,  7 Nov 2011 16:52:58 +0200 (EET)
Message-ID: <4EB7F0C9.6010509@ericsson.com>
Date: Mon, 7 Nov 2011 15:52:57 +0100
From: Salvatore Loreto 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Likepeng 
References: <4EB58338.3080609@ericsson.com> <34966E97BE8AD64EAE9D3D6E4DEE36F2D08EF8@szxeml525-mbs.china.huawei.com> <4EB66AC7.1090700@ericsson.com> <34966E97BE8AD64EAE9D3D6E4DEE36F2D0CB9E@szxeml525-mbs.china.huawei.com>
In-Reply-To: <34966E97BE8AD64EAE9D3D6E4DEE36F2D0CB9E@szxeml525-mbs.china.huawei.com>
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: AAAAAA==
Cc: "core@ietf.org" 
Subject: Re: [core] draft coap-size
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, 07 Nov 2011 14:53:04 -0000

On 11/7/11 11:02 AM, Likepeng wrote:
> Hi Salvatore,
>
>> so you mean that a GET request including an empty Size option (or a
>> Size=0) will always include some payload
>> (i.e. the first block of the resource representation) or what...
> If the GET request only includes Block option, server will return the indicated Block.
>
> If the GET request includes Block option and an empty Size option (or Size=0), the
> server will return the Size of the whole resource and the requested Block. Usually the
> Size option will be sent in the first block request.

is it still a possibility to send a GET request including only an empty
Size option?
and if it is so, what would be the right behavior for this possibility


Salvatore

--
Salvatore Loreto
www.sloreto.com



>
> So, in this way, the added Size option will not affact the normal block behavior.
>
> If this sounds reasonable, I will revise the draft to make it clear.
>
>> I am OK with whatever you decide, but that should be clear in the text
>> and consistent in all the spec.
> Sure.
>
> Thanks,
> Kind Regards
> Kepeng
>


From likepeng@huawei.com  Mon Nov  7 07:30:01 2011
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 0D82E21F8B32 for ; Mon,  7 Nov 2011 07:30:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.384
X-Spam-Level: 
X-Spam-Status: No, score=-4.384 tagged_above=-999 required=5 tests=[AWL=0.615,  BAYES_00=-2.599, J_BACKHAIR_43=1, J_CHICKENPOX_43=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 tK-4cW8SGX0D for ; Mon,  7 Nov 2011 07:30:00 -0800 (PST)
Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 66A8A21F8B30 for ; Mon,  7 Nov 2011 07:30:00 -0800 (PST)
Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUA00JSRR1WHC@szxga05-in.huawei.com> for core@ietf.org; Mon, 07 Nov 2011 23:29:57 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUA00EFTR1WO2@szxga05-in.huawei.com> for core@ietf.org; Mon, 07 Nov 2011 23:29:56 +0800 (CST)
Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AEU68981; Mon, 07 Nov 2011 23:29:56 +0800
Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 07 Nov 2011 23:29:53 +0800
Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.177]) by szxeml406-hub.china.huawei.com ([10.82.67.93]) with mapi id 14.01.0270.001; Mon, 07 Nov 2011 23:29:48 +0800
Date: Mon, 07 Nov 2011 15:29:47 +0000
From: Likepeng 
In-reply-to: <4EB7F0C9.6010509@ericsson.com>
X-Originating-IP: [172.24.2.40]
To: Salvatore Loreto 
Message-id: <34966E97BE8AD64EAE9D3D6E4DEE36F2D0DCA9@szxeml525-mbs.china.huawei.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-language: zh-CN
Content-transfer-encoding: 7BIT
Accept-Language: zh-CN, en-US
Thread-topic: [core] draft coap-size
Thread-index: AQHMm+qB3mvH55N6pUWVHEWVt7gb15WesXUXgAB5jICAAgPPV///zR6AgACIOS4=
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References: <4EB58338.3080609@ericsson.com> <34966E97BE8AD64EAE9D3D6E4DEE36F2D08EF8@szxeml525-mbs.china.huawei.com> <4EB66AC7.1090700@ericsson.com> <34966E97BE8AD64EAE9D3D6E4DEE36F2D0CB9E@szxeml525-mbs.china.huawei.com> <4EB7F0C9.6010509@ericsson.com>
Cc: "core@ietf.org" 
Subject: Re: [core] draft coap-size
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, 07 Nov 2011 15:30:01 -0000

Hi,

> is it still a possibility to send a GET request including only an empty Size option?  and if it is so, what would be the right behavior for this possibility.

Yes, if the GET request includes only an empty Size option without Block option, the server returns the size of the resource representation with the resource payload. 

If the resource size is bigger than one PDU, the response will contain the size of the resource and the first Block data.

So the GET processing is the same as the previous Block behavior.

To make a summary:
1. GET with Size option, without Block option:
a) Size=0, only returns size info, no payload;
b) Size is empty, returns size info, if sizePDU, returns first Block;
c) Size has a value other than 0, this case is not specified in the draft. In the mailing list, there was a propoal to use this to indicate the maximum accepted size (or something similar).

2. GET with Size option, with Block option:
a) Size=0, only returns size info, no payload; this case is not specified in the draft, because I hope to add only the minimized functionality to the Block draft.
b) Size is empty, returns size info, if sizePDU, returns first Block;
c) Size has a value other than 0,  this case is not specified in the draft.

3. GET without Size option:
a) If size>PDU, Size option SHOULD be included in the response.
b) If size
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 AC9E411E8097; Mon,  7 Nov 2011 11:28:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.586
X-Spam-Level: 
X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013,  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 vcCWu5q+Qrsz; Mon,  7 Nov 2011 11:28:00 -0800 (PST)
Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by ietfa.amsl.com (Postfix) with ESMTP id 2ADB511E808E; Mon,  7 Nov 2011 11:28:00 -0800 (PST)
Received: from SAM.InterDigital.com ([10.30.2.12]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 7 Nov 2011 14:27:59 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 7 Nov 2011 14:27:58 -0500
Message-ID: 
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-topic: [core] IETF82 CoRE agenda
Thread-index: AcyaQYr37hhcXtH2S0u1FMO4zN9KOADQanBQ
References: <97F83FD9-93AC-4E44-9EFA-73D0C154EF82@tzi.org> 
From: "Rahman, Akbar" 
To: "Carsten Bormann" 
X-OriginalArrivalTime: 07 Nov 2011 19:27:59.0394 (UTC) FILETIME=[5BD62820:01CC9D83]
Cc: core WG 
Subject: Re: [core] IETF82 CoRE agenda
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 07 Nov 2011 19:28:00 -0000

Hi Carsten,


Do you plan to have an update of the agenda soon?


Akbar

-----Original Message-----
From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of =
Carsten Bormann
Sent: Thursday, November 03, 2011 11:59 AM
To: core WG
Subject: Re: [core] IETF82 CoRE agenda

On Nov 1, 2011, at 23:48, Carsten Bormann wrote:

> 	http://www.ietf.org/proceedings/82/agenda/core.txt
>=20
> I plan to have a v2 agenda out 24 h from now.

Updated with the info I received so far.

If your draft is listed, but there are no objectives and/or no presenter =
listed, please get that info to me now, because for v3 I'll have to =
clean up some drafts from the Friday to make that meeting a bit more =
realistic schedulewise.

Gr=FC=DFe, Carsten

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

From salvatore.loreto@ericsson.com  Tue Nov  8 02:36:24 2011
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 94F0921F84BC for ; Tue,  8 Nov 2011 02:36:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.633
X-Spam-Level: 
X-Spam-Status: No, score=-105.633 tagged_above=-999 required=5 tests=[AWL=-0.634, BAYES_00=-2.599, J_BACKHAIR_43=1, J_CHICKENPOX_43=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 YfqiHNGm7Tt4 for ; Tue,  8 Nov 2011 02:36:24 -0800 (PST)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id C78C621F84A1 for ; Tue,  8 Nov 2011 02:36:23 -0800 (PST)
X-AuditID: c1b4fb3d-b7c26ae0000035b9-ec-4eb906231350
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 47.CA.13753.32609BE4; Tue,  8 Nov 2011 11:36:19 +0100 (CET)
Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Tue, 8 Nov 2011 11:36:18 +0100
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id 16262230D; Tue,  8 Nov 2011 12:36:19 +0200 (EET)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id BBE60518C7; Tue,  8 Nov 2011 12:36:18 +0200 (EET)
Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 302D4503CF; Tue,  8 Nov 2011 12:36:18 +0200 (EET)
Message-ID: <4EB90621.10307@ericsson.com>
Date: Tue, 8 Nov 2011 11:36:17 +0100
From: Salvatore Loreto 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Likepeng 
References: <4EB58338.3080609@ericsson.com> <34966E97BE8AD64EAE9D3D6E4DEE36F2D08EF8@szxeml525-mbs.china.huawei.com> <4EB66AC7.1090700@ericsson.com> <34966E97BE8AD64EAE9D3D6E4DEE36F2D0CB9E@szxeml525-mbs.china.huawei.com> <4EB7F0C9.6010509@ericsson.com> <34966E97BE8AD64EAE9D3D6E4DEE36F2D0DCA9@szxeml525-mbs.china.huawei.com>
In-Reply-To: <34966E97BE8AD64EAE9D3D6E4DEE36F2D0DCA9@szxeml525-mbs.china.huawei.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: AAAAAA==
Cc: "core@ietf.org" 
Subject: Re: [core] draft coap-size
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, 08 Nov 2011 10:36:24 -0000

On 11/7/11 4:29 PM, Likepeng wrote:
> Hi,
>
>> is it still a possibility to send a GET request including only an empty Size option?  and if it is so, what would be the right behavior for this possibility.
> Yes, if the GET request includes only an empty Size option without Block option, the server returns the size of the resource representation with the resource payload.
>
> If the resource size is bigger than one PDU, the response will contain the size of the resource and the first Block data.
>
> So the GET processing is the same as the previous Block behavior.
>
> To make a summary:
> 1. GET with Size option, without Block option:
> a) Size=0, only returns size info, no payload;
> b) Size is empty, returns size info, if sizePDU, returns first Block;
> c) Size has a value other than 0, this case is not specified in the draft. In the mailing list, there was a propoal to use this to indicate the maximum accepted size (or something similar).
>
> 2. GET with Size option, with Block option:
> a) Size=0, only returns size info, no payload; this case is not specified in the draft, because I hope to add only the minimized functionality to the Block draft.
> b) Size is empty, returns size info, if sizePDU, returns first Block;
> c) Size has a value other than 0,  this case is not specified in the draft.
>
> 3. GET without Size option:
> a) If size>PDU, Size option SHOULD be included in the response.
> b) If size
> Hope it clarifies.
>
> Thanks,
> Kind Regards
> Kepeng
>
>
>



From jari.arkko@piuha.net  Tue Nov  8 04:10:13 2011
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 01E8221F8C6E; Tue,  8 Nov 2011 04:10:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.524
X-Spam-Level: 
X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 S5nukf8c7ULc; Tue,  8 Nov 2011 04:10:12 -0800 (PST)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id D2D7821F8B66; Tue,  8 Nov 2011 04:10:06 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 2F7E52CCE0; Tue,  8 Nov 2011 14:10:06 +0200 (EET)
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 MBBDjaYvJSEC; Tue,  8 Nov 2011 14:10:05 +0200 (EET)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 9AB792CC61; Tue,  8 Nov 2011 14:10:05 +0200 (EET)
Message-ID: <4EB91C1D.5000606@piuha.net>
Date: Tue, 08 Nov 2011 14:10:05 +0200
From: Jari Arkko 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: core , 6lowpan@ietf.org, roll@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [core] informal hacking & interop session on Sunday
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, 08 Nov 2011 12:10:13 -0000

In the last IETF we organized an informal session to demonstrate & test various smart object related implementations. We are now doing this again for the Taipei IETF. We will meet at 19:00-22:00 on Sunday, November 13th, (room TBD). If you are attending the IETF and have your Internet of Things toys with you (be it 6lowpan, coap, rpl, or anything else) feel free to join. Maybe you'll find someone to test with, or at least get to see other people with interesting implementations.

Jari


From sye.loong.keoh@philips.com  Tue Nov  8 05:51:52 2011
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 D741921F891D for ; Tue,  8 Nov 2011 05:51:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aA5r6Iredlf3 for ; Tue,  8 Nov 2011 05:51:52 -0800 (PST)
Received: from DB3EHSOBE001.bigfish.com (db3ehsobe001.messaging.microsoft.com [213.199.154.139]) by ietfa.amsl.com (Postfix) with ESMTP id AAD5621F87C2 for ; Tue,  8 Nov 2011 05:51:51 -0800 (PST)
Received: from mail25-db3-R.bigfish.com (10.3.81.243) by DB3EHSOBE001.bigfish.com (10.3.84.21) with Microsoft SMTP Server id 14.1.225.22; Tue, 8 Nov 2011 13:51:28 +0000
Received: from mail25-db3 (localhost.localdomain [127.0.0.1])	by mail25-db3-R.bigfish.com (Postfix) with ESMTP id 82FF51903E5; Tue,  8 Nov 2011 13:51:41 +0000 (UTC)
X-SpamScore: -38
X-BigFish: VPS-38(zz217bL15d6O9251J542Mzz1202hzz1033IL8275dhz2dh2a8h668h839h944h)
X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPVD:NLI; H:mail.philips.com; RD:none; EFVD:NLI
X-FB-SS: 0,13,
Received: from mail25-db3 (localhost.localdomain [127.0.0.1]) by mail25-db3 (MessageSwitch) id 1320760259930483_18471; Tue,  8 Nov 2011 13:50:59 +0000 (UTC)
Received: from DB3EHSMHS016.bigfish.com (unknown [10.3.81.249])	by mail25-db3.bigfish.com (Postfix) with ESMTP id DD664748050; Tue,  8 Nov 2011 13:50:59 +0000 (UTC)
Received: from mail.philips.com (157.55.7.222) by DB3EHSMHS016.bigfish.com (10.3.87.116) with Microsoft SMTP Server (TLS) id 14.1.225.22; Tue, 8 Nov 2011 13:50:42 +0000
Received: from 011-DB3MPN1-031.MGDPHG.emi.philips.com ([169.254.1.103]) by 011-DB3MMR1-001.MGDPHG.emi.philips.com ([10.128.28.51]) with mapi id 14.01.0339.002; Tue, 8 Nov 2011 13:51:03 +0000
From: "Keoh, Sye Loong" 
To: Alper Yegin , core WG 
Thread-Topic: [core] draft-yegin-coap-security
Thread-Index: AQHMmi9w6IvvpBWZrUWmFrOT5cMxcpWjAPkw
Date: Tue, 8 Nov 2011 13:51:02 +0000
Message-ID: 
References: <97F83FD9-93AC-4E44-9EFA-73D0C154EF82@tzi.org> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [194.171.252.100]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: philips.com
Subject: Re: [core] draft-yegin-coap-security
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, 08 Nov 2011 13:51:53 -0000

Dear Alper,

While reading your draft, I have the following questions:

1. Since CryptoInitiate Option is sent in clear while negotiating the secur=
ity context, can the attacker exploit such a message to launch DoS attack? =
I do understand that even in DTLS, the handshake is performed in clear. Do =
you think we should consider mitigation strategy used in DTLS to include co=
okies to detect potential DoS attack?

2. Is my understanding correct that the secret-key used to encrypt the CoAP=
 messages is the PSK itself? Is there any reason for not deriving a session=
 key from the PSK? I am just thinking if the PSK is compromised, this means=
 that all previous communication messages are compromised too.

3. I suggest that the CryptoTerminate Option is protected/MACed in order to=
 ensure that it is originated from the client. Otherwise, any device in the=
 network can spoof this message in order to delete the security context.

Cheers
Sye-Loong

-----Original Message-----
From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Alp=
er Yegin
Sent: Thursday 3 November 2011 14:50
To: core WG
Subject: [core] draft-yegin-coap-security

Folks,

Please note the draft Zach and I produced for securing CoAP.

http://tools.ietf.org/html/draft-yegin-coap-security-options-00

Comments are very welcome.

Alper


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

________________________________
The information contained in this message may be confidential and legally p=
rotected under applicable law. The message is intended solely for the addre=
ssee(s). If you are not the intended recipient, you are hereby notified tha=
t any use, forwarding, dissemination, or reproduction of this message is st=
rictly prohibited and may be unlawful. If you are not the intended recipien=
t, please contact the sender by return e-mail and destroy all copies of the=
 original message.


From tianlinyi@huawei.com  Tue Nov  8 14:26:15 2011
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 271AD1F0C70; Tue,  8 Nov 2011 14:26:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.708
X-Spam-Level: ***
X-Spam-Status: No, score=3.708 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553,  MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.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 juWL8qp6w0oK; Tue,  8 Nov 2011 14:26:14 -0800 (PST)
Received: from szxga03-in.huawei.com (unknown [58.251.152.66]) by ietfa.amsl.com (Postfix) with ESMTP id 8D2CF11E80AD; Tue,  8 Nov 2011 14:25:47 -0800 (PST)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUD002SO4YWMZ@szxga03-in.huawei.com>; Wed, 09 Nov 2011 06:25:44 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUD000QF4YWA8@szxga03-in.huawei.com>; Wed, 09 Nov 2011 06:25:44 +0800 (CST)
Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AEV44266; Wed, 09 Nov 2011 06:25:25 +0800
Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 09 Nov 2011 06:25:21 +0800
Received: from SZXEML513-MBX.china.huawei.com ([169.254.8.59]) by szxeml409-hub.china.huawei.com ([10.82.67.136]) with mapi id 14.01.0270.001; Wed, 09 Nov 2011 06:25:19 +0800
Date: Tue, 08 Nov 2011 22:25:18 +0000
From: TianLinyi 
In-reply-to: <4EB91C1D.5000606@piuha.net>
X-Originating-IP: [172.24.2.40]
To: Jari Arkko , core , "6lowpan@ietf.org" <6lowpan@ietf.org>, "roll@ietf.org" 
Message-id: <3615F3CCD55F054395A882F51C6E5FDA181FD1FC@szxeml513-mbx.china.huawei.com>
MIME-version: 1.0
Content-type: text/plain; charset=gb2312
Content-language: zh-CN
Content-transfer-encoding: base64
Accept-Language: zh-CN, en-US
Thread-topic: [core] informal hacking & interop session on Sunday
Thread-index: AQHMng94QsTxRr2OuECfrzamTLX3rJWjjgFO
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References: <4EB91C1D.5000606@piuha.net>
Subject: Re: [core] informal hacking & interop session on Sunday
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, 08 Nov 2011 22:26:15 -0000

SGksIEphcmkNCg0KR29vZCB0byBrbm93IHRoaXMgZXZlbnQuIE15IHRlYW0gaGFzIGltcGxlbWVu
dGVkIHRoZSBsYXRlc3QgZHJhZnQgb2YgY29yZSwgbGluayBmb3JtYXQsIGJsb2NrIGFuZCBvYnNl
cnZlLiBTaW5jZSB3ZSBoYXZlIGEgY29tcGFueSBtZWV0aW5nIGF0IDE5OjAwIHdlIG1heSBjb21l
IGEgbGl0dGxlIGJpdCBsYXRlLg0KDQpDaGVlcnMsDQpMaW55aQ0KDQpfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IGNvcmUtYm91bmNlc0BpZXRmLm9yZyBb
Y29yZS1ib3VuY2VzQGlldGYub3JnXSC0+rHtIEphcmkgQXJra28gW2phcmkuYXJra29AcGl1aGEu
bmV0XQ0Kt6LLzcqxvOQ6IDIwMTHE6jEx1MI4yNUgMjA6MTANCrW9OiBjb3JlOyA2bG93cGFuQGll
dGYub3JnOyByb2xsQGlldGYub3JnDQrW98ziOiBbY29yZV0gaW5mb3JtYWwgaGFja2luZyAmIGlu
dGVyb3Agc2Vzc2lvbiBvbiBTdW5kYXkNCg0KSW4gdGhlIGxhc3QgSUVURiB3ZSBvcmdhbml6ZWQg
YW4gaW5mb3JtYWwgc2Vzc2lvbiB0byBkZW1vbnN0cmF0ZSAmIHRlc3QgdmFyaW91cyBzbWFydCBv
YmplY3QgcmVsYXRlZCBpbXBsZW1lbnRhdGlvbnMuIFdlIGFyZSBub3cgZG9pbmcgdGhpcyBhZ2Fp
biBmb3IgdGhlIFRhaXBlaSBJRVRGLiBXZSB3aWxsIG1lZXQgYXQgMTk6MDAtMjI6MDAgb24gU3Vu
ZGF5LCBOb3ZlbWJlciAxM3RoLCAocm9vbSBUQkQpLiBJZiB5b3UgYXJlIGF0dGVuZGluZyB0aGUg
SUVURiBhbmQgaGF2ZSB5b3VyIEludGVybmV0IG9mIFRoaW5ncyB0b3lzIHdpdGggeW91IChiZSBp
dCA2bG93cGFuLCBjb2FwLCBycGwsIG9yIGFueXRoaW5nIGVsc2UpIGZlZWwgZnJlZSB0byBqb2lu
LiBNYXliZSB5b3UnbGwgZmluZCBzb21lb25lIHRvIHRlc3Qgd2l0aCwgb3IgYXQgbGVhc3QgZ2V0
IHRvIHNlZSBvdGhlciBwZW9wbGUgd2l0aCBpbnRlcmVzdGluZyBpbXBsZW1lbnRhdGlvbnMuDQoN
CkphcmkNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N
CmNvcmUgbWFpbGluZyBsaXN0DQpjb3JlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL2NvcmU=

From likepeng@huawei.com  Tue Nov  8 21:00:32 2011
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 A42E211E8096 for ; Tue,  8 Nov 2011 21:00:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.607
X-Spam-Level: *
X-Spam-Status: No, score=1.607 tagged_above=-999 required=5 tests=[AWL=2.102,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553,  RDNS_NONE=0.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 HDfo2xQF55Ja for ; Tue,  8 Nov 2011 21:00:32 -0800 (PST)
Received: from szxga03-in.huawei.com (unknown [58.251.152.66]) by ietfa.amsl.com (Postfix) with ESMTP id 25E6C1F0C65 for ; Tue,  8 Nov 2011 21:00:19 -0800 (PST)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUD00JHCN85HM@szxga03-in.huawei.com> for core@ietf.org; Wed, 09 Nov 2011 13:00:05 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUD008V3N85NY@szxga03-in.huawei.com> for core@ietf.org; Wed, 09 Nov 2011 13:00:05 +0800 (CST)
Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AEV67046; Wed, 09 Nov 2011 13:00:04 +0800
Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 09 Nov 2011 13:00:00 +0800
Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.177]) by szxeml401-hub.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0270.001; Wed, 09 Nov 2011 12:59:51 +0800
Date: Wed, 09 Nov 2011 04:59:51 +0000
From: Likepeng 
In-reply-to: <4EB90621.10307@ericsson.com>
X-Originating-IP: [172.24.2.41]
To: Salvatore Loreto 
Message-id: <34966E97BE8AD64EAE9D3D6E4DEE36F2D0EE43@szxeml525-mbs.china.huawei.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-language: zh-CN
Content-transfer-encoding: 7BIT
Accept-Language: zh-CN, en-US
Thread-topic: [core] draft coap-size
Thread-index: AQHMm+qB3mvH55N6pUWVHEWVt7gb15WesXUXgAB5jICAAgPPV///zR6AgACIOS6AAMJlgIABtjK/
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References: <4EB58338.3080609@ericsson.com> <34966E97BE8AD64EAE9D3D6E4DEE36F2D08EF8@szxeml525-mbs.china.huawei.com> <4EB66AC7.1090700@ericsson.com> <34966E97BE8AD64EAE9D3D6E4DEE36F2D0CB9E@szxeml525-mbs.china.huawei.com> <4EB7F0C9.6010509@ericsson.com> <34966E97BE8AD64EAE9D3D6E4DEE36F2D0DCA9@szxeml525-mbs.china.huawei.com> <4EB90621.10307@ericsson.com>
Cc: "core@ietf.org" 
Subject: Re: [core] draft coap-size
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, 09 Nov 2011 05:00:32 -0000

Hi Salvatore,

> IMO GET without Size option must follow what specified in the draft-ietf-core-coap-08.

Yes, that is why we design this option as Elective option.

> a sensor can not discriminate if the GET is arriving from a client that understand the Size option, but didn't include it vs a GET that is arriving from a "legacy" CoAP sensor.

This is a good consideration. I think the server does not need to distinguish the two situations. The behavior for the server will be the same.

1. A GET is from a client does not understand the Size option, if the server sends the Size information acording to the principle as indicated in the draft, the client will just ignore it after receiving it. Because Size option is defined as Elective option.

2. A GET is from a client understands the Size option, if the server sends the Size information according to the principle as indicated in the draft, the client can understand the Size option correctly.

Thanks,
Kind Regards
Kepeng

  

From ycma610103@gmail.com  Wed Nov  9 03:12:45 2011
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 0C0E721F8C09 for ; Wed,  9 Nov 2011 03:12:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lXO5R91oYNrs for ; Wed,  9 Nov 2011 03:12:44 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id B85C021F8C08 for ; Wed,  9 Nov 2011 03:12:42 -0800 (PST)
Received: by ggnr4 with SMTP id r4so2267ggn.31 for ; Wed, 09 Nov 2011 03:12:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=xI0k8qSN/JT89nLKR8ftedHUz2phVT9wf/XK0faq82E=; b=QbPm54hez5PK23/FkUpuIFTBbxbZ/a7/wD4to8n03pgzbHyWdraY409eCPPMsXxJKj OuMv2RdYOVE2J1EmF5gOoBNGTbf9zxqA1sU70mRPaBBZhNfwzFTEz6ZCBBmUhRFHAsDB sghv2W95ot4yx21r3a26ZXa6gQwsdP0VyC+rA=
MIME-Version: 1.0
Received: by 10.146.186.3 with SMTP id j3mr174598yaf.2.1320837161331; Wed, 09 Nov 2011 03:12:41 -0800 (PST)
Received: by 10.236.208.6 with HTTP; Wed, 9 Nov 2011 03:12:41 -0800 (PST)
In-Reply-To: <4EB7EFDB.5070505@ericsson.com>
References: <4EB670B4.8070006@ericsson.com>  <4EB7EFDB.5070505@ericsson.com>
Date: Wed, 9 Nov 2011 19:12:41 +0800
Message-ID: 
From: ma yc 
To: Salvatore Loreto 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "core@ietf.org" , "draft-cao-core-pd@tools.ietf.org" 
Subject: Re: [core] about draft-cao-core-pd
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, 09 Nov 2011 11:12:45 -0000

Hi Salvatore

Thank you for your comments. Please see inline.

2011/11/7 Salvatore Loreto :
> On 11/7/11 2:07 AM, Zhen Cao wrote:
>>
>> Hi Salvatore,
>>
>> Thanks for your comments. =A0See inline.
>>
>> On Sun, Nov 6, 2011 at 7:34 PM, Salvatore Loreto
>>  =A0wrote:
>>>
>>> Hi there,
>>>
>>> how a CoAP client dynamically discovers a proxy to access the HTTP serv=
er
>>> is
>>> an interesting question
>>>
>>> the mechanism you proposed in the draft is to use a multicast GET reque=
st
>>> to
>>> /.well-known-core
>>> with a 'rt' parameter with the value "core-pd" is interesting
>>>
>>> about this proposal it is not clear to me why you mandate that the
>>> address
>>> of the proxy is carried
>>> within the Content payload;
>>> why is it not enough for the sensor reading the source address of the
>>> answer?
>>
>> We thought carrying the address in the payload could be used for
>> delegated case. But this should be discussed further.
>>
>>>
>>> thinking more about the issue,
>>> I am wondering if instead of sending a multicast GET request to
>>> /.well-known/core
>>> not would be more convenient and straightforward sending directly a
>>> multicast HTTP GET request
>>> and doing so discover intrinsically the IP address of the proxy?
>>
>> Are you saying that the sensor use HTTP GET ? But I think the
>> assumption is that the sensor is only CoAP capable, not HTTP capable.
>
> no I am saying that a sensor can issue a multicast CoAP GET with an HTTP =
URI
It seems a little bit weird to carry http uri in CoAP GET.
Since the uri mapping has been discussed in draft-castellani-core-http-mapp=
ing,
how about just use CoAP uri and specify that homogeneous mapping is used
for such kind of GET.

>>
>> For HTTP, I do not know if it has well known address that can be used
>> for discovery.
>
> the idea I had in mind was that the CoAP/HTTP proxy would be able to list=
en
> to this multicast CoAP GET request and translate it directly in the HTTP
> world
> and then translate back the HTTP response it gets, in a CoAP response,
> to the CoAP sensor
>
> /Sal
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>

From ycma610103@gmail.com  Wed Nov  9 19:46:01 2011
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 321BB1F0C34 for ; Wed,  9 Nov 2011 19:46:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.048
X-Spam-Level: 
X-Spam-Status: No, score=0.048 tagged_above=-999 required=5 tests=[AWL=-3.647,  BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3,  MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_GB2312=1.345]
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 VzHLmfUizhGu for ; Wed,  9 Nov 2011 19:46:00 -0800 (PST)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0B4851F0C38 for ; Wed,  9 Nov 2011 19:45:59 -0800 (PST)
Received: by ywt34 with SMTP id 34so229710ywt.31 for ; Wed, 09 Nov 2011 19:45:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=lNnsoPsoFEdveB/z9tnSKkNNdx1dH9F0PQaBe6BZDF8=; b=WABSxNMWGRK1BWxMWVUTlEkvt5IZnqt715A5h1MxrGir/9lhVqIBc1rg+7d3V2PZhu Ow+hbaVw/N0hKt07KuQ42pvEIuKAmZw3XLtRbobNs3GL1nGg7nVzZnvbwDINjMbyJdRI oG6XZZuAzynh3D+hqe85yS62Gkq+0pZan+5mY=
MIME-Version: 1.0
Received: by 10.101.137.38 with SMTP id p38mr2541602ann.33.1320896759503; Wed, 09 Nov 2011 19:45:59 -0800 (PST)
Received: by 10.236.208.6 with HTTP; Wed, 9 Nov 2011 19:45:59 -0800 (PST)
In-Reply-To: <3615F3CCD55F054395A882F51C6E5FDA181FB2AB@szxeml513-mbx.china.huawei.com>
References: <4EB58338.3080609@ericsson.com> <34966E97BE8AD64EAE9D3D6E4DEE36F2D08EF8@szxeml525-mbs.china.huawei.com> <4EB66AC7.1090700@ericsson.com> <3615F3CCD55F054395A882F51C6E5FDA181FB2AB@szxeml513-mbx.china.huawei.com>
Date: Thu, 10 Nov 2011 11:45:59 +0800
Message-ID: 
From: ma yc 
To: TianLinyi 
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: quoted-printable
Cc: "core@ietf.org" 
Subject: Re: [core] =?gb2312?b?tPC4tDogZHJhZnQgY29hcC1zaXpl?=
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, 10 Nov 2011 03:46:01 -0000

Hi, Linyi

please see in line.

Thank you.
Regards
Yuanchen


=D4=DA 2011=C4=EA11=D4=C26=C8=D5 =CF=C2=CE=E79:31=A3=ACTianLinyi  =D0=B4=B5=C0=A3=BA
> Hi, all
>
> I believe the size option should be used in case the data is not changing=
 during the whole transaction. If it changes, the previously transferred bl=
ock may be useless. This happens regardingless whether the size option is a=
ccurate or not.
>
> For example, if the coap server is capturing a video when you initial the=
 block tranfer at 18:00 GMT you get a video until that time. Even though th=
e video is growing you will only get that snapshot. When you initial a new =
block transfer you will get a new one.

I am not sure about this scenario.

You plan to use CoAP to carry video as payload?
In current CoAP spec the media type does not
include the media stream. Do you intend to
add new media type or i miss something?

>
> We may need a new mechanism to indicate the current transferred block is =
no longer valid a new transaction is needed.
>
> Cheers,
> Linyi
>
> ________________________________________
> =B7=A2=BC=FE=C8=CB: core-bounces@ietf.org [core-bounces@ietf.org] =B4=FA=
=B1=ED Salvatore Loreto [salvatore.loreto@ericsson.com]
> =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA11=D4=C26=C8=D5 19:08
> =B5=BD: Likepeng
> Cc: core@ietf.org
> =D6=F7=CC=E2: Re: [core] draft coap-size
>
> Hi,
>
> thanks for answering my questions, see more in line below
>
> cheers
>
> --
> Salvatore Loreto
> www.sloreto.com
>
>
>
> On 11/5/11 9:28 PM, Likepeng wrote:
>> Hello Salvatore,
>>
>>> I support the definition of the Size option as I think it is a useful o=
ption to be used in conjunction with Block.
>>> About the inclusion/merge of it in Block draft I don't care.
>> Thanks for the review and the support.
>> I would prefer to be merged with Block draft, but if the WG decides to b=
e separate, that is also fine to me.
>>
>>> 1) In section 2.2
>>>   The GET request including Size=3D0 is treated as a request to get the
>>>   size of the resource representation (but not the resource payload).
>>> this is a duplication as you can already obtain the size of the resourc=
e using the Link Forma "sz" attribute.
>> Yes, but the resource size got from "sz" attribute is not accurate.
>>
>>> more the above paragraph is not fully consistent with the sentence in S=
ection 4.2
>>>   For a GET request, if it includes an empty Size option, the Size
>>>   option MUST be included in the response.
>>> the above sentence does not specify if the response include the actual =
resource representation or not.
>> The response needs to include the actual resource representation for the=
 indicated block number.
>> I will fix the text.
>
> so you mean that a GET request including an empty Size option (or a
> Size=3D0) will always include some payload
> (i.e. the first block of the resource representation) or what...
>
> I am OK with whatever you decide, but that should be clear in the text
> and consistent in all the spec
>
>>
>>> 2) the following two paragraphs in Section 2.2 are not completely clear=
 at least to me:
>>>   If the Size option is specified it SHOULD be accurate at that time,
>>>   and SHOULD NOT be an estimate.
>>>   But due to the dynamic change of the resource data, the Size may not
>>>   be accurate.  If the value of Size option is not the same as the
>>>   actual transmitted data, the recipient MUST take the size of the
>>>   actual transmitted data as accurate, and ignore the Size option.  In
>>>   case that the recipient gets all the data but it is still smaller
>>>   than the announced Size, the recipient SHOULD stop the transmission.
>>>   If the recipient finds out the transmitted data reaches the Size
>>>   limit, and there's more data left, the recipient SHOULD continue to
>>>  transmit the remaining data.
>> I mean, for the dynamic data, during the transmission, the resource size=
 may be changed.
>>
>> I can revise the text to say:
>> If the Size option is specified, it MUST be accurate at that time.
>>
>> And remove the second paragraph, because it is more like the implementat=
ion recommendation or strategy.
>
> I don't think is an implementation recommendation,
> IMO it should completely clear what happens when the Size changes during
> a transfer (i.e. GET request)
> for example the server could include in one of the answer transferring
> one of the blocks the new Size...
> however it is not clear when the Size changes if the changes in the
> resource are only at the end of it...
> it can also happen that the changes have effected some of the blocks
> already transmitted
> so what would be the behavior in this case
>
>
> Cheers
> /Sal
>
>>
>> Kind Regards
>> Kepeng
>>
>> =B7=A2=BC=FE=C8=CB: core-bounces@ietf.org [core-bounces@ietf.org] =B4=FA=
=B1=ED Salvatore Loreto [salvatore.loreto@ericsson.com]
>> =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA11=D4=C26=C8=D5 2:40
>> =B5=BD: core@ietf.org; draft-li-core-coap-size-option@tools.ietf.org
>> =D6=F7=CC=E2: [core] draft coap-size
>>
>>
>> Hi there
>>
>> I have read the 02 version of the draft
>> and I support the definition of the Size option as I think it is a usefu=
l option to be used in conjunction with Block.
>> About the inclusion/merge of it in Block draft I don't care.
>>
>> some comments on the draft:
>>
>> 1) In section 2.2
>>
>>
>>    The GET request including Size=3D0 is treated as a request to get the
>>    size of the resource representation (but not the resource payload).
>>
>> this is a duplication as you can already obtain the size of the resource=
 using the Link Forma "sz" attribute.
>>
>> more the above paragraph is not fully consistent with the sentence in Se=
ction 4.2
>>
>>
>>    For a GET request, if it includes an empty Size option, the Size
>>    option MUST be included in the response.
>>
>> the above sentence does not specify if the response include the actual r=
esource representation or not.
>>
>>
>> 2) the following two paragraphs in Section 2.2 are not completely clear =
at least to me:
>>
>>
>>    If the Size option is specified it SHOULD be accurate at that time,
>>    and SHOULD NOT be an estimate.
>>
>>
>>    But due to the dynamic change of the resource data, the Size may not
>>    be accurate.  If the value of Size option is not the same as the
>>    actual transmitted data, the recipient MUST take the size of the
>>    actual transmitted data as accurate, and ignore the Size option.  In
>>    case that the recipient gets all the data but it is still smaller
>>    than the announced Size, the recipient SHOULD stop the transmission.
>>    If the recipient finds out the transmitted data reaches the Size
>>    limit, and there's more data left, the recipient SHOULD continue to
>>    transmit the remaining data.
>>
>> cheers
>> Salvatore
>>
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>

From zehn.cao@gmail.com  Wed Nov  9 23:42:50 2011
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 3727821F846D for ; Wed,  9 Nov 2011 23:42:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.91
X-Spam-Level: 
X-Spam-Status: No, score=-2.91 tagged_above=-999 required=5 tests=[AWL=0.689,  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 i-HG6AXVV-Bx for ; Wed,  9 Nov 2011 23:42:49 -0800 (PST)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 344431F0C41 for ; Wed,  9 Nov 2011 23:42:48 -0800 (PST)
Received: by iaeo4 with SMTP id o4so3381159iae.31 for ; Wed, 09 Nov 2011 23:42:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Os6PX1j2WB9ITVxln1WGWYBDtxG9cQu69j03mcryw/4=; b=U+43jxOc6b55eZX9xF7l0gokfVPaRwoJEorAFSrAqpMlTNtJs0CCI0a9UyMcYdjFM7 Q1RS5nmxDWCb7dCLGEoIaNRs6PSNYASAd+fvwaAcVm85w+Qtgx1CA/MuIE+nSe3nf95w k61qITnx8TAxv+WfBD+WhnQiRwKLR50l+YmZo=
MIME-Version: 1.0
Received: by 10.42.158.9 with SMTP id f9mr6378521icx.31.1320910967807; Wed, 09 Nov 2011 23:42:47 -0800 (PST)
Received: by 10.42.164.133 with HTTP; Wed, 9 Nov 2011 23:42:47 -0800 (PST)
In-Reply-To: <97F83FD9-93AC-4E44-9EFA-73D0C154EF82@tzi.org>
References: <97F83FD9-93AC-4E44-9EFA-73D0C154EF82@tzi.org>
Date: Thu, 10 Nov 2011 15:42:47 +0800
Message-ID: 
From: Zhen Cao 
To: Carsten Bormann 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: core WG 
Subject: Re: [core] IETF82 CoRE agenda
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Nov 2011 07:42:50 -0000

Hi Carsten,

The following drafts are related to the topic "mapping"; they are
about how to discover the HTTP-CoAP mapping function component.
	draft-cao-core-pd-00.txt
	draft-he-core-energy-aware-pd-00.txt
	draft-ma-core-dhcp-pd-00.txt

So could you move them to the mapping section? Thank you.

On Wed, Nov 2, 2011 at 6:48 AM, Carsten Bormann  wrote:
> I have uploaded a drafty agenda at:
>
> =A0 =A0 =A0 =A0http://www.ietf.org/proceedings/82/agenda/core.txt
>
> I mainly tried to cover the drafts we should be looking at -- did I miss =
any?
> The resulting shopping list is still short on objectives for most agenda =
items.
>
> Those who want to achieve progress on specific drafts -- please send me t=
he objectives for the slot I have put your draft under, and please tell me =
who will be presenting/leading the discussion.
>
> The agenda is way too full, and I probably even missed a lot of things we=
 also need to do, so we won't keep slots that don't have very specific, cre=
dible objectives for this meeting.
>
> I plan to have a v2 agenda out 24 h from now.
>
> Gr=FC=DFe, Carsten
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>



--=20
Best regards,
Zhen

From alper.yegin@yegin.org  Fri Nov 11 00:35:59 2011
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 E5E7221F848C for ; Fri, 11 Nov 2011 00:35:59 -0800 (PST)
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 A9dYPDmnqaET for ; Fri, 11 Nov 2011 00:35:59 -0800 (PST)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 4322321F848B for ; Fri, 11 Nov 2011 00:35:56 -0800 (PST)
Received: from [192.168.2.2] (dsl88-247-34762.ttnet.net.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0MIMh5-1RMIHZ2s19-003zkv; Fri, 11 Nov 2011 03:35:53 -0500
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: text/plain; charset=windows-1252
From: Alper Yegin 
In-Reply-To: 
Date: Fri, 11 Nov 2011 10:35:36 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <97F83FD9-93AC-4E44-9EFA-73D0C154EF82@tzi.org>  
To: "Keoh, Sye Loong" 
X-Mailer: Apple Mail (2.1244.3)
X-Provags-ID: V02:K0:JFlx/edzpA6RuQGgVm6YgLe43oUlQiKpSr51LRYNDwb ejoenGB9UdY/QrO7z8iLDlpdhauJVp+CBx1QC9pXNqdsP5vOaD SFMR21xYKJVs5TGSY7dFWvJEuexFYLLL1tbgoJtWDK07jyL/xo CfQ2IvZ61PhhFxejsrYti4F3bMvDFoaK0ebd9sv3ocbz5NPlSt w8VOD5hZAyUa6zEARRpJMbsyODB8wx1oUroR3bPacPC/E6ioXf HnO8ZN71JX0r4MK/jhAMMEzy3ns9TFo5CFLlipT+umwtyyo99k uEIw4ZlCBNOLTSRbjRsYdFS9B/zf4ceD5qYecgOaE5/CvA5s5x Qdv2AvBAvjhBh3V7uGACI007/sxVqr+ir80IC85+lv5/MdEN+M xjlcJ3yDd7c9g==
Cc: core WG 
Subject: Re: [core] draft-yegin-coap-security
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, 11 Nov 2011 08:36:00 -0000

Hello Sye-Loong,

On Nov 8, 2011, at 3:51 PM, Keoh, Sye Loong wrote:

> Dear Alper,
>=20
> While reading your draft, I have the following questions:
>=20

Thanks for the review and feedback.


> 1. Since CryptoInitiate Option is sent in clear while negotiating the =
security context, can the attacker exploit such a message to launch DoS =
attack? I do understand that even in DTLS, the handshake is performed in =
clear. Do you think we should consider mitigation strategy used in DTLS =
to include cookies to detect potential DoS attack?
>=20

This sounds reasonable.
Maybe we should even authenticate the end-points at the time of =
CryptoInitiation. Gotta think about the overhead of doing that=85

> 2. Is my understanding correct that the secret-key used to encrypt the =
CoAP messages is the PSK itself? Is there any reason for not deriving a =
session key from the PSK? I am just thinking if the PSK is compromised, =
this means that all previous communication messages are compromised too.
>=20

Key management is not handled by this protocol. It's assumed to be =
handled by an out-of scope mechanism. The task you are raising is for =
the key management.


> 3. I suggest that the CryptoTerminate Option is protected/MACed in =
order to ensure that it is originated from the client. Otherwise, any =
device in the network can spoof this message in order to delete the =
security context.
>=20

Makes sense.

Thanks.

Alper



> Cheers
> Sye-Loong
>=20
> -----Original Message-----
> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf =
Of Alper Yegin
> Sent: Thursday 3 November 2011 14:50
> To: core WG
> Subject: [core] draft-yegin-coap-security
>=20
> Folks,
>=20
> Please note the draft Zach and I produced for securing CoAP.
>=20
> http://tools.ietf.org/html/draft-yegin-coap-security-options-00
>=20
> Comments are very welcome.
>=20
> Alper
>=20
>=20
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>=20
> ________________________________
> The information contained in this message may be confidential and =
legally protected under applicable law. The message is intended solely =
for the addressee(s). If you are not the intended recipient, you are =
hereby notified that any use, forwarding, dissemination, or reproduction =
of this message is strictly prohibited and may be unlawful. If you are =
not the intended recipient, please contact the sender by return e-mail =
and destroy all copies of the original message.
>=20


From sarikaya2012@gmail.com  Fri Nov 11 18:41:05 2011
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 0102B11E8073 for ; Fri, 11 Nov 2011 18:41:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.445
X-Spam-Level: 
X-Spam-Status: No, score=-3.445 tagged_above=-999 required=5 tests=[AWL=0.153,  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 ViteujInzTI6 for ; Fri, 11 Nov 2011 18:41:04 -0800 (PST)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC8A21F8494 for ; Fri, 11 Nov 2011 18:41:04 -0800 (PST)
Received: by gye5 with SMTP id 5so4205577gye.31 for ; Fri, 11 Nov 2011 18:41:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=/N+w4AUT2j3eyhSH+Qw3Z+t1O2F8xuiFolmNrtwZe4c=; b=Pb+MKfHKyY6gqgeAidx30hs1dJMqtbiCeYC8/qtisWqNBXRSuve+oVO7xzUhoyxk56 2hf/sZLY2GFCPtj0WkbQvdJU8iRWY451rGGRf+QA56Ld8KvrNNpCQ/IT2X7Q9vcfU0cQ M+CLeSjWN3W89dx5pChffLi95/oEfjwRLbTN8=
MIME-Version: 1.0
Received: by 10.236.77.232 with SMTP id d68mr779029yhe.98.1321065662494; Fri, 11 Nov 2011 18:41:02 -0800 (PST)
Received: by 10.236.191.228 with HTTP; Fri, 11 Nov 2011 18:41:02 -0800 (PST)
In-Reply-To: <97F83FD9-93AC-4E44-9EFA-73D0C154EF82@tzi.org>
References: <97F83FD9-93AC-4E44-9EFA-73D0C154EF82@tzi.org>
Date: Fri, 11 Nov 2011 20:41:02 -0600
Message-ID: 
From: Behcet Sarikaya 
To: Carsten Bormann 
Content-Type: multipart/alternative; boundary=20cf300515c089b63604b18091c3
Cc: core WG 
Subject: Re: [core] IETF82 CoRE agenda
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: Sat, 12 Nov 2011 02:41:05 -0000

--20cf300515c089b63604b18091c3
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Carsten,
  It seems that you forgot to include  the objective for secure
bootstrapping.

Hint. Look at the charter.

Regards,

Behcet

On Tue, Nov 1, 2011 at 5:48 PM, Carsten Bormann  wrote:

> I have uploaded a drafty agenda at:
>
>        http://www.ietf.org/proceedings/82/agenda/core.txt
>
> I mainly tried to cover the drafts we should be looking at -- did I miss
> any?
> The resulting shopping list is still short on objectives for most agenda
> items.
>
> Those who want to achieve progress on specific drafts -- please send me
> the objectives for the slot I have put your draft under, and please tell =
me
> who will be presenting/leading the discussion.
>
> The agenda is way too full, and I probably even missed a lot of things we
> also need to do, so we won't keep slots that don't have very specific,
> credible objectives for this meeting.
>
> I plan to have a v2 agenda out 24 h from now.
>
> Gr=FC=DFe, Carsten
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>

--20cf300515c089b63604b18091c3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Carsten,
=A0 It seems that you forgot to include=A0 the objective for=
 secure bootstrapping.

Hint. Look at the charter.

Regards,
Behcet

On Tue, Nov 1, 2011 at 5:48 P=
M, Carsten Bormann <ca=
bo@tzi.org> wrote:


I have uploaded a drafty agenda at:



 =A0 =A0 =A0 =A0http://www.ietf.org/proceedings/82/agenda/core.txt



I mainly tried to cover the drafts we should be looking at -- did I miss an=
y?

The resulting shopping list is still short on objectives for most agenda it=
ems.



Those who want to achieve progress on specific drafts -- please send me the=
 objectives for the slot I have put your draft under, and please tell me wh=
o will be presenting/leading the discussion.



The agenda is way too full, and I probably even missed a lot of things we a=
lso need to do, so we won't keep slots that don't have very specifi=
c, credible objectives for this meeting.



I plan to have a v2 agenda out 24 h from now.



Gr=FC=DFe, Carsten



_______________________________________________

core mailing list

core@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/core





--20cf300515c089b63604b18091c3--

From jari.arkko@piuha.net  Sat Nov 12 04:13:41 2011
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 A21E521F85FF; Sat, 12 Nov 2011 04:13:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.526
X-Spam-Level: 
X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.073, 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 xSacoeXQee3Y; Sat, 12 Nov 2011 04:13:41 -0800 (PST)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 10AB121F8551; Sat, 12 Nov 2011 04:13:41 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 500112CCE1; Sat, 12 Nov 2011 14:13:26 +0200 (EET)
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 IL0adqpXQ9-0; Sat, 12 Nov 2011 14:13:25 +0200 (EET)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id F20672CC61; Sat, 12 Nov 2011 14:13:23 +0200 (EET)
Message-ID: <4EBE62E2.8010103@piuha.net>
Date: Sat, 12 Nov 2011 20:13:22 +0800
From: Jari Arkko 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: core , 6lowpan@ietf.org, roll@ietf.org
References: <4EB91C1D.5000606@piuha.net>
In-Reply-To: <4EB91C1D.5000606@piuha.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [core] informal hacking & interop session on Sunday
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 12 Nov 2011 12:13:41 -0000

The room is 202A. See you there!

Jari

On 08.11.2011 20:10, Jari Arkko wrote:
> In the last IETF we organized an informal session to demonstrate & test various smart object related implementations. We are now doing this again for the Taipei IETF. We will meet at 19:00-22:00 on Sunday, November 13th, (room TBD). If you are attending the IETF and have your Internet of Things toys with you (be it 6lowpan, coap, rpl, or anything else) feel free to join. Maybe you'll find someone to test with, or at least get to see other people with interesting implementations.
>
> Jari
>


From cabo@tzi.org  Sat Nov 12 18:31:38 2011
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 C3A6811E809D for ; Sat, 12 Nov 2011 18:31:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.688
X-Spam-Level: 
X-Spam-Status: No, score=-103.688 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, SARE_RECV_IP_061228=0.895, SARE_RECV_SPAM_DOMN0b=1.666, 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 Cf2dEbwHdhHo for ; Sat, 12 Nov 2011 18:31:38 -0800 (PST)
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 9A8ED11E809C for ; Sat, 12 Nov 2011 18:31:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id pAD2VLKg011527; Sun, 13 Nov 2011 03:31:22 +0100 (CET)
Received: from [192.168.0.237] (61-230-53-8.dynamic.hinet.net [61.230.53.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 4FD56495; Sun, 13 Nov 2011 03:31:19 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann 
In-Reply-To: 
Date: Sun, 13 Nov 2011 10:31:15 +0800
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <97F83FD9-93AC-4E44-9EFA-73D0C154EF82@tzi.org> 
To: sarikaya@ieee.org
X-Mailer: Apple Mail (2.1251.1)
Cc: core WG 
Subject: Re: [core] IETF82 CoRE agenda
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 13 Nov 2011 02:31:38 -0000

On Nov 12, 2011, at 10:41, Behcet Sarikaya wrote:

>   It seems that you forgot to include  the objective for secure =
bootstrapping.
>=20
> Hint. Look at the charter.

Sure, that is what the document is trying to address.

My request for an objective was about the meeting.
I see there are no changes from -02 to -03.
What is it that we want to spend meeting time on?
Please advise.

Gr=FC=DFe, Carsten


From sarikaya2012@gmail.com  Sun Nov 13 17:50:59 2011
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 3E10011E80F7 for ; Sun, 13 Nov 2011 17:50:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.456
X-Spam-Level: 
X-Spam-Status: No, score=-3.456 tagged_above=-999 required=5 tests=[AWL=0.142,  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 jMeHqS0MfQOo for ; Sun, 13 Nov 2011 17:50:58 -0800 (PST)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id EE34D11E80EB for ; Sun, 13 Nov 2011 17:50:57 -0800 (PST)
Received: by yenq4 with SMTP id q4so2793244yen.31 for ; Sun, 13 Nov 2011 17:50:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Xa7eiXEAzuCaBIBjjXOuRniiJ5h6tz9NC7QJIS7EVN8=; b=rDUzH9WIS64RWEs1Mp43ogRrFqhZAGSpjuqcq6Huccbgc8PbINc/WzfJHalb3Otv/v UOy1HSPKG6A9QYvAaMUrySjrvNl2S+BYAKS/vpu67kHuHqoedCm8yi8/2wHsGn1JoWQh N0u7W50CdhXFE5Y7+6Rneo5itQRk+AAeSQVnQ=
MIME-Version: 1.0
Received: by 10.236.22.136 with SMTP id t8mr11420251yht.30.1321235457590; Sun, 13 Nov 2011 17:50:57 -0800 (PST)
Received: by 10.236.191.228 with HTTP; Sun, 13 Nov 2011 17:50:57 -0800 (PST)
In-Reply-To: 
References: <97F83FD9-93AC-4E44-9EFA-73D0C154EF82@tzi.org>  
Date: Sun, 13 Nov 2011 19:50:57 -0600
Message-ID: 
From: Behcet Sarikaya 
To: Carsten Bormann 
Content-Type: multipart/mixed; boundary=e89a8f5033861d45f104b1a81a58
Cc: core WG 
Subject: Re: [core] IETF82 CoRE agenda
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: Mon, 14 Nov 2011 01:50:59 -0000

--e89a8f5033861d45f104b1a81a58
Content-Type: multipart/alternative; boundary=e89a8f5033861d45ed04b1a81a56

--e89a8f5033861d45ed04b1a81a56
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Carsten,
Yes but it has been revised at lot since last presentation in Beijing a
year ago.
Please see my presentation attached.

Regards,

Behcet

On Sat, Nov 12, 2011 at 8:31 PM, Carsten Bormann  wrote:

> On Nov 12, 2011, at 10:41, Behcet Sarikaya wrote:
>
> >   It seems that you forgot to include  the objective for secure
> bootstrapping.
> >
> > Hint. Look at the charter.
>
> Sure, that is what the document is trying to address.
>
> My request for an objective was about the meeting.
> I see there are no changes from -02 to -03.
> What is it that we want to spend meeting time on?
> Please advise.
>
> Gr=FC=DFe, Carsten
>
>

--e89a8f5033861d45ed04b1a81a56
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Carsten,
Yes but it has been revised at lot since last presentation i=
n Beijing a year ago.
Please see my presentation attached.

Regard=
s,

Behcet

On Sat, Nov 12, 2011 at =
8:31 PM, Carsten Bormann <cabo@tzi.org> wrote:


On Nov 12, 2011, at 10:41=
, Behcet Sarikaya wrote:



> =A0 It seems that you forgot to include =A0the objective for secure bo=
otstrapping.

>

> Hint. Look at the charter.




Sure, that is what the document is trying to address.



My request for an objective was about the meeting.

I see there are no changes from -02 to -03.

What is it that we want to spend meeting time on?

Please advise.



Gr=FC=DFe, Carsten







--e89a8f5033861d45ed04b1a81a56--
--e89a8f5033861d45f104b1a81a58
Content-Type: application/vnd.openxmlformats-officedocument.presentationml.presentation; 
	name="SecurityBootstrapping82.pptx"
Content-Disposition: attachment; filename="SecurityBootstrapping82.pptx"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_guytgk4n0

UEsDBBQABgAIAAAAIQDjZFbzbAIAABUSAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADM
WE1z2jAQvXcm/8GjawYL0jZNM5gckvbUj8wk/QGqvYBaW9JIgoZ/X1kGW2YMNrE85IIRtt4+7z6t
npjevWRpsAapKGcRmoRjFACLeULZIkK/nr+OblCgNGEJSTmDCG1AobvZxbvp80aACsxspiK01Frc
YqziJWREhVwAM3fmXGZEm6FcYEHiv2QB+Go8vsYxZxqYHukcA82mPw0BSRMIHonUP0hm4mAhNFap
+VEVl4+hQUTBfTE1jx4hIkRKY6INd7xmyV7cEZ/PaQwJj1eZiRYKCcpc7eNZGlrwyxwUtzD4RjZ8
pbc8isGnQdgU2K/ldHNGToxrUE9FuarvE9+MKui2JFVPKlx9v3prhN6fj5DV/3eitFn8xRIrBt6L
5gRqq5p9dMvGe2os+CkMPvguTicGeZt6lFwo39FL4E45aGh6w+SjX9MbZlvox+nad+Wsbrpx0mYH
Bmw/+zc7C9NJLds1O0zvOIVB/5d+jU1wst4/Bd2z3rBGh3n/btpzZFozS8N08jqnB5iTVaqDLy/G
WRZm9o+AxZ5hpFnuQe0NY/oa5khI1d6cFpO5NbahmWmdpVpSoXaKbYhw3MW22FFXm76bTA07I5Tt
XuKQO7e2amcgnEH/FeBSMU7dwW7jdEiC3jk5gY5xMocPu5djo6LeBYNc2wkkI2HsAUhNoRTaoRpp
8juFJ71JwbudcKCPZaA8xzU0q8nZyxKvlOZZ78oUMCfUxZFPrVVOxr257C0eJ1JbmdYU/g3iPEvg
NgYO2VpaPp8xK9Xp0T1JevfCVZhjSSr7ScwlnJ6U3WaVz25QK7Z/6sz+AwAA//8DAFBLAwQUAAYA
CAAAACEAR78a0BMBAAB1AwAACwAIAl9yZWxzLy5yZWxzIKIEAiigAAIAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKzTS0vEMBAA4Lvgfwi5b9Nd
H4hsuhcR9iZSf8CYTNto8yCZyu6/NxR8FGoV3GMyj3zJkO3uYHv2hjEZ7yRfFyVn6JTXxrWSP9X3
qxvOEoHT0HuHkh8x8V11frZ9xB4oF6XOhMRyF5ck74jCrRBJdWghFT6gy5HGRwuUl7EVAdQrtCg2
ZXkt4vcevJr0ZHstedzrC87qY8gn/6e3sEiggUAoH3EVYpZFMvkurIbYIkmuvXrI22nMKLKai3nQ
5rQg6gb77MD0M5TPWPESsP0JtP47yDeNUXjn1WDR0cwQxDTjyxQCiRAx5bJx7EsvdHVKkBoSefvL
yMacJdLlKUl4IHQa9TIKQvgQiclnqd4BAAD//wMAUEsDBBQABgAIAAAAIQDYA4Jr1wAAAM4BAAAg
AAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTEueG1sLnJlbHOskcFqwzAMhu+DvYPRfVbSQxmjTi+j
UOhp7R7A2EpiltjGcsfy9nMvxYHCLrvpl9CnD7Tb/8yT+KbELngFrWxAkDfBOj8o+LwcXl5BcNbe
6il4UrAQw757ftp90KRzWeLRRRaF4lnBmHN8Q2Qz0qxZhki+TPqQZp1LTANGbb70QLhpmi2mmgHd
iimOVkE62g2IyxLL5b/Zoe+dofdgrjP5/OAE+pCJz5OzVKg6DZQVSFm1uapbWdwBH2u1/6nFN6OT
XsI1r7yqPmMV7ma4+kL3CwAA//8DAFBLAwQUAAYACAAAACEAI/NwpNcAAADOAQAAIAAAAHBwdC9z
bGlkZXMvX3JlbHMvc2xpZGUyLnhtbC5yZWxzrJHBasMwDIbvg72D0X1WmkMZo04vY1DYae0ewNhK
YpbYxnJL8/ZzL8WBwi676ZfQpw+021/nSVwosQtewUY2IMibYJ0fFHyfPl5eQXDW3uopeFKwEMO+
e37afdGkc1ni0UUWheJZwZhzfENkM9KsWYZIvkz6kGadS0wDRm1+9EDYNs0WU82AbsUUB6sgHWwL
4rTEcvlvduh7Z+g9mPNMPj84gT5k4uPkLBWqTgNlBVJWba7qVhZ3wMdam//U4pvRp17COa+8qj5j
Fe5muPpC9wsAAP//AwBQSwMEFAAGAAgAAAAhAMRG2VDZAAAAzgEAACAAAABwcHQvc2xpZGVzL19y
ZWxzL3NsaWRlNC54bWwucmVsc6yRwWrDMAyG74O9g9G9dhrKGKNOL6VQ2GnrHsDYSmKaWMZyx/L2
8w4DBwq77KZfQp8+0P7wNU/iExN7Chq2sgGBwZLzYdDwcTltnkFwNsGZiQJqWJDh0D0+7N9wMrks
8egji0IJrGHMOb4oxXbE2bCkiKFMekqzySWmQUVjr2ZA1TbNk0o1A7oVU5ydhnR2LYjLEsvlv9nU
997ikextxpDvnFCBMvL75B0WqkkDZg1SVm2u6p0s7qDua23/U4t/jF7NQre88qr6rKrQ/pqp1Re6
bwAAAP//AwBQSwMEFAAGAAgAAAAhAMsIczdMAQAAfQYAAB8ACAFwcHQvX3JlbHMvcHJlc2VudGF0
aW9uLnhtbC5yZWxzIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAvJXLTsMwEEX3
SPxD5D1xkj54qE43CKkLJATlA0wyeYjEtjymkL/HSiF1q8psLDaJ5lq5czTjmazWX30X7UBjKwUj
aZyQCEQhy1bUjLxuH65uSISGi5J3UgAjAyBZ55cXq2fouLEfYdMqjKyLQEYaY9QdpVg00HOMpQJh
Tyqpe25sqGuqePHOa6BZkiypdj1IfuQZbUpG9Ka0+beDspn/9pZV1RZwL4uPHoQ5k4IqDfikpUJr
ynUNhpFJii0poechZiEhsGtLOACMIdLxlfkgrkNCCGkAHzka0AcUR0TqBKkPKwuJ5amNFyINDnFa
m5FsL/40ax94sZbBsQ7Ncu/NwtegNGhxDH/r4MUMnV0E0xA5oo9k8U/lmPsgUrviwm0UYzedM8xj
SMen92LMQzJ4hmbmq8RtSIhdC58nq3WSfiHo0U8j/wYAAP//AwBQSwMEFAAGAAgAAAAhAEv1Pey/
AAAANwEAACAAAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlNS54bWwucmVsc4SPwQrCMBBE74L/EPZu
Uj2ISFMvIgieRD9gSbZtsE1CNor9e3OsIHicHebNTn14j4N4UWIXvIa1rECQN8E632m4306rHQjO
6C0OwZOGiRgOzXJRX2nAXELcu8iiUDxr6HOOe6XY9DQiyxDJF6cNacRcZOpURPPAjtSmqrYqzRnQ
fDHF2WpIZ7sGcZtiaf7PDm3rDB2DeY7k848KxYOzdMEpPHPBYuooa5Byfue52MjyPqimVl9zmw8A
AAD//wMAUEsDBBQABgAIAAAAIQCtOQRg2QAAAM4BAAAgAAAAcHB0L3NsaWRlcy9fcmVscy9zbGlk
ZTMueG1sLnJlbHOskcFqwzAMhu+DvYPRvXaawhijTi+lUNhp6x7A2EpimljGcsfy9vMOAwcKu+ym
X0KfPtD+8DVP4hMTewoatrIBgcGS82HQ8HE5bZ5BcDbBmYkCaliQ4dA9PuzfcDK5LPHoI4tCCaxh
zDm+KMV2xNmwpIihTHpKs8klpkFFY69mQNU2zZNKNQO6FVOcnYZ0di2IyxLL5b/Z1Pfe4pHsbcaQ
75xQgTLy++QdFqpJA2YNUlZtruqdLO6g7mtt/1OLf4xezUK3vPKq+qyq0P6aqdUXum8AAAD//wMA
UEsDBBQABgAIAAAAIQBykoSAtwIAAAkOAAAUAAAAcHB0L3ByZXNlbnRhdGlvbi54bWzsl91umzAU
x+8n7R2Qb6eWhPBVFFK1mypV6qRoSR/ANYcG1RhkO1nSp98xOMVJuym3U3MHPh/8z0/H9mF6va25
twGpqkbkZHw5Ih4I1hSVeM7J4/LuIiWe0lQUlDcCcrIDRa5nX79M26yVoEBoqjHUwzRCZTQnK63b
zPcVW0FN1WXTgkBb2ciaanyVz34h6W9MX3M/GI1iv6aVIDZenhLflGXF4EfD1jV+vk8igXc61Kpq
1T5be0o2t4pDSYpuYLF+UqDvGqEV0iEzLFvx4idVGuR98aD00YpXFTkJxmESppNkFBBPZmYFfcfE
n039j8JFo0EdpTxYG5IkNsmBeVDhKrovei1R7IgITHynYW+OXY2T9+bIiQ7fm93k0Xtz4kTHxtwD
cHUuXj22zcnVOAxHI+w+tstJnEZp96J3LfacYhJAhFsrryvehr15mrB9jq7GAkq65noJW73QOw6z
Kc1wbT6X9unXXHqcmjYHcfG46NS5LnzDxy36UP6MO4NjJZrnBBWW2A033eITVYA9QTPVslso7dOc
aW9DO19T8ZH1psSe6dY+8rNWFGrkvYA0mxK3Sf+VhlfFXcV5l8BsMPjOZf8tve0bDDO7XmZXCM9g
LClDlDeyolgKW1GJfW3KQYk0A+r4fKvFBdDewNSRgakBFErs6rOkTCJ8DAy0msqHnIRRYrSfEb7x
N2z/gtBwswgnA8K+p88Ihxb+B0LDzSIMB4TjSTKOz2144k424CzDyGGYBikeyec+PKkPDTjLMB4Y
BkGKbegyxGN+SZ8Wr/ura7hjgD6IW/liZg68pPAMt68YvcI7C8en+VowPMDNTNLdWv/XfWGwWEKJ
QygJJ4cXxuclZLBYQulAyODBOcnZh5+XkMFiCV05hOIoOTztPy8hg6WbuRHB0TCMg7j75zP7AwAA
//8DAFBLAwQUAAYACAAAACEAy1F2Ss4DAABCDAAAFQAAAHBwdC9zbGlkZXMvc2xpZGU0LnhtbKxW
XXPaOBR978z+B42ftjOlgPkI9QQ6EwJpZrYpE9LpvgpbYM3KklcSLnSn/71Hsp0ADdsmhAfjj6uj
e869uveev99kghRMG67kMGi/bQWEyVglXK6Gwee7aWMQEGOpTKhQkg2DLTPB+9Efr87zyIiEYLU0
ER0GqbV51GyaOGUZNW9VziS+LZXOqMWjXjUTTb8CNRPNsNXqNzPKZVCt17+zXi2XPGaXKl5nTNoS
RDNBLTw3Kc9NjZb/DlqumQGMX73n0gjM4rlI3L/J7zRj7k4WVzqf5zPtP98UM014Ar0CImkGWYJm
9aEy848SZrhpHixf1Ug02ix1NjqnEbiRzTCA+Ft3xSIasY0lcfkyfngbp58esY3TySPWzXoDeHC/
qWNVMvqZTljTueNWMNK+Z1WaUiz9S8X/GCIVeDr6Jb34pqjBHGcHn6fEbnMoYx1UZVd+9HrU9gaa
erHs5kIlW0d8gX//kkbC2LndCuYFgds0AjgukF9Ql6FMNj7PA5Jwbb1GxGR2LBhFLlcy2tE4pdoy
Ta4ty86hiUVIKiAmkxnV9PYonuNHI+wMp2sPcVtKeFzITi3kWEmLNCMzQWOWKpHAj/A0WXmCpKiV
P6KoE+kgt7q9M5w7n2DtsD846x+k2SAM3/WdgUu2XnsA+74PW43kaZfBrZV4+VjdpYygUCwtSakh
K5QcYlOt1quUGIYyRQXRrOCuWpm9WJZR8qF6VpK4jQU1luyhPgsKTp8OQv5stDqvcdBInCLT2Zs9
yFPZ3lYa7oE+i+wL6MVloUSB1kA+XM8al5O/XwAT6oWvD9j98rAfFo9TVf7CEya2SNhYrST/xhKC
nLb3Ga4kcjpea263ZKGUNVbTPHc67Dl+qhe3TLCCogbt1sHoqVssfLN7vM66amOU4MmUC+Ef9Gox
FpoUVAyD6bSFX1VKdszAC3XcmdvRJYtJ2Gq3SIOgYjohuIRcR+QxOYs5hgHfvIlZLzJuLcytIteT
+ZVTeY/escQ+5MQ0BhG09N0ecjq32fyW0WT7LI9e1hMn0ALJmDHy5aoss3telZn2tE7XrTvdHPFn
5GadLdDidttd57R2V04RmDUBjdB8Gwb/rn0/DzCBuU7o2ymcPtIKnzJc+PmORglbYiKoWn+ZokvM
um7g+2/aG0/C1uW40T4Lx43upN1pXPT7fZStyeCi15t0p5PO96CafYzTRMJvl0U/DS27wS0HnHKv
R7a3o+5DpOCLw/tlOfuf2cX38nK2xW097sZCf6T5p8IfSkzxGJpwivHKFSWHBtMHE4cBT34AAAD/
/wMAUEsDBBQABgAIAAAAIQBtHVe9WQMAAB0KAAAVAAAAcHB0L3NsaWRlcy9zbGlkZTUueG1stFbf
b9s2EH4fsP/hoKcNqGNb/pUJsYPEcboBnWvMKbZXhjxbRChSI2nH3tD/vUdKaubGwbo6e5Eo6vjx
7rvjd7y43BUKtmidNHqcdM86CaDmRki9Hicf7m5b5wk4z7RgymgcJ3t0yeXk++8uyswpAbRau4yN
k9z7Mmu3Hc+xYO7MlKjp38rYgnn6tOu2sOyRUAvVTjudYbtgUif1evs1681qJTneGL4pUPsKxKJi
njx3uSxdg1Z+DVpp0RFMXH3g0oQi40slwtuVdxYxjPT2rS2X5cLG3/PtwoIUxFcCmhVES9Kuf9Rm
8VOTGQ3aXyxfN0gs261sMblgGcUGu3FC5O/DkxaxDHceeDXJn2Z5/v6ILc9nR6zbzQbkwedNQ1RV
RM/DSZtw7qRXCN3PUVWmjJa+M/zBgTYUZwi/Co/Ptw1YiDnAlzn4fUnM+ABV21U/Ix+NvSNOI1l+
d23EPgR+T+84yTLl/NLvFUZCyG2WETg9iH7FQoWibn1YJiCk9ZEjcIWfKmRUyzWNfjIPTC49lu7y
gijxlJEaB7VYMMt+exEuhMcy2ph8bhykYcXgyzz2Gh6nRnuqMlgoxjE3SqCF9DRWpaCaaIh/gdDA
0Rel1R+M6NjF+up2BumoNwxuPFXZeZr+NAwGodYGnVGvn45i1hqkGHaV24aJ10/VNGfSgmNSwCOC
RhS1+FjhwFvGH0DUAnCQyipJMVPfVCK/I3CmoWAPCNI/25PkDyRlcm2ZjwaP0ucwNRZhiXxjpd+D
M2oTpAh+uLl7t3wDJHcr3zrw8t9dQ0tSSKJypIr3uJb6P8IdgXkD6PnZjwdAJ7P3Fko6cw6BiS1p
NGwcGJ296h6Lq/nV4fE91evzTnrW/eN1MX/+ZdG6mb0y6JVSYFbgc+L33mzx0GU6wv+TivUbFVsq
KRDmm+Ke5OufUtY7TcqqBkHXCIKmmv9rnPy5YdajTai5BpWLUhnbRRCeOPjWvhFbN8sErkjta1kP
oCxb0TUm9PK/bwfTWdq5mba6o3Ta6s+6vdb1cDikhM7OrweDWf921vuY1G3NBU40+X20Hz07eC9v
7yeDp4NCvkRRPiGjUaerawsNm5sMV/ZXVr7fxojpgkYkT+NUSVeyQAeZPpkEDPLkEwAAAP//AwBQ
SwMEFAAGAAgAAAAhANvuk1iwAwAAxwwAABUAAABwcHQvc2xpZGVzL3NsaWRlMy54bWzUV21v2zYQ
/j5g/4HQd8eW/BJHiF0kjr0NaBOjToF9pSkq4kKRKkm7dof99z6krKRuvDZwFhT7IvPleLx77o73
+PzNppRkzY0VWo2i+KQTEa6YzoS6G0UfbmetYUSsoyqjUis+irbcRm/Gv/5yXqVWZgSnlU3pKCqc
q9J227KCl9Se6Ior7OXalNRhau7amaGfoLWU7aTTGbRLKlS0O2+ec17nuWD8SrNVyZWrlRguqYPl
thCVbbRVz9FWGW6hJpzeM2kMz9hCZv7XVreGcz9S699MtajmJmxfr+eGiAx4RUTRErBE7d3GTixM
FcQwaH9z/K7RRNNNbsrxOU3hG9mMIoC/9V8coinfOMLqRfa4yoqbA7KsmB6QbjcXwIKHS71XtUdP
3TlLYoS79uhWOMlJ/OBYLU1x+q1m95YoDVc9ArWH7Hrd6PNu+xuqgrhtBXCcV7WTqzcDJI28BawB
L7e51NnW+77Eb1ikqbRu4baSB0xgOU0hTjh9qy7NfYhAQdUdEmu+UsztDKIpLMAHkhK7o4ir1odF
RDJhXMCS2NJNJKfI+R3cbjw32mmmpT0HcA5xC1rwxa0wuLEOwxrB7+J41uA40coh0chcUsYLLTNu
SPIyVEWGtGiA/xdAvfvfZFevf4rKCykWx71uB+O9RBsmydnAC/h063f7p8O4G6LWaAqe17FtwHi9
UC1DbA8HzDtntRTZTEgZJv7Z4RNpyJrKUUQZA+Q1QnuSPqTeAR/fBWcrI9yW3Cz/4syJNT8U+BD9
F+XcqzsyvZjvZexRyZ8SqCF05QogJ1h4F0lu8Lh90uaeLKnlGdGKvJ9NSD/pne7dWNfI/wCqizUV
ki7xsL3jrtDZfsSPA+77SMg18hFt4lUerIvri593++9/zFtX0z9/ngHDTnIS/+D+I2F//Zotq4Ja
YYlQBCVHQI5yRzDfg/OohESReo2Gf1wJg1dROesLl1NWEJ2HPfpQBmVdBgQEj5ScO/TRIKH/qzeR
q2xODX3/7E58TL/tNc12gZ7AyfWqXKLLft1xQyMDsWtYylE8BoQXqsGHP4+ijytqHDcRaKBvxqGj
B1bj20sYvIDe+AaV8RygeXIVuo9fykG4Pev8e9afTJPO1aQVnyaTVm8ad1uXg8EA5TgdXvb7095s
2v0n2rEv6zFRsNureMKInvCgwHEPXu/G3cfshC1e3w/Du3PgEIMKdKIm2Bg2nJtJ845WN+vQpfFX
AiCjr2OpQm56bRB9FPE6YMkXAAAA//8DAFBLAwQUAAYACAAAACEAQAeLWGkEAABbFAAAFQAAAHBw
dC9zbGlkZXMvc2xpZGUyLnhtbOxYwW7jNhC9F+g/EDr05sh2Em+qRl7YjtMu4M0acRYFeqMpyhJC
kSpJO3GLXvoT/cz+Qh8pKbETL5pNNsjFPsiUOBzOvJkhZ+b0/W0hyIprkysZB52DdkC4ZCrJ5SIO
Pl+dt04CYiyVCRVK8jhYcxO873//3WkZGZEQrJYmonGQWVtGYWhYxgtqDlTJJeZSpQtq8aoXYaLp
DbgWIuy2272woLkM6vX6KetVmuaMnym2LLi0FRPNBbWQ3GR5aRpu5VO4lZobsPGrt0TqQzM2E4n7
N+WV5tyN5OpnXc7KqfbTF6upJnkCvAIiaQFYgrCeqMn8qwQZBuGD5YuGE41uU130T2kE3chtHAD8
tXtiEY34rSWs+sjuv7Ls0w5alo13UIfNBpDgblOnVaXRY3VOOj8eNRpd5VZw0rlTrKKmWD1R7NoQ
qaCqQ6DSkF2sGn5ObbdDmRG7LgGOdaxqumrSQ9LQG8Dq8bK3Q5Wsne5z/PuPNBLGzuxacI8JJKcR
yAmnEznU194CGZULONZ0KZmtBaIRJMADlAKzccBl6/MsIEmurceSmMKOBKfw+Rpu2x9oluWWM7vU
/BTYWZjOM8ITG0PmRkAMKxC/DOVhg+NISQtHI1NBGc+USLgm3Zehmidwiwb4rwGUaCtGSjidHTwS
0TlYWpXmlgg5K9klT5bMxRPYt/HzNmus4VbsNkZB9SQOuu+ODrvw4Fwm0DcOWs2HTVulQGMgFtiA
YuOAPLSd28SUbMjTejS1hqwoRD4+acTZmh+kMJNfc0e5QVfPzpfn2Nd7YworxMGv8Bd3xJnKFFBx
OcqoJgyPOPj373+c5jRKeHpZhbD3Ovdpt1/NvSPu9i4vnhJ5cp4L4V/cGclHQleKUcaAV2VOKHJP
6ZzPRZLzxJ5QN9PBBbk4I0qTLe98qkxcQzUcWJue/01k+y1fzPl2xDxVpm8uC5mNSfegTehGLIdW
lUqoxZrQRJWWJ1vwVcHtI7w6Wvbe/OrefKmUxQWScJIbwpTSiEVqlQ57k+Hl3jruhnOR+UZnzQdc
WDrHMaPVEiMT9vZGcafEmxplwmnqQ8bs4+ONTTHE6WWspmWJDIJc87Uhc2p4QpREtrlGxOxN9MYm
mqgbpNneGKTUyiqmhImelzdt5ig+K7T9k3b3oHN8cEQ+DkbkB1qUPz2P9a6UrN4CGiDf23Kk51wI
NTdkPrSsil0ycS66xXifAj0qFF89BfolX2Sv6aIfpgRNG0LnasUfOieXyZRqitLmidVx5SBfVwDf
NRJmKH04uVgWc+i7WQUfvqwKrnoLaEKBNaqaP+Lg9yXVSFhQgvoC2VfZvtPgbm4/eEHLwSVkO+rB
FE0w1wn68/x4NO62z0atzrvuqHU07hy2hr1er3U2Hp8Mj4/HR+fjw7+CuiNiHCYScvs076EdHp04
deqxY3vb796HMmRx/P7XvDgUvmRR39moml4YNn0wJvRHWn5a+YQU7T2AjPIVn9wN6LiB9J7E8YAk
/wEAAP//AwBQSwMEFAAGAAgAAAAhACBGqtfpBQAAhxIAABUAAABwcHQvc2xpZGVzL3NsaWRlMS54
bWzkWNtu4zYQfS/QfyD01KLwWvI9RpxFnGy2C2SzRpxF0b7RFBWpoUiVpBw7Rf+9M6QUy47dZNOi
Ldo8OJQ4HA4P53JGx29XuSBLrk2m5CSI3oQB4ZKpOJO3k+DzzUVrFBBjqYypUJJPgjU3wduTr786
LsZGxARWSzOmkyC1thi324alPKfmjSq4hLlE6ZxaeNS37VjTe9Cai3YnDAftnGYyqNbrl6xXSZIx
fq5YmXNpvRLNBbVguUmzwtTaipdoKzQ3oMat3jLpBE7G5iLG/6a40ZzjSC7f62JezLSbvlrONMli
wCsgkuYAS9CuJiox9yhBDAbtneW3tSY6XiU6PzmmYzgbWU0CAH+Nv7CIjvnKEuZfss1bln7aI8vS
d3uk2/UGYMHjpngqf6Knx+mEfTDBn+gms4KTzuPBvDSF1ZeK3RkiFRwVEfAnZFfLWh8eG3coUmLX
BYDDrHbaKlE/71CplxhA1kFmV1MVr/H4C/jvXtKxMHZu14I7WMB4OgZxwumlnOo7dwkplbfgW7NS
MlvZRMdgBPyApIDZScBl6/M8IHGmrYOTmNyeCU7B7SvE7cmcs1Jndk2mSlljNS0KUHsMQFq4R6cS
fsEEsL42FYYe0cO4DqLeoMZ1Xi6sg9YhB75WA/cqaE258NCCO4Kv1LdxAGIEZMflou4wGoTe8bqj
0QBiE69p436DXhiOUACdsBP2ulHXSTSdC68Pb7yGpL49oq04UwIBRpUSssFpaVWSWZIoaeeMCnCP
4bCP+oWcF+yaxyXDiMa94M+5TK0OdTzvC6j5VNyCBgp7BWTXN1CLKdhpAlfqRjNryJI6K9GXm7OL
8gK0OTdOKANbT3VGRUCKzLL0guaZAFC6PQAnpdpw8L0KvUV5BenSARnz5NrnAee3uOkrPHPKU8Yt
mVOd3dE1Jd9UCYzrb/e4p/PRp2HyH4CGaygWkHb3BO+PCsrAFhivQpp8Shd0S40P+b8B07/GVa7V
gmtLPipzp+4z+/DPnOXfEzo/pVySM6r+7zhUfrEFw/MR8gcBd6bpbcZ39HEZz6imkPJeWHdfU1D7
z1RTgpXI1UOf4x1lweTeqLfIyjb8rMlEyOL+o4oh27sCghp2iibUqxCzPiT/QTjsdMLBds0cRb3u
Ubfja2Z/GPXDXlXIakWFNvY9VznBwSTQnFlXIuny0lhfhWoR3F+qi0wIV06EJPeT4Kjf6Vc19XEm
zywH0LN8EkDBroonHaecxu9k7BZbmgk/BtSFdIAcLN7QFYBpqdIPAbkHKjQJzC8l1RxK9QdpwIao
14O6bd1Drz/swINuziyaM7LMHRWA3L1hBYRKBhtMAhtUwzMLT8g2VF5Qe4mcAPM9goCA3Kx+oLqo
ULNAka/UPKUF3weel/XwbYjHLs2IaqQAEc85ccV+miGWjiUQ6ugF0NrA8ZgG28C1QC6mPKlGM2Y9
uWjSmS2JFxGRF1cG8wCEBEncAaLrzFIii9Ft3AN2bPxMaG+mXXmwbQa8x7EiZGc1D3PtHQp7ntTU
g42YbDCl73LZErZye2DhuJc9gSYwsS1TsZgWU5q3zKJJtlthl1BLPry7uSCjzuHkclfmWa5+zpy3
bDH8DQQLN+lFykkggZJhNwsUCoJbqrkbBeSOa+x9HWoM/bwSRNcDIJG2UpE98O/d44IaLjLshd3c
TCuVuPH+zgLPjZHWCOIq9sBTmgA+YvsnL4InCWQTn0bouLyUNysX+yXeeDU+fFlA/OnOLXLqsxsz
OxPMVNe7yfnOL768P3pM5+CYnFyVOTAYMhNAuVMlYhj3cadG8sYo++I+FD5YgGrwAIgRzGSQLoOq
b3J9LlSHA42T23y3u3Go7k0UeNt7IjaBDyb41eDXzvkoGnSHR60jKBOt3lH3vDXt9qJWdN6fjqLu
UT/sTn+DzOq6Z4OYQPZ0Ke5JO/uEB7tWbO/29iTahBPYglZubu5AtYZDHirQrvH1H0iwrlbfTJjQ
H2nxaekCHj4FAciQL+AVdtKoDUQ3IqgDLPkdAAD//wMAUEsDBBQABgAIAAAAIQCSjbYzdgMAANML
AAAhAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDIueG1szFbNctowEL53pu+gcc+OMX8l
HiBTjN1LkzAleQDFlmM3suRKgkI7nclrtY+TJ+lKtkhDyQyEHHoxWN79pP1291sNz1YlRUsiZMHZ
yPFPWg4iLOFpwW5HzvVV7A4cJBVmKaackZGzJtI5G799M6wCSdNPeM0XCgEGkwEeOblSVeB5MslJ
ieUJrwiDbxkXJVbwKm69VOBvgF1Sr91q9b0SF8xp/MU+/jzLioRMebIoCVM1iCAUKzi/zItKWrRq
H7RKEAkwxvvpkdS6gmj5zRcHGSOxhFffGUPcyZymiOESFq4KRQkCdlDImQIkYyCrK0GINmXLj6Ka
VzNh/C6WM4GKVOM0/o7XfGjMzCsDM/jjbbnfWiQcrDJRjoc4ADLQauRAztb6CU44ICuFknoxeVxN
8ssdtkke7bD27AZwgs2mkO6qjujfcNo2nJoOfxNVbYrB9RNP7iRiHOLU4dfhJRdLC6Zj1vBVjmrm
lWa2sas/Gj6svQRODVlqNeHpWgd+A79mEQdUqrlaU2IIgWPjAMDhAfRTrAubMPd6DoVdqpASDIXf
kKfGIS2SO6Q4Immh0DmWighkDgNtAJBDYEdBchpIwtIZFvjzFrKODwewMxzanhD+1hQ+T2THEtlU
E5pRnJCc0xQO0T6O1iKForDMvwKjkABEl3RD3ZEM67I1BMsnDNcsGirhYbc0YRyQ1DlJOPQoJUtC
94A3TB8Af5UXYn/0js7jAegxXwiV73347qHwRbYTHZTkVWu7a2t7ihV5UtiGEJBVqwYv0otUQTt/
B83HNHNAZHWxm6Y2sqHF5QX6ofMENe4bAcdBSjJo9Lq3N8tQoVZutLlRmx32zVIGo0NPgB+n/mm3
34v67iCKO2439j+4k86k67ai6SCcxvGk3zr96TRimAJlqiiJnj9QOVtis0vGfN/zOzAdff+x3mFv
7f5MWlFaCGUHxkvEq2cTHHOuRfNv7TJFeWyKMyXqHH9dYAE72DQfLWqvn+ZnOH7hWOhbZue0SAm6
WJQ3W/z2jpsN9ciF+xxA76TYKOJ/2klxL4zarWno+u/boduN/I476ff77jSKBpNeL+rGUWfTSVIz
yCDKXY1kdPn53lXjh/tf7x7uf79qS5lrQX1fhL/6bmmuhFSc4+pyaaYqXKWh3EOzVMHlWZcRmD6a
aAx7GR//AQAA//8DAFBLAwQUAAYACAAAACEA1dGS8b4AAAA3AQAALAAAAHBwdC9zbGlkZUxheW91
dHMvX3JlbHMvc2xpZGVMYXlvdXQ0LnhtbC5yZWxzhI/BCsIwEETvgv8Q9m7SehCRpl5E8OBF9AOW
ZNsG2yRko+jfm2MFwePsMG92mv1rGsWTErvgNdSyAkHeBOt8r+F2Pa62IDijtzgGTxrexLBvl4vm
QiPmEuLBRRaF4lnDkHPcKcVmoAlZhki+OF1IE+YiU68imjv2pNZVtVFpzoD2iylOVkM62RrE9R1L
83926Dpn6BDMYyKff1QoHp2lM3KmVLCYesoapJzfeS5qWd4H1Tbqa277AQAA//8DAFBLAwQUAAYA
CAAAACEA1dGS8b4AAAA3AQAALAAAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQz
LnhtbC5yZWxzhI/BCsIwEETvgv8Q9m7SehCRpl5E8OBF9AOWZNsG2yRko+jfm2MFwePsMG92mv1r
GsWTErvgNdSyAkHeBOt8r+F2Pa62IDijtzgGTxrexLBvl4vmQiPmEuLBRRaF4lnDkHPcKcVmoAlZ
hki+OF1IE+YiU68imjv2pNZVtVFpzoD2iylOVkM62RrE9R1L83926Dpn6BDMYyKff1QoHp2lM3Km
VLCYesoapJzfeS5qWd4H1Tbqa277AQAA//8DAFBLAwQUAAYACAAAACEA1dGS8b4AAAA3AQAALAAA
AHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQyLnhtbC5yZWxzhI/BCsIwEETvgv8Q
9m7SehCRpl5E8OBF9AOWZNsG2yRko+jfm2MFwePsMG92mv1rGsWTErvgNdSyAkHeBOt8r+F2Pa62
IDijtzgGTxrexLBvl4vmQiPmEuLBRRaF4lnDkHPcKcVmoAlZhki+OF1IE+YiU68imjv2pNZVtVFp
zoD2iylOVkM62RrE9R1L83926Dpn6BDMYyKff1QoHp2lM3KmVLCYesoapJzfeS5qWd4H1Tbqa277
AQAA//8DAFBLAwQUAAYACAAAACEA1dGS8b4AAAA3AQAALAAAAHBwdC9zbGlkZUxheW91dHMvX3Jl
bHMvc2xpZGVMYXlvdXQxLnhtbC5yZWxzhI/BCsIwEETvgv8Q9m7SehCRpl5E8OBF9AOWZNsG2yRk
o+jfm2MFwePsMG92mv1rGsWTErvgNdSyAkHeBOt8r+F2Pa62IDijtzgGTxrexLBvl4vmQiPmEuLB
RRaF4lnDkHPcKcVmoAlZhki+OF1IE+YiU68imjv2pNZVtVFpzoD2iylOVkM62RrE9R1L83926Dpn
6BDMYyKff1QoHp2lM3KmVLCYesoapJzfeS5qWd4H1Tbqa277AQAA//8DAFBLAwQUAAYACAAAACEA
nouRgFYEAABCEQAAIQAAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQxLnhtbMxY224bNxB9
L9B/ILbPGy33or3AUgBZcV8cx6icD6B3KWsR7qVcSpUaFMhvtZ+TL+kML5Ls2ogbCIFeJC53ODwz
h8OZ2Yu320aQDZdD3bUTj74JPMLbsqvq9mHifby78jOPDIq1FRNdyyfejg/e2+nPP130xSCqa7br
1oqAjnYo2MRbKdUXo9FQrnjDhjddz1t4t+xkwxQ8yodRJdkfoLsRozAIxqOG1a1n18vXrO+Wy7rk
865cN7xVRonkginAP6zqfnDa+tdo6yUfQI1e/RiS2vVgraqV4B7RYnIDE9SbguXlQlSkZQ1M3KEE
WYi64vrV0N9JzlGo3fwq+0V/K/WKm82tJHWFGuxKb2RfWDH92IIYDEZPlj84TazYLmUzvWAFOIJs
Jx7wtcNfWMQKvlWkNJPlYbZcfXhGtly9e0Z65DYABPtNgereWPRfc0JnjnEE3VtlRBksve7KTwNp
O7ATzTfmlTcbpwxtRvX9ihivl0pqbVbUvNcucUsG7VaHde+McZZkgfFISKMgDpPHfknTNIxRAL1D
4zQIjMSx1UZ1X6jtrKt26NV7+NessEIMaqF2gmtvg09YAcjhB7gVDCOGt/7HBURMoy4FZxBRlhk1
vRR1+YmojvCqVuQ9GxSXROnTM6DKCwChgHmrkrfVLZPstyea0XmsgJ3BHQ4hDA0/L7MUOZYW63uz
Z3gKoob1vSEKTjYcO8ft6wmjUUrHlrEoy8ZwJzxmbAx0aUo1Y2kSorRxggkEbbw5P84fzzKGNImN
oHBwSMPktY6cuq0g+vWQiQdgC04eRDEoWN/AbadZrvgSSMDJoYMov6qF0A94xfFLIcmGCbgotngz
AIN1q8xMmgR7qPo+RGHN3pEe4NLph6HFh3pgGB6gxkmKniHnhxdBWrzRAW9OYx1m54cXQVq88QHv
/hieH2BEaQEnR4CzMNNhcX6AEaUFPD4ADsMMIvcsjzCitIDTI8BpHJ1pzCFKCzg7AEa0Zxp0iNIC
zo8Aj5NU3/3nd4YRpb6qXb5H9CdI95Avf1TGj13GnzPFya1gJV91ooKaIzpF5q8UFDl/QonNxBLy
ks7+JjFj5aq9h4OFdiTWJ7qAOtQs38rR6HCTGU2y36dGTJO2CNuTojd5LG+nllCnY9H9OcmjjM5n
1I+TMPHjq+Cdn8dZ4qdRTKM8vsyTOP7Ls/VnBS5TdcNNSn9NcUfpiEbQjFB6KONgb0T4QiFHqloq
V6N/T0mXOIKvug5LyWOK41NQvIRaSHP8+5pJ2MHR/I0qD/j64TS/4GNzdP53sTx2ntVdHblZN/dP
/KvbCmgDXQ/zXV0OtM+g+lkX6+JcNzznF0nhPKPjKM39PMojP86juT+DIPLpPJllEEtJEM32kTRg
X9yClRgJTwNJl9cvx66afv3y9y9fv/xz0pDS/YJp0WGIjbzuwoV8z/oPG52m4MsFHHeo1mGqh28V
eIxA9CCCOty3j+m/AAAA//8DAFBLAwQUAAYACAAAACEAFzztatUAAAC/AQAAKgAAAHBwdC9ub3Rl
c1NsaWRlcy9fcmVscy9ub3Rlc1NsaWRlMy54bWwucmVsc6yQwWrDMAyG74O9g9F9dtLCGKNOL2PQ
wy6lfQBjK4lZIhtLG+vbz1AKCRR22Un8Evr0od3+Z57UNxaOiSy0ugGF5FOINFg4n96fXkCxOApu
SoQWLsiw7x4fdkecnNQlHmNmVSnEFkaR/GoM+xFnxzplpDrpU5md1FgGk53/dAOaTdM8m7JkQLdi
qkOwUA5hA+p0yfXy3+zU99HjW/JfM5LcOWF4igEr0JUBxYLW1w5fy1ZXWTD3Pdr/9KAkyB+OBcvK
ZtFnswjtzcys3t79AgAA//8DAFBLAwQUAAYACAAAACEAaaJfIR4BAADHBwAALAAAAHBwdC9zbGlk
ZU1hc3RlcnMvX3JlbHMvc2xpZGVNYXN0ZXIxLnhtbC5yZWxzxNXdasMgFAfw+8HeQc79YpK26Qc1
vRmDwq5G9wASTz5YoqJ2LG8/KQwSKI5CwJuAiuf8+CvmePoZevKNxnZKMsiSFAjKSolONgw+L28v
OyDWcSl4ryQyGNHCqXx+On5gz53fZNtOW+KrSMugdU4fKLVViwO3idIo/UqtzMCdH5qGal598QZp
nqYFNdMaUM5qkrNgYM7C97+M2nf+v7aq667CV1VdB5TuTgtq+07gOx/V1fmy3DToGCTJdN5OB7vE
84Hel61iylYh2TambBuSZfmSNOevGc4O8jZDb98s5FiU8eitykOybMmAHpUFMytiyopgZnFDC6a2
iZnaJpiaf+vjPa1ZGrKtY9LWIdk+pmz/J6Oz32/5CwAA//8DAFBLAwQUAAYACAAAACEA1dGS8b4A
AAA3AQAALAAAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ2LnhtbC5yZWxzhI/B
CsIwEETvgv8Q9m7SehCRpl5E8OBF9AOWZNsG2yRko+jfm2MFwePsMG92mv1rGsWTErvgNdSyAkHe
BOt8r+F2Pa62IDijtzgGTxrexLBvl4vmQiPmEuLBRRaF4lnDkHPcKcVmoAlZhki+OF1IE+YiU68i
mjv2pNZVtVFpzoD2iylOVkM62RrE9R1L83926Dpn6BDMYyKff1QoHp2lM3KmVLCYesoapJzfeS5q
Wd4H1Tbqa277AQAA//8DAFBLAwQUAAYACAAAACEA1dGS8b4AAAA3AQAALAAAAHBwdC9zbGlkZUxh
eW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ3LnhtbC5yZWxzhI/BCsIwEETvgv8Q9m7SehCRpl5E8OBF
9AOWZNsG2yRko+jfm2MFwePsMG92mv1rGsWTErvgNdSyAkHeBOt8r+F2Pa62IDijtzgGTxrexLBv
l4vmQiPmEuLBRRaF4lnDkHPcKcVmoAlZhki+OF1IE+YiU68imjv2pNZVtVFpzoD2iylOVkM62RrE
9R1L83926Dpn6BDMYyKff1QoHp2lM3KmVLCYesoapJzfeS5qWd4H1Tbqa277AQAA//8DAFBLAwQU
AAYACAAAACEAmfaZrtUAAAC/AQAAKgAAAHBwdC9ub3Rlc1NsaWRlcy9fcmVscy9ub3Rlc1NsaWRl
Mi54bWwucmVsc6yQwWrDMAyG74O9g9F9VpLDGKNOL2PQwy6jewBjK4lpYhtLLevbz1AGCRR22Un8
Evr0od3+e5nVhQqHFA20ugFF0SUf4mjg6/j+9AKKxUZv5xTJwJUY9v3jw+6TZit1iaeQWVVKZAOT
SH5FZDfRYlmnTLFOhlQWKzWWEbN1JzsSdk3zjGXNgH7DVAdvoBx8B+p4zfXy3+w0DMHRW3LnhaLc
OYE8B08VaMtIYkDrW4dvpdNVFvC+R/ufHjEJ8YdlobKxWfUZV6H9NcPN2/sfAAAA//8DAFBLAwQU
AAYACAAAACEASq91OdQAAAC/AQAAKgAAAHBwdC9ub3Rlc1NsaWRlcy9fcmVscy9ub3Rlc1NsaWRl
MS54bWwucmVsc6yQwWrDMAyG74O9g9F9VtLDGKNOL2PQQy+lewBhK4lpYhvLG+3b11AYCRR22Un8
Evr0oe3uMk/qh7P4GAy0ugHFwUbnw2Dg6/T58gZKCgVHUwxs4MoCu+75aXvkiUpdktEnUZUSxMBY
SnpHFDvyTKJj4lAnfcwzlRrzgInsmQbGTdO8Yl4yoFsx1d4ZyHu3AXW6pnr5b3bse2/5I9rvmUN5
cAJl8o4rkPLAxYDW947cS6urLOBjj/Y/PUIsLAeSwnlls+gLLsKvGa7e3t0AAAD//wMAUEsDBBQA
BgAIAAAAIQDV0ZLxvgAAADcBAAAtAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91
dDExLnhtbC5yZWxzhI/BCsIwEETvgv8Q9m7SehCRpl5E8OBF9AOWZNsG2yRko+jfm2MFwePsMG92
mv1rGsWTErvgNdSyAkHeBOt8r+F2Pa62IDijtzgGTxrexLBvl4vmQiPmEuLBRRaF4lnDkHPcKcVm
oAlZhki+OF1IE+YiU68imjv2pNZVtVFpzoD2iylOVkM62RrE9R1L83926Dpn6BDMYyKff1QoHp2l
M3KmVLCYesoapJzfeS5qWd4H1Tbqa277AQAA//8DAFBLAwQUAAYACAAAACEA1dGS8b4AAAA3AQAA
LQAAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQxMC54bWwucmVsc4SPwQrCMBBE
74L/EPZu0noQkaZeRPDgRfQDlmTbBtskZKPo35tjBcHj7DBvdpr9axrFkxK74DXUsgJB3gTrfK/h
dj2utiA4o7c4Bk8a3sSwb5eL5kIj5hLiwUUWheJZw5Bz3CnFZqAJWYZIvjhdSBPmIlOvIpo79qTW
VbVRac6A9ospTlZDOtkaxPUdS/N/dug6Z+gQzGMin39UKB6dpTNyplSwmHrKGqSc33kualneB9U2
6mtu+wEAAP//AwBQSwMEFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAABwcHQvc2xpZGVMYXlvdXRz
L19yZWxzL3NsaWRlTGF5b3V0OS54bWwucmVsc4SPwQrCMBBE74L/EPZu0noQkaZeRPDgRfQDlmTb
BtskZKPo35tjBcHj7DBvdpr9axrFkxK74DXUsgJB3gTrfK/hdj2utiA4o7c4Bk8a3sSwb5eL5kIj
5hLiwUUWheJZw5Bz3CnFZqAJWYZIvjhdSBPmIlOvIpo79qTWVbVRac6A9ospTlZDOtkaxPUdS/N/
dug6Z+gQzGMin39UKB6dpTNyplSwmHrKGqSc33kualneB9U26mtu+wEAAP//AwBQSwMEFAAGAAgA
AAAhANXRkvG+AAAANwEAACwAAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0OC54
bWwucmVsc4SPwQrCMBBE74L/EPZu0noQkaZeRPDgRfQDlmTbBtskZKPo35tjBcHj7DBvdpr9axrF
kxK74DXUsgJB3gTrfK/hdj2utiA4o7c4Bk8a3sSwb5eL5kIj5hLiwUUWheJZw5Bz3CnFZqAJWYZI
vjhdSBPmIlOvIpo79qTWVbVRac6A9ospTlZDOtkaxPUdS/N/dug6Z+gQzGMin39UKB6dpTNyplSw
mHrKGqSc33kualneB9U26mtu+wEAAP//AwBQSwMEFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAABw
cHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0NS54bWwucmVsc4SPwQrCMBBE74L/EPZu
0noQkaZeRPDgRfQDlmTbBtskZKPo35tjBcHj7DBvdpr9axrFkxK74DXUsgJB3gTrfK/hdj2utiA4
o7c4Bk8a3sSwb5eL5kIj5hLiwUUWheJZw5Bz3CnFZqAJWYZIvjhdSBPmIlOvIpo79qTWVbVRac6A
9ospTlZDOtkaxPUdS/N/dug6Z+gQzGMin39UKB6dpTNyplSwmHrKGqSc33kualneB9U26mtu+wEA
AP//AwBQSwMEFAAGAAgAAAAhALLD2N/oCAAAlzoAACEAAABwcHQvc2xpZGVNYXN0ZXJzL3NsaWRl
TWFzdGVyMS54bWzsW9tu28gZvi/QdyDYy4XW4kmUhMgLn7QbwEmNtRe9HpEjkzVPHY4ce4sCeYd9
g32Ltnd9lDxJv3+GpEgdHDlx2sQWEFjD4c85fP/pm5/Mqx/u0sS45aKM82xiWt/3TYNnQR7G2fXE
/OVq2huaRilZFrIkz/jEvOel+cPhH//wqhiXSfiGlZILA2Nk5ZhNzEjKYnxwUAYRT1n5fV7wDPfm
uUiZxKW4PggFe4ex0+TA7vcHBymLM7N6XuzyfD6fxwE/zYNFyjOpBxE8YRLrL6O4KOvRil1GKwQv
MYx6urOkQ+wvuExC+p1d678/87kRh3dAqd+3zMNXbKz2yU8SYdyyZGLOri3z4PDVAT0C4apFD5fF
leCcWtntj6K4LC4EXQRvby8ExsSQppGxFPjSAOpGJaYuM4jpgTuPX9cjsfHdXKS0IsBjYIXQ4j39
xUNszO+kEejOYNkbRH/eIBtEZxukD+oJsLVmUtqV3tGG7fTtQb2jq1gm3LhIWMCjPAlhLgoltUn9
JIAszvPgpjSyHNsmNPRugU89NkFAsxWRIe8LACVp2EpO38Tiska+BMTG7N2bPIQsW8hcKWwFJtfz
YYUKK9t3B86wC9jQtkcDuk+wWZbr9HFBK6vhYONClPJHnqcGNSam4IFUE7Hb81Jq0VqEVJHl0zhJ
lFaSzHg3MUee7akHWnfSmHwqidOJOcSMek42jjgLz7JQPSxZnOg21pJkytJox4SQvDvOw3uabYZf
oADvxtKiXPxqGu8EA77l3xZMcNNIXmcl1mC5LjYp1YWCxDRE+86sfSdbpCc5jB0Wy7IAo07MQIr6
4kTimhDL04LJ8+yyCEiUVkM4XN39hYmiAkvCMN/mlxEr+CbMtKxCW2+EBklKeSnvE65QgPlhWOww
ucWCKmsHBmwsqJNRCONZ75dLhLBUniScIcRVYvLwJImDG0PmBg9jaVSRTFkVAh6mIDVLNT2GRBuz
wcJqdNHU5v+gE/iNE5ATtn3AJkP6XB8gXMwqJj2dK1iweXILhXEdPDq+4MJqRwNn7wvrviCfjSeQ
5pUjlBs8QblDy/lUxIbf7ep8lzzIs9BI+C1Pdhheecsjhr+KYrH76MqQHzH6NF8IGe28eFd70s7Y
TOP5A6M/Lga5dQA6ZbKbhNWmPzcAhTD38lckF5bMq0CkVIVFbsnJZCDbs/DA8fBvJfTYluM0adgZ
eBZSJmLTp2ZhFbl3SJWfkhyFTFRyRAZsJ0cVSevURQggYVmUuFhyjZSUmNQX8vnP6CI4LQq/1Ffm
SRwSZVAXxKqXbFPe6bwq40xq/ul7S4LSUFMFVGscwKZnUjeqheh2lVtprjq1LhemEVccg43nSaho
69+PHW9qDfxR7/R0etZzj/p+b+Tbo96ZbfcHp+7oaDiw/wFuoShbCBuUccr1unfJ0ZZ1YDkg+Za1
DBKYm1bFs/CCCUaQdTJ9GAtZs9xPydpe7THTPCce1k7aypM/12fmxJZIy0TCMEPlNzqbPsZvHMt2
a/q62XGGI+9ZOw4Rz6WFfhuus8VuK/eCIz6KYzanrEsECm68XaSzFZtVsfJzbRZHfQy9yWyVSzwq
3A88z3nYbJ97vP/2jLaJ90PbdX3P83qnnjvouWeO0xu5R17v2Ds7stz+9Oxk5DfxviSbxHlR+ehq
uFc5sUonOiF1Mow8/PD+n3/68P5fTxr4Ve7XpRg06wJPkIg3rDBQvkEuljjYIrVOzPAGrdm1TX02
9aEV3qDFggA1I0hUjboH93VPI+PUPU4t49Y9IGZa2Kt7kHh0z6DugXNHSZzdgF/Rj2nM8+Qn3VG3
iAipStw5u88X8nWIssNKj0rUtuX67tDx+1iJGFPFSbwOqzoMnLt+uiuLNTay1Xl1qyxW38hW1HKr
LPbVyFYpdassTtCNbBXKtsqiVNnIDtaQ6e5t1JL1H5a1wOaacVWJqIN4Z1wLNtPIjj4yLuykkcUk
q6rsDtxRXF0ga0FRKT6aG1GoazAgGqoWE6L6U40u71T1pFR1IiqgqUtKoV1Gqio6ILPqec7Os2MB
KwQO8zyTR4q0zliJClKEIgvKuReLLFCz0FBlERxT9VO1LoKKnKoVgJB17h7NYa1b5aq7LWKMQhUW
ccMF1ap3Jck6rrQoMHaLim+mWOkcZcmJ+V36114iSQMglmzlBmf6RlCu3AhKurGFUCtI7SXJ/6oh
VUr4yFljBxhPWBLPRGwaRSyDaMrSOAEVdxBHgoiJkteGuAYZ4URrgBU6e8h2goxwqiBz95DtBBnh
VEHm7SHbCTLCqYJsQJClTJxPzPq9iS5fdCLbSoKgZzsR/wvkAzXH/zF4ETAVRv4SI/VWhepAKlu+
dIwImAqj4RIjy/HpZcMeJCREpD5CpgJp1AJpaA/xHnAPkgaJkNFVkhZ/xRt3vApbI7M6WjmuPSL8
4gynUVCQXt1RV1+Np2W64KWYrqJLbS68E9udLabg2C2meSRilqwyKLzcXZyAUyliNTE/vP9dc9QW
V9ZFli/BlbNtXDnrbeHKWW9Hrqw15kNjeAuw1Jg99FDcrl0AaDwDjf22pjFbuflXrrFVqq41Vn8d
0VKZPWyF9uehsnUns7/YgfQJnWz1qFCpDOpRddgmLtrPUGUbvIyi8xepITyhylaPKlpldt/zlcE9
Y5X959/rcfFb0Njmk5LtWa4Kg9s1hpR9xWaXeCFYHxnWkhuKiqpitazDdetu1deIba7RnLM2s5Ft
LOMjhZsdaAfN99W71+Yjmz3yLZWC98p66KODHQqB36VPGAs3nx01ie+QxNX0tfcs/Z4AJZh2eWS9
+P2Eytp8hnWG+A6kcwZb4xp7Zf3vldWcpVun52Kcy4iL5iwNvVzosgRaq1/bNK8/KpH6LZKmK+0D
25Opt1qF+kzqWzgv0XdeVVFHvQ3S0HQrqDgdvVh8Np8nayrUlGheLD5bDm/dyulLNqDNRyWrWzV9
yQBtOZkotrQP0UhZW04DvqtLqPsYtIWBg9GpasQeoC2sd+D53Rroi81iDdNsk0v1qWv9QRJ9mlf/
h9LD/wIAAP//AwBQSwMEFAAGAAgAAAAhAPlczv+lBAAAlhEAACEAAABwcHQvc2xpZGVMYXlvdXRz
L3NsaWRlTGF5b3V0My54bWzMWNty2zYQfe9M/wHDPiviRRIpjqWMJVntg+N4IucDYBKyOAEvBWFV
aqcz+a32c/IlPQuQkuzIU9XJuH6xKWCxe/bsLnbJs7ebXLK1UHVWFiPHe+M6TBRJmWbF3cj5eDPv
RA6rNS9SLstCjJytqJ234x9/OKviWqaXfFveawYdRR3zkbPSuoq73TpZiZzXb8pKFNhblirnGj/V
XTdV/DfozmXXd91BN+dZ4TTn1Snny+UyS8SsTO5zUWirRAnJNfDXq6yqW23VKdoqJWqoMacfQtLb
Ct7WIvlF8NRhRlCtseQ5Y/ieLGTKCp5jYSESMs5IUCizW1c3SgiSK9Y/q2pRXStz6Gp9rViWkpLm
sNNtNhox87OAGB66j47ftZp4vFmqfHzGY7DBNiMHQdvSXxzisdholtjFZL+arN4fkU1WF0eku60B
INgZRbwr69HX7vitOzeZloJ5O6+sKMfRyzL5VLOihJ/kvnUvuVq3yshnUl+tmKVek6pGzm4aPlr5
2nDaAt0xEfp+4AWGjl7PHQzdR6SEYej3sMiIGi8Y+G7YN0ZaTTBiVVex3kzKdEuU3uI/IseLZFUi
SzWd4LGs9UJvJeKM57X0gIhxeYcyksgCHqdi+QFL9e8jByZh89YEPuFggEvZmG1OItwPNYJsHoMS
/IESyakeRdH5uEA95noqBYehxjs9nsos+cR0yUSaafaO11ooZihE9QIjadfGhlEpivSaK07wDjVT
VHgMy2Ch9d4QQpF5Ovzg25bCDeXeteSJWJUSxcB8chLV0sb5WZlA7DsoG+R0mzjPSgh/6A5CJIcJ
XlslDxOi77peFDaRsUV2SkLcWp3HEiLn6tIUaFakuGnokWJ6e3+F69QgOUgTXIl2uy5lls4zKUnW
3KZiKhVbc4ns29AVhHBmhbYrIWCbTEDwdsImlAd6sGctmY1d1pnU9Sl1LdJePwQK0H0CXC96QbiE
kdwG8mAPd+ihzE+FO3hBuISxgdvbw/WC0CMUp9FLnpkEeIFsIJAN3v4B3siPKMivDy+BbPAO9nh9
PwK9rxEvgWzwhgd4w15werm9ZD4QyAZvtMdLYE+vt5fESyAbvMMDvIN++DrrjUDam/hgijA9n9Dj
kts1d+PW82cAanRmBKgfzADP6fO9ts/PuBYP+rxpqt/a51ON0QbD0orLZdvvbVujQdjQRQ8Lw5wd
08x00U4q7ZxmuuqRXkzpYVsgJOD/rgfS85EoPJY3dnm8xORPM/wfs/5kNgyjqDN1Z2GnF0ZhZ3IR
9DvhMOhP/d50ch7N/nSacTYFZTrLhe3dp4TT87pegBccz9sHDrYJ1RPjG0szpduR/zkB7rcBnpcl
DZCHo1zve4xyS61sjH+95woW2jD/y1z3f4T5CY5t6vznEXnQMrvAYCfY1X1++4hf8xryrSWEV3Ko
PkqxGcUxzL7GSppfhHM/OPc68yCcd3qzwOtMJv55Z+7h+h4M3KDvB7tKqonBAl5SJTwuJFP7TaEe
1nqzpMdfPv/105fPf3/XkjKvCPaNH4/0acC89Ej1jlfv1+b+xtcQpDtmeCxV+P5BaQTRvQjpaL+n
jP8BAAD//wMAUEsDBBQABgAIAAAAIQB+QzBa1QAAAL8BAAAqAAAAcHB0L25vdGVzU2xpZGVzL19y
ZWxzL25vdGVzU2xpZGU0LnhtbC5yZWxzrJDBasMwDIbvg72D0X12UsoYo04vY9DDLqV9AGMriVki
G0sb69vPUAoJFHbZSfwS+vSh3f5nntQ3Fo6JLLS6AYXkU4g0WDif3p9eQLE4Cm5KhBYuyLDvHh92
R5yc1CUeY2ZVKcQWRpH8agz7EWfHOmWkOulTmZ3UWAaTnf90A5pN0zybsmRAt2KqQ7BQDmED6nTJ
9fLf7NT30eNb8l8zktw5YXiKASvQlQHFgtbXDl/LVldZMPc92v/0oCTIH44Fy8pm0WezCO3NzKze
3v0CAAD//wMAUEsDBBQABgAIAAAAIQBbrP4ZBQUAAP8SAAAhAAAAcHB0L3NsaWRlTGF5b3V0cy9z
bGlkZUxheW91dDgueG1szFjbctpGGL7vTN9hR70msOjAYQyZGpveOI6nkAdYpMWoWR0qLcSk05m8
Vvs4eZJ+u6vFQOQgbM+kN0JI3377n/9/dfH2IRFkw4syztKRQ990HMLTMIvi9H7kfJhPW32HlJKl
ERNZykfOlpfO2/HPP13kw1JEN2ybrSUBR1oO2chZSZkP2+0yXPGElW+ynKd4t8yKhEn8Le7bUcE+
gTsR7W6nE7QTFqdOtb5osj5bLuOQX2XhOuGpNCQFF0xC/nIV56Vly5uw5QUvQaNXH4oktzm0zRZ/
zB8comHFBg+oM4bm4UxEJGUJHkyyVIKBfIrlikxYruTQmDKfF5wrdLr5rchn+V2hl95u7goSR4qq
onDa1YsKpv+mgOGmfbT83jKx4cOySMYXbAiLkIeRA8dt1RWL2JA/SBKah+Hj03D1vgYbrq5r0G27
ASTYbQqf50ajb9XpWnXmsRSc0J1WBsqw9CYLP5YkzaCnUt+oF95uLJnSWdHnK2LMLxVVhTMvtT0s
vtQ2tYLuLOH5PcSWNke353b8I5u4nU7fpa5DlGUoDboVYl9jw5wP5cNlFm2VRRf4heNYGq4yBOrC
2FmUcia3Am5mQ7ERFAIRJu6RSQJBwIYRX/6OR+XnkQORINPCKr7Dw8e43+OBhdkQdsAFSwVTicjT
1ocZEjGRE8EZ6Cud5Hgi4vAjkRnhUSzJO1ZKXhBtN6QtJFPsUu+hKXka3bGCKaH2mZUr2BA7w75W
Z9wabz/tcxjxMAvuBAv5KhMRhOi+LALiCPFrg6S5812/5yuHqmSo875PKQXCeN/v+y5FKBj1TUJp
tU0cWktY7+vU2ndV5fIjT7sq+gzlHgC33Spe96Oiv4+1AGDdGqy3j7UAYL0arIq2nQwWAKx/CmsB
wAansBYAbO8U1gKA7Z/CWgCwg1NYA6jLIawkYNglywtzStVUnVLlQU6ZvNHJg4vdUgfuGWk842GW
RkTwDRcN6HVunUE/X8VFc3adEGewT7N1ge7XVHhPBeY59PGylh1t7lWrmWer2Vy5er+UaYOg7dtW
9axmpjoISjhawYqJpYMZAAVOO1I3NVVy9M1MR7wqvurR97ob9Vyfmjx/bPkH7c0LBrQTvLjAkYQV
N3rEiNMI0466VaIt1rcYCrU392oaPahTqicqLDJRlbeKyvboRnwH9fSoRlZ8A+qpXUkjvoPaeFRH
Kz7q9mjQlHDwnVpr+frdvir1jQQ84DuqxxVft9uHeM/hO6rZlq/n6bZ1vnxHdb3iU2SNHXKg71Ht
t3yB33ueP/4f/QGZbacJPWCoMffpucq3leiKSf76lSiS39QhaqYFddqoLUTI8UcNms9DuwnEVIEn
urQqD6Z+GHxVMZY4ZKmD0l8TdzD1aEBb7vTabXm077cGg+tBa/ArsmriXnd6l8HfTnVmiGAyGSdc
ndTQZI4G3boRmtI2dXGSpPSx82JvtfyJBkOiuJD2XPWcwTmwDp5mmRrY95uNbo8vbTZLWRgf/7lm
BXao2g09MVD/CDc/YeMqFM49kvSsZWcijji5XSeLI/v6avx4qX3x7QPUtSY+0dJ/hIl3mdTpTHr9
a/eyhROw3/KCaYBMooNW4F/5E7+PV126y6RSWTCFlnWJBDX0uKt+anJXjr9++eeXr1/+fdWU0qXT
fFbBrfoKoz0pincsf7/RYwY+OyHcJ/pRjg9NKowAfYQoDvvhavwfAAAA//8DAFBLAwQUAAYACAAA
ACEAKEP/ksYCAACkBwAAIQAAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQ3LnhtbMxVzW6b
QBC+V+o7IHomGAO1g2xHBode2sSqkweYwBJQll26u3btVpXyWu3j5Ek6u4DzU0eKqhxygWGYmd3v
+2Z2JyfbmlobImTF2dT2jga2RVjG84pdT+3Li9QZ25ZUwHKgnJGpvSPSPpm9fzdpIknzz7Dja2Vh
DSYjmNqlUk3kujIrSQ3yiDeE4b+CixoUfoprNxfwHWvX1B0OBh/dGipmd/niJfm8KKqMLHi2rglT
bRFBKCjcvyyrRvbVmpdUawSRWMZkP96S2jWI9ooCu7EtEyY26PDsGSLPVjS3GNToiE2EdsrmQhCi
Lbb5JJpVsxQm9myzFFaV69wux3a7H12Y+WQYhob7JP26rwTRthD1bAIRUmBtpzYqtdNPTIKIbJWV
tc7s3puV5wdis/L0QLTbL4A72C+qUbWI/oUz7OEsQBFrSSEjJac5EZa/B9hmAVb5zLMbaTGOkDUT
LdLsbNPX1fD1Sk1ptdTnChvvB4oItLCRPwTnGbCGIR1sjD5fIt2GR7WNeb7TnFzh2zgholKt1I6i
OmhvqGe0gSgnxdeW9QduJOJhOOKH6EB85yqwE7S4P5NhuliEcegEQTLAhx848yT1nTiM/WQ0Cr34
dPzL7sEhZaqqiW4niAQ2CLYRDhxhzuUKcdcqoQRwIDt51czzXM/Hdve8CW5QIXqIcG2dTli+BAGI
5HGVvBKq7wWMRiDIWE8Pmq20zwvs9wKnnCuU9aHEwWtIXCjRavxtDQJX6GXu26PtiTch8zMc6zb+
D2aDntkVrXJina3rqyf8hq/BLx7QWPogxcNuAt8QxftJGo+PgyD2544fj3CcxunCOQ79FMdplPhh
ks49b76fJKkZZIjy0CCZo/H52VWzu9vfH+5u/7zqSJnJaq8CNPVVYU57Kr5Ac77BcwsivBux3RPj
avA27E7D+xBdo79dZ38BAAD//wMAUEsDBBQABgAIAAAAIQANsnfzBQMAAPYIAAAhAAAAcHB0L3Ns
aWRlTGF5b3V0cy9zbGlkZUxheW91dDYueG1szFZLbtswEN0X6B0Ida3I9C+RYDtw5LibJjHq5ACM
SMVCKFIladduUSDXao+Tk3RIic6nDhAYXnRjU8OZx3lvZkQNTtclRyumdCHFMMBHrQAxkUlaiLth
cHM9DU8CpA0RlHAp2DDYMB2cjj5+GFSJ5vQL2cilQYAhdEKGwcKYKokinS1YSfSRrJiAvVyqkhh4
VHcRVeQ7YJc8arda/agkhQiaePWeeJnnRcYmMluWTJgaRDFODOSvF0WlPVr1HrRKMQ0wLvplSmZT
AVtTGM6uBN8EyLmqFRhxMAL22ZxTJEgJhmvrhZyb3dHVtWLMrsTqs6rm1Uy5gMvVTKGCWoAmMIia
jcbNPQpwg0X0KvzOI5FknatyNCAJaIHWwwBKtrG/EEQStjYoq43ZkzVbXO3wzRbnO7wjfwBksD3U
sqoZ/Uun7enUOuAtq9qVQOgXmd1rJCTwtPRretnlyoNZzha+WqBnwjd+9abTw/tr0NSJZdZnkm4s
8Vv4d0aScG3mZsOZEwTSJgmAww/Iz4ntaybCmzn0dWlSzgj0fSOeGaW8yO6RkYjRwqALog1TyHUB
TAFADkAdA8VpIJmgM6LI11fIlh9J4GRI2mcIy1rCt4XseCEnxDA04yRjC8kpZNA5hKbUAOUfMBaE
5wE0InQJdsSdtLYAe2hsheUrjl2Tk4SyHMSo+W/NoIUviXV3Fdnh35hymCs7JT/H4363N+33wk4L
j8NuOx2HZ+dxHLbTCT5rn7T66XTyK2gahoJkpiiZHc73lRrjCHfgBYLxU1HhbBv+RlkRLZTxQ7VP
gbu+wFMpbWM9L3H3ECXOjapr/G1JFJzgy+xHbu9ROnyZ39B4z9HpeWXnvKAMXS7L21f69g6hL1x5
AL1T4rbF/08naRIfp/gk7oS4i4/DbpziMIbhCvt4PI4nx60e7G4nSVsFBbDcNUjAEQbYviteznpj
MqPHh9+fHh/+HHSk3KuzvlNhaS9ed21ydUGqq5XLBb42oN1TZ6rg+6KuRfbkYjH898roLwAAAP//
AwBQSwMEFAAGAAgAAAAhAFDG5A+JBQAAdBwAACEAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5
b3V0NS54bWzsWd1y2kYUvu9M30GjXhNYSUjAGDK1sXuT2J5CHmCRFqNG0qrSgk06nclrtY+TJ+k5
+wPiR4mMPZPMlBsQ4tOn87Pn09mji7dPaWKtWFHGPBva5E3HtlgW8ijOHob2h+lNq2dbpaBZRBOe
saG9ZqX9dvTzTxf5oEyid3TNl8ICjqwc0KG9ECIftNtluGApLd/wnGXw35wXKRXws3hoRwV9BO40
aTudjt9OaZzZ+vqiyfV8Po9DNubhMmWZUCQFS6gA+8tFnJeGLW/ClhesBBp59a5JYp2Dt+KRT5+m
j/xu9odtSXCxgtPEHoH/4SSJrIymcOKKpzkt4pJn8p8ynxaMISZb/Vbkk/y+kBfcru4LK46QQF9o
t/UfGiZ/ZgCDg/be5Q+GiQ6e5kU6uqADiIb1NLQhaWv8hIvogD0JK1Qnw+3ZcHF3BBsuro+g2+YG
YMHmppDvXHl06I5j3JnGImEW2XiloBQufcfDj6WVcfAT3VfuhbcrQ4Y+I32+sHTokUrj1J8yHgZf
QkxlsMTTJY/W6PgMvuVJOkhKMRHrBFIAx6uEyATQQcTmv6vQVk6Dt1U4OEkHYAp8QLISinXAstaH
CdRBKq4SRqFOdKjF6CqJw4+W4BaLYmG9p6VghSVkFEo04ALYBaRSU7IsuqcFBSN2mDEadAB3BheN
P3CoAl4fdncTdsz5fUJDtuBJBBY4r5EBjKcNyxXWkklYTSIwWntL0usGUOByXZKu2yXERZO2q9Pr
eB3SA3HBNeq7/cCXNkMYFJF0Xy0JExGTYYtm4YKDWswUZTV7OtlWSot3si7iLIICx0O8+2x5Cyom
DVFrwSo/DW3HQ0tnxs3K2pCHDqweTWi8asTaOWRFKrQDzHS3rH3iSQuasJLeIStSaVZvy0rcgPgI
bkQrkbshQC5N263Q9pyetOFUWuTStP6W1nF6YMILrEUuTRtUaAPPlevwVGuRS9P2trTI2TxlR2KL
XJq2X6H1u8GLUoZcUkuqNSEVDW8Cq24jXfLupyscCo4UuHJH4U5RMc+o2BXPBNTqjpBJ1YBHrXlQ
PPNRgtW9oMlcy5iSGHysyjDhQfV5ggmplzGHBF4v6H5Fxtx+l0BxIKKJjkkZqibq4Em1VSdFWQHA
oRGTqpJhCW2wBgBYIxEVrFSSDdYAAGvqvorFVbnBGgBgTTHXYg0AsKZCa7EGAFhTdrVYAwCsqaVa
rAEAVhWI6QRkfKVIbnz7MSpINgPwYYpWPn+f0ZZMWMizyErYiiVHCnSfXtbFM+ini7hozq6f/I0V
54YvC7FobLynKrI5fTw/yg69yat2Z12ja9P97kxafLqoqf5YdWcocH8uaQFtp9Y4GW3ZKjfWON/r
dhwwFzqxul6NBKB8515taJ97NeiXz73a0Hb/j72abzTtWK8mW6PTZe1QyqROnixldf3aVsrO/RrG
fLf/OfdrNTOdr+549huqc7+GIzS1G9yPzY/arwVG28ZUsNfchKp+LRIwQNzdjhK1p6rdj8KmZDsP
NNMvOLk7sIRdzbPnm3JMYHZBau+jT81hpo0T6r86JBgHXtBrXXb7pOWRntv61fX81iUhl17/uu87
QedvWw9rIwiZiFOGg/Fmg1NC2sSF8T0h2/0J3Bsvr2nDrSguhBlonzJogGGjmtbfcI5j2urA9FVa
8rmAJvzwMUa+MT39HmmuibFeCs8dRPdNZCdJHDHrdpnO9uL7wt5AlRC8cALqoyH+xmTne4R4U0lj
v+t1YA7ZgunRTctz/aDVG7tB69J3nesbMr7u+N6mkkqMYAZeHiskcEMOBfBLTTt0wtQwUYy+fP7n
ly+f/33VkpKTePU+Cw7xpZd8ZZUU72l+t5LbbnjXBwV1JU/l8HYPrQLoFoIc5m3h6D8AAAD//wMA
UEsDBBQABgAIAAAAIQD2xDV2QAQAAKUSAAAhAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91
dDQueG1s7Fjdcto4FL7fmb6Dxr12jY3NjyfQCTjsTZtkCn0AxRbBrWy5kiDQnZ3pa+0+Tp+kR5JF
CDULbDrTm9wkQv50pPOdX+ni7bqgaEW4yFk5cPw3LQeRMmVZXt4PnI+zidtzkJC4zDBlJRk4GyKc
t8NXf1xUsaDZO7xhS4lARiliPHAWUlax54l0QQos3rCKlPBtzniBJfzk917G8QPILqgXtFodr8B5
6dTr+Snr2XyepyRh6bIgpTRCOKFYwvnFIq+ElVadIq3iRIAYvfrpkeSmAm3lA7u5++QgjeMrmPGd
IaieTmmGSlzAxOyBoTErJYjRn0Q144QoULn6k1fT6pbrFderW47yTEmoVzpe/aGG6Z8lwGDg7S2/
t5JwvJ7zYniBY2ACrQcOGGyj/sIiHJO1RKmZTB9n08VNAzZdXDWgPbsBnGC7Kdi6Mhr9rE5g1Znl
khLkb7UyUAxL37H0s0AlAz2V+ka99HplhSmdlfhqgWralagaZz5qPixeAKeaLLkesWyjFL+D/3oS
x1TIqdxQogmBY+MYhMMfoJ9i5dWkdD9OwasLOaYEg9fX5MnhmObpZyQZIlku0XssJOFIar2EEnkB
7EgwTi2SlNkt5vjDnmSlH45hZzi0PSEMDYWHiWxbImtvQrcUp2TBaAaHCJ5Hq/gK0YDp3AEPBPew
NjjAraJrz8vCqAvxql3N77Raaqz5tQ4Xtto9mHeQcrswCqJ+p60NaCVpAoyZLSeNVlN70xX1ddjg
OCNzRa86f9AzmwK3OwAYBg3YcBdrAYBtN2Bbu1gLAGz4M9Z/cgYLAGx0DGsBgO0cw1oAYLvHsBYA
2N4xrAUAtn8MawCK6zqclGF0NMFKBBK2YfPM6FIepINLPIkuE0H7W2rHPSOgpyRlZYYoWRF6gngd
ZWeIny1yfrp0HRBnSJ+wJZeLkw8fmog82RyTfN4oHarIL81r4X/lNc0J1FNbDM4sF3t5TdtPlwqV
afRgt2Y05bVO2HtJbFARXhJb/JLYto3QS2I7oWGLbGJLsCRPurVnZjXTBGcSetS9vk0b6HCCO94U
N7ZXpmGFmm66rgNFXy017Vjd4Koci+M53ITUteavaOwnnWjUcyM/6rphpz9yR5MgcpN+t93qJ2Gv
7wd/O3WHnwFlMi+Iuk5BSdzroJt6c9/3/Dbc93z/sZDD3mr5gXqFspxLewsy/QRQZ7vPEwzcsQae
MKZuArsNua62/79wGRPPJTc2/rLEHHaw7fmR/vx3mPkAx7UrnHvX6VpmpzTPCLpeFnd7/EbPu/AY
fuGFAkQ3UnykVfgdFG8jKekmSf8yCd2rsNt3w6tR4F4GSdsN/XDS6ybB1eQy2UaSUAyWoGVTIIEa
0EKbQG2IXTn8/u2f19+//ftLQ0pHlnkEgaF6KtHvHJS/x9XNSicNeBwCdx/rqQqeg5QbAfQRomTY
56XhDwAAAP//AwBQSwMEFAAGAAgAAAAhAF1Cxl2RAwAACgwAACIAAABwcHQvc2xpZGVMYXlvdXRz
L3NsaWRlTGF5b3V0MTAueG1szFbBcts2EL1npv+AYc8MRYl0FY6ljGRZvcSOJ1J6R0jQ5AQkWABi
pHQ6k99qPidfkgeQsCtXnpFlH3qhKHD3Yfft7gPO324rTlomVSnqiRe+HniE1anIyvp24n1cL/2x
R5SmdUa5qNnE2zHlvZ3+8uq8SRTP3tGd2GgCjFoldOIVWjdJEKi0YBVVr0XDanzLhayoxl95G2SS
fgF2xYPhYHAWVLSsvd5fHuMv8rxM2UKkm4rVugORjFON+FVRNsqhNcegNZIpwFjv/ZD0rkG2IEav
tx6xdrLFSuhNkXq64hmpaYWFdak5IyCI/AHjMqWcrNlWWzPVrCVjxqFuf5fNqrmR1vu6vZGkzAxa
j+IF/YfezP6tYYaX4IH7rUOiyTaX1fScJmCFbCceirczTzjRBEGQtFtM71fT4v0B27S4PGAduA0Q
wd2mqHvTZfTfdIYunY6U8C6rzpTC9Z1IPytSC+Rp0u/SS69bB2ZyNvBNQboSaMNvb9d9tHw4ewVO
LVl6OxfZziT+Cb92kSZc6ZXecWYJQdg0ATgeoJ9T0+Gs9j+u0OGVvuCMYgJ68vT0gpfpZ6IFYVmp
yRVVmklig8E8APIc7GgUp4dkdXZDJf3wANnkRxPsjKBdhHjtKHycyJEjcq+nyA2nKSsEzxDK8CXI
NVR5RMgSQ9B1u4e+RNO4yjyFcSMjQGHUBG2iO8Q/ykV4y++IfmY9TJPbcqi9enScW+LxcFvapJ7Q
AiuWCsw1Zy3jR8DbijwBfl2U8nj0Ucfo0XwtxUbq4ujgo6fCl/lBdOjOi05C5CZhQTXbGwBLCKTY
acdJ6pJpDP9XHBWU5671rQRYkTFSdILa2M5veWjlniYZyyELnRKg9btldKgTJ2NutemAfb+U47gx
58Vfs/AyjMfRpT+6XM796LfxyB/P3sz9ZTwcRotRPB+Hi7+9XjozUKbLipkz6zjRC8MgHOFQDcP7
fsfexv2RspKslNodL6dIXewKvBTCSOy/Nc425XNLnGvZ1fjPDZXYwZX5FInbE7WXL/MjHJ94iJw5
Zle8zBi53lSfHvAbm6F/Lr+4BgL6IMVWEf+nkzSMZrN4MYr85SJa+lE4vPDHZ6OBP4gHiziex7NB
dHY3ScowWCPLQ4Nkm+Lx2dXTH9/++fXHt+8vOlL2EtHdLvFq7qO2klxe0eZ9a08J3MDR7hd2qcGd
27QRTO9NDIa7w09/AgAA//8DAFBLAwQUAAYACAAAACEAo15jz+YEAAC8EgAAIQAAAHBwdC9zbGlk
ZUxheW91dHMvc2xpZGVMYXlvdXQ5LnhtbMRY3W7bNhS+H7B3ILRr16YkS7IQu4iVeDdpatTpAzAS
HQulfkbRrr1hQF9re5w+yc6hRNtKndZTDPQmkanDj+f3O4e6ervNBNlwWaVFPrbom4FFeB4XSZo/
ja2PD7NeYJFKsTxhosj52Nrxyno7+fWXqzKsRHLHdsVaEcDIq5CNrZVSZdjvV/GKZ6x6U5Q8h3fL
QmZMwU/51E8k+wzYmejbg4HXz1iaW81+ec7+YrlMY35TxOuM56oGkVwwBfpXq7SsDFp5DlopeQUw
endbJbUrwdoyjR+2FtFicgML1JqA5fFCJCRnGSzM01itJSefU7UiEStRDy1TlQ+Sc5TON7/LclHO
pd56v5lLkiYI1UBY/eZFI6Z/5iAGD/1n258MEgu3S5lNrlgIHiHbsQWB2+Ff2MRCvlUkrhfjw2q8
en9CNl7dnpDumwNAg/2hEPOytuhbc2xjzkOqBCd0b1UtymDrXRF/qkhegJ1ofm1efL8xYGgzwpcr
UrtfIVQjV7/U/jDylfapUXTvCeqPbDuAvAXL3QCybPDMK0M38FxYJOiboef5TqAPMUhwSA1dhmo7
LZIduvQR/kPkWB6vCsjUR9zBQlGphdoJiDM8bwQFjQgTT1BKArKAhQlffoCl6s+xBfkORz4ay/fy
EOQ2DriYheAI+ANbBcNK5Hnv4wIqMVOR4AzgG5PUJBJp/ImogvAkVeQdqxSXRDsO6hY0Q3Slz9CQ
PE/mTDJU6hgZY8FCOBlsNzZrN2A8Xg66Y4JuymAuWMxXhUhACRtdBMViAtwpBaACLSgXyGWTMN0S
waO27w/roJnqaOWBSykmy9mJIJWICoGBwEjlQHHXa1UsU1W7sk4XfHUqRTIm73TJpnkC/GNQHtf3
QLI6sY4Sx4HMadRqUkzDboSN2VZDuUMfpcg5ePbBTMBDkAbPOeCNqKsr5Cw8lKytBjwEafDcAx51
fIp1eJ6CWCl7QERpAIdHgAGUeDdARGkAvQMgUAYo2ElDRGkA/SNA39WR62AyojSAwQEQ0c4PSsuH
iNIAjo4AvaHfMSiIcpq4EB7SYM9QLxAOtIG5LIqlroJntNaFiVzDRA9Y3cc05GAqvZaGsJyBfoHG
V0wsG0bSBKc7knYGtuqF9ovpH6ahnGxNQwcaT915Dg27RUnBABpVfYhB+k5r0rTxarKhrWLGftbk
TUeyoS3yej3Z0FZeX4BsRhfmmhbeBaimhXcBpmnhXYBoWngX4JkW3vk0o9O0+7yEpKHHpao1L3Vh
oqFhohum+OWZKFHf8BCtuyXyz0ki0vxnpjozyb5EF1ju9fABEmD/fuTA56NpV0+pDT0cyzdLS7gh
4S3nr2hwM72ezbxeBN2r5/p02gsG3giebkbOwJ3S64H3t9UM/Am4TKUZx2vWeeMvpX3qwDWQ0kPg
4Gzc/lLnSVKpzKWoS4A9E+BZUeCwfdxs3Es0m6WSdYz/WDMJJ5gB+AcT8M8I8ws+rlPnf18nfOPZ
hUgTTu7X2eMz/+oJ/rXNHD5cAPRJF/+gpf8MF+8ryY9uZ67n2j3HieyeO4SamrqO15tNh8FtQKNZ
YEf7SqrQgzlYeaqQwAy47NWt/UTtqsnXL//89vXLvxctKT261N9E4BE/oeixTMh3rHy/0fwN34wg
3SO9VMJXIkwjED2IIIb56jT5DwAA//8DAFBLAwQUAAYACAAAACEAv8I+K28CAAD0BQAAHwAAAHBw
dC9ub3Rlc1NsaWRlcy9ub3Rlc1NsaWRlNC54bWyslNtuGjEQhu8r9R0s35MNB0GyyhIRDlWklqCQ
PIDjnWVX9am2odCo796xl01oDk1a9Qa89pz+b8Y+O99KQTZgXaVVRttHx5SA4jqv1Cqjtzez1gkl
zjOVM6EVZHQHjp4PP344M6nSHhxBf+VSltHSe5MmieMlSOaOtAGFZ4W2knn8tKskt+w7xpUi6Rwf
9xPJKkX3/vY9/rooKg4TzdcSlK+DWBDMY+2urIxropn3RDMWHIaJ3r+VNERtfCny8O/MjQUIK7X5
ZM3SLGw8nm8WllQ5EqNEMYlgaLI/2JvFT4VmuEieuK+aSCzdFlYOz1iK2sg2o4h/F37RiaWw9YTX
m/xxl5dXL9jycvqCddIkwAoekgZVtaLncjqNnKWociCXkq2ALATjUGqRgyXtB521M8NgnzX/6ojS
qLwGoq+136/GJVMrGDkDPG7VNPh80+QOiEI1piR+ZxCkE/mlXIU0EVs4jYvGwWEP6sNaxutiuo2Y
eZzUQxmdt2W8XemdzncUpwBbFLH8sV6T+u0FOoTGBsegi+EdsnK09rqofMh3eCScX/qdANxnKTYM
50HlC2bZNY6eQKoZBdW6XUZS0QLzNzlw+RadXkOnbvV8Le+wv4eQuv8DErYTQ+Mj8iOj39bMerAN
szjmfwkt0niOJt5LluZQIJ2a5H6rEHm8qPedQX9y2muftAbj/kWrNx2fti5m/V6rczqajGfd3nQ0
GPykD0OI46+w7sDdPgFOnPRjAQwfzP1NfT29H/ZCW31sLtbyb32M7axfIlw2jxMX9gszV5s4Sfjm
Itpx3DL4ygYIaPpoEkCHezD8BQAA//8DAFBLAwQUAAYACAAAACEAXSlsJSgDAABGCAAAHwAAAHBw
dC9ub3Rlc1NsaWRlcy9ub3Rlc1NsaWRlMy54bWy8Vk1PGzEQvVfqf7B8D/kghHTFBoWQVEghRCSo
54nXya7w2q7thKRV/3vH3t1AKWooReUAY3vmeeb5zSxn59tckA03NlMyps2jBiVcMpVkchXTu/mo
1qXEOpAJCCV5THfc0vPexw9nOpLKcUswXtoIYpo6p6N63bKU52CPlOYSz5bK5OBwaVb1xMAD4uai
3mo0OvUcMknLePOaeLVcZoxfKrbOuXQFiOECHOZu00zbCk2/Bk0bbhEmRP+SUg9rYzOR+L9Wzw3n
3pKbz0bP9NSE48lmakiWIGOUSMiRGFovD0q3sJTohkb9WfiqQoJouzR57wwirI1sY4r07/xvDIKI
bx1hxSZ73GXpzQu+LB2+4F2vLsAM9pf6qoqKfi+n1TxpdKqSZiJLOLnKYcXJVADjqRIJN6S5r7UA
AAQcK3ZviVRYfUGKulWutAYpyBXvW81ZtTXH2oZJFpYFQWyyqdLxrPkEdUrcTiO3ViRX+crfGpj0
p8GoAiw+C1k8XKsEnWHtFPX0STXKhAhMCuk3rMKC/F5YmNViIAzZgEDCw0+44JlbnjmsWGR5TLt7
J4hSDslQJgHcQSYKG+n2N2FuPqPS8JX8mfDTivBJ6KinVLcOU32YvoVKdhTVilIKT/cmEvdF6cht
LxDRk+iRkfoHA/jq9usaDMda1vlAIanYGiBZqrC3XWUOHK5Q5EzlGtxYzjTzjh5LG+vm2y9gNPEm
BqFGJmqWgubBATZj63y1T33DskjDgwjrZm4neHgYVDm6Yn4cxvLC3IeUvBZxCE3XshCj97GaXfBl
aU2ZK0VR6aE89ff6V8XGlMkUDNwitEC4mHJZu5vhoMzdQHDAQRo62AcEEVSEBQ4P6wFHbjFTigac
rPMFavCpLI7fQxbYVQiNWX+LqX86FHqpkpNQuR9ab221f2qbv1fY/5fVUiRh/n8/6bQanVGzXbvs
d4e1dqd7Wuu2+u1aYzRoNtv9T612o/uD7gcZTlTsj6Bnc0A+QW7FhOkde9W7IHa8+R00GKRYfNvQ
rD53TJhr0DeboHL8iqMkcEbilsaWKQfNowsGhv8Bej8BAAD//wMAUEsDBBQABgAIAAAAIQBYmrHO
JgMAAEYIAAAfAAAAcHB0L25vdGVzU2xpZGVzL25vdGVzU2xpZGUyLnhtbLxWUU/bMBB+n7T/YPm9
pC0tKxEpgrZMSFAqWrTnq+M2EY7t2W5pN+2/7+wkhTG0MobGA5ztu893n7+7cHK6KQRZc2NzJRPa
OmhSwiVTaS6XCb2bXTR6lFgHMgWhJE/ollt62v/44UTHUjluCcZLG0NCM+d0HEWWZbwAe6A0l3i2
UKYAh0uzjFIDD4hbiKjdbB5FBeSSVvHmNfFqscgZHyq2Krh0JYjhAhzmbrNc2xpNvwZNG24RJkT/
klIfa2NTkfq/Vs8M596S689GT/XEhOPxemJIniJjlEgokBgaVQeVW1hKdEMjeha+rJEg3ixM0T+B
GGsjm4Qi/Vv/G4Mg5htHWLnJHndZdvOCL8tGL3hH9QWYwe5SX1VZ0e/ltJudXrsuaSrylJPLApac
TAQwnimRckNau1pLAEDAK8XuLZEKqy9JUbfKVdYgA7nkZ1ZzVm/NsLZRmodlSRAbr+t0PGs+QZ0R
t9XIrRXpZbH0twYm/Wkw6gCLz0LmD9cqRWdYOUU9fVJd5EIEJoX0G1ZhQX4vLMxyPhCGrEEg4eEn
XPDMrcgdVizyIqG9nRPEGYd0JNMA7iAXpY10+5swN59RZfhK/kz4YU34OHTUU6rb+6neT99cpVuK
akUphad7E4m7onTsNueI6En0yEj9gwF8dft1BYZjLatioJBUbA2QLFPY2642Bw5XKHKmCg3uSk41
844eSxvrZpsvYDTxJgahRsZqmoHmwQHWV9b5ap/6hmWZhgcR1k3dVvDwMKhydMX8OFzJc3MfUvJa
xCE0WclSjN7HanbOF5U1Ya4SRa2H6tTf618VG1OmEzBwi9AC4RLKZeNuioOycAPBAQdp6GAfEERQ
ExY43K+HTq2HsgHHq2KOGnwqi8P3kAV2FUJj1t8S6p8OhV6ppBsq90Prra32T23z9wr7/7JaiDTM
/+9H7bN299Nw2PjUHHYanVb3rHE8Omo1OsfdUa8z7HZHF4MfdDfIcKJifwQ9mz3yCXIrJ0y/7VXv
gtjx5nfQYJBi+W1Ds/7cMWGuQd+sg8rxK46SwBmJWxpbpho0jy4YGP4H6P8EAAD//wMAUEsDBBQA
BgAIAAAAIQC4TY5gJQMAAEYIAAAfAAAAcHB0L25vdGVzU2xpZGVzL25vdGVzU2xpZGUxLnhtbLxW
wU4bMRC9V+o/rHwPIQlBEJEgEkiFBCEioJ4Hr5Nd4bVd2wlJq/57n727gSJUKEXlAGN7Zjzv+c0s
R8frQiYrYV2uVZ+1dnZZIhTXaa4WfXZ7M24csMR5UilJrUSfbYRjx4PPn45MT2kvXIJ45XrUZ5n3
ptdsOp6JgtyONkLhbK5tQR5Lu2imlh6Qt5DN9u7ufrOgXLEq3r4lXs/nORenmi8LoXyZxApJHrW7
LDeuzmbeks1Y4ZAmRv9W0gDY+Eym4a8zN1aIYKnVF2tmZmrj8WQ1tUmegjGWKCpADGtWB5VbXCq4
wWg+C1/Umai3ntticEQ9YEvWfQb6N+E3gqgn1j7h5SZ/3OXZ1Qu+PDt7wbtZX4AKtpcGVCWiF+Ds
dTp48RLSTOapSM4LWohkKomLTMtU2KS1xVomICS80PzeJUoDfUmKvta+skYZqYU4cUbweusG2M7S
PC5LgvhkVZcTWAsFmizxGwNunUzPi0W4NTIZTqNRBzg8S3L3cKlTONPSaxboU3qcSxmZlCpsOA1A
YS8u7OJuJG2yIgnC40+84JlbkXsglnnRZwdbJ+plgtIzlcbknnJZ2qA73ITaQkWVEZD8mfDDmvBJ
7KinVLdfp/p1+u50umFQK6QUn+5dJG5BmZ5fD5ExkBgyg/oHS3h1921JVgDLshhpkIrWIMUzjd72
tTnyWEHkXBeG/IWaGR4cQy5jnb9ZfyVrkmAiCBqZ6FlGRkQHWl04H9A+9Y3LsoyQRDo/8xsp4sNA
5XBFfYIu1NDex5KCFjGEpktVijH4OMOHYl5ZU+4rUdR6qE7DveFV0ZgqnZKla6SWSNdnQjVuZxiU
hR9JQRiksYNDQBRBTVjk8FU97IGfpw04WRZ30OBTWXQ+QhboKqRG1d/7LDwdhF6ppBuRh6H13lb7
p7b5e4X9f1nNZRrn/4/9dqs13G/vN9rjk25j7+Bs3Dg8bI0bo0633Tnsdrunw9OfbDvIMFHRH1HP
9hX5RLmVE2bQCqr3Uey4+QM0GKVYfttg1p87Lu0lmatVVDm+4pAEZiS2DFqmGjSPLgiM/wMMfgEA
AP//AwBQSwMEFAAGAAgAAAAhAGr8OIPVAwAA6gwAACIAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRl
TGF5b3V0MTEueG1szFfLjtMwFN0j8Q9WWIc0adJHNC2iLzYwjGhhbxJnEuHYwXZLC0Lit+Bz+BKu
7bgzUzqiw4Bgk6bJ9bHvOfceO2dPtjVFGyJkxdnICx93PERYxvOKXY6816uFP/CQVJjlmHJGRt6O
SO/J+OGDsyaVNH+Od3ytEGAwmeKRVyrVpEEgs5LUWD7mDWHwruCixgr+issgF/gDYNc0iDqdXlDj
innteHHKeF4UVUZmPFvXhCkLIgjFCtYvy6qRDq05Ba0RRAKMGX1zSWrXQLZAjFpVipKnLF9tPWTi
xQbehN4YKMiWNEcM1/DgDYRWGabIxCNgDK3IVpkw2awEIXoA2zwTzbK5EGb0+eZCoCrXaC2KF7Qv
2jDzl0EY3AQHwy8dEk63hajHZzgFdtB25IGIO32FQTiFRaDMPsyunmblyyOxWTk/Eh24CWAF+0lB
/8Zm9HM6kUvngJRwn54dgwHjOc/eScQ4JKx5sHlm5xuHqpPX8zQlspoorYeHuKhAOStRO8qGGprc
aGmoduvfE9TrRcO4Y2mK+nGvO7jJVdRJ+ua9ZiwZJGESJWYShwSTWOgmVdsJz3ea6bfwC4Lqohl5
BOvkLSyVaql2lBg9gDWcQkpwgWCKdaMR5r9eQqPVakoJhkZstVPjKa2yd0hxRPJKoRdYKiKQoQDa
EiDPQBwFtdFCEpZfYIFfHSBrVnEKM8O63XpNCprZ23Xs/qyjrqYLijNScprDUiKdITSCE+y3JNXE
HSgKbQE16+rhdGXjpA/GYur/mLC9Tjgc6Pd/S1ioN0Q3dK/gPYXWdBud5Q2hrZhGUbi4KQ1bd6it
Jck42BQlG0JPgDdS3wF+VVbidPSubZWT+VrwtVDlyYuP7wpfFUfRwU//aIvFrsVmWJEbnWUIuW9n
5Qpc5SNshZgWXttTxluMS2pnNTfX7dL0szMJZ2rGuZyNae+CGg9bb81JAX5jLWb/GCr0ergxvSPx
7aMCtlG9D37qzKfxPO7P/aQ/mfjxIon8QXc493uD/mLWSYaLcBh99tqdIAfKVFUTvRef5qZhGIRd
ODSE4VW9w9x6+C2yorwSym2bv+OhiRN4wbn27uvmaYryvhIXSliN36+xgBmczL/wzn8h8y0c29K5
8+7Uc8wuaZUTdL6u3x7wa/bs+/ILx1yAPkqxccT/tJO608FwFvX6fjKbh348mc39SdxN/HAeR+Hk
aT9OJvG+k6RmkEGWxxrJ9P7tvavG3798ffT9y7c/2lLmdGJPzXCrz9nmmEHFC9y83JhdAr4woNyn
5lED3xS6jCD0KkRjuG+U8Q8AAAD//wMAUEsDBBQABgAIAAAAIQD5zwk5gwYAAFwbAAAUAAAAcHB0
L3RoZW1lL3RoZW1lMi54bWzsWU9v2zYUvw/YdyB0b2MndhoHdYrYsZutTRvEboceaYmWWFOiQNJJ
fRva44ABw7phlwG77TBsK9ACu3SfJluHrQP6FfZISrIYy0jSBtuwxYdEIn98/9/jI3X9xqOYoUMi
JOVJ26tfrXmIJD4PaBK2vXvD/pUND0mFkwAznpC2NyPSu7H1/nvX8aaKSEwQrE/kJm57kVLp5sqK
9GEYy6s8JQnMjbmIsYJXEa4EAh8B3ZitrNZq6ysxpomHEhwD2bvjMfUJGmqS3lZOvMfgNVFSD/hM
DDRp4qww2GBS1wg5k10m0CFmbQ/4BPxoSB4pDzEsFUy0vZr5eStb11fwZraIqSVrS+v65petyxYE
k1XDU4Sjgmm932hd2ynoGwBTi7her9ft1Qt6BoB9HzS1spRpNvob9U5OswSyj4u0u7VmreHiS/TX
FmRudTqdZiuTxRI1IPvYWMBv1NYb26sO3oAsvrmAb3S2u911B29AFr++gO9fa603XLwBRYwmkwW0
dmi/n1EvIGPOdivhGwDfqGXwOQqioYguzWLME7Us1mL8kIs+ADSQYUUTpGYpGWMforiLGR0Jqhng
TYJLM3bIlwtDmheSvqCpansfphgyYk7vzcvv37x8jt68fHb8+MXx45+Onzw5fvyjpeUs3MVJWF74
+tvP/vz6Y/TH829eP/2iGi/L+F9/+OSXnz+vBkIGzSV69eWz3148e/XVp79/97QCvi3wqAwf0phI
dIccoQMeg27GMK7kZCTOt2IYYVpesZ2EEidYc6mg31ORg74zwwxX4DrEteB9ARWkCnhz+tAReBCJ
qcpc7mh2K4od4B7nrMNFpRVuaV4lMw+nSVjNXEzLuAOMD6t4d3Hi+Lc3TaF00iqS3Yg4Yu4znCgc
koQopOf4hJAKez2g1LHrHvUFl3ys0AOKOphWmmRIR040zRft0hj8MqsSEPzt2GbvPupwVqX1Djl0
kZAVmFUIPyTMMeNNPFU4riI5xDErG/w2VlGVkIOZ8Mu4nlTg6ZAwjnoBkbJqzV0B+pacfguqR7Xb
99gsdpFC0UkVzduY8zJyh0+6EY7TKuyAJlEZ+4GcQIhitM9VFXyPuxmi38EPOFnq7vuUOO4+vRrc
o6Ej0jxA9MxUaF9CtXaKcEyTy4p85oq8LWhlSuyeqMPLcCerb5eLgP77i+8Onib7BOJ9cQe6rL2X
tdf7z9feZfl81oo7L7JQf3WfYxtk0y7HS7vlMWVsoGaM3JamYZawYQR9GNTrzEmRFKenNILHrMA7
uFBgswYJrj6iKhpEOIVmu+5pIqHMSIcSpVzCIc8MV9LWeGjYlT0iNvXhwdYDidUeD+zwmh7OzwgF
GbPthOYgmjNa0wTOymztWkYU1H4bZnUt1Jm51Y1optQ53AqVwYeLqsFgYU3oRBD0L2DldTira9Zw
SMGMBNrudhPO3WK8cJEukhEOSOYjrfeij+rGSXmsmFsBiJ0KH+kD3ylWK3FrabLvwO0sTiqzayxh
l3vvXbyUR/DcSzpvT6QjS8rJyRJ01PZazdWmh3yctr0xnG/hMU7B61I3f5iFcEnkK2HD/tRkNlk+
92YrV8xNgjpcWVi7Lyjs1IFUSLWDZWRDw0xlIcASzcnKv9oEs16UAjbS30KKtQ0Ihn9MCrCj61oy
HhNflZ1dGtG2s69ZKeVTRcQgCo7QiE3FAQb361AFfQIq4ZrCVAT9Andq2tpmyi3OWdKVb7IMzo5j
lkY4K7c6RfNMtnCTx4UM5q0kHuhWKbtR7vyqmJS/IFXKYfw/U0XvJ3BlsBZoD/hwpSsw0vna9rhQ
EYcqlEbU7wtoHEztgGiBe1mYhqCCi2XzX5BD/d/mnKVh0hpOfuqAhkhQ2I9UJAjZh7Jkou8UYvVs
77IkWUbIRFRJXJlasUfkkLChroHrem/3UAShbqpJVgYM7mT8ue9ZBo1C3eSU882pIcXea3Pg7+58
bDKDUm4dNg1Nbv9CxIpd1a43y/O9t6yInpi3WY08K4BZaStoZWn/liKcc6u1FWtB49VmLhx4cVFj
GCwaohQufpD+A/sfFT6zXyn0hjrkB1BbEXx00MQgbCCqr9jGA+kCaQdH0DjZQRtMmpQ1bdY6aavl
m/UFd7oF3xPG1pKdxd/nNHbRnLnsnFy8SGNnFnZsbceWmho8ezJFYWicH2SMY8znrfIXKD56CI7e
gbv+KVPSBBN8XxIYWs+ByQNIfsvRLN36CwAA//8DAFBLAwQKAAAAAAAAACEAaaohwgBUAAAAVAAA
FwAAAGRvY1Byb3BzL3RodW1ibmFpbC5qcGVn/9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAEBAQEB
AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB
AQH/2wBDAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB
AQEBAQEBAQEBAQEBAQH/wAARCADAAQADASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAEC
AwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0Kx
wRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1
dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ
2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QA
tREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk
NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaH
iImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq
8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD+/iiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA
KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo
oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii
igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK
ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA
KKKKACiiigAoor4Stv2q/i945/ab+KnwT+C3wM+HnjXwF+zp4x+Gngb9oPxn4z/aDufh58VtG1f4
leB/DXxLs9W+E3wUsPgz470P4g+EdL8E+MdEuJNe+IHxl+CNxrniDTPG+g+GNJ1lfDNnqfiBwTnU
VKEZSm4Oo7RfJTpRqUaMq1apb2dCiq2IoUnWrTp0lVr0qbnz1IRlXJL2OJrpXp4Sj7etZp1HD2kK
SjQoJutiqzlUi1h8LTrYiUFUqKk6dKrOH3bRXh95+03+zbp3xr0z9mrUP2g/gfY/tGa1p7ato/wB
vPix4CtvjXq2lLpF94gbU9M+Fc+vp46v9PXQNL1PW2vLXQZbYaRp19qRkFlaXE0ckH7S37OV18ar
39my2+P/AME7j9ovTtLGt6h8AoPir4Em+NVhoraTa68ur3vwrj15vHVrpbaFe2WtDUJ9CS0Ok3dr
qIm+x3EUzqPvqnKPvRrQr1KUo6qrDCzqwxU6bV1OGGnQrwryjdUZ0asaji6c1GZJwU3NcipqhKo5
e6qccVVpUcK5t2UFia2IoUqDlZVqtalTp806kFL2yiuCh+KvwvudP8Eavb/EjwFPpXxM1r/hG/hv
qcPjDw9Lp/xB8RDS9c1w6B4IvU1FrbxXrQ0Xwx4l1j+ytBlv77+y/D2uah5H2TSb+a3+ffiH+2T8
LLHwx43n+BXjj4F/tA/En4daj8EpPGnwv0b9pL4R+ENR8JeDfjR468M+HdM8a+Ltb1bWNRs/Cmnv
4Q1jWfHHgm01y1s5Pik+gR+FPBtxc6vrlhKuP1iheK9tTblflSnGTajGlOc9G7U6VOvRrVqjtTo0
akK1WUKTUzaGHrTcbU3FSjSmqlRqjRjTrYl4OlVnWquFKnRni08Mq1ScaXt4ypOanFpfX9FfDkH/
AAUi/Yk/4aF+L37MOrftKfBLwx8WfgnoPh3XvGui+KPjH8JNFdE1uPxDPq+l2WnXPjr/AISVdZ8A
W2gw3XxFsdW8P6SPCtr4l8Kz3M0sesoYfsV/FXhePxLZ+DJPEmgx+MNR0K/8Uaf4TfWNPTxLfeGd
KvtO0vVPEVnoTXA1S60LTdT1jSNOv9XgtX0+zvtU060uLiO4vraOXaP7xUJU2qkcTQWJw8qbU418
O6daqq9FxbVWj7PD16ntIOUFChWk3alNx41iKDniKftYKphayw+JpykoTw9eVWFCFKtCVpU5zrVa
VKnGaTqVKlOMOZzinvUV+S3jX/gon8bvAfiv4j+KNW/Zh+GF9+y98MP2vvAP7H+u/ELRv2nvElx+
0PqPir4j+Nfhb8NdA8VeHf2c9Q/Zi0vwFrGkweNvi74ZTUtDh/acTxM3hey17WdD0zXNdtdO8I6t
95fEz9qX9mP4K+NvA3w0+Mn7RnwI+EvxH+J9zZ2fw1+H/wATPi98PvAfjb4h3eo6tBoGn2vgbwp4
p8Q6Vrvi25vtdurXRbODQLDUJbnVrmDToFe8mjhbLC16WMwOWZjh5c+EzilhK2WVJRlSnjIY/KcB
nuE9lh6yp4hTr5RmeBx8aU6Uaqo11zQjOnVjTtTjKWLjF8ywNbG4fF1IpyoUa+XZji8ox9KWIinQ
csJmWBxOErqNSXs6kIN+5WoTqe70V4R8TP2pf2Y/gr428DfDT4yftGfAj4S/Ef4n3NnZ/DX4f/Ez
4vfD7wH42+Id3qOrQaBp9r4G8KeKfEOla74tub7Xbq10Wzg0Cw1CW51a5g06BXvJo4W8t8L/ALf/
AOyN4u/ad+KX7IGk/Hb4Wf8AC+PhHoWia94l8Ez/ABP+GX9t3aahY+J9U8QaVo3hu28Z3PjKfWvh
vpXhhtW+JtjqHhnTR4P0zXfDd9ezPbaoZLeoVKdS7p1Kc7QxdR8s4y/d4CUY4+ej+HBSnGOLa0wz
klW5LjqzjQcFWbpupUw1GPOmr1cYpPCQ1WksUoS+rp29s4tU+Z6H2TRX52/EL/grJ/wTm+Hvw78M
fFh/2zP2Y/GXw78U/GDwr8EbXxh4C/aI+BfiHw3pvjTxJeaIl8NY8QH4j2Wh2en+B9D1/TvGvj/y
9SuNW8M+CJD4km0mezaATfUcX7TX7N0/ifwD4Kg/aC+CE3jL4rMyfC7wlF8V/Acnif4kunhHTfiA
y+AdBTXzqvjFl8B6zo/jZl8O2mokeEdV03xIQNGvrW9lpNSi5qUWljVlr95X+vywmHx0MJy35vb1
MHiqGJpQterSnzU+ZQnypTi631dO9b6lPMfZpNt4ClWxOHrYtWVnQw9bB4mniJptYd0n7b2alBy9
vorw/wACftOfs2fFL4j+O/g58Mv2hPgf8Rfi78Lpb6D4m/CvwJ8WPAXi74j/AA6n0vVBompw+O/A
/h/X9Q8T+EZdO1ojSL6PxBpenvaaoRYXAjuyIqZ4b/af/Zp8ZfEi2+DfhD9of4GeKvi9e+EY/iBZ
/Crw38WvAOufEi78BzCEw+NrbwNpniC68Tz+EZRcQGPxJFpb6M4nh23p81N0upTToJzgniqU62FT
lFPE0acak6lagr/vqVONKrKdSnzQjGnUcmlCTWkk4zxEJJxnhKyw+KhJNTw1eTpxjQxEXZ0a0pVq
MVTqKM26tNKN5xv7nRXhfh39qD9mrxj8R7f4OeD/ANob4GeLPjBeeEE+INl8KPDfxb8Aa38SLzwJ
MIjB41tvA+meILrxNN4Rm+0W/l+JY9LfRXE8JW9IkTdw3gT9rHwCv7PfgH45/tGeJfg3+zRN4m8A
33jvxXo3ib9oT4W+KfBfgqz0K4s7PxW8Pxj07VNK8CeLdA8K3mp6Vaaz4v0aaPQrS51OxguZbeW6
gSTF4zCKn7aWJoRouHtFXlVhGjKCq1KEpQrSkqdRU61GpSquEpeyqJQqckpwUtI0KsnJRhecKlKl
KknH2/PWp+2ppYe/tpKVLlnzRpuEY1KTlJe2pc/1bRXz140/a4/ZS+G/wp8IfHf4iftOfs9eAvgf
8Qv7H/4QH4y+NPjR8N/C3wp8cf8ACRaZc614f/4RD4ia54lsfCHiX+3NHsrzVtH/ALF1i9/tPTLS
5v7Lz7WCWVPQ/hZ8XPhR8c/A+kfE34JfE74e/GL4beIX1CPQPiF8LPGnhv4g+B9cfSdRutI1VNI8
WeEtS1fQdSfTNWsb3S9QWyv5zZ6jZ3VlciO5t5ok61CbVZqMmsPUjSrtRbVCrOPNGnW0/d1JR96M
J8spR1SaMnpGjN6RxEPaUJPSNempTi50W9KkOanUjzQco80Jq94yt6FRRRUgFFFFABRRRQAUUUUA
FFFFABRRRQAV+On7avwJ8efHP41eG9R+H37EvjXwz+0r4C8Q+DR8Bv8AgpR8PvjH8GvAXhr4c+CL
fVItT17Qvi9qmlfFbwX+1P438ER2Wo+OrXxJ+yxP8BvjH8CPiTqmpeHIdW8QWB1zVfGfw3/YuilH
nhiMNiYVKlOeFqqtT5GoNzjon7WKWIpPlc6fPh61CpyVKkefVNRWpxr0K2Gqc3scRFQrwjKUfa00
+eNOTi00o140cTCUXGpTxGHoVac4uDUv57tJ/Y4/aZ8LfHDX/h949uf+ChXj/wCDniv9uuf9qux1
/wCAOr/8Em9P/Zgs4NV/aB0/41eCLv4jaj8cNE8Kf8FDbC6+HYsNF8MfE3T/AANr/jvVdQ8H+GTo
Xwr8RX3hvU9O8AaD9ufsueEPjP8ABjx94/8AgR44/Zd8W+MfDmr/ALT/AO0L+0Fp37ZN14u/Z/m+
GOr6N8YPF3i34j+Enn8OyfEqb9oy2+LfgTQ/GGnfACKzk+CFr4VXw94KhvrD4mDw7JY2k36a0VpQ
qVKOBw2XuUa2Hw9GpRk6tGhGtiFKjkeHpSrV6FKjVh9Wo8PZbCjSwssNh5expuvRryweWvBa4qc8
XUxtWpJQnjs1qZ1VdKnRhCnj61TPKmIqUaSpujTjiY8R5vSrxdOTnTxdR8yqSnUn+F3w/wDhF+17
NN+wD8D9Z/ZQ8U+E/CX7GP7XfiPxf8Rvjpr3xa+Al14H8ffDuH4P/tY+AfCHj34OeFvCvxK8T/E/
V9L1i8+IHgybxTofxO8FfCTxl4UuPE+l22jeG/HFlZeK9W8L+5eHv2UviN4Y/wCCZfhX9nPw98Mt
H8P/ABRg1nwb4i1/wRot94I0u3l1+T9o/Rvij461y71ew1WDwpfaxqdoNZ8Va1qY1e4vdc1Se7kk
mvtbvDFN+r9FeHDI8LTwlTBRrYr2VWnVp1G6lNTkquCyXAOT5aKg5Qo5FhJQ9y0atTEyacZ040ur
FY6ti54OVRQUcBgoYDC0oJqnTw9PNM7zaHxSlUnUjieIMwgqk6kp/V3Sp3vGpOp+a3ij4J+LfGP7
Xf7Vfgj4mfs+694//ZZ/a/8A2WvhJ8M9Y+K2m+JPhJdeCvD974Og/aD0P4g/D74keB/FPjnRfikl
1rui+PfC83hDWfA/w6+Ivhq/l1a9h8R6j4VbRpHuvMv+CVVv8bfiXo/xS/aG/aR02yt/iNoWqzfs
TeB9b0jxIdd0H4h/Cv8AY48Z+NvAOo/Hew037BaJ4R1X4+fF26+InizVfD8V1q623h7RvAtqdZ1N
NPgun/Xbr1rE8OeGfDfg7RNO8M+EfD+ieFfDekQtb6T4f8OaVYaHommW7yyTtBp2k6Zb2thZQtPL
LM0VtbxIZZZJCpd2J9uM0q06sqalOWDhhlP2k4OFajVrLD4xQgk3iKGX43NMqio1YYSpgszxTxeC
xeNhgsbgvMeHhGLp0ZVMPSljXi6mHhOUqNSNWlQnjMPNVXUnKljc2wOWZ9VU5ydHM8uwywbwuChH
CQ/nT+LX7C3irxl4/wD2zLPw7/wTZutL/ap+Mn7Rfijx9+zV/wAFS7OX9i7RZfgbHf6F8P4/hz8T
n+JumfH22/ba0y1+Ges+HdTu734e+H/g9qNv4xs45/Amq6beeB/F/iCYfWvxc+Fnx/8ACfjX9vv4
e2P7HGu/tf8AhX9vG28Ov4a+JF543/Z08OfBvwNpN/8AADwv8AL74P8A7R2mfE34n+G/i/Z/C/wf
4h8Ka38UZ7v4N/Bz49XNz4c+K/ilNB8Lah4ztrnw9qn7JUVyYbC0MPkOX8NTpwxWT4HI8Nw5Uw1e
nShPMMpw+WZHlU6OLxOEp4XE0a+Kw/D2WzxOOyurl2PdSOJVHE0aGLxFCpphoPCZhjMyozksTjMw
xWaJzVOr9WxuLzfMc5qVKFSpTliKlKniczxFHC4TG1sXg8HhVGnhcPRnPEVa/wCGNx+z9+0f8E9F
/a1+ANx+yp4j/bm0r9rv4dfC3wppvxt1Xxx+z74d+Emjw6T+y/4G/Zn1v4d/tLaZ8WvixpHxrtPh
tovirwP4g+MN5efCb4U/tDanc+H/AIv+K00jw/q/ji2u9D1f0B/2fvij4K8d/tC/Cn4ofs3fFj9q
z4C/G7/gn/8AAb4K+IfiJ8MPiN8GPC+oeOPFPwd8FfHfwh8TPhr4g0/4n/H/AOEHxE8MeMvipY+L
fDj+APF+i6jqvhJdT8UXTeNPiR8PhoVzrUn7HUV6VbFVMS8xqV4UamIzajhMNmGKVKFGpiMNluHz
DD5TQdLDqlhKSy1ZpjqtOtRw1PFY+vXdXOcRmcoU+Tlw+X4XCTyOphY1sPV4ap8mRVqWKxUauXVJ
1cmqYjEwn7duvicVTyPCYedbF/WHh6dTE1MAsHiqscTT/D+XwD+3PrX7LMaa/wDCf9ob4p6v8Hv2
tv2V/if8JvhX+0J4z/Yd0X9rrxd8IfhT8SPhn4j+JWmat4p/Z28a6B+x9ealpdpYeJr34VRa78QP
DHiLxJp2kGw+JPi221/UbLU5vun4B/CnxNpH7Qv7W3x78QfCyDwFq3x1s/2fV8N6l4hk8B3/AI0u
dG8D/CK2sbrwZ4r1LwL4h8VlbbwN421bxLZHTo9e1Dw//al9rmreEr7VdO1U6vffa9FcVaHtqMaM
6lX3cyxea+1VSTryxWPyXL8jxjqVJOTqxxGFyvB16jqKdT65CdZVFCrUpS1o4ajQxH1mnBKrLCxw
NTRKlUwVDNsdnOAwv1eKjh6FDLMXmePjgKeFpYeNPDYiNCt7eOEwP1X8Lv2RvgD+25J+0n8Bvip+
0donxd0yw+DPgv49eBPEugeL4v8Agnx4e/Z+8F6x8RLHwe9in7E3h39mLwXdftFv+z3e3XhF9I0u
L9qL4pWPxPstB0z4ezeL/h3r3iebXvE3g/zX9jn4ffF74o/BT9hH4Y+F/wBkeP4P+Avg3+0De/tQ
+If2orfxX8EZvhl4l0yy1v4q3mqw/Dbw74W8W2n7QMvx1+NFx44Hhj4sjxv8GvAvgnT9J174vSt8
W/ifbweHbf4n/wBDfXrWJ4c8M+G/B2h6f4Z8I+H9E8LeG9Iha20rw94c0mw0PQ9Mt3lkneDT9J0y
3tbCyhaaWWZora3iRpZZJCpd2J4auXUZ5nhcwVKinhI0a1KDliLvMcHmWVZtl+LqzjWU60cPmGUY
LFVMPWnPDYupQp0sZQxGGlWoVOyvP6zhc0wlbndLNqOYYWuoVatJ4fB5phcZgMbhsCqVSEcLCpgM
fi8HTnCPt6FOvUrUa0MXOWJf4AfscfD34v8AxS+Cn7CPww8Lfsjx/B/wH8HP2gb39qDxD+1Db+K/
gjN8MvEumWet/FW81SH4beHfC3i60/aBl+OvxpuPHA8L/FkeN/g14E8E6fpOvfF6Vvi38T7aDw7b
/E/67+Bn7KXxG0G6/wCCbd78RPhlo8l1+zP4P/aPbxZdapfeCNeuPht418e6Xpuh+E9R0OaHVdRl
k1jVdEvPE2j/ANteDmv5LDS9S1TT9SvbO01OaG5/UTw54Z8N+DtE07wz4R8P6J4V8N6RC1vpPh/w
5pVhoeiaZbvLJO0GnaTplva2FlC08sszRW1vEhllkkKl3YnbrnwuSYfD4fAUoyqUqmDnRxNSdCpJ
RxGNpYTIcC6zVb2sqNP6lw1lOCp4bDPD4aFDDzqRorF4nFYmsq01WxlbGtONWrgaWW8iqVpUoYKl
i82x/sowqVJpyrY3PM1xOJrTc62Ini3Tq1JUKOHo0f5hviB8O/2zPgZ8ePgnY/AXwFbX/wAdNE8f
/wDBX/4j+HvhZZfBv4WfHtbv9nL9pT9sbwH418PfENbHxx+2t+wd8IPBllNFf+F7yVG/aVuPjHNq
PjVdGuPgdr2gW3xD1vwP+1v/AAT38QfDPXP2OPgbYfCM+NI/Bvw98Oal8Fm074i6f4R0zx14f8Xf
ArxLrfwd+IfhXxTafDu81P4ajWfCfj/wP4m8OXdx8L9Y1z4YXb6X9r+HOu634Lm0PVLv1z43/sx/
s2ftNaXoeiftI/s9/A/9oPRfDF/c6r4a0j43/CfwF8V9L8PapeW4tLvUtD0/x5oGv2mk391aKtrc
3lhDb3E9uohlkaMBa9R8KeFPC3gPwv4d8EeB/DWgeDPBfg/Q9K8MeEvCHhTRtO8O+F/C/hrQrGDT
ND8PeHdA0i2s9K0TQ9G021ttP0rSdMtLWw06xt4LS0t4beKONffw04U8sWFr/Wa+OpfUqP16viFi
pYyjhZ5rP6zXlWpRr4XE1Vj6LxlGjVr0cwzFY7OKtShLF0cvwfTmWYYzMsfisXUqUqdDFY7H5hHA
0MPDD4bBPMsVXzDE4SgoOVTE0oZljMbXwNfE1Pa4HAV4ZS4YqGHpY1b9FFFZHGFFFFABRRRQAUUU
UAFFFFABRRRQAUUUUAFFFc94o8W+FPA+i3PiPxr4n8PeD/D1m9vFea94o1rTfD+i2sl3PHa2sdzq
mrXNpYwPc3MsVvbpLOrTTyRwxhpHVSm0tW0ldK7dtW0kterbSS6tpLVjSb0Sbdm9FfRJtv0STbfR
Jt6HQ0VQs9W0vUdLtdc0/UtPv9FvrCHVLLV7O8t7rS7zTLi3W6t9RtdQgke0uLCe1dLmG7ime3lt
2WZJGjYMbFrdWt9a217ZXMF5Z3kEN1aXdrNHcWt1a3EazQXNtcQs8U8E8TpLDNE7RyxsrozKwJpp
pyi01KDSmmmnBycklJPWLbhNJOzbhK3wu0ppqLTTU03BppqSXK24vaSSnC7V0ueN/iV56KK5qXxp
4Oh8VW/gWbxZ4Zi8b3mlvrdp4Nl17S4/FV1oscksUmr2/h57oavPpaSwTxvfxWbWiyQyo0oaNwF1
S6u9l1fLGU5WW75YRlJ22jGUnomx9G+itd9FzSjCN3suacoxV95SjFatI6Wis/UdW0rR4oZ9X1PT
9LguLqGyt5tRvbaxinvLgsLe0hkuZIklupyrCG3QtLKVbYjYOLNrdWt9a217ZXMF5Z3kEN1aXdrN
HcWt1a3EazQXNtcQs8U8E8TpLDNE7RyxsrozKwJFqpNaqElGTWqjKUeaMZW2k4+8k7Nx1SsD0aT0
couUU9HKKfK5JbuKl7ra0T0epPRRVeG8tLiW7t7e6t557CZLa+hhnillsriW2gvI4LuNGZ7aaSzu
ra6SKZUd7a4gnVTFNG7AFiiiigAooooAKKrx3dpLcXFpFdW8t3ZrA13axzRvcWq3Ku1s1xCrGSBb
hY5GgMqqJVjcxlgrEWKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK8e+OXgjX/iB4
FXQ/DUNpdarb+JvCmupaXfj3xf8ADBbu30HXrLU7u2g8e+A9L1nxZ4au5be3kW2v9G0+W483bC7x
QyySr7DRUuKbpvrSrUK8NE0qmHrU69JuMlKMoqpTi5RknGSvGSabHfSpF6qpSrUZq8ot069KdGol
KLjKLcKklGUWpRdpJppHxT4c+Anxg0rx34I1q98eaqng7QPhld+EbjwNo3xX1i08DabqF1p3iW2h
sL7wJd/Cq7PxObTZNU0mG2+JWs+NPBPiu7GmQ6lqHh+e4gks9Q1tM+BfxB8KeHPBvhzRdc1PxFou
ga9ot/faFqv7QPxt8LziGDwd4X0q9urXxxp9v4m8V6hpeleItL8Q3ul/DG9a18CavZa7E94dHfTr
axT7AorRScXNx0dSpRnN80nKXsMZi8dThzyk5qCr42s3aXO1GlLnVWnGoQ4p8l9qdGrRgrLlSrYb
DYSdTltyuo6OEpRTknHlc6bi6M3SPhi3/Z0+LNxp/wAS4fFPjvxT4yutd+LPgvx/4Ug1r9oHx3Ya
NDp3hzxtc63fafo0HhP4aeGNY+EVpcaDcJb2vhnSNb+JWjx6pZaVNBfafNpUGqv6X8U/APxi1vxF
4lv/AIZ/8Ip4ft9W8F6hpFxf6v8AFL4k6ZF4u1b+xNTsvD9nrXhbwh4Y06/8Etour6hb6h/wsf4e
/EfT/HF7pumQ6HeW09qdLl0D6crzv4qQeKG8FanqHgq5uoPFmgtBr2gwQLez2+qXmnSb5NE1PTrE
+bqmm6xZvdafcWhjmeKS4h1C0RNRsbKeHKcf3EaCUuSMtVFx5254HD5ZOo5z+0sLhqUrKUIylCUZ
fuqk6ctE17WpWbSnJ812pOMeTEzxsYKMeZ8jxE5uUuWdRObqrmrxhNfPngz4KfGq18M6afGvjxLj
xlb6d4b0q5h0f4n/ABe1jwbHp0HinWdX8T2S2fi28vbvXZLzR5NA0ew17xZDrPiq4s7K90/UddFt
eXsupcxD8Cf2iLCX4N6FZ+N9Bn8N+EL14fiH4pk+K3xw0bxfrWhPb+HbeODwx4O8K3Gi/C+O4tdM
sL/w+tjr2h3ukRmGPxZ4bt/CGua/qdrp7JPi78ePC/gXxctlo2r+IdV8HDwxp2myan+zp8c9W8RL
LFrV1p+u6G9raeIo4Pjb4kvNA0+TULHx94O1jwN8MRrk1qdb1jR9G1a0u7fu7rUvjVZ6l8WPNtLv
WvCeov4j1LwfoqeG/Hum+KdK1HSNN+G5srWHxfonjoJd6FrVxqXiE2Gi+HdG0OeK60zVBFreqouo
pW1N89SvVpyio1p1MwlJ+1hB1cNPCQhRjFqniYUa0sxdanBWhXbnjPeoVaWLfPVj7KGHpyVR1KUH
gafwynCFSnVrTrSl71KVWlHCQpTlq6SSwskq1J4c5jT/AAD+0j4i1j4JeMv+Ej0m1s4NefxF8VYv
EPjT4yeFdc/shLnQbDTtK8L/AA48PahZ/DyUax4Y0EXmv6D8R9D1Q6R4i8Qa2+ktpN/NcX7X/iR4
P+KWsXl7oXhKx1prvWPjB4k1K/1SL4jfEj4TaXJoc/ww0+bw9rN14t+Hujatql1aaBqEGmaLBoU8
C6JrmqaI+lajdwLK6vq/FVPEMnxIukgPxmHiNrbwR/wp9/BcnxLj+GEd2NVum8US/EJvCjL8OGii
kCSa/F8WhIs3hlbSHwZBcaq9xBJyt9rP7QWj+Cdb+3anerNp3jbQPEHhrWLH4R/FPxVrml+G7j4s
eLoNY0XxV4c8PeOLrxH8TYLPwvpmlXYtPC48IFtC1OyiOlS2T2sk2UJLlpRd1GriKmD9pGXs4Qji
syyhy5a9F0HSqYf6lRm5xVBYSEMS4YlYqpGrG5JqVaolO+HoU8VySXNUk6FDG0acfq7jU9pRrvGO
nClFVKdZTotYRYahOmtL4o/AP4xeK7GSbw58WPHGm6zd+PtK1rUn8OfGrxf8Mo7zwxo/hldOsbWz
l/4Qb4paF4eVdfuNW1TWfCuh+CbXTvFqXennXfETNoOm26L49+DPx38UD45W2ieO9S8MWPjrVvAV
94OuND+OfxA0nxRbWmgTtF4k0zS9Zl+H2teGvgppmp2dvp93Fb+CPAfjPVtX1ObX4fEfiO803UdK
t/D+34V+Mnxb1T4t/DnwPrHgDxPa+HfEXw9i8Q+LPEB+C/izRvCmka02m6zdxhfiTqXxAuYNF1O+
nstKU/DXW/h/LrGipqxtdQ8aT6raPYP9a1c4txjfZ3glycn+61cJhPepOEEryyem50500qiqVfbU
71OSm6clry8zcXTm5SnKcn7VTx0F7XnlP3I45wpzhNSoqMfq84yj7WfzPZfBvxpPqPhm+1zxx4su
ItK8IeHPCepWx+LHj6cX0C+CPFWg+Lr3U7bRbbwZ4b8R+ItQ17UPDeq2fjKfwvouuedpl1q2np4a
vDFZS+Z+AP2fvjL4U8V/DXUrnx54htfDHg74U/8ACFXfhLTPj14z1fwhHr0Wl+IbA6ld+FPE3wsv
L/xw93f32m6zp+v3vjnwdqHg6OO18O6PpOoaL4Y05NU+5KKVT948S3eKxTk6qg3FLmo4+jaDTvBJ
Zni6iSf8aaqO7vzVTtTVFJKXsKUKVNySdlTr0K6nKOkZVG8NQpubi2qNGlThyqnBx8L+F/grWfB/
iO6tr661vUYrP4Z/D/R9V1vW/EHijxTJr3i2LW/Hmsa9Nba54tubzVLu2sJtaDWym48izstVs9Jt
bXT7PS7bT7b3SiirqVJVJynKyc51Juysk6lSdWSW9oqU2oRvaEFGnBKEIxUQgoKybfu0otybbfsa
FLDxlJvec4UozqzetSrKpVl705MKKKKgsKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA
qlqV5/Z+nX9/5fnfYbK6vPK3+X5v2aCSby/M2vs37Nu/Y+3O7a2MG7UNzbw3ltcWlwnmW91BLbzx
7nTfDPG0Uqb42V13IzLuRldc5VgQCMqyqyo1Y0JRhWdKoqM5axjVcWqcpJxmnGM7N+7LRfC9npSd
NVabqxcqSqQdWMdJSpqSc4xfNHVxul70dX8S3PmP4e/tP+HvEnw+t/Hviyws9PtL3UYrPT3+FNz4
w+PGi31u+hWet3t3Bqvg74e2OqBPDJuLjR/G1zP4bh0Twnrdm+nahrjTTQhukH7SHw2sbv4iweKL
+98MWXw5j1bU73X77QfFknhfVvDej6DofiC81bQ/FQ8NxeGdc1GK11yIyeFvDmr674hSONZvsTec
I4+g1f4E/DLWbKLT59H1rT4ITZYk8N+OPHnhG+lisdAsPCyWl1qfhXxLo2pXun3mgaVpOmaxp15d
z2GvQ6TpL63bahNplhLbun+BnwyudS1/VJtE1Np/EmmXWlahar4x8axaNaQ3lrYWU974d8PReIk0
HwhrxtNK02CPxN4T03RfEduljbfZ9ViMSEb1WnVxUqSUaTw9aGDhJSfJiGsNKhVrrn5nFThiIVIw
qtOjW0i6qhUpYQU1TwaqScqka1KeOknFc9G9ZVqWHfJyp8k6TpznTjJ1aMZScacqlKpxtx+1b8Fz
4C0n4kaFq/ijxn4Y1/w94g8T6JN4K+Hfj/xHd3ukeF7ubT9ZuLy2sfDbHw2tpqUD6cZPFr6Bbm9M
cBnBlQt0niD40ab4e8Z+AtBvtIuLXwz438L654hm8Was974fn8My6ba21/p1nrvhrW9IstQ06LUr
U38N1NqlzpmoaNq8WnaRdaPLNqM0mnYvhuH9nnxtY6j4L8N+PNA+IMlvoOv/AA21eCH4y6v4+8WR
aXr8lzqetaFqmvXPjPWvFy6qx0u6uILu81P+39Kt9MlXTbuyttPKQ+j618MfBPiS0t7LxBo8utQW
2iWnh1Tqmsa5e3M+k2WqaRrUEN/e3GpSXmpXDapoWl3lzqOoT3WpX0lvIt7d3Ed3eJcD5XKlKDkq
bnXm1K0+bDVaeYLByi4unzzjCplOIc4yp051Y4v3Z4d0qVU9/lrRfLzpUoRavF060KmBliOdPnST
SzGkqTi5KDwv7ynVnUq0POvCf7QvhvVfD/hvVPFulax4R1TxNr3iXRoNJstG8WeMrPRotD8ZX3hC
y1Hxf4i0DwqdI8FWuqz29s5u/Fsui6Tb30t9pttq2pjSbu9Nm5/aJ+HqP4fnsrnUrrR9b8eeKvhw
dRufDni/S7mfxV4T07Vbm+07wpo1/wCGo9T8fySajpF3o8E3hCHUrK5u7bURY3l7Lpd9bxaHiz4Y
fB7TYB4x8WFvDWleGLzVvE2q6rdfEHxV4S8MP/aPiOfxhqU3jiG38T6V4d8S6DF4ju7vVrfSvGkG
q+H9KlvLyPT7Gztru4hlp+Hvgz8FNW0eTW9AtpPE+meMNeb4jQ+Kx8Q/GPi241bW9S0Sw0ex8UaN
4wvPFWq6in2PRtP0tfC9zo2rQ2nh42Nhf+GRpt3bW90hFxk/eTio3c1CXO4qWJoqhFuSjrUwcMc5
TaivrVOiqdN0fauDqKXPU9nJKE6snRc42apXrymnBTd/YueCjGHtJSlTdVVMQqkqdR7tr8bvhtdX
ep2X9s6pZSaTfxafNcax4P8AGmhabevcS6jb299oOr614esNK8T6FPdaXdWcHiTw3ear4emvXsLK
PU2utV0uG85LWv2lvh1pFxp7wTax4i0zUU8KxRnwp4U8d+IvEMN74yuPDB0Yz+HtM8ITiPTV0zxf
oWoahMdU/tq0mv7TSU8PXGp3MVueji+AfwrjsfEmly6BqWoaZ4pawGpafrPjLxvrtjZ22l6x/b+n
6Z4ZtNZ8R38HgvRLTVwl7FoPg6PQtFDw28bWBhtreKKxJ8DPhe9vd28fh25she6pd61NcaV4l8V6
PqCape+LNM8bTXlpqmla5Z6lp8ieI9F0q5tBYXVtHYWNjBodiltoKnTDNHSphXiNaaqRli1S0cqa
haVKipatym3NVJTpuChGDhPmlJOtdxr+w0k7Rw/tNeVOpTk61SUVa8acatL6vGm1Uc41ViKPJ7OX
U+DvHnhrx4niB/Dk2ryHwt4jvPCeuQ6z4X8UeFbqz12wtbG+uLVLPxVo2i3d7bGz1KwurbVLCG60
q9guY5bK9uE3EdjXG+CvAPhv4fWOo6b4YXXY7LVda1LxBdQa54v8XeLvL1PV7l7zUn06TxdrmuS6
RaXd7LPeyaXpL2Wli9ubq8SyW5uriWXsqPs0/wCb2VH2v8rrqlD27p9VSdb2joxk3ONJwjOUpqUm
a3ntb2lTk0s1S9pL2Knq06ipciqSVoyqKUoxjFqKKKKKBhRRRQAUUUUAFFFFABRRRQAUUUUAFFFF
ABRRRQAUUUUAFFFFABRRRQAUUV8HeGfjv438KWHxD17xtrIubZde8jw2vxn174f/AA18D6ZaTfED
xr4ci1mx8efD7wjrbaJ8OVsNFsdHjufH2m6147XxgmnWGp2enWPijRdSv5c4qUYydnO6i2m1KfNG
Kpqyb55c14q1uWFSUnGMGx2bTaXNy8rkk0nGLkoupLmaShGTipSvo5wik3JJ9Nq3wW+K/jy51C98
ZJ4b8L61b+JPEviLR/Ffw/8AjN8TrLW9QkuPCvifw74KsLo6H4J+H174c0PwqLzQfP8ADltr3ifR
taebxHqmqQXeo3t0NZvS/Bj4yyfET4zeJm+JvimXRfHXhIaJ4NsG+Lmu2vhvwzeGHw/HFLpXw407
4bWT+CtUshp+pxt4z0H4m6rqGrG7mu7rQLW61Fjpebon7TGsXPxD0TSrrS/DF5onjPwP4T8Q6T4X
07xvDdfEOK8u9J8X6nq9/wCBfCSeDrab4i+DpV0jTZZ/FU3iPQRZabdafqUWhIL1rZ3fDb9p3x58
UfAug+IdC+Ffgay8TeIfGXiDwxa6E/x68N+LvD9vYaB4YTxRNql14u+GXhjxwsGsvbGWzk8HX+ja
bqtpexRpfXNra3UF2wmqSr1GnOOCwlWhiYy96HJL2eX1ajhJqnKvJ0YQdSmk1ThN6YSNRKHKNRU1
zez+s1qdWjKLcJJ1XHF0YqavNUF9WlOlTqtwpVKrso4mpQt6nf8Aw18U2Xw+0vQNDvbXxHrnhDx+
vjDwzbeP/GHi7W7bV9M0zxje61oWheJPG+t2vi7xal1aaNcW0Ntrl1ZeKLnR9XsNPuI7fVbeyjST
ybxb8L/2lNe+INl4h0XUvhx4U8Iy+AdRstd0HQPip8dtIvrzxZqqa7c3+jWdnpq23gDT9MuLzVLe
D/hbGneBNN+KNvfwN4tsoLV0g8KrfvfjLqWvfCT4L+M/E/xJ8KfBbSfiFA1x4v8AiR4M13wtr3h3
QdQi0W9vdO0LTPFHxK8L3/hPSZta1S0ew1CPxF4d1CWxv7O+8H6bfXGtzWOtvnfEn9rKX4S6X/an
ibSPBjaQfHWi/DrRNQ1jxX460PxD4z1mXwzF4g1mWz8JaJ8G/GEHh2/K3emxaNpniDxDY6TPPdXk
OveJfC5sbYano6U/b4nBt81aGKmpxbU/aYnFUcLklSpGo1KM51nisuo+zqS5pVVRrUqLg8ZOpLq0
1CGLa9nTlBSUkpUlClh8Ric6hSVNOMoUqHssdVUqUeWlh/aU51VyYZU/or4S+HPFHhXwZa6R4uuf
N1RNQ1a5is/+E28VfEr+xtOu7+aew0f/AIWD44sdM8X+LvskDhv7W1+wtb1PN/s+OM2djayP6XXw
Pbftf+IdQh8e69/wgfh4ad8Ptb8caVpWjeE/jr8OvFl54wi8PeGfEusWeoePrW28NzyfCO1m/sS2
lktPEOv6TrHh8Prd54ksZLDw+9tqf1P8FviJe/Ff4Z+F/H+o6FpPhq98QQX0txouheOvC/xL0eze
y1W+00f2f448GXF14c1+3nWzW4FxYSI1u8r2N3BBe2txCgm6i518MaGCqXcpOTo4ujOWFlKVSUqt
WpOnQk68qsp4mNT3sY1Wqp1GuWDcL6vEYuk7JcvtqE4TxEYqmlThThKvGNJQUaFr08PeNJxh6jRR
RUlhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRXl2t/GX4c6F468N/DOfxRot7478R6s+mf8ACK6d
rehXHiDQoV8KeIPGKa14j0N9Uh1jS9Bm0zw7cQwal9gnWS+vtMjEf2e5e6gbH8c/gnKNFMXxh+Fk
g8SavceH/Dpj+IPhJxr+vWktjBd6JopXVz/aur2s+p6bDcabY+feQy6hYxyQq93AJBLm5eX3ub4e
XXm9909Lb/vE4afbTj8SaHJOFuf3bwVRc2n7uXtGpO+yapVJK9nyQc/gs36nRXzb4C/az+BnxE8b
Xvw+0PxvoEXidda8RaJoFhc+KPBl1P4xl8K3iafrN3oFlofibWdUtoBdM50i18Uaf4b1jxNp1te6
/wCGNL1jw7ZXWrReta58Tfht4Y1mTw74k+IPgfw94gi0K88US6FrnizQdJ1mPwzp8V3Pf+IpNMv7
+3vU0KxhsL6a81doBp9tFZXck1wiW8xRJpwhV/5d1IOpCb0jKMabqzab604KUqsXaVLlmqii4SSH
GUZzpuLVSnUdKcGmpRmqzw/K1veVZeyg9pztGDk2r9xRXmtv8ZPhLe2Xh6/034nfDzVbbxhcXtl4
Nk07xx4VuI/GGo6fN9lvNN8LXA1dbXXL+2vMWdxb2E8zW10yw3JhbOHaT8VfCeo3VrZXt3D4eub7
RfBOsWS65q3hpba/l8e2/iC50XRNK1LStd1XS9a1lIfDOqSzx6Le6jYXMMaXWj6hqtoZLiKrPlnJ
q0YThTlJ6JTqSlGELuyc3KLi4q7i3FSSc4c08yvFXTcozmktXyU/jm7X5Yx196Vk+Wdm/Zz5fSKK
4Pwv8VPhh44jEvgv4j+A/F8RuL60Evhfxf4e8QRm60u3tbzU7YPpOo3am4060vrK6voc+ZaW95az
3CxxXETPJpHxO+GviDxHN4P0H4heB9b8W2+l2+tz+FtI8WaBqXiOHRbu2sry01ebRLLUJtTj0u5t
NT066t797VbSa21CynjlaK7gaQs3JxSfMoqbjb3lCUXOMmt1FwTmpbOKck7K49k29EpOLfRSUlBx
b6SU2oNbqTUd2kdxRXG3PxG+Htn4jvfB13478G2vi7TNGl8Ral4WufE+iQeI9P8AD9vEJ59dvdDl
vl1O00aGBlml1Oe1jso4mEjzqhBrIj+M3wfm8OWXjGH4rfDWXwjqOqnQtP8AFMfjrwu/hy/1sFgd
HstcXVDpl1qoKODp8F1Jdgq37n5TiYtTdotSemkfefvVXQjor/FWjKiu9WLpr300Evd+L3dWve01
VNVmteqpSjVa6U5KfwtM9Jorl9H8b+C/EOteIPDegeL/AAvrniLwnLBb+KdA0fX9J1PWvDU9z5ot
ofEGlWV3PfaNLcGCbyI9Rgtnl8mXy1by3xyXij43fCvwjdaxp2q+OvCh1fw1d+HofFmiQeJ/Dn9s
+D7HxLqml6ZZa94r0251a2uvD/h+3Or2V/fapqSQQw6bJ9qiE5aKOUTUnTSabrcnsrNWqKpKMYSi
9nBucffvyJNNtLUGmudNNOm7TVtYS092S3UndJRa5m2kk20n6rRXnVz8YPhJZaP4a8Q3nxR+HVpo
HjO6Nl4P1y58beGYNH8V3glMBtPDWpy6mllrt0JwYTb6XPdSiUGPZv8Alq7f/E34b6X4hvvCWp/E
HwRp/ivTNGuPEWo+GL3xXoVr4isPD9pbNe3Wu3miT36anbaPbWaPdz6nNapZRWytPJMsQLUTahzc
7UOSVSM+dqPJKlT9tVjK9uWVOj+9qJ2cKfvytHUI+9y8vvc0YSjy680as/ZU5Rte8alT93Bq6nP3
I3lodxRXjmm/tDfAjVvD3hbxVa/GD4cR6F42t7y48KXuo+MND0dtcGmxxSatb2Nnq97Y3z6howni
j1vTHtk1HRZ3+zara2dwGiF3w/8AHX4MeKdH8H69ofxS8B3mmfEB2h8FySeJ9JsbnxJeRGJbnTNL
07ULq01KfWbGWeK21LRfsi6tpl232PULK2ug0IqzvKNnzRcVJWd4uTaipLdOTjJRTs24u17MHorv
Re9q9vd5ubX+7yS5u3LK9rO2z4L+Gfg/4fTavceGLTV4Zta+yJdyaz4s8W+K2t7KwkvZdO0fRv8A
hK9c1seHfD2myalfvpvhvw+NM0DT2u7g2emweY2e9ryqL46/BCfw9c+LoPjJ8KpvCllqR0W88Txf
EPwjJ4etNYFut2dJudaTVzpsGpC0dLo2Etyl0Ld1m8ry2DHaufij8MrLVPDmh3nxF8CWmteMYbG4
8I6Rc+LvD8GqeKbfU136bP4c0+XUEu9ch1BPmsZdMhuku1+a3aQc0KL92CT09lShFJ6c8L0KcY9O
emr0oJe9BXgnFA2ryk3rJ1pzk3q3RS9vOTe7pJx9tJv3E1ztXR3dFeb3Hxb+HukWWmXni3xb4W8C
trWs6voOjWni7xj4M0+41fUNI1y50CSDTJbXxFf2F/Pc3tunlWFrey6raNcwafq9hpuspd6Za6I+
Jvw3PjNvhwPiD4IPxDWPzW8BjxXoJ8ZrF9gGq+a3hcX/APbgj/stl1LebHb9gYXmfs5ElJLmso+9
dzStrd0knUSte7ppp1FvBP3rBsm3ooxjOV9LQnLkhJ32jOfuwk9JS0i2zt6K8h8VfGTSPCfiu38N
3XhjxhqdhHeeFdO8ReMtJtdBl8K+DdQ8car/AGL4UtPEH27xDYeJbmTVdRe2jll8MeG/EdtodvfW
eoeI59H06cXY0vD/AMSTrHjrWvAGp+CPGXhDVdM0yfXNKv8AxC3g670fxZoNtqx0aXWNCufCXi/x
RdWcAupLSRLHxbZeGNamtr6KSHS3a21KOwIe/wAqjq5SrwimrSlPDUlXrxUXZuUKD9va15UFKvDm
pQlNErQjKcmlGPseaSacV7eqqNLVXXvVpRov+SrKFOpyznGL9MorkvGPj7wL8PNOt9Y+IHjXwl4G
0m7vE0611Txj4j0fwzp1zqEsM1xHYW97rV5ZW015JBbXE6WscrTvDBNIqFInZc7wt8U/hz438QeL
fCnhHxp4d8Q+JPAl9b6d4u0XS9St7rUNEubqztr2A3Nujb5LaSO6W3+3WwnsU1K31DSHuV1XS9Ss
7QXvNxj70kpSaWrUYKDm2lqlBVKbk3pFVIN25o3GnFKUlyxdrN6J80nCNm9HeacVbeScVrod9RXi
d98a4Rf6Dpfhv4dfEDxvqGu6h8RbI2vh2X4eWDaTbfDDxhZ+CPEerapL4z+IHhK3bT5dYv7aTS49
Km1TVbqxdp59MtZUa3HKy/tHXdvceLba5+A/xmtpfB+t+HPDF95l98DHW/8AEfi6/wDDVl4a0bTD
b/GybfPq0fizSdQjvL8afpNnZm5TU9Rsb+H7C4teSybdVyjTSi71HGrGg1BWvJuvJUYWv7StenDm
nGUVTjJNxtqpRi1de65TnT97W0VGcJe0bsqcXGdRxhOEpfS1FcBqnxAg8OfDjV/iR4t8OeIvClpo
Hh7VfEet+G9Ufw1e+I9NtdJhubie2nk8OeI9d8LyXUsFv5sUlt4mn06NJo2vb+0VLk2/FRfG25uP
C2peILX4QfFa61fRfEt14Z1nwRbj4ZyeItLmstDg8R3Gq3Os/wDCyx8OpNGXSru0dbm08d3NzJe3
MekR2bauk9jCpNQdXmaSo0/a1ZXXJCkqtOjKq6ifI6UKlWmqtRScKUakJ1JRhKMmopz9jypt15un
Si01OdRU3V9moO0lNwT5YSSlOScIpz9090orI0DXNO8TaDoniTSJXn0nxDpGm65pc0kUkEk2natZ
w39lK8EqrLC8ltcRO0UqrJGxKOoYEDXq5wlTnKnOLhOEpQnGStKMotqUZJ6ppppp7NEQnCpCFSnJ
ThUjGcJxd4yhNKUZJ9VJNNPswoooqSj51vPghrl38Q7XxN/wmujR+ELHx9q3xLtPDQ8Dyt4n/wCE
n1v4a6t8Nr+G78cf8JctreaGtpq0upWVk3g6PVLV4LbTG1ufS7a0t7bmPHf7Nmu+KfCfwt8FaJ8S
j4a8OfD7wxo/hnUtKj0zxzb6b4gTRk0GODUotJ8EfFn4f6Qbjy9FeOLS/Hdh8SfDVqtyv2fQ0ZdQ
bVfrGinBumqUYaRoLCqmt0lgqNehhE07qaoUsTVhTU+ZJOm7N0aLpk/3jm53bqU69KbTcbwxNeWI
xCXLbldatUqVKko2nJ1KqcuWpNS+e9K+Bt9ouv8Ah3WrHxhD5enar8eG1y2l0LUoLnU/Dnxz8e2/
j+903RdV0jxbpV94Y1/w5qGnaTZWPihH1Vbi1hv5o9E0+9vLO50rA1j9nnxANYnufA3xQ1bwXpD+
DdY8NFri++LPi7xtq17qdvqq2t94u8b6/wDGt28SWmjXmpJc6LcjQtL+Ifh21tItI8I/Evw1pbvb
19R0VMoqUeRq8UqiSu17tWFenON1ry8uJxDjG9oVK9arBRq1JzdyqTnOVSUrzlVnXbsrKtPEPFzq
xikoxnKu+dyik+WMKf8AChCEfmj4Tfs+XXw6uU1TWfGFv4q1o2HxCspb8aX4taUt4+1DwTfXEseq
+PviR8TfGUwtB4LgS4XWPF+sTahJdoY7jT7TT7Sxp2m/s8zaL4o8I+NNH8dXll4j8J/Dvwb8Mo52
0drzS7zw7oFjrNlrkw0O81qbTLLWdak1DTtR0nWreH+0/D11okVjd3XiLw3qmtaBf/StFU23SVFt
+zjSoUIxWjVLDvFulBTVppR+vYuMmpXqQrSp1XOCjGOShFSlJL3p1K1WV22nUxEqU6suVtx1nRpT
ikrU5wjOmoSVz4Luf2UvGNj4X1WxufH174y8V+J/GHhFLjxTaT+ObO/0HwlPpOseBPiDdy3/AMUP
jB8VdcvLu/8Ah/4q8TxWFppesWmkabrjaNfaN4VtprN5x6fe/s46jq/xWn8b6z8RtZl8HJZ6hYaN
4N0XVfix4W1bQLO/8PWWgrY6Hr2gfGWy8JeG4LMWjXEOo+Dfhn4W8V3KOLbU/E+oGXUrjU/qWii9
3NyUZOp7SMnKMWvZVMPh8N7BQsqfsacMPKVJODlSqYrGyhNLFVYttX5fenaLUornldVPrU8ZOqpt
uanVrypyrWko1fq2F54t0KbXzfJ8DfEMWm/EPwdpvjvS4/h544srqW30/XPCmueK/H2l+I5NC0LR
rbUtX+Ieu/EO5HjfSY30KG5vtM8U+F73XNXt55NMv/FslmkQXV8O/BzWIPEem+NfGnivQvEXi2Dx
1L421CbQPBd14X8PzSx/DXUvhnptpo+jap4x8Y6ho91b6XqH2y+1a58QaxcajMk1pHDYWUtvDZ+9
0UJtcurfJRp4eDk+dxpUlGNOMXPmalGMYwVRP2jpxVNzdNKIuWN5tJR9pUqVJ8vuqcqzk6vMo2Tj
UlKcpU2uRznObjzzlJ/LHgz9mW38M+KfF+qap4z13WdA16w8UaboVnZeLvjnoXivwxZeL/E1j4p1
q3sfES/HTUvDWkrcX2nWifafh/8AD/4eaiY7W1El86fbo7+vqn7OfiWXVNeudC+Iul6RpE954E1X
w3oOqeGvHnjOzTXfAXiXwv4j0zxF49/4Sv4zalb+MvElw3hr7DqPibQLP4feJdcTUZL/AMVax4j1
XTtIvbD6voqYJU3hpQvF4OMYYdpv93GFWdaHX33CtUqVYSnzShOc5Racm3TfMqil7yqz9pNSSknN
xjBtJ3UVKMIqUYpRkormTsj5SvP2evGMmltFY/ErwzFrXiTSfiVofxF1HUfhdJqGm6vpnxR8SL4k
1xPA+j2/j/TJ/BF1YTNNZ6ZNrGsePbe5t/sc3iSz8Q3thBdHp7D4I6xY+MbW+XxnpkngDT/GUfxC
svDTeELkeNv+Eqi8GL4MH234if8ACWtZX+gm1Mt2bCXwMmsENDpZ8R/2PbJYn6GopKEIpRUYqKp+
yUUkoqksT9cjTUbWUKeK/wBoowSUaNZupSUJNtqa9o5ud5OpOrUnJt806legsLXqSle7qVsMlh6s
2+apRXs5tw0PlzQfgH4v0O1+DWnQfEXQYLb4S2droEmqaP4L8W6F4n8T+DtKks4NL8NX97ZfF0+G
7i2udJso7TxFH4o8IeMNIvNTmn8ReGND8G6vHp02n9R8PfgvqPgqx8CW994tsNVvfh58NPEXwt8P
atpvhMaNex6FqV74Rk0a/m/tDxB4liOsabY+D7CHV3iSLS9f1FzqEelaNawx6VXvdFVraavL948R
KpLmlzzniqFXDV6kp353UnRxFeKqc3tKbr1qlOUKlWc5XKcpSlOTTlOVGctFZuhN1KScbcvJGbv7
O3s5JRjOMowil8MaN+zX8VfBuqeHtX0j4keH/E/ipvHVvr934s8W+F/iH4u03QbLTfhn488JpdX2
k/ED9oPxR4v1a71KfxJHZRReG/Hfh3S9IkuUntPD8WnLqkV10th+z14us9fs9Ds/FWk2XgHTvBnw
M0TXNUvvBenaj4s8Z3Xws8V+KPFJttD1Ky8S6Zp/gqI39zZHUF1Dwh4mtWstXki8ONpeo2k2op9h
UVXO+bn0clKjNXiuVPDq1OKhbk9nbSdHl9jVtGVWnOUYtQlZNXl73PzNtuT9pVdeTc3ebkq0pVYT
cuenOUvZyim0/nvUPgHaalpWrabca9byPqfgb44+CVupvD0U7WsHxq8XW/iq5ulR9UzJDootorCe
wEsSa5sjupLjTvLW2rzDwx8O/iRa/tGeK9b1HwlqyeA9aXXbRvEtzr95b6da6ffeGdI02PU/Bp0P
4+yQ6X4o1G40jTLG7uI/2cPBviG0shqgm+KWszWVvf8Air7ToqY2jKLspRjh8XhVTmlKm6WNxEsV
Xunq3KtOpNXlypVJQcXBQjCpNypxp3a5K0K8JxbU4ThChTXK72SlHC4Vy05uahFxlHnre1+bJv2f
bi11hbXQfG13b/DvVNQ8Ga14v8O+Ko/FnxC8da1rPgTXW8QaRcaf8VvFvj+91qxtL24t9G07WLTX
9I8XTDRNJj07w7e+HBJHNbdJ4I+E+qeGfiP4u+IOo6p4EjbxLFfwNpnw9+G9x8Ppdba81K1u7bWf
ibqc/jfxafiJ4r0WysIdM0PxAbHw2dOg1LxN5di0WuJbaf7fRTi3CXPF++/rF5v3pS+txhGvzSld
yU1ThZSbVNxUqahK7JaUouD+BypT5V7seejKUoTSjZKd5S55K0qifLUc4pJeKfHP4XeJPix4YsvD
vh3x5N4G8q/nn1Nwvjz7JrNjcaZfaebG8f4b/E/4R+J2WGS7W6jtpPFk+gXLRsmseHtVYWUthZ+F
3wv1L4a6h4n2+JrHWdC8Rw+DrkWDeHZ9P1ay1/wz4D8LfD+9vTrI8RXtnc6Rqml+D9JvLXR/7Bt7
3S7+XUWl13Vbe4trey9iopU/3TruneLxPs/b6tqoqUZRpqSd1yx5uZRSUfaKFRp1IQlGpNz9nzNv
2VOpSp9HGFWrRr1IpqztOrQpSbd3aMoX5J1Iy+V/FX7OFzrepeCdWstT+F+p3ngzxJ8VfEVpF8Uv
g5J8SrC3ufiX8QLDx7BfeHraL4heEZfDniTwxLYJpll4ijur+S5innuUsbBnEC9v4n+COk+L7f4h
6dr93pur6L8RfHPw68Xatomr+HbbVdKex8CHwOLrw5f2N7eyWmr2fiGLwa0M8tzBHDaR6oyyWGoL
aFbv3GihaRpxsnGlUdaCaUkqjr08S2+ZPmTrUac3CfNB8vJy8kpRb558/tOZqdmuZaOzqzraWsk1
VqTkmtVzWTUUkvP9c+H+ny/DfVfhz4Hay+HFhN4fvND8PP4X0qHTtO8MiaOQW5sdG0afREjsI5nP
2mx0y90eee2kuIrTUdNuZY72DwZP2f8Ax3ofw41DwboPxN+H/hix1LxafEOvaHp3wg1Ww+Etv4Oi
8PwaXd/D7wx8PrD4u2Gq+DfDWr31mnibxOum+PpINa1i88QeZZW2n+IdVsp/rmjr1qZqUvbNO860
IQm5uUozVOtHEQVSHMlOLqxTqrT21Nzo1HKjUqQkoNQ9mkko03Pk5VGMoc9P2UuSXK3CSh/Dkruj
NRq0+WpCMlheF5prjw14fuLi903Up59E0uaXUNH0e78PaTfPLYwSNd6ZoN/qOsX2i2FwW8200q81
XUrrT4Hjtbi+upYnmfdqOKKKCKOCCOOGGGNIoYYkWOKKKNQkcccaAIkaIAqIoCqoCqAABUla1JKc
5yV0pTlJJ8t0m21fljGN9deWMY9opWSiEeSEY6e7GMdE0vdSWibk0tNE5Sfdt6n/2f//////xwDV
APH/////////xQDdAFn/////////wgD9AMP/////////xAD9AMP/////////xgD1AN7/////////
xgAJAef/////////xgANAef////sBQAAAgFZAFn/////////xgBNAd7/////////xgBRAd7/////
////BAFZAFn/////////QgCAHuL/////////xABlAcH/////////QgCEHuL/////////xQBlAcH/
////////xgBlAeL/////////BAF5AMP/////////xgAD+8n/////////AgHdAFn/////////BAHd
AFn/////////DAHVAPH/////////BAFlAcH/////////DgF5Aef//////////AGDHtj/////////
QgAYIOf/////////QgAcIOf/////////QwAcIA8AAAD/////RAAYIPP/////////RAAcIPP/////
////wQCAHrD/////////wQCEHrD///8yBgAAwgCAHrD/////////wgCEHrD/////////wwCAHrD/
////////wwCEHrD///8kBgAAxACAHrD/////////xACEHrD/////////xQCAHrD/////////xQCE
HrD///8nBgAAQQBKABwAAAD/////QwBKAA8AAAD/////QgB2AOz/////////QwDGABQAAAD/////
RADCAND/////////QQAGAej///8HBgAAAgGEHrD/////////BAGAHrD/////////QQAKAej/////
////BAGEHrD/////////QQAiAef///8ABgAADgGEHuz///8xBgAAQQBOAeT/////////QQB2AVn/
////////QgB2Abr/////////xAAQIOf/////////xQAQIOf/////////xgAQINj//////////AFB
AOf/////////+gFRAOT/////////+gFVAN3///8aBgAA+gFZAFn///8bBgAA/AFRAN3/////////
/AFhAOX///8oBgAA/AFlAN7///8qBgAA/AFxAOL///8hBgAA+gF5AMP///8gBgAA/AF5AMv/////
////QgD6Aez/////////RAD6AdD/////////QQAaAmD///8pBgAAQgAaAtP///8rBgAAQwAaAgoA
AAAsBgAARAAaAuP/////////wQAuAA8AAAD/////xQAuAA8AAAD//////AHBAOf//////////AHF
AOf////VBQAAwABKABwAAAD/////wQBKABwAAAD/////+gHVAOT////wBQAAwABWAJf/////////
+gHZAN3/////////wwBKABwAAAD/////wQBWAJf//////////AHVAN3////xBQAA+gHdAFn/////
////wgBWAJf/////////xQBKABwAAAD/////wwBWAJf///9QBgAAxwBKAA8AAAD9BQAA/AHhAOX/
//9kBgAAxQBWAJf//////////AHpAN7//////////AH1AN7/////////wwB2AM7//////////AEB
AeX///8LBgAAAAEYIFv//////////AEVAd7///9rBgAAAgEYIFv//////////AEZAd7////1BQAA
CgEYIA8AAAD/////CgEcIA8AAAA6BgAADAEYIA8AAAD/////DAEcIA8AAAA+BgAADgEYIPP/////
/////AFNAd7////bBQAADgEcIPP///9CBgAA/AFRAd7/////////EAEYIPP/////////wQDSAOT/
////////wgDSAOT///80BgAAwwDSAOT////pBQAA+gFlAcH///8RBgAAxADSAOT///8FBgAAwwDW
AOT/////////wgDaAN3///8EBgAAwwDaAN3/////////xQDSAOT/////////xADWAOT/////////
xADaAN3////jBQAA/AFlAeL///8XBgAAxQDWAOT/////////xQDaAN3////WBQAA/AF5Afb/////
////xgDyAN7/////////wAAKAej///9LBgAAwgAGAej/////////wgAKAej/////////wwAKAej/
////////xAAGAej/////////xAAKAej/////////xgACAef///9hBgAAxQAGAej///9pBgAAxQAK
Aej///8lBgAAwAAeAef/////////xgAGAeL/////////wAAiAef/////////wQAiAef/////////
wgAeAef/////////wgAiAef/////////wwAeAef///9yBgAAAAEuAA8AAAD/////xAAeAef///8P
BgAAwwAiAef///9iBgAAxAAiAef///9jBgAAxQAeAef///8GBgAAAgEuAA8AAAD/////xgAeAeL/
////////xQAiAef///93BgAAxgAiAeL///9lBgAAxwAeAfH///9MBgAAxwAiAfH/////////AAFK
ABwAAAD//////AED+8n/////////AgFKABwAAAD/////AAFWAJf/////////wgBOAeT/////////
BAFKABwAAADiBQAAAgFWAJf///+KBgAAxABOAeT/////////BgFKAA8AAAAiBgAAxQBOAeT/////
////BAFWAJf///+MBgAAxwBOAfH/////////CAFKAA8AAAD/////wQBqAd3/////////wgBqAd3/
////////wQBuAd3/////////xgBaAez////6BQAACgFKAA8AAAD/////wgBuAd3/////////xgBe
Aez/////////AAF2AM7/////////wgByAd3/////////wQB2AVn/////////DAFKAA8AAAD/////
wgB2AVn/////////AgF2AM7/////////wwB2AVn/////////BAF2AM7/////////xQB2AVn/////
////AgHSAOT/////////BgHGABQAAAB8BgAAAgHWAOT/////////AgHaAN3/////////BAHSAOT/
////////CAHGABQAAAAMBgAABAHWAOT/////////BAHaAN3/////////BgHSAPH///++BgAACgHG
ABQAAAANBgAABgHWAPH/////////CAHSAPH////ABgAACAHWAPH/////////CgHSAPH/////////
DAHSAPH/////////AAEKAej/////////xgD6Aef/////////AgEKAej/////////BAEKAej/////
////wAAaAmD/////////wgAaAmD///9KBgAAAgEeAef/////////xAAaAmD///9NBgAAAgEiAef/
////////BAEeAef///88BgAABAEiAef///89BgAABgEeAfH///9ABgAAxwAaAgoAAAD/////BgEi
AfH///9BBgAACAEeAfH/////////CAEiAfH///9XBgAACgEiAfH///9aBgAADAEiAfH/////////
AgFOAeT/////////BAFOAeT/////////BgFOAfH/////////CAFOAfH/////////CAFSAfH/////
////CgFOAfH/////////CgFSAfH/////////BAFuAd3/////////DAFSAfH/////////BAFyAd3/
////////BAF2AVn/////////DgF2Acn/////////+gGAHrD/////////UEsDBBQABgAIAAAAIQC0
z1gZuwAAACQBAAAsAAAAcHB0L25vdGVzTWFzdGVycy9fcmVscy9ub3Rlc01hc3RlcjEueG1sLnJl
bHOEj8EKwjAQRO+C/xD2btL2ICJNehGhV6kfENJtGmyTkESxf2+gFwuCl4WZZd/M1s17nsgLQzTO
cihpAQStcr2xmsO9ux5OQGKStpeTs8hhwQiN2O/qG04y5aM4Gh9JptjIYUzJnxmLasRZRuo82rwZ
XJhlyjJo5qV6SI2sKoojC98MEBsmaXsOoe1LIN3ic/J/thsGo/Di1HNGm35EsJR7YQbKoDFxoHR1
1lnR3BWYqNnmN/EBAAD//wMAUEsDBBQABgAIAAAAIQD5zwk5gwYAAFwbAAAUAAAAcHB0L3RoZW1l
L3RoZW1lMS54bWzsWU9v2zYUvw/YdyB0b2MndhoHdYrYsZutTRvEboceaYmWWFOiQNJJfRva44AB
w7phlwG77TBsK9ACu3SfJluHrQP6FfZISrIYy0jSBtuwxYdEIn98/9/jI3X9xqOYoUMiJOVJ26tf
rXmIJD4PaBK2vXvD/pUND0mFkwAznpC2NyPSu7H1/nvX8aaKSEwQrE/kJm57kVLp5sqK9GEYy6s8
JQnMjbmIsYJXEa4EAh8B3ZitrNZq6ysxpomHEhwD2bvjMfUJGmqS3lZOvMfgNVFSD/hMDDRp4qww
2GBS1wg5k10m0CFmbQ/4BPxoSB4pDzEsFUy0vZr5eStb11fwZraIqSVrS+v65petyxYEk1XDU4Sj
gmm932hd2ynoGwBTi7her9ft1Qt6BoB9HzS1spRpNvob9U5OswSyj4u0u7VmreHiS/TXFmRudTqd
ZiuTxRI1IPvYWMBv1NYb26sO3oAsvrmAb3S2u911B29AFr++gO9fa603XLwBRYwmkwW0dmi/n1Ev
IGPOdivhGwDfqGXwOQqioYguzWLME7Us1mL8kIs+ADSQYUUTpGYpGWMforiLGR0JqhngTYJLM3bI
lwtDmheSvqCpansfphgyYk7vzcvv37x8jt68fHb8+MXx45+Onzw5fvyjpeUs3MVJWF74+tvP/vz6
Y/TH829eP/2iGi/L+F9/+OSXnz+vBkIGzSV69eWz3148e/XVp79/97QCvi3wqAwf0phIdIccoQMe
g27GMK7kZCTOt2IYYVpesZ2EEidYc6mg31ORg74zwwxX4DrEteB9ARWkCnhz+tAReBCJqcpc7mh2
K4od4B7nrMNFpRVuaV4lMw+nSVjNXEzLuAOMD6t4d3Hi+Lc3TaF00iqS3Yg4Yu4znCgckoQopOf4
hJAKez2g1LHrHvUFl3ys0AOKOphWmmRIR040zRft0hj8MqsSEPzt2GbvPupwVqX1Djl0kZAVmFUI
PyTMMeNNPFU4riI5xDErG/w2VlGVkIOZ8Mu4nlTg6ZAwjnoBkbJqzV0B+pacfguqR7Xb99gsdpFC
0UkVzduY8zJyh0+6EY7TKuyAJlEZ+4GcQIhitM9VFXyPuxmi38EPOFnq7vuUOO4+vRrco6Ej0jxA
9MxUaF9CtXaKcEyTy4p85oq8LWhlSuyeqMPLcCerb5eLgP77i+8Onib7BOJ9cQe6rL2Xtdf7z9fe
Zfl81oo7L7JQf3WfYxtk0y7HS7vlMWVsoGaM3JamYZawYQR9GNTrzEmRFKenNILHrMA7uFBgswYJ
rj6iKhpEOIVmu+5pIqHMSIcSpVzCIc8MV9LWeGjYlT0iNvXhwdYDidUeD+zwmh7OzwgFGbPthOYg
mjNa0wTOymztWkYU1H4bZnUt1Jm51Y1optQ53AqVwYeLqsFgYU3oRBD0L2DldTira9ZwSMGMBNru
dhPO3WK8cJEukhEOSOYjrfeij+rGSXmsmFsBiJ0KH+kD3ylWK3FrabLvwO0sTiqzayxhl3vvXbyU
R/DcSzpvT6QjS8rJyRJ01PZazdWmh3yctr0xnG/hMU7B61I3f5iFcEnkK2HD/tRkNlk+92YrV8xN
gjpcWVi7Lyjs1IFUSLWDZWRDw0xlIcASzcnKv9oEs16UAjbS30KKtQ0Ihn9MCrCj61oyHhNflZ1d
GtG2s69ZKeVTRcQgCo7QiE3FAQb361AFfQIq4ZrCVAT9Andq2tpmyi3OWdKVb7IMzo5jlkY4K7c6
RfNMtnCTx4UM5q0kHuhWKbtR7vyqmJS/IFXKYfw/U0XvJ3BlsBZoD/hwpSsw0vna9rhQEYcqlEbU
7wtoHEztgGiBe1mYhqCCi2XzX5BD/d/mnKVh0hpOfuqAhkhQ2I9UJAjZh7Jkou8UYvVs77IkWUbI
RFRJXJlasUfkkLChroHrem/3UAShbqpJVgYM7mT8ue9ZBo1C3eSU882pIcXea3Pg7+58bDKDUm4d
Ng1Nbv9CxIpd1a43y/O9t6yInpi3WY08K4BZaStoZWn/liKcc6u1FWtB49VmLhx4cVFjGCwaohQu
fpD+A/sfFT6zXyn0hjrkB1BbEXx00MQgbCCqr9jGA+kCaQdH0DjZQRtMmpQ1bdY6aavlm/UFd7oF
3xPG1pKdxd/nNHbRnLnsnFy8SGNnFnZsbceWmho8ezJFYWicH2SMY8znrfIXKD56CI7egbv+KVPS
BBN8XxIYWs+ByQNIfsvRLN36CwAA//8DAFBLAwQUAAYACAAAACEASTW0SXMGAABBHwAAIQAAAHBw
dC9ub3Rlc01hc3RlcnMvbm90ZXNNYXN0ZXIxLnhtbOxZ7W7bNhT9P2DvQGg/B9fWh2XZiFM4TtwW
SNugSR+AlihbCEVpFO06HQb0tbbH6ZPsXlK0bLdJ7TQr0CUIYNP8voeH517eHD1f5ZwsmayyQgwd
91nHIUzERZKJ2dB5fzVpRQ6pFBUJ5YVgQ+eGVc7z419/OSoHolCsek0rxSSBWUQ1oENnrlQ5aLer
eM5yWj0rSiagLS1kThX8lLN2IukHmD3nba/TCds5zYRTj5f7jC/SNIvZaREvciaUmUQyThVYUM2z
srKzlfvMVkpWwTR69NaWjsHC+JIn+D2dmc93LCVZsgKcOh3XOT6iA20nG3NJlpQPnenMddrHR20c
Ap3rEg6uyivJGJbE8oUsL8sLiT/iN8sLCXPClA4RNAeEcQLdUHfTPwV0MxNvDZ/ZmehglcocdwTw
ENghnOMNfsIgOmArRWJTGTe18fztV/rG87Ov9G7bBcC09aJolbHoS3M8a85LRhMgyAWnMZsXHMsa
I22iGQcwludFfF0RUYDRiIWxFdCxMyMAuFY5J+qmBJjmiQRmfhw6fyyoBArWQ0w/2KVYD6001taA
uxHy+j036gB4iFPQ7QFF9cTN6FJW6gUrcoKFoSNZrDQT6PK8UrhtOrBd9PGb1cuBWp0UyQ2exhS+
4dDh0sH4eSE/OoS/EtXQ6btBAEsr/UMv7hC52TLdalF8XADn6jPmlbpUNxwoRgd8yV0wmlA+g0vN
9f4Slr6DKkTMbayqe+ptb84A5wp2IOR0YEbWppkqJpILKilOyCkqBROt95c1UjAW8Lf2QtGw5Hau
+JYrp1SxLaZ4OOX3MiVRTn1rD+aIH0VB6ML+mltj79L/kSny4ZmS8kTL25/B+NTrTwKvNel1o1Zw
1hm1Ir87annR6YnfD/tn45H/F5BfX+4EiKCynE2y2UKytwtzxeSXdLuLpOrYdduuDx7CdfFaKs1y
2BCS+mEZHFgGX/IsYeRVTmfbRPa/TWQQv3cFKAI6gmI8h2vFRlUJ8rKfHlY8eZXPaqbre6NFEO+r
LlghvUUNXTfwOyh8wPQw6qIGwtVrXIfRwloY/cDrY2ejCdbzWNnbSxkphA+TjHO9CBfkA8pSD+bE
RasCYMRW/IHTNg4W3Mh1ve5GLzhdLrShP0BuCRUxyPbQiZX2OrB2rb3aGCudBLR1rc630A1O+kIW
RYr9SJWDnYyCYltkD1bSruXhG4zNtqQ0+DYD8Tg3xBZ96I7TRde17XWNsmp6H8S3mmNIt8CHv12+
dYMoxErjiIGdNSPXgUjjZvfiG2zuB1AD+Sog1h0tVJFmdThg/D02fZsn2uHu6txdLEFZG/Msviaq
ICzJFKkjcoWOqsKIoGrED8UAgNPXSn+goiJNdcRFB/da/pLFhUgIZ0vG91hKa9M9l7qaZ3L/lTQr
77nSpFhINd/bKH277rtUlt6xEhD3gFAqtAIwKUABtsPu7kMoQAqatxV2GwHQ9h8kAMbVRKADHgRY
Wjl/6tBq7RWmxhh71/W9/7ni8Z4lkYlm3izy6Q6VwoegEkQsMPXX2KSZehCbNgP1x8ip/zJy93rh
aT9wo1ZvHJ5A5D7ut04mYdDy+qPT8cQPzka93jpyrzAAFnCsyPtdR2bio1tfler486e/f/v86Z/G
i9w7Wtf+3qRcoGgTOTGXr2lJIE0Dz2IFkbZaQSm5htJ05mEd5C3UCkrJNZRoHENuCHrUBVsD7aZm
3ce3NfBWNE2BrYG3ganp2hqI0kxNaGtAtuc8E9eQD8Avh6QFf2kqbMncOJ1zu/WdT6TSISdh9Fyc
SJgOVDYthBrpRMCUVgwWgpcF5N8uFgKfFnXAXcYnmK7CTEx8ESuTzcIHgQ1Fob7pMUrhLbXdd6Nf
3bqbcCDXTGKKEZMPevRmkL+TR4NjQXshVtkI8iF+gjSd0E/EFLJJQ+f3XLS4MnrL6E4Do6YhrnYa
4qqe2+xQL7POg8AiS+5h8iSn8nydA1qnUp4gZg32h0KMuOLRA8R+A7FOewFRbbbqCeLvgBhxrSEO
Gohdv+eG+Jp6whhSGt+rFAhsjXF3A+PIi3Tq+AnjB8AYga0xDhuMPS8CGm/yGDT8ik4vIattZeQL
HwjOXTuOxiVuu0Dzn5yfzV0hKjVAvQ2AeoGPDra56I8WIESlBihqAEJ0dF5pfUsfLUCISg1QfwOg
sNvbdhWPFiBERadEN6NufJY2//g+/hcAAP//AwBQSwMEFAAGAAgAAAAhAN1sM0jHAQAAHQQAABEA
AABwcHQvdmlld1Byb3BzLnhtbJSTwW7iMBCG7yvtO1i+t0koGyAiVKpWe+phJdjeLWcIlhzb8rg0
8PQ7TkgJlAO9ZWY8/3z/2Fk+t41me/CorCl59phyBkbaSpm65P82fx7mnGEQphLaGij5AZA/r37+
WLpir+Djr2ckYLAQJd+F4IokQbmDRuCjdWCotrW+EYFCXyeVFx8k3OhkkqZ50ghl+Knf39Nvt1sl
4beV7w2Y0It40CIQPO6Uw0HN3aPmPCDJdN0XSCsyZyK2fustohHuDXxYO61CAGLNeFxaeBF+TQK0
l0YZ1agjVJztrD+OCqI9FaIsjQzWQ/UK28DwSEK/8knKk3FtY11XWkzzvCsllzjxLGpVQU8XQ7nW
1Sg6Ye+JTgpNdBnvmmKwWooCW0aXPVtwVlEt7YZQ9vA1S6Ox73KF9apWhrUlf8imiylnB/qaTyM8
HZPn+fU7wb1iiDO7b0attGm6FFoNZ85iySdZb2440ifn88HxWSSKj/xFpEv3xgbADbThjDCiOfEP
rqPdG7av0nHIV9/USZ4Hws8ZdPgGAlpPT+UepDy/RXSZ/S7Q9fTaq2rthKTfj0m6wtnT7IleHjmS
ZOkz6u9y3z371X8AAAD//wMAUEsDBBQABgAIAAAAIQBYm5DCqgAAAB8BAAARAAAAcHB0L3ByZXNQ
cm9wcy54bWyMjzsOwjAMQHck7hBlpykMCFX9LIiZAQ4QpW4bKXEiO/xuT8RHgq2jZb3n57q7eyeu
QGwDNnJdlFIAmtBbHBt5Ph1WOyk4aey1CwiNfADLrl0u6lhFAgZMOmX0SCKLkCvdyCmlWCnFZgKv
uQgRMO+GQF6nPNKoetK3fMA7tSnLrfLaovzwNIcPw2AN7IO5+BzwlhC4VwlPNvLXFufYfv/4S1Lt
EwAA//8DAFBLAwQUAAYACAAAACEA2P2Nj6wAAAC2AAAAEwAAAHBwdC90YWJsZVN0eWxlcy54bWwM
zEkOgjAYQOG9iXdo/n0tQ1EkFMIgK3fqASqUIelAaKMS491l+fKSL80/SqKXWOxkNAP/4AESujXd
pAcGj3uDY0DWcd1xabRgsAoLebbfpTxxT3lzqxRX69CmaJtwBqNzc0KIbUehuD2YWejt9WZR3G25
DKRb+HvTlSSB5x2J4pMG1ImewTeqgiCitMCny+WIaUgDXHo0xnFU1tW5qf0qLH5Asj8AAAD//wMA
UEsDBBQABgAIAAAAIQC1uaryOgIAAOoEAAAQAAgBZG9jUHJvcHMvYXBwLnhtbCCiBAEooAABAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJxUTW8aMRC9V+p/sPbUHsICpWmKjFFKFFGpBCQ26dn1
DmDVa1v2QEJ/fWd3YbMUVKnl9GbeMB9vZ8zHL4VhOwhROztKep1uwsAql2u7HiWP2f3VTcIiSptL
4yyMkj3EZCzevuGL4DwE1BAZpbBxlGwQ/TBNo9pAIWOHaEvMyoVCIplhnbrVSiu4c2pbgMW03+1e
p/CCYHPIr3yTMKkzDnf4v0lzp8r+4lO299Sw4BkU3kgEwdNXmDmUJtMFiJvPn4hoTP7dhTyKfrfP
0xryW++NVhJJJjHTKrjoVsjm1UBs4Z4hLJy2yNN2IIkEkSat/nZfCSHm9iqqAGDZcuOe2bvB8MN7
nl4I5AsZ5DpIv4liQO21TL40OocoPvL0gPiDQ3IMeFoDPtV5DvbAdnl6YvPZbGK0j4KII+RLJQ1M
SDWxkiYCpW4cfAqy3IiF1CEKvsPhDhS6wKL+RTsxSNgPGaHUepTsZNDSImlehtVGhY2PGERGy0G5
iavtCrbD2lgPRK8KIPDXwDpXNS3LNBqI/1CCVKR2zkqUznpMqn0qQF1ivqJPghf0uG7rUbVWq1F3
ediZMyEaSZagtkHjnn1xDkkz6T1p3x6oCb0NaqORvsU2nIjaBNAVoFPOnOjRsJMNDQCBfUUoLuZ/
oOtkSwQfx23+RJo/xPim7c/46DN3V57bYZVOnXxJdSGnd+DIvzr4lLYomDIJdWfXkB9jzonyKJ/q
p0v0+p0u/ar7O/rKszo+UuI3AAAA//8DAFBLAwQUAAYACAAAACEAHDKc2H8BAACxAgAAEQAIAWRv
Y1Byb3BzL2NvcmUueG1sIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAfJJPb+Mg
EMXvK+13sLj05ABO+kfIIVK6ymmrrtRUrXpDME1QbEAw29TfvthJ3FS7qsQF3psfbwbqxXvbFG8Q
k/VuTviEkQKc9sa6zZw8rlflDSkSKmdU4x3MSQeJLOTPH7UOQvsIf6IPENFCKjLJJaHDnGwRg6A0
6S20Kk2yw2Xx1cdWYd7GDQ1K79QGaMXYFW0BlVGoaA8sw0gkR6TRIzL8jc0AMJpCAy04TJRPOP30
IsQ2/bdgUM6crcUu5J6Occ/ZRh/E0f2e7Gjc7/eT/XSIkfNz+nz3+2FotbSun5UGImujBVpsQC69
x4RRhZBnWtPxvHfoCAp9lLe+sa64v1g1nXOD56T0c25Uwrv8JK8WzLKTDyranerUErYasLieXl3O
avqvry+N8Gb7p5UVHyzjPt8+jOMQAUyRGxSHcZyUp+ntr/WKyIpxVrJpWfE1Z+KSiermpc/4pb5v
+HDQHpN+T+Qlz2u2ZlzMrgVnZ8QTQA6Jv34y+QEAAP//AwBQSwMEFAAGAAgAAAAhAIxO8Gn2AAAA
bAEAABMACAFkb2NQcm9wcy9jdXN0b20ueG1sIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAnJDLboMwEEX3lfoPlveOjRFpjAxRAsm6i7R7yxiChB+yHVpU9d9rlD72Xc7c0Zkzw/fv
egKz8mG0poLZhkCgjLTdaIYKvlzOaAdBiMJ0YrJGVXBRAe7rxwf+7K1TPo4qgIQwoYLXGF2JcZBX
pUXYpNikpLdei5hKP2Db96NUrZU3rUzElJAtlrcQrUbuFwfvvHKO/0V2Vq524fWyuKRb82/4Anod
x66CH23RtG1BCkRPrEEZyY6I5ewJkR0h9EibMzucPiFw6zCFwAidTg/9JIZEm2M5ubcQfZ3lNKN5
vmWU478uxz/7ao5Xkfub6i8AAAD//wMAUEsBAi0AFAAGAAgAAAAhAONkVvNsAgAAFRIAABMAAAAA
AAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAR78a0BMBAAB1
AwAACwAAAAAAAAAAAAAAAAClBAAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEA2AOCa9cAAADO
AQAAIAAAAAAAAAAAAAAAAADpBwAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTEueG1sLnJlbHNQSwEC
LQAUAAYACAAAACEAI/NwpNcAAADOAQAAIAAAAAAAAAAAAAAAAAD+CAAAcHB0L3NsaWRlcy9fcmVs
cy9zbGlkZTIueG1sLnJlbHNQSwECLQAUAAYACAAAACEAxEbZUNkAAADOAQAAIAAAAAAAAAAAAAAA
AAATCgAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTQueG1sLnJlbHNQSwECLQAUAAYACAAAACEAywhz
N0wBAAB9BgAAHwAAAAAAAAAAAAAAAAAqCwAAcHB0L19yZWxzL3ByZXNlbnRhdGlvbi54bWwucmVs
c1BLAQItABQABgAIAAAAIQBL9T3svwAAADcBAAAgAAAAAAAAAAAAAAAAALsNAABwcHQvc2xpZGVz
L19yZWxzL3NsaWRlNS54bWwucmVsc1BLAQItABQABgAIAAAAIQCtOQRg2QAAAM4BAAAgAAAAAAAA
AAAAAAAAALgOAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlMy54bWwucmVsc1BLAQItABQABgAIAAAA
IQBykoSAtwIAAAkOAAAUAAAAAAAAAAAAAAAAAM8PAABwcHQvcHJlc2VudGF0aW9uLnhtbFBLAQIt
ABQABgAIAAAAIQDLUXZKzgMAAEIMAAAVAAAAAAAAAAAAAAAAALgSAABwcHQvc2xpZGVzL3NsaWRl
NC54bWxQSwECLQAUAAYACAAAACEAbR1XvVkDAAAdCgAAFQAAAAAAAAAAAAAAAAC5FgAAcHB0L3Ns
aWRlcy9zbGlkZTUueG1sUEsBAi0AFAAGAAgAAAAhANvuk1iwAwAAxwwAABUAAAAAAAAAAAAAAAAA
RRoAAHBwdC9zbGlkZXMvc2xpZGUzLnhtbFBLAQItABQABgAIAAAAIQBAB4tYaQQAAFsUAAAVAAAA
AAAAAAAAAAAAACgeAABwcHQvc2xpZGVzL3NsaWRlMi54bWxQSwECLQAUAAYACAAAACEAIEaq1+kF
AACHEgAAFQAAAAAAAAAAAAAAAADEIgAAcHB0L3NsaWRlcy9zbGlkZTEueG1sUEsBAi0AFAAGAAgA
AAAhAJKNtjN2AwAA0wsAACEAAAAAAAAAAAAAAAAA4CgAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVM
YXlvdXQyLnhtbFBLAQItABQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAAAAAAAAAAAAAAJUsAABw
cHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0NC54bWwucmVsc1BLAQItABQABgAIAAAA
IQDV0ZLxvgAAADcBAAAsAAAAAAAAAAAAAAAAAJ0tAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3Ns
aWRlTGF5b3V0My54bWwucmVsc1BLAQItABQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAAAAAAAAA
AAAAAKUuAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0Mi54bWwucmVsc1BLAQIt
ABQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAAAAAAAAAAAAAAK0vAABwcHQvc2xpZGVMYXlvdXRz
L19yZWxzL3NsaWRlTGF5b3V0MS54bWwucmVsc1BLAQItABQABgAIAAAAIQCei5GAVgQAAEIRAAAh
AAAAAAAAAAAAAAAAALUwAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0MS54bWxQSwECLQAU
AAYACAAAACEAFzztatUAAAC/AQAAKgAAAAAAAAAAAAAAAABKNQAAcHB0L25vdGVzU2xpZGVzL19y
ZWxzL25vdGVzU2xpZGUzLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAGmiXyEeAQAAxwcAACwAAAAA
AAAAAAAAAAAAZzYAAHBwdC9zbGlkZU1hc3RlcnMvX3JlbHMvc2xpZGVNYXN0ZXIxLnhtbC5yZWxz
UEsBAi0AFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAAAAAAAAAAAAAAAAzzcAAHBwdC9zbGlkZUxh
eW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ2LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhANXRkvG+AAAA
NwEAACwAAAAAAAAAAAAAAAAA1zgAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ3
LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAJn2ma7VAAAAvwEAACoAAAAAAAAAAAAAAAAA3zkAAHBw
dC9ub3Rlc1NsaWRlcy9fcmVscy9ub3Rlc1NsaWRlMi54bWwucmVsc1BLAQItABQABgAIAAAAIQBK
r3U51AAAAL8BAAAqAAAAAAAAAAAAAAAAAPw6AABwcHQvbm90ZXNTbGlkZXMvX3JlbHMvbm90ZXNT
bGlkZTEueG1sLnJlbHNQSwECLQAUAAYACAAAACEA1dGS8b4AAAA3AQAALQAAAAAAAAAAAAAAAAAY
PAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDExLnhtbC5yZWxzUEsBAi0AFAAG
AAgAAAAhANXRkvG+AAAANwEAAC0AAAAAAAAAAAAAAAAAIT0AAHBwdC9zbGlkZUxheW91dHMvX3Jl
bHMvc2xpZGVMYXlvdXQxMC54bWwucmVsc1BLAQItABQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAA
AAAAAAAAAAAAACo+AABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0OS54bWwucmVs
c1BLAQItABQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAAAAAAAAAAAAAADI/AABwcHQvc2xpZGVM
YXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0OC54bWwucmVsc1BLAQItABQABgAIAAAAIQDV0ZLxvgAA
ADcBAAAsAAAAAAAAAAAAAAAAADpAAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0
NS54bWwucmVsc1BLAQItABQABgAIAAAAIQCyw9jf6AgAAJc6AAAhAAAAAAAAAAAAAAAAAEJBAABw
cHQvc2xpZGVNYXN0ZXJzL3NsaWRlTWFzdGVyMS54bWxQSwECLQAUAAYACAAAACEA+VzO/6UEAACW
EQAAIQAAAAAAAAAAAAAAAABpSgAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDMueG1sUEsB
Ai0AFAAGAAgAAAAhAH5DMFrVAAAAvwEAACoAAAAAAAAAAAAAAAAATU8AAHBwdC9ub3Rlc1NsaWRl
cy9fcmVscy9ub3Rlc1NsaWRlNC54bWwucmVsc1BLAQItABQABgAIAAAAIQBbrP4ZBQUAAP8SAAAh
AAAAAAAAAAAAAAAAAGpQAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0OC54bWxQSwECLQAU
AAYACAAAACEAKEP/ksYCAACkBwAAIQAAAAAAAAAAAAAAAACuVQAAcHB0L3NsaWRlTGF5b3V0cy9z
bGlkZUxheW91dDcueG1sUEsBAi0AFAAGAAgAAAAhAA2yd/MFAwAA9ggAACEAAAAAAAAAAAAAAAAA
s1gAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQ2LnhtbFBLAQItABQABgAIAAAAIQBQxuQP
iQUAAHQcAAAhAAAAAAAAAAAAAAAAAPdbAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0NS54
bWxQSwECLQAUAAYACAAAACEA9sQ1dkAEAAClEgAAIQAAAAAAAAAAAAAAAAC/YQAAcHB0L3NsaWRl
TGF5b3V0cy9zbGlkZUxheW91dDQueG1sUEsBAi0AFAAGAAgAAAAhAF1Cxl2RAwAACgwAACIAAAAA
AAAAAAAAAAAAPmYAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQxMC54bWxQSwECLQAUAAYA
CAAAACEAo15jz+YEAAC8EgAAIQAAAAAAAAAAAAAAAAAPagAAcHB0L3NsaWRlTGF5b3V0cy9zbGlk
ZUxheW91dDkueG1sUEsBAi0AFAAGAAgAAAAhAL/CPitvAgAA9AUAAB8AAAAAAAAAAAAAAAAANG8A
AHBwdC9ub3Rlc1NsaWRlcy9ub3Rlc1NsaWRlNC54bWxQSwECLQAUAAYACAAAACEAXSlsJSgDAABG
CAAAHwAAAAAAAAAAAAAAAADgcQAAcHB0L25vdGVzU2xpZGVzL25vdGVzU2xpZGUzLnhtbFBLAQIt
ABQABgAIAAAAIQBYmrHOJgMAAEYIAAAfAAAAAAAAAAAAAAAAAEV1AABwcHQvbm90ZXNTbGlkZXMv
bm90ZXNTbGlkZTIueG1sUEsBAi0AFAAGAAgAAAAhALhNjmAlAwAARggAAB8AAAAAAAAAAAAAAAAA
qHgAAHBwdC9ub3Rlc1NsaWRlcy9ub3Rlc1NsaWRlMS54bWxQSwECLQAUAAYACAAAACEAavw4g9UD
AADqDAAAIgAAAAAAAAAAAAAAAAAKfAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDExLnht
bFBLAQItABQABgAIAAAAIQD5zwk5gwYAAFwbAAAUAAAAAAAAAAAAAAAAAB+AAABwcHQvdGhlbWUv
dGhlbWUyLnhtbFBLAQItAAoAAAAAAAAAIQBpqiHCAFQAAABUAAAXAAAAAAAAAAAAAAAAANSGAABk
b2NQcm9wcy90aHVtYm5haWwuanBlZ1BLAQItABQABgAIAAAAIQC0z1gZuwAAACQBAAAsAAAAAAAA
AAAAAAAAAAnbAABwcHQvbm90ZXNNYXN0ZXJzL19yZWxzL25vdGVzTWFzdGVyMS54bWwucmVsc1BL
AQItABQABgAIAAAAIQD5zwk5gwYAAFwbAAAUAAAAAAAAAAAAAAAAAA7cAABwcHQvdGhlbWUvdGhl
bWUxLnhtbFBLAQItABQABgAIAAAAIQBJNbRJcwYAAEEfAAAhAAAAAAAAAAAAAAAAAMPiAABwcHQv
bm90ZXNNYXN0ZXJzL25vdGVzTWFzdGVyMS54bWxQSwECLQAUAAYACAAAACEA3WwzSMcBAAAdBAAA
EQAAAAAAAAAAAAAAAAB16QAAcHB0L3ZpZXdQcm9wcy54bWxQSwECLQAUAAYACAAAACEAWJuQwqoA
AAAfAQAAEQAAAAAAAAAAAAAAAABr6wAAcHB0L3ByZXNQcm9wcy54bWxQSwECLQAUAAYACAAAACEA
2P2Nj6wAAAC2AAAAEwAAAAAAAAAAAAAAAABE7AAAcHB0L3RhYmxlU3R5bGVzLnhtbFBLAQItABQA
BgAIAAAAIQC1uaryOgIAAOoEAAAQAAAAAAAAAAAAAAAAACHtAABkb2NQcm9wcy9hcHAueG1sUEsB
Ai0AFAAGAAgAAAAhABwynNh/AQAAsQIAABEAAAAAAAAAAAAAAAAAkfAAAGRvY1Byb3BzL2NvcmUu
eG1sUEsBAi0AFAAGAAgAAAAhAIxO8Gn2AAAAbAEAABMAAAAAAAAAAAAAAAAAR/MAAGRvY1Byb3Bz
L2N1c3RvbS54bWxQSwUGAAAAADkAOQBREQAAdvUAAAAA
--e89a8f5033861d45f104b1a81a58--

From internet-drafts@ietf.org  Sun Nov 13 17:52:04 2011
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 DB58511E80DE; Sun, 13 Nov 2011 17:52:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.539
X-Spam-Level: 
X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 Wl5InPZ-PVpW; Sun, 13 Nov 2011 17:52:04 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6735121F84A5; Sun, 13 Nov 2011 17:52:04 -0800 (PST)
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: 3.63
Message-ID: <20111114015204.16502.69696.idtracker@ietfa.amsl.com>
Date: Sun, 13 Nov 2011 17:52:04 -0800
Cc: core@ietf.org
Subject: [core] I-D Action: draft-ietf-core-link-format-08.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, 14 Nov 2011 01:52:05 -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 Work=
ing Group of the IETF.

	Title           : CoRE Link Format
	Author(s)       : Zach Shelby
	Filename        : draft-ietf-core-link-format-08.txt
	Pages           : 19
	Date            : 2011-11-13

   This document defines Web Linking using a link format for use by
   constrained web servers to describe hosted resources, their
   attributes and other relationships between links.  Based on the HTTP
   Link Header format defined in RFC5988, the CoRE Link Format is
   carried as a payload and is assigned an Internet media type.  A well-
   known URI is defined as a default entry-point for requesting the
   links hosted by a server.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-core-link-format-08.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-core-link-format-08.txt

From tho@koanlogic.com  Mon Nov 14 09:11:11 2011
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 9637921F8D62 for ; Mon, 14 Nov 2011 09:11:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.505
X-Spam-Level: *
X-Spam-Status: No, score=1.505 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553,  IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, SARE_RECV_IP_069060096=1.666]
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 Opy9QcCyPfDI for ; Mon, 14 Nov 2011 09:11:11 -0800 (PST)
Received: from gonzo.koanlogic.com (unknown [69.60.118.166]) by ietfa.amsl.com (Postfix) with ESMTP id F1CD921F8D5D for ; Mon, 14 Nov 2011 09:11:10 -0800 (PST)
Received: from host25-53-dynamic.2-79-r.retail.telecomitalia.it ([79.2.53.25]:51866 helo=[192.168.0.2]) by gonzo.koanlogic.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1RQ03i-0005ac-MX for core@ietf.org; Mon, 14 Nov 2011 12:11:09 -0500
From: Thomas Fossati 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Mon, 14 Nov 2011 18:10:29 +0100
Message-Id: <1F3159DC-1BC2-4AA2-A4F1-981AF757893F@koanlogic.com>
To: core@ietf.org
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
X-SA-Exim-Connect-IP: 79.2.53.25
X-SA-Exim-Mail-From: tho@koanlogic.com
X-Spam-DCC: : 
X-Spam-Pyzor: Reported 0 times.
X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100)
X-SA-Exim-Scanned: Yes (on gonzo.koanlogic.com)
Subject: [core] Some comments on draft-lynn-core-discovery-mapping-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, 14 Nov 2011 17:11:11 -0000

Hi Kerry and Zach,

I've read with much interest your draft on RD to DNS-SD mapping, and =
collected some comments and questions that I'd like to share.

* Section 1.4
- Perhaps being a little more informative on the dynamics of DNS-SD =
could be valuable for the casual reader, since going through Cheshire's =
draft can be a lengthy (though edifying) experience
- When you say "The SRV record contains the host name (AAAA record =
name)" should be "AAAA or A record" (i.e. CoAP over IPv4), right ?

* Section 2.1
- When you say "to the extent that the "ins" attribute may be chosen to =
match the DNS host name of a service", you mean that we may end up =
having duplicate hostname information in both {Instance} and the =
corresponding SRV record like this: "XXYYZZ._coap._udp SRV 0 0 5683 =
XXYYZZ" ?

* Section 2.2
- s/stings/strings/

* Section 2.3
- The {Domain} mapping is likely to be a policy issue WRT the DNS zone =
configuration.  It may as well be some default value that all imported =
services inherit -- i.e. the (sub)domain where the records are pushed -- =
or a function of some parameters (e.g. ct) of the resources involved in =
the RD->DNS-SD export.  I don't think that we need to specify a method, =
since every deployment may have to implement its own logics.


An overall comment that I'd like to do is that the RD->DNS-SD export =
mechanism is quite generic, and may be used to map to a different URI =
scheme than 'coap' (e.g. 'http').  In this regard, I suspect that the =
terminating "_udp" constraint on the {Service} labels is artificially =
limiting.  In fact, I'm playing with these same mapping mechanisms in =
the context of a HTTP-CoAP gateway and I find very useful to let my =
homenet (e.g. browsers) know about the things that are exported as HTTP =
services (_http._tcp) by the gateway.

Thank you very much for your effort.=

From cabo@tzi.org  Mon Nov 14 21:43:00 2011
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 4DF0511E80C4; Mon, 14 Nov 2011 21:43:00 -0800 (PST)
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 UiNNimxzSOLL; Mon, 14 Nov 2011 21:42:58 -0800 (PST)
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 66C6A11E8098; Mon, 14 Nov 2011 21:42:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id pAF5gmN5015023; Tue, 15 Nov 2011 06:42:48 +0100 (CET)
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 23ADDC8D; Tue, 15 Nov 2011 06:42:45 +0100 (CET)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Apple Message framework v1251.1)
From: Carsten Bormann 
Date: Tue, 15 Nov 2011 13:42:39 +0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <72211CB7-0790-4F0B-A47D-40BFD83EEA81@tzi.org>
To: 6lowpan <6lowpan@ietf.org>, roll@ietf.org, core WG , lwip@ietf.org
X-Mailer: Apple Mail (2.1251.1)
Subject: [core] Cross-layer issues in Constrained Node/Networks: informal get-together
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: 6lowpan <6lowpan@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, 15 Nov 2011 05:43:00 -0000

Our WGs (6LoWPAN/ROLL/CoRE/LWIG) are about making IP work well on
constrained node/network environments.  A number of issues in this
space are cross-layer (or at least cross-WG) in nature.  While these
are a constant topic in the hallways, maybe we can make more progress
by getting a group of people in one room.

We are going to have an informal get-together to discuss some of these
issues at

       Thu, 1740-1940, room 102

While the room maybe is not optimal for an informal discussion (and
the overlap with TLS is unfortunate for some of us), it does enable
use of the projector -- and it was available now that the LISP WG
meeting is canceled.

I'm going to try to get some structure into the discussion.
The following items have been mentioned as possible subjects (drafts
are mentioned as potential background material):

0 -- implications of 802.15.4g, 802.15.4e on 6LoWPAN
   is there anything we need to do/should be doing to make 6LoWPAN
   more useful with these new/extended link layers in the 802.15.4
   space?  Anything beyond the adaptation layer?  What about
   security/key management?
   Also: other links, e.g. 6LoWPAN for Bluetooth-Low-Energy
   draft-ietf-6lowpan-btle-03.txt
   (We had a nice lunch discussion in a small group today, so we are
   already mostly done with the basic work on this topic) e.g., what
   are the interactions of the Bluetooth security protocols/attribute
   protocol and the things we are doing on the IP side?
1 -- 6LoWPAN-GHC and its application to ROLL, SenML and other protocols
   draft-bormann-6lowpan-ghc-03.txt
   draft-goyal-6lowpan-rpl-compression-00.txt
   draft-goyal-roll-rpl-compression-00.txt
   draft-jennings-senml-07.txt
   Any other protocols that would benefit significantly from
   6LoWPAN-GHC?
2 -- Cross-Layer implications of the CoRE discovery discussion
   Discover of servers, services, and resources sometimes interacts
   with discovery of network elements like proxies, routers, networks.
   http://tools.ietf.org/html/draft-brandt-coap-subnet-discovery-00
   Is there a useful overlap between application layer discovery and
   network layer autoconfiguration?
   Related: 6LoWPAN vs. HOMENET
   What are the implications of the HOMENET architecture document and
   technical proposals on the typical deployment of 6LoWPANs for home
   automation applications?  (Implications on discovery?)
3 -- LWIG
   draft-bormann-lwig-guidance-00.txt
   what can we do to discuss APIs in a meaningful way here?
   what else should be in this document?
4 -- extensions for industrial applications of 6LoWPAN
   draft-wang-6lowpan-scheduling-requirements-00.txt
   Are there solutions that could be implemented in 6LoWPAN that solve
   some of these requirements?
   Is it even useful to discuss industrial applications outside of the
   system standards ISA100.11a/Wireless-HART/WIA-PA (i.e., is there a
   "pure IPv6" space waiting to be explored)?
5 -- network management for constrained node/networks
   What is the best place to bring the various efforts together?
   Should we be doing the bigger picture in the IETF NMRG?

This is a lot of items, and we won't cover all of them in these two
hours, but maybe we can at least make interested people known to each
other and spin off further hallway discussions.

Maybe we can go through the items in this sequence (i.e., =E2=89=A4 10 =
minutes
per number) in the first hour and then revisit points that merit more
discussion.  If you want to make a more structured contribution to, or
lead, any one of these points, please tell me (and send a slide or two,=20=

if useful).

Gruesse, Carsten

PS.: To be redundantly clear, let me add this Disclaimer: This is not
a BOF, not even a Bar-BOF.  It is not about drumming up support for
some potential work.  Just about technical discussion.  No intent to
forcibly draw in ADs...

PPS.: I have attempted to set a reply-to to 6lowpan.  Feel free to
answer to *one* of the WGs.  Please don't spam all four.


From tho@koanlogic.com  Mon Nov 14 23:44:55 2011
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 D0B6D11E81E5 for ; Mon, 14 Nov 2011 23:44:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.505
X-Spam-Level: *
X-Spam-Status: No, score=1.505 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553,  IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, SARE_RECV_IP_069060096=1.666]
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 A7cI2ddQfdq1 for ; Mon, 14 Nov 2011 23:44:55 -0800 (PST)
Received: from gonzo.koanlogic.com (unknown [69.60.118.166]) by ietfa.amsl.com (Postfix) with ESMTP id 6A50A11E8096 for ; Mon, 14 Nov 2011 23:44:55 -0800 (PST)
Received: from host56-54-dynamic.52-79-r.retail.telecomitalia.it ([79.52.54.56]:53711 helo=t.homenet.telecomitalia.it) by gonzo.koanlogic.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1RQDhG-0006cx-BG for core@ietf.org; Tue, 15 Nov 2011 02:44:54 -0500
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1084)
From: Thomas Fossati 
In-Reply-To: <72211CB7-0790-4F0B-A47D-40BFD83EEA81@tzi.org>
Date: Tue, 15 Nov 2011 08:44:12 +0100
Content-Transfer-Encoding: 7bit
Message-Id: 
References: <72211CB7-0790-4F0B-A47D-40BFD83EEA81@tzi.org>
To: core WG 
X-Mailer: Apple Mail (2.1084)
X-SA-Exim-Connect-IP: 79.52.54.56
X-SA-Exim-Mail-From: tho@koanlogic.com
X-Spam-DCC: : 
X-Spam-Pyzor: Reported 0 times.
X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100)
X-SA-Exim-Scanned: Yes (on gonzo.koanlogic.com)
Subject: Re: [core] Cross-layer issues in Constrained Node/Networks: informal get-together
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, 15 Nov 2011 07:44:55 -0000

Hi Carsten,

On Nov 15, 2011, at 6:42 AM, Carsten Bormann wrote:
> We are going to have an informal get-together to discuss some of these
> issues at
> 
>       Thu, 1740-1940, room 102
> 
> While the room maybe is not optimal for an informal discussion (and
> the overlap with TLS is unfortunate for some of us), it does enable
> use of the projector -- and it was available now that the LISP WG
> meeting is canceled.

is there any chance to get at least the audio streaming of the meeting ?

That'd be very nice to the rest of us that could not get to Taipei.

Thanks.

From angelo.castellani@gmail.com  Mon Nov 14 23:46:56 2011
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 C594811E8220 for ; Mon, 14 Nov 2011 23:46:56 -0800 (PST)
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 b4fFByIlh+Rd for ; Mon, 14 Nov 2011 23:46:56 -0800 (PST)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id F3F2211E8209 for ; Mon, 14 Nov 2011 23:46:55 -0800 (PST)
Received: by wyf28 with SMTP id 28so5569586wyf.31 for ; Mon, 14 Nov 2011 23:46:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=VC5riql+R8HHnK4Eoq2WkHZ0kvKJlRyzcST+LPUmALE=; b=NU6D1rZ1veX+6HBKdJOnSA1sd4W5hRzTeGQ6vdI1CtwO7S2wIzx03JwPqkGASQYCDK Oj+t3L9jJZmCO9cBEQkh+/P0nYkTNg6yCyTFZDwRjMf9mC6fmAPEp1PSEbCMDUbRPuiR phbwU9yoeoxG6L5zHbUfmCwV57RPYDtyRQjaA=
Received: by 10.216.221.36 with SMTP id q36mr4558729wep.33.1321343215072; Mon, 14 Nov 2011 23:46:55 -0800 (PST)
MIME-Version: 1.0
Sender: angelo.castellani@gmail.com
Received: by 10.216.62.8 with HTTP; Mon, 14 Nov 2011 23:46:14 -0800 (PST)
In-Reply-To: 
References: <72211CB7-0790-4F0B-A47D-40BFD83EEA81@tzi.org> 
From: "Angelo P. Castellani" 
Date: Tue, 15 Nov 2011 08:46:14 +0100
X-Google-Sender-Auth: 4tIjV3jSX7uQ2KCHyLlqpRSzqPE
Message-ID: 
To: Thomas Fossati 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: core WG 
Subject: Re: [core] Cross-layer issues in Constrained Node/Networks: informal get-together
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, 15 Nov 2011 07:46:56 -0000

+1

On Tue, Nov 15, 2011 at 08:44, Thomas Fossati  wrote:
> Hi Carsten,
>
> On Nov 15, 2011, at 6:42 AM, Carsten Bormann wrote:
>> We are going to have an informal get-together to discuss some of these
>> issues at
>>
>> =C2=A0 =C2=A0 =C2=A0 Thu, 1740-1940, room 102
>>
>> While the room maybe is not optimal for an informal discussion (and
>> the overlap with TLS is unfortunate for some of us), it does enable
>> use of the projector -- and it was available now that the LISP WG
>> meeting is canceled.
>
> is there any chance to get at least the audio streaming of the meeting ?
>
> That'd be very nice to the rest of us that could not get to Taipei.
>
> Thanks.
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>

From alper.yegin@yegin.org  Tue Nov 15 00:06:10 2011
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 D849111E80AE for ; Tue, 15 Nov 2011 00:06:09 -0800 (PST)
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.001, 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 2j5IKiI-8dU0 for ; Tue, 15 Nov 2011 00:06:09 -0800 (PST)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 411AC11E8085 for ; Tue, 15 Nov 2011 00:06:09 -0800 (PST)
Received: from [10.1.1.2] (odakk1.odakk.com [78.111.98.194]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0LrM1s-1Qlkun2PN6-013BzZ; Tue, 15 Nov 2011 03:06:08 -0500
From: Alper Yegin 
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: multipart/alternative; boundary="Apple-Mail=_CC397BCB-772A-4881-ADB5-8330E5C6F074"
Date: Tue, 15 Nov 2011 10:06:01 +0200
In-Reply-To: <72211CB7-0790-4F0B-A47D-40BFD83EEA81@tzi.org>
To: core WG 
References: <72211CB7-0790-4F0B-A47D-40BFD83EEA81@tzi.org>
Message-Id: <43EB8C04-7878-4469-8856-9F0F6612A3BE@yegin.org>
X-Mailer: Apple Mail (2.1244.3)
X-Provags-ID: V02:K0:+OINtzK40AmpqDobpP/9iQam/vmpOQBniymeAt1XZwN tRjTl0lgBmfREKpE43f/phN5VJtLJGWAHMXbJSIsTvyT+wft2O ULE8Vvoyp19P74CbV0Gizcp3YAMJco6ivg1RHKHNS/JZBTdR8d BitnrlWMEsE98yEcFCsJH+tRY9SPCKoRt2wQY45ujNrLFgwMRC eNqDdqI9Y7NkDPWF4QNIa9bsA2onY9DJd25JrWuJdwYTyKxWcu 1haOAWcI03af6/kUN91DaDJOPTfpf6ZKgxEOjJbWugoME59qNa M9BIOWtzLUN4J4zfK8huSGtWsquzyW970oV9oW+gNtODQqmSnS eYBtihGJk/19Ps5o0iuNt4VnxFns59fb4MeUN6BfT
Subject: Re: [core] [6lowpan] Cross-layer issues in Constrained Node/Networks: informal get-together
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, 15 Nov 2011 08:06:10 -0000

--Apple-Mail=_CC397BCB-772A-4881-ADB5-8330E5C6F074
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi Carsten,

On Nov 15, 2011, at 7:42 AM, Carsten Bormann wrote:

>=20
> 0 -- implications of 802.15.4g, 802.15.4e on 6LoWPAN
>   is there anything we need to do/should be doing to make 6LoWPAN
>   more useful with these new/extended link layers in the 802.15.4
>   space?  Anything beyond the adaptation layer?  What about
>   security/key management?
>   Also: other links, e.g. 6LoWPAN for Bluetooth-Low-Energy
>   draft-ietf-6lowpan-btle-03.txt
>   (We had a nice lunch discussion in a small group today, so we are
>   already mostly done with the basic work on this topic) e.g., what


It'd be very useful if you share findings/notes from that lunch meeting =
either over the ML or at the informal get-together.

Thanks.

Alper



>   are the interactions of the Bluetooth security protocols/attribute
>   protocol and the things we are doing on the IP side?




--Apple-Mail=_CC397BCB-772A-4881-ADB5-8330E5C6F074
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

Hi =
Carsten,

On Nov 15, 2011, at 7:42 AM, Carsten Bormann =
wrote:


0 -- =
implications of 802.15.4g, 802.15.4e on 6LoWPAN
   is there =
anything we need to do/should be doing to make 6LoWPAN
 =
  more useful with these new/extended link layers in the =
802.15.4
   space?  Anything beyond the adaptation =
layer?  What about
   security/key management?
 =
  Also: other links, e.g. 6LoWPAN for Bluetooth-Low-Energy
 =
  draft-ietf-6lowpan-btle-03.txt
   (We had a =
nice lunch discussion in a small group today, so we are
 =
  already mostly done with the basic work on this topic) e.g., =
what
 


It'd be =
very useful if you share findings/notes from that lunch meeting either =
over the ML or at the informal =
get-together.

Thanks.

Al=
per



  are the interactions of the Bluetooth =
security protocols/attribute
   protocol and the things we =
are doing on the IP =
side?



=

--Apple-Mail=_CC397BCB-772A-4881-ADB5-8330E5C6F074--

From cabo@tzi.org  Tue Nov 15 00:30:01 2011
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 A552C21F8D79 for ; Tue, 15 Nov 2011 00:30:01 -0800 (PST)
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 z0kvl4an-Ybz for ; Tue, 15 Nov 2011 00:30:01 -0800 (PST)
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 BD9E521F8D5A for ; Tue, 15 Nov 2011 00:30:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id pAF8Tpib005382; Tue, 15 Nov 2011 09:29:51 +0100 (CET)
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 D7148D1F; Tue, 15 Nov 2011 09:29:49 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann 
In-Reply-To: 
Date: Tue, 15 Nov 2011 16:29:42 +0800
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <72211CB7-0790-4F0B-A47D-40BFD83EEA81@tzi.org> 
To: Thomas Fossati 
X-Mailer: Apple Mail (2.1251.1)
Cc: core WG 
Subject: Re: [core] Cross-layer issues in Constrained Node/Networks: informal get-together
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, 15 Nov 2011 08:30:02 -0000

On Nov 15, 2011, at 15:44, Thomas Fossati wrote:

> is there any chance to get at least the audio streaming of the meeting =
?

Well, this is more of a brainstorming gathering, and I'm not sure I want =
to enforce religious use of the microphone.

I think the stream from room 102 should work in principle, so if you go =
to http://ietf82streaming.dnsalias.net/ietf/ietf825.m3u you should have =
a good chance of hearing faint voices arguing in the background noise.  =
We also can try to have a jabber monitor (probably not a "jabber =
scribe", though).

Gr=FC=DFe, Carsten


From cabo@tzi.org  Tue Nov 15 00:35:12 2011
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 2114C21F8DEE for ; Tue, 15 Nov 2011 00:35:12 -0800 (PST)
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 68ftSWh4oHJZ for ; Tue, 15 Nov 2011 00:35:11 -0800 (PST)
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 5677E21F8DED for ; Tue, 15 Nov 2011 00:35:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id pAF8Z3Qj012241; Tue, 15 Nov 2011 09:35:03 +0100 (CET)
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 880C6D27; Tue, 15 Nov 2011 09:35:01 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann 
In-Reply-To: <43EB8C04-7878-4469-8856-9F0F6612A3BE@yegin.org>
Date: Tue, 15 Nov 2011 16:34:57 +0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <39C536E4-6716-4C52-968E-C4F4AD1C05CB@tzi.org>
References: <72211CB7-0790-4F0B-A47D-40BFD83EEA81@tzi.org> <43EB8C04-7878-4469-8856-9F0F6612A3BE@yegin.org>
To: Alper Yegin 
X-Mailer: Apple Mail (2.1251.1)
Cc: core WG 
Subject: Re: [core] [6lowpan] Cross-layer issues in Constrained Node/Networks: informal get-together
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, 15 Nov 2011 08:35:12 -0000

On Nov 15, 2011, at 16:06, Alper Yegin wrote:

> It'd be very useful if you share findings/notes from that lunch =
meeting either over the ML or at the informal get-together.

We focused on actual adaptation layer issues (encapsulation), so this =
would be very boring.  The next version of the draft will have it.

If you are interested in the right way to do cross-layer security given =
the security that BTLE-style environments already have -- I'm too, let's =
talk.  Send in a slide or two.

(Why was this a response to core and not to 6lowpan?)

Gr=FC=DFe, Carsten


From angelo.castellani@gmail.com  Tue Nov 15 00:44:20 2011
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 D85A721F8FBF; Tue, 15 Nov 2011 00:44:20 -0800 (PST)
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 oYFUPwxl913N; Tue, 15 Nov 2011 00:44:20 -0800 (PST)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 683E921F8FC1; Tue, 15 Nov 2011 00:44:19 -0800 (PST)
Received: by wwe5 with SMTP id 5so4069940wwe.13 for ; Tue, 15 Nov 2011 00:44:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=l/VV90Z3ZVSOjeRfbwdWFjmFD4CIZM9s/KdvMib9URA=; b=XTEJgS8D6qkZNrG9deRG0j4SXt/ddxln6qxdxfk6+q2JIJeQ/8XO+mxTtoe8fpspo8 i5F/rKfbDIMsQyQWOdPKXETL07bfCHQr1rnAcT3+fwmJ+wAzKlALNNMqj2BgSqefayOj 7ZB4UKFa88g2hdzc6hTPUjbaOMdzDuaQ6hof0=
Received: by 10.216.14.206 with SMTP id d56mr238784wed.33.1321346657131; Tue, 15 Nov 2011 00:44:17 -0800 (PST)
MIME-Version: 1.0
Sender: angelo.castellani@gmail.com
Received: by 10.216.62.8 with HTTP; Tue, 15 Nov 2011 00:43:36 -0800 (PST)
In-Reply-To: 
References: <72211CB7-0790-4F0B-A47D-40BFD83EEA81@tzi.org>  
From: "Angelo P. Castellani" 
Date: Tue, 15 Nov 2011 09:43:36 +0100
X-Google-Sender-Auth: 0SyBWOqg3ArIZ9AXELR7aYn5iIg
Message-ID: 
To: Carsten Bormann 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: lwip@ietf.org, roll WG , 6lowpan@ietf.org, core WG 
Subject: Re: [core] Cross-layer issues in Constrained Node/Networks: informal get-together
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, 15 Nov 2011 08:44:21 -0000

I will enjoy hearing to your talk and even send my comments to jabber,
if will be possible for you to use the microphone on the vast majority
of time (not always as during a formal WG meeting).

If using the microphone frequently is a problem, it would be probably
better to discuss offline the results of this informal meeting.

BTW, do you plan to circulate some notes after this informal talk?

Angelo

On Tue, Nov 15, 2011 at 09:29, Carsten Bormann  wrote:
> On Nov 15, 2011, at 15:44, Thomas Fossati wrote:
>
>> is there any chance to get at least the audio streaming of the meeting ?
>
> Well, this is more of a brainstorming gathering, and I'm not sure I want =
to enforce religious use of the microphone.
>
> I think the stream from room 102 should work in principle, so if you go t=
o http://ietf82streaming.dnsalias.net/ietf/ietf825.m3u you should have a go=
od chance of hearing faint voices arguing in the background noise. =C2=A0We=
 also can try to have a jabber monitor (probably not a "jabber scribe", tho=
ugh).
>
> Gr=C3=BC=C3=9Fe, Carsten
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>

From cabo@tzi.org  Tue Nov 15 01:01:04 2011
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 474E121F8D0C for ; Tue, 15 Nov 2011 01:01:04 -0800 (PST)
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 Hqw8Ok4r6KJE for ; Tue, 15 Nov 2011 01:01:03 -0800 (PST)
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 8C04421F8D0A for ; Tue, 15 Nov 2011 01:01:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id pAF90t0C011729 for ; Tue, 15 Nov 2011 10:00:55 +0100 (CET)
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 9EEEDD68; Tue, 15 Nov 2011 10:00:54 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann 
In-Reply-To: <97F83FD9-93AC-4E44-9EFA-73D0C154EF82@tzi.org>
Date: Tue, 15 Nov 2011 17:00:50 +0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <4FFEE8C2-7378-41B1-A3E6-54DBDE5F1D1E@tzi.org>
References: <97F83FD9-93AC-4E44-9EFA-73D0C154EF82@tzi.org>
To: core WG 
X-Mailer: Apple Mail (2.1251.1)
Subject: [core] Slides, please (Re:  IETF82 CoRE agenda)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Nov 2011 09:01:04 -0000

Those who plan to present and haven't sent me your slides -- please do =
by Wed 0000 UTC (that would 0800 Taipei time).  I want to have a slide =
set out on the meeting materials site > 24 h before the meeting so the =
non-native speakers can examine them in time. Thanks.

Gr=FC=DFe, Carsten


From tho@koanlogic.com  Tue Nov 15 02:32:27 2011
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 30EA911E824F for ; Tue, 15 Nov 2011 02:32:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.005
X-Spam-Level: **
X-Spam-Status: No, score=2.005 tagged_above=-999 required=5 tests=[AWL=-0.500,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553,  IP_NOT_FRIENDLY=0.334, J_BACKHAIR_32=1, RDNS_NONE=0.1, SARE_RECV_IP_069060096=1.666]
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 H+RXWcQsRXf3 for ; Tue, 15 Nov 2011 02:32:26 -0800 (PST)
Received: from gonzo.koanlogic.com (unknown [69.60.118.166]) by ietfa.amsl.com (Postfix) with ESMTP id 9259111E824E for ; Tue, 15 Nov 2011 02:32:26 -0800 (PST)
Received: from host56-54-dynamic.52-79-r.retail.telecomitalia.it ([79.52.54.56]:54263 helo=t.homenet.telecomitalia.it) by gonzo.koanlogic.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1RQGJO-0006tG-0q; Tue, 15 Nov 2011 05:32:24 -0500
From: Thomas Fossati 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Tue, 15 Nov 2011 11:31:43 +0100
Message-Id: 
To: Zach Shelby , Kerry Lynn 
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
X-SA-Exim-Connect-IP: 79.52.54.56
X-SA-Exim-Mail-From: tho@koanlogic.com
X-Spam-DCC: : 
X-Spam-Pyzor: Reported 0 times.
X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100)
X-SA-Exim-Scanned: Yes (on gonzo.koanlogic.com)
Cc: core WG 
Subject: [core] Long-lived queries towards RD
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, 15 Nov 2011 10:32:27 -0000

Hello Zach and Kerry, still rambling about the DNS-SD / RD =
interaction...

And I was wondering whether it'd be feasible to provide a native =
mechanism to RD that, via Observe, could mimic the semantics of the =
long-lived queries that we have in DNS-SD.

This feature would be particularly nice to have for implementing an =
efficient DNS<->RD synchronization agent, and more generally to any RD =
replication (be it partial or total), or service "popup" monitoring =
mechanism -- e.g. for automatic failover of a given (critical) service.=

From zach@sensinode.com  Tue Nov 15 08:03:04 2011
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 E064D21F8AFC for ; Tue, 15 Nov 2011 08:03:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_BACKHAIR_32=1, 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 vryYUhnVtZZD for ; Tue, 15 Nov 2011 08:03:00 -0800 (PST)
Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 89C2D21F8AF1 for ; Tue, 15 Nov 2011 08:02:56 -0800 (PST)
Received: from [172.20.0.248] (203-69-99-17.HINET-IP.hinet.net [203.69.99.17] (may be forged)) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id pAFG23su018090 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 15 Nov 2011 18:02:50 +0200
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/signed; boundary=Apple-Mail-651--531614081; protocol="application/pkcs7-signature"; micalg=sha1
From: Zach Shelby 
In-Reply-To: 
Date: Wed, 16 Nov 2011 00:02:49 +0800
Message-Id: <4C5F6048-544A-447A-A293-E3F5B149B806@sensinode.com>
References: 
To: Thomas Fossati 
X-Mailer: Apple Mail (2.1084)
Cc: core WG 
Subject: Re: [core] Long-lived queries towards RD
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, 15 Nov 2011 16:03:05 -0000

--Apple-Mail-651--531614081
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Nov 15, 2011, at 6:31 PM, Thomas Fossati wrote:

> Hello Zach and Kerry, still rambling about the DNS-SD / RD =
interaction...
>=20
> And I was wondering whether it'd be feasible to provide a native =
mechanism to RD that, via Observe, could mimic the semantics of the =
long-lived queries that we have in DNS-SD.
>=20
> This feature would be particularly nice to have for implementing an =
efficient DNS<->RD synchronization agent, and more generally to any RD =
replication (be it partial or total), or service "popup" monitoring =
mechanism -- e.g. for automatic failover of a given (critical) service.

Sounds like you want to monitor the RD lookup interface for any kinds of =
changes, and then use CoAP observe to get a notification when anything =
changes, right? I agree that would be useful for lots of things.=20

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


--Apple-Mail-651--531614081
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMWTCCBWMw
ggRLoAMCAQICEHOCkw2jxZ3D/33R5ncHHbgwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT
MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg
KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g
Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTEwMTAwMDAwMDBaFw0x
MjEwMDkyMzU5NTlaMIIBEDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S
UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh
bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2
aWNlMRQwEgYDVQQDFAtaYWNoIFNoZWxieTEhMB8GCSqGSIb3DQEJARYSemFjaEBzZW5zaW5vZGUu
Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzhUEvdReCaejkXy7oHgfRykbzYKT
UVdKPk27VuoqRENDsQvOx+7PedUCyaXF1CUyzY5/QI+8lRyPEdyctsqAKTb1Pp0Bx0zgpsSHrFVb
+JTLLEI4rKJ2KogmzXar3FQow+819WT0tIC7QIwma6m6N2MpxVGXd6VGTidqshi7ZfvyDwUh1BuH
HYgn8/fgTAvCFJoLD6asYUZ/AKreqDD7lwyjPZG5AfoaXPilBzuVIGArLCcYvaWSlMpntokmU5oh
5AjZX8Wmg32rxYnCy6NCGyoQHq1iQTnleH0eUcbvG5fTGDnOs1scoHHKeZ6meyFFDAc/d2KJJ8zW
bEKU2MalcQIDAQABo4HoMIHlMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAq
MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAd
BgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwFAYKYIZIAYb4RQEGBwQGFgROb25lMFAGA1Ud
HwRJMEcwRaBDoEGGP2h0dHA6Ly9pbmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29tL0lu
ZEMxRGlnaXRhbElELUczLmNybDANBgkqhkiG9w0BAQUFAAOCAQEATFvGnK8aGE+tObyxTKI5EzlL
7RKS5iH7fQ0DIdLXNTph4XZL1kLxp3LIwsm2+UsptMhtk7nXT8sWgiH8pugbYUZQl/pZZeTbcqGb
rPpWTQg1jqXNo0nZJG1jvgGyuA4ozmSiD6frU/s58cUCwNdmPK41lunpS4KyLbgw7vQZCwrb0RGW
YkCrVds9CtncAlcHROFAuuNsgrN6GX+VEsfqw+u+eOVIMaAVKfXqfquuLp/p41HgkDC6onA2biaO
guxLuH/fAhIwSNe8TBS/bYMTF8yROSxn0mnNryhMOZTsqt4R0XEgXxyNpPIgRmrg3DgnqldFWDPn
zHHOQRx73R3fXTCCBu4wggXWoAMCAQICEHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEFBQAw
gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig
YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp
bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAwMDAwMFoXDTE5MDQz
MDIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE
CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBz
Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlk
YXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0Eg
LSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAO3ER98qKB18Bmu71yEyyWwTj+mx
jUFONPfaC+Nq+mWIIAsRE+mb4ElOi2/VAdBfDUeRilpMdD4/xpEJu0w0no1uoYJRYvdpdliWB6+e
FBgHT1q9n9IxslQZc0ZqGUIR7BJzIY313DDN5dlWCjHFNm0pFJe9LdqJRxmI2EsEPeu2PGcedAAT
DdCG2pNn+DMDrho8a2l49sAsjuGDP3f5mf/+n1JawrSHCthsqUfBVCllQz5KwJYfwa33d69ssQRe
vsG2lC2XkC0n0rse6YNqhPbEsq4jBmUmpSdYKwcitG+mYkgad/LVUCeaKdOW+yj1uiR2YuOMWev7
btVCxL5Bx/UCAwEAAaOCArkwggK1MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDov
L29jc3AudmVyaXNpZ24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkwZzBlBgtghkgB
hvhFAQcXATBWMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMCoGCCsG
AQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCegJYYj
aHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4GCCsG
AQUFBwEMBGIwYKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy70FI4
mymsSweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAuBgNVHREE
JzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4EFgQUeUdhCEH9
OASiS+e1zPVD9kkrEfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UEBhMCVVMxFzAVBgNV
BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYD
VQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUw
QwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0
aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUAA4IBAQA5Tc9BmYG1
qQW1UjjpOYSJbOQ0qFrn2GwJTCQaulmkhztzIfGTgc+/aGNaZ/41hSuhw12jSsI6Gd0w1sxN7/HS
gZfKVFpDvzeLeo4ZjQ9DqIzyr2CzFYqzlZw84J6zJ5ikNXIX5fwqXYfTig3C0UUq+MD0rCqTOtWu
EnAI6/s74nfs6CtkNXbNutrg0csU1nFYm77VPn222egkxSRmTF2RH3azFz5/DcYhiS+zN7ih/1yy
bUneZVJC+w6I0u1KHb9L4/jMcvpIDmWOScjW+JmYO7eUPjFxBof6bFlTLtffK+1fYwCsFe0DuFUW
jMZoA+ciqHMLsbyg2lJY3QoOf8GCMYIEizCCBIcCAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkG
A1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkx
HjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3Mg
MSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQc4KTDaPFncP/fdHmdwcduDAJBgUrDgMC
GgUAoIICbTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTExMTUx
NjAyNDlaMCMGCSqGSIb3DQEJBDEWBBRTUGS0wdMagK2e8V/sodtpb3YR4zCCAQMGCSsGAQQBgjcQ
BDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6
Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRh
dGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAt
IEczAhBzgpMNo8Wdw/990eZ3Bx24MIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNVBAYT
AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0
d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9y
cGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNp
Z24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQc4KTDaPFncP/fdHmdwcd
uDANBgkqhkiG9w0BAQEFAASCAQBCrSVfFLpGpcszVfeLeIXEqUh83wXR/AOk0BIGUIcOa4p/+GUz
rDijyzKXk3HpOrEnrbLALGbxlztjo1eDRbCDCP5k2S6m/ulpnCidsybiiCv8/gpni7jCEuIvRjXQ
2u7fD/5kabGqmAM5wp6rkKcHHaeTIwkjtLVHvXod17sDmDNG6xGSEox0ekTLQrzOUmbbIhG8HjZo
jJUFrrbTH2aTAAWa/DFik8xQr6oqBuI3ijQayYw7k/UJeI9wU0LsqwccI8qfmHiQvPX0npdky9bs
sjv05d7rn4gCNKwaEXzhUVDTSKAl0fZ4XoxwIHfUs44JF+w+4begEQ+tAGpCdrr1AAAAAAAA

--Apple-Mail-651--531614081--

From tho@koanlogic.com  Tue Nov 15 09:59:33 2011
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 89DDD1F0C5B for ; Tue, 15 Nov 2011 09:59:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.505
X-Spam-Level: **
X-Spam-Status: No, score=2.505 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553,  IP_NOT_FRIENDLY=0.334, J_BACKHAIR_32=1, RDNS_NONE=0.1, SARE_RECV_IP_069060096=1.666]
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 f3C8qjwvYZxo for ; Tue, 15 Nov 2011 09:59:33 -0800 (PST)
Received: from gonzo.koanlogic.com (unknown [69.60.118.166]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7FA1F0C5A for ; Tue, 15 Nov 2011 09:59:32 -0800 (PST)
Received: from host200-55-dynamic.36-79-r.retail.telecomitalia.it ([79.36.55.200]:56687 helo=t.homenet.telecomitalia.it) by gonzo.koanlogic.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1RQNHu-0007YJ-Uo; Tue, 15 Nov 2011 12:59:26 -0500
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Thomas Fossati 
In-Reply-To: <4C5F6048-544A-447A-A293-E3F5B149B806@sensinode.com>
Date: Tue, 15 Nov 2011 18:58:24 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <4C5F6048-544A-447A-A293-E3F5B149B806@sensinode.com>
To: Zach Shelby 
X-Mailer: Apple Mail (2.1084)
X-SA-Exim-Connect-IP: 79.36.55.200
X-SA-Exim-Mail-From: tho@koanlogic.com
X-Spam-DCC: : 
X-Spam-Pyzor: Reported 0 times.
X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100)
X-SA-Exim-Scanned: Yes (on gonzo.koanlogic.com)
Cc: core WG 
Subject: Re: [core] Long-lived queries towards RD
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, 15 Nov 2011 17:59:33 -0000

On Nov 15, 2011, at 5:02 PM, Zach Shelby wrote:
> On Nov 15, 2011, at 6:31 PM, Thomas Fossati wrote:
>> And I was wondering whether it'd be feasible to provide a native =
mechanism to RD that, via Observe, could mimic the semantics of the =
long-lived queries that we have in DNS-SD.
>>=20
>> This feature would be particularly nice to have for implementing an =
efficient DNS<->RD synchronization agent, and more generally to any RD =
replication (be it partial or total), or service "popup" monitoring =
mechanism -- e.g. for automatic failover of a given (critical) service.
>=20
> Sounds like you want to monitor the RD lookup interface for any kinds =
of changes, and then use CoAP observe to get a notification when =
anything changes, right?

Exactly.

What I'd like to have in RD is a "permanent" lookup interface, i.e. an =
RD link that I can observe, which corresponds to a given query (e.g. =
"monitor all changes related to 'exp' resources", or "monitor all =
thermometers available in the area", etc.)  When a =
registration/update/deletion compatible to my query is triggered on the =
RD, I get notified.

Something like:
=20
    DNS-sync                    RD
      |                         |
      |      GET /rd?exp        |
      |       Observe: 0        |                        node
      +------------------------>|                         |
           ....                    POST /rd ";exp" |
      |                         |<------------------------+
      |  add  |                         |
      |<------------------------+                         |


From zach@sensinode.com  Tue Nov 15 18:27:46 2011
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 000E811E80EE for ; Tue, 15 Nov 2011 18:27:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_BACKHAIR_32=1, 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 so196MvTsP-y for ; Tue, 15 Nov 2011 18:27:41 -0800 (PST)
Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 9D83311E81A9 for ; Tue, 15 Nov 2011 18:27:40 -0800 (PST)
Received: from dhcp-123b.meeting.ietf.org (dhcp-123b.meeting.ietf.org [130.129.18.59]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id pAG2RTRZ021263 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 16 Nov 2011 04:27:34 +0200
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/signed; boundary=Apple-Mail-653--494133384; protocol="application/pkcs7-signature"; micalg=sha1
From: Zach Shelby 
In-Reply-To: 
Date: Wed, 16 Nov 2011 10:27:30 +0800
Message-Id: 
References:  <4C5F6048-544A-447A-A293-E3F5B149B806@sensinode.com> 
To: Thomas Fossati 
X-Mailer: Apple Mail (2.1084)
Cc: core WG 
Subject: Re: [core] Long-lived queries towards RD
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, 16 Nov 2011 02:27:46 -0000

--Apple-Mail-653--494133384
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Nov 16, 2011, at 1:58 AM, Thomas Fossati wrote:

> On Nov 15, 2011, at 5:02 PM, Zach Shelby wrote:
>> On Nov 15, 2011, at 6:31 PM, Thomas Fossati wrote:
>>> And I was wondering whether it'd be feasible to provide a native =
mechanism to RD that, via Observe, could mimic the semantics of the =
long-lived queries that we have in DNS-SD.
>>>=20
>>> This feature would be particularly nice to have for implementing an =
efficient DNS<->RD synchronization agent, and more generally to any RD =
replication (be it partial or total), or service "popup" monitoring =
mechanism -- e.g. for automatic failover of a given (critical) service.
>>=20
>> Sounds like you want to monitor the RD lookup interface for any kinds =
of changes, and then use CoAP observe to get a notification when =
anything changes, right?
>=20
> Exactly.
>=20
> What I'd like to have in RD is a "permanent" lookup interface, i.e. an =
RD link that I can observe, which corresponds to a given query (e.g. =
"monitor all changes related to 'exp' resources", or "monitor all =
thermometers available in the area", etc.)  When a =
registration/update/deletion compatible to my query is triggered on the =
RD, I get notified.
>=20
> Something like:
>=20
>    DNS-sync                    RD
>      |                         |
>      |      GET /rd?exp        |
>      |       Observe: 0        |                        node
>      +------------------------>|                         |
>           ....                    POST /rd ";exp" |
>      |                         |<------------------------+
>      |  add  |                         |
>      |<------------------------+                         |

That is exactly what Observe does already. Looks like the RD lookup =
interface just needs some more sophistication in the kinds of lookups =
that can be made, and text that says the /rd resource SHOULD be =
observable. I will add that for the next version of the draft.=20

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


--Apple-Mail-653--494133384
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMWTCCBWMw
ggRLoAMCAQICEHOCkw2jxZ3D/33R5ncHHbgwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT
MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg
KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g
Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTEwMTAwMDAwMDBaFw0x
MjEwMDkyMzU5NTlaMIIBEDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S
UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh
bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2
aWNlMRQwEgYDVQQDFAtaYWNoIFNoZWxieTEhMB8GCSqGSIb3DQEJARYSemFjaEBzZW5zaW5vZGUu
Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzhUEvdReCaejkXy7oHgfRykbzYKT
UVdKPk27VuoqRENDsQvOx+7PedUCyaXF1CUyzY5/QI+8lRyPEdyctsqAKTb1Pp0Bx0zgpsSHrFVb
+JTLLEI4rKJ2KogmzXar3FQow+819WT0tIC7QIwma6m6N2MpxVGXd6VGTidqshi7ZfvyDwUh1BuH
HYgn8/fgTAvCFJoLD6asYUZ/AKreqDD7lwyjPZG5AfoaXPilBzuVIGArLCcYvaWSlMpntokmU5oh
5AjZX8Wmg32rxYnCy6NCGyoQHq1iQTnleH0eUcbvG5fTGDnOs1scoHHKeZ6meyFFDAc/d2KJJ8zW
bEKU2MalcQIDAQABo4HoMIHlMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAq
MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAd
BgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwFAYKYIZIAYb4RQEGBwQGFgROb25lMFAGA1Ud
HwRJMEcwRaBDoEGGP2h0dHA6Ly9pbmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29tL0lu
ZEMxRGlnaXRhbElELUczLmNybDANBgkqhkiG9w0BAQUFAAOCAQEATFvGnK8aGE+tObyxTKI5EzlL
7RKS5iH7fQ0DIdLXNTph4XZL1kLxp3LIwsm2+UsptMhtk7nXT8sWgiH8pugbYUZQl/pZZeTbcqGb
rPpWTQg1jqXNo0nZJG1jvgGyuA4ozmSiD6frU/s58cUCwNdmPK41lunpS4KyLbgw7vQZCwrb0RGW
YkCrVds9CtncAlcHROFAuuNsgrN6GX+VEsfqw+u+eOVIMaAVKfXqfquuLp/p41HgkDC6onA2biaO
guxLuH/fAhIwSNe8TBS/bYMTF8yROSxn0mnNryhMOZTsqt4R0XEgXxyNpPIgRmrg3DgnqldFWDPn
zHHOQRx73R3fXTCCBu4wggXWoAMCAQICEHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEFBQAw
gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig
YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp
bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAwMDAwMFoXDTE5MDQz
MDIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE
CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBz
Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlk
YXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0Eg
LSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAO3ER98qKB18Bmu71yEyyWwTj+mx
jUFONPfaC+Nq+mWIIAsRE+mb4ElOi2/VAdBfDUeRilpMdD4/xpEJu0w0no1uoYJRYvdpdliWB6+e
FBgHT1q9n9IxslQZc0ZqGUIR7BJzIY313DDN5dlWCjHFNm0pFJe9LdqJRxmI2EsEPeu2PGcedAAT
DdCG2pNn+DMDrho8a2l49sAsjuGDP3f5mf/+n1JawrSHCthsqUfBVCllQz5KwJYfwa33d69ssQRe
vsG2lC2XkC0n0rse6YNqhPbEsq4jBmUmpSdYKwcitG+mYkgad/LVUCeaKdOW+yj1uiR2YuOMWev7
btVCxL5Bx/UCAwEAAaOCArkwggK1MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDov
L29jc3AudmVyaXNpZ24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkwZzBlBgtghkgB
hvhFAQcXATBWMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMCoGCCsG
AQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCegJYYj
aHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4GCCsG
AQUFBwEMBGIwYKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy70FI4
mymsSweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAuBgNVHREE
JzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4EFgQUeUdhCEH9
OASiS+e1zPVD9kkrEfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UEBhMCVVMxFzAVBgNV
BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYD
VQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUw
QwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0
aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUAA4IBAQA5Tc9BmYG1
qQW1UjjpOYSJbOQ0qFrn2GwJTCQaulmkhztzIfGTgc+/aGNaZ/41hSuhw12jSsI6Gd0w1sxN7/HS
gZfKVFpDvzeLeo4ZjQ9DqIzyr2CzFYqzlZw84J6zJ5ikNXIX5fwqXYfTig3C0UUq+MD0rCqTOtWu
EnAI6/s74nfs6CtkNXbNutrg0csU1nFYm77VPn222egkxSRmTF2RH3azFz5/DcYhiS+zN7ih/1yy
bUneZVJC+w6I0u1KHb9L4/jMcvpIDmWOScjW+JmYO7eUPjFxBof6bFlTLtffK+1fYwCsFe0DuFUW
jMZoA+ciqHMLsbyg2lJY3QoOf8GCMYIEizCCBIcCAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkG
A1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkx
HjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3Mg
MSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQc4KTDaPFncP/fdHmdwcduDAJBgUrDgMC
GgUAoIICbTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTExMTYw
MjI3MzBaMCMGCSqGSIb3DQEJBDEWBBTn3NvMdiuVQDnJgaFxBtJI3EuJ/jCCAQMGCSsGAQQBgjcQ
BDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6
Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRh
dGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAt
IEczAhBzgpMNo8Wdw/990eZ3Bx24MIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNVBAYT
AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0
d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9y
cGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNp
Z24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQc4KTDaPFncP/fdHmdwcd
uDANBgkqhkiG9w0BAQEFAASCAQAPnpSPJUVJpKsOkdRU8xHKiVWtfTsjqZNGFUME0prJZ885nSIg
FJFfIDS0crT0EAszPKY0ZiW8I4x1EO0v9HqtEFRwWykx7Mrk2tPqG16/8fmVCHlohCSy19CvrIzu
Us8wAguUI4FwPpcCJxT/Zv/a4f7RGXTyVXPL5ASFxw7f9WwiECHJGlt1+oyryVS8vEorjCFdTiko
URhCI7Pk3tBv/iAUXtPIY9JEcXD9GGcagao6VT4/y+2rdI5ycBj4uJS7t3JK1fcUK+JsdCbzga/H
G6JWaQlNDb/HkNv/o0R3f9lYyx5h/6rUxbUa+J4Ut4OdpG3+Y2u4ULxYA9i07WqLAAAAAAAA

--Apple-Mail-653--494133384--

From cabo@tzi.org  Tue Nov 15 19:08:44 2011
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 122B421F900D for ; Tue, 15 Nov 2011 19:08:44 -0800 (PST)
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=[AWL=-0.000, 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 pQVu2B-R-JI7 for ; Tue, 15 Nov 2011 19:08:40 -0800 (PST)
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 C106B11E8083 for ; Tue, 15 Nov 2011 19:08:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id pAG38SOT006680 for ; Wed, 16 Nov 2011 04:08:29 +0100 (CET)
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 A679C387; Wed, 16 Nov 2011 04:08:27 +0100 (CET)
From: Carsten Bormann 
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Date: Wed, 16 Nov 2011 11:08:23 +0800
To: core WG 
Message-Id: <15BFA8B6-FF1D-4CEC-AF01-A3DE7FD07CC2@tzi.org>
Mime-Version: 1.0 (Apple Message framework v1251.1)
X-Mailer: Apple Mail (2.1251.1)
Subject: [core] Core@IETF82: First version of slide set posted
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, 16 Nov 2011 03:08:44 -0000

http://www.ietf.org/proceedings/82/slides/core-0.pdf

Presenters: Please check whether your slides are in and whether they are =
the right version.  Those of you that have 20 slides for 5-minute =
discussion also maybe want to send me a reduced version.

Gr=FC=DFe, Carsten


From tho@koanlogic.com  Tue Nov 15 23:43:46 2011
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 31E0E1F0C78 for ; Tue, 15 Nov 2011 23:43:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.005
X-Spam-Level: **
X-Spam-Status: No, score=2.005 tagged_above=-999 required=5 tests=[AWL=0.500,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553,  IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, SARE_RECV_IP_069060096=1.666]
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 FpxrJpuXs5X2 for ; Tue, 15 Nov 2011 23:43:45 -0800 (PST)
Received: from gonzo.koanlogic.com (unknown [69.60.118.166]) by ietfa.amsl.com (Postfix) with ESMTP id 863F11F0C93 for ; Tue, 15 Nov 2011 23:43:45 -0800 (PST)
Received: from host200-55-dynamic.36-79-r.retail.telecomitalia.it ([79.36.55.200]:57739 helo=t.home) by gonzo.koanlogic.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1RQa9e-00006k-Np; Wed, 16 Nov 2011 02:43:43 -0500
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Thomas Fossati 
In-Reply-To: 
Date: Wed, 16 Nov 2011 08:43:00 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <5F044B64-5CEC-4402-8F99-0C6BA29D0C53@koanlogic.com>
References:  <4C5F6048-544A-447A-A293-E3F5B149B806@sensinode.com>  
To: Zach Shelby 
X-Mailer: Apple Mail (2.1084)
X-SA-Exim-Connect-IP: 79.36.55.200
X-SA-Exim-Mail-From: tho@koanlogic.com
X-Spam-DCC: : 
X-Spam-Pyzor: Reported 0 times.
X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100)
X-SA-Exim-Scanned: Yes (on gonzo.koanlogic.com)
Cc: core WG 
Subject: Re: [core] Long-lived queries towards RD
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, 16 Nov 2011 07:43:46 -0000

On Nov 16, 2011, at 3:27 AM, Zach Shelby wrote:
> That is exactly what Observe does already.

Yes, it seems like a fairly natural welding.

> Looks like the RD lookup interface just needs some more sophistication =
in the kinds of lookups that can be made, and text that says the /rd =
resource SHOULD be observable. I will add that for the next version of =
the draft.

Excellent, thanks.=

From stpeter@stpeter.im  Wed Nov 16 00:05:27 2011
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 9B37611E81F0 for ; Wed, 16 Nov 2011 00:05:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.57
X-Spam-Level: 
X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 p5EJBEuPyULt for ; Wed, 16 Nov 2011 00:05:25 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 97A4911E81EC for ; Wed, 16 Nov 2011 00:05:25 -0800 (PST)
Received: from squire.local (unknown [130.129.21.171]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A8D334214E for ; Wed, 16 Nov 2011 01:11:40 -0700 (MST)
Message-ID: <4EC36EC3.70808@stpeter.im>
Date: Wed, 16 Nov 2011 16:05:23 +0800
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: core WG 
References: <8BC845943058D844ABFC73D2220D46650B0E3598@nics-mail.sbg.nic.at>
In-Reply-To: <8BC845943058D844ABFC73D2220D46650B0E3598@nics-mail.sbg.nic.at>
X-Enigmail-Version: 1.3.3
OpenPGP: url=https://stpeter.im/stpeter.asc
X-Forwarded-Message-Id: <8BC845943058D844ABFC73D2220D46650B0E3598@nics-mail.sbg.nic.at>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: [core] Fwd: [domainrep] CoAP as a query transport protocol.
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, 16 Nov 2011 08:05:27 -0000

Here is a novel use suggested for CoAP. I was rather surprised to hear
the suggestion in the REPUTE WG meeting just now!

-------- Original Message --------
Subject: [domainrep] CoAP as a query transport protocol.
Date: Wed, 16 Nov 2011 08:24:22 +0100
From: Alexander Mayrhofer 
To: 

As i just said in the WG session, i would suggest looking whether CoAP
could be an alternative to the "plain" UDP currently proposed in
draft-kucherawy-reputation-query-udp-00.

thanks,

Alex

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

From ari.keranen@nomadiclab.com  Wed Nov 16 00:15:36 2011
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 8C5E51F0C41 for ; Wed, 16 Nov 2011 00:15:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-FhKv2X7ZOl for ; Wed, 16 Nov 2011 00:15:35 -0800 (PST)
Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by ietfa.amsl.com (Postfix) with ESMTP id 49D1D1F0C3F for ; Wed, 16 Nov 2011 00:15:35 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id A64D04E6DA; Wed, 16 Nov 2011 10:15:32 +0200 (EET)
X-Virus-Scanned: amavisd-new at nomadiclab.com
Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2p2pgtFXeZow; Wed, 16 Nov 2011 10:15:31 +0200 (EET)
Received: from As-MacBook-Air.local (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTPSA id C10364E6D4; Wed, 16 Nov 2011 10:15:30 +0200 (EET)
Message-ID: <4EC3711F.6010205@nomadiclab.com>
Date: Wed, 16 Nov 2011 16:15:27 +0800
From: Ari Keranen 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: draft-yegin-coap-security-options@tools.ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: core WG 
Subject: [core] draft-yegin-coap-security-options-00 review
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, 16 Nov 2011 08:15:37 -0000

Hi,

I had a quick read over the draft-yegin-coap-security-options-00 and 
have a few comments.

While it's an interesting idea, I'm not really convinced of the comment 
in the draft that "a solution defined within the same layer as the base 
specification would provide an efficient alternative to DTLS and IPsec 
in terms of crypto context setup, packet size, and implementation 
overhead." Where do you base this assumption? It would be nice to see 
some numbers or even estimates (not necessarily on the draft).

And we do already have fairly well working end-to-end security 
mechanisms (DTLS, IPsec) and even with light-weight keying (Tero's 
example of minimalistic IKEv2, HIP DEX). Considering that security is 
really hard to get right, I'd definitely recommend using something that 
already exists and has been widely reviewed. That said, your solution 
does have a bit different approach (can encrypt only parts), but how 
much benefits does that give (you do crypto over X bytes instead of X+6 
bytes?), I'm not that sure of.

Also, I'm a bit concerned about the fact that key management is out of 
scope for the document. After all, that's often the hard part in 
security protocols.

I'd need to have a closer look at this, but I think this protocol 
proposal could be also vulnerable to downgrade-attacks.

Anyhow, these are just some examples that I know, e.g., with HIP has 
been thought a lot, and I'd assume also IKE and DTLS has protection 
against. Yes, you could re-invent all that on top of CoAP, but in that 
case, why not just use something that already exists?

Some specific comments:

       - Context ID: One-octet unsigned integer value.  Value 0 is
       reserved to indicate invalid context ID, values 1-255 are valid.

This limits the amount of contexts to 255; how about e.g., an 
aggregating/gateway node taking care of more than 255 sensor nodes?

I found the use of strings as key and crypto algo identifiers a bit 
strange. Why not use, say, integer values which map to different algos 
and have an IANA registry for that?


Cheers,
Ari

From cabo@tzi.org  Wed Nov 16 01:49:33 2011
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 9DCAF21F9602 for ; Wed, 16 Nov 2011 01:49:33 -0800 (PST)
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 rn4-QX+GDEXY for ; Wed, 16 Nov 2011 01:49:33 -0800 (PST)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [134.102.201.18]) by ietfa.amsl.com (Postfix) with ESMTP id CD5D821F9601 for ; Wed, 16 Nov 2011 01:49:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id pAG9n3up025753 for ; Wed, 16 Nov 2011 10:49:03 +0100 (CET)
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 2A5A3504; Wed, 16 Nov 2011 10:49:01 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann 
In-Reply-To: <15BFA8B6-FF1D-4CEC-AF01-A3DE7FD07CC2@tzi.org>
Date: Wed, 16 Nov 2011 17:48:57 +0800
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <15BFA8B6-FF1D-4CEC-AF01-A3DE7FD07CC2@tzi.org>
To: core WG 
X-Mailer: Apple Mail (2.1251.1)
Subject: Re: [core] Core@IETF82: First version of slide set posted
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, 16 Nov 2011 09:49:33 -0000

I have repeatedly updated that slide set today, gradually decreasing the =
number of guffaws.
Please do redownload eagerly.

Gr=FC=DFe, Carsten

On Nov 16, 2011, at 11:08, Carsten Bormann wrote:

> http://www.ietf.org/proceedings/82/slides/core-0.pdf
>=20
> Presenters: Please check whether your slides are in and whether they =
are the right version.  Those of you that have 20 slides for 5-minute =
discussion also maybe want to send me a reduced version.
>=20
> Gr=FC=DFe, Carsten
>=20
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core


From internet-drafts@ietf.org  Wed Nov 16 07:16:31 2011
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 7DDDC21F8FD7; Wed, 16 Nov 2011 07:16:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.582
X-Spam-Level: 
X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 0wSCVTP8wn2W; Wed, 16 Nov 2011 07:16:30 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E81F621F8FA7; Wed, 16 Nov 2011 07:16:30 -0800 (PST)
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: 3.64
Message-ID: <20111116151630.30027.68018.idtracker@ietfa.amsl.com>
Date: Wed, 16 Nov 2011 07:16:30 -0800
Cc: core@ietf.org
Subject: [core] I-D Action: draft-ietf-core-link-format-09.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Nov 2011 15:16:31 -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 Work=
ing Group of the IETF.

	Title           : CoRE Link Format
	Author(s)       : Zach Shelby
	Filename        : draft-ietf-core-link-format-09.txt
	Pages           : 19
	Date            : 2011-11-16

   This document defines Web Linking using a link format for use by
   constrained web servers to describe hosted resources, their
   attributes and other relationships between links.  Based on the HTTP
   Link Header format defined in RFC5988, the CoRE Link Format is
   carried as a payload and is assigned an Internet media type.  A well-
   known URI is defined as a default entry-point for requesting the
   links hosted by a server.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-core-link-format-09.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-core-link-format-09.txt


From cabo@tzi.org  Wed Nov 16 18:56:20 2011
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 2660B1F0CA1; Wed, 16 Nov 2011 18:56:20 -0800 (PST)
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=[AWL=-0.000, 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 EAYmV0ND6fQI; Wed, 16 Nov 2011 18:56:19 -0800 (PST)
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 14AC51F0C8D; Wed, 16 Nov 2011 18:56:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id pAH2u990017121; Thu, 17 Nov 2011 03:56:09 +0100 (CET)
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 46DBC999; Thu, 17 Nov 2011 03:56:06 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=windows-1252
From: Carsten Bormann 
In-Reply-To: <72211CB7-0790-4F0B-A47D-40BFD83EEA81@tzi.org>
Date: Thu, 17 Nov 2011 10:56:02 +0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <49940D6A-23D5-4EF9-A328-E4C5F81F3A36@tzi.org>
References: <72211CB7-0790-4F0B-A47D-40BFD83EEA81@tzi.org>
To: 6lowpan <6lowpan@ietf.org>
X-Mailer: Apple Mail (2.1251.1)
Cc: lwip@ietf.org, roll@ietf.org, core WG 
Subject: Re: [core] [6lowpan] Cross-layer issues in Constrained Node/Networks: informal get-together
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: 6lowpan <6lowpan@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: Thu, 17 Nov 2011 02:56:20 -0000

On Nov 15, 2011, at 13:42, Carsten Bormann wrote:

> We are going to have an informal get-together to discuss some of these
> issues at
>=20
>       Thu, 1740-1940, room 102

I have started collecting slides for this event.
We don't need slides to discuss something, but where they help, I would =
like to have them before the meeting.

Observe*) the current set of slides at

	http://www.tzi.org/~cabo/cross-layer.pdf

Gr=FC=DFe, Carsten

*) Sorry, no CoAP server there yet=85  Manual repeated HTTP GET =
required.


From cabo@tzi.org  Wed Nov 16 20:12:45 2011
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 89FA311E80B0 for ; Wed, 16 Nov 2011 20:12:45 -0800 (PST)
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=[AWL=-0.000, 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 QSSU+PAvmWE4 for ; Wed, 16 Nov 2011 20:12:45 -0800 (PST)
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 C17A411E8088 for ; Wed, 16 Nov 2011 20:12:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id pAH4CZuh011424 for ; Thu, 17 Nov 2011 05:12:35 +0100 (CET)
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 AF9C799E; Thu, 17 Nov 2011 05:12:34 +0100 (CET)
From: Carsten Bormann 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Thu, 17 Nov 2011 12:12:30 +0800
To: core WG 
Message-Id: <2F008BD6-3D3D-4772-8289-08A8AF098AAA@tzi.org>
Mime-Version: 1.0 (Apple Message framework v1251.1)
X-Mailer: Apple Mail (2.1251.1)
Subject: [core] Second WGLC for draft-ietf-core-link-format-09.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Nov 2011 04:12:45 -0000

On January 16 this year, core-link-format-02 finished working group last =
call.
On March 15, the -03 draft incorporated the changes from the comments =
received on this WGLC.

Since that update, the draft has experienced some Brownian motion.
Changes were made e.g. to adapt the examples to some coap-core changes, =
to clarify the use of UTF-8, to address AD comments, and to properly =
distribute the normative content between the different CoRE specs.
With -09, we now have a version that passes all ID-Nits.
While I personally think it could be justified to send this on to the =
IESG as is, I also think that might be considered bad form.

So I'm announcing today a

   second working-group last call
   for draft-ietf-core-link-format-09.txt

This is a one-week WGLC, but time does not pass during an IETF.
So please send in any comments to the CoRE list now, or latest until

   2011-11-28, 1200 UTC.

A short note of the form "I've re-read -09 and it's OK" would also be =
very welcome.

Gruesse, Carsten

PS.: You can use
=
http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-link-format-09&url1=3D=
draft-ietf-core-link-format-03
to review the changes since -03.


From alper.yegin@yegin.org  Wed Nov 16 23:07:36 2011
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 01D8411E80D5 for ; Wed, 16 Nov 2011 23:07:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eixQPQs-Nt88 for ; Wed, 16 Nov 2011 23:07:35 -0800 (PST)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 3AE7D11E8083 for ; Wed, 16 Nov 2011 23:07:35 -0800 (PST)
Received: from [10.1.1.2] (odakk1.odakk.com [78.111.98.194]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0Lja6a-1QtoAf04lM-00bRL6; Thu, 17 Nov 2011 02:07:31 -0500
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: text/plain; charset=windows-1252
From: Alper Yegin 
In-Reply-To: <4EC3711F.6010205@nomadiclab.com>
Date: Thu, 17 Nov 2011 09:07:21 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <7C27259C-8186-4F01-8244-043203B6C4AD@yegin.org>
References: <4EC3711F.6010205@nomadiclab.com>
To: Ari Keranen 
X-Mailer: Apple Mail (2.1244.3)
X-Provags-ID: V02:K0:1ND33LBvgas8AlQZjuJRTIdU+p4CpG7dUHX9SFrgs+o havDukMsbCO+d5FWFwe51Uwv10dK+gAB0EZVaUYceb9UJXjC9D jvwk3z2kPrTRWIKKTIChwScnTBoB6+F47MygrY1027QkZIPfDF 1o/MQNsXjvkBxI/+RSVhTI9rajsX7MvgMFRVslTgcr6FIXnXF1 fmjbdF1XmhkD+NMQWR9jB1PuV1wlxLB0PDj3usTbjQz4jg3fkU o5IYrCeySTUSLLOpefYwiRXFF5ug/fOzK54rzS8RW5vBbyKcw3 VeXRHe+eE8j/6IpiDt+7cBtFmi6xyXdg4DlMgg1zWhXLiF6op6 IttX7YIAXVSiuakoWNsYBnHxm0+akVRqy4VsCZWr/
Cc: draft-yegin-coap-security-options@tools.ietf.org, core WG 
Subject: Re: [core] draft-yegin-coap-security-options-00 review
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, 17 Nov 2011 07:07:36 -0000

Hi Ari,

Thank you for the feedback.

Please see below for my feedback.

On Nov 16, 2011, at 10:15 AM, Ari Keranen wrote:

> Hi,
>=20
> I had a quick read over the draft-yegin-coap-security-options-00 and =
have a few comments.
>=20
> While it's an interesting idea, I'm not really convinced of the =
comment in the draft that "a solution defined within the same layer as =
the base specification would provide an efficient alternative to DTLS =
and IPsec in terms of crypto context setup, packet size, and =
implementation overhead." Where do you base this assumption? It would be =
nice to see some numbers or even estimates (not necessarily on the =
draft).
>=20

Let me work out some numbers and put on the slides.


> And we do already have fairly well working end-to-end security =
mechanisms (DTLS, IPsec) and even with light-weight keying (Tero's =
example of minimalistic IKEv2, HIP DEX). Considering that security is =
really hard to get right, I'd definitely recommend using something that =
already exists and has been widely reviewed. That said, your solution =
does have a bit different approach (can encrypt only parts), but how =
much benefits does that give (you do crypto over X bytes instead of X+6 =
bytes?), I'm not that sure of.
>=20

DTLS and IPsec are available and solid. They provide channel security. =
But that does not boil down to never developing/using a higher-layer =
security. XML security and now JOSE WG are good counter examples of =
that.=20

Even in IETF for Mobile IPv4 we used a solution similar to =
coap-security. In fact, that experience suggested me this question: How =
come we are not doing it the same on CoAP. I asked that question on the =
mailing list, no response. So, I did the exercise of developing "a" =
solution, and now collecting feedback :-)

Then for Mobile IPv6 we did what you recommended with IPsec, and that =
created problems=85=20


> Also, I'm a bit concerned about the fact that key management is out of =
scope for the document. After all, that's often the hard part in =
security protocols.
>=20


Yes, it's a hard problem. But it's a separate problem.=20
"Key management" and "using the generated key to secure a protocol" are =
typically separate mechanisms. One can  come up with an integrated =
solution. Integration is not ideal, but maybe useful. (Not sure if this =
is what your proposal is suggesting=85)=20


> I'd need to have a closer look at this, but I think this protocol =
proposal could be also vulnerable to downgrade-attacks.
>=20
> Anyhow, these are just some examples that I know, e.g., with HIP has =
been thought a lot, and I'd assume also IKE and DTLS has protection =
against. Yes, you could re-invent all that on top of CoAP, but in that =
case, why not just use something that already exists?
>=20
> Some specific comments:
>=20
>      - Context ID: One-octet unsigned integer value.  Value 0 is
>      reserved to indicate invalid context ID, values 1-255 are valid.
>=20
> This limits the amount of contexts to 255; how about e.g., an =
aggregating/gateway node taking care of more than 255 sensor nodes?
>=20


255 contexts between two end-points. Each end-point can have so many =
context with each other end point it is communicating with. So, this ID =
space is per pair of devices.


> I found the use of strings as key and crypto algo identifiers a bit =
strange. Why not use, say, integer values which map to different algos =
and have an IANA registry for that?
>=20

Algo identifiers is one-octet integer.

Key name is a string, similar to what XML and TLS does. (I think string =
is more flexible in defining key names than an integer is).

Thank you.

Alper






>=20
> Cheers,
> Ari


From salvatore.loreto@ericsson.com  Thu Nov 17 02:03:31 2011
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 911FD21F9B6B for ; Thu, 17 Nov 2011 02:03:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.111
X-Spam-Level: 
X-Spam-Status: No, score=-106.111 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_48=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 QqXo2hqzEFKl for ; Thu, 17 Nov 2011 02:03:29 -0800 (PST)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id CDEFE21F9B67 for ; Thu, 17 Nov 2011 02:03:28 -0800 (PST)
X-AuditID: c1b4fb39-b7b3eae00000252a-e9-4ec4dbefa549
Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 72.00.09514.FEBD4CE4; Thu, 17 Nov 2011 11:03:27 +0100 (CET)
Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Thu, 17 Nov 2011 11:03:27 +0100
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id 4C242230F	for ; Thu, 17 Nov 2011 12:03:27 +0200 (EET)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 0A21951A0E	for ; Thu, 17 Nov 2011 12:03:27 +0200 (EET)
Received: from dhcp-1324.meeting.ietf.org (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 9299A519CD	for ; Thu, 17 Nov 2011 12:03:25 +0200 (EET)
Message-ID: <4EC4DBEB.8070808@ericsson.com>
Date: Thu, 17 Nov 2011 18:03:23 +0800
From: Salvatore Loreto 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: core@ietf.org
References: <20111031113719.3103.79998.idtracker@ietfa.amsl.com> <4EB41F30.3000108@ericsson.com> <515E0BF2-4FF0-49E4-B857-842749305380@tzi.org> <4EB43CEC.3050402@ericsson.com>
In-Reply-To: <4EB43CEC.3050402@ericsson.com>
Content-Type: multipart/alternative; boundary="------------040102050604060108080809"
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: AAAAAA==
Subject: [core] Cache Refresh via Observe (was Re: I-D Action: draft-ietf-core-observe-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, 17 Nov 2011 10:03:31 -0000

--------------040102050604060108080809
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit

Hi there,

I want point you to the Cache Refresh mechanism we have started to 
describe within
the draft-castellani-core-http-mapping
(ref: 
http://tools.ietf.org/html/draft-castellani-core-http-mapping-02#page-12 )
I am sure you have already read it... but just in case I copy the text here:

4.2.2.  Cache Refresh via Observe

    There are cases where using CoAP observe protocol
    [I-D.ietf-core-observe] to handle proxy cache refresh may be
    preferable to the validation mechanism based on ETag's defined in
    section 5.6.2 of [I-D.ietf-core-coap].  For example: sleeping nodes,
    possibly showing high variance in requests' distribution, would
    greatly benefit from a server driven cache update mechanism.  Other
    expected candidates would be the crowded or very low throughput
    networks, where minimization of the total number of exchanged
    messages is a major goal.

    This subsection aims at providing a practical evaluation method to
    decide whether the refresh of a cached resource R is more efficiently
    handled via ETag validation or by establishing an observation on R.

    Let T_R be the mean time between two client requests to resource R,
    F_R be the freshness lifetime of R, and M_R be the total number of
    messages exchanged by the cache towards resource R in order to
    validate its freshness.  Assumed a negligible initial cost for
    establishing the observation relationship (one only message), an
    observation on R lessens M_R (i.e. it's a better cache update choice
    then using ETag validation) iff T_R<  2*F_R, or equivalently, iff the
    mean arrival time of requests for resource R is greater than half the
    refresh rate of R.

    The above relation can easily be grasped by noticing that, in case
    the mean interarrival time between requests is less than the refresh
    rate of R, an observation does not generate any unnecessary
    validation message, and is therefore optimal.  Further, since the
    number of messages used by ETag's validation is twice the observation
    cost (request/response vs server push), the bound on T_R can be
    doubled.

    As a rule of thumb, volatile resources (i.e. those showing tiny
    freshness lifetime) with access rate in the order of half their
    refresh rate, are good candidates for implementing observer-based
    cache refresh.  Imagine a sensor providing one new value every
    second, and clients accessing it on average once every 1.5 seconds:
    in one single day of usage, 28800 messages may have been saved if HC
    establishes an observation on the sensor resource.



cheers

-- 
Salvatore Loreto
www.sloreto.com



On 11/5/11 3:28 AM, Salvatore Loreto wrote:
> Hi Carsten,
>
> see in line
>
> On 11/4/11 6:58 PM, Carsten Bormann wrote:
>>> >  -in Section 1.3 Design Philosophy
>>> >  
>>> >  I don't agree on the similitude inserted in bracket of the first paragraph:
>>> >  
>>> >  (A server needs to keep track of the observers
>>> >      though, similar to how HTTP servers need to keep track of the TCP
>>> >      connections from their clients.)
>> I think this point is important, as people who think that HTTP is stateless always conveniently forget that e.g., for a long-poll, connection state has to be kept for a long time at the server.  An observation relationship is rather similar to this connection state, once you disregard the different layers.
>>
>> So where do you see the limitations of that allegory?
> now that you mentioned long-poll, the allegory starts to make some 
> sense to me
>
> as I said it is not clear from the context that the allegory is with 
> HTTP long-poll mechanism;
> while reading I understood the allegory was with the generic HTTP 
> "persistent connections" independently
> if they were or not at moment monopolized by long-polling requests
>
> More in some sense the HTTP servers do not need to keep track of the 
> connections used
> by long-poll as they are monopolized by the long-poll requests
>
>>> >    - more the last version of the draft introduces the Max-OFE,
>>> >  I don't recall that the concept has been discussed in the mailing list before,
>>> >  but most likely I have missed it.
>>> >  It is not clear to me the advantage of introducing a Max-OFE value
>>> >  versus to include directly the "optimistic freshness extension" time directly in the Max-Age:
>>> >  instead of having Max-Age of 60seconds and a MAX-OFE of 10seconds
>>> >  assigning directly to Max-Age a value of 70seconds
>> I thought that, too, for a while.
>> One reason why it is useful to have both max-age and max-ofe is that, with a single value, there is no indication when it would be a good time to start trying to get a new value -- at a time when the existing value can still be used.
>> See RFC5861 (the, somewhat more complex, HTTP version of this concept) for more background.
> thanks for the pointer, I didn't have it on the top of my mind..
>
> I see the usefulness of the indication of trying to get a new value 
> while still using the existing value,
> and even more the need to issue a new GET request to re-register (if 
> the client does not receive a new
> notification before Max-Age+Max-OFE ends)interest.
>
> however the current observe draft should specify a little deeply the 
> usage of it by caches ...
> if a client receive a stale value from the cache (through the issue of 
> a plain GET) it does not become aware
> of the fact that the value is a stale one,
> RFC5861 states that
>
>     Note that "stale" implies that the response will have a non-zero Age
>         header and a warning header, as per HTTP's requirements.
>
>
>
> Ciao
> Salvatore
> -- 
> Salvatore Loreto
> www.sloreto.com
>
>> Grüße, Carsten
>>
>



--------------040102050604060108080809
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit


  
    
  
  
    Hi there,

    

    I want point you to the Cache Refresh mechanism we have started to
    describe within

    the draft-castellani-core-http-mapping

    (ref:
    http://tools.ietf.org/html/draft-castellani-core-http-mapping-02#page-12
    )

    I am sure you have already read it... but just in case I copy the
    text here:

    

    
    
4.2.2.  Cache Refresh via Observe

   There are cases where using CoAP observe protocol
   [I-D.ietf-core-observe] to handle proxy cache refresh may be
   preferable to the validation mechanism based on ETag's defined in
   section 5.6.2 of [I-D.ietf-core-coap].  For example: sleeping nodes,
   possibly showing high variance in requests' distribution, would
   greatly benefit from a server driven cache update mechanism.  Other
   expected candidates would be the crowded or very low throughput
   networks, where minimization of the total number of exchanged
   messages is a major goal.

   This subsection aims at providing a practical evaluation method to
   decide whether the refresh of a cached resource R is more efficiently
   handled via ETag validation or by establishing an observation on R.

   Let T_R be the mean time between two client requests to resource R,
   F_R be the freshness lifetime of R, and M_R be the total number of
   messages exchanged by the cache towards resource R in order to
   validate its freshness.  Assumed a negligible initial cost for
   establishing the observation relationship (one only message), an
   observation on R lessens M_R (i.e. it's a better cache update choice
   then using ETag validation) iff T_R < 2*F_R, or equivalently, iff the
   mean arrival time of requests for resource R is greater than half the
   refresh rate of R.

   The above relation can easily be grasped by noticing that, in case
   the mean interarrival time between requests is less than the refresh
   rate of R, an observation does not generate any unnecessary
   validation message, and is therefore optimal.  Further, since the
   number of messages used by ETag's validation is twice the observation
   cost (request/response vs server push), the bound on T_R can be
   doubled.

   As a rule of thumb, volatile resources (i.e. those showing tiny
   freshness lifetime) with access rate in the order of half their
   refresh rate, are good candidates for implementing observer-based
   cache refresh.  Imagine a sensor providing one new value every
   second, and clients accessing it on average once every 1.5 seconds:
   in one single day of usage, 28800 messages may have been saved if HC
   establishes an observation on the sensor resource.




    cheers

    

    
-- 
Salvatore Loreto
www.sloreto.com

    

    

    On 11/5/11 3:28 AM, Salvatore Loreto wrote:
    

      
      Hi Carsten,

      

      see in line

      

      On 11/4/11 6:58 PM, Carsten Bormann wrote:
      

        

          
> -in Section 1.3 Design Philosophy 
> 
> I don't agree on the similitude inserted in bracket of the first paragraph:
> 
> (A server needs to keep track of the observers
>    though, similar to how HTTP servers need to keep track of the TCP
>    connections from their clients.)


        

        
I think this point is important, as people who think that HTTP is stateless always conveniently forget that e.g., for a long-poll, connection state has to be kept for a long time at the server.  An observation relationship is rather similar to this connection state, once you disregard the different layers.

So where do you see the limitations of that allegory?

      

      now that you mentioned long-poll, the allegory starts to make some
      sense to me

      

      as I said it is not clear from the context that the allegory is
      with HTTP long-poll mechanism;

      while reading I understood the allegory was with the generic HTTP
      "persistent connections" independently

      if they were or not at moment monopolized by long-polling requests

      

      More in some sense the HTTP servers do not need to keep track of
      the connections used

      by long-poll as they are monopolized by the long-poll requests

      
      

      

        

          
>  - more the last version of the draft introduces the Max-OFE,
> I don't recall that the concept has been discussed in the mailing list before,
> but most likely I have missed it.
> It is not clear to me the advantage of introducing a Max-OFE value 
> versus to include directly the "optimistic freshness extension" time directly in the Max-Age:
> instead of having Max-Age of 60seconds and a MAX-OFE of 10seconds 
> assigning directly to Max-Age a value of 70seconds


        

        
I thought that, too, for a while.
One reason why it is useful to have both max-age and max-ofe is that, with a single value, there is no indication when it would be a good time to start trying to get a new value -- at a time when the existing value can still be used.
See RFC5861 (the, somewhat more complex, HTTP version of this concept) for more background.

      

      thanks for the pointer, I didn't have it on the top of my mind..

      

      I see the usefulness of the indication of trying to get a new
      value while still using the existing value,

      and even more the need to issue a new GET request to re-register
      (if the client does not receive a new

      notification before Max-Age+Max-OFE ends)interest.

      

      however the current observe draft should specify a little deeply
      the usage of it by caches ...

      if a client receive a stale value from the cache (through the
      issue of a plain GET) it does not become aware

      of the fact that the value is a stale one,

      RFC5861 states that

      
      

        
Note that "stale" implies that the response will have a non-zero Age
   header and a warning header, as per HTTP's requirements.

      

      

      

      Ciao

      Salvatore

      
-- 
Salvatore Loreto
www.sloreto.com

      

      

        
Grüße, Carsten



      

      

    

    

    

  


--------------040102050604060108080809--

From salvatore.loreto@ericsson.com  Thu Nov 17 03:15:46 2011
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 E999021F9B94 for ; Thu, 17 Nov 2011 03:15:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.103
X-Spam-Level: 
X-Spam-Status: No, score=-106.103 tagged_above=-999 required=5 tests=[AWL=-0.105, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_48=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 UexoVWj0UexU for ; Thu, 17 Nov 2011 03:15:45 -0800 (PST)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 5348A21F9B78 for ; Thu, 17 Nov 2011 03:15:45 -0800 (PST)
X-AuditID: c1b4fb3d-b7c26ae0000035b9-cb-4ec4ece08cdf
Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id A1.10.13753.0ECE4CE4; Thu, 17 Nov 2011 12:15:44 +0100 (CET)
Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Thu, 17 Nov 2011 12:15:43 +0100
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id A439D230F	for ; Thu, 17 Nov 2011 13:15:43 +0200 (EET)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 5B85E51A57	for ; Thu, 17 Nov 2011 13:15:43 +0200 (EET)
Received: from dhcp-1324.meeting.ietf.org (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id D88B851A0E	for ; Thu, 17 Nov 2011 13:15:41 +0200 (EET)
Message-ID: <4EC4ECDC.1090304@ericsson.com>
Date: Thu, 17 Nov 2011 19:15:40 +0800
From: Salvatore Loreto 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: core@ietf.org
References: <20111031113719.3103.79998.idtracker@ietfa.amsl.com> <4EB41F30.3000108@ericsson.com> <515E0BF2-4FF0-49E4-B857-842749305380@tzi.org> <4EB43CEC.3050402@ericsson.com>
In-Reply-To: <4EB43CEC.3050402@ericsson.com>
Content-Type: multipart/alternative; boundary="------------080303080100050509010507"
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: AAAAAA==
Subject: [core] Max-OFE issue (was Re: I-D Action: draft-ietf-core-observe-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, 17 Nov 2011 11:15:47 -0000

--------------080303080100050509010507
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit

Hi Carsten,

from your previous answer to my concerns I understood
you borrowed the idea from RFC5861
that allows to a cache the possibility to serving stale responses while 
it attempts to revalidate it

However in draft observe-03 the mechanism draft is quite different as
the Max-OFE semantic is defined as a promise by the server that  it 
intends to send another notification
within "Max-OFE" time period once Max-Age time period has expired so 
that if the client does not receive
a new notification before Max-Age plus Max-OFE ends,  it will assume 
that it was removed from the list
of observers (e.g., due to a loss of server state)  and may issue a new 
GET request to re-register its interest.

after the discussion during the first CoRe session today and some more 
thinking on the issue,
I have concerns that there could be something dangerous in Max-OFE, 
because if the server does not set the value properly
this mechanism could end up to generate quite a lot of useless traffic, 
especially for servers that have high variances in value changes.
More, we should not expect the server doing something similar to what 
described in the draft-castellani-core-http-mapping
Section 4.2.2. "Cache Refresh via Observe" to obtain a precise Max-OFE, 
as get it could be too time/resource expensive for
a constrained server.

IMO It would safer that is the observer to do some statical calculation 
to figure it out if it was or not removed from the list
of the observer (i.e. because it has not received an updated when it 
supposed to receive)


comments, opinions are really welcome

regards
Salvatore

-- 
Salvatore Loreto
www.sloreto.com



On 11/5/11 3:28 AM, Salvatore Loreto wrote:
> Hi Carsten,
>
> see in line
>
> On 11/4/11 6:58 PM, Carsten Bormann wrote:
>>> >  -in Section 1.3 Design Philosophy
>>> >  
>>> >  I don't agree on the similitude inserted in bracket of the first paragraph:
>>> >  
>>> >  (A server needs to keep track of the observers
>>> >      though, similar to how HTTP servers need to keep track of the TCP
>>> >      connections from their clients.)
>> I think this point is important, as people who think that HTTP is stateless always conveniently forget that e.g., for a long-poll, connection state has to be kept for a long time at the server.  An observation relationship is rather similar to this connection state, once you disregard the different layers.
>>
>> So where do you see the limitations of that allegory?
> now that you mentioned long-poll, the allegory starts to make some 
> sense to me
>
> as I said it is not clear from the context that the allegory is with 
> HTTP long-poll mechanism;
> while reading I understood the allegory was with the generic HTTP 
> "persistent connections" independently
> if they were or not at moment monopolized by long-polling requests
>
> More in some sense the HTTP servers do not need to keep track of the 
> connections used
> by long-poll as they are monopolized by the long-poll requests
>
>>> >    - more the last version of the draft introduces the Max-OFE,
>>> >  I don't recall that the concept has been discussed in the mailing list before,
>>> >  but most likely I have missed it.
>>> >  It is not clear to me the advantage of introducing a Max-OFE value
>>> >  versus to include directly the "optimistic freshness extension" time directly in the Max-Age:
>>> >  instead of having Max-Age of 60seconds and a MAX-OFE of 10seconds
>>> >  assigning directly to Max-Age a value of 70seconds
>> I thought that, too, for a while.
>> One reason why it is useful to have both max-age and max-ofe is that, with a single value, there is no indication when it would be a good time to start trying to get a new value -- at a time when the existing value can still be used.
>> See RFC5861 (the, somewhat more complex, HTTP version of this concept) for more background.
> thanks for the pointer, I didn't have it on the top of my mind..
>
> I see the usefulness of the indication of trying to get a new value 
> while still using the existing value,
> and even more the need to issue a new GET request to re-register (if 
> the client does not receive a new
> notification before Max-Age+Max-OFE ends)interest.
>
> however the current observe draft should specify a little deeply the 
> usage of it by caches ...
> if a client receive a stale value from the cache (through the issue of 
> a plain GET) it does not become aware
> of the fact that the value is a stale one,
> RFC5861 states that
>
>     Note that "stale" implies that the response will have a non-zero Age
>         header and a warning header, as per HTTP's requirements.
>
>
>
> Ciao
> Salvatore
> -- 
> Salvatore Loreto
> www.sloreto.com
>
>> Grüße, Carsten
>>

--------------080303080100050509010507
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit


  
    
  
  
    Hi Carsten,

    

    from your previous answer to my concerns I understood 

    you borrowed the idea from RFC5861 

    that allows to a cache the possibility to serving stale responses
    while it attempts to revalidate it

    

    However in draft observe-03 the mechanism draft is quite different
    as

    the
    
    Max-OFE semantic is defined as a promise by the server that  it
    intends to send another notification 

    within "Max-OFE" time period once Max-Age time period has expired so
    that if the client does not receive 

    a new notification before Max-Age plus Max-OFE ends,  it will assume
    that it was removed from the list

    of observers (e.g., due to a loss of server state)  and may issue a
    new GET request to re-register its interest.

    

    after the discussion during the first CoRe session today and some
    more thinking on the issue,

    I have concerns that there could be something dangerous in Max-OFE,
    because if the server does not set the value properly

    this mechanism could end up to generate quite a lot of useless
    traffic, especially for servers that have high variances in value
    changes.

    More, we should not expect the server doing something similar to
    what described in the draft-castellani-core-http-mapping  

    Section 4.2.2. "Cache Refresh via Observe" to obtain a precise
    Max-OFE, as get it could be too time/resource expensive for

    a constrained server.

    

    IMO It would safer that is the observer to do some statical
    calculation to figure it out if it was or not removed from the list

    of the observer (i.e. because it has not received an updated when it
    supposed to receive) 

    

    

    comments, opinions are really welcome 

    

    regards

    Salvatore

    
-- 
Salvatore Loreto
www.sloreto.com

    

    

    On 11/5/11 3:28 AM, Salvatore Loreto wrote:
    

      
      Hi Carsten,

      

      see in line

      

      On 11/4/11 6:58 PM, Carsten Bormann wrote:
      

        

          
> -in Section 1.3 Design Philosophy 
> 
> I don't agree on the similitude inserted in bracket of the first paragraph:
> 
> (A server needs to keep track of the observers
>    though, similar to how HTTP servers need to keep track of the TCP
>    connections from their clients.)


        

        
I think this point is important, as people who think that HTTP is stateless always conveniently forget that e.g., for a long-poll, connection state has to be kept for a long time at the server.  An observation relationship is rather similar to this connection state, once you disregard the different layers.

So where do you see the limitations of that allegory?

      

      now that you mentioned long-poll, the allegory starts to make some
      sense to me

      

      as I said it is not clear from the context that the allegory is
      with HTTP long-poll mechanism;

      while reading I understood the allegory was with the generic HTTP
      "persistent connections" independently

      if they were or not at moment monopolized by long-polling requests

      

      More in some sense the HTTP servers do not need to keep track of
      the connections used

      by long-poll as they are monopolized by the long-poll requests

      
      

      

        

          
>  - more the last version of the draft introduces the Max-OFE,
> I don't recall that the concept has been discussed in the mailing list before,
> but most likely I have missed it.
> It is not clear to me the advantage of introducing a Max-OFE value 
> versus to include directly the "optimistic freshness extension" time directly in the Max-Age:
> instead of having Max-Age of 60seconds and a MAX-OFE of 10seconds 
> assigning directly to Max-Age a value of 70seconds


        

        
I thought that, too, for a while.
One reason why it is useful to have both max-age and max-ofe is that, with a single value, there is no indication when it would be a good time to start trying to get a new value -- at a time when the existing value can still be used.
See RFC5861 (the, somewhat more complex, HTTP version of this concept) for more background.

      

      thanks for the pointer, I didn't have it on the top of my mind..

      

      I see the usefulness of the indication of trying to get a new
      value while still using the existing value,

      and even more the need to issue a new GET request to re-register
      (if the client does not receive a new

      notification before Max-Age+Max-OFE ends)interest.

      

      however the current observe draft should specify a little deeply
      the usage of it by caches ...

      if a client receive a stale value from the cache (through the
      issue of a plain GET) it does not become aware

      of the fact that the value is a stale one,

      RFC5861 states that

      
      

        
Note that "stale" implies that the response will have a non-zero Age
   header and a warning header, as per HTTP's requirements.

      

      

      

      Ciao

      Salvatore

      
-- 
Salvatore Loreto
www.sloreto.com

      

      

        
Grüße, Carsten



      

    

  


--------------080303080100050509010507--

From hannes.tschofenig@gmx.net  Thu Nov 17 06:58:05 2011
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 EDDC61F0C47 for ; Thu, 17 Nov 2011 06:58:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ISHp3YO8kEl4 for ; Thu, 17 Nov 2011 06:58:05 -0800 (PST)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 812AF21F844C for ; Thu, 17 Nov 2011 06:58:04 -0800 (PST)
Received: (qmail invoked by alias); 17 Nov 2011 14:58:02 -0000
Received: from 203-69-99-17.HINET-IP.hinet.net (EHLO [172.20.3.142]) [203.69.99.17] by mail.gmx.net (mp021) with SMTP; 17 Nov 2011 15:58:02 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1+uBntVoRCuNvqesWrP3j5Wu+IAprDg4YMgrNUIvl y7DPZz8lNsGKEj
From: Hannes Tschofenig 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Thu, 17 Nov 2011 22:57:58 +0800
Message-Id: 
To: tls@ietf.org
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
X-Y-GMX-Trusted: 0
Cc: core 
Subject: [core] draft-wouters-tls-oob-pubkey-02.txt - Raw Public Keys in TLS
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, 17 Nov 2011 14:58:06 -0000

Hi all,=20

based on the feedback from the TLS WG session at the IETF#82 an updated =
draft version has been submitted:=20
http://www.ietf.org/internet-drafts/draft-wouters-tls-oob-pubkey-02.txt

This version only focuses on the support for raw public keys and the =
ability to exchange hashes of public keys has been removed.=20

Ciao
Hannes


From alper.yegin@yegin.org  Thu Nov 17 07:22:58 2011
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 79E1721F9952 for ; Thu, 17 Nov 2011 07:22:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.598
X-Spam-Level: 
X-Spam-Status: No, score=-102.598 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 lUC4mZEhK0sg for ; Thu, 17 Nov 2011 07:22:58 -0800 (PST)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id CEDB121F9947 for ; Thu, 17 Nov 2011 07:22:57 -0800 (PST)
Received: from [10.1.1.2] (odakk1.odakk.com [78.111.98.194]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0M6BOM-1Qhdt13Ycs-00yJEY; Thu, 17 Nov 2011 10:22:56 -0500
From: Alper Yegin 
Content-Type: multipart/alternative; boundary="Apple-Mail=_39D73A7B-EAF8-4F03-B29C-DC500B888D41"
Date: Thu, 17 Nov 2011 17:22:50 +0200
Message-Id: <0E08042A-74F3-452A-B255-E5B654C01283@yegin.org>
To: core WG 
Mime-Version: 1.0 (Apple Message framework v1244.3)
X-Mailer: Apple Mail (2.1244.3)
X-Provags-ID: V02:K0:uO9NxIen+Xu3BH8HjdJjCFEDWiS80QCWJR/36/l9Y0I Nq0oLhHyrEWGfpO01gE4B3alULW0WJm6Tynm9er0YlzwYD3ql2 aFAU4wP8Fd61bMLo8lBYOwUqT+1aaa9GZT7gxKZSztbqoHQSLI ztHwou9D6o+kvMBSvJOlhKj16rUnlP1jqeyWeL2lr2yCD1CDKR g2UfYsdX2xdIXkyA3fHavsf/hdbcy2vdz5mSH8TqVU14CwBRJY qzfeNmrr4hZ5uRtuskpwMbAcsvthW0xhdr5KNCKzAwgjl2kF9Q Q9qlFhbmJr0Iz9xSuHpTjIKX31AYQTr+z/4JIrO6/4G0aksNk8 oCg+Vl/huYg3wkVEUwnoJfzDlABnUU618Vcu9+c/d
Subject: [core] RawPublicKeys
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, 17 Nov 2011 15:22:58 -0000

--Apple-Mail=_39D73A7B-EAF8-4F03-B29C-DC500B888D41
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

D.2.  Provisioning

   The RawPublicKey mode was designed to be easily provisioned in M2M
   deployments.  It is assumed that each device has an appropriate
   asymmetric public key pair installed, and the identity of that public
   key has been calculated as described in Appendix D.1.  During
   provisioning, the identity of each node is collected, for example by
   reading a barcode on the outside of the device or by obtaining a pre-
   compiled list of the identities.  These identities are then installed
   in the corresponding end-point, for example an M2M data collection
   server.  The identity is used for two purposes, to associate the end-
   point with further device information and to perform access control.
   During provisioning, an access control list of identities the device
   may start DTLS sessions with SHOULD also be installed.


The above text explains how the network node authenticates/authorizes =
the device.
But, how does the device authenticate/authorize the network node? For =
that, the "identity" of the network node's public key needs to be known =
to the device. But how?

Alper=

--Apple-Mail=_39D73A7B-EAF8-4F03-B29C-DC500B888D41
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii


D.2.  Provisioning


   The RawPublicKey mode was designed to be easily provisioned in M2M
   deployments.  It is assumed that each device has an appropriate
   asymmetric public key pair installed, and the identity of that public
   key has been calculated as described in Appendix D.1.  During
   provisioning, the identity of each node is collected, for example by
   reading a barcode on the outside of the device or by obtaining a pre-
   compiled list of the identities.  These identities are then installed
   in the corresponding end-point, for example an M2M data collection
   server.  The identity is used for two purposes, to associate the end-
   point with further device information and to perform access control.
   During provisioning, an access control list of identities the device
   may start DTLS sessions with SHOULD also be installed.


The above text explains how the network node authenticates/authorizes the device.
But, how does the device authenticate/authorize the network node? For that, the "identity" of the network node's public key needs to be known to the device. But how?

Alper

--Apple-Mail=_39D73A7B-EAF8-4F03-B29C-DC500B888D41--

From rstruik.ext@gmail.com  Thu Nov 17 07:50:53 2011
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 E7E0721F9977 for ; Thu, 17 Nov 2011 07:50:53 -0800 (PST)
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=[AWL=0.043,  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 VgbyzWOCsVDT for ; Thu, 17 Nov 2011 07:50:53 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1E13921F9976 for ; Thu, 17 Nov 2011 07:50:53 -0800 (PST)
Received: by ggnr5 with SMTP id r5so1462240ggn.31 for ; Thu, 17 Nov 2011 07:50:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type; bh=4ibxYmopLzwaHkLQHJXzrniTDls8IpvmK3kt95WnjwQ=; b=OLouMB5WmqSIjPd4yx621ZyK32gKYGjYFalhWXGIk1ZUG4GOQTfSmDEkMDY4ht80U4 b8tk6Mf2vL3RlGORIarWEfv+A4+/RsBEFHb7zyuuXOUe0I6C2E2UfEVfOao27pVp0fEU 0zT4cd82EpmSQLcb3SNKKiXP77rQWPIT5RtCw=
Received: by 10.224.27.81 with SMTP id h17mr11221801qac.49.1321545052645; Thu, 17 Nov 2011 07:50:52 -0800 (PST)
Received: from [192.168.1.103] (CPE0013100e2c51-CM001cea35caa6.cpe.net.cable.rogers.com. [99.231.117.243]) by mx.google.com with ESMTPS id k1sm32790551qap.10.2011.11.17.07.50.50 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 17 Nov 2011 07:50:51 -0800 (PST)
Message-ID: <4EC52D50.1030303@gmail.com>
Date: Thu, 17 Nov 2011 10:50:40 -0500
From: Rene Struik 
User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Alper Yegin 
References: <0E08042A-74F3-452A-B255-E5B654C01283@yegin.org>
In-Reply-To: <0E08042A-74F3-452A-B255-E5B654C01283@yegin.org>
X-Enigmail-Version: 1.3.3
Content-Type: multipart/alternative; boundary="------------020907000405080007000806"
Cc: core WG 
Subject: Re: [core] RawPublicKeys
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, 17 Nov 2011 15:50:54 -0000

This is a multi-part message in MIME format.
--------------020907000405080007000806
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Dear colleagues:

Alper's question definitely has merit. I have another one, though:

Having public-key derived identities printed on a device presumes that a
device's public key will never change over its lifecycle. Moreover, it
assumes that the public key is available prior to printing the bar code.

Could you please explain how this would work from a lifecycle
perspective? (chip production, module manuacturing, public key
"registration", "certification", "revocation", etc.)
[Note - even if public keys are not certified by a CA using a
certificate, one should still consider
registration/certification/revocation, aspects]

These devices are assumed to have no trusted platform on board. What if
someone else clones a device, produces a million copies, and pollutes
the market place this way (one of the scenarios described in
draft-garcia-core-security-03 (Section 3.1)). It seems that one is just
out of luck then.

>From the text in Appendix D.1 it seems one just hashes bare public keys,
without any policy oriented info or time validity period. How does this
relate to security policies? What are those policies?

Rene

On 17/11/2011 10:22 AM, Alper Yegin wrote:
>
>
>   D.2. Provisioning
>
>
>
>    The RawPublicKey mode was designed to be easily provisioned in M2M
>    deployments.  It is assumed that each device has an appropriate
>    asymmetric public key pair installed, and the identity of that public
>    key has been calculated as described in Appendix D.1 .  During
>    provisioning, the identity of each node is collected, for example by
>    reading a barcode on the outside of the device or by obtaining a pre-
>    compiled list of the identities.  These identities are then installed
>    in the corresponding end-point, for example an M2M data collection
>    server.  The identity is used for two purposes, to associate the end-
>    point with further device information and to perform access control.
>    During provisioning, an access control list of identities the device
>    may start DTLS sessions with SHOULD also be installed.
>
>
> The above text explains how the network node authenticates/authorizes
> the device.
> But, how does the device authenticate/authorize the network node? For
> that, the "identity" of the network node's public key needs to be
> known to the device. But how?
>
> Alper
>
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core


-- 
email: rstruik.ext@gmail.com
Skype: rstruik
cell: +1 (647) 867-5658
USA Google voice: +1 (415) 690-7363


--------------020907000405080007000806
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Dear colleagues:

    

    Alper's question definitely has merit. I have another one, though:

    

    Having public-key derived identities printed on a device presumes
    that a device's public key will never change over its lifecycle.
    Moreover, it assumes that the public key is available prior to
    printing the bar code. 

    

    Could you please explain how this would work from a lifecycle
    perspective? (chip production, module manuacturing, public key
    "registration", "certification", "revocation", etc.) 

    [Note - even if public keys are not certified by a CA using a
    certificate, one should still consider
    registration/certification/revocation, aspects]

    

    These devices are assumed to have no trusted platform on board. What
    if someone else clones a device, produces a million copies, and
    pollutes the market place this way (one of the scenarios described
    in draft-garcia-core-security-03 (Section 3.1)). It seems that one
    is just out of luck then.

    

    From the text in Appendix D.1 it seems one just hashes bare public
    keys, without any policy oriented info or time validity period. How
    does this relate to security policies? What are those policies?

    

    Rene

    

    On 17/11/2011 10:22 AM, Alper Yegin wrote:
    

        
D.2.  Provisioning


   The RawPublicKey mode was designed to be easily provisioned in M2M
   deployments.  It is assumed that each device has an appropriate
   asymmetric public key pair installed, and the identity of that public
   key has been calculated as described in Appendix D.1.  During
   provisioning, the identity of each node is collected, for example by
   reading a barcode on the outside of the device or by obtaining a pre-
   compiled list of the identities.  These identities are then installed
   in the corresponding end-point, for example an M2M data collection
   server.  The identity is used for two purposes, to associate the end-
   point with further device information and to perform access control.
   During provisioning, an access control list of identities the device
   may start DTLS sessions with SHOULD also be installed.

      
      


      

      


      

      
The above text explains how the network node
        authenticates/authorizes the device.

      
But, how does the device authenticate/authorize the network
        node? For that, the "identity" of the network node's public key
        needs to be known to the device. But how?

      


      

      
Alper

      

      

      

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


    

    

    

    
-- 
email: rstruik.ext@gmail.com
Skype: rstruik
cell: +1 (647) 867-5658
USA Google voice: +1 (415) 690-7363

  


--------------020907000405080007000806--

From tianlinyi@huawei.com  Thu Nov 17 08:30:42 2011
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 8037611E8175 for ; Thu, 17 Nov 2011 08:30:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.479
X-Spam-Level: 
X-Spam-Status: No, score=-4.479 tagged_above=-999 required=5 tests=[AWL=1.519,  BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_48=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 5eDnmO+LitwL for ; Thu, 17 Nov 2011 08:30:41 -0800 (PST)
Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id D301211E8127 for ; Thu, 17 Nov 2011 08:30:40 -0800 (PST)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUT0048YCEPLH@szxga04-in.huawei.com> for core@ietf.org; Fri, 18 Nov 2011 00:28:01 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUT009V3CEFMA@szxga04-in.huawei.com> for core@ietf.org; Fri, 18 Nov 2011 00:28:01 +0800 (CST)
Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AFB40244; Fri, 18 Nov 2011 00:28:01 +0800
Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 18 Nov 2011 00:27:53 +0800
Received: from SZXEML513-MBX.china.huawei.com ([169.254.8.59]) by szxeml411-hub.china.huawei.com ([10.82.67.138]) with mapi id 14.01.0323.003; Fri, 18 Nov 2011 00:27:55 +0800
Date: Thu, 17 Nov 2011 16:27:54 +0000
From: TianLinyi 
In-reply-to: <3615F3CCD55F054395A882F51C6E5FDA182022B6@szxeml513-mbx.china.huawei.com>
X-Originating-IP: [172.24.2.41]
To: Salvatore Loreto , "core@ietf.org" 
Message-id: <3615F3CCD55F054395A882F51C6E5FDA182023BE@szxeml513-mbx.china.huawei.com>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_O5H7EbisrLuY4ICAuy2kiQ)"
Content-language: zh-CN
Accept-Language: zh-CN, en-US
Thread-topic: [core] Max-OFE issue (was Re: I-D Action: draft-ietf-core-observe-03.txt)
Thread-index: AQHMpRpHEFuIzgypzUmj8C0R/aXQlZWxGmoDgAAlvRA=
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References: <20111031113719.3103.79998.idtracker@ietfa.amsl.com> <4EB41F30.3000108@ericsson.com> <515E0BF2-4FF0-49E4-B857-842749305380@tzi.org> <4EB43CEC.3050402@ericsson.com> <4EC4ECDC.1090304@ericsson.com> <3615F3CCD55F054395A882F51C6E5FDA182022B6@szxeml513-mbx.china.huawei.com>
Subject: Re: [core] Max-OFE issue (was Re: I-D Action:	draft-ietf-core-observe-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, 17 Nov 2011 16:30:42 -0000

--Boundary_(ID_O5H7EbisrLuY4ICAuy2kiQ)
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: base64

SGksIENhcnN0ZW4sIFNhbHZhdG9yZQ0KDQoNCg0KSSBhZ3JlZSB3aXRoIFNhbHZhdG9yZSB0aGF0
IGEgbmV3IEdFVCBmb3IgY3JlYXRpbmcgYSBuZXcgb2JzZXJ2YXRpb24gd291bGQgYmUgZW5vdWdo
IGlmIHRoZSBzZXJ2ZXIgZGlkbid0IHJlY2VpdmUgZnVydGhlciBub3RpZmljYXRpb25zLg0KDQoN
Cg0KSSBkaWRuJ3Qgc2VlIG11Y2ggYmVuZWZpdCBmb3IgTUFYLU9GRSBpbiBSMDMgKG5laXRoZXIg
aW4gUkZDNTg2MSkuIEluc3RlYWQgaXQgYnJpbmcgY29tcGxleGl0eSB0byBzZW5zb3JzLiBJbiBv
dXIgaW1wbGVtZW50YXRpb24gd2UgYmVsaWV2ZSBNQVgtQUdFIHdvdWxkIGJlIGVub3VnaC4gTGV0
J3MgYnJpbmcgc29tZXRoaW5nIHJlYWxseSB1c2VmdWwgYW5kIHNpbXBsZSBpbiBvYnNlcnZlLg0K
DQoNCg0KQnkgdGhlIHdheSwgaSBldmVuIHRoaW5rIEFjY2VwdCBpcyBub3QgdmVyeSB1c2VmdWwg
aW4gTTJNIGVudmlyb25tZW50LiBJcyB0aGlzIHRvbyBsYXRlIHRvIGdldCByaWQgb2YgdGhpbmdz
PyBMT0wuDQoNCg0KDQpDaGVlcnMsDQpMaW55aQ0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX18NCuWPkeS7tuS6ujogY29yZS1ib3VuY2VzQGlldGYub3JnIFtjb3JlLWJvdW5j
ZXNAaWV0Zi5vcmddIOS7o+ihqCBTYWx2YXRvcmUgTG9yZXRvIFtzYWx2YXRvcmUubG9yZXRvQGVy
aWNzc29uLmNvbV0NCuWPkemAgeaXtumXtDogMjAxMeW5tDEx5pyIMTfml6UgMTk6MTUNCuWIsDog
Y29yZUBpZXRmLm9yZw0K5Li76aKYOiBbY29yZV0gTWF4LU9GRSBpc3N1ZSAod2FzIFJlOiBJLUQg
QWN0aW9uOiBkcmFmdC1pZXRmLWNvcmUtb2JzZXJ2ZS0wMy50eHQpDQoNCkhpIENhcnN0ZW4sDQoN
CmZyb20geW91ciBwcmV2aW91cyBhbnN3ZXIgdG8gbXkgY29uY2VybnMgSSB1bmRlcnN0b29kDQp5
b3UgYm9ycm93ZWQgdGhlIGlkZWEgZnJvbSBSRkM1ODYxDQp0aGF0IGFsbG93cyB0byBhIGNhY2hl
IHRoZSBwb3NzaWJpbGl0eSB0byBzZXJ2aW5nIHN0YWxlIHJlc3BvbnNlcyB3aGlsZSBpdCBhdHRl
bXB0cyB0byByZXZhbGlkYXRlIGl0DQoNCkhvd2V2ZXIgaW4gZHJhZnQgb2JzZXJ2ZS0wMyB0aGUg
bWVjaGFuaXNtIGRyYWZ0IGlzIHF1aXRlIGRpZmZlcmVudCBhcw0KdGhlIE1heC1PRkUgc2VtYW50
aWMgaXMgZGVmaW5lZCBhcyBhIHByb21pc2UgYnkgdGhlIHNlcnZlciB0aGF0ICBpdCBpbnRlbmRz
IHRvIHNlbmQgYW5vdGhlciBub3RpZmljYXRpb24NCndpdGhpbiAiTWF4LU9GRSIgdGltZSBwZXJp
b2Qgb25jZSBNYXgtQWdlIHRpbWUgcGVyaW9kIGhhcyBleHBpcmVkIHNvIHRoYXQgaWYgdGhlIGNs
aWVudCBkb2VzIG5vdCByZWNlaXZlDQphIG5ldyBub3RpZmljYXRpb24gYmVmb3JlIE1heC1BZ2Ug
cGx1cyBNYXgtT0ZFIGVuZHMsICBpdCB3aWxsIGFzc3VtZSB0aGF0IGl0IHdhcyByZW1vdmVkIGZy
b20gdGhlIGxpc3QNCm9mIG9ic2VydmVycyAoZS5nLiwgZHVlIHRvIGEgbG9zcyBvZiBzZXJ2ZXIg
c3RhdGUpICBhbmQgbWF5IGlzc3VlIGEgbmV3IEdFVCByZXF1ZXN0IHRvIHJlLXJlZ2lzdGVyIGl0
cyBpbnRlcmVzdC4NCg0KYWZ0ZXIgdGhlIGRpc2N1c3Npb24gZHVyaW5nIHRoZSBmaXJzdCBDb1Jl
IHNlc3Npb24gdG9kYXkgYW5kIHNvbWUgbW9yZSB0aGlua2luZyBvbiB0aGUgaXNzdWUsDQpJIGhh
dmUgY29uY2VybnMgdGhhdCB0aGVyZSBjb3VsZCBiZSBzb21ldGhpbmcgZGFuZ2Vyb3VzIGluIE1h
eC1PRkUsIGJlY2F1c2UgaWYgdGhlIHNlcnZlciBkb2VzIG5vdCBzZXQgdGhlIHZhbHVlIHByb3Bl
cmx5DQp0aGlzIG1lY2hhbmlzbSBjb3VsZCBlbmQgdXAgdG8gZ2VuZXJhdGUgcXVpdGUgYSBsb3Qg
b2YgdXNlbGVzcyB0cmFmZmljLCBlc3BlY2lhbGx5IGZvciBzZXJ2ZXJzIHRoYXQgaGF2ZSBoaWdo
IHZhcmlhbmNlcyBpbiB2YWx1ZSBjaGFuZ2VzLg0KTW9yZSwgd2Ugc2hvdWxkIG5vdCBleHBlY3Qg
dGhlIHNlcnZlciBkb2luZyBzb21ldGhpbmcgc2ltaWxhciB0byB3aGF0IGRlc2NyaWJlZCBpbiB0
aGUgZHJhZnQtY2FzdGVsbGFuaS1jb3JlLWh0dHAtbWFwcGluZw0KU2VjdGlvbiA0LjIuMi4gIkNh
Y2hlIFJlZnJlc2ggdmlhIE9ic2VydmUiIHRvIG9idGFpbiBhIHByZWNpc2UgTWF4LU9GRSwgYXMg
Z2V0IGl0IGNvdWxkIGJlIHRvbyB0aW1lL3Jlc291cmNlIGV4cGVuc2l2ZSBmb3INCmEgY29uc3Ry
YWluZWQgc2VydmVyLg0KDQpJTU8gSXQgd291bGQgc2FmZXIgdGhhdCBpcyB0aGUgb2JzZXJ2ZXIg
dG8gZG8gc29tZSBzdGF0aWNhbCBjYWxjdWxhdGlvbiB0byBmaWd1cmUgaXQgb3V0IGlmIGl0IHdh
cyBvciBub3QgcmVtb3ZlZCBmcm9tIHRoZSBsaXN0DQpvZiB0aGUgb2JzZXJ2ZXIgKGkuZS4gYmVj
YXVzZSBpdCBoYXMgbm90IHJlY2VpdmVkIGFuIHVwZGF0ZWQgd2hlbiBpdCBzdXBwb3NlZCB0byBy
ZWNlaXZlKQ0KDQoNCmNvbW1lbnRzLCBvcGluaW9ucyBhcmUgcmVhbGx5IHdlbGNvbWUNCg0KcmVn
YXJkcw0KU2FsdmF0b3JlDQoNCi0tDQpTYWx2YXRvcmUgTG9yZXRvDQp3d3cuc2xvcmV0by5jb208
aHR0cDovL3d3dy5zbG9yZXRvLmNvbT4NCg0KDQpPbiAxMS81LzExIDM6MjggQU0sIFNhbHZhdG9y
ZSBMb3JldG8gd3JvdGU6DQpIaSBDYXJzdGVuLA0KDQpzZWUgaW4gbGluZQ0KDQpPbiAxMS80LzEx
IDY6NTggUE0sIENhcnN0ZW4gQm9ybWFubiB3cm90ZToNCg0KPiAtaW4gU2VjdGlvbiAxLjMgRGVz
aWduIFBoaWxvc29waHkNCj4NCj4gSSBkb24ndCBhZ3JlZSBvbiB0aGUgc2ltaWxpdHVkZSBpbnNl
cnRlZCBpbiBicmFja2V0IG9mIHRoZSBmaXJzdCBwYXJhZ3JhcGg6DQo+DQo+IChBIHNlcnZlciBu
ZWVkcyB0byBrZWVwIHRyYWNrIG9mIHRoZSBvYnNlcnZlcnMNCj4gICAgdGhvdWdoLCBzaW1pbGFy
IHRvIGhvdyBIVFRQIHNlcnZlcnMgbmVlZCB0byBrZWVwIHRyYWNrIG9mIHRoZSBUQ1ANCj4gICAg
Y29ubmVjdGlvbnMgZnJvbSB0aGVpciBjbGllbnRzLikNCg0KDQpJIHRoaW5rIHRoaXMgcG9pbnQg
aXMgaW1wb3J0YW50LCBhcyBwZW9wbGUgd2hvIHRoaW5rIHRoYXQgSFRUUCBpcyBzdGF0ZWxlc3Mg
YWx3YXlzIGNvbnZlbmllbnRseSBmb3JnZXQgdGhhdCBlLmcuLCBmb3IgYSBsb25nLXBvbGwsIGNv
bm5lY3Rpb24gc3RhdGUgaGFzIHRvIGJlIGtlcHQgZm9yIGEgbG9uZyB0aW1lIGF0IHRoZSBzZXJ2
ZXIuICBBbiBvYnNlcnZhdGlvbiByZWxhdGlvbnNoaXAgaXMgcmF0aGVyIHNpbWlsYXIgdG8gdGhp
cyBjb25uZWN0aW9uIHN0YXRlLCBvbmNlIHlvdSBkaXNyZWdhcmQgdGhlIGRpZmZlcmVudCBsYXll
cnMuDQoNClNvIHdoZXJlIGRvIHlvdSBzZWUgdGhlIGxpbWl0YXRpb25zIG9mIHRoYXQgYWxsZWdv
cnk/DQoNCm5vdyB0aGF0IHlvdSBtZW50aW9uZWQgbG9uZy1wb2xsLCB0aGUgYWxsZWdvcnkgc3Rh
cnRzIHRvIG1ha2Ugc29tZSBzZW5zZSB0byBtZQ0KDQphcyBJIHNhaWQgaXQgaXMgbm90IGNsZWFy
IGZyb20gdGhlIGNvbnRleHQgdGhhdCB0aGUgYWxsZWdvcnkgaXMgd2l0aCBIVFRQIGxvbmctcG9s
bCBtZWNoYW5pc207DQp3aGlsZSByZWFkaW5nIEkgdW5kZXJzdG9vZCB0aGUgYWxsZWdvcnkgd2Fz
IHdpdGggdGhlIGdlbmVyaWMgSFRUUCAicGVyc2lzdGVudCBjb25uZWN0aW9ucyIgaW5kZXBlbmRl
bnRseQ0KaWYgdGhleSB3ZXJlIG9yIG5vdCBhdCBtb21lbnQgbW9ub3BvbGl6ZWQgYnkgbG9uZy1w
b2xsaW5nIHJlcXVlc3RzDQoNCk1vcmUgaW4gc29tZSBzZW5zZSB0aGUgSFRUUCBzZXJ2ZXJzIGRv
IG5vdCBuZWVkIHRvIGtlZXAgdHJhY2sgb2YgdGhlIGNvbm5lY3Rpb25zIHVzZWQNCmJ5IGxvbmct
cG9sbCBhcyB0aGV5IGFyZSBtb25vcG9saXplZCBieSB0aGUgbG9uZy1wb2xsIHJlcXVlc3RzDQoN
Cg0KPiAgLSBtb3JlIHRoZSBsYXN0IHZlcnNpb24gb2YgdGhlIGRyYWZ0IGludHJvZHVjZXMgdGhl
IE1heC1PRkUsDQo+IEkgZG9uJ3QgcmVjYWxsIHRoYXQgdGhlIGNvbmNlcHQgaGFzIGJlZW4gZGlz
Y3Vzc2VkIGluIHRoZSBtYWlsaW5nIGxpc3QgYmVmb3JlLA0KPiBidXQgbW9zdCBsaWtlbHkgSSBo
YXZlIG1pc3NlZCBpdC4NCj4gSXQgaXMgbm90IGNsZWFyIHRvIG1lIHRoZSBhZHZhbnRhZ2Ugb2Yg
aW50cm9kdWNpbmcgYSBNYXgtT0ZFIHZhbHVlDQo+IHZlcnN1cyB0byBpbmNsdWRlIGRpcmVjdGx5
IHRoZSAib3B0aW1pc3RpYyBmcmVzaG5lc3MgZXh0ZW5zaW9uIiB0aW1lIGRpcmVjdGx5IGluIHRo
ZSBNYXgtQWdlOg0KPiBpbnN0ZWFkIG9mIGhhdmluZyBNYXgtQWdlIG9mIDYwc2Vjb25kcyBhbmQg
YSBNQVgtT0ZFIG9mIDEwc2Vjb25kcw0KPiBhc3NpZ25pbmcgZGlyZWN0bHkgdG8gTWF4LUFnZSBh
IHZhbHVlIG9mIDcwc2Vjb25kcw0KDQoNCkkgdGhvdWdodCB0aGF0LCB0b28sIGZvciBhIHdoaWxl
Lg0KT25lIHJlYXNvbiB3aHkgaXQgaXMgdXNlZnVsIHRvIGhhdmUgYm90aCBtYXgtYWdlIGFuZCBt
YXgtb2ZlIGlzIHRoYXQsIHdpdGggYSBzaW5nbGUgdmFsdWUsIHRoZXJlIGlzIG5vIGluZGljYXRp
b24gd2hlbiBpdCB3b3VsZCBiZSBhIGdvb2QgdGltZSB0byBzdGFydCB0cnlpbmcgdG8gZ2V0IGEg
bmV3IHZhbHVlIC0tIGF0IGEgdGltZSB3aGVuIHRoZSBleGlzdGluZyB2YWx1ZSBjYW4gc3RpbGwg
YmUgdXNlZC4NClNlZSBSRkM1ODYxICh0aGUsIHNvbWV3aGF0IG1vcmUgY29tcGxleCwgSFRUUCB2
ZXJzaW9uIG9mIHRoaXMgY29uY2VwdCkgZm9yIG1vcmUgYmFja2dyb3VuZC4NCg0KdGhhbmtzIGZv
ciB0aGUgcG9pbnRlciwgSSBkaWRuJ3QgaGF2ZSBpdCBvbiB0aGUgdG9wIG9mIG15IG1pbmQuLg0K
DQpJIHNlZSB0aGUgdXNlZnVsbmVzcyBvZiB0aGUgaW5kaWNhdGlvbiBvZiB0cnlpbmcgdG8gZ2V0
IGEgbmV3IHZhbHVlIHdoaWxlIHN0aWxsIHVzaW5nIHRoZSBleGlzdGluZyB2YWx1ZSwNCmFuZCBl
dmVuIG1vcmUgdGhlIG5lZWQgdG8gaXNzdWUgYSBuZXcgR0VUIHJlcXVlc3QgdG8gcmUtcmVnaXN0
ZXIgKGlmIHRoZSBjbGllbnQgZG9lcyBub3QgcmVjZWl2ZSBhIG5ldw0Kbm90aWZpY2F0aW9uIGJl
Zm9yZSBNYXgtQWdlK01heC1PRkUgZW5kcylpbnRlcmVzdC4NCg0KaG93ZXZlciB0aGUgY3VycmVu
dCBvYnNlcnZlIGRyYWZ0IHNob3VsZCBzcGVjaWZ5IGEgbGl0dGxlIGRlZXBseSB0aGUgdXNhZ2Ug
b2YgaXQgYnkgY2FjaGVzIC4uLg0KaWYgYSBjbGllbnQgcmVjZWl2ZSBhIHN0YWxlIHZhbHVlIGZy
b20gdGhlIGNhY2hlICh0aHJvdWdoIHRoZSBpc3N1ZSBvZiBhIHBsYWluIEdFVCkgaXQgZG9lcyBu
b3QgYmVjb21lIGF3YXJlDQpvZiB0aGUgZmFjdCB0aGF0IHRoZSB2YWx1ZSBpcyBhIHN0YWxlIG9u
ZSwNClJGQzU4NjEgc3RhdGVzIHRoYXQNCg0KTm90ZSB0aGF0ICJzdGFsZSIgaW1wbGllcyB0aGF0
IHRoZSByZXNwb25zZSB3aWxsIGhhdmUgYSBub24temVybyBBZ2UNCiAgIGhlYWRlciBhbmQgYSB3
YXJuaW5nIGhlYWRlciwgYXMgcGVyIEhUVFAncyByZXF1aXJlbWVudHMuDQoNCg0KQ2lhbw0KU2Fs
dmF0b3JlDQoNCi0tDQpTYWx2YXRvcmUgTG9yZXRvDQp3d3cuc2xvcmV0by5jb208aHR0cDovL3d3
dy5zbG9yZXRvLmNvbT4NCg0KDQpHcsO8w59lLCBDYXJzdGVuDQoNCg0K

--Boundary_(ID_O5H7EbisrLuY4ICAuy2kiQ)
Content-type: text/html; charset=utf-8
Content-transfer-encoding: base64

PGh0bWwgZGlyPSJsdHIiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUi
IGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8c3R5bGUgaWQ9Im93YVBhcmFT
dHlsZSI+UCB7DQoJTUFSR0lOLVRPUDogMHB4OyBNQVJHSU4tQk9UVE9NOiAwcHgNCn0NClAgew0K
CU1BUkdJTi1UT1A6IDBweDsgTUFSR0lOLUJPVFRPTTogMHB4DQp9DQo8L3N0eWxlPg0KPC9oZWFk
Pg0KPGJvZHkgYmdjb2xvcj0iI2ZmZmZmZiIgZlBTdHlsZT0iMSIgb2NzaT0iMCI+DQo8ZGl2IHN0
eWxlPSJkaXJlY3Rpb246IGx0cjtmb250LWZhbWlseTogVGFob21hO2NvbG9yOiAjMDAwMDAwO2Zv
bnQtc2l6ZTogMTBwdDsiPg0KPHA+SGksIENhcnN0ZW4sIFNhbHZhdG9yZTwvcD4NCjxwPiZuYnNw
OzwvcD4NCjxwPkkgYWdyZWUgd2l0aCBTYWx2YXRvcmUgdGhhdCBhIG5ldyBHRVQgZm9yIGNyZWF0
aW5nIGEgbmV3IG9ic2VydmF0aW9uIHdvdWxkIGJlIGVub3VnaCBpZiB0aGUgc2VydmVyIGRpZG4n
dCByZWNlaXZlIGZ1cnRoZXIgbm90aWZpY2F0aW9ucy4NCjwvcD4NCjxwPiZuYnNwOzwvcD4NCjxw
PkkgZGlkbid0IHNlZSBtdWNoJm5ic3A7YmVuZWZpdCBmb3IgTUFYLU9GRSBpbiBSMDMgKG5laXRo
ZXIgaW4gUkZDNTg2MSkuIEluc3RlYWQgaXQgYnJpbmcgY29tcGxleGl0eSB0byBzZW5zb3JzLiBJ
biBvdXIgaW1wbGVtZW50YXRpb24gd2UgYmVsaWV2ZSBNQVgtQUdFIHdvdWxkIGJlIGVub3VnaC4g
TGV0J3MgYnJpbmcgc29tZXRoaW5nIHJlYWxseSB1c2VmdWwgYW5kIHNpbXBsZSBpbiBvYnNlcnZl
Lg0KPC9wPg0KPHA+Jm5ic3A7PC9wPg0KPHA+QnkgdGhlIHdheSwgaSBldmVuIHRoaW5rIEFjY2Vw
dCBpcyBub3QgdmVyeSB1c2VmdWwgaW4gTTJNIGVudmlyb25tZW50LiBJcyB0aGlzIHRvbyBsYXRl
IHRvIGdldCByaWQgb2YgdGhpbmdzPyBMT0wuPC9wPg0KPHA+Jm5ic3A7PC9wPg0KPHA+Q2hlZXJz
LDxicj4NCkxpbnlpPGJyPg0KPC9wPg0KPGRpdiBzdHlsZT0iRk9OVC1GQU1JTFk6IFRpbWVzIE5l
dyBSb21hbjsgQ09MT1I6ICMwMDAwMDA7IEZPTlQtU0laRTogMTZweCI+DQo8ZGl2PjwvZGl2Pg0K
PGRpdj4NCjxkaXYgc3R5bGU9IkZPTlQtRkFNSUxZOiBUYWhvbWE7IERJUkVDVElPTjogbHRyOyBD
T0xPUjogIzAwMDAwMDsgRk9OVC1TSVpFOiAxMHB0Ij4NCjxwPiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOzwvcD4NCjxkaXYgc3R5bGU9IkZPTlQtRkFNSUxZOiBUaW1lcyBOZXcgUm9tYW47IENPTE9S
OiAjMDAwMDAwOyBGT05ULVNJWkU6IDE2cHgiPg0KPGhyIHRhYmluZGV4PSItMSI+DQo8ZGl2IHN0
eWxlPSJESVJFQ1RJT046IGx0ciIgaWQ9ImRpdlJwRjU5ODE2MCI+PGZvbnQgY29sb3I9IiMwMDAw
MDAiIHNpemU9IjIiIGZhY2U9IlRhaG9tYSI+PGI+5Y+R5Lu25Lq6OjwvYj4gY29yZS1ib3VuY2Vz
QGlldGYub3JnIFtjb3JlLWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBTYWx2YXRvcmUgTG9yZXRv
IFtzYWx2YXRvcmUubG9yZXRvQGVyaWNzc29uLmNvbV08YnI+DQo8Yj7lj5HpgIHml7bpl7Q6PC9i
PiAyMDEx5bm0MTHmnIgxN+aXpSAxOToxNTxicj4NCjxiPuWIsDo8L2I+IGNvcmVAaWV0Zi5vcmc8
YnI+DQo8Yj7kuLvpopg6PC9iPiBbY29yZV0gTWF4LU9GRSBpc3N1ZSAod2FzIFJlOiBJLUQgQWN0
aW9uOiBkcmFmdC1pZXRmLWNvcmUtb2JzZXJ2ZS0wMy50eHQpPGJyPg0KPC9mb250Pjxicj4NCjwv
ZGl2Pg0KPGRpdj48L2Rpdj4NCjxkaXY+SGkgQ2Fyc3Rlbiw8YnI+DQo8YnI+DQpmcm9tIHlvdXIg
cHJldmlvdXMgYW5zd2VyIHRvIG15IGNvbmNlcm5zIEkgdW5kZXJzdG9vZCA8YnI+DQp5b3UgYm9y
cm93ZWQgdGhlIGlkZWEgZnJvbSBSRkM1ODYxIDxicj4NCnRoYXQgYWxsb3dzIHRvIGEgY2FjaGUg
dGhlIHBvc3NpYmlsaXR5IHRvIHNlcnZpbmcgc3RhbGUgcmVzcG9uc2VzIHdoaWxlIGl0IGF0dGVt
cHRzIHRvIHJldmFsaWRhdGUgaXQ8YnI+DQo8YnI+DQpIb3dldmVyIGluIGRyYWZ0IG9ic2VydmUt
MDMgdGhlIG1lY2hhbmlzbSBkcmFmdCBpcyBxdWl0ZSBkaWZmZXJlbnQgYXM8YnI+DQp0aGUgTWF4
LU9GRSBzZW1hbnRpYyBpcyBkZWZpbmVkIGFzIGEgcHJvbWlzZSBieSB0aGUgc2VydmVyIHRoYXQm
bmJzcDsgaXQgaW50ZW5kcyB0byBzZW5kIGFub3RoZXIgbm90aWZpY2F0aW9uDQo8YnI+DQp3aXRo
aW4gJnF1b3Q7TWF4LU9GRSZxdW90OyB0aW1lIHBlcmlvZCBvbmNlIE1heC1BZ2UgdGltZSBwZXJp
b2QgaGFzIGV4cGlyZWQgc28gdGhhdCBpZiB0aGUgY2xpZW50IGRvZXMgbm90IHJlY2VpdmUNCjxi
cj4NCmEgbmV3IG5vdGlmaWNhdGlvbiBiZWZvcmUgTWF4LUFnZSBwbHVzIE1heC1PRkUgZW5kcywm
bmJzcDsgaXQgd2lsbCBhc3N1bWUgdGhhdCBpdCB3YXMgcmVtb3ZlZCBmcm9tIHRoZSBsaXN0PGJy
Pg0Kb2Ygb2JzZXJ2ZXJzIChlLmcuLCBkdWUgdG8gYSBsb3NzIG9mIHNlcnZlciBzdGF0ZSkmbmJz
cDsgYW5kIG1heSBpc3N1ZSBhIG5ldyBHRVQgcmVxdWVzdCB0byByZS1yZWdpc3RlciBpdHMgaW50
ZXJlc3QuPGJyPg0KPGJyPg0KYWZ0ZXIgdGhlIGRpc2N1c3Npb24gZHVyaW5nIHRoZSBmaXJzdCBD
b1JlIHNlc3Npb24gdG9kYXkgYW5kIHNvbWUgbW9yZSB0aGlua2luZyBvbiB0aGUgaXNzdWUsPGJy
Pg0KSSBoYXZlIGNvbmNlcm5zIHRoYXQgdGhlcmUgY291bGQgYmUgc29tZXRoaW5nIGRhbmdlcm91
cyBpbiBNYXgtT0ZFLCBiZWNhdXNlIGlmIHRoZSBzZXJ2ZXIgZG9lcyBub3Qgc2V0IHRoZSB2YWx1
ZSBwcm9wZXJseTxicj4NCnRoaXMgbWVjaGFuaXNtIGNvdWxkIGVuZCB1cCB0byBnZW5lcmF0ZSBx
dWl0ZSBhIGxvdCBvZiB1c2VsZXNzIHRyYWZmaWMsIGVzcGVjaWFsbHkgZm9yIHNlcnZlcnMgdGhh
dCBoYXZlIGhpZ2ggdmFyaWFuY2VzIGluIHZhbHVlIGNoYW5nZXMuPGJyPg0KTW9yZSwgd2Ugc2hv
dWxkIG5vdCBleHBlY3QgdGhlIHNlcnZlciBkb2luZyBzb21ldGhpbmcgc2ltaWxhciB0byB3aGF0
IGRlc2NyaWJlZCBpbiB0aGUgZHJhZnQtY2FzdGVsbGFuaS1jb3JlLWh0dHAtbWFwcGluZyZuYnNw
Ow0KPGJyPg0KU2VjdGlvbiA0LjIuMi4gJnF1b3Q7Q2FjaGUgUmVmcmVzaCB2aWEgT2JzZXJ2ZSZx
dW90OyB0byBvYnRhaW4gYSBwcmVjaXNlIE1heC1PRkUsIGFzIGdldCBpdCBjb3VsZCBiZSB0b28g
dGltZS9yZXNvdXJjZSBleHBlbnNpdmUgZm9yPGJyPg0KYSBjb25zdHJhaW5lZCBzZXJ2ZXIuPGJy
Pg0KPGJyPg0KSU1PIEl0IHdvdWxkIHNhZmVyIHRoYXQgaXMgdGhlIG9ic2VydmVyIHRvIGRvIHNv
bWUgc3RhdGljYWwgY2FsY3VsYXRpb24gdG8gZmlndXJlIGl0IG91dCBpZiBpdCB3YXMgb3Igbm90
IHJlbW92ZWQgZnJvbSB0aGUgbGlzdDxicj4NCm9mIHRoZSBvYnNlcnZlciAoaS5lLiBiZWNhdXNl
IGl0IGhhcyBub3QgcmVjZWl2ZWQgYW4gdXBkYXRlZCB3aGVuIGl0IHN1cHBvc2VkIHRvIHJlY2Vp
dmUpDQo8YnI+DQo8YnI+DQo8YnI+DQpjb21tZW50cywgb3BpbmlvbnMgYXJlIHJlYWxseSB3ZWxj
b21lIDxicj4NCjxicj4NCnJlZ2FyZHM8YnI+DQpTYWx2YXRvcmU8YnI+DQo8cHJlIGNsYXNzPSJt
b3otc2lnbmF0dXJlIiBjb2xzPSI3MiI+LS0gDQpTYWx2YXRvcmUgTG9yZXRvDQo8YSBjbGFzcz0i
bW96LXR4dC1saW5rLWFiYnJldmlhdGVkIiBocmVmPSJodHRwOi8vd3d3LnNsb3JldG8uY29tIiB0
YXJnZXQ9Il9ibGFuayI+d3d3LnNsb3JldG8uY29tPC9hPjwvcHJlPg0KPGJyPg0KPGJyPg0KT24g
MTEvNS8xMSAzOjI4IEFNLCBTYWx2YXRvcmUgTG9yZXRvIHdyb3RlOg0KPGJsb2NrcXVvdGUgdHlw
ZT0iY2l0ZSI+SGkgQ2Fyc3Rlbiw8YnI+DQo8YnI+DQpzZWUgaW4gbGluZTxicj4NCjxicj4NCk9u
IDExLzQvMTEgNjo1OCBQTSwgQ2Fyc3RlbiBCb3JtYW5uIHdyb3RlOg0KPGJsb2NrcXVvdGUgdHlw
ZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSBzdHlsZT0iQ09MT1I6ICMwMDAwMDAiIHR5cGU9ImNpdGUi
Pg0KPHByZT48c3BhbiBjbGFzcz0ibW96LXR4dC1jaXRldGFncyI+Jmd0OyA8L3NwYW4+LWluIFNl
Y3Rpb24gMS4zIERlc2lnbiBQaGlsb3NvcGh5IA0KPHNwYW4gY2xhc3M9Im1vei10eHQtY2l0ZXRh
Z3MiPiZndDsgPC9zcGFuPg0KPHNwYW4gY2xhc3M9Im1vei10eHQtY2l0ZXRhZ3MiPiZndDsgPC9z
cGFuPkkgZG9uJ3QgYWdyZWUgb24gdGhlIHNpbWlsaXR1ZGUgaW5zZXJ0ZWQgaW4gYnJhY2tldCBv
ZiB0aGUgZmlyc3QgcGFyYWdyYXBoOg0KPHNwYW4gY2xhc3M9Im1vei10eHQtY2l0ZXRhZ3MiPiZn
dDsgPC9zcGFuPg0KPHNwYW4gY2xhc3M9Im1vei10eHQtY2l0ZXRhZ3MiPiZndDsgPC9zcGFuPihB
IHNlcnZlciBuZWVkcyB0byBrZWVwIHRyYWNrIG9mIHRoZSBvYnNlcnZlcnMNCjxzcGFuIGNsYXNz
PSJtb3otdHh0LWNpdGV0YWdzIj4mZ3Q7IDwvc3Bhbj4gICB0aG91Z2gsIHNpbWlsYXIgdG8gaG93
IEhUVFAgc2VydmVycyBuZWVkIHRvIGtlZXAgdHJhY2sgb2YgdGhlIFRDUA0KPHNwYW4gY2xhc3M9
Im1vei10eHQtY2l0ZXRhZ3MiPiZndDsgPC9zcGFuPiAgIGNvbm5lY3Rpb25zIGZyb20gdGhlaXIg
Y2xpZW50cy4pDQo8L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+SSB0aGluayB0aGlzIHBvaW50
IGlzIGltcG9ydGFudCwgYXMgcGVvcGxlIHdobyB0aGluayB0aGF0IEhUVFAgaXMgc3RhdGVsZXNz
IGFsd2F5cyBjb252ZW5pZW50bHkgZm9yZ2V0IHRoYXQgZS5nLiwgZm9yIGEgbG9uZy1wb2xsLCBj
b25uZWN0aW9uIHN0YXRlIGhhcyB0byBiZSBrZXB0IGZvciBhIGxvbmcgdGltZSBhdCB0aGUgc2Vy
dmVyLiAgQW4gb2JzZXJ2YXRpb24gcmVsYXRpb25zaGlwIGlzIHJhdGhlciBzaW1pbGFyIHRvIHRo
aXMgY29ubmVjdGlvbiBzdGF0ZSwgb25jZSB5b3UgZGlzcmVnYXJkIHRoZSBkaWZmZXJlbnQgbGF5
ZXJzLg0KDQpTbyB3aGVyZSBkbyB5b3Ugc2VlIHRoZSBsaW1pdGF0aW9ucyBvZiB0aGF0IGFsbGVn
b3J5PzwvcHJlPg0KPC9ibG9ja3F1b3RlPg0Kbm93IHRoYXQgeW91IG1lbnRpb25lZCBsb25nLXBv
bGwsIHRoZSBhbGxlZ29yeSBzdGFydHMgdG8gbWFrZSBzb21lIHNlbnNlIHRvIG1lPGJyPg0KPGJy
Pg0KYXMgSSBzYWlkIGl0IGlzIG5vdCBjbGVhciBmcm9tIHRoZSBjb250ZXh0IHRoYXQgdGhlIGFs
bGVnb3J5IGlzIHdpdGggSFRUUCBsb25nLXBvbGwgbWVjaGFuaXNtOzxicj4NCndoaWxlIHJlYWRp
bmcgSSB1bmRlcnN0b29kIHRoZSBhbGxlZ29yeSB3YXMgd2l0aCB0aGUgZ2VuZXJpYyBIVFRQICZx
dW90O3BlcnNpc3RlbnQgY29ubmVjdGlvbnMmcXVvdDsgaW5kZXBlbmRlbnRseTxicj4NCmlmIHRo
ZXkgd2VyZSBvciBub3QgYXQgbW9tZW50IG1vbm9wb2xpemVkIGJ5IGxvbmctcG9sbGluZyByZXF1
ZXN0czxicj4NCjxicj4NCk1vcmUgaW4gc29tZSBzZW5zZSB0aGUgSFRUUCBzZXJ2ZXJzIGRvIG5v
dCBuZWVkIHRvIGtlZXAgdHJhY2sgb2YgdGhlIGNvbm5lY3Rpb25zIHVzZWQ8YnI+DQpieSBsb25n
LXBvbGwgYXMgdGhleSBhcmUgbW9ub3BvbGl6ZWQgYnkgdGhlIGxvbmctcG9sbCByZXF1ZXN0czxi
cj4NCjxicj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgc3R5bGU9IkNP
TE9SOiAjMDAwMDAwIiB0eXBlPSJjaXRlIj4NCjxwcmU+PHNwYW4gY2xhc3M9Im1vei10eHQtY2l0
ZXRhZ3MiPiZndDsgPC9zcGFuPiAtIG1vcmUgdGhlIGxhc3QgdmVyc2lvbiBvZiB0aGUgZHJhZnQg
aW50cm9kdWNlcyB0aGUgTWF4LU9GRSwNCjxzcGFuIGNsYXNzPSJtb3otdHh0LWNpdGV0YWdzIj4m
Z3Q7IDwvc3Bhbj5JIGRvbid0IHJlY2FsbCB0aGF0IHRoZSBjb25jZXB0IGhhcyBiZWVuIGRpc2N1
c3NlZCBpbiB0aGUgbWFpbGluZyBsaXN0IGJlZm9yZSwNCjxzcGFuIGNsYXNzPSJtb3otdHh0LWNp
dGV0YWdzIj4mZ3Q7IDwvc3Bhbj5idXQgbW9zdCBsaWtlbHkgSSBoYXZlIG1pc3NlZCBpdC4NCjxz
cGFuIGNsYXNzPSJtb3otdHh0LWNpdGV0YWdzIj4mZ3Q7IDwvc3Bhbj5JdCBpcyBub3QgY2xlYXIg
dG8gbWUgdGhlIGFkdmFudGFnZSBvZiBpbnRyb2R1Y2luZyBhIE1heC1PRkUgdmFsdWUgDQo8c3Bh
biBjbGFzcz0ibW96LXR4dC1jaXRldGFncyI+Jmd0OyA8L3NwYW4+dmVyc3VzIHRvIGluY2x1ZGUg
ZGlyZWN0bHkgdGhlICZxdW90O29wdGltaXN0aWMgZnJlc2huZXNzIGV4dGVuc2lvbiZxdW90OyB0
aW1lIGRpcmVjdGx5IGluIHRoZSBNYXgtQWdlOg0KPHNwYW4gY2xhc3M9Im1vei10eHQtY2l0ZXRh
Z3MiPiZndDsgPC9zcGFuPmluc3RlYWQgb2YgaGF2aW5nIE1heC1BZ2Ugb2YgNjBzZWNvbmRzIGFu
ZCBhIE1BWC1PRkUgb2YgMTBzZWNvbmRzIA0KPHNwYW4gY2xhc3M9Im1vei10eHQtY2l0ZXRhZ3Mi
PiZndDsgPC9zcGFuPmFzc2lnbmluZyBkaXJlY3RseSB0byBNYXgtQWdlIGEgdmFsdWUgb2YgNzBz
ZWNvbmRzDQo8L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+SSB0aG91Z2h0IHRoYXQsIHRvbywg
Zm9yIGEgd2hpbGUuDQpPbmUgcmVhc29uIHdoeSBpdCBpcyB1c2VmdWwgdG8gaGF2ZSBib3RoIG1h
eC1hZ2UgYW5kIG1heC1vZmUgaXMgdGhhdCwgd2l0aCBhIHNpbmdsZSB2YWx1ZSwgdGhlcmUgaXMg
bm8gaW5kaWNhdGlvbiB3aGVuIGl0IHdvdWxkIGJlIGEgZ29vZCB0aW1lIHRvIHN0YXJ0IHRyeWlu
ZyB0byBnZXQgYSBuZXcgdmFsdWUgLS0gYXQgYSB0aW1lIHdoZW4gdGhlIGV4aXN0aW5nIHZhbHVl
IGNhbiBzdGlsbCBiZSB1c2VkLg0KU2VlIFJGQzU4NjEgKHRoZSwgc29tZXdoYXQgbW9yZSBjb21w
bGV4LCBIVFRQIHZlcnNpb24gb2YgdGhpcyBjb25jZXB0KSBmb3IgbW9yZSBiYWNrZ3JvdW5kLjwv
cHJlPg0KPC9ibG9ja3F1b3RlPg0KdGhhbmtzIGZvciB0aGUgcG9pbnRlciwgSSBkaWRuJ3QgaGF2
ZSBpdCBvbiB0aGUgdG9wIG9mIG15IG1pbmQuLjxicj4NCjxicj4NCkkgc2VlIHRoZSB1c2VmdWxu
ZXNzIG9mIHRoZSBpbmRpY2F0aW9uIG9mIHRyeWluZyB0byBnZXQgYSBuZXcgdmFsdWUgd2hpbGUg
c3RpbGwgdXNpbmcgdGhlIGV4aXN0aW5nIHZhbHVlLDxicj4NCmFuZCBldmVuIG1vcmUgdGhlIG5l
ZWQgdG8gaXNzdWUgYSBuZXcgR0VUIHJlcXVlc3QgdG8gcmUtcmVnaXN0ZXIgKGlmIHRoZSBjbGll
bnQgZG9lcyBub3QgcmVjZWl2ZSBhIG5ldzxicj4NCm5vdGlmaWNhdGlvbiBiZWZvcmUgTWF4LUFn
ZSYjNDM7TWF4LU9GRSBlbmRzKWludGVyZXN0Ljxicj4NCjxicj4NCmhvd2V2ZXIgdGhlIGN1cnJl
bnQgb2JzZXJ2ZSBkcmFmdCBzaG91bGQgc3BlY2lmeSBhIGxpdHRsZSBkZWVwbHkgdGhlIHVzYWdl
IG9mIGl0IGJ5IGNhY2hlcyAuLi48YnI+DQppZiBhIGNsaWVudCByZWNlaXZlIGEgc3RhbGUgdmFs
dWUgZnJvbSB0aGUgY2FjaGUgKHRocm91Z2ggdGhlIGlzc3VlIG9mIGEgcGxhaW4gR0VUKSBpdCBk
b2VzIG5vdCBiZWNvbWUgYXdhcmU8YnI+DQpvZiB0aGUgZmFjdCB0aGF0IHRoZSB2YWx1ZSBpcyBh
IHN0YWxlIG9uZSw8YnI+DQpSRkM1ODYxIHN0YXRlcyB0aGF0PGJyPg0KPGJsb2NrcXVvdGU+DQo8
cHJlPk5vdGUgdGhhdCAmcXVvdDtzdGFsZSZxdW90OyBpbXBsaWVzIHRoYXQgdGhlIHJlc3BvbnNl
IHdpbGwgaGF2ZSBhIG5vbi16ZXJvIEFnZQ0KICAgaGVhZGVyIGFuZCBhIHdhcm5pbmcgaGVhZGVy
LCBhcyBwZXIgSFRUUCdzIHJlcXVpcmVtZW50cy48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxicj4N
Cjxicj4NCkNpYW88YnI+DQpTYWx2YXRvcmU8YnI+DQo8cHJlIGNsYXNzPSJtb3otc2lnbmF0dXJl
IiBjb2xzPSI3MiI+LS0gDQpTYWx2YXRvcmUgTG9yZXRvDQo8YSBjbGFzcz0ibW96LXR4dC1saW5r
LWFiYnJldmlhdGVkIiBocmVmPSJodHRwOi8vd3d3LnNsb3JldG8uY29tIiB0YXJnZXQ9Il9ibGFu
ayI+d3d3LnNsb3JldG8uY29tPC9hPjwvcHJlPg0KPGJyPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0
ZSI+DQo8cHJlPkdyw7zDn2UsIENhcnN0ZW4NCg0KPC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Js
b2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--Boundary_(ID_O5H7EbisrLuY4ICAuy2kiQ)--

From cabo@tzi.org  Thu Nov 17 09:10:42 2011
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 4E17F1F0C38 for ; Thu, 17 Nov 2011 09:10:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.583
X-Spam-Level: 
X-Spam-Status: No, score=-104.583 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, SARE_RECV_SPAM_DOMN0b=1.666, 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 3Cs9Lhq4oEVZ for ; Thu, 17 Nov 2011 09:10:41 -0800 (PST)
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 7A7371F0C4F for ; Thu, 17 Nov 2011 09:10:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id pAHHALAt004193; Thu, 17 Nov 2011 18:10:21 +0100 (CET)
Received: from [192.168.0.84] (61-217-193-77.dynamic.hinet.net [61.217.193.77]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id D44A4EA9; Thu, 17 Nov 2011 18:10:19 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann 
In-Reply-To: <4EC4ECDC.1090304@ericsson.com>
Date: Fri, 18 Nov 2011 01:10:15 +0800
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20111031113719.3103.79998.idtracker@ietfa.amsl.com> <4EB41F30.3000108@ericsson.com> <515E0BF2-4FF0-49E4-B857-842749305380@tzi.org> <4EB43CEC.3050402@ericsson.com> <4EC4ECDC.1090304@ericsson.com>
To: Salvatore Loreto 
X-Mailer: Apple Mail (2.1251.1)
Cc: core@ietf.org
Subject: Re: [core] Max-OFE issue (was Re: I-D Action: draft-ietf-core-observe-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, 17 Nov 2011 17:10:42 -0000

On Nov 17, 2011, at 19:15, Salvatore Loreto wrote:

> IMO It would safer that is the observer to do some statical =
calculation to figure it out if it was or not removed from the list
> of the observer (i.e. because it has not received an updated when it =
supposed to receive)=20

The problem is that the client has nothing to base this calculation on.
That is why it is a good idea for the server to say something, because =
it is the server that intends to act on the observation relationship.

We may have various ideas of what is the best way to group the =
information to be made available from the server, but it is pretty clear =
that a single max-age value does not cut it.  A second value is needed, =
and we need to discuss how to slice this.

Note that all this is elective, so if you want to keep things simple, =
you can always leave it off -- things will just be less efficient.  =
Constrained environments may need the efficiency of correctly working =
client/proxy caching, though.

Gr=FC=DFe, Carsten

PS.: Linyi -- yes, Accept is not needed in many cases, but again, this =
Option also is elective. The alternative (where the functionality is =
needed) is to encode the required media type in the URI, and that =
probably causes more complexity.  Should this be in the base spec?  It =
does not make a difference where it is written up.



From cabo@tzi.org  Thu Nov 17 09:15:50 2011
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 10C2511E8120 for ; Thu, 17 Nov 2011 09:15:50 -0800 (PST)
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 mELeK2FukAg7 for ; Thu, 17 Nov 2011 09:15:49 -0800 (PST)
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 5095611E8114 for ; Thu, 17 Nov 2011 09:15:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id pAHHFghT009796; Thu, 17 Nov 2011 18:15:42 +0100 (CET)
Received: from [192.168.0.84] (61-31-89-133.static.tfn.net.tw [61.31.89.133]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id A2CD3EB6; Thu, 17 Nov 2011 18:15:40 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann 
In-Reply-To: <0E08042A-74F3-452A-B255-E5B654C01283@yegin.org>
Date: Fri, 18 Nov 2011 01:15:37 +0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <17AB9640-613B-4AAD-B6F4-882DEDCF9122@tzi.org>
References: <0E08042A-74F3-452A-B255-E5B654C01283@yegin.org>
To: Alper Yegin 
X-Mailer: Apple Mail (2.1251.1)
Cc: core WG 
Subject: Re: [core] RawPublicKeys
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, 17 Nov 2011 17:15:50 -0000

On Nov 17, 2011, at 23:22, Alper Yegin wrote:

> The above text explains how the network node authenticates/authorizes =
the device.
> But, how does the device authenticate/authorize the network node? For =
that, the "identity" of the network node's public key needs to be known =
to the device. But how?

Hi Alper,

what is a "network node" in the context of CoAP?
(I read "device" to include both the client and server roles, so from =
the point of CoAP, there is nothing else.  But maybe I'm missing =
something here.)

Gr=FC=DFe, Carsten


From rene.hummen@informatik.rwth-aachen.de  Thu Nov 17 09:43:12 2011
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 D2AB511E80D2 for ; Thu, 17 Nov 2011 09:43:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.501
X-Spam-Level: 
X-Spam-Status: No, score=-4.501 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Un-UwWlr-jeO for ; Thu, 17 Nov 2011 09:43:06 -0800 (PST)
Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2F9AB21F950A for ; Thu, 17 Nov 2011 09:43:06 -0800 (PST)
MIME-version: 1.0
Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LUT00812FVSYCH0@mta-1.ms.rz.RWTH-Aachen.de> for core@ietf.org; Thu, 17 Nov 2011 18:43:04 +0100 (CET)
X-IronPort-AV: E=Sophos;i="4.69,528,1315173600"; d="p7s'?scan'208";a="149275218"
Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Thu, 17 Nov 2011 18:43:04 +0100
Received: from [192.168.16.76] ([unknown] [60.248.160.10]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0LUT00CBRFVPL820@relay-auth-2.ms.rz.rwth-aachen.de> for core@ietf.org; Thu, 17 Nov 2011 18:43:04 +0100 (CET)
Content-type: multipart/signed; boundary=Apple-Mail-53--352803298; protocol="application/pkcs7-signature"; micalg=sha1
From: =?iso-8859-1?Q?Ren=E9_Hummen?= 
In-reply-to: <7C27259C-8186-4F01-8244-043203B6C4AD@yegin.org>
Date: Thu, 17 Nov 2011 18:43:00 +0100
Message-id: <9A09FA2C-BE22-461A-B481-761BD40AF67A@cs.rwth-aachen.de>
References: <4EC3711F.6010205@nomadiclab.com> <7C27259C-8186-4F01-8244-043203B6C4AD@yegin.org>
To: draft-yegin-coap-security-options@tools.ietf.org
X-Mailer: Apple Mail (2.1084)
Cc: core 
Subject: Re: [core] draft-yegin-coap-security-options-00 review
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, 17 Nov 2011 17:43:12 -0000

--Apple-Mail-53--352803298
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Hi Alper,

On 17.11.2011, at 08:07, Alper Yegin wrote:
> On Nov 16, 2011, at 10:15 AM, Ari Keranen wrote:

>> And we do already have fairly well working end-to-end security =
mechanisms (DTLS, IPsec) and even with light-weight keying (Tero's =
example of minimalistic IKEv2, HIP DEX). Considering that security is =
really hard to get right, I'd definitely recommend using something that =
already exists and has been widely reviewed. That said, your solution =
does have a bit different approach (can encrypt only parts), but how =
much benefits does that give (you do crypto over X bytes instead of X+6 =
bytes?), I'm not that sure of.
>>=20
>=20
> DTLS and IPsec are available and solid. They provide channel security. =
But that does not boil down to never developing/using a higher-layer =
security. XML security and now JOSE WG are good counter examples of =
that.

As far as I am aware, XML security does object security whereas DTLS and =
IPsec do transport security. These are two different things and require =
the standardization of distinct security mechanisms.=20

> Even in IETF for Mobile IPv4 we used a solution similar to =
coap-security. In fact, that experience suggested me this question: How =
come we are not doing it the same on CoAP. I asked that question on the =
mailing list, no response. So, I did the exercise of developing "a" =
solution, and now collecting feedback :-)
>=20
> Then for Mobile IPv6 we did what you recommended with IPsec, and that =
created problems=85=20

In my opinion, specifying a new security protocol for smart objects =
impedes the interoperability story between smart objects and Internet =
hosts as achieved by 6LowPAN (adaptation layer) and CoAP/HTTP (proxy). =
Right now, Internet hosts implement TLS/DTLS and IPsec. Do we expect =
them to support a special CoAP security protocol as well?=20

>> Also, I'm a bit concerned about the fact that key management is out =
of scope for the document. After all, that's often the hard part in =
security protocols.
>=20
> Yes, it's a hard problem. But it's a separate problem.=20
> "Key management" and "using the generated key to secure a protocol" =
are typically separate mechanisms. One can  come up with an integrated =
solution. Integration is not ideal, but maybe useful. (Not sure if this =
is what your proposal is suggesting=85)=20

I agree with Ari on this one. Can you elaborate on what you mean by =
"integration is not ideal"?

BR
Ren=E9




--
Dipl.-Inform. Rene Hummen, Ph.D. Student
Chair of Communication and Distributed Systems
RWTH Aachen University, Germany
tel: +49 241 80 20772
web: http://www.comsys.rwth-aachen.de/team/rene-hummen/


--Apple-Mail-53--352803298
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN7zCCBCEw
ggMJoAMCAQICAgDHMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0
c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQD
ExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNjEyMTkxMDI5MDBaFw0xOTA2MzAyMzU5
MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJ
MSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKm
FNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItq
aACa7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMq
ljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZDz+HV
Ez2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjgdkwgdYwcAYD
VR0fBGkwZzBloGOgYYZfaHR0cDovL3BraS50ZWxlc2VjLmRlL2NnaS1iaW4vc2VydmljZS9hZl9E
b3dubG9hZEFSTC5jcmw/LWNybF9mb3JtYXQ9WF81MDkmLWlzc3Vlcj1EVF9ST09UX0NBXzIwHQYD
VR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHDeRu69VPXF+CJei0XbAqz
K50zMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgECMA0GCSqGSIb3DQEBBQUAA4IB
AQA74Vp3wEgX3KkY7IGvWonwvSiSpspZGBJw7Cjy565/lizn8l0ZMfYTK3S9vYCyufdnyTmieTvh
ERHua3iRM347XyYndVNljjNj7s9zw7CSI0khUHUjoR8Y4pSFPT8z6XcgjaK95qGFKUD2P3MyWA0J
a6bahWzAP7uNZmRWJE6uDT8yNQFb6YyC2XJZT7GGhfF0hVblw/hc843uR7NTBXDn5U2KaYMo4RMJ
hp5eyOpYHgwf+aTUWgRo/Sg+iwK2WLX2oSw3VwBnqyNojWOl75lrXP1LVvarQIc01BGSbOyHxQoL
BzNytG8MHVQs2FHHzL8w00Ny8TK/jM5JY6gA9/IcMIIE2jCCA8KgAwIBAgIEDuQh4zANBgkqhkiG
9w0BAQUFADBeMQswCQYDVQQGEwJERTEUMBIGA1UEChMLUldUSCBBYWNoZW4xFzAVBgNVBAMTDlJX
VEggQWFjaGVuIENBMSAwHgYJKoZIhvcNAQkBFhFjYUByd3RoLWFhY2hlbi5kZTAeFw0wOTEwMDEx
MjQ1MDdaFw0xMjA5MzAxMjQ1MDdaMDkxCzAJBgNVBAYTAkRFMRQwEgYDVQQKEwtSV1RIIEFhY2hl
bjEUMBIGA1UEAxMLUmVuZSBIdW1tZW4wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCw
KpV77WtQa3ZIx+dWRTgR8wxSUsQoSEY2Do5wNPJ/m3hO3P7e8FfVKSaTimKHvRPiRvCX+HW2ldMA
f33GWtJTrN6hbSHzQTpq84uQOp/R8ad094wdKbenITaOWISEAjymgA0gS1RpvxaOv5r9uw1Th2ci
kjWEOA3tIXCFwFwfMzA/QllikzSkbmm8a6RryOUyQCqCpt9GGS0i1KC+NIa/GP883S4W4En9PxA+
VJ4hJFwjnIt0E+wUigPBQvLHxRqBT/sXSJxsSZO/uNR99dxKeQmdd4Uob5olMA94uZX/rbeZdgDu
49qSIlx/bEFzJTQzH7yDATed6nXGDojAVHeBAgMBAAGjggHDMIIBvzAJBgNVHRMEAjAAMAsGA1Ud
DwQEAwIF4DApBgNVHSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisGAQQBgjcUAgIwHQYDVR0O
BBYEFN+tg8k5s/o7Bjed1LmJouNUa4NUMB8GA1UdIwQYMBaAFG7VPsAcL3HJPL9JTu9qVUjs0fI4
MCgGA1UdEQQhMB+BHXJlbmUuaHVtbWVuQGNzLnJ3dGgtYWFjaGVuLmRlMHkGA1UdHwRyMHAwNqA0
oDKGMGh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvcnd0aC1jYS9wdWIvY3JsL2NhY3JsLmNybDA2oDSg
MoYwaHR0cDovL2NkcDIucGNhLmRmbi5kZS9yd3RoLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGUBggr
BgEFBQcBAQSBhzCBhDBABggrBgEFBQcwAoY0aHR0cDovL2NkcDEucGNhLmRmbi5kZS9yd3RoLWNh
L3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDBABggrBgEFBQcwAoY0aHR0cDovL2NkcDIucGNhLmRmbi5k
ZS9yd3RoLWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQUFAAOCAQEAmXPLNSHW
Ze3V4Rq3P2pcaBIlY4Z/nJ1jH3u6yBD3gGZrthpu1o0g45hOWbcvkkcQwvEXKlnWeiVXJsQ2XElz
ydNFQprK9GFRZvuOJUkMdR87uupqLESpoue7kmTVCFcqg8c/Q9D5KTbTTtrGDydcqKy+MWbrbtGb
lg0R8ZJmnIlb+8RLCqa4MbYq2M2kiImYzDrczlPWvy3SHiPASNFf31XDLFP26QlO3USacm/E+CfM
sgQFudf9BqE6yW8qoqx0x1xyMdo5tWyT1MUKsDA/cGADc+r2orBNBsZ7AjdPi85fJS3NE2PGhMEZ
BCsvt/EC/yIQK7O3DwELk0VlVaE/uDCCBOgwggPQoAMCAQICBAnydOAwDQYJKoZIhvcNAQEFBQAw
WjELMAkGA1UEBhMCREUxEzARBgNVBAoTCkRGTi1WZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAi
BgNVBAMTG0RGTi1WZXJlaW4gUENBIEdsb2JhbCAtIEcwMTAeFw0wNzAyMTQxMTQ5MzhaFw0xOTAy
MTMwMDAwMDBaMF4xCzAJBgNVBAYTAkRFMRQwEgYDVQQKEwtSV1RIIEFhY2hlbjEXMBUGA1UEAxMO
UldUSCBBYWNoZW4gQ0ExIDAeBgkqhkiG9w0BCQEWEWNhQHJ3dGgtYWFjaGVuLmRlMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuDAIZOPI3HpS3zVCOZLzL/gheeMSZy+Mf3CUJzdjSHeg
id36rNLIjtnsSAAn83Y8TlKUOmRTp+aXU704u7LZ5PFgGj/3fSxXfJPRm8Y4e8Ydy/tGt2nPv7Ry
XF+euJ7VMRrVRjLkoRKFGmVE+X8Pe0y9+lCfDqly66qXQCnBSmifqYEadoEy4+DDVDD4wOBpbLaY
6C50/vqhZu7f2UvdvxNzqjSVMBx+gt+b0q6FbHJoPmu18U+lOCTvfTGMTXEyDM4T0vWLaft9NsO4
udXWgY69IRRjytJy0leoL++8wUhSewFRiScQUlMw59MZAy2L2cKmnmJI/JAwdqEnkcnxowIDAQAB
o4IBsDCCAawwDwYDVR0TAQH/BAUwAwEB/zALBgNVHQ8EBAMCAQYwHQYDVR0OBBYEFG7VPsAcL3HJ
PL9JTu9qVUjs0fI4MB8GA1UdIwQYMBaAFEm3xs/oPR9/6kR7Eyn38QpwPt5kMBwGA1UdEQQVMBOB
EWNhQHJ3dGgtYWFjaGVuLmRlMIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NkcDEucGNhLmRm
bi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2NhY3JsLmNybDA9oDugOYY3aHR0cDovL2NkcDIu
cGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2NhY3JsLmNybDCBogYIKwYBBQUHAQEE
gZUwgZIwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2Ev
cHViL2NhY2VydC9jYWNlcnQuY3J0MEcGCCsGAQUFBzAChjtodHRwOi8vY2RwMi5wY2EuZGZuLmRl
L2dsb2JhbC1yb290LWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQUFAAOCAQEA
F4d+xiwLHCB61akGKxuT/3WFC8QLHlOsblyp0qVU5zFlRX9U7Tf6dg/vF0yrZfwOFpWGvZ6fjjW5
VnEtZybLmH+zfcKzuMwhHFQTSyABwmN2VxviKDR8IF6kmKlx86wEGY5Eia9UX2xROJ41MtJzYbQu
dR19KJ4Fn6jg3Os+2hfcHttOteTIfCpPLqMeF4Iyy1f1Iz1ZcEQJ7mCHhdMMnL0Oo8/zyTLjq10o
aano6WokV6isfKD1wJQnJ6KkS5UHNS9IsEBwZ9BJurQ5jB3GoW3/UgTlomfPjtGr+JcvAkPeaJM/
YbaPVBK11CMzXmtgEFwbZSMiyyoFbmD3+ItyMjGCAt4wggLaAgEBMGYwXjELMAkGA1UEBhMCREUx
FDASBgNVBAoTC1JXVEggQWFjaGVuMRcwFQYDVQQDEw5SV1RIIEFhY2hlbiBDQTEgMB4GCSqGSIb3
DQEJARYRY2FAcnd0aC1hYWNoZW4uZGUCBA7kIeMwCQYFKw4DAhoFAKCCAU0wGAYJKoZIhvcNAQkD
MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTExMTE3MTc0MzAwWjAjBgkqhkiG9w0BCQQx
FgQU0SH3jNXjp4qCorWpKdejzZYEfRMwdQYJKwYBBAGCNxAEMWgwZjBeMQswCQYDVQQGEwJERTEU
MBIGA1UEChMLUldUSCBBYWNoZW4xFzAVBgNVBAMTDlJXVEggQWFjaGVuIENBMSAwHgYJKoZIhvcN
AQkBFhFjYUByd3RoLWFhY2hlbi5kZQIEDuQh4zB3BgsqhkiG9w0BCRACCzFooGYwXjELMAkGA1UE
BhMCREUxFDASBgNVBAoTC1JXVEggQWFjaGVuMRcwFQYDVQQDEw5SV1RIIEFhY2hlbiBDQTEgMB4G
CSqGSIb3DQEJARYRY2FAcnd0aC1hYWNoZW4uZGUCBA7kIeMwDQYJKoZIhvcNAQEBBQAEggEAfo8E
Zf3KFkyc5X8B+dxdHE7zk2ZU8lBgV0lySxqGwEvmrIvBfmSEHDA9iA533kEQmBYCH6mgwqYc3d/m
RxJmSv82Kp40eHh1zoi9u8wFPiqOGBg6p380rSqCOM3YSDXcvVfRkcqZ/my6WSdureOrKSCCxxC6
ZdW1fUZoHW4KFMbh6tocLeKJwLg+vCH831JX2Z8PLUBug2IJDrrjguVIh1oqvMRcoPvOPdRpdS53
zdG1C4X+pv+aN8YTYP6kL4xVVZvvGT1dAyqFDqqTuNfvqz29liaAr7q7KenpClTS5QjzCdVKfQwU
SFTo6Bj49r4TCmyEojaV/yhmB4reqU504AAAAAAAAA==

--Apple-Mail-53--352803298--

From tianlinyi@huawei.com  Thu Nov 17 15:40:26 2011
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 AF1261F0C7F for ; Thu, 17 Nov 2011 15:40:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.931
X-Spam-Level: 
X-Spam-Status: No, score=-4.931 tagged_above=-999 required=5 tests=[AWL=1.668,  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 CnI9b9142jwA for ; Thu, 17 Nov 2011 15:40:26 -0800 (PST)
Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id B91451F0C67 for ; Thu, 17 Nov 2011 15:40:25 -0800 (PST)
Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUT00C12WF429@szxga05-in.huawei.com> for core@ietf.org; Fri, 18 Nov 2011 07:40:16 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUT00BKEWF3W3@szxga05-in.huawei.com> for core@ietf.org; Fri, 18 Nov 2011 07:40:16 +0800 (CST)
Received: from szxeml208-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AFD55426; Fri, 18 Nov 2011 07:40:15 +0800
Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 18 Nov 2011 07:40:07 +0800
Received: from SZXEML513-MBX.china.huawei.com ([169.254.8.59]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.01.0323.003; Fri, 18 Nov 2011 07:40:08 +0800
Date: Thu, 17 Nov 2011 23:40:07 +0000
From: TianLinyi 
In-reply-to: 
X-Originating-IP: [172.24.2.40]
To: Carsten Bormann , Salvatore Loreto 
Message-id: <3615F3CCD55F054395A882F51C6E5FDA182024A3@szxeml513-mbx.china.huawei.com>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-language: zh-CN
Content-transfer-encoding: base64
Accept-Language: zh-CN, en-US
Thread-topic: [core] Max-OFE issue (was Re: I-D Action: draft-ietf-core-observe-03.txt)
Thread-index: AQHMpRpHEFuIzgypzUmj8C0R/aXQlZWwxzuAgADvtPg=
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References: <20111031113719.3103.79998.idtracker@ietfa.amsl.com> <4EB41F30.3000108@ericsson.com> <515E0BF2-4FF0-49E4-B857-842749305380@tzi.org> <4EB43CEC.3050402@ericsson.com> <4EC4ECDC.1090304@ericsson.com> 
Cc: "core@ietf.org" 
Subject: Re: [core] Max-OFE issue (was Re: I-D Action:	draft-ietf-core-observe-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, 17 Nov 2011 23:40:26 -0000

PlRoZSBwcm9ibGVtIGlzIHRoYXQgdGhlIGNsaWVudCBoYXMgbm90aGluZyB0byBiYXNlIHRoaXMg
Y2FsY3VsYXRpb24gb24uDQo+VGhhdCBpcyB3aHkgaXQgaXMgYSBnb29kIGlkZWEgZm9yIHRoZSBz
ZXJ2ZXIgdG8gc2F5IHNvbWV0aGluZywgYmVjYXVzZSBpdCBpcyB0aGUgc2VydmVyIHRoYXQgaW50
ZW5kcyB0byBhY3Qgb24gdGhlIG9ic2VydmF0aW9uIHJlbGF0aW9uc2hpcC4NCg0KVGhlIG9ic2Vy
dmVyIHdpbGwgZGVjaWRlIHdoZXRoZXIgaXQgbWF5IGJlIHJlbW92ZWQgZnJvbSB0aGUgb2JzZXJ2
YXRpb24gbGlzdCBhY2NvcmRpbmcgdG8gdGhlIGxvY2FsIHBvbGljeSAoZS5nLiB0aW1lb3V0KS4g
SXQgaXMgbm90IG9ubHkgYmVjYXVzZSBvZiBNQVgtQUdFIG5laXRoZXIgTUFYLU9GRS4gDQoNClRo
ZXJlIG1heWJlIHVzZSBjYXNlIHRoYXQgdGhlIGFwcGxpY2F0aW9uIHRyeXMgdG8gZ2V0IHRoZSBk
YXRhIGZyb20gdGhlIHNlbnNvciB3aGlsZSB0aGUgUHJveHkgZm91bmQgb3V0IHRoYXQgdGhlIHNl
bnNvciBpcyBpbiBzbGVlcGluZyBtb2RlLiBJbiB0aGlzIGNhc2UsIHRoZSBwcm94eSBtYXkgd2Fu
dCB0byBleHRlbmQgdGhlIGNhY2hlIGV4cGlyeSB0aW1lIHVzaW5nIHRoZSBjYWNoZSBjb250cm9s
IG1lY2hhbmlzbSBpbiBSRkM1ODYxLiBCdXQgaSBkb24ndCBzZWUgdGhlIG5lZWQgZm9yIHRoZSBz
ZW5zb3IgdG8gdXNlIHRoaXMgbWVjaGlzbS4gVGhlcmVmb3JlIGkgZG9uJ3Qgc2VlIHRoZSBuZWVk
IHRvIGhhdmUgaXQgaW4gb2JzZXJ2ZS4gDQoNCk1ha2luZyBpdCBlbGVjdGl2ZSB3aWxsIG5vdCBt
YWtlIHRoaXMgbW9yZSB2YWx1YWJsZS4gTGVzcyBvcHRpb25hbCB0aGluZ3MgaW1wcm92ZSBpbnRl
cm9wZXJiaWxpdHkuIFBlb3BsZSBhcmUgY29uY2VybmluZyBhYm91dCB3aGV0aGVyIGl0IGlzIHJl
YWxseSB1c2VmdWwuIEJyaW5nIGV2ZXJ5dGhpbmcgZnJvbSBIVFRQIGlzIG5vdCB0aGUgd2F5IGZv
cndhcmQuIEkgYWdyZWUgd2l0aCB5b3UgQWNjZXB0IGNvdWxkIGJlIHVzZWZ1bCBpbiBzb21lIGNh
c2VzIHRoYXQncyB3aHkgd2UgaW1wbGVtZW50ZWQgaXQuIA0KDQpOb3RlIHRoYXQgUkZDNTg2MSBp
cyBpbmZvcm1hdGlvbiBhbmQgbm90IGEgc3RhbmRhcmQgdHJhY2suIA0KDQpfX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fDQrlj5Hku7bkuro6IGNvcmUtYm91bmNlc0BpZXRm
Lm9yZyBbY29yZS1ib3VuY2VzQGlldGYub3JnXSDku6PooaggQ2Fyc3RlbiBCb3JtYW5uIFtjYWJv
QHR6aS5vcmddDQrlj5HpgIHml7bpl7Q6IDIwMTHlubQxMeaciDE45pelIDE6MTANCuWIsDogU2Fs
dmF0b3JlIExvcmV0bw0KQ2M6IGNvcmVAaWV0Zi5vcmcNCuS4u+mimDogUmU6IFtjb3JlXSBNYXgt
T0ZFIGlzc3VlICh3YXMgUmU6IEktRCBBY3Rpb246ICAgICAgIGRyYWZ0LWlldGYtY29yZS1vYnNl
cnZlLTAzLnR4dCkNCg0KT24gTm92IDE3LCAyMDExLCBhdCAxOToxNSwgU2FsdmF0b3JlIExvcmV0
byB3cm90ZToNCg0KPiBJTU8gSXQgd291bGQgc2FmZXIgdGhhdCBpcyB0aGUgb2JzZXJ2ZXIgdG8g
ZG8gc29tZSBzdGF0aWNhbCBjYWxjdWxhdGlvbiB0byBmaWd1cmUgaXQgb3V0IGlmIGl0IHdhcyBv
ciBub3QgcmVtb3ZlZCBmcm9tIHRoZSBsaXN0DQo+IG9mIHRoZSBvYnNlcnZlciAoaS5lLiBiZWNh
dXNlIGl0IGhhcyBub3QgcmVjZWl2ZWQgYW4gdXBkYXRlZCB3aGVuIGl0IHN1cHBvc2VkIHRvIHJl
Y2VpdmUpDQoNClRoZSBwcm9ibGVtIGlzIHRoYXQgdGhlIGNsaWVudCBoYXMgbm90aGluZyB0byBi
YXNlIHRoaXMgY2FsY3VsYXRpb24gb24uDQpUaGF0IGlzIHdoeSBpdCBpcyBhIGdvb2QgaWRlYSBm
b3IgdGhlIHNlcnZlciB0byBzYXkgc29tZXRoaW5nLCBiZWNhdXNlIGl0IGlzIHRoZSBzZXJ2ZXIg
dGhhdCBpbnRlbmRzIHRvIGFjdCBvbiB0aGUgb2JzZXJ2YXRpb24gcmVsYXRpb25zaGlwLg0KDQpX
ZSBtYXkgaGF2ZSB2YXJpb3VzIGlkZWFzIG9mIHdoYXQgaXMgdGhlIGJlc3Qgd2F5IHRvIGdyb3Vw
IHRoZSBpbmZvcm1hdGlvbiB0byBiZSBtYWRlIGF2YWlsYWJsZSBmcm9tIHRoZSBzZXJ2ZXIsIGJ1
dCBpdCBpcyBwcmV0dHkgY2xlYXIgdGhhdCBhIHNpbmdsZSBtYXgtYWdlIHZhbHVlIGRvZXMgbm90
IGN1dCBpdC4gIEEgc2Vjb25kIHZhbHVlIGlzIG5lZWRlZCwgYW5kIHdlIG5lZWQgdG8gZGlzY3Vz
cyBob3cgdG8gc2xpY2UgdGhpcy4NCg0KTm90ZSB0aGF0IGFsbCB0aGlzIGlzIGVsZWN0aXZlLCBz
byBpZiB5b3Ugd2FudCB0byBrZWVwIHRoaW5ncyBzaW1wbGUsIHlvdSBjYW4gYWx3YXlzIGxlYXZl
IGl0IG9mZiAtLSB0aGluZ3Mgd2lsbCBqdXN0IGJlIGxlc3MgZWZmaWNpZW50LiAgQ29uc3RyYWlu
ZWQgZW52aXJvbm1lbnRzIG1heSBuZWVkIHRoZSBlZmZpY2llbmN5IG9mIGNvcnJlY3RseSB3b3Jr
aW5nIGNsaWVudC9wcm94eSBjYWNoaW5nLCB0aG91Z2guDQoNCkdyw7zDn2UsIENhcnN0ZW4NCg0K
UFMuOiBMaW55aSAtLSB5ZXMsIEFjY2VwdCBpcyBub3QgbmVlZGVkIGluIG1hbnkgY2FzZXMsIGJ1
dCBhZ2FpbiwgdGhpcyBPcHRpb24gYWxzbyBpcyBlbGVjdGl2ZS4gVGhlIGFsdGVybmF0aXZlICh3
aGVyZSB0aGUgZnVuY3Rpb25hbGl0eSBpcyBuZWVkZWQpIGlzIHRvIGVuY29kZSB0aGUgcmVxdWly
ZWQgbWVkaWEgdHlwZSBpbiB0aGUgVVJJLCBhbmQgdGhhdCBwcm9iYWJseSBjYXVzZXMgbW9yZSBj
b21wbGV4aXR5LiAgU2hvdWxkIHRoaXMgYmUgaW4gdGhlIGJhc2Ugc3BlYz8gIEl0IGRvZXMgbm90
IG1ha2UgYSBkaWZmZXJlbmNlIHdoZXJlIGl0IGlzIHdyaXR0ZW4gdXAuDQoNCg0KX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmNvcmUgbWFpbGluZyBsaXN0
DQpjb3JlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nv
cmU=

From Akbar.Rahman@InterDigital.com  Thu Nov 17 16:30:44 2011
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 943D011E80D2 for ; Thu, 17 Nov 2011 16:30:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.588
X-Spam-Level: 
X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011,  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 Z7yRiKvowEV5 for ; Thu, 17 Nov 2011 16:30:44 -0800 (PST)
Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by ietfa.amsl.com (Postfix) with ESMTP id ED16011E80D0 for ; Thu, 17 Nov 2011 16:30:43 -0800 (PST)
Received: from SAM.InterDigital.com ([10.30.2.12]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 17 Nov 2011 19:30:42 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
x-cr-hashedpuzzle: fvU= BVMX DE2+ DL6F DMP3 FmP/ GJZN GQBr HhxE H4qs KZyH MITR Nws6 OWe3 QwYl Vc/F; 2; YwBhAGIAbwBAAHQAegBpAC4AbwByAGcAOwBjAG8AcgBlAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {9450DF4D-56FE-454E-AE4B-34C639BC0B25}; YQBrAGIAYQByAC4AcgBhAGgAbQBhAG4AQABpAG4AdABlAHIAZABpAGcAaQB0AGEAbAAuAGMAbwBtAA==; Fri, 18 Nov 2011 00:30:37 GMT; TQB1AGwAdABpAGMAYQBzAHQAIABzAHUAcABwAG8AcgB0ACAAaQBuACAAQwBvAEEAUAA=
x-cr-puzzleid: {9450DF4D-56FE-454E-AE4B-34C639BC0B25}
Content-class: urn:content-classes:message
Date: Thu, 17 Nov 2011 19:30:37 -0500
Message-ID: 
In-Reply-To: <3615F3CCD55F054395A882F51C6E5FDA182024A3@szxeml513-mbx.china.huawei.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-topic: Multicast support in CoAP
Thread-index: AQHMpRpHEFuIzgypzUmj8C0R/aXQlZWwxzuAgADvtPiAAA9AMA==
References: <20111031113719.3103.79998.idtracker@ietfa.amsl.com><4EB41F30.3000108@ericsson.com><515E0BF2-4FF0-49E4-B857-842749305380@tzi.org><4EB43CEC.3050402@ericsson.com> <4EC4ECDC.1090304@ericsson.com> <3615F3CCD55F054395A882F51C6E5FDA182024A3@szxeml513-mbx.china.huawei.com>
From: "Rahman, Akbar" 
To: "Carsten Bormann" 
X-OriginalArrivalTime: 18 Nov 2011 00:30:42.0608 (UTC) FILETIME=[4E162B00:01CCA589]
Cc: core@ietf.org
Subject: [core] Multicast support in CoAP
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, 18 Nov 2011 00:30:44 -0000

SGkgQ2Fyc3RlbiwNCg0KDQpJbiBwcmVwYXJhdGlvbiBmb3IgY29udGludWluZyBvdXIgbXVsdGlj
YXN0IGRpc2N1c3Npb24gdG9kYXkgaW4gQ09SRSwgSSB3b3VsZCBsaWtlIHRvIGFkZCB0aHJlZSBw
b2ludHMgZm9yIGRpc2N1c3Npb246DQoNCg0KLSBJIGRpZCBhIHF1aWNrIHdvcmQgY291bnQsIGFu
ZCB0aGVyZSBhcmUgMjkgcmVmZXJlbmNlcyB0byBob3cgIm11bHRpY2FzdCIgaXMgc3VwcG9ydGVk
L3VzZWQgaW4gdGhlIGJhc2UgQ29BUCBzcGVjIChodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k
cmFmdC1pZXRmLWNvcmUtY29hcC0wOCkNCg0KDQotIFRoZSBiYXNlIFJQTCBzcGVjIGNsZWFybHkg
aGFzIGEgbXVsdGljYXN0IG1vZGUgb2Ygb3BlcmF0aW9uIChodHRwOi8vdG9vbHMuaWV0Zi5vcmcv
aHRtbC9kcmFmdC1pZXRmLXJvbGwtcnBsLTE5I3BhZ2UtMTA2KQ0KDQoNCi0gQ29BUCBpcyBzdXBw
b3NlZCB0byBydW4gb24gbm9uIExvd1BBTiBuZXR3b3JrcyB3aGVyZSBtdWx0aWNhc3QgaXMgb2J2
aW91c2x5IHN1cHBvcnRlZA0KDQoNCg0KU28sIEkgdW5kZXJzdGFuZCB0aGUgY29uY2VybiBhYm91
dCBhY3R1YWwgZGVwbG95bWVudHMgb2YgbXVsdGljYXN0LCBidXQgSSBkbyBub3QgbG9naWNhbGx5
IHNlZSBob3cgd2UgY2FuIHNob290IGRvd24gdGhlIEdyb3VwIENvbW11bmljYXRpb25zIGRyYWZ0
IG9uIHRoZSBiYXNpcyBvZiBhIHByZW1pc2UgdGhhdCBtdWx0aWNhc3QgaXMgTk9UIHN1cHBvcnRl
ZCBpbiB0aGUgdmFyaW91cyBwcm90b2NvbHMuDQoNCg0KTG9va2luZyBmb3J3YXJkIHRvIHlvdXIg
ZmVlZGJhY2shDQoNCg0KQWtiYXINCg0K

From alper.yegin@yegin.org  Thu Nov 17 17:21:44 2011
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 25D5911E8097 for ; Thu, 17 Nov 2011 17:21:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o5hnhUK4Kn2N for ; Thu, 17 Nov 2011 17:21:43 -0800 (PST)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 834AB11E808C for ; Thu, 17 Nov 2011 17:21:43 -0800 (PST)
Received: from [10.1.1.2] (odakk1.odakk.com [78.111.98.194]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0MH0Be-1ReuG00TmU-00EDl4; Thu, 17 Nov 2011 20:21:42 -0500
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: text/plain; charset=iso-8859-1
From: Alper Yegin 
In-Reply-To: <17AB9640-613B-4AAD-B6F4-882DEDCF9122@tzi.org>
Date: Fri, 18 Nov 2011 03:21:34 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <0E08042A-74F3-452A-B255-E5B654C01283@yegin.org> <17AB9640-613B-4AAD-B6F4-882DEDCF9122@tzi.org>
To: Carsten Bormann 
X-Mailer: Apple Mail (2.1244.3)
X-Provags-ID: V02:K0:JDL+6z7BGO4SsHMRuHYFiF1vOgqhWThNSq0FHYr54U1 HRxOl1vgHxWSmeR8NfHfB3mOp5pXR1jHorkySsJs3qpzkuT8Ao 2e6CazuwYChG+fygShCL8e4D+jOG5d6lm6hTxLWdkssqE6BDZD Z/XfH8qimugHo0kNg9J3zNm7PyB+XNiRjs9KHdRGRx8tkcmKYX BXX0obfjS+g3x86LoiPOLSbR2ZE75sypOgvfGSN2Yp3A9E6ufY 0VJ0/NCu2PB9HOiuorhh6uJN2oOSfA3NiEIaVLfgx96ny/EzMo L2rek2p7xX4aByJKoxWERCZquL8mQdZ/eJujiZ4RU4LPHNd0pf f7qhQuajHNqeJMRHfFSnOH5BQKI297Nf+S/gHd3cZ
Cc: core WG 
Subject: Re: [core] RawPublicKeys
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, 18 Nov 2011 01:21:44 -0000

Hi Carsten,

On Nov 17, 2011, at 7:15 PM, Carsten Bormann wrote:

> On Nov 17, 2011, at 23:22, Alper Yegin wrote:
>=20
>> The above text explains how the network node authenticates/authorizes =
the device.
>> But, how does the device authenticate/authorize the network node? For =
that, the "identity" of the network node's public key needs to be known =
to the device. But how?
>=20
> Hi Alper,
>=20
> what is a "network node" in the context of CoAP?
> (I read "device" to include both the client and server roles, so from =
the point of CoAP, there is nothing else.  But maybe I'm missing =
something here.)
>=20


In the context of a "home deployment" for example, the network node is =
the home gateway that one needs to configure when bringing in a new =
device to home. ACL on the home gateway needs to be updated with the =
device ID for access control. But this is just one side of the story. =
The other side is, how does the new device identify the network (the =
home gateway)?



> Gr=FC=DFe, Carsten
>=20


From alper.yegin@yegin.org  Thu Nov 17 17:29:27 2011
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 823DA11E80A4 for ; Thu, 17 Nov 2011 17:29:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.449
X-Spam-Level: 
X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 SIrKKq0erfKO for ; Thu, 17 Nov 2011 17:29:26 -0800 (PST)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id A3DC711E8094 for ; Thu, 17 Nov 2011 17:29:26 -0800 (PST)
Received: from [10.1.1.2] (odakk1.odakk.com [78.111.98.194]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0LvE78-1QjfDb0i94-010Wxl; Thu, 17 Nov 2011 20:29:15 -0500
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: text/plain; charset=windows-1252
From: Alper Yegin 
In-Reply-To: <9A09FA2C-BE22-461A-B481-761BD40AF67A@cs.rwth-aachen.de>
Date: Fri, 18 Nov 2011 03:29:04 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <1D9B4526-D130-4470-B9C1-8B538B6BCF7D@yegin.org>
References: <4EC3711F.6010205@nomadiclab.com> <7C27259C-8186-4F01-8244-043203B6C4AD@yegin.org> <9A09FA2C-BE22-461A-B481-761BD40AF67A@cs.rwth-aachen.de>
To: =?iso-8859-1?Q?Ren=E9_Hummen?= 
X-Mailer: Apple Mail (2.1244.3)
X-Provags-ID: V02:K0:dQ/JSZziJWHZoIp4sakSwUxs/YBIripTlNcs5l/5teK 3gbTEB4pcgnS5WSdUS14QpJH3QxUbYPh321/Zub5FyvJPVSTVr x04mC4kIfYlyXe+hwmOxYcvcB/hFVI4PVO9QuG2Q7DDPVmnuUm 1HDYugPdfMsHZdWM7kIhsopdtfXVx6rtj1KHQwU3aFUsXccBBO I5/VpwRuXNhohlR7/DIZM9qUKTXChU1t48GW0ci4XE9NImKE/2 WksVenUes2L9sA56FkgTvrM1haasV1svJsJOJgZYVUhmmf9QKS zZHMSZ/zQgJ3NhPRdarHikbteQ8DGF1jd3FrsEftHgabS9aseS ij/NfAMjCKTFXbT83nm4IRVI/aBPy6pYaIa7NoKSG
Cc: draft-yegin-coap-security-options@tools.ietf.org, core 
Subject: Re: [core] draft-yegin-coap-security-options-00 review
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, 18 Nov 2011 01:29:27 -0000

Hi Rene,

On Nov 17, 2011, at 7:43 PM, Ren=E9 Hummen wrote:

> Hi Alper,
>=20
> On 17.11.2011, at 08:07, Alper Yegin wrote:
>> On Nov 16, 2011, at 10:15 AM, Ari Keranen wrote:
>=20
>>> And we do already have fairly well working end-to-end security =
mechanisms (DTLS, IPsec) and even with light-weight keying (Tero's =
example of minimalistic IKEv2, HIP DEX). Considering that security is =
really hard to get right, I'd definitely recommend using something that =
already exists and has been widely reviewed. That said, your solution =
does have a bit different approach (can encrypt only parts), but how =
much benefits does that give (you do crypto over X bytes instead of X+6 =
bytes?), I'm not that sure of.
>>>=20
>>=20
>> DTLS and IPsec are available and solid. They provide channel =
security. But that does not boil down to never developing/using a =
higher-layer security. XML security and now JOSE WG are good counter =
examples of that.
>=20
> As far as I am aware, XML security does object security whereas DTLS =
and IPsec do transport security. These are two different things and =
require the standardization of distinct security mechanisms.=20
>=20

Right. the point is, if TLS/IPsec were enough, then we'd not be talking =
about those others at all, like Ari was suggesting.


>> Even in IETF for Mobile IPv4 we used a solution similar to =
coap-security. In fact, that experience suggested me this question: How =
come we are not doing it the same on CoAP. I asked that question on the =
mailing list, no response. So, I did the exercise of developing "a" =
solution, and now collecting feedback :-)
>>=20
>> Then for Mobile IPv6 we did what you recommended with IPsec, and that =
created problems=85=20
>=20
> In my opinion, specifying a new security protocol for smart objects =
impedes the interoperability story between smart objects and Internet =
hosts as achieved by 6LowPAN (adaptation layer) and CoAP/HTTP (proxy). =
Right now, Internet hosts implement TLS/DTLS and IPsec. Do we expect =
them to support a special CoAP security protocol as well?=20
>=20

Most of the time the devices won't be supporting all of them. And indeed =
adding one more to the toolbox works against the interop, and shall only =
be done if it is beneficial.=20


>>> Also, I'm a bit concerned about the fact that key management is out =
of scope for the document. After all, that's often the hard part in =
security protocols.
>>=20
>> Yes, it's a hard problem. But it's a separate problem.=20
>> "Key management" and "using the generated key to secure a protocol" =
are typically separate mechanisms. One can  come up with an integrated =
solution. Integration is not ideal, but maybe useful. (Not sure if this =
is what your proposal is suggesting=85)=20
>=20
> I agree with Ari on this one. Can you elaborate on what you mean by =
"integration is not ideal"?
>=20

Integrated means developing one solution (or a tightly-bound =
double-sided solution) that handles both key management and key use. I =
was responding to Ari about why we are solving one of the problems and =
not the other. Ours is equivalent to providing a DTLS-PSK solution but =
not describing how the PSK got there.

Alper




> BR
> Ren=E9
>=20
>=20
>=20
>=20
> --
> Dipl.-Inform. Rene Hummen, Ph.D. Student
> Chair of Communication and Distributed Systems
> RWTH Aachen University, Germany
> tel: +49 241 80 20772
> web: http://www.comsys.rwth-aachen.de/team/rene-hummen/
>=20
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core


From ekr@rtfm.com  Thu Nov 17 18:10:35 2011
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 2158321F93B2 for ; Thu, 17 Nov 2011 18:10:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.944
X-Spam-Level: 
X-Spam-Status: No, score=-102.944 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKU3UT-DuHvJ for ; Thu, 17 Nov 2011 18:10:34 -0800 (PST)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id DCF2121F931B for ; Thu, 17 Nov 2011 18:10:33 -0800 (PST)
Received: by vcbfl15 with SMTP id fl15so3139885vcb.31 for ; Thu, 17 Nov 2011 18:10:33 -0800 (PST)
Received: by 10.220.2.19 with SMTP id 19mr84611vch.161.1321582233158; Thu, 17 Nov 2011 18:10:33 -0800 (PST)
MIME-Version: 1.0
Received: by 10.220.118.132 with HTTP; Thu, 17 Nov 2011 18:09:52 -0800 (PST)
X-Originating-IP: [74.95.2.173]
From: Eric Rescorla 
Date: Thu, 17 Nov 2011 18:09:52 -0800
Message-ID: 
To: "CORE (Constrained RESTful Environments) WG" 
Content-Type: text/plain; charset=ISO-8859-1
Subject: [core] Review of draft-yegin-coap-security-options-00
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Nov 2011 02:10:35 -0000

I just read this document.

Overall, I don't understand the motivation for this document. The
Introduction implies that it's more efficient than DTLS with shared
keys, but I don't see any reason to expect that that is in fact the
case. Moreover, given the difficulty of designing correct
cryptographic protocols, you would need a very large efficiency gain
to justify this.

If I'm understanding this document correctly, the described
protocol is also subject to attacks which should be
prevented by a properly designed cryptographic protocol:

* I don't understand how this document prevents complete replay
  attacks. Given the short Context-ID, repeated contexts
  are inevitable, with the result that from the server's
  perspective it is not possible to distinguish complete
  replays of old connections and new connections, as long
  as the server has forgotten or timed out the Context-ID
  being replayed. Moreover, if the client times out and replays
  a Contex-ID, he too is subject to replay attacks.
  The conventional defense against this attack is for both sides
  to supply a longish nonce which is mixed into the long-term
  key to produce a traffic key.

* The handshake does not appear to be secure against downgrade
  attacks in which the attacker removes weak cipher suites
  from the client's CryptoInitiate in order to force the
  client and server to choose the weakest common cipher.
  The standard defense here is to have a strong MAC over the
  entire handshake based on the shared key. (D/TLS calls
  this the Finished).

Additionally, the anti-replay mechanism described in S 2.3
is very inconvenient, because it requires each side to memorize
every nonce in every valid context. The standard mechanism
here is to use sequence numbers and an anti-replay window.
Also, I wonder if there is a reflection attack here.

Given these issues, it's not clear to me why one would wish
to take on this document rather than use a well understood
protocol.

-Ekr

From alper.yegin@yegin.org  Thu Nov 17 18:27:36 2011
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 1638411E80D1 for ; Thu, 17 Nov 2011 18:27:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.577
X-Spam-Level: 
X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 FNCmVOTAI+dc for ; Thu, 17 Nov 2011 18:27:35 -0800 (PST)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 254B311E80D0 for ; Thu, 17 Nov 2011 18:27:35 -0800 (PST)
Received: from [10.1.1.2] (odakk1.odakk.com [78.111.98.194]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0MCtWV-1RaKrT0blj-009lHr; Thu, 17 Nov 2011 21:27:33 -0500
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: text/plain; charset=windows-1252
From: Alper Yegin 
In-Reply-To: 
Date: Fri, 18 Nov 2011 04:27:24 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
To: Eric Rescorla 
X-Mailer: Apple Mail (2.1244.3)
X-Provags-ID: V02:K0:5pAyNogxWK8sfeXVg2I81FOk6L7w4AMrSpeiAFCojsA vVYOpkaghazaQye7AngnM3qnlCpDgt9MvHocGLvt9aivET1uAL bAV1qlmsXwKx2qma7jNuyLmJnSTHZFLLxc1z7EAMIL4gucPE6F YvR75n6fAdLlFehyb+csv3YrhL9/IlUT7Ml5IArNnlNLBSOXej 7nLg6Kfg2blL47KtW+fGei8LGAmlDyb+SZAu0RDWQ8SPy+q0lj UHnm75E7/LJUltaKATaykSoCECnIlHGfTd52Ki7B8zdVBp7Nn2 CmhFoSkFd5vKocQpSBCeGKyk9nlqZ50xTNzjpOBVvGbFbGnH8z 4EoNzgCdVBCjtPypTG5Ubo+XBJ/q5IVP8k2PdnC83
Cc: "CORE \(Constrained RESTful Environments\) WG" 
Subject: Re: [core] Review of draft-yegin-coap-security-options-00
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Nov 2011 02:27:36 -0000

> I just read this document.
>=20

Thank you.

> Overall, I don't understand the motivation for this document. The
> Introduction implies that it's more efficient than DTLS with shared
> keys, but I don't see any reason to expect that that is in fact the
> case. Moreover, given the difficulty of designing correct
> cryptographic protocols, you would need a very large efficiency gain
> to justify this.
>=20
> If I'm understanding this document correctly, the described
> protocol is also subject to attacks which should be
> prevented by a properly designed cryptographic protocol:
>=20
> * I don't understand how this document prevents complete replay
>  attacks. Given the short Context-ID, repeated contexts
>  are inevitable, with the result that from the server's
>  perspective it is not possible to distinguish complete
>  replays of old connections and new connections, as long
>  as the server has forgotten or timed out the Context-ID
>  being replayed. Moreover, if the client times out and replays
>  a Contex-ID, he too is subject to replay attacks.
>  The conventional defense against this attack is for both sides
>  to supply a longish nonce which is mixed into the long-term
>  key to produce a traffic key.
>=20

We do have a nonce in the I-D. Please see Section 2.3.1.=20


> * The handshake does not appear to be secure against downgrade
>  attacks in which the attacker removes weak cipher suites
>  from the client's CryptoInitiate in order to force the
>  client and server to choose the weakest common cipher.
>  The standard defense here is to have a strong MAC over the
>  entire handshake based on the shared key. (D/TLS calls
>  this the Finished).
>=20

You are right. Will do in rev.


> Additionally, the anti-replay mechanism described in S 2.3
> is very inconvenient, because it requires each side to memorize
> every nonce in every valid context. The standard mechanism
> here is to use sequence numbers and an anti-replay window.

Right. Will do.

> Also, I wonder if there is a reflection attack here.
>=20

Let me think...


> Given these issues, it's not clear to me why one would wish
> to take on this document rather than use a well understood
> protocol.
>=20

I'm hoping our presentation today will shed light to that. We can take =
it from there=85

Thanks.

Alper





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


From ekr@rtfm.com  Thu Nov 17 18:32:24 2011
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 9154521F947A for ; Thu, 17 Nov 2011 18:32:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.945
X-Spam-Level: 
X-Spam-Status: No, score=-102.945 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8nxwscmfzyIE for ; Thu, 17 Nov 2011 18:32:24 -0800 (PST)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id D103421F9475 for ; Thu, 17 Nov 2011 18:32:23 -0800 (PST)
Received: by vcbfl15 with SMTP id fl15so3158102vcb.31 for ; Thu, 17 Nov 2011 18:32:23 -0800 (PST)
Received: by 10.52.65.14 with SMTP id t14mr1390261vds.47.1321583543306; Thu, 17 Nov 2011 18:32:23 -0800 (PST)
MIME-Version: 1.0
Received: by 10.220.118.132 with HTTP; Thu, 17 Nov 2011 18:31:42 -0800 (PST)
X-Originating-IP: [74.95.2.173]
In-Reply-To: 
References:  
From: Eric Rescorla 
Date: Thu, 17 Nov 2011 18:31:42 -0800
Message-ID: 
To: Alper Yegin 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "CORE \(Constrained RESTful Environments\) WG" 
Subject: Re: [core] Review of draft-yegin-coap-security-options-00
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Nov 2011 02:32:24 -0000

On Thu, Nov 17, 2011 at 6:27 PM, Alper Yegin  wrote:
>
>> I just read this document.
>>
>
> Thank you.
>
>> Overall, I don't understand the motivation for this document. The
>> Introduction implies that it's more efficient than DTLS with shared
>> keys, but I don't see any reason to expect that that is in fact the
>> case. Moreover, given the difficulty of designing correct
>> cryptographic protocols, you would need a very large efficiency gain
>> to justify this.
>>
>> If I'm understanding this document correctly, the described
>> protocol is also subject to attacks which should be
>> prevented by a properly designed cryptographic protocol:
>>
>> * I don't understand how this document prevents complete replay
>> =A0attacks. Given the short Context-ID, repeated contexts
>> =A0are inevitable, with the result that from the server's
>> =A0perspective it is not possible to distinguish complete
>> =A0replays of old connections and new connections, as long
>> =A0as the server has forgotten or timed out the Context-ID
>> =A0being replayed. Moreover, if the client times out and replays
>> =A0a Contex-ID, he too is subject to replay attacks.
>> =A0The conventional defense against this attack is for both sides
>> =A0to supply a longish nonce which is mixed into the long-term
>> =A0key to produce a traffic key.
>>
>
> We do have a nonce in the I-D. Please see Section 2.3.1.

That nonce is a per-message nonce, not a per-association nonce.
Unless you store that nonce forever, I believe you have a
whole-association replay problem.

>
>> * The handshake does not appear to be secure against downgrade
>> =A0attacks in which the attacker removes weak cipher suites
>> =A0from the client's CryptoInitiate in order to force the
>> =A0client and server to choose the weakest common cipher.
>> =A0The standard defense here is to have a strong MAC over the
>> =A0entire handshake based on the shared key. (D/TLS calls
>> =A0this the Finished).
>>
>
> You are right. Will do in rev.
>
>
>> Additionally, the anti-replay mechanism described in S 2.3
>> is very inconvenient, because it requires each side to memorize
>> every nonce in every valid context. The standard mechanism
>> here is to use sequence numbers and an anti-replay window.
>
> Right. Will do.
>
>> Also, I wonder if there is a reflection attack here.
>>
>
> Let me think...

At this point aren't we just redesigning DTLS shared key mode?

-Ekr

From alper.yegin@yegin.org  Thu Nov 17 19:08:54 2011
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 AB8B11F0C80 for ; Thu, 17 Nov 2011 19:08:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.58
X-Spam-Level: 
X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 XOsIazPxPQ3u for ; Thu, 17 Nov 2011 19:08:48 -0800 (PST)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id B8B511F0C34 for ; Thu, 17 Nov 2011 19:08:48 -0800 (PST)
Received: from [10.1.1.2] (odakk1.odakk.com [78.111.98.194]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0MKYUJ-1RQPbY1TVP-0026Sk; Thu, 17 Nov 2011 22:08:47 -0500
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: text/plain; charset=iso-8859-1
From: Alper Yegin 
In-Reply-To: 
Date: Fri, 18 Nov 2011 05:08:39 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <1758DEE6-C7E7-43DD-953A-8850EABA1869@yegin.org>
References:   
To: Eric Rescorla 
X-Mailer: Apple Mail (2.1244.3)
X-Provags-ID: V02:K0:NzH87ch1mhwsIVaRNn+2uzwMUIYs46P3p5MD8Bz5mjU q2U9oqsUWaqaEOP3ndGjcd90lzkWTNkr2YJqQXxTSfkRiEyFso VHhhGsTnyfM2U64AtgJ7kfLA8QeVxm7uZiM9m4tyt5c1gbUZ82 /P+vq3Kr3ddPO+CXXJzTXwgGVXEzHtyFl3UG+JcqXp6I5fR62P P3Avkr9IfmO+qJyKo7RrICVNcjpGSyQq4MPEXIX6duMB34by8/ tPHq8UUrpALY71QpmFa2s+DsJRYmTcuWxelVvStGOoMstDl30D GFoYr2sW3EF/RNBYI7Iw7XncdrO9Ob48y6bPezVWtNWXZnYhtv 99T9yNrsxWw3J81iy6aEegwvKePdMsbsPkJhE9S5E
Cc: "CORE \(Constrained RESTful Environments\) WG" 
Subject: Re: [core] Review of draft-yegin-coap-security-options-00
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Nov 2011 03:08:54 -0000

>>> * I don't understand how this document prevents complete replay
>>>  attacks. Given the short Context-ID, repeated contexts
>>>  are inevitable, with the result that from the server's
>>>  perspective it is not possible to distinguish complete
>>>  replays of old connections and new connections, as long
>>>  as the server has forgotten or timed out the Context-ID
>>>  being replayed. Moreover, if the client times out and replays
>>>  a Contex-ID, he too is subject to replay attacks.
>>>  The conventional defense against this attack is for both sides
>>>  to supply a longish nonce which is mixed into the long-term
>>>  key to produce a traffic key.
>>>=20
>>=20
>> We do have a nonce in the I-D. Please see Section 2.3.1.
>=20
> That nonce is a per-message nonce, not a per-association nonce.
> Unless you store that nonce forever, I believe you have a
> whole-association replay problem.


Got it. When we add integrity protection to the CryptoInitiate, we'll =
handle that as you suggested.

>=20
>>=20
>>> * The handshake does not appear to be secure against downgrade
>>>  attacks in which the attacker removes weak cipher suites
>>>  from the client's CryptoInitiate in order to force the
>>>  client and server to choose the weakest common cipher.
>>>  The standard defense here is to have a strong MAC over the
>>>  entire handshake based on the shared key. (D/TLS calls
>>>  this the Finished).
>>>=20
>>=20
>> You are right. Will do in rev.
>>=20
>>=20
>>> Additionally, the anti-replay mechanism described in S 2.3
>>> is very inconvenient, because it requires each side to memorize
>>> every nonce in every valid context. The standard mechanism
>>> here is to use sequence numbers and an anti-replay window.
>>=20
>> Right. Will do.
>>=20
>>> Also, I wonder if there is a reflection attack here.
>>>=20
>>=20
>> Let me think...
>=20
> At this point aren't we just redesigning DTLS shared key mode?
>=20

Obviously PSK mode in DTLS, IPsec, XML-ENC/DSIG, JOSE, Mobile IP, L2 =
ciphering, and anything of that sort have these common. And the same =
applies to this method. These should be common unless we are inventing =
some new crypto, or not using the crypto the right way. Neither is meant =
to be the case. We are fixing up the issues you are identifying.=20

The essential difference among those protocols is the "layer" they =
operate on.=20






> -Ekr


From ekr@rtfm.com  Thu Nov 17 19:31:12 2011
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 B956711E80E1 for ; Thu, 17 Nov 2011 19:31:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.946
X-Spam-Level: 
X-Spam-Status: No, score=-102.946 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WdSCTxPN2m-O for ; Thu, 17 Nov 2011 19:31:06 -0800 (PST)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id C792611E80E0 for ; Thu, 17 Nov 2011 19:31:06 -0800 (PST)
Received: by vcbfl15 with SMTP id fl15so3209124vcb.31 for ; Thu, 17 Nov 2011 19:31:06 -0800 (PST)
Received: by 10.52.174.65 with SMTP id bq1mr1589133vdc.30.1321587066159; Thu, 17 Nov 2011 19:31:06 -0800 (PST)
MIME-Version: 1.0
Received: by 10.220.118.132 with HTTP; Thu, 17 Nov 2011 19:30:25 -0800 (PST)
X-Originating-IP: [74.95.2.173]
In-Reply-To: <1758DEE6-C7E7-43DD-953A-8850EABA1869@yegin.org>
References:    <1758DEE6-C7E7-43DD-953A-8850EABA1869@yegin.org>
From: Eric Rescorla 
Date: Thu, 17 Nov 2011 19:30:25 -0800
Message-ID: 
To: Alper Yegin 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "CORE \(Constrained RESTful Environments\) WG" 
Subject: Re: [core] Review of draft-yegin-coap-security-options-00
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Nov 2011 03:31:12 -0000

On Thu, Nov 17, 2011 at 7:08 PM, Alper Yegin  wrote:

> Obviously PSK mode in DTLS, IPsec, XML-ENC/DSIG, JOSE, Mobile IP, L2 ciph=
ering, and anything of that sort have these common. And the same applies to=
 this method. These should be common unless we are inventing some new crypt=
o, or not using the crypto the right way. Neither is meant to be the case. =
We are fixing up the issues you are identifying.

Yes, but the point is that it's *hard* to design a new protocol of
this kind that
doesn't have a bunch of security issues, as evidenced by the number of
things i found in a cursory inspection. Thus, the barrier to arguing that
you need a new protocol is fairly high.


> The essential difference among those protocols is the "layer" they operat=
e on.

Yes but I have yet to hear a convincing argument for why that is a signific=
ant
improvement in this case.

-Ekr

>
>
>
>
>
>> -Ekr
>
>

From alper.yegin@yegin.org  Thu Nov 17 19:46:49 2011
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 F3A371F0C81 for ; Thu, 17 Nov 2011 19:46:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.582
X-Spam-Level: 
X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 uVdyPUMQBjLT for ; Thu, 17 Nov 2011 19:46:48 -0800 (PST)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 5F56B1F0C94 for ; Thu, 17 Nov 2011 19:46:48 -0800 (PST)
Received: from [10.1.1.2] (odakk1.odakk.com [78.111.98.194]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0M6BOM-1QhOA72Rpa-00yJwP; Thu, 17 Nov 2011 22:46:46 -0500
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: text/plain; charset=iso-8859-1
From: Alper Yegin 
In-Reply-To: 
Date: Fri, 18 Nov 2011 05:46:36 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <2AADF161-AA69-433A-99E7-08F37968B5B3@yegin.org>
References:    <1758DEE6-C7E7-43DD-953A-8850EABA1869@yegin.org> 
To: Eric Rescorla 
X-Mailer: Apple Mail (2.1244.3)
X-Provags-ID: V02:K0:9knyM5vTVzuBs5EhtZsGt8K3B5Z7iHWcbgGkYzsFZbD mNoKHknR7dTUMeJFuwnsgcmdmdIuNydzIwQSyXc1nBiPDxRgVe IOGHlPOJzK1zTVu6RQv4F8TaWgYxUC4sbq+juGGgQTjFuQjLLx MQkIifirkv8eUhj+UeUhbHGtHpw8pGYyPS6KD329emQCKxiR3I kaQzVHm9agmuBpOIXEdDhx3oNF7lf7QHVO0ovNLLbYbAE6ifC8 Kkhsxm827FwBQr7tcj0RenZ0X8BdHZvM2uUmkhexs7TJF8wf+/ 6/EDK2CqU/qSoVIiK4CMB28cWg+dmZj38bxeELfDOfRszdnTOl rSemVWIaXC+lGn2OQgQogsLoX7BhUja0qWLP1qesD
Cc: "CORE \(Constrained RESTful Environments\) WG" 
Subject: Re: [core] Review of draft-yegin-coap-security-options-00
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Nov 2011 03:46:49 -0000

Obviously we must get the crypto right (I'd have been surprised if we =
got it 100% right in version-00).

But I think the primary question on the table is this:=20

	What is(are) the right layer(s) we shall define or rely on a =
security solution for CoAP.

One can rely on security at one or more of the following layers:

Physical
Link-layer=20
Network (e.g., IPsec)
Transport (e.g., DTLS)
CoAP-layer (this proposal)
CoAP-payload media-layer (XML, JSON, etc.)
Application layer


Solutions at each layer above have its pros and cons.=20
We talk about such things all the time in IETF. We end up following =
different approaches most of the time. I was in PCP earlier, and now I =
see they are relying on Phy and Link-layer security.=20

I'm not saying we shall always have solutions at every layer for any =
protocol. It goes case-by-case, and we have a case at hand.


> Yes but I have yet to hear a convincing argument for why that is a =
significant
> improvement in this case.

Can we dive into that during/after my presentation? My detailed answer =
is there.

Alper
=20

On Nov 18, 2011, at 5:30 AM, Eric Rescorla wrote:

> On Thu, Nov 17, 2011 at 7:08 PM, Alper Yegin  =
wrote:
>=20
>> Obviously PSK mode in DTLS, IPsec, XML-ENC/DSIG, JOSE, Mobile IP, L2 =
ciphering, and anything of that sort have these common. And the same =
applies to this method. These should be common unless we are inventing =
some new crypto, or not using the crypto the right way. Neither is meant =
to be the case. We are fixing up the issues you are identifying.
>=20
> Yes, but the point is that it's *hard* to design a new protocol of
> this kind that
> doesn't have a bunch of security issues, as evidenced by the number of
> things i found in a cursory inspection. Thus, the barrier to arguing =
that
> you need a new protocol is fairly high.
>=20
>=20
>> The essential difference among those protocols is the "layer" they =
operate on.
>=20
> Yes but I have yet to hear a convincing argument for why that is a =
significant
> improvement in this case.
>=20
> -Ekr
>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>> -Ekr
>>=20
>>=20


From ekr@rtfm.com  Thu Nov 17 19:52:36 2011
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 779151F0C57 for ; Thu, 17 Nov 2011 19:52:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.947
X-Spam-Level: 
X-Spam-Status: No, score=-102.947 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F13XfYr0j2Zo for ; Thu, 17 Nov 2011 19:52:36 -0800 (PST)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id A23F81F0C51 for ; Thu, 17 Nov 2011 19:52:35 -0800 (PST)
Received: by ywt34 with SMTP id 34so2370048ywt.31 for ; Thu, 17 Nov 2011 19:52:35 -0800 (PST)
Received: by 10.236.195.4 with SMTP id o4mr2178727yhn.6.1321588355147; Thu, 17 Nov 2011 19:52:35 -0800 (PST)
MIME-Version: 1.0
Received: by 10.146.88.36 with HTTP; Thu, 17 Nov 2011 19:51:54 -0800 (PST)
X-Originating-IP: [74.95.2.173]
In-Reply-To: <2AADF161-AA69-433A-99E7-08F37968B5B3@yegin.org>
References:    <1758DEE6-C7E7-43DD-953A-8850EABA1869@yegin.org>  <2AADF161-AA69-433A-99E7-08F37968B5B3@yegin.org>
From: Eric Rescorla 
Date: Thu, 17 Nov 2011 19:51:54 -0800
Message-ID: 
To: Alper Yegin 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "CORE \(Constrained RESTful Environments\) WG" 
Subject: Re: [core] Review of draft-yegin-coap-security-options-00
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Nov 2011 03:52:36 -0000

On Thu, Nov 17, 2011 at 7:46 PM, Alper Yegin  wrote:
>
> Obviously we must get the crypto right (I'd have been surprised if we got=
 it 100% right in version-00).


> But I think the primary question on the table is this:
>
> =A0 =A0 =A0 =A0What is(are) the right layer(s) we shall define or rely on=
 a security solution for CoAP.
>
> One can rely on security at one or more of the following layers:
>
> Physical
> Link-layer
> Network (e.g., IPsec)
> Transport (e.g., DTLS)
> CoAP-layer (this proposal)
> CoAP-payload media-layer (XML, JSON, etc.)
> Application layer
>
>
> Solutions at each layer above have its pros and cons.
> We talk about such things all the time in IETF. We end up following diffe=
rent approaches most of the time. I was in PCP earlier, and now I see they =
are relying on Phy and Link-layer security.

> I'm not saying we shall always have solutions at every layer for any prot=
ocol. It goes case-by-case, and we have a case at hand.


Yes, we do, but these decisions aren't made in a vacuum.

One of the important constraints in these discussions is what
protocols already exist. In this case, we have an existing, mature protocol
being compared against a new protocol with extremely similar security
properties (i.e., one that is not gaining substantial superior security
properties via upper layer integration), with the only real arguments
for the new protocol being efficiency. If you were actually making
use of the fact that you were integrating it into CoAP, I might feel
differently.


>> Yes but I have yet to hear a convincing argument for why that is a signi=
ficant
>> improvement in this case.
>
> Can we dive into that during/after my presentation? My detailed answer is=
 there.

OK. As a preview, if the argument you're planning to offer is based on
wire format
compactness (which appears to be what your slides say) I find that profound=
ly
unconvincing.

-Ekr

From tianlinyi@huawei.com  Thu Nov 17 20:00:50 2011
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 37DF211E80CA for ; Thu, 17 Nov 2011 20:00:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.082
X-Spam-Level: 
X-Spam-Status: No, score=-5.082 tagged_above=-999 required=5 tests=[AWL=1.516,  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 7LrpqQtVmShZ for ; Thu, 17 Nov 2011 20:00:49 -0800 (PST)
Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 2489811E8073 for ; Thu, 17 Nov 2011 20:00:49 -0800 (PST)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUU00K4O8BOKB@szxga04-in.huawei.com> for core@ietf.org; Fri, 18 Nov 2011 11:57:24 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUU002ES8AYCD@szxga04-in.huawei.com> for core@ietf.org; Fri, 18 Nov 2011 11:57:24 +0800 (CST)
Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AFD70308; Fri, 18 Nov 2011 11:57:24 +0800
Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 18 Nov 2011 11:57:12 +0800
Received: from SZXEML513-MBX.china.huawei.com ([169.254.8.59]) by szxeml405-hub.china.huawei.com ([10.82.67.60]) with mapi id 14.01.0323.003; Fri, 18 Nov 2011 11:56:39 +0800
Date: Fri, 18 Nov 2011 03:57:11 +0000
From: TianLinyi 
X-Originating-IP: [172.24.2.40]
To: "core@ietf.org" 
Message-id: <3615F3CCD55F054395A882F51C6E5FDA182027B3@szxeml513-mbx.china.huawei.com>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_SEJI4ZRezNBydqVPLkPKEw)"
Content-language: zh-CN
Accept-Language: zh-CN, en-US
Thread-topic: Group Management feature
Thread-index: AcylpY1VpkIBbtWwT+uaxHCAwurMBA==
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
Subject: [core] Group Management feature
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, 18 Nov 2011 04:00:50 -0000

--Boundary_(ID_SEJI4ZRezNBydqVPLkPKEw)
Content-type: text/plain; charset=gb2312
Content-transfer-encoding: 7BIT

Hi, All



I would like to give some information about how application guys doing by leveraging our drafts:

1. When sensor is detected by the gateway, or it is registered with gateway using mechanism defined in draft-nieminen-core-service-discovery-01 or some othe mechanisms.

2. Gateway can notify the application server with inventory information.

3. Application Server can create the group by listing the device identifiers or based on some condition. Then gateway can assign the group identifer and gives to application server.



Group management is completely possible in application layer. Maybe we don't need to keep it in appendix either.



For multicast topic i see some value in this draft. I agree with Jari that we need to focus on specific topics in this draft and make it simpler.



Cheers,

Linyi

--Boundary_(ID_SEJI4ZRezNBydqVPLkPKEw)
Content-type: text/html; charset=gb2312
Content-transfer-encoding: 7BIT










Hi, All


 


I would like to give some information about how application guys doing by leveraging our drafts:


1. When sensor is detected by the gateway, or it is registered with gateway using mechanism defined in
draft-nieminen-core-service-discovery-01 or some othe mechanisms.


2. Gateway can notify the application server with inventory information.


3. Application Server can create the group by listing the device identifiers or based on some condition. Then gateway can assign the group identifer and gives to application server.


 


Group management is completely possible in application layer. Maybe we don't need to keep it in appendix either.


 


For multicast topic i see some value in this draft. I agree with Jari that we need to focus on specific topics in this draft and make it simpler.



 


Cheers,


Linyi






--Boundary_(ID_SEJI4ZRezNBydqVPLkPKEw)--

From alper.yegin@yegin.org  Thu Nov 17 20:02:08 2011
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 5E32511E80CD for ; Thu, 17 Nov 2011 20:02:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.584
X-Spam-Level: 
X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 VTQhgCQSBQEm for ; Thu, 17 Nov 2011 20:02:07 -0800 (PST)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id C685911E8073 for ; Thu, 17 Nov 2011 20:02:07 -0800 (PST)
Received: from [10.1.1.2] (odakk1.odakk.com [78.111.98.194]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0Lp3DY-1QvCcI0Fgi-00ehw7; Thu, 17 Nov 2011 23:02:06 -0500
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: text/plain; charset=iso-8859-1
From: Alper Yegin 
In-Reply-To: 
Date: Fri, 18 Nov 2011 06:01:57 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <360A6FB0-3AE6-4C46-9666-9779EBE24C30@yegin.org>
References:    <1758DEE6-C7E7-43DD-953A-8850EABA1869@yegin.org>  <2AADF161-AA69-433A-99E7-08F37968B5B3@yegin.org> 
To: Eric Rescorla 
X-Mailer: Apple Mail (2.1244.3)
X-Provags-ID: V02:K0:cguiN5zARCN67VGazhbzxYA4EZk9c74QU8R39Irrci+ l/7bJveMIej02qtIkZq0rosMkSbYcvU0h26WU+/58GRupIfyz2 R6fdbiO2lHGkJstJWKLYTOSLrGnpDLp77eiPcgVB569BfEP7ie jqXYeeXteIKBBkfMV9TzZC0Yxn5s3PNYc3+7zgyg6DhmnJ4YNB CzfxrbEshqnyCD11O900BofhzTv7n0C0njaDq0CePRBaPclmSd QdHgSuWrhdIgmBcgDTK4z4rjgBBKHAZIoOv6uPhbzrIJFCmO2G pMM9XrXCjbaMlxbGM5a6/jkDviXJq5Z/nHdFdDCk2PRixxthob kqYswhXAt3z6K6L/KWAXC2BwdlbFRW6JvCNNQcLgD
Cc: "CORE \(Constrained RESTful Environments\) WG" 
Subject: Re: [core] Review of draft-yegin-coap-security-options-00
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Nov 2011 04:02:08 -0000

>=20
>> But I think the primary question on the table is this:
>>=20
>>        What is(are) the right layer(s) we shall define or rely on a =
security solution for CoAP.
>>=20
>> One can rely on security at one or more of the following layers:
>>=20
>> Physical
>> Link-layer
>> Network (e.g., IPsec)
>> Transport (e.g., DTLS)
>> CoAP-layer (this proposal)
>> CoAP-payload media-layer (XML, JSON, etc.)
>> Application layer
>>=20
>>=20
>> Solutions at each layer above have its pros and cons.
>> We talk about such things all the time in IETF. We end up following =
different approaches most of the time. I was in PCP earlier, and now I =
see they are relying on Phy and Link-layer security.
>=20
>> I'm not saying we shall always have solutions at every layer for any =
protocol. It goes case-by-case, and we have a case at hand.
>=20
>=20
> Yes, we do, but these decisions aren't made in a vacuum.
>=20
> One of the important constraints in these discussions is what
> protocols already exist. In this case, we have an existing, mature =
protocol
> being compared against a new protocol with extremely similar security
> properties (i.e., one that is not gaining substantial superior =
security
> properties via upper layer integration), with the only real arguments
> for the new protocol being efficiency. If you were actually making
> use of the fact that you were integrating it into CoAP, I might feel
> differently.
>=20

I'm integrating into CoAP, and highlighting the benefits. See Slide 5. =
All those different uses are possible only if we use a CoAP-layer =
security. Cannot do the same with IPsec/DTLS.


>=20
>>> Yes but I have yet to hear a convincing argument for why that is a =
significant
>>> improvement in this case.
>>=20
>> Can we dive into that during/after my presentation? My detailed =
answer is there.
>=20
> OK. As a preview, if the argument you're planning to offer is based on
> wire format
> compactness (which appears to be what your slides say) I find that =
profoundly
> unconvincing.
>=20


Over-the-wire byte savings and round-trips saving are there. But that's =
not what excites me (maybe some gets excited, as it seems like we are =
after byte/rtt savings in this WG). Slide 5 is what I find more =
appealing.

Alper



> -Ekr


From hannes.tschofenig@gmx.net  Thu Nov 17 20:46:55 2011
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 D095D11E8097 for ; Thu, 17 Nov 2011 20:46:55 -0800 (PST)
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 St90obAdATCd for ; Thu, 17 Nov 2011 20:46:55 -0800 (PST)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id B628711E808B for ; Thu, 17 Nov 2011 20:46:54 -0800 (PST)
Received: (qmail invoked by alias); 18 Nov 2011 04:46:52 -0000
Received: from dhcp-172b.meeting.ietf.org (EHLO dhcp-172b.meeting.ietf.org) [130.129.23.43] by mail.gmx.net (mp056) with SMTP; 18 Nov 2011 05:46:52 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX18ZwGYeS+EZoHEk2D45q637PIBulthJtoc4zpgEbj B28j07rxRlELso
From: Hannes Tschofenig 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Fri, 18 Nov 2011 05:46:48 +0100
Message-Id: <77779B09-22DB-484B-BAFD-D7C8FEC6159A@gmx.net>
To: core 
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
X-Y-GMX-Trusted: 0
Subject: [core] draft-yegin-coap-security-options-00
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Nov 2011 04:46:55 -0000

I also read this document.=20

I do not quite understand why DTLS does not work for you. You are =
essentially defining another authentication and key exchange protocol =
above UDP. It claims to be an "efficient alternative" to DTLS but does =
not explain why. Designing new cryptographic mechanisms from scratch is =
time consuming and difficult. The document is missing a lot of details =
of what would be needed to describe such a protocol!

Ciao
Hannes



From robert.cragie@gridmerge.com  Thu Nov 17 21:07:11 2011
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 B404111E80B5 for ; Thu, 17 Nov 2011 21:07:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJ9wen8fpHc8 for ; Thu, 17 Nov 2011 21:07:11 -0800 (PST)
Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by ietfa.amsl.com (Postfix) with ESMTP id AD0DA11E80B2 for ; Thu, 17 Nov 2011 21:07:10 -0800 (PST)
Received: from client-86-31-219-171.oxfd.adsl.virginmedia.com ([86.31.219.171] helo=[192.168.1.80]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) id 1RRGfK-0007dW-C6; Fri, 18 Nov 2011 05:07:06 +0000
Message-ID: <4EC5E7F9.5000108@gridmerge.com>
Date: Fri, 18 Nov 2011 05:07:05 +0000
From: Robert Cragie 
Organization: Gridmerge Ltd.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Alper Yegin 
References:    <1758DEE6-C7E7-43DD-953A-8850EABA1869@yegin.org>  <2AADF161-AA69-433A-99E7-08F37968B5B3@yegin.org>  <360A6FB0-3AE6-4C46-9666-9779EBE24C30@yegin.org>
In-Reply-To: <360A6FB0-3AE6-4C46-9666-9779EBE24C30@yegin.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080606020205000407060901"
X-Authenticated-As: robert.cragie@gridmerge.com
Cc: "CORE \(Constrained RESTful Environments\) WG" 
Subject: Re: [core] Review of draft-yegin-coap-security-options-00
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, 18 Nov 2011 05:07:11 -0000

This is a cryptographically signed message in MIME format.

--------------ms080606020205000407060901
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

I think there are two questions to consider here:

1) Do we need CoAP-layer security, i.e. where we distinguish the=20
header/payload(s) at the CoAP layer and provide corresponding message=20
protection?
2) If so, is the mechanism described in the document adequate?

For (1), I think there may be some merits to specifying, as Alper points =

out on slide 5. Also, in my experience so far, it seems the IETF=20
generally likes to have a protocol message security solution whether it=20
ends up getting used or not to meet the general security requirements=20
for a protocol, for example for RPL options.
For (2), the solution proposed does seem lightweight and therefore open=20
to the issues already raised by others.

Some specific other comments:

* The CryptoInitiate needs to be more conversational and establish a=20
more distinct session, along the lines of (D)TLS/IKEv2/HIP BEX/DEX
* Use of the pre-shared key for session establishment and message=20
protection is overloading the use of the key. A separate session key=20
should be established. Or is the intent that the initial pre-shared key=20
be different for every session anyway? If so, then there will need to be =

an additional KMP anyway to establish this key, which would resemble=20
(D)TLS/IKEv2 no doubt, so we seem to be back to square one.

Robert

On 18/11/2011 4:01 AM, Alper Yegin wrote:
>>> But I think the primary question on the table is this:
>>>
>>>         What is(are) the right layer(s) we shall define or rely on a =
security solution for CoAP.
>>>
>>> One can rely on security at one or more of the following layers:
>>>
>>> Physical
>>> Link-layer
>>> Network (e.g., IPsec)
>>> Transport (e.g., DTLS)
>>> CoAP-layer (this proposal)
>>> CoAP-payload media-layer (XML, JSON, etc.)
>>> Application layer
>>>
>>>
>>> Solutions at each layer above have its pros and cons.
>>> We talk about such things all the time in IETF. We end up following d=
ifferent approaches most of the time. I was in PCP earlier, and now I see=
 they are relying on Phy and Link-layer security.
>>> I'm not saying we shall always have solutions at every layer for any =
protocol. It goes case-by-case, and we have a case at hand.
>>
>> Yes, we do, but these decisions aren't made in a vacuum.
>>
>> One of the important constraints in these discussions is what
>> protocols already exist. In this case, we have an existing, mature pro=
tocol
>> being compared against a new protocol with extremely similar security
>> properties (i.e., one that is not gaining substantial superior securit=
y
>> properties via upper layer integration), with the only real arguments
>> for the new protocol being efficiency. If you were actually making
>> use of the fact that you were integrating it into CoAP, I might feel
>> differently.
>>
> I'm integrating into CoAP, and highlighting the benefits. See Slide 5. =
All those different uses are possible only if we use a CoAP-layer securit=
y. Cannot do the same with IPsec/DTLS.
>
>
>>>> Yes but I have yet to hear a convincing argument for why that is a s=
ignificant
>>>> improvement in this case.
>>> Can we dive into that during/after my presentation? My detailed answe=
r is there.
>> OK. As a preview, if the argument you're planning to offer is based on=

>> wire format
>> compactness (which appears to be what your slides say) I find that pro=
foundly
>> unconvincing.
>>
>
> Over-the-wire byte savings and round-trips saving are there. But that's=
 not what excites me (maybe some gets excited, as it seems like we are af=
ter byte/rtt savings in this WG). Slide 5 is what I find more appealing.
>
> Alper
>
>
>
>> -Ekr
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>


--------------ms080606020205000407060901
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
sAU2MMOpel4RijGCBAwwggQIAgEBMIGoMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl
YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0Eg
TGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj
dXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9mMAkGBSsOAwIaBQCgggI4MBgGCSqGSIb3
DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMTExODA1MDcwNVowIwYJKoZI
hvcNAQkEMRYEFJLenwtARxRi18HOPcnEQt9NZ/j7MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZI
AWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr
DgMCBzANBggqhkiG9w0DAgIBKDCBuQYJKwYBBAGCNxAEMYGrMIGoMIGTMQswCQYDVQQGEwJH
QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYD
VQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50
aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9mMIG7BgsqhkiG
9w0BCRACCzGBq6CBqDCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl
c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3
BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD
QQIQXDFQ28QtqMuYch5f2nTvZjANBgkqhkiG9w0BAQEFAASCAQBYcyMLt6q4YjwJvB2eFMi3
Ty4i4xtSkED2cEVrKfCC6/b1CSk/xJ1fzoQJyhOaKgnxTrBM1Uop21FsfaD7YXOrSYYlyYPv
EO3e5Al6Fl67n7R5LPjVX52rpC9wn9hsB7cDnJKjZsDDHrpPBIHBH7o+juYI6urSuFFU+k0x
XWN+bSYBaQonz4QbBKHcwyBN4rlZ9wnk+KO4CVKpkqgMcGSVcKXLUs4iypx6lrUg7HAShR7R
QH9SfPW3Uu/IKyCOMWHO/cZArZtoUxjGOdqzM6GZCbsWvt3eeFm0Sh1K0GI+kwEdxXC9srS7
gCJY1XMKU21PblaQdzkfAZo7wF1+R0U3AAAAAAAA
--------------ms080606020205000407060901--

From ekr@rtfm.com  Thu Nov 17 21:10:45 2011
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 2E6D511E808B for ; Thu, 17 Nov 2011 21:10:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.948
X-Spam-Level: 
X-Spam-Status: No, score=-102.948 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIA1eIyYLDGN for ; Thu, 17 Nov 2011 21:10:44 -0800 (PST)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9F60E21F8BF4 for ; Thu, 17 Nov 2011 21:10:44 -0800 (PST)
Received: by ghrr14 with SMTP id r14so160625ghr.31 for ; Thu, 17 Nov 2011 21:10:44 -0800 (PST)
Received: by 10.236.181.134 with SMTP id l6mr2282849yhm.18.1321593044220; Thu, 17 Nov 2011 21:10:44 -0800 (PST)
MIME-Version: 1.0
Received: by 10.146.88.36 with HTTP; Thu, 17 Nov 2011 21:10:04 -0800 (PST)
X-Originating-IP: [74.95.2.173]
In-Reply-To: <4EC5E7F9.5000108@gridmerge.com>
References:    <1758DEE6-C7E7-43DD-953A-8850EABA1869@yegin.org>  <2AADF161-AA69-433A-99E7-08F37968B5B3@yegin.org>  <360A6FB0-3AE6-4C46-9666-9779EBE24C30@yegin.org> <4EC5E7F9.5000108@gridmerge.com>
From: Eric Rescorla 
Date: Thu, 17 Nov 2011 21:10:04 -0800
Message-ID: 
To: robert.cragie@gridmerge.com
Content-Type: text/plain; charset=ISO-8859-1
Cc: "CORE \(Constrained RESTful Environments\) WG" 
Subject: Re: [core] Review of draft-yegin-coap-security-options-00
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Nov 2011 05:10:45 -0000

On Thu, Nov 17, 2011 at 9:07 PM, Robert Cragie
 wrote:
> For (1), I think there may be some merits to specifying, as Alper points out
> on slide 5. Also, in my experience so far, it seems the IETF generally likes
> to have a protocol message security solution whether it ends up getting used
> or not to meet the general security requirements for a protocol, for example
> for RPL options.

That hasn't been my experience. The vast majority of the protocols I'm familiar
with are basically just being used with some channel-level security mechansm
(typically TLS).

-Ekr

From hannes.tschofenig@gmx.net  Thu Nov 17 21:16:41 2011
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 623CE11E80CA for ; Thu, 17 Nov 2011 21:16:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RD2jRiyzA7LO for ; Thu, 17 Nov 2011 21:16:40 -0800 (PST)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 1A00411E8097 for ; Thu, 17 Nov 2011 21:16:39 -0800 (PST)
Received: (qmail invoked by alias); 18 Nov 2011 05:16:37 -0000
Received: from dhcp-172b.meeting.ietf.org (EHLO dhcp-172b.meeting.ietf.org) [130.129.23.43] by mail.gmx.net (mp062) with SMTP; 18 Nov 2011 06:16:37 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1/S3PUZWKvSjCd8N+EQpNUHhpI1koqJRYzpyfPZaQ aaJ7SMyoTIOsuZ
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Hannes Tschofenig 
In-Reply-To: <4EC5E7F9.5000108@gridmerge.com>
Date: Fri, 18 Nov 2011 06:16:33 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:    <1758DEE6-C7E7-43DD-953A-8850EABA1869@yegin.org>  <2AADF161-AA69-433A-99E7-08F37968B5B3@yegin.org>  <360A6FB0-3AE6-4C46-9666-9779EBE24C30@yegin.org> <4EC5E7F9.5000108@gridmerge.com>
To: robert.cragie@gridmerge.com
X-Mailer: Apple Mail (2.1084)
X-Y-GMX-Trusted: 0
Cc: "CORE \(Constrained RESTful Environments\) WG" 
Subject: Re: [core] Review of draft-yegin-coap-security-options-00
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Nov 2011 05:16:41 -0000

Hi Robert,=20

If you want an application layer security solution then why don't you =
use use the work JOSE is doing by protecting some application specific =
elements using JSON object signing and encryption?=20

Ciao
Hannes

On Nov 18, 2011, at 6:07 AM, Robert Cragie wrote:

> I think there are two questions to consider here:
>=20
> 1) Do we need CoAP-layer security, i.e. where we distinguish the =
header/payload(s) at the CoAP layer and provide corresponding message =
protection?
> 2) If so, is the mechanism described in the document adequate?
>=20
> For (1), I think there may be some merits to specifying, as Alper =
points out on slide 5. Also, in my experience so far, it seems the IETF =
generally likes to have a protocol message security solution whether it =
ends up getting used or not to meet the general security requirements =
for a protocol, for example for RPL options.
> For (2), the solution proposed does seem lightweight and therefore =
open to the issues already raised by others.
>=20
> Some specific other comments:
>=20
> * The CryptoInitiate needs to be more conversational and establish a =
more distinct session, along the lines of (D)TLS/IKEv2/HIP BEX/DEX
> * Use of the pre-shared key for session establishment and message =
protection is overloading the use of the key. A separate session key =
should be established. Or is the intent that the initial pre-shared key =
be different for every session anyway? If so, then there will need to be =
an additional KMP anyway to establish this key, which would resemble =
(D)TLS/IKEv2 no doubt, so we seem to be back to square one.
>=20
> Robert
>=20
> On 18/11/2011 4:01 AM, Alper Yegin wrote:
>>>> But I think the primary question on the table is this:
>>>>=20
>>>>        What is(are) the right layer(s) we shall define or rely on a =
security solution for CoAP.
>>>>=20
>>>> One can rely on security at one or more of the following layers:
>>>>=20
>>>> Physical
>>>> Link-layer
>>>> Network (e.g., IPsec)
>>>> Transport (e.g., DTLS)
>>>> CoAP-layer (this proposal)
>>>> CoAP-payload media-layer (XML, JSON, etc.)
>>>> Application layer
>>>>=20
>>>>=20
>>>> Solutions at each layer above have its pros and cons.
>>>> We talk about such things all the time in IETF. We end up following =
different approaches most of the time. I was in PCP earlier, and now I =
see they are relying on Phy and Link-layer security.
>>>> I'm not saying we shall always have solutions at every layer for =
any protocol. It goes case-by-case, and we have a case at hand.
>>>=20
>>> Yes, we do, but these decisions aren't made in a vacuum.
>>>=20
>>> One of the important constraints in these discussions is what
>>> protocols already exist. In this case, we have an existing, mature =
protocol
>>> being compared against a new protocol with extremely similar =
security
>>> properties (i.e., one that is not gaining substantial superior =
security
>>> properties via upper layer integration), with the only real =
arguments
>>> for the new protocol being efficiency. If you were actually making
>>> use of the fact that you were integrating it into CoAP, I might feel
>>> differently.
>>>=20
>> I'm integrating into CoAP, and highlighting the benefits. See Slide =
5. All those different uses are possible only if we use a CoAP-layer =
security. Cannot do the same with IPsec/DTLS.
>>=20
>>=20
>>>>> Yes but I have yet to hear a convincing argument for why that is a =
significant
>>>>> improvement in this case.
>>>> Can we dive into that during/after my presentation? My detailed =
answer is there.
>>> OK. As a preview, if the argument you're planning to offer is based =
on
>>> wire format
>>> compactness (which appears to be what your slides say) I find that =
profoundly
>>> unconvincing.
>>>=20
>>=20
>> Over-the-wire byte savings and round-trips saving are there. But =
that's not what excites me (maybe some gets excited, as it seems like we =
are after byte/rtt savings in this WG). Slide 5 is what I find more =
appealing.
>>=20
>> Alper
>>=20
>>=20
>>=20
>>> -Ekr
>> _______________________________________________
>> core mailing list
>> core@ietf.org
>> https://www.ietf.org/mailman/listinfo/core
>>=20
>=20
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core


From robert.cragie@gridmerge.com  Thu Nov 17 21:19:47 2011
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 2667E21F9457 for ; Thu, 17 Nov 2011 21:19:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rEXQ8O80H5zB for ; Thu, 17 Nov 2011 21:19:46 -0800 (PST)
Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by ietfa.amsl.com (Postfix) with ESMTP id 2763321F944E for ; Thu, 17 Nov 2011 21:19:46 -0800 (PST)
Received: from client-86-31-219-171.oxfd.adsl.virginmedia.com ([86.31.219.171] helo=[192.168.1.80]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) id 1RRGrY-00053I-0s; Fri, 18 Nov 2011 05:19:44 +0000
Message-ID: <4EC5EAEF.4000501@gridmerge.com>
Date: Fri, 18 Nov 2011 05:19:43 +0000
From: Robert Cragie 
Organization: Gridmerge Ltd.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Eric Rescorla 
References:    <1758DEE6-C7E7-43DD-953A-8850EABA1869@yegin.org>  <2AADF161-AA69-433A-99E7-08F37968B5B3@yegin.org>  <360A6FB0-3AE6-4C46-9666-9779EBE24C30@yegin.org> <4EC5E7F9.5000108@gridmerge.com> 
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010805020605010802060504"
X-Authenticated-As: robert.cragie@gridmerge.com
Cc: "CORE \(Constrained RESTful Environments\) WG" 
Subject: Re: [core] Review of draft-yegin-coap-security-options-00
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, 18 Nov 2011 05:19:47 -0000

This is a cryptographically signed message in MIME format.

--------------ms010805020605010802060504
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

I remember the discussion regarding RPL and there still ended up being=20
some relatively arcane mechanism for protecting RPL packets. IIRC the=20
argument was that it wasn't sufficient to say that the RPL packets would =

be protected at Layer 2 and that using IPSec (the obvious solution) was=20
too heavyweight. So maybe the IETFs encroachment into trying to optimise =

for bytes on the wire and device complexity is spawning these additional =

security mechanisms. I personally agree with you - I think it makes far=20
more sense to use DTLS.

Robert

On 18/11/2011 5:10 AM, Eric Rescorla wrote:
> On Thu, Nov 17, 2011 at 9:07 PM, Robert Cragie
>   wrote:
>> For (1), I think there may be some merits to specifying, as Alper poin=
ts out
>> on slide 5. Also, in my experience so far, it seems the IETF generally=
 likes
>> to have a protocol message security solution whether it ends up gettin=
g used
>> or not to meet the general security requirements for a protocol, for e=
xample
>> for RPL options.
> That hasn't been my experience. The vast majority of the protocols I'm =
familiar
> with are basically just being used with some channel-level security mec=
hansm
> (typically TLS).
>
> -Ekr
>


--------------ms010805020605010802060504
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
sAU2MMOpel4RijGCBAwwggQIAgEBMIGoMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl
YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0Eg
TGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj
dXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9mMAkGBSsOAwIaBQCgggI4MBgGCSqGSIb3
DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMTExODA1MTk0M1owIwYJKoZI
hvcNAQkEMRYEFJqetSvgv0piod/yi1AP+4K2mj0TMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZI
AWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr
DgMCBzANBggqhkiG9w0DAgIBKDCBuQYJKwYBBAGCNxAEMYGrMIGoMIGTMQswCQYDVQQGEwJH
QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYD
VQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50
aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9mMIG7BgsqhkiG
9w0BCRACCzGBq6CBqDCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl
c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3
BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD
QQIQXDFQ28QtqMuYch5f2nTvZjANBgkqhkiG9w0BAQEFAASCAQAd1QFNnT96RDDJY6EcJxp0
nf/SZ0Gg04BruyKe7iSCXc7ngHtngoe0gQ+EZ+nsvhqy0jWnkWZCLdwylIsCGFL3rAP5gEZC
X/uqJC6CdtME7VqdHj7QzL+pP94C1Tqp9cm7NNw1n8Q/x3IRVQk6YzQ2w/Q3hGZRgqLnUa1q
8ntyx0/Qg617AYQsQUP/buABIznjFAyJbzernqxuYcx1JMu4txqKfvvwd5Xf5oyka8NzjbNz
DaXIiWgzyokGqPG9L2AeUOJ2fvYq63o+i6ISB0zGXjxW+MXggVeeOb86qext0ZNv+/xQyy6D
sin2oRCspnQmh0JnzRT053pKins8QkZKAAAAAAAA
--------------ms010805020605010802060504--

From zach@sensinode.com  Thu Nov 17 21:20:00 2011
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 50FD721F944E for ; Thu, 17 Nov 2011 21:20:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.474
X-Spam-Level: 
X-Spam-Status: No, score=-3.474 tagged_above=-999 required=5 tests=[AWL=0.125,  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 N1f+tVyUqNrv for ; Thu, 17 Nov 2011 21:19:55 -0800 (PST)
Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 54FA321F9461 for ; Thu, 17 Nov 2011 21:19:54 -0800 (PST)
Received: from dhcp-123b.meeting.ietf.org (dhcp-123b.meeting.ietf.org [130.129.18.59]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id pAI5Jh4o017520 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 18 Nov 2011 07:19:48 +0200
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/signed; boundary=Apple-Mail-712--311000955; protocol="application/pkcs7-signature"; micalg=sha1
From: Zach Shelby 
In-Reply-To: <77779B09-22DB-484B-BAFD-D7C8FEC6159A@gmx.net>
Date: Fri, 18 Nov 2011 13:19:42 +0800
Message-Id: 
References: <77779B09-22DB-484B-BAFD-D7C8FEC6159A@gmx.net>
To: Hannes Tschofenig 
X-Mailer: Apple Mail (2.1084)
Cc: core 
Subject: Re: [core] draft-yegin-coap-security-options-00
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Nov 2011 05:20:00 -0000

--Apple-Mail-712--311000955
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

I want to explain my intensions by co-authoring this with Alper.=20

Talking to people over the last years while starting and during the CoRE =
WG, the stark reality is that there is a huge gap between what M2M =
industry people need (want?) and what the IETF has to offer in terms of =
security.=20

Thanks to lots of cross-area cooperation and helpful security people, =
this is getting better. For example recent work on more efficient =
ciphers, the work on raw public keys, or object security work in JOSE. =
Our draft is a bit controversial on purpose as we want to stimulate =
discussion.=20
	- Is there interest and possible need for this class of security =
in CoRE?=20
	- Are there ways that DTLS could be made better for simple PSK =
applications?=20
	- How do we fill the gap between NoSec and PreSharedKey modes?=20=


What I am hearing so far, is that security people think it is not a good =
idea to design a new security protocol. Personally, I agree.=20

However, does that mean that we have volunteers to help make DTLS even =
more applicable to M2M applications? TinyDTLS? If that is what we are =
stuck with for all constrained application environments, it might be the =
long-term direction we need to take.=20

Zach

=20

On Nov 18, 2011, at 12:46 PM, Hannes Tschofenig wrote:

> I also read this document.=20
>=20
> I do not quite understand why DTLS does not work for you. You are =
essentially defining another authentication and key exchange protocol =
above UDP. It claims to be an "efficient alternative" to DTLS but does =
not explain why. Designing new cryptographic mechanisms from scratch is =
time consuming and difficult. The document is missing a lot of details =
of what would be needed to describe such a protocol!
>=20
> Ciao
> Hannes
>=20
>=20
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core

--=20
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297


--Apple-Mail-712--311000955
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMWTCCBWMw
ggRLoAMCAQICEHOCkw2jxZ3D/33R5ncHHbgwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT
MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg
KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g
Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTEwMTAwMDAwMDBaFw0x
MjEwMDkyMzU5NTlaMIIBEDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S
UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh
bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2
aWNlMRQwEgYDVQQDFAtaYWNoIFNoZWxieTEhMB8GCSqGSIb3DQEJARYSemFjaEBzZW5zaW5vZGUu
Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzhUEvdReCaejkXy7oHgfRykbzYKT
UVdKPk27VuoqRENDsQvOx+7PedUCyaXF1CUyzY5/QI+8lRyPEdyctsqAKTb1Pp0Bx0zgpsSHrFVb
+JTLLEI4rKJ2KogmzXar3FQow+819WT0tIC7QIwma6m6N2MpxVGXd6VGTidqshi7ZfvyDwUh1BuH
HYgn8/fgTAvCFJoLD6asYUZ/AKreqDD7lwyjPZG5AfoaXPilBzuVIGArLCcYvaWSlMpntokmU5oh
5AjZX8Wmg32rxYnCy6NCGyoQHq1iQTnleH0eUcbvG5fTGDnOs1scoHHKeZ6meyFFDAc/d2KJJ8zW
bEKU2MalcQIDAQABo4HoMIHlMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAq
MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAd
BgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwFAYKYIZIAYb4RQEGBwQGFgROb25lMFAGA1Ud
HwRJMEcwRaBDoEGGP2h0dHA6Ly9pbmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29tL0lu
ZEMxRGlnaXRhbElELUczLmNybDANBgkqhkiG9w0BAQUFAAOCAQEATFvGnK8aGE+tObyxTKI5EzlL
7RKS5iH7fQ0DIdLXNTph4XZL1kLxp3LIwsm2+UsptMhtk7nXT8sWgiH8pugbYUZQl/pZZeTbcqGb
rPpWTQg1jqXNo0nZJG1jvgGyuA4ozmSiD6frU/s58cUCwNdmPK41lunpS4KyLbgw7vQZCwrb0RGW
YkCrVds9CtncAlcHROFAuuNsgrN6GX+VEsfqw+u+eOVIMaAVKfXqfquuLp/p41HgkDC6onA2biaO
guxLuH/fAhIwSNe8TBS/bYMTF8yROSxn0mnNryhMOZTsqt4R0XEgXxyNpPIgRmrg3DgnqldFWDPn
zHHOQRx73R3fXTCCBu4wggXWoAMCAQICEHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEFBQAw
gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig
YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp
bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAwMDAwMFoXDTE5MDQz
MDIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE
CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBz
Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlk
YXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0Eg
LSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAO3ER98qKB18Bmu71yEyyWwTj+mx
jUFONPfaC+Nq+mWIIAsRE+mb4ElOi2/VAdBfDUeRilpMdD4/xpEJu0w0no1uoYJRYvdpdliWB6+e
FBgHT1q9n9IxslQZc0ZqGUIR7BJzIY313DDN5dlWCjHFNm0pFJe9LdqJRxmI2EsEPeu2PGcedAAT
DdCG2pNn+DMDrho8a2l49sAsjuGDP3f5mf/+n1JawrSHCthsqUfBVCllQz5KwJYfwa33d69ssQRe
vsG2lC2XkC0n0rse6YNqhPbEsq4jBmUmpSdYKwcitG+mYkgad/LVUCeaKdOW+yj1uiR2YuOMWev7
btVCxL5Bx/UCAwEAAaOCArkwggK1MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDov
L29jc3AudmVyaXNpZ24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkwZzBlBgtghkgB
hvhFAQcXATBWMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMCoGCCsG
AQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCegJYYj
aHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4GCCsG
AQUFBwEMBGIwYKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy70FI4
mymsSweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAuBgNVHREE
JzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4EFgQUeUdhCEH9
OASiS+e1zPVD9kkrEfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UEBhMCVVMxFzAVBgNV
BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYD
VQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUw
QwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0
aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUAA4IBAQA5Tc9BmYG1
qQW1UjjpOYSJbOQ0qFrn2GwJTCQaulmkhztzIfGTgc+/aGNaZ/41hSuhw12jSsI6Gd0w1sxN7/HS
gZfKVFpDvzeLeo4ZjQ9DqIzyr2CzFYqzlZw84J6zJ5ikNXIX5fwqXYfTig3C0UUq+MD0rCqTOtWu
EnAI6/s74nfs6CtkNXbNutrg0csU1nFYm77VPn222egkxSRmTF2RH3azFz5/DcYhiS+zN7ih/1yy
bUneZVJC+w6I0u1KHb9L4/jMcvpIDmWOScjW+JmYO7eUPjFxBof6bFlTLtffK+1fYwCsFe0DuFUW
jMZoA+ciqHMLsbyg2lJY3QoOf8GCMYIEizCCBIcCAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkG
A1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkx
HjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3Mg
MSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQc4KTDaPFncP/fdHmdwcduDAJBgUrDgMC
GgUAoIICbTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTExMTgw
NTE5NDNaMCMGCSqGSIb3DQEJBDEWBBQtPfhRrtASSQ8nbnLC7cYSUG/2YjCCAQMGCSsGAQQBgjcQ
BDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6
Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRh
dGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAt
IEczAhBzgpMNo8Wdw/990eZ3Bx24MIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNVBAYT
AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0
d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9y
cGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNp
Z24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQc4KTDaPFncP/fdHmdwcd
uDANBgkqhkiG9w0BAQEFAASCAQAi4D5Onq0660Nf/tKi0orqs3o4bxyCUb+GUL+2unpdhIpDVnVi
80+Y8PBUIKTcfGHfMIbU0nov0u1+eDUpRhMf2M7RCZWD7sT1x4r2W8YH7hNPpUmxjHIW12WUldJ0
sAu2eykMXTaTkeK9SdWf9IT693o9yDdgsr5AT9LbGqc2UWXsmnSoW8LRxvRWMrxbX3jZikPKxDRh
xdCgyBPs4B9mnEPxFX7VXw3LphwKakUamlmYQOqtD7UgEG/VU9DtMz5WzOts1xZMD25aBsDmNYD1
tHyWyhmUQa3w7IniEUQl61ApHf1YJxfvw7t3RZ5UTn3VcBz6fuSpadLJpaaCRB3uAAAAAAAA

--Apple-Mail-712--311000955--

From ekr@rtfm.com  Thu Nov 17 21:37:52 2011
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 A28AD11E80DE for ; Thu, 17 Nov 2011 21:37:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.949
X-Spam-Level: 
X-Spam-Status: No, score=-102.949 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yWO96nxiisKh for ; Thu, 17 Nov 2011 21:37:51 -0800 (PST)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF1021F8482 for ; Thu, 17 Nov 2011 21:37:51 -0800 (PST)
Received: by yenq4 with SMTP id q4so2437324yen.31 for ; Thu, 17 Nov 2011 21:37:51 -0800 (PST)
Received: by 10.236.181.134 with SMTP id l6mr2369552yhm.18.1321594671094; Thu, 17 Nov 2011 21:37:51 -0800 (PST)
MIME-Version: 1.0
Received: by 10.146.88.36 with HTTP; Thu, 17 Nov 2011 21:37:11 -0800 (PST)
X-Originating-IP: [74.95.2.173]
In-Reply-To: 
References: <77779B09-22DB-484B-BAFD-D7C8FEC6159A@gmx.net> 
From: Eric Rescorla 
Date: Thu, 17 Nov 2011 21:37:11 -0800
Message-ID: 
To: Zach Shelby 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: core 
Subject: Re: [core] draft-yegin-coap-security-options-00
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Nov 2011 05:37:52 -0000

On Thu, Nov 17, 2011 at 9:19 PM, Zach Shelby  wrote:
> I want to explain my intensions by co-authoring this with Alper.
>
> Talking to people over the last years while starting and during the CoRE =
WG, the stark reality is that there is a huge gap between what M2M industry=
 people need (want?) and what the IETF has to offer in terms of security.
>
> Thanks to lots of cross-area cooperation and helpful security people, thi=
s is getting better. For example recent work on more efficient ciphers, the=
 work on raw public keys, or object security work in JOSE. Our draft is a b=
it controversial on purpose as we want to stimulate discussion.
> =A0 =A0 =A0 =A0- Is there interest and possible need for this class of se=
curity in CoRE?
> =A0 =A0 =A0 =A0- Are there ways that DTLS could be made better for simple=
 PSK applications?
> =A0 =A0 =A0 =A0- How do we fill the gap between NoSec and PreSharedKey mo=
des?
>
> What I am hearing so far, is that security people think it is not a good =
idea to design a new security protocol. Personally, I agree.
>
> However, does that mean that we have volunteers to help make DTLS even mo=
re applicable to M2M applications? TinyDTLS? If that is what we are stuck w=
ith for all constrained application environments, it might be the long-term=
 direction we need to take.

I'm certainly enthusiastic about trying to make DTLS work better for CoAP.

I think it would be best to start with an enumeration of the (no doubt
many) deficiencies in
DTLS which are affecting you. Some of them may be fixable within DTLS,
some may require a
different style of protocol, and some may be open research questions.
But we won't know
till we have a gap analysis...

-Ekr

From hannes.tschofenig@gmx.net  Thu Nov 17 21:50:29 2011
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 BAD9921F90B6 for ; Thu, 17 Nov 2011 21:50:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.979
X-Spam-Level: 
X-Spam-Status: No, score=-101.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, SARE_LWSHORTT=1.24, 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 KvlqhlHkQyPK for ; Thu, 17 Nov 2011 21:50:23 -0800 (PST)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 5058421F8C09 for ; Thu, 17 Nov 2011 21:50:18 -0800 (PST)
Received: (qmail invoked by alias); 18 Nov 2011 05:50:16 -0000
Received: from dhcp-172b.meeting.ietf.org (EHLO dhcp-172b.meeting.ietf.org) [130.129.23.43] by mail.gmx.net (mp010) with SMTP; 18 Nov 2011 06:50:16 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX195eLcJ1/J57OsHTQXxNCECYb+bUfj6RY7cK2gw9T ruSMvfFFniRNX0
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Hannes Tschofenig 
In-Reply-To: 
Date: Fri, 18 Nov 2011 06:50:11 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <78538823-B882-4D57-B543-EEAA60F4ABD8@gmx.net>
References: <77779B09-22DB-484B-BAFD-D7C8FEC6159A@gmx.net> 
To: Zach Shelby 
X-Mailer: Apple Mail (2.1084)
X-Y-GMX-Trusted: 0
Cc: core 
Subject: Re: [core] draft-yegin-coap-security-options-00
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Nov 2011 05:50:29 -0000

Hi Zach,=20

I found the slides from the meeting that contained some information =
about the performance benefits. I will have to look at the details of it =
a little later.=20

I fully understand your need to make security mechanisms fit the smart =
object space. The problem here is, however, that there are different =
design goals.=20

For example, a design decision you have to make is whether you want an =
initial authentication and key exchange phase followed by the actual =
protection of the data traffic (integrity/confidentiality/data-origin =
authentication).=20

The benefit of having these two phases is that you can do the expensive =
operations at the beginning and then you get to be more efficient later =
with the data protection itself. Clearly, a solution that does not do =
the initial phase (as it is the case with, for example, CMS) is from a =
message point of view much more efficient. If you main goal is to reduce =
the number of messages then you are clearly able to accomplish it by =
omitting the initial phase.

In your writeup I actually get the impression that the context setup and =
context teardown are not complete since they do not offer the main =
features provided with many other protocols, such as the actually =
authentication and key establishment (establishment of short term =
temporary keys). Typically, you want to avoid using your long-term =
credentials for the per-packet security.=20

So, I believe it helps a lot to explain what your main goals are, such =
as reducing the code size, the number of messages, the per-packet =
overhead,  the number of cryptographic operations, the number of =
different cryptographic primitives etc. Typically, these goals will be =
in conflict with the set of features you want to have.=20

Ciao
Hannes

On Nov 18, 2011, at 6:19 AM, Zach Shelby wrote:

> I want to explain my intensions by co-authoring this with Alper.=20
>=20
> Talking to people over the last years while starting and during the =
CoRE WG, the stark reality is that there is a huge gap between what M2M =
industry people need (want?) and what the IETF has to offer in terms of =
security.=20
>=20
> Thanks to lots of cross-area cooperation and helpful security people, =
this is getting better. For example recent work on more efficient =
ciphers, the work on raw public keys, or object security work in JOSE. =
Our draft is a bit controversial on purpose as we want to stimulate =
discussion.=20
> 	- Is there interest and possible need for this class of security =
in CoRE?=20
> 	- Are there ways that DTLS could be made better for simple PSK =
applications?=20
> 	- How do we fill the gap between NoSec and PreSharedKey modes?=20=

>=20
> What I am hearing so far, is that security people think it is not a =
good idea to design a new security protocol. Personally, I agree.=20
>=20
> However, does that mean that we have volunteers to help make DTLS even =
more applicable to M2M applications? TinyDTLS? If that is what we are =
stuck with for all constrained application environments, it might be the =
long-term direction we need to take.=20
>=20
> Zach
>=20
>=20
>=20
> On Nov 18, 2011, at 12:46 PM, Hannes Tschofenig wrote:
>=20
>> I also read this document.=20
>>=20
>> I do not quite understand why DTLS does not work for you. You are =
essentially defining another authentication and key exchange protocol =
above UDP. It claims to be an "efficient alternative" to DTLS but does =
not explain why. Designing new cryptographic mechanisms from scratch is =
time consuming and difficult. The document is missing a lot of details =
of what would be needed to describe such a protocol!
>>=20
>> Ciao
>> Hannes
>>=20
>>=20
>> _______________________________________________
>> core mailing list
>> core@ietf.org
>> https://www.ietf.org/mailman/listinfo/core
>=20
> --=20
> Zach Shelby, Chief Nerd, Sensinode Ltd.
> http://www.sensinode.com
> 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


From stpeter@stpeter.im  Thu Nov 17 22:09:08 2011
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 B782321F9655 for ; Thu, 17 Nov 2011 22:09:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.552
X-Spam-Level: 
X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.047, 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 YRo3ozIBm2Pi for ; Thu, 17 Nov 2011 22:09:08 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 0409121F9615 for ; Thu, 17 Nov 2011 22:09:07 -0800 (PST)
Received: from dhcp-1422.meeting.ietf.org (unknown [130.129.20.34]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 99E7D421BB; Thu, 17 Nov 2011 23:15:27 -0700 (MST)
Message-ID: <4EC5F680.2030708@stpeter.im>
Date: Fri, 18 Nov 2011 14:09:04 +0800
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Eric Rescorla 
References: <77779B09-22DB-484B-BAFD-D7C8FEC6159A@gmx.net>  
In-Reply-To: 
X-Enigmail-Version: 1.3.3
OpenPGP: url=https://stpeter.im/stpeter.asc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: core 
Subject: Re: [core] draft-yegin-coap-security-options-00
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Nov 2011 06:09:08 -0000

On 11/18/11 1:37 PM, Eric Rescorla wrote:
> On Thu, Nov 17, 2011 at 9:19 PM, Zach Shelby  wrote:
>> I want to explain my intensions by co-authoring this with Alper.
>>
>> Talking to people over the last years while starting and during the CoRE WG, the stark reality is that there is a huge gap between what M2M industry people need (want?) and what the IETF has to offer in terms of security.
>>
>> Thanks to lots of cross-area cooperation and helpful security people, this is getting better. For example recent work on more efficient ciphers, the work on raw public keys, or object security work in JOSE. Our draft is a bit controversial on purpose as we want to stimulate discussion.
>>        - Is there interest and possible need for this class of security in CoRE?
>>        - Are there ways that DTLS could be made better for simple PSK applications?
>>        - How do we fill the gap between NoSec and PreSharedKey modes?
>>
>> What I am hearing so far, is that security people think it is not a good idea to design a new security protocol. Personally, I agree.
>>
>> However, does that mean that we have volunteers to help make DTLS even more applicable to M2M applications? TinyDTLS? If that is what we are stuck with for all constrained application environments, it might be the long-term direction we need to take.
> 
> I'm certainly enthusiastic about trying to make DTLS work better for CoAP.
> 
> I think it would be best to start with an enumeration of the (no doubt
> many) deficiencies in
> DTLS which are affecting you. Some of them may be fixable within DTLS,
> some may require a
> different style of protocol, and some may be open research questions.
> But we won't know
> till we have a gap analysis...

The audio had cut off when Cullen said this, but he asked the authors to
post to the SAAG list about this topic.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



From zach@sensinode.com  Fri Nov 18 06:09:22 2011
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 66FF921F8B2A for ; Fri, 18 Nov 2011 06:09:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.099
X-Spam-Level: 
X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500,  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 ZporJcqTlO67 for ; Fri, 18 Nov 2011 06:09:17 -0800 (PST)
Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id F134021F8AFE for ; Fri, 18 Nov 2011 06:09:14 -0800 (PST)
Received: from [172.20.3.72] (203-69-99-17.HINET-IP.hinet.net [203.69.99.17] (may be forged)) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id pAIE92at001216 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 18 Nov 2011 16:09:07 +0200
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/signed; boundary=Apple-Mail-721--279242278; protocol="application/pkcs7-signature"; micalg=sha1
From: Zach Shelby 
In-Reply-To: <4EC5F680.2030708@stpeter.im>
Date: Fri, 18 Nov 2011 22:09:01 +0800
Message-Id: 
References: <77779B09-22DB-484B-BAFD-D7C8FEC6159A@gmx.net>   <4EC5F680.2030708@stpeter.im>
To: Peter Saint-Andre 
X-Mailer: Apple Mail (2.1084)
Cc: core 
Subject: Re: [core] draft-yegin-coap-security-options-00
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Nov 2011 14:09:22 -0000

--Apple-Mail-721--279242278
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Nov 18, 2011, at 2:09 PM, Peter Saint-Andre wrote:

>> I'm certainly enthusiastic about trying to make DTLS work better for =
CoAP.
>>=20
>> I think it would be best to start with an enumeration of the (no =
doubt
>> many) deficiencies in
>> DTLS which are affecting you. Some of them may be fixable within =
DTLS,
>> some may require a
>> different style of protocol, and some may be open research questions.
>> But we won't know
>> till we have a gap analysis...
>=20
> The audio had cut off when Cullen said this, but he asked the authors =
to
> post to the SAAG list about this topic.

Of course this CoAP security option document needs to be discussed in =
SAAG as Cullen pointed out. Not in a rush in my opinion.

I like the idea of writing a kind of session security for M2M =
requirements and gap analysis draft, which could help us in thinking =
about future DTLS improvements. We can probably find authors to work on =
that on this list, and submit it to the TLS WG. This should also point =
out use cases as Hannes suggested.=20

=46rom my experience so far, we can live with DTLS PSK or RPK for most =
of the higher-end M2M applications (like Cellular M2M). So this document =
would shoot for the other applications in-between where implementers, =
system designers and other SDOs might be tempted to do something less =
than secure by themselves if they perceive DTLS as being too heavy or =
unsuitable for their needs.=20

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


--Apple-Mail-721--279242278
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMWTCCBWMw
ggRLoAMCAQICEHOCkw2jxZ3D/33R5ncHHbgwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT
MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg
KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g
Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTEwMTAwMDAwMDBaFw0x
MjEwMDkyMzU5NTlaMIIBEDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S
UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh
bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2
aWNlMRQwEgYDVQQDFAtaYWNoIFNoZWxieTEhMB8GCSqGSIb3DQEJARYSemFjaEBzZW5zaW5vZGUu
Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzhUEvdReCaejkXy7oHgfRykbzYKT
UVdKPk27VuoqRENDsQvOx+7PedUCyaXF1CUyzY5/QI+8lRyPEdyctsqAKTb1Pp0Bx0zgpsSHrFVb
+JTLLEI4rKJ2KogmzXar3FQow+819WT0tIC7QIwma6m6N2MpxVGXd6VGTidqshi7ZfvyDwUh1BuH
HYgn8/fgTAvCFJoLD6asYUZ/AKreqDD7lwyjPZG5AfoaXPilBzuVIGArLCcYvaWSlMpntokmU5oh
5AjZX8Wmg32rxYnCy6NCGyoQHq1iQTnleH0eUcbvG5fTGDnOs1scoHHKeZ6meyFFDAc/d2KJJ8zW
bEKU2MalcQIDAQABo4HoMIHlMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAq
MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAd
BgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwFAYKYIZIAYb4RQEGBwQGFgROb25lMFAGA1Ud
HwRJMEcwRaBDoEGGP2h0dHA6Ly9pbmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29tL0lu
ZEMxRGlnaXRhbElELUczLmNybDANBgkqhkiG9w0BAQUFAAOCAQEATFvGnK8aGE+tObyxTKI5EzlL
7RKS5iH7fQ0DIdLXNTph4XZL1kLxp3LIwsm2+UsptMhtk7nXT8sWgiH8pugbYUZQl/pZZeTbcqGb
rPpWTQg1jqXNo0nZJG1jvgGyuA4ozmSiD6frU/s58cUCwNdmPK41lunpS4KyLbgw7vQZCwrb0RGW
YkCrVds9CtncAlcHROFAuuNsgrN6GX+VEsfqw+u+eOVIMaAVKfXqfquuLp/p41HgkDC6onA2biaO
guxLuH/fAhIwSNe8TBS/bYMTF8yROSxn0mnNryhMOZTsqt4R0XEgXxyNpPIgRmrg3DgnqldFWDPn
zHHOQRx73R3fXTCCBu4wggXWoAMCAQICEHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEFBQAw
gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig
YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp
bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAwMDAwMFoXDTE5MDQz
MDIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE
CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBz
Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlk
YXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0Eg
LSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAO3ER98qKB18Bmu71yEyyWwTj+mx
jUFONPfaC+Nq+mWIIAsRE+mb4ElOi2/VAdBfDUeRilpMdD4/xpEJu0w0no1uoYJRYvdpdliWB6+e
FBgHT1q9n9IxslQZc0ZqGUIR7BJzIY313DDN5dlWCjHFNm0pFJe9LdqJRxmI2EsEPeu2PGcedAAT
DdCG2pNn+DMDrho8a2l49sAsjuGDP3f5mf/+n1JawrSHCthsqUfBVCllQz5KwJYfwa33d69ssQRe
vsG2lC2XkC0n0rse6YNqhPbEsq4jBmUmpSdYKwcitG+mYkgad/LVUCeaKdOW+yj1uiR2YuOMWev7
btVCxL5Bx/UCAwEAAaOCArkwggK1MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDov
L29jc3AudmVyaXNpZ24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkwZzBlBgtghkgB
hvhFAQcXATBWMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMCoGCCsG
AQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCegJYYj
aHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4GCCsG
AQUFBwEMBGIwYKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy70FI4
mymsSweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAuBgNVHREE
JzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4EFgQUeUdhCEH9
OASiS+e1zPVD9kkrEfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UEBhMCVVMxFzAVBgNV
BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYD
VQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUw
QwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0
aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUAA4IBAQA5Tc9BmYG1
qQW1UjjpOYSJbOQ0qFrn2GwJTCQaulmkhztzIfGTgc+/aGNaZ/41hSuhw12jSsI6Gd0w1sxN7/HS
gZfKVFpDvzeLeo4ZjQ9DqIzyr2CzFYqzlZw84J6zJ5ikNXIX5fwqXYfTig3C0UUq+MD0rCqTOtWu
EnAI6/s74nfs6CtkNXbNutrg0csU1nFYm77VPn222egkxSRmTF2RH3azFz5/DcYhiS+zN7ih/1yy
bUneZVJC+w6I0u1KHb9L4/jMcvpIDmWOScjW+JmYO7eUPjFxBof6bFlTLtffK+1fYwCsFe0DuFUW
jMZoA+ciqHMLsbyg2lJY3QoOf8GCMYIEizCCBIcCAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkG
A1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkx
HjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3Mg
MSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQc4KTDaPFncP/fdHmdwcduDAJBgUrDgMC
GgUAoIICbTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTExMTgx
NDA5MDFaMCMGCSqGSIb3DQEJBDEWBBRD/umPldCrjvy+EL3tDmqHWmsogzCCAQMGCSsGAQQBgjcQ
BDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6
Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRh
dGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAt
IEczAhBzgpMNo8Wdw/990eZ3Bx24MIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNVBAYT
AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0
d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9y
cGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNp
Z24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQc4KTDaPFncP/fdHmdwcd
uDANBgkqhkiG9w0BAQEFAASCAQADq0pvUwNyknEUigBhwhsJPdg2wr8adDU/E4tf5ersmwD+msOb
8Sjg9DymjoRrm+XDv+DCT1I3j8gfXLlKbIO/7DGUdyQSwqWkZjXPs/Q/WDnXB+B2mtOuiBa0BJGI
ukKuS10X3tky6YOHU0rBD3vfwwcufBOFAL1HPQ55SPc0z38PSqjuCQhJMZ/ZBKXGsBNZIx8SCd4M
sJ9ox69fRBjwJg/SLbiu8+TuhUMc5YlfwLA1r5fxOptePW5U5fzhaUPzNsHIJExF/XPmqKRV+64a
o1jerNWDAp1dnBT5qbteW4t/25GfTQxgxyC+KYDPcWeTv4Fu/4W7ijaOEpenTe7sAAAAAAAA

--Apple-Mail-721--279242278--

From sarikaya2012@gmail.com  Fri Nov 18 06:21:19 2011
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 2343721F8B08 for ; Fri, 18 Nov 2011 06:21:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.484
X-Spam-Level: 
X-Spam-Status: No, score=-3.484 tagged_above=-999 required=5 tests=[AWL=0.114,  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 EIYEPeN4shwW for ; Fri, 18 Nov 2011 06:21:18 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3A33921F8500 for ; Fri, 18 Nov 2011 06:21:18 -0800 (PST)
Received: by ggeq3 with SMTP id q3so1176522gge.31 for ; Fri, 18 Nov 2011 06:21:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=46u8mzfbZ6+ZQzgGJ1/fIHjsB6EXyOzVOcyb9cKSlwg=; b=iGyy+3BaucVB+bEfa+Onxame3LWGUy8KZMdy/yDzgWKl9oPFr9YcoU1HpCxefisieA n13t4gbwmYzCGpOY8wBb0u5wAdV6FO5sx1sDtzyZZrUU9TCzSpP69jRXlDlBNMT74BHl NFwKFQl9TN2NgNLKBakCkh1ViGOSjfzI7sCm0=
MIME-Version: 1.0
Received: by 10.147.147.7 with SMTP id z7mr769141yan.15.1321626077804; Fri, 18 Nov 2011 06:21:17 -0800 (PST)
Received: by 10.236.191.228 with HTTP; Fri, 18 Nov 2011 06:21:17 -0800 (PST)
In-Reply-To: <3615F3CCD55F054395A882F51C6E5FDA182027B3@szxeml513-mbx.china.huawei.com>
References: <3615F3CCD55F054395A882F51C6E5FDA182027B3@szxeml513-mbx.china.huawei.com>
Date: Fri, 18 Nov 2011 08:21:17 -0600
Message-ID: 
From: Behcet Sarikaya 
To: "Rahman, Akbar" 
Content-Type: multipart/alternative; boundary=000e0cd2e03ce4b7c704b2030ce3
Cc: "core@ietf.org" 
Subject: Re: [core] Group Management feature
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: Fri, 18 Nov 2011 14:21:19 -0000

--000e0cd2e03ce4b7c704b2030ce3
Content-Type: text/plain; charset=ISO-8859-1

Hi Akbar, all,
2011/11/17 TianLinyi 

>  Hi, All
>
>
>
> I would like to give some information about how application guys doing by
> leveraging our drafts:
>
> 1. When sensor is detected by the gateway, or it is registered with
> gateway using mechanism defined in
> draft-nieminen-core-service-discovery-01or some othe mechanisms.
>
> 2. Gateway can notify the application server with inventory information.
>
> 3. Application Server can create the group by listing the device
> identifiers or based on some condition. Then gateway can assign the group
> identifer and gives to application server.
>
>
>
> Group management is completely possible in application layer. Maybe we
> don't need to keep it in appendix either.
>
>
>
> For multicast topic i see some value in this draft. I agree with Jari that
> we need to focus on specific topics in this draft and make it simpler.
>
>
>
+1

I think mld related issues are better discussed in other places like
Multimob.

Regards,

Behcet

--000e0cd2e03ce4b7c704b2030ce3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Hi Akbar, all,
2011/11/17 TianLinyi <tianlinyi@huawei.c=
om>











Hi, All


=A0


I would like to give some information about how application guys doing b=
y leveraging our drafts:


1. When sensor is detected by the gateway, or it is registered with gate=
way using mechanism defined in
draft-nieminen-core-service-discovery-01 or some othe mechanisms.<=
/p>

2. Gateway can notify the application server with inventory information.=



3. Application Server can create the group by listing the device identif=
iers or based on some condition. Then gateway can assign the group identife=
r and gives to application server.


=A0


Group management is completely possible in application layer. Maybe we d=
on't need to keep it in appendix either.


=A0


For multicast topic i see some value in this draft. I agree with Jari th=
at we need to focus on specific topics in this draft and make it simpler.



=A0
+1

I think mld related i=
ssues are better discussed in other places like Multimob.

Regards,
Behcet 


--000e0cd2e03ce4b7c704b2030ce3--

From esko.dijk@philips.com  Mon Nov 21 03:05:13 2011
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 E0A9E21F8BAC for ; Mon, 21 Nov 2011 03:05:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.669
X-Spam-Level: 
X-Spam-Status: No, score=-2.669 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_20=-0.74, 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 5SFaBCbNQana for ; Mon, 21 Nov 2011 03:05:09 -0800 (PST)
Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id 8C11721F8B9E for ; Mon, 21 Nov 2011 03:05:09 -0800 (PST)
Received: from mail134-ch1-R.bigfish.com (10.43.68.244) by CH1EHSOBE004.bigfish.com (10.43.70.54) with Microsoft SMTP Server id 14.1.225.22; Mon, 21 Nov 2011 11:04:30 +0000
Received: from mail134-ch1 (localhost [127.0.0.1])	by mail134-ch1-R.bigfish.com (Postfix) with ESMTP id BBE3528047A	for ; Mon, 21 Nov 2011 11:04:21 +0000 (UTC)
X-SpamScore: -13
X-BigFish: VPS-13(zz217bL15d6O9251Jc85fhzz1202hzzz2dh2a8h668h839h)
X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI
X-FB-SS: 13,
Received: from mail134-ch1 (localhost.localdomain [127.0.0.1]) by mail134-ch1 (MessageSwitch) id 1321873461636362_7170; Mon, 21 Nov 2011 11:04:21 +0000 (UTC)
Received: from CH1EHSMHS018.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.250])	by mail134-ch1.bigfish.com (Postfix) with ESMTP id 8C8A3640046	for ; Mon, 21 Nov 2011 11:04:21 +0000 (UTC)
Received: from mail.philips.com (157.55.7.222) by CH1EHSMHS018.bigfish.com (10.43.70.18) with Microsoft SMTP Server (TLS) id 14.1.225.22; Mon, 21 Nov 2011 11:04:29 +0000
Received: from 011-DB3MPN1-012.MGDPHG.emi.philips.com ([169.254.2.218]) by 011-DB3MMR1-007.MGDPHG.emi.philips.com ([10.128.28.57]) with mapi id 14.01.0355.003; Mon, 21 Nov 2011 11:04:47 +0000
From: "Dijk, Esko" 
To: "core@ietf.org" 
Thread-Topic: Audio recordings of CoRE WG meetings IETF 82
Thread-Index: AcyoPWDbH+KuJy0oREO1YTTyxi61xA==
Date: Mon, 21 Nov 2011 11:04:46 +0000
Message-ID: <031DD135F9160444ABBE3B0C36CED61801C4F9@011-DB3MPN1-012.MGDPHG.emi.philips.com>
Accept-Language: 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_031DD135F9160444ABBE3B0C36CED61801C4F9011DB3MPN1012MGDP_"
MIME-Version: 1.0
X-OriginatorOrg: philips.com
Subject: [core] Audio recordings of CoRE WG meetings IETF 82
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, 21 Nov 2011 11:05:14 -0000

--_000_031DD135F9160444ABBE3B0C36CED61801C4F9011DB3MPN1012MGDP_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dear all,

for convenience I extracted the CoRE WG meeting audio from the IETF82 audio=
 recordings, into 2 files:

http://www.eskodijk.nl/IETF/ietf82-CoRE-1.mp3
http://www.eskodijk.nl/IETF/ietf82-CoRE-2.mp3

(Pre-session noise removed; parts of session 2 still missing; format set to=
 mono mp3 so this fixes the problem that in the IETF recordings the audio c=
ould only be heard at the left headphone.)

regards,
Esko


________________________________
The information contained in this message may be confidential and legally p=
rotected under applicable law. The message is intended solely for the addre=
ssee(s). If you are not the intended recipient, you are hereby notified tha=
t any use, forwarding, dissemination, or reproduction of this message is st=
rictly prohibited and may be unlawful. If you are not the intended recipien=
t, please contact the sender by return e-mail and destroy all copies of the=
 original message.

--_000_031DD135F9160444ABBE3B0C36CED61801C4F9011DB3MPN1012MGDP_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable










Dear all,


 


for convenience I extracted the CoRE WG meeting audi=
o from the IETF82 audio recordings, into 2 files:


 


http://www.eskodijk.nl/IETF/ietf82-CoRE-1.mp3


http://www.eskodijk.nl/IETF/ietf82-CoRE-2.mp3


 


(Pre-session noise removed; parts of session 2 still=
 missing; format set to mono mp3 so this fixes the problem that in the IETF=
 recordings the audio could only be heard at the left headphone.)


 


regards,


Esko


 







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

From esko.dijk@philips.com  Mon Nov 28 03:02:42 2011
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 1535C21F8B00 for ; Mon, 28 Nov 2011 03:02:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.999
X-Spam-Level: 
X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_50=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 1kJgGFeHt3ud for ; Mon, 28 Nov 2011 03:02:41 -0800 (PST)
Received: from VA3EHSOBE001.bigfish.com (va3ehsobe001.messaging.microsoft.com [216.32.180.11]) by ietfa.amsl.com (Postfix) with ESMTP id B474A21F85BB for ; Mon, 28 Nov 2011 03:02:40 -0800 (PST)
Received: from mail140-va3-R.bigfish.com (10.7.14.251) by VA3EHSOBE001.bigfish.com (10.7.40.21) with Microsoft SMTP Server id 14.1.225.22; Mon, 28 Nov 2011 11:01:53 +0000
Received: from mail140-va3 (localhost [127.0.0.1])	by mail140-va3-R.bigfish.com (Postfix) with ESMTP id 6A3B83001A1; Mon, 28 Nov 2011 10:58:15 +0000 (UTC)
X-SpamScore: -46
X-BigFish: VPS-46(zz217bL15d6O9251J936eK542M1db9Mzz1202hzz1033IL8275bh8275dhz2dh2a8h668h839h944h61h)
X-Spam-TCS-SCL: 0:0
X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI
Received: from mail140-va3 (localhost.localdomain [127.0.0.1]) by mail140-va3 (MessageSwitch) id 1322477894953782_439; Mon, 28 Nov 2011 10:58:14 +0000 (UTC)
Received: from VA3EHSMHS012.bigfish.com (unknown [10.7.14.252])	by mail140-va3.bigfish.com (Postfix) with ESMTP id DCAA7180045; Mon, 28 Nov 2011 10:58:14 +0000 (UTC)
Received: from mail.philips.com (157.55.7.222) by VA3EHSMHS012.bigfish.com (10.7.99.22) with Microsoft SMTP Server (TLS) id 14.1.225.22; Mon, 28 Nov 2011 11:01:51 +0000
Received: from 011-DB3MPN1-012.MGDPHG.emi.philips.com ([169.254.2.218]) by 011-DB3MMR1-011.MGDPHG.emi.philips.com ([10.128.28.50]) with mapi id 14.01.0355.003; Mon, 28 Nov 2011 11:02:36 +0000
From: "Dijk, Esko" 
To: Carsten Bormann , core WG , Zach Shelby 
Thread-Topic: [core] Second WGLC for draft-ietf-core-link-format-09.txt
Thread-Index: AQHMpN8raIOMnRP2+EekD7Ivap+WRpXCIIeQ
Date: Mon, 28 Nov 2011 11:02:35 +0000
Message-ID: <031DD135F9160444ABBE3B0C36CED61801E1FD@011-DB3MPN1-012.MGDPHG.emi.philips.com>
References: <2F008BD6-3D3D-4772-8289-08A8AF098AAA@tzi.org>
In-Reply-To: <2F008BD6-3D3D-4772-8289-08A8AF098AAA@tzi.org>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [194.171.252.101]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: philips.com
Subject: Re: [core] Second WGLC for draft-ietf-core-link-format-09.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Nov 2011 11:02:42 -0000

Dear Carsten,

I reviewed the changes (diff v3/v9) and text surrounding the changes; see c=
omments below. The first three points should be clarified or fixed in my vi=
ew. In general, the document looks in good shape.

** Relation type: RFC5988 supports multiple relations in one string/entry. =
Should we support this or explicitly (e.g. "SHOULD NOT") exclude this in Co=
RE Link Format context? For example:
        rel=3D"http://example.com/myRelationType1 http://example.com/myRela=
tionType2 describedby"

This may be an issue if a constrained client is looking for a "describedby"=
 relation using the byte-wise string comparison suggested by core-link-form=
at: it would not match to above string unfortunately. Also, it causes probl=
ems if the "rel" value is stored on a CoRE server as one key/value pair and=
 if I would do a query with resource-param =3D "rel" to look for a specific=
 relation type such as "describedby", or "copyright" or "http://example.com=
/myRelationType2". Again, this would not match as it is not bytewise identi=
cal as defined in core-link-format as the matching criterion. One solution =
would be to state in core-link-format something like "the value of a "rel" =
parameter SHOULD NOT contain more than one relation type" i.e. optimize the=
 use of RFC5988 a bit for constrained environments by constraining its flex=
ibility. Another solution approach is to provide more guidance in how to do=
 the matching in case of the "rel" attribute. Yet another solution approach=
 is to allow multiple relations in one "rel" value, but add some mandatory =
implementation guidance that multiple, say N, relations should be stored as=
 N separate relations so these can be individually found using filtering/qu=
erying.

** use of "quoted-string" in ABNF definitions - should be a regular string,=
 not "quoted-string" here?
link-extension =3D/ ( "rt=3D" quoted-string )
link-extension =3D/ ( "if=3D" quoted-string )

** Unclear sentence (for me) "A query-pattern of "*" will match that resour=
ce-param with an empty string value."
 Was it intended that "*" matches to an empty string value as well as to an=
y other non-empty string ?
 Or does this sentence intend to clarify that if the query is "*" then the =
string prefix matching process will use an empty string as the string to ma=
tch all values against? (In which case, also all value strings will match).
 Or both?

** Multicast and filtering:
  "A multicast request with a query string MUST NOT be responded
  to if filtering is not supported or if the filter does not match (to
  avoid a needless response storm)."
I'm thinking if this could also be a "SHOULD NOT" requirement, but perhaps =
there's a good reason why "MUST NOT" is used here. If anyone on the list ha=
s further opinions on this, I would be interested.


** Minor issues and typos
- Just a thought: In the intro e.g. section 1.1 or 1.2 we could add explici=
tly that CoRE Link Format can be applied in for example HTTP servers or CoA=
P servers. Some people may unconsciously and wrongly associate "CoRE Link F=
ormat" to "CoAP link format" e.g. due to its previous linkage to CoAP Conte=
nt Types and "ct" attribute.

- "Removed the assumption of a default content-type assumption"

- "To express other relations a links can make use of"

- "To express other relations a links can make use of any registered
relation parameter or target attributes by including the relation parameter=
."
  So, a link can make use of a relation parameter by including the relation=
 parameter - does not seem to add much, it's obvious? If I include somethin=
g I use it. Or was it meant "...use of any registered relation or target at=
tributes..." ?

- In below text, the first and second example looks exactly the same, contr=
adicting the text:
"""
  ;rt=3D"TemperatureC";if=3D"sensor",
  ;rt=3D"LightLux";if=3D"sensor"
  Without the linefeeds included for readability, the format actually
  looks as follows.
  ;rt=3D"TemperatureC";if=3D"sensor",
  ;rt=3D"LightLux";if=3D"sensor"
"""

- "When using a transfer protocol like the Constrained Application
Protocol (CoAP) that supports multicast requests, special care is taken."
Perhaps "is taken" -> "needs to be taken" ?

- "interface description" vs "Interface Description" - are they the same th=
ing? If so use same capitalization.

- "Resource registration can be archived by having each server POST" -> ...=
"can be achieved"

best regards,
Esko

-----Original Message-----
From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Car=
sten Bormann
Sent: Thursday 17 November 2011 5:13
To: core WG
Subject: [core] Second WGLC for draft-ietf-core-link-format-09.txt

On January 16 this year, core-link-format-02 finished working group last ca=
ll.
On March 15, the -03 draft incorporated the changes from the comments recei=
ved on this WGLC.

Since that update, the draft has experienced some Brownian motion.
Changes were made e.g. to adapt the examples to some coap-core changes, to =
clarify the use of UTF-8, to address AD comments, and to properly distribut=
e the normative content between the different CoRE specs.
With -09, we now have a version that passes all ID-Nits.
While I personally think it could be justified to send this on to the IESG =
as is, I also think that might be considered bad form.

So I'm announcing today a

   second working-group last call
   for draft-ietf-core-link-format-09.txt

This is a one-week WGLC, but time does not pass during an IETF.
So please send in any comments to the CoRE list now, or latest until

   2011-11-28, 1200 UTC.

A short note of the form "I've re-read -09 and it's OK" would also be very =
welcome.

Gruesse, Carsten

PS.: You can use
http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-link-format-09&url1=3D=
draft-ietf-core-link-format-03
to review the changes since -03.

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

________________________________
The information contained in this message may be confidential and legally p=
rotected under applicable law. The message is intended solely for the addre=
ssee(s). If you are not the intended recipient, you are hereby notified tha=
t any use, forwarding, dissemination, or reproduction of this message is st=
rictly prohibited and may be unlawful. If you are not the intended recipien=
t, please contact the sender by return e-mail and destroy all copies of the=
 original message.


From cabo@tzi.org  Mon Nov 28 03:36:15 2011
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 F32A221F8D02 for ; Mon, 28 Nov 2011 03:36:14 -0800 (PST)
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 tbSrwHsWU+Jv for ; Mon, 28 Nov 2011 03:36:10 -0800 (PST)
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 8EE4021F8D04 for ; Mon, 28 Nov 2011 03:36:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id pASBa0LF008724; Mon, 28 Nov 2011 12:36:00 +0100 (CET)
Received: from [10.0.1.3] (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 92E5029C; Mon, 28 Nov 2011 12:36:00 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann 
In-Reply-To: <031DD135F9160444ABBE3B0C36CED61801E1FD@011-DB3MPN1-012.MGDPHG.emi.philips.com>
Date: Mon, 28 Nov 2011 12:36:00 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <2F008BD6-3D3D-4772-8289-08A8AF098AAA@tzi.org> <031DD135F9160444ABBE3B0C36CED61801E1FD@011-DB3MPN1-012.MGDPHG.emi.philips.com>
To: "Dijk, Esko" 
X-Mailer: Apple Mail (2.1251.1)
Cc: core WG 
Subject: Re: [core] Second WGLC for draft-ietf-core-link-format-09.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Nov 2011 11:36:15 -0000

Hi Esko,

these are very useful comments.

I don't understand this one, though:

On Nov 28, 2011, at 12:02, Dijk, Esko wrote:

> ** use of "quoted-string" in ABNF definitions - should be a regular =
string, not "quoted-string" here?
> link-extension =3D/ ( "rt=3D" quoted-string )
> link-extension =3D/ ( "if=3D" quoted-string )

=46rom RFC 2616 we import via RFC 5988:

   A string of text is parsed as a single word if it is quoted using
   double-quote marks.

       quoted-string  =3D ( <"> *(qdtext | quoted-pair ) <"> )
       qdtext         =3D >

   The backslash character ("\") MAY be used as a single-character
   quoting mechanism only within quoted-string and comment constructs.

       quoted-pair    =3D "\" CHAR

Is this not exactly what we want to have?
As in:

   ;rt=3D"TemperatureC";if=3D"sensor",
   ;rt=3D"LightLux";if=3D"sensor"

An alternative would be ptoken, as in:

   ;rt=3DTemperatureC;if=3Dsensor,
   ;rt=3DLightLux;if=3Dsensor

Entirely switching to ptoken appears somewhat restrictive to me, but =
could be argued for.  Certainly the following looks a bit strange, but =
would indeed be easy to parse.

   =
;rt=3Dhttp://tzi.org/isq/temp&unit=3Dcentikelvin;if=3Dsenso=
r,
   ;rt=3DLightLux;if=3Dhttp://tzi.org/w/lightsensor.wadl

Allowing both ptoken and quoted-string appears to be unneeded =
complexity.

Gr=FC=DFe, Carsten


From esko.dijk@philips.com  Mon Nov 28 04:34:55 2011
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 EE31021F8CA6 for ; Mon, 28 Nov 2011 04:34:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level: 
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=1.300,  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 o1glr3PIbDEt for ; Mon, 28 Nov 2011 04:34:51 -0800 (PST)
Received: from VA3EHSOBE003.bigfish.com (va3ehsobe003.messaging.microsoft.com [216.32.180.13]) by ietfa.amsl.com (Postfix) with ESMTP id C207C21F85C7 for ; Mon, 28 Nov 2011 04:34:49 -0800 (PST)
Received: from mail68-va3-R.bigfish.com (10.7.14.245) by VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id 14.1.225.22; Mon, 28 Nov 2011 12:34:02 +0000
Received: from mail68-va3 (localhost [127.0.0.1])	by mail68-va3-R.bigfish.com (Postfix) with ESMTP id 85E16100118; Thu, 24 Nov 2011 11:31:47 +0000 (UTC)
X-SpamScore: -21
X-BigFish: VPS-21(zz217bL15d6O9251Jc89bh542M98dKzz1202hzz8275dhz2dh2a8h668h839h61h)
X-Spam-TCS-SCL: 0:0
X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI
X-FB-SS: 0,
Received: from mail68-va3 (localhost.localdomain [127.0.0.1]) by mail68-va3 (MessageSwitch) id 132213427489130_26758; Thu, 24 Nov 2011 11:31:14 +0000 (UTC)
Received: from VA3EHSMHS036.bigfish.com (unknown [10.7.14.244])	by mail68-va3.bigfish.com (Postfix) with ESMTP id 04ED64C0043; Thu, 24 Nov 2011 11:31:14 +0000 (UTC)
Received: from mail.philips.com (157.55.7.222) by VA3EHSMHS036.bigfish.com (10.7.99.46) with Microsoft SMTP Server (TLS) id 14.1.225.22; Mon, 28 Nov 2011 12:33:25 +0000
Received: from 011-DB3MPN1-012.MGDPHG.emi.philips.com ([169.254.2.218]) by 011-DB3MMR1-008.MGDPHG.emi.philips.com ([10.128.28.47]) with mapi id 14.01.0355.003; Mon, 28 Nov 2011 12:34:09 +0000
From: "Dijk, Esko" 
To: Carsten Bormann 
Thread-Topic: [core] Second WGLC for draft-ietf-core-link-format-09.txt
Thread-Index: AQHMpN8raIOMnRP2+EekD7Ivap+WRpXCIIeQgAAZiACAAAJVEA==
Date: Mon, 28 Nov 2011 12:34:08 +0000
Message-ID: <031DD135F9160444ABBE3B0C36CED61801E256@011-DB3MPN1-012.MGDPHG.emi.philips.com>
References: <2F008BD6-3D3D-4772-8289-08A8AF098AAA@tzi.org> <031DD135F9160444ABBE3B0C36CED61801E1FD@011-DB3MPN1-012.MGDPHG.emi.philips.com> 
In-Reply-To: 
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: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: philips.com
Cc: core WG 
Subject: Re: [core] Second WGLC for draft-ietf-core-link-format-09.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Nov 2011 12:34:55 -0000

Thanks Carsten,

My mistake; "quoted-string" does indeed occur in all the application/link-f=
ormat examples given. I wrote this after seeing unquoted values in example =
queries (as in GET /.well-known/core?rt=3DLightLux) in which the query patt=
ern is a ptoken.

Thinking of this, I can in theory name a resource type like
        rt=3D"outdoor temperature"
but querying it would not be possible like this (ptoken does not allow spac=
e, char 0x20):
        GET /.well-known/core?rt=3Doutdoor temperature
with current web server query conventions it could be phrased as:
        GET /.well-known/core?rt=3Doutdoor+temperature

Maybe a preferred solution for such cases could be indicated in the I-D? (O=
ne pragmatic solution is stating that values with whitespace characters are=
 to be avoided. Or maybe define a quoted-ptoken type?)

regards,
Esko

-----Original Message-----
From: Carsten Bormann [mailto:cabo@tzi.org]
Sent: Monday 28 November 2011 12:36
To: Dijk, Esko
Cc: core WG; Zach Shelby
Subject: Re: [core] Second WGLC for draft-ietf-core-link-format-09.txt

Hi Esko,

these are very useful comments.

I don't understand this one, though:

On Nov 28, 2011, at 12:02, Dijk, Esko wrote:

> ** use of "quoted-string" in ABNF definitions - should be a regular strin=
g, not "quoted-string" here?
> link-extension =3D/ ( "rt=3D" quoted-string )
> link-extension =3D/ ( "if=3D" quoted-string )

>From RFC 2616 we import via RFC 5988:

   A string of text is parsed as a single word if it is quoted using
   double-quote marks.

       quoted-string  =3D ( <"> *(qdtext | quoted-pair ) <"> )
       qdtext         =3D >

   The backslash character ("\") MAY be used as a single-character
   quoting mechanism only within quoted-string and comment constructs.

       quoted-pair    =3D "\" CHAR

Is this not exactly what we want to have?
As in:

   ;rt=3D"TemperatureC";if=3D"sensor",
   ;rt=3D"LightLux";if=3D"sensor"

An alternative would be ptoken, as in:

   ;rt=3DTemperatureC;if=3Dsensor,
   ;rt=3DLightLux;if=3Dsensor

Entirely switching to ptoken appears somewhat restrictive to me, but could =
be argued for.  Certainly the following looks a bit strange, but would inde=
ed be easy to parse.

   ;rt=3Dhttp://tzi.org/isq/temp&unit=3Dcentikelvin;if=3Dsen=
sor,
   ;rt=3DLightLux;if=3Dhttp://tzi.org/w/lightsensor.wadl

Allowing both ptoken and quoted-string appears to be unneeded complexity.

Gr=FC=DFe, Carsten


________________________________
The information contained in this message may be confidential and legally p=
rotected under applicable law. The message is intended solely for the addre=
ssee(s). If you are not the intended recipient, you are hereby notified tha=
t any use, forwarding, dissemination, or reproduction of this message is st=
rictly prohibited and may be unlawful. If you are not the intended recipien=
t, please contact the sender by return e-mail and destroy all copies of the=
 original message.


From esko.dijk@philips.com  Mon Nov 28 07:59:59 2011
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 DAB8A21F8C1C for ; Mon, 28 Nov 2011 07:59:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.949
X-Spam-Level: 
X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=0.649,  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 ki9MgScEpTLh for ; Mon, 28 Nov 2011 07:59:58 -0800 (PST)
Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id 8157421F8BC5 for ; Mon, 28 Nov 2011 07:59:51 -0800 (PST)
Received: from mail128-ch1-R.bigfish.com (10.43.68.253) by CH1EHSOBE006.bigfish.com (10.43.70.56) with Microsoft SMTP Server id 14.1.225.22; Mon, 28 Nov 2011 15:59:04 +0000
Received: from mail128-ch1 (localhost [127.0.0.1])	by mail128-ch1-R.bigfish.com (Postfix) with ESMTP id D2CC3C017B	for ; Mon, 28 Nov 2011 15:59:50 +0000 (UTC)
X-SpamScore: -13
X-BigFish: VPS-13(zz217bL15d6O9251Jc85fhzz1202hzz8275bhz2dh2a8h668h839h)
X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI
Received: from mail128-ch1 (localhost.localdomain [127.0.0.1]) by mail128-ch1 (MessageSwitch) id 1322495988685214_3418; Mon, 28 Nov 2011 15:59:48 +0000 (UTC)
Received: from CH1EHSMHS008.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.246])	by mail128-ch1.bigfish.com (Postfix) with ESMTP id 98A005A0047	for ; Mon, 28 Nov 2011 15:59:48 +0000 (UTC)
Received: from mail.philips.com (157.55.7.222) by CH1EHSMHS008.bigfish.com (10.43.70.8) with Microsoft SMTP Server (TLS) id 14.1.225.22; Mon, 28 Nov 2011 15:58:59 +0000
Received: from 011-DB3MPN1-012.MGDPHG.emi.philips.com ([169.254.2.218]) by 011-DB3MMR1-008.MGDPHG.emi.philips.com ([10.128.28.47]) with mapi id 14.01.0355.003; Mon, 28 Nov 2011 15:59:44 +0000
From: "Dijk, Esko" 
To: "core@ietf.org" 
Thread-Topic: Clarification of coap-08 multicast security requirements
Thread-Index: Acyt5r3U+HC0kyPrSr6e6lkqM/bsng==
Date: Mon, 28 Nov 2011 15:59:43 +0000
Message-ID: <031DD135F9160444ABBE3B0C36CED61801E4B5@011-DB3MPN1-012.MGDPHG.emi.philips.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [194.171.252.101]
Content-Type: multipart/alternative; boundary="_000_031DD135F9160444ABBE3B0C36CED61801E4B5011DB3MPN1012MGDP_"
MIME-Version: 1.0
X-OriginatorOrg: philips.com
Subject: [core] Clarification of coap-08 multicast security requirements
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, 28 Nov 2011 16:00:00 -0000

--_000_031DD135F9160444ABBE3B0C36CED61801E4B5011DB3MPN1012MGDP_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dear all,

There's a possible issue I see with the definition of CoAP multicast securi=
ty - the current core-coap-08 states:
  "To limit the possibility of malicious use, CoAP servers SHOULD NOT accep=
t
    multicast requests that can not be authenticated."

The "SHOULD NOT" seems too strong here. I would expect that in deployments =
using NoSec mode, authentication would typically not be available.
For example, if I configure my network using NoSec in CoAP clients/servers,=
 without object security, without IPSec, that seems to be allowed for unica=
st CoAP messages.  But not for multicast then? There is some specific text =
to cover this case:
  "The system is secured only by keeping attackers from
  being able to send or receive packets from the network with the CoAP node=
s"

I would assume this also applies then to multicast CoAP messages. Of course=
 the section 10 remark "Alternative techniques to provide lower layer secur=
ity SHOULD be used when appropriate." still holds. This could be realized b=
y IPSec but also link-layer encryption methods that may not provide authent=
ication, or even nothing - if that is appropriate for the use case.

best regards,

Esko Dijk

Philips Corporate Technologies, Research
High Tech Campus 34, Eindhoven, The Netherlands
esko.dijk@philips.com


________________________________
The information contained in this message may be confidential and legally p=
rotected under applicable law. The message is intended solely for the addre=
ssee(s). If you are not the intended recipient, you are hereby notified tha=
t any use, forwarding, dissemination, or reproduction of this message is st=
rictly prohibited and may be unlawful. If you are not the intended recipien=
t, please contact the sender by return e-mail and destroy all copies of the=
 original message.

--_000_031DD135F9160444ABBE3B0C36CED61801E4B5011DB3MPN1012MGDP_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable










Dear all,


 


There’s a possible issue I see with the defini=
tion of CoAP multicast security - the current core-coap-08 states:


  “To limit the possibility of malic=
ious use, CoAP servers SHOULD NOT accept



    multicast requests that can =
not be authenticated.”


 


The “SHOULD NOT” seems too strong here. =
I would expect that in deployments using NoSec mode, authentication would t=
ypically not be available.


For example, if I configure my network using NoSec i=
n CoAP clients/servers, without object security, without IPSec, that seems =
to be allowed for unicast CoAP messages.  But not for multicast then? =
There is some specific text to cover this
 case:


  “The system is secured only by keeping =
attackers from


  being able to send or receive packets from th=
e network with the CoAP nodes”


 


I would assume this also applies then to multicast C=
oAP messages. Of course the section 10 remark “Alternative techniques=
 to provide lower layer security SHOULD be used when appropriate.” st=
ill holds. This could be realized by IPSec but
 also link-layer encryption methods that may not provide authentication, or=
 even nothing - if that is appropriate for the use case.


 


best regards,


 


Esko Dijk


 


Philips Corporate Technologies, Research


High Tech Campus 34, Eindhoven, The Netherlands


esko.dijk@philips.com


 







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

From kerlyn2001@gmail.com  Mon Nov 28 10:01:06 2011
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 2DBF021F8B16 for ; Mon, 28 Nov 2011 10:01:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C12QDHnl7gvK for ; Mon, 28 Nov 2011 10:01:05 -0800 (PST)
Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1941321F8B05 for ; Mon, 28 Nov 2011 10:01:04 -0800 (PST)
Received: by eear51 with SMTP id r51so711186eea.31 for ; Mon, 28 Nov 2011 10:01:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fFV5U5YUPKgC8kICPUyWIOSZaXYOiVA7ptRsX9O0gWU=; b=Vk1heILw81jS3Bc5IsXyGZFfmGC4LF03Yh+6PNs4LWrmFo7QgGMl7jUahRpoCitQlr 5KS2v+VtsX7LKygZ3kD4cxx3HbNjfsczM1Bud+GhD/GzvrI4+m3e59vqKx8glrUyrvMG WvHVFKfaCGeVfoZTaJ/A3EdczbesjhRD9yq28=
MIME-Version: 1.0
Received: by 10.14.9.219 with SMTP id 67mr2628546eet.24.1322503264134; Mon, 28 Nov 2011 10:01:04 -0800 (PST)
Received: by 10.14.7.80 with HTTP; Mon, 28 Nov 2011 10:01:03 -0800 (PST)
In-Reply-To: <031DD135F9160444ABBE3B0C36CED61801E4B5@011-DB3MPN1-012.MGDPHG.emi.philips.com>
References: <031DD135F9160444ABBE3B0C36CED61801E4B5@011-DB3MPN1-012.MGDPHG.emi.philips.com>
Date: Mon, 28 Nov 2011 13:01:03 -0500
Message-ID: 
From: Kerry Lynn 
To: "Dijk, Esko" 
Content-Type: multipart/alternative; boundary=0016367d716845e56c04b2cf49d2
Cc: "core@ietf.org" 
Subject: Re: [core] Clarification of coap-08 multicast security requirements
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, 28 Nov 2011 18:01:06 -0000

--0016367d716845e56c04b2cf49d2
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Mon, Nov 28, 2011 at 10:59 AM, Dijk, Esko  wrote:

>  Dear all,
>
>
>
> There=92s a possible issue I see with the definition of CoAP multicast
> security - the current core-coap-08 states:
>
>   =93To limit the possibility of malicious use, CoAP servers SHOULD NOT
> accept
>
>     multicast requests that can not be authenticated.=94
>
>
>
> The =93SHOULD NOT=94 seems too strong here. I would expect that in deploy=
ments
> using NoSec mode, authentication would typically not be available.
>

Is your suggestion to change SHOULD NOT to MAY NOT?  That seems the only
option.
My own personal opinion is that the choice of security protocol will
ultimately be dictated
by the application (e.g. lighting control) and not by the application
protocol (e.g. CoAP).
One thing I'd be wary of is any language that requires devices to operate
at some
least common security level, but this change wouldn't do that.  IOW, if my
*application*
requires authenticated multicast requests, my devices will certainly reject
any requests
that aren't authenticated.

-K-


> For example, if I configure my network using NoSec in CoAP
> clients/servers, without object security, without IPSec, that seems to be
> allowed for unicast CoAP messages.  But not for multicast then? There is
> some specific text to cover this case:
>
>   =93The system is secured only by keeping attackers from
>
>   being able to send or receive packets from the network with the CoAP
> nodes=94
>
>
>
> I would assume this also applies then to multicast CoAP messages. Of
> course the section 10 remark =93Alternative techniques to provide lower l=
ayer
> security SHOULD be used when appropriate.=94 still holds. This could be
> realized by IPSec but also link-layer encryption methods that may not
> provide authentication, or even nothing - if that is appropriate for the
> use case.
>
>
>
> best regards,
>
>
>
> Esko Dijk
>
>
>
> Philips Corporate Technologies, Research
>
> High Tech Campus 34, Eindhoven, The Netherlands
>
> esko.dijk@philips.com
>
>
>
> ------------------------------
> The information contained in this message may be confidential and legally
> protected under applicable law. The message is intended solely for the
> addressee(s). If you are not the intended recipient, you are hereby
> notified that any use, forwarding, dissemination, or reproduction of this
> message is strictly prohibited and may be unlawful. If you are not the
> intended recipient, please contact the sender by return e-mail and destro=
y
> all copies of the original message.
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>
>

--0016367d716845e56c04b2cf49d2
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Mon, Nov 28, 2011 at 10:59 AM, Dijk, Esko <esko.dijk@philips.com> wrot=
e:











Dear all,


=A0


There=92s a possible issue I see with the definition=
 of CoAP multicast security - the current core-coap-08 states:


=A0=A0=93To limit the possibility of malicious use, =
CoAP servers SHOULD NOT accept



=A0=A0=A0=A0multicast requests that can not be authe=
nticated.=94


=A0


The =93SHOULD NOT=94 seems too strong here. I would =
expect that in deployments using NoSec mode, authentication would typically=
 not be available.

Is your =
suggestion to change SHOULD NOT to MAY NOT? =A0That seems the only option.<=
/div>

My own personal opinion is that the choice of security protocol will u=
ltimately be dictated
by the application (e.g. lighting control) =
and not by the application protocol (e.g. CoAP).
One=A0thing I=
9;d be wary of is any language that requires devices to operate at some

least common security level, but this change wouldn't do that. =A0=
IOW, if my *application*
requires authenticated multicast request=
s, my devices will certainly reject any requests
that aren't=
=A0authenticated.



-K-
=A0
=



For example, if I configure my network using NoSec i=
n CoAP clients/servers, without object security, without IPSec, that seems =
to be allowed for unicast CoAP messages. =A0But not for multicast then? The=
re is some specific text to cover this
 case:


=A0 =93The system is secured only by keeping attacke=
rs from


=A0 being able to send or receive packets from the n=
etwork with the CoAP nodes=94


=A0


I would assume this also applies then to multicast C=
oAP messages. Of course the section 10 remark =93Alternative techniques to =
provide lower layer security SHOULD be used when appropriate.=94 still hold=
s. This could be realized by IPSec but
 also link-layer encryption methods that may not provide authentication, or=
 even nothing - if that is appropriate for the use case.


=A0


best regards,


=A0


Esko Dijk


=A0


Philips Corporate Technologies, Research


High Tech Campus 34, Eindhoven, The Netherlands


esko.dijk@phil=
ips.com


=A0







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.







_______________________________________________

core mailing list

core@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/core





--0016367d716845e56c04b2cf49d2--

From tho@koanlogic.com  Mon Nov 28 12:24:00 2011
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 5F86A11E80AA for ; Mon, 28 Nov 2011 12:24:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.505
X-Spam-Level: *
X-Spam-Status: No, score=1.505 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553,  IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, SARE_RECV_IP_069060096=1.666]
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 fjPcrUJQnLWJ for ; Mon, 28 Nov 2011 12:24:00 -0800 (PST)
Received: from gonzo.koanlogic.com (unknown [69.60.118.166]) by ietfa.amsl.com (Postfix) with ESMTP id 085B221F8569 for ; Mon, 28 Nov 2011 12:23:59 -0800 (PST)
Received: from host12-55-dynamic.35-79-r.retail.telecomitalia.it ([79.35.55.12]:63974 helo=t.home) by gonzo.koanlogic.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1RV7jw-0007ux-Q7; Mon, 28 Nov 2011 15:23:55 -0500
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Thomas Fossati 
In-Reply-To: 
Date: Mon, 28 Nov 2011 21:23:14 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <2D66A4A2-17A1-4F47-9465-4901C0172F2E@koanlogic.com>
References: <031DD135F9160444ABBE3B0C36CED61801E4B5@011-DB3MPN1-012.MGDPHG.emi.philips.com> 
To: Kerry Lynn 
X-Mailer: Apple Mail (2.1084)
X-SA-Exim-Connect-IP: 79.35.55.12
X-SA-Exim-Mail-From: tho@koanlogic.com
X-Spam-DCC: : 
X-Spam-Pyzor: Reported 0 times.
X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100)
X-SA-Exim-Scanned: Yes (on gonzo.koanlogic.com)
Cc: "core@ietf.org" 
Subject: Re: [core] Clarification of coap-08 multicast security requirements
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, 28 Nov 2011 20:24:00 -0000

I fully agree with the point raised by Esko: there exist many use cases =
where a network can be assumed trusted by its end-points, with no crypto =
involved.  And this is valid independently of the communication =
protocol.

Further, if we allow unicast with NoSec, I don't see any stringent =
motivation to disallow the same security model with multicast.

So, +1 on substituting SHOULD NOT with MAY NOT, which would make it an =
application option, if I read RFC 2119 correctly.
It'd be also ok to remove the sentence altogether to avoid any doubt to =
CoAP implementers.=

From likepeng@huawei.com  Mon Nov 28 16:56:12 2011
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 A83271F0C46 for ; Mon, 28 Nov 2011 16:56:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xWEzAG3EuHHy for ; Mon, 28 Nov 2011 16:56:12 -0800 (PST)
Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id BE0821F0C36 for ; Mon, 28 Nov 2011 16:56:11 -0800 (PST)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LVE00E2ED9KF9@szxga03-in.huawei.com> for core@ietf.org; Tue, 29 Nov 2011 08:56:08 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LVE00E07D9J1U@szxga03-in.huawei.com> for core@ietf.org; Tue, 29 Nov 2011 08:56:07 +0800 (CST)
Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AFJ66096; Tue, 29 Nov 2011 08:56:00 +0800
Received: from SZXEML423-HUB.china.huawei.com (10.82.67.162) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 29 Nov 2011 08:55:58 +0800
Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.177]) by szxeml423-hub.china.huawei.com ([10.82.67.162]) with mapi id 14.01.0323.003; Tue, 29 Nov 2011 08:55:55 +0800
Date: Tue, 29 Nov 2011 00:55:55 +0000
From: Likepeng 
In-reply-to: <031DD135F9160444ABBE3B0C36CED61801E1FD@011-DB3MPN1-012.MGDPHG.emi.philips.com>
X-Originating-IP: [10.70.109.81]
To: Carsten Bormann , core WG , Zach Shelby 
Message-id: <34966E97BE8AD64EAE9D3D6E4DEE36F2D16067@szxeml525-mbs.china.huawei.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-language: zh-CN
Content-transfer-encoding: 7BIT
Accept-Language: zh-CN, en-US
Thread-topic: [core] Second WGLC for draft-ietf-core-link-format-09.txt
Thread-index: AQHMpN8sTTGIsVVv9UezbRHA3ZpeH5XBqpyAgAFsvKA=
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References: <2F008BD6-3D3D-4772-8289-08A8AF098AAA@tzi.org> <031DD135F9160444ABBE3B0C36CED61801E1FD@011-DB3MPN1-012.MGDPHG.emi.philips.com>
Subject: Re: [core] Second WGLC for draft-ietf-core-link-format-09.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Nov 2011 00:56:12 -0000

Hi Zach, Carsten and all,

It seems that my comments come late. Now it is after the WGLC deadline. Maybe it can be something for your future consideration.

Is it possible that we use defined binary code to replace the defined attributes. For example, use 0000 to represent "rt", 0001 represents "if", 0010 represents "ct", 0011 represents "sz", etc. We can adopt similar approach as we design options in CoAP spec.

In this way, we can avoid to use text/plain in the message payload. It will be easier for the requester to parse the link-format payload, and this can also save some bytes.

Any thoughts on this?

Thanks,
Kind Regards
Kepeng
-----Original Message-----
From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Carsten Bormann
Sent: Thursday 17 November 2011 5:13
To: core WG
Subject: [core] Second WGLC for draft-ietf-core-link-format-09.txt

On January 16 this year, core-link-format-02 finished working group last call.
On March 15, the -03 draft incorporated the changes from the comments received on this WGLC.

Since that update, the draft has experienced some Brownian motion.
Changes were made e.g. to adapt the examples to some coap-core changes, to clarify the use of UTF-8, to address AD comments, and to properly distribute the normative content between the different CoRE specs.
With -09, we now have a version that passes all ID-Nits.
While I personally think it could be justified to send this on to the IESG as is, I also think that might be considered bad form.

So I'm announcing today a

   second working-group last call
   for draft-ietf-core-link-format-09.txt

This is a one-week WGLC, but time does not pass during an IETF.
So please send in any comments to the CoRE list now, or latest until

   2011-11-28, 1200 UTC.

A short note of the form "I've re-read -09 and it's OK" would also be very welcome.

Gruesse, Carsten

PS.: You can use
http://tools.ietf.org/rfcdiff?url2=draft-ietf-core-link-format-09&url1=draft-ietf-core-link-format-03
to review the changes since -03.

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


From esko.dijk@philips.com  Tue Nov 29 01:14:25 2011
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 F3FAB21F8B86 for ; Tue, 29 Nov 2011 01:14:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.165
X-Spam-Level: 
X-Spam-Status: No, score=-3.165 tagged_above=-999 required=5 tests=[AWL=0.434,  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 MHSS+TtX6sar for ; Tue, 29 Nov 2011 01:14:24 -0800 (PST)
Received: from DB3EHSOBE002.bigfish.com (db3ehsobe002.messaging.microsoft.com [213.199.154.140]) by ietfa.amsl.com (Postfix) with ESMTP id 17B1D21F8B84 for ; Tue, 29 Nov 2011 01:14:24 -0800 (PST)
Received: from mail14-db3-R.bigfish.com (10.3.81.249) by DB3EHSOBE002.bigfish.com (10.3.84.22) with Microsoft SMTP Server id 14.1.225.22; Tue, 29 Nov 2011 09:13:35 +0000
Received: from mail14-db3 (localhost [127.0.0.1])	by mail14-db3-R.bigfish.com (Postfix) with ESMTP id 590304C021C; Tue, 29 Nov 2011 09:13:32 +0000 (UTC)
X-SpamScore: -38
X-BigFish: VPS-38(zz217bL15d6O9251J542Mzz1202hzz1033IL8275dhz2dh2a8h668h839h944h)
X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI
X-FB-SS: 13,
Received: from mail14-db3 (localhost.localdomain [127.0.0.1]) by mail14-db3 (MessageSwitch) id 1322558012233936_17793; Tue, 29 Nov 2011 09:13:32 +0000 (UTC)
Received: from DB3EHSMHS010.bigfish.com (unknown [10.3.81.245])	by mail14-db3.bigfish.com (Postfix) with ESMTP id 2882680019; Tue, 29 Nov 2011 09:13:32 +0000 (UTC)
Received: from mail.philips.com (157.55.7.222) by DB3EHSMHS010.bigfish.com (10.3.87.110) with Microsoft SMTP Server (TLS) id 14.1.225.22; Tue, 29 Nov 2011 09:13:34 +0000
Received: from 011-DB3MPN1-012.MGDPHG.emi.philips.com ([169.254.2.218]) by 011-DB3MMR1-005.MGDPHG.emi.philips.com ([10.128.28.55]) with mapi id 14.01.0355.003; Tue, 29 Nov 2011 09:14:21 +0000
From: "Dijk, Esko" 
To: Thomas Fossati , Kerry Lynn 
Thread-Topic: [core] Clarification of coap-08 multicast security requirements
Thread-Index: Acyt5r3U+HC0kyPrSr6e6lkqM/bsngAEPN6AAAT3NwAAGVVfsA==
Date: Tue, 29 Nov 2011 09:14:21 +0000
Message-ID: <031DD135F9160444ABBE3B0C36CED61801E626@011-DB3MPN1-012.MGDPHG.emi.philips.com>
References: <031DD135F9160444ABBE3B0C36CED61801E4B5@011-DB3MPN1-012.MGDPHG.emi.philips.com>  <2D66A4A2-17A1-4F47-9465-4901C0172F2E@koanlogic.com>
In-Reply-To: <2D66A4A2-17A1-4F47-9465-4901C0172F2E@koanlogic.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [194.171.252.101]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: philips.com
Cc: "core@ietf.org" 
Subject: Re: [core] Clarification of coap-08 multicast security requirements
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, 29 Nov 2011 09:14:25 -0000

Thomas, Kerry,

Suggested text would be:

"In NoSec security mode, a CoAP server MAY refuse to accept multicast reque=
sts that can not be authenticated in order to limit the possibilities of ma=
licious use of multicast requests. In all other security modes, a CoAP serv=
er SHOULD NOT accept multicast requests that can not be authenticated in or=
der to limit the possibilities of malicious use of multicast requests."

(Note in the above text it is implicitly stated that the optional authentic=
ation in the NoSec mode would have to be done below or above the transport =
layer.) Using "MAY NOT" would be a bit confusing and seems not defined in R=
FC2119.

regards,
Esko

-----Original Message-----
From: Thomas Fossati [mailto:tho@koanlogic.com]
Sent: Monday 28 November 2011 21:23
To: Kerry Lynn
Cc: Dijk, Esko; core@ietf.org
Subject: Re: [core] Clarification of coap-08 multicast security requirement=
s

I fully agree with the point raised by Esko: there exist many use cases whe=
re a network can be assumed trusted by its end-points, with no crypto invol=
ved.  And this is valid independently of the communication protocol.

Further, if we allow unicast with NoSec, I don't see any stringent motivati=
on to disallow the same security model with multicast.

So, +1 on substituting SHOULD NOT with MAY NOT, which would make it an appl=
ication option, if I read RFC 2119 correctly.
It'd be also ok to remove the sentence altogether to avoid any doubt to CoA=
P implementers.

________________________________
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 tho@koanlogic.com  Tue Nov 29 06:12:26 2011
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 0426821F8BE7 for ; Tue, 29 Nov 2011 06:12:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.505
X-Spam-Level: *
X-Spam-Status: No, score=1.505 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553,  IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, SARE_RECV_IP_069060096=1.666]
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 b3O3nOzkTsci for ; Tue, 29 Nov 2011 06:12:25 -0800 (PST)
Received: from gonzo.koanlogic.com (unknown [69.60.118.166]) by ietfa.amsl.com (Postfix) with ESMTP id 2CEE221F8BE5 for ; Tue, 29 Nov 2011 06:12:24 -0800 (PST)
Received: from host12-55-dynamic.35-79-r.retail.telecomitalia.it ([79.35.55.12]:51108 helo=t.home) by gonzo.koanlogic.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1RVOPs-0000xm-Pc for core@ietf.org; Tue, 29 Nov 2011 09:12:22 -0500
From: Thomas Fossati 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Tue, 29 Nov 2011 15:11:38 +0100
Message-Id: <4224466B-89A8-4A20-9D57-A5C29772E2A8@koanlogic.com>
To: "core@ietf.org WG" 
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
X-SA-Exim-Connect-IP: 79.35.55.12
X-SA-Exim-Mail-From: tho@koanlogic.com
X-Spam-DCC: : 
X-Spam-Pyzor: Reported 0 times.
X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100)
X-SA-Exim-Scanned: Yes (on gonzo.koanlogic.com)
Subject: [core] Uri-Port option really needed ?
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Nov 2011 14:12:26 -0000

I was wondering if the Uri-Port option is really needed, since it can =
always be inferred by the context. =20

In fact, how could it be different from the port on which the server =
received the request PDU ?=

From tho@koanlogic.com  Tue Nov 29 06:12:41 2011
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 1B33221F8491 for ; Tue, 29 Nov 2011 06:12:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.505
X-Spam-Level: *
X-Spam-Status: No, score=1.505 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553,  IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, SARE_RECV_IP_069060096=1.666]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6+FcAdqTvMlk for ; Tue, 29 Nov 2011 06:12:40 -0800 (PST)
Received: from gonzo.koanlogic.com (unknown [69.60.118.166]) by ietfa.amsl.com (Postfix) with ESMTP id A5F2921F84B1 for ; Tue, 29 Nov 2011 06:12:40 -0800 (PST)
Received: from host12-55-dynamic.35-79-r.retail.telecomitalia.it ([79.35.55.12]:51108 helo=t.home) by gonzo.koanlogic.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1RVOQ3-0000xm-Cp; Tue, 29 Nov 2011 09:12:38 -0500
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Thomas Fossati 
In-Reply-To: <031DD135F9160444ABBE3B0C36CED61801E626@011-DB3MPN1-012.MGDPHG.emi.philips.com>
Date: Tue, 29 Nov 2011 15:11:54 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <031DD135F9160444ABBE3B0C36CED61801E4B5@011-DB3MPN1-012.MGDPHG.emi.philips.com>  <2D66A4A2-17A1-4F47-9465-4901C0172F2E@koanlogic.com> <031DD135F9160444ABBE3B0C36CED61801E626@011-DB3MPN1-012.MGDPHG.emi.philips.com>
To: "Dijk, Esko" 
X-Mailer: Apple Mail (2.1084)
X-SA-Exim-Connect-IP: 79.35.55.12
X-SA-Exim-Mail-From: tho@koanlogic.com
X-Spam-DCC: : 
X-Spam-Pyzor: Reported 0 times.
X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100)
X-SA-Exim-Scanned: Yes (on gonzo.koanlogic.com)
Cc: "core@ietf.org" 
Subject: Re: [core] Clarification of coap-08 multicast security requirements
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, 29 Nov 2011 14:12:41 -0000

Hi Esko,

On Nov 29, 2011, at 10:14 AM, Dijk, Esko wrote:
> Suggested text would be:
>=20
> "In NoSec security mode, a CoAP server MAY refuse to accept multicast =
requests that can not be authenticated in order to limit the =
possibilities of malicious use of multicast requests. In all other =
security modes, a CoAP server SHOULD NOT accept multicast requests that =
can not be authenticated in order to limit the possibilities of =
malicious use of multicast requests."

sounds good to me.  It acknowledges the risk of unauthenticated =
messaging over multicast (but again, unicast too is vulnerable...), and =
at the same time it does not prevent an application to define its own =
security model.  There is still some residual risk for interoperability =
issues in case an implementer chooses to hardcode the MAY, but that =
would be an implementation error :-)

> (Note in the above text it is implicitly stated that the optional =
authentication in the NoSec mode would have to be done below or above =
the transport layer.)

Perhaps it would be nice to state explicitly which mechanisms may be =
used, though.

> Using "MAY NOT" would be a bit confusing and seems not defined in =
RFC2119.

You are right.=

From esko.dijk@philips.com  Tue Nov 29 06:42:07 2011
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 CDA0921F8B77 for ; Tue, 29 Nov 2011 06:42:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.274
X-Spam-Level: 
X-Spam-Status: No, score=-3.274 tagged_above=-999 required=5 tests=[AWL=0.325,  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 L9KMF-amlPJI for ; Tue, 29 Nov 2011 06:42:07 -0800 (PST)
Received: from AM1EHSOBE006.bigfish.com (am1ehsobe006.messaging.microsoft.com [213.199.154.209]) by ietfa.amsl.com (Postfix) with ESMTP id D2E9A21F8B23 for ; Tue, 29 Nov 2011 06:42:06 -0800 (PST)
Received: from mail82-am1-R.bigfish.com (10.3.201.252) by AM1EHSOBE006.bigfish.com (10.3.204.26) with Microsoft SMTP Server id 14.1.225.22; Tue, 29 Nov 2011 14:41:18 +0000
Received: from mail82-am1 (localhost [127.0.0.1])	by mail82-am1-R.bigfish.com (Postfix) with ESMTP id 2F14964021C; Tue, 29 Nov 2011 14:41:25 +0000 (UTC)
X-SpamScore: -38
X-BigFish: VPS-38(zz217bL15d6O9251J542Mzz1202hzz1033IL8275dhz2dh2a8h668h839h944h)
X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI
Received: from mail82-am1 (localhost.localdomain [127.0.0.1]) by mail82-am1 (MessageSwitch) id 132257768594363_16384; Tue, 29 Nov 2011 14:41:25 +0000 (UTC)
Received: from AM1EHSMHS014.bigfish.com (unknown [10.3.201.242])	by mail82-am1.bigfish.com (Postfix) with ESMTP id 0F286680043; Tue, 29 Nov 2011 14:41:25 +0000 (UTC)
Received: from mail.philips.com (157.55.7.222) by AM1EHSMHS014.bigfish.com (10.3.207.152) with Microsoft SMTP Server (TLS) id 14.1.225.22; Tue, 29 Nov 2011 14:41:15 +0000
Received: from 011-DB3MPN1-012.MGDPHG.emi.philips.com ([169.254.2.218]) by 011-DB3MMR1-007.MGDPHG.emi.philips.com ([10.128.28.57]) with mapi id 14.01.0355.003; Tue, 29 Nov 2011 14:42:02 +0000
From: "Dijk, Esko" 
To: Thomas Fossati 
Thread-Topic: [core] Uri-Port option really needed ?
Thread-Index: AQHMrqDwQI0W106/Vke+SVGjNQlc6ZXD6XKg
Date: Tue, 29 Nov 2011 14:42:02 +0000
Message-ID: <031DD135F9160444ABBE3B0C36CED61801E7B0@011-DB3MPN1-012.MGDPHG.emi.philips.com>
References: <4224466B-89A8-4A20-9D57-A5C29772E2A8@koanlogic.com>
In-Reply-To: <4224466B-89A8-4A20-9D57-A5C29772E2A8@koanlogic.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [194.171.252.101]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: philips.com
Cc: "core@ietf.org WG" 
Subject: Re: [core] Uri-Port option really needed ?
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Nov 2011 14:42:07 -0000

Hi,

The Uri-Port number can be different from the UDP port, in which case the U=
ri-Port option overrides the UDP port value in the CoAP server.

Speculating on the possible uses of this feature:
 - protect the port number against modification attacks if DTLS security is=
 used (while consuming the same nr of bytes in a 6LoWPAN packet)
 - re-use one and the same security context (which is bound to one UDP port=
, e.g. for coaps scheme) in accessing multiple ports on a CoAP server (in t=
his case the CoAP server port that will in the end be used is the one encod=
ed in the Uri-Port option)

Esko

-----Original Message-----
From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Tho=
mas Fossati
Sent: Tuesday 29 November 2011 15:12
To: core@ietf.org WG
Subject: [core] Uri-Port option really needed ?

I was wondering if the Uri-Port option is really needed, since it can alway=
s be inferred by the context.

In fact, how could it be different from the port on which the server receiv=
ed the request PDU ?
_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core

________________________________
The information contained in this message may be confidential and legally p=
rotected under applicable law. The message is intended solely for the addre=
ssee(s). If you are not the intended recipient, you are hereby notified tha=
t any use, forwarding, dissemination, or reproduction of this message is st=
rictly prohibited and may be unlawful. If you are not the intended recipien=
t, please contact the sender by return e-mail and destroy all copies of the=
 original message.


From tho@koanlogic.com  Tue Nov 29 08:49:00 2011
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 62B3721F8B80 for ; Tue, 29 Nov 2011 08:49:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.505
X-Spam-Level: *
X-Spam-Status: No, score=1.505 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553,  IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, SARE_RECV_IP_069060096=1.666]
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 6MdmbCa5ig5u for ; Tue, 29 Nov 2011 08:49:00 -0800 (PST)
Received: from gonzo.koanlogic.com (unknown [69.60.118.166]) by ietfa.amsl.com (Postfix) with ESMTP id DEFE321F8B79 for ; Tue, 29 Nov 2011 08:48:59 -0800 (PST)
Received: from host12-55-dynamic.35-79-r.retail.telecomitalia.it ([79.35.55.12]:51548 helo=t.home) by gonzo.koanlogic.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1RVQrR-0001Ej-Q6; Tue, 29 Nov 2011 11:48:57 -0500
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Thomas Fossati 
In-Reply-To: <031DD135F9160444ABBE3B0C36CED61801E7B0@011-DB3MPN1-012.MGDPHG.emi.philips.com>
Date: Tue, 29 Nov 2011 17:48:15 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <423A9692-1B3B-4919-B93A-E3ED5D0956D4@koanlogic.com>
References: <4224466B-89A8-4A20-9D57-A5C29772E2A8@koanlogic.com> <031DD135F9160444ABBE3B0C36CED61801E7B0@011-DB3MPN1-012.MGDPHG.emi.philips.com>
To: "Dijk, Esko" 
X-Mailer: Apple Mail (2.1084)
X-SA-Exim-Connect-IP: 79.35.55.12
X-SA-Exim-Mail-From: tho@koanlogic.com
X-Spam-DCC: : 
X-Spam-Pyzor: Reported 0 times.
X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100)
X-SA-Exim-Scanned: Yes (on gonzo.koanlogic.com)
Cc: "core@ietf.org WG" 
Subject: Re: [core] Uri-Port option really needed ?
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Nov 2011 16:49:00 -0000

Hi Esko, thanks for the answer.

While searching more carefully into the spec for "Uri-Port" I could find =
a couple of references to "virtual hosting", which seems to be the base =
rationale for having a possibly different port value.  It seems that the =
port is retained for full analogy with the Host header in HTTP.=

From tianlinyi@huawei.com  Wed Nov 30 21:45:10 2011
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 7558111E80A1 for ; Wed, 30 Nov 2011 21:45:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2f34bED+lWSY for ; Wed, 30 Nov 2011 21:45:09 -0800 (PST)
Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 4047111E8080 for ; Wed, 30 Nov 2011 21:45:09 -0800 (PST)
Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LVI0051CFSFFR@szxga05-in.huawei.com> for core@ietf.org; Thu, 01 Dec 2011 13:41:03 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LVI002GLFS9W0@szxga05-in.huawei.com> for core@ietf.org; Thu, 01 Dec 2011 13:41:03 +0800 (CST)
Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AFJ16910; Thu, 01 Dec 2011 13:41:02 +0800
Received: from SZXEML420-HUB.china.huawei.com (10.82.67.159) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 01 Dec 2011 13:40:56 +0800
Received: from SZXEML513-MBX.china.huawei.com ([169.254.8.59]) by szxeml420-hub.china.huawei.com ([10.82.67.159]) with mapi id 14.01.0323.003; Thu, 01 Dec 2011 13:40:55 +0800
Date: Thu, 01 Dec 2011 05:40:53 +0000
From: TianLinyi 
In-reply-to: <2D66A4A2-17A1-4F47-9465-4901C0172F2E@koanlogic.com>
X-Originating-IP: [10.70.109.57]
To: Thomas Fossati , Kerry Lynn 
Message-id: <3615F3CCD55F054395A882F51C6E5FDA1820A06E@szxeml513-mbx.china.huawei.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-language: zh-CN
Content-transfer-encoding: 7BIT
Accept-Language: zh-CN, en-US
Thread-topic: [core] Clarification of coap-08 multicast security requirements
Thread-index: Acyt5r3U+HC0kyPrSr6e6lkqM/bsnv//m8qAgAAnugD//vzq0A==
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References: <031DD135F9160444ABBE3B0C36CED61801E4B5@011-DB3MPN1-012.MGDPHG.emi.philips.com>  <2D66A4A2-17A1-4F47-9465-4901C0172F2E@koanlogic.com>
Cc: "core@ietf.org" 
Subject: Re: [core] Clarification of coap-08 multicast security requirements
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, 01 Dec 2011 05:45:10 -0000

Hi, Thomas and All

I am wondering whether we should change SHOULD NOT to MAY NOT. In most cases the authentication should be one either in transport layer or in application protocol layer. SHOULD NOT mean it can be avoided until there is a reason to do that. The case mentioned here is the case where authentication is not needed but not always. Therefore SHOULD NOT still make sense.

Cheers,
Linyi

-----Original Message-----
From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Thomas Fossati
Sent: Tuesday, November 29, 2011 4:23 AM
To: Kerry Lynn
Cc: core@ietf.org
Subject: Re: [core] Clarification of coap-08 multicast security requirements

I fully agree with the point raised by Esko: there exist many use cases where a network can be assumed trusted by its end-points, with no crypto involved.  And this is valid independently of the communication protocol.

Further, if we allow unicast with NoSec, I don't see any stringent motivation to disallow the same security model with multicast.

So, +1 on substituting SHOULD NOT with MAY NOT, which would make it an application option, if I read RFC 2119 correctly.
It'd be also ok to remove the sentence altogether to avoid any doubt to CoAP implementers.
_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core