From esko.dijk@philips.com Mon Oct 1 01:42:22 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB8821F84AF for ; Mon, 1 Oct 2012 01:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OYUqo5fuufPj for ; Mon, 1 Oct 2012 01:42:21 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (mail-tx2.bigfish.com [65.55.88.10]) by ietfa.amsl.com (Postfix) with ESMTP id 96A1221F8555 for ; Mon, 1 Oct 2012 01:42:20 -0700 (PDT) Received: from mail33-tx2-R.bigfish.com (10.9.14.253) by TX2EHSOBE001.bigfish.com (10.9.40.21) with Microsoft SMTP Server id 14.1.225.23; Mon, 1 Oct 2012 08:42:20 +0000 Received: from mail33-tx2 (localhost [127.0.0.1]) by mail33-tx2-R.bigfish.com (Postfix) with ESMTP id 291984A013B; Mon, 1 Oct 2012 08:42:20 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -38 X-BigFish: VPS-38(zz217bL15d6O9251Jd6eah542Mzz1202h1d1ah1d2ahzz1033IL8275dhz2dh2a8h668h839h944hd25hf0ah107ah1220h1288h12a5h12a9h12bdh137ah13b6h1155h) Received: from mail33-tx2 (localhost.localdomain [127.0.0.1]) by mail33-tx2 (MessageSwitch) id 1349080938181065_16906; Mon, 1 Oct 2012 08:42:18 +0000 (UTC) Received: from TX2EHSMHS034.bigfish.com (unknown [10.9.14.246]) by mail33-tx2.bigfish.com (Postfix) with ESMTP id 1AC262E01FE; Mon, 1 Oct 2012 08:42:18 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by TX2EHSMHS034.bigfish.com (10.9.99.134) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 1 Oct 2012 08:42:16 +0000 Received: from 011-DB3MPN2-083.MGDPHG.emi.philips.com ([169.254.3.124]) by 011-DB3MMR1-005.MGDPHG.emi.philips.com ([10.128.28.55]) with mapi id 14.02.0309.003; Mon, 1 Oct 2012 09:41:25 +0100 From: "Dijk, Esko" To: Matthieu Vial , Carsten Bormann Thread-Topic: [core] Issue of resources at non-default port in CoRE link format Thread-Index: Ac2bu+1gNBX/otvcQ1C9+0zNWG32cwAGOZKAAGmwMAAAjOpg8A== Date: Mon, 1 Oct 2012 08:41:25 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618AF3447@011-DB3MPN2-083.MGDPHG.emi.philips.com> References: <031DD135F9160444ABBE3B0C36CED618AF2BCB@011-DB3MPN2-083.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.103] 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] Issue of resources at non-default port in CoRE link format X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 08:42:22 -0000 Hi Matthieu, indeed such a 2-step approach works fine as a solution and is already one o= f the examples in RFC 6690. The "ct=3D40" part in the request indicates to = the client that it should/could check out the link-format description at po= rt 61616 further. Req: coap://mydevice/.well-known/core Rsp: 2.05 Content ;ct=3D40 Then Req: coap://mydevice:61616/.well-known/core Rsp: 2.05 Content , But if most CoAP discovery/client implementers don't implement such link fo= llowing (since it's not normative behavior to do so), there will potentiall= y be no single, interoperable means of service/resource discovery. The CoAP spec COULD provide some guidelines here on top of RFC 6690 to achi= eve such interoperability. Esko -----Original Message----- From: Matthieu Vial [mailto:matthieu.vi4l@gmail.com] Sent: Friday 28 September 2012 16:17 To: Carsten Bormann Cc: Dijk, Esko; core@ietf.org Subject: Re: [core] Issue of resources at non-default port in CoRE link for= mat Hi Esko and Carsten, Can we imagine something simpler with a kind of redirect like Req: coap://mydevice/.well-known/core Rsp: 2.05 Content Then Req: coap://mydevice:61616/.well-known/core Rsp: 2.05 Content , Now /resource1 should be resolved as coap://mydevice:61616/resource1 Obviously the simple lookup function of RFC6690 will not suffice in that ca= se. Perhaps a port redirect option in the response would even be more elegant and might work with the lookup interface. Regards, Matthieu ________________________________ 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 Oct 1 02:28:07 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8529921F85BB for ; Mon, 1 Oct 2012 02:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.899 X-Spam-Level: X-Spam-Status: No, score=-3.899 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3LaE+eN86Wi for ; Mon, 1 Oct 2012 02:28:06 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe001.messaging.microsoft.com [213.199.154.204]) by ietfa.amsl.com (Postfix) with ESMTP id 57C2321F8587 for ; Mon, 1 Oct 2012 02:28:06 -0700 (PDT) Received: from mail19-am1-R.bigfish.com (10.3.201.225) by AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id 14.1.225.23; Mon, 1 Oct 2012 09:28:05 +0000 Received: from mail19-am1 (localhost [127.0.0.1]) by mail19-am1-R.bigfish.com (Postfix) with ESMTP id 0F6C6420241; Mon, 1 Oct 2012 09:28:05 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -38 X-BigFish: VPS-38(zz217bL15d6O9251Jc89bhd6eah542Mzz1202h1d1ah1d2ahzz1033IL8275dhz2dh2a8h668h839hd25hf0ah107ah1288h12a5h12a9h12bdh137ah13b6h1155h) Received: from mail19-am1 (localhost.localdomain [127.0.0.1]) by mail19-am1 (MessageSwitch) id 1349083683233382_1153; Mon, 1 Oct 2012 09:28:03 +0000 (UTC) Received: from AM1EHSMHS008.bigfish.com (unknown [10.3.201.242]) by mail19-am1.bigfish.com (Postfix) with ESMTP id 2A7EE12004D; Mon, 1 Oct 2012 09:28:03 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by AM1EHSMHS008.bigfish.com (10.3.207.108) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 1 Oct 2012 09:28:02 +0000 Received: from 011-DB3MMR1-012.MGDPHG.emi.philips.com (10.128.28.96) by 011-DB3MMR1-009.MGDPHG.emi.philips.com (10.128.28.48) with Microsoft SMTP Server (TLS) id 14.2.309.3; Mon, 1 Oct 2012 10:28:01 +0100 Received: from 011-DB3MPN2-083.MGDPHG.emi.philips.com ([169.254.3.124]) by 011-DB3MMR1-012.MGDPHG.emi.philips.com ([10.128.28.96]) with mapi id 14.02.0309.003; Mon, 1 Oct 2012 10:28:01 +0100 From: "Dijk, Esko" To: Carsten Bormann Thread-Topic: [core] Issue of resources at non-default port in CoRE link format Thread-Index: Ac2bu+1gNBX/otvcQ1C9+0zNWG32cwAGOZKAAPhN5GA= Date: Mon, 1 Oct 2012 09:28:01 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618AF350F@011-DB3MPN2-083.MGDPHG.emi.philips.com> References: <031DD135F9160444ABBE3B0C36CED618AF2BCB@011-DB3MPN2-083.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.103] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: "core@ietf.org" Subject: Re: [core] Issue of resources at non-default port in CoRE link format X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 09:28:07 -0000 (Brainstorming mode continued:) Or we define something like a 'port hint' which gives an indication that th= e resource is hosted (or, also hosted) at the indicated port: ;rt=3D"core.rd";p=3D61616 Equal length to the absolute URI form: ;rt=3D"core.rd" Another interpretation of 'p' could be 'preferred alternative port for the = authority'. Esko -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org] Sent: Wednesday 26 September 2012 13:51 To: Dijk, Esko Cc: core@ietf.org Subject: Re: [core] Issue of resources at non-default port in CoRE link for= mat Hi Esko, I think the usecase you are describing is likely to occur with high frequen= cy. Definitely worth looking at. So, looking at: > ;rt=3D"core.rd" (Note that would be equivalent in a document that was obtaine= d from a coap:// URI.) Unfortunately, that is an absolute URI, but would need to be interpreted as= a relative reference (RFC 3986 =A7 4.2). I.e., in the algorithm listed in =A7 5.2.2, this evaluates to true: defined(R.authority) (Or, in still other words, you get to take the entire authority from the ba= se or from the URI reference, but can't mix within.) Brainstorming mode: Note that we have not defined the name resolution mechanism to be used for = hostnames in CoAP URIs. We could define a special host notation as the "context host" (some handwav= ing required here). Say, if that special notation we choose is ".": (We could also use an empty hostname, as you suggest above and as one could= read out of =A7 6.2.3, but that also contradicts other parts of that subse= ction.) I'm not sure I like that approach, because it means existing relative URI r= eference resolution implementations will need to add a special case. (At least, this could be handled in a post-processing step after doing the = main resolution.) 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 zach@sensinode.com Mon Oct 1 03:27:36 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF2421F860B for ; Mon, 1 Oct 2012 03:27:36 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F388YIJCFZgC for ; Mon, 1 Oct 2012 03:27:34 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 83E3E21F8600 for ; Mon, 1 Oct 2012 03:27:33 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q91ARUlS004780; Mon, 1 Oct 2012 13:27:30 +0300 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Zach Shelby In-Reply-To: <031DD135F9160444ABBE3B0C36CED618AF350F@011-DB3MPN2-083.MGDPHG.emi.philips.com> Date: Mon, 1 Oct 2012 13:27:30 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <174A046A-57EC-490B-BB01-86258A0AB7FB@sensinode.com> References: <031DD135F9160444ABBE3B0C36CED618AF2BCB@011-DB3MPN2-083.MGDPHG.emi.philips.com> <031DD135F9160444ABBE3B0C36CED618AF350F@011-DB3MPN2-083.MGDPHG.emi.philips.com> To: "Dijk, Esko" X-Mailer: Apple Mail (2.1084) Cc: "core@ietf.org" Subject: Re: [core] Issue of resources at non-default port in CoRE link format X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 10:27:36 -0000 On Oct 1, 2012, at 12:28 PM, Dijk, Esko wrote: > (Brainstorming mode continued:) >=20 > Or we define something like a 'port hint' which gives an indication = that the resource is hosted (or, also hosted) at the indicated port: > ;rt=3D"core.rd";p=3D61616 >=20 > Equal length to the absolute URI form: > ;rt=3D"core.rd" >=20 > Another interpretation of 'p' could be 'preferred alternative port for = the authority'. That certainly avoids the need to mess with the URI processing rules.=20 We should also consider the meaning of the already existing RFC5988 = "anchor" parameter. This parameter overrides the default context of the = "hosts" relation type. However, it is not clear if this can be used to = partially override the default context (e.g. just the port). As it is = defined as a URI, it should probably have the same processing rules as = with the target, so I would assume that mixing the default context (the = host) and the anchor (just the port) is not allowed. Zach >=20 > Esko >=20 > -----Original Message----- > From: Carsten Bormann [mailto:cabo@tzi.org] > Sent: Wednesday 26 September 2012 13:51 > To: Dijk, Esko > Cc: core@ietf.org > Subject: Re: [core] Issue of resources at non-default port in CoRE = link format >=20 > Hi Esko, >=20 > I think the usecase you are describing is likely to occur with high = frequency. > Definitely worth looking at. >=20 > So, looking at: >=20 >> ;rt=3D"core.rd" >=20 > (Note that would be equivalent in a document that was = obtained from a coap:// URI.) >=20 > Unfortunately, that is an absolute URI, but would need to be = interpreted as a relative reference (RFC 3986 =A7 4.2). > I.e., in the algorithm listed in =A7 5.2.2, this evaluates to true: >=20 > defined(R.authority) >=20 > (Or, in still other words, you get to take the entire authority from = the base or from the URI reference, but can't mix within.) >=20 > Brainstorming mode: > Note that we have not defined the name resolution mechanism to be used = for hostnames in CoAP URIs. > We could define a special host notation as the "context host" (some = handwaving required here). > Say, if that special notation we choose is ".": > (We could also use an empty hostname, as you suggest above and as one = could read out of =A7 6.2.3, but that also contradicts other parts of = that subsection.) > I'm not sure I like that approach, because it means existing relative = URI reference resolution implementations will need to add a special = case. > (At least, this could be handled in a post-processing step after doing = the main resolution.) >=20 > Gr=FC=DFe, Carsten >=20 >=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 > _______________________________________________ > 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 From internet-drafts@ietf.org Mon Oct 1 04:24:23 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 173DF21F8619; Mon, 1 Oct 2012 04:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.509 X-Spam-Level: X-Spam-Status: No, score=-102.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ld27XnfLFnPu; Mon, 1 Oct 2012 04:24:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72F7C21F8623; Mon, 1 Oct 2012 04:24:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121001112421.9211.80262.idtracker@ietfa.amsl.com> Date: Mon, 01 Oct 2012 04:24:21 -0700 Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-coap-12.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 11:24:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Constrained RESTful Environments Working = Group of the IETF. Title : Constrained Application Protocol (CoAP) Author(s) : Zach Shelby Klaus Hartke Carsten Bormann Brian Frank Filename : draft-ietf-core-coap-12.txt Pages : 108 Date : 2012-10-01 Abstract: The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as 6LoWPAN often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine-to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP easily interfaces with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead and simplicity for constrained environments. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-coap There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-core-coap-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-coap-12 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From cabo@tzi.org Mon Oct 1 04:27:51 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A7F021F861F for ; Mon, 1 Oct 2012 04:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.428 X-Spam-Level: X-Spam-Status: No, score=-105.428 tagged_above=-999 required=5 tests=[AWL=-0.822, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, RCVD_IN_NJABL_PROXY=1.643, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3II4X8ZK8y0a for ; Mon, 1 Oct 2012 04:27:50 -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 7B25721F860B for ; Mon, 1 Oct 2012 04:27:49 -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 q91BRes7020639 for ; Mon, 1 Oct 2012 13:27:40 +0200 (CEST) Received: from [192.168.217.105] (p5489473E.dip.t-dialin.net [84.137.71.62]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 4FFA1333; Mon, 1 Oct 2012 13:27:40 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Mon, 1 Oct 2012 13:27:39 +0200 To: "core@ietf.org WG" Message-Id: <878A65BD-90FE-4A87-B193-00F5602A5885@tzi.org> Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) X-Mailer: Apple Mail (2.1498) Subject: [core] coap-12 available X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 11:27:51 -0000 We just submitted coap-12. This is intended to cover most, but not all of the WGLC comments, with a focus on getting done with anything that would have an on-the-wire format impact. The big change, of course, is the great renumbering we agreed to in Vancouver. It is thus intended as the next stable version of CoAP, as input for interoperability testing, in particular the next ETSI event. Work continues on the remaining WGLC comments, but with maybe lower impact on implementers. Right now, -observe and -block are next. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-coap There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-core-coap-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-coap-12 Gr=FC=DFe, Carsten From kovatsch@inf.ethz.ch Mon Oct 1 15:07:57 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED0221F0CC4 for ; Mon, 1 Oct 2012 15:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ysNT48ghL5yo for ; Mon, 1 Oct 2012 15:07:57 -0700 (PDT) Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) by ietfa.amsl.com (Postfix) with ESMTP id 1CA701F0417 for ; Mon, 1 Oct 2012 15:07:55 -0700 (PDT) Received: from CAS22.d.ethz.ch (172.31.51.112) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.2.298.4; Tue, 2 Oct 2012 00:07:46 +0200 Received: from MBX10.d.ethz.ch ([fe80::6d7b:f3da:a5b1:c9e9]) by CAS22.d.ethz.ch ([fe80::dd0e:466a:b055:c090%10]) with mapi id 14.02.0298.004; Tue, 2 Oct 2012 00:07:47 +0200 From: "Kovatsch Matthias" To: "core@ietf.org WG" Thread-Topic: coaps testing (DTLS) Thread-Index: Ac2gIHCTXwW+f+DiQ5CRz9XOGwP+zg== Date: Mon, 1 Oct 2012 22:07:47 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B514CADA7A@MBX10.d.ethz.ch> Accept-Language: en-US, de-CH Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [178.83.15.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [core] coaps testing (DTLS) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 22:07:58 -0000 Dear list Does anyone I have not talked to yet already have DTLS 1.2 support for thei= r CoAP implementation? I have a some DTLS+CoAP-08 test servers running and would be happy about so= me interop testing. More information is given here: http://vs0.inf.ethz.ch/ Ciao Matthias From esko.dijk@philips.com Tue Oct 2 01:22:43 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E842921F8B4A for ; Tue, 2 Oct 2012 01:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.848 X-Spam-Level: X-Spam-Status: No, score=-3.848 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K5u47RYoaX8I for ; Tue, 2 Oct 2012 01:22:40 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe003.messaging.microsoft.com [216.32.180.186]) by ietfa.amsl.com (Postfix) with ESMTP id D902F21F8B49 for ; Tue, 2 Oct 2012 01:22:39 -0700 (PDT) Received: from mail69-co1-R.bigfish.com (10.243.78.229) by CO1EHSOBE016.bigfish.com (10.243.66.79) with Microsoft SMTP Server id 14.1.225.23; Tue, 2 Oct 2012 08:22:39 +0000 Received: from mail69-co1 (localhost [127.0.0.1]) by mail69-co1-R.bigfish.com (Postfix) with ESMTP id 248A0CC01E2 for ; Tue, 2 Oct 2012 08:22:39 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -34 X-BigFish: VPS-34(zz217bL15d6O9251Jc85fhd799h14ffIzz1202h1d1ah1d2ahzz1033IL8275dhz2dh2a8h668h839hd25hf0ah107ah1288h12a5h12bdh137ah1155h) Received: from mail69-co1 (localhost.localdomain [127.0.0.1]) by mail69-co1 (MessageSwitch) id 1349166156142512_11980; Tue, 2 Oct 2012 08:22:36 +0000 (UTC) Received: from CO1EHSMHS006.bigfish.com (unknown [10.243.78.241]) by mail69-co1.bigfish.com (Postfix) with ESMTP id 20578C0048; Tue, 2 Oct 2012 08:22:36 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CO1EHSMHS006.bigfish.com (10.243.66.16) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 2 Oct 2012 08:22:35 +0000 Received: from 011-DB3MPN2-083.MGDPHG.emi.philips.com ([169.254.3.124]) by 011-DB3MMR1-002.MGDPHG.emi.philips.com ([10.128.28.52]) with mapi id 14.02.0309.003; Tue, 2 Oct 2012 09:21:16 +0100 From: "Dijk, Esko" To: M Pouillot , "core@ietf.org" Thread-Topic: Block mechanism and size of ressources+query Thread-Index: Ac2aZXkYwm8DGNvaSiWLxAwhjt7VJwCL6bbw Date: Tue, 2 Oct 2012 08:21:16 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618AF380D@011-DB3MPN2-083.MGDPHG.emi.philips.com> References: <1D0972C5226A7649BBB5E3734FCD593D01BB362C@DB3PRD0510MB393.eurprd05.prod.outlook.com> In-Reply-To: <1D0972C5226A7649BBB5E3734FCD593D01BB362C@DB3PRD0510MB393.eurprd05.prod.outlook.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.103] Content-Type: multipart/alternative; boundary="_000_031DD135F9160444ABBE3B0C36CED618AF380D011DB3MPN2083MGDP_" MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: Re: [core] Block mechanism and size of ressources+query X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 08:22:43 -0000 --_000_031DD135F9160444ABBE3B0C36CED618AF380D011DB3MPN2083MGDP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mathieu, indeed a sort of BlockID Option could help to avoid the Uri + Uri-Query ove= rhead and possibly overhead of other options too. Also, simple servers supp= orting -block, but that do not want to store such state, can simply not use= the BlockID in their response. Note with the current -block specification, there is already a proprietary = way to avoid the overhead of Uri + Uri-query in each block request e.g. for= Blockwise PUT: * Client sends a POST to the resource that it wants to update, incl= uding the long Uri-Path and Uri-Query options * Server responds with a single Location-Path option of a new tempo= rary resource that was created e.g. a short random string "9X" This resource is an alias to the actual resource that was addressed in the = POST. * Client then PUTs / uploads blocks to the (short) resource path e.= g. "9X", without Uri-Query options. * After full block transfer is done, the server removes the tempora= ry resource Optionally the client could indicate in the first step with a specific Uri-= Query option that it want to apply the above technique (e.g. "create-alias= =3D1" or so) Esko From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of M P= ouillot Sent: Monday 24 September 2012 17:11 To: core@ietf.org Subject: [core] Block mechanism and size of ressources+query Hello all, Is there a mean in the block mechanism to not send at each blocked packet a= ll the ressource and query on which the request is done? The size of the uri could be very big and so take a lot of bandwith, energy= , ... on lossy network. May be we can imagine on the first transaction of Block to have in response= a BlockID-SequenceNumber on which all next transaction on this ID could be= suffisant to remember all the context(ressource+query)... Any suggestion? Mathieu ________________________________ 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_031DD135F9160444ABBE3B0C36CED618AF380D011DB3MPN2083MGDP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mathieu,

 

indeed a sort of Block= ID Option could help to avoid the Uri + Uri-Query overhead and possibly= overhead of other options too. Also, simple servers supporting –bloc= k, but that do not want to store such state, can simply not use the BlockID in their response.

 

Note with the current = –block specification, there is already a proprietary way to avoid the= overhead of Uri + Uri-query in each block request e.g. for Blockwise P= UT:

 

·      = ;   Client sends a POST to t= he resource that it wants to update, including the long Uri-Path and Uri-Qu= ery options

·      = ;   Server responds with a s= ingle Location-Path option of a new temporary resource that was created e.g= . a short random string “9X”
This resource is an alias to the actual resource that was addressed in the = POST.

·      = ;   Client then PUTs / uploa= ds blocks to the (short) resource path e.g. “9X”, without Uri-Q= uery options.

·      = ;   After full block transfe= r is done, the server removes the temporary resource

 

Optionally the client = could indicate in the first step with a specific Uri-Query option that it w= ant to apply the above technique (e.g. “create-alias=3D1” or so= )

 

Esko

 

From: core-b= ounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of M Pouillot
Sent: Monday 24 September 2012 17:11
To: core@ietf.org
Subject: [core] Block mechanism and size of ressources+query

 

Hello all,

 

Is there a mean in the block mecha= nism to not send at each blocked packet all the ressource and query on whic= h the request is done?

The size of the uri could be very = big and so take a lot of bandwith, energy, … on lossy network.=

 

May be we can imagine on the first= transaction of Block to have in response a BlockID-SequenceNumber on which= all next transaction on this ID could be suffisant to remember all the con= text(ressource+query)…

 

Any suggestion?

 

Mathieu


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_031DD135F9160444ABBE3B0C36CED618AF380D011DB3MPN2083MGDP_-- From cabo@tzi.org Tue Oct 2 01:48:38 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC9C21F8605 for ; Tue, 2 Oct 2012 01:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.215 X-Spam-Level: X-Spam-Status: No, score=-106.215 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8HpFPzqcio65 for ; Tue, 2 Oct 2012 01:48:37 -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 523EA21F85F7 for ; Tue, 2 Oct 2012 01:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q928mQ0F008012; Tue, 2 Oct 2012 10:48:26 +0200 (CEST) Received: from [192.168.217.105] (p54892CA3.dip.t-dialin.net [84.137.44.163]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id E26167A7; Tue, 2 Oct 2012 10:48:25 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: <031DD135F9160444ABBE3B0C36CED618AF380D@011-DB3MPN2-083.MGDPHG.emi.philips.com> Date: Tue, 2 Oct 2012 10:48:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8719175C-AC23-435B-8460-6D0E6913ABA5@tzi.org> References: <1D0972C5226A7649BBB5E3734FCD593D01BB362C@DB3PRD0510MB393.eurprd05.prod.outlook.com> <031DD135F9160444ABBE3B0C36CED618AF380D@011-DB3MPN2-083.MGDPHG.emi.philips.com> To: "Dijk, Esko" X-Mailer: Apple Mail (2.1498) Cc: "core@ietf.org" Subject: Re: [core] Block mechanism and size of ressources+query X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 08:48:38 -0000 > =B7 Client sends a POST to the resource that it wants to = update, including the long Uri-Path and Uri-Query options > =B7 Server responds with a single Location-Path option of a = new temporary resource that was created e.g. a short random string =939X=94= > This resource is an alias to the actual resource that was addressed in = the POST. > =B7 Client then PUTs / uploads blocks to the (short) resource = path e.g. =939X=94, without Uri-Query options. > =B7 After full block transfer is done, the server removes the = temporary resource Exactly, this is the way it can be done while not leaving the REST = framework too much if the overhead really hurts. Bonus: The client could even explicitly manage the state, and, DELETE = the temporary resource when it decides that the upload needs to be = aborted. (Klaus discussed this a while ago, naming this state a "session". = http://www.ietf.org/mail-archive/web/core/current/msg02992.html Right now, all this state is managed implicitly, which is probably the = right thing for most use cases.) A long time ago, we actually considered an option to give a temporary = name to a resource within the normal request methods. See appendix B.3 of coap-misc. At the time, we decided we didn't need this, so it's in the "cemetery" = part of coap-misc. > The size of the uri could be very big and so take a lot of bandwith, = energy, =85 on lossy network. Right, the classical response to this is "then don't do it" :-) Don't make big URIs for things that are used in many transfers. Gr=FC=DFe, Carsten From zach@sensinode.com Tue Oct 2 02:22:09 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26DFE21F8AFA for ; Tue, 2 Oct 2012 02:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCuJmbqaqJo6 for ; Tue, 2 Oct 2012 02:22:08 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE2021F8AFB for ; Tue, 2 Oct 2012 02:22:06 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q929M2QR005473; Tue, 2 Oct 2012 12:22:03 +0300 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <8719175C-AC23-435B-8460-6D0E6913ABA5@tzi.org> Date: Tue, 2 Oct 2012 12:22:02 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1D0972C5226A7649BBB5E3734FCD593D01BB362C@DB3PRD0510MB393.eurprd05.prod.outlook.com> <031DD135F9160444ABBE3B0C36CED618AF380D@011-DB3MPN2-083.MGDPHG.emi.philips.com> <8719175C-AC23-435B-8460-6D0E6913ABA5@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.1084) Cc: "core@ietf.org" Subject: Re: [core] Block mechanism and size of ressources+query X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 09:22:09 -0000 On Oct 2, 2012, at 11:48 AM, Carsten Bormann wrote: > A long time ago, we actually considered an option to give a temporary = name to a resource within the normal request methods. > See appendix B.3 of coap-misc. > At the time, we decided we didn't need this, so it's in the "cemetery" = part of coap-misc. There is nothing that stops you from doing this now, as multiple URIs = can be associated with the same logical resource. The issue is just how = you express that e.g. using the link format in order to discover = alternative URIs for a resource (e.g. for the purpose on block = transfer). For example RFC5988 points out an existing relation type = called "alternate", not 100% sure if that applies here though.=20 The alternative is of course to build something into the Block mechanism = as Esko suggested. Just a thought, how hard would it be to use Token for = that purpose? That is in practice what we use token for in Observe = relationships.=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 From esko.dijk@philips.com Tue Oct 2 06:30:33 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4CC321F866D for ; Tue, 2 Oct 2012 06:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.813 X-Spam-Level: X-Spam-Status: No, score=-3.813 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJJv2ymnyGB2 for ; Tue, 2 Oct 2012 06:30:32 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe003.messaging.microsoft.com [216.32.180.13]) by ietfa.amsl.com (Postfix) with ESMTP id 935DC21F8643 for ; Tue, 2 Oct 2012 06:30:32 -0700 (PDT) Received: from mail200-va3-R.bigfish.com (10.7.14.250) by VA3EHSOBE001.bigfish.com (10.7.40.21) with Microsoft SMTP Server id 14.1.225.23; Tue, 2 Oct 2012 13:30:31 +0000 Received: from mail200-va3 (localhost [127.0.0.1]) by mail200-va3-R.bigfish.com (Postfix) with ESMTP id 54084D802C8; Tue, 2 Oct 2012 13:30:31 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -45 X-BigFish: VPS-45(zz217bL98dI15d6O9371I9251Jd6eah542M1db9Mzz1202h1d1ah1d2ahzz8275ch1033IL17326ah8275bh8275dhz2dh2a8h668h839h944hd25hf0ah107ah1220h1288h12a5h12a9h12bdh137ah13b6h1155h) Received: from mail200-va3 (localhost.localdomain [127.0.0.1]) by mail200-va3 (MessageSwitch) id 1349184629586600_438; Tue, 2 Oct 2012 13:30:29 +0000 (UTC) Received: from VA3EHSMHS015.bigfish.com (unknown [10.7.14.246]) by mail200-va3.bigfish.com (Postfix) with ESMTP id 7FF65C00048; Tue, 2 Oct 2012 13:30:29 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by VA3EHSMHS015.bigfish.com (10.7.99.25) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 2 Oct 2012 13:30:28 +0000 Received: from 011-DB3MMR1-018.MGDPHG.emi.philips.com (10.128.28.104) by 011-DB3MMR1-009.MGDPHG.emi.philips.com (10.128.28.48) with Microsoft SMTP Server (TLS) id 14.2.309.3; Tue, 2 Oct 2012 14:30:09 +0100 Received: from 011-DB3MPN2-083.MGDPHG.emi.philips.com ([169.254.3.124]) by 011-DB3MMR1-018.MGDPHG.emi.philips.com ([10.128.28.104]) with mapi id 14.02.0309.003; Tue, 2 Oct 2012 14:30:09 +0100 From: "Dijk, Esko" To: Zach Shelby , Carsten Bormann Thread-Topic: [core] Block mechanism and size of ressources+query Thread-Index: Ac2aZXkYwm8DGNvaSiWLxAwhjt7VJwCL6bbwAPdLOwAAASy1AAAJ7xLA Date: Tue, 2 Oct 2012 13:30:09 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618AF392E@011-DB3MPN2-083.MGDPHG.emi.philips.com> References: <1D0972C5226A7649BBB5E3734FCD593D01BB362C@DB3PRD0510MB393.eurprd05.prod.outlook.com> <031DD135F9160444ABBE3B0C36CED618AF380D@011-DB3MPN2-083.MGDPHG.emi.philips.com> <8719175C-AC23-435B-8460-6D0E6913ABA5@tzi.org> 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.103] 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] Block mechanism and size of ressources+query X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 13:30:33 -0000 The "alternate" relation could be used for shortening Uri-Path, however it = can't cope with one or more Uri-Query Options in the blockwise request. The= se still have to be provided then in every request to PUT a block or reques= t to GET a block of data. Using a Token instead of a set of Uri-Path/Uri-Query seems possible in a bl= ock request following a previous one with the same Token, provided that the= root resource ('/') is not assigned to something. This because a stateless= server not supporting "sessions" via Token would interpret it as a request= to get a block of the resource '/' , since Uri-Path Options are not includ= ed in the subsequent block request by the client. The idea is then that a server not supporting the proposed use of Token wou= ld reply 4.04 Not Found, indicating to the client that establishing a "sess= ion" via Token this way is not supported. Esko -----Original Message----- From: Zach Shelby [mailto:zach@sensinode.com] Sent: Tuesday 2 October 2012 11:22 To: Carsten Bormann Cc: Dijk, Esko; core@ietf.org Subject: Re: [core] Block mechanism and size of ressources+query On Oct 2, 2012, at 11:48 AM, Carsten Bormann wrote: > A long time ago, we actually considered an option to give a temporary nam= e to a resource within the normal request methods. > See appendix B.3 of coap-misc. > At the time, we decided we didn't need this, so it's in the "cemetery" pa= rt of coap-misc. There is nothing that stops you from doing this now, as multiple URIs can b= e associated with the same logical resource. The issue is just how you expr= ess that e.g. using the link format in order to discover alternative URIs f= or a resource (e.g. for the purpose on block transfer). For example RFC5988= points out an existing relation type called "alternate", not 100% sure if = that applies here though. The alternative is of course to build something into the Block mechanism as= Esko suggested. Just a thought, how hard would it be to use Token for that= purpose? That is in practice what we use token for in Observe relationship= s. Zach -- 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 ________________________________ 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 Tue Oct 2 07:02:15 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C00A721F84B9 for ; Tue, 2 Oct 2012 07:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.216 X-Spam-Level: X-Spam-Status: No, score=-106.216 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WgPe8WyxE5pQ for ; Tue, 2 Oct 2012 07:02:15 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 0207121F84C4 for ; Tue, 2 Oct 2012 07:02:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q92E26Ax024760; Tue, 2 Oct 2012 16:02:06 +0200 (CEST) Received: from [192.168.217.105] (p54892E0F.dip.t-dialin.net [84.137.46.15]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id C98B1A37; Tue, 2 Oct 2012 16:02:05 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <031DD135F9160444ABBE3B0C36CED618AF392E@011-DB3MPN2-083.MGDPHG.emi.philips.com> Date: Tue, 2 Oct 2012 16:02:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1D0972C5226A7649BBB5E3734FCD593D01BB362C@DB3PRD0510MB393.eurprd05.prod.outlook.com> <031DD135F9160444ABBE3B0C36CED618AF380D@011-DB3MPN2-083.MGDPHG.emi.philips.com> <8719175C-AC23-435B-8460-6D0E6913ABA5@tzi.org> <031DD135F9160444ABBE3B0C36CED618AF392E@011-DB3MPN2-083.MGDPHG.emi.philips.com> To: "Dijk, Esko" X-Mailer: Apple Mail (2.1498) Cc: "core@ietf.org" Subject: Re: [core] Block mechanism and size of ressources+query X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 14:02:15 -0000 On Oct 2, 2012, at 15:30, "Dijk, Esko" wrote: > proposed use of Token Well, the whole point of ticket #210 was to get rid of such a second = meaning for Token, because we found out it hurts interoperability when = different implementations handle the overloading in a different way. Instead of overloading Token with this semantics, it is much cleaner to = have something like a special URI or a Teri. I think we have a good basic design, I'm just still not convinced we = need the function. Tell me about the usecase... Gr=FC=DFe, Carsten From esko.dijk@philips.com Tue Oct 2 07:14:33 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5484B21F847A for ; Tue, 2 Oct 2012 07:14:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.286 X-Spam-Level: X-Spam-Status: No, score=-5.286 tagged_above=-999 required=5 tests=[AWL=1.313, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id plF+c1Dl2jyB for ; Tue, 2 Oct 2012 07:14:32 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id AF8AA21F84A2 for ; Tue, 2 Oct 2012 07:14:32 -0700 (PDT) Received: from mail26-tx2-R.bigfish.com (10.9.14.241) by TX2EHSOBE014.bigfish.com (10.9.40.34) with Microsoft SMTP Server id 14.1.225.23; Tue, 2 Oct 2012 14:14:26 +0000 Received: from mail26-tx2 (localhost [127.0.0.1]) by mail26-tx2-R.bigfish.com (Postfix) with ESMTP id 280C61000CB; Tue, 2 Oct 2012 14:14:26 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -41 X-BigFish: VPS-41(zz217bL98dI15d6O9251Jc89bh1431Jd6eah542Mzz1202h1d1ah1d2ahzz1033IL8275bh8275dhz2dh2a8h668h839hd25hf0ah107ah1288h12a5h12a9h12bdh137ah13b6h1155h) Received: from mail26-tx2 (localhost.localdomain [127.0.0.1]) by mail26-tx2 (MessageSwitch) id 1349187263963676_1893; Tue, 2 Oct 2012 14:14:23 +0000 (UTC) Received: from TX2EHSMHS031.bigfish.com (unknown [10.9.14.250]) by mail26-tx2.bigfish.com (Postfix) with ESMTP id DE4B2380045; Tue, 2 Oct 2012 14:14:23 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by TX2EHSMHS031.bigfish.com (10.9.99.131) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 2 Oct 2012 14:14:22 +0000 Received: from 011-DB3MMR1-015.MGDPHG.emi.philips.com (10.128.28.99) by 011-DB3MMR1-010.MGDPHG.emi.philips.com (10.128.28.49) with Microsoft SMTP Server (TLS) id 14.2.309.3; Tue, 2 Oct 2012 15:15:14 +0100 Received: from 011-DB3MPN2-083.MGDPHG.emi.philips.com ([169.254.3.124]) by 011-DB3MMR1-015.MGDPHG.emi.philips.com ([10.128.28.99]) with mapi id 14.02.0309.003; Tue, 2 Oct 2012 15:13:41 +0100 From: "Dijk, Esko" To: Carsten Bormann Thread-Topic: [core] Block mechanism and size of ressources+query Thread-Index: Ac2aZXkYwm8DGNvaSiWLxAwhjt7VJwCL6bbwAPdLOwAAASy1AAAJ7xLA///+xwD//+32wA== Date: Tue, 2 Oct 2012 14:13:40 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618AF3982@011-DB3MPN2-083.MGDPHG.emi.philips.com> References: <1D0972C5226A7649BBB5E3734FCD593D01BB362C@DB3PRD0510MB393.eurprd05.prod.outlook.com> <031DD135F9160444ABBE3B0C36CED618AF380D@011-DB3MPN2-083.MGDPHG.emi.philips.com> <8719175C-AC23-435B-8460-6D0E6913ABA5@tzi.org> <031DD135F9160444ABBE3B0C36CED618AF392E@011-DB3MPN2-083.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.103] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: "core@ietf.org" Subject: Re: [core] Block mechanism and size of ressources+query X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 14:14:33 -0000 For me the basic design is ok, with use of a 'special URI' or simply short = URIs as a way to avoid the issue that Mathieu mentioned. I just wanted to c= onfirm that overloading Token this way is possible. (Even though ticket #21= 0 indicates we better not do this.) Esko -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org] Sent: Tuesday 2 October 2012 16:02 To: Dijk, Esko Cc: Zach Shelby; core@ietf.org Subject: Re: [core] Block mechanism and size of ressources+query On Oct 2, 2012, at 15:30, "Dijk, Esko" wrote: > proposed use of Token Well, the whole point of ticket #210 was to get rid of such a second meanin= g for Token, because we found out it hurts interoperability when different = implementations handle the overloading in a different way. Instead of overloading Token with this semantics, it is much cleaner to hav= e something like a special URI or a Teri. I think we have a good basic design, I'm just still not convinced we need t= he function. Tell me about the usecase... 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 cabo@tzi.org Tue Oct 2 07:14:39 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C55421F844C for ; Tue, 2 Oct 2012 07:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.217 X-Spam-Level: X-Spam-Status: No, score=-106.217 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PcFukh77kw40 for ; Tue, 2 Oct 2012 07:14:39 -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 BD5D121F841E for ; Tue, 2 Oct 2012 07:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q92EEVD2001834; Tue, 2 Oct 2012 16:14:31 +0200 (CEST) Received: from [192.168.217.105] (p54892E0F.dip.t-dialin.net [84.137.46.15]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 56C82A77; Tue, 2 Oct 2012 16:14:31 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Tue, 2 Oct 2012 16:14:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <102BDC14-E6FF-43E3-B2DC-1228B332BB1A@tzi.org> References: <1D0972C5226A7649BBB5E3734FCD593D01BB362C@DB3PRD0510MB393.eurprd05.prod.outlook.com> <031DD135F9160444ABBE3B0C36CED618AF380D@011-DB3MPN2-083.MGDPHG.emi.philips.com> <8719175C-AC23-435B-8460-6D0E6913ABA5@tzi.org> <031DD135F9160444ABBE3B0C36CED618AF392E@011-DB3MPN2-083.MGDPHG.emi.philips.com> To: "Dijk, Esko" X-Mailer: Apple Mail (2.1498) Cc: "core@ietf.org" Subject: Re: [core] Block mechanism and size of ressources+query X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 14:14:39 -0000 On Oct 2, 2012, at 16:02, Carsten Bormann wrote: > good basic design To summarize this outside the context of coap-misc B.3 (which didn't = even talk about -block): Any request on a URI can return an elective option, called Teri here. (B.3 made the Teri a separate namespace from URIs, but that is kind of = an orthogonal decision.) In B.3, a Teri is just an alternative name for the resource, with a = duration that is the length in time the server promises to remember that = alternative name. So this is entirely on the REST level, similar to the way a Location = header works (but of course different). People who have implemented Block1 using sessions/contexts might prefer = the Teri to be a name for just that state; i.e. it would go away on a = response with the more bit unset; the client might be able to delete the = context/session, etc. (Of course, when you have multiple names for something, you need to = decide whether DELETE deletes the name or the thing.) A Teri would always be elective, so you can run the protocol without = alt-naming the resource/the context/session. We would need to think about the proxy implications, but I would assume = Teri to be hop-by-hop in semantics. Gr=FC=DFe, Carsten From cabo@tzi.org Tue Oct 2 09:28:55 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3B9F21F8527 for ; Tue, 2 Oct 2012 09:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.219 X-Spam-Level: X-Spam-Status: No, score=-106.219 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4gil3b0xwVY for ; Tue, 2 Oct 2012 09:28:55 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 2672A21F850B for ; Tue, 2 Oct 2012 09:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q92GSl0s009014 for ; Tue, 2 Oct 2012 18:28:47 +0200 (CEST) Received: from [192.168.217.105] (p54892E0F.dip.t-dialin.net [84.137.46.15]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 4A66BBA8; Tue, 2 Oct 2012 18:28:47 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Tue, 2 Oct 2012 18:28:46 +0200 To: "core@ietf.org WG" Message-Id: <66FAC1E3-467E-4CA9-AB83-83A35AF2FB88@tzi.org> Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) X-Mailer: Apple Mail (2.1498) Subject: [core] coap-misc-21 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 16:28:56 -0000 As a followup to core-coap-12, I have just submitted version 21 of = coap-misc. Given that we are almost done, this is now almost empty, just with a = remaining section about -observe. If you are still wondering about the freshness model and haven't read = the short section, now would be a good time. Apart from the almost empty main body, there are appendices with the = Nursery, the Museum, and the Cemetery, useful for looking back why and how we did what we did. =20 (The appendix B.3 mentioned in my previous mail is now numbered C.3.) Htmlized: http://tools.ietf.org/html/draft-bormann-coap-misc-21 Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-bormann-coap-misc-21 Gr=FC=DFe, Carsten From m.pouillot@watteco.com Tue Oct 2 09:54:45 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 152F421F84CF for ; Tue, 2 Oct 2012 09:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.799 X-Spam-Level: X-Spam-Status: No, score=-4.799 tagged_above=-999 required=5 tests=[AWL=1.200, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6iBMo2Ec8Sri for ; Tue, 2 Oct 2012 09:54:44 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id 038E921F847C for ; Tue, 2 Oct 2012 09:54:43 -0700 (PDT) Received: from mail28-tx2-R.bigfish.com (10.9.14.240) by TX2EHSOBE006.bigfish.com (10.9.40.26) with Microsoft SMTP Server id 14.1.225.23; Tue, 2 Oct 2012 16:54:43 +0000 Received: from mail28-tx2 (localhost [127.0.0.1]) by mail28-tx2-R.bigfish.com (Postfix) with ESMTP id 0F1812E017B; Tue, 2 Oct 2012 16:54:43 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.252.165; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0510HT005.eurprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -91 X-BigFish: VPS-91(zz217bL98dI15d6O9251Jc89bh1431Jd6eah542Mc85dh15caKJzz1202h1d1ah1d2ahzz1033IL8275bh8275dhz2dh2a8h668h839hd25hf0ah107ah1288h12a5h12bdh137ah1441h34h1155h) Received: from mail28-tx2 (localhost.localdomain [127.0.0.1]) by mail28-tx2 (MessageSwitch) id 134919688044821_10076; Tue, 2 Oct 2012 16:54:40 +0000 (UTC) Received: from TX2EHSMHS005.bigfish.com (unknown [10.9.14.244]) by mail28-tx2.bigfish.com (Postfix) with ESMTP id EE15512004E; Tue, 2 Oct 2012 16:54:39 +0000 (UTC) Received: from DBXPRD0510HT005.eurprd05.prod.outlook.com (157.56.252.165) by TX2EHSMHS005.bigfish.com (10.9.99.105) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 2 Oct 2012 16:54:36 +0000 Received: from DBXPRD0510MB396.eurprd05.prod.outlook.com ([169.254.8.245]) by DBXPRD0510HT005.eurprd05.prod.outlook.com ([10.255.67.168]) with mapi id 14.16.0207.009; Tue, 2 Oct 2012 16:54:25 +0000 From: M Pouillot To: "Dijk, Esko" , Carsten Bormann Thread-Topic: [core] Block mechanism and size of ressources+query Thread-Index: Ac2aZXkYwm8DGNvaSiWLxAwhjt7VJwCL6bbwAPljrAAAASy1AAAIqlaAAAEdqAAAAGdqAAAE7UeQ Date: Tue, 2 Oct 2012 16:54:23 +0000 Message-ID: <1D0972C5226A7649BBB5E3734FCD593D075F81B4@DBXPRD0510MB396.eurprd05.prod.outlook.com> References: <1D0972C5226A7649BBB5E3734FCD593D01BB362C@DB3PRD0510MB393.eurprd05.prod.outlook.com> <031DD135F9160444ABBE3B0C36CED618AF380D@011-DB3MPN2-083.MGDPHG.emi.philips.com> <8719175C-AC23-435B-8460-6D0E6913ABA5@tzi.org> <031DD135F9160444ABBE3B0C36CED618AF392E@011-DB3MPN2-083.MGDPHG.emi.philips.com> <031DD135F9160444ABBE3B0C36CED618AF3982@011-DB3MPN2-083.MGDPHG.emi.philips.com> In-Reply-To: <031DD135F9160444ABBE3B0C36CED618AF3982@011-DB3MPN2-083.MGDPHG.emi.philips.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [82.241.54.131] Content-Type: multipart/mixed; boundary="_002_1D0972C5226A7649BBB5E3734FCD593D075F81B4DBXPRD0510MB396_" MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: "core@ietf.org" Subject: Re: [core] Block mechanism and size of ressources+query X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 16:54:45 -0000 --_002_1D0972C5226A7649BBB5E3734FCD593D075F81B4DBXPRD0510MB396_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Carsten, For example during the registration on a RD, a sensor needs to post all its= ressources. In my case it can be represented up to 10 blocks of 64 Bytes. = For each block, we repeat the uri of the RD(not so big) and the option quer= y of the RD (lifetime, host,...), 25 Bytes for 64 Bytes of data... =3D> 250= extra Bytes for only one sensor :-( during the bootstrapping. cordialement, Mathieu =20 =20 -----Message d'origine----- De=A0: core-bounces@ietf.org [mailto:core-bounces@ietf.org] De la part de D= ijk, Esko Envoy=E9=A0: mardi 2 octobre 2012 16:14 =C0=A0: Carsten Bormann Cc=A0: core@ietf.org Objet=A0: Re: [core] Block mechanism and size of ressources+query For me the basic design is ok, with use of a 'special URI' or simply short = URIs as a way to avoid the issue that Mathieu mentioned. I just wanted to c= onfirm that overloading Token this way is possible. (Even though ticket #21= 0 indicates we better not do this.) Esko -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org] Sent: Tuesday 2 October 2012 16:02 To: Dijk, Esko Cc: Zach Shelby; core@ietf.org Subject: Re: [core] Block mechanism and size of ressources+query On Oct 2, 2012, at 15:30, "Dijk, Esko" wrote: > proposed use of Token Well, the whole point of ticket #210 was to get rid of such a second meanin= g for Token, because we found out it hurts interoperability when different = implementations handle the overloading in a different way. Instead of overloading Token with this semantics, it is much cleaner to hav= e something like a special URI or a Teri. I think we have a good basic design, I'm just still not convinced we need t= he function. Tell me about the usecase... 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. _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core --_002_1D0972C5226A7649BBB5E3734FCD593D075F81B4DBXPRD0510MB396_ Content-Type: application/octet-stream; name="POST-Watteco-OPCL-2a60.pcap" Content-Description: POST-Watteco-OPCL-2a60.pcap Content-Disposition: attachment; filename="POST-Watteco-OPCL-2a60.pcap"; size=4473; creation-date="Tue, 02 Oct 2012 16:47:33 GMT"; modification-date="Tue, 02 Oct 2012 16:47:33 GMT" Content-Transfer-Encoding: base64 1MOyoQIABAAAAAAAAAAAAP//AAABAAAAMTFbUPIWDwBFAAAARQAAAK+rrK2ur0L7n4FagYCaYdya AWdgKgD//wAAAvEjAP//AAACfNcAPwAAAAAAAAAB8MSDFjNyT0IC+DqTcmRyA3JlZzEneDExW1CY Jg8AEwAAABMAAACvq6ytrq9C+5+BWoGAmgIAmmuOMjFbUNVNAAA7AAAAOwAAAK+rrK2ur0L7n4Fa gYCaYdzaAWfxIwD//wAAAmAqAP//AAACfvUAAAAAAAAAAAHwFjPEg+XdYET4Ol4yMjFbUHBdAAAT AAAAEwAAAK+rrK2ur0L7n4FagYCaAgDab8wyMVtQnlMBAIsAAACLAAAAr6usra6vQvufgVqBgJph 3NsBZ/EjAP//AAACYCoA//8AAALAkQAAfvUAAAAAAAAAAAHwFjMWM1OKRQIiQBEognJka2g9T1BM Qy0yYTYwCWx0PTQzMjAwMEEKPC9kZXYvbWZnPjt0aXRsZT0iTWFudWZhY3R1cmVyIjtydD0iaXBz by5kZXYubWZnTzIxW1BYWwEAEwAAABMAAACvq6ytrq9C+5+BWoGAmgIA2+bdMjFbUJHMAQA7AAAA OwAAAK+rrK2ur0L7n4FagYCaYdzcAWfxIwD//wAAAmAqAP//AAAC4JEAABBnIjtpZj0iY29yZSNw Iiw8L1AtMjFbUD/YAQATAAAAEwAAAK+rrK2ur0L7n4FagYCaAgDcWakyMVtQPFcDAD8AAAA/AAAA r6usra6vQvufgVqBgJph3JsBZ2AqAP//AAAC8SMA//8AAAJ81wA/AAAAAAAAAAHwFjMWM33RYkQi QOBRCqELMjFbUCRjAwATAAAAEwAAAK+rrK2ur0L7n4FagYCaAgCb4p8yMVtQa0UEAIsAAACLAAAA r6usra6vQvufgVqBgJph3N0BZ/EjAP//AAACYCoA//8AAALAkQABfvUAAAAAAAAAAAHwFjMWMwT4 RQIiQREognJka2g9T1BMQy0yYTYwCWx0PTQzMjAwMEEaZGV2L21kbD47dGl0bGU9Ik1vZGVsIjty dD0iaXBzby5kZXYubWRsIjtpZj0iY28b6DIxW1AuTQQAEwAAABMAAACvq6ytrq9C+5+BWoGAmgIA 3dC4MjFbUP+mBAA7AAAAOwAAAK+rrK2ur0L7n4FagYCaYdzeAWfxIwD//wAAAmAqAP//AAAC4JEA ARByZSNwIiw8L2Rldi9zZXI+O5z+MjFbUIq6BAATAAAAEwAAAK+rrK2ur0L7n4FagYCaAgDeS4oy MVtQUxoGAD8AAAA/AAAAr6usra6vQvufgVqBgJph3JwBZ2AqAP//AAAC8SMA//8AAAJ81wA/AAAA AAAAAAHwFjMWM23QYkQiQeBRGhH7MjFbUL0pBgATAAAAEwAAAK+rrK2ur0L7n4FagYCaAgCcXesy MVtQVBAHAIsAAACLAAAAr6usra6vQvufgVqBgJph3N8BZ/EjAP//AAACYCoA//8AAALAkQACfvUA AAAAAAAAAAHwFjMWM97zRQIiQhEognJka2g9T1BMQy0yYTYwCWx0PTQzMjAwMEEqdGl0bGU9IlNl cmlhbCI7cnQ9Imlwc28uZGV2LnNlciI7aWY9ImNvcmUjcCIsPC/AnTIxW1BeGAcAEwAAABMAAACv q6ytrq9C+5+BWoGAmgIA38KbMjFbUI19BwA7AAAAOwAAAK+rrK2ur0L7n4FagYCaYdzgAWfxIwD/ /wAAAmAqAP//AAAC4JEAAhBkZXYvbj47dGl0bGU9Ik5hbaNiMjFbUD+NBwATAAAAEwAAAK+rrK2u r0L7n4FagYCaAgDgtlIyMVtQzuwIAD8AAAA/AAAAr6usra6vQvufgVqBgJph3J0BZ2AqAP//AAAC 8SMA//8AAAJ81wA/AAAAAAAAAAHwFjMWM13PYkQiQuBRKgM7MjFbUGf8CAATAAAAEwAAAK+rrK2u r0L7n4FagYCaAgCd1PoyMVtQiPYJAIsAAACLAAAAr6usra6vQvufgVqBgJph3OEBZ/EjAP//AAAC YCoA//8AAALAkQADfvUAAAAAAAAAAAHwFjMWM/JbRQIiQxEognJka2g9T1BMQy0yYTYwCWx0PTQz MjAwMEE6ZSI7cnQ9Imlwc28uZGV2Lm4iO2lmPSJjb3JlI3AiLDwvZGV2L3B3ci8wPjt0aXSCpTIx W1AqBgoAEwAAABMAAACvq6ytrq9C+5+BWoGAmgIA4T9DMjFbUOJjCgA7AAAAOwAAAK+rrK2ur0L7 n4FagYCaYdziAWfxIwD//wAAAmAqAP//AAAC4JEAAxBsZT0iUG93ZXIgVHlwZSI7cgRiMjFbUI5z CgATAAAAEwAAAK+rrK2ur0L7n4FagYCaAgDipHEyMVtQG9MLAD8AAAA/AAAAr6usra6vQvufgVqB gJph3J4BZ2AqAP//AAAC8SMA//8AAAJ81wA/AAAAAAAAAAHwFjMWM03OYkQiQ+BROl8TMjFbUJfq CwATAAAAEwAAAK+rrK2ur0L7n4FagYCaAgCeT8gyMVtQztgMAIsAAACLAAAAr6usra6vQvufgVqB gJph3OMBZ/EjAP//AAACYCoA//8AAALAkQAEfvUAAAAAAAAAAAHwFjMWMze9RQIiRBEognJka2g9 T1BMQy0yYTYwCWx0PTQzMjAwMEFKdD0iaXBzby5kZXYucHdyIjtpZj0iY29yZSNycCIsPC9kZXYv cHdyLzAvdj47dGlyajIxW1B66AwAEwAAABMAAACvq6ytrq9C+5+BWoGAmgIA4y1gMjFbUFU+DQA7 AAAAOwAAAK+rrK2ur0L7n4FagYCaYdzkAWfxIwD//wAAAmAqAP//AAAC4JEABBB0bGU9IlBvd2Vy IjtydD0iaUpXMjFbUORNDQATAAAAEwAAAK+rrK2ur0L7n4FagYCaAgDkkhQyMVtQW7EOAD8AAAA/ AAAAr6usra6vQvufgVqBgJph3J8BZ2AqAP//AAAC8SMA//8AAAJ81wA/AAAAAAAAAAHwFjMWMz3N YkQiROBRStxlMjFbUPnADgATAAAAEwAAAK+rrK2ur0L7n4FagYCaAgCfxtkzMVtQOm0AAIsAAACL AAAAr6usra6vQvufgVqBgJph3OUBZ/EjAP//AAACYCoA//8AAALAkQAFfvUAAAAAAAAAAAHwFjMW M3DmRQIiRREognJka2g9T1BMQy0yYTYwCWx0PTQzMjAwMEFacHNvLmRldi5wd3IudiI7aWY9ImNv cmUjcyIsPC9kZXYvdGltZT47dGl0bGU9IlQ0SDMxW1D6dAAAEwAAABMAAACvq6ytrq9C+5+BWoGA mgIA5RsFMzFbUGPaAAA7AAAAOwAAAK+rrK2ur0L7n4FagYCaYdzmAWfxIwD//wAAAmAqAP//AAAC 4JEABRBpbWUiO3J0PSJpcHNvLmRldmpOMzFbUPjpAAATAAAAEwAAAK+rrK2ur0L7n4FagYCaAgDm gDczMVtQhVECAD8AAAA/AAAAr6usra6vQvufgVqBgJph3KABZ2AqAP//AAAC8SMA//8AAAJ81wA/ AAAAAAAAAAHwFjMWMy3MYkQiReBRWiCgMzFbUAlhAgATAAAAEwAAAK+rrK2ur0L7n4FagYCaAgCg shAzMVtQDl8DAIsAAACLAAAAr6usra6vQvufgVqBgJph3OcBZ/EjAP//AAACYCoA//8AAALAkQAG fvUAAAAAAAAAAAHwFjMWM6uZRQIiRhEognJka2g9T1BMQy0yYTYwCWx0PTQzMjAwMEFqLnRpbWUi O2lmPSJjb3JlI3AiLDwvZGV2L3VwdGltZT47dGl0bGU9IlVQVGltZSK7tTMxW1DaZgMAEwAAABMA AACvq6ytrq9C+5+BWoGAmgIA5wkmMzFbUG/IAwA7AAAAOwAAAK+rrK2ur0L7n4FagYCaYdzoAWfx IwD//wAAAmAqAP//AAAC4JEABhA7cnQ9Imlwc28uZGV2LnVwdOOUMzFbUGLYAwATAAAAEwAAAK+r rK2ur0L7n4FagYCaAgDo/t4zMVtQnTcFAD8AAAA/AAAAr6usra6vQvufgVqBgJph3KEBZ2AqAP// AAAC8SMA//8AAAJ81wA/AAAAAAAAAAHwFjMWMx3LYkQiRuBRavYWMzFbUGU/BQATAAAAEwAAAK+r rK2ur0L7n4FagYCaAgChOwEzMVtQVj0GAIsAAACLAAAAr6usra6vQvufgVqBgJph3OkBZ/EjAP// AAACYCoA//8AAALAkQAHfvUAAAAAAAAAAAHwFjMWM4HwRQIiRxEognJka2g9T1BMQy0yYTYwCWx0 PTQzMjAwMEF6aW1lIjtpZj0iY29yZSNzIiw8L2xvYy9zZW0+O3RpdGxlPSJTZW1hbnRpYyI7cnS7 UTMxW1AdRQYAEwAAABMAAACvq6ytrq9C+5+BWoGAmgIA6XfPMzFbUGWXBgBAAAAAQAAAAK+rrK2u r0L7n4FagYCaYdySfBXxJQD//wAAAiwnAP//AAACfvUAAAAAAAAAAAHwt5u3mi/bEQoEAgAAKQqm LJQzMVtQkq4GABMAAAATAAAAr6usra6vQvufgVqBgJoCAJIjAjMxW1A2EAcAOwAAADsAAACvq6yt rq9C+5+BWoGAmmHc6gFn8SMA//8AAAJgKgD//wAAAuCRAAcQPSJpcHNvLmxvYy5zZW0iO2mYMTMx W1CiKwcAEwAAABMAAACvq6ytrq9C+5+BWoGAmgIA6uz9MzFbUNhzCAA/AAAAPwAAAK+rrK2ur0L7 n4FagYCaYdyiAWdgKgD//wAAAvEjAP//AAACfNcAPwAAAAAAAAAB8BYzFjMNymJEIkfgUXqqPjMx W1BpgwgAEwAAABMAAACvq6ytrq9C+5+BWoGAmgIAoqAzMzFbUDmBCQCLAAAAiwAAAK+rrK2ur0L7 n4FagYCaYdzrAWfxIwD//wAAAmAqAP//AAACwJEACH71AAAAAAAAAAAB8BYzFjORIUUCIkgRKIJy ZGtoPU9QTEMtMmE2MAlsdD00MzIwMDBBimY9ImNvcmUjcCIsPC9ncGlvL2Rpbi8wPjt0aXRsZT0i Z3Bpby1kaW4iO3J0PSJpxQMzMVtQD4kJABMAAAATAAAAr6usra6vQvufgVqBgJoCAOtl7DMxW1Bp 9gkAOwAAADsAAACvq6ytrq9C+5+BWoGAmmHc7AFn8SMA//8AAAJgKgD//wAAAuCRAAgQcHNvLmdw aW8uZGluIjtpZj24DDMxW1AQBgoAEwAAABMAAACvq6ytrq9C+5+BWoGAmgIA7NqYMzFbUNJdCwA/ AAAAPwAAAK+rrK2ur0L7n4FagYCaYdyjAWdgKgD//wAAAvEjAP//AAACfNcAPwAAAAAAAAAB8BYz FjP9yGJEIkjgUYqRbDMxW1B+aQsAEwAAABMAAACvq6ytrq9C+5+BWoGAmgIAoykiMzFbUBwhDABk AAAAZAAAAK+rrK2ur0L7n4FagYCaYdztAWfxIwD//wAAAmAqAP//AAACfvUAAAAAAAAAAAHwFjMW M/1yRQIiSREognJka2g9T1BMQy0yYTYwCWx0PTQzMjAwMEGSImNvcmUjcyI7b2Jzu8YzMVtQ0SwM ABMAAAATAAAAr6usra6vQvufgVqBgJoCAO1TiTMxW1AangwAPwAAAD8AAACvq6ytrq9C+5+BWoGA mmHckQEA/yQA//8AAAJrJwD//wAAAn71AAAAAAAAAAAQ8Lebt5qouxEKAA8AVRAA7NEzMVtQtq0M ABMAAAATAAAAr6usra6vQvufgVqBgJoCAJG4MDQxW1CVzAEAYQAAAGEAAACvq6ytrq9C+5+BWoGA mmHcpAFnYCoA//8AAALxIwD//wAAAnzXAD8AAAAAAAAAAfAWMxYzcaNnQSJJJKC8+fQ2ZG9tYWlu EnJkBmRvbWFpbglPUExDLTJhNjAycmShkm9Q --_002_1D0972C5226A7649BBB5E3734FCD593D075F81B4DBXPRD0510MB396_-- From zach@sensinode.com Tue Oct 2 11:42:09 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFDC321F859A for ; Tue, 2 Oct 2012 11:42:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MbWAM4pfsa-p for ; Tue, 2 Oct 2012 11:42:09 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id AF2A421F8522 for ; Tue, 2 Oct 2012 11:42:07 -0700 (PDT) Received: from [192.168.1.102] (87-93-76-196.bb.dnainternet.fi [87.93.76.196]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q92Ig3io004534; Tue, 2 Oct 2012 21:42:04 +0300 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Zach Shelby In-Reply-To: <1D0972C5226A7649BBB5E3734FCD593D075F81B4@DBXPRD0510MB396.eurprd05.prod.outlook.com> Date: Tue, 2 Oct 2012 21:42:01 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1D0972C5226A7649BBB5E3734FCD593D01BB362C@DB3PRD0510MB393.eurprd05.prod.outlook.com> <031DD135F9160444ABBE3B0C36CED618AF380D@011-DB3MPN2-083.MGDPHG.emi.philips.com> <8719175C-AC23-435B-8460-6D0E6913ABA5@tzi.org> <031DD135F9160444ABBE3B0C36CED618AF392E@011-DB3MPN2-083.MGDPHG.emi.philips.com> <031DD135F9160444ABBE3B0C36CED618AF3982@011-DB3MPN2-083.MGDPHG.emi.philips.com> <1D0972C5226A7649BBB5E3734FCD593D075F81B4@DBXPRD0510MB396.eurprd05.prod.outlook.com> To: M Pouillot X-Mailer: Apple Mail (2.1084) Cc: "core@ietf.org" Subject: Re: [core] Block mechanism and size of ressources+query X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 18:42:09 -0000 On Oct 2, 2012, at 7:54 PM, M Pouillot wrote: > Hello Carsten, >=20 > For example during the registration on a RD, a sensor needs to post = all its ressources. In my case it can be represented up to 10 blocks of = 64 Bytes. For each block, we repeat the uri of the RD(not so big) and = the option query of the RD (lifetime, host,...), 25 Bytes for 64 Bytes = of data... =3D> 250 extra Bytes for only one sensor :-( during the = bootstrapping. This is surely a good use case to optimize for as an example. But maybe = not the best use of Block. Why not use 6LoWPAN fragmentation to handle = this? This is what we do in our 6LoWPAN networks to avoid the needed for = very small block sizes.=20 Zach >=20 > cordialement, >=20 > Mathieu >=20 >=20 >=20 > -----Message d'origine----- > De : core-bounces@ietf.org [mailto:core-bounces@ietf.org] De la part = de Dijk, Esko > Envoy=E9 : mardi 2 octobre 2012 16:14 > =C0 : Carsten Bormann > Cc : core@ietf.org > Objet : Re: [core] Block mechanism and size of ressources+query >=20 > For me the basic design is ok, with use of a 'special URI' or simply = short URIs as a way to avoid the issue that Mathieu mentioned. I just = wanted to confirm that overloading Token this way is possible. (Even = though ticket #210 indicates we better not do this.) >=20 > Esko >=20 > -----Original Message----- > From: Carsten Bormann [mailto:cabo@tzi.org] > Sent: Tuesday 2 October 2012 16:02 > To: Dijk, Esko > Cc: Zach Shelby; core@ietf.org > Subject: Re: [core] Block mechanism and size of ressources+query >=20 > On Oct 2, 2012, at 15:30, "Dijk, Esko" wrote: >=20 >> proposed use of Token >=20 > Well, the whole point of ticket #210 was to get rid of such a second = meaning for Token, because we found out it hurts interoperability when = different implementations handle the overloading in a different way. > Instead of overloading Token with this semantics, it is much cleaner = to have something like a special URI or a Teri. >=20 > I think we have a good basic design, I'm just still not convinced we = need the function. > Tell me about the usecase... >=20 > Gr=FC=DFe, Carsten >=20 >=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 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=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 From cabo@tzi.org Tue Oct 2 15:44:44 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1F3421F861E for ; Tue, 2 Oct 2012 15:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.22 X-Spam-Level: X-Spam-Status: No, score=-106.22 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nTjFr-srPk0G for ; Tue, 2 Oct 2012 15:44:44 -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 D3E4F21F8602 for ; Tue, 2 Oct 2012 15:44:41 -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 q92MiXGg000163; Wed, 3 Oct 2012 00:44:33 +0200 (CEST) Received: from [192.168.217.105] (p54892E0F.dip.t-dialin.net [84.137.46.15]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 96BC0C24; Wed, 3 Oct 2012 00:44:32 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <1D0972C5226A7649BBB5E3734FCD593D075F81B4@DBXPRD0510MB396.eurprd05.prod.outlook.com> Date: Wed, 3 Oct 2012 00:44:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1D0972C5226A7649BBB5E3734FCD593D01BB362C@DB3PRD0510MB393.eurprd05.prod.outlook.com> <031DD135F9160444ABBE3B0C36CED618AF380D@011-DB3MPN2-083.MGDPHG.emi.philips.com> <8719175C-AC23-435B-8460-6D0E6913ABA5@tzi.org> <031DD135F9160444ABBE3B0C36CED618AF392E@011-DB3MPN2-083.MGDPHG.emi.philips.com> <031DD135F9160444ABBE3B0C36CED618AF3982@011-DB3MPN2-083.MGDPHG.emi.philips.com> <1D0972C5226A7649BBB5E3734FCD593D075F81B4@DBXPRD0510MB396.eurprd05.prod.outlook.com> To: M Pouillot X-Mailer: Apple Mail (2.1498) Cc: "core@ietf.org" Subject: Re: [core] Block mechanism and size of ressources+query X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 22:44:44 -0000 On Oct 2, 2012, at 18:54, M Pouillot wrote: > Hi Mathieu, thanks for the hard data on this. I wish more people would send in = pcaps when they argue a point! In this case, the resource directory could do the POST/Location-Path = game that we had been discussing. =20 (First POST generates temporary URI to which a blockwise PUT can be = made.) 1 Packet exchange extra, and a change in the resource directory = resources. Or the temporary URI could even be provided in the original /rdr/reg = POST. =20 I don't want to second-guess that protocol here, just point out some = alternatives. Also, I see that you are already fragmenting. Adding in an IPHC context for 2002:db8::1 would save some 8 bytes per = packet. Going to 16-bit addresses might also help. (I'll also use your pcap to get some additional GHC results... Stay = tuned.) But more generally speaking -- how often do these POSTs happen? Is it worth optimizing out those ~ 20 % of one direction of the = exchange? Gr=FC=DFe, Carsten From esko.dijk@philips.com Wed Oct 3 01:05:02 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECD5121F86B6 for ; Wed, 3 Oct 2012 01:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.932 X-Spam-Level: X-Spam-Status: No, score=-3.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4UeBkeOHi2I4 for ; Wed, 3 Oct 2012 01:05:02 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by ietfa.amsl.com (Postfix) with ESMTP id 977F021F86B7 for ; Wed, 3 Oct 2012 01:05:01 -0700 (PDT) Received: from mail91-va3-R.bigfish.com (10.7.14.251) by VA3EHSOBE001.bigfish.com (10.7.40.21) with Microsoft SMTP Server id 14.1.225.23; Wed, 3 Oct 2012 08:05:00 +0000 Received: from mail91-va3 (localhost [127.0.0.1]) by mail91-va3-R.bigfish.com (Postfix) with ESMTP id 10AB5320168; Wed, 3 Oct 2012 08:05:00 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -41 X-BigFish: VPS-41(zz217bL98dI15d6O9251Jc89bhd6eah1b0bI542M1447Izz1202h1d1ah1d2ahzz1033IL8275bh8275dhz2dh2a8h668h839hd25hf0ah107ah1288h12a5h12a9h12bdh137ah13b6h1441h1155h) Received: from mail91-va3 (localhost.localdomain [127.0.0.1]) by mail91-va3 (MessageSwitch) id 1349251498355271_8852; Wed, 3 Oct 2012 08:04:58 +0000 (UTC) Received: from VA3EHSMHS024.bigfish.com (unknown [10.7.14.244]) by mail91-va3.bigfish.com (Postfix) with ESMTP id 481864A0046; Wed, 3 Oct 2012 08:04:58 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by VA3EHSMHS024.bigfish.com (10.7.99.34) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 3 Oct 2012 08:04:57 +0000 Received: from 011-DB3MPN2-083.MGDPHG.emi.philips.com ([169.254.3.124]) by 011-DB3MMR1-007.MGDPHG.emi.philips.com ([10.128.28.57]) with mapi id 14.02.0309.003; Wed, 3 Oct 2012 09:06:28 +0100 From: "Dijk, Esko" To: Carsten Bormann , M Pouillot Thread-Topic: [core] Block mechanism and size of ressources+query Thread-Index: Ac2aZXkYwm8DGNvaSiWLxAwhjt7VJwCL6bbwAPdLOwAAASy1AAAJ7xLA///+xwD//+32wIAAQi2AgABh0gD//1Q2sA== Date: Wed, 3 Oct 2012 08:04:54 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618AF3B33@011-DB3MPN2-083.MGDPHG.emi.philips.com> References: <1D0972C5226A7649BBB5E3734FCD593D01BB362C@DB3PRD0510MB393.eurprd05.prod.outlook.com> <031DD135F9160444ABBE3B0C36CED618AF380D@011-DB3MPN2-083.MGDPHG.emi.philips.com> <8719175C-AC23-435B-8460-6D0E6913ABA5@tzi.org> <031DD135F9160444ABBE3B0C36CED618AF392E@011-DB3MPN2-083.MGDPHG.emi.philips.com> <031DD135F9160444ABBE3B0C36CED618AF3982@011-DB3MPN2-083.MGDPHG.emi.philips.com> <1D0972C5226A7649BBB5E3734FCD593D075F81B4@DBXPRD0510MB396.eurprd05.prod.outlook.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.103] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: "core@ietf.org" Subject: Re: [core] Block mechanism and size of ressources+query X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 08:05:03 -0000 FYI For RD, another tactic is to do a first registration with only part of= the resources. Then, an update of the registration which includes a second part of the res= ources. If needed, a third update etc. until all resources are in the RD. This helps because an update does not need anymore the Uri-Query parameters= , only a short Uri-Path. And it also avoids excessive fragmentation. And it= allows similar to -block to overcome the 1280 bytes limit which link-forma= t descriptions may quickly run into. Esko -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org] Sent: Wednesday 3 October 2012 0:45 To: M Pouillot Cc: Dijk, Esko; core@ietf.org Subject: Re: [core] Block mechanism and size of ressources+query On Oct 2, 2012, at 18:54, M Pouillot wrote: > Hi Mathieu, thanks for the hard data on this. I wish more people would send in pcaps w= hen they argue a point! In this case, the resource directory could do the POST/Location-Path game t= hat we had been discussing. (First POST generates temporary URI to which a blockwise PUT can be made.) 1 Packet exchange extra, and a change in the resource directory resources. Or the temporary URI could even be provided in the original /rdr/reg POST. I don't want to second-guess that protocol here, just point out some altern= atives. Also, I see that you are already fragmenting. Adding in an IPHC context for 2002:db8::1 would save some 8 bytes per packe= t. Going to 16-bit addresses might also help. (I'll also use your pcap to get some additional GHC results... Stay tuned.) But more generally speaking -- how often do these POSTs happen? Is it worth optimizing out those ~ 20 % of one direction of the exchange? 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 m.pouillot@watteco.com Wed Oct 3 23:58:31 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE6F221F8507 for ; Wed, 3 Oct 2012 23:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r2qUE5YJnxhV for ; Wed, 3 Oct 2012 23:58:30 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id 9954C21F84FF for ; Wed, 3 Oct 2012 23:58:30 -0700 (PDT) Received: from mail50-tx2-R.bigfish.com (10.9.14.253) by TX2EHSOBE006.bigfish.com (10.9.40.26) with Microsoft SMTP Server id 14.1.225.23; Thu, 4 Oct 2012 06:58:29 +0000 Received: from mail50-tx2 (localhost [127.0.0.1]) by mail50-tx2-R.bigfish.com (Postfix) with ESMTP id 3ED801400EA; Thu, 4 Oct 2012 06:58:29 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.252.165; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0510HT001.eurprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -91 X-BigFish: VPS-91(zz217bL98dI15d6O9371I9251Jc89bh542M1432I15caKJzz1202h1d1ah1d2ahzz8275ch1033IL17326ah8275bh8275dhz2dh2a8h668h839hd25hf0ah107ah1288h12a5h12a9h12bdh137ah13b6h1441h1155h) Received: from mail50-tx2 (localhost.localdomain [127.0.0.1]) by mail50-tx2 (MessageSwitch) id 1349333906930175_4157; Thu, 4 Oct 2012 06:58:26 +0000 (UTC) Received: from TX2EHSMHS020.bigfish.com (unknown [10.9.14.247]) by mail50-tx2.bigfish.com (Postfix) with ESMTP id DF0D042008D; Thu, 4 Oct 2012 06:58:26 +0000 (UTC) Received: from DBXPRD0510HT001.eurprd05.prod.outlook.com (157.56.252.165) by TX2EHSMHS020.bigfish.com (10.9.99.120) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 4 Oct 2012 06:58:26 +0000 Received: from DBXPRD0510MB396.eurprd05.prod.outlook.com ([169.254.8.245]) by DBXPRD0510HT001.eurprd05.prod.outlook.com ([10.255.67.164]) with mapi id 14.16.0207.009; Thu, 4 Oct 2012 06:58:22 +0000 From: M Pouillot To: Zach Shelby Thread-Topic: [core] Block mechanism and size of ressources+query Thread-Index: Ac2aZXkYwm8DGNvaSiWLxAwhjt7VJwCL6bbwAPljrAAAASy1AAAIqlaAAAEdqAAAAGdqAAAE7UeQAARx9YAAS+3b8A== Date: Thu, 4 Oct 2012 06:58:21 +0000 Message-ID: <1D0972C5226A7649BBB5E3734FCD593D075F960F@DBXPRD0510MB396.eurprd05.prod.outlook.com> References: <1D0972C5226A7649BBB5E3734FCD593D01BB362C@DB3PRD0510MB393.eurprd05.prod.outlook.com> <031DD135F9160444ABBE3B0C36CED618AF380D@011-DB3MPN2-083.MGDPHG.emi.philips.com> <8719175C-AC23-435B-8460-6D0E6913ABA5@tzi.org> <031DD135F9160444ABBE3B0C36CED618AF392E@011-DB3MPN2-083.MGDPHG.emi.philips.com> <031DD135F9160444ABBE3B0C36CED618AF3982@011-DB3MPN2-083.MGDPHG.emi.philips.com> <1D0972C5226A7649BBB5E3734FCD593D075F81B4@DBXPRD0510MB396.eurprd05.prod.outlook.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [82.241.54.131] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: "core@ietf.org" Subject: Re: [core] Block mechanism and size of ressources+query X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 06:58:32 -0000 Hello Zach, 6lowpan fragmentation is not acknowledged from peer to peer... i don't want= send another time all packets just for one loss mathieu=20 -----Message d'origine----- De=A0: Zach Shelby [mailto:zach@sensinode.com]=20 Envoy=E9=A0: mardi 2 octobre 2012 20:42 =C0=A0: M Pouillot Cc=A0: Dijk, Esko; Carsten Bormann; core@ietf.org Objet=A0: Re: [core] Block mechanism and size of ressources+query On Oct 2, 2012, at 7:54 PM, M Pouillot wrote: > Hello Carsten, >=20 > For example during the registration on a RD, a sensor needs to post all i= ts ressources. In my case it can be represented up to 10 blocks of 64 Bytes= . For each block, we repeat the uri of the RD(not so big) and the option qu= ery of the RD (lifetime, host,...), 25 Bytes for 64 Bytes of data... =3D> 2= 50 extra Bytes for only one sensor :-( during the bootstrapping. This is surely a good use case to optimize for as an example. But maybe not= the best use of Block. Why not use 6LoWPAN fragmentation to handle this? T= his is what we do in our 6LoWPAN networks to avoid the needed for very smal= l block sizes.=20 Zach >=20 > cordialement, >=20 > Mathieu >=20 >=20 >=20 > -----Message d'origine----- > De : core-bounces@ietf.org [mailto:core-bounces@ietf.org] De la part=20 > de Dijk, Esko Envoy=E9 : mardi 2 octobre 2012 16:14 =C0 : Carsten Bormann= =20 > Cc : core@ietf.org Objet : Re: [core] Block mechanism and size of=20 > ressources+query >=20 > For me the basic design is ok, with use of a 'special URI' or simply=20 > short URIs as a way to avoid the issue that Mathieu mentioned. I just=20 > wanted to confirm that overloading Token this way is possible. (Even=20 > though ticket #210 indicates we better not do this.) >=20 > Esko >=20 > -----Original Message----- > From: Carsten Bormann [mailto:cabo@tzi.org] > Sent: Tuesday 2 October 2012 16:02 > To: Dijk, Esko > Cc: Zach Shelby; core@ietf.org > Subject: Re: [core] Block mechanism and size of ressources+query >=20 > On Oct 2, 2012, at 15:30, "Dijk, Esko" wrote: >=20 >> proposed use of Token >=20 > Well, the whole point of ticket #210 was to get rid of such a second mean= ing for Token, because we found out it hurts interoperability when differen= t implementations handle the overloading in a different way. > Instead of overloading Token with this semantics, it is much cleaner to h= ave something like a special URI or a Teri. >=20 > I think we have a good basic design, I'm just still not convinced we need= the function. > Tell me about the usecase... >=20 > Gr=FC=DFe, Carsten >=20 >=20 > ________________________________ > The information contained in this message may be confidential and legally= protected under applicable law. The message is intended solely for the add= ressee(s). If you are not the intended recipient, you are hereby notified t= hat any use, forwarding, dissemination, or reproduction of this message is = strictly prohibited and may be unlawful. If you are not the intended recipi= ent, please contact the sender by return e-mail and destroy all copies of t= he original message. >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 > _________________________________________ > ______ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core -- Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From cabo@tzi.org Thu Oct 4 00:38:08 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 937ED21F8645 for ; Thu, 4 Oct 2012 00:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.223 X-Spam-Level: X-Spam-Status: No, score=-106.223 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J1jMjdK5I2NG for ; Thu, 4 Oct 2012 00:38:08 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id CE39321F8630 for ; Thu, 4 Oct 2012 00:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q947bxiW010021; Thu, 4 Oct 2012 09:37:59 +0200 (CEST) Received: from [192.168.217.117] (p54893660.dip.t-dialin.net [84.137.54.96]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id C6274E8B; Thu, 4 Oct 2012 09:37:58 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <1D0972C5226A7649BBB5E3734FCD593D075F960F@DBXPRD0510MB396.eurprd05.prod.outlook.com> Date: Thu, 4 Oct 2012 09:37:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3BC576D7-469A-43EE-8D5D-CCD6A6EBBB33@tzi.org> References: <1D0972C5226A7649BBB5E3734FCD593D01BB362C@DB3PRD0510MB393.eurprd05.prod.outlook.com> <031DD135F9160444ABBE3B0C36CED618AF380D@011-DB3MPN2-083.MGDPHG.emi.philips.com> <8719175C-AC23-435B-8460-6D0E6913ABA5@tzi.org> <031DD135F9160444ABBE3B0C36CED618AF392E@011-DB3MPN2-083.MGDPHG.emi.philips.com> <031DD135F9160444ABBE3B0C36CED618AF3982@011-DB3MPN2-083.MGDPHG.emi.philips.com> <1D0972C5226A7649BBB5E3734FCD593D075F81B4@DBXPRD0510MB396.eurprd05.prod.outlook.com> <1D0972C5226A7649BBB5E3734FCD593D075F960F@DBXPRD0510MB396.eurprd05.prod.outlook.com> To: M Pouillot X-Mailer: Apple Mail (2.1498) Cc: "core@ietf.org" Subject: Re: [core] Block mechanism and size of ressources+query X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 07:38:08 -0000 Well, you already are fragmenting. If you go from 64 to 128, your = request blocks still fit in two fragments each, but you have halved your = overhead. > 6lowpan fragmentation is not acknowledged from peer to peer... i don't = want send another time all packets just for one loss I don't know who the peers are here, but you can (and should) have = hop-by-hop ACKs for frames both carrying unfragmented packets and = fragments. (I actually see those ACKs in your pcap, so you seem to be using them.) Do you have actual measurements that show a problem (with reasonable = numbers of fragments per packet, like, 2)? Gr=FC=DFe, Carsten From m.pouillot@watteco.com Thu Oct 4 01:00:24 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B91D821F8650 for ; Thu, 4 Oct 2012 01:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.399 X-Spam-Level: X-Spam-Status: No, score=-4.399 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5+MZpRKTFsGT for ; Thu, 4 Oct 2012 01:00:24 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe006.messaging.microsoft.com [213.199.154.209]) by ietfa.amsl.com (Postfix) with ESMTP id A3ED321F861F for ; Thu, 4 Oct 2012 01:00:23 -0700 (PDT) Received: from mail63-am1-R.bigfish.com (10.3.201.242) by AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id 14.1.225.23; Thu, 4 Oct 2012 08:00:21 +0000 Received: from mail63-am1 (localhost [127.0.0.1]) by mail63-am1-R.bigfish.com (Postfix) with ESMTP id A6BB62A0184; Thu, 4 Oct 2012 08:00:21 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.252.165; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0510HT005.eurprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -72 X-BigFish: VPS-72(zz98dIc89bh15caKJ1447Izz1202h1d1ah1d2ahzz1033IL8275bh8275dhz2dh2a8h668h839hd25hf0ah107ah1288h12a5h12a9h12bdh137ah13b6h1441h1155h) Received: from mail63-am1 (localhost.localdomain [127.0.0.1]) by mail63-am1 (MessageSwitch) id 1349337619131825_16103; Thu, 4 Oct 2012 08:00:19 +0000 (UTC) Received: from AM1EHSMHS018.bigfish.com (unknown [10.3.201.228]) by mail63-am1.bigfish.com (Postfix) with ESMTP id 1168A4018C; Thu, 4 Oct 2012 08:00:19 +0000 (UTC) Received: from DBXPRD0510HT005.eurprd05.prod.outlook.com (157.56.252.165) by AM1EHSMHS018.bigfish.com (10.3.207.156) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 4 Oct 2012 08:00:18 +0000 Received: from DBXPRD0510MB396.eurprd05.prod.outlook.com ([169.254.8.245]) by DBXPRD0510HT005.eurprd05.prod.outlook.com ([10.255.67.168]) with mapi id 14.16.0207.009; Thu, 4 Oct 2012 08:00:10 +0000 From: M Pouillot To: Carsten Bormann Thread-Topic: [core] Block mechanism and size of ressources+query Thread-Index: Ac2aZXkYwm8DGNvaSiWLxAwhjt7VJwCL6bbwAPljrAAAASy1AAAIqlaAAAEdqAAAAGdqAAAE7UeQAAzp7QAARMwxAA== Date: Thu, 4 Oct 2012 08:00:10 +0000 Message-ID: <1D0972C5226A7649BBB5E3734FCD593D075F967E@DBXPRD0510MB396.eurprd05.prod.outlook.com> References: <1D0972C5226A7649BBB5E3734FCD593D01BB362C@DB3PRD0510MB393.eurprd05.prod.outlook.com> <031DD135F9160444ABBE3B0C36CED618AF380D@011-DB3MPN2-083.MGDPHG.emi.philips.com> <8719175C-AC23-435B-8460-6D0E6913ABA5@tzi.org> <031DD135F9160444ABBE3B0C36CED618AF392E@011-DB3MPN2-083.MGDPHG.emi.philips.com> <031DD135F9160444ABBE3B0C36CED618AF3982@011-DB3MPN2-083.MGDPHG.emi.philips.com> <1D0972C5226A7649BBB5E3734FCD593D075F81B4@DBXPRD0510MB396.eurprd05.prod.outlook.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [82.241.54.131] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: "core@ietf.org" Subject: Re: [core] Block mechanism and size of ressources+query X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 08:00:24 -0000 Hi Carsten, inline cordialement, Mathieu -----Message d'origine----- De=A0: Carsten Bormann [mailto:cabo@tzi.org]=20 Envoy=E9=A0: mercredi 3 octobre 2012 00:44 =C0=A0: M Pouillot Cc=A0: Dijk, Esko; core@ietf.org Objet=A0: Re: [core] Block mechanism and size of ressources+query On Oct 2, 2012, at 18:54, M Pouillot wrote: > Hi Mathieu, thanks for the hard data on this. I wish more people would send in pcaps w= hen they argue a point! In this case, the resource directory could do the POST/Location-Path game t= hat we had been discussing. =20 (First POST generates temporary URI to which a blockwise PUT can be made.) 1 Packet exchange extra, and a change in the resource directory resources. Or the temporary URI could even be provided in the original /rdr/reg POST. = =20 I don't want to second-guess that protocol here, just point out some altern= atives. > could be interesting. I don't know if the RD allows that... What is defin= ed in RD, does it keep the query context of the last POST? Also, I see that you are already fragmenting. Adding in an IPHC context for 2002:db8::1 would save some 8 bytes per packe= t. > aaaah! we can have more than one context, I need to read more precisely t= he RFC :-) =20 Going to 16-bit addresses might also help. > we need to work on that :-) (I'll also use your pcap to get some additional GHC results... Stay tuned.) But more generally speaking -- how often do these POSTs happen? > in our case for the moment, just one time at the bootstrapping for each n= ode on the network to one RD. =20 Is it worth optimizing out those ~ 20 % of one direction of the exchange? > it is always interesting to optimise. In our case we run in solar power a= limentation, so all little gain to not send some data is indispensable. Gr=FC=DFe, Carsten From valerio.digregorio@Intecs.it Thu Oct 4 01:34:49 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE80221F8622 for ; Thu, 4 Oct 2012 01:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.882 X-Spam-Level: * X-Spam-Status: No, score=1.882 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, WEIRD_PORT=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBJKtUAu8Pzm for ; Thu, 4 Oct 2012 01:34:48 -0700 (PDT) Received: from mail.intecs.it (mail.intecs.it [78.7.240.11]) by ietfa.amsl.com (Postfix) with ESMTP id 7534F21F8621 for ; Thu, 4 Oct 2012 01:34:47 -0700 (PDT) thread-index: Ac2iCuPmoHqSrh12SQSfpe5TnBNn4w== Received: from [127.0.0.1] ([192.168.27.80]) by mail.intecs.it with Microsoft SMTPSVC(6.0.3790.4675); Thu, 4 Oct 2012 10:33:11 +0200 Message-ID: <506D4A30.6010704@intecs.it> Date: Thu, 04 Oct 2012 10:34:56 +0200 From: "Valerio Di Gregorio" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 Content-Class: urn:content-classes:message Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 MIME-Version: 1.0 To: Content-Type: text/plain; format=flowed; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable X-Antivirus: avast! (VPS 121003-1, 03/10/2012), Outbound message X-Antivirus-Status: Clean X-OriginalArrivalTime: 04 Oct 2012 08:33:12.0037 (UTC) FILETIME=[E3E43950:01CDA20A] Subject: [core] Block-wise transfer late negotiation and unrecognized critical options X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 08:34:49 -0000 Dear all, I want to share with you my problem. Intecs CoAP implementation supports = resource discovery but it does not support the block-wise transfer. In a = late negotiation scenario (i.e. GET=20 coap://vs0.inf.ethz.ch:5683/.well-known/core) Intecs client fails=20 receiving a Block2 (#17) option from the server. It is OK because option = 17 is an unrecognised critical option for the client. The question is: can the server use the block-wise transfer when it is=20 not strictly needed? In my opinion if the request does not contain a Block2 option, the=20 server can not assume block-wise transfer supported by the client and=20 avoid it. By the way in some cases (i.e. payload too long, not enough=20 resources, security reasons, etc.) a late negotiation attempt is still=20 better than an error code. From my point of view late negotiation should = be a "last resort solution". BR, Valerio --=20 Valerio Di Gregorio Automotive and Telecommunication Division Software Engineer INTECS Informatica e Tecnologia del Software S.p.A. Via Umberto Forti, 5 Polo di attivit=E0 di Montacchiello 56121 Ospedaletto, Pisa Italy LEGAL DISCLAIMER: The contents of this email and any transmitted files are confidential = and intended solely for the use of the individual or entity to whom they = are addressed. We hereby exclude any warranty and any liability as to = the quality or accuracy of the contents of this email and any attached = transmitted files. If you are not the intended recipient, be advised = that you have received this email in error and that any use, = dissemination, forwarding, printing or copying of this email is strictly = prohibited. If you have received this email in error please contact the = sender and delete the material from any computer. From isam.ishaq@intec.ugent.be Thu Oct 4 05:28:43 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F61921F85EA for ; Thu, 4 Oct 2012 05:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9YkFTlZAm-xW for ; Thu, 4 Oct 2012 05:28:42 -0700 (PDT) Received: from smtp2.ugent.be (smtp2.ugent.be [157.193.49.126]) by ietfa.amsl.com (Postfix) with ESMTP id CA79421F85AC for ; Thu, 4 Oct 2012 05:28:41 -0700 (PDT) Received: from localhost (mcheck2.ugent.be [157.193.49.249]) by smtp2.ugent.be (Postfix) with ESMTP id AD09E12C181; Thu, 4 Oct 2012 14:28:40 +0200 (CEST) X-Virus-Scanned: by UGent DICT Received: from smtp2.ugent.be ([157.193.49.126]) by localhost (mcheck2.UGent.be [157.193.43.11]) (amavisd-new, port 10024) with ESMTP id 2uDas6zQbgK0; Thu, 4 Oct 2012 14:28:40 +0200 (CEST) Received: from mail2.intec.ugent.be (mail2.intec.ugent.be [157.193.214.245]) by smtp2.ugent.be (Postfix) with ESMTP id 283A212C153; Thu, 4 Oct 2012 14:28:40 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail2.intec.ugent.be (Postfix) with ESMTP id 2AF6D20; Thu, 4 Oct 2012 14:28:40 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at intec.ugent.be Received: from mail2.intec.ugent.be ([127.0.0.1]) by localhost (mail2.intec.ugent.be [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVmhp2+j+32K; Thu, 4 Oct 2012 14:28:40 +0200 (CEST) Received: from [127.0.0.1] (visitors.ibbt.be [193.191.148.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: iishaq) by mail2.intec.ugent.be (Postfix) with ESMTPSA id 062021F; Thu, 4 Oct 2012 14:28:40 +0200 (CEST) Message-ID: <506D80F9.4030607@intec.ugent.be> Date: Thu, 04 Oct 2012 14:28:41 +0200 From: Isam Ishaq User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Bert Greevenbosch References: <46A1DF3F04371240B504290A071B4DB628FDC067@szxeml509-mbx> In-Reply-To: <46A1DF3F04371240B504290A071B4DB628FDC067@szxeml509-mbx> Content-Type: multipart/alternative; boundary="------------060506010907080703070307" X-Miltered: at jchkm1 with ID 506D80F8.000 by Joe's j-chkmail (http://helpdesk.ugent.be/email/)! X-j-chkmail-Enveloppe: 506D80F8.000 from mail2.intec.ugent.be/mail2.intec.ugent.be/157.193.214.245/mail2.intec.ugent.be/ X-j-chkmail-Score: MSGID : 506D80F8.000 on smtp2.ugent.be : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Cc: "core@ietf.org" Subject: Re: [core] Upload of Profile Description Format draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 12:28:43 -0000 This is a multi-part message in MIME format. --------------060506010907080703070307 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear Bert, Thank you for submitting the profile draft. We have been experimenting with the idea of resources profiles for some time and think this idea is worth further extension. One suggestion that we have is related to the interface of the profile. In the draft you propose to use a "/p" suffix to contain the profiles of the resources on the server. This means that the /p resource should be reserved , which can be confusing. Instead of using the /p suffix we suggest to create one new well-known resource on the server for example ".well-known/profile". This avoids the need to reserve /p as a resource. By sending a GET to .well-known/profile a client can get the CoAP capabilities of the server (some capabilities are server specific, others resource specific). We would like a solution to support both. Current draft is only about resource specific capabilities. To get the profile description of a particular resource on the server the coap query-option should be used. For example, the profile description of the sensor "coap://www.example.org/s/tmp" should be acquired with a GET to: "coap://www.example.org/.well-known/profile?path=/s/tmp". By using the query-option new capabilities are added to the profile. A client can for example also do a GET to: "coap://www.example.org/.well-known/profile?mt=mt1" in order to get a list of all resource that support mt1 as a media type. Best Regards,, Jeroen Hoebeke and Isam Ishaq On 12-Jun-12 3:16 AM, Bert Greevenbosch wrote: > > Hi all, > > I have just uploaded a draft concerning a "Profile Description Format": > > http://datatracker.ietf.org/doc/draft-greevenbosch-core-profile-description > > The draft proposes a JSON based format to express which capabilities > the server supports. Currently the draft proposes signalling for > supported options and media types. > > The draft is in quite an initial state, but I have already uploaded it > to receive comments on the proposal. Section 8 contains a > non-exhaustive list of issues that require more attention. > > Your comments will be appreciated! > > Best regards, > > Bert > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core -- Isam Ishaq Department of Information Technology Internet Based Communication Networks and Services (IBCN) Ghent University - IBBT Gaston Crommenlaan 8 (Bus 201), B-9050 Gent, Belgium M: +32 484 856 155 T Secr: +32 (0)9 33 14900 F: +32 (0)9 33 14899 E: isam.ishaq@intec.UGent.be W : www.ibcn.intec.UGent.be --------------060506010907080703070307 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Dear Bert,

Thank you for submitting the profile draft. We have been experimenting with the idea of resources profiles for some time and think this idea is worth further extension.

One suggestion that we have is related to the interface of the profile. In the draft you propose to use a "/p" suffix to contain the profiles of the resources on the server. This means that the /p resource should be reserved , which can be confusing.

Instead of using the /p suffix we suggest to create one new well-known resource on the server for example ".well-known/profile". This avoids the need to reserve /p as a resource.
By sending a GET to .well-known/profile a client can get the CoAP capabilities of the server (some capabilities are server specific, others resource specific). We would like a solution to support both. Current draft is only about resource specific capabilities.
To get the profile description of a particular resource on the server the coap query-option should be used. For example, the profile description of the sensor "coap://www.example.org/s/tmp" should be acquired with a GET to: "coap://www.example.org/.well-known/profile?path=/s/tmp".
By using the query-option new capabilities are added to the profile. A client can for example also do a GET to: "coap://www.example.org/.well-known/profile?mt=mt1" in order to get a list of all resource that support mt1 as a media type.

Best Regards,,
Jeroen Hoebeke and Isam Ishaq

On 12-Jun-12 3:16 AM, Bert Greevenbosch wrote:

Hi all,

 

I have just uploaded a draft concerning a "Profile Description Format":

http://datatracker.ietf.org/doc/draft-greevenbosch-core-profile-description

 

The draft proposes a JSON based format to express which capabilities the server supports. Currently the draft proposes signalling for supported options and media types.

 

The draft is in quite an initial state, but I have already uploaded it to receive comments on the proposal. Section 8 contains a non-exhaustive list of issues that require more attention.

 

Your comments will be appreciated!

 

Best regards,

Bert

 



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



-- 
Isam Ishaq
Department of Information Technology
Internet Based Communication Networks and Services (IBCN)
Ghent University - IBBT 
Gaston Crommenlaan 8 (Bus 201), B-9050 Gent, Belgium
M: +32 484 856 155
T Secr: +32 (0)9 33 14900
F: +32 (0)9 33 14899
E: isam.ishaq@intec.UGent.be
W : www.ibcn.intec.UGent.be
--------------060506010907080703070307-- From cabo@tzi.org Thu Oct 4 15:09:32 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87EDD21F8589; Thu, 4 Oct 2012 15:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.223 X-Spam-Level: X-Spam-Status: No, score=-106.223 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9WRXWDj-3qu1; Thu, 4 Oct 2012 15:09:31 -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 4BD1621F8588; Thu, 4 Oct 2012 15:09:30 -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 q94M9NtP022650; Fri, 5 Oct 2012 00:09:23 +0200 (CEST) Received: from [192.168.217.117] (p548920DE.dip.t-dialin.net [84.137.32.222]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 65763311; Fri, 5 Oct 2012 00:09:23 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Fri, 5 Oct 2012 00:09:22 +0200 To: "lwip@ietf.org" , "core@ietf.org WG" , roll WG , "6lowpan@ietf.org" <6lowpan@ietf.org> Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) X-Mailer: Apple Mail (2.1498) Subject: [core] Constrained Node/Network Cluster @ IETF85 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 22:09:32 -0000 Here is my usual eclectic condensed agenda. I'm sure we'll have a lot of ad-hoc meetings, too, but these are the = current WG meeting that could be considered part of a Constrained = Node/Network Cluster (or might impact it). As you can see, lwig is currently on top of Friday's core meeting, and = that will have to change. Apart from that, the damage seems to be limited this time, at least = before the usual round of swaps. See you all in Atlanta! Gr=FC=DFe, Carsten MONDAY, November 5, 2012 0900-1130 Morning Session I Salon A APP apparea Applications Area Open Meeting = - Combined with APPSAWG Salon D INT 6man IPv6 Maintenance WG 1300-1500 Afternoon Session I GrBlrm C INT intarea Internet Area Working Group WG 1520-1720 Afternoon Session II Salon C RTG roll Routing Over Low power and Lossy = networks WG GrBlrm D TSV tsvarea Transport Area Open Meeting=20 TUESDAY, November 6, 2012 0900-1130 Morning Session I Salon E APP httpbis Hypertext Transfer Protocol Bis = WG GrBlrm D INT homenet Home Networking WG 1300-1500 Afternoon Session I GrBlrm C APP core Constrained RESTful Environments = WG WEDNESDAY, November 7, 2012 0900-1130 Morning Session I Salon A SEC jose Javascript Object Signing and = Encryption WG 1300-1430 Afternoon Session I GrBlrm D SEC httpauth HTTP Authentication Mechanisms = BOF THURSDAY, November 8, 2012 0900-1130 Morning Session I Salon A SEC oauth Web Authorization Protocol WG 1300-1500 Afternoon Session I GrBlrm D RTG rtgarea Routing Area Open Meeting=20 Salon E TSV rmcat RTP Media Congestion Avoidance = Techniques WG 1510-1710 Afternoon Session II Salon A OPS eman Energy Management WG GrBlrm C TSV tsvwg Transport Area Working Group WG Salon C SEC saag Security Area Open Meeting=20 FRIDAY, November 9, 2012 0900-1100 Morning Session I Salon D TSV tsvwg Transport Area Working Group WG 1120-1220 Afternoon Session I Salon E APP core Constrained RESTful Environments = WG Salon C INT lwig Light-Weight Implementation = Guidance WG 1230-1330 Afternoon Session II Salon E APP core Constrained RESTful Environments = WG Salon C INT lwig Light-Weight Implementation = Guidance WG From barryleiba.mailing.lists@gmail.com Thu Oct 4 15:36:24 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A17B521F8545 for ; Thu, 4 Oct 2012 15:36:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.058 X-Spam-Level: X-Spam-Status: No, score=-103.058 tagged_above=-999 required=5 tests=[AWL=-0.082, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PqPRajU7eFJO for ; Thu, 4 Oct 2012 15:36:23 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id EAA5C21F84DC for ; Thu, 4 Oct 2012 15:36:22 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so925047lbo.31 for ; Thu, 04 Oct 2012 15:36:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=8JnlSv0TmEK+9B5zr5aRo84MtWG8TNklKDLOs4KQn+g=; b=xiiW432IpLpptq0FkMJlK3wBjxHfUHiNc6NyzoMgYWKazm5BvHMrmKO5+6LJy50wV9 yNfm0+DYLQjnT1oktI6042w0GS/a5EVzM3DNgsy45IVaVnhxhVxGajfV9vvrdSHM0Wrf udBalAZMl5iGvS3pmPmJ/3/waWP8C1o/8r2+C5y7OCqCdZyQeexxkYaLeHGM5dUYmVhB rkXNw++pGVkG/RDg/8w4O2p4CW08amoD9CilnGduNpA+L1cZZgp+NDy6ynPF0Zy00ceZ Nl2j/dFVQxCi+G2nBtrppEt/o1JiTSWR4/WzWzlWrb/ey5wMj4HOhLwZACnH7iJWfjGp u2QA== MIME-Version: 1.0 Received: by 10.112.8.4 with SMTP id n4mr3319727lba.38.1349390181876; Thu, 04 Oct 2012 15:36:21 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.150.194 with HTTP; Thu, 4 Oct 2012 15:36:21 -0700 (PDT) In-Reply-To: References: Date: Thu, 4 Oct 2012 18:36:21 -0400 X-Google-Sender-Auth: T9PpIPbXKQ2WJ_X6l6vnM3AwGZs Message-ID: From: Barry Leiba To: Carsten Bormann Content-Type: multipart/alternative; boundary=90e6ba3094e274450504cb4362b2 Cc: "core@ietf.org WG" Subject: Re: [core] Constrained Node/Network Cluster @ IETF85 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 22:36:24 -0000 --90e6ba3094e274450504cb4362b2 Content-Type: text/plain; charset=ISO-8859-1 > As you can see, lwig is currently on top of Friday's core meeting, and that will have to change. Yes, and I'll see what I can do about that. It's hard to move core... I'll see if it's possible to move lwig. Barry --90e6ba3094e274450504cb4362b2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > As you can see, lwig is currently on top of Friday's core meeting,= and that will have to change.

Yes, and I'll see what I can do a= bout that. =A0It's hard to move core... I'll see if it's possib= le to move lwig.

Barry --90e6ba3094e274450504cb4362b2-- From trac+core@trac.tools.ietf.org Fri Oct 5 01:54:18 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F1EE21F861B for ; Fri, 5 Oct 2012 01:54:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYr0EYDT5n6j for ; Fri, 5 Oct 2012 01:54:17 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id BA78B21F861C for ; Fri, 5 Oct 2012 01:54:17 -0700 (PDT) Received: from localhost ([127.0.0.1]:38404 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TK3fT-0004Ug-Uj; Fri, 05 Oct 2012 10:53:59 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Fri, 05 Oct 2012 08:53:59 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/247 Message-ID: <060.165feff053c11cfa0d65de452eb53ed9@trac.tools.ietf.org> X-Trac-Ticket-ID: 247 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: brian@skyfoundry.com, cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20121005085417.BA78B21F861C@ietfa.amsl.com> Resent-Date: Fri, 5 Oct 2012 01:54:17 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #247: Scalability question IANA reviewer for IPv4 multicast address request 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: Fri, 05 Oct 2012 08:54:18 -0000 #247: Scalability question IANA reviewer for IPv4 multicast address request The request for a global "All CoAP Nodes" IPv4 multicast address lead to the following question from the IANA designated expert: "Have they considered how this may work in sites with Internet multicast connectivity. E.g. there is multicast connectivity between thousands of universities. Do you want a node in one domain to reach all CoAP in all other domains across the Internet? Does this scale? Are there any security considerations?" It is not clear from the current CoAP draft how this issue should be addressed. 1) if we follow the guideline that unauthenticated multicast SHOULD NOT be accepted by a server, discovery won't work in typical cases because devices are not mutually authenticated in initial discovery situations. 2) if we state that we won't use this MC address for discovery purposes, we don't need the multicast address registration in the first place. -- -----------------------------+------------------------------------ Reporter: esko.dijk@… | Owner: draft-ietf-core-coap@… Type: protocol defect | Status: new Priority: major | Milestone: post-WGLC-1 Component: coap | Version: Severity: - | Keywords: -----------------------------+------------------------------------ Ticket URL: core From cabo@tzi.org Sun Oct 7 02:32:35 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33DD921F8522; Sun, 7 Oct 2012 02:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.924 X-Spam-Level: X-Spam-Status: No, score=-105.924 tagged_above=-999 required=5 tests=[AWL=-0.275, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ADCXvlu727Zk; Sun, 7 Oct 2012 02:32:34 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 4D4D921F8514; Sun, 7 Oct 2012 02:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q979WP7i026511; Sun, 7 Oct 2012 11:32:25 +0200 (CEST) Received: from [192.168.217.105] (p54891E9D.dip.t-dialin.net [84.137.30.157]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 475A688A; Sun, 7 Oct 2012 11:32:25 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Carsten Bormann In-Reply-To: Date: Sun, 7 Oct 2012 11:32:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "lwip@ietf.org" , "core@ietf.org WG" , roll WG , "6lowpan@ietf.org" <6lowpan@ietf.org> X-Mailer: Apple Mail (2.1498) Subject: Re: [core] [6lowpan] Constrained Node/Network Cluster @ IETF85 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, 07 Oct 2012 09:32:35 -0000 On Oct 5, 2012, at 00:09, Carsten Bormann wrote: > Here is my usual eclectic condensed agenda. ... and here is an update based on yesterday's changes. As you can see, the lwig/core overlap is fixed (thanks, Barry), and = there have been a few other relocations to avoid other conflicts. Gr=FC=DFe, Carsten MONDAY, November 5, 2012 0900-1130 Morning Session I Salon A APP apparea Applications Area Open Meeting - Combined with = APPSAWG Salon D INT 6man IPv6 Maintenance WG 1300-1500 Afternoon Session I Salon D APP httpbis Hypertext Transfer Protocol Bis WG Grand C INT intarea Internet Area Working Group WG 1520-1720 Afternoon Session II Salon C RTG *** roll Routing Over Low power and Lossy networks WG Grand D TSV tsvarea Transport Area Open Meeting 1740-1940 Afternoon Session III Salon E INT *** lwig Light-Weight Implementation Guidance WG TUESDAY, November 6, 2012 0900-1130 Morning Session I Salon E APP httpbis Hypertext Transfer Protocol Bis WG 1300-1500 Afternoon Session I Grand C APP *** core Constrained RESTful Environments WG WEDNESDAY, November 7, 2012 0900-1130 Morning Session I Salon D INT homenet Home Networking WG Salon A SEC jose Javascript Object Signing and Encryption WG 1300-1430 Afternoon Session I Grand D SEC httpauth HTTP Authentication Mechanisms BOF THURSDAY, November 8, 2012 0900-1130 Morning Session I Salon A SEC oauth Web Authorization Protocol WG 1300-1500 Afternoon Session I Salon D OPS v6ops IPv6 Operations WG Grand D RTG rtgarea Routing Area Open Meeting Salon E TSV rmcat RTP Media Congestion Avoidance Techniques WG 1510-1710 Afternoon Session II Salon A OPS eman Energy Management WG Salon D OPS v6ops IPv6 Operations WG Salon C SEC saag Security Area Open Meeting Grand C TSV tsvwg Transport Area Working Group WG FRIDAY, November 9, 2012 0900-1100 Morning Session I Salon D TSV tsvwg Transport Area Working Group WG 1120-1330 Afternoon Session I/II Salon E APP *** core Constrained RESTful Environments WG From Berta.Carballido@cit.ie Mon Oct 8 04:54:49 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9849921F855B for ; Mon, 8 Oct 2012 04:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gXUd3XlGxINm for ; Mon, 8 Oct 2012 04:54:47 -0700 (PDT) Received: from mx-1.cit.ie (mx-1.cit.ie [157.190.3.45]) by ietfa.amsl.com (Postfix) with ESMTP id 15DC021F8552 for ; Mon, 8 Oct 2012 04:54:46 -0700 (PDT) X-ASG-Debug-ID: 1349696872-019f2807f323c90001-aa7cYp Received: from CITMAIL.cit.ie ([157.190.22.71]) by mx-1.cit.ie with ESMTP id 3bolZpuDivd1JfxB; Mon, 08 Oct 2012 12:47:52 +0100 (IST) X-Barracuda-Envelope-From: Berta.Carballido@cit.ie X-Barracuda-Apparent-Source-IP: 157.190.22.71 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CDA54A.B693B0B1" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 8 Oct 2012 12:47:36 +0100 X-ASG-Orig-Subj: Service and Resource Discovery Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Service and Resource Discovery Thread-Index: Ac2lR/xAlR35FkBsSgWUjJs8hHeC9Q== From: "Berta Carballido" To: X-Barracuda-Connect: UNKNOWN[157.190.22.71] X-Barracuda-Start-Time: 1349696872 X-Barracuda-URL: http://157.190.3.45:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at cit.ie X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=6.0 tests=BSF_SC0_MISMATCH_TO, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.110751 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 0.00 HTML_MESSAGE BODY: HTML included in message Subject: [core] Service and Resource Discovery X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 11:54:49 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CDA54A.B693B0B1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello all, =20 I was reading the main CoAP draft and I noticed that the abstract mentions that CoAP supports built-in discovery of services and Resources. Sections 7.1 and 7.2 seem to make a distinction between service and resource discovery, although the difference between both is unclear after reading them. =20 Moreover, in Section 8, both terms seem to refer to the same concept:=20 =20 "CoAP endpoints that offer services that they want other endpoints to be able to find using multicast service discovery, join one or more of the appropriate all-CoAP-nodes multicast addresses Section 12.8 and listen on the default CoAP port."=20 =20 Is multicast service discovery referring in that phrase to multicast resource discovery as defined in RFC6690? =20 In summary, should a distinction be made with CoAP between service discovery and resource discovery? =20 Kind Regards, =20 Berta. =20 ------_=_NextPart_001_01CDA54A.B693B0B1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello = all,

 

I was reading the main CoAP draft and I noticed that = the abstract mentions that CoAP supports built-in discovery of services = and Resources. Sections 7.1 and 7.2 seem to make a distinction between = service and resource discovery, although the difference between both is = unclear after reading them.

 

Moreover, in = Section 8, both terms seem to refer to the same concept: =

 

“CoAP endpoints that offer services that they = want other endpoints to be able to find using multicast service = discovery, join one or more of the appropriate all-CoAP-nodes = multicast addresses Section 12.8 and listen on the default CoAP = port.”

 

Is multicast service discovery referring in = that phrase to multicast resource discovery as defined in = RFC6690?

 

In summary, should a distinction be made with CoAP = between service discovery and resource discovery?

 

Kind = Regards,

 

Berta.

 

------_=_NextPart_001_01CDA54A.B693B0B1-- From Gerald.Paprocki@us.elster.com Mon Oct 8 12:07:32 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D5E01F040A for ; Mon, 8 Oct 2012 12:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.789 X-Spam-Level: X-Spam-Status: No, score=-5.789 tagged_above=-999 required=5 tests=[AWL=0.810, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id noI4PC47RlRO for ; Mon, 8 Oct 2012 12:07:31 -0700 (PDT) Received: from mail136.messagelabs.com (mail136.messagelabs.com [216.82.249.3]) by ietfa.amsl.com (Postfix) with SMTP id 916D61F041F for ; Mon, 8 Oct 2012 12:07:31 -0700 (PDT) X-Env-Sender: Gerald.Paprocki@us.elster.com X-Msg-Ref: server-13.tower-136.messagelabs.com!1349723249!7451376!1 X-Originating-IP: [129.179.1.27] X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16393 invoked from network); 8 Oct 2012 19:07:29 -0000 Received: from ip27.net129179-1.block1.us.syntegra.com (HELO us-smtp01.smtp.elster.com) (129.179.1.27) by server-13.tower-136.messagelabs.com with SMTP; 8 Oct 2012 19:07:29 -0000 Auto-Submitted: auto-generated From: Gerald.Paprocki@us.elster.com To: core@ietf.org Message-ID: Date: Mon, 8 Oct 2012 15:07:34 -0400 X-MIMETrack: Serialize by Router on US-SMTP01.domino.elster-group.com/RIM-TEMP(Release 8.5.2FP3|July 10, 2011) at 10/08/2012 02:59:18 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [core] AUTO: Gerald Paprocki is out of the office (returning 10/15/2012) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 19:07:32 -0000 I am out of the office until 10/15/2012. I am out of the office and will be returning Monday 15th. If assistance is required during my absence please contact one of my primes below. - IP AxisLink Secure Tunnel server - Inyong Park @ 919-250-5698 - EA_MS Interfaces - Bill Phillips @ 919-212-4888 - EA Inspector - Ying Xu @ 919-250-5446 Note: This is an automated response to your message "core Digest, Vol 33, Issue 8" sent on 10/8/2012 3:00:28 PM. This is the only notification you will receive while this person is away. From oleksiy.ju.mazhelis@jyu.fi Tue Oct 9 00:09:48 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD5A821F86F7 for ; Tue, 9 Oct 2012 00:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L4z-ODy7h38b for ; Tue, 9 Oct 2012 00:09:48 -0700 (PDT) Received: from posti6.jyu.fi (posti6.jyu.fi [130.234.4.43]) by ietfa.amsl.com (Postfix) with ESMTP id D8CC121F86BE for ; Tue, 9 Oct 2012 00:09:40 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by posti6.jyu.fi (8.13.8/8.13.8) with ESMTP id q9979cmx009490 for ; Tue, 9 Oct 2012 10:09:38 +0300 X-Virus-Scanned: amavisd-new at cc.jyu.fi Received: from posti6.jyu.fi ([127.0.0.1]) by localhost (posti6.jyu.fi [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id seLfepTH++-t for ; Tue, 9 Oct 2012 10:09:38 +0300 (EEST) Received: from exmail.jyu.fi (cas1.ad.jyu.fi [130.234.8.8]) by posti6.jyu.fi (8.13.8/8.13.8) with ESMTP id q9979bki009486 for ; Tue, 9 Oct 2012 10:09:38 +0300 Received: from MBS1.ad.jyu.fi ([169.254.1.133]) by cas1.ad.jyu.fi ([2002:82ea:808::82ea:808]) with mapi id 14.02.0318.001; Tue, 9 Oct 2012 10:09:37 +0300 From: Mazhelis Oleksiy To: "core@ietf.org" Thread-Topic: Maximum number of nodes served by a single access point Thread-Index: Ac2l7Hgpw8zFn31HT5S8sf3204ZKtg== Date: Tue, 9 Oct 2012 07:09:37 +0000 Message-ID: Accept-Language: en-US, fi-FI Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.234.164.146] Content-Type: multipart/alternative; boundary="_000_C5426A3354D68540AC53DE5236E400D719E3B8F7mbs1adjyufi_" MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 09 Oct 2012 00:14:56 -0700 Subject: [core] Maximum number of nodes served by a single access point X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 07:10:52 -0000 --_000_C5426A3354D68540AC53DE5236E400D719E3B8F7mbs1adjyufi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, As a part of CoAP cost-efficiency analysis, we need to estimate the maximum= number of nodes served by a single access point (AP) in a simple network c= onsisting of 802.15.4 constrained nodes connected directly to the AP and co= mmunicating either via CoAP or HTTP. Could you, please, direct to the studi= es on this, or give some estimates based on your first-hand experience? In general, is the maximum largely determined by: - the application protocol (HTTP vs CoAP) - the transport (UDP as opposite to TCP) - related to the above - the radio used - the frequency and pattern of communication (e.g., pull vs. push) Or something else? Thank you in advance! Regards, Oleksiy Mazhelis -- Post-doctoral researcher Department of Comp.Sci & IS Agora, P.O.Box 35, FI-40014 Univ. of Jyv=E4skyl=E4, Finland Office: +358 40 805 4293 Mobile: +358 40 515 0641 Fax: +358 14 260 2544 Email: mazhelis@jyu.fi --_000_C5426A3354D68540AC53DE5236E400D719E3B8F7mbs1adjyufi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear all,

 

As a part of CoAP cost-efficiency analysis,= we need to estimate the maximum number of nodes served by a single access = point (AP) in a simple network consisting of 802.15.4 constrained nodes connected directly to the AP and communicating either vi= a CoAP or HTTP. Could you, please, direct to the studies on this, or give s= ome estimates based on your first-hand experience?

 

In general, is the maximum largely determin= ed by:

- the application protocol (HTTP vs CoAP)

- the transport (UDP as opposite to TCP) - = related to the above

- the radio used

- the frequency and pattern of communicatio= n (e.g., pull vs. push)

Or something else?

 

Thank you in advance!

Regards,

Oleksiy Mazhelis

--

Post-doctoral researcher<= /p>

Department of Comp.Sci & IS<= /span>

Agora, P.O.Box 35, FI-40014

Univ. of Jyv=E4skyl=E4, Finland<= /span>

Office: +358 40 805 4293

Mobile: +358 40 515 0641

Fax:    +358 14 260 2544=

Email:   mazhelis@jyu.fi

 

--_000_C5426A3354D68540AC53DE5236E400D719E3B8F7mbs1adjyufi_-- From cabo@tzi.org Tue Oct 9 00:42:36 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C006221F8810 for ; Tue, 9 Oct 2012 00:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.217 X-Spam-Level: X-Spam-Status: No, score=-106.217 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eUVYAutBMPdG for ; Tue, 9 Oct 2012 00:42:35 -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 EDA1A21F8749 for ; Tue, 9 Oct 2012 00:42:34 -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 q997gRto005858; Tue, 9 Oct 2012 09:42:27 +0200 (CEST) Received: from [192.168.217.105] (p54891A2C.dip.t-dialin.net [84.137.26.44]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 1427B10C; Tue, 9 Oct 2012 09:42:27 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Tue, 9 Oct 2012 09:42:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <609EA3B3-2B00-44C6-993E-51164F0786D6@tzi.org> References: To: Mazhelis Oleksiy X-Mailer: Apple Mail (2.1499) Cc: "core@ietf.org" Subject: Re: [core] Maximum number of nodes served by a single access point X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 07:42:36 -0000 Hi Oleksiy, > maximum number of nodes served by a single access point (AP) in a = simple network consisting of 802.15.4 constrained nodes connected = directly to the AP A star network is certainly one way to configure a 802.15.4 network, but = maybe not the one you would come up with under cost efficiency = considerations. Let me try a high-level answer anyway: > In general, is the maximum largely determined by: > - the application protocol (HTTP vs CoAP) > - the transport (UDP as opposite to TCP) - related to the above These choices are essentially translating the offered load at the = application layer to one at the network layer. How much of a difference these choices make depends a lot on the = application, which you haven't told us anything about. Depending on the application, the choices may be pretty much = inconsequential (e.g., for a web cam), or may cause a load difference = that is an order of magnitude. Whether that load difference translates into a performance difference is = another question. (If the resulting load is much smaller than your capacity, and you have = enough energy, there is no influence at all on the maximum number of = devices.) > - the radio used You said 802.15.4, but of course there are different variants and = different quality implementations of each of these. Another important input is what the radio propagation properties of the = environment are going to be (including interference). (E.g., the maximum number may be entirely limited by the density you = need times the area that can be covered.) > - the frequency and pattern of communication (e.g., pull vs. push) That is indeed the input you need to be able to assess the differences = in the choices above. (Your application will also tell you how close you can drive the network = to its limits. And don't work with averages, work with the peaks that still need to = work.) If you want to derive a useful answer, you probably have to be very = specific about the scenario you are looking at and make a number of = reasonable assumptions. > Or something else? How about the cost of the devices themselves? Gr=FC=DFe, Carsten From trac+core@trac.tools.ietf.org Sun Oct 14 11:21:54 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAC3E21F84D3 for ; Sun, 14 Oct 2012 11:21:54 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D5L8W0Y5C-7Z for ; Sun, 14 Oct 2012 11:21:54 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 17DDA21F84D2 for ; Sun, 14 Oct 2012 11:21:54 -0700 (PDT) Received: from localhost ([127.0.0.1]:60903 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TNSoi-0002ZF-Pi; Sun, 14 Oct 2012 20:21:36 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-core-observe@tools.ietf.org, hartke@tzi.org X-Trac-Project: core Date: Sun, 14 Oct 2012 18:21:36 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/236#comment:1 Message-ID: <066.22e68b926abecf761c681b86756f6d8b@trac.tools.ietf.org> References: <051.eff69ddadadd47a9adc6197b9ed29410@trac.tools.ietf.org> X-Trac-Ticket-ID: 236 In-Reply-To: <051.eff69ddadadd47a9adc6197b9ed29410@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-observe@tools.ietf.org, hartke@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: hartke@tzi.org Resent-Message-Id: <20121014182154.17DDA21F84D2@ietfa.amsl.com> Resent-Date: Sun, 14 Oct 2012 11:21:54 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #236: Clarify the semantics of the "obs" link target attribute 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, 14 Oct 2012 18:21:54 -0000 #236: Clarify the semantics of the "obs" link target attribute Changes (by hartke@…): * status: new => closed * resolution: => fixed Comment: Fixed in [974]: Closes #236: Done in observe-07 -- -----------------------------+---------------------------------------- Reporter: cabo@… | Owner: draft-ietf-core-observe@… Type: other technical | Status: closed Priority: minor | Milestone: post-WGLC-1 Component: observe | Version: observe-05 Severity: In WG Last Call | Resolution: fixed Keywords: | -----------------------------+---------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Sun Oct 14 11:29:53 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 916E821F8432 for ; Sun, 14 Oct 2012 11:29:53 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uAaoE6i3RV3N for ; Sun, 14 Oct 2012 11:29:52 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 1B73721F844D for ; Sun, 14 Oct 2012 11:29:52 -0700 (PDT) Received: from localhost ([127.0.0.1]:33353 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TNSwP-0008K6-Ak; Sun, 14 Oct 2012 20:29:33 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-core-observe@tools.ietf.org, cabo@tzi.org, hartke@tzi.org X-Trac-Project: core Date: Sun, 14 Oct 2012 18:29:33 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/225#comment:2 Message-ID: <066.ad99d38e50817c1f353c05a750e1aaa4@trac.tools.ietf.org> References: <051.8dc4d4529b0eb768972bc70c3c71cca2@trac.tools.ietf.org> X-Trac-Ticket-ID: 225 In-Reply-To: <051.8dc4d4529b0eb768972bc70c3c71cca2@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-observe@tools.ietf.org, cabo@tzi.org, hartke@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: hartke@tzi.org Resent-Message-Id: <20121014182952.1B73721F844D@ietfa.amsl.com> Resent-Date: Sun, 14 Oct 2012 11:29:52 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #225: Explain why it is not always possible to react to a RST that is in reply to a NON 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, 14 Oct 2012 18:29:53 -0000 #225: Explain why it is not always possible to react to a RST that is in reply to a NON Changes (by hartke@…): * status: new => closed * resolution: => fixed Comment: Fixed in [975]: Closes #225: Done in observe-07 -- -----------------------------+---------------------------------------- Reporter: cabo@… | Owner: draft-ietf-core-observe@… Type: editorial | Status: closed Priority: minor | Milestone: post-WGLC-1 Component: observe | Version: observe-05 Severity: In WG Last Call | Resolution: fixed Keywords: | -----------------------------+---------------------------------------- Ticket URL: core From yusuke.doi@toshiba.co.jp Mon Oct 15 00:06:53 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FFCB21F861C for ; Mon, 15 Oct 2012 00:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.089 X-Spam-Level: X-Spam-Status: No, score=-8.089 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-8, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id suo9WakPBBp1 for ; Mon, 15 Oct 2012 00:06:48 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by ietfa.amsl.com (Postfix) with ESMTP id B321621F861E for ; Mon, 15 Oct 2012 00:06:41 -0700 (PDT) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id q9F76dea026051 for ; Mon, 15 Oct 2012 16:06:39 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id q9F76d1a015153 for core@ietf.org; Mon, 15 Oct 2012 16:06:39 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id SAA15152; Mon, 15 Oct 2012 16:06:39 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id q9F76d5J028176 for ; Mon, 15 Oct 2012 16:06:39 +0900 (JST) Received: from spiffy21.isl.rdc.toshiba.co.jp by toshiba.co.jp id q9F76dOl029078; Mon, 15 Oct 2012 16:06:39 +0900 (JST) Received: from [133.199.17.48] (ivpn-2-48.mobile.toshiba.co.jp [133.199.17.48]) by spiffy21.isl.rdc.toshiba.co.jp (Postfix) with ESMTP id C851E97CAE for ; Mon, 15 Oct 2012 16:06:38 +0900 (JST) Message-ID: <507BB5FD.7060003@toshiba.co.jp> Date: Mon, 15 Oct 2012 16:06:37 +0900 From: Yusuke DOI User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: core@ietf.org Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: [core] Content-Type Parameter X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 07:06:53 -0000 Dear all, I have revised parameter option proposal (Content Type Parameter) and re-posted it as doi-core-parameter-option. > Filename: draft-doi-core-parameter-option > Revision: 01 > Title: CoAP Content-Type Parameter Option > Creation date: 2012-10-15 > WG ID: Individual Submission > Number of pages: 9 > URL: http://www.ietf.org/internet-drafts/draft-doi-core-parameter-option-01.txt > Status: http://datatracker.ietf.org/doc/draft-doi-core-parameter-option > Htmlized: http://tools.ietf.org/html/draft-doi-core-parameter-option-01 > Diff: http://www.ietf.org/rfcdiff?url2=draft-doi-core-parameter-option-01 My intention of this proposal is to make use of (multi-schema schema-informed) EXI in CoAP network. Efficient communication using EXI requires schema negotiation(*). But the proposal itself is neutral to its content-type and can be used in various ways. *) See also: draft-doi-exi-messaging-requirements http://tools.ietf.org/html/draft-doi-exi-messaging-requirements-00 FAQ: Q) Why don't use a content-type ID for a content type with parameter? A) Because an ID cannot represent semantics in parameter. For example, an application may want to keep backward compatibility between minor revisions but may not have it between major revisions. A single ID cannot represent (major).(minor) version of content. An UTF-8 String (or any other 8-bit transparent) parameter can transfer such semantics and be useful for client-server capability negotiation. Regards, // Yusuke DOI From fluffy@cisco.com Mon Oct 15 09:15:54 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D664721F85DA for ; Mon, 15 Oct 2012 09:15:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.503 X-Spam-Level: X-Spam-Status: No, score=-110.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SDta7GkW7aF1 for ; Mon, 15 Oct 2012 09:15:54 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id E52B521F85D5 for ; Mon, 15 Oct 2012 09:15:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=726; q=dns/txt; s=iport; t=1350317754; x=1351527354; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=YF4vil908FfnJObRzyZS6g+Nb5CZYtMneGfTBpcsrLQ=; b=D29bXm0zf5kPYKRgzu0vLYecJ/Rf6Zzk5C2zKQOESoYbaOm3htOtpu6l vmBkwJQBUlteSuXbhx4v5cb1mSVtipSNxHlxStZQFlcIMfAsXBV0L2Kdo EqN3giXJuC93hdzFnQh3elJUb4+pAZxhxNlb59K0pswybzT4r3rkk9jM+ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApkFADI2fFCtJV2c/2dsb2JhbABFhUu6LIEIgiIBAgISASdRASoUQicEGwEZh2ILnGGBKJ94kTZgA6QxgWuCbYIX X-IronPort-AV: E=Sophos;i="4.80,588,1344211200"; d="scan'208";a="131716930" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 15 Oct 2012 16:15:53 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q9FGFrE7008599 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 15 Oct 2012 16:15:53 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.217]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.001; Mon, 15 Oct 2012 11:15:53 -0500 From: "Cullen Jennings (fluffy)" To: core WG Thread-Topic: Draft on secure enrollment Thread-Index: AQHNqvBYj9GrzzZ+pUKJWZD/DhB11g== Date: Mon, 15 Oct 2012 16:15:52 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.65.199] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19274.004 x-tm-as-result: No--25.614400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <7ABA98D7FBC8674E918B04DC025C70D8@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [core] Draft on secure enrollment X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 16:15:55 -0000 I'd like to propose one possible way to get the initial keys needed for COR= E on the devices. I wrote up a draft at http://www.ietf.org/internet-drafts/draft-jennings-core-transitive-trust-= enrollment-01.pdf (do read the PDF version not the txt version as the txt version is missing = the figures) One things i like about this is you can probably build sensors that are run= ning in the closer to 32k of flash wight this approach. Part of what got it= so small was an extremely small set of crypto algorithms required. This is= obviously an early sketch of and many details would need to be worked out = but I think there is enough in the draft to be able to understand the idea = and discuss it.=20 From gilger@itsec.rwth-aachen.de Tue Oct 16 01:23:14 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 956BF21F888C for ; Tue, 16 Oct 2012 01:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v-js855IZsaS for ; Tue, 16 Oct 2012 01:23:13 -0700 (PDT) Received: from avalon.gnuzifer.de (avalon.gnuzifer.de [IPv6:2a01:4f8:121:43c1::a2:1]) by ietfa.amsl.com (Postfix) with ESMTP id E6B7B21F8887 for ; Tue, 16 Oct 2012 01:23:12 -0700 (PDT) Received: from [137.226.161.159] (port=46153 helo=localhost) by avalon.gnuzifer.de with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1TO2Qe-0006KH-3c; Tue, 16 Oct 2012 10:23:08 +0200 Date: Tue, 16 Oct 2012 10:23:46 +0200 From: Johannes Gilger To: core WG Message-ID: <20121016082346.GA29405@blackbox> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: 137.226.161.159 X-SA-Exim-Mail-From: gilger@itsec.rwth-aachen.de X-Mailman-Approved-At: Tue, 16 Oct 2012 01:42:40 -0700 Cc: "Cullen Jennings \(fluffy\)" Subject: Re: [core] Draft on secure enrollment X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 08:23:14 -0000 Hello Cullen, I read the draft (and remembered your presentation at the Smart Object Security Workshop) and have some small questions about the scheme in general. The core of my questions is: Why do you need the Transfer Agent (and the Manufacturer) to be involved in the enrollment? For example, I could modify the scheme like this: - Leave out the TA and the OTP - Transfer DevSecret from Device to Introducer (QR-Code) - Transfer DevSecret from Introducer to Controller (Backend) - Use DevSecret to enroll Device (In-Band) The way I see it this would have the following drawbacks: 1. Someone else could read the secret and try to enroll the device before I can. 2. Someone could reset the device and enroll it again with himself because there is no online entity (TA) which keeps track of the enrollment runs. 2. The device will need some sort of discovery mechanism to find a/the controller on its current network when it is activated (this might be the hard part, please educate me). Is there anything else I am missing? Is there another motivation for having the online TA? Why do we need an OTP *and* a DevSecret? Could we just use the DevSecret in place of the OTP? Or would it be unacceptable for the TA to know the DevSecret which we'll use in the first few packets to change the permanent DevSecret? I guess I haven't quite wrapped my head around it yet. But the draft itself reads very nicely, and I guess it fits the requirements for a lot of deployment scenarios. Stealing of OTPs could be prevented by hiding the QR-Code beneath a scratch-off field, if that is something that is acceptable for quick deployments without opening the box. Regards, Jojo -- Dipl.-Inform. Johannes Gilger Research Group IT-Security RWTH Aachen University Mies-van-der-Rohe-Straße 15 52074 Aachen Office: 211 Phone: +49 241 80 20781 http://itsec.rwth-aachen.de From salvatore.loreto@ericsson.com Tue Oct 16 06:18:57 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0077B21F86A4 for ; Tue, 16 Oct 2012 06:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.405 X-Spam-Level: X-Spam-Status: No, score=-106.405 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fcwHeASVG+du for ; Tue, 16 Oct 2012 06:18:55 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0D93A21F8645 for ; Tue, 16 Oct 2012 06:18:54 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-0a-507d5ebdf0db Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 53.70.11467.DBE5D705; Tue, 16 Oct 2012 15:18:53 +0200 (CEST) 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.279.1; Tue, 16 Oct 2012 15:18:53 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 340992AD2; Tue, 16 Oct 2012 16:18:53 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id D9BF853651; Tue, 16 Oct 2012 16:18:52 +0300 (EEST) Received: from n94.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 81B2C531B3; Tue, 16 Oct 2012 16:18:52 +0300 (EEST) Message-ID: <507D5EBC.3060907@ericsson.com> Date: Tue, 16 Oct 2012 16:18:52 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "core@ietf.org" References: <20121015134442.14537.59996.idtracker@ietfa.amsl.com> In-Reply-To: <20121015134442.14537.59996.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20121015134442.14537.59996.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------040306080505080108050002" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyM+Jvre7euNoAg2nLdSx+TWhistj3dj2z xdzNf1ktfpw+xOzA4rFkyU8mj6XX21g9pl+cwO6xdXojawBLFJdNSmpOZllqkb5dAlfGrQsT WQseWlc0/ehga2DcqN/FyMkhIWAiMf3ySmYIW0ziwr31bF2MXBxCAqcYJU70vmUFSQgJbGCU 6P0lDGHvZpT4vtoLomgdo8TkT4ugOpYxSkzdPo8FpIpXQFvi0epLQGM5OFgEVCWOb2UECbMJ mEk8f7gFbJuoQLLEvA1XmSHKBSVOznwC1ioioCyx+cxrRpCZzCCLb98/DnaFsICBxLOJrUwQ VzhKdGzZww5icwo4Sbz//44N4gVfiebpvWD1zAJhEt8XTGCBiKtJXD23iRmiV0ui92wn0wRG 0VlIds9C0gJhW0gsfnOQHcKWl9j+dg4zhK0hseDOPkZk8QWMbKsYhXMTM3PSyw31Uosyk4uL 8/P0ilM3MQLj7+CW37o7GE+dEznEKM3BoiTOy5W0319IID2xJDU7NbUgtSi+qDQntfgQIxMH p1QDYzzLRAXFC4YPnR1aKrbMX/s0spj/ob2W95yYRUsXlNTubM69IpjI9XqS8lPpp6+vHo1Y 1vjyapZPTtLV9qWnluSsu2ofriq146NnrEbXhSozqV2f+S7Uyfg0f7q5sf6R8DXRV/Ea7qL3 5lxmZtzAoWDy5yLbo18y3/N0N/k85H7kV6Nt18jRosRSnJFoqMVcVJwIAOcflgCNAgAA Cc: "matthieu.vial@non.schneider-electric.com" Subject: [core] new draft core-sleepy-problem-statement X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 13:18:57 -0000 --------------040306080505080108050002 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit The authors of the various I-Ds related to solutions for Sleepy Devices have collaborated to produce a first version of a problem statement: http://www.ietf.org/internet-drafts/draft-rahman-core-sleepy-problem-statement-00.txt The idea behind this joint effort is to trigger a discussions in the CORE WG so that all relevant considerations for sleeping devices as well all the possible use cases/scenarios are taken into account when designing the specific CoAP solution(s). We would really appreciate if you read it and send out comments in the CoRE mailing list. We also look forward to discuss this problem statement, with enough time, in on of the F2F session Atlanta cheers /Sal -- Salvatore Loreto, PhD www.sloreto.com -------- Original Message -------- Subject: New Version Notification for draft-rahman-core-sleepy-problem-statement-00.txt Date: Mon, 15 Oct 2012 16:44:42 +0300 From: internet-drafts@ietf.org To: akbar.rahman@interdigital.com CC: Salvatore Loreto , "tho@koanlogic.com" , "matthieu.vial@schneider-electric.com" A new version of I-D, draft-rahman-core-sleepy-problem-statement-00.txt has been successfully submitted by Akbar Rahman and posted to the IETF repository. Filename: draft-rahman-core-sleepy-problem-statement Revision: 00 Title: Sleepy Devices in CoAP - Problem Statement Creation date: 2012-10-15 WG ID: Individual Submission Number of pages: 8 URL: http://www.ietf.org/internet-drafts/draft-rahman-core-sleepy-problem-statement-00.txt Status: http://datatracker.ietf.org/doc/draft-rahman-core-sleepy-problem-statement Htmlized: http://tools.ietf.org/html/draft-rahman-core-sleepy-problem-statement-00 Abstract: This document analyzes the COAP protocol issues related to sleeping devices. The only goal of this document is to trigger discussions in the CORE WG so that all relevant considerations for sleeping devices are taken into account when designing CoAP. The IETF Secretariat --------------040306080505080108050002 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 7bit
The authors of the various I-Ds related to solutions for Sleepy Devices
have collaborated to produce a first version of a problem statement:
http://www.ietf.org/internet-drafts/draft-rahman-core-sleepy-problem-statement-00.txt

The idea behind this joint effort is to trigger a discussions in the CORE WG so
that all relevant considerations for sleeping devices as well all the possible use cases/scenarios
are taken into account when designing the specific CoAP solution(s).

We would really appreciate if you read it and send out comments in the CoRE mailing list.

We also look forward to discuss this problem statement, with enough time,
in on of the F2F session Atlanta

cheers
/Sal
-- 
Salvatore Loreto, PhD
www.sloreto.com


-------- Original Message --------
Subject: New Version Notification for draft-rahman-core-sleepy-problem-statement-00.txt
Date: Mon, 15 Oct 2012 16:44:42 +0300
From: internet-drafts@ietf.org <internet-drafts@ietf.org>
To: akbar.rahman@interdigital.com <akbar.rahman@interdigital.com>
CC: Salvatore Loreto <salvatore.loreto@ericsson.com>, "tho@koanlogic.com" <tho@koanlogic.com>, "matthieu.vial@schneider-electric.com" <matthieu.vial@schneider-electric.com> 


A new version of I-D, draft-rahman-core-sleepy-problem-statement-00.txt
has been successfully submitted by Akbar Rahman and posted to the
IETF repository.

Filename:	 draft-rahman-core-sleepy-problem-statement
Revision:	 00
Title:		 Sleepy Devices in CoAP - Problem Statement
Creation date:	 2012-10-15
WG ID:		 Individual Submission
Number of pages: 8
URL:             http://www.ietf.org/internet-drafts/draft-rahman-core-sleepy-problem-statement-00.txt
Status:          http://datatracker.ietf.org/doc/draft-rahman-core-sleepy-problem-statement
Htmlized:        http://tools.ietf.org/html/draft-rahman-core-sleepy-problem-statement-00


Abstract:
   This document analyzes the COAP protocol issues related to sleeping
   devices.  The only goal of this document is to trigger discussions in
   the CORE WG so that all relevant considerations for sleeping devices
   are taken into account when designing CoAP.

                                                                                  


The IETF Secretariat



--------------040306080505080108050002-- From trac+core@trac.tools.ietf.org Wed Oct 17 05:43:59 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54E8021F852E for ; Wed, 17 Oct 2012 05:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7wYKCZKQiD9 for ; Wed, 17 Oct 2012 05:43:57 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 24E5821F852A for ; Wed, 17 Oct 2012 05:43:57 -0700 (PDT) Received: from localhost ([127.0.0.1]:57015 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TOSyT-0007T5-Dy; Wed, 17 Oct 2012 14:43:49 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Wed, 17 Oct 2012 12:43:49 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/247#comment:1 Message-ID: <075.472e70d0e789349a4baba7d062e0fdbd@trac.tools.ietf.org> References: <060.165feff053c11cfa0d65de452eb53ed9@trac.tools.ietf.org> X-Trac-Ticket-ID: 247 In-Reply-To: <060.165feff053c11cfa0d65de452eb53ed9@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: brian@skyfoundry.com, cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20121017124357.24E5821F852A@ietfa.amsl.com> Resent-Date: Wed, 17 Oct 2012 05:43:57 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #247: Scalability question IANA reviewer for IPv4 multicast address request X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 12:43:59 -0000 #247: Scalability question IANA reviewer for IPv4 multicast address request Comment (by esko.dijk@…): Additionally the comment below from the IANA designated expert reviewer, for the IPv6 multicast address request that we made: "There are some concerns about how "All CoAP Nodes" will be used for IPv4, and it seems there is still discussion in the WG. As the same protocol is used also for IPv6, it may make sense to defer the IPv6 allocation until it is clear how "All CoAP Nodes" will be used for both IPv4 and IPv6, and then process the two applications together. Is there any need, e.g. implementations and testing, for doing the IPv6 application prior to the IPv4 application?" -- -----------------------------+------------------------------------- Reporter: esko.dijk@… | Owner: draft-ietf-core-coap@… Type: protocol defect | Status: new Priority: major | Milestone: post-WGLC-1 Component: coap | Version: Severity: - | Resolution: Keywords: | -----------------------------+------------------------------------- Ticket URL: core From mab@comnets.uni-bremen.de Wed Oct 17 06:03:03 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC8121F87CA for ; Wed, 17 Oct 2012 06:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fqMC2LfIuyv7 for ; Wed, 17 Oct 2012 06:03:02 -0700 (PDT) Received: from bugs.comnets.uni-bremen.de (bugs.comnets.uni-bremen.de [IPv6:2001:638:708:1155::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8762221F877A for ; Wed, 17 Oct 2012 06:02:54 -0700 (PDT) Received: from shelbyville.comnets.uni-bremen.de (shelbyville [10.10.155.50]) by bugs.comnets.uni-bremen.de (Postfix) with ESMTPS id 19DD6D42AAA; Wed, 17 Oct 2012 15:02:53 +0200 (CEST) From: Markus Becker Organization: Comnets, University Bremen To: "core@ietf.org" Date: Wed, 17 Oct 2012 15:02:52 +0200 User-Agent: KMail/1.13.7 (Linux/3.5-trunk-686-pae; KDE/4.8.4; i686; ; ) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201210171502.52422.mab@comnets.uni-bremen.de> Subject: [core] CoAP Block: zero length default values X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 13:03:03 -0000 Dear Carsten, dear WG, please advise us on an issue with the Block Option and its default values. Assuming a client requests a block transfer of resource with the Block2 option and the default value of 0. According to draft-ietf-core-coap-12#section-5.4.4 the complete option SHOULD NOT be included: Options may be defined to have a default value. If the value of option is intended to be this default value, the option SHOULD NOT be included in the message. If the option is not present, the default value MUST be assumed. For the server to detect that a Block transfer is requested, the option cannot be completely left out of the request, though. Should this valid reason speaking against the SHOULD NOT (BCP14) and the possibility of zero-length options be stated explicitly in core-block? E.g. The default value of both the Block1 and the Block2 Option is zero, indicating that the current block is the first and only block of the transfer (block number 0, M bit not set); however, there is no explicit size implied by this default value. + Contrary to the default value behaviour specified in draft-ietf-core- + coap-12#section-5.4.4, the Block options need to be included for the + 0-length default values, as the other end-point would not be able to + notice that a block transfer is desired. This text fragment should be similarly extended: The default value of both the Block1 and the Block2 Option is zero, indicating that the current block is the first and only block of the transfer (block number 0, M bit not set); however, there is no explicit size implied by this default value. The table might need to be adapted to 0-3 B as well, to make this more clear: +------+----------+--------+--------+--------+---------------+ | Type | C/E | Name | Format | Length | Default | +------+----------+--------+--------+--------+---------------+ | 19 | Critical | Block1 | uint | 1-3 B | 0 (see below) | | | | | | | | | 17 | Critical | Block2 | uint | 1-3 B | 0 (see below) | +------+----------+--------+--------+--------+---------------+ Or, should there be no default value for Block options thus increasing the size of the request by 1 byte for a rare case? -- Markus ------------------------------------------------ | Dipl.-Ing. Markus Becker | Communication Networks | TZI - Center for Computing Technologies | University Bremen | Germany ------------------------------------------------ | web: http://www.comnets.uni-bremen.de/~mab/ | mailto: mab@comnets.uni-bremen.de | telephone: +49 421 218 62379 | building: NW1 room: N2260 ------------------------------------------------ From cabo@tzi.org Wed Oct 17 06:53:45 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0B7621F8493 for ; Wed, 17 Oct 2012 06:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.278 X-Spam-Level: X-Spam-Status: No, score=-106.278 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZMUXFfTMgWhZ for ; Wed, 17 Oct 2012 06:53:45 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 13C4221F8484 for ; Wed, 17 Oct 2012 06:53:44 -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 q9HDrbE9000976; Wed, 17 Oct 2012 15:53:37 +0200 (CEST) Received: from [10.0.1.2] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 692E2CF9; Wed, 17 Oct 2012 15:53:37 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <201210171502.52422.mab@comnets.uni-bremen.de> Date: Wed, 17 Oct 2012 15:53:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4A5669C5-3473-4223-94EF-5C5CF4B01DA6@tzi.org> References: <201210171502.52422.mab@comnets.uni-bremen.de> To: Markus Becker X-Mailer: Apple Mail (2.1499) Cc: "core@ietf.org" Subject: Re: [core] CoAP Block: zero length default values X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 13:53:45 -0000 On Oct 17, 2012, at 15:02, Markus Becker = wrote: > Or, should there be no default value for Block options thus increasing = the=20 > size of the request by 1 byte for a rare case? Well, maybe it is indeed best to get rid of the fiction of a "default = value" for Block1/2. This was maybe more the reflection of an implementation strategy than a = piece of actual semantics. As you say, if the Block option is not present, this is different from a = Block option value of 0 (SZX=3D0, M=3D0, NUM=3D0). Say maybe we should just say that the Block option does NOT have a = default value, and that absence of the Block option is equivalent to = (SZX=3Dunspecified, M=3D0, NUM=3D0). [Looking into my own implementation -- that is exactly what I'm doing. = Oops.] Also, as you say, for consistency we should also allow giving an = explicit zero-length uint value. 0 again happens to mean SZX=3D0, M=3D0, NUM=3D0, and even though SZX=3D0 = is one of the less likely choices and therefore not one we would be = specifically optimizing for, we allow zero length uint for a zero = everywhere else. Very timely input for the upcoming -10, thanks! Gr=FC=DFe, Carsten From mab@comnets.uni-bremen.de Wed Oct 17 07:07:01 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF5A21F84EA for ; Wed, 17 Oct 2012 07:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gp4Yj1GAk5BW for ; Wed, 17 Oct 2012 07:07:01 -0700 (PDT) Received: from bugs.comnets.uni-bremen.de (bugs.comnets.uni-bremen.de [IPv6:2001:638:708:1155::1]) by ietfa.amsl.com (Postfix) with ESMTP id E01A321F8449 for ; Wed, 17 Oct 2012 07:07:00 -0700 (PDT) Received: from shelbyville.comnets.uni-bremen.de (shelbyville [10.10.155.50]) by bugs.comnets.uni-bremen.de (Postfix) with ESMTPS id 4EDEDD401F3; Wed, 17 Oct 2012 16:06:59 +0200 (CEST) From: Markus Becker Organization: Comnets, University Bremen To: Carsten Bormann Date: Wed, 17 Oct 2012 16:06:58 +0200 User-Agent: KMail/1.13.7 (Linux/3.5-trunk-686-pae; KDE/4.8.4; i686; ; ) References: <201210171502.52422.mab@comnets.uni-bremen.de> <4A5669C5-3473-4223-94EF-5C5CF4B01DA6@tzi.org> In-Reply-To: <4A5669C5-3473-4223-94EF-5C5CF4B01DA6@tzi.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201210171606.58732.mab@comnets.uni-bremen.de> Cc: "core@ietf.org" Subject: Re: [core] CoAP Block: zero length default values X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 14:07:01 -0000 > On Oct 17, 2012, at 15:02, Markus Becker wrot= e: > > Or, should there be no default value for Block options thus increasing > > the size of the request by 1 byte for a rare case? >=20 > Well, maybe it is indeed best to get rid of the fiction of a "default > value" for Block1/2. This was maybe more the reflection of an > implementation strategy than a piece of actual semantics. >=20 > As you say, if the Block option is not present, this is different from a > Block option value of 0 (SZX=3D0, M=3D0, NUM=3D0). Say maybe we should ju= st say > that the Block option does NOT have a default value, and that absence of > the Block option is equivalent to (SZX=3Dunspecified, M=3D0, NUM=3D0). [L= ooking > into my own implementation -- that is exactly what I'm doing. Oops.] Would that mean that the server can decide to send a Block option for a=20 "large" resource in a response, even though the client did not put a Block= =20 option in the request? What is the supposed behaviour of a client not=20 implementing Block, but receiving a Block option in the response? RST? > Also, as you say, for consistency we should also allow giving an explicit > zero-length uint value. 0 again happens to mean SZX=3D0, M=3D0, NUM=3D0, = and > even though SZX=3D0 is one of the less likely choices and therefore not o= ne > we would be specifically optimizing for, we allow zero length uint for a > zero everywhere else. >=20 > Very timely input for the upcoming -10, thanks! >=20 > Gr=FC=DFe, Carsten From cabo@tzi.org Wed Oct 17 07:57:42 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD42721F870A for ; Wed, 17 Oct 2012 07:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.274 X-Spam-Level: X-Spam-Status: No, score=-106.274 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uXToWmX6jKKp for ; Wed, 17 Oct 2012 07:57:42 -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 039E821F86CA for ; Wed, 17 Oct 2012 07:57:41 -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 q9HEvYBV009366; Wed, 17 Oct 2012 16:57:34 +0200 (CEST) Received: from [10.0.1.2] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 97392D90; Wed, 17 Oct 2012 16:57:34 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <201210171606.58732.mab@comnets.uni-bremen.de> Date: Wed, 17 Oct 2012 16:57:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <325864B9-613C-42E4-B5A1-B1949472DD94@tzi.org> References: <201210171502.52422.mab@comnets.uni-bremen.de> <4A5669C5-3473-4223-94EF-5C5CF4B01DA6@tzi.org> <201210171606.58732.mab@comnets.uni-bremen.de> To: Markus Becker X-Mailer: Apple Mail (2.1499) Cc: "core@ietf.org" Subject: Re: [core] CoAP Block: zero length default values X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 14:57:42 -0000 > Would that mean that the server can decide to send a Block option for = a=20 > "large" resource in a response, even though the client did not put a = Block=20 > option in the request? We indeed made that decision. That is not very related to the question whether the Block2 option has a = default value or not. The reasoning that we allow a server to spontaneously insert a Block2 = option is as follows: -- a client can't really know whether the resource representation is = "large" from the p.o.v of the server -- so a client that does implement Block would need to send the option = with every single request -- clients that are actually interested in the representations of large = respurces are more likely to implement Block2 than not. The underlying assumption is that the distribution of representation = sizes is somewhat bimodal: Sensor readings are very likely not to be "large" for a sensor. Manifests like .well-known/core are like to be large enough that a = client that wants them already implements Block2. > What is the supposed behaviour of a client not=20 > implementing Block, but receiving a Block option in the response? RST? We recently clarified this in coap-12. Section 5.4.1 now says: o Unrecognized options of class "critical" that occur in a confirmable response, or piggy-backed in an acknowledgement, MUST cause the response to be rejected (Section 4.2). Now, 4.2 says: ... rejecting a Confirmable message is effected by sending a matching Reset message and otherwise ignoring it. =20 ... Rejecting an Acknowledgement or Reset message is effected by silently ignoring it. and 4.3: ... rejecting a Non-Confirmable message MAY involve sending a matching Reset message, and apart from the Reset message the rejected message MUST be silently ignored. So if the response was piggy-backed, you do nothing about the Block = option. If the response was in a separate CON request, you RST. If the response was in a separate NON, you MAY RST. In any case, you can't do anything about the fact that the server is = only prepared to give you the resource representation if you implement = Block2. We wanted to give servers this freedom. Conclusion: As a client that wants to handle large resources, you better = do implement Block2. Gr=FC=DFe, Carsten From sye.loong.keoh@philips.com Wed Oct 17 08:43:21 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EB6B21F8671 for ; Wed, 17 Oct 2012 08:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ntPbMKvgHnM for ; Wed, 17 Oct 2012 08:43:20 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by ietfa.amsl.com (Postfix) with ESMTP id 4713B21F8596 for ; Wed, 17 Oct 2012 08:43:20 -0700 (PDT) Received: from mail272-va3-R.bigfish.com (10.7.14.242) by VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id 14.1.225.23; Wed, 17 Oct 2012 15:43:19 +0000 Received: from mail272-va3 (localhost [127.0.0.1]) by mail272-va3-R.bigfish.com (Postfix) with ESMTP id 77DAC16001EA; Wed, 17 Oct 2012 15:43:19 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -41 X-BigFish: VPS-41(zz217bL15d6O9251Jc89bhd6eah1be0I168aJ542Mzz1202h1d1ah1d2ahzz1033IL17326ah8275dhz2dh2a8h668h839h93fhd25hf0ah107ah1288h12a5h12a9h12bdh137ah13b6h1441h1155h) Received: from mail272-va3 (localhost.localdomain [127.0.0.1]) by mail272-va3 (MessageSwitch) id 1350488597927063_2971; Wed, 17 Oct 2012 15:43:17 +0000 (UTC) Received: from VA3EHSMHS007.bigfish.com (unknown [10.7.14.245]) by mail272-va3.bigfish.com (Postfix) with ESMTP id D13B01E000EC; Wed, 17 Oct 2012 15:43:17 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by VA3EHSMHS007.bigfish.com (10.7.99.17) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 17 Oct 2012 15:43:16 +0000 Received: from 011-DB3MPN1-033.MGDPHG.emi.philips.com ([169.254.3.39]) by 011-DB3MMR1-009.MGDPHG.emi.philips.com ([10.128.28.48]) with mapi id 14.02.0309.003; Wed, 17 Oct 2012 16:42:47 +0100 From: "Keoh, Sye Loong" To: Johannes Gilger , core WG Thread-Topic: [core] Draft on secure enrollment Thread-Index: AQHNqvBYj9GrzzZ+pUKJWZD/DhB11pe7iHoAgAIaD2A= Date: Wed, 17 Oct 2012 15:42:47 +0000 Message-ID: References: <20121016082346.GA29405@blackbox> In-Reply-To: <20121016082346.GA29405@blackbox> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.104] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: "Cullen Jennings \(fluffy\)" Subject: Re: [core] Draft on secure enrollment X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 15:43:21 -0000 SGVsbG8gQ3VsbGVuIGFuZCBKb2hhbm5lcywNCg0KSW4gc29tZSB1c2UgY2FzZXMsIHRoZSBtYW51 ZmFjdHVyZXJzIHdvdWxkIGxpa2UgdG8gZW5zdXJlIHRoYXQgb25seSB0aGUgYXV0aG9yaXplZCBk ZXZpY2VzIGNhbiBiZSBpbnN0YWxsZWQgaW4gYSBzeXN0ZW0uIENvcnJlY3QgbWUgaWYgSSBhbSB3 cm9uZywgdGhpcyBjb3VsZCBwcmV2ZW50IGRldmljZSBjbG9uaW5nIHN1Y2ggdGhhdCBPVFAgdGhh dCBoYXMgYWxyZWFkeSBiZWVuIHVzZWQgY2Fubm90IGJlIGFjdGl2YXRlZC9hc3NvY2lhdGVkIHdp dGggdGhlIGNvbnRyb2xsZXIuIEluIHRoaXMgY29udGV4dCwgdGhlcmUgYXJlIGJlbmVmaXRzIGZv ciBoYXZpbmcgdGhlIFRyYW5zZmVyIEFnZW50LCBhbmQgSSBzZWUgdGhlIHJvbGUgb2YgJ2ludHJv ZHVjZXInIGFzIGEgY29tbWlzc2lvbmluZyB0b29sIHRoYXQgaXMgdXNlZCB0byBpZGVudGlmeSB0 aGUgZGV2aWNlIHRvIGJlIGluc3RhbGxlZC4gTWF5YmUgaXQncyBnb29kIHRvIHNlcGFyYXRlIHRo ZSB1c2UgY2FzZSBvZiBhIGNvbXBsZXRlbHkgc3RhbmQtYWxvbmUgZGVwbG95bWVudCB3aGVyZSBu byBvbmxpbmUgY29ubmVjdGl2aXR5IGlzIGF2YWlsYWJsZSwgdGhlbiB0aGUgc2NoZW1lIHN1Z2dl c3RlZCAgYnkgSm9oYW5uZXMgaXMgcHJvYmFibHkgc3VmZmljaWVudC4gSW4gY2FzZSB0aGF0IG9u bGluZSBjb25uZWN0aXZpdHkgaXMgYXZhaWxhYmxlLCBkZXZpY2VzIGNhbiBiZSB2YWxpZGF0ZWQg d2l0aCB0aGUgVEEgaW4gdGhlIGJhY2tlbmQuDQoNCkkgYWxzbyBoYXZlIHRoZSBzYW1lIHF1ZXN0 aW9uIGFzIEpvaGFubmVzLCB3aHkgZG8gd2UgbmVlZCBzbyBtYW55IHNlY3JldHMsIGkuZS4sIE9U UCwgRGV2U2VjcmV0LCBUYVNlY3JldD8NClByZXN1bWFibHksIGlmIHRoZSBUQSBhbHNvIGtub3dz IHRoZSBEZXZTZWNyZXQgb3IgdGhlIE9UUCwgdGhlbiBhIHNlY3VyZSBjaGFubmVsIGNhbiBiZSBl c3RhYmxpc2hlZCBiZXR3ZWVuIHRoZW0gd2l0aG91dCByZXF1aXJpbmcgdGhlIFRhU2VjcmV0LiBK dXN0IGEgcXVlc3Rpb24sIGlzIHRoZSBUYVNlY3JldCB1bmlxdWUgcGVyIGRldmljZSBvciBpdCdz IGEgY29tbW9uIHNlY3JldCBmb3IgYWxsIGRldmljZXM/DQoNCkkgcXVpdGUgbGlrZSB0aGUgaWRl YSB0aGF0IHRoZSBPVFAgb3IgRGV2U2VjcmV0IGlzIGhpZGRlbiBhcyBhIHNjcmF0Y2gtb2ZmIGZp ZWxkLg0KDQpMYXN0bHksIGhvdyBhYm91dCBkZXZpY2UgcmVwbGFjZW1lbnQgYW5kIHJlLWluc3Rh bGxhdGlvbiBvZiB0aGUgZGV2aWNlPyBSZXF1aXJpbmcgdGhlIHVzZXIgdG8gYnJpbmcgdGhlIGRl dmljZSBiYWNrIHRvIHRoZSBtYW51ZmFjdHVyZXIgaXMgbm90IHNvIGNvbnZlbmllbnQgaW4gbXkg b3Bpbmlvbi4NCg0KS2luZCByZWdhcmRzLA0KU3llIExvb25nDQoNCg0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCkZyb206IGNvcmUtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNvcmUtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEpvaGFubmVzIEdpbGdlcg0KU2VudDogZGluc2Rh ZyAxNiBva3RvYmVyIDIwMTIgMTA6MjQNClRvOiBjb3JlIFdHDQpDYzogQ3VsbGVuIEplbm5pbmdz IChmbHVmZnkpDQpTdWJqZWN0OiBSZTogW2NvcmVdIERyYWZ0IG9uIHNlY3VyZSBlbnJvbGxtZW50 DQoNCkhlbGxvIEN1bGxlbiwNCg0KSSByZWFkIHRoZSBkcmFmdCAoYW5kIHJlbWVtYmVyZWQgeW91 ciBwcmVzZW50YXRpb24gYXQgdGhlIFNtYXJ0IE9iamVjdCBTZWN1cml0eSBXb3Jrc2hvcCkgYW5k IGhhdmUgc29tZSBzbWFsbCBxdWVzdGlvbnMgYWJvdXQgdGhlIHNjaGVtZSBpbiBnZW5lcmFsLiBU aGUgY29yZSBvZiBteSBxdWVzdGlvbnMgaXM6IFdoeSBkbyB5b3UgbmVlZCB0aGUgVHJhbnNmZXIg QWdlbnQgKGFuZCB0aGUgTWFudWZhY3R1cmVyKSB0byBiZSBpbnZvbHZlZCBpbiB0aGUgZW5yb2xs bWVudD8NCg0KRm9yIGV4YW1wbGUsIEkgY291bGQgbW9kaWZ5IHRoZSBzY2hlbWUgbGlrZSB0aGlz Og0KDQotIExlYXZlIG91dCB0aGUgVEEgYW5kIHRoZSBPVFANCi0gVHJhbnNmZXIgRGV2U2VjcmV0 IGZyb20gRGV2aWNlIHRvIEludHJvZHVjZXIgKFFSLUNvZGUpDQotIFRyYW5zZmVyIERldlNlY3Jl dCBmcm9tIEludHJvZHVjZXIgdG8gQ29udHJvbGxlciAoQmFja2VuZCkNCi0gVXNlIERldlNlY3Jl dCB0byBlbnJvbGwgRGV2aWNlIChJbi1CYW5kKQ0KDQpUaGUgd2F5IEkgc2VlIGl0IHRoaXMgd291 bGQgaGF2ZSB0aGUgZm9sbG93aW5nIGRyYXdiYWNrczoNCg0KMS4gU29tZW9uZSBlbHNlIGNvdWxk IHJlYWQgdGhlIHNlY3JldCBhbmQgdHJ5IHRvIGVucm9sbCB0aGUgZGV2aWNlDQogICBiZWZvcmUg SSBjYW4uDQoyLiBTb21lb25lIGNvdWxkIHJlc2V0IHRoZSBkZXZpY2UgYW5kIGVucm9sbCBpdCBh Z2FpbiB3aXRoIGhpbXNlbGYNCiAgIGJlY2F1c2UgdGhlcmUgaXMgbm8gb25saW5lIGVudGl0eSAo VEEpIHdoaWNoIGtlZXBzIHRyYWNrIG9mIHRoZQ0KICAgZW5yb2xsbWVudCBydW5zLg0KMi4gVGhl IGRldmljZSB3aWxsIG5lZWQgc29tZSBzb3J0IG9mIGRpc2NvdmVyeSBtZWNoYW5pc20gdG8gZmlu ZCBhL3RoZQ0KICAgY29udHJvbGxlciBvbiBpdHMgY3VycmVudCBuZXR3b3JrIHdoZW4gaXQgaXMg YWN0aXZhdGVkICh0aGlzIG1pZ2h0IGJlDQogICB0aGUgaGFyZCBwYXJ0LCBwbGVhc2UgZWR1Y2F0 ZSBtZSkuDQoNCklzIHRoZXJlIGFueXRoaW5nIGVsc2UgSSBhbSBtaXNzaW5nPyBJcyB0aGVyZSBh bm90aGVyIG1vdGl2YXRpb24gZm9yIGhhdmluZyB0aGUgb25saW5lIFRBPyBXaHkgZG8gd2UgbmVl ZCBhbiBPVFAgKmFuZCogYSBEZXZTZWNyZXQ/IENvdWxkIHdlIGp1c3QgdXNlIHRoZSBEZXZTZWNy ZXQgaW4gcGxhY2Ugb2YgdGhlIE9UUD8gT3Igd291bGQgaXQgYmUgdW5hY2NlcHRhYmxlIGZvciB0 aGUgVEEgdG8ga25vdyB0aGUgRGV2U2VjcmV0IHdoaWNoIHdlJ2xsIHVzZSBpbiB0aGUgZmlyc3Qg ZmV3IHBhY2tldHMgdG8gY2hhbmdlIHRoZSBwZXJtYW5lbnQgRGV2U2VjcmV0Pw0KDQpJIGd1ZXNz IEkgaGF2ZW4ndCBxdWl0ZSB3cmFwcGVkIG15IGhlYWQgYXJvdW5kIGl0IHlldC4gQnV0IHRoZSBk cmFmdCBpdHNlbGYgcmVhZHMgdmVyeSBuaWNlbHksIGFuZCBJIGd1ZXNzIGl0IGZpdHMgdGhlIHJl cXVpcmVtZW50cyBmb3IgYSBsb3Qgb2YgZGVwbG95bWVudCBzY2VuYXJpb3MuIFN0ZWFsaW5nIG9m IE9UUHMgY291bGQgYmUgcHJldmVudGVkIGJ5IGhpZGluZyB0aGUgUVItQ29kZSBiZW5lYXRoIGEg c2NyYXRjaC1vZmYgZmllbGQsIGlmIHRoYXQgaXMgc29tZXRoaW5nIHRoYXQgaXMgYWNjZXB0YWJs ZSBmb3IgcXVpY2sgZGVwbG95bWVudHMgd2l0aG91dCBvcGVuaW5nIHRoZSBib3guDQoNClJlZ2Fy ZHMsDQpKb2pvDQoNCi0tDQpEaXBsLi1JbmZvcm0uIEpvaGFubmVzIEdpbGdlcg0KUmVzZWFyY2gg R3JvdXAgSVQtU2VjdXJpdHkNClJXVEggQWFjaGVuIFVuaXZlcnNpdHkNCk1pZXMtdmFuLWRlci1S b2hlLVN0cmHDn2UgMTUNCjUyMDc0IEFhY2hlbg0KDQpPZmZpY2U6IDIxMQ0KUGhvbmU6ICs0OSAy NDEgODAgMjA3ODENCg0KaHR0cDovL2l0c2VjLnJ3dGgtYWFjaGVuLmRlDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KY29yZSBtYWlsaW5nIGxpc3QNCmNv cmVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZQ0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVGhlIGluZm9ybWF0aW9uIGNvbnRh aW5lZCBpbiB0aGlzIG1lc3NhZ2UgbWF5IGJlIGNvbmZpZGVudGlhbCBhbmQgbGVnYWxseSBwcm90 ZWN0ZWQgdW5kZXIgYXBwbGljYWJsZSBsYXcuIFRoZSBtZXNzYWdlIGlzIGludGVuZGVkIHNvbGVs eSBmb3IgdGhlIGFkZHJlc3NlZShzKS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lw aWVudCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgdXNlLCBmb3J3YXJkaW5nLCBk aXNzZW1pbmF0aW9uLCBvciByZXByb2R1Y3Rpb24gb2YgdGhpcyBtZXNzYWdlIGlzIHN0cmljdGx5 IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVu ZGVkIHJlY2lwaWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBieSByZXR1cm4gZS1tYWls IGFuZCBkZXN0cm95IGFsbCBjb3BpZXMgb2YgdGhlIG9yaWdpbmFsIG1lc3NhZ2UuDQo= From esko.dijk@philips.com Wed Oct 17 23:08:02 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07B0921F85AE for ; Wed, 17 Oct 2012 23:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ht40JWQYGJEs for ; Wed, 17 Oct 2012 23:08:01 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe001.messaging.microsoft.com [216.32.180.11]) by ietfa.amsl.com (Postfix) with ESMTP id 3073321F860F for ; Wed, 17 Oct 2012 23:08:01 -0700 (PDT) Received: from mail124-va3-R.bigfish.com (10.7.14.247) by VA3EHSOBE001.bigfish.com (10.7.40.21) with Microsoft SMTP Server id 14.1.225.23; Thu, 18 Oct 2012 06:08:00 +0000 Received: from mail124-va3 (localhost [127.0.0.1]) by mail124-va3-R.bigfish.com (Postfix) with ESMTP id 3746C4200C3 for ; Thu, 18 Oct 2012 06:08:00 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -33 X-BigFish: VPS-33(zz217bL15d6O9251Jc85fhzz1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dhz2dh2a8h668h839hd25hf0ah107ah1288h12a5h12bdh137ah1441h1155h) Received: from mail124-va3 (localhost.localdomain [127.0.0.1]) by mail124-va3 (MessageSwitch) id 1350540477950204_29360; Thu, 18 Oct 2012 06:07:57 +0000 (UTC) Received: from VA3EHSMHS032.bigfish.com (unknown [10.7.14.249]) by mail124-va3.bigfish.com (Postfix) with ESMTP id DA5ACA00F7; Thu, 18 Oct 2012 06:07:57 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by VA3EHSMHS032.bigfish.com (10.7.99.42) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 18 Oct 2012 06:07:57 +0000 Received: from 011-DB3MPN2-082.MGDPHG.emi.philips.com ([169.254.2.20]) by 011-DB3MMR1-005.MGDPHG.emi.philips.com ([10.128.28.55]) with mapi id 14.02.0309.003; Thu, 18 Oct 2012 07:07:55 +0100 From: "Dijk, Esko" To: "core@ietf.org" Thread-Topic: Scalability of multicast use for discovery (ticket #247) Thread-Index: Ac2s9uoOPZ6pzG7LT9++vLv1CHW/kw== Date: Thu, 18 Oct 2012 06:07:56 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618AFBE04@011-DB3MPN2-082.MGDPHG.emi.philips.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [109.38.94.116] Content-Type: multipart/alternative; boundary="_000_031DD135F9160444ABBE3B0C36CED618AFBE04011DB3MPN2082MGDP_" MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: [core] Scalability of multicast use for discovery (ticket #247) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 06:08:02 -0000 --_000_031DD135F9160444ABBE3B0C36CED618AFBE04011DB3MPN2082MGDP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, to explore possible solutions to ticket #247 (http://trac.tools.ietf.org/wg= /core/trac/ticket/247) in the WG here are some initial ideas. To enable safe use of multicast for CoAP discovery; we could include in cor= e-coap stricter requirements on multicast responding e.g.: - for site-local scope or any smaller scope, a discovery multicast request = (/.well-known/core) by an unauthenticated client MAY be responded to by a s= erver - for organization-local and global scope, a discovery multicast request by= an unauthenticated client SHOULD NOT be responsed to - for global scope, a discovery multicast request SHOULD NOT be responded t= o. Exception case is a server known to be deployed in an isolated network i= .e. multicast not propagating onto the internet or to multicast backbones. = In that case the server MUST be explicitly configured to do so. This would allow local multicast discovery (of servers previously unknown t= o the client) use cases without the side effects that the IANA appointed ex= pert mentions. regards, Esko Esko Dijk Philips Group Innovation, 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_031DD135F9160444ABBE3B0C36CED618AFBE04011DB3MPN2082MGDP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

to explore possible solutions to ticket #247 (http://trac.too= ls.ietf.org/wg/core/trac/ticket/247) in the WG here are some initial id= eas.

 

To enable safe use of multicast for CoAP discover= y; we could include in core-coap stricter requirements on multicast respond= ing e.g.:

 

- for site-local scope or any smaller scope, a di= scovery multicast request (/.well-known/core) by an unauthenticated client = MAY be responded to by a server

- for organization-local and global scope, a disc= overy multicast request by an unauthenticated client SHOULD NOT be response= d to

- for global scope, a discovery multicast request= SHOULD NOT be responded to. Exception case is a server known to be deploye= d in an isolated network i.e. multicast not propagating onto the internet o= r to multicast backbones. In that case the server MUST be explicitly configured to do so.

 

This would allow local multicast discovery (of se= rvers previously unknown to the client) use cases without the side effects = that the IANA appointed expert mentions.

 

regards,

Esko

 

 

Esko Dijk

 

Philips Group Innovation, 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_031DD135F9160444ABBE3B0C36CED618AFBE04011DB3MPN2082MGDP_-- From zach@sensinode.com Thu Oct 18 00:04:53 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7546521F85A7 for ; Thu, 18 Oct 2012 00:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQF1l+qyv41f for ; Thu, 18 Oct 2012 00:04:51 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id AB9DF21F855D for ; Thu, 18 Oct 2012 00:04:49 -0700 (PDT) Received: from [192.168.0.116] (85-23-200-242.co.dnainternet.fi [85.23.200.242]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q9I74kj0005444; Thu, 18 Oct 2012 10:04:47 +0300 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <031DD135F9160444ABBE3B0C36CED618AFBE04@011-DB3MPN2-082.MGDPHG.emi.philips.com> Date: Thu, 18 Oct 2012 10:04:46 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <1D48EEB1-8B66-4D82-97E7-AC3B6C7F944D@sensinode.com> References: <031DD135F9160444ABBE3B0C36CED618AFBE04@011-DB3MPN2-082.MGDPHG.emi.philips.com> To: "Dijk, Esko" X-Mailer: Apple Mail (2.1084) Cc: "core@ietf.org" Subject: Re: [core] Scalability of multicast use for discovery (ticket #247) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 07:04:53 -0000 Esko, On Oct 18, 2012, at 9:07 AM, Dijk, Esko wrote: > Dear all, > =20 > to explore possible solutions to ticket #247 = (http://trac.tools.ietf.org/wg/core/trac/ticket/247) in the WG here are = some initial ideas. > =20 > To enable safe use of multicast for CoAP discovery; we could include = in core-coap stricter requirements on multicast responding e.g.: > =20 > - for site-local scope or any smaller scope, a discovery multicast = request (/.well-known/core) by an unauthenticated client MAY be = responded to by a server > - for organization-local and global scope, a discovery multicast = request by an unauthenticated client SHOULD NOT be responsed to > - for global scope, a discovery multicast request SHOULD NOT be = responded to. Exception case is a server known to be deployed in an = isolated network i.e. multicast not propagating onto the internet or to = multicast backbones. In that case the server MUST be explicitly = configured to do so. This is not just about discovery, but for responding to any multicast = CoAP request.=20 I start to be doubtful about the actual utility of the CoAP multicast = address with global scope (the risks are much greater than the benefit). = To be safer, and deal with the IANA comments completely, we could just = limit the default CoAP multicast address to local and site-local scope = only. For specialized applications where global scope could be useful, = it would be better for that application to use a dedicated multicast = address for that purpose.=20 Zach > This would allow local multicast discovery (of servers previously = unknown to the client) use cases without the side effects that the IANA = appointed expert mentions. > =20 > regards, > Esko > =20 > =20 > Esko Dijk > =20 > Philips Group Innovation, Research > High Tech Campus 34, Eindhoven, The Netherlands > esko.dijk@philips.com > =20 > =20 >=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. > _______________________________________________ > 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 From esko.dijk@philips.com Thu Oct 18 00:27:10 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D2C321F85ED for ; Thu, 18 Oct 2012 00:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.849 X-Spam-Level: X-Spam-Status: No, score=-3.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KjDtAHXLbu6T for ; Thu, 18 Oct 2012 00:27:09 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id D9F6221F85AA for ; Thu, 18 Oct 2012 00:27:08 -0700 (PDT) Received: from mail96-ch1-R.bigfish.com (10.43.68.252) by CH1EHSOBE002.bigfish.com (10.43.70.52) with Microsoft SMTP Server id 14.1.225.23; Thu, 18 Oct 2012 07:27:07 +0000 Received: from mail96-ch1 (localhost [127.0.0.1]) by mail96-ch1-R.bigfish.com (Postfix) with ESMTP id 6E0C538013B; Thu, 18 Oct 2012 07:27:07 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -41 X-BigFish: VPS-41(zz217bL98dI15d6O9371I9251Jd6eah542M1432Izz1202h1d1ah1d2ahzz8275ch1033IL17326ah8275bh8275dhz2dh2a8h668h839h944hd25hf0ah107ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1155h) Received: from mail96-ch1 (localhost.localdomain [127.0.0.1]) by mail96-ch1 (MessageSwitch) id 1350545224997013_7018; Thu, 18 Oct 2012 07:27:04 +0000 (UTC) Received: from CH1EHSMHS020.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.232]) by mail96-ch1.bigfish.com (Postfix) with ESMTP id E18CA8007F; Thu, 18 Oct 2012 07:27:04 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CH1EHSMHS020.bigfish.com (10.43.70.20) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 18 Oct 2012 07:27:02 +0000 Received: from 011-DB3MPN2-082.MGDPHG.emi.philips.com ([169.254.2.20]) by 011-DB3MMR1-010.MGDPHG.emi.philips.com ([10.128.28.49]) with mapi id 14.02.0309.003; Thu, 18 Oct 2012 08:27:00 +0100 From: "Dijk, Esko" To: Zach Shelby Thread-Topic: [core] Scalability of multicast use for discovery (ticket #247) Thread-Index: Ac2s9uoOPZ6pzG7LT9++vLv1CHW/k////x4A///qPrA= Date: Thu, 18 Oct 2012 07:27:00 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618AFBE78@011-DB3MPN2-082.MGDPHG.emi.philips.com> References: <031DD135F9160444ABBE3B0C36CED618AFBE04@011-DB3MPN2-082.MGDPHG.emi.philips.com> <1D48EEB1-8B66-4D82-97E7-AC3B6C7F944D@sensinode.com> In-Reply-To: <1D48EEB1-8B66-4D82-97E7-AC3B6C7F944D@sensinode.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.103] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: "core@ietf.org" Subject: Re: [core] Scalability of multicast use for discovery (ticket #247) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 07:27:10 -0000 I agree, since the CoRE discovery use cases seem to be all for link-local o= r site-local scope multicast. For the IPv4 address assignment, there's no site-local IPv4 but looking at = the IANA registry (http://www.iana.org/assignments/multicast-addresses/mult= icast-addresses.xml#multicast-addresses-3 ) it looks somewhat like the ad-h= oc block I (224.0.2.0 - 224.0.255.255) has taken on this function? Since th= ere are some recent additions of single addresses in there. Alternatively we only register link-local for IPv4. Esko -----Original Message----- From: Zach Shelby [mailto:zach@sensinode.com]=20 Sent: Thursday 18 October 2012 9:05 To: Dijk, Esko Cc: core@ietf.org Subject: Re: [core] Scalability of multicast use for discovery (ticket #247= ) Esko, On Oct 18, 2012, at 9:07 AM, Dijk, Esko wrote: > Dear all, > =20 > to explore possible solutions to ticket #247 (http://trac.tools.ietf.org/= wg/core/trac/ticket/247) in the WG here are some initial ideas. > =20 > To enable safe use of multicast for CoAP discovery; we could include in c= ore-coap stricter requirements on multicast responding e.g.: > =20 > - for site-local scope or any smaller scope, a discovery multicast reques= t (/.well-known/core) by an unauthenticated client MAY be responded to by a= server > - for organization-local and global scope, a discovery multicast request = by an unauthenticated client SHOULD NOT be responsed to > - for global scope, a discovery multicast request SHOULD NOT be responded= to. Exception case is a server known to be deployed in an isolated network= i.e. multicast not propagating onto the internet or to multicast backbones= . In that case the server MUST be explicitly configured to do so. This is not just about discovery, but for responding to any multicast CoAP = request.=20 I start to be doubtful about the actual utility of the CoAP multicast addre= ss with global scope (the risks are much greater than the benefit). To be s= afer, and deal with the IANA comments completely, we could just limit the d= efault CoAP multicast address to local and site-local scope only. For speci= alized applications where global scope could be useful, it would be better = for that application to use a dedicated multicast address for that purpose.= =20 Zach > This would allow local multicast discovery (of servers previously unknown= to the client) use cases without the side effects that the IANA appointed = expert mentions. > =20 > regards, > Esko > =20 > =20 > Esko Dijk > =20 > Philips Group Innovation, Research > High Tech Campus 34, Eindhoven, The Netherlands > esko.dijk@philips.com > =20 > =20 >=20 > The information contained in this message may be confidential and legally= protected under applicable law. The message is intended solely for the add= ressee(s). If you are not the intended recipient, you are hereby notified t= hat any use, forwarding, dissemination, or reproduction of this message is = strictly prohibited and may be unlawful. If you are not the intended recipi= ent, please contact the sender by return e-mail and destroy all copies of t= he original message. > _______________________________________________ > 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 From trac+core@trac.tools.ietf.org Thu Oct 18 03:53:25 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4618621F85ED for ; Thu, 18 Oct 2012 03:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSymvxUjqXeb for ; Thu, 18 Oct 2012 03:53:24 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 5F58E21F85C2 for ; Thu, 18 Oct 2012 03:53:24 -0700 (PDT) Received: from localhost ([127.0.0.1]:40581 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TOniy-0006H2-9X; Thu, 18 Oct 2012 12:53:12 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: esko.dijk@philips.com X-Trac-Project: core Date: Thu, 18 Oct 2012 10:53:12 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/248 Message-ID: <060.d0703ca4d5f94f46e5ca1e5e42b0b1e3@trac.tools.ietf.org> X-Trac-Ticket-ID: 248 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] #248: Remove IANA request for multicast addresses 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: Thu, 18 Oct 2012 10:53:25 -0000 #248: Remove IANA request for multicast addresses Remove IANA request for multicast addresses - already done in core-coap. -- -------------------------+-------------------------- Reporter: esko.dijk@… | Owner: Akbar Rahman Type: editorial | Status: new Priority: major | Milestone: Component: groupcomm | Version: Severity: - | Keywords: -------------------------+-------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Thu Oct 18 04:57:23 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 382BC21F86BD for ; Thu, 18 Oct 2012 04:57:23 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5WPfl3MCiofz for ; Thu, 18 Oct 2012 04:57:22 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 7262B21F86B8 for ; Thu, 18 Oct 2012 04:57:15 -0700 (PDT) Received: from localhost ([127.0.0.1]:46763 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TOoih-0006PU-5b; Thu, 18 Oct 2012 13:56:59 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: esko.dijk@philips.com X-Trac-Project: core Date: Thu, 18 Oct 2012 11:56:59 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/248#comment:1 Message-ID: <075.e41ad6239277a47a3881bda5a9abaf9e@trac.tools.ietf.org> References: <060.d0703ca4d5f94f46e5ca1e5e42b0b1e3@trac.tools.ietf.org> X-Trac-Ticket-ID: 248 In-Reply-To: <060.d0703ca4d5f94f46e5ca1e5e42b0b1e3@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #248: Remove IANA request for multicast addresses 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: Thu, 18 Oct 2012 11:57:23 -0000 #248: Remove IANA request for multicast addresses Changes (by esko.dijk@…): * status: new => closed * resolution: => fixed Comment: Removed in GroupComm-03. -- -------------------------+--------------------------- Reporter: esko.dijk@… | Owner: Akbar Rahman Type: editorial | Status: closed Priority: major | Milestone: Component: groupcomm | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+--------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Thu Oct 18 05:00:27 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71BE821F85C2 for ; Thu, 18 Oct 2012 05:00:27 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ae1sWoqB+rAd for ; Thu, 18 Oct 2012 05:00:26 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 651A921F85AC for ; Thu, 18 Oct 2012 05:00:26 -0700 (PDT) Received: from localhost ([127.0.0.1]:47057 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TOolw-00079k-Oz; Thu, 18 Oct 2012 14:00:20 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Thu, 18 Oct 2012 12:00:20 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/186#comment:1 Message-ID: <075.edfa61196063b22ebcd1c1ba071d9506@trac.tools.ietf.org> References: <060.eb5c7fd492cee5e575b774073d7222ad@trac.tools.ietf.org> X-Trac-Ticket-ID: 186 In-Reply-To: <060.eb5c7fd492cee5e575b774073d7222ad@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, esko.dijk@philips.com Resent-Message-Id: <20121018120026.651A921F85AC@ietfa.amsl.com> Resent-Date: Thu, 18 Oct 2012 05:00:26 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #186: Clearer guidance on group operations (PUT/POST/GET) 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: Thu, 18 Oct 2012 12:00:27 -0000 #186: Clearer guidance on group operations (PUT/POST/GET) Changes (by esko.dijk@…): * status: new => closed * resolution: => fixed Comment: Guidance on which methods to use is more clear: only idempotent methods. Definition of a group in terms of CoAP endpoints and naming/identification (Group Name, Group FQDN, IP address(es)) is added. -- -------------------------+------------------------------------------ Reporter: esko.dijk@… | Owner: draft-ietf-core-groupcomm@… Type: task | Status: closed Priority: major | Milestone: Component: groupcomm | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+------------------------------------------ Ticket URL: core From trac+core@trac.tools.ietf.org Thu Oct 18 05:53:41 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3DA521F847F for ; Thu, 18 Oct 2012 05:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aAKwuHPoIyG8 for ; Thu, 18 Oct 2012 05:53:41 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 3D1C221F8470 for ; Thu, 18 Oct 2012 05:53:41 -0700 (PDT) Received: from localhost ([127.0.0.1]:51717 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TOpbM-0000VU-Md; Thu, 18 Oct 2012 14:53:28 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: esko.dijk@philips.com X-Trac-Project: core Date: Thu, 18 Oct 2012 12:53:28 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/249 Message-ID: <060.29749b8fad902a3784a94a2457c2885e@trac.tools.ietf.org> X-Trac-Ticket-ID: 249 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] #249: Add means for configuring group membership in endpoints 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: Thu, 18 Oct 2012 12:53:41 -0000 #249: Add means for configuring group membership in endpoints GroupComm: Add a common means for configuring group membership in endpoints, to support use cases where group membership may change over time, or membership is changed by a commissioning process. Configuration may include group name and group multicast IP address. A first mechanism will be added to the draft to initiate discussion/comments on this topic. -- ----------------------------------+-------------------------- Reporter: esko.dijk@… | Owner: Akbar Rahman Type: protocol enhancement | Status: new Priority: major | Milestone: Component: groupcomm | Version: Severity: - | Keywords: ----------------------------------+-------------------------- Ticket URL: core From gilger@itsec.rwth-aachen.de Thu Oct 18 07:09:06 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE1121F859E for ; Thu, 18 Oct 2012 07:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id omeDIimhMYDB for ; Thu, 18 Oct 2012 07:09:05 -0700 (PDT) Received: from avalon.gnuzifer.de (avalon.gnuzifer.de [IPv6:2a01:4f8:121:43c1::a2:1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C54321F8495 for ; Thu, 18 Oct 2012 07:09:05 -0700 (PDT) Received: from [137.226.161.159] (port=60624 helo=localhost) by avalon.gnuzifer.de with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1TOqmT-0004FO-37; Thu, 18 Oct 2012 16:09:01 +0200 Date: Thu, 18 Oct 2012 16:09:40 +0200 From: Johannes Gilger To: "Keoh, Sye Loong" Message-ID: <20121018140940.GA13067@blackbox> References: <20121016082346.GA29405@blackbox> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: 137.226.161.159 X-SA-Exim-Mail-From: gilger@itsec.rwth-aachen.de Cc: "Cullen Jennings \(fluffy\)" , core WG Subject: Re: [core] Draft on secure enrollment X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 14:09:06 -0000 Hey Sye Loong, let me see if I understood your argument: > In some use cases, the manufacturers would like to ensure that only > the authorized devices can be installed in a system. What kind of knowledge does the manufacturer have about the system? I am building a Smart Object network with components from various vendors, and one interface-constrained device just happens to be built by manufacturer x. > Correct me if I am wrong, this could prevent device cloning such that > OTP that has already been used cannot be activated/associated with the > controller. Cloning? As in copying the keys on the device and putting them in cheap knock-off hardware? Sure, this would help. But then again I could also manufacture cheap knock-offs and have them not require any online procedure during enrollment. Maybe I didn't get your point on this one. > In this context, there are benefits for having the Transfer Agent, and > I see the role of 'introducer' as a commissioning tool that is used to > identify the device to be installed. I'm not arguing about the Introducer here, just about the transfer agent (and online connectivity). > Maybe it's good to separate the use case of a completely stand-alone > deployment where no online connectivity is available, then the scheme > suggested by Johannes is probably sufficient. In case that online > connectivity is available, devices can be validated with the TA in the > backend. I agree that one benefit of an online TA would be that you can not simply clone a device along with its proof of authenticity. If that is one of the more important features of Cullen's proposal, it should be stated more clearly. > I also have the same question as Johannes, why do we need so many > secrets, i.e., OTP, DevSecret, TaSecret? Presumably, if the TA also > knows the DevSecret or the OTP, then a secure channel can be > established between them without requiring the TaSecret. No, if we are really using the TA, then we probably need all of these secrets. The TA must not know the DevSecret or it could eavesdrop on us changing our key. On the other hand, an attacker that is able to read the QR code (before or after deployment) could read our DevSecret and in turn also intercept / modify our messages which refresh the DevSecret. So the QR code should be separated from the device during installation, or we have to perform the DevSecret refresh before anyone else can read the QR code. Looking at it that way, it could also work to have an OTP on the device and a symmetric password DevSecret on the controller. The Introducer could fetch the DevSecret from its controller, send it to the TA along with the OTP. The TA would forward it to the device (encapsulated with TaSecret) along with the ID of our controller. In this case, the only one able to attack us would be the TA, and then only if it can modify messages while we are changing our DevSecret. (I assume an integrity-protected Diffie Hellman to generate the new DevSecret, protected by the current DevSecret). The proposal under "Open Issue" at the end of the draft would protect against both: A DevSecret and a ContSecret, where the ContSecret is only sent to the TA (and then to the device) and the DevSecret is only read from the QR by the introducer. A locally present attack can not get the ContSecret and the TA can not read the DevSecret. > Just a question, is the TaSecret unique per device or it's a common > secret for all devices? If it were common for all device, every enrollment message from the TA could be intercepted as soon as someone gets the TaSecret from the device. > Lastly, how about device replacement and re-installation of the > device? Requiring the user to bring the device back to the > manufacturer is not so convenient in my opinion. You can reset the device into factory-settings yourself. The problem is that you know the QR code by that point, so you could eavesdrop on any new enrollment, unless we really introduce an additional ContSecret that is chosen by the new owner of the device. Hope my thoughts did not come across too convoluted. Regards, Jojo -- Dipl.-Inform. Johannes Gilger Research Group IT-Security RWTH Aachen University Mies-van-der-Rohe-Straße 15 52074 Aachen Office: 211 Phone: +49 241 80 20781 http://itsec.rwth-aachen.de From trac+core@trac.tools.ietf.org Fri Oct 19 05:21:37 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D73AD21F8611 for ; Fri, 19 Oct 2012 05:21:37 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yLn9ostO4HfV for ; Fri, 19 Oct 2012 05:21:37 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 2E89421F86C8 for ; Fri, 19 Oct 2012 05:21:37 -0700 (PDT) Received: from localhost ([127.0.0.1]:45276 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TPBZs-0008GJ-Ne; Fri, 19 Oct 2012 14:21:24 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: esko.dijk@philips.com X-Trac-Project: core Date: Fri, 19 Oct 2012 12:21:24 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/249#comment:1 Message-ID: <075.ea644bf7e964510d65a74608d6e0aed7@trac.tools.ietf.org> References: <060.29749b8fad902a3784a94a2457c2885e@trac.tools.ietf.org> X-Trac-Ticket-ID: 249 In-Reply-To: <060.29749b8fad902a3784a94a2457c2885e@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #249: Add means for configuring group membership in endpoints 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: Fri, 19 Oct 2012 12:21:38 -0000 #249: Add means for configuring group membership in endpoints Changes (by esko.dijk@…): * status: new => closed * resolution: => fixed Comment: Placeholder section now included in groupcomm-03. -- ----------------------------------+--------------------------- Reporter: esko.dijk@… | Owner: Akbar Rahman Type: protocol enhancement | Status: closed Priority: major | Milestone: Component: groupcomm | Version: Severity: - | Resolution: fixed Keywords: | ----------------------------------+--------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Fri Oct 19 05:23:14 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB0F321F8620 for ; Fri, 19 Oct 2012 05:23:14 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3NNOO2qAvFF0 for ; Fri, 19 Oct 2012 05:23:14 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 1F37421F8489 for ; Fri, 19 Oct 2012 05:23:14 -0700 (PDT) Received: from localhost ([127.0.0.1]:45455 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TPBba-000242-F9; Fri, 19 Oct 2012 14:23:10 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Fri, 19 Oct 2012 12:23:10 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/250 Message-ID: <060.1065c7b93afca547f89e145054b44266@trac.tools.ietf.org> X-Trac-Ticket-ID: 250 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, esko.dijk@philips.com Resent-Message-Id: <20121019122314.1F37421F8489@ietfa.amsl.com> Resent-Date: Fri, 19 Oct 2012 05:23:14 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #250: Mention CoAP NoSec mode is to be used for CoAP multicast 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: Fri, 19 Oct 2012 12:23:15 -0000 #250: Mention CoAP NoSec mode is to be used for CoAP multicast GroupComm: Mention in security considerations that CoAP NoSec mode is to be used for CoAP multicast - since there no other mechanism defined currently. -- -------------------------+----------------------------------------- Reporter: esko.dijk@… | Owner: draft-ietf-core-groupcomm@… Type: editorial | Status: new Priority: minor | Milestone: Component: groupcomm | Version: Severity: - | Keywords: -------------------------+----------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Fri Oct 19 05:28:08 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DED121F8634 for ; Fri, 19 Oct 2012 05:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7bp8m9gFEnJ2 for ; Fri, 19 Oct 2012 05:28:07 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 807CD21F8630 for ; Fri, 19 Oct 2012 05:28:07 -0700 (PDT) Received: from localhost ([127.0.0.1]:45917 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TPBgA-0002Db-2e; Fri, 19 Oct 2012 14:27:54 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Fri, 19 Oct 2012 12:27:54 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/251 Message-ID: <060.5552119b3d77e905bc167e32e3a0640b@trac.tools.ietf.org> X-Trac-Ticket-ID: 251 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, esko.dijk@philips.com Resent-Message-Id: <20121019122807.807CD21F8630@ietfa.amsl.com> Resent-Date: Fri, 19 Oct 2012 05:28:07 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #251: Clarify how to handle mixture of success/error responses 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: Fri, 19 Oct 2012 12:28:08 -0000 #251: Clarify how to handle mixture of success/error responses GroupComm: Clarify that a group resource manipulation may return back a mixture of successful and unsuccessful responses. If the client needs to do anything special to handle this mix, also mention it. Remark came from the IETF84 CoRE WG meeting. -- -------------------------+----------------------------------------- Reporter: esko.dijk@… | Owner: draft-ietf-core-groupcomm@… Type: editorial | Status: new Priority: minor | Milestone: Component: groupcomm | Version: Severity: - | Keywords: -------------------------+----------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Fri Oct 19 05:37:57 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D98121F8495 for ; Fri, 19 Oct 2012 05:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LnTHOts872o4 for ; Fri, 19 Oct 2012 05:37:56 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id B49B321F8480 for ; Fri, 19 Oct 2012 05:37:56 -0700 (PDT) Received: from localhost ([127.0.0.1]:46622 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TPBpf-0001wo-I3; Fri, 19 Oct 2012 14:37:43 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Fri, 19 Oct 2012 12:37:43 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/251#comment:1 Message-ID: <075.cb7749a36e2f736949d2cf04085564d1@trac.tools.ietf.org> References: <060.5552119b3d77e905bc167e32e3a0640b@trac.tools.ietf.org> X-Trac-Ticket-ID: 251 In-Reply-To: <060.5552119b3d77e905bc167e32e3a0640b@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, esko.dijk@philips.com Resent-Message-Id: <20121019123756.B49B321F8480@ietfa.amsl.com> Resent-Date: Fri, 19 Oct 2012 05:37:56 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #251: Clarify how to handle mixture of success/error responses 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: Fri, 19 Oct 2012 12:37:57 -0000 #251: Clarify how to handle mixture of success/error responses Changes (by esko.dijk@…): * status: new => closed * resolution: => fixed Comment: done in groupcomm-03; no special actions to handle this mixture are defined currently. -- -------------------------+------------------------------------------ Reporter: esko.dijk@… | Owner: draft-ietf-core-groupcomm@… Type: editorial | Status: closed Priority: minor | Milestone: Component: groupcomm | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+------------------------------------------ Ticket URL: core From trac+core@trac.tools.ietf.org Fri Oct 19 05:38:10 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAAA021F8480 for ; Fri, 19 Oct 2012 05:38:10 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qBYpcJoMzE9x for ; Fri, 19 Oct 2012 05:38:10 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 2247621F8594 for ; Fri, 19 Oct 2012 05:38:10 -0700 (PDT) Received: from localhost ([127.0.0.1]:46628 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TPBq2-0000XZ-US; Fri, 19 Oct 2012 14:38:07 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Fri, 19 Oct 2012 12:38:06 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/250#comment:1 Message-ID: <075.34f39f617ef2766f98afe671c84e23dc@trac.tools.ietf.org> References: <060.1065c7b93afca547f89e145054b44266@trac.tools.ietf.org> X-Trac-Ticket-ID: 250 In-Reply-To: <060.1065c7b93afca547f89e145054b44266@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, esko.dijk@philips.com Resent-Message-Id: <20121019123810.2247621F8594@ietfa.amsl.com> Resent-Date: Fri, 19 Oct 2012 05:38:10 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #250: Mention CoAP NoSec mode is to be used for CoAP multicast 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: Fri, 19 Oct 2012 12:38:10 -0000 #250: Mention CoAP NoSec mode is to be used for CoAP multicast Changes (by esko.dijk@…): * status: new => closed * resolution: => fixed Comment: done in groupcomm-03 -- -------------------------+------------------------------------------ Reporter: esko.dijk@… | Owner: draft-ietf-core-groupcomm@… Type: editorial | Status: closed Priority: minor | Milestone: Component: groupcomm | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+------------------------------------------ Ticket URL: core From internet-drafts@ietf.org Fri Oct 19 07:27:42 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B089821F85A4; Fri, 19 Oct 2012 07:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.51 X-Spam-Level: X-Spam-Status: No, score=-102.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eaBvfW7SPmzi; Fri, 19 Oct 2012 07:27:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 308A121F86E8; Fri, 19 Oct 2012 07:27:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121019142742.11275.83577.idtracker@ietfa.amsl.com> Date: Fri, 19 Oct 2012 07:27:42 -0700 Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-groupcomm-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, 19 Oct 2012 14:27:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Constrained RESTful Environments Working = Group of the IETF. Title : Group Communication for CoAP Author(s) : Akbar Rahman Esko Dijk Filename : draft-ietf-core-groupcomm-03.txt Pages : 27 Date : 2012-10-19 Abstract: CoAP is a RESTful transfer protocol for constrained devices. It is anticipated that constrained devices will often naturally operate in groups (e.g. in a building automation scenario all lights in a given room may need to be switched on/off as a group). This document defines how the CoAP protocol should be used in a group communication context. An approach for using CoAP on top of IP multicast is detailed for both constrained and un-constrained networks. Also, various use causes and corresponding protocol flows are provided to illustrate important concepts. Finally, guidance is provided for deployment in various network topologies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-groupcomm There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-core-groupcomm-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-groupcomm-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Akbar.Rahman@InterDigital.com Fri Oct 19 07:32:56 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2585921F8707 for ; Fri, 19 Oct 2012 07:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hynHzEp3s+5g for ; Fri, 19 Oct 2012 07:32:55 -0700 (PDT) Received: from idcout.InterDigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 6E7B621F86EC for ; Fri, 19 Oct 2012 07:32:55 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 19 Oct 2012 10:32:54 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 19 Oct 2012 10:32:53 -0400 Message-ID: In-Reply-To: <20121019142742.11275.83577.idtracker@ietfa.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] I-D Action: draft-ietf-core-groupcomm-03.txt Thread-Index: Ac2uBeiDjtN2wpHfTTyKtcci2pq82wAAAydA References: <20121019142742.11275.83577.idtracker@ietfa.amsl.com> From: "Rahman, Akbar" To: X-OriginalArrivalTime: 19 Oct 2012 14:32:54.0088 (UTC) FILETIME=[9FFE1C80:01CDAE06] Subject: Re: [core] I-D Action: draft-ietf-core-groupcomm-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, 19 Oct 2012 14:32:56 -0000 Hi, Esko and I posted a new revision of the Group Communication I-D. The changes were made to address the open tickets as follows: Changes from ietf-02 to ietf-03: o Clarified that a group resource manipulation may return back a mixture of successful and unsuccessful responses (section 3.4 and Figure 6) (#251). o Clarified that security option for group communication must be NoSec mode (section 6) (#250). o Added mechanism for group membership configuration (#249). o Removed IANA request for multicast addresses (section 7) and replaced with a note indicating that the request is being made in [I-D.ietf-core-coap] (#248). o Made the definition of 'group' more specific to group of CoAP endpoints and included text on UDP port selection (#186). o Added explanatory text in section 3.4 regarding why not to use group communication for non-idempotent messages (i.e. CoAP POST) (#186). o Changed link-local RD discovery to site-local in RD discovery use case to make it more realistic. o Fixed lighting control use case CoAP proxying; now returns individual CoAP responses as in coap-12. o Replaced link format I-D with RFC6690 reference. o Various editorial updates for improved readability Looking forward to discussing with all of you in Atlanta. /Akbar and Esko -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Friday, October 19, 2012 10:28 AM To: i-d-announce@ietf.org Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-groupcomm-03.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments Working Group of the IETF. Title : Group Communication for CoAP Author(s) : Akbar Rahman Esko Dijk Filename : draft-ietf-core-groupcomm-03.txt Pages : 27 Date : 2012-10-19 Abstract: CoAP is a RESTful transfer protocol for constrained devices. It is anticipated that constrained devices will often naturally operate in groups (e.g. in a building automation scenario all lights in a given room may need to be switched on/off as a group). This document defines how the CoAP protocol should be used in a group communication context. An approach for using CoAP on top of IP multicast is detailed for both constrained and un-constrained networks. Also, various use causes and corresponding protocol flows are provided to illustrate important concepts. Finally, guidance is provided for deployment in various network topologies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-groupcomm There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-core-groupcomm-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-groupcomm-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From internet-drafts@ietf.org Sun Oct 21 04:59:07 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3EC521F885E; Sun, 21 Oct 2012 04:59:07 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bs739zUsZsoI; Sun, 21 Oct 2012 04:59:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DBA921F85B0; Sun, 21 Oct 2012 04:59:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121021115907.4757.95800.idtracker@ietfa.amsl.com> Date: Sun, 21 Oct 2012 04:59:07 -0700 Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-block-10.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Oct 2012 11:59:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Constrained RESTful Environments Working = Group of the IETF. Title : Blockwise transfers in CoAP Author(s) : Carsten Bormann Zach Shelby Filename : draft-ietf-core-block-10.txt Pages : 29 Date : 2012-10-21 Abstract: CoAP is a RESTful transfer protocol for constrained nodes and networks. Basic CoAP messages work well for the small payloads we expect from temperature sensors, light switches, and similar building-automation devices. Occasionally, however, applications will need to transfer larger payloads -- for instance, for firmware updates. With HTTP, TCP does the grunt work of slicing large payloads up into multiple packets and ensuring that they all arrive and are handled in the right order. CoAP is based on datagram transports such as UDP or DTLS, which limits the maximum size of resource representations that can be transferred without too much fragmentation. Although UDP supports larger payloads through IP fragmentation, it is limited to 64 KiB and, more importantly, doesn't really work well for constrained applications and networks. Instead of relying on IP fragmentation, this specification extends basic CoAP with a pair of "Block" options, for transferring multiple blocks of information from a resource representation in multiple request-response pairs. In many important cases, the Block options enable a server to be truly stateless: the server can handle each block transfer separately, with no need for a connection setup or other server-side memory of previous block transfers. In summary, the Block options provide a minimal way to transfer larger representations in a block-wise fashion. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-block There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-core-block-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-block-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From cabo@tzi.org Sun Oct 21 05:01:51 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2008021F8991 for ; Sun, 21 Oct 2012 05:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.087 X-Spam-Level: X-Spam-Status: No, score=-106.087 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pa9+UZNR6VHK for ; Sun, 21 Oct 2012 05:01:50 -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 43E2D21F8917 for ; Sun, 21 Oct 2012 05:01:49 -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 q9LC1elX003398; Sun, 21 Oct 2012 14:01:40 +0200 (CEST) Received: from [127.0.0.1] (fido.informatik.uni-bremen.de [134.102.218.23]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 38EC4C83; Sun, 21 Oct 2012 14:01:38 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Carsten Bormann In-Reply-To: <4A5669C5-3473-4223-94EF-5C5CF4B01DA6@tzi.org> Date: Sun, 21 Oct 2012 14:01:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <38625A17-06C8-4C28-8D97-BFC99A54A95E@tzi.org> References: <201210171502.52422.mab@comnets.uni-bremen.de> <4A5669C5-3473-4223-94EF-5C5CF4B01DA6@tzi.org> To: Markus Becker , "core@ietf.org WG" X-Mailer: Apple Mail (2.1499) Subject: Re: [core] CoAP Block: zero length default values 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, 21 Oct 2012 12:01:51 -0000 On Oct 17, 2012, at 15:53, Carsten Bormann wrote: > Well, maybe it is indeed best to get rid of the fiction of a "default = value" for Block1/2. > [...] > Very timely input for the upcoming -10, thanks! Well, I decided to backport this and submit a -10 with just this fix, = and with the new option numbers that fit coap-12. (Otherwise these small but important updates would be buried in the = large number of outstanding editorial changes, which are now scheduled = for block-11.) Htmlized: http://tools.ietf.org/html/draft-ietf-core-block-10 Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-block-10 Gr=FC=DFe, Carsten From kujtimhyseni@hotmail.com Mon Oct 22 02:11:18 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 855FC21F8A09 for ; Mon, 22 Oct 2012 02:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHxVlRJvw-MI for ; Mon, 22 Oct 2012 02:11:17 -0700 (PDT) Received: from col0-omc1-s2.col0.hotmail.com (col0-omc1-s2.col0.hotmail.com [65.55.34.12]) by ietfa.amsl.com (Postfix) with ESMTP id 9D1A021F8A2F for ; Mon, 22 Oct 2012 02:11:17 -0700 (PDT) Received: from COL107-W4 ([65.55.34.9]) by col0-omc1-s2.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 22 Oct 2012 02:11:16 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_df540467-c1dd-480a-a0bb-f491f3f773d0_" X-Originating-IP: [109.245.59.26] From: Kujtim Hyseni To: Date: Mon, 22 Oct 2012 09:11:16 +0000 Importance: Normal In-Reply-To: References: , MIME-Version: 1.0 X-OriginalArrivalTime: 22 Oct 2012 09:11:16.0380 (UTC) FILETIME=[30E6CDC0:01CDB035] Subject: Re: [core] CoAP accessed from standard RESTful client X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 09:11:18 -0000 --_df540467-c1dd-480a-a0bb-f491f3f773d0_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Carsten=2C thank you for replying and introducing your forum. I have few questions indeed regarding the CoAP: 1) Who is the language for describing CoAP web service functionalities? Sin= ce it is RESTful=2C regarding the Master's work at http://code.google.com/p= /rest-api-code-gen/ I suppose is the WADL (Web Application Description Lang= uage)=2C although there are presented other languages. Also=2C there states= that WSDL 2.0 is also able to describe RESTful web services. But=2C I want= also to know your opinion? 2) In my previous email (see it below) I have asked "How can be accessed th= e CoAP based embedded device from standard RESTful client?". Since it is st= ill unclear I will comment further this question: I intend to access CoAP b= ased device from Personal Computer. Also=2C I would like to have a "common"= way of accessing CoAP device - a way to consider it as a usual RESTful we= b service from the client's view point. Other alternative would be: Are the= re tools for generating CoAP RESTful clients given its description file? - = server is my problem=2C and it usually provides data read from sensor. I still don't know whether my question 2) is clear now? Yes when I say "sta= ndard RESTful client" I mean "existing HTTP client". Best Wishes=2C Kujtim Hyseni > Subject: Re: CoAP accessed from standard RESTful client > From: cabo@tzi.org > Date: Sat=2C 20 Oct 2012 13:12:15 +0200 > CC: draft-ietf-core-coap@tools.ietf.org > To: kujtimhyseni@hotmail.com >=20 > Hi Kujtim=2C >=20 > I think when you say "standard RESTful client" you mean "existing HTTP cl= ient". > (Both CoAP and HTTP are based on the REST model=2C and both are=2C or are= intended to be=2C standards.) >=20 > Indeed=2C the existing HTTP client could learn CoAP as a second protocol = (I think that is your alternative 1) or it could make use of a proxy that t= ranslates the HTTP requests into CoAP requests=2C and the CoAP responses in= to HTTP responses. >=20 > What kind of existing HTTP client do you have in mind? >=20 > oOo >=20 >=20 > As a general observation=2C if you want to work in the CoRE/CoAP space=2C= it is best to subscribe to the CoRE mailing list at: >=20 > https://www.ietf.org/mailman/listinfo/core >=20 > and ask questions there=2C so others can benefit from the answers as well= . >=20 > Gr=FC=DFe=2C Carsten >=20 >=20 > On Oct 20=2C 2012=2C at 12:05=2C Kujtim Hyseni = wrote: >=20 > > Dear Mr./Mme.=2C > >=20 > > I have a question for You regarding the access of CoAP based embedded s= erver from standard RESTful client. > >=20 > > How can be accessed the CoAP based embedded device from standard RESTfu= l client? > >=20 > > I have two possibilities in my mind: > > 1) The client is dedicated i.e. it is based on CoAP. > > 2) There is a gateway/proxy which translates (compresses) original full= RESTful requests to CoAP and vice versa - decompresses responses to standa= rd RESTful protocol. > >=20 > > Waiting for response=2C > >=20 > > Best Wishes=2C > > Kujtim Hyseni PhD student >=20 = --_df540467-c1dd-480a-a0bb-f491f3f773d0_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Carsten=2C

thank you for replying and introducing your forum.
=
I have few questions indeed regarding the CoAP:

1) Who is the la= nguage for describing CoAP web service functionalities? Since it is RESTful= =2C regarding the Master's work at http://code.google.com/p/rest-api-code-g= en/ I suppose is the WADL (Web Application Description Language)=2C althoug= h there are presented other languages. Also=2C there states that WSDL 2.0 i= s also able to describe RESTful web services. But=2C I want also to know yo= ur opinion?

2) In my previous email (see it below) I have asked "How= can be accessed the CoAP based embedded device from standard RESTful clien= t?". Since it is still unclear I will comment further this question: I inte= nd to access CoAP based device from Personal Computer. Also=2C I would like= to have a "common" way of accessing CoAP device - =3B a way to conside= r it as a usual RESTful web service from the client's view point. Other alt= ernative would be: Are there tools for generating CoAP RESTful clients give= n its description file? - server is my problem=2C and it usually provides d= ata read from sensor.
I still don't know whether my question 2) is clear= now? Yes when I say "standard RESTful client" I mean "existing HTTP client= ".

Best Wishes=2C
Kujtim Hyseni

>=3B Subject: Re: CoAP accessed from standard RESTful cl= ient
>=3B From: cabo@tzi.org
>=3B Date: Sat=2C 20 Oct 2012 13:12:= 15 +0200
>=3B CC: draft-ietf-core-coap@tools.ietf.org
>=3B To: ku= jtimhyseni@hotmail.com
>=3B
>=3B Hi Kujtim=2C
>=3B
>= =3B I think when you say "standard RESTful client" you mean "existing HTTP = client".
>=3B (Both CoAP and HTTP are based on the REST model=2C and b= oth are=2C or are intended to be=2C standards.)
>=3B
>=3B Indeed= =2C the existing HTTP client could learn CoAP as a second protocol (I think= that is your alternative 1) or it could make use of a proxy that translate= s the HTTP requests into CoAP requests=2C and the CoAP responses into HTTP = responses.
>=3B
>=3B What kind of existing HTTP client do you ha= ve in mind?
>=3B
>=3B oOo
&g= t=3B
>=3B
>=3B As a general observation=2C if you want to work = in the CoRE/CoAP space=2C it is best to subscribe to the CoRE mailing list = at:
>=3B
>=3B https://www.ietf.org/mailman/listinfo/core
>= =3B
>=3B and ask questions there=2C so others can benefit from the an= swers as well.
>=3B
>=3B Gr=FC=DFe=2C Carsten
>=3B
>= =3B
>=3B On Oct 20=2C 2012=2C at 12:05=2C Kujtim Hyseni <=3Bkujtimh= yseni@hotmail.com>=3B wrote:
>=3B
>=3B >=3B Dear Mr./Mme.=2C=
>=3B >=3B
>=3B >=3B I have a question for You regarding the= access of CoAP based embedded server from standard RESTful client.
>= =3B >=3B
>=3B >=3B How can be accessed the CoAP based embedded de= vice from standard RESTful client?
>=3B >=3B
>=3B >=3B I hav= e two possibilities in my mind:
>=3B >=3B 1) The client is dedicated= i.e. it is based on CoAP.
>=3B >=3B 2) There is a gateway/proxy whi= ch translates (compresses) original full RESTful requests to CoAP and vice = versa - decompresses responses to standard RESTful protocol.
>=3B >= =3B
>=3B >=3B Waiting for response=2C
>=3B >=3B
>=3B &= gt=3B Best Wishes=2C
>=3B >=3B Kujtim Hyseni PhD student
>=3B <= br>
= --_df540467-c1dd-480a-a0bb-f491f3f773d0_-- From cabo@tzi.org Mon Oct 22 06:39:36 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACC9921F8BC3 for ; Mon, 22 Oct 2012 06:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.101 X-Spam-Level: X-Spam-Status: No, score=-106.101 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fx3FZD6uS8kV for ; Mon, 22 Oct 2012 06:39:35 -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 849BA21F8A62 for ; Mon, 22 Oct 2012 06:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q9MDdPhX016747 for ; Mon, 22 Oct 2012 15:39:25 +0200 (CEST) Received: from [10.0.1.2] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 5948F257; Mon, 22 Oct 2012 15:39:25 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Mon, 22 Oct 2012 15:39:25 +0200 To: "core@ietf.org WG" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [core] Updated CoRE Roadmap X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 13:39:36 -0000 I have submitted an updated version of my little CoRE roadmap document. If you don't know what's going on in the WG, this is one way to get = started. If you do, you almost certainly will find pointers there you didn't know = about. If you contribute, you might want to read it to send me corrections. (There are still a couple hours left until I-D cutoff, so I might even = fix bugs today!) Enjoy: Htmlized: = http://tools.ietf.org/html/draft-bormann-core-roadmap-02 Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-bormann-core-roadmap-02 Gr=FC=DFe, Carsten From trac+core@trac.tools.ietf.org Mon Oct 22 12:29:33 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1AE421F8842 for ; Mon, 22 Oct 2012 12:29:33 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NLbbQqoXM-0e for ; Mon, 22 Oct 2012 12:29:33 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 3913721F84B2 for ; Mon, 22 Oct 2012 12:29:33 -0700 (PDT) Received: from localhost ([127.0.0.1]:35130 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TQNgk-0006oU-QU; Mon, 22 Oct 2012 21:29:26 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-core-observe@tools.ietf.org, hartke@tzi.org X-Trac-Project: core Date: Mon, 22 Oct 2012 19:29:26 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/217#comment:3 Message-ID: <066.f52a976ba8e4fef499fd96efde7227d7@trac.tools.ietf.org> References: <051.9ec4e5813aa29f30a67cab16c3a9ea51@trac.tools.ietf.org> X-Trac-Ticket-ID: 217 In-Reply-To: <051.9ec4e5813aa29f30a67cab16c3a9ea51@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-observe@tools.ietf.org, hartke@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: hartke@tzi.org Resent-Message-Id: <20121022192933.3913721F84B2@ietfa.amsl.com> Resent-Date: Mon, 22 Oct 2012 12:29:33 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #217: how fast must the observe clock be able to go? 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, 22 Oct 2012 19:29:33 -0000 #217: how fast must the observe clock be able to go? Changes (by hartke@…): * status: new => closed * resolution: => fixed Comment: Fixed in [986]: Closes #217: Done in observe-07 -- ----------------------------------+---------------------------------------- Reporter: cabo@… | Owner: draft-ietf-core-observe@… Type: protocol enhancement | Status: closed Priority: major | Milestone: post-WGLC-1 Component: observe | Version: observe-05 Severity: In WG Last Call | Resolution: fixed Keywords: | ----------------------------------+---------------------------------------- Ticket URL: core From internet-drafts@ietf.org Mon Oct 22 12:32:44 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9520021F8525; Mon, 22 Oct 2012 12:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e97Y6RJpge2e; Mon, 22 Oct 2012 12:32:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1112821F8880; Mon, 22 Oct 2012 12:32:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121022193238.19462.66812.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 12:32:38 -0700 Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-observe-07.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, 22 Oct 2012 19:32:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Constrained RESTful Environments Working = Group of the IETF. Title : Observing Resources in CoAP Author(s) : Klaus Hartke Filename : draft-ietf-core-observe-07.txt Pages : 28 Date : 2012-10-22 Abstract: CoAP is a RESTful application protocol for constrained nodes and networks. The state of a resource on a CoAP server can change over time. This document specifies a simple protocol extension for CoAP that enables a server to replicate a resource state to interested clients. The protocol follows a best-effort approach when transmitting new resource states to clients, and provides eventual consistency between the state observed by each client and the actual resource state. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-observe There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-core-observe-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-observe-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From cabo@tzi.org Mon Oct 22 13:00:43 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD08A21F869C for ; Mon, 22 Oct 2012 13:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.222 X-Spam-Level: X-Spam-Status: No, score=-106.222 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dg1YmbJkIhdY for ; Mon, 22 Oct 2012 13:00:43 -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 27AD921F8623 for ; Mon, 22 Oct 2012 13:00:42 -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 q9MK0YUj024373 for ; Mon, 22 Oct 2012 22:00:34 +0200 (CEST) Received: from [192.168.217.117] (p54893222.dip.t-dialin.net [84.137.50.34]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 94995430; Mon, 22 Oct 2012 22:00:34 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Carsten Bormann In-Reply-To: Date: Mon, 22 Oct 2012 22:00:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "core@ietf.org WG" X-Mailer: Apple Mail (2.1499) Subject: Re: [core] Updated (again) CoRE Roadmap X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 20:00:44 -0000 On Oct 22, 2012, at 15:39, Carsten Bormann wrote: > I have submitted an updated version of my little CoRE roadmap = document. >=20 > If you don't know what's going on in the WG, this is one way to get = started. > If you do, you almost certainly will find pointers there you didn't = know about. > If you contribute, you might want to read it to send me corrections. > (There are still a couple hours left until I-D cutoff, so I might even = fix bugs today!) Akbar was nice enough to supply a couple of corrections and, more = importantly,=20 a sorely needed page of text for section 5.7 (more support for sleepy = nodes). =20 I hope I have not butchered it too much. =20 So here is the -03: Htmlized: = http://tools.ietf.org/html/draft-bormann-core-roadmap-03 Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-bormann-core-roadmap-03 Gr=FC=DFe, Carsten From jara@um.es Mon Oct 22 16:16:28 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB53911E80FB for ; Mon, 22 Oct 2012 16:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XfNjgSJ-ursi for ; Mon, 22 Oct 2012 16:16:26 -0700 (PDT) Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id 5C50E11E80F5 for ; Mon, 22 Oct 2012 16:16:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id C321453664 for ; Tue, 23 Oct 2012 01:16:22 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon11.um.es Received: from xenon11.um.es ([127.0.0.1]) by localhost (xenon11.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Ier10YYyzvxb for ; Tue, 23 Oct 2012 01:16:22 +0200 (CEST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jara) by xenon11.um.es (Postfix) with ESMTPSA id E328653658 for ; Tue, 23 Oct 2012 01:16:20 +0200 (CEST) Received: by mail-da0-f44.google.com with SMTP id h15so1599229dan.31 for ; Mon, 22 Oct 2012 16:16:19 -0700 (PDT) Received: by 10.68.229.194 with SMTP id ss2mr34731727pbc.17.1350947779070; Mon, 22 Oct 2012 16:16:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.222.195 with HTTP; Mon, 22 Oct 2012 16:15:38 -0700 (PDT) In-Reply-To: <20121022145612.13563.85959.idtracker@ietfa.amsl.com> References: <20121022145612.13563.85959.idtracker@ietfa.amsl.com> From: Antonio Jara Date: Tue, 23 Oct 2012 00:15:38 +0100 Message-ID: To: "core@ietf.org WG" Content-Type: multipart/alternative; boundary=047d7b339c4d7b497704ccae0a8c Subject: [core] New Version Notification for draft-li-core-conditional-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: Mon, 22 Oct 2012 23:16:28 -0000 --047d7b339c4d7b497704ccae0a8c Content-Type: text/plain; charset=ISO-8859-1 A new version of I-D, draft-li-core-conditional-observe-03.txt has been successfully submitted by Jeroen Hoebeke and posted to the IETF repository. Filename: draft-li-core-conditional-observe Revision: 03 Title: Conditional observe in CoAP Creation date: 2012-10-22 WG ID: Individual Submission Number of pages: 29 URL: http://www.ietf.org/internet-drafts/draft-li-core-conditional-observe-03.txt Status: http://datatracker.ietf.org/doc/draft-li-core-conditional-observe Htmlized: http://tools.ietf.org/html/draft-li-core-conditional-observe-03 Diff: http://www.ietf.org/rfcdiff?url2=draft-li-core-conditional-observe-03 Abstract: CoAP is a RESTful application protocol for constrained nodes and networks. Through the Observe option, clients can observe changes in the state of resources and obtain a current representation of the last resource state. This document defines a new mechanism in CoAP Observe so that a CoAP client can conditionally observe a resource on a CoAP server, only being informed about state changes meeting a specific condition or set of conditions. This offers possibilities to extend network intelligence, enhance scalability, and optimize the lifetime and performance in order to address the requirements from the Constrained Nodes and Networks. The IETF Secretariat --047d7b339c4d7b497704ccae0a8c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable A new version of I-D, draft-li-core-conditional-observe-03.txt
has been successfully submitted by Jeroen Hoebeke and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-li-core-conditional-observe
Revision: =A0 =A0 =A0 =A003
Title: =A0 =A0 =A0 =A0 =A0 Conditional observe in CoAP
Creation date: =A0 2012-10-22
WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 29
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.iet= f.org/internet-drafts/draft-li-core-conditional-observe-03.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org= /doc/draft-li-core-conditional-observe
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draf= t-li-core-conditional-observe-03
Diff: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.org= /rfcdiff?url2=3Ddraft-li-core-conditional-observe-03

Abstract:
=A0 =A0CoAP is a RESTful application protocol for constrained nodes and
=A0 =A0networks. =A0Through the Observe option, clients can observe changes= in
=A0 =A0the state of resources and obtain a current representation of the =A0 =A0last resource state. =A0This document defines a new mechanism in CoA= P
=A0 =A0Observe so that a CoAP client can conditionally observe a resource o= n
=A0 =A0a CoAP server, only being informed about state changes meeting a
=A0 =A0specific condition or set of conditions. =A0This offers possibilitie= s
=A0 =A0to extend network intelligence, enhance scalability, and optimize th= e
=A0 =A0lifetime and performance in order to address the requirements from =A0 =A0the Constrained Nodes and Networks.




The IETF Secretariat


--047d7b339c4d7b497704ccae0a8c-- From cabo@tzi.org Wed Oct 24 13:32:45 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B53721F8B86 for ; Wed, 24 Oct 2012 13:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.224 X-Spam-Level: X-Spam-Status: No, score=-106.224 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GKxCraJwuI4j for ; Wed, 24 Oct 2012 13:32:45 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id B9A2C21F8B85 for ; Wed, 24 Oct 2012 13:32:44 -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 q9OKWa8R016822 for ; Wed, 24 Oct 2012 22:32:36 +0200 (CEST) Received: from [192.168.217.117] (p5489481E.dip.t-dialin.net [84.137.72.30]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id D566CC4B; Wed, 24 Oct 2012 22:32:35 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Oct 2012 22:32:34 +0200 To: "core@ietf.org WG" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [core] CoRE agenda @ IETF85 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, 24 Oct 2012 20:32:45 -0000 I put in a first version of the agenda at: http://www.ietf.org/proceedings/85/agenda/agenda-85-core This time we might have a chance to cover a little more of the new = stuff, in the Friday session. If you haven't put in your slot request, please do so, and please = indicate -- time needed for any presentation and, more importantly, for = discussion -- who will run the slot (presenter) -- what are your objectives for requesting the slot? If you have, and I lost it, please retransmit :-) Gr=FC=DFe, Carsten From cabo@tzi.org Thu Oct 25 01:12:11 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE5E321F89B6; Thu, 25 Oct 2012 01:12:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.114 X-Spam-Level: X-Spam-Status: No, score=-106.114 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xTLLZ16mDoCj; Thu, 25 Oct 2012 01:12:11 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id C609421F89CB; Thu, 25 Oct 2012 01:12:10 -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 q9P8Bw0a014709; Thu, 25 Oct 2012 10:12:00 +0200 (CEST) Received: from [10.0.1.2] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 1D491D73; Thu, 25 Oct 2012 10:11:46 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Carsten Bormann Date: Thu, 25 Oct 2012 10:11:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4FB2FFE4-ABD7-44DD-84F0-C5BA38493891@tzi.org> To: "6lowpan@ietf.org" <6lowpan@ietf.org>, "core@ietf.org WG" X-Mailer: Apple Mail (2.1499) Subject: [core] IETF85: Adaptation Layer Fragmentation Indication (ALFI) on intarea agenda X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "6lowpan@ietf.org" <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, 25 Oct 2012 08:12:11 -0000 One problem we have in 6LoWPAN networks is that the 6LoWPAN = fragmentation is "transparent", i.e. there is no equivalent of Path MTU = discovery that would enable applications to make informed decisions = about the packet sizes they choose. Since that problem is not specific to 6LoWPAN, and not even to IPv6, it = is being discussed in the intarea working group. (The specific proposal is currently focused on IPv6, however.) If you care about this subject, below is a snippet from the current = intarea agenda (which, of course, can change). Gr=FC=DFe, Carsten http://www.ietf.org/proceedings/85/agenda/agenda-85-intarea says: > intarea WG Agenda=20 > IETF 85 > Monday, November 5, 2012 > 1300-1500 Afternoon Session I >=20 > 1. Agenda Bashing, WG & Document Status (Chairs) 10 minutes > =20 > 2. Adaptation Layer Fragmentation Indication > Carsten Bormann 20 minutes > draft-bormann-intarea-alfi-01 >=20 > Objective: >=20 > Present the draft that describes a mechanism by which an > IPv6 adaptation layer can indicate the presence of > fragmentation capability and can specify preferred packet > sizes for the link type. The goal is to publicize the work > and identify a suitable venue to continue this work. From kovatsch@inf.ethz.ch Thu Oct 25 02:45:27 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 529A721F89A0 for ; Thu, 25 Oct 2012 02:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cY4C12wjpsGh for ; Thu, 25 Oct 2012 02:45:26 -0700 (PDT) Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) by ietfa.amsl.com (Postfix) with ESMTP id B807321F89A9 for ; Thu, 25 Oct 2012 02:45:25 -0700 (PDT) Received: from CAS22.d.ethz.ch (172.31.51.112) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.2.298.4; Thu, 25 Oct 2012 11:45:10 +0200 Received: from MBX10.d.ethz.ch ([fe80::6d7b:f3da:a5b1:c9e9]) by CAS22.d.ethz.ch ([fe80::dd0e:466a:b055:c090%10]) with mapi id 14.02.0298.004; Thu, 25 Oct 2012 11:45:18 +0200 From: "Kovatsch Matthias" To: CoRE Thread-Topic: [core] I-D Action: draft-ietf-core-observe-07.txt Thread-Index: AQHNsIwe5jkym9M+Z0aID1DulUoGCpfJp9AA Date: Thu, 25 Oct 2012 09:45:17 +0000 Message-ID: <2085396A-BABC-434A-B1FF-6C2A4D536719@inf.ethz.ch> References: <20121022193238.19462.66812.idtracker@ietfa.amsl.com> In-Reply-To: <20121022193238.19462.66812.idtracker@ietfa.amsl.com> Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.132.209.223] Content-Type: text/plain; charset="us-ascii" Content-ID: <4F313A35F9A1CE419EB6583E9BFDDA03@intern.ethz.ch> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [core] I-D Action: draft-ietf-core-observe-07.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, 25 Oct 2012 09:45:27 -0000 Dear Klaus, dear list I read the new observe draft and a few questions popped up: > 4.5. Retransmission > When a notification is transmitted multiple times (either as caused > by a retransmission attempt or repeating it), the server MUST update > value of the Observe Option. Otherwise, the client might discard the > notification as too old. Why is this required for retransmissions (of the same state) at all? Either= the client received the notification and updated its observe clock or it d= id not (and cannot discard it as old). Or is this just intended for the case the server updates the state during a= n open CON transmission? If I am missing the reason for this, I want to point out that this creates = a messy dependency between all open transmissions, or requires one observe = clock per client... > 5. Intermediaries > Because a client (or an intermediary in the client role) can only be > once in the list of observers of a resource at a server (or an > intermediary in the server role) -- it is useless to observe the same > resource multiple times -- an intermediary MUST observe a resource > only once, even if there are multiple clients for which it observes > the resource. What about different content-types/accept options? An intermediary must be = able to serve them if they are supported by the origin server. But if they = cannot be converted, the intermediary can only use observing for one conten= t-type. Maybe the observe list entry should also be dependent on the content-type? > 6. Block-wise Transfers So for observe, the server can send all blocks without the stop-and-wait me= chanism?! Okay, this saves energy/messages and time, so why not do this for= any blockwise transfer? I would absolutely not do this because this is half way to TCP with its sli= ding window. A client would need a large buffer to store the whole body and= must manage missing blocks. The whole point of CoAP's blockwise transfers = is that the application can make use of fragments and for instance processe= s them on the fly. This is now broken, as the can arrive out of order and w= ith gaps. Almost no advantage over 6LoWPAN fragmentation anymore... This indirectly affects core-block, where I would also recommend in-order b= lock transfers or at least the possibility for the receiver to enforce them= . What do you think? Ciao Matthias From cabo@tzi.org Thu Oct 25 03:49:14 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 022ED21F8847 for ; Thu, 25 Oct 2012 03:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.224 X-Spam-Level: X-Spam-Status: No, score=-106.224 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l+zO+iyp03Es for ; Thu, 25 Oct 2012 03:49:13 -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 1F1E921F87A2 for ; Thu, 25 Oct 2012 03:49:12 -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 q9PAn5P5007702; Thu, 25 Oct 2012 12:49:05 +0200 (CEST) Received: from [192.168.217.117] (p5489481E.dip.t-dialin.net [84.137.72.30]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 6DD88ED5; Thu, 25 Oct 2012 12:49:05 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <2085396A-BABC-434A-B1FF-6C2A4D536719@inf.ethz.ch> Date: Thu, 25 Oct 2012 12:49:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <02D9F441-D677-403A-9172-9AE93CA792F5@tzi.org> References: <20121022193238.19462.66812.idtracker@ietfa.amsl.com> <2085396A-BABC-434A-B1FF-6C2A4D536719@inf.ethz.ch> To: "Kovatsch Matthias" X-Mailer: Apple Mail (2.1499) Cc: CoRE Subject: Re: [core] I-D Action: draft-ietf-core-observe-07.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, 25 Oct 2012 10:49:14 -0000 Hi Matthias, let me try to answer this one: On Oct 25, 2012, at 11:45, "Kovatsch Matthias" = wrote: >> 6. Block-wise Transfers >=20 > So for observe, the server can send all blocks without the = stop-and-wait mechanism?!=20 I think the operative text here is=20 suitably sequenced by its congestion control mechanism, So stop-and-wait (or whatever is the advanced CC mechanism selected, if = any) does continue to apply. What can we do to say this in a less confusing way? Gr=FC=DFe, Carsten From kovatsch@inf.ethz.ch Thu Oct 25 04:58:04 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF91921F8B06 for ; Thu, 25 Oct 2012 04:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VxCfhgjx02HD for ; Thu, 25 Oct 2012 04:58:04 -0700 (PDT) Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) by ietfa.amsl.com (Postfix) with ESMTP id 14E0821F8B05 for ; Thu, 25 Oct 2012 04:58:03 -0700 (PDT) Received: from CAS10.d.ethz.ch (172.31.38.210) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.2.298.4; Thu, 25 Oct 2012 13:57:51 +0200 Received: from MBX10.d.ethz.ch ([fe80::6d7b:f3da:a5b1:c9e9]) by CAS10.d.ethz.ch ([fe80::cce:fc66:7b56:a06a%10]) with mapi id 14.02.0298.004; Thu, 25 Oct 2012 13:57:59 +0200 From: "Kovatsch Matthias" To: Carsten Bormann Thread-Topic: [core] I-D Action: draft-ietf-core-observe-07.txt Thread-Index: AQHNsIwe5jkym9M+Z0aID1DulUoGCpfJp9AAgAASQwCAADTIZw== Date: Thu, 25 Oct 2012 11:57:58 +0000 Message-ID: <1wjtl5fu2p55hoken4uf8pu1.1351165882860@email.android.com> References: <20121022193238.19462.66812.idtracker@ietfa.amsl.com> <2085396A-BABC-434A-B1FF-6C2A4D536719@inf.ethz.ch>, <02D9F441-D677-403A-9172-9AE93CA792F5@tzi.org> In-Reply-To: <02D9F441-D677-403A-9172-9AE93CA792F5@tzi.org> Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: CoRE Subject: Re: [core] I-D Action: draft-ietf-core-observe-07.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, 25 Oct 2012 11:58:04 -0000 Ah, I see. It was mainly the example figure that suggested notifications wi= thout ACKs/block requests. So the client will decide which notification block to receive next? Carsten Bormann wrote: Hi Matthias, let me try to answer this one: On Oct 25, 2012, at 11:45, "Kovatsch Matthias" wrot= e: >> 6. Block-wise Transfers > > So for observe, the server can send all blocks without the stop-and-wait = mechanism?! I think the operative text here is suitably sequenced by its congestion control mechanism, So stop-and-wait (or whatever is the advanced CC mechanism selected, if any= ) does continue to apply. What can we do to say this in a less confusing way? Gr=FC=DFe, Carsten From cabo@tzi.org Thu Oct 25 05:14:41 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ADAC21F8B02 for ; Thu, 25 Oct 2012 05:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.225 X-Spam-Level: X-Spam-Status: No, score=-106.225 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HXjpDDbrIrio for ; Thu, 25 Oct 2012 05:14:40 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 4369A21F8AF9 for ; Thu, 25 Oct 2012 05:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q9PCEWaH013871; Thu, 25 Oct 2012 14:14:33 +0200 (CEST) Received: from [192.168.217.117] (p54892C1E.dip.t-dialin.net [84.137.44.30]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 16F10F98; Thu, 25 Oct 2012 14:14:32 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <1wjtl5fu2p55hoken4uf8pu1.1351165882860@email.android.com> Date: Thu, 25 Oct 2012 14:14:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <74736B54-FC9B-4B3F-83DA-C40CC7624715@tzi.org> References: <20121022193238.19462.66812.idtracker@ietfa.amsl.com> <2085396A-BABC-434A-B1FF-6C2A4D536719@inf.ethz.ch>, <02D9F441-D677-403A-9172-9AE93CA792F5@tzi.org> <1wjtl5fu2p55hoken4uf8pu1.1351165882860@email.android.com> To: "Kovatsch Matthias" X-Mailer: Apple Mail (2.1499) Cc: CoRE Subject: Re: [core] I-D Action: draft-ietf-core-observe-07.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, 25 Oct 2012 12:14:41 -0000 On Oct 25, 2012, at 13:57, "Kovatsch Matthias" = wrote: > So the client will decide which notification block to receive next? Unfortunately, we don't have a way to do this. When the "initiative" (as I call it in the still not finished block-11) = is with the server, it is the server that goes through the Block2 = blocks. (It's not that different in TCP :-) But the client (the one receiving the notifications) still has to ACK = them. (Unless they are NON notifications, which I wouldn't really recommend = using with -block.) The ACK reduces the number of outstanding exchanges, triggering the next = CON. (Unless something like section 5.2 of = draft-bormann-core-congestion-control-02.txt is in effect, but we aren't = quite there yet, and we haven't decided how to negotiate/enable = something like that, if it is really desirable.) Gr=FC=DFe, Carsten From Gerald.Paprocki@us.elster.com Thu Oct 25 12:02:22 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 872B621F8989 for ; Thu, 25 Oct 2012 12:02:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.07 X-Spam-Level: X-Spam-Status: No, score=-6.07 tagged_above=-999 required=5 tests=[AWL=0.529, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W+EPJeCVgmJN for ; Thu, 25 Oct 2012 12:02:22 -0700 (PDT) Received: from mail44.messagelabs.com (mail44.messagelabs.com [216.82.249.179]) by ietfa.amsl.com (Postfix) with SMTP id F375321F8987 for ; Thu, 25 Oct 2012 12:02:21 -0700 (PDT) X-Env-Sender: Gerald.Paprocki@us.elster.com X-Msg-Ref: server-2.tower-44.messagelabs.com!1351191741!13924418!1 X-Originating-IP: [129.179.1.27] X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27606 invoked from network); 25 Oct 2012 19:02:21 -0000 Received: from ip27.net129179-1.block1.us.syntegra.com (HELO us-smtp01.smtp.elster.com) (129.179.1.27) by server-2.tower-44.messagelabs.com with SMTP; 25 Oct 2012 19:02:21 -0000 Auto-Submitted: auto-generated From: Gerald.Paprocki@us.elster.com To: core@ietf.org Message-ID: Date: Thu, 25 Oct 2012 15:02:32 -0400 X-MIMETrack: Serialize by Router on US-SMTP01.domino.elster-group.com/RIM-TEMP(Release 8.5.2FP3|July 10, 2011) at 10/25/2012 02:53:45 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [core] AUTO: Gerald Paprocki is out of the office (returning 10/29/2012) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 19:02:22 -0000 I am out of the office until 10/29/2012. I am out of the office and will be returning Monday Oct 29th. If assistance is required during my absence please contact one of my primes below. - IP AxisLink Secure Tunnel server - Inyong Park @ 919-250-5698 - EA_MS Interfaces - Bill Phillips @ 919-212-4888 - EA Inspector - Ying Xu @ 919-250-5446 Note: This is an automated response to your message "core Digest, Vol 33, Issue 20" sent on 10/25/2012 3:00:37 PM. This is the only notification you will receive while this person is away. From yusuke.doi@toshiba.co.jp Fri Oct 26 09:14:45 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F120921F8625 for ; Fri, 26 Oct 2012 09:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.089 X-Spam-Level: X-Spam-Status: No, score=-6.089 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kNn8ZBrqDzSG for ; Fri, 26 Oct 2012 09:14:44 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id 4B5A121F8620 for ; Fri, 26 Oct 2012 09:14:44 -0700 (PDT) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id q9QGEhpr013092 for ; Sat, 27 Oct 2012 01:14:43 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id q9QGEhCL029617 for core@ietf.org; Sat, 27 Oct 2012 01:14:43 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id BAA29616; Sat, 27 Oct 2012 01:14:43 +0900 Received: from mx12.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id q9QGEgoh007317 for ; Sat, 27 Oct 2012 01:14:42 +0900 (JST) Received: from spiffy21.isl.rdc.toshiba.co.jp by toshiba.co.jp id q9QGEgds013224; Sat, 27 Oct 2012 01:14:42 +0900 (JST) Received: from [133.199.16.143] (ivpn-1-143.mobile.toshiba.co.jp [133.199.16.143]) by spiffy21.isl.rdc.toshiba.co.jp (Postfix) with ESMTP id 3801A97CC1; Sat, 27 Oct 2012 01:14:42 +0900 (JST) Message-ID: <508AB6F1.4060701@toshiba.co.jp> Date: Sat, 27 Oct 2012 01:14:41 +0900 From: Yusuke DOI User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: Carsten Bormann References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "core@ietf.org WG" Subject: Re: [core] CoRE agenda @ IETF85 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 16:14:45 -0000 Carsten, if it's not too late, please let me introduce content-type parameter option in 5 min. talk. I'll be on the site. - Time: 5 min. for presentation, maybe another 5 min. for discussion? (I have no idea it's too long or short) - Presenter: Yusuke DOI - Objective: discussion on the content-type parameter proposal Thanks! Yusuke (2012/10/25 5:32), Carsten Bormann wrote: > I put in a first version of the agenda at: > > http://www.ietf.org/proceedings/85/agenda/agenda-85-core > > This time we might have a chance to cover a little more of the new stuff, in the Friday session. > > If you haven't put in your slot request, please do so, and please indicate > -- time needed for any presentation and, more importantly, for discussion > -- who will run the slot (presenter) > -- what are your objectives for requesting the slot? > > If you have, and I lost it, please retransmit :-) > > Grüße, Carsten > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From cabo@tzi.org Fri Oct 26 09:35:55 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F9D221F853B for ; Fri, 26 Oct 2012 09:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.227 X-Spam-Level: X-Spam-Status: No, score=-106.227 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mFQhxzl5G+4B for ; Fri, 26 Oct 2012 09:35:54 -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 4621921F8526 for ; Fri, 26 Oct 2012 09:35:53 -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 q9QGZiuT000117; Fri, 26 Oct 2012 18:35:44 +0200 (CEST) Received: from [192.168.217.117] (p548935F1.dip.t-dialin.net [84.137.53.241]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 57E657AF; Fri, 26 Oct 2012 18:35:44 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <508AB6F1.4060701@toshiba.co.jp> Date: Fri, 26 Oct 2012 18:35:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <508AB6F1.4060701@toshiba.co.jp> To: Yusuke DOI X-Mailer: Apple Mail (2.1499) Cc: "core@ietf.org WG" Subject: [core] Content-Format vs. Parameters (Re: CoRE agenda @ IETF85) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 16:35:55 -0000 On Oct 26, 2012, at 18:14, Yusuke DOI wrote: > Carsten, >=20 > if it's not too late, please let me introduce content-type parameter = option in 5 min. talk. I'll be on the site. >=20 > - Time: 5 min. for presentation, maybe another 5 min. for discussion? > (I have no idea it's too long or short) > - Presenter: Yusuke DOI > - Objective: discussion on the content-type parameter proposal Certainly! I would like to structure this discussion into three items: 1) sanity check: Is what we are doing with Content-Format = (coap-12's name for what was Content-Type earlier) the right thing for = the majority of CoAP applications? 2) requirements: What are the applications we can't cover with Content-Format? What use-cases are behind them? 3) solution: is draft-doi-core-parameter-option the right = solution for these (some of these) use-cases? I think I can introduce 1, and I'd like you to do 2 and 3, with a focus = on really making the case for 2. I'd like to allocate some 10 min for this. If we get a good discussion = about 1 and/or 2, we should be flexible about that. Updated agenda proposal is at: http://www.ietf.org/proceedings/85/agenda/agenda-85-core Gr=FC=DFe, Carsten From charles.palmer@acutetechnology.com Fri Oct 26 10:10:42 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEB2C21F8612 for ; Fri, 26 Oct 2012 10:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.335 X-Spam-Level: X-Spam-Status: No, score=0.335 tagged_above=-999 required=5 tests=[BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qn-x2aMiWjON for ; Fri, 26 Oct 2012 10:10:42 -0700 (PDT) Received: from gateway05.websitewelcome.com (gateway05.websitewelcome.com [67.18.124.3]) by ietfa.amsl.com (Postfix) with ESMTP id 368BF21F85B3 for ; Fri, 26 Oct 2012 10:10:41 -0700 (PDT) Received: by gateway05.websitewelcome.com (Postfix, from userid 5007) id AFE4965CE8BD4; Fri, 26 Oct 2012 12:10:40 -0500 (CDT) Received: from gator192.hostgator.com (gator192.hostgator.com [184.173.197.213]) by gateway05.websitewelcome.com (Postfix) with ESMTP id 9E4EE65CE8BAD for ; Fri, 26 Oct 2012 12:10:40 -0500 (CDT) Received: from [86.153.133.70] (port=3538 helo=[192.168.1.77]) by gator192.hostgator.com with esmtpa (Exim 4.80) (envelope-from ) id 1TRnQe-0005tb-Ad for core@ietf.org; Fri, 26 Oct 2012 12:10:40 -0500 Message-ID: <508AC40F.2030807@acutetechnology.com> Date: Fri, 26 Oct 2012 18:10:39 +0100 From: Charles Palmer Organization: Acute Technology Limited User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: CoRE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator192.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - acutetechnology.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.77]) [86.153.133.70]:3538 X-Source-Auth: charles.palmer+acutetechnology.com X-Email-Count: 1 X-Source-Cap: YWN1dGV0ZWM7YWN1dGV0ZWM7Z2F0b3IxOTIuaG9zdGdhdG9yLmNvbQ== Subject: [core] Practical CoAP implementations and interoperability X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 17:10:42 -0000 Dear colleagues I note that the new IEEE 802.15.4g PHY and 802.15.4e MAC standards introduce multiple new PHY and MAC options, and Google suggests that some people are implementing CoAP on top of these. Yet clearly there will be no interoperability unless implementers make the same choices. Is a consensus forming on these matters? Is there any resource that lists practical CoAP implementations, plus the IEEE 802.15.4 PHY and MAC selections of each of these implementations? What happens at Plugtest events? (My present interest is examining sub-GHz implementations on the basis that this might address range issues observed with ZigBee at 2.4GHz). -- Regards - Charles Palmer Project Hydra Project Manager - Acute Technology Limited Woodthorpe, Calver Road, Baslow, Derbyshire, DE45 1RR, United Kingdom Mob: +44 (0)7977 577 627 Skype: Acutetech Email: charles.palmer@acutetechnology.com Web: http://projecthydra.info From yusuke.doi@toshiba.co.jp Sun Oct 28 09:05:44 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A61DC21F866E for ; Sun, 28 Oct 2012 09:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.489 X-Spam-Level: X-Spam-Status: No, score=-5.489 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-8, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qFl7ig8Icf+Y for ; Sun, 28 Oct 2012 09:05:44 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by ietfa.amsl.com (Postfix) with ESMTP id 84E6021F8513 for ; Sun, 28 Oct 2012 09:05:40 -0700 (PDT) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id q9SG5dfo014201 for ; Mon, 29 Oct 2012 01:05:39 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id q9SG5d8N015616 for core@ietf.org; Mon, 29 Oct 2012 01:05:39 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id BAA15615; Mon, 29 Oct 2012 01:05:39 +0900 Received: from mx12.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id q9SG5csD010231 for ; Mon, 29 Oct 2012 01:05:38 +0900 (JST) Received: from spiffy21.isl.rdc.toshiba.co.jp by toshiba.co.jp id q9SG5cA6005971; Mon, 29 Oct 2012 01:05:38 +0900 (JST) Received: from [133.199.16.107] (ivpn-1-107.mobile.toshiba.co.jp [133.199.16.107]) by spiffy21.isl.rdc.toshiba.co.jp (Postfix) with ESMTP id A777597CC0; Mon, 29 Oct 2012 01:05:38 +0900 (JST) Message-ID: <508D57D2.7090405@toshiba.co.jp> Date: Mon, 29 Oct 2012 01:05:38 +0900 From: Yusuke DOI User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: Carsten Bormann References: <508AB6F1.4060701@toshiba.co.jp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "core@ietf.org WG" Subject: Re: [core] Content-Format vs. Parameters (Re: CoRE agenda @ IETF85) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Oct 2012 16:05:44 -0000 Carsten, Thank you for arrangement! Yusuke (2012/10/27 1:35), Carsten Bormann wrote: > On Oct 26, 2012, at 18:14, Yusuke DOI wrote: > >> Carsten, >> >> if it's not too late, please let me introduce content-type parameter option in 5 min. talk. I'll be on the site. >> >> - Time: 5 min. for presentation, maybe another 5 min. for discussion? >> (I have no idea it's too long or short) >> - Presenter: Yusuke DOI >> - Objective: discussion on the content-type parameter proposal > > Certainly! > > I would like to structure this discussion into three items: > > 1) sanity check: Is what we are doing with Content-Format (coap-12's > name for what was Content-Type earlier) the right thing for the > majority of CoAP applications? > > 2) requirements: What are the applications we can't cover with > Content-Format? What use-cases are behind them? > > 3) solution: is draft-doi-core-parameter-option the right solution > for these (some of these) use-cases? > > I think I can introduce 1, and I'd like you to do 2 and 3, with a focus on really making the case for 2. > > I'd like to allocate some 10 min for this. If we get a good discussion about 1 and/or 2, we should be flexible about that. > > Updated agenda proposal is at: > > http://www.ietf.org/proceedings/85/agenda/agenda-85-core > > Grüße, Carsten > From trac+core@trac.tools.ietf.org Tue Oct 30 07:47:43 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F074121F8453 for ; Tue, 30 Oct 2012 07:47:43 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vHXKsTH5rDP5 for ; Tue, 30 Oct 2012 07:47:43 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 647E221F8444 for ; Tue, 30 Oct 2012 07:47:43 -0700 (PDT) Received: from localhost ([127.0.0.1]:48201 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TTD6C-0008Es-P5; Tue, 30 Oct 2012 15:47:24 +0100 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, esko.dijk@philips.com X-Trac-Project: core Date: Tue, 30 Oct 2012 14:47:24 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/247#comment:2 Message-ID: <075.bcb025de59b9fa237b89429479734f36@trac.tools.ietf.org> References: <060.165feff053c11cfa0d65de452eb53ed9@trac.tools.ietf.org> X-Trac-Ticket-ID: 247 In-Reply-To: <060.165feff053c11cfa0d65de452eb53ed9@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: brian@skyfoundry.com, cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20121030144743.647E221F8444@ietfa.amsl.com> Resent-Date: Tue, 30 Oct 2012 07:47:43 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #247: Scalability questions IANA review for IPv6/IPv4 multicast address request (was: Scalability question IANA reviewer for IPv4 multicast address request) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 14:47:44 -0000 #247: Scalability questions IANA review for IPv6/IPv4 multicast address request -- -----------------------------+------------------------------------- Reporter: esko.dijk@… | Owner: draft-ietf-core-coap@… Type: protocol defect | Status: new Priority: major | Milestone: post-WGLC-1 Component: coap | Version: Severity: - | Resolution: Keywords: | -----------------------------+------------------------------------- Ticket URL: core From esko.dijk@philips.com Wed Oct 31 05:58:25 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D29BB21F84FF for ; Wed, 31 Oct 2012 05:58:25 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uL8qSWcsNjxn for ; Wed, 31 Oct 2012 05:58:25 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id DA0F221F84D9 for ; Wed, 31 Oct 2012 05:58:24 -0700 (PDT) Received: from mail210-ch1-R.bigfish.com (10.43.68.230) by CH1EHSOBE001.bigfish.com (10.43.70.51) with Microsoft SMTP Server id 14.1.225.23; Wed, 31 Oct 2012 12:58:22 +0000 Received: from mail210-ch1 (localhost [127.0.0.1]) by mail210-ch1-R.bigfish.com (Postfix) with ESMTP id D39B4380330; Wed, 31 Oct 2012 12:58:22 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -35 X-BigFish: VPS-35(zz217bI15d6O9251Jc89bh542Mzz1202h1d1ah1d2ahzz1033IL17326ah8275dhz2dh2a8h668h839h93fhd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh1155h) Received: from mail210-ch1 (localhost.localdomain [127.0.0.1]) by mail210-ch1 (MessageSwitch) id 1351688301668263_25625; Wed, 31 Oct 2012 12:58:21 +0000 (UTC) Received: from CH1EHSMHS008.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.243]) by mail210-ch1.bigfish.com (Postfix) with ESMTP id A141D36004E; Wed, 31 Oct 2012 12:58:21 +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.23; Wed, 31 Oct 2012 12:58:19 +0000 Received: from 011-DB3MMR1-013.MGDPHG.emi.philips.com (10.128.28.97) by 011-DB3MMR1-004.MGDPHG.emi.philips.com (10.128.28.54) with Microsoft SMTP Server (TLS) id 14.2.309.3; Wed, 31 Oct 2012 12:57:42 +0000 Received: from 011-DB3MPN2-082.MGDPHG.emi.philips.com ([169.254.2.20]) by 011-DB3MMR1-013.MGDPHG.emi.philips.com ([10.128.28.97]) with mapi id 14.02.0309.003; Wed, 31 Oct 2012 12:57:42 +0000 From: "Dijk, Esko" To: "consultancy@vanderstok.org" , "core@ietf.org" Thread-Topic: [core] htpp-coap proxy / review comments Peter on HTTP Mapping draft Thread-Index: AQHNt2dQkoH/qo1Nu0eotb012e9JsQ== Date: Wed, 31 Oct 2012 12:57:41 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618B0985A@011-DB3MPN2-082.MGDPHG.emi.philips.com> References: <8100259ac909c3f6c7b43eb7a4b407a8@xs4all.nl> In-Reply-To: <8100259ac909c3f6c7b43eb7a4b407a8@xs4all.nl> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.103] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: Re: [core] htpp-coap proxy / review comments Peter on HTTP Mapping draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 12:58:26 -0000 RGVhciBQZXRlciwNCg0KdGhhbmtzIGZvciB5b3VyIGRldGFpbGVkIHJldmlldyBvZiB0aGUgSFRU UC1tYXBwaW5nIGRyYWZ0LiBUaGlzIGhhcyBiZWVuIHVzZWQsIGFsb25nIHdpdGggc29tZSBnZW5l cmFsIFdHIGNvbW1lbnRzIG9uIGxhc3QgSUVURiBtZWV0aW5nLCB0byBpbXByb3ZlIGl0Lg0KDQpC ZWxvdyBhcmUgc3BlY2lmaWMgcmVwbHkgY29tbWVudHMgdG8geW91ciBmZWVkYmFjayBpbiB0aGUg V29yZCBkb2N1bWVudCAodXNpbmcgdGhlIG9yaWdpbmFsIFdvcmQgY29tbWVudCBudW1iZXJpbmcg W24uLi5dIHdoZXJlIHBvc3NpYmxlKSB3aXRoIGV4cGxhbmF0aW9uIGhvdyB0aGUgYXV0aG9ycyBh cHBsaWVkIHRoZSBjb21tZW50IHRvIHRoZSBkcmFmdC4gVGhlIGZvY3VzIGlzIGhlcmUgb24gU2Vj dGlvbiAzLTUuIEFueSBpdGVtcyBmb3IgdGhlc2Ugc2VjdGlvbnMgbm90IGxpc3RlZCwgd2VyZSBz aW1wbHkgYXBwbGllZC4NClRoZSBuZXcgdmVyc2lvbiBpcyBodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1jYXN0ZWxsYW5pLWNvcmUtaHR0cC1tYXBwaW5nLTA2DQoNCioqKiBTZWN0aW9u IDM6IENyb3NzLVByb3RvY29sIFVzYWdlIG9mIFVSSXMNCg0KUGFyYWdyYXBoIDMgJiA1OiBZb3Vy IHN1Z2dlc3Rpb24gd2FzIHRvIHJlLXdyaXRlIHNvbWUgb2YgdGhlIHNlbnRlbmNlcy4gIFdlIHJl dmlld2VkIHRoZSBzZW50ZW5jZXMgYW5kIGRlY2lkZWQgdG8gY29tYmluZSB0aGUgdHdvIHBhcmFn cmFwaHMgdG8gbWFrZSBpdCBjbGVhcmVyLg0KDQpQYXJhZ3JhcGggNDogWW91ciBzdWdnZXN0aW9u IHdhcyB0byBlbGltaW5hdGUgdGhlIHBhcmFncmFwaCAobW9zdCBwcm9iYWJseSBiZWNhdXNlIGl0 IHdhcyBjb25mdXNpbmcpLiBXZSBhZ3JlZWQgYW5kIGhhdmUgZWxpbWluYXRlZCB0aGUgcGFyYWdy YXBoLg0KDQoNCioqKiBTZWN0aW9uIDQ6IEhUVFAgdG8gQ29BUCBVUkkgTWFwcGluZw0KVmFyaW91 cyBwYXJhZ3JhcGhzOiBZb3UgaGFkIGFzc29ydGVkIGVkaXRvcmlhbCBzdWdnZXN0aW9ucyB0aHJv dWdob3V0IHRoZSBzZWN0aW9uLiAgV2UgaW1wbGVtZW50ZWQgbW9zdCBvZiB5b3VyIHN1Z2dlc3Rp b25zLiAgQWxzbyB3ZSByZS13b3JkZWQgdGhlIHNlY3Rpb24gdG8gZm9jdXMgZXhwbGljaXRseSBv biB0aGUgUmV2ZXJzZSBQcm94eSBzY2VuYXJpbyBtb3JlIGNsZWFybHkuDQoNCg0KKioqIFNlY3Rp b24gNTogSFRUUC10by1Db0FQDQpbbjNdLFtuNV06IHlvdXIgc3VnZ2VzdGlvbiB0byByZW1vdmUg aXRlbXMgb24gdGltZW91dCBvZiBIVFRQIHJlcXVlc3QgYW5kIEhUVFAgY29ubmVjdGlvbiBwaXBl bGluaW5nOw0KUmVzb2x1dGlvbjogVGhlc2UgaXRlbXMgd2VyZSBtb3ZlZCB0byBhIHNlcGFyYXRl IHNlY3Rpb24gYXQgdGhlIGVuZCwgdG8gbWFrZSB0aGUgc2VjdGlvbiA1IGludHJvIGVhc2llciB0 byByZWFkLg0KDQpbbjldOiB1bmNsYXJpdHkgb2YgdGV4dCBhYm91dCBtdWx0aXBsZSBmb3J3YXJk IHByb3hpZXM7IHRoZSBpc3N1ZSB3YXMgbm90IHJlc29sdmVkIHlldCAocGVuZGluZyBtb3JlIGNv bW11bmljYXRpb24gYmV0d2VlbiB0aGUgYXV0aG9ycyBhbmQvb3IgV0cpLiBCdXQgdGhlIHN1Ympl Y3QgaXMgaW5kZWVkIG5vdCBjbGVhciBlbm91Z2ggeWV0Lg0KDQpbbjEwXTogYWJvdXQgZGV0ZWN0 aW9uIG9mIGR1cGxpY2F0ZSBpZGVtcG90ZW50IHJlcXVlc3RzOyBoZXJlIHRoZSB0ZXh0IHdhcyB1 cGRhdGVkIHRvIHJlZmxlY3QgdGhhdCB0aGlzIGlzIGFib3V0IGR1cGxpY2F0ZSByZXF1ZXN0cyBt YWRlIGJ5IHRoZSBzYW1lIHByb3h5LiBJbiB0aGF0IGNhc2UgdGhlIHByb3h5IHdpbGwga25vdyB3 aGF0IG90aGVyIHJlcXVlc3RzIGl0IGlzIHNlcnZpbmcuIChObyBjb21tdW5pY2F0aW9uIHdpdGgg b3RoZXIgcHJveGllcyBpcyBuZWVkZWQuKQ0KDQpbbjExXTogdW5jbGVhciByb2xlIG9mIGlkZW1w b3RlbmN5IDsgd2UgcmVtb3ZlZCB0aGUgd29yZCBoZXJlLg0KDQpbbjEyXTogb2JzZXJ2ZSBvbiB0 aGUgcHJveHkgOyB0ZXh0IHNsaWdodGx5IGFkYXB0ZWQuIFRoZSBjcm9zcy1wcm94eSB3aWxsIGFj dCBhcyBhIENvQVAtb2JzZXJ2ZSBjbGllbnQgaGVyZS4gSXQgd2lsbCBub3QgYWN0IGFzIENvQVAt b2JzZXJ2ZSBzZXJ2ZXIuIFJlZ2FyZGluZyB0aGUgc2Vjb25kIHF1ZXN0aW9uLCB3ZSBkbyBub3Qg bWFrZSByZWNvbW1lbmRhdGlvbnMgY3VycmVudGx5IGFib3V0IG51bWJlciBvZiBjcm9zcy1wcm94 eSBzZXJ2ZXJzIHRvIGJlIHVzZWQuIEJ1dCB0aGUgcXVlc3Rpb24gaXMgbm90IGVudGlyZWx5IGNs ZWFyIHRvIHVzLg0KDQpbbjE0XTogcHJveHkgcXVldWVpbmcgYW5kIGRyb3BwaW5nIGJlaGF2aW9y OyB3ZSB0b29rIG92ZXIgdGhlIHN1Z2dlc3Rpb24gdG8gbWFrZSB0aGlzIGNvbmZpZ3VyYWJsZS4N Cg0KW24xNV06IHVzaW5nIGNvYXAtb2JzZXJ2ZTsgY29ycmVjdCB0aGVyZSBhcmUgbm8gaW50ZXJv cGVyYWJpbGl0eSBpc3N1ZXMgaGVyZSBpbiB1c2luZyDigJNvYnNlcnZlIG9yIG5vdC4gVGhlcmVm b3JlIGl0IGlzIGFsc28gbm90IHBhcnQgb2Ygb3VyIHNldCBvZiBndWlkZWxpbmVzLiBUaGlzIGlz IGp1c3QgdG8gaW5mb3JtIHByb3h5IGRldmVsb3BlcnMgb2YgYSBnb29kIHRlY2huaXF1ZSB0byBl bXBsb3kgZm9yIGNhY2hpbmcuIFRoZSBzZWN0aW9uIGlzIHNob3J0ZW5lZCwgdGhvdWdoIGFuZCBv bmx5IHJlc3VsdCBoZXVyaXN0aWMgaXMgcHJlc2VudGVkLg0KDQpbbjE2XTogYWJvdXQgY29yZS1i bG9jayBtaXNtYXRjaCBvZiBibG9jayBzaXplczsgdGV4dCB3YXMgYWRkZWQgZm9yIGNhc2UgdGhh dCBDb0FQIGVuZHBvaW50cyBkbyBub3Qgc3VwcG9ydCDigJNibG9jay4gRGlmZmVyZW50IGJsb2Nr IHNpemVzIHN1cHBvcnQgaXMgZGVhbHQgd2l0aCBieSB0aGUgY29yZS1ibG9jayBwcm90b2NvbCBu ZWdvdGlhdGlvbi4gVGhlIHRyYW5zcGFyZW50IGNsaWVudC10by1zZXJ2ZXIgYmxvY2tpbmcgc3Vn Z2VzdGlvbiB3YXMgbm90IHRha2VuIHVwOyBzaW5jZSB0aGUgdXNlIG9mIOKAk2Jsb2NrIGlzIG9u bHkgYmV0d2VlbiBwcm94eSBhbmQgY29hcCBzZXJ2ZXI7IGNsaWVudCBub3QgaW52b2x2ZWQuDQoN CnRoYW5rcyAmIGJlc3QgcmVnYXJkcywNCg0KdGhlIGF1dGhvcnMgb2YgZHJhZnQtY2FzdGVsbGFu aS1jb3JlLWh0dHAtbWFwcGluZw0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjb3JlLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBwZXRlciB2YW4gZGVyIFN0b2sNClNlbnQ6IFR1ZXNkYXkgMTEgU2VwdGVtYmVy IDIwMTIgMTE6MDYNClRvOiBha2JhciByYWhtYW47IGNvcmVAaWV0Zi5vcmcNClN1YmplY3Q6IFtj b3JlXSBodHBwLWNvYXAgcHJveHkNCg0KSGkgQWtiYXIsDQoNCmF0dGFjaGVkIHRoZSBjb21tZW50 cyBvbiB0aGUgY3Jvc3MtcHJveHkgZHJhZnQuDQpJIGNvbnZlcnRlZCB0aGUgdHh0IGRvY3VtZW50 IHRvIHdvcmQgYW5kIGVkaXRlZCB0aGUgd29yZCBkb2N1bWVudDsgdGhhdCBtYWRlIG15IGxpZmUg ZWFzaWVyLg0KDQpJIGNoYW5nZWQgdGhlIGFic3RyYWN0IHRvIG1ha2UgY2xlYXJlciB0aGF0IHRo ZSBkcmFmdCBnaXZlcyBndWlkZWxpbmVzIGZvciBpbnRlcm9wZXJhYmlsaXR5IGludGVhZCBvZiBh bHRlcm5hdGl2ZSBkZXNpZ25zLg0KTXkgY29tbWVudHMgb24gc2VjdXJpdHkgYXJlIGJhc2VkIG9u IG15IHNlbnRpbWVudHMgYW5kIG5vdCBvbiBmYWN0dWFsIGtub3dsZWRnZS4NClRleHQgd2FzIGFk ZGVkIG9uIHRoZSBiYXNpcyBvZiBteSB1bmRlcnN0YW5kaW5nIGFuZCBtYXkgY29uc2VxdWVudGx5 IGJlIG9mZiB0aGUgbWFyay4NCg0KUGV0ZXINCi0tDQpQZXRlciB2YW4gZGVyIFN0b2sNCnZhbmRl cnN0b2sgY29uc3VsdGFuY3kNCm1haWx0bzogY29uc3VsdGFuY3lAdmFuZGVyc3Rvay5vcmcNCnd3 dzogd3d3LnZhbmRlcnN0b2sub3JnDQp0ZWwgTkw6ICszMSgwKTQ5MjQ3NDY3MyAgICAgRjogKzMz KDApOTY2MDE1MjQ4DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpUaGUgaW5m b3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWVzc2FnZSBtYXkgYmUgY29uZmlkZW50aWFsIGFu ZCBsZWdhbGx5IHByb3RlY3RlZCB1bmRlciBhcHBsaWNhYmxlIGxhdy4gVGhlIG1lc3NhZ2UgaXMg aW50ZW5kZWQgc29sZWx5IGZvciB0aGUgYWRkcmVzc2VlKHMpLiBJZiB5b3UgYXJlIG5vdCB0aGUg aW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSB1c2Us IGZvcndhcmRpbmcsIGRpc3NlbWluYXRpb24sIG9yIHJlcHJvZHVjdGlvbiBvZiB0aGlzIG1lc3Nh Z2UgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgYXJl IG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGJ5 IHJldHVybiBlLW1haWwgYW5kIGRlc3Ryb3kgYWxsIGNvcGllcyBvZiB0aGUgb3JpZ2luYWwgbWVz c2FnZS4NCg==