From zach@sensinode.com Mon Nov 1 00:11:44 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4EEF3A6863 for ; Mon, 1 Nov 2010 00:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.185 X-Spam-Level: X-Spam-Status: No, score=-1.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0aX6fy0fPIyY for ; Mon, 1 Nov 2010 00:11:42 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id E924B3A6821 for ; Mon, 1 Nov 2010 00:11:41 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id oA17BcBj032455 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 1 Nov 2010 09:11:38 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-52-1050654333; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: Date: Mon, 1 Nov 2010 09:11:39 +0200 Message-Id: References: <2F0A9D45-A3D3-48B8-999B-0CEA5674784D@sensinode.com> To: Peter Bigot X-Mailer: Apple Mail (2.1081) Cc: core Subject: Re: [core] What's to be presented to IESG in December? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 07:11:44 -0000 --Apple-Mail-52-1050654333 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 1, 2010, at 12:14 AM, Peter Bigot wrote: > On Sun, Oct 31, 2010 at 4:34 PM, Zach Shelby = wrote: > On Oct 29, 2010, at 3:37 PM, Peter Bigot wrote: >=20 > > I feel coap-block is unnecessary if one can defer to alternative = protocols (and we will need Uri-Scheme back to enable that, which I very = much want) >=20 > I don't agree that this has anything to do with CoAP, which is a = transfer protocol. If you want to provide a link to a different = protocol, this should be done in your resource representation (just like = an HTML link). Alternatively, the CoRE link format would allow you to = include links to other protocols. I absolutely do not agree that CoAP = should be returning some header option redirecting a client to use some = other protocol. >=20 > Could you clarify: are you saying that you don't want to require CoAP = to redirect to another protocol in this case, or that you don't want = CoAP to ever support redirection to another protocol? CoAP is a transfer protocol, it is not in the business of redirecting to = other protocols. Linking should be performed in your application, e.g.: 1. In the representation, just throw in the equivalent of an HTML link.=20= 2. In the CoRE link format, or any other link format of your choice. = Heck, if you are going to use TFTP, just point your client to use that = in the first place.=20 Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 --Apple-Mail-52-1050654333 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9 fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb 6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja 5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I 2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTEwMTA3MTEz OVowIwYJKoZIhvcNAQkEMRYEFPGSmcYEzfqJUWLtuAXJTRYS3OlSMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAH3fCv5qyylFx79BZZ4ozCN4MtaB3Z5dM93jSoUoQ2oTKdjCrJYyn/b1 9SdL3IzvOJWUXIuCKhamd5WNbBwSZor7+qZLAigJOZtngElSORZlEyc8aMycX+lxMcPVKs4XJGJk QXntC7BqlA7sBwVBslNRWFdDVyqwNgluEx8f85c/3dhGLyDXEro9cEnyjO1IMgv2VJ4CPsS2h8Vm nPmd9IKvOgS4WMhhzuodD4PAGNhiqCuXGFz29L0wCMUTVI4U2VQIPQlgG7tLzxDx/g92xRL6FJLd Pw4hIhXHmoJFbntUI8YxyH4wgVwNDjALCk94YHvRse3aOtAzN97EQjM+LKcAAAAAAAA= --Apple-Mail-52-1050654333-- From cabo@tzi.org Mon Nov 1 01:51:53 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C890B3A66B4 for ; Mon, 1 Nov 2010 01:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2lM-lcuUoQi3 for ; Mon, 1 Nov 2010 01:51:53 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 886493A6403 for ; Mon, 1 Nov 2010 01:51:52 -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 oA18pj1L029829 for ; Mon, 1 Nov 2010 09:51:45 +0100 (CET) Received: from [192.168.217.101] (p5489F9A1.dip.t-dialin.net [84.137.249.161]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 2B6DFD45; Mon, 1 Nov 2010 09:51:43 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Mon, 1 Nov 2010 09:51:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <77BDBF42-5FA8-4F92-8A90-6709FEBBDF83@tzi.org> References: <2F0A9D45-A3D3-48B8-999B-0CEA5674784D@sensinode.com> To: core X-Mailer: Apple Mail (2.1081) Subject: [core] Redirect (Re: What's to be presented to IESG in December?) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 08:51:54 -0000 As far as I know, we haven't made redirect a part of the CoAP state = machine yet. (At least, the "30x response code" alluded to in 3.2.5 hasn't been = defined.) Do we want to? As with any addition to CoAP, I'd like to understand the use cases. On the specific example (assuming that we indeed have a redirect = mechanism and that this can redirect to a full URI including scheme): Redirect to a protocol preferred for large representations would be = appropriate if it were somewhat of a surprise that the resource = representation suddenly is so large. Otherwise, I agree with Zach, the = resource that gave you the URI (i.e., resource discovery or some other = resource representation) should have given you a URI with the right = scheme in the first place. Narrowing this down to surprises, this specific use case seems = relatively narrow. But that may just be my lack of imagination, and of course there may be = other use cases for redirection. Gruesse, Carsten From pab@peoplepowerco.com Mon Nov 1 05:28:53 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDB3C3A69BA for ; Mon, 1 Nov 2010 05:28:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-CdYFZ+j3Iq for ; Mon, 1 Nov 2010 05:28:53 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 7B50B3A69A1 for ; Mon, 1 Nov 2010 05:26:35 -0700 (PDT) Received: by fxm9 with SMTP id 9so5183608fxm.31 for ; Mon, 01 Nov 2010 05:26:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.113.78 with SMTP id z14mr9070623fap.50.1288614396023; Mon, 01 Nov 2010 05:26:36 -0700 (PDT) Received: by 10.223.100.14 with HTTP; Mon, 1 Nov 2010 05:26:35 -0700 (PDT) In-Reply-To: <77BDBF42-5FA8-4F92-8A90-6709FEBBDF83@tzi.org> References: <2F0A9D45-A3D3-48B8-999B-0CEA5674784D@sensinode.com> <77BDBF42-5FA8-4F92-8A90-6709FEBBDF83@tzi.org> Date: Mon, 1 Nov 2010 07:26:35 -0500 Message-ID: From: Peter Bigot To: Carsten Bormann Content-Type: multipart/alternative; boundary=001636c5ae1d53d4250493fcebb2 Cc: core Subject: Re: [core] Redirect (Re: What's to be presented to IESG in December?) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 12:28:53 -0000 --001636c5ae1d53d4250493fcebb2 Content-Type: text/plain; charset=ISO-8859-1 I missed that we didn't have the referenced 30x redirect code defined, so hadn't thought of it as an addition. OK, I see that perspective. Off-hand use cases for redirect: * Forward a permanent URI to the entity temporarily responsible for managing it * Delegating complex representation formatting activities to a service on another (less constrained) node * Enabling client metadata such as message size restrictions to influence the delivery mechanism (including the transfer protocol) * Routing an unauthorized request to a security service through which authorization can be obtained The technique has clearly been valuable in HTTP, but maybe it's irrelevant or unnecessary in CoAP. Peter On Mon, Nov 1, 2010 at 3:51 AM, Carsten Bormann wrote: > As far as I know, we haven't made redirect a part of the CoAP state machine > yet. > (At least, the "30x response code" alluded to in 3.2.5 hasn't been > defined.) > > Do we want to? > As with any addition to CoAP, I'd like to understand the use cases. > > On the specific example (assuming that we indeed have a redirect mechanism > and that this can redirect to a full URI including scheme): > Redirect to a protocol preferred for large representations would be > appropriate if it were somewhat of a surprise that the resource > representation suddenly is so large. Otherwise, I agree with Zach, the > resource that gave you the URI (i.e., resource discovery or some other > resource representation) should have given you a URI with the right scheme > in the first place. > > Narrowing this down to surprises, this specific use case seems relatively > narrow. > But that may just be my lack of imagination, and of course there may be > other use cases for redirection. > > Gruesse, Carsten > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --001636c5ae1d53d4250493fcebb2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I missed that we didn't have the referenced 30x redirect code defined, = so hadn't thought of it as an addition.

OK, I see that perspecti= ve.=A0 Off-hand use cases for redirect:

* Forward a permanent URI to= the entity temporarily responsible for managing it

* Delegating complex representation formatting activities to a service = on another (less constrained) node

* Enabling client metadata such a= s message size restrictions to influence the delivery mechanism (including = the transfer protocol)

* Routing an unauthorized request to a security service through which a= uthorization can be obtained

The technique has clearly been valuable= in HTTP, but maybe it's irrelevant or unnecessary in CoAP.

Peter

On Mon, Nov 1, 2010 at 3:51 AM, Car= sten Bormann <cabo@tzi= .org> wrote:
As far as I know, we haven't made redirect a part of the CoAP state mac= hine yet.
(At least, the "30x response code" alluded to in 3.2.5 hasn't= been defined.)

Do we want to?
As with any addition to CoAP, I'd like to understand the use cases.

On the specific example (assuming that we indeed have a redirect mechanism = and that this can redirect to a full URI including scheme):
Redirect to a protocol preferred for large representations would be appropr= iate if it were somewhat of a surprise that the resource representation sud= denly is so large. =A0Otherwise, I agree with Zach, the resource that gave = you the URI (i.e., resource discovery or some other resource representation= ) should have given you a URI with the right scheme in the first place.

Narrowing this down to surprises, this specific use case seems relatively n= arrow.
But that may just be my lack of imagination, and of course there may be oth= er use cases for redirection.

Gruesse, Carsten

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

--001636c5ae1d53d4250493fcebb2-- From pab@peoplepowerco.com Mon Nov 1 06:09:08 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 406CA3A67A4 for ; Mon, 1 Nov 2010 06:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ks6n5fjnRf9D for ; Mon, 1 Nov 2010 06:09:07 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 8AC4D3A679C for ; Mon, 1 Nov 2010 06:09:06 -0700 (PDT) Received: by fxm9 with SMTP id 9so5216290fxm.31 for ; Mon, 01 Nov 2010 06:09:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.113.78 with SMTP id z14mr9126817fap.50.1288616945821; Mon, 01 Nov 2010 06:09:05 -0700 (PDT) Received: by 10.223.100.14 with HTTP; Mon, 1 Nov 2010 06:09:05 -0700 (PDT) In-Reply-To: References: <2F0A9D45-A3D3-48B8-999B-0CEA5674784D@sensinode.com> Date: Mon, 1 Nov 2010 08:09:05 -0500 Message-ID: From: Peter Bigot To: L.Wood@surrey.ac.uk Content-Type: multipart/alternative; boundary=001636c5ae1d4ea7a60493fd832a Cc: core@ietf.org Subject: Re: [core] What's to be presented to IESG in December? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 13:09:08 -0000 --001636c5ae1d4ea7a60493fd832a Content-Type: text/plain; charset=ISO-8859-1 My thought was: it's an IETF standard with over a decade's worth of interoperable implementations that use a datagram transport to transfer larger-than-one-datagram documents reliably using minimal client and server resources. A task and environment that seem to fit a CoAP need perfectly. Nobody agrees. Wish somebody'd explain why. Might help me make my comments more relevant. Peter On Sun, Oct 31, 2010 at 4:59 PM, wrote: > > On 31 Oct 2010, at 21:34, Zach Shelby wrote: > > > > You have already indicated that you personally want to use TFTP for your > application, fine. > > Why would anyone want to use tftp for _anything_? > > > puzzled, > > L. > > Lloyd Wood > L.Wood@surrey.ac.uk > http://sat-net.com/L.Wood > > > > --001636c5ae1d4ea7a60493fd832a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable My thought was:=A0 it's an IETF standard with over a decade's worth= of interoperable implementations that use a datagram transport to transfer= larger-than-one-datagram documents reliably using minimal client and serve= r resources.

A task and environment that seem to fit a CoAP need perfectly.=A0 Nobod= y agrees.=A0 Wish somebody'd explain why.=A0 Might help me make my comm= ents more relevant.

Peter

On Sun, = Oct 31, 2010 at 4:59 PM, <L.Wood@surrey.ac.uk> wrote:

On 31 Oct 2010, at 21:34, Zach Shelby wrote:
>
> You have already indicated that you personally want to use TFTP for yo= ur application, fine.

Why would anyone want to use tftp for _anything_?


puzzled,

L.

Lloyd Wood
L.Wood@surrey.ac.uk
http://sat-net.com/= L.Wood




--001636c5ae1d4ea7a60493fd832a-- From darco@deepdarc.com Mon Nov 1 14:10:34 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B8193A67B2 for ; Mon, 1 Nov 2010 14:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vd080O0JjyaR for ; Mon, 1 Nov 2010 14:10:30 -0700 (PDT) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id D43033A6767 for ; Mon, 1 Nov 2010 14:10:28 -0700 (PDT) Received: from relay16.apple.com (relay16.apple.com [17.128.113.55]) by mail-out3.apple.com (Postfix) with ESMTP id 88AB1B38C4F0; Mon, 1 Nov 2010 14:10:30 -0700 (PDT) X-AuditID: 11807137-b7bf7ae000000f05-65-4ccf2cc6486f Received: from bellatrix.apple.com (bellatrix.apple.com [17.197.13.66]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay16.apple.com (Apple SCV relay) with SMTP id CF.AB.03845.6CC2FCC4; Mon, 1 Nov 2010 14:10:30 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Robert Quattlebaum In-Reply-To: <83E52281-5A66-4ADC-B9EE-D72F1EB77A0F@tzi.org> Date: Mon, 1 Nov 2010 14:10:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <71FE4DE2-B472-45F0-83AE-FBE8E5559368@tzi.org> <83E52281-5A66-4ADC-B9EE-D72F1EB77A0F@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== Cc: core Subject: Re: [core] draft-bormann-core-coap-block-01.txt now all sliced up (Re: Next/Range Options (re: draft-ietf-core-block-00)) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 21:10:34 -0000 Hello Carsten! Overall, draft-bormann-core-coap-block-01 = appears to = address most, if not all, of my original concerns. In particular, I like = how this proposal allows for both sliced transfers in both directions = for POST/PUT requests. My largest concern is that this proposal adds = five new header options. I'll skip over the largely aesthetic concerns, ie: "slice" vs "chunk", = etc. > When a representation is larger than can be comfortably transferred > in a single UDP datagram, the Continuation options can be used to > indicate a sliced transfer. The value of both Continuation-request > and Continuation-response options is an opaque sequence of bytes = that > is used to link up one slice transaction with the next in a = sequence > of transactions. I assume that the distinction between the request and response is = necessary for asynchronous response correlation. I'd love to consolidate = these together, but I'm not sure how yet.=20 > (TBD: Does the continuation request have to supply the URI and = other > parameters again along with the Continuation-request option, or = does > the server make sure the Continuation-response provides all > information required, e.g., by sending back a descriptor or by > encoding the request parameters in the Continuation-response?) I would say yes, because doing otherwise seems like it would require = more complicated implementations. I don't think there is a great deal to = be gained by not including those headers.=20 > Each continuation response in a sliced transfer carries the = response > code that, based on information currently available, the server > expects the transfer to receive at the end of the entire sequence = of > slices, e.g. a 200 code (encoded as 80 decimal) for a successful > resource representation retrieval. However, only the response code > of the last slice transferred (i.e., without a = Continuation-response > option) is binding. I don't see the benefit of having this capability, other than returning = obnoxiously long custom 404 error messages. It also makes it impossible = for a HTTP-CoAP proxy to incrementally populate an HTTP response without = receiving (and caching) the entire content first---because the response = code goes first in the HTTP response and you don't know the "real" = response code until the end of the transfer.=20 I am inclined to either always use 206(Partial Content), or always using = 200(OK) for "sliced" transfers. I prefer 206 over 200 because 200 = implies to me that the response is self-contained.=20 > For PUT and POST requests, a client has to indicate that it = requests > a Continuation-response option from the server whenever it is = unable > or unwilling to provide the entire (rest of the) representation in > the current transaction, i.e. that the slice(s) transferred so far > are only a prefix of the entire representation to be transferred. > This is done by supplying a Continuation-required option in the > request. The request that carries the last slice of the > representation does not contain a Continuation-required option. What is the response code of the intermediate responses from the server? = 100 (Continue)? > However, the response to that last forward-transferring request may > carry a Continuation-response option, in case the representation > returned from the PUT or POST request is larger than can be > comfortably transferred in one message. The exchange then = continues > as it would for a sliced GET request. Interesting. I like this. If we specify the end of the request content as a message with no = content, then we might be able to do away with the = "continuation-required" option. In such a case we would use an empty = "continuation-request" to signify the start of the transfer. Just a = thought. > 3. The Size-Estimate option >=20 > (This is new functionality not provided by the Block option.) >=20 > The party slicing up a resource representation for sliced transfer > may have an idea of the size of the entire resource representation = in > bytes. Providing this size as an estimate may be beneficial for = the > other party. If provided, it should be sent with the first slice, > and SHOULD provide a close upper bound of the total size that will = be > transferred. In a PUT or POST transfer, both sides MAY provide a > Size-Estimate for their respective resource representation to be > transferred. I'm somewhat neutral on this new option. I wouldn't loose any sleep if = we dropped it, but if there is a compelling case for it I don't mind. > o An attacker might attempt to forge Continuation-response values = to > obtain increased access. Where the structure of the = Continuation- > response might make this possible, the server should validate it > e.g. by including an HMAC computed from a secret only known to = the > server. If replay attacks might be problem, the server should > mitigate them, e.g. by adding a timestamp or a sequence number > into the protected data. I can imagine someone using a pointer to the next item in their linked = list as the value of the continuation-request, which would be a bad, bad = idea. Perhaps we should call out cases like this specifically. __________________ Robert Quattlebaum Jabber: darco@deepdarc.com eMail: darco@deepdarc.com www: http://www.deepdarc.com/ From cabo@tzi.org Mon Nov 1 14:57:11 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6D313A67B2 for ; Mon, 1 Nov 2010 14:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z00Jm+jcBj+F for ; Mon, 1 Nov 2010 14:57:11 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 84D9D3A6774 for ; Mon, 1 Nov 2010 14:57: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 oA1LuwXf011050; Mon, 1 Nov 2010 22:56:58 +0100 (CET) Received: from [192.168.217.101] (p5489F9A1.dip.t-dialin.net [84.137.249.161]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 9DFF01B3; Mon, 1 Nov 2010 22:56:57 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Mon, 1 Nov 2010 22:56:25 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6ADE0F8E-908D-4656-8908-6154F1D80CB8@tzi.org> References: <71FE4DE2-B472-45F0-83AE-FBE8E5559368@tzi.org> <83E52281-5A66-4ADC-B9EE-D72F1EB77A0F@tzi.org> To: Robert Quattlebaum X-Mailer: Apple Mail (2.1081) Cc: core Subject: Re: [core] draft-bormann-core-coap-block-01.txt now all sliced up (Re: Next/Range Options (re: draft-ietf-core-block-00)) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 21:57:11 -0000 On Nov 1, 2010, at 22:10, Robert Quattlebaum wrote: > five new header options Yes, that's what gives me pause, too. However, one option (the Size-Estimate option) is completely unrelated = to the rest of the draft -- if we want the capability, we'll have to = have an option like this. This leaves four options for the continuation mechanism: one for message = size negotiation and three for the actual state machine. Every attempt I have made to consolidate them made things more = complicated instead of simpler. The beauty of the block option is that things just happen to fall = together nicely. (However, block does not solve the extended PUT/POST response problem; = this would probably need a second option.) As a general rule, I accept generalizing approaches only when things = become simpler or stay as simple through generalizing. But here, the generalization also addresses a somewhat unfortunate = limitation. So it's not as clear-cut. We probably should make a decision within the course of November. Gruesse, Carsten PS.: I tried to use terminology that is different from everything people = are used to, hence no chunks etc. =20 E.g., HTTP chunking is solving a completely different problem, so = reusing the term will confuse people. From darco@deepdarc.com Mon Nov 1 17:24:14 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 921B13A6A8F for ; Mon, 1 Nov 2010 17:24:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-t-0GvC-cyK for ; Mon, 1 Nov 2010 17:24:13 -0700 (PDT) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 35B063A67F1 for ; Mon, 1 Nov 2010 17:24:12 -0700 (PDT) Received: from relay15.apple.com (relay15.apple.com [17.128.113.54]) by mail-out3.apple.com (Postfix) with ESMTP id 8D2E0B396377; Mon, 1 Nov 2010 17:24:15 -0700 (PDT) X-AuditID: 11807136-b7b3aae0000033cc-56-4ccf5a2f7a22 Received: from bellatrix.apple.com (bellatrix.apple.com [17.197.13.66]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay15.apple.com (Apple SCV relay) with SMTP id 89.32.13260.F2A5FCC4; Mon, 1 Nov 2010 17:24:15 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Robert Quattlebaum In-Reply-To: <6ADE0F8E-908D-4656-8908-6154F1D80CB8@tzi.org> Date: Mon, 1 Nov 2010 17:24:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <71A4245E-5D43-4A44-B185-5BFAA489365F@deepdarc.com> References: <71FE4DE2-B472-45F0-83AE-FBE8E5559368@tzi.org> <83E52281-5A66-4ADC-B9EE-D72F1EB77A0F@tzi.org> <6ADE0F8E-908D-4656-8908-6154F1D80CB8@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== Cc: core Subject: Re: [core] draft-bormann-core-coap-block-01.txt now all sliced up (Re: Next/Range Options (re: draft-ietf-core-block-00)) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 00:24:14 -0000 Hello Carsten! On Nov 1, 2010, at 2:56 PM, Carsten Bormann wrote: > On Nov 1, 2010, at 22:10, Robert Quattlebaum wrote: >=20 >> five new header options >=20 > Yes, that's what gives me pause, too. > However, one option (the Size-Estimate option) is completely unrelated = to the rest of the draft -- if we want the capability, we'll have to = have an option like this. > This leaves four options for the continuation mechanism: one for = message size negotiation and three for the actual state machine. > Every attempt I have made to consolidate them made things more = complicated instead of simpler. After doing some more thinking, I think that we can take the option = count down from five to three if we remove the extended PUT/POST = response support (which is something previous proposals didn't support = anyway): * Replace the Message-Size and Size-Estimate with a single option value = that is interpreted as Message-size in requests and Size-Estimate in = responses. (We would however loose the ability to send a size-estimate = to the sever for sliced PUT/POST request content) * Continuation-Requried would be removed. The start of a sliced = PUT/POST request would be denoted by the presence of an empty = Continuation-response header. The end of a sliced PUT/POST request would = be denoted by a message with no content. My Range header was basically my attempt to reduce the header count = further by using the byte offset field as a way to correlate async = responses, as well as specify the maximum message size. This allows us = to merge the Continuation-requested and Continuation-required options. = We still loose the extended PUT/POST though. The name 'Range' however = implies the possibility of random access, which (based on previous = messages in this mailing list) seems to be a method of access that the = WG doesn't want to promote. I made a few passes at trying to make a = compelling case for random access in = , but = it didn't seem to catch on.=20 But if we dissect the Range header, we get two values: Max-message-size = and Continuation-offset. If we don't allow random access, the = Max-message-size only makes sense in requests, and the = continuation-offset would only make sense in async responses. This means = that we can overload a single header option value to mean = "Max-message-size" for requests and "Continuation-offset" for responses, = at the expense of Size-estimate header option. Since we can then use = Continuation-offset to correlate the async response, we can then merge = the Continuation-request and Continuation-response header options as = well. That gives us four header options using two header option indexes: RequestHeaders/ResponseHeaders Continuation-response/Continuation-request Max-message-size/Continuation-offset Zach seemed to imply in = that = this sort of header option index combo is acceptable. This would reduce = the header index count to two, sacrificing the Size-estimate header = option and the extended PUT/POST response support. It might even still be possible to do extended PUT/POST response support = using this mechanism, but I'll have to do some more thinking about that. __________________ Robert Quattlebaum Jabber: darco@deepdarc.com eMail: darco@deepdarc.com www: http://www.deepdarc.com/ From darco@deepdarc.com Mon Nov 1 17:52:30 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05BE73A69A7 for ; Mon, 1 Nov 2010 17:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UWDzYbqr0gSZ for ; Mon, 1 Nov 2010 17:52:29 -0700 (PDT) Received: from mail-out3.apple.com (mail-out.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 07F303A67DA for ; Mon, 1 Nov 2010 17:52:29 -0700 (PDT) Received: from relay16.apple.com (relay16.apple.com [17.128.113.55]) by mail-out3.apple.com (Postfix) with ESMTP id DEC65B39783B; Mon, 1 Nov 2010 17:52:31 -0700 (PDT) X-AuditID: 11807137-b7bf7ae000000f05-77-4ccf60cf0b33 Received: from bellatrix.apple.com (bellatrix.apple.com [17.197.13.66]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay16.apple.com (Apple SCV relay) with SMTP id BB.AF.03845.FC06FCC4; Mon, 1 Nov 2010 17:52:31 -0700 (PDT) From: Robert Quattlebaum Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 1 Nov 2010 17:52:31 -0700 To: core Message-Id: <5A8F194F-76E8-4A93-ADED-DFB57C2AC82E@deepdarc.com> Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== Subject: [core] application/x-www-form-urlencoded X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 00:52:30 -0000 Has anyone considered adding a content-type which would be the = equivalent of "application/x-www-form-urlencoded"? This content-type is = often used in HTTP POST requests. Considering that we have codes for = things like "application/json" and "application/soap+xml", = "application/x-www-form-urlencoded" (Or some other mime-type that = represents the format of a url query component) seems like a natural = addition. __________________ Robert Quattlebaum Jabber: darco@deepdarc.com eMail: darco@deepdarc.com www: http://www.deepdarc.com/ From matthieu.vial@fr.non.schneider-electric.com Tue Nov 2 07:58:50 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 086353A696D for ; Tue, 2 Nov 2010 07:58:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.178 X-Spam-Level: X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KtBE7WbQdDen for ; Tue, 2 Nov 2010 07:58:48 -0700 (PDT) Received: from mailX02.eud.schneider-electric.com (mailx02.eud.schneider-electric.com [205.167.7.38]) by core3.amsl.com (Postfix) with ESMTP id 2B7D13A6876 for ; Tue, 2 Nov 2010 07:58:48 -0700 (PDT) Received: from ateui02.Schneider-Electric.com ([10.198.14.10]) by mailX02.eud.schneider-electric.com with ESMTP id 2010110215403088-170906 ; Tue, 2 Nov 2010 15:40:30 +0100 In-Reply-To: To: Peter Bigot X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: matthieu.vial@fr.non.schneider-electric.com Date: Tue, 2 Nov 2010 15:58:47 +0100 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on ATEUI02.Schneider-Electric.com/T/SVR/Schneider at 02/11/2010 15:58:47, Itemize by SMTP Server on AXEU2OUT.schneider-electric.com/X/SVR/SEIxtra at 02/11/2010 15:40:30, Serialize by Router on AXEU2OUT.schneider-electric.com/X/SVR/SEIxtra at 02/11/2010 15:40:33 Content-type: multipart/related; Boundary="0__=4EBBFD5CDFA344A78f9e8a93df938690918c4EBBFD5CDFA344A7" Cc: core Subject: [core] RE CoAP block use cases (was Re: What's to be presented to IESG in December?) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 14:58:50 -0000 --0__=4EBBFD5CDFA344A78f9e8a93df938690918c4EBBFD5CDFA344A7 Content-type: multipart/alternative; Boundary="1__=4EBBFD5CDFA344A78f9e8a93df938690918c4EBBFD5CDFA344A7" --1__=4EBBFD5CDFA344A78f9e8a93df938690918c4EBBFD5CDFA344A7 Content-transfer-encoding: quoted-printable Content-type: text/plain; charset=ISO-8859-1 Hi Peter, See mvial> comments inline = Peter Bigot = = A Matthieu = 29/10/2010 17:14 Vial/FR/Non/Schneider@Europe = = cc core = Ob= jet CoAP block use cases (was Re: = [core] What's to be presented to= IESG in December?) = = = = = = = On Fri, Oct 29, 2010 at 9:11 AM, < matthieu.vial@fr.non.schneider-electric.com> wrote: >I feel coap-block is unnecessary if one can defer to alternative= protocols (and we will need Uri-Scheme back to enable that, which= I very much want) and therefore would not use it myself, but >with = a change that prevents servers from introducing it in the response = when Block doesn't appear in the request---and pending a final review-= --I would support it for December. I think we should clearly expose the use cases where coap-block w= ould be necessary. Agreed, almost.=A0 Let's expose the use cases where "something like coap-block" would be necessary.=A0 A quick attempt at "something like" produced "a client or server cannot transmit or receive a request or response for a particular resource representation in a single CoAP mess= age while meeting system quality requirements such as avoiding link-layer--induced fragmentation", which is just gross regardless of whether it's accurate. I see the following items from the previous emails. 1) transfer resources larger than the 1280-x limit There is no 1280-x limit.=A0 The formal limit is the size of an IP data= gram. Any specific numeric limit imposes an assumption of an underlying IP version and perhaps link technology, which I argued last summer was inappropriate for CoAP.=A0 We could revisit that position.=A0 But yes, = even for an IP datagram limit, this is a valid use case. mvial> Agreed, almost. Some constrained devices will probably not suppo= rt IP fragmentation. 2) force small transactions due to limited available RAM for CoAP= buffers Yes.=A0 The size-related options proposed too late for inclusion in -03= would be a good approach to ensure this situation is detected and handled, an= d are arguably a MUST for the final version. 3) semantic segmentation of a large resource to be able to produc= e and consume it incrementally. It also reduces the hardware (RAM, = CPU) requirements to process the resource. If there's a semantic segmentation within the resource representation, = I think each segment should be treatable as a distinguished resource.=A0 = That could be as simple as adding a numeric or symbolic component at the end= of the path component of the URI for the the aggregate resource.=A0 Or def= ining "first" and "next" keys in a query part and using POST, if you want to dynamically generate the representation.=A0 Absence of those keys would= require that the entire resource be returned in a single representation= , through whatever mechanism that is done. mvial> I think that 2) and 3) are highly correlated. Because a device t= hat can't receive a large content in a single transaction will probably not= have enough memory to reassemble the whole representation split into a bunch of smaller transactions. Offering an optimized mechanism to produ= ce and/or consume a large amount of data incrementally will definitely be = a nice feature. I don't know yet if it should be a builtin feature of CoA= P or just recommendations on the design of the API and URIs. >From your comment I don't get how you can create a linked list of resou= rces by just adding a symbolic component at the end of the path. You should = at least add a link to the next URI whitin the representation of each reso= urce which is part of the aggregate. Always using POST will prevent clients and proxies from caching the resource. Given the complexity to generate and transfer this kind of resource it would certainly be valuable to cache it. 4) optimize link-layer fragmentation and avoid network congestion= How CoAP should accommodate link-layer limits that are smaller than IP-datagram limits, given that there is no requirement to provide acces= s to those limits, is an open question.=A0 Again, the size-related options w= ould at least provide a way for the client and server to negotiate the transaction limits via application or even CoAP-level configuration. Protocols like tftp would probably only solve item 1) and maybe 4= ) within limits. Do you think other items are acceptable and need a solution ? (2) yes, though I don't see why tftp doesn't work there too.=A0 (3) I t= hink should be solved at the architectural level in the API, not within the transfer protocol. For non-semantic segmentation and to enable a coap-only implementation,= I think the block option can be made to work (with that change I mentione= d, and maybe a little more investigation into the impacts of random access= and/or dropped packets in the face of dynamic representation generation= ). That I currently believe TFTP is a superior approach for my own systems= is an architectural trade-off based on my strong preference to re-use existing, proven solutions unless they're clearly inappropriate. mvial> Neither POST nor caching options are available with TFTP thus I= don't think it can be considered as the ultimate solution each time a representation exceeds few link-layer packets. Being able to cache larg= e resources is very desirable. IMHO CoAP and its extensions (coap-block o= r something else) should define a comprehensive protocol that can handle = such a situation while permitting alternative solutions (TFTP, FTP...). Matthieu ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________= --1__=4EBBFD5CDFA344A78f9e8a93df938690918c4EBBFD5CDFA344A7 Content-transfer-encoding: quoted-printable Content-type: text/html; charset=ISO-8859-1 Content-Disposition: inline

Hi Peter,

See mvial> comments inline


3D"InactivePeter Bigot <pab@peoplepowerco.com>




=
          Peter Bigot <pab@peoplepowerco.com>

          29/10/2010 17:14

 = =
3D""
A
3D""
Matthieu Vial/FR/Non/Schneider@Europe
3D""
cc
3D""
core <core@ietf.org>
3D""
Objet
3D""
CoAP block use cases (was Re: [core] What's to be pres= ented to IESG in December?)
3D""3D=

On Fri, Oct 29, 2010 at 9:11 AM, <matthieu.vial@fr.non.schneider-electric.com<= /u>> wrote:

      >I feel coap-block is unnecessary if one can de= fer to alternative protocols (and we will need Uri-Scheme back to enabl= e that, which I very much want) and therefore would not use it myself, = but >with a change that prevents servers from introducing it in the = response when Block doesn't appear in the request---and pending a final= review---I would support it for December.

      I think we should clearly expose the use cases where c= oap-block would be necessary.

Agreed, almost.=A0 Let's expose the use cases where "something lik= e coap-block" would be necessary.=A0 A quick attempt at "some= thing like" produced "a client or server cannot transmit or r= eceive a request or response for a particular resource representation i= n a single CoAP message while meeting system quality requirements such = as avoiding link-layer--induced fragmentation", which is just gros= s regardless of whether it's accurate.
=A0
      I see the following items from the previous emails= .
      1) transfer resources larger than the 1280-x limit

There is no 1280-x limit.=A0 The formal limit is the size of an IP data= gram.=A0 Any specific numeric limit imposes an assumption of an underly= ing IP version and perhaps link technology, which I argued last summer = was inappropriate for CoAP.=A0 We could revisit that position.=A0 But y= es, even for an IP datagram limit, this is a valid use case.
=
mvial> Agreed, almost. Some constrained devices wil= l probably not support IP fragmentation.
=A0
      2) force small transactions due to limited availab= le RAM for CoAP buffers

Yes.=A0 The size-related options proposed too late for inclusion in -03= would be a good approach to ensure this situation is detected and hand= led, and are arguably a MUST for the final version.
=A0
      3) semantic segmentation of a large resource to be= able to produce and consume it incrementally. It also reduces the hard= ware (RAM, CPU) requirements to process the resource.

If there's a semantic segmentation within the resource representation, = I think each segment should be treatable as a distinguished resource.=A0= That could be as simple as adding a numeric or symbolic component at t= he end of the path component of the URI for the the aggregate resource.= =A0 Or defining "first" and "next" keys in a query = part and using POST, if you want to dynamically generate the representa= tion.=A0 Absence of those keys would require that the entire resource b= e returned in a single representation, through whatever mechanism that = is done.

mvial> I think that 2) and 3) are highly cor= related. Because a device that can't receive a large content in a singl= e transaction will probably not have enough memory to reassemble the wh= ole representation split into a bunch of smaller transactions. Offering= an optimized mechanism to produce and/or consume a large amount of dat= a incrementally will definitely be a nice feature. I don't know yet if = it should be a builtin feature of CoAP or just recommendations on the design of the API and URIs.
From your comment I don't get how you can create a lin= ked list of resources by just adding a symbolic component at the end of= the path. You should at least add a link to the next URI whitin the re= presentation of each resource which is part of the aggregate. Always using POST will prevent clients and proxies fro= m caching the resource. Given the complexity to= generate and transfer this kind of resource it would certainly be valu= able to cache it.
=A0
      4) optimize link-layer fragmentation and avoid net= work congestion

How CoAP should accommodate link-layer limits that are smaller than IP-= datagram limits, given that there is no requirement to provide access t= o those limits, is an open question.=A0 Again, the size-related options= would at least provide a way for the client and server to negotiate th= e transaction limits via application or even CoAP-level configuration.<= br> =A0
      Protocols like tftp would probably only solve item= 1) and maybe 4) within limits.
      Do you think other items are acceptable and need a solution ?

    (2) yes, though I don't see why tftp doesn't work there too.=A0 (3) I t= hink should be solved at the architectural level in the API, not within= the transfer protocol.

    For non-semantic segmentation and to enable a coap-only implementation,= I think the block option can be made to work (with that change I menti= oned, and maybe a little more investigation into the impacts of random = access and/or dropped packets in the face of dynamic representation gen= eration).=A0 That I currently believe TFTP is a superior approach for m= y own systems is an architectural trade-off based on my strong preferen= ce to re-use existing, proven solutions unless they're clearly inapprop= riate.

    mvial> Neither POST nor caching options are = available with TFTP thus I don't think it can be considered as the ult= imate solution each time a representation exceeds few link-layer packet= s. Being able to cache large resources is very desirable. IMHO CoAP and= its extensions (coap-block or something else) should define a comprehe= nsive protocol that can handle such a situation while permitting altern= ative solutions (TFTP, FTP...).

    Matthieu


    ______________________________________________________________________<= br> This email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________<= /font>
    = --1__=4EBBFD5CDFA344A78f9e8a93df938690918c4EBBFD5CDFA344A7-- --0__=4EBBFD5CDFA344A78f9e8a93df938690918c4EBBFD5CDFA344A7 Content-type: image/gif; name="pic02306.gif" Content-Disposition: inline; filename="pic02306.gif" Content-ID: <1__=4EBBFD5CDFA344A78@Schneider-Electric.com> Content-Transfer-Encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --0__=4EBBFD5CDFA344A78f9e8a93df938690918c4EBBFD5CDFA344A7-- From klaus.hartke@googlemail.com Tue Nov 2 10:22:13 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 875B33A69B6 for ; Tue, 2 Nov 2010 10:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id plpYryoa63i6 for ; Tue, 2 Nov 2010 10:22:12 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 4DF693A69ED for ; Tue, 2 Nov 2010 10:22:12 -0700 (PDT) Received: by bwz12 with SMTP id 12so6279889bwz.31 for ; Tue, 02 Nov 2010 10:22:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=4ORL9AJ9rYNMUR1lGn2ChVZiOoKM9zt8bTZ10P6csqk=; b=dInW9CcRyahEGuGW+X5P7hkevzFx7ls/3IE2Tbi1xNZw0ugKkQYmaRAGA3vTMbBbvd /pRuBRPt3FIaqXumDThL2kRQ571M/VobVtD/4+H97K2ngCV9G20CVv2gOOsUPlQdDfPQ m8mPVTDk09vfyKqBBTU21zVlwU4stlwX1Y878= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; b=f9cwIHeiIa105g7ZaFUKWfKQMs5edEmXGRUP84IAkrUKECCiHNIkxgnJNGaCwLmsMV PtxBQ1ES86VFmPlDw4hAa/Z/ne0etUU6d8502KlSr760LOEkymGofPHY74u1bKCRUMBk /CBWqA9ivlcZ2Kr1VfImM+nOHsW5htdE8qVvw= MIME-Version: 1.0 Received: by 10.204.116.141 with SMTP id m13mr5372048bkq.187.1288718535189; Tue, 02 Nov 2010 10:22:15 -0700 (PDT) Sender: klaus.hartke@googlemail.com Received: by 10.204.101.65 with HTTP; Tue, 2 Nov 2010 10:22:15 -0700 (PDT) Date: Tue, 2 Nov 2010 18:22:15 +0100 X-Google-Sender-Auth: PnwcoBe4A78yu5B8rJ1gwiUw-B0 Message-ID: From: Klaus Hartke To: core Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [core] Token spoofing (was Re: Comments on draft-ietf-core-coap-03) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 17:22:13 -0000 Peter Bigot wrote: >> 3.2.8. >> It is sufficient if token values are unique in use per server. > > Not generally.=A0 This is only true if the implementation retains the ser= ver > network information along with the outstanding request, and uses envelope > information from the response in combination with the token to uniquely > identify the corresponding request. Shouldn't a client always do this to prevent accidental or intentional spoofing of tokens? Klaus From klaus.hartke@googlemail.com Tue Nov 2 10:22:57 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BFA528C0D9 for ; Tue, 2 Nov 2010 10:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bkIffcX+fahp for ; Tue, 2 Nov 2010 10:22:56 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 95D233A69F3 for ; Tue, 2 Nov 2010 10:22:54 -0700 (PDT) Received: by bwz12 with SMTP id 12so6281039bwz.31 for ; Tue, 02 Nov 2010 10:22:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=4tw2o1rcpyO8eW5SqBeArwL126kUQ3FYc3rCzylEcLk=; b=fiGCgb07odNOP1M8UZsWraVa/j0tepx1kUF8VrK9MY9YtS22ZviOpK6Z6pBfKAbop5 aLgZoh7U/xA/9N/k0daXLpYTnH0LkOWURG9Lhq4+1uUTeI+yK0mz/NC9se8R/XzNOAi3 tHDacRqMSIqWEvTwscuNSl5jfkEsuMjdNGP0A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=oXF/q5N6tnyzRCAXU++MoqXZz4kxUiuwGmc+I9oHhwTFn/aOhTCWnbzOYfESxVfZuJ MKyCZhTFVQefCnbot9ZjSezoPh+N873tv8xWYu5U3pHKar05VIHPv4fCupYLU1lFeWsd g7BLhtuGFYyYi8GRiIhrW2Zej5jRlSqE7bRss= MIME-Version: 1.0 Received: by 10.204.68.142 with SMTP id v14mr7886265bki.106.1288718578606; Tue, 02 Nov 2010 10:22:58 -0700 (PDT) Sender: klaus.hartke@googlemail.com Received: by 10.204.101.65 with HTTP; Tue, 2 Nov 2010 10:22:58 -0700 (PDT) Date: Tue, 2 Nov 2010 18:22:58 +0100 X-Google-Sender-Auth: _AvU8IHnoaK49ws1SKgZjTwwUPg Message-ID: From: Klaus Hartke To: core Content-Type: text/plain; charset=ISO-8859-1 Subject: [core] Token length (was Re: Comments on draft-ietf-core-coap-03) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 17:22:57 -0000 Zach Shelby wrote: >> 3.2. >> Table 2 lists the Token Option with a length of 1-2 B. That prevents a >> lot of interesting usage cases wrt statelessness. What's the reasoning >> to limit a token to 1-2 B? > > I take responsibility for this one. Let's ask the question the other way around. Why do you need more than 64k token possibilities? When an application receives a response, it typically wants to continue executing from where it left off when it sent the request. So when it sends the request, it saves its state, and when it receives the response, it restores the state. There are two options to save the state for this purpose: (a) save it locally, assign it a number and include that number as token, or (b) save it in the token. In the first case, the client needs to take the token from the response, retrieve the locally saved state, and restore it. In the second case, the client can restore the state directly from the token in the response. The second option is very useful, as you've noted yourself: If the application needs to know the URI of the resource to continue execution when it receives a response, it is useful to have the URI included in the response. This allows, for example, a proxy to observe more than 64k resources at the same time, without having to keep any local state at all. It would be very useful to enable this for arbitrary data. Klaus From klaus.hartke@googlemail.com Tue Nov 2 10:24:30 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5A473A68DE for ; Tue, 2 Nov 2010 10:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2G2Dym4bXbUg for ; Tue, 2 Nov 2010 10:24:30 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 2FA1928C0D9 for ; Tue, 2 Nov 2010 10:24:27 -0700 (PDT) Received: by bwz12 with SMTP id 12so6283599bwz.31 for ; Tue, 02 Nov 2010 10:24:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=xWAxh05Rjy1r+mO8TytauKwUyzJ5VbjZ36jViAe8/Cg=; b=R4F4u32p0mmEMcm+AanaeVyF+NKMtCWD5CsnRdHQkMdF8VtugoG5M0PsTzCY2epILZ 7KGD0TOaXFZV/sGztCN5AHtwUuro6NbunTo9vmetoaJ4ak0Fg0UaJVEjgpdIMudSe6zE K66+/VsEqDx3ce/1QxQJ/IT8InelpPV3dkfSM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=gxT+UBma3yf7Zf1D0ETSgOiSr6lrkIsX5v9RJ3/GLAiaqtKYv4Q/AqFPpFxgvTEkPr S4EoPutfxkSv8ejsm7Q2SX22j3G9ZLo2hbfmUr+85kerKhDxJo+T7gQftf2w0ccvQOGw bRUxHSyZJV1qYwtlcmkOchO+3DYhQ4+j/pve4= MIME-Version: 1.0 Received: by 10.204.52.208 with SMTP id j16mr14425860bkg.133.1288718671104; Tue, 02 Nov 2010 10:24:31 -0700 (PDT) Sender: klaus.hartke@googlemail.com Received: by 10.204.101.65 with HTTP; Tue, 2 Nov 2010 10:24:30 -0700 (PDT) In-Reply-To: References: Date: Tue, 2 Nov 2010 18:24:30 +0100 X-Google-Sender-Auth: KueeE_e52E1o8By8r1Cz2-Y35_Y Message-ID: From: Klaus Hartke To: core Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [core] coap-observe response code X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 17:24:30 -0000 Zach Shelby wrote: > Now, it might really make sense to send a response code different than 200 for observe notifications. Something in the CoAP reserved range? Or would a new 2xx code make more sense as it could be weird to mix errors and success in the new 6xx range. We need to keep in mind that there are not only 200 responses when observing a resource. A grammar for the stream of notifications could look like this: ( 200 | 304 )* ( 404 | 500 )? 200: The resource changed to a new state; the payload contains a representation of the new state. 304: The resource changed to a new state; the Etag Option indicates which cached state the resource changed to. 404: The resource was deleted. 500: The server encountered an unexpected condition which prevented it from continuing the subscription. There are possibly more response codes that'd make sense in the context of observing resources. So we would need a new response code for many of the existing response codes. But I believe most implementations would treat them exactly like their non-notification counterpart. Klaus From klaus.hartke@googlemail.com Tue Nov 2 10:25:26 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D6C628C12A for ; Tue, 2 Nov 2010 10:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m5GnyqL8YVr8 for ; Tue, 2 Nov 2010 10:25:25 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 07A0728C126 for ; Tue, 2 Nov 2010 10:25:24 -0700 (PDT) Received: by ewy27 with SMTP id 27so3675544ewy.31 for ; Tue, 02 Nov 2010 10:25:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=Z9Bd0AfwsBhHvvSVUPD11PMrvEbkuPhrXIjiiY1yOkA=; b=XZ3IKX2zTLqoG6gfQd0BQ2RFFgCPt73EaOEQiomweOqiJoKsLgqOgm/0KmGMbmskRA U5HOs/DgdrHPjhQy+EteTKkIhrq0jadz7jQgnAmWZo3AdDaGNeLDgSj57ND234JSt6fB Fpg+F53hjotmTu/glJt2Uqkvr3zoHJVxpkTRw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=lDE0cSKJq5g7Fsg8elFsnudARFpsSjMs4U7fYKm5g+dC/L74jd/BbTrMukfBXgaK2o c3IrKGobFUPQD4TA/7NK6xGGOqyy/NJd8G1LbdwuDzxPGwtBcYFeFVxQOlYUnITt5+GP KCUa0ewnbq/XxzET0K0SEJHxJQSyaLu+Kj9s0= MIME-Version: 1.0 Received: by 10.204.68.142 with SMTP id v14mr7888691bki.106.1288718727724; Tue, 02 Nov 2010 10:25:27 -0700 (PDT) Sender: klaus.hartke@googlemail.com Received: by 10.204.101.65 with HTTP; Tue, 2 Nov 2010 10:25:27 -0700 (PDT) Date: Tue, 2 Nov 2010 18:25:27 +0100 X-Google-Sender-Auth: r4gj9cyauEgIeiWOv55STRtxLB4 Message-ID: From: Klaus Hartke To: core Content-Type: text/plain; charset=ISO-8859-1 Subject: [core] Notifying unresponsive clients (was Re: Comments on draft-ietf-core-coap-03) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 17:25:26 -0000 Peter Bigot wrote: > There must be some limit: constrainedness should not excuse clearly > undesirable behavior. In the context of CoAP-observe, it is undesirable to transmit the representation of a resource state that has already changed long ago. So what we need is some strategy that deals with the case when a resource state changes and the observer hasn't acknowledged the last confirmable notification. There are many reasons why an observer might not have acknowledged the last confirmable notification: - there's a short interruption in message delivery, - the client's battery has run out of charge, - the client can't keep up with processing the notifications, - the network is congested, - etc. We want a server to end a subscription when the client is gone, but we don't want to end a subscription just because there's a short hiccup in the network. I came up with the following possible solutions: (a) Set MAX_RETRANSMIT for confirmable notifications to 1. (b) Do not allow confirmable notifications while a confirmable notification is pending. (c) Cancel pending confirmable notifications when the next confirmable notification is to be sent. (d) Do not transmit a snapshot, but a representation of the state that is current at the instant of the retransmission. Solution (a) ends a subscription prematurely when a single message goes missing. (b) is undesirable, because it makes not a lot of sense to insist on transmitting a state that has already changed. (c) doesn't end the subscription when the client is gone but the state constantly changes before the end of the retransmission window. So (d) looked like a good choice when I added the recommendation to CoAP-observe. This doesn't mean this cannot be further improved. Thinking about it, there is another solution that I haven't thought of yet: (e) Cancel the pending confirmable notification and send the new confirmable notification with MAX_RETRANSMIT set to the number of attempts remaining from the canceled notification. Does that make sense? Klaus From klaus.hartke@googlemail.com Tue Nov 2 10:25:37 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53EFB28C132 for ; Tue, 2 Nov 2010 10:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1iHVMqv4Vr-0 for ; Tue, 2 Nov 2010 10:25:36 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 5408728C126 for ; Tue, 2 Nov 2010 10:25:36 -0700 (PDT) Received: by bwz12 with SMTP id 12so6285498bwz.31 for ; Tue, 02 Nov 2010 10:25:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=GoX7EGyaC3XqmMQIkFNq8IX2gSGxehqoqpHrZdoFMeE=; b=dfWo+z+s/dVRZf32+1R3XC7lDKnwJbF9wtGEUwoIi7f12eaPlVPbEKZ/FkTGpVeoqa 4fg8R8yAswcqVK5mweHLhNten3PWqyFFFBTEGGZKprBKbT37grHjOhcaagYL/xEjvUzQ ZLyiivnks80///NQ+e48a57791n/CX07+pOLA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; b=EMBII7Y/5FSTBBqj4z/fDY3J3THcJGhNB4lV3JS/PHlZuW384HbSk3g8LxD2JmL6Pz ig1ruoKWNBp9RIwYeqeMHUeTjvOM69tutxfxGL1xj8ae/uuEnF3NErGKrNqLA2belgS+ 5oY3+MWHCcVhr13DYIa+JBC0TtGVYzQ2omIYM= MIME-Version: 1.0 Received: by 10.204.52.208 with SMTP id j16mr14427007bkg.133.1288718739412; Tue, 02 Nov 2010 10:25:39 -0700 (PDT) Sender: klaus.hartke@googlemail.com Received: by 10.204.101.65 with HTTP; Tue, 2 Nov 2010 10:25:39 -0700 (PDT) Date: Tue, 2 Nov 2010 18:25:39 +0100 X-Google-Sender-Auth: HbMV_JsW_E4LCiJlIte9Bn_O5Gg Message-ID: From: Klaus Hartke To: core@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [core] Reordered notifications (was Re: Comments on draft-ietf-core-observe-00) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 17:25:37 -0000 Zach Shelby wrote: >>> Also, the remaining lifetime can be used to detect if notification >>> messages got reordered, although this hasn't been formalized yet. >> > Klaus has an interesting point, although that might not be the most relia= ble way to do it (what if your CoAP implementation automatically updates th= e subscription lifetime, but some application doesn't realize it?). I usual= ly recommend the payload data to include a sequence number or timestamp if = this is important. I'd prefer if the CoAP layer would weed out notifications that arrive later than more recent notifications. The goal is that the state observed by the application running on the client becomes eventually consistent with the actual state of the resource. If the sequence number or time-stamp is in the payload, it is the responsibility of the application to determine the latest known state of a resource. This is something that can be easily done by the CoAP layer, with the same result. It can simply abstract the possibility of notifications being reordered away, so applications do not have to worry about it. Klaus From rene.hummen@informatik.rwth-aachen.de Tue Nov 2 11:16:52 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A3DF3A69F2 for ; Tue, 2 Nov 2010 11:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.299 X-Spam-Level: **** X-Spam-Status: No, score=4.299 tagged_above=-999 required=5 tests=[BAYES_50=0.001, GB_SUMOF=5, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, J_CHICKENPOX_31=0.6, J_CHICKENPOX_41=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2bb4gzWfPm5w for ; Tue, 2 Nov 2010 11:16:50 -0700 (PDT) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by core3.amsl.com (Postfix) with ESMTP id 805A628C143 for ; Tue, 2 Nov 2010 11:16:49 -0700 (PDT) MIME-version: 1.0 Received: from ironport-out-2.rz.rwth-aachen.de ([134.130.5.41]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LB9008THS44SK10@mta-2.ms.rz.RWTH-Aachen.de> for core@ietf.org; Tue, 02 Nov 2010 19:16:52 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.58,283,1286143200"; d="p7s'?scan'208";a="42350319" Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by ironport-in-2.rz.rwth-aachen.de with ESMTP; Tue, 02 Nov 2010 19:16:52 +0100 Received: from umic-i4-137-226-45-95.nn.rwth-aachen.de ([unknown] [137.226.45.95]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0LB900EZMS449G90@relay-auth-1.ms.rz.rwth-aachen.de> for core@ietf.org; Tue, 02 Nov 2010 19:16:52 +0100 (CET) Content-type: multipart/signed; boundary=Apple-Mail-26--970512747; protocol="application/pkcs7-signature"; micalg=sha1 From: =?iso-8859-1?Q?Ren=E9_Hummen?= In-reply-to: <03481F84-F3DE-4794-B826-4336A187FC8F@cs.rwth-aachen.de> Date: Tue, 02 Nov 2010 19:16:56 +0100 Message-id: <782C1120-72A6-43C9-84F5-491513AD53B4@cs.rwth-aachen.de> References: <935DB371-B149-486A-8AD2-3B4454C9B172@tzi.org> <4CA3BB54.8050706@gmail.com> <4CA5E8E0.4030503@gmail.com> <4CA6095F.6040403@gmail.com> <4CB48B9B.9010206@gmail.com> <4CBF03D6.3050903@gmail.com> <44203C3A-2A58-4880-BDC9-7E0C3D16A49A@cs.rwth-aachen.de> <4CBF11BC.5040301@gmail.com> <4CBF5288.5090706@gmail.com> <4CCAC5DF.5090201@gmail.com> <03481F84-F3DE-4794-B826-4336A187FC8F@cs.rwth-aachen.de> To: Rene Struik X-Mailer: Apple Mail (2.1081) Cc: core Subject: Re: [core] HIP identities and puzzle X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 18:16:52 -0000 --Apple-Mail-26--970512747 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hello Rene, please see my comments below. On 29.10.2010, at 17:14, Tobias Heer wrote: > Hello Rene, >=20 > thanks for picking this up again. >=20 > First, one has to distinguish HIP and DEX (as proposed by Robert). HIP = is (as defined in 5201) the base protocol and DEX would be the trimmed = down variant for resource constrained scenarios. However, the DEX is = certainly still WIP and can probably be bent in one or the other = direction (if needed). I am not an author of the DEX and I somehow ended = up mandating HIP here although CoRE is certainly not my primary field of = work. Hence, I'd like to state that my intention is not to claim that = HIP is the best protocol for CoRE. I simply don't know CoRE well enough = to make such statement. However, I can try to answer some questions = related to HIP so that CoRE WG can make a sound decision on whether HIP = is something to consider or if it isn't. >=20 > Am 29.10.2010 um 15:02 schrieb Rene Struik: >=20 >> Hi Tobias: >>=20 >> It would help to have some more insight into claimed functionality of = the HIP protocol. We had some correspondence on this over the last 4 = weeks, but unfortunately detail as to claimed security properties, >=20 > I) Which specific security properties are unclear to you? Maybe we can = narrow things down a bit. Otherwise I might end up repeating the whole = protocol as described in RFC5201 here. >=20 >> distinguishing features w.r.t. other protocols, >=20 > II) Distinguishing features of HIP are (in my opinion): >=20 > On a conceptual level: > a) the implementation of the locator/identifier split,=20 >=20 > b) the quite flexible protocol design (emphasis on extendability - = many people have successfully used HIP for quite different scenarios by = extending and modifying the base protocol without breaking = compatibility), >=20 > c) the identity-focused namespace based on cryptographic identities, >=20 > d) its integration within the stack. Upper layers just use HITs like = IPv6 addresses and HIP takes care of establishing and maintaining an = authenticated and encrypted channel to the other host. =20 >=20 >=20 > Features on a more technical level are: > e) A 4-way handshake that includes authentication of both peers, = generation of a shared secret and set-up of an encrypted payload = channel. Depending on the scenario, this four-way handshake might be = better than, e.g., the multi-packet flight-based exchange of DTLS that = sends more packets. However, I am aware that HIP needs optimizations in = the form of DEX to avoid fragmentation and DTLS could probably be = modified to avoid multi-packet flights. >=20 > f) DoS prevention: HIP implements two different mechanisms here: = return routability checks and puzzles. However, depending on the = scenario, these may be applicable or may be not applicable for CoRE. I'd = be happy to discuss this. >=20 > All aforementioned points (a-f) are valid for HIP and DEX. > I will gladly give a more detailed explanation of these points if you = wish - just tell me which requires further elaboration. >=20 >> computational benefits over other approaches >=20 >=20 > HIP uses an authenticated Diffie Hellman key exchange. In terms of = public key operations, it does: >=20 > 2 public key verifications at the Initiator side > 1 public key verification at the Responder side > 1 public key signature at the Initiator side > 1 public key signature at the Responder side > 1 offline public key signature at the Responder side > 1 DH shared key generation at the Initiator side > 1 DH shared key generation at the Responder side >=20 > This is certainly not an optimal design for tightly resource = constrained devices. Hence, Robert tried to reduce the number of = computations needed without changing the way HIP works. > DEX (as proposed by Robert) uses a static Diffie Hellman key exchange = and amounts to: >=20 > 1 DH shared key generation at the Initiator side > 1 DH shared key generation at the Responder side >=20 > The actual cost of these operations depends on the chosen DH groups/ = ECC curves but the set algorithms is interchangeable and can be adopted = to the needs of the scenario. >=20 > The aforementioned numbers don't reflect the cost of the use of an = additional third-party certificate (which I believe you would like to = see in a handshake). Hence, certificate verification at the sender or = receiver should be added to the cost if the scenario demands it. >=20 > I hope this gives you a rough feeling for the cryptographic cost of = running HIP/DEX. >=20 >> Moreover, I still have trouble to understand how the protocol could = facilitate separation of device ids and cryptographic objects, as seems = to be beneficial in deployment scenarios, such as large scale = manufacturing of sensor nodes. >=20 > Ren=E9 Hummen is currently preparing a draft on the solution that I = mentioned in my previous mail. I hope he is done before or shortly after = Beijing. I hope this document will answer your questions. As Tobias mentioned, I'm currently working on a draft about a = certificate-based namespace for HIP. However, as I just started it = recently, it might well take until after Beijing. >> If you could elaborate and put the issues to rest, that would be = great. >>=20 > Sure. I hope the explanations above shed some light on the open = questions regarding HIP. I tried to put each argument/point to a new = line to make it easy for you to indicate which you would like to discuss = in more detail. >=20 >> For the benefit of easy comprehension, I would suggest a succinct = description (perhaps, with mathematical description of security-relevant = portions of the protocol flows, properties, etc?). >>=20 > I believe Rene Hummen is preparing this, too. I hope the sum of the = cryptographic operations is enough for now to develop a feeling for the = cost. I'm not an author of the DEX draft myself, but I already discussed with = Robert about the protocol and I'm very interested in the topic. That = said, these are my thoughts and findings on HIP and DEX. HIP and DEX both have - as Tobias pointed out before - a 4 way = handshake. The initial packet (I1) triggers the handshake and does not = contain any cryptographic mechanisms. I'll now go through the packet = exchange of both protocols focusing on the remaining packets R1, I2 and = R2 and describe the respective cryptographic portions. Note that Rx = (i.e. R1 and R2) denotes a packet sent by the responder, whereas Ix = (i.e. I1 and I2) represents a packet sent by the initiator.=20 HIP: ------ Initiator = Responder I1 ------------------------------------> = Create eph. DH key pair: x, g^x R1: ID_R, g^x, SIGN(ID_R, R1) <------------------------------------ VER_SIG(ID_R, R1) Create eph. DH key pair: y, g^y DH KEYMAT: Derived using HKDF* on g^{xy}, salt and peer info as input Derive shared secret from DH KEYMAT: s I2: ID_I, g^y, HMAC(s, I2), SIGN(ID_I, I2) ------------------------------------> =09= = VER_SIG(ID_I, I2) = DH KEYMAT: Derived using HKDF* on g^{xy}, salt and peer info as input = Derive shared secret from DH KEYMAT: s = HMAC(s, I2) R2: HMAC(s, R2), SIGN(ID_R, R2) <------------------------------------ HMAC(s, R2) VER_SIG(ID_R, R2) * The HMAC-based Key Derivation Function (HKDF) is defined in RFC5869. ID_x represent the public key of the respective host. SIGN and VER_SIG = use the private key as first parameter and the message as second input. = Their cost of depend on the signature algorithm in use. HIP supports = RSA, DSA and ECDSA. Likewise, HIP supports both classical DH and ECDH. DEX: ------- Initiator = Responder I1 ------------------------------------> = Existing static DH key pair: x, [ID_R =3D] g^x R1: ID_R <------------------------------------ Existing static DH key pair: y, [ID_I =3D] g^y DH DEX KEYMAT*: Derived using g^{xy}, salt and peer info as input Derive master key from DH: k Draw random secret: s_I I2: ID_I, ECR(k, s_I), CMAC(k, I2) ------------------------------------> = DH DEX KEYMAT*: Derived using g^{xy}, salt and peer info as input = Derive master key from DH: k = Verify CMAC(k, I2) = s_I =3D DCR(k, s_I) = Draw random secret: s_R = Pair-wise key**: Derived using DH DEX KEYMAT* generation function on s_I = | s_R as input R2: PK, ECR(k, s_R), CMAC(k, R2) <------------------------------------ Verify CMAC(k, R2) s_I =3D DCR(k, s_I) Pair-wise key**: Derived using DH DEX KEYMAT* generation function on s_I = | s_R as input * Section 6.3 of draft-moskowitz-hip-rg-dex-02 explains how key material = generation works in detail. ** The pair-wise key is used in DEX for the payload protection protocol.=20= ECR and DCR denote encryption and decryption functions (preferably AES = in the CoRE scenario) with the symmetric key as first input and the = plain-text as second input parameter. Furthermore, the DEX draft does = not provide signing functionality at the moment. However, I believe that = this can still be changed according to the needs of the community. I have left out performance optimizations and DoS protection mechanisms = in my descriptions (e.g. R1 pre-creation and puzzle) for the sake of = clarity. I hope that this description provides the kind of information = you are looking for. Note that PK-based authentication and DH key = derivation are two separate mechanisms with HIP and are not integrated = in a similar way as for HMQV. Please let me know, if you need more specific information on one of the = mechanisms or the packet exchange I talked about above. BR, Ren=E9 >> I am sending this to the list, since Carsten Bormann is right: the = group as a whole would benefit from technical discussions. >>=20 > Sure. >=20 > Best regards, >=20 > Tobias >=20 >=20 >=20 >> Best regards, Rene >>=20 >> On 20/10/2010 4:35 PM, Rene Struik wrote: >>> Hi Tobias: >>>=20 >>> If the device's public key and the CA's signature verification key = are similar mathematical objects (e.g., both are on the same elliptic = curve), then the crypto real estate to perform certificate self-tests = can be made to reuse that used to perform key computations with an = authenticated key agreement scheme that uses certs. Obviously, this = would require the device to have access to an authentic copy of the CA's = signature verification key. If the CA's public key is not available, it = cannot check its own cert an alternative authentic channel has to be = established between the device and an external party who attests to the = authenticity of the cert. This being said, I do not know of practical = scenarios where the latter limitation arises (usually, one does not = accept any cert for which one does not already have a bootstrapped [or = not] root CA key). >>>=20 >>> It seems somewhat dangerous to use certs to bind arbitrary strings = to public keys if the semantics of that string is not well-understood or = can be defined at will be another process. After all, if the string is = StrA and semantics of one application defines this as "temperature = sensor A", while another application defines this as "thermometer B", = confusion may arise: does (StrA, PublicKey) relate to some physical = device A or some physical device B? Not sure how this can be avoided if = one does not stipulate that for any semantics one may define, the = mapping String --> Globally Unique Device Id is an injection. = Intuitively, this seems to suggest that each string contains an object = that is 1-1 mappable to this globally unique device id. >>>=20 >>> Best regards, Rene >>>=20 >>>=20 >>>=20 >>> On 20/10/2010 2:37 PM, Tobias Heer wrote: >>>> Hi Rene, >>>>=20 >>>> Am 20.10.2010 um 17:58 schrieb Rene Struik: >>>>=20 >>>>> Hi Tobias: >>>>>=20 >>>>> No worries - I am just curious to see how HIP fits in with = ubiquitous networks of smart objects, why one would care about the = protocol, and which use cases are enabled. Depending the outcome hereof, = it may be worth pointing to in IETF drafts etc. >>>>>=20 >>>>> Some brief comments below (enclosed by RS>> and<>>>>=20 >>>>> Best regards, Rene >>>>>=20 >>>>> On 20/10/2010 11:31 AM, Tobias Heer wrote: >>>>>> Hi Rene, >>>>>>=20 >>>>>> First: thanks for your feedback. [snip(RS)]. I'll respond to the = quick questions immediately and will come back with a more detailed and = better specified description in a couple of days. Actually Ren=E9 Hummen = might respond instead of me. >>>>>>=20 >>>>>> Am 20.10.2010 um 16:59 schrieb Rene Struik: >>>>>>=20 >>>>>>> Hi Tobias, Zhen: >>>>>>>=20 >>>>>>> I would be indebted if you could provide some feedback on my = email as of Tuesday last week (October 12, 2010, 12:23pm EDT - - cf. = below). >>>>>>>=20 >>>>>>> Best regards, Rene >>>>>>>=20 >>>>>>> On 12/10/2010 12:23 PM, Rene Struik wrote: >>>>>>>> Hi Tobias: >>>>>>>>=20 >>>>>>>> Thanks for your note. >>>>>>>>=20 >>>>>>>> Does your "ascii art" description, Step 1)-3) allow the = scenario, where (a) one assigns a node id and imprints this (e.g., = blowing fuse during chip testing); >>>>>>>> (b) has a node generating its own long-term public/private key = pair and outputting its node id and public key (e.g., during chip = testing -- this would >>>>>>>> correspond to registering a public key with an RA); (c) have CA = create a certificate in different process and return this value at later = production/ >>>>>>>> personalization stage? >>>>>> a) yes it would >>>>>> b) yes, the node could generate the static DH key by itself and = acquire a certificate for this key (e.g., at deployment time) >>>>>> c) I am not completely sure what you mean with "different = process" and "return" however, I can outline the possible flexibility = that one would have: >>>>>>=20 >>>>> RS>> >>>>> Setting would be where one would register a pair (Device Id, = Public key) during production, ship a database of these pairs to a CA, = have the latter generating a certificate for (Device Id, Public key) = pairs of its choosing and tie this to associated keying material (such = as policy field, validity period, and the-like). Certificates themselves = could then find a way back to a device via any other communication = channel (does not require online/inline involvement of CA and could, = e.g., by provided when personalized in a BestBuy shop, using a BestBuy = CA (note that BestBuy CA would then have to relie on the RA used during = production - the one that collected the database). >>>>> <>>>>> (I am taking about DEX now, not HIP BEX) >>>>>>=20 >>>>>> i) The static DH key can either be node-generated or imprinted = by some entity (in a secure environment) >>>>>> ii) The certificate can either be imprinted when the node is = manufactured or it can be imprinted later (again, in a secure = environment) >>>>> RS>> >>>>> Not sure why imprinting of certificate (authorization of state = change aside) would need to be done in secured environment in general, = since this is public piece of information. >>>>> <>>> Sure, the information is public but nodes that cannot verify their = own certificate (I do not assume that all nodes are able to verify = digital signatures. However, I am not sure if it is useful to assume = that a host supports ECDH but not ECDSA) might accept an invalid = certificate and could, from that moment on, not authenticate towards a = legitimate host anymore. The secure environment is not needed if a) a = node can verify its own certificate or b) if the node can verify the = identity of the device that imprints the certificate. >>>>=20 >>>>>> iii) The certificate could be renewed at any time (provided there = is a secure mechanism for that) >>>>>> iv) The DH public key could be renewed as well (at any time), = however, a node would require a new certificate, authenticating the new = DH key then >>>>>>=20 >>>>>> For BEX, nodes' identity would be the RSA/DSA/ECDSA key of the = node instead of the static DH public key. Hence, the ephemeral DH key = would change more often while the ECDSA public key would be in the = certificate. >>>>>>=20 >>>>> RS>> >>>>> I still have some trouble understanding how identifying nodes by = their public key is going to satisfy use case scenarios where one may = have changes to the public key, different certificates, and the-like. = Please note that the objective of certificates is to provide for a = secure binding between a device's id and its private key (via the = corresponding public key), thus freeing one to just use device ids -- = after all, certificate processing would then yield the corresponding = public key(s) purportedly owned by that device. >>>>> <>>> The certificate would bind a string to the public key (static DH or = RSA/DSA/ECDSA). The string would be used by layers above HIP. HIP maps = the string to the static public key of the peer in the BEX by using the = certificate that the peer provides. A device is therefore identified by = a string not a public key (as in vanilla HIP). >>>>=20 >>>>>>>> Right now, from Section 4.1.3 of draft-ietf-hip-rfc5201-bis-02, = I get the impression that HIP does execute an authenticated DH key = agreement scheme. If so, >>>>>>>> this makes me wonder how HIP differentiates from protocols, = such as ECMQV and, e.g., HMQV, which are all not that much more = expensive than ECDH. If the >>>>>>>> difference is in the "puzzle" element, couldn't one just add = something similar to a well-known authenticated scheme that is already = standardized with, e.g., >>>>>>>> NIST? >>>>>> I'll let Ren=E9 Hummen respond to this question. >>>>>>=20 >>>>> RS>> >>>>> Sure - looking forward to this. This would be easy to compare, = once one has succinct description of the cryptographic aspects of the = protocol (so that, e.g., one can count the number of scalar point = multiplications involved, etc.). >>>>> <>>>>>>> As to forward secrecy: reason to include this is that many = sensor-type nodes can be expected to be physically unprotected (e.g., = screwed on a street lamp >>>>>>>> post, on a garage roof, etc.) and, therefore, may be more = vulnerable to device compromise over time (esp. since one cannot expect = all nodes to be tamper >>>>>>>> resistant or tamper evident). By virtue of forward secrecy, = compromise over time does not compromise the whole device's history, but = only the current set of >>>>>>>> symmetric keys (note: I make some shortcuts in my reasoning on = key management here). Admittedly, my list of security properties is = based on "desired" >>>>>>>> functionality and does not exclude functionality that may = require, e.g., public-key crypto constructs. However, from a user's = perspective, the only thing that >>>>>>>> matters is features and not what is "under the hood", as long = as that is not cost-prohibitive (which I contend it is not -- cf., e.g., = Section 3.2 of >>>>>>>> draft-struik-6lowapp-security-considerations-00). (BTW - All = other desired security properties I listed have an underlying = rationale.) >>>>>> I am still somewhat unsure about cost and capabilities of the = targeted devices. Depending on who you talk to, people seem to expect = sensors that are capable of ECC crypto, barely capable or not capable at = all. >>>>>> Are there minimal hardware specs for target devices? >>>>>>=20 >>>>> RS>> >>>>> Almost all 802.15.4-based modules have hardware support for = AES-128 (in forward mode). Since the MAC layer requires error detection = using CRC-16 linear feedback shift regsiter circuits (which is a no = brainer) and since, e.g., elliptic curves over binary extension fields = can be realized using shift registers that are of order of magnitude = anything up to 256 registers, I do not see a problem for hardware = support here (once implemented in large scale environments). >>>>>=20 >>>>> Source: http://2010.eccworkshop.org/ >>>>> Junfeng Fan(K.U.Leuven, = Belgium) >>>>> /ECC on constrained devices/ >>>>> The embedded security community has been looking at the ECC ever = since it was introduced. Hardware designers are now challenged by = limited area (<15k Gates), low power budget (<100uw) and sophisticated = physical attacks. This talk will report the state-of-the-art ECC = implementations for ultra-constrained devices. We take a passive RFID = tag as our potential target. We will discuss the known techniques to = realize ECC on such kind of devices, and what are the challenges we face = now and in the near future. >>>>> <>>> Impressive. I'll certainly give it a closer look. >>>>=20 >>>> Tobias >>>>=20 >>>=20 >>>=20 >>=20 >>=20 >> --=20 >> email: rstruik.ext@gmail.com >> Skype: rstruik >> cell: +1 (647) 867-5658 >> USA Google voice: +1 (415) 690-7363 >>=20 >=20 >=20 >=20 >=20 > --=20 > Dipl.-Inform. Tobias Heer, Ph.D. Student > Chair of Communication and Distributed Systems - comsys > RWTH Aachen University, Germany > tel: +49 241 80 207 76 > web: http://ds.cs.rwth-aachen.de/members/heer > blog: http://dtobi.wordpress.com/ > card: http://card.ly/dtobi >=20 >=20 >=20 >=20 >=20 >=20 >=20 -- Dipl.-Inform. Rene Hummen, Ph.D. Student Chair of Communication and Distributed Systems RWTH Aachen University, Germany tel: +49 241 80 20772 web: http://ds.rwth-aachen.de/members/hummen --Apple-Mail-26--970512747 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN7zCCBCEw ggMJoAMCAQICAgDHMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0 c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQD ExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNjEyMTkxMDI5MDBaFw0xOTA2MzAyMzU5 MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJ MSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKm FNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItq aACa7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMq ljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZDz+HV Ez2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjgdkwgdYwcAYD VR0fBGkwZzBloGOgYYZfaHR0cDovL3BraS50ZWxlc2VjLmRlL2NnaS1iaW4vc2VydmljZS9hZl9E b3dubG9hZEFSTC5jcmw/LWNybF9mb3JtYXQ9WF81MDkmLWlzc3Vlcj1EVF9ST09UX0NBXzIwHQYD VR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHDeRu69VPXF+CJei0XbAqz K50zMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgECMA0GCSqGSIb3DQEBBQUAA4IB AQA74Vp3wEgX3KkY7IGvWonwvSiSpspZGBJw7Cjy565/lizn8l0ZMfYTK3S9vYCyufdnyTmieTvh ERHua3iRM347XyYndVNljjNj7s9zw7CSI0khUHUjoR8Y4pSFPT8z6XcgjaK95qGFKUD2P3MyWA0J a6bahWzAP7uNZmRWJE6uDT8yNQFb6YyC2XJZT7GGhfF0hVblw/hc843uR7NTBXDn5U2KaYMo4RMJ hp5eyOpYHgwf+aTUWgRo/Sg+iwK2WLX2oSw3VwBnqyNojWOl75lrXP1LVvarQIc01BGSbOyHxQoL BzNytG8MHVQs2FHHzL8w00Ny8TK/jM5JY6gA9/IcMIIE2jCCA8KgAwIBAgIEDuQh4zANBgkqhkiG 9w0BAQUFADBeMQswCQYDVQQGEwJERTEUMBIGA1UEChMLUldUSCBBYWNoZW4xFzAVBgNVBAMTDlJX VEggQWFjaGVuIENBMSAwHgYJKoZIhvcNAQkBFhFjYUByd3RoLWFhY2hlbi5kZTAeFw0wOTEwMDEx MjQ1MDdaFw0xMjA5MzAxMjQ1MDdaMDkxCzAJBgNVBAYTAkRFMRQwEgYDVQQKEwtSV1RIIEFhY2hl bjEUMBIGA1UEAxMLUmVuZSBIdW1tZW4wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCw KpV77WtQa3ZIx+dWRTgR8wxSUsQoSEY2Do5wNPJ/m3hO3P7e8FfVKSaTimKHvRPiRvCX+HW2ldMA f33GWtJTrN6hbSHzQTpq84uQOp/R8ad094wdKbenITaOWISEAjymgA0gS1RpvxaOv5r9uw1Th2ci kjWEOA3tIXCFwFwfMzA/QllikzSkbmm8a6RryOUyQCqCpt9GGS0i1KC+NIa/GP883S4W4En9PxA+ VJ4hJFwjnIt0E+wUigPBQvLHxRqBT/sXSJxsSZO/uNR99dxKeQmdd4Uob5olMA94uZX/rbeZdgDu 49qSIlx/bEFzJTQzH7yDATed6nXGDojAVHeBAgMBAAGjggHDMIIBvzAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIF4DApBgNVHSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisGAQQBgjcUAgIwHQYDVR0O BBYEFN+tg8k5s/o7Bjed1LmJouNUa4NUMB8GA1UdIwQYMBaAFG7VPsAcL3HJPL9JTu9qVUjs0fI4 MCgGA1UdEQQhMB+BHXJlbmUuaHVtbWVuQGNzLnJ3dGgtYWFjaGVuLmRlMHkGA1UdHwRyMHAwNqA0 oDKGMGh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvcnd0aC1jYS9wdWIvY3JsL2NhY3JsLmNybDA2oDSg MoYwaHR0cDovL2NkcDIucGNhLmRmbi5kZS9yd3RoLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGUBggr BgEFBQcBAQSBhzCBhDBABggrBgEFBQcwAoY0aHR0cDovL2NkcDEucGNhLmRmbi5kZS9yd3RoLWNh L3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDBABggrBgEFBQcwAoY0aHR0cDovL2NkcDIucGNhLmRmbi5k ZS9yd3RoLWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQUFAAOCAQEAmXPLNSHW Ze3V4Rq3P2pcaBIlY4Z/nJ1jH3u6yBD3gGZrthpu1o0g45hOWbcvkkcQwvEXKlnWeiVXJsQ2XElz ydNFQprK9GFRZvuOJUkMdR87uupqLESpoue7kmTVCFcqg8c/Q9D5KTbTTtrGDydcqKy+MWbrbtGb lg0R8ZJmnIlb+8RLCqa4MbYq2M2kiImYzDrczlPWvy3SHiPASNFf31XDLFP26QlO3USacm/E+CfM sgQFudf9BqE6yW8qoqx0x1xyMdo5tWyT1MUKsDA/cGADc+r2orBNBsZ7AjdPi85fJS3NE2PGhMEZ BCsvt/EC/yIQK7O3DwELk0VlVaE/uDCCBOgwggPQoAMCAQICBAnydOAwDQYJKoZIhvcNAQEFBQAw WjELMAkGA1UEBhMCREUxEzARBgNVBAoTCkRGTi1WZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAi BgNVBAMTG0RGTi1WZXJlaW4gUENBIEdsb2JhbCAtIEcwMTAeFw0wNzAyMTQxMTQ5MzhaFw0xOTAy MTMwMDAwMDBaMF4xCzAJBgNVBAYTAkRFMRQwEgYDVQQKEwtSV1RIIEFhY2hlbjEXMBUGA1UEAxMO UldUSCBBYWNoZW4gQ0ExIDAeBgkqhkiG9w0BCQEWEWNhQHJ3dGgtYWFjaGVuLmRlMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuDAIZOPI3HpS3zVCOZLzL/gheeMSZy+Mf3CUJzdjSHeg id36rNLIjtnsSAAn83Y8TlKUOmRTp+aXU704u7LZ5PFgGj/3fSxXfJPRm8Y4e8Ydy/tGt2nPv7Ry XF+euJ7VMRrVRjLkoRKFGmVE+X8Pe0y9+lCfDqly66qXQCnBSmifqYEadoEy4+DDVDD4wOBpbLaY 6C50/vqhZu7f2UvdvxNzqjSVMBx+gt+b0q6FbHJoPmu18U+lOCTvfTGMTXEyDM4T0vWLaft9NsO4 udXWgY69IRRjytJy0leoL++8wUhSewFRiScQUlMw59MZAy2L2cKmnmJI/JAwdqEnkcnxowIDAQAB o4IBsDCCAawwDwYDVR0TAQH/BAUwAwEB/zALBgNVHQ8EBAMCAQYwHQYDVR0OBBYEFG7VPsAcL3HJ PL9JTu9qVUjs0fI4MB8GA1UdIwQYMBaAFEm3xs/oPR9/6kR7Eyn38QpwPt5kMBwGA1UdEQQVMBOB EWNhQHJ3dGgtYWFjaGVuLmRlMIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NkcDEucGNhLmRm bi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2NhY3JsLmNybDA9oDugOYY3aHR0cDovL2NkcDIu cGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2NhY3JsLmNybDCBogYIKwYBBQUHAQEE gZUwgZIwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2Ev cHViL2NhY2VydC9jYWNlcnQuY3J0MEcGCCsGAQUFBzAChjtodHRwOi8vY2RwMi5wY2EuZGZuLmRl L2dsb2JhbC1yb290LWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQUFAAOCAQEA F4d+xiwLHCB61akGKxuT/3WFC8QLHlOsblyp0qVU5zFlRX9U7Tf6dg/vF0yrZfwOFpWGvZ6fjjW5 VnEtZybLmH+zfcKzuMwhHFQTSyABwmN2VxviKDR8IF6kmKlx86wEGY5Eia9UX2xROJ41MtJzYbQu dR19KJ4Fn6jg3Os+2hfcHttOteTIfCpPLqMeF4Iyy1f1Iz1ZcEQJ7mCHhdMMnL0Oo8/zyTLjq10o aano6WokV6isfKD1wJQnJ6KkS5UHNS9IsEBwZ9BJurQ5jB3GoW3/UgTlomfPjtGr+JcvAkPeaJM/ YbaPVBK11CMzXmtgEFwbZSMiyyoFbmD3+ItyMjGCAt4wggLaAgEBMGYwXjELMAkGA1UEBhMCREUx FDASBgNVBAoTC1JXVEggQWFjaGVuMRcwFQYDVQQDEw5SV1RIIEFhY2hlbiBDQTEgMB4GCSqGSIb3 DQEJARYRY2FAcnd0aC1hYWNoZW4uZGUCBA7kIeMwCQYFKw4DAhoFAKCCAU0wGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTAxMTAyMTgxNjU2WjAjBgkqhkiG9w0BCQQx FgQUgh15Jl/ObdWKMesUsYOoCP0V53AwdQYJKwYBBAGCNxAEMWgwZjBeMQswCQYDVQQGEwJERTEU MBIGA1UEChMLUldUSCBBYWNoZW4xFzAVBgNVBAMTDlJXVEggQWFjaGVuIENBMSAwHgYJKoZIhvcN AQkBFhFjYUByd3RoLWFhY2hlbi5kZQIEDuQh4zB3BgsqhkiG9w0BCRACCzFooGYwXjELMAkGA1UE BhMCREUxFDASBgNVBAoTC1JXVEggQWFjaGVuMRcwFQYDVQQDEw5SV1RIIEFhY2hlbiBDQTEgMB4G CSqGSIb3DQEJARYRY2FAcnd0aC1hYWNoZW4uZGUCBA7kIeMwDQYJKoZIhvcNAQEBBQAEggEAIbOB Ed0s1n1o1YM6YzV9W1tf36us3chAywAIaY49q8yTlSX/9bwj7FmnMBLJhAhbYQu0lNpCKWWRuyi6 /Rgf5osa6Ie42a+JXW4YtQ5UL0nHz/baaiUdAoO62tqKvgYvG25BD5ORL4GVgqLACBrM2kyLC0cj I+CIqlP+vyDYiMHI32yow+kanJCYJL36s8pttv8iltBw3X417lUVCl6Axy+KfNoS55aAZqfrA15L RvYXasWGKd+Uci4j5E71SJI5MswNHrSeTQ1Lh0yNr7r8UFyedn2kyRwAZ5uuyatvAB6cg+JoZ/uO ukePlAzB7pQYNmZ0x8fzVxjZAqXXgrVDGwAAAAAAAA== --Apple-Mail-26--970512747-- From angelo.castellani@gmail.com Wed Nov 3 00:58:32 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9FF43A6A9B for ; Wed, 3 Nov 2010 00:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WyRwN2cH5QDV for ; Wed, 3 Nov 2010 00:58:31 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id BD40C3A6A93 for ; Wed, 3 Nov 2010 00:58:30 -0700 (PDT) Received: by ywp6 with SMTP id 6so273684ywp.31 for ; Wed, 03 Nov 2010 00:58:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=BM1trDHCjaWnl0eR2rrIuUi6j4JIc76s8Dobqudhz2U=; b=CiusVjBexbbYYtvTVWXa4MOjIRJcUtKoZ/p7evDqPxitcQH4tdojZeNRUNLUrhw91/ istJBrpk6iyLpgCnkpMOkQzhHEAd4Ri+zFtc59Xi0w9/OZJmtlTMR8av6mg28btuIkb8 nLngto5hiFxiite9uQfq+bpwgii7y5R1n4aBU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=N7KK4kJYkMgyEIO8286YXkMSxNdVVZAB6+oVyeFtfSKc107dNb92v1xD5mlghJCIIe JqoepRVtyCJ7uRQ+toHDOzu7+r9C0e8yBB6bm8GWilIEcAUO9Bly1nVef/D551//TLVp VKOatbJCnVBCX0fvUtvMSBsaEZsPx8sTAOI+M= Received: by 10.229.215.8 with SMTP id hc8mr10637278qcb.23.1288771116814; Wed, 03 Nov 2010 00:58:36 -0700 (PDT) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.229.249.201 with HTTP; Wed, 3 Nov 2010 00:58:16 -0700 (PDT) In-Reply-To: References: From: "Angelo P. Castellani" Date: Wed, 3 Nov 2010 08:58:16 +0100 X-Google-Sender-Auth: AZJG56nZBmWubgEESAX4y1T-3WQ Message-ID: To: Klaus Hartke Content-Type: multipart/alternative; boundary=0016e65dc4ee9d52e2049421682d Cc: core Subject: Re: [core] Token length (was Re: Comments on draft-ietf-core-coap-03) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 07:58:32 -0000 --0016e65dc4ee9d52e2049421682d Content-Type: text/plain; charset=ISO-8859-1 On Tue, Nov 2, 2010 at 18:22, Klaus Hartke wrote: > (b) save it in the token. > When the server that has to handle and store the Token is a constrained node, this is an undesiderable behaviour. Constrained devices have strong limitations in RAM, so requesting the node to store an arbitrary amount of data as "Token" of the served request is not efficient; also handling variable length Tokens can lead to a more complex implementation, because static memory allocation is tipically used on that kind of systems (e.g.: TinyOS). Angelo --0016e65dc4ee9d52e2049421682d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    On Tue, Nov 2, 2010 at 18:22, Klaus Hartke <hartke@tzi.org> wrote:
    (b) save it in the token.
    =A0
    When the server that = has to handle and store the Token is a constrained node, this is an undesid= erable behaviour.

    Constrained devices have strong limitations in RAM, so reque= sting the node to store an arbitrary amount of data as "Token" of= the served request is not efficient; also handling variable length Tokens = can lead to a more complex implementation, because static memory allocation= is tipically used on that kind of systems (e.g.: TinyOS).

    Angelo

    --0016e65dc4ee9d52e2049421682d-- From klaus.hartke@googlemail.com Wed Nov 3 05:54:08 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BEC03A68DA for ; Wed, 3 Nov 2010 05:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1a+E2pN7ShrZ for ; Wed, 3 Nov 2010 05:54:07 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id E68BF3A68D2 for ; Wed, 3 Nov 2010 05:54:05 -0700 (PDT) Received: by bwz12 with SMTP id 12so532691bwz.31 for ; Wed, 03 Nov 2010 05:54:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=6C1QXIKJbaXIv+sR3QmkT0oTlnQs8tGCAh52KQhYupc=; b=d7WWPcCng0UBKsR0IRTA/ucu8MDvMXzw+CMpIX54wfTgFjsC4M7p85w8bSwS3TCgGN nItDu5yqGZ/DKkW3mWfP7WFLYWrIecX2hgSURq76s5vs9ZkJ7mrBwoUqJ+0VsvvJULOj 5MNzHjt//rTXDKxf7rbOrAjwFZ03ZvOfo+PNs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=Nl2v3FrMGxzi12wlkxFO7XjkAcz9fDV5I8wtx5DAGq/dD7KBnZG0u9I0nSSCio8dgA zkqXVSUEsZG3+UQzDafwkAfV7M0LekShYvPJYDhCRSAAttjqjJSceN0waISO+eXpf9tp buprm0y0qBJgb3wwkK0ECVshgiSpadmUUThx0= MIME-Version: 1.0 Received: by 10.204.103.66 with SMTP id j2mr11705732bko.160.1288788851994; Wed, 03 Nov 2010 05:54:11 -0700 (PDT) Sender: klaus.hartke@googlemail.com Received: by 10.204.101.65 with HTTP; Wed, 3 Nov 2010 05:54:11 -0700 (PDT) In-Reply-To: References: Date: Wed, 3 Nov 2010 13:54:11 +0100 X-Google-Sender-Auth: 3hSCPV0hHeRH8yCAk8RtJ5jLwEw Message-ID: From: Klaus Hartke To: core Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [core] Token length (was Re: Comments on draft-ietf-core-coap-03) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 12:54:08 -0000 Angelo P. Castellani wrote: > Constrained devices have strong limitations in RAM, so requesting the node > to store an arbitrary amount of data as "Token" of the served request is not > efficient; also handling variable length Tokens can lead to a more complex > implementation, because static memory allocation is tipically used on that > kind of systems (e.g.: TinyOS). It's not an _arbitrary_ amount of data; it still needs to fit in a single option (270 bytes at most). A URI can be up to 810 bytes in length (authority+path+query), and it doesn't seem to a concern to include that in every notification. Klaus From zach@sensinode.com Wed Nov 3 06:04:53 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A67AF3A6AA6 for ; Wed, 3 Nov 2010 06:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.392 X-Spam-Level: X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pVXMFrBcWNgt for ; Wed, 3 Nov 2010 06:04:52 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 8F0B53A68DA for ; Wed, 3 Nov 2010 06:04:51 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id oA3D4spC001265 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 3 Nov 2010 15:04:55 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-239--902832809; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: Date: Wed, 3 Nov 2010 15:04:55 +0200 Message-Id: <139C9A0D-6F59-4369-9B53-AD99804931B1@sensinode.com> References: To: Klaus Hartke X-Mailer: Apple Mail (2.1081) Cc: core Subject: Re: [core] Token length (was Re: Comments on draft-ietf-core-coap-03) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 13:04:53 -0000 --Apple-Mail-239--902832809 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 3, 2010, at 2:54 PM, Klaus Hartke wrote: > Angelo P. Castellani wrote: >> Constrained devices have strong limitations in RAM, so requesting the = node >> to store an arbitrary amount of data as "Token" of the served request = is not >> efficient; also handling variable length Tokens can lead to a more = complex >> implementation, because static memory allocation is tipically used on = that >> kind of systems (e.g.: TinyOS). >=20 > It's not an _arbitrary_ amount of data; it still needs to fit in a > single option (270 bytes at most). I was just going to ask if that is what you had in mind. So Token Option = would be 1-270 B.=20 >=20 > A URI can be up to 810 bytes in length (authority+path+query), and it > doesn't seem to a concern to include that in every notification. That does not require state on the server though, just over the air. The = server already knows the URI of the resource it is sending a = notification about. What Angelo (and myself) are concerned about is = forcing a server to hold even more state about each observation. The = current state is not too bad, the IP address + port of the observer and = the lifetime (4B). But adding up to a 270 B token starts to get extreme. = Many of these nodes have 4-8 kB of RAM in total. What that means in = practice is that observations with a large token might be rejected = because of lack of RAM, or a node will be able to handle very few = observations. =20 Are you suggesting forcing the use of a Token with coap-observe? I was = assuming that if no Token was provided then the notification would = simply include the Uri-Path of the resource.=20 Zach=20 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 --Apple-Mail-239--902832809 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9 fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb 6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja 5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I 2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTEwMzEzMDQ1 NlowIwYJKoZIhvcNAQkEMRYEFCWNvYa+1GeW1x8nIHQCYLF9nJf1MIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAHTGurwCPNUxWqteIhIGX6JFE4XkEgF2ErZEP+87ejKjsjRXAYFb/V4/ a5790Z1lSS9TK6PFKVPc9lEHlm5v9MNHrAPGt919Y+BegaTM/XbRLOLAZlJh8YSVn3ta7B8dwcu1 ircT5EgOBGp3rIDR8Ya7oGlKakQpWb7fcgtV/ckZkQEmJDpGzt5bX8mZ7fwR18ohWeiOxrPaBTgW bhNEZu3X+JfVv/BuY7jrebqRI1e3uVvj8UD0ojTS2A2AegrFn4kFecaOUh9l/nnr40H+0I8PLpRx kv+i5eXDctBaLI8BQhb06Ukf69OsS9hT9cYGDbMhtkE+8SVrlC0xzda2KMEAAAAAAAA= --Apple-Mail-239--902832809-- From klaus.hartke@googlemail.com Wed Nov 3 06:23:40 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC4D63A6A5D for ; Wed, 3 Nov 2010 06:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fNy2dSWsX9gG for ; Wed, 3 Nov 2010 06:23:40 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 8676C3A6838 for ; Wed, 3 Nov 2010 06:23:39 -0700 (PDT) Received: by bwz12 with SMTP id 12so561281bwz.31 for ; Wed, 03 Nov 2010 06:23:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=671jKXP+l0wUL4zxBcHESfS/xDCLo9VCp62vve5goo8=; b=Z9vWcs9OcFAvOwDy4QCdAG6fJR5T0BeE/1fuYCYxBMlmjDp1+T7eC84dcNY+72jYLA azbgLN2DDQXGW3yp/F3cw+nrtL3/xQ+u1MAufE47AB/OJya0R6V7XmXz/m4OsYSbxs0i mIHxDxRu96HxGQAhjEYjLpJv3K924a8B2Jssg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=voBsnOR8A3psGsv4vTYikjJPwl1BpuAcC882xxfNANrEUER6QbbZ6V59pSzosraZIG gPNkoLtexRySD9tEfNjYKVbBF0LN1dcMy5DSME6hXMdrdwK8LFXJ3qqlo6/7/lRXofTF QwiyYfEN/yUNBZ0ZKxIB3HqxqV+KXw905pDYQ= MIME-Version: 1.0 Received: by 10.204.72.80 with SMTP id l16mr802407bkj.133.1288790626005; Wed, 03 Nov 2010 06:23:46 -0700 (PDT) Sender: klaus.hartke@googlemail.com Received: by 10.204.101.65 with HTTP; Wed, 3 Nov 2010 06:23:45 -0700 (PDT) In-Reply-To: <139C9A0D-6F59-4369-9B53-AD99804931B1@sensinode.com> References: <139C9A0D-6F59-4369-9B53-AD99804931B1@sensinode.com> Date: Wed, 3 Nov 2010 14:23:45 +0100 X-Google-Sender-Auth: vhbF1lP-pHHYxBrX35H6abCmKSQ Message-ID: From: Klaus Hartke To: core Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [core] Token length (was Re: Comments on draft-ietf-core-coap-03) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 13:23:40 -0000 Zach Shelby wrote: >> A URI can be up to 810 bytes in length (authority+path+query), and it >> doesn't seem to a concern to include that in every notification. > > That does not require state on the server though, just over the air. The server already knows the URI of the resource it is sending a notification about. > [...] > Are you suggesting forcing the use of a Token with coap-observe? I was assuming that if no Token was provided then the notification would simply include the Uri-Path of the resource. Yes, it knows the authority and the path. But not the query - which may potentially be different for each observer and which needs to be included in every notification (a notification about the resource /sensors/temperature?unit=celsius does not provide a new state for the resource /sensors/temperature?unit=fahrenheit if both resources are observed at the same time). Klaus From zach@sensinode.com Wed Nov 3 06:30:06 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D1B928C0DC for ; Wed, 3 Nov 2010 06:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.995 X-Spam-Level: X-Spam-Status: No, score=-2.995 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Px6PzbaZSjST for ; Wed, 3 Nov 2010 06:30:03 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id ADEFE3A6ABA for ; Wed, 3 Nov 2010 06:30:02 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id oA3DU5T6005358 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 3 Nov 2010 15:30:06 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-242--901321442; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: Date: Wed, 3 Nov 2010 15:30:07 +0200 Message-Id: References: <139C9A0D-6F59-4369-9B53-AD99804931B1@sensinode.com> To: Klaus Hartke X-Mailer: Apple Mail (2.1081) Cc: core Subject: Re: [core] Token length (was Re: Comments on draft-ietf-core-coap-03) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 13:30:07 -0000 --Apple-Mail-242--901321442 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 3, 2010, at 3:23 PM, Klaus Hartke wrote: > Zach Shelby wrote: >>> A URI can be up to 810 bytes in length (authority+path+query), and = it >>> doesn't seem to a concern to include that in every notification. >>=20 >> That does not require state on the server though, just over the air. = The server already knows the URI of the resource it is sending a = notification about. >> [...] >> Are you suggesting forcing the use of a Token with coap-observe? I = was assuming that if no Token was provided then the notification would = simply include the Uri-Path of the resource. >=20 > Yes, it knows the authority and the path. But not the query - which > may potentially be different for each observer and which needs to be > included in every notification (a notification about the resource > /sensors/temperature?unit=3Dcelsius does not provide a new state for = the > resource /sensors/temperature?unit=3Dfahrenheit if both resources are > observed at the same time). Agreed.=20 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 --Apple-Mail-242--901321442 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9 fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb 6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja 5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I 2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTEwMzEzMzAw N1owIwYJKoZIhvcNAQkEMRYEFIfpxDfRDZLosLmuDdwyLHoLY6F8MIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAJg63t2H6d+2bhPfB85dBd8zfh5xIj+Bf+mxvlYx3bUDSpQXKheJf5IQ ZT/QaPH3oW7VB6odez+6pkFLtETp9x6r3c0FWELRK4MmWdT7OlySNCsTUH0nk4MD3IS+zdPyzOpX JqBp2ys5mJCLL+t9zTQRZAHIY61X37QPRo+5aaHzoIYl9Vak8UfC3GJ8ZC4+q2VnDYLUUVkEkISl nB41PBg2SzElzU98pOHPt7ISw2TziBEtAE0fhy2apSu1mT6iCDSPRQ8L1reWI3ppPZ13zGpO8KkT wJQcVoKa4TVIZhAbMZsF8UsvNYh2gKVHH8g1/AZ56kVdd3WefNKKNFH6SEYAAAAAAAA= --Apple-Mail-242--901321442-- From adam@nostrum.com Wed Nov 3 08:01:58 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AA753A69B8 for ; Wed, 3 Nov 2010 08:01:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Ah0rHIIi6yq for ; Wed, 3 Nov 2010 08:01:57 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 35A3128C0ED for ; Wed, 3 Nov 2010 08:01:53 -0700 (PDT) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id oA3F1xA7099539 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 3 Nov 2010 10:02:00 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4CD17966.8020504@nostrum.com> Date: Wed, 03 Nov 2010 10:01:58 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Zach Shelby References: <139C9A0D-6F59-4369-9B53-AD99804931B1@sensinode.com> In-Reply-To: <139C9A0D-6F59-4369-9B53-AD99804931B1@sensinode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: core , Klaus Hartke Subject: [core] Subscription Refresh Correlation (was Re: Token length (was Re: Comments on draft-ietf-core-coap-03)) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 15:01:58 -0000 On 11/3/10 8:04 AM, Zach Shelby wrote: > Are you suggesting forcing the use of a Token with coap-observe? I was > assuming that if no Token was provided then the notification would > simply include the Uri-Path of the resource. I've been trying to figure out how subscription correlation (for the purpose of refreshing subscriptions) would work without tokens. In fact, coap-observe is a bit under-specified regarding matching subscription refreshes to the original subscription. Clearly, when a client provides a token, the server should be able to recognize refreshes as being (a) to the same resource, (b) from the same client (IP and port), and (c) with the same token. Do we want to make it so that a subscription without a token would simply be correlated by being (a) to the same resource and (b) from the same client? On a slightly related note, there should probably be a sentence or two in coap-observe that talks about how clients unsubscribe from a resource. Once we have an explicit subscription correlation model, all the mechanisms are actually in place: refreshing a subscription with a duration of "0" would cause the subscription to immediately expire (this is a natural property of the current design). It would be nice if the draft pointed this out. /a From klaus.hartke@googlemail.com Wed Nov 3 09:56:43 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48C3628C0D8 for ; Wed, 3 Nov 2010 09:56:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lR-962Sql+uJ for ; Wed, 3 Nov 2010 09:56:42 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id B5E633A69E7 for ; Wed, 3 Nov 2010 09:56:40 -0700 (PDT) Received: by bwz12 with SMTP id 12so767614bwz.31 for ; Wed, 03 Nov 2010 09:56:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=EQPsDcgEjr5DFoljd10djI55Q5UopBFyfIFhbfZTH40=; b=t8uNxvaWDLhWWtNIwgb9n8cJc0X9u5e//V35wdH/N8yqOJ7Qv2QDXrAa1Z34O3qsua xQzyewUmZMLNYhC52T00IT6kNkRN4fRFWvMMwl3U4eWu6hpIfOcEjRs5rjGqEpCLBobl f4kJ4UtmWZxO/us9UfpY4qPs58FZ3Csn3IkoM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=VFj/JR1Xh0IoDnvaZlj/3J6RtBHIkAbBb9VoTVjIZhdNarCBEt0fl4LnAvdVDENVd2 K6iiQ/PEgs6qvgSd2a1tHfgliM4ny+ZnrFSsztsvx+OYuph+vRdwIHw/Ocxbiqjz/mCr DRkVQZ2hLowspkLOcchnRG4I3kTcWnxoOCCfQ= MIME-Version: 1.0 Received: by 10.204.68.142 with SMTP id v14mr981825bki.106.1288803407352; Wed, 03 Nov 2010 09:56:47 -0700 (PDT) Sender: klaus.hartke@googlemail.com Received: by 10.204.101.65 with HTTP; Wed, 3 Nov 2010 09:56:47 -0700 (PDT) In-Reply-To: <4CD17966.8020504@nostrum.com> References: <139C9A0D-6F59-4369-9B53-AD99804931B1@sensinode.com> <4CD17966.8020504@nostrum.com> Date: Wed, 3 Nov 2010 17:56:47 +0100 X-Google-Sender-Auth: xpesAv0i9nzPV4pBDGlGvnUASQI Message-ID: From: Klaus Hartke To: core Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [core] Subscription Refresh Correlation (was Re: Token length (was Re: Comments on draft-ietf-core-coap-03)) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 16:56:43 -0000 Adam Roach wrote: > I've been trying to figure out how subscription correlation (for the purpose > of refreshing subscriptions) would work without tokens. In fact, > coap-observe is a bit under-specified regarding matching subscription > refreshes to the original subscription. > > Clearly, when a client provides a token, the server should be able to > recognize refreshes as being (a) to the same resource, (b) from the same > client (IP and port), and (c) with the same token. > > Do we want to make it so that a subscription without a token would simply be > correlated by being (a) to the same resource and (b) from the same client? It is the intention that a subscription is identified by (a) the URI of the resource (including Uri-Query) and (b) the identity of the client (IP and port). A client may or may not reuse the same token when refreshing a subscription. I will clarify this in coap-observe. > On a slightly related note, there should probably be a sentence or two in > coap-observe that talks about how clients unsubscribe from a resource. Once > we have an explicit subscription correlation model, all the mechanisms are > actually in place: refreshing a subscription with a duration of "0" would > cause the subscription to immediately expire (this is a natural property of > the current design). It would be nice if the draft pointed this out. Refreshing a subscription with a duration of 0 seconds actually doesn't unsubscribe the client immediately. It sets the remaining lifetime of the subscription to 0 seconds, but also retrieves the current state of the resource (it's indistinguishable from a basic GET request). I agree it would be nice to have this mention in the draft, including the "surprise" that a non-subscription-related GET request can affect a subscription. I will add this to coap-observe. Klaus From adam@nostrum.com Wed Nov 3 10:42:13 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FB923A69FA for ; Wed, 3 Nov 2010 10:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3vTK1-mAZmL for ; Wed, 3 Nov 2010 10:42:12 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id B12B03A69EF for ; Wed, 3 Nov 2010 10:42:11 -0700 (PDT) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id oA3HgHkJ013373 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 3 Nov 2010 12:42:18 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4CD19EF9.3050107@nostrum.com> Date: Wed, 03 Nov 2010 12:42:17 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Klaus Hartke References: <139C9A0D-6F59-4369-9B53-AD99804931B1@sensinode.com> <4CD17966.8020504@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: core Subject: Re: [core] Subscription Refresh Correlation (was Re: Token length (was Re: Comments on draft-ietf-core-coap-03)) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 17:42:13 -0000 On 11/3/10 11:56 AM, Klaus Hartke wrote: > Refreshing a subscription with a duration of 0 seconds actually > doesn't unsubscribe the client immediately. It sets the remaining > lifetime of the subscription to 0 seconds, but also retrieves the > current state of the resource (it's indistinguishable from a basic GET > request). Right. We do the same thing in SIP (unless the subscriber uses an etag mechanism similar to HTTP's, which could be easily retrofitted onto CoAP at a later date if people really want it). > I agree it would be nice to have this mention in the draft, including > the "surprise" that a non-subscription-related GET request can affect > a subscription. I will add this to coap-observe. Are you sure you want to treat a GET with no Subscription-Lifetime the same as a GET with a Subscription-Lifetime present but set to zero? As you mention, this can lead to the surprise you describe above. You can avoid this situation by treating a GET with no Subscription-Lifetime as incapable of affecting subscriptions. That's certainly what I would have expected. /a From klaus.hartke@googlemail.com Wed Nov 3 12:10:57 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EBE428C123 for ; Wed, 3 Nov 2010 12:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5y81duX8VN0W for ; Wed, 3 Nov 2010 12:10:55 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 4ECA03A6905 for ; Wed, 3 Nov 2010 12:10:46 -0700 (PDT) Received: by gwb15 with SMTP id 15so796761gwb.31 for ; Wed, 03 Nov 2010 12:10:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=amlKPRC0XtUSOxUZ9GcEf2KNBezTeIeJooU8CtLgFxg=; b=gQO7XdZjychxXmkqGbBxrIOlLowbIFvv3dAXSqdk/EiVATgx85XRbP0CIJSP/pl7EU RZR+k5rU74QteGpcfv+Y47LwiiXp6aFwPXVX09JucC+kZ6wB89IhE71/JAo1pX546IVV /yEpjRh8sMs0EgSCLeoTlRXlvVe7k4GnwiISo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=fWLA1npakF4eh4TnYrpJXXIKtix2bsx487apoNgMqtcpVVpmCVCZg2s/8GA74gZvEy ogHRzqGuGWVC383N0dH33D5Mq3xWG8zPuAMeVObRDuMMH4S2bQkyNtqoL6AFe6nzaqEi BriPfp6sV5IlZwaiJr8CCAhyaLrHbZsFoTZ9I= MIME-Version: 1.0 Received: by 10.204.55.208 with SMTP id v16mr5207706bkg.214.1288811452761; Wed, 03 Nov 2010 12:10:52 -0700 (PDT) Sender: klaus.hartke@googlemail.com Received: by 10.204.101.65 with HTTP; Wed, 3 Nov 2010 12:10:52 -0700 (PDT) In-Reply-To: <4CD19EF9.3050107@nostrum.com> References: <139C9A0D-6F59-4369-9B53-AD99804931B1@sensinode.com> <4CD17966.8020504@nostrum.com> <4CD19EF9.3050107@nostrum.com> Date: Wed, 3 Nov 2010 20:10:52 +0100 X-Google-Sender-Auth: F0L8Pd_uElbAkOSbgcO_kCrMQaE Message-ID: From: Klaus Hartke To: core Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [core] Subscription Refresh Correlation (was Re: Token length (was Re: Comments on draft-ietf-core-coap-03)) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 19:10:57 -0000 Adam Roach wrote: >> Refreshing a subscription with a duration of 0 seconds actually doesn't >> unsubscribe the client immediately. It sets the remaining lifetime of the >> subscription to 0 seconds, but also retrieves the current state of the >> resource (it's indistinguishable from a basic GET request). > > Right. We do the same thing in SIP (unless the subscriber uses an etag > mechanism similar to HTTP's, which could be easily retrofitted onto CoAP at > a later date if people really want it). I imagine caching to work as follows with coap-observe: C: GET coap://server/resource for 3600s S: 200 (Etag: 0x0dc2) "> I agree it would be nice to have this mention in the draft, including the >> "surprise" that a non-subscription-related GET request can affect a >> subscription. I will add this to coap-observe. > > Are you sure you want to treat a GET with no Subscription-Lifetime the same > as a GET with a Subscription-Lifetime present but set to zero? Why would a client want to GET the current state of a resource during the time it has a subscription to that resource? It already knows the current state. Klaus From adam@nostrum.com Wed Nov 3 13:16:04 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 015F43A69D0 for ; Wed, 3 Nov 2010 13:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id weZdtGLjjNxa for ; Wed, 3 Nov 2010 13:16:03 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 682193A6883 for ; Wed, 3 Nov 2010 13:16:02 -0700 (PDT) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id oA3KG6cW026856 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 3 Nov 2010 15:16:08 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4CD1C305.6030609@nostrum.com> Date: Wed, 03 Nov 2010 15:16:05 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Klaus Hartke References: <139C9A0D-6F59-4369-9B53-AD99804931B1@sensinode.com> <4CD17966.8020504@nostrum.com> <4CD19EF9.3050107@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: core Subject: Re: [core] Subscription Refresh Correlation (was Re: Token length (was Re: Comments on draft-ietf-core-coap-03)) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 20:16:04 -0000 On 11/3/10 2:10 PM, Klaus Hartke wrote: > Adam Roach wrote: >>> Refreshing a subscription with a duration of 0 seconds actually doesn't >>> unsubscribe the client immediately. It sets the remaining lifetime of the >>> subscription to 0 seconds, but also retrieves the current state of the >>> resource (it's indistinguishable from a basic GET request). >> Right. We do the same thing in SIP (unless the subscriber uses an etag >> mechanism similar to HTTP's, which could be easily retrofitted onto CoAP at >> a later date if people really want it). > I imagine caching to work as follows with coap-observe: > > C: GET coap://server/resource for 3600s > S: 200 (Etag: 0x0dc2) " S: 200 (Etag: 0x6fdb) " S: 200 (Etag: 0x29bc) " S: 200 (Etag: 0x7b39) " S: 200 (Etag: 0x2152) " C: GET coap://server/resource for 3600s (I have 0x2152, 0x7b39 and 0x29bc) > S: 200 (Etag: 0x37ba) " S: 304 (Etag: 0x7b39) > S: 200 (Etag: 0x5cb0) " S: 304 (Etag: 0x2152) > S: 304 (Etag: 0x7b39) > C: GET coap://server/resource for 3600s (I have 0x7b39, 0x2152 and 0x5cb0) > S: 304 (Etag: 0x5cb0) > S: 304 (Etag: 0x2152) > etc. > > That is, a client can cache one or more responses, indicate to the > server which responses it has cached, and gets notified to which > cached state the resource changed to. That seems somewhat ill defined. In your example, there is an implication that the client promises to keep the cached versions around until the next GET. For example: Consider a case in which I cache the last three resource representations I've received (as your client above seems to do), and send the etags for all three of them in a GET. The server then sends dozens of differing resource representations, followed by a 304 indicating one of the etags I sent with my GET. The client has long since discarded this old version in favor of the more recent documents. Is that valid? I guess the client can recover by sending a new GET without the offending etag, which should (?) result in an immediate 200 containing the actual resource state. Is that what you have in mind? An alternate approach would be including the etag in the ACKs (assuming the server responses are sent confirmable, which isn't always the case). >>> I agree it would be nice to have this mention in the draft, including the >>> "surprise" that a non-subscription-related GET request can affect a >>> subscription. I will add this to coap-observe. >> Are you sure you want to treat a GET with no Subscription-Lifetime the same >> as a GET with a Subscription-Lifetime present but set to zero? > Why would a client want to GET the current state of a resource during > the time it has a subscription to that resource? It already knows the > current state. It might, or it might not; section 2.2: "It is not necessary that... the server sends a notification response for every single state change." If the client has a good reason to make sure it has the current state (instead of something approximating the current state), it needs some way of being able to do that. /a From adam@nostrum.com Wed Nov 3 13:28:19 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E44F528C0F5 for ; Wed, 3 Nov 2010 13:28:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31lC673OfWV6 for ; Wed, 3 Nov 2010 13:28:19 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id D7C1C28C0EE for ; Wed, 3 Nov 2010 13:28:18 -0700 (PDT) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id oA3KSPtM027950 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 3 Nov 2010 15:28:25 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4CD1C5E9.6070108@nostrum.com> Date: Wed, 03 Nov 2010 15:28:25 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Klaus Hartke References: <139C9A0D-6F59-4369-9B53-AD99804931B1@sensinode.com> <4CD17966.8020504@nostrum.com> <4CD19EF9.3050107@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: core Subject: [core] Multiple Etags in a Request (was: Subscription Refresh Correlation) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 20:28:20 -0000 On 11/3/10 2:10 PM, Klaus Hartke wrote: > That is, a client can cache one or more responses, indicate to the > server which responses it has cached, and gets notified to which > cached state the resource changed to. As an aside, I don't see anywhere in core-coap or core-observe that indicates that clients can include more than one Etag in a request. I agree it can be useful if specified the way you imply, but think you need to have some more explicit language in a document somewhere if you expect people to actually use Etags that way. /a From zach@sensinode.com Wed Nov 3 13:34:50 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA1343A69F2 for ; Wed, 3 Nov 2010 13:34:49 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yVWtth7kzxJP for ; Wed, 3 Nov 2010 13:34:48 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 8EB3928B797 for ; Wed, 3 Nov 2010 13:34:46 -0700 (PDT) Received: from [192.168.1.3] (line-5199.dyn.kponet.fi [85.29.66.162]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id oA3KYnJp009153 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 3 Nov 2010 22:34:50 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-272--875837247; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: <4CD1C5E9.6070108@nostrum.com> Date: Wed, 3 Nov 2010 22:34:51 +0200 Message-Id: References: <139C9A0D-6F59-4369-9B53-AD99804931B1@sensinode.com> <4CD17966.8020504@nostrum.com> <4CD19EF9.3050107@nostrum.com> <4CD1C5E9.6070108@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.1081) Cc: core , Klaus Hartke Subject: Re: [core] Multiple Etags in a Request (was: Subscription Refresh Correlation) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 20:34:50 -0000 --Apple-Mail-272--875837247 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 3, 2010, at 10:28 PM, Adam Roach wrote: > On 11/3/10 2:10 PM, Klaus Hartke wrote: >> That is, a client can cache one or more responses, indicate to the = server which responses it has cached, and gets notified to which cached = state the resource changed to. >=20 > As an aside, I don't see anywhere in core-coap or core-observe that = indicates that clients can include more than one Etag in a request. I = agree it can be useful if specified the way you imply, but think you = need to have some more explicit language in a document somewhere if you = expect people to actually use Etags that way. We discussed this earlier, but decided only to allow a single Etag in a = header for now. Although Klaus and Carsten are playing around with ideas = for multiple Etags, I would prefer that we take the approach of = completing coap-observe with a single Etag and then later explore more = advanced functionality. OK? Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 --Apple-Mail-272--875837247 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9 fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb 6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja 5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I 2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTEwMzIwMzQ1 MlowIwYJKoZIhvcNAQkEMRYEFH7qU7LIKZ0N0GJHg7t8JeTQo8IiMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAFRccSLSSEiPMEs1e389Uv8cQtGFFnDiUstJP0eUh/ptmTfacsZMaqE0 YQUPX5vr89fgMYzCk7HryVdoL1RPL4/p0GW5EVYSSY91Yw4KwjsBFXZaEvzLfxeH7mjXUzaeE+Au BVJg6EgRhSazJwMrWrJmMPGUNkKK5kzIS4YqiT0fDj2Ws37sP9BeJPLhThSwi0KayDLBp0jkdpyi 61MY/YsfBX5kL461zMoWrJGh2i0rayvXlZvQz3RyYP9J3YOyaC8DZhORGSWuZ1RQGTV1gg8w6Cqf 7hQaZFBGEbyDl8XTtiSW/9BQO8RSRmwEl9o41su6msN1reNaJab2Yad4ex4AAAAAAAA= --Apple-Mail-272--875837247-- From klaus.hartke@googlemail.com Wed Nov 3 14:07:53 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A93A28C0D7 for ; Wed, 3 Nov 2010 14:07:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XnDT6XMxRgkj for ; Wed, 3 Nov 2010 14:07:51 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 978AA28C0CF for ; Wed, 3 Nov 2010 14:07:51 -0700 (PDT) Received: by bwz12 with SMTP id 12so1008777bwz.31 for ; Wed, 03 Nov 2010 14:07:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; bh=IXddfNrbHlIsjIBtKCVXDgdjd86sVlYnUVw9jkmCau4=; b=PQ7nGrSMzuR8TVTxra8hwaKJxK41IL4hu/dw6RcBGCirrJIZYo70FWOQGfSXKGU0cn PGg+YtOYa3OFhN2KdIhZa8JB+rhOhntggAprzozxIDVmHkhUFyfbuEw71TCycMAwu6P5 8rnwUfEJBYAq5TbIBBQ8A9IhQMlpdxnp301Fg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=ZnsUAFko/83OyxnuVXzhUF6vbzn4yopJdTMeiPC3jXAvWq68545F+sdGbu1tQZDB0g HLnjmkptiIj2WKxkVvglKyibEHRE4RBXANvhGCs6M89XAaDW/NBK8qA1MGs3TIyKvdkr B26Wd7bXrteGVTp+QZP+6oSCYP9SMmxW4gFyM= MIME-Version: 1.0 Received: by 10.204.68.142 with SMTP id v14mr1185753bki.106.1288818478535; Wed, 03 Nov 2010 14:07:58 -0700 (PDT) Sender: klaus.hartke@googlemail.com Received: by 10.204.101.65 with HTTP; Wed, 3 Nov 2010 14:07:58 -0700 (PDT) In-Reply-To: References: <139C9A0D-6F59-4369-9B53-AD99804931B1@sensinode.com> <4CD17966.8020504@nostrum.com> <4CD19EF9.3050107@nostrum.com> <4CD1C5E9.6070108@nostrum.com> Date: Wed, 3 Nov 2010 22:07:58 +0100 X-Google-Sender-Auth: T88G5hwctvysVL1x_eL_U7RrX-k Message-ID: From: Klaus Hartke To: core Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [core] Multiple Etags in a Request (was: Subscription Refresh Correlation) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 21:07:53 -0000 Zach Shelby wrote: > We discussed this earlier, but decided only to allow a single Etag in a h= eader for now. Although Klaus and Carsten are playing around with ideas for= multiple Etags, I would prefer that we take the approach of completing coa= p-observe with a single Etag and then later explore more advanced functiona= lity. OK? coap-03 section 3.2.7 doesn't say that "This option MUST NOT occur more than once in a header." :-) But, yes, we can explore multiple Etags in a request later. (HTTP's If-None-Match header allows multiple entity tags.) Klaus From klaus.hartke@googlemail.com Wed Nov 3 14:09:42 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B06313A69FA for ; Wed, 3 Nov 2010 14:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SCWvCcxGSqxf for ; Wed, 3 Nov 2010 14:09:41 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 937733A66B4 for ; Wed, 3 Nov 2010 14:09:41 -0700 (PDT) Received: by bwz12 with SMTP id 12so1010406bwz.31 for ; Wed, 03 Nov 2010 14:09:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; bh=kFbaqh+YZbYTQhRTn09FRNkCZEJhVo2L0Vg3KMV5r+Q=; b=basPZWzHACNuQwt8vAxKRVKFgQMlxoelCNeVyPjfGtzk2UnahP1uu/Mbwew9anJ2NR RNWeaGo0lIIyIhDYrctC87U4pCVjF/mIJ1Zo9FviLR2IOtahiFAvRRxs9hLDAlCHFFHq PeWJ/3cZserbmzFRWNZpU73INs1NDnEqLYu6o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=W1l85Xv5pi+GwnCbpig1c+FmBcHOVLI1U8oZfDcl1Vs8Dl0gTqTxEb5mz4XTCuuqsq goubTKuWMDE6JOTYEy36mbPrB5XvREz33rAJMpYPAHyLCQE9oXvOIvatWHbocsULGTAf bXww1XyD52x6w2agjKbQrX2VbPQMtstN6dTmg= MIME-Version: 1.0 Received: by 10.204.55.208 with SMTP id v16mr5297307bkg.214.1288818588909; Wed, 03 Nov 2010 14:09:48 -0700 (PDT) Sender: klaus.hartke@googlemail.com Received: by 10.204.101.65 with HTTP; Wed, 3 Nov 2010 14:09:48 -0700 (PDT) In-Reply-To: <4CD1C305.6030609@nostrum.com> References: <139C9A0D-6F59-4369-9B53-AD99804931B1@sensinode.com> <4CD17966.8020504@nostrum.com> <4CD19EF9.3050107@nostrum.com> <4CD1C305.6030609@nostrum.com> Date: Wed, 3 Nov 2010 22:09:48 +0100 X-Google-Sender-Auth: HoRIR8Al-bFeYs9b0NsZV23N2EM Message-ID: From: Klaus Hartke To: core Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [core] Subscription Refresh Correlation (was Re: Token length (was Re: Comments on draft-ietf-core-coap-03)) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 21:09:42 -0000 Here's an updated example for caching in coap-observe with a single Etag: C: GET coap://server/resource for 3600s S: 200 (Etag: 0x0dc2) "> That is, a client can cache one or more responses, indicate to the >> server which responses it has cached, and gets notified to which >> cached state the resource changed to. > > That seems somewhat ill defined. In your example, there is an implication > that the client promises to keep the cached versions around until the nex= t > GET. Yes, that's what I have in mind. The client needs to keep the response it indicated to the server cached until the next subscription refresh. It can cache one or more additional responses. When it resubscribes, it discards all but one response, according to some caching strategy. It indicates to the server which response it kept, and keeps that response until the next refresh. > I guess the client can recover by sending a new GET without the offending > etag, which should (?) result in an immediate 200 containing the actual > resource state. Is that what you have in mind? No, I think it doesn't make sense to tell the server that a client has cached a specific state, and immediately retrieve that state when the resource changed to it. If a client doesn't want to keep around some old response, it can always resubscribe with another Etag or without any Etag. > An alternate approach would be including the etag in the ACKs (assuming t= he > server responses are sent confirmable, which isn't always the case). A server can't conclude from an ACK that the client has added a response to its cache. We could invent some protocol to keep the client's cache and what the server thinks is in the client's cache in sync, but I think we shouldn't go down this road. >> Why would a client want to GET the current state of a resource during >> the time it has a subscription to that resource? It already knows the >> current state. > > It might, or it might not; section 2.2: > > =A0"It is not necessary that... the server sends a notification > =A0 response for every single state change." > > If the client has a good reason to make sure it has the current state > (instead of something approximating the current state), it needs some way= of > being able to do that. If a client has a subscription and wants to make sure it has the current state, it can send a GET request. If it wants to continue the subscription, it includes a Subscription-Lifetime Option. If it doesn't want to continue the subscription, it omits it. I think there is no problem here. Klaus From zach@sensinode.com Wed Nov 3 14:26:20 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18FF93A6900 for ; Wed, 3 Nov 2010 14:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FVBEz8rNT6Qu for ; Wed, 3 Nov 2010 14:26:19 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 6A04B3A66B4 for ; Wed, 3 Nov 2010 14:26:17 -0700 (PDT) Received: from [192.168.1.3] (line-5199.dyn.kponet.fi [85.29.66.162]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id oA3LQKcB010670 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 3 Nov 2010 23:26:21 +0200 From: Zach Shelby Content-Type: multipart/signed; boundary=Apple-Mail-283--872745810; protocol="application/pkcs7-signature"; micalg=sha1 Date: Wed, 3 Nov 2010 23:26:22 +0200 Message-Id: To: core Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [core] coap-03 server, directory and proxy up X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 21:26:20 -0000 --Apple-Mail-283--872745810 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Szymon and I have now put up a full coap-03 test server along with an = updated HTTP proxy and directory. IPv4 only right now, likely will have = an IPv6 tunnel up by the plugfest. http://trac.tools.ietf.org/wg/core/trac/wiki/PlugFest=20 The server is running at coap://184.106.150.250:61618 The HTTP-CoAP proxy is running at http://184.106.150.250/coap An example of requesting a CoAP resource via the proxy is = http://184.106.150.250/coap/[::1]:61618/time/china The directory REST interface is still evolving some before Sunday, but = we will keep the wiki updated. We encourage everyone to register your = own coap server with the directory (just POST your link-format to it = with coap, and POST/PUT again before max-age runs out). This makes it = easy to see in real-time which servers are up, and you can easily browse = the links from HTTP as well. We look forward to feedback and new feature = ideas. You can browse the directory at: http://184.106.150.250 Zach & Szymon --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 --Apple-Mail-283--872745810 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9 fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb 6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja 5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I 2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTEwMzIxMjYy M1owIwYJKoZIhvcNAQkEMRYEFLqCB9CE7piv4jieJzkfp8a8mnQCMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBABzYFl/MWUwmXliYciUgb69L0TISzGx7z3Joq7RTKrZ2M6/HQt+QSCJd +0GgsYmga3detGcm2OAMNdRhLkWXL0QOIBefzdcbjW11dyo4VRiK5vck0I/qGzmpw3oVtR85EC2y ShYEX026+1XL3HpkgDAZerF0A8AO9mA7UN9w+vsYXSxWombJYH1pNDm9+ETChposLMiOUNP6i5KG Xji1BwnbmhT/8e5pd4XNEYRw2O4dN0OGRYsEmF4iYTqoX24W/OV2El0wvPTD/lE3493b6rKuiecY mZSSknCQlzZXPDy2P++CLfDoNo2wqTm+ZWslkokpukVs4x3xdZHtZbQ0pYkAAAAAAAA= --Apple-Mail-283--872745810-- From adam@nostrum.com Wed Nov 3 14:37:57 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C19453A690A for ; Wed, 3 Nov 2010 14:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CqbJoxJq45nX for ; Wed, 3 Nov 2010 14:37:04 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 811BF3A69F2 for ; Wed, 3 Nov 2010 14:36:54 -0700 (PDT) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id oA3Lb00K034137 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 3 Nov 2010 16:37:01 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4CD1D5FC.6040909@nostrum.com> Date: Wed, 03 Nov 2010 16:37:00 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Klaus Hartke References: <139C9A0D-6F59-4369-9B53-AD99804931B1@sensinode.com> <4CD17966.8020504@nostrum.com> <4CD19EF9.3050107@nostrum.com> <4CD1C305.6030609@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: core Subject: Re: [core] Subscription Refresh Correlation (was Re: Token length (was Re: Comments on draft-ietf-core-coap-03)) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 21:38:03 -0000 On 11/3/10 4:09 PM, Klaus Hartke wrote: > If a client has a subscription and wants to make sure it has the > current state, it can send a GET request. If it wants to continue the > subscription, it includes a Subscription-Lifetime Option. If it > doesn't want to continue the subscription, it omits it. I think there > is no problem here. You used the term "surprise" to describe this situation, and I've found "surprise" to generally be a bad property in a protocol. My experience is that surprising aspects of protocols are where implementors tend to make invalid assumptions and write code that doesn't quite interoperate. So I agree with you: what you propose is surprising. I also agree with you that it works. There's another option that works without any surprises. I have a natural bias towards this other approach because of the value I place on interoperability. You don't seem to like this second approach, but have not yet explained why. /a From zach@sensinode.com Wed Nov 3 14:49:44 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFB893A68E8 for ; Wed, 3 Nov 2010 14:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id halVv1HzCTnV for ; Wed, 3 Nov 2010 14:49:43 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 1627D3A68C0 for ; Wed, 3 Nov 2010 14:49:42 -0700 (PDT) Received: from [192.168.1.3] (line-5199.dyn.kponet.fi [85.29.66.162]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id oA3Lnjg0011282 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 3 Nov 2010 23:49:46 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-285--871341161; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: <4CD1D5FC.6040909@nostrum.com> Date: Wed, 3 Nov 2010 23:49:47 +0200 Message-Id: References: <139C9A0D-6F59-4369-9B53-AD99804931B1@sensinode.com> <4CD17966.8020504@nostrum.com> <4CD19EF9.3050107@nostrum.com> <4CD1C305.6030609@nostrum.com> <4CD1D5FC.6040909@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.1081) Cc: core , Klaus Hartke Subject: Re: [core] Subscription Refresh Correlation (was Re: Token length (was Re: Comments on draft-ietf-core-coap-03)) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 21:49:45 -0000 --Apple-Mail-285--871341161 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 3, 2010, at 11:37 PM, Adam Roach wrote: > On 11/3/10 4:09 PM, Klaus Hartke wrote: >> If a client has a subscription and wants to make sure it has the = current state, it can send a GET request. If it wants to continue the = subscription, it includes a Subscription-Lifetime Option. If it doesn't = want to continue the subscription, it omits it. I think there is no = problem here. >=20 > You used the term "surprise" to describe this situation, and I've = found "surprise" to generally be a bad property in a protocol. My = experience is that surprising aspects of protocols are where = implementors tend to make invalid assumptions and write code that = doesn't quite interoperate. >=20 > So I agree with you: what you propose is surprising. I also agree with = you that it works. There's another option that works without any = surprises. I have a natural bias towards this other approach because of = the value I place on interoperability. You don't seem to like this = second approach, but have not yet explained why Adam has a valid point here, I also think we should not remove the = subscription due to a normal GET. This is the most logical behavior and = doesn't hurt anything. I propose we make a ticket on this. Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 --Apple-Mail-285--871341161 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9 fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb 6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja 5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I 2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTEwMzIxNDk0 OFowIwYJKoZIhvcNAQkEMRYEFNKsMf1MLZpl0EKQXUVgHTQiIG73MIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAC05HggybyPXJ4sxdgBZE0PUN1AtpHXKwGzhn01pTvo35oTmqdMrl/Yq GcbaqdnRfm4+XbDomZsWEx0pQu2MXGhkAyyBfS7KlNUg/iIT7oNXI5Ib5JV+kYHZpBvVbqkxj0xB oZ6GaG0JoRrnuXpouHviLuNX1CUK4Kn/e5nN+SgCs9tmJ7p5TfMMdj1IZK4nEh1+UvGGh8Uq/1jd o4rN22/FrAIVAJyyebsdPbskoH7M00ykB7Jt/CiXwk+2wcwjoFyCr6f30xOH1hoqBlfigliHDjWt eytb/WA+F/qGLchmHs8gdv48raoKqLegBjukzH4atXKdiMwkW4FOjiHux48AAAAAAAA= --Apple-Mail-285--871341161-- From zach@sensinode.com Wed Nov 3 15:01:25 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A119A3A69FA for ; Wed, 3 Nov 2010 15:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NjBoUIJl1+OE for ; Wed, 3 Nov 2010 15:01:24 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id EDF253A69F2 for ; Wed, 3 Nov 2010 15:01:23 -0700 (PDT) Received: from [192.168.1.3] (line-5199.dyn.kponet.fi [85.29.66.162]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id oA3M1QCo011529 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 4 Nov 2010 00:01:27 +0200 From: Zach Shelby Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-286--870639717; protocol="application/pkcs7-signature"; micalg=sha1 Date: Thu, 4 Nov 2010 00:01:29 +0200 In-Reply-To: To: core References: Message-Id: X-Mailer: Apple Mail (2.1081) Subject: Re: [core] coap-03 server, directory and proxy up X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 22:01:25 -0000 --Apple-Mail-286--870639717 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Also now available via IPv6 at core-plugfest.broker.freenet6.net On Nov 3, 2010, at 11:26 PM, Zach Shelby wrote: > Hi, >=20 > Szymon and I have now put up a full coap-03 test server along with an = updated HTTP proxy and directory. IPv4 only right now, likely will have = an IPv6 tunnel up by the plugfest. >=20 > http://trac.tools.ietf.org/wg/core/trac/wiki/PlugFest=20 >=20 > The server is running at coap://184.106.150.250:61618 >=20 > The HTTP-CoAP proxy is running at http://184.106.150.250/coap >=20 > An example of requesting a CoAP resource via the proxy is = http://184.106.150.250/coap/[::1]:61618/time/china >=20 > The directory REST interface is still evolving some before Sunday, but = we will keep the wiki updated. We encourage everyone to register your = own coap server with the directory (just POST your link-format to it = with coap, and POST/PUT again before max-age runs out). This makes it = easy to see in real-time which servers are up, and you can easily browse = the links from HTTP as well. We look forward to feedback and new feature = ideas. You can browse the directory at: >=20 > http://184.106.150.250 >=20 > Zach & Szymon >=20 > --=20 > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 --Apple-Mail-286--870639717 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9 fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb 6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja 5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I 2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTEwMzIyMDEy OVowIwYJKoZIhvcNAQkEMRYEFEOOU8n+llYU/viKxhYFFajhP2YkMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAKYvxVMkLh7sYuRAyDNhLPBqg7yZlFN8zIRR49a2v4tMkmX5k07p0mqH w3WZO6Obyad6Tt9kfoZ825pMKQ/yVhBNgjRmhZsMSENq8QECs1SA2vZ17LMkHNxaHqydLmxdueQB iUC7L1ncozNQCPLtb+xWQBtlcZKVb4w0r6m0C6RcXCf0TcOPU+Uh6pVYdlEnTsHwe1E2CGUbkEnk 3KV/HaGNzjEW0nRMtpQzeM2tN2ClBrcUf66m2G6qq7s0kA5HFD5/PHLlCebofhhNZOjU6bHudasd JhO7gsI5dp1G44H5ouQiemjeKA1G3MHtllnpjESQITs13wAijL9qSohXXAgAAAAAAAA= --Apple-Mail-286--870639717-- From nkong@cnnic.cn Thu Nov 4 02:35:49 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46B823A69F0 for ; Thu, 4 Nov 2010 02:35:18 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 0.805 X-Spam-Level: X-Spam-Status: No, score=0.805 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yyNfpbPDNtLd for ; Thu, 4 Nov 2010 02:34:51 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by core3.amsl.com (Postfix) with SMTP id 529BA3A69D1 for ; Thu, 4 Nov 2010 02:34:12 -0700 (PDT) Received: (eyou send program); Thu, 04 Nov 2010 17:34:05 +0800 Message-ID: <488863245.25157@cnnic.cn> X-EYOUMAIL-SMTPAUTH: nkong@cnnic.cn Received: from unknown (HELO naptrthink) (127.0.0.1) by 127.0.0.1 with SMTP; Thu, 04 Nov 2010 17:34:05 +0800 Message-ID: <14CA16B400A94293BA6CD2C5FD48D2D4@NAPTRTHINK> From: "Ning Kong" To: Date: Thu, 4 Nov 2010 17:33:55 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0141_01CB7C46.7490E940" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3502.922 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3502.922 Cc: Gyu Myoung Lee , Bruce Nordman Subject: [core] Doodle: Discussion of the PS draft and Charter for IoT RG in Beijing X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 09:35:50 -0000 ÕâÊÇÒ»·â MIME ¸ñʽµÄ¶à·½Óʼþ¡£ ------=_NextPart_000_0141_01CB7C46.7490E940 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable ? Hi folks,=20 Sorry for cross-posting! There have been two bar BoF meetings for IoT (Internet of Things) at = IETF 77 and IETF 78. Gyu Myoung, Bruce and I would like to arrange an = informal meeting to discuss the PS draft = (draft-lee-iot-problem-statement-00) and Charter (coming soon) for IoT = RG at IETF 79. We cordially invite you to join us. In case you would like to attend this meeting, please indicate your = availabilities by 7 November 2010, on Doodle: = http://doodle.com/4t7phhfeqc9a5duh=20 We will decide whether this meeting should be announced as a bar BoF at = IETF 79 based on the result of the Doodle.=20 If you have any problem or suggestions, please feel free to let me know. = Cheers,=20 Ning=20 ------=_NextPart_000_0141_01CB7C46.7490E940 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

     

    Hi folks,

     
    Sorry for = cross-posting!
     
    There have been two bar = BoF meetings=20 for IoT (Internet of Things) at IETF 77 and IETF 78. Gyu Myoung, Bruce = and I=20 would like to arrange an informal meeting to discuss the PS draft=20 (draft-lee-iot-problem-statement-00) and Charter (coming soon) for IoT = RG at=20 IETF 79. We cordially invite you to join us.
     
    In case you would like = to attend this=20 meeting, please indicate your availabilities by 7 November 2010, on = Doodle:=20 http://doodle.com/4t7phhfeqc9a5duh
    We will decide whether = this meeting=20 should be announced as a bar BoF at IETF 79 based on the result of the = Doodle.=20
     
    If you have any problem = or=20 suggestions, please feel free to let me know.
     
     
    Cheers,
    Ning

    ------=_NextPart_000_0141_01CB7C46.7490E940-- From prvs=1924DA8252=guido.moritz@uni-rostock.de Thu Nov 4 05:56:00 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D2F33A69EB for ; Thu, 4 Nov 2010 05:56:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.049 X-Spam-Level: X-Spam-Status: No, score=-1.049 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, HELO_EQ_DE=0.35, J_CHICKENPOX_24=0.6, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SLAsF4clgrB2 for ; Thu, 4 Nov 2010 05:55:58 -0700 (PDT) Received: from mailrelay1.uni-rostock.de (mailrelay1.uni-rostock.de [139.30.8.201]) by core3.amsl.com (Postfix) with ESMTP id 3CD823A69FD for ; Thu, 4 Nov 2010 05:55:57 -0700 (PDT) From: Guido Moritz To: 'core' References: <139C9A0D-6F59-4369-9B53-AD99804931B1@sensinode.com> <4CD17966.8020504@nostrum.com> In-Reply-To: Date: Thu, 4 Nov 2010 13:56:08 +0100 Message-ID: <006401cb7c1f$a665c930$f3315b90$@uni-rostock.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQCxDlxUBgWiaigUMqD745tQ263MJwLgBgExAkXFvbsC60S20wHIvWntAZBhUheVOsuKIA== Content-Language: de Subject: Re: [core] Subscription Refresh Correlation (was Re: Token length (was Re: Comments on draft-ietf-core-coap-03)) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 12:56:00 -0000 Sorry for being maybe a bit too late to this discussion, but I am a bit confused about correlation of subscriptions, notifications and = subscription refresh. First of all I would like to express that I would say using the Token = Option is a bit misleading because Tokens are to identify the transaction and = each single subscription, notification and subscription refresh is a single transaction for itself which might be CON or NON. Let's say a = subscription causes a notification each 25 days. So as a client I would appreciate if = the server can ACK my subscription to be sure I will get the notification. Using the URI of the subscription would probably result in long URIs (especially due to the long queries for filtering). So I would propose to use a single EventID for the subscription. The = EventID can be very compact because it identifies the subscription together with IP+Port of client (which must be stored anyway) and there might be not = many subscriptions to distinguish from. In case of a CON subscription the = server includes the EventID together with the Token (and without the URI) in = the subscription ACK. If the subscription is NON, the server may include the EventID in the first notification and only in this first notification = also the URI. For each subsequent notification or refresh of the subscription = the EventID is included (without any URI). The URI is known by both = endpoints and not needs to be transmitted unless a change is required by the = client. The URI also must not be stored on both sides, only the "application = logic" behind the URI and the query. Thus the transaction layer and the = application logic behind the subscription are decoupled more logical. The nice thing about this subscription identification is that even no URI+query must be included for subscription refreshing, only the new subscription time and the EventID. BTW: Including such an EventID is the way how WS-Eventing avoids = including complex filtering/query information which both endpoints already know in each message and it works nice even in only slightly complex queries.=20 Guido > -----Urspr=FCngliche Nachricht----- > Von: core-bounces@ietf.org [mailto:core-bounces@ietf.org] Im Auftrag = von > Klaus Hartke > Gesendet: Mittwoch, 3. November 2010 17:57 > An: core > Betreff: Re: [core] Subscription Refresh Correlation (was Re: Token = length > (was Re: Comments on draft-ietf-core-coap-03)) >=20 > Adam Roach wrote: > > I've been trying to figure out how subscription correlation (for the purpose > > of refreshing subscriptions) would work without tokens. In fact, > > coap-observe is a bit under-specified regarding matching = subscription > > refreshes to the original subscription. > > > > Clearly, when a client provides a token, the server should be able = to > > recognize refreshes as being (a) to the same resource, (b) from the = same > > client (IP and port), and (c) with the same token. > > > > Do we want to make it so that a subscription without a token would simply > be > > correlated by being (a) to the same resource and (b) from the same client? >=20 > It is the intention that a subscription is identified by (a) the URI > of the resource (including Uri-Query) and (b) the identity of the > client (IP and port). A client may or may not reuse the same token > when refreshing a subscription. I will clarify this in coap-observe. >=20 > > On a slightly related note, there should probably be a sentence or = two in > > coap-observe that talks about how clients unsubscribe from a = resource. > Once > > we have an explicit subscription correlation model, all the = mechanisms are > > actually in place: refreshing a subscription with a duration of "0" would > > cause the subscription to immediately expire (this is a natural = property of > > the current design). It would be nice if the draft pointed this out. >=20 > Refreshing a subscription with a duration of 0 seconds actually > doesn't unsubscribe the client immediately. It sets the remaining > lifetime of the subscription to 0 seconds, but also retrieves the > current state of the resource (it's indistinguishable from a basic GET > request). I agree it would be nice to have this mention in the draft, > including the "surprise" that a non-subscription-related GET request > can affect a subscription. I will add this to coap-observe. >=20 >=20 > Klaus > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From cabo@tzi.org Thu Nov 4 06:47:14 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 449553A688D for ; Thu, 4 Nov 2010 06:47:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTEmlNdPQHLm for ; Thu, 4 Nov 2010 06:47:13 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 1A65B3A68B5 for ; Thu, 4 Nov 2010 06:47: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 oA4DlENN004506 for ; Thu, 4 Nov 2010 14:47:15 +0100 (CET) Received: from [10.40.73.68] (unknown [222.128.202.2]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id B03D623; Thu, 4 Nov 2010 14:47:13 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <006401cb7c1f$a665c930$f3315b90$@uni-rostock.de> Date: Thu, 4 Nov 2010 21:47:09 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <139C9A0D-6F59-4369-9B53-AD99804931B1@sensinode.com> <4CD17966.8020504@nostrum.com> <006401cb7c1f$a665c930$f3315b90$@uni-rostock.de> To: core X-Mailer: Apple Mail (2.1081) Subject: Re: [core] Subscription Refresh Correlation (was Re: Token length (was Re: Comments on draft-ietf-core-coap-03)) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 13:47:14 -0000 As a general observation, the DNS protocol (RFC 1035), which is trying = to work in the constrained space of 512-byte UDP packets, went very well = with repeating the request parameters in every response. It might be = worthwhile to have a look why that was done and what advantages it has = up to today. Gruesse, Carsten From rene.hummen@informatik.rwth-aachen.de Fri Nov 5 07:42:19 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E6AD3A66B4 for ; Fri, 5 Nov 2010 07:42:19 -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=[AWL=1.300, BAYES_00=-2.599, GB_SUMOF=5, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, J_CHICKENPOX_31=0.6, J_CHICKENPOX_41=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tRmupsyBLc7g for ; Fri, 5 Nov 2010 07:42:16 -0700 (PDT) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id 1BA613A67A3 for ; Fri, 5 Nov 2010 07:42:15 -0700 (PDT) MIME-version: 1.0 Received: from ironport-out-2.rz.rwth-aachen.de ([134.130.5.41]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LBF00HMK26RTFE0@mta-1.ms.rz.RWTH-Aachen.de> for core@ietf.org; Fri, 05 Nov 2010 15:42:27 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.58,303,1286143200"; d="p7s'?scan'208";a="42602362" Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by ironport-in-2.rz.rwth-aachen.de with ESMTP; Fri, 05 Nov 2010 15:42:28 +0100 Received: from umic-i4-137-226-45-95.nn.rwth-aachen.de ([unknown] [137.226.45.95]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0LBF002VH26R3F20@relay-auth-1.ms.rz.rwth-aachen.de> for core@ietf.org; Fri, 05 Nov 2010 15:42:27 +0100 (CET) From: =?iso-8859-1?Q?Ren=E9_Hummen?= Content-type: multipart/signed; boundary=Apple-Mail-20--724181842; protocol="application/pkcs7-signature"; micalg=sha1 Date: Fri, 05 Nov 2010 15:42:26 +0100 Message-id: <6194C0CE-81B9-4D81-B15D-EB25763D72CF@cs.rwth-aachen.de> To: Rene Struik X-Mailer: Apple Mail (2.1081) Cc: core Subject: Re: [core] HIP identities and puzzle X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 14:42:19 -0000 --Apple-Mail-20--724181842 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Rene, On 02.11.2010, at 20:56, Rene Struik wrote: > Hi fellow-Rene: we don't get the opportunity to say something like that too often :-) > Quick questions re your description of the protocol: > 1) With HIP, why does the responder sign two messages, rather than = one. According to Tobias Heer's email (October 29, 2010, 11:14pm EDT), = the first of these is offline and the second is online. Question, = however, is what the benefit is. After all, offline signatures do not = prove the responder's active participation with the protocol, so any = party could just replay an offline signature. You are of course right when saying that offline signatures do not prove = the responder's active participation in the current handshake. Still, = the offline signature binds the responder's DH key in the R1 to its = identity. The freshness of the handshake is established through the HMAC = in the R2 packet, for which the key was derived from the DH keys. The PK = signature in R1 also ensures that parameters such as the PUZZLE (with a = given difficulty) and the DH_GROUP_LIST have originally been sent by the = responder. Otherwise, HIP would be open to new DoS and downgrade = attacks. The online signature in R2 is required to enable forwarding entities to = check the successful conclusion of the handshake as part of HIP's = middlebox-friendly design. Please note that the signature might also = have another use that I am currently unaware of. One of the original HIP = authors might know more about it.=20 > 2) With HIP, the protocol flows imply that initiator and responder = have to perform their computations consecutively (since key confirmation = and ephemeral contributions are combined with one protocol flow). This = seems inefficient: one would be much better off designing the protocol = so as to allow parallelization of computationally expensive steps of the = protocol. HIP actually allows a receiver to pre-create R1 packets. This = pre-creation includes the generation of the DH key pair and the PK = signature over the R1 packet by excluding certain parameters in the = HIP_SIGNATURE_2 [1] parameter. Furthermore, HIP allows an initiator to = pre-create a DH key pair before the handshake and to use it during the = creation of an I2. The remaining computations need to be performed consecutively, as they = show interdependencies with previous packets of the handshake: I2.1) The generation of the DH KEYMAT is required for the I2 in order = for the initiator to prove (by means of an HMAC) that he computed the = correct symmetric key. The DH KEYMAT generation depends on information = from R1 (i.e. the responder's DH public key). I2.2) The PK signature in I2 needs to cover the initiator's public DH = key and the puzzle solution (DoS protection mechanism) to authenticate = the DH key and to prove that the initiator actively takes part in the = exchange. The puzzle solution depends on the challenge in R1. R2.1) The same line of argumentation as for (I2.1) is true for R2 with a = dependency on the DH key in I2. R2.2) The PK signature in the R2 could potentially already be = pre-computed after receiving I1. Note, however, that the I1 is not = protected cryptographically and might be spoofed. > 3) With HIP, it is unclear what features make it more attractive than, = e.g., "ECDH with signed exponents". After all, it does not seem to offer = any computational benefits over the latter. Same remark, but now in = comparison to (H)MQV: doesn't that alternative provide far better = performance? HIP not only provides an authenticated key exchange, but aims at solving = a more fundamental problem: the dual role of IP addresses. By = implementing the id/locator split, it enables, e.g., host mobility and = multi-homing transparently for the transport layer and above. However, = in my opinion, an aspect of HIP that might be very interesting for CoRE = on the conceptual level is flexible packet structure of HIP. It provides = a very flexible and authenticated signaling channel that allows to = convey tailored information based on the requirements of specific = scenarios. Getting back to your question, HIP differs from pure key exchange = protocols by providing a signaling channel and by defining replay and = DoS protection mechanisms. =46rom my point of view, it might still be = interesting to see how MQV schemes could be integrate in HIP in order to = further improve its efficiency. > 4) With HIP, how does one party obtain the public signature = verification key of the other party? (with the protocol flows shown, = this is not communicated along the way). As stated in my previous email, ID_x, where x in {I, R}, is the public = key of the initiator and responder respectively. > 5) With DEX, one seems to use static (i.e., non-ephemeral) = contributions by either party (which seem then to be equated with = identifiers of either party). If so, the DH scheme comes down to = Static-(EC)DH. Does this imply that these static keys are cast in stone, = i.e., never change over the lifetime of the device in which they are = embedded? Or, is change hereto possible under certain circumstances? =46rom a protocol perspective, the DH key could be changed between any = two connections. However, changing the DH key implies changing a = device's identity. This might not be what one expects in all scenarios. = I'm currently working on a draft about a certificate-based namespace = that will allow changing the cryptographic identities while keeping a = stable device identifier, so that the DH keys can be changed without = changing the identifier of a host. > 6) With DEX, if one uses static-DH, why not simply cash the DH key and = use a symmetric-key only protocol instead? Static DH allows to dynamically set up pair-wise encrypted channels in a = memory efficient way, as each device only needs to store it's own DH key = pair. With symmetric keys you would need to store a shared key with each = device in the network in order to achieve pair-wise encrypted channels. = Of course a choice between both approaches involves a trade-off in space = vs. computational complexity. Still, it might be beneficial to add a = resume mechanism to DEX in order to refer to previously generated keying = material. Such a mechanism could easily be incorpoarated in to the HIP = signaling channel. > 7) With DEX, it is unclear why one would have ECR, DCR relate to CMAC. = Your description suggests that ECR should use AES, but in which mode of = operation? At first sight, one should be able to combine ECR and CMAC = into one cryptographic AEAD transformation, so question is why this is = not considered here. In the current version of the DEX draft, it is assumed that AES-CBC is = used for symmetric encryption and CMAC for MACing functions. It might be = well worth looking, e.g., into AES CCM* as it is one of the supported = modes in 802.15.4. > 8) With DEX, couldn't one simplify the protocol flows by including a = random value S_R already in the first message pass from responder to = initiator ("R1") and computing the pair-wise key from S_R and SI on the = initiator's side earlier on? When sending S_R already in R1, the random value would not be encrypted = and therefore be visible to a malicious node. Still, I don't see a = problem with that right away given that S_I provides "sufficient" = randomness and is well protected. The initiator could start generating = the pair-wise key for the payload protocol early on. Note, however, that = the responder is only authenticated after successful validation of R2 = and, thus, the initiator would not want to use the pair-wise key before. Let me know, in case I left one of your questions unanswered. BR, Ren=E9 [1] = http://tools.ietf.org/html/draft-ietf-hip-rfc5201-bis-03#section-5.2.14=20= > Just a few questions that came up when studying your protocol flows (I = did not review the RFCs you referred to for now). >=20 > Best regards, Rene >=20 >=20 > On 02/11/2010 2:16 PM, Ren=E9 Hummen wrote: >> Hello Rene, >>=20 >> please see my comments below. >>=20 >>=20 >> On 29.10.2010, at 17:14, Tobias Heer wrote: >>> Hello Rene, >>>=20 >>> thanks for picking this up again. >>>=20 >>> First, one has to distinguish HIP and DEX (as proposed by Robert). = HIP is (as defined in 5201) the base protocol and DEX would be the = trimmed down variant for resource constrained scenarios. However, the = DEX is certainly still WIP and can probably be bent in one or the other = direction (if needed). I am not an author of the DEX and I somehow ended = up mandating HIP here although CoRE is certainly not my primary field of = work. Hence, I'd like to state that my intention is not to claim that = HIP is the best protocol for CoRE. I simply don't know CoRE well enough = to make such statement. However, I can try to answer some questions = related to HIP so that CoRE WG can make a sound decision on whether HIP = is something to consider or if it isn't. >>>=20 >>> Am 29.10.2010 um 15:02 schrieb Rene Struik: >>>=20 >>>> Hi Tobias: >>>>=20 >>>> It would help to have some more insight into claimed functionality = of the HIP protocol. We had some correspondence on this over the last 4 = weeks, but unfortunately detail as to claimed security properties, >>> I) Which specific security properties are unclear to you? Maybe we = can narrow things down a bit. Otherwise I might end up repeating the = whole protocol as described in RFC5201 here. >>>=20 >>>> distinguishing features w.r.t. other protocols, >>> II) Distinguishing features of HIP are (in my opinion): >>>=20 >>> On a conceptual level: >>> a) the implementation of the locator/identifier split, >>>=20 >>> b) the quite flexible protocol design (emphasis on extendability - = many people have successfully used HIP for quite different scenarios by = extending and modifying the base protocol without breaking = compatibility), >>>=20 >>> c) the identity-focused namespace based on cryptographic identities, >>>=20 >>> d) its integration within the stack. Upper layers just use HITs like = IPv6 addresses and HIP takes care of establishing and maintaining an = authenticated and encrypted channel to the other host. >>>=20 >>>=20 >>> Features on a more technical level are: >>> e) A 4-way handshake that includes authentication of both peers, = generation of a shared secret and set-up of an encrypted payload = channel. Depending on the scenario, this four-way handshake might be = better than, e.g., the multi-packet flight-based exchange of DTLS that = sends more packets. However, I am aware that HIP needs optimizations in = the form of DEX to avoid fragmentation and DTLS could probably be = modified to avoid multi-packet flights. >>>=20 >>> f) DoS prevention: HIP implements two different mechanisms here: = return routability checks and puzzles. However, depending on the = scenario, these may be applicable or may be not applicable for CoRE. I'd = be happy to discuss this. >>>=20 >>> All aforementioned points (a-f) are valid for HIP and DEX. >>> I will gladly give a more detailed explanation of these points if = you wish - just tell me which requires further elaboration. >>>=20 >>>> computational benefits over other approaches >>>=20 >>> HIP uses an authenticated Diffie Hellman key exchange. In terms of = public key operations, it does: >>>=20 >>> 2 public key verifications at the Initiator side >>> 1 public key verification at the Responder side >>> 1 public key signature at the Initiator side >>> 1 public key signature at the Responder side >>> 1 offline public key signature at the Responder side >>> 1 DH shared key generation at the Initiator side >>> 1 DH shared key generation at the Responder side >>>=20 >>> This is certainly not an optimal design for tightly resource = constrained devices. Hence, Robert tried to reduce the number of = computations needed without changing the way HIP works. >>> DEX (as proposed by Robert) uses a static Diffie Hellman key = exchange and amounts to: >>>=20 >>> 1 DH shared key generation at the Initiator side >>> 1 DH shared key generation at the Responder side >>>=20 >>> The actual cost of these operations depends on the chosen DH groups/ = ECC curves but the set algorithms is interchangeable and can be adopted = to the needs of the scenario. >>>=20 >>> The aforementioned numbers don't reflect the cost of the use of an = additional third-party certificate (which I believe you would like to = see in a handshake). Hence, certificate verification at the sender or = receiver should be added to the cost if the scenario demands it. >>>=20 >>> I hope this gives you a rough feeling for the cryptographic cost of = running HIP/DEX. >>>=20 >>>> Moreover, I still have trouble to understand how the protocol could = facilitate separation of device ids and cryptographic objects, as seems = to be beneficial in deployment scenarios, such as large scale = manufacturing of sensor nodes. >>> Ren=E9 Hummen is currently preparing a draft on the solution that I = mentioned in my previous mail. I hope he is done before or shortly after = Beijing. I hope this document will answer your questions. >> As Tobias mentioned, I'm currently working on a draft about a = certificate-based namespace for HIP. However, as I just started it = recently, it might well take until after Beijing. >>=20 >>>> If you could elaborate and put the issues to rest, that would be = great. >>>>=20 >>> Sure. I hope the explanations above shed some light on the open = questions regarding HIP. I tried to put each argument/point to a new = line to make it easy for you to indicate which you would like to discuss = in more detail. >>>=20 >>>> For the benefit of easy comprehension, I would suggest a succinct = description (perhaps, with mathematical description of security-relevant = portions of the protocol flows, properties, etc?). >>>>=20 >>> I believe Rene Hummen is preparing this, too. I hope the sum of the = cryptographic operations is enough for now to develop a feeling for the = cost. >> I'm not an author of the DEX draft myself, but I already discussed = with Robert about the protocol and I'm very interested in the topic. = That said, these are my thoughts and findings on HIP and DEX. >>=20 >> HIP and DEX both have - as Tobias pointed out before - a 4 way = handshake. The initial packet (I1) triggers the handshake and does not = contain any cryptographic mechanisms. I'll now go through the packet = exchange of both protocols focusing on the remaining packets R1, I2 and = R2 and describe the respective cryptographic portions. Note that Rx = (i.e. R1 and R2) denotes a packet sent by the responder, whereas Ix = (i.e. I1 and I2) represents a packet sent by the initiator. >>=20 >> HIP: >> ------ >>=20 >> Initiator = Responder >>=20 >> I1 >> ------------------------------------> >>=20 >> = Create eph. DH key pair: x, g^x >>=20 >> R1: ID_R, g^x, SIGN(ID_R, R1) >> <------------------------------------ >>=20 >> VER_SIG(ID_R, R1) >> Create eph. DH key pair: y, g^y >> DH KEYMAT: Derived using HKDF* on g^{xy}, salt and peer info as input >> Derive shared secret from DH KEYMAT: s >>=20 >> I2: ID_I, g^y, HMAC(s, I2), SIGN(ID_I, I2) >> ------------------------------------> >>=20 >> =09= >> = VER_SIG(ID_I, I2) >> = DH KEYMAT: Derived using HKDF* on g^{xy}, salt and peer info as input >> = Derive shared secret from DH KEYMAT: s >> = HMAC(s, I2) >>=20 >> R2: HMAC(s, R2), SIGN(ID_R, R2) >> <------------------------------------ >>=20 >> HMAC(s, R2) >> VER_SIG(ID_R, R2) >>=20 >>=20 >> * The HMAC-based Key Derivation Function (HKDF) is defined in = RFC5869. >>=20 >> ID_x represent the public key of the respective host. SIGN and = VER_SIG use the private key as first parameter and the message as second = input. Their cost of depend on the signature algorithm in use. HIP = supports RSA, DSA and ECDSA. Likewise, HIP supports both classical DH = and ECDH. >>=20 >>=20 >>=20 >> DEX: >> ------- >>=20 >> Initiator = Responder >>=20 >> I1 >> ------------------------------------> >>=20 >> = Existing static DH key pair: x, [ID_R =3D] g^x >>=20 >> R1: ID_R >> <------------------------------------ >>=20 >> Existing static DH key pair: y, [ID_I =3D] g^y >> DH DEX KEYMAT*: Derived using g^{xy}, salt and peer info as input >> Derive master key from DH: k >> Draw random secret: s_I >>=20 >> I2: ID_I, ECR(k, s_I), CMAC(k, I2) >> ------------------------------------> >>=20 >> = DH DEX KEYMAT*: Derived using g^{xy}, salt and peer info as input >> = Derive master key from DH: k >> = Verify CMAC(k, I2) >> = s_I =3D DCR(k, s_I) >> = Draw random secret: s_R >> = Pair-wise key**: Derived using DH DEX KEYMAT* generation function on s_I = | s_R as input >>=20 >> R2: PK, ECR(k, s_R), CMAC(k, R2) >> <------------------------------------ >>=20 >> Verify CMAC(k, R2) >> s_I =3D DCR(k, s_I) >> Pair-wise key**: Derived using DH DEX KEYMAT* generation function on = s_I | s_R as input >>=20 >>=20 >> * Section 6.3 of draft-moskowitz-hip-rg-dex-02 explains how key = material generation works in detail. >> ** The pair-wise key is used in DEX for the payload protection = protocol. >>=20 >> ECR and DCR denote encryption and decryption functions (preferably = AES in the CoRE scenario) with the symmetric key as first input and the = plain-text as second input parameter. Furthermore, the DEX draft does = not provide signing functionality at the moment. However, I believe that = this can still be changed according to the needs of the community. >>=20 >> I have left out performance optimizations and DoS protection = mechanisms in my descriptions (e.g. R1 pre-creation and puzzle) for the = sake of clarity. I hope that this description provides the kind of = information you are looking for. Note that PK-based authentication and = DH key derivation are two separate mechanisms with HIP and are not = integrated in a similar way as for HMQV. >>=20 >> Please let me know, if you need more specific information on one of = the mechanisms or the packet exchange I talked about above. >>=20 >> BR, >> Ren=E9 >>=20 >>=20 >>=20 >>>> I am sending this to the list, since Carsten Bormann is right: the = group as a whole would benefit from technical discussions. >>>>=20 >>> Sure. >>>=20 >>> Best regards, >>>=20 >>> Tobias >>>=20 >>>=20 >>>=20 >>>> Best regards, Rene >>>>=20 >>>> On 20/10/2010 4:35 PM, Rene Struik wrote: >>>>> Hi Tobias: >>>>>=20 >>>>> If the device's public key and the CA's signature verification key = are similar mathematical objects (e.g., both are on the same elliptic = curve), then the crypto real estate to perform certificate self-tests = can be made to reuse that used to perform key computations with an = authenticated key agreement scheme that uses certs. Obviously, this = would require the device to have access to an authentic copy of the CA's = signature verification key. If the CA's public key is not available, it = cannot check its own cert an alternative authentic channel has to be = established between the device and an external party who attests to the = authenticity of the cert. This being said, I do not know of practical = scenarios where the latter limitation arises (usually, one does not = accept any cert for which one does not already have a bootstrapped [or = not] root CA key). >>>>>=20 >>>>> It seems somewhat dangerous to use certs to bind arbitrary strings = to public keys if the semantics of that string is not well-understood or = can be defined at will be another process. After all, if the string is = StrA and semantics of one application defines this as "temperature = sensor A", while another application defines this as "thermometer B", = confusion may arise: does (StrA, PublicKey) relate to some physical = device A or some physical device B? Not sure how this can be avoided if = one does not stipulate that for any semantics one may define, the = mapping String --> Globally Unique Device Id is an injection. = Intuitively, this seems to suggest that each string contains an object = that is 1-1 mappable to this globally unique device id. >>>>>=20 >>>>> Best regards, Rene >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 20/10/2010 2:37 PM, Tobias Heer wrote: >>>>>> Hi Rene, >>>>>>=20 >>>>>> Am 20.10.2010 um 17:58 schrieb Rene Struik: >>>>>>=20 >>>>>>> Hi Tobias: >>>>>>>=20 >>>>>>> No worries - I am just curious to see how HIP fits in with = ubiquitous networks of smart objects, why one would care about the = protocol, and which use cases are enabled. Depending the outcome hereof, = it may be worth pointing to in IETF drafts etc. >>>>>>>=20 >>>>>>> Some brief comments below (enclosed by RS>> and<>>>>>>=20 >>>>>>> Best regards, Rene >>>>>>>=20 >>>>>>> On 20/10/2010 11:31 AM, Tobias Heer wrote: >>>>>>>> Hi Rene, >>>>>>>>=20 >>>>>>>> First: thanks for your feedback. [snip(RS)]. I'll respond to = the quick questions immediately and will come back with a more detailed = and better specified description in a couple of days. Actually Ren=E9 = Hummen might respond instead of me. >>>>>>>>=20 >>>>>>>> Am 20.10.2010 um 16:59 schrieb Rene Struik: >>>>>>>>=20 >>>>>>>>> Hi Tobias, Zhen: >>>>>>>>>=20 >>>>>>>>> I would be indebted if you could provide some feedback on my = email as of Tuesday last week (October 12, 2010, 12:23pm EDT - - cf. = below). >>>>>>>>>=20 >>>>>>>>> Best regards, Rene >>>>>>>>>=20 >>>>>>>>> On 12/10/2010 12:23 PM, Rene Struik wrote: >>>>>>>>>> Hi Tobias: >>>>>>>>>>=20 >>>>>>>>>> Thanks for your note. >>>>>>>>>>=20 >>>>>>>>>> Does your "ascii art" description, Step 1)-3) allow the = scenario, where (a) one assigns a node id and imprints this (e.g., = blowing fuse during chip testing); >>>>>>>>>> (b) has a node generating its own long-term public/private = key pair and outputting its node id and public key (e.g., during chip = testing -- this would >>>>>>>>>> correspond to registering a public key with an RA); (c) have = CA create a certificate in different process and return this value at = later production/ >>>>>>>>>> personalization stage? >>>>>>>> a) yes it would >>>>>>>> b) yes, the node could generate the static DH key by itself and = acquire a certificate for this key (e.g., at deployment time) >>>>>>>> c) I am not completely sure what you mean with "different = process" and "return" however, I can outline the possible flexibility = that one would have: >>>>>>>>=20 >>>>>>> RS>> >>>>>>> Setting would be where one would register a pair (Device Id, = Public key) during production, ship a database of these pairs to a CA, = have the latter generating a certificate for (Device Id, Public key) = pairs of its choosing and tie this to associated keying material (such = as policy field, validity period, and the-like). Certificates themselves = could then find a way back to a device via any other communication = channel (does not require online/inline involvement of CA and could, = e.g., by provided when personalized in a BestBuy shop, using a BestBuy = CA (note that BestBuy CA would then have to relie on the RA used during = production - the one that collected the database). >>>>>>> <>>>>>>> (I am taking about DEX now, not HIP BEX) >>>>>>>>=20 >>>>>>>> i) The static DH key can either be node-generated or = imprinted by some entity (in a secure environment) >>>>>>>> ii) The certificate can either be imprinted when the node is = manufactured or it can be imprinted later (again, in a secure = environment) >>>>>>> RS>> >>>>>>> Not sure why imprinting of certificate (authorization of state = change aside) would need to be done in secured environment in general, = since this is public piece of information. >>>>>>> <>>>>> Sure, the information is public but nodes that cannot verify = their own certificate (I do not assume that all nodes are able to verify = digital signatures. However, I am not sure if it is useful to assume = that a host supports ECDH but not ECDSA) might accept an invalid = certificate and could, from that moment on, not authenticate towards a = legitimate host anymore. The secure environment is not needed if a) a = node can verify its own certificate or b) if the node can verify the = identity of the device that imprints the certificate. >>>>>>=20 >>>>>>>> iii) The certificate could be renewed at any time (provided = there is a secure mechanism for that) >>>>>>>> iv) The DH public key could be renewed as well (at any time), = however, a node would require a new certificate, authenticating the new = DH key then >>>>>>>>=20 >>>>>>>> For BEX, nodes' identity would be the RSA/DSA/ECDSA key of the = node instead of the static DH public key. Hence, the ephemeral DH key = would change more often while the ECDSA public key would be in the = certificate. >>>>>>>>=20 >>>>>>> RS>> >>>>>>> I still have some trouble understanding how identifying nodes by = their public key is going to satisfy use case scenarios where one may = have changes to the public key, different certificates, and the-like. = Please note that the objective of certificates is to provide for a = secure binding between a device's id and its private key (via the = corresponding public key), thus freeing one to just use device ids -- = after all, certificate processing would then yield the corresponding = public key(s) purportedly owned by that device. >>>>>>> <>>>>> The certificate would bind a string to the public key (static DH = or RSA/DSA/ECDSA). The string would be used by layers above HIP. HIP = maps the string to the static public key of the peer in the BEX by using = the certificate that the peer provides. A device is therefore identified = by a string not a public key (as in vanilla HIP). >>>>>>=20 >>>>>>>>>> Right now, from Section 4.1.3 of = draft-ietf-hip-rfc5201-bis-02, I get the impression that HIP does = execute an authenticated DH key agreement scheme. If so, >>>>>>>>>> this makes me wonder how HIP differentiates from protocols, = such as ECMQV and, e.g., HMQV, which are all not that much more = expensive than ECDH. If the >>>>>>>>>> difference is in the "puzzle" element, couldn't one just add = something similar to a well-known authenticated scheme that is already = standardized with, e.g., >>>>>>>>>> NIST? >>>>>>>> I'll let Ren=E9 Hummen respond to this question. >>>>>>>>=20 >>>>>>> RS>> >>>>>>> Sure - looking forward to this. This would be easy to compare, = once one has succinct description of the cryptographic aspects of the = protocol (so that, e.g., one can count the number of scalar point = multiplications involved, etc.). >>>>>>> <>>>>>>>>> As to forward secrecy: reason to include this is that many = sensor-type nodes can be expected to be physically unprotected (e.g., = screwed on a street lamp >>>>>>>>>> post, on a garage roof, etc.) and, therefore, may be more = vulnerable to device compromise over time (esp. since one cannot expect = all nodes to be tamper >>>>>>>>>> resistant or tamper evident). By virtue of forward secrecy, = compromise over time does not compromise the whole device's history, but = only the current set of >>>>>>>>>> symmetric keys (note: I make some shortcuts in my reasoning = on key management here). Admittedly, my list of security properties is = based on "desired" >>>>>>>>>> functionality and does not exclude functionality that may = require, e.g., public-key crypto constructs. However, from a user's = perspective, the only thing that >>>>>>>>>> matters is features and not what is "under the hood", as long = as that is not cost-prohibitive (which I contend it is not -- cf., e.g., = Section 3.2 of >>>>>>>>>> draft-struik-6lowapp-security-considerations-00). (BTW - All = other desired security properties I listed have an underlying = rationale.) >>>>>>>> I am still somewhat unsure about cost and capabilities of the = targeted devices. Depending on who you talk to, people seem to expect = sensors that are capable of ECC crypto, barely capable or not capable at = all. >>>>>>>> Are there minimal hardware specs for target devices? >>>>>>>>=20 >>>>>>> RS>> >>>>>>> Almost all 802.15.4-based modules have hardware support for = AES-128 (in forward mode). Since the MAC layer requires error detection = using CRC-16 linear feedback shift regsiter circuits (which is a no = brainer) and since, e.g., elliptic curves over binary extension fields = can be realized using shift registers that are of order of magnitude = anything up to 256 registers, I do not see a problem for hardware = support here (once implemented in large scale environments). >>>>>>>=20 >>>>>>> Source: http://2010.eccworkshop.org/ >>>>>>> Junfeng Fan(K.U.Leuven, = Belgium) >>>>>>> /ECC on constrained devices/ >>>>>>> The embedded security community has been looking at the ECC ever = since it was introduced. Hardware designers are now challenged by = limited area (<15k Gates), low power budget (<100uw) and sophisticated = physical attacks. This talk will report the state-of-the-art ECC = implementations for ultra-constrained devices. We take a passive RFID = tag as our potential target. We will discuss the known techniques to = realize ECC on such kind of devices, and what are the challenges we face = now and in the near future. >>>>>>> <>>>>> Impressive. I'll certainly give it a closer look. >>>>>>=20 >>>>>> Tobias >>>>>>=20 >>>>>=20 >>>>=20 >>>> --=20 >>>> email: rstruik.ext@gmail.com >>>> Skype: rstruik >>>> cell: +1 (647) 867-5658 >>>> USA Google voice: +1 (415) 690-7363 >>>>=20 >>>=20 >>>=20 >>>=20 >>> --=20 >>> Dipl.-Inform. Tobias Heer, Ph.D. Student >>> Chair of Communication and Distributed Systems - comsys >>> RWTH Aachen University, Germany >>> tel: +49 241 80 207 76 >>> web: http://ds.cs.rwth-aachen.de/members/heer >>> blog: http://dtobi.wordpress.com/ >>> card: http://card.ly/dtobi >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >>=20 >>=20 >> -- >> Dipl.-Inform. Rene Hummen, Ph.D. Student >> Chair of Communication and Distributed Systems >> RWTH Aachen University, Germany >> tel: +49 241 80 20772 >> web: http://ds.rwth-aachen.de/members/hummen >>=20 >=20 >=20 > --=20 > email: rstruik.ext@gmail.com > Skype: rstruik > cell: +1 (647) 867-5658 > USA Google voice: +1 (415) 690-7363 >=20 -- Dipl.-Inform. Rene Hummen, Ph.D. Student Chair of Communication and Distributed Systems RWTH Aachen University, Germany tel: +49 241 80 20772 web: http://ds.rwth-aachen.de/members/hummen -- Dipl.-Inform. Rene Hummen, Ph.D. Student Chair of Communication and Distributed Systems RWTH Aachen University, Germany tel: +49 241 80 20772 web: http://ds.rwth-aachen.de/members/hummen --Apple-Mail-20--724181842 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN7zCCBCEw ggMJoAMCAQICAgDHMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0 c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQD ExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNjEyMTkxMDI5MDBaFw0xOTA2MzAyMzU5 MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJ MSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKm FNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItq aACa7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMq ljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZDz+HV Ez2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjgdkwgdYwcAYD VR0fBGkwZzBloGOgYYZfaHR0cDovL3BraS50ZWxlc2VjLmRlL2NnaS1iaW4vc2VydmljZS9hZl9E b3dubG9hZEFSTC5jcmw/LWNybF9mb3JtYXQ9WF81MDkmLWlzc3Vlcj1EVF9ST09UX0NBXzIwHQYD VR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHDeRu69VPXF+CJei0XbAqz K50zMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgECMA0GCSqGSIb3DQEBBQUAA4IB AQA74Vp3wEgX3KkY7IGvWonwvSiSpspZGBJw7Cjy565/lizn8l0ZMfYTK3S9vYCyufdnyTmieTvh ERHua3iRM347XyYndVNljjNj7s9zw7CSI0khUHUjoR8Y4pSFPT8z6XcgjaK95qGFKUD2P3MyWA0J a6bahWzAP7uNZmRWJE6uDT8yNQFb6YyC2XJZT7GGhfF0hVblw/hc843uR7NTBXDn5U2KaYMo4RMJ hp5eyOpYHgwf+aTUWgRo/Sg+iwK2WLX2oSw3VwBnqyNojWOl75lrXP1LVvarQIc01BGSbOyHxQoL BzNytG8MHVQs2FHHzL8w00Ny8TK/jM5JY6gA9/IcMIIE2jCCA8KgAwIBAgIEDuQh4zANBgkqhkiG 9w0BAQUFADBeMQswCQYDVQQGEwJERTEUMBIGA1UEChMLUldUSCBBYWNoZW4xFzAVBgNVBAMTDlJX VEggQWFjaGVuIENBMSAwHgYJKoZIhvcNAQkBFhFjYUByd3RoLWFhY2hlbi5kZTAeFw0wOTEwMDEx MjQ1MDdaFw0xMjA5MzAxMjQ1MDdaMDkxCzAJBgNVBAYTAkRFMRQwEgYDVQQKEwtSV1RIIEFhY2hl bjEUMBIGA1UEAxMLUmVuZSBIdW1tZW4wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCw KpV77WtQa3ZIx+dWRTgR8wxSUsQoSEY2Do5wNPJ/m3hO3P7e8FfVKSaTimKHvRPiRvCX+HW2ldMA f33GWtJTrN6hbSHzQTpq84uQOp/R8ad094wdKbenITaOWISEAjymgA0gS1RpvxaOv5r9uw1Th2ci kjWEOA3tIXCFwFwfMzA/QllikzSkbmm8a6RryOUyQCqCpt9GGS0i1KC+NIa/GP883S4W4En9PxA+ VJ4hJFwjnIt0E+wUigPBQvLHxRqBT/sXSJxsSZO/uNR99dxKeQmdd4Uob5olMA94uZX/rbeZdgDu 49qSIlx/bEFzJTQzH7yDATed6nXGDojAVHeBAgMBAAGjggHDMIIBvzAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIF4DApBgNVHSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisGAQQBgjcUAgIwHQYDVR0O BBYEFN+tg8k5s/o7Bjed1LmJouNUa4NUMB8GA1UdIwQYMBaAFG7VPsAcL3HJPL9JTu9qVUjs0fI4 MCgGA1UdEQQhMB+BHXJlbmUuaHVtbWVuQGNzLnJ3dGgtYWFjaGVuLmRlMHkGA1UdHwRyMHAwNqA0 oDKGMGh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvcnd0aC1jYS9wdWIvY3JsL2NhY3JsLmNybDA2oDSg MoYwaHR0cDovL2NkcDIucGNhLmRmbi5kZS9yd3RoLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGUBggr BgEFBQcBAQSBhzCBhDBABggrBgEFBQcwAoY0aHR0cDovL2NkcDEucGNhLmRmbi5kZS9yd3RoLWNh L3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDBABggrBgEFBQcwAoY0aHR0cDovL2NkcDIucGNhLmRmbi5k ZS9yd3RoLWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQUFAAOCAQEAmXPLNSHW Ze3V4Rq3P2pcaBIlY4Z/nJ1jH3u6yBD3gGZrthpu1o0g45hOWbcvkkcQwvEXKlnWeiVXJsQ2XElz ydNFQprK9GFRZvuOJUkMdR87uupqLESpoue7kmTVCFcqg8c/Q9D5KTbTTtrGDydcqKy+MWbrbtGb lg0R8ZJmnIlb+8RLCqa4MbYq2M2kiImYzDrczlPWvy3SHiPASNFf31XDLFP26QlO3USacm/E+CfM sgQFudf9BqE6yW8qoqx0x1xyMdo5tWyT1MUKsDA/cGADc+r2orBNBsZ7AjdPi85fJS3NE2PGhMEZ BCsvt/EC/yIQK7O3DwELk0VlVaE/uDCCBOgwggPQoAMCAQICBAnydOAwDQYJKoZIhvcNAQEFBQAw WjELMAkGA1UEBhMCREUxEzARBgNVBAoTCkRGTi1WZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAi BgNVBAMTG0RGTi1WZXJlaW4gUENBIEdsb2JhbCAtIEcwMTAeFw0wNzAyMTQxMTQ5MzhaFw0xOTAy MTMwMDAwMDBaMF4xCzAJBgNVBAYTAkRFMRQwEgYDVQQKEwtSV1RIIEFhY2hlbjEXMBUGA1UEAxMO UldUSCBBYWNoZW4gQ0ExIDAeBgkqhkiG9w0BCQEWEWNhQHJ3dGgtYWFjaGVuLmRlMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuDAIZOPI3HpS3zVCOZLzL/gheeMSZy+Mf3CUJzdjSHeg id36rNLIjtnsSAAn83Y8TlKUOmRTp+aXU704u7LZ5PFgGj/3fSxXfJPRm8Y4e8Ydy/tGt2nPv7Ry XF+euJ7VMRrVRjLkoRKFGmVE+X8Pe0y9+lCfDqly66qXQCnBSmifqYEadoEy4+DDVDD4wOBpbLaY 6C50/vqhZu7f2UvdvxNzqjSVMBx+gt+b0q6FbHJoPmu18U+lOCTvfTGMTXEyDM4T0vWLaft9NsO4 udXWgY69IRRjytJy0leoL++8wUhSewFRiScQUlMw59MZAy2L2cKmnmJI/JAwdqEnkcnxowIDAQAB o4IBsDCCAawwDwYDVR0TAQH/BAUwAwEB/zALBgNVHQ8EBAMCAQYwHQYDVR0OBBYEFG7VPsAcL3HJ PL9JTu9qVUjs0fI4MB8GA1UdIwQYMBaAFEm3xs/oPR9/6kR7Eyn38QpwPt5kMBwGA1UdEQQVMBOB EWNhQHJ3dGgtYWFjaGVuLmRlMIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NkcDEucGNhLmRm bi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2NhY3JsLmNybDA9oDugOYY3aHR0cDovL2NkcDIu cGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2NhY3JsLmNybDCBogYIKwYBBQUHAQEE gZUwgZIwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2Ev cHViL2NhY2VydC9jYWNlcnQuY3J0MEcGCCsGAQUFBzAChjtodHRwOi8vY2RwMi5wY2EuZGZuLmRl L2dsb2JhbC1yb290LWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQUFAAOCAQEA F4d+xiwLHCB61akGKxuT/3WFC8QLHlOsblyp0qVU5zFlRX9U7Tf6dg/vF0yrZfwOFpWGvZ6fjjW5 VnEtZybLmH+zfcKzuMwhHFQTSyABwmN2VxviKDR8IF6kmKlx86wEGY5Eia9UX2xROJ41MtJzYbQu dR19KJ4Fn6jg3Os+2hfcHttOteTIfCpPLqMeF4Iyy1f1Iz1ZcEQJ7mCHhdMMnL0Oo8/zyTLjq10o aano6WokV6isfKD1wJQnJ6KkS5UHNS9IsEBwZ9BJurQ5jB3GoW3/UgTlomfPjtGr+JcvAkPeaJM/ YbaPVBK11CMzXmtgEFwbZSMiyyoFbmD3+ItyMjGCAt4wggLaAgEBMGYwXjELMAkGA1UEBhMCREUx FDASBgNVBAoTC1JXVEggQWFjaGVuMRcwFQYDVQQDEw5SV1RIIEFhY2hlbiBDQTEgMB4GCSqGSIb3 DQEJARYRY2FAcnd0aC1hYWNoZW4uZGUCBA7kIeMwCQYFKw4DAhoFAKCCAU0wGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTAxMTA1MTQ0MjI3WjAjBgkqhkiG9w0BCQQx FgQU0iJo4sjlPCLYkcvCXPOik8I+ZUowdQYJKwYBBAGCNxAEMWgwZjBeMQswCQYDVQQGEwJERTEU MBIGA1UEChMLUldUSCBBYWNoZW4xFzAVBgNVBAMTDlJXVEggQWFjaGVuIENBMSAwHgYJKoZIhvcN AQkBFhFjYUByd3RoLWFhY2hlbi5kZQIEDuQh4zB3BgsqhkiG9w0BCRACCzFooGYwXjELMAkGA1UE BhMCREUxFDASBgNVBAoTC1JXVEggQWFjaGVuMRcwFQYDVQQDEw5SV1RIIEFhY2hlbiBDQTEgMB4G CSqGSIb3DQEJARYRY2FAcnd0aC1hYWNoZW4uZGUCBA7kIeMwDQYJKoZIhvcNAQEBBQAEggEAj/y2 Ts07f8hj5zA9I2/eSmiYx0vum1CtuU496yOt1G7r2sO+K6ra1HSaT0IpZ5leQ7VlGGt95w5+k+en aS670DO/o3KOqPOqLeHN9NdQ0rTSZMsfAd3sR34LHSJGe/7MxPHmsAIVPPICnsYncCLzQ4XJIxXC vizXfznXwa/+2NNwr9xCoHYGFR8PVO8VT+25p+1b0tpGFhNc+TBVPM9vYTYaUl6QPECp0fTzvGg2 j4sU6o6B99/551IBDkS2B6wwCMtFU0grxIFqHoYEM+bGzKeCdZmhovjtfN6jOSo6OWFO/mIpOf3s rIq2AJfB1QhAhmjuq/H/DoJ9ET1DabUmowAAAAAAAA== --Apple-Mail-20--724181842-- From fluffy@cisco.com Fri Nov 5 17:40:54 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 736B13A6951 for ; Fri, 5 Nov 2010 17:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m78wC7WxpFHd for ; Fri, 5 Nov 2010 17:40:48 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id B632328C0EE for ; Fri, 5 Nov 2010 17:40:41 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtINAIJA1EyrRN+K/2dsb2JhbAAcoVhxn0WbHIVIBIRYhX6DCg X-IronPort-AV: E=Sophos;i="4.58,306,1286150400"; d="scan'208";a="289399902" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-2.cisco.com with ESMTP; 06 Nov 2010 00:40:38 +0000 Received: from [192.168.4.2] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id oA60ecfv007604 for ; Sat, 6 Nov 2010 00:40:38 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 5 Nov 2010 18:40:55 -0600 Message-Id: <523C7286-C01F-4AD0-A4E7-3E61AE7F9991@cisco.com> To: core Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [core] AD-Hoc Plug Fest Room For Sunday X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 00:40:54 -0000 The plug fest will be in room "Jade 1" From trac@tools.ietf.org Sat Nov 6 02:12:48 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2ABA73A68DC for ; Sat, 6 Nov 2010 02:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qbW51iEEy-VK for ; Sat, 6 Nov 2010 02:12:38 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id E7F8D3A68E3 for ; Sat, 6 Nov 2010 02:12:37 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PEepP-00066E-FU; Sat, 06 Nov 2010 02:12:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Sat, 06 Nov 2010 09:12:51 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/32 Message-ID: <057.c5048ce08a040beee18d2c625df11c1e@tools.ietf.org> X-Trac-Ticket-ID: 32 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] observe #32 (new): Improve abstract and intro X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 09:12:49 -0000 #32: Improve abstract and intro The abstract and introduction of coap-observe are pretty thin right now for a WG document. We need to add more on the requirements the design solves, its features and possible uses. -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: enhancement | Status: new Priority: trivial | Milestone: Component: observe | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From trac@tools.ietf.org Sat Nov 6 02:14:58 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73E6C3A68D8 for ; Sat, 6 Nov 2010 02:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aqYGQMtT5jHY for ; Sat, 6 Nov 2010 02:14:57 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 6609A3A68D1 for ; Sat, 6 Nov 2010 02:14:57 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PEere-0007DH-AS; Sat, 06 Nov 2010 02:15:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: hartke@tzi.org, zach@sensinode.com X-Trac-Project: core Date: Sat, 06 Nov 2010 09:15:10 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/33 Message-ID: <057.511b2f10b38fa3e3e629a436c4d75ef2@tools.ietf.org> X-Trac-Ticket-ID: 33 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hartke@tzi.org, zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] observe #33 (new): s/Subscription/Observation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 09:14:58 -0000 #33: s/Subscription/Observation The current terminology used in the draft about Subscription is misleading, and seems to often confuse people to think that this is trying to achieve some pub/sub middleware framework (which it is not). Since observation/notification is the proper terminology, this ticket is to remove any references to "subscription" and replace them with "observation". -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: hartke@… Type: enhancement | Status: new Priority: minor | Milestone: Component: observe | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From trac@tools.ietf.org Sat Nov 6 02:18:06 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E18763A68F5 for ; Sat, 6 Nov 2010 02:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id euY22TOu04E2 for ; Sat, 6 Nov 2010 02:17:54 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 547483A68D8 for ; Sat, 6 Nov 2010 02:17:52 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PEeuU-00083G-Az; Sat, 06 Nov 2010 02:18:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: hartke@tzi.org, zach@sensinode.com X-Trac-Project: core Date: Sat, 06 Nov 2010 09:18:06 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/34 Message-ID: <057.e823b6e524d6a0de0f3b41d3177b07dd@tools.ietf.org> X-Trac-Ticket-ID: 34 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hartke@tzi.org, zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] observe #34 (new): Cancelling a subscription X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 09:18:06 -0000 #34: Cancelling a subscription coap-observe is currently lacking a proper discussion on tearing down a observation. A paragraph should be added to 2.1 describing how sending a GET request with an Observation-lifetime of 0 removes an observation. As discussed on the mailing list with Adam Roach, it should be clarified that making a normal GET (with no Observation-lifetime option) does not affect any ongoing observation. -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: hartke@… Type: enhancement | Status: new Priority: major | Milestone: Component: observe | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From trac@tools.ietf.org Sat Nov 6 02:18:59 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04B0A3A68E3 for ; Sat, 6 Nov 2010 02:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGDNO+9cPgCv for ; Sat, 6 Nov 2010 02:18:57 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 7FBCA3A68D8 for ; Sat, 6 Nov 2010 02:18:57 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PEevX-00020B-OU; Sat, 06 Nov 2010 02:19:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: hartke@tzi.org, zach@sensinode.com X-Trac-Project: core Date: Sat, 06 Nov 2010 09:19:11 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/35 Message-ID: <057.f781103e2e244ce4f30199f4808df127@tools.ietf.org> X-Trac-Ticket-ID: 35 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hartke@tzi.org, zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] observe #35 (new): Add discussion on message reordering X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 09:18:59 -0000 #35: Add discussion on message reordering This ticket is to add a discussion on message reordering. -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: hartke@… Type: enhancement | Status: new Priority: minor | Milestone: Component: observe | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From trac@tools.ietf.org Sat Nov 6 02:19:51 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 324743A68D8 for ; Sat, 6 Nov 2010 02:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Npu-7PrMINlL for ; Sat, 6 Nov 2010 02:19:50 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 6F52E3A68D1 for ; Sat, 6 Nov 2010 02:19:50 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PEewO-00059q-S5; Sat, 06 Nov 2010 02:20:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: hartke@tzi.org, zach@sensinode.com X-Trac-Project: core Date: Sat, 06 Nov 2010 09:20:04 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/36 Message-ID: <057.dbea84638c82722d3a8ba105936f431e@tools.ietf.org> X-Trac-Ticket-ID: 36 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hartke@tzi.org, zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] observe #36 (new): Interaction with other mechanisms X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 09:19:51 -0000 #36: Interaction with other mechanisms Descibe how observations interact with other CoAP features such as the block-option, caching etc. -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: hartke@… Type: defect | Status: new Priority: minor | Milestone: Component: observe | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From trac@tools.ietf.org Sat Nov 6 02:21:29 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 983023A68F3 for ; Sat, 6 Nov 2010 02:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sGKTfaF++mre for ; Sat, 6 Nov 2010 02:21:29 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 0083F3A68F8 for ; Sat, 6 Nov 2010 02:21:28 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PEexz-0001PX-B1; Sat, 06 Nov 2010 02:21:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: hartke@tzi.org, zach@sensinode.com X-Trac-Project: core Date: Sat, 06 Nov 2010 09:21:43 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/37 Message-ID: <057.d76c4fb4eaf8e8db6bc0402562ae16bd@tools.ietf.org> X-Trac-Ticket-ID: 37 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hartke@tzi.org, zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] observe #37 (new): Section on complimentary sub/pub REST frameworks X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 09:21:29 -0000 #37: Section on complimentary sub/pub REST frameworks Add a section descibing how this CoAP observation mechanism (at the transfer protocol layer) has a different purpose and is complimentary to general sub/pub REST frameworks like Websockets. -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: hartke@… Type: enhancement | Status: new Priority: minor | Milestone: Component: observe | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From trac@tools.ietf.org Sat Nov 6 02:22:41 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2E963A68FD for ; Sat, 6 Nov 2010 02:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kIwgWm4cheRu for ; Sat, 6 Nov 2010 02:22:39 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 572633A68F7 for ; Sat, 6 Nov 2010 02:22:39 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PEez7-0003it-P7; Sat, 06 Nov 2010 02:22:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: hartke@tzi.org, zach@sensinode.com X-Trac-Project: core Date: Sat, 06 Nov 2010 09:22:53 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/38 Message-ID: <057.96d9816362e6ef1fb87feaf9a3bb73ae@tools.ietf.org> X-Trac-Ticket-ID: 38 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hartke@tzi.org, zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] observe #38 (new): Example on proxy interaction X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 09:22:41 -0000 #38: Example on proxy interaction Add an example to the document showing how a proxy could use observe to update a cache which is then used to feed HTTP clients doing e.g. polling or long-polling on the resource. -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: hartke@… Type: enhancement | Status: new Priority: minor | Milestone: Component: observe | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From trac@tools.ietf.org Sat Nov 6 02:23:30 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A98BB3A6905 for ; Sat, 6 Nov 2010 02:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lNTUQr0snhG6 for ; Sat, 6 Nov 2010 02:23:29 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 933B63A6904 for ; Sat, 6 Nov 2010 02:23:29 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PEezv-0005kZ-KS; Sat, 06 Nov 2010 02:23:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: hartke@tzi.org, zach@sensinode.com X-Trac-Project: core Date: Sat, 06 Nov 2010 09:23:43 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/39 Message-ID: <057.04993421656cb054a86ee66d5b7ae8f8@tools.ietf.org> X-Trac-Ticket-ID: 39 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hartke@tzi.org, zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] observe #39 (new): Etag X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 09:23:30 -0000 #39: Etag Add an explanation of how observation interacts with (a single) Etag, and include an example showing Etag being used with observation. -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: hartke@… Type: enhancement | Status: new Priority: minor | Milestone: Component: observe | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From trac@tools.ietf.org Sat Nov 6 02:24:34 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11BA73A68FE for ; Sat, 6 Nov 2010 02:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wlRolbY59WJ9 for ; Sat, 6 Nov 2010 02:24:33 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 63FF93A68D1 for ; Sat, 6 Nov 2010 02:24:33 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PEf0v-0008T4-7B; Sat, 06 Nov 2010 02:24:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: cabo@tzi.org, zach@sensinode.com X-Trac-Project: core Date: Sat, 06 Nov 2010 09:24:45 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/40 Message-ID: <057.3802a750112dbc5e91ef2c793f29c25d@tools.ietf.org> X-Trac-Ticket-ID: 40 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: cabo@tzi.org, zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] observe #40 (new): Security section X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 09:24:34 -0000 #40: Security section A security section needs to be written for coap-observe. -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: cabo@… Type: enhancement | Status: new Priority: major | Milestone: Component: observe | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From trac@tools.ietf.org Sat Nov 6 02:28:06 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAB7F3A6903 for ; Sat, 6 Nov 2010 02:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SRRhS47mHn+9 for ; Sat, 6 Nov 2010 02:28:06 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 067813A68F3 for ; Sat, 6 Nov 2010 02:28:06 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PEf4P-0006ry-CR; Sat, 06 Nov 2010 02:28:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Sat, 06 Nov 2010 09:28:21 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/41 Message-ID: <057.674ff82a32feefa05923eefa8d128859@tools.ietf.org> X-Trac-Ticket-ID: 41 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] link-format #41 (new): Update link-header ref to RFC5988 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 09:28:06 -0000 #41: Update link-header ref to RFC5988 -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: defect | Status: new Priority: trivial | Milestone: Component: link-format | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From trac@tools.ietf.org Sat Nov 6 02:32:09 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDB923A68F3 for ; Sat, 6 Nov 2010 02:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zpi2d0acN82 for ; Sat, 6 Nov 2010 02:32:09 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 0BEA73A68D1 for ; Sat, 6 Nov 2010 02:32:09 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PEf8K-0004xZ-1w; Sat, 06 Nov 2010 02:32:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Sat, 06 Nov 2010 09:32:24 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/42 Message-ID: <057.5a0b47dd50a974001be4384c2bf76521@tools.ietf.org> X-Trac-Ticket-ID: 42 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] link-format #42 (new): Finalize the link-extensions to define X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 09:32:10 -0000 #42: Finalize the link-extensions to define The final link-extensions to be defined in this draft need to be locked down. Extensions to consider for removal: - sh "Short URL": Is this really in use? So far it seems people instead just make short URLs in the first place. Suggestion to remove. Extensions to consider for addition: - obs "Observation flag": A link-extension (with no value part) that when present indicates that this resource supports observation. - size "Size estimate": Indicates the estimated size for larger resources that will likely require block transfer. NOTE: link-extensions are exactly that, extensions. This is just small number defines for interoperability. Any other standard of vendor using this specification can extend the link-format with attributes of their own. -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: enhancement | Status: new Priority: major | Milestone: Component: link-format | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From trac@tools.ietf.org Sat Nov 6 02:33:04 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDEC63A68D1 for ; Sat, 6 Nov 2010 02:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtT2dhauOmaH for ; Sat, 6 Nov 2010 02:33:04 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 107B23A67D3 for ; Sat, 6 Nov 2010 02:33:04 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PEf9D-0007K8-Ee; Sat, 06 Nov 2010 02:33:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Sat, 06 Nov 2010 09:33:19 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/43 Message-ID: <057.d005db5590ce8657b72c72ab444450a0@tools.ietf.org> X-Trac-Ticket-ID: 43 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] link-format #43 (new): More examples X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 09:33:04 -0000 #43: More examples More examples are needed showing how the different features and link- extensions could be used. -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: link-format | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From trac@tools.ietf.org Sat Nov 6 02:41:50 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E731E3A68D1 for ; Sat, 6 Nov 2010 02:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KBrv2C3St5gu for ; Sat, 6 Nov 2010 02:41:50 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 3646C3A6910 for ; Sat, 6 Nov 2010 02:41:50 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PEfHh-00087k-8h; Sat, 06 Nov 2010 02:42:05 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Sat, 06 Nov 2010 09:42:05 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/44 Message-ID: <057.5368cb3fe031bdae8ac56f6b7d67d322@tools.ietf.org> X-Trac-Ticket-ID: 44 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] block #44 (new): How to estimate the size of a representation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 09:41:51 -0000 #44: How to estimate the size of a representation The issue has been brought up that it would be nice to be able to determine the size of a large representation before starting a block transfer on it (in case the receiving side does not have e.g. enough storage space for it). - At the minimum, the link-format should be able to indicate this for fairly static large resources. - The WG needs to determine if it is worthwhile also adding a new Size- estimate option that can be used to indicate the size of a representation when responding to a GET request, or in the request of a POST/PUT. -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: enhancement | Status: new Priority: major | Milestone: Component: block | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From trac@tools.ietf.org Sat Nov 6 02:46:24 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E48203A67D3 for ; Sat, 6 Nov 2010 02:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MiX2GOQg7AuK for ; Sat, 6 Nov 2010 02:46:23 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id E9AAE3A67B5 for ; Sat, 6 Nov 2010 02:46:23 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PEfM7-00015e-7k; Sat, 06 Nov 2010 02:46:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Sat, 06 Nov 2010 09:46:39 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/45 Message-ID: <057.da83241436b82aeff88628eb9e900b6e@tools.ietf.org> X-Trac-Ticket-ID: 45 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] block #45 (new): Large responses to large POST/PUT X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 09:46:25 -0000 #45: Large responses to large POST/PUT Section 2.2 of ietf-block-00 indicates that the mechanism is not able to deal with large responses to a large POST/PUT request. The document suggests that this would be dealt with using a redirect to perform the retrieval using a GET instead. coap-03 doesn't currently support redirects. This ticket proposes to add limited (same-host only) support for redirect to support the block option and other simple redirection needs. -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: enhancement | Status: new Priority: major | Milestone: Component: block | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From trac@tools.ietf.org Sat Nov 6 02:47:32 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8126B3A691C for ; Sat, 6 Nov 2010 02:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PSmnOTn-nxDK for ; Sat, 6 Nov 2010 02:47:31 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 8ED823A6910 for ; Sat, 6 Nov 2010 02:47:31 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PEfNC-0003RW-KT; Sat, 06 Nov 2010 02:47:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Sat, 06 Nov 2010 09:47:46 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/46 Message-ID: <057.402b325076adf6c484c4eea03498eaf9@tools.ietf.org> X-Trac-Ticket-ID: 46 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] block #46 (new): Error codes for block X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 09:47:32 -0000 #46: Error codes for block The error codes for block-00 are still 4__ TBD. This code needs to be defined. -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: task | Status: new Priority: trivial | Milestone: Component: block | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From trac@tools.ietf.org Sat Nov 6 02:48:32 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 331FE3A691C for ; Sat, 6 Nov 2010 02:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCy4MgcR09Zt for ; Sat, 6 Nov 2010 02:48:31 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 6CB613A6910 for ; Sat, 6 Nov 2010 02:48:31 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PEfOA-0003wi-SL; Sat, 06 Nov 2010 02:48:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Sat, 06 Nov 2010 09:48:46 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/47 Message-ID: <057.bc5380c6c85bd757f33164f373868a0c@tools.ietf.org> X-Trac-Ticket-ID: 47 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] block #47 (new): Benefits to introduction X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 09:48:32 -0000 #47: Benefits to introduction Move the benefits at the end of Section 2.2 to the document introduction. In addition add: - Easy to debug - Enables random access to a resource -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: Type: defect | Status: new Priority: major | Milestone: Component: block | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From trac@tools.ietf.org Sat Nov 6 02:49:17 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 797403A6929 for ; Sat, 6 Nov 2010 02:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6LRxQtMPWFjt for ; Sat, 6 Nov 2010 02:49:16 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id CE1773A691C for ; Sat, 6 Nov 2010 02:49:16 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PEfOt-0003xN-9K; Sat, 06 Nov 2010 02:49:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: cabo@tzi.org, zach@sensinode.com X-Trac-Project: core Date: Sat, 06 Nov 2010 09:49:31 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/48 Message-ID: <057.8ff30dd8b9126a4f506cc1fe56054290@tools.ietf.org> X-Trac-Ticket-ID: 48 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: cabo@tzi.org, zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] block #48 (new): Examples needed X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 09:49:17 -0000 #48: Examples needed Section on examples needs to be added to the draft. -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: cabo@… Type: enhancement | Status: new Priority: minor | Milestone: Component: block | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From trac@tools.ietf.org Sat Nov 6 02:50:15 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49DBA3A6929 for ; Sat, 6 Nov 2010 02:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jw4l3xIOBG-F for ; Sat, 6 Nov 2010 02:50:14 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 9496A3A692A for ; Sat, 6 Nov 2010 02:50:14 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PEfPo-00045X-R6; Sat, 06 Nov 2010 02:50:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: cabo@tzi.org, zach@sensinode.com X-Trac-Project: core Date: Sat, 06 Nov 2010 09:50:28 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/49 Message-ID: <057.97f8dcf1fed79b1e46222d730c06cc07@tools.ietf.org> X-Trac-Ticket-ID: 49 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: cabo@tzi.org, zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] block #49 (new): Security considerations X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 09:50:15 -0000 #49: Security considerations Security considerations need to be written for the draft. Any ideas on other threats or considerations that need to be covered in this document? -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: cabo@… Type: task | Status: new Priority: major | Milestone: Component: block | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From trac@tools.ietf.org Sat Nov 6 04:24:43 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 552663A69A4 for ; Sat, 6 Nov 2010 04:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id erE5XijyqsLQ for ; Sat, 6 Nov 2010 04:24:42 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id A8F383A6988 for ; Sat, 6 Nov 2010 04:24:42 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PEgtF-000416-In; Sat, 06 Nov 2010 04:24:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Sat, 06 Nov 2010 11:24:57 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/50 Message-ID: <057.5388bf9ad1647d65c4eca0123ed73ff3@tools.ietf.org> X-Trac-Ticket-ID: 50 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] coap #50 (new): Human readable error payloads X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 11:24:43 -0000 #50: Human readable error payloads From Klaus: "2.1.1. The figure suggests that the payload of a 4xx/5xx response is a human-readable diagnostic message (here: "Not found"). This doesn't seem to be defined anywhere, although I'd love if it was. (For example, my CoAP server includes a complete stack trace in a 500 response when an exception is thrown and it's in debug mode. This helps remote debugging a lot.)" Suggestion to recommend this in Section 11.1. -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: Type: enhancement | Status: new Priority: trivial | Milestone: Component: coap | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From trac@tools.ietf.org Sat Nov 6 04:26:22 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3645C3A6987 for ; Sat, 6 Nov 2010 04:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uike45QG4ig6 for ; Sat, 6 Nov 2010 04:26:21 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 8D3013A6973 for ; Sat, 6 Nov 2010 04:26:21 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PEgur-0007WP-5W; Sat, 06 Nov 2010 04:26:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Sat, 06 Nov 2010 11:26:37 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/51 Message-ID: <057.4b7183120354df949e6f1eceb1905167@tools.ietf.org> X-Trac-Ticket-ID: 51 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] coap #51 (new): Section 2 organization X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 11:26:22 -0000 #51: Section 2 organization Klaus commented on some inconsistencies in the Section 2 orgization. On the e-mail list an outline like this was proposed: 2.1. Transaction Model[[BR]] 2.1.1. Reliable Transaction[[BR]] 2.1.2. Unreliable Transaction[[BR]] 2.1.3. Transaction Messages[[BR]] 2.2. Request/Response Model[[BR]] 2.2.1. Synchronous Responses[[BR]] 2.2.2. Asynchronous Responses[[BR]] 2.2.3. Methods[[BR]] 2.2.4. Codes[[BR]] 2.3. Options -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: Type: enhancement | Status: new Priority: trivial | Milestone: Component: coap | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From trac@tools.ietf.org Sat Nov 6 04:29:53 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5203E3A68E8 for ; Sat, 6 Nov 2010 04:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ub05a5izROY for ; Sat, 6 Nov 2010 04:29:51 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id D12863A686D for ; Sat, 6 Nov 2010 04:29:50 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PEgyE-0006cj-12; Sat, 06 Nov 2010 04:30:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Sat, 06 Nov 2010 11:30:05 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/52 Message-ID: <057.7877dadaee8c1a49ad3c621003bde997@tools.ietf.org> X-Trac-Ticket-ID: 52 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] coap #52 (new): How strict to make POST definition? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 11:29:53 -0000 #52: How strict to make POST definition? In coap-03 a change was made to the POST definition (suggested by Kerry) to make it slightly more REST oriented compared to RFC2616. This ticket is to decide whether to: 1. Keep the coap-02 definition that was closer to RFC2616 allowing POST to be used for other things than creating sub-resources. or 2. Keep the coap-03 definition which includes only the REST usage of POST. -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: coap | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From trac@tools.ietf.org Sat Nov 6 04:34:13 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EBF63A68E1 for ; Sat, 6 Nov 2010 04:34:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EjBcKK88Cfd3 for ; Sat, 6 Nov 2010 04:34:12 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 7070E3A686D for ; Sat, 6 Nov 2010 04:34:12 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PEh2S-0006pE-1a; Sat, 06 Nov 2010 04:34:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Sat, 06 Nov 2010 11:34:27 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/53 Message-ID: <057.3c2c33e201209462cb9746082696f761@tools.ietf.org> X-Trac-Ticket-ID: 53 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] coap #53 (new): Token length X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 11:34:13 -0000 #53: Token length coap-03 integrated the Token Option, and initially was assigned a 1-2 byte length suitable only for short token codes assigned by a client. Klaus and Carsten have suggested that this should be substantially longer (even up to 270 bytes), allowing for the client to include context in the token itself and to protect it. On the other hand, Angelo and Zach argued that large tokens are difficult/impossible for constrained servers and that putting the wrong context into a token may be a security risk. As a compromise, this ticket suggsets to expand the Token option length to 1-8 bytes. Although 4 bytes could be enough for some context, it is not enough for protecting the context. For this 8 bytes would be a reasonable length. -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: coap | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From kerlyn2001@gmail.com Sat Nov 6 05:54:05 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9FD43A68CE for ; Sat, 6 Nov 2010 05:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GgqP1l8oXgTs for ; Sat, 6 Nov 2010 05:54:04 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 6E1863A6817 for ; Sat, 6 Nov 2010 05:54:04 -0700 (PDT) Received: by bwz12 with SMTP id 12so3890627bwz.31 for ; Sat, 06 Nov 2010 05:54:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=9+PN6xmuWKE6wv2tBPQ5IqZl/NcvhRfMJWHS9+J4yQw=; b=Ip1jMibuYro7Eu88A7VInZdGm8sfZFKcTG22m7S5tN7jkH5ZcO4+1/OtC2f786mitL jdQuFo1xuUCgpepySUxZdqu06N0X0D5qrrrU34i8NIxKNJ5HpumF7y+fYYiUVn01ybta 4uEtrC4JxonHqnCjSl0KemwV4NkosstV6FV2o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=VAinlyVncaFa0oD2n4jhbkWiq7bGPJfTiUCsw87YE5EcIt7CqZmKXHMf712rYNfGmQ PUkhLnmUy7EbYxFaBHqsWkJmO+VJYCBrjME/vqBJkzRk9EGEK/WU3J63EEqjM2MYSheb vxqa/IrZCmSJ1X3kG2u7wm/noWhGLKwXxXKlk= MIME-Version: 1.0 Received: by 10.204.97.131 with SMTP id l3mr2892149bkn.112.1289048057989; Sat, 06 Nov 2010 05:54:17 -0700 (PDT) Received: by 10.204.50.150 with HTTP; Sat, 6 Nov 2010 05:54:17 -0700 (PDT) In-Reply-To: <057.7877dadaee8c1a49ad3c621003bde997@tools.ietf.org> References: <057.7877dadaee8c1a49ad3c621003bde997@tools.ietf.org> Date: Sat, 6 Nov 2010 08:54:17 -0400 Message-ID: From: Kerry Lynn To: core issue tracker Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: core@ietf.org Subject: Re: [core] coap #52 (new): How strict to make POST definition? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 12:54:06 -0000 To be clear, I only suggested the addition of two words, "subordinate" and "parent", to clarify the text that was already there. I don't think th= is substantially changed the meaning of the text between versions 2 & 3. The section we're talking about is 2.3.2: http://tools.ietf.org/wg/core/draft-ietf-core-coap/draft-ietf-core-coap-03-= from-02.diff.html Now compare this to RFC 2616, section 9.5: "9.5 POST The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line. POST is designed to allow a uniform method to cover the following functions: - Annotation of existing resources; - Posting a message to a bulletin board, newsgroup, mailing list, or similar group of articles; - Providing a block of data, such as the result of submitting a form, to a data-handling process; - Extending a database through an append operation. The actual function performed by the POST method is determined by the server and is usually dependent on the Request-URI. The posted entity is subordinate to that URI in the same way that a file is subordinat= e to a directory containing it, a news article is subordinate to a newsgroup to which it is posted, or a record is subordinate to a database. The action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either 200 (OK) or 204 (No Content) is the appropriate response status, depending on whether or not the response includes an entity that describes the result. If a resource has been created on the origin server, the response SHOULD be 201 (Created) and contain an entity which describes the status of the request and refers to the new resource, and a Location header (see section 14.30). Responses to this method are not cacheable, unless the response includes appropriate Cache-Control or Expires header fields. However, the 303 (See Other) response can be used to direct the user agent to retrieve a cacheable resource. POST requests MUST obey the message transmission requirements set out in section 8.2. See section 15.1.3 for security considerations." If we want coap POST to be more like 2616, then I think language like "The actual function performed by the POST method is determined by the server and is usually dependent on the Request-URI" needs to be *added*. This will provide the backdoor RPC capability that many so- called RESTful designs depend on (IOW, using POST more like "invoke" than "append"). Now one thing I belive *is* a problem, and needs a new ticket, is the inability of the underlying transaction model to treat POST in a non- idempotent fashion. Figure 8 in draft-ietf-core-coap-03 shows the client retying a GET in the case where the ACK is lost. How the server treats this in the case of POST is unspecified. I believe this may result in the creation of *multiple* resources at the server. Need a new ticket: "CoAP MUST support At Most Once transactions" Regards, -K- On Sat, Nov 6, 2010 at 7:30 AM, core issue tracker wr= ote: > #52: How strict to make POST definition? > > =A0In coap-03 a change was made to the POST definition (suggested by Kerr= y) > =A0to make it slightly more REST oriented compared to RFC2616. This ticke= t is > =A0to decide whether to: > > =A01. Keep the coap-02 definition that was closer to RFC2616 allowing POS= T to > =A0be used for other things than creating sub-resources. > > =A0or > > =A02. Keep the coap-03 definition which includes only the REST usage of P= OST. > > -- > --------------------------------+----------------------------------------= --- > =A0Reporter: =A0zach@=85 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 Owner: > =A0 =A0 Type: =A0enhancement =A0 =A0 =A0 =A0 | =A0 =A0 =A0Status: =A0new > =A0Priority: =A0minor =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 Milestone: > Component: =A0coap =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 Version: > =A0Severity: =A0- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0Keywords: > --------------------------------+----------------------------------------= --- > > Ticket URL: > core > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From trac@tools.ietf.org Sat Nov 6 09:10:48 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1C6C3A682A for ; Sat, 6 Nov 2010 09:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RCJ7OJe8V813 for ; Sat, 6 Nov 2010 09:10:44 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id A54613A6888 for ; Sat, 6 Nov 2010 09:10:44 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PElM3-0007QL-47; Sat, 06 Nov 2010 09:10:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Sat, 06 Nov 2010 16:10:58 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/54 Message-ID: <057.c99f346c5afd3fa73502ae8c72aadce9@tools.ietf.org> X-Trac-Ticket-ID: 54 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] coap #54 (new): IPsec and multicast X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 16:10:48 -0000 #54: IPsec and multicast As CoAP is used with multicast, Section 10.1 needs to be extended with a discussion on the use of IPsec with multicast in a MultiKey setup. -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: Type: task | Status: new Priority: minor | Milestone: Component: coap | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From trac@tools.ietf.org Sat Nov 6 09:12:44 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDD663A682A for ; Sat, 6 Nov 2010 09:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZOwvVexv5rP for ; Sat, 6 Nov 2010 09:12:44 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 0D50D3A67ED for ; Sat, 6 Nov 2010 09:12:44 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PElO0-0007DX-53; Sat, 06 Nov 2010 09:13:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Sat, 06 Nov 2010 16:13:00 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/55 Message-ID: <057.cbcb8082fb49a1a254def976b454a663@tools.ietf.org> X-Trac-Ticket-ID: 55 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] coap #55 (new): AES-CCM vs. AES-CBC X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 16:12:45 -0000 #55: AES-CCM vs. AES-CBC As AES-CCM is more suitabe to most low-power RF chips such as 802.15.4, Section 10 should consider cypher suites that make use of it intead of AES-CBC. -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: Type: enhancement | Status: new Priority: trivial | Milestone: Component: coap | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From trac@tools.ietf.org Sat Nov 6 09:15:19 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEFC83A6885 for ; Sat, 6 Nov 2010 09:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0+acT14R15Sz for ; Sat, 6 Nov 2010 09:15:19 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 33EDF3A67ED for ; Sat, 6 Nov 2010 09:15:19 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PElQV-0001i7-Bx; Sat, 06 Nov 2010 09:15:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Sat, 06 Nov 2010 16:15:35 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/56 Message-ID: <057.86ca4d29ed54c1be14e57fe22ff95263@tools.ietf.org> X-Trac-Ticket-ID: 56 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] coap #56 (new): Distinguishing DTLS, CoAP and STUN X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 16:15:19 -0000 #56: Distinguishing DTLS, CoAP and STUN Section 10.2 need a discussion on how to tell the difference between DTLS and CoAP messages as the same port is used by default. -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: Type: enhancement | Status: new Priority: trivial | Milestone: Component: coap | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From cabo@tzi.org Sat Nov 6 09:54:29 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A46433A6895 for ; Sat, 6 Nov 2010 09:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SepdJUr1RuXc for ; Sat, 6 Nov 2010 09:54:28 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 481743A67DF for ; Sat, 6 Nov 2010 09:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id oA6Gsa9O028892; Sat, 6 Nov 2010 17:54:36 +0100 (CET) Received: from [10.40.72.1] (unknown [222.128.202.2]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 770E26F7; Sat, 6 Nov 2010 17:54:32 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Sun, 7 Nov 2010 00:53:10 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <057.7877dadaee8c1a49ad3c621003bde997@tools.ietf.org> To: Kerry Lynn X-Mailer: Apple Mail (2.1081) Cc: core issue tracker , core@ietf.org Subject: Re: [core] coap #52 (new): How strict to make POST definition? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 16:54:30 -0000 On Nov 6, 2010, at 20:54, Kerry Lynn wrote: > Now one thing I belive *is* a problem, and needs a new ticket, is the > inability of the underlying transaction model to treat POST in a non- > idempotent fashion. Figure 8 in draft-ietf-core-coap-03 shows the > client retying a GET in the case where the ACK is lost. How the server > treats this in the case of POST is unspecified. I believe this may = result > in the creation of *multiple* resources at the server. Maybe I don't understand your concern correctly. Figure 8 shows how a lost ACK is handled by the transaction layer. The mechanism shown also works for POST. A server that wants to offer at-most-once POST can use the transaction = ID to differentiate a retransmission from a new request. How it does this is indeed unspecified, but we rarely specify = implementation details. The semantics of a POST are defined by the resource/the server. Requiring the server to offer at-most-once POSTs would be an onus for = those applications that don't need that. We could go ahead and specify -- requirements on the time that must elapse before TID reuse by a = client (to avoid false positives) -- requirements on the time TID state is kept at a server (to avoid = false negatives) Do we need to? (Not a rhetorical question.) My ceterum censeo: Please talk about the use case you have in mind. (E.g., I have one use case for POST where the at-most-once semantics are = important enough to be realized in the application, so I wouldn't even = care if the server does them right or not.) Gruesse, Carsten From trac@tools.ietf.org Sat Nov 6 16:55:54 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 461813A68C7 for ; Sat, 6 Nov 2010 16:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7cURBwQtQGSi for ; Sat, 6 Nov 2010 16:55:52 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 64D633A68E7 for ; Sat, 6 Nov 2010 16:55:52 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PEscC-0006qE-Ba; Sat, 06 Nov 2010 16:56:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: cabo@tzi.org X-Trac-Project: core Date: Sat, 06 Nov 2010 23:56:08 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/56#comment:1 Message-ID: <066.48fe98aab404ccbab7c5768fc53ce7c7@tools.ietf.org> References: <057.86ca4d29ed54c1be14e57fe22ff95263@tools.ietf.org> X-Trac-Ticket-ID: 56 In-Reply-To: <057.86ca4d29ed54c1be14e57fe22ff95263@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] coap #56 (new): Distinguishing DTLS, CoAP and STUN X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 23:55:54 -0000 #56: Distinguishing DTLS, CoAP and STUN Comment(by cabo@…): DTLS UDP payloads begin with a byte out of enum { change_cipher_spec(20), alert(21), handshake(22), application_data(23), (255) } ContentType; i.e. 0x14 to 0x17. This would be decoded as a CoAP version 0. We have to make sure we never use that version, and we have to ask DTLS to reserve contenttypes (that's what they call the initial byte) outside of the range 0..63. Similarly, STUN messages begin with 0 0 binary (MSBs). Again, we have to avoid using CoAP version number 0. -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: Type: enhancement | Status: new Priority: trivial | Milestone: Component: coap | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From cabo@tzi.org Sat Nov 6 19:13:23 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AED203A6974 for ; Sat, 6 Nov 2010 19:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wCUJzkJGFEkX for ; Sat, 6 Nov 2010 19:13:22 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 6827C3A6961 for ; Sat, 6 Nov 2010 19:13:22 -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 oA72DVou028836 for ; Sun, 7 Nov 2010 03:13:31 +0100 (CET) Received: from dhcp-630a.meeting.ietf.org (dhcp-630a.meeting.ietf.org [130.129.99.10]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 6078F754; Sun, 7 Nov 2010 03:13:30 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <523C7286-C01F-4AD0-A4E7-3E61AE7F9991@cisco.com> Date: Sun, 7 Nov 2010 10:13:25 +0800 Content-Transfer-Encoding: 7bit Message-Id: References: <523C7286-C01F-4AD0-A4E7-3E61AE7F9991@cisco.com> To: core X-Mailer: Apple Mail (2.1081) Subject: Re: [core] AD-Hoc Plug Fest Room For Sunday X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 02:13:23 -0000 We have started to assemble in Jade 1. This is on the third floor of the Valley Wing, a little hard to find. See also: http://www.ietf.org/meeting/79/floor-plans.pdf During the plugfest, we'll share information on the following Etherpad: http://piratenpad.de/6zxaHcV8my Gruesse, Carsten From cabo@tzi.org Sat Nov 6 20:14:00 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 473003A69B5 for ; Sat, 6 Nov 2010 20:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CpohrI1QF6qd for ; Sat, 6 Nov 2010 20:13:59 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 0CA073A69A7 for ; Sat, 6 Nov 2010 20:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id oA73E7LQ009143 for ; Sun, 7 Nov 2010 04:14:07 +0100 (CET) Received: from dhcp-74d4.meeting.ietf.org (dhcp-74d4.meeting.ietf.org [130.129.116.212]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id BDF52756; Sun, 7 Nov 2010 04:14:06 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Sun, 7 Nov 2010 11:14:02 +0800 Content-Transfer-Encoding: 7bit Message-Id: <8EAFDDF9-8355-4EA2-BC9F-E2513F3DC4C6@tzi.org> References: <523C7286-C01F-4AD0-A4E7-3E61AE7F9991@cisco.com> To: core X-Mailer: Apple Mail (2.1081) Subject: Re: [core] AD-Hoc Plug Fest Room For Sunday X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 03:14:00 -0000 On Nov 7, 2010, at 10:13, Carsten Bormann wrote: > http://piratenpad.de/6zxaHcV8my We seem to have blown the little brain of that server. Info is at: http://trac.tools.ietf.org/wg/core/trac/wiki/PlugFest Gruesse, Carsten From fluffy@cisco.com Sat Nov 6 20:19:11 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A36303A69A8 for ; Sat, 6 Nov 2010 20:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IP9PKFJy0JW1 for ; Sat, 6 Nov 2010 20:19:10 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id D7BA23A6974 for ; Sat, 6 Nov 2010 20:19:10 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAu31UyrR7H+/2dsb2JhbACiCXGfWZpIhUgEhFiFfYMK X-IronPort-AV: E=Sophos;i="4.58,308,1286150400"; d="scan'208";a="282087557" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 07 Nov 2010 03:19:28 +0000 Received: from [192.168.4.2] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id oA73JDwr022794; Sun, 7 Nov 2010 03:19:27 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <057.5a0b47dd50a974001be4384c2bf76521@tools.ietf.org> Date: Sat, 6 Nov 2010 21:19:46 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <057.5a0b47dd50a974001be4384c2bf76521@tools.ietf.org> To: core issue tracker X-Mailer: Apple Mail (2.1081) Cc: core@ietf.org Subject: Re: [core] link-format #42 (new): Finalize the link-extensions to define X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 03:19:11 -0000 On Nov 6, 2010, at 3:32 AM, core issue tracker wrote: > Extensions to consider for removal: >=20 > - sh "Short URL": Is this really in use? So far it seems people = instead > just make short URLs in the first place. Suggestion to remove. +1=20 >=20 > Extensions to consider for addition: >=20 > - obs "Observation flag": A link-extension (with no value part) that = when > present indicates that this resource supports observation. seems reasonable=20 >=20 > - size "Size estimate": Indicates the estimated size for larger = resources > that will likely require block transfer. It might be better to have a "max-size" that mean this resource will = never be larger than this size.=20 From fluffy@cisco.com Sat Nov 6 20:19:54 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8661A3A6974 for ; Sat, 6 Nov 2010 20:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Fv7-EsTwiY2 for ; Sat, 6 Nov 2010 20:19:53 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id CBBD63A69A8 for ; Sat, 6 Nov 2010 20:19:52 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADe41UyrR7H+/2dsb2JhbACiCXGfZJpLhUgEhFiFfYMK X-IronPort-AV: E=Sophos;i="4.58,308,1286150400"; d="scan'208";a="282087698" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 07 Nov 2010 03:20:10 +0000 Received: from [192.168.4.2] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id oA73JDws022794; Sun, 7 Nov 2010 03:20:09 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=windows-1252 From: Cullen Jennings In-Reply-To: <066.48fe98aab404ccbab7c5768fc53ce7c7@tools.ietf.org> Date: Sat, 6 Nov 2010 21:20:27 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <3F87B418-9936-48D1-9C1D-4082E7B8B42F@cisco.com> References: <057.86ca4d29ed54c1be14e57fe22ff95263@tools.ietf.org> <066.48fe98aab404ccbab7c5768fc53ce7c7@tools.ietf.org> To: core issue tracker X-Mailer: Apple Mail (2.1081) Cc: core@ietf.org Subject: Re: [core] coap #56 (new): Distinguishing DTLS, CoAP and STUN X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 03:19:54 -0000 Section 5.1.2 of RFC 5764 discusses the demux of RTP / DTLS / STUN. It = seems to me that if COAP stepped on top of the same code points as RTP, = it would be very unlikely to conflict with future exertions of STUN or = DTLS because theses protocols will have big problems if they step on top = of RTP.=20 On Nov 6, 2010, at 5:56 PM, core issue tracker wrote: > #56: Distinguishing DTLS, CoAP and STUN >=20 >=20 > Comment(by cabo@=85): >=20 > DTLS UDP payloads begin with a byte out of >=20 > enum { > change_cipher_spec(20), alert(21), handshake(22), > application_data(23), (255) > } ContentType; >=20 > i.e. 0x14 to 0x17. > This would be decoded as a CoAP version 0. We have to make sure we = never > use that version, and we have to ask DTLS to reserve contenttypes = (that's > what they call the initial byte) outside of the range 0..63. >=20 > Similarly, STUN messages begin with 0 0 binary (MSBs). Again, we have = to > avoid using CoAP version number 0. >=20 > --=20 > = --------------------------------+-----------------------------------------= -- > Reporter: zach@=85 | Owner: =20 > Type: enhancement | Status: new > Priority: trivial | Milestone: =20 > Component: coap | Version: =20 > Severity: - | Keywords: =20 > = --------------------------------+-----------------------------------------= -- >=20 > Ticket URL: = > core >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From fluffy@cisco.com Sat Nov 6 20:20:06 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65F003A6974 for ; Sat, 6 Nov 2010 20:20:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.269 X-Spam-Level: X-Spam-Status: No, score=-110.269 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OaTUEoZuJzyh for ; Sat, 6 Nov 2010 20:20:05 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 613B23A69C0 for ; Sat, 6 Nov 2010 20:20:05 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADe41UyrR7H+/2dsb2JhbACiCXGfZJpLhUgEhFiFfYMK X-IronPort-AV: E=Sophos;i="4.58,308,1286150400"; d="scan'208";a="282087728" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 07 Nov 2010 03:20:22 +0000 Received: from [192.168.4.2] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id oA73JDwt022794 for ; Sun, 7 Nov 2010 03:20:21 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 6 Nov 2010 21:20:39 -0600 Message-Id: <6206EA80-23B4-45B1-BCAE-23AFADD90FC1@cisco.com> To: core Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [core] media types in draft-ietf-core-coap X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 03:20:06 -0000 This is a pretty minor point in the overall design so I have been = ignoring it for awhile but seems like it is about time to mention it.=20 Many the media types in Table 4 have one thing in common. Many of them = are useless as media types and never should have been approved as = media/types in the first place. Take text/xml or application/xml. The = fact we can't even tell if is is text or an application is telling. And = what does it mean? What can you do with these bits? What application do = you hand them too? How do you interpret them?There is no information = that helps answer that in this media type. If an device receiving this = knew the answer to these questions, then it would not need the media = type in the first place. It's as useless as media type that indicated = that the words where 8 bits long. Imagine application/8bit - it's just = not helpful. Now that I look I see we actually have that media type - = it's called application/octet-stream. Seriously, why bother. The more = you think about it, the situation is about the same for application/xml = - yep, there will be angle brackets in the data but you still don't know = what to do with it any more than what you did with application/8bit. For = some of the types, such as image/jpeg, it is clear and you do know what = the media types is and how you can interpret the bits you find inside. = But when we get to audio/raw, it's again close to useless without = knowing how bits the samples where and what the same rate was, how many = channels there were and how they were interlaced.=20 My suggestion is we update table 4 to have a column that is a reference = to a spec that describes the semantic meaning of the information that = one will find in this type of data. For types that do not have semantic = meaning but are only a formatting container for some structure data = inside of them, we do not put them in the table. So if some other = organization defined a XML based format for caring power readings from a = smart energy meter, it would be fine to have something like = application/smart-energy-meter+xml but something that provide no real = information about the contained data, such as as = application/octet-stream does not go in the table. Remember that it fine = to send a message with no Content-Type option for cases where it's just = some bits and both ends know what to do with the bits.=20 From fluffy@cisco.com Sat Nov 6 20:20:09 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 347A13A69C5 for ; Sat, 6 Nov 2010 20:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.544 X-Spam-Level: X-Spam-Status: No, score=-110.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JW7-P4g8LWq6 for ; Sat, 6 Nov 2010 20:20:08 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 5BF4E3A69C4 for ; Sat, 6 Nov 2010 20:20:08 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am0KADe41UyrR7H+/2dsb2JhbAAcoW1xn2SaS4VIBIRYhX2DCg X-IronPort-AV: E=Sophos;i="4.58,308,1286150400"; d="scan'208";a="282087736" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 07 Nov 2010 03:20:25 +0000 Received: from [192.168.4.2] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id oA73JDwu022794 for ; Sun, 7 Nov 2010 03:20:25 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 6 Nov 2010 21:20:44 -0600 Message-Id: <1974BED3-B0CA-441D-8446-1F9C73CFE6BB@cisco.com> To: core Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [core] draft-ietf-core-block - how long to hold fragments X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 03:20:09 -0000 How long does a node that is reassembling some data have to hold onto = blocks?=20 From fluffy@cisco.com Sat Nov 6 20:20:34 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 431913A69B3 for ; Sat, 6 Nov 2010 20:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.549 X-Spam-Level: X-Spam-Status: No, score=-110.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mL9PjTgMYCiC for ; Sat, 6 Nov 2010 20:20:33 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 6D3423A69A8 for ; Sat, 6 Nov 2010 20:20:33 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADe41UyrR7H+/2dsb2JhbACiCXGfZJpLhUgEhFiFfYMK X-IronPort-AV: E=Sophos;i="4.58,308,1286150400"; d="scan'208";a="213088197" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 07 Nov 2010 03:20:50 +0000 Received: from [192.168.4.2] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id oA73JDwv022794 for ; Sun, 7 Nov 2010 03:20:50 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 6 Nov 2010 21:21:09 -0600 Message-Id: <9301DC58-C649-4ECF-B2B9-D093FA86BDDC@cisco.com> To: core Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [core] draft-ietf-core-link-format X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 03:20:34 -0000 Section 2.5=20 Is there any particular list of ontologies you might suggest people = consider using? From fluffy@cisco.com Sat Nov 6 20:20:39 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADFCD3A69CB for ; Sat, 6 Nov 2010 20:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.553 X-Spam-Level: X-Spam-Status: No, score=-110.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hzWS5mp2QcVJ for ; Sat, 6 Nov 2010 20:20:38 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id A719C3A69B3 for ; Sat, 6 Nov 2010 20:20:38 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADe41UyrR7H+/2dsb2JhbACiCXGfZJpLhUgEhFiFfYMK X-IronPort-AV: E=Sophos;i="4.58,308,1286150400"; d="scan'208";a="282087843" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 07 Nov 2010 03:20:56 +0000 Received: from [192.168.4.2] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id oA73JDww022794 for ; Sun, 7 Nov 2010 03:20:55 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 6 Nov 2010 21:21:14 -0600 Message-Id: <05D7FB47-E2DC-4F73-B9F7-551E9251FF23@cisco.com> To: core Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [core] draft-oflynn-core-bootstrapping X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 03:20:39 -0000 Big question: Lots of good stuff but I think we need to start narrow in on what we = need to specify to actually go and implement this. For example, say I = have a device with a button and LED, what do I need to implement so that = the user can take that device and get to the point where the "bootstrap" = is complete and all the information needed to security run COAP is = there. I realize that is probably a bunch of different things and = different use cases but at some point we need to be clear about what a = device need to implement and how it will be secure.=20 Few minor things.=20 It mention SE2.0 has devices be programmed with a certificate. What the = trust root for theses?=20 HIP I assume we are talking about the rfc4843-bis style ORCHIDs here which = thought they are 182 bits long, 28 of those bits get fixed so you really = have 100 bits of hash resulting in a much smaller search space for = collisions. It would be worth thinking about how long theses would = remain security given current estimates. There must be some reasons that = these are written up an experiment that ends in 2014 if not explicitly = renewed.=20 From cabo@tzi.org Sat Nov 6 20:51:53 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FFA33A6978 for ; Sat, 6 Nov 2010 20:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2szG+NIT722z for ; Sat, 6 Nov 2010 20:51:52 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id BF7013A6990 for ; Sat, 6 Nov 2010 20:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id oA73px2j016979; Sun, 7 Nov 2010 04:51:59 +0100 (CET) Received: from dhcp-74d4.meeting.ietf.org (dhcp-74d4.meeting.ietf.org [130.129.116.212]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id E20BD758; Sun, 7 Nov 2010 04:51:57 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <3F87B418-9936-48D1-9C1D-4082E7B8B42F@cisco.com> Date: Sun, 7 Nov 2010 11:51:53 +0800 Content-Transfer-Encoding: 7bit Message-Id: References: <057.86ca4d29ed54c1be14e57fe22ff95263@tools.ietf.org> <066.48fe98aab404ccbab7c5768fc53ce7c7@tools.ietf.org> <3F87B418-9936-48D1-9C1D-4082E7B8B42F@cisco.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1081) Cc: core issue tracker , core@ietf.org Subject: Re: [core] coap #56 (new): Distinguishing DTLS, CoAP and STUN X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 03:51:53 -0000 On Nov 7, 2010, at 11:20, Cullen Jennings wrote: > if COAP stepped on top of the same code points as RTP That would mean advancing CoAP to version 2. Not something we want to do lightly with all the implementations out there. (I'd also rather stay at 1 and be able to distinguish RTP and CoAP, too.) Gruesse, Carsten From zach@sensinode.com Sat Nov 6 21:25:21 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C2563A69E4 for ; Sat, 6 Nov 2010 21:25:21 -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_72=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VA-0uFQaI2Gj for ; Sat, 6 Nov 2010 21:25:20 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id A540B3A69D2 for ; Sat, 6 Nov 2010 21:25:18 -0700 (PDT) Received: from dhcp-8719.meeting.ietf.org (dhcp-8719.meeting.ietf.org [130.129.135.25]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id oA74PN0S001975 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 7 Nov 2010 06:25:30 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-29--588405825; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: <066.48fe98aab404ccbab7c5768fc53ce7c7@tools.ietf.org> Date: Sun, 7 Nov 2010 12:25:22 +0800 Message-Id: <77932BA3-58DE-4553-915F-CB44E0032372@sensinode.com> References: <057.86ca4d29ed54c1be14e57fe22ff95263@tools.ietf.org> <066.48fe98aab404ccbab7c5768fc53ce7c7@tools.ietf.org> To: core issue tracker X-Mailer: Apple Mail (2.1081) Cc: core@ietf.org Subject: Re: [core] coap #56 (new): Distinguishing DTLS, CoAP and STUN X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 04:25:21 -0000 --Apple-Mail-29--588405825 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Nov 7, 2010, at 7:56 AM, core issue tracker wrote: > #56: Distinguishing DTLS, CoAP and STUN >=20 >=20 > Comment(by cabo@=85): >=20 > DTLS UDP payloads begin with a byte out of >=20 > enum { > change_cipher_spec(20), alert(21), handshake(22), > application_data(23), (255) > } ContentType; >=20 > i.e. 0x14 to 0x17. > This would be decoded as a CoAP version 0. We have to make sure we = never > use that version, and we have to ask DTLS to reserve contenttypes = (that's > what they call the initial byte) outside of the range 0..63. >=20 > Similarly, STUN messages begin with 0 0 binary (MSBs). Again, we have = to > avoid using CoAP version number 0. Thanks for checking that ;-) I will include this information into the = security section of coap-04. And we need to mention that version 0 can = not (and will not) be used for this reason. >=20 > --=20 > = --------------------------------+-----------------------------------------= -- > Reporter: zach@=85 | Owner: =20 > Type: enhancement | Status: new > Priority: trivial | Milestone: =20 > Component: coap | Version: =20 > Severity: - | Keywords: =20 > = --------------------------------+-----------------------------------------= -- >=20 > Ticket URL: = > core >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 --Apple-Mail-29--588405825 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9 fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb 6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja 5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I 2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTEwNzA0MjUy M1owIwYJKoZIhvcNAQkEMRYEFHkO/TsTCKxQDPTBNA2XofSpNZVVMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAH1s5f4W5jple3HlqQzFPYe6FnkiUA3Xx2QbYejuH+vziUHBcOzdFQ8x rDsurxYhZosIBTReN1QvqAoUycW7mPM4PcD5qpZX/FVyxYFNvuvuXoCZGp2/orBOnyFdXEOtg5Tt 7VPkX0YNpjrCA+gChM8do8wK5X4b7/rsz6O9bBZlBATiZJ9SkruxPPKcrO7bece1HTLPzWAnBqhV Zp7zyHoPRJIPiIBAe/jrXaJWWApMF1nLXrecHTx+BN8CzDNkLl8cNEDb1m4FrmWXMNGEYzbqCjzZ sUAHs/rj1/bBcgKj2q+KLiLjBuSvvzz9mw4mzTTC30tW/ZutUOOdY7FDfJsAAAAAAAA= --Apple-Mail-29--588405825-- From zach@sensinode.com Sat Nov 6 21:30:18 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DB1D3A6978 for ; Sat, 6 Nov 2010 21:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvvJLUJFWAVc for ; Sat, 6 Nov 2010 21:30:17 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 658723A69AC for ; Sat, 6 Nov 2010 21:30:17 -0700 (PDT) Received: from dhcp-8719.meeting.ietf.org (dhcp-8719.meeting.ietf.org [130.129.135.25]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id oA74URpQ002016 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 7 Nov 2010 06:30:31 +0200 From: Zach Shelby Content-Type: multipart/signed; boundary=Apple-Mail-30--588102161; protocol="application/pkcs7-signature"; micalg=sha1 Date: Sun, 7 Nov 2010 12:30:26 +0800 Message-Id: <07D7755F-6A3D-4413-90DD-CB632FCD9400@sensinode.com> To: core Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [core] Plugfest lunch today at 13 in Nishimura X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 04:30:18 -0000 --Apple-Mail-30--588102161 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Those of us at the CoRE plugfest are having lunch at the Japanese = restaurant (Garden Wing, Level 2) at 13 today. If other CoRE people = around at the IETF want to join us you're welcome!=20 Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 --Apple-Mail-30--588102161 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9 fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb 6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja 5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I 2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTEwNzA0MzAy N1owIwYJKoZIhvcNAQkEMRYEFK0vEE2JNbb0TL0QXEOoSPZLaHlzMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBABc2tV3VlM/ndA9EwyLd6BXKCKqQPB7C0xA60UfkcWQDSqHVWkP6KrvU orYSzHxGNfN5cUL2M71W/ZA0xEhXoJyhuiSuTunrwn+LSIFXGtFnPERHnvHseHN3TQhDNTjXi8C1 8RVgUX4Z3ZW09Gh8tQO4rc0S5MN1dAL0h3gsrvCySqV3xNdlcnQRZjfCfnObUZVHiYIFJA8YiJDs hpiR71tWrg/lxYBt4DSFsgaQ/GO4IfQOllXlVT2R9edtjWaYGi18biL8FHwTQ1x/ozpSxQMiQ+L7 5AijT9Sku62OthUTCChU4Yk3p9FeEA6/XGellrtOcYCCGDgQegWOOe0byisAAAAAAAA= --Apple-Mail-30--588102161-- From trac@tools.ietf.org Sat Nov 6 21:39:35 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33B523A69EE for ; Sat, 6 Nov 2010 21:39:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k8pRAPrAoZny for ; Sat, 6 Nov 2010 21:39:32 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id C1A3128C0FC for ; Sat, 6 Nov 2010 21:39:31 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PEx2i-0000of-DK; Sat, 06 Nov 2010 21:39:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Sun, 07 Nov 2010 04:39:48 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/57 Message-ID: <057.dc5d58539b472c717336f800047ad3f5@tools.ietf.org> X-Trac-Ticket-ID: 57 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] link-format #57 (new): Cyclical links X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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 Nov 2010 04:39:35 -0000 #57: Cyclical links The security section should discuss the issue of cyclical links. Clients parsing the link-format should be aware that /.well-known/core could include a link to itself (although not necessary). -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: Type: enhancement | Status: new Priority: trivial | Milestone: Component: link-format | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From zach@sensinode.com Sun Nov 7 06:18:16 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2671A3A676A for ; Sun, 7 Nov 2010 06:18:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VIzm3QEfY74N for ; Sun, 7 Nov 2010 06:18:15 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 9E52C3A63CB for ; Sun, 7 Nov 2010 06:18:14 -0800 (PST) Received: from dhcp-40a3.meeting.ietf.org (dhcp-40a3.meeting.ietf.org [130.129.64.163]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id oA7EIG9u009917 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 7 Nov 2010 16:18:26 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-53--552832401; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: Date: Sun, 7 Nov 2010 22:18:16 +0800 Message-Id: References: <057.7877dadaee8c1a49ad3c621003bde997@tools.ietf.org> To: Kerry Lynn X-Mailer: Apple Mail (2.1081) Cc: core issue tracker , core@ietf.org Subject: Re: [core] coap #52 (new): How strict to make POST definition? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 14:18:16 -0000 --Apple-Mail-53--552832401 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Kerry, On Nov 6, 2010, at 8:54 PM, Kerry Lynn wrote: > If we want coap POST to be more like 2616, then I think language like > "The actual function performed by the POST method is determined by > the server and is usually dependent on the Request-URI" needs to be > *added*. This will provide the backdoor RPC capability that many so- > called RESTful designs depend on (IOW, using POST more like "invoke" > than "append"). You are right, I agree the original comment that started this thread = really doesn't have to do with your added words (my mistake). But you do = bring up a good point here. I think it would be a good idea to add that = sentence in order to bring this in line with the RFC2616 definition. = Will be proposed in tomorrow's CoAP WG slides.=20 Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 --Apple-Mail-53--552832401 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9 fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb 6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja 5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I 2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTEwNzE0MTgx NlowIwYJKoZIhvcNAQkEMRYEFBguVt2z2ceXB7Um74hC98KvjEn1MIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBACF4Nv7WzpmLKcZla8XUxsLAtlWRrPloTSWt+yyWdCapEvDEgQSD/QoG TsR3z+awj2Szd4dXQ/gtjovwAt3gZqbiyoUHRpPqx/P8eN9/vuSAseXXRXORkvUS3cpFHKiIayRH eNmQRZu13jcssBhF6GpGsDDJALp/1zg4ESckeBXxzlm/F8oZaP3rpX3kbUpOjFBlDrZ3H/ZxCl7D Xau+KAWqPbyMyaLThCgwtpNre5QQS9l/BdwspLmLRhDzFbpxZEEtGr1vEKEx2OWyvbEJQYPHH1DU l3FQYfeeKDhNu2WauQGY82vYa2ojydeSUW9n7SJrzxkAwEiZGbebIVrznDEAAAAAAAA= --Apple-Mail-53--552832401-- From trac@tools.ietf.org Sun Nov 7 06:44:42 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FE973A67AD for ; Sun, 7 Nov 2010 06:44:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4pG2IrjD6i3 for ; Sun, 7 Nov 2010 06:44:41 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 6B57F3A67A4 for ; Sun, 7 Nov 2010 06:44:41 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PF6UN-0002Ar-Ll; Sun, 07 Nov 2010 06:44:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Sun, 07 Nov 2010 14:44:59 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/55#comment:1 Message-ID: <066.63fb91dca55d084a2befe44dbc7ac046@tools.ietf.org> References: <057.cbcb8082fb49a1a254def976b454a663@tools.ietf.org> X-Trac-Ticket-ID: 55 In-Reply-To: <057.cbcb8082fb49a1a254def976b454a663@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] coap #55 (new): AES-CCM vs. AES-CBC X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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 Nov 2010 14:44:42 -0000 #55: AES-CCM vs. AES-CBC Comment(by zach@…): DTLS [RFC4347] does not current support Authenticated Encryption with Additional Data (AEAD) cyphers like CCM. AEAD support was added to TLS 1.2 but this is no currently defined with DTLS. (Thanks to Robert Cragie for pointing that out) Proposal is to encourage TLS working group to add TLS 1.2 support to DTLS. -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: Type: enhancement | Status: new Priority: trivial | Milestone: Component: coap | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From trac@tools.ietf.org Sun Nov 7 06:45:45 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBB253A67A4 for ; Sun, 7 Nov 2010 06:45:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fb-1GKBA6xP7 for ; Sun, 7 Nov 2010 06:45:44 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id BA6B53A67A6 for ; Sun, 7 Nov 2010 06:45:43 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PF6VO-0002ME-Gd; Sun, 07 Nov 2010 06:46:02 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Sun, 07 Nov 2010 14:46:02 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/28#comment:1 Message-ID: <066.b40acb2c34e342f6e9767a6f0a736976@tools.ietf.org> References: <057.548fe514a79c88899d8aba947024686a@tools.ietf.org> X-Trac-Ticket-ID: 28 In-Reply-To: <057.548fe514a79c88899d8aba947024686a@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] coap #28 (new): Clarification on retransmission X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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 Nov 2010 14:45:45 -0000 #28: Clarification on retransmission Comment(by zach@…): The conclusion from mailing list discussions was that in some cases more memory efficient to send current state (rather than saving snapshot). Proposal: Change Section 4.3 with “MAY include the current snapshot†and an explanation. -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: Type: enhancement | Status: new Priority: trivial | Milestone: Component: coap | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From alper.yegin@yegin.org Sun Nov 7 08:51:50 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5CDD3A67F6 for ; Sun, 7 Nov 2010 08:51:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.149 X-Spam-Level: X-Spam-Status: No, score=-101.149 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PwYiGhDASJ4e for ; Sun, 7 Nov 2010 08:51:36 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 8692E3A67AB for ; Sun, 7 Nov 2010 08:51:36 -0800 (PST) Received: from ibm ([211.154.201.18]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0LqhqM-1OapuK0T0U-00eWNv; Sun, 07 Nov 2010 11:51:54 -0500 From: "Alper Yegin" To: "'Rene Struik'" , "'Carsten Bormann'" References: <935DB371-B149-486A-8AD2-3B4454C9B172@tzi.org> <4CA3BB54.8050706@gmail.com> <4CA5E8E0.4030503@gmail.com> <4CA6095F.6040403@gmail.com> <4CB48B9B.9010206@gmail.com> <4CC83F61.5060109@gmail.com> <023a01cb76e1$869bfcc0$93d3f640$@yegin@yegin.org> <4CC9EB4B.7040802@gmail.com> In-Reply-To: <4CC9EB4B.7040802@gmail.com> Date: Sun, 7 Nov 2010 18:51:42 +0200 Message-ID: <011001cb7e9c$14567740$3d0365c0$@yegin@yegin.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0111_01CB7EAC.D7DF4740" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Act250u3YAOdsZCXRSuykTXwsCcaOgHsvWMQ Content-Language: en-us X-Provags-ID: V02:K0:uVfwyQMixKOCklaVSQXGso6OfmtoQP1nJ+u5oUYALGv V8GgIecnB/a4OxvWdQhYSXVDgcFoFIDG2SLEnuhJsrZ8BSdfiU ZB3R4u29xFkD5xbNjBZHmfNGRoMaBk4s+fP4ICqFrxtLXxB1Ro zq+OxOu8VkGxJFaFqkSUC2TOT3aCTMq2LgO/rmkds7P5lEP+0s Cz6wf6EX6zatYEGLsz+RwY7FvTJ3MQ5zNrT2u0EZIA= Cc: 'core' Subject: Re: [core] concerns re draft-oflynn-core-bootstrapping-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 16:51:50 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0111_01CB7EAC.D7DF4740 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sorry about the late response. I'm still not 100% sure I understand the question/issue, but let me say the following and see if it helps. PAA is located on a node that acts as NAS (Network Access Server). If there are nodes with different trust anchors that need to be authenticated, NAS would be in charge of contacting the individual trust anchors for each authentication procedure. For example, NAS could be using RADIUS for talking with those trust anchors. PANA has nothing to do with that part. Please see RFC 5193 to see how these protocols come together to form a generic architecture. If the NAS can act as the trust anchor (because it holds the credential database, or using public key certificates [and does not care about OCSP/CRL ??]), then it can be offline. But, again, this has nothing to do with PANA. PANA gets EAP packets back and forth between the joining node and NAS. How NAS performs authentication (whether by itself, or offloads to a AAA server) is invisible to PANA. . I didn't understand the issue about "move from one mothership to the next" at all to comment on it. Regards, Alper From: Rene Struik [mailto:rstruik.ext@gmail.com] Sent: Friday, October 29, 2010 12:30 AM To: Alper Yegin Cc: 'core' Subject: Re: [core] concerns re draft-oflynn-core-bootstrapping-02 Hi Alper: With "mothership" I meant to indicate a node that serves as security manager for a collection of nodes. There are of course different granularities in what the security manager role entails. In ZigBee, the mothership node would be "the" trust center. I hope this helps. Rene On 28/10/2010 4:48 PM, Alper Yegin wrote: Hello, Similarly, e.g., PANA does not seem to work in heterogeneous trust environments, assumes online connectivity of a "mothership" node, and does not seem to include consideration of how to move from one mothership node to the next (or, e.g., if one has an authenticator, how to make this work with single-hop/MAC security). Can you please elaborate on what "mothership" node is. Alper Dear colleagues: I had a brief look at the bootstrapping draft (draft-oflynn-core-bootstrapping-02. Some comments below (I am having some offline discussions on this, but thought to send this to the list as well): I miss a detailed analysis of deployment scenarios to be considered as guidance into design, so as to have as very minimal benchmark whether all those crypto protocols actually enable the deployment scenarios one has in mind. To me, it seems to have merit to discuss the whole spectrum and end up with cryptographic building blocks, security protocols, and security policies and accompanying enforcement mechanism for trust policies that would fit the operational scenarios. I would favor not sprinkling protocol acronyms into any draft too early (since, in my mind, this pushes into a particular direction, and not always with merit). As an example, right now I do not see how, e.g., HIP or cryptographically generated addresses (802.1-like) would fit in. Similarly, e.g., PANA does not seem to work in heterogeneous trust environments, assumes online connectivity of a "mothership" node, and does not seem to include consideration of how to move from one mothership node to the next (or, e.g., if one has an authenticator, how to make this work with single-hop/MAC security). I also miss security objectives and design considerations, such as "separation of concern" and no entanglement of concepts from different disciplines in the document. BTW - I mentioned some of this in email correspondence after the last CoRE conf call (Wed September 29, 2010). So far, I have not seen too much traffic on this. Moreover, I have not seen any adequate answers as to what makes, e.g., HIP features an attractive fit for CoRE-like environments. Best regards, Rene [excerpt email RS as of October 1, 2010, 12:16pm EDT] In my mind, properties of suitable authenticated key agreement schemes should include (a) key establishment; (b) implicit key authentication; (c) key confirmation; (d) mutual entity authentication; (e) forward secrecy; (f) {perhaps} some more esoteric properties (key compromise impersonation resilience, etc.). Moreover, the "name space" (device identifiers) and the "cryptographic space" (public keys, etc.) should be independent, so that this would allow trust lifecycle management to be reduced to proper management of device identifiers (i.e., *no* entanglement of concepts from different disciplines). On 12/10/2010 12:23 PM, Rene Struik wrote: Hi Tobias: Thanks for your note. Does your "ascii art" description, Step 1)-3) allow the scenario, where (a) one assigns a node id and imprints this (e.g., blowing fuse during chip testing); (b) has a node generating its own long-term public/private key pair and outputting its node id and public key (e.g., during chip testing -- this would correspond to registering a public key with an RA); (c) have CA create a certificate in different process and return this value at later production/ personalization stage? Right now, from Section 4.1.3 of draft-ietf-hip-rfc5201-bis-02, I get the impression that HIP does execute an authenticated DH key agreement scheme. If so, this makes me wonder how HIP differentiates from protocols, such as ECMQV and, e.g., HMQV, which are all not that much more expensive than ECDH. If the difference is in the "puzzle" element, couldn't one just add something similar to a well-known authenticated scheme that is already standardized with, e.g., NIST? As to forward secrecy: reason to include this is that many sensor-type nodes can be expected to be physically unprotected (e.g., screwed on a street lamp post, on a garage roof, etc.) and, therefore, may be more vulnerable to device compromise over time (esp. since one cannot expect all nodes to be tamper resistant or tamper evident). By virtue of forward secrecy, compromise over time does not compromise the whole device's history, but only the current set of symmetric keys (note: I make some shortcuts in my reasoning on key management here). Admittedly, my list of security properties is based on "desired" functionality and does not exclude functionality that may require, e.g., public-key crypto constructs. However, from a user's perspective, the only thing that matters is features and not what is "under the hood", as long as that is not cost-prohibitive (which I contend it is not -- cf., e.g., Section 3.2 of draft-struik-6lowapp-security-considerations-00). (BTW - All other desired security properties I listed have an underlying rationale.) It would help to have a succinct mathematical description of the protocol you suggest (stripped from formatting issues) and describe claimed cryptographic properties. I would be happy to give this a look and review. Please feel free to provide to me in person if this would be cumbersome material for non-crypto people on the mailing list. Best regards, Rene [excerpt email RS as of October 1, 2010, 12:16pm EDT and response Tobias Heer as of October 7, 2010, 5:36am EDT] To aid clarity and succinct discussions, it would help to have a clear description of desired security services to be offered by an authenticated key agreement scheme and see whether a candidate scheme (such as, who knows, HIP) satisfies these. If you could provide a succinct description of the HIP protocol itself, so that this is easy to understand, and could provide what properties it has, that would be of great help! > > In my mind, properties of suitable authenticated key agreement schemes should include (a) key establishment; (b) implicit key authentication; (c) key confirmation; (d) mutual entity authentication; (e) forward secrecy; (f) {perhaps} some more esoteric properties (key compromise impersonation resilience, etc.). > Is this list valid for all targeted use cases? If yes, it is a very handy list to check against. However, (e) forward secrecy seems to rule a number of "cheaper" cryptographic approaches (e.g., pre-shared keys) and might not be relevant to all use cases (especially small setups). However, I am not absolutely firm with the envisaged scenarios in CORE. > Moreover, the "name space" (device identifiers) and the "cryptographic space" (public keys, etc.) should be independent, so that this would allow trust lifecycle management to be reduced to proper management of device identifiers (i.e., *no* entanglement of concepts from different disciplines). Does the "*no* entanglement of concepts from different disciplines" also mean that a concept like the id/loc split should be used to avoid entanglement of routing and naming? On 07/10/2010 5:36 AM, Tobias Heer wrote: To aid clarity and succinct discussions, it would help to have a clear description of desired security services to be offered by an authenticated key agreement scheme and see whether a candidate scheme (such as, who knows, HIP) satisfies these. If you could provide a succinct description of the HIP protocol itself, so that this is easy to understand, and could provide what properties it has, that would be of great help! > > In my mind, properties of suitable authenticated key agreement schemes should include (a) key establishment; (b) implicit key authentication; (c) key confirmation; (d) mutual entity authentication; (e) forward secrecy; (f) {perhaps} some more esoteric properties (key compromise impersonation resilience, etc.). > Is this list valid for all targeted use cases? If yes, it is a very handy list to check against. However, (e) forward secrecy seems to rule a number of "cheaper" cryptographic approaches (e.g., pre-shared keys) and might not be relevant to all use cases (especially small setups). However, I am not absolutely firm with the envisaged scenarios in CORE. > Moreover, the "name space" (device identifiers) and the "cryptographic space" (public keys, etc.) should be independent, so that this would allow trust lifecycle management to be reduced to proper management of device identifiers (i.e., *no* entanglement of concepts from different disciplines). Does the "*no* entanglement of concepts from different disciplines" also mean that a concept like the id/loc split should be used to avoid entanglement of routing and naming? -- email: rstruik.ext@gmail.com Skype: rstruik cell: +1 (647) 867-5658 USA Google voice: +1 (415) 690-7363 -- email: rstruik.ext@gmail.com Skype: rstruik cell: +1 (647) 867-5658 USA Google voice: +1 (415) 690-7363 -- email: rstruik.ext@gmail.com Skype: rstruik cell: +1 (647) 867-5658 USA Google voice: +1 (415) 690-7363 ------=_NextPart_000_0111_01CB7EAC.D7DF4740 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Sorry about the late response.

    I’m still not 100% sure I understand the = question/issue, but let me say the following and see if it helps.

     

    PAA is located on a node that acts as NAS (Network Access Server). If there are nodes with different trust anchors that need to be authenticated, NAS would be in charge of contacting the individual trust anchors for each authentication procedure. For example, NAS could be = using RADIUS for talking with those trust anchors. PANA has nothing to do with = that part. Please see RFC 5193 to see how these protocols come together to = form a generic architecture.

     

    If the NAS can act as the trust anchor (because it holds = the credential database, or using public key certificates [and does not care = about OCSP/CRL ??]), then it can be offline. But, again, this has nothing to = do with PANA. PANA gets EAP packets back and forth between the joining node and = NAS. How NAS performs authentication (whether by itself, or offloads to a AAA server) is invisible to PANA.

     

    …

     

    I didn’t understand the issue about “move = from one mothership to the next” at all to comment on = it.

     

    Regards,

     

    Alper

     

     

     

     

     

     

     

     

     

     

    From: Rene Struik [mailto:rstruik.ext@gmail.com]
    Sent: Friday, October 29, 2010 12:30 AM
    To: Alper Yegin
    Cc: 'core'
    Subject: Re: [core] concerns re = draft-oflynn-core-bootstrapping-02

     

    Hi Alper:

    With "mothership" I meant to indicate a node that serves as = security manager for a collection of nodes. There are of course different = granularities in what the security manager role entails. In ZigBee, the mothership = node would be "the" trust center.

    I hope this helps.

    Rene
     
    On 28/10/2010 4:48 PM, Alper Yegin wrote:

    Hello,

     

    Similarly, = e.g., PANA does not seem to work in heterogeneous trust environments, assumes online connectivity = of a "mothership" node, and does not seem to include consideration = of how to move from one  mothership node to the next (or, e.g., if one has = an authenticator, how to make this work with single-hop/MAC security).


    Can you please elaborate on what “mothership” node = is.

     

    Alper

     

     

     

     

     

     

    Dear colleagues:

    I had a brief look at the bootstrapping draft (draft-oflynn-core-bootstrapping-02. Some comments below (I am having = some offline discussions on this, but thought to send this to the list as = well):

    I miss a detailed analysis of deployment scenarios to be considered as = guidance into = design, so as to have as very minimal benchmark whether all those crypto protocols = actually enable the deployment scenarios one has in mind. To me, it seems to have = merit to discuss the whole spectrum and end up with cryptographic building = blocks, security protocols, and security policies and accompanying enforcement mechanism for trust policies that would fit the operational = scenarios.

    I would favor not sprinkling protocol acronyms into any draft too early = (since, in my mind, this pushes into a particular direction, and not always with = merit). As an example, right now I do not see how, e.g., HIP or cryptographically = generated addresses (802.1-like) would fit in. Similarly, e.g., PANA does not seem to work in = heterogeneous trust = environments, assumes online connectivity of a "mothership" node, and does = not seem to include consideration of how to move from one  mothership node = to the next (or, e.g., if one has an authenticator, how to make this work with single-hop/MAC security).

    I also miss security objectives and design considerations, such = as "separation of concern" and no entanglement of concepts from different disciplines in the document.

    BTW - I mentioned some of this in email correspondence after the last = CoRE conf call (Wed September 29, 2010). So far, I have not seen too much traffic = on this. Moreover, I have not seen any adequate answers as to what makes, = e.g., HIP features an attractive fit for CoRE-like environments.

    Best regards, Rene

    [excerpt email RS as of October 1, 2010, 12:16pm EDT]

    In my mind, properties of suitable authenticated key agreement schemes = should include (a) key establishment; (b) implicit key authentication; (c) key confirmation; (d) mutual entity authentication; (e) forward secrecy; (f) {perhaps} some more esoteric properties (key compromise impersonation resilience, etc.).

    Moreover, the "name space" (device identifiers) and the = "cryptographic space" (public keys, etc.) should be independent, so that this = would allow trust lifecycle management to be reduced to proper management of device identifiers (i.e., *no* entanglement of concepts from different disciplines).


    On 12/10/2010 12:23 PM, Rene Struik wrote: 

    Hi Tobias:
     
    Thanks =
for your note. 
     
    Does =
your "ascii art" description, Step 1)-3) allow the scenario, =
where (a) one assigns a node id and imprints this (e.g., blowing fuse =
during chip testing); 
    (b) has a node generating =
its own long-term public/private key pair and outputting its node id and =
public key (e.g., during chip testing -- this would =

    correspond to registering a public key with an =
RA); (c) have CA create a certificate in different process and return =
this value at later production/
    personalization =
stage?
     
    Right now, from =
Section 4.1.3 of draft-ietf-hip-rfc5201-bis-02, I get the impression =
that HIP does execute an authenticated DH key agreement scheme. If =
so,
    this makes me wonder how HIP differentiates =
from protocols, such as ECMQV and, e.g., HMQV, which are all not that =
much more expensive than ECDH. If the 
    difference =
is in the "puzzle" element, couldn't one just add something =
similar to a well-known authenticated scheme that is already =
standardized with, e.g., =

    NIST?
     
    <= pre>As to forward secrecy: reason to include this is that many = sensor-type nodes can be expected to be physically unprotected (e.g., = screwed on a street lamp 
    post, on a garage roof, =
etc.) and, therefore, may be more vulnerable to device compromise over =
time (esp. since one cannot expect all nodes to be tamper =

    resistant or tamper evident). By virtue of forward =
secrecy, compromise over time does not compromise the whole device's =
history, but only the current set of
    symmetric keys =
(note: I make some shortcuts in my reasoning on key management here). =
Admittedly, my list of security properties is based on =
"desired" 
    functionality and does not =
exclude functionality that may require, e.g., public-key crypto =
constructs. However, from a user's perspective, the only thing =
that
    matters is features and not what is =
"under the hood", as long as that is not cost-prohibitive =
(which I contend it is not -- cf., e.g., Section 3.2 =
of
    draft-struik-6lowapp-security-considerations-00).=
 (BTW - All other desired security properties I listed have an =
underlying =
rationale.)
     
    It would =
help to have a succinct mathematical description of the protocol you =
suggest (stripped from formatting issues) and describe claimed =
cryptographic
    properties. I would be happy to give =
this a look and review. =

     
    Please feel free to =
provide to me in person if this would be cumbersome material for =
non-crypto people on the mailing =
list.
     
    Best regards, =
Rene
     
     
    [excerpt email RS as of October 1, 2010, 12:16pm EDT and =
response Tobias Heer as of October 7, 2010, 5:36am =
EDT]
     
    To aid clarity and =
succinct discussions, it would help to have a clear description of =
desired security services to be offered by an authenticated =

    key agreement scheme and see whether a candidate =
scheme (such as, who knows, HIP) satisfies these. If you could provide a =
succinct description of 
    the HIP protocol itself, =
so that this is easy to understand, and could provide what properties it =
has, that would be of great help!
    > 
    > In my mind, properties of suitable =
authenticated key agreement schemes should include (a) key =
establishment; (b) implicit key authentication; =

    (c) key confirmation; (d) mutual entity =
authentication; (e) forward secrecy; (f) {perhaps} some more esoteric =
properties (key compromise 
    impersonation =
resilience, etc.).
    > 
    Is this =
list valid for all targeted use cases? If yes, it is a very handy list =
to check against. However, (e) forward secrecy seems to =

    rule a number of "cheaper" cryptographic =
approaches (e.g., pre-shared keys) and might not be relevant to all use =
cases (especially small 
    setups). However, I am not =
absolutely firm with the envisaged scenarios in CORE.
    


    > Moreover, the "name =
space" (device identifiers) and the "cryptographic space" =
(public keys, etc.) should be independent, so that this would =

    


    allow =
trust lifecycle management to be reduced to proper management of device =
identifiers (i.e., *no* entanglement of concepts from different =

    


    disciplines).
    


     
    Does the "*no* entanglement of concepts from different =
disciplines" also mean that a concept like the id/loc split should =
be used to avoid 
    entanglement of routing and =
naming?
     
    



    

    

    

    
On 07/10/2010 5:36 AM, Tobias Heer wrote: 
    


    To aid =
clarity and succinct discussions, it would help to have a clear =
description of desired security services to be offered by an =
authenticated key agreement scheme and see whether a candidate scheme =
(such as, who knows, HIP) satisfies these. If you could provide a =
succinct description of the HIP protocol itself, so that this is easy to =
understand, and could provide what properties it has, that would be of =
great help!
    > 
    > In my mind, properties of suitable =
authenticated key agreement schemes should include (a) key =
establishment; (b) implicit key authentication; (c) key confirmation; =
(d) mutual entity authentication; (e) forward secrecy; (f) {perhaps} =
some more esoteric properties (key compromise impersonation resilience, =
etc.).
    > 
    


    Is this list valid for all targeted use cases? If yes, it is a very =
handy list to check against. However, (e) forward secrecy seems to rule =
a number of "cheaper" cryptographic approaches (e.g., =
pre-shared keys) and might not be relevant to all use cases (especially =
small setups). However, I am not absolutely firm with the envisaged =
scenarios in CORE.
     
    


    > Moreover, the "name =
space" (device identifiers) and the "cryptographic space" =
(public keys, etc.) should be independent, so that this would allow =
trust lifecycle management to be reduced to proper management of device =
identifiers (i.e., *no* entanglement of concepts from different =
disciplines).
    


     
    Does the "*no* entanglement of concepts from different =
disciplines" also mean that a concept like the id/loc split should =
be used to avoid entanglement of routing and =
naming?
     
    



    

    

    

    

    


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



    

    

    

    

    


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




    -- 
    email: rstruik.ext@gmail.com
    Skype: rstruik
    cell: +1 (647) =
867-5658
    USA Google voice: +1 (415) =
690-7363
    ------=_NextPart_000_0111_01CB7EAC.D7DF4740-- From robert.cragie@gridmerge.com Sun Nov 7 12:44:32 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23A3A28C0EF for ; Sun, 7 Nov 2010 12:44:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDBzWDITZ3nM for ; Sun, 7 Nov 2010 12:44:21 -0800 (PST) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id 007A93A68B1 for ; Sun, 7 Nov 2010 12:44:20 -0800 (PST) Received: from client-86-29-103-19.glfd.adsl.virginmedia.com ([86.29.103.19] helo=[192.168.1.80]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) id 1PFC6M-0008PA-Td; Sun, 07 Nov 2010 20:44:36 +0000 Message-ID: <4CD70FA8.5000901@gridmerge.com> Date: Sun, 07 Nov 2010 20:44:24 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Alper Yegin References: <935DB371-B149-486A-8AD2-3B4454C9B172@tzi.org> <4CA3BB54.8050706@gmail.com> <4CA5E8E0.4030503@gmail.com> <4CA6095F.6040403@gmail.com> <4CB48B9B.9010206@gmail.com> <4CC83F61.5060109@gmail.com> <023a01cb76e1$869bfcc0$93d3f640$@yegin@yegin.org> <4CC9EB4B.7040802@gmail.com> <011001cb7e9c$14567740$3d0365c0$@yegin@yegin.org> In-Reply-To: <011001cb7e9c$14567740$3d0365c0$@yegin@yegin.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050302010006080603030701" Cc: 'core' Subject: Re: [core] concerns re draft-oflynn-core-bootstrapping-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Nov 2010 20:44:32 -0000 This is a cryptographically signed message in MIME format. --------------ms050302010006080603030701 Content-Type: multipart/alternative; boundary="------------050405050203030706060108" This is a multi-part message in MIME format. --------------050405050203030706060108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Alper, With regard to the 'mothership', what Rene is referring to is exactly=20 the reason for introducing the PRE element in the ZigBee IP/6lowpan=20 scenario where the authenticator/PAA is not in direct contact with a=20 peer/PaC. <----- PANA ----><---- AAA ----> |-----| |-----| |-----| | Pac |---| PAA |---//---| TrA | |-----| |-----| |-----| AP Backend server NAS The onlink case is shown as above, where, for example, the NAS would be=20 a 802.11 access point. However, in the ZigBee IP/6lowpan case, it could=20 be more complex: <---------- PANA ---------><---- AAA ----> |-----| |-----| |-----| |-----| | Pac |---| PRE |---| PAA |---//---| TrA | |-----| |-----| |-----| |-----| 6LR/H 6LR 6LBR Backend server NAS So the introduction of the relay element (PRE) allows for this=20 separation. Does that cover your point, Rene? With regard to Rene's other point, I think you have that covered and I=20 have shown that above as the AAA protocol between authenticator and=20 backend server. Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com On 07/11/2010 4:51 PM, Alper Yegin wrote: > > Sorry about the late response. > > I'm still not 100% sure I understand the question/issue, but let me=20 > say the following and see if it helps. > > PAA is located on a node that acts as NAS (Network Access Server). If=20 > there are nodes with different trust anchors that need to be=20 > authenticated, NAS would be in charge of contacting the individual=20 > trust anchors for each authentication procedure. For example, NAS=20 > could be using RADIUS for talking with those trust anchors. PANA has=20 > nothing to do with that part. Please see RFC 5193 to see how these=20 > protocols come together to form a generic architecture. > > If the NAS can act as the trust anchor (because it holds the=20 > credential database, or using public key certificates [and does not=20 > care about OCSP/CRL ??]), then it can be offline. But, again, this has = > nothing to do with PANA. PANA gets EAP packets back and forth between=20 > the joining node and NAS. How NAS performs authentication (whether by=20 > itself, or offloads to a AAA server) is invisible to PANA. > > ... > > I didn't understand the issue about "move from one mothership to the=20 > next" at all to comment on it. > > Regards, > > Alper > > *From:*Rene Struik [mailto:rstruik.ext@gmail.com] > *Sent:* Friday, October 29, 2010 12:30 AM > *To:* Alper Yegin > *Cc:* 'core' > *Subject:* Re: [core] concerns re draft-oflynn-core-bootstrapping-02 > > Hi Alper: > > With "mothership" I meant to indicate a node that serves as security=20 > manager for a collection of nodes. There are of course different=20 > granularities in what the security manager role entails. In ZigBee,=20 > the mothership node would be "the" trust center. > > I hope this helps. > > Rene > > On 28/10/2010 4:48 PM, Alper Yegin wrote: > > Hello, > > Similarly, e.g., PANA does not seem to work in heterogeneous=20 > trustenvironments, assumes online connectivity of a "mothership" node, = > and does not seem to include consideration of how to move from one =20 > mothership node to the next (or, e.g., if one has an authenticator,=20 > how to make this work with single-hop/MAC security). > > > Can you please elaborate on what "mothership" node is. > > Alper > > Dear colleagues: > > I had a brief look at the bootstrapping draft=20 > (draft-oflynn-core-bootstrapping-02. Some comments below (I am having=20 > some offline discussions on this, but thought to send this to the list = > as well): > > I miss a detailed analysis of deployment scenarios to be considered as = > guidance intodesign, so as to have as very minimal benchmark whether=20 > all those crypto protocols actually enable the deployment scenarios=20 > one has in mind. To me, it seems to have merit to discuss the whole=20 > spectrum and end up with cryptographic building blocks, security=20 > protocols, and security policies and accompanying enforcement=20 > mechanism for trust policies that would fit the operational scenarios. > > I would favor not sprinkling protocol acronyms into any draft too=20 > early (since, in my mind, this pushes into a particular direction, and = > notalways with merit). As an example, right now I do not see how,=20 > e.g., HIP or cryptographically generated addresses (802.1-like) would=20 > fit in.Similarly, e.g., PANA does not seem to work in heterogeneous=20 > trustenvironments, assumes online connectivity of a "mothership" node, = > and does not seem to include consideration of how to move from one =20 > mothership node to the next (or, e.g., if one has an authenticator,=20 > how to make this work with single-hop/MAC security). > > I also miss security objectives and design considerations, such as=20 > "separation of concern" and no entanglement of concepts from different = > disciplines in the document. > > BTW - I mentioned some of this in email correspondence after the last=20 > CoRE conf call (Wed September 29, 2010). So far, I have not seen too=20 > much traffic on this. Moreover, I have not seen any adequate answers=20 > as to what makes, e.g., HIP features an attractive fit for CoRE-like=20 > environments. > > Best regards, Rene > > [excerpt email RS as of October 1, 2010, 12:16pm EDT] > > In my mind, properties of suitable authenticated key agreement schemes = > should include (a) key establishment; (b) implicit key authentication; = > (c) key confirmation; (d) mutual entity authentication; (e) forward=20 > secrecy; (f) {perhaps} some more esoteric properties (key compromise=20 > impersonation resilience, etc.). > > Moreover, the "name space" (device identifiers) and the "cryptographic = > space" (public keys, etc.) should be independent, so that this would=20 > allow trust lifecycle management to be reduced to proper management of = > device identifiers (i.e., ****no** entanglement of concepts from=20 > different disciplines). > > > On 12/10/2010 12:23 PM, Rene Struik wrote: > > Hi Tobias: > =20 > Thanks for your note. > =20 > Does your "ascii art" description, Step 1)-3) allow the scenario, where= (a) one assigns a node id and imprints this (e.g., blowing fuse during c= hip testing); > (b) has a node generating its own long-term public/private key pair and= outputting its node id and public key (e.g., during chip testing -- this= would > correspond to registering a public key with an RA); (c) have CA create = a certificate in different process and return this value at later product= ion/ > personalization stage? > =20 > Right now, from Section 4.1.3 of draft-ietf-hip-rfc5201-bis-02, I get t= he impression that HIP does execute an authenticated DH key agreement sch= eme. If so, > this makes me wonder how HIP differentiates from protocols, such as ECM= QV and, e.g., HMQV, which are all not that much more expensive than ECDH.= If the > difference is in the "puzzle" element, couldn't one just add something = similar to a well-known authenticated scheme that is already standardized= with, e.g., > NIST? > =20 > As to forward secrecy: reason to include this is that many sensor-type = nodes can be expected to be physically unprotected (e.g., screwed on a st= reet lamp > post, on a garage roof, etc.) and, therefore, may be more vulnerable to= device compromise over time (esp. since one cannot expect all nodes to b= e tamper > resistant or tamper evident). By virtue of forward secrecy, compromise = over time does not compromise the whole device's history, but only the cu= rrent set of > symmetric keys (note: I make some shortcuts in my reasoning on key mana= gement here). Admittedly, my list of security properties is based on "des= ired" > functionality and does not exclude functionality that may require, e.g.= , public-key crypto constructs. However, from a user's perspective, the o= nly thing that > matters is features and not what is "under the hood", as long as that i= s not cost-prohibitive (which I contend it is not -- cf., e.g., Section 3= =2E2 of > draft-struik-6lowapp-security-considerations-00). (BTW - All other desi= red security properties I listed have an underlying rationale.) > =20 > It would help to have a succinct mathematical description of the protoc= ol you suggest (stripped from formatting issues) and describe claimed cry= ptographic > properties. I would be happy to give this a look and review. > =20 > Please feel free to provide to me in person if this would be cumbersome= material for non-crypto people on the mailing list. > =20 > Best regards, Rene > =20 > =20 > [excerpt email RS as of October 1, 2010, 12:16pm EDT and response Tobia= s Heer as of October 7, 2010, 5:36am EDT] > =20 > To aid clarity and succinct discussions, it would help to have a clear = description of desired security services to be offered by an authenticate= d > key agreement scheme and see whether a candidate scheme (such as, who k= nows, HIP) satisfies these. If you could provide a succinct description o= f > the HIP protocol itself, so that this is easy to understand, and could = provide what properties it has, that would be of great help! > > =20 > > In my mind, properties of suitable authenticated key agreement schem= es should include (a) key establishment; (b) implicit key authentication;= > (c) key confirmation; (d) mutual entity authentication; (e) forward sec= recy; (f) {perhaps} some more esoteric properties (key compromise > impersonation resilience, etc.). > > =20 > Is this list valid for all targeted use cases? If yes, it is a very han= dy list to check against. However, (e) forward secrecy seems to > rule a number of "cheaper" cryptographic approaches (e.g., pre-shared k= eys) and might not be relevant to all use cases (especially small > setups). However, I am not absolutely firm with the envisaged scenarios= in CORE. > > > Moreover, the "name space" (device identifiers) and the "cryptog= raphic space" (public keys, etc.) should be independent, so that this wou= ld > > allow trust lifecycle management to be reduced to proper management= of device identifiers (i.e.,****no** entanglement of concepts from diff= erent > > disciplines). > > =20 > Does the "****no** entanglement of concepts from different disciplines= " also mean that a concept like the id/loc split should be used to avoid > entanglement of routing and naming? > =20 > > > > > > On 07/10/2010 5:36 AM, Tobias Heer wrote: > > To aid clarity and succinct discussions, it would help to have a cl= ear description of desired security services to be offered by an authenti= cated key agreement scheme and see whether a candidate scheme (such as, w= ho knows, HIP) satisfies these. If you could provide a succinct descripti= on of the HIP protocol itself, so that this is easy to understand, and co= uld provide what properties it has, that would be of great help! > > > =20 > > > In my mind, properties of suitable authenticated key agreement s= chemes should include (a) key establishment; (b) implicit key authenticat= ion; (c) key confirmation; (d) mutual entity authentication; (e) forward = secrecy; (f) {perhaps} some more esoteric properties (key compromise impe= rsonation resilience, etc.). > > > =20 > > Is this list valid for all targeted use cases? If yes, it is a very han= dy list to check against. However, (e) forward secrecy seems to rule a nu= mber of "cheaper" cryptographic approaches (e.g., pre-shared keys) and mi= ght not be relevant to all use cases (especially small setups). However, = I am not absolutely firm with the envisaged scenarios in CORE. > =20 > > > Moreover, the "name space" (device identifiers) and the "cryptog= raphic space" (public keys, etc.) should be independent, so that this wou= ld allow trust lifecycle management to be reduced to proper management of= device identifiers (i.e.,****no** entanglement of concepts from differe= nt disciplines). > > =20 > Does the "****no** entanglement of concepts from different disciplines= " also mean that a concept like the id/loc split should be used to avoid = entanglement of routing and naming? > =20 > > > > > > --=20 > email:rstruik.ext@gmail.com > Skype: rstruik > cell: +1 (647) 867-5658 > USA Google voice: +1 (415) 690-7363 > > > > > > --=20 > email:rstruik.ext@gmail.com > Skype: rstruik > cell: +1 (647) 867-5658 > USA Google voice: +1 (415) 690-7363 > > > > > --=20 > email:rstruik.ext@gmail.com > Skype: rstruik > cell: +1 (647) 867-5658 > USA Google voice: +1 (415) 690-7363 > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --------------050405050203030706060108 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Alper,

    With regard to the 'mothership', what Rene is referring to is exactly the reason for introducing the PRE element in the ZigBee IP/6lowpan scenario where the authenticator/PAA is not in direct contact with a peer/PaC.

    <----- PANA ----><---- AAA ---->
    |-----|   |-----|      &nbs= p; |-----|
    | Pac |---| PAA |---//---| TrA |
    |-----|       |-----|     &= nbsp;  |-----|
                = AP            Back= end server
                = NAS

    The onlink case is shown as above, where, for example, the NAS would be a 802.11 access point. However, in the ZigBee IP/6lowpan case, it could be more complex:

    <---------- PANA ---------><---- AAA ---->
    |-----|   |-----|   |-----|  &= nbsp;     |-----|
    | Pac |---| PRE |---| PAA |---//---| TrA |
    |-----|       |-----|   |-----|  = ;      |-----|
    6LR/H       6LR   &nbs= p;   6LBR         =     Backend server
               = ;           NAS
    So the introduction of the relay element (PRE) allows for this separation. Does that cover your point, Rene?

    With regard to Rene's other point, I think you have that covered and I have shown that above as the AAA protocol between authenticator and backend server.

    Robert

    Robert Cragie (Pacific Gas & Electric)

    Gridmerge Ltd.
    89 Greenfield Crescent,
    Wakefield, WF4 4WA, UK
    +44 1924 910888
    +1 415 513 0064
    http://www.gridmerge.com


    On 07/11/2010 4:51 PM, Alper Yegin wrote:

    Sorry about the late response.

    I’m still not 100% sure I understand the question/issue, but let me say the following and see if it helps.<= /span>

     

    PAA is located on a node that acts as NAS (Network Access Server). If there are nodes with different trust anchors that need to be authenticated, NAS would be in charge of contacting the individual trust anchors for each authentication procedure. For example, NAS could be using RADIUS for talking with those trust anchors. PANA has nothing to do with that part. Please see RFC 5193 to see how these protocols come together to form a generic architecture.

     

    If the NAS can act as the trust anchor (because it holds the credential database, or using public key certificates [and does not care about OCSP/CRL ??]), then it can be offline. But, again, this has nothing to do with PANA. PANA gets EAP packets back and forth between the joining node and NAS. How NAS performs authentication (whether by itself, or offloads to a AAA server) is invisible to PANA.

     

    …

     

    I didn’t understand the issue about “m= ove from one mothership to the next” at all to comment on it.

     

    Regards,

     

    Alper

     

     

     

     

     

     

     

     

     

     

    From: Rene Struik [mailto:rstruik.ext@gmail.com]
    Sent: Friday, October 29, 2010 12:30 AM
    To: Alper Yegin
    Cc: 'core'
    Subject: Re: [core] concerns re draft-oflynn-core-bootstrapping-02

     

    Hi Alper:

    With "mothership" I meant to indicate a node that serves as security manager for a collection of nodes. There are of course different granularities in what the security manager role entails. In ZigBee, the mothership node would be "the" trust center.

    I hope this helps.

    Rene
     
    On 28/10/2010 4:48 PM, Alper Yegin wrote:

    Hello,

     

    Sim= ilarly, e.g., PANA does not seem to work in heterogeneous trust environments, assumes online connectivity of a "mothership" node, and does not seem to include consideration of how to move from one  mothership node to the next (or, e.g., i= f one has an authenticator, how to make this work with single-hop/MAC security).


    Can you please elaborate on what “mothership” node is= =2E

     

    Alper

     

     

     

     

     

     

    Dear colleagues:

    I had a brief look at the bootstrapping draft (draft-oflynn-core-bootstrapping-02. Some comments below (I am having some offline discussions on this, but thought to send this to the list as well):

    I miss a detailed analysis of deployment scenarios to be considered as guidance into = design, so as to have as very minimal benchmark whether all those crypto protocols actually enable the deployment scenarios one has in mind. To me, it seems to have merit to discuss the whole spectrum and end up with cryptographic building blocks, security protocols, and security policies and accompanying enforcement mechanism for trust policies that would fit the operational scenarios.

    I would favor not sprinkling protocol acronyms into any draft too early (since, in my mind, this pushes into a particular direction, and not<= span style=3D"font-size: 10pt; font-family: Consolas;"> a= lways with merit). As an example, right now I do not see how, e.g., HIP or cryptographically generated addresses (802.1-like) would fit in. Similarly, e.g., PANA does not seem to work in heterogeneous trust= environments, assumes online connectivity of a "mothership" node, and does not seem to include consideration of how to move from one  mother= ship node to the next (or, e.g., if one has an authenticator, how to make this work with single-hop/MAC security).

    I also miss security objectives and design considerations, such as "separation of concern" and no entanglement of concepts from different disciplines in the document.

    BTW - I mentioned some of this in email correspondence after the last CoRE conf call (Wed September 29, 2010). So far, I have not seen too much traffic on this. Moreover, I have not seen any adequate answers as to what makes, e.g., HIP features an attractive fit for CoRE-like environments.
    Best regards, Rene

    [excerpt email RS as of October 1, 2010, 12:16pm EDT]

    In my mind, properties of suitable authenticated key agreement schemes should include (a) key establishment; (b) implicit key authentication; (c) key confirmation; (d) mutual entity authentication; (e) forward secrecy; (f) {perhaps} some more esoteric properties (key compromise impersonation resilience, etc.).

    Moreover, the "name space" (device identifiers) and the "cryptographic space" (public keys, etc.) should be independent, so that this would allow trust lifecycle management to be reduced to proper management of device identifiers (i.e., *no* entanglement of concepts from different disciplines).


    On 12/10/2010 12:23 PM, Rene Struik wrote: 

    Hi Tobias:
     
    Thanks for your note. 
     
    Does your "ascii art" description, Step 1)-3) allow the sc=
enario, where (a) one assigns a node id and imprints this (e.g., blowing =
fuse during chip testing); 
    (b) has a node generating its own long-term public/private=
 key pair and outputting its node id and public key (e.g., during chip te=
sting -- this would 
    correspond to registering a public key with an RA); (c) ha=
ve CA create a certificate in different process and return this value at =
later production/
    personalization stage?
     
    Right now, from Section 4.1.3 of draft-ietf-hip-rfc5201-bi=
s-02, I get the impression that HIP does execute an authenticated DH key =
agreement scheme. If so,
    this makes me wonder how HIP differentiates from protocols=
, such as ECMQV and, e.g., HMQV, which are all not that much more expensi=
ve than ECDH. If the 
    difference is in the "puzzle" element, couldn't one just a=
dd something similar to a well-known authenticated scheme that is already=
 standardized with, e.g., 
    NIST?
     
    As to forward secrecy: reason to include this is that many=
 sensor-type nodes can be expected to be physically unprotected (e.g., sc=
rewed on a street lamp 
    post, on a garage roof, etc.) and, therefore, may be more =
vulnerable to device compromise over time (esp. since one cannot expect a=
ll nodes to be tamper 
    resistant or tamper evident). By virtue of forward secrecy=
, compromise over time does not compromise the whole device's history, bu=
t only the current set of
    symmetric keys (note: I make some shortcuts in my reasonin=
g on key management here). Admittedly, my list of security properties is =
based on "desired" 
    functionality and does not exclude functionality that may =
require, e.g., public-key crypto constructs. However, from a user's persp=
ective, the only thing that
    matters is features and not what is "under the hood", as l=
ong as that is not cost-prohibitive (which I contend it is not -- cf., e.=
g., Section 3.2 of
    draft-struik-6lowapp-security-considerations-00). (BTW - A=
ll other desired security properties I listed have an underlying rational=
e.)
     
    It would help to have a succinct mathematical description =
of the protocol you suggest (stripped from formatting issues) and describ=
e claimed cryptographic
    properties. I would be happy to give this a look and revie=
w. 
     
    Please feel free to provide to me in person if this would =
be cumbersome material for non-crypto people on the mailing list.
     
    Best regards, Rene
     
     
    [excerpt email RS as of October 1, 2010, 12:16pm EDT and r=
esponse Tobias Heer as of October 7, 2010, 5:36am EDT]
     
    To aid clarity and succinct discussions, it would help to =
have a clear description of desired security services to be offered by an=
 authenticated 
    key agreement scheme and see whether a candidate scheme (s=
uch as, who knows, HIP) satisfies these. If you could provide a succinct =
description of 
    the HIP protocol itself, so that this is easy to understan=
d, and could provide what properties it has, that would be of great help!=

    > 
          
    > In my mind, p=
roperties of suitable authenticated key agreement schemes should include =
(a) key establishment; (b) implicit key authentication; 
    =

          
    (c) key confirmation; (d) mutual entity authentication; (e=
) forward secrecy; (f) {perhaps} some more esoteric properties (key compr=
omise 
    
          
    impersonation resilience, etc.).
    
          
    > 
    
          
    Is this list valid for all targeted use cases? If yes, it =
is a very handy list to check against. However, (e) forward secrecy seems=
 to 
    
          
    rule a number of "cheaper" cryptographic approaches (e.g.,=
 pre-shared keys) and might not be relevant to all use cases (especially =
small 
    
          
    setups). However, I am not absolutely firm with the envisa=
ged scenarios in CORE.
    
          
    
            
    > Moreover, t=
he "name space" (device identifiers) and the "cryptographic space" (publi=
c keys, etc.) should be independent, so that this would 
    =

          
    
          
    
            
    allow trust lifecycle management to be reduced to proper=
 management of device identifiers (i.e., *=
no* entanglement of =
concepts from different 
    
          
    
          
    
            
    disciplines).
    
          
    
          
     
    
          
    Does the "*no=
* entanglement of concepts from di=
fferent disciplines" also mean that a concept like the id/loc split shoul=
d be used to avoid 
    
          
    entanglement of routing and naming?
    
          
     
    
          

    
            
    
            
    
            
    
            On 07/10/2010 5:36 AM, Tobias Heer wrote: 
    
          
    
            
    To aid clarity and succinct discussions, it would help t=
o have a clear description of desired security services to be offered by =
an authenticated key agreement scheme and see whether a candidate scheme =
(such as, who knows, HIP) satisfies these. If you could provide a succinc=
t description of the HIP protocol itself, so that this is easy to underst=
and, and could provide what properties it has, that would be of great hel=
p!
    
            
    > =

    
            
    > In my mind,=
 properties of suitable authenticated key agreement schemes should includ=
e (a) key establishment; (b) implicit key authentication; (c) key confirm=
ation; (d) mutual entity authentication; (e) forward secrecy; (f) {perhap=
s} some more esoteric properties (key compromise impersonation resilience=
, etc.).
    
            
    > =

    
          
    
          
    Is this list valid for all targeted use cases? If yes, it =
is a very handy list to check against. However, (e) forward secrecy seems=
 to rule a number of "cheaper" cryptographic approaches (e.g., pre-shared=
 keys) and might not be relevant to all use cases (especially small setup=
s). However, I am not absolutely firm with the envisaged scenarios in COR=
E.
    
          
     
    
          
    
            
    > Moreover, t=
he "name space" (device identifiers) and the "cryptographic space" (publi=
c keys, etc.) should be independent, so that this would allow trust lifec=
ycle management to be reduced to proper management of device identifiers =
(i.e., *no* entanglement of concepts from different discipline=
s).
    
          
    
          
     
    
          
    Does the "*no=
* entanglement of concepts from di=
fferent disciplines" also mean that a concept like the id/loc split shoul=
d be used to avoid entanglement of routing and naming?
    
          
     
    
          

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

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




    -- 
    email: rstruik.ext@gmail.com
    Skype: rstruik
    cell: +1 (647) 867-5658
    USA Google voice: +1 (415) 690-7363
    
_______________________________________________
core mailing list
core@=
ietf.org
https://www.ietf.org/mailman/listinfo/core
    --------------050405050203030706060108-- --------------ms050302010006080603030701 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRZTCC BN0wggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UE BhMCR0IxGzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEa MBgGA1UECgwRQ29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJV UzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUg VVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWls MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5 ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqk kqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWL eeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJ Q/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udl y/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0jBBgwFoAUoBEKIz6W8Qfs 4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQE AwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAR BgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5jb21vZG9j YS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwuY29t b2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvz bRx8NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12 jMOCAU9sAPMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxog L5dMUbtGB8SKN04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNB pEMD9O3vMyfbOeAUTibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mY HK9/FX8wggY+MIIFJqADAgECAhEAtlwUjTTxveqQY8soFvBYEjANBgkqhkiG9w0BAQUFADCB rjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEe MBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVz ZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIGFuZCBFbWFpbDAeFw0xMDA4MzAwMDAwMDBaFw0xMTA4MzAyMzU5NTlaMIHkMTUwMwYD VQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBFUlNPTkEgTk9UIFZBTElEQVRFRDFGMEQG A1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5u ZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMyBDb21vZG8gTGltaXRlZDEWMBQGA1UE AxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVy Z2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtAJ+m9Tgd3li8BgAIRth Gtth3YcCbhLPjfAcnDKcEGSrkZqao79Jg2uDW62IOwNCq9ae3VweBlvg3UUVu8upXzgDR/jF z4S1ZNk1if6V9QEiyBHdE1qMUQeeytedk3qw93CU5snWiXgVRacU8H8Dv+WJPsb4WYAH4MBz aJMI2N/E5XGGYpKFj9vxnEiQ7h83jXxw3Ee2rXCCbhJEci/tUl+Cx40pB3m7nlEdASY+A3tq JLIiG8Argf0+bWaxmuSUihKoakhHQruAylWY9EVtbKg8SACYZhdHCx2+ZSSrxbbAKSv0cDk0 0vQPvgH5GEi6zSB9QvqWCdBH/rL0XfV5jQIDAQABo4ICHTCCAhkwHwYDVR0jBBgwFoAUiYJn fcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFGkahOqOBMk95XAb8dpcRdaef8AYMA4GA1Ud DwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIx AQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzAp BggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCB mjBMoEqgSIZGaHR0cDovL2NybC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRB dXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0 L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYB BQUHAQEEYDBeMDYGCCsGAQUFBzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFD bGllbnRDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNV HREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEB ADcjSJQKgVIfD/IztFrhx2YqR9mKsDs3XakKd4hUoeunHgskiaMIQY2Kcfob48OuzrfY73rN fNoaqr5LZwDeVflMnZd0rPcTA9rAHq5l/qwdSta3k0xvBui0NAtOrSBdbqC4vggLKuZvoR2o 7mSbxSSBZHuVLObx/E5E+D5fjWC7ffNvr9y/uFXeCYFsM+Hc9VPIZ+cAY7JQFJEK/Nuti2QH IIxdR91N2vHuNXWIPROPFMl7y8ltO/fONwhxMcY2dH4JkDH6pdNzMtzykvsO0NeiRHnNlS4K A8aD9RaBR8FNQHq+JusC2tf11qdHBpHrVAK7dHodKDnbRr2t9VdrU2owggY+MIIFJqADAgEC AhEAtlwUjTTxveqQY8soFvBYEjANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJU UlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNV BAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0x MDA4MzAwMDAwMDBaFw0xMTA4MzAyMzU5NTlaMIHkMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3Qg TmV0d29yayAtIFBFUlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENv bmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0G A1UECxMWKGMpMjAwMyBDb21vZG8gTGltaXRlZDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEq MCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtAJ+m9Tgd3li8BgAIRthGtth3YcCbhLPjfAcnDKcEGSr kZqao79Jg2uDW62IOwNCq9ae3VweBlvg3UUVu8upXzgDR/jFz4S1ZNk1if6V9QEiyBHdE1qM UQeeytedk3qw93CU5snWiXgVRacU8H8Dv+WJPsb4WYAH4MBzaJMI2N/E5XGGYpKFj9vxnEiQ 7h83jXxw3Ee2rXCCbhJEci/tUl+Cx40pB3m7nlEdASY+A3tqJLIiG8Argf0+bWaxmuSUihKo akhHQruAylWY9EVtbKg8SACYZhdHCx2+ZSSrxbbAKSv0cDk00vQPvgH5GEi6zSB9QvqWCdBH /rL0XfV5jQIDAQABo4ICHTCCAhkwHwYDVR0jBBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0w HQYDVR0OBBYEFGkahOqOBMk95XAb8dpcRdaef8AYMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMB Af8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEE BAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6 Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0cDovL2Ny bC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVt YWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xp ZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQUF BzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwYB BQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRtyb2JlcnQuY3Jh Z2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBADcjSJQKgVIfD/IztFrhx2Yq R9mKsDs3XakKd4hUoeunHgskiaMIQY2Kcfob48OuzrfY73rNfNoaqr5LZwDeVflMnZd0rPcT A9rAHq5l/qwdSta3k0xvBui0NAtOrSBdbqC4vggLKuZvoR2o7mSbxSSBZHuVLObx/E5E+D5f jWC7ffNvr9y/uFXeCYFsM+Hc9VPIZ+cAY7JQFJEK/Nuti2QHIIxdR91N2vHuNXWIPROPFMl7 y8ltO/fONwhxMcY2dH4JkDH6pdNzMtzykvsO0NeiRHnNlS4KA8aD9RaBR8FNQHq+JusC2tf1 1qdHBpHrVAK7dHodKDnbRr2t9VdrU2oxggRgMIIEXAIBATCBxDCBrjELMAkGA1UEBhMCVVMx CzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVT RVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0 BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIR ALZcFI008b3qkGPLKBbwWBIwCQYFKw4DAhoFAKCCAnAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTAxMTA3MjA0NDI0WjAjBgkqhkiG9w0BCQQxFgQU4G9M xVuLGzpll2kdKbrbmXo0iAwwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJV VDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4t VVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQC2XBSNNPG96pBj yygW8FgSMIHXBgsqhkiG9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgT AlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBO ZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIRALZcFI008b3q kGPLKBbwWBIwDQYJKoZIhvcNAQEBBQAEggEAVRquEtuYtNwTPJpQ1aFCA8Gptl2VlijhoFa3 9IW/QBrrCSAucuYy3iUvm6VD6YCITFyquikbz3WdNCweUjlM3Jqe7CGNAPCacsuvMFHNjIXJ U23v3qDM+HZRTvMOdVk9phZMSGuom752TLNFJpVZoCpCLw+NLJnA1pap4NIc2lPQG2F60eXC fAA+FUSx1oq0snnxyy6I7r/SPfBluR28l3zBPAQFUPaPd+5JhwLkrxDqC26BvHCS7vsxMjPL 29u6SZcUT7rQIsbVA2Z+stQAVtn0dLswUDyBSbCZuRUZ4BCZuefRE6ZSrt7CtR6p5ffkbxiC pyW++OlBvLE3exuYTwAAAAAAAA== --------------ms050302010006080603030701-- From ekr@rtfm.com Sun Nov 7 13:28:33 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2960928C0D7 for ; Sun, 7 Nov 2010 13:28:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.555 X-Spam-Level: X-Spam-Status: No, score=-101.555 tagged_above=-999 required=5 tests=[AWL=0.421, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pAPHrBZsErtw for ; Sun, 7 Nov 2010 13:28:31 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 746E33A68D7 for ; Sun, 7 Nov 2010 13:28:31 -0800 (PST) Received: by gya6 with SMTP id 6so3266507gya.31 for ; Sun, 07 Nov 2010 13:28:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.90.4.1 with SMTP id 1mr4333394agd.124.1289165330052; Sun, 07 Nov 2010 13:28:50 -0800 (PST) Received: by 10.91.78.6 with HTTP; Sun, 7 Nov 2010 13:28:49 -0800 (PST) Date: Sun, 7 Nov 2010 13:28:49 -0800 Message-ID: From: Eric Rescorla To: core@ietf.org Content-Type: multipart/alternative; boundary=00163630fab18df5cb04947d31c2 Subject: [core] Review of draft-ietf-core-coap-03 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 21:28:33 -0000 --00163630fab18df5cb04947d31c2 Content-Type: text/plain; charset=ISO-8859-1 I've reviewed this document. Comments below. My concerns here are primarily about the security parts, which seem a bit handwavy. It's certainly possible to build systems where all the security provided by channel security mechanisms (IPsec and DTLS) but can't tell if this is such a system without more security analysis. In particular: - What's the general trust model in terms of the relationship between the servers and clients? - What are the assumed capabilities of the devices in question? - How is access control expected to behave with respect to proxy caches? (The HTTP story is clear but you've stripped out the HTTP access control mechanisms). I don't see how a server even verifies a client who goes through a cache. - I'd like to see some discussion of cross-protocol attacks, which seem likely with the NoSec mode. IPsec You don't actually say this, but I'm assuming that you intend to use IPsec's manual keying mode, rather than IKE. If so, this seems to have a series of obvious problems around the lack of guaranteed fresh keys/nonces, as well as replay attacks. In particular, if you're going to have single-packet messages which control network devices, it seems like anti-replay is very important, but RFC 4303 says: If the key used to compute an ICV is manually distributed, a compliant implementation SHOULD NOT provide anti-replay service. If a user chooses to employ anti-replay in conjunction with SAs that are manually keyed, the sequence number counter at the sender MUST be correctly maintained across local reboots, etc., until the key is replaced. (See Section 5.) This seems like a fairly problematic combination and at minimum needs some discussion. I'm similarly concerned about the use of CCM, which fails catastrophically in the face of replayed packets. I'd like to understand how you're going to assure that the nonce is never replayed in the face of very long-lived keys used throughout a large network. Recall that the birthday limit for AES-CCM in ESP is only 2^{32} packets, but even that's for ~0.5 probability of replay. The security is weakened long before that. IMO it's very unwise to use ESP this way w/o at minimum some form of automatic key diversification. DTLS The claim that DTLS is an order of magnitude more complicated than CoAP is unsupported and, for instance, if we're just counting pages that doesn't appear to be correct. Certainly, if you just do TLS_PSK modes, that's not correct. In my experience, the majority of the code in a TLS stack is the crypto algorithms and the certificate processing. You will need the crypto algorithms in any case and the PSK profile you have chosen does not require certificates. If this is the basis for thinking that DTLS inadequate, you may want to rethink that. Regardless, please please remove this claim. Similarly, I don't know what "appreciable handshake overhead" means. Please provide some measurements for the profile you have chosen or remove this as well. The particular TLS PSK mode you specify has no private entropy other than from the shared key. If you are going to select this mode, you need language about the minimum entropy of the PSK. This is an issue for IPsec as well, btw. The PSK modes are not specified in 5246, so please fix this citation. Throughout the document you write "cypher suite". The TLS term is "cipher suite" The question of whether you should use certs is quasi-orthogonal to whether you use TLS_RSA_PSK. You can use self-signed certs with TLS_RSA_PSK. S 10.3.1. This seems kind of superfluous. Code in general has bugs and it's not clear that "stringent tests" are that useful for finding them. -Ekr --00163630fab18df5cb04947d31c2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    I've reviewed this document. Comments below.

    <= div>My concerns here are primarily about the security parts, which seem a
    bit handwavy. It's certainly possible to build systems where a= ll the
    security provided by channel security mechanisms (IPsec and DTLS) but<= /div>
    can't tell if this is such a system without more security ana= lysis.

    In particular:
    - What's the g= eneral trust model in terms of the relationship between
    =A0=A0the servers and clients?
    - What are the assumed capabi= lities of the devices in question?
    - How is access control expect= ed to behave with respect to proxy caches?
    =A0=A0(The HTTP story = is clear but you've stripped out the HTTP access
    =A0=A0control mechanisms). I don't see how a server even verifies = a
    =A0=A0client who goes through a cache.
    - I'd like= to see some discussion of cross-protocol attacks, which=A0
    =A0= =A0seem likely with the NoSec mode.

    IPsec
    You don't actually say this, but I&= #39;m assuming that you intend to
    use IPsec's manual keying m= ode, rather than IKE. If so, this seems
    to have a series of obvio= us problems around the lack of guaranteed
    fresh keys/nonces, as well as replay attacks. In particular, if
    <= div>you're going to have single-packet messages which control network
    devices, it seems like anti-replay is very important, but RFC 4303=
    says:

    =A0=A0 If the key used to compute an IC= V is manually distributed, a
    =A0=A0 compliant implementation SHOU= LD NOT provide anti-replay service. =A0If
    =A0=A0 a user chooses t= o employ anti-replay in conjunction with SAs that are
    =A0=A0 manually keyed, the sequence number counter at the sender MUST = be
    =A0=A0 correctly maintained across local reboots, etc., until = the key is
    =A0=A0 replaced. =A0(See Section 5.)

    This seems like a fairly problematic combination and at minimum
    needs some discussion.

    I'm similarly conc= erned about the use of CCM, which fails
    catastrophically in the f= ace of replayed packets. I'd like to
    understand how you'r= e going to assure that the nonce is never replayed
    in the face of very long-lived keys used throughout a large network.
    Recall that the birthday limit for AES-CCM in ESP is only 2^{32}
    packets, but even that's for ~0.5 probability of replay. The s= ecurity
    is weakened long before that.

    IMO it's ve= ry unwise to use ESP this way w/o at minimum some form of
    automat= ic key diversification.


    DTLS
    The claim that DTLS is an order of magnitude more complicated than CoA= P
    is unsupported and, for instance, if we're just counting pa= ges that doesn't
    appear to be correct. Certainly, if you just= do TLS_PSK modes, that's
    not correct. In my experience, the majority of the code in a TLS stack=
    is the crypto algorithms and the certificate processing. You wil= l
    need the crypto algorithms in any case and the PSK profile you = have
    chosen does not require certificates. If this is the basis for thinkin= g
    that DTLS inadequate, you may want to rethink that. Regardless,= please
    please remove this claim.

    Simila= rly, I don't know what "appreciable handshake overhead" means= .
    Please provide some measurements for the profile you have chosen or
    remove this as well.

    The particular TLS PS= K mode you specify has no private entropy other than=A0
    from the = shared key. If you are going to select this mode, you need=A0
    language about the minimum entropy of the PSK. This is an issue for
    IPsec as well, btw.

    The PSK modes are not = specified in 5246, so please fix this citation.

    Throughout the document you write "cypher suite". The TLS term is= "cipher suite"

    The question of whether = you should use certs is quasi-orthogonal to whether
    you use TLS_R= SA_PSK. You can use self-signed certs with TLS_RSA_PSK.


    S 10.3.1.
    This seems kind of s= uperfluous. Code in general has bugs and it's not
    clear that = "stringent tests" are that useful for finding them.



    -Ekr

    =




    =



    --00163630fab18df5cb04947d31c2-- From robert.cragie@gridmerge.com Sun Nov 7 13:49:29 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E2DE3A68D0 for ; Sun, 7 Nov 2010 13:49:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8RfCfEecTCf for ; Sun, 7 Nov 2010 13:49:27 -0800 (PST) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id 2BA0D3A68C8 for ; Sun, 7 Nov 2010 13:49:27 -0800 (PST) Received: from client-86-29-103-19.glfd.adsl.virginmedia.com ([86.29.103.19] helo=[192.168.1.80]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) id 1PFD7S-0003kX-20; Sun, 07 Nov 2010 21:49:46 +0000 Message-ID: <4CD71EF0.2080606@gridmerge.com> Date: Sun, 07 Nov 2010 21:49:36 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Cullen Jennings References: <05D7FB47-E2DC-4F73-B9F7-551E9251FF23@cisco.com> In-Reply-To: <05D7FB47-E2DC-4F73-B9F7-551E9251FF23@cisco.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020105080104070304060305" Cc: core Subject: Re: [core] draft-oflynn-core-bootstrapping X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Nov 2010 21:49:29 -0000 This is a cryptographically signed message in MIME format. --------------ms020105080104070304060305 Content-Type: multipart/alternative; boundary="------------070401060203050003070306" This is a multi-part message in MIME format. --------------070401060203050003070306 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Cullen, Comments inline, bracketed by Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com On 07/11/2010 3:21 AM, Cullen Jennings wrote: > Big question: > > Lots of good stuff but I think we need to start narrow in on what we ne= ed to specify to actually go and implement this. For example, say I have = a device with a button and LED, what do I need to implement so that the u= ser can take that device and get to the point where the "bootstrap" is co= mplete and all the information needed to security run COAP is there. I re= alize that is probably a bunch of different things and different use case= s but at some point we need to be clear about what a device need to imple= ment and how it will be secure. I think that is the problem - there is a huge bunch of use cases. The=20 foundation of this document is the described general architecture, the=20 aim of which is to provide a framework for fitting bootstrapping=20 protocols into. The examples may need to refer more clearly as to which=20 of the protocols is used and to use the architecture nomenclature more.=20 This should make is clearer how it all fits together. > Few minor things. > It mention SE2.0 has devices be programmed with a certificate. What the= trust root for theses? There is a PKI with a Root CA as usual so the certificate can be=20 verified up to the root. There may be more than one Root CA. This is=20 pretty standard - is it necessary to mention this? > HIP > I assume we are talking about the rfc4843-bis style ORCHIDs here which = thought they are 182 bits long, 28 of those bits get fixed so you really = have 100 bits of hash resulting in a much smaller search space for collis= ions. It would be worth thinking about how long theses would remain secur= ity given current estimates. There must be some reasons that these are wr= itten up an experiment that ends in 2014 if not explicitly renewed. I think this ties in with Rene's earlier concerns re. entangling=20 name space and cryptographic space. > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --------------070401060203050003070306 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Cullen,

    Comments inline, bracketed by <RCC></RCC>

    Robert

    Robert Cragie (Pacific Gas & Electric)

    Gridmerge Ltd.
    89 Greenfield Crescent,
    Wakefield, WF4 4WA, UK
    +44 1924 910888
    +1 415 513 0064
    http://www.gridmerge.com


    On 07/11/2010 3:21 AM, Cullen Jennings wrote: 
    Big question:

Lots of good stuff but I think we need to start narrow in on what we need=
 to specify to actually go and implement this. For example, say I have a =
device with a button and LED, what do I need to implement so that the use=
r can take that device and get to the point where the "bootstrap" is comp=
lete and all the information needed to security run COAP is there. I real=
ize that is probably a bunch of different things and different use cases =
but at some point we need to be clear about what a device need to impleme=
nt and how it will be secure.=20
    <RCC>
    I think that is the problem - there is a huge bunch of use cases. The foundation of this document is the described general architecture, the aim of which is to provide a framework for fitting bootstrapping protocols into. The examples may need to refer more clearly as to which of the protocols is used and to use the architecture nomenclature more. This should make is clearer how it all fits together.
    </RCC>
    Few minor things.=20
It mention SE2.0 has devices be programmed with a certificate. What the t=
rust root for theses?=20
    <RCC>There is a PKI with a Root CA as usual so the certificate can be verified up to the root. There may be more than one Root CA. This is pretty standard - is it necessary to mention this?</RCC>
    HIP
I assume we are talking about the rfc4843-bis style ORCHIDs here which th=
ought they are 182 bits long, 28 of those bits get fixed so you really ha=
ve 100 bits of hash resulting in a much smaller search space for collisio=
ns. It would be worth thinking about how long theses would remain securit=
y given current estimates. There must be some reasons that these are writ=
ten up an experiment that ends in 2014 if not explicitly renewed.=20
    <RCC>I think this ties in with Rene's earlier concerns re. entangling name space and cryptographic space.</RCC>
    

_______________________________________________
core mailing list
core@=
ietf.org
https://www.ietf.org/mailman/listinfo/core
    --------------070401060203050003070306-- --------------ms020105080104070304060305 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRZTCC BN0wggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UE BhMCR0IxGzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEa MBgGA1UECgwRQ29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJV UzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUg VVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWls MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5 ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqk kqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWL eeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJ Q/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udl y/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0jBBgwFoAUoBEKIz6W8Qfs 4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQE AwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAR BgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5jb21vZG9j YS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwuY29t b2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvz bRx8NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12 jMOCAU9sAPMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxog L5dMUbtGB8SKN04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNB pEMD9O3vMyfbOeAUTibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mY HK9/FX8wggY+MIIFJqADAgECAhEAtlwUjTTxveqQY8soFvBYEjANBgkqhkiG9w0BAQUFADCB rjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEe MBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVz ZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIGFuZCBFbWFpbDAeFw0xMDA4MzAwMDAwMDBaFw0xMTA4MzAyMzU5NTlaMIHkMTUwMwYD VQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBFUlNPTkEgTk9UIFZBTElEQVRFRDFGMEQG A1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5u ZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMyBDb21vZG8gTGltaXRlZDEWMBQGA1UE AxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVy Z2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtAJ+m9Tgd3li8BgAIRth Gtth3YcCbhLPjfAcnDKcEGSrkZqao79Jg2uDW62IOwNCq9ae3VweBlvg3UUVu8upXzgDR/jF z4S1ZNk1if6V9QEiyBHdE1qMUQeeytedk3qw93CU5snWiXgVRacU8H8Dv+WJPsb4WYAH4MBz aJMI2N/E5XGGYpKFj9vxnEiQ7h83jXxw3Ee2rXCCbhJEci/tUl+Cx40pB3m7nlEdASY+A3tq JLIiG8Argf0+bWaxmuSUihKoakhHQruAylWY9EVtbKg8SACYZhdHCx2+ZSSrxbbAKSv0cDk0 0vQPvgH5GEi6zSB9QvqWCdBH/rL0XfV5jQIDAQABo4ICHTCCAhkwHwYDVR0jBBgwFoAUiYJn fcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFGkahOqOBMk95XAb8dpcRdaef8AYMA4GA1Ud DwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIx AQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzAp BggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCB mjBMoEqgSIZGaHR0cDovL2NybC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRB dXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0 L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYB BQUHAQEEYDBeMDYGCCsGAQUFBzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFD bGllbnRDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNV HREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEB ADcjSJQKgVIfD/IztFrhx2YqR9mKsDs3XakKd4hUoeunHgskiaMIQY2Kcfob48OuzrfY73rN fNoaqr5LZwDeVflMnZd0rPcTA9rAHq5l/qwdSta3k0xvBui0NAtOrSBdbqC4vggLKuZvoR2o 7mSbxSSBZHuVLObx/E5E+D5fjWC7ffNvr9y/uFXeCYFsM+Hc9VPIZ+cAY7JQFJEK/Nuti2QH IIxdR91N2vHuNXWIPROPFMl7y8ltO/fONwhxMcY2dH4JkDH6pdNzMtzykvsO0NeiRHnNlS4K A8aD9RaBR8FNQHq+JusC2tf11qdHBpHrVAK7dHodKDnbRr2t9VdrU2owggY+MIIFJqADAgEC AhEAtlwUjTTxveqQY8soFvBYEjANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJU UlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNV BAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0x MDA4MzAwMDAwMDBaFw0xMTA4MzAyMzU5NTlaMIHkMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3Qg TmV0d29yayAtIFBFUlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENv bmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0G A1UECxMWKGMpMjAwMyBDb21vZG8gTGltaXRlZDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEq MCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtAJ+m9Tgd3li8BgAIRthGtth3YcCbhLPjfAcnDKcEGSr kZqao79Jg2uDW62IOwNCq9ae3VweBlvg3UUVu8upXzgDR/jFz4S1ZNk1if6V9QEiyBHdE1qM UQeeytedk3qw93CU5snWiXgVRacU8H8Dv+WJPsb4WYAH4MBzaJMI2N/E5XGGYpKFj9vxnEiQ 7h83jXxw3Ee2rXCCbhJEci/tUl+Cx40pB3m7nlEdASY+A3tqJLIiG8Argf0+bWaxmuSUihKo akhHQruAylWY9EVtbKg8SACYZhdHCx2+ZSSrxbbAKSv0cDk00vQPvgH5GEi6zSB9QvqWCdBH /rL0XfV5jQIDAQABo4ICHTCCAhkwHwYDVR0jBBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0w HQYDVR0OBBYEFGkahOqOBMk95XAb8dpcRdaef8AYMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMB Af8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEE BAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6 Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0cDovL2Ny bC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVt YWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xp ZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQUF BzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwYB BQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRtyb2JlcnQuY3Jh Z2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBADcjSJQKgVIfD/IztFrhx2Yq R9mKsDs3XakKd4hUoeunHgskiaMIQY2Kcfob48OuzrfY73rNfNoaqr5LZwDeVflMnZd0rPcT A9rAHq5l/qwdSta3k0xvBui0NAtOrSBdbqC4vggLKuZvoR2o7mSbxSSBZHuVLObx/E5E+D5f jWC7ffNvr9y/uFXeCYFsM+Hc9VPIZ+cAY7JQFJEK/Nuti2QHIIxdR91N2vHuNXWIPROPFMl7 y8ltO/fONwhxMcY2dH4JkDH6pdNzMtzykvsO0NeiRHnNlS4KA8aD9RaBR8FNQHq+JusC2tf1 1qdHBpHrVAK7dHodKDnbRr2t9VdrU2oxggRgMIIEXAIBATCBxDCBrjELMAkGA1UEBhMCVVMx CzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVT RVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0 BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIR ALZcFI008b3qkGPLKBbwWBIwCQYFKw4DAhoFAKCCAnAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTAxMTA3MjE0OTM2WjAjBgkqhkiG9w0BCQQxFgQUvLdt aqog0iyrAvz6tYQ1H+twjlcwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJV VDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4t VVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQC2XBSNNPG96pBj yygW8FgSMIHXBgsqhkiG9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgT AlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBO ZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIRALZcFI008b3q kGPLKBbwWBIwDQYJKoZIhvcNAQEBBQAEggEAjWhy8RoZ/Cy0/N9j8q3bL2Q2GFS82x4S7slA 0eWZtPaSDaWFgNv9w2Eh4JmhLvwB5XIvbPbpTko2jPD+E799schVzLryJvtQnZI/IevuLiIV BW7cblq3IVoF75XPxbHo+9xCTK6iC6qdHHN8W3xyo8j0YSgfc1JZIcnVLbkV1O3wc5elN4Lo FxhgLNlBbLboxp1sIRBLuXzPQJpoGY9fTNLtvP6+1dWbAJAPFUVfrhsEyt5bb82q9JDcpgdL b/8n/Iwd3DereNwZlDLGoFT0cbwFnW1STEd48rC8x+xCaIv5QfPWrbMJXBR6923RkHohMMte A1zTqquuhIRHbme0twAAAAAAAA== --------------ms020105080104070304060305-- From kerlyn2001@gmail.com Sun Nov 7 18:31:46 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6058B28C0DF for ; Sun, 7 Nov 2010 18:31:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oN75Wm5-P61z for ; Sun, 7 Nov 2010 18:31:45 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id E355B3A694D for ; Sun, 7 Nov 2010 18:31:44 -0800 (PST) Received: by bwz12 with SMTP id 12so4918567bwz.31 for ; Sun, 07 Nov 2010 18:32:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=4Ov8n3b2A7witjy6VUIbik2AlofsiHxQNrqbX8qILCM=; b=ZNWrkJxYvW/NbGQKSSawKjqdbMULk4GlZ7XImRL4+xUM87rkEQKx1AoR73QiO3PQuc W+38eaJlVrBMJl5s+4e5NOmilFPnPeOCKjjNi8H673ZXQ70XTBLO2aGpPANf3rb/njGz 28xQB6iycphxnzwLM5zvxQi+pcmrjB7aE4xOc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=BW1lnW8RQgjRahW0qeeZeUVzy9UBcYFjw8Mx/iPOCyFI3qNRrqNgoA28itgFwmjvtF zB6ErZTMxIvTma7OvDUTGx7e3O0GGjBLElY1aBz5fuTZ5BGvHPEDDBZ8WUIBW3lNiRcj 4vJGAwNJomN/JlQfSX5X253r2ZEc5rbJOVHuE= MIME-Version: 1.0 Received: by 10.204.72.6 with SMTP id k6mr4468768bkj.58.1289183524225; Sun, 07 Nov 2010 18:32:04 -0800 (PST) Received: by 10.204.50.150 with HTTP; Sun, 7 Nov 2010 18:32:04 -0800 (PST) In-Reply-To: References: <057.7877dadaee8c1a49ad3c621003bde997@tools.ietf.org> Date: Sun, 7 Nov 2010 21:32:04 -0500 Message-ID: From: Kerry Lynn To: Carsten Bormann Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: core issue tracker , core@ietf.org Subject: Re: [core] coap #52 (new): How strict to make POST definition? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 02:31:46 -0000 On Sat, Nov 6, 2010 at 12:53 PM, Carsten Bormann wrote: > On Nov 6, 2010, at 20:54, Kerry Lynn wrote: > >> Now one thing I belive *is* a problem, and needs a new ticket, is the >> inability of the underlying transaction model to treat POST in a non- >> idempotent fashion. =A0Figure 8 in draft-ietf-core-coap-03 shows the >> client retying a GET in the case where the ACK is lost. How the server >> treats this in the case of POST is unspecified. =A0I believe this may re= sult >> in the creation of *multiple* resources at the server. > > Maybe I don't understand your concern correctly. I guess I didn't fully understand the *lack* of concern until now, so either I'm slow or the spec could use more explanation on this point (or both :) Hence the suggestion that we raise this to an issue that should be discussed and tracked by the WG. > Figure 8 shows how a lost ACK is handled by the transaction layer. > The mechanism shown also works for POST. The client cannot know whether the CON or ACK has been lost. All it can do in this situation is retry the CON and that's where the problem may arise. This is not an issue with HTTP servers because TCP provides reliable transport and duplicate client requests do not occur as a result of the protocol. > A server that wants to offer at-most-once POST can use the transaction > ID to differentiate a retransmission from a new request. If the server receives a duplicate CON+POST, a naive implementation may treat this as a new indication and duplicate the function at the server= . What the server *should* do in the case of POST is to cache the response and return that to the client upon receipt of a duplicate CON, without offering the equivalent of a duplicate indication to the application. This would normally be the responsibility of the transaction layer; the desire for AMO behavior would be signaled by the client and implemented by the server. > How it does this is indeed unspecified, but we rarely specify implementat= ion details. > The semantics of a POST are defined by the resource/the server. > Requiring the server to offer at-most-once POSTs would be an onus for tho= se applications that don't need that. > HTTP is pretty clear on this point; POST does not have the idempotent property. Section 2.3 says coap methods have the same properties as their HTTP equivalents. If all coap implementations don't treat POST the same way, then how can we call it a uniform method? > We could go ahead and specify > -- requirements on the time that must elapse before TID reuse by a client= (to avoid false positives) Done. See section 2.2.5. > -- requirements on the time TID state is kept at a server (to avoid false= negatives) > RFC 955 talks about retaining state until a new TID is received, but this doesn't allow for parallel requests. Some transaction protocols have a "release" message to signal the server that the response has been received. I'm sure there are other equally valid approaches. > Do we need to? > (Not a rhetorical question.) > > My ceterum censeo: Please talk about the use case you have in mind. > (E.g., I have one use case for POST where the at-most-once semantics are > important enough to be realized in the application, so I wouldn't even ca= re > if the server does them right or not.) I guess that may depend on the outcome of the issue #52 discussion. If the consensus is to allow POST to act as "invoke" as well as "append" (and I suspect this will be the case), then basically any situation that can result in duplicate indications would be a use case. For example, I wouldn't want my energy controller to receive duplicate load shed invocations. Regards, -K- > > Gruesse, Carsten > > From trac@tools.ietf.org Sun Nov 7 18:41:24 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02F063A6934 for ; Sun, 7 Nov 2010 18:41:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mjEAhXzmNuoc for ; Sun, 7 Nov 2010 18:41:22 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id E3EC93A672F for ; Sun, 7 Nov 2010 18:41:22 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PFHfy-0001KA-Fi; Sun, 07 Nov 2010 18:41:42 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Mon, 08 Nov 2010 02:41:42 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/58 Message-ID: <057.c926cbbf08febeb5dad3f2eec7273279@tools.ietf.org> X-Trac-Ticket-ID: 58 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] coap #58 (new): Define trust model X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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 Nov 2010 02:41:24 -0000 #58: Define trust model From Eric Rescorla's coap-03 review: What's the general trust model in terms of the relationship between the servers and clients? -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: Type: task | Status: new Priority: minor | Milestone: Component: coap | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From trac@tools.ietf.org Sun Nov 7 18:44:33 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DE7B28C103 for ; Sun, 7 Nov 2010 18:44:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJogOFLFKfck for ; Sun, 7 Nov 2010 18:44:32 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id DDCAB28C11D for ; Sun, 7 Nov 2010 18:44:32 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PFHj3-0001QE-6u; Sun, 07 Nov 2010 18:44:53 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Mon, 08 Nov 2010 02:44:53 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/59 Message-ID: <057.cbf0bd75bba0dd710f209966e4d26782@tools.ietf.org> X-Trac-Ticket-ID: 59 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] coap #59 (new): Assumed device capabilities X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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 Nov 2010 02:44:33 -0000 #59: Assumed device capabilities From Eirc Rescorla's coap-03 review: What are the assumed capabilities of the devices in question? -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: Type: task | Status: new Priority: trivial | Milestone: Component: coap | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From trac@tools.ietf.org Sun Nov 7 18:46:11 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF0FF3A6951 for ; Sun, 7 Nov 2010 18:46:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 345ffD3KbIDw for ; Sun, 7 Nov 2010 18:46:08 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id BA4593A694D for ; Sun, 7 Nov 2010 18:46:08 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PFHkb-0002RZ-0i; Sun, 07 Nov 2010 18:46:29 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Mon, 08 Nov 2010 02:46:28 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/60 Message-ID: <057.b16a799c382877519fb8cb657d149a2b@tools.ietf.org> X-Trac-Ticket-ID: 60 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] coap #60 (new): Access control and proxy caches X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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 Nov 2010 02:46:11 -0000 #60: Access control and proxy caches From Eric Resola's coap-03 review and brought up by Adam Roach: How is access control expected to behave with respect to proxy caches? (The HTTP story is clear but you've stripped out the HTTP access control mechanisms). I don't see how a server even verifies a client who goes through a cache. -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: Type: defect | Status: new Priority: major | Milestone: Component: coap | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From trac@tools.ietf.org Sun Nov 7 18:47:53 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA89D3A68F0 for ; Sun, 7 Nov 2010 18:47:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4dGBOAAP2b7U for ; Sun, 7 Nov 2010 18:47:51 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 6FB0E3A68E9 for ; Sun, 7 Nov 2010 18:47:51 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PFHmF-0005bf-CW; Sun, 07 Nov 2010 18:48:11 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Mon, 08 Nov 2010 02:48:11 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/61 Message-ID: <057.e4cc3beda4c24f32f37d2786e56a309d@tools.ietf.org> X-Trac-Ticket-ID: 61 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] coap #61 (new): Cross-protocol attacks X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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 Nov 2010 02:47:53 -0000 #61: Cross-protocol attacks From Eric Resola's coap-03 review: I'd like to see some discussion of cross-protocol attacks, which seems likely with the NoSec mode. -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: Type: task | Status: new Priority: minor | Milestone: Component: coap | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From ekr@rtfm.com Sun Nov 7 18:51:24 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAD6F3A6936 for ; Sun, 7 Nov 2010 18:51:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.615 X-Spam-Level: X-Spam-Status: No, score=-101.615 tagged_above=-999 required=5 tests=[AWL=0.361, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSF20aMYpftE for ; Sun, 7 Nov 2010 18:51:24 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id F03F03A6930 for ; Sun, 7 Nov 2010 18:51:23 -0800 (PST) Received: by ywp6 with SMTP id 6so3390234ywp.31 for ; Sun, 07 Nov 2010 18:51:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.90.4.6 with SMTP id 6mr4658475agd.16.1289184702900; Sun, 07 Nov 2010 18:51:42 -0800 (PST) Received: by 10.91.78.6 with HTTP; Sun, 7 Nov 2010 18:51:42 -0800 (PST) In-Reply-To: <057.e4cc3beda4c24f32f37d2786e56a309d@tools.ietf.org> References: <057.e4cc3beda4c24f32f37d2786e56a309d@tools.ietf.org> Date: Sun, 7 Nov 2010 18:51:42 -0800 Message-ID: From: Eric Rescorla To: core issue tracker Content-Type: multipart/alternative; boundary=00163630ffbd442b42049481b436 Cc: core@ietf.org Subject: Re: [core] coap #61 (new): Cross-protocol attacks X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 02:51:25 -0000 --00163630ffbd442b42049481b436 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Not trying to be difficult here, but my name is Rescorla, not Rescola. -Ekr On Sun, Nov 7, 2010 at 6:48 PM, core issue tracker wro= te: > #61: Cross-protocol attacks > > From Eric Resola's coap-03 review: > > I'd like to see some discussion of cross-protocol attacks, which seems > likely with the NoSec mode. > > -- > > --------------------------------+----------------------------------------= --- > Reporter: zach@=85 | Owner: > Type: task | Status: new > Priority: minor | Milestone: > Component: coap | Version: > Severity: - | Keywords: > > --------------------------------+----------------------------------------= --- > > Ticket URL: > core > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --00163630ffbd442b42049481b436 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Not trying to be difficult here, but my name is Rescorla, not Rescola.
    =
    -Ekr


    On Sun, Nov 7, 2010 at 6:48 PM, core issue tracker <<= a href=3D"mailto:trac@tools.ietf.org">trac@tools.ietf.org> wr= ote:
    #61: Cross-protocol attacks

    =A0From Eric Resola's coap-03 review:

    =A0I'd like to see some discussion of cross-protocol attacks, which see= ms
    =A0likely with the NoSec mode.

    --
    --------------------------------+------------------------------------------= -
    =A0Reporter: =A0zach@=85 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 Owner: =A0 =A0 Type: =A0task =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0Status: = =A0new
    =A0Priority: =A0minor =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 Milestone:
    Component: =A0coap =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 Version:
    =A0Severity: =A0- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0Keywords: --------------------------------+------------------------------------------= -

    Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/61&= gt;
    core <http://t= ools.ietf.org/core/>

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

    --00163630ffbd442b42049481b436-- From trac@tools.ietf.org Sun Nov 7 21:55:31 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B0433A6998 for ; Sun, 7 Nov 2010 21:55:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lu0slz6wnNvD for ; Sun, 7 Nov 2010 21:55:29 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 7D7833A69AA for ; Sun, 7 Nov 2010 21:55:29 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PFKhp-0001QX-HC; Sun, 07 Nov 2010 21:55:49 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Mon, 08 Nov 2010 05:55:49 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/62 Message-ID: <057.d26408d9e353ca9909f2d305c8811103@tools.ietf.org> X-Trac-Ticket-ID: 62 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] coap #62 (new): Uri-Scheme option X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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 Nov 2010 05:55:31 -0000 #62: Uri-Scheme option In draft-ietf-core-coap-01 and earlier we had a Uri-Scheme option (3, default coap://). It was removed in coap-02 after determining that it was not necessary. Recent discussion has indicated that some people would find Uri-Scheme useful for a client to indicate the protocol to proxy to when using a multi-protocol proxy. Discussion is neeed to detemine if we want to add Uri-Scheme back to the protocol. The following text described this option in coap-01: "3.2.2. Uri-Scheme Option The Uri-Scheme Option indicates the schema part of the URI without any ":" or "://" glue. This option is most often used to access a resource via a proxy. For example, to access an HTTP resource via a proxy the option value would be "http". In the absence of this option, the URI scheme is assumed to be "coap". Section 2.5.2 specifies the rules for URIs in CoAP. This option MUST be supported by an end-point implementing proxy functionality." -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: coap | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From fluffy@cisco.com Sun Nov 7 22:12:44 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DAEB3A69C9 for ; Sun, 7 Nov 2010 22:11:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOFOjHUZpHwq for ; Sun, 7 Nov 2010 22:11:10 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 4EAEB3A69C5 for ; Sun, 7 Nov 2010 22:10:10 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AloFAMoi10ytJXG8/2dsb2JhbACUB41/cZ99ml6CcYJXBIRYhX2DCg X-IronPort-AV: E=Sophos;i="4.58,312,1286150400"; d="scan'208";a="179581500" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rtp-iport-2.cisco.com with ESMTP; 08 Nov 2010 06:10:10 +0000 Received: from [192.168.4.2] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id oA86A9dw032275; Mon, 8 Nov 2010 06:10:09 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4CD71EF0.2080606@gridmerge.com> Date: Sun, 7 Nov 2010 23:10:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5796D385-F3C8-42CE-A28C-54DDFEC0E11D@cisco.com> References: <05D7FB47-E2DC-4F73-B9F7-551E9251FF23@cisco.com> <4CD71EF0.2080606@gridmerge.com> To: X-Mailer: Apple Mail (2.1081) Cc: core Subject: Re: [core] draft-oflynn-core-bootstrapping X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 06:12:44 -0000 X-List-Received-Date: Mon, 08 Nov 2010 06:12:44 -0000 On Nov 7, 2010, at 2:49 PM, Robert Cragie wrote: > Hi Cullen, >=20 >> Few minor things.=20 >> It mention SE2.0 has devices be programmed with a certificate. What = the trust root for theses?=20 >>=20 > There is a PKI with a Root CA as usual so the certificate can be = verified up to the root. There may be more than one Root CA. This is = pretty standard - is it necessary to mention this? No I don't think it needs to be mentioned in the draft I was just trying = to get up to speed.=20 I was trying to get an idea if there was one PKI and all the the = manufactured build devices with certificates that go up to the same = trust root -- or -- if it was the people deploying the devices had = their own root CA and as they deployed the devices they installed = certificates so different deployments might have a different trust root.=20= Some of the IP phone manufactures consider both of theses models and = decided neither of them were ideal. The model where the certificate = needed to be installed on the phone by the service provider meant you = could not ship the phone from manufacture to the where it was being = installed or at least you had to touch the phone in some way as part of = the installment to install the certificate. On the other hand, the = manufactures were not keen on having the liability of running a CA to = sign the certs on the phones where if it was compromised, it would = compromise the security of all their customers operational networks. It = seems like there might some of the same concerns these deployments. The end solution that is used involves the manufactures installs a = manufactured installed cert that is tied to the mac address of the phone = which you can barcode off the boxes without opening them. The only thing = this certificate is used for is to identify the phone to install a local = certificate. So the service provider would use the manufacture = certificate to help install the local certificate and the SP runs, or = contracted out, the CA for local certificates. If the manufacture's CA = is compromised, then the SP has to stop allowing new phones to be = enrolled in the system while the issues is dealt with but all the phones = that were already enrolled before the compromise are not at risk. The = risk of the operational network sits with the SP's CA. Clearly if the = manufactures CA is compromised but it takes them months to notice, then = there phones deployed in that time window are at risk but this type of = scheme helps mitigate risk and helps allocate it between manufactures = and SP.=20= From trac@tools.ietf.org Sun Nov 7 22:19:26 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E26693A69A0 for ; Sun, 7 Nov 2010 22:19:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5f9JaJZN3uhp for ; Sun, 7 Nov 2010 22:19:25 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 93FBD3A684F for ; Sun, 7 Nov 2010 22:19:25 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PFL4z-0007l1-H9; Sun, 07 Nov 2010 22:19:45 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Mon, 08 Nov 2010 06:19:45 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/63 Message-ID: <057.0bb67d2c41ff89e249108086d44ce3e4@tools.ietf.org> X-Trac-Ticket-ID: 63 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] coap #63 (new): Verify all syncronous and asyncronous interactions X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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 Nov 2010 06:19:27 -0000 #63: Verify all syncronous and asyncronous interactions With the token option added in coap-03 (from coap-misc), and now having some interop experience with that, it is time to go through and do a sanity check on all the synchronous and asyncronous interactions in the protocol. - Check that all the transaction exchanges are properly documented. - Adjust the Token rules for synchronous and asynchronous responses. - Make sure the option processing is fully documented (as suggsted by Adam). - Check if any examples are missing for the above. -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: Type: task | Status: new Priority: minor | Milestone: Component: coap | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From robert.cragie@gridmerge.com Sun Nov 7 23:23:25 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F422D3A6452 for ; Sun, 7 Nov 2010 23:23:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7gKNgWGKlhPN for ; Sun, 7 Nov 2010 23:23:20 -0800 (PST) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id A67E03A635F for ; Sun, 7 Nov 2010 23:23:13 -0800 (PST) Received: from client-86-29-103-19.glfd.adsl.virginmedia.com ([86.29.103.19] helo=[192.168.1.80]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) id 1PFM4Z-0008Uv-Gl; Mon, 08 Nov 2010 07:23:24 +0000 Message-ID: <4CD7A561.1080000@gridmerge.com> Date: Mon, 08 Nov 2010 07:23:13 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Kerry Lynn References: <057.7877dadaee8c1a49ad3c621003bde997@tools.ietf.org> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070907020804080709020008" Cc: core issue tracker , core@ietf.org Subject: Re: [core] coap #52 (new): How strict to make POST definition? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2010 07:23:26 -0000 This is a cryptographically signed message in MIME format. --------------ms070907020804080709020008 Content-Type: multipart/alternative; boundary="------------060809040709030805050804" This is a multi-part message in MIME format. --------------060809040709030805050804 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable I think the language of CON+ACK processing at the end-point as a server=20 needs to be tightened up. The transaction handler should not be=20 submitting multiple CONs with the same tid for further processing. In=20 that case it then just becomes a reliable delivery mechanism and POST=20 does not have to be idempotent. However, I think the idea of caching the = response makes sense if you apply a lifetime to it. Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com On 08/11/2010 2:32 AM, Kerry Lynn wrote: > On Sat, Nov 6, 2010 at 12:53 PM, Carsten Bormann wrote: >> On Nov 6, 2010, at 20:54, Kerry Lynn wrote: >> >>> Now one thing I belive *is* a problem, and needs a new ticket, is the= >>> inability of the underlying transaction model to treat POST in a non-= >>> idempotent fashion. Figure 8 in draft-ietf-core-coap-03 shows the >>> client retying a GET in the case where the ACK is lost. How the serve= r >>> treats this in the case of POST is unspecified. I believe this may r= esult >>> in the creation of *multiple* resources at the server. >> Maybe I don't understand your concern correctly. > I guess I didn't fully understand the *lack* of concern until now, so > either I'm slow or the spec could use more explanation on this point > (or both :) Hence the suggestion that we raise this to an issue that > should be discussed and tracked by the WG. > >> Figure 8 shows how a lost ACK is handled by the transaction layer. >> The mechanism shown also works for POST. > The client cannot know whether the CON or ACK has been lost. All > it can do in this situation is retry the CON and that's where the probl= em > may arise. > > This is not an issue with HTTP servers because TCP provides reliable > transport and duplicate client requests do not occur as a result of the= > protocol. > >> A server that wants to offer at-most-once POST can use the transaction= >> ID to differentiate a retransmission from a new request. > If the server receives a duplicate CON+POST, a naive implementation > may treat this as a new indication and duplicate the function at the se= rver. > What the server *should* do in the case of POST is to cache the respons= e > and return that to the client upon receipt of a duplicate CON, without > offering the equivalent of a duplicate indication to the application. = This > would normally be the responsibility of the transaction layer; the desi= re > for AMO behavior would be signaled by the client and implemented by > the server. > >> How it does this is indeed unspecified, but we rarely specify implemen= tation details. >> The semantics of a POST are defined by the resource/the server. >> Requiring the server to offer at-most-once POSTs would be an onus for = those applications that don't need that. >> > HTTP is pretty clear on this point; POST does not have the idempotent > property. Section 2.3 says coap methods have the same properties as > their HTTP equivalents. If all coap implementations don't treat POST t= he > same way, then how can we call it a uniform method? > >> We could go ahead and specify >> -- requirements on the time that must elapse before TID reuse by a cli= ent (to avoid false positives) > Done. See section 2.2.5. > >> -- requirements on the time TID state is kept at a server (to avoid fa= lse negatives) >> > RFC 955 talks about retaining state until a new TID is received, but th= is > doesn't allow for parallel requests. Some transaction protocols have a= > "release" message to signal the server that the response has been recei= ved. > I'm sure there are other equally valid approaches. > >> Do we need to? >> (Not a rhetorical question.) >> >> My ceterum censeo: Please talk about the use case you have in mind. >> (E.g., I have one use case for POST where the at-most-once semantics a= re >> important enough to be realized in the application, so I wouldn't even= care >> if the server does them right or not.) > I guess that may depend on the outcome of the issue #52 discussion. > If the consensus is to allow POST to act as "invoke" as well as > "append" (and I suspect this will be the case), then basically any > situation that can result in duplicate indications would be a use case.= > For example, I wouldn't want my energy controller to receive duplicate > load shed invocations. > > Regards, -K- > > >> Gruesse, Carsten >> >> > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --------------060809040709030805050804 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think the language of CON+ACK processing at the end-point as a server needs to be tightened up. The transaction handler should not be submitting multiple CONs with the same tid for further processing. In that case it then just becomes a reliable delivery mechanism and POST does not have to be idempotent. However, I think the idea of caching the response makes sense if you apply a lifetime to it.

    Robert

    Robert Cragie (Pacific Gas & Electric)

    Gridmerge Ltd.
    89 Greenfield Crescent,
    Wakefield, WF4 4WA, UK
    +44 1924 910888
    +1 415 513 0064
    http://www.gridmerge.com


    On 08/11/2010 2:32 AM, Kerry Lynn wrote: 
    On Sat, Nov 6, 2010 at 12:53 PM, Carsten Bormann <cabo@tzi=
=2Eorg> wrote:

    On Nov 6, 2010, at 20:54, Kerry Lynn wrote:


    Now one thing I belive *is* a problem, and needs=
 a new ticket, is the
inability of the underlying transaction model to treat POST in a non-
idempotent fashion.  Figure 8 in draft-ietf-core-coap-03 shows the
client retying a GET in the case where the ACK is lost. How the server
treats this in the case of POST is unspecified.  I believe this may =
result
in the creation of *multiple* resources at the server.

    Maybe I don't understand your concern correctly.

    I guess I didn't fully understand the *lack* of concern until now, so
either I'm slow or the spec could use more explanation on this point
(or both :)  Hence the suggestion that we raise this to an issue that
should be discussed and tracked by the WG.


    Figure 8 shows how a lost ACK is handled by the tr=
ansaction layer.
The mechanism shown also works for POST.

    The client cannot know whether the CON or ACK has been lost.  All
it can do in this situation is retry the CON and that's where the problem=

may arise.

This is not an issue with HTTP servers because TCP provides reliable
transport and duplicate client requests do not occur as a result of the
protocol.


    A server that wants to offer at-most-once POST can=
 use the transaction
ID to differentiate a retransmission from a new request.

    If the server receives a duplicate CON+POST, a naive implementation
may treat this as a new indication and duplicate the function at the serv=
er.
What the server *should* do in the case of POST is to cache the response
and return that to the client upon receipt of a duplicate CON, without
offering the equivalent of a duplicate indication to the application.  Th=
is
would normally be the responsibility of the transaction layer; the desire=

for AMO behavior would be signaled by the client and implemented by
the server.


    How it does this is indeed unspecified, but we rar=
ely specify implementation details.
The semantics of a POST are defined by the resource/the server.
Requiring the server to offer at-most-once POSTs would be an onus for tho=
se applications that don't need that.


    HTTP is pretty clear on this point; POST does not have the idempotent
property.  Section 2.3 says coap methods have the same properties as
their HTTP equivalents.  If all coap implementations don't treat POST the=

same way, then how can we call it a uniform method?


    We could go ahead and specify
-- requirements on the time that must elapse before TID reuse by a client=
 (to avoid false positives)

    Done.  See section 2.2.5.


    -- requirements on the time TID state is kept at a=
 server (to avoid false negatives)


    RFC 955 talks about retaining state until a new TID is received, but this=

doesn't allow for parallel requests.  Some transaction protocols have a
"release" message to signal the server that the response has been receive=
d.
I'm sure there are other equally valid approaches.


    Do we need to?
(Not a rhetorical question.)

My ceterum censeo: Please talk about the use case you have in mind.
(E.g., I have one use case for POST where the at-most-once semantics are
important enough to be realized in the application, so I wouldn't even ca=
re
if the server does them right or not.)

    I guess that may depend on the outcome of the issue #52 discussion.
If the consensus is to allow POST to act as "invoke" as well as
"append" (and I suspect this will be the case), then basically any
situation that can result in duplicate indications would be a use case.
For example, I wouldn't want my energy controller to receive duplicate
load shed invocations.

Regards, -K-



    Gruesse, Carsten



    _______________________________________________
core mailing list
core@=
ietf.org
https://www.ietf.org/mailman/listinfo/core
    --------------060809040709030805050804-- --------------ms070907020804080709020008 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRZTCC BN0wggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UE BhMCR0IxGzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEa MBgGA1UECgwRQ29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJV UzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUg VVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWls MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5 ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqk kqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWL eeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJ Q/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udl y/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0jBBgwFoAUoBEKIz6W8Qfs 4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQE AwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAR BgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5jb21vZG9j YS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwuY29t b2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvz bRx8NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12 jMOCAU9sAPMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxog L5dMUbtGB8SKN04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNB pEMD9O3vMyfbOeAUTibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mY HK9/FX8wggY+MIIFJqADAgECAhEAtlwUjTTxveqQY8soFvBYEjANBgkqhkiG9w0BAQUFADCB rjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEe MBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVz ZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIGFuZCBFbWFpbDAeFw0xMDA4MzAwMDAwMDBaFw0xMTA4MzAyMzU5NTlaMIHkMTUwMwYD VQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBFUlNPTkEgTk9UIFZBTElEQVRFRDFGMEQG A1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5u ZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMyBDb21vZG8gTGltaXRlZDEWMBQGA1UE AxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVy Z2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtAJ+m9Tgd3li8BgAIRth Gtth3YcCbhLPjfAcnDKcEGSrkZqao79Jg2uDW62IOwNCq9ae3VweBlvg3UUVu8upXzgDR/jF z4S1ZNk1if6V9QEiyBHdE1qMUQeeytedk3qw93CU5snWiXgVRacU8H8Dv+WJPsb4WYAH4MBz aJMI2N/E5XGGYpKFj9vxnEiQ7h83jXxw3Ee2rXCCbhJEci/tUl+Cx40pB3m7nlEdASY+A3tq JLIiG8Argf0+bWaxmuSUihKoakhHQruAylWY9EVtbKg8SACYZhdHCx2+ZSSrxbbAKSv0cDk0 0vQPvgH5GEi6zSB9QvqWCdBH/rL0XfV5jQIDAQABo4ICHTCCAhkwHwYDVR0jBBgwFoAUiYJn fcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFGkahOqOBMk95XAb8dpcRdaef8AYMA4GA1Ud DwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIx AQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzAp BggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCB mjBMoEqgSIZGaHR0cDovL2NybC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRB dXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0 L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYB BQUHAQEEYDBeMDYGCCsGAQUFBzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFD bGllbnRDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNV HREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEB ADcjSJQKgVIfD/IztFrhx2YqR9mKsDs3XakKd4hUoeunHgskiaMIQY2Kcfob48OuzrfY73rN fNoaqr5LZwDeVflMnZd0rPcTA9rAHq5l/qwdSta3k0xvBui0NAtOrSBdbqC4vggLKuZvoR2o 7mSbxSSBZHuVLObx/E5E+D5fjWC7ffNvr9y/uFXeCYFsM+Hc9VPIZ+cAY7JQFJEK/Nuti2QH IIxdR91N2vHuNXWIPROPFMl7y8ltO/fONwhxMcY2dH4JkDH6pdNzMtzykvsO0NeiRHnNlS4K A8aD9RaBR8FNQHq+JusC2tf11qdHBpHrVAK7dHodKDnbRr2t9VdrU2owggY+MIIFJqADAgEC AhEAtlwUjTTxveqQY8soFvBYEjANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJU UlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNV BAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0x MDA4MzAwMDAwMDBaFw0xMTA4MzAyMzU5NTlaMIHkMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3Qg TmV0d29yayAtIFBFUlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENv bmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0G A1UECxMWKGMpMjAwMyBDb21vZG8gTGltaXRlZDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEq MCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtAJ+m9Tgd3li8BgAIRthGtth3YcCbhLPjfAcnDKcEGSr kZqao79Jg2uDW62IOwNCq9ae3VweBlvg3UUVu8upXzgDR/jFz4S1ZNk1if6V9QEiyBHdE1qM UQeeytedk3qw93CU5snWiXgVRacU8H8Dv+WJPsb4WYAH4MBzaJMI2N/E5XGGYpKFj9vxnEiQ 7h83jXxw3Ee2rXCCbhJEci/tUl+Cx40pB3m7nlEdASY+A3tqJLIiG8Argf0+bWaxmuSUihKo akhHQruAylWY9EVtbKg8SACYZhdHCx2+ZSSrxbbAKSv0cDk00vQPvgH5GEi6zSB9QvqWCdBH /rL0XfV5jQIDAQABo4ICHTCCAhkwHwYDVR0jBBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0w HQYDVR0OBBYEFGkahOqOBMk95XAb8dpcRdaef8AYMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMB Af8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEE BAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6 Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0cDovL2Ny bC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVt YWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xp ZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQUF BzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwYB BQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRtyb2JlcnQuY3Jh Z2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBADcjSJQKgVIfD/IztFrhx2Yq R9mKsDs3XakKd4hUoeunHgskiaMIQY2Kcfob48OuzrfY73rNfNoaqr5LZwDeVflMnZd0rPcT A9rAHq5l/qwdSta3k0xvBui0NAtOrSBdbqC4vggLKuZvoR2o7mSbxSSBZHuVLObx/E5E+D5f jWC7ffNvr9y/uFXeCYFsM+Hc9VPIZ+cAY7JQFJEK/Nuti2QHIIxdR91N2vHuNXWIPROPFMl7 y8ltO/fONwhxMcY2dH4JkDH6pdNzMtzykvsO0NeiRHnNlS4KA8aD9RaBR8FNQHq+JusC2tf1 1qdHBpHrVAK7dHodKDnbRr2t9VdrU2oxggRgMIIEXAIBATCBxDCBrjELMAkGA1UEBhMCVVMx CzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVT RVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0 BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIR ALZcFI008b3qkGPLKBbwWBIwCQYFKw4DAhoFAKCCAnAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTAxMTA4MDcyMzEzWjAjBgkqhkiG9w0BCQQxFgQULMWR dwGMcHJeoy8bXFFO/7lbyfwwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJV VDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4t VVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQC2XBSNNPG96pBj yygW8FgSMIHXBgsqhkiG9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgT AlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBO ZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIRALZcFI008b3q kGPLKBbwWBIwDQYJKoZIhvcNAQEBBQAEggEASiAbJYEjUazvtin4WeB6H2DYjaIfFEyUCOe2 AJMKzeStfpDcREEgTMAlwf+wBvaqCD36e1zhcSSYbdTizSZPf/9SxDSugm/a3HSSZ+bPVnc3 xnWJFBhh/WLvLWDhMmm5TuqcGM9G3RN459NO1phK9cFPCtthRipXCZlqrHzQQdZRBp5XWgj4 CgTouEO5N+5uuYMQ0e590y8V2zvdJLoPZRPy6Li2L9wOcBSi3fZ/f3tTWocxghncRBSiP7o4 VMkEPOJRe+VmHN4K4gw1sTrN0GC3o4YIHZziZYYOzLqEZukYJ4IxtPzftQ4qwEKW23+xC+OD WS7EtZk2M8LFn/WxWQAAAAAAAA== --------------ms070907020804080709020008-- From ekr@rtfm.com Sun Nov 7 23:39:39 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A2913A6843 for ; Sun, 7 Nov 2010 23:39:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.695 X-Spam-Level: X-Spam-Status: No, score=-101.695 tagged_above=-999 required=5 tests=[AWL=0.281, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WpJe1uTH4UEA for ; Sun, 7 Nov 2010 23:39:38 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id A4D903A679F for ; Sun, 7 Nov 2010 23:39:38 -0800 (PST) Received: by ywp6 with SMTP id 6so3465368ywp.31 for ; Sun, 07 Nov 2010 23:39:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.91.21.7 with SMTP id y7mr4926113agi.70.1289201998851; Sun, 07 Nov 2010 23:39:58 -0800 (PST) Received: by 10.91.78.6 with HTTP; Sun, 7 Nov 2010 23:39:58 -0800 (PST) Date: Sun, 7 Nov 2010 23:39:58 -0800 Message-ID: From: Eric Rescorla To: core@ietf.org Content-Type: multipart/alternative; boundary=0016e640cc6a2f6d10049485bbe9 Subject: [core] Stuffing state in tokens X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 07:39:39 -0000 --0016e640cc6a2f6d10049485bbe9 Content-Type: text/plain; charset=ISO-8859-1 As a general matter if you're going to have a token that has state in it that would be advantageous to someone who has the token to modify then you need to protect the token. So, the question then becomes how difficult it is for an attacker to generate a new, valid token with a different state. The classic way to generate these tokens (see for instance, http://tools.ietf.org/html/draft-rescorla-stateless-tokens-01) is to have some payload plus an integrity check (MAC). So you have a token composed of: P || M Where P is the payload and M is the MAC. Say that the attacker generates an arbitrary payload P' and then generates a random MAC M', the chance that the MAC is valid is 2^{-m} where m is the length of the MAC. In most cases, a forgery probability of 2^{-64} is considered the minimum acceptable limit with 2^{-80} being preferred. This implies a MAC of at least 8-10 bytes. Now, perhaps there is some argument that in this case the risk of forgery is lower, but I don't see how it's going to be acceptable at less than a 4 byte (2^{-32} probability) MAC and we only accepted that for SRTP because there was an argument that a single forged media sample was a low risk. I don't see that that applies here. -Ekr --0016e640cc6a2f6d10049485bbe9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable As a general matter if you're going to have a token that has state in i= t
    that would be advantageous to someone who has the token to modify
    then you need to protect the token. So, the question then becomes
    how difficult it is for an attacker to generate a new, valid token wit= h
    a different state.

    The classic way to = generate these tokens (see for instance,
    have some payload plus an integrity check (MAC). So you have
    a token composed of:

    P || M

    <= div>Where P is the payload and M is the MAC.

    Say t= hat the attacker generates an arbitrary payload P' and then generates
    a random MAC M', the chance that the MAC is valid is 2^{-m} where = m is the
    length of the MAC. In most cases, a forgery probability = of 2^{-64} is considered
    the minimum acceptable limit with 2^{-80= } being preferred. This implies a MAC
    of at least 8-10 bytes. Now, perhaps there is some argument that in th= is case
    the risk of forgery is lower, but I don't see how it&= #39;s going to be acceptable
    at less than a 4 byte (2^{-32} proba= bility) MAC and we only accepted that
    for SRTP because there was an argument that a single forged media samp= le
    was a low risk. I don't see that that applies here.
    <= div>
    -Ekr

    --0016e640cc6a2f6d10049485bbe9-- From adam@nostrum.com Mon Nov 8 00:17:18 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 339323A67D1 for ; Mon, 8 Nov 2010 00:17:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.5 X-Spam-Level: X-Spam-Status: No, score=-102.5 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-dAwaR4r4LY for ; Mon, 8 Nov 2010 00:17:17 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 9E5023A67D4 for ; Mon, 8 Nov 2010 00:17:16 -0800 (PST) Received: from dhcp-235b.meeting.ietf.org (dhcp-235b.meeting.ietf.org [130.129.35.91]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id oA88HYkq059741 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Mon, 8 Nov 2010 02:17:35 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4CD7B21C.2000600@nostrum.com> Date: Mon, 08 Nov 2010 16:17:32 +0800 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: "CORE (Constrained RESTful Environments) WG" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.35.91 is authenticated by a trusted mechanism) Subject: [core] Towards authc/authz user cases X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 08:17:18 -0000 In today's meeting, Carsten brought up the topic of the kinds of authentication and authorization models we want to consider for CoRE, in particular when you start using proxies. I'm think of this mostly in terms of a CoRE server, an HTTP client, and an HTTP/CoRE proxy in the middle: +--------+ +-------+ +--------+ | Client |------| Proxy |------| Server | +--------+ HTTP +-------+ CoRE +--------+ In this context, Carsten spoke of the "big friend" model. Under this model, the Proxy would use normal HTTP authentication mechanisms (e.g., Basic over TLS, or Digest). It then checks its own local ACLs for authorization purposes, and provides access only to those resources on the server that the authenticated user is allowed to access. The use cases for this model are pretty obvious: very simple servers that can't reasonably be provisioned with user information (e.g., light switches), where the nature of what can be done (e.g., turning lights on and off) is reasonable to trust the proxy with. For the sake of concreteness, let's nail down the nature of the proxy. Let's assume that this proxy is inside my electric meter, and is administered by my power utility company. But let's assume they're pretty progressive, and let me access the proxy so that I can remotely monitor and control my various CoAP-attached devices. Now, with that in place, let's consider something other than light switches. Let's think about my CoAP-attached alarm system, and my CoAP-controllable deadbolt lock. If we pursue only the model under which the proxy authenticates the user and then has free reign over the various home-area-network devices, this would potentially give a set of power utility employees the ability to monitor and control my alarm system and my front-door deadbolt. This gives me pause. So, in addition to the "big friend" model, I think it's clear that we need the ability for the client to authenticate end-to-end, through the proxy. And, since the proxy can only marginally be trusted in this case, we need to make sure it can't lift the credentials from, say, HTTP basic auth it receives over TLS connections. Without defining a new model for HTTP, it seems that this situation kind of requires the ability to interwork HTTP digest parameters with semantically equivalent CoAP parameters. /a From peter.van.der.stok@philips.com Mon Nov 8 01:20:45 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD67C3A6946 for ; Mon, 8 Nov 2010 01:20:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4EsX9TVjhix for ; Mon, 8 Nov 2010 01:20:44 -0800 (PST) Received: from VA3EHSOBE008.bigfish.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by core3.amsl.com (Postfix) with ESMTP id 41E553A6903 for ; Mon, 8 Nov 2010 01:20:44 -0800 (PST) Received: from mail46-va3-R.bigfish.com (10.7.14.248) by VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id 14.1.225.8; Mon, 8 Nov 2010 09:21:05 +0000 Received: from mail46-va3 (localhost.localdomain [127.0.0.1]) by mail46-va3-R.bigfish.com (Postfix) with ESMTP id EE3221604B7; Mon, 8 Nov 2010 09:21:04 +0000 (UTC) X-SpamScore: -45 X-BigFish: VPS-45(zz15d6O9251J542N9370J217bPzz1202hzz8275dh1033ILz2dh2a8h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:NLAMSEXE03.connect1.local; RD:smtpx.philips.com; EFVD:NLI Received: from mail46-va3 (localhost.localdomain [127.0.0.1]) by mail46-va3 (MessageSwitch) id 1289208064574615_2236; Mon, 8 Nov 2010 09:21:04 +0000 (UTC) Received: from VA3EHSMHS014.bigfish.com (unknown [10.7.14.245]) by mail46-va3.bigfish.com (Postfix) with ESMTP id 85B6C15D804E; Mon, 8 Nov 2010 09:21:04 +0000 (UTC) Received: from NLAMSEXE03.connect1.local (168.87.56.20) by VA3EHSMHS014.bigfish.com (10.7.99.24) with Microsoft SMTP Server (TLS) id 14.1.225.8; Mon, 8 Nov 2010 09:21:02 +0000 Received: from NLAMSEXH04.connect1.local (172.16.153.25) by connect1.philips.com (172.16.156.42) with Microsoft SMTP Server (TLS) id 8.3.106.1; Mon, 8 Nov 2010 10:20:58 +0100 Received: from NLCLUEXM03.connect1.local ([172.16.157.42]) by NLAMSEXH04.connect1.local ([172.16.153.25]) with mapi; Mon, 8 Nov 2010 10:21:01 +0100 From: "Stok, Peter van der" To: Adam Roach , "CORE (Constrained RESTful Environments) WG" Date: Mon, 8 Nov 2010 10:21:02 +0100 Thread-Topic: [core] Towards authc/authz user cases Thread-Index: Act/HW0DXhPhHlcgTH+PSSPjQwmQLwACC2tg Message-ID: References: <4CD7B21C.2000600@nostrum.com> In-Reply-To: <4CD7B21C.2000600@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: Re: [core] Towards authc/authz user cases X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 09:20:45 -0000 Dear Adam, There are a lot of assumptions in your solution. For me it is not even clear that we need authorization for small devices. A= nd when we need it in a CoAP environment, the security technology burden ma= y be such that we have to resort to other techniques. These other technique= s will be very application dependent. My suggestion is to first get more insight in the security needs which exis= t in various scenarios and applications. Then look at consequences of exist= ing technologies, and probably continue with coap solutions where needed. Peter van der stok -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Ada= m Roach Sent: Monday 8 November 2010 9:18 To: CORE (Constrained RESTful Environments) WG Subject: [core] Towards authc/authz user cases In today's meeting, Carsten brought up the topic of the kinds of authentication and authorization models we want to consider for CoRE, in particular when you start using proxies. I'm think of this mostly in terms of a CoRE server, an HTTP client, and an HTTP/CoRE proxy in the middle: +--------+ +-------+ +--------+ | Client |------| Proxy |------| Server | +--------+ HTTP +-------+ CoRE +--------+ In this context, Carsten spoke of the "big friend" model. Under this model, the Proxy would use normal HTTP authentication mechanisms (e.g., Basic over TLS, or Digest). It then checks its own local ACLs for authorization purposes, and provides access only to those resources on the server that the authenticated user is allowed to access. The use cases for this model are pretty obvious: very simple servers that can't reasonably be provisioned with user information (e.g., light switches), where the nature of what can be done (e.g., turning lights on and off) is reasonable to trust the proxy with. For the sake of concreteness, let's nail down the nature of the proxy. Let's assume that this proxy is inside my electric meter, and is administered by my power utility company. But let's assume they're pretty progressive, and let me access the proxy so that I can remotely monitor and control my various CoAP-attached devices. Now, with that in place, let's consider something other than light switches. Let's think about my CoAP-attached alarm system, and my CoAP-controllable deadbolt lock. If we pursue only the model under which the proxy authenticates the user and then has free reign over the various home-area-network devices, this would potentially give a set of power utility employees the ability to monitor and control my alarm system and my front-door deadbolt. This gives me pause. So, in addition to the "big friend" model, I think it's clear that we need the ability for the client to authenticate end-to-end, through the proxy. And, since the proxy can only marginally be trusted in this case, we need to make sure it can't lift the credentials from, say, HTTP basic auth it receives over TLS connections. Without defining a new model for HTTP, it seems that this situation kind of requires the ability to interwork HTTP digest parameters with semantically equivalent CoAP parameters. /a _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From ekr@rtfm.com Mon Nov 8 01:36:31 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF3A63A68BF for ; Mon, 8 Nov 2010 01:36:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.724 X-Spam-Level: X-Spam-Status: No, score=-101.724 tagged_above=-999 required=5 tests=[AWL=0.252, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d8sJIqgFu965 for ; Mon, 8 Nov 2010 01:36:29 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 112153A693C for ; Mon, 8 Nov 2010 01:36:28 -0800 (PST) Received: by gxk27 with SMTP id 27so1916928gxk.31 for ; Mon, 08 Nov 2010 01:36:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.90.2.23 with SMTP id 23mr5030368agb.97.1289209009347; Mon, 08 Nov 2010 01:36:49 -0800 (PST) Received: by 10.91.78.6 with HTTP; Mon, 8 Nov 2010 01:36:49 -0800 (PST) In-Reply-To: References: <4CD7B21C.2000600@nostrum.com> Date: Mon, 8 Nov 2010 01:36:49 -0800 Message-ID: From: Eric Rescorla To: "Stok, Peter van der" Content-Type: multipart/alternative; boundary=00163631086b0b1be70494875d22 Cc: "CORE \(Constrained RESTful Environments\) WG" Subject: Re: [core] Towards authc/authz user cases X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 09:36:31 -0000 --00163631086b0b1be70494875d22 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Nov 8, 2010 at 1:21 AM, Stok, Peter van der < peter.van.der.stok@philips.com> wrote: > Dear Adam, > > There are a lot of assumptions in your solution. > For me it is not even clear that we need authorization for small devices. Well, this is precisely why I asked the question about threat models. Naively, if the light switches or locks in my house are controlled by IP, I'd like some authentication, I would think. -Ekr > And when we need it in a CoAP environment, the security technology burden > may be such that we have to resort to other techniques. These other > techniques will be very application dependent. > > My suggestion is to first get more insight in the security needs which > exist in various scenarios and applications. Then look at consequences of > existing technologies, and probably continue with coap solutions where > needed. > > Peter van der stok > > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of > Adam Roach > Sent: Monday 8 November 2010 9:18 > To: CORE (Constrained RESTful Environments) WG > Subject: [core] Towards authc/authz user cases > > In today's meeting, Carsten brought up the topic of the kinds of > authentication and authorization models we want to consider for CoRE, in > particular when you start using proxies. I'm think of this mostly in > terms of a CoRE server, an HTTP client, and an HTTP/CoRE proxy in the > middle: > > +--------+ +-------+ +--------+ > | Client |------| Proxy |------| Server | > +--------+ HTTP +-------+ CoRE +--------+ > > In this context, Carsten spoke of the "big friend" model. Under this > model, the Proxy would use normal HTTP authentication mechanisms (e.g., > Basic over TLS, or Digest). It then checks its own local ACLs for > authorization purposes, and provides access only to those resources on > the server that the authenticated user is allowed to access. The use > cases for this model are pretty obvious: very simple servers that can't > reasonably be provisioned with user information (e.g., light switches), > where the nature of what can be done (e.g., turning lights on and off) > is reasonable to trust the proxy with. > > For the sake of concreteness, let's nail down the nature of the proxy. > Let's assume that this proxy is inside my electric meter, and is > administered by my power utility company. But let's assume they're > pretty progressive, and let me access the proxy so that I can remotely > monitor and control my various CoAP-attached devices. > > Now, with that in place, let's consider something other than light > switches. Let's think about my CoAP-attached alarm system, and my > CoAP-controllable deadbolt lock. > > If we pursue only the model under which the proxy authenticates the user > and then has free reign over the various home-area-network devices, this > would potentially give a set of power utility employees the ability to > monitor and control my alarm system and my front-door deadbolt. > > This gives me pause. > > So, in addition to the "big friend" model, I think it's clear that we > need the ability for the client to authenticate end-to-end, through the > proxy. And, since the proxy can only marginally be trusted in this case, > we need to make sure it can't lift the credentials from, say, HTTP basic > auth it receives over TLS connections. > > Without defining a new model for HTTP, it seems that this situation kind > of requires the ability to interwork HTTP digest parameters with > semantically equivalent CoAP parameters. > > /a > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > 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 > --00163631086b0b1be70494875d22 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

    On Mon, Nov 8, 2010 at 1:21 AM, Stok, Pe= ter van der <peter.van.der.stok@philips.com> wrote:
    Dear Adam,

    There are a lot of assumptions in your solution.
    For me it is not even clear that we need authorization for small devices. <= /blockquote>

    Well, this is precisely why I asked the que= stion about threat models.

    Naively, if the light s= witches or locks in my house are controlled by IP, I'd like some authen= tication,
    I would think.

    -Ekr
    =A0
    And when we need it in a CoAP environment, the se= curity technology burden may be such that we have to resort to other techni= ques. These other techniques will be very application dependent.

    My suggestion is to first get more insight in the security needs which exis= t in various scenarios and applications. Then look at consequences of exist= ing technologies, and probably continue with coap solutions where needed.
    Peter van der stok

    -----Original Message-----
    From: core-bounces@ietf.org [m= ailto:core-bounces@ietf.org] O= n Behalf Of Adam Roach
    Sent: Monday 8 November 2010 9:18
    To: CORE (Constrained RESTful Environments) WG
    Subject: [core] Towards authc/authz user cases

    In today's meeting, Carsten brought up the topic of the kinds of
    authentication and authorization models we want to consider for CoRE, in particular when you start using proxies. I'm think of this mostly in terms of a CoRE server, an HTTP client, and an HTTP/CoRE proxy in the
    middle:

    +--------+ +-------+ +--------+
    | Client |------| Proxy |------| Server |
    +--------+ HTTP +-------+ CoRE +--------+

    In this context, Carsten spoke of the "big friend" model. Under t= his
    model, the Proxy would use normal HTTP authentication mechanisms (e.g.,
    Basic over TLS, or Digest). It then checks its own local ACLs for
    authorization purposes, and provides access only to those resources on
    the server that the authenticated user is allowed to access. The use
    cases for this model are pretty obvious: very simple servers that can't=
    reasonably be provisioned with user information (e.g., light switches),
    where the nature of what can be done (e.g., turning lights on and off)
    is reasonable to trust the proxy with.

    For the sake of concreteness, let's nail down the nature of the proxy.<= br> Let's assume that this proxy is inside my electric meter, and is
    administered by my power utility company. But let's assume they're<= br> pretty progressive, and let me access the proxy so that I can remotely
    monitor and control my various CoAP-attached devices.

    Now, with that in place, let's consider something other than light
    switches. Let's think about my CoAP-attached alarm system, and my
    CoAP-controllable deadbolt lock.

    If we pursue only the model under which the proxy authenticates the user and then has free reign over the various home-area-network devices, this would potentially give a set of power utility employees the ability to
    monitor and control my alarm system and my front-door deadbolt.

    This gives me pause.

    So, in addition to the "big friend" model, I think it's clear= that we
    need the ability for the client to authenticate end-to-end, through the
    proxy. And, since the proxy can only marginally be trusted in this case, we need to make sure it can't lift the credentials from, say, HTTP basi= c
    auth it receives over TLS connections.

    Without defining a new model for HTTP, it seems that this situation kind of requires the ability to interwork HTTP digest parameters with
    semantically equivalent CoAP parameters.

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

    The information contained in this message may be confidential a= nd legally protected under applicable law. The message is intended solely f= or the addressee(s). If you are not the intended recipient, you are hereby = notified that any use, forwarding, dissemination, or reproduction of this m= essage is strictly prohibited and may be unlawful. If you are not the inten= ded recipient, please contact the sender by return e-mail and destroy all c= opies of the original message.

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

    --00163631086b0b1be70494875d22-- From robert.cragie@gridmerge.com Mon Nov 8 01:56:50 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6E1B3A6959 for ; Mon, 8 Nov 2010 01:56:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.478 X-Spam-Level: X-Spam-Status: No, score=-3.478 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-V2WsBDvYxg for ; Mon, 8 Nov 2010 01:56:49 -0800 (PST) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id 655FD28C0F2 for ; Mon, 8 Nov 2010 01:56:48 -0800 (PST) Received: from client-86-29-103-19.glfd.adsl.virginmedia.com ([86.29.103.19] helo=[192.168.1.80]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) id 1PFOTL-0006zJ-Sf; Mon, 08 Nov 2010 09:57:08 +0000 Message-ID: <4CD7C969.1000409@gridmerge.com> Date: Mon, 08 Nov 2010 09:56:57 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Adam Roach References: <4CD7B21C.2000600@nostrum.com> In-Reply-To: <4CD7B21C.2000600@nostrum.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000505000402030409050404" Cc: "CORE \(Constrained RESTful Environments\) WG" Subject: Re: [core] Towards authc/authz user cases X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2010 09:56:51 -0000 This is a cryptographically signed message in MIME format. --------------ms000505000402030409050404 Content-Type: multipart/alternative; boundary="------------080606010903010601080903" This is a multi-part message in MIME format. --------------080606010903010601080903 Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: quoted-printable Hi Adam, Comments below, bracketed by Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com On 08/11/2010 8:17 AM, Adam Roach wrote: > In today's meeting, Carsten brought up the topic of the kinds of=20 > authentication and authorization models we want to consider for CoRE,=20 > in particular when you start using proxies. I'm think of this mostly=20 > in terms of a CoRE server, an HTTP client, and an HTTP/CoRE proxy in=20 > the middle: > > +--------+ +-------+ +--------+ > | Client |------| Proxy |------| Server | > +--------+ HTTP +-------+ CoRE +--------+ > > In this context, Carsten spoke of the "big friend" model. Under this=20 > model, the Proxy would use normal HTTP authentication mechanisms=20 > (e.g., Basic over TLS, or Digest). It then checks its own local ACLs=20 > for authorization purposes, and provides access only to those=20 > resources on the server that the authenticated user is allowed to=20 > access. The use cases for this model are pretty obvious: very simple=20 > servers that can't reasonably be provisioned with user information=20 > (e.g., light switches), where the nature of what can be done (e.g.,=20 > turning lights on and off) is reasonable to trust the proxy with. > > For the sake of concreteness, let's nail down the nature of the proxy. = > Let's assume that this proxy is inside my electric meter, and is=20 > administered by my power utility company. But let's assume they're=20 > pretty progressive, and let me access the proxy so that I can remotely = > monitor and control my various CoAP-attached devices. > > Now, with that in place, let's consider something other than light=20 > switches. Let's think about my CoAP-attached alarm system, and my=20 > CoAP-controllable deadbolt lock. CoAP-attached to what and CoAP-controllable by what? These may be=20 part of the same home network but that doesn't necessary imply=20 attachment or controllability in an application domain. > > If we pursue only the model under which the proxy authenticates the=20 > user and then has free reign over the various home-area-network=20 > devices, this would potentially give a set of power utility employees=20 > the ability to monitor and control my alarm system and my front-door=20 > deadbolt. So why would we pursue that model? There is the notion of an=20 authentication server from the point of view of network access but there = is also a distinct notion of different authentication servers in the=20 application domain separating the application domains (or indeed=20 combining them at a node if it makes sense). These are Carsten's big=20 friend, or indeed, friends; plural implies multiple service providers so = the utility may be one of those but there is provision for other service = providers too. > > This gives me pause. > > So, in addition to the "big friend" model, I think it's clear that we=20 > need the ability for the client to authenticate end-to-end, through=20 > the proxy. And, since the proxy can only marginally be trusted in this = > case, we need to make sure it can't lift the credentials from, say,=20 > HTTP basic auth it receives over TLS connections. Why would the proxy only be marginally trusted? End to end is=20 preferable as it provides a secure association between peer. However if=20 a peer (client/server) and proxy is authenticated independently in both=20 federated domains, it can be trusted across those domains even if there=20 is no secure association. Authentication can be delegated to the proxy=20 'big friend',which can grant authorization tokens to the application=20 peers it is friendly with (including itself). The application peers can=20 then mutually authenticate they both know the big friend. > > Without defining a new model for HTTP, it seems that this situation=20 > kind of requires the ability to interwork HTTP digest parameters with=20 > semantically equivalent CoAP parameters. > > /a > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --------------080606010903010601080903 Content-Type: text/html; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Hi Adam,

    Comments below, bracketed by <RCC></RCC>

    Robert

    Robert Cragie (Pacific Gas & Electric)

    Gridmerge Ltd.
    89 Greenfield Crescent,
    Wakefield, WF4 4WA, UK
    +44 1924 910888
    +1 415 513 0064
    http://www.gridmerge.com


    On 08/11/2010 8:17 AM, Adam Roach wrote:
    I= n today's meeting, Carsten brought up the topic of the kinds of authentication and authorization models we want to consider for CoRE, in particular when you start using proxies. I'm think of this mostly in terms of a CoRE server, an HTTP client, and an HTTP/CoRE proxy in the middle:

    +--------+ +-------+ +--------+
    | Client |------| Proxy |------| Server |
    +--------+ HTTP +-------+ CoRE +--------+

    In this context, Carsten spoke of the "big friend" model. Under this model, the Proxy would use normal HTTP authentication mechanisms (e.g., Basic over TLS, or Digest). It then checks its own local ACLs for authorization purposes, and provides access only to those resources on the server that the authenticated user is allowed to access. The use cases for this model are pretty obvious: very simple servers that can't reasonably be provisioned with user information (e.g., light switches), where the nature of what can be done (e.g., turning lights on and off) is reasonable to trust the proxy with.

    For the sake of concreteness, let's nail down the nature of the proxy. Let's assume that this proxy is inside my electric meter, and is administered by my power utility company. But let's assume they're pretty progressive, and let me access the proxy so that I can remotely monitor and control my various CoAP-attached devices.

    Now, with that in place, let's consider something other than light switches. Let's think about my CoAP-attached alarm system, and my CoAP-controllable deadbolt lock.
    <RCC>CoAP-attached to what and CoAP-controllable by what? These may be part of the same home network but that doesn't necessary imply attachment or controllability in an application domain.</RCC>
    =
    If we pursue only the model under which the proxy authenticates the user and then has free reign over the various home-area-network devices, this would potentially give a set of power utility employees the ability to monitor and control my alarm system and my front-door deadbolt.
    <RCC>So why would we pursue that model? There is the notion of an authentication server from the point of view of network access but there is also a distinct notion of different authentication servers in the application domain separating the application domains (or indeed combining them at a node if it makes sense). These are Carsten's big friend, or indeed, friends; plural implies multiple service providers so the utility may be one of those but there is provision for other service providers too.</RCC>
    =
    This gives me pause.

    So, in addition to the "big friend" model, I think it's clear that we need the ability for the client to authenticate end-to-end, through the proxy. And, since the proxy can only marginally be trusted in this case, we need to make sure it can't lift the credentials from, say, HTTP basic auth it receives over TLS connections.
    <RCC>Why would the proxy only be marginally trusted? End to end is preferable as it provides a secure association between peer. However if a peer (client/server) and proxy is authenticated independently in both federated domains, it can be trusted across those domains even if there is no secure association. Authentication can be delegated to the proxy 'big friend',which can grant authorization tokens to the application peers it is friendly with (including itself). The application peers can then mutually authenticate they both know the big friend.</RCC>
    =
    Without defining a new model for HTTP, it seems that this situation kind of requires the ability to interwork HTTP digest parameters with semantically equivalent CoAP parameters.

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

    --------------080606010903010601080903-- --------------ms000505000402030409050404 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRZTCC BN0wggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UE BhMCR0IxGzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEa MBgGA1UECgwRQ29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJV UzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUg VVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWls MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5 ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqk kqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWL eeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJ Q/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udl y/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0jBBgwFoAUoBEKIz6W8Qfs 4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQE AwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAR BgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5jb21vZG9j YS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwuY29t b2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvz bRx8NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12 jMOCAU9sAPMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxog L5dMUbtGB8SKN04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNB pEMD9O3vMyfbOeAUTibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mY HK9/FX8wggY+MIIFJqADAgECAhEAtlwUjTTxveqQY8soFvBYEjANBgkqhkiG9w0BAQUFADCB rjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEe MBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVz ZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIGFuZCBFbWFpbDAeFw0xMDA4MzAwMDAwMDBaFw0xMTA4MzAyMzU5NTlaMIHkMTUwMwYD VQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBFUlNPTkEgTk9UIFZBTElEQVRFRDFGMEQG A1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5u ZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMyBDb21vZG8gTGltaXRlZDEWMBQGA1UE AxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVy Z2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtAJ+m9Tgd3li8BgAIRth Gtth3YcCbhLPjfAcnDKcEGSrkZqao79Jg2uDW62IOwNCq9ae3VweBlvg3UUVu8upXzgDR/jF z4S1ZNk1if6V9QEiyBHdE1qMUQeeytedk3qw93CU5snWiXgVRacU8H8Dv+WJPsb4WYAH4MBz aJMI2N/E5XGGYpKFj9vxnEiQ7h83jXxw3Ee2rXCCbhJEci/tUl+Cx40pB3m7nlEdASY+A3tq JLIiG8Argf0+bWaxmuSUihKoakhHQruAylWY9EVtbKg8SACYZhdHCx2+ZSSrxbbAKSv0cDk0 0vQPvgH5GEi6zSB9QvqWCdBH/rL0XfV5jQIDAQABo4ICHTCCAhkwHwYDVR0jBBgwFoAUiYJn fcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFGkahOqOBMk95XAb8dpcRdaef8AYMA4GA1Ud DwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIx AQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzAp BggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCB mjBMoEqgSIZGaHR0cDovL2NybC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRB dXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0 L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYB BQUHAQEEYDBeMDYGCCsGAQUFBzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFD bGllbnRDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNV HREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEB ADcjSJQKgVIfD/IztFrhx2YqR9mKsDs3XakKd4hUoeunHgskiaMIQY2Kcfob48OuzrfY73rN fNoaqr5LZwDeVflMnZd0rPcTA9rAHq5l/qwdSta3k0xvBui0NAtOrSBdbqC4vggLKuZvoR2o 7mSbxSSBZHuVLObx/E5E+D5fjWC7ffNvr9y/uFXeCYFsM+Hc9VPIZ+cAY7JQFJEK/Nuti2QH IIxdR91N2vHuNXWIPROPFMl7y8ltO/fONwhxMcY2dH4JkDH6pdNzMtzykvsO0NeiRHnNlS4K A8aD9RaBR8FNQHq+JusC2tf11qdHBpHrVAK7dHodKDnbRr2t9VdrU2owggY+MIIFJqADAgEC AhEAtlwUjTTxveqQY8soFvBYEjANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJU UlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNV BAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0x MDA4MzAwMDAwMDBaFw0xMTA4MzAyMzU5NTlaMIHkMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3Qg TmV0d29yayAtIFBFUlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENv bmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0G A1UECxMWKGMpMjAwMyBDb21vZG8gTGltaXRlZDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEq MCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtAJ+m9Tgd3li8BgAIRthGtth3YcCbhLPjfAcnDKcEGSr kZqao79Jg2uDW62IOwNCq9ae3VweBlvg3UUVu8upXzgDR/jFz4S1ZNk1if6V9QEiyBHdE1qM UQeeytedk3qw93CU5snWiXgVRacU8H8Dv+WJPsb4WYAH4MBzaJMI2N/E5XGGYpKFj9vxnEiQ 7h83jXxw3Ee2rXCCbhJEci/tUl+Cx40pB3m7nlEdASY+A3tqJLIiG8Argf0+bWaxmuSUihKo akhHQruAylWY9EVtbKg8SACYZhdHCx2+ZSSrxbbAKSv0cDk00vQPvgH5GEi6zSB9QvqWCdBH /rL0XfV5jQIDAQABo4ICHTCCAhkwHwYDVR0jBBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0w HQYDVR0OBBYEFGkahOqOBMk95XAb8dpcRdaef8AYMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMB Af8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEE BAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6 Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0cDovL2Ny bC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVt YWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xp ZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQUF BzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwYB BQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRtyb2JlcnQuY3Jh Z2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBADcjSJQKgVIfD/IztFrhx2Yq R9mKsDs3XakKd4hUoeunHgskiaMIQY2Kcfob48OuzrfY73rNfNoaqr5LZwDeVflMnZd0rPcT A9rAHq5l/qwdSta3k0xvBui0NAtOrSBdbqC4vggLKuZvoR2o7mSbxSSBZHuVLObx/E5E+D5f jWC7ffNvr9y/uFXeCYFsM+Hc9VPIZ+cAY7JQFJEK/Nuti2QHIIxdR91N2vHuNXWIPROPFMl7 y8ltO/fONwhxMcY2dH4JkDH6pdNzMtzykvsO0NeiRHnNlS4KA8aD9RaBR8FNQHq+JusC2tf1 1qdHBpHrVAK7dHodKDnbRr2t9VdrU2oxggRgMIIEXAIBATCBxDCBrjELMAkGA1UEBhMCVVMx CzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVT RVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0 BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIR ALZcFI008b3qkGPLKBbwWBIwCQYFKw4DAhoFAKCCAnAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTAxMTA4MDk1NjU3WjAjBgkqhkiG9w0BCQQxFgQUGqTd gfK5QXH9gt9rWedrQ7SI8scwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJV VDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4t VVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQC2XBSNNPG96pBj yygW8FgSMIHXBgsqhkiG9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgT AlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBO ZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIRALZcFI008b3q kGPLKBbwWBIwDQYJKoZIhvcNAQEBBQAEggEAcMnw0/g7cyLv/2SOOjS/TurojFY4y2ns2WIY raH2dHhPicbVEY2xd3tw8ia3Ue+g4MyAYVNID1g2d/5lCLkNYQFziGZK6N50Uv5UAm8Uywzv z6CCyuCzxDyq9yaVdnkhHxSYS+CpxyJWSGBtzvaFS4AavTrtXUO2ETSmp/2rxPEgqVFfapkP LI2cg+tE5cNB49WixqoIqn/I8l9quHFuaaMwUzqheLCA9MpYAQAZckdIrDq1i3GuH3+6avlR +rjpJn3J9QNKwmvJH/lGtRRcTSSIwllvQzzpr6YcaFoVPWCsFkRhZ+umMIRiSIaqWkrP8dj2 yB985jwsg96qtT8N1QAAAAAAAA== --------------ms000505000402030409050404-- From tianlinyi@huawei.com Mon Nov 8 01:58:38 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B19083A6966 for ; Mon, 8 Nov 2010 01:58:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.352 X-Spam-Level: *** X-Spam-Status: No, score=3.352 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1aV+BQNYo6I for ; Mon, 8 Nov 2010 01:58:37 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id C52603A6979 for ; Mon, 8 Nov 2010 01:58:36 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LBK00DVD90NJX@szxga03-in.huawei.com> for core@ietf.org; Mon, 08 Nov 2010 17:58:01 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LBK006EL8ZNZT@szxga03-in.huawei.com> for core@ietf.org; Mon, 08 Nov 2010 17:57:56 +0800 (CST) Received: from [130.129.131.148] (dhcp-8394.meeting.ietf.org [130.129.131.148]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LBK0029M8ZZAZ@szxml02-in.huawei.com>; Mon, 08 Nov 2010 17:57:44 +0800 (CST) Date: Mon, 08 Nov 2010 17:57:34 +0800 From: Linyi Tian In-reply-to: To: Eric Rescorla , "Stok, Peter van der" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_GWc6UQM6STSBkuvikHqfCg)" Thread-topic: [core] Towards authc/authz user cases Thread-index: Act/K12MxJ9zSQ3UWEqW9si+BOl7Mg== User-Agent: Microsoft-Entourage/12.25.0.100505 Cc: "CORE \(Constrained RESTful Environments\) WG" Subject: Re: [core] Towards authc/authz user cases X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 09:58:38 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --Boundary_(ID_GWc6UQM6STSBkuvikHqfCg) Content-type: text/plain; charset=GB2312 Content-transfer-encoding: quoted-printable Hi, Adam and Peter Adam did raised some interesting issue regarding security. For example who will be authorized to control the door lock. Whether the device should trus= t the control message from the proxy? I think Peter made a good point that we need to get more insight in the scenarios/enrionment. In the electric meter scenario it makes sense that th= e power utility company takes the full control of the electric meter. In this case the big friend model will work. In the door lock case, the proxy most likely will be operated by the house owner, e.g. home gateway. The application who is allowed to control the door lock should be under control by the user as well. For example, the application can be installed in the mobile phone and interacts with the proxy over internet. In this case the application has to be authenticated and authorized by the proxy first. If the proxy and device are in trusted environment the authentication/authorization may not needed. otherwise it MUST be provided to avoid security holes. Cheers, Linyi On 10-11-8 =CF=C2=CE=E75:36, "Eric Rescorla" wrote: >=20 >=20 > On Mon, Nov 8, 2010 at 1:21 AM, Stok, Peter van der > wrote: >> Dear Adam, >>=20 >> There are a lot of assumptions in your solution. >> For me it is not even clear that we need authorization for small devices= . >=20 > Well, this is precisely why I asked the question about threat models. >=20 > Naively, if the light switches or locks in my house are controlled by IP,= I'd > like some authentication, > I would think. >=20 > -Ekr > =20 >> And when we need it in a CoAP environment, the security technology burde= n may >> be such that we have to resort to other techniques. These other techniqu= es >> will be very application dependent. >>=20 >> My suggestion is to first get more insight in the security needs which e= xist >> in various scenarios and applications. Then look at consequences of exis= ting >> technologies, and probably continue with coap solutions where needed. >>=20 >> Peter van der stok >>=20 >> -----Original Message----- >> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of = Adam >> Roach >> Sent: Monday 8 November 2010 9:18 >> To: CORE (Constrained RESTful Environments) WG >> Subject: [core] Towards authc/authz user cases >>=20 >> In today's meeting, Carsten brought up the topic of the kinds of >> authentication and authorization models we want to consider for CoRE, in >> particular when you start using proxies. I'm think of this mostly in >> terms of a CoRE server, an HTTP client, and an HTTP/CoRE proxy in the >> middle: >>=20 >> +--------+ +-------+ +--------+ >> | Client |------| Proxy |------| Server | >> +--------+ HTTP +-------+ CoRE +--------+ >>=20 >> In this context, Carsten spoke of the "big friend" model. Under this >> model, the Proxy would use normal HTTP authentication mechanisms (e.g., >> Basic over TLS, or Digest). It then checks its own local ACLs for >> authorization purposes, and provides access only to those resources on >> the server that the authenticated user is allowed to access. The use >> cases for this model are pretty obvious: very simple servers that can't >> reasonably be provisioned with user information (e.g., light switches), >> where the nature of what can be done (e.g., turning lights on and off) >> is reasonable to trust the proxy with. >>=20 >> For the sake of concreteness, let's nail down the nature of the proxy. >> Let's assume that this proxy is inside my electric meter, and is >> administered by my power utility company. But let's assume they're >> pretty progressive, and let me access the proxy so that I can remotely >> monitor and control my various CoAP-attached devices. >>=20 >> Now, with that in place, let's consider something other than light >> switches. Let's think about my CoAP-attached alarm system, and my >> CoAP-controllable deadbolt lock. >>=20 >> If we pursue only the model under which the proxy authenticates the user >> and then has free reign over the various home-area-network devices, this >> would potentially give a set of power utility employees the ability to >> monitor and control my alarm system and my front-door deadbolt. >>=20 >> This gives me pause. >>=20 >> So, in addition to the "big friend" model, I think it's clear that we >> need the ability for the client to authenticate end-to-end, through the >> proxy. And, since the proxy can only marginally be trusted in this case, >> we need to make sure it can't lift the credentials from, say, HTTP basic >> auth it receives over TLS connections. >>=20 >> Without defining a new model for HTTP, it seems that this situation kind >> of requires the ability to interwork HTTP digest parameters with >> semantically equivalent CoAP parameters. >>=20 >> /a >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >>=20 >> The information contained in this message may be confidential and legall= y >> protected under applicable law. The message is intended solely for the >> addressee(s). If you are not the intended recipient, you are hereby noti= fied >> 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 co= pies >> of the original message. >>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >=20 >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --Boundary_(ID_GWc6UQM6STSBkuvikHqfCg) Content-type: text/html; charset=GB2312 Content-transfer-encoding: quoted-printable Re: [core] Towards authc/authz user cases Hi, Adam and Peter

    Adam did raised some interesting issue regarding security. For example who = will be authorized to control the door lock. Whether the device should trust= the control message from the proxy?

    I think Peter made a good point that we need to get more insight in the sce= narios/enrionment. In the electric meter scenario it makes sense that the po= wer utility company takes the full control of the electric meter. In this ca= se the big friend model will work. In the door lock case, the proxy most lik= ely will be operated by the house owner, e.g. home gateway. The application = who is allowed to control the door lock should be under control by the user = as well. For example, the application can be installed in the mobile phone a= nd interacts with the proxy over internet. In this case the application has = to be authenticated and authorized by the proxy first. If the proxy and devi= ce are in trusted environment the authentication/authorization may not neede= d. otherwise it MUST be provided to avoid security holes.

    Cheers,
    Linyi



    On 10-11-8 =CF=C2=CE=E75:36, "Eric Rescorla" <e= kr@rtfm.com> wrote:

    <= SPAN STYLE=3D'font-size:11pt'>

    On Mon, Nov 8, 2010 at 1:21 AM, Stok, Peter van der <peter.van.der.stok@philips.com> wrote:
    <= SPAN STYLE=3D'font-size:11pt'>Dear Adam,

    There are a lot of assumptions in your solution.
    For me it is not even clear that we need authorization for small devices. <= BR>
    =
    Well, this is precisely why I asked the question about threat models.

    Naively, if the light switches or locks in my house are controlled by IP, I= 'd like some authentication,
    I would think.

    -Ekr

    <= SPAN STYLE=3D'font-size:11pt'>And when we need it in a CoAP environment, the s= ecurity technology burden may be such that we have to resort to other techni= ques. These other techniques will be very application dependent.

    My suggestion is to first get more insight in the security needs which exis= t in various scenarios and applications. Then look at consequences of existi= ng technologies, and probably continue with coap solutions where needed.

    Peter van der stok

    -----Original Message-----
    From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of = Adam Roach
    Sent: Monday 8 November 2010 9:18
    To: CORE (Constrained RESTful Environments) WG
    Subject: [core] Towards authc/authz user cases

    In today's meeting, Carsten brought up the topic of the kinds of
    authentication and authorization models we want to consider for CoRE, in particular when you start using proxies. I'm think of this mostly in
    terms of a CoRE server, an HTTP client, and an HTTP/CoRE proxy in the
    middle:

    +--------+ +-------+ +--------+
    | Client |------| Proxy |------| Server |
    +--------+ HTTP +-------+ CoRE +--------+

    In this context, Carsten spoke of the "big friend" model. Under t= his
    model, the Proxy would use normal HTTP authentication mechanisms (e.g.,
    Basic over TLS, or Digest). It then checks its own local ACLs for
    authorization purposes, and provides access only to those resources on
    the server that the authenticated user is allowed to access. The use
    cases for this model are pretty obvious: very simple servers that can't
    reasonably be provisioned with user information (e.g., light switches),
    where the nature of what can be done (e.g., turning lights on and off)
    is reasonable to trust the proxy with.

    For the sake of concreteness, let's nail down the nature of the proxy.
    Let's assume that this proxy is inside my electric meter, and is
    administered by my power utility company. But let's assume they're
    pretty progressive, and let me access the proxy so that I can remotely
    monitor and control my various CoAP-attached devices.

    Now, with that in place, let's consider something other than light
    switches. Let's think about my CoAP-attached alarm system, and my
    CoAP-controllable deadbolt lock.

    If we pursue only the model under which the proxy authenticates the user and then has free reign over the various home-area-network devices, this would potentially give a set of power utility employees the ability to
    monitor and control my alarm system and my front-door deadbolt.

    This gives me pause.

    So, in addition to the "big friend" model, I think it's clear tha= t we
    need the ability for the client to authenticate end-to-end, through the
    proxy. And, since the proxy can only marginally be trusted in this case, we need to make sure it can't lift the credentials from, say, HTTP basic auth it receives over TLS connections.

    Without defining a new model for HTTP, it seems that this situation kind of requires the ability to interwork HTTP digest parameters with
    semantically equivalent CoAP parameters.

    /a
    _______________________________________________
    core mailing list
    core@ietf.org
    https://www.ietf.org/m= ailman/listinfo/core

    The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addres= see(s). If you are not the intended recipient, you are hereby notified that = any use, forwarding, dissemination, or reproduction of this message is stric= tly prohibited and may be unlawful. If you are not the intended recipient, p= lease contact the sender by return e-mail and destroy all copies of the orig= inal message.

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

    ___________= ____________________________________
    core mailing list
    core@ietf.org
    https://www.ietf.org/m= ailman/listinfo/core
    --Boundary_(ID_GWc6UQM6STSBkuvikHqfCg)-- From d.sturek@att.net Mon Nov 8 02:24:31 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF1FF28C13F for ; Mon, 8 Nov 2010 02:24:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dyGnrICMxbFj for ; Mon, 8 Nov 2010 02:24:30 -0800 (PST) Received: from web81406.mail.mud.yahoo.com (web81406.mail.mud.yahoo.com [68.142.199.134]) by core3.amsl.com (Postfix) with SMTP id 304533A6990 for ; Mon, 8 Nov 2010 02:24:30 -0800 (PST) Received: (qmail 7874 invoked by uid 60001); 8 Nov 2010 10:24:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1289211884; bh=V6/tSepU1941g5zuDr0HVrb1NPTeujemisXpuJwALvM=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=Tn2vVdc2PyHpeEvTA54zxfrgg0MFuRV3RO7N715o4eNLo6BduZ44AHOPMNnv5z70ovUHZZ4nAmLEsRAwDuLNeeSjJrKQjLV8Z4kG1JVAqKbVrpFEZz1R7+mHNzEkTlNQVvYyrSH6Nftl1gvYbOAjf2Y0z9Oh7aBg5Ml6BQvDHfk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=att.net; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=J3UfO5648GxuRpjdVLUV0CyYXgyqk1+vyySHgjxHohbpH5ZDCYVCMLyIX3rvtEGq7wKSAZjuBmXjdYO9G2G1Xf0h8DwOw12gw7dHk+h46SmqhIc52lVPbENqfx8kC6VFWj7/J0+317yOofCYPZtZhjJ5cqnmFOUCrJRNYCbG0Ds=; Message-ID: <54809.3102.qm@web81406.mail.mud.yahoo.com> X-YMail-OSG: KNxo1ZsVM1l7tYnOinmsQAk5GWkor9lteSkr_SMVDkm2rWs PbP_b5biWG6MKooPwVHlWpTkaSfgB9xwLbu38jfloAF.sMiIku17UJN8Z.VK 18ur4gON0Dag2QjTVbKSARKBlJxOGzx9FGK1VQANmLnvLs25DR0FIyb_g1MT edv1f0bMi6AylWPH6YRIY0QBQrzG_b1JCapxXnzSyc6_1XgQGmh1o1zDYodd yCBQ70YaGbNOIEaJHXs6buEqpm_KaLaVr8UYvWmJVSWD0ugHTE3iD.5TnwLc _uvDQhLOWpD9Z.x6bGylK6EYUN2Sl6y4fnTOATF.m0P_zbLwvHGIPS1HU9g- - Received: from [130.129.65.181] by web81406.mail.mud.yahoo.com via HTTP; Mon, 08 Nov 2010 02:24:43 PST X-Mailer: YahooMailRC/504.5 YahooMailWebService/0.8.107.284920 References: <4CD7B21C.2000600@nostrum.com> Date: Mon, 8 Nov 2010 02:24:43 -0800 (PST) From: Don Sturek To: Adam Roach , "CORE \(Constrained RESTful Environments\) WG" In-Reply-To: <4CD7B21C.2000600@nostrum.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-845576457-1289211883=:3102" Subject: Re: [core] Towards authc/authz user cases X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 10:24:31 -0000 --0-845576457-1289211883=:3102 Content-Type: text/plain; charset=us-ascii Hi Adam, I think your note below is a bad example. No electric company I know of will allow you access homeowner to a proxy in the meter and none (at least the US based utilities I know of) will allow un-enrolled access to anything other than meter usage data and information on price (and this access is authenticated for privacy reasons). If you enroll your devices in a utility program then you could also receive demand response messages. Really that is it in terms of services provided by the meter......... Now it is true that the meter usage data, price and other information can be used in the HAN for energy savings. The utility is not involved in this and does not host homeowner applications within the meter. The utility only supplies the requested data to the HAN devices to support that application. Don ________________________________ From: Adam Roach To: CORE (Constrained RESTful Environments) WG Sent: Mon, November 8, 2010 12:17:32 AM Subject: [core] Towards authc/authz user cases In today's meeting, Carsten brought up the topic of the kinds of authentication and authorization models we want to consider for CoRE, in particular when you start using proxies. I'm think of this mostly in terms of a CoRE server, an HTTP client, and an HTTP/CoRE proxy in the middle: +--------+ +-------+ +--------+ | Client |------| Proxy |------| Server | +--------+ HTTP +-------+ CoRE +--------+ In this context, Carsten spoke of the "big friend" model. Under this model, the Proxy would use normal HTTP authentication mechanisms (e.g., Basic over TLS, or Digest). It then checks its own local ACLs for authorization purposes, and provides access only to those resources on the server that the authenticated user is allowed to access. The use cases for this model are pretty obvious: very simple servers that can't reasonably be provisioned with user information (e.g., light switches), where the nature of what can be done (e.g., turning lights on and off) is reasonable to trust the proxy with. For the sake of concreteness, let's nail down the nature of the proxy. Let's assume that this proxy is inside my electric meter, and is administered by my power utility company. But let's assume they're pretty progressive, and let me access the proxy so that I can remotely monitor and control my various CoAP-attached devices. Now, with that in place, let's consider something other than light switches. Let's think about my CoAP-attached alarm system, and my CoAP-controllable deadbolt lock. If we pursue only the model under which the proxy authenticates the user and then has free reign over the various home-area-network devices, this would potentially give a set of power utility employees the ability to monitor and control my alarm system and my front-door deadbolt. This gives me pause. So, in addition to the "big friend" model, I think it's clear that we need the ability for the client to authenticate end-to-end, through the proxy. And, since the proxy can only marginally be trusted in this case, we need to make sure it can't lift the credentials from, say, HTTP basic auth it receives over TLS connections. Without defining a new model for HTTP, it seems that this situation kind of requires the ability to interwork HTTP digest parameters with semantically equivalent CoAP parameters. /a _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core --0-845576457-1289211883=:3102 Content-Type: text/html; charset=us-ascii
    Hi Adam,

    I think your note below is a bad example.   No electric company I know of will allow you access homeowner to a proxy in the meter and none (at least the US based utilities I know of) will allow un-enrolled access to anything other than meter usage data and information on price (and this access is authenticated for privacy reasons).  If you enroll your devices in a utility program then you could also receive demand response messages.  Really that is it in terms of services provided by the meter.........

    Now it is true that the meter usage data, price and other information can be used in the HAN for energy savings.  The utility is not involved in this and does not host homeowner applications within the meter.  The utility only supplies the requested data to the HAN devices to support that application.

    Don


    From: Adam Roach <adam@nostrum.com>
    To: CORE (Constrained RESTful Environments) WG <core@ietf.org>
    Sent: Mon, November 8, 2010 12:17:32 AM
    Subject: [core] Towards authc/authz user cases

    In today's meeting, Carsten brought up the topic of the kinds of authentication and authorization models we want to consider for CoRE, in particular when you start using proxies. I'm think of this mostly in terms of a CoRE server, an HTTP client, and an HTTP/CoRE proxy in the middle:

    +--------+ +-------+ +--------+
    | Client |------| Proxy |------| Server |
    +--------+ HTTP +-------+ CoRE +--------+

    In this context, Carsten spoke of the "big friend" model. Under this model, the Proxy would use normal HTTP authentication mechanisms (e.g., Basic over TLS, or Digest). It then checks its own local ACLs for authorization purposes, and provides access only to those resources on the server that the authenticated user is allowed to access. The use cases for this model are pretty obvious: very simple servers that can't reasonably be provisioned with user information (e.g., light switches), where the nature of what can be done (e.g., turning lights on and off) is reasonable to trust the proxy with.

    For the sake of concreteness, let's nail down the nature of the proxy. Let's assume that this proxy is inside my electric meter, and is administered by my power utility company. But let's assume they're pretty progressive, and let me access the proxy so that I can remotely monitor and control my various CoAP-attached devices.

    Now, with that in place, let's consider something other than light switches. Let's think about my CoAP-attached alarm system, and my CoAP-controllable deadbolt lock.

    If we pursue only the model under which the proxy authenticates the user and then has free reign over the various home-area-network devices, this would potentially give a set of power utility employees the ability to monitor and control my alarm system and my front-door deadbolt.

    This gives me pause.

    So, in addition to the "big friend" model, I think it's clear that we need the ability for the client to authenticate end-to-end, through the proxy. And, since the proxy can only marginally be trusted in this case, we need to make sure it can't lift the credentials from, say, HTTP basic auth it receives over TLS connections.

    Without defining a new model for HTTP, it seems that this situation kind of requires the ability to interwork HTTP digest parameters with semantically equivalent CoAP parameters.

    /a
    _______________________________________________
    core mailing list
    core@ietf.org
    https://www.ietf.org/mailman/listinfo/core
    --0-845576457-1289211883=:3102-- From peter.van.der.stok@philips.com Mon Nov 8 02:29:17 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1A2128C132 for ; Mon, 8 Nov 2010 02:29:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QkvK3POoXFbN for ; Mon, 8 Nov 2010 02:29:16 -0800 (PST) Received: from VA3EHSOBE008.bigfish.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by core3.amsl.com (Postfix) with ESMTP id 4607128C113 for ; Mon, 8 Nov 2010 02:29:16 -0800 (PST) Received: from mail4-va3-R.bigfish.com (10.7.14.244) by VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id 14.1.225.8; Mon, 8 Nov 2010 10:29:37 +0000 Received: from mail4-va3 (localhost.localdomain [127.0.0.1]) by mail4-va3-R.bigfish.com (Postfix) with ESMTP id 10906F3008A; Mon, 8 Nov 2010 10:29:37 +0000 (UTC) X-SpamScore: -54 X-BigFish: VPS-54(zz15d6O9251J9370J609J217bP9371Pzz1202hzz8275bh8275dh1033IL186Mz2dh2a8h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:NLAMSEXE03.connect1.local; RD:smtpx.philips.com; EFVD:NLI Received: from mail4-va3 (localhost.localdomain [127.0.0.1]) by mail4-va3 (MessageSwitch) id 128921217661408_595; Mon, 8 Nov 2010 10:29:36 +0000 (UTC) Received: from VA3EHSMHS029.bigfish.com (unknown [10.7.14.249]) by mail4-va3.bigfish.com (Postfix) with ESMTP id 077C1940050; Mon, 8 Nov 2010 10:29:36 +0000 (UTC) Received: from NLAMSEXE03.connect1.local (168.87.56.20) by VA3EHSMHS029.bigfish.com (10.7.99.39) with Microsoft SMTP Server (TLS) id 14.1.225.8; Mon, 8 Nov 2010 10:29:36 +0000 Received: from NLHILEXH04.connect1.local (172.16.153.45) by connect1.philips.com (172.16.156.42) with Microsoft SMTP Server (TLS) id 8.3.106.1; Mon, 8 Nov 2010 11:29:31 +0100 Received: from NLCLUEXM03.connect1.local ([172.16.157.42]) by NLHILEXH04.connect1.local ([172.16.153.45]) with mapi; Mon, 8 Nov 2010 11:29:34 +0100 From: "Stok, Peter van der" To: Don Sturek , Adam Roach , "CORE (Constrained RESTful Environments) WG" Date: Mon, 8 Nov 2010 11:29:35 +0100 Thread-Topic: [core] Towards authc/authz user cases Thread-Index: Act/LzPCraqZdZfBScCu9BbtR+e+KQAAH+hw Message-ID: References: <4CD7B21C.2000600@nostrum.com> <54809.3102.qm@web81406.mail.mud.yahoo.com> In-Reply-To: <54809.3102.qm@web81406.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_B5584ABB89131542BEA01BFAF71A73878664173989NLCLUEXM03con_" MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: Re: [core] Towards authc/authz user cases X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 10:29:17 -0000 --_000_B5584ABB89131542BEA01BFAF71A73878664173989NLCLUEXM03con_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Don, This is a good example of a use case. Ready to share it in a draft? (with a= bit more text?) Peter From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Don= Sturek Sent: Monday 8 November 2010 11:25 To: Adam Roach; CORE (Constrained RESTful Environments) WG Subject: Re: [core] Towards authc/authz user cases Hi Adam, I think your note below is a bad example. No electric company I know of w= ill allow you access homeowner to a proxy in the meter and none (at least t= he US based utilities I know of) will allow un-enrolled access to anything = other than meter usage data and information on price (and this access is au= thenticated for privacy reasons). If you enroll your devices in a utility = program then you could also receive demand response messages. Really that = is it in terms of services provided by the meter......... Now it is true that the meter usage data, price and other information can b= e used in the HAN for energy savings. The utility is not involved in this = and does not host homeowner applications within the meter. The utility onl= y supplies the requested data to the HAN devices to support that applicatio= n. Don ________________________________ From: Adam Roach To: CORE (Constrained RESTful Environments) WG Sent: Mon, November 8, 2010 12:17:32 AM Subject: [core] Towards authc/authz user cases In today's meeting, Carsten brought up the topic of the kinds of authentica= tion and authorization models we want to consider for CoRE, in particular w= hen you start using proxies. I'm think of this mostly in terms of a CoRE se= rver, an HTTP client, and an HTTP/CoRE proxy in the middle: +--------+ +-------+ +--------+ | Client |------| Proxy |------| Server | +--------+ HTTP +-------+ CoRE +--------+ In this context, Carsten spoke of the "big friend" model. Under this model,= the Proxy would use normal HTTP authentication mechanisms (e.g., Basic ove= r TLS, or Digest). It then checks its own local ACLs for authorization purp= oses, and provides access only to those resources on the server that the au= thenticated user is allowed to access. The use cases for this model are pre= tty obvious: very simple servers that can't reasonably be provisioned with = user information (e.g., light switches), where the nature of what can be do= ne (e.g., turning lights on and off) is reasonable to trust the proxy with. For the sake of concreteness, let's nail down the nature of the proxy. Let'= s assume that this proxy is inside my electric meter, and is administered b= y my power utility company. But let's assume they're pretty progressive, an= d let me access the proxy so that I can remotely monitor and control my var= ious CoAP-attached devices. Now, with that in place, let's consider something other than light switches= . Let's think about my CoAP-attached alarm system, and my CoAP-controllable= deadbolt lock. If we pursue only the model under which the proxy authenticates the user an= d then has free reign over the various home-area-network devices, this woul= d potentially give a set of power utility employees the ability to monitor = and control my alarm system and my front-door deadbolt. This gives me pause. So, in addition to the "big friend" model, I think it's clear that we need = the ability for the client to authenticate end-to-end, through the proxy. A= nd, since the proxy can only marginally be trusted in this case, we need to= make sure it can't lift the credentials from, say, HTTP basic auth it rece= ives over TLS connections. Without defining a new model for HTTP, it seems that this situation kind of= requires the ability to interwork HTTP digest parameters with semantically= equivalent CoAP parameters. /a _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. --_000_B5584ABB89131542BEA01BFAF71A73878664173989NLCLUEXM03con_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi Don,

     

    This is a good example of a use case. Ready to share it in a= draft? (with a bit more text?)

     

    Peter

     

    From: core-bou= nces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Don Sturek
    Sent: Monday 8 November 2010 11:25
    To: Adam Roach; CORE (Constrained RESTful Environments) WG
    Subject: Re: [core] Towards authc/authz user cases    =

     

    Hi Adam,

    I think your note below is a bad example.   No electric company I= know of will allow you access homeowner to a proxy in the meter and none (= at least the US based utilities I know of) will allow un-enrolled access to= anything other than meter usage data and information on price (and this access is authenticated for privacy reasons= ).  If you enroll your devices in a utility program then you could als= o receive demand response messages.  Really that is it in terms of ser= vices provided by the meter.........

    Now it is true that the meter usage data, price and other information can b= e used in the HAN for energy savings.  The utility is not involved in = this and does not host homeowner applications within the meter.  The u= tility only supplies the requested data to the HAN devices to support that application.

    Don

     

    From: Adam Roa= ch <adam@nostrum.com>
    To: CORE (Constrained RESTful Environments) WG <core@ietf.org>=
    Sent: Mon, November 8, 2010 12:17:32 AM
    Subject: [core] Towards authc/authz user cases

    In today's meeting, Carsten brought up the topic of the kinds of authentica= tion and authorization models we want to consider for CoRE, in particular w= hen you start using proxies. I'm think of this mostly in terms of a CoRE se= rver, an HTTP client, and an HTTP/CoRE proxy in the middle:

    +--------+ +-------+ +--------+
    | Client |------| Proxy |------| Server |
    +--------+ HTTP +-------+ CoRE +--------+

    In this context, Carsten spoke of the "big friend" model. Under t= his model, the Proxy would use normal HTTP authentication mechanisms (e.g.,= Basic over TLS, or Digest). It then checks its own local ACLs for authoriz= ation purposes, and provides access only to those resources on the server that the authenticated user is allowed to ac= cess. The use cases for this model are pretty obvious: very simple servers = that can't reasonably be provisioned with user information (e.g., light swi= tches), where the nature of what can be done (e.g., turning lights on and off) is reasonable to trust the p= roxy with.

    For the sake of concreteness, let's nail down the nature of the proxy. Let'= s assume that this proxy is inside my electric meter, and is administered b= y my power utility company. But let's assume they're pretty progressive, an= d let me access the proxy so that I can remotely monitor and control my various CoAP-attached devices.

    Now, with that in place, let's consider something other than light switches= . Let's think about my CoAP-attached alarm system, and my CoAP-controllable= deadbolt lock.

    If we pursue only the model under which the proxy authenticates the user an= d then has free reign over the various home-area-network devices, this woul= d potentially give a set of power utility employees the ability to monitor = and control my alarm system and my front-door deadbolt.

    This gives me pause.

    So, in addition to the "big friend" model, I think it's clear tha= t we need the ability for the client to authenticate end-to-end, through th= e proxy. And, since the proxy can only marginally be trusted in this case, = we need to make sure it can't lift the credentials from, say, HTTP basic auth it receives over TLS connections.

    Without defining a new model for HTTP, it seems that this situation kind of= requires the ability to interwork HTTP digest parameters with semantically= equivalent CoAP parameters.

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


    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_B5584ABB89131542BEA01BFAF71A73878664173989NLCLUEXM03con_-- From d.sturek@att.net Mon Nov 8 02:34:49 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFB4D28C113 for ; Mon, 8 Nov 2010 02:34:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0f3TRKFlDPj3 for ; Mon, 8 Nov 2010 02:34:47 -0800 (PST) Received: from web81402.mail.mud.yahoo.com (web81402.mail.mud.yahoo.com [68.142.199.130]) by core3.amsl.com (Postfix) with SMTP id BEFDC28C0F1 for ; Mon, 8 Nov 2010 02:34:47 -0800 (PST) Received: (qmail 12099 invoked by uid 60001); 8 Nov 2010 10:35:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1289212504; bh=f7GIMcxRzD6yANYxZNvK7pPPeCDYVy2NhoEoHLGO/MA=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=hgJ3UYcLk5Y5eRrYYALido+b5RFadrozgv3t4oaX8VKBpydo4bpURpyG+iENYbBWD9oQyYnxwqqjQJdI+WopaMRWrrcVmNsdxwPyUf3peRvFMIY6C4V393+NKNDUZ1x/kS5Aog/ANPunJgC85zC5j7gfmHjC3ieTYau/5q++X8Y= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=att.net; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=e4W5rsUc5JTqZIagUtATElIbu/KPloOIQCyeLBrxBe/UguOfHo80YVt6ZsQ0HITIn9SxIUWcqMKhNFaBAeYV3F9v9zvMypUahAmvGllLI8gifTJSFboKTqbEzn41DSTHU8hlq31SSxvdPV7s4ZYyo2vuIaGt2buSuVVqIkIYHvM=; Message-ID: <769644.11054.qm@web81402.mail.mud.yahoo.com> X-YMail-OSG: R6jUfUkVM1kHmAsdaMNbixx_ZwYnZ0YFSvyENvqaV65hmsV JKuBhDisVI88y_7v7Z5g6uqK84YosCv.1f1CirkzjV.19k9JqnynxW75SgNv ETsTVih4SuP6xPxbbNjnuz6Spl_llOmd3jXz_sngYzlGh5QvgOOeAVOu0m0v e3mjxuImD7QfJaZYpW1sXqbWOlXM3vLWJsQ9InnQfQKwYDrxkNryLtyLaCZU jg8Nxhb2jqdlE.FMR1BRsUZKgyQlmBMaqNpHg0FP7ZLgThHNrJ4uQWMwdYM6 NOmD0iSimECfIbcj91SVJUbjp6W9.5.OkIw0Ro0KeJZFJ2leBlMRK4JHWm7A EwEb1u1zDG2cglDp6rJN9G_XTdaSHsB.q Received: from [130.129.65.181] by web81402.mail.mud.yahoo.com via HTTP; Mon, 08 Nov 2010 02:35:04 PST X-Mailer: YahooMailRC/504.5 YahooMailWebService/0.8.107.284920 References: <4CD7B21C.2000600@nostrum.com> <54809.3102.qm@web81406.mail.mud.yahoo.com> Date: Mon, 8 Nov 2010 02:35:04 -0800 (PST) From: Don Sturek To: "Stok, Peter van der" , Adam Roach , "CORE \(Constrained RESTful Environments\) WG" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-886013751-1289212504=:11054" Subject: Re: [core] Towards authc/authz user cases X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 10:34:49 -0000 --0-886013751-1289212504=:11054 Content-Type: text/plain; charset=us-ascii Hi Peter, Both I and Tom Herbst have provided some input to http://datatracker.ietf.org/doc/draft-baker-ietf-core/ Appendix I. It should have a decent explanation of this use case. The main issue is the utilities do not want access from the HAN Devices to resources in the meter/Utility ESI nor do they want the HAN devices to have the ability to route back through the meter/utility ESI into the AMI. Don ________________________________ From: "Stok, Peter van der" To: Don Sturek ; Adam Roach ; CORE (Constrained RESTful Environments) WG Sent: Mon, November 8, 2010 2:29:35 AM Subject: RE: [core] Towards authc/authz user cases Hi Don, This is a good example of a use case. Ready to share it in a draft? (with a bit more text?) Peter From:core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Don Sturek Sent: Monday 8 November 2010 11:25 To: Adam Roach; CORE (Constrained RESTful Environments) WG Subject: Re: [core] Towards authc/authz user cases Hi Adam, I think your note below is a bad example. No electric company I know of will allow you access homeowner to a proxy in the meter and none (at least the US based utilities I know of) will allow un-enrolled access to anything other than meter usage data and information on price (and this access is authenticated for privacy reasons). If you enroll your devices in a utility program then you could also receive demand response messages. Really that is it in terms of services provided by the meter......... Now it is true that the meter usage data, price and other information can be used in the HAN for energy savings. The utility is not involved in this and does not host homeowner applications within the meter. The utility only supplies the requested data to the HAN devices to support that application. Don ________________________________ From:Adam Roach To: CORE (Constrained RESTful Environments) WG Sent: Mon, November 8, 2010 12:17:32 AM Subject: [core] Towards authc/authz user cases In today's meeting, Carsten brought up the topic of the kinds of authentication and authorization models we want to consider for CoRE, in particular when you start using proxies. I'm think of this mostly in terms of a CoRE server, an HTTP client, and an HTTP/CoRE proxy in the middle: +--------+ +-------+ +--------+ | Client |------| Proxy |------| Server | +--------+ HTTP +-------+ CoRE +--------+ In this context, Carsten spoke of the "big friend" model. Under this model, the Proxy would use normal HTTP authentication mechanisms (e.g., Basic over TLS, or Digest). It then checks its own local ACLs for authorization purposes, and provides access only to those resources on the server that the authenticated user is allowed to access. The use cases for this model are pretty obvious: very simple servers that can't reasonably be provisioned with user information (e.g., light switches), where the nature of what can be done (e.g., turning lights on and off) is reasonable to trust the proxy with. For the sake of concreteness, let's nail down the nature of the proxy. Let's assume that this proxy is inside my electric meter, and is administered by my power utility company. But let's assume they're pretty progressive, and let me access the proxy so that I can remotely monitor and control my various CoAP-attached devices. Now, with that in place, let's consider something other than light switches. Let's think about my CoAP-attached alarm system, and my CoAP-controllable deadbolt lock. If we pursue only the model under which the proxy authenticates the user and then has free reign over the various home-area-network devices, this would potentially give a set of power utility employees the ability to monitor and control my alarm system and my front-door deadbolt. This gives me pause. So, in addition to the "big friend" model, I think it's clear that we need the ability for the client to authenticate end-to-end, through the proxy. And, since the proxy can only marginally be trusted in this case, we need to make sure it can't lift the credentials from, say, HTTP basic auth it receives over TLS connections. Without defining a new model for HTTP, it seems that this situation kind of requires the ability to interwork HTTP digest parameters with semantically equivalent CoAP parameters. /a _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ________________________________ 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. --0-886013751-1289212504=:11054 Content-Type: text/html; charset=us-ascii
    Hi Peter,

    Both I and Tom Herbst have provided some input to http://datatracker.ietf.org/doc/draft-baker-ietf-core/ Appendix I.   It should have a decent explanation of this use case.

    The main issue is the utilities do not want access from the HAN Devices to resources in the meter/Utility ESI nor do they want the HAN devices to have the ability to route back through the meter/utility ESI into the AMI.

    Don


    From: "Stok, Peter van der" <peter.van.der.stok@philips.com>
    To: Don Sturek <d.sturek@att.net>; Adam Roach <adam@nostrum.com>; CORE (Constrained RESTful Environments) WG <core@ietf.org>
    Sent: Mon, November 8, 2010 2:29:35 AM
    Subject: RE: [core] Towards authc/authz user cases

    Hi Don,

     

    This is a good example of a use case. Ready to share it in a draft? (with a bit more text?)

     

    Peter

     

    From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Don Sturek
    Sent: Monday 8 November 2010 11:25
    To: Adam Roach; CORE (Constrained RESTful Environments) WG
    Subject: Re: [core] Towards authc/authz user cases

     

    Hi Adam,

    I think your note below is a bad example.   No electric company I know of will allow you access homeowner to a proxy in the meter and none (at least the US based utilities I know of) will allow un-enrolled access to anything other than meter usage data and information on price (and this access is authenticated for privacy reasons).  If you enroll your devices in a utility program then you could also receive demand response messages.  Really that is it in terms of services provided by the meter.........

    Now it is true that the meter usage data, price and other information can be used in the HAN for energy savings.  The utility is not involved in this and does not host homeowner applications within the meter.  The utility only supplies the requested data to the HAN devices to support that application.

    Don

     

    From: Adam Roach <adam@nostrum.com>
    To: CORE (Constrained RESTful Environments) WG <core@ietf.org>
    Sent: Mon, November 8, 2010 12:17:32 AM
    Subject: [core] Towards authc/authz user cases

    In today's meeting, Carsten brought up the topic of the kinds of authentication and authorization models we want to consider for CoRE, in particular when you start using proxies. I'm think of this mostly in terms of a CoRE server, an HTTP client, and an HTTP/CoRE proxy in the middle:

    +--------+ +-------+ +--------+
    | Client |------| Proxy |------| Server |
    +--------+ HTTP +-------+ CoRE +--------+

    In this context, Carsten spoke of the "big friend" model. Under this model, the Proxy would use normal HTTP authentication mechanisms (e.g., Basic over TLS, or Digest). It then checks its own local ACLs for authorization purposes, and provides access only to those resources on the server that the authenticated user is allowed to access. The use cases for this model are pretty obvious: very simple servers that can't reasonably be provisioned with user information (e.g., light switches), where the nature of what can be done (e.g., turning lights on and off) is reasonable to trust the proxy with.

    For the sake of concreteness, let's nail down the nature of the proxy. Let's assume that this proxy is inside my electric meter, and is administered by my power utility company. But let's assume they're pretty progressive, and let me access the proxy so that I can remotely monitor and control my various CoAP-attached devices.

    Now, with that in place, let's consider something other than light switches. Let's think about my CoAP-attached alarm system, and my CoAP-controllable deadbolt lock.

    If we pursue only the model under which the proxy authenticates the user and then has free reign over the various home-area-network devices, this would potentially give a set of power utility employees the ability to monitor and control my alarm system and my front-door deadbolt.

    This gives me pause.

    So, in addition to the "big friend" model, I think it's clear that we need the ability for the client to authenticate end-to-end, through the proxy. And, since the proxy can only marginally be trusted in this case, we need to make sure it can't lift the credentials from, say, HTTP basic auth it receives over TLS connections.

    Without defining a new model for HTTP, it seems that this situation kind of requires the ability to interwork HTTP digest parameters with semantically equivalent CoAP parameters.

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


    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.
    --0-886013751-1289212504=:11054-- From d.sturek@att.net Mon Nov 8 02:59:21 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 068E63A6978 for ; Mon, 8 Nov 2010 02:59:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SPqZ7mSr0XDy for ; Mon, 8 Nov 2010 02:59:19 -0800 (PST) Received: from web81405.mail.mud.yahoo.com (web81405.mail.mud.yahoo.com [68.142.199.133]) by core3.amsl.com (Postfix) with SMTP id 1CDF628C13A for ; Mon, 8 Nov 2010 02:59:19 -0800 (PST) Received: (qmail 46888 invoked by uid 60001); 8 Nov 2010 10:59:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1289213977; bh=vbC/MVJ6bmT9rX/xqhjyuilnixpD9h0PnVvQTdLcrkI=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=PH2zqFN3cKy0nqwqbSAlQ319jBx+nY2tCLPG/oWMpiI3IJtSUlFmxyHvjOZYoL1EPZ/LUfCxWWuhirJEbGeGgWCNPT3qgDkUkn2xjflyLSpi8u47tqPlzv+6wRgDOl1Nsx7Ogp/xxaofO1+ClegsyZOM5nE6yvNtKjwW9Dd5fCo= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=att.net; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=J1iN01zprhfyjUX8ZP1MlaDcplFBWenNYDwHUA3VdwhVShKsIQpM8QY8aeCZVvtAMF8rh5Af7l5ASRKsYpVXPeqLvU5KPmMJlyNbZGXEWd3+wc+J3kWDz8Qqjf3M2X/zjfH+yAYVYJAAGvJ0HuocPQX+AbvHDxU6TmfXROffyHc=; Message-ID: <253277.46657.qm@web81405.mail.mud.yahoo.com> X-YMail-OSG: ydDj98cVM1kKJXkvNM1hG_0Htov7i_sC0qxYZyDP0HZIP16 O.bqxds_U8ST0aQZ49mBagXs5KCcidffb74wP8Rvg.bdeZwPBkRYxKj8hG20 oUDvk2tvcwk5RKK1hcv8r13rHk8SjNJSr5OhHsF_nzQcXfaPlvZ52gd6KzSg HdV9e0y5_Fe.Vj9u4TldmVxuJv8.5AVhnE6_tqrubDac59sM5T44nwGIvnh1 tludatlHFBFazY4TtxiRkvVnreiVFGffRUUknXJhFtkoTv6RQbyxvo.4aGlE 1vdmk4uBJMdrsByMAm2f80nWF7cuWBqXRdA5AMzz5WPqaPRoPANBHrjam8g- - Received: from [130.129.65.181] by web81405.mail.mud.yahoo.com via HTTP; Mon, 08 Nov 2010 02:59:36 PST X-Mailer: YahooMailRC/504.5 YahooMailWebService/0.8.107.284920 References: <4CD7B21C.2000600@nostrum.com> <54809.3102.qm@web81406.mail.mud.yahoo.com> Date: Mon, 8 Nov 2010 02:59:36 -0800 (PST) From: Don Sturek To: "Stok, Peter van der" , Adam Roach , "CORE \(Constrained RESTful Environments\) WG" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1781050207-1289213976=:46657" Subject: Re: [core] Towards authc/authz user cases X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 10:59:21 -0000 --0-1781050207-1289213976=:46657 Content-Type: text/plain; charset=us-ascii Hi Peter, One more useful link would be the OpenSG OpenHAN 2.0 document. This was a collaboration of utilities and vendors and is used by the Smart Energy 2.0 work as a requirements document. Here is a link to the OpenHAN 2.0 document: http://osgug.ucaiug.org/sgsystems/openhan/Shared%20Documents/OpenHAN%202.0/UCAIug%20HAN%20SRS%20-%20v2.0.pdf It is really the OpenHAN 2.0 document that the US utilities are looking to support....... Don ________________________________ From: "Stok, Peter van der" To: Don Sturek ; Adam Roach ; CORE (Constrained RESTful Environments) WG Sent: Mon, November 8, 2010 2:29:35 AM Subject: RE: [core] Towards authc/authz user cases Hi Don, This is a good example of a use case. Ready to share it in a draft? (with a bit more text?) Peter From:core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Don Sturek Sent: Monday 8 November 2010 11:25 To: Adam Roach; CORE (Constrained RESTful Environments) WG Subject: Re: [core] Towards authc/authz user cases Hi Adam, I think your note below is a bad example. No electric company I know of will allow you access homeowner to a proxy in the meter and none (at least the US based utilities I know of) will allow un-enrolled access to anything other than meter usage data and information on price (and this access is authenticated for privacy reasons). If you enroll your devices in a utility program then you could also receive demand response messages. Really that is it in terms of services provided by the meter......... Now it is true that the meter usage data, price and other information can be used in the HAN for energy savings. The utility is not involved in this and does not host homeowner applications within the meter. The utility only supplies the requested data to the HAN devices to support that application. Don ________________________________ From:Adam Roach To: CORE (Constrained RESTful Environments) WG Sent: Mon, November 8, 2010 12:17:32 AM Subject: [core] Towards authc/authz user cases In today's meeting, Carsten brought up the topic of the kinds of authentication and authorization models we want to consider for CoRE, in particular when you start using proxies. I'm think of this mostly in terms of a CoRE server, an HTTP client, and an HTTP/CoRE proxy in the middle: +--------+ +-------+ +--------+ | Client |------| Proxy |------| Server | +--------+ HTTP +-------+ CoRE +--------+ In this context, Carsten spoke of the "big friend" model. Under this model, the Proxy would use normal HTTP authentication mechanisms (e.g., Basic over TLS, or Digest). It then checks its own local ACLs for authorization purposes, and provides access only to those resources on the server that the authenticated user is allowed to access. The use cases for this model are pretty obvious: very simple servers that can't reasonably be provisioned with user information (e.g., light switches), where the nature of what can be done (e.g., turning lights on and off) is reasonable to trust the proxy with. For the sake of concreteness, let's nail down the nature of the proxy. Let's assume that this proxy is inside my electric meter, and is administered by my power utility company. But let's assume they're pretty progressive, and let me access the proxy so that I can remotely monitor and control my various CoAP-attached devices. Now, with that in place, let's consider something other than light switches. Let's think about my CoAP-attached alarm system, and my CoAP-controllable deadbolt lock. If we pursue only the model under which the proxy authenticates the user and then has free reign over the various home-area-network devices, this would potentially give a set of power utility employees the ability to monitor and control my alarm system and my front-door deadbolt. This gives me pause. So, in addition to the "big friend" model, I think it's clear that we need the ability for the client to authenticate end-to-end, through the proxy. And, since the proxy can only marginally be trusted in this case, we need to make sure it can't lift the credentials from, say, HTTP basic auth it receives over TLS connections. Without defining a new model for HTTP, it seems that this situation kind of requires the ability to interwork HTTP digest parameters with semantically equivalent CoAP parameters. /a _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ________________________________ 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. --0-1781050207-1289213976=:46657 Content-Type: text/html; charset=us-ascii
    Hi Peter,

    One more useful link would be the OpenSG OpenHAN 2.0 document.  This was a collaboration of utilities and vendors and is used by the Smart Energy 2.0 work as a requirements document.  Here is a link to the OpenHAN 2.0 document:

    http://osgug.ucaiug.org/sgsystems/openhan/Shared%20Documents/OpenHAN%202.0/UCAIug%20HAN%20SRS%20-%20v2.0.pdf

    It is really the OpenHAN 2.0 document that the US utilities are looking to support.......

    Don


    From: "Stok, Peter van der" <peter.van.der.stok@philips.com>
    To: Don Sturek <d.sturek@att.net>; Adam Roach <adam@nostrum.com>; CORE (Constrained RESTful Environments) WG <core@ietf.org>
    Sent: Mon, November 8, 2010 2:29:35 AM
    Subject: RE: [core] Towards authc/authz user cases

    Hi Don,

     

    This is a good example of a use case. Ready to share it in a draft? (with a bit more text?)

     

    Peter

     

    From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Don Sturek
    Sent: Monday 8 November 2010 11:25
    To: Adam Roach; CORE (Constrained RESTful Environments) WG
    Subject: Re: [core] Towards authc/authz user cases

     

    Hi Adam,

    I think your note below is a bad example.   No electric company I know of will allow you access homeowner to a proxy in the meter and none (at least the US based utilities I know of) will allow un-enrolled access to anything other than meter usage data and information on price (and this access is authenticated for privacy reasons).  If you enroll your devices in a utility program then you could also receive demand response messages.  Really that is it in terms of services provided by the meter.........

    Now it is true that the meter usage data, price and other information can be used in the HAN for energy savings.  The utility is not involved in this and does not host homeowner applications within the meter.  The utility only supplies the requested data to the HAN devices to support that application.

    Don

     

    From: Adam Roach <adam@nostrum.com>
    To: CORE (Constrained RESTful Environments) WG <core@ietf.org>
    Sent: Mon, November 8, 2010 12:17:32 AM
    Subject: [core] Towards authc/authz user cases

    In today's meeting, Carsten brought up the topic of the kinds of authentication and authorization models we want to consider for CoRE, in particular when you start using proxies. I'm think of this mostly in terms of a CoRE server, an HTTP client, and an HTTP/CoRE proxy in the middle:

    +--------+ +-------+ +--------+
    | Client |------| Proxy |------| Server |
    +--------+ HTTP +-------+ CoRE +--------+

    In this context, Carsten spoke of the "big friend" model. Under this model, the Proxy would use normal HTTP authentication mechanisms (e.g., Basic over TLS, or Digest). It then checks its own local ACLs for authorization purposes, and provides access only to those resources on the server that the authenticated user is allowed to access. The use cases for this model are pretty obvious: very simple servers that can't reasonably be provisioned with user information (e.g., light switches), where the nature of what can be done (e.g., turning lights on and off) is reasonable to trust the proxy with.

    For the sake of concreteness, let's nail down the nature of the proxy. Let's assume that this proxy is inside my electric meter, and is administered by my power utility company. But let's assume they're pretty progressive, and let me access the proxy so that I can remotely monitor and control my various CoAP-attached devices.

    Now, with that in place, let's consider something other than light switches. Let's think about my CoAP-attached alarm system, and my CoAP-controllable deadbolt lock.

    If we pursue only the model under which the proxy authenticates the user and then has free reign over the various home-area-network devices, this would potentially give a set of power utility employees the ability to monitor and control my alarm system and my front-door deadbolt.

    This gives me pause.

    So, in addition to the "big friend" model, I think it's clear that we need the ability for the client to authenticate end-to-end, through the proxy. And, since the proxy can only marginally be trusted in this case, we need to make sure it can't lift the credentials from, say, HTTP basic auth it receives over TLS connections.

    Without defining a new model for HTTP, it seems that this situation kind of requires the ability to interwork HTTP digest parameters with semantically equivalent CoAP parameters.

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


    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.
    --0-1781050207-1289213976=:46657-- From hvdsomp@gmail.com Mon Nov 8 08:09:30 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6F183A6940 for ; Mon, 8 Nov 2010 08:09:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rjtl4-V3Eoym for ; Mon, 8 Nov 2010 08:09:29 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id 7B8BC3A692F for ; Mon, 8 Nov 2010 08:09:29 -0800 (PST) Received: by pzk4 with SMTP id 4so1161652pzk.31 for ; Mon, 08 Nov 2010 08:09:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type; bh=vB22eFSnt5Z/pkKe7F+qO3KArO3G2NpqJrMqFJeXBnQ=; b=kKYyPDKf5DI5LqbKg+YtbU5/7M87pZsigMWU5Nt69juJlL+fP0j2OFcr5q3FMyJVCO PeCPu831u09weIXzWwfxRTV1WWAw5aVnIRwWIZJDxi8y2RYTKtO5I6UN/vg1r1YqqQS2 ZYfAyGYCgTRM0T8dPxsOhRpYh0rjj5uUBEcpc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=rPyyIsti8WKUHbBvCNCOmEWxGw5XIOFM3uUSmEiWNAJDXtwqxSEJXPOx18+QKMama/ NtAgqpA5QbFhRAKiMK1OcthG8hOVQKbt7A0Wv+QN0cmt3GpPGfaNtUtGo/fcaqOpf6ns tF+zgVufTQMM040D9bDnBSxBXk2hvgZPCV1hs= MIME-Version: 1.0 Received: by 10.229.74.147 with SMTP id u19mr5219288qcj.214.1289232590118; Mon, 08 Nov 2010 08:09:50 -0800 (PST) Received: by 10.229.13.133 with HTTP; Mon, 8 Nov 2010 08:09:50 -0800 (PST) Date: Mon, 8 Nov 2010 09:09:50 -0700 Message-ID: From: Herbert van de Sompel To: core@ietf.org Content-Type: multipart/alternative; boundary=001636427489913b9d04948cda77 Subject: [core] Memento TimeMaps and application/link-format X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 16:09:30 -0000 --001636427489913b9d04948cda77 Content-Type: text/plain; charset=ISO-8859-1 Hi all, Mark Nottingham informed me of your work, specifically the introduction of a MIME type for "Link" formatted documents. In the context of the Memento work (http://mementoweb.org), we introduced so-called TimeMaps that are formatted according to the link-value construction rule of the BNF of RFC 5988. For example, this is a TimeMap: http://mementoproxy.lanl.gov/aggr/timemap/link/http://lib.ugent.be We are currently finalizing the first version of an Internet Draft for Memento, and we are in need of a special-purpose MIME type as the text/csv that we currently use is inaccurate. In that context, I was wondering about the following: (1) Is it appropriate for us to use "application/link-format" for our TimeMaps? Note that our TimeMaps strictly adhere to the link-value construction rule of RFC 5988, i.e. we are not using any of the extensions that you propose. (2) Why the path was chosen to define extensions as part of the basic "application/link-format" MIME type, i.e. why is "application/link-format" not introduced to identify documents strictly formatted according to RFC 5988's link-value rule, and why are extensions not handled like, for example, in XML, e.g. " application/core+link-format"? Greetings Herbert Van de Sompel -- Herbert Van de Sompel Digital Library Research & Prototyping Los Alamos National Laboratory, Research Library http://public.lanl.gov/herbertv/ == --001636427489913b9d04948cda77 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

    M= ark Nottingham informed me of your work, specifically the introduction of a= MIME type for "Link" formatted documents.=A0

    In the= context of the Memento work (http://mementoweb.org), we in= troduced so-called TimeMaps that are formatted according to the link-value = construction rule of the BNF of RFC 5988. For example, this is a TimeMap:


    We are= currently finalizing the first version of an Internet Draft for Memento, a= nd we are in need of a special-purpose MIME type as the text/csv that we cu= rrently use is inaccurate. In that context,=A0I was wondering about the fol= lowing:

    (1) Is= it appropriate for us to use "application/link-format" for our TimeMaps= ? Note that our TimeMaps strictly adhere to the link-value construction rule of RFC 5988, i.e. we are not using any= of the extensions that you propose.

    (2) Wh= y the path was chosen to define extensions as part of the basic=A0"application/link-format" MIME type, i.e. why is "application/link-format" not introduced = to identify documents strictly formatted according to RFC 5988's link-value rule, and why are e= xtensions not handled like, for example, in XML, e.g.=A0"application/core+link-format"?

    Greeti= ngs

    Herbert Van de Sompel

    --
    Herbert= Van de Sompel
    Digital Library Research & Prototyping
    Los Alamos National Laborator= y, Research Library
    http://public.lanl.gov/herbertv/

    =3D=3D<= /div>
    --001636427489913b9d04948cda77-- From L.Wood@surrey.ac.uk Mon Nov 8 08:16:19 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9A233A67B6 for ; Mon, 8 Nov 2010 08:16:19 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J2nzW6gvPE5b for ; Mon, 8 Nov 2010 08:16:18 -0800 (PST) Received: from mail78.messagelabs.com (mail78.messagelabs.com [195.245.230.131]) by core3.amsl.com (Postfix) with ESMTP id 1AD013A67EE for ; Mon, 8 Nov 2010 08:16:17 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-5.tower-78.messagelabs.com!1289232998!40142617!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [131.227.200.31] Received: (qmail 19471 invoked from network); 8 Nov 2010 16:16:38 -0000 Received: from unknown (HELO EXHT011P.surrey.ac.uk) (131.227.200.31) by server-5.tower-78.messagelabs.com with AES128-SHA encrypted SMTP; 8 Nov 2010 16:16:38 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.245]) by EXHT011P.surrey.ac.uk ([131.227.200.31]) with mapi; Mon, 8 Nov 2010 16:16:38 +0000 From: To: , Date: Mon, 8 Nov 2010 16:16:37 +0000 Thread-Topic: [core] Memento TimeMaps and application/link-format Thread-Index: Act/X2PXmSPjsGvTRXadxdTHa62nagAAFG/A Message-ID: References: In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_FD7B10366AE3794AB1EC5DE97A93A3730C2EDC9192EXMB01CMSsurr_" MIME-Version: 1.0 Subject: Re: [core] Memento TimeMaps and application/link-format X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 16:16:19 -0000 --_000_FD7B10366AE3794AB1EC5DE97A93A3730C2EDC9192EXMB01CMSsurr_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Herbert, interesting that outlook strips the second double slash to a single slash w= hen it's clicked, breaking your link... Have you thought of simply providing a browser plugin interface to archive.= org's existing WayBack Machine to bootstrap this? ________________________________ From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Her= bert van de Sompel Sent: 08 November 2010 16:10 To: core@ietf.org Subject: [core] Memento TimeMaps and application/link-format Hi all, Mark Nottingham informed me of your work, specifically the introduction of = a MIME type for "Link" formatted documents. In the context of the Memento work (http://mementoweb.org), we introduced so-called TimeMaps that are formatted according to t= he link-value construction rule of the BNF of RFC 5988. For example, this i= s a TimeMap: http://mementoproxy.lanl.gov/aggr/timemap/link/http://lib.ugent.be We are currently finalizing the first version of an Internet Draft for Meme= nto, and we are in need of a special-purpose MIME type as the text/csv that= we currently use is inaccurate. In that context, I was wondering about the= following: (1) Is it appropriate for us to use "application/link-format" for our TimeM= aps? Note that our TimeMaps strictly adhere to the link-value construction = rule of RFC 5988, i.e. we are not using any of the extensions that you prop= ose. (2) Why the path was chosen to define extensions as part of the basic "appl= ication/link-format" MIME type, i.e. why is "application/link-format" not i= ntroduced to identify documents strictly formatted according to RFC 5988's = link-value rule, and why are extensions not handled like, for example, in X= ML, e.g. "application/core+link-format"? Greetings Herbert Van de Sompel -- Herbert Van de Sompel Digital Library Research & Prototyping Los Alamos National Laboratory, Research Library http://public.lanl.gov/herbertv/ =3D=3D --_000_FD7B10366AE3794AB1EC5DE97A93A3730C2EDC9192EXMB01CMSsurr_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    Herbert,
     
    interesting that outlook strips the second double slash to a s= ingle=20 slash when it's clicked, breaking your link...
     
    Have=20 you thought of simply providing a browser plugin interface to archive.org's= =20 existing WayBack Machine to bootstrap this?
     
     

    From: core-bounces@ietf.org=20 [mailto:core-bounces@ietf.org] On Behalf Of Herbert van de=20 Sompel
    Sent: 08 November 2010 16:10
    To:=20 core@ietf.org
    Subject: [core] Memento TimeMaps and=20 application/link-format

    Hi all,

    Mark Nottingham informed me of your work, specifica= lly the=20 introduction of a MIME type for "Link" formatted documents. 

    In the context of the Memento work (http://mementoweb.org), we introduced so-called TimeMap= s that=20 are formatted according to the link-value construction rule of the BNF of R= FC=20 5988. For example, this is a TimeMap:


    We are currently finalizing the first version of an= =20 Internet Draft for Memento, and we are in need of a special-purpose MIME ty= pe as=20 the text/csv that we currently use is inaccurate. In that context, I w= as=20 wondering about the following:

    (1) Is it appropriate for us to use "application/link-format"= for our=20 TimeMaps? Note that our TimeMaps strictly adhere to the link-value construction rule of RFC 5988, i.e. we are not = using=20 any of the extensions that you propose.

    (2) Why the path was chosen to define extensions as= part=20 of the basic "application/link-format"= MIME=20 type, i.e. why is "application/link-format"= not=20 introduced to identify documents strictly formatted according to=20 RFC 5988's link-value rule= , and=20 why are extensions not handled like, for example, in XML, e.g. = "application/core+link-format"?

    Greetings

    Herbert Van de Sompel

    --
    Herbert Van de Sompel
    Digital Library Research &=20 Prototyping
    Los Alamos National Laboratory, Research Library
    http://public.lanl.gov/herbertv/

    =3D=3D

    --_000_FD7B10366AE3794AB1EC5DE97A93A3730C2EDC9192EXMB01CMSsurr_-- From hvdsomp@gmail.com Mon Nov 8 08:26:53 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92C643A67EE for ; Mon, 8 Nov 2010 08:26:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XDB3lTjRCcDW for ; Mon, 8 Nov 2010 08:26:50 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id AE5C83A67E7 for ; Mon, 8 Nov 2010 08:26:50 -0800 (PST) Received: by vws3 with SMTP id 3so2123871vws.31 for ; Mon, 08 Nov 2010 08:27:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=+lKo5tWBaVmJsFou4OCI8M2fUQdpYrO4Lq5BEKgZAL4=; b=T6bY8kqV0bB8YRkLXXfnP0o5UOTB+vxfHJqV6r/QS2ak/F/gM6eI9ms8QMeN4wh4rS gGNob1EChp4Gom87MRK9eMZe3zJAmOjl7bQzvuMiDFJ0SSgf+DhnOQyi8qU9UR+mZgt8 /BSiDt49Jklahuuix5wx03JBm1FkCy+J6u1Jg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=HTJKboBfn+u8xpfmZRDTQLrV8LOp5Oh/wqnEgcXIZ2Gry82leqkInEHB3ij2CvjXhd CBk0mBnN2OOO4pB/BvbNgIqjmWV4A/xJ9MN1zIQBKF1kPklEyQ9RBV0QRx5DdRvNkOFN WwsgO2fcc6uStHNDZpy8Y0tfSitsegSmFucFA= MIME-Version: 1.0 Received: by 10.224.210.137 with SMTP id gk9mr1947749qab.294.1289233630852; Mon, 08 Nov 2010 08:27:10 -0800 (PST) Received: by 10.229.13.133 with HTTP; Mon, 8 Nov 2010 08:27:10 -0800 (PST) In-Reply-To: References: Date: Mon, 8 Nov 2010 09:27:10 -0700 Message-ID: From: Herbert van de Sompel To: L.Wood@surrey.ac.uk Content-Type: multipart/alternative; boundary=20cf30025c589977c404948d182f Cc: core@ietf.org Subject: Re: [core] Memento TimeMaps and application/link-format X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 16:26:53 -0000 --20cf30025c589977c404948d182f Content-Type: text/plain; charset=ISO-8859-1 On Mon, Nov 8, 2010 at 9:16 AM, wrote: > Herbert, > > interesting that outlook strips the second double slash to a single slash > when it's clicked, breaking your link... > Let's blame that on Outlook ;-) . > > Have you thought of simply providing a browser plugin interface to > archive.org's existing WayBack Machine to bootstrap this? > The upcoming release of the Internet Archive's Wayback software will be compatible with the Memento Internet Draft that we will soon publish. And there is a Memento FireFox plug-in, as well as an Android app. And some other tools, see http://www.mementoweb.org/tools/ Cheers Herbert > > > > ------------------------------ > *From:* core-bounces@ietf.org [mailto:core-bounces@ietf.org] *On Behalf Of > *Herbert van de Sompel > *Sent:* 08 November 2010 16:10 > *To:* core@ietf.org > *Subject:* [core] Memento TimeMaps and application/link-format > > Hi all, > > Mark Nottingham informed me of your work, specifically the introduction of > a MIME type for "Link" formatted documents. > > In the context of the Memento work (http://mementoweb.org), we introduced > so-called TimeMaps that are formatted according to the link-value > construction rule of the BNF of RFC 5988. For example, this is a TimeMap: > > http://mementoproxy.lanl.gov/aggr/timemap/link/http://lib.ugent.be > > We are currently finalizing the first version of an Internet Draft for > Memento, and we are in need of a special-purpose MIME type as the text/csv > that we currently use is inaccurate. In that context, I was wondering about > the following: > > (1) Is it appropriate for us to use "application/link-format" for our > TimeMaps? Note that our TimeMaps strictly adhere to the link-value > construction rule of RFC 5988, i.e. we are not using any of the extensions > that you propose. > > (2) Why the path was chosen to define extensions as part of the basic "application/link-format" > MIME type, i.e. why is "application/link-format" not introduced to > identify documents strictly formatted according to RFC 5988's link-value > rule, and why are extensions not handled like, for example, in XML, e.g. " > application/core+link-format"? > > Greetings > > Herbert Van de Sompel > > -- > Herbert Van de Sompel > Digital Library Research & Prototyping > Los Alamos National Laboratory, Research Library > http://public.lanl.gov/herbertv/ > > == > > -- Herbert Van de Sompel Digital Library Research & Prototyping Los Alamos National Laboratory, Research Library http://public.lanl.gov/herbertv/ == --20cf30025c589977c404948d182f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Nov 8, 2010 at 9:16 AM, <L.Wood@surrey.ac.uk> wrote:
    Herbert,
    = =A0
    interesting th= at outlook strips the second double slash to a single=20 slash when it's clicked, breaking your link...
    =

    Let's blame that on Outloo= k ;-) .=A0
    =A0
    =A0
    Have=20 you thought of simply providing a browser plugin interface to archive.org's=20 existing WayBack Machine to bootstrap this?

    The upcoming release of the Internet Archive'= ;s Wayback software will be compatible with the Memento Internet Draft that= we will soon publish. And there is a Memento FireFox plug-in, as well as a= n Android app. And some other tools, see http://www.mementoweb.org/tools/=A0

    Cheers

    Herbert
    =A0
    = =A0
    = =A0

    From: core-bounces@ietf.org=20 [mailto:core-bou= nces@ietf.org] On Behalf Of Herbert van de=20 Sompel
    Sent: 08 November 2010 16:10
    To:=20 core@ietf.org
    = Subject: [core] Memento TimeMaps and=20 application/link-format

    Hi all,

    Mark Nottingham informed me of your work, specifi= cally the=20 introduction of a MIME type for "Link" formatted documents.=A0

    In the context of the Memento work (http:/= /mementoweb.org), we introduced so-called TimeMaps that=20 are formatted according to the link-value construction rule of the BNF of R= FC=20 5988. For example, this is a TimeMap:


    We are currently finalizing the first version of = an=20 Internet Draft for Memento, and we are in need of a special-purpose MIME ty= pe as=20 the text/csv that we currently use is inaccurate. In that context,=A0I was= =20 wondering about the following:

    (1) Is it appropriate for us to use "= application/link-= format" for our=20 TimeMaps? Note that our TimeMaps strictly adhere to the link-value construction rule of RFC 5988, i.e. we are not u= sing=20 any of the extensions that you propose.

    (2) Why the path was chosen to define extensions = as part=20 of the basic=A0"application/link-format" MIME= =20 type, i.e. why is "application/link-format&qu= ot; not=20 introduced to identify documents strictly formatted according to=20 RFC 5988's link-value r= ule, and=20 why are extensions not handled like, for example, in XML, e.g.=A0"application/core+link-format"?

    Greetings

    Herbert Van de Sompel

    -- <= br>
    Herbert Van de Sompel
    Digital Library Research &=20 Prototyping
    Los Alamos National Laboratory, Research Library
    http://public.lanl.= gov/herbertv/

    =3D=3D




    --
    Herbert Van de Som= pel
    Digital Library Research & Prototyping
    Los Alamos National = Laboratory, Research Library
    http://public.lanl.gov/herbertv/

    =3D=3D

    --20cf30025c589977c404948d182f-- From darco@deepdarc.com Mon Nov 8 09:36:07 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA3A03A6851 for ; Mon, 8 Nov 2010 09:36:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.868 X-Spam-Level: X-Spam-Status: No, score=-0.868 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LnGXz+KPC3mA for ; Mon, 8 Nov 2010 09:36:04 -0800 (PST) Received: from spider.nocdirect.com (spider.nocdirect.com [69.73.181.158]) by core3.amsl.com (Postfix) with ESMTP id EFA303A6874 for ; Mon, 8 Nov 2010 09:36:03 -0800 (PST) Received: from c-67-174-221-32.hsd1.ca.comcast.net ([67.174.221.32]:40317 helo=[172.30.96.6]) by spider.nocdirect.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1PFVdo-0002QY-Gw; Mon, 08 Nov 2010 12:36:25 -0500 References: In-Reply-To: Mime-Version: 1.0 (iPad Mail 8C5115c) Content-Type: multipart/alternative; boundary=Apple-Mail-2--454547112 Message-Id: <5FA6A38E-A209-4BF7-89D1-8BCC3B9E04DF@deepdarc.com> Content-Transfer-Encoding: 7bit X-Mailer: iPad Mail (8C5115c) From: Robert Quattlebaum Date: Mon, 8 Nov 2010 09:36:15 -0800 To: core X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - spider.nocdirect.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - deepdarc.com Subject: Re: [core] Towards authc/authz user cases X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 17:36:07 -0000 --Apple-Mail-2--454547112 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 For what it's worth, i've implemented digest authentication on an embedded d= evice, and it wasn't bad at all. I plan to use it for authenticating both ad= ministrative actions and automated commands between devices. The idea being t= hat if I pair my deadbolt to a switch in the house, only the switch would ha= ve the credentials to control the lock on the deadbolt. The username/passwor= d credentials would be negotiated during the pairing process and generated a= utomatically, perhaps using some sort of key exchange protocol. As an added b= onus, this would also protect you against replay attacks*. I like this because it protects my house even if someone were to somehow det= ermine my HAN key.=20 Imagine I have a key-fob-like device on my keychain which when I press the b= utton it attempts to send a authenticated request to the deadbolt. If I loos= e the fob, I can remove the pairing with the fob from the deadbolt without l= osing any other pairings.=20 This works quite nicely in a "callback" style system where the switch actual= ly does a PUT or POST to a specific path on the deadbolt. Not sure how well i= t would work with observe.=20 I think that digest authentication for CoAP can be made to be compatible wit= h HTTP digest. Indeed, it could probably be used as-is... But i think it wou= ld be wise to encode the key-value pairs using a more dense mechanism, perha= ps similar to how CoAP header options are encoded. This would be both easier= to parse and take up less space. The proxy would then need to deal with con= verting to and from the different representations, but that doesn't seem unr= easonable to me.=20 * Unless the content is hashed, if someone intercepts a command that didn't m= ake it to the intended target device, they could modify the content and rese= nd as an authenticated packet. This would work as long as the target device h= asn't received any other authenticated packets in the mean time. the key fob= idea above is particularly vulnerable to this. This can be worked around by= forcing the nonce count to be renegotiated after a timeout.=20 On Nov 8, 2010, at 1:57 AM, Linyi Tian wrote: > Hi, Adam and Peter >=20 > Adam did raised some interesting issue regarding security. For example who= will be authorized to control the door lock. Whether the device should trus= t the control message from the proxy?=20 >=20 > I think Peter made a good point that we need to get more insight in the sc= enarios/enrionment. In the electric meter scenario it makes sense that the p= ower utility company takes the full control of the electric meter. In this c= ase the big friend model will work. In the door lock case, the proxy most li= kely will be operated by the house owner, e.g. home gateway. The application= who is allowed to control the door lock should be under control by the user= as well. For example, the application can be installed in the mobile phone a= nd interacts with the proxy over internet. In this case the application has t= o be authenticated and authorized by the proxy first. If the proxy and devic= e are in trusted environment the authentication/authorization may not needed= . otherwise it MUST be provided to avoid security holes. >=20 > Cheers, > Linyi >=20 >=20 >=20 > On 10-11-8 =E4=B8=8B=E5=8D=885:36, "Eric Rescorla" wrote: >=20 >=20 >=20 > On Mon, Nov 8, 2010 at 1:21 AM, Stok, Peter van der wrote: > Dear Adam, >=20 > There are a lot of assumptions in your solution. > For me it is not even clear that we need authorization for small devices.=20= >=20 > Well, this is precisely why I asked the question about threat models. >=20 > Naively, if the light switches or locks in my house are controlled by IP, I= 'd like some authentication, > I would think. >=20 > -Ekr >=20 > And when we need it in a CoAP environment, the security technology burden m= ay be such that we have to resort to other techniques. These other technique= s will be very application dependent. >=20 > My suggestion is to first get more insight in the security needs which exi= st in various scenarios and applications. Then look at consequences of exist= ing technologies, and probably continue with coap solutions where needed. >=20 > Peter van der stok >=20 > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Ad= am Roach > Sent: Monday 8 November 2010 9:18 > To: CORE (Constrained RESTful Environments) WG > Subject: [core] Towards authc/authz user cases >=20 > In today's meeting, Carsten brought up the topic of the kinds of > authentication and authorization models we want to consider for CoRE, in > particular when you start using proxies. I'm think of this mostly in > terms of a CoRE server, an HTTP client, and an HTTP/CoRE proxy in the > middle: >=20 > +--------+ +-------+ +--------+ > | Client |------| Proxy |------| Server | > +--------+ HTTP +-------+ CoRE +--------+ >=20 > In this context, Carsten spoke of the "big friend" model. Under this > model, the Proxy would use normal HTTP authentication mechanisms (e.g., > Basic over TLS, or Digest). It then checks its own local ACLs for > authorization purposes, and provides access only to those resources on > the server that the authenticated user is allowed to access. The use > cases for this model are pretty obvious: very simple servers that can't > reasonably be provisioned with user information (e.g., light switches), > where the nature of what can be done (e.g., turning lights on and off) > is reasonable to trust the proxy with. >=20 > For the sake of concreteness, let's nail down the nature of the proxy. > Let's assume that this proxy is inside my electric meter, and is > administered by my power utility company. But let's assume they're > pretty progressive, and let me access the proxy so that I can remotely > monitor and control my various CoAP-attached devices. >=20 > Now, with that in place, let's consider something other than light > switches. Let's think about my CoAP-attached alarm system, and my > CoAP-controllable deadbolt lock. >=20 > If we pursue only the model under which the proxy authenticates the user > and then has free reign over the various home-area-network devices, this > would potentially give a set of power utility employees the ability to > monitor and control my alarm system and my front-door deadbolt. >=20 > This gives me pause. >=20 > So, in addition to the "big friend" model, I think it's clear that we > need the ability for the client to authenticate end-to-end, through the > proxy. And, since the proxy can only marginally be trusted in this case, > we need to make sure it can't lift the credentials from, say, HTTP basic > auth it receives over TLS connections. >=20 > Without defining a new model for HTTP, it seems that this situation kind > of requires the ability to interwork HTTP digest parameters with > semantically equivalent CoAP parameters. >=20 > /a > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 > The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addres= see(s). If you are not the intended recipient, you are hereby notified that a= ny use, forwarding, dissemination, or reproduction of this message is strict= ly prohibited and may be unlawful. If you are not the intended recipient, pl= ease contact the sender by return e-mail and destroy all copies of the origi= nal message. >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --Apple-Mail-2--454547112 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
    For what it's worth, i've implemented d= igest authentication on an embedded device, and it wasn't bad at all. I plan= to use it for authenticating both administrative actions and automated comm= ands between devices. The idea being that if I pair my deadbolt to a switch i= n the house, only the switch would have the credentials to control the lock o= n the deadbolt. The username/password credentials would be negotiated during= the pairing process and generated automatically, perhaps using some sort of= key exchange protocol. As an added bonus, this would also protect you again= st replay attacks*.

    I like this because it protects= my house even if someone were to somehow determine my HAN key. 
    <= div>
    Imagine I have a key-fob-like device on my keychain which= when I press the button it attempts to send a authenticated request to the d= eadbolt. If I loose the fob, I can remove the pairing with the fob from the d= eadbolt without losing any other pairings. 

    Th= is works quite nicely in a "callback" style system where the switch actually= does a PUT or POST to a specific path on the deadbolt. Not sure how well it= would work with observe. 

    I think that digest= authentication for CoAP can be made to be compatible with HTTP digest. Inde= ed, it could probably be used as-is... But i think it would be wise to encod= e the key-value pairs using a more dense mechanism, perhaps similar to how C= oAP header options are encoded. This would be both easier to parse and take u= p less space. The proxy would then need to deal with converting to and from t= he different representations, but that doesn't seem unreasonable to me. = ;

    * Unless the content is hashed, if someone interc= epts a command that didn't make it to the intended target device, they could= modify the content and resend as an authenticated packet. This would work a= s long as the target device hasn't received any other authenticated packets i= n the mean time. the key fob idea above is particularly vulnerable to this. T= his can be worked around by forcing the nonce count to be renegotiated after= a timeout. 

    On Nov 8, 2010, at 1:57 AM, Linyi Tian <<= a href=3D"mailto:tianlinyi@huawei.com">tianlinyi@huawei.com> wrote:
    Hi, Adam and Peter

    Adam did raised some interesting issue regarding security. For example who w= ill be authorized to control the door lock. Whether the device should trust t= he control message from the proxy?

    I think Peter made a good point that we need to get more insight in the scen= arios/enrionment. In the electric meter scenario it makes sense that the pow= er utility company takes the full control of the electric meter. In this cas= e the big friend model will work. In the door lock case, the proxy most like= ly will be operated by the house owner, e.g. home gateway. The application w= ho is allowed to control the door lock should be under control by the user a= s well. For example, the application can be installed in the mobile phone an= d interacts with the proxy over internet. In this case the application has t= o be authenticated and authorized by the proxy first. If the proxy and devic= e are in trusted environment the authentication/authorization may not needed= . otherwise it MUST be provided to avoid security holes.

    Cheers,
    Linyi



    On 10-11-8 =E4=B8=8B=E5=8D=885:36, "Eric Rescorla" <ekr@rtfm.com> wrote:

    =

    On Mon, Nov 8, 2010 at 1:21 AM, Stok, Peter van der <pet= er.van.der.stok@philips.com> wrote:
    = Dear Adam,

    There are a lot of assumptions in your solution.
    For me it is not even clear that we need authorization for small devices.

    Well, this is precisely why I asked the question about threat models.

    Naively, if the light switches or locks in my house are controlled by IP, I'= d like some authentication,
    I would think.

    -Ekr

    = And when we need it in a CoAP environment, th= e security technology burden may be such that we have to resort to other tec= hniques. These other techniques will be very application dependent.

    My suggestion is to first get more insight in the security needs which exist= in various scenarios and applications. Then look at consequences of existin= g technologies, and probably continue with coap solutions where needed.

    Peter van der stok

    -----Original Message-----
    From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Adam Roach
    Sent: Monday 8 November 2010 9:18
    To: CORE (Constrained RESTful Environments) WG
    Subject: [core] Towards authc/authz user cases

    In today's meeting, Carsten brought up the topic of the kinds of
    authentication and authorization models we want to consider for CoRE, in
    = particular when you start using proxies. I'm think of this mostly in
    terms of a CoRE server, an HTTP client, and an HTTP/CoRE proxy in the
    middle:

    +--------+ +-------+ +--------+
    | Client |------| Proxy |------| Server |
    +--------+ HTTP +-------+ CoRE +--------+

    In this context, Carsten spoke of the "big friend" model. Under this
    model, the Proxy would use normal HTTP authentication mechanisms (e.g.,
    Basic over TLS, or Digest). It then checks its own local ACLs for
    authorization purposes, and provides access only to those resources on
    the server that the authenticated user is allowed to access. The use
    cases for this model are pretty obvious: very simple servers that can't
    reasonably be provisioned with user information (e.g., light switches),
    where the nature of what can be done (e.g., turning lights on and off)
    is reasonable to trust the proxy with.

    For the sake of concreteness, let's nail down the nature of the proxy.
    Let's assume that this proxy is inside my electric meter, and is
    administered by my power utility company. But let's assume they're
    pretty progressive, and let me access the proxy so that I can remotely
    monitor and control my various CoAP-attached devices.

    Now, with that in place, let's consider something other than light
    switches. Let's think about my CoAP-attached alarm system, and my
    CoAP-controllable deadbolt lock.

    If we pursue only the model under which the proxy authenticates the user
    = and then has free reign over the various home-area-network devices, this
    = would potentially give a set of power utility employees the ability to
    monitor and control my alarm system and my front-door deadbolt.

    This gives me pause.

    So, in addition to the "big friend" model, I think it's clear that we
    need the ability for the client to authenticate end-to-end, through the
    proxy. And, since the proxy can only marginally be trusted in this case,
    = we need to make sure it can't lift the credentials from, say, HTTP basic
    = auth it receives over TLS connections.

    Without defining a new model for HTTP, it seems that this situation kind
    = of requires the ability to interwork HTTP digest parameters with
    semantically equivalent CoAP parameters.

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

    The information contained in this message may be confidential and legally pr= otected under applicable law. The message is intended solely for the address= ee(s). If you are not the intended recipient, you are hereby notified that a= ny use, forwarding, dissemination, or reproduction of this message is strict= ly prohibited and may be unlawful. If you are not the intended recipient, pl= ease contact the sender by return e-mail and destroy all copies of the origi= nal message.

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


    _______________________________________________
    core mailing list
    core@ietf.org=
    https://www.ietf.org/mailman/listinfo/core=
    ____________________= ___________________________
    core mailing list
    core@ietf.org
    https://www.ietf.org/mailman= /listinfo/core
    = --Apple-Mail-2--454547112-- From pab@peoplepowerco.com Mon Nov 8 09:59:06 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A52FB3A683F for ; Mon, 8 Nov 2010 09:59:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FAUpFRd+Tyku for ; Mon, 8 Nov 2010 09:59:05 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 860813A67FB for ; Mon, 8 Nov 2010 09:59:05 -0800 (PST) Received: by fxm3 with SMTP id 3so201651fxm.31 for ; Mon, 08 Nov 2010 09:59:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.101.194 with SMTP id d2mr4132715fao.88.1289239146229; Mon, 08 Nov 2010 09:59:06 -0800 (PST) Received: by 10.223.100.14 with HTTP; Mon, 8 Nov 2010 09:59:06 -0800 (PST) In-Reply-To: <057.86ca4d29ed54c1be14e57fe22ff95263@tools.ietf.org> References: <057.86ca4d29ed54c1be14e57fe22ff95263@tools.ietf.org> Date: Mon, 8 Nov 2010 11:59:06 -0600 Message-ID: From: Peter Bigot To: core Content-Type: multipart/alternative; boundary=20cf3054a4ad5770c004948e619c Subject: Re: [core] coap #56 (new): Distinguishing DTLS, CoAP and STUN X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 17:59:06 -0000 --20cf3054a4ad5770c004948e619c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I missed the working group discussion during which it was decided to carry both secure and non-secure packets over the same protocol on the same port. Following the general URI concept that the authority and hier-part define the resource, while the scheme defines how you talk to the resource owner, it is more natural (and consistent with http/https) that an alternative scheme denote encrypted CoAP traffic. Since the scheme would be encrypted, use of a distinct port to disambiguate the content is also more clear. Thi= s would also decouple CoAP from being impacted by evolutionary decisions made within DTLS. On what basis was the decision made to diverge from the way it's done in HTTP? Peter On Sat, Nov 6, 2010 at 11:15 AM, core issue tracker wr= ote: > #56: Distinguishing DTLS, CoAP and STUN > > Section 10.2 need a discussion on how to tell the difference between DTL= S > and CoAP messages as the same port is used by default. > > -- > > --------------------------------+----------------------------------------= --- > Reporter: zach@=85 | Owner: > Type: enhancement | Status: new > Priority: trivial | Milestone: > Component: coap | Version: > Severity: - | Keywords: > > --------------------------------+----------------------------------------= --- > > Ticket URL: > core > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --20cf3054a4ad5770c004948e619c Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I missed the working group discussion during which it was decided to carry = both secure and non-secure packets over the same protocol on the same port.=

    Following the general URI concept that the authority and hier-part = define the resource, while the scheme defines how you talk to the resource = owner, it is more natural (and consistent with http/https) that an alternat= ive scheme denote encrypted CoAP traffic.=A0 Since the scheme would be encr= ypted, use of a distinct port to disambiguate the content is also more clea= r.=A0 This would also decouple CoAP from being impacted by evolutionary dec= isions made within DTLS.

    On what basis was the decision made to diverge from the way it's do= ne in HTTP?

    Peter

    On Sat, Nov 6, 2= 010 at 11:15 AM, core issue tracker <trac@tools.ietf.org> wrote:
    #56: Distinguishi= ng DTLS, CoAP and STUN

    =A0Section 10.2 need a discussion on how to tell the difference between DTL= S
    =A0and CoAP messages as the same port is used by default.

    --
    --------------------------------+------------------------------------------= -
    =A0Reporter: =A0zach@=85 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 Owner: =A0 =A0 Type: =A0enhancement =A0 =A0 =A0 =A0 | =A0 =A0 =A0Status: =A0new =A0Priority: =A0trivial =A0 =A0 =A0 =A0 =A0 =A0 | =A0 Milestone:
    Component: =A0coap =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 Version:
    =A0Severity: =A0- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0Keywords: --------------------------------+------------------------------------------= -

    Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/56&= gt;
    core <http://t= ools.ietf.org/core/>

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

    --20cf3054a4ad5770c004948e619c-- From pab@peoplepowerco.com Mon Nov 8 10:12:31 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C6133A6824 for ; Mon, 8 Nov 2010 10:12:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cv0KJEb-ZaLP for ; Mon, 8 Nov 2010 10:12:30 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id C45143A67DF for ; Mon, 8 Nov 2010 10:12:29 -0800 (PST) Received: by fxm3 with SMTP id 3so215575fxm.31 for ; Mon, 08 Nov 2010 10:12:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.79.4 with SMTP id n4mr3789900fak.69.1289239970909; Mon, 08 Nov 2010 10:12:50 -0800 (PST) Received: by 10.223.100.14 with HTTP; Mon, 8 Nov 2010 10:12:50 -0800 (PST) In-Reply-To: References: Date: Mon, 8 Nov 2010 12:12:50 -0600 Message-ID: From: Peter Bigot To: Eric Rescorla Content-Type: multipart/alternative; boundary=20cf304345147f0fba04948e9202 Cc: core@ietf.org Subject: Re: [core] Stuffing state in tokens X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 18:12:31 -0000 --20cf304345147f0fba04948e9202 Content-Type: text/plain; charset=ISO-8859-1 When introduced in draft-bormann-coap-misc-05, Token was specifically an opaque transaction-layer header introduced to eliminate the need to perform complex comparisons on URI fields to correlate an asynchronous response with a request. What is the motivation for extending this simple concept of a transaction-layer key interpretable only on the client into a back-door mechanism to convey meaningful state from client to server outside the message body, or to transport it to and from the server rather than retain it on the client? If it serves only this correlation role, is there a security aspect that needs to be addressed (that isn't naturally addressed by protecting the entire message)? Peter On Mon, Nov 8, 2010 at 1:39 AM, Eric Rescorla wrote: > As a general matter if you're going to have a token that has state in it > that would be advantageous to someone who has the token to modify > then you need to protect the token. So, the question then becomes > how difficult it is for an attacker to generate a new, valid token with > a different state. > > The classic way to generate these tokens (see for instance, > http://tools.ietf.org/html/draft-rescorla-stateless-tokens-01) is to > have some payload plus an integrity check (MAC). So you have > a token composed of: > > P || M > > Where P is the payload and M is the MAC. > > Say that the attacker generates an arbitrary payload P' and then generates > a random MAC M', the chance that the MAC is valid is 2^{-m} where m is the > length of the MAC. In most cases, a forgery probability of 2^{-64} is > considered > the minimum acceptable limit with 2^{-80} being preferred. This implies a > MAC > of at least 8-10 bytes. Now, perhaps there is some argument that in this > case > the risk of forgery is lower, but I don't see how it's going to be > acceptable > at less than a 4 byte (2^{-32} probability) MAC and we only accepted that > for SRTP because there was an argument that a single forged media sample > was a low risk. I don't see that that applies here. > > -Ekr > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > --20cf304345147f0fba04948e9202 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable When introduced in draft-bormann-coap-misc-05, Token was specifically an op= aque transaction-layer header introduced to eliminate the need to perform c= omplex comparisons on URI fields to correlate an asynchronous response with= a request.

    What is the motivation for extending this simple concept of a transacti= on-layer key interpretable only on the client into a back-door mechanism to= convey meaningful state from client to server outside the message body, or= to transport it to and from the server rather than retain it on the client= ?

    If it serves only this correlation role, is there a security aspect tha= t needs to be addressed (that isn't naturally addressed by protecting t= he entire message)?

    Peter

    On Mon, = Nov 8, 2010 at 1:39 AM, Eric Rescorla <ekr@rtfm.com> wrote:
    As a general matt= er if you're going to have a token that has state in it
    that would = be advantageous to someone who has the token to modify
    then you need to protect the token. So, the question then becomes
    how difficult it is for an attacker to generate a new, valid token wit= h
    a different state.

    The classic way to = generate these tokens (see for instance,
    have some payload plus an integrity check (MAC). So you have
    a token composed of:

    P || M

    <= div>Where P is the payload and M is the MAC.

    Say that the attacker generates an arbitrary payload P' and then genera= tes
    a random MAC M', the chance that the MAC is valid is 2^{-m} where = m is the
    length of the MAC. In most cases, a forgery probability = of 2^{-64} is considered
    the minimum acceptable limit with 2^{-80= } being preferred. This implies a MAC
    of at least 8-10 bytes. Now, perhaps there is some argument that in th= is case
    the risk of forgery is lower, but I don't see how it&= #39;s going to be acceptable
    at less than a 4 byte (2^{-32} proba= bility) MAC and we only accepted that
    for SRTP because there was an argument that a single forged media samp= le
    was a low risk. I don't see that that applies here.
    <= div>
    -Ekr


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


    --20cf304345147f0fba04948e9202-- From ekr@rtfm.com Mon Nov 8 10:14:49 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D06583A6936 for ; Mon, 8 Nov 2010 10:14:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.746 X-Spam-Level: X-Spam-Status: No, score=-101.746 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AcInXBXipXNB for ; Mon, 8 Nov 2010 10:14:48 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id AC78D3A6824 for ; Mon, 8 Nov 2010 10:14:48 -0800 (PST) Received: by yxp4 with SMTP id 4so3915818yxp.31 for ; Mon, 08 Nov 2010 10:15:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.90.4.1 with SMTP id 1mr5637533agd.124.1289240110218; Mon, 08 Nov 2010 10:15:10 -0800 (PST) Received: by 10.91.78.6 with HTTP; Mon, 8 Nov 2010 10:15:10 -0800 (PST) In-Reply-To: References: Date: Mon, 8 Nov 2010 10:15:10 -0800 Message-ID: From: Eric Rescorla To: Peter Bigot Content-Type: multipart/alternative; boundary=00163630fab1ccc47004948e9ac0 Cc: core@ietf.org Subject: Re: [core] Stuffing state in tokens X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 18:14:49 -0000 --00163630fab1ccc47004948e9ac0 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Nov 8, 2010 at 10:12 AM, Peter Bigot wrote: > When introduced in draft-bormann-coap-misc-05, Token was specifically an > opaque transaction-layer header introduced to eliminate the need to perform > complex comparisons on URI fields to correlate an asynchronous response with > a request. > > What is the motivation for extending this simple concept of a > transaction-layer key interpretable only on the client into a back-door > mechanism to convey meaningful state from client to server outside the > message body, or to transport it to and from the server rather than retain > it on the client? I didn't say there was. This was raised in the meeting and I'm attempting to discuss the security issues. > If it serves only this correlation role, is there a security aspect that > needs to be addressed (that isn't naturally addressed by protecting the > entire message)? > Well, in general if tokens are short and guessable, then there are some potential attacks. -ekr > Peter > > On Mon, Nov 8, 2010 at 1:39 AM, Eric Rescorla wrote: > >> As a general matter if you're going to have a token that has state in it >> that would be advantageous to someone who has the token to modify >> then you need to protect the token. So, the question then becomes >> how difficult it is for an attacker to generate a new, valid token with >> a different state. >> >> The classic way to generate these tokens (see for instance, >> http://tools.ietf.org/html/draft-rescorla-stateless-tokens-01) is to >> have some payload plus an integrity check (MAC). So you have >> a token composed of: >> >> P || M >> >> Where P is the payload and M is the MAC. >> >> Say that the attacker generates an arbitrary payload P' and then generates >> a random MAC M', the chance that the MAC is valid is 2^{-m} where m is the >> length of the MAC. In most cases, a forgery probability of 2^{-64} is >> considered >> the minimum acceptable limit with 2^{-80} being preferred. This implies a >> MAC >> of at least 8-10 bytes. Now, perhaps there is some argument that in this >> case >> the risk of forgery is lower, but I don't see how it's going to be >> acceptable >> at less than a 4 byte (2^{-32} probability) MAC and we only accepted that >> for SRTP because there was an argument that a single forged media sample >> was a low risk. I don't see that that applies here. >> >> -Ekr >> >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> >> > --00163630fab1ccc47004948e9ac0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

    On Mon, Nov 8, 2010 at 10:12 AM, Peter B= igot <pab@peo= plepowerco.com> wrote:
    When introduced in draft-bormann-coap-misc-05, Token was specifically an op= aque transaction-layer header introduced to eliminate the need to perform c= omplex comparisons on URI fields to correlate an asynchronous response with= a request.

    What is the motivation for extending this simple concept of a transacti= on-layer key interpretable only on the client into a back-door mechanism to= convey meaningful state from client to server outside the message body, or= to transport it to and from the server rather than retain it on the client= ?

    I didn't say there was. This was raised in the meet= ing and I'm attempting
    to discuss the security issues.
    <= div>=A0
    =A0
    If it serves only this corr= elation role, is there a security aspect that needs to be addressed (that i= sn't naturally addressed by protecting the entire message)?

    Well, in general if tokens are short and g= uessable, then there are some potential attacks.

    -= ekr
    =A0
    Peter

    O= n Mon, Nov 8, 2010 at 1:39 AM, Eric Rescorla <ekr@rtfm.com> wrot= e:
    <= /div>
    As a general matter if you're going to have a to= ken that has state in it
    that would be advantageous to someone who has the token to modify
    then you need to protect the token. So, the question then becomes
    how difficult it is for an attacker to generate a new, valid token wit= h
    a different state.

    The classic way to = generate these tokens (see for instance,
    have some payload plus an integrity check (MAC). So you have
    a token composed of:

    P || M

    <= div>Where P is the payload and M is the MAC.

    Say that the attacker generates an arbitrary payload P' and then genera= tes
    a random MAC M', the chance that the MAC is valid is 2^{-m} where = m is the
    length of the MAC. In most cases, a forgery probability = of 2^{-64} is considered
    the minimum acceptable limit with 2^{-80= } being preferred. This implies a MAC
    of at least 8-10 bytes. Now, perhaps there is some argument that in th= is case
    the risk of forgery is lower, but I don't see how it&= #39;s going to be acceptable
    at less than a 4 byte (2^{-32} proba= bility) MAC and we only accepted that
    for SRTP because there was an argument that a single forged media samp= le
    was a low risk. I don't see that that applies here.
    <= div>
    -Ekr


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



    --00163630fab1ccc47004948e9ac0-- From pab@peoplepowerco.com Mon Nov 8 10:30:32 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0C0F3A686A for ; Mon, 8 Nov 2010 10:30:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Or-gPoz8pTnm for ; Mon, 8 Nov 2010 10:30:31 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 7BDA43A6848 for ; Mon, 8 Nov 2010 10:30:31 -0800 (PST) Received: by yxp4 with SMTP id 4so3932723yxp.31 for ; Mon, 08 Nov 2010 10:30:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.119.132 with SMTP id z4mr165755faq.31.1289241051866; Mon, 08 Nov 2010 10:30:51 -0800 (PST) Received: by 10.223.100.14 with HTTP; Mon, 8 Nov 2010 10:30:51 -0800 (PST) In-Reply-To: References: Date: Mon, 8 Nov 2010 12:30:51 -0600 Message-ID: From: Peter Bigot To: Eric Rescorla Content-Type: multipart/alternative; boundary=001636c5b231ed273704948ed281 Cc: core@ietf.org Subject: Re: [core] Stuffing state in tokens X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 18:30:32 -0000 --001636c5b231ed273704948ed281 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Nov 8, 2010 at 12:15 PM, Eric Rescorla wrote: > On Mon, Nov 8, 2010 at 10:12 AM, Peter Bigot wrote: > >> When introduced in draft-bormann-coap-misc-05, Token was specifically an >> opaque transaction-layer header introduced to eliminate the need to perform >> complex comparisons on URI fields to correlate an asynchronous response with >> a request. >> >> What is the motivation for extending this simple concept of a >> transaction-layer key interpretable only on the client into a back-door >> mechanism to convey meaningful state from client to server outside the >> message body, or to transport it to and from the server rather than retain >> it on the client? > > > I didn't say there was. This was raised in the meeting and I'm attempting > to discuss the security issues. > My hope was that understanding what sort of state somebody wants to put in there and why would help illuminate what, if any, security issues are present. If the state is not advantageous to anybody except the client, then from what you wrote it may not be necessary to protect it. If it serves only this correlation role, is there a security aspect that >> needs to be addressed (that isn't naturally addressed by protecting the >> entire message)? >> > > Well, in general if tokens are short and guessable, then there are some > potential attacks. > Yes. I would hope that using whole-message encryption would eliminate that potential. I suppose somebody might conceive of a practice where a client encrypted a token in an otherwise clear message, and the server responded by re-encrypting it as a form of authenticating the response. Perhaps that's a case we need to account for in the threat model. Otherwise there's really no need to guess the token: an adversary can just extract it from a snooped request, and return it in a spoofed response. Peter > > -ekr > > >> Peter >> >> On Mon, Nov 8, 2010 at 1:39 AM, Eric Rescorla wrote: >> >>> As a general matter if you're going to have a token that has state in it >>> that would be advantageous to someone who has the token to modify >>> then you need to protect the token. So, the question then becomes >>> how difficult it is for an attacker to generate a new, valid token with >>> a different state. >>> >>> The classic way to generate these tokens (see for instance, >>> http://tools.ietf.org/html/draft-rescorla-stateless-tokens-01) is to >>> have some payload plus an integrity check (MAC). So you have >>> a token composed of: >>> >>> P || M >>> >>> Where P is the payload and M is the MAC. >>> >>> Say that the attacker generates an arbitrary payload P' and then >>> generates >>> a random MAC M', the chance that the MAC is valid is 2^{-m} where m is >>> the >>> length of the MAC. In most cases, a forgery probability of 2^{-64} is >>> considered >>> the minimum acceptable limit with 2^{-80} being preferred. This implies a >>> MAC >>> of at least 8-10 bytes. Now, perhaps there is some argument that in this >>> case >>> the risk of forgery is lower, but I don't see how it's going to be >>> acceptable >>> at less than a 4 byte (2^{-32} probability) MAC and we only accepted that >>> for SRTP because there was an argument that a single forged media sample >>> was a low risk. I don't see that that applies here. >>> >>> -Ekr >>> >>> >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>> >>> >> > --001636c5b231ed273704948ed281 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Nov 8, 2010 at 12:15 PM, Eric Rescorla <ekr@rtfm.com> wrote:
    On Mon, Nov 8, 2010 at 10:12 A= M, Peter Bigot <pab@peoplepowerco.com> wrote:
    When introduced in draft-bormann-coap-misc-05, Token was specifically an op= aque transaction-layer header introduced to eliminate the need to perform c= omplex comparisons on URI fields to correlate an asynchronous response with= a request.

    What is the motivation for extending this simple concept of a transacti= on-layer key interpretable only on the client into a back-door mechanism to= convey meaningful state from client to server outside the message body, or= to transport it to and from the server rather than retain it on the client= ?

    I didn't say there was. This was raised in th= e meeting and I'm attempting
    to discuss the security issues.<= /div>

    My hope= was that understanding what sort of state somebody wants to put=20 in there and why would help illuminate what, if any, security issues are present.=A0 If the state is not advantageous to anybody except the client,= then from what you wrote it may not be necessary to protect it.

    If it serves only this correlation= role, is there a security aspect that needs to be addressed (that isn'= t naturally addressed by protecting the entire message)?

    Well, in general if tokens are short= and guessable, then there are some potential attacks.

    Yes.=A0 I would hope that using whole-message encryption would= eliminate that potential.=A0 I suppose somebody might conceive of a practi= ce where a client encrypted a token in an otherwise clear message, and the = server responded by re-encrypting it as a form of authenticating the respon= se.=A0 Perhaps that's a case we need to account for in the threat model= .=A0 Otherwise there's really no need to guess the token: an adversary = can just extract it from a snooped request, and return it in a spoofed resp= onse.

    Peter
    =A0

    -ekr
    =A0
    Peter

    On Mon, Nov 8,= 2010 at 1:39 AM, Eric Rescorla <ekr@rtfm.com> wrote:
    =
    As a general matter if you're going to have a token tha= t has state in it
    that would be advantageous to someone who has the token to modify
    then you need to protect the token. So, the question then becomes
    how difficult it is for an attacker to generate a new, valid token wit= h
    a different state.

    The classic way to = generate these tokens (see for instance,
    have some payload plus an integrity check (MAC). So you have
    a token composed of:

    P || M

    <= div>Where P is the payload and M is the MAC.

    Say that the attacker generates an arbitrary payload P' and then genera= tes
    a random MAC M', the chance that the MAC is valid is 2^{-m} where = m is the
    length of the MAC. In most cases, a forgery probability = of 2^{-64} is considered
    the minimum acceptable limit with 2^{-80= } being preferred. This implies a MAC
    of at least 8-10 bytes. Now, perhaps there is some argument that in th= is case
    the risk of forgery is lower, but I don't see how it&= #39;s going to be acceptable
    at less than a 4 byte (2^{-32} proba= bility) MAC and we only accepted that
    for SRTP because there was an argument that a single forged media samp= le
    was a low risk. I don't see that that applies here.
    <= div>
    -Ekr


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




    --001636c5b231ed273704948ed281-- From darco@deepdarc.com Mon Nov 8 11:46:26 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 989233A6884 for ; Mon, 8 Nov 2010 11:46:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F7IFMJkPiFai for ; Mon, 8 Nov 2010 11:46:25 -0800 (PST) Received: from mail-out3.apple.com (mail-out.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 97B053A686D for ; Mon, 8 Nov 2010 11:46:25 -0800 (PST) Received: from relay14.apple.com (relay14.apple.com [17.128.113.52]) by mail-out3.apple.com (Postfix) with ESMTP id 8D98AB59FBB5; Mon, 8 Nov 2010 11:46:47 -0800 (PST) X-AuditID: 11807134-b7c05ae000002d5d-7f-4cd853a7d00b Received: from bellatrix.apple.com (bellatrix.apple.com [17.197.13.66]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay14.apple.com (Apple SCV relay) with SMTP id 5B.C1.11613.7A358DC4; Mon, 8 Nov 2010 11:46:47 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Robert Quattlebaum In-Reply-To: Date: Mon, 8 Nov 2010 11:46:46 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Peter Bigot X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== Cc: core@ietf.org Subject: Re: [core] Stuffing state in tokens X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 19:46:26 -0000 Hello Peter! On Nov 8, 2010, at 10:12 AM, Peter Bigot wrote: > When introduced in draft-bormann-coap-misc-05, Token was specifically = an opaque transaction-layer header introduced to eliminate the need to = perform complex comparisons on URI fields to correlate an asynchronous = response with a request. >=20 > What is the motivation for extending this simple concept of a = transaction-layer key interpretable only on the client into a back-door = mechanism to convey meaningful state from client to server outside the = message body, or to transport it to and from the server rather than = retain it on the client? Those are two distinct scenarios, the first of which effectively breaks = the current assumptions about the Token header being opaque. I believe = the second scenario is what is interesting here. Here are some example cases: The token header could be used to implement a stateless sliced/blocked = POST upload. The token would be used to contain the state of what has = been sent so far and what else needs to be sent. If the upload consists = of discrete records, the token could be used to describe the next record = to send, and perhaps an integer describing an offset into the record for = cases where the last record was truncated and needs to be continued in = the next transaction. The client simply starts the ball rolling by = sending the first packet. After that, the upload would drive itself with = no state. For sliced/blocked GET requests, imagine a case where a constrained = device does a GET request for records from a database. It performs a = specific action on each record retrieved, as they are retrieved. In = cases where the responses contain partial records, the token parameter = could be used to help the client fill-in-the-blanks when a record is = split across a packet boundary. Otherwise the client would need to keep = state of the last partial record received in order to make sense of the = second half of the record in the next response. __________________ Robert Quattlebaum Jabber: darco@deepdarc.com eMail: darco@deepdarc.com www: http://www.deepdarc.com/ From darco@deepdarc.com Mon Nov 8 11:56:41 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14A0D3A692D for ; Mon, 8 Nov 2010 11:56:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ayBnwWE7CZxn for ; Mon, 8 Nov 2010 11:56:40 -0800 (PST) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id 23F933A6800 for ; Mon, 8 Nov 2010 11:56:40 -0800 (PST) Received: from relay15.apple.com (relay15.apple.com [17.128.113.54]) by mail-out4.apple.com (Postfix) with ESMTP id 32312BB675F0; Mon, 8 Nov 2010 11:57:02 -0800 (PST) X-AuditID: 11807136-b7b3aae0000033cc-dc-4cd8560dae0e Received: from bellatrix.apple.com (bellatrix.apple.com [17.197.13.66]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay15.apple.com (Apple SCV relay) with SMTP id CE.2A.13260.E0658DC4; Mon, 8 Nov 2010 11:57:02 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Robert Quattlebaum In-Reply-To: Date: Mon, 8 Nov 2010 11:57:01 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <477BEE5F-F155-4C8C-B7C4-98230E322F5B@deepdarc.com> References: To: Peter Bigot X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== Cc: core@ietf.org Subject: Re: [core] Stuffing state in tokens X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 19:56:41 -0000 Hello Peter! On Nov 8, 2010, at 10:30 AM, Peter Bigot wrote: > My hope was that understanding what sort of state somebody wants to = put in there and why would help illuminate what, if any, security issues = are present. If the state is not advantageous to anybody except the = client, then from what you wrote it may not be necessary to protect it. Lets say you wanted to implement a stateless sliced POST upload of some = resource from memory for some reason. You could use the token to store a = pointer to the next byte of data and an integer describing how much more = data needs to be transferred. This would work great, and you would get a = fully automatic stateless POST upload, but it has serious security = issues: if an attacker knows what you are storing in the token and the = client doesn't do any sanity checks then the attacker could effectively = dump all of RAM. Ouch. While the token's contents are only useful to the client from a protocol = perspective, that doesn't mean that the client can trust that it was = always the one who generated the incoming token. If we allow arbitrary = data to be kept in the Token option, then we should encourage = implementors to not assume that token in a response has not been = tampered with. __________________ Robert Quattlebaum Jabber: darco@deepdarc.com eMail: darco@deepdarc.com www: http://www.deepdarc.com/ From ekr@rtfm.com Mon Nov 8 12:04:30 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82ED23A695A for ; Mon, 8 Nov 2010 12:04:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.976 X-Spam-Level: X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ic-dl-l2HYUT for ; Mon, 8 Nov 2010 12:04:29 -0800 (PST) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 925393A688D for ; Mon, 8 Nov 2010 12:04:29 -0800 (PST) Received: by gwb15 with SMTP id 15so4048761gwb.31 for ; Mon, 08 Nov 2010 12:04:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.90.185.14 with SMTP id i14mr5756982agf.178.1289246691276; Mon, 08 Nov 2010 12:04:51 -0800 (PST) Received: by 10.91.78.6 with HTTP; Mon, 8 Nov 2010 12:04:51 -0800 (PST) In-Reply-To: <477BEE5F-F155-4C8C-B7C4-98230E322F5B@deepdarc.com> References: <477BEE5F-F155-4C8C-B7C4-98230E322F5B@deepdarc.com> Date: Mon, 8 Nov 2010 12:04:51 -0800 Message-ID: From: Eric Rescorla To: Robert Quattlebaum Content-Type: multipart/alternative; boundary=0016363b7efc0fb96c0494902300 Cc: core@ietf.org Subject: Re: [core] Stuffing state in tokens X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 20:04:30 -0000 --0016363b7efc0fb96c0494902300 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Nov 8, 2010 at 11:57 AM, Robert Quattlebaum wrote: > Hello Peter! > > On Nov 8, 2010, at 10:30 AM, Peter Bigot wrote: > > > My hope was that understanding what sort of state somebody wants to put > in there and why would help illuminate what, if any, security issues are > present. If the state is not advantageous to anybody except the client, > then from what you wrote it may not be necessary to protect it. > > Lets say you wanted to implement a stateless sliced POST upload of some > resource from memory for some reason. You could use the token to store a > pointer to the next byte of data and an integer describing how much more > data needs to be transferred. This would work great, and you would get a > fully automatic stateless POST upload, but it has serious security issues: > if an attacker knows what you are storing in the token and the client > doesn't do any sanity checks then the attacker could effectively dump all of > RAM. Ouch. > Exactly. This is a pretty well-known tyoe of attack on state tokens. > While the token's contents are only useful to the client from a protocol > perspective, that doesn't mean that the client can trust that it was always > the one who generated the incoming token. If we allow arbitrary data to be > kept in the Token option, then we should encourage implementors to not > assume that token in a response has not been tampered with. I disagree with this. Rather, the tokens should be cryptographically protected so that they cannot be tampered. -Ekr --0016363b7efc0fb96c0494902300 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

    On Mon, Nov 8, 2010 at 11:57 AM, Robert = Quattlebaum <dar= co@deepdarc.com> wrote:
    Hello Peter!

    On Nov 8, 2010, at 10:30 AM, Peter Bigot wrote:

    > My hope was that understanding what sort of state somebody wants to pu= t in there and why would help illuminate what, if any, security issues are = present. =A0If the state is not advantageous to anybody except the client, = then from what you wrote it may not be necessary to protect it.

    Lets say you wanted to implement a stateless sliced POST upload of so= me resource from memory for some reason. You could use the token to store a= pointer to the next byte of data and an integer describing how much more d= ata needs to be transferred. This would work great, and you would get a ful= ly automatic stateless POST upload, but it has serious security issues: if = an attacker knows what you are storing in the token and the client doesn= 9;t do any sanity checks then the attacker could effectively dump all of RA= M. Ouch.

    Exactly. This is a pretty well-known tyoe = of attack on state tokens.

    =A0
    While the token's contents are only useful to the client from a protoco= l perspective, that doesn't mean that the client can trust that it was = always the one who generated the incoming token. If we allow arbitrary data= to be kept in the Token option, then we should encourage implementors to n= ot assume that token in a response has not been tampered with.

    I disagree with this. Rather, the tokens should be cryp= tographically protected so that they cannot be
    tampered.

    -Ekr

    --0016363b7efc0fb96c0494902300-- From darco@deepdarc.com Mon Nov 8 12:26:12 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DFB13A686D for ; Mon, 8 Nov 2010 12:26:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 727sgBz+fx7J for ; Mon, 8 Nov 2010 12:26:11 -0800 (PST) Received: from mail-out4.apple.com (mail-out.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id 927333A6834 for ; Mon, 8 Nov 2010 12:26:11 -0800 (PST) Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out4.apple.com (Postfix) with ESMTP id 6EBEABB68C9C; Mon, 8 Nov 2010 12:26:33 -0800 (PST) X-AuditID: 11807130-b7b53ae0000049b6-b4-4cd85cf9d2a3 Received: from bellatrix.apple.com (bellatrix.apple.com [17.197.13.66]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay11.apple.com (Apple SCV relay) with SMTP id 0D.FE.18870.9FC58DC4; Mon, 8 Nov 2010 12:26:33 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Robert Quattlebaum In-Reply-To: Date: Mon, 8 Nov 2010 12:26:33 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <477BEE5F-F155-4C8C-B7C4-98230E322F5B@deepdarc.com> To: Eric Rescorla X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== Cc: core@ietf.org Subject: Re: [core] Stuffing state in tokens X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 20:26:12 -0000 Hello Eric! On Nov 8, 2010, at 12:04 PM, Eric Rescorla wrote: > On Mon, Nov 8, 2010 at 11:57 AM, Robert Quattlebaum = wrote: >> While the token's contents are only useful to the client from a = protocol perspective, that doesn't mean that the client can trust that = it was always the one who generated the incoming token. If we allow = arbitrary data to be kept in the Token option, then we should encourage = implementors to not assume that token in a response has not been = tampered with. >>=20 >>=20 > I disagree with this. Rather, the tokens should be cryptographically = protected so that they cannot be > tampered. I think that cryptographically protecting a state payload contained in a = token is a strategy for dealing with the fact that you cannot trust that = the token has not been tampered with. I believe that this should ultimately be an implementation decision = (albeit highly recommended). For example, imagine a case where we use a token to contain the index of = the next record to put in the following request. If this value is = range-checked by the client (and the client always uploads all records) = then there is no need to cryptographically protect the token, IMHO. __________________ Robert Quattlebaum Jabber: darco@deepdarc.com eMail: darco@deepdarc.com www: http://www.deepdarc.com/ From cabo@tzi.org Mon Nov 8 14:44:14 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71C023A68FF for ; Mon, 8 Nov 2010 14:44:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ikiR2eeCy9-r for ; Mon, 8 Nov 2010 14:44:13 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 31E5C3A68DC for ; Mon, 8 Nov 2010 14:44:12 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id oA8MiRVb004524; Mon, 8 Nov 2010 23:44:27 +0100 (CET) Received: from dhcp-40d3.meeting.ietf.org (dhcp-40d3.meeting.ietf.org [130.129.64.211]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 072ADDC9; Mon, 8 Nov 2010 23:44:25 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Tue, 9 Nov 2010 06:44:21 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <057.86ca4d29ed54c1be14e57fe22ff95263@tools.ietf.org> To: Peter Bigot X-Mailer: Apple Mail (2.1081) Cc: core Subject: Re: [core] coap #56 (new): Distinguishing DTLS, CoAP and STUN X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 22:44:14 -0000 Peter, the current discussion is about documenting that you indeed *can* carry = DTLS and unprotected CoAP on the same UDP port. This is a useful property that HTTP/HTTPS did not have: HTTP was long = deployed when HTTPS was invented, and TLS (SSL) was not designed to use = something like an upgrade mechanism. Why do we want that property? -- it enables us to get by with just one port reservation with IANA = (good) -- it enables implementations to mix raw CoAP with DTLS traffic on one = port (maybe not that important) -- it makes CoAP robust against STUN packets and enables the return of = STUN information from the same port (not that important in a v6 network, = but useful in v4). Now the question you raise is about the URI scheme. HTTPS had the unique situation that the mere scheme identifies both the = protocol to be used and much of the security context (at least for = "public" URIs). CoAP-03 has three modes of operation: raw (NoSec), IPsec and DTLS. It is not clear to me that you can encode the mode as well the security = context (how do you set up the security association) in one scheme. I think we need a separate ticket on this issue. Gruesse, Carsten From cabo@tzi.org Mon Nov 8 14:54:40 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B58C28C0E6 for ; Mon, 8 Nov 2010 14:54:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EAwpyxVIfl1j for ; Mon, 8 Nov 2010 14:54:39 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [134.102.201.18]) by core3.amsl.com (Postfix) with ESMTP id 4C3F128C0DB for ; Mon, 8 Nov 2010 14:54:39 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id oA8MsXjo007812; Mon, 8 Nov 2010 23:54:33 +0100 (CET) Received: from dhcp-40d3.meeting.ietf.org (dhcp-40d3.meeting.ietf.org [130.129.64.211]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 828E7DCE; Mon, 8 Nov 2010 23:54:31 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Tue, 9 Nov 2010 06:54:26 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Peter Bigot X-Mailer: Apple Mail (2.1081) Cc: core@ietf.org Subject: Re: [core] Stuffing state in tokens X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 22:54:40 -0000 On Nov 9, 2010, at 02:12, Peter Bigot wrote: > When introduced in draft-bormann-coap-misc-05, Token was specifically = an opaque transaction-layer header introduced to eliminate the need to = perform complex comparisons on URI fields to correlate an asynchronous = response with a request. (Actually, that was not the original reason, but this is indeed one = use.) > What is the motivation for extending this simple concept of a = transaction-layer key interpretable only on the client into a back-door = mechanism to convey meaningful state from client to server outside the = message body, No. The token is the client's data and entirely opaque to the server. = I'm not aware of anybody trying to change that. (In some followup messages there is a reference to the continuation = options of my thought experiment = http://tools.ietf.org/html/draft-bormann-core-coap-block-01. These are = completely different, as they are the server's data and opaque to the = client, but they do raise exactly the same security considerations.) > or to transport it to and from the server rather than retain it on the = client? >=20 > If it serves only this correlation role, is there a security aspect = that needs to be addressed (that isn't naturally addressed by protecting = the entire message)? The entire discussion was about providing enough space in the token so = that a client that does want to put information in a token that needs to = be protected can do that. 8 bytes is borderline for that purpose, but = may be good enough. Gruesse, Carsten From cabo@tzi.org Mon Nov 8 16:21:04 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EFBF3A6877 for ; Mon, 8 Nov 2010 16:21:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WMUGwhdmS1L2 for ; Mon, 8 Nov 2010 16:21:03 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 2F28D3A6860 for ; Mon, 8 Nov 2010 16:21:02 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id oA90LG39000018; Tue, 9 Nov 2010 01:21:16 +0100 (CET) Received: from dhcp-67f2.meeting.ietf.org (dhcp-67f2.meeting.ietf.org [130.129.103.242]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 73293DDE; Tue, 9 Nov 2010 01:21:14 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <4CD7A561.1080000@gridmerge.com> Date: Tue, 9 Nov 2010 08:21:10 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <5D2DC44C-8CF2-4461-8C33-9064FFD9EA79@tzi.org> References: <057.7877dadaee8c1a49ad3c621003bde997@tools.ietf.org> <4CD7A561.1080000@gridmerge.com> To: robert.cragie@gridmerge.com X-Mailer: Apple Mail (2.1081) Cc: core Subject: Re: [core] coap #52 (new): How strict to make POST definition? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 00:21:04 -0000 On Nov 8, 2010, at 15:23, Robert Cragie wrote: > However, I think the idea of caching the response makes sense if you = apply a lifetime to it. Sure, in particular if we don't try to prevent a server from setting = that lifetime to zero. I agree that the current text (2.2.5) is a bit implicit about the = meaning of transaction-IDs. What it should say is at least: -- a client SHOULD send retransmissions with the same TID it sent the = original message with -- a server SHOULD use TIDs for duplicate detection (lost ACKs) and act = on duplicate messages in a way that is appropriate (e.g. it could = minimize its work by caching a response for a while, and it SHOULD use = TIDs to implement at-most-once semantics for non-idempotent operations = where that is desired). The language need not be fuzzy to grant the server some leeway; it could = quite explicitly say that a server may choose not to to duplicate = detection IF that is appropriate (i.e., for idempotent operations, as = well as for POST (non-idempotent operations) IF the resource semantics = do not require at-most-once operation). Gruesse, Carsten From behcetsarikaya@yahoo.com Mon Nov 8 17:50:35 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A43F3A68E5 for ; Mon, 8 Nov 2010 17:50:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hvx1OxVIXwO8 for ; Mon, 8 Nov 2010 17:50:33 -0800 (PST) Received: from nm29.bullet.mail.sp2.yahoo.com (nm29.bullet.mail.sp2.yahoo.com [98.139.91.99]) by core3.amsl.com (Postfix) with SMTP id 093D33A6A04 for ; Mon, 8 Nov 2010 17:50:32 -0800 (PST) Received: from [98.139.91.63] by nm29.bullet.mail.sp2.yahoo.com with NNFMP; 09 Nov 2010 01:50:52 -0000 Received: from [98.139.91.41] by tm3.bullet.mail.sp2.yahoo.com with NNFMP; 09 Nov 2010 01:50:52 -0000 Received: from [127.0.0.1] by omp1041.mail.sp2.yahoo.com with NNFMP; 09 Nov 2010 01:50:52 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 472090.98256.bm@omp1041.mail.sp2.yahoo.com Received: (qmail 36140 invoked by uid 60001); 9 Nov 2010 01:50:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1289267451; bh=jPXjx25KYVC3wP5NWZFEegkMvuiOo4rslm40fpr1lAU=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=LKuEM2rwfGgp/bPvrtbOfldn+mo90hAQTa3bqs0wyqJknylve20sF2EJxzxFlSTZ52uCv6N0Eki2XliggZN6corHb9FsadQnz5hs5g8Ca+HS1q1Nv3urMvrFNIAPROvEX48Vh18bpeU5Byv+jFPpebKKgkm+D0ozG2J9EtvhFL8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=QCB3t1kbn2UA4Cu+0GGeLLwxNk+zruTtlLEYvbi4bD9WgCzautSbS1mSIT+HxS9D1H+J8jjk2g/WYd+Ib9tMwOt2dsPqtFkeJ+C80PVXfn2nyT/yi72Fmcblt4UqPzhZI9Gj4egjz/3Xlr1hmrNgmgxfI1U39+5iIUmyKlH1+pg=; Message-ID: <968230.35124.qm@web111404.mail.gq1.yahoo.com> X-YMail-OSG: JHUAxnwVM1mMY1hvSOFNO8Z4Z6L8Ek6wSbynHQq4EQhpHaO 9GNa.HH4Grv2VaQDO.UFbiEdavsDq.9VtF5fBanOb_fE02GSbJS9NOcTRwpB SNVM425dETd.PEI7LmenjnIN.UM1Im2NIUwQXGgwN5aqzVR1SrwCknEh7KzE 4NMQQfLMKhzDuQndQbz1iZj5OTNDMjCIIDwQrdntNNXY7ZZuUs_EDjDhFw5T LovL8t0w_UdDHKh9SBvtQ6_3YjkL7gJaSa1HWdocTeaAct542wjYzTIYQ.wj 56LhclIHmY.RAEWc8e6dcWdmHRu0zhm_6FQH_PZg6Xm.F3K5u.Zbgf9dI0HN 1ybL8Dmgztx1XdaucOiMRq8IsK33qiTxdoc6y8lclp3o- Received: from [130.129.131.75] by web111404.mail.gq1.yahoo.com via HTTP; Mon, 08 Nov 2010 17:50:51 PST X-Mailer: YahooMailRC/504.5 YahooMailWebService/0.8.107.284920 Date: Mon, 8 Nov 2010 17:50:51 -0800 (PST) From: Behcet Sarikaya To: core MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [core] Fw: New Version Notification for draft-oflynn-core-bootstrapping-03 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya 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 Nov 2010 01:50:35 -0000 ----- Forwarded Message ---- > From: IETF I-D Submission Tool > To: sarikaya@ieee.org > Cc: yoshihiro.ohba@toshiba.co.jp; caozhen@chinamobile.com; >robert.cragie@gridmerge.com > Sent: Mon, November 8, 2010 4:20:00 AM > Subject: New Version Notification for draft-oflynn-core-bootstrapping-03 > > > A new version of I-D, draft-oflynn-core-bootstrapping-03.txt has been >successfully submitted by Behcet Sarikaya and posted to the IETF repository. > > Filename: draft-oflynn-core-bootstrapping > Revision: 03 > Title: Security Bootstrapping of Resource-Constrained Devices > Creation_date: 2010-11-08 > WG ID: Independent Submission > Number_of_pages: 25 > > Abstract: > The Internet of Things is marching its way towards completion. Nodes > can use standards from the 6LoWPAN and ROLL WG to achieve IP > connectivity. IEEE Standards ensure connectivity at lower layers for > resource-constrained devices. Yet a central problem remains at a > more basic layer without a suitable answer: how to initially > configure the network. Without configuration the network never > advances beyond a large box of nodes. Current solutions tend to be > specific to a certain vendor, node type, or application. > > This document outlines exactly what problems are faced in solving > this problem. General problems faced in any low-power wireless > network are outlined first; followed by how these apply to > bootstrapping. A selection of currently proposed techniques is > presented. From these a more generic approach is presented, which > can solve the problem for a wide range of situations. > > An emphasis is on performing this bootstrapping in a secure manner. > This document does not cover operation of the network securely. This > document does provide the basis for allowing the network to operate > securely however, by providing standard methods for key exchanges and > authentication. > > > > > > The IETF Secretariat. > > > From tianlinyi@huawei.com Mon Nov 8 18:10:28 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 653F73A69D4 for ; Mon, 8 Nov 2010 18:10:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.429 X-Spam-Level: * X-Spam-Status: No, score=1.429 tagged_above=-999 required=5 tests=[AWL=1.923, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rg1curd6gqVN for ; Mon, 8 Nov 2010 18:10:26 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 322DD3A6A09 for ; Mon, 8 Nov 2010 18:10:26 -0800 (PST) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LBL007BBI1NJB@szxga01-in.huawei.com> for core@ietf.org; Tue, 09 Nov 2010 10:10:35 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LBL00L3XI1NB2@szxga01-in.huawei.com> for core@ietf.org; Tue, 09 Nov 2010 10:10:35 +0800 (CST) Received: from [130.129.131.148] (dhcp-8394.meeting.ietf.org [130.129.131.148]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LBL0030KI1ER9@szxml01-in.huawei.com> for core@ietf.org; Tue, 09 Nov 2010 10:10:35 +0800 (CST) Date: Tue, 09 Nov 2010 10:10:23 +0800 From: Linyi Tian To: "CORE (Constrained RESTful Environments) WG" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_nS1voDfcQOj5c3s6+PnEmw)" Thread-topic: Question about the block options Thread-index: Act/s0QvEgo9uA/JGEmyY7QuwYpkyg== User-Agent: Microsoft-Entourage/12.25.0.100505 Subject: [core] Question about the block options X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 02:10:28 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --Boundary_(ID_nS1voDfcQOj5c3s6+PnEmw) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Hi, Z. Shelby and C. Bormann I am not sure whether this has been discussed since I am new to this group. If it was discussed, please point to me the previous thread then I can have a review myself. My question is related to the block size and length of block numbers. 1. Why the maximum for the block is 2048? How it is decided? Since in the charter we also mentioned that even though CoAP is designed for constrained environment it may also be used in general IP environment. Do you think we can increase this size? 2. Do you think that the NUM filed is too long? Is there real scenario the data will be divided into 2^20 pieces? Do you think that in most cases the below first two options would be enough? If that is the case, is it reasonable to further reduce the length of NUM field? 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | NUM |M| SZX | +-+-+-+-+-+-+-+-+ 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NUM |M| SZX | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NUM |M| SZX | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Block option Cheers, Linyi --Boundary_(ID_nS1voDfcQOj5c3s6+PnEmw) Content-type: text/html; charset=US-ASCII Content-transfer-encoding: 7BIT Question about the block options Hi, Z. Shelby and C. Bormann

    I am not sure whether this has been discussed since I am new to this group. If it was discussed, please point to me the previous thread then I can have a review myself.

    My question is related to the block size and length of block numbers.
    1. Why the maximum for the block is 2048? How it is decided? Since in the charter we also mentioned that even though CoAP is designed for constrained environment it may also be used in general IP environment. Do you think we can increase this size?
    2. Do you think that the NUM filed is too long? Is there real scenario the data will be divided into 2^20 pieces? Do you think that in most cases the below first two options would be enough? If that is the case, is it reasonable to further reduce the length of NUM field?


              0 1 2 3 4 5 6 7
              +-+-+-+-+-+-+-+-+
              |  NUM  |M| SZX |
              +-+-+-+-+-+-+-+-+

               0                   1
               0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              |          NUM          |M| SZX |
              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               0                   1                   2
               0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              |                   NUM                 |M| SZX |
              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                              Figure 1: Block option

    Cheers,
    Linyi     --Boundary_(ID_nS1voDfcQOj5c3s6+PnEmw)-- From cabo@tzi.org Mon Nov 8 18:44:49 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E305E3A6931 for ; Mon, 8 Nov 2010 18:44:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHGMCa-gO7pb for ; Mon, 8 Nov 2010 18:44:43 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 0143B3A6A62 for ; Mon, 8 Nov 2010 18:44:40 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id oA92ipAS003632; Tue, 9 Nov 2010 03:44:51 +0100 (CET) Received: from dhcp-67f2.meeting.ietf.org (dhcp-67f2.meeting.ietf.org [130.129.103.242]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 2CDD3DF8; Tue, 9 Nov 2010 03:44:48 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: Date: Tue, 9 Nov 2010 10:44:45 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <6C3B1C2E-7FB0-4440-BAE8-517360E5D851@tzi.org> References: To: Linyi Tian X-Mailer: Apple Mail (2.1081) Cc: "CORE \(Constrained RESTful Environments\) WG" Subject: Re: [core] Question about the block options X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 02:44:49 -0000 Hi Linyi, thanks for looking into the document. > My question is related to the block size and length of block numbers.=20= > =95 Why the maximum for the block is 2048? How it is decided? = Since in the charter we also mentioned that even though CoAP is designed = for constrained environment it may also be used in general IP = environment. Do you think we can increase this size? This came out because of the simple fact that we allocated three bits to = the size, so in a power-of-two regime we can span a size range of 1:2^7 = or 1:128. Less than 16 didn't seem very useful, so the largest size = became 16*128 =3D 2048. I don't see a use case for that value; 1024 is = the more likely upper bound given that we don't have Path MTU discovery. (Note that the current layout of the option allows you to compute the = start address in bytes simply as (block & ~0xf) << (block & 0x7) once = you have decoded the option as a variable-length unsigned integer; = changing the layout might make this decoding slightly more complex.) > =95 Do you think that the NUM filed is too long? No. 12 bits seemed somewhat limiting, so we did allow for the next = higher size (24 bits, of which 20 bits are the block number) as well. I = don't think anybody will transfer a million blocks in a row using CoAP, = though... In a constrained implementation, you would likely only implement as much = as your largest resource would need. If no resource is 64 KiB or larger, the first two sizes will suffice. = But if you plan to use this for firmware updates, the third byte might = find use. Gruesse, Carsten > Is there real scenario the data will be divided into 2^20 pieces? Do = you think that in most cases the below first two options would be = enough? If that is the case, is it reasonable to further reduce the = length of NUM field? >=20 >=20 > 0 1 2 3 4 5 6 7 > +-+-+-+-+-+-+-+-+ > | NUM |M| SZX | > +-+-+-+-+-+-+-+-+ >=20 > 0 1 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | NUM |M| SZX | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > 0 1 2 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | NUM |M| SZX | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > Figure 1: Block option >=20 > Cheers, > Linyi > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From robert.cragie@gridmerge.com Mon Nov 8 18:55:15 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BED728C1B2 for ; Mon, 8 Nov 2010 18:55:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.523 X-Spam-Level: X-Spam-Status: No, score=-3.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YC0fHAIXzoS4 for ; Mon, 8 Nov 2010 18:55:12 -0800 (PST) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id 76C0C28C1D4 for ; Mon, 8 Nov 2010 18:55:07 -0800 (PST) Received: from client-86-29-103-19.glfd.adsl.virginmedia.com ([86.29.103.19] helo=[192.168.1.80]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) id 1PFeMo-0002T5-WE; Tue, 09 Nov 2010 02:55:27 +0000 Message-ID: <4CD8B81D.1080607@gridmerge.com> Date: Tue, 09 Nov 2010 02:55:25 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Peter Bigot References: In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000403040801040204060502" Cc: core@ietf.org Subject: Re: [core] Stuffing state in tokens X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 02:55:15 -0000 This is a cryptographically signed message in MIME format. --------------ms000403040801040204060502 Content-Type: multipart/alternative; boundary="------------070504040104070400010709" This is a multi-part message in MIME format. --------------070504040104070400010709 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Peter, The point is that it is just an opaque chunk of data returned to the=20 client. I think too many assumptions are being made about what is being=20 carried in that data. If it is simply classified as opaque, it could be=20 anything On that basis, protecting the client to/from server messages isn't=20 sufficient. That will give: * the server data origin integrity of the client data * the client data origin integrity of the server data but it won't give is: * the client data origin integrity of the client data it itself produ= ced So applying the MAC seems like a good idea to me in certain situations,=20 although given the opacity of the data, it is integral to the data=20 itself and therefore may only need to be recommended in the=20 specification, so the extended length of the field should suffice. Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com On 08/11/2010 6:12 PM, Peter Bigot wrote: > When introduced in draft-bormann-coap-misc-05, Token was specifically=20 > an opaque transaction-layer header introduced to eliminate the need to = > perform complex comparisons on URI fields to correlate an asynchronous = > response with a request. > > What is the motivation for extending this simple concept of a=20 > transaction-layer key interpretable only on the client into a=20 > back-door mechanism to convey meaningful state from client to server=20 > outside the message body, or to transport it to and from the server=20 > rather than retain it on the client? > > If it serves only this correlation role, is there a security aspect=20 > that needs to be addressed (that isn't naturally addressed by=20 > protecting the entire message)? > > Peter > > On Mon, Nov 8, 2010 at 1:39 AM, Eric Rescorla > wrote: > > As a general matter if you're going to have a token that has state > in it > that would be advantageous to someone who has the token to modify > then you need to protect the token. So, the question then becomes > how difficult it is for an attacker to generate a new, valid token > with > a different state. > > The classic way to generate these tokens (see for instance, > http://tools.ietf.org/html/draft-rescorla-stateless-tokens-01) is t= o > have some payload plus an integrity check (MAC). So you have > a token composed of: > > P || M > > Where P is the payload and M is the MAC. > > Say that the attacker generates an arbitrary payload P' and then > generates > a random MAC M', the chance that the MAC is valid is 2^{-m} where > m is the > length of the MAC. In most cases, a forgery probability of 2^{-64} > is considered > the minimum acceptable limit with 2^{-80} being preferred. This > implies a MAC > of at least 8-10 bytes. Now, perhaps there is some argument that > in this case > the risk of forgery is lower, but I don't see how it's going to be > acceptable > at less than a 4 byte (2^{-32} probability) MAC and we only > accepted that > for SRTP because there was an argument that a single forged media > sample > was a low risk. I don't see that that applies here. > > -Ekr > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --------------070504040104070400010709 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Peter,

    The point is that it is just an opaque chunk of data returned to the client. I think too many assumptions are being made about what is being carried in that data. If it is simply classified as opaque, it could be anything

    On that basis, protecting the client to/from server messages isn't sufficient. That will give:
    • the server data origin integrity of the client data
    • the client data origin integrity of the server data
    but it won't give is:
    • the client data origin integrity of the client data it itself produced
    So applying the MAC seems like a good idea to me in certain situations, although given the opacity of the data, it is integral to the data itself and therefore may only need to be recommended in the specification, so the extended length of the field should suffice.

    Robert

    Robert Cragie (Pacific Gas & Electric)

    Gridmerge Ltd.
    89 Greenfield Crescent,
    Wakefield, WF4 4WA, UK
    +44 1924 910888
    +1 415 513 0064
    http://www.gridmerge.com


    On 08/11/2010 6:12 PM, Peter Bigot wrote:
    When introduced in draft-bormann-coap-misc-05, Token was specifically an opaque transaction-layer header introduced to eliminate the need to perform complex comparisons on URI fields to correlate an asynchronous response with a request.

    What is the motivation for extending this simple concept of a transaction-layer key interpretable only on the client into a back-door mechanism to convey meaningful state from client to server outside the message body, or to transport it to and from the server rather than retain it on the client?

    If it serves only this correlation role, is there a security aspect that needs to be addressed (that isn't naturally addressed by protecting the entire message)?

    Peter

    On Mon, Nov 8, 2010 at 1:39 AM, Eric Rescorla <ekr@rtfm.com> wrote:
    As a general matter if you're going to have a token that has state in it
    that would be advantageous to someone who has the token to modify
    then you need to protect the token. So, the question then becomes
    how difficult it is for an attacker to generate a new, valid token with
    a different state.

    The classic way to generate these tokens (see for instance,
    have some payload plus an integrity check (MAC). So you have
    a token composed of:

    P || M

    Where P is the payload and M is the MAC.

    Say that the attacker generates an arbitrary payload P' and then generates
    a random MAC M', the chance that the MAC is valid is 2^{-m} where m is the
    length of the MAC. In most cases, a forgery probability of 2^{-64} is considered
    the minimum acceptable limit with 2^{-80} being preferred. This implies a MAC
    of at least 8-10 bytes. Now, perhaps there is some argument that in this case
    the risk of forgery is lower, but I don't see how it's going to be acceptable
    at less than a 4 byte (2^{-32} probability) MAC and we only accepted that
    for SRTP because there was an argument that a single forged media sample
    was a low risk. I don't see that that applies here.

    -Ekr


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


    
_______________________________________________
core mailing list
    core@=
ietf.org
https://www.ietf.org/mailman/listinfo/core
    --------------070504040104070400010709-- --------------ms000403040801040204060502 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRZTCC BN0wggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UE BhMCR0IxGzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEa MBgGA1UECgwRQ29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJV UzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUg VVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWls MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5 ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqk kqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWL eeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJ Q/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udl y/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0jBBgwFoAUoBEKIz6W8Qfs 4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQE AwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAR BgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5jb21vZG9j YS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwuY29t b2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvz bRx8NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12 jMOCAU9sAPMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxog L5dMUbtGB8SKN04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNB pEMD9O3vMyfbOeAUTibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mY HK9/FX8wggY+MIIFJqADAgECAhEAtlwUjTTxveqQY8soFvBYEjANBgkqhkiG9w0BAQUFADCB rjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEe MBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVz ZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIGFuZCBFbWFpbDAeFw0xMDA4MzAwMDAwMDBaFw0xMTA4MzAyMzU5NTlaMIHkMTUwMwYD VQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBFUlNPTkEgTk9UIFZBTElEQVRFRDFGMEQG A1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5u ZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMyBDb21vZG8gTGltaXRlZDEWMBQGA1UE AxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVy Z2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtAJ+m9Tgd3li8BgAIRth Gtth3YcCbhLPjfAcnDKcEGSrkZqao79Jg2uDW62IOwNCq9ae3VweBlvg3UUVu8upXzgDR/jF z4S1ZNk1if6V9QEiyBHdE1qMUQeeytedk3qw93CU5snWiXgVRacU8H8Dv+WJPsb4WYAH4MBz aJMI2N/E5XGGYpKFj9vxnEiQ7h83jXxw3Ee2rXCCbhJEci/tUl+Cx40pB3m7nlEdASY+A3tq JLIiG8Argf0+bWaxmuSUihKoakhHQruAylWY9EVtbKg8SACYZhdHCx2+ZSSrxbbAKSv0cDk0 0vQPvgH5GEi6zSB9QvqWCdBH/rL0XfV5jQIDAQABo4ICHTCCAhkwHwYDVR0jBBgwFoAUiYJn fcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFGkahOqOBMk95XAb8dpcRdaef8AYMA4GA1Ud DwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIx AQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzAp BggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCB mjBMoEqgSIZGaHR0cDovL2NybC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRB dXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0 L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYB BQUHAQEEYDBeMDYGCCsGAQUFBzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFD bGllbnRDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNV HREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEB ADcjSJQKgVIfD/IztFrhx2YqR9mKsDs3XakKd4hUoeunHgskiaMIQY2Kcfob48OuzrfY73rN fNoaqr5LZwDeVflMnZd0rPcTA9rAHq5l/qwdSta3k0xvBui0NAtOrSBdbqC4vggLKuZvoR2o 7mSbxSSBZHuVLObx/E5E+D5fjWC7ffNvr9y/uFXeCYFsM+Hc9VPIZ+cAY7JQFJEK/Nuti2QH IIxdR91N2vHuNXWIPROPFMl7y8ltO/fONwhxMcY2dH4JkDH6pdNzMtzykvsO0NeiRHnNlS4K A8aD9RaBR8FNQHq+JusC2tf11qdHBpHrVAK7dHodKDnbRr2t9VdrU2owggY+MIIFJqADAgEC AhEAtlwUjTTxveqQY8soFvBYEjANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJU UlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNV BAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0x MDA4MzAwMDAwMDBaFw0xMTA4MzAyMzU5NTlaMIHkMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3Qg TmV0d29yayAtIFBFUlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENv bmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0G A1UECxMWKGMpMjAwMyBDb21vZG8gTGltaXRlZDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEq MCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtAJ+m9Tgd3li8BgAIRthGtth3YcCbhLPjfAcnDKcEGSr kZqao79Jg2uDW62IOwNCq9ae3VweBlvg3UUVu8upXzgDR/jFz4S1ZNk1if6V9QEiyBHdE1qM UQeeytedk3qw93CU5snWiXgVRacU8H8Dv+WJPsb4WYAH4MBzaJMI2N/E5XGGYpKFj9vxnEiQ 7h83jXxw3Ee2rXCCbhJEci/tUl+Cx40pB3m7nlEdASY+A3tqJLIiG8Argf0+bWaxmuSUihKo akhHQruAylWY9EVtbKg8SACYZhdHCx2+ZSSrxbbAKSv0cDk00vQPvgH5GEi6zSB9QvqWCdBH /rL0XfV5jQIDAQABo4ICHTCCAhkwHwYDVR0jBBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0w HQYDVR0OBBYEFGkahOqOBMk95XAb8dpcRdaef8AYMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMB Af8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEE BAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6 Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0cDovL2Ny bC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVt YWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xp ZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQUF BzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwYB BQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRtyb2JlcnQuY3Jh Z2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBADcjSJQKgVIfD/IztFrhx2Yq R9mKsDs3XakKd4hUoeunHgskiaMIQY2Kcfob48OuzrfY73rNfNoaqr5LZwDeVflMnZd0rPcT A9rAHq5l/qwdSta3k0xvBui0NAtOrSBdbqC4vggLKuZvoR2o7mSbxSSBZHuVLObx/E5E+D5f jWC7ffNvr9y/uFXeCYFsM+Hc9VPIZ+cAY7JQFJEK/Nuti2QHIIxdR91N2vHuNXWIPROPFMl7 y8ltO/fONwhxMcY2dH4JkDH6pdNzMtzykvsO0NeiRHnNlS4KA8aD9RaBR8FNQHq+JusC2tf1 1qdHBpHrVAK7dHodKDnbRr2t9VdrU2oxggRgMIIEXAIBATCBxDCBrjELMAkGA1UEBhMCVVMx CzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVT RVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0 BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIR ALZcFI008b3qkGPLKBbwWBIwCQYFKw4DAhoFAKCCAnAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTAxMTA5MDI1NTI1WjAjBgkqhkiG9w0BCQQxFgQUhniL gGTKcaAZu784qhRZMCdHNPowXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJV VDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4t VVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQC2XBSNNPG96pBj yygW8FgSMIHXBgsqhkiG9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgT AlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBO ZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIRALZcFI008b3q kGPLKBbwWBIwDQYJKoZIhvcNAQEBBQAEggEAlmbqyoJWIgsoHBcly2HfCD40zmal6GX38x/e MymXqBaYlE0hn/e3HXiX1x9zuTjIJmrZui8flgMQmgWQYlRhHx5M1fY5PJcIfIcQBkKgFQ+z xFToPPHKqZagILTpNZUiCjeDAs9GHe+D/Mk59pWomHDqsszfPhGQLLzZ/3H/dymnBQI52yTq fSzlPeucvQGO4hWoxaqUO6DAlydSbgYjEJg4sV6b5uwCfNnhMfzEbs5Rpc+9QaxuyMrQfHwB T85LJOTKhTRKFNg5zWGt6qF+wQD5fFPvI/o1+geTGSf6w4CMcLd/Isnmhw+IxQhh/tdsDNEQ JeVmz/kFRHF0i04KgwAAAAAAAA== --------------ms000403040801040204060502-- From tianlinyi@huawei.com Mon Nov 8 19:21:48 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48EE628C1FE for ; Mon, 8 Nov 2010 19:21:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.39 X-Spam-Level: ** X-Spam-Status: No, score=2.39 tagged_above=-999 required=5 tests=[AWL=-0.961, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GSZKbHHrZCoh for ; Mon, 8 Nov 2010 19:21:47 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 4530B28C20C for ; Mon, 8 Nov 2010 19:21:47 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LBL00F2SLCQAH@szxga04-in.huawei.com> for core@ietf.org; Tue, 09 Nov 2010 11:22:02 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LBL00ATLLCQ4G@szxga04-in.huawei.com> for core@ietf.org; Tue, 09 Nov 2010 11:22:02 +0800 (CST) Received: from [130.129.131.148] (dhcp-8394.meeting.ietf.org [130.129.131.148]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LBL0017ELCLH7@szxml02-in.huawei.com>; Tue, 09 Nov 2010 11:22:02 +0800 (CST) Date: Tue, 09 Nov 2010 11:21:56 +0800 From: Linyi Tian In-reply-to: <6C3B1C2E-7FB0-4440-BAE8-517360E5D851@tzi.org> To: Carsten Bormann Message-id: MIME-version: 1.0 Content-type: text/plain; charset=GB2312 Content-transfer-encoding: quoted-printable Thread-topic: [core] Question about the block options Thread-index: Act/vUMCd5+sd3ZVgEicYOT895xfdQ== User-Agent: Microsoft-Entourage/12.25.0.100505 Cc: "CORE \(Constrained RESTful Environments\) WG" Subject: Re: [core] Question about the block options X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 03:21:48 -0000 Hi, Carsten Bormann Ok. Now I understand. I misunderstood this block as application layer fragmentation.=20 So this design will make each CoAP block fits one UDP package (e.g. MTU 1480). Then the block size makes perfect sense ranged from 16 to 2048. I agree with you 2^12 NUM would not be enough for firmware update case. Thanks a lot for your prompt response. Cheers, Linyi On 10-11-9 =C9=CF=CE=E710:44, "Carsten Bormann" wrote: > Hi Linyi, >=20 > thanks for looking into the document. >=20 >> My question is related to the block size and length of block numbers. >> =A1=A4 Why the maximum for the block is 2048? How it is decided? Since in th= e >> charter we also mentioned that even though CoAP is designed for constrai= ned >> environment it may also be used in general IP environment. Do you think = we >> can increase this size? >=20 > This came out because of the simple fact that we allocated three bits to = the > size, so in a power-of-two regime we can span a size range of 1:2^7 or 1:= 128. > Less than 16 didn't seem very useful, so the largest size became 16*128 =3D > 2048. I don't see a use case for that value; 1024 is the more likely upp= er > bound given that we don't have Path MTU discovery. >=20 > (Note that the current layout of the option allows you to compute the sta= rt > address in bytes simply as (block & ~0xf) << (block & 0x7) once you have > decoded the option as a variable-length unsigned integer; changing the la= yout > might make this decoding slightly more complex.) >=20 >> =A1=A4 Do you think that the NUM filed is too long? >=20 > No. 12 bits seemed somewhat limiting, so we did allow for the next highe= r > size (24 bits, of which 20 bits are the block number) as well. I don't t= hink > anybody will transfer a million blocks in a row using CoAP, though... >=20 > In a constrained implementation, you would likely only implement as much = as > your largest resource would need. > If no resource is 64 KiB or larger, the first two sizes will suffice. Bu= t if > you plan to use this for firmware updates, the third byte might find use. >=20 > Gruesse, Carsten >=20 >=20 >> Is there real scenario the data will be divided into 2^20 pieces? Do you >> think that in most cases the below first two options would be enough? If= that >> is the case, is it reasonable to further reduce the length of NUM field? >>=20 >>=20 >> 0 1 2 3 4 5 6 7 >> +-+-+-+-+-+-+-+-+ >> | NUM |M| SZX | >> +-+-+-+-+-+-+-+-+ >>=20 >> 0 1 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | NUM |M| SZX | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>=20 >> 0 1 2 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | NUM |M| SZX | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>=20 >> Figure 1: Block option >>=20 >> Cheers, >> Linyi >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >=20 From zach@sensinode.com Mon Nov 8 21:29:14 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A89F03A6905 for ; Mon, 8 Nov 2010 21:29:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4eQs-hPr3IlH for ; Mon, 8 Nov 2010 21:29:13 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 026143A68F0 for ; Mon, 8 Nov 2010 21:29:12 -0800 (PST) Received: from dhcp-75ec.meeting.ietf.org (dhcp-75ec.meeting.ietf.org [130.129.117.236]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id oA95TODd010165 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 9 Nov 2010 07:29:29 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-188--411764134; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: <4CD8B81D.1080607@gridmerge.com> Date: Tue, 9 Nov 2010 13:29:24 +0800 Message-Id: References: <4CD8B81D.1080607@gridmerge.com> To: robert.cragie@gridmerge.com X-Mailer: Apple Mail (2.1081) Cc: core@ietf.org Subject: Re: [core] Stuffing state in tokens X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 05:29:14 -0000 --Apple-Mail-188--411764134 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 9, 2010, at 10:55 AM, Robert Cragie wrote: > So applying the MAC seems like a good idea to me in certain = situations, although given the opacity of the data, it is integral to = the data itself and therefore may only need to be recommended in the = specification, so the extended length of the field should suffice. I totally agree. So now we need to decide what that length should be. If = we need an 8-10 byte MAC, I guess a Token Option length up to 16 bytes = would suffice? Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 --Apple-Mail-188--411764134 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9 fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb 6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja 5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I 2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTEwOTA1Mjky NVowIwYJKoZIhvcNAQkEMRYEFI+PGdvUO/2vEtQw+2CbjMzYrgb2MIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAC5D9hF7ho8O/dHQtyQq2O/oXQKoLfnliGe9V8h0M/Tw9bLiQddXR4Am 0wlYBVtiALSRDLuKxVZV5Q+cAJtKOM3/F1JCCcmrKTWXqepoN3zDI3gNjxd3Kku13u96GOKjo5ST Xr5XvBgTJr+IqLAIKEna1GeMAeVsog/qcvPEKzeXp7waQTB+4UPVAPXyNFe+hE0cebAnhAjl8Ph+ sSJ25Ra69srv7LthF8hvcbaEosMcBCMdoOqGeX55ACd4H1N3nOFvrwrCc4pU1VklyExfXVryaQ3p iADauA7iw8Lsn0ukW4NiIY1AspAWso/9uOXcc5DHv1cu+JuU8fpas5rVlm0AAAAAAAA= --Apple-Mail-188--411764134-- From adam@nostrum.com Mon Nov 8 22:01:14 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DF883A69ED for ; Mon, 8 Nov 2010 22:01:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.475 X-Spam-Level: X-Spam-Status: No, score=-102.475 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bgO9odqG7FJb for ; Mon, 8 Nov 2010 22:01:13 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id ABACA3A69AE for ; Mon, 8 Nov 2010 22:01:05 -0800 (PST) Received: from dhcp-634e.meeting.ietf.org (dhcp-634e.meeting.ietf.org [130.129.99.78]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id oA961O94068661 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Tue, 9 Nov 2010 00:01:26 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4CD8E3B3.7040101@nostrum.com> Date: Tue, 09 Nov 2010 14:01:23 +0800 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: "CORE (Constrained RESTful Environments) WG" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.99.78 is authenticated by a trusted mechanism) Subject: [core] Tightening up unknown status code semantics X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 06:01:14 -0000 CoAP borrows its status code structure (after a fashion) from HTTP. But, in reading through the current document, there's an important aspect of HTTP status codes that is missing, and that I suspect we want to adopt. The language in RFC 2616 in question is: HTTP status codes are extensible. HTTP applications are not required to understand the meaning of all registered status codes, though such understanding is obviously desirable. However, applications MUST understand the class of any status code, as indicated by the first digit, and treat any unrecognized response as being equivalent to the x00 status code of that class, with the exception that an unrecognized response MUST NOT be cached. For example, if an unrecognized status code of 431 is received by the client, it can safely assume that there was something wrong with its request and treat the response as if it had received a 400 status code. To maintain reasonable behavior as we introduce new status codes in CoAP, I think we want to have similar language in the base CoAP spec. But this raises another question about how to handle the new 240 - 255 class of CoAP-specific error codes. Certainly we don't want to treat all unknown CoAP errors as "240 Token Required." Finally, on the topic of response codes: we might benefit from some explicit language about how HTTP/CoAP proxies deal with mapping these CoAP-specific codes into HTTP responses. Presumably, if the proxy can recover (e.g., on receipt of a 240), it will do so. But you can also envision circumstances -- like 241 -- that the server won't be able to recover from. Perhaps we don't need to specify how the proxy translates these into HTTP; but it might be nice to be unambiguous in the specification (possibly something like calling out that an HTTP 502 response would be a reasonable response if it receives a CoAP-specific response it can't automatically recover from). (As an aside, I note that you could have 39 different CoAP codes if you put them in the 1-39 range, rather than the 15 codes afforded by the 240 - 255 range). /a From alper.yegin@yegin.org Mon Nov 8 22:18:14 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B79ED3A6914 for ; Mon, 8 Nov 2010 22:18:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.15 X-Spam-Level: X-Spam-Status: No, score=-101.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2SuNAOjKZSf for ; Mon, 8 Nov 2010 22:18:10 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 6314428C119 for ; Mon, 8 Nov 2010 22:15:28 -0800 (PST) Received: from ibm (dhcp-8371.meeting.ietf.org [130.129.131.113]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MMksB-1PB2uX25Cp-008Htn; Tue, 09 Nov 2010 01:14:44 -0500 From: "Alper Yegin" To: "'Cullen Jennings'" , References: <05D7FB47-E2DC-4F73-B9F7-551E9251FF23@cisco.com> <4CD71EF0.2080606@gridmerge.com> <5796D385-F3C8-42CE-A28C-54DDFEC0E11D@cisco.com> In-Reply-To: <5796D385-F3C8-42CE-A28C-54DDFEC0E11D@cisco.com> Date: Tue, 9 Nov 2010 08:14:33 +0200 Message-ID: <03c501cb7fd5$674e08c0$35ea1a40$@yegin@yegin.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Act/DC/kA/IPepRgQ4iDjALR5TvfngAyNl6A Content-Language: en-us X-Provags-ID: V02:K0:qXOTmCEcD9sBPgfDc3ZKO3rnBQx87gG9rHVfdXpq7ko wAVdPo006/t3eiWmxbmXkNjrMoKgy5z0ncjfFUJeHR19CLP+8z /+USsanhuE75rxzY2EcJhwCuS5KbGSCaDk5ULNPHoE72GbK3xT jtfzvtSmS6mMw3YVpeIX/u7TfJFG3d8wieENqrp/fq7gtT/Qsn cvLlrJAmW2M1JkvhfBpkgAnTnKKmJwbhrLkhIRtQtc= Cc: 'core' Subject: Re: [core] draft-oflynn-core-bootstrapping X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 06:18:14 -0000 Hello, Alternative to the manufacturer running its own Sub CA is to let a CA vendor produce the certs for the manufacturer. That can increase the cost for the manufacturer, but reduces the risk mentioned in Cullen's email. Alper -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Cullen Jennings Sent: Monday, November 08, 2010 8:10 AM To: robert.cragie@gridmerge.com Cc: core Subject: Re: [core] draft-oflynn-core-bootstrapping On Nov 7, 2010, at 2:49 PM, Robert Cragie wrote: > Hi Cullen, > >> Few minor things. >> It mention SE2.0 has devices be programmed with a certificate. What the trust root for theses? >> > There is a PKI with a Root CA as usual so the certificate can be verified up to the root. There may be more than one Root CA. This is pretty standard - is it necessary to mention this? No I don't think it needs to be mentioned in the draft I was just trying to get up to speed. I was trying to get an idea if there was one PKI and all the the manufactured build devices with certificates that go up to the same trust root -- or -- if it was the people deploying the devices had their own root CA and as they deployed the devices they installed certificates so different deployments might have a different trust root. Some of the IP phone manufactures consider both of theses models and decided neither of them were ideal. The model where the certificate needed to be installed on the phone by the service provider meant you could not ship the phone from manufacture to the where it was being installed or at least you had to touch the phone in some way as part of the installment to install the certificate. On the other hand, the manufactures were not keen on having the liability of running a CA to sign the certs on the phones where if it was compromised, it would compromise the security of all their customers operational networks. It seems like there might some of the same concerns these deployments. The end solution that is used involves the manufactures installs a manufactured installed cert that is tied to the mac address of the phone which you can barcode off the boxes without opening them. The only thing this certificate is used for is to identify the phone to install a local certificate. So the service provider would use the manufacture certificate to help install the local certificate and the SP runs, or contracted out, the CA for local certificates. If the manufacture's CA is compromised, then the SP has to stop allowing new phones to be enrolled in the system while the issues is dealt with but all the phones that were already enrolled before the compromise are not at risk. The risk of the operational network sits with the SP's CA. Clearly if the manufactures CA is compromised but it takes them months to notice, then there phones deployed in that time window are at risk but this type of scheme helps mitigate risk and helps allocate it between manufactures and SP. _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From Mohana.Jeyatharan@sg.panasonic.com Mon Nov 8 22:21:22 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 041393A67F3 for ; Mon, 8 Nov 2010 22:21:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ou8iFJlPXVCE for ; Mon, 8 Nov 2010 22:21:19 -0800 (PST) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id CC2113A686E for ; Mon, 8 Nov 2010 22:21:17 -0800 (PST) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile14) with ESMTP id oA96LdYV015018 for ; Tue, 9 Nov 2010 15:21:39 +0900 (JST) Received: from pslexc01.psl.local ([10.81.112.5]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili11) with ESMTP id oA96Ld512136 for ; Tue, 9 Nov 2010 15:21:39 +0900 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Nov 2010 14:21:34 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD04786B32@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Some clarification on CoAP POST/PUT related to caching Thread-index: Act/1ZdmMQMtKt6CQHW7rs4w+jDJFQ== From: "Mohana Jeyatharan" To: Subject: [core] Some clarification on CoAP POST/PUT related to caching X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 06:21:22 -0000 Hi Zach, I have a small clarification question on CoAP. Can CoAP support caching for PUT, POST methods? Yesterday your slides mentioned caching only for GET method. I would like to know whether current CoAP can support this. A CoAP device (or HTTP device) can do a POST/PUT to a resource that is cached in the proxy. I was thinking such mechanism is possible. Example: -------------- HTTP client sending a POST to client that is running only CoAP. The proxy intercepts and updates the resource state or cached resource state of the client. Then when CoAP device is ready, proxy will do a POST to the CoAP client. I was thinking such methods were possible with CoAP. Thanks. BR, Mohana From heer@informatik.rwth-aachen.de Mon Nov 8 22:27:21 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32BBD28C0EF for ; Mon, 8 Nov 2010 22:27:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.8 X-Spam-Level: X-Spam-Status: No, score=-4.8 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pAMOADOUF6Bt for ; Mon, 8 Nov 2010 22:27:19 -0800 (PST) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by core3.amsl.com (Postfix) with ESMTP id 3693928C0E2 for ; Mon, 8 Nov 2010 22:27:19 -0800 (PST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_5JnftY7q8hYnmwHpJqghyw)" Received: from ironport-out-2.rz.rwth-aachen.de ([134.130.5.41]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LBL00JHZTY6P9C0@mta-2.ms.rz.RWTH-Aachen.de> for core@ietf.org; Tue, 09 Nov 2010 07:27:42 +0100 (CET) X-IronPort-AV: E=Sophos; i="4.59,173,1288566000"; d="scan'208,217"; a="42803825" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-2.rz.rwth-aachen.de with ESMTP; Tue, 09 Nov 2010 07:27:42 +0100 Received: from dhcp-4889.meeting.ietf.org ([unknown] [130.129.72.137]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0LBL00M69TY1IV10@relay-auth-2.ms.rz.rwth-aachen.de> for core@ietf.org; Tue, 09 Nov 2010 07:27:42 +0100 (CET) From: Tobias Heer In-reply-to: <4CD8B81D.1080607@gridmerge.com> Date: Tue, 09 Nov 2010 14:27:35 +0800 Message-id: <8CA62EDC-9E72-44E7-9C22-605394C6EABF@cs.rwth-aachen.de> References: <4CD8B81D.1080607@gridmerge.com> To: robert.cragie@gridmerge.com X-Mailer: Apple Mail (2.1081) Cc: core@ietf.org Subject: Re: [core] Stuffing state in tokens X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 06:27:21 -0000 --Boundary_(ID_5JnftY7q8hYnmwHpJqghyw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, Am 09.11.2010 um 10:55 schrieb Robert Cragie: > Hi Peter, > > The point is that it is just an opaque chunk of data returned to the client. I think too many assumptions are being made about what is being carried in that data. If it is simply classified as opaque, it could be anything > > On that basis, protecting the client to/from server messages isn't sufficient. That will give: > the server data origin integrity of the client data > the client data origin integrity of the server data > but it won't give is: > the client data origin integrity of the client data it itself produced > So applying the MAC seems like a good idea to me in certain situations, although given the opacity of the data, it is integral to the data itself and therefore may only need to be recommended in the specification, so the extended length of the field should suffice. > In addition to adding a MAC, one should also think about replay protection. Otherwise, it may be possible to reset a client to a state that corresponds to a previous (valid and authenticated) token. Staying completely stateless may not allow for such replay protection in all cases. I agree that the exact use of the token should not be fully specified in the document but should be left to implementors. However, it might help to give implementors some guidance in designing it properly (in the form of recommendations). Tobias > Robert > Robert Cragie (Pacific Gas & Electric) > > Gridmerge Ltd. > 89 Greenfield Crescent, > Wakefield, WF4 4WA, UK > +44 1924 910888 > +1 415 513 0064 > http://www.gridmerge.com > > > On 08/11/2010 6:12 PM, Peter Bigot wrote: >> >> When introduced in draft-bormann-coap-misc-05, Token was specifically an opaque transaction-layer header introduced to eliminate the need to perform complex comparisons on URI fields to correlate an asynchronous response with a request. >> >> What is the motivation for extending this simple concept of a transaction-layer key interpretable only on the client into a back-door mechanism to convey meaningful state from client to server outside the message body, or to transport it to and from the server rather than retain it on the client? >> >> If it serves only this correlation role, is there a security aspect that needs to be addressed (that isn't naturally addressed by protecting the entire message)? >> >> Peter >> >> On Mon, Nov 8, 2010 at 1:39 AM, Eric Rescorla wrote: >> As a general matter if you're going to have a token that has state in it >> that would be advantageous to someone who has the token to modify >> then you need to protect the token. So, the question then becomes >> how difficult it is for an attacker to generate a new, valid token with >> a different state. >> >> The classic way to generate these tokens (see for instance, >> http://tools.ietf.org/html/draft-rescorla-stateless-tokens-01) is to >> have some payload plus an integrity check (MAC). So you have >> a token composed of: >> >> P || M >> >> Where P is the payload and M is the MAC. >> >> Say that the attacker generates an arbitrary payload P' and then generates >> a random MAC M', the chance that the MAC is valid is 2^{-m} where m is the >> length of the MAC. In most cases, a forgery probability of 2^{-64} is considered >> the minimum acceptable limit with 2^{-80} being preferred. This implies a MAC >> of at least 8-10 bytes. Now, perhaps there is some argument that in this case >> the risk of forgery is lower, but I don't see how it's going to be acceptable >> at less than a 4 byte (2^{-32} probability) MAC and we only accepted that >> for SRTP because there was an argument that a single forged media sample >> was a low risk. I don't see that that applies here. >> >> -Ekr >> >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> >> >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core -- Dipl.-Inform. Tobias Heer, Ph.D. Student Chair of Communication and Distributed Systems - comsys RWTH Aachen University, Germany tel: +49 241 80 207 76 web: http://ds.cs.rwth-aachen.de/members/heer blog: http://dtobi.wordpress.com/ card: http://card.ly/dtobi --Boundary_(ID_5JnftY7q8hYnmwHpJqghyw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT Hi,

    Am 09.11.2010 um 10:55 schrieb Robert Cragie:

    Hi Peter,

    The point is that it is just an opaque chunk of data returned to the client. I think too many assumptions are being made about what is being carried in that data. If it is simply classified as opaque, it could be anything

    On that basis, protecting the client to/from server messages isn't sufficient. That will give:
    • the server data origin integrity of the client data
    • the client data origin integrity of the server data
    but it won't give is:
    • the client data origin integrity of the client data it itself produced
    So applying the MAC seems like a good idea to me in certain situations, although given the opacity of the data, it is integral to the data itself and therefore may only need to be recommended in the specification, so the extended length of the field should suffice.

    In addition to adding a MAC, one should also think about replay protection. Otherwise, it may be possible to reset a client to a state that corresponds to a previous (valid and authenticated) token. Staying completely stateless may not allow for such replay protection in all cases.

    I agree that the exact use of the token should not be fully specified in the document but should be left to implementors. However, it might help to give implementors some guidance in designing it properly (in the form of recommendations).

    Tobias


    Robert

    Robert Cragie (Pacific Gas & Electric)

    Gridmerge Ltd.
    89 Greenfield Crescent,
    Wakefield, WF4 4WA, UK
    +44 1924 910888
    +1 415 513 0064
    http://www.gridmerge.com


    On 08/11/2010 6:12 PM, Peter Bigot wrote:
    When introduced in draft-bormann-coap-misc-05, Token was specifically an opaque transaction-layer header introduced to eliminate the need to perform complex comparisons on URI fields to correlate an asynchronous response with a request.

    What is the motivation for extending this simple concept of a transaction-layer key interpretable only on the client into a back-door mechanism to convey meaningful state from client to server outside the message body, or to transport it to and from the server rather than retain it on the client?

    If it serves only this correlation role, is there a security aspect that needs to be addressed (that isn't naturally addressed by protecting the entire message)?

    Peter

    On Mon, Nov 8, 2010 at 1:39 AM, Eric Rescorla <ekr@rtfm.com> wrote:
    As a general matter if you're going to have a token that has state in it
    that would be advantageous to someone who has the token to modify
    then you need to protect the token. So, the question then becomes
    how difficult it is for an attacker to generate a new, valid token with
    a different state.

    The classic way to generate these tokens (see for instance,
    have some payload plus an integrity check (MAC). So you have
    a token composed of:

    P || M

    Where P is the payload and M is the MAC.

    Say that the attacker generates an arbitrary payload P' and then generates
    a random MAC M', the chance that the MAC is valid is 2^{-m} where m is the
    length of the MAC. In most cases, a forgery probability of 2^{-64} is considered
    the minimum acceptable limit with 2^{-80} being preferred. This implies a MAC
    of at least 8-10 bytes. Now, perhaps there is some argument that in this case
    the risk of forgery is lower, but I don't see how it's going to be acceptable
    at less than a 4 byte (2^{-32} probability) MAC and we only accepted that
    for SRTP because there was an argument that a single forged media sample
    was a low risk. I don't see that that applies here.

    -Ekr


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


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

    -- 
    Dipl.-Inform. Tobias Heer, Ph.D. Student
    Chair of Communication and Distributed Systems - comsys
    RWTH Aachen University, Germany
    tel: +49 241 80 207 76
    web: http://ds.cs.rwth-aachen.de/members/heer
    blog: http://dtobi.wordpress.com/
    card: http://card.ly/dtobi

    --Boundary_(ID_5JnftY7q8hYnmwHpJqghyw)-- From Mohana.Jeyatharan@sg.panasonic.com Mon Nov 8 22:47:44 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 243103A67AD for ; Mon, 8 Nov 2010 22:47:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gXexoqSE9p-g for ; Mon, 8 Nov 2010 22:47:42 -0800 (PST) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id E7FA83A690A for ; Mon, 8 Nov 2010 22:47:40 -0800 (PST) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile13) with ESMTP id oA96lt3r026305; Tue, 9 Nov 2010 15:47:55 +0900 (JST) Received: from pslexc01.psl.local ([10.81.112.5]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili14) with ESMTP id oA96lsg21296; Tue, 9 Nov 2010 15:47:54 +0900 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Nov 2010 14:47:50 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD04786B4F@pslexc01.psl.local> In-Reply-To: <1C353DAB-3C1B-4282-BB01-DF397A46DABD@tzi.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] Some clarification on CoAP POST/PUT related to caching Thread-index: Act/19AtUjXx38vmR5CYsw32tz99HAAAQToA References: <5F09D220B62F79418461A978CA0921BD04786B32@pslexc01.psl.local> <1C353DAB-3C1B-4282-BB01-DF397A46DABD@tzi.org> From: "Mohana Jeyatharan" To: "Carsten Bormann" Cc: core@ietf.org Subject: Re: [core] Some clarification on CoAP POST/PUT related to caching X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 06:47:44 -0000 Hi Carsten,=20 Thanks for reply. Please see below. BR,=20 Mohana > -----Original Message----- > From: Carsten Bormann [mailto:cabo@tzi.org] > Sent: Tuesday, November 09, 2010 2:32 PM > To: Mohana Jeyatharan > Cc: core@ietf.org > Subject: Re: [core] Some clarification on CoAP POST/PUT related to caching >=20 > Mohana, >=20 > HTTP only ever allows caching responses. > PUT/POST invalidates a cache but never fills the cache from the request > body. CoAP follows the HTTP principles, so such caching is not possible. Or perhaps you are saying there is no need for caching of POST/PUT In the majority of the scenarios where HTTP and CoAP is used. Or does caching for request body break the RESTful principles?=20 >=20 > What you are proposing appears to be caching a request body. Yes, POST will carry message in the request body. I was considering caching for this request body. > More generally, you seem to be assuming that the proxy can anticipate what > the server will do with the POST. >=20 > I think it would be useful to flesh out your example a bit more, in particular > with respect to the use case. I was thinking if the server is in sleep state, then when the client does a POST, the proxy can cache this information and send it to server when it wakes up. This was the scenario I had in mind.=20 > Gruesse, Carsten From robert.cragie@gridmerge.com Mon Nov 8 23:00:34 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E04FD3A6807 for ; Mon, 8 Nov 2010 23:00:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.531 X-Spam-Level: X-Spam-Status: No, score=-3.531 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ph9J3PR0WM-t for ; Mon, 8 Nov 2010 23:00:31 -0800 (PST) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id 53C723A67FA for ; Mon, 8 Nov 2010 23:00:28 -0800 (PST) Received: from client-86-29-103-19.glfd.adsl.virginmedia.com ([86.29.103.19] helo=[192.168.1.80]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) id 1PFiCI-00089Y-8E; Tue, 09 Nov 2010 07:00:50 +0000 Message-ID: <4CD8F1A0.50203@gridmerge.com> Date: Tue, 09 Nov 2010 07:00:48 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Cullen Jennings References: <05D7FB47-E2DC-4F73-B9F7-551E9251FF23@cisco.com> <4CD71EF0.2080606@gridmerge.com> <5796D385-F3C8-42CE-A28C-54DDFEC0E11D@cisco.com> In-Reply-To: <5796D385-F3C8-42CE-A28C-54DDFEC0E11D@cisco.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000207030501090807050300" Cc: core Subject: Re: [core] draft-oflynn-core-bootstrapping X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 07:00:34 -0000 This is a cryptographically signed message in MIME format. --------------ms000207030501090807050300 Content-Type: multipart/alternative; boundary="------------060106010403020905060603" This is a multi-part message in MIME format. --------------060106010403020905060603 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Cullen, What you describe is pretty much what we are proposing for ZigBee SE=20 2.0. In my comment below, I was only referring to mfr. certificates. Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com On 08/11/2010 6:10 AM, Cullen Jennings wrote: > On Nov 7, 2010, at 2:49 PM, Robert Cragie wrote: > >> Hi Cullen, >> >>> Few minor things. >>> It mention SE2.0 has devices be programmed with a certificate. What t= he trust root for theses? >>> >> There is a PKI with a Root CA as usual so the certificate can be = verified up to the root. There may be more than one Root CA. This is pret= ty standard - is it necessary to mention this? > No I don't think it needs to be mentioned in the draft I was just tryin= g to get up to speed. > > I was trying to get an idea if there was one PKI and all the the manufa= ctured build devices with certificates that go up to the same trust root = -- or -- if it was the people deploying the devices had their own root C= A and as they deployed the devices they installed certificates so differe= nt deployments might have a different trust root. > > Some of the IP phone manufactures consider both of theses models and de= cided neither of them were ideal. The model where the certificate needed = to be installed on the phone by the service provider meant you could not = ship the phone from manufacture to the where it was being installed or at= least you had to touch the phone in some way as part of the installment = to install the certificate. On the other hand, the manufactures were not = keen on having the liability of running a CA to sign the certs on the pho= nes where if it was compromised, it would compromise the security of all = their customers operational networks. It seems like there might some of t= he same concerns these deployments. > > The end solution that is used involves the manufactures installs a manu= factured installed cert that is tied to the mac address of the phone whic= h you can barcode off the boxes without opening them. The only thing this= certificate is used for is to identify the phone to install a local cert= ificate. So the service provider would use the manufacture certificate to= help install the local certificate and the SP runs, or contracted out, t= he CA for local certificates. If the manufacture's CA is compromised, the= n the SP has to stop allowing new phones to be enrolled in the system whi= le the issues is dealt with but all the phones that were already enrolled= before the compromise are not at risk. The risk of the operational netwo= rk sits with the SP's CA. Clearly if the manufactures CA is compromised b= ut it takes them months to notice, then there phones deployed in that tim= e window are at risk but this type of scheme helps mitigate risk and help= s allocate it between manufactures and SP. --------------060106010403020905060603 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Cullen,

    What you describe is pretty much what we are proposing for ZigBee SE 2.0. In my comment below, I was only referring to mfr. certificates.<= br>
    Robert

    Robert Cragie (Pacific Gas & Electric)

    Gridmerge Ltd.
    89 Greenfield Crescent,
    Wakefield, WF4 4WA, UK
    +44 1924 910888
    +1 415 513 0064
    http://www.gridmerge.com


    On 08/11/2010 6:10 AM, Cullen Jennings wrote: 
    On Nov 7, 2010, at 2:49 PM, Robert Cragie wrote:


    Hi Cullen,


    Few minor things.=20
It mention SE2.0 has devices be programmed with a certificate. What the t=
rust root for theses?=20


    <RCC>There is a PKI with a Root CA as usual =
so the certificate can be verified up to the root. There may be more than=
 one Root CA. This is pretty standard - is it necessary to mention this?&=
lt;/RCC>

    No I don't think it needs to be mentioned in the draft I was just trying =
to get up to speed.=20

I was trying to get an idea if there was one PKI and all the the manufact=
ured build devices with certificates that go up to the same trust root --=
 or --  if it was the people deploying the devices had their own root CA =
and as they deployed the devices they installed certificates so different=
 deployments might have a different trust root.=20

Some of the IP phone manufactures consider both of theses models and deci=
ded neither of them were ideal. The model where the certificate needed to=
 be installed on the phone by the service provider meant you could not sh=
ip the phone from manufacture to the where it was being installed or at l=
east you had to touch the phone in some way as part of the installment to=
 install the certificate. On the other hand, the manufactures were not ke=
en on having the liability of running a CA to sign the certs on the phone=
s where if it was compromised, it would compromise the security of all th=
eir customers operational networks. It seems like there might some of the=
 same concerns these deployments.

The end solution that is used involves the manufactures installs a manufa=
ctured installed cert that is tied to the mac address of the phone which =
you can barcode off the boxes without opening them. The only thing this c=
ertificate is used for is to identify the phone to install a local certif=
icate. So the service provider would use the manufacture certificate to h=
elp install the local certificate and the SP runs, or contracted out, the=
 CA for local certificates. If the manufacture's CA is compromised, then =
the SP has to stop allowing new phones to be enrolled in the system while=
 the issues is dealt with but all the phones that were already enrolled b=
efore the compromise are not at risk. The risk of the operational network=
 sits with the SP's CA. Clearly if the manufactures CA is compromised but=
 it takes them months to notice, then there phones deployed in that time =
window are at risk but this type of scheme helps mitigate risk and helps =
allocate it between manufactures and SP.
=20
    --------------060106010403020905060603-- --------------ms000207030501090807050300 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRZTCC BN0wggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UE BhMCR0IxGzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEa MBgGA1UECgwRQ29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJV UzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUg VVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWls MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5 ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqk kqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWL eeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJ Q/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udl y/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0jBBgwFoAUoBEKIz6W8Qfs 4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQE AwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAR BgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5jb21vZG9j YS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwuY29t b2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvz bRx8NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12 jMOCAU9sAPMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxog L5dMUbtGB8SKN04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNB pEMD9O3vMyfbOeAUTibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mY HK9/FX8wggY+MIIFJqADAgECAhEAtlwUjTTxveqQY8soFvBYEjANBgkqhkiG9w0BAQUFADCB rjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEe MBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVz ZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIGFuZCBFbWFpbDAeFw0xMDA4MzAwMDAwMDBaFw0xMTA4MzAyMzU5NTlaMIHkMTUwMwYD VQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBFUlNPTkEgTk9UIFZBTElEQVRFRDFGMEQG A1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5u ZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMyBDb21vZG8gTGltaXRlZDEWMBQGA1UE AxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVy Z2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtAJ+m9Tgd3li8BgAIRth Gtth3YcCbhLPjfAcnDKcEGSrkZqao79Jg2uDW62IOwNCq9ae3VweBlvg3UUVu8upXzgDR/jF z4S1ZNk1if6V9QEiyBHdE1qMUQeeytedk3qw93CU5snWiXgVRacU8H8Dv+WJPsb4WYAH4MBz aJMI2N/E5XGGYpKFj9vxnEiQ7h83jXxw3Ee2rXCCbhJEci/tUl+Cx40pB3m7nlEdASY+A3tq JLIiG8Argf0+bWaxmuSUihKoakhHQruAylWY9EVtbKg8SACYZhdHCx2+ZSSrxbbAKSv0cDk0 0vQPvgH5GEi6zSB9QvqWCdBH/rL0XfV5jQIDAQABo4ICHTCCAhkwHwYDVR0jBBgwFoAUiYJn fcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFGkahOqOBMk95XAb8dpcRdaef8AYMA4GA1Ud DwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIx AQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzAp BggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCB mjBMoEqgSIZGaHR0cDovL2NybC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRB dXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0 L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYB BQUHAQEEYDBeMDYGCCsGAQUFBzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFD bGllbnRDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNV HREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEB ADcjSJQKgVIfD/IztFrhx2YqR9mKsDs3XakKd4hUoeunHgskiaMIQY2Kcfob48OuzrfY73rN fNoaqr5LZwDeVflMnZd0rPcTA9rAHq5l/qwdSta3k0xvBui0NAtOrSBdbqC4vggLKuZvoR2o 7mSbxSSBZHuVLObx/E5E+D5fjWC7ffNvr9y/uFXeCYFsM+Hc9VPIZ+cAY7JQFJEK/Nuti2QH IIxdR91N2vHuNXWIPROPFMl7y8ltO/fONwhxMcY2dH4JkDH6pdNzMtzykvsO0NeiRHnNlS4K A8aD9RaBR8FNQHq+JusC2tf11qdHBpHrVAK7dHodKDnbRr2t9VdrU2owggY+MIIFJqADAgEC AhEAtlwUjTTxveqQY8soFvBYEjANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJU UlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNV BAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0x MDA4MzAwMDAwMDBaFw0xMTA4MzAyMzU5NTlaMIHkMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3Qg TmV0d29yayAtIFBFUlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENv bmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0G A1UECxMWKGMpMjAwMyBDb21vZG8gTGltaXRlZDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEq MCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtAJ+m9Tgd3li8BgAIRthGtth3YcCbhLPjfAcnDKcEGSr kZqao79Jg2uDW62IOwNCq9ae3VweBlvg3UUVu8upXzgDR/jFz4S1ZNk1if6V9QEiyBHdE1qM UQeeytedk3qw93CU5snWiXgVRacU8H8Dv+WJPsb4WYAH4MBzaJMI2N/E5XGGYpKFj9vxnEiQ 7h83jXxw3Ee2rXCCbhJEci/tUl+Cx40pB3m7nlEdASY+A3tqJLIiG8Argf0+bWaxmuSUihKo akhHQruAylWY9EVtbKg8SACYZhdHCx2+ZSSrxbbAKSv0cDk00vQPvgH5GEi6zSB9QvqWCdBH /rL0XfV5jQIDAQABo4ICHTCCAhkwHwYDVR0jBBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0w HQYDVR0OBBYEFGkahOqOBMk95XAb8dpcRdaef8AYMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMB Af8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEE BAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6 Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0cDovL2Ny bC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVt YWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xp ZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQUF BzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwYB BQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRtyb2JlcnQuY3Jh Z2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBADcjSJQKgVIfD/IztFrhx2Yq R9mKsDs3XakKd4hUoeunHgskiaMIQY2Kcfob48OuzrfY73rNfNoaqr5LZwDeVflMnZd0rPcT A9rAHq5l/qwdSta3k0xvBui0NAtOrSBdbqC4vggLKuZvoR2o7mSbxSSBZHuVLObx/E5E+D5f jWC7ffNvr9y/uFXeCYFsM+Hc9VPIZ+cAY7JQFJEK/Nuti2QHIIxdR91N2vHuNXWIPROPFMl7 y8ltO/fONwhxMcY2dH4JkDH6pdNzMtzykvsO0NeiRHnNlS4KA8aD9RaBR8FNQHq+JusC2tf1 1qdHBpHrVAK7dHodKDnbRr2t9VdrU2oxggRgMIIEXAIBATCBxDCBrjELMAkGA1UEBhMCVVMx CzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVT RVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0 BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIR ALZcFI008b3qkGPLKBbwWBIwCQYFKw4DAhoFAKCCAnAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTAxMTA5MDcwMDQ4WjAjBgkqhkiG9w0BCQQxFgQUoCYH ltHFo9HpTxsgwFUDcCrEg8MwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJV VDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4t VVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQC2XBSNNPG96pBj yygW8FgSMIHXBgsqhkiG9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgT AlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBO ZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIRALZcFI008b3q kGPLKBbwWBIwDQYJKoZIhvcNAQEBBQAEggEAjtJvYvruyuuCQKyXv+/zxSIzb6wZmyPjNqym LVel7YG3Lq2ykkczvZkfgqQRGGzD5y1dP/0jd1JpMhwKqQTwXYY1ujP/f59D66Gz6EPxn7Vt LpTw2pgf0FV/vmZl5fJRit5W4vkuewQkKyrzZ8CyaA46mM+osxV7Wbp2cpOjMxdIrslANWGx ba3Pu7Eds1DlW69nVCnmG4ybHLae2mpJDCLVfWZ7KuJtkdr/rmEFsge9e1jk20elqQmFoh+K 4h2J1fuEbiTjruILrMFWzWyqdir9injsb0zbeTr6Wh7usOpzF9swD6Olcq0R6tbi5JX4dymw 5TIWIYaBNCF3SjTn7gAAAAAAAA== --------------ms000207030501090807050300-- From cabo@tzi.org Mon Nov 8 23:12:11 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B4F63A6807 for ; Mon, 8 Nov 2010 23:12:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vdoz9+Hgb6j0 for ; Mon, 8 Nov 2010 23:12:08 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 8A16E3A6873 for ; Mon, 8 Nov 2010 23:12:00 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id oA96VmYa001817; Tue, 9 Nov 2010 07:31:48 +0100 (CET) Received: from dhcp-67f2.meeting.ietf.org (dhcp-67f2.meeting.ietf.org [130.129.103.242]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 71B53E12; Tue, 9 Nov 2010 07:31:46 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <5F09D220B62F79418461A978CA0921BD04786B32@pslexc01.psl.local> Date: Tue, 9 Nov 2010 14:31:42 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <1C353DAB-3C1B-4282-BB01-DF397A46DABD@tzi.org> References: <5F09D220B62F79418461A978CA0921BD04786B32@pslexc01.psl.local> To: "Mohana Jeyatharan" X-Mailer: Apple Mail (2.1081) Cc: core@ietf.org Subject: Re: [core] Some clarification on CoAP POST/PUT related to caching X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 07:12:12 -0000 Mohana, HTTP only ever allows caching responses. PUT/POST invalidates a cache but never fills the cache from the request = body. What you are proposing appears to be caching a request body. More generally, you seem to be assuming that the proxy can anticipate = what the server will do with the POST. I think it would be useful to flesh out your example a bit more, in = particular with respect to the use case. Gruesse, Carsten From cabo@tzi.org Mon Nov 8 23:12:12 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2CC53A67C2 for ; Mon, 8 Nov 2010 23:12:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fPkCaNln0PFw for ; Mon, 8 Nov 2010 23:12:09 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id A63FA3A67B1 for ; Mon, 8 Nov 2010 23:12:02 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id oA96G0kL027108; Tue, 9 Nov 2010 07:16:00 +0100 (CET) Received: from dhcp-67f2.meeting.ietf.org (dhcp-67f2.meeting.ietf.org [130.129.103.242]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id A79FCE0D; Tue, 9 Nov 2010 07:15:58 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <4CD8E3B3.7040101@nostrum.com> Date: Tue, 9 Nov 2010 14:15:53 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <19B03EA5-7261-4EEE-8633-F562A1ECC60A@tzi.org> References: <4CD8E3B3.7040101@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.1081) Cc: "CORE \(Constrained RESTful Environments\) WG" Subject: Re: [core] Tightening up unknown status code semantics X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 07:12:12 -0000 Very good point, Adam. CoAP uses a base-10-4 number representation, which I will use here (the = second in the three digits only goes from 0 to 3, so we can encode the = whole thing in a byte). Instead of using 6xx codes (240 base 10-10) for CoAP-specific = applications, we might reserve x3x. So the set of CoAP-specific 400-kind codes would be 430, 431, etc. Still works with the HTTP assignments so far: http://www.iana.org/assignments/http-status-codes If somebody really comes up with an HTTP 43x and we want to use that, we = can map it to a CoAP status code. (And we can still use 6xx for something completely foreign to the HTTP = classes, if we want to, or as an extension to the crowded 4xx field.) Gruesse, Carsten From pab@peoplepowerco.com Tue Nov 9 00:06:51 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 310283A693D for ; Tue, 9 Nov 2010 00:06:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0kPRbgzhMQMi for ; Tue, 9 Nov 2010 00:06:49 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id BF2943A688E for ; Tue, 9 Nov 2010 00:06:48 -0800 (PST) Received: by fxm3 with SMTP id 3so721566fxm.31 for ; Tue, 09 Nov 2010 00:07:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.100.9 with SMTP id w9mr1042698fan.12.1289290029129; Tue, 09 Nov 2010 00:07:09 -0800 (PST) Received: by 10.223.100.14 with HTTP; Tue, 9 Nov 2010 00:07:01 -0800 (PST) In-Reply-To: <4CD8B81D.1080607@gridmerge.com> References: <4CD8B81D.1080607@gridmerge.com> Date: Tue, 9 Nov 2010 02:07:01 -0600 Message-ID: From: Peter Bigot To: robert.cragie@gridmerge.com Content-Type: multipart/alternative; boundary=20cf30433e96332d2804949a3a27 Cc: core@ietf.org Subject: Re: [core] Stuffing state in tokens X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 08:06:51 -0000 --20cf30433e96332d2804949a3a27 Content-Type: text/plain; charset=ISO-8859-1 Alright, I'm completely confused. I'm pretty sure neither Carsten nor darco were saying that Token is now supposed to incorporate a MAC for the entire message, which sounds like what you (Robert Cragie) are describing. Great idea to support a message-level MAC, but it should be a different option. >From the original description: In addition to the context provided by including the URI again in delayed responses, we propose adding a "Token" option, which can be included in GET, PUT, POST, DELETE messages, and is echoed back in exactly those cases where the URI is echoed back. The Token allows a recipient of an asynchronous message to relate back to an earlier request and thus can be used as the long-term equivalent of what TID is for a single transaction. The Token option value is a sequence of bytes, which is opaque to the server. we now want to use Token to drag client data on a round trip to the server so that clients doing things like multi-part post don't need to keep track of what they're doing? Furthermore, we want to turn that single header value into a nano-message complete with its own internal MAC so it can be protected independently of the whole message? I swear, I have no idea what we're trying to accomplish here, but Rube Goldberg would be jealous. Peter On Mon, Nov 8, 2010 at 8:55 PM, Robert Cragie wrote: > Hi Peter, > > The point is that it is just an opaque chunk of data returned to the > client. I think too many assumptions are being made about what is being > carried in that data. If it is simply classified as opaque, it could be > anything > > On that basis, protecting the client to/from server messages isn't > sufficient. That will give: > > - the server data origin integrity of the client data > - the client data origin integrity of the server data > > but it won't give is: > > - the client data origin integrity of the client data it itself > produced > > So applying the MAC seems like a good idea to me in certain situations, > although given the opacity of the data, it is integral to the data itself > and therefore may only need to be recommended in the specification, so the > extended length of the field should suffice. > > Robert > > Robert Cragie (Pacific Gas & Electric) > > Gridmerge Ltd. > 89 Greenfield Crescent, > Wakefield, WF4 4WA, UK > +44 1924 910888 > +1 415 513 0064 > http://www.gridmerge.com > > On 08/11/2010 6:12 PM, Peter Bigot wrote: > > When introduced in draft-bormann-coap-misc-05, Token was specifically an > opaque transaction-layer header introduced to eliminate the need to perform > complex comparisons on URI fields to correlate an asynchronous response with > a request. > > What is the motivation for extending this simple concept of a > transaction-layer key interpretable only on the client into a back-door > mechanism to convey meaningful state from client to server outside the > message body, or to transport it to and from the server rather than retain > it on the client? > > If it serves only this correlation role, is there a security aspect that > needs to be addressed (that isn't naturally addressed by protecting the > entire message)? > > Peter > > On Mon, Nov 8, 2010 at 1:39 AM, Eric Rescorla wrote: > >> As a general matter if you're going to have a token that has state in it >> that would be advantageous to someone who has the token to modify >> then you need to protect the token. So, the question then becomes >> how difficult it is for an attacker to generate a new, valid token with >> a different state. >> >> The classic way to generate these tokens (see for instance, >> http://tools.ietf.org/html/draft-rescorla-stateless-tokens-01) is to >> have some payload plus an integrity check (MAC). So you have >> a token composed of: >> >> P || M >> >> Where P is the payload and M is the MAC. >> >> Say that the attacker generates an arbitrary payload P' and then >> generates >> a random MAC M', the chance that the MAC is valid is 2^{-m} where m is the >> length of the MAC. In most cases, a forgery probability of 2^{-64} is >> considered >> the minimum acceptable limit with 2^{-80} being preferred. This implies a >> MAC >> of at least 8-10 bytes. Now, perhaps there is some argument that in this >> case >> the risk of forgery is lower, but I don't see how it's going to be >> acceptable >> at less than a 4 byte (2^{-32} probability) MAC and we only accepted that >> for SRTP because there was an argument that a single forged media sample >> was a low risk. I don't see that that applies here. >> >> -Ekr >> >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> >> > > _______________________________________________ > core mailing listcore@ietf.orghttps://www.ietf.org/mailman/listinfo/core > > --20cf30433e96332d2804949a3a27 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Alright, I'm completely confused.

    I'm pretty sure neither Ca= rsten nor darco were saying that Token is now=20 supposed to incorporate a MAC for the entire message, which sounds like=20 what you (Robert Cragie) are describing.=A0 Great idea to support a message= -level MAC, but=20 it should be a different option.

    From the original description:
    =A0=A0 In addition to the context provided by includ=
ing the URI again in
   delayed responses, we propose adding a "Token" option, which c=
an be
   included in GET, PUT, POST, DELETE messages, and is echoed back in
   exactly those cases where the URI is echoed back.  The Token allows a
   recipient of an asynchronous message to relate back to an earlier
   request and thus can be used as the long-term equivalent of what TID
   is for a single transaction.  The Token option value is a sequence of
   bytes, which is opaque to the server.
    we now want to use Token to d= rag client data on a round trip to the server so that clients doing things = like multi-part post don't need to keep track of what they're doing= ?=A0 Furthermore, we want to turn that single header value into a nano-mess= age complete with its own internal MAC so it can be protected independently= of the whole message?

    I swear, I have no idea what we're trying to accomplish here, but R= ube Goldberg would be jealous.

    Peter

    On Mon, Nov 8, 2010 at 8:55 PM, Robert Cragie <robert.cragie@gridmerge.com&= gt; wrote:
    =20 =20 =20
    Hi Peter,

    The point is that it is just an opaque chunk of data returned to the client. I think too many assumptions are being made about what is being carried in that data. If it is simply classified as opaque, it could be anything

    On that basis, protecting the client to/from server messages isn't sufficient. That will give:
    • the server data origin integrity of the client data
    • the client data origin integrity of the server data
    but it won't give is:
    • the client data origin integrity of the client data it itself produced
    So applying the MAC seems like a good idea to me in certain situations, although given the opacity of the data, it is integral to the data itself and therefore may only need to be recommended in the specification, so the extended length of the field should suffice.

    Robert
    =20

    Robert Cragie (Pacific Gas & Electric)

    Gridmerge Ltd.
    89 Greenfield Crescent,
    Wakefield, WF4 4WA, UK
    +44 1924 910888
    +1 415 513 0064
    http://www.= gridmerge.com


    On 08/11/2010 6:12 PM, Peter Bigot wrote:
    When introduced in draft-bormann-coap-misc-05= , Token was specifically an opaque transaction-layer header introduced to eliminate the need to perform complex comparisons on URI fields to correlate an asynchronous response with a request.

    What is the motivation for extending this simple concept of a transaction-layer key interpretable only on the client into a back-door mechanism to convey meaningful state from client to server outside the message body, or to transport it to and from the server rather than retain it on the client?

    If it serves only this correlation role, is there a security aspect that needs to be addressed (that isn't naturally addressed by protecting the entire message)?

    Peter

    On Mon, Nov 8, 2010 at 1:39 AM, Eric Rescorla <ekr@rtfm.com> wrote:
    As a gene= ral matter if you're going to have a token that has state in it
    that would be advantageous to someone who has the token to modify
    then you need to protect the token. So, the question then becomes
    how difficult it is for an attacker to generate a new, valid token with
    a different state.

    The classic way to generate these tokens (see for instance,
    have some payload plus an integrity check (MAC). So you have
    a token composed of:

    P || M

    Where P is the payload and M is the MAC.

    Say that the attacker generates an arbitrary payload P' and then generates
    a random MAC M', the chance that the MAC is valid is 2^{-m} where m is the
    length of the MAC. In most cases, a forgery probability of 2^{-64} is considered
    the minimum acceptable limit with 2^{-80} being preferred. This implies a MAC
    of at least 8-10 bytes. Now, perhaps there is some argument that in this case
    the risk of forgery is lower, but I don't see how it'= ;s going to be acceptable
    at less than a 4 byte (2^{-32} probability) MAC and we only accepted that
    for SRTP because there was an argument that a single forged media sample
    was a low risk. I don't see that that applies here.

    -Ekr


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


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

    --20cf30433e96332d2804949a3a27-- From pab@peoplepowerco.com Tue Nov 9 00:10:30 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEBD03A693D for ; Tue, 9 Nov 2010 00:10:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d+dbUKml3yCW for ; Tue, 9 Nov 2010 00:10:30 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id AD36F3A6880 for ; Tue, 9 Nov 2010 00:10:29 -0800 (PST) Received: by fxm3 with SMTP id 3so723245fxm.31 for ; Tue, 09 Nov 2010 00:10:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.123.209 with SMTP id q17mr4739845far.126.1289290252266; Tue, 09 Nov 2010 00:10:52 -0800 (PST) Received: by 10.223.100.14 with HTTP; Tue, 9 Nov 2010 00:10:52 -0800 (PST) In-Reply-To: References: <4CD8B81D.1080607@gridmerge.com> Date: Tue, 9 Nov 2010 02:10:52 -0600 Message-ID: From: Peter Bigot To: robert.cragie@gridmerge.com Content-Type: multipart/alternative; boundary=001636c5b2377fade104949a4732 Cc: core@ietf.org Subject: Re: [core] Stuffing state in tokens X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 08:10:30 -0000 --001636c5b2377fade104949a4732 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Nov 9, 2010 at 2:07 AM, Peter Bigot wrote: > I'm pretty sure neither Carsten nor darco were saying that Token is now > supposed to incorporate a MAC for the entire message, which sounds like what > you (Robert Cragie) are describing. Great idea to support a message-level > MAC, but it should be a different option. > OK, sorry, misread---that's not what you were saying. The rest of my point stands. Peter --001636c5b2377fade104949a4732 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Nov 9, 2010 at 2:07 AM, Peter Bigot <pab@peoplepowerco.com> wrot= e:
    I'm pretty sure neither Carsten nor darco were saying that Token is now= =20 supposed to incorporate a MAC for the entire message, which sounds like=20 what you (Robert Cragie) are describing.=A0 Great idea to support a message= -level MAC, but=20 it should be a different option.

    OK, sorry, misrea= d---that's not what you were saying.

    The rest of my point stands= .

    Peter

    --001636c5b2377fade104949a4732-- From matthieu.vial@fr.non.schneider-electric.com Tue Nov 9 00:54:35 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D20F3A69B8; Tue, 9 Nov 2010 00:54:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.178 X-Spam-Level: X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UER1FGD6xMJY; Tue, 9 Nov 2010 00:54:34 -0800 (PST) Received: from mailX02.eud.schneider-electric.com (mailx02.eud.schneider-electric.com [205.167.7.38]) by core3.amsl.com (Postfix) with ESMTP id 05B533A69D8; Tue, 9 Nov 2010 00:54:34 -0800 (PST) Received: from ateui02.Schneider-Electric.com ([10.198.14.10]) by mailX02.eud.schneider-electric.com with ESMTP id 2010110909361538-164213 ; Tue, 9 Nov 2010 09:36:15 +0100 In-Reply-To: <5D2DC44C-8CF2-4461-8C33-9064FFD9EA79@tzi.org> To: Carsten Bormann X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: matthieu.vial@fr.non.schneider-electric.com Date: Tue, 9 Nov 2010 09:54:52 +0100 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on ATEUI02.Schneider-Electric.com/T/SVR/Schneider at 09/11/2010 09:54:53, Itemize by SMTP Server on AXEU2OUT.schneider-electric.com/X/SVR/SEIxtra at 09/11/2010 09:36:15, Serialize by Router on AXEU2OUT.schneider-electric.com/X/SVR/SEIxtra at 09/11/2010 09:36:16 Content-type: multipart/related; Boundary="0__=4EBBFD45DFBDD1548f9e8a93df938690918c4EBBFD45DFBDD154" Cc: core-bounces@ietf.org, core Subject: Re: [core] coap #52 (new): How strict to make POST definition? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 08:54:35 -0000 --0__=4EBBFD45DFBDD1548f9e8a93df938690918c4EBBFD45DFBDD154 Content-type: multipart/alternative; Boundary="1__=4EBBFD45DFBDD1548f9e8a93df938690918c4EBBFD45DFBDD154" --1__=4EBBFD45DFBDD1548f9e8a93df938690918c4EBBFD45DFBDD154 Content-transfer-encoding: quoted-printable Content-type: text/plain; charset=ISO-8859-1 Hi Carsten, >-- a client SHOULD send retransmissions with the same TID it sent the original message with >-- a server SHOULD use TIDs for duplicate detection (lost ACKs) and ac= t on duplicate messages in a way that is appropriate (e.g. it could minimiz= e >its work by caching a response for a while, and it SHOULD use TIDs to implement at-most-once semantics for non-idempotent operations where th= at is >desired). May be the following questions could be clarified too: - how long the server should keep the state ? - what information should be used to detect duplication: (TID) or (TID,= src address)? Do you think that the initial random TID of each client would= suffice to prevent false duplicate detection if we only use (TID)? (TID= , src address) seems more robust. Regards, Matthieu = Carsten Bormann = = Envoy=E9 par : = A core-bounces@ietf robert.cragie@gridmerge.com = .org = cc core = Ob= jet 09/11/2010 01:21 Re: [core] coap #52 (new): How = strict to make POST definition? = = = = = = = On Nov 8, 2010, at 15:23, Robert Cragie wrote: > However, I think the idea of caching the response makes sense if you apply a lifetime to it. Sure, in particular if we don't try to prevent a server from setting th= at lifetime to zero. I agree that the current text (2.2.5) is a bit implicit about the meani= ng of transaction-IDs. What it should say is at least: -- a client SHOULD send retransmissions with the same TID it sent the original message with -- a server SHOULD use TIDs for duplicate detection (lost ACKs) and act= on duplicate messages in a way that is appropriate (e.g. it could minimiz= e its work by caching a response for a while, and it SHOULD use TIDs to implement at-most-once semantics for non-idempotent operations where th= at is desired). The language need not be fuzzy to grant the server some leeway; it coul= d quite explicitly say that a server may choose not to to duplicate detec= tion IF that is appropriate (i.e., for idempotent operations, as well as for= POST (non-idempotent operations) IF the resource semantics do not requi= re at-most-once operation). Gruesse, Carsten _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________ = --1__=4EBBFD45DFBDD1548f9e8a93df938690918c4EBBFD45DFBDD154 Content-transfer-encoding: quoted-printable Content-type: text/html; charset=ISO-8859-1 Content-Disposition: inline

    Hi Carsten,

    >-- a client SHOULD send retransmissions with the same TID it se= nt the original message with
    >-- a server SHOULD use TIDs for duplicate detection (lost ACKs)= and act on duplicate messages in a way that is appropriate  (e.g.= it could minimize >its work by caching a response for a while, and = it SHOULD use TIDs to implement at-most-once semantics for non-idempote= nt operations where that is >desired).

    May be the following questions could be clarified too:
    - how long the server should keep the state ?
    - what information should be used to detect duplication: (TID) or (= TID, src address)? Do you think that the initial random TID of each cli= ent would suffice to prevent false duplicate detection if we only use (= TID)? (TID, src address) seems more robust.

    Regards,
    Matthieu

    3D"InactiveCarsten Bormann <cabo@tzi.org>




    =
            Carsten Bormann <cabo@tzi.org>=
            Envoy=E9 par : core-bounces@ietf.org

            09/11/2010 01:21

    		 =
    3D""
    A
    		3D""
    robert.cragie@gridmerge.com
    3D""
    cc
    		3D""
    core <core@ietf.org>
    3D""
    Objet
    		3D""
    Re: [core] coap #52 (new): How strict to make POST def= inition?
    3D""3D=

    On Nov 8, 2010, at 15:23, Robert Cragie wrote:

    > However, I think the idea of caching the response makes sense if y= ou apply a lifetime to it.

    Sure, in particular if we don't try to prevent a server from setting th= at lifetime to zero.

    I agree that the current text (2.2.5) is a bit implicit about the meani= ng of transaction-IDs.
    What it should say is at least:

    -- a client SHOULD send retransmissions with the same TID it sent the o= riginal message with
    -- a server SHOULD use TIDs for duplicate detection (lost ACKs) and act= on duplicate messages in a way that is appropriate  (e.g. it coul= d minimize its work by caching a response for a while, and it SHOULD us= e TIDs to implement at-most-once semantics for non-idempotent operation= s where that is desired).

    The language need not be fuzzy to grant the server some leeway; it coul= d quite explicitly say that a server may choose not to to duplicate det= ection IF that is appropriate (i.e., for idempotent operations, as well= as for POST (non-idempotent operations) IF the resource semantics do n= ot require at-most-once operation).

    Gruesse, Carsten

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

    ______________________________________________________________________<= br> This email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________<= br>
    = --1__=4EBBFD45DFBDD1548f9e8a93df938690918c4EBBFD45DFBDD154-- --0__=4EBBFD45DFBDD1548f9e8a93df938690918c4EBBFD45DFBDD154 Content-type: image/gif; name="pic16512.gif" Content-Disposition: inline; filename="pic16512.gif" Content-ID: <1__=4EBBFD45DFBDD1548@Schneider-Electric.com> Content-Transfer-Encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --0__=4EBBFD45DFBDD1548f9e8a93df938690918c4EBBFD45DFBDD154-- From klaus.hartke@googlemail.com Tue Nov 9 01:50:53 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AABB28C108 for ; Tue, 9 Nov 2010 01:50:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IyHsiTdcEp+F for ; Tue, 9 Nov 2010 01:50:52 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id B1FA33A6924 for ; Tue, 9 Nov 2010 01:50:51 -0800 (PST) Received: by bwz12 with SMTP id 12so6275886bwz.31 for ; Tue, 09 Nov 2010 01:51:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=h6xiGTk95wBDWhtzqD11FRHk4kpSkBQtPW6g5/dDnUk=; b=ksMC7ktRx8V0M0Ja9/OTFLBaIqsevRjYLIXjK1asoas7ckWWA0HZ/HN50W6oqVh6SN CElVkTNegsqqDQcTswzBmZKTjlaWjHSnc9d0UTS83Zw4bMNI2Zsa5EUCWI+GWvN/PBbl ZxtSOhDtC+8mE0rcSh25j5/ElTK5FYzC37mkw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=CYVPtHkTTRYtvYKw78ERIq2UxJKr9XR4Vk7OHfS9G81JCLkXlfxrW5yg4dpCej4A9B pgFi+tmzPgWtLN5k/vOBQYKDy+j90/IgI6bttqZ3l03FyOUuJEiAn9ZUcJKXJJaLlbmn 7Zdu4xBGN/2hR1r3gT890JX1Z+3LoUy1QwiUI= MIME-Version: 1.0 Received: by 10.204.127.94 with SMTP id f30mr6109872bks.1.1289296273273; Tue, 09 Nov 2010 01:51:13 -0800 (PST) Sender: klaus.hartke@googlemail.com Received: by 10.204.121.134 with HTTP; Tue, 9 Nov 2010 01:51:13 -0800 (PST) In-Reply-To: <5F09D220B62F79418461A978CA0921BD04786B4F@pslexc01.psl.local> References: <5F09D220B62F79418461A978CA0921BD04786B32@pslexc01.psl.local> <1C353DAB-3C1B-4282-BB01-DF397A46DABD@tzi.org> <5F09D220B62F79418461A978CA0921BD04786B4F@pslexc01.psl.local> Date: Tue, 9 Nov 2010 10:51:13 +0100 X-Google-Sender-Auth: ky8H5A_3SqcoorTDp-P3-LcWyEg Message-ID: From: Klaus Hartke To: core@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [core] Some clarification on CoAP POST/PUT related to caching X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 09:50:53 -0000 Mohana Jeyatharan wrote: > I was thinking if the server is in sleep state, then when the client > does a POST, the proxy can cache this information and send it to server > when it wakes up. I think you're talking about a gateway here, not a proxy [1]. If a gateway (a.k.a. "big brother" in some cases) knows the sleep schedule of a server, it's definitely possible that it processes a POST request on behalf of the sleeping server, and synchronises with the server as soon as it wakes up. For example, if the POST request means something like "append" in the context of the specific resource, then the gateway could collect all such requests into a single request and forward that to the server when it wakes up. I wouldn't call this "caching" though, because it happens at the application layer, not the CoAP layer. The gateway needs to understand the application-specific semantics of the request to be able to handle the request in a meaningful way. I don't think we should add a store-and-forward mechanism to CoAP as found in Message Queues. Klaus [1] http://www.ietf.org/mail-archive/web/core/current/msg00862.html From pab@peoplepowerco.com Tue Nov 9 02:43:01 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 661343A695F for ; Tue, 9 Nov 2010 02:43:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29xh1hXYBTYd for ; Tue, 9 Nov 2010 02:43:00 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 5443A28C110 for ; Tue, 9 Nov 2010 02:42:59 -0800 (PST) Received: by fxm3 with SMTP id 3so799647fxm.31 for ; Tue, 09 Nov 2010 02:43:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.101.194 with SMTP id d2mr4966832fao.88.1289299402139; Tue, 09 Nov 2010 02:43:22 -0800 (PST) Received: by 10.223.100.14 with HTTP; Tue, 9 Nov 2010 02:43:22 -0800 (PST) Date: Tue, 9 Nov 2010 04:43:22 -0600 Message-ID: From: Peter Bigot To: core Content-Type: multipart/alternative; boundary=20cf3054a4addfa77b04949c6815 Subject: [core] Symmetry, or Stuffing state in etag X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 10:43:01 -0000 --20cf3054a4addfa77b04949c6815 Content-Type: text/plain; charset=ISO-8859-1 Let's try it this way: Token is an opaque sequence introduced by a client to correlate a response with a previous request. Etag is an opaque sequence introduced by a server to correlate a request with (the content in) a previous response. A client may choose to embed information in a request Token, and extract that information when a response Token is received. To accommodate this use, Token must be large enough to hold this embedded information as well as a MAC to ensure the information is valid. Use case: the client is transferring a large block of memory to a server. It uses the Token to encode the address of the next block to transfer. When it receives the response, it decodes the Token value to determine how much data to send from what address. A server may choose to embed information in a response Etag, and extract that information when a subsequent request provides an Etag. To accommodate this use, Etag must be large enough to hold this embedded information as well as a MAC to ensure the information is valid. Use case: the server wishes to track how information it provides is distributed. Upon a request with no Etag, the server creates a data structure holding information about the client. It embeds the address of this data structure in the Etag. When it receives a request with an Etag, it dereferences the pointer to see whether this client is in the list of "friends" who have shared data with the original requester. Either use case could be easily accommodated by using the value as a small opaque key to identify locally stored (protected) information that never goes out in a message, avoiding the whole problem, but that's not the point here. The situations are symmetric, and should be handled the same way. That historically the draft says an end-point (including the server?) MUST make no assumptions about the format of an Etag value, but did not use the same language for Token, is an uncompelling reason to treat them differently. Peter --20cf3054a4addfa77b04949c6815 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Let's try it this way:

    Token is an opaque sequence introduced by= a client to correlate a response with a previous request.

    Etag is a= n opaque sequence introduced by a server to correlate a request with (the c= ontent in) a previous response.

    A client may choose to embed information in a request Token, and extrac= t that information when a response Token is received.=A0 To accommodate thi= s use, Token must be large enough to hold this embedded information as well= as a MAC to ensure the information is valid.

    Use case: the client is transferring = a large block of memory to a server.=A0 It uses the Token to encode the add= ress of the next block to transfer.=A0 When it receives the response, it de= codes the Token value to determine how much data to send from what address.=

    A server may choose to embed information in a response Etag, and = extract that information when a subsequent request provides an Etag.=A0 To = accommodate this use, Etag must be large enough to hold this embedded infor= mation as well as a MAC to ensure the information is valid.

    Use case: the server wishes to track = how information it provides is distributed.=A0 Upon a request with no Etag,= the server creates a data structure holding information about the client.= =A0 It embeds the address of this data structure in the Etag.=A0 When it re= ceives a request with an Etag, it dereferences the pointer to see whether t= his client is in the list of "friends" who have shared data with = the original requester.

    Either use case could be easily accommodated by using the value a= s a small=20 opaque key to identify locally stored (protected) information that never go= es out in a message, avoiding the whole problem, but that's not the poi= nt here.=A0 The situations are symmetric, and should be handled the same wa= y.=A0 That historically the draft says an end-point (including the server?)= MUST make no assumptions about the format of an Etag value, but did not us= e the same language for Token, is an uncompelling reason to treat them diff= erently.

    Peter
    --20cf3054a4addfa77b04949c6815-- From robert.cragie@gridmerge.com Tue Nov 9 02:53:26 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB1073A68BF for ; Tue, 9 Nov 2010 02:53:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.918 X-Spam-Level: X-Spam-Status: No, score=-2.918 tagged_above=-999 required=5 tests=[AWL=-0.560, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kiK0qjWGguS6 for ; Tue, 9 Nov 2010 02:53:25 -0800 (PST) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id E21C228C0F4 for ; Tue, 9 Nov 2010 02:53:22 -0800 (PST) Received: from client-86-29-103-19.glfd.adsl.virginmedia.com ([86.29.103.19] helo=[192.168.1.80]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) id 1PFlpf-0004Xq-3H; Tue, 09 Nov 2010 10:53:43 +0000 Message-ID: <4CD92834.5050600@gridmerge.com> Date: Tue, 09 Nov 2010 10:53:40 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Peter Bigot References: <4CD8B81D.1080607@gridmerge.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030708050300040400020102" Cc: core@ietf.org Subject: Re: [core] Stuffing state in tokens X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 10:53:26 -0000 This is a cryptographically signed message in MIME format. --------------ms030708050300040400020102 Content-Type: multipart/alternative; boundary="------------030601080209070309060201" This is a multi-part message in MIME format. --------------030601080209070309060201 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Peter, Comments inline, bracketed by Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com On 09/11/2010 8:07 AM, Peter Bigot wrote: > Alright, I'm completely confused. > > I'm pretty sure neither Carsten nor darco were saying that Token is=20 > now supposed to incorporate a MAC for the entire message, which sounds = > like what you (Robert Cragie) are describing. Great idea to support a = > message-level MAC, but it should be a different option. That's not what I was describing but you realise that in your later = e-mail. > > From the original description: > In addition to the context provided by including the URI again in > delayed responses, we propose adding a "Token" option, which can be= > included in GET, PUT, POST, DELETE messages, and is echoed back in > exactly those cases where the URI is echoed back. The Token allows= a > recipient of an asynchronous message to relate back to an earlier > request and thus can be used as the long-term equivalent of what TI= D > is for a single transaction. The Token option value is a sequence = of > bytes, which is opaque to the server. > we now want to use Token to drag client data on a round trip to the=20 > server so that clients doing things like multi-part post don't need to = > keep track of what they're doing? Furthermore, we want to turn that=20 > single header value into a nano-message complete with its own internal = > MAC so it can be protected independently of the whole message? But that's what a token is. If it is an opaque sequence of bytes,=20 it could carry my pet dog's name, for all the server cares. If the=20 client has short term partial memory loss, it would ike to know that=20 what the server echoes back is indeed what it sent out in the first=20 place. The point is securing the original client message and the=20 returning server message individually does not achieve that. I am not=20 saying that you must add a MAC but that it is recommended in certain=20 cases and therefore the length should be able to accommodate it. I don't = see many changes to the draft arising from this. > > I swear, I have no idea what we're trying to accomplish here, but Rube = > Goldberg would be jealous. > > Peter > > On Mon, Nov 8, 2010 at 8:55 PM, Robert Cragie=20 > > wrot= e: > > Hi Peter, > > The point is that it is just an opaque chunk of data returned to > the client. I think too many assumptions are being made about what > is being carried in that data. If it is simply classified as > opaque, it could be anything > > On that basis, protecting the client to/from server messages isn't > sufficient. That will give: > > * the server data origin integrity of the client data > * the client data origin integrity of the server data > > but it won't give is: > > * the client data origin integrity of the client data it > itself produced > > So applying the MAC seems like a good idea to me in certain > situations, although given the opacity of the data, it is integral > to the data itself and therefore may only need to be recommended > in the specification, so the extended length of the field should > suffice. > > Robert > > Robert Cragie (Pacific Gas & Electric) > > Gridmerge Ltd. > 89 Greenfield Crescent, > Wakefield, WF4 4WA, UK > +44 1924 910888 > +1 415 513 0064 > http://www.gridmerge.com > > > On 08/11/2010 6:12 PM, Peter Bigot wrote: >> When introduced in draft-bormann-coap-misc-05, Token was >> specifically an opaque transaction-layer header introduced to >> eliminate the need to perform complex comparisons on URI fields >> to correlate an asynchronous response with a request. >> >> What is the motivation for extending this simple concept of a >> transaction-layer key interpretable only on the client into a >> back-door mechanism to convey meaningful state from client to >> server outside the message body, or to transport it to and from >> the server rather than retain it on the client? >> >> If it serves only this correlation role, is there a security >> aspect that needs to be addressed (that isn't naturally addressed >> by protecting the entire message)? >> >> Peter >> >> On Mon, Nov 8, 2010 at 1:39 AM, Eric Rescorla > > wrote: >> >> As a general matter if you're going to have a token that has >> state in it >> that would be advantageous to someone who has the token to mod= ify >> then you need to protect the token. So, the question then beco= mes >> how difficult it is for an attacker to generate a new, valid >> token with >> a different state. >> >> The classic way to generate these tokens (see for instance, >> http://tools.ietf.org/html/draft-rescorla-stateless-tokens-01)= is >> to >> have some payload plus an integrity check (MAC). So you have >> a token composed of: >> >> P || M >> >> Where P is the payload and M is the MAC. >> >> Say that the attacker generates an arbitrary payload P' and >> then generates >> a random MAC M', the chance that the MAC is valid is 2^{-m} >> where m is the >> length of the MAC. In most cases, a forgery probability of >> 2^{-64} is considered >> the minimum acceptable limit with 2^{-80} being preferred. >> This implies a MAC >> of at least 8-10 bytes. Now, perhaps there is some argument >> that in this case >> the risk of forgery is lower, but I don't see how it's going >> to be acceptable >> at less than a 4 byte (2^{-32} probability) MAC and we only >> accepted that >> for SRTP because there was an argument that a single forged >> media sample >> was a low risk. I don't see that that applies here. >> >> -Ekr >> >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> >> >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core > > --------------030601080209070309060201 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Peter,

    Comments inline, bracketed by <RCC></RCC>

    Robert

    Robert Cragie (Pacific Gas & Electric)

    Gridmerge Ltd.
    89 Greenfield Crescent,
    Wakefield, WF4 4WA, UK
    +44 1924 910888
    +1 415 513 0064
    http://www.gridmerge.com


    On 09/11/2010 8:07 AM, Peter Bigot wrote:
    Alright, I'm completely confused.

    I'm pretty sure neither Carsten nor darco were saying that Token is now supposed to incorporate a MAC for the entire message, which sounds like what you (Robert Cragie) are describing.  Great id= ea to support a message-level MAC, but it should be a different option.
    <RCC>That's not what I was describing but you realise that in your later e-mail.</RCC>

    From the original description:
       In addition to the context prov=
ided by including the URI again in
   delayed responses, we propose adding a "Token" option, which can be
   included in GET, PUT, POST, DELETE messages, and is echoed back in
   exactly those cases where the URI is echoed back.  The Token allows a
   recipient of an asynchronous message to relate back to an earlier
   request and thus can be used as the long-term equivalent of what TID
   is for a single transaction.  The Token option value is a sequence of
   bytes, which is opaque to the server.
    we now want to use Token to drag client data on a round trip to the server so that clients doing things like multi-part post don't need to keep track of what they're doing?  Furthermore, we wan= t to turn that single header value into a nano-message complete with its own internal MAC so it can be protected independently of the whole message?
    <RCC>But that's what a token is. If it is an opaque sequence of bytes, it could carry my pet dog's name, for all the server cares. If the client has short term partial memory loss, it would ike to know that what the server echoes back is indeed what it sent out in the first place. The point is securing the original client message and the returning server message individually does not achieve that. I am not saying that you must add a MAC but that it is recommended in certain cases and therefore the length should be able to accommodate it. I don't see many changes to the draft arising from this.</RCC>

    I swear, I have no idea what we're trying to accomplish here, but Rube Goldberg would be jealous.

    Peter

    On Mon, Nov 8, 2010 at 8:55 PM, Robert Cragie <robert.cragie@gri= dmerge.com> wrote:
    Hi Peter,

    The point is that it is just an opaque chunk of data returned to the client. I think too many assumptions are being made about what is being carried in that data. If it is simply classified as opaque, it could be anything

    On that basis, protecting the client to/from server messages isn't sufficient. That will give:
    • the server data origin integrity of the client data
      =
    • the client data origin integrity of the server data
    but it won't give is:
    • the client data origin integrity of the client data it itself produced
    So applying the MAC seems like a good idea to me in certain situations, although given the opacity of the data, it is integral to the data itself and therefore may only need to be recommended in the specification, so the extended length of the field should suffice.

    Robert

    Robert Cragie (Pacific Gas & Electric)

    Gridmerge Ltd.
    89 Greenfield Crescent,
    Wakefield, WF4 4WA, UK
    +44 1924 910888
    +1 415 513 0064
    ht= tp://www.gridmerge.com


    On 08/11/2010 6:12 PM, Peter Bigot wrote:
    When introduced in draft-bormann-coap-misc-05, Token was specifically an opaque transaction-layer header introduced to eliminate the need to perform complex comparisons on URI fields to correlate an asynchronous response with a request.

    What is the motivation for extending this simple concept of a transaction-layer key interpretable only on the client into a back-door mechanism to convey meaningful state from client to server outside the message body, or to transport it to and from the server rather than retain it on the client?

    If it serves only this correlation role, is there a security aspect that needs to be addressed (that isn't naturally addressed by protecting the entire message)?<= br>
    Peter

    On Mon, Nov 8, 2010 at 1:39 AM, Eric Rescorla <ek= r@rtfm.com> wrote:
    As a general matter if you're going to have a token that has state in it
    that would be advantageous to someone who has the token to modify
    then you need to protect the token. So, the question then becomes
    how difficult it is for an attacker to generate a new, valid token with
    a different state.

    The classic way to generate these tokens (see for instance,
    have some payload plus an integrity check (MAC). So you have
    a token composed of:

    P || M

    Where P is the payload and M is the MAC.
    =

    Say that the attacker generates an arbitrary payload P' and then generates
    a random MAC M', the chance that the MAC is valid is 2^{-m} where m is the
    length of the MAC. In most cases, a forgery probability of 2^{-64} is considered
    the minimum acceptable limit with 2^{-80} being preferred. This implies a MAC
    of at least 8-10 bytes. Now, perhaps there is some argument that in this case
    the risk of forgery is lower, but I don't see how it's going to be acceptable
    at less than a 4 byte (2^{-32} probability) MAC and we only accepted that
    for SRTP because there was an argument that a single forged media sample
    was a low risk. I don't see that that applies here.

    -Ekr


    _______________________________________________
    = core mailing list
    c= ore@ietf.org
    https://www.ietf.org/mailman/li= stinfo/core


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

    --------------030601080209070309060201-- --------------ms030708050300040400020102 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRZTCC BN0wggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UE BhMCR0IxGzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEa MBgGA1UECgwRQ29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJV UzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUg VVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWls MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5 ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqk kqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWL eeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJ Q/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udl y/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0jBBgwFoAUoBEKIz6W8Qfs 4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQE AwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAR BgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5jb21vZG9j YS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwuY29t b2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvz bRx8NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12 jMOCAU9sAPMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxog L5dMUbtGB8SKN04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNB pEMD9O3vMyfbOeAUTibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mY HK9/FX8wggY+MIIFJqADAgECAhEAtlwUjTTxveqQY8soFvBYEjANBgkqhkiG9w0BAQUFADCB rjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEe MBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVz ZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIGFuZCBFbWFpbDAeFw0xMDA4MzAwMDAwMDBaFw0xMTA4MzAyMzU5NTlaMIHkMTUwMwYD VQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBFUlNPTkEgTk9UIFZBTElEQVRFRDFGMEQG A1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5u ZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMyBDb21vZG8gTGltaXRlZDEWMBQGA1UE AxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVy Z2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtAJ+m9Tgd3li8BgAIRth Gtth3YcCbhLPjfAcnDKcEGSrkZqao79Jg2uDW62IOwNCq9ae3VweBlvg3UUVu8upXzgDR/jF z4S1ZNk1if6V9QEiyBHdE1qMUQeeytedk3qw93CU5snWiXgVRacU8H8Dv+WJPsb4WYAH4MBz aJMI2N/E5XGGYpKFj9vxnEiQ7h83jXxw3Ee2rXCCbhJEci/tUl+Cx40pB3m7nlEdASY+A3tq JLIiG8Argf0+bWaxmuSUihKoakhHQruAylWY9EVtbKg8SACYZhdHCx2+ZSSrxbbAKSv0cDk0 0vQPvgH5GEi6zSB9QvqWCdBH/rL0XfV5jQIDAQABo4ICHTCCAhkwHwYDVR0jBBgwFoAUiYJn fcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFGkahOqOBMk95XAb8dpcRdaef8AYMA4GA1Ud DwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIx AQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzAp BggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCB mjBMoEqgSIZGaHR0cDovL2NybC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRB dXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0 L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYB BQUHAQEEYDBeMDYGCCsGAQUFBzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFD bGllbnRDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNV HREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEB ADcjSJQKgVIfD/IztFrhx2YqR9mKsDs3XakKd4hUoeunHgskiaMIQY2Kcfob48OuzrfY73rN fNoaqr5LZwDeVflMnZd0rPcTA9rAHq5l/qwdSta3k0xvBui0NAtOrSBdbqC4vggLKuZvoR2o 7mSbxSSBZHuVLObx/E5E+D5fjWC7ffNvr9y/uFXeCYFsM+Hc9VPIZ+cAY7JQFJEK/Nuti2QH IIxdR91N2vHuNXWIPROPFMl7y8ltO/fONwhxMcY2dH4JkDH6pdNzMtzykvsO0NeiRHnNlS4K A8aD9RaBR8FNQHq+JusC2tf11qdHBpHrVAK7dHodKDnbRr2t9VdrU2owggY+MIIFJqADAgEC AhEAtlwUjTTxveqQY8soFvBYEjANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJU UlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNV BAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0x MDA4MzAwMDAwMDBaFw0xMTA4MzAyMzU5NTlaMIHkMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3Qg TmV0d29yayAtIFBFUlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENv bmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0G A1UECxMWKGMpMjAwMyBDb21vZG8gTGltaXRlZDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEq MCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtAJ+m9Tgd3li8BgAIRthGtth3YcCbhLPjfAcnDKcEGSr kZqao79Jg2uDW62IOwNCq9ae3VweBlvg3UUVu8upXzgDR/jFz4S1ZNk1if6V9QEiyBHdE1qM UQeeytedk3qw93CU5snWiXgVRacU8H8Dv+WJPsb4WYAH4MBzaJMI2N/E5XGGYpKFj9vxnEiQ 7h83jXxw3Ee2rXCCbhJEci/tUl+Cx40pB3m7nlEdASY+A3tqJLIiG8Argf0+bWaxmuSUihKo akhHQruAylWY9EVtbKg8SACYZhdHCx2+ZSSrxbbAKSv0cDk00vQPvgH5GEi6zSB9QvqWCdBH /rL0XfV5jQIDAQABo4ICHTCCAhkwHwYDVR0jBBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0w HQYDVR0OBBYEFGkahOqOBMk95XAb8dpcRdaef8AYMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMB Af8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEE BAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6 Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0cDovL2Ny bC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVt YWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xp ZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQUF BzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwYB BQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRtyb2JlcnQuY3Jh Z2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBADcjSJQKgVIfD/IztFrhx2Yq R9mKsDs3XakKd4hUoeunHgskiaMIQY2Kcfob48OuzrfY73rNfNoaqr5LZwDeVflMnZd0rPcT A9rAHq5l/qwdSta3k0xvBui0NAtOrSBdbqC4vggLKuZvoR2o7mSbxSSBZHuVLObx/E5E+D5f jWC7ffNvr9y/uFXeCYFsM+Hc9VPIZ+cAY7JQFJEK/Nuti2QHIIxdR91N2vHuNXWIPROPFMl7 y8ltO/fONwhxMcY2dH4JkDH6pdNzMtzykvsO0NeiRHnNlS4KA8aD9RaBR8FNQHq+JusC2tf1 1qdHBpHrVAK7dHodKDnbRr2t9VdrU2oxggRgMIIEXAIBATCBxDCBrjELMAkGA1UEBhMCVVMx CzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVT RVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0 BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIR ALZcFI008b3qkGPLKBbwWBIwCQYFKw4DAhoFAKCCAnAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTAxMTA5MTA1MzQwWjAjBgkqhkiG9w0BCQQxFgQUKaGP S9rPjvYXx1D1DhE22wgZq9UwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJV VDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4t VVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQC2XBSNNPG96pBj yygW8FgSMIHXBgsqhkiG9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgT AlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBO ZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIRALZcFI008b3q kGPLKBbwWBIwDQYJKoZIhvcNAQEBBQAEggEAiN/vcPpehCkTB3/71rJh+1cpqb1L2bze9aKN 5hBwpfvaZ5IsH5WmfodOU6qBGXVj6L+ynEE9q9H32kVFSEWrbvWqVYfGiA7GDMJslPqtbSE5 w630VlpXwhbItatmYo6p827Q3oRwi7OCgQjehSCZVURa6zuvXbhSxg0NsGJFjlMwZs/NW8bA BAZHwigRft8MAYc89q/jZs6NVnBVt46qVfUhP7enJ4XAz/4+QGvv00dT1JMa8WFvi+MsXipU pFpLe1sCzN+oIya/y73VBLdAomOzUpzXwSAg5TqiKKxKDIaRfHrwN3MytJMKFErLPYw7IOr6 +8RgmMmxTiNanR7l6gAAAAAAAA== --------------ms030708050300040400020102-- From ekr@rtfm.com Tue Nov 9 06:57:21 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 000243A69BE for ; Tue, 9 Nov 2010 06:57:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.766 X-Spam-Level: X-Spam-Status: No, score=-101.766 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qMvy3KyEmpdN for ; Tue, 9 Nov 2010 06:57:19 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id A20223A681F for ; Tue, 9 Nov 2010 06:57:19 -0800 (PST) Received: by gya6 with SMTP id 6so4651903gya.31 for ; Tue, 09 Nov 2010 06:57:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.90.2.23 with SMTP id 23mr7180466agb.97.1289314662379; Tue, 09 Nov 2010 06:57:42 -0800 (PST) Received: by 10.91.78.6 with HTTP; Tue, 9 Nov 2010 06:57:40 -0800 (PST) In-Reply-To: References: Date: Tue, 9 Nov 2010 06:57:40 -0800 Message-ID: From: Eric Rescorla To: Peter Bigot Content-Type: multipart/alternative; boundary=00163631086b7470bd04949ff693 Cc: core Subject: Re: [core] Symmetry, or Stuffing state in etag X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 14:57:21 -0000 --00163631086b7470bd04949ff693 Content-Type: text/plain; charset=ISO-8859-1 I don't think this is a very useful analogy. We're deliberately contemplating the use of tokens as a form of state transfer from one side to another. If we're doing so, we need to address the security issue. By contrast, Etags are intended purely as a check for whether two versions of a resource match and are not intended to be interpreted. If someone *did* decide to use them the way you suggest, then they of course would need to add security features. However, since this is not the intended use of etags, the situation is different. -Ekr On Tue, Nov 9, 2010 at 2:43 AM, Peter Bigot wrote: > Let's try it this way: > > Token is an opaque sequence introduced by a client to correlate a response > with a previous request. > > Etag is an opaque sequence introduced by a server to correlate a request > with (the content in) a previous response. > > A client may choose to embed information in a request Token, and extract > that information when a response Token is received. To accommodate this > use, Token must be large enough to hold this embedded information as well as > a MAC to ensure the information is valid. > > Use case: the client is transferring a large block of memory to a server. > It uses the Token to encode the address of the next block to transfer. When > it receives the response, it decodes the Token value to determine how much > data to send from what address. > > A server may choose to embed information in a response Etag, and extract > that information when a subsequent request provides an Etag. To accommodate > this use, Etag must be large enough to hold this embedded information as > well as a MAC to ensure the information is valid. > > Use case: the server wishes to track how information it provides is > distributed. Upon a request with no Etag, the server creates a data > structure holding information about the client. It embeds the address of > this data structure in the Etag. When it receives a request with an Etag, > it dereferences the pointer to see whether this client is in the list of > "friends" who have shared data with the original requester. > > Either use case could be easily accommodated by using the value as a small > opaque key to identify locally stored (protected) information that never > goes out in a message, avoiding the whole problem, but that's not the point > here. The situations are symmetric, and should be handled the same way. > That historically the draft says an end-point (including the server?) MUST > make no assumptions about the format of an Etag value, but did not use the > same language for Token, is an uncompelling reason to treat them > differently. > > Peter > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > --00163631086b7470bd04949ff693 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I don't think this is a very useful analogy. We're deliberately con= templating the use of tokens as a
    form of state transfer from one side = to another. If we're doing so, we need to address the security
    issue. By contrast, Etags are intended purely as a check for whether t= wo versions of a resource
    match and are not intended to be interp= reted. If someone *did* decide to use them the way you
    suggest, t= hen they of course would need to add security features. However, since this= is not
    the intended use of etags, the situation is different.
    =
    -Ekr

    On Tue, Nov 9, 2010 at 2:43 AM, Peter Bigot <pab@peoplepowerco.com>= wrote:
    Let's try it this way:

    Token is = an opaque sequence introduced by a client to correlate a response with a pr= evious request.

    Etag is an opaque sequence introduced by a server to correlate a reques= t with (the content in) a previous response.

    A client may choose to embed information in a request Token, and extrac= t that information when a response Token is received.=A0 To accommodate thi= s use, Token must be large enough to hold this embedded information as well= as a MAC to ensure the information is valid.

    Use case: the client is transferring a = large block of memory to a server.=A0 It uses the Token to encode the addre= ss of the next block to transfer.=A0 When it receives the response, it deco= des the Token value to determine how much data to send from what address.

    A server may choose to embed information in a response Etag, and = extract that information when a subsequent request provides an Etag.=A0 To = accommodate this use, Etag must be large enough to hold this embedded infor= mation as well as a MAC to ensure the information is valid.

    Use case: the server wishes to track ho= w information it provides is distributed.=A0 Upon a request with no Etag, t= he server creates a data structure holding information about the client.=A0= It embeds the address of this data structure in the Etag.=A0 When it recei= ves a request with an Etag, it dereferences the pointer to see whether this= client is in the list of "friends" who have shared data with the= original requester.

    Either use case could be easily accommodated by using the value a= s a small=20 opaque key to identify locally stored (protected) information that never go= es out in a message, avoiding the whole problem, but that's not the poi= nt here.=A0 The situations are symmetric, and should be handled the same wa= y.=A0 That historically the draft says an end-point (including the server?)= MUST make no assumptions about the format of an Etag value, but did not us= e the same language for Token, is an uncompelling reason to treat them diff= erently.

    Peter

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


    --00163631086b7470bd04949ff693-- From hvdsomp@gmail.com Tue Nov 9 07:00:09 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B101028C0F4 for ; Tue, 9 Nov 2010 07:00:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3XeA5TdW6+oT for ; Tue, 9 Nov 2010 07:00:08 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 329293A6A04 for ; Tue, 9 Nov 2010 07:00:08 -0800 (PST) Received: by vws3 with SMTP id 3so3467471vws.31 for ; Tue, 09 Nov 2010 07:00:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=Sqauh+bAEXsV/C0gR1hzgR0HM/IiWKuEJkBdmafR0fM=; b=sWLnAqgrMhWMdhDaiC01rdJcIOPzuh78jbDlkL75vqChwV5+6Lo5c5R/m0QUDNwJ6v ZXP++psNUJloExiJbHq4Tr8JuuKJwpo3zFwd61lSu0HPgK5oiUv1cDVfHpSvc7Lyyfa7 5cljKYfTDwJb3/EfhDLi8DBRpmvuQbS4hLRFI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=CiEAlT0W6Q/qs4CD1n+eVCFiQRpEH5lYChG3f2n1rxbUXbR6NRnKgNOSp/Az7s/Qfs wrV50NU/QJsrV2cSlYTbheyBsM3+SXPZDANj0tvn3NljxN1S1+M5gsxXeOKu1ZUClcUq dpYKVON9kUVaItZdEREF2ClgpFPl2Ak7q7L/w= MIME-Version: 1.0 Received: by 10.224.137.75 with SMTP id v11mr5322200qat.244.1289314831991; Tue, 09 Nov 2010 07:00:31 -0800 (PST) Received: by 10.229.13.133 with HTTP; Tue, 9 Nov 2010 07:00:31 -0800 (PST) Date: Tue, 9 Nov 2010 08:00:31 -0700 Message-ID: From: Herbert van de Sompel To: core@ietf.org Content-Type: multipart/alternative; boundary=0022152d66d59086430494a00066 Subject: [core] Memento TimeMaps, again X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 15:00:09 -0000 --0022152d66d59086430494a00066 Content-Type: text/plain; charset=ISO-8859-1 Hi again, Since there have been some problems with the link to a TimeMap I sent in yesterday's mail, I have posted a TimeMap at a URI that should not cause confusion: http://dl.dropbox.com/u/2114080/ugent_timemap.txt TimeMaps are introduced in the Memento framework (http://mementoweb.org) and are formatted according to the link-value construction rule of the BNF of RFC 5988. I would like to repeat the questions I posted yesterday: We are currently finalizing the first version of an Internet Draft for Memento, and we are in need of a special-purpose MIME type as the text/csv that we currently use is inaccurate. In that context, I was wondering about the following: (1) Is it appropriate for us to use "application/link-format" for our TimeMaps? Note that our TimeMaps strictly adhere to the link-value construction rule of RFC 5988, i.e. we are not using any of the extensions that you propose. (2) Why the path was chosen to define extensions as part of the basic "application/link-format" MIME type, i.e. why is "application/link-format" not introduced to identify documents strictly formatted according to RFC 5988's link-value rule, and why are extensions not handled like, for example, in XML, e.g. " application/core+link-format"? My apologies for the confusion caused by yesterday's link. I am looking forward to your feedback. Greetings Herbert Van de Sompel -- Herbert Van de Sompel Digital Library Research & Prototyping Los Alamos National Laboratory, Research Library http://public.lanl.gov/herbertv/ == --0022152d66d59086430494a00066 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    Hi a= gain,

    Since there have been some problems with the link to a TimeMap = I sent in yesterday's mail, I have posted a TimeMap at a URI that shoul= d not cause confusion:

    TimeMaps are introduced in the Memento framework = (http://mementoweb.org) and are forma= tted according to the link-value construction rule of the BNF of RFC 5988.= =A0

    I woul= d like to repeat the questions I posted yesterday:

    We are currently f= inalizing the first version of an Internet Draft for Memento, and we are in= need of a special-purpose MIME type as the text/csv that we currently use = is inaccurate. In that context,=A0I was wondering about the following:

    (1) Is= it appropriate for us to use "application/link-format" for our TimeMaps= ? Note that our TimeMaps strictly adhere to the link-value construction rule of RFC 5988, i.e. we are not using any= of the extensions that you propose.

    (2) Wh= y the path was chosen to define extensions as part of the basic=A0"application/link-format" MIME type, i.e. why is "application/link-format" not introduced = to identify documents strictly formatted according to RFC 5988's link-value rule, and why are e= xtensions not handled like, for example, in XML, e.g.=A0"application/core+link-format"?

    My apologies for the confusion caused by yesterday's link. I am l= ooking forward to your feedback.

    Greeti= ngs

    Herbert Van de Sompel

    --
    Herbert= Van de Sompel
    Digital Library Research & Prototyping
    Los Alamos National Laborator= y, Research Library
    http://public.lanl.gov/herbertv/

    =3D=3D<= /div>
    --0022152d66d59086430494a00066-- From pab@peoplepowerco.com Tue Nov 9 07:43:45 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFD743A681D for ; Tue, 9 Nov 2010 07:43:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OmQpgcljKV8V for ; Tue, 9 Nov 2010 07:43:44 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 318303A67B2 for ; Tue, 9 Nov 2010 07:43:43 -0800 (PST) Received: by fxm3 with SMTP id 3so1039698fxm.31 for ; Tue, 09 Nov 2010 07:44:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.113.78 with SMTP id z14mr5269909fap.50.1289317447878; Tue, 09 Nov 2010 07:44:07 -0800 (PST) Received: by 10.223.100.14 with HTTP; Tue, 9 Nov 2010 07:44:07 -0800 (PST) In-Reply-To: References: Date: Tue, 9 Nov 2010 09:44:07 -0600 Message-ID: From: Peter Bigot To: Eric Rescorla Content-Type: multipart/alternative; boundary=001636c5ae1d7bc7aa0494a09c2e Cc: core Subject: Re: [core] Symmetry, or Stuffing state in etag X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 15:43:45 -0000 --001636c5ae1d7bc7aa0494a09c2e Content-Type: text/plain; charset=ISO-8859-1 Well, no. We're deliberately contemplating the use of tokens as a form of state transfer from a node back to itself. While exposing the state to modification by hopping it through a series of other nodes. As opposed to keeping the state at the client and using Token as a key to match the response to a specific request and its locally-retained state. I don't believe anybody's claimed that an end-point other than the originating client is entitled to extract information from the Token, so there's no intent to support state transfer from one side to another via content in Token. Has somebody suggested this use, and I've missed it? I am unconvinced that supporting interpretation of a response on a node that doesn't remember the original request is worth this level of effort. The whole problem goes away if we simply treat Etag and Token as the same sort of thing, and accept that a client that doesn't remember the request for which it receives a response should reply with a RST like the draft suggests. Peter On Tue, Nov 9, 2010 at 8:57 AM, Eric Rescorla wrote: > I don't think this is a very useful analogy. We're deliberately > contemplating the use of tokens as a > form of state transfer from one side to another. If we're doing so, we need > to address the security > issue. By contrast, Etags are intended purely as a check for whether two > versions of a resource > match and are not intended to be interpreted. If someone *did* decide to > use them the way you > suggest, then they of course would need to add security features. However, > since this is not > the intended use of etags, the situation is different. > > -Ekr > > On Tue, Nov 9, 2010 at 2:43 AM, Peter Bigot wrote: > >> Let's try it this way: >> >> Token is an opaque sequence introduced by a client to correlate a response >> with a previous request. >> >> Etag is an opaque sequence introduced by a server to correlate a request >> with (the content in) a previous response. >> >> A client may choose to embed information in a request Token, and extract >> that information when a response Token is received. To accommodate this >> use, Token must be large enough to hold this embedded information as well as >> a MAC to ensure the information is valid. >> >> Use case: the client is transferring a large block of memory to a server. >> It uses the Token to encode the address of the next block to transfer. When >> it receives the response, it decodes the Token value to determine how much >> data to send from what address. >> >> A server may choose to embed information in a response Etag, and extract >> that information when a subsequent request provides an Etag. To accommodate >> this use, Etag must be large enough to hold this embedded information as >> well as a MAC to ensure the information is valid. >> >> Use case: the server wishes to track how information it provides is >> distributed. Upon a request with no Etag, the server creates a data >> structure holding information about the client. It embeds the address of >> this data structure in the Etag. When it receives a request with an Etag, >> it dereferences the pointer to see whether this client is in the list of >> "friends" who have shared data with the original requester. >> >> Either use case could be easily accommodated by using the value as a small >> opaque key to identify locally stored (protected) information that never >> goes out in a message, avoiding the whole problem, but that's not the point >> here. The situations are symmetric, and should be handled the same way. >> That historically the draft says an end-point (including the server?) MUST >> make no assumptions about the format of an Etag value, but did not use the >> same language for Token, is an uncompelling reason to treat them >> differently. >> >> Peter >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> >> > --001636c5ae1d7bc7aa0494a09c2e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Well, no.=A0 We're deliberately contemplating the use of tokens as a fo= rm of state transfer from a node back to itself. =A0 While exposing the sta= te to modification by hopping it through a series of other nodes.=A0 As opp= osed to keeping the state at the client and using Token as a key to match t= he response to a specific request and its locally-retained state.

    I don't believe anybody's claimed that an end-point other than = the originating client is entitled to extract information from the Token, s= o there's no intent to support state transfer from one side to another = via content in Token.=A0 Has somebody suggested this use, and I've miss= ed it?

    I am unconvinced that supporting interpretation of a response on a node= that doesn't remember the original request is worth this level of effo= rt.=A0 The whole problem goes away if we simply treat Etag and Token as the= same sort of thing, and accept that a client that doesn't remember the= request for which it receives a response should reply with a RST like the = draft suggests.

    Peter

    On Tue, Nov 9, 2010 at 8:57 AM,= Eric Rescorla <ekr@rt= fm.com> wrote:
    I don't think this is a very useful analogy. We're deliberately con= templating the use of tokens as a
    form of state transfer from one side = to another. If we're doing so, we need to address the security
    issue. By contrast, Etags are intended purely as a check for whether t= wo versions of a resource
    match and are not intended to be interp= reted. If someone *did* decide to use them the way you
    suggest, t= hen they of course would need to add security features. However, since this= is not
    the intended use of etags, the situation is different.
    =
    -Ekr

    On Tue, Nov 9, 2010 at 2:43 AM, Pe= ter Bigot <pab@peoplepowerco.com> wrote:
    =
    Let's try it this way:

    Token is an = opaque sequence introduced by a client to correlate a response with a previ= ous request.

    Etag is an opaque sequence introduced by a server to correlate a reques= t with (the content in) a previous response.

    A client may choose to embed information in a request Token, and extrac= t that information when a response Token is received.=A0 To accommodate thi= s use, Token must be large enough to hold this embedded information as well= as a MAC to ensure the information is valid.

    Use case: the client is transferring = a large block of memory to a server.=A0 It uses the Token to encode the add= ress of the next block to transfer.=A0 When it receives the response, it de= codes the Token value to determine how much data to send from what address.=

    A server may choose to embed information in a response Etag, and = extract that information when a subsequent request provides an Etag.=A0 To = accommodate this use, Etag must be large enough to hold this embedded infor= mation as well as a MAC to ensure the information is valid.

    Use case: the server wishes to track = how information it provides is distributed.=A0 Upon a request with no Etag,= the server creates a data structure holding information about the client.= =A0 It embeds the address of this data structure in the Etag.=A0 When it re= ceives a request with an Etag, it dereferences the pointer to see whether t= his client is in the list of "friends" who have shared data with = the original requester.

    Either use case could be easily accommodated by using the value a= s a small=20 opaque key to identify locally stored (protected) information that never go= es out in a message, avoiding the whole problem, but that's not the poi= nt here.=A0 The situations are symmetric, and should be handled the same wa= y.=A0 That historically the draft says an end-point (including the server?)= MUST make no assumptions about the format of an Etag value, but did not us= e the same language for Token, is an uncompelling reason to treat them diff= erently.

    Peter

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



    --001636c5ae1d7bc7aa0494a09c2e-- From ekr@rtfm.com Tue Nov 9 08:01:01 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A55328C11B for ; Tue, 9 Nov 2010 08:01:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.782 X-Spam-Level: X-Spam-Status: No, score=-101.782 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ycaRPfthPyA for ; Tue, 9 Nov 2010 08:00:59 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 32CE528C10D for ; Tue, 9 Nov 2010 08:00:59 -0800 (PST) Received: by ywp6 with SMTP id 6so4760406ywp.31 for ; Tue, 09 Nov 2010 08:01:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.91.19.13 with SMTP id w13mr7235657agi.151.1289318483491; Tue, 09 Nov 2010 08:01:23 -0800 (PST) Received: by 10.91.78.6 with HTTP; Tue, 9 Nov 2010 08:01:23 -0800 (PST) In-Reply-To: References: Date: Tue, 9 Nov 2010 08:01:23 -0800 Message-ID: From: Eric Rescorla To: Peter Bigot Content-Type: multipart/alternative; boundary=001485f6d0da35fb480494a0da4e Cc: core Subject: Re: [core] Symmetry, or Stuffing state in etag X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 16:01:02 -0000 --001485f6d0da35fb480494a0da4e Content-Type: text/plain; charset=ISO-8859-1 On Tue, Nov 9, 2010 at 7:44 AM, Peter Bigot wrote: > Well, no. We're deliberately contemplating the use of tokens as a form of > state transfer from a node back to itself. Yes, that's what creates the security issue, because the node which is transiting the state is untrusted. > I am unconvinced that supporting interpretation of a response on a node > that doesn't remember the original request is worth this level of effort. > The whole problem goes away if we simply treat Etag and Token as the same > sort of thing, and accept that a client that doesn't remember the request > for which it receives a response should reply with a RST like the draft > suggests I don't understand what point you're making. If the Token is relied upon in any way such that modification of the token would cause the processing side to do anything other than fail the connection than it must be protected. -Ekr --001485f6d0da35fb480494a0da4e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

    On Tue, Nov 9, 2010 at 7:44 AM, Peter Bi= got <pab@peop= lepowerco.com> wrote:
    Well, no.=A0 We're deliberately contemplating the use of tokens as a fo= rm of state transfer from a node back to itself.

    Yes, that's what creates the security issue, because the node whi= ch is transiting the state is untrusted.

    =A0
    I am unconvinc= ed that supporting interpretation of a response on a node that doesn't = remember the original request is worth this level of effort.=A0 The whole p= roblem goes away if we simply treat Etag and Token as the same sort of thin= g, and accept that a client that doesn't remember the request for which= it receives a response should reply with a RST like the draft suggests

    I don't understand what point you're making.

    If the Token is relied upon in any way such that mod= ification of the token would cause the processing
    side to do anyt= hing other than fail the connection than it must be protected.

    -Ekr
    =A0
    --001485f6d0da35fb480494a0da4e-- From pab@peoplepowerco.com Tue Nov 9 08:06:51 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0FF13A6916 for ; Tue, 9 Nov 2010 08:06:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0jFB6WYUq37 for ; Tue, 9 Nov 2010 08:06:50 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 9A05C3A6879 for ; Tue, 9 Nov 2010 08:06:50 -0800 (PST) Received: by ewy27 with SMTP id 27so3946604ewy.31 for ; Tue, 09 Nov 2010 08:07:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.213.2.204 with SMTP id 12mr4516088ebk.98.1289318834422; Tue, 09 Nov 2010 08:07:14 -0800 (PST) Received: by 10.223.100.14 with HTTP; Tue, 9 Nov 2010 08:07:14 -0800 (PST) In-Reply-To: References: Date: Tue, 9 Nov 2010 10:07:14 -0600 Message-ID: From: Peter Bigot To: Eric Rescorla Content-Type: multipart/alternative; boundary=0015174beab620c59c0494a0efdd Cc: core Subject: Re: [core] Symmetry, or Stuffing state in etag X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 16:06:51 -0000 --0015174beab620c59c0494a0efdd Content-Type: text/plain; charset=ISO-8859-1 Is there a security issue if a node simply generates a random N-byte value (pick your N, I'd say 4), uses that as Token, and when it gets a response sees whether it has an outstanding request associated with that value? Peter On Tue, Nov 9, 2010 at 10:01 AM, Eric Rescorla wrote: > On Tue, Nov 9, 2010 at 7:44 AM, Peter Bigot wrote: > >> Well, no. We're deliberately contemplating the use of tokens as a form of >> state transfer from a node back to itself. > > > Yes, that's what creates the security issue, because the node which is > transiting the state is untrusted. > > > >> I am unconvinced that supporting interpretation of a response on a node >> that doesn't remember the original request is worth this level of effort. >> The whole problem goes away if we simply treat Etag and Token as the same >> sort of thing, and accept that a client that doesn't remember the request >> for which it receives a response should reply with a RST like the draft >> suggests > > > I don't understand what point you're making. > > If the Token is relied upon in any way such that modification of the token > would cause the processing > side to do anything other than fail the connection than it must be > protected. > > -Ekr > > --0015174beab620c59c0494a0efdd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Is there a security issue if a node simply generates a random N-byte value = (pick your N, I'd say 4), uses that as Token, and when it gets a respon= se sees whether it has an outstanding request associated with that value?
    Peter

    On Tue, Nov 9, 2010 at 10:01 AM= , Eric Rescorla <ekr@r= tfm.com> wrote:
    On Tue, Nov 9, 2010 at 7:44 AM= , Peter Bigot <pab@peoplepowerco.com> wrote:
    Well, no.=A0 We're deliberately contemplating the use of tokens as a fo= rm of state transfer from a node back to itself.

    Yes, that's what creates the security issue, because the no= de which is transiting the state is untrusted.

    =A0
    I am unconvinced that supporting interpretation of a response o= n a node that doesn't remember the original request is worth this level= of effort.=A0 The whole problem goes away if we simply treat Etag and Toke= n as the same sort of thing, and accept that a client that doesn't reme= mber the request for which it receives a response should reply with a RST l= ike the draft suggests

    I don't understand what point you're maki= ng.

    If the Token is relied upon in any way such th= at modification of the token would cause the processing
    side to d= o anything other than fail the connection than it must be protected.

    -Ekr
    =A0

    --0015174beab620c59c0494a0efdd-- From ekr@rtfm.com Tue Nov 9 08:13:06 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94DF63A682B for ; Tue, 9 Nov 2010 08:13:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.796 X-Spam-Level: X-Spam-Status: No, score=-101.796 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzZ-Xcn746wJ for ; Tue, 9 Nov 2010 08:13:05 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 8AA7B3A67B3 for ; Tue, 9 Nov 2010 08:13:05 -0800 (PST) Received: by gxk27 with SMTP id 27so3201849gxk.31 for ; Tue, 09 Nov 2010 08:13:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.90.4.6 with SMTP id 6mr7296468agd.16.1289319208810; Tue, 09 Nov 2010 08:13:28 -0800 (PST) Received: by 10.91.78.6 with HTTP; Tue, 9 Nov 2010 08:13:28 -0800 (PST) In-Reply-To: References: Date: Tue, 9 Nov 2010 08:13:28 -0800 Message-ID: From: Eric Rescorla To: Peter Bigot Content-Type: multipart/alternative; boundary=00163630ffbd7178290494a10520 Cc: core Subject: Re: [core] Symmetry, or Stuffing state in etag X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 16:13:06 -0000 --00163630ffbd7178290494a10520 Content-Type: text/plain; charset=ISO-8859-1 Quite possibly, unless it also checks that the responder is associated with that Token. -Ekr On Tue, Nov 9, 2010 at 8:07 AM, Peter Bigot wrote: > Is there a security issue if a node simply generates a random N-byte value > (pick your N, I'd say 4), uses that as Token, and when it gets a response > sees whether it has an outstanding request associated with that value? > > Peter > > > On Tue, Nov 9, 2010 at 10:01 AM, Eric Rescorla wrote: > >> On Tue, Nov 9, 2010 at 7:44 AM, Peter Bigot wrote: >> >>> Well, no. We're deliberately contemplating the use of tokens as a form >>> of state transfer from a node back to itself. >> >> >> Yes, that's what creates the security issue, because the node which is >> transiting the state is untrusted. >> >> >> >>> I am unconvinced that supporting interpretation of a response on a node >>> that doesn't remember the original request is worth this level of effort. >>> The whole problem goes away if we simply treat Etag and Token as the same >>> sort of thing, and accept that a client that doesn't remember the request >>> for which it receives a response should reply with a RST like the draft >>> suggests >> >> >> I don't understand what point you're making. >> >> If the Token is relied upon in any way such that modification of the token >> would cause the processing >> side to do anything other than fail the connection than it must be >> protected. >> >> -Ekr >> >> > > --00163630ffbd7178290494a10520 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Quite possibly, unless it also checks that the responder is associated with= that Token.

    -Ekr


    On Tue, Nov 9, 2010 at 8:07 AM, Peter Bigot <pab@peoplepowerco.com>= wrote:
    Is there a security issue if a node simply = generates a random N-byte value (pick your N, I'd say 4), uses that as = Token, and when it gets a response sees whether it has an outstanding reque= st associated with that value?

    Peter


    On Tue, Nov 9, 2010 at 10:01 AM, Eric Rescorla = <ekr@rtfm.com><= /span> wrote:
    On Tue, Nov 9, 2010 at 7:44 AM, Peter Bigot= <pab@peoplepowerco.com> wrote:
    Well, no.=A0 We're deliberately contemplating the use of tokens as a fo= rm of state transfer from a node back to itself.

    Yes, that's what creates the security issue, because the no= de which is transiting the state is untrusted.

    =A0
    I am unconvinced that supporting interpretation of a response on a no= de that doesn't remember the original request is worth this level of ef= fort.=A0 The whole problem goes away if we simply treat Etag and Token as t= he same sort of thing, and accept that a client that doesn't remember t= he request for which it receives a response should reply with a RST like th= e draft suggests

    I don't understand what point you're maki= ng.

    If the Token is relied upon in any way such th= at modification of the token would cause the processing
    side to d= o anything other than fail the connection than it must be protected.

    -Ekr
    =A0


    --00163630ffbd7178290494a10520-- From trac@tools.ietf.org Tue Nov 9 08:20:22 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE21F3A68B0 for ; Tue, 9 Nov 2010 08:20:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FbJpsh+M+GKX for ; Tue, 9 Nov 2010 08:20:22 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 91A0C3A68A5 for ; Tue, 9 Nov 2010 08:20:19 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PFqw8-0006fT-Bm; Tue, 09 Nov 2010 08:20:44 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: hartke@tzi.org X-Trac-Project: core Date: Tue, 09 Nov 2010 16:20:43 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/39#comment:1 Message-ID: <066.19b27112c2d8eebd84ddd8ef054db16d@tools.ietf.org> References: <057.04993421656cb054a86ee66d5b7ae8f8@tools.ietf.org> X-Trac-Ticket-ID: 39 In-Reply-To: <057.04993421656cb054a86ee66d5b7ae8f8@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hartke@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] observe #39 (new): Caching (validation model) (was: Etag) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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 Nov 2010 16:20:22 -0000 #39: Caching (validation model) -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: hartke@… Type: enhancement | Status: new Priority: minor | Milestone: Component: observe | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From trac@tools.ietf.org Tue Nov 9 08:23:09 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADE583A689A for ; Tue, 9 Nov 2010 08:23:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJouX0VNRFl4 for ; Tue, 9 Nov 2010 08:23:08 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id A9E853A67B3 for ; Tue, 9 Nov 2010 08:23:08 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PFqyr-0003zK-Ey; Tue, 09 Nov 2010 08:23:33 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: hartke@tzi.org X-Trac-Project: core Date: Tue, 09 Nov 2010 16:23:33 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/64 Message-ID: <053.f347afde6bc9e094e715841651603be6@tools.ietf.org> X-Trac-Ticket-ID: 64 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hartke@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] observe #64 (new): Caching (freshness model) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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 Nov 2010 16:23:09 -0000 #64: Caching (freshness model) Add an explanation of how notifications with Max-Age Option are cached, and include an example. -- ----------------------------+----------------------------------------------- Reporter: hartke@… | Owner: hartke@… Type: enhancement | Status: new Priority: minor | Milestone: Component: observe | Version: Severity: - | Keywords: ----------------------------+----------------------------------------------- Ticket URL: core From tianlinyi@huawei.com Tue Nov 9 08:25:19 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 022793A68AB for ; Tue, 9 Nov 2010 08:25:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.446 X-Spam-Level: ** X-Spam-Status: No, score=2.446 tagged_above=-999 required=5 tests=[AWL=2.448, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, J_CHICKENPOX_37=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9z+h-4LtFTw for ; Tue, 9 Nov 2010 08:25:16 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [58.251.152.64]) by core3.amsl.com (Postfix) with ESMTP id E90903A6885 for ; Tue, 9 Nov 2010 08:25:15 -0800 (PST) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LBM00IHXLMQUC@szxga01-in.huawei.com> for core@ietf.org; Wed, 10 Nov 2010 00:25:38 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LBM00HF5LMQI2@szxga01-in.huawei.com> for core@ietf.org; Wed, 10 Nov 2010 00:25:38 +0800 (CST) Received: from [192.168.50.208] ([124.205.65.18]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LBM00L14LMMJX@szxml02-in.huawei.com> for core@ietf.org; Wed, 10 Nov 2010 00:25:38 +0800 (CST) Date: Wed, 10 Nov 2010 00:25:33 +0800 From: Linyi Tian To: "CORE (Constrained RESTful Environments) WG" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_X6WemOG9E9mCy2vYc/rLVg)" Thread-topic: Question about rel=Index and rel=section In Link Format draft Thread-index: AcuAKrtTUO40dUpQWkaHQbjZZc5K/w== User-Agent: Microsoft-Entourage/12.25.0.100505 Subject: [core] Question about rel=Index and rel=section In Link Format draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 16:25:19 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --Boundary_(ID_X6WemOG9E9mCy2vYc/rLVg) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable Hi, Z. Shelby and all The link format draft shows two examples In section 2.8. I am wondering wha= t Is the difference between =8CRel=3DIndex =8Cand =8CRel=3Dsection=B9 In the examples. It Is easy to understand that =8Crel=3Dsection=B9 means there Is a collection of resources that the CoAP requestor can further retrieve the Information. Wha= t I don=B9t understand Is what =B3rel=3DIndex=B2 means. Why the two sub-resources are returned together with the Index. Is that the normal behavior? What will be returned If the requestor sends GET /.well-known/core/sensors In the first example? In the first example, the relative URI Is returned for all three resources, while the absolute URI Is returned for the first response In the second example. Why? This example includes link descriptions for an index to sensors hosted by a server, along with links two two different sensors. GET /.well-known/core ;rel=3D"index";n=3D"Sensor Index", ;sh=3D"/t";n=3D"TemperatureC", ;sh=3D"/l";ct=3D41;n=3D"LightLux" This example arranges link descriptions hierarchically, with the entry point including a link description to a sub-resource containing link descriptions about the sensors. GET /.well-known/core ;rel=3D"section" ;type=3D"application/link-format" GET /.well-known/core/sensors ;sh=3D"/t";n=3D"TemperatureC", ;sh=3D"/l";ct=3D41;n=3D"LightLux" Cheers, Linyi --Boundary_(ID_X6WemOG9E9mCy2vYc/rLVg) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Question about rel=Index and rel=section In Link Format draft Hi, Z. Shelby and all

    The link format draft shows two examples In section 2.8. I am wondering what Is the difference between ‘Rel=Index ‘and ‘Rel=section’ In the examples.

    It Is easy to understand that ‘rel=section’ means there Is a collection of resources that the CoAP requestor can further retrieve the Information. What I don’t understand Is what “rel=Index” means. Why the two sub-resources are returned together with the Index. Is that the normal behavior? What will be returned If the requestor sends GET /.well-known/core/sensors In the first example?

    In the first example, the relative URI Is returned for all three resources, while the absolute URI Is returned for the first response In the second example. Why?

    This example includes link descriptions for an index to sensors
       hosted by a server, along with links two two different sensors.

       GET /.well-known/core

       </sensors>;rel="index";n="Sensor Index",
       </sensors/temp>;sh="/t";n="TemperatureC",
       </sensors/light>;sh="/l";ct=41;n="LightLux"

       This example arranges link descriptions hierarchically, with the
       entry point including a link description to a sub-resource containing
       link descriptions about the sensors.

       GET /.well-known/core

       </.well-known/core/sensors>;rel="section"
       ;type="application/link-format"

       GET /.well-known/core/sensors

       </sensors/temp>;sh="/t";n="TemperatureC",
       </sensors/light>;sh="/l";ct=41;n="LightLux"

    Cheers,
    Linyi     --Boundary_(ID_X6WemOG9E9mCy2vYc/rLVg)-- From trac@tools.ietf.org Tue Nov 9 08:26:35 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7DC73A6911 for ; Tue, 9 Nov 2010 08:26:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ySK5sojqRg12 for ; Tue, 9 Nov 2010 08:26:35 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 158293A6885 for ; Tue, 9 Nov 2010 08:26:35 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PFr2B-0004V3-RU; Tue, 09 Nov 2010 08:26:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: hartke@tzi.org X-Trac-Project: core Date: Tue, 09 Nov 2010 16:26:59 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/36#comment:1 Message-ID: <066.1523d56390030b865777c2dc37194655@tools.ietf.org> References: <057.dbea84638c82722d3a8ba105936f431e@tools.ietf.org> X-Trac-Ticket-ID: 36 In-Reply-To: <057.dbea84638c82722d3a8ba105936f431e@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hartke@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] observe #36 (new): Interaction with draft-ietf-core-block (was: Interaction with other mechanisms) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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 Nov 2010 16:26:35 -0000 #36: Interaction with draft-ietf-core-block Comment(by hartke@…): This ticket is now about how observations interact with the Block Option. Caching has been moved to tickets #39 and #64. -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: hartke@… Type: defect | Status: new Priority: minor | Milestone: Component: observe | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From trac@tools.ietf.org Tue Nov 9 08:30:55 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E80973A69AE for ; Tue, 9 Nov 2010 08:30:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3KQXBmGaFW-d for ; Tue, 9 Nov 2010 08:30:55 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 5AE3E3A6885 for ; Tue, 9 Nov 2010 08:30:55 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PFr6O-0001lG-5N; Tue, 09 Nov 2010 08:31:20 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: hartke@tzi.org X-Trac-Project: core Date: Tue, 09 Nov 2010 16:31:20 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/65 Message-ID: <053.90384a457ccefcfb111aee0cbf87a0b9@tools.ietf.org> X-Trac-Ticket-ID: 65 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hartke@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] observe #65 (new): Normal requests should not affect any ongoing observation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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 Nov 2010 16:30:56 -0000 #65: Normal requests should not affect any ongoing observation As discussed on the mailing list with Adam Roach, it should be clarified that making a normal GET (with no Observation-lifetime option) does not affect any ongoing observation. -- ----------------------------+----------------------------------------------- Reporter: hartke@… | Owner: hartke@… Type: defect | Status: new Priority: major | Milestone: Component: observe | Version: Severity: - | Keywords: ----------------------------+----------------------------------------------- Ticket URL: core From trac@tools.ietf.org Tue Nov 9 08:37:17 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E18E3A69A4 for ; Tue, 9 Nov 2010 08:37:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NP4hfHJEuxae for ; Tue, 9 Nov 2010 08:37:09 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id AB2363A6A05 for ; Tue, 9 Nov 2010 08:37:03 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PFrCJ-0007aI-6Y; Tue, 09 Nov 2010 08:37:27 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: hartke@tzi.org X-Trac-Project: core Date: Tue, 09 Nov 2010 16:37:27 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/66 Message-ID: <053.44399fd645fe2aa7d70a9c84cb0da595@tools.ietf.org> X-Trac-Ticket-ID: 66 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hartke@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] observe #66 (new): Identifying observations X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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 Nov 2010 16:37:17 -0000 #66: Identifying observations It should be clarified that an observation is identified by the URI of the observed resource and the the IP address + port of the observer. A token submitted by the observer must not be used by the server to identify an observation; observation requests from the same observer to the same resource must update/replace any ongoing observation, even if the token has changed. -- ----------------------------+----------------------------------------------- Reporter: hartke@… | Owner: hartke@… Type: defect | Status: new Priority: minor | Milestone: Component: observe | Version: Severity: - | Keywords: ----------------------------+----------------------------------------------- Ticket URL: core From trac@tools.ietf.org Tue Nov 9 08:44:43 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BAC63A69B4 for ; Tue, 9 Nov 2010 08:44:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oKNlPX9slcfZ for ; Tue, 9 Nov 2010 08:44:43 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id F3A4E3A68C2 for ; Tue, 9 Nov 2010 08:44:42 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PFrJj-00013T-Qp; Tue, 09 Nov 2010 08:45:07 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: hartke@tzi.org X-Trac-Project: core Date: Tue, 09 Nov 2010 16:45:07 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/core/trac/ticket/67 Message-ID: <053.741236a6f0f28d5442a1da35fc6ce726@tools.ietf.org> X-Trac-Ticket-ID: 67 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hartke@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] observe #67 (new): Business rules for notifications X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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 Nov 2010 16:44:43 -0000 #67: Business rules for notifications draft-ietf-core-observe-00 states: "It is not necessary that [...] the server sends a notification response for every single state change." It should be clarified that a server does not need to send a notification response for every single state change if, for example, the state is changing rapidly. The overriding objective, however, is that the state observed by an observer eventually becomes consistent with the actual state of the observed resource. This means, for example, if a resource stops changing frequently, that the server should make sure that the observer receives the latest resource state. It should also be clarified that a server may notify an observer more than once about the same state change, for example, first using a non- confirmable notification response, and after some timeout a confirmable notification response, to make sure that the observer receives the latest resource state. -- ----------------------------+----------------------------------------------- Reporter: hartke@… | Owner: hartke@… Type: enhancement | Status: new Priority: minor | Milestone: Component: observe | Version: Severity: - | Keywords: ----------------------------+----------------------------------------------- Ticket URL: core From trac@tools.ietf.org Tue Nov 9 08:48:16 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 547993A68E8 for ; Tue, 9 Nov 2010 08:48:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m+B6sN9Y+rmD for ; Tue, 9 Nov 2010 08:48:15 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 9FB783A68C2 for ; Tue, 9 Nov 2010 08:48:15 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PFrNA-0005Am-G6; Tue, 09 Nov 2010 08:48:40 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: hartke@tzi.org X-Trac-Project: core Date: Tue, 09 Nov 2010 16:48:40 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/core/trac/ticket/68 Message-ID: <053.e2e32367bc816bfaa499f9c42fd41c7d@tools.ietf.org> X-Trac-Ticket-ID: 68 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hartke@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] observe #68 (new): Minimum duration between observation requests X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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 Nov 2010 16:48:16 -0000 #68: Minimum duration between observation requests There should probably be a minimum duration between two observation requests by the same client to the same resource. This is in particular required in the case the observation request falls back to a normal GET request. -- ----------------------------+----------------------------------------------- Reporter: hartke@… | Owner: hartke@… Type: enhancement | Status: new Priority: minor | Milestone: Component: observe | Version: Severity: - | Keywords: ----------------------------+----------------------------------------------- Ticket URL: core From tianlinyi@huawei.com Tue Nov 9 08:48:22 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6326D3A698C for ; Tue, 9 Nov 2010 08:48:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.674 X-Spam-Level: * X-Spam-Status: No, score=1.674 tagged_above=-999 required=5 tests=[AWL=0.772, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvjTTiRLMmLo for ; Tue, 9 Nov 2010 08:48:19 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [58.251.152.67]) by core3.amsl.com (Postfix) with ESMTP id 51DBB3A68C2 for ; Tue, 9 Nov 2010 08:48:19 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LBM00A7MMP32Q@szxga04-in.huawei.com> for core@ietf.org; Wed, 10 Nov 2010 00:48:39 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LBM00GWLMP2B4@szxga04-in.huawei.com> for core@ietf.org; Wed, 10 Nov 2010 00:48:39 +0800 (CST) Received: from [192.168.50.208] ([124.205.65.18]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LBM00FY4MP20Q@szxml01-in.huawei.com> for core@ietf.org; Wed, 10 Nov 2010 00:48:38 +0800 (CST) Date: Wed, 10 Nov 2010 00:48:37 +0800 From: Linyi Tian To: "CORE (Constrained RESTful Environments) WG" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_Wov8wF7rSTCbx7gocBEvhw)" Thread-topic: A potential new ticket for '-d' usage in link format draft Thread-index: AcuALfRB6Pmzzbm4UESqVUGLkYhqtA== User-Agent: Microsoft-Entourage/12.25.0.100505 Subject: [core] A potential new ticket for '-d' usage in link format draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 16:48:22 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --Boundary_(ID_Wov8wF7rSTCbx7gocBEvhw) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable Hi, Z. Shelby and all When I review the link format draft, I believe there is a potential issue for =ADd usage extension. Consider the following example: --Sensor-----Light |--Temp For light, its URI could be ;sh=3D=B2/l=B2;n=3D=B2LightLux=B2;d=3D=B2http://example.com/index=B2;ct=3D41 If the requestor sends GET /l, the xml description file will be returned according to content type code 41. This is clear. However what is the semantics behind the =B3-d=B2 URI is unclear. Even though you mentioned that =ADd could be a WADL definition, it is not possible for th= e requestor to know the relation type and purpose of this =ADd URI. It is also unclear whether it is allowed for the requestor to use GET command against this =ADd URI. Do you think this would be a problem? I think this needs to be clarified in the spec and the example. By the way how to create a new ticket? Do I need to execute SQL to add a ne= w one? Is there any authority will review the reported issue and create a ticket when he/she thinks this is really an issue? Cheers, Linyi --Boundary_(ID_Wov8wF7rSTCbx7gocBEvhw) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT A potential new ticket for '-d' usage in link format draft Hi, Z. Shelby and all

    When I review the link format draft, I believe there is a potential issue for –d usage extension.

    Consider the following example:
    --Sensor-----Light
                    |--Temp

    For light, its URI could be <Sensor/Light>;sh=”/l”;n=”LightLux”;d=”http://example.com/index”;ct=41

    If the requestor sends GET /l, the xml description file will be returned according to content type code 41. This is clear.

    However what is the semantics behind the “-d” URI is unclear. Even though you mentioned that –d could be a WADL definition, it is not possible for the requestor to know the relation type and purpose of this –d URI.

    It is also unclear whether it is allowed for the requestor to use GET command against this –d URI. Do you think this would be a problem? I think this needs to be clarified in the spec and the example.

    By the way how to create a new ticket? Do I need to execute SQL to add a new one? Is there any authority will review the reported issue and create a ticket when he/she thinks this is really an issue?

    Cheers,
    Linyi     --Boundary_(ID_Wov8wF7rSTCbx7gocBEvhw)-- From trac@tools.ietf.org Tue Nov 9 08:59:54 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3E5A3A69F8 for ; Tue, 9 Nov 2010 08:59:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8XY8P3PmKsRW for ; Tue, 9 Nov 2010 08:59:53 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id F12FF3A69E8 for ; Tue, 9 Nov 2010 08:59:53 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PFrYQ-0008Ne-36; Tue, 09 Nov 2010 09:00:18 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: hartke@tzi.org X-Trac-Project: core Date: Tue, 09 Nov 2010 17:00:18 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/69 Message-ID: <053.302c4bd20f0e7ef12ddf5197c20c08c7@tools.ietf.org> X-Trac-Ticket-ID: 69 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hartke@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] observe #69 (new): Notifying temporarily unresponsive clients X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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 Nov 2010 16:59:55 -0000 #69: Notifying temporarily unresponsive clients In the context of CoAP-observe, it is undesirable to transmit the representation of a resource state that has already been replaced by a new resource state long ago. So what we need is some strategy that deals with the case when a resource state changes and the observer hasn't acknowledged the last confirmable notification. There are many reasons why an observer might not have acknowledged the last confirmable notification: * there's a short interruption in message delivery, * the client's battery has run out of charge, * the client can't keep up with processing the notifications, * the network is congested, * etc. We want a server to end a subscription when the client is gone, but we don't want to end a subscription just because there's a short hiccup in the network. There are several possible solutions, including: * (a) Set MAX_RETRANSMIT for confirmable notifications to 1. * (b) Do not allow any notifications while a confirmable notification is pending. * (c) Cancel pending confirmable notifications when the next confirmable notification is to be sent. * (d) Do not transmit a snapshot, but a representation of the state that is current at the instant of the retransmission. * (e) Cancel the pending confirmable notification and send the new confirmable notification with MAX_RETRANSMIT set to the number of attempts remaining from the canceled notification. draft-ietf-core-observe-00 recommends (d). This ticket proposes to recommend (e). -- ----------------------------+----------------------------------------------- Reporter: hartke@… | Owner: hartke@… Type: defect | Status: new Priority: major | Milestone: Component: observe | Version: Severity: - | Keywords: ----------------------------+----------------------------------------------- Ticket URL: core From tianlinyi@huawei.com Tue Nov 9 09:03:27 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65D493A68E0 for ; Tue, 9 Nov 2010 09:03:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.417 X-Spam-Level: * X-Spam-Status: No, score=1.417 tagged_above=-999 required=5 tests=[AWL=0.515, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lABaPB00aRAy for ; Tue, 9 Nov 2010 09:03:24 -0800 (PST) Received: from szxga05-in.huawei.com (unknown [58.251.152.67]) by core3.amsl.com (Postfix) with ESMTP id 0BB123A68E9 for ; Tue, 9 Nov 2010 09:03:24 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LBM00837NEBPU@szxga05-in.huawei.com> for core@ietf.org; Wed, 10 Nov 2010 01:03:48 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LBM009EZNEB1A@szxga05-in.huawei.com> for core@ietf.org; Wed, 10 Nov 2010 01:03:47 +0800 (CST) Received: from [192.168.50.208] ([124.205.65.18]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LBM00FF1NEB0Q@szxml01-in.huawei.com> for core@ietf.org; Wed, 10 Nov 2010 01:03:47 +0800 (CST) Date: Wed, 10 Nov 2010 01:03:45 +0800 From: Linyi Tian To: "CORE (Constrained RESTful Environments) WG" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_sIPoYymLxG/uHVCLtGqfwg)" Thread-topic: Need clarification for filter params in link format draft Thread-index: AcuAMBF316NyoAIJlkGE7eveMTVafA== User-Agent: Microsoft-Entourage/12.25.0.100505 Subject: [core] Need clarification for filter params in link format draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 17:03:27 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --Boundary_(ID_sIPoYymLxG/uHVCLtGqfwg) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable Hi, Z. Shelby and all Currently there are five params listed in the filtering section. I doubt whether =8Curi=B9, =8Cd=B9 and =8Csh=B9 are needed. resource-param =3D "uri" | "d" | "sh" | "n" | "id" I am wondering how to use these three params. It is easy to understand the case that that requestor doesn=B9t know the exact location but just the name. If the requestor knows the URI, what has been filtered by including the URI (uri, d, sh)? Another question is that why =8Crel=B9 and =8Cct=B9 is not included. The requestor may wants to know all the index nodes by adding rel param in the query. On the other hand, the requestor may also wants to query all the resources wit= h content type image/jpeg. So do you think it make sense to include =8Crel=B9 and =8Cct? Cheers, Linyi --Boundary_(ID_sIPoYymLxG/uHVCLtGqfwg) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Need clarification for filter params in link format draft Hi, Z. Shelby and all

    Currently there are five params listed in the filtering section. I doubt whether ‘uri’, ‘d’ and ‘sh’ are needed.

    resource-param = "uri" | "d" | "sh" | "n" | "id"

    I am wondering how to use these three params. It is easy to understand the case that that requestor doesn’t know the exact location but just the name. If the requestor knows the URI, what has been filtered by including the URI (uri, d, sh)?

    Another question is that why ‘rel’ and ‘ct’ is not included. The requestor may wants to know all the index nodes by adding rel param in the query. On the other hand, the requestor may also wants to query all the resources with content type image/jpeg. So do you think it make sense to include ‘rel’ and ‘ct?

    Cheers,
    Linyi     --Boundary_(ID_sIPoYymLxG/uHVCLtGqfwg)-- From pab@peoplepowerco.com Tue Nov 9 09:05:30 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DDCD3A6911 for ; Tue, 9 Nov 2010 09:05:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVAzTkWQGgj7 for ; Tue, 9 Nov 2010 09:05:29 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id B7F243A68ED for ; Tue, 9 Nov 2010 09:05:28 -0800 (PST) Received: by fxm3 with SMTP id 3so1116855fxm.31 for ; Tue, 09 Nov 2010 09:05:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.119.132 with SMTP id z4mr1397583faq.31.1289322352265; Tue, 09 Nov 2010 09:05:52 -0800 (PST) Received: by 10.223.100.14 with HTTP; Tue, 9 Nov 2010 09:05:52 -0800 (PST) In-Reply-To: References: Date: Tue, 9 Nov 2010 11:05:52 -0600 Message-ID: From: Peter Bigot To: Eric Rescorla Content-Type: multipart/alternative; boundary=001636c5b231cecb9c0494a1c09c Cc: core Subject: Re: [core] Symmetry, or Stuffing state in etag X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 17:05:30 -0000 --001636c5b231cecb9c0494a1c09c Content-Type: text/plain; charset=ISO-8859-1 Then a client should follow that procedure (including checking the responder against the target of the original request) and there's no need to suggest that implementations are entitled to put other information in the Token but should add a MAC if they do so. Security risk eliminated, message size decreased, concept of what Token is for simplified. What I'm saying is that the intended use of Token was like Etag, and extending it to a purpose that requires addition of a MAC to be secure should be rejected as it is proposed only for use cases that are neither common nor compelling. Peter On Tue, Nov 9, 2010 at 10:13 AM, Eric Rescorla wrote: > Quite possibly, unless it also checks that the responder is associated with > that Token. > > -Ekr > > > On Tue, Nov 9, 2010 at 8:07 AM, Peter Bigot wrote: > >> Is there a security issue if a node simply generates a random N-byte value >> (pick your N, I'd say 4), uses that as Token, and when it gets a response >> sees whether it has an outstanding request associated with that value? >> >> Peter >> >> >> On Tue, Nov 9, 2010 at 10:01 AM, Eric Rescorla wrote: >> >>> On Tue, Nov 9, 2010 at 7:44 AM, Peter Bigot wrote: >>> >>>> Well, no. We're deliberately contemplating the use of tokens as a form >>>> of state transfer from a node back to itself. >>> >>> >>> Yes, that's what creates the security issue, because the node which is >>> transiting the state is untrusted. >>> >>> >>> >>>> I am unconvinced that supporting interpretation of a response on a node >>>> that doesn't remember the original request is worth this level of effort. >>>> The whole problem goes away if we simply treat Etag and Token as the same >>>> sort of thing, and accept that a client that doesn't remember the request >>>> for which it receives a response should reply with a RST like the draft >>>> suggests >>> >>> >>> I don't understand what point you're making. >>> >>> If the Token is relied upon in any way such that modification of the >>> token would cause the processing >>> side to do anything other than fail the connection than it must be >>> protected. >>> >>> -Ekr >>> >>> >> >> > --001636c5b231cecb9c0494a1c09c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Then a client should follow that procedure (including checking the responde= r against the target of the original request) and there's no need to su= ggest that implementations are entitled to put other information in the Tok= en but should add a MAC if they do so.=A0 Security risk eliminated, message= size decreased, concept of what Token is for simplified.

    What I'm saying is that the intended use of Token was like Etag, an= d extending it to a purpose that requires addition of a MAC to be secure sh= ould be rejected as it is proposed only for use cases that are neither comm= on nor compelling.

    Peter

    On Tue, Nov 9, 2010 at 10:13 AM= , Eric Rescorla <ekr@r= tfm.com> wrote:
    Quite possibly, unless it also checks that the responder is associated with= that Token.

    -Ekr


    On Tue, Nov 9, 2010 at 8:07 AM, Pe= ter Bigot <pab@peoplepowerco.com> wrote:
    Is there a securi= ty issue if a node simply generates a random N-byte value (pick your N, I&#= 39;d say 4), uses that as Token, and when it gets a response sees whether i= t has an outstanding request associated with that value?

    Peter


    On = Tue, Nov 9, 2010 at 10:01 AM, Eric Rescorla <ekr@rtfm.com> wrot= e:
    On Tue, Nov 9, 2010 at 7:44 AM, Peter Bigot= <pab@peoplepowerco.com> wrote:
    Well, no.=A0 We're deliberately contemplating the use of tokens as a fo= rm of state transfer from a node back to itself.

    Yes, that's what creates the security issue, because the no= de which is transiting the state is untrusted.

    =A0
    I am unconvinced that supporting interpretation of a response o= n a node that doesn't remember the original request is worth this level= of effort.=A0 The whole problem goes away if we simply treat Etag and Toke= n as the same sort of thing, and accept that a client that doesn't reme= mber the request for which it receives a response should reply with a RST l= ike the draft suggests

    I don't understand what point you're maki= ng.

    If the Token is relied upon in any way such th= at modification of the token would cause the processing
    side to d= o anything other than fail the connection than it must be protected.

    -Ekr
    =A0



    --001636c5b231cecb9c0494a1c09c-- From zach@sensinode.com Tue Nov 9 09:15:10 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B00463A68ED for ; Tue, 9 Nov 2010 09:15:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.562 X-Spam-Level: X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ykp4FjpRdzAH for ; Tue, 9 Nov 2010 09:15:09 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 17B1A3A68E0 for ; Tue, 9 Nov 2010 09:15:08 -0800 (PST) Received: from dhcp-40a3.meeting.ietf.org (dhcp-40a3.meeting.ietf.org [130.129.64.163]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id oA9HFK4E001070 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 9 Nov 2010 19:15:25 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-253--369406185; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: Date: Wed, 10 Nov 2010 01:15:22 +0800 Message-Id: <2F9AEE46-6032-437A-B33D-5833F7755E16@sensinode.com> References: To: Herbert van de Sompel X-Mailer: Apple Mail (2.1081) Cc: core@ietf.org Subject: Re: [core] Memento TimeMaps, again X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 17:15:10 -0000 --Apple-Mail-253--369406185 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Herbert, Sorry I am slow answering right now, IETF week... We are actually = discussing link-format in tomorrow's WG meeting and I will mention your = case. See answers to your questions below: On Nov 9, 2010, at 11:00 PM, Herbert van de Sompel wrote: > Hi again, >=20 > Since there have been some problems with the link to a TimeMap I sent = in yesterday's mail, I have posted a TimeMap at a URI that should not = cause confusion: >=20 > http://dl.dropbox.com/u/2114080/ugent_timemap.txt >=20 > TimeMaps are introduced in the Memento framework = (http://mementoweb.org) and are formatted according to the link-value = construction rule of the BNF of RFC 5988.=20 >=20 > I would like to repeat the questions I posted yesterday: >=20 > We are currently finalizing the first version of an Internet Draft for = Memento, and we are in need of a special-purpose MIME type as the = text/csv that we currently use is inaccurate. In that context, I was = wondering about the following: >=20 > (1) Is it appropriate for us to use "application/link-format" for our = TimeMaps? Note that our TimeMaps strictly adhere to the link-value = construction rule of RFC 5988, i.e. we are not using any of the = extensions that you propose. Sure, I don't see why not. application/link-format does not require use = of any link-extensions.=20 >=20 > (2) Why the path was chosen to define extensions as part of the basic = "application/link-format" MIME type, i.e. why is = "application/link-format" not introduced to identify documents strictly = formatted according to RFC 5988's link-value rule, and why are = extensions not handled like, for example, in XML, e.g. = "application/core+link-format"? This is because we are conforming to RFC5988, and link-extensions are = optional. Thus I think you can reference this document as-is and you are = good to go.=20 Regards, Zach >=20 > My apologies for the confusion caused by yesterday's link. I am = looking forward to your feedback. >=20 > Greetings >=20 > Herbert Van de Sompel >=20 > --=20 > Herbert Van de Sompel > Digital Library Research & Prototyping > Los Alamos National Laboratory, Research Library > http://public.lanl.gov/herbertv/ >=20 > =3D=3D >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 --Apple-Mail-253--369406185 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9 fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb 6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja 5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I 2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTEwOTE3MTUy M1owIwYJKoZIhvcNAQkEMRYEFGGJKCbTj1ZkehrWiGgaaeCjklEAMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAEsrtFo/oefDjTUgn27UasAWCaX70YCQ7j1D5tA/JtV1uLLB3nMMhOJt fe/fqhE4OKRCiNUPZ65/sv0+4ceyDjRpj7GZs42X1IgER3DF1QxUfxrBZyoxmlNiYpMF1B5KqvBD W2cVwo3lgxmMLlrgQRQFmRcFVhSZQw9q8++Qp79NotzRrvrLcUX9rHOu+rR7LReYxrFVZkKUKvtr lWnS03rNlfa7dHicBqYC0SmD1icjvurXpOWFZJM1vhzMbNHHJUxpIRawgwRMT9hGdukuTUmgnczv pyTM7ddnGZudFjUGYU6aaTZDPPRzjJ6JDCcxdh83uGOxT4p1kF+sWSw+tu0AAAAAAAA= --Apple-Mail-253--369406185-- From pab@peoplepowerco.com Tue Nov 9 09:18:23 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB27D3A6975 for ; Tue, 9 Nov 2010 09:18:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCk-vScw0FAL for ; Tue, 9 Nov 2010 09:18:23 -0800 (PST) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 557163A6860 for ; Tue, 9 Nov 2010 09:18:22 -0800 (PST) Received: by gwj19 with SMTP id 19so6542gwj.31 for ; Tue, 09 Nov 2010 09:18:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.71.83 with SMTP id g19mr6663500bkj.158.1289323125546; Tue, 09 Nov 2010 09:18:45 -0800 (PST) Received: by 10.223.100.14 with HTTP; Tue, 9 Nov 2010 09:18:45 -0800 (PST) In-Reply-To: References: Date: Tue, 9 Nov 2010 11:18:45 -0600 Message-ID: From: Peter Bigot To: Linyi Tian Content-Type: multipart/alternative; boundary=00504502e270e61df90494a1eeb7 Cc: "CORE \(Constrained RESTful Environments\) WG" Subject: Re: [core] Need clarification for filter params in link format draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 17:18:24 -0000 --00504502e270e61df90494a1eeb7 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I believe "uri" was intended to provide a name that can be used to access that portion of the link description that is called the "Target IRI" in RFC5988. It is the one field that you might want to filter on that is not = a link-param. Naming specific elements seems unwise, as it leads to the sorts of other questions you raise, and there's really no reason to do so. I suspect the rule should be: resource-param =3D "uri" | parmname Peter On Tue, Nov 9, 2010 at 11:03 AM, Linyi Tian wrote: > Hi, Z. Shelby and all > > Currently there are five params listed in the filtering section. I doubt > whether =91uri=92, =91d=92 and =91sh=92 are needed. > > resource-param =3D "uri" | "d" | "sh" | "n" | "id" > > I am wondering how to use these three params. It is easy to understand th= e > case that that requestor doesn=92t know the exact location but just the n= ame. > If the requestor knows the URI, what has been filtered by including the U= RI > (uri, d, sh)? > > Another question is that why =91rel=92 and =91ct=92 is not included. The = requestor > may wants to know all the index nodes by adding rel param in the query. O= n > the other hand, the requestor may also wants to query all the resources w= ith > content type image/jpeg. So do you think it make sense to include =91rel= =92 and > =91ct? > > Cheers, > Linyi > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > --00504502e270e61df90494a1eeb7 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I believe "uri" was intended to provide a name that can be used t= o access that portion of the link description that is called the "Targ= et IRI" in RFC5988.=A0 It is the one field that you might want to filt= er on that is not a link-param.

    Naming specific elements seems unwise, as it leads to the sorts of othe= r questions you raise, and there's really no reason to do so.=A0 I susp= ect the rule should be:

    =A0=A0 resource-param =3D "uri" | = parmname

    Peter

    On Tue, Nov 9, 2010 at 11:03 AM= , Linyi Tian <= tianlinyi@huawei.com> wrote:
    Hi, Z. Shelby and all

    Currently there are five params listed in the filtering section. I doubt wh= ether =91uri=92, =91d=92 and =91sh=92 are needed.

    resource-param =3D "uri" | "d"= | "sh" | "n" | "id"

    I am wondering how to use these three params. It is easy to understand the = case that that requestor doesn=92t know the exact location but just the nam= e. If the requestor knows the URI, what has been filtered by including the = URI (uri, d, sh)?

    Another question is that why =91rel=92 and =91ct=92 is not included. The re= questor may wants to know all the index nodes by adding rel param in the qu= ery. On the other hand, the requestor may also wants to query all the resou= rces with content type image/jpeg. So do you think it make sense to include= =91rel=92 and =91ct?

    Cheers,
    Linyi

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


    --00504502e270e61df90494a1eeb7-- From zach@sensinode.com Tue Nov 9 09:25:10 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFE3C3A67F1 for ; Tue, 9 Nov 2010 09:25:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.966 X-Spam-Level: X-Spam-Status: No, score=-2.966 tagged_above=-999 required=5 tests=[AWL=-0.567, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24yn1Dv6UbPr for ; Tue, 9 Nov 2010 09:25:08 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 3DB833A692A for ; Tue, 9 Nov 2010 09:25:03 -0800 (PST) Received: from dhcp-40a3.meeting.ietf.org (dhcp-40a3.meeting.ietf.org [130.129.64.163]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id oA9HPCHp001482 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 9 Nov 2010 19:25:18 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-254--368815010; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: Date: Wed, 10 Nov 2010 01:25:13 +0800 Message-Id: <71D6BA63-2534-4526-97E4-FA1A6FC9222F@sensinode.com> References: To: Linyi Tian X-Mailer: Apple Mail (2.1081) Cc: "CORE \(Constrained RESTful Environments\) WG" Subject: Re: [core] Question about rel=Index and rel=section In Link Format draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 17:25:10 -0000 --Apple-Mail-254--368815010 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, Thanks for these comments (and the more recent ones too).=20 On Nov 10, 2010, at 12:25 AM, Linyi Tian wrote: > Hi, Z. Shelby and all >=20 > The link format draft shows two examples In section 2.8. I am = wondering what Is the difference between =91Rel=3DIndex =91and = =91Rel=3Dsection=92 In the examples.=20 >=20 > It Is easy to understand that =91rel=3Dsection=92 means there Is a = collection of resources that the CoAP requestor can further retrieve the = Information. What I don=92t understand Is what =93rel=3DIndex=94 means. = Why the two sub-resources are returned together with the Index. Is that = the normal behavior? What will be returned If the requestor sends GET = /.well-known/core/sensors In the first example? That URL doesn't exist in the first example. You would GET /sensors. The = reason that I included /sensors/temp and /sensors/light in the example = is that /sensors is not necessarily application/link-format, but might = e.g. contain the values of both siblings. It is really up to the server = to decide.=20 > In the first example, the relative URI Is returned for all three = resources, while the absolute URI Is returned for the first response In = the second example. Why? The URIs in the first example are not relative. I think you were = assuming that /sensors is under /.well-known/core because it is an = "index"? It is not. I might interpret RFC5988 wrong here, but to me "index" is a summary or = list of information about siblings (outside of /.well-known/core), = whereas "section" is used to indicate that the URL under = /.well-known/core contains a part of the links. Attempting to make = logical use of the different relations from RFC5988 in a logical way for = CoRE... OK, obviously the examples need some more explanation (and we need some = more examples). I'll be sure to do that in the next version. Zach > This example includes link descriptions for an index to sensors > hosted by a server, along with links two two different sensors. >=20 > GET /.well-known/core >=20 > ;rel=3D"index";n=3D"Sensor Index", > ;sh=3D"/t";n=3D"TemperatureC", > ;sh=3D"/l";ct=3D41;n=3D"LightLux" >=20 > This example arranges link descriptions hierarchically, with the > entry point including a link description to a sub-resource = containing > link descriptions about the sensors. >=20 > GET /.well-known/core >=20 > ;rel=3D"section" > ;type=3D"application/link-format" >=20 > GET /.well-known/core/sensors >=20 > ;sh=3D"/t";n=3D"TemperatureC", > ;sh=3D"/l";ct=3D41;n=3D"LightLux" >=20 > Cheers, > Linyi > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 --Apple-Mail-254--368815010 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9 fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb 6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja 5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I 2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTEwOTE3MjUx NFowIwYJKoZIhvcNAQkEMRYEFCkATC6a03PbQR/8+dmoLJUz/KghMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAAYsQBTvXYYKkC2Q1Wcpw2iMH80F1HzOWNx9FSKFL5gjyEAfuFMLpr1w bpbbCuiKRsxyk0o/eq3Zn/o5cNtn61JgAZtBK+utS7ElulaIVL6uly+ZW0ExB3j8gBhO1he+x5V1 QUgK2/QMNK5UagBOEknYIRlgmTs+ry4q0yrxAr2wsHeI6wAgIWFAoJz8b4+imWJfKItnPm7EhSAo H8zs/oDclTLTJi8hekZJfMeXubZj08sXDee4qJRHooEHV/0vCZ6OaplVZD4+dUcoulo1/0pYG+YO 6m3vg9svUq9ZSDPh+U2gNtJqSvGBQD5LEK5/qcd2kGKfiXfIWeakPdhF5kwAAAAAAAA= --Apple-Mail-254--368815010-- From zach@sensinode.com Tue Nov 9 09:26:47 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B83B63A68FF for ; Tue, 9 Nov 2010 09:26:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.509 X-Spam-Level: X-Spam-Status: No, score=-3.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X0H0YgwwnBFB for ; Tue, 9 Nov 2010 09:26:46 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 6F4733A67F1 for ; Tue, 9 Nov 2010 09:26:46 -0800 (PST) Received: from dhcp-40a3.meeting.ietf.org (dhcp-40a3.meeting.ietf.org [130.129.64.163]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id oA9HQu9S001531 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 9 Nov 2010 19:27:01 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-255--368710289; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: Date: Wed, 10 Nov 2010 01:26:58 +0800 Message-Id: <2AA2EFA2-B0A5-466B-A757-E492B06B2DE0@sensinode.com> References: To: Peter Bigot X-Mailer: Apple Mail (2.1081) Cc: "CORE \(Constrained RESTful Environments\) WG" Subject: Re: [core] Need clarification for filter params in link format draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 17:26:47 -0000 --Apple-Mail-255--368710289 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Nov 10, 2010, at 1:18 AM, Peter Bigot wrote: > I believe "uri" was intended to provide a name that can be used to = access that portion of the link description that is called the "Target = IRI" in RFC5988. It is the one field that you might want to filter on = that is not a link-param. >=20 > Naming specific elements seems unwise, as it leads to the sorts of = other questions you raise, and there's really no reason to do so. I = suspect the rule should be: >=20 > resource-param =3D "uri" | parmname I agree, that would make more sense. That way the filter query string = could handle future link-extensions (and RFC5988 parameters) as well.=20 Zach >=20 > Peter >=20 > On Tue, Nov 9, 2010 at 11:03 AM, Linyi Tian = wrote: > Hi, Z. Shelby and all >=20 > Currently there are five params listed in the filtering section. I = doubt whether =91uri=92, =91d=92 and =91sh=92 are needed. >=20 > resource-param =3D "uri" | "d" | "sh" | "n" | "id" >=20 > I am wondering how to use these three params. It is easy to understand = the case that that requestor doesn=92t know the exact location but just = the name. If the requestor knows the URI, what has been filtered by = including the URI (uri, d, sh)? >=20 > Another question is that why =91rel=92 and =91ct=92 is not included. = The requestor may wants to know all the index nodes by adding rel param = in the query. On the other hand, the requestor may also wants to query = all the resources with content type image/jpeg. So do you think it make = sense to include =91rel=92 and =91ct? >=20 > Cheers, > Linyi >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 --Apple-Mail-255--368710289 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9 fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb 6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja 5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I 2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTEwOTE3MjY1 OFowIwYJKoZIhvcNAQkEMRYEFIM6N/chqZSWcwePCSMQo18j0AgJMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAI/dZUZ5giZMLYJ9iEyg9bhvjoVjofVkjo66FL/mSgOZjFck/pEXwhUD Tnqby7ZZMcgUL+TJshH8V0RgZgeaOtSOk7z8PeAHr9uxhaz+UlIGjS6eiSMj72QVn77QTtSsWpFK RXk5dGmGrAKH10+mbazlU2qXr5FMgofgg2J/rCL3i+2vN4FJpz3FTVeZwk3DHOl6zqldGMHEr3a8 qVw7k94Yq6qh/pn6JXc4logUDFyM8jcg9fIJGNwxzgszNHq/xltphxPwOl8aSpCUw+NEDZjTMWaQ ORXGIWLmZTCdtPIvGMgrpeOYfniQIQLdOwQyz4RNqsPp6Eta6wbumE2Aff8AAAAAAAA= --Apple-Mail-255--368710289-- From trac@tools.ietf.org Tue Nov 9 09:28:29 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBE723A68E0 for ; Tue, 9 Nov 2010 09:28:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c+uZwalJ+Uof for ; Tue, 9 Nov 2010 09:28:29 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 06B2A3A67CC for ; Tue, 9 Nov 2010 09:28:29 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PFs04-0006iu-8K; Tue, 09 Nov 2010 09:28:52 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Tue, 09 Nov 2010 17:28:52 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/70 Message-ID: <057.ed9a1127238752379f8e4e81e955aaa0@tools.ietf.org> X-Trac-Ticket-ID: 70 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] link-format #70 (new): Query string filter definition X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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 Nov 2010 17:28:29 -0000 #70: Query string filter definition Linyi Tian brought up an issue with the query string definition in link- format-01 forgetting some parameters. Peter Bigot suggested a fix for this allowing any paramter to be used in the filter query string. This ticket proposes for the definition to be changed to: resource-param = "uri" | parmname -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: link-format | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From ekr@rtfm.com Tue Nov 9 10:09:01 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB4123A6A2E for ; Tue, 9 Nov 2010 10:09:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.976 X-Spam-Level: X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ulFkDkcADUWx for ; Tue, 9 Nov 2010 10:09:01 -0800 (PST) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id B50053A6A2F for ; Tue, 9 Nov 2010 10:09:00 -0800 (PST) Received: by gwaa12 with SMTP id a12so6901gwa.31 for ; Tue, 09 Nov 2010 10:09:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.90.116.13 with SMTP id o13mr7361932agc.43.1289326165189; Tue, 09 Nov 2010 10:09:25 -0800 (PST) Received: by 10.91.78.6 with HTTP; Tue, 9 Nov 2010 10:09:25 -0800 (PST) In-Reply-To: References: Date: Tue, 9 Nov 2010 10:09:25 -0800 Message-ID: From: Eric Rescorla To: Peter Bigot Content-Type: multipart/alternative; boundary=00163616453b1370910494a2a4b5 Cc: core Subject: Re: [core] Symmetry, or Stuffing state in etag X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 18:09:01 -0000 --00163616453b1370910494a2a4b5 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Nov 9, 2010 at 9:05 AM, Peter Bigot wrote: > Then a client should follow that procedure (including checking the > responder against the target of the original request) and there's no need to > suggest that implementations are entitled to put other information in the > Token but should add a MAC if they do so. Security risk eliminated, message > size decreased, concept of what Token is for simplified. > Once again, there has been a discussion of putting other data into the token, at which point there are other issues. I'm not addressing the wisdom of that proposal, but merely the security measures which must be taken if it is to be implemneted. -Ekr --00163616453b1370910494a2a4b5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

    On Tue, Nov 9, 2010 at 9:05 AM, Peter Bi= got <pab@peop= lepowerco.com> wrote:
    Then a client should follow that procedure (including checking the responde= r against the target of the original request) and there's no need to su= ggest that implementations are entitled to put other information in the Tok= en but should add a MAC if they do so.=A0 Security risk eliminated, message= size decreased, concept of what Token is for simplified.

    Once again, there has been a discussion of= putting other data into the token, at which point there
    are othe= r issues. I'm not addressing the wisdom of that proposal, but merely th= e security
    measures which must be taken if it is to be implemneted.
    -Ekr

    =A0
    --00163616453b1370910494a2a4b5-- From darco@deepdarc.com Tue Nov 9 14:13:31 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DA143A696C for ; Tue, 9 Nov 2010 14:13:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y39yhYvW1EBV for ; Tue, 9 Nov 2010 14:13:30 -0800 (PST) Received: from mail-out4.apple.com (mail-out.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id 275B23A692E for ; Tue, 9 Nov 2010 14:13:29 -0800 (PST) Received: from relay15.apple.com (relay15.apple.com [17.128.113.54]) by mail-out4.apple.com (Postfix) with ESMTP id D3515BBBD76C; Tue, 9 Nov 2010 14:13:54 -0800 (PST) X-AuditID: 11807136-b7b3aae0000033cc-72-4cd9c7a2f81f Received: from bellatrix.apple.com (bellatrix.apple.com [17.197.13.66]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay15.apple.com (Apple SCV relay) with SMTP id 27.C3.13260.2A7C9DC4; Tue, 9 Nov 2010 14:13:54 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Robert Quattlebaum In-Reply-To: Date: Tue, 9 Nov 2010 14:13:54 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <0ED0C03C-D76C-4F8F-95C1-BC84268BEB9E@deepdarc.com> References: To: Peter Bigot X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== Cc: core Subject: Re: [core] Symmetry, or Stuffing state in etag X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 22:13:31 -0000 On Nov 9, 2010, at 9:05 AM, Peter Bigot wrote: > What I'm saying is that the intended use of Token was like Etag, and = extending it to a purpose that requires addition of a MAC to be secure = should be rejected as it is proposed only for use cases that are neither = common nor compelling. =46rom what I have gathered, there is only one proposal that has any = significant impact on the CoAP spec: To increase the valid size of the = value of a Token option from 2 bytes to a larger TBD size. I've seen a = size of 16 thrown around, which seems reasonable to me. I'm not sure why increasing the valid size of the value that this option = may carry to 16 would cause any significant additional implementation = complications, even for constrained devices. Doing so would increase the = flexibility of client implementations. One point about etags is that they are intended to be used by the client = for performing comparisons to determine if a resource has changed or = not. A server which uses the etag in such a way that would break this = behavior (which your use case seems to do) would be out-of-spec. __________________ Robert Quattlebaum Jabber: darco@deepdarc.com eMail: darco@deepdarc.com www: http://www.deepdarc.com/ From pab@peoplepowerco.com Tue Nov 9 14:37:59 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96A393A692E for ; Tue, 9 Nov 2010 14:37:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gDOKJQnzkoUz for ; Tue, 9 Nov 2010 14:37:58 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id BD8B83A6935 for ; Tue, 9 Nov 2010 14:37:57 -0800 (PST) Received: by fxm3 with SMTP id 3so1443006fxm.31 for ; Tue, 09 Nov 2010 14:38:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.101.194 with SMTP id d2mr5761109fao.88.1289342301517; Tue, 09 Nov 2010 14:38:21 -0800 (PST) Received: by 10.223.100.14 with HTTP; Tue, 9 Nov 2010 14:38:21 -0800 (PST) In-Reply-To: <0ED0C03C-D76C-4F8F-95C1-BC84268BEB9E@deepdarc.com> References: <0ED0C03C-D76C-4F8F-95C1-BC84268BEB9E@deepdarc.com> Date: Tue, 9 Nov 2010 16:38:21 -0600 Message-ID: From: Peter Bigot To: Robert Quattlebaum Content-Type: multipart/alternative; boundary=20cf3054a4ade037570494a66572 Cc: core Subject: Re: [core] Symmetry, or Stuffing state in etag X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 22:37:59 -0000 --20cf3054a4ade037570494a66572 Content-Type: text/plain; charset=ISO-8859-1 OK, valid point. Comes from trying to get tricky. Still, based on what Eric's explained, servers won't be able to securely interpret what they see in an Etag either unless CoAP increases the size of Etag to accommodate a MAC. I could probably contrive a conforming situation, but it's not really relevant at this point. I just thought to reduce the number of concepts involved by treating Etag and Token as duals. I certainly have no standing to object when other folks try to use CoAP in unintended ways, except of course that the way I want to use it has been ruled out by the pending decision not to support redirection to another end-point and/or protocol. Pity; that capability is certainly useful in the real world of web services, even if it can be a security risk if not done properly. (Kinda like embedding state in tokens.) Peter On Tue, Nov 9, 2010 at 4:13 PM, Robert Quattlebaum wrote: > One point about etags is that they are intended to be used by the client > for performing comparisons to determine if a resource has changed or not. A > server which uses the etag in such a way that would break this behavior > (which your use case seems to do) would be out-of-spec. > > __________________ > Robert Quattlebaum > Jabber: darco@deepdarc.com > eMail: darco@deepdarc.com > www: http://www.deepdarc.com/ > > > > --20cf3054a4ade037570494a66572 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable OK, valid point.=A0 Comes from trying to get tricky.=A0 Still, based on wha= t Eric's explained, servers won't be able to securely interpret wha= t they see in an Etag either unless CoAP increases the size of Etag to acco= mmodate a MAC.=A0 I could probably contrive a conforming situation, but it&= #39;s not really relevant at this point.=A0 I just thought to reduce the nu= mber of concepts involved by treating Etag and Token as duals.

    I certainly have no standing to object when other folks try to use CoAP= in unintended ways, except of course that the way I want to use it has bee= n ruled out by the pending decision not to support redirection to another e= nd-point and/or protocol.=A0 Pity; that capability is certainly useful in t= he real world of web services, even if it can be a security risk if not don= e properly.=A0 (Kinda like embedding state in tokens.)

    Peter

    On Tue, Nov 9, 2010 at 4:13 PM,= Robert Quattlebaum <darco@deepdarc.com> wrote:
    One point about etags is that they are intended to be used by the client fo= r performing comparisons to determine if a resource has changed or not. A s= erver which uses the etag in such a way that would break this behavior (whi= ch your use case seems to do) would be out-of-spec.

    __________________
    Robert Quattlebaum
    Jabber: darco@deepdarc.com
    eMail: =A0darco@deepdarc.com
    www: =A0 =A0http://w= ww.deepdarc.com/




    --20cf3054a4ade037570494a66572-- From darco@deepdarc.com Tue Nov 9 15:34:53 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D66AA3A68B0 for ; Tue, 9 Nov 2010 15:34:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3ULS9w+62Eq for ; Tue, 9 Nov 2010 15:34:52 -0800 (PST) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id C44033A6800 for ; Tue, 9 Nov 2010 15:34:52 -0800 (PST) Received: from relay15.apple.com (relay15.apple.com [17.128.113.54]) by mail-out4.apple.com (Postfix) with ESMTP id 44C65BBC3089; Tue, 9 Nov 2010 15:35:18 -0800 (PST) X-AuditID: 11807136-b7b3aae0000033cc-1e-4cd9dab6b270 Received: from bellatrix.apple.com (bellatrix.apple.com [17.197.13.66]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay15.apple.com (Apple SCV relay) with SMTP id 8F.2E.13260.6BAD9DC4; Tue, 9 Nov 2010 15:35:18 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Robert Quattlebaum In-Reply-To: Date: Tue, 9 Nov 2010 15:35:17 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0ED0C03C-D76C-4F8F-95C1-BC84268BEB9E@deepdarc.com> To: Peter Bigot X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== Cc: core Subject: Re: [core] Symmetry, or Stuffing state in etag X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 23:34:54 -0000 On Nov 9, 2010, at 2:38 PM, Peter Bigot wrote: > OK, valid point. Comes from trying to get tricky. Still, based on = what Eric's explained, servers won't be able to securely interpret what = they see in an Etag either unless CoAP increases the size of Etag to = accommodate a MAC. I could probably contrive a conforming situation, = but it's not really relevant at this point. I just thought to reduce = the number of concepts involved by treating Etag and Token as duals. Actually, after reviewing the spec, I see no explicit language which = indicates that a client can derive any useful information by comparing = etags for equality. In fact the existing language appears to imply the = contrary, so strictly speaking your example still stands---at least as = far as coap-03 is concerned. I could argue that perhaps the language in = coap-03 regarding etags should be modified a bit, but I'll leave that = for a different discussion. I think a significant distinction between etags and tokens is that = tokens are used to aide the interpretation of responses received by the = client. Etags serve no such purpose for the server, and exist solely to = determine if a resource has changed since the last time you accessed it. = These are considerably different purposes, so I don't think there is any = technical (or even aesthetic) benefits to making their definitions = symmetric in ways which are not supported by reasonable use cases. I think the most significant concern for increasing the Token size is = what sort of impact such a change would have on CoAP server = implementations, IMHO. __________________ Robert Quattlebaum Jabber: darco@deepdarc.com eMail: darco@deepdarc.com www: http://www.deepdarc.com/ From tianlinyi@huawei.com Tue Nov 9 16:58:59 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C2D93A69C6 for ; Tue, 9 Nov 2010 16:58:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.55 X-Spam-Level: * X-Spam-Status: No, score=1.55 tagged_above=-999 required=5 tests=[AWL=0.303, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ycto4wYyLZSt for ; Tue, 9 Nov 2010 16:58:58 -0800 (PST) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [58.251.152.65]) by core3.amsl.com (Postfix) with ESMTP id 16FC03A6994 for ; Tue, 9 Nov 2010 16:58:58 -0800 (PST) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LBN005HF9EXU7@szxga02-in.huawei.com> for core@ietf.org; Wed, 10 Nov 2010 08:59:21 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LBN00H4Q9EUS1@szxga02-in.huawei.com> for core@ietf.org; Wed, 10 Nov 2010 08:59:20 +0800 (CST) Received: from [130.129.117.92] (dhcp-755c.meeting.ietf.org [130.129.117.92]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LBN00FPT9EKNZ@szxml01-in.huawei.com>; Wed, 10 Nov 2010 08:59:14 +0800 (CST) Date: Wed, 10 Nov 2010 08:59:00 +0800 From: Linyi Tian In-reply-to: <2AA2EFA2-B0A5-466B-A757-E492B06B2DE0@sensinode.com> To: Zach Shelby , Peter Bigot Message-id: MIME-version: 1.0 Content-type: text/plain; charset=GB2312 Content-transfer-encoding: quoted-printable Thread-topic: [core] Need clarification for filter params in link format draft Thread-index: AcuAcnW6TdZsdbNcjUqH6qsua9nJog== User-Agent: Microsoft-Entourage/12.25.0.100505 Cc: "CORE \(Constrained RESTful Environments\) WG" Subject: Re: [core] Need clarification for filter params in link format draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 00:58:59 -0000 On 10-11-10 =C9=CF=CE=E71:26, "Zach Shelby" wrote: >=20 > On Nov 10, 2010, at 1:18 AM, Peter Bigot wrote: >=20 >> I believe "uri" was intended to provide a name that can be used to acces= s >> that portion of the link description that is called the "Target IRI" in >> RFC5988. It is the one field that you might want to filter on that is n= ot a >> link-param. >>=20 >> Naming specific elements seems unwise, as it leads to the sorts of other >> questions you raise, and there's really no reason to do so. I suspect t= he >> rule should be: >>=20 >> resource-param =3D "uri" | parmname >=20 > I agree, that would make more sense. That way the filter query string cou= ld > handle future link-extensions (and RFC5988 parameters) as well. >=20 > Zach [Linyi] Yes, this will remove my doubt about URI. Some text and reference t= o RFC5988 will be helpful. But It Is still unclear how to use "d" and "sh" In the query. Could you please provide examples to explain? >=20 >>=20 >> Peter >>=20 >> On Tue, Nov 9, 2010 at 11:03 AM, Linyi Tian wrote= : >> Hi, Z. Shelby and all >>=20 >> Currently there are five params listed in the filtering section. I doubt >> whether =A1=AEuri=A1=AF, =A1=AEd=A1=AF and =A1=AEsh=A1=AF are needed. >>=20 >> resource-param =3D "uri" | "d" | "sh" | "n" | "id" >>=20 >> I am wondering how to use these three params. It is easy to understand t= he >> case that that requestor doesn=A1=AFt know the exact location but just the n= ame. >> If the requestor knows the URI, what has been filtered by including the = URI >> (uri, d, sh)? >>=20 >> Another question is that why =A1=AErel=A1=AF and =A1=AEct=A1=AF is not included. The req= uestor >> may wants to know all the index nodes by adding rel param in the query. = On >> the other hand, the requestor may also wants to query all the resources = with >> content type image/jpeg. So do you think it make sense to include =A1=AErel=A1= =AF and >> =A1=AEct? >>=20 >> Cheers, >> Linyi >>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >>=20 >>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core From adam@nostrum.com Tue Nov 9 17:45:39 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 144753A6A25 for ; Tue, 9 Nov 2010 17:45:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s20FXF1vtfHt for ; Tue, 9 Nov 2010 17:45:38 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id A72A33A68AB for ; Tue, 9 Nov 2010 17:45:37 -0800 (PST) Received: from dhcp-634e.meeting.ietf.org (dhcp-634e.meeting.ietf.org [130.129.99.78]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id oAA1jwxI067032 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 9 Nov 2010 19:46:01 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4CD9F956.4040505@nostrum.com> Date: Wed, 10 Nov 2010 09:45:58 +0800 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Carsten Bormann References: <4CD8E3B3.7040101@nostrum.com> <19B03EA5-7261-4EEE-8633-F562A1ECC60A@tzi.org> In-Reply-To: <19B03EA5-7261-4EEE-8633-F562A1ECC60A@tzi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.99.78 is authenticated by a trusted mechanism) Cc: "CORE \(Constrained RESTful Environments\) WG" Subject: Re: [core] Tightening up unknown status code semantics X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 01:45:39 -0000 On 11/9/10 2:15 PM, Carsten Bormann wrote: > Very good point, Adam. > > CoAP uses a base-10-4 number representation, which I will use here (the second in the three digits only goes from 0 to 3, so we can encode the whole thing in a byte). > > Instead of using 6xx codes (240 base 10-10) for CoAP-specific applications, we might reserve x3x. > So the set of CoAP-specific 400-kind codes would be 430, 431, etc. > > Still works with the HTTP assignments so far: > > http://www.iana.org/assignments/http-status-codes > > If somebody really comes up with an HTTP 43x and we want to use that, we can map it to a CoAP status code. > > (And we can still use 6xx for something completely foreign to the HTTP classes, if we want to, or as an extension to the crowded 4xx field.) An alternative that might make sense -- again, taking advantage of what would be the nonsensical "0xx" status code range in HTTP -- would be something like: 1 - 9 : CoAP-specific 2xx-class responses 10 - 19: CoAP-specific 3xx-class responses 20 - 29: CoAP-specific 4xx-class responses 30 - 39: CoAP-specific 5xx-class responses Alternately, as it seems unlikely that CoAP-specific responses are unlikely to ever be in the 2xx or 3xx class, we could give ourselves more headroom by defining them as: 1 - 19: CoAP-specific 4xx-class responses 20 - 39 : CoAP-specific 5xx-class responses Thoughts? /a From robert.cragie@gridmerge.com Tue Nov 9 17:47:57 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B813C3A68AB for ; Tue, 9 Nov 2010 17:47:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.487 X-Spam-Level: X-Spam-Status: No, score=-3.487 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cjk6ZeFaKlQI for ; Tue, 9 Nov 2010 17:47:56 -0800 (PST) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id D76CA3A6904 for ; Tue, 9 Nov 2010 17:47:55 -0800 (PST) Received: from client-86-29-103-19.glfd.adsl.virginmedia.com ([86.29.103.19] helo=[192.168.1.80]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) id 1PFznQ-0000b1-7k for core@ietf.org; Wed, 10 Nov 2010 01:48:20 +0000 Message-ID: <4CD9F9E1.9030501@gridmerge.com> Date: Wed, 10 Nov 2010 01:48:17 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: core@ietf.org References: <0ED0C03C-D76C-4F8F-95C1-BC84268BEB9E@deepdarc.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040803030709070306010303" Subject: Re: [core] Symmetry, or Stuffing state in etag X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 01:47:57 -0000 This is a cryptographically signed message in MIME format. --------------ms040803030709070306010303 Content-Type: multipart/alternative; boundary="------------060205090803060103030305" This is a multi-part message in MIME format. --------------060205090803060103030305 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Comments below, bracketed by Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com On 09/11/2010 11:35 PM, Robert Quattlebaum wrote: > On Nov 9, 2010, at 2:38 PM, Peter Bigot wrote: > >> OK, valid point. Comes from trying to get tricky. Still, based on wh= at Eric's explained, servers won't be able to securely interpret what the= y see in an Etag either unless CoAP increases the size of Etag to accommo= date a MAC. I could probably contrive a conforming situation, but it's n= ot really relevant at this point. I just thought to reduce the number of= concepts involved by treating Etag and Token as duals. So are we agreed that an etag and a token are not the same? Clearly = if you abstract both concepts there are commonalities but as they stand=20 with their specific definitions they are not the same. > Actually, after reviewing the spec, I see no explicit language which in= dicates that a client can derive any useful information by comparing etag= s for equality. In fact the existing language appears to imply the contra= ry, so strictly speaking your example still stands---at least as far as c= oap-03 is concerned. I could argue that perhaps the language in coap-03 r= egarding etags should be modified a bit, but I'll leave that for a differ= ent discussion. > > I think a significant distinction between etags and tokens is that toke= ns are used to aide the interpretation of responses received by the clien= t. Etags serve no such purpose for the server, and exist solely to determ= ine if a resource has changed since the last time you accessed it. These = are considerably different purposes, so I don't think there is any techni= cal (or even aesthetic) benefits to making their definitions symmetric in= ways which are not supported by reasonable use cases. Actually that is one property which is the same in an etag and a token.=20 If you consider a server response and a subsequent client request for an = etag as analagous to the client request and subsequent response for a=20 token, the returned etag is used for matching like a token. However for=20 an etag there is implied subsequent processing regarding what will then=20 go into the acoompanying payload; this does not exist with a token. If we really want this sort of symmetry (and I'm not sure we do) then we = would probably need to have a token which is only oprionally returned.=20 That could then hold an etag. > I think the most significant concern for increasing the Token size is w= hat sort of impact such a change would have on CoAP server implementation= s, IMHO. > > __________________ > Robert Quattlebaum > Jabber: darco@deepdarc.com > eMail: darco@deepdarc.com > www: http://www.deepdarc.com/ > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --------------060205090803060103030305 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Comments below, bracketed by <RCC></RCC>

    Robert

    Robert Cragie (Pacific Gas & Electric)

    Gridmerge Ltd.
    89 Greenfield Crescent,
    Wakefield, WF4 4WA, UK
    +44 1924 910888
    +1 415 513 0064
    http://www.gridmerge.com


    On 09/11/2010 11:35 PM, Robert Quattlebaum wrote: 
    On Nov 9, 2010, at 2:38 PM, Peter Bigot wrote:


    OK, valid point.  Comes from trying to get tricky.=
  Still, based on what Eric's explained, servers won't be able to securel=
y interpret what they see in an Etag either unless CoAP increases the siz=
e of Etag to accommodate a MAC.  I could probably contrive a conforming s=
ituation, but it's not really relevant at this point.  I just thought to =
reduce the number of concepts involved by treating Etag and Token as dual=
s.
    <RCC>So are we agreed that an etag and a token are not the same? Clearly if you abstract both concepts there are commonalities but as they stand with their specific definitions they are not the same.</RCC>
    Actually, after reviewing the spec, I see no explicit language which indi=
cates that a client can derive any useful information by comparing etags =
for equality. In fact the existing language appears to imply the contrary=
, so strictly speaking your example still stands---at least as far as coa=
p-03 is concerned. I could argue that perhaps the language in coap-03 reg=
arding etags should be modified a bit, but I'll leave that for a differen=
t discussion.

I think a significant distinction between etags and tokens is that tokens=
 are used to aide the interpretation of responses received by the client.=
 Etags serve no such purpose for the server, and exist solely to determin=
e if a resource has changed since the last time you accessed it. These ar=
e considerably different purposes, so I don't think there is any technica=
l (or even aesthetic) benefits to making their definitions symmetric in w=
ays which are not supported by reasonable use cases.
    <RCC>
    Actually that is one property which is the same in an etag and a token. If you consider a server response and a subsequent client request for an etag as analagous to the client request and subsequent response for a token, the returned etag is used for matching like a token. However for an etag there is implied subsequent processing regarding what will then go into the acoompanying payload; this does not exist with a token.

    If we really want this sort of symmetry (and I'm not sure we do) then we would probably need to have a token which is only oprionally returned. That could then hold an etag.
    </RCC>


    I think the most significant concern for increasing the Token size is wha=
t sort of impact such a change would have on CoAP server implementations,=
 IMHO.

__________________
Robert Quattlebaum
Jabber: darco@deepdarc.com
eMail:  darco@deepdarc.com
www:    http://www.deepdarc.com/



_______________________________________________
core mailing list
core@=
ietf.org
https://www.ietf.org/mailman/listinfo/core
    --------------060205090803060103030305-- --------------ms040803030709070306010303 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRZTCC BN0wggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UE BhMCR0IxGzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEa MBgGA1UECgwRQ29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJV UzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUg VVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWls MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5 ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqk kqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWL eeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJ Q/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udl y/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0jBBgwFoAUoBEKIz6W8Qfs 4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQE AwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAR BgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5jb21vZG9j YS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwuY29t b2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvz bRx8NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12 jMOCAU9sAPMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxog L5dMUbtGB8SKN04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNB pEMD9O3vMyfbOeAUTibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mY HK9/FX8wggY+MIIFJqADAgECAhEAtlwUjTTxveqQY8soFvBYEjANBgkqhkiG9w0BAQUFADCB rjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEe MBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVz ZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIGFuZCBFbWFpbDAeFw0xMDA4MzAwMDAwMDBaFw0xMTA4MzAyMzU5NTlaMIHkMTUwMwYD VQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBFUlNPTkEgTk9UIFZBTElEQVRFRDFGMEQG A1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5u ZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMyBDb21vZG8gTGltaXRlZDEWMBQGA1UE AxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVy Z2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtAJ+m9Tgd3li8BgAIRth Gtth3YcCbhLPjfAcnDKcEGSrkZqao79Jg2uDW62IOwNCq9ae3VweBlvg3UUVu8upXzgDR/jF z4S1ZNk1if6V9QEiyBHdE1qMUQeeytedk3qw93CU5snWiXgVRacU8H8Dv+WJPsb4WYAH4MBz aJMI2N/E5XGGYpKFj9vxnEiQ7h83jXxw3Ee2rXCCbhJEci/tUl+Cx40pB3m7nlEdASY+A3tq JLIiG8Argf0+bWaxmuSUihKoakhHQruAylWY9EVtbKg8SACYZhdHCx2+ZSSrxbbAKSv0cDk0 0vQPvgH5GEi6zSB9QvqWCdBH/rL0XfV5jQIDAQABo4ICHTCCAhkwHwYDVR0jBBgwFoAUiYJn fcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFGkahOqOBMk95XAb8dpcRdaef8AYMA4GA1Ud DwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIx AQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzAp BggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCB mjBMoEqgSIZGaHR0cDovL2NybC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRB dXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0 L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYB BQUHAQEEYDBeMDYGCCsGAQUFBzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFD bGllbnRDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNV HREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEB ADcjSJQKgVIfD/IztFrhx2YqR9mKsDs3XakKd4hUoeunHgskiaMIQY2Kcfob48OuzrfY73rN fNoaqr5LZwDeVflMnZd0rPcTA9rAHq5l/qwdSta3k0xvBui0NAtOrSBdbqC4vggLKuZvoR2o 7mSbxSSBZHuVLObx/E5E+D5fjWC7ffNvr9y/uFXeCYFsM+Hc9VPIZ+cAY7JQFJEK/Nuti2QH IIxdR91N2vHuNXWIPROPFMl7y8ltO/fONwhxMcY2dH4JkDH6pdNzMtzykvsO0NeiRHnNlS4K A8aD9RaBR8FNQHq+JusC2tf11qdHBpHrVAK7dHodKDnbRr2t9VdrU2owggY+MIIFJqADAgEC AhEAtlwUjTTxveqQY8soFvBYEjANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJU UlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNV BAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0x MDA4MzAwMDAwMDBaFw0xMTA4MzAyMzU5NTlaMIHkMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3Qg TmV0d29yayAtIFBFUlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENv bmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0G A1UECxMWKGMpMjAwMyBDb21vZG8gTGltaXRlZDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEq MCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtAJ+m9Tgd3li8BgAIRthGtth3YcCbhLPjfAcnDKcEGSr kZqao79Jg2uDW62IOwNCq9ae3VweBlvg3UUVu8upXzgDR/jFz4S1ZNk1if6V9QEiyBHdE1qM UQeeytedk3qw93CU5snWiXgVRacU8H8Dv+WJPsb4WYAH4MBzaJMI2N/E5XGGYpKFj9vxnEiQ 7h83jXxw3Ee2rXCCbhJEci/tUl+Cx40pB3m7nlEdASY+A3tqJLIiG8Argf0+bWaxmuSUihKo akhHQruAylWY9EVtbKg8SACYZhdHCx2+ZSSrxbbAKSv0cDk00vQPvgH5GEi6zSB9QvqWCdBH /rL0XfV5jQIDAQABo4ICHTCCAhkwHwYDVR0jBBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0w HQYDVR0OBBYEFGkahOqOBMk95XAb8dpcRdaef8AYMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMB Af8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEE BAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6 Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0cDovL2Ny bC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVt YWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xp ZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQUF BzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwYB BQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRtyb2JlcnQuY3Jh Z2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBADcjSJQKgVIfD/IztFrhx2Yq R9mKsDs3XakKd4hUoeunHgskiaMIQY2Kcfob48OuzrfY73rNfNoaqr5LZwDeVflMnZd0rPcT A9rAHq5l/qwdSta3k0xvBui0NAtOrSBdbqC4vggLKuZvoR2o7mSbxSSBZHuVLObx/E5E+D5f jWC7ffNvr9y/uFXeCYFsM+Hc9VPIZ+cAY7JQFJEK/Nuti2QHIIxdR91N2vHuNXWIPROPFMl7 y8ltO/fONwhxMcY2dH4JkDH6pdNzMtzykvsO0NeiRHnNlS4KA8aD9RaBR8FNQHq+JusC2tf1 1qdHBpHrVAK7dHodKDnbRr2t9VdrU2oxggRgMIIEXAIBATCBxDCBrjELMAkGA1UEBhMCVVMx CzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVT RVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0 BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIR ALZcFI008b3qkGPLKBbwWBIwCQYFKw4DAhoFAKCCAnAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTAxMTEwMDE0ODE3WjAjBgkqhkiG9w0BCQQxFgQU6HRx TnC9dZ2suohUT0OjhHOObFowXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJV VDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4t VVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQC2XBSNNPG96pBj yygW8FgSMIHXBgsqhkiG9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgT AlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBO ZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIRALZcFI008b3q kGPLKBbwWBIwDQYJKoZIhvcNAQEBBQAEggEARJJg4bZpEwNMoAN/7xQJW1Z11ERwWfYvfcYK b41Fbu/SsuJyeuQu6vGuud9Gths5a5MqnHkGmg2X4XARjODITLVMYx91T+b7vYzi9ZqSxgsL iCZmgYsA/GLCl2xEhP3JT6pwQ+rAeMoTAl4Vb73rdLnaWqpkTDibyN1usMvaQxOH6RxFFlGh Kfis4eFO8jFMwZ7ZjMzkNR4L/fGG9k3e1X8ZSeLdhPbKhbHzIhKMhMpKgNc2YakmQDwyrrY6 qY5WXp3hVZQ81f3x52o9npOhOm0R8Il7XkiTne46QP4ACBNQmwTyR8gtjhN8n7lwHuWXertG gS9JtS1anZJo/WhUqQAAAAAAAA== --------------ms040803030709070306010303-- From adam@nostrum.com Tue Nov 9 17:51:20 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 105713A6A36 for ; Tue, 9 Nov 2010 17:51:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eWbUW94lGEev for ; Tue, 9 Nov 2010 17:51:19 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id CFA3F3A6A25 for ; Tue, 9 Nov 2010 17:51:18 -0800 (PST) Received: from dhcp-634e.meeting.ietf.org (dhcp-634e.meeting.ietf.org [130.129.99.78]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id oAA1pcFG067471 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 9 Nov 2010 19:51:40 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4CD9FAA9.6030309@nostrum.com> Date: Wed, 10 Nov 2010 09:51:37 +0800 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: robert.cragie@gridmerge.com References: <0ED0C03C-D76C-4F8F-95C1-BC84268BEB9E@deepdarc.com> <4CD9F9E1.9030501@gridmerge.com> In-Reply-To: <4CD9F9E1.9030501@gridmerge.com> Content-Type: multipart/alternative; boundary="------------030208030803030906040603" Received-SPF: pass (nostrum.com: 130.129.99.78 is authenticated by a trusted mechanism) Cc: core@ietf.org Subject: Re: [core] Symmetry, or Stuffing state in etag X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 01:51:20 -0000 This is a multi-part message in MIME format. --------------030208030803030906040603 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 11/10/10 9:48 AM, Robert Cragie wrote: > So are we agreed that an etag and a token are not the same? Yes, they're very different things. The etag is selected by the server, is opaque to the client, and corresponds to the current state of the resource. The token is selected by the client, is opaque to the server, and corresponds to a CoAP request. /a --------------030208030803030906040603 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 11/10/10 9:48 AM, Robert Cragie wrote:
    So are we agreed that an etag and a token are not the same?

    Yes, they're very different things. The etag is selected by the server, is opaque to the client, and corresponds to the current state of the resource. The token is selected by the client, is opaque to the server, and corresponds to a CoAP request.

    /a
    --------------030208030803030906040603-- From robert.cragie@gridmerge.com Tue Nov 9 17:55:37 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 252293A6A37 for ; Tue, 9 Nov 2010 17:55:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.496 X-Spam-Level: X-Spam-Status: No, score=-3.496 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gtvsMxA4jANr for ; Tue, 9 Nov 2010 17:55:35 -0800 (PST) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id 44FC33A6A26 for ; Tue, 9 Nov 2010 17:55:35 -0800 (PST) Received: from client-86-29-103-19.glfd.adsl.virginmedia.com ([86.29.103.19] helo=[192.168.1.80]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) id 1PFzuo-0006gT-9Z; Wed, 10 Nov 2010 01:55:58 +0000 Message-ID: <4CD9FBAB.4010803@gridmerge.com> Date: Wed, 10 Nov 2010 01:55:55 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Peter Bigot References: <0ED0C03C-D76C-4F8F-95C1-BC84268BEB9E@deepdarc.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010702070300020703020002" Cc: Robert Quattlebaum , core Subject: Re: [core] Symmetry, or Stuffing state in etag X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 01:55:37 -0000 This is a cryptographically signed message in MIME format. --------------ms010702070300020703020002 Content-Type: multipart/alternative; boundary="------------070408080006010205040906" This is a multi-part message in MIME format. --------------070408080006010205040906 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Comments below, bracketed by Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com On 09/11/2010 10:38 PM, Peter Bigot wrote: > OK, valid point. Comes from trying to get tricky. Still, based on=20 > what Eric's explained, servers won't be able to securely interpret=20 > what they see in an Etag either unless CoAP increases the size of Etag = > to accommodate a MAC. I could probably contrive a conforming=20 > situation, but it's not really relevant at this point. I just thought = > to reduce the number of concepts involved by treating Etag and Token=20 > as duals. That's true but the use of etags (well, formal use at least) does=20 not require it. There would be point in applying a MAC to the etag as=20 the server has no subsequent use for it beyond determining what it puts=20 in a corresponding response. All a 'malicious' client is going to do is=20 revert to the worst case re. caching, i.e. return the resource=20 representation every time. Ironically, etags are being used as tokens=20 for sneaky cookies based on browsers always caching. > > I certainly have no standing to object when other folks try to use=20 > CoAP in unintended ways, except of course that the way I want to use=20 > it has been ruled out by the pending decision not to support=20 > redirection to another end-point and/or protocol. Pity; that=20 > capability is certainly useful in the real world of web services, even = > if it can be a security risk if not done properly. (Kinda like=20 > embedding state in tokens.) > > Peter > > On Tue, Nov 9, 2010 at 4:13 PM, Robert Quattlebaum > wrote: > > One point about etags is that they are intended to be used by the > client for performing comparisons to determine if a resource has > changed or not. A server which uses the etag in such a way that > would break this behavior (which your use case seems to do) would > be out-of-spec. > > __________________ > Robert Quattlebaum > Jabber: darco@deepdarc.com > eMail: darco@deepdarc.com > www: http://www.deepdarc.com/ > > > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --------------070408080006010205040906 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Comments below, bracketed by <RCC></RCC>

    Robert

    Robert Cragie (Pacific Gas & Electric)

    Gridmerge Ltd.
    89 Greenfield Crescent,
    Wakefield, WF4 4WA, UK
    +44 1924 910888
    +1 415 513 0064
    http://www.gridmerge.com


    On 09/11/2010 10:38 PM, Peter Bigot wrote:
    OK, valid point.  Comes from trying to get trick= y.  Still, based on what Eric's explained, servers won't be able to securely interpret what they see in an Etag either unless CoAP increases the size of Etag to accommodate a MAC.  I could prob= ably contrive a conforming situation, but it's not really relevant at this point.  I just thought to reduce the number of concepts involved by treating Etag and Token as duals.
    <RCC>That's true but the use of etags (well, formal use at least) does not require it. There would be point in applying a MAC to the etag as the server has no subsequent use for it beyond determining what it puts in a corresponding response. All a 'malicious' client is going to do is revert to the worst case re. caching, i.e. return the resource representation every time. Ironically, etags are being used as tokens for sneaky cookies based on browsers always caching.</RCC>

    I certainly have no standing to object when other folks try to use CoAP in unintended ways, except of course that the way I want to use it has been ruled out by the pending decision not to support redirection to another end-point and/or protocol.  Pity; that capability is certainly useful in the real world of web services, even if it can be a security risk if not done properly.  (Kind= a like embedding state in tokens.)

    Peter

    On Tue, Nov 9, 2010 at 4:13 PM, Robert Quattlebaum <darco@deepdarc.com>= wrote:
    One point about etags is that they are intended to be used by the client for performing comparisons to determine if a resource has changed or not. A server which uses the etag in such a way that would break this behavior (which your use case seems to do) would be out-of-spec.

    __________________
    Robert Quattlebaum
    Jabber: darco@deepdarc.com eMail:  darco@deepdarc.com www:    http://= www.deepdarc.com/




    
_______________________________________________
core mailing list
core@=
ietf.org
https://www.ietf.org/mailman/listinfo/core
    --------------070408080006010205040906-- --------------ms010702070300020703020002 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRZTCC BN0wggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UE BhMCR0IxGzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEa MBgGA1UECgwRQ29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJV UzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUg VVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWls MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5 ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqk kqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWL eeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJ Q/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udl y/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0jBBgwFoAUoBEKIz6W8Qfs 4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQE AwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAR BgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5jb21vZG9j YS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwuY29t b2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvz bRx8NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12 jMOCAU9sAPMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxog L5dMUbtGB8SKN04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNB pEMD9O3vMyfbOeAUTibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mY HK9/FX8wggY+MIIFJqADAgECAhEAtlwUjTTxveqQY8soFvBYEjANBgkqhkiG9w0BAQUFADCB rjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEe MBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVz ZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIGFuZCBFbWFpbDAeFw0xMDA4MzAwMDAwMDBaFw0xMTA4MzAyMzU5NTlaMIHkMTUwMwYD VQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBFUlNPTkEgTk9UIFZBTElEQVRFRDFGMEQG A1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5u ZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMyBDb21vZG8gTGltaXRlZDEWMBQGA1UE AxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVy Z2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtAJ+m9Tgd3li8BgAIRth Gtth3YcCbhLPjfAcnDKcEGSrkZqao79Jg2uDW62IOwNCq9ae3VweBlvg3UUVu8upXzgDR/jF z4S1ZNk1if6V9QEiyBHdE1qMUQeeytedk3qw93CU5snWiXgVRacU8H8Dv+WJPsb4WYAH4MBz aJMI2N/E5XGGYpKFj9vxnEiQ7h83jXxw3Ee2rXCCbhJEci/tUl+Cx40pB3m7nlEdASY+A3tq JLIiG8Argf0+bWaxmuSUihKoakhHQruAylWY9EVtbKg8SACYZhdHCx2+ZSSrxbbAKSv0cDk0 0vQPvgH5GEi6zSB9QvqWCdBH/rL0XfV5jQIDAQABo4ICHTCCAhkwHwYDVR0jBBgwFoAUiYJn fcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFGkahOqOBMk95XAb8dpcRdaef8AYMA4GA1Ud DwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIx AQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzAp BggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCB mjBMoEqgSIZGaHR0cDovL2NybC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRB dXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0 L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYB BQUHAQEEYDBeMDYGCCsGAQUFBzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFD bGllbnRDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNV HREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEB ADcjSJQKgVIfD/IztFrhx2YqR9mKsDs3XakKd4hUoeunHgskiaMIQY2Kcfob48OuzrfY73rN fNoaqr5LZwDeVflMnZd0rPcTA9rAHq5l/qwdSta3k0xvBui0NAtOrSBdbqC4vggLKuZvoR2o 7mSbxSSBZHuVLObx/E5E+D5fjWC7ffNvr9y/uFXeCYFsM+Hc9VPIZ+cAY7JQFJEK/Nuti2QH IIxdR91N2vHuNXWIPROPFMl7y8ltO/fONwhxMcY2dH4JkDH6pdNzMtzykvsO0NeiRHnNlS4K A8aD9RaBR8FNQHq+JusC2tf11qdHBpHrVAK7dHodKDnbRr2t9VdrU2owggY+MIIFJqADAgEC AhEAtlwUjTTxveqQY8soFvBYEjANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJU UlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNV BAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0x MDA4MzAwMDAwMDBaFw0xMTA4MzAyMzU5NTlaMIHkMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3Qg TmV0d29yayAtIFBFUlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENv bmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0G A1UECxMWKGMpMjAwMyBDb21vZG8gTGltaXRlZDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEq MCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtAJ+m9Tgd3li8BgAIRthGtth3YcCbhLPjfAcnDKcEGSr kZqao79Jg2uDW62IOwNCq9ae3VweBlvg3UUVu8upXzgDR/jFz4S1ZNk1if6V9QEiyBHdE1qM UQeeytedk3qw93CU5snWiXgVRacU8H8Dv+WJPsb4WYAH4MBzaJMI2N/E5XGGYpKFj9vxnEiQ 7h83jXxw3Ee2rXCCbhJEci/tUl+Cx40pB3m7nlEdASY+A3tqJLIiG8Argf0+bWaxmuSUihKo akhHQruAylWY9EVtbKg8SACYZhdHCx2+ZSSrxbbAKSv0cDk00vQPvgH5GEi6zSB9QvqWCdBH /rL0XfV5jQIDAQABo4ICHTCCAhkwHwYDVR0jBBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0w HQYDVR0OBBYEFGkahOqOBMk95XAb8dpcRdaef8AYMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMB Af8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEE BAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6 Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0cDovL2Ny bC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVt YWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xp ZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQUF BzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwYB BQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRtyb2JlcnQuY3Jh Z2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBADcjSJQKgVIfD/IztFrhx2Yq R9mKsDs3XakKd4hUoeunHgskiaMIQY2Kcfob48OuzrfY73rNfNoaqr5LZwDeVflMnZd0rPcT A9rAHq5l/qwdSta3k0xvBui0NAtOrSBdbqC4vggLKuZvoR2o7mSbxSSBZHuVLObx/E5E+D5f jWC7ffNvr9y/uFXeCYFsM+Hc9VPIZ+cAY7JQFJEK/Nuti2QHIIxdR91N2vHuNXWIPROPFMl7 y8ltO/fONwhxMcY2dH4JkDH6pdNzMtzykvsO0NeiRHnNlS4KA8aD9RaBR8FNQHq+JusC2tf1 1qdHBpHrVAK7dHodKDnbRr2t9VdrU2oxggRgMIIEXAIBATCBxDCBrjELMAkGA1UEBhMCVVMx CzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVT RVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0 BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIR ALZcFI008b3qkGPLKBbwWBIwCQYFKw4DAhoFAKCCAnAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTAxMTEwMDE1NTU1WjAjBgkqhkiG9w0BCQQxFgQU51Mf LJQ5ID1OZm/L1E/Rmh7zlaYwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJV VDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4t VVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQC2XBSNNPG96pBj yygW8FgSMIHXBgsqhkiG9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgT AlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBO ZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIRALZcFI008b3q kGPLKBbwWBIwDQYJKoZIhvcNAQEBBQAEggEAIlORhS9l77iQB6Nh/FqOgI0fMAQx7/0ikFhR a7ctBWXypqCVnwsKxiISaNRNDdthQJKYHyZ2VMqJQrbflqdqYqmhk2HC42JhiH+C9HRB8ILe CS4U+5JSMIHygjHEc8/h0RAGH0+4vP7E75nRDQ1//v7VGheZlMha8gNod5A6fnui7yk3sCp/ z4UabxvX9iQVrs6wHbS40HDpLvLEir5GdYs56gXiCHLk3Ip04xi91LBGYjkdTO4e5diFZSqJ uZcp1tvmvvAjEYDgp1Ju648DKmL0CyqWPhWjJS9otNKo7BDmx8/Htsab+odTlhurLo9HZxe6 h9TcnwXuAp+m/Fv0TAAAAAAAAA== --------------ms010702070300020703020002-- From adam@nostrum.com Tue Nov 9 17:59:42 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66C6A3A6A44 for ; Tue, 9 Nov 2010 17:59:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FqWYCvuo1P-2 for ; Tue, 9 Nov 2010 17:59:41 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 174733A69BA for ; Tue, 9 Nov 2010 17:59:40 -0800 (PST) Received: from dhcp-235b.meeting.ietf.org (dhcp-235b.meeting.ietf.org [130.129.35.91]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id oAA202tc068124 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 9 Nov 2010 20:00:04 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4CD9FCA1.3030909@nostrum.com> Date: Wed, 10 Nov 2010 10:00:01 +0800 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Don Sturek References: <4CD7B21C.2000600@nostrum.com> <54809.3102.qm@web81406.mail.mud.yahoo.com> In-Reply-To: <54809.3102.qm@web81406.mail.mud.yahoo.com> Content-Type: multipart/alternative; boundary="------------000201070108040104080705" Received-SPF: pass (nostrum.com: 130.129.35.91 is authenticated by a trusted mechanism) Cc: "CORE \(Constrained RESTful Environments\) WG" Subject: Re: [core] Towards authc/authz user cases X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 01:59:42 -0000 This is a multi-part message in MIME format. --------------000201070108040104080705 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 11/8/10 6:24 PM, Don Sturek wrote: > I think your note below is a bad example. No electric company I know > of will allow you access homeowner to a proxy in the meter and none > (at least the US based utilities I know of) will allow un-enrolled > access to anything other than meter usage data and information on > price (and this access is authenticated for privacy reasons). If you > enroll your devices in a utility program then you could also receive > demand response messages. Really that is it in terms of services > provided by the meter......... > > Now it is true that the meter usage data, price and other information > can be used in the HAN for energy savings. The utility is not > involved in this and does not host homeowner applications within the > meter. The utility only supplies the requested data to the HAN > devices to support that application. Okay, so that point to having a separate home gateway for homeowner-controller devices. That's workable. There's still an issue of protecting the deadbolt from accepting messages from other devices on the network (which may or may not be under control of the homeowner) without authentication. We need to have some scheme to prevent this. /a --------------000201070108040104080705 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 11/8/10 6:24 PM, Don Sturek wrote:
    I think your note below is a bad example.   No electric company I know of will allow you access homeowner to a proxy in the meter and none (at least the US based utilities I know of) will allow un-enrolled access to anything other than meter usage data and information on price (and this access is authenticated for privacy reasons).  If you enroll your devices in a utility program then you could also receive demand response messages.  Really that is it in terms of services provided by the meter.........

    Now it is true that the meter usage data, price and other information can be used in the HAN for energy savings.  The utility is not involved in this and does not host homeowner applications within the meter.  The utility only supplies the requested data to the HAN devices to support that application.

    Okay, so that point to having a separate home gateway for homeowner-controller devices. That's workable. There's still an issue of protecting the deadbolt from accepting messages from other devices on the network (which may or may not be under control of the homeowner) without authentication. We need to have some scheme to prevent this.

    /a
    --------------000201070108040104080705-- From likepeng@huawei.com Tue Nov 9 18:13:11 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D5403A67E3 for ; Tue, 9 Nov 2010 18:13:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MxlGu30g1zAX for ; Tue, 9 Nov 2010 18:13:09 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [58.251.152.66]) by core3.amsl.com (Postfix) with ESMTP id 02BA13A6A32 for ; Tue, 9 Nov 2010 18:13:09 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LBN006OUCUJ29@szxga03-in.huawei.com> for core@ietf.org; Wed, 10 Nov 2010 10:13:32 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LBN001Y3CUJK2@szxga03-in.huawei.com> for core@ietf.org; Wed, 10 Nov 2010 10:13:31 +0800 (CST) Received: from MICROSOF4AFFB7 (dhcp-7525.meeting.ietf.org [130.129.117.37]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LBN00FL3CUFNZ@szxml01-in.huawei.com> for core@ietf.org; Wed, 10 Nov 2010 10:13:31 +0800 (CST) Date: Wed, 10 Nov 2010 10:16:10 +0800 From: Kepeng Li In-reply-to: <4CD9FBAB.4010803@gridmerge.com> To: 'core' Message-id: <004401cb807d$4067c180$c1374480$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_mFcEd0epblimVQYpiUPHAw)" Content-language: zh-cn Thread-index: AcuAenSNZ5JbaS3ERyyBqMKsaIcORgAAmmFw References: <0ED0C03C-D76C-4F8F-95C1-BC84268BEB9E@deepdarc.com> <4CD9FBAB.4010803@gridmerge.com> Subject: [core] Editorial Comment to Observe Draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 02:13:11 -0000 This is a multi-part message in MIME format. --Boundary_(ID_mFcEd0epblimVQYpiUPHAw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, In the COAP draft, we use "Subscription-lifetime" as the Option name, but in the Observe draft, we use "lifetime". This should be consistent. Thanks Cheers Kepeng --Boundary_(ID_mFcEd0epblimVQYpiUPHAw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

    Hi,

     

    In the COAP draft, we use “Subscription-lifetime” as the Option name, but in the Observe draft, we use “lifetime”. This should be consistent.

     

    Thanks

    Cheers

    Kepeng

    --Boundary_(ID_mFcEd0epblimVQYpiUPHAw)-- From tianlinyi@huawei.com Tue Nov 9 18:15:04 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74E483A6811 for ; Tue, 9 Nov 2010 18:15:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.619 X-Spam-Level: X-Spam-Status: No, score=0.619 tagged_above=-999 required=5 tests=[AWL=1.113, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VLnMkGaOYU24 for ; Tue, 9 Nov 2010 18:15:03 -0800 (PST) Received: from szxga05-in.huawei.com (unknown [58.251.152.67]) by core3.amsl.com (Postfix) with ESMTP id 60EF63A6A39 for ; Tue, 9 Nov 2010 18:15:03 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LBN00981CXR6Q@szxga05-in.huawei.com> for core@ietf.org; Wed, 10 Nov 2010 10:15:27 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LBN0083RCXQ7I@szxga05-in.huawei.com> for core@ietf.org; Wed, 10 Nov 2010 10:15:27 +0800 (CST) Received: from [130.129.117.92] (dhcp-755c.meeting.ietf.org [130.129.117.92]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LBN0039NCXJOM@szxml02-in.huawei.com> for core@ietf.org; Wed, 10 Nov 2010 10:15:26 +0800 (CST) Date: Wed, 10 Nov 2010 10:15:16 +0800 From: Linyi Tian To: "CORE (Constrained RESTful Environments) WG" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_3Hd+iwpV6BzJ1T7zOSVQyw)" Thread-topic: New ticket for Observe: Non-confirmable vs confirmable notification Thread-index: AcuAfR0978FgMbUN2U2H//v8VZpbvg== User-Agent: Microsoft-Entourage/12.25.0.100505 Subject: [core] New ticket for Observe: Non-confirmable vs confirmable notification X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 02:15:04 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --Boundary_(ID_3Hd+iwpV6BzJ1T7zOSVQyw) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Hi, All I just want to echo this potential new ticket. In the current draft, It Is RECOMMENDED to send non-confirmable notification by the server. In the example, It Is shown that during the lifetime, the server can switch between non-confirmable and confirmable notification. I asked the question why not just send non-confirmable notification and let the client to GET If It does want to get the status In real time. The answer I got was following: 1. If the resource changes frequently, then the non-confirmable notification would be better. 2. If the resource Is quite stable, then the confirmable notification would be better. I think this kind of description should be Included In the draft to help the server developer. It Is better to say one method Is recommended without the rationale. Cheers, Linyi --Boundary_(ID_3Hd+iwpV6BzJ1T7zOSVQyw) Content-type: text/html; charset=US-ASCII Content-transfer-encoding: 7BIT New ticket for Observe: Non-confirmable vs confirmable notification Hi, All
     
    I just want to echo this potential new ticket.

    In the current draft, It Is RECOMMENDED to send non-confirmable notification by the server. In the example, It Is shown that during the lifetime, the server can switch between non-confirmable and confirmable notification.

    I asked the question why not just send non-confirmable notification and let the client to GET If It does want to get the status In real time.

    The answer I got was following:
    1. If the resource changes frequently, then the non-confirmable notification would be better.
    2. If the resource Is quite stable, then the confirmable notification would be better.

    I think this kind of description should be Included In the draft to help the server developer. It Is better to say one method Is recommended without the rationale.

    Cheers,
    Linyi     --Boundary_(ID_3Hd+iwpV6BzJ1T7zOSVQyw)-- From zach@sensinode.com Tue Nov 9 18:37:43 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 025D23A6452 for ; Tue, 9 Nov 2010 18:37:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.517 X-Spam-Level: X-Spam-Status: No, score=-3.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kgRSqYvnDesK for ; Tue, 9 Nov 2010 18:37:41 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id C287C3A635F for ; Tue, 9 Nov 2010 18:37:40 -0800 (PST) Received: from dhcp-75ec.meeting.ietf.org (dhcp-75ec.meeting.ietf.org [130.129.117.236]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id oAA2bk1U013008 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 10 Nov 2010 04:37:51 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-292--335663344; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: <004401cb807d$4067c180$c1374480$@com> Date: Wed, 10 Nov 2010 10:37:45 +0800 Message-Id: References: <0ED0C03C-D76C-4F8F-95C1-BC84268BEB9E@deepdarc.com> <4CD9FBAB.4010803@gridmerge.com> <004401cb807d$4067c180$c1374480$@com> To: Kepeng Li X-Mailer: Apple Mail (2.1081) Cc: 'core' Subject: Re: [core] Editorial Comment to Observe Draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 02:37:43 -0000 --Apple-Mail-292--335663344 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Nov 10, 2010, at 10:16 AM, Kepeng Li wrote: > In the COAP draft, we use =93Subscription-lifetime=94 as the Option = name, but in the Observe draft, we use =93lifetime=94. This should be = consistent. Yes, we will do that. In ticket #33 the naming will be changed to = Observation-lifetime throughout the documents. We will stop using = "subscription/subscribe" all together.=20 Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 --Apple-Mail-292--335663344 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9 fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb 6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja 5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I 2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTExMDAyMzc0 NVowIwYJKoZIhvcNAQkEMRYEFB5n0jO/HFNH9u0Dbi74M5r3OF8eMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBADPMFT5DczV0Kg+s7+7TFGiPMXAvyEFMo70zJ2DQaCVwoOT59lWOvCGf VXw2CPgEq/zzCDObMjTWyvhhWup1yUotrBUy6TyxOE0NYOJ5P+bg7jWr3bVfb3WguwSRVF3+2IbG 9yneScRsDPZmaHN4BjGmYmA6IeHDg9Md3TtB1flPdDBe57MzdTaq73FgEOAcjskGtWl8DgmUdT6R SwmxcIaN7Uwj/gkao0yM097PfTkplmu91/ZTuaz0U3LEYIhoh8tycveh+z+DArmP2ZLFfcCyguVv /r+ZeB52At5qELQICrZwZTHBsGAtqyF/jrfpn/C2cTvSHVHfu4eQ11d43zMAAAAAAAA= --Apple-Mail-292--335663344-- From darco@deepdarc.com Tue Nov 9 21:38:24 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 048333A67D6 for ; Tue, 9 Nov 2010 21:38:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1awIlNVUxIRr for ; Tue, 9 Nov 2010 21:38:23 -0800 (PST) Received: from spider.nocdirect.com (spider.nocdirect.com [69.73.181.158]) by core3.amsl.com (Postfix) with ESMTP id 9EE8D3A67A3 for ; Tue, 9 Nov 2010 21:38:22 -0800 (PST) Received: from [166.135.118.159] (port=49338 helo=[10.14.248.98]) by spider.nocdirect.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1PG3O0-0001fS-VF; Wed, 10 Nov 2010 00:38:22 -0500 References: <4CD8E3B3.7040101@nostrum.com> <19B03EA5-7261-4EEE-8633-F562A1ECC60A@tzi.org> <4CD9F956.4040505@nostrum.com> In-Reply-To: <4CD9F956.4040505@nostrum.com> Mime-Version: 1.0 (iPad Mail 8C134) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (8C134) From: Robert Quattlebaum Date: Tue, 9 Nov 2010 21:38:07 -0800 To: Adam Roach X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - spider.nocdirect.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - deepdarc.com Cc: "CORE \(Constrained RESTful Environments\) WG" Subject: Re: [core] Tightening up unknown status code semantics X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 05:38:24 -0000 I may be misunderstanding, but wouldn't this then conflict with method codes= ? On Nov 9, 2010, at 5:45 PM, Adam Roach wrote: > On 11/9/10 2:15 PM, Carsten Bormann wrote: >> Very good point, Adam. >>=20 >> CoAP uses a base-10-4 number representation, which I will use here (the s= econd in the three digits only goes from 0 to 3, so we can encode the whole t= hing in a byte). >>=20 >> Instead of using 6xx codes (240 base 10-10) for CoAP-specific application= s, we might reserve x3x. >> So the set of CoAP-specific 400-kind codes would be 430, 431, etc. >>=20 >> Still works with the HTTP assignments so far: >>=20 >> http://www.iana.org/assignments/http-status-codes >>=20 >> If somebody really comes up with an HTTP 43x and we want to use that, we c= an map it to a CoAP status code. >>=20 >> (And we can still use 6xx for something completely foreign to the HTTP cl= asses, if we want to, or as an extension to the crowded 4xx field.) >=20 > An alternative that might make sense -- again, taking advantage of what wo= uld be the nonsensical "0xx" status code range in HTTP -- would be something= like: >=20 > 1 - 9 : CoAP-specific 2xx-class responses > 10 - 19: CoAP-specific 3xx-class responses > 20 - 29: CoAP-specific 4xx-class responses > 30 - 39: CoAP-specific 5xx-class responses >=20 > Alternately, as it seems unlikely that CoAP-specific responses are unlikel= y to ever be in the 2xx or 3xx class, we could give ourselves more headroom b= y defining them as: >=20 > 1 - 19: CoAP-specific 4xx-class responses > 20 - 39 : CoAP-specific 5xx-class responses >=20 > Thoughts? >=20 > /a > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 From cabo@tzi.org Tue Nov 9 22:11:04 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 444C93A691C for ; Tue, 9 Nov 2010 22:11:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SNFGLm5Xnm96 for ; Tue, 9 Nov 2010 22:11:02 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 56EB93A693A for ; Tue, 9 Nov 2010 22:10:48 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id oAA6An43013401; Wed, 10 Nov 2010 07:10:49 +0100 (CET) Received: from dhcp-67f2.meeting.ietf.org (dhcp-67f2.meeting.ietf.org [130.129.103.242]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 1ED0E37D; Wed, 10 Nov 2010 07:10:47 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Wed, 10 Nov 2010 14:10:44 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4CD8E3B3.7040101@nostrum.com> <19B03EA5-7261-4EEE-8633-F562A1ECC60A@tzi.org> <4CD9F956.4040505@nostrum.com> To: Robert Quattlebaum X-Mailer: Apple Mail (2.1081) Cc: "CORE \(Constrained RESTful Environments\) WG" Subject: Re: [core] Tightening up unknown status code semantics X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 06:11:04 -0000 On Nov 10, 2010, at 13:38, Robert Quattlebaum wrote: > I may be misunderstanding, but wouldn't this then conflict with method = codes? Yes, it would. We may not need to reserve all 40 values allocated for methode codes = now, though. (I'd rather use this as extension space if the 43x codes run out. =20 But we have to decide that now. So how about using 03x as an extension space to 43x? =20 More complexity. Hmm.) Gruesse, Carsten From behcetsarikaya@yahoo.com Tue Nov 9 22:55:38 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 894563A69A3 for ; Tue, 9 Nov 2010 22:55:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KY1OH5e7860k for ; Tue, 9 Nov 2010 22:55:37 -0800 (PST) Received: from nm24.bullet.mail.sp2.yahoo.com (nm24.bullet.mail.sp2.yahoo.com [98.139.91.94]) by core3.amsl.com (Postfix) with SMTP id C1AC63A6996 for ; Tue, 9 Nov 2010 22:55:37 -0800 (PST) Received: from [98.139.91.65] by nm24.bullet.mail.sp2.yahoo.com with NNFMP; 10 Nov 2010 06:56:00 -0000 Received: from [98.139.91.29] by tm5.bullet.mail.sp2.yahoo.com with NNFMP; 10 Nov 2010 06:56:00 -0000 Received: from [127.0.0.1] by omp1029.mail.sp2.yahoo.com with NNFMP; 10 Nov 2010 06:56:00 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 728121.52932.bm@omp1029.mail.sp2.yahoo.com Received: (qmail 80326 invoked by uid 60001); 10 Nov 2010 06:56:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1289372160; bh=WGa00kpahenDda2i1C7w0/zJRyFD9VVeuQ/DdymiXe0=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=hcsIEvybWhRgvq+CusnVvsc9gD1uCDmAMDEVgE3aYDymyCzGEmQakQwZq2PDjL8BBOBl4LBpxqdyFeTT/eJntjjK+nVnCeysZZu2CvrUno6loX47lBQVUxhJ4VC/wIp4EjuKo8Vd1inQUk9kERL6YrIvrxddlouSwHztqBHsn70= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=rcWmwrKh9R8eeLL8DkFxd32oE9W8Q9HQNT3YcI87tVDFSUHrlTuU1h9Em0+B+nKifDc/qH9jv1zxbXWZWNrCu+JBxkFx5mSdpT/mrhdypxxzT2jlJFjXDJDd3L05a2PjDJIpVGc3o8nTStIiRJgfnJHUYqwQwOQldnaGNGm8+wI=; Message-ID: <421997.73823.qm@web111415.mail.gq1.yahoo.com> X-YMail-OSG: fkeHA28VM1nGFaQDXNA8PL6u2ocnq7C1.1X9.gAdN4Y0eGb tfahFCDYWm65Td.bEzvmE7oabpZ5r9oixnn32k8NpFUgsPZR6pZFv_IdDebZ RZo0LsuI4NGEQoGjioXG8UcfmS_j73fHwWIJt30xqwqwmRjjbT7ShP1btqvW D8UgVPLLYkCHlytpquZTTA1jlxQtC1jfyuHxc1bZaKbhaqA9HiNVP_GLsVrk PKPvMqLwtzpm8t3MKpQNHmZFeTIODYCn.sdnj4AOncfDuSZbvPGO0S3lmhjo ttlpPck6IUR5_OG5izA_aDdFYHWSHu_t..ltkZw4XLwOWrOZw5JXdZNzy_I. noeNiCDR_mcW3j8qjp68K3y6PyKS.t.CzZJZwR54PhJQ- Received: from [130.129.131.75] by web111415.mail.gq1.yahoo.com via HTTP; Tue, 09 Nov 2010 22:56:00 PST X-Mailer: YahooMailRC/504.5 YahooMailWebService/0.8.107.284920 Date: Tue, 9 Nov 2010 22:56:00 -0800 (PST) From: Behcet Sarikaya To: core MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [core] Fw: New Version Notification for draft-sarikaya-core-sbootstrapping-00 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 06:55:38 -0000 Folks, this is the latest version of security bootstrapping draft as Colin asked to be removed from the author list. Regards Behcet ----- Forwarded Message ---- > From: IETF I-D Submission Tool > To: sarikaya@ieee.org > Cc: yoshihiro.ohba@toshiba.co.jp; caozhen@chinamobile.com; >robert.cragie@gridmerge.com > Sent: Wed, November 10, 2010 12:52:46 AM > Subject: New Version Notification for >draft-sarikaya-core-sbootstrapping-00 > > > > A new version of I-D, draft-sarikaya-core-sbootstrapping-00.txt has been >successfully submitted by Behcet Sarikaya and posted to the IETF repository. > > Filename: draft-sarikaya-core-sbootstrapping > Revision: 00 > Title: Security Bootstrapping of Resource-Constrained Devices > Creation_date: 2010-11-10 > WG ID: Independent Submission > Number_of_pages: 25 > > Abstract: > The Internet of Things is marching its way towards completion. Nodes > can use standards from the 6LoWPAN and ROLL WG to achieve IP > connectivity. IEEE Standards ensure connectivity at lower layers for > resource-constrained devices. Yet a central problem remains at a > more basic layer without a suitable answer: how to initially > configure the network. Without configuration the network never > advances beyond a large box of nodes. Current solutions tend to be > specific to a certain vendor, node type, or application. > > This document outlines exactly what problems are faced in solving > this problem. General problems faced in any low-power wireless > network are outlined first; followed by how these apply to > bootstrapping. A selection of currently proposed techniques is > presented. From these a more generic approach is presented, which > can solve the problem for a wide range of situations. > > An emphasis is on performing this bootstrapping in a secure manner. > This document does not cover operation of the network securely. This > document does provide the basis for allowing the network to operate > securely however, by providing standard methods for key exchanges and > authentication. > > > > > > The IETF Secretariat. > > > From matthieu.vial@fr.non.schneider-electric.com Wed Nov 10 02:06:43 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C1AC3A6807; Wed, 10 Nov 2010 02:06:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.178 X-Spam-Level: X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 37fmvHG5WPo2; Wed, 10 Nov 2010 02:06:37 -0800 (PST) Received: from mailX03.eud.schneider-electric.com (mailx03.eud.schneider-electric.com [205.167.7.41]) by core3.amsl.com (Postfix) with ESMTP id 45A3F3A6A81; Wed, 10 Nov 2010 02:06:37 -0800 (PST) Received: from ateui02.Schneider-Electric.com ([10.198.14.10]) by mailX03.eud.schneider-electric.com with ESMTP id 2010111010531771-180150 ; Wed, 10 Nov 2010 10:53:17 +0100 In-Reply-To: <053.44399fd645fe2aa7d70a9c84cb0da595@tools.ietf.org> To: hartke@tzi.org X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: matthieu.vial@fr.non.schneider-electric.com Date: Wed, 10 Nov 2010 11:07:10 +0100 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on ATEUI02.Schneider-Electric.com/T/SVR/Schneider at 10/11/2010 11:06:56, Itemize by SMTP Server on AXEU3OUT.schneider-electric.com/X/SVR/SEIxtra at 10/11/2010 10:53:17, Serialize by Router on AXEU3OUT.schneider-electric.com/X/SVR/SEIxtra at 10/11/2010 10:53:19 Content-type: multipart/related; Boundary="0__=4EBBFD44DFBE7C628f9e8a93df938690918c4EBBFD44DFBE7C62" Cc: core-bounces@ietf.org, core@ietf.org Subject: [core] RE observe #66 (new): Identifying observations X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 10:06:43 -0000 --0__=4EBBFD44DFBE7C628f9e8a93df938690918c4EBBFD44DFBE7C62 Content-type: multipart/alternative; Boundary="1__=4EBBFD44DFBE7C628f9e8a93df938690918c4EBBFD44DFBE7C62" --1__=4EBBFD44DFBE7C628f9e8a93df938690918c4EBBFD44DFBE7C62 Content-transfer-encoding: quoted-printable Content-type: text/plain; charset=ISO-8859-1 Hi Klaus, I understand that a token is not a valid identifier for an observation.= >From the text in coap-3 the lifetime of a token seems to be request-response(s) but the lifetime of an observation can span over multiple requests. However the size of URI + IP + port is 0(scheme?)+27= 0 (authority)+270(path)+270(query)+16(IP)+2(port) =3D 828 bytes ! Storing= 828 bytes seems unadapted to constrained devices. Guido Moritz suggested a = new identifier named EventID that could help to create a relation between a= n obsvervation and the requests required to manage the lifetime of that observation. Moreover the current text in coap-observe-0 section 2.1 specify that th= e token MAY be included. But as I understand coap-3 the token option is a= MUST for asynchronous responses. And in a way coap-observe is just mult= iple asynchronous responses. Do you think the text should be changed ? One last question. Imagine an observer creating an observation through = a proxy. For example a 6lowpan IPv6-only client wants notifications from = an IPv4 only server through a dual stack proxy. How the proxy can identify= the observer from the notification messages ? The proxy could store the con= text of the observer during the lifetime of the observation just like the or= igin server. Also many proxied requests may appear with the same tuple (URI,address,port) from the server point of view. Maybe this use case should be clarified. Regards, Matthieu = "core issue = tracker" = hartke@tzi.org = Envoy=E9 par : = cc core-bounces@ietf core@ietf.org = .org Ob= jet [core] observe #66 (new): = Identifying observations = 09/11/2010 17:37 = = = = = = #66: Identifying observations It should be clarified that an observation is identified by the URI of= the observed resource and the the IP address + port of the observer. A token submitted by the observer must not be used by the server to identify an observation; observation requests from the same observer t= o the same resource must update/replace any ongoing observation, even if= the token has changed. -- ----------------------------+------------------------------------------= ----- Reporter: hartke@? | Owner: hartke@? Type: defect | Status: new Priority: minor | Milestone: Component: observe | Version: Severity: - | Keywords: ----------------------------+------------------------------------------= ----- Ticket URL: core _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________ = --1__=4EBBFD44DFBE7C628f9e8a93df938690918c4EBBFD44DFBE7C62 Content-transfer-encoding: quoted-printable Content-type: text/html; charset=ISO-8859-1 Content-Disposition: inline

    Hi Klaus,

    I understand that a token is not a valid identifier for an observation.= From the text in coap-3 the lifetime of a token seems to be request-re= sponse(s) but the lifetime of an observation can span over multiple req= uests. However the size of URI + IP + port is 0(scheme?)+270(authority)= +270(path)+270(query)+16(IP)+2(port) =3D 828 bytes ! Storing 828 bytes = seems unadapted to constrained devices. Guido Moritz suggested a new id= entifier named EventID that could help to create a relation between an = obsvervation and the requests required to manage the lifetime of that o= bservation.

    Moreover the current text in coap-observe-0 section 2.1 specify that th= e token MAY be included. But as I understand coap-3 the token option is= a MUST for asynchronous responses. And in a way coap-observe is just m= ultiple asynchronous responses. Do you think the text should be changed= ?

    One last question. Imagine an observer creating an observation through = a proxy. For example a 6lowpan IPv6-only client wants notifications fro= m an IPv4 only server through a dual stack proxy. How the proxy can ide= ntify the observer from the notification messages ? The proxy could sto= re the context of the observer during the lifetime of the observation j= ust like the origin server. Also many proxied requests may appear with = the same tuple (URI,address,port) from the server point of view. Maybe = this use case should be clarified.

    Regards,
    Matthieu

    3D"Inactive"core issue tracker" <trac@tools.ie= tf.org>




    =
            "core issue tracker" <trac@tools.i= etf.org>
            Envoy=E9 par : core-bounces@ietf.org

            09/11/2010 17:37

    		 =
    3D""
    A
    		3D""
    hartke@tzi.org
    3D""
    cc
    		3D""
    core@ietf.org
    3D""
    Objet
    		3D""
    [core] observe #66 (new): Identifying observations
    3D""3D=

    #66: Identifying observations

    It should be clarified that an observation is identified by the URI of= the
    observed resource and the the IP address + port of the observer.
    A token submitted by the observer must not be used by the server to identify an observation; observation requests from the same observer t= o
    the same resource must update/replace any ongoing observation, even if= the
    token has changed.

    --
    ----------------------------+------------------------------------------= -----
    Reporter:  hartke@…        |   &nb= sp;   Owner:  hartke@…      
        Type:  defect          | &= nbsp;    Status:  new          =
    Priority:  minor           |   Mile= stone:                
    Component:  observe         |     Ve= rsion:                
    Severity:  -               | &= nbsp;  Keywords:               =  
    ----------------------------+------------------------------------------= -----

    Ticket URL: <    http://trac.tools.ietf.org/wg/core/trac/ticket/66>
    core <    http://tools.= ietf.org/core/>

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

    ______________________________________________________________________<= br> This email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________<= br>
    = --1__=4EBBFD44DFBE7C628f9e8a93df938690918c4EBBFD44DFBE7C62-- --0__=4EBBFD44DFBE7C628f9e8a93df938690918c4EBBFD44DFBE7C62 Content-type: image/gif; name="pic19976.gif" Content-Disposition: inline; filename="pic19976.gif" Content-ID: <1__=4EBBFD44DFBE7C628@Schneider-Electric.com> Content-Transfer-Encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --0__=4EBBFD44DFBE7C628f9e8a93df938690918c4EBBFD44DFBE7C62-- From cabo@tzi.org Wed Nov 10 02:42:23 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E15F43A6901; Wed, 10 Nov 2010 02:42:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id giVRMHUAiS8C; Wed, 10 Nov 2010 02:42:18 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id D28593A6826; Wed, 10 Nov 2010 02:42:17 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id oAAAgZmb014262; Wed, 10 Nov 2010 11:42:35 +0100 (CET) Received: from dhcp-67f2.meeting.ietf.org (dhcp-67f2.meeting.ietf.org [130.129.103.242]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 2A807544; Wed, 10 Nov 2010 11:42:32 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Wed, 10 Nov 2010 18:42:29 +0800 Content-Transfer-Encoding: 7bit Message-Id: <42598F1B-B6C1-4DAB-861C-00B3C499021F@tzi.org> References: To: matthieu.vial@fr.non.schneider-electric.com X-Mailer: Apple Mail (2.1081) Cc: core@ietf.org, core-bounces@ietf.org, hartke@tzi.org Subject: Re: [core] RE observe #66 (new): Identifying observations X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 10:42:23 -0000 On Nov 10, 2010, at 18:07, matthieu.vial@fr.non.schneider-electric.com wrote: > Storing 828 bytes seems unadapted to constrained devices. Then don't do that. You don't *have* to use ridiculously large URIs. Gruesse, Carsten From robert.cragie@gridmerge.com Wed Nov 10 03:07:12 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C281E3A6A17 for ; Wed, 10 Nov 2010 03:07:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.504 X-Spam-Level: X-Spam-Status: No, score=-3.504 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XvZ-+UhSfnK9 for ; Wed, 10 Nov 2010 03:07:09 -0800 (PST) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id 402333A69FC for ; Wed, 10 Nov 2010 03:07:09 -0800 (PST) Received: from client-86-29-103-19.glfd.adsl.virginmedia.com ([86.29.103.19] helo=[192.168.1.80]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) id 1PG8WZ-0001fn-3p; Wed, 10 Nov 2010 11:07:31 +0000 Message-ID: <4CDA7CF0.6060605@gridmerge.com> Date: Wed, 10 Nov 2010 11:07:28 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Adam Roach References: <4CD7B21C.2000600@nostrum.com> <54809.3102.qm@web81406.mail.mud.yahoo.com> <4CD9FCA1.3030909@nostrum.com> In-Reply-To: <4CD9FCA1.3030909@nostrum.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040305050909000508020205" Cc: "CORE \(Constrained RESTful Environments\) WG" Subject: Re: [core] Towards authc/authz user cases X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 11:07:12 -0000 This is a cryptographically signed message in MIME format. --------------ms040305050909000508020205 Content-Type: multipart/alternative; boundary="------------070004030106010605010205" This is a multi-part message in MIME format. --------------070004030106010605010205 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Comments below RCC On 10/11/2010 2:00 AM, Adam Roach wrote: > On 11/8/10 6:24 PM, Don Sturek wrote: >> I think your note below is a bad example. No electric company I=20 >> know of will allow you access homeowner to a proxy in the meter and=20 >> none (at least the US based utilities I know of) will allow=20 >> un-enrolled access to anything other than meter usage data and=20 >> information on price (and this access is authenticated for privacy=20 >> reasons). If you enroll your devices in a utility program then you=20 >> could also receive demand response messages. Really that is it in=20 >> terms of services provided by the meter......... >> >> Now it is true that the meter usage data, price and other information = >> can be used in the HAN for energy savings. The utility is not=20 >> involved in this and does not host homeowner applications within the=20 >> meter. The utility only supplies the requested data to the HAN=20 >> devices to support that application. > > Okay, so that point to having a separate home gateway for=20 > homeowner-controller devices. That's workable. There's still an issue=20 > of protecting the deadbolt from accepting messages from other devices=20 > on the network (which may or may not be under control of the=20 > homeowner) without authentication. We need to have some scheme to=20 > prevent this. Absolutely. The model proposed in Open HAN 2.0=20 (http://osgug.ucaiug.org/sgsystems/openhan/Shared%20Documents/OpenHAN%202= =2E0/UCAIug%20HAN%20SRS%20-%20v2.0.pdf)=20 supports this and that is what I would propose > > /a > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --------------070004030106010605010205 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Comments below

    RCC

    On 10/11/2010 2:00 AM, Adam Roach wrote:

    On 11/8/10 6:24 PM, Don Sturek wrote:
    I think your note below is a bad example.   No e= lectric company I know of will allow you access homeowner to a proxy in the meter and none (at least the US based utilities I know of) will allow un-enrolled access to anything other than meter usage data and information on price (and this access is authenticated for privacy reasons).  If you en= roll your devices in a utility program then you could also receive demand response messages.  Really that is it in terms of services provided by the meter.........

    Now it is true that the meter usage data, price and other information can be used in the HAN for energy savings.  = The utility is not involved in this and does not host homeowner applications within the meter.  The utility only supplie= s the requested data to the HAN devices to support that application.

    Okay, so that point to having a separate home gateway for homeowner-controller devices. That's workable. There's still an issue of protecting the deadbolt from accepting messages from other devices on the network (which may or may not be under control of the homeowner) without authentication. We need to have some scheme to prevent this.
    <RCC>Absolutely. The model proposed in Open HAN 2.0 (http://osgug.ucaiug.org/sgsystems/openhan/Shared%20Documents/= OpenHAN%202.0/UCAIug%20HAN%20SRS%20-%20v2.0.pdf) supports this and that is what I would propose</RCC>
    =
    /a
    
_______________________________________________
core mailing list
core@=
ietf.org
https://www.ietf.org/mailman/listinfo/core
    --------------070004030106010605010205-- --------------ms040305050909000508020205 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRZTCC BN0wggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UE BhMCR0IxGzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEa MBgGA1UECgwRQ29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJV UzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUg VVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWls MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5 ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqk kqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWL eeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJ Q/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udl y/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0jBBgwFoAUoBEKIz6W8Qfs 4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQE AwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAR BgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5jb21vZG9j YS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwuY29t b2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvz bRx8NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12 jMOCAU9sAPMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxog L5dMUbtGB8SKN04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNB pEMD9O3vMyfbOeAUTibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mY HK9/FX8wggY+MIIFJqADAgECAhEAtlwUjTTxveqQY8soFvBYEjANBgkqhkiG9w0BAQUFADCB rjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEe MBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVz ZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIGFuZCBFbWFpbDAeFw0xMDA4MzAwMDAwMDBaFw0xMTA4MzAyMzU5NTlaMIHkMTUwMwYD VQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBFUlNPTkEgTk9UIFZBTElEQVRFRDFGMEQG A1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5u ZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMyBDb21vZG8gTGltaXRlZDEWMBQGA1UE AxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVy Z2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtAJ+m9Tgd3li8BgAIRth Gtth3YcCbhLPjfAcnDKcEGSrkZqao79Jg2uDW62IOwNCq9ae3VweBlvg3UUVu8upXzgDR/jF z4S1ZNk1if6V9QEiyBHdE1qMUQeeytedk3qw93CU5snWiXgVRacU8H8Dv+WJPsb4WYAH4MBz aJMI2N/E5XGGYpKFj9vxnEiQ7h83jXxw3Ee2rXCCbhJEci/tUl+Cx40pB3m7nlEdASY+A3tq JLIiG8Argf0+bWaxmuSUihKoakhHQruAylWY9EVtbKg8SACYZhdHCx2+ZSSrxbbAKSv0cDk0 0vQPvgH5GEi6zSB9QvqWCdBH/rL0XfV5jQIDAQABo4ICHTCCAhkwHwYDVR0jBBgwFoAUiYJn fcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFGkahOqOBMk95XAb8dpcRdaef8AYMA4GA1Ud DwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIx AQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzAp BggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCB mjBMoEqgSIZGaHR0cDovL2NybC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRB dXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0 L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYB BQUHAQEEYDBeMDYGCCsGAQUFBzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFD bGllbnRDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNV HREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEB ADcjSJQKgVIfD/IztFrhx2YqR9mKsDs3XakKd4hUoeunHgskiaMIQY2Kcfob48OuzrfY73rN fNoaqr5LZwDeVflMnZd0rPcTA9rAHq5l/qwdSta3k0xvBui0NAtOrSBdbqC4vggLKuZvoR2o 7mSbxSSBZHuVLObx/E5E+D5fjWC7ffNvr9y/uFXeCYFsM+Hc9VPIZ+cAY7JQFJEK/Nuti2QH IIxdR91N2vHuNXWIPROPFMl7y8ltO/fONwhxMcY2dH4JkDH6pdNzMtzykvsO0NeiRHnNlS4K A8aD9RaBR8FNQHq+JusC2tf11qdHBpHrVAK7dHodKDnbRr2t9VdrU2owggY+MIIFJqADAgEC AhEAtlwUjTTxveqQY8soFvBYEjANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJU UlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNV BAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0x MDA4MzAwMDAwMDBaFw0xMTA4MzAyMzU5NTlaMIHkMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3Qg TmV0d29yayAtIFBFUlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENv bmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0G A1UECxMWKGMpMjAwMyBDb21vZG8gTGltaXRlZDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEq MCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtAJ+m9Tgd3li8BgAIRthGtth3YcCbhLPjfAcnDKcEGSr kZqao79Jg2uDW62IOwNCq9ae3VweBlvg3UUVu8upXzgDR/jFz4S1ZNk1if6V9QEiyBHdE1qM UQeeytedk3qw93CU5snWiXgVRacU8H8Dv+WJPsb4WYAH4MBzaJMI2N/E5XGGYpKFj9vxnEiQ 7h83jXxw3Ee2rXCCbhJEci/tUl+Cx40pB3m7nlEdASY+A3tqJLIiG8Argf0+bWaxmuSUihKo akhHQruAylWY9EVtbKg8SACYZhdHCx2+ZSSrxbbAKSv0cDk00vQPvgH5GEi6zSB9QvqWCdBH /rL0XfV5jQIDAQABo4ICHTCCAhkwHwYDVR0jBBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0w HQYDVR0OBBYEFGkahOqOBMk95XAb8dpcRdaef8AYMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMB Af8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEE BAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6 Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0cDovL2Ny bC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVt YWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xp ZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQUF BzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwYB BQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRtyb2JlcnQuY3Jh Z2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBADcjSJQKgVIfD/IztFrhx2Yq R9mKsDs3XakKd4hUoeunHgskiaMIQY2Kcfob48OuzrfY73rNfNoaqr5LZwDeVflMnZd0rPcT A9rAHq5l/qwdSta3k0xvBui0NAtOrSBdbqC4vggLKuZvoR2o7mSbxSSBZHuVLObx/E5E+D5f jWC7ffNvr9y/uFXeCYFsM+Hc9VPIZ+cAY7JQFJEK/Nuti2QHIIxdR91N2vHuNXWIPROPFMl7 y8ltO/fONwhxMcY2dH4JkDH6pdNzMtzykvsO0NeiRHnNlS4KA8aD9RaBR8FNQHq+JusC2tf1 1qdHBpHrVAK7dHodKDnbRr2t9VdrU2oxggRgMIIEXAIBATCBxDCBrjELMAkGA1UEBhMCVVMx CzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVT RVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0 BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIR ALZcFI008b3qkGPLKBbwWBIwCQYFKw4DAhoFAKCCAnAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTAxMTEwMTEwNzI4WjAjBgkqhkiG9w0BCQQxFgQUbLsr KQR0osSuMvE6ltBK7rWOvREwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJV VDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4t VVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQC2XBSNNPG96pBj yygW8FgSMIHXBgsqhkiG9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgT AlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBO ZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIRALZcFI008b3q kGPLKBbwWBIwDQYJKoZIhvcNAQEBBQAEggEAbhfaL+S/aO+THM1m1KBcXQjOvqumOfzkKbyo NtH+prO+1F3OnKoyU8pSHUatn7yVdD1U5ES56VZ7EsON4jEoZJEQ0fVe8OUFkoHHTuxZDkm7 mmt4MGcstqVrluecpk0w9RePXyF1OBkz19mBTv6vvvZw0awRLxuBQz8QlHQQtqywJVMCFbdo K2d9fiLbAEnbFWxIwKo7eL2W5G6F9BTpOfsIQ6Rkt7Seo1dk9UPegYwpmdy+inAbmhQd4BPN 43W8YPzAFdro54H6G4cu123r5AmthOJsUxxgCsPW3oxUoapVzqc2wJdDWHtphKCrwHSmnadp czWpC2dNkh83C05vGgAAAAAAAA== --------------ms040305050909000508020205-- From rstruik.ext@gmail.com Wed Nov 10 06:08:27 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7662F28C0EC for ; Wed, 10 Nov 2010 06:08:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZcUnm2mmxpL for ; Wed, 10 Nov 2010 06:08:25 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id AB83C3A6983 for ; Wed, 10 Nov 2010 06:08:24 -0800 (PST) Received: by yxh35 with SMTP id 35so1501yxh.31 for ; Wed, 10 Nov 2010 06:08:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type; bh=HK4zDujbCprQEpsbV2xLZF8+5TrhZmcUInXsddcldb0=; b=YNWrvLvbNafG0tSlu7tkiJ/UASWPRVSOEPjrA1KGwy3GzgMRKriHwRmkX7JIu/dg3t VNrcp0t3YH56Xg9IvJuKr3RoYxcFfErco1AMvikXVrEBVRtyO6qy1bxPJyT7wnmnfVrH nmzJMP77MXONVFuiv+QQ5BUeJbMnLRJr1vHj4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; b=OeEyPyJavx1iJhiF14LUrwAPnI9GGmT61A0jPwl+v005bRrjAzZyKY/7lCVZ6Z69+r WfLyfu/0zge7tKE0XBh8xDVjxfWat/2nz0dVjYEfeBM4Rgc2OQzu5/XQZwa3j1xf7vT4 JbnIi3vxT+94RihYsVEiIkCqyv1lxsWV4w3CU= Received: by 10.100.105.16 with SMTP id d16mr4888420anc.219.1289398131188; Wed, 10 Nov 2010 06:08:51 -0800 (PST) Received: from [10.61.37.211] (67.110.80.10.ptr.us.xo.net [67.110.80.10]) by mx.google.com with ESMTPS id c1sm890978and.39.2010.11.10.06.08.50 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 10 Nov 2010 06:08:50 -0800 (PST) Message-ID: <4CDAA76B.5080805@gmail.com> Date: Wed, 10 Nov 2010 09:08:43 -0500 From: Rene Struik User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: core References: <935DB371-B149-486A-8AD2-3B4454C9B172@tzi.org> <4CA3BB54.8050706@gmail.com> <4CA5E8E0.4030503@gmail.com> <4CA6095F.6040403@gmail.com> <4CB48B9B.9010206@gmail.com> <4CC83F61.5060109@gmail.com> In-Reply-To: <4CC83F61.5060109@gmail.com> Content-Type: multipart/alternative; boundary="------------020500050108070009070002" Subject: [core] bootstrapping concerns still remain all (was Re: concerns re draft-oflynn-core-bootstrapping-02) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 14:08:27 -0000 This is a multi-part message in MIME format. --------------020500050108070009070002 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Dear colleagues: I did a quick comparison of draft-oflynn-core-bootstrapping-02 and draft-oflynn-core-bootstrapping-03; unfortunately, my major overall concerns expressed in my email as of Wed October 27, 2010 ff still stand. NOTE: draft-03, which was posted two days ago has been reposted a few hours ago as draft-sarikaya-core-sbootstrapping-00, since it apparently lost of the main authors of previous versions. Some preliminary feedback: 0) main difference with draft-oflynn-core-bootstrapping-02 and draft-oflynn-core-bootstrapping-03 is in Section 5.1 only 1) Detailed analysis of deployment scenarios is still missing (since no changes to Appendix A - examples). 2) Security services to be offered still needs far more detail (I provided an initial list on September 29, 2010, after the CoAP Conf Call on desired properties and had *many* email exchanges on this in context of HIP protocol, but do not really see this reflected. 3) Consideration for security policies and trust management aspects is virtually not there. 4) It is entirely unclear whether one can rely on a globally unique (and thereby unchanging id) -- cf. e.g. language in Section 5.1. It is unclear what the statement that one MUST support various tyypes of identities means, whether "various" could mean "1" and how one can bind the various identities, so as to allow conversion between theses and mapping this to a static globally unique id. 5) Multi-domain support: in my mind, intention should be that a device may be part of more than one network at the same time and be able to move from one to the next while maintaining part of its state. 6) Authentication/authhorization: An online connectivity to the "trust center" (a ZigBee term) is assumed. In many cases, this online connectivity is simply not there -- one of the main characteristics of sensor-style networks is that one cannot always assume connectivity to security management functionality, esp. if centralized. It seems that the centralized ZigBee model has been written-in without any explanation as to why this would cover deployment scenarios (which, by itself, reiterates importance to study deployment scenarios in detail. 7) The PANA Section does not describe what PANA accomplishes and section is littered with references to external standards (C12.22), without explanation of how things fit together, whether security framework and design philosophy match/are complementary, etc., etc. Moreover, as already mentioned, not clear at all what the security policy and trust management framework is. 8) The need for HIP is, after at least 10 email communications still entirely unclear. Moreover entanglement of name space and crypto space is still an issue. Most questions posed over the last month resulted in comments that one could support/ameliorite better properties, more efficiencies, disentanglement as work-of-progress items for next version of HI/HIP-DEX. In my mind, this indicates immaturity and (for now) unsuitability for standardization. 9) The sections on PANA, HIP, 802.1x seem to be more text fillers, since do not provide any motivation or allow one to grasp concepts behind things. As Cullen Jennings already articulated in his initial feedback: it is completely unclear how one would build to this. I can provide more feedback once back from the current IEEE 802 meeting. Best regards, Rene On 27/10/2010 11:04 AM, Rene Struik wrote: > Dear colleagues: > > I had a brief look at the bootstrapping draft > (draft-oflynn-core-bootstrapping-02. Some comments below (I am having > some offline discussions on this, but thought to send this to the list > as well): > > I miss a detailed analysis of deployment scenarios to be considered as > guidance intodesign, so as to have as very minimal benchmark whether > all those crypto protocols actually enable the deployment scenarios > one has in mind. To me, it seems to have merit to discuss the whole > spectrum and end up with cryptographic building blocks, security > protocols, and security policies and accompanying enforcement > mechanism for trust policies that would fit the operational scenarios. > > I would favor not sprinkling protocol acronyms into any draft too > early (since, in my mind, this pushes into a particular direction, and > notalways with merit). As an example, right now I do not see how, > e.g., HIP or cryptographically generated addresses (802.1-like) would > fit in.Similarly, e.g., PANA does not seem to work in heterogeneous > trustenvironments, assumes online connectivity of a "mothership" node, > and does not seem to include consideration of how to move from one > mothership node to the next (or, e.g., if one has an authenticator, > how to make this work with single-hop/MAC security). > > I also miss security objectives and design considerations, such as > "separation of concern" and no entanglement of concepts from different > disciplines in the document. > > BTW - I mentioned some of this in email correspondence after the last > CoRE conf call (Wed September 29, 2010). So far, I have not seen too > much traffic on this. Moreover, I have not seen any adequate answers > as to what makes, e.g., HIP features an attractive fit for CoRE-like > environments. > > Best regards, Rene > > [excerpt email RS as of October 1, 2010, 12:16pm EDT] > > In my mind, properties of suitable authenticated key agreement schemes > should include (a) key establishment; (b) implicit key authentication; > (c) key confirmation; (d) mutual entity authentication; (e) forward > secrecy; (f) {perhaps} some more esoteric properties (key compromise > impersonation resilience, etc.). > > Moreover, the "name space" (device identifiers) and the "cryptographic > space" (public keys, etc.) should be independent, so that this would > allow trust lifecycle management to be reduced to proper management of > device identifiers (i.e., *no* entanglement of concepts from different > disciplines). > > > On 12/10/2010 12:23 PM, Rene Struik wrote: >> Hi Tobias: >> >> Thanks for your note. >> >> Does your "ascii art" description, Step 1)-3) allow the scenario, where (a) one assigns a node id and imprints this (e.g., blowing fuse during chip testing); >> (b) has a node generating its own long-term public/private key pair and outputting its node id and public key (e.g., during chip testing -- this would >> correspond to registering a public key with an RA); (c) have CA create a certificate in different process and return this value at later production/ >> personalization stage? >> >> Right now, from Section 4.1.3 of draft-ietf-hip-rfc5201-bis-02, I get the impression that HIP does execute an authenticated DH key agreement scheme. If so, >> this makes me wonder how HIP differentiates from protocols, such as ECMQV and, e.g., HMQV, which are all not that much more expensive than ECDH. If the >> difference is in the "puzzle" element, couldn't one just add something similar to a well-known authenticated scheme that is already standardized with, e.g., >> NIST? >> >> As to forward secrecy: reason to include this is that many sensor-type nodes can be expected to be physically unprotected (e.g., screwed on a street lamp >> post, on a garage roof, etc.) and, therefore, may be more vulnerable to device compromise over time (esp. since one cannot expect all nodes to be tamper >> resistant or tamper evident). By virtue of forward secrecy, compromise over time does not compromise the whole device's history, but only the current set of >> symmetric keys (note: I make some shortcuts in my reasoning on key management here). Admittedly, my list of security properties is based on "desired" >> functionality and does not exclude functionality that may require, e.g., public-key crypto constructs. However, from a user's perspective, the only thing that >> matters is features and not what is "under the hood", as long as that is not cost-prohibitive (which I contend it is not -- cf., e.g., Section 3.2 of >> draft-struik-6lowapp-security-considerations-00). (BTW - All other desired security properties I listed have an underlying rationale.) >> >> It would help to have a succinct mathematical description of the protocol you suggest (stripped from formatting issues) and describe claimed cryptographic >> properties. I would be happy to give this a look and review. >> >> Please feel free to provide to me in person if this would be cumbersome material for non-crypto people on the mailing list. >> >> Best regards, Rene >> >> >> [excerpt email RS as of October 1, 2010, 12:16pm EDT and response Tobias Heer as of October 7, 2010, 5:36am EDT] >> >> To aid clarity and succinct discussions, it would help to have a clear description of desired security services to be offered by an authenticated >> key agreement scheme and see whether a candidate scheme (such as, who knows, HIP) satisfies these. If you could provide a succinct description of >> the HIP protocol itself, so that this is easy to understand, and could provide what properties it has, that would be of great help! >> > >> > In my mind, properties of suitable authenticated key agreement schemes should include (a) key establishment; (b) implicit key authentication; >> (c) key confirmation; (d) mutual entity authentication; (e) forward secrecy; (f) {perhaps} some more esoteric properties (key compromise >> impersonation resilience, etc.). >> > >> Is this list valid for all targeted use cases? If yes, it is a very handy list to check against. However, (e) forward secrecy seems to >> rule a number of "cheaper" cryptographic approaches (e.g., pre-shared keys) and might not be relevant to all use cases (especially small >> setups). However, I am not absolutely firm with the envisaged scenarios in CORE. >>> > Moreover, the "name space" (device identifiers) and the "cryptographic space" (public keys, etc.) should be independent, so that this would >>> allow trust lifecycle management to be reduced to proper management of device identifiers (i.e.,*no* entanglement of concepts from different >>> disciplines). >> >> Does the "*no* entanglement of concepts from different disciplines" also mean that a concept like the id/loc split should be used to avoid >> entanglement of routing and naming? >> >> >> >> >> >> On 07/10/2010 5:36 AM, Tobias Heer wrote: >>>> To aid clarity and succinct discussions, it would help to have a clear description of desired security services to be offered by an authenticated key agreement scheme and see whether a candidate scheme (such as, who knows, HIP) satisfies these. If you could provide a succinct description of the HIP protocol itself, so that this is easy to understand, and could provide what properties it has, that would be of great help! >>>> > >>>> > In my mind, properties of suitable authenticated key agreement schemes should include (a) key establishment; (b) implicit key authentication; (c) key confirmation; (d) mutual entity authentication; (e) forward secrecy; (f) {perhaps} some more esoteric properties (key compromise impersonation resilience, etc.). >>>> > >>> Is this list valid for all targeted use cases? If yes, it is a very handy list to check against. However, (e) forward secrecy seems to rule a number of "cheaper" cryptographic approaches (e.g., pre-shared keys) and might not be relevant to all use cases (especially small setups). However, I am not absolutely firm with the envisaged scenarios in CORE. >>> >>>> > Moreover, the "name space" (device identifiers) and the "cryptographic space" (public keys, etc.) should be independent, so that this would allow trust lifecycle management to be reduced to proper management of device identifiers (i.e.,*no* entanglement of concepts from different disciplines). >>> >>> Does the "*no* entanglement of concepts from different disciplines" also mean that a concept like the id/loc split should be used to avoid entanglement of routing and naming? >>> >> >> >> -- >> email:rstruik.ext@gmail.com >> Skype: rstruik >> cell: +1 (647) 867-5658 >> USA Google voice: +1 (415) 690-7363 > > > -- > email:rstruik.ext@gmail.com > Skype: rstruik > cell: +1 (647) 867-5658 > USA Google voice: +1 (415) 690-7363 -- email: rstruik.ext@gmail.com Skype: rstruik cell: +1 (647) 867-5658 USA Google voice: +1 (415) 690-7363 --------------020500050108070009070002 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Dear colleagues:

    I did a quick comparison of draft-oflynn-core-bootstrapping-02 and draft-oflynn-core-bootstrapping-03; unfortunately, my major overall concerns expressed in my email as of Wed October 27, 2010 ff still stand. NOTE: draft-03, which was posted two days ago has been reposted a few hours ago as draft-sarikaya-core-sbootstrapping-00, since it apparently lost of the main authors of previous versions.

    Some preliminary feedback:
    0) main difference with draft-oflynn-core-bootstrapping-02 and draft-oflynn-core-bootstrapping-03 is in Section 5.1 only
    1) Detailed analysis of deployment scenarios is still missing (since no changes to Appendix A - examples).
    2) Security services to be offered still needs far more detail (I provided an initial list on September 29, 2010, after the CoAP Conf Call on desired properties and had *many* email exchanges on this in context of HIP protocol, but do not really see this reflected.
    3) Consideration for security policies and trust management aspects is virtually not there.
    4) It is entirely unclear whether one can rely on a globally unique (and thereby unchanging id) -- cf. e.g. language in Section 5.1. It is unclear what the statement that one MUST support various tyypes of identities means, whether "various" could mean "1" and how one can bind the various identities, so as to allow conversion between theses and mapping this to a static globally unique id.
    5) Multi-domain support: in my mind, intention should be that a device may be part of more than one network at the same time and be able to move from one to the next while maintaining part of its state.
    6) Authentication/authhorization: An online connectivity to the "trust center" (a ZigBee term) is assumed. In many cases, this online connectivity is simply not there -- one of the main characteristics of sensor-style networks is that one cannot always assume connectivity to security management functionality, esp. if centralized. It seems that the centralized ZigBee model has been written-in without any explanation as to why this would cover deployment scenarios (which, by itself, reiterates importance to study deployment scenarios in detail.
    7) The PANA Section does not describe what PANA accomplishes and section is littered with references to external standards (C12.22), without explanation of how things fit together, whether security framework and design philosophy match/are complementary, etc., etc. Moreover, as already mentioned, not clear at all what the security policy and trust management framework is.
    8) The need for HIP is, after at least 10 email communications still entirely unclear. Moreover entanglement of name space and crypto space is still an issue. Most questions posed over the last month resulted in comments that one could support/ameliorite better properties, more efficiencies, disentanglement as work-of-progress items for next version of HI/HIP-DEX. In my mind, this indicates immaturity and (for now) unsuitability for standardization.
    9) The sections on PANA, HIP, 802.1x seem to be more text fillers, since do not provide any motivation or allow one to grasp concepts behind things. As Cullen Jennings already articulated in his initial feedback: it is completely unclear how one would build to this.

    I can provide more feedback once back from the current IEEE 802 meeting.

    Best regards, Rene



    On 27/10/2010 11:04 AM, Rene Struik wrote:
    Dear colleagues:

    I had a brief look at the bootstrapping draft (draft-oflynn-core-bootstrapping-02. Some comments below (I am having some offline discussions on this, but thought to send this to the list as well):

    I miss a detailed analysis of deployment scenarios to be considered as guidance into design, so as to have as very minimal benchmark whether all those crypto protocols actually enable the deployment scenarios one has in mind. To me, it seems to have merit to discuss the whole spectrum and end up with cryptographic building blocks, security protocols, and security policies and accompanying enforcement mechanism for trust policies that would fit the operational scenarios.

    I would favor not sprinkling protocol acronyms into any draft too early (since, in my mind, this pushes into a particular direction, and not always with merit). As an example, right now I do not see how, e.g., HIP or cryptographically generated addresses (802.1-like) would fit in. Similarly, e.g., PANA does not seem to work in heterogeneous trust environments, assumes online connectivity of a "mothership" node, and does not seem to include consideration of how to move from one  mothership node to the next (or, e.g., if one has an authenticator, how to make this work with single-hop/MAC security).

    I also miss security objectives and design considerations, such as "separation of concern" and no entanglement of concepts from different disciplines in the document.

    BTW - I mentioned some of this in email correspondence after the last CoRE conf call (Wed September 29, 2010). So far, I have not seen too much traffic on this. Moreover, I have not seen any adequate answers as to what makes, e.g., HIP features an attractive fit for CoRE-like environments.

    Best regards, Rene

    [excerpt email RS as of October 1, 2010, 12:16pm EDT]

    In my mind, properties of suitable authenticated key agreement schemes should include (a) key establishment; (b) implicit key authentication; (c) key confirmation; (d) mutual entity authentication; (e) forward secrecy; (f) {perhaps} some more esoteric properties (key compromise impersonation resilience, etc.).

    Moreover, the "name space" (device identifiers) and the "cryptographic space" (public keys, etc.) should be independent, so that this would allow trust lifecycle management to be reduced to proper management of device identifiers (i.e., *no* entanglement of concepts from different disciplines).


    On 12/10/2010 12:23 PM, Rene Struik wrote: 
    Hi Tobias:

Thanks for your note. 

Does your "ascii art" description, Step 1)-3) allow the scenario, where (a) one assigns a node id and imprints this (e.g., blowing fuse during chip testing); 
(b) has a node generating its own long-term public/private key pair and outputting its node id and public key (e.g., during chip testing -- this would 
correspond to registering a public key with an RA); (c) have CA create a certificate in different process and return this value at later production/
personalization stage?

Right now, from Section 4.1.3 of draft-ietf-hip-rfc5201-bis-02, I get the impression that HIP does execute an authenticated DH key agreement scheme. If so,
this makes me wonder how HIP differentiates from protocols, such as ECMQV and, e.g., HMQV, which are all not that much more expensive than ECDH. If the 
difference is in the "puzzle" element, couldn't one just add something similar to a well-known authenticated scheme that is already standardized with, e.g., 
NIST?

As to forward secrecy: reason to include this is that many sensor-type nodes can be expected to be physically unprotected (e.g., screwed on a street lamp 
post, on a garage roof, etc.) and, therefore, may be more vulnerable to device compromise over time (esp. since one cannot expect all nodes to be tamper 
resistant or tamper evident). By virtue of forward secrecy, compromise over time does not compromise the whole device's history, but only the current set of
symmetric keys (note: I make some shortcuts in my reasoning on key management here). Admittedly, my list of security properties is based on "desired" 
functionality and does not exclude functionality that may require, e.g., public-key crypto constructs. However, from a user's perspective, the only thing that
matters is features and not what is "under the hood", as long as that is not cost-prohibitive (which I contend it is not -- cf., e.g., Section 3.2 of
draft-struik-6lowapp-security-considerations-00). (BTW - All other desired security properties I listed have an underlying rationale.)

It would help to have a succinct mathematical description of the protocol you suggest (stripped from formatting issues) and describe claimed cryptographic
properties. I would be happy to give this a look and review. 

Please feel free to provide to me in person if this would be cumbersome material for non-crypto people on the mailing list.

Best regards, Rene


[excerpt email RS as of October 1, 2010, 12:16pm EDT and response Tobias Heer as of October 7, 2010, 5:36am EDT]

To aid clarity and succinct discussions, it would help to have a clear description of desired security services to be offered by an authenticated 
key agreement scheme and see whether a candidate scheme (such as, who knows, HIP) satisfies these. If you could provide a succinct description of 
the HIP protocol itself, so that this is easy to understand, and could provide what properties it has, that would be of great help!
> 
> In my mind, properties of suitable authenticated key agreement schemes should include (a) key establishment; (b) implicit key authentication; 
(c) key confirmation; (d) mutual entity authentication; (e) forward secrecy; (f) {perhaps} some more esoteric properties (key compromise 
impersonation resilience, etc.).
>
    Is this list valid for all targeted use cases? If yes, it is a very handy list to check against. However, (e) forward secrecy seems to 
rule a number of "cheaper" cryptographic approaches (e.g., pre-shared keys) and might not be relevant to all use cases (especially small 
setups). However, I am not absolutely firm with the envisaged scenarios in CORE.

    > Moreover, the "name space" (device identifiers) and the "cryptographic space" (public keys, etc.) should be independent, so that this would 
    allow trust lifecycle management to be reduced to proper management of device identifiers (i.e., *no* entanglement of concepts from different 
    disciplines).

     
Does the "*no* entanglement of concepts from different disciplines" also mean that a concept like the id/loc split should be used to avoid 
entanglement of routing and naming?




    On 07/10/2010 5:36 AM, Tobias Heer wrote: 
    To aid clarity and succinct discussions, it would help to have a clear description of desired security services to be offered by an authenticated key agreement scheme and see whether a candidate scheme (such as, who knows, HIP) satisfies these. If you could provide a succinct description of the HIP protocol itself, so that this is easy to understand, and could provide what properties it has, that would be of great help!
> 
> In my mind, properties of suitable authenticated key agreement schemes should include (a) key establishment; (b) implicit key authentication; (c) key confirmation; (d) mutual entity authentication; (e) forward secrecy; (f) {perhaps} some more esoteric properties (key compromise impersonation resilience, etc.).
> 

    Is this list valid for all targeted use cases? If yes, it is a very handy list to check against. However, (e) forward secrecy seems to rule a number of "cheaper" cryptographic approaches (e.g., pre-shared keys) and might not be relevant to all use cases (especially small setups). However, I am not absolutely firm with the envisaged scenarios in CORE.


    > Moreover, the "name space" (device identifiers) and the "cryptographic space" (public keys, etc.) should be independent, so that this would allow trust lifecycle management to be reduced to proper management of device identifiers (i.e., *no* entanglement of concepts from different disciplines).

     
Does the "*no* entanglement of concepts from different disciplines" also mean that a concept like the id/loc split should be used to avoid entanglement of routing and naming?




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


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


    -- 
email: rstruik.ext@gmail.com
Skype: rstruik
cell: +1 (647) 867-5658
USA Google voice: +1 (415) 690-7363
    --------------020500050108070009070002-- From adam@nostrum.com Wed Nov 10 06:59:49 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D20503A69CD for ; Wed, 10 Nov 2010 06:59:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jnF49ysawhwp for ; Wed, 10 Nov 2010 06:59:48 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 1E8C63A68DA for ; Wed, 10 Nov 2010 06:59:47 -0800 (PST) Received: from dhcp-48c3.meeting.ietf.org (dhcp-48c3.meeting.ietf.org [130.129.72.195]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id oAAF007k033829 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 10 Nov 2010 09:00:02 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4CDAB36F.8000407@nostrum.com> Date: Wed, 10 Nov 2010 22:59:59 +0800 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Robert Quattlebaum References: <4CD8E3B3.7040101@nostrum.com> <19B03EA5-7261-4EEE-8633-F562A1ECC60A@tzi.org> <4CD9F956.4040505@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.72.195 is authenticated by a trusted mechanism) Cc: "CORE \(Constrained RESTful Environments\) WG" Subject: Re: [core] Tightening up unknown status code semantics X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 14:59:49 -0000 Gack. You're right. I forgot to look before I proposed this, and for some reason I had it in my head that this field was set to 0 for requests. Okay, so we're back into the 6xx range (or taking over the upper end of the normal 4xx and 5xx ranges). That is, unless, we want to limit ourselves to a maximum of 20 methods, and take 20-29 for 4xx-like codes and 30-39 for 5xx-like codes. /a On 11/10/10 1:38 PM, Robert Quattlebaum wrote: > I may be misunderstanding, but wouldn't this then conflict with method codes? > > On Nov 9, 2010, at 5:45 PM, Adam Roach wrote: > >> On 11/9/10 2:15 PM, Carsten Bormann wrote: >>> Very good point, Adam. >>> >>> CoAP uses a base-10-4 number representation, which I will use here (the second in the three digits only goes from 0 to 3, so we can encode the whole thing in a byte). >>> >>> Instead of using 6xx codes (240 base 10-10) for CoAP-specific applications, we might reserve x3x. >>> So the set of CoAP-specific 400-kind codes would be 430, 431, etc. >>> >>> Still works with the HTTP assignments so far: >>> >>> http://www.iana.org/assignments/http-status-codes >>> >>> If somebody really comes up with an HTTP 43x and we want to use that, we can map it to a CoAP status code. >>> >>> (And we can still use 6xx for something completely foreign to the HTTP classes, if we want to, or as an extension to the crowded 4xx field.) >> An alternative that might make sense -- again, taking advantage of what would be the nonsensical "0xx" status code range in HTTP -- would be something like: >> >> 1 - 9 : CoAP-specific 2xx-class responses >> 10 - 19: CoAP-specific 3xx-class responses >> 20 - 29: CoAP-specific 4xx-class responses >> 30 - 39: CoAP-specific 5xx-class responses >> >> Alternately, as it seems unlikely that CoAP-specific responses are unlikely to ever be in the 2xx or 3xx class, we could give ourselves more headroom by defining them as: >> >> 1 - 19: CoAP-specific 4xx-class responses >> 20 - 39 : CoAP-specific 5xx-class responses >> >> Thoughts? >> >> /a >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> From cabo@tzi.org Wed Nov 10 07:02:56 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B74E3A69D2 for ; Wed, 10 Nov 2010 07:02:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R3o5lCPkeXEu for ; Wed, 10 Nov 2010 07:02:54 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 7FBE13A69CD for ; Wed, 10 Nov 2010 07:02:53 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id oAAF3AIP013608 for ; Wed, 10 Nov 2010 16:03:10 +0100 (CET) Received: from dhcp-67f2.meeting.ietf.org (dhcp-67f2.meeting.ietf.org [130.129.103.242]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id BBA7A72B; Wed, 10 Nov 2010 16:03:09 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <523C7286-C01F-4AD0-A4E7-3E61AE7F9991@cisco.com> Date: Wed, 10 Nov 2010 23:03:05 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <4B3B33CA-DE0B-476E-9B5F-B06C678136AF@tzi.org> References: <523C7286-C01F-4AD0-A4E7-3E61AE7F9991@cisco.com> To: X-Mailer: Apple Mail (2.1081) Subject: [core] Plugfest continuation on Thursday X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 15:02:56 -0000 This has been announced in the WG meeting, but not explicitly on the = mailing list: We will have an informal second edition of the CoAP Plugfest on Thursday = at 1530 Beijing time in the Shangri-La terminal room (Lotus, in Garden = Wing Level 2). 1530 Beijing time is 0830 CET/0930 EET, so this time the Europeans will = have less of a hard time joining in remotely. (On the other hand, much = of the US will already sleep.) Focus will be on finishing Sunday's block test and getting more pairs of = observe done, but of course everyone is welcome to test what is = important to them. Those onsite are likely to converge on a dinner later. You can prepare (find servers etc.) at: http://trac.tools.ietf.org/wg/core/trac/wiki/PlugFest Don't miss the CoAP resource directory server: http://184.106.150.250 (more details on the above wiki page). Gruesse, Carsten From klaus.hartke@googlemail.com Wed Nov 10 07:07:58 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DB7D3A6851 for ; Wed, 10 Nov 2010 07:07:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yzoGEpewl-Pb for ; Wed, 10 Nov 2010 07:07:56 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 3FBA23A6A1E for ; Wed, 10 Nov 2010 07:07:56 -0800 (PST) Received: by fxm3 with SMTP id 3so472352fxm.31 for ; Wed, 10 Nov 2010 07:08:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; bh=qON+FVLj+tdExN1bk4M7ISMW8FUqCbWhov6CRjGoVh8=; b=Lk4fzDREpL08RqGDWIPm0fsPvjGhtQ9RdrZYOJ9TQ+kseK3M3y1DLAqWqVIux4RCC1 3EYqoNhbg+zwAZgoQn6t1lg+y3UNsppgaNymJ+TcwynBeSiASiZijc3vcepIWxUZ8ZOj 4ovafWegGKtpjWz/fBM5S9WDzHgQyVpHIAs9I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=XtVjXwCxhVZFwsxEDvyHTdz/5ZBC8VQkFPUMavLOZ/LshkX8VZ/xf9PelHmRAYGh6s IHjghecwdlbBA1gkJEdF8KlKT4zn1/OcNcFHyYFR/xDlc7lagbbJ7PIv4pSk2BfGmbb5 LG8wSSstEdoUXPtMAsk/Jad0c7wmofRoi+Gus= MIME-Version: 1.0 Received: by 10.204.127.94 with SMTP id f30mr8225014bks.1.1289401701783; Wed, 10 Nov 2010 07:08:21 -0800 (PST) Sender: klaus.hartke@googlemail.com Received: by 10.204.121.134 with HTTP; Wed, 10 Nov 2010 07:08:21 -0800 (PST) In-Reply-To: References: <053.44399fd645fe2aa7d70a9c84cb0da595@tools.ietf.org> Date: Wed, 10 Nov 2010 16:08:21 +0100 X-Google-Sender-Auth: _pQgVNX_ffTabspce9-WgI5nVPA Message-ID: From: Klaus Hartke To: core@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [core] RE observe #66 (new): Identifying observations X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 15:07:58 -0000 matthieu.vial@fr.non.schneider-electric.com wrote: > I understand that a token is not a valid identifier for an observation. F= rom the text in coap-3 the lifetime of a token seems to be request-response= (s) but the lifetime of an observation can span over multiple requests. Right. Illustrating example: C: GET /light (token=3D0xab6f) (observation-lifetime=3D60s) S: 200 (token=3D0xab6f) (observation-lifetime=3D60s) "..." S: 200 (token=3D0xab6f) (observation-lifetime=3D32s) "..." S: 200 (token=3D0xab6f) (observation-lifetime=3D11s) "..." C: GET /light (token=3D0x1b80) (observation-lifetime=3D60s) S: 200 (token=3D0x1b80) (observation-lifetime=3D59s) "..." S: 200 (token=3D0x1b80) (observation-lifetime=3D57s) "..." ... > However the size of URI + IP + port is 0(scheme?)+270(authority)+270(path= )+270(query)+16(IP)+2(port) =3D 828 bytes ! Storing 828 bytes seems unadapt= ed to constrained devices. As someone pointed out somewhere else, the scheme, authority and path are likely to be stored somewhere already, so it's probably more something like 4(pointer to resource)+270(query)+16(IP address)+2(port)+4(remaining lifetime) =3D 296 bytes. A constrained device that doesn't serve any parametrizable resources doesn't have to reserve space for queries, then it's something like 4(pointer to resource)+0(query)+16(IP address)+2(port)+4(remaining lifetime) =3D 26 bytes. I think that's reasonable. > Guido Moritz suggested a new identifier named EventID that could help to = create a relation between an obsvervation and the requests required to mana= ge the lifetime of that observation. If I read his mail correctly, the advantage of the EventID is that requests to extend the lifetime of an observation don't need to reiterate the URI of the subject in the request. That saves a few bytes in the messages, but introduces additional state at both the server and the client which hurts when it gets out of sync. What I like about the current solution is that, in the case the server and the client disagree about the state of the observation, the client can simply synchronize the conversation state by sending a request to extend the lifetime of an observation (which is indistinguishable from a plain observation request) and everything is well again. > Moreover the current text in coap-observe-0 section 2.1 specify that the = token MAY be included. But as I understand coap-3 the token option is a MUS= T for asynchronous responses. And in a way coap-observe is just multiple as= ynchronous responses. Do you think the text should be changed ? Yes, -observe currently doesn't reflect the wording in -coap. That needs to be fixed. > One last question. Imagine an observer creating an observation through a = proxy. For example a 6lowpan IPv6-only client wants notifications from an I= Pv4 only server through a dual stack proxy. How the proxy can identify the = observer from the notification messages ? The proxy could store the context= of the observer during the lifetime of the observation just like the origi= n server. Also many proxied requests may appear with the same tuple (URI,ad= dress,port) from the server point of view. Maybe this use case should be cl= arified. The idea is that, when multiple clients observe the same resource through a proxy, the proxy creates a single observation and notifies all clients when it receives a notification from the server. The proxy doesn't need to observe the same resource multiple times, because the single observation will already make sure that the proxy receives the current state of the resource whenever it changes. Klaus From prvs=3930033F59=guido.moritz@uni-rostock.de Wed Nov 10 08:21:31 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C58513A6A15 for ; Wed, 10 Nov 2010 08:21:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.72 X-Spam-Level: X-Spam-Status: No, score=-0.72 tagged_above=-999 required=5 tests=[AWL=-0.329, BAYES_20=-0.74, DOS_OUTLOOK_TO_MX=1, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cGqyMjf4islI for ; Wed, 10 Nov 2010 08:21:30 -0800 (PST) Received: from mailrelay1.uni-rostock.de (mailrelay1.uni-rostock.de [139.30.8.201]) by core3.amsl.com (Postfix) with ESMTP id 0929A3A6AC7 for ; Wed, 10 Nov 2010 08:18:54 -0800 (PST) From: Guido Moritz To: 'core' References: <053.44399fd645fe2aa7d70a9c84cb0da595@tools.ietf.org> In-Reply-To: Date: Wed, 10 Nov 2010 17:19:24 +0100 Message-ID: <003701cb80f3$0a1a5fe0$1e4f1fa0$@uni-rostock.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHKr+wEnqYn8xM8chFbTLKPemRGKgI9rosGAl5j0qyTR6CNsA== Content-Language: de Subject: Re: [core] RE observe #66 (new): Identifying observations X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 16:21:31 -0000 > > Guido Moritz suggested a new identifier named EventID that could help to > create a relation between an obsvervation and the requests required to > manage the lifetime of that observation. > > If I read his mail correctly, the advantage of the EventID is that > requests to extend the lifetime of an observation don't need to > reiterate the URI of the subject in the request. That saves a few > bytes in the messages, but introduces additional state at both the > server and the client which hurts when it gets out of sync. The advantage is a very simple assignment of the messages to the subscription. This applies for all messages, the subscription management (lifetime refresh, unsubscribe, ...) and for notifications as well. Without pushing this discussion in a too theoretical corner, I would argue Sub/Not is always stateful at both sides. A server must be aware to send a Not if a resource changes, so the server has a state (subscribers, queries, ...). A client has a state as well, because it must be aware of retrieving a Not and correctly handling it. > > What I like about the current solution is that, in the case the server > and the client disagree about the state of the observation, the client > can simply synchronize the conversation state by sending a request to > extend the lifetime of an observation (which is indistinguishable from > a plain observation request) and everything is well again. In case a server goes down and up again the subscription might be lost. So there is no other chance for a client to subscribe again after not retrieving any notifications. In case a client goes down and retrieves an unknown EventID, the client may ask the server to send the resource+query to the client to get in sync again. The client also may cancel the subscription with the unknown EventID and subscribe again. This would be one more round trip in case of a lost subscription, but the EventID approach might save numerous bytes especially for frequent notifications. If we assume that the resources to subscribe to have a short path and only short queries, the current approach is fine. But for frequent notifications with only slightly complex querries, the EventID might result in much more compact messages and might reduce the required RAM on servers side. Guido From matthieu.vial@fr.non.schneider-electric.com Wed Nov 10 09:03:52 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F261D3A689A; Wed, 10 Nov 2010 09:03:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.588 X-Spam-Level: X-Spam-Status: No, score=-1.588 tagged_above=-999 required=5 tests=[AWL=-0.590, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0OiMG2j3nEz3; Wed, 10 Nov 2010 09:03:51 -0800 (PST) Received: from mailX01.eud.schneider-electric.com (mailx01.eud.schneider-electric.com [205.167.7.35]) by core3.amsl.com (Postfix) with ESMTP id 0D9BD3A6919; Wed, 10 Nov 2010 09:03:50 -0800 (PST) Received: from ateui02.Schneider-Electric.com ([10.198.14.10]) by mailX01.eud.schneider-electric.com with ESMTP id 2010111017453105-78483 ; Wed, 10 Nov 2010 17:45:31 +0100 In-Reply-To: <003701cb80f3$0a1a5fe0$1e4f1fa0$@uni-rostock.de> To: Guido Moritz X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: matthieu.vial@fr.non.schneider-electric.com Date: Wed, 10 Nov 2010 18:04:24 +0100 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on ATEUI02.Schneider-Electric.com/T/SVR/Schneider at 10/11/2010 18:04:09, Itemize by SMTP Server on AXEU1OUT.schneider-electric.com/X/SVR/SEIxtra at 10/11/2010 17:45:31, Serialize by Router on AXEU1OUT.schneider-electric.com/X/SVR/SEIxtra at 10/11/2010 17:45:33, Serialize complete at 10/11/2010 17:45:33 Content-type: multipart/alternative; Boundary="0__=4EBBFD44DFCEA3BA8f9e8a93df938690918c4EBBFD44DFCEA3BA" Content-Disposition: inline Cc: core-bounces@ietf.org, 'core' Subject: Re: [core] RE observe #66 (new): Identifying observations X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 17:03:52 -0000 --0__=4EBBFD44DFCEA3BA8f9e8a93df938690918c4EBBFD44DFCEA3BA Content-type: text/plain; charset=US-ASCII >If we assume that the resources to subscribe to have a short path and only short queries, the current approach is fine. But for frequent notifications with only slightly complex querries, the EventID might result in much more compact messages and might reduce the required RAM on servers side. The notifications do not include the URI but a token. Illustrating example from Klaus C: GET /light (token=0xab6f) (observation-lifetime=60s) S: 200 (token=0xab6f) (observation-lifetime=60s) "..." S: 200 (token=0xab6f) (observation-lifetime=32s) "..." S: 200 (token=0xab6f) (observation-lifetime=11s) "..." C: GET /light (token=0x1b80) (observation-lifetime=60s) S: 200 (token=0x1b80) (observation-lifetime=59s) "..." S: 200 (token=0x1b80) (observation-lifetime=57s) "..." ... Matthieu --0__=4EBBFD44DFCEA3BA8f9e8a93df938690918c4EBBFD44DFCEA3BA Content-type: text/html; charset=US-ASCII Content-Disposition: inline

    >If we assume that the resources to subscribe to have a short path and only
    short queries, the current approach is fine. But for frequent notifications
    with only slightly complex querries, the EventID might result in much more
    compact messages and might reduce the required RAM on servers side.

    The notifications do not include the URI but a token.

    Illustrating example from Klaus

    C: GET /light (token=0xab6f) (observation-lifetime=60s)
    S: 200 (token=0xab6f) (observation-lifetime=60s) "<light>..."
    S: 200 (token=0xab6f) (observation-lifetime=32s) "<light>..."
    S: 200 (token=0xab6f) (observation-lifetime=11s) "<light>..."
    C: GET /light (token=0x1b80) (observation-lifetime=60s)
    S: 200 (token=0x1b80) (observation-lifetime=59s) "<light>..."
    S: 200 (token=0x1b80) (observation-lifetime=57s) "<light>..."
    ...

    Matthieu --0__=4EBBFD44DFCEA3BA8f9e8a93df938690918c4EBBFD44DFCEA3BA-- From darco@deepdarc.com Wed Nov 10 09:57:00 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68E1E3A69C7 for ; Wed, 10 Nov 2010 09:57:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.868 X-Spam-Level: X-Spam-Status: No, score=-0.868 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-9BV4sgVYgS for ; Wed, 10 Nov 2010 09:56:59 -0800 (PST) Received: from spider.nocdirect.com (spider.nocdirect.com [69.73.181.158]) by core3.amsl.com (Postfix) with ESMTP id 5C8083A69C3 for ; Wed, 10 Nov 2010 09:56:59 -0800 (PST) Received: from c-67-174-221-32.hsd1.ca.comcast.net ([67.174.221.32]:33059 helo=[172.30.96.6]) by spider.nocdirect.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1PGEvC-000619-Qu; Wed, 10 Nov 2010 12:57:23 -0500 References: In-Reply-To: Mime-Version: 1.0 (iPad Mail 8C134) Content-Type: multipart/alternative; boundary=Apple-Mail-1--280489234 Message-Id: <4242C434-01D8-4933-BF7C-5A2FFAB7BB4D@deepdarc.com> Content-Transfer-Encoding: 7bit X-Mailer: iPad Mail (8C134) From: Robert Quattlebaum Date: Wed, 10 Nov 2010 09:57:13 -0800 To: Linyi Tian X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - spider.nocdirect.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - deepdarc.com Cc: "CORE \(Constrained RESTful Environments\) WG" Subject: Re: [core] A potential new ticket for '-d' usage in link format draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 17:57:00 -0000 --Apple-Mail-1--280489234 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I got the feeling that the 'd' field was to be used similar to how XML names= paces are URIs. They may well point to something descriptive if actually que= ried, but the URI itself would normally be the only description needed or us= ed. Devices would recognize the URIs that they support and use them.=20 Then again, i could be misunderstanding this entirely or mixing my interpret= ation with my own worldview. Someone correct me if I'm mistaken.=20 Sent from my iPad On Nov 9, 2010, at 8:48 AM, Linyi Tian wrote: > Hi, Z. Shelby and all >=20 > When I review the link format draft, I believe there is a potential issue f= or =E2=80=93d usage extension.=20 >=20 > Consider the following example: > --Sensor-----Light > |--Temp >=20 > For light, its URI could be ;sh=3D=E2=80=9D/l=E2=80=9D;n=3D=E2= =80=9DLightLux=E2=80=9D;d=3D=E2=80=9Dhttp://example.com/index=E2=80=9D;ct=3D= 41 >=20 > If the requestor sends GET /l, the xml description file will be returned a= ccording to content type code 41. This is clear.=20 >=20 > However what is the semantics behind the =E2=80=9C-d=E2=80=9D URI is uncle= ar. Even though you mentioned that =E2=80=93d could be a WADL definition, it= is not possible for the requestor to know the relation type and purpose of t= his =E2=80=93d URI. >=20 > It is also unclear whether it is allowed for the requestor to use GET comm= and against this =E2=80=93d URI. Do you think this would be a problem? I thi= nk this needs to be clarified in the spec and the example. >=20 > By the way how to create a new ticket? Do I need to execute SQL to add a n= ew one? Is there any authority will review the reported issue and create a t= icket when he/she thinks this is really an issue? >=20 > Cheers, > Linyi > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --Apple-Mail-1--280489234 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

    I got the feeling that the 'd' field wa= s to be used similar to how XML namespaces are URIs. They may well point to s= omething descriptive if actually queried, but the URI itself would normally b= e the only description needed or used. Devices would recognize the URIs that= they support and use them. 

    Then again, i cou= ld be misunderstanding this entirely or mixing my interpretation with my own= worldview. Someone correct me if I'm mistaken. 

    Sent from my iP= ad

    On Nov 9, 2010, at 8:48 AM, Linyi Tian <tianlinyi@huawei.com> wrote:

    Hi, Z. Shelby and all

    When I review the link format draft, I believe there is a potential issue fo= r =E2=80=93d usage extension.

    Consider the following example:
    --Sensor-----Light
                &nbs= p;   |--Temp

    For light, its URI could be <Sensor/Light>;sh=3D=E2=80=9D/l=E2=80=9D;n= =3D=E2=80=9DLightLux=E2=80=9D;d=3D=E2=80=9Dh= ttp://example.com/index=E2=80=9D;ct=3D41

    If the requestor sends GET /l, the xml description file will be returned acc= ording to content type code 41. This is clear.

    However what is the semantics behind the =E2=80=9C-d=E2=80=9D URI is unclear= . Even though you mentioned that =E2=80=93d could be a WADL definition, it i= s not possible for the requestor to know the relation type and purpose of th= is =E2=80=93d URI.

    It is also unclear whether it is allowed for the requestor to use GET comman= d against this =E2=80=93d URI. Do you think this would be a problem? I think= this needs to be clarified in the spec and the example.

    By the way how to create a new ticket? Do I need to execute SQL to add a new= one? Is there any authority will review the reported issue and create a tic= ket when he/she thinks this is really an issue?

    Cheers,
    Linyi
    ____________________= ___________________________
    core mailing list
    core@ietf.org
    https://www.ietf.org/mailman= /listinfo/core
    = --Apple-Mail-1--280489234-- From prvs=3930033F59=guido.moritz@uni-rostock.de Wed Nov 10 11:55:04 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B541F3A68A5 for ; Wed, 10 Nov 2010 11:55:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.184 X-Spam-Level: X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5 tests=[AWL=-0.536, BAYES_50=0.001, DOS_OUTLOOK_TO_MX=1, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j3A53XYuYwS2 for ; Wed, 10 Nov 2010 11:55:03 -0800 (PST) Received: from mailrelay1.uni-rostock.de (mailrelay1.uni-rostock.de [139.30.8.201]) by core3.amsl.com (Postfix) with ESMTP id D88D83A6852 for ; Wed, 10 Nov 2010 11:55:02 -0800 (PST) From: Guido Moritz To: 'core' References: <003701cb80f3$0a1a5fe0$1e4f1fa0$@uni-rostock.de> In-Reply-To: Date: Wed, 10 Nov 2010 20:55:31 +0100 Message-ID: <000e01cb8111$3bbed3a0$b33c7ae0$@uni-rostock.de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01CB8119.9D873340" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFdGemcHp9GHhq0ptv7HOVlz2u6MZRH7a0g Content-Language: de Subject: Re: [core] RE observe #66 (new): Identifying observations X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 19:55:04 -0000 ------=_NextPart_000_000F_01CB8119.9D873340 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit But as I mentioned before, I would say this is not completely straight forward as tokens are to identify the transaction, not the subscription itself. I am also thinking about scenarios with CON notifications. In such cases, using the tokens to identify the subscription might be misleading. So I would vote for a clear separation of transaction (tokens) and subscription logic (some kind of EventID). Guido Von: matthieu.vial@fr.non.schneider-electric.com [mailto:matthieu.vial@fr.non.schneider-electric.com] Gesendet: Mittwoch, 10. November 2010 18:04 An: Guido Moritz Cc: 'core'; core-bounces@ietf.org Betreff: Re: [core] RE observe #66 (new): Identifying observations >If we assume that the resources to subscribe to have a short path and only short queries, the current approach is fine. But for frequent notifications with only slightly complex querries, the EventID might result in much more compact messages and might reduce the required RAM on servers side. The notifications do not include the URI but a token. Illustrating example from Klaus C: GET /light (token=0xab6f) (observation-lifetime=60s) S: 200 (token=0xab6f) (observation-lifetime=60s) "..." S: 200 (token=0xab6f) (observation-lifetime=32s) "..." S: 200 (token=0xab6f) (observation-lifetime=11s) "..." C: GET /light (token=0x1b80) (observation-lifetime=60s) S: 200 (token=0x1b80) (observation-lifetime=59s) "..." S: 200 (token=0x1b80) (observation-lifetime=57s) "..." ... Matthieu ------=_NextPart_000_000F_01CB8119.9D873340 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    But as I mentioned before, I would say this is not completely = straight forward as tokens are to identify the transaction, not the = subscription itself. I am also thinking about scenarios with CON = notifications. In such cases, using the tokens to identify the = subscription might be misleading. So I would

    vote for a clear separation of transaction (tokens) and subscription = logic (some kind of EventID).

     

    Guido

     

    Von:<= /b> = matthieu.vial@fr.non.schneider-electric.com = [mailto:matthieu.vial@fr.non.schneider-electric.com] =
    Gesendet: Mittwoch, 10. November 2010 18:04
    An: = Guido Moritz
    Cc: 'core'; = core-bounces@ietf.org
    Betreff: Re: [core] RE observe #66 = (new): Identifying observations

     

    >If we assume that the resources to = subscribe to have a short path and only
    short = queries, the current approach is fine. But for frequent = notifications
    with only slightly complex querries, the = EventID might result in much more
    compact messages and might = reduce the required RAM on servers side.

    The notifications do not include the URI but = a token.

    Illustrating example from = Klaus

    C: GET /light (token=3D0xab6f) = (observation-lifetime=3D60s)
    S: 200 (token=3D0xab6f) = (observation-lifetime=3D60s) "<light>..."
    S: = 200 (token=3D0xab6f) (observation-lifetime=3D32s) = "<light>..."
    S: 200 (token=3D0xab6f) = (observation-lifetime=3D11s) "<light>..."
    C: = GET /light (token=3D0x1b80) (observation-lifetime=3D60s)
    S: = 200 (token=3D0x1b80) (observation-lifetime=3D59s) = "<light>..."
    S: 200 (token=3D0x1b80) = (observation-lifetime=3D57s) = "<light>..."
    ...

    Matthieu

    ------=_NextPart_000_000F_01CB8119.9D873340-- From zach@sensinode.com Wed Nov 10 17:03:55 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F51F3A686E for ; Wed, 10 Nov 2010 17:03:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.53 X-Spam-Level: X-Spam-Status: No, score=-3.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RyEcOuZw-pCe for ; Wed, 10 Nov 2010 17:03:54 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 857093A6870 for ; Wed, 10 Nov 2010 17:03:53 -0800 (PST) Received: from dhcp-40a3.meeting.ietf.org (dhcp-40a3.meeting.ietf.org [130.129.64.163]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id oAB13w3d018658 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 11 Nov 2010 03:04:03 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-343--254891168; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: <4242C434-01D8-4933-BF7C-5A2FFAB7BB4D@deepdarc.com> Date: Thu, 11 Nov 2010 09:03:57 +0800 Message-Id: References: <4242C434-01D8-4933-BF7C-5A2FFAB7BB4D@deepdarc.com> To: Robert Quattlebaum X-Mailer: Apple Mail (2.1081) Cc: "CORE \(Constrained RESTful Environments\) WG" Subject: Re: [core] A potential new ticket for '-d' usage in link format draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 01:03:55 -0000 --Apple-Mail-343--254891168 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Nov 11, 2010, at 1:57 AM, Robert Quattlebaum wrote: > I got the feeling that the 'd' field was to be used similar to how XML = namespaces are URIs. They may well point to something descriptive if = actually queried, but the URI itself would normally be the only = description needed or used. Devices would recognize the URIs that they = support and use them.=20 Right, this is exactly how it is meant to be used. I don't expect = constrained devices to go and fetch a .wadl from the URI, parse it, and = then generate code to interact the resource based on that :-/=20 Zach >=20 > Then again, i could be misunderstanding this entirely or mixing my = interpretation with my own worldview. Someone correct me if I'm = mistaken.=20 >=20 > Sent from my iPad >=20 > On Nov 9, 2010, at 8:48 AM, Linyi Tian wrote: >=20 >> Hi, Z. Shelby and all >>=20 >> When I review the link format draft, I believe there is a potential = issue for =96d usage extension.=20 >>=20 >> Consider the following example: >> --Sensor-----Light >> |--Temp >>=20 >> For light, its URI could be = ;sh=3D=94/l=94;n=3D=94LightLux=94;d=3D=94http://example.com/= index=94;ct=3D41 >>=20 >> If the requestor sends GET /l, the xml description file will be = returned according to content type code 41. This is clear.=20 >>=20 >> However what is the semantics behind the =93-d=94 URI is unclear. = Even though you mentioned that =96d could be a WADL definition, it is = not possible for the requestor to know the relation type and purpose of = this =96d URI. >>=20 >> It is also unclear whether it is allowed for the requestor to use GET = command against this =96d URI. Do you think this would be a problem? I = think this needs to be clarified in the spec and the example. >>=20 >> By the way how to create a new ticket? Do I need to execute SQL to = add a new one? Is there any authority will review the reported issue and = create a ticket when he/she thinks this is really an issue? >>=20 >> Cheers, >> Linyi >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 --Apple-Mail-343--254891168 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9 fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb 6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja 5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I 2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTExMTAxMDM1 OFowIwYJKoZIhvcNAQkEMRYEFGShYwyfFZ3JR4xDsQF3+OILDb5oMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAEucIStsEiQXD9308apQAn5IszYN+EVqODpkpZCuMHYV48Rn8Mu5sRWX ZLzTppVIeMEReUwI+ZLHYw+z1y06UbMTzPvt228GDPqNxQ8G4inF9G5+RuMl4K00T1n22iEXhGuJ mKEhCUyJAmFKFeD0xc8PnfTyFoKNbDpUWWGqoZ2eFBplaVcQ3PhILsULeXmD3WUF4AfVCU8Ura2W xFdA0Bl+9iQp0Y33zzhPOLy+TG4DR84S5cOhCT/hHVGKMiF663+zpOt0MQisH6/ZUc69BYGD2bo6 MIgz3Me6fr9JzHDwrP+KSrsxS6fmj9q8KkiszxiFScR0hvWKCagUYTaYhecAAAAAAAA= --Apple-Mail-343--254891168-- From behcetsarikaya@yahoo.com Wed Nov 10 17:53:09 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0BDF3A68E7 for ; Wed, 10 Nov 2010 17:53:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id un3KUWiU3UL9 for ; Wed, 10 Nov 2010 17:53:07 -0800 (PST) Received: from nm1-vm1.bullet.mail.sp2.yahoo.com (nm1-vm1.bullet.mail.sp2.yahoo.com [98.139.91.203]) by core3.amsl.com (Postfix) with SMTP id 176983A68A2 for ; Wed, 10 Nov 2010 17:53:04 -0800 (PST) Received: from [98.139.91.67] by nm1.bullet.mail.sp2.yahoo.com with NNFMP; 11 Nov 2010 01:53:30 -0000 Received: from [98.139.91.27] by tm7.bullet.mail.sp2.yahoo.com with NNFMP; 11 Nov 2010 01:53:30 -0000 Received: from [127.0.0.1] by omp1027.mail.sp2.yahoo.com with NNFMP; 11 Nov 2010 01:53:29 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 989462.59900.bm@omp1027.mail.sp2.yahoo.com Received: (qmail 40492 invoked by uid 60001); 11 Nov 2010 01:53:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1289440409; bh=MbMOYiVpD5FKtusBNIyoq80VdFjQRXm7zjY3a4Srkqc=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=SD9zKRIaRKU9pyd8fX/D8RS71+XUtZIW4vFgdj+obktYME+8XauYG5kUwqOqB5xd78AwO+arrECJjs7TfaIPm+6F2DkLA2Dntu78zZRb5Q2B0FTWNqARNb2Jpifv+0YwSuAtG1KpILhvtykQ0Vw5myR867TiKxb1whszpptdrTA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=yIMOQYyVRz79nfjGvdgh10Inwlbvgw9OyJodUcsqHHUxzPeO5toTByOoUe0beTeUy5Y+VvgfUtgB1u7R7264jcR1uTu3kLJsCDoyT4jOYtDa/wj81/5N+JQD8j69ikPhiO7l7dQBjiXujdgIRsV+KIOuVwvYETQTpOK8PhTF1S4=; Message-ID: <661651.35967.qm@web111404.mail.gq1.yahoo.com> X-YMail-OSG: 5SrGsXAVM1lVIkV7.1sC.CwaSTzR7M6C6vlzXUeLSfqfmb4 P.1fnWmcBePBIazQxA3QYjhujZ_JbwLGbm543IIL190RcdlEmlyoCTI36UuV jyi2RxQkokpJlr82h4qJccQknmS9sFY5nSuD_7bzrbw97XtlBmaFSQPiVKPj xQeIXG9APaWbDplzTeRxuRaVFpyITkv9eGaLnV3rKUAoRwk02.8A3YOfNqWE ysgJ9z1RS5YiGNNF9sYDm_STY2cgCsAszQTxBh.tM3fjqT.B2iqp5FtHZWCm Fo3RVjGQyRWkqFm4nqmlY256BJ5cGW2WmIHIlfhAVqNp56R7r8BPmhIpuEaZ k1hx7feKPyvnbOOSb0lcSFRoPfY_cOfrDiQ-- Received: from [130.129.131.75] by web111404.mail.gq1.yahoo.com via HTTP; Wed, 10 Nov 2010 17:53:29 PST X-Mailer: YahooMailRC/504.5 YahooMailWebService/0.8.107.285259 References: <935DB371-B149-486A-8AD2-3B4454C9B172@tzi.org> <4CA3BB54.8050706@gmail.com> <4CA5E8E0.4030503@gmail.com> <4CA6095F.6040403@gmail.com> <4CB48B9B.9010206@gmail.com> <4CC83F61.5060109@gmail.com> <4CDAA76B.5080805@gmail.com> Date: Wed, 10 Nov 2010 17:53:29 -0800 (PST) From: Behcet Sarikaya To: Rene Struik , core In-Reply-To: <4CDAA76B.5080805@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-660853163-1289440409=:35967" Subject: Re: [core] bootstrapping concerns still remain all (was Re: concerns re draft-oflynn-core-bootstrapping-02) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 01:53:09 -0000 --0-660853163-1289440409=:35967 Content-Type: text/plain; charset=us-ascii Hi Rene, Currently some of the authors are attending IETF in Beijing. We expect to discuss the points below as well as comments made during the presentation yesterday and possibly take some action. If you wish to get good results, my recommendation is to provide some text. Regards, Behcet > >From: Rene Struik >To: core >Sent: Wed, November 10, 2010 8:08:43 AM >Subject: [core] bootstrapping concerns still remain all (was Re: concerns re >draft-oflynn-core-bootstrapping-02) > >Dear colleagues: > >I did a quick comparison of draft-oflynn-core-bootstrapping-02 and >draft-oflynn-core-bootstrapping-03; unfortunately, my major overall concerns >expressed in my email as of Wed October 27, 2010 ff still stand. NOTE: >draft-03, which was posted two days ago has been reposted a few hours ago as >draft-sarikaya-core-sbootstrapping-00, since it apparently lost of the main >authors of previous versions. > >Some preliminary feedback: >0) main difference with draft-oflynn-core-bootstrapping-02 and >draft-oflynn-core-bootstrapping-03 is in Section 5.1 only >1) Detailed analysis of deployment scenarios is still missing (since no >changes to Appendix A - examples). >2) Security services to be offered still needs far more detail (I provided >an initial list on September 29, 2010, after the CoAP Conf Call on desired >properties and had *many* email exchanges on this in context of HIP >protocol, but do not really see this reflected. >3) Consideration for security policies and trust management aspects is >virtually not there. >4) It is entirely unclear whether one can rely on a globally unique (and >thereby unchanging id) -- cf. e.g. language in Section 5.1. It is unclear >what the statement that one MUST support various tyypes of identities means, >whether "various" could mean "1" and how one can bind the various >identities, so as to allow conversion between theses and mapping this to a >static globally unique id. > >5) Multi-domain support: in my mind, intention should be that a device may >be part of more than one network at the same time and be able to move from >one to the next while maintaining part of its state. >6) Authentication/authhorization: An online connectivity to the "trust >center" (a ZigBee term) is assumed. In many cases, this online connectivity >is simply not there -- one of the main characteristics of sensor-style >networks is that one cannot always assume connectivity to security >management functionality, esp. if centralized. It seems that the centralized >ZigBee model has been written-in without any explanation as to why this >would cover deployment scenarios (which, by itself, reiterates importance to >study deployment scenarios in detail. >7) The PANA Section does not describe what PANA accomplishes and section is >littered with references to external standards (C12.22), without explanation >of how things fit together, whether security framework and design philosophy >match/are complementary, etc., etc. Moreover, as already mentioned, not >clear at all what the security policy and trust management framework is. >8) The need for HIP is, after at least 10 email communications still >entirely unclear. Moreover entanglement of name space and crypto space is >still an issue. Most questions posed over the last month resulted in >comments that one could support/ameliorite better properties, more >efficiencies, disentanglement as work-of-progress items for next version of >HI/HIP-DEX. In my mind, this indicates immaturity and (for now) >unsuitability for standardization. >9) The sections on PANA, HIP, 802.1x seem to be more text fillers, since do >not provide any motivation or allow one to grasp concepts behind things. As >Cullen Jennings already articulated in his initial feedback: it is >completely unclear how one would build to this. > >I can provide more feedback once back from the current IEEE 802 meeting. > >Best regards, Rene > > > >On 27/10/2010 11:04 AM, Rene Struik wrote: >Dear colleagues: >> >>I had a brief look at the bootstrapping draft >>(draft-oflynn-core-bootstrapping-02. Some comments below (I am having some >>offline discussions on this, but thought to send this to the list as >>well): >> >>I miss a detailed analysis of deployment scenarios to be considered as >>guidance intodesign, so as to have as very minimal benchmark whether all >>those crypto protocols actually enable the deployment scenarios one has in >>mind. To me, it seems to have merit to discuss the whole spectrum and end >>up with cryptographic building blocks, security protocols, and security >>policies and accompanying enforcement mechanism for trust policies that >>would fit the operational scenarios. >> >>I would favor not sprinkling protocol acronyms into any draft too early >>(since, in my mind, this pushes into a particular direction, and notalways >>with merit). As an example, right now I do not see how, e.g., HIP or >>cryptographically generated addresses (802.1-like) would fit in.Similarly, >>e.g., PANA does not seem to work in heterogeneous trustenvironments, >>assumes online connectivity of a "mothership" node, and does not seem to >>include consideration of how to move from one mothership node to the next >>(or, e.g., if one has an authenticator, how to make this work with >>single-hop/MAC security). >> >> >>I also miss security objectives and design considerations, such as >>"separation of concern" and no entanglement of concepts from different >>disciplines in the document. >> >>BTW - I mentioned some of this in email correspondence after the last CoRE >>conf call (Wed September 29, 2010). So far, I have not seen too much >>traffic on this. Moreover, I have not seen any adequate answers as to what >>makes, e.g., HIP features an attractive fit for CoRE-like environments. >> >>Best regards, Rene >> >>[excerpt email RS as of October 1, 2010, 12:16pm EDT] >> >>In my mind, properties of suitable authenticated key agreement schemes >>should include (a) key establishment; (b) implicit key authentication; (c) >>key confirmation; (d) mutual entity authentication; (e) forward secrecy; >>(f) {perhaps} some more esoteric properties (key compromise impersonation >>resilience, etc.). >> >> >>Moreover, the "name space" (device identifiers) and the "cryptographic >>space" (public keys, etc.) should be independent, so that this would allow >>trust lifecycle management to be reduced to proper management of device >>identifiers (i.e., *no* entanglement of concepts from different >>disciplines). >> >> >> >>On 12/10/2010 12:23 PM, Rene Struik wrote: >>Hi Tobias: >>> >>>Thanks for your note. >>> >>>Does your "ascii art" description, Step 1)-3) allow the scenario, where (a) one >>>assigns a node id and imprints this (e.g., blowing fuse during chip testing); >>> >>>(b) has a node generating its own long-term public/private key pair and >>>outputting its node id and public key (e.g., during chip testing -- this would >>> >>>correspond to registering a public key with an RA); (c) have CA create a >>>certificate in different process and return this value at later production/ >>>personalization stage? >>> >>>Right now, from Section 4.1.3 of draft-ietf-hip-rfc5201-bis-02, I get the >>>impression that HIP does execute an authenticated DH key agreement scheme. If >>>so, >>>this makes me wonder how HIP differentiates from protocols, such as ECMQV and, >>>e.g., HMQV, which are all not that much more expensive than ECDH. If the >>> >>>difference is in the "puzzle" element, couldn't one just add something similar >>>to a well-known authenticated scheme that is already standardized with, e.g., >>> >>>NIST? >>> >>>As to forward secrecy: reason to include this is that many sensor-type nodes can >>>be expected to be physically unprotected (e.g., screwed on a street lamp >>> >>>post, on a garage roof, etc.) and, therefore, may be more vulnerable to device >>>compromise over time (esp. since one cannot expect all nodes to be tamper >>> >>>resistant or tamper evident). By virtue of forward secrecy, compromise over time >>>does not compromise the whole device's history, but only the current set of >>>symmetric keys (note: I make some shortcuts in my reasoning on key management >>>here). Admittedly, my list of security properties is based on "desired" >>> >>>functionality and does not exclude functionality that may require, e.g., >>>public-key crypto constructs. However, from a user's perspective, the only thing >>>that >>>matters is features and not what is "under the hood", as long as that is not >>>cost-prohibitive (which I contend it is not -- cf., e.g., Section 3.2 of >>>draft-struik-6lowapp-security-considerations-00). (BTW - All other desired >>>security properties I listed have an underlying rationale.) >>> >>>It would help to have a succinct mathematical description of the protocol you >>>suggest (stripped from formatting issues) and describe claimed cryptographic >>>properties. I would be happy to give this a look and review. >>> >>>Please feel free to provide to me in person if this would be cumbersome material >>>for non-crypto people on the mailing list. >>> >>>Best regards, Rene >>> >>> >>>[excerpt email RS as of October 1, 2010, 12:16pm EDT and response Tobias Heer as >>>of October 7, 2010, 5:36am EDT] >>> >>>To aid clarity and succinct discussions, it would help to have a clear >>>description of desired security services to be offered by an authenticated >>> >>>key agreement scheme and see whether a candidate scheme (such as, who knows, >>>HIP) satisfies these. If you could provide a succinct description of >>> >>>the HIP protocol itself, so that this is easy to understand, and could provide >>>what properties it has, that would be of great help! >>>> > In my mind, properties of suitable authenticated key agreement schemes >>>>should include (a) key establishment; (b) implicit key authentication; >>>> >>>(c) key confirmation; (d) mutual entity authentication; (e) forward secrecy; (f) >>>{perhaps} some more esoteric properties (key compromise >>> >>>impersonation resilience, etc.). >>>> >>>Is this list valid for all targeted use cases? If yes, it is a very handy list >>>to check against. However, (e) forward secrecy seems to >>> >>>rule a number of "cheaper" cryptographic approaches (e.g., pre-shared keys) and >>>might not be relevant to all use cases (especially small >>> >>>setups). However, I am not absolutely firm with the envisaged scenarios in >>CORE. >>> >>>> Moreover, the "name space" (device identifiers) and the "cryptographic space" >>>>(public keys, etc.) should be independent, so that this would >>>> >>allow trust lifecycle management to be reduced to proper management of device >>identifiers (i.e., *no* entanglement of concepts from different >> >disciplines). >> Does the "*no* entanglement of concepts from different disciplines" also mean that a concept like the id/loc split should be used to avoid entanglement of routing and naming? On 07/10/2010 5:36 AM, Tobias Heer wrote: To aid clarity and succinct discussions, it would help to have a clear description of desired security services to be offered by an authenticated key agreement scheme and see whether a candidate scheme (such as, who knows, HIP) satisfies these. If you could provide a succinct description of the HIP protocol itself, so that this is easy to understand, and could provide what properties it has, that would be of great help! >>> > In my mind, properties of suitable authenticated key agreement schemes >>>should include (a) key establishment; (b) implicit key authentication; (c) key >>>confirmation; (d) mutual entity authentication; (e) forward secrecy; (f) >>>{perhaps} some more esoteric properties (key compromise impersonation >>>resilience, etc.). >>> Is this list valid for all targeted use cases? If yes, it is a very handy list to check against. However, (e) forward secrecy seems to rule a number of "cheaper" cryptographic approaches (e.g., pre-shared keys) and might not be relevant to all use cases (especially small setups). However, I am not absolutely firm with the envisaged scenarios in CORE. > Moreover, the "name space" (device identifiers) and the "cryptographic space" >(public keys, etc.) should be independent, so that this would allow trust >lifecycle management to be reduced to proper management of device identifiers >(i.e., *no* entanglement of concepts from different disciplines). > Does the "*no* entanglement of concepts from different disciplines" also mean that a concept like the id/loc split should be used to avoid entanglement of routing and naming? -- email: rstruik.ext@gmail.com Skype: rstruik cell: +1 (647) 867-5658 USA Google voice: +1 (415) 690-7363 > > >-- >email: rstruik.ext@gmail.com Skype: rstruik cell: +1 (647) 867-5658 USA Google >voice: +1 (415) 690-7363 -- email: rstruik.ext@gmail.com Skype: rstruik cell: +1 (647) 867-5658 USA Google voice: +1 (415) 690-7363 --0-660853163-1289440409=:35967 Content-Type: text/html; charset=us-ascii
    Hi Rene,
      Currently some of the authors are attending IETF in Beijing.
    We expect to discuss the points below as well as comments made during the presentation yesterday and possibly take some action. If you wish to get good results, my recommendation is to provide some text.

    Regards,

    Behcet

    From: Rene Struik <rstruik.ext@gmail.com>
    To: core <core@ietf.org>
    Sent: Wed, November 10, 2010 8:08:43 AM
    Subject: [core] bootstrapping concerns still remain all (was Re: concerns re draft-oflynn-core-bootstrapping-02)

    Dear colleagues:

    I did a quick comparison of draft-oflynn-core-bootstrapping-02 and draft-oflynn-core-bootstrapping-03; unfortunately, my major overall concerns expressed in my email as of Wed October 27, 2010 ff still stand. NOTE: draft-03, which was posted two days ago has been reposted a few hours ago as draft-sarikaya-core-sbootstrapping-00, since it apparently lost of the main authors of previous versions.

    Some preliminary feedback:
    0) main difference with draft-oflynn-core-bootstrapping-02 and draft-oflynn-core-bootstrapping-03 is in Section 5.1 only
    1) Detailed analysis of deployment scenarios is still missing (since no changes to Appendix A - examples).
    2) Security services to be offered still needs far more detail (I provided an initial list on September 29, 2010, after the CoAP Conf Call on desired properties and had *many* email exchanges on this in context of HIP protocol, but do not really see this reflected.
    3) Consideration for security policies and trust management aspects is virtually not there.
    4) It is entirely unclear whether one can rely on a globally unique (and thereby unchanging id) -- cf. e.g. language in Section 5.1. It is unclear what the statement that one MUST support various tyypes of identities means, whether "various" could mean "1" and how one can bind the various identities, so as to allow conversion between theses and mapping this to a static globally unique id.
    5) Multi-domain support: in my mind, intention should be that a device may be part of more than one network at the same time and be able to move from one to the next while maintaining part of its state.
    6) Authentication/authhorization: An online connectivity to the "trust center" (a ZigBee term) is assumed. In many cases, this online connectivity is simply not there -- one of the main characteristics of sensor-style networks is that one cannot always assume connectivity to security management functionality, esp. if centralized. It seems that the centralized ZigBee model has been written-in without any explanation as to why this would cover deployment scenarios (which, by itself, reiterates importance to study deployment scenarios in detail.
    7) The PANA Section does not describe what PANA accomplishes and section is littered with references to external standards (C12.22), without explanation of how things fit together, whether security framework and design philosophy match/are complementary, etc., etc. Moreover, as already mentioned, not clear at all what the security policy and trust management framework is.
    8) The need for HIP is, after at least 10 email communications still entirely unclear. Moreover entanglement of name space and crypto space is still an issue. Most questions posed over the last month resulted in comments that one could support/ameliorite better properties, more efficiencies, disentanglement as work-of-progress items for next version of HI/HIP-DEX. In my mind, this indicates immaturity and (for now) unsuitability for standardization.
    9) The sections on PANA, HIP, 802.1x seem to be more text fillers, since do not provide any motivation or allow one to grasp concepts behind things. As Cullen Jennings already articulated in his initial feedback: it is completely unclear how one would build to this.

    I can provide more feedback once back from the current IEEE 802 meeting.

    Best regards, Rene



    On 27/10/2010 11:04 AM, Rene Struik wrote:
    Dear colleagues:

    I had a brief look at the bootstrapping draft (draft-oflynn-core-bootstrapping-02. Some comments below (I am having some offline discussions on this, but thought to send this to the list as well):

    I miss a detailed analysis of deployment scenarios to be considered as guidance into design, so as to have as very minimal benchmark whether all those crypto protocols actually enable the deployment scenarios one has in mind. To me, it seems to have merit to discuss the whole spectrum and end up with cryptographic building blocks, security protocols, and security policies and accompanying enforcement mechanism for trust policies that would fit the operational scenarios.

    I would favor not sprinkling protocol acronyms into any draft too early (since, in my mind, this pushes into a particular direction, and not always with merit). As an example, right now I do not see how, e.g., HIP or cryptographically generated addresses (802.1-like) would fit in. Similarly, e.g., PANA does not seem to work in heterogeneous trust environments, assumes online connectivity of a "mothership" node, and does not seem to include consideration of how to move from one  mothership node to the next (or, e.g., if one has an authenticator, how to make this work with single-hop/MAC security).

    I also miss security objectives and design considerations, such as "separation of concern" and no entanglement of concepts from different disciplines in the document.

    BTW - I mentioned some of this in email correspondence after the last CoRE conf call (Wed September 29, 2010). So far, I have not seen too much traffic on this. Moreover, I have not seen any adequate answers as to what makes, e.g., HIP features an attractive fit for CoRE-like environments.

    Best regards, Rene

    [excerpt email RS as of October 1, 2010, 12:16pm EDT]

    In my mind, properties of suitable authenticated key agreement schemes should include (a) key establishment; (b) implicit key authentication; (c) key confirmation; (d) mutual entity authentication; (e) forward secrecy; (f) {perhaps} some more esoteric properties (key compromise impersonation resilience, etc.).

    Moreover, the "name space" (device identifiers) and the "cryptographic space" (public keys, etc.) should be independent, so that this would allow trust lifecycle management to be reduced to proper management of device identifiers (i.e., *no* entanglement of concepts from different disciplines).


    On 12/10/2010 12:23 PM, Rene Struik wrote: 
    Hi Tobias:

    Thanks for your note. 

    Does your "ascii art" description, Step 1)-3) allow the scenario, where (a) one assigns a node id and imprints this (e.g., blowing fuse during chip testing); 
    (b) has a node generating its own long-term public/private key pair and outputting its node id and public key (e.g., during chip testing -- this would 
    correspond to registering a public key with an RA); (c) have CA create a certificate in different process and return this value at later production/
    personalization stage?

    Right now, from Section 4.1.3 of draft-ietf-hip-rfc5201-bis-02, I get the impression that HIP does execute an authenticated DH key agreement scheme. If so,
    this makes me wonder how HIP differentiates from protocols, such as ECMQV and, e.g., HMQV, which are all not that much more expensive than ECDH. If the 
    difference is in the "puzzle" element, couldn't one just add something similar to a
 well-known authenticated scheme that is already standardized with, e.g., 
    NIST?

    As to forward secrecy: reason to include this is that many sensor-type nodes can be expected to be physically unprotected (e.g., screwed on a street lamp 
    post, on a garage roof, etc.) and, therefore, may be more vulnerable to device compromise over time (esp. since one cannot expect all nodes to be tamper 
    resistant or tamper evident). By virtue of forward secrecy, compromise over time does not compromise the whole device's history, but only the current set of
    symmetric keys (note: I make some shortcuts in my reasoning on key management here). Admittedly, my list of security properties is based on "desired" 
    functionality and does not exclude functionality that may require, e.g., public-key crypto constructs. However, from a user's perspective, the only thing that
    matters is features and not what is "under the hood", as long as that is not
 cost-prohibitive (which I contend it is not -- cf., e.g., Section 3.2 of
    draft-struik-6lowapp-security-considerations-00). (BTW - All other desired security properties I listed have an underlying rationale.)

    It would help to have a succinct mathematical description of the protocol you suggest (stripped from formatting issues) and describe claimed cryptographic
    properties. I would be happy to give this a look and review. 

    Please feel free to provide to me in person if this would be cumbersome material for non-crypto people on the mailing list.

    Best regards, Rene


    [excerpt email RS as of October 1, 2010, 12:16pm EDT and response Tobias Heer as of October 7, 2010, 5:36am EDT]

    To aid clarity and succinct discussions, it would help to have a clear description of desired security services to be offered by an authenticated 
    key agreement scheme and see whether a candidate scheme (such as, who knows, HIP) satisfies
 these. If you could provide a succinct description of 
    the HIP protocol itself, so that this is easy to understand, and could provide what properties it has, that would be of great help!
    > 
> In my mind, properties of suitable authenticated key agreement schemes should include (a) key establishment; (b) implicit key authentication; 
    (c) key confirmation; (d) mutual entity authentication; (e) forward secrecy; (f) {perhaps} some more esoteric properties (key compromise 
    impersonation resilience, etc.).
    >
    Is this list valid for all targeted use cases? If yes, it is a very handy list to check against. However, (e) forward secrecy seems to 
    rule a number of "cheaper" cryptographic approaches (e.g., pre-shared keys) and might not be relevant to all use cases (especially small 
    setups). However, I am not absolutely firm with the envisaged scenarios in CORE.
    > Moreover, the "name space" (device identifiers) and the "cryptographic space" (public keys, etc.) should be independent, so that this would 
    allow trust lifecycle management to be reduced to proper management of device identifiers (i.e., *no* entanglement of concepts from different 
    disciplines).
     
    Does the "*no* entanglement of concepts from different disciplines" also mean that a concept like the id/loc split should be used to avoid 
    entanglement of routing and naming?





    On 07/10/2010 5:36 AM, Tobias Heer wrote: 
    To aid clarity and succinct discussions, it would help to have a clear description of desired security services to be offered by an authenticated key agreement scheme and see whether a candidate scheme (such as, who knows, HIP) satisfies these. If you could provide a succinct description of the HIP protocol itself, so that this is easy to understand, and could provide what properties it has, that would be of great help!
    > 
> In my mind, properties of suitable authenticated key agreement schemes should include (a) key establishment; (b) implicit key authentication; (c) key confirmation; (d) mutual entity authentication; (e) forward secrecy; (f) {perhaps} some more esoteric properties (key compromise impersonation resilience, etc.).
    > 

    Is this list valid for all targeted use cases? If yes, it is a very handy list to check against. However, (e) forward secrecy seems to rule a number of "cheaper" cryptographic approaches (e.g., pre-shared keys) and might not be relevant to all use cases (especially small setups). However, I am not absolutely firm with the envisaged scenarios in CORE.

    > Moreover, the "name space" (device identifiers) and the "cryptographic space" (public keys, etc.) should be independent, so that this would allow trust lifecycle management to be reduced to proper management of device identifiers (i.e., *no* entanglement of concepts from different disciplines).
     
    Does the "*no* entanglement of concepts from different disciplines" also mean that a concept like the id/loc split should be used to avoid entanglement of routing and naming?



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


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


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

    --0-660853163-1289440409=:35967-- From tianlinyi@huawei.com Wed Nov 10 18:22:03 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9ECC33A691A for ; Wed, 10 Nov 2010 18:22:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8MyM-9bG2ax1 for ; Wed, 10 Nov 2010 18:22:02 -0800 (PST) Received: from szxga05-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 1AE933A6921 for ; Wed, 10 Nov 2010 18:22:02 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LBP00EJT7X7FJ@szxga05-in.huawei.com> for core@ietf.org; Thu, 11 Nov 2010 10:22:20 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LBP00J2L7X6TC@szxga05-in.huawei.com> for core@ietf.org; Thu, 11 Nov 2010 10:22:19 +0800 (CST) Received: from [130.129.131.148] (dhcp-8394.meeting.ietf.org [130.129.131.148]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LBP007LF7X1TL@szxml01-in.huawei.com>; Thu, 11 Nov 2010 10:22:18 +0800 (CST) Date: Thu, 11 Nov 2010 10:22:08 +0800 From: Linyi Tian In-reply-to: To: Zach Shelby , Robert Quattlebaum Message-id: MIME-version: 1.0 Content-type: text/plain; charset=Big5 Content-transfer-encoding: quoted-printable Thread-topic: [core] A potential new ticket for '-d' usage in link format draft Thread-index: AcuBRz05JWjxXZnlbEaOoLcAveaTyg== User-Agent: Microsoft-Entourage/12.25.0.100505 Cc: "CORE \(Constrained RESTful Environments\) WG" Subject: Re: [core] A potential new ticket for '-d' usage in link format draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 02:22:03 -0000 If I understand correctly, you are saying that the semantics will be define= d by the implementation. We just provide the mechanism to convey this URI in the message and allow application to interpret. The scenario came to my mind actually was from the draft. It says the -d provides the URI to an interface to access the resource. Then WADL was listed as an example. Did I misunderstood the draft? Could you please give me a real example how can I use this -d field? ---------------------- 2.3. Description 'd' usage The description "d" attribute can provide a URI to a specific interface definition used to access the target resource. This could be for example a URI to the WADL definition of the target resource. Cheers, Linyi On 10-11-11 =A4W=A4=C89:03, "Zach Shelby" wrote: >=20 > On Nov 11, 2010, at 1:57 AM, Robert Quattlebaum wrote: >=20 >> I got the feeling that the 'd' field was to be used similar to how XML >> namespaces are URIs. They may well point to something descriptive if act= ually >> queried, but the URI itself would normally be the only description neede= d or >> used. Devices would recognize the URIs that they support and use them. >=20 > Right, this is exactly how it is meant to be used. I don't expect constra= ined > devices to go and fetch a .wadl from the URI, parse it, and then generate= code > to interact the resource based on that :-/ >=20 > Zach >=20 >>=20 >> Then again, i could be misunderstanding this entirely or mixing my >> interpretation with my own worldview. Someone correct me if I'm mistaken= . >>=20 >> Sent from my iPad >>=20 >> On Nov 9, 2010, at 8:48 AM, Linyi Tian wrote: >>=20 >>> Hi, Z. Shelby and all >>>=20 >>> When I review the link format draft, I believe there is a potential iss= ue >>> for =A1Vd usage extension. >>>=20 >>> Consider the following example: >>> --Sensor-----Light >>> |--Temp >>>=20 >>> For light, its URI could be >>> ;sh=3D=A1=A8/l=A1=A8;n=3D=A1=A8LightLux=A1=A8;d=3D=A1=A8http://example.com/index=A1=A8;= ct=3D41 >>>=20 >>> If the requestor sends GET /l, the xml description file will be returne= d >>> according to content type code 41. This is clear. >>>=20 >>> However what is the semantics behind the =A1=A7-d=A1=A8 URI is unclear. Even th= ough >>> you mentioned that =A1Vd could be a WADL definition, it is not possible f= or the >>> requestor to know the relation type and purpose of this =A1Vd URI. >>>=20 >>> It is also unclear whether it is allowed for the requestor to use GET >>> command against this =A1Vd URI. Do you think this would be a problem? I t= hink >>> this needs to be clarified in the spec and the example. >>>=20 >>> By the way how to create a new ticket? Do I need to execute SQL to add = a new >>> one? Is there any authority will review the reported issue and create a >>> ticket when he/she thinks this is really an issue? >>>=20 >>> Cheers, >>> Linyi >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core From robert.cragie@gridmerge.com Wed Nov 10 19:25:06 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1F893A67D0 for ; Wed, 10 Nov 2010 19:25:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.511 X-Spam-Level: X-Spam-Status: No, score=-3.511 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMbQgPKNu0oc for ; Wed, 10 Nov 2010 19:25:04 -0800 (PST) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id 430003A6946 for ; Wed, 10 Nov 2010 19:25:03 -0800 (PST) Received: from client-86-29-103-19.glfd.adsl.virginmedia.com ([86.29.103.19] helo=[192.168.1.80]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) id 1PGNmz-0003P1-On; Thu, 11 Nov 2010 03:25:30 +0000 Message-ID: <4CDB6226.9000802@gridmerge.com> Date: Thu, 11 Nov 2010 03:25:26 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Rene Struik References: <935DB371-B149-486A-8AD2-3B4454C9B172@tzi.org> <4CA3BB54.8050706@gmail.com> <4CA5E8E0.4030503@gmail.com> <4CA6095F.6040403@gmail.com> <4CB48B9B.9010206@gmail.com> <4CC83F61.5060109@gmail.com> <4CDAA76B.5080805@gmail.com> In-Reply-To: <4CDAA76B.5080805@gmail.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050307010203060901040202" Cc: core Subject: Re: [core] bootstrapping concerns still remain all (was Re: concerns re draft-oflynn-core-bootstrapping-02) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 03:25:06 -0000 This is a cryptographically signed message in MIME format. --------------ms050307010203060901040202 Content-Type: multipart/alternative; boundary="------------040504030809060607010000" This is a multi-part message in MIME format. --------------040504030809060607010000 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Hi Rene, Comments inline, bracketed by Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com On 10/11/2010 2:08 PM, Rene Struik wrote: > Dear colleagues: > > I did a quick comparison of draft-oflynn-core-bootstrapping-02 and=20 > draft-oflynn-core-bootstrapping-03; unfortunately, my major overall=20 > concerns expressed in my email as of Wed October 27, 2010 ff still=20 > stand. NOTE: draft-03, which was posted two days ago has been reposted = > a few hours ago as draft-sarikaya-core-sbootstrapping-00, since it=20 > apparently lost of the main authors of previous versions. > > Some preliminary feedback: > 0) main difference with draft-oflynn-core-bootstrapping-02 and=20 > draft-oflynn-core-bootstrapping-03 is in Section 5.1 only > 1) Detailed analysis of deployment scenarios is still missing (since=20 > no changes to Appendix A - examples). We discussed this yesterday. Whilst it may be beneficial to have an = extensive list of use cases, in practice it would take a very long time=20 to document use cases for all the possible systems CoAP could be used=20 in. The aim in the document is to develop a generic bootstrapping=20 architecture which should apply to the majority of use cases based on=20 applying to a more limited set. > 2) Security services to be offered still needs far more detail (I=20 > provided an initial list on September 29, 2010, after the CoAP Conf=20 > Call on desired properties and had *many* email exchanges on this in=20 > context of HIP protocol, but do not really see this reflected. Was this list posted to the reflector? I can only see one e-mail=20 from you on 29th September and that doesn't comprise a list > 3) Consideration for security policies and trust management aspects is = > virtually not there. That's rather vague - please elaborate > 4) It is entirely unclear whether one can rely on a globally unique=20 > (and thereby unchanging id) -- cf. e.g. language in Section 5.1. It is = > unclear what the statement that one MUST support various tyypes of=20 > identities means, whether "various" could mean "1" and how one can=20 > bind the various identities, so as to allow conversion between theses=20 > and mapping this to a static globally unique id. Firstly, various means ">1". Secondly, it is not clear that theses=20 identities need to be bound to each other or the context in which they=20 are used. This does need clarifiying > 5) Multi-domain support: in my mind, intention should be that a device = > may be part of more than one network at the same time and be able to=20 > move from one to the next while maintaining part of its state. I don't think that is the intention of the text. There is=20 separation of administrative domains from access networks here.=20 Resource-constrained single interface devices are unlikely to be part of = more than one network at a time but they may move between networks.=20 However these devices may be registered in more than one administrative=20 domain whilst part of a network. > 6) Authentication/authhorization: An online connectivity to the "trust = > center" (a ZigBee term) is assumed. In many cases, this online=20 > connectivity is simply not there -- one of the main characteristics of = > sensor-style networks is that one cannot always assume connectivity to = > security management functionality, esp. if centralized. It seems that=20 > the centralized ZigBee model has been written-in without any=20 > explanation as to why this would cover deployment scenarios (which, by = > itself, reiterates importance to study deployment scenarios in detail. What is the basis for your claim regarding online connectivity (no=20 reference given)? With regard to initial authentication, all models I am = aware of assume an authentication server somewhere in the network,=20 whether local or further afield. This may not be a fixed static node=20 forever but something has to provide this function. > 7) The PANA Section does not describe what PANA accomplishes and=20 > section is littered with references to external standards (C12.22),=20 > without explanation of how things fit together, whether security=20 > framework and design philosophy match/are complementary, etc., etc.=20 > Moreover, as already mentioned, not clear at all what the security=20 > policy and trust management framework is. The first paragraph tells you what PANA accomplishes - it is an EAP = transport (lower layer) over UDP. I am not sure there is much more to be = said there. I agree with you regarding references to C12.22; these seem=20 unnecessary seeing as the standard is not freely available either (i.e.=20 costs money). Again, please elaborate what you mean regarding the=20 abstract concepts of 'security framework', 'design philosphy', 'security = policy' and 'trust management framework' in this context. > 8) The need for HIP is, after at least 10 email communications still=20 > entirely unclear. Moreover entanglement of name space and crypto space = > is still an issue. Most questions posed over the last month resulted=20 > in comments that one could support/ameliorite better properties, more=20 > efficiencies, disentanglement as work-of-progress items for next=20 > version of HI/HIP-DEX. In my mind, this indicates immaturity and (for=20 > now) unsuitability for standardization. I too have reservations about HIP especially in view of perfectly=20 acceptable and widely-used protocol alternatives. Neverthless, if the=20 concerns can be addressed, I think the HIP authors should be given the=20 opportunity to do so. > 9) The sections on PANA, HIP, 802.1x seem to be more text fillers,=20 > since do not provide any motivation or allow one to grasp concepts=20 > behind things. As Cullen Jennings already articulated in his initial=20 > feedback: it is completely unclear how one would build to this. I agree they need be placed into context along with the rest of the = security. Perhaps this is what you mean by security framework. > > I can provide more feedback once back from the current IEEE 802 meeting= =2E > > Best regards, Rene > > > > On 27/10/2010 11:04 AM, Rene Struik wrote: >> Dear colleagues: >> >> I had a brief look at the bootstrapping draft=20 >> (draft-oflynn-core-bootstrapping-02. Some comments below (I am having = >> some offline discussions on this, but thought to send this to the=20 >> list as well): >> >> I miss a detailed analysis of deployment scenarios to be considered=20 >> as guidance intodesign, so as to have as very minimal benchmark=20 >> whether all those crypto protocols actually enable the deployment=20 >> scenarios one has in mind. To me, it seems to have merit to discuss=20 >> the whole spectrum and end up with cryptographic building blocks,=20 >> security protocols, and security policies and accompanying=20 >> enforcement mechanism for trust policies that would fit the=20 >> operational scenarios. >> >> I would favor not sprinkling protocol acronyms into any draft too=20 >> early (since, in my mind, this pushes into a particular direction,=20 >> and notalways with merit). As an example, right now I do not see how, = >> e.g., HIP or cryptographically generated addresses (802.1-like) would = >> fit in.Similarly, e.g., PANA does not seem to work in heterogeneous=20 >> trustenvironments, assumes online connectivity of a "mothership"=20 >> node, and does not seem to include consideration of how to move from=20 >> one mothership node to the next (or, e.g., if one has an=20 >> authenticator, how to make this work with single-hop/MAC security). >> >> I also miss security objectives and design considerations, such as=20 >> "separation of concern" and no entanglement of concepts from=20 >> different disciplines in the document. >> >> BTW - I mentioned some of this in email correspondence after the last = >> CoRE conf call (Wed September 29, 2010). So far, I have not seen too=20 >> much traffic on this. Moreover, I have not seen any adequate answers=20 >> as to what makes, e.g., HIP features an attractive fit for CoRE-like=20 >> environments. >> >> Best regards, Rene >> >> [excerpt email RS as of October 1, 2010, 12:16pm EDT] >> >> In my mind, properties of suitable authenticated key agreement=20 >> schemes should include (a) key establishment; (b) implicit key=20 >> authentication; (c) key confirmation; (d) mutual entity=20 >> authentication; (e) forward secrecy; (f) {perhaps} some more esoteric = >> properties (key compromise impersonation resilience, etc.). >> >> Moreover, the "name space" (device identifiers) and the=20 >> "cryptographic space" (public keys, etc.) should be independent, so=20 >> that this would allow trust lifecycle management to be reduced to=20 >> proper management of device identifiers (i.e., *no* entanglement of=20 >> concepts from different disciplines). >> >> >> On 12/10/2010 12:23 PM, Rene Struik wrote: >>> Hi Tobias: >>> >>> Thanks for your note. >>> >>> Does your "ascii art" description, Step 1)-3) allow the scenario, whe= re (a) one assigns a node id and imprints this (e.g., blowing fuse during= chip testing); >>> (b) has a node generating its own long-term public/private key pair a= nd outputting its node id and public key (e.g., during chip testing -- th= is would >>> correspond to registering a public key with an RA); (c) have CA creat= e a certificate in different process and return this value at later produ= ction/ >>> personalization stage? >>> >>> Right now, from Section 4.1.3 of draft-ietf-hip-rfc5201-bis-02, I get= the impression that HIP does execute an authenticated DH key agreement s= cheme. If so, >>> this makes me wonder how HIP differentiates from protocols, such as E= CMQV and, e.g., HMQV, which are all not that much more expensive than ECD= H. If the >>> difference is in the "puzzle" element, couldn't one just add somethin= g similar to a well-known authenticated scheme that is already standardiz= ed with, e.g., >>> NIST? >>> >>> As to forward secrecy: reason to include this is that many sensor-typ= e nodes can be expected to be physically unprotected (e.g., screwed on a = street lamp >>> post, on a garage roof, etc.) and, therefore, may be more vulnerable = to device compromise over time (esp. since one cannot expect all nodes to= be tamper >>> resistant or tamper evident). By virtue of forward secrecy, compromis= e over time does not compromise the whole device's history, but only the = current set of >>> symmetric keys (note: I make some shortcuts in my reasoning on key ma= nagement here). Admittedly, my list of security properties is based on "d= esired" >>> functionality and does not exclude functionality that may require, e.= g., public-key crypto constructs. However, from a user's perspective, the= only thing that >>> matters is features and not what is "under the hood", as long as that= is not cost-prohibitive (which I contend it is not -- cf., e.g., Section= 3.2 of >>> draft-struik-6lowapp-security-considerations-00). (BTW - All other de= sired security properties I listed have an underlying rationale.) >>> >>> It would help to have a succinct mathematical description of the prot= ocol you suggest (stripped from formatting issues) and describe claimed c= ryptographic >>> properties. I would be happy to give this a look and review. >>> >>> Please feel free to provide to me in person if this would be cumberso= me material for non-crypto people on the mailing list. >>> >>> Best regards, Rene >>> >>> >>> [excerpt email RS as of October 1, 2010, 12:16pm EDT and response Tob= ias Heer as of October 7, 2010, 5:36am EDT] >>> >>> To aid clarity and succinct discussions, it would help to have a clea= r description of desired security services to be offered by an authentica= ted >>> key agreement scheme and see whether a candidate scheme (such as, who= knows, HIP) satisfies these. If you could provide a succinct description= of >>> the HIP protocol itself, so that this is easy to understand, and coul= d provide what properties it has, that would be of great help! >>> > =20 >>> > In my mind, properties of suitable authenticated key agreement sch= emes should include (a) key establishment; (b) implicit key authenticatio= n; >>> (c) key confirmation; (d) mutual entity authentication; (e) forward s= ecrecy; (f) {perhaps} some more esoteric properties (key compromise >>> impersonation resilience, etc.). >>> > >>> Is this list valid for all targeted use cases? If yes, it is a very h= andy list to check against. However, (e) forward secrecy seems to >>> rule a number of "cheaper" cryptographic approaches (e.g., pre-shared= keys) and might not be relevant to all use cases (especially small >>> setups). However, I am not absolutely firm with the envisaged scenari= os in CORE. >>>> > Moreover, the "name space" (device identifiers) and the "cryptogr= aphic space" (public keys, etc.) should be independent, so that this woul= d >>>> allow trust lifecycle management to be reduced to proper management = of device identifiers (i.e.,*no* entanglement of concepts from different= >>>> disciplines). >>> >>> Does the "*no* entanglement of concepts from different disciplines" = also mean that a concept like the id/loc split should be used to avoid >>> entanglement of routing and naming? >>> >>> >>> >>> >>> >>> On 07/10/2010 5:36 AM, Tobias Heer wrote: >>>>> To aid clarity and succinct discussions, it would help to have a cl= ear description of desired security services to be offered by an authenti= cated key agreement scheme and see whether a candidate scheme (such as, w= ho knows, HIP) satisfies these. If you could provide a succinct descripti= on of the HIP protocol itself, so that this is easy to understand, and co= uld provide what properties it has, that would be of great help! >>>>> > =20 >>>>> > In my mind, properties of suitable authenticated key agreement s= chemes should include (a) key establishment; (b) implicit key authenticat= ion; (c) key confirmation; (d) mutual entity authentication; (e) forward = secrecy; (f) {perhaps} some more esoteric properties (key compromise impe= rsonation resilience, etc.). >>>>> > =20 >>>> Is this list valid for all targeted use cases? If yes, it is a very = handy list to check against. However, (e) forward secrecy seems to rule a= number of "cheaper" cryptographic approaches (e.g., pre-shared keys) and= might not be relevant to all use cases (especially small setups). Howeve= r, I am not absolutely firm with the envisaged scenarios in CORE. >>>> >>>>> > Moreover, the "name space" (device identifiers) and the "cryptog= raphic space" (public keys, etc.) should be independent, so that this wou= ld allow trust lifecycle management to be reduced to proper management of= device identifiers (i.e.,*no* entanglement of concepts from different d= isciplines). >>>> >>>> Does the "*no* entanglement of concepts from different disciplines"= also mean that a concept like the id/loc split should be used to avoid e= ntanglement of routing and naming? >>>> >>> >>> >>> --=20 >>> email:rstruik.ext@gmail.com >>> Skype: rstruik >>> cell: +1 (647) 867-5658 >>> USA Google voice: +1 (415) 690-7363 >> >> >> --=20 >> email:rstruik.ext@gmail.com >> Skype: rstruik >> cell: +1 (647) 867-5658 >> USA Google voice: +1 (415) 690-7363 > > > --=20 > email:rstruik.ext@gmail.com > Skype: rstruik > cell: +1 (647) 867-5658 > USA Google voice: +1 (415) 690-7363 > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --------------040504030809060607010000 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Rene,

    Comments inline, bracketed by <RCC></RCC>

    Robert

    Robert Cragie (Pacific Gas & Electric)

    Gridmerge Ltd.
    89 Greenfield Crescent,
    Wakefield, WF4 4WA, UK
    +44 1924 910888
    +1 415 513 0064
    http://www.gridmerge.com


    On 10/11/2010 2:08 PM, Rene Struik wrote:
    Dear colleagues:

    I did a quick comparison of draft-oflynn-core-bootstrapping-02 and draft-oflynn-core-bootstrapping-03; unfortunately, my major overall concerns expressed in my email as of Wed October 27, 2010 ff still stand. NOTE: draft-03, which was posted two days ago has been reposted a few hours ago as draft-sarikaya-core-sbootstrapping-00, since it apparently lost of the main authors of previous versions.

    Some preliminary feedback:
    0) main difference with draft-oflynn-core-bootstrapping-02 and draft-oflynn-core-bootstrapping-03 is in Section 5.1 only
    1) Detailed analysis of deployment scenarios is still missing (since no changes to Appendix A - examples).
    <RCC>We discussed this yesterday. Whilst it may be beneficial to have an extensive list of use cases, in practice it would take a very long time to document use cases for all the possible systems CoAP could be used in. The aim in the document is to develop a generic bootstrapping architecture which should apply to the majority of use cases based on applying to a more limited set.</RCC>
    2)= Security services to be offered still needs far more detail (I provided an initial list on September 29, 2010, after the CoAP Conf Call on desired properties and had *many* email exchanges on this in context of HIP protocol, but do not really see this reflected.
    <RCC>Was this list posted to the reflector? I can only see one e-mail from you on 29th September and that doesn't comprise a list</RCC>
    3)= Consideration for security policies and trust management aspects is virtually not there.
    <RCC>That's rather vague - please elaborate</RCC>
    4)= It is entirely unclear whether one can rely on a globally unique (and thereby unchanging id) -- cf. e.g. language in Section 5.1. It is unclear what the statement that one MUST support various tyypes of identities means, whether "various" could mean "1" and how one can bind the various identities, so as to allow conversion between theses and mapping this to a static globally unique id.
    <RCC>Firstly, various means ">1". Secondly, it is not clear that theses identities need to be bound to each other or the context in which they are used. This does need clarifiying</RCC>
    5)= Multi-domain support: in my mind, intention should be that a device may be part of more than one network at the same time and be able to move from one to the next while maintaining part of its state.
    <RCC>I don't think that is the intention of the text. There is separation of administrative domains from access networks here. Resource-constrained single interface devices are unlikely to be part of more than one network at a time but they may move between networks. However these devices may be registered in more than one administrative domain whilst part of a network.</RCC>
    6)= Authentication/authhorization: An online connectivity to the "trust center" (a ZigBee term) is assumed. In many cases, this online connectivity is simply not there -- one of the main characteristics of sensor-style networks is that one cannot always assume connectivity to security management functionality, esp. if centralized. It seems that the centralized ZigBee model has been written-in without any explanation as to why this would cover deployment scenarios (which, by itself, reiterates importance to study deployment scenarios in detail.
    <RCC>What is the basis for your claim regarding online connectivity (no reference given)? With regard to initial authentication, all models I am aware of assume an authentication server somewhere in the network, whether local or further afield. This may not be a fixed static node forever but something has to provide this function.</RCC>
    7)= The PANA Section does not describe what PANA accomplishes and section is littered with references to external standards (C12.22), without explanation of how things fit together, whether security framework and design philosophy match/are complementary, etc., etc. Moreover, as already mentioned, not clear at all what the security policy and trust management framework is.
    <RCC>The first paragraph tells you what PANA accomplishes - it is an EAP transport (lower layer) over UDP. I am not sure there is much more to be said there. I agree with you regarding references to C12.22; these seem unnecessary seeing as the standard is not freely available either (i.e. costs money). Again, please elaborate what you mean regarding the abstract concepts of 'security framework', 'design philosphy', 'security policy' and 'trust management framework' in this context.</RCC>
    8)= The need for HIP is, after at least 10 email communications still entirely unclear. Moreover entanglement of name space and crypto space is still an issue. Most questions posed over the last month resulted in comments that one could support/ameliorite better properties, more efficiencies, disentanglement as work-of-progress items for next version of HI/HIP-DEX. In my mind, this indicates immaturity and (for now) unsuitability for standardization.
    <RCC>I too have reservations about HIP especially in view of perfectly acceptable and widely-used protocol alternatives. Neverthless, if the concerns can be addressed, I think the HIP authors should be given the opportunity to do so.</RCC>
    9)= The sections on PANA, HIP, 802.1x seem to be more text fillers, since do not provide any motivation or allow one to grasp concepts behind things. As Cullen Jennings already articulated in his initial feedback: it is completely unclear how one would build to this.
    <RCC>I agree they need be placed into context along with the rest of the security. Perhaps this is what you mean by security framework.</RCC>
    I can provide more feedback once back from the current IEEE 802 meeting.

    Best regards, Rene



    On 27/10/2010 11:04 AM, Rene Struik wrote:
    Dear colleagues:

    I had a brief look at the bootstrapping draft (draft-oflynn-core-bootstrapping-02. Some comments below (I am having some offline discussions on this, but thought to send this to the list as well):

    I miss a detailed analysis of deployment scenarios to be considered as guidance into design, so as to have as very minimal benchmark whether all those crypto protocols actually enable the deployment scenarios one has in mind. To me, it seems to have merit to discuss the whole spectrum and end up with cryptographic building blocks, security protocols, and security policies and accompanying enforcement mechanism for trust policies that would fit the operational scenarios.

    I would favor not sprinkling protocol acronyms into any draft too early (since, in my mind, this pushes into a particular direction, and not always with merit). As an example, right now I do not see how, e.g., HIP or cryptographically generated addresses (802.1-like) would fit in.<= font size=3D"2">     Si= milarly, e.g., PANA does not seem to work in heterogeneous trust en= vironments, assumes online connectivity of a "mothership" node, and does not seem to include consideration of how to move from one=A0 mothership node to the next (or, e.g., if one has an authenticator, how to make this work with single-hop/MAC security).

    I also miss security objectives and design considerations, such as "separation of concern" and no entanglement of concepts from different disciplines in the document.

    BTW - I mentioned some of this in email correspondence after the last CoRE conf call (Wed September 29, 2010). So far, I have not seen too much traffic on this. Moreover, I have not seen any adequate answers as to what makes, e.g., HIP features an attractive fit for CoRE-like environments.

    Best regards, Rene

    [excerpt email RS as of October 1, 2010, 12:16pm EDT]

    In my mind, properties of suitable authenticated key agreement schemes should include (a) key establishment; (b) implicit key authentication; (c) key confirmation; (d) mutual entity authentication; (e) forward secrecy; (f) {perhaps} some more esoteric properties (key compromise impersonation resilience, etc.).

    Moreover, the "name space" (device identifiers) and the "cryptographic space" (public keys, etc.) should be independent, so that this would allow trust lifecycle management to be reduced to proper management of device identifiers (i.e., *no* entanglement of concepts from different disciplines).


    On 12/10/2010 12:23 PM, Rene Struik wrote: 
    Hi Tobias:

Thanks for your note.=20

Does your "ascii art" description, Step 1)-3) allow the scenario, where (=
a) one assigns a node id and imprints this (e.g., blowing fuse during chi=
p testing);=20
(b) has a node generating its own long-term public/private key pair and o=
utputting its node id and public key (e.g., during chip testing -- this w=
ould=20
correspond to registering a public key with an RA); (c) have CA create a =
certificate in different process and return this value at later productio=
n/
personalization stage?

Right now, from Section 4.1.3 of draft-ietf-hip-rfc5201-bis-02, I get the=
 impression that HIP does execute an authenticated DH key agreement schem=
e. If so,
this makes me wonder how HIP differentiates from protocols, such as ECMQV=
 and, e.g., HMQV, which are all not that much more expensive than ECDH. I=
f the=20
difference is in the "puzzle" element, couldn't one just add something si=
milar to a well-known authenticated scheme that is already standardized w=
ith, e.g.,=20
NIST?

As to forward secrecy: reason to include this is that many sensor-type no=
des can be expected to be physically unprotected (e.g., screwed on a stre=
et lamp=20
post, on a garage roof, etc.) and, therefore, may be more vulnerable to d=
evice compromise over time (esp. since one cannot expect all nodes to be =
tamper=20
resistant or tamper evident). By virtue of forward secrecy, compromise ov=
er time does not compromise the whole device's history, but only the curr=
ent set of
symmetric keys (note: I make some shortcuts in my reasoning on key manage=
ment here). Admittedly, my list of security properties is based on "desir=
ed"=20
functionality and does not exclude functionality that may require, e.g., =
public-key crypto constructs. However, from a user's perspective, the onl=
y thing that
matters is features and not what is "under the hood", as long as that is =
not cost-prohibitive (which I contend it is not -- cf., e.g., Section 3.2=
 of
draft-struik-6lowapp-security-considerations-00). (BTW - All other desire=
d security properties I listed have an underlying rationale.)

It would help to have a succinct mathematical description of the protocol=
 you suggest (stripped from formatting issues) and describe claimed crypt=
ographic
properties. I would be happy to give this a look and review.=20

Please feel free to provide to me in person if this would be cumbersome m=
aterial for non-crypto people on the mailing list.

Best regards, Rene


[excerpt email RS as of October 1, 2010, 12:16pm EDT and response Tobias =
Heer as of October 7, 2010, 5:36am EDT]

To aid clarity and succinct discussions, it would help to have a clear de=
scription of desired security services to be offered by an authenticated =

key agreement scheme and see whether a candidate scheme (such as, who kno=
ws, HIP) satisfies these. If you could provide a succinct description of =

the HIP protocol itself, so that this is easy to understand, and could pr=
ovide what properties it has, that would be of great help!
> 
> In my mind, properties of su=
itable authenticated key agreement schemes should include (a) key establi=
shment; (b) implicit key authentication;=20
(c) key confirmation; (d) mutual entity authentication; (e) forward secre=
cy; (f) {perhaps} some more esoteric properties (key compromise=20
impersonation resilience, etc.).
>
    Is this list valid for all targeted use cases? If yes, it =
is a very handy list to check against. However, (e) forward secrecy seems=
 to=20
rule a number of "cheaper" cryptographic approaches (e.g., pre-shared key=
s) and might not be relevant to all use cases (especially small=20
setups). However, I am not absolutely firm with the envisaged scenarios i=
n CORE.

    > Moreover, t=
he "name space" (device identifiers) and the "cryptographic space" (publi=
c keys, etc.) should be independent, so that this would 
    allow trust lifecycle management to be reduced to proper=
 management of device identifiers (i.e., *no* =
entanglement of concepts from different 
    disciplines).

    =20
Does the "*n=
o* entanglement of concepts from d=
ifferent disciplines" also mean that a concept like the id/loc split shou=
ld be used to avoid=20
entanglement of routing and naming?




    On 07/10/2010 5:36 AM, Tobias Heer wrote: 
    To aid clarity and succinct discussions, it =
would help to have a clear description of desired security services to be=
 offered by an authenticated key agreement scheme and see whether a candi=
date scheme (such as, who knows, HIP) satisfies these. If you could provi=
de a succinct description of the HIP protocol itself, so that this is eas=
y to understand, and could provide what properties it has, that would be =
of great help!
> 
> In my mind, properties of su=
itable authenticated key agreement schemes should include (a) key establi=
shment; (b) implicit key authentication; (c) key confirmation; (d) mutual=
 entity authentication; (e) forward secrecy; (f) {perhaps} some more esot=
eric properties (key compromise impersonation resilience, etc.).
> 

    Is this list valid for all targeted use cases?=
 If yes, it is a very handy list to check against. However, (e) forward s=
ecrecy seems to rule a number of "cheaper" cryptographic approaches (e.g.=
, pre-shared keys) and might not be relevant to all use cases (especially=
 small setups). However, I am not absolutely firm with the envisaged scen=
arios in CORE.


    > Moreover, the "name space" (device identifiers) and the "cryptographic s=
pace" (public keys, etc.) should be independent, so that this would allow=
 trust lifecycle management to be reduced to proper management of device =
identifiers (i.e., =
*no* entanglement of concep=
ts from different disciplines).

    =20
Does the "*n=
o* entanglement of concepts from d=
ifferent disciplines" also mean that a concept like the id/loc split shou=
ld be used to avoid entanglement of routing and naming?




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


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


    --=20
email: rstruik.ext@gmail.com
Skype: rstruik
cell: +1 (647) 867-5658
USA Google voice: +1 (415) 690-7363
    
_______________________________________________
core mailing list
core@=
ietf.org
https://www.ietf.org/mailman/listinfo/core
    --------------040504030809060607010000-- --------------ms050307010203060901040202 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRZTCC BN0wggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UE BhMCR0IxGzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEa MBgGA1UECgwRQ29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJV UzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUg VVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWls MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5 ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqk kqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWL eeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJ Q/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udl y/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0jBBgwFoAUoBEKIz6W8Qfs 4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQE AwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAR BgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5jb21vZG9j YS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwuY29t b2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvz bRx8NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12 jMOCAU9sAPMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxog L5dMUbtGB8SKN04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNB pEMD9O3vMyfbOeAUTibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mY HK9/FX8wggY+MIIFJqADAgECAhEAtlwUjTTxveqQY8soFvBYEjANBgkqhkiG9w0BAQUFADCB rjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEe MBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVz ZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIGFuZCBFbWFpbDAeFw0xMDA4MzAwMDAwMDBaFw0xMTA4MzAyMzU5NTlaMIHkMTUwMwYD VQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBFUlNPTkEgTk9UIFZBTElEQVRFRDFGMEQG A1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5u ZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMyBDb21vZG8gTGltaXRlZDEWMBQGA1UE AxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVy Z2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtAJ+m9Tgd3li8BgAIRth Gtth3YcCbhLPjfAcnDKcEGSrkZqao79Jg2uDW62IOwNCq9ae3VweBlvg3UUVu8upXzgDR/jF z4S1ZNk1if6V9QEiyBHdE1qMUQeeytedk3qw93CU5snWiXgVRacU8H8Dv+WJPsb4WYAH4MBz aJMI2N/E5XGGYpKFj9vxnEiQ7h83jXxw3Ee2rXCCbhJEci/tUl+Cx40pB3m7nlEdASY+A3tq JLIiG8Argf0+bWaxmuSUihKoakhHQruAylWY9EVtbKg8SACYZhdHCx2+ZSSrxbbAKSv0cDk0 0vQPvgH5GEi6zSB9QvqWCdBH/rL0XfV5jQIDAQABo4ICHTCCAhkwHwYDVR0jBBgwFoAUiYJn fcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFGkahOqOBMk95XAb8dpcRdaef8AYMA4GA1Ud DwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIx AQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzAp BggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCB mjBMoEqgSIZGaHR0cDovL2NybC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRB dXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0 L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYB BQUHAQEEYDBeMDYGCCsGAQUFBzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFD bGllbnRDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNV HREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEB ADcjSJQKgVIfD/IztFrhx2YqR9mKsDs3XakKd4hUoeunHgskiaMIQY2Kcfob48OuzrfY73rN fNoaqr5LZwDeVflMnZd0rPcTA9rAHq5l/qwdSta3k0xvBui0NAtOrSBdbqC4vggLKuZvoR2o 7mSbxSSBZHuVLObx/E5E+D5fjWC7ffNvr9y/uFXeCYFsM+Hc9VPIZ+cAY7JQFJEK/Nuti2QH IIxdR91N2vHuNXWIPROPFMl7y8ltO/fONwhxMcY2dH4JkDH6pdNzMtzykvsO0NeiRHnNlS4K A8aD9RaBR8FNQHq+JusC2tf11qdHBpHrVAK7dHodKDnbRr2t9VdrU2owggY+MIIFJqADAgEC AhEAtlwUjTTxveqQY8soFvBYEjANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJU UlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNV BAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0x MDA4MzAwMDAwMDBaFw0xMTA4MzAyMzU5NTlaMIHkMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3Qg TmV0d29yayAtIFBFUlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENv bmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0G A1UECxMWKGMpMjAwMyBDb21vZG8gTGltaXRlZDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEq MCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtAJ+m9Tgd3li8BgAIRthGtth3YcCbhLPjfAcnDKcEGSr kZqao79Jg2uDW62IOwNCq9ae3VweBlvg3UUVu8upXzgDR/jFz4S1ZNk1if6V9QEiyBHdE1qM UQeeytedk3qw93CU5snWiXgVRacU8H8Dv+WJPsb4WYAH4MBzaJMI2N/E5XGGYpKFj9vxnEiQ 7h83jXxw3Ee2rXCCbhJEci/tUl+Cx40pB3m7nlEdASY+A3tqJLIiG8Argf0+bWaxmuSUihKo akhHQruAylWY9EVtbKg8SACYZhdHCx2+ZSSrxbbAKSv0cDk00vQPvgH5GEi6zSB9QvqWCdBH /rL0XfV5jQIDAQABo4ICHTCCAhkwHwYDVR0jBBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0w HQYDVR0OBBYEFGkahOqOBMk95XAb8dpcRdaef8AYMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMB Af8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEE BAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6 Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0cDovL2Ny bC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVt YWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xp ZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQUF BzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwYB BQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRtyb2JlcnQuY3Jh Z2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBADcjSJQKgVIfD/IztFrhx2Yq R9mKsDs3XakKd4hUoeunHgskiaMIQY2Kcfob48OuzrfY73rNfNoaqr5LZwDeVflMnZd0rPcT A9rAHq5l/qwdSta3k0xvBui0NAtOrSBdbqC4vggLKuZvoR2o7mSbxSSBZHuVLObx/E5E+D5f jWC7ffNvr9y/uFXeCYFsM+Hc9VPIZ+cAY7JQFJEK/Nuti2QHIIxdR91N2vHuNXWIPROPFMl7 y8ltO/fONwhxMcY2dH4JkDH6pdNzMtzykvsO0NeiRHnNlS4KA8aD9RaBR8FNQHq+JusC2tf1 1qdHBpHrVAK7dHodKDnbRr2t9VdrU2oxggRgMIIEXAIBATCBxDCBrjELMAkGA1UEBhMCVVMx CzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVT RVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0 BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIR ALZcFI008b3qkGPLKBbwWBIwCQYFKw4DAhoFAKCCAnAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTAxMTExMDMyNTI2WjAjBgkqhkiG9w0BCQQxFgQUnGQb XfhnXKIkfH1QxcLIcHgKtdkwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJV VDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4t VVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQC2XBSNNPG96pBj yygW8FgSMIHXBgsqhkiG9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgT AlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBO ZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIRALZcFI008b3q kGPLKBbwWBIwDQYJKoZIhvcNAQEBBQAEggEAs1d9QdtjRBVwu4XFKTmZSDlFnhAIxLb3T7jh 90fZd8RMRuD2oUxIXWd1PeShi/ZPW95vBAhAO9Ovj2Im5fmaohG/m4Vi73n5qpEdDi1ANWKw oqqxOjHK1yOcT+no1dIhlhjsEclaJZuOBeUrRY9Y6WGjtk4XXMaYmBDBs2jsfqRTMjwdBWhY Zik159BymOWzG1TuV1ugpFPplk1duBcxpcsSQ4SGO1yatx4xJlWbPE1ekHusluhf+YFzeX5w e/4XtcJDbIzdVol2VoU8xaLYIsUTEjmwsPz9VCPmCwdpquc/RYixmtzrWToSKyGqiLatZxvX KPHW+3PIQx1hlNUEPAAAAAAAAA== --------------ms050307010203060901040202-- From yoshihiro.ohba@toshiba.co.jp Wed Nov 10 20:02:28 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB3E93A6874 for ; Wed, 10 Nov 2010 20:02:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.089 X-Spam-Level: X-Spam-Status: No, score=-4.089 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HVMQzwYRzEyi for ; Wed, 10 Nov 2010 20:02:28 -0800 (PST) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by core3.amsl.com (Postfix) with ESMTP id D000E3A682C for ; Wed, 10 Nov 2010 20:02:27 -0800 (PST) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id oAB42tmK011660 for ; Thu, 11 Nov 2010 13:02:55 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id oAB42tcj017172 for core@ietf.org; Thu, 11 Nov 2010 13:02:55 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id PAA17168; Thu, 11 Nov 2010 13:02:55 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id oAB42tgX024009 for ; Thu, 11 Nov 2010 13:02:55 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id oAB42s8O017949; Thu, 11 Nov 2010 13:02:54 +0900 (JST) Received: from [133.199.75.54] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0LBP0023UCKTSH40@mail.po.toshiba.co.jp> for core@ietf.org; Thu, 11 Nov 2010 13:02:54 +0900 (JST) Date: Thu, 11 Nov 2010 13:02:46 +0900 From: Yoshihiro Ohba In-reply-to: <4CDAA76B.5080805@gmail.com> To: core@ietf.org Message-id: <4CDB6AE6.9050508@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-2022-JP Content-transfer-encoding: 7bit References: <935DB371-B149-486A-8AD2-3B4454C9B172@tzi.org> <4CA3BB54.8050706@gmail.com> <4CA5E8E0.4030503@gmail.com> <4CA6095F.6040403@gmail.com> <4CB48B9B.9010206@gmail.com> <4CC83F61.5060109@gmail.com> <4CDAA76B.5080805@gmail.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 Subject: Re: [core] bootstrapping concerns still remain all (was Re: concerns re draft-oflynn-core-bootstrapping-02) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 04:02:28 -0000 (2010/11/10 23:08), Rene Struik wrote: (snip) > 7) The PANA Section does not describe what PANA accomplishes and > section is littered with references to external standards (C12.22), > without explanation of how things fit together, whether security > framework and design philosophy match/are complementary, etc., etc. > Moreover, as already mentioned, not clear at all what the security > policy and trust management framework is. W.r.t, C12.22, the protocol is referred as an example protocol that is used by resource-constrained devices and does not have a dynamic keying mechanism. To bootstrap such a protocol, out-of-band protocol is needed to dynamically generate keys used by the protocol. If there is an IETF protocol that is used by resource-constrained devices and does not have a dynamic keying mechanism, we can replace reference to C12.22 with such an IETF protocol. Yoshihiro Ohba From likepeng@huawei.com Wed Nov 10 22:53:01 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E27133A680D for ; Wed, 10 Nov 2010 22:53:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.546 X-Spam-Level: X-Spam-Status: No, score=-1.546 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIMRj3iOAUiF for ; Wed, 10 Nov 2010 22:52:58 -0800 (PST) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 2FDD23A67B4 for ; Wed, 10 Nov 2010 22:52:58 -0800 (PST) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LBP0091TKGWR8@szxga02-in.huawei.com> for core@ietf.org; Thu, 11 Nov 2010 14:53:20 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LBP00A4FKGWBR@szxga02-in.huawei.com> for core@ietf.org; Thu, 11 Nov 2010 14:53:20 +0800 (CST) Received: from MICROSOF4AFFB7 (dhcp-7525.meeting.ietf.org [130.129.117.37]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LBP0092VKGRWX@szxml01-in.huawei.com> for core@ietf.org; Thu, 11 Nov 2010 14:53:20 +0800 (CST) Date: Thu, 11 Nov 2010 14:55:59 +0800 From: Kepeng Li To: 'core' Message-id: <006f01cb816d$81d52900$857f7b00$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_CpruvYwqoYMj8BkGmQnkZQ)" Content-language: zh-cn Thread-index: AcuBbX7JoG4Gy2AlSGSskF9zj3Bung== Subject: [core] Payload in CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 06:53:01 -0000 This is a multi-part message in MIME format. --Boundary_(ID_CpruvYwqoYMj8BkGmQnkZQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, When I read draft-ietf-core-coap-03, I find no explanation about the payload. Do we need to have one field to specify the length of the payload? And also how can the receiver know that it is the end of the whole message? Should this be done by the UDP? I notice that there is a length field in UDP. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Ver| T | OC | Code | Transaction ID +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options (if any) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload (if any) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Thanks, Cheers Kepeng --Boundary_(ID_CpruvYwqoYMj8BkGmQnkZQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

    Hi,

     

    When I read = draft-ietf-core-coap-03, I find no explanation about the payload.

     

    Do we need to have one field to = specify the length of the payload? And also how can the receiver know that it is the = end of the whole message?

     

    Should this be done by the UDP? = I notice that there is a length field in UDP.

     

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       |Ver| T |  = OC   |      Code     |        Transaction ID         =

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       |   = Options (if any) ...

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       |   = Payload (if any) ...

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     

    Thanks,

    Cheers

    Kepeng

    --Boundary_(ID_CpruvYwqoYMj8BkGmQnkZQ)-- From tianlinyi@huawei.com Wed Nov 10 23:38:48 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E5F73A699D for ; Wed, 10 Nov 2010 23:38:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.754 X-Spam-Level: * X-Spam-Status: No, score=1.754 tagged_above=-999 required=5 tests=[AWL=-0.202, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_CHARSET_FARAWAY=2.45, NORMAL_HTTP_TO_IP=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUp5HeVjmGeR for ; Wed, 10 Nov 2010 23:38:47 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 475953A695D for ; Wed, 10 Nov 2010 23:38:47 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LBP00EDJML1XN@szxga03-in.huawei.com> for core@ietf.org; Thu, 11 Nov 2010 15:39:02 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LBP00IA1ML1RC@szxga03-in.huawei.com> for core@ietf.org; Thu, 11 Nov 2010 15:39:01 +0800 (CST) Received: from [130.129.117.92] (dhcp-755c.meeting.ietf.org [130.129.117.92]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LBP0090SMKWCG@szxml02-in.huawei.com>; Thu, 11 Nov 2010 15:39:01 +0800 (CST) Date: Thu, 11 Nov 2010 15:38:53 +0800 From: Linyi Tian In-reply-to: <4B3B33CA-DE0B-476E-9B5F-B06C678136AF@tzi.org> To: Carsten Bormann , core@ietf.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset=GB2312 Content-transfer-encoding: quoted-printable Thread-topic: [core] Plugfest continuation on Thursday Thread-index: AcuBc30VO9Q0VRBFm0aaWBeskp435Q== User-Agent: Microsoft-Entourage/12.25.0.100505 Subject: Re: [core] Plugfest continuation on Thursday X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 07:38:48 -0000 I am now In the terminal room but didn't see any test activity here. Did I entered the wrong room? (Lotus, Garden Wing Level 2) Cheers, Linyi On 10-11-10 =CF=C2=CE=E711:03, "Carsten Bormann" wrote: > This has been announced in the WG meeting, but not explicitly on the mail= ing > list: >=20 > We will have an informal second edition of the CoAP Plugfest on Thursday = at > 1530 Beijing time in the Shangri-La terminal room (Lotus, in Garden Wing = Level > 2). >=20 > 1530 Beijing time is 0830 CET/0930 EET, so this time the Europeans will h= ave > less of a hard time joining in remotely. (On the other hand, much of the= US > will already sleep.) >=20 > Focus will be on finishing Sunday's block test and getting more pairs of > observe done, but of course everyone is welcome to test what is important= to > them. >=20 > Those onsite are likely to converge on a dinner later. >=20 > You can prepare (find servers etc.) at: > http://trac.tools.ietf.org/wg/core/trac/wiki/PlugFest > Don't miss the CoAP resource directory server: > http://184.106.150.250 (more details on the above wiki page). >=20 > Gruesse, Carsten >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From tianlinyi@huawei.com Thu Nov 11 00:48:17 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3AF73A6A24 for ; Thu, 11 Nov 2010 00:48:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.776 X-Spam-Level: * X-Spam-Status: No, score=1.776 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_CHARSET_FARAWAY=2.45, NORMAL_HTTP_TO_IP=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sJNCJcnuHl+W for ; Thu, 11 Nov 2010 00:48:17 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 3E2A63A6A66 for ; Thu, 11 Nov 2010 00:48:12 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LBP0037QPSUSE@szxga03-in.huawei.com> for core@ietf.org; Thu, 11 Nov 2010 16:48:30 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LBP00HAMPSOV1@szxga03-in.huawei.com> for core@ietf.org; Thu, 11 Nov 2010 16:48:29 +0800 (CST) Received: from [130.129.117.92] (dhcp-755c.meeting.ietf.org [130.129.117.92]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LBP00EJ3PSNQJ@szxml02-in.huawei.com> for core@ietf.org; Thu, 11 Nov 2010 16:48:27 +0800 (CST) Date: Thu, 11 Nov 2010 16:48:21 +0800 From: Linyi Tian In-reply-to: To: core@ietf.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset=GB2312 Content-transfer-encoding: quoted-printable Thread-topic: [core] Plugfest continuation on Thursday Thread-index: AcuBc30VO9Q0VRBFm0aaWBeskp435QACbRQc User-Agent: Microsoft-Entourage/12.25.0.100505 Subject: Re: [core] Plugfest continuation on Thursday X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 08:48:17 -0000 Now we have Carsten here to lead the test:) I guess people were drunk by th= e coffee just now. Cheers, Linyi On 10-11-11 =CF=C2=CE=E73:38, "Linyi Tian" wrote: > I am now In the terminal room but didn't see any test activity here. Did > I entered the wrong room? (Lotus, Garden Wing Level 2) Cheers, Linyi On > 10-11-10 =CF=C2=CE=E711:03, "Carsten Bormann" wrote: > This has been > announced in the WG meeting, but not explicitly on the mailing > list: > > We > will have an informal second edition of the CoAP Plugfest on Thursday at > > 1530 Beijing time in the Shangri-La terminal room (Lotus, in Garden Wing > Level > 2). > > 1530 Beijing time is 0830 CET/0930 EET, so this time the > Europeans will have > less of a hard time joining in remotely. (On the other > hand, much of the US > will already sleep.) > > Focus will be on finishing > Sunday's block test and getting more pairs of > observe done, but of course > everyone is welcome to test what is important to > them. > > Those onsite are > likely to converge on a dinner later. > > You can prepare (find servers etc.) > at: > http://trac.tools.ietf.org/wg/core/trac/wiki/PlugFest > Don't miss the > CoAP resource directory server: > http://184.106.150.250 (more details on the > above wiki page). > > Gruesse, Carsten > > > _______________________________________________ > core mailing list > > core@ietf.org >=20 > https://www.ietf.org/mailman/listinfo/core _________________________________ > ______________ core mailing > list core@ietf.org https://www.ietf.org/mailman/listinfo/core From brian.tridium@gmail.com Thu Nov 11 04:25:01 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 940E13A68F2 for ; Thu, 11 Nov 2010 04:25:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iyJ8KAHsnT2D for ; Thu, 11 Nov 2010 04:25:00 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 2FE143A68D0 for ; Thu, 11 Nov 2010 04:24:57 -0800 (PST) Received: by bwz12 with SMTP id 12so2270025bwz.31 for ; Thu, 11 Nov 2010 04:25:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=xf0QWL7hMKkA2PVNjln+XFdAOV4i3o2c34++Gq4rdYk=; b=V9FH/bw2p1jOJhL1x3OFzMrbF6C/rmJNsew+lWMGtPCa45wIUy54oMk55/9aCmpgDY faywxzJ12tA0AkWVpPLEiFVjdzflkPAMbJIzzQn9YlVdt5EN3vKwUhwgo0sQIXuYMIyX 0goqH7zBCVxio5JKPJtzrAumz0b5axiAWqZAg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=qhuYME23MTWZ2HwUYVU6OqK3VjSBVJ8hS6yiTiaqsTjWJ89s1utZOmLRW8VjVtI++P ESaV8aeMuFI2F652vXBdR8b4oFWLLdAQHeJQ8MgkeI4RzzqFA353lS5hpjjlrD0dmDVp LpoMgBqwiFVEwuvCQerhSDv9EVENZvnHJtP0A= MIME-Version: 1.0 Received: by 10.204.116.199 with SMTP id n7mr1232188bkq.80.1289478326825; Thu, 11 Nov 2010 04:25:26 -0800 (PST) Received: by 10.204.56.10 with HTTP; Thu, 11 Nov 2010 04:25:26 -0800 (PST) Date: Thu, 11 Nov 2010 07:25:26 -0500 Message-ID: From: Brian Frank To: core Content-Type: multipart/alternative; boundary=0016e6d6489f9db12c0494c6113a Subject: [core] Subscription and Tokens/EventId X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 12:25:01 -0000 --0016e6d6489f9db12c0494c6113a Content-Type: text/plain; charset=ISO-8859-1 I really just started digging into this and catching up on the emails. First off, let me ask if I understand this correctly. Based on the observation I-D it sounds like the client can include a Token with its subscribe. Token size is being debated somewhere b/w 2-16 bytes. However if I read it correctly, the server is free to choose to send notifications either with the URI *or* the Token (which maybe has been renamed EventId)? If that is the proposed design, then I would suggest ditching the idea of Tokens all together for matching up subscriptions with notifications. In my opinion requiring a server to store a token per subscription is way too much overhead, even if the token is just a few bytes. Here is how I am approaching the problem: there are two required components to a subscription: 1. the client/subscriber's IP address and port 2. an indication of which resource or resources are subscribed by a given client An efficient implementation is probably going to manage each unique client with some table like this: - client 1: ip+port - client 2: ip+port Side note I haven't seen mentioned: if a client fails to confirm a notification message (has gone down), then likely the result should be server should cancel all that clients subscriptions. Then we are going to somehow mark which resources are subscribed by each client: - resource 1: client 1 - resource 2: client 1 + client 2 - resource 3: no subscriptions In Sedona we did this like this: a) assign each unique client an index in a fixed size table b) keep track of subscriptions using a bit in a bitmask on each resource That model has worked quite well. If you decide you want to support 16 simultaneous clients, then you add 2 byte overhead to each resource object. For a 100 resources, we add an extra 200 bytes and can support 1600 subscriptions in fixed sized tables (ignoring client ip+port table). As soon as we start having to keep track of something other than a boolean state per client per resource things get ugly and complicated. To me, storing 2 bytes per subscription seems like a big deal, let alone 4, 8, or even 16. In Sedona's current design we can support 16 clients x 100 resources in 200 bytes (ignoring client ip+port table). If the server is forced to store 8 bytes for a token per subscription plus lets say at least 2 bytes to reference the client table and 2 bytes to reference the resource, then that 200 bytes buys us a measly 16 subscriptions before we run out of RAM in our tables. So if I am reading the proposed spec right, and Token is optional I personally would always choose to throw the Token away and just send my notifications with URIs. And I suspect that this is the design most limited devices would choose since RAM tends to be the most limited resource. Quite possible I am missing some fundamental in the proposed design, but those our my thoughts on how I read thru the I-Ds and comments out there. Brian --0016e6d6489f9db12c0494c6113a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    I really just started digging into this and catching up on the emails.=

    First off, let me ask if I understand this correc= tly. =A0Based on the observation I-D it sounds like the client can include = a Token with its subscribe. =A0Token size is being debated somewhere b/w 2-= 16 bytes. =A0However if I read it correctly, the server is free to choose t= o send notifications either with the URI *or* the Token (which maybe has be= en renamed EventId)?

    If that is the proposed design, then I would suggest di= tching the idea of Tokens all together for matching up subscriptions with n= otifications. =A0In my opinion requiring a server to store a token per subs= cription is way too much overhead, even if the token is just a few bytes. = =A0

    Here is how I am approaching the problem: =A0there are = two=A0required=A0components to a subscription:
    =A0=A01. the clien= t/subscriber's IP address and port
    =A0=A02. an indication of = which resource or resources are subscribed by a given client

    An efficient implementation is probably going to manage= each unique client with some table like this:

    =A0= =A0- client 1: ip+port
    =A0=A0- client 2: ip+port

    Side note I haven't seen mentioned: if a client fails to confirm a= notification message (has gone down), then likely the result should be ser= ver should cancel all that clients subscriptions.

    Then we are going to somehow mark which resources are subscribed by each cl= ient:

    =A0=A0- resource 1: client 1
    =A0= =A0- resource 2: client 1 + client 2
    =A0=A0- resource 3: no subsc= riptions

    In Sedona we did this like this:
    =A0=A0a) ass= ign each unique client an index in a fixed size table
    =A0=A0b) ke= ep track of subscriptions using a bit in a bitmask on each resource

    That model has worked quite well. =A0If you decide you want to s= upport 16=A0simultaneous=A0clients, then you add =A02 byte overhead to each= resource object. =A0For a 100 resources, we add an extra 200 bytes and can= support 1600 subscriptions in fixed sized tables (ignoring client ip+port = table). =A0As soon as we start having to keep track of something other than= a boolean state per client per resource things get ugly and complicated. = =A0

    To me, storing 2 bytes per subscription seems like a bi= g deal, let alone 4, 8, or even 16. =A0In Sedona's current design we ca= n support 16 clients x 100 resources in 200 bytes (ignoring client ip+port = table). =A0If the server is forced to store 8 bytes for a token per subscri= ption plus lets say at least 2 bytes to reference the client table and 2 by= tes to reference the resource, then that 200 bytes buys us a measly 16 subs= criptions before we run out of RAM in our tables.

    So if I am reading the proposed spec right, and Token i= s optional I personally would always choose to throw the Token away and jus= t send my notifications with URIs. =A0And I suspect that this is the design= most limited devices would choose since RAM tends to be the most limited r= esource.=A0

    Quite possible I am missing some fundamental in the pro= posed design, but those our my thoughts on how I read thru the I-Ds and com= ments out there.

    Brian
    --0016e6d6489f9db12c0494c6113a-- From klaus.hartke@googlemail.com Thu Nov 11 05:26:49 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B6863A6A3F for ; Thu, 11 Nov 2010 05:26:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_24=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iRyEOsKJL5Bk for ; Thu, 11 Nov 2010 05:26:48 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id DBDF93A689C for ; Thu, 11 Nov 2010 05:26:47 -0800 (PST) Received: by bwz12 with SMTP id 12so2354050bwz.31 for ; Thu, 11 Nov 2010 05:27:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; bh=2gbDelGVrm/QvD0+AfzYsN5fet1UnzlKWhFpKj10KVw=; b=btcKnI7dx7detek//MTPxXJfDSuvkkk/J9Zx4ORfFeAdKuN2/hiSJD7P/8dUI7y09y yzqOMOQXjLvFln84PBXzHrH0PsAm+G5wJ14EhXSm84Bvvc0jCl0KM9UIonmVRyIwRKzs XOsDaTb1IpL6mWDKKIUBmvyaN79lATEm9FRXU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=mFxtOXbJBjnhFZwLgNvix1K40NE+zd5p6zgQIg9YzqHQT/Y5sWAUpEYQO5oBAaMUxL 19eENdyBVX1hOxUtdAeryiLLg/qoElbqRiGKQxSuTYUCi8gR/ZDR3PMSaqvZ2B70bsNB Y83e2hivmZO/S+OPB79E7/Y4yRIzw8zu0cyAM= MIME-Version: 1.0 Received: by 10.204.72.140 with SMTP id m12mr1336194bkj.163.1289482037205; Thu, 11 Nov 2010 05:27:17 -0800 (PST) Sender: klaus.hartke@googlemail.com Received: by 10.204.121.134 with HTTP; Thu, 11 Nov 2010 05:27:16 -0800 (PST) In-Reply-To: References: Date: Thu, 11 Nov 2010 14:27:16 +0100 X-Google-Sender-Auth: VzUx20WJTRNBSOwGQiLDu2dCOKo Message-ID: From: Klaus Hartke To: core Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [core] Subscription and Tokens/EventId X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 13:26:49 -0000 Brian Frank wrote: > First off, let me ask if I understand this correctly. =A0Based on the > observation I-D it sounds like the client can include a Token with its > subscribe. =A0Token size is being debated somewhere b/w 2-16 bytes. Right. > However if I read it correctly, the server is free to choose to > send notifications either with the URI *or* the Token The current intent is that, if the client specifies a Token, the server MUST include the Token in every notification; if the client doesn't specify a Token, the server MUST include the URI. > If that is the proposed design, then I would suggest ditching the idea of > Tokens all together for matching up subscriptions with notifications. =A0= In my > opinion requiring a server to store a token per subscription is way too m= uch > overhead, even if the token is just a few bytes. What about (a) - client 1a: 16(ip)+2(port)+16(token) =3D 34 bytes - client 1b: 16(ip)+2(port)+16(token) =3D 34 bytes - client 2a: 16(ip)+2(port)+16(token) =3D 34 bytes =A0=A0- resource 1: client 1a =A0=A0- resource 2: client 1b + client 2a =A0=A0- resource 3: no subscriptions or (b) - client 1: 16(ip)+2(port) =3D 18 bytes - client 2: 16(ip)+2(port) =3D 18 bytes - subscription 1: 2(pointer to client 1)+16(token) =3D 18 bytes - subscription 2: 2(pointer to client 1)+16(token) =3D 18 bytes - subscription 3: 2(pointer to client 2)+16(token) =3D 18 bytes - resource 1: subscription 1 - resource 2: subscription 2 + subscription 3 - resource 3: no subscriptions That indeed requires more bytes than just (c) - client 1: 16(ip)+2(port) =3D 18 bytes - client 2: 16(ip)+2(port) =3D 18 bytes =A0=A0- resource 1: client 1 =A0=A0- resource 2: client 1 + client 2 =A0=A0- resource 3: no subscriptions but I don't think that brings the number of possible subscription down from 1600 to 16... Assuming 3 resources, 2 bytes per resource and (200-3*2=3D)194 bytes of available space, then - in the worst case - the number of possible subscriptions are (a) 5.71 subscriptions (b) 5.39 subscriptions (c) 10.78 subscriptions That looks like a factor of 2 to me. In the average case, when there are multiple subscriptions from the same IP+port, (b) should perform better than (a). In best case, when all subscriptions are from the same IP+port, (b) allows up to 9.78 subscriptions, which is already close to (c). Just for fun: (d) - prefix 1: 8 bytes - client 1: 2(pointer to prefix 1)+8(remaining ip address)+2(port) =3D 1= 2 bytes - client 2: 2(pointer to prefix 1)+8(remaining ip address)+2(port) =3D 1= 2 bytes - subscription 1: 2(pointer to client 1)+16(token) =3D 18 bytes - subscription 2: 2(pointer to client 1)+16(token) =3D 18 bytes - subscription 3: 2(pointer to client 2)+16(token) =3D 18 bytes - resource 1: subscription 1 - resource 2: subscription 2 + subscription 3 - resource 3: no subscriptions Worst case: 5.11 subscriptions Best case: 9.67 subscriptions Klaus From oscar.garcia@philips.com Thu Nov 11 05:43:24 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F37123A682B for ; Thu, 11 Nov 2010 05:43:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cOouH9CRb4Ff for ; Thu, 11 Nov 2010 05:43:21 -0800 (PST) Received: from DB3EHSOBE003.bigfish.com (db3ehsobe003.messaging.microsoft.com [213.199.154.141]) by core3.amsl.com (Postfix) with ESMTP id 225A73A68B7 for ; Thu, 11 Nov 2010 05:43:20 -0800 (PST) Received: from mail67-db3-R.bigfish.com (10.3.81.248) by DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id 14.1.225.8; Thu, 11 Nov 2010 13:43:49 +0000 Received: from mail67-db3 (localhost.localdomain [127.0.0.1]) by mail67-db3-R.bigfish.com (Postfix) with ESMTP id BA13A103811F; Thu, 11 Nov 2010 13:44:25 +0000 (UTC) X-SpamScore: -84 X-BigFish: VPS-84(zfe0izbb2dKbb2cK15d6O9251J1454K1432N9370J98dN604T217bP9371Pzz1202hzz8275bh8275dh1033IL186Mz2dh2a8h668h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:NLAMSEXE02.connect1.local; RD:smtpx.philips.com; EFVD:NLI Received: from mail67-db3 (localhost.localdomain [127.0.0.1]) by mail67-db3 (MessageSwitch) id 1289483062203855_22527; Thu, 11 Nov 2010 13:44:22 +0000 (UTC) Received: from DB3EHSMHS001.bigfish.com (unknown [10.3.81.251]) by mail67-db3.bigfish.com (Postfix) with ESMTP id 25124128004E; Thu, 11 Nov 2010 13:44:22 +0000 (UTC) Received: from NLAMSEXE02.connect1.local (168.87.56.20) by DB3EHSMHS001.bigfish.com (10.3.87.101) with Microsoft SMTP Server (TLS) id 14.1.225.8; Thu, 11 Nov 2010 13:43:42 +0000 Received: from NLHILEXH03.connect1.local (172.16.153.78) by connect1.philips.com (172.16.156.41) with Microsoft SMTP Server (TLS) id 8.3.106.1; Thu, 11 Nov 2010 14:43:34 +0100 Received: from NLCLUEXM03.connect1.local ([172.16.157.42]) by NLHILEXH03.connect1.local ([172.16.153.78]) with mapi; Thu, 11 Nov 2010 14:43:42 +0100 From: "Garcia Morchon, Oscar" To: Behcet Sarikaya , Rene Struik , core Date: Thu, 11 Nov 2010 14:43:57 +0100 Thread-Topic: [core] bootstrapping concerns still remain all (was Re:concerns re draft-oflynn-core-bootstrapping-02) Thread-Index: AcuBQ0nbPXw+1RiQQI2ey6S28qqi6gAGqumQABINlDA= Message-ID: <5F6BB0D9318FCA4083FC774C9A9ECEF68859297D11@NLCLUEXM03.connect1.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5F6BB0D9318FCA4083FC774C9A9ECEF68859297D11NLCLUEXM03con_" MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: [core] FW: bootstrapping concerns still remain all (was Re:concerns re draft-oflynn-core-bootstrapping-02) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 13:43:24 -0000 --_000_5F6BB0D9318FCA4083FC774C9A9ECEF68859297D11NLCLUEXM03con_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hey, In my view, the proposed solution(s) in the existing bootstrapping draft ca= n be a very valid solution for some use cases, but not for all of them. The security design and the used security protocols/procedures/cryptoalgori= thms depend on the target application and its needs regarding security, ope= ration, or the available resources. In my view, we should first list a set = of possible requirements/features. Once we have this list of requirements/f= eatures, we can map the proposed security solutions (e.g., some of them rel= ated to bootstrapping) to these requirements. The advantage of doing this in this way is that anyone having a look at the= m can know for which purposes a solution is good and what the offered capab= ilities are. I do not think that we can agree on a single solution that fits all the use= cases and all the requirements. In my view, we might have: - different solutions for different applications if their needs are not com= patible (e.g., one can assume the presence of a security manager in applica= tion A and this cannot be assumed for application B). - or extend an existing solution to fulfill additional requirements if we c= onsider a solution to be slightly incomplete. I would be happy to collaborate to gather relevant requirements&features fo= r the security design in an I-D. Regards and have a safe trip back home, Oscar. _____________________________ Oscar Garcia-Morchon Distributed Sensor Systems Philips Research Europe www.research.philips.com From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Beh= cet Sarikaya Sent: Thursday 11 November 2010 9:53 To: Rene Struik; core Subject: Re: [core] bootstrapping concerns still remain all (was Re:concern= s re draft-oflynn-core-bootstrapping-02) Hi Rene, Currently some of the authors are attending IETF in Beijing. We expect to discuss the points below as well as comments made during the p= resentation yesterday and possibly take some action. If you wish to get goo= d results, my recommendation is to provide some text. Regards, Behcet From: Rene Struik To: core Sent: Wed, November 10, 2010 8:08:43 AM Subject: [core] bootstrapping concerns still remain all (was Re: concerns r= e draft-oflynn-core-bootstrapping-02) Dear colleagues: I did a quick comparison of draft-oflynn-core-bootstrapping-02 and draft-of= lynn-core-bootstrapping-03; unfortunately, my major overall concerns expres= sed in my email as of Wed October 27, 2010 ff still stand. NOTE: draft-03, = which was posted two days ago has been reposted a few hours ago as draft-sa= rikaya-core-sbootstrapping-00, since it apparently lost of the main authors= of previous versions. Some preliminary feedback: 0) main difference with draft-oflynn-core-bootstrapping-02 and draft-oflynn= -core-bootstrapping-03 is in Section 5.1 only 1) Detailed analysis of deployment scenarios is still missing (since no cha= nges to Appendix A - examples). 2) Security services to be offered still needs far more detail (I provided = an initial list on September 29, 2010, after the CoAP Conf Call on desired = properties and had *many* email exchanges on this in context of HIP protoco= l, but do not really see this reflected. 3) Consideration for security policies and trust management aspects is virt= ually not there. 4) It is entirely unclear whether one can rely on a globally unique (and th= ereby unchanging id) -- cf. e.g. language in Section 5.1. It is unclear wha= t the statement that one MUST support various tyypes of identities means, w= hether "various" could mean "1" and how one can bind the various identities= , so as to allow conversion between theses and mapping this to a static glo= bally unique id. 5) Multi-domain support: in my mind, intention should be that a device may = be part of more than one network at the same time and be able to move from = one to the next while maintaining part of its state. 6) Authentication/authhorization: An online connectivity to the "trust cent= er" (a ZigBee term) is assumed. In many cases, this online connectivity is = simply not there -- one of the main characteristics of sensor-style network= s is that one cannot always assume connectivity to security management func= tionality, esp. if centralized. It seems that the centralized ZigBee model = has been written-in without any explanation as to why this would cover depl= oyment scenarios (which, by itself, reiterates importance to study deployme= nt scenarios in detail. 7) The PANA Section does not describe what PANA accomplishes and section is= littered with references to external standards (C12.22), without explanati= on of how things fit together, whether security framework and design philos= ophy match/are complementary, etc., etc. Moreover, as already mentioned, no= t clear at all what the security policy and trust management framework is. 8) The need for HIP is, after at least 10 email communications still entire= ly unclear. Moreover entanglement of name space and crypto space is still a= n issue. Most questions posed over the last month resulted in comments that= one could support/ameliorite better properties, more efficiencies, disenta= nglement as work-of-progress items for next version of HI/HIP-DEX. In my mi= nd, this indicates immaturity and (for now) unsuitability for standardizati= on. 9) The sections on PANA, HIP, 802.1x seem to be more text fillers, since do= not provide any motivation or allow one to grasp concepts behind things. A= s Cullen Jennings already articulated in his initial feedback: it is comple= tely unclear how one would build to this. I can provide more feedback once back from the current IEEE 802 meeting. Best regards, Rene On 27/10/2010 11:04 AM, Rene Struik wrote: Dear colleagues: I had a brief look at the bootstrapping draft (draft-oflynn-core-bootstrapp= ing-02. Some comments below (I am having some offline discussions on this, = but thought to send this to the list as well): I miss a detailed analysis of deployment scenarios to be considered as guid= ance into design, so as to have as very minimal benchmark whether all those= crypto protocols actually enable the deployment scenarios one has in mind.= To me, it seems to have merit to discuss the whole spectrum and end up wit= h cryptographic building blocks, security protocols, and security policies = and accompanying enforcement mechanism for trust policies that would fit th= e operational scenarios. I would favor not sprinkling protocol acronyms into any draft too early (si= nce, in my mind, this pushes into a particular direction, and not always wi= th merit). As an example, right now I do not see how, e.g., HIP or cryptogr= aphically generated addresses (802.1-like) would fit in. Similarly, e.g., P= ANA does not seem to work in heterogeneous trust environments, assumes onli= ne connectivity of a "mothership" node, and does not seem to include consid= eration of how to move from one mothership node to the next (or, e.g., if = one has an authenticator, how to make this work with single-hop/MAC securit= y). I also miss security objectives and design considerations, such as "separat= ion of concern" and no entanglement of concepts from different disciplines = in the document. BTW - I mentioned some of this in email correspondence after the last CoRE = conf call (Wed September 29, 2010). So far, I have not seen too much traffi= c on this. Moreover, I have not seen any adequate answers as to what makes,= e.g., HIP features an attractive fit for CoRE-like environments. Best regards, Rene [excerpt email RS as of October 1, 2010, 12:16pm EDT] In my mind, properties of suitable authenticated key agreement schemes shou= ld include (a) key establishment; (b) implicit key authentication; (c) key = confirmation; (d) mutual entity authentication; (e) forward secrecy; (f) {p= erhaps} some more esoteric properties (key compromise impersonation resilie= nce, etc.). Moreover, the "name space" (device identifiers) and the "cryptographic spac= e" (public keys, etc.) should be independent, so that this would allow trus= t lifecycle management to be reduced to proper management of device identif= iers (i.e., *no* entanglement of concepts from different disciplines). On 12/10/2010 12:23 PM, Rene Struik wrote: Hi Tobias: Thanks for your note. Does your "ascii art" description, Step 1)-3) allow the scenario, where (a)= one assigns a node id and imprints this (e.g., blowing fuse during chip te= sting); (b) has a node generating its own long-term public/private key pair and out= putting its node id and public key (e.g., during chip testing -- this would correspond to registering a public key with an RA); (c) have CA create a ce= rtificate in different process and return this value at later production/ personalization stage? Right now, from Section 4.1.3 of draft-ietf-hip-rfc5201-bis-02, I get the i= mpression that HIP does execute an authenticated DH key agreement scheme. I= f so, this makes me wonder how HIP differentiates from protocols, such as ECMQV a= nd, e.g., HMQV, which are all not that much more expensive than ECDH. If th= e difference is in the "puzzle" element, couldn't one just add something simi= lar to a well-known authenticated scheme that is already standardized with, e.g., NIST? As to forward secrecy: reason to include this is that many sensor-type node= s can be expected to be physically unprotected (e.g., screwed on a street l= amp post, on a garage roof, etc.) and, therefore, may be more vulnerable to dev= ice compromise over time (esp. since one cannot expect all nodes to be tamp= er resistant or tamper evident). By virtue of forward secrecy, compromise over= time does not compromise the whole device's history, but only the current = set of symmetric keys (note: I make some shortcuts in my reasoning on key manageme= nt here). Admittedly, my list of security properties is based on "desired" functionality and does not exclude functionality that may require, e.g., pu= blic-key crypto constructs. However, from a user's perspective, the only th= ing that matters is features and not what is "under the hood", as long as that is no= t cost-prohibitive (which I contend it is not -- cf., e.g., Section 3.2 of draft-struik-6lowapp-security-considerations-00). (BTW - All other desired = security properties I listed have an underlying rationale.) It would help to have a succinct mathematical description of the protocol y= ou suggest (stripped from formatting issues) and describe claimed cryptogra= phic properties. I would be happy to give this a look and review. Please feel free to provide to me in person if this would be cumbersome mat= erial for non-crypto people on the mailing list. Best regards, Rene [excerpt email RS as of October 1, 2010, 12:16pm EDT and response Tobias He= er as of October 7, 2010, 5:36am EDT] To aid clarity and succinct discussions, it would help to have a clear desc= ription of desired security services to be offered by an authenticated key agreement scheme and see whether a candidate scheme (such as, who knows= , HIP) satisfies these. If you could provide a succinct description of the HIP protocol itself, so that this is easy to understand, and could prov= ide what properties it has, that would be of great help! > > In my mind, properties of suitable authenticated key agreement schemes sh= ould include (a) key establishment; (b) implicit key authentication; (c) key confirmation; (d) mutual entity authentication; (e) forward secrecy= ; (f) {perhaps} some more esoteric properties (key compromise impersonation resilience, etc.). > Is this list valid for all targeted use cases? If yes, it is a very handy l= ist to check against. However, (e) forward secrecy seems to rule a number of "cheaper" cryptographic approaches (e.g., pre-shared keys)= and might not be relevant to all use cases (especially small setups). However, I am not absolutely firm with the envisaged scenarios in = CORE. > Moreover, the "name space" (device identifiers) and the "cryptographic sp= ace" (public keys, etc.) should be independent, so that this would allow trust lifecycle management to be reduced to proper management of devi= ce identifiers (i.e., *no* entanglement of concepts from different disciplines). Does the "*no* entanglement of concepts from different disciplines" also me= an that a concept like the id/loc split should be used to avoid entanglement of routing and naming? On 07/10/2010 5:36 AM, Tobias Heer wrote: To aid clarity and succinct discussions, it would help to have a clear desc= ription of desired security services to be offered by an authenticated key = agreement scheme and see whether a candidate scheme (such as, who knows, HI= P) satisfies these. If you could provide a succinct description of the HIP = protocol itself, so that this is easy to understand, and could provide what= properties it has, that would be of great help! > > In my mind, properties of suitable authenticated key agreement schemes sh= ould include (a) key establishment; (b) implicit key authentication; (c) ke= y confirmation; (d) mutual entity authentication; (e) forward secrecy; (f) = {perhaps} some more esoteric properties (key compromise impersonation resil= ience, etc.). > Is this list valid for all targeted use cases? If yes, it is a very handy l= ist to check against. However, (e) forward secrecy seems to rule a number o= f "cheaper" cryptographic approaches (e.g., pre-shared keys) and might not = be relevant to all use cases (especially small setups). However, I am not a= bsolutely firm with the envisaged scenarios in CORE. > Moreover, the "name space" (device identifiers) and the "cryptographic sp= ace" (public keys, etc.) should be independent, so that this would allow tr= ust lifecycle management to be reduced to proper management of device ident= ifiers (i.e., *no* entanglement of concepts from different disciplines). Does the "*no* entanglement of concepts from different disciplines" also me= an that a concept like the id/loc split should be used to avoid entanglemen= t of routing and naming? -- email: rstruik.ext@gmail.com Skype: rstruik cell: +1 (647) 867-5658 USA Google voice: +1 (415) 690-7363 -- email: rstruik.ext@gmail.com Skype: rstruik cell: +1 (647) 867-5658 USA Google voice: +1 (415) 690-7363 -- email: rstruik.ext@gmail.com Skype: rstruik cell: +1 (647) 867-5658 USA Google voice: +1 (415) 690-7363 ________________________________ 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_5F6BB0D9318FCA4083FC774C9A9ECEF68859297D11NLCLUEXM03con_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hey,

     

    In my view, the proposed solution(s) in the exist= ing bootstrapping draft can be a very valid solution for some use cases, bu= t not for all of them.

     

    The security design and the used security protoco= ls/procedures/cryptoalgorithms depend on the target application and its nee= ds regarding security, operation, or the available resources. In my view, w= e should first list a set of possible requirements/features. Once we have this list of requirements/features, we= can map the proposed security solutions (e.g., some of them related to boo= tstrapping) to these requirements.

     

    The advantage of doing this in this way is that a= nyone having a look at them can know for which purposes a solution is good = and what the offered capabilities are.

     

    I do not think that we can agree on a single solu= tion that fits all the use cases and all the requirements.

     

    In my view, we might have:

    - different solutions for different applications = if their needs are not compatible (e.g., one can assume the presence of a s= ecurity manager in application A and this cannot be assumed for application= B).

    - or extend an existing solution to fulfill addit= ional requirements if we consider a solution to be slightly incomplete.

     

    I would be happy to collaborate to gather relevan= t requirements&features for the security design in an I-D.

     

    Regards and have a safe trip back home,

     

          Oscar.<= /p>

    _____________________________

    Oscar Garcia-Morchon

    Distributed Sensor Systems

    Philips Research Europe

    www.research.philips.com

     

     

    From: core-bou= nces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Behcet Sarikaya
    Sent: Thursday 11 November 2010 9:53
    To: Rene Struik; core
    Subject: Re: [core] bootstrapping concerns still remain all (was Re:= concerns re draft-oflynn-core-bootstrapping-02)

     

    Hi Rene,
      Currently some of the authors are attending IETF in Beijing.
    We expect to discuss the points below as well as comments made during the p= resentation yesterday and possibly take some action. If you wish to get goo= d results, my recommendation is to provide some text.

    Regards,

    Behcet

     

    From: Rene Str= uik <rstruik.ext@gmail.com>
    To: core <core@ietf.org>
    Sent: Wed, November 10, 2010 8:08:43 AM
    Subject: [core] bootstrapping concerns still remain all (was Re: con= cerns re draft-oflynn-core-bootstrapping-02)

    Dear colleagues:

    I did a quick comparison of draft-oflynn-core-bootstrapping-02 and draft-of= lynn-core-bootstrapping-03; unfortunately, my major overall concerns expres= sed in my email as of Wed October 27, 2010 ff still stand. NOTE: draft-03, = which was posted two days ago has been reposted a few hours ago as draft-sarikaya-core-sbootstrapping-00, si= nce it apparently lost of the main authors of previous versions.

    Some preliminary feedback:
    0) main difference with draft-oflynn-core-bootstrapping-02 and draft-oflynn= -core-bootstrapping-03 is in Section 5.1 only
    1) Detailed analysis of deployment scenarios is still missing (since no cha= nges to Appendix A - examples).
    2) Security services to be offered still needs far more detail (I provided = an initial list on September 29, 2010, after the CoAP Conf Call on desired = properties and had *many* email exchanges on this in context of HIP protoco= l, but do not really see this reflected.
    3) Consideration for security policies and trust management aspects is virt= ually not there.
    4) It is entirely unclear whether one can rely on a globally unique (and th= ereby unchanging id) -- cf. e.g. language in Section 5.1. It is unclear wha= t the statement that one MUST support various tyypes of identities means, w= hether "various" could mean "1" and how one can bind the various identities, so as to allow conversion bet= ween theses and mapping this to a static globally unique id.
    5) Multi-domain support: in my mind, intention should be that a device may = be part of more than one network at the same time and be able to move from = one to the next while maintaining part of its state.
    6) Authentication/authhorization: An online connectivity to the "trust= center" (a ZigBee term) is assumed. In many cases, this online connec= tivity is simply not there -- one of the main characteristics of sensor-sty= le networks is that one cannot always assume connectivity to security management functionality, esp. if centralized. It= seems that the centralized ZigBee model has been written-in without any ex= planation as to why this would cover deployment scenarios (which, by itself= , reiterates importance to study deployment scenarios in detail.
    7) The PANA Section does not describe what PANA accomplishes and section is= littered with references to external standards (C12.22), without explanati= on of how things fit together, whether security framework and design philos= ophy match/are complementary, etc., etc. Moreover, as already mentioned, not clear at all what the security po= licy and trust management framework is.
    8) The need for HIP is, after at least 10 email communications still entire= ly unclear. Moreover entanglement of name space and crypto space is still a= n issue. Most questions posed over the last month resulted in comments that= one could support/ameliorite better properties, more efficiencies, disentanglement as work-of-progress items f= or next version of HI/HIP-DEX. In my mind, this indicates immaturity and (f= or now) unsuitability for standardization.
    9) The sections on PANA, HIP, 802.1x seem to be more text fillers, since do= not provide any motivation or allow one to grasp concepts behind things. A= s Cullen Jennings already articulated in his initial feedback: it is comple= tely unclear how one would build to this.

    I can provide more feedback once back from the current IEEE 802 meeting.
    Best regards, Rene



    On 27/10/2010 11:04 AM, Rene Struik wrote:

    Dear colleagues:

    I had a brief look at the bootstrapping draft (draft-oflynn-core-bootstrapp= ing-02. Some comments below (I am having some offline discussions on this, = but thought to send this to the list as well):

    I miss a detailed analysis of deployment scenarios to be considered as guid= ance into design, so as to have as very minimal benchmark whether all those cr= ypto protocols actually enable the deployment scenarios one has in mind. To= me, it seems to have merit to discuss the whole spectrum and end up with c= ryptographic building blocks, security protocols, and security policies and accompanying enforcement mechanism fo= r trust policies that would fit the operational scenarios.

    I would favor not sprinkling protocol acronyms into any draft too early (si= nce, in my mind, this pushes into a particular direction, and not always with merit). As an example, right now I do not see how, e.g.,= HIP or cryptographically generated addresses (802.1-like) would fit in. Similarly, e.g., PANA does not seem to work in heterogeneous trust environments, assumes online connectivity of a "mothership"= ; node, and does not seem to include consideration of how to move from one&= nbsp; mothership node to the next (or, e.g., if one has an authenticator, h= ow to make this work with single-hop/MAC security).

    I also miss security objectives and design considerations, such as &= quot;separation of concern" and no entanglement of concepts from diffe= rent disciplines in the document.

    BTW - I mentioned some of this in email correspondence after the last CoRE = conf call (Wed September 29, 2010). So far, I have not seen too much traffi= c on this. Moreover, I have not seen any adequate answers as to what makes,= e.g., HIP features an attractive fit for CoRE-like environments.

    Best regards, Rene

    [excerpt email RS as of October 1, 2010, 12:16pm EDT]

    In my mind, properties of suitable authenticated key agreement schemes shou= ld include (a) key establishment; (b) implicit key authentication; (c) key = confirmation; (d) mutual entity authentication; (e) forward secrecy; (f) {p= erhaps} some more esoteric properties (key compromise impersonation resilience, etc.).

    Moreover, the "name space" (device identifiers) and the "cry= ptographic space" (public keys, etc.) should be independent, so that t= his would allow trust lifecycle management to be reduced to proper manageme= nt of device identifiers (i.e., *no* entanglement of concepts from different disciplines).


    On 12/10/2010 12:23 PM, Rene Struik wrote: 

    Hi Tobias:
    

    


    

    

    Thanks for your note. 
    

    


    

    

    Does your "ascii art" description, Step 1)-3) allow the scen=
ario, where (a) one assigns a node id and imprints this (e.g., blowing fuse=
 during chip testing); 
    

    

    (b) has a node generating its own long-term public/private key pair an=
d outputting its node id and public key (e.g., during chip testing -- this =
would 
    

    

    correspond to registering a public key with an RA); (c) have CA create=
 a certificate in different process and return this value at later producti=
on/
    

    

    personalization stage?
    

    


    

    

    Right now, from Section 4.1.3 of draft-ietf-hip-rfc5201-bis-02, I get =
the impression that HIP does execute an authenticated DH key agreement sche=
me. If so,
    

    

    this makes me wonder how HIP differentiates from protocols, such as EC=
MQV and, e.g., HMQV, which are all not that much more expensive than ECDH. =
If the 
    

    

    difference is in the "puzzle" element, couldn't one just add=
 something similar to a
     well-known authenticated scheme that is already standardized with, e.=
g., 
    

    

    NIST?
    

    


    

    

    As to forward secrecy: reason to include this is that many sensor-type=
 nodes can be expected to be physically unprotected (e.g., screwed on a str=
eet lamp 
    

    

    post, on a garage roof, etc.) and, therefore, may be more vulnerable t=
o device compromise over time (esp. since one cannot expect all nodes to be=
 tamper 
    

    

    resistant or tamper evident). By virtue of forward secrecy, compromise=
 over time does not compromise the whole device's history, but only the cur=
rent set of
    

    

    symmetric keys (note: I make some shortcuts in my reasoning on key man=
agement here). Admittedly, my list of security properties is based on "=
;desired" 
    

    

    functionality and does not exclude functionality that may require, e.g=
., public-key crypto constructs. However, from a user's perspective, the on=
ly thing that
    

    

    matters is features and not what is "under the hood", as lon=
g as that is not
     cost-prohibitive (which I contend it is not -- cf., e.g., Section 3.2=
 of
    

    

    draft-struik-6lowapp-security-considerations-00). (BTW - All other des=
ired security properties I listed have an underlying rationale.)
    

    


    

    

    It would help to have a succinct mathematical description of the proto=
col you suggest (stripped from formatting issues) and describe claimed cryp=
tographic
    

    

    properties. I would be happy to give this a look and review. 
    

    


    

    

    Please feel free to provide to me in person if this would be cumbersom=
e material for non-crypto people on the mailing list.
    

    


    

    

    Best regards, Rene
    

    


    

    


    

    

    [excerpt email RS as of October 1, 2010, 12:16pm EDT and response Tobi=
as Heer as of October 7, 2010, 5:36am EDT]
    

    


    

    

    To aid clarity and succinct discussions, it would help to have a clear=
 description of desired security services to be offered by an authenticated=
 
    

    

    key agreement scheme and see whether a candidate scheme (such as, who =
knows, HIP) satisfies
     these. If you could provide a succinct description of 
    

    

    the HIP protocol itself, so that this is easy to understand, and could=
 provide what properties it has, that would be of great help!
    

    

    > 
    > In my mind, properties of=
 suitable authenticated key agreement schemes should include (a) key establ=
ishment; (b) implicit key authentication; 
    

    

    (c) key confirmation; (d) mutual entity authentication; (e) forward se=
crecy; (f) {perhaps} some more esoteric properties (key compromise 
    

    

    impersonation resilience, etc.).
    

    

    > 
    Is this list valid for all targeted use cases? If yes, it is a very ha=
ndy list to check against. However, (e) forward secrecy seems to 
    

    

    rule a number of "cheaper" cryptographic approaches (e.g., p=
re-shared keys) and might not be relevant to all use cases (especially smal=
l 
    

    

    setups). However, I am not absolutely firm with the envisaged scenario=
s in CORE.
    > Moreover, the "name space" =
(device identifiers) and the "cryptographic space" (public keys, =
etc.) should be independent, so that this would 
    allow trust lifecycle management to be red=
uced to proper management of device identifiers (i.e., *no* entang=
lement of concepts from different 
    disciplines).
     
    

    

    Does the "*no* entangleme=
nt of concepts from different disciplines" also mean that a concept li=
ke the id/loc split should be used to avoid 
    

    

    entanglement of routing and naming?





    On 07/10/2010 5:36 AM, Tobias Heer wrote: 

    To aid clarity and succinct discussions, i=
t would help to have a clear description of desired security services to be=
 offered by an authenticated key agreement scheme and see whether a candida=
te scheme (such as, who knows, HIP) satisfies these. If you could provide a=
 succinct description of the HIP protocol itself, so that this is easy to u=
nderstand, and could provide what properties it has, that would be of great=
 help!
    

    

    > 
    > In my mind, properties of suitable au=
thenticated key agreement schemes should include (a) key establishment; (b)=
 implicit key authentication; (c) key confirmation; (d) mutual entity authe=
ntication; (e) forward secrecy; (f) {perhaps} some more esoteric properties=
 (key compromise impersonation resilience, etc.).
    

    

    > 
    Is this list valid for all targeted use=
 cases? If yes, it is a very handy list to check against. However, (e) forw=
ard secrecy seems to rule a number of "cheaper" cryptographic app=
roaches (e.g., pre-shared keys) and might not be relevant to all use cases =
(especially small setups). However, I am not absolutely firm with the envis=
aged scenarios in CORE.
    > Moreover, the "name space" =
(device identifiers) and the "cryptographic space" (public keys, =
etc.) should be independent, so that this would allow trust lifecycle manag=
ement to be reduced to proper management of device identifiers (i.e., *no* entanglement of concepts from different disciplines).
     
    

    

    Does the "*no* entangleme=
nt of concepts from different disciplines" also mean that a concept li=
ke the id/loc split should be used to avoid entanglement of routing and nam=
ing?

     

    -- 
    

    

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

     

    -- 
    

    

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

     

    -- 
    

    

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

     


    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_5F6BB0D9318FCA4083FC774C9A9ECEF68859297D11NLCLUEXM03con_-- From klaus.hartke@googlemail.com Thu Nov 11 06:32:34 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 691103A6989 for ; Thu, 11 Nov 2010 06:32:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.954 X-Spam-Level: X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EoKcD0xWIDXL for ; Thu, 11 Nov 2010 06:32:33 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 3C60B3A69D3 for ; Thu, 11 Nov 2010 06:32:33 -0800 (PST) Received: by bwz12 with SMTP id 12so2438701bwz.31 for ; Thu, 11 Nov 2010 06:33:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=1sW7BhG/OdjfIffF+Nwi0SO00a/2nVP/a3WrqwrRUeI=; b=mx6WGhP9z0zrJ7s4TMRuG4ORT5DZuEmNTOPzDOdcXk5ceyFTQD90IGIaD2BVXjU2Ed t378VPPzaRHeQh9U7saHllqjrYo8BtA0+iJdGvivzn/3Km3NK8v+rKB6UoaQ5C9888Ko VD+JloTyUGKB+MdTZtpM4qntyUNOtd+YKZ9KE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=RaRvz4+c/ME5Dmn2DQLMmqVGfM7pNaT3DfVm84B6TeaEWH9Jdp+k3oswhmhf2PhWhp wrIriFmAlWc3zhhI24gZfUlDeLn0LrLLtoi4AshwpOZIDcSEUMqgFeoyU9AsA2XnUIX3 TFfCAMu7Xz9nwnsa9vdcaBOszoB+aZX7uyh98= MIME-Version: 1.0 Received: by 10.204.52.7 with SMTP id f7mr1411122bkg.190.1289485982518; Thu, 11 Nov 2010 06:33:02 -0800 (PST) Sender: klaus.hartke@googlemail.com Received: by 10.204.121.134 with HTTP; Thu, 11 Nov 2010 06:33:02 -0800 (PST) In-Reply-To: References: Date: Thu, 11 Nov 2010 15:33:02 +0100 X-Google-Sender-Auth: UqDVJQhPg7IfuXXei2Z5QwxJmjs Message-ID: From: Klaus Hartke To: core Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [core] Subscription and Tokens/EventId X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 14:32:34 -0000 Almost forgot: You also need to store the remaining lifetime somewhere, which is per-subscription, not per-client. So (c) probably doesn't even work (unless we remove the subscription lifetime mechanism)... Klaus From zach@sensinode.com Thu Nov 11 07:10:17 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 761493A69B8 for ; Thu, 11 Nov 2010 07:10:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.535 X-Spam-Level: X-Spam-Status: No, score=-3.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hO9az3sPTOta for ; Thu, 11 Nov 2010 07:10:12 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 6BE653A69EC for ; Thu, 11 Nov 2010 07:10:10 -0800 (PST) Received: from dhcp-40a3.meeting.ietf.org (dhcp-40a3.meeting.ietf.org [130.129.64.163]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id oABFATU8028700 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 11 Nov 2010 17:10:34 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-402--204099163; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: Date: Thu, 11 Nov 2010 23:10:29 +0800 Message-Id: <038C6E01-2132-4711-9141-AF741354AE5C@sensinode.com> References: To: Klaus Hartke X-Mailer: Apple Mail (2.1081) Cc: core Subject: Re: [core] Subscription and Tokens/EventId X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 15:10:18 -0000 --Apple-Mail-402--204099163 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 11, 2010, at 9:27 PM, Klaus Hartke wrote: >> However if I read it correctly, the server is free to choose to >> send notifications either with the URI *or* the Token >=20 > The current intent is that, if the client specifies a Token, the > server MUST include the Token in every notification; if the client > doesn't specify a Token, the server MUST include the URI. And the ability to leave the token (and thus get the URI in each = notification) out is a feature I really want to keep, sounds like Brian = has the same in mind. The Token does have some advantages, especially in = saving overhead for possibly long URIs (e.g. with a query component). = The current philosophy is correct, with it is up to the client which = should be used. Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 --Apple-Mail-402--204099163 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9 fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb 6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja 5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I 2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTExMTE1MTAz MFowIwYJKoZIhvcNAQkEMRYEFMhDs7tz5v8mniaAeea7gd9+ey90MIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBACzrCerPiZd009N0KcSfoWrp0uZTUcscUXdGkUdDq6AIlFZVRxXsOAVY KzDbiTCy+OVTFt+gBmZcpwCgCbMv7kdEbQD49DHKDYMbnbjDDMqSqq5hIJ3bJ6nuQg5jePzyeNse aJ11WGZHJxh2kF0aW93mREkLWhe+OrwkJSR5QR87ywW4+qT50sVuksOlTqt7fOXFlTqF8WBJBDAT a3S6bbctIbRJ1nf9RCBMNe+8Mzo2/b8c8iSgv8FWB6Mn4Ri+1ukOVjqHH0U/qQ29lBYhpVM3o/qH HIBJ6c6/5yUjZUW09DaoXdDQX4TntipXA1PcYsVaqHiTQjPDiNU2jPaPTxQAAAAAAAA= --Apple-Mail-402--204099163-- From pab@peoplepowerco.com Thu Nov 11 07:28:16 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B9793A683F for ; Thu, 11 Nov 2010 07:28:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJ3xxY4MHYzS for ; Thu, 11 Nov 2010 07:28:15 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id DBBED3A69E9 for ; Thu, 11 Nov 2010 07:28:14 -0800 (PST) Received: by fxm3 with SMTP id 3so1491827fxm.31 for ; Thu, 11 Nov 2010 07:28:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.106.210 with SMTP id y18mr277254fao.108.1289489324311; Thu, 11 Nov 2010 07:28:44 -0800 (PST) Received: by 10.223.93.197 with HTTP; Thu, 11 Nov 2010 07:28:44 -0800 (PST) In-Reply-To: <038C6E01-2132-4711-9141-AF741354AE5C@sensinode.com> References: <038C6E01-2132-4711-9141-AF741354AE5C@sensinode.com> Date: Thu, 11 Nov 2010 09:28:44 -0600 Message-ID: From: Peter Bigot To: Zach Shelby Content-Type: multipart/alternative; boundary=0016e68e92891e069b0494c8a124 Cc: core , Klaus Hartke Subject: Re: [core] Subscription and Tokens/EventId X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 15:28:16 -0000 --0016e68e92891e069b0494c8a124 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Nov 11, 2010 at 9:10 AM, Zach Shelby wrote: > On Nov 11, 2010, at 9:27 PM, Klaus Hartke wrote: > >> However if I read it correctly, the server is free to choose to > >> send notifications either with the URI *or* the Token > > > > The current intent is that, if the client specifies a Token, the > > server MUST include the Token in every notification; if the client > > doesn't specify a Token, the server MUST include the URI. > > And the ability to leave the token (and thus get the URI in each > notification) out is a feature I really want to keep, sounds like Brian has > the same in mind. The rationale for this is that it enables client-independent response messages, or clients that don't remember they subscribed? > The Token does have some advantages, especially in saving overhead for > possibly long URIs (e.g. with a query component). The current philosophy is > correct, with it is up to the client which should be used. > I rather dislike CoAP having two mechanisms (compare Token; compare set of URI options) to correlate asynchronous responses (one-time or observations) with a request, especially since nobody's specified the rules to be used for the URI-based approach. I'll be interested to see how Uri-Authority is handled in those rules. Also not convinced requiring a server to support two client styles is in the spirit of constrained devices. Peter --0016e68e92891e069b0494c8a124 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    On Thu, Nov 11, 2010 at 9:10 AM, Zach Shelby <zach@sensinode.com= > wrote:
    On Nov 11, 2010, at 9:27 PM, Klaus Hartke wrote:
    >> However if I read it correctly, the server is free to choose to >> send notifications either with the URI *or* the Token
    >
    > The current intent is that, if the client specifies a Token, the
    > server MUST include the Token in every notification; if the client
    > doesn't specify a Token, the server MUST include the URI.

    And the ability to leave the token (and thus get the URI in each noti= fication) out is a feature I really want to keep, sounds like Brian has the= same in mind.

    The rationale for this is that it enabl= es client-independent response messages, or clients that don't remember= they subscribed?
    =A0
    The To= ken does have some advantages, especially in saving overhead for possibly l= ong URIs (e.g. with a query component). The current philosophy is correct, = with it is up to the client which should be used.

    I rather dislike CoAP having two mechanisms (compare = Token; compare set of URI options) to correlate asynchronous responses (one= -time or observations) with a request, especially since nobody's specif= ied the rules to be used for the URI-based approach.=A0 I'll be interes= ted to see how Uri-Authority is handled in those rules.

    Also not convinced requiring a server to support two client styles is i= n the spirit of constrained devices.

    Peter
    --0016e68e92891e069b0494c8a124-- From Nathan.Smith@ember.com Thu Nov 11 07:38:21 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B427A3A69FB for ; Thu, 11 Nov 2010 07:38:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SDO-KmKAkwth for ; Thu, 11 Nov 2010 07:37:58 -0800 (PST) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id D269C3A683F for ; Thu, 11 Nov 2010 07:37:37 -0800 (PST) Received: from [192.168.81.63] ([192.168.81.63]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 11 Nov 2010 10:38:00 -0500 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-4--202429934 From: Nathan Smith In-Reply-To: <006f01cb816d$81d52900$857f7b00$@com> Date: Thu, 11 Nov 2010 10:38:18 -0500 Message-Id: <777F56BE-3A57-4B9F-BEA6-E3A46BB240EA@ember.com> References: <006f01cb816d$81d52900$857f7b00$@com> To: Kepeng Li X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 11 Nov 2010 15:38:00.0957 (UTC) FILETIME=[6C3402D0:01CB81B6] Cc: 'core' Subject: Re: [core] Payload in CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 15:38:22 -0000 --Apple-Mail-4--202429934 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Kepeng, Your guess is the correct one -- since we know where the start of the = payload is (since each CoAP header option has a length field), we can = use the length field in the UDP header to determine where the CoAP = payload ends. Cheers, Nate On Nov 11, 2010, at 1:55 AM, Kepeng Li wrote: > Hi, > =20 > When I read draft-ietf-core-coap-03, I find no explanation about the = payload. > =20 > Do we need to have one field to specify the length of the payload? And = also how can the receiver know that it is the end of the whole message? > =20 > Should this be done by the UDP? I notice that there is a length field = in UDP. > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |Ver| T | OC | Code | Transaction ID =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Options (if any) ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Payload (if any) ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > =20 > Thanks, > Cheers > Kepeng > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --Apple-Mail-4--202429934 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi Kepeng,

    Your guess is the = correct one -- since we know where the start of the payload is (since = each CoAP header option has a length field), we can use the length field = in the UDP header to determine where the CoAP payload = ends.

    Cheers,
    Nate

    <= div>On Nov 11, 2010, at 1:55 AM, Kepeng Li wrote:

    Hi,
     
    When I read = draft-ietf-core-coap-03, I find no explanation about the = payload.
     
    Do we need to have one field = to specify the length of the payload? And also how can the receiver know = that it is the end of the whole message?
     
    Should this be done by the UDP? I = notice that there is a length field in UDP.
     
       = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Ver| T |  OC   = |      Code     = |        Transaction = ID        
    =
       = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Options (if any) = ...
       = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Payload (if any) = ...
       = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     
    Thanks,
    Cheers
    Kepeng
    _______________________= ________________________
    core mailing list
    core@ietf.org
    Subject: Re: [core] A potential new ticket for '-d' usage in link format draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 18:51:07 -0000 Hello Linyi! On Nov 10, 2010, at 6:22 PM, Linyi Tian wrote: > If I understand correctly, you are saying that the semantics will be = defined > by the implementation. We just provide the mechanism to convey this = URI in > the message and allow application to interpret. >=20 > The scenario came to my mind actually was from the draft. It says the = -d > provides the URI to an interface to access the resource. Then WADL was > listed as an example. Did I misunderstood the draft? The language in the draft is probably misleading. It should probably be = reworded to indicate that the end devices are not expected to actually = retrieve any document from the given URL, and that the value is only = meant to identify a interface definition. If you choose to implement a given interface definition, then seeing = this field with the URI of the interface definition you support would = simply indicate to you that you know how to read it. It could even be a = URI which is not retrievable, like = . It is simply an = identifier. If it happens to be a URI which points to a WADL definition, = then that's great for developers---but it doesn't make any difference to = constrained devices. > Could you please give me a real example how can I use this -d field? Lets say that there is a standardized interface definition for dim-able = light fixtures called . I have a = CoAP light fixture and a CoAP dimmer switch---both of which support this = interface definition. Lets say the both have a "Pair" button, so I press = the pair button on both of them. The dimmer switch does service = discovery by querying .well-known/core on the light fixture and notices = that one of the returned items has an interface definition of = . Because the dimmer switch also = supports , it recognizes it and = configures itself to use the URI that supported = .=20 It is intended to be used simply as an opaque identifier by constrained = devices to indicate that you can find a specific interface at the given = location. That it happens to be a URI itself is somewhat confusing, but = many other standards use URIs in a similar fashion (XML, for example). I hope this helps. __________________ Robert Quattlebaum Jabber: darco@deepdarc.com eMail: darco@deepdarc.com www: http://www.deepdarc.com/ From tianlinyi@huawei.com Thu Nov 11 17:39:07 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB7EC3A6A9C for ; Thu, 11 Nov 2010 17:39:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.492 X-Spam-Level: ** X-Spam-Status: No, score=2.492 tagged_above=-999 required=5 tests=[AWL=-0.860, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KK0ouzACez4X for ; Thu, 11 Nov 2010 17:39:02 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id DC85D3A688A for ; Thu, 11 Nov 2010 17:39:00 -0800 (PST) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LBR00ML70LLA9@szxga01-in.huawei.com> for core@ietf.org; Fri, 12 Nov 2010 09:39:21 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LBR00NFS0LL43@szxga01-in.huawei.com> for core@ietf.org; Fri, 12 Nov 2010 09:39:21 +0800 (CST) Received: from [130.129.131.148] (dhcp-8394.meeting.ietf.org [130.129.131.148]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LBR003Q00L8EU@szxml02-in.huawei.com>; Fri, 12 Nov 2010 09:39:21 +0800 (CST) Date: Fri, 12 Nov 2010 09:39:05 +0800 From: Linyi Tian In-reply-to: <777F56BE-3A57-4B9F-BEA6-E3A46BB240EA@ember.com> To: Nathan Smith , Kepeng Li Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_NsERzoxZFecXyG7ndAxU/Q)" Thread-topic: [core] Payload in CoAP Thread-index: AcuCCmQMHieSh5cE3U6R3bgQPNQo5g== User-Agent: Microsoft-Entourage/12.25.0.100505 Cc: 'core' Subject: Re: [core] Payload in CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 01:39:07 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --Boundary_(ID_NsERzoxZFecXyG7ndAxU/Q) Content-type: text/plain; charset=GB2312 Content-transfer-encoding: quoted-printable Hi, Nate Does CoAP layer aware with length field In the UDP layer? Is =A1=AE\0=A1=AF used to end the buffer for the CoAP payload instead? Cheers, Linyi On 10-11-11 =CF=C2=CE=E711:38, "Nathan Smith" wrote: > Hi Kepeng, >=20 > Your guess is the correct one -- since we know where the start of the pay= load > is (since each CoAP header option has a length field), we can use the len= gth > field in the UDP header to determine where the CoAP payload ends. >=20 > Cheers, > Nate >=20 > On Nov 11, 2010, at 1:55 AM, Kepeng Li wrote: >=20 >> Hi, >> =20 >> When I read draft-ietf-core-coap-03, I find no explanation about the pay= load. >> =20 >> Do we need to have one field to specify the length of the payload? And a= lso >> how can the receiver know that it is the end of the whole message? >> =20 >> Should this be done by the UDP? I notice that there is a length field in= UDP. >> =20 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |Ver| T | OC | Code | Transaction ID >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Options (if any) ... >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Payload (if any) ... >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> =20 >> Thanks, >> Cheers >> Kepeng >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >=20 >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --Boundary_(ID_NsERzoxZFecXyG7ndAxU/Q) Content-type: text/html; charset=GB2312 Content-transfer-encoding: quoted-printable Re: [core] Payload in CoAP Hi, Nate

    Does CoAP layer aware with length field In the UDP layer? Is ‘\0̵= 7; used to end the buffer for the CoAP payload instead?

    Cheers,
    Linyi


    On 10-11-11 =CF=C2=CE=E711:38, "Nathan Smith" <    nathan.smith@ember.com> wrote:

    <= SPAN STYLE=3D'font-size:11pt'>Hi Kepeng,

    Your guess is the correct one -- since we know where the start of the paylo= ad is (since each CoAP header option has a length field), we can use the len= gth field in the UDP header to determine where the CoAP payload ends.

    Cheers,
    Nate

    On Nov 11, 2010, at 1:55 AM, Kepeng Li wrote:

    <= FONT SIZE=3D"2">Hi,
     
    When I read draft-ietf-core-coap-03, I find no explanation about the payloa= d.
     
    Do we need to have one field to specify the length of the payload? And also= how can the receiver know that it is the end of the whole message?
     
    Should this be done by the UDP? I notice that there is a length field in UD= P.
     
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
       |Ver| T |  OC   |     =  Code     |       &nb= sp;Transaction ID        
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
       |   Options (if any) ...
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
       |   Payload (if any) ...
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
     
    Thanks,
    Cheers
    Kepeng
    _______________________________________________
    core mailing list
    core@ietf.org
    https://www.ietf.org/m= ailman/listinfo/core


    ___________= ____________________________________
    core mailing list
    core@ietf.org
    https://www.ietf.org/m= ailman/listinfo/core
    --Boundary_(ID_NsERzoxZFecXyG7ndAxU/Q)-- From cabo@tzi.org Thu Nov 11 17:50:59 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 743B63A6860 for ; Thu, 11 Nov 2010 17:50:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UEt8VRy+FDw2 for ; Thu, 11 Nov 2010 17:50:58 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 787CB3A67EE for ; Thu, 11 Nov 2010 17:50:56 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id oAC1pEAR027809; Fri, 12 Nov 2010 02:51:14 +0100 (CET) Received: from dhcp-67f2.meeting.ietf.org (dhcp-67f2.meeting.ietf.org [130.129.103.242]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 5537FEA4; Fri, 12 Nov 2010 02:51:11 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: Date: Fri, 12 Nov 2010 09:51:09 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <06C8403E-B9DF-4D13-B47C-CD6EE28F647E@tzi.org> References: To: Linyi Tian X-Mailer: Apple Mail (2.1081) Cc: 'core' Subject: Re: [core] Payload in CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 01:50:59 -0000 On Nov 12, 2010, at 09:39, Linyi Tian wrote: > Does CoAP layer aware with length field In the UDP layer? Is =91\0=92 = used to end the buffer for the CoAP payload instead? Due to the usual layering in the IP stack, the CoAP implementation gets = UDP datagrams with a defined length (and, yes, this happens to be = encoded in the UDP length field, but that wouldn't even have been = necessary, as IP itself already delimits the end of the datagram). So there is no further need to delimit the end of the payload. Gruesse, Carsten From gayang@cisco.com Sun Nov 14 08:23:32 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8021B3A6A44 for ; Sun, 14 Nov 2010 08:23:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.738 X-Spam-Level: X-Spam-Status: No, score=-10.738 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7PJD0PFry18 for ; Sun, 14 Nov 2010 08:23:31 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 908243A6A1E for ; Sun, 14 Nov 2010 08:23:31 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AukFAGac30xAaMHG/2dsb2JhbACUWo1/caMkmgOFSgSEWIkR X-IronPort-AV: E=Sophos;i="4.59,196,1288569600"; d="scan'208,217";a="619810760" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-6.cisco.com with ESMTP; 14 Nov 2010 16:24:09 +0000 Received: from xbh-hkg-412.apac.cisco.com (xbh-hkg-412.cisco.com [64.104.123.69]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oAEGO8p0012234 for ; Sun, 14 Nov 2010 16:24:08 GMT Received: from xmb-hkg-41a.cisco.com ([64.104.123.115]) by xbh-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 15 Nov 2010 00:24:08 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB8418.5CC4AC84" Date: Mon, 15 Nov 2010 00:24:02 +0800 Message-ID: <8CC1E6C311149F42AA72A11750D75B1C80F0C7@XMB-HKG-41A.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-oflynn-core-bootstrapping-03 Thread-Index: AcuEGFk7YwIog+s7RvKlMqoSVtPoZA== From: "Gary Yang (gayang)" To: X-OriginalArrivalTime: 14 Nov 2010 16:24:08.0101 (UTC) FILETIME=[5CC9ED50:01CB8418] Subject: [core] Comments on draft-oflynn-core-bootstrapping-03 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Nov 2010 16:23:32 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB8418.5CC4AC84 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable The recommissioning for widely deployed city management sensor network is a different type of bootstrapping scenario. The administration domain of a large cluster of sensors switched from X to Y, and it is so at scale that the field manual recommissioning is too costly.=20 So we can leverage the AAA server proposed to support the recommissioning, for example, service provider Y transfers the corresponding AAA records of recommissionged sensors from Service provider X, by administrating new passwords into devices, and then reboot devices remotely in order to generate a new key associated with Y, thus to bind the cluster of sensors in question to the new service provider.=20 It works for me and my opinion is to add City-wide sensing network recommissioning as additional usage case.=20 -gary ------_=_NextPart_001_01CB8418.5CC4AC84 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Comments on draft-oflynn-core-bootstrapping-03

    The = recommissioning for widely deployed = city management sensor = network is a different = type of bootstrapping = scenario. = The administration domain of a large = cluster of sensors switched = from = X to Y, and it is so at scale that the field manual recommissioning is too costly.

    So = we can leverage the AAA server proposed to support the = recommissioning, for = example, service = provider = Y transfers the = corresponding AAA = records of = recommissionged sensors from Service = provider = X, by = administrating new = passwords into = devices, and = then = reboot devices = remotely in order to = generate a new = key associated with = Y, thus to bind the cluster of sensors in question to the new service = provider.

    It works for me = and my opinion is to add City-wide sensing network recommissioning as additional usage = case.


    -gary

    ------_=_NextPart_001_01CB8418.5CC4AC84-- From angelo.castellani@gmail.com Mon Nov 15 03:23:16 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CACE13A6BF2 for ; Mon, 15 Nov 2010 03:23:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.477 X-Spam-Level: X-Spam-Status: No, score=-1.477 tagged_above=-999 required=5 tests=[AWL=-0.499, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_BACKHAIR_44=1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKCcf5a-EhLd for ; Mon, 15 Nov 2010 03:23:16 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id EDED33A6AFE for ; Mon, 15 Nov 2010 03:23:15 -0800 (PST) Received: by qyk30 with SMTP id 30so1833732qyk.10 for ; Mon, 15 Nov 2010 03:23:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=JCrrnlOWzTvbahV1w1TNQQhioesL66xM56TkKCVHmMs=; b=bcDOBmSofJ2sy43mZYxxs2U1XmnOkf5JjUCFMomlRFc0fLAeGdCul/mkxtO93exyOK JSABsukK90IXsY1Q02EqnSYcn9GnhJODaFOe8t7IoSY0r8DynukB0oiGgRZy+NEjB6av OoFdhLJ/0Cep0b1yK3SyfICtmFDEULK9jzeus= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=rwsVLPHVKRAQVoPtirK1cpZNKQGclRF2BpvLJH6sQC/vSQtWZ6XXUux2EuFOave3/q xch6nwLAvMQeu6S94LswKj1CuYKEP0Vdtu4He3eSb/zCvHMyvp5LPLiwQJFawe9facnc fx/4pVHawYU2YCzyTnP1PoXu/9v1Uglyf9qHM= Received: by 10.229.189.134 with SMTP id de6mr5112169qcb.51.1289820236784; Mon, 15 Nov 2010 03:23:56 -0800 (PST) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.229.248.201 with HTTP; Mon, 15 Nov 2010 03:23:36 -0800 (PST) In-Reply-To: <4CD7B21C.2000600@nostrum.com> References: <4CD7B21C.2000600@nostrum.com> From: "Angelo P. Castellani" Date: Mon, 15 Nov 2010 12:23:36 +0100 X-Google-Sender-Auth: x8WdZXTqzmDe7LC6M3FRmXevU58 Message-ID: To: Adam Roach Content-Type: text/plain; charset=ISO-8859-1 Cc: "CORE \(Constrained RESTful Environments\) WG" Subject: Re: [core] Towards authc/authz user cases X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 11:23:16 -0000 Adam, I share your concern about current security model supporting ONLY the "trusted proxy". This can limit the scope of application of CoAP, if we consider that the proxy should reside on the edge of the constrained network. If I understand correctly, seems that we're assuming that all CoAP devices and the CoAP/HTTP proxy are always in the same security "domain".. This seems a strong assumption, because nobody cannot deploy a trusted CoAP device on the network without deploying also a proxy THEY trust on each local network. The network and the proxy in my opinion should reside on the edge of the constrained local network: - for scalability - early UDP/UDP conversion - access to local multicast features - probably many other reasons... AND is very convenient if it exists a techique to achieve end-to-end security using the proxy only for *translation* purposes and without trust. Obviously if the proxy resides on the other end there is no such problem, but in that case CoAP<->HTTP mapping is used only for convenience and the endpoints of security are always CoAP<->CoAP. Angelo On Mon, Nov 8, 2010 at 09:17, Adam Roach wrote: > If we pursue only the model under which the proxy authenticates the user and > then has free reign over the various home-area-network devices, this would > potentially give a set of power utility employees the ability to monitor and > control my alarm system and my front-door deadbolt. From angelo.castellani@gmail.com Mon Nov 15 03:33:19 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D8543A6C6D for ; Mon, 15 Nov 2010 03:33:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.727 X-Spam-Level: X-Spam-Status: No, score=-1.727 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7IU5A-8-xac for ; Mon, 15 Nov 2010 03:33:18 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id A80733A6C5C for ; Mon, 15 Nov 2010 03:33:18 -0800 (PST) Received: by qyk30 with SMTP id 30so1842979qyk.10 for ; Mon, 15 Nov 2010 03:33:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=PS0ovJPJ60bZ9WJRQC5lKDSacJcY4F6ayfiDqubrknE=; b=iXSdHA/ZNmw+dFS2MjcOL6qhKgeYvx9G/Z2JUyPPic/FGPt/OipVsvj2eI/82rMmG9 SoIMMhCxYQvRmDD11Y2zWzfE4hSy458S9iaVXEeeRNPJ4rJ0SbSV03e3rNtNGlpZF9Xu phJecJg3PYTIhDNhdUo7+0MEnQK86fW9rISyY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=NkG67Oa0eW213NjyzeEGemOmdJF+cXL9s2RGEehG1E/ZVwQxazxfQ/w+qOywVRPRax Dd/Qb4X9X82S0ykH6aPG1HZjbe++hdBXzob5G8cwjHpgGRgmPxCuCt6tv22I1AYhH1QT kIr5aWuNoc/2oMnwk+VWRfafsdK62NJo545wE= Received: by 10.229.85.213 with SMTP id p21mr5059779qcl.127.1289820839598; Mon, 15 Nov 2010 03:33:59 -0800 (PST) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.229.248.201 with HTTP; Mon, 15 Nov 2010 03:33:39 -0800 (PST) In-Reply-To: References: <4CD7B21C.2000600@nostrum.com> From: "Angelo P. Castellani" Date: Mon, 15 Nov 2010 12:33:39 +0100 X-Google-Sender-Auth: p99613D8VNX1izoRJu3MQQdIzR4 Message-ID: To: Adam Roach Content-Type: text/plain; charset=ISO-8859-1 Cc: "CORE \(Constrained RESTful Environments\) WG" Subject: Re: [core] Towards authc/authz user cases X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 11:33:19 -0000 On Mon, Nov 15, 2010 at 12:23, Angelo P. Castellani wrote: > The network and the proxy in my opinion should reside on the edge of > the constrained local network: > - for scalability > - early UDP/UDP conversion > - access to local multicast features > - probably many other reasons... > > AND is very convenient if it exists a techique to achieve end-to-end > security using the proxy only for *translation* purposes and without > trust. I missed spell checking this paragraph.. The corrected version follows: The CoAP/HTTP proxy in my opinion should reside on the edge of the constrained local network: - for scalability - early TCP/UDP conversion - access to local multicast features - probably many other reasons... AND is very convenient if it exists a technique to achieve end-to-end security using the proxy only for *translation* purposes and without trust. From brian.tridium@gmail.com Mon Nov 15 06:33:17 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E03523A6CAF for ; Mon, 15 Nov 2010 06:33:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rv8vFrAkpFT7 for ; Mon, 15 Nov 2010 06:33:09 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 89FAF3A6C37 for ; Mon, 15 Nov 2010 06:33:08 -0800 (PST) Received: by bwz12 with SMTP id 12so6139260bwz.31 for ; Mon, 15 Nov 2010 06:33:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=DhCRAIPw0HGCD8MDeP1PHC6oXk2ZovaptHMNLou51K4=; b=BVTni7zchxYIK6gv1+It+uMoPTF516Fe1xtZRQ6QbWMpbZ/FxK9o0xvsvg4eUb80Fl t/LqOh3VaqLyPtEgVao+jxKokr5Ctbn1XisVZQCEugMrorKBEmEOHKUl04E3/YAgfy0/ jGJsme3Gqy+GgG5tRsZejNq5NZJ0N4MWsaixQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=pADuCvIsaIbyam81ruuoth1y1+cQ1nfaIWoLHmlDD+KsH41rgA8//66mvqSBXAw0Ww hFqpJyWs9brBRc1aeBYTnJTO6oBlA9+qNgNNTNb+Tz4RFHzeqrvnAlBiSf9aN0v/HL57 akD6nPBklJTxIPP2HpaHqXw8tuXhrAEd4SZX4= MIME-Version: 1.0 Received: by 10.204.116.199 with SMTP id n7mr5922799bkq.80.1289831628864; Mon, 15 Nov 2010 06:33:48 -0800 (PST) Received: by 10.204.119.20 with HTTP; Mon, 15 Nov 2010 06:33:48 -0800 (PST) In-Reply-To: References: <038C6E01-2132-4711-9141-AF741354AE5C@sensinode.com> Date: Mon, 15 Nov 2010 09:33:48 -0500 Message-ID: From: Brian Frank To: Peter Bigot Content-Type: multipart/alternative; boundary=0016e6d6489f0f03b0049518545e Cc: Klaus Hartke , core Subject: Re: [core] Subscription and Tokens/EventId X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 14:33:18 -0000 --0016e6d6489f0f03b0049518545e Content-Type: text/plain; charset=ISO-8859-1 I agree - I think we should just pick the one most limited devices will probably support (which IMO is URI correlation). Also I would really like to figure out how remove subscription lifetime as a per subscription option. As Klaus pointed out, that adds a pretty hefty overhead per subscription. Can we make lifetime a per client issue versus a per subscription issue? I think we could even simplify it even further to just say that as long as the client is ack'ing the notifications we can assume it is still interested in the subscription. That requires no memory overhead, and solves the primary issue which is how to release resources when communications to a client is lost. On Thu, Nov 11, 2010 at 10:28 AM, Peter Bigot wrote: > On Thu, Nov 11, 2010 at 9:10 AM, Zach Shelby wrote: > >> On Nov 11, 2010, at 9:27 PM, Klaus Hartke wrote: >> >> However if I read it correctly, the server is free to choose to >> >> send notifications either with the URI *or* the Token >> > >> > The current intent is that, if the client specifies a Token, the >> > server MUST include the Token in every notification; if the client >> > doesn't specify a Token, the server MUST include the URI. >> >> And the ability to leave the token (and thus get the URI in each >> notification) out is a feature I really want to keep, sounds like Brian has >> the same in mind. > > > The rationale for this is that it enables client-independent response > messages, or clients that don't remember they subscribed? > > >> The Token does have some advantages, especially in saving overhead for >> possibly long URIs (e.g. with a query component). The current philosophy is >> correct, with it is up to the client which should be used. >> > > I rather dislike CoAP having two mechanisms (compare Token; compare set of > URI options) to correlate asynchronous responses (one-time or observations) > with a request, especially since nobody's specified the rules to be used for > the URI-based approach. I'll be interested to see how Uri-Authority is > handled in those rules. > > Also not convinced requiring a server to support two client styles is in > the spirit of constrained devices. > > Peter > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > --0016e6d6489f0f03b0049518545e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I agree - I think we should just pick the one most limited devices will pro= bably support (which IMO is URI correlation).

    Also I wou= ld really like to figure out how remove subscription lifetime as a per subs= cription option. =A0As Klaus pointed out, that adds a pretty hefty overhead= per subscription. =A0Can we make lifetime a per client issue versus a per = subscription issue?

    I think we could even simplify it even further to just = say that as long as the client is ack'ing the notifications we can assu= me it is still interested in the subscription. =A0That requires no memory o= verhead, and solves the primary issue which is how to release resources whe= n communications to a client is lost.



    On Thu, Nov 11, 2010 at 10:28 AM, Peter Bigot <pab@peoplepowerco.com> wr= ote:
    On Thu, Nov 11, 2010 at 9:10 AM, Zach Shelby <zach@sensinode.com>= ; wrote:
    On Nov 11, 2010, at 9:27 PM, Klaus Hartke wrote:
    >> However if I read it correctly, the server is free to choose to >> send notifications either with the URI *or* the Token
    >
    > The current intent is that, if the client specifies a Token, the
    > server MUST include the Token in every notification; if the client
    > doesn't specify a Token, the server MUST include the URI.

    And the ability to leave the token (and thus get the URI in each noti= fication) out is a feature I really want to keep, sounds like Brian has the= same in mind.

    The rationale for this is that it= enables client-independent response messages, or clients that don't re= member they subscribed?
    =A0
    The Token does have some advantages, especially in saving overhead fo= r possibly long URIs (e.g. with a query component). The current philosophy = is correct, with it is up to the client which should be used.

    I rather dislike CoAP having two mechanisms (co= mpare Token; compare set of URI options) to correlate asynchronous response= s (one-time or observations) with a request, especially since nobody's = specified the rules to be used for the URI-based approach.=A0 I'll be i= nterested to see how Uri-Authority is handled in those rules.

    Also not convinced requiring a server to support two client styles is i= n the spirit of constrained devices.

    Peter

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


    --0016e6d6489f0f03b0049518545e-- From robert.cragie@gridmerge.com Mon Nov 15 09:02:51 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2167B3A6CD6 for ; Mon, 15 Nov 2010 09:02:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.017 X-Spam-Level: X-Spam-Status: No, score=-3.017 tagged_above=-999 required=5 tests=[AWL=-0.419, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_BACKHAIR_44=1, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ppGFHCJoGK-X for ; Mon, 15 Nov 2010 09:02:44 -0800 (PST) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id B589B3A6BB5 for ; Mon, 15 Nov 2010 09:02:43 -0800 (PST) Received: from client-86-29-103-19.glfd.adsl.virginmedia.com ([86.29.103.19] helo=[192.168.1.80]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) id 1PI2Sg-0006GE-DA; Mon, 15 Nov 2010 17:03:22 +0000 Message-ID: <4CE167D7.5030904@gridmerge.com> Date: Mon, 15 Nov 2010 17:03:19 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: "Angelo P. Castellani" References: <4CD7B21C.2000600@nostrum.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080101070208040501020604" Cc: "CORE \(Constrained RESTful Environments\) WG" Subject: Re: [core] Towards authc/authz user cases X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Nov 2010 17:02:51 -0000 This is a cryptographically signed message in MIME format. --------------ms080101070208040501020604 Content-Type: multipart/alternative; boundary="------------080604070102000705000405" This is a multi-part message in MIME format. --------------080604070102000705000405 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Angelo, I'm struggling to see how you can have end-to-end security which goes=20 through a translation point. At the point of translation, end-to-end=20 security is lost, unless we are talking essentially about session=20 protocol translation only, which I don't think is the case here. I am also confused because early on you seem to say that having a proxy=20 residing on the edge limits the scope of application of CoAP but in then = you same to say in your corrected version (as below) that it should=20 reside on the edge of the network. Can you clarify where your 'ends' are?= Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com On 15/11/2010 11:23 AM, Angelo P. Castellani wrote: > Adam, > I share your concern about current security model supporting ONLY the > "trusted proxy". This can limit the scope of application of CoAP, if > we consider that the proxy should reside on the edge of the > constrained network. > > If I understand correctly, seems that we're assuming that all CoAP > devices and the CoAP/HTTP proxy are always in the same security > "domain".. > > This seems a strong assumption, because nobody cannot deploy a trusted > CoAP device on the network without deploying also a proxy THEY trust > on each local network. > > The CoAP/HTTP proxy in my opinion should reside on the edge of > the constrained local network: > - for scalability > - early UDP/UDP conversion > - access to local multicast features > - probably many other reasons... > > AND is very convenient if it exists a techique to achieve end-to-end > security using the proxy only for *translation* purposes and without > trust. > > Obviously if the proxy resides on the other end there is no such > problem, but in that case CoAP<->HTTP mapping is used only for > convenience and the endpoints of security are always CoAP<->CoAP. > > Angelo > > > On Mon, Nov 8, 2010 at 09:17, Adam Roach wrote: >> If we pursue only the model under which the proxy authenticates the us= er and >> then has free reign over the various home-area-network devices, this w= ould >> potentially give a set of power utility employees the ability to monit= or and >> control my alarm system and my front-door deadbolt. > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --------------080604070102000705000405 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Angelo,

    I'm struggling to see how you can have end-to-end security which goes through a translation point. At the point of translation, end-to-end security is lost, unless we are talking essentially about session protocol translation only, which I don't think is the case here.

    I am also confused because early on you seem to say that having a proxy residing on the edge limits the scope of application of CoAP but in then you same to say in your corrected version (as below) that it should reside on the edge of the network. Can you clarify where your 'ends' are?

    Robert

    Robert Cragie (Pacific Gas & Electric)

    Gridmerge Ltd.
    89 Greenfield Crescent,
    Wakefield, WF4 4WA, UK
    +44 1924 910888
    +1 415 513 0064
    http://www.gridmerge.com


    On 15/11/2010 11:23 AM, Angelo P. Castellani wrote: 
    Adam,
I share your concern about current security model supporting ONLY the
"trusted proxy". This can limit the scope of application of CoAP, if
we consider that the proxy should reside on the edge of the
constrained network.

If I understand correctly, seems that we're assuming that all CoAP
devices and the CoAP/HTTP proxy are always in the same security
"domain"..

This seems a strong assumption, because nobody cannot deploy a trusted
CoAP device on the network without deploying also a proxy THEY trust
on each local network.

The CoAP/HTTP proxy in my opinion should reside on the edge of
the constrained local network:
- for scalability
- early UDP/UDP conversion
- access to local multicast features
- probably many other reasons...

AND is very convenient if it exists a techique to achieve end-to-end
security using the proxy only for *translation* purposes and without
trust.

Obviously if the proxy resides on the other end there is no such
problem, but in that case CoAP<->HTTP mapping is used only for
convenience and the endpoints of security are always CoAP<->CoAP.

Angelo


On Mon, Nov 8, 2010 at 09:17, Adam Roach <adam@nostrum.com> wrote:

    If we pursue only the model under which the proxy =
authenticates the user and
then has free reign over the various home-area-network devices, this woul=
d
potentially give a set of power utility employees the ability to monitor =
and
control my alarm system and my front-door deadbolt.

    _______________________________________________
core mailing list
core@=
ietf.org
https://www.ietf.org/mailman/listinfo/core
    --------------080604070102000705000405-- --------------ms080101070208040501020604 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRZTCC BN0wggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UE BhMCR0IxGzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEa MBgGA1UECgwRQ29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJV UzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUg VVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWls MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5 ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqk kqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWL eeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJ Q/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udl y/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0jBBgwFoAUoBEKIz6W8Qfs 4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQE AwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAR BgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5jb21vZG9j YS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwuY29t b2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvz bRx8NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12 jMOCAU9sAPMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxog L5dMUbtGB8SKN04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNB pEMD9O3vMyfbOeAUTibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mY HK9/FX8wggY+MIIFJqADAgECAhEAtlwUjTTxveqQY8soFvBYEjANBgkqhkiG9w0BAQUFADCB rjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEe MBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVz ZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIGFuZCBFbWFpbDAeFw0xMDA4MzAwMDAwMDBaFw0xMTA4MzAyMzU5NTlaMIHkMTUwMwYD VQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBFUlNPTkEgTk9UIFZBTElEQVRFRDFGMEQG A1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5u ZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMyBDb21vZG8gTGltaXRlZDEWMBQGA1UE AxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVy Z2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtAJ+m9Tgd3li8BgAIRth Gtth3YcCbhLPjfAcnDKcEGSrkZqao79Jg2uDW62IOwNCq9ae3VweBlvg3UUVu8upXzgDR/jF z4S1ZNk1if6V9QEiyBHdE1qMUQeeytedk3qw93CU5snWiXgVRacU8H8Dv+WJPsb4WYAH4MBz aJMI2N/E5XGGYpKFj9vxnEiQ7h83jXxw3Ee2rXCCbhJEci/tUl+Cx40pB3m7nlEdASY+A3tq JLIiG8Argf0+bWaxmuSUihKoakhHQruAylWY9EVtbKg8SACYZhdHCx2+ZSSrxbbAKSv0cDk0 0vQPvgH5GEi6zSB9QvqWCdBH/rL0XfV5jQIDAQABo4ICHTCCAhkwHwYDVR0jBBgwFoAUiYJn fcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFGkahOqOBMk95XAb8dpcRdaef8AYMA4GA1Ud DwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIx AQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzAp BggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCB mjBMoEqgSIZGaHR0cDovL2NybC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRB dXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0 L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYB BQUHAQEEYDBeMDYGCCsGAQUFBzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFD bGllbnRDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNV HREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEB ADcjSJQKgVIfD/IztFrhx2YqR9mKsDs3XakKd4hUoeunHgskiaMIQY2Kcfob48OuzrfY73rN fNoaqr5LZwDeVflMnZd0rPcTA9rAHq5l/qwdSta3k0xvBui0NAtOrSBdbqC4vggLKuZvoR2o 7mSbxSSBZHuVLObx/E5E+D5fjWC7ffNvr9y/uFXeCYFsM+Hc9VPIZ+cAY7JQFJEK/Nuti2QH IIxdR91N2vHuNXWIPROPFMl7y8ltO/fONwhxMcY2dH4JkDH6pdNzMtzykvsO0NeiRHnNlS4K A8aD9RaBR8FNQHq+JusC2tf11qdHBpHrVAK7dHodKDnbRr2t9VdrU2owggY+MIIFJqADAgEC AhEAtlwUjTTxveqQY8soFvBYEjANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJU UlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNV BAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0x MDA4MzAwMDAwMDBaFw0xMTA4MzAyMzU5NTlaMIHkMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3Qg TmV0d29yayAtIFBFUlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENv bmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0G A1UECxMWKGMpMjAwMyBDb21vZG8gTGltaXRlZDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEq MCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtAJ+m9Tgd3li8BgAIRthGtth3YcCbhLPjfAcnDKcEGSr kZqao79Jg2uDW62IOwNCq9ae3VweBlvg3UUVu8upXzgDR/jFz4S1ZNk1if6V9QEiyBHdE1qM UQeeytedk3qw93CU5snWiXgVRacU8H8Dv+WJPsb4WYAH4MBzaJMI2N/E5XGGYpKFj9vxnEiQ 7h83jXxw3Ee2rXCCbhJEci/tUl+Cx40pB3m7nlEdASY+A3tqJLIiG8Argf0+bWaxmuSUihKo akhHQruAylWY9EVtbKg8SACYZhdHCx2+ZSSrxbbAKSv0cDk00vQPvgH5GEi6zSB9QvqWCdBH /rL0XfV5jQIDAQABo4ICHTCCAhkwHwYDVR0jBBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0w HQYDVR0OBBYEFGkahOqOBMk95XAb8dpcRdaef8AYMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMB Af8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEE BAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6 Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0cDovL2Ny bC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVt YWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xp ZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQUF BzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwYB BQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRtyb2JlcnQuY3Jh Z2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBADcjSJQKgVIfD/IztFrhx2Yq R9mKsDs3XakKd4hUoeunHgskiaMIQY2Kcfob48OuzrfY73rNfNoaqr5LZwDeVflMnZd0rPcT A9rAHq5l/qwdSta3k0xvBui0NAtOrSBdbqC4vggLKuZvoR2o7mSbxSSBZHuVLObx/E5E+D5f jWC7ffNvr9y/uFXeCYFsM+Hc9VPIZ+cAY7JQFJEK/Nuti2QHIIxdR91N2vHuNXWIPROPFMl7 y8ltO/fONwhxMcY2dH4JkDH6pdNzMtzykvsO0NeiRHnNlS4KA8aD9RaBR8FNQHq+JusC2tf1 1qdHBpHrVAK7dHodKDnbRr2t9VdrU2oxggRgMIIEXAIBATCBxDCBrjELMAkGA1UEBhMCVVMx CzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVT RVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0 BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIR ALZcFI008b3qkGPLKBbwWBIwCQYFKw4DAhoFAKCCAnAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTAxMTE1MTcwMzE5WjAjBgkqhkiG9w0BCQQxFgQUlT7P CRIvW0KJILnxCbbAY/dDqTAwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJV VDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4t VVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQC2XBSNNPG96pBj yygW8FgSMIHXBgsqhkiG9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgT AlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBO ZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIRALZcFI008b3q kGPLKBbwWBIwDQYJKoZIhvcNAQEBBQAEggEAloW4upoiDCiV8Fir5lsJyRxSazfhrzYfkUJn bdcw6f3shbZ2sOMvyIwNn1O9VFtd0cGqYuKn9FMN0TtbYI8m198hSorkGy5Uns0kMACjAFCS f0hfc+tc82Sq+pXmkHpJY6vPZ0HTYf7oMJGps5S928EIZBCwB68l1CtQUjrSXZo2ZKx18Vvm EVpRWpPlvIIn7RrlzE7gzm1Fo6vy14uZdqkLWhUITN59QgSMcR91JBiHrPxWOf60vtoYVNKK kE1SEwbrQgTOtERjpEKPEw6Wsz2QvI9HIJQkVDq3jg8eehDYaHjalmhdiqCWROpLFU6RsmeF UVqKHtaN93dZmUNhtAAAAAAAAA== --------------ms080101070208040501020604-- From angelo.castellani@gmail.com Tue Nov 16 01:37:20 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 936EB3A6DB9 for ; Tue, 16 Nov 2010 01:37:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_BACKHAIR_44=1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7YDep7ERc03 for ; Tue, 16 Nov 2010 01:37:19 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id A879B3A6DB6 for ; Tue, 16 Nov 2010 01:37:18 -0800 (PST) Received: by qyk35 with SMTP id 35so819956qyk.10 for ; Tue, 16 Nov 2010 01:38:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=VF2lwgP3VJF/+PRLsQMgJZjYE0fZUA9w7/U6vL2fIyo=; b=YkJrB07I+oNTnbtHSydSg2c8gaOI7bwgjZEuFohR0qr4Cfp3ERy6AtSnZnANOeSWf5 DVq8cP5+maGYKRRvgd+tf/mwTla3Puh7QsToQpCH10E/quEONs8fbGvsjUdPlQohhf8K utfe3TNRgtlQuKqDlg73C/7sr3g3VhwZPPCmc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=MBsaREVDsk7wXHmioHUbcNp/rpnc0nEvOhUaKQVkfoRKU1izRI/rmY7DsiRR9kqRxQ Z6geMwAq3h0De4jqbUhCC0WUBJSEsjqK6NOo5By9OO4S0ESlW8vsKtiIgBjWGXoVRqEk 77LTs0JLDhzUuVbuZqJ3ch4iZ2hFwshi4WPSs= Received: by 10.229.74.65 with SMTP id t1mr6007273qcj.279.1289900280393; Tue, 16 Nov 2010 01:38:00 -0800 (PST) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.229.183.130 with HTTP; Tue, 16 Nov 2010 01:37:40 -0800 (PST) In-Reply-To: <4CE167D7.5030904@gridmerge.com> References: <4CD7B21C.2000600@nostrum.com> <4CE167D7.5030904@gridmerge.com> From: "Angelo P. Castellani" Date: Tue, 16 Nov 2010 10:37:40 +0100 X-Google-Sender-Auth: LIGVa3YXQ_HCHFQMd6gdTnEMLmU Message-ID: To: robert.cragie@gridmerge.com Content-Type: text/plain; charset=ISO-8859-1 Cc: "CORE \(Constrained RESTful Environments\) WG" Subject: Re: [core] Towards authc/authz user cases X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 09:37:20 -0000 I don't know if end-to-end security can be obtained with in-the-middle untrusted translation between HTTP and CoAP (I'm not a security expert). I explain better my doubt: If secured CoAP requires always a trusted proxy to be mapped to HTTP, I think that this can limit the scope of application of CoAP. So I was wondering if is possible to design something similar to IPsec at the CoAP level? I attach some notes and an example just to better explain a (possible?) alternative. AUTHENTICATION An option to include a MAC or a signature of the payload and of a selected set of relevant options --> this can be translated to HTTP with a (new?) HTTP Header option defined in the same way ENCRYPTION The payload and a selected set of options can be encrypted at CoAP level, leaving out of the process options that the proxy needs to work properly. --> HTTP mapping in this way can be preserved transparently. Toy example of secured (?) CoAP mapped to HTTP: ### Request ### POST Option1: plain-text Option2: MAC: ### Response ### 200 OK Option1: plain-text Option2: MAC: Angelo On Mon, Nov 15, 2010 at 18:03, Robert Cragie wrote: > Hi Angelo, > > I'm struggling to see how you can have end-to-end security which goes > through a translation point. At the point of translation, end-to-end > security is lost, unless we are talking essentially about session protocol > translation only, which I don't think is the case here. > > I am also confused because early on you seem to say that having a proxy > residing on the edge limits the scope of application of CoAP but in then you > same to say in your corrected version (as below) that it should reside on > the edge of the network. Can you clarify where your 'ends' are? > > Robert > > Robert Cragie (Pacific Gas & Electric) > > Gridmerge Ltd. > 89 Greenfield Crescent, > Wakefield, WF4 4WA, UK > +44 1924 910888 > +1 415 513 0064 > http://www.gridmerge.com > > On 15/11/2010 11:23 AM, Angelo P. Castellani wrote: > > Adam, > I share your concern about current security model supporting ONLY the > "trusted proxy". This can limit the scope of application of CoAP, if > we consider that the proxy should reside on the edge of the > constrained network. > > If I understand correctly, seems that we're assuming that all CoAP > devices and the CoAP/HTTP proxy are always in the same security > "domain".. > > This seems a strong assumption, because nobody cannot deploy a trusted > CoAP device on the network without deploying also a proxy THEY trust > on each local network. > > The CoAP/HTTP proxy in my opinion should reside on the edge of > the constrained local network: > - for scalability > - early UDP/UDP conversion > - access to local multicast features > - probably many other reasons... > > AND is very convenient if it exists a techique to achieve end-to-end > security using the proxy only for *translation* purposes and without > trust. > > Obviously if the proxy resides on the other end there is no such > problem, but in that case CoAP<->HTTP mapping is used only for > convenience and the endpoints of security are always CoAP<->CoAP. > > Angelo > > > On Mon, Nov 8, 2010 at 09:17, Adam Roach wrote: > > If we pursue only the model under which the proxy authenticates the user and > then has free reign over the various home-area-network devices, this would > potentially give a set of power utility employees the ability to monitor and > control my alarm system and my front-door deadbolt. > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > From angelo.castellani@gmail.com Tue Nov 16 01:55:53 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B71B73A6C56 for ; Tue, 16 Nov 2010 01:55:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.727 X-Spam-Level: X-Spam-Status: No, score=-1.727 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eJsvmt8VnQ6a for ; Tue, 16 Nov 2010 01:55:53 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id E9E643A6D9C for ; Tue, 16 Nov 2010 01:55:52 -0800 (PST) Received: by qyk35 with SMTP id 35so837158qyk.10 for ; Tue, 16 Nov 2010 01:56:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=T/p8EbNlxQZPVY1PnIowFTKR+DkLR2LfCTBBgVXx2YY=; b=Xxzu1vGERUKWn3wkZT4TjHYR8Emg/99jJwlF8Mb2PTOsQaourz6hNmOeqOY5kFDM00 1N6mtLlVQQ3uxotfuEbMfpflpNBIX07Wfq8Fr64oSBUff7XI3//Fm/Xkh5UYwDpu+U6D AVC+cIhDu4vIQ/VrMck830yX1xpcUnEgNwkw8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=MB2gnUJkwN/ekZ6uF5MtzC+wZrNh01YImaR0uWVDZlVXT7Out5mUxZpCSnOqHQ1Icw 55XN6bwGo+7PMDY5rN45IlBocA7ui7bTWl549SECHGckPVTmISvtpw238nE+g8rA28r+ 9J0nCkaGdvVSEAxESmpYkhcPeBybGBbEwhKaM= Received: by 10.229.241.5 with SMTP id lc5mr5129306qcb.165.1289901392827; Tue, 16 Nov 2010 01:56:32 -0800 (PST) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.229.183.130 with HTTP; Tue, 16 Nov 2010 01:56:11 -0800 (PST) In-Reply-To: <4CE167D7.5030904@gridmerge.com> References: <4CD7B21C.2000600@nostrum.com> <4CE167D7.5030904@gridmerge.com> From: "Angelo P. Castellani" Date: Tue, 16 Nov 2010 10:56:11 +0100 X-Google-Sender-Auth: q_IM1xiO0qDWridK0IFlpJHXj0w Message-ID: To: robert.cragie@gridmerge.com Content-Type: text/plain; charset=ISO-8859-1 Cc: "CORE \(Constrained RESTful Environments\) WG" Subject: Re: [core] Towards authc/authz user cases X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 09:55:53 -0000 On Mon, Nov 15, 2010 at 18:03, Robert Cragie wrote: > I am also confused because early on you seem to say that having a proxy > residing on the edge limits the scope of application of CoAP but in then you > same to say in your corrected version (as below) that it should reside on > the edge of the network. Can you clarify where your 'ends' are? Sorry for the misunderstanding in the initial sentence, my opinion is that the CoAP/HTTP proxy should be deployed on the edge of the constrained network and not on the "traditional" Internet. Angelo From klaus.hartke@googlemail.com Tue Nov 16 08:58:16 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 235AD3A6CAA for ; Tue, 16 Nov 2010 08:58:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.656 X-Spam-Level: X-Spam-Status: No, score=-2.656 tagged_above=-999 required=5 tests=[AWL=0.721, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6aq+GE9W9AQl for ; Tue, 16 Nov 2010 08:58:15 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id ED0073A6C89 for ; Tue, 16 Nov 2010 08:58:14 -0800 (PST) Received: by vws8 with SMTP id 8so380930vws.31 for ; Tue, 16 Nov 2010 08:58:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; bh=P1HD5LDmd+SLjq0ntIJNLqgeAp/jjnAzQ/P35hRkxzA=; b=I3o10gdBr+TCrSQCFJ+oQEB5iJ3yszcOhABBecq16x8IuFGQbj4wLJEK3KNGM9J0Fm XezvleoJMNDiS80hbCvrKgFgvpOVhLYPJmSPqLctjRFuyBWngc9+6QqnmJ8YrrjG0ZqF pBHpDHu/pEbJk7yA68EJcMWm7nrvNB9kAi3eQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=EryXdzDlskfyrJUChAPpRUNyaWUE3cRKj6aDAZaZEU4JSfEB399KlilGT92KID2Ihy NYiEnQ0dtpvuTzuqvnMkd6nP8JSHhZ0UY/RqEKSF5fdnzTs1fSr7kr14OtQFyL/UDhB5 DX7SvDzfARuKP7DBdKwC7kVhq3H0ic2et/6wU= MIME-Version: 1.0 Received: by 10.204.98.75 with SMTP id p11mr6292439bkn.55.1289926737890; Tue, 16 Nov 2010 08:58:57 -0800 (PST) Sender: klaus.hartke@googlemail.com Received: by 10.204.121.134 with HTTP; Tue, 16 Nov 2010 08:58:57 -0800 (PST) In-Reply-To: References: <038C6E01-2132-4711-9141-AF741354AE5C@sensinode.com> Date: Tue, 16 Nov 2010 17:58:57 +0100 X-Google-Sender-Auth: ISaiiM6OlCwmZDVlH84XxTIo5QM Message-ID: From: Klaus Hartke To: core Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [core] Subscription and Tokens/EventId X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 16:58:16 -0000 Brian Frank wrote: > I agree - I think we should just pick the one most limited devices will > probably support (which IMO is URI correlation). URI correlation doesn't suffice if a client has more than one outstanding request to the same resource. A client implementation can opt-out from having more than one outstanding request, but a server implementation cannot. > Also I would really like to figure out how remove subscription lifetime a= s a > per subscription option. =A0As Klaus pointed out, that adds a pretty heft= y > overhead per subscription. =A0Can we make lifetime a per client issue ver= sus a > per subscription issue? The Etag(s) known by a client are also per-subscription. A server may opt-out from using Etags though. > I think we could even simplify it even further to just say that as long a= s > the client is ack'ing the notifications we can assume it is still interes= ted > in the subscription. [...] There are two issues that need to be addressed: - a client needs to know if the server is still sending notifications, and - a server needs to know if the client is still interested in receiving notifications. The current (Subscription-lifetime) mechanism addresses both: a server knows that the client is still interested because the client repeatedly sends subscription requests, and the client knows that the server is sending notifications, because the server repeatedly acknowledges subscription requests. If one of the two fails or they disagree about the state of the subscription, the next subscription request will fix it. I like the idea of using ack'ing the notifications to signal that the client is still interested in receiving notifications. To make sure the server is still sending notifications, the client could refresh the subscription after it didn't receive a notification for some time (which it probably should be doing anyway). I'm slightly concerned about 'lazy' implementations that simply ack every response instead of checking if the response can be related to an outstanding request. I heard people tend to send newsletters to their spam folder rather than clicking the 'unsubscribe' link when they want to get rid of them. Klaus From klaus.hartke@googlemail.com Tue Nov 16 09:07:41 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C05D3A6BAA for ; Tue, 16 Nov 2010 09:07:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, WEIRD_PORT=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QStBRcWnDOt3 for ; Tue, 16 Nov 2010 09:07:40 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 085CF3A6BA4 for ; Tue, 16 Nov 2010 09:07:39 -0800 (PST) Received: by vws8 with SMTP id 8so391044vws.31 for ; Tue, 16 Nov 2010 09:08:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=s+TRF56Cjy5yC9Qo43PUQFSUYt6oKwo8AR7YXxEV4i8=; b=DogrR98DP501IqTlW0UD/1v+S0u5xx8HnJCwfolKLgsFr19oLpVREsoKPvPDHFoBnu dQoQdJ+W08UmIw888xUlHEmUaYwuaS9SQOhWOheZKywf5HufIhdzcH7eTIv3RkpRr7MC slsK0FDSIlF1aH4cW57ka/sO/76BQjBWkSNDM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=M9mnAWt2yw+uOghwKVW5nnbYt2m0QmVyAyHLFO4znUfnoLuh9HvWiMvy6Qr5MDhHOE AMpenY64VJiFJDVesLQpqzmmk4UOBDwnxM5IbguGpcDFMqIoAEzfTpNad1gMNvQCRfrc tmqhSsFdI5z81cxzVyW/lfAxs671f8tnKsTpk= MIME-Version: 1.0 Received: by 10.204.98.75 with SMTP id p11mr6299357bkn.55.1289927301661; Tue, 16 Nov 2010 09:08:21 -0800 (PST) Sender: klaus.hartke@googlemail.com Received: by 10.204.121.134 with HTTP; Tue, 16 Nov 2010 09:08:21 -0800 (PST) Date: Tue, 16 Nov 2010 18:08:21 +0100 X-Google-Sender-Auth: d33Vsy00SUNWu7UNUNbSTRU0u58 Message-ID: From: Klaus Hartke To: core Content-Type: text/plain; charset=ISO-8859-1 Subject: [core] Proxy and server on the same port X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 17:07:41 -0000 Terminology: - server: an end-point that serves resources; - proxy: an end-point that can be tasked with retrieving/manipulating remote resources on behalf of a client; - gateway: an end-point that looks/feels/smells like a server, but forwards requests to one or more servers and/or handles requests on behalf of them. During the Beijing plugfest, I noticed that requests to my implementation (which runs a server and a proxy on the same port) repeatedly got stuck in an infinite loop. Before we had mandatory Uri-Authority, my implementation simply did this: if Uri-Authority is present: resolve Uri-Authority to IP address forward request to resolved address else: serve resource Now, my implementation does this: if Uri-Authority in { [::1]:61616, 127.0.0.1:61616, localhost:61616, coap.no-ip.org:61616, 92.224.240.96:61616, g224240096.adsl.alicedsl.de:61616, [2002:5ce0:f060::5ce0:f060]:61616 }: serve resource else: resolve Uri-Authority to IP address forward request to resolved address This makes the proxy forward requests to itself when a client knows an authority for the server which the server/proxy doesn't know about (e.g., because it's behind a NAT, there are additional A/AAAA records, etc.) Is this a bug in my implementation? Do we need to change the protocol? Or are proxy and server on the same port generally discouraged? Klaus (For reference, I'd expect a gateway to operate like this: if Uri-Authority == server1:61616: forward request to IP address configured for server1 elif Uri-Authority == server2:61616: forward request to IP address configured for server2 elif Uri-Authority in { [::1]:61616, 127.0.0.1:61616, ... }: serve resource else: return 404 ) From klaus.hartke@googlemail.com Tue Nov 16 09:13:15 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1C013A6CD2 for ; Tue, 16 Nov 2010 09:13:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dN0gQCxF+8Wn for ; Tue, 16 Nov 2010 09:13:14 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id A4D983A6CA2 for ; Tue, 16 Nov 2010 09:13:14 -0800 (PST) Received: by gyh20 with SMTP id 20so517484gyh.31 for ; Tue, 16 Nov 2010 09:13:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=qyyIDtKlJA5bWVcISDilc/E4bufZVoJ3tiku8DdV81k=; b=afPS558wP79zMVnYCP+WhcNZZk2imx96iWaOOcngkJ7IjCkcc8p0YtzRMaA1ExqM3A YcHUNsqq60spkRgN90JYNyMoLlP7VaifzzaNw3eZM9vyOaz9Vjq3L1Y8qSB+eUcUZrAc wuJWIBqXTB2cQVwSAGfKIi4Z5/CooWGFLzZxU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=TbpyQes7hSVpFi3oEZt+z6qnMOIkdL1aAE1F6DUCvu9zUBTy2YP2Dmiyp2vV96SLvf joYMwWugPVlE6IqNSyF9nzQNezXhxP+04pbtzsK/7xKy0Q7noXz7up+s+AB8kVf4zujq 6DcVTxtInog014rh6dP7jnR2Ho1Si6f1YSkl0= MIME-Version: 1.0 Received: by 10.204.98.75 with SMTP id p11mr6308906bkn.55.1289927633562; Tue, 16 Nov 2010 09:13:53 -0800 (PST) Sender: klaus.hartke@googlemail.com Received: by 10.204.121.134 with HTTP; Tue, 16 Nov 2010 09:13:53 -0800 (PST) Date: Tue, 16 Nov 2010 18:13:53 +0100 X-Google-Sender-Auth: bbQA540GxMuipQiRFcfbmJphXGY Message-ID: From: Klaus Hartke To: core Content-Type: text/plain; charset=ISO-8859-1 Subject: [core] Caching of responses X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 17:13:15 -0000 A cacheable response contains one or or more of the following information: * Transaction-local information - Token - Block - Subscription lifetime * URI - Uri-Authority - Uri-Path - Uri-Query * Freshness-related information - Max-Age * Entity - Status - Etag - Content-Type - Content The semantics of response codes are currently not specified in coap-03 but implicitly imported from HTTP. I find it confusing that a cache stores responses in whole. - Token, Block and Subscription lifetime clearly shouldn't be cached. - Wouldn't it make more sense to store a local expiration date (i.e., an absolute value) instead of Max-Age (a relative value)? - Does a 304 response set the expiration date of the stored response to (Now + StoredResponse.MaxAge) or (Now + 304Response.MaxAge)? (Since Max-Age has a default value, a response cannot not have a Max-Age). - Does a response retrieved from a cache have the original Max-Age value or an updated Max-Age value that reflects the remaining time the response is considered fresh? - Is a 404 response cached? Can a stored 404 response be validated with an Etag? Does Max-Age apply to 404 responses? - Is any other 4xx or a 5xx response cached? A lot of this are implementation details. But I feel that some bits are currently underspecified and should be clarified. Proposal: * A cache stores tuples of the form { URI, Etag, Status, FreshBefore, ContentType, Content } * A cacheable response with any code except 304 adds or updates the tuple for the given URI and Etag. FreshBefore is set to (Now + response.MaxAge). ContentType and Content are set to nil for any code except 200. Any previously stored tuple for the given URI is considered not fresh. * A cacheable response with code 304 updates the tuple for the given URI and Etag. FreshBefore is set to (Now + response.MaxAge). Status, ContentType and Content remain unchanged. Any previously stored tuple for the given URI is considered not fresh. So, an Etag absent from a response is treated like an empty Etag, except that a stored tuple with empty Etag cannot be validated, and there is always at most one tuple that is considered fresh. Token, Block, Subscription lifetime, Location and Max-Age options are not cached. Klaus From cabo@tzi.org Tue Nov 16 10:01:01 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 819D33A6C89 for ; Tue, 16 Nov 2010 10:01:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fw8D2vQ8vwGg for ; Tue, 16 Nov 2010 10:01:00 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 235C43A6CE7 for ; Tue, 16 Nov 2010 10:00:59 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id oAGI1ac4017107 for ; Tue, 16 Nov 2010 19:01:36 +0100 (CET) Received: from [192.168.217.101] (p5489E218.dip.t-dialin.net [84.137.226.24]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id EC072F93; Tue, 16 Nov 2010 19:01:35 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Tue, 16 Nov 2010 19:01:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <97485938-E515-445D-88AD-B2F536CD44F8@tzi.org> References: To: Klaus Hartke X-Mailer: Apple Mail (2.1081) Cc: core Subject: Re: [core] Caching of responses X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 18:01:01 -0000 Hi Klaus, nice! These are all very good points for clarification of the spec. Let me try to add my personal view of how they might be resolved. As usual, I'll use RFC 2616 for guidance, unless that would lead down = the wrong path. On Nov 16, 2010, at 18:13, Klaus Hartke wrote: > A cacheable response contains one or or more of the following = information: >=20 > * Transaction-local information > - Token > - Block > - Subscription lifetime >=20 > * URI > - Uri-Authority > - Uri-Path > - Uri-Query >=20 > * Freshness-related information > - Max-Age >=20 > * Entity > - Status > - Etag > - Content-Type > - Content (s/Content/Payload/...) > The semantics of response codes are currently not specified in coap-03 > but implicitly imported from HTTP. >=20 > I find it confusing that a cache stores responses in whole. Does the current text say that? Where? > - Token, Block and Subscription lifetime clearly shouldn't be cached. (Unless a Cache caches any blocks separately. During a blockwise sequence of initial GETs, the Cache will have part of = the resource and MAY already answer requests for the parts it has! But yes, that is not caching the Block option, it is caching parts of = the resource representation.) > - Wouldn't it make more sense to store a local expiration date (i.e., > an absolute value) instead of Max-Age (a relative value)? I would indeed expect a cache implementation to convert a max-age into = an absolute expiration time. This is an implementation detail, however. =20 RFC 2616 says: When the max-age cache-control directive is present in a cached response, the response is stale if its current age is greater than the age value given (in seconds) at the time of a new request for that resource. > - Does a 304 response set the expiration date of the stored response > to (Now + StoredResponse.MaxAge) or (Now + 304Response.MaxAge)? (Since > Max-Age has a default value, a response cannot not have a Max-Age). Good point. The second. RFC 2616 says: If a cache uses a received 304 response to update a cache entry, the cache MUST update the entry to reflect any new field values given in the response. > - Does a response retrieved from a cache have the original Max-Age > value or an updated Max-Age value that reflects the remaining time the > response is considered fresh? The latter. > - Is a 404 response cached? Can a stored 404 response be validated > with an Etag? Does Max-Age apply to 404 responses? HTTP does allow the caching of errors. > - Is any other 4xx or a 5xx response cached? HTTP does allow the caching of errors. (Of course, it never mandates caching.) > A lot of this are implementation details. But I feel that some bits > are currently underspecified and should be clarified. >=20 > Proposal: >=20 > * A cache stores tuples of the form { URI, Etag, Status, FreshBefore, > ContentType, Content } This is getting dangerously close to an implementation model. One other interesting question is what happens to elective options not = understood by the cache. > * A cacheable response with any code except 304 adds or updates the > tuple for the given URI and Etag. > FreshBefore is set to (Now + response.MaxAge). Again, that is an implementation detail. The Cache might as well cache = max-age and keep a local age counting up as in the model used by RFC = 2616. This is equivalent to FreshBefore but does not introduce a separate = concept. > ContentType and Content are set to nil for any code except 200. > Any previously stored tuple for the given URI is considered not = fresh. >=20 > * A cacheable response with code 304 updates the tuple for the given > URI and Etag. > FreshBefore is set to (Now + response.MaxAge). > Status, ContentType and Content remain unchanged. > Any previously stored tuple for the given URI is considered not = fresh. >=20 > So, an Etag absent from a response is treated like an empty Etag, > except that a stored tuple with empty Etag cannot be validated, and > there is always at most one tuple that is considered fresh. >=20 > Token, Block, Subscription lifetime, Location and Max-Age options are > not cached. (See above for max-age.) I don't like the sentence in 5.1: If the client specifies a Max-Age of zero seconds, then the response MUST discard the cached representation and return a fresh representation. "Discard"? Of course, it should be able to serve the cached = representation to others that request less critical max-age values until = the new response is available. Gruesse, Carsten From zach@sensinode.com Tue Nov 16 23:24:01 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3CAB3A6891 for ; Tue, 16 Nov 2010 23:24:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.196 X-Spam-Level: X-Spam-Status: No, score=-3.196 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, WEIRD_PORT=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dzLmGz0V9HrC for ; Tue, 16 Nov 2010 23:24:00 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 0AE173A680C for ; Tue, 16 Nov 2010 23:23:59 -0800 (PST) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id oAH7Oe2x023151 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 17 Nov 2010 09:24:41 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-55-286353289; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: Date: Wed, 17 Nov 2010 09:24:42 +0200 Message-Id: <1909899D-43E8-4C00-B957-6787468B4CDB@sensinode.com> References: To: Klaus Hartke X-Mailer: Apple Mail (2.1081) Cc: core Subject: Re: [core] Proxy and server on the same port X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 07:24:02 -0000 --Apple-Mail-55-286353289 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 16, 2010, at 7:08 PM, Klaus Hartke wrote: > Terminology: > - server: an end-point that serves resources; > - proxy: an end-point that can be tasked with retrieving/manipulating > remote resources on behalf of a client; > - gateway: an end-point that looks/feels/smells like a server, but > forwards requests to one or more servers and/or handles requests on > behalf of them. Yep. >=20 > During the Beijing plugfest, I noticed that requests to my > implementation (which runs a server and a proxy on the same port) > repeatedly got stuck in an infinite loop. >=20 > Before we had mandatory Uri-Authority, my implementation simply did = this: >=20 > if Uri-Authority is present: > resolve Uri-Authority to IP address > forward request to resolved address > else: > serve resource >=20 > Now, my implementation does this: >=20 > if Uri-Authority in { [::1]:61616, 127.0.0.1:61616, > localhost:61616, coap.no-ip.org:61616, 92.224.240.96:61616, > g224240096.adsl.alicedsl.de:61616, [2002:5ce0:f060::5ce0:f060]:61616 > }: > serve resource > else: > resolve Uri-Authority to IP address > forward request to resolved address >=20 > This makes the proxy forward requests to itself when a client knows an > authority for the server which the server/proxy doesn't know about > (e.g., because it's behind a NAT, there are additional A/AAAA records, > etc.) >=20 > Is this a bug in my implementation? Do we need to change the protocol? > Or are proxy and server on the same port generally discouraged? To me the answer is discouraging (forbidding?) running a proxy and a = server on the same port. Running a proxy and a server on the same port = is not common practice with HTTP servers either as far as I know. =20 Zach >=20 >=20 > Klaus >=20 >=20 > (For reference, I'd expect a gateway to operate like this: >=20 > if Uri-Authority =3D=3D server1:61616: > forward request to IP address configured for server1 > elif Uri-Authority =3D=3D server2:61616: > forward request to IP address configured for server2 > elif Uri-Authority in { [::1]:61616, 127.0.0.1:61616, ... }: > serve resource > else: > return 404 > ) > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 --Apple-Mail-55-286353289 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9 fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb 6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja 5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I 2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTExNzA3MjQ0 MlowIwYJKoZIhvcNAQkEMRYEFLm++mSSTDaJvMJtiQIBBfNYvVujMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAAhK8lx/GmGlxg8gk4nhW7qEYKMUKGxXSypvJkMn/X+sqYEQrdoTZsiT t8u81slJp72zzLp+1ZWt6gweU065mxDfpJ8UKf45a3jbrOmwrVKWpAB/5/JIfKR2ykXvkP1w0q9U 308PyP3HdcXzR8TdzFAlKdYJvpd2lngXeu8dh2YK1yM+UmOY9Uc23OkXVCxjAilT9dDuL5jMCzDg EHPkalZLq1UUbSxGfDyhtNBnkvz4SoP3VE1cYVasU7SQOBeq/zS/Gr9IHc7XFQDcOgF7OynmSzCP p/DamI4IJ3dB2BuCo2fHJTOlpRemfdjjE6UWnV0raW66Vq440mFD0YfINZ0AAAAAAAA= --Apple-Mail-55-286353289-- From alexey.melnikov@isode.com Tue Nov 16 23:32:13 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2F4B3A688A for ; Tue, 16 Nov 2010 23:32:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZpBizC0FkwKo for ; Tue, 16 Nov 2010 23:32:12 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 631D03A680C for ; Tue, 16 Nov 2010 23:32:12 -0800 (PST) Received: from [192.168.20.2] ((unknown) [212.183.140.19]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 17 Nov 2010 07:32:55 +0000 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4CE38524.60106@isode.com> Date: Wed, 17 Nov 2010 15:32:52 +0800 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.21) Gecko/20090303 SeaMonkey/1.1.15 To: core@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [core] Review of draft-ietf-core-coap-03.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 07:32:13 -0000 Hi, I've decided to do IESG-type review of the document, as it seems to be getting close to being done. many of my comments are editorial in nature. In general I found the document to be well written. In Section 1 - the first reference to HTTP needs an Informative Reference. In Section 2.1.2 (Asynchronous response) - the first reference to "token option" needs a reference (either a cross reference, or an external reference). > 2.5.1. Option Processing > > If no options are to be included, the Option Count field is set to 0 > below and the Payload (if any) immediately follows the Transaction > ID. If options are to be included, the following rules apply. The > number of options is placed in the Option Count field. Each option > is then placed in order of Type, immediately following the > Transaction ID with no padding. Upon reception, unknown options of > class "elective" MUST be silently skipped. Unknown options of class > "critical" in a Confirmable MUST cause the return of a response code > "Critical Option not supported (CoAP 242)" including a copy of the > critical option number in the payload of the response. Does this need a new payload (MIME) type registration? Options don't seem to be considered to be a part of a payload (assuming my reading of Sections 3 and 3.1 is correct). Or did you mean that the options need to be returned as TLVs? > 3.2.8. Token Option > > This option MUST NOT occur ore than once in a header. typo: more > 5.1. Cache control > In general, the origin server end-point is responsible for > determining cache age. However, in some cases a client may wish to > determine its own tolerance for cache staleness. In this case, a > client may specify the Max-Age header during a GET request. If the > client's Max-Age is of a shorter duration than the age of a cached "than the remaining age"? > resource, then the proxy or end-point SHOULD perform a cache refresh. > If the client specifies a Max-Age of zero seconds, then the response > MUST discard the cached representation and return a fresh In Section 7 - the first references to XMPP and SIP require Informative References. > 7. HTTP Mapping > > The caching and proxying of CoAP is specified in Section 5. In a > similar manner, caching and proxying MAY be performed between CoAP > and HTTP by an intermediate node. A proxy SHOULD respond with a 502 > (Bad Gateway) error to HTTP requests which can not be successfully > mapped to CoAP. CoAP transaction messages are transparent to > request/response exchanges and MUST have no affect on a proxy > function. I am not entirely sure about the meaning of the last sentence. Can you clarify? > 10. Security Considerations > > Certificate: The device has an asymmetric key pair with a X.509 > [RFC5280] certificate that binds it to its Authority Name and is > signed by a some common trust root. The device also has a list or > root trust anchors that can be used for validating a certificate. > There may be an optional shared key that all the nodes that > communicate have access too. > > The Authority Name in the certificate is the name that would be used > in the Authority part of a CoAP URI. It is worth noting that this > would typically not be either an IP address or DNS name but would > instead be a long term unique identifier for the device such as the > EUI-64. I think this needs a reference. > The discovery process used in the system would build up the > mapping between IP addresses of the given devices and the Authority > Name for each device. Some devices could have more than one > Authority and would need more than a single certificate. > 10.2. Securing CoAP with DTLS > > Devices SHOULD support the Server Name Indication (SNI) to indicate > their Authority Name in the SNI HostName field as defined in Section > 3 of draft-ietf-tls-rfc4366-bis. That document was approved by IESG, so this needs to be converted to a proper Normative Reference. > This is needed so that when a host > that acts as a virtual server for multiple Authorities receives a new > DTLS connection, it knows which keys to use for the DTLS session. > 10.2.1. SharedKey & MultiKey Modes > > When forming a connection to a new node, the system selects an > appropriate key based on which nodes it is trying to reach then forms > a DTLS session using a PSK (Pre-Shared Key) mode of DTLS. > Implementations SHOULD support the mandatory to implement cipher I think this needs to be a MUST, conditional on DTLS being supported by the node. > suite TLS_PSK_WITH_AES_128_CBC_SHA as specified in [RFC5246]. > 10.2.2. Certificate Mode > > As with IPsec, DTLS should be configured with a cypher suite > compatible with any possible hardware engine on the node, for example > AES-CBC in the case of IEEE 802.15.4. Implementations SHOULD support As above, I think this needs to be a MUST. > the mandatory to implement cipher suite TLS_RSA_WITH_AES_128_CBC_SHA > as specified in [RFC5246]. In Section 11 - IANA registration policy for COAP status codes and COAP MIME types is not defined. I suggest Expert Review at minimum (because of code/MIME type space is so small). Also, the coap:// URI scheme needs to be registered using the URI registration template. Should COAP methods be registered with IANA together with COAP status codes (as they are used in the same field)? From matthieu.vial@fr.non.schneider-electric.com Wed Nov 17 03:12:07 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADF243A68B3; Wed, 17 Nov 2010 03:12:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[AWL=0.558, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oLuLN2fNr6+4; Wed, 17 Nov 2010 03:12:01 -0800 (PST) Received: from mailX01.eud.schneider-electric.com (mailx01.eud.schneider-electric.com [205.167.7.35]) by core3.amsl.com (Postfix) with ESMTP id 3F31E3A68A8; Wed, 17 Nov 2010 03:11:59 -0800 (PST) Received: from ateui02.Schneider-Electric.com ([10.198.14.10]) by mailX01.eud.schneider-electric.com with ESMTP id 2010111711533680-57448 ; Wed, 17 Nov 2010 11:53:36 +0100 In-Reply-To: To: Klaus Hartke X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: matthieu.vial@fr.non.schneider-electric.com Date: Wed, 17 Nov 2010 12:12:40 +0100 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on ATEUI02.Schneider-Electric.com/T/SVR/Schneider at 17/11/2010 12:12:37, Itemize by SMTP Server on AXEU1OUT.schneider-electric.com/X/SVR/SEIxtra at 17/11/2010 11:53:36, Serialize by Router on AXEU1OUT.schneider-electric.com/X/SVR/SEIxtra at 17/11/2010 11:53:37, Serialize complete at 17/11/2010 11:53:37 Content-type: multipart/alternative; Boundary="0__=4EBBFD4DDFA470B58f9e8a93df938690918c4EBBFD4DDFA470B5" Content-Disposition: inline Cc: core-bounces@ietf.org, core Subject: Re: [core] Subscription and Tokens/EventId X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 11:12:07 -0000 --0__=4EBBFD4DDFA470B58f9e8a93df938690918c4EBBFD4DDFA470B5 Content-transfer-encoding: quoted-printable Content-type: text/plain; charset=US-ASCII Brian Frank wrote: >> I agree - I think we should just pick the one most limited devices w= ill >> probably support (which IMO is URI correlation). >URI correlation doesn't suffice if a client has more than one >outstanding request to the same resource. A client implementation can >opt-out from having more than one outstanding request, but a server >implementation cannot. What do you mean by the same resource ? The same URI-Path and URI-Query= on different servers ? >> I think we could even simplify it even further to just say that as l= ong as >> the client is ack'ing the notifications we can assume it is still interested >> in the subscription. [...] >I like the idea of using ack'ing the notifications to signal that the >client is still interested in receiving notifications. To make sure >the server is still sending notifications, the client could refresh >the subscription after it didn't receive a notification for some time >(which it probably should be doing anyway). Then "subscription lifetime" would be replaced by "maximum allowed time= between 2 notifications" ? This is an interesting idea because the clie= nt will have to repeat the subscription request (with a potentially long U= RI) only in case of failure or very infrequent events. Most of the time bot= h the server and the client know they can get in touch. And they reset th= eir time counter to the maximum allowed time on each notification. However = in case of very frequent notifications acking all notifications may not be= the optimal solution. The server should be able to send non confirmable message. For example if the time since the last notification is short compared to the maximum allowed time the server could decide to send th= e next notification as a non confirmable message. Sadly this mechanism requires more state because the server must store the maximum allowed t= ime plus the time counter. Maybe the state could be on a per client basis? = If we don't need a mechanism which is tolerant to transient failures the server could also just release all observations from a client if a notification is not acked as suggested by Brian. But if it is supposed = to be deployed in lossy networks I'm not sure this is the right solution. Does that make sense ? Matthieu= --0__=4EBBFD4DDFA470B58f9e8a93df938690918c4EBBFD4DDFA470B5 Content-transfer-encoding: quoted-printable Content-type: text/html; charset=US-ASCII Content-Disposition: inline

    Brian Frank wrote:
    >> I agree - I think we should just pick the one most limited dev= ices will
    >> probably support (which IMO is URI correlation).

    >URI correlation doesn't suffice if a client has more than one
    >outstanding request to the same resource. A client implementation c= an
    >opt-out from having more than one outstanding request, but a server=
    >implementation cannot.

    What do you mean by the same resource ? The same URI-Path and URI-Query= on different servers ?


    >> I think we could even simplify it even further to just say tha= t as long as
    >> the client is ack'ing the notifications we can assume it is st= ill interested
    >> in the subscription. [...]

    >I like the idea of using ack'ing the notifications to signal that t= he
    >client is still interested in receiving notifications. To make sure=
    >the server is still sending notifications, the client could refresh=
    >the subscription after it didn't receive a notification for some ti= me
    >(which it probably should be doing anyway).

    Then "subscription lifetime" would be replaced by "maxim= um allowed time between 2 notifications" ? This is an interesting = idea because the client will have to repeat the subscription request (w= ith a potentially long URI) only in case of failure or very infrequent = events. Most of the time both the server and the client know they can g= et in touch. And they reset their time counter to the maximum allowed t= ime on each notification. However in case of very frequent notification= s acking all notifications may not be the optimal solution. The server = should be able to send non confirmable message. For example if the time= since the last notification is short compared to the maximum allowed t= ime the server could decide to send the next notification as a non conf= irmable message. Sadly this mechanism requires more state because the s= erver must store the maximum allowed time plus the time counter. Maybe = the state could be on a per client basis? If we don't need a mechanism = which is tolerant to transient failures the server could also just rele= ase all observations from a client if a notification is not acked as su= ggested by Brian. But if it is supposed to be deployed in lossy network= s I'm not sure this is the right solution.
    Does that make sense ?

    Matthieu= --0__=4EBBFD4DDFA470B58f9e8a93df938690918c4EBBFD4DDFA470B5-- From ngocthanhdinh@gmail.com Wed Nov 17 03:41:58 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 838363A68D5 for ; Wed, 17 Nov 2010 03:41:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id erKJgw4FqBpC for ; Wed, 17 Nov 2010 03:41:57 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id DB61B3A68D2 for ; Wed, 17 Nov 2010 03:41:56 -0800 (PST) Received: by bwz12 with SMTP id 12so1563716bwz.31 for ; Wed, 17 Nov 2010 03:42:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=cay/fUJ3DYSPcjWrcRITkDFWCXTSYRhjwe6YKrOVj+Q=; b=ISnhvcLu1Ijy/LXo+fU1W5txzVBKYgi1hHgFUujrz6yUKuKKg4pRRC+Y6x2vf8V2rg DOhfRj4ZrkeTMAMkkw8xaFDbQmbU0momucuW6wJZrMfZrKATxBb29op0x2ck0ICM/Bfg zA9pZKHlzRzvZw4I2TNLiUojkurS32aAwuplQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=rbz7qLq7fEmuEaTGYVsHVEAUwsxr6RnD/rpinUxCpm8QJk484ihhvEmamQRFnM3B5v XzTkN8wYHmUIUn/f/d9Ef0N7lEq4nVrAJ15g+drKq6rgFsUFGjDC+EmPgFRvKOFhKphj aBC+M/84EPAFFN8/uluqCjFtVIi0pK4EMjbfM= MIME-Version: 1.0 Received: by 10.204.65.204 with SMTP id k12mr9007824bki.169.1289994161380; Wed, 17 Nov 2010 03:42:41 -0800 (PST) Received: by 10.204.52.146 with HTTP; Wed, 17 Nov 2010 03:42:41 -0800 (PST) Date: Wed, 17 Nov 2010 20:42:41 +0900 Message-ID: From: Thanh Ngoc To: core@ietf.org Content-Type: multipart/alternative; boundary=001636c5b800c05e1104953e2b31 Subject: [core] Asking you about problem for CoAP Demo X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 13:17:26 -0000 --001636c5b800c05e1104953e2b31 Content-Type: text/plain; charset=ISO-8859-1 Dear all members, i a new member. now i have to make Demo of CoAP. i am reading some draft about CoAP and i wonder does it has any implementation of CoAP. Can you help me how to start to make a Demo of CoAP such as : a program can send a request information from Mote, or put some value into mote. or something look like http protocol. if it is implemented already. could you help me know some information about that to help me run a Demo of CoAP. thank you very much, Ngoc Thanh --001636c5b800c05e1104953e2b31 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear all members,

    i a new member. now i have to make Demo of CoAP.i am reading some draft about CoAP and i wonder does it has any implement= ation of CoAP.

    Can you help me how to start to make a Demo of CoAP s= uch as :

    a program can send a request information from Mote, or put some value i= nto mote.
    or something look like http protocol.

    if it is implemen= ted already. could you help me know some information about that to help me = run a Demo of CoAP.


    thank you very much,

    =A0 Ngoc Thanh
    --001636c5b800c05e1104953e2b31-- From klaus.hartke@googlemail.com Wed Nov 17 06:09:32 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 684FC3A690E for ; Wed, 17 Nov 2010 06:09:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[AWL=-0.324, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_33=0.6, WEIRD_PORT=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NbT1AwF5dBPF for ; Wed, 17 Nov 2010 06:09:31 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 1CF723A6912 for ; Wed, 17 Nov 2010 06:09:30 -0800 (PST) Received: by bwz12 with SMTP id 12so1715297bwz.31 for ; Wed, 17 Nov 2010 06:10:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=zwTlXKoBphk8L4rE1HvSRCH9zVNgAFYDi/0I0xtfdOQ=; b=J9wCIW281w933xuJ03amYYxWGJcRzvDprYp6EzZv8qQMkhFVXG5CEheFTB2uHkHe8p gsoVVWhkHWPiUu5UCL9yhU09NfO2ZPAvZV3DpZ5q+U7z0fny5CGJcY3DBiiR8cOVnsnb sy4mOEX6DD9S6n6YquD6I+RIAm9TP7dGXAihc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=GhSkNd0TgARzBdP1yHJzk44zUSgkOznHqN3aB8wSWGBBYecFRTkWEZIoCoy4oyr6Yp 47UeGWBCoUASd6mBbV6ePwtvzusUB05ePHdva6d08X8WIsvnsXlBlr8r/Nty2n1SR0+a iIVlx3z2O3HmpcvE9PYnnl8lpXkBaQjMU2KH4= MIME-Version: 1.0 Received: by 10.204.119.133 with SMTP id z5mr9135478bkq.82.1290003012104; Wed, 17 Nov 2010 06:10:12 -0800 (PST) Sender: klaus.hartke@googlemail.com Received: by 10.204.121.134 with HTTP; Wed, 17 Nov 2010 06:10:11 -0800 (PST) In-Reply-To: References: Date: Wed, 17 Nov 2010 15:10:11 +0100 X-Google-Sender-Auth: YQy8fgA--fZyVJzFJRxyCxk3wtw Message-ID: From: Klaus Hartke To: core Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [core] Subscription and Tokens/EventId X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 14:09:32 -0000 matthieu.vial@fr.non.schneider-electric.com wrote: >>URI correlation doesn't suffice if a client has more than one >>outstanding request to the same resource. A client implementation can >>opt-out from having more than one outstanding request, but a server >>implementation cannot. > > What do you mean by the same resource ? The same URI-Path and URI-Query on > different servers ? Example: C: GET coap://example.org:61616/resource C: POST coap://example.org:61616/resource "foo" S: 200 coap://example.org:61616/resource S: 405 coap://example.org:61616/resource Which response belongs to which request? Solution 1: "Then don't do it" C: GET coap://example.org:61616/resource S: 405 coap://example.org:61616/resource C: POST coap://example.org:61616/resource "foo" S: 200 coap://example.org:61616/resource Solution 2: Tokens C: GET coap://example.org:61616/resource (token=42) C: POST coap://example.org:61616/resource (token=99) "foo" S: 200 (token=99) S: 405 (token=42) >>I like the idea of using ack'ing the notifications to signal that the >>client is still interested in receiving notifications. To make sure >>the server is still sending notifications, the client could refresh >>the subscription after it didn't receive a notification for some time >>(which it probably should be doing anyway). > > Then "subscription lifetime" would be replaced by "maximum allowed time > between 2 notifications" ? Yes, the client could inform the server of that duration after which it subscribes again. I could imagine it's just an implementation detail how the server uses this information. The server could: - send a confirmable notification with the current state just before the time is up; - end the subscription after it didn't send a notification for that duration, so it doesn't have to keep the subscription around until the next notification; - simply ignore it and keep the subscription going as long as the client is ack'ing notifications; - simply ignore it and regularly kill all subscriptions. - ... > However in case of > very frequent notifications acking all notifications may not be the optimal > solution. The server should be able to send non confirmable message. Right, the server should implement some strategy when to send notifications confirmable or non-confirmable (ticket #67). In the best case (which is very likely for very constrained nodes) the server implementation knows about the application: For example, if the resource represents a temperature sensor that changes its state every second, the server implementation could be hard-coded to send the notification for every n'th state change confirmable and all other non-confirmable. This example would require only per-resource state. Klaus From klaus.hartke@googlemail.com Wed Nov 17 06:26:19 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F9323A68F6 for ; Wed, 17 Nov 2010 06:26:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gw8XkQJ1aBlq for ; Wed, 17 Nov 2010 06:26:18 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 0A0443A6903 for ; Wed, 17 Nov 2010 06:26:17 -0800 (PST) Received: by bwz12 with SMTP id 12so1731787bwz.31 for ; Wed, 17 Nov 2010 06:27:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=DnzkBkKFGRqPq3vcalEQ25Mld/SbVKmZf5iVkv5uof4=; b=fz3ZdVZygjGoggsTjsaFwKT/sEf7XLVn8NQQQUTeRVm4bgQxR7FKatiIGoqdzVkAOm e9yVcJm1KruhZTf8U2WMXGhD/DwwzTqQBCsN+TazGzlf8GktOXfsGHwvaN1Mb3BilO2z MGttwBL4UiqRiqaYd4rd+TA3IK2OTfbW9dEYk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=KukQFF1PsMA+EZUfDEevN/CM6dslHqZ0vf2PjPLGWhyVck4tzUKQ3T1JCByqV2F9WR OIL320WPSVZKjy6m/mM9sKt8fYBRjpsF9/SuoQ3cI/BZoKh6VcZmb2Mq5GJSnr3rYEbE ast8tOzTWBUq2RaixW57akcOo/An1u9oTrC9M= MIME-Version: 1.0 Received: by 10.204.72.140 with SMTP id m12mr9125130bkj.163.1290004023025; Wed, 17 Nov 2010 06:27:03 -0800 (PST) Sender: klaus.hartke@googlemail.com Received: by 10.204.121.134 with HTTP; Wed, 17 Nov 2010 06:27:02 -0800 (PST) In-Reply-To: <1909899D-43E8-4C00-B957-6787468B4CDB@sensinode.com> References: <1909899D-43E8-4C00-B957-6787468B4CDB@sensinode.com> Date: Wed, 17 Nov 2010 15:27:02 +0100 X-Google-Sender-Auth: dBxbpBFgEVm9PMR5IV_-JJFZnOU Message-ID: From: Klaus Hartke To: core Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [core] Proxy and server on the same port X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 14:26:19 -0000 Zach Shelby wrote: > To me the answer is discouraging (forbidding?) running a proxy and a server on the same port. Running a proxy and a server on the same port is not common practice with HTTP servers either as far as I know. What about this: A proxy runs on [2001::xx:1]:61616. A client believes that [2001::xx:1]:61616 is a server (for example, because [2001::xx:1]:61616 actually was a server like half an hour ago). The client sends a request for coap://[2001::xx:1]:61616/resource to [2001::xx:1]:61616. The proxy begins to retrieve coap://[2001::xx:1]:61616/resource on behalf of the client. Because it cannot retrieve the resource immediately, it ack's the client's request. While the client has no reason to not believe the remote end-point is a server and will return the requested resource in a few moments, the proxy will forward the request to itself, which will cause it to forward the request to itself, which will cause it to forward the request to itself, ... Klaus From matthieu.vial@fr.non.schneider-electric.com Wed Nov 17 07:35:23 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93D003A692C; Wed, 17 Nov 2010 07:35:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.852 X-Spam-Level: X-Spam-Status: No, score=-2.852 tagged_above=-999 required=5 tests=[AWL=0.746, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, WEIRD_PORT=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebPE5f3c29zl; Wed, 17 Nov 2010 07:35:22 -0800 (PST) Received: from mailX03.eud.schneider-electric.com (mailx03.eud.schneider-electric.com [205.167.7.41]) by core3.amsl.com (Postfix) with ESMTP id 7FFEF3A692A; Wed, 17 Nov 2010 07:35:22 -0800 (PST) Received: from ateui02.Schneider-Electric.com ([10.198.14.10]) by mailX03.eud.schneider-electric.com with ESMTP id 2010111716220509-186872 ; Wed, 17 Nov 2010 16:22:05 +0100 In-Reply-To: To: Klaus Hartke X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: matthieu.vial@fr.non.schneider-electric.com Date: Wed, 17 Nov 2010 16:36:02 +0100 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on ATEUI02.Schneider-Electric.com/T/SVR/Schneider at 17/11/2010 16:36:00, Itemize by SMTP Server on AXEU3OUT.schneider-electric.com/X/SVR/SEIxtra at 17/11/2010 16:22:05, Serialize by Router on AXEU3OUT.schneider-electric.com/X/SVR/SEIxtra at 17/11/2010 16:22:06, Serialize complete at 17/11/2010 16:22:06 Content-type: multipart/alternative; Boundary="0__=4EBBFD4DDFC0CC698f9e8a93df938690918c4EBBFD4DDFC0CC69" Content-Disposition: inline Cc: core-bounces@ietf.org, core Subject: Re: [core] Subscription and Tokens/EventId X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 15:35:23 -0000 --0__=4EBBFD4DDFC0CC698f9e8a93df938690918c4EBBFD4DDFC0CC69 Content-type: text/plain; charset=US-ASCII >Example: > C: GET coap://example.org:61616/resource > C: POST coap://example.org:61616/resource "foo" > S: 200 coap://example.org:61616/resource > S: 405 coap://example.org:61616/resource >Which response belongs to which request? According to coap-3 the responses can't be asynchronous because the client requests didn't include a Token option. So I would answer look at the transaction ID. C: CON TID 1 GET coap://example.org:61616/resource C: CON TID 2 POST coap://example.org:61616/resource "foo" S: ACK TID 1 200 coap://example.org:61616/resource S: ACK TID 2 405 coap://example.org:61616/resource But as I understand coap-observe all notifications (except the first one transmitted with the ACK) are asynchronous responses so according to coap-3 a token is required. Matthieu --0__=4EBBFD4DDFC0CC698f9e8a93df938690918c4EBBFD4DDFC0CC69 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

    >Example:

    > C: GET coap://example.org:61616/resource
    > C: POST coap://example.org:61616/resource "foo"
    > S: 200 coap://example.org:61616/resource
    > S: 405 coap://example.org:61616/resource

    >Which response belongs to which request?

    According to coap-3 the responses can't be asynchronous because the client requests didn't include a Token option. So I would answer look at the transaction ID.

    C: CON TID 1 GET coap://example.org:61616/resource
    C: CON TID 2 POST coap://example.org:61616/resource "foo"
    S: ACK TID 1 200 coap://example.org:61616/resource
    S: ACK TID 2 405 coap://example.org:61616/resource

    But as I understand coap-observe all notifications (except the first one transmitted with the ACK) are asynchronous responses so according to coap-3 a token is required.

    Matthieu --0__=4EBBFD4DDFC0CC698f9e8a93df938690918c4EBBFD4DDFC0CC69-- From cabo@tzi.org Wed Nov 17 10:04:55 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D97F33A6949 for ; Wed, 17 Nov 2010 10:04:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100, WEIRD_PORT=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwg6YP4Nqd4H for ; Wed, 17 Nov 2010 10:04:55 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 73FDE3A693C for ; Wed, 17 Nov 2010 10:04:38 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id oAHI5HZv006864 for ; Wed, 17 Nov 2010 19:05:17 +0100 (CET) Received: from [192.168.217.101] (p5489E3E0.dip.t-dialin.net [84.137.227.224]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3B6E459B; Wed, 17 Nov 2010 19:05:17 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Wed, 17 Nov 2010 19:05:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Klaus Hartke X-Mailer: Apple Mail (2.1081) Cc: core Subject: Re: [core] Subscription and Tokens/EventId X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 18:04:55 -0000 On Nov 17, 2010, at 15:10, Klaus Hartke wrote: > Solution 2: Tokens Solution 2a: require tokens for asynchronous responses to = POST/PUT/DELETE, because the response is about the request, not about = the resource. (An asynchronous response to a GET is self-describing.) Weird but elucidating example: C: GET coap://example.org:61616/resource ... C: GET coap://example.org:61616/resource ... S: 200 coap://example.org:61616/resource (Yes, that asynchronous response answers both requests!) Gruesse, Carsten From matthieu.vial@fr.non.schneider-electric.com Thu Nov 18 02:09:31 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7755D3A6804; Thu, 18 Nov 2010 02:09:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=0.621, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, WEIRD_PORT=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YAbVTgx6mVi6; Thu, 18 Nov 2010 02:09:30 -0800 (PST) Received: from mailX02.eud.schneider-electric.com (mailx02.eud.schneider-electric.com [205.167.7.38]) by core3.amsl.com (Postfix) with ESMTP id 456273A6765; Thu, 18 Nov 2010 02:09:30 -0800 (PST) Received: from ateui02.Schneider-Electric.com ([10.198.14.10]) by mailX02.eud.schneider-electric.com with ESMTP id 2010111810510651-48722 ; Thu, 18 Nov 2010 10:51:06 +0100 In-Reply-To: To: Carsten Bormann X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: matthieu.vial@fr.non.schneider-electric.com Date: Thu, 18 Nov 2010 11:10:11 +0100 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on ATEUI02.Schneider-Electric.com/T/SVR/Schneider at 18/11/2010 11:10:08, Itemize by SMTP Server on AXEU2OUT.schneider-electric.com/X/SVR/SEIxtra at 18/11/2010 10:51:06, Serialize by Router on AXEU2OUT.schneider-electric.com/X/SVR/SEIxtra at 18/11/2010 10:51:07, Serialize complete at 18/11/2010 10:51:07 Content-type: multipart/alternative; Boundary="0__=4EBBFD4CDFA4E29F8f9e8a93df938690918c4EBBFD4CDFA4E29F" Content-Disposition: inline Cc: core-bounces@ietf.org, core , Klaus Hartke Subject: Re: [core] Subscription and Tokens/EventId X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 10:09:31 -0000 --0__=4EBBFD4CDFA4E29F8f9e8a93df938690918c4EBBFD4CDFA4E29F Content-type: text/plain; charset=US-ASCII >> Solution 2: Tokens >Solution 2a: require tokens for asynchronous responses to POST/PUT/DELETE, because the response is about the request, not about the resource. >(An asynchronous response to a GET is self-describing.) >Weird but elucidating example: > C: GET coap://example.org:61616/resource >... > C: GET coap://example.org:61616/resource >... > S: 200 coap://example.org:61616/resource >(Yes, that asynchronous response answers both requests!) I'm not sure a GET is completely self-describing because a client may want ordered responses. Is it possible to have the following sequence? C: GET coap://example.org:61616/resource S: 200 coap://example.org:61616/resource "foo" [not received because of network delay] S: 200 coap://example.org:61616/resource "foo" [retry OK] C: PUT coap://example.org:61616/resource "bar" (token=10) S: 200 (token=10) C: GET coap://example.org:61616/resource 200 coap://example.org:61616/resource "foo" [previously delayed response] Here the client detects inconsistency and starts a failure procedure S: 200 coap://example.org:61616/resource "bar" With Token option the same sequence should look like this: C: GET coap://example.org:61616/resource (token=5) S: 200 (token=5) "foo" [not received because of network delay] S: 200 (token=5) "foo" [retry OK] C: PUT coap://example.org:61616/resource "bar" (token=10) S: 200 (token=10) C: GET coap://example.org:61616/resource (token=15) 200 (token=5) "foo" [previously delayed response] Here the client has released the request with token=5 so it sends a RESET but it continues with the current procedure C: RST S: 200 (token=15) "bar" And do we really want to support different correlation methods? I would say no just like Peter. Matthieu --0__=4EBBFD4CDFA4E29F8f9e8a93df938690918c4EBBFD4CDFA4E29F Content-type: text/html; charset=US-ASCII Content-Disposition: inline

    >> Solution 2: Tokens

    >Solution 2a: require tokens for asynchronous responses to POST/PUT/DELETE, because the response is about the request, not about the resource.
    >(An asynchronous response to a GET is self-describing.)

    >Weird but elucidating example:

    > C: GET coap://example.org:61616/resource
    >...
    > C: GET coap://example.org:61616/resource
    >...
    > S: 200 coap://example.org:61616/resource

    >(Yes, that asynchronous response answers both requests!)

    I'm not sure a GET is completely self-describing because a client may want ordered responses. Is it possible to have the following sequence?

    C: GET coap://example.org:61616/resource
    S: 200 coap://example.org:61616/resource "foo" [not received because of network delay]
    S: 200 coap://example.org:61616/resource "foo" [retry OK]
    C: PUT coap://example.org:61616/resource "bar" (token=10)
    S: 200 (token=10)
    C: GET coap://example.org:61616/resource
    200 coap://example.org:61616/resource "foo" [previously delayed response]
    Here the client detects inconsistency and starts a failure procedure
    S: 200 coap://example.org:61616/resource "bar"


    With Token option the same sequence should look like this:

    C: GET coap://example.org:61616/resource (token=5)
    S: 200 (token=5) "foo" [not received because of network delay]
    S: 200 (token=5) "foo" [retry OK]
    C: PUT coap://example.org:61616/resource "bar" (token=10)
    S: 200 (token=10)
    C: GET coap://example.org:61616/resource (token=15)
    200 (token=5) "foo" [previously delayed response]
    Here the client has released the request with token=5 so it sends a RESET but it continues with the current procedure
    C: RST
    S: 200 (token=15) "bar"

    And do we really want to support different correlation methods? I would say no just like Peter.

    Matthieu --0__=4EBBFD4CDFA4E29F8f9e8a93df938690918c4EBBFD4CDFA4E29F-- From sakane@tanu.org Thu Nov 18 18:34:51 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1139028C0EF for ; Thu, 18 Nov 2010 18:34:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[AWL=-1.169, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZoY4xEXL27zJ for ; Thu, 18 Nov 2010 18:34:46 -0800 (PST) Received: from mama.tanu.org (z189134.ppp.asahi-net.or.jp [110.4.189.134]) by core3.amsl.com (Postfix) with ESMTP id D197828C0D9 for ; Thu, 18 Nov 2010 18:34:44 -0800 (PST) Received: from dhcp-64-104-shinjuku-wlan-5-214.cisco.com (dhcp-64-104-shinjuku-wlan-5-214.cisco.com [64.104.5.214]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mama.tanu.org (Postfix) with ESMTPSA id 50D8716DC7 for ; Fri, 19 Nov 2010 11:35:32 +0900 (JST) Message-ID: <4CE5E274.6020806@tanu.org> Date: Fri, 19 Nov 2010 11:35:32 +0900 From: Shoichi Sakane User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: core@ietf.org References: <4CC0194D.4040909@tanu.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [core] COAP dissector for wireshark X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 02:34:51 -0000 FYI, The patches was merged into the wireshark svn at last. Thanks for your feedback at the plugtest. Shoichi From pab@peoplepowerco.com Sat Nov 20 02:20:16 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DCB428C0ED for ; Sat, 20 Nov 2010 02:20:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AqxouNvVXsXq for ; Sat, 20 Nov 2010 02:20:10 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 0AD0E3A69A3 for ; Sat, 20 Nov 2010 02:20:08 -0800 (PST) Received: by fxm3 with SMTP id 3so3492367fxm.31 for ; Sat, 20 Nov 2010 02:20:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.71.201 with SMTP id i9mr1865787faj.89.1290248455397; Sat, 20 Nov 2010 02:20:55 -0800 (PST) Received: by 10.223.70.198 with HTTP; Sat, 20 Nov 2010 02:20:55 -0800 (PST) Date: Sat, 20 Nov 2010 04:20:55 -0600 Message-ID: From: Peter Bigot To: core Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [core] Asynchronous Response Correlation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Nov 2010 10:20:16 -0000 I don't believe there is consensus on this issue, but the discussion in various threads has stopped.=A0 I don't want this to remain in limbo until time pressures result in an ad hoc solution in the final document. I propose that Token be the sole technique used in CoAP to correlate asynchronous responses with original requests.=A0 This should hold for all methods, and regardless of the number of responses transmitted (subscriptions or other situations). - As a "REST-level" equivalent to the transaction-level TID, uniform =A0 application of this simple rule repeats an existing practice, decreasin= g =A0 the conceptual complexity of the system - Token permits the client to control whether the server may use =A0 asynchronous responses, a feature that may be required for severely =A0 constrained devices or specific applications The only alternative to this I've seen proposed is to use URI correlation b= y providing URI-related options in the response message.=A0 I ask the propone= nts of this to: - Define clearly the steps involved in URI correlation, including which options are involved and whether the comparison is as opaque octet sequences or semantically-equivalent representations - Provide a compelling use case where URI correlation is superior to Token =A0 correlation - Specify whether they wish URI correlation to be the sole technique for =A0 asynchronous response correlation, or whether it should co-exist with =A0 Token correlation - Describe how the client may control use of asynchronous responses with =A0 this technique, or provide an argument why such control is unnecessary Without such a response, we either do not have consensus, or we can assume that consensus is to use Token uniformly. Peter From cabo@tzi.org Sat Nov 20 22:46:21 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B50693A6A47 for ; Sat, 20 Nov 2010 22:46:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VT1nXsx04gFJ for ; Sat, 20 Nov 2010 22:46:12 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 1D5373A6A43 for ; Sat, 20 Nov 2010 22:46:08 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id oAL6ksDV026391; Sun, 21 Nov 2010 07:46:54 +0100 (CET) Received: from [192.168.217.101] (p5489D2C7.dip.t-dialin.net [84.137.210.199]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id F404450; Sun, 21 Nov 2010 07:46:53 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Sun, 21 Nov 2010 07:46:53 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8AB09D60-C571-4059-B065-B99EF3E2199E@tzi.org> References: To: Peter Bigot X-Mailer: Apple Mail (2.1082) Cc: core Subject: Re: [core] Asynchronous Response Correlation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 06:46:21 -0000 On Nov 20, 2010, at 11:20, Peter Bigot wrote: > use Token uniformly Well, the problem is that Token is an option. At the last plugfest we were reminded that implementations that require = a certain option are the road to interoperability failure, e.g.: Implementation A happens to not send tokens, as it wants to send minimum = size packets. Implementation B happens to require tokens, as it might want to send = asynchronous (delayed) responses. The approach to try without Token and then add one in a second request = after failure adds significant complexity to the state machine. So what you are proposing makes Token kind of mandatory for every = request if you want interoperability. Indeed, we have no good way to correlate PUT/POST/DELETE delayed = responses without a Token, so making them required there appears = reasonable. Not so sure about GET. Yes, we have to write up the correlation rule, = but it should be simpler than a "try without Token and then try again = with Token" state machine. Gruesse, Carsten From trac@tools.ietf.org Sat Nov 20 23:07:54 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2FD73A6A45 for ; Sat, 20 Nov 2010 23:07:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UYaNt1g5GWAQ for ; Sat, 20 Nov 2010 23:07:52 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 820203A6967 for ; Sat, 20 Nov 2010 23:07:51 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PK42S-0005xn-8A; Sat, 20 Nov 2010 23:08:40 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: cabo@tzi.org, zach@sensinode.com X-Trac-Project: core Date: Sun, 21 Nov 2010 07:08:39 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/55#comment:2 Message-ID: <066.eb1f365d85e4c3a9535e2e51dca9266d@tools.ietf.org> References: <057.cbcb8082fb49a1a254def976b454a663@tools.ietf.org> X-Trac-Ticket-ID: 55 In-Reply-To: <057.cbcb8082fb49a1a254def976b454a663@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: cabo@tzi.org, zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] coap #55 (new): AES-CCM vs. AES-CBC X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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 Nov 2010 07:07:54 -0000 #55: AES-CCM vs. AES-CBC Old description: > As AES-CCM is more suitabe to most low-power RF chips such as 802.15.4, > Section 10 should consider cypher suites that make use of it intead of > AES-CBC. New description: As AES-CCM is more suitable to most low-power RF chips such as 802.15.4, Section 10 should consider cipher suites that make use of it instead of AES-CBC. -- Comment(by cabo@…): We probably should be referencing (informative): Cipher suites: * I-D.mcgrew-tls-aes-ccm * I-D.mcgrew-tls-aes-ccm-ecc DTLS 1.2: * I-D.ietf-tls-rfc4347-bis The latter is now in "Publication requested state". Still, it is not a normative reference as the use of DTLS is not a "MUST implement". (Also, I think many other references currently specified as normative aren't.) (and s/cypher/cipher/g) -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: Type: enhancement | Status: new Priority: trivial | Milestone: Component: coap | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From cabo@tzi.org Sun Nov 21 00:16:06 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAE623A6A5F for ; Sun, 21 Nov 2010 00:16:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MU5cbOWy8dgg for ; Sun, 21 Nov 2010 00:16:04 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 52A4B3A6A5B for ; Sun, 21 Nov 2010 00:16:04 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id oAL8GnlC015701 for ; Sun, 21 Nov 2010 09:16:50 +0100 (CET) Received: from [192.168.217.101] (p5489D2C7.dip.t-dialin.net [84.137.210.199]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 914D953; Sun, 21 Nov 2010 09:16:49 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 21 Nov 2010 09:16:48 +0100 To: "Constrained RESTful Environments WG" Message-Id: <7925360F-9E9E-41F8-8053-9AF6F244C7A9@tzi.org> Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [core] CoRE WG webex call on Nov 24, 1500 UTC X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 08:16:06 -0000 This is a reminder that our next WG webex call is this Wednesday, Nov = 24. As we decided to stick with a constant UTC time despite various DST = switches, the time for the call is: 0700 PST =3D 1000 EST =3D 1500 UTC =3D 1600 CET =3D=20 1700 EET =3D 2300 China =3D 2400 Japan/Korea I expect us to spend most of the time on the open tickets (we have now = and we might create until then) on the WG documents. Where possible, = I'd like the authors to append proposed resolutions to the tickets, so = we can quickly tick off those tickets where we have agreement. Do we have any other contributions we should discuss on Wednesday? Gruesse, Carsten From cabo@tzi.org Sun Nov 21 00:22:00 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 067943A6A5F for ; Sun, 21 Nov 2010 00:22:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.248 X-Spam-Level: X-Spam-Status: No, score=-107.248 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_INVITATION=-2, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eraf12smDcLU for ; Sun, 21 Nov 2010 00:21:58 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 224F23A6A63 for ; Sun, 21 Nov 2010 00:21:57 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id oAL8Mg9f017327 for ; Sun, 21 Nov 2010 09:22:42 +0100 (CET) Received: from [192.168.217.101] (p5489D2C7.dip.t-dialin.net [84.137.210.199]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 54EAF54; Sun, 21 Nov 2010 09:22:42 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-4-635432221 From: Carsten Bormann X-Priority: 3 Date: Sun, 21 Nov 2010 09:22:41 +0100 Message-Id: References: <246702410.1288294444998.JavaMail.nobody@jsj2wl013.webex.com> To: Constrained RESTful Environments WG X-Mailer: Apple Mail (2.1082) Subject: [core] Fwd: Meeting invitation: CORE WG Interim X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 08:22:00 -0000 --Apple-Mail-4-635432221 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii ...and here is the (recurring) Webex information for the next three = calls. (Note that, contrary to the calendaring information below, we do NOT = currently plan to make use of the phone call slot on Dec 29th.) Gruesse, Carsten Begin forwarded message: > From: IETF Secretariat > Date: October 28, 2010 21:34:05 +0200 > To: cabo@tzi.org > Subject: Meeting invitation: CORE WG Interim > Reply-To: amorris@amsl.com >=20 >=20 > Hello ,=20 >=20 > IETF Secretariat invites you to attend this online meeting.=20 >=20 > Topic: CORE WG Interim=20 > Date: The 4th Wednesday of every 1 months, from Wednesday, November = 24, 2010 to Wednesday, February 23, 2011=20 > Time: 7:00 am, Pacific Standard Time (San Francisco, GMT-08:00)=20 > Meeting Number: 968 779 888=20 > Meeting Password: (This meeting does not require a password.)=20 >=20 >=20 > -------------------------------------------------------=20 > To join the online meeting (Now from the Apple iPhone (R) too!)=20 > -------------------------------------------------------=20 > 1. Go to = https://workgreen.webex.com/workgreen/j.php?ED=3D148478702&UID=3D119101834= 2&RT=3DMiM0=20 > 2. If requested, enter your name and email address.=20 > 3. If a password is required, enter the meeting password: (This = meeting does not require a password.)=20 > 4. Click "Join".=20 >=20 > To view in other time zones or languages, please click the link:=20 > = https://workgreen.webex.com/workgreen/j.php?ED=3D148478702&UID=3D119101834= 2&ORT=3DMiM0=20 >=20 > -------------------------------------------------------=20 > To join the audio conference only=20 > -------------------------------------------------------=20 > To receive a call back, provide your phone number when you join the = meeting, or call the number below and enter the access code.=20 > Call-in toll number (US/Canada): 1-408-792-6300=20 > Global call-in numbers: = https://workgreen.webex.com/workgreen/globalcallin.php?serviceType=3DMC&ED= =3D148478702&tollFree=3D0=20 >=20 > Access code:968 779 888=20 >=20 > -------------------------------------------------------=20 > For assistance=20 > -------------------------------------------------------=20 > 1. Go to https://workgreen.webex.com/workgreen/mc=20 > 2. On the left navigation bar, click "Support".=20 >=20 > You can contact me at:=20 > amorris@amsl.com=20 > 1-510-492-4081=20 >=20 > To add this meeting to your calendar program (for example Microsoft = Outlook), click this link:=20 > = https://workgreen.webex.com/workgreen/j.php?ED=3D148478702&UID=3D119101834= 2&ICS=3DMI&LD=3D1&RD=3D2&ST=3D1&SHA2=3DveNIkert46u3Z39RM7KdaRRpdk2jFD7u36h= OBg9YwdM=3D&RT=3DMiM0=20 >=20 > The playback of UCF (Universal Communications Format) rich media files = requires appropriate players. To view this type of rich media files in = the meeting, please check whether you have the players installed on your = computer by going to = https://workgreen.webex.com/workgreen/systemdiagnosis.php=20 >=20 > Sign up for a free trial of WebEx=20 > http://www.webex.com/go/mcemfreetrial=20 >=20 > http://www.webex.com=20 >=20 >=20 >=20 > IMPORTANT NOTICE: This WebEx service includes a feature that allows = audio and any documents and other materials exchanged or viewed during = the session to be recorded. By joining this session, you automatically = consent to such recordings. If you do not consent to the recording, = discuss your concerns with the meeting host prior to the start of the = recording or do not join the session. Please note that any such = recordings may be subject to discovery in the event of litigation.=20 --Apple-Mail-4-635432221 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

    From: IETF Secretariat = <messenger@webex.com>
    =
    Date: October 28, 2010 = 21:34:05 +0200
    Subject: Meeting = invitation: CORE WG Interim

    =
    Hello ,

    IETF Secretariat invites you to attend = this online meeting.

    Topic: CORE WG Interim
    Date: The 4th = Wednesday of every 1 months, from Wednesday, November 24, 2010 to = Wednesday, February 23, 2011
    Time: 7:00 am, Pacific Standard Time = (San Francisco, GMT-08:00)
    Meeting Number: 968 779 888
    Meeting = Password: (This meeting does not require a password.)


    = -------------------------------------------------------
    To join the = online meeting (Now from the Apple iPhone (R) too!)
    = -------------------------------------------------------
    1. Go to https://workgreen.webex.com/workgreen/j.php?ED=3D1484787= 02&UID=3D1191018342&RT=3DMiM0
    2. If requested, enter = your name and email address.
    3. If a password is required, enter = the meeting password: (This meeting does not require a password.)
    = 4. Click "Join".

    To view in other time zones or languages, = please click the link:
    https://workgreen.webex.com/workgreen/j.php?ED=3D1484787= 02&UID=3D1191018342&ORT=3DMiM0

    = -------------------------------------------------------
    To join the = audio conference only
    = -------------------------------------------------------
    To receive = a call back, provide your phone number when you join the meeting, or = call the number below and enter the access code.
    Call-in toll = number (US/Canada): 1-408-792-6300
    Global call-in numbers: https://workgreen.webex.com/workgreen/globalcallin.php?s= erviceType=3DMC&ED=3D148478702&tollFree=3D0

    Access = code:968 779 888

    = -------------------------------------------------------
    For = assistance
    ------------------------------------------------------- =
    1. Go to https://workgreen.webex.com/workgreen/mc
    2. = On the left navigation bar, click "Support".

    You can contact = me at:
    amorris@amsl.com =
    1-510-492-4081

    To add this meeting to your calendar = program (for example Microsoft Outlook), click this link:
    https://workgreen.webex.com/workgreen/j.php?ED=3D1484787= 02&UID=3D1191018342&ICS=3DMI&LD=3D1&RD=3D2&ST=3D1&= SHA2=3DveNIkert46u3Z39RM7KdaRRpdk2jFD7u36hOBg9YwdM=3D&RT=3DMiM0 =

    The playback of UCF (Universal Communications Format) rich = media files requires appropriate players. To view this type of rich = media files in the meeting, please check whether you have the players = installed on your computer by going to https://workgreen.webex.com/workgreen/systemdiagnosis.ph= p

    Sign up for a free trial of WebEx
    http://www.webex.com/go/mcemfreetrial

    http://www.webex.com =



    IMPORTANT NOTICE: This WebEx service includes a = feature that allows audio and any documents and other materials = exchanged or viewed during the session to be recorded. By joining this = session, you automatically consent to such recordings. If you do not = consent to the recording, discuss your concerns with the meeting host = prior to the start of the recording or do not join the session. Please = note that any such recordings may be subject to discovery in the event = of litigation.

    = --Apple-Mail-4-635432221-- From trac@tools.ietf.org Sun Nov 21 00:41:42 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF11E3A6A6A for ; Sun, 21 Nov 2010 00:41:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B4JgvpuEvEI2 for ; Sun, 21 Nov 2010 00:41:41 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id C421E3A6A69 for ; Sun, 21 Nov 2010 00:41:41 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PK5VJ-0005iA-0D; Sun, 21 Nov 2010 00:42:33 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: cabo@tzi.org, zach@sensinode.com X-Trac-Project: core Date: Sun, 21 Nov 2010 08:42:32 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/core/trac/ticket/55#comment:3 Message-ID: <066.34c8fead60f7ba790f916b74f04e04ab@tools.ietf.org> References: <057.cbcb8082fb49a1a254def976b454a663@tools.ietf.org> X-Trac-Ticket-ID: 55 In-Reply-To: <057.cbcb8082fb49a1a254def976b454a663@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: cabo@tzi.org, zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] coap #55 (new): AES-CCM vs. AES-CBC X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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 Nov 2010 08:41:42 -0000 #55: AES-CCM vs. AES-CBC Comment(by cabo@…): Re IPsec, add a brief discussion (expanding the existing reference to section 9 of RFC 4309) about the requirements AES-CCM places on key establishment (i.e., the traditional manual keying approach does not work vert well here). More generally speaking, this text about key establishment should also point out that anti-replay requires a protocol to manage keys and sequence numbers. (the above are channeling comments by Eric Rescorla in http://www.ietf.org /mail-archive/web/core/current/msg01061.html which discusses this in more detail and also contains text from RFC 4303 that we might use.) If Tero Kivinen's lightweight IKE draft becomes available in time; add a reference to that (as relevant work in progress). -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: Type: enhancement | Status: new Priority: trivial | Milestone: Component: coap | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From pab@peoplepowerco.com Sun Nov 21 05:18:54 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9B9F28B56A for ; Sun, 21 Nov 2010 05:18:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.676 X-Spam-Level: X-Spam-Status: No, score=-1.676 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_84=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id egNRasfYAgyD for ; Sun, 21 Nov 2010 05:18:53 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 5EDB83A6AA6 for ; Sun, 21 Nov 2010 05:18:53 -0800 (PST) Received: by fxm3 with SMTP id 3so4044576fxm.31 for ; Sun, 21 Nov 2010 05:19:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.106.210 with SMTP id y18mr2697333fao.108.1290345585936; Sun, 21 Nov 2010 05:19:45 -0800 (PST) Received: by 10.223.70.198 with HTTP; Sun, 21 Nov 2010 05:19:45 -0800 (PST) In-Reply-To: <8AB09D60-C571-4059-B065-B99EF3E2199E@tzi.org> References: <8AB09D60-C571-4059-B065-B99EF3E2199E@tzi.org> Date: Sun, 21 Nov 2010 07:19:45 -0600 Message-ID: From: Peter Bigot To: Carsten Bormann Content-Type: multipart/alternative; boundary=0016e68e928949899404958ffe99 Cc: core Subject: Re: [core] Asynchronous Response Correlation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 13:18:54 -0000 --0016e68e928949899404958ffe99 Content-Type: text/plain; charset=ISO-8859-1 > > On Sun, Nov 21, 2010 at 12:46 AM, Carsten Bormann wrote: > On Nov 20, 2010, at 11:20, Peter Bigot wrote: > > > use Token uniformly > > Well, the problem is that Token is an option. > Well, complexity has to go somewhere, especially if applications/implementations choose to optimize different things. It seems you're considering adding the complexity for this specific case to the protocol, affecting all implementations, rather than leaving it to the implementations that make those incompatible choices. I personally don't see why: Lookup original request for synchronous reponse If response.code == TOKEN_REQUIRED: request.includeToken = TRUE request.transmit() return adds a lot of state machine complexity to a client implementation that supports asynchronous responses, but of course the details are going to be specific to the implementation. It does increase response delay, on at least one REST transaction, but it should be up to the implementation whether (a) increasing request message size by two bytes or (b) increasing the code size to support retransmits and accepting the increased latency is less desirable. At any rate, my gut instinct is that URI correlation is not nearly as easy as you believe. Somebody needs to write it up and post it here for discussion so we can find out. I absolutely don't believe the code space required to support it will be less than the code space to recognize a TOKEN_REQUIRED response and invoke transmit again. I also think it's a bad idea to remove the mechanism by which clients can influence the server's decision to use or not use asynchronous responses, i.e. presence or absence of Token in the request. - If the client doesn't send Token because wants minimum-sized packets, it's rather rude of the server to unilaterally decide to send asynchronous responses that have the whole URI encapsulated. Perhaps the client knew that the response message would be too big if the URI was included. - I don't recall that there's a requirement that clients support asynchronous responses. Without the ability to influence the server, such a client cannot communicate with a cooperative server that would make an effort to return the response synchronously if the client is not async-capable. That's why I also asked for an alternative solution to the influence problem, or an argument that it's not important. Thanks for replying. Clearly we do not have consensus, and I look forward to responses to my request so we can resolve this. I am strongly opposed to a protocol for constrained devices that solves the same problem in two incompatible ways. If Token is going to be the solution for non-GET methods, there needs to be a really compelling reason why an additional mechanism should be added for GET. Peter --0016e68e928949899404958ffe99 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    On Sun, Nov 21, 2= 010 at 12:46 AM, Carsten Bormann <cabo@tzi.org> wrote:
    On Nov 20, 2010, at 11:20, Peter Bigot wrote:

    > use Token uniformly

    Well, the problem is that Token is an option.

    Well, complexity has to go somewhere, especially if applications/implem= entations choose to optimize different things.=A0 It seems you're consi= dering adding the complexity for this specific case to the protocol, affect= ing all implementations, rather than leaving it to the implementations that= make those incompatible choices.

    I personally don't see why:

    Lookup original request for sync= hronous reponse
    If response.code =3D=3D TOKEN_REQUIRED:
    =A0=A0 reques= t.includeToken =3D TRUE
    =A0=A0 request.transmit()
    =A0=A0 return
    adds a lot of state machine complexity to a client implementation that su= pports asynchronous responses, but of course the details are going to be sp= ecific to the implementation.=A0 It does increase response delay, on at lea= st one REST transaction, but it should be up to the implementation whether = (a) increasing request message size by two bytes or (b) increasing the code= size to support retransmits and accepting the increased latency is less de= sirable.

    At any rate, my gut instinct is that URI correlation is not nearly as e= asy as you believe.=A0 Somebody needs to write it up and post it here for d= iscussion so we can find out.=A0 I absolutely don't believe the code sp= ace required to support it will be less than the code space to recognize a = TOKEN_REQUIRED response and invoke transmit again.

    I also think it's a bad idea to remove the mechanism by which clien= ts can=20 influence the server's decision to use or not use asynchronous=20 responses, i.e. presence or absence of Token in the request.
    • If = the client doesn't send Token because wants minimum-sized packets, it&#= 39;s rather rude of the server to unilaterally decide to send asynchronous = responses that have the whole URI encapsulated. Perhaps the client knew tha= t the response message would be too big if the URI was included.
    • I don't recall that there's a requirement that cl= ients support asynchronous responses.=A0 Without the ability to influence t= he server, such a client cannot communicate with a cooperative server that = would make an effort to return the response synchronously if the client is = not async-capable.
    That's why I also asked for an alternative solution to the in= fluence=20 problem, or an argument that it's not important.

    Thanks for repl= ying.=A0 Clearly we do not have consensus, and I look forward to responses = to my request so we can resolve this.=A0 I am strongly opposed to a protoco= l for constrained devices that solves the same problem in two incompatible = ways.=A0 If Token is going to be the solution for non-GET methods, there ne= eds to be a really compelling reason why an additional mechanism should be = added for GET.

    Peter

    --0016e68e928949899404958ffe99-- From pab@peoplepowerco.com Sun Nov 21 08:54:20 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C12433A69E0 for ; Sun, 21 Nov 2010 08:54:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.956 X-Spam-Level: X-Spam-Status: No, score=-1.956 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55Xt8d0Xao+S for ; Sun, 21 Nov 2010 08:54:19 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id BC60D3A6836 for ; Sun, 21 Nov 2010 08:54:18 -0800 (PST) Received: by fxm3 with SMTP id 3so4132351fxm.31 for ; Sun, 21 Nov 2010 08:55:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.104.68 with SMTP id n4mr1533599fao.127.1290358510148; Sun, 21 Nov 2010 08:55:10 -0800 (PST) Received: by 10.223.70.198 with HTTP; Sun, 21 Nov 2010 08:55:10 -0800 (PST) Date: Sun, 21 Nov 2010 10:55:10 -0600 Message-ID: From: Peter Bigot To: core , mnot@mnot.net Content-Type: multipart/alternative; boundary=001636c9239ea15d6a049593001e Subject: [core] Link Format document X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 16:54:20 -0000 --001636c9239ea15d6a049593001e Content-Type: text/plain; charset=ISO-8859-1 Either at the IETF session or in some email I can't easily find, there was a specific question raised about exactly how the link description is supposed to be used in CoAP that started me down a path that led to the following comment. I've cc'd Mark Nottingham, author of RFC5988 "Web Linking", in hopes he might have time to provide relevant information to guide us. My understanding of RFC5988 is it proposes a way to provide, in an HTTP response header, information about (target) resources that are related in (rel) some way to the (context) resource identified in the original request. Other contexts can be specified through the anchor parameter, but I expect this is unusual. In CoAP's link format document at http://tools.ietf.org/html/draft-ietf-core-link-format, we are rather mis-using this to provide a list of resources that are hosted on a server. Technically, the context of the list items is the resource which is the server itself ("coap://authority"), though we provide access to it at "coap://authority/.well-known/core". The problem is that, because the document containing links lists the resources available on the server, we provide additional information about specific resources in link parameters, rather than as link descriptions. I now think that the roles served by the "d" and "sh" extensions, and some uses of "n", should really be link descriptions whose context is the target, target is the extension value, and rel is the extension name. For example, rather than: n="http://sweet.jpl.nasa.gov/2.0/phys.owl#Temperature ",sh="/l"; being one of the link descriptions at coap://authority/.well-known/core, use consistent with RFC5988 would be to provide: rel="describedby"; rel="alternate"; as the set of link descriptions for coap://authority/sensors/temperature. Based on this perspective, and despite the fact that I've been added as an author due to my contributions to disambiguating the syntax, I don't think that CoRE Link Format describes a conceptually clean solution to this problem that is compatible with what link descriptions mean in RFC5988. I believe a conceptually clean and compatible solution would be to have coap://authority/.well-known/core return a list of links like: rel="hosts"; rel="hosts"; to indicate that these are resources hosted on the server. Further, define that coap://authority/.well-known/core/ provides a link description document for context coap://authority/. For example, coap://authority/.well-known/core/sensors/temperature would return: rel="describedby"; rel="alternate"; Thus providing in a single document the same sort of thing that would be provided by a set of Link headers in an HTTP request to the context URI. Note that what I called "further" is really the only case: returning the list of hosted resources falls out as a consequence of applying this rule with an empty . Very simple, very orthogonal, only difference from HTTP is the URI used to obtain the link descriptions and their encoding as a document rather than as header Link fields. (I can't tell from RFC5988 what the "index" relation is intended to do, so perhaps it could be used instead of the newly created "hosts" relation.) I don't propose that CoAP actually implement this change, since I don't think such a proposal would be accepted due to non-technical pressures. But I did feel it necessary to raise the possibility, and to ask for an outside perspective so we don't end up sending IESG something that's completely at odds with how the concept we're borrowing is understood and used by the rest of the Internet community. Peter --001636c9239ea15d6a049593001e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Either at the IETF session or in some email I can't easily find, there = was a specific question raised about exactly how the link description is su= pposed to be used in CoAP that started me down a path that led to the follo= wing comment.=A0 I've cc'd Mark Nottingham, author of RFC5988 "= ;Web Linking", in hopes he might have time to provide relevant informa= tion to guide us.

    My understanding of RFC5988 is it proposes a way to provide, in an HTTP= response header, information about (target) resources that are related in = (rel) some way to the (context) resource identified in the original request= .=A0 Other contexts can be specified through the anchor parameter, but I ex= pect this is unusual.

    In CoAP's link format document at http://tools.ietf.org/html/draft-ietf-cor= e-link-format, we are rather mis-using this to provide a list of resour= ces that are hosted on a server.=A0 Technically, the context of the list it= ems is the resource which is the server itself ("coap://authority"= ;), though we provide access to it at "coap://authority/.well-known/co= re".

    The problem is that, because the document containing links lists the re= sources available on the server, we provide additional information about sp= ecific resources in link parameters, rather than as link descriptions.=A0 I= now think that the roles served by the "d" and "sh" ex= tensions, and some uses of "n", should really be link description= s whose context is the target, target is the extension value, and rel is th= e extension name.=A0 For example, rather than:

    <sensors/temperature>n=3D"http://sweet.jpl.nasa.gov/2.0/phys.owl#Tempera= ture",sh=3D"/l";

    being one of the link descriptio= ns at coap://authority/.well-known/core, use consistent with RFC5988 would = be to provide:

    <http= ://sweet.jpl.nasa.gov/2.0/phys.owl#Temperature>rel=3D"described= by";
    </l>rel=3D"alternate";

    as the set of li= nk descriptions for coap://authority/sensors/temperature.

    Based on this perspective, and despite the fact that I've been adde= d as an author due to my contributions to disambiguating the syntax, I don&= #39;t think that CoRE Link Format describes a conceptually clean solution t= o this problem that is compatible with what link descriptions mean in RFC59= 88.

    I believe a conceptually clean and compatible solution would be to have= coap://authority/.well-known/core return a list of links like:

    <= sensors/temperature>rel=3D"hosts";
    <sensors/humidity>= rel=3D"hosts";

    to indicate that these are resources hosted on the server.

    Furth= er, define that coap://authority/.well-known/core/<somepath> provides= a link description document for context coap://authority/<somepath>.= =A0 For example, coap://authority/.well-known/core/sensors/temperature woul= d return:

    <http= ://sweet.jpl.nasa.gov/2.0/phys.owl#Temperature>rel=3D"described= by";
    </l>rel=3D"alternate";

    Thus providing i= n a single document the same sort of thing that would be provided by a set = of Link headers in an HTTP request to the context URI.=A0 Note that what I = called "further" is really the only case: returning the list of h= osted resources falls out as a consequence of applying this rule with an em= pty <somepath>.=A0 Very simple, very orthogonal, only difference from= HTTP is the URI used to obtain the link descriptions and their encoding as= a document rather than as header Link fields.

    (I can't tell from RFC5988 what the "index" relation is i= ntended to do, so perhaps it could be used instead of the newly created &qu= ot;hosts" relation.)

    I don't propose that CoAP actually imp= lement this change, since I don't think such a proposal would be accept= ed due to non-technical pressures.=A0 But I did feel it necessary to raise = the possibility, and to ask for an outside perspective so we don't end = up sending IESG something that's completely at odds with how the concep= t we're borrowing is understood and used by the rest of the Internet co= mmunity.

    Peter
    --001636c9239ea15d6a049593001e-- From trac@tools.ietf.org Sun Nov 21 13:10:50 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDAC33A6AAE for ; Sun, 21 Nov 2010 13:10:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89FKMclcRrh0 for ; Sun, 21 Nov 2010 13:10:46 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 87AB63A6A0E for ; Sun, 21 Nov 2010 13:10:46 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PKHC9-0005lF-88; Sun, 21 Nov 2010 13:11:33 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com, hartke@tzi.org X-Trac-Project: core Date: Sun, 21 Nov 2010 21:11:32 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/71 Message-ID: <053.57a7428f32de33ba4221270bca8ca168@tools.ietf.org> X-Trac-Ticket-ID: 71 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, hartke@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] coap #71 (new): Terminology section X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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 Nov 2010 21:10:50 -0000 #71: Terminology section A terminology section needs to be written. -- ----------------------------+----------------------------------------------- Reporter: hartke@… | Owner: zach@… Type: enhancement | Status: new Priority: minor | Milestone: Component: coap | Version: Severity: - | Keywords: ----------------------------+----------------------------------------------- Ticket URL: core From trac@tools.ietf.org Sun Nov 21 13:11:41 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E1133A6A0F for ; Sun, 21 Nov 2010 13:11:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4v6-OuVW0tB3 for ; Sun, 21 Nov 2010 13:11:39 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 1C6FA3A6A0E for ; Sun, 21 Nov 2010 13:11:38 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PKHD5-0007J0-62; Sun, 21 Nov 2010 13:12:31 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com, hartke@tzi.org X-Trac-Project: core Date: Sun, 21 Nov 2010 21:12:31 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/72 Message-ID: <053.639894f29bddd032e710ff634d4068d3@tools.ietf.org> X-Trac-Ticket-ID: 72 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, hartke@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] coap #72 (new): Proxy versus Gateway X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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 Nov 2010 21:11:41 -0000 #72: Proxy versus Gateway The current terminology used in the draft about intermediary nodes doesn't differentiate between proxies and gateways. ([http://www.ietf.org/mail- archive/web/core/current/msg00862.html Proxy versus Gateway]) -- ----------------------------+----------------------------------------------- Reporter: hartke@… | Owner: zach@… Type: task | Status: new Priority: minor | Milestone: Component: coap | Version: Severity: - | Keywords: ----------------------------+----------------------------------------------- Ticket URL: core From trac@tools.ietf.org Sun Nov 21 13:12:39 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 292553A6A0E for ; Sun, 21 Nov 2010 13:12:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRniGvYeAYX3 for ; Sun, 21 Nov 2010 13:12:38 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 3AB6A3A68D0 for ; Sun, 21 Nov 2010 13:12:38 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PKHE3-0007b1-Kh; Sun, 21 Nov 2010 13:13:31 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com, hartke@tzi.org X-Trac-Project: core Date: Sun, 21 Nov 2010 21:13:31 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/73 Message-ID: <053.1163754bc120a3c150f5dfe921422222@tools.ietf.org> X-Trac-Ticket-ID: 73 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, hartke@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] coap #73 (new): Immediate/deferred responses X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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 Nov 2010 21:12:39 -0000 #73: Immediate/deferred responses This ticket is to remove any references to "synchronous" or "asynchronous" responses and replace them with "immediate" and "deferred" responses respectively. -- ----------------------------+----------------------------------------------- Reporter: hartke@… | Owner: zach@… Type: task | Status: new Priority: minor | Milestone: Component: coap | Version: Severity: - | Keywords: ----------------------------+----------------------------------------------- Ticket URL: core From trac@tools.ietf.org Sun Nov 21 13:13:19 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE4A33A6AAE for ; Sun, 21 Nov 2010 13:13:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.208 X-Spam-Level: X-Spam-Status: No, score=-102.208 tagged_above=-999 required=5 tests=[AWL=-0.392, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_SUB_NEED_REPLY=0.784, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKJLV9HZ1EkZ for ; Sun, 21 Nov 2010 13:13:18 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 889BF3A6A0F for ; Sun, 21 Nov 2010 13:13:18 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PKHEh-0007cC-2L; Sun, 21 Nov 2010 13:14:11 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com, hartke@tzi.org X-Trac-Project: core Date: Sun, 21 Nov 2010 21:14:11 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/74 Message-ID: <053.554f6b2288336042158a0f86973c4d2f@tools.ietf.org> X-Trac-Ticket-ID: 74 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, hartke@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] coap #74 (new): Rules for request/response matching X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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 Nov 2010 21:13:19 -0000 #74: Rules for request/response matching This ticket is to add rules for request/response matching * within a transaction; * between request and deferred response. With e.g. DTLS, request and response should be in the same security context. With nosec, there is only the IP address that must match. -- ----------------------------+----------------------------------------------- Reporter: hartke@… | Owner: zach@… Type: enhancement | Status: new Priority: minor | Milestone: Component: coap | Version: Severity: - | Keywords: ----------------------------+----------------------------------------------- Ticket URL: core From trac@tools.ietf.org Sun Nov 21 13:13:47 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2E9C3A6A0F for ; Sun, 21 Nov 2010 13:13:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.595 X-Spam-Level: X-Spam-Status: No, score=-102.595 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JfUCZIenZWTh for ; Sun, 21 Nov 2010 13:13:47 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 42D2B3A68D0 for ; Sun, 21 Nov 2010 13:13:47 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PKHFA-0007dM-LY; Sun, 21 Nov 2010 13:14:40 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com, hartke@tzi.org X-Trac-Project: core Date: Sun, 21 Nov 2010 21:14:40 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/75 Message-ID: <053.310dac6d65b7eb7bd1bd723e299cee6d@tools.ietf.org> X-Trac-Ticket-ID: 75 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, hartke@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] coap #75 (new): Error in Section 3.2.5. X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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 Nov 2010 21:13:47 -0000 #75: Error in Section 3.2.5. Section 3.2.5. of coap-03 refers to a 30x response code that doesn't exist. -- ----------------------------+----------------------------------------------- Reporter: hartke@… | Owner: zach@… Type: defect | Status: new Priority: minor | Milestone: Component: coap | Version: Severity: - | Keywords: ----------------------------+----------------------------------------------- Ticket URL: core From trac@tools.ietf.org Sun Nov 21 13:14:21 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3FD33A6A0E for ; Sun, 21 Nov 2010 13:14:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.595 X-Spam-Level: X-Spam-Status: No, score=-102.595 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JOe0jg1V8fvo for ; Sun, 21 Nov 2010 13:14:21 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 055513A68D0 for ; Sun, 21 Nov 2010 13:14:21 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PKHFi-00081p-Fi; Sun, 21 Nov 2010 13:15:14 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com, hartke@tzi.org X-Trac-Project: core Date: Sun, 21 Nov 2010 21:15:14 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/76 Message-ID: <053.48772f16e4210556e31256ce985ef8fc@tools.ietf.org> X-Trac-Ticket-ID: 76 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, hartke@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] coap #76 (new): Media types X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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 Nov 2010 21:14:21 -0000 #76: Media types This ticket is about [http://www.ietf.org/mail- archive/web/core/current/msg01048.html media types in draft-ietf-core- coap]. -- ----------------------------+----------------------------------------------- Reporter: hartke@… | Owner: zach@… Type: defect | Status: new Priority: major | Milestone: Component: coap | Version: Severity: - | Keywords: ----------------------------+----------------------------------------------- Ticket URL: core From trac@tools.ietf.org Sun Nov 21 13:15:17 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85C803A68D0 for ; Sun, 21 Nov 2010 13:15:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.595 X-Spam-Level: X-Spam-Status: No, score=-102.595 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x11lSZ-lGIBI for ; Sun, 21 Nov 2010 13:15:16 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id BB8553A6A0E for ; Sun, 21 Nov 2010 13:15:16 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PKHGX-0000rk-46; Sun, 21 Nov 2010 13:16:06 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com, hartke@tzi.org X-Trac-Project: core Date: Sun, 21 Nov 2010 21:16:05 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/77 Message-ID: <053.9ea9efc3dcb9be1a7f2b477e72d5fadd@tools.ietf.org> X-Trac-Ticket-ID: 77 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, hartke@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] coap #77 (new): Response code semantics X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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 Nov 2010 21:15:17 -0000 #77: Response code semantics The current draft implicitly imports the meaning of response codes from HTTP. This ticket is to make the semantics of the response codes explicit in the draft. -- ----------------------------+----------------------------------------------- Reporter: hartke@… | Owner: zach@… Type: enhancement | Status: new Priority: major | Milestone: Component: coap | Version: Severity: - | Keywords: ----------------------------+----------------------------------------------- Ticket URL: core From trac@tools.ietf.org Sun Nov 21 13:16:22 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B58F3A6AAE for ; Sun, 21 Nov 2010 13:16:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id neK78o3Yl62a for ; Sun, 21 Nov 2010 13:16:21 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 47D5A3A68D0 for ; Sun, 21 Nov 2010 13:16:21 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PKHHd-0002bu-Ih; Sun, 21 Nov 2010 13:17:14 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com, hartke@tzi.org X-Trac-Project: core Date: Sun, 21 Nov 2010 21:17:13 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/78 Message-ID: <053.2a7e2622a76fb227d41b3b95d0d18a8d@tools.ietf.org> X-Trac-Ticket-ID: 78 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, hartke@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] coap #78 (new): Caching semantics X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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 Nov 2010 21:16:22 -0000 #78: Caching semantics The current draft implicitly imports a lot of caching-related rules from HTTP. This ticket is to reference or repeat some caching semantics from 2616. -- ----------------------------+----------------------------------------------- Reporter: hartke@… | Owner: zach@… Type: enhancement | Status: new Priority: major | Milestone: Component: coap | Version: Severity: - | Keywords: ----------------------------+----------------------------------------------- Ticket URL: core From trac@tools.ietf.org Sun Nov 21 13:17:17 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCBF128C0CE for ; Sun, 21 Nov 2010 13:17:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rtu9T-ZGXYBv for ; Sun, 21 Nov 2010 13:17:17 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 0378728C0D8 for ; Sun, 21 Nov 2010 13:17:17 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PKHIY-0004AO-GI; Sun, 21 Nov 2010 13:18:11 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: hartke@tzi.org X-Trac-Project: core Date: Sun, 21 Nov 2010 21:18:10 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/67#comment:1 Message-ID: <062.b2da3d3e4daf60d93bd61502b61d8868@tools.ietf.org> References: <053.741236a6f0f28d5442a1da35fc6ce726@tools.ietf.org> X-Trac-Ticket-ID: 67 In-Reply-To: <053.741236a6f0f28d5442a1da35fc6ce726@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hartke@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] observe #67 (new): Rules for notifications (was: Business rules for notifications) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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 Nov 2010 21:17:17 -0000 #67: Rules for notifications Comment(by hartke@…): It should also be clarified that a server can employ different strategies to achieve the overriding objective w.r.t. sending notifications confirmable or non-confirmable. ([http://www.ietf.org/mail- archive/web/core/current/msg01152.html Non-confirmable vs confirmable notification]) -- ----------------------------+----------------------------------------------- Reporter: hartke@… | Owner: hartke@… Type: enhancement | Status: new Priority: minor | Milestone: Component: observe | Version: Severity: - | Keywords: ----------------------------+----------------------------------------------- Ticket URL: core From trac@tools.ietf.org Sun Nov 21 13:30:39 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3ADA3A6AB2 for ; Sun, 21 Nov 2010 13:30:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jTwlqR-h3OPF for ; Sun, 21 Nov 2010 13:30:39 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 2A7BE3A6915 for ; Sun, 21 Nov 2010 13:30:38 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PKHVV-0002AI-DM; Sun, 21 Nov 2010 13:31:33 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: hartke@tzi.org X-Trac-Project: core Date: Sun, 21 Nov 2010 21:31:33 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/35#comment:1 Message-ID: <066.bb75a951662a0193c2fadba56a9b2694@tools.ietf.org> References: <057.f781103e2e244ce4f30199f4808df127@tools.ietf.org> X-Trac-Ticket-ID: 35 In-Reply-To: <057.f781103e2e244ce4f30199f4808df127@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hartke@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] observe #35 (new): Add discussion on message reordering X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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 Nov 2010 21:30:39 -0000 #35: Add discussion on message reordering Comment(by hartke@…): Since the overriding objective is that observed state observed eventually becomes consistent with the resource state, it is never wrong to discard a notification that arrives later than a newer notification. This ticket proposes to define a simple mechanism for clients to determine if a notification is newer than another. Rules: * The remaining subscription lifetime in a notification MUST be strictly monotonically decreasing. * A client SHOULD use a different Token value each time it refreshes a subscription. The Token functions as a generation identifier, the subscription lifetime as notification identifier within a generation. -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: hartke@… Type: enhancement | Status: new Priority: minor | Milestone: Component: observe | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From trac@tools.ietf.org Sun Nov 21 13:37:44 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CA4E3A6A11 for ; Sun, 21 Nov 2010 13:37:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m2+iG9HwKj9g for ; Sun, 21 Nov 2010 13:37:43 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id CBEF63A6A0D for ; Sun, 21 Nov 2010 13:37:43 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PKHcM-0000k3-C1; Sun, 21 Nov 2010 13:38:38 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: hartke@tzi.org X-Trac-Project: core Date: Sun, 21 Nov 2010 21:38:38 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/68#comment:1 Message-ID: <062.00a41e4efb646687cc5b4c5a7379f4d9@tools.ietf.org> References: <053.e2e32367bc816bfaa499f9c42fd41c7d@tools.ietf.org> X-Trac-Ticket-ID: 68 In-Reply-To: <053.e2e32367bc816bfaa499f9c42fd41c7d@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hartke@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] observe #68 (new): Rules for subscribing (was: Minimum duration between observation requests) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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 Nov 2010 21:37:44 -0000 #68: Rules for subscribing Comment(by hartke@…): This ticket is to add following rules for subscribing an observer to a resource: * A client SHOULD NOT subscribe or refresh a subscription to a resource for the duration specified in the Max-Age option in the last notification after receiving that notification. * A client MAY refresh a subscription before the remaining lifetime ends. -- ----------------------------+----------------------------------------------- Reporter: hartke@… | Owner: hartke@… Type: enhancement | Status: new Priority: minor | Milestone: Component: observe | Version: Severity: - | Keywords: ----------------------------+----------------------------------------------- Ticket URL: core From fluffy@cisco.com Sun Nov 21 13:52:02 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04EAE28C0CF for ; Sun, 21 Nov 2010 13:52:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.573 X-Spam-Level: X-Spam-Status: No, score=-110.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yCDM820vcjSP for ; Sun, 21 Nov 2010 13:52:00 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id C583D3A6AB2 for ; Sun, 21 Nov 2010 13:52:00 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAE8j6UyrR7H+/2dsb2JhbACiWXGhYplmhUsEhFqGBIMO X-IronPort-AV: E=Sophos;i="4.59,232,1288569600"; d="scan'208";a="623733452" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 21 Nov 2010 21:52:55 +0000 Received: from [192.168.4.2] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id oALLqrni014531; Sun, 21 Nov 2010 21:52:54 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4CE38524.60106@isode.com> Date: Sun, 21 Nov 2010 14:53:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1FED2A6E-035E-4772-8B2B-BF5762517B57@cisco.com> References: <4CE38524.60106@isode.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.1082) Cc: core@ietf.org Subject: Re: [core] Review of draft-ietf-core-coap-03.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 21:52:02 -0000 Thanks - good input. Any thoughts on what we should do around security? On Nov 17, 2010, at 12:32 AM, Alexey Melnikov wrote: > Hi, > I've decided to do IESG-type review of the document, as it seems to be = getting close to being done. many of my comments are editorial in = nature. In general I found the document to be well written. >=20 > In Section 1 - the first reference to HTTP needs an Informative = Reference. >=20 > In Section 2.1.2 (Asynchronous response) - the first reference to = "token option" needs a reference (either a cross reference, or an = external reference). >=20 >> 2.5.1. Option Processing >>=20 >> If no options are to be included, the Option Count field is set to = 0 >> below and the Payload (if any) immediately follows the Transaction >> ID. If options are to be included, the following rules apply. The >> number of options is placed in the Option Count field. Each option >> is then placed in order of Type, immediately following the >> Transaction ID with no padding. Upon reception, unknown options of >> class "elective" MUST be silently skipped. Unknown options of = class >> "critical" in a Confirmable MUST cause the return of a response = code >> "Critical Option not supported (CoAP 242)" including a copy of the >> critical option number in the payload of the response. > Does this need a new payload (MIME) type registration? Options don't = seem to be considered to be a part of a payload (assuming my reading of = Sections 3 and 3.1 is correct). Or did you mean that the options need to = be returned as TLVs? >=20 >> 3.2.8. Token Option >>=20 >> This option MUST NOT occur ore than once in a header. > typo: more >=20 >> 5.1. Cache control >> In general, the origin server end-point is responsible for >> determining cache age. However, in some cases a client may wish to >> determine its own tolerance for cache staleness. In this case, a >> client may specify the Max-Age header during a GET request. If the >> client's Max-Age is of a shorter duration than the age of a cached > "than the remaining age"? >> resource, then the proxy or end-point SHOULD perform a cache = refresh. >> If the client specifies a Max-Age of zero seconds, then the = response >> MUST discard the cached representation and return a fresh > In Section 7 - the first references to XMPP and SIP require = Informative References. >=20 >> 7. HTTP Mapping >>=20 >> The caching and proxying of CoAP is specified in Section 5. In a >> similar manner, caching and proxying MAY be performed between CoAP >> and HTTP by an intermediate node. A proxy SHOULD respond with a = 502 >> (Bad Gateway) error to HTTP requests which can not be successfully >> mapped to CoAP. CoAP transaction messages are transparent to >> request/response exchanges and MUST have no affect on a proxy >> function. > I am not entirely sure about the meaning of the last sentence. Can you = clarify? >> 10. Security Considerations >>=20 >> Certificate: The device has an asymmetric key pair with a X.509 >> [RFC5280] certificate that binds it to its Authority Name and is >> signed by a some common trust root. The device also has a list = or >> root trust anchors that can be used for validating a = certificate. >> There may be an optional shared key that all the nodes that >> communicate have access too. >>=20 >> The Authority Name in the certificate is the name that would be = used >> in the Authority part of a CoAP URI. It is worth noting that this >> would typically not be either an IP address or DNS name but would >> instead be a long term unique identifier for the device such as the >> EUI-64. > I think this needs a reference. >> The discovery process used in the system would build up the >> mapping between IP addresses of the given devices and the Authority >> Name for each device. Some devices could have more than one >> Authority and would need more than a single certificate. >=20 >> 10.2. Securing CoAP with DTLS >>=20 >> Devices SHOULD support the Server Name Indication (SNI) to indicate >> their Authority Name in the SNI HostName field as defined in = Section >> 3 of draft-ietf-tls-rfc4366-bis. > That document was approved by IESG, so this needs to be converted to a = proper Normative Reference. >> This is needed so that when a host >> that acts as a virtual server for multiple Authorities receives a = new >> DTLS connection, it knows which keys to use for the DTLS session. >=20 >> 10.2.1. SharedKey & MultiKey Modes >>=20 >> When forming a connection to a new node, the system selects an >> appropriate key based on which nodes it is trying to reach then = forms >> a DTLS session using a PSK (Pre-Shared Key) mode of DTLS. >> Implementations SHOULD support the mandatory to implement cipher > I think this needs to be a MUST, conditional on DTLS being supported = by the node. >> suite TLS_PSK_WITH_AES_128_CBC_SHA as specified in [RFC5246]. >> 10.2.2. Certificate Mode >>=20 >> As with IPsec, DTLS should be configured with a cypher suite >> compatible with any possible hardware engine on the node, for = example >> AES-CBC in the case of IEEE 802.15.4. Implementations SHOULD = support > As above, I think this needs to be a MUST. >> the mandatory to implement cipher suite = TLS_RSA_WITH_AES_128_CBC_SHA >> as specified in [RFC5246]. >=20 >=20 > In Section 11 - IANA registration policy for COAP status codes and = COAP MIME types is not defined. I suggest Expert Review at minimum = (because of code/MIME type space is so small). >=20 > Also, the coap:// URI scheme needs to be registered using the URI = registration template. >=20 > Should COAP methods be registered with IANA together with COAP status = codes (as they are used in the same field)? >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From klaus.hartke@googlemail.com Sun Nov 21 14:38:37 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABF953A6A0F for ; Sun, 21 Nov 2010 14:38:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-SkPlqEDPCz for ; Sun, 21 Nov 2010 14:38:36 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 018D73A68E3 for ; Sun, 21 Nov 2010 14:38:35 -0800 (PST) Received: by bwz12 with SMTP id 12so5977951bwz.31 for ; Sun, 21 Nov 2010 14:39:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=VXc4dg8agKv5XbczZQy8/UyY0EaKV4PSkRb9upkmW7U=; b=ROALnMZwKSIu0PiNe4L+BSo8PwjOh2bGuGwx8CKhldy6JZI43Z4D9UN1p3OFlk//tO YE/QdWr9O9i25nGZQdvbLri6D9hiFZTE+khSecuplRrS8QpiQ0FzHOxwdCo0GznycAYz TiNuYPhk2Xn/wi79qcXSomXn2I8sNrmaM5GbM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; b=gu+FljjxpqnILYdkHQINpAFQlUlhf+rFTQ0tjMfNuIl4MqaSOhg8a46r1hCDi41ujd hauf4wk37AtTpTLgWgHY7e8u/bJ85j4qsV5l094hS6RSXvrhufxz7JeTuRwMtnLEZwY0 ztTi0OsGZh+jyFYlksxVTxmik+01n0xjUN26U= MIME-Version: 1.0 Received: by 10.204.62.139 with SMTP id x11mr4528540bkh.28.1290379169793; Sun, 21 Nov 2010 14:39:29 -0800 (PST) Sender: klaus.hartke@googlemail.com Received: by 10.204.121.134 with HTTP; Sun, 21 Nov 2010 14:39:29 -0800 (PST) Date: Sun, 21 Nov 2010 23:39:29 +0100 X-Google-Sender-Auth: vUM2YdeZRdXXHs8LSdaaRdb42pE Message-ID: From: Klaus Hartke To: core Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [core] When are two requests equivalent? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 22:38:37 -0000 Again, a caching-related issue that is largely an implementation detail, but IMO should have some bits clarified in the draft. Say a client sends a request with a critical option unknown to the server: C: GET coap://server/resource (99=3D0x00) S: 602 (maxage=3D60s) "Unknown critical option 99." Since responses to GET are cacheable, the client caches the response for 60 seconds. From coap-03 section 5.1.: > When a client reads the response from a GET request, it should cache the = resource representation for the cache lifetime as specified by the Max-Age = header. During the cache lifetime, the client SHOULD use its cached version= and avoid performing additional GETs for the resource. Then the client wants to repeat the request without the unknown option. Since it has a cached version of the resource, it avoids performing the GET and ends up with a 602 response. So, what exactly are the rules for determining if a cached response can be used to avoid a GET request? Checking if the cache stores a response for the given URI is not enough. Klaus From ngocthanhdinh@gmail.com Sun Nov 21 17:12:30 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16CB128C0FB for ; Sun, 21 Nov 2010 17:12:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUy0tqiyxFnf for ; Sun, 21 Nov 2010 17:12:29 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 1787B28C104 for ; Sun, 21 Nov 2010 17:12:07 -0800 (PST) Received: by bwz12 with SMTP id 12so6062656bwz.31 for ; Sun, 21 Nov 2010 17:13:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=Azs6WE/TMOQNUxRu0WDPHBxDxM3XavescdX0FfsxnH4=; b=r2fPkkMmhDko1gj/Nsp1Jhd3mgkFrgrzws8rRAKxYdXCaQOrtBC+PtK+lVdCheFO3m WIY+kaiW7vM0yKoM4XWZ7NRuI9FqfRJ5Ha1pm1BgQ6r3/ejKkFijHEGcaEzXHKgSvnR7 SQlpvDYbe+YfzwXk9BPt2ex/4dULLe1SPxP4U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=YjBb0Kn7SauiMwVgQttfwvr9Sk3HN5sc2CuJZs4ILc3PevviUB6nWJCnYHvchnz4+n 5MIyje2yQZ1MYKY74tnNTk8OZMscKW2DLNZXNwS0HxSb9YTtylPEo/eWNWaLFXhUNJyJ xq40hhoMdtyl5/DU9e2CEb4r+UZ8Nd4jnMj2g= MIME-Version: 1.0 Received: by 10.204.152.218 with SMTP id h26mr4637406bkw.196.1290388381131; Sun, 21 Nov 2010 17:13:01 -0800 (PST) Received: by 10.204.52.146 with HTTP; Sun, 21 Nov 2010 17:13:01 -0800 (PST) Date: Mon, 22 Nov 2010 10:13:01 +0900 Message-ID: From: Thanh Ngoc To: core@ietf.org Content-Type: multipart/alternative; boundary=00151750d852146499049599f50b Subject: [core] Help me with CoAP Demo X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 01:12:30 -0000 --00151750d852146499049599f50b Content-Type: text/plain; charset=ISO-8859-1 Dear evey one, now i am starting with CoAP and have to make a demo. do you know where i should start ? and does it have any demo is available for CoAP (in tinyos or contiki). could you give me some guide for CoAP Demo? thank you very much, Ngoc Thanh --00151750d852146499049599f50b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear evey one,

    now i am starting with CoAP and have to make a demo.<= br>
    do you know where i should start ? and does it have any demo is avai= lable for CoAP (in tinyos or contiki).

    could you give me some guide = for CoAP Demo?

    thank you very much,


    =A0=A0=A0=A0=A0=A0=A0 Ngoc Thanh
    --00151750d852146499049599f50b-- From mnot@mnot.net Sun Nov 21 19:47:22 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 363313A69FA for ; Sun, 21 Nov 2010 19:47:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.875 X-Spam-Level: X-Spam-Status: No, score=-104.875 tagged_above=-999 required=5 tests=[AWL=-2.276, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id frBhKL-nCUdB for ; Sun, 21 Nov 2010 19:47:20 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by core3.amsl.com (Postfix) with ESMTP id AC14E3A68FE for ; Sun, 21 Nov 2010 19:47:20 -0800 (PST) Received: from chancetrain-lm.mnot.net (unknown [118.209.2.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id CDE6F22E254; Sun, 21 Nov 2010 22:48:08 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: Date: Mon, 22 Nov 2010 14:48:05 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <06B60978-B13D-4B4F-A96F-106020A571A5@mnot.net> References: To: Peter Bigot X-Mailer: Apple Mail (2.1082) X-Mailman-Approved-At: Sun, 21 Nov 2010 20:18:58 -0800 Cc: core Subject: Re: [core] Link Format document X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 03:47:22 -0000 Peter, I haven't dug into that part of CoAP, so please take my response with a = grain of salt.=20 Having said that, I've been uncomfortable with those extensions for a = while, but didn't have the time to figure out why. If what you're saying = is the case, I'd generally agree that there are more compatible ways to = do this. Regards, On 22/11/2010, at 3:55 AM, Peter Bigot wrote: > Either at the IETF session or in some email I can't easily find, there = was a specific question raised about exactly how the link description is = supposed to be used in CoAP that started me down a path that led to the = following comment. I've cc'd Mark Nottingham, author of RFC5988 "Web = Linking", in hopes he might have time to provide relevant information to = guide us. >=20 > My understanding of RFC5988 is it proposes a way to provide, in an = HTTP response header, information about (target) resources that are = related in (rel) some way to the (context) resource identified in the = original request. Other contexts can be specified through the anchor = parameter, but I expect this is unusual. >=20 > In CoAP's link format document at = http://tools.ietf.org/html/draft-ietf-core-link-format, we are rather = mis-using this to provide a list of resources that are hosted on a = server. Technically, the context of the list items is the resource = which is the server itself ("coap://authority"), though we provide = access to it at "coap://authority/.well-known/core". >=20 > The problem is that, because the document containing links lists the = resources available on the server, we provide additional information = about specific resources in link parameters, rather than as link = descriptions. I now think that the roles served by the "d" and "sh" = extensions, and some uses of "n", should really be link descriptions = whose context is the target, target is the extension value, and rel is = the extension name. For example, rather than: >=20 > = n=3D"http://sweet.jpl.nasa.gov/2.0/phys.owl#Temperatu= re",sh=3D"/l"; >=20 > being one of the link descriptions at = coap://authority/.well-known/core, use consistent with RFC5988 would be = to provide: >=20 > rel=3D"describedby";= > rel=3D"alternate"; >=20 > as the set of link descriptions for = coap://authority/sensors/temperature. >=20 > Based on this perspective, and despite the fact that I've been added = as an author due to my contributions to disambiguating the syntax, I = don't think that CoRE Link Format describes a conceptually clean = solution to this problem that is compatible with what link descriptions = mean in RFC5988. >=20 > I believe a conceptually clean and compatible solution would be to = have coap://authority/.well-known/core return a list of links like: >=20 > rel=3D"hosts"; > rel=3D"hosts"; >=20 > to indicate that these are resources hosted on the server. >=20 > Further, define that coap://authority/.well-known/core/ = provides a link description document for context = coap://authority/. For example, = coap://authority/.well-known/core/sensors/temperature would return: >=20 > rel=3D"describedby";= > rel=3D"alternate"; >=20 > Thus providing in a single document the same sort of thing that would = be provided by a set of Link headers in an HTTP request to the context = URI. Note that what I called "further" is really the only case: = returning the list of hosted resources falls out as a consequence of = applying this rule with an empty . Very simple, very = orthogonal, only difference from HTTP is the URI used to obtain the link = descriptions and their encoding as a document rather than as header Link = fields. >=20 > (I can't tell from RFC5988 what the "index" relation is intended to = do, so perhaps it could be used instead of the newly created "hosts" = relation.) >=20 > I don't propose that CoAP actually implement this change, since I = don't think such a proposal would be accepted due to non-technical = pressures. But I did feel it necessary to raise the possibility, and to = ask for an outside perspective so we don't end up sending IESG something = that's completely at odds with how the concept we're borrowing is = understood and used by the rest of the Internet community. >=20 > Peter -- Mark Nottingham http://www.mnot.net/ From mab@comnets.uni-bremen.de Mon Nov 22 01:04:44 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E81F33A6ACC for ; Mon, 22 Nov 2010 01:04:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.835 X-Spam-Level: X-Spam-Status: No, score=-3.835 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47+cB3ThLH6o for ; Mon, 22 Nov 2010 01:04:43 -0800 (PST) Received: from bugs.comnets.uni-bremen.de (bugs.comnets.uni-bremen.de [134.102.186.10]) by core3.amsl.com (Postfix) with ESMTP id 7138728C0D7 for ; Mon, 22 Nov 2010 01:04:43 -0800 (PST) Received: from shelbyville.comnets.uni-bremen.de (shelbyville.comnets.uni-bremen.de [134.102.155.175]) by bugs.comnets.uni-bremen.de (Postfix) with ESMTPS id A0DB6D42442 for ; Mon, 22 Nov 2010 10:05:37 +0100 (CET) From: Markus Becker Organization: Comnets, University Bremen To: core@ietf.org Date: Mon, 22 Nov 2010 10:05:36 +0100 User-Agent: KMail/1.13.5 (Linux/2.6.32-5-686; KDE/4.5.3; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201011221005.37045.mab@comnets.uni-bremen.de> Subject: Re: [core] Help me with CoAP Demo X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 09:04:45 -0000 > Dear evey one, > > now i am starting with CoAP and have to make a demo. > > do you know where i should start ? and does it have any demo is available > for CoAP (in tinyos or contiki). > > could you give me some guide for CoAP Demo? Probably you would want to start with Olaf's C implementation libcoap [1] or Peter's Python implementation coappy [2] on a usual computer and not start directly on WSN nodes. [1] http://sourceforge.net/projects/libcoap/ [2] http://coapy.sourceforge.net/ We are currently working on a port of libcoap to TinyOS. Markus > thank you very much, > > > Ngoc Thanh ------------------------------------------------ | Dipl.-Ing. Markus Becker | Communication Networks | Mobile Research Center | 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 mab@comnets.uni-bremen.de Mon Nov 22 01:27:43 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B47903A6A7A for ; Mon, 22 Nov 2010 01:27:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.042 X-Spam-Level: X-Spam-Status: No, score=-5.042 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bmRb8jqnB9Uh for ; Mon, 22 Nov 2010 01:27:42 -0800 (PST) Received: from bugs.comnets.uni-bremen.de (bugs.comnets.uni-bremen.de [134.102.186.10]) by core3.amsl.com (Postfix) with ESMTP id 43F5D3A6A74 for ; Mon, 22 Nov 2010 01:27:42 -0800 (PST) Received: from shelbyville.comnets.uni-bremen.de (shelbyville.comnets.uni-bremen.de [134.102.155.175]) by bugs.comnets.uni-bremen.de (Postfix) with ESMTPS id 394D1D4030C for ; Mon, 22 Nov 2010 10:28:31 +0100 (CET) To: core@ietf.org From: Markus Becker Organization: Comnets, University Bremen Date: Mon, 22 Nov 2010 10:28:30 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011221028.30662.mab@comnets.uni-bremen.de> Subject: [core] Size of CoAP implementation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 09:27:43 -0000 Hi, Carsten asked me to give some data points on how big CoAP is right now on constrained nodes (here: TinyOS, TelosB). As a reference: Simple TinyOS application with Radio stack: (RadioCountToLeds) 11890 bytes in ROM 329 bytes in RAM Sample TinyOS blip 6LoWPAN application with a shell and echo service (UDPEcho, not optimized aka ntop6 support included, debugging): 29474 bytes in ROM 5062 bytes in RAM (same, ntop6 support removed, debugging) 28794 bytes in ROM 5062 bytes in RAM Simple CoAP server based on Olaf's libcoap and TinyOS blip 6lowpan stack (no sensors pulled in, ntop6 support removed, NO debugging) 31866 bytes in ROM 5492 bytes in RAM Simple CoAP server based on Olaf's libcoap and TinyOS blip 6lowpan stack (not optimized, 2 async sensor resources being served, debugging): 40730 bytes in ROM 5802 bytes in RAM As a reference: TelosB motes are equipped with 48k ROM, 10k RAM Markus ------------------------------------------------ | Dipl.-Ing. Markus Becker | Communication Networks | Mobile Research Center | 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 doganyazar@yahoo.com Mon Nov 22 02:10:10 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C72203A6ACC for ; Mon, 22 Nov 2010 02:10:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9oPA14HSYr+U for ; Mon, 22 Nov 2010 02:10:08 -0800 (PST) Received: from web52204.mail.re2.yahoo.com (web52204.mail.re2.yahoo.com [206.190.48.127]) by core3.amsl.com (Postfix) with SMTP id 67A8228C0E8 for ; Mon, 22 Nov 2010 02:10:07 -0800 (PST) Received: (qmail 93342 invoked by uid 60001); 22 Nov 2010 10:10:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1290420659; bh=u3Hg96gorfolwNvCU7s1e8u3IjHECvt7iJapI2mJsTo=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=Q0LEmoP2FlIy4DOpYhoo32Gw2Hq1dJWlEciKG3UOHM8S+uRDADTwkqgIEF9alH3lzafXfpuwP710JhqpWBxl3FrAOken0/ShygXNp1cBtk35O6Vpe3GtoQ7ubstexfsAOMXhZ7JAK0LiwjEhORXDqVeUH7PaIL9nj23eKwMHeWs= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=zoqq03Svb0pX//dJzaJfXw/oH3GdvUdcZzmirCR3lAvMCBdqDxzQZ7vjiXWO+DnPQO3W8F4KCSUcyy5VvjQG+YDRibWpXKzvpnER+ArLONV0ocy25SJaO1qMpIeaFADWQ7Mge+pNb4GIK6OtOxkCprl/cJ/IvFHjTHYFHKZy750=; Message-ID: <860443.93182.qm@web52204.mail.re2.yahoo.com> X-YMail-OSG: IaVdiRQVM1kNP9jnuRv7D6Y.mWP5x7TQhKV__9h8oLmo6_f hS00dMsZLlT57cHMYc4O2MH72DvgQnFwKGtim1dsrlyThdiTpf_3RisDHj9W KrpMq09_JzC3iHudGKdRycxM15VBccC_cjTJg0hF.7X0NJRRn6No2Q_05noQ 15G.JoTH_Y_OHs8DPjhg8RHO9giCv2lyXXG0Ra.1yd9dXhNXmVIqhA84Gbdj ON3oRHbeOlC596CqK_MCnCDafbsj0nXvOPJ5Kz8uiD8gKIwElrqpQrr8CeeX qskiC6n9fxBkzBHJUcGzvC7HCgWxoo.sXW4L2gTso1EasvUWPjxqRlG7yWsA Nh.kDb9oG4XEstUr6_lNO.dRbjhgAQktnCwsRGLEMYw-- Received: from [193.10.66.60] by web52204.mail.re2.yahoo.com via HTTP; Mon, 22 Nov 2010 02:10:59 PST X-Mailer: YahooMailRC/504.5 YahooMailWebService/0.8.107.285259 References: Date: Mon, 22 Nov 2010 02:10:59 -0800 (PST) From: dogan yazar To: Thanh Ngoc , core@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-876789876-1290420659=:93182" Subject: Re: [core] Help me with CoAP Demo X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 10:10:10 -0000 --0-876789876-1290420659=:93182 Content-Type: text/plain; charset=us-ascii There is a COAP implementation in the upcoming version of Contiki (version 2.5). There is also a REST layer written on top of it to ease the development of RESTful applications. Regards Dogan Yazar ________________________________ From: Thanh Ngoc To: core@ietf.org Sent: Mon, November 22, 2010 2:13:01 AM Subject: [core] Help me with CoAP Demo Dear evey one, now i am starting with CoAP and have to make a demo. do you know where i should start ? and does it have any demo is available for CoAP (in tinyos or contiki). could you give me some guide for CoAP Demo? thank you very much, Ngoc Thanh --0-876789876-1290420659=:93182 Content-Type: text/html; charset=us-ascii
    There is a COAP implementation in the upcoming version of Contiki (version 2.5). There is also a REST layer written on top of it to ease the development of RESTful applications.

    Regards
    Dogan Yazar

    From: Thanh Ngoc <ngocthanhdinh@gmail.com>
    To: core@ietf.org
    Sent: Mon, November 22, 2010 2:13:01 AM
    Subject: [core] Help me with CoAP Demo

    Dear evey one,

    now i am starting with CoAP and have to make a demo.

    do you know where i should start ? and does it have any demo is available for CoAP (in tinyos or contiki).

    could you give me some guide for CoAP Demo?

    thank you very much,


            Ngoc Thanh

    --0-876789876-1290420659=:93182-- From zach@sensinode.com Mon Nov 22 04:20:38 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 297EC28C102 for ; Mon, 22 Nov 2010 04:20:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.297 X-Spam-Level: X-Spam-Status: No, score=-3.297 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2FRIrPuca22 for ; Mon, 22 Nov 2010 04:20:33 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id EF2233A69B3 for ; Mon, 22 Nov 2010 04:20:31 -0800 (PST) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id oAMCLNNC004588 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 22 Nov 2010 14:21:23 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-90-736155767; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: Date: Mon, 22 Nov 2010 14:21:24 +0200 Message-Id: <708E8D43-2BE9-4983-9C75-B245062FF3BF@sensinode.com> References: To: Peter Bigot X-Mailer: Apple Mail (2.1081) Cc: Mark Nottingham , "core Environments\) WG" Subject: Re: [core] Link Format document X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 12:20:38 -0000 --Apple-Mail-90-736155767 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Peter, I also agree that we don't quite have the ideal use of the link relation = concept yet, but are getting there. Consider that the first version of = the CoRE link format didn't use the relation concept at all, in the last = couple versions we have gotten much closer. But just because we are = re-using the link format from RFC5988, does not mean we are bound to use = exactly the same link relation semantics that were designed for = hypertext HTTP servers (nor does that necessarily even make sense). = However, I do find the link relation work done in RFC5988 to be useful = also in our domain to some extent, so we should try to apply what we can = to M2M.=20 I wouldn't go quite as far as Peter's idea below though. For M2M these = descriptions need to be as compact as possible, nor can we expect = constrained device to traverse many links to find out simple information = about a resource. I do think we should improve the way we use rel=3D"" = for example, and the use of link-extensions can use improvement too. On a related note, I also received really helpful feedback from Martin = Thomson on this same subject in Beijing. I will CC the list with some of = that discussion pretty soon. He has good ideas for improving the use of = rel=3D and how our link-extensions should be used.=20 See some comments in-line: On Nov 21, 2010, at 6:55 PM, Peter Bigot wrote: > Either at the IETF session or in some email I can't easily find, there = was a specific question raised about exactly how the link description is = supposed to be used in CoAP that started me down a path that led to the = following comment. I've cc'd Mark Nottingham, author of RFC5988 "Web = Linking", in hopes he might have time to provide relevant information to = guide us. >=20 > My understanding of RFC5988 is it proposes a way to provide, in an = HTTP response header, information about (target) resources that are = related in (rel) some way to the (context) resource identified in the = original request. Other contexts can be specified through the anchor = parameter, but I expect this is unusual. Yes, this is the basic concept of RFC5988. I agree that anchor will be = rare, as we point out in Section 2.1 of core-link-format-01. >=20 > In CoAP's link format document at = http://tools.ietf.org/html/draft-ietf-core-link-format, we are rather = mis-using this to provide a list of resources that are hosted on a = server. Technically, the context of the list items is the resource = which is the server itself ("coap://authority"), though we provide = access to it at "coap://authority/.well-known/core". I wouldn't say we are misusing it, but that we are defining what the = context is by default. Section 2.1 explains that the CoRE link entries = are describing links to resources hosted on the server. The rel=3D = relation is defined to be "service" by default in Section 2.2 to = describe that the link is a service of the server. I do like your idea = here of explaining that the context is the URI coap://authority.=20 > The problem is that, because the document containing links lists the = resources available on the server, we provide additional information = about specific resources in link parameters, rather than as link = descriptions. I now think that the roles served by the "d" and "sh" = extensions, and some uses of "n", should really be link descriptions = whose context is the target, target is the extension value, and rel is = the extension name. For example, rather than: Link parameters are meant to provide further information about the link. = This is the purpose of the link-extensions defined in the CoRE link = format. In that way they are similar to the link-parameters defined in = RFC5988. =20 > = n=3D"http://sweet.jpl.nasa.gov/2.0/phys.owl#Temperatu= re",sh=3D"/l"; I do see what you are getting at here, however in Beijing we basically = decided to remove the Short URL "sh" parameter anyways. Furthermore, I = don't consider the way you are thinking about the Name "n" is quite = right. This is not meant to be a link (URL) to some document, but = instead is meant to be a semantic name or URI used as a semantic name. > being one of the link descriptions at = coap://authority/.well-known/core, use consistent with RFC5988 would be = to provide: >=20 > rel=3D"describedby";= > rel=3D"alternate"; You could do this, however it would be both inefficient and complex. I = think we can avoid this by using Name properly. Let's get back to that = in a separate mail with Marin's suggestions.=20 >=20 > as the set of link descriptions for = coap://authority/sensors/temperature. >=20 > Based on this perspective, and despite the fact that I've been added = as an author due to my contributions to disambiguating the syntax, I = don't think that CoRE Link Format describes a conceptually clean = solution to this problem that is compatible with what link descriptions = mean in RFC5988. >=20 > I believe a conceptually clean and compatible solution would be to = have coap://authority/.well-known/core return a list of links like: >=20 > rel=3D"hosts"; > rel=3D"hosts"; >=20 > to indicate that these are resources hosted on the server. Now I like this idea. I tried to use "service" to indicate this, but = would be happy with defining a new "hosts" relation for this purpose. = What do others think? That does not stop you from including the needed link-parameter = meta-data with this link description. For example title=3D"Title Name", = n=3D"SemanticName", ct=3D1, id=3D3 etc.=20 >=20 > Further, define that coap://authority/.well-known/core/ = provides a link description document for context = coap://authority/. For example, = coap://authority/.well-known/core/sensors/temperature would return: >=20 > rel=3D"describedby";= > rel=3D"alternate"; You could do this with relations, however I don't think anybody really = wants to do this. So as I summary I do propose that we consider creating the new "hosts" = relation and better explaining that our context is coap://authority. We = should also better define how we should use our link-extensions. We = might consider giving some example of more creative use of deeper sets = of relations about a resource, but this is something that I definitely = would not require from a constrained node. Peter, how about I make a = ticket on this? Zach >=20 > Thus providing in a single document the same sort of thing that would = be provided by a set of Link headers in an HTTP request to the context = URI. Note that what I called "further" is really the only case: = returning the list of hosted resources falls out as a consequence of = applying this rule with an empty . Very simple, very = orthogonal, only difference from HTTP is the URI used to obtain the link = descriptions and their encoding as a document rather than as header Link = fields. >=20 > (I can't tell from RFC5988 what the "index" relation is intended to = do, so perhaps it could be used instead of the newly created "hosts" = relation.) >=20 > I don't propose that CoAP actually implement this change, since I = don't think such a proposal would be accepted due to non-technical = pressures. But I did feel it necessary to raise the possibility, and to = ask for an outside perspective so we don't end up sending IESG something = that's completely at odds with how the concept we're borrowing is = understood and used by the rest of the Internet community. >=20 > Peter > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 --Apple-Mail-90-736155767 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9 fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb 6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja 5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I 2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTEyMjEyMjEy NVowIwYJKoZIhvcNAQkEMRYEFHtPj6zuVQCb4S0FCvnXgYIa/LauMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAGI6WQ6F1Ef7qBuEWMODaiufCTY97ggq45nARufh49WIWuwAeWnlk/Jq Cvxzx22jUJMFwcyGe0zkg0Y2tsRB3vO9UJ6OZ9WBkAF1vejpVmqLtwPOf0EhBYU9CwA7DNn0e36k ovezYJAgSnI9qfJLiAa7pgs4fNqA9TIcQOM4kTQ8/cOkbS3U/M6Hir7yXga8Ft087xNWl0w8ylw2 GnJR5q52jaw3PlIAXRY+MpxJzv8kiAbq3xbxa6RQ/8LR9r6CxQ24VTBnwXusko83EQqVoA7bimP7 FMYyQLn+iII7y4YDjjsLE5CuRkHVpGtl+BKMSpiA2VpeUMPSHLjjdBvOBcAAAAAAAAA= --Apple-Mail-90-736155767-- From zach@sensinode.com Mon Nov 22 04:37:16 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B7EB28C0FE for ; Mon, 22 Nov 2010 04:37:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.357 X-Spam-Level: X-Spam-Status: No, score=-3.357 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VFmP3uK0Gnq9 for ; Mon, 22 Nov 2010 04:37:15 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 937C73A69B3 for ; Mon, 22 Nov 2010 04:37:14 -0800 (PST) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id oAMCc4dq016319 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 22 Nov 2010 14:38:04 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-93-737156921; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03F33652D2@SISPE7MB1.commscope.com> Date: Mon, 22 Nov 2010 14:38:05 +0200 Message-Id: <02FEE582-3AD1-44BD-90D0-1F272AE5D255@sensinode.com> References: <8B0A9FCBB9832F43971E38010638454F03F33652D2@SISPE7MB1.commscope.com> To: "Thomson, Martin" X-Mailer: Apple Mail (2.1081) Cc: Mark Nottingham , "core Environments\) WG" Subject: Re: [core] Core linking X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 12:37:16 -0000 --Apple-Mail-93-737156921 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Martin Thomson and I discussed the CoRE link format after the WG meeting = in Beijing, and he was nice enough to give us some helpful comments as = well. Here I am CCing the list when responding as this compliments the = comments from Peter too.=20 On Nov 10, 2010, at 5:05 AM, Thomson, Martin wrote: > 'd' sounds like a neat metadata indirection mechanism. That's = probably the best of these links. >=20 > Like others, I agree that 'sh' is not useful. If you need a short URI = for the resource, then you can simply identify the resource with a short = URI and save the bytes from all uses for the resource. >=20 > 'id' seems a little strange. Unless the scope of the identifier is = something other than the server, the URL provides enough information for = someone to identify a resource. Does this have a different scope than = the one server? Or is the intent to convey information on from = different identification domains? We were originally thinking ID would have global scope, something like a = UUID. However in Beijing it was suggested to instead give it server = scope and use it as a kind of index. For example you might have three = different hosted resources with the semantic name "TemperatureC". The = index would be used to give each an index on the server.=20 > I really like the format, but I have two requests: =20 > Can you use line terminations to separate links rather than commas? = That's going to be easier for me to process (in unix tools for example) = and display. I know that the link header uses commas, but that is = intended for a single HTTP header. In a file format, this is less = important. I wouldn't want to do that, we actually prefer to stick with the comma. = When this is displayed to a human at some point, the display can always = add terminations. > Can you use UTF-8 rather than ASCII? The only cost being that = clients need to be able to cope with having the high bit set in each = octet. The cost to a parser can be quite small and I think that you'll = find that this will save you a lot of awkward questions. Now this is a very interesting idea, which will probably save us lots of = pain later. I will make a ticket.=20 > The 'rel'/'n' stuff is tricky. >=20 > Keying on 'n' sounds dangerous as it is currently defined. The fact = that it is both (or variably) human readable and semantically = significant is an overloading that could cause problems. >=20 > For one, 'n' and 'title' [RFC5988] seem very similar. Maybe the human = readable capability is better left to 'title'. It also punts on the = other human-readable concerns, like language tagging. I like this suggestion. We should instead use title for these human = readable uses.=20 > With human-readable concerns dealt with, that leaves 'n' with a single = purpose... If it is needed. n is meant to be a semantic name, used for a machine to find a resource = to use, e.g. "TemperatureC". This would indeed leave it for a single = purpose, which is good.=20 >=20 > 'rel' might be used to provide typing in the way that is compatible = with 'n'. The form that this takes might be a little different. And = from .well-known it is difficult because the context of .well-known is = somewhat poorly understood. >=20 > For instance, a light sensor could provide a .well-known with a link = maybe like... >=20 > ,rel=3Dsensor-state >=20 > The .well-known resource is about the server; the sensor state = resource is related to the .well-known resource in a specific way. For this I like the suggestion from Peter on the CoRE list, which is to = define that the context is coap://authority and we use a new relation = type "hosts".=20 >=20 > That doesn't work that well for devices with multiple sensors; so = having a separate disambiguation function is useful. The URL does that. = The title can be used to provide user-consumable clues. For = automatons, you need something less fuzzy than title and more definite = than a URI (potentially something across different servers). >=20 > In my experience, having a domain-specific namespace for identifying = the type of resource is the easiest solution. Something defined by the = server with scoping for the server. I think that this is what you = intended for the 'n' parameter. Though in this case it might be better = to find a better label for the parameter. "name" is something with a = lot of semantic baggage. Maybe you can consider using 'id' for this = purpose (in light of my above comment). >=20 > ;id=3D'current';rel=3Dsensor;title=3D"Current Temperature" > ;id=3D'hourly';rel=3Dsensor;title=3D"Temperate Average = (Hourly)" >=20 > This is a tricky problem. I expect that you will need to explore your = options and provide a good amount of explanatory text on the topic when = you finally decide. Each type-/name-/identifier-class parameter needs a = description that identifies scope, domain and all that sort of stuff. I = don't think that there is enough there yet. We'll need to discuss this some more, maybe more examples will be the = best for nailing down the best uses for the extensions. Regards, Zach=20 >=20 > --Martin >=20 > (Feel free to forward this to the core WG, if you think that this is = useful.) --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 --Apple-Mail-93-737156921 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9 fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb 6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja 5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I 2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTEyMjEyMzgw NlowIwYJKoZIhvcNAQkEMRYEFB+NZIr5WvAa8tHitWohDWM+E5deMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBABJ+7CL/x8WOfBMDk5yq3cK/kTZPGyKf0pN39kS2oIXNhjmCUoTMO86G Nbm1ezdjkqc4UNokBxI8QwDkdoyIhQZms7iJnOcdFc5L/XL76/dNeJ4T+MCAFX94k56a67mkBp27 GXnwfLEd82EhkIrO2DH7VTJ4TbL5dn1amU4lb5Jhlsk7V9twF+j98hBRGv2oMRAUEQtzPlkmVY/j gsgndcUnSyjuN7r3WfCRsfZa4ZhUBA/teuP7TGff52T9MNjYffJxgTmNf13JuHwqTS8PKVASCpUJ pQjKmHhPqKS2gXKbr60tBwOp+voCXgZVtZD7vyILJTwlAErhS2Ce2dxUg/UAAAAAAAA= --Apple-Mail-93-737156921-- From klaus.hartke@googlemail.com Mon Nov 22 06:28:16 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 665EB28C0EC for ; Mon, 22 Nov 2010 06:28:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZq4xNjmfYGl for ; Mon, 22 Nov 2010 06:28:15 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 27B1D3A691A for ; Mon, 22 Nov 2010 06:28:14 -0800 (PST) Received: by ewy8 with SMTP id 8so3576241ewy.31 for ; Mon, 22 Nov 2010 06:29:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=IMYq0T+5JE//I+qjc2Rsws97Dnkoe5OslW7uzQqvM40=; b=V0FzM8iqR3kpow8P3JbUAjU5OdOTFqAxGqCmLXbqZCEmaX1Brd0xuERXbwhU4Q8sB0 rcS9xZOJKL5C/rLvyXgZoJS6Cs5PkyZYV2nn0KAFRrrAVtXBXwzu0XB35HqB75BYiW0J RW7Y25HIxMg7hsIeYHwYkoFKJsQ4sl+uy9sFY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=AeCoGLGAoiaPtApK754LJqKHzJ+8M4cdjlK7KgxNkt7HiVQxZl+CqRIq21i8hT1NT6 0xA6N5WSZWxsK3Pp2xAd8FwPOp4oAav3yCE2xE/JtlMEQTuvbB0rZGAQr8JM8rB2KZU5 4Em1ZRvi2vXjq2j3scII898QUG9FWYzexEajk= MIME-Version: 1.0 Received: by 10.204.72.140 with SMTP id m12mr5336301bkj.163.1290436149564; Mon, 22 Nov 2010 06:29:09 -0800 (PST) Sender: klaus.hartke@googlemail.com Received: by 10.204.121.134 with HTTP; Mon, 22 Nov 2010 06:29:09 -0800 (PST) In-Reply-To: References: <1909899D-43E8-4C00-B957-6787468B4CDB@sensinode.com> Date: Mon, 22 Nov 2010 15:29:09 +0100 X-Google-Sender-Auth: fqC7Kj8jCnc6dWZ_9Kbtfonr4L8 Message-ID: From: Klaus Hartke To: core Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [core] Proxy and server on the same port X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 14:28:16 -0000 Proposal: We resurrect the Uri-Scheme Option, but without a default value. The rules are: * If an end-point is configured to make the request though a proxy, the end-point must include the Uri-Scheme Option in the request. * If an end-point is not configured to make the request through a proxy, the end-point must not include the Uri-Scheme Option in the request. * If an end-point receives a request with Uri-Scheme Option but isn't a proxy, it must send a 4xx response. * If an end-point receives a request with Uri-Scheme Option and is a proxy, it forwards the request according to the first two rules. * If an end-point receives a request without Uri-Scheme Option but isn't a server, it must send a 4xx response. * If an end-point receives a request without Uri-Scheme Option and is a server, it handles the request. Klaus From pab@peoplepowerco.com Mon Nov 22 06:37:25 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8F883A6A89 for ; Mon, 22 Nov 2010 06:37:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.957 X-Spam-Level: X-Spam-Status: No, score=-1.957 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mXQuU8aNhpRo for ; Mon, 22 Nov 2010 06:37:25 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id CCB013A6A97 for ; Mon, 22 Nov 2010 06:37:24 -0800 (PST) Received: by fxm3 with SMTP id 3so4834801fxm.31 for ; Mon, 22 Nov 2010 06:38:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.104.68 with SMTP id n4mr2602641fao.127.1290436699849; Mon, 22 Nov 2010 06:38:19 -0800 (PST) Received: by 10.223.70.198 with HTTP; Mon, 22 Nov 2010 06:38:19 -0800 (PST) In-Reply-To: References: <1909899D-43E8-4C00-B957-6787468B4CDB@sensinode.com> Date: Mon, 22 Nov 2010 08:38:19 -0600 Message-ID: From: Peter Bigot To: Klaus Hartke Content-Type: multipart/alternative; boundary=001636c9239e1984420495a53598 Cc: core Subject: Re: [core] Proxy and server on the same port X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 14:37:26 -0000 --001636c9239e1984420495a53598 Content-Type: text/plain; charset=ISO-8859-1 Back on 23Oct, I sent an email entitled "Proxy versus Gateway" that proposed clarifying some terminology. Nobody responded, but I see it's become ticket #72. I would like to see some discussion before taking on any responsibilities associated with that ticket. If what I proposed is to be adopted, much of this confusion may go away. Putting a proxy on the same port as a server is unnecessarily confusing in that situation. They really are completely different applications, used in different ways. Peter On Mon, Nov 22, 2010 at 8:29 AM, Klaus Hartke wrote: > Proposal: We resurrect the Uri-Scheme Option, but without a default > value. The rules are: > > * If an end-point is configured to make the request though a proxy, > the end-point must include the Uri-Scheme Option in the request. > * If an end-point is not configured to make the request through a > proxy, the end-point must not include the Uri-Scheme Option in the > request. > * If an end-point receives a request with Uri-Scheme Option but isn't > a proxy, it must send a 4xx response. > * If an end-point receives a request with Uri-Scheme Option and is a > proxy, it forwards the request according to the first two rules. > * If an end-point receives a request without Uri-Scheme Option but > isn't a server, it must send a 4xx response. > * If an end-point receives a request without Uri-Scheme Option and is > a server, it handles the request. > > > Klaus > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --001636c9239e1984420495a53598 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Back on 23Oct, I sent an email entitled "Proxy versus Gateway" th= at proposed clarifying some terminology.=A0 Nobody responded, but I see it&= #39;s become ticket #72.=A0 I would like to see some discussion before taki= ng on any responsibilities associated with that ticket.

    If what I proposed is to be adopted, much of this confusion may go away= .=A0 Putting a proxy on the same port as a server is unnecessarily confusin= g in that situation.=A0 They really are completely different applications, = used in different ways.

    Peter

    On Mon, Nov 22, 2010 at 8:29 AM= , Klaus Hartke <hart= ke@tzi.org> wrote:
    Proposal: We resurrect the Uri-Scheme Option, but without a default
    value. The rules are:

    * If an end-point is configured to make the request though a proxy,
    the end-point must include the Uri-Scheme Option in the request.
    * If an end-point is not configured to make the request through a
    proxy, the end-point must not include the Uri-Scheme Option in the
    request.
    * If an end-point receives a request with Uri-Scheme Option but isn't a proxy, it must send a 4xx response.
    * If an end-point receives a request with Uri-Scheme Option and is a
    proxy, it forwards the request according to the first two rules.
    * If an end-point receives a request without Uri-Scheme Option but
    isn't a server, it must send a 4xx response.
    * If an end-point receives a request without Uri-Scheme Option and is
    a server, it handles the request.


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

    --001636c9239e1984420495a53598-- From mab@comnets.uni-bremen.de Mon Nov 22 07:30:31 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D761128B56A for ; Mon, 22 Nov 2010 07:30:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.646 X-Spam-Level: X-Spam-Status: No, score=-5.646 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mmTeRKtoEt8A for ; Mon, 22 Nov 2010 07:30:30 -0800 (PST) Received: from bugs.comnets.uni-bremen.de (bugs.comnets.uni-bremen.de [134.102.186.10]) by core3.amsl.com (Postfix) with ESMTP id 692823A69D2 for ; Mon, 22 Nov 2010 07:30:30 -0800 (PST) Received: from shelbyville.comnets.uni-bremen.de (shelbyville.comnets.uni-bremen.de [134.102.155.175]) by bugs.comnets.uni-bremen.de (Postfix) with ESMTPS id 18ACCD42442; Mon, 22 Nov 2010 16:31:24 +0100 (CET) From: Markus Becker Organization: Comnets, University Bremen To: noblomov Date: Mon, 22 Nov 2010 16:31:22 +0100 User-Agent: KMail/1.13.5 (Linux/2.6.32-5-686; KDE/4.5.3; i686; ; ) References: <201011221028.30662.mab@comnets.uni-bremen.de> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201011221631.23299.mab@comnets.uni-bremen.de> Cc: core@ietf.org Subject: Re: [core] Size of CoAP implementation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 15:30:32 -0000 > Hi, > > Could you specify exactly what parts include these implementations ? > CoAP only, or CoAP and 6lowpan/uIP stack and radio stack, routing, etc... ? Those numbers are for TinyOS. uIP would be Contiki. The TinyOS 6LoWPAN stack in use here is the Berkeley Low-Power IP (blip) stack, version 1.0, which uses HYDRO routing protocol (not RPL). More information inline. > Thanks, > > N. > > On Mon, Nov 22, 2010 at 10:28 AM, Markus Becker > > wrote: > > Hi, > > > > Carsten asked me to give some data points on how big CoAP is right now on > > constrained nodes (here: TinyOS, TelosB). > > > > As a reference: Simple TinyOS application with Radio stack: > > (RadioCountToLeds) Usual TinyOS radio stack, not 6LoWPAN, no CoAP, no multi-hop. > > > > 11890 bytes in ROM > > > > 329 bytes in RAM > > > > Sample TinyOS blip 6LoWPAN application with a shell and echo service TinyOS 6LoWPAN Berkeley Low-Power IP (blip) stack, no CoAP. > > > > (UDPEcho, not optimized aka ntop6 support included, debugging): > > 29474 bytes in ROM > > > > 5062 bytes in RAM > > > > (same, ntop6 support removed, debugging) > > > > 28794 bytes in ROM > > > > 5062 bytes in RAM > > > > Simple CoAP server based on Olaf's libcoap and TinyOS blip 6lowpan stack > > (no sensors pulled in, ntop6 support removed, NO debugging) TinyOS 6LoWPAN Berkeley Low-Power IP (blip) stack + CoAP. > > > > 31866 bytes in ROM > > > > 5492 bytes in RAM > > > > Simple CoAP server based on Olaf's libcoap and TinyOS blip 6lowpan stack TinyOS 6LoWPAN Berkeley Low-Power IP (blip) stack + CoAP + Sensor drivers. > > > > (not optimized, 2 async sensor resources being served, debugging): > > 40730 bytes in ROM > > > > 5802 bytes in RAM > > > > As a reference: TelosB motes are equipped with 48k ROM, 10k RAM > > > > Markus > > > > > > ------------------------------------------------ > > > > | Dipl.-Ing. Markus Becker > > | Communication Networks > > | Mobile Research Center > > | 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 > > > > ------------------------------------------------ > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core ------------------------------------------------ | Dipl.-Ing. Markus Becker | Communication Networks | Mobile Research Center | 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 pab@peoplepowerco.com Mon Nov 22 07:38:28 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E4423A6923 for ; Mon, 22 Nov 2010 07:38:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DMbu-xdduaPC for ; Mon, 22 Nov 2010 07:38:25 -0800 (PST) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 5215C3A69D2 for ; Mon, 22 Nov 2010 07:38:25 -0800 (PST) Received: by gwb15 with SMTP id 15so169763gwb.31 for ; Mon, 22 Nov 2010 07:39:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.71.201 with SMTP id i9mr4233812faj.89.1290440359957; Mon, 22 Nov 2010 07:39:19 -0800 (PST) Received: by 10.223.70.198 with HTTP; Mon, 22 Nov 2010 07:39:19 -0800 (PST) In-Reply-To: <708E8D43-2BE9-4983-9C75-B245062FF3BF@sensinode.com> References: <708E8D43-2BE9-4983-9C75-B245062FF3BF@sensinode.com> Date: Mon, 22 Nov 2010 09:39:19 -0600 Message-ID: From: Peter Bigot To: Zach Shelby Content-Type: multipart/alternative; boundary=20cf30433ed04255100495a60f00 Cc: Mark Nottingham , "core Environments\) WG" Subject: Re: [core] Link Format document X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 15:38:28 -0000 --20cf30433ed04255100495a60f00 Content-Type: text/plain; charset=ISO-8859-1 The CoRE working group doesn't really have consensus on the fundamental principles by which a proposal should be judged, let alone how to resolve conflicting goals. In my opinion, this has diminished the conceptual integrity of CoAP, resulting in ad hoc solutions prompted by specific cases regardless of the holistic effect. My own perspective is to strongly prefer existing practice in the web services and REST communities, given their demonstrated success and the requirement that CoAP bridge to HTTP. (If my understanding of existing practice is wrong, please help me correct it.) In this case, though we may not be bound to use the same link relation semantics as RFC5988 and HTTP, to deviate from them without a clear rationale is inconsistent with my philosophy. As an author of an IETF document I'm willing to put some significant effort into making it great, but I don't want to be an author of something I don't believe in. For CoRE Link Format to be acceptable to me as an author, my starting position is that we need two things: - The document shall not define a link-param which expresses a relation to a resource that will be accessed. That's what link descriptions are for, not link parameters. I don't see any link parameters in RFC5988 where the value is a resource (URI), except for extensions where the value serves purely as an identifier. - The approach for CoAP shall define a mechanism by which a set of link relations can be obtained for a specific URI on a server. I don't think either of these are onerous, and I believe they help preserve consistency with what the concept means to the rest of the world. Let's start with the first by reviewing the link extensions currently listed in the draft: - d -- Should be removed. I think this is what the "service" registered relation means. I believe it will be used rarely anyway. - sh -- There's a proposal to remove this. That's fine with me; when I want its function I'll use the "alternate" or "self" relations. - n -- I'm ok with describing this as a semantic identifier, and even allowing that identifier to be spelled the same way as a URL, as long as we make clear that the value is not intended to be used as a URL (a URN would be appropriate). This is what's done in section 4.2 of RFC5988 which specifies that URIs in extension relations should not be accessed. If a URI is to be used with the expectation that an implementation will attempt to access it, the "describedby" registered relation should be used. - ct -- Not a relation, fine as an extension. It's just a different encoding of the media link parameter. - id -- Not a relation, fine as an extension (but see my response in the other thread). So we end up with CoAP adding three link extensions: n, ct, and id, none of which describe relations to resources. Three potential relations to resources survive (service, alternate, describedby) but none seem critical for M2M, so there's no requirement for any specific implementation to support them. For the second, we: 1. Stipulate that the URI coap://authority/ refers to a resource which is the entire server. 2. Define and register a new link relation "hosts" indicating a resource that can be located at the target URI. ("hosts" is not necessarily the right name for this relation; we should discuss this after reviewing the existing relations.) It is to these relations that the CoAP-added link parameters will be attached. 3. Define that a GET on a URI coap://authority/.well-known/core/ provides a link description document for context coap://authority/and default relation "hosts". If this is done, then the existing practice of retrieving a list of resources available on the server by retrieving coap://authority/.well-known/core is preserved without change. A system with a need to provide relations between resources can do so by accepting other URIs prefixed with coap://authority/.well-known/core, but nobody is obliged to do so. You could do this with relations, however I don't think anybody really wants > to do this. > This is the sort of claim I don't find convincing. First, there are already situations where I do indeed want to do this: my own approach to observation would benefit from being able to use the "monitor" and "monitor-group" registered relations derived from RFC5989. Second, if allowing this does not impact implementations that choose not to use it, but ruling it out prevents use of CoAP to solve somebody's problem (which I think would be the case), I believe it should be allowed. How does all that fly? Peter On Mon, Nov 22, 2010 at 6:21 AM, Zach Shelby wrote: > Peter, > > I also agree that we don't quite have the ideal use of the link relation > concept yet, but are getting there. Consider that the first version of the > CoRE link format didn't use the relation concept at all, in the last couple > versions we have gotten much closer. But just because we are re-using the > link format from RFC5988, does not mean we are bound to use exactly the same > link relation semantics that were designed for hypertext HTTP servers (nor > does that necessarily even make sense). However, I do find the link relation > work done in RFC5988 to be useful also in our domain to some extent, so we > should try to apply what we can to M2M. > > I wouldn't go quite as far as Peter's idea below though. For M2M these > descriptions need to be as compact as possible, nor can we expect > constrained device to traverse many links to find out simple information > about a resource. I do think we should improve the way we use rel="" for > example, and the use of link-extensions can use improvement too. > > On a related note, I also received really helpful feedback from Martin > Thomson on this same subject in Beijing. I will CC the list with some of > that discussion pretty soon. He has good ideas for improving the use of rel= > and how our link-extensions should be used. > > See some comments in-line: > > On Nov 21, 2010, at 6:55 PM, Peter Bigot wrote: > > > Either at the IETF session or in some email I can't easily find, there > was a specific question raised about exactly how the link description is > supposed to be used in CoAP that started me down a path that led to the > following comment. I've cc'd Mark Nottingham, author of RFC5988 "Web > Linking", in hopes he might have time to provide relevant information to > guide us. > > > > My understanding of RFC5988 is it proposes a way to provide, in an HTTP > response header, information about (target) resources that are related in > (rel) some way to the (context) resource identified in the original request. > Other contexts can be specified through the anchor parameter, but I expect > this is unusual. > > Yes, this is the basic concept of RFC5988. I agree that anchor will be > rare, as we point out in Section 2.1 of core-link-format-01. > > > > > In CoAP's link format document at > http://tools.ietf.org/html/draft-ietf-core-link-format, we are rather > mis-using this to provide a list of resources that are hosted on a server. > Technically, the context of the list items is the resource which is the > server itself ("coap://authority"), though we provide access to it at > "coap://authority/.well-known/core". > > I wouldn't say we are misusing it, but that we are defining what the > context is by default. Section 2.1 explains that the CoRE link entries are > describing links to resources hosted on the server. The rel= relation is > defined to be "service" by default in Section 2.2 to describe that the link > is a service of the server. I do like your idea here of explaining that the > context is the URI coap://authority. > > > The problem is that, because the document containing links lists the > resources available on the server, we provide additional information about > specific resources in link parameters, rather than as link descriptions. I > now think that the roles served by the "d" and "sh" extensions, and some > uses of "n", should really be link descriptions whose context is the target, > target is the extension value, and rel is the extension name. For example, > rather than: > > Link parameters are meant to provide further information about the link. > This is the purpose of the link-extensions defined in the CoRE link format. > In that way they are similar to the link-parameters defined in RFC5988. > > > n=" > http://sweet.jpl.nasa.gov/2.0/phys.owl#Temperature",sh="/l"; > > I do see what you are getting at here, however in Beijing we basically > decided to remove the Short URL "sh" parameter anyways. Furthermore, I don't > consider the way you are thinking about the Name "n" is quite right. This is > not meant to be a link (URL) to some document, but instead is meant to be a > semantic name or URI used as a semantic name. > > > being one of the link descriptions at coap://authority/.well-known/core, > use consistent with RFC5988 would be to provide: > > > > rel="describedby"; > > rel="alternate"; > > You could do this, however it would be both inefficient and complex. I > think we can avoid this by using Name properly. Let's get back to that in a > separate mail with Marin's suggestions. > > > > > as the set of link descriptions for coap://authority/sensors/temperature. > > > > Based on this perspective, and despite the fact that I've been added as > an author due to my contributions to disambiguating the syntax, I don't > think that CoRE Link Format describes a conceptually clean solution to this > problem that is compatible with what link descriptions mean in RFC5988. > > > > I believe a conceptually clean and compatible solution would be to have > coap://authority/.well-known/core return a list of links like: > > > > rel="hosts"; > > rel="hosts"; > > > > to indicate that these are resources hosted on the server. > > Now I like this idea. I tried to use "service" to indicate this, but would > be happy with defining a new "hosts" relation for this purpose. What do > others think? > > That does not stop you from including the needed link-parameter meta-data > with this link description. For example title="Title Name", > n="SemanticName", ct=1, id=3 etc. > > > > > Further, define that coap://authority/.well-known/core/ > provides a link description document for context > coap://authority/. For example, > coap://authority/.well-known/core/sensors/temperature would return: > > > > rel="describedby"; > > rel="alternate"; > > You could do this with relations, however I don't think anybody really > wants to do this. > > So as I summary I do propose that we consider creating the new "hosts" > relation and better explaining that our context is coap://authority. We > should also better define how we should use our link-extensions. We might > consider giving some example of more creative use of deeper sets of > relations about a resource, but this is something that I definitely would > not require from a constrained node. Peter, how about I make a ticket on > this? > > Zach > > > > > Thus providing in a single document the same sort of thing that would be > provided by a set of Link headers in an HTTP request to the context URI. > Note that what I called "further" is really the only case: returning the > list of hosted resources falls out as a consequence of applying this rule > with an empty . Very simple, very orthogonal, only difference > from HTTP is the URI used to obtain the link descriptions and their encoding > as a document rather than as header Link fields. > > > > (I can't tell from RFC5988 what the "index" relation is intended to do, > so perhaps it could be used instead of the newly created "hosts" relation.) > > > > I don't propose that CoAP actually implement this change, since I don't > think such a proposal would be accepted due to non-technical pressures. But > I did feel it necessary to raise the possibility, and to ask for an outside > perspective so we don't end up sending IESG something that's completely at > odds with how the concept we're borrowing is understood and used by the rest > of the Internet community. > > > > Peter > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core > > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 > > --20cf30433ed04255100495a60f00 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The CoRE working group doesn't really have consensus on the fundamental= principles by which a proposal should be judged, let alone how to resolve = conflicting goals.=A0 In my opinion, this has diminished the conceptual int= egrity of CoAP, resulting in ad hoc solutions prompted by specific cases re= gardless of the holistic effect.

    My own perspective is to strongly prefer existing practice in the web s= ervices and REST communities, given their demonstrated success and the requ= irement that CoAP bridge to HTTP.=A0 (If my understanding of existing pract= ice is wrong, please help me correct it.)=A0 In this case, though we may no= t be bound to use the same link relation=20 semantics as RFC5988 and HTTP, to deviate from them without a clear rationa= le is=20 inconsistent with my philosophy.

    As an author of an IETF document I&= #39;m willing to put some significant effort into making it great, but I do= n't want to be an author of something I don't believe in.=A0 For Co= RE Link Format to be acceptable to me as an author, my starting position is= that we need two things:
    • The document shall not define a link-param which expresses a relati= on to a resource that will be accessed.=A0 That's what link description= s are for, not link parameters.=A0 I don't see any link parameters in R= FC5988 where the value is a resource (URI), except for extensions where the= value serves purely as an identifier.
    • The approach for CoAP shall define a mechanism by which a set of l= ink relations can be obtained for a specific URI on a server.
    = I don't think either of these are onerous, and I believe they help pres= erve consistency with what the concept means to the rest of the world. Let&= #39;s start with the first by reviewing the link extensions currently liste= d in the draft:
    • d -- Should be removed.=A0 I think this is what the "service&q= uot; registered relation means.=A0 I believe it will be used rarely anyway.=
    • sh -- There's a proposal to remove this.=A0 That's fine wi= th me; when I want its function I'll use the "alternate" or &= quot;self" relations.
    • n -- I'm ok with describing this as a semantic identifier, and even= allowing that identifier to be spelled the same way as a URL, as long as w= e make clear that the value is not intended to be used as a URL (a URN woul= d be appropriate).=A0 This is what's done in section 4.2 of RFC5988 whi= ch specifies that URIs in extension relations should not be accessed.=A0 If= a URI is to be used with the expectation that an implementation will attem= pt to access it, the "describedby" registered relation should be = used.
    • ct -- Not a relation, fine as an extension.=A0 It's just a differen= t encoding of the media link parameter.
    • id -- Not a relation, fine = as an extension (but see my response in the other thread).
    So = we end up with CoAP adding three link extensions: n, ct, and id, none of wh= ich describe relations to resources.=A0 Three potential relations to resour= ces survive (service, alternate, describedby) but none seem critical for M2= M, so there's no requirement for any specific implementation to support= them.

    For the second, we:
    1. Stipulate that the URI coap://authority/= refers to a resource which is the entire server.
    2. Define and regist= er a new link relation "hosts" indicating a resource that can be = located at the target URI.=A0 ("hosts" is not necessarily the rig= ht name for this relation; we should discuss this after reviewing the exist= ing relations.)=A0 It is to these relations that the CoAP-added link parame= ters will be attached.
    3. Define that a GET on a URI coap://authority/.well-known/core/<somepa= th> provides a link description document for context coap://authority/&l= t;somepath>and default relation "hosts".
    If this = is done, then the existing practice of retrieving a list of resources avail= able on the server by retrieving coap://authority/.well-known/core is prese= rved without change.=A0 A system with a need to provide relations between r= esources can do so by accepting other URIs prefixed with coap://authority/.= well-known/core, but nobody is obliged to do so.

    You could do = this with relations, however I don't think anybody really wants to do t= his.

    This is the sort of claim I don't find convincing.=A0 = First, there are already situations where I do indeed want to do this: my o= wn approach to observation would benefit from being able to use the "m= onitor" and "monitor-group" registered relations derived fro= m RFC5989.=A0 Second, if allowing this does not impact implementations that= choose not to use it, but ruling it out prevents use of CoAP to solve some= body's problem (which I think would be the case), I believe it should b= e allowed.

    How does all that fly?

    Peter

    O= n Mon, Nov 22, 2010 at 6:21 AM, Zach Shelby <zach@sensinode.com> wrote:
    =
    Peter,

    I also agree that we don't quite have the ideal use of the link relatio= n concept yet, but are getting there. Consider that the first version of th= e CoRE link format didn't use the relation concept at all, in the last = couple versions we have gotten much closer. But just because we are re-usin= g the link format from RFC5988, does not mean we are bound to use exactly t= he same link relation semantics that were designed for hypertext HTTP serve= rs (nor does that necessarily even make sense). However, I do find the link= relation work done in RFC5988 to be useful also in our domain to some exte= nt, so we should try to apply what we can to M2M.

    I wouldn't go quite as far as Peter's idea below though. For M2M th= ese descriptions need to be as compact as possible, nor can we expect const= rained device to traverse many links to find out simple information about a= resource. I do think we should improve the way we use rel=3D"" f= or example, and the use of link-extensions can use improvement too.

    On a related note, I also received really helpful feedback from Martin Thom= son on this same subject in Beijing. I will CC the list with some of that d= iscussion pretty soon. He has good ideas for improving the use of rel=3D an= d how our link-extensions should be used.

    See some comments in-line:

    On Nov 21, 2010, at 6:55 PM, Peter Bigot wrote:

    > Either at the IETF session or in some email I can't easily find, t= here was a specific question raised about exactly how the link description = is supposed to be used in CoAP that started me down a path that led to the = following comment. =A0I've cc'd Mark Nottingham, author of RFC5988 = "Web Linking", in hopes he might have time to provide relevant in= formation to guide us.
    >
    > My understanding of RFC5988 is it proposes a way to provide, in an HTT= P response header, information about (target) resources that are related in= (rel) some way to the (context) resource identified in the original reques= t. =A0Other contexts can be specified through the anchor parameter, but I e= xpect this is unusual.

    Yes, this is the basic concept of RFC5988. I agree that anchor will b= e rare, as we point out in Section 2.1 of core-link-format-01.

    >
    > In CoAP's link format document at http://tools.ietf.org/= html/draft-ietf-core-link-format, we are rather mis-using this to provi= de a list of resources that are hosted on a server. =A0Technically, the con= text of the list items is the resource which is the server itself ("co= ap://authority"), though we provide access to it at "coap://autho= rity/.well-known/core".

    I wouldn't say we are misusing it, but that we are defining what = the context is by default. Section 2.1 explains that the CoRE link entries = are describing links to resources hosted on the server. The rel=3D relation= is defined to be "service" by default in Section 2.2 to describe= that the link is a service of the server. I do like your idea here of expl= aining that the context is the URI coap://authority.

    > The problem is that, because the document containing links lists the r= esources available on the server, we provide additional information about s= pecific resources in link parameters, rather than as link descriptions. =A0= I now think that the roles served by the "d" and "sh" e= xtensions, and some uses of "n", should really be link descriptio= ns whose context is the target, target is the extension value, and rel is t= he extension name. =A0For example, rather than:

    Link parameters are meant to provide further information about the li= nk. This is the purpose of the link-extensions defined in the CoRE link for= mat. In that way they are similar to the link-parameters defined in RFC5988= .

    > <sensors/temperature>n=3D"http://sweet.jpl.nasa.gov/2= .0/phys.owl#Temperature",sh=3D"/l";

    I do see what you are getting at here, however in Beijing we basicall= y decided to remove the Short URL "sh" parameter anyways. Further= more, I don't consider the way you are thinking about the Name "n&= quot; is quite right. This is not meant to be a link (URL) to some document= , but instead is meant to be a semantic name or URI used as a semantic name= .

    > being one of the link descriptions at coap://authority/.well-known/cor= e, use consistent with RFC5988 would be to provide:
    >
    > <http://sweet.jpl.nasa.gov/2.0/phys.owl#Temperature>re= l=3D"describedby";
    > </l>rel=3D"alternate";

    You could do this, however it would be both inefficient and complex. = I think we can avoid this by using Name properly. Let's get back to tha= t in a separate mail with Marin's suggestions.

    >
    > as the set of link descriptions for coap://authority/sensors/temperatu= re.
    >
    > Based on this perspective, and despite the fact that I've been add= ed as an author due to my contributions to disambiguating the syntax, I don= 't think that CoRE Link Format describes a conceptually clean solution = to this problem that is compatible with what link descriptions mean in RFC5= 988.
    >
    > I believe a conceptually clean and compatible solution would be to hav= e coap://authority/.well-known/core return a list of links like:
    >
    > <sensors/temperature>rel=3D"hosts";
    > <sensors/humidity>rel=3D"hosts";
    >
    > to indicate that these are resources hosted on the server.

    Now I like this idea. I tried to use "service" to indicate = this, but would be happy with defining a new "hosts" relation for= this purpose. What do others think?

    That does not stop you from including the needed link-parameter meta-data w= ith this link description. For example title=3D"Title Name", n=3D= "SemanticName", ct=3D1, id=3D3 etc.

    >
    > Further, define that coap://authority/.well-known/core/<somepath>= ; provides a link description document for context coap://authority/<som= epath>. =A0For example, coap://authority/.well-known/core/sensors/temper= ature would return:
    >
    > <http://sweet.jpl.nasa.gov/2.0/phys.owl#Temperature>re= l=3D"describedby";
    > </l>rel=3D"alternate";

    You could do this with relations, however I don't think anybody r= eally wants to do this.

    So as I summary I do propose that we consider creating the new "hosts&= quot; relation and better explaining that our context is coap://authority. = We should also better define how we should use our link-extensions. We migh= t consider giving some example of more creative use of deeper sets of relat= ions about a resource, but this is something that I definitely would not re= quire from a constrained node. Peter, how about I make a ticket on this?
    Zach

    >
    > Thus providing in a single document the same sort of thing that would = be provided by a set of Link headers in an HTTP request to the context URI.= =A0Note that what I called "further" is really the only case: re= turning the list of hosted resources falls out as a consequence of applying= this rule with an empty <somepath>. =A0Very simple, very orthogonal,= only difference from HTTP is the URI used to obtain the link descriptions = and their encoding as a document rather than as header Link fields.
    >
    > (I can't tell from RFC5988 what the "index" relation is = intended to do, so perhaps it could be used instead of the newly created &q= uot;hosts" relation.)
    >
    > I don't propose that CoAP actually implement this change, since I = don't think such a proposal would be accepted due to non-technical pres= sures. =A0But I did feel it necessary to raise the possibility, and to ask = for an outside perspective so we don't end up sending IESG something th= at's completely at odds with how the concept we're borrowing is und= erstood and used by the rest of the Internet community.
    >
    > Peter
    > _______________________________________________
    > core mailing list
    > core@ietf.org
    > https://www.ietf.org/mailman/listinfo/core

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


    --20cf30433ed04255100495a60f00-- From pab@peoplepowerco.com Mon Nov 22 07:52:18 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 863A93A6A7E for ; Mon, 22 Nov 2010 07:52:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.958 X-Spam-Level: X-Spam-Status: No, score=-1.958 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Hsc+uH1C+Cj for ; Mon, 22 Nov 2010 07:52:16 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 33A303A6A62 for ; Mon, 22 Nov 2010 07:52:16 -0800 (PST) Received: by fxm3 with SMTP id 3so4913539fxm.31 for ; Mon, 22 Nov 2010 07:53:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.104.68 with SMTP id n4mr2699852fao.127.1290441191172; Mon, 22 Nov 2010 07:53:11 -0800 (PST) Received: by 10.223.70.198 with HTTP; Mon, 22 Nov 2010 07:53:11 -0800 (PST) In-Reply-To: <02FEE582-3AD1-44BD-90D0-1F272AE5D255@sensinode.com> References: <8B0A9FCBB9832F43971E38010638454F03F33652D2@SISPE7MB1.commscope.com> <02FEE582-3AD1-44BD-90D0-1F272AE5D255@sensinode.com> Date: Mon, 22 Nov 2010 09:53:11 -0600 Message-ID: From: Peter Bigot To: Zach Shelby Content-Type: multipart/alternative; boundary=001636c9239ecdac2f0495a6404d Cc: Mark Nottingham , "core Environments\) WG" , "Thomson, Martin" Subject: Re: [core] Core linking X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 15:52:18 -0000 --001636c9239ecdac2f0495a6404d Content-Type: text/plain; charset=ISO-8859-1 On Mon, Nov 22, 2010 at 6:38 AM, Zach Shelby wrote: > > 'id' seems a little strange. Unless the scope of the identifier is > something other than the server, the URL provides enough information for > someone to identify a resource. Does this have a different scope than the > one server? Or is the intent to convey information on from different > identification domains? > > We were originally thinking ID would have global scope, something like a > UUID. However in Beijing it was suggested to instead give it server scope > and use it as a kind of index. For example you might have three different > hosted resources with the semantic name "TemperatureC". The index would be > used to give each an index on the server. > This is really unconvincing. "a kind of index"? How is the application supposed to use that index? I don't think we should include id without a better understanding of what it's for, why it's necessary, and how the (M2M) application or a human is expected to make use of it. > > I really like the format, but I have two requests: > > Can you use line terminations to separate links rather than commas? > That's going to be easier for me to process (in unix tools for example) and > display. I know that the link header uses commas, but that is intended for > a single HTTP header. In a file format, this is less important. > > I wouldn't want to do that, we actually prefer to stick with the comma. > When this is displayed to a human at some point, the display can always add > terminations. > Or otherwise reformat it, e.g. into a table. I also feel the syntax should match HTTP unless there's a compelling reason within CoAP to deviate from this. > > > Can you use UTF-8 rather than ASCII? The only cost being that clients > need to be able to cope with having the high bit set in each octet. The > cost to a parser can be quite small and I think that you'll find that this > will save you a lot of awkward questions. > > Now this is a very interesting idea, which will probably save us lots of > pain later. I will make a ticket. > OK. I wonder if we should do the same with the URI options that carry text. (Actually, we have to, at least for URI-Query, if we intend to support search for UTF-8 parameter values.) > > The 'rel'/'n' stuff is tricky. > > > > Keying on 'n' sounds dangerous as it is currently defined. The fact that > it is both (or variably) human readable and semantically significant is an > overloading that could cause problems. > > > > For one, 'n' and 'title' [RFC5988] seem very similar. Maybe the human > readable capability is better left to 'title'. It also punts on the other > human-readable concerns, like language tagging. > > I like this suggestion. We should instead use title for these human > readable uses. > > With human-readable concerns dealt with, that leaves 'n' with a single > purpose... If it is needed. > > n is meant to be a semantic name, used for a machine to find a resource to > use, e.g. "TemperatureC". This would indeed leave it for a single purpose, > which is good. > Consistent with what I just proposed; agreed. > > > > 'rel' might be used to provide typing in the way that is compatible with > 'n'. The form that this takes might be a little different. And from > .well-known it is difficult because the context of .well-known is somewhat > poorly understood. > > > > For instance, a light sensor could provide a .well-known with a link > maybe like... > > > > ,rel=sensor-state > > > > The .well-known resource is about the server; the sensor state resource > is related to the .well-known resource in a specific way. > > For this I like the suggestion from Peter on the CoRE list, which is to > define that the context is coap://authority and we use a new relation type > "hosts". > > > > > That doesn't work that well for devices with multiple sensors; so having > a separate disambiguation function is useful. The URL does that. The title > can be used to provide user-consumable clues. For automatons, you need > something less fuzzy than title and more definite than a URI (potentially > something across different servers). > > > > In my experience, having a domain-specific namespace for identifying the > type of resource is the easiest solution. Something defined by the server > with scoping for the server. I think that this is what you intended for the > 'n' parameter. Though in this case it might be better to find a better > label for the parameter. "name" is something with a lot of semantic > baggage. Maybe you can consider using 'id' for this purpose (in light of my > above comment). > > > > ;id='current';rel=sensor;title="Current Temperature" > > ;id='hourly';rel=sensor;title="Temperate Average (Hourly)" > > > > This is a tricky problem. I expect that you will need to explore your > options and provide a good amount of explanatory text on the topic when you > finally decide. Each type-/name-/identifier-class parameter needs a > description that identifies scope, domain and all that sort of stuff. I > don't think that there is enough there yet. > I think it would be inappropriate to use the "rel" attribute with a value "sensor"; the server does not have a "sensor" relation to the resource "/temp/now". "/temp/now" is a resource with role (class, type) "sensor". Adding a new link parameter would be appropriate, if it is necessary to do this. In fact, can "n" (which is also pretty vague) go away if we add two new parameters: u -- units, a semantic identifier like "degC" r -- role, a semantic identifier like "temperature" We'll need to discuss this some more, maybe more examples will be the best > for nailing down the best uses for the extensions. > > Regards, > Zach > > > > > --Martin > > > > (Feel free to forward this to the core WG, if you think that this is > useful.) > > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > --001636c9239ecdac2f0495a6404d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    On Mon, Nov 22, 2010 at 6:38 AM, Zach Shelby <zach@sensinode.com= > wrote:
    > 'id' seems a little strange. =A0Unless the scope of the identi= fier is something other than the server, the URL provides enough informatio= n for someone to identify a resource. =A0Does this have a different scope t= han the one server? =A0Or is the intent to convey information on from diffe= rent identification domains?

    We were originally thinking ID would have global scope, something like a UU= ID. However in Beijing it was suggested to instead give it server scope and= use it as a kind of index. For example you might have three different host= ed resources with the semantic name "TemperatureC". The index wou= ld be used to give each an index on the server.

    This is really unconvincing.=A0 "a kind of index= "?=A0 How is the application supposed to use that index?

    I don&= #39;t think we should include id without a better understanding of what it&= #39;s for, why it's necessary, and how the (M2M) application or a human= is expected to make use of it.
    =A0
    > I really like the format, but I have two requests:
    > =A0Can you use line terminations to separate links rather than commas?= =A0That's going to be easier for me to process (in unix tools for exam= ple) and display. =A0I know that the link header uses commas, but that is i= ntended for a single HTTP header. =A0In a file format, this is less importa= nt.

    I wouldn't want to do that, we actually prefer to stick with the comma.= When this is displayed to a human at some point, the display can always ad= d terminations.

    Or otherwise reformat it, e.g. int= o a table.=A0 I also feel the syntax should match HTTP unless there's a= compelling reason within CoAP to deviate from this.

    > =A0Can you use UTF-8 rather than ASCII? =A0The only cost being that cl= ients need to be able to cope with having the high bit set in each octet. = =A0The cost to a parser can be quite small and I think that you'll find= that this will save you a lot of awkward questions.

    Now this is a very interesting idea, which will probably save us lots of pa= in later. I will make a ticket.

    OK.=A0 I wonder if= we should do the same with the URI options that carry text.=A0 (Actually, = we have to, at least for URI-Query, if we intend to support search for UTF-= 8 parameter values.)
    =A0
    > The 'rel'/'n' stuff is tricky.
    >
    > Keying on 'n' sounds dangerous as it is currently defined. =A0= The fact that it is both (or variably) human readable and semantically sign= ificant is an overloading that could cause problems.
    >
    > For one, 'n' and 'title' [RFC5988] seem very similar. = =A0Maybe the human readable capability is better left to 'title'. = =A0It also punts on the other human-readable concerns, like language taggin= g.

    I like this suggestion. We should instead use title for these human readabl= e uses.

    > With human-readable concerns dealt with, that leaves 'n' with = a single purpose... If it is needed.

    n is meant to be a semantic name, used for a machine to find a resource to = use, e.g. "TemperatureC". This would indeed leave it for a single= purpose, which is good.

    Consistent with what I ju= st proposed; agreed.
    =A0
    >
    > 'rel' might be used to provide typing in the way that is compa= tible with 'n'. =A0The form that this takes might be a little diffe= rent. =A0And from .well-known it is difficult because the context of .well-= known is somewhat poorly understood.
    >
    > For instance, a light sensor could provide a .well-known with a link m= aybe like...
    >
    > =A0</light>,rel=3Dsensor-state
    >
    > The .well-known resource is about the server; the sensor state resourc= e is related to the .well-known resource in a specific way.

    For this I like the suggestion from Peter on the CoRE list, which is to def= ine that the context is coap://authority and we use a new relation type &qu= ot;hosts".

    >
    > That doesn't work that well for devices with multiple sensors; so = having a separate disambiguation function is useful. =A0The URL does that. = =A0The title can be used to provide user-consumable clues. =A0For automaton= s, you need something less fuzzy than title and more definite than a URI (p= otentially something across different servers).
    >
    > In my experience, having a domain-specific namespace for identifying t= he type of resource is the easiest solution. =A0Something defined by the se= rver with scoping for the server. =A0I think that this is what you intended= for the 'n' parameter. =A0Though in this case it might be better t= o find a better label for the parameter. =A0"name" is something w= ith a lot of semantic baggage. =A0Maybe you can consider using 'id'= for this purpose (in light of my above comment).
    >
    > =A0</temp/now>;id=3D'current';rel=3Dsensor;title=3D"= ;Current Temperature"
    > =A0</temp/hr>;id=3D'hourly';rel=3Dsensor;title=3D"T= emperate Average (Hourly)"
    >
    > This is a tricky problem. =A0I expect that you will need to explore yo= ur options and provide a good amount of explanatory text on the topic when = you finally decide. =A0Each type-/name-/identifier-class parameter needs a = description that identifies scope, domain and all that sort of stuff. =A0I = don't think that there is enough there yet.

    I think it would be inappropriate to use the "re= l" attribute with a value "sensor"; the server does not have= a "sensor" relation to the resource "/temp/now".=A0 &q= uot;/temp/now" is a resource with role (class, type) "sensor"= ;.=A0 Adding a new link parameter would be appropriate, if it is necessary = to do this.

    In fact, can "n" (which is also pretty vague) go away if we a= dd two new parameters:

    u -- units, a semantic identifier like "= degC"

    r -- role, a semantic identifier like "temperature&q= uot;

    We'll need to discuss this some more, maybe more examples will be the b= est for nailing down the best uses for the extensions.

    Regards,
    Zach

    >
    > --Martin
    >
    > (Feel free to forward this to the core WG, if you think that this is u= seful.)

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


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


    --001636c9239ecdac2f0495a6404d-- From klaus.hartke@googlemail.com Mon Nov 22 08:08:51 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 644F93A6A98 for ; Mon, 22 Nov 2010 08:08:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CCKI+9ug7qhO for ; Mon, 22 Nov 2010 08:08:50 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 434393A6A7E for ; Mon, 22 Nov 2010 08:08:50 -0800 (PST) Received: by bwz12 with SMTP id 12so6719785bwz.31 for ; Mon, 22 Nov 2010 08:09:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; bh=+1rGpJSP+c2MpiY1CVJrQgX3mUnTFLC8WjTLUIEQW6A=; b=GrZ2aAxaw3gtIBOObZn3nLLgRilpi7YK6QfXxw5hvSszFppLOVoxgMn9hGx+Hw6jXL bKtDJRN1jdrALaxpMNrUjs++OGJnVSc7MzNm/2Eo5Zz+EqeIDwA6ttiTXnOdrF4BXqW0 P5cL7n9Q3U8wSw5vhp11dAc812pVjKs1Wm/Ro= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=etoYRjQHkS/+vusEKyxjzswZ34obWHqJhx7QsQWWZaVc5V9rdu1ERpPO9tF4jZCRFI iSogz809nx0qAhIR4kx7KYtMjTBUmq/SGr1M/0P7Bl7bwcRXotnvE2rVehUk3Px8k9Ex 9aUTNVqSerMpgbqY/jbqCK/ZlV0KB0ujOj9Iw= MIME-Version: 1.0 Received: by 10.204.127.94 with SMTP id f30mr5603563bks.1.1290442176212; Mon, 22 Nov 2010 08:09:36 -0800 (PST) Sender: klaus.hartke@googlemail.com Received: by 10.204.121.134 with HTTP; Mon, 22 Nov 2010 08:09:36 -0800 (PST) In-Reply-To: References: <1909899D-43E8-4C00-B957-6787468B4CDB@sensinode.com> Date: Mon, 22 Nov 2010 17:09:36 +0100 X-Google-Sender-Auth: RfRDmWufdiR8ZxgWh1ZXVTJFCvc Message-ID: From: Klaus Hartke To: core Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [core] Proxy and server on the same port X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 16:08:51 -0000 Peter Bigot wrote: > Back on 23Oct, I sent an email entitled "Proxy versus Gateway" that propo= sed > clarifying some terminology.=A0 Nobody responded, but I see it's become t= icket > #72.=A0 I would like to see some discussion before taking on any > responsibilities associated with that ticket. I think it makes a lot of sense to distinguish between end-points that act on behalf of a client and those that act on behalf of a server. Not sure what needs to be discussed (apart maybe from the actual terms used for the two roles). > If what I proposed is to be adopted, much of this confusion may go away. > Putting a proxy on the same port as a server is unnecessarily confusing i= n > that situation.=A0 They really are completely different applications, use= d in > different ways. Exactly. My proposal makes the intended meaning of a request explicit and leaves no room for uncertainty, regardless of whether there is a proxy and server on the same port or not. Klaus From noblomov@gmail.com Mon Nov 22 07:11:38 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D61A03A6A97 for ; Mon, 22 Nov 2010 07:11:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IC4bpDX1xSQ3 for ; Mon, 22 Nov 2010 07:11:35 -0800 (PST) Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [217.70.183.194]) by core3.amsl.com (Postfix) with ESMTP id 5ADB63A691A for ; Mon, 22 Nov 2010 07:11:34 -0800 (PST) X-Originating-IP: 217.70.178.42 Received: from mfilter2-d.gandi.net (mfilter2-d.gandi.net [217.70.178.42]) by relay2-d.mail.gandi.net (Postfix) with ESMTP id BE09F2251A6 for ; Mon, 22 Nov 2010 16:12:18 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter2-d.gandi.net Received: from relay2-d.mail.gandi.net ([217.70.183.194]) by mfilter2-d.gandi.net (mfilter2-d.gandi.net [217.70.178.42]) (amavisd-new, port 10024) with ESMTP id HyqMwn35ucOX for ; Mon, 22 Nov 2010 16:12:16 +0100 (CET) X-Originating-IP: 209.85.216.44 Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) (Authenticated sender: nicosmtp@sen.se) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id CBF66225149 for ; Mon, 22 Nov 2010 16:12:15 +0100 (CET) Received: by qwb7 with SMTP id 7so2447065qwb.31 for ; Mon, 22 Nov 2010 07:12:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=HLH1Xb1K/y7lCCu+MDHUrQq5WnlRZt9F0ocnUZm5ZoA=; b=jMSGmArU85IIlt6CPdZ+fGwm008SJxI/YWegt09FngU3qVwANnPSt9vFYZFaLHXrY9 e7BLWfFjKXORRk/DHvBQco8JjngTAaEs3OSsIEzeWRnEk/M5NZqLwqU0Sqxyyv0kgdye Krzi2zIw1sUStgffWXh32tbuazYs3gtu2ohAA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=lQ9B/SkC7i3qtmZvpQRe18QrhVYYKe6Nod+HGUPKXjizOkmBqMWm8Mce8b4G+3Eafo cxi9inzlvaQiX8ugJoAzEc+DL+4MKXh8A8T4GkN+ygZQv6WflNQm2fH6Z9HawxtqyZgY bv+9pP+kYW4r5y4rgKa3mKocTVHNZDV1ycypA= MIME-Version: 1.0 Received: by 10.229.227.8 with SMTP id iy8mr5214794qcb.36.1290438734554; Mon, 22 Nov 2010 07:12:14 -0800 (PST) Received: by 10.229.91.85 with HTTP; Mon, 22 Nov 2010 07:12:14 -0800 (PST) In-Reply-To: <201011221028.30662.mab@comnets.uni-bremen.de> References: <201011221028.30662.mab@comnets.uni-bremen.de> Date: Mon, 22 Nov 2010 16:12:14 +0100 Message-ID: From: noblomov To: Markus Becker Content-Type: multipart/alternative; boundary=00163630faa960a4b10495a5aeca X-Mailman-Approved-At: Mon, 22 Nov 2010 08:34:11 -0800 Cc: core@ietf.org Subject: Re: [core] Size of CoAP implementation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 15:14:16 -0000 --00163630faa960a4b10495a5aeca Content-Type: text/plain; charset=ISO-8859-1 Hi, Could you specify exactly what parts include these implementations ? CoAP only, or CoAP and 6lowpan/uIP stack and radio stack, routing, etc... ? Thanks, N. On Mon, Nov 22, 2010 at 10:28 AM, Markus Becker wrote: > Hi, > > Carsten asked me to give some data points on how big CoAP is right now on > constrained nodes (here: TinyOS, TelosB). > > As a reference: Simple TinyOS application with Radio stack: > (RadioCountToLeds) > 11890 bytes in ROM > 329 bytes in RAM > > Sample TinyOS blip 6LoWPAN application with a shell and echo service > (UDPEcho, not optimized aka ntop6 support included, debugging): > 29474 bytes in ROM > 5062 bytes in RAM > (same, ntop6 support removed, debugging) > 28794 bytes in ROM > 5062 bytes in RAM > > Simple CoAP server based on Olaf's libcoap and TinyOS blip 6lowpan stack > (no sensors pulled in, ntop6 support removed, NO debugging) > 31866 bytes in ROM > 5492 bytes in RAM > > Simple CoAP server based on Olaf's libcoap and TinyOS blip 6lowpan stack > (not optimized, 2 async sensor resources being served, debugging): > 40730 bytes in ROM > 5802 bytes in RAM > > As a reference: TelosB motes are equipped with 48k ROM, 10k RAM > > Markus > > > ------------------------------------------------ > | Dipl.-Ing. Markus Becker > | Communication Networks > | Mobile Research Center > | 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 > ------------------------------------------------ > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --00163630faa960a4b10495a5aeca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

    Could you specify exactly what parts include these i= mplementations ?=A0
    CoAP only, or CoAP and 6lowpan/uIP stack and = radio stack, routing, etc... ?

    Thanks,

    N.

    On Mon, Nov 22, 2010 at= 10:28 AM, Markus Becker <mab@comnets.uni-bremen.de> wrote:
    Hi,

    Carsten asked me to give some data points on how big CoAP is right now on constrained nodes (here: TinyOS, TelosB).

    As a reference: Simple TinyOS application with Radio stack:
    (RadioCountToLeds)
    =A0 =A0 =A0 =A0 =A0 11890 bytes in ROM
    =A0 =A0 =A0 =A0 =A0 =A0 329 bytes in RAM

    Sample TinyOS blip 6LoWPAN application with a shell and echo service
    (UDPEcho, not optimized aka ntop6 support included, debugging):
    =A0 =A0 =A0 =A0 =A0 29474 bytes in ROM
    =A0 =A0 =A0 =A0 =A0 =A05062 bytes in RAM
    (same, ntop6 support removed, debugging)
    =A0 =A0 =A0 =A0 =A0 28794 bytes in ROM
    =A0 =A0 =A0 =A0 =A0 =A05062 bytes in RAM

    Simple CoAP server based on Olaf's libcoap and TinyOS blip 6lowpan stac= k
    (no sensors pulled in, ntop6 support removed, NO debugging)
    =A0 =A0 =A0 =A0 =A0 31866 bytes in ROM
    =A0 =A0 =A0 =A0 =A0 =A05492 bytes in RAM

    Simple CoAP server based on Olaf's libcoap and TinyOS blip 6lowpan stac= k
    (not optimized, 2 async sensor resources being served, debugging):
    =A0 =A0 =A0 =A0 =A0 40730 bytes in ROM
    =A0 =A0 =A0 =A0 =A0 =A05802 bytes in RAM

    As a reference: TelosB motes are equipped with 48k ROM, 10k RAM

    Markus


    ------------------------------------------------
    | Dipl.-Ing. Markus Becker
    | Communication Networks
    | Mobile Research Center
    | TZI - Center for Computing Technologies
    | University Bremen
    | Germany
    ------------------------------------------------
    | web: http://www.comnets.uni-bremen.de/~mab/
    | mailto: mab@comnets.uni-brem= en.de
    | telephone: +49 421 218 62379
    | building: NW1 room: N2260
    ------------------------------------------------
    _______________________________________________
    core mailing list
    core@ietf.org
    ht= tps://www.ietf.org/mailman/listinfo/core

    --00163630faa960a4b10495a5aeca-- From pab@peoplepowerco.com Mon Nov 22 08:53:00 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB5C93A6A9B for ; Mon, 22 Nov 2010 08:53:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[AWL=-0.048, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SARE_RMML_Stock10=0.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZ6sO-7wtyR2 for ; Mon, 22 Nov 2010 08:53:00 -0800 (PST) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id 0A0DE3A6AA4 for ; Mon, 22 Nov 2010 08:52:59 -0800 (PST) Received: by pxi6 with SMTP id 6so1874543pxi.31 for ; Mon, 22 Nov 2010 08:53:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.97.13 with SMTP id j13mr4464281fan.146.1290444834580; Mon, 22 Nov 2010 08:53:54 -0800 (PST) Received: by 10.223.70.198 with HTTP; Mon, 22 Nov 2010 08:53:54 -0800 (PST) In-Reply-To: References: <1909899D-43E8-4C00-B957-6787468B4CDB@sensinode.com> Date: Mon, 22 Nov 2010 10:53:54 -0600 Message-ID: From: Peter Bigot To: Klaus Hartke Content-Type: multipart/alternative; boundary=20cf3054a615f814f80495a71938 Cc: core Subject: Re: [core] Proxy and server on the same port X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 16:53:01 -0000 --20cf3054a615f814f80495a71938 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Nov 22, 2010 at 10:09 AM, Klaus Hartke wrote: > Peter Bigot wrote: > > Back on 23Oct, I sent an email entitled "Proxy versus Gateway" that > proposed > > clarifying some terminology. Nobody responded, but I see it's become > ticket > > #72. I would like to see some discussion before taking on any > > responsibilities associated with that ticket. > > I think it makes a lot of sense to distinguish between end-points that > act on behalf of a client and those that act on behalf of a server. > Not sure what needs to be discussed (apart maybe from the actual terms > used for the two roles). > Just that I proposed completely rewriting section five to get CoAP to use specific terms in the way I described in my email, which would result in a significant change (clarification) to what "proxy" means, and a separation of it from the concept of a "cache". Your comment above is not the same thing, and since nobody else has commented I don't think my email should be the basis of a ticket. In what I proposed, a client is specifically configured to use a (single) proxy, and that proxy is providing specific enhanced services on behalf of the client. With that model it makes little sense to accommodate placing the proxy at the same end-point (port) as a normal server. However, if there's no buy-in for that change, and there's some compelling reason why we should accommodate two applications at a single port, I suppose a set of rules to use UriScheme values as a cue to whether a request might have been intended for a proxy or a server could be made to work. "Don't do that" seems like a better approach, in my opinion. Peter --20cf3054a615f814f80495a71938 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    On Mon, Nov 22, 2010 at 10:09 AM, Klaus Hartke <= span dir=3D"ltr"><hartke@tzi.org&g= t; wrote:
    Peter Bigot wrote:
    > Back on 23Oct, I sent an email entitled "Proxy versus Gateway&quo= t; that proposed
    > clarifying some terminology.=A0 Nobody responded, but I see it's b= ecome ticket
    > #72.=A0 I would like to see some discussion before taking on any
    > responsibilities associated with that ticket.

    I think it makes a lot of sense to distinguish between end-points tha= t
    act on behalf of a client and those that act on behalf of a server.
    Not sure what needs to be discussed (apart maybe from the actual terms
    used for the two roles).

    Just that I proposed comp= letely rewriting section five to get CoAP to use specific terms in the way = I described in my email, which would result in a significant change (clarif= ication) to what "proxy" means, and a separation of it from the c= oncept of a "cache".=A0 Your comment above is not the same thing,= and since nobody else has commented I don't think my email should be t= he basis of a ticket.

    In what I proposed, a client is specifically configured to use a (singl= e) proxy, and that proxy is providing specific enhanced services on behalf = of the client.=A0 With that model it makes little sense to accommodate plac= ing the proxy at the same end-point (port) as a normal server.

    However, if there's no buy-in for that change, and there's some= compelling reason why we should accommodate two applications at a single p= ort, I suppose a set of rules to use UriScheme values as a cue to whether a= request might have been intended for a proxy or a server could be made to = work.=A0 "Don't do that" seems like a better approach, in my = opinion.

    Peter
    --20cf3054a615f814f80495a71938-- From klaus.hartke@googlemail.com Mon Nov 22 09:21:43 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E63963A6AE4 for ; Mon, 22 Nov 2010 09:21:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, SARE_RMML_Stock10=0.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hzUxcye6302U for ; Mon, 22 Nov 2010 09:21:41 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 186F03A6AE2 for ; Mon, 22 Nov 2010 09:21:40 -0800 (PST) Received: by bwz12 with SMTP id 12so6800124bwz.31 for ; Mon, 22 Nov 2010 09:22:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; bh=PodQevFMXduQhPv0fMY8K5+GXYoARl3MVVmKMvXhkRA=; b=MtbiNoyqqa9FlKk96ZUdDKoVn45+gQjZ94x0Smruxo6xVUJQFt/oPe2u7BCylltyDe IBtHShnMTR4UDWC0I7NkMIaFA54RfqfDnnTFkmQgi4/Zcxbq1GacMwcK+5TV7uuJzaZQ 5b6rCv+KNC4nEJS/CRSTYXkh5QOv+9l8u7Xio= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=kTpg7Eg+0SdAD8BwH2JqqAg/ilSyKVaoZEPR+OYV2x8NCDeEkVpvjctjI+G7ySGd1J y1Lylc536o/qLrtXk4M0m2PYSyywSeQXQObeiu2dFOMDQaizfsv7xqEG3r/g1Ej5/4Lk NwIVbQ6AAufk29v/0nQiX7RRe/cI8lqozumx4= MIME-Version: 1.0 Received: by 10.204.119.133 with SMTP id z5mr5651645bkq.82.1290446549528; Mon, 22 Nov 2010 09:22:29 -0800 (PST) Sender: klaus.hartke@googlemail.com Received: by 10.204.121.134 with HTTP; Mon, 22 Nov 2010 09:22:28 -0800 (PST) In-Reply-To: References: <1909899D-43E8-4C00-B957-6787468B4CDB@sensinode.com> Date: Mon, 22 Nov 2010 18:22:28 +0100 X-Google-Sender-Auth: MlQLBxJfyns1hiIhV-jX4DD8vPI Message-ID: From: Klaus Hartke To: core Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [core] Proxy and server on the same port X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 17:21:43 -0000 Peter Bigot wrote: >> I think it makes a lot of sense to distinguish between end-points that >> act on behalf of a client and those that act on behalf of a server. >> Not sure what needs to be discussed (apart maybe from the actual terms >> used for the two roles). > > Just that I proposed completely rewriting section five to get CoAP to use > specific terms in the way I described in my email, which would result in = a > significant change (clarification) to what "proxy" means, and a separatio= n > of it from the concept of a "cache".=A0 Your comment above is not the sam= e > thing, and since nobody else has commented I don't think my email should = be > the basis of a ticket. I thought my comment above would capture the essence of your email, but apparently it didn't. So here's an attempt at a more complete summary of your email: * Intermediary CoAP end-points act as both a client and a server in order to forward, with possible translation, requests and responses. * A proxy is an intermediary selected by a client. A client can delegate all CoAP requests it can't do itself to a proxy. Configuration of this proxy for a particular node is an administrative function outside the scope of CoAP. * A gateway (a.k.a., reverse proxy, big brother, ...) is an intermediary imposed by the origin server to support sleeping nodes or perform any other role that might be hidden behind the authority part of a URI. * Caching in turn is a function that may be paired with a proxy or with a gateway, but is not inherently coupled to either one. Please correct me if I'm missing something essential. > In what I proposed, a client is specifically configured to use a (single) > proxy, and that proxy is providing specific enhanced services on behalf o= f > the client.=A0 With that model it makes little sense to accommodate placi= ng > the proxy at the same end-point (port) as a normal server. > > However, if there's no buy-in for that change, and there's some compellin= g > reason why we should accommodate two applications at a single port, I > suppose a set of rules to use UriScheme values as a cue to whether a requ= est > might have been intended for a proxy or a server could be made to work. > "Don't do that" seems like a better approach, in my opinion. There are two things: 1. Does it make sense to run a proxy and a server on the same port? The answer is probably: No. 2. What to do when a client thinks an end-point is a server when it's actually a proxy? The solution is to have the client say what it thinks, so that its wrong assumption can be pointed out by the recipient. Klaus From pab@peoplepowerco.com Mon Nov 22 09:52:36 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC4293A6AE0 for ; Mon, 22 Nov 2010 09:52:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SARE_RMML_Stock10=0.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CqAR7jmbP1FR for ; Mon, 22 Nov 2010 09:52:35 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 60CC63A69F4 for ; Mon, 22 Nov 2010 09:52:35 -0800 (PST) Received: by vws7 with SMTP id 7so1198293vws.31 for ; Mon, 22 Nov 2010 09:53:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.104.68 with SMTP id n4mr2858156fao.127.1290448410393; Mon, 22 Nov 2010 09:53:30 -0800 (PST) Received: by 10.223.70.198 with HTTP; Mon, 22 Nov 2010 09:53:30 -0800 (PST) In-Reply-To: References: <1909899D-43E8-4C00-B957-6787468B4CDB@sensinode.com> Date: Mon, 22 Nov 2010 11:53:30 -0600 Message-ID: From: Peter Bigot To: Klaus Hartke Content-Type: multipart/alternative; boundary=001636c9239e1a3e450495a7ef28 Cc: core Subject: Re: [core] Proxy and server on the same port X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 17:52:36 -0000 --001636c9239e1a3e450495a7ef28 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Nov 22, 2010 at 11:22 AM, Klaus Hartke wrote: > Peter Bigot wrote: > >> I think it makes a lot of sense to distinguish between end-points that > >> act on behalf of a client and those that act on behalf of a server. > >> Not sure what needs to be discussed (apart maybe from the actual terms > >> used for the two roles). > > > > Just that I proposed completely rewriting section five to get CoAP to use > > specific terms in the way I described in my email, which would result in > a > > significant change (clarification) to what "proxy" means, and a > separation > > of it from the concept of a "cache". Your comment above is not the same > > thing, and since nobody else has commented I don't think my email should > be > > the basis of a ticket. > > I thought my comment above would capture the essence of your email, > but apparently it didn't. Sorry, I didn't read it that way. > So here's an attempt at a more complete > summary of your email: > > * Intermediary CoAP end-points act as both a client and a server in > order to forward, with possible translation, requests and responses. > OK. * A proxy is an intermediary selected by a client. A client can > delegate all CoAP requests it can't do itself to a proxy. > Configuration of this proxy for a particular node is an administrative > function outside the scope of CoAP. > Yes. * A gateway (a.k.a., reverse proxy, big brother, ...) is an > intermediary imposed by the origin server to support sleeping nodes or > perform any other role that might be hidden behind the authority part > of a URI. > Almost; the origin server may be unaware of the presence of a gateway. The network may impose the gateway. * Caching in turn is a function that may be paired with a proxy or > with a gateway, but is not inherently coupled to either one. > Yes. > Please correct me if I'm missing something essential. > Not at first glance, So you do agree with what was in that email? I assumed the complete lack of response meant nobody thought it relevant. > > In what I proposed, a client is specifically configured to use a > (single) > > proxy, and that proxy is providing specific enhanced services on behalf > of > > the client. With that model it makes little sense to accommodate placing > > the proxy at the same end-point (port) as a normal server. > > > > However, if there's no buy-in for that change, and there's some > compelling > > reason why we should accommodate two applications at a single port, I > > suppose a set of rules to use UriScheme values as a cue to whether a > request > > might have been intended for a proxy or a server could be made to work. > > "Don't do that" seems like a better approach, in my opinion. > > There are two things: > > 1. Does it make sense to run a proxy and a server on the same port? > > The answer is probably: No. > Good. 2. What to do when a client thinks an end-point is a server when it's > actually a proxy? > Ah. I lost the context from the earlier parts of the thread, and assumed your proposal was a way to allow dual-use. In fact, your rules seem to be a complete workable solution that does allow dual use. Nice. That's not what raised my hackles. The solution is to have the client say what it thinks, so that its > wrong assumption can be pointed out by the recipient. > That is a good solution. But in the details, I think it would be more clear if the client does say what it thinks (that it's talking with a proxy), rather than creating complex rules on how to interpret Uri-Scheme to infer that it thinks it's talking with a proxy. So use a new option named Uri-Proxy with no value, the presence/absence of which indicates the client's expectations. Don't overload Uri-Scheme to mean something weird that could conflict with future use, e.g. putting a coap and a coapm (multicast) service on the same port. Change Uri-Scheme to Uri-Proxy in your proposal and you've got a solution that allows disambiguation while at the same time allowing both functions to occur on the same port and not muddying what Uri-Scheme means. That's the sort of approach I like: one technique that solves multiple problems without introducing new ones. Barring some undiscovered flaw, I'd support that. > > Klaus > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --001636c9239e1a3e450495a7ef28 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    On Mon, Nov 22, 2010 at 11:22 AM, Klaus Hartke <= span dir=3D"ltr"><hartke@tzi.org&g= t; wrote:
    Peter Bigot wrote:
    >> I think it makes a lot of sense to distinguish between end-points = that
    >> act on behalf of a client and those that act on behalf of a server= .
    >> Not sure what needs to be discussed (apart maybe from the actual t= erms
    >> used for the two roles).
    >
    > Just that I proposed completely rewriting section five to get CoAP to = use
    > specific terms in the way I described in my email, which would result = in a
    > significant change (clarification) to what "proxy" means, an= d a separation
    > of it from the concept of a "cache".=A0 Your comment above i= s not the same
    > thing, and since nobody else has commented I don't think my email = should be
    > the basis of a ticket.

    I thought my comment above would capture the essence of your email, but apparently it didn't.

    Sorry,=A0 I didn't r= ead it that way.
    =A0
    So here's an attempt at a more complete
    summary of your email:

    * Intermediary CoAP end-points act as both a client and a server in
    order to forward, with possible translation, requests and responses.

    OK.

    * A proxy is an intermediary selected by a client. A client can
    delegate all CoAP requests it can't do itself to a proxy.
    Configuration of this proxy for a particular node is an administrative
    function outside the scope of CoAP.

    Yes.

    <= /div>
    * A gateway (a.k.a., reverse proxy, big brother, ...) is an
    intermediary imposed by the origin server to support sleeping nodes or
    perform any other role that might be hidden behind the authority part
    of a URI.

    =A0Almost; the origin server may be unaw= are of the presence of a gateway.=A0 The network may impose the gateway.
    * Caching in turn is a function that may be paired with a proxy or
    with a gateway, but is not inherently coupled to either one.

    Yes.
    =A0
    Please correct me if I'm missing something essential.
    <= div>
    Not at first glance,

    So you do agree with what was in that e= mail?=A0 I assumed the complete lack of response meant nobody thought it re= levant.
    =A0
    > In what I proposed, a client is specifically configured to use a (sing= le)
    > proxy, and that proxy is providing specific enhanced services on behal= f of
    > the client.=A0 With that model it makes little sense to accommodate pl= acing
    > the proxy at the same end-point (port) as a normal server.
    >
    > However, if there's no buy-in for that change, and there's som= e compelling
    > reason why we should accommodate two applications at a single port, I<= br> > suppose a set of rules to use UriScheme values as a cue to whether a r= equest
    > might have been intended for a proxy or a server could be made to work= .
    > "Don't do that" seems like a better approach, in my opin= ion.

    There are two things:

    1. Does it make sense to run a proxy and a server on the same port?

    The answer is probably: No.

    Good.

    2. What to do when a client thinks an end-point is a server when it's actually a proxy?

    Ah.=A0 I lost the context from t= he earlier parts of the thread, and assumed your proposal was a way to allo= w dual-use. =A0In fact, your rules seem to be a complete workable solution = that does allow dual use. =A0Nice. =A0That's not what raised my hackles= .

    The solution is to have the client say what it thinks, so that its
    wrong assumption can be pointed out by the recipient.
    =
    That is a good solution.=A0 But in the details, I think it would be mor= e clear if the client does say what it thinks (that it's talking with a= proxy), rather than creating complex rules on how to interpret Uri-Scheme = to infer that it thinks it's talking with a proxy.=A0 So use a new opti= on named Uri-Proxy with no value, the presence/absence of which indicates t= he client's expectations.=A0 Don't overload Uri-Scheme to mean some= thing weird that could conflict with future use, e.g. putting a coap and a = coapm (multicast) service on the same port.

    Change Uri-Scheme to Uri-Proxy in your proposal and you've got a so= lution that allows disambiguation while at the same time allowing both func= tions to occur on the same port and not muddying what Uri-Scheme means. =A0= That's the sort of approach I like: one technique that solves multiple = problems without=A0introducing new ones. =A0Barring some undiscovered flaw,= I'd support that.
    =A0

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

    --001636c9239e1a3e450495a7ef28-- From klaus.hartke@googlemail.com Mon Nov 22 10:26:54 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6254A3A687F for ; Mon, 22 Nov 2010 10:26:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zNEqd6kNvyTu for ; Mon, 22 Nov 2010 10:26:50 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id F383B28C14F for ; Mon, 22 Nov 2010 10:26:49 -0800 (PST) Received: by bwz12 with SMTP id 12so6867476bwz.31 for ; Mon, 22 Nov 2010 10:27:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; bh=W9QHEXdLy35eWWBiRVYk+PcdZiKJeBmcXYhv8bXklFY=; b=RCRg8Toei3fqrFOsz0ehYRTRNqZlB39kuMax3tibwuYd4MitJ5bUG6X56ptkaYzGhX WytGs9GAJ2uKEUz3L1nENKvNfdxZJXZ/1/Vt1+lNtTQntvpODJt1BvB7lOEio2yOEcrF Vd+9ZQzodaNDBmNC3MrAo9lrtT0sJou8VTtBg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=FX0RNZtoIWDG+2GCtcDMUlbHxuIvupVlDagqbqNHfXvtZ64wcklUqHpiQufY+4qQbH ndTbYuJc3WSXae0qrhr6BUrBsl2o3aXvq6g86y4qnu+XizpLomAGEYn0agGi5Ffx0kKK C5wvmgvngV/8HT4i1WgfuhWcgDtKhqomxnXVU= MIME-Version: 1.0 Received: by 10.204.127.94 with SMTP id f30mr5866927bks.1.1290450463424; Mon, 22 Nov 2010 10:27:43 -0800 (PST) Sender: klaus.hartke@googlemail.com Received: by 10.204.121.134 with HTTP; Mon, 22 Nov 2010 10:27:43 -0800 (PST) In-Reply-To: References: <1909899D-43E8-4C00-B957-6787468B4CDB@sensinode.com> Date: Mon, 22 Nov 2010 19:27:43 +0100 X-Google-Sender-Auth: -t-Wg7KvgtlYrP07iDSTfOX0Ap0 Message-ID: From: Klaus Hartke To: core Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [core] Proxy and server on the same port X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 18:26:54 -0000 Peter Bigot wrote: > =A0Almost; the origin server may be unaware of the presence of a gateway.= =A0 The > network may impose the gateway. Oh, that's what "imposed by the network" means. Good. > So you do agree with what was in that email? Yes. That's why there's a ticket which consists of a link to your email. :-= ) > Change Uri-Scheme to Uri-Proxy in your proposal and you've got a solution > that allows disambiguation while at the same time allowing both functions= to > occur on the same port and not muddying what Uri-Scheme means. Works for me. I just know Zach's dislike for new options, and Uri-Scheme seemed to be used only in proxy (not gateway) scenarios so far. Klaus From mnot@mnot.net Mon Nov 22 15:53:24 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 047C528C155 for ; Mon, 22 Nov 2010 15:53:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.827 X-Spam-Level: X-Spam-Status: No, score=-104.827 tagged_above=-999 required=5 tests=[AWL=-2.228, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lsN3lMF74MVS for ; Mon, 22 Nov 2010 15:53:22 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by core3.amsl.com (Postfix) with ESMTP id 0F3C728C187 for ; Mon, 22 Nov 2010 15:53:21 -0800 (PST) Received: from chancetrain-lm.mnot.net (unknown [118.209.2.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 6AF6C22E253; Mon, 22 Nov 2010 18:54:10 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <708E8D43-2BE9-4983-9C75-B245062FF3BF@sensinode.com> Date: Tue, 23 Nov 2010 10:54:08 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <1F6BD491-B097-447E-8006-48E9EA3D3507@mnot.net> References: <708E8D43-2BE9-4983-9C75-B245062FF3BF@sensinode.com> To: Zach Shelby X-Mailer: Apple Mail (2.1082) Cc: "core Environments\) WG" Subject: Re: [core] Link Format document X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 23:53:24 -0000 It's very important to note that RFC5988 is *not* just about putting = link headers into HTTP; rather, it's a framework that's designed to = allow links to be serialised in various ways with equivalent semantics.=20= As such, syntactic compatibility is a nice-to-have, but not critical; = the only thing that I'd say is that inventing a syntax that's = almost-but-not-quite-like another probably isn't productive. OTOH semantic compatibility is very important; if you change the meaning = of links, or how they operate, it's probably not helpful to use the = framework in 5988. Regards, On 22/11/2010, at 11:21 PM, Zach Shelby wrote: > Peter, >=20 > I also agree that we don't quite have the ideal use of the link = relation concept yet, but are getting there. Consider that the first = version of the CoRE link format didn't use the relation concept at all, = in the last couple versions we have gotten much closer. But just because = we are re-using the link format from RFC5988, does not mean we are bound = to use exactly the same link relation semantics that were designed for = hypertext HTTP servers (nor does that necessarily even make sense). = However, I do find the link relation work done in RFC5988 to be useful = also in our domain to some extent, so we should try to apply what we can = to M2M.=20 >=20 > I wouldn't go quite as far as Peter's idea below though. For M2M these = descriptions need to be as compact as possible, nor can we expect = constrained device to traverse many links to find out simple information = about a resource. I do think we should improve the way we use rel=3D"" = for example, and the use of link-extensions can use improvement too. >=20 > On a related note, I also received really helpful feedback from Martin = Thomson on this same subject in Beijing. I will CC the list with some of = that discussion pretty soon. He has good ideas for improving the use of = rel=3D and how our link-extensions should be used.=20 >=20 > See some comments in-line: >=20 > On Nov 21, 2010, at 6:55 PM, Peter Bigot wrote: >=20 >> Either at the IETF session or in some email I can't easily find, = there was a specific question raised about exactly how the link = description is supposed to be used in CoAP that started me down a path = that led to the following comment. I've cc'd Mark Nottingham, author of = RFC5988 "Web Linking", in hopes he might have time to provide relevant = information to guide us. >>=20 >> My understanding of RFC5988 is it proposes a way to provide, in an = HTTP response header, information about (target) resources that are = related in (rel) some way to the (context) resource identified in the = original request. Other contexts can be specified through the anchor = parameter, but I expect this is unusual. >=20 > Yes, this is the basic concept of RFC5988. I agree that anchor will be = rare, as we point out in Section 2.1 of core-link-format-01. >=20 >>=20 >> In CoAP's link format document at = http://tools.ietf.org/html/draft-ietf-core-link-format, we are rather = mis-using this to provide a list of resources that are hosted on a = server. Technically, the context of the list items is the resource = which is the server itself ("coap://authority"), though we provide = access to it at "coap://authority/.well-known/core". >=20 > I wouldn't say we are misusing it, but that we are defining what the = context is by default. Section 2.1 explains that the CoRE link entries = are describing links to resources hosted on the server. The rel=3D = relation is defined to be "service" by default in Section 2.2 to = describe that the link is a service of the server. I do like your idea = here of explaining that the context is the URI coap://authority.=20 >=20 >> The problem is that, because the document containing links lists the = resources available on the server, we provide additional information = about specific resources in link parameters, rather than as link = descriptions. I now think that the roles served by the "d" and "sh" = extensions, and some uses of "n", should really be link descriptions = whose context is the target, target is the extension value, and rel is = the extension name. For example, rather than: >=20 > Link parameters are meant to provide further information about the = link. This is the purpose of the link-extensions defined in the CoRE = link format. In that way they are similar to the link-parameters defined = in RFC5988. =20 >=20 >> = n=3D"http://sweet.jpl.nasa.gov/2.0/phys.owl#Temperatu= re",sh=3D"/l"; >=20 > I do see what you are getting at here, however in Beijing we basically = decided to remove the Short URL "sh" parameter anyways. Furthermore, I = don't consider the way you are thinking about the Name "n" is quite = right. This is not meant to be a link (URL) to some document, but = instead is meant to be a semantic name or URI used as a semantic name. >=20 >> being one of the link descriptions at = coap://authority/.well-known/core, use consistent with RFC5988 would be = to provide: >>=20 >> = rel=3D"describedby"; >> rel=3D"alternate"; >=20 > You could do this, however it would be both inefficient and complex. I = think we can avoid this by using Name properly. Let's get back to that = in a separate mail with Marin's suggestions.=20 >=20 >>=20 >> as the set of link descriptions for = coap://authority/sensors/temperature. >>=20 >> Based on this perspective, and despite the fact that I've been added = as an author due to my contributions to disambiguating the syntax, I = don't think that CoRE Link Format describes a conceptually clean = solution to this problem that is compatible with what link descriptions = mean in RFC5988. >>=20 >> I believe a conceptually clean and compatible solution would be to = have coap://authority/.well-known/core return a list of links like: >>=20 >> rel=3D"hosts"; >> rel=3D"hosts"; >>=20 >> to indicate that these are resources hosted on the server. >=20 > Now I like this idea. I tried to use "service" to indicate this, but = would be happy with defining a new "hosts" relation for this purpose. = What do others think? >=20 > That does not stop you from including the needed link-parameter = meta-data with this link description. For example title=3D"Title Name", = n=3D"SemanticName", ct=3D1, id=3D3 etc.=20 >=20 >>=20 >> Further, define that coap://authority/.well-known/core/ = provides a link description document for context = coap://authority/. For example, = coap://authority/.well-known/core/sensors/temperature would return: >>=20 >> = rel=3D"describedby"; >> rel=3D"alternate"; >=20 > You could do this with relations, however I don't think anybody really = wants to do this. >=20 > So as I summary I do propose that we consider creating the new "hosts" = relation and better explaining that our context is coap://authority. We = should also better define how we should use our link-extensions. We = might consider giving some example of more creative use of deeper sets = of relations about a resource, but this is something that I definitely = would not require from a constrained node. Peter, how about I make a = ticket on this? >=20 > Zach >=20 >>=20 >> Thus providing in a single document the same sort of thing that would = be provided by a set of Link headers in an HTTP request to the context = URI. Note that what I called "further" is really the only case: = returning the list of hosted resources falls out as a consequence of = applying this rule with an empty . Very simple, very = orthogonal, only difference from HTTP is the URI used to obtain the link = descriptions and their encoding as a document rather than as header Link = fields. >>=20 >> (I can't tell from RFC5988 what the "index" relation is intended to = do, so perhaps it could be used instead of the newly created "hosts" = relation.) >>=20 >> I don't propose that CoAP actually implement this change, since I = don't think such a proposal would be accepted due to non-technical = pressures. But I did feel it necessary to raise the possibility, and to = ask for an outside perspective so we don't end up sending IESG something = that's completely at odds with how the concept we're borrowing is = understood and used by the rest of the Internet community. >>=20 >> Peter >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >=20 > --=20 > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 >=20 -- Mark Nottingham http://www.mnot.net/ From zach@sensinode.com Tue Nov 23 00:19:14 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EE783A69F9 for ; Tue, 23 Nov 2010 00:19:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2xaew7mkuIsc for ; Tue, 23 Nov 2010 00:19:13 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 830B13A6AE4 for ; Tue, 23 Nov 2010 00:19:11 -0800 (PST) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id oAN8K4Oc015338 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 23 Nov 2010 10:20:05 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-142-808076740; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: Date: Tue, 23 Nov 2010 10:20:05 +0200 Message-Id: <773B6F97-435A-430E-92A1-830D4F382CAD@sensinode.com> References: To: Klaus Hartke X-Mailer: Apple Mail (2.1081) Cc: core Subject: Re: [core] When are two requests equivalent? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 08:19:14 -0000 --Apple-Mail-142-808076740 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 22, 2010, at 12:39 AM, Klaus Hartke wrote: > Again, a caching-related issue that is largely an implementation > detail, but IMO should have some bits clarified in the draft. >=20 > Say a client sends a request with a critical option unknown to the = server: >=20 > C: GET coap://server/resource (99=3D0x00) > S: 602 (maxage=3D60s) "Unknown critical option 99." >=20 > Since responses to GET are cacheable, the client caches the response > for 60 seconds. =46rom coap-03 section 5.1.: >=20 >> When a client reads the response from a GET request, it should cache = the resource representation for the cache lifetime as specified by the = Max-Age header. During the cache lifetime, the client SHOULD use its = cached version and avoid performing additional GETs for the resource. When we cache something, we are caching the representation of a resource = identified by that URI. Thus it would make no sense to cache an error = response. The text in Section 5.1 should specify that only successful = responses are to be cached (it was assumed). In practice that means only = if the response code is "200 OK". Would that be a reasonable ticket to = solve the issue Klaus? Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 --Apple-Mail-142-808076740 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9 fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb 6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja 5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I 2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTEyMzA4MjAw NlowIwYJKoZIhvcNAQkEMRYEFJIPE5sjKp/sn0nb2a7KNxXn17fRMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAF1w4sW9jh4HkgTwLY9LOliN87oHmIoSzjWr7jKU4FiJCb3prtbmRUxF dfq5uagnMV0M/wSjIc+xTQo/IihkZmhpxg/BIribvsWhKmKcu8EdrIroHzovtvQ2WeS6Vs4dp7Jx zrKxilHpRi5Fy9zr3qGHN04z39h8oFQQ3bPuCeykgBUzq5InVsyCR7w/LB+R/cZPPJya89iMMD6f 3+j+Q8CRVwH5gV+OgxJm0MVUfez5r4Zb9EjvBj1ZejoJOuJPGGBrK+oisvKh2kHA2fDDiH/OULB8 o+oOkt1rCXxNEXiOX6vyjlideMU88CyLRYvx+6hoy4SuROmwf/6344Krss4AAAAAAAA= --Apple-Mail-142-808076740-- From abr@sdesigns.dk Tue Nov 23 00:34:17 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B84328C112 for ; Tue, 23 Nov 2010 00:34:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.447 X-Spam-Level: X-Spam-Status: No, score=-1.447 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, SARE_RMML_Stock10=0.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8FhEemiXCLqt for ; Tue, 23 Nov 2010 00:34:16 -0800 (PST) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id 6CF6E28C106 for ; Tue, 23 Nov 2010 00:34:15 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB8AE9.57C4ACD7" Date: Tue, 23 Nov 2010 09:31:22 +0100 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01AD4757@zensys17.zensys.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] Proxy and server on the same port Thread-Index: AcuKbjFLbjsEqkTARDGcudJwoD99kwAep4EF References: <1909899D-43E8-4C00-B957-6787468B4CDB@sensinode.com> From: "Anders Brandt" To: "Peter Bigot" , "Klaus Hartke" Cc: core Subject: Re: [core] Proxy and server on the same port X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 08:34:17 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB8AE9.57C4ACD7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > So you do agree with what was in that email? I assumed the complete = lack of response meant nobody thought it relevant. Actually, this thread is very relevant. I am currently investigating CoAP multi-subnet environments with = sleeping nodes and I am very much in favor of a precise terminology. =20 Unfortunately I am still not 100% up to speed on CoRE. What is the = preferred way of indicating that a node (typically the default gateway) = provides caching on behalf of other servers in the same subnet? and in = another subnet? =20 Thanks, Anders ________________________________ Fra: core-bounces@ietf.org p=E5 vegne af Peter Bigot Sendt: ma 22-11-2010 10:53 Til: Klaus Hartke Cc: core Emne: Re: [core] Proxy and server on the same port On Mon, Nov 22, 2010 at 11:22 AM, Klaus Hartke wrote: Peter Bigot wrote: >> I think it makes a lot of sense to distinguish between end-points = that >> act on behalf of a client and those that act on behalf of a server. >> Not sure what needs to be discussed (apart maybe from the actual = terms >> used for the two roles). > > Just that I proposed completely rewriting section five to get CoAP to = use > specific terms in the way I described in my email, which would result = in a > significant change (clarification) to what "proxy" means, and a = separation > of it from the concept of a "cache". Your comment above is not the = same > thing, and since nobody else has commented I don't think my email = should be > the basis of a ticket. =09 =09 I thought my comment above would capture the essence of your email, but apparently it didn't. Sorry, I didn't read it that way. =20 So here's an attempt at a more complete summary of your email: =09 * Intermediary CoAP end-points act as both a client and a server in order to forward, with possible translation, requests and responses. =09 OK.=20 * A proxy is an intermediary selected by a client. A client can delegate all CoAP requests it can't do itself to a proxy. Configuration of this proxy for a particular node is an administrative function outside the scope of CoAP. =09 Yes.=20 * A gateway (a.k.a., reverse proxy, big brother, ...) is an intermediary imposed by the origin server to support sleeping nodes or perform any other role that might be hidden behind the authority part of a URI. =09 Almost; the origin server may be unaware of the presence of a gateway. = The network may impose the gateway. * Caching in turn is a function that may be paired with a proxy or with a gateway, but is not inherently coupled to either one. =09 Yes. =20 Please correct me if I'm missing something essential. =09 Not at first glance, So you do agree with what was in that email? I assumed the complete = lack of response meant nobody thought it relevant. =20 > In what I proposed, a client is specifically configured to use a = (single) > proxy, and that proxy is providing specific enhanced services on = behalf of > the client. With that model it makes little sense to accommodate = placing > the proxy at the same end-point (port) as a normal server. > > However, if there's no buy-in for that change, and there's some = compelling > reason why we should accommodate two applications at a single port, I > suppose a set of rules to use UriScheme values as a cue to whether a = request > might have been intended for a proxy or a server could be made to = work. > "Don't do that" seems like a better approach, in my opinion. =09 =09 There are two things: =09 1. Does it make sense to run a proxy and a server on the same port? =09 The answer is probably: No. =09 Good. 2. What to do when a client thinks an end-point is a server when it's actually a proxy? =09 Ah. I lost the context from the earlier parts of the thread, and = assumed your proposal was a way to allow dual-use. In fact, your rules = seem to be a complete workable solution that does allow dual use. Nice. = That's not what raised my hackles. The solution is to have the client say what it thinks, so that its wrong assumption can be pointed out by the recipient. =09 That is a good solution. But in the details, I think it would be more = clear if the client does say what it thinks (that it's talking with a = proxy), rather than creating complex rules on how to interpret = Uri-Scheme to infer that it thinks it's talking with a proxy. So use a = new option named Uri-Proxy with no value, the presence/absence of which = indicates the client's expectations. Don't overload Uri-Scheme to mean = something weird that could conflict with future use, e.g. putting a coap = and a coapm (multicast) service on the same port. Change Uri-Scheme to Uri-Proxy in your proposal and you've got a = solution that allows disambiguation while at the same time allowing both = functions to occur on the same port and not muddying what Uri-Scheme = means. That's the sort of approach I like: one technique that solves = multiple problems without introducing new ones. Barring some = undiscovered flaw, I'd support that. =20 Klaus _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core =09 ------_=_NextPart_001_01CB8AE9.57C4ACD7 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A=
    =0A=
    > So you do agree with what was in that = email?  I assumed the complete lack of response meant nobody = thought it relevant.
    =0A=
    Actually, = this thread is very relevant.
    =0A=
    I am currently investigating = CoAP multi-subnet environments with sleeping nodes and I am very much in = favor of a precise terminology.
    =0A=
     
    =0A=
    Unfortunately I am still not = 100% up to speed on CoRE. What is the preferred way of indicating that a = node (typically the default gateway) provides caching on behalf of other = servers in the same subnet? and in another subnet?
    =0A=
     
    =0A=
    Thanks,
    =0A=
      = Anders
    =0A=

    =0A=
    =0A= Fra: core-bounces@ietf.org p=E5 = vegne af Peter Bigot
    Sendt: ma 22-11-2010 10:53
    Til: = Klaus Hartke
    Cc: core
    Emne: Re: [core] Proxy and = server on the same port

    =0A=
    =0A=
    On Mon, Nov 22, 2010 at 11:22 AM, Klaus Hartke = <hartke@tzi.org> wrote:
    =0A=
    =0A=
    Peter Bigot wrote:
    >> I think it makes a lot of = sense to distinguish between end-points that
    >> act on behalf = of a client and those that act on behalf of a server.
    >> Not = sure what needs to be discussed (apart maybe from the actual = terms
    >> used for the two roles).
    >
    > Just that I = proposed completely rewriting section five to get CoAP to use
    > = specific terms in the way I described in my email, which would result in = a
    > significant change (clarification) to what "proxy" means, and = a separation
    > of it from the concept of a "cache".  Your = comment above is not the same
    > thing, and since nobody else has = commented I don't think my email should be
    > the basis of a = ticket.

    I thought my comment above would capture the = essence of your email,
    but apparently it didn't.
    =0A=

    Sorry,  I didn't read it that way.
     
    =0A=
    So here's an = attempt at a more complete
    summary of your email:

    * = Intermediary CoAP end-points act as both a client and a server = in
    order to forward, with possible translation, requests and = responses.
    =0A=

    OK.

    =0A=
    * A proxy is = an intermediary selected by a client. A client can
    delegate all CoAP = requests it can't do itself to a proxy.
    Configuration of this proxy = for a particular node is an administrative
    function outside the scope = of CoAP.
    =0A=

    Yes.

    =0A=
    * A gateway = (a.k.a., reverse proxy, big brother, ...) is an
    intermediary imposed = by the origin server to support sleeping nodes or
    perform any other = role that might be hidden behind the authority part
    of a = URI.
    =0A=

     Almost; the origin server may be unaware of the presence = of a gateway.  The network may impose the gateway.

    =0A=
    * Caching in = turn is a function that may be paired with a proxy or
    with a gateway, = but is not inherently coupled to either one.
    =0A=

    Yes.
     
    =0A=
    Please correct = me if I'm missing something essential.
    =0A=

    Not at first glance,

    So you do agree with what was in = that email?  I assumed the complete lack of response meant nobody = thought it relevant.
     
    =0A=
    =0A=
    > In what I proposed, a client is specifically = configured to use a (single)
    > proxy, and that proxy is providing = specific enhanced services on behalf of
    > the client.  With = that model it makes little sense to accommodate placing
    > the = proxy at the same end-point (port) as a normal server.
    >
    > = However, if there's no buy-in for that change, and there's some = compelling
    > reason why we should accommodate two applications at = a single port, I
    > suppose a set of rules to use UriScheme values = as a cue to whether a request
    > might have been intended for a = proxy or a server could be made to work.
    > "Don't do that" seems = like a better approach, in my opinion.

    There are two = things:

    1. Does it make sense to run a proxy and a server on the = same port?

    The answer is probably: No.
    =0A=

    Good.

    =0A=
    2. What to do = when a client thinks an end-point is a server when it's
    actually a = proxy?
    =0A=

    Ah.  I lost the context from the earlier parts of the = thread, and assumed your proposal was a way to allow dual-use.  In = fact, your rules seem to be a complete workable solution that does allow = dual use.  Nice.  That's not what raised my = hackles.

    =0A=
    The solution = is to have the client say what it thinks, so that its
    wrong = assumption can be pointed out by the recipient.
    =0A=

    That is a good solution.  But in the details, I think it = would be more clear if the client does say what it thinks (that it's = talking with a proxy), rather than creating complex rules on how to = interpret Uri-Scheme to infer that it thinks it's talking with a = proxy.  So use a new option named Uri-Proxy with no value, the = presence/absence of which indicates the client's expectations.  = Don't overload Uri-Scheme to mean something weird that could conflict = with future use, e.g. putting a coap and a coapm (multicast) service on = the same port.

    Change Uri-Scheme to Uri-Proxy in your proposal = and you've got a solution that allows disambiguation while at the same = time allowing both functions to occur on the same port and not muddying = what Uri-Scheme means.  That's the sort of approach I like: one = technique that solves multiple problems without introducing new = ones.  Barring some undiscovered flaw, I'd support = that.
     
    =0A=
    =0A=
    =0A=
    =0A=

    Klaus
    _______________________________________________core mailing list
    core@ietf.org
    https://www.ietf.org/mailman/listinfo/core
    <= /DIV>

    ------_=_NextPart_001_01CB8AE9.57C4ACD7-- From trac@tools.ietf.org Tue Nov 23 00:38:29 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4004E3A677D for ; Tue, 23 Nov 2010 00:38:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xYeCxVsQxBSq for ; Tue, 23 Nov 2010 00:38:28 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 3DE9E3A67A1 for ; Tue, 23 Nov 2010 00:38:28 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PKoPL-0000vF-NJ; Tue, 23 Nov 2010 00:39:23 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Tue, 23 Nov 2010 08:39:23 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/76#comment:1 Message-ID: <062.e005eebef68d9cfe38103602bef0a764@tools.ietf.org> References: <053.48772f16e4210556e31256ce985ef8fc@tools.ietf.org> X-Trac-Ticket-ID: 76 In-Reply-To: <053.48772f16e4210556e31256ce985ef8fc@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] coap #76 (new): Media types X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 08:38:29 -0000 #76: Media types Changes (by zach@…): * priority: major => minor * type: defect => enhancement Comment: Let's be very specific about what changes are suggested by this ticket to Section 11.2. The mail from Cullen below suggests making changes to how MIME types are used that is way beyond our scope. I think that is something that needs to be fixed in the App area, and not in this working group. Although I see where Cullen is coming from, some basic MIME types are very useful when an application specific MIME type is not available, especially when getting started with a new application. For example application/xml, text/plain, application/exi, application/json all tell you what kind of parser needs to be used on the payload, or how the data could be displayed to a human. That said, I do think we can do some of the things suggested by Cullen: 1. Add a column to the table pointing to a document describing what the payload means semantically. 2. Remove some types from the table not really needed. Do we really need the image and video ones for example? application/x-bxml also is not a standard nor widely deployed. I would argue that we need to keep (at least some of) the basic text and application types. 3. We add a paragraph explaining how MIME types should be designed and used for real applications as per Cullen's mail. For example something like application/sep20+xml in the case of ZigBee smart energy. Or the proposed application/dali, application/bacnet etc. from draft-vanderstok- core-bc. -- ----------------------------+----------------------------------------------- Reporter: hartke@… | Owner: zach@… Type: enhancement | Status: new Priority: minor | Milestone: Component: coap | Version: Severity: - | Keywords: ----------------------------+----------------------------------------------- Ticket URL: core From zach@sensinode.com Tue Nov 23 00:50:15 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 761BC3A67E4 for ; Tue, 23 Nov 2010 00:50:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.426 X-Spam-Level: X-Spam-Status: No, score=-3.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WxriGxVdtsSH for ; Tue, 23 Nov 2010 00:50:14 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id D95503A67E1 for ; Tue, 23 Nov 2010 00:50:13 -0800 (PST) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id oAN8p68C026219 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 23 Nov 2010 10:51:07 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-145-809939142; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: Date: Tue, 23 Nov 2010 10:51:07 +0200 Message-Id: <536D0E28-00BE-4B25-A073-8AC3E8C0B169@sensinode.com> References: <1909899D-43E8-4C00-B957-6787468B4CDB@sensinode.com> To: Klaus Hartke X-Mailer: Apple Mail (2.1081) Cc: core Subject: Re: [core] Proxy and server on the same port X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 08:50:15 -0000 --Apple-Mail-145-809939142 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 22, 2010, at 8:27 PM, Klaus Hartke wrote: > Peter Bigot wrote: >> Almost; the origin server may be unaware of the presence of a = gateway. The >> network may impose the gateway. >=20 > Oh, that's what "imposed by the network" means. Good. >=20 >> So you do agree with what was in that email? >=20 > Yes. That's why there's a ticket which consists of a link to your = email. :-) I also agree with the improved definitions for Section 5. We are talking = with Brian about how to make those changes. This will need changes to = Section 7 on HTTP mapping as well. >=20 >> Change Uri-Scheme to Uri-Proxy in your proposal and you've got a = solution >> that allows disambiguation while at the same time allowing both = functions to >> occur on the same port and not muddying what Uri-Scheme means. >=20 > Works for me. I just know Zach's dislike for new options, and > Uri-Scheme seemed to be used only in proxy (not gateway) scenarios so > far. ;-) Sorry for playing option police, but someone has to do it. Adding a = Uri-Proxy option would not bother me, as this is only needed by a proxy = or a client using it. Regarding Uri-Scheme I am becoming less convinced that we need that at = all with the Chapter 5 terminology improvements and a Uri-Proxy option = (not sure if the name is perfect). But that is a different thread.=20 Zach=20 >=20 >=20 > Klaus > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 --Apple-Mail-145-809939142 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9 fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb 6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja 5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I 2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTEyMzA4NTEw OFowIwYJKoZIhvcNAQkEMRYEFAmraJDEk2osd1Z6QsoeAGQB/qvTMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAKYsagefHvmTrN8rboLmC13QyQRNDedZ2iw2YNm/8o+RnYMJMvxKuHCl fjZTYtSF7u4WPmtiFpc6KaaYenQmLzcDNAzk8eqiA2hLMma5trH2BtcbMnUMDCamLDcQBzm8lgjM DS2eZvG2MenYJlpwHb89Dp7+6b1xvDRk+J8AqdFr8tAcqiIDrKDQSHtsk9xFIrKU3qHySi7DV9KZ QjmNfMSvr6A8GazUwVgf9yyft9a2putIYMkNuK156UKRnBj/N8d06U5XGpp4qJBJEbfAlWTeRO41 FY+XdpZziEB7/poqUeSooMi9ffcXVuUoskniCbsh8m9uLQiT6Tg9yzN/Iz0AAAAAAAA= --Apple-Mail-145-809939142-- From matthieu.vial@fr.non.schneider-electric.com Tue Nov 23 00:56:29 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8A673A67F8; Tue, 23 Nov 2010 00:56:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.065 X-Spam-Level: X-Spam-Status: No, score=-3.065 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VnOQDzfb8sLe; Tue, 23 Nov 2010 00:56:28 -0800 (PST) Received: from mailX02.eud.schneider-electric.com (mailx02.eud.schneider-electric.com [205.167.7.38]) by core3.amsl.com (Postfix) with ESMTP id 6189E3A67F3; Tue, 23 Nov 2010 00:56:28 -0800 (PST) Received: from ateui02.Schneider-Electric.com ([10.198.14.10]) by mailX02.eud.schneider-electric.com with ESMTP id 2010112309375854-167957 ; Tue, 23 Nov 2010 09:37:58 +0100 In-Reply-To: To: Peter Bigot X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: matthieu.vial@fr.non.schneider-electric.com Date: Tue, 23 Nov 2010 09:57:19 +0100 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on ATEUI02.Schneider-Electric.com/T/SVR/Schneider at 23/11/2010 09:57:20, Itemize by SMTP Server on AXEU2OUT.schneider-electric.com/X/SVR/SEIxtra at 23/11/2010 09:37:58, Serialize by Router on AXEU2OUT.schneider-electric.com/X/SVR/SEIxtra at 23/11/2010 09:37:59, Serialize complete at 23/11/2010 09:37:59 Content-type: multipart/alternative; Boundary="0__=4EBBFD77DFBF469A8f9e8a93df938690918c4EBBFD77DFBF469A" Content-Disposition: inline Cc: core-bounces@ietf.org, core , Klaus Hartke Subject: Re: [core] Proxy and server on the same port X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 08:56:29 -0000 --0__=4EBBFD77DFBF469A8f9e8a93df938690918c4EBBFD77DFBF469A Content-transfer-encoding: quoted-printable Content-type: text/plain; charset=ISO-8859-1 >>* A gateway (a.k.a., reverse proxy, big brother, ...) is an >>intermediary imposed by the origin server to support sleeping n= odes or >>perform any other role that might be hidden behind the authorit= y part >>of a URI. >=A0Almost; the origin server may be unaware of the presence of a gatew= ay. The network may impose the gateway. I'm sorry but I can't catch the exact meaning of "any other role that m= ight be hidden behind the authority part of a URI". A gateway acting as a reverse proxy could for example implement a cache= for sleeping nodes. The reverse proxy can map the sleeping nodes into its o= wn namespace. In that case it's not just the authority part of the URI but= the full URI that is used to decide what should be done. coap://bigbrother1.example.org/sensor1/ is actually redirected to coap://sensor1.example.org/ coap://bigbrother1.example.org/sensor2/ is actually redirected to coap://sensor2.example.org/ Or maybe you want to separate the different functions of the gateway in= to different domain names that resolve to the same IP? coap://cache.example.org/ implements the caching feature coap://http.example.org/ implements HTTP translation coap://6to4.example.org/ implements IPv6 to IPv4 translation But then I suppose it could also be defined like that: coap://gateway.example.org/cache/ coap://gateway.example.org/http/ coap://gateway.example.org/6to4/ On the other hand a gateway acting as a transparent/interception proxy = will use some IP magic to answer on the behalf of the origin server. In that= case the gateway only uses the authority part of the URI (or the destination address). But transparent proxying requires some advanced I= P stack features that are not always available: 1. Redirect sessions destined to the outer network to a local proces= s using a packet filter rule. 2. Make it possible for a process to listen to connections on a fore= ign address. 3. Make it possible for a process to initiate a connection with a foreign address as a source. Could you please tell me if something is wrong with my reasoning? Regards, Matthieu= --0__=4EBBFD77DFBF469A8f9e8a93df938690918c4EBBFD77DFBF469A Content-transfer-encoding: quoted-printable Content-type: text/html; charset=ISO-8859-1 Content-Disposition: inline

        >>* A gateway (a.k.a., reverse proxy, big bro= ther, ...) is an
        >>intermediary imposed by the origin server to support sleeping n= odes or
        >>perform any other role that might be hidden behind the authorit= y part
        >>of a URI.


    >=A0Almost; the origin server may be unaware of the presence of a ga= teway.=A0 The network may impose the gateway.

    I'm sorry but I can't catch the exact meaning of "= ;any other role that might be hidden behind the authority part
    of a URI".
    A gateway acting as a reverse proxy could for example = implement a cache for sleeping nodes. The reverse proxy can map the sle= eping nodes into its own namespace. In that case it's not just the auth= ority part of the URI but the full URI that is used to decide what shou= ld be done.
    coap://bigbrother1.example.org/sensor1/ is actually re= directed to coap://sensor1.example.org/
    coap://bigbrother1.example.org/sensor2/ is actually re= directed to coap://sensor2.example.org/

    Or maybe you want to separate the different functions = of the gateway into different domain names that resolve to the same IP?=
    coap://cache.example.org/ implements the caching featu= re
    coap://http.example.org/ implements HTTP translation
    coap://6to4.example.org/ implements IPv6 to IPv4 trans= lation
    But then I suppose it could also be defined like that:=
    coap://gateway.example.org/cache/
    coap://gateway.example.org/http/
    coap://gateway.example.org/6to4/

    On the other hand a gateway acting as a transparent/in= terception proxy will use some IP magic to answer on the behalf of the = origin server. In that case the gateway only uses the authority part of= the URI (or the destination address). But transparent proxying require= s some advanced IP stack features that are not always available:=
    1. Redirect sessions destined to the outer network = to a local process using a packet filter rule.
    2. Make it possible for a process to listen to conn= ections on a foreign address.
    3. Make it possible for a process to initiate a con= nection with a foreign address as a source.

    Could you please tell me if something is wrong with my= reasoning?

    Regards,
    Matthieu= --0__=4EBBFD77DFBF469A8f9e8a93df938690918c4EBBFD77DFBF469A-- From trac@tools.ietf.org Tue Nov 23 00:56:57 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E94553A67F8 for ; Tue, 23 Nov 2010 00:56:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FHPAEQlyRdcH for ; Tue, 23 Nov 2010 00:56:56 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id E3BFA3A67F3 for ; Tue, 23 Nov 2010 00:56:55 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PKohD-0005r0-J9; Tue, 23 Nov 2010 00:57:51 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: brian@skyfoundry.com, zach@sensinode.com X-Trac-Project: core Date: Tue, 23 Nov 2010 08:57:51 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/72#comment:1 Message-ID: <062.55de57dc5b4271a506dce13f0999a65d@tools.ietf.org> References: <053.639894f29bddd032e710ff634d4068d3@tools.ietf.org> X-Trac-Ticket-ID: 72 In-Reply-To: <053.639894f29bddd032e710ff634d4068d3@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: brian@skyfoundry.com, zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] coap #72 (new): Proxy versus Gateway X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 08:56:58 -0000 #72: Proxy versus Gateway Changes (by zach@…): * owner: zach@… => brian@… * type: task => enhancement Comment: A summary of the suggested terminology from Klaus and Peter: * Intermediary CoAP end-points act as both a client and a server in order to forward, with possible translation, requests and responses. * A proxy is an intermediary selected by a client. A client can delegate all CoAP requests it can't do itself to a proxy. Configuration of this proxy for a particular node is an administrative function outside the scope of CoAP. * A gateway (a.k.a., reverse proxy, big brother, ...) is an intermediary imposed by the origin server to support sleeping nodes or perform any other role that might be hidden behind the authority part of a URI. The origin server may be unaware of the presence of a gateway. The network may impose the gateway. * Caching in turn is a function that may be paired with a proxy or with a gateway, but is not inherently coupled to either one. -- ----------------------------+----------------------------------------------- Reporter: hartke@… | Owner: brian@… Type: enhancement | Status: new Priority: minor | Milestone: Component: coap | Version: Severity: - | Keywords: ----------------------------+----------------------------------------------- Ticket URL: core From trac@tools.ietf.org Tue Nov 23 01:08:19 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C4143A67F2 for ; Tue, 23 Nov 2010 01:08:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mgpel9v2QYkc for ; Tue, 23 Nov 2010 01:08:18 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 2A4223A67F1 for ; Tue, 23 Nov 2010 01:08:18 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PKosF-0002X3-3o; Tue, 23 Nov 2010 01:09:15 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Tue, 23 Nov 2010 09:09:14 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/45#comment:1 Message-ID: <066.460c325d5f2b30b0e3c8100afb3c510e@tools.ietf.org> References: <057.da83241436b82aeff88628eb9e900b6e@tools.ietf.org> X-Trac-Ticket-ID: 45 In-Reply-To: <057.da83241436b82aeff88628eb9e900b6e@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] block #45 (closed): Large responses to large POST/PUT X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 09:08:19 -0000 #45: Large responses to large POST/PUT Changes (by zach@…): * status: new => closed * resolution: => wontfix Comment: The conclusion from the WG meeting in Beijing was that we don't need to support large representations in both directions, so this doesn't warrant redirect support. -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: enhancement | Status: closed Priority: major | Milestone: Component: block | Version: Severity: - | Resolution: wontfix Keywords: | --------------------------------+------------------------------------------- Ticket URL: core From trac@tools.ietf.org Tue Nov 23 01:13:29 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91F8D3A6832 for ; Tue, 23 Nov 2010 01:13:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id abuXC-2Oc2oH for ; Tue, 23 Nov 2010 01:13:28 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id CF7A53A6827 for ; Tue, 23 Nov 2010 01:13:28 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PKoxF-0003F9-Th; Tue, 23 Nov 2010 01:14:25 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Tue, 23 Nov 2010 09:14:25 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/50#comment:1 Message-ID: <066.9ee9af8e5d7d2fbae433980de2ace32a@tools.ietf.org> References: <057.5388bf9ad1647d65c4eca0123ed73ff3@tools.ietf.org> X-Trac-Ticket-ID: 50 In-Reply-To: <057.5388bf9ad1647d65c4eca0123ed73ff3@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] coap #50 (new): Human readable error payloads X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 09:13:29 -0000 #50: Human readable error payloads Comment(by zach@…): It also needs to be clarified that the payload included with an error response is text/plain. -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: Type: enhancement | Status: new Priority: trivial | Milestone: Component: coap | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From trac@tools.ietf.org Tue Nov 23 01:17:03 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A6EA3A6867 for ; Tue, 23 Nov 2010 01:17:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JHHG2S2aKSQN for ; Tue, 23 Nov 2010 01:17:02 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 7ED053A6866 for ; Tue, 23 Nov 2010 01:17:02 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PKp0h-0007Xx-IQ; Tue, 23 Nov 2010 01:17:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Tue, 23 Nov 2010 09:17:59 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/79 Message-ID: <057.a5ce8c3e8bd308082ac99363243e76b0@tools.ietf.org> X-Trac-Ticket-ID: 79 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] coap #79 (new): References X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 09:17:03 -0000 #79: References Alexey found some reference issues in his review: * In Section 1 - the first reference to HTTP needs an Informative Reference. * In Section 2.1.2 (Asynchronous response) - the first reference to "token option" needs a reference (either a cross reference, or an external reference). * In Section 7 - the first references to XMPP and SIP require Informative References. * " The Authority Name in the certificate is the name that would be used in the Authority part of a CoAP URI. It is worth noting that this would typically not be either an IP address or DNS name but would instead be a long term unique identifier for the device such as the EUI-64." I think this needs a reference. * draft-ietf-tls-rfc4366-bis. That document was approved by IESG, so this needs to be converted to a proper Normative Reference. -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: defect | Status: new Priority: trivial | Milestone: Component: coap | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From trac@tools.ietf.org Tue Nov 23 01:19:23 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A88AF3A6808 for ; Tue, 23 Nov 2010 01:19:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8vep7uv4uPa for ; Tue, 23 Nov 2010 01:19:22 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id C52453A67DB for ; Tue, 23 Nov 2010 01:19:22 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PKp2x-0002jb-Pk; Tue, 23 Nov 2010 01:20:19 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Tue, 23 Nov 2010 09:20:19 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/80 Message-ID: <057.92cfec853763e811014fc69193f53889@tools.ietf.org> X-Trac-Ticket-ID: 80 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] coap #80 (new): IANA section X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 09:19:23 -0000 #80: IANA section Alexey suggests improvements to the IANA section: * In Section 11 - IANA registration policy for COAP status codes and COAP MIME types is not defined. I suggest Expert Review at minimum (because of code/MIME type space is so small). * Also, the coap:// URI scheme needs to be registered using the URI registration template. * Should COAP methods be registered with IANA together with COAP status codes (as they are used in the same field)? (Zach: Yes they should be) -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: enhancement | Status: new Priority: minor | Milestone: Component: coap | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From zach@sensinode.com Tue Nov 23 01:27:56 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F8463A6869 for ; Tue, 23 Nov 2010 01:27:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.448 X-Spam-Level: X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sosySC95Cp0h for ; Tue, 23 Nov 2010 01:27:54 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id C24D03A681D for ; Tue, 23 Nov 2010 01:27:53 -0800 (PST) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id oAN9Slb9002019 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 23 Nov 2010 11:28:47 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-150-812199354; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: <4CE38524.60106@isode.com> Date: Tue, 23 Nov 2010 11:28:48 +0200 Message-Id: References: <4CE38524.60106@isode.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.1081) Cc: core WG Subject: Re: [core] Review of draft-ietf-core-coap-03.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 09:27:56 -0000 --Apple-Mail-150-812199354 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Alexey, Thanks for the review, very helpful. I will now be making tickets for = these. Some comments in-line. On Nov 17, 2010, at 9:32 AM, Alexey Melnikov wrote: > Hi, > I've decided to do IESG-type review of the document, as it seems to be = getting close to being done. many of my comments are editorial in = nature. In general I found the document to be well written. >=20 > In Section 1 - the first reference to HTTP needs an Informative = Reference. >=20 > In Section 2.1.2 (Asynchronous response) - the first reference to = "token option" needs a reference (either a cross reference, or an = external reference). >=20 >> 2.5.1. Option Processing >>=20 >> If no options are to be included, the Option Count field is set to = 0 >> below and the Payload (if any) immediately follows the Transaction >> ID. If options are to be included, the following rules apply. The >> number of options is placed in the Option Count field. Each option >> is then placed in order of Type, immediately following the >> Transaction ID with no padding. Upon reception, unknown options of >> class "elective" MUST be silently skipped. Unknown options of = class >> "critical" in a Confirmable MUST cause the return of a response = code >> "Critical Option not supported (CoAP 242)" including a copy of the >> critical option number in the payload of the response. > Does this need a new payload (MIME) type registration? Options don't = seem to be considered to be a part of a payload (assuming my reading of = Sections 3 and 3.1 is correct). Or did you mean that the options need to = be returned as TLVs? This payload is meant to be text/plain. We also have a ticket to include = a human readable error message: = http://trac.tools.ietf.org/wg/core/trac/ticket/50 >=20 >> 3.2.8. Token Option >>=20 >> This option MUST NOT occur ore than once in a header. > typo: more >=20 >> 5.1. Cache control >> In general, the origin server end-point is responsible for >> determining cache age. However, in some cases a client may wish to >> determine its own tolerance for cache staleness. In this case, a >> client may specify the Max-Age header during a GET request. If the >> client's Max-Age is of a shorter duration than the age of a cached > "than the remaining age"? Yep, will fix that. >> resource, then the proxy or end-point SHOULD perform a cache = refresh. >> If the client specifies a Max-Age of zero seconds, then the = response >> MUST discard the cached representation and return a fresh > In Section 7 - the first references to XMPP and SIP require = Informative References. >=20 >> 7. HTTP Mapping >>=20 >> The caching and proxying of CoAP is specified in Section 5. In a >> similar manner, caching and proxying MAY be performed between CoAP >> and HTTP by an intermediate node. A proxy SHOULD respond with a = 502 >> (Bad Gateway) error to HTTP requests which can not be successfully >> mapped to CoAP. CoAP transaction messages are transparent to >> request/response exchanges and MUST have no affect on a proxy >> function. > I am not entirely sure about the meaning of the last sentence. Can you = clarify? You can consider CoAP to have two layers:=20 - A transaction layer with transaction messages and a TID. =20 - A request/response layer with Method/Code and options. Responses in = CoAP may be deferred for example. This sentence just clarifies that the underlying CoAP transaction model = has to be transparent to proxy functionality. For example you don't send = an error message to an HTTP client while waiting for a deferred CoAP = response. This will be explained better in coap-04. >> 10. Security Considerations >>=20 >> Certificate: The device has an asymmetric key pair with a X.509 >> [RFC5280] certificate that binds it to its Authority Name and is >> signed by a some common trust root. The device also has a list = or >> root trust anchors that can be used for validating a = certificate. >> There may be an optional shared key that all the nodes that >> communicate have access too. >>=20 >> The Authority Name in the certificate is the name that would be = used >> in the Authority part of a CoAP URI. It is worth noting that this >> would typically not be either an IP address or DNS name but would >> instead be a long term unique identifier for the device such as the >> EUI-64. > I think this needs a reference. >> The discovery process used in the system would build up the >> mapping between IP addresses of the given devices and the Authority >> Name for each device. Some devices could have more than one >> Authority and would need more than a single certificate. >=20 >> 10.2. Securing CoAP with DTLS >>=20 >> Devices SHOULD support the Server Name Indication (SNI) to indicate >> their Authority Name in the SNI HostName field as defined in = Section >> 3 of draft-ietf-tls-rfc4366-bis. > That document was approved by IESG, so this needs to be converted to a = proper Normative Reference. >> This is needed so that when a host >> that acts as a virtual server for multiple Authorities receives a = new >> DTLS connection, it knows which keys to use for the DTLS session. >=20 >> 10.2.1. SharedKey & MultiKey Modes >>=20 >> When forming a connection to a new node, the system selects an >> appropriate key based on which nodes it is trying to reach then = forms >> a DTLS session using a PSK (Pre-Shared Key) mode of DTLS. >> Implementations SHOULD support the mandatory to implement cipher > I think this needs to be a MUST, conditional on DTLS being supported = by the node. >> suite TLS_PSK_WITH_AES_128_CBC_SHA as specified in [RFC5246]. >> 10.2.2. Certificate Mode >>=20 >> As with IPsec, DTLS should be configured with a cypher suite >> compatible with any possible hardware engine on the node, for = example >> AES-CBC in the case of IEEE 802.15.4. Implementations SHOULD = support > As above, I think this needs to be a MUST. >> the mandatory to implement cipher suite = TLS_RSA_WITH_AES_128_CBC_SHA >> as specified in [RFC5246]. >=20 The thinking behind the SHOULD in for these default cipher suites was = that not all constrained devices would have hardware for AES-CBC (or = AES-CCM is actually our goal). It is true for lots of IEEE 802.15.4 = devices, but a different platform for e.g. industrial automation might = need a totally different cipher suite for the encryption hardware it has = support for. Should we require those industrial devices to support the = default AES-CCM cipher suite also? =20 > In Section 11 - IANA registration policy for COAP status codes and = COAP MIME types is not defined. I suggest Expert Review at minimum = (because of code/MIME type space is so small). >=20 > Also, the coap:// URI scheme needs to be registered using the URI = registration template. >=20 > Should COAP methods be registered with IANA together with COAP status = codes (as they are used in the same field)? Yes they should, thanks for pointing that out. Zach >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 --Apple-Mail-150-812199354 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9 fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb 6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja 5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I 2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTEyMzA5Mjg0 OFowIwYJKoZIhvcNAQkEMRYEFPkOtDYS+8bRbx61ztsT3q9BfwokMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBABxsw+EzUq7XbrbP9YqO9/wCsz69rEbhzDCT8fHYSFpE8hebhkjheUwL /TLNIfKq5LdcmX9Xcc54drdCZd1bL0KFllakV3PYN2GHt9AMjWnmt1V4idfPdgziPrGGf44idfk2 lLQ9EhUYnn2dSfAp//SnDv5QRjwqbKZtkHx+O2REuz3YUlyDGof5JEyVRaqh+psE8rmtsyx7a/hs rlX9Ei1WeH/35BJojS4eiKe3lYkuam8MqINa/CBlhl9GxMnHbpobIfHft9DUxwy69/5Vr5UzRZOS 2GmBG1D9+Rb65e27g2AGl7svTEU/JTifPw7w7KChzaJIFLiN43LfkeHWAQIAAAAAAAA= --Apple-Mail-150-812199354-- From abr@sdesigns.dk Tue Nov 23 02:00:59 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C5803A68B2 for ; Tue, 23 Nov 2010 02:00:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.47 X-Spam-Level: X-Spam-Status: No, score=-1.47 tagged_above=-999 required=5 tests=[AWL=-0.268, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qgEivs5DbSuO for ; Tue, 23 Nov 2010 02:00:57 -0800 (PST) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id 6D4C93A68A7 for ; Tue, 23 Nov 2010 02:00:57 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB8AF5.74C3EA71" Date: Tue, 23 Nov 2010 11:01:54 +0100 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01AD475A@zensys17.zensys.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] Proxy and server on the same port Thread-Index: AcuK7HcFNY8SdP+RQtm/m4kAK//UzQABMp2z References: From: "Anders Brandt" To: , "Peter Bigot" Cc: Klaus Hartke , core Subject: Re: [core] Proxy and server on the same port X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 10:00:59 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB8AF5.74C3EA71 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Matthieu, =20 Very good points! =20 On the other hand a gateway acting as a transparent/interception proxy = will use some IP magic to answer on the behalf of the origin server. In = that case the gateway only uses the authority part of the URI (or the = destination address). But transparent proxying requires some advanced IP = stack features that are not always available: 1. Redirect sessions destined to the outer network to a local process = using a packet filter rule. 2. Make it possible for a process to listen to connections on a foreign = address. 3. Make it possible for a process to initiate a connection with a = foreign address as a source. =20 This is one component I would actually expect to see in CoRE = environment, exactly because I do not want the Clients to be bothered by = the network topology.=20 But what would we then call this beast? =20 A "caching gateway" - or just a "gateway" and then indicate in an option = that it performs caching?=20 =20 And something related but slightly different: How do I represent my advanced powerstrip device: Global on/off + on/off = per outlet ? Depending on imlementation, such multichannel devices may have one = master IPv6 address + one IPv6 address per outlet - or it may have only address and you access it via coap://bigbrother1.example.org/output/ <- master on/off=20 coap://bigbrother1.example.org/1/output coap://bigbrother1.example.org/2/output in the latter case, this is already supported by coap - but if you have = individual IPv6 addresses, as in the first example, then I suppose that your device is a server (the master on/off function) = AND a gateway for the other IPv6 addresses? =20 coap://bigbrother1.example.org/output/ <- master on/off=20 coap://bigbrother1-1.example.org/output coap://bigbrother1-2.example.org/output One could argue that this is just a multihomed server - but in order to = present these functions as one physical instance in a management tool, my discovery process needs to understand that = there is a tight connection.=20 While the URIs above might suggest that there is such a connection, it = is not explicit. =20 Is this a gateway at all - or do we need a third type: "MultiChannel = server", where the master address advertizes the other ones? =20 Thanks, Anders ________________________________ Fra: core-bounces@ietf.org p=E5 vegne af = matthieu.vial@fr.non.schneider-electric.com Sendt: ti 23-11-2010 01:57 Til: Peter Bigot Cc: core-bounces@ietf.org; core; Klaus Hartke Emne: Re: [core] Proxy and server on the same port >>* A gateway (a.k.a., reverse proxy, big brother, ...) is an >>intermediary imposed by the origin server to support sleeping nodes = or >>perform any other role that might be hidden behind the authority = part >>of a URI. > Almost; the origin server may be unaware of the presence of a gateway. = The network may impose the gateway. I'm sorry but I can't catch the exact meaning of "any other role that = might be hidden behind the authority part of a URI".=20 A gateway acting as a reverse proxy could for example implement a cache = for sleeping nodes. The reverse proxy can map the sleeping nodes into = its own namespace. In that case it's not just the authority part of the = URI but the full URI that is used to decide what should be done. coap://bigbrother1.example.org/sensor1/ is actually redirected to = coap://sensor1.example.org/ coap://bigbrother1.example.org/sensor2/ is actually redirected to = coap://sensor2.example.org/ Or maybe you want to separate the different functions of the gateway = into different domain names that resolve to the same IP? coap://cache.example.org/ implements the caching feature coap://http.example.org/ implements HTTP translation coap://6to4.example.org/ implements IPv6 to IPv4 translation But then I suppose it could also be defined like that: coap://gateway.example.org/cache/ coap://gateway.example.org/http/ coap://gateway.example.org/6to4/ On the other hand a gateway acting as a transparent/interception proxy = will use some IP magic to answer on the behalf of the origin server. In = that case the gateway only uses the authority part of the URI (or the = destination address). But transparent proxying requires some advanced IP = stack features that are not always available: 1. Redirect sessions destined to the outer network to a local process = using a packet filter rule. 2. Make it possible for a process to listen to connections on a foreign = address. 3. Make it possible for a process to initiate a connection with a = foreign address as a source. Could you please tell me if something is wrong with my reasoning? Regards, Matthieu ------_=_NextPart_001_01CB8AF5.74C3EA71 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A=
    =0A=
    Matthieu,
    =0A=
     
    =0A=
    Very good points!
    =0A=
     
    =0A=
    <Quote>
    =0A=
    On the other hand a gateway acting as a = transparent/interception proxy will use some IP magic to answer on the = behalf of the origin server. In that case the gateway only uses the = authority part of the URI (or the destination address). But transparent = proxying requires some advanced IP stack features that are not always = available:
    1. Redirect sessions destined to the outer network to a = local process using a packet filter rule.
    2. = Make it possible for a process to listen to connections on a foreign = address.
    3. Make it possible for a process to = initiate a connection with a foreign address as a = source.
    =0A=
    </Quote>
    =0A=
     
    =0A=
    This is one component I would actually expect to see in = CoRE environment, exactly because I do not want the Clients to be = bothered by the network topology.=0A=
    But what would we then call this beast?
    =0A=
     
    =0A=
    A "caching gateway" - or just a "gateway" and then = indicate in an option that it performs caching? 
    =0A=
     
    =0A=
    And something related but slightly different:
    =0A=
    How do I represent my advanced powerstrip device: Global = on/off + on/off per outlet   ?
    Depending on imlementation, = such multichannel devices may have one master IPv6 address + one IPv6 = address per outlet - or
    =0A=
    it may have only address and you access it via
    =0A=
    coap://bigbrother1.example.org/output/ = <- master on/off =
    coap://bigbrother1.example.org/1/output
    coap://bigbrother1.example= .org/2/output
    =0A=
    in the latter case, this is already = supported by coap - but if you have individual IPv6 addresses, as in the = first example,
    =0A=
    then I suppose that your device is a = server (the master on/off function) AND a gateway for the other IPv6 = addresses?
    =0A=
     
    =0A=
    coap://bigbrother1.example.org/output/ = <- master on/off =
    coap://bigbrother1-1.example.org/output
    =0A=
    coap://bigbrother1-2.example.org/output
    =0A=
    =0A=
    One could argue that this is just a = multihomed server - but in order to present these functions as one = physical instance
    in a management tool, my discovery process needs to = understand that there is a tight connection.
    =0A=
    While the URIs above might suggest that = there is such a connection, it is not explicit.
    =0A=
     
    =0A=
    Is this a gateway at all - or do we need a = third type: "MultiChannel server", where the master address advertizes = the other ones?
    =0A=
     
    =0A=
    Thanks,
    =0A=
      Anders
    =0A=

    =0A=
    =0A= Fra: core-bounces@ietf.org p=E5 = vegne af matthieu.vial@fr.non.schneider-electric.com
    Sendt: ti = 23-11-2010 01:57
    Til: Peter Bigot
    Cc: = core-bounces@ietf.org; core; Klaus Hartke
    Emne: Re: [core] = Proxy and server on the same port

    =0A=
    =0A=
      =0A=
        =0A=

        >>* A gateway (a.k.a., reverse proxy, big = brother, ...) is an
        >>intermediary imposed by the origin server = to support sleeping nodes or
        >>perform any other role that = might be hidden behind the authority part
        >>of a = URI.


    > Almost; the origin = server may be unaware of the presence of a gateway.  The network = may impose the gateway.

    I'm sorry but I = can't catch the exact meaning of "any other role that might be hidden = behind the authority part
    of a URI".
    A = gateway acting as a reverse proxy could for example implement a cache = for sleeping nodes. The reverse proxy can map the sleeping nodes into = its own namespace. In that case it's not just the authority part of the = URI but the full URI that is used to decide what should be = done.
    coap://bigbrother1.example.org/sensor1/ = is actually redirected to coap://sensor1.example.org/
    coap://bigbrother1.example.org/sensor2/ is actually redirected = to coap://sensor2.example.org/

    Or maybe you = want to separate the different functions of the gateway into different = domain names that resolve to the same IP?
    coap://cache.example.org/ implements the caching = feature
    coap://http.example.org/ implements = HTTP translation
    coap://6to4.example.org/ = implements IPv6 to IPv4 translation
    But then I = suppose it could also be defined like that:
    coap://gateway.example.org/cache/
    coap://gateway.example.org/http/
    coap://gateway.example.org/6to4/

    On the other hand a gateway acting as a = transparent/interception proxy will use some IP magic to answer on the = behalf of the origin server. In that case the gateway only uses the = authority part of the URI (or the destination address). But transparent = proxying requires some advanced IP stack features that are not always = available:
    1. Redirect sessions destined to the = outer network to a local process using a packet filter = rule.
    2. Make it possible for a process to = listen to connections on a foreign address.
    3. = Make it possible for a process to initiate a connection with a foreign = address as a source.

    Could you please tell = me if something is wrong with my reasoning?

    Regards,
    Matthieu
    ------_=_NextPart_001_01CB8AF5.74C3EA71-- From pab@peoplepowerco.com Tue Nov 23 04:46:01 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0213C3A6939 for ; Tue, 23 Nov 2010 04:46:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SARE_RMML_Stock10=0.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sv04KJsl6D+Y for ; Tue, 23 Nov 2010 04:45:59 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 03B4B3A6924 for ; Tue, 23 Nov 2010 04:45:58 -0800 (PST) Received: by fxm3 with SMTP id 3so6008544fxm.31 for ; Tue, 23 Nov 2010 04:46:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.97.13 with SMTP id j13mr5639379fan.146.1290516415622; Tue, 23 Nov 2010 04:46:55 -0800 (PST) Received: by 10.223.70.198 with HTTP; Tue, 23 Nov 2010 04:46:55 -0800 (PST) In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E01AD4757@zensys17.zensys.local> References: <1909899D-43E8-4C00-B957-6787468B4CDB@sensinode.com> <6D9687E95918C04A8B30A7D6DA805A3E01AD4757@zensys17.zensys.local> Date: Tue, 23 Nov 2010 06:46:55 -0600 Message-ID: From: Peter Bigot To: Anders Brandt Content-Type: multipart/alternative; boundary=20cf3054a61587ae420495b7c4eb Cc: core , Klaus Hartke Subject: Re: [core] Proxy and server on the same port X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 12:46:01 -0000 --20cf3054a61587ae420495b7c4eb Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >From my perspective: why do you need to know? The client should transmit a request for data from a URI to some other node (either a proxy, or an end-point extracted from the URI authority). If it has "freshness" needs, it should incorporate a Max-Age option. Whether the response comes from the origin server or a cache somewhere between the client and the origin server should not be detectable by the client. An alternative model is to allow applications to be made aware of something that caches resource values and provides access to them through a different URI; e.g. if the client thinks that coap://bigben/temperature is too far away, it might GET coap://chicagocacher/bigben/temperature. Then the issue is how does it find out that chicagocacher exists and supports this sort of operation. That's a service discovery and resource discovery issue. Peter On Tue, Nov 23, 2010 at 2:31 AM, Anders Brandt wrote: > > So you do agree with what was in that email? I assumed the complete > lack of response meant nobody thought it relevant. > Actually, this thread is very relevant. > I am currently investigating CoAP multi-subnet environments with sleeping > nodes and I am very much in favor of a precise terminology. > > Unfortunately I am still not 100% up to speed on CoRE. What is the > preferred way of indicating that a node (typically the default gateway) > provides caching on behalf of other servers in the same subnet? and in > another subnet? > > Thanks, > Anders > > ------------------------------ > *Fra:* core-bounces@ietf.org p=E5 vegne af Peter Bigot > *Sendt:* ma 22-11-2010 10:53 > *Til:* Klaus Hartke > *Cc:* core > *Emne:* Re: [core] Proxy and server on the same port > > On Mon, Nov 22, 2010 at 11:22 AM, Klaus Hartke wrote: > >> Peter Bigot wrote: >> >> I think it makes a lot of sense to distinguish between end-points tha= t >> >> act on behalf of a client and those that act on behalf of a server. >> >> Not sure what needs to be discussed (apart maybe from the actual term= s >> >> used for the two roles). >> > >> > Just that I proposed completely rewriting section five to get CoAP to >> use >> > specific terms in the way I described in my email, which would result = in >> a >> > significant change (clarification) to what "proxy" means, and a >> separation >> > of it from the concept of a "cache". Your comment above is not the sa= me >> > thing, and since nobody else has commented I don't think my email shou= ld >> be >> > the basis of a ticket. >> >> I thought my comment above would capture the essence of your email, >> but apparently it didn't. > > > Sorry, I didn't read it that way. > > >> So here's an attempt at a more complete >> summary of your email: >> >> * Intermediary CoAP end-points act as both a client and a server in >> order to forward, with possible translation, requests and responses. >> > > OK. > > * A proxy is an intermediary selected by a client. A client can >> delegate all CoAP requests it can't do itself to a proxy. >> Configuration of this proxy for a particular node is an administrative >> function outside the scope of CoAP. >> > > Yes. > > * A gateway (a.k.a., reverse proxy, big brother, ...) is an >> intermediary imposed by the origin server to support sleeping nodes or >> perform any other role that might be hidden behind the authority part >> of a URI. >> > > Almost; the origin server may be unaware of the presence of a gateway. > The network may impose the gateway. > > * Caching in turn is a function that may be paired with a proxy or >> with a gateway, but is not inherently coupled to either one. >> > > Yes. > > >> Please correct me if I'm missing something essential. >> > > Not at first glance, > > So you do agree with what was in that email? I assumed the complete lack > of response meant nobody thought it relevant. > > >> > In what I proposed, a client is specifically configured to use a >> (single) >> > proxy, and that proxy is providing specific enhanced services on behal= f >> of >> > the client. With that model it makes little sense to accommodate >> placing >> > the proxy at the same end-point (port) as a normal server. >> > >> > However, if there's no buy-in for that change, and there's some >> compelling >> > reason why we should accommodate two applications at a single port, I >> > suppose a set of rules to use UriScheme values as a cue to whether a >> request >> > might have been intended for a proxy or a server could be made to work= . >> > "Don't do that" seems like a better approach, in my opinion. >> >> There are two things: >> >> 1. Does it make sense to run a proxy and a server on the same port? >> >> The answer is probably: No. >> > > Good. > > 2. What to do when a client thinks an end-point is a server when it's >> actually a proxy? >> > > Ah. I lost the context from the earlier parts of the thread, and assumed > your proposal was a way to allow dual-use. In fact, your rules seem to b= e a > complete workable solution that does allow dual use. Nice. That's not w= hat > raised my hackles. > > The solution is to have the client say what it thinks, so that its >> wrong assumption can be pointed out by the recipient. >> > > That is a good solution. But in the details, I think it would be more > clear if the client does say what it thinks (that it's talking with a > proxy), rather than creating complex rules on how to interpret Uri-Scheme= to > infer that it thinks it's talking with a proxy. So use a new option name= d > Uri-Proxy with no value, the presence/absence of which indicates the > client's expectations. Don't overload Uri-Scheme to mean something weird > that could conflict with future use, e.g. putting a coap and a coapm > (multicast) service on the same port. > > Change Uri-Scheme to Uri-Proxy in your proposal and you've got a solution > that allows disambiguation while at the same time allowing both functions= to > occur on the same port and not muddying what Uri-Scheme means. That's th= e > sort of approach I like: one technique that solves multiple problems > without introducing new ones. Barring some undiscovered flaw, I'd suppor= t > that. > > >> >> Klaus >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> > > --20cf3054a61587ae420495b7c4eb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >From my perspective: why do you need to know?

    The client should tran= smit a request for data from a URI to some other node (either a proxy, or a= n end-point extracted from the URI authority).=A0 If it has "freshness= " needs, it should incorporate a Max-Age option.=A0 Whether the respon= se comes from the origin server or a cache somewhere between the client and= the origin server should not be detectable by the client.

    An alternative model is to allow applications to be made aware of somet= hing that caches resource values and provides access to them through a diff= erent URI; e.g. if the client thinks that coap://bigben/temperature is too = far away, it might GET coap://chicagocacher/bigben/temperature.=A0 Then the= issue is how does it find out that chicagocacher exists and supports this = sort of operation.=A0 That's a service discovery and resource discovery= issue.

    Peter

    On Tue, Nov 23, 2010 at 2:31 AM= , Anders Brandt <ab= r@sdesigns.dk> wrote:
    > So you do agree with what was in tha= t email?=A0 I assumed the complete lack of response meant nobody thought it= relevant.
    Ac= tually, this thread is very relevant.
    I am currently investigati= ng CoAP multi-subnet environments with sleeping nodes and I am very much in= favor of a precise terminology.
    =A0
    Unfortunately I am still n= ot 100% up to speed on CoRE. What is the preferred way of indicating that a= node (typically the default gateway) provides caching on behalf of other s= ervers in the same subnet? and in another subnet?
    =A0
    Thanks,
    =A0 Anders

    Fra: core-bounces@ietf.org p=E5 vegne af Peter = Bigot
    Sendt: ma 22-11-2010 10:53
    Til: Klaus Hartke
    <= b>Cc: core
    Emne: Re: [core] Proxy and server on the same port

    On Mon, Nov 22, 2010 at 11:22 AM, Klaus Hartke <= span dir=3D"ltr"><ha= rtke@tzi.org> wrote:
    Peter Bigot wrote:
    >> I think it makes a lot of sense to dist= inguish between end-points that
    >> act on behalf of a client and t= hose that act on behalf of a server.
    >> Not sure what needs to be = discussed (apart maybe from the actual terms
    >> used for the two roles).
    >
    > Just that I proposed comp= letely rewriting section five to get CoAP to use
    > specific terms in = the way I described in my email, which would result in a
    > significan= t change (clarification) to what "proxy" means, and a separation<= br> > of it from the concept of a "cache".=A0 Your comment above i= s not the same
    > thing, and since nobody else has commented I don'= ;t think my email should be
    > the basis of a ticket.

    I t= hought my comment above would capture the essence of your email,
    but apparently it didn't.

    Sorry,=A0 I didn't read it that way.
    =A0
    So here's an = attempt at a more complete
    summary of your email:

    * Intermediary = CoAP end-points act as both a client and a server in
    order to forward, with possible translation, requests and responses.

    OK.

    * A proxy is an i= ntermediary selected by a client. A client can
    delegate all CoAP request= s it can't do itself to a proxy.
    Configuration of this proxy for a particular node is an administrative
    f= unction outside the scope of CoAP.

    Yes.

    * A gateway (a.k.= a., reverse proxy, big brother, ...) is an
    intermediary imposed by the o= rigin server to support sleeping nodes or
    perform any other role that might be hidden behind the authority part
    of= a URI.

    =A0Almost; the origin server may be unaware of the presence of a g= ateway.=A0 The network may impose the gateway.

    * Caching in turn= is a function that may be paired with a proxy or
    with a gateway, but is= not inherently coupled to either one.

    Yes.
    =A0
    Please correct me= if I'm missing something essential.

    Not at first glance,

    So you do agree with what was in that = email?=A0 I assumed the complete lack of response meant nobody thought it r= elevant.
    =A0
    > In what I proposed, a client is specifically configured to use a = (single)
    > proxy, and that proxy is providing specific enhanced servi= ces on behalf of
    > the client.=A0 With that model it makes little sen= se to accommodate placing
    > the proxy at the same end-point (port) as a normal server.
    >
    = > However, if there's no buy-in for that change, and there's som= e compelling
    > reason why we should accommodate two applications at a= single port, I
    > suppose a set of rules to use UriScheme values as a cue to whether a r= equest
    > might have been intended for a proxy or a server could be ma= de to work.
    > "Don't do that" seems like a better appro= ach, in my opinion.

    There are two things:

    1. Does it make sense to run a proxy= and a server on the same port?

    The answer is probably: No.

    Good.

    2. What to do whe= n a client thinks an end-point is a server when it's
    actually a prox= y?

    Ah.=A0 I lost the context from the earlier parts of the thread, an= d assumed your proposal was a way to allow dual-use. =A0In fact, your rules= seem to be a complete workable solution that does allow dual use. =A0Nice.= =A0That's not what raised my hackles.

    The solution is t= o have the client say what it thinks, so that its
    wrong assumption can b= e pointed out by the recipient.

    That is a good solution.=A0 But in the details, I think it would b= e more clear if the client does say what it thinks (that it's talking w= ith a proxy), rather than creating complex rules on how to interpret Uri-Sc= heme to infer that it thinks it's talking with a proxy.=A0 So use a new= option named Uri-Proxy with no value, the presence/absence of which indica= tes the client's expectations.=A0 Don't overload Uri-Scheme to mean= something weird that could conflict with future use, e.g. putting a coap a= nd a coapm (multicast) service on the same port.

    Change Uri-Scheme to Uri-Proxy in your proposal and you've got a so= lution that allows disambiguation while at the same time allowing both func= tions to occur on the same port and not muddying what Uri-Scheme means. =A0= That's the sort of approach I like: one technique that solves multiple = problems without=A0introducing new ones. =A0Barring some undiscovered flaw,= I'd support that.
    =A0

    Klaus
    _______________________________________________
    core m= ailing list
    core@ietf= .org
    https://www.ietf.org/mailman/listinfo/core


    --20cf3054a61587ae420495b7c4eb-- From pab@peoplepowerco.com Tue Nov 23 05:13:02 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E34ED3A6950 for ; Tue, 23 Nov 2010 05:13:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.952 X-Spam-Level: X-Spam-Status: No, score=-1.952 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0zFpyu+jU7q6 for ; Tue, 23 Nov 2010 05:13:01 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 816233A694C for ; Tue, 23 Nov 2010 05:13:00 -0800 (PST) Received: by fxm3 with SMTP id 3so6034590fxm.31 for ; Tue, 23 Nov 2010 05:13:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.104.68 with SMTP id n4mr3996491fao.127.1290518022372; Tue, 23 Nov 2010 05:13:42 -0800 (PST) Received: by 10.223.70.198 with HTTP; Tue, 23 Nov 2010 05:13:42 -0800 (PST) In-Reply-To: References: Date: Tue, 23 Nov 2010 07:13:42 -0600 Message-ID: From: Peter Bigot To: core , matthieu.vial@fr.non.schneider-electric.com, Klaus Hartke , Anders Brandt Content-Type: multipart/alternative; boundary=001636c9239e4cbcdb0495b824a9 Subject: Re: [core] Proxy versus Gateway X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 13:13:03 -0000 --001636c9239e4cbcdb0495b824a9 Content-Type: text/plain; charset=ISO-8859-1 I hope nobody minds, but I've transplanted this back to the original thread, with my original argument below. Though my corrections to Klaus's summary of what I said may be accurate, I'd prefer to not depend on that. Please refresh your memories of what I wrote last month, as I have done. (In particular, I don't want to lose my subtle other suggestion which is that "cache" needs to be refined, not just use of "proxy" and "gateway". Personally I'd like to see the entire semantic description of CoAP caching pulled out to another document, as I believe is being done in HTTPbis, leaving base CoAP to describe the generic encoding and method-independent transaction details.) Matthieu: All your cases are gateways. A gateway can operate at any level in the OSI stack. Those that operate at the application (CoAP) level may end up doing a translation that involves initiating a new CoAP request, potentially to a completely different URI, even one with a non-CoAP scheme. Such a node is a gateway because the authority part of the URI led the data flow to it. In my mind, there's no implication that a gateway is restricted from inspecting or manipulating other parts of the URI in order to fulfill its responsibilities (Fielding's list of gateway purposes should not be read as exhaustive). Do you feel that a further refinement to characterize types of gateway would improve an understanding of CoAP? Anders: As I suggested in my specific response to caching, neither the client nor the server should be aware that there are gateways between them, at least not at the REST level. Any such knowledge introduces coupling, and limits the ability of organizations to restructure their networks while providing the same resources via the same URIs. Peter On Tue, Nov 23, 2010 at 2:57 AM, < matthieu.vial@fr.non.schneider-electric.com> wrote: > > >>* A gateway (a.k.a., reverse proxy, big brother, ...) is an > >>intermediary imposed by the origin server to support sleeping > nodes or > >>perform any other role that might be hidden behind the authority > part > >>of a URI. > > > > Almost; the origin server may be unaware of the presence of a gateway. > The network may impose the gateway. > > I'm sorry but I can't catch the exact meaning of "any other role that might > be hidden behind the authority part > of a URI". > A gateway acting as a reverse proxy could for example implement a cache for > sleeping nodes. The reverse proxy can map the sleeping nodes into its own > namespace. In that case it's not just the authority part of the URI but the > full URI that is used to decide what should be done. > coap://bigbrother1.example.org/sensor1/ is actually redirected to coap:// > sensor1.example.org/ > coap://bigbrother1.example.org/sensor2/ is actually redirected to coap:// > sensor2.example.org/ > > Or maybe you want to separate the different functions of the gateway into > different domain names that resolve to the same IP? > coap://cache.example.org/ implements the caching feature > coap://http.example.org/ implements HTTP translation > coap://6to4.example.org/ implements IPv6 to IPv4 translation > But then I suppose it could also be defined like that: > coap://gateway.example.org/cache/ > coap://gateway.example.org/http/ > coap://gateway.example.org/6to4/ > > On the other hand a gateway acting as a transparent/interception proxy will > use some IP magic to answer on the behalf of the origin server. In that case > the gateway only uses the authority part of the URI (or the destination > address). But transparent proxying requires some advanced IP stack features > that are not always available: > 1. Redirect sessions destined to the outer network to a local process > using a packet filter rule. > 2. Make it possible for a process to listen to connections on a foreign > address. > 3. Make it possible for a process to initiate a connection with a foreign > address as a source. > > Could you please tell me if something is wrong with my reasoning? > > Regards, > Matthieu > On Sat, Oct 23, 2010 at 5:55 AM, Peter Bigot wrote: > I and others have been somewhat confused by the CoAP terms "proxy" and > "cache", which unless clarified actually mix several concepts. I found > enlightenment in section 5.2.3 of Fielding's dissertation > : > > Intermediary components act as both a client and a server in order to > forward, with possible translation, requests and responses. A proxy > component is an intermediary selected by a client to provide interface > encapsulation of other services, data translation, performance enhancement, > or security protection. A gateway (a.k.a., reverse proxy) component is an > intermediary imposed by the network or origin server to provide an interface > encapsulation of other services, for data translation, performance > enhancement, or security enforcement. Note that the difference between a > proxy and a gateway is that a client determines when it will use a proxy. > > I had been misled because the non-technical use of the term "proxy" is > appropriate for several key roles in a CoAP system, including that entity > which serves as the intermediary for sleeping nodes. The correct term for > this function is "gateway", as most clients need not be aware that they are > acting through an intermediary. > > CoAP's use of the term "proxy" is inconsistent with these definitions: > > 5.3. Proxying A proxy is defined as a CoAP end-point which services cached requests > on behalf of other CoAP end-points. Any node in a CoAP network may > act as a proxy, although in general the node between the constrained > network and the Internet at large SHOULD always support proxy > functionality. > > This is misleading because it focuses solely on caching, leaving aside the > other reasons why a proxy might be necessary. As an example, many > constrained nodes will not support DNS, and therefore cannot translate an > ASCII authority found within a URI to a network address. Similarly, > constrained devices are unlikely to have the computational resources > necessary to support public key cryptography. It would be better to say > that a proxy is an intermediary explicitly selected by the client as its > agent when dealing with any transaction it is unable to perform directly. > > This is an important but currently implicit role in a CoAP system. As with > the traditional use of proxy in web browsers (back before desktops became > full participants in the Internet), a CoAP client should need only one proxy > to which it can delegate all CoAP transactions it can't do itself. > Configuration of this proxy for a particular node is an administrative > function outside the scope of CoAP as an on-wire protocol. (If multiple > proxies were expected at a client, there would have to be some way of > selecting which proxy to use for which operation, an unnecessary > complication that could easily be supported by delegation.) CoAP need > merely provide a mechanism by which the full information required to > delegate the transaction can be conveyed, which it does. > > I encourage use of the term "gateway" when referring to an entity that > supports sleeping nodes, coordinates group activities, or performs any other > role that might be hidden behind the authority part of a URI. > > Caching in turn is a function that may be paired with a proxy or with a > gateway, but is not inherently coupled to either one. > > If it's not too late to make so major a change in terminology and concept, > I would encourage a rewrite of section 5 to make clear that proxies, > gateways, and caches are independent functions. I would contribute text for > this if the editors would find that helpful. > > Peter > --001636c9239e4cbcdb0495b824a9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    I hope nobody minds, but I've transplanted t= his back to the original thread, with my original argument below.=A0 Though= my corrections to Klaus's summary of what I said may be accurate, I= 9;d prefer to not depend on that.=A0 Please refresh your memories of what I= wrote last month, as I have done.=A0 (In particular, I don't want to l= ose my subtle other suggestion which is that "cache" needs to be = refined, not just use of "proxy" and "gateway".=A0 Pers= onally I'd like to see the entire semantic description of CoAP caching = pulled out to another document, as I believe is being done in HTTPbis, leav= ing base CoAP to describe the generic encoding and method-independent trans= action details.)

    Matthieu:=A0 All your cases are gateways.=A0 A gateway can operate at a= ny level in the OSI stack.=A0 Those that operate at the application (CoAP) = level may end up doing a translation that involves initiating a new CoAP re= quest, potentially to a completely different URI, even one with a non-CoAP = scheme.=A0 Such a node is a gateway because the authority part of the URI l= ed the data flow to it.=A0 In my mind, there's no implication that a ga= teway is restricted from inspecting or manipulating other parts of the URI = in order to fulfill its responsibilities (Fielding's list of gateway pu= rposes should not be read as exhaustive).=A0 Do you feel that a further ref= inement to characterize types of gateway would improve an understanding of = CoAP?

    Anders: As I suggested in my specific response to caching, neither the = client nor the server should be aware that there are gateways between them,= at least not at the REST level.=A0 Any such knowledge introduces coupling,= and limits the ability of organizations to restructure their networks whil= e providing the same resources via the same URIs.

    Peter

    On Tue, Nov 23, 2010 at 2:57 AM, <matthieu.vial@= fr.non.schneider-electric.com> wrote:

        >>* A gateway (a.k.a., reverse proxy, big= brother, ...) is an
        >>intermediary imposed by the origin server to support sleeping nodes= or
        >>perform any other role that might be hidden behind the authority pa= rt
        >>of a URI.


    >=A0Almost; the origin server may be unaware of the presence of a gatewa= y.=A0 The network may impose the gateway.

    I'm sorry but I can't catch the exact meanin= g of "any other role that might be hidden behind the authority part of a URI".
    A gateway acting as a reverse proxy could for example=20 implement a cache for sleeping nodes. The reverse proxy can map the=20 sleeping nodes into its own namespace. In that case it's not just the= =20 authority part of the URI but the full URI that is used to decide what=20 should be done.
    coap://bigbrother1.example.org/sensor1/ is actually redirec= ted to coap://sen= sor1.example.org/
    coap://bigbrother1.example.org/sensor2/ is actually redirec= ted to coap://sen= sor2.example.org/

    Or maybe you want to separate the different functions of t= he gateway into different domain names that resolve to the same IP?<= br> coap://cache.example.org/ implements the caching feature
    coap://http.example.org/ implements HTTP translation
    coap://6to4.example.org/ implements IPv6 to IPv4 translation
    But then I suppose it could also be defined like that:
    coap://gateway.example.org/cache/
    coap://gateway.example.org/http/
    coap://gateway.example.org/6to4/

    On the other hand a gateway acting as a=20 transparent/interception proxy will use some IP magic to answer on the=20 behalf of the origin server. In that case the gateway only uses the=20 authority part of the URI (or the destination address). But transparent=20 proxying requires some advanced IP stack features that are not always=20 available:
    1. Redirect sessions destined to the outer network to a= local process using a packet filter rule.
    2. Make it possible for a process to listen to connecti= ons on a foreign address.
    3. Make it possible for a process to initiate a connect= ion with a foreign address as a source.

    Could you please tell me if something is wrong with my rea= soning?

    Regards,
    Matthieu


    On Sat, Oct 23, 2010 at 5:55 AM, Peter Bigot <pab@peoplepowerco.com= > wrote:
    I and others have= been somewhat confused by the CoAP terms "proxy" and "cache= ", which unless clarified actually mix several concepts.=A0 I found en= lightenment in section 5.2.3 of Field= ing's dissertation:

    Intermediary components act as both a= client and a server in order to=20 forward, with possible translation, requests and responses. A proxy=20 component is an intermediary selected by a client to provide interface=20 encapsulation of other services, data translation, performance=20 enhancement, or security protection. A gateway (a.k.a., reverse proxy)=20 component is an intermediary imposed by the network or origin server to=20 provide an interface encapsulation of other services, for data=20 translation, performance enhancement, or security enforcement. Note that the difference between a proxy and a gateway is that a client=20 determines when it will use a proxy.

    I had been misled because= the non-technical use of the term "proxy" is appropriate for sev= eral key roles in a CoAP system, including that entity which serves as the = intermediary for sleeping nodes.=A0 The correct term for this function is &= quot;gateway", as most clients need not be aware that they are acting = through an intermediary.

    CoAP's use of the term "proxy" is inconsistent with these= definitions:
    5.=
3.  Proxying
    =A0=A0 A proxy is defined as a CoAP end-point w=
hich services cached requests
   on behalf of other CoAP end-points.  Any node in a CoAP network may
   act as a proxy, although in general the node between the constrained
   network and the Internet at large SHOULD always support proxy
   functionality.
    This is misleading because it focuses solely on caching, leaving asid= e the other reasons why a proxy might be necessary.=A0=A0 As an example, ma= ny constrained nodes=A0 will not support DNS, and=20 therefore cannot translate an ASCII authority found within a URI to a=20 network address. =A0 Similarly, constrained devices are unlikely to have th= e computational resources necessary to support public key cryptography. =A0= It would be better to say that a proxy is an intermediary explicitly selec= ted by the client as its agent when dealing with any transaction it is unab= le to perform directly.

    This is an important but currently implicit role in a CoAP system.=A0 A= s with the traditional use of proxy in web browsers (back before desktops b= ecame full participants in the Internet), a CoAP client should need only on= e proxy to which it can delegate all CoAP transactions it can't do itse= lf.=A0 Configuration of this proxy for a particular node is an administrati= ve function outside the scope of CoAP as an on-wire protocol.=A0 (If multip= le proxies were expected at a client, there would have to be some way of se= lecting which proxy to use for which operation, an unnecessary complication= that could easily be supported by delegation.)=A0 CoAP need merely provide= a mechanism by which the full information required to delegate the transac= tion can be conveyed, which it does.

    I encourage use of the term "gateway" when referring to an en= tity that supports sleeping nodes, coordinates group activities, or perform= s any other role that might be hidden behind the authority part of a URI.
    Caching in turn is a function that may be paired with a proxy or with a= =20 gateway, but is not inherently coupled to either one.

    If it's not too late to make so major a change in terminology and conce= pt, I would encourage a rewrite of section=20 5 to make clear that proxies,=A0 gateways, and caches are independent funct= ions.=A0 I would contribute text for this if the editors would find that he= lpful.

    Peter

    --001636c9239e4cbcdb0495b824a9-- From abr@sdesigns.dk Tue Nov 23 05:15:22 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73D2D3A694D for ; Tue, 23 Nov 2010 05:15:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.378 X-Spam-Level: X-Spam-Status: No, score=-2.378 tagged_above=-999 required=5 tests=[AWL=0.694, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, SARE_RMML_Stock10=0.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g94OIYDl5G6W for ; Tue, 23 Nov 2010 05:15:20 -0800 (PST) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id EA8593A694C for ; Tue, 23 Nov 2010 05:15:19 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB8B10.9C5F06C7" Date: Tue, 23 Nov 2010 14:16:16 +0100 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01AD475D@zensys17.zensys.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] Proxy and server on the same port Thread-Index: AcuLDINWfQvS3aFFT+CRVLtCzkdXDwAAYAbz References: <1909899D-43E8-4C00-B957-6787468B4CDB@sensinode.com><6D9687E95918C04A8B30A7D6DA805A3E01AD4757@zensys17.zensys.local> From: "Anders Brandt" To: "Peter Bigot" Cc: core , Klaus Hartke Subject: Re: [core] Proxy and server on the same port X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 13:15:22 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB8B10.9C5F06C7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Peter =20 > From my perspective: why do you need to know? One one hand I agree with you. When rootcausing an issue in my network I = may like to know... I imagine my gateway just returns "/caching=3DTRUE" (Zach may come up = with a one-letter code for this standard path) The example of going to coap://chicagocacher in a sort of redirect was = not what I was looking for. My main intention is (as stated in the CoAP = spec): 1) to save network bandwidth, 2) discover sleeping nodes =20 >... Then the issue is how does it find out that chicagocacher exists = and supports this sort of operation.=20 > That's a service discovery and resource discovery issue. =20 Agree 100%=20 My main reason for responding is exactly discovery. For achieving a plug-and-play experience across subnets I have a need = for identifying gateways and asking them what interfaces they have on = their other side. Then I can go ask these interfaces to report local = CoAP hosts, and so on. Every time, these hosts may be cached or = discovered on demand via multicast if relevant. This can be done in a hierarchical, de-centralised fashion where no = gateways have to store any information that is already stored in other gateways. Only the client running the discovery will get the full picture of all = nodes in all subnets. Do you follow me? Thanks, Anders ________________________________ Fra: Peter Bigot [mailto:pab@peoplepowerco.com] Sendt: ti 23-11-2010 05:46 Til: Anders Brandt Cc: Klaus Hartke; core Emne: Re: [core] Proxy and server on the same port >From my perspective: why do you need to know? The client should transmit a request for data from a URI to some other = node (either a proxy, or an end-point extracted from the URI authority). = If it has "freshness" needs, it should incorporate a Max-Age option. = Whether the response comes from the origin server or a cache somewhere = between the client and the origin server should not be detectable by the = client. An alternative model is to allow applications to be made aware of = something that caches resource values and provides access to them = through a different URI; e.g. if the client thinks that = coap://bigben/temperature is too far away, it might GET = coap://chicagocacher/bigben/temperature. Then the issue is how does it = find out that chicagocacher exists and supports this sort of operation. = That's a service discovery and resource discovery issue. Peter On Tue, Nov 23, 2010 at 2:31 AM, Anders Brandt wrote: > So you do agree with what was in that email? I assumed the complete = lack of response meant nobody thought it relevant. =09 Actually, this thread is very relevant. I am currently investigating CoAP multi-subnet environments with = sleeping nodes and I am very much in favor of a precise terminology. =20 Unfortunately I am still not 100% up to speed on CoRE. What is the = preferred way of indicating that a node (typically the default gateway) = provides caching on behalf of other servers in the same subnet? and in = another subnet? =20 Thanks, Anders ________________________________ Fra: core-bounces@ietf.org p=E5 vegne af Peter Bigot Sendt: ma 22-11-2010 10:53 Til: Klaus Hartke Cc: core Emne: Re: [core] Proxy and server on the same port =09 =09 On Mon, Nov 22, 2010 at 11:22 AM, Klaus Hartke wrote: =09 Peter Bigot wrote: >> I think it makes a lot of sense to distinguish between end-points = that >> act on behalf of a client and those that act on behalf of a server. >> Not sure what needs to be discussed (apart maybe from the actual = terms >> used for the two roles). > > Just that I proposed completely rewriting section five to get CoAP = to use > specific terms in the way I described in my email, which would = result in a > significant change (clarification) to what "proxy" means, and a = separation > of it from the concept of a "cache". Your comment above is not the = same > thing, and since nobody else has commented I don't think my email = should be > the basis of a ticket. =09 =09 I thought my comment above would capture the essence of your email, but apparently it didn't. Sorry, I didn't read it that way. =20 =09 So here's an attempt at a more complete summary of your email: =09 * Intermediary CoAP end-points act as both a client and a server in order to forward, with possible translation, requests and responses. =09 OK.=20 =09 =09 * A proxy is an intermediary selected by a client. A client can delegate all CoAP requests it can't do itself to a proxy. Configuration of this proxy for a particular node is an administrative function outside the scope of CoAP. =09 Yes.=20 =09 =09 * A gateway (a.k.a., reverse proxy, big brother, ...) is an intermediary imposed by the origin server to support sleeping nodes or perform any other role that might be hidden behind the authority part of a URI. =09 Almost; the origin server may be unaware of the presence of a gateway. = The network may impose the gateway. =09 =09 * Caching in turn is a function that may be paired with a proxy or with a gateway, but is not inherently coupled to either one. =09 Yes. =20 =09 Please correct me if I'm missing something essential. =09 Not at first glance, =09 So you do agree with what was in that email? I assumed the complete = lack of response meant nobody thought it relevant. =20 > In what I proposed, a client is specifically configured to use a = (single) > proxy, and that proxy is providing specific enhanced services on = behalf of > the client. With that model it makes little sense to accommodate = placing > the proxy at the same end-point (port) as a normal server. > > However, if there's no buy-in for that change, and there's some = compelling > reason why we should accommodate two applications at a single port, = I > suppose a set of rules to use UriScheme values as a cue to whether a = request > might have been intended for a proxy or a server could be made to = work. > "Don't do that" seems like a better approach, in my opinion. =09 =09 There are two things: =09 1. Does it make sense to run a proxy and a server on the same port? =09 The answer is probably: No. =09 Good. =09 =09 2. What to do when a client thinks an end-point is a server when it's actually a proxy? =09 Ah. I lost the context from the earlier parts of the thread, and = assumed your proposal was a way to allow dual-use. In fact, your rules = seem to be a complete workable solution that does allow dual use. Nice. = That's not what raised my hackles. =09 =09 The solution is to have the client say what it thinks, so that its wrong assumption can be pointed out by the recipient. =09 That is a good solution. But in the details, I think it would be more = clear if the client does say what it thinks (that it's talking with a = proxy), rather than creating complex rules on how to interpret = Uri-Scheme to infer that it thinks it's talking with a proxy. So use a = new option named Uri-Proxy with no value, the presence/absence of which = indicates the client's expectations. Don't overload Uri-Scheme to mean = something weird that could conflict with future use, e.g. putting a coap = and a coapm (multicast) service on the same port. =09 Change Uri-Scheme to Uri-Proxy in your proposal and you've got a = solution that allows disambiguation while at the same time allowing both = functions to occur on the same port and not muddying what Uri-Scheme = means. That's the sort of approach I like: one technique that solves = multiple problems without introducing new ones. Barring some = undiscovered flaw, I'd support that. =20 =09 Klaus _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core =09 ------_=_NextPart_001_01CB8B10.9C5F06C7 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A=
    =0A=
    Hi Peter
    =0A=
     
    =0A=
    > From my perspective: why do you = need to know?
    =0A=

    One one hand I agree with you. = When rootcausing an issue in my network I may like to = know...
    =0A=
    I imagine my gateway just returns = "/caching=3DTRUE" (Zach may come up with a one-letter code for this = standard path)
    =0A=
    The example of going to coap://chicagocacher in a sort of = redirect was not what I was looking for. My main intention is (as stated = in the CoAP spec): 1) to save network bandwidth, 2) discover = sleeping nodes
    =0A=
     
    =0A=
    >...  Then the issue is how = does it find out that chicagocacher exists and supports this sort of = operation. 
    =0A=
    > That's a service discovery and = resource discovery issue.
    =0A=
     
    =0A=
    Agree 100%=0A=
    My main reason for responding is exactly discovery.
    =0A=
    For achieving a plug-and-play experience across subnets I = have a need for identifying gateways and asking them what interfaces = they have on their other side. Then I can go ask these interfaces to = report local CoAP hosts, and so on. Every time, these hosts may be = cached or discovered on demand via multicast if relevant.
    =0A=
    This can be done in a hierarchical, de-centralised = fashion where no gateways have to store any information
    =0A=
    that is already stored in other gateways.
    =0A=
    Only the client running the discovery will get the full = picture of all nodes in all subnets.
    =0A=

    Do you follow me?
    =0A=
    Thanks,
    =0A=
      Anders
    =0A=

    =0A=
    =0A= Fra: Peter Bigot = [mailto:pab@peoplepowerco.com]
    Sendt: ti 23-11-2010 = 05:46
    Til: Anders Brandt
    Cc: Klaus Hartke; = core
    Emne: Re: [core] Proxy and server on the same = port

    =0A=
    From my perspective: why do you need to know?

    The client = should transmit a request for data from a URI to some other node (either = a proxy, or an end-point extracted from the URI authority).  If it = has "freshness" needs, it should incorporate a Max-Age option.  = Whether the response comes from the origin server or a cache somewhere = between the client and the origin server should not be detectable by the = client.

    An alternative model is to allow applications to be made = aware of something that caches resource values and provides access to = them through a different URI; e.g. if the client thinks that = coap://bigben/temperature is too far away, it might GET = coap://chicagocacher/bigben/temperature.  Then the issue is how = does it find out that chicagocacher exists and supports this sort of = operation.  That's a service discovery and resource discovery = issue.

    Peter

    =0A=
    On Tue, Nov 23, 2010 at 2:31 AM, Anders Brandt = <abr@sdesigns.dk> wrote:
    =0A=
    =0A=
    =0A=
    =0A=
    =0A=
    > So you do agree with what was in that = email?  I assumed the complete lack of response meant nobody = thought it relevant.
    =0A=
    Actually, = this thread is very relevant.
    =0A=
    I am currently investigating = CoAP multi-subnet environments with sleeping nodes and I am very much in = favor of a precise terminology.
    =0A=
     
    =0A=
    Unfortunately I am still not = 100% up to speed on CoRE. What is the preferred way of indicating that a = node (typically the default gateway) provides caching on behalf of other = servers in the same subnet? and in another subnet?
    =0A=
     
    =0A=
    Thanks,
    =0A=
      = Anders
    =0A=

    =0A=
    =0A= Fra: core-bounces@ietf.org p=E5 vegne af Peter = Bigot
    Sendt: ma 22-11-2010 10:53
    Til: Klaus = Hartke
    Cc: core
    Emne: Re: [core] Proxy and server on = the same port

    =0A=
    =0A=
    =0A=
    =0A=
    =0A=
    On Mon, Nov 22, 2010 at 11:22 AM, Klaus Hartke = <hartke@tzi.org> wrote:
    =0A=
    =0A=
    Peter Bigot wrote:
    >> I think it makes a lot of sense to = distinguish between end-points that
    >> act on behalf of a = client and those that act on behalf of a server.
    >> Not sure = what needs to be discussed (apart maybe from the actual = terms
    >> used for the two roles).
    >
    > Just that I = proposed completely rewriting section five to get CoAP to use
    > = specific terms in the way I described in my email, which would result in = a
    > significant change (clarification) to what "proxy" means, and = a separation
    > of it from the concept of a "cache".  Your = comment above is not the same
    > thing, and since nobody else has = commented I don't think my email should be
    > the basis of a = ticket.

    I thought my comment above would capture the = essence of your email,
    but apparently it didn't.
    =0A=

    Sorry,  I didn't read it that way.
     
    =0A=
    So here's an = attempt at a more complete
    summary of your email:

    * = Intermediary CoAP end-points act as both a client and a server = in
    order to forward, with possible translation, requests and = responses.
    =0A=

    OK.

    =0A=
    * A proxy is = an intermediary selected by a client. A client can
    delegate all CoAP = requests it can't do itself to a proxy.
    Configuration of this proxy = for a particular node is an administrative
    function outside the scope = of CoAP.
    =0A=

    Yes.

    =0A=
    * A gateway = (a.k.a., reverse proxy, big brother, ...) is an
    intermediary imposed = by the origin server to support sleeping nodes or
    perform any other = role that might be hidden behind the authority part
    of a = URI.
    =0A=

     Almost; the origin server may be unaware of the presence = of a gateway.  The network may impose the gateway.

    =0A=
    * Caching in = turn is a function that may be paired with a proxy or
    with a gateway, = but is not inherently coupled to either one.
    =0A=

    Yes.
     
    =0A=
    Please correct = me if I'm missing something essential.
    =0A=

    Not at first glance,

    So you do agree with what was in = that email?  I assumed the complete lack of response meant nobody = thought it relevant.
     
    =0A=
    =0A=
    > In what I proposed, a client is specifically configured to use = a (single)
    > proxy, and that proxy is providing specific enhanced = services on behalf of
    > the client.  With that model it makes = little sense to accommodate placing
    > the proxy at the same = end-point (port) as a normal server.
    >
    > However, if there's = no buy-in for that change, and there's some compelling
    > reason = why we should accommodate two applications at a single port, I
    > = suppose a set of rules to use UriScheme values as a cue to whether a = request
    > might have been intended for a proxy or a server could = be made to work.
    > "Don't do that" seems like a better approach, = in my opinion.

    There are two things:

    1. Does it make = sense to run a proxy and a server on the same port?

    The answer is = probably: No.
    =0A=

    Good.

    =0A=
    2. What to do = when a client thinks an end-point is a server when it's
    actually a = proxy?
    =0A=

    Ah.  I lost the context from the earlier parts of the = thread, and assumed your proposal was a way to allow dual-use.  In = fact, your rules seem to be a complete workable solution that does allow = dual use.  Nice.  That's not what raised my = hackles.

    =0A=
    The solution = is to have the client say what it thinks, so that its
    wrong = assumption can be pointed out by the recipient.
    =0A=

    That is a good solution.  But in the details, I think it = would be more clear if the client does say what it thinks (that it's = talking with a proxy), rather than creating complex rules on how to = interpret Uri-Scheme to infer that it thinks it's talking with a = proxy.  So use a new option named Uri-Proxy with no value, the = presence/absence of which indicates the client's expectations.  = Don't overload Uri-Scheme to mean something weird that could conflict = with future use, e.g. putting a coap and a coapm (multicast) service on = the same port.

    Change Uri-Scheme to Uri-Proxy in your proposal = and you've got a solution that allows disambiguation while at the same = time allowing both functions to occur on the same port and not muddying = what Uri-Scheme means.  That's the sort of approach I like: one = technique that solves multiple problems without introducing new = ones.  Barring some undiscovered flaw, I'd support = that.
     
    =0A=
    =0A=
    =0A=
    =0A=

    Klaus
    _______________________________________________
    core= mailing list
    core@ietf.org
    https://www.ietf.org/mailman/listinfo/core
    <= /DIV>

    =0A=
    =0A= =0A=
    ------_=_NextPart_001_01CB8B10.9C5F06C7-- From abr@sdesigns.dk Tue Nov 23 05:16:50 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D843128C0CE for ; Tue, 23 Nov 2010 05:16:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.506 X-Spam-Level: X-Spam-Status: No, score=-1.506 tagged_above=-999 required=5 tests=[AWL=-0.304, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sN2O4PMW-EZc for ; Tue, 23 Nov 2010 05:16:48 -0800 (PST) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id EA5DF3A6950 for ; Tue, 23 Nov 2010 05:16:47 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB8B10.D0DC4C2F" Date: Tue, 23 Nov 2010 14:17:07 +0100 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01AD475E@zensys17.zensys.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proxy versus Gateway Thread-Index: AcuLEEnTBXKdx6CbQnGEQ+1PInsiKAAAHB25 References: From: "Anders Brandt" To: "Peter Bigot" , "core" , , "Klaus Hartke" Subject: Re: [core] Proxy versus Gateway X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 13:16:50 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB8B10.D0DC4C2F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >Anders: As I suggested in my specific response to caching, neither the = client nor the server >should be aware that there are gateways between them, at least not at = the REST level.=20 >Any such knowledge introduces coupling, and limits the ability of = organizations to restructure >their networks while providing the same resources via the same URIs. Agreed! ________________________________ Fra: Peter Bigot [mailto:pab@peoplepowerco.com] Sendt: ti 23-11-2010 06:13 Til: core; matthieu.vial@fr.non.schneider-electric.com; Klaus Hartke; = Anders Brandt Emne: Re: Proxy versus Gateway I hope nobody minds, but I've transplanted this back to the original = thread, with my original argument below. Though my corrections to = Klaus's summary of what I said may be accurate, I'd prefer to not depend = on that. Please refresh your memories of what I wrote last month, as I = have done. (In particular, I don't want to lose my subtle other = suggestion which is that "cache" needs to be refined, not just use of = "proxy" and "gateway". Personally I'd like to see the entire semantic = description of CoAP caching pulled out to another document, as I believe = is being done in HTTPbis, leaving base CoAP to describe the generic = encoding and method-independent transaction details.) Matthieu: All your cases are gateways. A gateway can operate at any = level in the OSI stack. Those that operate at the application (CoAP) = level may end up doing a translation that involves initiating a new CoAP = request, potentially to a completely different URI, even one with a = non-CoAP scheme. Such a node is a gateway because the authority part of = the URI led the data flow to it. In my mind, there's no implication = that a gateway is restricted from inspecting or manipulating other parts = of the URI in order to fulfill its responsibilities (Fielding's list of = gateway purposes should not be read as exhaustive). Do you feel that a = further refinement to characterize types of gateway would improve an = understanding of CoAP? Anders: As I suggested in my specific response to caching, neither the = client nor the server should be aware that there are gateways between = them, at least not at the REST level. Any such knowledge introduces = coupling, and limits the ability of organizations to restructure their = networks while providing the same resources via the same URIs. Peter On Tue, Nov 23, 2010 at 2:57 AM, = wrote: >>* A gateway (a.k.a., reverse proxy, big brother, ...) is an >>intermediary imposed by the origin server to support sleeping nodes = or >>perform any other role that might be hidden behind the authority = part >>of a URI. =09 > Almost; the origin server may be unaware of the presence of a = gateway. The network may impose the gateway. =09 =09 I'm sorry but I can't catch the exact meaning of "any other role that = might be hidden behind the authority part of a URI".=20 A gateway acting as a reverse proxy could for example implement a cache = for sleeping nodes. The reverse proxy can map the sleeping nodes into = its own namespace. In that case it's not just the authority part of the = URI but the full URI that is used to decide what should be done. coap://bigbrother1.example.org/sensor1/ is actually redirected to = coap://sensor1.example.org/ coap://bigbrother1.example.org/sensor2/ is actually redirected to = coap://sensor2.example.org/ =09 Or maybe you want to separate the different functions of the gateway = into different domain names that resolve to the same IP? coap://cache.example.org/ implements the caching feature coap://http.example.org/ implements HTTP translation coap://6to4.example.org/ implements IPv6 to IPv4 translation But then I suppose it could also be defined like that: coap://gateway.example.org/cache/ coap://gateway.example.org/http/ coap://gateway.example.org/6to4/ =09 On the other hand a gateway acting as a transparent/interception proxy = will use some IP magic to answer on the behalf of the origin server. In = that case the gateway only uses the authority part of the URI (or the = destination address). But transparent proxying requires some advanced IP = stack features that are not always available: 1. Redirect sessions destined to the outer network to a local process = using a packet filter rule. 2. Make it possible for a process to listen to connections on a foreign = address. 3. Make it possible for a process to initiate a connection with a = foreign address as a source. =09 Could you please tell me if something is wrong with my reasoning? =09 Regards, Matthieu On Sat, Oct 23, 2010 at 5:55 AM, Peter Bigot = wrote: I and others have been somewhat confused by the CoAP terms "proxy" and = "cache", which unless clarified actually mix several concepts. I found = enlightenment in section 5.2.3 of Fielding's dissertation = : =09 =09 Intermediary components act as both a client and a server in order to = forward, with possible translation, requests and responses. A proxy = component is an intermediary selected by a client to provide interface = encapsulation of other services, data translation, performance = enhancement, or security protection. A gateway (a.k.a., reverse proxy) = component is an intermediary imposed by the network or origin server to = provide an interface encapsulation of other services, for data = translation, performance enhancement, or security enforcement. Note that = the difference between a proxy and a gateway is that a client determines = when it will use a proxy. =09 I had been misled because the non-technical use of the term "proxy" is = appropriate for several key roles in a CoAP system, including that = entity which serves as the intermediary for sleeping nodes. The correct = term for this function is "gateway", as most clients need not be aware = that they are acting through an intermediary. =09 CoAP's use of the term "proxy" is inconsistent with these definitions: =09 =09 5.3. Proxying A proxy is defined as a CoAP end-point which services cached = requests on behalf of other CoAP end-points. Any node in a CoAP network may act as a proxy, although in general the node between the constrained network and the Internet at large SHOULD always support proxy functionality. This is misleading because it focuses solely on caching, leaving aside = the other reasons why a proxy might be necessary. As an example, many = constrained nodes will not support DNS, and therefore cannot translate = an ASCII authority found within a URI to a network address. Similarly, = constrained devices are unlikely to have the computational resources = necessary to support public key cryptography. It would be better to = say that a proxy is an intermediary explicitly selected by the client as = its agent when dealing with any transaction it is unable to perform = directly. =09 This is an important but currently implicit role in a CoAP system. As = with the traditional use of proxy in web browsers (back before desktops = became full participants in the Internet), a CoAP client should need = only one proxy to which it can delegate all CoAP transactions it can't = do itself. Configuration of this proxy for a particular node is an = administrative function outside the scope of CoAP as an on-wire = protocol. (If multiple proxies were expected at a client, there would = have to be some way of selecting which proxy to use for which operation, = an unnecessary complication that could easily be supported by = delegation.) CoAP need merely provide a mechanism by which the full = information required to delegate the transaction can be conveyed, which = it does. =09 I encourage use of the term "gateway" when referring to an entity that = supports sleeping nodes, coordinates group activities, or performs any = other role that might be hidden behind the authority part of a URI. =09 Caching in turn is a function that may be paired with a proxy or with a = gateway, but is not inherently coupled to either one. =09 If it's not too late to make so major a change in terminology and = concept, I would encourage a rewrite of section 5 to make clear that = proxies, gateways, and caches are independent functions. I would = contribute text for this if the editors would find that helpful. =09 Peter =09 ------_=_NextPart_001_01CB8B10.D0DC4C2F Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A=
    =0A=
    >Anders: As I suggested in my = specific response to caching, neither the client nor the = server
    =0A=
    >should be aware that there are = gateways between them, at least not at the REST = level. 
    =0A=
    >Any such knowledge introduces = coupling, and limits the ability of organizations to = restructure
    =0A=
    >their networks while providing the = same resources via the same URIs.
    =0A=
    Agreed!
    =0A=

    =0A=
    =0A= Fra: Peter Bigot = [mailto:pab@peoplepowerco.com]
    Sendt: ti 23-11-2010 = 06:13
    Til: core; matthieu.vial@fr.non.schneider-electric.com; = Klaus Hartke; Anders Brandt
    Emne: Re: Proxy versus = Gateway

    =0A=
    =0A=
    I hope nobody minds, but I've transplanted this = back to the original thread, with my original argument below.  = Though my corrections to Klaus's summary of what I said may be accurate, = I'd prefer to not depend on that.  Please refresh your memories of = what I wrote last month, as I have done.  (In particular, I don't = want to lose my subtle other suggestion which is that "cache" needs to = be refined, not just use of "proxy" and "gateway".  Personally I'd = like to see the entire semantic description of CoAP caching pulled out = to another document, as I believe is being done in HTTPbis, leaving base = CoAP to describe the generic encoding and method-independent transaction = details.)

    Matthieu:  All your cases are gateways.  A = gateway can operate at any level in the OSI stack.  Those that = operate at the application (CoAP) level may end up doing a translation = that involves initiating a new CoAP request, potentially to a completely = different URI, even one with a non-CoAP scheme.  Such a node is a = gateway because the authority part of the URI led the data flow to = it.  In my mind, there's no implication that a gateway is = restricted from inspecting or manipulating other parts of the URI in = order to fulfill its responsibilities (Fielding's list of gateway = purposes should not be read as exhaustive).  Do you feel that a = further refinement to characterize types of gateway would improve an = understanding of CoAP?

    Anders: As I suggested in my specific = response to caching, neither the client nor the server should be aware = that there are gateways between them, at least not at the REST = level.  Any such knowledge introduces coupling, and limits the = ability of organizations to restructure their networks while providing = the same resources via the same URIs.

    Peter

    On Tue, Nov = 23, 2010 at 2:57 AM, <matthieu.vial= @fr.non.schneider-electric.com> wrote:
    =0A=
    =0A=
    =0A=
    =0A=
      =0A=
        =0A=

        >>* A gateway (a.k.a., reverse proxy, big = brother, ...) is an
        >>intermediary imposed by the origin server = to support sleeping nodes or
        >>perform any other role that = might be hidden behind the authority part
        >>of a = URI.


    > Almost; the origin = server may be unaware of the presence of a gateway.  The network = may impose the gateway.

    I'm sorry but = I can't catch the exact meaning of "any other role that might be hidden = behind the authority part
    of a URI".
    A = gateway acting as a reverse proxy could for example implement a cache = for sleeping nodes. The reverse proxy can map the sleeping nodes into = its own namespace. In that case it's not just the authority part of the = URI but the full URI that is used to decide what should be = done.
    coap://bigbrother1.example.org/sensor1/ is actually = redirected to coap://sensor1.example.org/
    coap://bigbrother1.example.org/sensor2/ is actually = redirected to coap://sensor2.example.org/

    Or = maybe you want to separate the different functions of the gateway into = different domain names that resolve to the same IP?
    coap://cache.example.org/ implements the caching = feature
    coap://http.example.org/ = implements HTTP translation
    coap://6to4.example.org/ = implements IPv6 to IPv4 translation
    But then I = suppose it could also be defined like that:
    coap://gateway.example.org/cache/
    coap://gateway.example.org/http/
    coap://gateway.example.org/6to4/

    On the other hand a gateway acting as a = transparent/interception proxy will use some IP magic to answer on the = behalf of the origin server. In that case the gateway only uses the = authority part of the URI (or the destination address). But transparent = proxying requires some advanced IP stack features that are not always = available:
    1. Redirect sessions destined to the = outer network to a local process using a packet filter = rule.
    2. Make it possible for a process to = listen to connections on a foreign address.
    3. = Make it possible for a process to initiate a connection with a foreign = address as a source.

    Could you please tell = me if something is wrong with my reasoning?

    Regards,
    Matthieu


    =0A=
    On Sat, Oct 23, 2010 at 5:55 AM, Peter Bigot = <pab@peoplepowerco.com> wrote:
    =0A=
    I and others = have been somewhat confused by the CoAP terms "proxy" and "cache", which = unless clarified actually mix several concepts.  I found = enlightenment in section 5.2.3 of Fielding's = dissertation:

    =0A=
    Intermediary components act as both a = client and a server in order to forward, with possible translation, = requests and responses. A proxy component is an intermediary selected by = a client to provide interface encapsulation of other services, data = translation, performance enhancement, or security protection. A gateway = (a.k.a., reverse proxy) component is an intermediary imposed by the = network or origin server to provide an interface encapsulation of other = services, for data translation, performance enhancement, or security = enforcement. Note that the difference between a proxy and a gateway is = that a client determines when it will use a proxy.

    I had = been misled because the non-technical use of the term "proxy" is = appropriate for several key roles in a CoAP system, including that = entity which serves as the intermediary for sleeping nodes.  The = correct term for this function is "gateway", as most clients need not be = aware that they are acting through an intermediary.

    CoAP's use of = the term "proxy" is inconsistent with these = definitions:
    5.3.  =
Proxying
       A proxy is defined as a CoAP end-point =
which services cached requests=0A=
   on behalf of other CoAP end-points.  Any node in a CoAP network may=0A=
   act as a proxy, although in general the node between the constrained=0A=
   network and the Internet at large SHOULD always support proxy=0A=
   functionality.=0A=
    This is misleading because it focuses solely on caching, leaving = aside the other reasons why a proxy might be necessary.   As = an example, many constrained nodes  will not support DNS, and = therefore cannot translate an ASCII authority found within a URI to a = network address.   Similarly, constrained devices are unlikely to = have the computational resources necessary to support public key = cryptography.   It would be better to say that a proxy is an = intermediary explicitly selected by the client as its agent when dealing = with any transaction it is unable to perform directly.

    This is an = important but currently implicit role in a CoAP system.  As with = the traditional use of proxy in web browsers (back before desktops = became full participants in the Internet), a CoAP client should need = only one proxy to which it can delegate all CoAP transactions it can't = do itself.  Configuration of this proxy for a particular node is an = administrative function outside the scope of CoAP as an on-wire = protocol.  (If multiple proxies were expected at a client, there = would have to be some way of selecting which proxy to use for which = operation, an unnecessary complication that could easily be supported by = delegation.)  CoAP need merely provide a mechanism by which the = full information required to delegate the transaction can be conveyed, = which it does.

    I encourage use of the term "gateway" when = referring to an entity that supports sleeping nodes, coordinates group = activities, or performs any other role that might be hidden behind the = authority part of a URI.

    Caching in turn is a function that may = be paired with a proxy or with a gateway, but is not inherently coupled = to either one.

    If it's not too late to make so major a change in = terminology and concept, I would encourage a rewrite of section 5 to = make clear that proxies,  gateways, and caches are independent = functions.  I would contribute text for this if the editors would = find that helpful.

    Peter

    =0A=
    =0A= =0A=
    ------_=_NextPart_001_01CB8B10.D0DC4C2F-- From abr@sdesigns.dk Tue Nov 23 05:27:46 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A83EF3A694D for ; Tue, 23 Nov 2010 05:27:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.481 X-Spam-Level: X-Spam-Status: No, score=-1.481 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOB9AYyR-XI8 for ; Tue, 23 Nov 2010 05:27:41 -0800 (PST) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id CC40B3A6939 for ; Tue, 23 Nov 2010 05:27:37 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB8B12.542B6E9D" Date: Tue, 23 Nov 2010 14:28:34 +0100 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01AD475F@zensys17.zensys.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proxy versus Gateway Thread-Index: AcuLEEnTBXKdx6CbQnGEQ+1PInsiKAAAQmVD References: From: "Anders Brandt" To: "Peter Bigot" , "core" , , "Klaus Hartke" Subject: Re: [core] Proxy versus Gateway X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 13:27:46 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB8B12.542B6E9D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Peter =20 ...A gateway can operate at any level in the OSI stack. Those that = operate at the application (CoAP) level may end up doing a translation = that involves initiating a new CoAP request, potentially to a completely = different URI, even one with a non-CoAP scheme. Such a node is a = gateway ... =20 You are getting to some important detail here. And I agree with you that = terminology is extremely important. =20 What I think (speaking for myself at least) is causing us to avoid the = "gateway" term is exactly the inherent understanding that it translates my application content. What if my device is completely transparent to all application payload, = but just does a bit of caching and buffering? Everytime I say "gateway" to a customer I will have to explain that this = particular gateway does not do any translation - it just enables connectivity via standard frame = formats. =20 New term wanted! =20 - Anders ________________________________ Fra: Peter Bigot [mailto:pab@peoplepowerco.com] Sendt: ti 23-11-2010 06:13 Til: core; matthieu.vial@fr.non.schneider-electric.com; Klaus Hartke; = Anders Brandt Emne: Re: Proxy versus Gateway I hope nobody minds, but I've transplanted this back to the original = thread, with my original argument below. Though my corrections to = Klaus's summary of what I said may be accurate, I'd prefer to not depend = on that. Please refresh your memories of what I wrote last month, as I = have done. (In particular, I don't want to lose my subtle other = suggestion which is that "cache" needs to be refined, not just use of = "proxy" and "gateway". Personally I'd like to see the entire semantic = description of CoAP caching pulled out to another document, as I believe = is being done in HTTPbis, leaving base CoAP to describe the generic = encoding and method-independent transaction details.) Matthieu: All your cases are gateways. A gateway can operate at any = level in the OSI stack. Those that operate at the application (CoAP) = level may end up doing a translation that involves initiating a new CoAP = request, potentially to a completely different URI, even one with a = non-CoAP scheme. Such a node is a gateway because the authority part of = the URI led the data flow to it. In my mind, there's no implication = that a gateway is restricted from inspecting or manipulating other parts = of the URI in order to fulfill its responsibilities (Fielding's list of = gateway purposes should not be read as exhaustive). Do you feel that a = further refinement to characterize types of gateway would improve an = understanding of CoAP? Anders: As I suggested in my specific response to caching, neither the = client nor the server should be aware that there are gateways between = them, at least not at the REST level. Any such knowledge introduces = coupling, and limits the ability of organizations to restructure their = networks while providing the same resources via the same URIs. Peter On Tue, Nov 23, 2010 at 2:57 AM, = wrote: >>* A gateway (a.k.a., reverse proxy, big brother, ...) is an >>intermediary imposed by the origin server to support sleeping nodes = or >>perform any other role that might be hidden behind the authority = part >>of a URI. =09 > Almost; the origin server may be unaware of the presence of a = gateway. The network may impose the gateway. =09 =09 I'm sorry but I can't catch the exact meaning of "any other role that = might be hidden behind the authority part of a URI".=20 A gateway acting as a reverse proxy could for example implement a cache = for sleeping nodes. The reverse proxy can map the sleeping nodes into = its own namespace. In that case it's not just the authority part of the = URI but the full URI that is used to decide what should be done. coap://bigbrother1.example.org/sensor1/ is actually redirected to = coap://sensor1.example.org/ coap://bigbrother1.example.org/sensor2/ is actually redirected to = coap://sensor2.example.org/ =09 Or maybe you want to separate the different functions of the gateway = into different domain names that resolve to the same IP? coap://cache.example.org/ implements the caching feature coap://http.example.org/ implements HTTP translation coap://6to4.example.org/ implements IPv6 to IPv4 translation But then I suppose it could also be defined like that: coap://gateway.example.org/cache/ coap://gateway.example.org/http/ coap://gateway.example.org/6to4/ =09 On the other hand a gateway acting as a transparent/interception proxy = will use some IP magic to answer on the behalf of the origin server. In = that case the gateway only uses the authority part of the URI (or the = destination address). But transparent proxying requires some advanced IP = stack features that are not always available: 1. Redirect sessions destined to the outer network to a local process = using a packet filter rule. 2. Make it possible for a process to listen to connections on a foreign = address. 3. Make it possible for a process to initiate a connection with a = foreign address as a source. =09 Could you please tell me if something is wrong with my reasoning? =09 Regards, Matthieu On Sat, Oct 23, 2010 at 5:55 AM, Peter Bigot = wrote: I and others have been somewhat confused by the CoAP terms "proxy" and = "cache", which unless clarified actually mix several concepts. I found = enlightenment in section 5.2.3 of Fielding's dissertation = : =09 =09 Intermediary components act as both a client and a server in order to = forward, with possible translation, requests and responses. A proxy = component is an intermediary selected by a client to provide interface = encapsulation of other services, data translation, performance = enhancement, or security protection. A gateway (a.k.a., reverse proxy) = component is an intermediary imposed by the network or origin server to = provide an interface encapsulation of other services, for data = translation, performance enhancement, or security enforcement. Note that = the difference between a proxy and a gateway is that a client determines = when it will use a proxy. =09 I had been misled because the non-technical use of the term "proxy" is = appropriate for several key roles in a CoAP system, including that = entity which serves as the intermediary for sleeping nodes. The correct = term for this function is "gateway", as most clients need not be aware = that they are acting through an intermediary. =09 CoAP's use of the term "proxy" is inconsistent with these definitions: =09 =09 5.3. Proxying A proxy is defined as a CoAP end-point which services cached = requests on behalf of other CoAP end-points. Any node in a CoAP network may act as a proxy, although in general the node between the constrained network and the Internet at large SHOULD always support proxy functionality. This is misleading because it focuses solely on caching, leaving aside = the other reasons why a proxy might be necessary. As an example, many = constrained nodes will not support DNS, and therefore cannot translate = an ASCII authority found within a URI to a network address. Similarly, = constrained devices are unlikely to have the computational resources = necessary to support public key cryptography. It would be better to = say that a proxy is an intermediary explicitly selected by the client as = its agent when dealing with any transaction it is unable to perform = directly. =09 This is an important but currently implicit role in a CoAP system. As = with the traditional use of proxy in web browsers (back before desktops = became full participants in the Internet), a CoAP client should need = only one proxy to which it can delegate all CoAP transactions it can't = do itself. Configuration of this proxy for a particular node is an = administrative function outside the scope of CoAP as an on-wire = protocol. (If multiple proxies were expected at a client, there would = have to be some way of selecting which proxy to use for which operation, = an unnecessary complication that could easily be supported by = delegation.) CoAP need merely provide a mechanism by which the full = information required to delegate the transaction can be conveyed, which = it does. =09 I encourage use of the term "gateway" when referring to an entity that = supports sleeping nodes, coordinates group activities, or performs any = other role that might be hidden behind the authority part of a URI. =09 Caching in turn is a function that may be paired with a proxy or with a = gateway, but is not inherently coupled to either one. =09 If it's not too late to make so major a change in terminology and = concept, I would encourage a rewrite of section 5 to make clear that = proxies, gateways, and caches are independent functions. I would = contribute text for this if the editors would find that helpful. =09 Peter =09 ------_=_NextPart_001_01CB8B12.542B6E9D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A=
    =0A=
    Hi Peter
    =0A=
     
    =0A=
    <Quote>
    =0A=
    ...A gateway can operate at any = level in the OSI stack.  Those that operate at the application = (CoAP) level may end up doing a translation that involves initiating a = new CoAP request, potentially to a completely different URI, even one = with a non-CoAP scheme.  Such a node is a gateway ...
    =0A=
    </Qoute>
    =0A=
     
    =0A=
    You are getting to some important detail here. And I = agree with you that terminology is extremely important.
    =0A=
     
    =0A=
    What I think (speaking for myself at least) is causing us = to avoid the "gateway" term is exactly the inherent
    =0A=
    understanding that it translates my application = content.
    =0A=
    What if my device is completely transparent to all = application payload, but just does a bit of caching and buffering?
    =0A=
    Everytime I say "gateway" to a customer I will have to = explain that this particular gateway does not
    do any translation - it = just enables connectivity via standard frame formats.
    =0A=
     
    =0A=
    New term wanted!
    =0A=
     
    =0A=
    - Anders
    =0A=

    =0A=
    =0A= Fra: Peter Bigot = [mailto:pab@peoplepowerco.com]
    Sendt: ti 23-11-2010 = 06:13
    Til: core; matthieu.vial@fr.non.schneider-electric.com; = Klaus Hartke; Anders Brandt
    Emne: Re: Proxy versus = Gateway

    =0A=
    =0A=
    I hope nobody minds, but I've transplanted this = back to the original thread, with my original argument below.  = Though my corrections to Klaus's summary of what I said may be accurate, = I'd prefer to not depend on that.  Please refresh your memories of = what I wrote last month, as I have done.  (In particular, I don't = want to lose my subtle other suggestion which is that "cache" needs to = be refined, not just use of "proxy" and "gateway".  Personally I'd = like to see the entire semantic description of CoAP caching pulled out = to another document, as I believe is being done in HTTPbis, leaving base = CoAP to describe the generic encoding and method-independent transaction = details.)

    Matthieu:  All your cases are gateways.  A = gateway can operate at any level in the OSI stack.  Those that = operate at the application (CoAP) level may end up doing a translation = that involves initiating a new CoAP request, potentially to a completely = different URI, even one with a non-CoAP scheme.  Such a node is a = gateway because the authority part of the URI led the data flow to = it.  In my mind, there's no implication that a gateway is = restricted from inspecting or manipulating other parts of the URI in = order to fulfill its responsibilities (Fielding's list of gateway = purposes should not be read as exhaustive).  Do you feel that a = further refinement to characterize types of gateway would improve an = understanding of CoAP?

    Anders: As I suggested in my specific = response to caching, neither the client nor the server should be aware = that there are gateways between them, at least not at the REST = level.  Any such knowledge introduces coupling, and limits the = ability of organizations to restructure their networks while providing = the same resources via the same URIs.

    Peter

    On Tue, Nov = 23, 2010 at 2:57 AM, <matthieu.vial= @fr.non.schneider-electric.com> wrote:
    =0A=
    =0A=
    =0A=
    =0A=
      =0A=
        =0A=

        >>* A gateway (a.k.a., reverse proxy, big = brother, ...) is an
        >>intermediary imposed by the origin server = to support sleeping nodes or
        >>perform any other role that = might be hidden behind the authority part
        >>of a = URI.


    > Almost; the origin = server may be unaware of the presence of a gateway.  The network = may impose the gateway.

    I'm sorry but = I can't catch the exact meaning of "any other role that might be hidden = behind the authority part
    of a URI".
    A = gateway acting as a reverse proxy could for example implement a cache = for sleeping nodes. The reverse proxy can map the sleeping nodes into = its own namespace. In that case it's not just the authority part of the = URI but the full URI that is used to decide what should be = done.
    coap://bigbrother1.example.org/sensor1/ is actually = redirected to coap://sensor1.example.org/
    coap://bigbrother1.example.org/sensor2/ is actually = redirected to coap://sensor2.example.org/

    Or = maybe you want to separate the different functions of the gateway into = different domain names that resolve to the same IP?
    coap://cache.example.org/ implements the caching = feature
    coap://http.example.org/ = implements HTTP translation
    coap://6to4.example.org/ = implements IPv6 to IPv4 translation
    But then I = suppose it could also be defined like that:
    coap://gateway.example.org/cache/
    coap://gateway.example.org/http/
    coap://gateway.example.org/6to4/

    On the other hand a gateway acting as a = transparent/interception proxy will use some IP magic to answer on the = behalf of the origin server. In that case the gateway only uses the = authority part of the URI (or the destination address). But transparent = proxying requires some advanced IP stack features that are not always = available:
    1. Redirect sessions destined to the = outer network to a local process using a packet filter = rule.
    2. Make it possible for a process to = listen to connections on a foreign address.
    3. = Make it possible for a process to initiate a connection with a foreign = address as a source.

    Could you please tell = me if something is wrong with my reasoning?

    Regards,
    Matthieu


    =0A=
    On Sat, Oct 23, 2010 at 5:55 AM, Peter Bigot = <pab@peoplepowerco.com> wrote:
    =0A=
    I and others = have been somewhat confused by the CoAP terms "proxy" and "cache", which = unless clarified actually mix several concepts.  I found = enlightenment in section 5.2.3 of Fielding's = dissertation:

    =0A=
    Intermediary components act as both a = client and a server in order to forward, with possible translation, = requests and responses. A proxy component is an intermediary selected by = a client to provide interface encapsulation of other services, data = translation, performance enhancement, or security protection. A gateway = (a.k.a., reverse proxy) component is an intermediary imposed by the = network or origin server to provide an interface encapsulation of other = services, for data translation, performance enhancement, or security = enforcement. Note that the difference between a proxy and a gateway is = that a client determines when it will use a proxy.

    I had = been misled because the non-technical use of the term "proxy" is = appropriate for several key roles in a CoAP system, including that = entity which serves as the intermediary for sleeping nodes.  The = correct term for this function is "gateway", as most clients need not be = aware that they are acting through an intermediary.

    CoAP's use of = the term "proxy" is inconsistent with these = definitions:
    5.3.  =
Proxying
       A proxy is defined as a CoAP end-point =
which services cached requests=0A=
   on behalf of other CoAP end-points.  Any node in a CoAP network may=0A=
   act as a proxy, although in general the node between the constrained=0A=
   network and the Internet at large SHOULD always support proxy=0A=
   functionality.=0A=
    This is misleading because it focuses solely on caching, leaving = aside the other reasons why a proxy might be necessary.   As = an example, many constrained nodes  will not support DNS, and = therefore cannot translate an ASCII authority found within a URI to a = network address.   Similarly, constrained devices are unlikely to = have the computational resources necessary to support public key = cryptography.   It would be better to say that a proxy is an = intermediary explicitly selected by the client as its agent when dealing = with any transaction it is unable to perform directly.

    This is an = important but currently implicit role in a CoAP system.  As with = the traditional use of proxy in web browsers (back before desktops = became full participants in the Internet), a CoAP client should need = only one proxy to which it can delegate all CoAP transactions it can't = do itself.  Configuration of this proxy for a particular node is an = administrative function outside the scope of CoAP as an on-wire = protocol.  (If multiple proxies were expected at a client, there = would have to be some way of selecting which proxy to use for which = operation, an unnecessary complication that could easily be supported by = delegation.)  CoAP need merely provide a mechanism by which the = full information required to delegate the transaction can be conveyed, = which it does.

    I encourage use of the term "gateway" when = referring to an entity that supports sleeping nodes, coordinates group = activities, or performs any other role that might be hidden behind the = authority part of a URI.

    Caching in turn is a function that may = be paired with a proxy or with a gateway, but is not inherently coupled = to either one.

    If it's not too late to make so major a change in = terminology and concept, I would encourage a rewrite of section 5 to = make clear that proxies,  gateways, and caches are independent = functions.  I would contribute text for this if the editors would = find that helpful.

    Peter

    =0A=
    =0A= =0A=
    ------_=_NextPart_001_01CB8B12.542B6E9D-- From pab@peoplepowerco.com Tue Nov 23 05:34:43 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85F983A6947 for ; Tue, 23 Nov 2010 05:34:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.889 X-Spam-Level: X-Spam-Status: No, score=-2.889 tagged_above=-999 required=5 tests=[AWL=0.957, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_MESSAGE=0.001, SARE_RMML_Stock10=0.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q2VD-kmxQvhs for ; Tue, 23 Nov 2010 05:34:39 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id A087A3A6938 for ; Tue, 23 Nov 2010 05:34:38 -0800 (PST) Received: by fxm3 with SMTP id 3so6055355fxm.31 for ; Tue, 23 Nov 2010 05:35:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.97.13 with SMTP id j13mr5699113fan.146.1290519333743; Tue, 23 Nov 2010 05:35:33 -0800 (PST) Received: by 10.223.70.198 with HTTP; Tue, 23 Nov 2010 05:35:33 -0800 (PST) Date: Tue, 23 Nov 2010 07:35:33 -0600 Message-ID: From: Peter Bigot To: Anders Brandt Content-Type: multipart/alternative; boundary=20cf3054a61576ad3d0495b87249 Cc: core , Klaus Hartke Subject: [core] CoAP Topology Discovery (was Re: Proxy and server on the same port) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 13:34:43 -0000 --20cf3054a61576ad3d0495b87249 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable More subject changing to keep threads separate. OK, I think I see what you're after. In my opinion, this is not a CoAP protocol problem, but a network management problem related to CoAP traffic. The same issue ought to translate to HTTP which also has application-level gateways, and I would look for an existing solution in that domain. If there isn't one for HTTP, but one is needed for CoAP and it is done usin= g CoAP rather than SNMP or some other mechanism, off-hand I'd suggest definin= g a standard resource like coap://authority/topology that could be used as an entrypoint to introspect the network topology and features including gateway, proxy, and cache functions. I think this would be a separate document, incorporating the functionality you describe below. Two slightly related issues: Rather than standardize the hier-part of the URI to locate this function, I'd propose adding a link relation that would allow it to be placed without globally limiting how servers manage their resource namespace. Alternatively, put it in /.well-known/core/topo, but that would require tha= t the link description resources be pushed down a level to something like /.well-known/core/ld as the root. Which is worth considering in a differen= t thread. Sleeping nodes might be identified by a link parameter "sleeping=3D" in their link descriptions on the end-point identified by the authority part of the standard URI used to access their resources (presumbly hosted on an always-awake endpoint). I don't think the link format document needs to define that parameter; it should be part of the sleeping node solution, which might also introduce a standard resource for management that normal clients don't need to know about. Peter On Tue, Nov 23, 2010 at 7:16 AM, Anders Brandt wrote: > Hi Peter > > > From my perspective: why do you need to know? > > One one hand I agree with you. When rootcausing an issue in my network I > may like to know... > I imagine my gateway just returns "/caching=3DTRUE" (Zach may come up wit= h a > one-letter code for this standard path) > The example of going to coap://chicagocacher in a sort of redirect was no= t > what I was looking for. My main intention is (as stated in the CoAP spec)= : > 1) to save network bandwidth, 2) discover sleeping nodes > > >... Then the issue is how does it find out that chicagocacher exists an= d > supports this sort of operation. > > That's a service discovery and resource discovery issue. > > Agree 100% > My main reason for responding is exactly discovery. > For achieving a plug-and-play experience across subnets I have a need for > identifying gateways and asking them what interfaces they have on their > other side. Then I can go ask these interfaces to report local CoAP hosts= , > and so on. Every time, these hosts may be cached or discovered on demand = via > multicast if relevant. > This can be done in a hierarchical, de-centralised fashion where no > gateways have to store any information > that is already stored in other gateways. > Only the client running the discovery will get the full picture of all > nodes in all subnets. > > Do you follow me? > Thanks, > Anders > > ------------------------------ > *Fra:* Peter Bigot [mailto:pab@peoplepowerco.com] > *Sendt:* ti 23-11-2010 05:46 > *Til:* Anders Brandt > *Cc:* Klaus Hartke; core > > *Emne:* Re: [core] Proxy and server on the same port > > From my perspective: why do you need to know? > > The client should transmit a request for data from a URI to some other no= de > (either a proxy, or an end-point extracted from the URI authority). If i= t > has "freshness" needs, it should incorporate a Max-Age option. Whether t= he > response comes from the origin server or a cache somewhere between the > client and the origin server should not be detectable by the client. > > An alternative model is to allow applications to be made aware of somethi= ng > that caches resource values and provides access to them through a differe= nt > URI; e.g. if the client thinks that coap://bigben/temperature is too far > away, it might GET coap://chicagocacher/bigben/temperature. Then the iss= ue > is how does it find out that chicagocacher exists and supports this sort = of > operation. That's a service discovery and resource discovery issue. > > Peter > > On Tue, Nov 23, 2010 at 2:31 AM, Anders Brandt wrote: > >> > So you do agree with what was in that email? I assumed the complete >> lack of response meant nobody thought it relevant. >> Actually, this thread is very relevant. >> I am currently investigating CoAP multi-subnet environments with sleepin= g >> nodes and I am very much in favor of a precise terminology. >> >> Unfortunately I am still not 100% up to speed on CoRE. What is the >> preferred way of indicating that a node (typically the default gateway) >> provides caching on behalf of other servers in the same subnet? and in >> another subnet? >> >> Thanks, >> Anders >> >> ------------------------------ >> *Fra:* core-bounces@ietf.org p=E5 vegne af Peter Bigot >> *Sendt:* ma 22-11-2010 10:53 >> *Til:* Klaus Hartke >> *Cc:* core >> *Emne:* Re: [core] Proxy and server on the same port >> >> On Mon, Nov 22, 2010 at 11:22 AM, Klaus Hartke wrote: >> >>> Peter Bigot wrote: >>> >> I think it makes a lot of sense to distinguish between end-points th= at >>> >> act on behalf of a client and those that act on behalf of a server. >>> >> Not sure what needs to be discussed (apart maybe from the actual ter= ms >>> >> used for the two roles). >>> > >>> > Just that I proposed completely rewriting section five to get CoAP to >>> use >>> > specific terms in the way I described in my email, which would result >>> in a >>> > significant change (clarification) to what "proxy" means, and a >>> separation >>> > of it from the concept of a "cache". Your comment above is not the >>> same >>> > thing, and since nobody else has commented I don't think my email >>> should be >>> > the basis of a ticket. >>> >>> I thought my comment above would capture the essence of your email, >>> but apparently it didn't. >> >> >> Sorry, I didn't read it that way. >> >> >>> So here's an attempt at a more complete >>> summary of your email: >>> >>> * Intermediary CoAP end-points act as both a client and a server in >>> order to forward, with possible translation, requests and responses. >>> >> >> OK. >> >> * A proxy is an intermediary selected by a client. A client can >>> delegate all CoAP requests it can't do itself to a proxy. >>> Configuration of this proxy for a particular node is an administrative >>> function outside the scope of CoAP. >>> >> >> Yes. >> >> * A gateway (a.k.a., reverse proxy, big brother, ...) is an >>> intermediary imposed by the origin server to support sleeping nodes or >>> perform any other role that might be hidden behind the authority part >>> of a URI. >>> >> >> Almost; the origin server may be unaware of the presence of a gateway. >> The network may impose the gateway. >> >> * Caching in turn is a function that may be paired with a proxy or >>> with a gateway, but is not inherently coupled to either one. >>> >> >> Yes. >> >> >>> Please correct me if I'm missing something essential. >>> >> >> Not at first glance, >> >> So you do agree with what was in that email? I assumed the complete lac= k >> of response meant nobody thought it relevant. >> >> >>> > In what I proposed, a client is specifically configured to use a >>> (single) >>> > proxy, and that proxy is providing specific enhanced services on beha= lf >>> of >>> > the client. With that model it makes little sense to accommodate >>> placing >>> > the proxy at the same end-point (port) as a normal server. >>> > >>> > However, if there's no buy-in for that change, and there's some >>> compelling >>> > reason why we should accommodate two applications at a single port, I >>> > suppose a set of rules to use UriScheme values as a cue to whether a >>> request >>> > might have been intended for a proxy or a server could be made to wor= k. >>> > "Don't do that" seems like a better approach, in my opinion. >>> >>> There are two things: >>> >>> 1. Does it make sense to run a proxy and a server on the same port? >>> >>> The answer is probably: No. >>> >> >> Good. >> >> 2. What to do when a client thinks an end-point is a server when it's >>> actually a proxy? >>> >> >> Ah. I lost the context from the earlier parts of the thread, and assume= d >> your proposal was a way to allow dual-use. In fact, your rules seem to = be a >> complete workable solution that does allow dual use. Nice. That's not = what >> raised my hackles. >> >> The solution is to have the client say what it thinks, so that its >>> wrong assumption can be pointed out by the recipient. >>> >> >> That is a good solution. But in the details, I think it would be more >> clear if the client does say what it thinks (that it's talking with a >> proxy), rather than creating complex rules on how to interpret Uri-Schem= e to >> infer that it thinks it's talking with a proxy. So use a new option nam= ed >> Uri-Proxy with no value, the presence/absence of which indicates the >> client's expectations. Don't overload Uri-Scheme to mean something weir= d >> that could conflict with future use, e.g. putting a coap and a coapm >> (multicast) service on the same port. >> >> Change Uri-Scheme to Uri-Proxy in your proposal and you've got a solutio= n >> that allows disambiguation while at the same time allowing both function= s to >> occur on the same port and not muddying what Uri-Scheme means. That's t= he >> sort of approach I like: one technique that solves multiple problems >> without introducing new ones. Barring some undiscovered flaw, I'd suppo= rt >> that. >> >> >>> >>> Klaus >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>> >> >> > --20cf3054a61576ad3d0495b87249 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable More subject changing to keep threads separate.

    OK, I think I see wh= at you're after.=A0 In my opinion, this is not a CoAP protocol problem,= but a network management problem related to CoAP traffic.=A0 The same issu= e ought to translate to HTTP which also has application-level gateways, and= I would look for an existing solution in that domain.

    If there isn't one for HTTP, but one is needed for CoAP and it is d= one using CoAP rather than SNMP or some other mechanism, off-hand I'd s= uggest defining a standard resource like coap://authority/topology that cou= ld be used as an entrypoint to introspect the network topology and features= including gateway, proxy, and cache functions.=A0 I think this would be a = separate document, incorporating the functionality you describe below.

    Two slightly related issues:

    Rather than standardize the hier-pa= rt of the URI to locate this function, I'd propose adding a link relati= on that would allow it to be placed without globally limiting how servers m= anage their resource namespace.=A0 Alternatively, put it in /.well-known/co= re/topo, but that would require that the link description resources be push= ed down a level to something like /.well-known/core/ld as the root.=A0 Whic= h is worth considering in a different thread.

    Sleeping nodes might be identified by a link parameter "sleeping= =3D<duty_cycle_description>" in their link descriptions on the e= nd-point identified by the authority part of the standard URI used to acces= s their resources (presumbly hosted on an always-awake endpoint).=A0 I don&= #39;t think the link format document needs to define that parameter; it sho= uld be part of the sleeping node solution, which might also introduce a sta= ndard resource for management that normal clients don't need to know ab= out.

    Peter

    On Tue, Nov 23, 2010 at 7:16 AM= , Anders Brandt <ab= r@sdesigns.dk> wrote:
    Hi Peter
    =A0
    > From my perspective: why do you need= to know?

    One one hand I agree with you. = When rootcausing an issue in my network I may like to know...    =
    I imagine my gateway just returns "/= caching=3DTRUE" (Zach may come up with a one-letter code for this stan= dard path)
    The example of going to coap://chicagocacher in a sort of = redirect was not what I was looking for. My main intention is (as stated in= the CoAP spec): 1) to save network bandwidth, 2)=A0discover sleeping nodes=
    =A0
    >...=A0 Then the issue is how does it = find out that chicagocacher exists and supports this sort of operation.=A0<= /font>
    > That's a service discovery and r= esource discovery issue.
    =A0
    Agree 100%
    My main reason for responding is exactly discovery.
    For achieving a plug-and-play experience across subnets I = have a need for identifying gateways and asking them what interfaces they h= ave on their other side. Then I can go ask these interfaces to report local= CoAP hosts, and so on. Every time, these hosts may be cached or discovered= on demand via multicast if relevant.
    This=A0can be done in a hierarchical, de-centralised fashi= on where no gateways have to store any information
    that is already stored in other gateways.
    Only the client running the discovery will get the full pi= cture of all nodes in all subnets.

    Do you follow me?
    Thanks,
    =A0 Anders

    Fra: Peter Bigot [mailto:pab@peoplepowerco.com]=
    Sendt: ti 23-11-2010 05:46
    Til: Anders Brandt
    Cc= : Klaus Hartke; core

    Emne: Re: [core] Proxy and server o= n the same port

    From my perspective: why do you need to know?

    The client should= transmit a request for data from a URI to some other node (either a proxy,= or an end-point extracted from the URI authority).=A0 If it has "fres= hness" needs, it should incorporate a Max-Age option.=A0 Whether the r= esponse comes from the origin server or a cache somewhere between the clien= t and the origin server should not be detectable by the client.

    An alternative model is to allow applications to be made aware of somet= hing that caches resource values and provides access to them through a diff= erent URI; e.g. if the client thinks that coap://bigben/temperature is too = far away, it might GET coap://chicagocacher/bigben/temperature.=A0 Then the= issue is how does it find out that chicagocacher exists and supports this = sort of operation.=A0 That's a service discovery and resource discovery= issue.

    Peter

    On Tue, Nov 23, 2010 at 2:31 AM, Anders Brandt <= span dir=3D"ltr"><a= br@sdesigns.dk> wrote:
    > So you do agree with what was in tha= t email?=A0 I assumed the complete lack of response meant nobody thought it= relevant.
    Actually= , this thread is very relevant.
    I am currently investigati= ng CoAP multi-subnet environments with sleeping nodes and I am very much in= favor of a precise terminology.
    =A0
    Unfortunately I am still n= ot 100% up to speed on CoRE. What is the preferred way of indicating that a= node (typically the default gateway) provides caching on behalf of other s= ervers in the same subnet? and in another subnet?
    =A0
    Thanks,
    =A0 Anders

    Fra: core-bounces@ietf.org p=E5 vegne af Peter = Bigot
    Sendt: ma 22-11-2010 10:53
    Til: Klaus Hartke
    <= b>Cc: core
    Emne: Re: [core] Proxy and server on the same port

    On Mon, Nov 22, 2010 at 11:22 AM, Klaus Hartke <= span dir=3D"ltr"><ha= rtke@tzi.org> wrote:
    Peter Bigot wrote:
    >> I think it makes a lot of sense to dist= inguish between end-points that
    >> act on behalf of a client and t= hose that act on behalf of a server.
    >> Not sure what needs to be = discussed (apart maybe from the actual terms
    >> used for the two roles).
    >
    > Just that I proposed comp= letely rewriting section five to get CoAP to use
    > specific terms in = the way I described in my email, which would result in a
    > significan= t change (clarification) to what "proxy" means, and a separation<= br> > of it from the concept of a "cache".=A0 Your comment above i= s not the same
    > thing, and since nobody else has commented I don'= ;t think my email should be
    > the basis of a ticket.

    I t= hought my comment above would capture the essence of your email,
    but apparently it didn't.

    Sorry,=A0 I didn't read it that way.
    =A0
    So here's an = attempt at a more complete
    summary of your email:

    * Intermediary = CoAP end-points act as both a client and a server in
    order to forward, with possible translation, requests and responses.

    OK.

    * A proxy is an i= ntermediary selected by a client. A client can
    delegate all CoAP request= s it can't do itself to a proxy.
    Configuration of this proxy for a particular node is an administrative
    f= unction outside the scope of CoAP.

    Yes.

    * A gateway (a.k.= a., reverse proxy, big brother, ...) is an
    intermediary imposed by the o= rigin server to support sleeping nodes or
    perform any other role that might be hidden behind the authority part
    of= a URI.

    =A0Almost; the origin server may be unaware of the presence of a g= ateway.=A0 The network may impose the gateway.

    * Caching in turn= is a function that may be paired with a proxy or
    with a gateway, but is= not inherently coupled to either one.

    Yes.
    =A0
    Please correct me= if I'm missing something essential.

    Not at first glance,

    So you do agree with what was in that = email?=A0 I assumed the complete lack of response meant nobody thought it r= elevant.
    =A0
    > In what I proposed, a client is specifically configured to use a = (single)
    > proxy, and that proxy is providing specific enhanced servi= ces on behalf of
    > the client.=A0 With that model it makes little sen= se to accommodate placing
    > the proxy at the same end-point (port) as a normal server.
    >
    = > However, if there's no buy-in for that change, and there's som= e compelling
    > reason why we should accommodate two applications at a= single port, I
    > suppose a set of rules to use UriScheme values as a cue to whether a r= equest
    > might have been intended for a proxy or a server could be ma= de to work.
    > "Don't do that" seems like a better appro= ach, in my opinion.

    There are two things:

    1. Does it make sense to run a proxy= and a server on the same port?

    The answer is probably: No.

    Good.

    2. What to do whe= n a client thinks an end-point is a server when it's
    actually a prox= y?

    Ah.=A0 I lost the context from the earlier parts of the thread, an= d assumed your proposal was a way to allow dual-use. =A0In fact, your rules= seem to be a complete workable solution that does allow dual use. =A0Nice.= =A0That's not what raised my hackles.

    The solution is t= o have the client say what it thinks, so that its
    wrong assumption can b= e pointed out by the recipient.

    That is a good solution.=A0 But in the details, I think it would b= e more clear if the client does say what it thinks (that it's talking w= ith a proxy), rather than creating complex rules on how to interpret Uri-Sc= heme to infer that it thinks it's talking with a proxy.=A0 So use a new= option named Uri-Proxy with no value, the presence/absence of which indica= tes the client's expectations.=A0 Don't overload Uri-Scheme to mean= something weird that could conflict with future use, e.g. putting a coap a= nd a coapm (multicast) service on the same port.

    Change Uri-Scheme to Uri-Proxy in your proposal and you've got a so= lution that allows disambiguation while at the same time allowing both func= tions to occur on the same port and not muddying what Uri-Scheme means. =A0= That's the sort of approach I like: one technique that solves multiple = problems without=A0introducing new ones. =A0Barring some undiscovered flaw,= I'd support that.
    =A0

    Klaus
    _______________________________________________
    core m= ailing list
    core@ietf= .org
    https://www.ietf.org/mailman/listinfo/core



    --20cf3054a61576ad3d0495b87249-- From pab@peoplepowerco.com Tue Nov 23 05:46:55 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 157FD3A695E for ; Tue, 23 Nov 2010 05:46:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.995 X-Spam-Level: X-Spam-Status: No, score=-1.995 tagged_above=-999 required=5 tests=[AWL=-0.019, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00Ki-twiUj0Z for ; Tue, 23 Nov 2010 05:46:46 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 1A64F3A6947 for ; Tue, 23 Nov 2010 05:46:45 -0800 (PST) Received: by fxm3 with SMTP id 3so6067470fxm.31 for ; Tue, 23 Nov 2010 05:47:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.71.201 with SMTP id i9mr5589779faj.89.1290520062861; Tue, 23 Nov 2010 05:47:42 -0800 (PST) Received: by 10.223.70.198 with HTTP; Tue, 23 Nov 2010 05:47:42 -0800 (PST) In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E01AD475F@zensys17.zensys.local> References: <6D9687E95918C04A8B30A7D6DA805A3E01AD475F@zensys17.zensys.local> Date: Tue, 23 Nov 2010 07:47:42 -0600 Message-ID: From: Peter Bigot To: Anders Brandt Content-Type: multipart/alternative; boundary=20cf30433ed0ec24680495b89d60 Cc: core , Klaus Hartke Subject: Re: [core] Proxy versus Gateway X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 13:46:55 -0000 --20cf30433ed0ec24680495b89d60 Content-Type: text/plain; charset=ISO-8859-1 We need to correct that understanding, then. Personally, I got thrown somewhere in this email chain by an offhand reference to "the default gateway", meaning where to send IP packets that have a destination address not in the routing table. ("What 'default gateway'? CoAP doesn't define a ... oh, that kind of gateway.") Notwithstanding, I think "gateway" is the right term. You could use "CoAP gateway" to distinguish it from "IP gateway", leaving "gateway" to be left generic or determined by context. There's going to be ambiguity; we can't help that. Any other term is either going to be unrecognized and have to be constantly explained, or already means something else (like the original CoAP use of proxy encompassing only a cache) resulting in latent misunderstanding. Though if you have a specific term in mind, and its use can be traced to a definition like I did with gateway and proxy, my position could change. Peter On Tue, Nov 23, 2010 at 7:28 AM, Anders Brandt wrote: > Hi Peter > > > ...A gateway can operate at any level in the OSI stack. Those that operate > at the application (CoAP) level may end up doing a translation that involves > initiating a new CoAP request, potentially to a completely different URI, > even one with a non-CoAP scheme. Such a node is a gateway ... > > > You are getting to some important detail here. And I agree with you that > terminology is extremely important. > > What I think (speaking for myself at least) is causing us to avoid the > "gateway" term is exactly the inherent > understanding that it translates my application content. > What if my device is completely transparent to all application payload, but > just does a bit of caching and buffering? > Everytime I say "gateway" to a customer I will have to explain that this > particular gateway does not > do any translation - it just enables connectivity via standard frame > formats. > > New term wanted! > > - Anders > > ------------------------------ > *Fra:* Peter Bigot [mailto:pab@peoplepowerco.com] > *Sendt:* ti 23-11-2010 06:13 > *Til:* core; matthieu.vial@fr.non.schneider-electric.com; Klaus Hartke; > Anders Brandt > *Emne:* Re: Proxy versus Gateway > > I hope nobody minds, but I've transplanted this back to the original > thread, with my original argument below. Though my corrections to Klaus's > summary of what I said may be accurate, I'd prefer to not depend on that. > Please refresh your memories of what I wrote last month, as I have done. > (In particular, I don't want to lose my subtle other suggestion which is > that "cache" needs to be refined, not just use of "proxy" and "gateway". > Personally I'd like to see the entire semantic description of CoAP caching > pulled out to another document, as I believe is being done in HTTPbis, > leaving base CoAP to describe the generic encoding and method-independent > transaction details.) > > Matthieu: All your cases are gateways. A gateway can operate at any level > in the OSI stack. Those that operate at the application (CoAP) level may > end up doing a translation that involves initiating a new CoAP request, > potentially to a completely different URI, even one with a non-CoAP scheme. > Such a node is a gateway because the authority part of the URI led the data > flow to it. In my mind, there's no implication that a gateway is restricted > from inspecting or manipulating other parts of the URI in order to fulfill > its responsibilities (Fielding's list of gateway purposes should not be read > as exhaustive). Do you feel that a further refinement to characterize types > of gateway would improve an understanding of CoAP? > > Anders: As I suggested in my specific response to caching, neither the > client nor the server should be aware that there are gateways between them, > at least not at the REST level. Any such knowledge introduces coupling, and > limits the ability of organizations to restructure their networks while > providing the same resources via the same URIs. > > Peter > > On Tue, Nov 23, 2010 at 2:57 AM, < > matthieu.vial@fr.non.schneider-electric.com> wrote: > >> >> >>* A gateway (a.k.a., reverse proxy, big brother, ...) is an >> >>intermediary imposed by the origin server to support sleeping >> nodes or >> >>perform any other role that might be hidden behind the authority >> part >> >>of a URI. >> >> >> > Almost; the origin server may be unaware of the presence of a gateway. >> The network may impose the gateway. >> >> I'm sorry but I can't catch the exact meaning of "any other role that >> might be hidden behind the authority part >> of a URI". >> A gateway acting as a reverse proxy could for example implement a cache >> for sleeping nodes. The reverse proxy can map the sleeping nodes into its >> own namespace. In that case it's not just the authority part of the URI but >> the full URI that is used to decide what should be done. >> coap://bigbrother1.example.org/sensor1/ is actually redirected to coap:// >> sensor1.example.org/ >> coap://bigbrother1.example.org/sensor2/ is actually redirected to coap:// >> sensor2.example.org/ >> >> Or maybe you want to separate the different functions of the gateway into >> different domain names that resolve to the same IP? >> coap://cache.example.org/ implements the caching feature >> coap://http.example.org/ implements HTTP translation >> coap://6to4.example.org/ implements IPv6 to IPv4 translation >> But then I suppose it could also be defined like that: >> coap://gateway.example.org/cache/ >> coap://gateway.example.org/http/ >> coap://gateway.example.org/6to4/ >> >> On the other hand a gateway acting as a transparent/interception proxy >> will use some IP magic to answer on the behalf of the origin server. In that >> case the gateway only uses the authority part of the URI (or the destination >> address). But transparent proxying requires some advanced IP stack features >> that are not always available: >> 1. Redirect sessions destined to the outer network to a local process >> using a packet filter rule. >> 2. Make it possible for a process to listen to connections on a foreign >> address. >> 3. Make it possible for a process to initiate a connection with a foreign >> address as a source. >> >> Could you please tell me if something is wrong with my reasoning? >> >> Regards, >> Matthieu >> > > > On Sat, Oct 23, 2010 at 5:55 AM, Peter Bigot wrote: > >> I and others have been somewhat confused by the CoAP terms "proxy" and >> "cache", which unless clarified actually mix several concepts. I found >> enlightenment in section 5.2.3 of Fielding's dissertation >> : >> >> Intermediary components act as both a client and a server in order to >> forward, with possible translation, requests and responses. A proxy >> component is an intermediary selected by a client to provide interface >> encapsulation of other services, data translation, performance enhancement, >> or security protection. A gateway (a.k.a., reverse proxy) component is an >> intermediary imposed by the network or origin server to provide an interface >> encapsulation of other services, for data translation, performance >> enhancement, or security enforcement. Note that the difference between a >> proxy and a gateway is that a client determines when it will use a proxy. >> >> I had been misled because the non-technical use of the term "proxy" is >> appropriate for several key roles in a CoAP system, including that entity >> which serves as the intermediary for sleeping nodes. The correct term for >> this function is "gateway", as most clients need not be aware that they are >> acting through an intermediary. >> >> CoAP's use of the term "proxy" is inconsistent with these definitions: >> >> 5.3. Proxying A proxy is defined as a CoAP end-point which services cached requests >> on behalf of other CoAP end-points. Any node in a CoAP network may >> act as a proxy, although in general the node between the constrained >> network and the Internet at large SHOULD always support proxy >> functionality. >> >> This is misleading because it focuses solely on caching, leaving aside the >> other reasons why a proxy might be necessary. As an example, many >> constrained nodes will not support DNS, and therefore cannot translate an >> ASCII authority found within a URI to a network address. Similarly, >> constrained devices are unlikely to have the computational resources >> necessary to support public key cryptography. It would be better to say >> that a proxy is an intermediary explicitly selected by the client as its >> agent when dealing with any transaction it is unable to perform directly. >> >> This is an important but currently implicit role in a CoAP system. As >> with the traditional use of proxy in web browsers (back before desktops >> became full participants in the Internet), a CoAP client should need only >> one proxy to which it can delegate all CoAP transactions it can't do >> itself. Configuration of this proxy for a particular node is an >> administrative function outside the scope of CoAP as an on-wire protocol. >> (If multiple proxies were expected at a client, there would have to be some >> way of selecting which proxy to use for which operation, an unnecessary >> complication that could easily be supported by delegation.) CoAP need >> merely provide a mechanism by which the full information required to >> delegate the transaction can be conveyed, which it does. >> >> I encourage use of the term "gateway" when referring to an entity that >> supports sleeping nodes, coordinates group activities, or performs any other >> role that might be hidden behind the authority part of a URI. >> >> Caching in turn is a function that may be paired with a proxy or with a >> gateway, but is not inherently coupled to either one. >> >> If it's not too late to make so major a change in terminology and concept, >> I would encourage a rewrite of section 5 to make clear that proxies, >> gateways, and caches are independent functions. I would contribute text for >> this if the editors would find that helpful. >> >> Peter >> > > --20cf30433ed0ec24680495b89d60 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable We need to correct that understanding, then.=A0 Personally, I got thrown so= mewhere in this email chain by an offhand reference to "the default ga= teway", meaning where to send IP packets that have a destination addre= ss not in the routing table.=A0 ("What 'default gateway'?=A0 C= oAP doesn't define a ... oh, that kind of gateway.")

    Notwithstanding, I think "gateway" is the right term.=A0 You = could use "CoAP gateway" to distinguish it from "IP gateway&= quot;, leaving "gateway" to be left generic or determined by cont= ext.

    There's going to be ambiguity; we can't help that.=A0 Any other= term is either going to be unrecognized and have to be constantly explaine= d, or already means something else (like the original CoAP use of proxy enc= ompassing only a cache) resulting in latent misunderstanding.

    Though if you have a specific term in mind, and its use can be traced t= o a definition like I did with gateway and proxy, my position could change.=

    Peter

    On Tue, Nov 23, 2010 at 7:2= 8 AM, Anders Brandt <abr@sdesigns.dk> wrote:
    Hi Peter
    =A0
    <Quote>
    ...A gateway can operate at any le= vel in the OSI stack.=A0 Those that operate at the application (CoAP) level= may end up doing a translation that involves initiating a new CoAP request= , potentially to a completely different URI, even one with a non-CoAP schem= e.=A0 Such a node is a gateway ...
    </Qoute>
    =A0
    You are getting to some important detail here. And I agree= with you that terminology is extremely important.
    =A0
    What I think (speaking for myself at least) is causing us = to avoid the "gateway" term is exactly the inherent
    understanding that it translates my application content.
    What if my device is completely transparent to all applica= tion payload, but just does a bit of caching and buffering?
    Everytime I say "gateway" to a customer I will h= ave to explain that this particular gateway does not
    do any translation = - it just enables connectivity via standard frame formats.
    =A0
    New term wanted!
    =A0
    - Anders

    Fra: Peter Bigot [mailto:pab@peoplepowerco.com]=
    Sendt: ti 23-11-2010 06:13
    Til: core; matthieu.v= ial@fr.non.schneider-electric.com; Klaus Hartke; Anders Brandt
    Emne: Re: Proxy versus Gateway

    I hope nobody minds, but I've transplanted t= his back to the original thread, with my original argument below.=A0 Though= my corrections to Klaus's summary of what I said may be accurate, I= 9;d prefer to not depend on that.=A0 Please refresh your memories of what I= wrote last month, as I have done.=A0 (In particular, I don't want to l= ose my subtle other suggestion which is that "cache" needs to be = refined, not just use of "proxy" and "gateway".=A0 Pers= onally I'd like to see the entire semantic description of CoAP caching = pulled out to another document, as I believe is being done in HTTPbis, leav= ing base CoAP to describe the generic encoding and method-independent trans= action details.)

    Matthieu:=A0 All your cases are gateways.=A0 A gateway can operate at a= ny level in the OSI stack.=A0 Those that operate at the application (CoAP) = level may end up doing a translation that involves initiating a new CoAP re= quest, potentially to a completely different URI, even one with a non-CoAP = scheme.=A0 Such a node is a gateway because the authority part of the URI l= ed the data flow to it.=A0 In my mind, there's no implication that a ga= teway is restricted from inspecting or manipulating other parts of the URI = in order to fulfill its responsibilities (Fielding's list of gateway pu= rposes should not be read as exhaustive).=A0 Do you feel that a further ref= inement to characterize types of gateway would improve an understanding of = CoAP?

    Anders: As I suggested in my specific response to caching, neither the = client nor the server should be aware that there are gateways between them,= at least not at the REST level.=A0 Any such knowledge introduces coupling,= and limits the ability of organizations to restructure their networks whil= e providing the same resources via the same URIs.

    Peter

    On Tue, Nov 23, 2010 at 2:57 AM, <matthieu.vial@fr.non.schneider-electric.com> wrote:

        >>* A gateway (a.k.a., reverse proxy, big brother= , ...) is an
        >>intermediary imposed by the origin server to suppor= t sleeping nodes or
        >>perform any other role that might be hidden = behind the authority part
        >>of a URI.


    >=A0Almost; t= he origin server may be unaware of the presence of a gateway.=A0 The networ= k may impose the gateway.

    I'm sorr= y but I can't catch the exact meaning of "any other role that migh= t be hidden behind the authority part
    of a URI".
    A gateway acting as a reverse p= roxy could for example implement a cache for sleeping nodes. The reverse pr= oxy can map the sleeping nodes into its own namespace. In that case it'= s not just the authority part of the URI but the full URI that is used to d= ecide what should be done.
    coap://bigbrother1.example.org/sensor1/ is actually redirec= ted to coap://sen= sor1.example.org/
    coap://bigbrother1.example.org/sensor2/ is actually redirec= ted to coap://sen= sor2.example.org/

    Or maybe you want to separate the different functions = of the gateway into different domain names that resolve to the same IP?
    coap://cache.example.org/ implements the caching feature coap://http.example.org/ implements HTTP translation
    coap://6to4.e= xample.org/ implements IPv6 to IPv4 translation
    But then I suppose it could also be defined like that:
    coap://gateway.example.org/cache/
    coap://ga= teway.example.org/http/
    coap://gateway.example.org/6to4/

    On= the other hand a gateway acting as a transparent/interception proxy will u= se some IP magic to answer on the behalf of the origin server. In that case= the gateway only uses the authority part of the URI (or the destination ad= dress). But transparent proxying requires some advanced IP stack features t= hat are not always available:
    1. Redirect sessions destined to the outer network to a lo= cal process using a packet filter rule.
    2. Make = it possible for a process to listen to connections on a foreign address.
    3. Make it possible for a process to initiate a connection= with a foreign address as a source.

    Could y= ou please tell me if something is wrong with my reasoning?

    Regards,
    Matthieu


    On Sat, Oct 23, 2010 at 5:55 AM, Peter Bigot <pab@peoplepowerco.com> wrote:
    I and others have= been somewhat confused by the CoAP terms "proxy" and "cache= ", which unless clarified actually mix several concepts.=A0 I found en= lightenment in section 5.2.3 of Field= ing's dissertation:

    Intermediary components act as both a cli= ent and a server in order to forward, with possible translation, requests a= nd responses. A proxy component is an intermediary selected by a client to = provide interface encapsulation of other services, data translation, perfor= mance enhancement, or security protection. A gateway (a.k.a., reverse proxy= ) component is an intermediary imposed by the network or origin server to p= rovide an interface encapsulation of other services, for data translation, = performance enhancement, or security enforcement. Note that the difference = between a proxy and a gateway is that a client determines when it will use = a proxy.

    I had been misled because the non-technical use of the term "= ;proxy" is appropriate for several key roles in a CoAP system, includi= ng that entity which serves as the intermediary for sleeping nodes.=A0 The = correct term for this function is "gateway", as most clients need= not be aware that they are acting through an intermediary.

    CoAP's use of the term "proxy" is inconsistent with these= definitions:
    5.3.  Proxying
    =A0=A0 A proxy is defined as a=
 CoAP end-point which services cached requests
   on behalf of other CoAP end-points.  Any node in a CoAP network may
   act as a proxy, although in general the node between the constrained
   network and the Internet at large SHOULD always support proxy
   functionality.
    This is misleading because it focuses solely on caching, leaving asid= e the other reasons why a proxy might be necessary.=A0=A0 As an example, ma= ny constrained nodes=A0 will not support DNS, and therefore cannot translat= e an ASCII authority found within a URI to a network address. =A0 Similarly= , constrained devices are unlikely to have the computational resources nece= ssary to support public key cryptography. =A0 It would be better to say tha= t a proxy is an intermediary explicitly selected by the client as its agent= when dealing with any transaction it is unable to perform directly.

    This is an important but currently implicit role in a CoAP system.=A0 A= s with the traditional use of proxy in web browsers (back before desktops b= ecame full participants in the Internet), a CoAP client should need only on= e proxy to which it can delegate all CoAP transactions it can't do itse= lf.=A0 Configuration of this proxy for a particular node is an administrati= ve function outside the scope of CoAP as an on-wire protocol.=A0 (If multip= le proxies were expected at a client, there would have to be some way of se= lecting which proxy to use for which operation, an unnecessary complication= that could easily be supported by delegation.)=A0 CoAP need merely provide= a mechanism by which the full information required to delegate the transac= tion can be conveyed, which it does.

    I encourage use of the term "gateway" when referring to an en= tity that supports sleeping nodes, coordinates group activities, or perform= s any other role that might be hidden behind the authority part of a URI.
    Caching in turn is a function that may be paired with a proxy or with a= gateway, but is not inherently coupled to either one.

    If it's n= ot too late to make so major a change in terminology and concept, I would e= ncourage a rewrite of section 5 to make clear that proxies,=A0 gateways, an= d caches are independent functions.=A0 I would contribute text for this if = the editors would find that helpful.

    Peter


    --20cf30433ed0ec24680495b89d60-- From pab@peoplepowerco.com Tue Nov 23 05:50:49 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 167CE3A6947 for ; Tue, 23 Nov 2010 05:50:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.994 X-Spam-Level: X-Spam-Status: No, score=-1.994 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74tGVjQ2jORq for ; Tue, 23 Nov 2010 05:50:48 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id B95B53A694D for ; Tue, 23 Nov 2010 05:50:47 -0800 (PST) Received: by fxm3 with SMTP id 3so6071561fxm.31 for ; Tue, 23 Nov 2010 05:51:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.104.68 with SMTP id n4mr4041734fao.127.1290520303944; Tue, 23 Nov 2010 05:51:43 -0800 (PST) Received: by 10.223.70.198 with HTTP; Tue, 23 Nov 2010 05:51:43 -0800 (PST) In-Reply-To: References: Date: Tue, 23 Nov 2010 07:51:43 -0600 Message-ID: From: Peter Bigot To: matthieu.vial@fr.non.schneider-electric.com Content-Type: multipart/alternative; boundary=001636c9239e4ac3d70495b8ac2b Cc: Klaus Hartke , core Subject: Re: [core] Proxy and server on the same port X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 13:50:49 -0000 --001636c9239e4ac3d70495b8ac2b Content-Type: text/plain; charset=ISO-8859-1 To help people tracking this in the email archive three years from now: Please see response in the "Proxy versus Gateway" thread. Peter On Tue, Nov 23, 2010 at 2:57 AM, < matthieu.vial@fr.non.schneider-electric.com> wrote: > > >>* A gateway (a.k.a., reverse proxy, big brother, ...) is an > >>intermediary imposed by the origin server to support sleeping > nodes or > >>perform any other role that might be hidden behind the authority > part > >>of a URI. > > > > Almost; the origin server may be unaware of the presence of a gateway. > The network may impose the gateway. > > I'm sorry but I can't catch the exact meaning of "any other role that might > be hidden behind the authority part > of a URI". > A gateway acting as a reverse proxy could for example implement a cache for > sleeping nodes. The reverse proxy can map the sleeping nodes into its own > namespace. In that case it's not just the authority part of the URI but the > full URI that is used to decide what should be done. > coap://bigbrother1.example.org/sensor1/ is actually redirected to coap:// > sensor1.example.org/ > coap://bigbrother1.example.org/sensor2/ is actually redirected to coap:// > sensor2.example.org/ > > Or maybe you want to separate the different functions of the gateway into > different domain names that resolve to the same IP? > coap://cache.example.org/ implements the caching feature > coap://http.example.org/ implements HTTP translation > coap://6to4.example.org/ implements IPv6 to IPv4 translation > But then I suppose it could also be defined like that: > coap://gateway.example.org/cache/ > coap://gateway.example.org/http/ > coap://gateway.example.org/6to4/ > > On the other hand a gateway acting as a transparent/interception proxy will > use some IP magic to answer on the behalf of the origin server. In that case > the gateway only uses the authority part of the URI (or the destination > address). But transparent proxying requires some advanced IP stack features > that are not always available: > 1. Redirect sessions destined to the outer network to a local process > using a packet filter rule. > 2. Make it possible for a process to listen to connections on a foreign > address. > 3. Make it possible for a process to initiate a connection with a foreign > address as a source. > > Could you please tell me if something is wrong with my reasoning? > > Regards, > Matthieu > --001636c9239e4ac3d70495b8ac2b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable To help people tracking this in the email archive three years from now: Ple= ase see response in the "Proxy versus Gateway" thread.

    Pet= er

    On Tue, Nov 23, 2010 at 2:57 AM, <matthieu.vial@fr.non.schneider-electric.com> wrote:

        >>* A gateway (a.k.a., reverse proxy, big brother= , ...) is an
        >>intermediary imposed by the origin server to support sleeping nodes= or
        >>perform any other role that might be hidden behind the authority pa= rt
        >>of a URI.


    >=A0Almost; the origin server may be unaware of the presence of a gatewa= y.=A0 The network may impose the gateway.

    I'm sorry but I can't catch the exact meanin= g of "any other role that might be hidden behind the authority part of a URI".
    A gateway acting as a reverse proxy could for example impl= ement a cache for sleeping nodes. The reverse proxy can map the sleeping no= des into its own namespace. In that case it's not just the authority pa= rt of the URI but the full URI that is used to decide what should be done.<= /font>
    coap://bigbrother1.example.org/sensor1/ is actually redirec= ted to coap://sen= sor1.example.org/
    coap://bigbrother1.example.org/sensor2/ is actually redirec= ted to coap://sen= sor2.example.org/

    Or maybe you want to separate the different functions of t= he gateway into different domain names that resolve to the same IP?<= br> coap://cache.example.org/ implements the caching feature
    coap://http.example.org/ implements HTTP translation
    coap://6to4.example.org/ implements IPv6 to IPv4 translation
    But then I suppose it could also be defined like that:
    coap://gateway.example.org/cache/
    coap://gateway.example.org/http/
    coap://gateway.example.org/6to4/

    On the other hand a gateway acting as a transparent/interc= eption proxy will use some IP magic to answer on the behalf of the origin s= erver. In that case the gateway only uses the authority part of the URI (or= the destination address). But transparent proxying requires some advanced = IP stack features that are not always available:
    1. Redirect sessions destined to the outer network to a= local process using a packet filter rule.
    2. Make it possible for a process to listen to connecti= ons on a foreign address.
    3. Make it possible for a process to initiate a connect= ion with a foreign address as a source.

    Could you please tell me if something is wrong with my rea= soning?

    Regards,
    Matthieu

    #avg_ls_inline_popup { position:absolute; z-index:99= 99; padding: 0px 0px; margin-left: 0px; margin-top: 0px; width: 240px; = overflow: hidden; word-wrap: break-word; color: black; font-size: 10px;= text-align: left; line-height: 13px;} --001636c9239e4ac3d70495b8ac2b-- From klaus.hartke@googlemail.com Tue Nov 23 08:45:09 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E627428C16C for ; Tue, 23 Nov 2010 08:45:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id afJIMWMheQdW for ; Tue, 23 Nov 2010 08:45:07 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id E237428C145 for ; Tue, 23 Nov 2010 08:45:06 -0800 (PST) Received: by pzk27 with SMTP id 27so90117pzk.31 for ; Tue, 23 Nov 2010 08:46:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=RE80KflYkft8MzdlXvtN00+LciVpN90tb26HgJ3sSKg=; b=fr2SPJYSVOjKiGZ3NX6k4SNKonR2u0RoHWqOy175YNE44Tt3YmC7VHVMvXhV8Cvewl AqQ53y71pFycnUvrOZgJeopY5cwDj4Ky7NNZIGvyz7YZ3zJpnpkYD3l3CJgckRM1H3zh KiZ7vY8amFgBt+3WF81ArJfGFAdDG9C+EfUeI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=q/Chhp2YHE2l4i+as+1QRrpQqOJ4kjBlm82PTRRL9lfAPhDLrPr0pGGv6nPiOFdTOo 21eqX4k1rJm/fF/PXfZKdNnNSJwAYY+yq9ofY/Z/Z1dcV8q3xHbudJe4KjIrbMEUS1ET aEMhR4xri1oFvHLUjo2IztUQMG5m27I96EwE0= MIME-Version: 1.0 Received: by 10.204.72.140 with SMTP id m12mr7073942bkj.163.1290530763605; Tue, 23 Nov 2010 08:46:03 -0800 (PST) Sender: klaus.hartke@googlemail.com Received: by 10.204.121.134 with HTTP; Tue, 23 Nov 2010 08:46:03 -0800 (PST) Date: Tue, 23 Nov 2010 17:46:03 +0100 X-Google-Sender-Auth: yuztwaGkOw_vRUHYU-4PUvbaJJ4 Message-ID: From: Klaus Hartke To: core Content-Type: text/plain; charset=ISO-8859-1 Subject: [core] What responses are cacheable (Re: When are two requests equivalent?) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 16:45:09 -0000 Zach Shelby wrote: > When we cache something, we are caching the > representation of a resource identified by that URI. > Thus it would make no sense to cache an error > response. Actually, it makes a lot of sense to cache error responses. Example: C: GET coap://server/resource S: 404 (max-age=3600s) "Not found." If the server returns that the resource doesn't exist and that this information will be fresh for the next 3600 seconds, it doesn't make sense for the client to repeat its request. This is a perfect example when a GET request can be avoided by using the cached response. It also makes a lot of sense to cache error responses to other non-GET requests. Example: C: PUT coap://server/resource (content-type=0) "Hello World" S: 405 (max-age=365d) "Method not allowed." If the server returns that the resource doesn't support the requested method and that this information will be fresh for the next 365 days, it doesn't make sense for the client to repeat the request before the time is up and expect a different result. ("Insanity: doing the same thing over and over again and expecting different results." - Albert Einstein) Of course, it makes no sense to cache the 200 response to a PUT, POST or DELETE request. And I'm not sure if it makes sense to validate that a resource still doesn't exist or doesn't support a method using Etags. So regarding the cacheability of responses, I'd propose the following: 200 - in response to GET: cacheable; can be validated using Etag - in response to PUT/POST/DELETE: not cacheable 4xx/5xx - cacheable, not validatable 304 - used to signal that a cached 200 response is valid; updates freshness Klaus From matthieu.vial@fr.non.schneider-electric.com Tue Nov 23 09:29:21 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8155D3A6893 for ; Tue, 23 Nov 2010 09:29:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.132 X-Spam-Level: X-Spam-Status: No, score=-3.132 tagged_above=-999 required=5 tests=[AWL=0.466, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jme6273oj9KN for ; Tue, 23 Nov 2010 09:29:18 -0800 (PST) Received: from mailX02.eud.schneider-electric.com (mailx02.eud.schneider-electric.com [205.167.7.38]) by core3.amsl.com (Postfix) with ESMTP id 9E8BB3A693E for ; Tue, 23 Nov 2010 09:29:16 -0800 (PST) Received: from ateui02.Schneider-Electric.com ([10.198.14.10]) by mailX02.eud.schneider-electric.com with ESMTP id 2010112318104084-191468 ; Tue, 23 Nov 2010 18:10:40 +0100 In-Reply-To: To: Peter Bigot X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: matthieu.vial@fr.non.schneider-electric.com Date: Tue, 23 Nov 2010 18:30:01 +0100 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on ATEUI02.Schneider-Electric.com/T/SVR/Schneider at 23/11/2010 18:30:03, Itemize by SMTP Server on AXEU2OUT.schneider-electric.com/X/SVR/SEIxtra at 23/11/2010 18:10:40, Serialize by Router on AXEU2OUT.schneider-electric.com/X/SVR/SEIxtra at 23/11/2010 18:10:47, Serialize complete at 23/11/2010 18:10:47 Content-type: multipart/alternative; Boundary="0__=4EBBFD77DFCEA1C48f9e8a93df938690918c4EBBFD77DFCEA1C4" Content-Disposition: inline Cc: core Subject: Re: [core] Proxy versus Gateway X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 17:29:21 -0000 --0__=4EBBFD77DFCEA1C48f9e8a93df938690918c4EBBFD77DFCEA1C4 Content-transfer-encoding: quoted-printable Content-type: text/plain; charset=ISO-8859-1 Peter >Matthieu:=A0 All your cases are gateways.=A0 A gateway can operate at = any level in the OSI stack.=A0 Those that operate at the application (CoAP)= level may end up doing a translation that involves >initiating a new CoAP request, potentially to a completely different URI, even one with a non-CoAP scheme.=A0 Such a node is a gateway because the authority part= of the URI led the data flow to it. >In my mind, there's no implication that a gateway is restricted from inspecting or manipulating other parts of the URI in order to fulfill i= ts responsibilities (Fielding's list of gateway purposes should not >be re= ad as exhaustive).=A0 Do you feel that a further refinement to characteriz= e types of gateway would improve an understanding of CoAP? I fully agree that they are all gateways. I just wanted clarified that = the gateway could perform different roles with the same authority part. The= Authority part guide the data flow through the gateway but the exact ac= tion to be taken depends on the full URI. And I don't think we need further refinement. It may help to understant= what's behind the scene to implement the gateway but it would not neces= sary improve an understanding of CoAP. Matthieu= --0__=4EBBFD77DFCEA1C48f9e8a93df938690918c4EBBFD77DFCEA1C4 Content-transfer-encoding: quoted-printable Content-type: text/html; charset=ISO-8859-1 Content-Disposition: inline

    Peter

    >Matthieu:=A0 All your cases are gateways.=A0 A gat= eway can operate at any level in the OSI stack.=A0 Those that operate a= t the application (CoAP) level may end up doing a translation that invo= lves >initiating a new CoAP request, potentially to a completely dif= ferent URI, even one with a non-CoAP scheme.=A0 Such a node is a gatewa= y because the authority part of the URI led the data flow to it.=A0
    >In my mind, there's no implication that a gateway = is restricted from inspecting or manipulating other parts of the URI in= order to fulfill its responsibilities (Fielding's list of gateway purp= oses should not >be read as exhaustive).=A0 Do you feel that a furth= er refinement to characterize types of gateway would improve an underst= anding of CoAP?

    I fully agree that they are all gateways. I just wante= d clarified that the gateway could perform different roles with the sam= e authority part. The Authority part guide the data flow through the ga= teway but the exact action to be taken depends on the full URI.<= br> And I don't think we need further refinement. It may h= elp to understant what's behind the scene to implement the gateway but = it would not necessary improve an understanding of CoAP.

    Matthieu= --0__=4EBBFD77DFCEA1C48f9e8a93df938690918c4EBBFD77DFCEA1C4-- From trac@tools.ietf.org Tue Nov 23 18:46:54 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 585D728C0E7 for ; Tue, 23 Nov 2010 18:46:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UkZyjPdr3kcU for ; Tue, 23 Nov 2010 18:46:53 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id B0FDC28C1AB for ; Tue, 23 Nov 2010 18:46:53 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PL5Oc-0007pa-KB; Tue, 23 Nov 2010 18:47:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com, hartke@tzi.org X-Trac-Project: core Date: Wed, 24 Nov 2010 02:47:46 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/core/trac/ticket/81 Message-ID: <053.89e842f5a4c5096e84594674209b060f@tools.ietf.org> X-Trac-Ticket-ID: 81 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, hartke@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] coap #81 (new): Non-confirmable message exchanges X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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 Nov 2010 02:46:54 -0000 #81: Non-confirmable message exchanges Section 2.1. of the current draft says that transaction messages enable optional reliability, and sections 2.1.1. and 2.1.2. describe reliable requests, but no section talks about unreliable interactions. (The only place where non-confirmable messages are mentioned is in section 4.1.: "Multicast messages SHOULD be Non-Confirmable.") This ticket is to define non-confirmable message exchanges. -- ----------------------------+----------------------------------------------- Reporter: hartke@… | Owner: zach@… Type: enhancement | Status: new Priority: major | Milestone: Component: coap | Version: Severity: - | Keywords: ----------------------------+----------------------------------------------- Ticket URL: core From trac@tools.ietf.org Tue Nov 23 18:47:27 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 334D43A69EF for ; Tue, 23 Nov 2010 18:47:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3X8+ut3OlV9o for ; Tue, 23 Nov 2010 18:47:26 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 6FCA028C0E7 for ; Tue, 23 Nov 2010 18:47:26 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PL5PE-00087E-FC; Tue, 23 Nov 2010 18:48:24 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com, hartke@tzi.org X-Trac-Project: core Date: Wed, 24 Nov 2010 02:48:24 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/82 Message-ID: <053.3048b61f06b5f9e56aebee58dc9e9ca0@tools.ietf.org> X-Trac-Ticket-ID: 82 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, hartke@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] coap #82 (new): Disambiguate between proxy and non-proxy requests X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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 Nov 2010 02:47:27 -0000 #82: Disambiguate between proxy and non-proxy requests What to do when a client thinks an end-point is a server when it's actually a proxy? The solution is to have the client say what it thinks, so that its wrong assumption can be pointed out by the remote end-point. Possible solutions include: * Use the Uri-Scheme Option with a small set of new rules from [http://www.ietf.org/mail-archive/web/core/current/msg01235.html here]; * Add a new Uri-Proxy Option with similar rules (option has no value); * Increment the method code by 20 for requests made through proxies. -- ----------------------------+----------------------------------------------- Reporter: hartke@… | Owner: zach@… Type: enhancement | Status: new Priority: minor | Milestone: Component: coap | Version: Severity: - | Keywords: ----------------------------+----------------------------------------------- Ticket URL: core From trac@tools.ietf.org Tue Nov 23 18:48:39 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F23428C0E7 for ; Tue, 23 Nov 2010 18:48:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zfWwHwC-CgRv for ; Tue, 23 Nov 2010 18:48:38 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 884AD3A69EB for ; Tue, 23 Nov 2010 18:48:38 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PL5QO-00088n-JF; Tue, 23 Nov 2010 18:49:36 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com, hartke@tzi.org X-Trac-Project: core Date: Wed, 24 Nov 2010 02:49:36 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/core/trac/ticket/83 Message-ID: <053.b061b9a9e179f3d95df711ee7014ee5b@tools.ietf.org> X-Trac-Ticket-ID: 83 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, hartke@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] coap #83 (new): Critical options in cached states X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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 Nov 2010 02:48:39 -0000 #83: Critical options in cached states -- ----------------------------+----------------------------------------------- Reporter: hartke@… | Owner: zach@… Type: defect | Status: new Priority: minor | Milestone: Component: coap | Version: Severity: - | Keywords: ----------------------------+----------------------------------------------- Ticket URL: core From zach@sensinode.com Wed Nov 24 01:48:00 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88A723A688A for ; Wed, 24 Nov 2010 01:48:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.465 X-Spam-Level: X-Spam-Status: No, score=-3.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8YZpLTu0wq3 for ; Wed, 24 Nov 2010 01:47:59 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id AD3273A6817 for ; Wed, 24 Nov 2010 01:47:58 -0800 (PST) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id oAO9mp5Z026113 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 24 Nov 2010 11:48:51 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-198-899804000; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: Date: Wed, 24 Nov 2010 11:48:52 +0200 Message-Id: <7B7188E0-9A64-412F-98B6-3152FE499DAC@sensinode.com> References: <8B0A9FCBB9832F43971E38010638454F03F33652D2@SISPE7MB1.commscope.com> <02FEE582-3AD1-44BD-90D0-1F272AE5D255@sensinode.com> To: Peter Bigot X-Mailer: Apple Mail (2.1081) Cc: Mark Nottingham , "core Environments\) WG" , "Thomson, Martin" Subject: Re: [core] Core linking X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 09:48:00 -0000 --Apple-Mail-198-899804000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 22, 2010, at 5:53 PM, Peter Bigot wrote: > On Mon, Nov 22, 2010 at 6:38 AM, Zach Shelby = wrote: > > 'id' seems a little strange. Unless the scope of the identifier is = something other than the server, the URL provides enough information for = someone to identify a resource. Does this have a different scope than = the one server? Or is the intent to convey information on from = different identification domains? >=20 > We were originally thinking ID would have global scope, something like = a UUID. However in Beijing it was suggested to instead give it server = scope and use it as a kind of index. For example you might have three = different hosted resources with the semantic name "TemperatureC". The = index would be used to give each an index on the server. >=20 > This is really unconvincing. "a kind of index"? How is the = application supposed to use that index? This idea of an index was brought up in Beijing by Carsten. This was = just an idea thrown out there during the meeting.=20 > I don't think we should include id without a better understanding of = what it's for, why it's necessary, and how the (M2M > ) application or a human is expected to make use of it. I happen to agree, if we don't find its use as either a universal ID or = a local index useful, then it can be removed. The current draft defines = that this could be an XRI for the resource. Do people familiar with XRIs = think this would be useful? =20 >=20 > > Can you use UTF-8 rather than ASCII? The only cost being that = clients need to be able to cope with having the high bit set in each = octet. The cost to a parser can be quite small and I think that you'll = find that this will save you a lot of awkward questions. >=20 > Now this is a very interesting idea, which will probably save us lots = of pain later. I will make a ticket. >=20 > OK. I wonder if we should do the same with the URI options that carry = text. (Actually, we have to, at least for URI-Query, if we intend to = support search for UTF-8 parameter values.) Good question, I will make a coap ticket on that. Already our text/* = MIME types are defined as being UTF-8. > > In my experience, having a domain-specific namespace for identifying = the type of resource is the easiest solution. Something defined by the = server with scoping for the server. I think that this is what you = intended for the 'n' parameter. Though in this case it might be better = to find a better label for the parameter. "name" is something with a = lot of semantic baggage. Maybe you can consider using 'id' for this = purpose (in light of my above comment). > > > > ;id=3D'current';rel=3Dsensor;title=3D"Current = Temperature" > > ;id=3D'hourly';rel=3Dsensor;title=3D"Temperate Average = (Hourly)" > > > > This is a tricky problem. I expect that you will need to explore = your options and provide a good amount of explanatory text on the topic = when you finally decide. Each type-/name-/identifier-class parameter = needs a description that identifies scope, domain and all that sort of = stuff. I don't think that there is enough there yet. >=20 > I think it would be inappropriate to use the "rel" attribute with a = value "sensor"; the server does not have a "sensor" relation to the = resource "/temp/now". "/temp/now" is a resource with role (class, type) = "sensor". Adding a new link parameter would be appropriate, if it is = necessary to do this. >=20 > In fact, can "n" (which is also pretty vague) go away if we add two = new parameters: >=20 > u -- units, a semantic identifier like "degC" >=20 > r -- role, a semantic identifier like "temperature" That is getting too specific. If we were developing a framework for = sensors, it would make sense. But for general M2M use we need to allow = the application domain, deployment or other SDO to specify what their = names mean. If a specific application needs more specific fields, it can = always add its own link extensions.=20 Zach >=20 > We'll need to discuss this some more, maybe more examples will be the = best for nailing down the best uses for the extensions. >=20 > Regards, > Zach >=20 > > > > --Martin > > > > (Feel free to forward this to the core WG, if you think that this is = useful.) >=20 > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 >=20 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 --Apple-Mail-198-899804000 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9 fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb 6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja 5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I 2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTEyNDA5NDg1 M1owIwYJKoZIhvcNAQkEMRYEFHD5m9gv0kFw6sCrQu7iiuIiHcB0MIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAJUNqSq3Nr7t8NXtEe/NLbnjc3aUxtDc2s9HHe3w6+bhMlMK0RXaFZkm dd7f377GQXGDUoDUgG1rSZctggIaXPHnxd1V633iVBcsQU9JPe6OGKt+Ee6+3La954nUafoHmL07 zFiP9FyCL8dP1/HDRETdHuhBsqvyl9gpuRI8isyPJc5imWvTXuOfiiQ6khjbNMPQntE44mP6TVmG Bj0yGvNnVQAXa64cqk99fhpgwPjgK+SFphfb3mnC5ifj+i2gVwN6yYgVTbjXvy1Gdu2SoGn9Kef8 ZdxLMwsRv0c8isFvj4eEtL5BseP+GDkhkkQdf0dG5uqutgCa2hPIaM0I6zUAAAAAAAA= --Apple-Mail-198-899804000-- From trac@tools.ietf.org Wed Nov 24 01:55:02 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D4FD28C0F1 for ; Wed, 24 Nov 2010 01:55:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k823W9TEfixN for ; Wed, 24 Nov 2010 01:55:01 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id B191028C0F2 for ; Wed, 24 Nov 2010 01:55:01 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PLC52-00007j-Ga; Wed, 24 Nov 2010 01:56:00 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Wed, 24 Nov 2010 09:56:00 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/42#comment:1 Message-ID: <066.057cd9cd36caab10d506a73031b6cbfe@tools.ietf.org> References: <057.5a0b47dd50a974001be4384c2bf76521@tools.ietf.org> X-Trac-Ticket-ID: 42 In-Reply-To: <057.5a0b47dd50a974001be4384c2bf76521@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] link-format #42 (new): Finalize the link-extensions to define X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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 Nov 2010 09:55:02 -0000 #42: Finalize the link-extensions to define Comment(by zach@…): This ticket was discussed in Beijing and on the mailing list ticket thread. Summary: - "sh" should be dropped, also because it does not work with RFC5988. - "obs" and "sz" were found to be useful, and should be added. - "n" should be more clearly defined for use only as a semantic name, and not as a user readable title. "title" should be recommended for such use. Also clarify that this is not to hold a link to some document (URL), but may include a URI or URN. - "d" should be more clearly defined for use as a interface description identifier. It is not to be used as a link to a document to be fetched (URL), but rather as a URI or URN. - "id" is being considered for removal. It is currently not clear if there is enough interest for using it for indicating a universal indentifier (e.g. UUID or XRI) for the resource. In Beijing the idea of using it as a local index was suggested. -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: enhancement | Status: new Priority: major | Milestone: Component: link-format | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From trac@tools.ietf.org Wed Nov 24 01:59:20 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2388128C0E5 for ; Wed, 24 Nov 2010 01:59:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.521 X-Spam-Level: X-Spam-Status: No, score=-102.521 tagged_above=-999 required=5 tests=[AWL=-0.073, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WvHEO+eNsjxp for ; Wed, 24 Nov 2010 01:59:19 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 7D8D93A6A22 for ; Wed, 24 Nov 2010 01:59:19 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PLC9D-00035e-1q; Wed, 24 Nov 2010 02:00:19 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Wed, 24 Nov 2010 10:00:19 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/84 Message-ID: <057.ae02b52e4b00896632b3e313777acfc7@tools.ietf.org> X-Trac-Ticket-ID: 84 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] link-format #84 (new): UTF-8 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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 Nov 2010 09:59:20 -0000 #84: UTF-8 Martin Thomson suggested that it might be useful to use UTF-8 for the link format instead of US-ASCII. The cost associated with this is for clients to be able to ignore the high bit being set. Note: this would require CoAP Uri-* options to be in UTF-8 as well in order to be able to query for link format parameters in the query string. To be considered in a separate CoAP ticket. -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: enhancement | Status: new Priority: minor | Milestone: Component: link-format | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From Gerald.Paprocki@us.elster.com Wed Nov 24 02:00:37 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 104483A6A24 for ; Wed, 24 Nov 2010 02:00:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fe1Qj2T0fVqz for ; Wed, 24 Nov 2010 02:00:36 -0800 (PST) Received: from mail44.messagelabs.com (mail44.messagelabs.com [216.82.249.179]) by core3.amsl.com (Postfix) with SMTP id 419483A6A22 for ; Wed, 24 Nov 2010 02:00:36 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: Gerald.Paprocki@us.elster.com X-Msg-Ref: server-3.tower-44.messagelabs.com!1290592892!43078935!3 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [206.182.155.20] Received: (qmail 19366 invoked from network); 24 Nov 2010 10:01:35 -0000 Received: from unknown (HELO us-smtp01.smtp.elster.com) (206.182.155.20) by server-3.tower-44.messagelabs.com with SMTP; 24 Nov 2010 10:01:35 -0000 Auto-Submitted: auto-generated From: Gerald.Paprocki@us.elster.com To: core@ietf.org Message-ID: Date: Wed, 24 Nov 2010 05:01:55 -0500 X-MIMETrack: Serialize by Router on US-SMTP01.domino.elster-group.com/RIM-TEMP(Release 8.5.1|September 28, 2009) at 11/24/2010 04:55:29 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [core] AUTO: Gerald Paprocki is out of the office (returning 11/29/2010) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 10:00:37 -0000 I am out of the office until 11/29/2010. I will be out of the office starting Wednesday 11/24 and returning to the office Monday 11/29. While I am away I will have limited access to my email and phone messages. Note: This is an automated response to your message "core Digest, Vol 10, Issue 72" sent on 11/24/2010 4:59:21 AM. This is the only notification you will receive while this person is away. From trac@tools.ietf.org Wed Nov 24 02:06:42 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95E0E28C120 for ; Wed, 24 Nov 2010 02:06:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZ5KyEBcM7Mp for ; Wed, 24 Nov 2010 02:06:41 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id CA2C03A6830 for ; Wed, 24 Nov 2010 02:06:41 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PLCGI-00065R-9Z; Wed, 24 Nov 2010 02:07:38 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: pab@peoplepowerco.com, zach@sensinode.com X-Trac-Project: core Date: Wed, 24 Nov 2010 10:07:37 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/85 Message-ID: <057.255be90258c8ddd82a23283f036d6cf6@tools.ietf.org> X-Trac-Ticket-ID: 85 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: pab@peoplepowerco.com, zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] link-format #85 (new): Context and default relation type X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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 Nov 2010 10:06:42 -0000 #85: Context and default relation type Peter brought up two points that need to be improved in Section 2.1 and 2.2 of the document in http://www.ietf.org/mail- archive/web/core/current/msg01214.html * The Context of the link relation should be better explained in Section 2.1. Technically, the context of the list items is the resource which is the server itself ("coap://authority"). * Currently Section 2.2 defines use of the RFC5988 relation type "service" to indicate that /.well-known/core links are services of the server. This overloading of that relation might cause confusion. It was suggested instead that a new relation "hosts" (name TBD) should be defined. This relation describes that the link is hosted by the server. -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: pab@… Type: enhancement | Status: new Priority: major | Milestone: Component: link-format | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From zach@sensinode.com Wed Nov 24 04:50:59 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1D7228C1F3 for ; Wed, 24 Nov 2010 04:50:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.478 X-Spam-Level: X-Spam-Status: No, score=-3.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n93KNraHD-q0 for ; Wed, 24 Nov 2010 04:50:57 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 83CA328C1EF for ; Wed, 24 Nov 2010 04:50:56 -0800 (PST) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id oAOCpqa1026159 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 24 Nov 2010 14:51:52 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-205-910785147; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: Date: Wed, 24 Nov 2010 14:51:53 +0200 Message-Id: References: <708E8D43-2BE9-4983-9C75-B245062FF3BF@sensinode.com> To: Peter Bigot X-Mailer: Apple Mail (2.1081) Cc: Mark Nottingham , "core Environments\) WG" Subject: Re: [core] Link Format document X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 12:50:59 -0000 --Apple-Mail-205-910785147 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Nov 22, 2010, at 5:39 PM, Peter Bigot wrote: > =95 The document shall not define a link-param which expresses a = relation to a resource that will be accessed. That's what link = descriptions are for, not link parameters. I don't see any link = parameters in RFC5988 where the value is a resource (URI), except for = extensions where the value serves purely as an identifier. None of the link-params were ever meant to contain a URL that is = accessed (with the exception of sh, but we are removing that). I think = you misunderstood what is meant by URI in d and n, those are purely = identifiers in the examples. I will clarify that point in = link-format-02. =20 In general, the philosophy in the CoRE Link Format draft should be that = all the metadata needed to access a hosted resource is available in its = link entry, without requiring a client to traverse other links or make = further requests to find out. In other words, the "hosts" relation must = be self describing. I agree that it should be possible to include other = relations about a resource or the server. =20 > =95 The approach for CoAP shall define a mechanism by which a = set of link relations can be obtained for a specific URI on a server. > I don't think either of these are onerous, and I believe they help = preserve consistency with what the concept means to the rest of the = world. Let's start with the first by reviewing the link extensions = currently listed in the draft: I have updated ticket #42 on this. I'll address your comments below as = well.=20 > =95 d -- Should be removed. I think this is what the "service" = registered relation means. I believe it will be used rarely anyway. I think you misunderstood what this is for. In REST interfaces between = machines, it is often useful to be able to identify what kind of REST = interface this is, in order to be able to use the resource. This is = usually an identifier (URI) or URN, and it is pretty critical for REST = to work properly in an M2M environment.=20 > =95 sh -- There's a proposal to remove this. That's fine with = me; when I want its function I'll use the "alternate" or "self" = relations. I agree, we should recommend "alternate" if someone want to do this. So = far it seems URLs are short enough from interop events.=20 > =95 n -- I'm ok with describing this as a semantic identifier, = and even allowing that identifier to be spelled the same way as a URL, = as long as we make clear that the value is not intended to be used as a = URL (a URN would be appropriate). This is what's done in section 4.2 of = RFC5988 which specifies that URIs in extension relations should not be = accessed. If a URI is to be used with the expectation that an = implementation will attempt to access it, the "describedby" registered = relation should be used. Yep, it was always the intention of a URI in n to be an identifier. We = can reference section 4.2 of RFC5988 to clarify that. =20 > =95 ct -- Not a relation, fine as an extension. It's just a = different encoding of the media link parameter. > =95 id -- Not a relation, fine as an extension (but see my = response in the other thread). The ticket is considering removing this if we can't find enough interest = in using it.=20 > So we end up with CoAP adding three link extensions: n, ct, and id, = none of which describe relations to resources. Three potential = relations to resources survive (service, alternate, describedby) but = none seem critical for M2M, so there's no requirement for any specific = implementation to support them. http://trac.tools.ietf.org/wg/core/trac/ticket/42 proposes keeping d, n = and ct. There is a question about id. In addition in Beijing we decided = to add "obs" and "sz". None of these are relations, so I think we are in = good shape here. Mostly editorial work needed to make their use clear. > For the second, we: > =95 Stipulate that the URI coap://authority/ refers to a = resource which is the entire server. Agreed, http://trac.tools.ietf.org/wg/core/trac/ticket/85 > =95 Define and register a new link relation "hosts" indicating a = resource that can be located at the target URI. ("hosts" is not = necessarily the right name for this relation; we should discuss this = after reviewing the existing relations.) It is to these relations that = the CoAP-added link parameters will be attached. Agreed, http://trac.tools.ietf.org/wg/core/trac/ticket/85 > =95 Define that a GET on a URI = coap://authority/.well-known/core/ provides a link description = document for context coap://authority/and default relation = "hosts". > If this is done, then the existing practice of retrieving a list of = resources available on the server by retrieving = coap://authority/.well-known/core is preserved without change. A system = with a need to provide relations between resources can do so by = accepting other URIs prefixed with coap://authority/.well-known/core, = but nobody is obliged to do so. This needs more thought and discussion first. I do agree that it should = be possible to include further link relations about hosted resources (or = about the server itself!) as this is what RFC5988 is for. I also agree = that we can not require constrained nodes to provide or understand such = relations.=20 However, there are multiple ways to so this. In addition, we would need = to think carefully before reserving the whole = /.well-known/core/ for this purpose.=20 - Currently link-format specifies that /.well-known/core/ may = be used for organizing link entries as the server sees fit. It gives an = example of using the "section" relation to do that. With your proposal = this would not be possible. Is it an issue to have to include all links = about coap://authority in /.well-known/core? This might become quite = long, although filtering helps. You and others have also suggested other = uses of the /.well-known/core/ path.=20 - How does a client know that /.well-known/core/ is available = in the first place? That is a pretty big space, do you just do it by = trial and error? Obviously not all hosted resources would have further = link relations (or only in homogeneous applications).=20 - Use of the "anchor=3D" link-parameter would be another way to achieve = this. This way you immediately know the further link relations without = having to make more requests, and you don't need to define what = /.well-known/core/ has to be used for. This is actually what = link-format-01 assumes people would do. ; rel=3D"hosts", ; rel=3D"alternate"; anchor=3D"/sensors/temperature" Another useful relation would be to use "describedby" in order to point = to a resource that describes the server itself. This is very easy in = /.well-known/core and doesn't require anything new to link-format-01. ; rel=3D"describedby" > You could do this with relations, however I don't think anybody really = wants to do this. >=20 > This is the sort of claim I don't find convincing. =20 What I meant is that nobody in M2M would want to require a client to = make multiple requests in order to find out basic metadata about a = hosted resource such as the interface description identifier or semantic = name. I didn't disagree that people should be able to make further = relations, but we can't require that. Now I think we both agree about = that.=20 > First, there are already situations where I do indeed want to do this: = my own approach to observation would benefit from being able to use the = "monitor" and "monitor-group" registered relations derived from RFC5989. = Second, if allowing this does not impact implementations that choose = not to use it, but ruling it out prevents use of CoAP to solve = somebody's problem (which I think would be the case), I believe it = should be allowed. Not sure I understand what you want to do there. Could it be done using = the "anchor" proposal above just as well?=20 In general I think we need to collect more real M2M examples of how = these further relations can be used. So far we have: - Providing an alternate URL to access a resource. - Pointing to a resource that describes the server itself. - You monitoring case, a more complete example would be helpful. - Others? Zach >=20 > How does all that fly? >=20 > Peter >=20 > On Mon, Nov 22, 2010 at 6:21 AM, Zach Shelby = wrote: > Peter, >=20 > I also agree that we don't quite have the ideal use of the link = relation concept yet, but are getting there. Consider that the first = version of the CoRE link format didn't use the relation concept at all, = in the last couple versions we have gotten much closer. But just because = we are re-using the link format from RFC5988, does not mean we are bound = to use exactly the same link relation semantics that were designed for = hypertext HTTP servers (nor does that necessarily even make sense). = However, I do find the link relation work done in RFC5988 to be useful = also in our domain to some extent, so we should try to apply what we can = to M2M. >=20 > I wouldn't go quite as far as Peter's idea below though. For M2M these = descriptions need to be as compact as possible, nor can we expect = constrained device to traverse many links to find out simple information = about a resource. I do think we should improve the way we use rel=3D"" = for example, and the use of link-extensions can use improvement too. >=20 > On a related note, I also received really helpful feedback from Martin = Thomson on this same subject in Beijing. I will CC the list with some of = that discussion pretty soon. He has good ideas for improving the use of = rel=3D and how our link-extensions should be used. >=20 > See some comments in-line: >=20 > On Nov 21, 2010, at 6:55 PM, Peter Bigot wrote: >=20 > > Either at the IETF session or in some email I can't easily find, = there was a specific question raised about exactly how the link = description is supposed to be used in CoAP that started me down a path = that led to the following comment. I've cc'd Mark Nottingham, author of = RFC5988 "Web Linking", in hopes he might have time to provide relevant = information to guide us. > > > > My understanding of RFC5988 is it proposes a way to provide, in an = HTTP response header, information about (target) resources that are = related in (rel) some way to the (context) resource identified in the = original request. Other contexts can be specified through the anchor = parameter, but I expect this is unusual. >=20 > Yes, this is the basic concept of RFC5988. I agree that anchor will be = rare, as we point out in Section 2.1 of core-link-format-01. >=20 > > > > In CoAP's link format document at = http://tools.ietf.org/html/draft-ietf-core-link-format, we are rather = mis-using this to provide a list of resources that are hosted on a = server. Technically, the context of the list items is the resource = which is the server itself ("coap://authority"), though we provide = access to it at "coap://authority/.well-known/core". >=20 > I wouldn't say we are misusing it, but that we are defining what the = context is by default. Section 2.1 explains that the CoRE link entries = are describing links to resources hosted on the server. The rel=3D = relation is defined to be "service" by default in Section 2.2 to = describe that the link is a service of the server. I do like your idea = here of explaining that the context is the URI coap://authority. >=20 > > The problem is that, because the document containing links lists the = resources available on the server, we provide additional information = about specific resources in link parameters, rather than as link = descriptions. I now think that the roles served by the "d" and "sh" = extensions, and some uses of "n", should really be link descriptions = whose context is the target, target is the extension value, and rel is = the extension name. For example, rather than: >=20 > Link parameters are meant to provide further information about the = link. This is the purpose of the link-extensions defined in the CoRE = link format. In that way they are similar to the link-parameters defined = in RFC5988. >=20 > > = n=3D"http://sweet.jpl.nasa.gov/2.0/phys.owl#Temperatu= re",sh=3D"/l"; >=20 > I do see what you are getting at here, however in Beijing we basically = decided to remove the Short URL "sh" parameter anyways. Furthermore, I = don't consider the way you are thinking about the Name "n" is quite = right. This is not meant to be a link (URL) to some document, but = instead is meant to be a semantic name or URI used as a semantic name. >=20 > > being one of the link descriptions at = coap://authority/.well-known/core, use consistent with RFC5988 would be = to provide: > > > > = rel=3D"describedby"; > > rel=3D"alternate"; >=20 > You could do this, however it would be both inefficient and complex. I = think we can avoid this by using Name properly. Let's get back to that = in a separate mail with Marin's suggestions. >=20 > > > > as the set of link descriptions for = coap://authority/sensors/temperature. > > > > Based on this perspective, and despite the fact that I've been added = as an author due to my contributions to disambiguating the syntax, I = don't think that CoRE Link Format describes a conceptually clean = solution to this problem that is compatible with what link descriptions = mean in RFC5988. > > > > I believe a conceptually clean and compatible solution would be to = have coap://authority/.well-known/core return a list of links like: > > > > rel=3D"hosts"; > > rel=3D"hosts"; > > > > to indicate that these are resources hosted on the server. >=20 > Now I like this idea. I tried to use "service" to indicate this, but = would be happy with defining a new "hosts" relation for this purpose. = What do others think? >=20 > That does not stop you from including the needed link-parameter = meta-data with this link description. For example title=3D"Title Name", = n=3D"SemanticName", ct=3D1, id=3D3 etc. >=20 > > > > Further, define that coap://authority/.well-known/core/ = provides a link description document for context = coap://authority/. For example, = coap://authority/.well-known/core/sensors/temperature would return: > > > > = rel=3D"describedby"; > > rel=3D"alternate"; >=20 > You could do this with relations, however I don't think anybody really = wants to do this. >=20 > So as I summary I do propose that we consider creating the new "hosts" = relation and better explaining that our context is coap://authority. We = should also better define how we should use our link-extensions. We = might consider giving some example of more creative use of deeper sets = of relations about a resource, but this is something that I definitely = would not require from a constrained node. Peter, how about I make a = ticket on this? >=20 > Zach >=20 > > > > Thus providing in a single document the same sort of thing that = would be provided by a set of Link headers in an HTTP request to the = context URI. Note that what I called "further" is really the only case: = returning the list of hosted resources falls out as a consequence of = applying this rule with an empty . Very simple, very = orthogonal, only difference from HTTP is the URI used to obtain the link = descriptions and their encoding as a document rather than as header Link = fields. > > > > (I can't tell from RFC5988 what the "index" relation is intended to = do, so perhaps it could be used instead of the newly created "hosts" = relation.) > > > > I don't propose that CoAP actually implement this change, since I = don't think such a proposal would be accepted due to non-technical = pressures. But I did feel it necessary to raise the possibility, and to = ask for an outside perspective so we don't end up sending IESG something = that's completely at odds with how the concept we're borrowing is = understood and used by the rest of the Internet community. > > > > Peter > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core >=20 > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 >=20 >=20 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 --Apple-Mail-205-910785147 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9 fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb 6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja 5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I 2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTEyNDEyNTE1 NFowIwYJKoZIhvcNAQkEMRYEFM1q4RKvAnBGQN21Dy/+sSO483juMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAHNNHtBVIk5enpE+Ql8kVJQezIkCAUfIG6vd4TE3Y4in3MaYJvASxvKh DnX4vHzwoaXziEnT9NNCUeO5hNoPVnv3Gp+jkL0WPFNyPZIpUR08G0xXDzHCxFlsORj9hBG0d2Fi NSNq/d7Rt56L5mcJRT+7bBjSCJtdbTlAw+wBJRjBxvB4GTH+9P6ykG3anRhSHaiwyh8/YCUogKB7 HNzjGalCPOk1YpY6yZ/uZGdBU3sER0bqXt0WDHQh/aggOYFl0+L35sq9G15klQ5M+wh5FMd72D3X Vfac1F9k/I61pJhj34GIHpzHSCKFSL3qdiCXskwgZWy4UKQTW/FWDP1VkoIAAAAAAAA= --Apple-Mail-205-910785147-- From cabo@tzi.org Wed Nov 24 06:49:26 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20DE928C267 for ; Wed, 24 Nov 2010 06:49:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPrDz5+Iqe8Y for ; Wed, 24 Nov 2010 06:49:25 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 0F4E028C25C for ; Wed, 24 Nov 2010 06:49:22 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id oAOEoKbT007991 for ; Wed, 24 Nov 2010 15:50:21 +0100 (CET) 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 A288DED9; Wed, 24 Nov 2010 15:50:20 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/mixed; boundary=Apple-Mail-35-917891435 From: Carsten Bormann In-Reply-To: <7925360F-9E9E-41F8-8053-9AF6F244C7A9@tzi.org> Date: Wed, 24 Nov 2010 15:50:20 +0100 Message-Id: <9AD87A9C-6C4F-4627-968F-AB71140B7294@tzi.org> References: <7925360F-9E9E-41F8-8053-9AF6F244C7A9@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.1082) Cc: Constrained RESTful Environments WG Subject: Re: [core] CoRE WG webex call on Nov 24, 1500 UTC X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 14:49:26 -0000 --Apple-Mail-35-917891435 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Here are the (consolidated) slides that we'll use in 10 minutes. Gruesse, Carsten On Nov 21, 2010, at 09:16, Carsten Bormann wrote: > This is a reminder that our next WG webex call is this Wednesday, Nov = 24. > As we decided to stick with a constant UTC time despite various DST = switches, > the time for the call is: >=20 > 0700 PST =3D 1000 EST =3D 1500 UTC =3D 1600 CET =3D=20 > 1700 EET =3D 2300 China =3D 2400 Japan/Korea >=20 > I expect us to spend most of the time on the open tickets (we have now = and we might create until then) on the WG documents. Where possible, = I'd like the authors to append proposed resolutions to the tickets, so = we can quickly tick off those tickets where we have agreement. --Apple-Mail-35-917891435 Content-Disposition: inline; filename=IETF79-core-interim-v1.pdf Content-Type: application/pdf; name="IETF79-core-interim-v1.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjMKJcTl8uXrp/Og0MTGCjQgMCBvYmoKPDwgL0xlbmd0aCA1IDAgUiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PgpzdHJlYW0KeAGtVk1PG0EMve+v8HEjlcnM7OxkghBCRFAJtQealTiUHmia 0KB8lCQUtb++3vHYu+QDgVSBhNmxPfbze959hGt4BI0/PauhdBpWY7iBBXQHawOjNRhYj7bPJ6CV h2ntY8nHgMn2+sXQeDLFe0z898iAs/XvaA7nFZiQngboKQvWZNUcupdGafSvJvAV8p8dONLKQL7Z /GLzuNv1bM/YWLLx3MEabZbf8QOJE0Mt+GzMxqYD36C6gosqwiLlWueh8Fmq16V6HTin+toWJZge xKJtq+gRZ12uYjGQyz1nnQyrg3y6wBtjY3LEvtP5B7CcQbNh2JAnR3UqRAZP6mqiQVgdpdSSxR3o rgwFFBqnkdXTaHWnsDFPjRXcWH1R9UAIEXUKjK3JY02bPDZD8tS80pFAkS8tAhDXCFCXrsS/xqvQ dyXeiwkjok7pjGkwiN0jbksaHVprfrRh4O6mCW3xQWwj2j86GSKDQfCFoy6GbFWTJzaRTeR2ISl+ c1K8xYQ6B5aQss05v3hvpCo4APmB9q3XKhShj3xKKsD2RQU3H7mw2xzJFWusuUUFcRW3nfad9YgK j0Pw1oENIWvkHaV7eEIYhf77NGqs6+OhJp2WrQplQCRYhIn0hwYCSOCv1sftAlucoBuTytBZa22h Gr1cEHS5S3rzfHkOg6fZbLyAq/FiMV3cr+GkkzFPd+7Y7cp4r3xZ4lrazozrZzJLekWKRNQnkz/c zlk0UIAkd+o0OgkJ5AS3E55kuUpptg4gn7eRMSqEvncBnmnRDoZJT8NBe5U2qDU9BOWM78McChSU LXwBLj2awfDlajs05iayR3NuoD5FVr8D2p6imfUKVHTWvZREiCxmilgJcYQvyGvii8C4oR2JCKPQ Io4cfc6+BDDkEoyAUhbJS7GcgyvI8hMZhrh+T8VxVhn15i+vA54ku6x4Kdyn2NP2RN/AQwbL6D3y +iyliZrozdfWFzZILWMJZEBi7yd+INHr+PrB6NcluSsXKdNus6M1VB6PINuglCqTiSZos3pNRELI yWayi3HT4N63daOI7a8LIqIpaybiJ0Z7dV0Jtjh2wk2MMU919SacMPqV1WVCmqzoIAcYLVfY8TtE VZbKuIAvzJ1sOAAh6kNCs91bhJepLTCjYsqy2Uz/dwxNsYYXk+kb1bP4dWFCekab6fofxXohQQpl bmRzdHJlYW0KZW5kb2JqCjUgMCBvYmoKODg5CmVuZG9iagoyIDAgb2JqCjw8IC9UeXBlIC9QYWdl IC9QYXJlbnQgMyAwIFIgL1Jlc291cmNlcyA2IDAgUiAvQ29udGVudHMgNCAwIFIgL01lZGlhQm94 IFswIDAgNzIwIDU0MF0KL0Fubm90cyAxNiAwIFIgPj4KZW5kb2JqCjYgMCBvYmoKPDwgL1Byb2NT ZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUiAvQ3MyIDggMCBSID4+ IC9Gb250IDw8Ci9GNS4wIDEzIDAgUiAvRjYuMCAxNCAwIFIgL0Y0LjAgMTIgMCBSIC9GMy4wIDEx IDAgUiAvRjIuMCAxMCAwIFIgL0YxLjAgOSAwIFIKPj4gPj4KZW5kb2JqCjE2IDAgb2JqClsgMTcg MCBSIDE4IDAgUiAxOSAwIFIgMjAgMCBSIF0KZW5kb2JqCjIxIDAgb2JqCjw8IC9MZW5ndGggMjIg MCBSIC9OIDEgL0FsdGVybmF0ZSAvRGV2aWNlR3JheSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+Pgpz dHJlYW0KeAGFUk9IFFEc/s02EoSIQYV4iHcKCZUprKyg2nZ1WZVtW5XSohhn37qjszPTm9k1xZME XaI8dQ+iY3Ts0KGbl6LArEvXIKkgCDx16PvN7OoohG95O9/7/f1+33tEbZ2m7zspQVRzQ5Urpadu Tk2Lgx8pRR3UTlimFfjpYnGMseu5kr+719Zn0tiy3se1dvv2PbWVZWAh6i22txD6IZFmAB+Znyhl gLPAHZav2D4BPFgOrBrwI6IDD5q5MNPRnHSlsi2RU+aiKCqvYjtJrvv5uca+i7WJg/5cj2bWjr2z 6qrRTNS090ShvA+uRBnPX1T2bDUUpw3jnEhDGinyrtXfK0zHEZErEEoGUjVkuZ9qTp114HUYu126 k+P49hClPslgqIm16bKZHYV9AHYqy+wQ8AXo8bJiD+eBe2H/W1HDk8AnYT9kh3nWrR/2F65T4HuE PTXgzhSuxfHaih9eLQFD91QjaIxzTcTT1zlzpIjvMdQZmPdGOaYLMXeWqhM3gDthH1mqZgqxXfuu 6iXuewJ30+M70Zs5C1ygHElysRXZFNA8CVgUfYuwSQ48Ps4eVeB3qJjAHLmJ3M0o9x7VERtno1KB VnqNV8ZP47nxxfhlbBjPgH6sdtd7fP/p4xV117Y+PPmNetw5rr2dG1VhVnFlC93/xzKEj9knOabB 06FZWGvYduQPmsxMsAwoxH8FPpf6khNV3NXu7bhFEsxQPixsJbpLVG4p1Oo9g0qsHCvYAHZwksQs Why4U2u6OXh32CJ6bflNV7Lrhv769nr72vIebcqoKSgTzbNEZpSxW6Pk3Xjb/WaREZ84Or7nvYpa yf5JRRA/hTlaKvIUVfRWUNbEb2cOfhu2flw/pef1Qf08CT2tn9Gv6KMRvgx0Sc/Cc1Efo0nwsGkh 4hKgioMz1E5UY40D4inx8rRbZJH9D0AZ/WYKZW5kc3RyZWFtCmVuZG9iagoyMiAwIG9iago3MDQK ZW5kb2JqCjcgMCBvYmoKWyAvSUNDQmFzZWQgMjEgMCBSIF0KZW5kb2JqCjIzIDAgb2JqCjw8IC9M ZW5ndGggMjQgMCBSIC9OIDMgL0FsdGVybmF0ZSAvRGV2aWNlUkdCIC9GaWx0ZXIgL0ZsYXRlRGVj b2RlID4+CnN0cmVhbQp4AYVUz2sTQRT+Nm6p0CIIWmsOsniQIklZq2hF1Db9EWJrDNsftkWQZDNJ 1m426+4mtaWI5OLRKt5F7aEH/4AeevBkL0qFWkUo3qsoYqEXLfHNbky2perAzn7z3jfvfW923wAN ctI09YAE5A3HUqIRaWx8Qmr8iACOoglBNCVV2+xOJAZBg3P5e+fYeg+BW1bDe/t3snetmtK2mgeE /UDgR5rZKrDvF3EKWRICiDzfoSnHdAjf49jy7I85Tnl4wbUPKz3EWSJ8QDUtzn9NuFPNJdNAg0g4 lPVxUj6c14uU1x0HaW5mxsgQvU+QprvM7qtioZxO9g6QvZ30fk6z3j7CIcILGa0/RriNnvWM1T/i YeGk5sSGPRwYNfT4YBW3Gqn4NcIUXxBNJ6JUcdkuDfGYrv1W8kqCcJA4ymRhgHNaSE/XTG74uocF fSbXE6/id1ZR4XmPE2fe1N3vRdoCrzAOHQwaDJoNSFAQRQRhmLBQQIY8GjE0snI/I6sGG5N7MnUk art0YkSxQXs23D23UaTdPP4oInGUQ7UIkvxB/iqvyU/lefnLXLDYVveUrZuauvLgO8XlmbkaHtfT yONzTV58ldR2k1dHlqx5erya7Bo/7FeXMeaCNY/Ec7D78S1flcyXKYwUxeNV8+pLhHVaMTffn2x/ Oz3iLs8utdZzrYmLN1abl2f9akj77qq8k+ZV+U9e9fH8Z83EY+IpMSZ2iuchiZfFLvGS2EurC+Jg bccInZWGKdJtkfok1WBgmrz1L10/W3i9Rn8M9VGUGczSVIn3f8IqZDSduQ5v+o/bx/wX5PeK558o Ai9s4MiZum1Tce8QoWWlbnOuAhe/0X3wtm5ro344/ARYPKsWrVI1nyC8ARx2h3oe6CmY05aWzTlS hyyfk7rpymJSzFDbQ1JS1yXXZUsWs5lVYul22JnTHW4coTlC98SnSmWT+q/xEbD9sFL5+axS2X5O GtaBl/pvwLz9RQplbmRzdHJlYW0KZW5kb2JqCjI0IDAgb2JqCjczNwplbmRvYmoKOCAwIG9iagpb IC9JQ0NCYXNlZCAyMyAwIFIgXQplbmRvYmoKMjYgMCBvYmoKPDwgL0xlbmd0aCAyNyAwIFIgL0Zp bHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBpVbbbhMxEH33Vww8OVKzsb3ezYYn1IpKICFR iNQHygOEBgL0mgXE3zO+nIlzWdQKtdW6tudyzhzbc0dndEeGf6bOUOMN3V/SOV3T5GRtabEmS+vF 7vqSTNXSKuxxaY8lqw7ui6ZxZcVxbPx3bMm78Lu4ouM52S7PdjStHDmr5lc0ObWV4f3zJb0n/XVE Y1NZ0n1/i+GzyaTF+AcGNxj8HnGOTumPmBA7GVTXWLvEoB/RB5q/ohfzSIuk63xLdatyvj7n68n7 amZc3ZCdUkzaFUkv4PXmPiZDWuI8HynOjvTqmiNGYLKEvaurI3LwYDCwGMjMOLhiZnglZBMHiatx di1e/AC6pqupNlwNFapRoKsYWJuA1QCm2d38W2IoSIcNvXHUti3NSvE4xeIJujJRQFEvhQCC2QwK qNvEKH/ruqYmk+lzTKVpJ2ZL1nQc01DtfKHYqMbAbPrrDoduydecXhQfm4cUx/yN4msrrqf3CfSU iY0S1E82CQimEs2Ay9oHQWcK2bUI+nzEsg8KSHXnAUOMkkiCZeWuY6l5RQY/85YrrOwZs7ajE1ng 88ATSmOBD8r2BoTlE1aGJ/1rIIjSrFAWWJl7zpn05+wFXnu4lYSwknYWzsTHsmfAm1MYIqW/WM09 0vMlslPHGes11DFdJY+s477LWMdZnbyVdXwtwGTQrzIJfL1Emr7kr9QxcVBUWGyF2iH2+QZMJS0F o1I5QL7YCqXIJN1IZeW2y8EXUr6YlkugEBuoDxLqYYudgi8PlIaJ4JMtsP2UufkDTWFBNC7n4Tu2 IB5QgV823cjmATqJRbV4bsqqwiOoxhcMI0ngE1iXo1wL7IDlEhNLKYoQK+yMpbZj3pY97W+DK1lB EOFMBilBpUEVqBNTyUZUC2cwYWwbVlnP8eEy1WMOo+26eBr3L1WFl2T4Uh04jOwzuUPdFLcJx5CI UAquBGfqCyj3BXwU5MgVNulxBhNSu+Hb7GWW8Zu3yACBb/OBkjAoAfiVUmBh8KpeQxJHORpiCDjx JQNgkPCQMA460oDk4VOkiAlBdpqjn2ygJr5qTMwwmGLAM85wNxFeuY2aDp3R0IIUd3l6QNGEoNah JRTQQABkSBgIw3OSLkis4NiCaViKy160kNWvYkM43CmnviN2EtzrFrh811YudFGmmjZJyqqA96+W 4+mm5RhyuN/DOKaoafxUmo6maDqOU5vMomcGdp5wyjpdp1a7fCOEjNir8srWlfDw3ALYhnu6Q/3V /4Ftcr9Wgn23uOcTlVDyK7MFV+kLvb4YlVo8+wtXy5AjCmVuZHN0cmVhbQplbmRvYmoKMjcgMCBv YmoKOTc0CmVuZG9iagoyNSAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDMgMCBSIC9SZXNv dXJjZXMgMjggMCBSIC9Db250ZW50cyAyNiAwIFIgL01lZGlhQm94ClswIDAgNzIwIDU0MF0gPj4K ZW5kb2JqCjI4IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8 IC9DczEgNyAwIFIgL0NzMiA4IDAgUiA+PiAvRm9udCA8PAovRjIuMCAxMCAwIFIgL0YzLjAgMTEg MCBSIC9GMS4wIDkgMCBSIC9GNy4xIDMwIDAgUiAvRjUuMCAxMyAwIFIgL0Y2LjAgMTQgMCBSCi9G NC4wIDEyIDAgUiA+PiA+PgplbmRvYmoKMzMgMCBvYmoKPDwgL0xlbmd0aCAzNCAwIFIgL0ZpbHRl ciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBnVdNb9tGEL3zV0xvFFCtuUtyReXU1nU/AhRwIgE+ ND2kipW4jezGZmH03/ftxxtSoqzahQ1wtZydnX3z5s3yi7yRL1Lhb+EqaZtK7q/lSm7l7PzByuZB rDxsDt9vpTJeboKNSzZWbHHULi6Nb26wj40/51YaF/43O/luLbbLs50sjBNni/VOzn6wpoL9eiu/ SvlpJvPKWCn7/i8OX52deY4/c3DHweMMMbqifM8JXacDc8t31xz0M/lN1q/lYh1h0XBd46X2RY63 yfE20jRmWbm6FbuQGLQbBb2h17v7GIyUus83swLRSXlzix3jwfQVbW92X4ujh4oDy4HOzIMrIIM3 IZo4SFjNs2v10jxxurarpa6QjSJkY3Q6g4P5dLCaByvrmaz/SAgF6mBh3TXivRfr/Ig9rgB7ArGq yKBImBEDsK61YdNAgdonSPFsl6byrlmKr9LOjakK8uCXDORNfiLvEUegF58PER4A29+l5GJ48K4o 5V25Bcq2Cxm420kcAsGrH7MXQeaiu0Q7WL1nVnp6yw7gLfEpGH3ky3ezJ5DeO7TLSONprTMukGzp Evlbwq3kxwaRK6On7vwqx3u29yzKD4QjVcFo6WTiXmc2f+IYYBCscci2DQNDvvKNmjCmbd7a5Gcq xODjI9cwusdZkdyP3wxl50xrl21t5THpy/kqs2h1PlaQBGUoyQG8xtTetlZ20lgg2HSdLDn3WVb7 Nb2Xi8pUVQXsNzLKyuDEJSp6ZqXc3N0DAtbBMVoXw2qGgLB8axZNY58b1jgYXXqEIoR2MzCWqN8z Q5oyZFXRLo6FfiTMHVrDwthq0fxn6FklR6EPSzOOKOkk7SUCPwnisHQAsW1rs1i0k0ieaGTaqmwQ pNjOotx4CExQLvS7bWTG4WzogrpY+1xUM7RJ17VmaZFK3zqp6yK6qUwXepxpguTByHo3GFlXp83C 4WMcsPA+GFQ+uvEOBgW6a/yDi3F20IEQbdLLEbiNQHVj71F2QjO+T+kvStRhLOXUjFCPf+eJHQmi vIBiRtMeihgHqqZpTVH+friWOqyWOuAb7k/n2QC6yd1owYmf84uLFfUY8qaEnUIy5RuYgXbl6qZJ wIC4wBs3ifKr43QjtKH/jaCFBi3rKbbfEjnoL2UyCRqP4KhwqUsD9dS3McCM9aFfw3Zed51ZSLnS FIz6WfK4oSdNylXelOBwT2h9DIZwasJpsL3LIo763w+XadUWMMmiTtAZfW05cU6n3F9RumR/pekE NjrruVZj5wRwOcGAY0Vh3SJSILXTZzMgXEb2GQBHSgG9h+Ty4o0OedWQeUpHQI5yoDZNLIG58xCz ET+4/AV4PpAjBFbpNAkq3Ypx78xk6dEvImu47Y6+lAt0yieXsqDRxPc8aBIl0+0nArHOlnxeHhLj LS0vVrA5kfBpyaNUbdtqolK5QwdxrrmNCKdR1Zo6zbqFQ9oUO8oia0Hlkeftw9Uv1Q1LjaDlIw+a NpUwmiqsk4q6XI2OvNeWqU4H3MStEfIRZO6UyoGyoZvgkwvt7WgDCdDhovRUC1GOF/+D4xnqxHGt CDJjwnFySsHpVasUOOaDttdk7GFW1InmTcuByVbvdNr/Q29MGPlAJeKzV/dHYky1UpTPrRn1xQXj kEMdFIcfpCeS6fjJNr4PJPYHpQH4qIhpHWRuExqe+3QdpK9YYjUq/aQJL6uD5GyvDqKbIC/hYvXs +1CH+yXK4oT0v+SChfpwXXY2hvQ15UCpSUoSDyV8RVNcA9q2CLeBGt/DUZ2augqS9JYm49QnuaFG 6z5KW0hS/pTSKe49yYWuZp3wqSs+DR95UdF5HCq8shQrTohz6sbFfhet7eEnFMW5XUZSyjwJsh5E cfiQwyIztYpHFvstiDXKFXp34kVDby2sex6Vv3sOFDXezIiWNg4Nh7uOanhA6c2/ScnJ7wplbmRz dHJlYW0KZW5kb2JqCjM0IDAgb2JqCjE0NTIKZW5kb2JqCjMyIDAgb2JqCjw8IC9UeXBlIC9QYWdl IC9QYXJlbnQgMyAwIFIgL1Jlc291cmNlcyAzNSAwIFIgL0NvbnRlbnRzIDMzIDAgUiAvTWVkaWFC b3gKWzAgMCA3MjAgNTQwXSAvQW5ub3RzIDM3IDAgUiA+PgplbmRvYmoKMzUgMCBvYmoKPDwgL1By b2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUiAvQ3MyIDggMCBS ID4+IC9Gb250IDw8Ci9GMi4wIDEwIDAgUiAvRjMuMCAxMSAwIFIgL0YxLjAgOSAwIFIgL0Y3LjEg MzAgMCBSIC9GNS4wIDEzIDAgUiAvRjYuMCAxNCAwIFIKL0Y0LjAgMTIgMCBSID4+ID4+CmVuZG9i agozNyAwIG9iagpbIDM4IDAgUiAzOSAwIFIgXQplbmRvYmoKNDEgMCBvYmoKPDwgL0xlbmd0aCA0 MiAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBnVfJbhw3EL3zK+rYA7hbTbK3 mVNsw3GQXBx4AgHJ5KAolj1JJC+aLJ/pT8rj8qqplkYYGxLAGi7FqlevitUf5Uf5KC3+RtdK37Xy 6Y2cy42cPb+1cnkrVm4vl+tX0jaD7MMel/ZYsebBffFoXNnjHht/1lY6F/4vr+XZVuyUZycZGyfO mu21nH1rmxb7t1fyi1TvVlK3jZXqcPhAcXN2NlD+i8J7Cv+uYKMz1QUn9JwKzQ3X3lA4rORX2X4v L7YRFjXXdYP4wWR7u2xvJ13XrFvne7GjRKNdYfQltb7/FI2RSu/5ZmVgnVT7G9wYHdMl7t1fPxFH DS0FS0Fn6qAKyGAlWBOFhFWdVauW7oh3/eTFt4iGCdEovGvg2JAc83SsgpbtHwmhQB0c9FMnwzCI dUPBHmfAnkCsNjIoEqZgAM71NlwaKOCHBCnG0TV26noIfbq5a1pDHgDSiFtA1E4BQeAWZyROAIfz l5zh5guwI+5Jo6nEAb0H43zMKG/HZmr9WBoFxidy2rYG+H0fzLG16zaw5Yu0d8PUjJNz0J6oD5eV +lCWVD+Noccdb+lz4i9mfucS2K43mxidAOyA+HjEeM7smLWPxAZsx/4UG5cJgTGm55BsHAobEyth SE9DNomfmFIBjjBSxYho5PnzIqQgMI7+lldSbmDiP6rnmZTlUoEO4QjTHVuBTdTxNo/kwD7/Xq4/ yfPQ7MfGm2qGO6+oFTwK1OMVqcTgzkJHXHh9yEumOvydN98iTZEKwet6jZBXz+kTatxddTQ1OycV ziYv6f4uZH3CSmHerQoOlCUXuXU0qP14UlDv30ZL7o5zUPUEN3ymwZxIVRJAoHRH/9XdDPisTKHi Vo3RK2Y/tR4Inqr/k+BpHA/A0zU+xWIMscDp2hWS9c0o1c/ZsNdUvgs1MEViojtfBfuUXw3kkpY4 RWzOJZX0Nlry8GhmWnDDPdhrYsgky+TiIwU0NKn+oZMKHdUehblQE2D2XTMFeE1th6kl5veh/oE3 fUeBN+0qz6lMdVN9FeYW7UZ8qucCVuCVOgo4v3G87kTQ+fCiCNHm+6Afq0KZnFLVV4yLon9NQ7TO HHjByfD70CEE+H0HQuP4aTRXLmbIRSE3yw7psepiu/USckVLqgFmxcTfaIS/FPLoUtTxmcoIUU1+ E3riuywMs44C1WyZhkcTIJDartEfBTCttQ9Req4ooY6YudI/Y0Rp5A4g5Dp+EqfN4k224+MAZ92b XLaE9StYnxpRWrIcXxE2JR9fP44stDdZEx7c2vVNF5Gpj2T7DM0spWKba7wJLf9pz+EcuN3cfxQw xj5IO/nHeOrQjy5KQ8HTkdQ6ubeZLXtBtNgzEHey8YrAKy0VcEYAo/Z2y482c6y1Kxput/YyDcea uuQ4vrn0IcLjGj8scC/yE/VDBQkZkuZSccJiygwISIyUznIRAcMUStndbxz5KQd3i3AXTv0P9ojE TAplbmRzdHJlYW0KZW5kb2JqCjQyIDAgb2JqCjExMDQKZW5kb2JqCjQwIDAgb2JqCjw8IC9UeXBl IC9QYWdlIC9QYXJlbnQgMyAwIFIgL1Jlc291cmNlcyA0MyAwIFIgL0NvbnRlbnRzIDQxIDAgUiAv TWVkaWFCb3gKWzAgMCA3MjAgNTQwXSA+PgplbmRvYmoKNDMgMCBvYmoKPDwgL1Byb2NTZXQgWyAv UERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUiAvQ3MyIDggMCBSID4+IC9Gb250 IDw8Ci9GNi4wIDE0IDAgUiAvRjQuMCAxMiAwIFIgL0YzLjAgMTEgMCBSIC9GMi4wIDEwIDAgUiAv RjEuMCA5IDAgUiA+PiA+PgplbmRvYmoKNDYgMCBvYmoKPDwgL0xlbmd0aCA0NyAwIFIgL0ZpbHRl ciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBnVfJbhtHEL33V9SxCXhG0z0reUosOAmSiwMzEBDT B4exHCahHFvM8pn5pLxeXs1wGUUWJKCLvdTy6lV1z0f5Xj5Khb/eV9I2lXx6JzdyJ1fX90629+Lk fnu6fitV2cku7PFpjxNnLu6LR+PKDnZc/Fk4aXz43+7l+VrckGcH6Usv3pn1Xq6+cmWF/etbeS32 l4UUVenEHg5/UFxdXXWUf6fwgcLfC/jojX3LCT2nQnnHtXcUDgt5I+tv5cU6wqLu+qaTujPZ3yb7 20jTlMvK1624XqLTfuL0llo/fIrOiFU7XywMvBO7u4PFGJguce9u/0w8NVQUHAWdKYIqIIOV4E0U ElZFVq1ampno2qGWukI2TMjGJLoSgXUpsJqB2XYh618TQoE6OFgPjXRdJ853E/Z4A/YEYlWRQZEw EwbgXOuC0UCBukuQYux96YamhdAmy01ZGfIAkEbcAqJuCAgCtzgjcQI43HzNGW5+C3bEPWk0VjzQ u5jnOadq15dDVfdTp8D4RE5XFQC/bYM7rvDNCr58lvamG8p+8B7aE/URslIfypLqL2PqYeM9Y078 xczPXALb1bKJ2QnAdshPjRznyj6v3ZghlH7tq3LpGiddD767cAClLpWJG6bJwzIUpuT5zBiMsX4z Y7pJEIm28LRdGJATwioRGJIKiJSpvDjeTHIelBj7Uz6Rige6/iEQ1JXagFjwJdlN/QBbAV608j6O xpIkuzx/vC72WZ6H5rova7FjPvJK9sKoaqQlmlCbEx1x4dVBlw5/5s33qGPUioWdYukR5DVdRxM8 VkdXNTicTVEy/E1oC2mqIvKbxYQk056M4ptNapv7G5Nq0JRVNTpCsrHSqUcn1dEtuvwvlXEitVFk DL09xq/hatq59ZrKuFVz9JLtgVsPBE/V/0bDmscD8PQh1ThU9KjPKPiJ5OqyF/tjduwVlW8sWm2C ZEiCsU+CfTiBPdyFitgIu0rZWnQ0YkWPTsecKPTC7PsZ7AUxZJEpuRR2TcRfDFKXqPb/YcadDs11 Uw4JXtcNVVlHx4pzqL8jrt9QoKWNrTml5IuYmwv3+UNUd3iPxLucXE+gx3wam54coMLK09zngs7s GHsO+lwXUnIWt8yLor8n68dmQlAeDX8dnhA4VdRNP4f9BZqf1/sRzc0jrwzXLGchF0Ju7Eoz/FTI hZCPxC/Ib0JPfM8bwxyqxmp6tAACqd0SD6iAqnOObWRK6bGjpD6i7es5qUWLG4IgT+sjrl+ml8UF TivA4LS2LRXowfE4wveSsCn5eHFyZKPlb1y4hW/LJvFtptpHaEaJIOXOOnMdmvGuRwpOr0PtlEc8 nbsFzenTBg/WudYgtqe5i2+b9OA/hpGdQOwLosM3AzeSjbec2J5VOzOAUR9/D3zVxS82vsunFeqX tQzdw4+66UcZLtf45QG7gNnFJ1QQEFXoO0ncU0iVgcUxK4kymEIri+fyHrDrh3wtrfH6mQT1HwQN yxkKZW5kc3RyZWFtCmVuZG9iago0NyAwIG9iagoxMTE3CmVuZG9iago0NSAwIG9iago8PCAvVHlw ZSAvUGFnZSAvUGFyZW50IDMgMCBSIC9SZXNvdXJjZXMgNDggMCBSIC9Db250ZW50cyA0NiAwIFIg L01lZGlhQm94ClswIDAgNzIwIDU0MF0gPj4KZW5kb2JqCjQ4IDAgb2JqCjw8IC9Qcm9jU2V0IFsg L1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAwIFIgL0NzMiA4IDAgUiA+PiAvRm9u dCA8PAovRjYuMCAxNCAwIFIgL0Y0LjAgMTIgMCBSIC9GMy4wIDExIDAgUiAvRjIuMCAxMCAwIFIg L0YxLjAgOSAwIFIgPj4gPj4KZW5kb2JqCjUxIDAgb2JqCjw8IC9MZW5ndGggNTIgMCBSIC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AY1TTU/bQBC97694R1uqN96NN+scIUBFT4FaQir0 kLqOahEn4LiV+u87tncmJAWEfNj1vPl6b2eecYNnpPR5m8JlKdoKd9histgblHsY7MtTfI1Uz1D3 Pnb0MTDqNb/JsmrL6qn7vdqgralSX6X/jBuOssHkujG42A19HKHOOnWEj5FDGap9W21WXf2nWuw2 u7Zuqq6ty7GGGVInBtYQJatz71A26ryAyQOUw2sL6qWgBq6cpoZQrHGPaBEjSQmLdny55cslYiJO 0F2shvNz+P8UTsavw/+WI7tgqNjQ1nxrEJItf7FJWuB8lpGMLzokNDF8pg0iuvRtq4gRiUk5Jrgg Ist3FF9wWQyii1xZjsxkJBVIKhukotN5PfWpIT3n6gN6Ces9025X3IPQ3sZqlFkk+ck+xNo5PUV0 9sQmuWzYIonKFWfiagLJC0pHLOiyFYyjgkFFpUBSjMMeXpmOs+VD/K6e/Qwf62l8qudzb+D9//Mn MhxEW4fH7sKkJMJQxGMW7JocWLTi9MIooomyCU3F+CLTt+lMTaqHZRoYjfuY0BZZm+mZm9FG2XFC 8hcb9S20z5PJan6VgZcORfEfYzMq+jsMOO3c6Y6dn6a7CmUOusmzPxIjxQN/8w/d4P62CmVuZHN0 cmVhbQplbmRvYmoKNTIgMCBvYmoKNDgxCmVuZG9iago1MCAwIG9iago8PCAvVHlwZSAvUGFnZSAv UGFyZW50IDMgMCBSIC9SZXNvdXJjZXMgNTMgMCBSIC9Db250ZW50cyA1MSAwIFIgL01lZGlhQm94 ClswIDAgNzIwIDU0MF0gPj4KZW5kb2JqCjUzIDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4 dCAvSW1hZ2VCIC9JbWFnZUMgL0ltYWdlSSBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAwIFIKL0Nz MiA4IDAgUiA+PiAvRm9udCA8PCAvRjguMCA1NiAwIFIgL0Y1LjAgMTMgMCBSID4+IC9YT2JqZWN0 IDw8IC9JbTEgNTQgMCBSCj4+ID4+CmVuZG9iago1NCAwIG9iago8PCAvTGVuZ3RoIDU1IDAgUiAv VHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDcyMCAvSGVpZ2h0IDE1IC9JbnRl cnBvbGF0ZQp0cnVlIC9Db2xvclNwYWNlIDU4IDAgUiAvSW50ZW50IC9QZXJjZXB0dWFsIC9CaXRz UGVyQ29tcG9uZW50IDggL0ZpbHRlciAvRENURGVjb2RlCj4+CnN0cmVhbQr/2P/gABBKRklGAAEB AAABAAEAAP/iBUBJQ0NfUFJPRklMRQABAQAABTBhcHBsAiAAAG1udHJSR0IgWFlaIAfZAAIAGQAL ABoAC2Fjc3BBUFBMAAAAAGFwcGwAAAAAAAAAAAAAAAAAAAAAAAD21gABAAAAANMtYXBwbAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC2RzY20AAAEIAAAC8mRl c2MAAAP8AAAAb2dYWVoAAARsAAAAFHd0cHQAAASAAAAAFHJYWVoAAASUAAAAFGJYWVoAAASoAAAA FHJUUkMAAAS8AAAADmNwcnQAAATMAAAAOGNoYWQAAAUEAAAALGdUUkMAAAS8AAAADmJUUkMAAAS8 AAAADm1sdWMAAAAAAAAAEQAAAAxlblVTAAAAJgAAAn5lc0VTAAAAJgAAAYJkYURLAAAALgAAAepk ZURFAAAALAAAAahmaUZJAAAAKAAAANxmckZVAAAAKAAAASppdElUAAAAKAAAAlZubE5MAAAAKAAA AhhuYk5PAAAAJgAAAQRwdEJSAAAAJgAAAYJzdlNFAAAAJgAAAQRqYUpQAAAAGgAAAVJrb0tSAAAA FgAAAkB6aFRXAAAAFgAAAWx6aENOAAAAFgAAAdRydVJVAAAAIgAAAqRwbFBMAAAALAAAAsYAWQBs AGUAaQBuAGUAbgAgAFIARwBCAC0AcAByAG8AZgBpAGkAbABpAEcAZQBuAGUAcgBpAHMAawAgAFIA RwBCAC0AcAByAG8AZgBpAGwAUAByAG8AZgBpAGwAIABHAOkAbgDpAHIAaQBxAHUAZQAgAFIAVgBC TgCCLAAgAFIARwBCACAw1zDtMNUwoTCkMOuQGnUoACAAUgBHAEIAIIJyX2ljz4/wAFAAZQByAGYA aQBsACAAUgBHAEIAIABHAGUAbgDpAHIAaQBjAG8AQQBsAGwAZwBlAG0AZQBpAG4AZQBzACAAUgBH AEIALQBQAHIAbwBmAGkAbGZukBoAIABSAEcAQgAgY8+P8GWHTvYARwBlAG4AZQByAGUAbAAgAFIA RwBCAC0AYgBlAHMAawByAGkAdgBlAGwAcwBlAEEAbABnAGUAbQBlAGUAbgAgAFIARwBCAC0AcABy AG8AZgBpAGUAbMd8vBgAIABSAEcAQgAg1QS4XNMMx3wAUAByAG8AZgBpAGwAbwAgAFIARwBCACAA RwBlAG4AZQByAGkAYwBvAEcAZQBuAGUAcgBpAGMAIABSAEcAQgAgAFAAcgBvAGYAaQBsAGUEHgQx BEkEOAQ5ACAEPwRABD4ERAQ4BDsETAAgAFIARwBCAFUAbgBpAHcAZQByAHMAYQBsAG4AeQAgAHAA cgBvAGYAaQBsACAAUgBHAEIAAGRlc2MAAAAAAAAAFEdlbmVyaWMgUkdCIFByb2ZpbGUAAAAAAAAA AAAAABRHZW5lcmljIFJHQiBQcm9maWxlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAABYWVogAAAAAAAAWnUAAKxzAAAXNFhZWiAAAAAAAADzUgABAAAAARbP WFlaIAAAAAAAAHRNAAA97gAAA9BYWVogAAAAAAAAKBoAABWfAAC4NmN1cnYAAAAAAAAAAQHNAAB0 ZXh0AAAAAENvcHlyaWdodCAyMDA3IEFwcGxlIEluYy4sIGFsbCByaWdodHMgcmVzZXJ2ZWQuAHNm MzIAAAAAAAEMQgAABd7///MmAAAHkgAA/ZH///ui///9owAAA9wAAMBs/+EAQEV4aWYAAE1NACoA AAAIAAGHaQAEAAAAAQAAABoAAAAAAAKgAgAEAAAAAQAAAtCgAwAEAAAAAQAAAA8AAAAA/9sAQwAD AgICAgIDAgICAwMDAwQHBAQEBAQIBgYFBwoJCgoKCQkJCwwPDQsLDwwJCQ0SDg8QEBEREQoNExQT ERQPERER/9sAQwEDAwMEBAQIBAQIEQsJCxERERERERERERERERERERERERERERERERERERERERER ERERERERERERERERERERERER/8AAEQgADwLQAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A+BKKKK88/PwooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAP/ZCmVuZHN0cmVhbQplbmRv YmoKNTUgMCBvYmoKMjIyMQplbmRvYmoKNTkgMCBvYmoKPDwgL0xlbmd0aCA2MCAwIFIgL04gMyAv QWx0ZXJuYXRlIC9EZXZpY2VSR0IgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBhVTP axNBFP42bqnQIghaaw6yeJAiSVmraEXUNv0RYmsM2x+2RZBkM0nWbjbr7ia1pYjk4tEq3kXtoQf/ gB568GQvSoVaRSjeqyhioRct8c1uTLal6sDOfvPeN+99b3bfAA1y0jT1gATkDcdSohFpbHxCavyI AI6iCUE0JVXb7E4kBkGDc/l759h6D4FbVsN7+3eyd62a0raaB4T9QOBHmtkqsO8XcQpZEgKIPN+h Kcd0CN/j2PLsjzlOeXjBtQ8rPcRZInxANS3Of024U80l00CDSDiU9XFSPpzXi5TXHQdpbmbGyBC9 T5Cmu8zuq2KhnE72DpC9nfR+TrPePsIhwgsZrT9GuI2e9YzVP+Jh4aTmxIY9HBg19PhgFbcaqfg1 whRfEE0nolRx2S4N8Ziu/VbySoJwkDjKZGGAc1pIT9dMbvi6hwV9JtcTr+J3VlHheY8TZ97U3e9F 2gKvMA4dDBoMmg1IUBBFBGGYsFBAhjwaMTSycj8jqwYbk3sydSRqu3RiRLFBezbcPbdRpN08/igi cZRDtQiS/EH+Kq/JT+V5+ctcsNhW95Stm5q68uA7xeWZuRoe19PI43NNXnyV1HaTV0eWrHl6vJrs Gj/sV5cx5oI1j8RzsPvxLV+VzJcpjBTF41Xz6kuEdVoxN9+fbH87PeIuzy611nOtiYs3VpuXZ/1q SPvuqryT5lX5T1718fxnzcRj4ikxJnaK5yGJl8Uu8ZLYS6sL4mBtxwidlYYp0m2R+iTVYGCavPUv XT9beL1Gfwz1UZQZzNJUifd/wipkNJ25Dm/6j9vH/Bfk94rnnygCL2zgyJm6bVNx7xChZaVuc64C F7/RffC2bmujfjj8BFg8qxatUjWfILwBHHaHeh7oKZjTlpbNOVKHLJ+TuunKYlLMUNtDUlLXJddl SxazmVVi6XbYmdMdbhyhOUL3xKdKZZP6r/ERsP2wUvn5rFLZfk4a1oGX+m/AvP1FCmVuZHN0cmVh bQplbmRvYmoKNjAgMCBvYmoKNzM3CmVuZG9iago1OCAwIG9iagpbIC9JQ0NCYXNlZCA1OSAwIFIg XQplbmRvYmoKNjIgMCBvYmoKPDwgL0xlbmd0aCA2MyAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUg Pj4Kc3RyZWFtCngBrVfJctQwEL3rK7qKi32II9mWl2NYCwqqJjAUB+BAmQQCDJBxwvJB/A8X/oeW 5X7SjD1ZIDUHayS51f1e92v5lA7plDT/6lyTLTWtj+gFfab9O72hridDfbe9fkw6q+jE7cn9HkNG ze3bXxytu6OvZ+dvPtH6hE9yp7ifscOjW9H+w1VOd78Mfmys2tyqjXXnaVFlTW2pLBqqyobaPON/ weXBHZ3pVpu20g37meuizU2loknn6OD/KUfnnNkzYtcW2hnkY28vec6v8tPwQW3BK7ZVS/b5vs04 Bloe00tKbh+ltMcnUXIigw8ywMxnmXknA0rZKX5psf4iU1hbw2Tfp/Salo/o3pIh8hCwWy54B0IU umK2OC5dN2WR86i2VVPlDgOj24ZhGJicBj7YGSP25OwVnA7sWmG2gk1+pbT84F3xWxnLDRTnjRXl nLX/h+67APdGBj2lHDCj+lVmArpvZepcBt3ZsFsF4r4BeDF0PBoESWtZuSNmsHSwSFUg61IyroCc o6G+URom1piGaSQBh5CKwE8AMKnyed8IErLicY0KovsIYGUNVI12VQJe1heWjSdYzLyXs3GAFNaL kbkH41OcW2EnBmJs7tybYNSVoRMafpYFU2qM3i6t39corchcZbN6xhyT+lyAQSkIABIt8nZzISqH Gdp4b0jxXRnMaqt1TstORa7mpshsUTpvaRDRVkQ0uVUVIfwdRjdMVVzklgUetiDICTsIjbpIDl3D 2nEUsQAOfI1CaCxr/YbsbyihcnuvZm1Qwqk5puvZmHsqQavokJ9C0HVbzVif8jr0cmIYVQQl3ap2 laA5IW0w2Nob1T1iQRKei2hIFopzsIZ3ZEV2wsnIfd9DnzyOs/JfhTfOMF+mTbvN+1XLVPEFIsp9 X6YTc453BNPN6J8PXSU/BQtADanqw3t9j9kpmuNFQg0XiX+FKI5pgCjPm5tUsqk5hojJ9X0GQUlG oIdgRdq1x0slQHcKnBjBu6HtoAo+ydHSVADwChkdbhiha4Yeg2yW4yaW4Bl8xfEuvqC2M6Rx+ke3 u11yFiWiJ62qpnmtoJqD9l2gZ5G5Ia/zbXOKSXsqyCGqb8AOUxAkSW+hTzBVyYqXrM0KSg5ABt7/ gREK5FVysFikZJrMkOsFw21wBFQl4TYDjIP9u+Lyq/QS2MOl+hpdpND1Nuq/ol513S4yNRdKJcp7 Sbs/jEmdtZSgZgIWFzPjJVbszImwBxmZDlIm9J6N3zzIhJkLxmbO70rpqEOXus5M2fL3iq69FlVy sWBEbgmptQyMDPawhgssX0PGelOHHNUlX1O7nIsKZKi3orQ3KZJTcxznAeCHnkj2zxEdOoVwwruD 1OyKDBe7uBHkusz4e5u/oiXO6GZno5vd4V9SoE4FCmVuZHN0cmVhbQplbmRvYmoKNjMgMCBvYmoK MTA0NgplbmRvYmoKNjEgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAzIDAgUiAvUmVzb3Vy Y2VzIDY0IDAgUiAvQ29udGVudHMgNjIgMCBSIC9NZWRpYUJveApbMCAwIDcyMCA1NDBdID4+CmVu ZG9iago2NCAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgL0ltYWdlQiAvSW1hZ2VDIC9J bWFnZUkgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcgMCBSCi9DczIgOCAwIFIgPj4gL0ZvbnQgPDwg L0Y2LjAgMTQgMCBSIC9GNS4wIDEzIDAgUiAvRjkuMCA2NyAwIFIgPj4gL1hPYmplY3QKPDwgL0lt MiA2NSAwIFIgPj4gPj4KZW5kb2JqCjY1IDAgb2JqCjw8IC9MZW5ndGggNjYgMCBSIC9UeXBlIC9Y T2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNzIwIC9IZWlnaHQgMTUgL0ludGVycG9sYXRl CnRydWUgL0NvbG9yU3BhY2UgNTggMCBSIC9JbnRlbnQgL1BlcmNlcHR1YWwgL0JpdHNQZXJDb21w b25lbnQgOCAvRmlsdGVyIC9EQ1REZWNvZGUKPj4Kc3RyZWFtCv/Y/+AAEEpGSUYAAQEAAAEAAQAA /+IFQElDQ19QUk9GSUxFAAEBAAAFMGFwcGwCIAAAbW50clJHQiBYWVogB9kAAgAZAAsAGgALYWNz cEFQUEwAAAAAYXBwbAAAAAAAAAAAAAAAAAAAAAAAAPbWAAEAAAAA0y1hcHBsAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALZHNjbQAAAQgAAALyZGVzYwAAA/wA AABvZ1hZWgAABGwAAAAUd3RwdAAABIAAAAAUclhZWgAABJQAAAAUYlhZWgAABKgAAAAUclRSQwAA BLwAAAAOY3BydAAABMwAAAA4Y2hhZAAABQQAAAAsZ1RSQwAABLwAAAAOYlRSQwAABLwAAAAObWx1 YwAAAAAAAAARAAAADGVuVVMAAAAmAAACfmVzRVMAAAAmAAABgmRhREsAAAAuAAAB6mRlREUAAAAs AAABqGZpRkkAAAAoAAAA3GZyRlUAAAAoAAABKml0SVQAAAAoAAACVm5sTkwAAAAoAAACGG5iTk8A AAAmAAABBHB0QlIAAAAmAAABgnN2U0UAAAAmAAABBGphSlAAAAAaAAABUmtvS1IAAAAWAAACQHpo VFcAAAAWAAABbHpoQ04AAAAWAAAB1HJ1UlUAAAAiAAACpHBsUEwAAAAsAAACxgBZAGwAZQBpAG4A ZQBuACAAUgBHAEIALQBwAHIAbwBmAGkAaQBsAGkARwBlAG4AZQByAGkAcwBrACAAUgBHAEIALQBw AHIAbwBmAGkAbABQAHIAbwBmAGkAbAAgAEcA6QBuAOkAcgBpAHEAdQBlACAAUgBWAEJOAIIsACAA UgBHAEIAIDDXMO0w1TChMKQw65AadSgAIABSAEcAQgAggnJfaWPPj/AAUABlAHIAZgBpAGwAIABS AEcAQgAgAEcAZQBuAOkAcgBpAGMAbwBBAGwAbABnAGUAbQBlAGkAbgBlAHMAIABSAEcAQgAtAFAA cgBvAGYAaQBsZm6QGgAgAFIARwBCACBjz4/wZYdO9gBHAGUAbgBlAHIAZQBsACAAUgBHAEIALQBi AGUAcwBrAHIAaQB2AGUAbABzAGUAQQBsAGcAZQBtAGUAZQBuACAAUgBHAEIALQBwAHIAbwBmAGkA ZQBsx3y8GAAgAFIARwBCACDVBLhc0wzHfABQAHIAbwBmAGkAbABvACAAUgBHAEIAIABHAGUAbgBl AHIAaQBjAG8ARwBlAG4AZQByAGkAYwAgAFIARwBCACAAUAByAG8AZgBpAGwAZQQeBDEESQQ4BDkA IAQ/BEAEPgREBDgEOwRMACAAUgBHAEIAVQBuAGkAdwBlAHIAcwBhAGwAbgB5ACAAcAByAG8AZgBp AGwAIABSAEcAQgAAZGVzYwAAAAAAAAAUR2VuZXJpYyBSR0IgUHJvZmlsZQAAAAAAAAAAAAAAFEdl bmVyaWMgUkdCIFByb2ZpbGUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAFhZWiAAAAAAAABadQAArHMAABc0WFlaIAAAAAAAAPNSAAEAAAABFs9YWVogAAAA AAAAdE0AAD3uAAAD0FhZWiAAAAAAAAAoGgAAFZ8AALg2Y3VydgAAAAAAAAABAc0AAHRleHQAAAAA Q29weXJpZ2h0IDIwMDcgQXBwbGUgSW5jLiwgYWxsIHJpZ2h0cyByZXNlcnZlZC4Ac2YzMgAAAAAA AQxCAAAF3v//8yYAAAeSAAD9kf//+6L///2jAAAD3AAAwGz/4QBARXhpZgAATU0AKgAAAAgAAYdp AAQAAAABAAAAGgAAAAAAAqACAAQAAAABAAAC0KADAAQAAAABAAAADwAAAAD/2wBDAAMCAgICAgMC AgIDAwMDBAcEBAQEBAgGBgUHCgkKCgoJCQkLDA8NCwsPDAkJDRIODxAQERERCg0TFBMRFA8RERH/ 2wBDAQMDAwQEBAgEBAgRCwkLERERERERERERERERERERERERERERERERERERERERERERERERERER ERERERERERERERH/wAARCAAPAtADASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQF BgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS 0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4 eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi 4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl 8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImK kpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP0 9fb3+Pn6/9oADAMBAAIRAxEAPwD4Eooorzz8/CiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA/9kKZW5kc3RyZWFtCmVuZG9iago2NiAw IG9iagoyMjIxCmVuZG9iago3MCAwIG9iago8PCAvTGVuZ3RoIDcxIDAgUiAvRmlsdGVyIC9GbGF0 ZURlY29kZSA+PgpzdHJlYW0KeAGtWE1z2zYQveNX7Ewv5MEyP0SKzCXTNO1MeopbTXtocnBZu3Ub OTGZpB//x/8nP6kLAu+BImhJnmR0EASAD7v73i6WupMLuZNMP5sik2qdSX8lP8utnH8z5NINksvQ zdevJVvVcmP3FG5PLrlZ2nf+8qrvrt69/3D5RvobPcmeYj95NX51Ozl/sSvl+dvRjr3VqqjM3rq1 tKxXzaaSddlIvW6kLVb6K5g8mpOtsjbL2zpr1M4iK9sir81k0ho62n+n3lljznLgVmVmAfXYZ1vd lGVZIdtOV90+/c6bzarIq0aq1mzV+u/qlXoj22tJvqrKVLZ/yrfb0ZmD2BPEYq2ITVYSsQLiL5JI qieuCkm2OshzSd6mcqZeSfLXFUa3GOjmcemNmzBJvOV37H3v9/6RymvZfu+MdhFWX21sbYwnkTUq Bg1btmnWZaGjTVU3dWFDnGetmt+OQonjOuK4gBY+jPqtLkvRuAjS3+Q+xM/JRKnaI2kZrFwvoWn0 vk6lqmywEBl4fTyKJvkbobrEYAAMZ37DEgcMOWckVfGpDdHZQOtoDXHfAfcsw0i1ZYk3D/sCvB1h cGSnLDvVYE9/lRo3c4elDxjQhQHPW8eDSiJGbJpqvkzoHRmpWhkzhPwqIwzqDU7DGd7E4J+a6I0e GA5Gipofwq6pjVSqxn5RqZETPuknTliNthv6YFyW33+GRiM0jchP0Cgd6f8FS0EZC/72Hz3PhtJi UD8SDFC+JsjhmuCUGqmFYb/2VQOoOSg6KzDC0jPonpRTlsyjoEueEPhUl6k5tetI5XmQz7Ur3cVa a4cSmpfFvOp8egyjAa6uVpsFOKX0B8SCLATX6SgZfcKYuujvyCK3cCas/UdsBJzISr7P7Z5Mcjct mdQnd2twhcf6LSElAzl9UFgPA1guiITc1tM9lebi+CVyMpX15otSGcEplS97hvVXsBqn0i5w6GJ5 Cwb4NELBYLHcak65Kx7JRbY7P1q6yOd4eJgHkhay4Y42SUcHeBLlQe7n+PhNfKQ3WedKKNxwdqGO Ac+fbJJ/MIOHaBxt0hVWhIf7gnmGttVMJUorzqLNB7qpVwkjSFqj5OENFfSCMxjbDjMgAr/jLEUM jgdOEhoFuFfpNE6Pr5zxdT52a9r17V/np7VrMZpr1yK4/WxjQEnRcImkon4RJnjOvVggTyQBeXID MKqLW/BwuNwapD6W9HJzie5NWcrQw632QVrsu9SpVbCoQ4viX0SmF5qxjfRpcOOFFsMpLz/6YmWS 48VqqcMAP4jatW+JyReL1cCpXcQHULgFSWs0B2b97SmJE1UcCoxw1A8spyyP57lJWMFosQKHCnZQ AoucIZdCiRt7mjLT1tS+i7LTTqYSGBugJQnEcKMEYjiVwOGexvcbjBsr5oFLEyHl3p0Pk0l4NxIQ 3OMhRhT5jAVeRx42NMeRnvAosahCmkRU/7BJpo3PlyFz/6W41LfuGZf3p/Sn4DKgjWU2hlMunyNb 6Dn89L36pJxhhSFh8eWAKOz0w0NeGJj4jNbDhL8+gMb8okwCPiXEFJ7w7xrtuVRCWzDZ6sp8fBJs YM3ABJTKqKBK2ZvaV6mnR5Sj9k3+VDn1Jig35Vw6n1KDP6SO/6ESqoorA3M4o9J54e895A68DnUb MxRD3N2wY8HeR1RViarqQvUPd0d4w6SAyQJJHXbOkFArSB4sDD1t/H8JccKmp6kJdf7if+4gPiIK ZW5kc3RyZWFtCmVuZG9iago3MSAwIG9iagoxMjkyCmVuZG9iago2OSAwIG9iago8PCAvVHlwZSAv UGFnZSAvUGFyZW50IDMgMCBSIC9SZXNvdXJjZXMgNzIgMCBSIC9Db250ZW50cyA3MCAwIFIgL01l ZGlhQm94ClswIDAgNzIwIDU0MF0gPj4KZW5kb2JqCjcyIDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BE RiAvVGV4dCAvSW1hZ2VCIC9JbWFnZUMgL0ltYWdlSSBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAw IFIKL0NzMiA4IDAgUiA+PiAvRm9udCA8PCAvRjYuMCAxNCAwIFIgL0Y1LjAgMTMgMCBSID4+IC9Y T2JqZWN0IDw8IC9JbTMgNzMgMCBSCj4+ID4+CmVuZG9iago3MyAwIG9iago8PCAvTGVuZ3RoIDc0 IDAgUiAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDcyMCAvSGVpZ2h0IDE1 IC9JbnRlcnBvbGF0ZQp0cnVlIC9Db2xvclNwYWNlIDU4IDAgUiAvSW50ZW50IC9QZXJjZXB0dWFs IC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlciAvRENURGVjb2RlCj4+CnN0cmVhbQr/2P/gABBK RklGAAEBAAABAAEAAP/iBUBJQ0NfUFJPRklMRQABAQAABTBhcHBsAiAAAG1udHJSR0IgWFlaIAfZ AAIAGQALABoAC2Fjc3BBUFBMAAAAAGFwcGwAAAAAAAAAAAAAAAAAAAAAAAD21gABAAAAANMtYXBw bAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC2RzY20AAAEI AAAC8mRlc2MAAAP8AAAAb2dYWVoAAARsAAAAFHd0cHQAAASAAAAAFHJYWVoAAASUAAAAFGJYWVoA AASoAAAAFHJUUkMAAAS8AAAADmNwcnQAAATMAAAAOGNoYWQAAAUEAAAALGdUUkMAAAS8AAAADmJU UkMAAAS8AAAADm1sdWMAAAAAAAAAEQAAAAxlblVTAAAAJgAAAn5lc0VTAAAAJgAAAYJkYURLAAAA LgAAAepkZURFAAAALAAAAahmaUZJAAAAKAAAANxmckZVAAAAKAAAASppdElUAAAAKAAAAlZubE5M AAAAKAAAAhhuYk5PAAAAJgAAAQRwdEJSAAAAJgAAAYJzdlNFAAAAJgAAAQRqYUpQAAAAGgAAAVJr b0tSAAAAFgAAAkB6aFRXAAAAFgAAAWx6aENOAAAAFgAAAdRydVJVAAAAIgAAAqRwbFBMAAAALAAA AsYAWQBsAGUAaQBuAGUAbgAgAFIARwBCAC0AcAByAG8AZgBpAGkAbABpAEcAZQBuAGUAcgBpAHMA awAgAFIARwBCAC0AcAByAG8AZgBpAGwAUAByAG8AZgBpAGwAIABHAOkAbgDpAHIAaQBxAHUAZQAg AFIAVgBCTgCCLAAgAFIARwBCACAw1zDtMNUwoTCkMOuQGnUoACAAUgBHAEIAIIJyX2ljz4/wAFAA ZQByAGYAaQBsACAAUgBHAEIAIABHAGUAbgDpAHIAaQBjAG8AQQBsAGwAZwBlAG0AZQBpAG4AZQBz ACAAUgBHAEIALQBQAHIAbwBmAGkAbGZukBoAIABSAEcAQgAgY8+P8GWHTvYARwBlAG4AZQByAGUA bAAgAFIARwBCAC0AYgBlAHMAawByAGkAdgBlAGwAcwBlAEEAbABnAGUAbQBlAGUAbgAgAFIARwBC AC0AcAByAG8AZgBpAGUAbMd8vBgAIABSAEcAQgAg1QS4XNMMx3wAUAByAG8AZgBpAGwAbwAgAFIA RwBCACAARwBlAG4AZQByAGkAYwBvAEcAZQBuAGUAcgBpAGMAIABSAEcAQgAgAFAAcgBvAGYAaQBs AGUEHgQxBEkEOAQ5ACAEPwRABD4ERAQ4BDsETAAgAFIARwBCAFUAbgBpAHcAZQByAHMAYQBsAG4A eQAgAHAAcgBvAGYAaQBsACAAUgBHAEIAAGRlc2MAAAAAAAAAFEdlbmVyaWMgUkdCIFByb2ZpbGUA AAAAAAAAAAAAABRHZW5lcmljIFJHQiBQcm9maWxlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYWVogAAAAAAAAWnUAAKxzAAAXNFhZWiAAAAAAAADzUgAB AAAAARbPWFlaIAAAAAAAAHRNAAA97gAAA9BYWVogAAAAAAAAKBoAABWfAAC4NmN1cnYAAAAAAAAA AQHNAAB0ZXh0AAAAAENvcHlyaWdodCAyMDA3IEFwcGxlIEluYy4sIGFsbCByaWdodHMgcmVzZXJ2 ZWQuAHNmMzIAAAAAAAEMQgAABd7///MmAAAHkgAA/ZH///ui///9owAAA9wAAMBs/+EAQEV4aWYA AE1NACoAAAAIAAGHaQAEAAAAAQAAABoAAAAAAAKgAgAEAAAAAQAAAtCgAwAEAAAAAQAAAA8AAAAA /9sAQwADAgICAgIDAgICAwMDAwQHBAQEBAQIBgYFBwoJCgoKCQkJCwwPDQsLDwwJCQ0SDg8QEBER EQoNExQTERQPERER/9sAQwEDAwMEBAQIBAQIEQsJCxERERERERERERERERERERERERERERERERER ERERERERERERERERERERERERERERERER/8AAEQgADwLQAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEB AAAAAAAAAAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQci cRQygZGhCCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpj ZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfI ycrS09TV1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgME BQYHCAkKC//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkj M1LwFWJy0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2 d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ 2uLj5OXm5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A+BKKKK88/PwooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAP/ZCmVuZHN0cmVh bQplbmRvYmoKNzQgMCBvYmoKMjIyMQplbmRvYmoKNzggMCBvYmoKPDwgL0xlbmd0aCA3OSAwIFIg L0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngB3VdNc9xEEL3Pr+gqLtoqrJVG30cghgoH KgFV5ZBwMMoaDFYSS05i/yD+Dxf+Dy3N9JvRx3q37M2F8mHl+XjT87pfd88NvaQbiviv0BFlaUTd jl7RO9p+18fU9BRT38znLykKc7oa1mizJqZYra3bvth1ze7D7ceLa+qu+KThlOEvzsafpqXt8zal Z+9HOyazmc7UZH6wNMnDssgoTUrK05IqHfJ/zuTRnCiMqiiu8qhkO3WUVDrOlTc4GDraf8O3G4w5 iwU3S6IBkI/9tuYxM8u/OtJhlRWUVVS3avt9FvIVqL6k1xScv93QGR9EwZV83G6Gkyl4LwMdpi5k 6Np8qIDsYtmEpc1fO1ksc/2GfqX6RzqvmS/DB9s4MMGMqAUPeVSUaaLZmCLLy1wPhMRRVTIno1uX LIzMNq3i62t7ff4t+DK8uWZvuasHf2+o/tOYYpzKxE4oHY0yXDL9UaSpbnzYJPVwc6E0+KqIHfI+ QN+6IsyKqiyXJrJ3mN24HHxR80ccUwBOu/Zqo4zj3gnPcJj1jufC32XNvTisB1Rzu+EA8yMAQAzt PMZh97BH9t42NaGoU+aUD8qjuTP+cZQddAajjGHPv3kWFks05u0bRDU+5N72bioAbUzEKS45Dbgq m9/xNAEnuH7AacfeXhd41knACZSfDoSlFx1i4M6GjAo+IWS6/qMEVC9bfrCZADlCZI9dn2XPhYTu /dOoN6lOeRExxlesizn5RwUYw42pYxZgSziOMBEkaBIa3K2tPAel2hSLkMOuI5VqoVipJjUDEUCA /touEXvgDrtCBQtJOF/CVbIbBwFfZn7ZiROPsUp2ZQcczonIS/GLaLa1zU+fnE/inKvZPLurw9nd ou3P7gaYK6avtuQBta3YJ2oD1prcnluntS08AC/BBfCkiQLlisHWbsceoFzaGQx0HT6xmmz+d1P9 BwnZZYC5wjGp56gO7MLVer3XmU5uRr1VAm+qsU0JjlXv0Pd4yWAsD/ECjtUrfCOqe1EW2AHbHk2T vkgFQq4Ed38PvOYPIdAlUkyCUys8FfTiQZz6BKwDEpt2UXu94hUMlpjWpVpI7IgG6qDEAOxLjLOE qPcY+0RiwFqT2HnnPNGJx6At+EZmHpfeODeYniy0uuPSPAyoQAb4alhxiq5jJh592t5qCcfi+Vmu AK2IEOyACjp0BaIrxLwQjEiXAXAXCf7dYxOTQDY49a0UK9gsa964RhCrZc51OU7PYpNcDEJfxhKa 7jebA5p8VNnTVYpEad5z/Kg5RdkzwLOyVz1Sk6ORs0en8HswkihwNclKVAUNfLhegDjBHVeAhgf6 tGKMBSjh9mKW644qQEu4sQAt4bwC1KLQuuzEbbbt91w3gPwkYQeBifbc/pbpzbIw4WfQtSCBsjt8 3f/Lb8oirCgAliP7E6IZ6z9v1FMS1kprxHUlyeMvU1cA7NWV8qGX+Yp9UleAtVZXfpJshewBX525 /IOxy/lbu2uRCX8TKLwKQL4oxkVE3+MVhTyzWI6BO5fAcBxssvu9hvILCctrxWzCepKwFnAsrGfC Ia4uArERPX34m1os7IKR/4cvnVxf/gfDpkhrCmVuZHN0cmVhbQplbmRvYmoKNzkgMCBvYmoKMTE5 MwplbmRvYmoKNzYgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCA3NyAwIFIgL1Jlc291cmNl cyA4MCAwIFIgL0NvbnRlbnRzIDc4IDAgUiAvTWVkaWFCb3gKWzAgMCA3MjAgNTQwXSA+PgplbmRv YmoKODAgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IC9JbWFnZUIgL0ltYWdlQyAvSW1h Z2VJIF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUgovQ3MyIDggMCBSID4+IC9Gb250IDw8IC9G Ni4wIDE0IDAgUiAvRjUuMCAxMyAwIFIgPj4gL1hPYmplY3QgPDwgL0ltNCA4MSAwIFIKPj4gPj4K ZW5kb2JqCjgxIDAgb2JqCjw8IC9MZW5ndGggODIgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBl IC9JbWFnZSAvV2lkdGggNzIwIC9IZWlnaHQgMTUgL0ludGVycG9sYXRlCnRydWUgL0NvbG9yU3Bh Y2UgNTggMCBSIC9JbnRlbnQgL1BlcmNlcHR1YWwgL0JpdHNQZXJDb21wb25lbnQgOCAvRmlsdGVy IC9EQ1REZWNvZGUKPj4Kc3RyZWFtCv/Y/+AAEEpGSUYAAQEAAAEAAQAA/+IFQElDQ19QUk9GSUxF AAEBAAAFMGFwcGwCIAAAbW50clJHQiBYWVogB9kAAgAZAAsAGgALYWNzcEFQUEwAAAAAYXBwbAAA AAAAAAAAAAAAAAAAAAAAAPbWAAEAAAAA0y1hcHBsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAALZHNjbQAAAQgAAALyZGVzYwAAA/wAAABvZ1hZWgAABGwAAAAU d3RwdAAABIAAAAAUclhZWgAABJQAAAAUYlhZWgAABKgAAAAUclRSQwAABLwAAAAOY3BydAAABMwA AAA4Y2hhZAAABQQAAAAsZ1RSQwAABLwAAAAOYlRSQwAABLwAAAAObWx1YwAAAAAAAAARAAAADGVu VVMAAAAmAAACfmVzRVMAAAAmAAABgmRhREsAAAAuAAAB6mRlREUAAAAsAAABqGZpRkkAAAAoAAAA 3GZyRlUAAAAoAAABKml0SVQAAAAoAAACVm5sTkwAAAAoAAACGG5iTk8AAAAmAAABBHB0QlIAAAAm AAABgnN2U0UAAAAmAAABBGphSlAAAAAaAAABUmtvS1IAAAAWAAACQHpoVFcAAAAWAAABbHpoQ04A AAAWAAAB1HJ1UlUAAAAiAAACpHBsUEwAAAAsAAACxgBZAGwAZQBpAG4AZQBuACAAUgBHAEIALQBw AHIAbwBmAGkAaQBsAGkARwBlAG4AZQByAGkAcwBrACAAUgBHAEIALQBwAHIAbwBmAGkAbABQAHIA bwBmAGkAbAAgAEcA6QBuAOkAcgBpAHEAdQBlACAAUgBWAEJOAIIsACAAUgBHAEIAIDDXMO0w1TCh MKQw65AadSgAIABSAEcAQgAggnJfaWPPj/AAUABlAHIAZgBpAGwAIABSAEcAQgAgAEcAZQBuAOkA cgBpAGMAbwBBAGwAbABnAGUAbQBlAGkAbgBlAHMAIABSAEcAQgAtAFAAcgBvAGYAaQBsZm6QGgAg AFIARwBCACBjz4/wZYdO9gBHAGUAbgBlAHIAZQBsACAAUgBHAEIALQBiAGUAcwBrAHIAaQB2AGUA bABzAGUAQQBsAGcAZQBtAGUAZQBuACAAUgBHAEIALQBwAHIAbwBmAGkAZQBsx3y8GAAgAFIARwBC ACDVBLhc0wzHfABQAHIAbwBmAGkAbABvACAAUgBHAEIAIABHAGUAbgBlAHIAaQBjAG8ARwBlAG4A ZQByAGkAYwAgAFIARwBCACAAUAByAG8AZgBpAGwAZQQeBDEESQQ4BDkAIAQ/BEAEPgREBDgEOwRM ACAAUgBHAEIAVQBuAGkAdwBlAHIAcwBhAGwAbgB5ACAAcAByAG8AZgBpAGwAIABSAEcAQgAAZGVz YwAAAAAAAAAUR2VuZXJpYyBSR0IgUHJvZmlsZQAAAAAAAAAAAAAAFEdlbmVyaWMgUkdCIFByb2Zp bGUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFhZWiAA AAAAAABadQAArHMAABc0WFlaIAAAAAAAAPNSAAEAAAABFs9YWVogAAAAAAAAdE0AAD3uAAAD0FhZ WiAAAAAAAAAoGgAAFZ8AALg2Y3VydgAAAAAAAAABAc0AAHRleHQAAAAAQ29weXJpZ2h0IDIwMDcg QXBwbGUgSW5jLiwgYWxsIHJpZ2h0cyByZXNlcnZlZC4Ac2YzMgAAAAAAAQxCAAAF3v//8yYAAAeS AAD9kf//+6L///2jAAAD3AAAwGz/4QBARXhpZgAATU0AKgAAAAgAAYdpAAQAAAABAAAAGgAAAAAA AqACAAQAAAABAAAC0KADAAQAAAABAAAADwAAAAD/2wBDAAMCAgICAgMCAgIDAwMDBAcEBAQEBAgG BgUHCgkKCgoJCQkLDA8NCwsPDAkJDRIODxAQERERCg0TFBMRFA8RERH/2wBDAQMDAwQEBAgEBAgR CwkLERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERH/wAAR CAAPAtADASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgED AwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRol JicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWW l5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3 +Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3 AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5 OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaan qKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIR AxEAPwD4Eooorzz8/CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooA/9kKZW5kc3RyZWFtCmVuZG9iago4MiAwIG9iagoyMjIxCmVuZG9i ago4NSAwIG9iago8PCAvTGVuZ3RoIDg2IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJl YW0KeAGtWE1v3DYQvfNXDNCLFmh29a3VqUAbt3ARoE69RQ5FD+7GbtzGTiw5aP2D/H/6kzqk+B61 otZe14YPK4vD4cx7b4akbuSt3Eiqf02eSlWm0p3LO7mW1Xd9JtteMum30/ELSZe1XFqbfLDJJDNz dquT8257/vn2y9lH6S51JbuK/csq97O9ktXxVSWvP7k4dkarvDI74zbSol6um0rKYi11uZY2X+p/ IWQXTrpM2zRr63StceZp0eZZbUYvbaAu/hvNzgbzKoPfqkitQ132240apWmay2aro4Od/jaNBtCu G6las9Hov6+Xmo1sLiT5qikXsvlTjjYumQd9jzxmRbNsy7Kgxwoef5VEFjYHSX5eyCv38AUPH/Fw jocexhdukkk+YaTDSEfjG4yt/AphiH6uzgYjk9x6o+0HTLvEwzUe/ljIb7L5cUh/4EpRsyxZtgaO DCSjBKTNuixyTa+p6nWdW7KytF0rX05yMUPOz0BN7gnR30bhydcDF0QuuQ9MDIJT0nfonndWlHPe lIeNByDOn2gBIyKz/et8YQbWMAYeaBPNJmcw9RxI8h7O3gNxmHSHi0IgCpM8UxQyFoVPk2nNi+JR 0iOGbAPQSszLof70tyyUoToVV3uB738P4Tv2VlfLJvamfP8NjJkSKPQKMAlHmCz4IGV4gbkdRzin PwOtW1jRMbWg1qG0HkTRduEIRd/Ppii22ttsB5tH0di6OcybQzHypij+PqBoErYd5Eh8OcIHQgP0 Qme6AVYUPGf18IxZMdSTujFaUb6p0svQOSXE24XFaY0VwlD/GYGNKRtKv1fnB5I3CzdEu9vxsryZ knf/lBII3lzLi90pe78AHpvCkAxS92maBIBhACywT46nZmu7lW0WkmUZG5Ek2iade5McrvNZqPbo PMNWPS9011qeIPTYnWJ1QrCQ3td+xwAyJz/5F6fWwiExDJnkUalK8hoMHL3hk/pxR4IjLHENFRJ0 PkTi5Zo6eZYXQ17kubxAwpMunrUv2sZjd8rLD8BoArrdTr3oWLIEi5syWxFtbieshh4Q9yb28WAE pjgEf7tqGUmCxzw+MBb2UHilBnlaPF7owVdrDhZcl5lhJMSozcxXO1fy1iYJneCbl+lqE0nk+YN7 0t5SjRXm9qTYnUrCKmG2/zid2z5niBerhOgTdA7d9bvkjTqbHrEG/KdISkKHd2CAnuPeSfxhy8X7 OzIZzuZdvBzf+J1TqYSvQ5iXEfM6L+xn0VljHxPldL9SJqhGxsK8PDwm4MQMiBPrlc3tMVEqGaMr RhQ79o+wOQ6Xi0iT9wuDe97/uF1M3BlF4pS5bD1BknSEB02CUgllOD00ji59KozA04OHxtnNNCbS Hb2LrJwePJ5z9o7dKRrvfJONAODZG9olbEs/RS+hw0kFL2DJDVTL37XEN+j/p9PyDQXBSzJJ4YIz 501/CWJBUpaIITje32NdpXlPmNezI7AIGBD7SLRafPiGP+LKUHUkaGVvXYRm7bprUfhPIDxXKXfQ KkMmYlhdbzyeo6vR2NAnR8Jmhg/UwZZ4MJNb33Hp+h9EpIoIOb5cPTT68Wf/LeqpO1YRuXtSPRAG AjNCdKpzADOiygsvCBWkUTJs1VyBa1KKvk+Fz0ajFTz18Hvsq/HEnUL1VoABisTrenRbC9H1/crP j88sHdKDR/z/AadkLoERtQwKObgK2nry8UkZu6J6oz6Bj2qhVMLGvVyYEMDb/wBow03dCmVuZHN0 cmVhbQplbmRvYmoKODYgMCBvYmoKMTMwMgplbmRvYmoKODQgMCBvYmoKPDwgL1R5cGUgL1BhZ2Ug L1BhcmVudCA3NyAwIFIgL1Jlc291cmNlcyA4NyAwIFIgL0NvbnRlbnRzIDg1IDAgUiAvTWVkaWFC b3gKWzAgMCA3MjAgNTQwXSA+PgplbmRvYmoKODcgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9U ZXh0IC9JbWFnZUIgL0ltYWdlQyAvSW1hZ2VJIF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUgov Q3MyIDggMCBSID4+IC9Gb250IDw8IC9GNi4wIDE0IDAgUiAvRjUuMCAxMyAwIFIgPj4gL1hPYmpl Y3QgPDwgL0ltNSA4OCAwIFIKPj4gPj4KZW5kb2JqCjg4IDAgb2JqCjw8IC9MZW5ndGggODkgMCBS IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNzIwIC9IZWlnaHQgMTUgL0lu dGVycG9sYXRlCnRydWUgL0NvbG9yU3BhY2UgNTggMCBSIC9JbnRlbnQgL1BlcmNlcHR1YWwgL0Jp dHNQZXJDb21wb25lbnQgOCAvRmlsdGVyIC9EQ1REZWNvZGUKPj4Kc3RyZWFtCv/Y/+AAEEpGSUYA AQEAAAEAAQAA/+IFQElDQ19QUk9GSUxFAAEBAAAFMGFwcGwCIAAAbW50clJHQiBYWVogB9kAAgAZ AAsAGgALYWNzcEFQUEwAAAAAYXBwbAAAAAAAAAAAAAAAAAAAAAAAAPbWAAEAAAAA0y1hcHBsAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALZHNjbQAAAQgAAALy ZGVzYwAAA/wAAABvZ1hZWgAABGwAAAAUd3RwdAAABIAAAAAUclhZWgAABJQAAAAUYlhZWgAABKgA AAAUclRSQwAABLwAAAAOY3BydAAABMwAAAA4Y2hhZAAABQQAAAAsZ1RSQwAABLwAAAAOYlRSQwAA BLwAAAAObWx1YwAAAAAAAAARAAAADGVuVVMAAAAmAAACfmVzRVMAAAAmAAABgmRhREsAAAAuAAAB 6mRlREUAAAAsAAABqGZpRkkAAAAoAAAA3GZyRlUAAAAoAAABKml0SVQAAAAoAAACVm5sTkwAAAAo AAACGG5iTk8AAAAmAAABBHB0QlIAAAAmAAABgnN2U0UAAAAmAAABBGphSlAAAAAaAAABUmtvS1IA AAAWAAACQHpoVFcAAAAWAAABbHpoQ04AAAAWAAAB1HJ1UlUAAAAiAAACpHBsUEwAAAAsAAACxgBZ AGwAZQBpAG4AZQBuACAAUgBHAEIALQBwAHIAbwBmAGkAaQBsAGkARwBlAG4AZQByAGkAcwBrACAA UgBHAEIALQBwAHIAbwBmAGkAbABQAHIAbwBmAGkAbAAgAEcA6QBuAOkAcgBpAHEAdQBlACAAUgBW AEJOAIIsACAAUgBHAEIAIDDXMO0w1TChMKQw65AadSgAIABSAEcAQgAggnJfaWPPj/AAUABlAHIA ZgBpAGwAIABSAEcAQgAgAEcAZQBuAOkAcgBpAGMAbwBBAGwAbABnAGUAbQBlAGkAbgBlAHMAIABS AEcAQgAtAFAAcgBvAGYAaQBsZm6QGgAgAFIARwBCACBjz4/wZYdO9gBHAGUAbgBlAHIAZQBsACAA UgBHAEIALQBiAGUAcwBrAHIAaQB2AGUAbABzAGUAQQBsAGcAZQBtAGUAZQBuACAAUgBHAEIALQBw AHIAbwBmAGkAZQBsx3y8GAAgAFIARwBCACDVBLhc0wzHfABQAHIAbwBmAGkAbABvACAAUgBHAEIA IABHAGUAbgBlAHIAaQBjAG8ARwBlAG4AZQByAGkAYwAgAFIARwBCACAAUAByAG8AZgBpAGwAZQQe BDEESQQ4BDkAIAQ/BEAEPgREBDgEOwRMACAAUgBHAEIAVQBuAGkAdwBlAHIAcwBhAGwAbgB5ACAA cAByAG8AZgBpAGwAIABSAEcAQgAAZGVzYwAAAAAAAAAUR2VuZXJpYyBSR0IgUHJvZmlsZQAAAAAA AAAAAAAAFEdlbmVyaWMgUkdCIFByb2ZpbGUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAFhZWiAAAAAAAABadQAArHMAABc0WFlaIAAAAAAAAPNSAAEAAAAB Fs9YWVogAAAAAAAAdE0AAD3uAAAD0FhZWiAAAAAAAAAoGgAAFZ8AALg2Y3VydgAAAAAAAAABAc0A AHRleHQAAAAAQ29weXJpZ2h0IDIwMDcgQXBwbGUgSW5jLiwgYWxsIHJpZ2h0cyByZXNlcnZlZC4A c2YzMgAAAAAAAQxCAAAF3v//8yYAAAeSAAD9kf//+6L///2jAAAD3AAAwGz/4QBARXhpZgAATU0A KgAAAAgAAYdpAAQAAAABAAAAGgAAAAAAAqACAAQAAAABAAAC0KADAAQAAAABAAAADwAAAAD/2wBD AAMCAgICAgMCAgIDAwMDBAcEBAQEBAgGBgUHCgkKCgoJCQkLDA8NCwsPDAkJDRIODxAQERERCg0T FBMRFA8RERH/2wBDAQMDAwQEBAgEBAgRCwkLERERERERERERERERERERERERERERERERERERERER ERERERERERERERERERERERERERH/wAARCAAPAtADASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAA AAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKB kaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZn aGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT 1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcI CQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAV YnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6 goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk 5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD4Eooorzz8/CiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA/9kKZW5kc3RyZWFtCmVu ZG9iago4OSAwIG9iagoyMjIxCmVuZG9iago5MiAwIG9iago8PCAvTGVuZ3RoIDkzIDAgUiAvRmls dGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAGVWNtuGzcQfedXDNCHUkC83rt2+9akDpACAZpA QFAEfXBUuXFhObHWaesP6v/kkzrk8hyulpKqwA+iyOHhzDkzQ8oP8kYeJNe/ZZlLU+ey28g7uZfL F0Mh60EKGdbz9RvJs1ZunU052hRSmEN2l79sduvN58cv13eyu9WT3Cnur2j8x3orl6+2rfz0yfux t9qUjdlbd55WbdYtG6mrTtq6k77M9Ft02buTZ3mfF32bd+pnmVd9WbRmMukc9f4/aHTOmYsCuE2V O0A99vlKjfI8L2W11tXRTj+Lvsj6opOmNyt1/mWbaTCyuhH73bJdyOpPuVr5WE5CTwDLRgG7siZi A8T3YmXhQhD7erOQCz/6HYNbDK4xgPGj32Ts02escPewkN9k9fPo48inRuaYdIwmPLb5squrUslb Nm3Xlo7QIu875dSnRcqixxnpq0alL/RzqTFUytLWXL5kePbfSNdoqsLsSXIYrKo92kg/0ZSs52Ri YMCkC+R8Aif3GMhC41OOt9xOau+izajDTdBjR5gtgF+MtsZ+wSbu5oBu6eFRB03GkWc9I+HZldUZ pDiG204Z1pQkJzOGTe5EOwPMM5ygKcMhRrEfF2ZMR3JGOv9A+GQxXQJnyNSP2EOCYPE3VnjQE5Ze v0JxXGHqFm4NmKEYJ1KCjnLXELYZu6NHFJEOMAd4iMZT5lnt6zbqmzDu2pr2l0mBeMb7fqafMs4z kHkIbFiHJWPTMocRNhFlhxUqyaW34O7qWeAVth+gwTROXzKwoEqBLcPGtaZuzIIfzs59TVeTkBea s+tFrnXrZ11p8hdVPWPPft3rL6ezfwLXNtnyAJyK8WPoJsYmbYVhghLII5aJQ/q25AK9ZyyEidyA wcLxCoHFNfSjXDyYOQxUZgzVZw0E14wF7nxFLCsccDAlGhYCKz4dTtRDKumoQVvNJH0/YZ6HrSOv DJQEwzV4ROE2oGtY7xgiqeMMgZKgmfNpL5wfiu/HRaQgVPGJ6jFQ5hiDQFRbBk4b6qhX/kVR/H9T OiZCry+gcKsY/9DRQojNNF6aZArRksPYAxjTHdh/+pZmcOzuMpPq9c2gLJd0OrzO9puBdo4jV6HR xjyB84mYwikHb9EVyf2WSv0V5mIfHLgWtYJ6IOzQew02N+GRcuDhge3HswsWLEfmOQVhEDiQctJx oMBCr8b5I4BwHLjL8tsrv2za9HlHj+grByyIdCYLxKkfReeeeb8uRJ/wnVjaDs9mFx5LmyZjzMae 4wP4OSX5h4S6IZYLANLbO1YbxBg0vsjvyZfksYx3T5FJxo8F1JczAWa36fECmsGNBZTAaQG9gyIz lsWyiVFXDiAETUDWpIOGX0o72rB3xymas3sDiN78QxtmMxEpFhMizExShKcCmQXKkmKiwWTvTTsR 9oxXkCe6Kt2vrOlvACX6MZTAqf4ypM7xWmX4QYXY1dhHSBoCoWBciQlOYu5RBTTiNuCQcRKdmAQ/ zeRWSmzSUsIB8YHPo3g5qU2srbMlqKfPeKP/GVAJiM2c4oDsMqfifYkqZ3Ixc0gHf7PwCM7wCNI7 ef6H1p2KTH+4i2d97/pkodc/yEM/MpbOc3sWm2ok8c1/5nihWgplbmRzdHJlYW0KZW5kb2JqCjkz IDAgb2JqCjEyMDcKZW5kb2JqCjkxIDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgNzcgMCBS IC9SZXNvdXJjZXMgOTQgMCBSIC9Db250ZW50cyA5MiAwIFIgL01lZGlhQm94ClswIDAgNzIwIDU0 MF0gPj4KZW5kb2JqCjk0IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCAvSW1hZ2VCIC9J bWFnZUMgL0ltYWdlSSBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAwIFIKL0NzMiA4IDAgUiA+PiAv Rm9udCA8PCAvRjYuMCAxNCAwIFIgL0Y1LjAgMTMgMCBSID4+IC9YT2JqZWN0IDw8IC9JbTYgOTUg MCBSCj4+ID4+CmVuZG9iago5NSAwIG9iago8PCAvTGVuZ3RoIDk2IDAgUiAvVHlwZSAvWE9iamVj dCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDcyMCAvSGVpZ2h0IDE1IC9JbnRlcnBvbGF0ZQp0cnVl IC9Db2xvclNwYWNlIDU4IDAgUiAvSW50ZW50IC9QZXJjZXB0dWFsIC9CaXRzUGVyQ29tcG9uZW50 IDggL0ZpbHRlciAvRENURGVjb2RlCj4+CnN0cmVhbQr/2P/gABBKRklGAAEBAAABAAEAAP/iBUBJ Q0NfUFJPRklMRQABAQAABTBhcHBsAiAAAG1udHJSR0IgWFlaIAfZAAIAGQALABoAC2Fjc3BBUFBM AAAAAGFwcGwAAAAAAAAAAAAAAAAAAAAAAAD21gABAAAAANMtYXBwbAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC2RzY20AAAEIAAAC8mRlc2MAAAP8AAAAb2dY WVoAAARsAAAAFHd0cHQAAASAAAAAFHJYWVoAAASUAAAAFGJYWVoAAASoAAAAFHJUUkMAAAS8AAAA DmNwcnQAAATMAAAAOGNoYWQAAAUEAAAALGdUUkMAAAS8AAAADmJUUkMAAAS8AAAADm1sdWMAAAAA AAAAEQAAAAxlblVTAAAAJgAAAn5lc0VTAAAAJgAAAYJkYURLAAAALgAAAepkZURFAAAALAAAAahm aUZJAAAAKAAAANxmckZVAAAAKAAAASppdElUAAAAKAAAAlZubE5MAAAAKAAAAhhuYk5PAAAAJgAA AQRwdEJSAAAAJgAAAYJzdlNFAAAAJgAAAQRqYUpQAAAAGgAAAVJrb0tSAAAAFgAAAkB6aFRXAAAA FgAAAWx6aENOAAAAFgAAAdRydVJVAAAAIgAAAqRwbFBMAAAALAAAAsYAWQBsAGUAaQBuAGUAbgAg AFIARwBCAC0AcAByAG8AZgBpAGkAbABpAEcAZQBuAGUAcgBpAHMAawAgAFIARwBCAC0AcAByAG8A ZgBpAGwAUAByAG8AZgBpAGwAIABHAOkAbgDpAHIAaQBxAHUAZQAgAFIAVgBCTgCCLAAgAFIARwBC ACAw1zDtMNUwoTCkMOuQGnUoACAAUgBHAEIAIIJyX2ljz4/wAFAAZQByAGYAaQBsACAAUgBHAEIA IABHAGUAbgDpAHIAaQBjAG8AQQBsAGwAZwBlAG0AZQBpAG4AZQBzACAAUgBHAEIALQBQAHIAbwBm AGkAbGZukBoAIABSAEcAQgAgY8+P8GWHTvYARwBlAG4AZQByAGUAbAAgAFIARwBCAC0AYgBlAHMA awByAGkAdgBlAGwAcwBlAEEAbABnAGUAbQBlAGUAbgAgAFIARwBCAC0AcAByAG8AZgBpAGUAbMd8 vBgAIABSAEcAQgAg1QS4XNMMx3wAUAByAG8AZgBpAGwAbwAgAFIARwBCACAARwBlAG4AZQByAGkA YwBvAEcAZQBuAGUAcgBpAGMAIABSAEcAQgAgAFAAcgBvAGYAaQBsAGUEHgQxBEkEOAQ5ACAEPwRA BD4ERAQ4BDsETAAgAFIARwBCAFUAbgBpAHcAZQByAHMAYQBsAG4AeQAgAHAAcgBvAGYAaQBsACAA UgBHAEIAAGRlc2MAAAAAAAAAFEdlbmVyaWMgUkdCIFByb2ZpbGUAAAAAAAAAAAAAABRHZW5lcmlj IFJHQiBQcm9maWxlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAABYWVogAAAAAAAAWnUAAKxzAAAXNFhZWiAAAAAAAADzUgABAAAAARbPWFlaIAAAAAAAAHRN AAA97gAAA9BYWVogAAAAAAAAKBoAABWfAAC4NmN1cnYAAAAAAAAAAQHNAAB0ZXh0AAAAAENvcHly aWdodCAyMDA3IEFwcGxlIEluYy4sIGFsbCByaWdodHMgcmVzZXJ2ZWQuAHNmMzIAAAAAAAEMQgAA Bd7///MmAAAHkgAA/ZH///ui///9owAAA9wAAMBs/+EAQEV4aWYAAE1NACoAAAAIAAGHaQAEAAAA AQAAABoAAAAAAAKgAgAEAAAAAQAAAtCgAwAEAAAAAQAAAA8AAAAA/9sAQwADAgICAgIDAgICAwMD AwQHBAQEBAQIBgYFBwoJCgoKCQkJCwwPDQsLDwwJCQ0SDg8QEBEREQoNExQTERQPERER/9sAQwED AwMEBAQIBAQIEQsJCxERERERERERERERERERERERERERERERERERERERERERERERERERERERERER ERERERER/8AAEQgADwLQAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYHCAkK C//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGhCCNCscEVUtHwJDNi coIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6g4SF hoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2drh4uPk5ebn 6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkKC//EALURAAIBAgQE AwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBka JicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWW l5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5 +v/aAAwDAQACEQMRAD8A+BKKKK88/PwooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKAP/ZCmVuZHN0cmVhbQplbmRvYmoKOTYgMCBvYmoK MjIyMQplbmRvYmoKOTkgMCBvYmoKPDwgL0xlbmd0aCAxMDAgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVj b2RlID4+CnN0cmVhbQp4AaVVy27bQAy871cQ6EU6WN6VvHpc+wjanpJCQA9BD4HitGkjx5YcoP2g /me5qx1KtlSjQOGD1iI5S86Q1IFu6ECaf0WqyW40dVv6TDtav+kNNT0Z6ptz+wPpJKdH55MOPoaM WvJbX2+7Zrs/vtw9UffIN7lb3M9Y/2haWn9oC3r77PM4sdrUqhO7yzTLk7KwtMlKyjclVWnC/8aU fTo60ZU2Va5LzjPVWZWaXE1eukR9/geuziWzMsC1mXaAfO3rmp201inVDVsHP34WRVLazJKtVM3J X+UJF0P1A0WviiKm+ju9q30tF6EngCYrksqUAmgBeEsRxa4Cij7FtPKHLQ79HqdnHHY49NtYDe6I b8TpHk6CBB+OCpe0dzgFSBUdQyKPsDR9TF+o/jhUOyjDHDlNnDYzRXJdlJssZRkKm5d56qQxuipZ Hd9gcz08ziBENvTMip8F05Ex361aXwlT0e+R+MGVJT4Rdxks23i0QUhBY97rUO43lCvcgK3mBaau E+MOvIMueAvrnVD7EK44dxWG2z3QnnCV2Bo5IVx8fuFOcWEgL6yKpAs6hPXwxovFikehZ6S6CeVR mSjkSc0tS8TTMSW1FZ6EBGnZkKyK5M1XFI0MJXkwB8PI/3QowgQI3tjeiLs0FMLLcJmKOrm+Rfx7 ZFgHKfG8jsmkZVJRlAQLhwQO1Y3bPcMw8GlxGGYkh300IdmNgdH2rHP/aw7mcEuDIF0lDKFzxNL8 kP0DGygTn1m00AtXLCEVMVxYTLABdrFZ/Z4c1QYOcWuFnkC4ZMOfuSCUpHHeZIgJV6pomtSF+ZhL 5+fD8NrDgCj/+WCylxs51P6PjRxKlOykMnnzU74csjNGIuR0jHlV85cHxIhB8oDljBk6YcZj3IP4 v28/HpSRxJs/KjO5UwplbmRzdHJlYW0KZW5kb2JqCjEwMCAwIG9iago2ODMKZW5kb2JqCjk4IDAg b2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgNzcgMCBSIC9SZXNvdXJjZXMgMTAxIDAgUiAvQ29u dGVudHMgOTkgMCBSIC9NZWRpYUJveApbMCAwIDcyMCA1NDBdID4+CmVuZG9iagoxMDEgMCBvYmoK PDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IC9JbWFnZUIgL0ltYWdlQyAvSW1hZ2VJIF0gL0NvbG9y U3BhY2UgPDwgL0NzMSA3IDAgUgovQ3MyIDggMCBSID4+IC9Gb250IDw8IC9GNi4wIDE0IDAgUiAv RjUuMCAxMyAwIFIgPj4gL1hPYmplY3QgPDwgL0ltNyAxMDIgMCBSCj4+ID4+CmVuZG9iagoxMDIg MCBvYmoKPDwgL0xlbmd0aCAxMDMgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAv V2lkdGggNzIwIC9IZWlnaHQgMTUgL0ludGVycG9sYXRlCnRydWUgL0NvbG9yU3BhY2UgNTggMCBS IC9JbnRlbnQgL1BlcmNlcHR1YWwgL0JpdHNQZXJDb21wb25lbnQgOCAvRmlsdGVyIC9EQ1REZWNv ZGUKPj4Kc3RyZWFtCv/Y/+AAEEpGSUYAAQEAAAEAAQAA/+IFQElDQ19QUk9GSUxFAAEBAAAFMGFw cGwCIAAAbW50clJHQiBYWVogB9kAAgAZAAsAGgALYWNzcEFQUEwAAAAAYXBwbAAAAAAAAAAAAAAA AAAAAAAAAPbWAAEAAAAA0y1hcHBsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAALZHNjbQAAAQgAAALyZGVzYwAAA/wAAABvZ1hZWgAABGwAAAAUd3RwdAAABIAA AAAUclhZWgAABJQAAAAUYlhZWgAABKgAAAAUclRSQwAABLwAAAAOY3BydAAABMwAAAA4Y2hhZAAA BQQAAAAsZ1RSQwAABLwAAAAOYlRSQwAABLwAAAAObWx1YwAAAAAAAAARAAAADGVuVVMAAAAmAAAC fmVzRVMAAAAmAAABgmRhREsAAAAuAAAB6mRlREUAAAAsAAABqGZpRkkAAAAoAAAA3GZyRlUAAAAo AAABKml0SVQAAAAoAAACVm5sTkwAAAAoAAACGG5iTk8AAAAmAAABBHB0QlIAAAAmAAABgnN2U0UA AAAmAAABBGphSlAAAAAaAAABUmtvS1IAAAAWAAACQHpoVFcAAAAWAAABbHpoQ04AAAAWAAAB1HJ1 UlUAAAAiAAACpHBsUEwAAAAsAAACxgBZAGwAZQBpAG4AZQBuACAAUgBHAEIALQBwAHIAbwBmAGkA aQBsAGkARwBlAG4AZQByAGkAcwBrACAAUgBHAEIALQBwAHIAbwBmAGkAbABQAHIAbwBmAGkAbAAg AEcA6QBuAOkAcgBpAHEAdQBlACAAUgBWAEJOAIIsACAAUgBHAEIAIDDXMO0w1TChMKQw65AadSgA IABSAEcAQgAggnJfaWPPj/AAUABlAHIAZgBpAGwAIABSAEcAQgAgAEcAZQBuAOkAcgBpAGMAbwBB AGwAbABnAGUAbQBlAGkAbgBlAHMAIABSAEcAQgAtAFAAcgBvAGYAaQBsZm6QGgAgAFIARwBCACBj z4/wZYdO9gBHAGUAbgBlAHIAZQBsACAAUgBHAEIALQBiAGUAcwBrAHIAaQB2AGUAbABzAGUAQQBs AGcAZQBtAGUAZQBuACAAUgBHAEIALQBwAHIAbwBmAGkAZQBsx3y8GAAgAFIARwBCACDVBLhc0wzH fABQAHIAbwBmAGkAbABvACAAUgBHAEIAIABHAGUAbgBlAHIAaQBjAG8ARwBlAG4AZQByAGkAYwAg AFIARwBCACAAUAByAG8AZgBpAGwAZQQeBDEESQQ4BDkAIAQ/BEAEPgREBDgEOwRMACAAUgBHAEIA VQBuAGkAdwBlAHIAcwBhAGwAbgB5ACAAcAByAG8AZgBpAGwAIABSAEcAQgAAZGVzYwAAAAAAAAAU R2VuZXJpYyBSR0IgUHJvZmlsZQAAAAAAAAAAAAAAFEdlbmVyaWMgUkdCIFByb2ZpbGUAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFhZWiAAAAAAAABadQAA rHMAABc0WFlaIAAAAAAAAPNSAAEAAAABFs9YWVogAAAAAAAAdE0AAD3uAAAD0FhZWiAAAAAAAAAo GgAAFZ8AALg2Y3VydgAAAAAAAAABAc0AAHRleHQAAAAAQ29weXJpZ2h0IDIwMDcgQXBwbGUgSW5j LiwgYWxsIHJpZ2h0cyByZXNlcnZlZC4Ac2YzMgAAAAAAAQxCAAAF3v//8yYAAAeSAAD9kf//+6L/ //2jAAAD3AAAwGz/4QBARXhpZgAATU0AKgAAAAgAAYdpAAQAAAABAAAAGgAAAAAAAqACAAQAAAAB AAAC0KADAAQAAAABAAAADwAAAAD/2wBDAAMCAgICAgMCAgIDAwMDBAcEBAQEBAgGBgUHCgkKCgoJ CQkLDA8NCwsPDAkJDRIODxAQERERCg0TFBMRFA8RERH/2wBDAQMDAwQEBAgEBAgRCwkLERERERER ERERERERERERERERERERERERERERERERERERERERERERERERERERERERERH/wAARCAAPAtADASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD4Eooo rzz8/CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooA/9kKZW5kc3RyZWFtCmVuZG9iagoxMDMgMCBvYmoKMjIyMQplbmRvYmoKMTA2IDAg b2JqCjw8IC9MZW5ndGggMTA3IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAGt Vstu1EAQvPsrWuLiPexmxm9fCSDglEiWOCAOkdmEhTgPOznwQfwnPfZU2bv2LpGC9uCJu6anurqm nUe5lEcx+ssjI2lipN3KF7mTs/POSt2Jla4+jF+L2WSyc5howFixwRLu7GLb1tuHp+erW2l3epI7 xf1s2j/qRs4+NYW8u+957EXTKA324o5pnG2KPJUkLiRLCimjjf41Uu7pmI0pjS0zUyjPyMRlZLNg 8tIR7fk/anWOzNoibxobl1CPfVspyBgTSVVrdMDp0zoGZZFIWgaVsv+QbbQaqa4lfJMXK6l+yvuq L+Zk7mnGMtuUWVQyY4qMXyWUlatBwvOVrPvFFRb1D6x2WNxhcbMKBjS2d1uEGiYg+smfwTx1t5Jv Un3uKwkG2VUAJ7gTfiZ3ZvIiiSNlmqdZkUVOd2vKQqXv3TMX2+VxzVWV48EQa33mWmmsWjpZKUL4 ZxR1gGr/9jq3nCxOlrKppJUvl/pRm0GtIKyfoVbbMjiTC9p+J5jSXvsjnlbqO+0eoFS4ecCmWywY q7lCYzwmCH+fSHSPRC22dUCTF17cwh/chD1AMIBSNEBLvFj+LD1opspfk82ig71xb1DNeuwApWIG sGaT2IuhjiBs2UruJpj6oMaWVTfQ4SN4VL6VlW/txVQPHSenr8AL/OrMb82hYK9y/zzdkv1pN69H EEJWRupfFA0xCEQM1QTiHiYDdOwkBGfWMcRrVjOIXrI77Twj7xN3zUyCTR2JNQRr7IS7/fdgMqn6 4WJ1vFVNMJlV/7a3n+K0N0l5KkH4sgGNfVBywboR9M/gYYuFvhnL/W/mLczBbX+deWfpBvPG+SaW kLbbs+b+tH2DcnMsIiwgHy1F2yGC0X3sKyEhZw1dhGaQnM8ajHRxOQg5zoARpB2o6eeJ1l6coMcs xiN5U6/gEM5GvRt+ux42WmQ2vo7ciMgmwz9F/Hprz8a7zWNYAOSghBRV/LwFYkqs/6YiwAbN6wNk hzr3zDKp7/IvemQzJgplbmRzdHJlYW0KZW5kb2JqCjEwNyAwIG9iago3NTcKZW5kb2JqCjEwNSAw IG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDc3IDAgUiAvUmVzb3VyY2VzIDEwOCAwIFIgL0Nv bnRlbnRzIDEwNiAwIFIgL01lZGlhQm94ClswIDAgNzIwIDU0MF0gPj4KZW5kb2JqCjEwOCAwIG9i ago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgL0ltYWdlQiAvSW1hZ2VDIC9JbWFnZUkgXSAvQ29s b3JTcGFjZSA8PCAvQ3MxIDcgMCBSCi9DczIgOCAwIFIgPj4gL0ZvbnQgPDwgL0Y2LjAgMTQgMCBS IC9GNS4wIDEzIDAgUiA+PiAvWE9iamVjdCA8PCAvSW04IDEwOSAwIFIKPj4gPj4KZW5kb2JqCjEw OSAwIG9iago8PCAvTGVuZ3RoIDExMCAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdl IC9XaWR0aCA3MjAgL0hlaWdodCAxNSAvSW50ZXJwb2xhdGUKdHJ1ZSAvQ29sb3JTcGFjZSA1OCAw IFIgL0ludGVudCAvUGVyY2VwdHVhbCAvQml0c1BlckNvbXBvbmVudCA4IC9GaWx0ZXIgL0RDVERl Y29kZQo+PgpzdHJlYW0K/9j/4AAQSkZJRgABAQAAAQABAAD/4gVASUNDX1BST0ZJTEUAAQEAAAUw YXBwbAIgAABtbnRyUkdCIFhZWiAH2QACABkACwAaAAthY3NwQVBQTAAAAABhcHBsAAAAAAAAAAAA AAAAAAAAAAAA9tYAAQAAAADTLWFwcGwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAtkc2NtAAABCAAAAvJkZXNjAAAD/AAAAG9nWFlaAAAEbAAAABR3dHB0AAAE gAAAABRyWFlaAAAElAAAABRiWFlaAAAEqAAAABRyVFJDAAAEvAAAAA5jcHJ0AAAEzAAAADhjaGFk AAAFBAAAACxnVFJDAAAEvAAAAA5iVFJDAAAEvAAAAA5tbHVjAAAAAAAAABEAAAAMZW5VUwAAACYA AAJ+ZXNFUwAAACYAAAGCZGFESwAAAC4AAAHqZGVERQAAACwAAAGoZmlGSQAAACgAAADcZnJGVQAA ACgAAAEqaXRJVAAAACgAAAJWbmxOTAAAACgAAAIYbmJOTwAAACYAAAEEcHRCUgAAACYAAAGCc3ZT RQAAACYAAAEEamFKUAAAABoAAAFSa29LUgAAABYAAAJAemhUVwAAABYAAAFsemhDTgAAABYAAAHU cnVSVQAAACIAAAKkcGxQTAAAACwAAALGAFkAbABlAGkAbgBlAG4AIABSAEcAQgAtAHAAcgBvAGYA aQBpAGwAaQBHAGUAbgBlAHIAaQBzAGsAIABSAEcAQgAtAHAAcgBvAGYAaQBsAFAAcgBvAGYAaQBs ACAARwDpAG4A6QByAGkAcQB1AGUAIABSAFYAQk4AgiwAIABSAEcAQgAgMNcw7TDVMKEwpDDrkBp1 KAAgAFIARwBCACCCcl9pY8+P8ABQAGUAcgBmAGkAbAAgAFIARwBCACAARwBlAG4A6QByAGkAYwBv AEEAbABsAGcAZQBtAGUAaQBuAGUAcwAgAFIARwBCAC0AUAByAG8AZgBpAGxmbpAaACAAUgBHAEIA IGPPj/Blh072AEcAZQBuAGUAcgBlAGwAIABSAEcAQgAtAGIAZQBzAGsAcgBpAHYAZQBsAHMAZQBB AGwAZwBlAG0AZQBlAG4AIABSAEcAQgAtAHAAcgBvAGYAaQBlAGzHfLwYACAAUgBHAEIAINUEuFzT DMd8AFAAcgBvAGYAaQBsAG8AIABSAEcAQgAgAEcAZQBuAGUAcgBpAGMAbwBHAGUAbgBlAHIAaQBj ACAAUgBHAEIAIABQAHIAbwBmAGkAbABlBB4EMQRJBDgEOQAgBD8EQAQ+BEQEOAQ7BEwAIABSAEcA QgBVAG4AaQB3AGUAcgBzAGEAbABuAHkAIABwAHIAbwBmAGkAbAAgAFIARwBCAABkZXNjAAAAAAAA ABRHZW5lcmljIFJHQiBQcm9maWxlAAAAAAAAAAAAAAAUR2VuZXJpYyBSR0IgUHJvZmlsZQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWFlaIAAAAAAAAFp1 AACscwAAFzRYWVogAAAAAAAA81IAAQAAAAEWz1hZWiAAAAAAAAB0TQAAPe4AAAPQWFlaIAAAAAAA ACgaAAAVnwAAuDZjdXJ2AAAAAAAAAAEBzQAAdGV4dAAAAABDb3B5cmlnaHQgMjAwNyBBcHBsZSBJ bmMuLCBhbGwgcmlnaHRzIHJlc2VydmVkLgBzZjMyAAAAAAABDEIAAAXe///zJgAAB5IAAP2R///7 ov///aMAAAPcAADAbP/hAEBFeGlmAABNTQAqAAAACAABh2kABAAAAAEAAAAaAAAAAAACoAIABAAA AAEAAALQoAMABAAAAAEAAAAPAAAAAP/bAEMAAwICAgICAwICAgMDAwMEBwQEBAQECAYGBQcKCQoK CgkJCQsMDw0LCw8MCQkNEg4PEBAREREKDRMUExEUDxEREf/bAEMBAwMDBAQECAQECBELCQsRERER EREREREREREREREREREREREREREREREREREREREREREREREREREREREREREREf/AABEIAA8C0AMB IgACEQEDEQH/xAAfAAABBQEBAQEBAQAAAAAAAAAAAQIDBAUGBwgJCgv/xAC1EAACAQMDAgQDBQUE BAAAAX0BAgMABBEFEiExQQYTUWEHInEUMoGRoQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1 Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOk paanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+fr/xAAf AQADAQEBAQEBAQEBAAAAAAAAAQIDBAUGBwgJCgv/xAC1EQACAQIEBAMEBwUEBAABAncAAQIDEQQF ITEGEkFRB2FxEyIygQgUQpGhscEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdI SUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1 tre4ubrCw8TFxsfIycrS09TV1tfY2dri4+Tl5ufo6ery8/T19vf4+fr/2gAMAwEAAhEDEQA/APgS iiivPPz8KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigD/2QplbmRzdHJlYW0KZW5kb2JqCjExMCAwIG9iagoyMjIxCmVuZG9iagoxMTMg MCBvYmoKPDwgL0xlbmd0aCAxMTQgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4 AZVX247bNhB951cM0BcJqGVKsm55c9INsAWS7jYO+tDkYaPsJltESdba3D6o/9NP6lDkHNKi7XXg B9HicHjmzBlydEeXdEeaf02hqVpp2l7TX/SRlk/GnPqRchr7+fwN6aymW2NTWJuccrXPbnlxve2v P99/ufpA21veyexifnk1PfqBludDR799mnDszFZFpXbmDdKyztqmolXZUr1qqSsy/uchT3B0pjud d7VuGWehy67IaxW8NEAn/HccnQGzyMVvVWrjkLd9vGEjrXVBm55nrR0/87bKOkZfdWrD4J/WGQdD mxtKfml1Spt/6GwzxXLUdeCwWLHDpvMeK/H4NyWUmhAoOXfP9fOUFtObdUpVZabEZLyWqf4+5XB5 6lbefJLBx5Re0+Z3i9HyyZEZJg2jEY+1btpVWbC3pqrbujCE5rprmdNJFjGLkx9LX2kzveBnw2hK ZmlQy6cIL/nX02VNOTE7KdnvrFxN3iz98MZkrT9ImKDiO0Y/hKfPYgRSblNlOWV27ODe0Y3Vb2VG vGDxF5mxa5TPB0wGuJHVJ6QToAYA3sLjV3j0viPwI3KtLo3gbS55tDeXh4g3OTclws9VycTXTvcg PvnvJ9IYeKurrIm9cRqFHAQkrL1A1KxwWxdzhaskWpWn1KyynBIe2OyKv4UMZMewutRudW2x9ztx g71HQbO9kjl542xUgtRF+JBemEDG2KGHem9cacN4y0H4kj4hixPvuZ5XIxP/RND/IafNRcrnneFO mEKos0hVgjoYxbYHRlQPSIQR/ICXt1KN4ucEWM8kg8/OZJWU4w/wG28OfrlUFnnNejSBHmHT3Ed8 McxVnJcln218GaAomE0EBBpEFBaiSmJabuayhhOAx6LM2ZJThFAgBIzICBSLAbwhn4Lp7HvM13YX OCV/ilDg5yuodK9U8k2MBBBSHbg7wrW7hCOu6yo++QdsD8LwZgAPgyB5lbyx4FSCCHrAg72/UWUh UimJkgnWurtDkB94XrpEHRQpJZFIg2sE+QDAHq55+wcZVBGDXROrFXShMkcEK0GOw5VEiSMKg1cp C9KDefi+UUGDFFz0Adrpvim4VdqtrejCMZ3nqQdf7G6nceCgXR5/RXnZm0ZE+15kHSZh6raEJn/u gS7k8JHzKpqQp6x9Kd5RYufAYXu6sY8R+CZA/KAMgBIDJ1CVINMSWpRwVyXkq4T9+xxHnB84Hou6 naWQOX/gQrXBArS3Rn1JqL5coWFE7w48X00SasyhuDuWAaME9RByK5eDrQCFrYDTmuwt6BC27/1Q ZzgFZsYq+cn6C799jtRfqevZeRvVn/kUiLRw4PiO3Z3WeHiJS9wuhUFrBWlA2SPyDG1DLmAUy+Qm 3Sv7qcS9DHGVQnS4Sl32QqEEW1h54HLE8llYYSfC7fvJ9PJX3O5pyfTKEcLtrRPcev7xKLuDJsQH LYoJeMeMaUEnek6LajINmjpb6uuLU3tNOtJr7muq/HcQf5df/g+dx1ayCmVuZHN0cmVhbQplbmRv YmoKMTE0IDAgb2JqCjExMjYKZW5kb2JqCjExMiAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50 IDc3IDAgUiAvUmVzb3VyY2VzIDExNSAwIFIgL0NvbnRlbnRzIDExMyAwIFIgL01lZGlhQm94Clsw IDAgNzIwIDU0MF0gPj4KZW5kb2JqCjExNSAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQg L0ltYWdlQiAvSW1hZ2VDIC9JbWFnZUkgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcgMCBSCi9DczIg OCAwIFIgPj4gL0ZvbnQgPDwgL0Y2LjAgMTQgMCBSIC9GNS4wIDEzIDAgUiA+PiAvWE9iamVjdCA8 PCAvSW05IDExNiAwIFIKPj4gPj4KZW5kb2JqCjExNiAwIG9iago8PCAvTGVuZ3RoIDExNyAwIFIg L1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA3MjAgL0hlaWdodCAxNSAvSW50 ZXJwb2xhdGUKdHJ1ZSAvQ29sb3JTcGFjZSA1OCAwIFIgL0ludGVudCAvUGVyY2VwdHVhbCAvQml0 c1BlckNvbXBvbmVudCA4IC9GaWx0ZXIgL0RDVERlY29kZQo+PgpzdHJlYW0K/9j/4AAQSkZJRgAB AQAAAQABAAD/4gVASUNDX1BST0ZJTEUAAQEAAAUwYXBwbAIgAABtbnRyUkdCIFhZWiAH2QACABkA CwAaAAthY3NwQVBQTAAAAABhcHBsAAAAAAAAAAAAAAAAAAAAAAAA9tYAAQAAAADTLWFwcGwAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAtkc2NtAAABCAAAAvJk ZXNjAAAD/AAAAG9nWFlaAAAEbAAAABR3dHB0AAAEgAAAABRyWFlaAAAElAAAABRiWFlaAAAEqAAA ABRyVFJDAAAEvAAAAA5jcHJ0AAAEzAAAADhjaGFkAAAFBAAAACxnVFJDAAAEvAAAAA5iVFJDAAAE vAAAAA5tbHVjAAAAAAAAABEAAAAMZW5VUwAAACYAAAJ+ZXNFUwAAACYAAAGCZGFESwAAAC4AAAHq ZGVERQAAACwAAAGoZmlGSQAAACgAAADcZnJGVQAAACgAAAEqaXRJVAAAACgAAAJWbmxOTAAAACgA AAIYbmJOTwAAACYAAAEEcHRCUgAAACYAAAGCc3ZTRQAAACYAAAEEamFKUAAAABoAAAFSa29LUgAA ABYAAAJAemhUVwAAABYAAAFsemhDTgAAABYAAAHUcnVSVQAAACIAAAKkcGxQTAAAACwAAALGAFkA bABlAGkAbgBlAG4AIABSAEcAQgAtAHAAcgBvAGYAaQBpAGwAaQBHAGUAbgBlAHIAaQBzAGsAIABS AEcAQgAtAHAAcgBvAGYAaQBsAFAAcgBvAGYAaQBsACAARwDpAG4A6QByAGkAcQB1AGUAIABSAFYA Qk4AgiwAIABSAEcAQgAgMNcw7TDVMKEwpDDrkBp1KAAgAFIARwBCACCCcl9pY8+P8ABQAGUAcgBm AGkAbAAgAFIARwBCACAARwBlAG4A6QByAGkAYwBvAEEAbABsAGcAZQBtAGUAaQBuAGUAcwAgAFIA RwBCAC0AUAByAG8AZgBpAGxmbpAaACAAUgBHAEIAIGPPj/Blh072AEcAZQBuAGUAcgBlAGwAIABS AEcAQgAtAGIAZQBzAGsAcgBpAHYAZQBsAHMAZQBBAGwAZwBlAG0AZQBlAG4AIABSAEcAQgAtAHAA cgBvAGYAaQBlAGzHfLwYACAAUgBHAEIAINUEuFzTDMd8AFAAcgBvAGYAaQBsAG8AIABSAEcAQgAg AEcAZQBuAGUAcgBpAGMAbwBHAGUAbgBlAHIAaQBjACAAUgBHAEIAIABQAHIAbwBmAGkAbABlBB4E MQRJBDgEOQAgBD8EQAQ+BEQEOAQ7BEwAIABSAEcAQgBVAG4AaQB3AGUAcgBzAGEAbABuAHkAIABw AHIAbwBmAGkAbAAgAFIARwBCAABkZXNjAAAAAAAAABRHZW5lcmljIFJHQiBQcm9maWxlAAAAAAAA AAAAAAAUR2VuZXJpYyBSR0IgUHJvZmlsZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAWFlaIAAAAAAAAFp1AACscwAAFzRYWVogAAAAAAAA81IAAQAAAAEW z1hZWiAAAAAAAAB0TQAAPe4AAAPQWFlaIAAAAAAAACgaAAAVnwAAuDZjdXJ2AAAAAAAAAAEBzQAA dGV4dAAAAABDb3B5cmlnaHQgMjAwNyBBcHBsZSBJbmMuLCBhbGwgcmlnaHRzIHJlc2VydmVkLgBz ZjMyAAAAAAABDEIAAAXe///zJgAAB5IAAP2R///7ov///aMAAAPcAADAbP/hAEBFeGlmAABNTQAq AAAACAABh2kABAAAAAEAAAAaAAAAAAACoAIABAAAAAEAAALQoAMABAAAAAEAAAAPAAAAAP/bAEMA AwICAgICAwICAgMDAwMEBwQEBAQECAYGBQcKCQoKCgkJCQsMDw0LCw8MCQkNEg4PEBAREREKDRMU ExEUDxEREf/bAEMBAwMDBAQECAQECBELCQsRERERERERERERERERERERERERERERERERERERERER EREREREREREREREREREREREREf/AABEIAA8C0AMBIgACEQEDEQH/xAAfAAABBQEBAQEBAQAAAAAA AAAAAQIDBAUGBwgJCgv/xAC1EAACAQMDAgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEUMoGR oQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdo aWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU 1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+fr/xAAfAQADAQEBAQEBAQEBAAAAAAAAAQIDBAUGBwgJ Cgv/xAC1EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIygQgUQpGhscEJIzNS8BVi ctEKFiQ04SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqC g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2dri4+Tl 5ufo6ery8/T19vf4+fr/2gAMAwEAAhEDEQA/APgSiiivPPz8KKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigD/2QplbmRzdHJlYW0KZW5k b2JqCjExNyAwIG9iagoyMjIxCmVuZG9iagoxMjAgMCBvYmoKPDwgL0xlbmd0aCAxMjEgMCBSIC9G aWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AZVYTXPbNhC941fsTA+lDqLBb7I9dFqnnUkv scfq5FD34Cpy6tZybNKO0x+U/5Of1AWJ9wiRktyMJkOYWCx233u7APMg5/IgVn9VaqXIrbQbeSt3 cnLaJbLuJJFuPZ2/FhuXcuNs0sEmkcTsszs527Trzf3j09WttDe6k9vF/ZKif6y3cvJ6m1h59aEP ZGe6SAuza+Bizcq4rgrJs1rKvJYmjfWvMeg+IBvbxiZNaWuNNLVZkyalCV66UPsMHjQ/F84ygd8i s86h7vvTSo2stams1jo72OkzTeLaFmUhWW1WGv8vZaz5yOpaom/qdCGrv+XnVZ/NUd+Bx1o9VlZD 8A4LOPxdIlm4FCR6tZBlP7jBoLvCaPsnRpx8vzCD+ROmaP3oPW4wgy3ohTODqYmeYcoZDu4wBS/3 eNF+wOjTv5i8Qlhc9g5GavKHrH79WuySsombpG6ktgMbIXjchaHwzfJonO0GgT4gPgLJ1Dsg2YWh DxpVtTh1OpW2G+MLymuztFWdZ6nyWhVlXaZOpIltatVpX2xzZfZ+ekmabKifpT4r1UWmwnMaZNbR 51GBg6mKfUfm3plRfQfOsnyfNxXgWy+XvwDETEiy0NpSiQIOgg3WyfFshsKidwJPpuCF++LF+hYh Ufbkxq82DAqLECQ35Fpu+E8HY255BzlgZrqRRExyVBbTne6xE9YB1Y+cz2jS3gPSTd94lCZuMQ8e MXcMuv04DjH7jBSJDG2IDGy5GdD81okkkchvbiIit4YJ64dTpI+DoE/4bgdt7a3WH8K604Z+vK4e FCv2+v3ouopK7Iiub+uf5yVl9pWUOzKmJTV3p2SdURlddwPc2X4JBwkA7h3X0YawDjibUQi0JX2U Bvnj1FhLdPgOgTGM774O7/BsdXi7w1wRcv1Of0t95pkDPM8pZw/4lzng8x42d1cWcbXHnQL+GzrF WAPAFLjNZQ8LLm6J2/JiPbffeqAMD+03vndSvSgGOpqThF19awwIxWLuDFNWFF50W76iUG5BJ43I KxxjhkFdLyTNFFOX0JE2dYiJqpwQq0xQcdydZ8CwvYlaSpDB07hTDfaHDWK9jMLQVFh6erp/7tQ7 UPCBANPExnlS1pLsi5VAP05OOPKJaE58VHgyp3BQFBLF3hMFwMxAgmLeJxj7J8lo30PE2EVZ9rc8 uiNiSyqgHaVKs7H/qy/PrDmXNLaFNtFEnoe7/emFK1WP6MXpvAbdPTnAsI6zUm/2W1M0TZxnZaa4 +ne3cjG9Ewc9OKCkL+JUb+6zI45YEjO2TCCyHtGiEeeegFar1zt/vlCOgB/W245wWxgnGKTwlOFN gQFoC7Qz8LlVal6ooSF1leSAouRVFudFD3D/ZsDQNU/b63vaYIevFhOACQ8BnL7FXi6CHnvs6HTf dYcOu3An18rTvCJte1q5OR54eDIMUMzcaQP50V+0zHjjQi+g5PGC7JJvaggmvrlr12FxLM/2fbq8 8fXI2odiuM5rz4w9DptwV9piMWUCU70PeGlueTNgUTPBFuZHe6UaUXEHLywBhwPoVTPhUEG/jHxy Et1D+0iBAdOEsCNKZskEeFGkLVdj0UcaM38eDOTzcvH9kKTpv7lfvgTur5lQev2lJEuqyedk9CUo mBdKMHTXgzp3p6C+9ooiBOuxL+EuERyYwBtXYvxNcAkKEBydzGypVX62YNHYQjk1c8y+yws7OyKb JfzhPCO/o3bpd/qRbSJOhR/Zy9p9Zqpjqvr/dKaBgLyZ8KkEjLekw6nOkNPeMP2vFZ4UpALJs1kE HYX14nM0URd7Jeykdv4fBFXj/QplbmRzdHJlYW0KZW5kb2JqCjEyMSAwIG9iagoxMzU4CmVuZG9i agoxMTkgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCA3NyAwIFIgL1Jlc291cmNlcyAxMjIg MCBSIC9Db250ZW50cyAxMjAgMCBSIC9NZWRpYUJveApbMCAwIDcyMCA1NDBdIC9Bbm5vdHMgMTI2 IDAgUiA+PgplbmRvYmoKMTIyIDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCAvSW1hZ2VC IC9JbWFnZUMgL0ltYWdlSSBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAwIFIKL0NzMiA4IDAgUiA+ PiAvRm9udCA8PCAvRjYuMCAxNCAwIFIgL0Y1LjAgMTMgMCBSID4+IC9YT2JqZWN0IDw8IC9JbTEw IDEyMyAwIFIKPj4gPj4KZW5kb2JqCjEyNiAwIG9iagpbIDEyNyAwIFIgMTI4IDAgUiAxMjkgMCBS IDEzMCAwIFIgXQplbmRvYmoKMTIzIDAgb2JqCjw8IC9MZW5ndGggMTI0IDAgUiAvVHlwZSAvWE9i amVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDcyMCAvSGVpZ2h0IDE1IC9JbnRlcnBvbGF0ZQp0 cnVlIC9Db2xvclNwYWNlIDU4IDAgUiAvSW50ZW50IC9QZXJjZXB0dWFsIC9CaXRzUGVyQ29tcG9u ZW50IDggL0ZpbHRlciAvRENURGVjb2RlCj4+CnN0cmVhbQr/2P/gABBKRklGAAEBAAABAAEAAP/i BUBJQ0NfUFJPRklMRQABAQAABTBhcHBsAiAAAG1udHJSR0IgWFlaIAfZAAIAGQALABoAC2Fjc3BB UFBMAAAAAGFwcGwAAAAAAAAAAAAAAAAAAAAAAAD21gABAAAAANMtYXBwbAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC2RzY20AAAEIAAAC8mRlc2MAAAP8AAAA b2dYWVoAAARsAAAAFHd0cHQAAASAAAAAFHJYWVoAAASUAAAAFGJYWVoAAASoAAAAFHJUUkMAAAS8 AAAADmNwcnQAAATMAAAAOGNoYWQAAAUEAAAALGdUUkMAAAS8AAAADmJUUkMAAAS8AAAADm1sdWMA AAAAAAAAEQAAAAxlblVTAAAAJgAAAn5lc0VTAAAAJgAAAYJkYURLAAAALgAAAepkZURFAAAALAAA AahmaUZJAAAAKAAAANxmckZVAAAAKAAAASppdElUAAAAKAAAAlZubE5MAAAAKAAAAhhuYk5PAAAA JgAAAQRwdEJSAAAAJgAAAYJzdlNFAAAAJgAAAQRqYUpQAAAAGgAAAVJrb0tSAAAAFgAAAkB6aFRX AAAAFgAAAWx6aENOAAAAFgAAAdRydVJVAAAAIgAAAqRwbFBMAAAALAAAAsYAWQBsAGUAaQBuAGUA bgAgAFIARwBCAC0AcAByAG8AZgBpAGkAbABpAEcAZQBuAGUAcgBpAHMAawAgAFIARwBCAC0AcABy AG8AZgBpAGwAUAByAG8AZgBpAGwAIABHAOkAbgDpAHIAaQBxAHUAZQAgAFIAVgBCTgCCLAAgAFIA RwBCACAw1zDtMNUwoTCkMOuQGnUoACAAUgBHAEIAIIJyX2ljz4/wAFAAZQByAGYAaQBsACAAUgBH AEIAIABHAGUAbgDpAHIAaQBjAG8AQQBsAGwAZwBlAG0AZQBpAG4AZQBzACAAUgBHAEIALQBQAHIA bwBmAGkAbGZukBoAIABSAEcAQgAgY8+P8GWHTvYARwBlAG4AZQByAGUAbAAgAFIARwBCAC0AYgBl AHMAawByAGkAdgBlAGwAcwBlAEEAbABnAGUAbQBlAGUAbgAgAFIARwBCAC0AcAByAG8AZgBpAGUA bMd8vBgAIABSAEcAQgAg1QS4XNMMx3wAUAByAG8AZgBpAGwAbwAgAFIARwBCACAARwBlAG4AZQBy AGkAYwBvAEcAZQBuAGUAcgBpAGMAIABSAEcAQgAgAFAAcgBvAGYAaQBsAGUEHgQxBEkEOAQ5ACAE PwRABD4ERAQ4BDsETAAgAFIARwBCAFUAbgBpAHcAZQByAHMAYQBsAG4AeQAgAHAAcgBvAGYAaQBs ACAAUgBHAEIAAGRlc2MAAAAAAAAAFEdlbmVyaWMgUkdCIFByb2ZpbGUAAAAAAAAAAAAAABRHZW5l cmljIFJHQiBQcm9maWxlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAABYWVogAAAAAAAAWnUAAKxzAAAXNFhZWiAAAAAAAADzUgABAAAAARbPWFlaIAAAAAAA AHRNAAA97gAAA9BYWVogAAAAAAAAKBoAABWfAAC4NmN1cnYAAAAAAAAAAQHNAAB0ZXh0AAAAAENv cHlyaWdodCAyMDA3IEFwcGxlIEluYy4sIGFsbCByaWdodHMgcmVzZXJ2ZWQuAHNmMzIAAAAAAAEM QgAABd7///MmAAAHkgAA/ZH///ui///9owAAA9wAAMBs/+EAQEV4aWYAAE1NACoAAAAIAAGHaQAE AAAAAQAAABoAAAAAAAKgAgAEAAAAAQAAAtCgAwAEAAAAAQAAAA8AAAAA/9sAQwADAgICAgIDAgIC AwMDAwQHBAQEBAQIBgYFBwoJCgoKCQkJCwwPDQsLDwwJCQ0SDg8QEBEREQoNExQTERQPERER/9sA QwEDAwMEBAQIBAQIEQsJCxERERERERERERERERERERERERERERERERERERERERERERERERERERER ERERERERERER/8AAEQgADwLQAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYH CAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGhCCNCscEVUtHw JDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6 g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2drh4uPk 5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkKC//EALURAAIB AgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEX GBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKT lJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX2 9/j5+v/aAAwDAQACEQMRAD8A+BKKKK88/PwooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAP/ZCmVuZHN0cmVhbQplbmRvYmoKMTI0IDAg b2JqCjIyMjEKZW5kb2JqCjEzMiAwIG9iago8PCAvTGVuZ3RoIDEzMyAwIFIgL0ZpbHRlciAvRmxh dGVEZWNvZGUgPj4Kc3RyZWFtCngBrZXNbptAEMfv+xRzhIPxLrAYrk3aqpVa1QpSDlUPCbVbN3ES Q6K2D5T3ySN1dpcZPpb4Q6p8ADPD7Px/88EOlrADib9FLEGnEuoVXMIdzM8aBVUDCppqbF+DjDLY GJ/Y+ShQYspv/mVVV6uHx6erW6g3eJI5xfyUtpdqC/MPW6Xg/N4mMjDrWIuhg8k1yaJ8oSFNcsjS HIo4wn9d0jYhGclCqiKTOWYay6SIVSZ6D02qVsEO9Zl0Zori6kSagHjumxKfOSte40RHhS4K0IUo Met3OkIVUK7hKwSfQ5jhQRCs6ObPY2iOhgDa6wU9YJcH5yuCJoRvUH6EtyUycBLxWCPOiPSkZXKR p0mM4Rc6y7PYaFSyyFGmrYEvzMZpFTn8swQLjuklqGAgJngOofyFqYillS5N+QeUpoMl6VQ0RHMW CofmltDc003DKAgSMfpJLuxBvoKBku+GfKsb9ibbgCxWfEwOe6Ilt0+mIYy/GV7TBGVmxRjaSygs NKye47sHWi9apqOFF00gtE8dI5IyRrRXtnMWwRWxqRkNxeEH38mHI9KRnES9oSJyQKxm17MTZLue nCRr5hrnq8fCklU4sKN+fGn7cS9aP5xF64czbFkDC74jBBBiR+DQrtuhZQLVE7k0BJBtvbfdyHe9 2r2GCNsVQXT/nkJQHDGCZp4VLo0RwOcRQLMjjohmB9oPhwAvmMU1tcXWU0eUKsbE2Nu9B8FMEpPU 3XTD/ZssXmBeDWzx+MevRuOm55ubQyuia+Qjwdky5N6K6JdBmCVxShm8cFiG97ZHRcCACTk1mGfg DcylaMjXvSuCik3s/H8mHb83doe2350Yrwf6dBJQO+i9aLZP/XAI6LIdYgeq+xL/oPZgQL7ogyyb U4bg9VY9pz5vGxIrwK25vR4ZIaj7O2P5D78S+ZsKZW5kc3RyZWFtCmVuZG9iagoxMzMgMCBvYmoK Njk0CmVuZG9iagoxMzEgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCA3NyAwIFIgL1Jlc291 cmNlcyAxMzQgMCBSIC9Db250ZW50cyAxMzIgMCBSIC9NZWRpYUJveApbMCAwIDcyMCA1NDBdID4+ CmVuZG9iagoxMzQgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IC9JbWFnZUIgL0ltYWdl QyAvSW1hZ2VJIF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUgovQ3MyIDggMCBSID4+IC9Gb250 IDw8IC9GNS4wIDEzIDAgUiA+PiAvWE9iamVjdCA8PCAvSW0xMSAxMzUgMCBSID4+ID4+CmVuZG9i agoxMzUgMCBvYmoKPDwgL0xlbmd0aCAxMzYgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9J bWFnZSAvV2lkdGggNzIwIC9IZWlnaHQgMTUgL0ludGVycG9sYXRlCnRydWUgL0NvbG9yU3BhY2Ug NTggMCBSIC9JbnRlbnQgL1BlcmNlcHR1YWwgL0JpdHNQZXJDb21wb25lbnQgOCAvRmlsdGVyIC9E Q1REZWNvZGUKPj4Kc3RyZWFtCv/Y/+AAEEpGSUYAAQEAAAEAAQAA/+IFQElDQ19QUk9GSUxFAAEB AAAFMGFwcGwCIAAAbW50clJHQiBYWVogB9kAAgAZAAsAGgALYWNzcEFQUEwAAAAAYXBwbAAAAAAA AAAAAAAAAAAAAAAAAPbWAAEAAAAA0y1hcHBsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAALZHNjbQAAAQgAAALyZGVzYwAAA/wAAABvZ1hZWgAABGwAAAAUd3Rw dAAABIAAAAAUclhZWgAABJQAAAAUYlhZWgAABKgAAAAUclRSQwAABLwAAAAOY3BydAAABMwAAAA4 Y2hhZAAABQQAAAAsZ1RSQwAABLwAAAAOYlRSQwAABLwAAAAObWx1YwAAAAAAAAARAAAADGVuVVMA AAAmAAACfmVzRVMAAAAmAAABgmRhREsAAAAuAAAB6mRlREUAAAAsAAABqGZpRkkAAAAoAAAA3GZy RlUAAAAoAAABKml0SVQAAAAoAAACVm5sTkwAAAAoAAACGG5iTk8AAAAmAAABBHB0QlIAAAAmAAAB gnN2U0UAAAAmAAABBGphSlAAAAAaAAABUmtvS1IAAAAWAAACQHpoVFcAAAAWAAABbHpoQ04AAAAW AAAB1HJ1UlUAAAAiAAACpHBsUEwAAAAsAAACxgBZAGwAZQBpAG4AZQBuACAAUgBHAEIALQBwAHIA bwBmAGkAaQBsAGkARwBlAG4AZQByAGkAcwBrACAAUgBHAEIALQBwAHIAbwBmAGkAbABQAHIAbwBm AGkAbAAgAEcA6QBuAOkAcgBpAHEAdQBlACAAUgBWAEJOAIIsACAAUgBHAEIAIDDXMO0w1TChMKQw 65AadSgAIABSAEcAQgAggnJfaWPPj/AAUABlAHIAZgBpAGwAIABSAEcAQgAgAEcAZQBuAOkAcgBp AGMAbwBBAGwAbABnAGUAbQBlAGkAbgBlAHMAIABSAEcAQgAtAFAAcgBvAGYAaQBsZm6QGgAgAFIA RwBCACBjz4/wZYdO9gBHAGUAbgBlAHIAZQBsACAAUgBHAEIALQBiAGUAcwBrAHIAaQB2AGUAbABz AGUAQQBsAGcAZQBtAGUAZQBuACAAUgBHAEIALQBwAHIAbwBmAGkAZQBsx3y8GAAgAFIARwBCACDV BLhc0wzHfABQAHIAbwBmAGkAbABvACAAUgBHAEIAIABHAGUAbgBlAHIAaQBjAG8ARwBlAG4AZQBy AGkAYwAgAFIARwBCACAAUAByAG8AZgBpAGwAZQQeBDEESQQ4BDkAIAQ/BEAEPgREBDgEOwRMACAA UgBHAEIAVQBuAGkAdwBlAHIAcwBhAGwAbgB5ACAAcAByAG8AZgBpAGwAIABSAEcAQgAAZGVzYwAA AAAAAAAUR2VuZXJpYyBSR0IgUHJvZmlsZQAAAAAAAAAAAAAAFEdlbmVyaWMgUkdCIFByb2ZpbGUA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFhZWiAAAAAA AABadQAArHMAABc0WFlaIAAAAAAAAPNSAAEAAAABFs9YWVogAAAAAAAAdE0AAD3uAAAD0FhZWiAA AAAAAAAoGgAAFZ8AALg2Y3VydgAAAAAAAAABAc0AAHRleHQAAAAAQ29weXJpZ2h0IDIwMDcgQXBw bGUgSW5jLiwgYWxsIHJpZ2h0cyByZXNlcnZlZC4Ac2YzMgAAAAAAAQxCAAAF3v//8yYAAAeSAAD9 kf//+6L///2jAAAD3AAAwGz/4QBARXhpZgAATU0AKgAAAAgAAYdpAAQAAAABAAAAGgAAAAAAAqAC AAQAAAABAAAC0KADAAQAAAABAAAADwAAAAD/2wBDAAMCAgICAgMCAgIDAwMDBAcEBAQEBAgGBgUH CgkKCgoJCQkLDA8NCwsPDAkJDRIODxAQERERCg0TFBMRFA8RERH/2wBDAQMDAwQEBAgEBAgRCwkL ERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERH/wAARCAAP AtADASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIE AwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJico KSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZ mqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6 /8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAEC AxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNE RUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmq srO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEA PwD4Eooorzz8/CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooA/9kKZW5kc3RyZWFtCmVuZG9iagoxMzYgMCBvYmoKMjIyMQplbmRvYmoK MTQwIDAgb2JqCjw8IC9MZW5ndGggMTQxIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJl YW0KeAGdV8luG0cQvfdX1LEJeEbTPSt5Siw4CZKLAzMQENMHh7EcJqEcW8zymfmkvF5ezXAZRRYk oIu91PLqVXXPR/lePkqFv95X0jaVfHonN3InV9f3Trb34uR+e7p+K1XZyS7s8WmPE2cu7otH48oO dlz8WThpfPjf7uX5WtyQZwfpSy/emfVerr5yZYX961t5LfaXhRRV6cQeDn9QXF1ddZR/p/CBwt8L +OiNfcsJPadCece1dxQOC3kj62/lxTrCou76ppO6M9nfJvvbSNOUy8rXrbheotN+4vSWWj98is6I VTtfLAy8E7u7g8UYmC5x727/TDw1VBQcBZ0pgiogg5XgTRQSVkVWrVqamejaflm2UlfIhwn5mMSH edel0GqGZl2/kPWvCaTAHpysh0a6rhPnu0wgQ3IEblWRRJEzExLgXOuC1cCCukuoYux96YamhdAm 001ZGVIBqEboAqhuCCACujgjcQJQ3HzNGW5+C4LEPWk0VjwAvJjqOadq15dDVfdTp0D6xE9XFcC/ bYM7rvDNCr58lvamG8p+8B7aE/sRsrIfypLqL2P2YeM9Y04UxszPXALh1bKJ2QnAdshPPdQs7vPy jRlC9ftlVS5d46TrQfnYDVDtUpm4YZo8LENhSp7PlMEYSzhTppsEkZgLT9uFAT8hrBKHIamASJnK i+PNJOdBibE/5ROpfqDrHwJBXakTiAVfkt3UErAV4EUr7+NoLEmyy/PH62Kf5XlorvuyFjvmI69k L4yqRlqiCbU50REXXh106fBn3nyPUkatWNgplh5BXtN19MFjdXRVg8PZFCXD34TOkKYqIr9ZTEgy bcsovtmktrnFMakGfVlVt7Sx0qlHJ9XRLbr8L5VxInVSZAztPcav4WraufWayrhVc/SS7YFbDwRP 1f9Gw5rHA/D0IdU4VPSozyj4ieTqshf7Y3bsFZVvLLptgn1IgrFPgn04gT1ch4rYCLtK2Vp0NGJF j07HnCj0wuz7GewFMWSRKbkUdk3EXwxSl6j2/2HGtQ7NdVMOCV7XDVVZR8eKc6i/I67fUKClja05 peSLmJsLV/pDVHd4ksTrnFxPoMd8GpteHaDCytPc54LO7Bh7DvpcF1JyFrfMi6K/J+vHZkJQHg1/ HV4ROFXUTT+H/QWan9f7Ec3NI68M1yxnIRdCbuxKM/xUyIWQj8QvyG9CT3zPG8McqsZqerQAAqld eFkFVJ1zbCNTSo8dJfURbV/PSS1a3BAEeVofcf0yvSwucFoBBqe1balAD47HEb6XhE3Jx4uTIxst f+PCLXxbNolvM9U+QjNKBCl31pnr0Ix3PVJweh1qpzzi6dwtaE6fNniwzrUGsXgYJ3MX3zbpzX8M IzuB2BdEh28GbiQbbzmxPat2ZgCjPv4e+LCLH218l08r1C9rGbqHH3XT7zJcrvHjA3YRt4tPqCAg qtB3krinkCoDi2NWEmUwhVYWz+U9YNcP+Vpa4/UzCeo/GzfLuQplbmRzdHJlYW0KZW5kb2JqCjE0 MSAwIG9iagoxMTE3CmVuZG9iagoxMzggMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAxMzkg MCBSIC9SZXNvdXJjZXMgMTQyIDAgUiAvQ29udGVudHMgMTQwIDAgUiAvTWVkaWFCb3gKWzAgMCA3 MjAgNTQwXSA+PgplbmRvYmoKMTQyIDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9D b2xvclNwYWNlIDw8IC9DczEgNyAwIFIgL0NzMiA4IDAgUiA+PiAvRm9udCA8PAovRjYuMCAxNCAw IFIgL0Y0LjAgMTIgMCBSIC9GMy4wIDExIDAgUiAvRjIuMCAxMCAwIFIgL0YxLjAgOSAwIFIgPj4g Pj4KZW5kb2JqCjE0NSAwIG9iago8PCAvTGVuZ3RoIDE0NiAwIFIgL0ZpbHRlciAvRmxhdGVEZWNv ZGUgPj4Kc3RyZWFtCngBlZJPTwIxEMXv+ynekU3c0g5bdrmKqOhBxU1INB5wXeJG/khZSfz2lt1O EcRE08M07evM701nhTusIO1KSELHEqbAGAu0+2uFfA2FdX54P4UUXZRbDTUaBRUc07VvC5MX79XH ZAZT2krbKtuldB3yOdrDuSKcLWuQvWtNOtgXNG/rQrb6qJhNqnJT9JezpSnnRWXKvKmi6uSRAiWx 6JKGJpEmdbbTDCp11ykSIdNuV8WwWJllOdfCsiGb4hGtfohICkJryZsRbwYIg/pqHNpeWMmFiycu wsWhiwt+WbmDgg9MGQZNmXmIJ2RXGGR1L7yJOEVsEW0rLDw5eBtVj0SSdgjU8/DB3+Ab6BvH8sws 6x3VZsJYTFyyyrfDmvofsFZCx6ltey/40e0XTm8mvJs6PiaIPILnrNw/sDTKPZ3xosifHXW600n2 LH931lFSJJp/o5nIyI4PkRSS7KwRNb+RCul/41o4KzwXl+zRmzXs8s3z7A9T0HpwSQ6T3b9yNv90 xife8ec3S8HdF1cJ0e4KZW5kc3RyZWFtCmVuZG9iagoxNDYgMCBvYmoKNDAwCmVuZG9iagoxNDQg MCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAxMzkgMCBSIC9SZXNvdXJjZXMgMTQ3IDAgUiAv Q29udGVudHMgMTQ1IDAgUiAvTWVkaWFCb3gKWzAgMCA3MjAgNTQwXSA+PgplbmRvYmoKMTQ3IDAg b2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCAvSW1hZ2VCIC9JbWFnZUMgL0ltYWdlSSBdIC9D b2xvclNwYWNlIDw8IC9DczEgNyAwIFIKL0NzMiA4IDAgUiA+PiAvRm9udCA8PCAvRjguMCA1NiAw IFIgL0Y1LjAgMTMgMCBSID4+IC9YT2JqZWN0IDw8IC9JbTEyIDE0OCAwIFIKPj4gPj4KZW5kb2Jq CjE0OCAwIG9iago8PCAvTGVuZ3RoIDE0OSAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0lt YWdlIC9XaWR0aCA3MjAgL0hlaWdodCAxNSAvSW50ZXJwb2xhdGUKdHJ1ZSAvQ29sb3JTcGFjZSA1 OCAwIFIgL0ludGVudCAvUGVyY2VwdHVhbCAvQml0c1BlckNvbXBvbmVudCA4IC9GaWx0ZXIgL0RD VERlY29kZQo+PgpzdHJlYW0K/9j/4AAQSkZJRgABAQAAAQABAAD/4gVASUNDX1BST0ZJTEUAAQEA AAUwYXBwbAIgAABtbnRyUkdCIFhZWiAH2QACABkACwAaAAthY3NwQVBQTAAAAABhcHBsAAAAAAAA AAAAAAAAAAAAAAAA9tYAAQAAAADTLWFwcGwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAtkc2NtAAABCAAAAvJkZXNjAAAD/AAAAG9nWFlaAAAEbAAAABR3dHB0 AAAEgAAAABRyWFlaAAAElAAAABRiWFlaAAAEqAAAABRyVFJDAAAEvAAAAA5jcHJ0AAAEzAAAADhj aGFkAAAFBAAAACxnVFJDAAAEvAAAAA5iVFJDAAAEvAAAAA5tbHVjAAAAAAAAABEAAAAMZW5VUwAA ACYAAAJ+ZXNFUwAAACYAAAGCZGFESwAAAC4AAAHqZGVERQAAACwAAAGoZmlGSQAAACgAAADcZnJG VQAAACgAAAEqaXRJVAAAACgAAAJWbmxOTAAAACgAAAIYbmJOTwAAACYAAAEEcHRCUgAAACYAAAGC c3ZTRQAAACYAAAEEamFKUAAAABoAAAFSa29LUgAAABYAAAJAemhUVwAAABYAAAFsemhDTgAAABYA AAHUcnVSVQAAACIAAAKkcGxQTAAAACwAAALGAFkAbABlAGkAbgBlAG4AIABSAEcAQgAtAHAAcgBv AGYAaQBpAGwAaQBHAGUAbgBlAHIAaQBzAGsAIABSAEcAQgAtAHAAcgBvAGYAaQBsAFAAcgBvAGYA aQBsACAARwDpAG4A6QByAGkAcQB1AGUAIABSAFYAQk4AgiwAIABSAEcAQgAgMNcw7TDVMKEwpDDr kBp1KAAgAFIARwBCACCCcl9pY8+P8ABQAGUAcgBmAGkAbAAgAFIARwBCACAARwBlAG4A6QByAGkA YwBvAEEAbABsAGcAZQBtAGUAaQBuAGUAcwAgAFIARwBCAC0AUAByAG8AZgBpAGxmbpAaACAAUgBH AEIAIGPPj/Blh072AEcAZQBuAGUAcgBlAGwAIABSAEcAQgAtAGIAZQBzAGsAcgBpAHYAZQBsAHMA ZQBBAGwAZwBlAG0AZQBlAG4AIABSAEcAQgAtAHAAcgBvAGYAaQBlAGzHfLwYACAAUgBHAEIAINUE uFzTDMd8AFAAcgBvAGYAaQBsAG8AIABSAEcAQgAgAEcAZQBuAGUAcgBpAGMAbwBHAGUAbgBlAHIA aQBjACAAUgBHAEIAIABQAHIAbwBmAGkAbABlBB4EMQRJBDgEOQAgBD8EQAQ+BEQEOAQ7BEwAIABS AEcAQgBVAG4AaQB3AGUAcgBzAGEAbABuAHkAIABwAHIAbwBmAGkAbAAgAFIARwBCAABkZXNjAAAA AAAAABRHZW5lcmljIFJHQiBQcm9maWxlAAAAAAAAAAAAAAAUR2VuZXJpYyBSR0IgUHJvZmlsZQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWFlaIAAAAAAA AFp1AACscwAAFzRYWVogAAAAAAAA81IAAQAAAAEWz1hZWiAAAAAAAAB0TQAAPe4AAAPQWFlaIAAA AAAAACgaAAAVnwAAuDZjdXJ2AAAAAAAAAAEBzQAAdGV4dAAAAABDb3B5cmlnaHQgMjAwNyBBcHBs ZSBJbmMuLCBhbGwgcmlnaHRzIHJlc2VydmVkLgBzZjMyAAAAAAABDEIAAAXe///zJgAAB5IAAP2R ///7ov///aMAAAPcAADAbP/hAEBFeGlmAABNTQAqAAAACAABh2kABAAAAAEAAAAaAAAAAAACoAIA BAAAAAEAAALQoAMABAAAAAEAAAAPAAAAAP/bAEMAAwICAgICAwICAgMDAwMEBwQEBAQECAYGBQcK CQoKCgkJCQsMDw0LCw8MCQkNEg4PEBAREREKDRMUExEUDxEREf/bAEMBAwMDBAQECAQECBELCQsR EREREREREREREREREREREREREREREREREREREREREREREREREREREREREREREREREf/AABEIAA8C 0AMBIgACEQEDEQH/xAAfAAABBQEBAQEBAQAAAAAAAAAAAQIDBAUGBwgJCgv/xAC1EAACAQMDAgQD BQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEUMoGRoQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygp KjQ1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJma oqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+fr/ xAAfAQADAQEBAQEBAQEBAAAAAAAAAQIDBAUGBwgJCgv/xAC1EQACAQIEBAMEBwUEBAABAncAAQID EQQFITEGEkFRB2FxEyIygQgUQpGhscEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3ODk6Q0RF RkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqy s7S1tre4ubrCw8TFxsfIycrS09TV1tfY2dri4+Tl5ufo6ery8/T19vf4+fr/2gAMAwEAAhEDEQA/ APgSiiivPPz8KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigD/2QplbmRzdHJlYW0KZW5kb2JqCjE0OSAwIG9iagoyMjIxCmVuZG9iagox NTIgMCBvYmoKPDwgL0xlbmd0aCAxNTMgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVh bQp4Ab1XTW/UMBC9+1cM6iWR2GycD2+2JwRqDxxARSs40B5K6ZZFtKXdAOq/Z/zxxmncXboUoYLi je2Z8XtvxpMbOqIbKvlvVpXUNiXdntMHuqLpq7WmszVpWp+N55dUFoZWdk3l12jS6sF1bqubWbEf 7X5ONDWV/Xd2SS8XpLvwtqNZUVGl1eKSpoe6KHn9YkkfKfuS06QsNGV9/x3D/enUYPwNg2sMfuUc Y6WyU7yQfTIorjB3jkGf0wktXtPBwsEi4VaNodqoEG8T4m2oaYp5WdUt6Rm5oKtB0Gewen3rgqFM /LzIFUdH2eqKPbqDyRTWri6fUwULJQYaA3kzsaYYGZ6x0biBx2oSTIuVZng6S3tdUt01ZIwhXRlm XgXmHatWFKVj35E9YI/3tboM9NXGw8FPRqIwRmuatZ7DZgDHIqe5LjqHgjs8Tnq5CvB4PhiWa+bT Lbm+uMtVZMTFbN0Z4yOPWvURM6Z2X8lurOaSuJnFrgk0VoFGfjrZmYKZbBrP44whdeLLnuW0+OoF IYAModhgsm6slI23xqZFyu9zalvLvWecB4wDE8aDT+7UKtsnHD88/QRla6xM9/5Mpiho7DjrOX2c A9kGB2KwlymfMBzN57DpzltWWbpJ1sbtx/lQZJ4MIeQRuFkqTPnvqWDBuAQdUvEGmHHVcPj8CE8W Iv8eEPE2TOxCRARnFZiAGzYfNc2iYrVaqbJiE4BCjnFptn8TfjY1I9R1Rannbe2zLIp17zFiTW2a tpixTW9tiFCqHFGMCAaykPMGPauo8GQJcAQiAL7HyrHjqD7JFgkAxUIC6FFQYN7zKfmj7H3iCMdC vhPcb7hHfOKj9/fJIGvDlMpgHHt92ecEQlxwIsawQ04bIo+2kHuwmaIuMKSJz1MnCpeYPZb/70ri RoHdL4a65crN1ZBzRk0Po76e7aKvaNIVQ7aZCuyP1ZBiNTwQFPrTXA1LZoq1LAXTQFJEAhJQJp+a 4hZllY0VB7fH2c6yQO/CSpK9G5W9vewqaWT4krY3vm9kRjegtlXFk87t18OkK1uGthWqMeldl9bd QPqgQIiakXhyBb5DjZbsWcpiebWGHB7Btk/0LWwHZYkXSTCRzkYWErbV7kVgM9uxPGxnO3bZ29iu Ku5Vme3xFfKUFGebT0xxZKUvgLHqC/ZYAKi3EBm6qkCkyv6KSCkkIrZbiE3sDaaCT0SHciBiwkTI 6P+jD5b8zh1G1XITxi3GWB57u9wAsWtxHQbbTOUxvunllh7ctUBNVCCcCvTJElQSULBDiyHlFuVE /EJ9F6FfEPciEx9HvAiWCEzOKcbk+hd1iDm0DnLPbSw54hixotvgliY2maNvfDX+bnLd5f2y3s7m RWu/ENOPXn6vw5dNXZR8ufBHeqbnURlHvwH9GzdiCmVuZHN0cmVhbQplbmRvYmoKMTUzIDAgb2Jq CjEwNTQKZW5kb2JqCjE1MSAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDEzOSAwIFIgL1Jl c291cmNlcyAxNTQgMCBSIC9Db250ZW50cyAxNTIgMCBSIC9NZWRpYUJveApbMCAwIDcyMCA1NDBd ID4+CmVuZG9iagoxNTQgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3Bh Y2UgPDwgL0NzMSA3IDAgUiAvQ3MyIDggMCBSID4+IC9Gb250IDw8Ci9GNy4xIDMwIDAgUiAvRjYu MCAxNCAwIFIgL0Y0LjAgMTIgMCBSIC9GMy4wIDExIDAgUiAvRjIuMCAxMCAwIFIgL0YxLjAgOSAw IFIKPj4gPj4KZW5kb2JqCjE1NyAwIG9iago8PCAvTGVuZ3RoIDE1OCAwIFIgL0ZpbHRlciAvRmxh dGVEZWNvZGUgPj4Kc3RyZWFtCngBnVhNj123Dd3fX6HlzMKyqK8rrQLESYAUKNDAA3SRdJG+TgrX niSecZu/30NJlHjvm4mbwkDmhk+kjqhDUuRH8535aBz+7d6ZFJ15vDd/NT+b12+eyFyeDJmny/n3 n4yz2bzjNb6vIUPbc+te/+X+8XL/66d///jBPL7DTrwL/6PU/lwezOtvHyiYr35pQA4/J5+284Ls un4owexkgjNjRewm+DQh27InE0MxORZTvcX/Pd5v41gNsrOuOqrZFZzFu1A9ZXxNIR+mnfEjPMBb vsJm3W4KDgYZ2Zd3kPVf8dfn3ebsyaRq7nCub5LFOc3dT+Z7c3N3a8Jug7l5d2teYUdzc3l/3z+3 m0+3DMLcPN2av5m7P5mv7+CMl+9lHCAVhu2hukeiPcOjNuSSPcABvgZei80eHsnBJnYYgPNx27Gy 2a0rOVPkw1wBf3e7dbw/C3Az0P4qgsdf5Ouf8vE4zoYz6UNt3af8X2dL51byuwW2ULxNBVf2YNjB xSXg2at1vkTzAcwkG3eADqXaXGPetKwGNgHJ1BRrkIn9bAn+4lUi6TvCEhMaHPkNiP5livlzZ/ab t81Fzrx9o73ZwwReHHYo7TZS9uZhm/tTdrYyXIWSEu6Hj6VlMfPGkAhyscbn6zgpBVuYqEoydvxg 3oInMRabEu4ft98/HkxMZANFliW71xI3JcFPPmell6CXC6gBWV9uQkq2kANp4Pm2XCQbAouX4y6U XhjLQxbrSzJMLr2Bc+P9xPqODwa8ECzJ+XwX3Jjid7sRDsjpCYJujCGBTfPctEdEOu5ESRAXe4hK r0AvEKJ74aASLZWqPLEk4gkaeuxBOTft3Tr8NXyzEEw9wak8QfAOLkN5QiTb9fkuRwZ4VxE6Oepz e4cAj4iieW7vwPw9Z2WvQo+ODKAKvawZsCQT/9Bjf8kpxbqWCALRmzjVuT0BVY4JqAZhRLLuR+ld M4Az2/RQQEBRDXlTDAjB25o0AwKScvSaASFCr6A8MTKJhQi9UBmZsHVIuMiMWFB64ollfUk6AhVD A2fbT6wj8OFOxYCwJBILcr4TA4A5gABBMwBgUyxhXwwAagcCBOUv6IEAUTMf7krZxYpVE5lI5rmH nma+WF/MXwhEb+JUDEAeA/REy/MiWUxVep9hQKwRlQI1TTEggtPYAMyX/Jgc2XpgQHLQOzEgIYYi GLA8IZJ1k1pP7ntZF4kgWMwRnDobxgpUBwYoyWCA6MHzXAUyQh/p3he7u1JA+0zBusRl1CeLIsKF J/tgd37qhIancoFSsmpDq0ZKdZjDsm4fnPA5chk9bgjB8/fRl3ki6ytxkZzGPUVbIgqRwuDhfCru gNU7PBhafVeq3Ryq5LCPC9pRjyauuWGvkQMsLIXQHhnLVEUJ3lEgFYrA1x3jAVkgYuPTqWJKEASH Ml34gbGdNvuMZwIeNHg3gqbTuI940OCaNCbP0cjXqXB6XzUmL6YEk8eTlYifDgOTWtE4Qw6c8Sj1 rj+98ArsnPGIj9SfXtnHzhmfPVJqe3opGXIkP2CU5rDGsm4e9ay/vEQgK7YXKNP1UHdre1cp46X0 ZyA7QWDte3suNmdNGWr9EZZYm7BQskN/Vg1Yc8XGvpHXV66oGeXwLqWcbXQtoOa7lIDC5RZQS1Ya cQFsPe/E3HrM7XiUU4uo85bPEYefOWNd2NGwRI6pZT+wtdpiasIIuLcaWkwtWWqxrqFNcxNa4HOW FlTnLXVUUURng6jSOYfAYI4qzVZK8SqqqIesRNU0hVtq+YYfzT2qRDA2g+EXyNPzFLq+HlUr3wRE OkeVxhRKuooqtCKN0JI+xZQEEbcgPaokB84VLRPLNYKg546GPLWOhv2Omto6GgrUOhrsqWTp1NGQ WJu3Q0j13NGwrdEprDXP+2asi5RGx7KIE6m0jkUji65cdSwRCfrYsUxrEwfa0daxLGRqzapVBFPl lI0J5difeQNzFdkY5matIhyhx/e4pWlsMofBt3wszJHtwJzt3D3w27Ezjt+xCPBDPuZXXiubCkGE +7m8alSRL0BzZxoTVGguLNLNqlNqxdtNqji6V07I/IibNQHdBCfkQ0QxEZGQW2GSyt7GHQxKYmoa EwygPOfjVcPVimvecMIZnkGjOxPycDs2Xwl5vC0ix2xvdOd9RYQtxjkKVhRrAisiPUhCbjGsVqxi hbwVkY5DSzajWKF+VaTj7ppRAZC6EtJxd82QIV/SsSpMawyMixUmJA7JuCcAFsgK3Oq1bxprml5E qkf09vfNgIWeCwOl8b4ZECLyc+y5eBawiJrAAyvGMFW7ueYwhhH3bGtPxR3o3LBnYqx5eRzURngb j9/mLCsBNVzx/0yEPt1ijINp1eMcZf1nfv0oA6APepSl90XV5TuQjbc/MIr6TYzPedPjexlG/UPG VPO3Oa/CKGpN1TDzQn5xYBAPzjBhjNV59o/CGB16GtyHj2VM+TCg7MMyDB1lWIY60oZlcOQa8/1w 8zQnX/OjY9xuXv1dDgDv9KHaRHt5/8OtxqngZPSojAbsxR9E45d32/8M6DJ3eHiYgKZr5Cqfvvj9 vXekRFxa29u8uPf2+puDMz63N18FBoSHveeAEBwbA8LZ0nvkqavhBuLuNNwAWB5uzNZ28zv0TsMN 9uZxuLEk0qJqvdG+wZZYl4bOTwRTT3Cq1tbzOwO97WxtNyUZDd0833PjLXb+8gRyJw83VGu7eWSq 43ADfdppuMEj6vNww/OLVLe225LMEym9ee5pfUomgqEHTAOn9gS/Ag+tLYJQJOKJpceZ/7v/AuwN 8SYKZW5kc3RyZWFtCmVuZG9iagoxNTggMCBvYmoKMjA5MgplbmRvYmoKMTU2IDAgb2JqCjw8IC9U eXBlIC9QYWdlIC9QYXJlbnQgMTM5IDAgUiAvUmVzb3VyY2VzIDE1OSAwIFIgL0NvbnRlbnRzIDE1 NyAwIFIgL01lZGlhQm94ClswIDAgNzIwIDU0MF0gPj4KZW5kb2JqCjE1OSAwIG9iago8PCAvUHJv Y1NldCBbIC9QREYgL1RleHQgL0ltYWdlQiAvSW1hZ2VDIC9JbWFnZUkgXSAvQ29sb3JTcGFjZSA8 PCAvQ3MxIDcgMCBSCi9DczIgOCAwIFIgPj4gL0ZvbnQgPDwgL0YxMC4wIDE2NCAwIFIgL0Y1LjAg MTMgMCBSID4+IC9YT2JqZWN0IDw8IC9JbTE0IDE2MiAwIFIKL0ltMTMgMTYwIDAgUiA+PiA+Pgpl bmRvYmoKMTYyIDAgb2JqCjw8IC9MZW5ndGggMTYzIDAgUiAvVHlwZSAvWE9iamVjdCAvU3VidHlw ZSAvSW1hZ2UgL1dpZHRoIDYwMCAvSGVpZ2h0IDM4MyAvSW50ZXJwb2xhdGUKdHJ1ZSAvQ29sb3JT cGFjZSA1OCAwIFIgL0ludGVudCAvUGVyY2VwdHVhbCAvQml0c1BlckNvbXBvbmVudCA4IC9GaWx0 ZXIgL0RDVERlY29kZQo+PgpzdHJlYW0K/9j/4AAQSkZJRgABAQAAAQABAAD/4gVASUNDX1BST0ZJ TEUAAQEAAAUwYXBwbAIgAABtbnRyUkdCIFhZWiAH2QACABkACwAaAAthY3NwQVBQTAAAAABhcHBs AAAAAAAAAAAAAAAAAAAAAAAA9tYAAQAAAADTLWFwcGwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAtkc2NtAAABCAAAAvJkZXNjAAAD/AAAAG9nWFlaAAAEbAAA ABR3dHB0AAAEgAAAABRyWFlaAAAElAAAABRiWFlaAAAEqAAAABRyVFJDAAAEvAAAAA5jcHJ0AAAE zAAAADhjaGFkAAAFBAAAACxnVFJDAAAEvAAAAA5iVFJDAAAEvAAAAA5tbHVjAAAAAAAAABEAAAAM ZW5VUwAAACYAAAJ+ZXNFUwAAACYAAAGCZGFESwAAAC4AAAHqZGVERQAAACwAAAGoZmlGSQAAACgA AADcZnJGVQAAACgAAAEqaXRJVAAAACgAAAJWbmxOTAAAACgAAAIYbmJOTwAAACYAAAEEcHRCUgAA ACYAAAGCc3ZTRQAAACYAAAEEamFKUAAAABoAAAFSa29LUgAAABYAAAJAemhUVwAAABYAAAFsemhD TgAAABYAAAHUcnVSVQAAACIAAAKkcGxQTAAAACwAAALGAFkAbABlAGkAbgBlAG4AIABSAEcAQgAt AHAAcgBvAGYAaQBpAGwAaQBHAGUAbgBlAHIAaQBzAGsAIABSAEcAQgAtAHAAcgBvAGYAaQBsAFAA cgBvAGYAaQBsACAARwDpAG4A6QByAGkAcQB1AGUAIABSAFYAQk4AgiwAIABSAEcAQgAgMNcw7TDV MKEwpDDrkBp1KAAgAFIARwBCACCCcl9pY8+P8ABQAGUAcgBmAGkAbAAgAFIARwBCACAARwBlAG4A 6QByAGkAYwBvAEEAbABsAGcAZQBtAGUAaQBuAGUAcwAgAFIARwBCAC0AUAByAG8AZgBpAGxmbpAa ACAAUgBHAEIAIGPPj/Blh072AEcAZQBuAGUAcgBlAGwAIABSAEcAQgAtAGIAZQBzAGsAcgBpAHYA ZQBsAHMAZQBBAGwAZwBlAG0AZQBlAG4AIABSAEcAQgAtAHAAcgBvAGYAaQBlAGzHfLwYACAAUgBH AEIAINUEuFzTDMd8AFAAcgBvAGYAaQBsAG8AIABSAEcAQgAgAEcAZQBuAGUAcgBpAGMAbwBHAGUA bgBlAHIAaQBjACAAUgBHAEIAIABQAHIAbwBmAGkAbABlBB4EMQRJBDgEOQAgBD8EQAQ+BEQEOAQ7 BEwAIABSAEcAQgBVAG4AaQB3AGUAcgBzAGEAbABuAHkAIABwAHIAbwBmAGkAbAAgAFIARwBCAABk ZXNjAAAAAAAAABRHZW5lcmljIFJHQiBQcm9maWxlAAAAAAAAAAAAAAAUR2VuZXJpYyBSR0IgUHJv ZmlsZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWFla IAAAAAAAAFp1AACscwAAFzRYWVogAAAAAAAA81IAAQAAAAEWz1hZWiAAAAAAAAB0TQAAPe4AAAPQ WFlaIAAAAAAAACgaAAAVnwAAuDZjdXJ2AAAAAAAAAAEBzQAAdGV4dAAAAABDb3B5cmlnaHQgMjAw NyBBcHBsZSBJbmMuLCBhbGwgcmlnaHRzIHJlc2VydmVkLgBzZjMyAAAAAAABDEIAAAXe///zJgAA B5IAAP2R///7ov///aMAAAPcAADAbP/hAEBFeGlmAABNTQAqAAAACAABh2kABAAAAAEAAAAaAAAA AAACoAIABAAAAAEAAAJYoAMABAAAAAEAAAF/AAAAAP/bAEMAAwICAgICAwICAgMDAwMEBwQEBAQE CAYGBQcKCQoKCgkJCQsMDw0LCw8MCQkNEg4PEBAREREKDRMUExEUDxEREf/bAEMBAwMDBAQECAQE CBELCQsREREREREREREREREREREREREREREREREREREREREREREREREREREREREREREREREREf/A ABEIAX8CWAMBIgACEQEDEQH/xAAfAAABBQEBAQEBAQAAAAAAAAAAAQIDBAUGBwgJCgv/xAC1EAAC AQMDAgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEUMoGRoQgjQrHBFVLR8CQzYnKCCQoWFxgZ GiUmJygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOU lZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T1 9vf4+fr/xAAfAQADAQEBAQEBAQEBAAAAAAAAAQIDBAUGBwgJCgv/xAC1EQACAQIEBAMEBwUEBAAB AncAAQIDEQQFITEGEkFRB2FxEyIygQgUQpGhscEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Sl pqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2dri4+Tl5ufo6ery8/T19vf4+fr/2gAMAwEA AhEDEQA/AP0U1LUPDHhbwmviTX7MC1t4IjK0GnyXUzs5VFCRRI8kjMzKAqqSSelcp4Z+OXwQ8XaZ FrOiX0hs57210+GW68O3tp501zK8MAQTQIXVpI5E3qCisjBiMGuy1TxRoHgvwX/wk3ijWLHS9Msb SNprq9u4raFS21UUyysqKWZlUbmALMBnmvirS/izo+g/Ab4X+H9F+IWjWHiTw34uhvNXstP+JWiW 2/TlvHmnWQpqSxTpJE+0RszfNnIUfNXoZbl0cXBtp35oq90lZ3u3ddLLW+l02uj66VHng3bXX8m/ z/yPszxv4k8CfDnw9L4q8YRxWWlwSxwy3EemyXPltI4RNyxIzBSzKNxGBnkit7+ytL/6Btr/AN+V /wAK+BPGPxEsta8C/ErR9Q+LllrnibWbxksGk+JmhT6BdQDU1uLeW3tZr9HtZEtwsbIBGrCPqzHd TvEXxk8SX2g61pNj8W/DVtqMni4Xt/qlp8UbVodZ0wmcqun2ja5HJp+xniLQLdRBlT/WEfuq7Y8O zlTXv+9fXtb3de/V+b7K0mtvqT112bX3K9/R7L9D71ay0NbhLRrSxE8iNIkRjTeyqVDMB1IBZQT2 3D1FSf2Vpf8A0DbX/vyv+FfI/wAEfEmnax+0F4K1C8+Lln4zuW+Hg0UyQ+MNNa4GoRyySy+fp9vq EvmM0CIWaP7Qu5d5Ybdy/YdePmGCeEqRp817q/bq169L6232OSpTcJcr7L8Un+D0+Rl6npmmx6bd yJp9srLA5DCJQQdp5HFU/FGp+DvBmiXHiLxHFa2tjbFFZltDNJI7sESOOKNWeSR3ZUSNFZ3ZlVQS QK1dW/5Bd5/17v8A+gmvMf2oNQ8B2nwkvrP4irZPpeo3dvbIs3iG10WcTB/NWS0urmSOMXUflGWN S65aLkhckGWYZYrGUsPO9pSSdrXs2r2vZXt307mbaSbfT+v669jrvBvin4f+P7W8u/CvkXI064Fn exTafJbT2k/lpJ5U0MyJJHIEkQlGUMu7BAPFdB/ZWl/9A21/78r/AIV8IaN8V/7D8C6a0n7TEevp oHjmz1DTtM1T4maHF4hm0QIBc295cQX62t0xkZ2USTH5Av3DhF5vUfi1qVx4F8EaY3xmuRqml2/i S31g2Xxn0hZZvN806Z5kzaqrS7WaH58+YoQgkDhvupeHtWpVfsayUOZpX1dlCUr68l72UdkuaVru 13xxxeykt/8ANrz6K/o1tfT9E/7K0v8A6Btr/wB+V/wo/srS/wDoG2v/AH5X/Cvzmg+Mfi2bwF48 067+NrLrWqaJ4ebSJz8XNBWePVYWP9oyQsmp7IYmDD5MLG4Q5Qk/Ns+AfjbqGkfFfRNU1D4yt/wj Vr4s1aSSPVfi1oN3CuizWhW1SWP+05DLIty2/LK7IqgIQBspVfDjFwhUkq8W4JtL+a0IysterfIt N0+ugljU0ny72/Jv/gerttqfoB/ZWl/9A21/78r/AIUf2Vpf/QNtf+/K/wCFfm7pvxa8ZDwP8SrG 6+Nqw32uWukXPhhD8Y9HmvbC7jnk+2A3B1TYNyFWOxYoJFAAgjP7serp45+DOn/FTR9P0H9r1NS8 NXWn3MHiVNa+KFwr2jNdR3tu9rPHcLE78PaHy23LFgFm+cNliuAMRh5OLq81r/DFy0UIzbbTstZO Ef5pxaTK+trWy/4Ov+Wv39tfsv8AsrS/+gba/wDflf8ACj+ytL/6Btr/AN+V/wAKt0V+eXZ2FT+y tL/6Btr/AN+V/wAKP7K0v/oG2v8A35X/AAq3RRdgVP7K0v8A6Btr/wB+V/wo/srS/wDoG2v/AH5X /CrdFF2BU/srS/8AoG2v/flf8KP7K0v/AKBtr/35X/CrdFF2BU/srS/+gba/9+V/wo/srS/+gba/ 9+V/wq3RRdgVP7K0v/oG2v8A35X/AAo/srS/+gba/wDflf8ACrdFF2BU/srS/wDoG2v/AH5X/Cj+ ytL/AOgba/8Aflf8Kt0UXYFT+ytL/wCgba/9+V/wo/srS/8AoG2v/flf8Kt0UXYFT+ytL/6Btr/3 5X/Cj+ytL/6Btr/35X/CrdFF2BU/srS/+gba/wDflf8ACj+ytL/6Btr/AN+V/wAKt0UXYFT+ytL/ AOgba/8Aflf8KP7K0v8A6Btr/wB+V/wq3RRdgVP7K0v/AKBtr/35X/Cj+ytL/wCgba/9+V/wq3RR dgVP7K0v/oG2v/flf8KP7K0v/oG2v/flf8Kt0UXYFT+ytL/6Btr/AN+V/wAKP7K0v/oG2v8A35X/ AAq3RRdgVP7K0v8A6Btr/wB+V/wo/srS/wDoG2v/AH5X/CrdFF2BU/srS/8AoG2v/flf8KP7K0v/ AKBtr/35X/CrdFF2BU/srS/+gba/9+V/wo/srS/+gba/9+V/wq3RRdgVP7K0v/oG2v8A35X/AAo/ srS/+gba/wDflf8ACrdFF2BU/srS/wDoG2v/AH5X/Cj+ytL/AOgba/8Aflf8Kt0UXYFT+ytL/wCg ba/9+V/wo/srS/8AoG2v/flf8Kt0UXYFT+ytL/6Btr/35X/Cj+ytL/6Btr/35X/CrdFF2BU/srS/ +gba/wDflf8ACj+ytL/6Btr/AN+V/wAKt0UXYFT+ytL/AOgba/8Aflf8KP7K0v8A6Btr/wB+V/wq 3RRdgVP7K0v/AKBtr/35X/Cj+ytL/wCgba/9+V/wq3RRdgVP7K0v/oG2v/flf8KP7K0v/oG2v/fl f8Kt0UXYFT+ytL/6Btr/AN+V/wAKP7K0v/oG2v8A35X/AAq3RRdgVP7K0v8A6Btr/wB+V/wo/srS /wDoG2v/AH5X/CrdFF2BU/srS/8AoG2v/flf8KP7K0v/AKBtr/35X/CrdFF2BU/srS/+gba/9+V/ wo/srS/+gba/9+V/wq3RRdgVP7K0v/oG2v8A35X/AAo/srS/+gba/wDflf8ACrdFF2Bl6npmmx6b dyJp9srLA5DCJQQdp5HFFWdW/wCQXef9e7/+gmitqexLMmPw3qpjUw+ONct49o2QpFZFYx2UFrbd gdOefXmnf8I3rP8A0UDX/wDvzYf/ACNW3bDbbxDGMIBjGMcemB/IfQV8R6z4/wDG3iHxxq1jJ4lM sPiDx1Y2OY/hL4hYvb6ZsuPklE5Uqk0EsckQDMd0snyIxC+jgMveLm4p2tZ7N9Unsnsnf5fNa06T lFzvov8AJv8AJM+wf+Eb1n/ooGv/APfmw/8Akaj/AIRvWf8AooGv/wDfmw/+Rq+Wvjh8O5fh1+05 8L/jYvh3WrjTr3xCNL1nxLaeIJp753ugYbS0ksnCRRWgkkVf3O4sgbcA5Bk4D4lftaeCvGf7S/w0 X/hYEtpofhbxhd2V3oa2Nz+5dEe2ju52Ee2R5JHdY1jLCOMgthpHVPQw2QTxSpywz5lJNvS9mr6a N76WvZ6q6Rs8JJpzi7pRcvnaWnW1+X8V10PuT/hG9Z/6KBr/AP35sP8A5Go/4RvWf+iga/8A9+bD /wCRq36K8HlXY47nPSeG9V8tjN441y4j2nfC8VkFkHdSVtt2D0459Oad/wAI3rP/AEUDX/8AvzYf /I1bdyN1vKMZyhGMZzx6YP8AI/Q1FqTXq6ddNpqK92IHNurHAaTadoJ7DOKTSS2KirtK5wepeKvB +j+I/wDhD9X/AGg4LHXjEZ/7LudQ0iK88sIXL+S0AfbsVmzjGFJ6CulHhzWGAZfiFrxB5BENhz/5 LV4t+znYfDrWP2XFs/H0Gk3onF03j5NTVHc6oJC139u3c+cHA5b5gBGVONpqv45+I/ivRPH9ivgf x5rt5pVh4l0jQ9T0qPQLSLSNJguRAnlXdxcAXUt0wnEg+zv+6HlrLGm4O/rTyuLxEsLS+KLs29nq krNLS7el9NtbtI1dK9+XTlve/l+u+j2dld3Pcv8AhG9Z/wCiga//AN+bD/5Go/4RvWf+iga//wB+ bD/5Gr508K/Ez406bcaN4h8VfEEeIkufiRrHg2XSLLRLa0triCCO/aJl+/MJBJaoFPm4CEBxIwMj dHo3j/4gW/wcm/aIt/iZH4ih1HwZda3D4Vm022FrFfLD56x20sKpOEi2SxPHK0znBO5CpqamUzgu bmi1prru72W27t108ypYaaqezurt2Xn7zj+ae9tNj0Xxz4h0L4aaZa6v46+Meq6Ra317Dptq00Ni WnuJWCpGiLalmJJycDhQzHCqSMvwt8RfBHjeXS4/Cfxu1fVBrdxe22nyW9natFcvZkC42SfY9pVS Rhs7XByhYc14l4uvfjBffCe9v/iP428L+INE1q58Natof2PVYr27ydXs98qGLT7JfszLJHtysjqe sh3YHN3fjz4u+BIPGEPw98a6Zo2nvcfEPWI7eTQ0uXS6sb5ZBIXaQA5WUqihQqtlnEwwg7qWSU3T alJc6cldP3fdin/K3dXd/S3ma08IqsI8j95yUfLWLfb0/HyPsj/hG9Z/6KBr/wD35sP/AJGo/wCE b1n/AKKBr/8A35sP/kavnzVfiT8ZPDEPiPRm8bya7qM3hPQfEEM40m1jksXu72W2ulsYET96/loG ghl852l2rmTcEPqHwFfx5e6b4g1fxl4t8U63ZXGryRaC3iHRrfS7oWSKoDvbJa28iM0hlH71RuWN GVVDc+fXyuVGnKpKUbL112208+tr2dr2OWVNxgp33t+MVJfgzs/+Eb1n/ooGv/8Afmw/+RqP+Eb1 n/ooGv8A/fmw/wDkavFNK+JXjB/jXoFrp3j/AFvxF4W1vXdV0W9aTRLKz0W2lgindLe0kIF5LNE1 uEebdLA5MgDKy+WnUftBa18SdDTTdQ8Hah4gttFtLW7udabwyumT6tAqopjnFrfROtxbqQ4dImSX Lpt3crUPLpKrTpSlFc6vd3SW+91o9O3Yv2Evaeyvr8+9vW91ta99Nz0P/hG9Z/6KDr//AH5sP/ka sDwTrOkfEfR5PEPgf4v6trOmR3c1j9rtobExPLC5SQIxtQHUMDh1yrDlSQc14h4l+LXjyysPHt/o vxcvXh0Lxp4cj0ZprDT1a4sdRSyd7VlNsCU23cpU4EwEa5c4bLfhzrPjfwnrR1LSvGkb6fr3xb8Q 6I/hyWzgWGSEz3sr3Al2mfzo2iMhIcR+Uu0x7syN1LJ2qMpzavpbf+WMrP3e012Sad9NSvq79j7W /Vfdyyk/novLfqfSH/CN6z/0UDX/APvzYf8AyNR/wjes/wDRQNf/AO/Nh/8AI1fPFv8AF/4leCdF 1PTviH4h1+18RXUulQtdalb6XPpFjbXV/wDZJNR0+6tYYxJABJGRHdjzIyYi4ZSxbovHDfGfwd4j 8D+DLD49NfW3ibxXJYXV1c+HrA6rb2j6fPKib0Vbfcr20rK/2YZLJuDLG6y5vKJKXK5RtrZ6tOyT dmk9r/eS6DTabWib67JXvt/Wj2aZ6fpksWsa5rHhvTvifr82o6A8KajD9ks18gyxiSMbjaBWyhB+ UnHQ4PFa3/CN6z/0UHX/APvzYf8AyNXzXq/jv49WHxHl+H//AAuG2Wyj+Idj4Ya9/wCEctRdmzuN GN2oQkmMShlYljGwaVlZVSNTA0Ojar8V/GXxS8F2X/C39SSaxk8WafaXg06xks9QOn3MEMVxPAkS 7ywlaKURyR/6k+UYSz5uWT+6p88UnHm6vTk5/wCVb9t1frZs0lhmrXktVfr15rdOvK2fQnhWWLxt 4fs/FPhj4n6/e6XqCl7ef7JZx7wGKk7XtQw5UjkDpWt/wjes/wDRQNf/AO/Nh/8AI1fLehfHL4se J/h3b6hL8QhomteHvhjD47a5ewszD4guN84kSdGiOy3X7Oit5BicG4zuGFB07j4ofHG1vPG3inWf HyWtp4W8U+HLaDQbXQ7dI/s+oCwM1tPJJvlfYt2wDI0bGRWbIRliTSeRVPaypqUVZ21u/tKC15db tr9bPQUsNNPlb17f+Av0+0vv9T6R/wCEb1n/AKKBr/8A35sP/kaj/hG9Z/6KBr//AH5sP/kat+iv E5V2OW5gf8I3rP8A0UDX/wDvzYf/ACNR/wAI3rP/AEUDX/8AvzYf/I1b9FHKuwXMD/hG9Z/6KBr/ AP35sP8A5Go/4RvWf+iga/8A9+bD/wCRq36KOVdguYH/AAjes/8ARQNf/wC/Nh/8jUf8I3rP/RQN f/782H/yNW/RRyrsFzA/4RvWf+iga/8A9+bD/wCRqP8AhG9Z/wCiga//AN+bD/5Grfoo5V2C5gf8 I3rP/RQNf/782H/yNR/wjes/9FA1/wD782H/AMjVv0Ucq7BcwP8AhG9Z/wCiga//AN+bD/5Go/4R vWf+iga//wB+bD/5Grfoo5V2C5gf8I3rP/RQNf8A+/Nh/wDI1H/CN6z/ANFA1/8A782H/wAjVv0U cq7BcwP+Eb1n/ooGv/8Afmw/+RqP+Eb1n/ooGv8A/fmw/wDkat+ijlXYLmB/wjes/wDRQNf/AO/N h/8AI1H/AAjes/8ARQNf/wC/Nh/8jVv0Ucq7BcwP+Eb1n/ooGv8A/fmw/wDkaj/hG9Z/6KBr/wD3 5sP/AJGrfoo5V2C5gf8ACN6z/wBFA1//AL82H/yNR/wjes/9FA1//vzYf/I1b9FHKuwXMD/hG9Z/ 6KBr/wD35sP/AJGo/wCEb1n/AKKBr/8A35sP/kat+ijlXYLmB/wjes/9FA1//vzYf/I1H/CN6z/0 UDX/APvzYf8AyNW/RRyrsFzA/wCEb1n/AKKBr/8A35sP/kaj/hG9Z/6KBr//AH5sP/kat+ijlXYL mB/wjes/9FA1/wD782H/AMjUf8I3rP8A0UDX/wDvzYf/ACNW/RRyrsFzA/4RvWf+iga//wB+bD/5 Go/4RvWf+iga/wD9+bD/AORq36KOVdguYH/CN6z/ANFA1/8A782H/wAjUf8ACN6z/wBFA1//AL82 H/yNW/RRyrsFzA/4RvWf+iga/wD9+bD/AORqP+Eb1n/ooGv/APfmw/8Akat+ijlXYLmB/wAI3rP/ AEUDX/8AvzYf/I1H/CN6z/0UDX/+/Nh/8jVv0Ucq7BcwP+Eb1n/ooGv/APfmw/8Akaj/AIRvWf8A ooGv/wDfmw/+Rq36KOVdguYH/CN6z/0UDX/+/Nh/8jUf8I3rP/RQNf8A+/Nh/wDI1b9FHKuwXMD/ AIRvWf8AooGv/wDfmw/+RqP+Eb1n/ooGv/8Afmw/+Rq36KOVdguYH/CN6z/0UDX/APvzYf8AyNR/ wjes/wDRQNf/AO/Nh/8AI1b9FHKuwXOek8N6r5bGbxxrlxHtO+F4rILIO6krbbsHpxz6c0Vu3I3W 8oxnKEYxnPHpg/yP0NFCSWwBbDbbxDGMIBjGMcemB/IfQV45p3wj+Lmk3Nld2Hjz4cxS6ddXt9bN /wAIRqbbJryRpLl8HWiCXd3POcbiFwDivZrfTNOaCNn062LFATmFc5x/uj+Q+grB1PxZ8PdHuNQt tRmtYpNKnsrW7AsnYRy3kixW0eVQgs7ugwMld6lsBgT1YetWheNHW/kn5dU+9vO9i4SktI/5/wBb ninhT9mHxj4J1R9W8OeMPAcDNfS6olpN4Z1u5sYbuRizXEVnLrzQRS5Jw6IrKCQCASK3/Evwc+K/ i/xF4b8V+IvHXw5u9V8I3Et3o1x/whOpx/ZZJE2O21NbCvlRjDhgO1eoeIvE3w+8J6toGheIbvTr PUfFF6dP0i1aDdJdzKjSMFVVJACqSWOFGVBILKDkH4pfCIeNG8AHUbcaut4NNJOmTfZBeGLzha/b PL+z/aTGd/keZ5mOdtdqxuYVJKotWk7PlT02ettuj+42dWs25vqnd26O6fTZ6p/PzOyop/8AZWl/ 9A21/wC/K/4Uf2Vpf/QNtf8Avyv+FeScxBcjdbyjGcoRjGc8emD/ACP0NRalaz32nXVla6lc6dNc QPFHeWyxtNbMykCRBIjoWUncA6MuQMqRkGxcaZpywSMmnWwYISMQrnOP90/yP0NPfTdJjUu+n2iq oySYlAA/Ki9tRrc8Ou/2WdJ1DxWnju/+JWvXPiWORJk1mbwz4Ue+V0AVGE50jzAVCqAc5AAA6VV1 /wDZE8K+K9bl8S+KfHOqaxq85Qy6hqHhPwlcXMhRQq7pX0cscKqgZPAAHauz8IfGDwf4zvtGhsvh /r9pp/iaaVdB1e502A2OpxRxyymdJI5HMSMsWUWdYpHDgqhCuU9J/srS/wDoG2v/AH5X/CvUqY3G 0JJSdmlZaR0XbburNdGrPVG8q1WLs3rtstv8jwCD9j3wfavayWvjTUYXsbw6jatH4R8JKYLk7MzI Ro/yyHy48uMN8i88CtXRv2aLfw74gv8AxZ4f+K/iXTNc1Uub/U7Pw74Whu7su29/NmXSA77mAY7i ckZPNe1f2Vpf/QNtf+/K/wCFH9laX/0DbX/vyv8AhWTzPFSVnJf+Ax/yJdeo1Zv8EeAf8Me+D/7M u9E/4TPUf7O1C5W8u7T/AIRHwl5NxMu4LJIn9j7Wcb3wxBI3Hnk1n/8ADDfwv/6C3/lj+Dv/AJTV 7U2tWem69d6b4n8MWOkWEt9bafod880Up1eWWIuyrEq7oyjK64bqFLcCul/srS/+gba/9+V/wrX+ 1MbDXm38o9l5b2t5rZlPE1lo359P6/4J82eKP2MNO1LRr638M/EqTTdVu7WCxF1e+BvC91C1vE8R WCWKLTYHlhCwooj8wKNqZBVdp0PhP+y14l+GOl3cFr8e9Zsb3UJFe7/4Rfwn4f0axl25CH7J9hmU SYYhnDZYBQeFUD6D/srS/wDoG2v/AH5X/Cj+ytL/AOgba/8Aflf8KTzfFum6MpJxf92P+XkJ4mo4 8j29F6dux4GP2Q/Cq+I/+ExHjjUxr5uzf/2qPCfhL7Z9oLbzN539j7/M3fNuznPOa0vFP7NFv45n srnxt8WPEviCbTWLWUmq+HfC121sSQSYzJpDFCSqk4x90ele1f2Vpf8A0DrX/vyv+Fc1Za1Z69d6 BeeEvDFjrPhvV47iS51qOaKNLXy8CLbEy7pRI28ArwNueQRUxzDFyakmvd2do6aPZ200TsuuyD29 Rvmf5I8x8Q/sq6L4u1KbWPFnxH1zWr+4gW1mutR8MeFLmaSFWDLGzvo5JQMAQpOAQDVqw/Zqh0vx He+MdM+LPiaz1/UojBe6rB4e8LR3lzGduVkmGkB3U7E4JI+VfQV7T/ZWl/8AQNtf+/K/4Uf2Vpf/ AEDbX/vyv+FR/aWJ5eW6tt8Mdu2wvrFS1r/gv66I8O0L9lnSvC+l6nofhr4l69pGm60hi1KzsfDP hW3gvUKlSs0aaQFkBVmGGB4YjvVK2/Y/8I2UOn29n411KCLSbtr/AE9IvCXhJVtLhtm6aIDR/kkP lR5ZcE+WvPyivfv7K0v/AKBtr/35X/Cj+ytL/wCgba/9+V/wqv7UxV3LmV35R/yD6xU7/gj5a+Iv 7EUnjbU7K/sfi8YEfVl1jWxqngXw9eSarMquqNI0VnAGYLNcf69Z1zIG25XnttR/Ze07WNK0vQtX +J/iC+03Q126ZZ3PhrwrLBYjbtxBG2kFYxtGPlA44r2/+ytL/wCgba/9+V/wo/srS/8AoG2v/flf 8Kp5ti3CMHJWjt7sf8vl6aFPFVW029vJHg6fsl+HI7XR7GPx/q623h6drrSIR4V8JhNOlZg7SW6/ 2PiJyyqxZMElQeoqPU/2QvCmtS6hPrHjfU7+XVrlb2/e58JeEpWu513hZZS2jne48yTDNkje3PJr 3z+ytL/6Btr/AN+V/wAKP7K0v/oG2v8A35X/AAqVmmKvfmX3R737d9fUSxFRbP8ABEUcccUaxRIq IgCqqjAUDoAPSnU/+ytL/wCgba/9+V/wo/srS/8AoG2v/flf8K88wGUU/wDsrS/+gba/9+V/wo/s rS/+gba/9+V/woAZRT/7K0v/AKBtr/35X/Cj+ytL/wCgba/9+V/woAZRT/7K0v8A6Btr/wB+V/wo /srS/wDoG2v/AH5X/CgBlFP/ALK0v/oG2v8A35X/AAo/srS/+gba/wDflf8ACgBlFP8A7K0v/oG2 v/flf8KP7K0v/oG2v/flf8KAGUU/+ytL/wCgba/9+V/wo/srS/8AoG2v/flf8KAGUU/+ytL/AOgb a/8Aflf8KP7K0v8A6Btr/wB+V/woAZRT/wCytL/6Btr/AN+V/wAKP7K0v/oG2v8A35X/AAoAZRT/ AOytL/6Btr/35X/Cj+ytL/6Btr/35X/CgBlFP/srS/8AoG2v/flf8KP7K0v/AKBtr/35X/CgBlFP /srS/wDoG2v/AH5X/Cj+ytL/AOgba/8Aflf8KAGUU/8AsrS/+gba/wDflf8ACj+ytL/6Btr/AN+V /wAKAGUU/wDsrS/+gba/9+V/wo/srS/+gba/9+V/woAZRT/7K0v/AKBtr/35X/Cj+ytL/wCgba/9 +V/woAZRT/7K0v8A6Btr/wB+V/wo/srS/wDoG2v/AH5X/CgBlFP/ALK0v/oG2v8A35X/AAo/srS/ +gba/wDflf8ACgBlFP8A7K0v/oG2v/flf8KP7K0v/oG2v/flf8KAGUU/+ytL/wCgba/9+V/wo/sr S/8AoG2v/flf8KAGUU/+ytL/AOgba/8Aflf8KP7K0v8A6Btr/wB+V/woAZRT/wCytL/6Btr/AN+V /wAKP7K0v/oG2v8A35X/AAoAZRT/AOytL/6Btr/35X/Cj+ytL/6Btr/35X/CgBlFP/srS/8AoG2v /flf8KP7K0v/AKBtr/35X/CgBlFP/srS/wDoG2v/AH5X/Cj+ytL/AOgba/8Aflf8KAILkbreUYzl CMYznj0wf5H6Gin3GmacsEjJp1sGCEjEK5zj/dP8j9DRQBZtRttYV24xGoxjGOPTAx+Q+gr4etPh 9438TeO4Li38Nebb+I/H97dL5vxc8RLvg0oGFg8XkFcCe1SSOX5mGY0UKgDL9o2+uWEUEcRivQUQ KQLCfAwPaMfyH0rzv/hUHw1/6DXxW/8AC78Vf/JdenlmNhhZSlK93ta/r0lHqk/vXU3pVVGEoPr+ Vmu673+R8j/FDVfj7D+1R8LfEvjj4Esuqt4tv4dDuP8AhKrN4r+wVCscMMS7vsqxxN5zlyWlkdvu /IiXpvD+tGC4+D0c2PiA37Qo8Ttp/nB7s6aZBcDUQhO42wiwTLgLuG3O75a+qv8AhUHw1/6DXxW/ 8LvxV/8AJdH/AAqD4a/9Br4rf+F34q/+S69iGe4aMKcVC3Iui3akpLeb001S3vutEuqpi6c+ltLf +l+e1pvTy3tovWaKzv7f0/8AuX3/AIAT/wDxFH9v6f8A3L7/AMAJ/wD4ivlDzi5dDdazLtzmNhjG c8emDn8j9DUh6HjPtWXca5YSwSRCK9JdCoBsJ8HI94z/ACP0qLU73w7rWm3ej6xpkt/YX8D211a3 OlTSwzxOpV45EaMhlZSQVIIIJBotfRgj51+GGj6t4X8faDbfB7RfHvhbSNZ8+fxb4K1vSbkaFoe+ CWXztPu5oxEkn2qRFMNtJIkglY+WgjJXhvh18JvGVj4X1vV9Bb4m2fxo/wCEa1HT9US90mz07T7q 9YEGVtUS0hF6zyIrQSm5nePzQzFQJCPoT/hRP7Mf/RvvgX/whoP/AJHo/wCFE/sx/wDRvvgX/wAI aD/5Hr6J5rQ95q95JJtxTel925Xa96zvrZJc2h3vFRu35p7b2beuut776PRed/H/ABn4A+FGvfCz WNc+E3wD8QaVrVpeaFq95aS+EL2wmR7a+ikdobeaNRNdrC12Hlt1d3UlS7bkB4rUPB3h7xH8emvH +EXjyDw1q3xEt9XeBvCOsW+nXVnNopgnnuYVhEOHuyFcTAOBJLvAR5QfpX/hRP7Mf/RvvgX/AMIa D/5Ho/4UT+zH/wBG++Bf/CGg/wDkero5xRp83vTd777q/J15unIrdk3vuKGJjGEoJvVNX66q3fda /wBb/OmvfCTwhbfFXV55PgvrOo+HNF+Jmm3gNz4Qv9QjXTjo7W8wtg8DmS1W6jiXy4d0aCOIhVjV CPXvCHwb0nw98VdS+Hlr4E8PDwRZ6vH8SLCVLWLfb6hMrwLAY8ZBSWOWaOQbdqhI14Qgdb/won9m P/o33wL/AOENB/8AI9Zmg/s0fsp+G7ae00/4C+GJkuLl7pzf+GWvnDuckK88bsieiKQi/wAIFRPN ac6ag5z0iltfZRV/j0d43v3f3qriIzVrvZLbzd3vu1Jr0flri/tX+F7TxDJoF02gnX76xtr37JpG peBbvxJo18XVF8uZraNpLGfcE8u5DKFXzMhxkDiPEfw2v/FPxt1HW/ihp3xK03UftOk6h4Qfw7pF nqFvbxpDD5loupmyleyKXMc/m7ri3jkSUHkMxPsn/Cif2Y/+jffAv/hDQf8AyPR/won9mP8A6N98 C/8AhDQf/I9Z4bMqNCnGEZS0TV+VaXaemuj0s276bWF7eHJyXezWy628/L599rcJ4J8E+B9a8WXd h8YPhDq2o/EWPXNUjk1ubw9dS2eo2EzTCHfqCp9mktPscqR/ZZZCFKbPK3qufFvBfw88R+HtD8A6 b8MPh/4r8NeOYPAHiHRb64PhzUrKyt9XeO3+zu8rxLarK7RSD7SDh9ke52CxivqT/hRP7Mf/AEb7 4F/8IaD/AOR6P+FE/sx/9G++Bf8AwhoP/ketKea0YJrmlZrayt8Mo2S5vh99vl7pa2NIYuMZOWr1 vZ6rr57a6Ly36nzP42+HthrHgzU9T8D/AAx+IPh3w5cQ+GTdaDYaDq2nzTazFfh7u4+ywIssjR2m RJcbTG7iIq7yxqV+g/2fbGw8P+Ofiv4b8PeENV8P+HE162u9Iim0G706zkBsbeK4e3MsaI4M8MpY pncTvOQ4Y6v/AAon9mP/AKN98C/+ENB/8j10ng7wp8Kfh39r/wCFf/DzSfDP9obPtf8AY/hv7F9o 2btnmeVEu7bvfGc43HHU1GLzWlVoTpRcne+/m4b6vbksvJ2MalaMocqbe2/lZffZavu2+tjtaKzv 7f0/+5ff+AE//wARR/b+n/3L7/wAn/8AiK8A5TRorO/t/T/7l9/4AT//ABFH9v6f/cvv/ACf/wCI oA0aKzv7f0/+5ff+AE//AMRR/b+n/wBy+/8AACf/AOIoA0aKzv7f0/8AuX3/AIAT/wDxFH9v6f8A 3L7/AMAJ/wD4igDRorO/t/T/AO5ff+AE/wD8RR/b+n/3L7/wAn/+IoA0aKzv7f0/+5ff+AE//wAR R/b+n/3L7/wAn/8AiKANGis7+39P/uX3/gBP/wDEUf2/p/8Acvv/AAAn/wDiKANGis7+39P/ALl9 /wCAE/8A8RR/b+n/ANy+/wDACf8A+IoA0aKzv7f0/wDuX3/gBP8A/EUf2/p/9y+/8AJ//iKANGis 7+39P/uX3/gBP/8AEUf2/p/9y+/8AJ//AIigDRorO/t/T/7l9/4AT/8AxFH9v6f/AHL7/wAAJ/8A 4igDRorO/t/T/wC5ff8AgBP/APEUf2/p/wDcvv8AwAn/APiKANGis7+39P8A7l9/4AT/APxFH9v6 f/cvv/ACf/4igDRorO/t/T/7l9/4AT//ABFH9v6f/cvv/ACf/wCIoA0aKzv7f0/+5ff+AE//AMRR /b+n/wBy+/8AACf/AOIoA0aKzv7f0/8AuX3/AIAT/wDxFH9v6f8A3L7/AMAJ/wD4igDRorO/t/T/ AO5ff+AE/wD8RR/b+n/3L7/wAn/+IoA0aKzv7f0/+5ff+AE//wARR/b+n/3L7/wAn/8AiKANGis7 +39P/uX3/gBP/wDEUf2/p/8Acvv/AAAn/wDiKANGis7+39P/ALl9/wCAE/8A8RR/b+n/ANy+/wDA Cf8A+IoA0aKzv7f0/wDuX3/gBP8A/EUf2/p/9y+/8AJ//iKANGis7+39P/uX3/gBP/8AEUf2/p/9 y+/8AJ//AIigDRorO/t/T/7l9/4AT/8AxFH9v6f/AHL7/wAAJ/8A4igDRorO/t/T/wC5ff8AgBP/ APEUf2/p/wDcvv8AwAn/APiKANGis7+39P8A7l9/4AT/APxFH9v6f/cvv/ACf/4igDRorO/t/T/7 l9/4AT//ABFH9v6f/cvv/ACf/wCIoA0aKzv7f0/+5ff+AE//AMRR/b+n/wBy+/8AACf/AOIoAuXQ 3Wsy7c5jYYxnPHpg5/I/Q0Vn3GuWEsEkQivSXQqAbCfByPeM/wAj9KKAJLYbbeIYxhAMYxjj0wP5 D6CvEtb/AGu/hHpmsaxo1p4z8IXlxpuq6bpEEY8TWqSXUlzLGk7qnJEcCyhmYZyUkU7SuT7bbDbb xDGMIBjGMcemB/IfQV8WaZrngq78U2Gsav8AtkaRaQXXjDUfEGoInifwqyQrEr21g4/cFi8kCwZG WVQG4V8MPWyrCUq8pOsrpW2v3vbRPdJr1t1OijTUoSk1drb7m+210l8z3TWf2jtEl+Lp+CXgSLQd W8SWUka6mNV8RQ6ZFBuQyGKBNstxdThAHKxwmNQcPKjArWI/7SfjXXPjTffCv4Z/CnQvFWn6Repa anq6+PtPt7iyVWVLiSTTsPcBYnYp0+Yrx1FfM8ieEL3V5fAWofF/4btYR/GD/hZFn4yTxrpIijs2 BkeEx/aftP2rd+7A8sx853gKM9TrXiL9nL4g+N4b86F8Mvhr4j0HxaNS03xxovjrQDDeWsdxHJJN OILiO4eW4jWVBHLC4UyZLjLV7dPKcNDkvDmXLre+jfL7zSlF7trlXvJJ3UtDrqYaEeZRV9NH53lr utWkn15b6p6H3bRRRXxx5hHcjdbyjGcoRjGc8emD/I/Q1HqKahLp9zHpN1b2188LrbTXEDTxRyEH azxq6F1BwSodSRxuHUSXI3W8oxnKEYxnPHpg/wAj9DVfWdR/sjR77Vjbyz/YraS48qGGWZ5Niltq xxI8jk4wFRHYnhVY4BavfQcb3Vjw/wAHfGr4h6pN4n+Hfi8+HNG8bWQvrrw5qi6dM+l65Z2tzJBI 6WxuRIs0bRESQ+eSokjcFlJA7AfGTQPA/hfQZ/iz4os11bUrFL+6n0vRbxbS2idlAmmVWuPssCl1 UyzSBCQx3DkDxXVtWg+IPwwvfD3i7QPF3hbxbY6xe614a1jQvBXie/NhcTTSzqxaXSIDtPnPBJHt ZZIy2SN2Fp+Mr66udS1CfwnpniO5tfFvgaLwTr0eq/D/AMUx/YfK80JdWyppjif5bm4zC5hDFU/e DJx9I8BGpNxnBx12S7J6qVmkpaaarmT0V1budCMpLRpa3084rftbmkl/272b9w1X9p/4E6LLr6X3 j+Ax+FZXg1q5t7K5uLbT5FQN5c08cbRo7btiKWzJIGjQNIrKI5P2pfgXELov4zm/0OGO8lxo1+f9 DfO29XEPz2Py83a5txlcyDcufA5bjVYPAvxn8EaZ4W1xYfHUSWnh+WXwj4rJjiFjDYbrrGi/Iwjg EuE8wFmKZAHmGHxhq/jPxR/wnvleDL+3/wCEw+H1n4Rg3eGPFreRcR+f5kjf8SLmP/S5duOT5KZC +YfLuOT4d/Zn06pbqLenL0ba+Q4YSErcya11121gu3aUn/26fT2p/Gz4b6X4tTwNda/OmrSXcOnB 10q7lsorqZA8UEt2kZt45WUqwjaRWIZePmGef+CPjzxDdfD3xL4g+LPivTp5/DviTWrG81MW6WNp Fb2l1LGG25OyNUTq7M2B8zMck/P/AIv8S/FXxRrGm3d5o2u3dlo2p6RqelWf9i+MbO1sRbC3kuIX t4tBxeM8sUm2adyFXYyRRNvDegfCj4jXfgzwZ4w07X/CXiRtW1fXtW1rTorPwZ4pktn+1yvOkc0r aQjR4Z9hKxycDcASdtY1srdLCvkg3J28+22l1u015btJNw8O+SEbatxb+6V9e3w/P0PVtH/aA+Ff iDwwPGeia5qF7o8phW1uYdCv2+3vKCVjtF8jddSAK+5IQ7RlGDhSpAddfH34VWvh6y8Tf8JBeXFt qElxFDb2ej311fhrckXHmWUULXEflEASF41EZZQ+0soPzfNZ2uq/Aj4a+BPEHg7UNT134d3VtM+l 6j8OPE19ourxxQyWzxyvJpIaMvFKzq3kv5cirw4Gak1PxlbfDuK2+IHhb4cWXh2z0/QtS0/VvD8P gbxLpOl2UEzRSmeO9XRypcGD52e3iVgwyV8vLVUyilzSVOM370kttUk+XW32nbW1ls+7qGFjKUUk 9X+tu3azvs9lqe/j9pT4OnR9Q19fEOptYaXolr4kuZh4e1Ij+zrkZiuUH2fMkZAbcyBtmx9+3Y2N bVPjZ8NNG1Sz0nUNfmSS8NsouE026ktLdrjb5CXNysZhtnk3ptWZ0Y71wPmGfjbwvrl74o+EmkTf D22v9Qt/EnwetfAF/NceEfEksdjcQpOrSQyWumzRXK755I2w6hSm4F/u11Wk6VoGn+NbnxNrPwc0 3xM2uRabc3F9rfwu8SXF7oF3BbRW8otWbRybuE+RG6BntSGL/wB7I3qZHQhUlFqeja6XdnbsrdXd +SWrV5lhoqN0nt+No/q5ab2X3/Rfij9of4d+F9O8R38qeI7z/hGrO6vLg23hnUngmFuwSUQ3PkeT LtdgrFHYJhmYhUYizpnx28DX1voJnh8RW91r0FvMkH/CM6o/2Xz5DFH9pcW2LdWdWCtN5YYLuHy8 1866oG1i+8eW+m+H/Ffg/S/Fuk6xY3NvpnhXxdeWWrXF3H5UV1Np8ukpFZzLhXeSB2LkuG3btws6 vr+sa5qfhXWofBHiDw1r+k6faWE/iTRtC8YrdwxxTBnge3/sRYtRt2VEIjnMYUySBcH5zhDKaLjF OMru19tNH5d9d27W05tB1MNFL3U/tf8Attv/AG7a59UeLvGugeB7GC/199QYXc/2a3g0/TLrULma Taz4SC2jklbCozEhSAFJOBXjU37Q1l4X+MOr/wDCZeNiPBF54L0/xJo1pD4euVuLRJJrhJprhFR7 jaojUu7rHHEGRWVWyzw/Gn4h+FvHnh/T9N034a+K9dmtNQS9Qah4U8XaLNZuisUntb210uWWKZWw MqBlWcFsEg+Uapc+O7qz8VWdxa+INdn1/wCGsfghNS1Pwj4qjuXuN9wWmnCaIQwVbtxuHzSGBWKo ZT5cYDLk6blWhK7uraLTurp2d+r+V9bVRw8ZR5Zpq9vl78dV8r32urn1ZrXxh+HXh/xJaeFNV194 7+9eGKNo7G4ltUkmz5EctykZhiklx+7SR1ZyVCg7hnEl+O/gTXdN0+18K+Jbiz1TxNe3mhaJNqPh rURDHqUAffDcRtHEY2Uo52SNEWCPtPBI+d4otQmXWPDWo6Jrx8OeNLrRdW1x/wDhB/Fct1ptzZJb JNFaodJVbiOQWUGyR2hMZdjsfaFLbvUvGWn6vZJofhq/vdK0j4j3vjm2e78HeLba4uo7oXWYHVdG kWJozdHDAyBwo/1fe/7Gp25VzOX3LZeX8zat1Ub7NWmGH9zms+bt0+GT7fzcqa6XevVdZrX7Seva H+yLpviu68asnxJ1Lwa2tx3UXhyXUVR14M00VunlWyM3yJJNtiDZOHCMte8+K/it4F+GXg3TfFvx N8W2Oh2V41vbC5u22iWeUDCqqgk92OBhVVmOFUkfGOi6F488OfDnVvBljo15dy+KfAcfg7VBP4O8 WxrYyW/2lYLi3lGikyo6XTl4WRNrAFXbJr2T4rfEK68b/Bmw8H6N4T8SR+IRc6Vc3Ud14M8UpZx/ ZbmG4cRzrpDO+TAEBMScPuOMbT0YzLqUq0Y04PklUd2la0W1tpoktt11Vr2Kq4ePPCEU7Xld+qjb p0fMl6Puj2K2+N/w2u9Bv/EcGs3pt9N1BdKuLZtHvVvvtTqjpElmYRcSMySI6hI23Kdy5GTWNH+0 d8Pb/wAV+D/C+grrOq/8JlDcT2t5baLfNBCIXEbrKwhOx1kOyRX2mEj97syobwDVtS8U3/j/AFz4 jWvh/WYLyDxjY+KNDsn8IeLHhuo4rD+zpoblv7GHkM8OZFdFm2uQpBA3HV8NX48MeMvCXju20DxJ PeR6lr1/4isx4E8UxRQnVZoJWNq/9lMZjEIAuHWHzSS2Y87RzxyikknKMndbdnyXtt/NpzbdGupE sNFLRNv8tG/nb3fW+mzPpDx78VvA/wANPsq+LdQvo5byKa4it7DSrvUZzDCFMspitopHWJNybpGA UFlBOSK8z+K/xkub/wAX+Cfhz4D8V6/osfjPS7rVYfEejeF5tV2hVh+zeXutpYHiYz7pT1jVV3NF 5itXPfG74neIfF76bp/gWx8bnQHtbqLWdOk8K+K9DnuZW8v7Oy3lvpE8wjTEpZIzCWO0M7IWRuV8 JeKvFmha58Iry/8ABmpSWvgHw1caBqTQ+FfFvmSmYW8fmQqdEwwVLRGwzJlpWXgIGeMHllqca1SD cve0/wC3Z20a/mUe6d15pVChyqM+W7s7/po166a9Gdj8LPjZrPiW61Lx74r+IWuWulaJq134dn8P N4Fuoo9SdJGiglswYPtRuyYJZJbdWnMYYq0cZXdXq8vxz+GSeHLTxTFrd7d2l9LPBFb2ej3t1fh4 CVnV7KKFrhDERiTdGPLJAbbkZ+WZrK/8QeEHsPFvgF7y90/x/d+NbPSrzwH4o1LS9Siu5LgzWl0Z dFQxFUuW2SrHL86K2wYxXVWHiI+DtX8OeN/h18L/AOxrzT7S+0y+8J2Xw+8UWGli3uXhlEkV3Fo5 JnWS2UljaqJFlIIUxhm6MTltOpK6i09rJJL4bpXS1vLTm2Wz2Q6mHjzvkTtd+Wl3bW3azu9723uz 2zwv+0F4F8afEK28A+GI9Xv/ALZoUGv2+pppF4LKWGbcYyJjF5YUqjfOWC7gYwS4ZV1fG3xq+G/w 81VdG8Wa3dW1yII7qc2+l3d3FZwySGOOW6lhidLaNnDAPKyKdrYPynHkelfEme2+MsPxJ1Dw14me z1Twtb6JqsUPgXxSstlNDPczqYFOlkXCE3AQszQn5C23nYOT/aH8VeMvifJqmgeF7TxdL4Wv9FW2 t7O48M+LdHa3vy0u+ef7Po0r3cexogIWlSI/Pvjc7GXmhlcJ4inBwkoNa663u+vLb0VlfvqZxw3N Uas7Wj99o3/G+n/AT92/4aQ+Cj+I7zwpbeOYLvUdN1SLRb4WlpcXENndSsqxxzzxxtFEGdxGGdgp kDJnerKNDSPjZ8Pde0+PU9KvNZmgl8QHwuM+HdRR1v1JDRsjQBlRSrBpSBGpUhnBBFfLviLWvH+u Wnj94/Bl3BeeMPEOha1bgeG/F+y3WwW18xWb+ws7mayQLgdJWJxsAf0L4bfEX4c+LfjTqHivwbqn jDUNA1GWJHs4fBesNp9t4gObWeVrhrULCywLEknmeWq+YzsclttVMopwpc7jK6V31V+WDa0jpduS X+HrcJ4dKDkk7/f09O7+6Mvl9NUUUV86cYUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQBHcjdbyjGcoRjGc8emD/I/Q 0UXI3W8oxnKEYxnPHpg/yP0NFABbDbbxDGMIBjGMcemB/IfQVJUdsNtvEMYwgGMYxx6YH8h9BUlA BRRRQAUUUUAR3I3W8oxnKEYxnPHpg/yP0NSVHcjdbyjGcoRjGc8emD/I/Q0lys7W0q2rqkxQiNmG QrY4JHpmk3ZXGld2JaK+ENT+Hevat8NdTj/4V/4003xXD4G1rTviBJaaRfwP4j1ZmRbMiWFQdQL3 CyyLJEZEWF3SQrHJsOprmgWujQeKdE8JeC/FulaZrHgnw294ZPC+rCHVtRS+Jmhu3aEvO8sM8MU+ BJO0bOoWRkaOvf8A7Gg/dVW7vbbTe1732t7y01TXfTreEXR9e3nFd/71/RXufbdZOoajr1v4g0nT rDw59r0u8Sc3+o/bEj+wlFUxDyiN0nmEsMr93bk9a+RNA8I6Bp/hZ7rRvhfBDpN547g1Xx54Q0jw jfoU0qSCSG2jW2uLK3uL22SdUnKrb7QfNVVIjbPH/ET4b6jBo0duPBvxKuLG98M+MLPQbGy0rWpR p1pcTRvpFo0dupFvuKPmJwrCLy4pwEVUDp5PD2nLKb67x68t7fFvfbWz0d2nYqnhIymouW7te3m1 ffpa/wD29HufoDRXxJrmgWujQeKdE8JeC/FulaZrHgnw294ZPC+rCHVtRS+Jmhu3aEvO8sM8MU+B JO0bOoWRkaOvZf2VNA8G6Fp3i2XQfCOm+GNV1XWP7Sv9Is9BvNNWxhdAkESG7tLWaaL93K4bylRW klRR8pJwxOVqlRlWUm0tvd9N9Xbd23Wmtro550uWmp97dO8VL8L29T23Urqex066vbbTrjUJreF5 Y7S3aNZbhlBIjQyMiBmIwNzKuTyQOa5v4S+PT8Ufhr4c+IZ0g6WfEFhHffYjP5xg3fw+ZtXdj1wK 8C8N+EvE0/xXs7m88Ja1Z/EDTvHeoXWq+J/7JlS1v/DjxzGGE3xXyZodj2cS24dnjki3bF2M45P4 T/DCGw8JaJYweCPG3hu/0jwRqek+PtQt9Euoru8eQIsMEBmjP9oSIUkaIwiaONECKQsiI1xy2j7C XNP3vdadulpt9dm1FJ73aVlfXZ4eKvG+qa19W1+l13TXc+1qK+LZvA/ieX4Xw+HrLwNPZ+Drbxha za7ceE/Ah0e51qyNmYnnk8P31vKHMc4t2kRYZElVN0abkwt3wr8G/ACfFfwBoFz4S+IXibwl/Yms pjxb4fuv7Njaa4t5YI3tFt47S1j3R3JSKSGIqY4iVAFuaf8AZFNXvV2vtHtHm1u1ZvZJ6/NNKHQi o8zl36dm1rr5fK6ufYtVtR1Gx0jT7rVtTuo7azsoXuLieRsJFGgLMzHsAASfpXz74L+Ben+G/Gut /Dt/hjoo8BaVri+PNEuIdOhUG6mRkFqmQMSwyxyOHBBWM28eQnA8St/BsfimDxTY6R8BL/QovFPw 21W0/sT/AIQrV1ZNUTy5rT7fqN3Ekd7eblldZ9oKSEoJJiVkbOlllKo3y1NEk72WzTevvaPR+V+u qvpSw0JTs5aJpfJv10933vvXQ+3LDXdV1LXooLTQN/h240qO/g1r7Uo8yZ3I8j7ORvHybX3nj5sY yK3K+HLvwreWF94gPwk+G3jCx0+78DaEt/Yf8I1qdjDdJb6hI+pWVsk8SRxyPbO37mPb5rSuVDO7 k3tY+Gej33inw3c6V4B8Z2vgC4+I8NzpOhQaHqtpa2NkdNaK9kksY41+z28l2yDbNGgIacqPKlkL dE8npc1uey16a6Nb+9u76d1GT6a5qgmnKTtpfb+4pNb730t6+h9q0V49+y6DaeBNZ0WLw5q+h2Gn eKtXXSrLUNGutNEdhJdyS2whinjQiLy5F2hRhR8uAQQPYa8bE0fY1XTve3y/AwnHknKD6Nr7nYKK KKwJCiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAI7kbreUYzlCMYznj0wf5 H6Gii5G63lGM5QjGM549MH+R+hooAhtnuvs0W3TZiNgwVeIqeO2GAx+AqXfd/wDQLuP++4v/AIur tqd1rC27OY1Oc5zx65OfzP1NeAa5+1TDba/reiaN4e1+R7XxDpegaeJvBOtkSNI0T3rO4gC7kglZ o4/lZvL3DerrXRhsLWxEuSjG70/Fpfmy4U5STaWiPct93/0C7j/vuL/4ujfd/wDQLuP++4v/AIuv CNf/AGpIr/4xJ8LPC2raL4esLTWk8PzeItf0m/u7XU9T2F306zaHyrdZVG1S8tyrb8qsMnDHmrj9 sDxUmsSeLbfRtFl8B2vxM/4VpdWXky/2qkm0L9u8/wA3y9vmn/UeTu2YPmZPHZTyfFz5bRtzJNX6 3sl5XbaSX32NXhaivdbf5N/lF/dbfQ+nN93/ANAu4/77i/8Ai6N93/0C7j/vuL/4utKivLOcyLl7 o20u7TZgNhyWeIKOO+WIx+BqPUrCHWdOutH1jw59usL6B7a6tblIZYZ4nUq6OjMQyspIIIIIJBrW ujttZm3YxGxznGOPXIx+Y+opmo2s99p91ZW2o3GnzTwvFHd2yxtLbsQQJEEiuhZScjcrLkcgjimn Z3Q1ueX/APDOPwB/6Nw8A/8AhMaZ/wDE1neIP2U/2dPE2kXGh6l+zv4Sht7naHfT9KtLC4GGDDZP blJU5AztYZGQcgkHk/DHxH+JWl3WufDD4keOL9JdZn1RvA/jO3s7JLm4+x3E6SWVwhtzbC6RLfzA fKCyxu2AGjNdhL8a9P8Ahp4V0y18TyeKvGl/Y6DF4h8RajbWtiZdMspCf9KuY4/s6mMbZcLBG8hW BjsOCT7MoY+Evcqtu6taUtd9U9NmmnezTWx1NV4TSjJ36Wb8rNet0l1vpa+hW8Mfslfs3+EdKXR9 K/Z58LzwK7SB9U0+31KfJ65muWkkI9BuwOwFa3/DOPwB/wCjcPAP/hMaZ/8AE1wni39pCy1afxj4 Z1/wp4+0TQtK1vSNIs/EHhyS2klkkumtpYnMsU7+TDIs0bbnVVMTFSwldYqwfEPxZ8RRfFLxz4r8 U+EfizDpXw21zT7Wzj0DV9Nis/Ilt4dyXtq18I50le583zGQtFHsJeEo6jaFDMqsuapVldq+st78 luu75436r1shqFZpvm6X33vtrfr3PSPEH7Kf7OnibSLjQ9S/Z38JQ29ztDvp+lWlhcDDBhsntykq cgZ2sMjIOQSDF4Y/ZK/Zv8I6Uuj6V+zz4XngV2kD6pp9vqU+T1zNctJIR6DdgdgKX4n/ABr8NaL4 00fwjrujfEuway1+Bbe/0GzE9nqMwspLpraXyWeR08sjMDIskjFDGsiqzLJ4W/av+H3iTR7bxLee HvFfh/Q77w3d+KLTUdX0+OOO4tbTy/tIVEleXfH5qdUCuDmNnGDWCeaOhzRnNxeu7ttfvq7J+as+ wrYlqMU207Nb9dNPP/g9maP/AAzj8Af+jcPAP/hMaZ/8TR/wzj8Af+jcPAP/AITGmf8AxNafw6+M n/CwvE2qeFpPhp4u8N3Ok2NtqE8usnT/AC2juNxhCfZ7uZiWCSH7uBsYMQ2AeYf9pey0PXPiWPHn hDUvDvh/4e3FtaHVLq4stlzLMkTRp8tySrS/aIihYKiqcyvGcqudsw53TU3zJJ25u7SXXW7a031R EfbSdou+3Xvt6mp/wzj8Af8Ao3DwD/4TGmf/ABNH/DOPwB/6Nw8A/wDhMaZ/8TXMaN+2p8LPEP8A Z9poWheKNV1XUdZbQYtP0q2ttRC3P2c3CBru2nks9rqMAichTuL7FilaPa0H9qTwfrc2nCXwV420 23v72+0j7TdaUjrFqNmk8k9kEhlklmlCW0pVoElicjYshkygudHNYJubkreb9e+vy/VDccQt7/1f /J/JN7Jl3/hnH4A/9G4eAf8AwmNM/wDiaP8AhnH4A/8ARuHgH/wmNM/+Jqj4P/aq+H3ivT7HXb/Q /E3hjRdV0O58Q6fqmu2cUFvd21sFNztCSu6vGGBIdVDqC0ZkX5qg1X9rLwP4ctp/+Eq8F+ONI1KO bThFpUmkpc3dxb30pht7pBbSyoIS6up3OrqyhCm940deyzTn9nefNta73va2/fR9nuHLiLta6efp +V1fs2k9Wav/AAzj8Af+jcPAP/hMaZ/8TR/wzj8Af+jcPAP/AITGmf8AxNS+Kvjy3gvTRq/iH4Pf EGCztrNb/V51trGSLSIWlaMNNIt2UlICmRktjO6Jguq7gDzvjX9pTwk2ifEawj8IfE06f4LjudP1 3WdI0kQyWTfZlkWS38x1lYkSfLIsZRNolkKQlJWmEcxlrGUmvKXml37tW73Vr3HTjXnJJN6269z0 jwn4M8L+AtOk0fwN8PdN8O2E05uZLXSbK1s4XlKqpcpGVBYqiDOM4UDsK2993/0C7j/vuL/4uvnL 4X/FHUvAXjjxT4e12+8e+N9N1jxZpGj6Tf3s9pKdKF1pdrNGtxukiVEy78xoxZhzukkG/wB40jxt PrWk69qll4N1stot9dWENsz2Yk1RoCVLWx8/YFZwyL5zREFTuCjmscbg6tKXNN3TSd790n110uvz 2MZQlo297W873t+T+41d93/0C7j/AL7i/wDi6N93/wBAu4/77i/+LrxvU/2wPAej+G9G8XX3gnxx /ZWv+FrnxZZTW+nQXLNDblPOhaOKdnWVRLGSSBEFbcZAFYrPqX7WvgXRLSW61vwT49sT/wASuW1h bQ/Nmu7fUJnht51SJ3MSb4nBWbypMgKELOisf2XjHtTe9vnflt630K+r1bX5f60/zXzdj13fd/8A QLuP++4v/i6N93/0C7j/AL7i/wDi68j+Iv7W/wAOvhOLK18f6Tqej6tcWJ1O70i51DSY7yxtt7os jK16FnLGNyI7Zp5cD7gJAPRWnx58P6p4m1DQ9A8L+ItasNIjSTUdY02O2uYLTfafa4w9sk5vSXj2 hNlswZmCqSc4zeAxCh7Rx93V30tpo9fXRd+lxOjUSu15/wBfg/Rp7M7rfd/9Au4/77i/+Lo33f8A 0C7j/vuL/wCLryvwf+1V8PvFen2Ou3+h+JvDGi6rodz4h0/VNds4oLe7trYKbnaEld1eMMCQ6qHU FozIvzVW1r9rXwN4W0+8uPFngnx1pF9aNp7jS20hbq7mtb2XyoLtBbSSoIS4ZTudZFdQhTe8aPf9 m4vn9n7N821vO9rffo+z3D2FS9rf1p/mk+zaT1Z67vu/+gXcf99xf/F0b7v/AKBdx/33F/8AF15t L+0f4fgt5YJ/BHieDXo/EMfhlNAuH063vJrqS2W7j2SSXa2xDwsrKPODknbt3fLXLeJf2i/DvhTx tf61eeC/ivLe6d4f0w6lophtLexsY7y4cRzMtxcRxtKsmIpZo3eNRxuISQo6eW4iclFR3228rddn da7ajVCdm7bf52/4bv0Pct93/wBAu4/77i/+Lo33f/QLuP8AvuL/AOLrzzx9+0X4Q+Gj6x/wmGj6 np8Gm3ltptrdXF3p0Fvqd1NEZhDDLLdIsbJGCzG4MKgYwW3LnovhZ8WvB/xf8FJ488KXTDTvPntp xNJExglhYrIrSRO8TgEZDxu6MCCrEHNYSwlaNL27j7mmvTVXIdKaSk1o9v6/rZ9mdDvu/wDoF3H/ AH3F/wDF0b7v/oF3H/fcX/xdeG/Fv4val4y+Dvjn/hDdK+IHhSM+Dr/xBoXi+C1t0tb2KCPephmV 5JIDICColSCUoWaMhlyKfh/9pH4beDdJ8S+KPEeveLmube/0zQprLXp4bKCS9NgkoFibySFI43Td I0kzxpIwLKzBkLdMMrrypuSWq6ddWl8tXbumrOxp9Xm0mtb3/Dlf5O/yPft93/0C7j/vuL/4ujfd /wDQLuP++4v/AIuvGdC/bG+HfiyfQ9P8GeEvGfiLUdfgvpba103ToZYxJZyKk0JvDMLRmG7cGSdo 9u07x5kQdNN/as07U/EVxLH4F12HwfbeCIfGr63M1muLeUSspaM3O9V/cvFjYT5gJO2MCRpeV4tX 5oWtd62W1/vvZ272dhfV6tm7bf5pfm7ff2PZ993/ANAu4/77i/8Ai6N93/0C7j/vuL/4usvwD40n 8daO+sy+D9Z8PpvUQR6lLZTfaomjSRJoZLS4nieJg+AQ+cqeOhPTVx1KcqcnCW6+f5GJm77v/oF3 H/fcX/xdG+7/AOgXcf8AfcX/AMXWlRUAZu+7/wCgXcf99xf/ABdG+7/6Bdx/33F/8XWlRQBm77v/ AKBdx/33F/8AF0b7v/oF3H/fcX/xdaVFAGbvu/8AoF3H/fcX/wAXRvu/+gXcf99xf/F1pUUAZu+7 /wCgXcf99xf/ABdG+7/6Bdx/33F/8XWlRQBm77v/AKBdx/33F/8AF0b7v/oF3H/fcX/xdaVFAGbv u/8AoF3H/fcX/wAXRvu/+gXcf99xf/F1pUUAZu+7/wCgXcf99xf/ABdG+7/6Bdx/33F/8XWlRQBm 77v/AKBdx/33F/8AF0b7v/oF3H/fcX/xdaVFAGbvu/8AoF3H/fcX/wAXRvu/+gXcf99xf/F1pUUA Zu+7/wCgXcf99xf/ABdG+7/6Bdx/33F/8XWlRQBm77v/AKBdx/33F/8AF0b7v/oF3H/fcX/xdaVF AGbvu/8AoF3H/fcX/wAXRvu/+gXcf99xf/F1pUUAZu+7/wCgXcf99xf/ABdG+7/6Bdx/33F/8XWl RQBm77v/AKBdx/33F/8AF0b7v/oF3H/fcX/xdaVFAGbvu/8AoF3H/fcX/wAXRvu/+gXcf99xf/F1 pUUAZu+7/wCgXcf99xf/ABdG+7/6Bdx/33F/8XWlRQBkXL3Rtpd2mzAbDks8QUcd8sRj8DRWldHb azNuxiNjnOMceuRj8x9RRQAWp3WsLbs5jU5znPHrk5/M/U18c6X4V+H48R6br2tv8Z5CniXU9f1A QaV4+Ak3mSOxCJ5AUPHA0aO/yk+XtyyEivraC41AwxlJ7faVBGYmY4x67zn65NSefqX/AD3tv+/D f/F16WDrTw/M1fXs7fo/+HRywzajGLg72f8Ak1+rPhgfD+CTVbnwbenxdceApfiYPiVDfN8O/FA1 WF8Fmshb/wBl+VtMhx53nZClv3ZJwOjtvCPw+8RfF9viZ4r8IeL/AA7pdvrv/CQN4f0HwT4yu7fW dQQARX16JbKK3Rx97y47bdv+Zp3DMp+xPP1L/nvbf9+G/wDi6PP1L/nvbf8Afhv/AIuvR/tWppyp p2tpJeSb+HdqK+5NWeptPPaUr3T10e3W7f3tt/PSy0NGis7z9S/5723/AH4b/wCLo8/Uv+e9t/34 b/4uvC9jI4/7So+ZcujttZm3YxGxznGOPXIx+Y+oqDWrm+stHv7zS7GW9vILaSW3toRGZJ5ApKoo kkjQliABukRcnllHIrT3GoCGQvPb7QpJxEynGPXeMfXIqTz9S/5723/fhv8A4uhUZXGsyorWzPmy 98PfEjxj8Kta+GnxQ+CXjfVJNQ1C41Sw1TRIdC0ubTLmSdrlJot2vzsJY5nZlYOvy4Ug/MWqeLfC HxP1jU5NQ8MfCj4h6KNZ8KR+DfEiTW/hy7N9ZoW2SW5/ttPs9woluAHYTJ+8GYzs5+nvP1L/AJ72 3/fhv/i6jt7+7u4I7q1vrKaGZQ8ckcRZXUjIIIfBBHevVjmFaLbUI6u9tbXatte23l0T3SOlZ5TV mltf8Wn37xT8mtD5R8YfD34uar/wlWn+DvhX4w0TR/FF7o+ota3ml6Dey2sumi1WJUlXxDCDGws4 gVKbhlsNyMa1tqvxI8F6t8RfE3xI+BHj3xP4f+Ik8Ud3pGk+HdKkmj/cR2ao3k65cs8ZhjAc+Uo3 FmLIvyj6c8/Uv+e9t/34b/4uqem69HrMc02j63pV9HbXElpM9t+9Ec0bFJI2KyHDqwKsp5BBB5q/ 7RrSh7OdOLjs97293re/2I6+QRzumopKOitsrbWtrfyX3HzDN4R+M8Pgf4d+HvDvwr8dWWp+CdVG u3N7rMehaw2oXXkSwgO667bMVCzuM8EhI8BAuDzo8B/HHwl4Q8MQN8NfF1/beAfB2r6BHEnhrQ5p b1bqMDeY11+bcVENuPLEMu8iQbT5iqn2Z5+pf897b/vw3/xdHn6l/wA97b/vw3/xdUs2xGqcIWbb ej6pp6t32k15X9CoZ9Ti01Hby82+/dv7z5R/Zl8Y/Enw6dWS0/Z1+I17pU0cSSXF/on9jaissaqs UYOsa9cSTW6x79qxsiRHOFPmMRpeLPCHxI8T6p4+ni+E3xJ02z8a3Gn6vbm3Tw4b3S9TsVtxb3CT HWjHJEDaxsYmiyST84HFfSNtrqXt9eaZZ61pc95pzIt5bxDdLbF13IJFEmULKQwzjI5FW/P1L/nv bf8Afhv/AIupq5jVdd4iNOKk0tXdvRprqluk07LZErOqUZuSjv5enn5fP5nzVrkf7SHijWPBev8A iD4f+Jpbrwlrp1h4rfQdBit7hfIkt/LjU+I2eNilxMWdnkBbyiqKFZZOYtPC3xy8K2Hh/U9T+HHj C8t/CPi/UvHFwln4b0Z5rsXInMtvHGniOR9wF1c7CqyMSYhsYowk+sdK11Nd0+HVtE1rS9Qsbkbo bm1HmxSDJGVdZCCMgjg9qt+fqX/Pe2/78N/8XS/tGvFez9nBLtb18/Nh/bdJLklHTbbp7y7/AN+X 3+St8SfBjwd8R/F/wn0TQfir8EfiTqWmaX4YvvCtjYW2j6Tok1qt0FSeWQ32qCaVwkarG/kwrgsS j5BXoNc+Hnx48SaNG2t+BfF914ktxo9pDqjaH4fWEWmnXP2tFa3HiIEzSzhDJIJApVQqRofmr63F /dtcParfWRnjRZHjER3qrEhWI35AJVgD32n0qTz9S/572v8A34b/AOLrapnGIdZ1o04rW630d2+/ du/frcqWfQbbcd/Lvbz8l6tXPlP45+CPjD8ZtQunk+Ffi+HS7rR49OTTdY03QtSg0+5V5Wa+s418 RQxx3JEiqJHSV0CYR1DuDJD4X+PE3hj4r6FrPw48VXNx8UYyj3MGi6FCtgzWiWUhEZ8Rv5gMMSkD cm18sSwIQfTuk68mv6bbazoWt6XqOn3kYlt7u0/fQzIejI6yFWB9Qat+fqX/AD3tv+/Df/F1l/aO IjT9h7ONlpaz7p977xV/QFnsYte7rG1tO1vPy+fU+PRo/wAUPD2g+NPDPjv4M/ELxFc/Er7Hb6e+ i6DpVqmm3traxwW88kya1eCBVNtbyCWQKqyITk5Cj3fwz428ZeGPDmneHbb9m/4mSx2FskHnS6j4 daSVgPmkdjquS7HLEnkkk16X5+pf897b/vw3/wAXR5+pf897b/vw3/xdZ4nGzxEbVacX3+JLRJLR NW0VvMylnFBpLl2/4C79kvx7nxVd/Bj47TeGdI8I2/hLxium6D4b1fwlYLNoHh95BY36RozSMviN d1wgjUbwFQ4/1YOSdDxf8Nf2hPFWsQauvgjxFaGLStE01oz4c0OTd/Zl19sjcH/hJxjfOWyOcRkK DuBc/Yvn6l/z3tv+/Df/ABdVBrqHVW0Ia1pZ1JbcXbWeP34hLFRIY/M3bCwK7sYyCK6Y5zi+ZSUI XWu3m5X37ts2efxa1jpr07tN9e6R4V4km+NUvxCX4leA/hT480PUr3R49E1m2v7Xw9qFneRRSPJD LGi67C0UyGacBi7qRLgoSAaxvEln8R7j4hWHxW8R/Avxpcw+FQLu1udP0TQR4jeKOBla2e8t9bP2 iB2eVjbrancX2qAwU19M+fqX/Pe2/wC/Df8AxdHn6l/z3tv+/Df/ABdcscbUirKnHZrrez6Xvfy8 lotDJZ1R6x6Wfdrbe/ZWPiT4MeDviP4v+E+iaD8Vfgj8SdS0zS/DF94VsbC20fSdEmtVugqTyyG+ 1QTSuEjVY38mFcFiUfIK9Frnw9+Onibw5Pba/wCA/GN34je30jTYtV/sXw+kKWen3Qu0VrceIstN LMqmSQSBNqgLGhyx+ufP1L/nvbf9+G/+Lo8/Uv8Anvbf9+G/+LrqqZxiJVnVjTitbrfR3b017t37 9bmks+g23y9b7ej7+S9WrnypqvhT45arqfjq8vvg9eapY+OdVttQutK1rwnoF/ZrHBbrbpG6HxKu 9gIYHDgph0Y4wwCO8MfDrx1pGo3lp4g+DHj/AF7wvf8AgiHwTPpVymg/aGgjeZ932p9ef5c3Eqqp QlUEQ3koWf6p8/Uv+e9t/wB+G/8Ai6PP1L/nvbf9+G/+LrH+06/J7PkjayXVbLlWz3S0vuL+3odv w7NPv3ivuPmy68M/EdPAHg/w/o/wq+KsHinwXqEOsWniO7l8N3JvLtY3hma6g/thTJHLFLLGVWRG VWXa42ivQdE8d/FX/hH5dM8b/AXx9rt5eB1u5Lb/AIRyytirDbsih/tiRlTH9+SRsk/NjAHqXn6l /wA97b/vw3/xdHn6l/z3tv8Avw3/AMXWNXFzqxcalOLu2+vXzvdLyWnkZ/2xR093bb8+/dt+rPlt PD/7QcXwo1X4LL4H8Zy+G5dBn8OaVLcaN4ee/t7Z0MKfaph4hVLhkgYqCkcBZ1V2yAyNiaZ8Nfjp a3l54hu/BHjQeIU1rTte0m8sNH0CCC1ntbIae0c8L+IpDPDLbZRlDxsGdmVxwB9f+fqX/Pe2/wC/ Df8AxdHn6l/z3tv+/Df/ABddEc2xEXJqEPe3031T791r36lrPaaXKo6a9O9r9dnZXWx826gn7RWp eN/DHj+7+HfiiXUvDum6nZmJtE0AW8kl4IhujVfEQZIkNvAdjNI7fvf3g3r5fPfDnwL8cvhpFpra L8PfF013Y+EF8JSSz6L4fZJEhluJbaZU/wCEiwpVrjEikuJAvymLOR9Z+fqX/Pe2/wC/Df8AxdHn 6l/z3tv+/Df/ABdSsyrKHs1Thy7Ws/73n/fl9/krH9uU+Xk5dNOnZ3XXvqeTfs0eC9Z8GWfiWLV/ h9d+EG1K9ivBYwWNjp2k7vL8sm0s7XUr4QtiNTKS6ByyFVyHNe1VnefqX/Pe2/78N/8AF0efqX/P e2/78N/8XXn4mVXEVXVna7t+Csc880oyk5NPX+u5o0VnefqX/Pe2/wC/Df8AxdHn6l/z3tv+/Df/ ABdYexkT/aVHzNGis7z9S/5723/fhv8A4ujz9S/5723/AH4b/wCLo9jIP7So+Zo0VnefqX/Pe2/7 8N/8XR5+pf8APe2/78N/8XR7GQf2lR8zRorO8/Uv+e9t/wB+G/8Ai6PP1L/nvbf9+G/+Lo9jIP7S o+Zo0VnefqX/AD3tv+/Df/F0efqX/Pe2/wC/Df8AxdHsZB/aVHzNGis7z9S/5723/fhv/i6PP1L/ AJ723/fhv/i6PYyD+0qPmaNFZ3n6l/z3tv8Avw3/AMXR5+pf897b/vw3/wAXR7GQf2lR8zRorO8/ Uv8Anvbf9+G/+Lo8/Uv+e9t/34b/AOLo9jIP7So+Zo0VnefqX/Pe2/78N/8AF0efqX/Pe2/78N/8 XR7GQf2lR8zRorO8/Uv+e9t/34b/AOLo8/Uv+e9t/wB+G/8Ai6PYyD+0qPmaNFZ3n6l/z3tv+/Df /F0efqX/AD3tv+/Df/F0exkH9pUfM0aKzvP1L/nvbf8Afhv/AIujz9S/5723/fhv/i6PYyD+0qPm aNFZ3n6l/wA97b/vw3/xdHn6l/z3tv8Avw3/AMXR7GQf2lR8zRorO8/Uv+e9t/34b/4ujz9S/wCe 9t/34b/4uj2Mg/tKj5mjRWd5+pf897b/AL8N/wDF0efqX/Pe2/78N/8AF0exkH9pUfM0aKzvP1L/ AJ723/fhv/i6PP1L/nvbf9+G/wDi6PYyD+0qPmaNFZ3n6l/z3tv+/Df/ABdHn6l/z3tv+/Df/F0e xkH9pUfMuXR22szbsYjY5zjHHrkY/MfUUVnz3GoCGQvPb7QpJxEynGPXeMfXIoqXSa3LhjqcvhT/ AK+Ytud1vEc5ygOc5zx65P8AM/U18aa5+0t4g1DxlrWiweOfhjZrfeMtM0i3EXxOdHtra18q4m2R izAEc22aGSTKnfJ5eH2KT9l253W8RznKA5znPHrk/wAz9TXhukeC/jTo99pmoQfDnwVNJpWpalq0 Qm+IV2we4vpJHlZsaICdvnSIgGMKcHPWveyuVKEpTqxUtrJtLW9+u+1vmefhZU0p80U30u0raPXX fWx5/wDFm/8AH3w1/ai+GviLU/iH8RLfw14m1iTTNSlfyn8LKroy2tnHaRFnjnd2RDNP1JLq2EYI fFm/8ffDX9qL4a+ItT+IfxEt/DXibWJNM1KV/KfwsqujLa2cdpEWeOd3ZEM0/UkurYRgnQaR8Ifj xZ38cniGzsPFul2urf25ZaR4g+Jk91b2l2JPMidJRoC3DLEf9XHJM6LwdpZVINI+EPx4s7+OTxDZ 2Hi3S7XVv7cstI8QfEye6t7S7EnmROko0BbhliP+rjkmdF4O0sqkerSqU4+z53F8sXF6x1T7dpK7 3912XdndKcNdYv3HHeKv8VpLs1eO/bTZH0tRRRXzB4JHcHFvKc4whOc4xx65H8x9RTpWdInaOPzH Ckqucbj2Ge1NuDi3lOcYQnOcY49cj+Y+oqDV7e+u9JvbTTLm2t7ya3kjt5rmBp4Y5CpCs8avGzqC QSodCRkBlzkFr6FK2lzw7wT8WvHvizSfE2geJ9QsNL8XLb29vb6H/wAI9daVf6TNcTSW3ms01xNH e26sFZbi3IRhG3AJAHF/FrwVbeDPFninxl4q8Dp4x8BvZW1hNrmh3mzxF4FtobULJEqZ3SWjB1nd I2BKzTebHKhw3ceFvgN8UPB13Ff6R8SPB091BtEE+qeHtd1OWBQrIEje616QpHh2+RSFJwcZUEQe Iv2dviD4q1a71nWvHXgeSXUpEl1K3h8M63b2epFESNReWsWvLDcrsjRCsqOpUbSCCQfoaVfCU8Q5 06iUWtbKSfTa1rWs7O9+junK/r06uHjWk1P3H2TT6XtZK211v5pq5W8T/G34paJH46ms7jwldR+D /GWi6VEx0m5UXWn6gLM44ujidPtq/vOUbyz+7Xd8vO/BjxB4w+GxfS9D0bwyngnUfijr3huDSrW3 eK8gJubt45Y3DLEkStEIzAIjhB5gk/5ZrveLv2XfF/jnVdR1rxH4y8DyXOrNbSXv2Xw5rtnFNLbl fImMUGvInnR+WgWULvAUANjir+m/s8/EHSfE8/i+y8beAf7QnuLi8Cy+FdZmtYbicETTw2r66YIZ nDOGljRXIkkBPztkjWwMaDpqSu1r7r6Riu3dSd7ac2iY3Vwn1f2XMruzejtdRa/9Kk36aFDQf2hv GkOm6laeMH0i18WyXmm6ZbeH7rw9eaVPpU95dvaCWd5LiZL21D7Ss9uypJtK5UuNux4s8bftF+Dd W8IeFrwfDi+n8WeJZtHj1iK3voUit/sUk6ObEyMfMDwy5H2khlRFBQyF4s2D9mnxxHoWp+HLzxv4 J1ax1e1WyuF1nw5rupyJCpDIkMtzr0kkAVgrr5TJtdEYYZVIY37M/wAQZLnRb25+Jvh66uvD+oHV NPubrT/Es80c+3ZuaR/EJaRQu5QjlkCySAACRwy5su5+bmVv8L7K1trWd+rvfVtkuWD5pNSWt7e6 9+Wyey69Nuur0MOf4vfGnRviLf8AhGy8JfDS31a+8cWfhW+1mOK7BlSTSPtcNw8Qw0rgKx2NKoQK sIZ932hJLP4pfHvxN8SfCmh2Gq+E7ee2PiSyv7BtPuorPU7nTpoIg4mE7PFHIs6bcpL5LCQkT/Lt yPiX+yr8cvEPiOy1zw34z8BzS3/iOHxFrtzIfEemS+fDC9vE0Aj1OfGIppBtia2I8qJd+3gdtJ+z h4+ay0Kxt/HXgiyHhoXA06ew8N65Z3KfaCGuC9xFryyymVgHcyMxdxubLc1pKeAVKElKN3Fp+69+ Tlv6c2qVlda7o2qTwSUHFrbXRvpJfny9mktHqct4Q+P/AI6v/hnZXngXw14N0m48N+ArfxvrGl/2 dNHaXiSvOfstjsmX7NxbTHzXEwDSJlD8xrT/AOGhfi8994o1y40Twhp/hvwx4k0PTvszC7uL66tN S+xY3Sbo0hmRbxXJ2SLnMePk813Rfsk+IINM0fR4vFPgYWmh2cmm2sf/AAj2vHzLN5BI1pcN/b+b m2LAfuJjJGASAoBIM2t/sseMvEUmvSar4/8ACrnxNqNvquqCLSfEcKz3FuAIHCx+IVCBMJtVAqjy 4uP3abadXK3Vcrqzf8rvbnTfreN15Pa+5Mp5e5PXT0d7e7/9s77rmSWyZJ8Y9Q1i9vfDVpcahd2O g+PviDB4d1OWCdonOmwRThLbzEIKJPcwvkqQWSfYThiKd498EeDPhn8UfhtoXw58IaLo+neO7y/0 LxL4e0+wih0/VbAWcsrST2qqImaNlQeYV3bZWQkq5Wul1b4S/FnXvB//AAgOt+NfhlqGg/Z47UWl 14D1CXCpjY29tZL+YpVWEm7eGAYNuGaoeE/gZ8U/Bmqy69pPxH8F3eqzW/2T+0NY8Na3q13HBuDG KOa716V44ywDFEIViqkgkAjkhVoRpciqpfFpaVpXSSvpuvn5WZiq1JR0qW0atra7vaW28bq2l/dW vbz79n/x58WfCPwi+Heg2eg6BrVtrngm7ufD1hZLJHdw3NpHGY0nlklWOVJg+flWHy2ITc4PmV0Q /aM8cf8ACIWVtpK6f4j8aaz4kj0GGwj8NTaLc6UzWTXZW706/v4y0oWKQLi6jSQMpRjjDXND/Zm8 a+HLa/s9I8aeB4Yr+xk0wB/DeuSmztXbc8NkX14mzjLBSVtzGMxxn+BNsk/7N3jy88PTeGtR8c+C NQgnvYdRN3feHNcutRS4hIMMsd9JrzXMbx4+QpINmW243HPTWr5fVrSqyktXfZ/zN66dnbS3NbV6 m1SrgpVHO61bez7aXXk7aX1s23d6RaR8UP2mtV8Y+F/h7rfg/wAH+D9Q1rStUvp73UVe/f8A0W4g RJBZ210URXjnT939rchnY78RATavg34l/FrXNSvPAeqax4PXxnoniqSz1OCHQbqOA6QsSypcIrXj MpkR4sS5dVeTy/LbYXNHTP2c/iJpHibSPGVl8RPCP9s6Jby21rdTaHr8zOkpzJ54fXytwzYTLyh2 IiiBOI029Ivw1+MieIb/AMVr45+GH9ranYxabeXR+H98Xmt4mkZI2/4nGMAzSduc85wMc9WphGrU 3HZ/Za97mbT1Unblsmvu88Kk8M01BxXye+qe6btZ3Wu6Xmzy/wAQfH/4rTaL4503S/F3ge9utP8A Auo+JrLVtD0O/eytZrVlEtvFdyTiK/IEmzzotnlSofMiyPLqyfjL488A61e2/jHRPB+pavH4U0BN L120s5457h9RvpLVDeb3Zkhjkw7RrI+7azh1MmyO3pX7I/iXR/KS18ceFJoINJm0KK1vdK8R3dtH YzR+XJbLBN4heNYioUbQuBtUjBUETL+yj4qIvxeeNvB+orqejLoF0upaL4hvVks1YukeJvEDgFHJ ZHGHRiSrKTmupVcsXu8149fdab1fVbaWXXq3d6vonUwDvFPT/D5w7L+7LTbXpuLrHxv+Omj+LbD4 cJovgm71RfGMPhq+1p0u7e1miudPe9glgtA8jK6hHEitOcmJQpAm3w+sfBvxrrfjnwpeXniYaedW 0jXNS0K8k0+GSG3me0u5YPMSN3dkDLGrbS74yRuNeYj9mfx0E0hT4/8ACLSaJq/9vW1w+h+IGuHv dgjE88x8QeZcMIwIh5zOBH8gwny16R8FvhbP8J/Duo6Ndata6jPqOqTapJNbDUFQvKFLki9vryTe z73ZhIqsXzt3bmbhxc8E6FqTXPpsmrvq+y6uy027HJi5YWVJextzK3R6/FffveOnSzXr6BRRRXjn mhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQBHcHFvKc4whOc4xx65H8x9RRRcHFvKc4wh Oc4xx65H8x9RRWdQ7MLsxYLSGSCOQtKS6BiRM+OR7Mf5n61SutU8MWMtxBe69aW8loYRcJLqGxof ObZDvBb5d7AqufvEYGTWpbHdbRNnOUU5znPHrk/zP1NfEEv/AAsvxL44njT/AIW9dWfiP4hcBf8A hEPKmi0kLnrhxJFc2fH3YyiDO+Qnd3YDCfWZNSmopW1b81f8Lv5HTRwkailNtJL8dG7L5Jn2A/iv wHH4qTwJJ4x0pfEssP2lNGOrKL5osE7xBv8AMK4BOcY4NZ2s/FD4QeHfES+EPEHxQ8MaZrrvGi6X eeIYYLtmkx5YELSB8tkbRjnIxXzX8XfBnhyD40/Cr46fDXTfAnijQofGv9mao2kEf2zPf3O6LzJb 9Xk+0pAxaQwsE8tYtvKZMdXVfAnibwx8WJPjnoHib4V/GPTrnxrHpmqWJ8LWC6voUst1DHGlrfxG SZ7i3WRAVlddkaZ29CvfQyyhNU5Oo1zJ6be/dLl62vdO7stVrrZdLwFBK/N9m6WzveSa7K3L1te+ l7a/ZX2GD1m/7/P/AI0fYYPWb/v8/wDjViivBuzzOWPYqT2kMcEkgaUFELAmZ8cD3YfzH1p/2GD1 m/7/AD/41JcnbbStnGEY5zjHHrkfzH1FR6jqOn6Pp91q2r39vY2NlC9xc3NzKsUUEaAszu7EBVAB JJOABmi7uUoJ2SRhXnizwXp/jPTvh7ea6I/EWrWU2o2dgZZS8sEJVZHyPlGC4wCQThsA7WxX+JXj Lw98LPAus/EHxFa6xc6dodq13cRadFLc3DKv91FP5sxVFGWZlUEj5q+KHjPXNQ0aH9p/QB4Fu/C3 hnxJDrNn4gh8Vv8AbZtMi3Wk1klubQR7pUkuCIjc582Ucb/krN/aX+Jngrx/pPj221T4nzWXh+b4 eNqHgQ6dr8ljY6/ct9oF2N0UipeSIY7aI2z79odvky7Ee3RyqUpU3K9r2l1aas2rLZ2ez10lLZHq UMsjKtBSXu6J+vMotL0um+yb6o+nPHXxE8L/AA90DSPEWtWeuT22talZaXbrZQyzMkt1KkUbSsG2 RIC4yzMB2G5mVW69rO3RS5M+FGTiWQn8gea+G/iV8RfBviOPUNR8ZfFB9Pv9C8V+Fp/Dmmf8JE9r pt3ofnWMn21LcSiC8Qu107zlXMflKMoEGfon9onxZDoVv4Ih1vxJeaB4H1rXltvEmuWV9LZfZoPI le3V7yJ1e2ikuFgRpVZeDtLAOTU1stcI04q/NJv7uWEkl3fvW85aHN9SXLTTWrTb07K7t30276dz d8C/Fnw38RItLu/DvhnxcLPVLzUrH7VdWUsCWj2Upif7SGfdD5jKfLV1DHBDKhBFd/8AYYPWb/v8 /wDjXwJ8NfH3h7RdWsvCfh/9pEaZZy2/juGVLjXY7uKzdb7zLW+nVXWaaVonklDySElI2dCuXZvQ fDvxISDwlp1hrniG9s/Bj+K47DxX4s0j4gX2t6X5b2BMTW2sSSfabS3a6SGORS6GJ5FXftl3HfE5 O1K9O6XS+/xNdbXemiV7/idGIyxQqSUVpeVtNbJu3a7aVlbd9VdX+uvsMHrN/wB/n/xo+wwes3/f 5/8AGvl/U9a8BeE/GPw/mg+OPibUfAniHRvEGlS6zd+MbqW3u5fMge2ihuUkVJJ0825jilQtO3l7 d7tHxwfgT4mz3fhz4SeJNT+KLeKrqbRNNSfQIPHd5p+vPci8ZHuIrYS+Vqu7bIk0Ey7x5BAYklKw p5TOcVOLdnptbrNd7L4NbtaNGP8AZ16ftFt6ev8Ak/8Ah3Y+0Nblg0XRr/WfsGp3/wBgtpLn7LZF 5bifYpbZEm4bnbGFGRkkCn6YINS0611H7Lf2v2qBJ/IuXdJotyg7ZF3fKwzgjsQa+NviF47uNIT4 tRWXxiuLm/j0XXLq213w545nd9IeNkaK0vtJuGkisJfMU20c9uFZ+g8qSQGtK8+Jet69rc7WPxIv 7fxrb3fh2TwLptrrErWmvaVcR2/2mb7Ir+VeqzNf+bMVcwiENuTZmnDKKkoKSe9vxsvuu7u9mkm7 d7nllo39enbl37L3t+nVX0PsD7DB6zf9/n/xo+wwes3/AH+f/Gvi74e/Emx0fW/COr3n7Qeq+Ir+ /wDi3rHhhk1HxTG8NxpoW8Eam2jKQsN7Wbq/l5UzRrGURkSvZv2g/E9jpPjLwboXj3xhfeEPAGr2 uoi81q01qbSNmpIkbWsUl5E6GMGP7U6oWAkaMAhsbTjVy2pTqRp3vzJvZ9FdpXtd222u9CKmXOFf 2L8+nZyi9PWL+R7X9hg9Zv8Av8/+NH2GD1m/7/P/AI18Han468WjT/Ft78Sfj34i07X9K+D9n4hh 0tdcTSBb6ruuFhZreLy5BK/+iO8Tk73ugrqy+Sie5/tF/EFB8A/CvjfSvi5L4STVta0Jl1bTdRtY luopriHzVEsiMrIIjLKQuAViO/dHvU6VMoqwqU6alfnko3s7XbsumvXoE8tcakIaPm62dvhjL56S X4nv32GD1m/7/P8A40fYYPWb/v8AP/jXxRq/xC0LwZqXje+sfj/qrReCviToemaTaX/jWS4hgtbg 2X21JvMlL3KMPtoInaRYvs8hjEZWQnqvBWueLNd+M+o33iX9oCPQdf0rxRf2kngprG+e6utNBcWx S2N8bdrcwNBP9qjswQVO6U4ckllMlT9q52Vr7O/wxktFfpNJvZO/k3U8t5YuTeno/N9L9LXeybS2 1Pq37DB6zf8Af5/8aPsMHrN/3+f/ABr468NeMmk8B+NdKh+M2jyXEVrYTN43T4g6jfaDdMbpwsNw WuPO0W4mUqjrDJtUPuQny9lJ4o+KfhNvhv4b0y/8T+JtBu7xdbGkyz/FaW10a5MMqZuf7f3fab2M CVRbxqJCSxWSICMyRkspqKXKm3rbb+7zX1f4breXKOOWOVRQXe2y7X7/ANd76H2N9hg9Zv8Av8/+ NH2GD1m/7/P/AI18O+NvirJ4r8NeDDqXxlmtZfEHgHTZLC/s/HkXh2HT9TaZkuru7Y3VubyM+WUZ YhO8RgceWjSqzdh4g1HxDd/GvUfD9z+0H/wg6aDdaU3hLTrpNRu59d04wwsxtgNQSLUWllW5ikMl vcyrwdwJTFvJpxlyznZ+9fRv4Wo9Nd3fbZN621z/ALPXJzSdtL7en+dndKz9Vf6y+wwes3/f5/8A Gj7DB6zf9/n/AMa8P/aT1iGz8a/CHQrv4p6n4VsvEHiebT76ysdXTTjqMBs5+DIMTcSGCMFHXDTq RiTymXgPFF34nf45ar4X1H4+yeAm8OXmlr4V0q9i1G6udasPJiZ/IX+0Ei1B5JVuYpPMt7mZTg7g SmOfDZe60Yyc7XTezezUem+rvpfS76WFHApwU2/s82z/AJnH81q9lofV/wBhg9Zv+/z/AONI1nbo pcmfCjJxLIT+QPNfI9z4+1678W3jy/FPVfD3jqy8Wavp/iTSTqp+zab4djguHhvRZTlreBEiWymS 7MeGkfazOJChreE/Flta/Aj4P+KfEvxW8TT+H/Glza2/jrxRJ4puybRo7aXyoTcpKBYK10sMMskf lsxG2Vizsx1WU1ORT5t+Xo/tJvTurJ2t8T0RpPLeR6+ey7XvbvdRbj3TT0vp9M/DXxz4b+KnhpvF fh211m2s1v7vTvL1KOW2n3287wOWiZtyAtGSA4VgMblU5A6n7DB6zf8Af5/8a+DfDfimOLwf4e8H 6N8bLTw14KfxX4rg1DxLd6jeTxC8W+aWyju7+1v7WWJpYHmlRpJ9sp25DllI77wBcLrfxV13wj4s /an8Raz/AGD4F0zVIbu21WPSEinVroSXv2UcMoi8iZvP86OQXCPIJEMO3TE5UoKdSMmoq7s027J2 7Wv1t2afUuvlsYym09E3pZ7c/Itba76n0/4V1KDxT4fs9f8A7F1vSPtiF/sWqo9vdw4YjEke47Tx nr0IrV+wwes3/f5/8a/Ozwl8U21vwJ4g1jVP2nvEN3eaN8HrbWoLZfGCQ/Z9ZSS5jUOYisjy7xbb o5GYu1yqyB1MKp6T4g+IOneOfitY6bqXxhntBqeoaHeafc2PxFTRbGHTntopbi0ezjvIZbmWZ3Yp NFDKGM6J5iCJkXWrkVSNZw5tFfo9NbdbX7+i0u2kFbKnTlK+yTe3ZRdv/JkvU+yvsMHrN/3+f/Gj 7DB6zf8Af5/8asAYGKK+euzy+Vdiv9hg9Zv+/wA/+NH2GD1m/wC/z/41Yoouw5Y9iv8AYYPWb/v8 /wDjR9hg9Zv+/wA/+NWKKLsOWPYr/YYPWb/v8/8AjR9hg9Zv+/z/AONWKKLsOWPYr/YYPWb/AL/P /jR9hg9Zv+/z/wCNWKKLsOWPYr/YYPWb/v8AP/jR9hg9Zv8Av8/+NWKKLsOWPYr/AGGD1m/7/P8A 40fYYPWb/v8AP/jViii7Dlj2K/2GD1m/7/P/AI0fYYPWb/v8/wDjViii7Dlj2K/2GD1m/wC/z/40 fYYPWb/v8/8AjViii7Dlj2K/2GD1m/7/AD/40fYYPWb/AL/P/jViii7Dlj2K/wBhg9Zv+/z/AONH 2GD1m/7/AD/41Yoouw5Y9iv9hg9Zv+/z/wCNH2GD1m/7/P8A41Yoouw5Y9iv9hg9Zv8Av8/+NH2G D1m/7/P/AI1Yoouw5Y9iv9hg9Zv+/wA/+NH2GD1m/wC/z/41Yoouw5Y9iv8AYYPWb/v8/wDjR9hg 9Zv+/wA/+NWKKLsOWPYr/YYPWb/v8/8AjR9hg9Zv+/z/AONWKKLsOWPYr/YYPWb/AL/P/jR9hg9Z v+/z/wCNWKKLsOWPYr/YYPWb/v8AP/jR9hg9Zv8Av8/+NWKKLsOWPYr/AGGD1m/7/P8A40fYYPWb /v8AP/jViii7Dlj2Kk9pDHBJIGlBRCwJmfHA92H8x9aKnuTttpWzjCMc5xjj1yP5j6iipk2dFGnB p3RXg1CxWCMPfQBggBzKM5x/vH+Z+pryy2+DdzZSwT2f7Qvi6CS1eaSB4tM8Lq0TTNvmZSNK+UyM SzkfePJya9Ttzut4jnOUBznOePXJ/mfqa5LWPil4f0a71a0ms9QmbRtR03Sp2hjQh7m+kjSJEy4J K+fE7kgAK4I3YIHbh3UT5aSve3RPyW67u3zOenXrJtQSfyv5dfU4LQ/2a/DfhjxBdeLPDXxd1fSd cvfM+1anY+HvCcF3P5jBn3zJpAdtzAMck5Iyabpv7NHhjRvFE3jfR/i1q1j4juJJJZtXtvDvhKK9 keTPmM066QHJbJ3EnnJzmtK8/ae8BWHxa0r4SXWg+LUm1u5ksLDX20d10W5u0Db7eO5JHmOpUqxR WVW4LDBx0mt/F3R7Dxj/AMIB4e8Pa94r1638p9SttFgiaPSo5AWR7q4mkigjJUbhF5hmZSGWMqc1 3uePVrr4l/LH4fu29dDpniMam1Nbq7ult3fz09dNzuv7R0//AJ/7f/v6v+NH9o6f/wA/9v8A9/V/ xooryOVHn+2kRz6hYtBIEvoCxQgYlGc4/wB4fzH1FRak2j6tp11pd1qRSG8ge3ka2vntplVlKkpL GyvG2Dw6MrKcEEEA1LcHFvKc4whOc4xx65H8x9RSzmdYJGto0kmCExpI5RWbHALAEgZ74OPQ0JWd 0Uqs9LHnf/ClPhr/ANDZ4+/8Od4h/wDk6j/hSnw1/wChs8ff+HO8Q/8AydVL4cfG2TxDo2q6x8Sr Lwv4KjsNevfD9v8A8VL9pW6ns3lWchpre3wAIHdQNxKKzMF2kVqyfHz4OL4j8N+FoPiP4dur/wAW RtNpIt9Ut5EuEDbAVYPht7gomMl2VgM7Wx6Uo49ScOaTa7NvpfdXW2p1Sq42MnFt3V779N+vSxX/ AOFKfDX/AKGzx9/4c7xD/wDJ1H/ClPhr/wBDZ4+/8Od4h/8Ak6uhj+J3w1mutbsYviF4Ze58NRvL rUK6tbl9MRM7muV35hAwcl8AYqrqHxk+EOk6c2r6r8VfB9nYpeyaa11ca5axwi6QZeAuzgeao5KZ 3DuKzU8a9pT+9krEYy9ru/z9fyMj/hSnw1/6Gzx9/wCHO8Q//J1H/ClPhr/0Nnj7/wAOd4h/+Tq6 bxF8RPh/4Qi0+fxb468PaJHqzbdPfUdTgtluzwcRF2G8/Mv3c/eHrXG6v8ePBWq3PiXwp4A+Ingk eKPDd1a2tymsami2qPJNHG6HY+8sN/lDAwJmRDzkVVN42fwyl977pfm0OFfGSXMm7d9bb2/Muf8A ClPhr/0Nnj7/AMOd4h/+TqP+FKfDX/obPH3/AIc7xD/8nV1ieOPBcnia48FR+L9EbxDaW/2u40ld QiN7FDgHzHg3b1TDL8xGPmHrUWgfEPwB4sv20vwt458P6zepapfNbafqcFxKLd8bJSiMT5bbhhsY ORg81n7XF2vzStvu9u5DxWLSu2/xOY/4Up8Nf+hs8ff+HO8Q/wDydR/wpT4a/wDQ2ePv/DneIf8A 5Ord1v4sfCzwzqF9pHiT4l+FdKvtLgS6vrW+1m2gltYnZFWSVHcFELSRgMwAJdQOorJ8VfFjwsNE b/hC/iX8PxrE1vaX9p/ausx/ZntJp441mPlvuKPuKRsPlaRkGTmrjLGStaUrPrd2LVfGO2r19fL/ ADRB/wAKU+Gv/Q2ePv8Aw53iH/5Oo/4Up8Nf+hs8ff8AhzvEP/ydXG6x+1L4b1LW/C8nw38S+D9W 8N3HimXw/wCJdQk1QPJZKtrczrLGqHYIm+zSHzpHC7UO1HDb19q0PXtD8T6Tba94a1qw1bTLxS9v e2Nyk8EygkZSRCVYZBHB6g1VX69Sip1JSSfm/wAe3l5DrVsZRaVRtX9e7Xfe6Zw//ClPhr/0Nnj7 /wAOd4h/+TqP+FKfDX/obPH3/hzvEP8A8nVh3v7Qehx/HKP4dWfirwTN4fsPD+o6nr15HrKSXel3 NrNAjR3KghLZFWRyS5JYq3CeWd/Z6h8ZPhDpOnNq+q/FXwfZ2KXsmmtdXGuWscIukGXgLs4HmqOS mdw7iiSx0VFuUveV1q+7X6DnUx0Wk27v19TI/wCFKfDX/obPH3/hzvEP/wAnUf8AClPhr/0Nnj7/ AMOd4h/+Tq5n42ftCaV4G1/RPAfh/wCIXw/0HXNc0+61RNQ8UXymxto4lTyllRZ4nHntJhH3YxFI Qrldtd98KfiZ4a+LXgmw8ZeGNY03UIp0EdybC6E8cM4A3x5HIxkEBgrbWUlVJxTlHHRoqvKUuV+b 81+aa+XpcnVxkKcasm7S23/rXp6GP/wpT4a/9DZ4+/8ADneIf/k6j/hSnw1/6Gzx9/4c7xD/APJ1 XbL4maFoehap4j+IvxA8C6fpkOuXOnWl/DqqRWqIjsqQzySuFF0uxxIgPDKQBwahufj98G7Lxdc+ Cbz4keHINTs9LGr3Al1S3RIoCpfJYuOfLHmkdo8OcBgTCljX8MpO2ujfRXf3C9tjbuzbt697fnY4 zxJ+y34L13Xotb0346/GDw/GIY4Lix074h3rw3ao7sPNa4eaXkOy4WRQB0AJJPTWfwI+FWn2kFhY eIvHNta20awwww/EvxAkcSKMKqqL7AUAAADgAVnfs/8AxX8S/GfTW8fRat4NvPCeo2yta2mlySNq WkXW7LWt43mPHI3lNE5IELKWxsIIavQB4+8CnxYfAQ8aaCfEwj806L/aMP2/Zt37vs+7zMbfmzt6 c9K1r1MdTk6E5yvHezd1be/p5/LQdbFYyM3TlLWO9r/15anLf8KU+Gv/AENnj7/w53iH/wCTqP8A hSnw1/6Gzx9/4c7xD/8AJ1dJF8Sfh3PLrkEHj7w5JJ4XUvriJqsBbSwN2TcgN+5A2Nnfj7p9DUF5 8WPhZp+jXHiO/wDiX4VttJtL5tMuL+bWbZLeG6XrA8hfaso7oTuHpWCqYx/al9767feR9Yxl7Xf4 +phf8KU+Gv8A0Nnj7/w53iH/AOTqP+FKfDX/AKGzx9/4c7xD/wDJ1d1c3txPosuo+HVstQmktTPY iS6MdvcMVzHmZFcqjHHzqr4ByA3Q+E6f+0nqut/s03/xJ8O3XgzUfiHpPhL/AISTUdA/tAolmPK8 0tJCrPMqbPmVWK7+BvXduF0njKibjOWjSer0ve3otNXsjShUxla3s5btLd7va+uiO8/4Up8Nf+hs 8ff+HO8Q/wDydR/wpT4a/wDQ2ePv/DneIf8A5Orf074ieEzN4f0LW/FehWXiTxBYR3lrpMl9FHdX IKbmMMDNvdRtfkA42nng03WPiH4ag1W98E6D4o8MXnjiK0e4tfD1zrMcFzIwjLrvjUPKiEYJYRth TnBqZ1MZFtOctL9Xst36eZlDFYqdrSeuvXZ9d9vMwv8AhSnw1/6Gzx9/4c7xD/8AJ1cbqP7J/gDU /Elzq8/xr+LY0e+dWvPDf/CwLx9NugI1jZZS7NcMGCjOZs9gQoCjqvgx8Z9L8e+BPA974t17w7p/ jDxboqaquiwXaxSyjBLtBA7tI0Y2tz82NpyeK9PrSpXxuFqyhKburre+ztpfzW5UsZi6UnCUmn8/ 6+Yf2jp//P8A2/8A39X/ABo/tHT/APn/ALf/AL+r/jRRXm8qOT20g/tHT/8An/t/+/q/40f2jp// AD/2/wD39X/GiijlQe2kH9o6f/z/ANv/AN/V/wAaP7R0/wD5/wC3/wC/q/40UUcqD20g/tHT/wDn /t/+/q/40f2jp/8Az/2//f1f8aKKOVB7aQf2jp//AD/2/wD39X/Gj+0dP/5/7f8A7+r/AI0UUcqD 20g/tHT/APn/ALf/AL+r/jR/aOn/APP/AG//AH9X/GiijlQe2kH9o6f/AM/9v/39X/Gj+0dP/wCf +3/7+r/jRRRyoPbSD+0dP/5/7f8A7+r/AI0f2jp//P8A2/8A39X/ABooo5UHtpB/aOn/APP/AG// AH9X/Gj+0dP/AOf+3/7+r/jRRRyoPbSD+0dP/wCf+3/7+r/jR/aOn/8AP/b/APf1f8aKKOVB7aQf 2jp//P8A2/8A39X/ABo/tHT/APn/ALf/AL+r/jRRRyoPbSD+0dP/AOf+3/7+r/jR/aOn/wDP/b/9 /V/xooo5UHtpB/aOn/8AP/b/APf1f8aP7R0//n/t/wDv6v8AjRRRyoPbSD+0dP8A+f8At/8Av6v+ NH9o6f8A8/8Ab/8Af1f8aKKOVB7aQf2jp/8Az/2//f1f8aP7R0//AJ/7f/v6v+NFFHKg9tIP7R0/ /n/t/wDv6v8AjR/aOn/8/wDb/wDf1f8AGiijlQe2kH9o6f8A8/8Ab/8Af1f8aP7R0/8A5/7f/v6v +NFFHKg9tIP7R0//AJ/7f/v6v+NH9o6f/wA/9v8A9/V/xooo5UHtpB/aOn/8/wDb/wDf1f8AGj+0 dP8A+f8At/8Av6v+NFFHKg9tIjn1CxaCQJfQFihAxKM5x/vD+Y+ooouDi3lOcYQnOcY49cj+Y+oo qJxR1Yec2na33f8ABC3O63iOc5QHOc549cn+Z+pr40039mnxBq/jWw1mfwN8MbOPU/GmpapM8/wx ffbW9oJLeHfJ9sAEU/lxzKmFy8hky2Cp+yIXm8mPFtK42jDBkIbjr94/zNee/wDDOP7P3/Ru/wAP /wDwmNO/+Ir1Mvxv1ZylGVm1bRJ/m11s/kPD4iVKM4Xa5vK+lmratd/wPIPGthqHxh+K/gbx74B8 P/E/wt4z8E+JTBd23iLSrqHSH0vd5N5MplD2ZLwlhG1u4lcSZKnaHj8wHwc+Ilz8QpIT4E1Wz+Jd t8ZD4jh8Yw6bKIJvDzoWYPqQTyjEI/3f2XfuzhdmC1fV3/DOP7P3/Ru/w/8A/CY07/4ij/hnH9n7 /o3f4f8A/hMad/8AEV6NDN6NBKMG7JWV0r7p2vzfDdfC+717dix8YxcI3tay06e9pe+q956Py7a+ k0VHvn/58pv++k/+Ko3z/wDPlN/30n/xVfPXR4vLLsFwcW8pzjCE5zjHHrkfzH1FV9Z1ax0DR77X dUuIrez062ku7iWWZIkjjRSzMzuyogABJZmCgckgc1LO83kybraVBtOWLIAvHX7w/mKfvn/58pv+ +k/+Kppq+pSi9Lo+ArL4gfC/WL7wne+I7TwW1xpPxX1HxW9zfeMPC0z22m3Ul1IuGGou2VeW2d0X PzQZG4omdn4e/Ffwbpvjrw/4m1XxX4T02yt9e8WrJGfG/h1pbO31W7guLe4YR35BRQsgcKzSBh8q MMGvuTfP/wA+U3/fSf8AxVG+f/nym/76T/4qvclnFKUeR0tLNfE+qs+nY9apmXPe9Pv1fXn8v77+ 5ed/znuB8FG+DGp+C9Wk8L67410jw1eaDY6refFywvtMupJCEjnsLa61IrCWZILhleG38vyzsLMi K3rPxK+O3w9m8PeEdK8FeIvAdvaP4cudN1GXTfEPhaTWdHDJbhLOE3d6trHDJtIlKfaAVhCqqkpK v1/vn/58pv8AvpP/AIqjfP8A8+U3/fSf/FUqucwqtOpTvq3rJ21TT0ttrey6+WgPMr1I1JU2+Vya u2/it3XSysfEngL4w/DzwlZad/wmN54H8V6XrPgXTPDF/pA8a+G5ptNmsvNSWOZJ71YZLacTCQGO SRsoQ6DK1m/FTx98NdSv/H0djq3gHX31nxN4d8SaHeWnjPw95Vp9jjsY7hUNxexSRyhLe4QEIAyy AbgGYD7t3z/8+U3/AH0n/wAVRvn/AOfKb/vpP/iqazmmq/1j2fvf4nb4lLt3il5re71M6eOjCfPG m9kt30t5dopea3u9T4dj8afC/Ub2Lwr4u8Z/D/VtP0bxtqni463J400OWPV7G6huT9h8p7oSGZ/t S2zpKqwbISfMICAx/Az4k/DnwPe/BXTrvXPBGiW3hfwxqul+ILlPGXhzyYbm5kt3UkRXzPJua1Zy yKx/fJnkuE+5t8//AD5Tf99J/wDFUb5/+fKb/vpP/iqX9sU+Rw9no/7392Ub7dpPyvay3vU8wU4u LpvW/XvzXe1t5N/8DQ+aPin8Qfgf4q8Y6TrGhfHf4WNp+tafceFvGEVx4qsR5+kyBpAVxJkyK4kj Xn5Rdu3avOfG3jT4faj8F4NP8Q/Ez4beNfGml67pcWmy2/i7RfPjsdPvQ0dz5txcRKs0kAnLYbdu udn3d2Pt3fP/AM+U3/fSf/FUb5/+fKb/AL6T/wCKrGhmdOkoKMH7rTXvLo7/AMu1/wADOnjFDl9x u3n/AMDron5Rj2PhWT4lfDt7/QdC1LWfBmpWGmfF+98Zz3beNPDj2rWU7XrxSKj34kLxtcxMVMYI MbFdxC59L+B3xw+Fmn+BfF+leIPir4K8JX2p+Jda1DTlu/GOjTNHDd3Ek8Lj7NdyqCvmgFSwIZWx kYY/T++f/nym/wC+k/8AiqN8/wDz5Tf99J/8VTrZlRq0nRlT0f8Ae9PK3TsVWxyqr3qb3vv1vN9r bzf4H5t+MfFvhHXvAGg+DLvT/At7eaD8PtV8Gyzx+OvDEtrc30jWptr2NptQWTyzJbPOWdFlR3B2 lstXsvxK+O3w9m8PeEdK8FeIvAdvaP4cudN1GXTfEPhaTWdHDJbhLOE3d6trHDJtIlKfaAVhCqqk pKv1/vn/AOfKb/vpP/iqN8//AD5Tf99J/wDFVtVzmlUUVKlonJ/FvzXvfT+8/wAFtoaf2kuaEvZf Be2r623v6Kx8XeCvjb4F07xH8EH1PxF4Wtrfwj4RutC1q5Pjnw68dpPMtpEpIXUC7qPsbuxRW+WS PGW3KvQ/BT4k/DXTvhT4N8K+IP2mdD8E3fhO1XTL3TrXxT4ZubbVghB8zewuXETDKjDwvjOVU4Nf WG+f/nym/wC+k/8AiqN8/wDz5Tf99J/8VWdbNaVRNOla7vvfrN9U19uX4dVcweKg4ezVNpade1+6 f835H576H4h+GGmT6Tqc+teHbbQNH8Q+JVHhzQfihpOjXsdnqFwk9rPavaanFEURYhC8LzJgOSqt tFeleCviv8Fvhh4/t9V8OeIfBq+Gv+EBttFtLGx+IGj3MlhLbXN5OtvI9zeozO6zxqrKXQOSC4RQ 5+vt8/8Az5Tf99J/8VRvn/58pv8AvpP/AIqqrZvCrDknB2s18T638t9W77/LQ1rZh7XmU6btK91d 21lz9u/4b9z5O+BfxP8AhzYfCPwL4f8AEH7S2jeAdQ8LWUdhfaVb+KvDFzDflCDuaQ/aj5bcqNkk bYzkA4NP+H3xq+Emg3EvgfxX4o+Huoy2fiHU9V03xqPGGgyWyLdSTSrcAPc/ao7oRzmBgsJUlSBJ sbI+rt8//PlN/wB9J/8AFUb5/wDnym/76T/4qsquY0akpylT+Jt721bvulfq921+BlLFxk5N03q7 77PXy13e9/M/OvxLq3gbxL8KLXwdrHiL4e3WseDPBeq+F47j/hONBkj8R3NxJCttPDvuwRGrQfbH a4EUiPt2K75x6d8RfiN8GNYuPhj4ms/HPhu50jw/o91pOpeGdD+Jthoup2Pnx2/lvFJBqMEEgQ25 iePz9u2XK79oFfY2+f8A58pv++k/+Ko3z/8APlN/30n/AMVW8s6hJp+z2cn8X8179OvM9tuhs8xu 4v2bVua2r+0kn0v0uv8ALQ+d/AfxF+AXhjTPD1vof7TnhvwtoekWa28Xg+Pxhol7ZxIN21JbiWN7 lmww3bbjaGXCkqMt8+2XiHwHH8HrPwXbeIPAGman4R8Ba34ZV4vG+gKddvNQVYwbcpeYFvuVp5Hu DE5YoQjMWx+hW+f/AJ8pv++k/wDiqN8//PlN/wB9J/8AFVlTzSnByfI3zO7vL/Et7XekmtbvUmhj /YvmjBt3T37X7JXvdpt6+dz4WPjzwTqZ1jwxqXxA8EC38W6l4d1601yTx1ogbw61ktqJreULdmTz YzaO0RtxKjG4wXQF2HbeCPjx8J/BwuvDPibUfAfia50jXtU1zS/E0HjLw88VwLiSaZHTz7xJ4rwx zm2OYwm4f60RtuH1nvn/AOfKb/vpP/iqN8//AD5Tf99J/wDFU62a0asXCdPR/wB7ySvt2SXZ7u71 IeLg4ezdN2069la+3VPVbeR8bfsX+OoPDN5ofw21DxHpHiK71rSYoonh8Y6He3Ojy20cnmWiW9td sXtSsYmR4UeTMjmYcbx9m1Hvn/58pv8AvpP/AIqjfP8A8+U3/fSf/FVyZhjY4us66jyt76/16fLv dnPjKzxFZ1lG19ySio98/wDz5Tf99J/8VRvn/wCfKb/vpP8A4quG6OXll2JKKj3z/wDPlN/30n/x VG+f/nym/wC+k/8AiqLoOWXYkoqPfP8A8+U3/fSf/FUb5/8Anym/76T/AOKoug5ZdiSio98//PlN /wB9J/8AFUb5/wDnym/76T/4qi6Dll2JKKj3z/8APlN/30n/AMVRvn/58pv++k/+Koug5ZdiSio9 8/8Az5Tf99J/8VRvn/58pv8AvpP/AIqi6Dll2JKKj3z/APPlN/30n/xVG+f/AJ8pv++k/wDiqLoO WXYkoqPfP/z5Tf8AfSf/ABVG+f8A58pv++k/+Koug5ZdiSio98//AD5Tf99J/wDFUb5/+fKb/vpP /iqLoOWXYkoqPfP/AM+U3/fSf/FUb5/+fKb/AL6T/wCKoug5ZdiSio98/wDz5Tf99J/8VRvn/wCf Kb/vpP8A4qi6Dll2JKKj3z/8+U3/AH0n/wAVRvn/AOfKb/vpP/iqLoOWXYkoqPfP/wA+U3/fSf8A xVG+f/nym/76T/4qi6Dll2JKKj3z/wDPlN/30n/xVG+f/nym/wC+k/8AiqLoOWXYkoqPfP8A8+U3 /fSf/FUb5/8Anym/76T/AOKoug5ZdiSio98//PlN/wB9J/8AFUb5/wDnym/76T/4qi6Dll2JKKj3 z/8APlN/30n/AMVRvn/58pv++k/+Koug5ZdiSio98/8Az5Tf99J/8VRvn/58pv8AvpP/AIqi6Dll 2JKKj3z/APPlN/30n/xVG+f/AJ8pv++k/wDiqLoOWXYLg4t5TnGEJznGOPXI/mPqKKZO83kybraV BtOWLIAvHX7w/mKKiep14e6TuvwLdsd1tE2c5RTnOc8euT/M/U14Drf7U0Nvr+taJo/h/X5HtfEO l6BYCbwVrZEjSNE96zuIAu5IJHaOP5WPlbvnV1r362O62ibOcopznOePXJ/mfqa+O9K8LeAF8Rab rutv8ZpCniTU9f1AQaX49Ak8wyJYhE8gKHSB40d/lJ8vblkJFelldGjOUpV4uSVtEr9b/ik18zvw 1OnJTck2+lvRvX5pL5nd+Ivj/wDFbw/+014S+E8+j+A5NA8V3FxbppkWqySeIrSKKKST7ZcKD5MU LiMsiYZmAI3Bsqr/ABP4u/bI0bx7pcMdj8ILfwpr3iVdLsLaVNSn1oWZdmaR1SRYDItvHJK2G2jb j2rhvEOu6r8XdZ8PD4y+CZoI/B/idNf0jX9A+H3i1r8xQzK8duIJtLHkGQJH5rrcODsACZ2uvqt3 8VfCmpfEaw8VX2jfED+zdF0uWDT4l+HXiQyNdTuPOkdDp+AFjijVCGJPnTAgYBb0HR9mqbVBOSTU tG0+qfq9npda9LW6a1Pl0hT+zZ6N+9dpNfJxb9O9z26iiivnDyCO5O22lbOMIxznGOPXI/mPqKe5 cIxjUMwB2gnAJ+tMuTttpWzjCMc5xjj1yP5j6iotUuriy027vbXTbnUJ7eB5Y7S2aNZrhlUkRxmR 0QMxGAXdVyRlgMkJpvRFLofPXwR+KXi/xb4rt9B8X/EyXTfFljLcXfi3wLr2kQWdxZR7Z1i/syVE UzWgfy28wtcF0EbGWMlo5Nvwr+2Z8DvFmuX+kWeveTBZ6dc6tFfm6s7iK5trfHmuIreeWeEgMGCX EULsM7VJBA5DT9J+Md74g8I6j8QPhd458R2fgfzJNKkWx8O22qzSyWzWzG7vTrriRGSRyyxxQl3E ZZjsIaponhL4q2/w7vPgv4j+G3xK1PwH/Zk+j6dbwweG7fVYLdwywrLeHWXSQwoVCFIIjmNC275g 30tbD4OcpSk47KyjJJLWV7aa292yl0bTk2rnr1KOGlNttatbNK2rvbTXS29t7a2ud948/aO17wp4 T1PW4fgZ46t7yyutOt4o9ShsY4JkvJxAkiSrdmNsMQpi3iVWkj3qiEupoHxw8LRa54wvYdM+IM+u PrlloK+F9SWCOQ3xs1l8mwjklWNU8vfI8jSCNzGzo7IVZuL1+D9obxr8Pb3wV448AeLb65LWE1hf WOi+H7VUmtbmK4ElzEfEEnnFmgQERtAMM+BypXn7rwH8btQ8S6t46u/h34tTxJP4isPE2l3Nto+g pb2dzb2YsZI5Ym8RM00MtvuUqHjZWbcHOAKVPC4TllGcop91LdXp236fG317dERToUHTfO4qWuz0 e1vO179nZdXZnrMP7VngzUNU0fw5oXgjxzq2u6xBfOumW2kor2s9lKIrm1nmklS3SZGJyPNKABTv /ew+Z6DpHxK8Jat8NbX4tG/ay8N3OkLrjXF2hjaC2MfmkyLzgqucgZ5HGa+c9O8JfGXRPFeg+MtH +F/i5dQ0yHWpr43WlaDIl7fam6SSzAJ4hTy4UeGAJF8zbEZWkZm3rveD9D8ZaX8AIvgF4x+BPxD1 ux/saXQp76zbw7YtJburICEbWZdsgVhzuILDOAOKwxGCwvs06UlzXV/eXed7XsrJcluuuut7TPDY bmjyy0vrqr2u9ei2t82/l1WtftZeB/C9heXHizwV450i+tH09hpbaQt1dzW17KYoLtRbSSoIS4dT udXDqEKb3jR/QfAHxFsvHx1u2Tw/rGh6h4e1AadqFhqqQrNG7QxTowMMkiFWjmjYYbIzhgpBFfMm ufD745+JvDs9vr/gTxhd+I3g0jT4tV/sXQEhS00+6F2itbjxDlppZlUySeYE2qAsaHLH0H4fX3xd 8I+N/Hfi/W/gv411SPxnf299Ha2ttoFo1mYYEt1UyNrsvmZjijydqfNuPRgq3XwWD9lL2U482tve /wAFrXtunO9+q7WvNXD0fZtwkub/ABel7X6Xct9bJfP0fT/jDYat4og0TS/BXiq70e4vLjTl8TwW kMmlLcQCTzVdhKZ41V4pI/NaIRFxgOcjPI6t+1r8O9C0m+8Qav4e8VwaWuj3GvaNdpp8dwniCzgZ VllshFK7AL5kTHzxDhJBIcIGZeY8Gr8ZvBF7eaHpXwo8bzeBbrUrvUU0e4svDzahALl2mkt0vRro TyfOkkIBty4Rtm/gMOAu/hF8V7rwHL8PZPh547k07S9Av/DPhaSbTfDzS6bZ3jIshuSNeH2qZII1 hjdfIUZZnSQkAFLBYRy/eTjbT7WvW9+zvyp2urXtrZmtLDYX2tqkly3XXW19/W1ub/yXsvZdQ/at 8MaZ/bH274bfECH+w9Mh8QXfmaZbps0mTzMXx3TjYg8pswPtuuuIDsfbcuv2nvBcfiHW9Bj8L+Mm s/Dur2ui6vrn9lLDY2MtyIvIlJldZJImaZRvjjcAYc4ieOR/H/E3gn49eKP+Ex+1fD7xND/wmPgu 18Hz+XoWh/uFi8zdOufEnJb7Tc4U/d3RctsbzOb8Kj4zeLfH/jrQ9b+D3xDXw5faro95q1t/with YvqMlhb20TC3vLrVlgWKSa0yVi+1ExYxKpcMOiGXYGd5KSsld+95xT/Dmt576aDjhKDpud1otfe6 2h+N3NK7t7qv3fReEPjvo/wx+2f8LM8VfFTxHqHhXU/F94Jre0e4ttQtLa+EO2faqxvIgKFEj2xw Aln8pCterah+1b4Y0z+2Pt3w2+IEP9h6ZD4gu/M0y3TZpMnmYvjunGxB5TZgfbddcQHY+3wHXfgn +0Brkep20nhTxHFBqY8QowHhnRC6LrUiSXOG/wCEnxlDGojOOOdwft1XibwT8evFH/CY/avh94mh /wCEx8F2vg+fy9C0P9wsXmbp1z4k5LfabnCn7u6LltjeZrVw2AqKMpzi5W196yWvZJdP66nRVoYO dTmc1rKTeuyc1a2n8rk/VJeT9a8bftb/AAe8B+OU8B6vqplu1ntba7mgu7L/AESS52GIG3edbqUE SRsWghlVQ/zEYbCaF+1N4Y8TSwLonw68eyxXer33h+1mudMhshPqNqk8htglxPG6u6W8hVmVUU/L I0bhlXh/D9n8d/CniO+1rw98PvHVta+I0spvENo+neHZd93BAlu9xYM2u4tvMjiiBSVbkAxgjvnn 7DwR8dbR9E834eeKJY9J8fXvjqQLomhqZ3ufO3W4P/CSHYB9quMPhusfHyNv5VgsDycvNG9t+frb XS3R3trqrX6nIsPh/Z7rmsvtaN8sn/6Vyp67PR9T1Lwb+0frPiH4XaD8Qbn4KeN7ufW7SfUfsmlQ 2UqR2sYVvOMr3SxgEOFWNnWZyrkRYBI1dL/aP8PeJvEf/CL+CPAfjXxHeDRrHX2e20+G1gFpdq7R OJruaFGxsAIUtksQu4xy+X4RL8MPjY3gXwv8PG+Hnii/0PwxZ3OnLpmq6Lolxp9/C/leQ91bJ4lj WaeHy3Ks5aLc4dYkdFauh+EejfGn4U+ID4k1/wCF/jLXrK28J2HhkWtno+h2s/lWJlaKQN/wkE25 z50oZRH83yYwQd1VcHgeWpOE43u+Vc3m7X17W6rfforq4bD8rdNpy1sr/wB5W/8AJb9ul7s9t8E/ Gax8d2XhG/0zwR4ltYvF0N7OovBZo+mJbMEY3aLcMylnZVCxiRlZgJAhzix4g+LVno3j2H4d6b4R 1zX9U+y299ef2bLYgWFvNMYVmkjmuY5njDKxZoo5NoHOCQD5X8KNc17S9b8U/EPQ/wBmr4sw2fjC 9F7aWV9Loto1mCoM5FrPqEckDS3HmyupXLEq2eQFqfFLS/iT8T/E+kalefAfxPb6dpEsFxayPp3h 99asJUlEjvY6kmvIbffsjDAxSAhCCGBxXL9To/WFGdox6+8tG9bW5rtxvbpe1zn9hT9pJXXLbTVe vffpvbS+uz7iP9oLSPEVjo+nw+F/GmgzeKde1DwdHe+XpzyaRqVuJg3m/v5UJzBMyMqzITH8wwQD y/7M/wAdoL/4ZeCNE8dxeJ4dQu/C76nH4g1tVaDVxbBftTJIZGlLpvBJlRN6gvGXT5q43/hBvjLB 4ksL2x+HfjiPQtL8d3Hjm306XTPDzzmS58/z4JLga8oZf9Jl8thGuzI3CXFT+BvA3xO8NWGh6J4g +Ffj/V9K8JadJo+hW1va+HbRktZXj883TnXJPPmaGIQh0EKqJJDsYsu3q+rYP2EoKUbys/i1VlL8 m11s0n11OmpRwyjKMWrX011+KXf+7y3vpva7PQX/AGj9O8GS3nhnxB4J8darrekaJH4s102elgwa faXDyyNtlnkjEqwAbCsW9jtIRWaOVY9O8/aZ8MWdnrN+/gvxVJbaDr9hoF5LEti6r9tELW12pFz8 1u4uYDx+8HmDMYw2PEfH+ufGLx58efEemaD8F/iXoOl634Jg8Nas8/hzTrkyxia4ll+zX7anHZRy eVdhVYvOd24GL5Dm54z+HHxa1ifxNaeDvhr440HRPEl5o+pSWNzpvh69kguNNFssQWUa9FmBltIt ybd+ckSAZUuOAwb5HXcY8yTfvd5K+3Tl5uW1/PoDwtBSSm0rpN691H9XJ9Votd79v8Cfi/daRPee B/G8vjLWXu/HuuaBZ+KdTjia1knjubhorVmDIysYovlMcItwf3asrAxjX/aQ8Xa34G13wXqy/FXx X4U8O6jd3VnrKaHodrqTrHHaXFyJ1R7G5lBBiUMQCgQEkLgtXHeHfDXxP0jxMLjUfhJ4/vPDFt4o vfGNnpUVv4ehuvt9y0r4nujrjrJCjTysqJDG2RHudgrB9r4iX3xt8YeNvBvifQvhF4u0qw8KXcl5 Jp95p+gXr3rSQy27gyjX4gi+VM20BCQ4BJYfJWcqVF4mNROFrO+sbX5e2ut+yaWj7kzjSeKnUTXK +Z7rduVkr3tpy9LJ36FO48Y/GI/sxeMfiC/xC1O3m0yW61nwl4ij0/TXvNX0fYsts9zbiGSEFw7L hI4pCqRkqjFlrpPCviDxrcad4r1bwR488f8AjLVNI0GSWz0Txr4Wg0SO4vZA7W3lt9hspSu6CRGJ 3IfMGGUqceW6p4C+Ott4R8VfC/wH4D8W6N4E8RPMbPSb/RNAvZtGjm+aWC1nTxFCoiMhkZVaNtgf aDgCuzOr/tO6ybiDxX4M8ZRWraXd2dsPDWl6Hpk0VzMgRLlpJfEdxvMQ3lU2qNzBjkquNK1KhKEu SVPV3Xw3SstHpvuvdkkndrQcoU9GnB+830WjaaW1++iei0Vyf4S+NPFvxR0u+0rwt8er2fVLPTRb 6zYa9oFpYeItA1J3tyxktxAsZjSMTqgMTLvJzJOMeXrfDrTfivqvjPxfBP8AHPxLqVt4O8WW+mJZ ahp2jrDe2ZsrK5lErQWMcgkzcy7WRkHyoCOpON4bf4uxfEiH4m+Ovgx4w1jU9O0ibQ9OOl2Hh3TW +zzSxyv9qdtcmM7Awx7NvlIpaU7CXG298IpvjN4a8c+KNQ8WfDPxLPYeNtZi1CRo9O0WzTTH8mC1 Lu667cvJEsVvGzBYy5IYqDkJUVVTTnKDh8Oi9x+9zJ2Wi+zfot7Xe7zqRiozUXHpb4b672dlt8vJ H0DRRRXzp5YUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU UUUAFFFFABRRRQAUUUUAFFFFAEdydttK2cYRjnOMceuR/MfUUUXJ220rZxhGOc4xx65H8x9RRUSO mhswtjutomznKKc5znj1yf5n6mpKjtjutomznKKc5znj1yf5n6mpKo53uFFFFMQUUUUAR3J220rZ xhGOc4xx65H8x9RTpZY4Y3mmkWOONSzuxwFA6knsKbcnbbStnGEY5zjHHrkfzH1FQ6rqmn6Jpd5r Wr3tvZ2NhA91dXNxKsUUMSKWd3diFVQASWJAAGSQKLNuyKSvZHhfgT9pfSvHHifU9ct/iX8L7XwL pmoX2k3EE+rKmpxtB5hhu1mExhkhmS3uZQhRMRJvEjhWA9Vj+Knwwl1zTvDEXxI8LPrGrwJc6fp6 6xbm5vInUskkMW/dIrKCwZQQQCRXxLo/xJ+Gt54j8G6rr9t4P83R/ijq/imS8u/GfhWVrWwvGuXj II1Jm3LJNbSMi55t8jcVTO/8W/jZ4W1zx9ONI8ReBZ9C0/xbpOuWz6H4o8KxRa0kIt2mnv57q+W5 M6hHijWOOIBUAaSVWAT6erk8Z1YQguVW7rTVLV9Xrfptba7XsV8uTqyUFZWk1t0lJJed0k+7TTv1 f1zL8WfhXBfyaXP8TPCkd7DBcXUls+s2wlSK3aRZ5Cm/ISNoZQ7dEMbhsbTia/8Aid8NtK8L2vjj VPiF4as/Dl8VW11i41a3jspy2doSdnCMTtbGCc4PpXw34N8Y/CDR7HwDp503wDp9ro/xS1PxVfW6 eLfCojt7SUXItJtqagQzRi4tgAuWQWh2j5Yt7tM8a+AXHh/xB4h8VaM9jpWveJxdaDpfxX0vS9TF vqV2Lu3uoJrXVI4nVceVJFJOnLsQr7VJiWRRTVm7fLz216uy7K92EssgpaNtXfbb3/8A5FP/ALfX lf7Y1L4x/CLRbi5tNY+KnhCxnsrSO/uYrnXLWJ4LeQoI5nDOCsbGWIKx4PmLg/MM3LT4lfDq/Zks fH/hy5ZdLGuMItVgciwPS6OG/wBR/wBNPue9fL91rn7P0Fr4OsPBnxV+FmhaFc6LN4P8UaPdeObO 7aPRZN0qJ5xmLSTIweIYdgv2uQhmChjV1fx14RvvgjqGk6j+0L8L9V8Y6fdWMdpGfGenqNX0/TLx ZYIZpDIAJLmNHZt3yhp8MQoOMP7Jg7W5ld21Wyu1dpJ7buzejsn1OdYFNRsnrb9PLTaW7091t6n1 KnxU+GEnh628XJ8R/C7aFePLHbamNYtzaTNErvIEm37GKLFKzAHgRsTgKccH4I+Ptleav49f4j6/ 4M8P6FoGuWmn6JqKauotr23ubOG6hc3EpVHkkWXcFQAAfKC+3e3zbqfjb4Q6v8XPD/xYmvfAoS88 eJr1xZzeMvDclxo9tHpgs2mlP24p5ktwIZisDS5W1R2IkCpVwfGfw5of7QXiz4rWPjLw7qugXGuw GLRT4+8NxQ3sAsIbU38AN+p+0RvbfKlwVUxTkgJJmumnk0bNNNtxvq1pLmj7qe17XV3ZWu7WN/7P Si0lf3b/AD5muX7ldvruvP7K0z4h+ANb8S3vgvRvHPh+/wDEGnI0l5pNrqcEt5bKpUMZIFYugBdQ SQMFh6iugr5c+C/xH8Map8bZtE8DfEDT30TUJtTuG0TUPFOhauHnkYSmTR2tbqS9RH8uSaSGZRGo ZioQrg/UdeLjcL9XlGPdJ/1/T9TzcTR9lU5f6/r+rvcKKKK4zAKKKKACiiigAooooAKKKKACiiig AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAC iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAjuTttpWzjCMc5xjj1yP5j6iii5O22lbOMI xznGOPXI/mPqKKiR00NmVILi/EMYNtCcKOTM4J49Cufz5qT7Tff8+sH/AH/b/wCIpLcYt4hjGEAx jGOPTA/kPoK+c9a+OvxUm8S6zo+j/DTxdbpJ4t0zw7pz7tDaOIIIrm9BzeFmkktzNtOGVQE5Rw4H fhcJLES5YWW27tu0v1OKnTq1OZqWi3vZf1pd+iPo37Tff8+sH/f9v/iKPtN9/wA+sH/f9v8A4ivl 3x/8Vvi34D/an+H/AIT1X4naVbeHPGd9cWb+Hrjw61vYwwJGxjZNVkANxdyMY18qMgK7ohUhgz8i 37RXxZHx81r4aal45j0XxTZ+PLfT9L8K3ttYx6LqGgSLH+9W7ZPPN55brNtE4YtIirERuRe+jkta qouDWsebrspcr6dHu17qWt7HV/Z+I5XNTVuXm+V2u3dWvttrqj7Q+033/PrB/wB/2/8AiKPtN9/z 6wf9/wBv/iKfRXkWR5vPPv8AkQT3F+YZALaEZU8iZyRx6Bc/lzUn2m+/59YP+/7f/EUlwN1vKMZy hGMZzx6YP8j9DTb20i1CznsJ3mWO5iaJ2gneGQBgQSsiEMjc8MpBB5BBosilOWl5fkP+033/AD6w f9/2/wDiKPtN9/z6wf8Af9v/AIivl74G6Ff6u+lnUdG+Mcz2/iPUYh4nuvH91PpskdreXPlo9qdQ kZ1ZYEgYS2yqcsd2Spb0Xwh8ZfHviH4l6h8MtX+Gem6XqGiPJPqjJrs8oSxZF+yXVuXso0uBM/nJ sDr5ZhbeQflrvrZfyylGm+blTb2Wi/7ef3b+WqOqrh6sZSUJXUd/h727vS+nq0t2k/XPtN9/z6wf 9/2/+Io+033/AD6wf9/2/wDiK+e9e/ao8ReEpPF2n+JPhbp76z4Y8MS+KDo+k+Lra8vIIkZAYr9T Gi2smyaOX5GnDLv8syEANLrf7THjzQP+Em/tH4Kwx/8ACL+H7fxfd58TxnbpkvnfK22A/wCnDyHx Cm+E7W/0kYXe45ViGk1FWe3vR1/Er6li72/WP93/AOSj96R7/wDab7/n1g/7/t/8RR9pvv8An1g/ 7/t/8RXhWoftK67b654pif4UXEPhnwhrdhpGqarca3Ely8V4sBiuLe2jR94H2hXZWkjYRshGZC8U fBfDv4rL8FvCt74G8L+FNV8T6te+NfFL2kEn9p3ZW2ttRZHknmtrW8uGctNEoZoyGLEu6nG5wyqt KN7auzS0d9E++lk09eg44LEygpRd22rbbOMpXv6Lbz+/6y+033/PrB/3/b/4ij7Tff8APrB/3/b/ AOIrjIfinp1r8IW+L/ivQtY8OWdro76xqGnahatHe2YRCzxtG2DvG0gA4zx0zXmXir9qLxX4Gtby 28SfBa4n1uFdKvoLPSdehnglsb65+yrK080cO2VJf3bRBGG54yH2F5I8aeX1qk3ThHVO263vay11 87bbvQwp0MRU1j6dF2XXza+9dz6A+033/PrB/wB/2/8AiKPtN9/z6wf9/wBv/iK4v4bfEHVvGV74 o0LxH4bttE1nwpqaafd29rqP22F1ktobmN1kMUR5ScAgoMMrAFhzXm2l/tP+KbtU1bUvgnfWWjze JNQ8JxKNdtZdRa/tvP2L5AAhCSGAx7/tHyyEjDRgTMo4GrJtJLRJ7rZq6trrfyuVHD4mV7dPOPVN /PRN6dD337Tff8+sH/f9v/iKPtN9/wA+sH/f9v8A4ivE/Df7QninxB4D8JeLpfhxpthf/EKS2g8L aXN4iZmnd4JJ5TdSrakQRpHDIysgmZxtyiMSgztY/ad8S6VoOneJH+FkAsm1O78M6uZNZm3abrUT yRRWx8uzkD288yxRpdEoo85S6ocKdf7LxHO6fLqnbdb/AH666addN9BrCYpu36x8/wDJ/c+x779p vv8An1g/7/t/8RR9pvv+fWD/AL/t/wDEV5RqXxg8a+HfEl14b8VeAtC0+QeEZfEOnyp4kklF/dxb VmskH2NT8jOmZBuJWWMiMlmVD46eKDo3wksb3xt8NH15NS1HSrTVdMstYEcNjJNdQKHNwfLkkSOY oBsj3Odu5UUsy5xwU3OEWviaSs073dtNbb6b77tERo1nKMW/i227J/r9+m56v9pvv+fWD/v+3/xF H2m+/wCfWD/v+3/xFeCaB+0p428QS2TH4NQ6RBqXifUfB9r/AGn4ljEv9o2yXLoJFghlVYW+ysju rsyOSFSVQHbF8N/tReOIvhf4G1jW/AEWs+LPGljcata2ultqN1ALOIxbpJfsmnTyxPunjQIIXTu0 oJGdf7KxHSKe2zT3TfR9otvyNvqOL5uXre28fP8AWLXyPpX7Tff8+sH/AH/b/wCIo+033/PrB/3/ AG/+IrxjwP8AH3xr8QPGaeEtO+Cep6IING0/XNQl8RaktjPBDctMjolusckhlVoWVVk8oPtcsYwE Mla1/aYk0bxD4i8P/Erwlpeh3Hh/w5J4lntdL8SRarfW0StGBb3kCxxiC4ZZoWUB5I23HEhA3GHl tdScOVXSvZNN29EzP6tibtdVbrH7Vrffdel9T3D7Tff8+sH/AH/b/wCIo+033/PrB/3/AG/+Irwn 4n/Fn49+EfA+p6z/AMKq8O6Vcw32lW9peHxSbq3lS7ult2GPsgdZkZ4gwKGMCUsryFPLanonxiGl +MfF2nxfCmHSvH+q+JrHw4LS58Ql7bVLkactyJmnSJxBAturlSsRdgE3Ro7FFqGW1ZQc0k7dmn/L 57e8rvW3W26qOFxEoOad1rs4vazbfZJPfp1PoL7Tff8APrB/3/b/AOIo+033/PrB/wB/2/8AiK8E sP2mvF2veJdF8E+HfgvNLrmopq1veNe69Db2NlfadMkU8PmiN5ZI/wB4rLKIRkSxYQ5k8r1n4a+N rX4k/D/w74+srN7OHX9Nh1Bbd5A7QmRAxQsODtJIzxnHQdKyrYGrSh7ScdPVPuls+vK7d7GdajiK SvU/R+XT0f3M6L7Tff8APrB/3/b/AOIo+033/PrB/wB/2/8AiKfRXLZHPzz7/kM+033/AD6wf9/2 /wDiKPtN9/z6wf8Af9v/AIin0UWQc8+/5DPtN9/z6wf9/wBv/iKPtN9/z6wf9/2/+Ip9FFkHPPv+ Qz7Tff8APrB/3/b/AOIo+033/PrB/wB/2/8AiKfRRZBzz7/kM+033/PrB/3/AG/+Io+033/PrB/3 /b/4in0UWQc8+/5DPtN9/wA+sH/f9v8A4ij7Tff8+sH/AH/b/wCIp9FFkHPPv+Qz7Tff8+sH/f8A b/4ij7Tff8+sH/f9v/iKfRRZBzz7/kM+033/AD6wf9/2/wDiKPtN9/z6wf8Af9v/AIin0UWQc8+/ 5DPtN9/z6wf9/wBv/iKPtN9/z6wf9/2/+Ip9FFkHPPv+Qz7Tff8APrB/3/b/AOIo+033/PrB/wB/ 2/8AiKfRRZBzz7/kM+033/PrB/3/AG/+Io+033/PrB/3/b/4in0UWQc8+/5DPtN9/wA+sH/f9v8A 4ij7Tff8+sH/AH/b/wCIp9FFkHPPv+Qz7Tff8+sH/f8Ab/4ij7Tff8+sH/f9v/iKfRRZBzz7/kM+ 033/AD6wf9/2/wDiKPtN9/z6wf8Af9v/AIin0UWQc8+/5DPtN9/z6wf9/wBv/iKPtN9/z6wf9/2/ +Ip9FFkHPPv+Qz7Tff8APrB/3/b/AOIo+033/PrB/wB/2/8AiKfRRZBzz7/kM+033/PrB/3/AG/+ Io+033/PrB/3/b/4in0UWQc8+/5DPtN9/wA+sH/f9v8A4ij7Tff8+sH/AH/b/wCIp9FFkHPPv+Qz 7Tff8+sH/f8Ab/4ij7Tff8+sH/f9v/iKfRRZBzz7/kM+033/AD6wf9/2/wDiKPtN9/z6wf8Af9v/ AIin0UWQc8+/5DPtN9/z6wf9/wBv/iKPtN9/z6wf9/2/+Ip9FFkHPPv+Qz7Tff8APrB/3/b/AOIo +033/PrB/wB/2/8AiKfRRZBzz7/kQT3F+YZALaEZU8iZyRx6Bc/lzRT7gbreUYzlCMYznj0wf5H6 GionZdDrw7m0/ef4f5BbjFvEMYwgGMYxx6YH8h9BXydpXwY8OWWt6bruofsd6vf3Fnq+p6vcM+j+ Ew9011LI8MbN/ah+SBZNqg5yURvlIr6xgtGMMZFzMg2j5QqgLx05QfyFP+xv/wA/s/5J/wDE124X HTw6fJ19V+TXcdKrVpKUYrR+vmujXdny0+jfHHxTc2Vj8W/h/wCN/F2haR4gTxHpsCaT4ZsL6OaG XzLaKW4TW2jeKPodsEbvgZfBZW5R/gr45uL1NFv/AIVePbrwXH46bx9Hp8ln4dOqrdkmQxf2gdcK +UZCST5HmFCU3j71faH2N/8An9n/ACT/AOJo+xv/AM/s/wCSf/E12U86q0/4cIr0T8tbX30Wu/md H16tqlGKT7ad9tdPie1txaKT7G//AD+z/kn/AMTR9jf/AJ/Z/wAk/wDia8jmR53spDLgbreUYzlC MYznj0wf5H6Gqmvx6tLoWpRaA6pqb2kq2TNMIVExQ7CZDFKEG7HzGKQDrsf7ptz2jeTITczONp+U qpDcdOEP8jT/ALG//P7P+Sf/ABNNSSdylTkrM+W9C+Cn7R2haRB4ZXXI7vQkvjfT6ZcePLURXZa4 NzLHLJH4XWYxySM29VkXKuy5AOKt23wa+O1r4i0bxYljpTaxpV5fXVxff8LC2z6ol2yGSC7dfDoZ oVWKJI0Qp5axxhSDFGV9z1L4h/DfR/Ef/CH6v8UNAsde8oz/ANlXOq2kV55YQyF/JYh9oRWbOMbV J6CumFqWAZb6Yg8ggJz/AOO16k8yqL3pU0ua/Rq99H11v1O6eJrL4oJc2vVXv1389/8AgHxxH+yl 8ZIvDy+FYbm3h0qPQ7rw6lvF46tIwLO5ZXnQsvhYM7yMgZpGLSFizFtxJO/rfwF+O/iD/hI/7TNg /wDwlPhm38Kajt8eQrutId2CuPDXyyN5k+49P374C7Y9n09q11p2g6Xd63reurYafYQvc3V1cvHH FBGoJZ3YjCqACSTWLpfjrwfrXw/j+KWmeJppvC8umtq6X/2ZlzbKhcyeWYxJ90E427vatHm9eS5+ RNX3s93r33bTfnqaLF4mUlNQV2+z3un33uov5I+WfCHwo/aavviH4qu/FfgCOPQrjUdMvPsl/wCP rOPT9aksIIYIppGtdJkuG3PaxzldtohyqNEQGU9FY/AH42aW8Gpabaaba69Z6zqGtWmtx/EFRdQN fnddwbP+Ec8iSCR8PtkicqyqVK7Rj6f0yW11jTrXVtO1Oea0vYEuYJNirvjdQynBUEZBBwRmrP2N /wDn9n/JP/iaVTOKvNZ04qySt73RW117Kz7rR6aEPG1JbQilZKyvayVu/ZtPvc8eudK+OGp+Drnw N4g+F3gPWtNv7KSwvzf/ABE1CSW7jkUrJvYaOMFtzfd2hc4UKAAPNLz9n3426j4Ym8O6nDY3lxKu nQLq8/xDV72O2sJfPtrdT/wjnlbFm/eMxjMrkAO7KAtfTfiDV9I8Laa2ra7rUttbCRIVPlh3kkdg qRxoqFndmIVUUFmJAAJrR+xv/wA/s/5J/wDE1hTzGVL34QSu7/a3WvfpczhXqU1aMFbfr/n3S+aX ZHg/grwf+0D4K8U+LfFsfhrwvq9z4wu4r28g1Dx64hgeOJYUEIh0CNgBGkafOzZCAn5izHzD4Z/C v9pu/n1zV/Fnw/i0QS+JNV17StJ1Hx9aLb2FzemUi5gW20m6MjxLcSKv2iRk3Ev5I+XH1X428WeF vhx4W1Dxr448Uro+iaXF511d3G3agzgAAKWZiSAqqCzEgAEkCk0LxZ4Z8S3up6doviKa4uNHS3e9 UwGMQrPEJojlowDmNg3BOOhweK1hmFRU5zVFNNJN2lolZW3stLL7jWOIrKDapq0ra6/ZVrLW20rP 1t118Ft/gz8Zrb4Z+F/htH4a8PD/AIQu5gutA1wfEGRdSsHhyse0jw+IXAjZ4iHiYMjHdk/NUN98 DvjBqeknRNQ8LeHLqyl0/UbW5huPHzTJc3V+WNxqEiv4eKm7O91UgCONHdEjVGZT7/4I8YeE/iRo K+KPA/ioaxpL3E9ql5bqPKkeGRopNjFBuUOjAMMqwGVJBBrS1u9sPDujX/iDWdVnt7DTLaS8upvL D+XFGpd22qhJwoJwASewpTzOrGbU4JSu2/ivd6PqJYjEKfIoLmT21ve7037t6dLvuz50Pg34/wCp 3Hg/wj4k+EXh3XoPANzDrFl4n1v4hNK97KiSRrEzQ6VHIZF3ozM8GxhGCSz/ADDpPil4V+PvxV8K HwjqHg/wjotu15bXzXGl+PpvOL28qzRj9/oMq7RJHGx+XJ2AZwSD7VpktrrGnWuradqc81pewJcw SbFXfG6hlOCoIyCDgjNWfsb/APP7P+Sf/E1E8xaqKTppSi7/AGtHe97c2juYqvLmjOMI6bb6de/d t/l0PlbTfgJ8d9OXR1LWFz/Y3iu48ZIZvHkI+0X0+/zPM2+GV/dnzrj5U2489sH5Y9k2nfAf406L ovhnTdD0vSdOvfBjTx6Bq0HxC/0uytJkCPZ7W8OmGaA7UP76ORwyK2/IBr6j+xv/AM/s/wCSf/E0 fY3/AOf2f8k/+Jqnm9T+SP4+nfs2vRtbM1eMrN3cV+PW9+vXmf3nz14c+HXx98O+O9R8fDR9D1G6 1TSINGubW++IsrwtHEzurh10BZhJvmnfiTaDKQFCrGqcd4b/AGZfiroNra6Ne6HomtaDbaHeeHf7 GvfHccVtLZ3RDTLI9t4bhmZ2dVkMvmeYXG4sSWz9bfY3/wCf2f8AJP8A4msDwt4y8I+NrvXLLwn4 sXVJfDeoHSdU+zgMlvdKiu0W/ZtZlDqG2k7TlThlIDhmdW0nCC2V99Fqk99Piavvra4RxVdJuMV0 116Ky1vo7LffQ8KuvhR+0Nq/gu98EeKGsdftpxafZbq++IYFxYNbTRzRPGYvDiLI/mRRktOspO3B 4Zs5k/wE+N15f6trl/a6Zca1qer2WvQ6ofH6R3Gn3trCLdJoAnhtY/mgHlOkiSIyk/KCSa948R/F H4d+E/E8XgzX/Gy22ty6dJq5sliMskVnGyq88uyMiOMFvvOVGFc9Ecr1kMSXMMdxb6lJLFKoeORD GyupGQQQuCCO9P8AtKtTXP7NJS12aT1W2vVxV7btaj+sVqat7NJPyaXTz2atdbNep8z2/wAF/jlY a1oniHStN0ax1HRLXUolnj8fCRrqfUG8y6upvM8OsDM0ixuAu2JfKVVjCZQ+w/A7wLqfw0+Fmg+B dWkZp9Hha2VTqCXwjjDt5aidbW18zCbeTCpHIJbG9u6+xv8A8/s/5J/8TR9jf/n9n/JP/ia5q+YS rU/ZtJLyv5vq31k/vMK1apVjytJa36+fn5t+otFJ9jf/AJ/Z/wAk/wDiaPsb/wDP7P8Akn/xNcXM jl9lIWik+xv/AM/s/wCSf/E0fY3/AOf2f8k/+Jo5kHspC0Un2N/+f2f8k/8AiaPsb/8AP7P+Sf8A xNHMg9lIWik+xv8A8/s/5J/8TR9jf/n9n/JP/iaOZB7KQtFJ9jf/AJ/Z/wAk/wDiaPsb/wDP7P8A kn/xNHMg9lIWik+xv/z+z/kn/wATR9jf/n9n/JP/AImjmQeykLRSfY3/AOf2f8k/+Jo+xv8A8/s/ 5J/8TRzIPZSFopPsb/8AP7P+Sf8AxNH2N/8An9n/ACT/AOJo5kHspC0Un2N/+f2f8k/+Jo+xv/z+ z/kn/wATRzIPZSFopPsb/wDP7P8Akn/xNH2N/wDn9n/JP/iaOZB7KQtFJ9jf/n9n/JP/AImj7G// AD+z/kn/AMTRzIPZSFopPsb/APP7P+Sf/E0fY3/5/Z/yT/4mjmQeykLRSfY3/wCf2f8AJP8A4mj7 G/8Az+z/AJJ/8TRzIPZSFopPsb/8/s/5J/8AE0fY3/5/Z/yT/wCJo5kHspC0Un2N/wDn9n/JP/ia Psb/APP7P+Sf/E0cyD2UhaKT7G//AD+z/kn/AMTR9jf/AJ/Z/wAk/wDiaOZB7KQtFJ9jf/n9n/JP /iaPsb/8/s/5J/8AE0cyD2UhaKT7G/8Az+z/AJJ/8TR9jf8A5/Z/yT/4mjmQeykLRSfY3/5/Z/yT /wCJo+xv/wA/s/5J/wDE0cyD2UhaKT7G/wDz+z/kn/xNH2N/+f2f8k/+Jo5kHspC0Un2N/8An9n/ ACT/AOJo+xv/AM/s/wCSf/E0cyD2UhaKT7G//P7P+Sf/ABNH2N/+f2f8k/8AiaOZB7KQy4G63lGM 5QjGM549MH+R+hoontG8mQm5mcbT8pVSG46cIf5Giom0zqw8JJPQsWw220S4xhFGMYxx6YH8h9BX xDrHj/xt4i8carYyeJTLB4g8d2NlmP4SeIWL2+l7Lj5JROVKJPbyxyRAM3zSyHYjEL9vWw220S4x hFGMYxx6YH8h9BXjenfCL4u6Tc2V3p/j34cRS6ddXt7bN/whGptsmvJGluXwdbIJd3c85xuIXAOK 9PK69KjKU6j10tfune/wy6pfJnbhqsIKak7N7fc/J6p2fT9DyH43/DuX4c/tP/C742r4c1q406+8 QjStZ8S2niCa4vne6BhtLSSycJFDaCSRV/c7iyK24ByDJ534gh8e6N8U7eLW/D+t2PxevvjQsuha 2dOm8vU/DhiAaCK+2eU1qkGS9vv+XBJUNur3/wAJ/sweMvBGqNqvhvxh4CgJvpdUS0m8Ma5c2MF3 IxZp4bOXXmgilyTh0jVlDEAgEitjw78DPid4X8RXnjDTPG/w6m8QX4ZJdX1HwZquoXyxMQxhjuLj XJJI4MjIhRljB5Cg17FHMsPSjFOopcsbK6kr6qST303Tto42Vlud8sZR5XHmv7vKm09fitffS0tv JJWsj3OiiivlDwiO5G62lXGcowxjOePTB/kfoai1Nr5dNu20yNXvBA5t1Y4DSbTtBPYZxUtyN1tK uM5RhjGc8emD/I/Q1FqVrPfaddWNrqVzp01xA8Ud5bLG01szKQJEEiOhZSdwDoy5AypGQVa+hcXZ p+Z8/fs5WHw51j9lpLPx9BpN8s4um8fJqaq7nVfMLXn27dz54cDlvmAEZU42moPG/wASfFOifEPT x4K8d6/faRYeJtI0LVNJh0Gzh0jSre5EC+TdXNwBdS3bCfzB9nc+UPLWWNMhn6K7/ZX0i/8AFaeP L74l69c+Jo5EmTWpvDHhR75XRQqMLg6P5gKhVAO7IAAHSquv/sheFfFety+JvFHjnVNY1icoZdQv /CXhK4uZCihV3Svo5Y4VVAyeAAB0r6FV8JLEuvUmmpO7jZtJtq6V47Wuk9GtN1dP0Oag5Tcp3upb puzl8t/7ys20tOho/DfX/GXxDuz8RH+Kbabp1n4h1LRNR8JSafZvbIIJpraOLzdq3MdySsMxYysr bsLGFZSPnrwp44+MXw4+APgw+FfiPBGNV+F2ta3aQXGiW8tvpj6cltJE0I4keRo5ZFZpZJI95DiI KPLPv15+yxpWoeIbjxdf/EzXrnXbyFra41Sbwz4Ue7miaPymR5jo+9lMf7sgnBX5enFZFx+xT8Pb yC1trvxJcTw2MRhtY5PBfhBlgQuzlUB0bCqXd2wMDLMepNVQxGDhdSlGztpy7WjNfy62ck7vV2sz ehXw0J3m043Tty9r6bedr9UtexxyfE/442TeMfE+sfFGKey8KeKPDVpb6ZZ6BawxXFtqC6f50U7v 5khwl2xDI0beYGbOwrEnU+GPEfxl8XfGOGxPjPxTaaZY+I9Tj1bT7TQLX+w1023LJa+TqMloxlld xGk0aTmVXaYBYfKIFiP9in4exWM2mReJLhLO5ljnmt18F+EBFJIgcIzL/Y2CyiSQAnkb2x1Nc9ov 7E/iKx+IsnjbUPjnEyLqEupWtxp3w90Cz1yOUyF0L6n9ncvjO1x5Sq65XaqnbW3tsvnze9FOzt7j /litlHe6k7vvuQ5YZ0muZc1t+V66W7aa3d99t7WPWvEdxPe/tB+D9EvRtsbbw1quqWRJHzXgltIC 6g9XjhnlA9BO2etcP4N1/wCJM/ijV/hL4g+KfiBvEPhnxEdXutUn0/TI0ufD7Rb7cELahNjt+5Yr tl8yOZldVUIOl1/4DeL9ZubDWI/2kfiFFrGjmWTTLuSw0FkgeSNo28yNNOj82MhsmNm2kqrcMqsN Jfg74sS9l1JP2h/iAt3PEkEtwNM8NiR40LFEZv7KyVUyOQDwC7Y6mvNhOjGko88W+W2qe/M5J/C+ js1169Dn5qfLy8y2XR6PVP7L0abf+Kz6HgXiT4ieMNd8G+P9H1Dxxrvizwt4g+E+ta1Y6lq2h2Om Wt3PEir5mnRRqtytticgC5DFgiPHJIrbzqeHfit8Tk8SL8KNU+IMOmQ6p4q07Q9P1qz0y3hbS7Rt Ejv1t4VmWaN7iVwIt828Eu5VFOxF66P9iL4bwtI8OvSo0qlJCvgnweC6nqD/AMSbkHuKs2n7Gvgm w0y/0Sx8X31vp2qeX9utIvB/hFIbry2LR+ag0ba+1iSu4HBORXpfWsvUXG6d/wC715r3+G10tHol LqknY6518K00mutvd2bUVfa2nLdrZt9DzjwXrni3w78Mh4X8P/FDxMviU6/4uuUtNC0HTrjUtXeD U5Va5mkuk+x20CF9zhhFvZ0SNw22N6mreNPi3qD+I/ihoPxYvdP1Sz+Cdj4titH02zudPiuJFumm RIjGHHNvvUmQkORv8yNRFXp037FngC5tE0+48T3MtrHM9ykD+DPCDRrK4VXcKdGwGYRxgnqQi56C rNz+x94RvLKz0288balPaadbvaWcEnhHwk0dtC7F3jjU6PhEZiWKjAJJJpfW8Hdy5otu+rj3v/d2 1WnTXW1kq+s4bnc3Z3k27rvNSttrora7XZzGp/GP4m3U+veINJ8U/ZLjwVqvh7S/+EaktbYw67Fq CWu+aRzH5ySO11IsXlOiBrcBlfLCk8CfEP4zQ6v4c1Txl8S49Yh1D4nat4IuNOtdDtrS0e2hW/Mc g+/MJFe1TaRLjZ8riRgZG7a3/Zc0201TSNctfif4gh1LQLVbHSbyPw14VWfT4FDARW8g0jdFGA7g KpAG5uOTVCD9jzwhayWstt411GJ7G9bUrVk8I+ElMFy2zM6EaP8ALKfLjy4wx2Lz8orP6xgLOPu2 f93XZL+Xum79Oa20Uc6nhvZezur23tr8Ml2/malfd2s9kX/inq3xSn+NPhvwN4X+I48N6Bq3hfVN RuBZ6Pbz3wntpLUKyTXHmRjPnqMGIgL5oILOjxeZ+H/jt8YfD3g/w94+1/Xl8WXHiT4Wan4wbSE0 2C1tre7s1tGj8ny180h1nfzQ8jgtloxEuIx6dr/7MNl4r1dPEHij4p+I9Y1SK0ewS+v/AA34VuLh bdw6vCJH0gsI2EkgK5wQ7Aj5jVXR/wBkzw94d1HTdX8P/ELWdMvtHjeHTrqz8K+E4ZrNHLl1hddH BjVjLKSFIB8xs/eOcqNXBxoqnNxbSf2Xr8fXlv8Aajrv7pcKuGUYqVna3S1/na/z9fnxWu/GT4h+ Bo7zRj8SI/EOna7pnh69tPFV5aWaHQTql41pJIVhiSF4QimaEyKcMCJGkXpgf8JH8R/htrnjrwr4 d8Zf2hrXij4p2WhN4i1qW1sZIxJotvLGDJFZS26Ss0cUCk2rqxcDbubcPXNK/Zc03QdA1DwnofxP 8QadomrljqGm2nhrwrDa3ZZQrebCukBHyoAO4HIAFU7H9kPwtpem6jo2meOtUtNP1iKOHUbSDwn4 SjhvEjOY1mQaOFkVTyoYEA9K3hisDFy+Gz8mrq8HraOluV6LSV7vbVwrYaKabT+XW1r7f9vcu1/v MTwuPH6fGr4W2fxR1rQdW8R2Ol+KbW4udKuROPLD6a0STsIIF88I679sMak/MFUNivRv2fGmg8G6 toaw7NO0HxRq+k6VgAKLSG8lWNFAAASP5oVAHCxAdq5Y/sqQ6e+lX/hn4q6tpmqeH4/I0a8/4RHw sx06IsS6QbNKRowweXhGUZckg8g+mfDPwCPhp4XTwrH4s1rxBBDM8sVzq62gnQPgspa3ghD5fe5Z 1Z2aRizHgDixlejKio05JvayTX2pSulay+K1r9zlxNSnKlyxkr3T6/3tNtveX3bbHV0UUV45whRR RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQBHcjdbSrjOUYYxnPHpg/yP0NFFyN1tKuM5RhjG c8emD/I/Q0VEjpobMow2NmYYy9nDuKgnMQznH0H8h9KwdS8X+A9Inv7bULq3ik0u4srW7AtHYRy3 kixW8eVQgs7ugwMkb1LYDAnpLcYt4hjGEAxjGOPTA/kPoK+JLPwB418S+Obe4t/Dfm2/iLx7e3Y8 34teIRvh0sGBg8XkFcCe2SSOX5mGY0AVMMvr5fhoV5P2srJW7d1fdrpd/I5KGFp1FOc9EvTXRu2r XRM+rPE/xE+G3hDX9P8ACesXiSa7qaiW20rT9Nm1C9MRJXzmt7eOSRIAVIMzKIwRgsDV7xD4q8Ce FNW0HQvEF9Y2mo+J7xrDSbZot0l3MsbSMFVQSFCqSWOFGVBILKD8P2WqeObb4qape6Jruuab8Ybz 4zJbaloY1GYR6n4bEREckljv8prSO3HFwUJXHDglTUfxL1T49Q/tS/C7xJ43+BrJqreLL+HRbj/h KLN47+xCFY4Yo13fZljibzmLktLI7/d+VE9WlkkJzpx594tu7Su+VP3b2utbXu72bsrHfLJ6alJK S0jJ7pNtKVmk/s3jur6NN21a/QL7BY/8+UH/AH7FH2Cx/wCfKD/v2Knor5y54fKuxVmsbMQyFLOH cFJGIhnOPof5H6U/7BY/8+UH/ftafcDdbyjGcoRjGc8emD/I/Q1Fqdo+oabd2Edy1u9zA8KzKMmM spAYD1Gc1Lb6FxhB2T0PLJfjt4Vls9T8Q6B8NfFniDwrpLTxz+I9K023ms5HhyJBBEZhc3Ch12eZ FC8ROTv2qzL6jbW+mXdvFdQ2cBjmQSITEBkEZHavCfgZ4p1D4U/DXRvgx4l+HvjD/hKPCkX9jxLZ 6Bdz6fqm3mK4i1BIzapHKGViZZEMbblcArzwfxcikl+MkHiC3+DuqWesaD4q0e5n1218LazrV9qd sFtzObO+hi8i0tI42lRogz+cfNzFC3zP7TwEKmIdCnpHpLe6ukna/W97rbqtGzveCjOcoxjy8qb7 3Stb7/5ldO+iSTPqvV0i07S7u/svDp1O4t4HlisrYQpLcMASI0aRkQMx4BZlXnkgVyHw/wDHEvxD +DmlfFDSPA0A1DWNG/tO20X7VH80pQssH2hkVRlgF3lQBnOK8y8BaV4VsPFtxrPxL+GHiZ/ido2t 6pcjxFbeHr+VbuzdpjAyX8CGKWD7JJGi2rSFlZNgi8xVz8+XXgJdM+EHhTSLH4YfEW31nVfhjrml +IDZ+GNcW6uL9vI+w29zLHDuKCWCULG7eWsZwQIpAGdDL4Ti4Nu/u2dv7s27e9qnyqz0100N8Nlt Gc/Zy/mWrWjWt/tbWSaate/TRn6A6bbrdada3Oo6JBZXcsCST23ySeQ5UFk3gYbByMjg4zVn7BY/ 8+UH/fsV8KQ+F9Os7Txt4z074afEO41yPxZ4Y1DQbi+8La9PdQrGtib2S2E0JeNQILyNygX5Fjj+ 4YVPXeE/DPhK9/aAtvEHi/whE0mn+L9UurPxPqXhfU3vdQmlkaG2tZrl7H7JHHC+BBILtiBDAgji dmVbqZTFNtTez05evLGVl7396297oweWxjSdS70W3LrtfXXZaJ+fSyZ9N+LtesvDjadpunaBDqmt azObfT7EFYg+0bpJJJCp8uGNfmZsMeiqrOyq3Ov4/wBT1D4jXngzwl8OLXWNN0G/t9O8Rag2oR20 1g89uLhHit2j2zxqjxbz5iOC/wAqPtNN8RCbTv2hPBmq38wWw1Hw5quj2e4gKt4ZbS4KDJ+88NvI wAySLdj2r5i+I/w+8Gz+KPibf6b8HvFtteXPjzQrqxvNG8F6xbPcWcbWR1BkmtrdfMi8yG5lI3EN IqyrlzG5ywGEpVXGM+qv1dm6ihrqtEry+96pWKwuDo1LqS+zo7X1btfdbbeqe6PuP7BY/wDPlB/3 7FVNXSLTtLu7+y8OnU7i3geWKythCktwwBIjRpGRAzHgFmVeeSBXy98Zvg34e1D4gWOhavoPi7R/ h2PDUcPh1PBfhW1vodNv/tErXAEP2G4ksZ3WWBkuIxDzG26QFRjUfQv+Ee+PFt4ts/CGp+IbyNoT qM2ueCLp9T0uNLBo5J7HXLeIwzqVKhrTMheQy+WQxCHL6jF0+eM7uzaVu2yetl5/y/NMhYGmkpRf Npe1tHtpe/nZ9mrK7sj2v4S+LrL4o/DTw38Q28NwaWfEGnx3xst6z+RvGdnmbV3Y9do+ldb9gsf+ fKD/AL9ivz1uvAS6Z8IPCmkWPww+ItvrOq/DHXNL8QGz8Ma4t1cX7eR9ht7mWOHcUEsEoWN28tYz ggRSAN3OueFtcs4vFXh/4TeBfG2n2uqeCPDt1qZt9Bu7WfU5obx5NQQTXsPlT3r2cqoyzb2kP7tg xV0HdXymm6knTnypyaV1okpNau+ySvftbudNXKaXNeEtG3utkpRjrr/ev6Lft9o/YLH/AJ8oP+/Y o+wWP/PlB/37FfJFx8KvAml/Dd7Hw63j+fSJvEsOpw2niH4XG/0tp1gdHik0G2sreRLdlHMiQxjz ijrIW3Zl1PwzqLax8OtePwptpPEWm6RpVrH4Xu/Bl5eaZZrFc7kk07V1iH9lzIqsxS4bGPKWRVKl q5VlsG7Ko97fC+1+/fTy3lZWOX6hTtdS7/Ztt6/j0XU+svsFj/z5Qf8AfsUfYLH/AJ8oP+/Yrw/9 pLwvpfibxp8IotY8O+I9YsIfE0p1GHT7PUbqyW1aznib7WluDF5bSSQIfOGCjyqcxmYV5B8O/DUH hvUPAGseGvh14u0vV4viFrlmbqbwlqqfYdFlW9FrCTJBiCwzcWbiMbIlYu+AySsudDAKpQ9rzO+u lr7X638uw4ZfCVFVFLVq+3+PS9/7nbqj7P8AsFj/AM+UH/fsVxOieOINX+LHiX4YTeCzZL4e0qx1 OPUZZYWW+W5edf3caZKqpgIy5DE7vkChWb5m0PwZ8Uz4Ze6+HnhDxF4d+JNp4M1fT/G99Jp8lgNc 1UvGLeRLuRRHdzs63MsVxGziNXwWQOqmlfeEofN8eL8C/hJ4z8KafrfhPQHmsrXwlcaTPdC2vpm1 G3U3VuIHujbOq7X3icsR+9BauqnldNOUZTT6X6L3rcz12srp6px1stDeOWUuWUXJX0S0296Cd9eq btvdXelj6d+Jfj+XwF4g8F6Bp/gBdW/4THVX0hb17mK3trKUW8syCQ7XkJfySBtQgAMSwIVX6Lwd r+ieMtKlv7fR2sbmzuZLG/sbqFVns7iM4eN8ZB6hlZSVdGVlJVgT8z6T4L0DwXcfD+LwDpfxN1DS JfiNBq1yNR8GyWFvYKNPureRo7O2sbcWsW+aDczQojs7OGbbIy+4/C22mk8f/FPXrZwdKv8AxBbw W+0ALJPBY28NxIMdf3i+UT13QMO1YYjC06dJpbpN31V9Yq1n/if3epzYnDUoQXIum/d80laz2dkn byeh6J9gsf8Anyg/79ij7BY/8+UH/fsVPRXlXODlXYg+wWP/AD5Qf9+xR9gsf+fKD/v2KnoouHKu xB9gsf8Anyg/79ij7BY/8+UH/fsVPRRcOVdiD7BY/wDPlB/37FH2Cx/58oP+/Yqeii4cq7EH2Cx/ 58oP+/Yo+wWP/PlB/wB+xU9FFw5V2IPsFj/z5Qf9+xR9gsf+fKD/AL9ip6KLhyrsQfYLH/nyg/79 ij7BY/8APlB/37FT0UXDlXYg+wWP/PlB/wB+xR9gsf8Anyg/79ip6KLhyrsQfYLH/nyg/wC/Yo+w WP8Az5Qf9+xU9FFw5V2IPsFj/wA+UH/fsUfYLH/nyg/79ip6KLhyrsQfYLH/AJ8oP+/Yo+wWP/Pl B/37FT0UXDlXYg+wWP8Az5Qf9+xR9gsf+fKD/v2KnoouHKuxB9gsf+fKD/v2KPsFj/z5Qf8AfsVP RRcOVdiD7BY/8+UH/fsUfYLH/nyg/wC/Yqeii4cq7EH2Cx/58oP+/Yo+wWP/AD5Qf9+xU9FFw5V2 IPsFj/z5Qf8AfsUfYLH/AJ8oP+/Yqeii4cq7EH2Cx/58oP8Av2KPsFj/AM+UH/fsVPRRcOVdiD7B Y/8APlB/37FH2Cx/58oP+/Yqeii4cq7EH2Cx/wCfKD/v2KPsFj/z5Qf9+xU9FFw5V2IPsFj/AM+U H/fsUfYLH/nyg/79ip6KLhyrsQfYLH/nyg/79ij7BY/8+UH/AH7FT0UXDlXYg+wWP/PlB/37FH2C x/58oP8Av2KnoouHKuxB9gsf+fKD/v2KPsFj/wA+UH/fsVPRRcOVdirNY2YhkKWcO4KSMRDOcfQ/ yP0oqa4G63lGM5QjGM549MH+R+horObZ14anBp3SI4ZVjhjjMUwKqBgQtjp7KP5CvPf+FGeBP+gz 8TP/AA4XiX/5Nr062G22iXGMIoxjGOPTA/kPoK8S1r9r34RaZrGsaLZ+NPCF5cabq2m6RBGPE1qk l1JcyxpO6pyRHAsoZmGcmORTtK5PXg1ipvlwt76betl+LN6NCs3L2Lfnb9Tf/wCFGeBP+gz8TP8A w4XiX/5No/4UZ4E/6DPxM/8ADheJf/k2s7WP2kNEm+Lx+CPgOLQdW8SWUka6oNV8Rw6ZFBuQyGKB NstxdXAQByscPlqDh5UYFaNY/aQ0Sb4vH4I+A4tB1bxJZSRrqg1XxHDpkUG5DIYoE2y3F1cBAHKx w+WoOHlRgVrqjHMZWs5arm+L7Pd66LVWb3urGzoYtXvJ6K+/TvuerfaE/wCec/8A35f/AAo+0J/z zn/78v8A4VdoryuY4PYruZ80qyQyRiKYllIwYWx091P8jUWpWul6zp11o+saYt9YX0D211a3NmZY Z4nUq6OjKQyspIIIIIJBrRuRutpVxnKMMYznj0wf5H6GlnE7QSLbSRxzFCI3kQuqtjglQQSM9sjP qKFNp3RSo7anmH/DO37On/RAPAH/AISFp/8AGaP+Gdv2dP8AogHgD/wkLT/4zWN8OfjLr8Pg/wAQ +KPjBr2iN9g8VXvhfTo9A8O3omuJbe5ktxstlnuZp5JCm8RxjKKGzuALCj8F/j7DefCi38W/ErxH d6tqN/r2r2lp/Znhq7NzcQW95NGrJp0EclxGiRrGG3qzJlRIxY5PrSjj1GUlNtJpaOWravp6Lc7p YfFxT96TtLl0vv717enKzp/+Gdv2dP8AogHgD/wkLT/4zR/wzt+zp/0QDwB/4SFp/wDGaguf2rP2 freea2i+JNnfy2umw6xcJptrc3xt7OUblnlEEb+XGFwzlseWGQvtDqTg+KP2mPAt5feJfBVv4z1H wRqOkatYaRbazfeHbmWK6uZnibyYUkiCSF0fC4Ykxs0ygxrvKhDM5SUffX/gXdL1erW12SqGMe7k vv201/E6X/hnb9nT/ogHgD/wkLT/AOM1zGl/sZfsqaR4muPFtp8ENHkvrl5HeK6guLmyBc5bZZys 1ugH8IWMBei4Fc9rH7RI/wCFp+JW1Lxt4q8LeHfAmt2WmTWSeAL++tdWSaGPes8otDLDM09wiQlJ FDKqsElWQGvQPiJ8c/h54c8Wab4P1L4rx+D9Ts9TilvYr/R5fK1C2FtJPJCk8qCNUCBXeZGIiIVW KtIAdF/acOXlnL31fTn2snrZa6NN2va6vqauhjYe4py1V3bm9bP715K6u9xb79mr9m7ULOaxn+Af gdI50MbtB4Wt4ZADx8siRBlPupBHY1P/AMM7fs6f9EA8Af8AhIWn/wAZqz4U/aN+C/jWEXfh3xvF LZtpM2uJe3Fnc2to9pCVE8izzRpG3lF1Eihi0ZOHCmtHwJ8aPAPxI1m+0DwpPrj32m28d1dR3/hv UtPWKOTmMl7mCNcuPmUA5ZQSAQCa55zzGKfNzrl3+LTpr21VvkYShi4puUpJL1/rsYv/AAzt+zp/ 0QDwB/4SFp/8Zo/4Z2/Z0/6IB4A/8JC0/wDjNdFrnxc+H/hzxVa+C9Y117fVLyWG2UixuHtoppsi GKa6VDDDJIRhEkdWclQoO4Z84+B3x4t9Wn1HwR8SfGkF74tj8Wazo8E0OkS2lk4tribZAsgDQpKI I/MELzNN5eHO4HeXCWPnTlUUpWSvvLVdWvJdSvZYr2bqc0rad9mm7+nuvU6X/hnb9nT/AKIB4A/8 JC0/+M0f8M7fs6f9EA8Af+Ehaf8AxmtnSvjX8O9Y03VNZt9S1O2sdIgiuZ7jUNCv7JJo5WZYmtzP Cn2kOylU8nfuJUDJdc41x+078ELM2tvfeMpbPUL2+fTYNIutJvYdVe4WITeX9geEXIYoyFcx/OZI 1Xc0iBkpZi24rnuv8RKp4ttpOWnr2v8Alr6ah/wzt+zp/wBEA8Af+Ehaf/GaP+Gdv2dP+iAeAP8A wkLT/wCM1b0/9oL4Z6npXiHWLWfxMIPCksMGrxy+EdXiuLaSUAonkPbCV22sjEIrFVdWbCsCXRft A/CyfW5vDttrGqz30X2tUWLw/qLx3UlqCbiG2lEBjuJo8MGiiZ5AVYbcqQBzzFXvz6a/a7J/k0/R ph7PF95fiUv+Gdv2dP8AogHgD/wkLT/4zR/wzt+zp/0QDwB/4SFp/wDGawfAv7Rvgb4o6v4TvtI8 eyeHvtek3+sXfhvUdJkilu7RAgS5aeVE8qJMlg6kpIS4Vm8psbt3+1B8CdN0e513W/H0OjWtpdW1 pKNWsbqwmLXOfIdYZ4kkeJwrssqqYyscjbtqORc45lGXI+e/b3tNXFfe1pa/be6KdDGJ8t5X+Yv/ AAzt+zp/0QDwB/4SFp/8Zo/4Z2/Z0/6IB4A/8JC0/wDjNaUXx3+GlxpM+sWuo6xcLbal/ZElnB4d 1GTUBc+UJtgslgNwR5REgYRlSh3ZxzXZ6JrNh4h0ex17Snlez1G3S6t2mgkgco6hl3RyKrocEZVg GB4IBrCdfGwV5uSXm36/kZS+sR+KUl82ea3X7Nv7OF5azWk3wC8Cqk8bRsYvCttE4BGDtdYgynng qQR1BBrpfBPw5+G3w2huIPh98P8ARvDa3axpcnStHS1a4EYYJ5rIgMhXe+CxJ+ZvU12VFYzxlecX Cc212uzOUqklyym2vUpfaE/55z/9+X/wo+0J/wA85/8Avy/+FXaKw5jL2K7lL7Qn/POf/vy/+FH2 hP8AnnP/AN+X/wAKu0UcwexXcpfaE/55z/8Afl/8KPtCf885/wDvy/8AhV2ijmD2K7lL7Qn/ADzn /wC/L/4UfaE/55z/APfl/wDCrtFHMHsV3KX2hP8AnnP/AN+X/wAKPtCf885/+/L/AOFXaKOYPYru UvtCf885/wDvy/8AhR9oT/nnP/35f/CrtFHMHsV3KX2hP+ec/wD35f8Awo+0J/zzn/78v/hV2ijm D2K7lL7Qn/POf/vy/wDhR9oT/nnP/wB+X/wq7RRzB7Fdyl9oT/nnP/35f/Cj7Qn/ADzn/wC/L/4V doo5g9iu5S+0J/zzn/78v/hR9oT/AJ5z/wDfl/8ACrtFHMHsV3KX2hP+ec//AH5f/Cj7Qn/POf8A 78v/AIVdoo5g9iu5S+0J/wA85/8Avy/+FH2hP+ec/wD35f8Awq7RRzB7Fdyl9oT/AJ5z/wDfl/8A Cj7Qn/POf/vy/wDhV2ijmD2K7lL7Qn/POf8A78v/AIUfaE/55z/9+X/wq7RRzB7Fdyl9oT/nnP8A 9+X/AMKPtCf885/+/L/4Vdoo5g9iu5S+0J/zzn/78v8A4UfaE/55z/8Afl/8Ku0UcwexXcpfaE/5 5z/9+X/wo+0J/wA85/8Avy/+FXaKOYPYruUvtCf885/+/L/4UfaE/wCec/8A35f/AAq7RRzB7Fdy l9oT/nnP/wB+X/wo+0J/zzn/AO/L/wCFXaKOYPYruUvtCf8APOf/AL8v/hR9oT/nnP8A9+X/AMKu 0UcwexXcpfaE/wCec/8A35f/AAo+0J/zzn/78v8A4Vdoo5g9iu5S+0J/zzn/AO/L/wCFH2hP+ec/ /fl/8Ku0UcwexXcpfaE/55z/APfl/wDCj7Qn/POf/vy/+FXaKOYPYruZ80qyQyRiKYllIwYWx091 P8jRVy5G62lXGcowxjOePTB/kfoaKicjpoUmk7MLYbbaJcYwijGMY49MD+Q+gr4r0vXPBN34p0/W NX/bJ0i0hufGGpeIdQRPE/hV0hWJXtrBx+4LF5IBBkZZVAbhXww+yYJ7xIY1S0h2hQBmUqcY9Ngx 9MCpPtN9/wA+sH/f9v8A4iu/BYn6vzPlu3p0/VPrZ+qQ6WNpwUotXv5eTXVPufni6eD73V5PAOo/ GD4bNYQ/GH/hZFn4yTxtpIijs2BkeEx/aftP2rd+7A8sx8534UZHTwfe6vJ4B1H4wfDZrCH4w/8A CyLPxknjbSRFHZsDI8Jj+0/aftW792B5Zj5zvwoz+h32m+/59YP+/wC3/wARR9pvv+fWD/v+3/xF etHPZRtantbqt1y67b+6tPh301O6Wdwle8d7/e+a72680vLXYt0VU+033/PrB/3/AG/+Io+033/P rB/3/b/4ivneVnke2h/SZPcjdbSrjOUYYxnPHpg/yP0NV9a1H+x9Hv8AVvs8s/2K2kufKhhlmeTY pbascSPI5OMBUR2J4VWOAWTz3jwyK9pDtZSDiUscY9Nhz9MGpPtN9/z6wf8Af9v/AIihRd9SlXhp f9T4v0PVPG+mQ6d4hPhe/i17QPHepeLrOw/4RHxbPZXsGo/aVngknOiI8EkaXJ2SLHIGKnKqGIrJ h0CS5Oka34q+F1t4outI1zX7ptA1r4f+J7vTru01S5F0HE8mhsYLmGRUUEQyB038pvwPub7Tff8A PrB/3/b/AOIo+033/PrB/wB/2/8AiK9tZsk+aNOz/wAWyta23Zvz1dmtLej/AGvTbb5Xq29+/N5f 35ff5K3xh4kn1q6PjS18M/D5tM0/xH8OU8F2FpZ+BvFdjb2UpluXZhCmiuqxIt5IBtOXMKnbH5pE dTXrnxveaP4r02x8KahNJ4sv/D2sSSXHhfxdH9mn05LESwjGht5iObI7ZPlP7zlBt5+2vtN9/wA+ sH/f9v8A4ij7Tff8+sH/AH/b/wCIohmqi01T10+12akundJ/8ASzWkmnyu6/yiu39xHyWvxN8I6P qfxY1H45aTqmh+DfiLdQRxXKeGvE4liYWsNlGjGbSIUSRhEJFZZCVchQGxvqrqHiPxS3hH4bzWuj +K/EHinQPEC+JvEN1rvgjxNp7XkwtJrZYwbfSblchJkUnkAQDl9xYfX32m+/59YP+/7f/EUfab7/ AJ9YP+/7f/EVl9fpK1qb6L4la0VypfDfbfXWyvsT/aVH+V22tfvHl/lvt5+Z8Ite634Z+H/hHTvF XhOaXSPA/wAP9c8P6y9x4Y8WLBc/aY02sd2jxKIQLWIuWljx5j4I8sM/Zfsv/tC+Drq91y8kn8S+ Mmntra2n8RaRpusa+0S267YbOZYNCsljwsksitskZi0m9/uZ+vPtN9/z6wf9/wBv/iKPtN9/z6wf 9/2/+IrarmlKrTnCpSd5f3u8nJ/Z7t/gVVzShVp8koO/r3d39nq/07I+SvFVxHrHirxhpdppfimf wX4+1rS9e1Ke7+H/AIpXUdPmtPs4kighGmNHMsi2cG12ljMRdztfaAy6HqU1vr39k6toniH/AIRa x8baj44tryPwB4plvruW4eeSK2ktzpapAqNcktIs0pYRBdi+YSn1p9pvv+fWD/v+3/xFH2m+/wCf WD/v+3/xFYrMIqChyOyVviXRRSfw7pRS7aXtfUl5nTcXCzs/zs43+HdptP799T4ll0BdZ8DeJvCL +H/EfhfTb9LO603wxF4M8W+INBW+t7sXe/ybnSYTa20jDyntog0exsgArhteHUUsdY8Dap4V+Bum eDrXQfE39tapp+g+A/FECyILSa13LImhIJpCLp2CtHGF8kLvbzC0f2H9pvv+fWD/AL/t/wDEUfab 7/n1g/7/ALf/ABFa/wBq7pwdm725urSTvpd7Ldu1tLIbzSm0007O/V/aXK+nbrvfW+rv89ap4j8H 3fxig+IVlF8RYNGvrCJNe0s/DXxIRfXdrJvsZh/oOBs8yUseCTHCOQDXBjxV8RL/AOLuheOfEune JtUtNC8QXtxDOfD3i+JE0yZJ4YoYtMTRBAs0ccwYyPLJK7BlMoQqqfYP2m+/59YP+/7f/EUfab7/ AJ9YP+/7f/EVhTxtOMeV021Zx1ktnvqop7aellskQsxo2acXqrfK1v5ez/J7o+FYPD+uat4X8H/D rxHouuWmi+HvCGteD7nU7Hwf4slupY72OFI7lLdtGRQymBS0Rlx85+c4+bU8WXPjHxpotzrOseFb yLxY1joWjRxW/g7xcLOS30++F/LO0x0XeHlkVUWERkRjLeY5O0fa32m+/wCfWD/v+3/xFH2m+/59 YP8Av+3/AMRXT/a/vKfJqnf4lvzOT6dW3fy0NpZvTdrxen+ak+nVpP5Lzv8AG+varqmveIfG+p6x 8Kr/AFez8QeJLLW9KT+yPGunXdgbezS2WeK6g0PzLe4zBG2Y85WR0LYGX+ofg5Lqcvwx8O/2zrGr 6rfRWnkz3mradcWV3KyMUJliuIoZcjbje8aGQASbQHrp/tN9/wA+sH/f9v8A4ij7Tff8+sH/AH/b /wCIrixOLVWkqUYWSt1vtHlXTsld9ba3srcuIx1OrFJJq3q/0/rqW6Kqfab7/n1g/wC/7f8AxFH2 m+/59YP+/wC3/wARXn8rOX20P6TLdFVPtN9/z6wf9/2/+Io+033/AD6wf9/2/wDiKOVh7aH9Jlui qn2m+/59YP8Av+3/AMRR9pvv+fWD/v8At/8AEUcrD20P6TLdFVPtN9/z6wf9/wBv/iKPtN9/z6wf 9/2/+Io5WHtof0mW6Kqfab7/AJ9YP+/7f/EUfab7/n1g/wC/7f8AxFHKw9tD+ky3RVT7Tff8+sH/ AH/b/wCIo+033/PrB/3/AG/+Io5WHtof0mW6Kqfab7/n1g/7/t/8RR9pvv8An1g/7/t/8RRysPbQ /pMt0VU+033/AD6wf9/2/wDiKPtN9/z6wf8Af9v/AIijlYe2h/SZboqp9pvv+fWD/v8At/8AEUfa b7/n1g/7/t/8RRysPbQ/pMt0VU+033/PrB/3/b/4ij7Tff8APrB/3/b/AOIo5WHtof0mW6Kqfab7 /n1g/wC/7f8AxFH2m+/59YP+/wC3/wARRysPbQ/pMt0VU+033/PrB/3/AG/+Io+033/PrB/3/b/4 ijlYe2h/SZboqp9pvv8An1g/7/t/8RR9pvv+fWD/AL/t/wDEUcrD20P6TLdFVPtN9/z6wf8Af9v/ AIij7Tff8+sH/f8Ab/4ijlYe2h/SZboqp9pvv+fWD/v+3/xFH2m+/wCfWD/v+3/xFHKw9tD+ky3R VT7Tff8APrB/3/b/AOIo+033/PrB/wB/2/8AiKOVh7aH9Jluiqn2m+/59YP+/wC3/wARR9pvv+fW D/v+3/xFHKw9tD+ky3RVT7Tff8+sH/f9v/iKPtN9/wA+sH/f9v8A4ijlYe2h/SZboqp9pvv+fWD/ AL/t/wDEUfab7/n1g/7/ALf/ABFHKw9tD+ky3RVT7Tff8+sH/f8Ab/4ij7Tff8+sH/f9v/iKOVh7 aH9Jluiqn2m+/wCfWD/v+3/xFH2m+/59YP8Av+3/AMRRysPbQ/pMt0VU+033/PrB/wB/2/8AiKPt N9/z6wf9/wBv/iKOVh7aH9Jluiqn2m+/59YP+/7f/EUfab7/AJ9YP+/7f/EUcrD20P6TLdFVPtN9 /wA+sH/f9v8A4ij7Tff8+sH/AH/b/wCIo5WHtof0mT3I3W0q4zlGGMZzx6YP8j9DRVSee8eGRXtI drKQcSljjHpsOfpg0VEoM6KFeFnv9z/yH24xbxDGMIBjGMcemB/IfQV85618dfipN4l1nR9H+Gni 63STxbpnh3Tn3aG0cQQRXN6Dm8LNJJbmbacMqgJyjhwPoy3GLeIYxhAMYxjj0wP5D6Cvk7Svgx4c stb03XdQ/Y71e/uLPV9T1e4Z9H8Jh7prqWR4Y2b+1D8kCybVBzkojfKRXsZWqPNKVezStZO2979Z R7Wfr2DCqlabna/S/o9dWuqXfct+If2m9S1f4pxaY2r674Q+HFv4tXwVa+ItK06xuxqmsKrGSG4l uGdre33/ALsFLZixXf58a5Ubfizwv+07pvxG0O5h/aZSLTPEniXZD4XtPB9gwttPVnmlT7bIC52W 8ZXeyZLso7iuCg+CfiiHxBc27fCP4kyeB7nxuvxAOguvh43S6iF+4L3+2sfZjJhzH5O7gDzOST7P J4o8cXPjuHxpefs9/ESUWOltp1hbfafDwMDSyB7iQv8A2vht4itlA2gr5bcnfhfTm6NL2bw/I7LW /I+i35r6uV7taJfC1sdmI9lFtYfltyta8r6tLfW9mnJ7XWnRHstFFFfNHhkdwN1vKMZyhGMZzx6Y P8j9DTb20i1CznsJ3mWO5iaJ2gneGQBgQSsiEMjc8MpBB5BBp1wN1vKMZyhGMZzx6YP8j9DVTX49 Wl0LUotAdU1N7SVbJmmEKiYodhMhilCDdj5jFIB12P8AdIld2LjfSztqfHfwyv8AXtQ8aeEPCGhe IfiJpPiiHxFqOovq3ibxheXuk69o1nfz21xa29vJczpLOImjG14oHTZ5u/5Rv9j8SftBeKPD6+ME ufh1psw8IeK9M8PXhi8RSKZba/Fv5VzGfsoPmL9rh3Q8AYfEhwN3D23wC+NMXgWDwTcWGm3Umna2 3iHSNbk+IpTU9Ku3leWRreWPw6qbXaWYMsiOCsrLwuAI/En7P3xx8USatLfCzhbX5dOvNU+z/EJE F3e2Pk+Rdsp8NkCTFvEGRQsLbc+XnBH09RYatVTrOLin/N/ei773tycyt0lqtHp7dRUKtZzm1bpr /ev37P5NWtZK9b4d/FZfgt4VvfA3hfwpqvifVr3xr4pe0gk/tO7K21tqLI8k81ta3lwzlpolDNGQ xYl3U43ejxftG6ld+I/Bvhw+BrXw/deKtPtb9rPxbqs2jX2ZJvKmgtIntXjubiEYZojLE5DpgYbI 4PT/AIA/G3Smt9R02206316z1nUNZtNcj+IKi6ha/O67h2f8I55EkEj4fbJE5VlUqV2jG94h+GPx +8UraWGu6Zol7osK25vNHufiAZ7bUJYZTKssryeHmmjcvg5gliA2KEChRUVKeFqSjKdm38T5/XZX 9PNtNaLUjEQw9SpKateTk783VybWl+3mut2uvU/tYax4v0f4P3MnhG1spXvNV0ywvTcajJaHyJr6 CJ0UpDJuEm/ynB24SR2G4qEbmtF+I+i/Bm01PRPCXwp02w8J+G9atLLxYNK1qV00nUb/AMl2WxtX gVZbZGuYCxBtwA7lYiQwOj8VfCPx/wDiv4XTwpfeFvCmh2ovbe+eXSfHsnmytBKs0SsbjQJVCiSO N+ACSgBO0spwr34O/Ga/8UT+Jbjwr4cMeqSWF1rmlr8QpVstaurPb5FzcKNA3rJmOLcIXijfykDI VyDhhYUo4f2VZr4m3aS1XuWv71tlO3aTXRyM6Uaf1dU6jW7fxei72va9unfc9J+DfxT8WfFe3v8A Wr74dR+GtHs7+90tTdaylxfPcW1y8DAwxRmIJhDlvOJDhlCsoWVuV1D9pHxLp/ibxRp1z8I5bTRf B/iXTfD+o6jea7AssiXzW6RTwwRpIGwbpHKPJHiMqd2/dEjfhd4R/aA+FmiXuhWfhbwprkV9qdzq zS6t49k8xJbiRpZQv2fQIl2mR3fBBILEAhQAOQ8TfAr46eJ5fFslxDplovjLWbHW76O28ex7YpbP y/ISLf4bYhB5FvkMWJ8hcn5n3lPD4b6zLnUfZ6W97+9G/wBq/wAPNvpewo0MO61Tm5eS/u+9sr+v 8vfqd7L+0Jqtxq1udE8EWV34e1bXLzwpo+rS6w8bS6rbiUbLiBbZzDbPLbzRiZWlbIUmIBsjhvhp 8XfGnxAvfhlqviv4U6XP4q1nwxquueH9ZHiJ4rH/AJd1eB40gLozCSMMWikCAIUaVmcJo6J8IvjF oXitvEdv4M8MTWK6vN4hg0Gb4hznTrbUpozHLdIF0ETbm3zPsMpiDzMyopClcbQfgJ8ePDM/hubR JLG2Twhp17pWiRf8J5A62dvchAyDd4ZJfaYoipcscxjcWBYNcaOFUHGPLdrfm/uzXSW/M43t7rV9 O+qp4ZXUbLt72v2tNH25VLo3e2ljhfgt4r8J+C5PBHxf+Jvwft4fE+q+CdS1yXxvYa0ZptTii8ky LNb7Y9907XGCZAVQeUElcFli+n7Xxl8ZhYaw2o/BewF/bpbPpKWfiqKa2vDK5V1mlkgjeAwgB3xF KCp/dmRhtrw7Tf2aPivbab4e0DV9F0jXNE8OaNfeHrfTL/4gKsM1jdoiTRSvD4cjlPEceHV1dSgI bk52tW+Dn7QXiXwLe+APF72HiCwuhaLFLqPxAR5LdbeVJVUqvhtYrgOY0D/aUm3rkH7zZ3xqw9eo pJx36yulHnbXKuZbRautFvy2ZeJjRrVFO61et3fS+lve7br/AMB8p5P2l/H/AIosvDFx4C8L+Drp 73x0/hLUJLbxWbuynKWr3Sm1uksyHjdFOXKKyMuzYdxdLngL4zO9pPoXw7+EUVn4v17X9fvbnQdU 8RGJAbK5EV1PJcpHOqyPI8QWKMNGCxw+1dxwYPgT8eYxLc3LWF3qTeIofFMOoy+PYVltr2O3a1LI ieGlhKvC2xlaNh8oK7TkmOy+AHxu0ww3+mQafaa5a6xqOsW+txfEBBdxG/O67g2nw35LQyPtkw8b MrKpVlAxUOjg+Vwjyr/t7rZb66xUvK9lor7qdPCtcseVK/8ANp9vfXXeKvo9H0322/a91fVLXVdW 8J/Bu+udJ0jwbD42mvNU1qCyL2pMwmjWNEmfzUa3kRQwUO0cmSi+W8ncaV8cpda+L3/Cs7LSdCgh WOKfN/rj2uq3EElsZluLWya22XMAYeUzx3BKsr5UbcHyzUP2evi7cw6vY6ZoWi6Pp+seEofBUllZ /EHfHDp8ZY4R5vDskhkbzZ9zu7E+e54IQr0fh/4UfG0+JvDFz41h0vWNE8P3ttdQWl14yiuBaSRR CH7TEE8PwSmUJvfyxPHGzMynarYEVKGBabiorR297Xye7Ta7aJvysZVqOF5W6dlo/ta35Y2e9r83 N5dbPZ/RFFFFfPHjhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAEdwN1vKM ZyhGMZzx6YP8j9DRRcDdbyjGcoRjGc8emD/I/Q0VnUOzC7MILRjDGRczINo+UKoC8dOUH8hT/sb/ APP7P+Sf/E1LbDbbRLjGEUYxjHHpgfyH0FfEOseP/G3iLxxqtjJ4lMsHiDx3Y2WY/hJ4hYvb6Xsu PklE5Uok9vLHJEAzfNLIdiMQvbgMHLFTcU7Wt0b6pdF0Tv8AI6KODVVSlso+Tfd/kn6n2z9jf/n9 n/JP/iaPsb/8/s/5J/8AE18I6/8AFHWfFfj4/GPxfoug+MvCNl8VU+HFp4V1O2mlbRVQFFvrced9 ma5Z28wmSB5AGCJKi9OZun/s/wCMWr+MdXsp9U8L6r8X4E0v4q6dbq2r2FwCkcmksHcS/YhzbBxm IBH2pIHRR6dHIpzspTs2r7dfd93dXaUk/PaKkdksoUVLmesV26rmut+ji/NrVJpNn6KfY3/5/Z/y T/4mj7G//P7P+Sf/ABNWaK+fuzyeSPYpz2jeTITczONp+UqpDcdOEP8AI0y9a102zn1HUdY+y2lr E08887xpHFGoJZmYjCqACSTwAKt3I3W0q4zlGGMZzx6YP8j9DUlF2UoQ0ujgfD3xk+DPi7WLfw94 U+NfhDWtVu932ex07X7G5uJtqlm2RoxZsKrMcDgAntXaNbbFLvfzKqjJJ2AAf9818Z+FpL2abwFY fErUdKi+F7+O9U1DQ9T0y2EE9jrdvq12ba2vZ5JJF8iUecFeJYWLbYmOGO/svHfxL+JHhuX4kw2n xUvo5PCvj7w/Zaak1npxaS0vxZGWzYfZxuQC6mKsP3oES5dsNn2qmV81RU6Et++v24w3S3vJXVtF rdpo76uXR9q6dN7d/wDE129L9nfsz3rwL418H/EzQ28S+BPFY1nSluprIXluo8p5IXKPsYoN6hlO HXKsOVJBBrofsb/8/s/5J/8AE18faH4u+JlnqKfC74Yanp2i3Xifxz4zuhe3F/HZPI9rqGVt4Xls b2MsVlkkKGHcVhJDrg7u61Xxp8ZvD9x4U1vxt4slk0Ozs7KHxDqHgX+z7+yjvvtflTG9t7mD7V9m kXCiS1YNGUl3IAAwiplcuaLhJJS2TevXsu6aXd2sia+XKFSUYtWTlbXWyk0vm7dPM951zUdL8NaT da7ruttZ2FmnmTTSBcKOgAAXJJJACgEkkAAkgVneCfGHhr4iaRLrnhTWr64toLqWxuEubGSzuLee JtskUsE8SSxuD/Cyg4IPQg151+2Bpd9qfwbb7F4k1HSfJ8Q6IX+xx27edu1O1QBvOikxtZhINu35 kUNuXcjcp4n+JnxM0rWvFTaP44uXn+HOu6FoA0S+tLIjxHDei2Vrm4ZIVkSaRrmQR+QYow0GCjAs oyw2B9vQ54y95ya8lbkXZ7uaW+m+17TTwUZ0VOO93+mm27b3vZddz6P+xv8A8/s/5J/8TR9jf/n9 n/JP/ia8l/Zz1L4keKtI1bxV8QviHJrM0Gu6tosVha6XbWViiW1/LEkgUK82/EZUZmK7NoIZwZWy /FHiH4j2PxffTNZ8W+KtG8K6veJpWi3ugwaTe6fHNJaOPKvFltnu7e6Ew8xHJkt2zErAZKnF4SSq ypc6vFX66+S0u32VjN4NKpOnde5e+/Te2l+n3a7HqvjLxP4Z+HvhfUfGnjTxOukaLpMJuLy8uCoS NegAAUlmJIVVUFmYhVBJArTsvJ1Czg1Cz1GeSC5iWaJ9qjcrAEHBXI4I618ZeJPir8QPFHwb0GTX PiBJqSeM/gx4l1HWtONrZIj3NvbxhLgGOJZELGaRSoYJ+7GFBBz6BZ698bdItNV8DeGfHEfiPUR4 T0bWrQNHYafcafNNO8clpau8LxDzYon+zi5EpDIfMkcHcO2eUzhC0prmu1u7WUnF9NLOLd29rddD oqZYoU4ttXu79rJwXbo5a38rH0n9jf8A5/Z/yT/4mj7I3/P7P+Sf/E189+HfiN4o8Z6r4c+FVr8R vF3hzUbyDWZrrVtW0nS4taa7sriFBZGMQvZNsjuBIzxRt5kaIysPnNWdFuvjhrfxZ1vwHJ8cbA22 geFNK1K3uNP8M2yx3d68l3DK1wrySM0TvbszxxPE33FR4yrtJyywE4RcpzSsm/tapNq6strrTuYv Apc3M0uXff8AmUV06t/LW9noejeBvi58M/iVqlxovgfx0urX1pYxajcwRQsrwQys6xmQNGNjMUY7 Gw20q2NrKT0Gma9omsa5rPhzTtbnm1Hw+8Meow+Tt8hpYxJGNxQK2UIPyk46HB4r468NeNPiV4hi n+LMvxQXQ9cs/gpp2v3+oHTLRkvbiO61F1SVXQokDEMHWNVkOV2SJgh+nl+J/wC0TqXxBi8OyfEb TdGt7vx5YaJNbQ+G4mltLW60T7d5KNJI3zRsHBdw5aTa3yxgwN31cnaqShCSVlrdvRqSj/Lqvu7u 2z6a2VxjOai0klfW+loxlLZa/FpbuvM+s/sb/wDP7P8Akn/xNH2N/wDn9n/JP/ia+WL34q/Fm40C x0YeN/EqNZax4o0m61nQPDdvqmsXUthdGGyMlnHayoIGVsTSRwIBJ5Q3RB/m+jPhta+LLPwDoEHj vU7nUPEf9nxPqs9yLcP9pZQ0i/uI44sKxKjao4UZJOSfOxGDnRpqpKS1em+u+u3l6q6utTkr4P2N ua17tf8AgLs/xNv7G/8Az+z/AJJ/8TR9jf8A5/Z/yT/4mrNFcV2c3JHsVvsb/wDP7P8Akn/xNH2N /wDn9n/JP/ias0UXYckexW+xv/z+z/kn/wATR9jf/n9n/JP/AImrNFF2HJHsVvsb/wDP7P8Akn/x NH2N/wDn9n/JP/ias0UXYckexW+xv/z+z/kn/wATR9jf/n9n/JP/AImrNFF2HJHsVvsb/wDP7P8A kn/xNH2N/wDn9n/JP/ias0UXYckexW+xv/z+z/kn/wATR9jf/n9n/JP/AImrNFF2HJHsVvsb/wDP 7P8Akn/xNH2N/wDn9n/JP/ias0UXYckexW+xv/z+z/kn/wATR9jf/n9n/JP/AImrNFF2HJHsVvsb /wDP7P8Akn/xNH2N/wDn9n/JP/ias0UXYckexW+xv/z+z/kn/wATR9jf/n9n/JP/AImrNFF2HJHs Vvsb/wDP7P8Akn/xNH2N/wDn9n/JP/ias0UXYckexW+xv/z+z/kn/wATR9jf/n9n/JP/AImrNFF2 HJHsVvsb/wDP7P8Akn/xNH2N/wDn9n/JP/ias0UXYckexW+xv/z+z/kn/wATR9jf/n9n/JP/AImr NFF2HJHsVvsb/wDP7P8Akn/xNH2N/wDn9n/JP/ias0UXYckexW+xv/z+z/kn/wATR9jf/n9n/JP/ AImrNFF2HJHsVvsb/wDP7P8Akn/xNH2N/wDn9n/JP/ias0UXYckexW+xv/z+z/kn/wATR9jf/n9n /JP/AImrNFF2HJHsVvsb/wDP7P8Akn/xNH2N/wDn9n/JP/ias0UXYckexW+xv/z+z/kn/wATR9jf /n9n/JP/AImrNFF2HJHsVvsb/wDP7P8Akn/xNH2N/wDn9n/JP/ias0UXYckexW+xv/z+z/kn/wAT R9jf/n9n/JP/AImrNFF2HJHsVvsb/wDP7P8Akn/xNH2N/wDn9n/JP/ias0UXYckexW+xv/z+z/kn /wATR9jf/n9n/JP/AImrNFF2HJHsU57RvJkJuZnG0/KVUhuOnCH+RoqxcjdbSrjOUYYxnPHpg/yP 0NFRKTOmhTjZhbDbbRLjGEUYxjHHpgfyH0FeN6d8Ivi7pNzZXen+PfhxFLp11e3ts3/CEam2ya8k aW5fB1sgl3dzznG4hcA4rtUtrcqCYI84/uD/AArC1Hxl4M0qe+t7+9ijk02eztroC2dhHLdyLHbp kKQWdnQYGSNylsAgn1sPRqw0pPe3RPy6372+ZtCNSLah18r+X62+ZxSfs0+MovG8nxCj8TfDZdZl vxqz48G6t9ka9EZjF2bP+3Ps5uQpIE3l+ZyTuyc1Xi/Zb8WQ+KT4vj8U/D0Xjav/AMJAbU+FdaOn f2ht2/a/sB177L5/8Qk8rcG+cHd81bUnx2+CkXxOT4NyeNNMHjCTgaaInPzbS3lmXb5QkwM7C27p xyKhsv2gvgZqPxNm+Dll450ybxdBI0D6esMm3zVXc0Ym2eU0ijIKBywKsCMqQPRj/aeji38P8q+H 7vh/A6m8bZ3vtr7vTz021fke80Vxv2a3/wCfeP8A74FH2a3/AOfeP/vgV4/1PzPP9j5nXXI3W0q4 zlGGMZzx6YP8j9DVTxBo8XiHQdS0CedoItStJbN5UhhlZBIhQsEmR4mIznbIjoejKwyDzb21uFJE Eecf3B/hTZ4oYoZJY7ETMilljRVDOQPujcQMnpyQPUihYRp3v+BUaTTTTPP7L9kvw7pvhy/8H6d8 QdYtdA1SRZb7SofCvhNLO6dSpVpYRo+xyCqkFgSNo9BUF7+x74Q1EIuoeNdRuhFZR6agm8I+En22 sZBSAZ0fiJSqkJ90YGBxWv8ADL4h2XxNstUv7fwPrWgppWozaVKurCzLSTwu0cyp9nnmGEdCpJwD wV3Dmuz+zW//AD7x/wDfAr0pzxlObUpq++0e2/3HU6mIhJxcrNPst+vzuvwPOP8AhkPwr/YU/hb/ AITrVP7FubsahPp3/CJ+EvsstwBtEzRf2PtMmON5GccZq3P+y1pl1rWl+I7r4na/Nq2iRR2+mX8n hnwo1zYxx58tIJDpG6NVydoUgDJxiu8+zW//AD7x/wDfAo+zW/8Az7x/98Cs/bYrfnX/AICvTt2I 9rW6tfcuu/Tqcf4s/Zzk8fWEWleOvjH4r8R2UEouIrbVtA8L3kSSAFQ6pJpDANhmGQM4J9agb9mW 2bW9L8St8V/Ep1fRLZbLTNQPhzwr9psYFDBYoJf7I3RoA7gKpAAY8cmu3+zW/wDz7x/98Cj7Nb/8 +8f/AHwKlTxCXKpK3+GPXfoL2lW1rq3ouu/Q4/wn+zk/gOzm07wN8YvFfh20uZjcTQaToHhe0jlk IALssekKC2ABk84AqGL9me3g8WyeP4Pix4lj8USrtk1tfDvhYX7jYEwbj+yPMI2AL97oMdK7b7Nb /wDPvH/3wK43VvHS6V8VfD3w0bwlI8Ov6Xe6kurNNEsSNbtEDCsYy7NiZSSQigFdpclglweKnN8s lzNO/ux1SV307LYpSrzbaa130Wv4amdZfsl+HdN1L+2dO+IOsWuoebPP9rg8K+E0m8yZdkz7xo+d 0ikq5zlhwciltf2TfD9l4Yu/BFl8Q9Zt/Dt/OLm70iLwt4TSyuJRtw8kA0fYzDy05IJ+RfQV6F9m t/8An3j/AO+BVLStS0HW1un0ma3ulsrqSynZF4SaM4dM45Kng46EEdQaXtcU/trS32V0enTo9vMH Wr/E5fgt9X29fxOPv/2V9I1TwvZ+CNT+JevXnhzTpBLZ6RP4Y8KSWVs43YaOA6OUQ/O/IA+83qaS 1/ZV0ex1C41ay+JWu299d2A0q4uYvDHhRJZrQIsYt3caPlodiImwnbtRRjAFd99mt/8An3j/AO+B R9mtv+eEf/fIpe2xNmuda/3Y9d+nUSrVkrJr7l69u55zB+yJ4Xtv7H+zeO9Vi/4R6Uz6Rs8J+El/ s6Qv5ha3xo/7pt4D5TB3c9eaZcfsfeEbzxC3i278balPrjXQvW1OTwj4Sa7M4bcJTMdH3+ZuAO7O c85rvNF1LQvEel2+taJNb3ljdKWgnjX5JACRleORkHB79RV37Nb/APPvH/3wKp1sWnrPXX7K+fTv uN1q6unL8F/keD+Nf2GZNUtdPsPA3xT0rSLS1lnnntNZ+GXhnU7Z5JBEPMSGKztkSTEQBdg7EYAK gHd9A/DDwJD8MvAekeBoNYuNUTSo3QXU9vBAW3OzkLFAiRxxqX2oiKAiKq84ya32a3/594/++BXG +AvHS+Ntc8ZaLceEpNIfwlrQ0jM80UrXQNvDOJsJkIrCYYXcTjBbaxKKVXi8TR9lOacY+9tFdbXu rN6y89x1ZV69O03dR8kt/wAWeyUV5zoE+p6gl+2ueF49Ja3v5re1X7RHP9qt1OI58qPk3jnYeV71 ONS0E623hxZrc6klqL1rYLl1hLFA544BYMB67T6GuH6jK9r/ANbnK6DV9dv+G/M7+iuN+zW//PvH /wB8Cj7Nb/8APvH/AN8Cl9T8xex8zsqK437Nb/8APvH/AN8Cj7Nb/wDPvH/3wKPqfmHsfM7KiuN+ zW//AD7x/wDfAo+zW/8Az7x/98Cj6n5h7HzOyorjfs1v/wA+8f8A3wKPs1v/AM+8f/fAo+p+Yex8 zsqK437Nb/8APvH/AN8Cj7Nb/wDPvH/3wKPqfmHsfM7KiuN+zW//AD7x/wDfAo+zW/8Az7x/98Cj 6n5h7HzOyorjfs1v/wA+8f8A3wKPs1v/AM+8f/fAo+p+Yex8zsqK437Nb/8APvH/AN8Cj7Nb/wDP vH/3wKPqfmHsfM7KiuN+zW//AD7x/wDfAo+zW/8Az7x/98Cj6n5h7HzOyorjfs1v/wA+8f8A3wKP s1v/AM+8f/fAo+p+Yex8zsqK437Nb/8APvH/AN8Cj7Nb/wDPvH/3wKPqfmHsfM7KiuN+zW//AD7x /wDfAo+zW/8Az7x/98Cj6n5h7HzOyorjfs1v/wA+8f8A3wKPs1v/AM+8f/fAo+p+Yex8zsqK437N b/8APvH/AN8Cj7Nb/wDPvH/3wKPqfmHsfM7KiuN+zW//AD7x/wDfAo+zW/8Az7x/98Cj6n5h7HzO yorjfs1v/wA+8f8A3wKPs1v/AM+8f/fAo+p+Yex8zsqK437Nb/8APvH/AN8Cj7Nb/wDPvH/3wKPq fmHsfM7KiuN+zW//AD7x/wDfAo+zW/8Az7x/98Cj6n5h7HzOyorjfs1v/wA+8f8A3wKPs1v/AM+8 f/fAo+p+Yex8zsqK437Nb/8APvH/AN8Cj7Nb/wDPvH/3wKPqfmHsfM7KiuN+zW//AD7x/wDfAo+z W/8Az7x/98Cj6n5h7HzOyorjfs1v/wA+8f8A3wKPs1v/AM+8f/fAo+p+Yex8zsqK437Nb/8APvH/ AN8Cj7Nb/wDPvH/3wKPqfmHsfM7KiuN+zW//AD7x/wDfAo+zW/8Az7x/98Cj6n5h7HzOuuRutpVx nKMMYznj0wf5H6GiuQe2twpIgjzj+4P8KKxqYZRer/D/AIJvSptIkThFHTgV8Y2ngTxl4i8awXEH h3zLfxB45vLoeZ8VNfG+HTAYWDx+QVwJrZHST5mGUQBUwy/YianYqoUz9Bj7p/wrz/8A4VD8O/8A oYviD/4cHxD/APJle5l+YUcO3Jy1aXX5/wAy6pfkdtCbhGUWnr69mu673+R4t461vwx8Rviv8OvF XwT8fabr954P8VyWmoeBpdPSM2glcw3t95QSO4iMe+RzLLvjLlCpDfLJY8S/F39mnxv8f/BPhSLx RYy3/gLUpE0jT9N0ySUX2pXAEYRJ0j8pIoj8zfON0gUkgRfP7D/wqH4d/wDQxfEH/wAOD4h/+TKP +FQ/Dv8A6GL4g/8AhwfEP/yZXZDM8BHlTlL3U7WcU9d9eu7tpfXfRHRKrSd9JaRcVts779/ia6de u3plFVP7VsP+e/8A463+FH9q2H/Pf/x1v8K8b29L+ZfeebyS7FmTlGHXg02eZLeGS4kDlYlLsERn YgDPCqCSfYAk9qrvqdiylfP6jH3T/hUGoyaBq+n3Wk6tBb3tjewvb3NtcQeZFPE4KujowIZWBIII wQSDSValfWS+8ahLqmfI1vo1j4r1Lwpba94F8fy2g+Ket6ld28/hrW7e1bTrs3ZjkuI/JWNo3MsC t5gOEkkRsIZRSeCvCGl6dN4Kn0/4feNdMupPHet6fcXMfh7V7Say0OZL1YIkm8pWtbT/AEi1ZVQx ojlpBtdJGX6B/wCFGfs4/wDRFPh9/wCEtZ//ABqq+ofs/wD7Nep2Fzp1z8F/AyRXUTQyNb+HreCU KwIJSWONXRsHhlIYHkEEZr3Hm+EcPZqbStbp2t3PUlioyvfmV79O/O+/ed/+3UfJ2g+DLLxH+z/p 934D8E+MI7xPh7qFl4gu7TSdTil1m5lMK2MCyKoe9USKxBTzIo4VKMUjbYfcvFvgvwnp8fgE3vwt vtU+Gt9YXsmtaXb+Gbm7uP7UlhhMF5eWgia5eUrHcIZXQuryAsQSCO08Ofs1/sw+FtLTR9M+DfhG aCNmcPqOlLqE5JOTma4EkhHoCxA6DFaf/CjP2cf+iKfD7/wlrP8A+NVeJznCVJtxqO15Pp9q/wDe 3V/dfSy3sFXFRnPmXNZOTXfWy3vuraeWmx5PofwW8W6CfB+r3vhG01XV/Gvhf/hDvGl3e2sM91ar s8yK4uJCGEpWKN4JMkiVxAGLYBqprPwf05Pi9fWmvaf480610u50x/Ar+GdCtLi0itIYoh9njvTZ yPYbZopfMVp4I3WUHncxPsf/AAoz9nH/AKIp8Pv/AAlrP/41R/woz9nH/oinw+/8Jaz/APjVZrOa PPzup36Lvdfae2y7JtGX1htO99Vbb08+ySt2XfUqftErYzeGtFs9T+HL+Lra51dY3SXTrzUrLTz5 MxF1dWNqkkl3GpGFiKhS7Jl4iBIvhPhzwxp8+ifDM/EX4a+KNW8NeG4/EulXlj/wh+qMhMtxDJZr /Z5jeX7OYkBj3ho42jQFg6KR9A/8KM/Zx/6Ip8Pv/CWs/wD41R/woz9nH/oinw+/8Jaz/wDjVZUM ywlKn7NTe7fTrFx7uzs3r6XvYdKvGnGKXNp/wfPTf8O7Z4pL4C17Rrj4eyaz4Tn8S+KdJ0nTbV9I 13wrPqcEKpc70NtrcKNHZXUSblkaSRo5NkeQBhzgWfwp8IaX4q0Dw/dfCLXbYQ/E/VptSjsPC2or ps2lSreLamZoIfs00GJoEG4sEjkkQ7UMor6K/wCFGfs4/wDRFPh9/wCEtZ//ABqj/hRn7OP/AERT 4ff+EtZ//Gq3jnWHTbc3rfay3d/5umu93rvayGsT7jhrquit9mUe/wDeuvNLU8W+J2l2GnfFW1uv Dvwav9Ln8MeJNHMeq2XhLVdSu72yRYBILK6gj+z2VpHEZIzArSCQ+ZmOJvmfrfBng/wZrPia6svi t8KdVv8Ax+ms6kkmsTaDcyWl/ZTNMIt9+F+zSWv2SVE+zSyEKV2eXvUV3n/CjP2cf+iKfD7/AMJa z/8AjVH/AAoz9nH/AKIp8Pv/AAlrP/41WMszwroql7R7WvpfZLfm2drteelkkTOtGSSXMrJL7r+e 2r09NbKxk/ss6BZ+FfgVoegReD7rQtSsLcw6vaPpMmnSzXiqBI/zonmk4UCZSytjhzjj5vvtCTUd K8U/2T8G/FPhmHxJ8PdQsm0jR/CXiCK6/tENHJbJf35iT7fOzeYWfbt+d43eZTvb6m/4UZ+zj/0R T4ff+EtZ/wDxqj/hRn7OP/RFPh9/4S1n/wDGqqGa4VVqlZzd5+nn/e87rqrLXe90sTGnOU0nq09u zv379f8AM+ftX0LUNIvNV0nwD8N/F/8AYOo+GPDlx4ktotA1CGXVliu5H1CMyTRr5909rMiurMZZ BujyWVlHrX7OOk6Bouv/ABN0/wAL+CtV8NaFf69BqOl283h280iB4XsbdGMKTRRgfvY5gVUAqeSA CCen/wCFGfs4/wDRFPh9/wCEtZ//ABqj/hRn7OP/AERT4ff+EtZ//GqdbNsJUhKDm/e327xevva2 5Ul2u++mU6kZQ5Pe6dOySvvu7bnzV4I8A+GJfiNpkfin4c/EG90Oxu/FzXUWq6Br11aS20t0k9n5 iSxsk7SIsrch3d1j35dYgMKT4ei78AX2pa/8JPFf/CQ6n8JrfSLO5t/CepC/OrQPdQukkkUPmozR /ZkYyEJLFhSWjBFfWX/CjP2cf+iKfD7/AMJaz/8AjVH/AAoz9nH/AKIp8Pv/AAlrP/41WyzzDK3v vRJbrpzefXm/BHX9ftNzSlq7/wDk3Nbfvp6HnHi3wX4T0+PwCb34W32qfDW+sL2TWtLt/DNzd3H9 qSwwmC8vLQRNcvKVjuEMroXV5AWIJBHsHwa0vxTonwq8LaT41ubqfW7XTIo7xrqQSThgOFlcEhpF XarNk5IJyc5rG/4UZ+zj/wBEU+H3/hLWf/xqux0Cy8IeFNJg0DwtpWn6Ppdru8iy0+zW3t4tzF22 xooVcszMcDkknqa4MTmNCpS5IzvrfW3eT7vX3reaUe2vnVHenGEbu3df8Hr177m3RVT+1bD/AJ7/ APjrf4Uf2rYf89//AB1v8K8/29L+Zfec/JLsW6Kqf2rYf89//HW/wo/tWw/57/8Ajrf4Ue3pfzL7 w5Jdi3RVT+1bD/nv/wCOt/hR/ath/wA9/wDx1v8ACj29L+ZfeHJLsW6Kqf2rYf8APf8A8db/AAo/ tWw/57/+Ot/hR7el/MvvDkl2LdFVP7VsP+e//jrf4Uf2rYf89/8Ax1v8KPb0v5l94ckuxboqp/at h/z3/wDHW/wo/tWw/wCe/wD463+FHt6X8y+8OSXYt0VU/tWw/wCe/wD463+FH9q2H/Pf/wAdb/Cj 29L+ZfeHJLsW6Kqf2rYf89//AB1v8KP7VsP+e/8A463+FHt6X8y+8OSXYt0VU/tWw/57/wDjrf4U f2rYf89//HW/wo9vS/mX3hyS7Fuiqn9q2H/Pf/x1v8KP7VsP+e//AI63+FHt6X8y+8OSXYt0VU/t Ww/57/8Ajrf4Uf2rYf8APf8A8db/AAo9vS/mX3hyS7Fuiqn9q2H/AD3/APHW/wAKP7VsP+e//jrf 4Ue3pfzL7w5Jdi3RVT+1bD/nv/463+FH9q2H/Pf/AMdb/Cj29L+ZfeHJLsW6Kqf2rYf89/8Ax1v8 KP7VsP8Anv8A+Ot/hR7el/MvvDkl2LdFVP7VsP8Anv8A+Ot/hR/ath/z3/8AHW/wo9vS/mX3hyS7 Fuiqn9q2H/Pf/wAdb/Cj+1bD/nv/AOOt/hR7el/MvvDkl2LdFVP7VsP+e/8A463+FH9q2H/Pf/x1 v8KPb0v5l94ckuxboqp/ath/z3/8db/Cj+1bD/nv/wCOt/hR7el/MvvDkl2LdFVP7VsP+e//AI63 +FH9q2H/AD3/APHW/wAKPb0v5l94ckuxboqp/ath/wA9/wDx1v8ACj+1bD/nv/463+FHt6X8y+8O SXYt0VU/tWw/57/+Ot/hR/ath/z3/wDHW/wo9vS/mX3hyS7Fuiqn9q2H/Pf/AMdb/Cj+1bD/AJ7/ APjrf4Ue3pfzL7w5Jdi3RVT+1bD/AJ7/APjrf4Uf2rYf89//AB1v8KPb0v5l94ckuxZk5Rh14NFV X1OxZSvn9Rj7p/wormr1YNq0kaU4yW6P/9kKZW5kc3RyZWFtCmVuZG9iagoxNjMgMCBvYmoKNzQx NTkKZW5kb2JqCjE2MCAwIG9iago8PCAvTGVuZ3RoIDE2MSAwIFIgL1R5cGUgL1hPYmplY3QgL1N1 YnR5cGUgL0ltYWdlIC9XaWR0aCA3MjAgL0hlaWdodCAxNSAvSW50ZXJwb2xhdGUKdHJ1ZSAvQ29s b3JTcGFjZSA1OCAwIFIgL0ludGVudCAvUGVyY2VwdHVhbCAvQml0c1BlckNvbXBvbmVudCA4IC9G aWx0ZXIgL0RDVERlY29kZQo+PgpzdHJlYW0K/9j/4AAQSkZJRgABAQAAAQABAAD/4gVASUNDX1BS T0ZJTEUAAQEAAAUwYXBwbAIgAABtbnRyUkdCIFhZWiAH2QACABkACwAaAAthY3NwQVBQTAAAAABh cHBsAAAAAAAAAAAAAAAAAAAAAAAA9tYAAQAAAADTLWFwcGwAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAtkc2NtAAABCAAAAvJkZXNjAAAD/AAAAG9nWFlaAAAE bAAAABR3dHB0AAAEgAAAABRyWFlaAAAElAAAABRiWFlaAAAEqAAAABRyVFJDAAAEvAAAAA5jcHJ0 AAAEzAAAADhjaGFkAAAFBAAAACxnVFJDAAAEvAAAAA5iVFJDAAAEvAAAAA5tbHVjAAAAAAAAABEA AAAMZW5VUwAAACYAAAJ+ZXNFUwAAACYAAAGCZGFESwAAAC4AAAHqZGVERQAAACwAAAGoZmlGSQAA ACgAAADcZnJGVQAAACgAAAEqaXRJVAAAACgAAAJWbmxOTAAAACgAAAIYbmJOTwAAACYAAAEEcHRC UgAAACYAAAGCc3ZTRQAAACYAAAEEamFKUAAAABoAAAFSa29LUgAAABYAAAJAemhUVwAAABYAAAFs emhDTgAAABYAAAHUcnVSVQAAACIAAAKkcGxQTAAAACwAAALGAFkAbABlAGkAbgBlAG4AIABSAEcA QgAtAHAAcgBvAGYAaQBpAGwAaQBHAGUAbgBlAHIAaQBzAGsAIABSAEcAQgAtAHAAcgBvAGYAaQBs AFAAcgBvAGYAaQBsACAARwDpAG4A6QByAGkAcQB1AGUAIABSAFYAQk4AgiwAIABSAEcAQgAgMNcw 7TDVMKEwpDDrkBp1KAAgAFIARwBCACCCcl9pY8+P8ABQAGUAcgBmAGkAbAAgAFIARwBCACAARwBl AG4A6QByAGkAYwBvAEEAbABsAGcAZQBtAGUAaQBuAGUAcwAgAFIARwBCAC0AUAByAG8AZgBpAGxm bpAaACAAUgBHAEIAIGPPj/Blh072AEcAZQBuAGUAcgBlAGwAIABSAEcAQgAtAGIAZQBzAGsAcgBp AHYAZQBsAHMAZQBBAGwAZwBlAG0AZQBlAG4AIABSAEcAQgAtAHAAcgBvAGYAaQBlAGzHfLwYACAA UgBHAEIAINUEuFzTDMd8AFAAcgBvAGYAaQBsAG8AIABSAEcAQgAgAEcAZQBuAGUAcgBpAGMAbwBH AGUAbgBlAHIAaQBjACAAUgBHAEIAIABQAHIAbwBmAGkAbABlBB4EMQRJBDgEOQAgBD8EQAQ+BEQE OAQ7BEwAIABSAEcAQgBVAG4AaQB3AGUAcgBzAGEAbABuAHkAIABwAHIAbwBmAGkAbAAgAFIARwBC AABkZXNjAAAAAAAAABRHZW5lcmljIFJHQiBQcm9maWxlAAAAAAAAAAAAAAAUR2VuZXJpYyBSR0Ig UHJvZmlsZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA WFlaIAAAAAAAAFp1AACscwAAFzRYWVogAAAAAAAA81IAAQAAAAEWz1hZWiAAAAAAAAB0TQAAPe4A AAPQWFlaIAAAAAAAACgaAAAVnwAAuDZjdXJ2AAAAAAAAAAEBzQAAdGV4dAAAAABDb3B5cmlnaHQg MjAwNyBBcHBsZSBJbmMuLCBhbGwgcmlnaHRzIHJlc2VydmVkLgBzZjMyAAAAAAABDEIAAAXe///z JgAAB5IAAP2R///7ov///aMAAAPcAADAbP/hAEBFeGlmAABNTQAqAAAACAABh2kABAAAAAEAAAAa AAAAAAACoAIABAAAAAEAAALQoAMABAAAAAEAAAAPAAAAAP/bAEMAAwICAgICAwICAgMDAwMEBwQE BAQECAYGBQcKCQoKCgkJCQsMDw0LCw8MCQkNEg4PEBAREREKDRMUExEUDxEREf/bAEMBAwMDBAQE CAQECBELCQsRERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERER Ef/AABEIAA8C0AMBIgACEQEDEQH/xAAfAAABBQEBAQEBAQAAAAAAAAAAAQIDBAUGBwgJCgv/xAC1 EAACAQMDAgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEUMoGRoQgjQrHBFVLR8CQzYnKCCQoW FxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoOEhYaHiImK kpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy 8/T19vf4+fr/xAAfAQADAQEBAQEBAQEBAAAAAAAAAQIDBAUGBwgJCgv/xAC1EQACAQIEBAMEBwUE BAABAncAAQIDEQQFITEGEkFRB2FxEyIygQgUQpGhscEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkq NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqi o6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2dri4+Tl5ufo6ery8/T19vf4+fr/2gAM AwEAAhEDEQA/APgSiiivPPz8KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigD/2QplbmRzdHJlYW0KZW5kb2JqCjE2MSAwIG9iagoyMjIx CmVuZG9iagoxNjcgMCBvYmoKPDwgL0xlbmd0aCAxNjggMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl ID4+CnN0cmVhbQp4AZVW224TMRB991cciRevRDZr7yVJnyg3IcRFFUEIIR7atLkgutsmaeGH+E9m bR9nswlFVSvtxGOPz5wzY/sWZ7hFJn8jm6EsMqyv8AU1hi82BrMNDDazvn+OLK2waudYP8fAqKPz 3FLnWck+xv0cGBS2/Z9d4/kUZhxGxxilFtao6TWGr02ayfzpHN+glwkGWWqgt9sbmifDYUX7J42G xq9EMFqlzzkQ10Ujrem7orFN8B3Tt3g1dbREuLaokFcq4C0C3gJFkU4ym5cwIzjQtgN6xqjN2oGB jvs8S5Sgg17VsqNLLLo4d3X9FJYRMhqGRhwZtKGEGfG0aJzhuRqE0DFK0c2ulT3PkI8LVFUFYytR XgXlnaptUWROfSd2Rz1ZV5osyJdXng755nmam0luMSq9hkWHjifV+ATM7s7lIQyIco4Jyd99N3Rg 3tJmxq2IOPBuzy84kRFW/Qi+aFqWg6dOlDAjAws0cXnckHsQ4v35lgsbXymyUmaHAlFnrkRc9lXl iey1zj/IE56EdF9LNtSSfAvYwFpO1vSfBNMfB9XYMn0sgp1ICF+HEkKxeU4TlCU0pB5d9n3CmLiv RUkSn8jtG28o/ZEjn2m8C9FecgAfaMXJUy+gROQeG0rg6l72kv50oC76qKIuSzRrKc0wbx6tGGoJ BhFZ4zIuWN/Tyy13qoJDjYTwHYko8P4J8ADnpY2chwNL6Q7K9uSSRJu7NQUgtLbEI4RlHL28W+8g h3MiZN/UiAnecAHDMq85DU64hB9Ruj6y3XvKxk1/D045tGAINDfkirEECzc6FvbxPI4m/tCI5S8H P6uC2GL2RIO6oUk0IX+lSQwX9ydKBnTN6WPCnZKbhdKgi/vc06gXO1oZkPEO8Ckd9fk/vvRBFsN9 tHeGmDzvVePjDxGJcajE6aNPkVBYSsvSiZE7RH9N5BZt76jj/Rw6ZdfP9X5D+154sKEvKJK0Fs2d OHFEfD7YdWgsyhYljcbivyeCkjdMRwM5hY3cB+45cKyUGXlONCyVVQ8T/fHwrC9j+e8VxrEXnHIv uP17vHODl6NJWrb3/+GTRsZN1YGv5AmmrTwveBOd/QXP5BeBCmVuZHN0cmVhbQplbmRvYmoKMTY4 IDAgb2JqCjgyMwplbmRvYmoKMTY2IDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgMTM5IDAg UiAvUmVzb3VyY2VzIDE2OSAwIFIgL0NvbnRlbnRzIDE2NyAwIFIgL01lZGlhQm94ClswIDAgNzIw IDU0MF0gPj4KZW5kb2JqCjE2OSAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29s b3JTcGFjZSA8PCAvQ3MxIDcgMCBSIC9DczIgOCAwIFIgPj4gL0ZvbnQgPDwKL0Y0LjAgMTIgMCBS IC9GMy4wIDExIDAgUiAvRjIuMCAxMCAwIFIgL0YxLjAgOSAwIFIgPj4gPj4KZW5kb2JqCjE3MiAw IG9iago8PCAvTGVuZ3RoIDE3MyAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngB nVlNb9tGEL3vr5giFwqwaS5FUrRP/UZRtCiMqOih6cFVLddJbDcS66I/qP+zszv7HmmtZCVGEoja nX078+bN7Ir5IJfyQSr9s6graZtKNtfyi9zL2VdbL6uteNmudufXUpWd3Aab2my8eLfXLi6NM7e6 j49fT700dfi7upMvl+L7NNrLoqyl9m55J2ff+rJS++VafpXiz5mcVqWXYhj+wuPF2VmH5/d4eMDD PzP1sXbFFQa4jg/lPeau8TDM5DdZfi/fLCMtdLduOpl3LvnbJH8baZryvKrnrfiFRKfridMroD5s ojNScJ/PZ069k+L2XneMgXEKtrd3J1IDocKDxwNHTgOUMqMzwZv4YFydJmiiNNPoQtrnlcz7Rrqu E193mnmXMh+zGkRRxezHZE+yp+taX6X0zTujQz/rruy73reyaC2HzYSOV/P2QjQ634fINd7IALn5 I0Y2mSERiSvLlhrcyOMWxqUA6BEPtBv+htWV6iPuJqsE9kArQt0mGw4MGaJmNML8a0S6KJNIZOCg 64zOsYCMRg03rKrKfj+ZKq2+Sdqqk7b0M9ZCV6q8msbEtdA8x4ooPpvJ8q2plFma5ucA5LxRPzTR UaoKzfrSsomBPYIxDV1FpGRrFsKDw4NqNtlqwqIFviuj8ftN+pT0Cezf0/e3KQXcwupE9xoAlbtx sR/NFcwW4ZLHUuQocBlgXDxczZzFG5JuTzDiQI6HkIPSYuzWbZQtCA6fqhii7u0wWj2hFK3DTFQQ U9Y2Vk7TlIFOukcaQfgd9qRJitcViC1bg4jIDFLCgZEgs3XFADTruaNCBm3bkRYYcIAeYYYy4ww3 RDjgmPml81wDNMapeU28B7dH4oNX9i/WZFY6eR5CNfa9VaMl4xOrMYeMqe37PLXgnMRigJwgUKQr MeD2aJ50YQ2yxAkQDDAr4FEkAwyAgDLK3GJGSDvzijXAoAUGUCmcGIUGEwgO/rBfrOFJ7gBtsAhR Gqgr3rChlUmtlBMGTkYZjxLKNJN38Jhg7/f0WxbCGC2CTCOThstEIcq8EWXC2GFTi5RREQ475s48 5UjSJUo7tIxncSxsgkJUHMh2ASbyoImxO9BLkvdmtlPNESqdsFlm8tIL1eyb81jO+dnqjp+tOaQl uzl/erg6vbwyOcgfG7NeRSONyBbZQ2poeY3ziQpHb6WCQDB24bYEAer6IVGfJYno8Ahg9Ay7DISH Jg62Ca7do0H6Zhu5AvhcBKfhyRoDDFwHXlCWi3Rjn56p2HyiUUtQ0qgrSBB3P9JgxtNwQlgA3RPq 8SI6VKpjs6ZfWSwQDJll9i8mBDq9T+pFNfy+019tB0vJbp2n+pOxmWst1ZXS6M/bp7Xkilcfc09F LY2YXVsuAiZryeGH4DJVTBYMVMGgGCYllqhxbPigCNLC990bLDOHKwjuXtusKrk9MFHiR2XyPtUk Fq4ZAJcyEk4haixCBKhJqgGGMDikcNmvcOvUWAQQgP74M25Zr5EfTIEp9djPVVPhBHmmWA9Jod5p q+GdAMkfMtJZpQP62PT+HVsuubSgxmpEkGxniBYcE5zkYhP7dEW2GS4/zBsx6DqniMr4sDEcgTzL SdmGn+DPlC3uJmOJWdm2+8pWPq5sc0wr23YsW/6+/GKmr0/CywnoggSAMwRJHhAtL8Gvv4PKfkpN gLL7IQ18bRZjN0TBsoIJD0dINwaQK3PIFeuxEPNkZU6q/hdN2UgBGb2D0zzBsQYb8jZHV6AneJ85 TSwuIZ9ojEA/2jzGdhiYfkFtLsbaZJvOmVrnQ0wKfGaclD6iYJwY4FpwhEbDCTKyQZOGxI625CeF lR2Bue4X53oEzqt0oWjxXqX4bzz9MhTrdE4P0PAnHKTn4VKao2inQ1NVnuwlAolSOux12nLmvNe3 gCo7M3lHG9UbXz3E1rdO1aLU2QQtVkOcipKwKeLRZosUMCf5CExuQH3uDEc2xLHN44Vp/+ZjXWsq zUSr1R6IR0czOMSdFrv0OtZecrWtsl+cJGoQADD2Mh/J3CYWXaEKNFe2qw39U63ZIJA4M2VWG6e2 DN00lJ+9VTwgGL0V7QhG38XG13mUnQpGG0jYdZJHxE6aMn/uOIXgmRhNsF0AyC2dz2CwEeNcEcZs J04RhbjYmqufza85Rdtsa0a0Aa7esC0dXASnmGHOZE4xEKDpQWxo3Og+E/wnyFuKctqAL92h/5d5 +nZ+opRWO1Eb3urn/1Gh476zV01zNqi6HjvU5f93AxKKCmVuZHN0cmVhbQplbmRvYmoKMTczIDAg b2JqCjE2ODgKZW5kb2JqCjE3MSAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDEzOSAwIFIg L1Jlc291cmNlcyAxNzQgMCBSIC9Db250ZW50cyAxNzIgMCBSIC9NZWRpYUJveApbMCAwIDcyMCA1 NDBdID4+CmVuZG9iagoxNzQgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9y U3BhY2UgPDwgL0NzMSA3IDAgUiAvQ3MyIDggMCBSID4+IC9Gb250IDw8Ci9GMi4wIDEwIDAgUiAv RjMuMCAxMSAwIFIgL0YxLjAgOSAwIFIgL0Y3LjEgMzAgMCBSIC9GNS4wIDEzIDAgUiAvRjYuMCAx NCAwIFIKL0Y0LjAgMTIgMCBSID4+ID4+CmVuZG9iagoxNzcgMCBvYmoKPDwgL0xlbmd0aCAxNzgg MCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AZWUzW7bMAzH73oKHuVDHEm2ZPva bgM2YMOCGNih2KHznC1r3TZ2uo8H2nuOskw6jpOhgQ+2KYrk/0dKO1jBDhQ+mVFgUwVtDZ/gAZbX nYaqAw1ddby+ARU72HofE3w0aHHKb/mxbqv6af98ew/tFjP5LP7Rtn9VDSzfNvjz6rEvZLJsjRVT B19r4uI8s5AmObg0h8LE+DcW3RekYlUoXTiVY6VGJYXRThwYfam9gh3q8+UsNMW1ifIBMe9Vibaw im+T2LhwYAsoG7F8Y2PUAOUGbkB+iGCBaUDW9PF7H/nEIGF4r8nALk/BV8gugs9QvoPXJRIIAjGp l+YlzoQ5leVpYjB8Zl3ujFeoVZGjyL4Dc1l9nEFPgL9IsN2xyp3TKSQoA7swKpJ/I1H+CPUEf8Q1 AXU6YpIgIO3MNKIIjNZ/HghORVB+kWVLH0TpOxnItXoMFiFvaWkACHKhyJQeosQGn0eFQy1eIIkh ZWYOCRiS8JguhDSLiIN0HYkwSPekaJANsuPBISQzVkceQpIH463u2IfWJtP3X2R+ui5BpnG2ZoMV mIlVf6wuZjYPeSPk+plgfaGPhhWTTILGPNl3BNv+rIn/OFL6kpGa8/H3l79HTpw7be05PngNnD94 85B88OYhcajes+aWux9wCMmcGj5NPHrs3PAXH2HCyodxH+H1ivcdB+SkvIdaQHs5akeWYbOQvOcb dZQ2c0J2+Xrsshmu3CG+GG9lduXmc7jq7rDPq3//tnMLCmVuZHN0cmVhbQplbmRvYmoKMTc4IDAg b2JqCjU2OAplbmRvYmoKMTc2IDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgMTM5IDAgUiAv UmVzb3VyY2VzIDE3OSAwIFIgL0NvbnRlbnRzIDE3NyAwIFIgL01lZGlhQm94ClswIDAgNzIwIDU0 MF0gPj4KZW5kb2JqCjE3OSAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgL0ltYWdlQiAv SW1hZ2VDIC9JbWFnZUkgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcgMCBSCi9DczIgOCAwIFIgPj4g L0ZvbnQgPDwgL0Y1LjAgMTMgMCBSID4+IC9YT2JqZWN0IDw8IC9JbTE1IDE4MCAwIFIgPj4gPj4K ZW5kb2JqCjE4MCAwIG9iago8PCAvTGVuZ3RoIDE4MSAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5 cGUgL0ltYWdlIC9XaWR0aCA3MjAgL0hlaWdodCAxNSAvSW50ZXJwb2xhdGUKdHJ1ZSAvQ29sb3JT cGFjZSA1OCAwIFIgL0ludGVudCAvUGVyY2VwdHVhbCAvQml0c1BlckNvbXBvbmVudCA4IC9GaWx0 ZXIgL0RDVERlY29kZQo+PgpzdHJlYW0K/9j/4AAQSkZJRgABAQAAAQABAAD/4gVASUNDX1BST0ZJ TEUAAQEAAAUwYXBwbAIgAABtbnRyUkdCIFhZWiAH2QACABkACwAaAAthY3NwQVBQTAAAAABhcHBs AAAAAAAAAAAAAAAAAAAAAAAA9tYAAQAAAADTLWFwcGwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAtkc2NtAAABCAAAAvJkZXNjAAAD/AAAAG9nWFlaAAAEbAAA ABR3dHB0AAAEgAAAABRyWFlaAAAElAAAABRiWFlaAAAEqAAAABRyVFJDAAAEvAAAAA5jcHJ0AAAE zAAAADhjaGFkAAAFBAAAACxnVFJDAAAEvAAAAA5iVFJDAAAEvAAAAA5tbHVjAAAAAAAAABEAAAAM ZW5VUwAAACYAAAJ+ZXNFUwAAACYAAAGCZGFESwAAAC4AAAHqZGVERQAAACwAAAGoZmlGSQAAACgA AADcZnJGVQAAACgAAAEqaXRJVAAAACgAAAJWbmxOTAAAACgAAAIYbmJOTwAAACYAAAEEcHRCUgAA ACYAAAGCc3ZTRQAAACYAAAEEamFKUAAAABoAAAFSa29LUgAAABYAAAJAemhUVwAAABYAAAFsemhD TgAAABYAAAHUcnVSVQAAACIAAAKkcGxQTAAAACwAAALGAFkAbABlAGkAbgBlAG4AIABSAEcAQgAt AHAAcgBvAGYAaQBpAGwAaQBHAGUAbgBlAHIAaQBzAGsAIABSAEcAQgAtAHAAcgBvAGYAaQBsAFAA cgBvAGYAaQBsACAARwDpAG4A6QByAGkAcQB1AGUAIABSAFYAQk4AgiwAIABSAEcAQgAgMNcw7TDV MKEwpDDrkBp1KAAgAFIARwBCACCCcl9pY8+P8ABQAGUAcgBmAGkAbAAgAFIARwBCACAARwBlAG4A 6QByAGkAYwBvAEEAbABsAGcAZQBtAGUAaQBuAGUAcwAgAFIARwBCAC0AUAByAG8AZgBpAGxmbpAa ACAAUgBHAEIAIGPPj/Blh072AEcAZQBuAGUAcgBlAGwAIABSAEcAQgAtAGIAZQBzAGsAcgBpAHYA ZQBsAHMAZQBBAGwAZwBlAG0AZQBlAG4AIABSAEcAQgAtAHAAcgBvAGYAaQBlAGzHfLwYACAAUgBH AEIAINUEuFzTDMd8AFAAcgBvAGYAaQBsAG8AIABSAEcAQgAgAEcAZQBuAGUAcgBpAGMAbwBHAGUA bgBlAHIAaQBjACAAUgBHAEIAIABQAHIAbwBmAGkAbABlBB4EMQRJBDgEOQAgBD8EQAQ+BEQEOAQ7 BEwAIABSAEcAQgBVAG4AaQB3AGUAcgBzAGEAbABuAHkAIABwAHIAbwBmAGkAbAAgAFIARwBCAABk ZXNjAAAAAAAAABRHZW5lcmljIFJHQiBQcm9maWxlAAAAAAAAAAAAAAAUR2VuZXJpYyBSR0IgUHJv ZmlsZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWFla IAAAAAAAAFp1AACscwAAFzRYWVogAAAAAAAA81IAAQAAAAEWz1hZWiAAAAAAAAB0TQAAPe4AAAPQ WFlaIAAAAAAAACgaAAAVnwAAuDZjdXJ2AAAAAAAAAAEBzQAAdGV4dAAAAABDb3B5cmlnaHQgMjAw NyBBcHBsZSBJbmMuLCBhbGwgcmlnaHRzIHJlc2VydmVkLgBzZjMyAAAAAAABDEIAAAXe///zJgAA B5IAAP2R///7ov///aMAAAPcAADAbP/hAEBFeGlmAABNTQAqAAAACAABh2kABAAAAAEAAAAaAAAA AAACoAIABAAAAAEAAALQoAMABAAAAAEAAAAPAAAAAP/bAEMAAwICAgICAwICAgMDAwMEBwQEBAQE CAYGBQcKCQoKCgkJCQsMDw0LCw8MCQkNEg4PEBAREREKDRMUExEUDxEREf/bAEMBAwMDBAQECAQE CBELCQsREREREREREREREREREREREREREREREREREREREREREREREREREREREREREREREREREf/A ABEIAA8C0AMBIgACEQEDEQH/xAAfAAABBQEBAQEBAQAAAAAAAAAAAQIDBAUGBwgJCgv/xAC1EAAC AQMDAgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEUMoGRoQgjQrHBFVLR8CQzYnKCCQoWFxgZ GiUmJygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOU lZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T1 9vf4+fr/xAAfAQADAQEBAQEBAQEBAAAAAAAAAQIDBAUGBwgJCgv/xAC1EQACAQIEBAMEBwUEBAAB AncAAQIDEQQFITEGEkFRB2FxEyIygQgUQpGhscEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Sl pqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2dri4+Tl5ufo6ery8/T19vf4+fr/2gAMAwEA AhEDEQA/APgSiiivPPz8KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigD/2QplbmRzdHJlYW0KZW5kb2JqCjE4MSAwIG9iagoyMjIxCmVu ZG9iagoxODQgMCBvYmoKPDwgL0xlbmd0aCAxODUgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+ CnN0cmVhbQp4AZ1XyW4bRxC991fUsQl4RtM9K3lKLDgJkosDMxAQ0weHsRwmoRxbzPKZ+aS8Xl7N cBlFFiSgi73U8upVdc9H+V4+SoW/3lfSNpV8eic3cidX1/dOtvfi5H57un4rVdnJLuzxaY8TZy7u i0fjyg52XPxZOGl8+N/u5fla3JBnB+lLL96Z9V6uvnJlhf3rW3kt9peFFFXpxB4Of1BcXV11lH+n 8IHC3wv46I19ywk9p0J5x7V3FA4LeSPrb+XFOsKi7vqmk7oz2d8m+9tI05TLytetuF6i037i9JZa P3yKzohVO18sDLwTu7uDxRiYLnHvbv9MPDVUFBwFnSmCKiCDleBNFBJWRVatWpqZ6Np+WbZSV8iH CfmYxId516XQaoZmPRStf00gBfbgZD000nWdON9lAhmSI3CriiSKnJmQAOdaF6wGFtRdQhVj70s3 NC2ENpluysqQCkA1QhdAdUMAEdDFGYkTgOLma85w81sQJO5Jo7HiAeDFVM85Vbu+HKq6nzoF0id+ uqoA/m0b3HGFb1bw5bO0N91Q9oP30J7Yj5CV/VCWVH8Zsw8b7xlzojBmfuYSCK+WTcxOALZDfuqh ZnGfl2/MEKrft8ty6RonXQ/Ku3AA1S6ViRumycMyFKbk+UwZjLGEM2W6SRCJufC0XRjwE8IqcRiS CoiUqbw43kxyHpQY+1M+keoHuv4hENSVOoFY8CXZTS0BWwFetPI+jsaSJLs8f7wu9lmeh+a6L2ux Yz7ySvbCqGqkJZpQmxMdceHVQZcOf+bN9yhl1IqFnWLpEeQ1XUcfPFZHVzU4nE1RMvxN6AxpqiLy m8WEJNO2jOKbTWqbWxyTatCXVXVLGyudenRSHd2iy/9SGSdSJ0XG0N5j/Bqupp1br6mMWzVHL9ke uPVA8FT9bzSseTwATx9SjUNFj/qMgp9Iri57sT9mx15R+caiSSbYhyQY+yTYhxPYw3WoiI2wq5St RUcjVvTodMyJQi/Mvp/BXhBDFpmSS2HXRPzFIHWJav8fZlzr0Fw35ZDgdd1QlXV0rDiH+jvi+g0F WtrYmlNKvoi5uXClP0R1hydJvM7J9QR6zKex6dUBKqw8zX0u6MyOseegz3UhJWdxy7wo+nuyfmwm BOXR8NfhFYFTRd30c9hfoPl5vR/R3DzyynDNchZyIeTGrjTDT4VcCPlI/IL8JvTE97wxzKFqrKZH CyCQ2oWXVUDVOcc2MqX02FFSH9H29ZzUosUNQZCn9RHXL9PL4gKnFWBwWtuWCvTgeBzhe0nYlHy8 ODmy0fI3LtzCt2WT+DZT7SM0o0SQcmeduQ7NeNcjBafXoXbKI57O3YLm9GmDB+tcaxDb09zFt016 8x/DyE4g9gXR4ZuBG8nGW05sz6qdGcCoj78HPuziRxvf5dMK9ctahu7hR930uwyXa/z4gF3A7OIT KgiIKvSdJO4ppMrA4piVRBlMoZXFc3kP2PVDvpbWeP1MgvoPQerLvQplbmRzdHJlYW0KZW5kb2Jq CjE4NSAwIG9iagoxMTE1CmVuZG9iagoxODMgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAx MzkgMCBSIC9SZXNvdXJjZXMgMTg2IDAgUiAvQ29udGVudHMgMTg0IDAgUiAvTWVkaWFCb3gKWzAg MCA3MjAgNTQwXSA+PgplbmRvYmoKMTg2IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBd IC9Db2xvclNwYWNlIDw8IC9DczEgNyAwIFIgL0NzMiA4IDAgUiA+PiAvRm9udCA8PAovRjYuMCAx NCAwIFIgL0Y0LjAgMTIgMCBSIC9GMy4wIDExIDAgUiAvRjIuMCAxMCAwIFIgL0YxLjAgOSAwIFIg Pj4gPj4KZW5kb2JqCjE5MCAwIG9iago8PCAvTGVuZ3RoIDE5MSAwIFIgL0ZpbHRlciAvRmxhdGVE ZWNvZGUgPj4Kc3RyZWFtCngBlVNdT9swFH33rziPjkTc2E3q9JUOENMegEVCYuKhy9IR0VBws037 93Nt3wu0AwnlwY7v1znHx0+4xBMK/1lToCoLuA7XeMBksdVot9DYtvvxFQo1Q7/LMTFHQ4v/5U0u Otd2j+Ov5Rqu95N2U3afrsLSDpicD3qGT5sA5FW4MpV4nRBrwyA//apbL8f+d7fYrDeuH7rR9W2c okPzXMNoT8qo2oZOxw10nUI1rDLwaBoP4bRSHhKaFb5BLjLkhY/JDW2uaHOCzFM3Ql6HFfIsrUdp jXHI8/T/QJVjOujowPVxJ+RARRd3FGQIFDIUKWmjUkOdwZZKQ+pMRNgU4ZqCanxuTPEnt2g+46QJ qrNcZY1Sl2gH4aUySSq/6nmpplVVwcw/qpcIUn6hyYk1JCtzTxxPEyOW3Q1LKvPy3Yr3AGMP8HSm Cl1YWHsI+Acp5bj/Ks2ma8oZJ18YhSg1bxNQIR0n5WtCzA2eieZU+gbD4Kz85W29dUlTXShb+XsK tOOryL2XdWnVvLRTGCOCr+sXvr5JHMkfpPtXth3TYBbfIx0h/wab+Uex7/Q/B4RJKG5Lg9KBkIdz HqkL5ZJUjrV6fiZcPmbRXXzgqPyY5f9JnbnRzkts/st/rgkBagplbmRzdHJlYW0KZW5kb2JqCjE5 MSAwIG9iago0NzcKZW5kb2JqCjE4OCAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDE4OSAw IFIgL1Jlc291cmNlcyAxOTIgMCBSIC9Db250ZW50cyAxOTAgMCBSIC9NZWRpYUJveApbMCAwIDcy MCA1NDBdID4+CmVuZG9iagoxOTIgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IC9JbWFn ZUIgL0ltYWdlQyAvSW1hZ2VJIF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUgovQ3MyIDggMCBS ID4+IC9Gb250IDw8IC9GOC4wIDU2IDAgUiAvRjUuMCAxMyAwIFIgPj4gL1hPYmplY3QgPDwgL0lt MTYgMTkzIDAgUgo+PiA+PgplbmRvYmoKMTkzIDAgb2JqCjw8IC9MZW5ndGggMTk0IDAgUiAvVHlw ZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDcyMCAvSGVpZ2h0IDE1IC9JbnRlcnBv bGF0ZQp0cnVlIC9Db2xvclNwYWNlIDU4IDAgUiAvSW50ZW50IC9QZXJjZXB0dWFsIC9CaXRzUGVy Q29tcG9uZW50IDggL0ZpbHRlciAvRENURGVjb2RlCj4+CnN0cmVhbQr/2P/gABBKRklGAAEBAAAB AAEAAP/iBUBJQ0NfUFJPRklMRQABAQAABTBhcHBsAiAAAG1udHJSR0IgWFlaIAfZAAIAGQALABoA C2Fjc3BBUFBMAAAAAGFwcGwAAAAAAAAAAAAAAAAAAAAAAAD21gABAAAAANMtYXBwbAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC2RzY20AAAEIAAAC8mRlc2MA AAP8AAAAb2dYWVoAAARsAAAAFHd0cHQAAASAAAAAFHJYWVoAAASUAAAAFGJYWVoAAASoAAAAFHJU UkMAAAS8AAAADmNwcnQAAATMAAAAOGNoYWQAAAUEAAAALGdUUkMAAAS8AAAADmJUUkMAAAS8AAAA Dm1sdWMAAAAAAAAAEQAAAAxlblVTAAAAJgAAAn5lc0VTAAAAJgAAAYJkYURLAAAALgAAAepkZURF AAAALAAAAahmaUZJAAAAKAAAANxmckZVAAAAKAAAASppdElUAAAAKAAAAlZubE5MAAAAKAAAAhhu Yk5PAAAAJgAAAQRwdEJSAAAAJgAAAYJzdlNFAAAAJgAAAQRqYUpQAAAAGgAAAVJrb0tSAAAAFgAA AkB6aFRXAAAAFgAAAWx6aENOAAAAFgAAAdRydVJVAAAAIgAAAqRwbFBMAAAALAAAAsYAWQBsAGUA aQBuAGUAbgAgAFIARwBCAC0AcAByAG8AZgBpAGkAbABpAEcAZQBuAGUAcgBpAHMAawAgAFIARwBC AC0AcAByAG8AZgBpAGwAUAByAG8AZgBpAGwAIABHAOkAbgDpAHIAaQBxAHUAZQAgAFIAVgBCTgCC LAAgAFIARwBCACAw1zDtMNUwoTCkMOuQGnUoACAAUgBHAEIAIIJyX2ljz4/wAFAAZQByAGYAaQBs ACAAUgBHAEIAIABHAGUAbgDpAHIAaQBjAG8AQQBsAGwAZwBlAG0AZQBpAG4AZQBzACAAUgBHAEIA LQBQAHIAbwBmAGkAbGZukBoAIABSAEcAQgAgY8+P8GWHTvYARwBlAG4AZQByAGUAbAAgAFIARwBC AC0AYgBlAHMAawByAGkAdgBlAGwAcwBlAEEAbABnAGUAbQBlAGUAbgAgAFIARwBCAC0AcAByAG8A ZgBpAGUAbMd8vBgAIABSAEcAQgAg1QS4XNMMx3wAUAByAG8AZgBpAGwAbwAgAFIARwBCACAARwBl AG4AZQByAGkAYwBvAEcAZQBuAGUAcgBpAGMAIABSAEcAQgAgAFAAcgBvAGYAaQBsAGUEHgQxBEkE OAQ5ACAEPwRABD4ERAQ4BDsETAAgAFIARwBCAFUAbgBpAHcAZQByAHMAYQBsAG4AeQAgAHAAcgBv AGYAaQBsACAAUgBHAEIAAGRlc2MAAAAAAAAAFEdlbmVyaWMgUkdCIFByb2ZpbGUAAAAAAAAAAAAA ABRHZW5lcmljIFJHQiBQcm9maWxlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABYWVogAAAAAAAAWnUAAKxzAAAXNFhZWiAAAAAAAADzUgABAAAAARbPWFla IAAAAAAAAHRNAAA97gAAA9BYWVogAAAAAAAAKBoAABWfAAC4NmN1cnYAAAAAAAAAAQHNAAB0ZXh0 AAAAAENvcHlyaWdodCAyMDA3IEFwcGxlIEluYy4sIGFsbCByaWdodHMgcmVzZXJ2ZWQuAHNmMzIA AAAAAAEMQgAABd7///MmAAAHkgAA/ZH///ui///9owAAA9wAAMBs/+EAQEV4aWYAAE1NACoAAAAI AAGHaQAEAAAAAQAAABoAAAAAAAKgAgAEAAAAAQAAAtCgAwAEAAAAAQAAAA8AAAAA/9sAQwADAgIC AgIDAgICAwMDAwQHBAQEBAQIBgYFBwoJCgoKCQkJCwwPDQsLDwwJCQ0SDg8QEBEREQoNExQTERQP ERER/9sAQwEDAwMEBAQIBAQIEQsJCxERERERERERERERERERERERERERERERERERERERERERERER ERERERERERERERERERER/8AAEQgADwLQAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAAAAAB AgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGhCCNC scEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0 dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY 2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkKC//E ALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoW JDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWG h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp 6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A+BKKKK88/PwooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAP/ZCmVuZHN0cmVhbQplbmRvYmoK MTk0IDAgb2JqCjIyMjEKZW5kb2JqCjE5NyAwIG9iago8PCAvTGVuZ3RoIDE5OCAwIFIgL0ZpbHRl ciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBrVbLUtwwELzrK+ZoHzCS375CoEKKqoRkqzikOBCz JAssDxuS4oPyP6nkhxjZnpbXXsMmofZgrTQa9XTPSHNHR3RHmn9ZqCmJNVVzOqZr2t6tDZU1GarL 4fo56SClhbUJWxtDRq2z2/4wr8r57f3D6RVVCz7JnmJ/Jmk+5ZK2D5Ymozc3DZCV5SRM1KqBxRql QZ4lFEc5pXFORRjwPwe6AaQDXWhTpDpnpKGOitCkqjdpoTYR3HF8Fs6WEb9JpK1DPndnxnPtKn9D nQVFXISUFGrGqPeTgKOg2Tl9Jm/Xpy0+iLwHGVTVXIbXMrj3LRryqPt+uvcZFE+cDi3gpvbphGbv aG/G9LTRMyIbt41/NWr2leosj6OQj8mSNE9DG77RRc4MNDKOY278dMG2ymxFnAuMKjKDOL2fPs0u WiitKdO4QuB6Z1G8zhuz9lHC3u8IAY2JrBQyyAcDBRZ/H/tkcksjGP8ixsL0oUwsZABRLhe+arXD 1Fcx+iP7b2UGwuCIK1nqXCuv/iZTAHQmM+LQZUcJI5wveXIlyB77WfCiyhOSKJsNNtX5G0fMV1rQ aiJ7vzYUWHFp9LylSZCNvbHAs05XEAL6ayHiTGK8EYpKcLycpka2Dx0qD1RjcwWj75iDlTg676BW wLGkrjr/NU1d4UIyLtG1hTkhGXEpNpJ1JWmMhmSquXv+qybH7lrNjDG9YqolHafJA8FdCrvilL0/ RF3QK8SjtFBI0L+rQ+WJOEAATOIFK07iUTnVvlojydRdOSVJL++bKjLx8D3YuIzsC9Nz15TR2B1r 8r5LToQErh6FACG6l+y42PC8YJvsgnB1DdZBJWq0pV950A62ADSqJ3iGiZy5M5eSh82FZAdmsItz 4FnRuKJ6D9zGouUZCql9xFk0tfHjNhJt6E6xaG8lKNAPQvF4gGsMELjQ9SBsYQUkuVyvahwCjTFA jiAhluOiA4BnLl3YsNonSroSXG5/W0mDyy0Ms9dsOMbuWJNMNBF2pWzAaXmJKGWNZWvbNPcyPdfd reO96w67KlGuU4GochiAyJ2HCeCy7EtP+HLPN1USQ/bT/FXZH7lj9g+G15gEjdBcWzS44d0bsPJA c8px3+dS1o1GxOLyCjo1MVGh3xtmBUxkweGTO3ENdBztWjvZLwGjIcJ2zjGIunlTrcPBNcYs78qF AfRoYPYEx6HUAbILoC/FZr9Rq3frV0tcMhyHQ3v0BDX33FYKZW5kc3RyZWFtCmVuZG9iagoxOTgg MCBvYmoKOTIyCmVuZG9iagoxOTYgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAxODkgMCBS IC9SZXNvdXJjZXMgMTk5IDAgUiAvQ29udGVudHMgMTk3IDAgUiAvTWVkaWFCb3gKWzAgMCA3MjAg NTQwXSA+PgplbmRvYmoKMTk5IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCAvSW1hZ2VC IC9JbWFnZUMgL0ltYWdlSSBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAwIFIKL0NzMiA4IDAgUiA+ PiAvRm9udCA8PCAvRjUuMCAxMyAwIFIgPj4gL1hPYmplY3QgPDwgL0ltMTcgMjAwIDAgUiA+PiA+ PgplbmRvYmoKMjAwIDAgb2JqCjw8IC9MZW5ndGggMjAxIDAgUiAvVHlwZSAvWE9iamVjdCAvU3Vi dHlwZSAvSW1hZ2UgL1dpZHRoIDcyMCAvSGVpZ2h0IDE1IC9JbnRlcnBvbGF0ZQp0cnVlIC9Db2xv clNwYWNlIDU4IDAgUiAvSW50ZW50IC9QZXJjZXB0dWFsIC9CaXRzUGVyQ29tcG9uZW50IDggL0Zp bHRlciAvRENURGVjb2RlCj4+CnN0cmVhbQr/2P/gABBKRklGAAEBAAABAAEAAP/iBUBJQ0NfUFJP RklMRQABAQAABTBhcHBsAiAAAG1udHJSR0IgWFlaIAfZAAIAGQALABoAC2Fjc3BBUFBMAAAAAGFw cGwAAAAAAAAAAAAAAAAAAAAAAAD21gABAAAAANMtYXBwbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC2RzY20AAAEIAAAC8mRlc2MAAAP8AAAAb2dYWVoAAARs AAAAFHd0cHQAAASAAAAAFHJYWVoAAASUAAAAFGJYWVoAAASoAAAAFHJUUkMAAAS8AAAADmNwcnQA AATMAAAAOGNoYWQAAAUEAAAALGdUUkMAAAS8AAAADmJUUkMAAAS8AAAADm1sdWMAAAAAAAAAEQAA AAxlblVTAAAAJgAAAn5lc0VTAAAAJgAAAYJkYURLAAAALgAAAepkZURFAAAALAAAAahmaUZJAAAA KAAAANxmckZVAAAAKAAAASppdElUAAAAKAAAAlZubE5MAAAAKAAAAhhuYk5PAAAAJgAAAQRwdEJS AAAAJgAAAYJzdlNFAAAAJgAAAQRqYUpQAAAAGgAAAVJrb0tSAAAAFgAAAkB6aFRXAAAAFgAAAWx6 aENOAAAAFgAAAdRydVJVAAAAIgAAAqRwbFBMAAAALAAAAsYAWQBsAGUAaQBuAGUAbgAgAFIARwBC AC0AcAByAG8AZgBpAGkAbABpAEcAZQBuAGUAcgBpAHMAawAgAFIARwBCAC0AcAByAG8AZgBpAGwA UAByAG8AZgBpAGwAIABHAOkAbgDpAHIAaQBxAHUAZQAgAFIAVgBCTgCCLAAgAFIARwBCACAw1zDt MNUwoTCkMOuQGnUoACAAUgBHAEIAIIJyX2ljz4/wAFAAZQByAGYAaQBsACAAUgBHAEIAIABHAGUA bgDpAHIAaQBjAG8AQQBsAGwAZwBlAG0AZQBpAG4AZQBzACAAUgBHAEIALQBQAHIAbwBmAGkAbGZu kBoAIABSAEcAQgAgY8+P8GWHTvYARwBlAG4AZQByAGUAbAAgAFIARwBCAC0AYgBlAHMAawByAGkA dgBlAGwAcwBlAEEAbABnAGUAbQBlAGUAbgAgAFIARwBCAC0AcAByAG8AZgBpAGUAbMd8vBgAIABS AEcAQgAg1QS4XNMMx3wAUAByAG8AZgBpAGwAbwAgAFIARwBCACAARwBlAG4AZQByAGkAYwBvAEcA ZQBuAGUAcgBpAGMAIABSAEcAQgAgAFAAcgBvAGYAaQBsAGUEHgQxBEkEOAQ5ACAEPwRABD4ERAQ4 BDsETAAgAFIARwBCAFUAbgBpAHcAZQByAHMAYQBsAG4AeQAgAHAAcgBvAGYAaQBsACAAUgBHAEIA AGRlc2MAAAAAAAAAFEdlbmVyaWMgUkdCIFByb2ZpbGUAAAAAAAAAAAAAABRHZW5lcmljIFJHQiBQ cm9maWxlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABY WVogAAAAAAAAWnUAAKxzAAAXNFhZWiAAAAAAAADzUgABAAAAARbPWFlaIAAAAAAAAHRNAAA97gAA A9BYWVogAAAAAAAAKBoAABWfAAC4NmN1cnYAAAAAAAAAAQHNAAB0ZXh0AAAAAENvcHlyaWdodCAy MDA3IEFwcGxlIEluYy4sIGFsbCByaWdodHMgcmVzZXJ2ZWQuAHNmMzIAAAAAAAEMQgAABd7///Mm AAAHkgAA/ZH///ui///9owAAA9wAAMBs/+EAQEV4aWYAAE1NACoAAAAIAAGHaQAEAAAAAQAAABoA AAAAAAKgAgAEAAAAAQAAAtCgAwAEAAAAAQAAAA8AAAAA/9sAQwADAgICAgIDAgICAwMDAwQHBAQE BAQIBgYFBwoJCgoKCQkJCwwPDQsLDwwJCQ0SDg8QEBEREQoNExQTERQPERER/9sAQwEDAwMEBAQI BAQIEQsJCxERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERER /8AAEQgADwLQAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYHCAkKC//EALUQ AAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGhCCNCscEVUtHwJDNicoIJChYX GBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqS k5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2drh4uPk5ebn6Onq8fLz 9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkKC//EALURAAIBAgQEAwQHBQQE AAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJicoKSo1 Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKj pKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/aAAwD AQACEQMRAD8A+BKKKK88/PwooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKAP/ZCmVuZHN0cmVhbQplbmRvYmoKMjAxIDAgb2JqCjIyMjEK ZW5kb2JqCjIwNCAwIG9iago8PCAvTGVuZ3RoIDIwNSAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUg Pj4Kc3RyZWFtCngBrVfLctw2ELzjK6bKF/CwFN+Pqx27yq5KVZRsKoc4B4dexfJ6ZYuUX/mf/E8+ KUMS3cQSWsmluHQgRAwaw+6eAfZazuVaEv2rs0TKIpF+J7/JlZw9GVLpBkll6NbzF5LElVyOMdkc k0pqbos7+2nXd7sPNx9fvZP+Uncadxn/0nJ6dAc5e35IG/nh/ZTI0XSZleY4YMw1r+KmLqXIG6mK Rtos1v+WpKeEkjhpk7StkkYzzZK8zdLKeC/HVKcvuNbvG9PZpMAt82QE1H0fb/XdPKvPKo3LpmhL KVuz1ayflbF+hWwv5Hex20jyOs7F9peRbHRLsZ84eoVX7zCQaExL7E2kSemTod1+h5gbFzMg+KXt 3mPyE8N6jl5HZt4ZC4h6hWWYecxFjHmLGPfGWK76C1Mvo0j+kO0LebpVsWYtlJ9RhVGNQIMqqZsi z/Qb67JqqmwUI03aRvWYTBUqMOE46mefbHJ1pnKUK9UH47Fu/4lk+3ZOZQ5VUY/k9MBU+iTJZNuJ wk166zMvJtxZzQpq2kdFuiCfAvRgGoUp81oNlIbGAOO/gsMPGLzGgPaA4k4cY7GYvqFa1Ga/eQMc akpAbrGDNXpALra5cD7DDLKg1zDx87yRsc/ciifYucSgxaDxBotjtORmR6gPnCPUG54jvoHt0QvK 9XEFzl4wky3/hxeAq14wU2WrF7KHeQFQ2iRmKG0SIBL8hWpSuVDxvwNXQKjQANgoRPF8Q098ARAN xKiBKdINyxx2mZcbyxBMePZzPRFeIyzRdG/6RD0R+OS4c5zyydhh9G+jzyJXo6RpsipJ+++i571O 8eCqMq5vgVNVfyFtLG3K2HMUcCyu9Q+hSD5vJEUJuIOU8ew9RYrXqsbiScvbq8d1UjOycgfa6U5K YLRSo+WTL3R/Q35spcTCIWu8+vmRTlu6GDxHMb6Q+gN1cVQbyygerr4R51OUMb4c85S+cbqY87t1 uYvJtS7t+vj4TidcCmDoIvZRWT9QF2BBl/HyA+55HnztQlN31INzKAG+CNvCfiDVet94cAl4hTz1 hUy5X50gfl+4rwY8uKkvhHDKimPD2PDzaC26Du2BfqRnSVuvzdhd8LiMNzNIAJx7zwSz3DmJtt+g Py8FduD+gMZWg9vDa/wfcerzk1k7WPUnQsiBzizFdKpHBIxXeplbX8KZ6mcQxTdho8DnkCnGYmZO 2dgzd92J3fNz8An8XA42e7JKLpkVp4C83OvDPJe5NbvGBuyGBbRUIpdzlSfB/DOEFCyaTLd87yeS d6cONGmL1RVdq4CMhKnt4QkQTqbAPNcgYmDKxFXLfv8zMs/Llb2OevF9/eH0GUlg9GI9I+vkYb2Y WOjF/hl57sxK1clc/xW8D6B1+dHqrGls0FnQGqgJFQDKsgM2cE7zztsAhbVAXMDxBW1xFZlF6vP/ AAviV10KZW5kc3RyZWFtCmVuZG9iagoyMDUgMCBvYmoKMTA3OAplbmRvYmoKMjAzIDAgb2JqCjw8 IC9UeXBlIC9QYWdlIC9QYXJlbnQgMTg5IDAgUiAvUmVzb3VyY2VzIDIwNiAwIFIgL0NvbnRlbnRz IDIwNCAwIFIgL01lZGlhQm94ClswIDAgNzIwIDU0MF0gPj4KZW5kb2JqCjIwNiAwIG9iago8PCAv UHJvY1NldCBbIC9QREYgL1RleHQgL0ltYWdlQiAvSW1hZ2VDIC9JbWFnZUkgXSAvQ29sb3JTcGFj ZSA8PCAvQ3MxIDcgMCBSCi9DczIgOCAwIFIgPj4gL0ZvbnQgPDwgL0Y2LjAgMTQgMCBSIC9GNS4w IDEzIDAgUiA+PiAvWE9iamVjdCA8PCAvSW0xOCAyMDcgMCBSCj4+ID4+CmVuZG9iagoyMDcgMCBv YmoKPDwgL0xlbmd0aCAyMDggMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lk dGggNzIwIC9IZWlnaHQgMTUgL0ludGVycG9sYXRlCnRydWUgL0NvbG9yU3BhY2UgNTggMCBSIC9J bnRlbnQgL1BlcmNlcHR1YWwgL0JpdHNQZXJDb21wb25lbnQgOCAvRmlsdGVyIC9EQ1REZWNvZGUK Pj4Kc3RyZWFtCv/Y/+AAEEpGSUYAAQEAAAEAAQAA/+IFQElDQ19QUk9GSUxFAAEBAAAFMGFwcGwC IAAAbW50clJHQiBYWVogB9kAAgAZAAsAGgALYWNzcEFQUEwAAAAAYXBwbAAAAAAAAAAAAAAAAAAA AAAAAPbWAAEAAAAA0y1hcHBsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAALZHNjbQAAAQgAAALyZGVzYwAAA/wAAABvZ1hZWgAABGwAAAAUd3RwdAAABIAAAAAU clhZWgAABJQAAAAUYlhZWgAABKgAAAAUclRSQwAABLwAAAAOY3BydAAABMwAAAA4Y2hhZAAABQQA AAAsZ1RSQwAABLwAAAAOYlRSQwAABLwAAAAObWx1YwAAAAAAAAARAAAADGVuVVMAAAAmAAACfmVz RVMAAAAmAAABgmRhREsAAAAuAAAB6mRlREUAAAAsAAABqGZpRkkAAAAoAAAA3GZyRlUAAAAoAAAB Kml0SVQAAAAoAAACVm5sTkwAAAAoAAACGG5iTk8AAAAmAAABBHB0QlIAAAAmAAABgnN2U0UAAAAm AAABBGphSlAAAAAaAAABUmtvS1IAAAAWAAACQHpoVFcAAAAWAAABbHpoQ04AAAAWAAAB1HJ1UlUA AAAiAAACpHBsUEwAAAAsAAACxgBZAGwAZQBpAG4AZQBuACAAUgBHAEIALQBwAHIAbwBmAGkAaQBs AGkARwBlAG4AZQByAGkAcwBrACAAUgBHAEIALQBwAHIAbwBmAGkAbABQAHIAbwBmAGkAbAAgAEcA 6QBuAOkAcgBpAHEAdQBlACAAUgBWAEJOAIIsACAAUgBHAEIAIDDXMO0w1TChMKQw65AadSgAIABS AEcAQgAggnJfaWPPj/AAUABlAHIAZgBpAGwAIABSAEcAQgAgAEcAZQBuAOkAcgBpAGMAbwBBAGwA bABnAGUAbQBlAGkAbgBlAHMAIABSAEcAQgAtAFAAcgBvAGYAaQBsZm6QGgAgAFIARwBCACBjz4/w ZYdO9gBHAGUAbgBlAHIAZQBsACAAUgBHAEIALQBiAGUAcwBrAHIAaQB2AGUAbABzAGUAQQBsAGcA ZQBtAGUAZQBuACAAUgBHAEIALQBwAHIAbwBmAGkAZQBsx3y8GAAgAFIARwBCACDVBLhc0wzHfABQ AHIAbwBmAGkAbABvACAAUgBHAEIAIABHAGUAbgBlAHIAaQBjAG8ARwBlAG4AZQByAGkAYwAgAFIA RwBCACAAUAByAG8AZgBpAGwAZQQeBDEESQQ4BDkAIAQ/BEAEPgREBDgEOwRMACAAUgBHAEIAVQBu AGkAdwBlAHIAcwBhAGwAbgB5ACAAcAByAG8AZgBpAGwAIABSAEcAQgAAZGVzYwAAAAAAAAAUR2Vu ZXJpYyBSR0IgUHJvZmlsZQAAAAAAAAAAAAAAFEdlbmVyaWMgUkdCIFByb2ZpbGUAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFhZWiAAAAAAAABadQAArHMA ABc0WFlaIAAAAAAAAPNSAAEAAAABFs9YWVogAAAAAAAAdE0AAD3uAAAD0FhZWiAAAAAAAAAoGgAA FZ8AALg2Y3VydgAAAAAAAAABAc0AAHRleHQAAAAAQ29weXJpZ2h0IDIwMDcgQXBwbGUgSW5jLiwg YWxsIHJpZ2h0cyByZXNlcnZlZC4Ac2YzMgAAAAAAAQxCAAAF3v//8yYAAAeSAAD9kf//+6L///2j AAAD3AAAwGz/4QBARXhpZgAATU0AKgAAAAgAAYdpAAQAAAABAAAAGgAAAAAAAqACAAQAAAABAAAC 0KADAAQAAAABAAAADwAAAAD/2wBDAAMCAgICAgMCAgIDAwMDBAcEBAQEBAgGBgUHCgkKCgoJCQkL DA8NCwsPDAkJDRIODxAQERERCg0TFBMRFA8RERH/2wBDAQMDAwQEBAgEBAgRCwkLERERERERERER ERERERERERERERERERERERERERERERERERERERERERERERERERERERH/wAARCAAPAtADASIAAhEB AxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9 AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6 Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ip qrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEB AQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJB UQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RV VldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6 wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD4Eooorzz8 /CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooA/9kKZW5kc3RyZWFtCmVuZG9iagoyMDggMCBvYmoKMjIyMQplbmRvYmoKMjExIDAgb2Jq Cjw8IC9MZW5ndGggMjEyIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAHNWUtv GzcQvvNXEOhlfZC83Je0pwJ1EiBt0Zdd9BDkkChS7MayY0lJmvz6zoMzS+7bRg+FD1o+hpyZb570 g/3dPtgU/lZZassitYet/cve2fOLo7Obo3X2uGmv72y6rOwN7sl4j7PO9O07/2172Gw/nj69ubWH G7gJb8E/V9LPZm/PX+5dbZ/dEyPRcpmVJt6AvObVcr0qbZGvbVWsbZ0tYdQwTQyly7ROXV2la+A0 S/M6c5UJJpFVkuAB5EN2Fk7OLfMUD4R7f7iCTWmaZvZqA6u8D37L9XJdurK0ZW2ugP8X1RLksVc7 m3xXZGf26m/7/IqkGT07ONG59bJ2cLI/sJQDX9nEnqEINnnhf2/O7IIm7uTjjXzcyoffY5Jv3d3v ZZMcfPIHX8vCVj5kx+2Z4Su7p31Y6O5/5CCdUQ6PSngvRzVrZ/a1vfqRVTZgi7G1pcuSsQVE/Reo SL4AWlevlmAgaUqGsrfVaumyZuJWJvIVKLK0t0xgdHhtszI+wdXr4EQkwLES8HYdXpvC5cH+PZwX 0/NYCXi7Dq9thTaGRs4ymL0tXBGceOvHSiIEOtE5w+7tzmYgr/kClux99+KSrDq1lxfgWWquVQU3 gyPtwSILm62QDOhxkKcZcXZrr+2lQbyGqCCUCL1jNQNF7BbRPSZLV+h5niivAZhxCutW5TJvSNIK 6YHKjN1jXUaw8z1uVdARg3dhBELB1ytvTThwrp4jks0pOPkDKG6ZwYtE3Y6MlWly5yUizTn7patv 5C+HOKgo4SBCaUjnREUoMT2iNM4e7ROUaDCGknDWoMT0gtKwNeA+RQkGZhIlVB5SKUp0xARKwqCg RAdwdhlFic72KOE3oTSuOVdnDUI4mEQImSMqQojpp/2I9glCNMjrac4ahJh+HCHhTBFColkI4UZF CAZmjh8hkSBEB0wgpOx5hIg+8qPemOXyECEYeIQmtIdUjBDRjyNErOE+RQgHYz6Edo2cBQgRPSI0 zVmDEB0xI9LhXQ1CSDXhQ8KgIoQHzIh0JJQgBDRxpKOEMxDs0saRUgFpPFUABUGElALQcIqAXQIP fE6BA5UfJyHI0Ug57jqoLaCQBITEM0BJG0iAYgYgoBefeIBU3WVMZEk6QDntKgvabfK0oGRdEow4 kqjZm6hQdqYkGHzaJmKDuHDqHk4KQpvXUAhheuR7ASEYy80PpqccEUqA1dcxnpQnlLZdyqC7elrE CQuy5l6ZGaQO5EXMwF8DYppouG7fHNCCN0qJw1zzxLjze67BCiKBeSwci5ONqIxLOL43VXax6vM1 ta83HTRNyCX8VFBEtLsxKjKhMA8Db1yTg6ah3fK94QJ+ASqbZa3+Ctqh5/9Id3IK+wzqiI6yBO0G Tdz7X2g2Xpuwx4jq97L2fHe6yB6+o04ADSTqEjsC2FaD+NP2a9Mgoh6jTgCbyvkqjJsKZgX6tHRV FNixdnjpKvMKmFkAbMlH/C1sAiqNmzGB2bENCM5lgT7/CJzzigrmAZhBS+b8Rdj1PhMoFeTj5qBd JLJLAEvLqSuAOK6YBCGP2koPuRcEMGcZ5mPOInjIO8ploFWE5F0vzKJGfDyYrUJvIo/U4J+ioz/k 46X3hsVBlbrzUzohS6RA1vGmYxTci+ZemKzgFDagT4PPK7Hve/opgcKXFfD8gzwdKLOAMVmBPoDs RVTdIk8YJwkFPGESCRFyRhNNDnLITs/dyFR4rjevuAeeFq0oWzEBRANjIaPV4zWS6c3KlTAOPsAu IBMiIUtk9OFI1vkS8nEGVkWXHTv5UD7g1jhw+niQram+kHAANQNG//lhP4fXDAwgw/EAwFdnAg1d 6uuU93CwB3F+gbRr8T/3BwHPPcb9PsbJYts2K+GD+Mb03Jeu2kHgeH1m5DWwCfaiPAz2ffdT1mnf 74PAY/XW1clLbzcaBUwyGAUshtHxKOCFkSDAAs1JDBJEQoU2z62d+NpKXslhu7//DHYaqleMM1th FQJ9Excl3cBk4F2bn6HjwCQHrKkanQWyAeP8RZSkAWMPnPWln8yz1pt+hrhi08sewxTiFmqGrUdu p7dr1vsMl/W0dP18h30QnXySD3Vc9luDxQbbFkQm/lgcxaebXK8WCA/XsUrZgkQoscD5edXTT+kV KhN94AewNSLDa3ucfToheoflFe2REHWCMBYTnTRDyZIEYc0BsqO10ER4NTvY2agoKLanJS3KloOB pMqAAqX5VW8EdOIs5NXTMCc7lEQP6fiIdz8HnV3gvvNDirhvVpH/D/gvCxomlwuBSU1UjU7sUVXQ WjHJQrZ81aq0Ixh7sJfrCWknG5eonXY2p760I2p9Qtrx989td1S3yc3daft+C44RBiO2Rs+OuO18 lMXtQ5DBy+QfdZOZ4/5DzI5YXZVrxgBmwAC7sREqg96E4eoCCdjgxnhRpKDnxv8Xvny3vTvd7G7a KvIGAyyxtfRy4+vqpn0XMwuYGdGL8gKPD8jLzbteq0G1sMmMMdE8YHC6YI38D9OFA3kCm5vXxIrF BortmBmos5UpIPNRbOzG0Z0sSQ6REC81vPY6sqC5RQORhlGh+SxRTLd8z+nA0H+jg0cbLIygXJf6 aMjaO32beko2H9hfvRLeCndHZe/w2ecEk+iq/gt7KIYy64Ne0dNtii/R/zPnvNZI+DLJ/VvALgxd 3ri9/p7gFtVc1SWL+GZvgnzzUw24Eh2MxahWIZDcbb/ErHgzqGt691Uroqe/VtDsbaXEjDJ8FJ3Z Sr0yySXUP1xNfRswDs8RGkcfM1rym6A08tbxGF6S4zdVCHX/bBWiD7SK0evDZ1BvUHT9f5pePTdq KbMfZr2hhQp5urX8C5eThMsKZW5kc3RyZWFtCmVuZG9iagoyMTIgMCBvYmoKMjEzMgplbmRvYmoK MjEwIDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgMTg5IDAgUiAvUmVzb3VyY2VzIDIxMyAw IFIgL0NvbnRlbnRzIDIxMSAwIFIgL01lZGlhQm94ClswIDAgNzIwIDU0MF0gPj4KZW5kb2JqCjIx MyAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgL0ltYWdlQiAvSW1hZ2VDIC9JbWFnZUkg XSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcgMCBSCi9DczIgOCAwIFIgPj4gL0ZvbnQgPDwgL0Y2LjAg MTQgMCBSIC9GNS4wIDEzIDAgUiA+PiAvWE9iamVjdCA8PCAvSW0xOSAyMTQgMCBSCj4+ID4+CmVu ZG9iagoyMTQgMCBvYmoKPDwgL0xlbmd0aCAyMTUgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBl IC9JbWFnZSAvV2lkdGggNzIwIC9IZWlnaHQgMTUgL0ludGVycG9sYXRlCnRydWUgL0NvbG9yU3Bh Y2UgNTggMCBSIC9JbnRlbnQgL1BlcmNlcHR1YWwgL0JpdHNQZXJDb21wb25lbnQgOCAvRmlsdGVy IC9EQ1REZWNvZGUKPj4Kc3RyZWFtCv/Y/+AAEEpGSUYAAQEAAAEAAQAA/+IFQElDQ19QUk9GSUxF AAEBAAAFMGFwcGwCIAAAbW50clJHQiBYWVogB9kAAgAZAAsAGgALYWNzcEFQUEwAAAAAYXBwbAAA AAAAAAAAAAAAAAAAAAAAAPbWAAEAAAAA0y1hcHBsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAALZHNjbQAAAQgAAALyZGVzYwAAA/wAAABvZ1hZWgAABGwAAAAU d3RwdAAABIAAAAAUclhZWgAABJQAAAAUYlhZWgAABKgAAAAUclRSQwAABLwAAAAOY3BydAAABMwA AAA4Y2hhZAAABQQAAAAsZ1RSQwAABLwAAAAOYlRSQwAABLwAAAAObWx1YwAAAAAAAAARAAAADGVu VVMAAAAmAAACfmVzRVMAAAAmAAABgmRhREsAAAAuAAAB6mRlREUAAAAsAAABqGZpRkkAAAAoAAAA 3GZyRlUAAAAoAAABKml0SVQAAAAoAAACVm5sTkwAAAAoAAACGG5iTk8AAAAmAAABBHB0QlIAAAAm AAABgnN2U0UAAAAmAAABBGphSlAAAAAaAAABUmtvS1IAAAAWAAACQHpoVFcAAAAWAAABbHpoQ04A AAAWAAAB1HJ1UlUAAAAiAAACpHBsUEwAAAAsAAACxgBZAGwAZQBpAG4AZQBuACAAUgBHAEIALQBw AHIAbwBmAGkAaQBsAGkARwBlAG4AZQByAGkAcwBrACAAUgBHAEIALQBwAHIAbwBmAGkAbABQAHIA bwBmAGkAbAAgAEcA6QBuAOkAcgBpAHEAdQBlACAAUgBWAEJOAIIsACAAUgBHAEIAIDDXMO0w1TCh MKQw65AadSgAIABSAEcAQgAggnJfaWPPj/AAUABlAHIAZgBpAGwAIABSAEcAQgAgAEcAZQBuAOkA cgBpAGMAbwBBAGwAbABnAGUAbQBlAGkAbgBlAHMAIABSAEcAQgAtAFAAcgBvAGYAaQBsZm6QGgAg AFIARwBCACBjz4/wZYdO9gBHAGUAbgBlAHIAZQBsACAAUgBHAEIALQBiAGUAcwBrAHIAaQB2AGUA bABzAGUAQQBsAGcAZQBtAGUAZQBuACAAUgBHAEIALQBwAHIAbwBmAGkAZQBsx3y8GAAgAFIARwBC ACDVBLhc0wzHfABQAHIAbwBmAGkAbABvACAAUgBHAEIAIABHAGUAbgBlAHIAaQBjAG8ARwBlAG4A ZQByAGkAYwAgAFIARwBCACAAUAByAG8AZgBpAGwAZQQeBDEESQQ4BDkAIAQ/BEAEPgREBDgEOwRM ACAAUgBHAEIAVQBuAGkAdwBlAHIAcwBhAGwAbgB5ACAAcAByAG8AZgBpAGwAIABSAEcAQgAAZGVz YwAAAAAAAAAUR2VuZXJpYyBSR0IgUHJvZmlsZQAAAAAAAAAAAAAAFEdlbmVyaWMgUkdCIFByb2Zp bGUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFhZWiAA AAAAAABadQAArHMAABc0WFlaIAAAAAAAAPNSAAEAAAABFs9YWVogAAAAAAAAdE0AAD3uAAAD0FhZ WiAAAAAAAAAoGgAAFZ8AALg2Y3VydgAAAAAAAAABAc0AAHRleHQAAAAAQ29weXJpZ2h0IDIwMDcg QXBwbGUgSW5jLiwgYWxsIHJpZ2h0cyByZXNlcnZlZC4Ac2YzMgAAAAAAAQxCAAAF3v//8yYAAAeS AAD9kf//+6L///2jAAAD3AAAwGz/4QBARXhpZgAATU0AKgAAAAgAAYdpAAQAAAABAAAAGgAAAAAA AqACAAQAAAABAAAC0KADAAQAAAABAAAADwAAAAD/2wBDAAMCAgICAgMCAgIDAwMDBAcEBAQEBAgG BgUHCgkKCgoJCQkLDA8NCwsPDAkJDRIODxAQERERCg0TFBMRFA8RERH/2wBDAQMDAwQEBAgEBAgR CwkLERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERH/wAAR CAAPAtADASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgED AwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRol JicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWW l5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3 +Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3 AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5 OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaan qKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIR AxEAPwD4Eooorzz8/CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooA/9kKZW5kc3RyZWFtCmVuZG9iagoyMTUgMCBvYmoKMjIyMQplbmRv YmoKMjE4IDAgb2JqCjw8IC9MZW5ndGggMjE5IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+Pgpz dHJlYW0KeAGVVstu2zAQvPMrFuhFPkihJOt1yCFJGyAFCiSIgh6KHFLXTtPGeUgJin5Q/qef1KXE HUqi7brwQbS4Gs7ODpd8pgt6Js2/ItGUzTU1S/pMD3Rw0sa0aCmmdjGdX5GOcrozMUkfE1OsNsUd nC+bxfLp5fXmnpo7XsmsYn5x1j0Wazo4W/O7948dkdF0lmRqHGC4pnlUFhnN05LyeUlVEvE/R7oj pCNd6bjKdclME51WSZyrwUtDtcvgmfMzdMJYcLNUG0Be97jmIK11QvWCZ/s4fiZpEVVFklNWqZr5 n+YR50P1ioJ35XxG9Q/6UHfZ7MQeIlZlpNMiBmImiF8ooJnJgYKrGYXdoLYvTu0zLGd0TfXHftVe IiZrxGGRlCdNrotyniaMWmR5mSdGo1hXJcvU1doXphN7sVasSNqXL+RnwaxSzttIAMLBmxOgD2Wt Ryp3pHp5B2DpfBMap//pRvJuXmzCd/LmoR8oo1FcGpFEm+8S8iiDdYuh/cxJ275K1O1M9SLfypul DFpZHm++yZSUSCLs6ioAd5mRSKQwnVhjBgyANo39KuuDEcM7J3iqW1NPVc+z3saoIasOQVpgr6z6 mLqX5SWpnp8KILRM4BOHJlNXAlL7rralkFAhAPhGZkQYVB2kJeJe6gp5YYKfEuPjrzfV71rJVttX 4KqabBIW2PJQAXj4/sLqntEggXCmGbe3YZO4DI8uT0TbM6stP509uAFubwSmme+RnmkBMbeNHT1A mS6wH1rXA3w4VstmMrAW1JLqHfJgz+SYjtqWnOmG/Av5OU9NdkU5ze7PqMNxfjuyG8DlWVRsgBtm hx0Fl8LIsIl4vZXEMYPYpZjd8418DP8ICCIBYs2nApCS2F9iK7AUWOw/CcULG6qCaVdzTRjdzIMV NERYkkp2EbldBHz5yLUcZrnTILyDBsfgvgZJ4sI3iJI7wPYj0DbjqUE8OOUMQq6zHp13J17s5EMj baBfeDFu2SpAdZvfos8m+9iLBkwBr0mhH8VhguJO0CdxBwYwGw5w+cpyVji2Ty3h8ZVmZ6fauPvM tdG/rCSZV6q30V7e0ql8tK5T+XBcqmNI7Au7sk0aBRI5RY/Dfzh0dFHbu4UlVe47FLdUduj/tTAf jtOWwr2KMSQ1HP0NhJFsYZAGDsGAzzV3zl78BVlLhgUKZW5kc3RyZWFtCmVuZG9iagoyMTkgMCBv YmoKODgxCmVuZG9iagoyMTcgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAxODkgMCBSIC9S ZXNvdXJjZXMgMjIwIDAgUiAvQ29udGVudHMgMjE4IDAgUiAvTWVkaWFCb3gKWzAgMCA3MjAgNTQw XSA+PgplbmRvYmoKMjIwIDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCAvSW1hZ2VCIC9J bWFnZUMgL0ltYWdlSSBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAwIFIKL0NzMiA4IDAgUiA+PiAv Rm9udCA8PCAvRjYuMCAxNCAwIFIgL0Y1LjAgMTMgMCBSID4+IC9YT2JqZWN0IDw8IC9JbTIwIDIy MSAwIFIKPj4gPj4KZW5kb2JqCjIyMSAwIG9iago8PCAvTGVuZ3RoIDIyMiAwIFIgL1R5cGUgL1hP YmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA3MjAgL0hlaWdodCAxNSAvSW50ZXJwb2xhdGUK dHJ1ZSAvQ29sb3JTcGFjZSA1OCAwIFIgL0ludGVudCAvUGVyY2VwdHVhbCAvQml0c1BlckNvbXBv bmVudCA4IC9GaWx0ZXIgL0RDVERlY29kZQo+PgpzdHJlYW0K/9j/4AAQSkZJRgABAQAAAQABAAD/ 4gVASUNDX1BST0ZJTEUAAQEAAAUwYXBwbAIgAABtbnRyUkdCIFhZWiAH2QACABkACwAaAAthY3Nw QVBQTAAAAABhcHBsAAAAAAAAAAAAAAAAAAAAAAAA9tYAAQAAAADTLWFwcGwAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAtkc2NtAAABCAAAAvJkZXNjAAAD/AAA AG9nWFlaAAAEbAAAABR3dHB0AAAEgAAAABRyWFlaAAAElAAAABRiWFlaAAAEqAAAABRyVFJDAAAE vAAAAA5jcHJ0AAAEzAAAADhjaGFkAAAFBAAAACxnVFJDAAAEvAAAAA5iVFJDAAAEvAAAAA5tbHVj AAAAAAAAABEAAAAMZW5VUwAAACYAAAJ+ZXNFUwAAACYAAAGCZGFESwAAAC4AAAHqZGVERQAAACwA AAGoZmlGSQAAACgAAADcZnJGVQAAACgAAAEqaXRJVAAAACgAAAJWbmxOTAAAACgAAAIYbmJOTwAA ACYAAAEEcHRCUgAAACYAAAGCc3ZTRQAAACYAAAEEamFKUAAAABoAAAFSa29LUgAAABYAAAJAemhU VwAAABYAAAFsemhDTgAAABYAAAHUcnVSVQAAACIAAAKkcGxQTAAAACwAAALGAFkAbABlAGkAbgBl AG4AIABSAEcAQgAtAHAAcgBvAGYAaQBpAGwAaQBHAGUAbgBlAHIAaQBzAGsAIABSAEcAQgAtAHAA cgBvAGYAaQBsAFAAcgBvAGYAaQBsACAARwDpAG4A6QByAGkAcQB1AGUAIABSAFYAQk4AgiwAIABS AEcAQgAgMNcw7TDVMKEwpDDrkBp1KAAgAFIARwBCACCCcl9pY8+P8ABQAGUAcgBmAGkAbAAgAFIA RwBCACAARwBlAG4A6QByAGkAYwBvAEEAbABsAGcAZQBtAGUAaQBuAGUAcwAgAFIARwBCAC0AUABy AG8AZgBpAGxmbpAaACAAUgBHAEIAIGPPj/Blh072AEcAZQBuAGUAcgBlAGwAIABSAEcAQgAtAGIA ZQBzAGsAcgBpAHYAZQBsAHMAZQBBAGwAZwBlAG0AZQBlAG4AIABSAEcAQgAtAHAAcgBvAGYAaQBl AGzHfLwYACAAUgBHAEIAINUEuFzTDMd8AFAAcgBvAGYAaQBsAG8AIABSAEcAQgAgAEcAZQBuAGUA cgBpAGMAbwBHAGUAbgBlAHIAaQBjACAAUgBHAEIAIABQAHIAbwBmAGkAbABlBB4EMQRJBDgEOQAg BD8EQAQ+BEQEOAQ7BEwAIABSAEcAQgBVAG4AaQB3AGUAcgBzAGEAbABuAHkAIABwAHIAbwBmAGkA bAAgAFIARwBCAABkZXNjAAAAAAAAABRHZW5lcmljIFJHQiBQcm9maWxlAAAAAAAAAAAAAAAUR2Vu ZXJpYyBSR0IgUHJvZmlsZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAWFlaIAAAAAAAAFp1AACscwAAFzRYWVogAAAAAAAA81IAAQAAAAEWz1hZWiAAAAAA AAB0TQAAPe4AAAPQWFlaIAAAAAAAACgaAAAVnwAAuDZjdXJ2AAAAAAAAAAEBzQAAdGV4dAAAAABD b3B5cmlnaHQgMjAwNyBBcHBsZSBJbmMuLCBhbGwgcmlnaHRzIHJlc2VydmVkLgBzZjMyAAAAAAAB DEIAAAXe///zJgAAB5IAAP2R///7ov///aMAAAPcAADAbP/hAEBFeGlmAABNTQAqAAAACAABh2kA BAAAAAEAAAAaAAAAAAACoAIABAAAAAEAAALQoAMABAAAAAEAAAAPAAAAAP/bAEMAAwICAgICAwIC AgMDAwMEBwQEBAQECAYGBQcKCQoKCgkJCQsMDw0LCw8MCQkNEg4PEBAREREKDRMUExEUDxEREf/b AEMBAwMDBAQECAQECBELCQsRERERERERERERERERERERERERERERERERERERERERERERERERERER EREREREREREREf/AABEIAA8C0AMBIgACEQEDEQH/xAAfAAABBQEBAQEBAQAAAAAAAAAAAQIDBAUG BwgJCgv/xAC1EAACAQMDAgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEUMoGRoQgjQrHBFVLR 8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5 eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj 5OXm5+jp6vHy8/T19vf4+fr/xAAfAQADAQEBAQEBAQEBAAAAAAAAAQIDBAUGBwgJCgv/xAC1EQAC AQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIygQgUQpGhscEJIzNS8BVictEKFiQ04SXx FxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqS k5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2dri4+Tl5ufo6ery8/T1 9vf4+fr/2gAMAwEAAhEDEQA/APgSiiivPPz8KKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigD/2QplbmRzdHJlYW0KZW5kb2JqCjIyMiAw IG9iagoyMjIxCmVuZG9iagoyMjUgMCBvYmoKPDwgL0xlbmd0aCAyMjYgMCBSIC9GaWx0ZXIgL0Zs YXRlRGVjb2RlID4+CnN0cmVhbQp4AaVXTXPbNhC941fsuBdoppH5IVJkL51J0sykp6TVTA5xDwlj N24tJyadtP5B+T/9SV0SeA8UIDmKMz6QJhaL3ffe7kI38lJuJNO/dZFJtcqkP5dXci2nT4ZcukFy Gbp4/UKyZS2Xo03hbHLJzT670xfnfXf+8fbTmyvpL/Wk8ZTxL6+mR7eV0+fbIpenH6ZAdparojK7 BmOsZb1s1pWsykbqVSNtsdT/QtBTQNkya7O8rbNGIy2ysi3y2sw+jqFOGdxofmM4j3L4rcpsdKjn Pt6oUZZlhWw6XXV2+qybZZM35Uqq1mw0/mf1UvORzYXYH5pqIZu/5JfNlM29vmce80JdNkVDjxU8 vhYrizEHsU8W8mh6+YCXa7zcepNzfPjXfTHc/AYr3PMOX+CfH+jlwrv1m439hD1XeMHJcNJzM014 NGwvFyZN5A/Z/Opgcxwr2iO7I8sJt3W2blZlobCsq7qpi0apzbO2UZ4nsabMTn4cpYUnUp9rhVVB nzgE4sZ+CQw6qapYdmSy31m5ir0ZVYTy94KQAAB+6AHbW+DZk1xi/adbM/Y9jOAHu2n6ERZYgeU/ WPDugzC4hQdfwpZSgZchdpt4Yx5MEVvodcsTQ66faf5uYYIStERjppXzGdNH0DJyXNeuTsGxfBfH iTfl+JWvFFKUiD7BwYNpLNDlXoKBPcdXvrG+8kPbIK+oZnj92rnGsoRJHiXxN7w8uOBdC/gZYlN/ RxI/zpmDxK9cly5WWqTKfJ5pXx5bdKD+v1l5m7HAj3NXV8v1HnfK/WYheZ4bS9o6Mkm4CGBHYRBc vtwtZK1NxNgfvZqA8deYEtuRZR7pNs3C+n5lhK7BmJnYgCARNFewQHy2Kn3t2DrSaJN0FkLIXTsC Sfgf7wk6r5X3aZrr0xFWtBH/SliQ7EDY2EL1toLxhEzYPBkU4w5Uw5hL31DfA5PsQyfkbKDHW49a MCcNcW2f2RMEFKRB6fkObOxPXmin0ZOWhAUkEgIi1/v4QiO7OzlbHF3Ne8sPbO6O6ryuIzKP6+Op t2lWp+5UG2y1zLwPcrmGMoAG8b8D2r+Tyg5G5I+Q+RoN5VSgCy49EfwAv4cvZ4Sflc8QWFVMJkgH jhlUkJCrTYRPxukWW39D1M981ASvwkoLxBp84Yt6CQ0/qWd//55d1hxn7Toa5Tv1TD4oYGSxjwR/ C0U6ML3jBSXJ+CTg13+my9AxxqILST3o+mJ2u9g0xQq9694zxaaWt2+KQfhRU0zduSk2tWTSzfTY yCiVWZMi4lwk9JQsPVH3/kr7kEsK3Tu6Qg2FMmVMke1s3jBaFg1G0pbRMkhCAoVAMWGYJwU2xRWk cFDfMTV1FjH92uwb7ijWcC7DTlNDU9EUQ0QPEmc0Yp042yoqSTu/Yh0UJyo8RiBxp+J87htMTAAn M5lmyxs8NMaSR76wrnlp4ReKFhwTVzb/dBNPT3YjYErIm4ZhiXPoAx+oTMbGbGECyc9u6nSDkxl/ qgt1E/SQKPRA8yiLMlao2BPmx1OI0qBN0U2UM8ucGOaW2Wk0eTNeCjee7MdPMTPOFsh4eI+BwoNY Aiz7hIVDv0qNpSnDQGURN8ZME26aFdZu6ISDXqhLcCbh1xXBcJyZcC1mkgzifs4O1FRZ5VGJak0x C+Y1dLjLiU0hYwa4hjLJKP7Q1aFBWvIo8HkFOgkUM+UvTC4xAvojPl5ts187TA9HMSPe1e4Lzyl2 Pu4Ze7+QqhqFGuif1dHL/wHYgS+wCmVuZHN0cmVhbQplbmRvYmoKMjI2IDAgb2JqCjEzMTIKZW5k b2JqCjIyNCAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDE4OSAwIFIgL1Jlc291cmNlcyAy MjcgMCBSIC9Db250ZW50cyAyMjUgMCBSIC9NZWRpYUJveApbMCAwIDcyMCA1NDBdID4+CmVuZG9i agoyMjcgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IC9JbWFnZUIgL0ltYWdlQyAvSW1h Z2VJIF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUgovQ3MyIDggMCBSID4+IC9Gb250IDw8IC9G Ni4wIDE0IDAgUiAvRjUuMCAxMyAwIFIgPj4gL1hPYmplY3QgPDwgL0ltMjEgMjI4IDAgUgo+PiA+ PgplbmRvYmoKMjI4IDAgb2JqCjw8IC9MZW5ndGggMjI5IDAgUiAvVHlwZSAvWE9iamVjdCAvU3Vi dHlwZSAvSW1hZ2UgL1dpZHRoIDcyMCAvSGVpZ2h0IDE1IC9JbnRlcnBvbGF0ZQp0cnVlIC9Db2xv clNwYWNlIDU4IDAgUiAvSW50ZW50IC9QZXJjZXB0dWFsIC9CaXRzUGVyQ29tcG9uZW50IDggL0Zp bHRlciAvRENURGVjb2RlCj4+CnN0cmVhbQr/2P/gABBKRklGAAEBAAABAAEAAP/iBUBJQ0NfUFJP RklMRQABAQAABTBhcHBsAiAAAG1udHJSR0IgWFlaIAfZAAIAGQALABoAC2Fjc3BBUFBMAAAAAGFw cGwAAAAAAAAAAAAAAAAAAAAAAAD21gABAAAAANMtYXBwbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC2RzY20AAAEIAAAC8mRlc2MAAAP8AAAAb2dYWVoAAARs AAAAFHd0cHQAAASAAAAAFHJYWVoAAASUAAAAFGJYWVoAAASoAAAAFHJUUkMAAAS8AAAADmNwcnQA AATMAAAAOGNoYWQAAAUEAAAALGdUUkMAAAS8AAAADmJUUkMAAAS8AAAADm1sdWMAAAAAAAAAEQAA AAxlblVTAAAAJgAAAn5lc0VTAAAAJgAAAYJkYURLAAAALgAAAepkZURFAAAALAAAAahmaUZJAAAA KAAAANxmckZVAAAAKAAAASppdElUAAAAKAAAAlZubE5MAAAAKAAAAhhuYk5PAAAAJgAAAQRwdEJS AAAAJgAAAYJzdlNFAAAAJgAAAQRqYUpQAAAAGgAAAVJrb0tSAAAAFgAAAkB6aFRXAAAAFgAAAWx6 aENOAAAAFgAAAdRydVJVAAAAIgAAAqRwbFBMAAAALAAAAsYAWQBsAGUAaQBuAGUAbgAgAFIARwBC AC0AcAByAG8AZgBpAGkAbABpAEcAZQBuAGUAcgBpAHMAawAgAFIARwBCAC0AcAByAG8AZgBpAGwA UAByAG8AZgBpAGwAIABHAOkAbgDpAHIAaQBxAHUAZQAgAFIAVgBCTgCCLAAgAFIARwBCACAw1zDt MNUwoTCkMOuQGnUoACAAUgBHAEIAIIJyX2ljz4/wAFAAZQByAGYAaQBsACAAUgBHAEIAIABHAGUA bgDpAHIAaQBjAG8AQQBsAGwAZwBlAG0AZQBpAG4AZQBzACAAUgBHAEIALQBQAHIAbwBmAGkAbGZu kBoAIABSAEcAQgAgY8+P8GWHTvYARwBlAG4AZQByAGUAbAAgAFIARwBCAC0AYgBlAHMAawByAGkA dgBlAGwAcwBlAEEAbABnAGUAbQBlAGUAbgAgAFIARwBCAC0AcAByAG8AZgBpAGUAbMd8vBgAIABS AEcAQgAg1QS4XNMMx3wAUAByAG8AZgBpAGwAbwAgAFIARwBCACAARwBlAG4AZQByAGkAYwBvAEcA ZQBuAGUAcgBpAGMAIABSAEcAQgAgAFAAcgBvAGYAaQBsAGUEHgQxBEkEOAQ5ACAEPwRABD4ERAQ4 BDsETAAgAFIARwBCAFUAbgBpAHcAZQByAHMAYQBsAG4AeQAgAHAAcgBvAGYAaQBsACAAUgBHAEIA AGRlc2MAAAAAAAAAFEdlbmVyaWMgUkdCIFByb2ZpbGUAAAAAAAAAAAAAABRHZW5lcmljIFJHQiBQ cm9maWxlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABY WVogAAAAAAAAWnUAAKxzAAAXNFhZWiAAAAAAAADzUgABAAAAARbPWFlaIAAAAAAAAHRNAAA97gAA A9BYWVogAAAAAAAAKBoAABWfAAC4NmN1cnYAAAAAAAAAAQHNAAB0ZXh0AAAAAENvcHlyaWdodCAy MDA3IEFwcGxlIEluYy4sIGFsbCByaWdodHMgcmVzZXJ2ZWQuAHNmMzIAAAAAAAEMQgAABd7///Mm AAAHkgAA/ZH///ui///9owAAA9wAAMBs/+EAQEV4aWYAAE1NACoAAAAIAAGHaQAEAAAAAQAAABoA AAAAAAKgAgAEAAAAAQAAAtCgAwAEAAAAAQAAAA8AAAAA/9sAQwADAgICAgIDAgICAwMDAwQHBAQE BAQIBgYFBwoJCgoKCQkJCwwPDQsLDwwJCQ0SDg8QEBEREQoNExQTERQPERER/9sAQwEDAwMEBAQI BAQIEQsJCxERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERER /8AAEQgADwLQAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYHCAkKC//EALUQ AAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGhCCNCscEVUtHwJDNicoIJChYX GBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqS k5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2drh4uPk5ebn6Onq8fLz 9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkKC//EALURAAIBAgQEAwQHBQQE AAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJicoKSo1 Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKj pKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/aAAwD AQACEQMRAD8A+BKKKK88/PwooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKAP/ZCmVuZHN0cmVhbQplbmRvYmoKMjI5IDAgb2JqCjIyMjEK ZW5kb2JqCjIzMiAwIG9iago8PCAvTGVuZ3RoIDIzMyAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUg Pj4Kc3RyZWFtCngBpVfZbtNAFH2fr7iPjkQcL/ESREGitAIEEqBIPCAeWpPSQNPFbkH9IP4HtT/E HXvOsWOnVUqVB088d+5yzl3GF/JRLiTQXxYFkkwDKRfyWU5lsluFUlQSSlX0948k8FNZWpmokQkl NJvkJh8WZbE4v7w6OJFyqZasFfsLk/pRrGTyZhVF8uqsdmRtO4kSsy5gfY1TP88Smca5pNNcZpGv /1qna4cCP5gF4SwNcvU0CuJZFKam89K6WkdwofFZd8Yh9CZxYBWq3Zdzfdfs6jOL/TyNo0ySmZmr 1/uJr1HI/Ei+iPd6JGM1JN4ZFr+xkJF1QbxL96REs2G8b5BcYHHkRJd4cYoFRaAVoleNhPFK2Dke nClxqKSaEwgdYIHjy5HpRUQnqhcj+Srzt7I3V84aShQmS4YlZUBFGmT5NI4U/yxJ8zSynITBLFda 6twaElHrcQw06TKONUEVxlgRX5kO+N6fkcx/NK40osrtGqublcXTWtuQyvckqAIWwG0XIFHkE97s yUjjU5q3w7afLS22yArmD5OAXHEBvw7hBXnFzgFYpAhddxnTJibOUInv0vB7o954+qLlfQuMLWGZ JaxXLcUZ3GLanSOEp87opPek5MDvYyhjaCUxA4PXCO6GZUFp0lzdgsRnsN6yWVGeDmhjg9fPu8ho Z7k/47eELgwjYmfqTvOoZB+q08b1DhEQMqbiT2BGbshBydVqAfQBNTEpKyhQvl3CUzmkqcjZNx5F cFpNuNODQ2ydVNOKuPYFLZR4QCVAGTOMnqjWB1VC3W3CadprXkrAthn2xNUD4nGu1EVZNx5XpWKr tH4BSURBhvGCfYS6dvpWCPBghzQNdopL1wp3uiCxKNS5jWPgjqIw2vjrAe0GQJhnLIpm/G5dFMYO 9FZbw8lAnXLCrr7voGTjT5pUNN4MOZkPFsCdGUec2x4CGWYWhVk0rBnQxc7FLBwMdOPRFhXiOOmn YlJImxV7W0HP4CoVVo+j1d7olAh7C9DfWJ/TWOdEFNni6A4K7+82k32oLk38bIM65fWG6UwIq6Id FodoZdylPJvGtc6IprwII1m4IUQn0ATwqbEk6BSGDAn6RelbhdrgovW/FdTNeTuRozTt3Xq2rqD6 StyroKE6RXqL+zCxJZANssbj1Yc4AHNCRBQLJjxTl4o5mnCclgD5PSVFvc5mZzBxMLa9m9J3s0rj p0gOlh0PMc0ozKjgssbSmTx6LairyH693HfPDYJecSlHDN4ZMx5vQgSeWALCNuS2mdFHXohUFQ4M KcMOIqIftAoJ13ZN+1XFzqz37aYMifzQEHnCRxKvneWKkMOL9W+af9Ey/skKZW5kc3RyZWFtCmVu ZG9iagoyMzMgMCBvYmoKMTAwMwplbmRvYmoKMjMxIDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJl bnQgMTg5IDAgUiAvUmVzb3VyY2VzIDIzNCAwIFIgL0NvbnRlbnRzIDIzMiAwIFIgL01lZGlhQm94 ClswIDAgNzIwIDU0MF0gPj4KZW5kb2JqCjIzNCAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1Rl eHQgL0ltYWdlQiAvSW1hZ2VDIC9JbWFnZUkgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcgMCBSCi9D czIgOCAwIFIgPj4gL0ZvbnQgPDwgL0Y1LjAgMTMgMCBSID4+IC9YT2JqZWN0IDw8IC9JbTIyIDIz NSAwIFIgPj4gPj4KZW5kb2JqCjIzNSAwIG9iago8PCAvTGVuZ3RoIDIzNiAwIFIgL1R5cGUgL1hP YmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA3MjAgL0hlaWdodCAxNSAvSW50ZXJwb2xhdGUK dHJ1ZSAvQ29sb3JTcGFjZSA1OCAwIFIgL0ludGVudCAvUGVyY2VwdHVhbCAvQml0c1BlckNvbXBv bmVudCA4IC9GaWx0ZXIgL0RDVERlY29kZQo+PgpzdHJlYW0K/9j/4AAQSkZJRgABAQAAAQABAAD/ 4gVASUNDX1BST0ZJTEUAAQEAAAUwYXBwbAIgAABtbnRyUkdCIFhZWiAH2QACABkACwAaAAthY3Nw QVBQTAAAAABhcHBsAAAAAAAAAAAAAAAAAAAAAAAA9tYAAQAAAADTLWFwcGwAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAtkc2NtAAABCAAAAvJkZXNjAAAD/AAA AG9nWFlaAAAEbAAAABR3dHB0AAAEgAAAABRyWFlaAAAElAAAABRiWFlaAAAEqAAAABRyVFJDAAAE vAAAAA5jcHJ0AAAEzAAAADhjaGFkAAAFBAAAACxnVFJDAAAEvAAAAA5iVFJDAAAEvAAAAA5tbHVj AAAAAAAAABEAAAAMZW5VUwAAACYAAAJ+ZXNFUwAAACYAAAGCZGFESwAAAC4AAAHqZGVERQAAACwA AAGoZmlGSQAAACgAAADcZnJGVQAAACgAAAEqaXRJVAAAACgAAAJWbmxOTAAAACgAAAIYbmJOTwAA ACYAAAEEcHRCUgAAACYAAAGCc3ZTRQAAACYAAAEEamFKUAAAABoAAAFSa29LUgAAABYAAAJAemhU VwAAABYAAAFsemhDTgAAABYAAAHUcnVSVQAAACIAAAKkcGxQTAAAACwAAALGAFkAbABlAGkAbgBl AG4AIABSAEcAQgAtAHAAcgBvAGYAaQBpAGwAaQBHAGUAbgBlAHIAaQBzAGsAIABSAEcAQgAtAHAA cgBvAGYAaQBsAFAAcgBvAGYAaQBsACAARwDpAG4A6QByAGkAcQB1AGUAIABSAFYAQk4AgiwAIABS AEcAQgAgMNcw7TDVMKEwpDDrkBp1KAAgAFIARwBCACCCcl9pY8+P8ABQAGUAcgBmAGkAbAAgAFIA RwBCACAARwBlAG4A6QByAGkAYwBvAEEAbABsAGcAZQBtAGUAaQBuAGUAcwAgAFIARwBCAC0AUABy AG8AZgBpAGxmbpAaACAAUgBHAEIAIGPPj/Blh072AEcAZQBuAGUAcgBlAGwAIABSAEcAQgAtAGIA ZQBzAGsAcgBpAHYAZQBsAHMAZQBBAGwAZwBlAG0AZQBlAG4AIABSAEcAQgAtAHAAcgBvAGYAaQBl AGzHfLwYACAAUgBHAEIAINUEuFzTDMd8AFAAcgBvAGYAaQBsAG8AIABSAEcAQgAgAEcAZQBuAGUA cgBpAGMAbwBHAGUAbgBlAHIAaQBjACAAUgBHAEIAIABQAHIAbwBmAGkAbABlBB4EMQRJBDgEOQAg BD8EQAQ+BEQEOAQ7BEwAIABSAEcAQgBVAG4AaQB3AGUAcgBzAGEAbABuAHkAIABwAHIAbwBmAGkA bAAgAFIARwBCAABkZXNjAAAAAAAAABRHZW5lcmljIFJHQiBQcm9maWxlAAAAAAAAAAAAAAAUR2Vu ZXJpYyBSR0IgUHJvZmlsZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAWFlaIAAAAAAAAFp1AACscwAAFzRYWVogAAAAAAAA81IAAQAAAAEWz1hZWiAAAAAA AAB0TQAAPe4AAAPQWFlaIAAAAAAAACgaAAAVnwAAuDZjdXJ2AAAAAAAAAAEBzQAAdGV4dAAAAABD b3B5cmlnaHQgMjAwNyBBcHBsZSBJbmMuLCBhbGwgcmlnaHRzIHJlc2VydmVkLgBzZjMyAAAAAAAB DEIAAAXe///zJgAAB5IAAP2R///7ov///aMAAAPcAADAbP/hAEBFeGlmAABNTQAqAAAACAABh2kA BAAAAAEAAAAaAAAAAAACoAIABAAAAAEAAALQoAMABAAAAAEAAAAPAAAAAP/bAEMAAwICAgICAwIC AgMDAwMEBwQEBAQECAYGBQcKCQoKCgkJCQsMDw0LCw8MCQkNEg4PEBAREREKDRMUExEUDxEREf/b AEMBAwMDBAQECAQECBELCQsRERERERERERERERERERERERERERERERERERERERERERERERERERER EREREREREREREf/AABEIAA8C0AMBIgACEQEDEQH/xAAfAAABBQEBAQEBAQAAAAAAAAAAAQIDBAUG BwgJCgv/xAC1EAACAQMDAgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEUMoGRoQgjQrHBFVLR 8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5 eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj 5OXm5+jp6vHy8/T19vf4+fr/xAAfAQADAQEBAQEBAQEBAAAAAAAAAQIDBAUGBwgJCgv/xAC1EQAC AQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIygQgUQpGhscEJIzNS8BVictEKFiQ04SXx FxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqS k5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2dri4+Tl5ufo6ery8/T1 9vf4+fr/2gAMAwEAAhEDEQA/APgSiiivPPz8KKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigD/2QplbmRzdHJlYW0KZW5kb2JqCjIzNiAw IG9iagoyMjIxCmVuZG9iagoyMzkgMCBvYmoKPDwgL0xlbmd0aCAyNDAgMCBSIC9GaWx0ZXIgL0Zs YXRlRGVjb2RlID4+CnN0cmVhbQp4AZVUS2+cMBC++1eM9gRSF2zeNEkr9d2eEmmlHqoetpQ027CQ YFb5Rf1DzR/qGJiBAJsm2oO9eDyP7+FbuIBbkPiLPQlhIKHO4SuU4L7VCjINCnQ2Pb8E6USwMzFe F6NAiaU49zyvs/ymOWwLqHdYyVQxPxW2S7YH9/Pe8+Fd1Tby4Dj0QvEwwPTqR04ShxD4CURBAqnn 4L+h6bYh6chUqjSSCXbqST/1VCRGH02r7QS3OJ9pZ60ob+hLkxDrvtngt+4U19h3ksj3YghTscGu P4QOTgGbS/gG1icb1lgIrIo2d7QB27QAVtOvHNEdCOsnRea0uexDd/ShpA2HUFYKPXQRwqqpztXs Tk2Xak5TUNCWNnR9Z4vJRNyEfm3Dd9h8gfcb5KyjBGEyZBhSZlREMk4C30P84zBKIs9womSaIC2t tuZEtHl6Bjq5rH0UKMLoI+J7MQLf+mPD5nfXSheK3D5gdTmZH7TZ5lQyJHP0r9cEN5NY70fI4YRI 9FoSloo2BDzHat0TBtaeydAU1thdpjmFFMGJmJSMg4fezv7egy0Gqp4KSxQiyBOF33SzCItL17wb RiD18EysOfYDt3cghTHi7AQa8wcByPnohOHT/dHIRy/H8jw2Mz4GUqKYMlC9x3E1CkuDThNKkb+t jyh017nLi2J9XVZ3pZtVxkIku8dLiHkJhW9gC/Coxqmr81JXtXabfH+T19vmUOevTtBNxdnqqtKN Xr2wxdNKLkylgp5TLimsU7egAtuiyety2+SrE9iW2VVVn62WGrofpsb3s/M1urn3Nap25OtjsKCT 2xe3d7TnBRO1oaV50GdbepZO4PN8zvo5LtDBkb9IdbxhjenZ/ZlmB2XOHxBOiLZs34qhKEt93TsN BqdRUba4HktcHAP6qMS90J/pb1njzMPza8TppIYR3P80PtLX4xUXXOWjoKauWpxqqYtBcY/XXbCW H0aTusvWGs128Q/sYhH+CmVuZHN0cmVhbQplbmRvYmoKMjQwIDAgb2JqCjczNgplbmRvYmoKMjM4 IDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgMTg5IDAgUiAvUmVzb3VyY2VzIDI0MSAwIFIg L0NvbnRlbnRzIDIzOSAwIFIgL01lZGlhQm94ClswIDAgNzIwIDU0MF0gPj4KZW5kb2JqCjI0MSAw IG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgL0ltYWdlQiAvSW1hZ2VDIC9JbWFnZUkgXSAv Q29sb3JTcGFjZSA8PCAvQ3MxIDcgMCBSCi9DczIgOCAwIFIgPj4gL0ZvbnQgPDwgL0Y1LjAgMTMg MCBSIC9GMTEuMCAyNDQgMCBSID4+IC9YT2JqZWN0IDw8IC9JbTIzIDI0MiAwIFIKPj4gPj4KZW5k b2JqCjI0MiAwIG9iago8PCAvTGVuZ3RoIDI0MyAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUg L0ltYWdlIC9XaWR0aCA3MjAgL0hlaWdodCAxNSAvSW50ZXJwb2xhdGUKdHJ1ZSAvQ29sb3JTcGFj ZSA1OCAwIFIgL0ludGVudCAvUGVyY2VwdHVhbCAvQml0c1BlckNvbXBvbmVudCA4IC9GaWx0ZXIg L0RDVERlY29kZQo+PgpzdHJlYW0K/9j/4AAQSkZJRgABAQAAAQABAAD/4gVASUNDX1BST0ZJTEUA AQEAAAUwYXBwbAIgAABtbnRyUkdCIFhZWiAH2QACABkACwAaAAthY3NwQVBQTAAAAABhcHBsAAAA AAAAAAAAAAAAAAAAAAAA9tYAAQAAAADTLWFwcGwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAtkc2NtAAABCAAAAvJkZXNjAAAD/AAAAG9nWFlaAAAEbAAAABR3 dHB0AAAEgAAAABRyWFlaAAAElAAAABRiWFlaAAAEqAAAABRyVFJDAAAEvAAAAA5jcHJ0AAAEzAAA ADhjaGFkAAAFBAAAACxnVFJDAAAEvAAAAA5iVFJDAAAEvAAAAA5tbHVjAAAAAAAAABEAAAAMZW5V UwAAACYAAAJ+ZXNFUwAAACYAAAGCZGFESwAAAC4AAAHqZGVERQAAACwAAAGoZmlGSQAAACgAAADc ZnJGVQAAACgAAAEqaXRJVAAAACgAAAJWbmxOTAAAACgAAAIYbmJOTwAAACYAAAEEcHRCUgAAACYA AAGCc3ZTRQAAACYAAAEEamFKUAAAABoAAAFSa29LUgAAABYAAAJAemhUVwAAABYAAAFsemhDTgAA ABYAAAHUcnVSVQAAACIAAAKkcGxQTAAAACwAAALGAFkAbABlAGkAbgBlAG4AIABSAEcAQgAtAHAA cgBvAGYAaQBpAGwAaQBHAGUAbgBlAHIAaQBzAGsAIABSAEcAQgAtAHAAcgBvAGYAaQBsAFAAcgBv AGYAaQBsACAARwDpAG4A6QByAGkAcQB1AGUAIABSAFYAQk4AgiwAIABSAEcAQgAgMNcw7TDVMKEw pDDrkBp1KAAgAFIARwBCACCCcl9pY8+P8ABQAGUAcgBmAGkAbAAgAFIARwBCACAARwBlAG4A6QBy AGkAYwBvAEEAbABsAGcAZQBtAGUAaQBuAGUAcwAgAFIARwBCAC0AUAByAG8AZgBpAGxmbpAaACAA UgBHAEIAIGPPj/Blh072AEcAZQBuAGUAcgBlAGwAIABSAEcAQgAtAGIAZQBzAGsAcgBpAHYAZQBs AHMAZQBBAGwAZwBlAG0AZQBlAG4AIABSAEcAQgAtAHAAcgBvAGYAaQBlAGzHfLwYACAAUgBHAEIA INUEuFzTDMd8AFAAcgBvAGYAaQBsAG8AIABSAEcAQgAgAEcAZQBuAGUAcgBpAGMAbwBHAGUAbgBl AHIAaQBjACAAUgBHAEIAIABQAHIAbwBmAGkAbABlBB4EMQRJBDgEOQAgBD8EQAQ+BEQEOAQ7BEwA IABSAEcAQgBVAG4AaQB3AGUAcgBzAGEAbABuAHkAIABwAHIAbwBmAGkAbAAgAFIARwBCAABkZXNj AAAAAAAAABRHZW5lcmljIFJHQiBQcm9maWxlAAAAAAAAAAAAAAAUR2VuZXJpYyBSR0IgUHJvZmls ZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWFlaIAAA AAAAAFp1AACscwAAFzRYWVogAAAAAAAA81IAAQAAAAEWz1hZWiAAAAAAAAB0TQAAPe4AAAPQWFla IAAAAAAAACgaAAAVnwAAuDZjdXJ2AAAAAAAAAAEBzQAAdGV4dAAAAABDb3B5cmlnaHQgMjAwNyBB cHBsZSBJbmMuLCBhbGwgcmlnaHRzIHJlc2VydmVkLgBzZjMyAAAAAAABDEIAAAXe///zJgAAB5IA AP2R///7ov///aMAAAPcAADAbP/hAEBFeGlmAABNTQAqAAAACAABh2kABAAAAAEAAAAaAAAAAAAC oAIABAAAAAEAAALQoAMABAAAAAEAAAAPAAAAAP/bAEMAAwICAgICAwICAgMDAwMEBwQEBAQECAYG BQcKCQoKCgkJCQsMDw0LCw8MCQkNEg4PEBAREREKDRMUExEUDxEREf/bAEMBAwMDBAQECAQECBEL CQsREREREREREREREREREREREREREREREREREREREREREREREREREREREREREREREREREf/AABEI AA8C0AMBIgACEQEDEQH/xAAfAAABBQEBAQEBAQAAAAAAAAAAAQIDBAUGBwgJCgv/xAC1EAACAQMD AgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEUMoGRoQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUm JygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaX mJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4 +fr/xAAfAQADAQEBAQEBAQEBAAAAAAAAAQIDBAUGBwgJCgv/xAC1EQACAQIEBAMEBwUEBAABAncA AQIDEQQFITEGEkFRB2FxEyIygQgUQpGhscEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3ODk6 Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Slpqeo qaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2dri4+Tl5ufo6ery8/T19vf4+fr/2gAMAwEAAhED EQA/APgSiiivPPz8KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigD/2QplbmRzdHJlYW0KZW5kb2JqCjI0MyAwIG9iagoyMjIxCmVuZG9i agoyNDggMCBvYmoKPDwgL0xlbmd0aCAyNDkgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0 cmVhbQp4AZWUTXObMBCG7/oVe4QDWB+Ij2uTttMeOvWEmRwyPSSM3boOSQzxtH+o/7MriV2DIZlk OCCkl9W+z650gDUcQOJTaAk2k9Bt4BoeYHXRK2h6UNA35+tbkGkOO6fRQaNAiSXd6vumazZPz8fb e+h2uJPbxT3K+lfTwupLqzO4fPSJTJattmIqcLmaPC0LC5kpIc9KqHSKX6ekfUIylZVUVS5LzFRL U2mVi9GkS9U7OKA/l06iKK410gXEfT/UOBdW8a2NTStbVWArUWPWn2yKLqDewg1E32JIcCOINjT4 +xy7rSGC4X1FEyx5CloR9TH8gPorfKyRQbCI2zpzzuTMWi6LMjMawxc2L3PtPCpZlWjT12BuzMcZ HAX8icGCY3oGHUzMRP9iqH9jKmLtrUtX/gml5WAmW4qGaC5iEdDcE5pHGvSMgiARo18kYQVpBQMl 7Y60zZ7VtDYhixU/J4c9MZB7o03HrFhmJnz5At53MJtFQ2ZXR4J2R+ZatkneiBlzZcUD/bRPtr77 RMTMu/aWVilQImlG04BicyQmi32N0EZ9/Yf+YQkP9uO+XqA/7ds3NJmjr5R+qWXx7EjhCvAO/PNw yP/zOTXiQcgYJy1wEZhuT9ogEVHDSyzGwengvwpo0ZK7HN0lNT3SyprXAPlTvQRoHs2f6Xk4BHQ9 XGoB1OmS+xmaYdRvc9OEjPjMWPZHaqk7OgYvd/+86Sn+JUUZ+hErwJ3Z8rniqW5ci/V/MaJxhQpl bmRzdHJlYW0KZW5kb2JqCjI0OSAwIG9iago1NjMKZW5kb2JqCjI0NiAwIG9iago8PCAvVHlwZSAv UGFnZSAvUGFyZW50IDI0NyAwIFIgL1Jlc291cmNlcyAyNTAgMCBSIC9Db250ZW50cyAyNDggMCBS IC9NZWRpYUJveApbMCAwIDcyMCA1NDBdID4+CmVuZG9iagoyNTAgMCBvYmoKPDwgL1Byb2NTZXQg WyAvUERGIC9UZXh0IC9JbWFnZUIgL0ltYWdlQyAvSW1hZ2VJIF0gL0NvbG9yU3BhY2UgPDwgL0Nz MSA3IDAgUgovQ3MyIDggMCBSID4+IC9Gb250IDw8IC9GNS4wIDEzIDAgUiA+PiAvWE9iamVjdCA8 PCAvSW0yNCAyNTEgMCBSID4+ID4+CmVuZG9iagoyNTEgMCBvYmoKPDwgL0xlbmd0aCAyNTIgMCBS IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNzIwIC9IZWlnaHQgMTUgL0lu dGVycG9sYXRlCnRydWUgL0NvbG9yU3BhY2UgNTggMCBSIC9JbnRlbnQgL1BlcmNlcHR1YWwgL0Jp dHNQZXJDb21wb25lbnQgOCAvRmlsdGVyIC9EQ1REZWNvZGUKPj4Kc3RyZWFtCv/Y/+AAEEpGSUYA AQEAAAEAAQAA/+IFQElDQ19QUk9GSUxFAAEBAAAFMGFwcGwCIAAAbW50clJHQiBYWVogB9kAAgAZ AAsAGgALYWNzcEFQUEwAAAAAYXBwbAAAAAAAAAAAAAAAAAAAAAAAAPbWAAEAAAAA0y1hcHBsAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALZHNjbQAAAQgAAALy ZGVzYwAAA/wAAABvZ1hZWgAABGwAAAAUd3RwdAAABIAAAAAUclhZWgAABJQAAAAUYlhZWgAABKgA AAAUclRSQwAABLwAAAAOY3BydAAABMwAAAA4Y2hhZAAABQQAAAAsZ1RSQwAABLwAAAAOYlRSQwAA BLwAAAAObWx1YwAAAAAAAAARAAAADGVuVVMAAAAmAAACfmVzRVMAAAAmAAABgmRhREsAAAAuAAAB 6mRlREUAAAAsAAABqGZpRkkAAAAoAAAA3GZyRlUAAAAoAAABKml0SVQAAAAoAAACVm5sTkwAAAAo AAACGG5iTk8AAAAmAAABBHB0QlIAAAAmAAABgnN2U0UAAAAmAAABBGphSlAAAAAaAAABUmtvS1IA AAAWAAACQHpoVFcAAAAWAAABbHpoQ04AAAAWAAAB1HJ1UlUAAAAiAAACpHBsUEwAAAAsAAACxgBZ AGwAZQBpAG4AZQBuACAAUgBHAEIALQBwAHIAbwBmAGkAaQBsAGkARwBlAG4AZQByAGkAcwBrACAA UgBHAEIALQBwAHIAbwBmAGkAbABQAHIAbwBmAGkAbAAgAEcA6QBuAOkAcgBpAHEAdQBlACAAUgBW AEJOAIIsACAAUgBHAEIAIDDXMO0w1TChMKQw65AadSgAIABSAEcAQgAggnJfaWPPj/AAUABlAHIA ZgBpAGwAIABSAEcAQgAgAEcAZQBuAOkAcgBpAGMAbwBBAGwAbABnAGUAbQBlAGkAbgBlAHMAIABS AEcAQgAtAFAAcgBvAGYAaQBsZm6QGgAgAFIARwBCACBjz4/wZYdO9gBHAGUAbgBlAHIAZQBsACAA UgBHAEIALQBiAGUAcwBrAHIAaQB2AGUAbABzAGUAQQBsAGcAZQBtAGUAZQBuACAAUgBHAEIALQBw AHIAbwBmAGkAZQBsx3y8GAAgAFIARwBCACDVBLhc0wzHfABQAHIAbwBmAGkAbABvACAAUgBHAEIA IABHAGUAbgBlAHIAaQBjAG8ARwBlAG4AZQByAGkAYwAgAFIARwBCACAAUAByAG8AZgBpAGwAZQQe BDEESQQ4BDkAIAQ/BEAEPgREBDgEOwRMACAAUgBHAEIAVQBuAGkAdwBlAHIAcwBhAGwAbgB5ACAA cAByAG8AZgBpAGwAIABSAEcAQgAAZGVzYwAAAAAAAAAUR2VuZXJpYyBSR0IgUHJvZmlsZQAAAAAA AAAAAAAAFEdlbmVyaWMgUkdCIFByb2ZpbGUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAFhZWiAAAAAAAABadQAArHMAABc0WFlaIAAAAAAAAPNSAAEAAAAB Fs9YWVogAAAAAAAAdE0AAD3uAAAD0FhZWiAAAAAAAAAoGgAAFZ8AALg2Y3VydgAAAAAAAAABAc0A AHRleHQAAAAAQ29weXJpZ2h0IDIwMDcgQXBwbGUgSW5jLiwgYWxsIHJpZ2h0cyByZXNlcnZlZC4A c2YzMgAAAAAAAQxCAAAF3v//8yYAAAeSAAD9kf//+6L///2jAAAD3AAAwGz/4QBARXhpZgAATU0A KgAAAAgAAYdpAAQAAAABAAAAGgAAAAAAAqACAAQAAAABAAAC0KADAAQAAAABAAAADwAAAAD/2wBD AAMCAgICAgMCAgIDAwMDBAcEBAQEBAgGBgUHCgkKCgoJCQkLDA8NCwsPDAkJDRIODxAQERERCg0T FBMRFA8RERH/2wBDAQMDAwQEBAgEBAgRCwkLERERERERERERERERERERERERERERERERERERERER ERERERERERERERERERERERERERH/wAARCAAPAtADASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAA AAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKB kaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZn aGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT 1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcI CQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAV YnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6 goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk 5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD4Eooorzz8/CiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA/9kKZW5kc3RyZWFtCmVu ZG9iagoyNTIgMCBvYmoKMjIyMQplbmRvYmoKMjU1IDAgb2JqCjw8IC9MZW5ndGggMjU2IDAgUiAv RmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAGdV8luG0cQvfdX1LEJeEbTPSt5Siw4CZKL AzMQENMHh7EcJqEcW8zymfmkvF5ezXAZRRYkoIu91PLqVXXPR/lePkqFv95X0jaVfHonN3InV9f3 Trb34uR+e7p+K1XZyS7s8WmPE2cu7otH48oOdlz8WThpfPjf7uX5WtyQZwfpSy/emfVerr5yZYX9 61t5LfaXhRRV6cQeDn9QXF1ddZR/p/CBwt8L+OiNfcsJPadCece1dxQOC3kj62/lxTrCou76ppO6 M9nfJvvbSNOUy8rXrbheotN+4vSWWj98is6IVTtfLAy8E7u7g8UYmC5x727/TDw1VBQcBZ0pgiog g5XgTRQSVkVWrVqamejaflm2UlfIhwn5mMSHedel0GqGZmsoWv+aQArswcl6aKTrOnG+ywQyJEfg VhVJFDkzIQHOtS5YDSyou4Qqxt6XbmhaCG0y3ZSVIRWAaoQugOqGACKgizMSJwDFzdec4ea3IEjc k0ZjxQPAi6mec6p2fTlUdT91CqRP/HRVAfzbNrjjCt+s4MtnaW+6oewH76E9sR8hK/uhLKn+MmYf Nt4z5kRhzPzMJRBeLZuYnQBsh/zUQ83iPi/fmCFUv/dDuXSNk64H5V04gGqXysQN0+RhGQpT8nym DMZYwpky3SSIxFx42i4M+AlhlTgMSQVEylReHG8mOQ9KjP0pn0j1A13/EAjqSp1ALPiS7KaWgK0A L1p5H0djSZJdnj9eF/ssz0Nz3Ze12DEfeSV7YVQ10hJNqM2Jjrjw6qBLhz/z5nuUMmrFwk6x9Ajy mq6jDx6ro6saHM6mKBn+JnSGNFUR+c1iQpJpW0bxzSa1zS2OSTXoy6q6pY2VTj06qY5u0eV/qYwT qZMiY2jvMX4NV9POrddUxq2ao5dsD9x6IHiq/jca1jwegKcPqcahokd9RsFPJFeXvdgfs2OvqHxj 0SQT7EMSjH0S7MMJ7OE6VMRG2FXK1qKjESt6dDrmRKEXZt/PYC+IIYtMyaWwayL+YpC6RLX/DzOu dWium3JI8LpuqMo6OlacQ/0dcf2GAi1tbM0pJV/E3Fy40h+iusOTJF7n5HoCPebT2PTqABVWnuY+ F3Rmx9hz0Oe6kJKzuGVeFP09WT82E4LyaPjr8IrAqaJu+jnsL9D8vN6PaG4eeWW4ZjkLuRByY1ea 4adCLoR8JH5BfhN64nveGOZQNVbTowUQSO3Cyyqg6pxjG5lSeuwoqY9o+3pOatHihiDI0/qI65fp ZXGB0wowOK1tSwV6cDyO8L0kbEo+Xpwc2Wj5Gxdu4duySXybqfYRmlEiSLmzzlyHZrzrkYLT61A7 5RFP525Bc/q0wYN1rjWI7Wnu4tsmvfmPYWQnEPuC6PDNwI1k4y0ntmfVzgxg1MffAx928aON7/Jp hfplLUP38KNu+l2GyzV+fMAuYHbxCRUERBX6ThL3FFJlYHHMSqIMptDK4rm8B+z6IV9La7x+JkH9 ByPoy7oKZW5kc3RyZWFtCmVuZG9iagoyNTYgMCBvYmoKMTExNQplbmRvYmoKMjU0IDAgb2JqCjw8 IC9UeXBlIC9QYWdlIC9QYXJlbnQgMjQ3IDAgUiAvUmVzb3VyY2VzIDI1NyAwIFIgL0NvbnRlbnRz IDI1NSAwIFIgL01lZGlhQm94ClswIDAgNzIwIDU0MF0gPj4KZW5kb2JqCjI1NyAwIG9iago8PCAv UHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcgMCBSIC9DczIgOCAw IFIgPj4gL0ZvbnQgPDwKL0Y2LjAgMTQgMCBSIC9GNC4wIDEyIDAgUiAvRjMuMCAxMSAwIFIgL0Yy LjAgMTAgMCBSIC9GMS4wIDkgMCBSID4+ID4+CmVuZG9iagoyNjAgMCBvYmoKPDwgL0xlbmd0aCAy NjEgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AaVWTW/TQBC9768YxGUtEWfX Xq/tnqAoHJA4VLLEgXIooYEASWhjvv49sx9v4rZpVYGaypPd2bcz782Mc0VndEWG/9rKUOMMXV/S W9rS/OXe0nJPlvbL2/srMqWndfCpko8lq476xaNxZ8332Ph1ZslV4bPc0OlAtsurHbVlRZVVw4bm r2xp2H9Y0TvSnwuamdKSHsfvME/mcw/7G4wdjF8Fx1gpfYEFOSdGucXeJYyxoPc0vKbFEGmRcCvn qfYqx+tyvI6cK3tT1Q3ZlmLQ1SToJVB31zEY0nLP80JxdKTXW74xJiZb8F1vnlEFBAPDwpCVWYBi ZngnRBONxNUsQwuKm2YXZK8N1Z0j7z3ZyrPyKisfVQ1FYaL6UeyJenyusSbLV/tEBz9t35fWG8t1 lDR0EzpOWaSY9I6JicbXmAzTMDOGCq6DkMcAY529lpkr8Waq4vFxj/Mn08QeEWfXl8Y23lLv78a5 +AhYRDCKgFi5QC7EdcZscw7skzSVOOlcpwoLuzQibGSfapr36M7KxbZQCfUTTp0X0xyjeIF375OE h6ZN0nFEISpTdiwgxxW6dUoMlzMLn+q5yvXMz9h/vuSSdi4VdMuaxC7UTwoavqjYGVIZj4CsHcfB xRXbg6Glp58iRy7LlGwLg4shcvqG2zkaP7GT2iSQlndYLPZQGspITaTuY88f2VN2xMAZ3MJqRSxg Y32FhQ8ZSqJIJ9DYfNkKmChOJZGOgAMaXAEycuvnWsr3pOSQgtKS04izwGSMw+AKlKX/oP5R3RXP 3Vu6d90DuqeJeL/ueTROIKPuXXdM95yl6N4hb2ambsta6RdYAQN4gjtR4Dc806BnCTZY4UEf5USv yhmAgEQRQDxECUHN1Ct9jPpAtuay+l8JrOPBxL13tPX+UQLGfIwGPVhL5Ci9EGYTj5RfpZwp+Lot ijSW8CisoQmFWHA//rl5MR2KfFLbIDi0x6HXcb9cJ+gi24NqKbzp7/8JdPNFOBl3TduXTXiBxhmq 7OQ3Aa/bPO9qzDtdN2F8Jg3P/gLnquDyCmVuZHN0cmVhbQplbmRvYmoKMjYxIDAgb2JqCjc4NApl bmRvYmoKMjU5IDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgMjQ3IDAgUiAvUmVzb3VyY2Vz IDI2MiAwIFIgL0NvbnRlbnRzIDI2MCAwIFIgL01lZGlhQm94ClswIDAgNzIwIDU0MF0gPj4KZW5k b2JqCjI2MiAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAv Q3MxIDcgMCBSIC9DczIgOCAwIFIgPj4gL0ZvbnQgPDwKL0Y3LjEgMzAgMCBSIC9GNi4wIDE0IDAg UiAvRjQuMCAxMiAwIFIgL0YzLjAgMTEgMCBSIC9GMi4wIDEwIDAgUiAvRjEuMCA5IDAgUgo+PiA+ PgplbmRvYmoKMjY1IDAgb2JqCjw8IC9MZW5ndGggMjY2IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29k ZSA+PgpzdHJlYW0KeAGlVU2P0zAQvftXDNpLIm1c23GclAsItHvgtlIkDisOq6oVAdKl2yAQv56x xzNJt10JhNoqrmc8H+89Tw5wBwcw+GmdgcYbeNrCR9jD6v3RwuYIFo6b5/YdGB1giD6OfCxYddEv HU2WAfPY9Ley4F38bkZ414Pt8m4HrXbgrOpHWN1abdC/38E9FJ9LqIy2UEzTd16+Xq0Cr7/x4pEX P0us0anigTfknCz0nm1bXkwlfIL+A9z0CRYp1/kAdVC5Xp/r9eC9XhtXN2BbSEW7RdEbjvr4lIqB QvK8LRVWB8Wwx4ypMTGx7zBeg+MIhheWF7JTxVCIDFpiNWlBWFU5tETxy+4i7bWBuvMQQgDrAjKv MvOJ1SgKk9hPZC/Yw3ONNZm+OhAc+LRt0E3jW2gb4tAv4LjyHrDL1PcxtYEATEPeGR8mNsJEdKOZ tlQBcoD9f+dz6DEzlnqK5YRAnc1apo5QETG/0d3lvpBlxINodplmfCZZBo1MYw+J51ZblcRZvCqh /0KCEcCWUL0QsvZR6oGiYWiKhlK/zY2hkhNUqAekE7GAvIGqTf/ZgZQ+24esLfbjc3hH0jlGkO1f OUG145CScywVJadrFAlb4h3j0S/h+RdtRySDISRJIogkXfP/QjIYioZIytC4+cWdSfV0JWMbjMq5 sLbc83UGjF3Hs3CSgF3OAIRMBsqUgJR8s/LZJFXGm0Deb07QRu3iqMTLiPP0RaxJhBUOc18j2F2n jV03tcg2waOKq3+R7RwzNLrFmCJbHPs0oX9ksKQ/6YGxEeylz+e+qpAdPnQuSbZIfNZznBpJ4Nmi CpExn5HwAj5fCn6yJ18OIlTNejnkJNyvZJd6OIT0y7GlLgEACzwdXhHo8/fw6TReMN+0a93gFL/w YsJ9m6dLzXeiqPGFycPq7g9A75enCmVuZHN0cmVhbQplbmRvYmoKMjY2IDAgb2JqCjY5MwplbmRv YmoKMjY0IDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgMjQ3IDAgUiAvUmVzb3VyY2VzIDI2 NyAwIFIgL0NvbnRlbnRzIDI2NSAwIFIgL01lZGlhQm94ClswIDAgNzIwIDU0MF0gPj4KZW5kb2Jq CjI2NyAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3Mx IDcgMCBSIC9DczIgOCAwIFIgPj4gL0ZvbnQgPDwKL0Y3LjEgMzAgMCBSIC9GNi4wIDE0IDAgUiAv RjQuMCAxMiAwIFIgL0YzLjAgMTEgMCBSIC9GMi4wIDEwIDAgUiAvRjEuMCA5IDAgUgo+PiA+Pgpl bmRvYmoKMjcwIDAgb2JqCjw8IC9MZW5ndGggMjcxIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+ PgpzdHJlYW0KeAGlWE2TGzUQvetXdCqXcRX2zpfHdi6QLAlVXNiAKQ4kB2LWYLJeJ/YEsvwffhL/ h5Za7814ZGc3RSUpKyOp1d3vvW7NvJeX8l5y/TMrc5nWueyv5Se5lYvLQyGrgxRyWA3n15JPGtn4 NaWtKaRwJ9eFrWFmo+cU4b/jQurS/11t5dlSinl8OpfZpJSycMutXLwoJrmuX67lZ8l+H8k4nxSS te07DJ9cXDQY32Cww+CvkfpYuuwXPOA+Dia3mLvGoB3Ja1l+K8+XIS10t6wbqRoX/a2jv7XU9WSR l9VUipkEp8ue0ytY3e2DM5LxnK9GTr2TbHOrJ4bAOIW1m+0XUsJCjkGBAZ+MvSnNjM54b8LAcjWO pmml7kfnYa9yqea1NE0jRdko8i4iH1D1pMgD+gHsHnq6b1rkEb6qsXTob1HlkzyfKY5Tw7DupeOx 5vA5otPfYu4z4HNjI7kMsflnv2KkWQkoHvBA1r0NzxT2kMadpjoM3iYReueaxuIcxqfn+135ZH46 SsVcs2OglxF0/Q0kbSaKe11bmDMFIFA1ezSS5R9GH6avn7gzJqta/Sgbs6amSfzvEbjxQ5NjhNaB 0UsH7QZpiL/K65A1if9vVRUhPXhw9SPMLgczWKmoKInUuG1x2dV3ceUPwy2mtKDRsIOe0gafwJhK MCxNV/yJc4cxfYhbOiaEBy7jA57yW1y6hS3OWGI0Y9ykHkXBOy8ICl7JfBL7ANS0NrH3gSIs+5Gz zCWn/hv9agED9zBqPrHwXQaGc+JNNIIJPaWrWD6p9i8wOoknFrABl+dz47IF9ZlcTk2GFM3naYru 57I7x2XwUKEDQ5HEc1x2GVaSZdzyuVx2GW0QVRhrtTcd8x4zJBn3kBsEvDd1JDjJtAYGs4iCK6NZ F6UpGViNlZ5fHScSEqQFLSBWFCfKD2Ij/VLHEe0wQz1lwjFomEtZwhgcrA1g7hnjDK0km4cawfnx OJdpmzCNEiKci6VrPDgPbzzfxa6utfJ8WeM59BWgtUytlnG7FMAHXdLBeJ+0U1R9myrqRdD2/2lT vqXnpSxX0qsbRpl6MehY2dObw07e7Q6HzZubO7ne73f7w5OjnqjN1l8e9UqYMBO1xDrnWO+jdeWD mGmBKhbTYX16fGTXrioPsNlMJzNvMy1Q30TJPR+2uMi5TnL3MEw6hoFHwNs04DI2J5giM8hrbCUF O6pgCpQhvzCRWL0D5XvsCvUFdUYi++gHPNYFHQ2T/IJ3HWazhWJW5vEGOMVlJvung+sBVhbhlpVH 0NWKw7vASiMw9WoubWDXf1UgL47Iw57htBHcD+jPew3QtmMx125VyTaFXXdYw5kIhsvueDodI1CJ P9rXzTAPP+CIazjW391lXhP8CemkMATplFUVpDPU/4Okk9oM0lGbA9XrC9pZ6eB2iPscyWwJdRmY igsN+MnewGINCEBMtJMopc4UcRxKKWTz4kWD67o6/showRm7ejudwXE5IMMD4gNHOglZy4ZjNt/r XZhAo8AvYqa/LUM4tt3F+PB0sTYAgr/V+Gt34i33+NI7VLS+RIVX3FTRn7o6d1ZM0YkVzXRf0fHy TE0lCuoUzSnWgRXT1mPXoERQpKu3APRAVfrUHNeECLbztyyb4bHcbl8ntPzQzjoWG2gbS5Xs3ki4 15u1E+7wJMa1jfvwBUGP2iNCnsltvYoSXSZj1fdeRTl6W3Bni/Lxm29VzsKVYtiNVUjxzdcZ5qc6 PEpKZzJcJNRm2o2/Rq6IyRoMNmH1soH8kustpcTYVVORXHhBZE/E9nUiRMxcAn2seApjV2MeCjnT YdYwOM4IOAMY+QAHKFShP9MYj4FPr7KP8KrC4CPc+jJufzXqQ37+W9/xF58eF6baz6f6pejExy99 XjQGnLaZ+AWkmpEI8vI/EZwDkAplbmRzdHJlYW0KZW5kb2JqCjI3MSAwIG9iagoxNDM1CmVuZG9i agoyNjkgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAyNDcgMCBSIC9SZXNvdXJjZXMgMjcy IDAgUiAvQ29udGVudHMgMjcwIDAgUiAvTWVkaWFCb3gKWzAgMCA3MjAgNTQwXSA+PgplbmRvYmoK MjcyIDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEg NyAwIFIgL0NzMiA4IDAgUiA+PiAvRm9udCA8PAovRjIuMCAxMCAwIFIgL0YzLjAgMTEgMCBSIC9G MS4wIDkgMCBSIC9GNy4xIDMwIDAgUiAvRjUuMCAxMyAwIFIgL0Y2LjAgMTQgMCBSCi9GNi4xIDI3 MyAwIFIgL0Y0LjAgMTIgMCBSID4+ID4+CmVuZG9iagoyNzYgMCBvYmoKPDwgL0xlbmd0aCAyNzcg MCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4Ab1XTY8bRRC9968olMtYisfdM+MZ by5BfASJE4ss5YAQSjbr4MCu2bUTRH4miP9DdXW/N+MZWxgOUTZyuz9eVb1XVd1+kGt5EK//usrL svHyeCsv5V4WX+6D3OwlyP5mvL4RX7ayjXuqtCdIcCf32VFb2aqdYF/nQZoq/t3cyRdrCas8u5Ku rKQKbn0nixeh9Lp/vZEfpPh5JnNfBikOh98wfLZYtBj/isEOg99n6mPlileY4DkOynus3WJwmMmP sv5Wvl4bLXS3alqpW5f9bbK/jTRNeeWreimhE3O6Gjh9A9TdozkjBe18PnPqnRTbe7VogXEJe7d3 T6UCgscgYMCZeYRSZnQlemODxNU8QxOlGUYXZa+91KtG2raVULWqvMvKm6oxKbypb2IP1NNzy+Cz fHWb6NDP4LvSV00j3TJp2AzoeKIbtpmIxLwScNC4jQmE/UpZs4kD9u7uZ04D0s2ye23h63CPwfj8 B0wsMg6PaI4oiit2sPDLhI4YSdsmUvoySGSoA9EJX64yJe4ooTW4SGXKkCpniH5aRrfKSq20WIp0 qpbldfHZTNbvNNfctTFoXA9ZPgNZN+qHymVoCs0q+SZnVcolZUlpNuI4oSwnKlNZ6JbESv/5x0y6 JubT0wwmPY+GhQNaafY9ZbkiKZ1Zprzy57s8eJ+hKNoBoKlKpQAY/SMYz/yV1HJWmkkJqnEBaVGH 1o90cMc6aM0z5y+ANB00W6BDQtNu9TLHrV3LKCLZjPtNXkHcFCiH6wowdAAIt2CFxAPkDgJoypvd VEGOadD7wdrKO5EowAbkBhP5aO8XbFyeDtQ2R+KKh2z9ff5kiBSdhMEhbd4WWt8dbKKPUR0+2cHP 1aeJuFpNRSRZ4AaajSjpqwwL8PX1OO1/gkAgDTJsGDkwPhlZxiYzh35Mon8+5FWrRNugvgHinX+2 UlItzfVZ0dRafSForwpXy3EXfPJfumCP2S7LLmJSObbB7x5xYUAJZA2+M78YJhR5BgG+h1a3AJuS xBkUA+mjfIBLlvs0hT1tt8dNE1DYAJdZ7bkz9pXIYJBNH+kGrCN+usUdmnn5cp2uIfFpmqeAC4vY KTnjTzatC8pyrG59lZ4Rw0uO4dIbev4BZE6X5nvECZ9RztyLoMA4lDhlMHNGg8yjUV+aNgeYB2Wb 3cz1zMRqTP/tlXG2tI7fF6HTZ6c+MLQU3OLF9H3xf+41xZxy/+8XG8LjxXFx4pNm8M/qGinkCijD 4omvyFRGRBmrSYcoFZKV6TMFQd3AJYhGKzwCMNYKrm2aw9m348tu2ln1Qd/GR+ZZ+fs6sc5aeX3Y nOyszt6XF+nfY1pnVczjzur0YaOdNfMMRsYMkRnGjUbGzvoVKhEYYOZv3O3Q7kBzVJpL6XDfBZkt NMwn5ECk/HiAOMjW7HWPBtcQHsuaZnD0I+1xD1xDXPAZ3wGuj9+6K2spyuHdOv05fvpH2SA5lt1V uYw/5qa/T3UeV2Rd+vzerVf5ytXEuP4HqQcknQplbmRzdHJlYW0KZW5kb2JqCjI3NyAwIG9iagox MTMzCmVuZG9iagoyNzUgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAyNDcgMCBSIC9SZXNv dXJjZXMgMjc4IDAgUiAvQ29udGVudHMgMjc2IDAgUiAvTWVkaWFCb3gKWzAgMCA3MjAgNTQwXSA+ PgplbmRvYmoKMjc4IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNl IDw8IC9DczEgNyAwIFIgL0NzMiA4IDAgUiA+PiAvRm9udCA8PAovRjcuMSAzMCAwIFIgL0Y2LjAg MTQgMCBSIC9GNi4xIDI3MyAwIFIgL0Y0LjAgMTIgMCBSIC9GMy4wIDExIDAgUiAvRjIuMCAxMCAw IFIKL0YxLjAgOSAwIFIgPj4gPj4KZW5kb2JqCjI4MSAwIG9iago8PCAvTGVuZ3RoIDI4MiAwIFIg L0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBnVfJbhtHEL33V9SxCXhG0z0reUosOAmS iwMzEBDTB4exHCahHFvM8pn5pLxeXs1wGUUWJKCLvdTy6lV1z0f5Xj5Khb/eV9I2lXx6JzdyJ1fX 90629+Lkfnu6fitV2cku7PFpjxNnLu6LR+PKDnZc/Fk4aXz43+7l+VrckGcH6Usv3pn1Xq6+cmWF /etbeS32l4UUVenEHg5/UFxdXXWUf6fwgcLfC/jojX3LCT2nQnnHtXcUDgt5I+tv5cU6wqLu+qaT ujPZ3yb720jTlMvK1624XqLTfuL0llo/fIrOiFU7XywMvBO7u4PFGJguce9u/0w8NVQUHAWdKYIq IIOV4E0UElZFVq1ampno2n5ZtlJXyIcJ+ZjEh3nXpdBqhmbr5ULWvyaQAntwsh4a6bpOnO8ygQzJ EbhVRRJFzkxIgHOtC1YDC+ouoYqx96UbmhZCm0w3ZWVIBaAaoQuguiGACOjijMQJQHHzNWe4+S0I Evek0VjxAPBiquecql1fDlXdT50C6RM/XVUA/7YN7rjCNyv48lnam24o+8F7aE/sR8jKfihLqr+M 2YeN94w5URgzP3MJhFfLJmYnANshP/VQs7jPyzdmCNXvlkO5dI2TrgflYzdAtUtl4oZp8rAMhSl5 PlMGYyzhTJluEkRiLjxtFwb8hLBKHIakAiJlKi+ON5OcByXG/pRPpPqBrn8IBHWlTiAWfEl2U0vA VoAXrbyPo7EkyS7PH6+LfZbnobnuy1rsmI+8kr0wqhppiSbU5kRHXHh10KXDn3nzPUoZtWJhp1h6 BHlN19EHj9XRVQ0OZ1OUDH8TOkOaqoj8ZjEhybQto/hmk9rmFsekGvRlVd3SxkqnHp1UR7fo8r9U xonUSZExtPcYv4araefWayrjVs3RS7YHbj0QPFX/Gw1rHg/A04dU41DRoz6j4CeSq8te7I/ZsVdU vrHotgn2IQnGPgn24QT2cB0qYiPsKmVr0dGIFT06HXOi0Auz72ewF8SQRabkUtg1EX8xSF2i2v+H Gdc6NNdNOSR4XTdUZR0dK86h/o64fkOBlja25pSSL2JuLlzpD1Hd4UkSr3NyPYEe82lsenWACitP c58LOrNj7Dnoc11IyVncMi+K/p6sH5sJQXk0/HV4ReBUUTf9HPYXaH5e70c0N4+8MlyznIVcCLmx K83wUyEXQj4SvyC/CT3xPW8Mc6gaq+nRAgikduFlFVB1zrGNTCk9dpTUR7R9PSe1aHFDEORpfcT1 y/SyuMBpBRic1ralAj04Hkf4XhI2JR8vTo5stPyNC7fwbdkkvs1U+wjNKBGk3FlnrkMz3vVIwel1 qJ3yiKdzt6A5fdrgwTrXGsT2NHfxbZPe/McwshOIfUF0+GbgRrLxlhPbs2pnBjDq4++BD7v40cZ3 +bRC/bKWoXv4UTf9LsPlGj8+YBcwu/iECgKiCn0niXsKqTKwOGYlUQZTaGXxXN4Ddv2Qr6U1Xj+T oP4Dl4DLxAplbmRzdHJlYW0KZW5kb2JqCjI4MiAwIG9iagoxMTE2CmVuZG9iagoyODAgMCBvYmoK PDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAyNDcgMCBSIC9SZXNvdXJjZXMgMjgzIDAgUiAvQ29udGVu dHMgMjgxIDAgUiAvTWVkaWFCb3gKWzAgMCA3MjAgNTQwXSA+PgplbmRvYmoKMjgzIDAgb2JqCjw8 IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAwIFIgL0NzMiA4 IDAgUiA+PiAvRm9udCA8PAovRjYuMCAxNCAwIFIgL0Y2LjEgMjczIDAgUiAvRjQuMCAxMiAwIFIg L0YzLjAgMTEgMCBSIC9GMi4wIDEwIDAgUiAvRjEuMCA5IDAgUgo+PiA+PgplbmRvYmoKMyAwIG9i ago8PCAvVHlwZSAvUGFnZXMgL1BhcmVudCAyODUgMCBSIC9Db3VudCA4IC9LaWRzIFsgMiAwIFIg MjUgMCBSIDMyIDAgUiA0MCAwIFIKNDUgMCBSIDUwIDAgUiA2MSAwIFIgNjkgMCBSIF0gPj4KZW5k b2JqCjc3IDAgb2JqCjw8IC9UeXBlIC9QYWdlcyAvUGFyZW50IDI4NSAwIFIgL0NvdW50IDggL0tp ZHMgWyA3NiAwIFIgODQgMCBSIDkxIDAgUiA5OCAwIFIKMTA1IDAgUiAxMTIgMCBSIDExOSAwIFIg MTMxIDAgUiBdID4+CmVuZG9iagoxMzkgMCBvYmoKPDwgL1R5cGUgL1BhZ2VzIC9QYXJlbnQgMjg1 IDAgUiAvQ291bnQgOCAvS2lkcyBbIDEzOCAwIFIgMTQ0IDAgUiAxNTEgMCBSIDE1NiAwIFIKMTY2 IDAgUiAxNzEgMCBSIDE3NiAwIFIgMTgzIDAgUiBdID4+CmVuZG9iagoxODkgMCBvYmoKPDwgL1R5 cGUgL1BhZ2VzIC9QYXJlbnQgMjg1IDAgUiAvQ291bnQgOCAvS2lkcyBbIDE4OCAwIFIgMTk2IDAg UiAyMDMgMCBSIDIxMCAwIFIKMjE3IDAgUiAyMjQgMCBSIDIzMSAwIFIgMjM4IDAgUiBdID4+CmVu ZG9iagoyNDcgMCBvYmoKPDwgL1R5cGUgL1BhZ2VzIC9QYXJlbnQgMjg1IDAgUiAvQ291bnQgNyAv S2lkcyBbIDI0NiAwIFIgMjU0IDAgUiAyNTkgMCBSIDI2NCAwIFIKMjY5IDAgUiAyNzUgMCBSIDI4 MCAwIFIgXSA+PgplbmRvYmoKMjg1IDAgb2JqCjw8IC9UeXBlIC9QYWdlcyAvTWVkaWFCb3ggWzAg MCA3MjAgNTQwXSAvQ291bnQgMzkgL0tpZHMgWyAzIDAgUiA3NyAwIFIgMTM5IDAgUgoxODkgMCBS IDI0NyAwIFIgXSA+PgplbmRvYmoKMjg2IDAgb2JqCjw8IC9UeXBlIC9DYXRhbG9nIC9QYWdlcyAy ODUgMCBSID4+CmVuZG9iagoyMDIgMCBvYmoKWyAxOTYgMCBSIC9YWVogMCA1NDAgMCBdCmVuZG9i agoxMjUgMCBvYmoKWyAxMTkgMCBSIC9YWVogMCA1NDAgMCBdCmVuZG9iagoxNTUgMCBvYmoKWyAx NTEgMCBSIC9YWVogMCA1NDAgMCBdCmVuZG9iagoyMzAgMCBvYmoKWyAyMjQgMCBSIC9YWVogMCA1 NDAgMCBdCmVuZG9iagoyNjMgMCBvYmoKWyAyNTkgMCBSIC9YWVogMCA1NDAgMCBdCmVuZG9iago0 NCAwIG9iagpbIDQwIDAgUiAvWFlaIDAgNTQwIDAgXQplbmRvYmoKOTAgMCBvYmoKWyA4NCAwIFIg L1hZWiAwIDU0MCAwIF0KZW5kb2JqCjE3NSAwIG9iagpbIDE3MSAwIFIgL1hZWiAwIDU0MCAwIF0K ZW5kb2JqCjE5NSAwIG9iagpbIDE4OCAwIFIgL1hZWiAwIDU0MCAwIF0KZW5kb2JqCjExOCAwIG9i agpbIDExMiAwIFIgL1hZWiAwIDU0MCAwIF0KZW5kb2JqCjE1MCAwIG9iagpbIDE0NCAwIFIgL1hZ WiAwIDU0MCAwIF0KZW5kb2JqCjIyMyAwIG9iagpbIDIxNyAwIFIgL1hZWiAwIDU0MCAwIF0KZW5k b2JqCjE4NyAwIG9iagpbIDE4MyAwIFIgL1hZWiAwIDU0MCAwIF0KZW5kb2JqCjE1IDAgb2JqClsg MiAwIFIgL1hZWiAwIDU0MCAwIF0KZW5kb2JqCjgzIDAgb2JqClsgNzYgMCBSIC9YWVogMCA1NDAg MCBdCmVuZG9iagoxNzAgMCBvYmoKWyAxNjYgMCBSIC9YWVogMCA1NDAgMCBdCmVuZG9iagoyNTMg MCBvYmoKWyAyNDYgMCBSIC9YWVogMCA1NDAgMCBdCmVuZG9iagoyODQgMCBvYmoKWyAyODAgMCBS IC9YWVogMCA1NDAgMCBdCmVuZG9iagoxMTEgMCBvYmoKWyAxMDUgMCBSIC9YWVogMCA1NDAgMCBd CmVuZG9iago2OCAwIG9iagpbIDYxIDAgUiAvWFlaIDAgNTQwIDAgXQplbmRvYmoKMjY4IDAgb2Jq ClsgMjY0IDAgUiAvWFlaIDAgNTQwIDAgXQplbmRvYmoKMjc5IDAgb2JqClsgMjc1IDAgUiAvWFla IDAgNTQwIDAgXQplbmRvYmoKNDkgMCBvYmoKWyA0NSAwIFIgL1hZWiAwIDU0MCAwIF0KZW5kb2Jq CjIxNiAwIG9iagpbIDIxMCAwIFIgL1hZWiAwIDU0MCAwIF0KZW5kb2JqCjc1IDAgb2JqClsgNjkg MCBSIC9YWVogMCA1NDAgMCBdCmVuZG9iagoxNjUgMCBvYmoKWyAxNTYgMCBSIC9YWVogMCA1NDAg MCBdCmVuZG9iagoyNDUgMCBvYmoKWyAyMzggMCBSIC9YWVogMCA1NDAgMCBdCmVuZG9iagoxMDQg MCBvYmoKWyA5OCAwIFIgL1hZWiAwIDU0MCAwIF0KZW5kb2JqCjU3IDAgb2JqClsgNTAgMCBSIC9Y WVogMCA1NDAgMCBdCmVuZG9iagoyNTggMCBvYmoKWyAyNTQgMCBSIC9YWVogMCA1NDAgMCBdCmVu ZG9iagozMSAwIG9iagpbIDI1IDAgUiAvWFlaIDAgNTQwIDAgXQplbmRvYmoKMjA5IDAgb2JqClsg MjAzIDAgUiAvWFlaIDAgNTQwIDAgXQplbmRvYmoKMTM3IDAgb2JqClsgMTMxIDAgUiAvWFlaIDAg NTQwIDAgXQplbmRvYmoKMjM3IDAgb2JqClsgMjMxIDAgUiAvWFlaIDAgNTQwIDAgXQplbmRvYmoK Mjc0IDAgb2JqClsgMjY5IDAgUiAvWFlaIDAgNTQwIDAgXQplbmRvYmoKOTcgMCBvYmoKWyA5MSAw IFIgL1hZWiAwIDU0MCAwIF0KZW5kb2JqCjE4MiAwIG9iagpbIDE3NiAwIFIgL1hZWiAwIDU0MCAw IF0KZW5kb2JqCjE0MyAwIG9iagpbIDEzOCAwIFIgL1hZWiAwIDU0MCAwIF0KZW5kb2JqCjM2IDAg b2JqClsgMzIgMCBSIC9YWVogMCA1NDAgMCBdCmVuZG9iagoxMzAgMCBvYmoKPDwgL1N1YnR5cGUg L0xpbmsgL0EgMjg3IDAgUiAvUmVjdCBbMTAxIDIyNyA1MTAgMjU1XSAvVHlwZSAvQW5ub3QgL0Jv cmRlcgpbIDAgMCAwIF0gPj4KZW5kb2JqCjI4NyAwIG9iago8PCAvVVJJIDI4OCAwIFIgL1R5cGUg L0FjdGlvbiAvUyAvVVJJID4+CmVuZG9iagoyODggMCBvYmoKKGh0dHA6Ly93d3cuaWV0Zi5vcmcv bWFpbC1hcmNoaXZlL3dlYi9jb3JlL2N1cnJlbnQvbXNnMDEyMzUuaHRtbCkKZW5kb2JqCjEyOSAw IG9iago8PCAvU3VidHlwZSAvTGluayAvQSAyODkgMCBSIC9SZWN0IFsxMDEgMjIyIDUxMCAyMjdd IC9UeXBlIC9Bbm5vdCAvQm9yZGVyClsgMCAwIDAgXSA+PgplbmRvYmoKMjg5IDAgb2JqCjw8IC9V UkkgMjg4IDAgUiAvVHlwZSAvQWN0aW9uIC9TIC9VUkkgPj4KZW5kb2JqCjEyOCAwIG9iago8PCAv U3VidHlwZSAvTGluayAvQSAyOTAgMCBSIC9SZWN0IFsyNDYgMjU5IDYzNiAyODddIC9UeXBlIC9B bm5vdCAvQm9yZGVyClsgMCAwIDAgXSA+PgplbmRvYmoKMjkwIDAgb2JqCjw8IC9VUkkgMjg4IDAg UiAvVHlwZSAvQWN0aW9uIC9TIC9VUkkgPj4KZW5kb2JqCjEyNyAwIG9iago8PCAvU3VidHlwZSAv TGluayAvQSAyOTEgMCBSIC9SZWN0IFsyNDYgMjU0IDYzNiAyNTldIC9UeXBlIC9Bbm5vdCAvQm9y ZGVyClsgMCAwIDAgXSA+PgplbmRvYmoKMjkxIDAgb2JqCjw8IC9VUkkgMjg4IDAgUiAvVHlwZSAv QWN0aW9uIC9TIC9VUkkgPj4KZW5kb2JqCjM5IDAgb2JqCjw8IC9TdWJ0eXBlIC9MaW5rIC9BIDI5 MiAwIFIgL1JlY3QgWzE0MiA0MTYgNTg0IDQ0MF0gL1R5cGUgL0Fubm90IC9Cb3JkZXIKWyAwIDAg MCBdID4+CmVuZG9iagoyOTIgMCBvYmoKPDwgL1VSSSAyOTMgMCBSIC9UeXBlIC9BY3Rpb24gL1Mg L1VSSSA+PgplbmRvYmoKMjkzIDAgb2JqCihodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvd2cv Y29yZS9jaGFydGVyLykKZW5kb2JqCjM4IDAgb2JqCjw8IC9TdWJ0eXBlIC9MaW5rIC9BIDI5NCAw IFIgL1JlY3QgWzE0MiA0MTEgNTg0IDQxNl0gL1R5cGUgL0Fubm90IC9Cb3JkZXIKWyAwIDAgMCBd ID4+CmVuZG9iagoyOTQgMCBvYmoKPDwgL1VSSSAyOTMgMCBSIC9UeXBlIC9BY3Rpb24gL1MgL1VS SSA+PgplbmRvYmoKMjAgMCBvYmoKPDwgL1N1YnR5cGUgL0xpbmsgL0EgMjk1IDAgUiAvUmVjdCBb OTEgMTA4IDIyOCAxMzBdIC9UeXBlIC9Bbm5vdCAvQm9yZGVyIFsKMCAwIDAgXSA+PgplbmRvYmoK Mjk1IDAgb2JqCjw8IC9VUkkgMjk2IDAgUiAvVHlwZSAvQWN0aW9uIC9TIC9VUkkgPj4KZW5kb2Jq CjI5NiAwIG9iagoobWFpbHRvOjZsb3dwYW5AamFiYmVyLmlldGYub3JnKQplbmRvYmoKMTkgMCBv YmoKPDwgL1N1YnR5cGUgL0xpbmsgL0EgMjk3IDAgUiAvUmVjdCBbOTEgMTAzIDIyOCAxMDhdIC9U eXBlIC9Bbm5vdCAvQm9yZGVyIFsKMCAwIDAgXSA+PgplbmRvYmoKMjk3IDAgb2JqCjw8IC9VUkkg Mjk2IDAgUiAvVHlwZSAvQWN0aW9uIC9TIC9VUkkgPj4KZW5kb2JqCjE4IDAgb2JqCjw8IC9TdWJ0 eXBlIC9MaW5rIC9BIDI5OCAwIFIgL1JlY3QgWzIwMiAyNDEgMzUzIDI2M10gL1R5cGUgL0Fubm90 IC9Cb3JkZXIKWyAwIDAgMCBdID4+CmVuZG9iagoyOTggMCBvYmoKPDwgL1VSSSAyOTkgMCBSIC9U eXBlIC9BY3Rpb24gL1MgL1VSSSA+PgplbmRvYmoKMjk5IDAgb2JqCihtYWlsdG86Zmx1ZmZ5QGNp c2NvLmNvbSkKZW5kb2JqCjE3IDAgb2JqCjw8IC9TdWJ0eXBlIC9MaW5rIC9BIDMwMCAwIFIgL1Jl Y3QgWzIwMiAyMzYgMzUzIDI0MV0gL1R5cGUgL0Fubm90IC9Cb3JkZXIKWyAwIDAgMCBdID4+CmVu ZG9iagozMDAgMCBvYmoKPDwgL1VSSSAyOTkgMCBSIC9UeXBlIC9BY3Rpb24gL1MgL1VSSSA+Pgpl bmRvYmoKMzAxIDAgb2JqCjw8IC9MZW5ndGggMzAyIDAgUiAvTGVuZ3RoMSA5NDYwIC9GaWx0ZXIg L0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AY1aCXxU5bU/57v3zp3JzGSWTGayQGbCkAQJISEhQDCa C1lYUiRAMAkxMAECgYpJ2ATUGFsRCWpifVpxA6vi1spNcJmA1mitrfZVeFhFbZU8i0Zbo9QXtS6Z ef87iVZb+37v3pxvOed8yznf+b5z7jfZunlbE9mogyTS1mxqbKXY452E7Nk127cGRuu2tUTy0XWt 6zeN1l3Ay8+tv3jnutG6z0lkn93c1Ai+2PMV0hnNQIxWeTryic2btu4YrSeeQV52ccuaMbr3A4O+ qXHH2Pj0J9QDlzRuahrln/hb5FNaW7ZsHav/APnlrZubxvi5lshqG6V9K2WUXfQxFVM1KSTISbmk YeY1/CHkZbxEonH+HcvuGF7lKP6E/OZY43v84aeMwq987/8tMjhynRo1nwavFT2MPminXh65gMj8 w8hgZFCNxnoaI8Yy15woHRYXkQ4YAEgY6CJwbRX1SJ3iB6QBOgASHUQ6ABAUEAspD9AK6AD0A04A TMAsRrsOsQRpCOlBwAmAhFoVcP1IzwIE+l1KVQBIK+ajx/nGrJF+XetAuRtwEGAC53z0MB/9z0fv /6D0o3wWYEa7eehlHuY1D33Pg0TzMNo8tA0h7QB0Aw4CDIqCseZ9p438TYsToAwAzsb4qpCGAK2A DkA34CDAhJEqMFIFqBWgVoBaAUoFmdB3BeZS8S8cJuiiAn1XoO+KmE7+0bIbGB3QDxjtwYnSt3up ilE6kBq8BwEG7wnAAOAsQI3xaygZvCGAjJnNhd4DSEMAo3YQoAPOAkxzkkArBa0UtFLQStHma4xR G4hhnNxDAUAe92hWKbAzb6e2s3Wn3HqU66mD6zWvoF0duwTVdNQIC23jorPb2GK3hs3U67cYmXa7 nxxOR8CR55CLuh0HHbqj33HCMeA461AtDvZzLpewXHSAD/PTfJxP80ccZVAUv5KrlCigKIeVp5Xj ymnlIyWqgCL5pVypRAJFOiw9LR2XTksfSVFJtZDVaQ1Y86yyQ/WruWqJigGtB626td96wjpgPWtV D6iH1afV4+pp9SM1qqpaWAS0I0xdzq5AV16X1lXVFepq7ero6u6KC3Wd7RKj2P6uE10DqKqBF/Ne 7H9R2ifvU47JxxQ5VU5VKuVKRT5XPld5WH5YkRf7D/iFw+/3i8VpB9KEI82fJiyONIdfmFuSuSRZ SxaU7EwWLUlckqQlCUpyJkFvSZQMhsTuRFGSqCUKSnQmihZPt0eUeDSPII/TAyYPJQqzvs7k19cd iw6Tibz8fO8p1R/m5zXfqWWqd3koyb885EryUkUFNrnbZdaO8ZsoWfjnve3ZYHygtz2E7P7e9rf8 c6z8M1ovbiM/383V8oN0Pzq8jat7f+r19vH+0UKYV/a2e9Gkvrc9B1ltb/s1RssLqV2ZjpZVXC12 Uh1aVqLB6QBaLuBqzfLCeO9X7ZP8n9c/aQxAf+dqznpisved9lL/mfY5cfwkkCe42rKUF5GXjqOX N3vXe3/fB77bemd7fxfm6iPDQe+LRv7sOO8LyDVLd6L3GMToG+v0CTCX9k71Pgbio4+meO9rDCvT e/331h+LjXkPsJjGAWM4K4a7i6vdPwfFS3diuOW91d47jIav+b03gmXSXZDHS90gGRPuQt8tvdO9 e3/5zST3AHW49zxvByYpPdl7jfcK0NQd6NtLO7naNL33LW8rUBmrYj1tMnrq9W9on+M0euRDtC2W 30crJlUaHHyAaiC9n+t6t93vfwrFGmGjxSCUH6k5nOoNs79329P+OU4eTyuUZ+hpUMahyVqagVIq SlNpKkopR2rOBMGd/FjNqXTvFyv6jO57vZ/VhNn+xDnel7fl+f9rV9iYy0s1fRM+MmhHt4XZ+rg/ XPOW/9CKsKIeud97O9gTNNtk708wmWtB2Lirz7aan9Rc3ovQQ4W1QqkwL7fg6Q4zaflq9/tq96/V 7jp1onmCOWBOM48zp5iTzF6zx+w2O83xZps5zmw2m8yyWZhxTJ/zNEyxCDAf8FuAzHqCVCkql83l Sr1/DVWuDuifLguGOW7JCl0JzmXdXUmV1XP1WdmVOEeW6jOzK3W1qr62h/mGOl1ci3lU10Juo747 VXeX1vYR8zm7r0818uju6+vqeEsSebP/9UkyUFxZtfMo9J9GanblMhS7Y8Wk8fotlctq9YfG1+n5 RiE6vq5Sb1kWuKi2D8fTm+VlffyWkdXV9knpfLp8qYGX0svqwHZ/jI3W81tgo3YjA5v8Ma032Gi9 /LHBBu2P8tWjOfgajQx86l6qj/HVq3tjfMp0g6/n5Prysp71SMCTtZROxnhOZi39Fg+MEm3LeuqR gCvjWq6OTaw641pwUaU+K9bTrl3g2YYEPNxJu2I97eJOoyd93j9YVoyxfPINyycxltA/WGpGWcQD X7OIB8DCrZDuf5bV9lakV5TvK4Os0qBRa4zVetvXV5Q3B8tDZf83W2P9/4ftKJ2E1GOc9K+rPIbh f0v5fkLTXD6y8o/7LytvwkSD5U2AkL5ve3OS3rE6EOjZ/0eDENClzNDqNc1G3tik/zHYVKbvD5YF elbG2v0T+TKDvDJY1kOXlVfX9lymNZX1rtRWlgcby+qONLStvuk7Y+39ZqzVbd8zVpvR2WpjrIZY u38a6yaD3GCMdZMx1k3GWA1aQ2wsLt9gbLeq2h4zza0rhWkZ+RFhjcPuCaWm1831OlvPj22lc9OT 2lOPysQPkDW7TrcF5+p2gLHLcubkzDFIMmJakOKBdoyRktrPTU89yg+MkZxAu7CVx5YA0Ud5c5jf K2/WtX0hPRAs000G4v0xxAQgyED8dRQR5r8Ey2jllpVbYs+/FLZu3bJl67Yt27aBYSWSb0N2dqy2 FfQtvGUr3i1bUUHNQBkFAzf6KkcpOQaHKFnOpGSi6ODXELk4OmjQImuiH4rB6Ic4id3iVHRY6Sdb 9FVEfMi/HVj/u7I4T5xn0KKn/h3HGP4vyA34/mcx5ZPRw5X0dxrkZNpBl5EgH31ApSTRHbQ4ehjf E0xf0NvRN6mQ3o3+hi6ld6Jd4CqnNhpB21Q6QAPAPUUX0H+DMwFfM1PofLqR7qR7EQacoDfpbbJQ Cp2LtnvpP+ld+pyV6HNo64V2UukcWkjb6Ak6Rq/SGYpGO/HtkYb6IA3RWXZLC6K9NB48F9Eq2k77 6V6RLS0lN+2jHjpCL6D/QRacHL0o2hx9OfoaJVKQZtIsWkBN1Eo3472PHofHe4GOY4TXMZtB+hsn 8zxu4K0cloLSVKkj2kH1mN1P6Vbqwxxfoc9ohON5MmfzRdzKt3JY7IIrn0Q5kHMDbaEOvHsg5eP0 PPr7jJnHIeAJ8zuiXHwhxSGuvFXaLx2VWV4lXw99KVjZUrRdQktpHf0QEl9GV+G9ge6hR0ino/RL +ht9yTKCn00cFb+WPJJPCkkfRW+L6tHXsQp2clAWZpCN77oZeGfh624B1dIa9NdMGyHrpXQ5taPP 3Xhvpttj+n8YfRu6fZKew0xfhGSn6I/Q2X9jHT7FeAIjKuzhJGgki2ci4qrkNbyeb+Cf8C/4lLBA mgukTdLViI6fl/5LGpJ9cpFcLL+nsHKeabKpC9+EH0Xzo49Gj0bPQk4J3w8WrFc65pqNmKIC7wJa Ae2uovXQ23a8u2BxV2OOe+ha6qafwErux+q8SC/THzC3P9FbsLqPMbvPKIrPVjO7MLfRdxzmmM8F mGcxX8CX8n/w/dzHv+aT/KFwCrfIEtPEdLFYLBOrxRqxXtwkCckhTcAKF0izpJCcKdfKa+U9si4/ CQlIcSrnK0uVe5VfmXJMV9P7NEzvfXerYFesph/FcKvMQbmPZ4t2moPI6m66g2/ma3glvm0CfCsi 6LfpWXoIkqyUlnzVM2LiazmHl/IJvp5nilR8CbczS/Fsl34sPSPfQPMkO+3mjSKej4py6ZR0n0jg F8QkyUPHpOV8Bb8k3Mp5yq/Er6GhDKzIG3IzTZZCVInvk59Is7AKa+VirMw07AWrKKIK/hiW9SAs /4Q8yO/z32BtXpEFbf6J7+V76QKRAFsdQCBZK/L4x3ifxY520m/oFljKj+i3Em41tHNLzp9dNGvm 9IL8aXm5U3OmZE8+Z1JWZsbE4IT0gD9t/LjUlOQknzfRk+B2OR3xdps1zmJWTYosCaYp5cGKUEDP DOlyZnD+/ByjHmwEovFbCBzUQFV8l0cPGO0aQfoOpwbOdf/EqY1yat9wsjNQTMU5UwLlwYD++7Jg IMwrltSifH1ZsC6gD8XKi2JlOTNWsaOSno4WgfKk5rKAzqFAuV6xvbkTkUTOFO6xxpUGS5vicqZQ T5wVRStKekWwtYcrzudYQVSUz+4RZLZDRn1hsKxcXxBEU3QjZZQ3rtWrltSWl6Wmp9flTNG5dE1w tU6GW8uOsVBpbBjdVKqrsWECG3SIQ/sCPVP6O68LO2l1KNu2Nri28aJaXWpEH+W6K1ufB3c2b9eZ pJwpYT5UXatbSmMhax8tjHb0LOgoQ7iE0eBR93ybPVXqLE/aEDBad3buCegHl9R+q7PUdKPLujp0 mjOlcmltOmYdLL8OMUAGYrmYBOiUk3IxcQNniDkq8GjQkhHaGNAtwbnB5s6NISxWSqdOS3em96Ys 1PqiA7SwPNBZXRtM10tSg3WNZeN6PNS5dOeRBVpgwXcpOVN6nK5RTffEO8YKNvu3C01YhVFarBRj N0qY9deqZmOOwQW6BhtbE8BMaoO6yJhlJE2zqHPNLKwInjqGRjdAf6FO52xIpysZzmCg8xOCIQSH PvgupnEMY8pwfkIG0TCXb0xO58avy3p2tj55smEpaimWFjM7P1YvzJmyXa8MtjoDeiXiPKqqRaO6 2blQeXq6scr7whqtRkXvWFI7Wg/Q6tRe0nIRDYmQQen/mpK43KB0fE35pnkoCHN+FC6CKFE3Z37z 53B6E8qbZ+vs/T/ITaN0bJ/yQI+sZHRW1WY2du5LzQx1XlcHq67Aru7srAgGKjpDnY3haMfqYMAZ 7OyprOxsLcduHBUpHO3fl6pr19U1M5SqF4xqQ08orZVShWGZKIlUCaXKZcHKJStqjdUwjEuXM/C3 YG2wfO0GmFDH6o1YL/w1XmfsrPROp77wU0jHQDlPBJ9hnRN03GHoXBwTi3VK0BkLv0CXfLNAzOGX aQqAACGRS4XSIZy1h2g3YDLAb1pH+cgrADPAs1N5BV9Sgi4FlIrrqQVtELNBmYY6CV7bRI8iD9Dy MUwM/Z3E8HrGI8PL49YNHvD7n9EL1++n/f+xFrDGjbFbx3IbooP4WNmBFCd57DkXMdcuxBfDPINv E0JSpT24XbocXm+b8oop13Qn/PUUiNqDi0zDby/qUeQw5/WSST3GeSAyv/KYJFGcSQnztMclSSy0 qOCY9jjTAvOFP0zKvsA5XLxopPgC56fFi5wjxVRSjHTESKblFbjSXRnprvQpvDvyEE+KvKbQl1Qo HzR0G4r0cR18q5UWa1MVVTG/Lr+qyBaTmeFOmC7STH+Is8aZ1Lg47u6wXhlQ81RNrVJDqqL24YbX 5vy0YThlqCjXVYAhz6SMFLsKpuXRyoaVDQkFiR7VpGadzzODW96dNG1LTlmxaOHkFx5etj5/67hV tRi9kPfwF+IgZJ6p2SQWLxPc15USS2Eu1BxKK0K7bjqIwGkAy9nHhSQ7323An6uoiHKHioqm5SVA tkLEHXs4OTIIRc2LDkrVSj/k8dFCLd290WS3bSQl8SRJq6QrpQNjF4tqrtQlDUiSFBYeLd5xMmRp tXRYui26RbH0wUEnQa6hkYa2ISoZKhmalsf58LMiOEG4nG7fBJPL6S3In+FyZvLvD7/22iMGlC1Z UlZeVaX0R45EQpHGyBFeyPfxnbzo/UcjekQ/8igv5irjaNiNr4ubMUMLrXisRFmsCCzpIc0lv60J FiazRWGyCbaQcTmW0oFwlq0KyWdl4ZQDsiZXyd3ygGyS+0QixWGWbcWuotwGrLSx5ngbhocapuWl B10mtRCqLxA3v3vVg6GXJh2VgzeWRbNe+LGx6pNhZksxh3HUrOXvSWA1odm1wyVZ1AQ2O34W/7Zt o1uhcV+wsCnjtHFCH8fjhGVvYiJpuBsUCMETNEta/F7HTxdjzn0ih8Y7P20bHsJ0ioudQ66ChjZM ZqS4ZGT4DHRnWEMDu9JnuGfOmDmjcHpmcIJhFgX5iF/iWcWftPSr1+y7+28NTr+wYr/tncTjP3+q f9q6S1vOdbMS+fI/2Pr6L86rWxFa/c64gZOfHljx4MO7r6jKxGr7IceVkCMOu+5mzWezy3ZYkZls JruqxFntKtlsdnuYKzWHJHskCeGRTVbtX5hFmA9rVpLxMSDZhWyjY7hziMPt1chjitIdx3FHuZRU MVWzHBenhYBZxsSMh5gNI8MNxc4PsbOKDDMsKcHOg9mjskeZmi1f4XzO4XCwq4hcbtgntl0hF7gK EoMuycXCGsGd77M333w68gFnfSrd89XKzyKvizT+JIIDRFB+ZIlplfIHfLUt4nHa3Ny03Pkl8xem LZy/8Acr5l/ibffe4N07fm/mvvlfTBye56jK2DpBrJ3HwXkTfbum8/Tbbbzw9kDGxIe0QH9gICAF 1OwwL9ICHs/c25PjuIpCGOL+7cXXFIvi22VHKON4hvhRBmeEOVGbEMjMyxSZ3ccn8sTfkA/252Oz 5jvgO+x73fcX37DP5Avz55qzNa8jrzvvYJ6ct8N5He3Ad1aOlr3YsZgtAHOgJK+kv0S6qoRL9rSM 6xonumA5p6+c1TXrwKzDs+RZO8x94hzCITXSEGlrGGqDYaxscH46NDzSMBwrn2kYaTjT1kAlBqK4 ZAjWBIs20iFYkLuoCLZNDdyQUWCS0wMTje04sSBfdic6VVNwQmaWkRROd8+AbflmFkimRA826swZ 7sLpAlYni0SPWy7In8jfoA1bNCk9j9REuiOfRM5G9px8l7cN/Y7PfWzvgc/mVthDV14dvqG/ZcHF Qc9rl9kS7JnnL9t440cPvRh5ue8RnvrGc5zy1cCF2qzc8+pqS5pKahNO/fVVbPoJfA6/8denInf+ OfLlK5/NKN488MwveeFNZWUtIwXlib7kWQtZdD7Arr1PR7ZHXo88ev9uEbhq++QZLF/dtmPzQezQ iuh70uXy+TjFHtG03fab7eKWeL4mfq9zv1Pa4Nnp3OmRTPEm7wbnY+JRq+JIZrrqIFwyfpZgfKe9 JdUkqvarWm0dtm6bZAvzBVq2pcZhNX6VEdxId+faSmzC1phnr7KH7K32Dnu3XbefsJ+1W8jO9rDA cfxRMqNbU2OLm919+IqJHYkNDSNYN+OMwRINN5xBYizhMHZ5WwMerI0KlY7qfcZMn0ifIAqdbiyH 1Prn5KuXNzfXzKl2/7kicuSVl95/av8z4oP8+7sffuqOurbcSAeXncEX5vifGTthBuRfC/m9lIaL 6XmOAHfG3yJuMUkbxE6xV1xj2h2nXGraHrcr/laTvN60Lm5jvNTh60gTPkpzpmlprWkdaSfSTFVp IRQH0s6mKc40TgtzihZwOdyL3V1uCYL5IZs7McX4cUrwVf2EIIYpLLzagqrEUOITiZI7kRNrZGtL Co9P4ZQam5rmzqUSQnjyJok0MDfy3bm+Ep/wNea5qlwhV6urw9Xt0l1nXWZyaS7hgi4fcze2wJ8a SvTH/MqoCje3NRhec2hzgwGfNLSdaYCF527GkT5iJLD0NjaU2sa+eA5OyMp0OWfCsn1el5qehuMz YSqwqsknNr8z9dl9z2y4/IqNDxzbuItHnhabFrXkS2vLF+QXMC/NPXj7VbfgDiXu4J7OuyL/GWjv 5Ecvv2LO3O3Q8064gxBuwoyoY0UPHK+YpE03KSZVjmuBNxSSSaiksFDrOS/mfTrgf5SAnCeH5FYZ HmkUK+ODPIHMhj/ajNMQGzW2WWMu6dOXDDddgPOvwLVzcHBQfpzlyFdfLpQzv3wDGlxPpDRjpTOo T5szUc2wT1cL7WVqtXpGPWMfVoftcbIq20VijdXqr1FUJpPT5UpOSZmYEZebVZXVnaVnyQ5nvbsK ejfU7dOsKUnJ9alVKd0pIsWo52YEJ9Zn8J0IxTLyMrSMqozuDCUPWSijFcX+DFNgDB/KOJFhyujj Ysp0wvtvxsGDc96Jo+jrFHYPF2f8wdcax1PM8hHrxPyZz0jTONEVdBlezhQrZKEUb+DW/6Ho2sXV l2XN3l1Zd1Xp4Ky5i1YOJiT/oODCzEE588bl1dXLl1cvv+vekTqx6sCGm16NCFHxi/y5ZT++Y+Qr 6OlS+LobYzviR5qW4Sn0iGTPTs9ez37Pg54+j+lzDzvcbIsz1bjj7Sa36nBYbVyfS+wkzsU1ySrq osO4eDtNH+F3m7CI17zW+jxblU34bXk2EUCioSbbjIX0xRbSCIA2Dxk2CS9nnMHwcrHjt60B8cV0 w/picsG7jckt3TiYMi9n9srMwVeLumqa9hWKtHsunl159RMRv5x5x4oVG+67AzZXir39PCSxI77f oM08ZH7cLH6jnFKElS0mk1ny7ZJdu6yyarWeSGVP43y1FvFmq9qt6uoJ9axqJmRCDQunZo/Hv450 IEaUWqAhY4OlYOabh4xDCiFICZYPC2RsI2pIiLkFd6JHmIITKMHwAKOxiKn08t9ecfLsFb/b+WyU Pmivq7m8vbbmCjHhDvznQ+SJP90b+ftunsTS3fcd+tldhw5hnBYcUPdg/k66TEszvjVElRJSWhXp tBtr4HeLOAvMNA57BydvnTZFVeMs+LXWbLectgiLBWcPFqUel1B3VoluIQYEB0Se0ESVkIWhfdeo 9o3gHSdEbhtOWOOcMMI7l3EfxAivGtqwBKN69xknLhaCLxx8dWZN0eL584sK8hYE5Myfbiwv/GTq vKOfY87J0fdEinInfpO+Xpu6IX5HvJgcPzt+YfyKeDnJQz4p0UNelzuBvS5cf/mkOJtF9Xp86i6b FX7/MS0b1pXQlSASwuQxWeL2cRdumwVd45PqvS5PwvPkCrjycN5VuRSXIUIyRIDbxrb5qqF4ON+I BtuKnWdKDGvCMVCAEMlhCNLACIw8PsNJ+7AsmVmZha5gYUHhTJdQ71TjswPFnqqm2o3u+I0bsUcG ItX7vJNS35hcvXh2Lx8fePneyF5sanyHGE80Czdo3/e4cMYJlmL3qyZW4R8tjF+P2cZ2nIoOdrJL 2dLauKZJWdOyaVOjqXlna3PTJfKups0tUsslTdLWS1vkdS3bNovGrbj/a+INuBe+hFt4Mxv/F8S4 AR/9QjXBW9OS6qXLyuZmz9m8ofHiCxo3b265NGduy8Vrwfi/Ipp2iwplbmRzdHJlYW0KZW5kb2Jq CjMwMiAwIG9iago2OTcxCmVuZG9iagozMDMgMCBvYmoKPDwgL1R5cGUgL0ZvbnREZXNjcmlwdG9y IC9Bc2NlbnQgOTM2IC9DYXBIZWlnaHQgNzI4IC9EZXNjZW50IC0yMTIgL0ZsYWdzIDMyCi9Gb250 QkJveCBbLTEzNyAtMzA3IDEwMDAgMTEwOV0gL0ZvbnROYW1lIC9RVFJTREIrQXJpYWxOYXJyb3ct Qm9sZCAvSXRhbGljQW5nbGUKMCAvU3RlbVYgMCAvQXZnV2lkdGggMzkyIC9NYXhXaWR0aCAxMDUy IC9YSGVpZ2h0IDUzMCAvRm9udEZpbGUyIDMwMSAwIFIgPj4KZW5kb2JqCjMwNCAwIG9iagpbIDIy OCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMjI4IDI3MyAwIDAgNDU2IDQ1NiA0NTYgMCA0NTYgMCAw IDAgMCAwIDAgMCAwCjAgMCAwIDgwMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAKMCAwIDQ1NiAwIDQ1NiAwIDAgMCAyMjggMCAw IDAgNzI5IDUwMSA1MDEgMCAwIDMxOSAwIDI3MyBdCmVuZG9iagoxMCAwIG9iago8PCAvVHlwZSAv Rm9udCAvU3VidHlwZSAvVHJ1ZVR5cGUgL0Jhc2VGb250IC9RVFJTREIrQXJpYWxOYXJyb3ctQm9s ZCAvRm9udERlc2NyaXB0b3IKMzAzIDAgUiAvV2lkdGhzIDMwNCAwIFIgL0ZpcnN0Q2hhciAzMiAv TGFzdENoYXIgMTE2IC9FbmNvZGluZyAvTWFjUm9tYW5FbmNvZGluZwo+PgplbmRvYmoKMzA1IDAg b2JqCjw8IC9MZW5ndGggMzA2IDAgUiAvTGVuZ3RoMSAxMjUzMiAvRmlsdGVyIC9GbGF0ZURlY29k ZSA+PgpzdHJlYW0KeAHVeo9j1MW175nvfPdHssn+zm42+zv7e5Owm80PCAmQaEAKiKgIAURBQkQ0 /BAQKdciz3ItamotioBavYhcpVYpINX441aNtX2Fqz6it1yxxdf4q92by7NUfTRs3mdmN0pi3x/Q 3Z3znXPOzHxnzpw558zMrr95w3IqpduJ05yFS9d0kfyM20WkXL2se+maPG76ERG7fdkt6wN53PAV +D/qWnN9dx43/gDPnutv2lSob5lD5Pn1iuVLO/N8GsKzcQUIeZzV4xle0b3+1jxuKsfz1ptWLyvw LWbgk7uX3lp4P50CHli1tHt5vvw4US+wZvW69QVc1F+y5ublhfKsg6j4EWKg+th9VETfJQ0pZKZW shDpPi3+F4yXST7KbH971cC1ppa/MoteNvf41vzzVU/TmnOvD72o9el/AYZWlhclUEerz6GQdue5 18+9pvV9zZH1AXxtw8rtrI1sxFkrlQBOphzgJAkn0mTkm+hFwAmSMl7mG2kxKA20E7Be0uskPUOd oKQlpUbCahbGU8OSEkvQjeDHqQEwJvNR+c6I5IqSnIVkqwHmp0rUC0iayHPmk2W9zENXguOV5USe MzfNAqyQeZesUc6ceGok5MxBr0rMLnk2+X4rXYI6FmamcyhnkRyR58wk8yUSGiQsZkXkRSkBOdPT X6gYmB7zxJmO/hda0uDZDkwry2skVAvlVIlxCRUpUUbjUJbECGgYdCNmXTxFmfPQAlHfCEzkOXQS pelvkn+O/i/dBv45iYk8p6/ICvglfUH3g/Ol5HxJvyQVlL/SUtAEhwPeDtpf6Sza00gOp7+2DUPX VNDkmCSPyzynM1SGWv8t2xuk/yIDag1KTOQ5ZeljcoKWlbQ/059kiT9LTOQ5fUY+wE9pP+An1AT4 MX1EetQRNbnMcxqgZ4U88RQS+KOE/1toGH0o86fB5/QHmf+9hO9L+J9kB/0k/U5K5KSkiTyn/5Cc 9yTlXTpCbWj9XYn1S3giP2d0Qs6AmD9O70jO2xK+RRWg/Lts5bjMH5P039L/FHNNv5WYyHP6Df0a 5TR4it6LPKc36VeSJiCnN4SmU59YIfQ6vSY5r1NEYMNill4rjF9wuNRUTq/Qy3QPWn1FtvqKnM2X 6SVaAJrgcEAxmy+h1ShogsMBxVwKCqfewrh7KQPsBSmX52Vrv5DwqBzXc5j/vHyek9Tnht9GC4LC 6TAdkn04LDmHZR8O0c9lHwSHgy/68HM6KPsgOByY6MPBwpgEh8s8Z1MpDq1vF5CekXP6M9ny0xL+ VMID0A5OT8r8v0q4X8J99LhYpxJy2ivWKf0LzQR8jB4V9gBPIV+R5/QTWecRelhqhoCc9tBuUDUS ctolSzwgOffDYk4E537Z3g5hZejHkn8f/UjqtICc7hVrl35IPZRA6R/KVSnyHLIQc3+3hHdJuJ1+ gNIa2i7fIPKc7pScf5aavU3qxPfpDtA0EnL6H5K/FX3hkCssHm2h79E08LfQAWAiz2mTrH+rbHej rHELbZD9v0ViIs9prcyvkrCbbiITWummOnBEnuPtoscrKYf553QDrYAt0+ApVprIc7qexgN20UK5 NruEdaPl8q2dNFeW7pSzsIyug8Q0tEy2KPIcNmcJfLUGzxpgIs/pGvRbrBMBOS0qtLtI1hLv4NAe 0aeOQusdUrLzyS/t4XzJmyfff1WhxFWSJvrCMeui7hXUKOfrColdLluYI/OzpbZfKuvPknAmTUCN GZL7HeG3aLrMXyJtwjRps6ZKysXSil1UaPsiuhVl22TbrZhXYblaZf0pBWyKbEFwOE2SsEW20yzh RAmbJJwAGZej/gQpyfGFNwgal3lO9bKtOlk6I2GthGlZI0XVKDlOUqS/BS7kUCVhUpZJkA6UeEHH 43LsMblWoqJU205YIuGHwnirmJ+w1NWQbKFSwqCE0hPL2eCQhyrL+qRWeCFFTp4CzSNLuyHvOFpz S0zkObkKb3BJmngbhxcQ/XVIKL0zIhGr9BACckRBZkhaIyGH5hrh6TV4ivUv8hy6lV+9pbKNEsy/ WFECcsi+CG1rJORoT9B0hfI6KQNRl6NEfjwaaQFEnuMrSjOpNyQ9LGPl23pY1T/wh/6x+u7NR6m7 4MsWwrMeh9XeT8WKW5lOm6HHR4A/TE/TG0ox20nvsinsedrBtrNXWSfbLksfRwN2noL2lLBXVb2S RY1nQNsOW3yc/VE9Se9Dd3vofb6HNvEp4GyiZ9hCfhHivLWqXeL7UOZdIrWJN9NOVsxeYifZ++xu 2s/eZHg776DP0d52/jA/il5uV130Oa/jCt60E+94UraBdkHfxRW2l33ABukoOVkXe4aV0JPKLrxz IzsHG76TtrMauo/uY1NgM69THwNtK+yh+J7BW3ZRD/stxt2D9CqfhfLPYLTHmRv9OE5H2Frq5Hq2 FfFijp3jRu4UbcEX3onvDtql3MGmsfsULyIpIYEeQFK/UPfmv0D8kNsg3tlDQXVQfDVG2qC40ROU AbVHa9fOY28qNex59iYk3ak4lR7WjZiGyMU6RS1ejHL3KbP5Furh7yguRCQ9GMNWtlndq+xTuoCV YCT3sl3KQtTaqTTDZm/W2tViyE9+Qe0RI1Wma45rJmm8GPNO/jC7lz9MrzAtufDcTD/hO7XbILON 7ACkd5uQP62F1DrVx9DT1fiuRdqMtjrg487Ao63menig46K36LUTkioWkkIbayGpIG3WrEWstU55 h9ZJuAPS2gS/+wf0Bp8tw+jTLnjodKtOq1ExkVQdMB9UIt/pPNh6eUfg1wuCNdVj0IBZFzhIcw6W bgo8Pzw8p0N1axYc1HgO8oj+oBoJffj/Y35YUz1zTkfgeXbx1PZCs1OXtIN4ZQfegJ8g43VT22vQ M/U4dSHhyTqQupHfg+dePD8p4O2FMhfhKZLAr0a6E2kJkqjfibQCqVc9Ppwr5BfiKcqLNg8hoX2a Dn4Wz6/w6vy+lDCjWnYz8ABWJDY12L9++8NhYTWwvH//o4NtLoK1vvBjAFJyIWFUvnQUdiFiBGJC EjtzErtofKzwKnbsZhzwNwQv5IJVdyPnEcx/wE/eMFYiRvwubOPHTMsmsB+zj5W48k/cyg+pGfUV zWTN77R36a7WHdEfKLqm6OniruIBw59KvlfqKP2dsRNjVqgrt1Pt0uyDl9ORs7VIxTTqNYpKqWOn jtWSuf9Y/7G0zRK0RIKWYJdKQ+u4e+ij3E6d8avPb9YmhNgU1sG7+QbNQsg5RJNbYwGfs8xYouF6 K/2iQn84HAq4K8qsWp/DYizSc9KWKKpD8YXN/dlTWWeTxepswouGWgYyzqY0q4zGeEN9YzPLOLyM G1ko+C0KL3E5VL/TsdTh9KsOV+5Ol5P7Hc4lTocPKO92RdnaEld5uaskd2/UNRpDfxnrzr3Ca9gs 6EBNa0W51WJQjcXkMvLjLoEUq4gSdK4yFzqY79oxa1OTRXRuMhP9KrNrdQw9q4ym2DjW0MLGszP6 Cv/7Jquq5v5LV27kOv00s1lhzkpbSZHGrDvfZ7IqvEJnLTEUabA69mCF1ikpaGiwFTSVq7p36G2z Sa8j1cDN5v4++d6zA3inrTI6idU31gWFPOza0Bt2p9POJzkrfDbW7XKstDkctpVWoQuM7R3+nFex eYh77K1FvL/oRInWTSUYBuR7NpuOoBnZe/Sc7e2ev+Cm7o6Om/bN7rxuzpzrrkO/Phm+V1U1u7BO fK1mXmrvoi6bYisuItWsted7tRgq0ZfWyNFjmsZDJPk2dWybI+b2JLUaZY0r6vYlNRp3Jpzw6stK NG31kbhHby8SutKde5XH4BnKEWO2tUZGpB8xvsUr+z1/4cdBKstPgtZVFtb53a6IuX+oPws1sTQJ TckOZc0fF2Yk8ndnBP2yXTjWz4rKvW+VWjA7Ob3NqC/iF5lMjFdBAqtWLei46WzQWlLEMU2fmI0I 77RWg1ps4Edndy677LJlQi7t1KPOU69BPNDaWq23l9sVr91mKGZYMjrm/EB3yldFc0j5jmml7WtO hRox+SB6KPXiWkjtbHYxZnNxEfMx6A9mIMaisWhD/fhRMowpH1RHQ35jpX/oI1V79UK9yt3uqNEf ilYrm3LPlCUqfOFiE1vHeDKTiasQZ6mh0utOiCgFa5ltU7v4CkTDbkq0lhuPlf1Bd4x+73GUmYx6 HSO9VY24DB5zf4vollh0kGXaBtUSXcJCw4yOxvbzrb5g0De0xR8M+i/IK65YKByNhsNRdlkUuUgk HEEXIKuLIKu5X8uquLxY8ZYVZOVkug+cp3xhupaUaablhq85pkiFClm1YLmNlhVWl5xHJ3M40Ucd 1p1OyE5oHl97PjIuGvKZIh7uVvULO4pVyKy+3BeKjlM2sdmQlbfSUJrboajxTG1CVXI9ijPsq0iU FfqJaA5xwiS6p3VOfFyqKhj2l5mL6poaJ+ooPOj/pGqQUuxMiqWy3qIXXH82D9Tq+hr/RJOsnjJz sY6penVcoDaW8dSWUYydibFY2mdqKmsoVfWpyeahvsxAZqilb/Fa82AGP2HkLNDZWkoNDmZyIi1e O5AbAA1KDWi1SH66Lj+6ZmYZyYwsfGEHYIPzApGm4NuU3lQ4UnVpa+vMmki0hk+sDPliCf/5LNN6 wyG3Jxx2584pdn8i6g8Hw+G4l2/zJyKhRCxbH6++9N7csw2NyZoZvTOT6amh3NS9l1YnmobCUaH/ wx+qO9TXsUva2bpiRnpRepHjRseN6dvSmx33ph9NP5p6PPCio7f+SOPhgCmYiceqwtZyC1kmmNgL U/RM/98T+sqrPsv0hT/1HS5/rtlR72iM1kcb19etH7/PqzMVmUv0Sk0wpdHEajUJMpWYG0rd6Was mP6+oQG57oXksIYGhvA1D+YWQ6BSakKkVqyqSENeWsJKQpWrmEXYaBipAOFwHgbKKc1UXmqxaGwc jLdSZrfWZRr5vq983ooIO1jhCiZLS6xN/7kmdzZ3lF18rn37jOKQJ+WvTNY79ZrIXQsOv5fta9r0 9GAgGPUEgxFP7s/l7rLiyjSbx2z4dvn9Fc4Jy39QG2u1FV82L3f+1B9zZ31iTVyNyGwtdK2WVrdO 8biptthS6i6zFmlJ6ynnac8LpQM1vr5orCaVDES9IaPVwt1lpcVFXEvu2rLpoUu8VKud7jUlL0ll zP0D2bNZ88DZwbxO5fVqRLegWplfZeCrIJi0zqiz5Q11urHBBglAOk6b3dGQtz88aCl4s8LSb1Ys wTOKvyYUUoqVcJQvj4aZQYlG4z6lOPfhnlgyGq48/1ZlOJYK7sl9yI0zE5Gw38xmRCCM3FFrgIVD iZlMHdocDIcikVAkwLcJm6DQncOfqHfyI4jkGuiO1vnf1dyteUizp+wB3U81+3T7Ij+NHyh7rvhF f6+ltMLraiitLaKSpCvBT592MMdQ0Tlz4Cvv6eiX5hPJv9VWWSZae628tmpcQ6YUpx5+F8USc7Tx kK3RfKoPkskMYKnl9SWVHRgq6Au0RSqMWGTpxfDaoUptmd2B+W9w5kWUtzMN9VFwCsoEXbLknVuV DEvax19ft+fQ6nlbTuqveLXrgV/85dTEWyavWj/7l35v9IOnDx6pvSQdjz/iCWtZr9WyoqO9Y9v0 t2bM3r/tJ8+YzLp1q+amIs1XHH421+yLhcOVAejFEsilBnKpps2tV2/z3GvaHXrU9JBxt3Vf9Yum 3tCR6mK9AWabW9TLDNcaVhs6Pes9WwyPGp417PMc9BX7nOfCBstpNfll+ERNu7XdMdc61/FU9Kl4 b7Q3rjfaqTaom2uPx+bVwNCf7ctaCouoL9tnzvUtlvojpDHKpMi1UZANfFM+YlBDldRQLxYS3xGN J/zRqDvmSW9f8PDrL+64eFOjLdAW8cdy7z55MvcHFvjdrN18iRr0p2f2RiL+2suvfP7HD7wciZS4 GmL+y55gjrffZk4ROCrUhfEvxI7Zg7jx5bbZOGfU0C1I+2Vy0FOI359CuaPAxfnVaRExAZbBE7+A 01Fxx6XFiSyBJtpDCATelyh1AtFFOyhzkfYj3n8KMc1TiE+fQo3ngPcC7wXeC7wY3tKDeITQqhW5 IpxsxQHLsW/0ImeleRQekSD0Bz9pjLJDi/sWZ82D5kHI0IcwKFyIhIRC5cVF0hhFglLfmF1/+KEN zO71xZPjOt+9YSA3yCo/O8EcqRWm88uVu01Pbd52lO390SO3RT3etLO2nulOfsCsw3R0QvSOjffd gw6it4ja1c3YETfRb9qmw9PHxLkGdk6MkhgzbvBAkYIALYYTMjPkoce9UhX2CeJEi3CHlJEjroTU /ZCXGyO1QQczlEJLTTgfFmdujZBACaSnQQ0/9uchWLFymo+SKcAkeDHwrgS+CGWvQKkFNNEMez2A SN6cd21wa9+Yp4KJahl0ZgZzEFrBJYoFOf5rZyeWXD6iLKy8EdPELHJljizIArlu0NZel4jtcvu+ c++lD/4slamOx3NfpIKJptDK5dc/FGpJBlO5L2KxVHuPSoF4OOyw5Zrb217an2uGAwz7E3Eve2zD 5ru6ckuEpxQ+Uch4BWS8CzJuoS/axMl7NU1FmoZz7Isgx7nIX4HnHvD3UDOkFZfnnAHIx44ZaQHf BT6hZhytGbDrLcWW2E5xwAATJ4vDqFcDzt9wtqvKGhWoUQOqFl5CaGIY58G1aLsRbRFkbYHEJwkT lxno7+vvE9KjFOK4jAiHIUyxQRHQ2oQjgjYHVeOmpVq0iWczvi1UJShILZKDYwM8XWIXrDNn9dls VqcRzwXpWraYWYQTlXHWBZGImJxIPiSTfhbhmJGZWGEDUJiS8YwdDFa8EIunLk0n5mUSsX9z+xiC x+okM0XjS22GxHWZ+9jmeVWRRCz3f6rjsVjuP9iW3Ml4WkhfJX9CzNL5us+NlU6fr7KypVhRNA3V W3KdAbgUX9AdK2HtkGov5kicDLlpQZsfkgQJNmIYM1ECqdrwLYXu68HRgWUHXcVXnAgYIM05sAEM SVAQD/f1LR6SIpXhGIK0bGYoi/3eBVGFJR9ajCheUAkdWFqbiLEZGN5EOI3UeWhQMsnK1J78EP62 OxgWKgVbgM4N59DfT2DrLmMVbStxyzSBHkCfdshzdqKL0UM35l7o2mWwOEb0ehLuBeqwPsVZBcdK nojZI6qD/rQi/yXsWxLWSuzb/4YT6xDqTIV+Yn7pKjyvwnM50gYkLU3BmBl4M3G/cTH0LA29q4KW hSiA906CxRQn7UbIRovzdEKpZYBXo2wA9zdu0Jcify2444Fdjfrz0aJYBYIWQ+052OucHRjIZswD WP7mwQGpi8ITQyXxyMe3IrxPtUgbgFBFBMYjjhn6DDM6apELDZzELHmfrPuWQchPjghh8tFdHo5Y CKm+/GTd5BnzrZMSlaEtVf725pqZ7khLsjINmxBJtdut0+ri8d3BMiVxTfO0RY7kqku2bjRPToZD m+JRpaZn2e1rcku8sBrxi7xs/+yZ8xvqz58UdiIUiXuVrYF4KOSMVCcnTZ7S8uRLebeexl9F8vZj C/x6M73VNgN6aIQd0GOGq+R9LyYR+DmsaLgr0mM+LZjNasyFuGkX9rlOekRhAwLIObBG7aCJWStF O+KfAc2IpMS/AibAe5UWrHQA8xHG3LgwN3Y5Q1Xg5a20HVZ6AvjoHux0izht+XuGWkzVSMIqGGur L7DUijiOGGWpv7EXoydRkWak7nNY6mQqteQbU51q+aA1nJwIS931MCx1eNrRxkQCllpINhJ02NpH DHUs6EvGfN8Y6qRPTABGvRDxwzp+CNrppKmt9XTapD1d9qXpRHm7rt0wUzOTzdXNNSzSLGIHLAds TzifKO219Nqecz5Xaubxks6iuHVeufDr2fzeAmY0HUFAmO++3cHshLUrwx5Suva88avdu9/oU/41 d+qzT3OnWPjTT1lk3esPPvjGGw/ueo0tfC93hpnfe4+ZcmcgY4Uuyq1V7+A/wUzX0+/b5uOGIowU w921F+fhYaQY7ta9WD1x3G1FsKo8GIUZuiI0QAfaaVBT0BM/maEnTqbisIFThOlA+RLzPxN3fjNh AxbhuQjPJxAb7YcWPYfnUTz1sBsZtGlBm3pYOhPkJGyhsHnVeGslciISEN6lEvbCDv6VKHU5NcCP Z+DH+/qkZ4FKwLfIoCc7MCDcjfhiTyuVBas2H/d846q/WZl5HUEYhAgyGhsl3c4z0Wgklbsknqib arNNrUvEd/nc7U9c+xtmHKY3Vx5qYY13Hzp8110Hnx2mcDgWCIfiAdUoFp29bOm0abkzx9/IzZym PHv3D35+cPtdB8W664aNXY11V0V3tKUwsjhG75GrDnZfyBASjUOuQn5CniOyvh8S24d0BEncKAqZ CYnZIUFTQWZ5OdkhKQNo1fDEfX2QkDRtOEuBWcvCFQ99LbGmdGSUxxjlR0eWjtyIYcOhU1Q2KxYJ pc7fHIsnqp5pX5qOxQfcnmv/feOCVeODzu6q2T+7oWfEnyhb/YlQqMx+YOP66U2Rpkmrb8XYDw1/ pjox9la2qO0B/Cclg3jFAkuQQfRqwf1FM+4tKpDcSB78S8GG2xIrfR925Z9R5hHwd0h/5MbTQw+B vxv8+8HfCf5OWJLd0LGfodzjKPc42nkc5Z6SelcK6aXx74RxuE1thlZXILmRPPDSSUTqNZBsLWRf iRQEpxoRdjP0bgJkmcFbLNKSlUvdNGB+JuDOJYKbmzjWUYS1ovxp1CjHrE0G7wStwdxAj8FpQ3xU jzeUQuPTaMWAdvVoE+fXst0yzOZy/B8kiP80BOnf5PwGsXZSoBLsbZuIqPoRxovtoZxGc3YxTm76 stnF0P285o8YRTio8XKv5HQ4RbwvTEXB6mEFAAccdcQgtlEoiU2A0H65zzwUjCTKzaXJfctW3n79 beOPvffOy5c+phom+yqDgZCv2m9vuPXya9bd8vrbv+w/0nTPylDGEopMP1QdnVBpaWybN+2Slh/e +f0fV8UymQ0NqbqQtbbqytYpjarmzp4795a5nE4ROzLqGB5Ur1N7IZHH2iZix1BK65G+j3Q/0j4k DSyPE5LyIRlhg1KwN9WoKyKAc+D4QXsBlKjcXWHpMD2oJzCLUfikkLRbIt7iyFtQWwcbEsO68OLt OKww9y9GaIoVUth146hxYGhxC4JXbDxHHAyesB3ywCYUtMjN+AUbKHFIA+c/YkrkGbi8EthYW5NM 5m686vpFOZ8nVtt83SNTNzwas1sOJKP1V62NxKoreWdlJBTKHdq3YmXcG6x1xsIzZ4SWdPrZbAjf d7yhKpFZ8Fshp+m4xVqHu8RaerJN6GMEo+bQ/FrojojAfJBDBSinoblRWF+CJhthNyohCRusdAXG XAMNjyBnh3xM0O1v4qhxoBPk6Uc7IkZyYjVascdNwsoKmxuBpc3A/4hTrRZ5EigDpZGASEShYEBk 0MN8EIUQieUPLb6Wy+gzikn5a4mGC9mse+W67oe2x0LR5LtR/7jaKrlfWrJ91hNPlLVnYokHQ262 9nvr71rBHgmGouFg6/krAhERg7fPGP/sz9lrwuJ60ugxG84Of6C+A3lNpP62KYhLdBiLiCcI/xmC 6cV6DUE2HkhB7H2asTIZyuJSAzJQYUnCiE1wtwI5VpMJchwP6gmUEzd/4i6OoS6hRj1aCaF0HTS1 BPgN0M7roc0MORtyJdSMY7AB/MQuyCxOWrPOjPlX8FIQkdj/WCmE3Y3oTRjPOnzryY2c8LIVeOrF OzVy45OHC8SuR1w3idumvNIVDhOxx6nC7bqMdZxu5PPxTN646wpVlCVbi+PxcNz8UVEyEosyQ2PU YbHUBCY+vdUQj4UT5tueKK+amg7XsxK/P5z5sDQWCyeNbCgXifqiGeVkMFYZ9sfKQ6pGPf8kOxL1 xWpzS5QObFB94cpoQDlvEyQRV3yl7OEfqXthDWtpc1stYBVmIYyxin/WCFtqkHeoYn9uZAmMV/y3 MnNBOS9oLkhgHFbyNzVUlEM0CpuoA/0BcMsAddDQ/mx/Nr9Zz98ZFC7qvrl5yctA3oXlb4RGLsnG MK7T2V3PFJs5fx9XLIpON6HEqCjsjM4GqpHzk1pLiaLVjy/FJYy60WMy6HmJLtdcWsq4XWMqUg0a dv+3qLjMQbchF/nJ7cD50d/74BgW4xP/GTJDQla5sgPwBnHIbjx2UtOw45lJs7H3moNVeQVW6FXw m/NxArQQ8ZT4MNSC4uKjhW2gWVfOmT5vbtXFqzfcfMPymwscwb0dSRzVPIz0NNJLSMeQTiFlkYbQ VAmSB6kaqQVpFtLVSDch/RPSPUgPIz2N9BLSMaRTSFmkIQy2BMmDVI3UgjRruPBB+/R1nmEeR+Ni J3ohH/VH4TgTGIWPG4OnxuDCZl7YHvoyCp80Bp88Bp86Br9kDD53DL50DL5sDC58+oX9wTnOKPzG MfhNY3DEj6PKrxqDrx6DrxmDi/8/XPj+dWPw9WPwDWPwjaPxgLzh/394M/FpCmVuZHN0cmVhbQpl bmRvYmoKMzA2IDAgb2JqCjc4NDIKZW5kb2JqCjMwNyAwIG9iago8PCAvVHlwZSAvRm9udERlc2Ny aXB0b3IgL0FzY2VudCA3NTQgL0NhcEhlaWdodCA1OTUgL0Rlc2NlbnQgLTI0NiAvRmxhZ3MgMzIK L0ZvbnRCQm94IFstNjU1IC00MDkgNzY0IDEwODldIC9Gb250TmFtZSAvTFNQSFZUK0NvdXJpZXIg L0l0YWxpY0FuZ2xlIDAgL1N0ZW1WCjAgL01heFdpZHRoIDgyMyAvWEhlaWdodCA0NjIgL0ZvbnRG aWxlMiAzMDUgMCBSID4+CmVuZG9iagozMDggMCBvYmoKWyA2MDAgMCA2MDAgMCAwIDAgMCAwIDAg MCAwIDAgNjAwIDYwMCA2MDAgNjAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA2MDAgNjAwCjYwMCA2 MDAgMCAwIDAgMCAwIDAgNjAwIDAgNjAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDYwMCAwIDAg MCAwIDAgMCAwIDAKMCAwIDAgMCA2MDAgMCA2MDAgMCA2MDAgMCAwIDYwMCAwIDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgMCA2MDAgNjAwIDYwMAo2MDAgMCA2MDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwCjAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAKMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA2MDAgXQpl bmRvYmoKMjQ0IDAgb2JqCjw8IC9UeXBlIC9Gb250IC9TdWJ0eXBlIC9UcnVlVHlwZSAvQmFzZUZv bnQgL0xTUEhWVCtDb3VyaWVyIC9Gb250RGVzY3JpcHRvcgozMDcgMCBSIC9XaWR0aHMgMzA4IDAg UiAvRmlyc3RDaGFyIDMyIC9MYXN0Q2hhciAyMTEgL0VuY29kaW5nIC9NYWNSb21hbkVuY29kaW5n Cj4+CmVuZG9iagozMDkgMCBvYmoKPDwgL0xlbmd0aCAzMTAgMCBSIC9MZW5ndGgxIDEzMjY4IC9G aWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AYV6CWBTVdbwufdteUmTvCxt0vUlTVtC01Jo SxcoNNBFoBYoS23BSEtZRZaWioALqINgQSky4zYqLgi4QdoCpnUBHdwH5XOWf5xFnfnqMmrFcdBR Icl/7ktaYL75/v8l767n3eXcs7/X2XH9UkiArcCBv2116zrQLlsxZr9u29DpitV1mAkty9YtXx2r G1uwvnj5dZuWxer2CgDVvmJp65JYHS5gXrICG2J1wsbLWrG6c2Osbj2F+brr1rbF++2secLq1o3x +eHPWHetaV29lHUAFD2LiXfd2vWdWhWKZmN+9bqOpXF40gQgHoj1XZISLKfBt1ABC0AACgoUwHwA Wknrgccf6xcAlnz04epF5orvdMlsnwBPdLx6guW/Egdbz/8lvNwgS+fxaVmDZx34nDQ5MhOq9E+f /8tPcwwyuEFiHSNXWs+8sS/QpxHSTw/1lhf5Q/RQn5JYyPJeiVWf6kuwFm6ZYqEH4AjeJ/A+izcP YzGdhfcivPFQ6IHe3Qz+QO8iLeub2VC4Fat9V9az0Q70+afFcr0xlssTYvnYIga3v69mI6vv7yuc EKvnjovVs7JxeoXuxzWe1VIzpgV4V+K9BW8eJ9/fl5gee0y2s8ee6EtJLTSfoE8gxBP43BPaEp/w 67HbOkucJdGzU0rJlzjmPi3doqWLtLRSSwu01KylW8gXbHYtPaGlR7S0QEsrtXSWlq7VUg2eDOHv K/x9ib8vyBd+K+QRUImSRxSV+POIXyX9RCaG3mJ1T4gY/KXF6hhXlVqId5HrCjUPcxXvG3Onqfl4 u3Or1VIChIBMKOjA4cBTtFp0/hB59vnIdmN4uxHkEKnszb1SnSKTCTDAs+lK8H4Qb743t0N9GZ92 aVUAF32mVz2fHyKNvepPakhHetUf1RAlfpv6gzqo/kt9Qf1OnaG+lfuM2o9QD/aqITXEI9SjuSH6 jN+s7lTn4OIG1Y3qdeoal9Z1nRszv0Ftw4cW5C5Qm1wI2qvOdGmzXKHiMMfVGuyszg0Rclz1q3eq Rfnao4Xs0ePqOLVDHcPgetW82HSjY2vzsuy4Ogony9RmqVHnG2WjXNr9Z6n7kNR9QOq+ReqeInVP lLpLpO7xUvdYqbtA6vZJ3dlSd7pk11l1is6kS9DpdTqdqON1VAc6eyj6sd/HOMUuKiwTeZbyWlmh rIwJpkCJjsIMCNq4Olo3dyqpC55sg7rFruD3cz0hom9YEBQ8U0nQWgd186Y6g2W+upAUnRMs9dUF pdkLm3oIubsZW4N0R4jAvKYQSWZN21KD1qqmfjzV5G13pbI8uu2u5mZI2lDprLROtpTXVv+HpEVr bKn2XbycF4usVDd7Uz8eelOfpE6SsDoXq92s2s2qzvTgvXVzm4JPpzcHC1khmt5cF9w713V1Uz85 TJ6tqe4nz7GsuamfyyOHa+awdi6vurm5Do9Gg4NKbEe4wyxDON3voZLBQaXu9xocT2JwHg0OyS4G l+QCjwbnSXJdBpdBnsPxIJdlOJ7jY8jQ4DIcH18C1zPgqanu8WCCMDjWgAYzEBsrWMGm7FFVBHFj giDIKqoGohLKhgnWXgTJj4OMGQEZo83EaSuPDcPGwmGMrmEYI1v15cj+32pLp/p8NSsZrcxu6tHB 1OYqXBzLk5R1k7VzNyZPfjJ1AN7nvgSDrzmo90wNGjxTobLS6VMqSIGYEBSxScKbUclEt/OW1AFU B4c06ARsNsa78qfkT2FdSL1sIBM2m+NdzlsmulMHyKF4l4LNFpzjkkV3dl6PFzhrVlaP/NfHr+vj eSfUBXPn1gUrGxY09UhSTdDfUt2MbWOH2wyGmlD0ZKxxDDZWMECOGwEcaZPlOCBi4/isPDJLJaW+ zs5m33pc0vr1nZcszNfJ2nydyKDCACRr9wFI4XPACRD9DO/PWR5ZGf2a9UXWRv9G/4bseix+Y4bX i3ACdkEfHMBfDyiEhyWwCXbi7xX4ArrgcdhDjsJ62Az7sfwCeYmuQz28FRywDn4FYwkXPQPPws3E CCJY4S04DY2wJ7qb2MAAyVAFHdDPvcn9n+jXpJasQXGRCtUwB45zX8MfCE8nCU5hfTQf9bcMr8Np eiWu2wKJUArTYSZcjWs6iOt9Df5EvEJV9CPU0H6YizNvgrvhCXib7KZL6fV0P/emMD/6YBRnwZF0 kAO1sBKh1sMN8CDu4yzRExt5hXzCOfmHIt9Gfozux52PgmKYAjVwPe7mFLwDH8An8AOZT5ZRH53H reMFfnk0KXoU15wOhSjcZkA92h0tcBNsQYw9DD30CW5X5FTkXygAOfzl46pLYQLufwHi6jT8kVhI Mskmo8g0MpesJI+S81Si5fRWup/+ixM4L/5KuCe4Y9xfuI+4f/DT+I38p6Ih6o3WRVdEN0b3RU9E /4o4VcELV+KYV8M10Iq7ugFuhdthB57WQ/h7GPbBk3AcQtAPA/Ab+Aj+irbSv4iJFJKJpIIsI9eR jSiHjpHnyXvkfRqgrfRxeprzcAtw7v3IFNX8bH49/34EImWRXZGeyLtRU7Q3+kb0q2gYsakizrMR o/nQBEtx5m2wBx7AGZ+BIxDE3wD8Ce28vyPmZPwpxE4cJIuMJvmkgJSQ2aSBLCDLSSfZRG4jd5Nu 8gB5iARJH67mZfIa+SP5nHxDvkXMIJqpgZqpSjNpHs2nY+hMupxup930WXqMvoi/M/S39A/0T/QT +g/6I2fh7PjL5HK4adwM7mpuLbeR28Tdwj2D+HyH+5jn8fzMvJfP43/GP8kf4d/jv+R/FAzC3cJe 4X7hE+ETEURFnCTOFleIvxBD4gcSJzVIy6RbpC3SbdJx1H4e3bPQi9zRgzu95KJXw2PwG/IyfEgO cHb6DJlND5J7iYlzwirul+S/hDq4k1bQIKmnSdw/yQayARK5p8g5OAfHKU//QHz8QfIovIictIuu oht5M7mKf4oPk07+fZ6jg3CAfs2mE+38QVSsG1C/riaTsbQcVsMj1A7voFW3DdrhVXhElGk3nvtu yKHTYDyZzs6GnoUvkTsspBKuRT4JkyeETvoY2cx9ThOgkYTpR2Si0AnLUKPfSvroTO4dMoic9yLS Sx1ZQcvJYgjDp+Rx8imdD/X0dniCXy78lvyF+MhMYQXSH/Afc9O5ZdRGX7gELbHiETiKnHAaruTe hKvJPcj9p6kPptO18DD3Evk7HCU38cu5FbjKjZQntyMvPAt93DTeAFPhKHcUXiaHuN8THxzhN5I1 ZG+0JhyA78QD/GGuRyjh06JvR/5MniRnogP0H1AafZubH1lOHuKTkS9vQu7tQAwZ4Bl8/iGUGAdA h6Vs5Me7kV4TUbbJyOW1KLmuhGvIt8gxtyOWSogXZtJMWEWnSC4RXRhpFDwdZZy8BkaTP/KHUD4M +KfM81dOnlQxcUJ5Wen44qLCcWMLxuTn+XJHe0flZGd5Mt0uNSM9LTUl2elISrTbrBbFbDImGPSy ThIFPFUCeTWe2hZXMKclyOd4pk3LZ3VPKza0XtLQEnRhU+3lMEEXe64Vuy6D9CPksn+D9Mcg/SOQ RHFVQEV+nqvG4wqervagqbmgoQnLd1V7ml3BIa1cr5X5HK1ixIrbjU+4apwrql1B0uKqCdZuWNFV 01Kdn0d6DPoqT9VSfX4e9OgNWDRgKejwrOshjslEK1BHzYQetMGNuMdgiqe6JpjswUdxGC67pnVJ cHZDU011qtvdnJ8XJFVtnsVBYArZp4FAlTZNUKwKSto0rpVB3A7sdPXknezaFVJgcYsvYYlnSevV TUGuFceoCVp8OG910LF50HmxioOjVbD90t5UrqvGudLFgLu6truCjzY0XfJsqpuN0NyMY+CzNLu2 pasWp96FR0WcBbg4tny2ldimlnpqWEvLta6g7JnqWdF1bQseSEpXEOZscvempPj7ox9DSo2ra16T xx2sTPU0t1an9diha86mvmS/K/nynvy8HsUSw2aPyRwvJBgvLSxFTMf6tJIGzkp1c0bQSdiKPNPR +gi62ly4kiYPbqSMJUvLoKutDLGOVzPBp4JL8BhWBuWqli5lAmtHVJKgkK14XF3fAR67Z+iry1ta 4y1itvIdsE5GHCMEFiStw+WgzxfMzWV0IVXhQeIaJ2v18fl5G0K0xLNOQcenBNEHs5vwseYJBYhz t5ud6s6QHxZjJbi1oSlWd8Hi1F7wF6DdRltYz8nhnsT5rGfrcM/I4y0eJN+jzCuBxKAuZ+RvVpJs NSsmBEnS/6N7aay/bq6nDk00V01XS5xU6+ZdVov1M4Qi3rAvXgraqpq4VMpIG0s0ldN6kRKvXjAC gpWmhCCfjX9Ro+QlIUmHpKi1EFdtUGmZFkub9W53nFH+fw+Fot+wp7Ts4mPxbQQn+OILjS07OPGy +mXLS+ji6uahoKF18xZ0dekv66tFEdbVVetx1Xa1dLWGolsXe1yKp6ufPkmf7FpXg8IndqKh6MDO 1GDtrmbcygoyAemWwtQeD9nR0OMnO+YuaOpHD9K1Y15TLyW0qmVqc3M+6js8MVqOeq4cxuG9QWiE Zv6/ISC8AY1YXoh3E97d2FbIr4cFeFfjfS3CBjAfz+rkDZjEA9RiXiI+DVVxmCX8+uiXGMepRtj1 ON4+hGEXxgu0PAEnfxlLLrSyYi1a82UJc3S5y1r+90p8eBaVwpHZdTGuFAtOyVrrcKIfLmi5ASN5 7DKCCcwY7bJg2Qo2sKMOS0LtBcy+R9uaXSl4p2qlCWh5boDdZAI5SAvRvpvGS/w2oVQYErdJJukL 3SPylfpU/SHD3Qn5CQ8bG4x/NzWbHeYufBaVEwug4WI5XOeMHkpeIGNw3RIt7QWBD5ExRznQS6xw jECyThRYPwWOVPXJC19GZ+z7inDFTOVcRX24AiqxrFzAZNxYt8VtycYEIwZwwcWdvOAX4Dy4+JMM 8+MifyAr0FKQYabfkiWNl6gkypyOFzgQr5VC9LZeGbgQfdBvpZTUgJ47QmvIEajXr/6UzXguPAiV ONOQUvH9kMVRTqzloLw1biwJFJUWSaIolZaUrvW9m525u9VyQ87pvsfuNcxyh3BeZk+twXk5SD7O xsVRQ+RcHz+BDXtuCCqHxo1lQ2zwnc47fZrhpBmxMwk9KCtGIb3wO/8VOS7FUpzIkvLMlYlvpL2R ztu86WnenESbQcgabbB509LTM4CgMUHsNrfXO2oU8KlpbtLi5WlGuttrBZ0jVxei9/qNplzImpXV krU1i8/KCpHf+TPSZYJBrLQ0OT39RtmMsU6kvNrRaFqDo7aBBTIqiG/zTOUbVEoB3+b6f2COTQWa S+zbrHzL2sNsIxW+MFRU+s5harGWF1Qo4YrtwhjfzcopwDqxWB3lUgUeEwn4fEXEXejIoIl2UUpC A0YUPdhQMr44J8fj5tyFpZMplj2oOYrI6zdVLN4+Y9udN2zY+cldkcNk9O9emNB6R+TNITJz25hA 59Rbj0V2CQN6y/y9zZtCY0c9vHLTh5u4aTtum7xg9Pm9slJ/S83yVXgOAcTqNMSqDM/4S1Si8qk6 rogrEaP0vMgLOhlvg56X5TgeRcGt00kScLzbi0JD9oJOCpHr+xSRiCHy6nFBUHjuVYpFv5PnFfnG TkKIEkNfrR6RV7vK6WOIQjoN+CoCpD6MFeXcoMKywQBSk48RL8NZHFnCdg1ZiKjyYUQFEE8SIgTv ACnk+j1hQyvHeS6EdwoDByP5B8PLcWeNyPQ63JkBPvLP4GWdTuD0BqqXeY43JlCDYXhHkpShE+zY Let5zq3XU4MoCJR6CTWwreIORVGWpBt1siDgKCHa5fcYZUplg+FGjHKSEeJIkAkIOqQPnaP2WS3U pVRggGSYGDTq2KyMEMpmjXb+rZVtnz01kjOSQf4aJpntY5yMcoapRlIY5RSRIs5tKyIem5trJEW/ 2kJ/2HIq8u6p7rC8RxgI76OtP9XSvnA94/eFeN4sDmGAH/xXWVF44JmjfkwV8Yx1er3AcTymBnoR QRzazXyGoLcLgh45OkPW2RFUFJhRzQnGBL3McQaB1xDm1UmgE0Kk1G80dlxy8v2kFPDctROfqXyK B1zBjhnvigqkf207uu31Y3wCbo7tUYc5Hry2WUlXoauQFF1Fj0ir5jX5DaIzwVIsuzDhQtEzfpPB Uiw6rd5imSXY9HEv5vHYUTNjLOhAXX+U91qdxcTXzNBF3IR4COEWksJTe7k0Yg9fRf75p0hz5PQS xNhk+mr4mQu/pJ9FvotkoWRGnxuEXyDWzJACv/SXHeIP2miebYJto+1OK29SUsw2xaQkptqoJcVs jhOWRXEbTSZITtE4xYx0lBIiJ/yZibkFYiX6uy3iOnGrKIor01T0y+kIl6y8iKjvA/VhRNZlHBGu iDNEXHqUl1uG2QIYXxQywWFCKY4Sw4bCIy49mkgRXbJv34oZ7Z1T7+qO7LlpH6l6MXht2bI9kR3C wPSeNQtf3DzZ7A4/R39sOBCYttCHtNId/UxYJPwGfbAP+iEv+nGf0VKcy2LRTiwkMPx3jrltNC3h S3Rlbk4uITzrLMZOtwsTiSXZBSX5PzdwZqMhN2+MmDQ+vTwNykl6ehIh4z35SZyYP14mN0KITPQb R+W6rGOt1GxdZ6XWEC3qK5Nzx2G8zq/Hqca9kZ6b0pLGqkqmt9iVNjaNFqSdSfs4jUsL0Z195W9W oeb4LtCOkvacb0j5PtA+pOmRyiFkIUt5gTKoDDJhG5O0vgAEUOD6bKWSPSmpiAnZUTnslzO+uKSk SMOiJBWPGkM9mZKYaE9yaD8mlHlPZlb3STrz6E3B/nGFHz1X2XbNTWfv7ft+LXnJYJ+3d+GjzdVl 04t/9UjF7MY9UXjyxwjGV6xF8++qf7Ctpryspc475YHF7cdbNr65UE40T/ZMmlc0rXRhyfzR6Y21 3vH3tdzw1poPGKcWIs05keYS4Wl/1XTDAxz1mr0WSjleEIjZYjGZTJbERGOiPcHAOwhjRoNgslgy iGAnRBAsDmJKEO4wuFHY2e9A7R8iJX2J6A6+RO8FEylAC4ag5jOYMbRUgOo1mBTsJ+OQS5lkrh9E kYxc+mn4EzQkPrEwDi0vR0G8/WbUWnGGZSwpKaaK7Yrp1CkUQxBgWp+gxhc9oyTJXeqWiCiVFLml Qhv98P4xvkD22AnlEZuH+6flwtCeUXlGTvXs5VaHygoMKCsOPnCh+bk8kQVbYEH0c76En4yxwfHw ir9hYT7J1mcbPAnZeRPIDCIW6Mp1V7mXu/nivFwDX+DNMXJmyM7weH2czagvTPH6fHl6o12vNyZl qQ7imGNTU6QcfaHKGRxN5iSSFCK/8mcUuMScErMrA5oUzzoP9UQz/BZrMWQoGWszuIwX6UYk/BxM GUo+Dfjqvw8MKUOInfowltBAqawcCgcGt5vG+ExxZV7OsMRQxegsTmpIZtmoxzM1uiotySrVKM2T KUqjGJ2xOIXEIYE5PDk2tJdMqPwZOZZwyjWH2/YebbijdRKZPyNxTOWmjj3u58v+2f/a+qbkiWlJ z5sn5Vy17JHbpq5sXXCg5WcNdc9tb75zrjXBlD5jXGVW4dKA8siha2rXzV8X+eGWWYXXFJNPzYps 8l1TfuXiRU8zHFcjjpnmt4EHLviXpbhMluIMlvDuWdnXJ3ZZnrL0W8TRloLsyuwrEhsTlyWKm92E s9oTM224SCuXlsWJqo1SD76XQlsJFQBwWaoqSjYv6J2q2SC7rJVpBNIK0irTZqWdTRPS0pgETADU njbNvLLZkCr9yfJYQIKshFmwiL0caMzSzKzGpf9mZnWgnfVXZmex1w6oVk+yckyNBtpRwvetS8Mo faCZaKfDpGZ4EIXnv1tb25Fc8YoRrGZ0ocHDWB7lJocHNUqyoUzAM7AyYwsPSqwmhcdWN+668hdv zN5wy88mrXw0P3c1ua110b5lty5avL90NKqMc7OmfPjbu77Yt6hgbcdb5Gjmjru3kZQb7vj5fQ9f j7i+FnE9Bek5GTLhZD+4UUzKaLeqzHhNYkKzCfEui97Mnc6dybwz+YoUKsGx5NeSMa6aZ7ghZXsK DwwWUlOAsxKLOR2yFPT6KWCodzYW8D0Wn5qSZ+m2Poqy08q71ATJofIGFKP3+FPtLl2OJ91l9jtc xWBWzOvMH5l58+SsnMmMtr9H2o7RNbL8kCYuA8x7CAfaBzW+R0p+y8fEZkc7E5nEwUQgE5TWLA1r kpsJSEQYcTNtgyjjZgdzImdf2vDa8scI/OLl/zZd+Ja/sy1wNJJF55EdqzpPkJXW279afWbbYXLF vq9+PXOOmvyLhzeTzWkJO/Y8irIPrVKuCjVPErzuv9YjES8ZbSiXPrJ9ZBecJMdaYuXwtTHHJ3LW xKQkC5ZBSDAkcAbZZElK8oCAJr8wy0RMLpnYaR5nQ4zwnJiEdGnrtHOdCpqu1s7ERDkpqQlkHm1U uQBnhRC1H3XI7+xCuotb8Mw8G8TKsNU2WBAYLBg2UpmhhtZ85VA7I7FhIWAtV96SBDTMYsYZCbSj qimyeUqL0HxHhpc0mpKKJA8XeOXx9MdVZ9H6tprb3VdPHl9qd76d/vYr3IO77mtfMiX9Eef4to5d F/CzEArjI1dhBH0y0k8RSe+HHNTGSA+oHbW8kNFQJePdcfZxlHeWy/NzluZsHS9k+8aOp9nW7MRK qFB5NA3yHA69Ptlr9DqTkz16B8pIfE8A6N5S3P3d/iJjgWqXnF6H6FWNelFNNzudcnJyk4xwiC3Z scVBVEeBY6vjPQe/yEEApWuIZh+VMQKBSvw9fxp17XYT92tKTqWegJ7oi70ORe/QF+tzFiFalQp0 nHzKyUA7+RSl6CdK2Lf520CgvYMkIyvHGfqMxtcayrEpuQCcjCw1M4jpdU3kMkPRpyklk3JKF2Pm dk2jOxwiquqiQtRDqIiY3LUicztKizgT6nJGtja7Q1P5Mf420QnP08zscTP3TyvwWu/a99gHz3x1 83+1Zx34vafjnW1b+xd+lpixtro5uHrPqqk3rSptsUyebEmaX36icffQB30k74HXD5+PPvXSiqlb 5iTTuatL6xtuJuINt//yij1vMy1ejXH6iShlncTuv+EKnuRIRE1QjVQm2brppFZ3Fbdd965FWi5t 1m1GifuC7gWLyBt4E7Ub0IrjHE5KnU5PzImVExI8RsVuNCo2lLJM3hqRomUZ25uM8m6FKIpcYKw0 bjG+Z+QV4yzjIuNaI280hujN/vwU5rI4nUjvVlS25N9FbjI6L4oRnRejoxGlAl5x5yXu4nYwTmCO 7ggrjEjeeE+sQzvDmMnKBPDQMGdgHjPmTTFfNxAIdECgndnicdkrcR5bXHyIEsdE7vVLD1/9s3tc tx/bnj6tenHv0txFKGhPL56/s6Ps3vBd9PZdWcVTl/e9ESlD4p2ETJKFeMbYCSnw6w9yr3Ofcd9x vMwMxisLyopnyVvlMzKnygXyPvmIfEKOyiKGVXjCISqBcF4qSR6e2FlLG8OtKIiSl9cj1iRpDS8r GtZQjrABnTjgVv4MT3k0oIr563WosPg44uJxAV+7D8kYtdIx3l8/plJ7TK7MqeT9k7O1Wl8dVthg pilubLV7MbF6Yl3pY2N5WkEsd8RBZTsDTR+ltfYmuyvZQY1czf/jjOK+A2Md7STiTCMJl0gnXzvB OAuxoVNU4zvqi1R/eOxDfuj06fM2Puf8HxkN1yINr0HcGsiSftBHv/GPNijFLsEvLOSv5Xfy9/MP CpLMEzO+zHxM/4n+O72wUv4Zd594muPjLptXVtCER09Rx7MPxXhRB3qdESSjgUMEG6hiaMLYABgT mL7BUAAGBZgJpVlS5WiHVlayqi/VPxtNpBFH1UB5UeDwGxmDIc4hmq9aFPNVZZ2s13kk0S5hRAvf /6ACMCYgb7GzFXjRwHxVPX6LFPL79HxbgUCEXZUaz3BGth7Nfb1olDQm4AIbUTP8j+DFTCWAftrQ Ra8Wgz0VI6EdtJlHfNmRQtxcZJtF55bZ0boKdFSRHwhqWM0/LUL/lJO4WlJ09GWqnI1MJNbXf/vn GcLAhfXkx0hneBl1vxx5mJ1OCVJ+ukb5Ef/8FoHMErYKZwROR1ShQNgnHBFOCFFBohgfiUkRtn8O 5QYSNsetGRYHVnzD+h7QrXAGmclvQDt4BR+zwpjYRsJi7O5r74iRNPid1kpgxMtIGhhJazVTWinW kJSBkTJr6nNjC8uRhGMPIAkDI2GtFUlYy5EXWP48sgL4PdbL6do3TNgjsmdYwDDpgshktkl7B+IN XyMWHou8Kwz8VIuYqcII0FbUmblkun9SrYXk+WV98b68Fzwn8t5zvOX5jIoPOB7wHE46nHkk7wWH WGNq1M03XWVdZtqSJ8okU5dpGq8rMtXqxDy201lGpZgbnUtpbi7DJHEp5Wg44AmkZ2R4VJfdxRpc BD+HM1utHpvdbmcNdmKz2bNVMVlNSNBktpirZjADOS9E3vcb7WbZ2mRXwKbYKNrCq/xGNV3JaEJl qioqxU/MVvlVoEousscltOhDWnQpql2xMVkdizsyk3g4rDYcVcN4C4nF12KlUxhiY6jDKy4ZMHA7 hPEENOuY+cIiLpcXsVGKSWwfSuyADw2ZIkkT2I7/KLYvFeFVHx7LXrov0LYtsaGvbds2x+5j99im VjQcCniuO3avMqW4/qlrM1fyOUfaG1des6Ttlo5x7eF59OXG7OKKxfueDIfp6elqsX/xkccjejxL pkfL8SwdcNY/W4tTe2iWroTW6hrpVQnL6CbdRsvTlhOoPn+te8ti4pIcKBw46nBoZ+VXytdpZxVX oQo2dCgkrkm5EIn40bMmojfBYTSi1cJUIYqG53sTmhTM/KhUyUWF+gK9GS15SgZ6HU3oVg/4bZec jfOiCo150mH0pdGSDg9qGhWFGZqGvsoKSFYG0a5BCo5jnGlILMZlA3NStNDVRYwzR3EEv6ghP9w/ atVA6617U7Yfuytxes3OD4qW8zn9q5fsun7ilvDN9LHFBeOnvvnPiBUZegn6H3MQeyZwwcZ+sKC1 OBetxVTm7o2SSUvmukwqCqmJ9gyu2b4gsTGjUV2b2KKKVQLpVDbYb0zZnHGUE9JUXrKqBoPZBf78 gmLIcSe7QFKkdfjNxvrMHHTXmDOh+RLoUWi+REyooYGHO7MppWiIoZdFNfehlLkMkynzh9EiNtEl z9/33ckvfx45e99N76w61r12QsfimkR1z5r5u9rHk72k9NeHvvn185HXDl376p57f1nQcuMVbQu7 9zU89B6Kv+iXkZX43c5kfEfjhp/8mTVqI3+NeUHiKrMwIXG8WsPXm6cnCtn8GLMvsZSvMAsKvqDz N+Dm0xgGmp0bySbnneQ++MEtJjtzEsrINLJcWeEUdW5itVAu3UEtlrj4VBRTesz6Eh0qhh69YJJd KZCyKIWmhKjbn8W8W9liQUNrh2YyKEi9cKUMmV7kWgdk6t9h9tWwIYxylRm6jD+ZeXWJEcUEbgC7 EJGaJaWlYQxkxYUeUzFIJUgkmt2LcYYAR+LMiThmMYdRXNzUHbZ0E0nRQTWwd879b655dH/jiZUb eyzJHXUPnby1pWbD0qmRlcJLP2+t+8u7ByJnD8x8NXyCm37DmCmzyaLnt++dvuf9GBdyCxHPZjjn v1Hm7pD36vbIvGhMMh7QvcH/nf+JE3Ooly8jJXQafmp0J5FMZsrh90TmOPbkJp1oiKMPQ6JMCZnN TeA3KcVaLN2Kgg3GohXHPJIW/MrlDHyDIYEYf3HQqGg66Z1+UoFhmbha+pZhCeU/2lr9+KXdyT6m YZjElk0O1CbGpJiKyccKtvZmxLWLplQQyb5hR8OJszBMx7A9bC/BMJaRiIeFX8yH45AFH82f8/Cc klkzCsoWvVm+gM/54MYNow5l/jYyFMHXDwTWR7+m9wiHIAV2+HNnmJeZN5i3m+83PWA7KAfTTqZ9 bkPRRvAVmBmshjxLAmoJzmD+xoLyqFfptA6QCNhoap+9SU4I0dReY6fhRZqKSEsFGbdnyMpDpCny bpmTQ3R3X2pZH3slF/CdG8T3KWGWag49+vKVlnLmljKBko2R4cxR6AWVMpfUVsoxRzTmv5MvM6ZM us4/NuXW3em7S99r6M3oudGRnVux9+eW8d4azy105S4i3By5ZVf42LokVybubx9q2FI+B1JIoj/n k2RiTvsojY5OviL5Btsd3FbDHQm32bY5t6bcJ//O/pn8uf5zm4kFcPvS3cVaILcK7Uj8QsdkwW90 DKbEJIfD7kxOSXEwc03Usw92kIxTwGRz2K0Wi8HgaMPXMyimbaY2uz1FbEtBf36ALgE7Xfp8SprD kWJtsgyQfjDQJX0n0fcMkf4+2kSQL5f0mXG5IfKKXzYjVyan3oWm3ExlsL3++/ZPFQzoRZK/d4aT Z9Ysrf7UWa98/zXKaXynqQxVMHmNmeYNYWCP2aQY8LwZA0ha3DOWasWLCeLZ5wu0Q8DNFdlsSagq S21FLMcMzbqcUaJEiGnt4bE2fLOSOyb8mkdHC9sHj4V/fBFfTY4ui3zG50Q8kXMZC5etXkpzw0Ob 3r7ja/K383+kayccWnVT+F5GWxBp4G9G3Nvhfv9cV9JYgz/Bn7RdL8gJBiM66vpcQ5lR1OlkfAkh AUkEG9FxZkUpkkxoEZuMJr2kcEYdYl+vl0WdnnPZkBMVE8G/Sd8kkwF6DyQSrgcRpQwWDBUEOmJB Tw0VDBNapJOFP5kvzqSR9jYTscOf0rH3me0BS2ncD0c0JDnQPGNCyVA2vjQzr3hCT+9sp4X86aXw wsX3t1VGlj2tJLsXruBHhz/bt4+76nx9sIPFPSB6Du9RgFv+D1catnEojSz4fdlo8MEYKEJ7eBJa CzUwDabjt6J1+JXZTAwszoYG/N51Ln6hdpX2DScbjOC7ZMQjXiJG2WFu1aw5s2f7pnSsbL0uf3pn 63Ur2+rnwf8FIhZnSQplbmRzdHJlYW0KZW5kb2JqCjMxMCAwIG9iago5Njc0CmVuZG9iagozMTEg MCBvYmoKPDwgL1R5cGUgL0ZvbnREZXNjcmlwdG9yIC9Bc2NlbnQgOTA1IC9DYXBIZWlnaHQgNzE2 IC9EZXNjZW50IC0yMTIgL0ZsYWdzIDk2Ci9Gb250QkJveCBbLTUxNyAtMzI1IDEzNzkgOTk3XSAv Rm9udE5hbWUgL1NDT1JQUCtBcmlhbC1JdGFsaWNNVCAvSXRhbGljQW5nbGUKLTYgL1N0ZW1WIDAg L0F2Z1dpZHRoIDQ0MSAvTGVhZGluZyAzMyAvTWF4V2lkdGggMTMzMyAvWEhlaWdodCA1MTkgL0Zv bnRGaWxlMgozMDkgMCBSID4+CmVuZG9iagozMTIgMCBvYmoKWyAyNzggMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDI3OCAwIDI3OCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMAowIDY2 NyAwIDAgMCA2MTEgMCA3MjIgMCAwIDY2NyAwIDAgMCAwIDY2NyAwIDAgNjY3IDAgMCAwIDAgMCAw IDYxMSAwIDAgMCAwCjAgMCA1NTYgNTU2IDAgMCA1NTYgMjc4IDU1NiA1NTYgMjIyIDAgNTAwIDIy MiA4MzMgNTU2IDU1NiA1NTYgMCAzMzMgMCAyNzgKMCAwIDcyMiAwIDUwMCBdCmVuZG9iago1NiAw IG9iago8PCAvVHlwZSAvRm9udCAvU3VidHlwZSAvVHJ1ZVR5cGUgL0Jhc2VGb250IC9TQ09SUFAr QXJpYWwtSXRhbGljTVQgL0ZvbnREZXNjcmlwdG9yCjMxMSAwIFIgL1dpZHRocyAzMTIgMCBSIC9G aXJzdENoYXIgMzIgL0xhc3RDaGFyIDEyMSAvRW5jb2RpbmcgL01hY1JvbWFuRW5jb2RpbmcKPj4K ZW5kb2JqCjMxMyAwIG9iago8PCAvTGVuZ3RoIDMxNCAwIFIgL0xlbmd0aDEgMzQwMDAgL0ZpbHRl ciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBtL0JeFTV/T98zl1mX+7MJLNktjszmZkkk2QmK5kQ yA1J2AImyJYgkbAIuJUkLAqVEheKgApa61ohVnHD/hjCYkAr0aqtC5W21mpbBS1atdLSllqtJHk/ 505w6f/3vO/zPu/z3uHs5957lu/+PTes6V17GTGRPsITZenVi7uJegVOE0Lzl65bI2fLUj8h2t8v 715xdbbsvo4Qcf+Kq9Yvz5blZYQsfWHlZYuRqtd5xNUrUZEt0kqk+SuvXnNtthxIIT141aqlY+2y DuWFVy++duz95I8oy99ZfPVl2f43PYy0uHvV6jVj5QKk13X3XjbWn7YTYm1+zXN7wRvXbL8r2wcx RSgh/yB15AGiJRyRSJLMw8jfF/5CRJRZu8jtOJuzesEia92/dB42DEJ+/Cf/8yz9mfbam79cM3yL RHQWFPVqf9aA+7ShkWYyXyJfrvnPSSn7JtZy4So5Qubwnx7gi4L1Dbn8adLFf0x28x+QkwgCkVAj IVeP0I38KII4OsS/d6C5uVwZRJooVdOBgsLyI6xhIM9X/lP+Pe5JEidBVJwccHrVlncHJk0ay1TX ZDMHikrKTzYY+HfJ3xA4/l3+JCnI3nWgoLT8bIMZFZT/HrFSSoKkn3+HZBA4ovC/P5AfK999jH8N 7a/wL5Nl6m0vD5ht5Xjgz/mniJ0E+cP8obGWQwcstnLSsJq/FWsyhPgEwimEswgCWcU/SjYh7EDY hyAQK+IgQhKhldXwe/m9GOce3G9FnERYhbADQcASPoH6K1nMP8ZfQcK49xb+TpKLdDv/AzV9GGke yj9GfQDpgyizdPdY+X6krP2+sfp7UXaifM9YejfqvSjfhTJLfzhWXsevVe9bM5b286sHAkGpIYB2 GSGFwCN3J3J3YunuRIkgpvyN/FXqCPYjLccTr86m2LWNA6GIukcbD7g85f1Y0o1Y+o1YuY1YuY1E QJ/rLvS5LtunhL8Ofa5Dn+vQ5zqsSopfjfetxoYRxBKCjMBj3Vdj3Vl9BvEQwgkEntyEeCdCPyvx 12AdCzGqrfwVAwVBANuKA2mlvP5pfjmWWuGXH/D4y3d8XdIbGCAuP6C3jKVW1vcyte9lB/QmVnvZ gTx/NkWvKxss/FLyXQSO5CDOR6hEaEIQ+KUD+cngUf4icrWOKJbgJm4Tv0nYJAqpJmo/xpeTNmBg kNj5ElKHDoXBRXV0XJe+W9+n5yW9rE/pFX2bXlzFb+J38HyQT/L1fCu/iBcHR4cGtLUVSJQpmtqK ncZ+Y8Y4ZDxhFDOaIc0JzSnNWY0oa1IaRdOm6dJ0a/o0OzX9Gv1OzU4t12XsNvYZeckoG1NGxdhm FINa2t+wmV+CaRLEEkI3wk4EAWu8CPUyfynCIuzGIizbpagniAlKEsIJ5E8hFVGyop8V/ayotaLW ilqCmLW0IXQhdCOwVs1XLRfuYf3PshaEOFoteJKFcHiOBfXIIUxHyYySGSUzep3gzmOEEmIZoQ2B V+tOIQeoQXyhLTXW3oVUQ1j7WQROvY+1KQg8d15ZHB8qpJlC2l9IdxZSpa6+oVwJI7Lb7Ysii6KL ChbtEVZFVkVXFazaI7RGWqOtBa17hPpIfbS+oH6PkIwko8mC5B4hGAlGgwXBPcKOGftmHJvx+gxh 0YxVMzbN4Mdh6w4MJFLlahqOsvTQgCevfJy1YTy3D9NZhHg3wkkEngQRJxHqEVYhCNw+xEHuJ6j9 CWp/QloRFiGIuOMnuN+KmLWzNla/G0FUcyeR477VDmbIPTlQW9HaMB0kdxHCbgQez34S9z+p9s7m 9qn1GcSn1PpWxKx/PwIb5ZNf3cODwC1g40AcRKhHWITQjSCS1/n5YA7z2ZMRBxG6EfYhCPwC/Obz 87mf4Pck9yRfrJjLcoPE6QS3sdt0UoPEmQADZvqYGt+jxlvVuF6N8xXLdPNn083PTjd/f7o5jgxX QBpww51qHFKMDeaDDebWBnNhgxlPc5EQMXO5aqxhMf2LGl+kxsVKTsj8Rcj8z5D57yHzAyFzT8g8 IcTu8wF3zVyOGhtZTO9S4+lqHFOMQfNLQfP8oHlc0NxgprsoxkAmqXFAjb0spv84aG2yEv3T9B+k Cc+jA3WFwUGOqAkdHahrCA7SkYG6KUiGB+p2IfnPQN0Pgs/QL6jK0uhnA/mngw259BydJoDF0X+O pX+n08helM8iXYH0EVJHo0gfHqi7nvV/CPffh/KPSVjH7nuQtKn376bT1PoHxu770UDxErz1/oHi 9XjrfaSYst53DxSfRu0PBoq3IrljoPgqJDsGomyAVwzUFQUbbHQFyedY36UkyrGRzBh741Q8+SqU p2Rvbh4oZnc1sRcM0saBSBmSOBvlMzRC2tTXBQci6iT9JKIOzkci6qC9JKqmFmpVB28mYTXVDUSu x1M0B6Ong/+ue5pNnPyLWgd2Bf/0DOY3D8X36bSBvcFfHWHLNRB8vXiQRg8Hfxl5Ovhi/iCdNxAc Kh7UoeFY8SBHDwX3Y5Ez6MvRw8F9xSuCP4morXsiaMVW764rCd4fWRC8N4ryQPD64mfYMMjVmPE8 NHcUTwzOqNsbnBwdpGhW6vAyxRCsjfQG06iuGaTTDuwNluUPsqGk8Iy9h4NFeGMsog5l7rijXBXR 0rVKsXaNdol2nnaWdry2QluilbV+rU+bo7PrJJ1FZ9IZdDqdRifoOB3R5QyOnlISTFzL0ahSmwZk mxJBzUsgjRQIqEpzHNVxwJ2Mg2/hWmZPohl7C2mZMykzLtEyqB29OFOTaMno2i5p30/pbR0oZbib BymZ0z5IR1nVZm/G3th+hFCa3Hyrl6XXbb61o4O2ZIaWkpYlcuaz2ZiHYdaCjBiZ5CbOdfXuevtE W3py0/8SdamVXU2Jry/311nk3P7MXS2z2zNP+Dsy5Swz6u9oyUyZLS9sP8L1cKuam45w3SzpaD9C N3A9zRezerqhqeOrbiTMdaMbqWMJ63aAhFk3EqYH1G4z1KcBTMPNTfvDiFin5+k01gng87zaaYXa CTDew57VxhJ04wIkX31WPhdg3QAP2YdZv/kwE6FW9WFWE1Ef5mOd9kejeF8xoo72/eOi6LA/Ok5t 3vt1c0RtPkI7COtwhERph/oeqr4n+4iCbB9AwVgfToc+31rG/6+Fyyb9v3gCPbD4j8uWNl8Wae6K NF+G0JXZvm6lO9O3RJb3L/sja5AzfKxrydKVLF18WeaPkcuaMssiTfL+xep9/9W8lDUvjjTtJ0ub 57TvX6pc1jSwWFncHFnc1HHgkU2NLd9619av3tW46X951yb2sEb2rkfU+/7rXS2s+RH2rhb2rhb2 rkeUR9R3tVw8iba0te/XkUkdjdhAlh7gjAbgQ5c31DHJKXVPVJFjfMj9Pe9RgYBtGRMdGVNkUsaM wPCmpKGkgTUBO1mTBdXWsSb398aHvEfpY2NNEqptkUkkQdzNlzd99W/16tVrWFi7NoF4zVrWiAyQ NjS7JTN51oL2TF2mrjmjdDV1ULZra8euxnZFOlb3eh23qm5T3Y663XX76sS1aztQbT8Wfj3MLQqv Cm8K7wjvDu8La1jDwvbDSt3u8N/C/FpAE12Dq5m9Cq9Gin+suGYtBrN6NcFLViNkX5dYm2hsbwiT pZB2KSTzEuJAiCBUIMxGEMnPEP8G4U8I/0QQyI2If4DwEMIBVsOX8CXN7sub2Bs78MQjxM2XH0hV ldcMIl28PJvOXpBNmy/KpnUN5W60D9RXGBqsELwpOYr4FYTfI3yC8B8EkS/ny9WHY8zs6lhNVico VougsIZFqxNraAIZypZ7zepEAh1YGRUoYW3V5UV57CJ09VqCpcCGIEEntX41uw3vwL1jF2sAKRZv Q5hBggg+aFdeQkbfQziN8NHI9NHz4pUkMnLF6Cnegc4/GQuERMldZDfJJ2dpGXmeDIGSPwJRp43c SaaQ18k+YiHr6atYzQgkjMdAL4Kg+5OJi4rkXvI2WUh6yQfkFLTmFvIuteM5zaQbWmN69GPELeTm 0SPoZSCN5H/IUXoVnQ27QiOZyhVjJaJkx+gQcZGC0eOjb6H0APmA5o/uJ1OR+5DYIJ1vIrdDjb6C vDLKrCT5ZAl5lF5HP4Zs1UW2C5XCttEryXhyiPyWtiA3k6wX39IfgnRwO3mIuujQ6MnRP5NnwUsv w5NuIDdjxANkiCvlG8V+IpMYmUAuIovR+l3yNnXQMl4ZjY9OGr0XtY+Sf3AJ7iVei3EkyDSyiNxK HsRqvElOQxQw0ir6AN2L36/oX8W3MLYWspZsIH0Y+SO490lyhJbRMs4F+ZDDDAvJXLTtIHvw/gPk BG2hHXSIPsfvEVMj9aM5o7mjfx4dJUWkHSPcTZ7DO87RFPrgDXyYXyMEhDVi+fD1mOEy8iNygvwK 43gX6/4v8jktwu897nvcptH5o4+NfoCx6CA71JBZZAFZRdaRa8iPsavPkxfI3+mXnB49XxdeFDeI Z0fvwNrGyCSMvRW9Z+PZ27FLA2QQvzcxSxuVMYsaehG9mK6gO+hddJC+Td/mNFwIrPITPsO/yv9R qBbF0Vo8yck0eUDJfLISO/A9rPYdmO9j5EXyMs2lMVqCGb2J+z/jxnNN+D3Evc69y2/mdwjnxe+P nBr5y8iXo9tge2oC3LVjNZ/AKvyNOjGGQnoFXU3/hJHv5A7yFl7iI3wV38DP4Tv4m/k7+V/wvxR6 hb3C78Vp4mJxr3bxyHdGfjXaMnoT1oJCVwsAkopJJRkH+FkOaLoS4+vGr5dcR64n28htgJc7SD/k 3UFyjLxMfkveIZ9iBwgNYcyX4+1XA+o209vwu5c+SZ+jL9KX6Xv0M/bjwvgVcNVcPdfITeZWcJvx u5M7wb3JfcT7+KXQv/vw2wVT0Nug0oIwKpbjN1XcLj6qeVVboJ2qXaJ77fyZ4aLhjuF3R8hI3sgl I3eNPDfy59F5o+sx/ijscqUY6RaM8l7A4B78ngAkHiYvkdfI79Sx/oNyVATEu2kE0FCMXaunUyBq TKMz6Sz85uI3ny7AbzFdQlfit4n20RvojfQmeiv9ofq7B3PbQx+nh/F7ih7F77f0JP2QfkL/wQGI OR7QHOXiXJJLY6aN3BSulbsYvxXcKvy6uV5uHXboUe4Ad4R7k3fwUVDbxXwPfy//P/zz/Bv8FwIn FAtJoU6YJ6wQbhReF34lvCV8KQbFZnGluEt8XuPVVGrmaq7Q3KPZp/lIc16r0bZBXL1O+4Z2VBcF xfo55n0Ie/r1ldS8TleLOcK13EnghZvvFrfQuVgxDTeHv4q/jf+1uJye5WX6e7qNv5y/cvQhfjL3 Ob+KzuOO0TAfFGthyrmFjNK93HvcOe7PQi6dw31MC4Tb6VPcKr6Rg40BNPU3Qq5wo/gRrAG/I7Xc RjrEvQjL1Y2jPyW14i56UtzF/YrIwinOQU4Cq7dwd+OmX3KXc9tJu1Apfkkux7o/Ll6L9Z7I3UyL +DeEXeQDPsL9E9rVXaAax+l0IZ+7lEvTvaC4wzRAztAe0k1/SBT6NH2HDkImfox/lM7gTNitDGem 42BsOc6H6Bu8gXSwMdIYl0vbuLPcXP4ZzQm+CmrPCfJrsoHyNAXYuXCNkO8AA+7k4qBpzaAmv6Hl xE3uBr0/N/IMo9jiW+J2wNmDfDG5mKRIJ/cqqQVufIBfO/k+bHRHAYM3kxR3D7lutI8uA92fCfrJ EehtJEmNoJYujG0T+IWTC4MWLsKrPwf9fwVUv4X+lVxDZWDWECkQWMstQjMoUxfo73b8lpFOlH5E 7tAcEn9DWqmLEEEe2QUo/yO5FDznT3h/HizUt4OyPSgUY9QyKHMP7vjRyFSi4Pd98irlyEaMeSLw vE2YCsp71+gVmOHl4FEzwBNfJpeP3k0asXcXj944up0sGn1wdCE03Nmjj4H+rhsdINVki9jBzRMT QiVo7Mv0BfCjP9DtoNtTye9Bj6LUTT7B738w/oni02Sb8DvQzvrRW0Z/CytrASyv94LOTAf1upr8 Fes2lR8iFSMXcftHJ/Pd4FAnyazRR0eD1EBWjl4FyvsM2aMVQXv6SEDcA9jdLiznUhhvIXHSJGoX irsJUSbNnaPUT5xQN742XTOuuqqyorwslSwtKU4UFRbEY9H8SDgkBwN+nzfP43Y5cxx2m2S1mE1G g16n1YgCD1W6uDkyuUvOxLoyQiwydWoJK0cWo2LxNyq6MjKqJn+7T0Zm9y1G07d6Kui5/L96Ktme ylc9qSTXkbqSYrk5ImeON0XkQbpgVjvytzZFOuTMGTU/U83vVPNm5EMh3CA3u1c2yRnaJTdnJq9b ua25q6mkmO43GhojjZcZSorJfoMRWSNyGVekez91TaRqhnM11+7niM6MKWbyIk3NGU8Et+IxfLR5 8bJM26z25iZvKNRRUpyhjUsjSzKESc0JtQtpVF+T0TRmtOpr5MszmA3ZLu8vHtp2y6BElnQlTMsi yxYvbM/wi/GM5owtgfc2ZVwbTru/LuLhkM+3fLPVy2+DhCizztu2bZEz/bPav3GvN8Se0NGBZ2S4 6OSubZPx4luwTy1MfctwmzvaM3QzXggNI6rOKTu7rPoT7bpCzugjkyIrt13RhY3J25YhF68PDeTl KUdGT5G8ZnnbnPZIKFPvjXQsbvLtzyHbLl5/wKPInm+3lBTvl2zZZd1vsY5lTOZvZi7Dkmfb1Jza neVaLv5qXSkbY2QalIaMvFTGSNojmFMNiy6rIduW1mD5cXVQ3JVZhv24PKNv7Nom1aJewhRpRoxK EXnbvwj2P3Lm02/XLB6r0USlfxHWyKDkK0DLgMmNAV0mkcgUFTEA0TZiRzHGiWq5qqR43SCXiXRL MhJoj6QNa7u4ozaJxQ+F2PZuH1TIEhQyfbPas2WZLPEOECUJLYvrYi1DF1py57KWvgstX93eFQEc HwQPJyQ3o4t99c8qOR3NK2sz1Pl/03xZtr1ldqQFOpjcvK1rDGZb5nyrlG1nC4p1Q9tYjmZvxIJn hGhGE50WAehdDGUOFfgnRidHmi/vmgpUwxgzjsZ23svhASzHeXn1UYDfhQsuPI8V2k3sWUJUo8L/ skGtDgCs1lB5ckbqmpqNOwyh0Bh6/T/dNDh6lt2lJl/fNjbnTG1ibFbZOWbGf6v8reGZtvEtc0Cd uJY5C7ZtM3yrbTLo3rZtkyPy5G1d2xYPjvYtichSZNsRvp1v39bdDIqV3f7B0aPbvZnJt3RgKitp LYCcI5P2R+jNs/Yr9ObZC9qPwPgl3zynfYCjXGPXpA62XlzjnPax8aorjxGzncCWa9LUx0xk3BNk NtLbBULOIhQjzEaQEZYgtCPMQLgOYZb4cyIhRFgQ/kQKtX4SFn8++gHKU4XVpA91E5E3Ijj4W8k0 gYx+iXQy7m1COgPvakV+AoKZS8NElSYTNGliQ9mE0Iz+X6CPmfeTZWjLQR2HwNq93HHIxATQyuAV /YmGMrO5DK6arVGr/yviYLpnlwANXAPpXQffr4EYcfe3L7NaZL5hdlmzCbzMNmgOTB9lVw74J3sj u8D7v3W5iQe830t8xK/qGbLaGgK3jUAvjKIUg5RfAK5ZhDxTh///uYrVx46H1rmS3Ek19K/cO/xy yLUfi8s039GW6dbqSw0thjdNgjlk3mcttv5O+oPdkmPMLXEudL3oOZT3b39j4A9ydSg/sjU6IbY6 /nbB3xOzi79XciK5ouxg2fuEoz5InD4R7ius5sz9HH2ae5atLHdsgIjCIPfsQZ4YtCxziBKPTiMe Qzt2gRYSPb2SXkrcCemzuuG6i6RzdTOH60g98tJ5RGWpkC1kiyKiPoGcl/mh84pIvgQcDmF/Z9M+ rh3aKk/qFZkT+/zLqjeJkCKZh5QnnETbQGF30n56ApMepJWHAItzFrB3DXfWSXUkeQZxWYp2Jhyh 3NBsThz+knNBEKbk9tHTdBXkOiNJKD6iaIy8oldqq/RKfdUiPd2t36fn9JtNV2xgz+rpTSTOkPoz ZalouTM3RxMJx6oqqylJKg2lpQ0Nz6txaVJhzz2LJdKIKwExdys5irvL3e8+5RaIW3Fz6wCynKXB Ad2tAavSDyjh1bwO+Qhu/hwO/cshXzUg/w8F5n8rFGMq6nUmjoeZ4t/oPk2xWyxWxVaVsm6y7rT2 WwWrx3WUy6enscJY3M5E3UzpzGlMvb6uvs5mT1NbmvzrzHn6r0SiDJIz7el0RCtsOU6nKzdUNZGr slXGY7FIWHuWTg856haOcF01ToM2mhedJPz8wS+39NYEuGiU85dt4P54Z5EcCLI5Atr4vZhjgK5U btC6jWmX2zeh0q0g8rDIGnA6C7V12mnax7UaRb5EWKC7xLXAfaVujW2N/UfGByz32p40Pml5WXzZ 9Qv326633afkL4QvXLm51C94RG+ux+lx+d1avcvoNvorPVM8W107ZK3bw3GuPI/JozHzHk7UQKDM zdE6BPMghqHXKzmm+j491Q/yFYpJEvN2eOhuzz4P5znKV2Dhbj1AOVNgkN6qmInm/VbHIscqxyaH 4BikWsWhYFJ5RFbkPpnvkvtlTvY8Tb8A1JmpouQsgiK5idvBHYNp4CT3N07HeYJHoXTTsSWfebru zEVSZ89nnTPPdZ6RACl1Z4Y7e+rqh3v2axghfmqHnh7Tv67nSGdPR+K0ze5KqztjT6c5Kdvl4EbP rR60d1jqtkjixhcsLwBqe3o7sWMwp5EE5UNVhFRVYqs02kh1dQUDRKiinDZUXl09jt+76PwpCBjy ru8s2x2Lel6/f887qemPfDGRLrlq/uQ8Ko58GaWT6D2PX//I2p4jL72xc8WKHx8aOVsjlTHL5ezR j/h52M9yOuMIMYyeGjCl9cwRX2dKN+ibDZONLWHhdT0tLKwpVCq7Kl+vPFX5b4OWVNIG/abIhtIn 8o/kHy19ufRk5GT0D6WfhD+OmqbpCgfpLQcKCiQyyJ0+cCJFU4N85SFelJzUOUh3H/IriWSlH56x A5K5sOBpuhJkVs/9Cb577AG3U90D7OSBjImaBulO1Jf0lXA7S/pLuBLUH1qk3YS5D3IfKAalkvZX DlVyldD2Jj6lOI45OIen4igN0I++2iB1d8509mB/OntOgwYBmxNneuvPdJ6xp5NA7Mb1SnVpMhAz WAVNOBQJ5YeiIUEjRi2xmEFeQpNCyRIasCIXMsaXUIO+VJNaQoNm/xIYSqW6MRNp0fW4VBzrJT2J hINtkwqkTnWzQirZYFVOl7OiHOpSPMaQL8LwkO2sdmXt/psemj/p6Ma+7jtG/rJ1aTLkybNd64oW Lb87khdM3HWR3Lp76vVd968Upm/94RWtC+7cVXb4u5nrH2uK+4t1Yr3GuOuq1pYaf0FDwHDpTa0r Nj0CPgpOSfgj2F0DXLW/UwqcZmolzWbFyitWWmSiuVrKaSivFzVUMBnNRDCZBY3JDKzyKXatLker 1el4QasxwX5npuan6Y9A9410t2IWqUav02h0omAyCU/DscQTHV2uGPV6K0938/t4jh+k/1bctF5F LyvtAr06ZeWtGkVLtR7LN3Cop07doTogELIfSoxD1KeTEqi3dEYa7q2zpW0gZfb0ltKEsFF6gWWt VisoWm8n7ezppbkRW8QWqqIVSCh/5PCe4ee5td/ZM5JPz902ch9d3sffcP4W7sFhqPeULAG8r4c9 OkQDSuPDArV3BC4PbBI3aTb5bxFu9WuruKrQXH6uPD90pW+duN63hduWt833EP+Yvj9yKmKFu9Yq 2eyOXKdLl2PmeMzSp9jkUI7MC3Ioz+vjtW5BRO3uA7IcchwFJXHzDgVrSsFJ3w+FIJYcpROJl045 1KftZ3BM/wU4jlAl0hXhIkCQLw5LXH+IhthDFL2sSP0SJ3nCR2ES+1gF6tOdIPMSeBwiEJ4zp0F0 kD9Tf0YFaFB9RmW26EoTIpaLsEKW0CjmXtrL9co30Bu4G2QNKA4jNKAzkKMV45XCKvuyQLfY7Rc7 O2gn1Ya0AoNgjUY7xvVAeMaAF7Abp/z6i0ZWdlD9/Zvn3zRr9foNq0ojefFky8y1+3dtv/oZKogz njgc33Xz4JWH++LjZpf7ElKocv+m7/62tkTLQdziSDv2Yj+g0w0p6bxStFa/znCN5Qb929GPoxoN TzfyG4QNzs0uoU5XoBH5iKfAo+HlRTqqA+04LMdoLGYF47/1gJuI0OE1B6xmOEKowvZIsRvzSJFS xClFXUX9RaeKhCJPdt3RRBySQ3akHIpjp6PfoXV4ChnFyJL0850zh0+rFH3mGZVUgKCDTHSe6cUy AvQurOVBI4yDjGir9KPYF9Xb/b6Aj9PYouZYVB8BhZC8S0jIgly+IbaE+uzyEhI2IVL9K6qjBERD JRk018JrL9D1SDges1Xa86srqCY356sVB/Hn77rp0YeuzN95+/bXVlz32vbFz95BrZ9fOfyafcrk imnzt968MTZfXBk1t/7451uXnso8ccsTCw9Q/2E6daR9uGnL7K73JiUfvmfvf2RgwYzR07D0z4AE 9NwRHFw7dcDhnYhjWHCvI+PRUZEv0k8iirnL3G9+hb7MvUXf4k6ZsaTwMxCzYuY5URBwWkLJ47kc nucE3iwqU6rE96kGieZ9CjAfpPce7jdSo8ckHuU+Ijz3Z8UEZ72gCG1CvyAKz3AfEtPYuksMjJkI M/Mc46AJ6Uyivm6LWJrYYtn4whjw6teIazQ3iTfB658FXHDIXnBISHc0QkNhcMT4L7nfjdTBTDmy vSc1p8Ivzoj951nhRW9pl5FJr9cB3rYB3jyQzCvoBuVoB6X6imBFUXxVxYZwn7HP1JfX570h2hfb VvG4e0/eo9EDpoN5T8Wejr9oeNH4O7NTSwxUY+by9HGn2ZUXNUctLfQWeqN5s+VxYhlPaimOGdBp BYvoJfGFFVeQK+jl3IrYFfGVFd+l18XXFV9XsUPYIfZp+3Q32G6w78jZ4bxHuEt3p+0u+/3OR2I/ if+kYlA4rPvY+InpY8vH8Y/LC7VmfbyWpGlNudikI6a8uKBGkouB+4BGLGGJw+xv0IOu6wH5LKSQ l0CLJVKlVHFKVVdVf9WpKqEq8gwaeNCeIqCHIeVSXDtdvMtTeZT+dYywYPnPnFOJypnT55jQW3+G ATx1pVUgL08kA2GbU9DlRkNiZAkJav1LaHFO0RJSagdHDAtgkQEdooSzZAlJ2hAxUB9jkIw/MmKD f73AXAjRqhyj0QLCVbk6zuqi1WCNTNBhkO/QsGSMW9KtD3a+9vjDv7hqbyY94/f7n7tq3npadq2y bvnyvqqy6tltt1591Q2xKdzem/rn3XRsoHfGritvvmh5z45X1y9evWD/m1dtbL38mnWtlSuTI3+e vKfr+vs3zJ+avgI0aBYw4THAhIvEqUmp+G78bfF34bfjwkphvbhRt0F/jela83rHNfJ23Y0OWC53 FHLjdWLcHYq7RT4QFYhWPEqXEjdVDsbbwNlAmRR9MroqCsmZQOTUDFhE0KhbDrpcxOxmFCiPWnEQ V7LLdt4+SC8DNSpUCvsKeaWwq7C/8FShUAg/hwL+ZH1KMRwzcAZPwbfkGQj4jOoPZ6l+/Rhxks5h q1S6z9hjdr+KvPk6mykmRX2xSCxoDi0hfmseqJEOOdkYWEK9NkRhffSbJCmRyG5Tp6uquto+Lkv5 x2Gv2C5x4ASUbVB2h1RmcNUNp35V+MCmHa8t/+5Lj15zx7svPfgsV2GftH5mx/c7GhaVfs8X5dbS /H2XvfPUwPbHt+398v2R9ddfwR254aLF713bv+s318wrxi7AiiFm4A3GGTTOvZ9jgrNip8EAF/AT UFXiD1LQ1pxn+feJC0GLYODfV1w6zhfgrTqf00+C3fAfcZTqrJyOJOsZzT5+4ngyySBYOnPmr5/S ZPaSNm554QUJoSzlVbw6i9VqlgwBfbAtpMm1OqQ8W57X63P7NSGIwQPRKpYcSLVXqmmiVE0HCrPV cixbnRfIVrvU6oFcNVHulhyVZqsRD09bp1snS9MCraEO63xpbk574ArrCmllYJ3UJ2yxbLNukbbY twZuDt5vvV+613Z/4Ij1iPTTvCOBV62vSL/wvxL4g/Ut6S/Wj6SPAl9YP5e+8H8RKNZbW7xcEFwL i0T8gYBPbzF49U6fy+vUcVqvLteW4829NmCVZCng84VtUo6t20aZCd4yyL2s2LhADscFgv49BG4d tnCD9JBi0klWPtfp1On0Oh8O5il6K+7h9lgU2yCXOtAaoIFB7lPFIiuWNstZC295VL5yG9OSOz15 w51n3HlMJGE6EBPeEJ+DkDJct8WSlUS2dFpK3Ykt0HASbiKdodLQ/xlvkTa+UKetwz9VNFG5pEpD eiGThLQqWYDyWj2uehytoFlNlpGMuJHjHx/+58Lw+CUjc+d6KibSdyL0rXTn7OGPZ6ULvvPhp/Sl N1vjwaQ2GrW6Uz8QFn55z82zxGhUKA0VL6JmLn8YHy1wTBMXmXToBP7xSofRa/R/X/qh9FtJXCet y9ki3eO4N/dl78v+NySd22bP8Qd4bS7dkndzgCvQaYJeAi4U9JpDEVfIEyywWMycpwAHPXW+ulY7 zSJ9yq7YRfvg6LuHzWZurn1ahClbE+urIAHKEdodYVImHwm5NA4HN9dlghkAMevqAoMzSRI3V6NW avJYpWZXePFSVfnHIsG4osagD72JzxKdvTPVrTjDpENbOs2MAFB1fHkBa64UzYkFrL55NC8Xkd8W nEe9Ds88kGv1wAcTS3pob2dPRVVFOXw7zFAAVSUkC/ZcSasJxUGUiU0iUFsiFfPynb74zAquAJ7p Cc89+dzI2j9smvcRLR/55dkFq6PjQqv5qzbJxdFtI8/+ZuSDZ99Y4qOT4Rf20CY/k8fZij+AFW+m 12Tx/qkpCpsZiQ6OfnaILUK0cnD0vGJn2Up10pXqAlQ60EFxsGoHDZtYGlYXKjw4+hGsAFipsNox nNcggV74EYoRkgilxIRYj1CPUAdKYpxA8vNLJ3ClPgNH6pMq/TgOsvHpp2pEkwwIh44nWPpOYqgs lfAqPd1T+qecmHJqiuCYssunVLchy9mDXmMoHA56faFwZdBbGgo3B70TQ2Eu6DWEIo6g1xuKRIPe klCkKuidEIpgBSL5+d6JEyYYjQautKTE5/Pq7I4wp4TpyTCVw6lwd7g/fCJ8KqwJD3KykidN6Zoy NIWXp9ApzdFwVRu0cq5y1+TFf3QnZkrnepmJTerphTLVCxPb17gIjARNRBWbCbtU0xhlaMW2N7vB udhRMF1bjovJnRXAtOz+h/6Pmv++he7h1pkNciKV4ppSqYTsMhuCxanU8DOp2THP8Da1qWz46dSc mDvbwjVjEYNu7nf0ppUhj90djbqkhmXnf7giWyiTN9AHRpZ+XeKv/EY3BjmFMPE+BciRSUbxShB5 ZCJTJTwf7v9ruG3yvfLj8hHZRMOD9DalwrKsei63MMDpg14+FHaO89omhA1BrxSKyEEZbmUF4uGf fTacgo5wvI48Sa/iBrkXlKTzf0NEvd6gwpdBhS+DCpSGXaHFnV9joqSi4jkmRdUxBDzdyRCQrXlv ArqVCyadb2FWbmxs2bHqMOoId4XWfPlhxbxoropay6+aL0um8huX/uh7K+k12pGd0Rp5DX8lQ6so LVLWn39ydjA3p3QtViUMK/8/sCop+rLykdVNLUTnsnjMBdZCa5GQ0ton0AnJDvcqutJ9dXK9+256 X/JV9+/dH9G/uM1mNzW4NKnJKb7aXZ2a4uadqbg7luI1bjHlcvEJUogSpFxX2l3lqUrVl7eWr8RZ gXXu9Z41qW1kq3tz6l5yd+px8kiqvzxT/prrZfdQ+R9h4jtRfsb1ifsTz6nyz8h/XP9ORXFg2jU5 uYB2uOYlr3Bd63nJ/WLqTfebqQ/cH6Qs1qBXHwrLQW9eKFwa9BaouKMLRaSg1wnrTNAbB311u8OE 5hC3h1CP28042sRUMifldqWS7iRNYuwwF3pcnF6Hb1JSqXiBLnUJCLwnWRqGXt4fyoSGQidCp0Ka 0C6lnJZT7PbLilmyylYbN9e6q4xhE/QRRlNhVO38rJNlYIlIjmBDVfamMjjkmFb4lbINpdutat1j R3wZjnX24ILYy5Rsb1KCqZJmIyntdtvSbsmeJjp32jU4euKQK+1K5aSzZj/1IB4UcdIZogz9voGO QL4YyDGlIRVhVXz9RjPlJw+f80bbUiMFKVDnHEsLbOn0U3qa9iXng1pH25LDQ6n5Eefwv4S159dt DBZFo5VyL79uQYE/Hv3yD4JaPL/tq4ZtX24Hxo1+MPqJ+ARgK06fU1q22al9B6Wc0lq1g6N2P0fj XImjxnGt4x5YSkc5rSMctmPPDKEw9swbwuEW7Gskh+1rxG63UY4L28M5dnsYGPpjxRp/EqY1PeW8 eTq7nlf3w2SfbbPJUkpSJF6CdnrQhs1B5txBxhZZRmWi0q5CxkQlMNFCKrPPXE4VcoWOHLaluaFQ KkyHwuAQKkeQ2J3gEGcVA+MyYU/B4h9fwFqYn2ZCXMF2q/wzkcCmSx+q5igmzICLnoEJSrWpwLae VrdYy1wMpLMXR0wL9HaPvRAGr7S9lUy3LyIL7KvIFfYN9vtxhOlpesj+Kv0Ptf+No1D5OztgJKQ9 AIkjhBt97EDAXs8xOdNprods8NFhAJXiS7PswFjiVUuHPWkKWEHDW4rVnrY77bAi5yJ40mCHbw0Y 03jMiWzy+aGcNKfABaBS+wtqWBaqSCcPoBrj6mMwFPlvKIsxpuCl3fwEBjH0LQZL+edv8MZaAVgM kMZPGO8fL844r+UtF0Dly61C0/mfXijx+5qLHXrIVVNH3xOvhXxvgr9sv1J2t/0x7eOGxyXhGrpe u4XerBUadeYCwucWaPTuOvZlGNxHEi/zKV7hRX6an+1vXn2V7Ff8nN9Wx74m46z6IPw003zLsgIQ E3dmSj2Jz7JyD3TXrNJKvdaoMZYXc8QsJlsJDG/uEpqjRc4pIicZzCXUwyGy63JLiEtAxNZLFYNY 5nogMDgLhJ0Qi8dVMznMJjHVBwda4jHuDNXRG0c24LDgRyM3/vHYvw9/Z+ttVx849sXW74hXjqwa eWPk1ZGVcBjU0cbX9k/b8tjIMyMHD+DIFW2gC/fezPhY3+h7goi1qeHmKx77D4vxiYWVM+KDIwG+ QzHRSls5va12kE5WTlTXVOfxXmGRe5FnUd4ir0Y0ixZSNFQrrDGuMa+xrLN2B7qD3cnu1Fbd941b zFssN1m3JB4THquQ7OYKc6W5yl/hr/RXgUByJYIckIOFhSUQlSdy9ULKkwqkgqnQhMoJVVPNU4vm GOeZ50vzCucloHsFOW9FsMpbPcc9xzMnr6N8YcXCyoVVC6sXjLPwRmOhw+gtjBjl2vGFqdpee69j a/492nuS96YeSw4VPFf0UmKo9mxtzkW6Gi8+9vLuo69D29hEKT1KBvkWxVx1X5nP618V9AYCR/2s ptJzX04RxFmTJcdksiRMRRYhplcTaJ/D4G8FZXykIEfPPUmVQLgSKhBMgYM0okhJ2zEbdxKHRG37 bCdtPJSWLU8FnwwkJOYbQofg7lJ6rPRvpaOlfCnsVErp6yjwpFQuTZUOlQqlz9DJsLZMxnEqlSZ0 diZ6AFW955hLp3e4N51UXYH1cCxmDSNMt2TajQV2Vqg0n56DUgMLiprrpFIP8ioQVuentI6CmLFY X0EKrbEKmu9ApE2haCgxVRCjqTgRl4oqqNVSWBS1RyqILqmpoIBEpkhloyxEQjmH/aQT5Ea/1Ljc vEJamhA6O+Da603g2JnKY0xGtzUtpKzpCgQGzB3UFinlVJsKxLoAN2ZtYTq8NmKrCHCqhQXInj9m llH1eviVovbOJxeuvDkx8eNnt7f87ZnxlcGf5Xn8UKHy2g9dtfH2cbXxkYd/MOPUT65aX+PKCxkA 74kt/ZdumjWxomXj8qvvnHXfSb1YH0jSX91xe9dNC8qXFwd+tuaWOXf8psoTTDLInwgJLgN+EiR/ V2pxFJRb4F8QuJJeyV3pvzKgS4bqQ62he8S7vY+Jj3i1HPUHnExiC0OGs4YiWncExgLJqgsNckOK Q08TRHFZ6u1WPK4Nh1FhgOQKlDydXtWk9KqoplcVBH3Y5QwmAoymWNgdJCAFFgX6A0LgKL6sc45+ qhgZr3Cqcp0TTz8gL4NoJ32WSJzDyh8hARgGjFXsAQNGayUWOAGna1bgU3eGKMYqhAtNH0JkYD5v UBXpZellJhOABTgiWHFoVf/F2lUBXBtxCA9aY0ZHcMWcY6C3yeHnGPF9aFFB5XRtTBJnjDw/J792 3JfnLhBawWRxXLUQ1iWsqnH0lLgfq1pKbzxCUmAqRcnKFGMucr6aKnOcvsoCTa1mhma9VYhGovHy SHm8OdIc3xPXFsbTca4ttcb4Xet98WPxz2OaOosu6OVC4WDQ6wmFi4Jeqqox7lAEgheHYyfRArO+ CBz47wfZqiHzocqe1QzjsYWMD0t6vU4xpXVwscu6FD7nAvNWbDk53FydqrrpNOxmVnuYcWhdHhux 0lRfJaVod6o/lUmdSgmpoKxupqxupqxuphy22zc56CoHdagc3gF7DjTCAHuzw5M89zV3Z9xc3SRm 3Yd+jKuTKc3ZSmbtVOU6Vl+Wapm1fv84HdTlWKjAYGNeQU5jjcaj+Ra5hEi2mKmwhBoNISlaQgqM iNjeMkTFzTDqwy2Fg6M9DGVp1VcymoYZ02DltMHACentguim4t+Yjs3/ip6qaEvkzjrz2rsfpuRm qNXTK+fke/wzdqzc/OuZUAbEeDTaGOwZ/v1r7z143w0d/+LsGy+KRqvye4f3t77WO33Nobe4KPQC wAHOsIiPq3Dw24MioXZ1RR+DkJS61H2ppy0lFLu+61ofWx/f7toa13hED9wZqVxtboGcakuJogi3 T0EuJ4SgVeVrC+L5BdHSVGoyVVKzaLt2QaC9oC21WrNau7pgdVF3qo/2aW7S3lTQV9SX2l30EH2I 60+94P+t/1RK3qzZot1SwFMt56VZBA7GZG+QFJR6SRaVA26/N5Afc7tccH3kxOMxuB0Z0ITjBSgV uGOuZIE2pSvQxmNuMShRfGUOqxdQ3+UcHP3PQab6I5OVCllGsbLdd4YVHaQEQIMedU+xKv2TcpzB ld1cJcdTcSXeFu+O98V3xrXxQe6eA0lmzPKwgxR5AJS6PLcKLir2Mjqs2sKZdZWFLUKW7CN1q/Sf 2tNjVi14L76ybWXzY37+2lhtPOsyUrUCRrApPBiqFCjC+WKB+EcL7MZ6wiI3k/5MaW02wbg/2m9S 6TkDK+agYxAE59x/i20wrkNuU+EL5jIXHTPY8ifo23l5yy6uGznii11cDAUAFGXklknJ6TkxrimQ bJ1AvdRQ56+uFmdES+ctHh4eefICeaENXM2y8oghGi0uzr90pIX++NJSX7GHWcymjZ7BXyPYh3PQ E/hpY5ZbuV414dTDOsPNzfVqS6M6oxGGHBVho8SEL/3PKka7nZtb4WRdUH5XJR7InFNy2ZZVqH0r 0lo11ZaUsm2T9biltIIEhMLiVKVJ0eOhJsXvZ7ENTabB0TeUAOsEp/QmN3WrtW61h1uKBrR1OOmW hGT4AlAfxhCsY+J4cpht5xuJ47DxHFerEkND7yQSL0hvHIeFAnaeVUbftgrOPrua2uVguq/+Mf1h A29P2DeSjRXfJ9uN26s0fruzVqrvqxf0vhniDE2z3ByeUavUb/XrDBatTMLTaIthmnFaVcu4xtpp E+YbVxg3628y3GS0znHe6OSC9YvquS5dBamsKy0sqXyaeiEom0aHDuvTpgJjGtOC9FtbJZnaTJyC qMvEy2qyziSY6gAnbymFxnSre5F7lZtPuje5Off3gCZsxqk6pY7DtLvZEYqSKqzbID9ZsQnG0qES WtIVJRVmk6myEgt/HjugmVvxNMVXziTK3mhJk2gw2hfdGRWU6Nko1xelUYl1ij7NNeIoWC74XzCd O0hXKAFvMl2mVSxpWdum7dPykpae1VLmEGmc2PidrDDV09ubYP6lBAgu07DAMVWCC9SCek3qzw2f 7pTO9NSf6YW0lbClWZ9EIpnFnQHeBL2pI+vkGPNvTKka74uIjnE11TUcTiMYdJwGdoMwp6kypiGr +x0+YndYg2YfDUfGi2kfqdFVyrSq0mj3ST5qCSOq1dT5mIjEpCzKyDej4EVF7DAHMBNaOwQrSFXt A/V2ZinrTJBeYOvBMswUEHlqQFKTw5b0OBlzz2IqklOK0Zh2yzgcheBj0J5nTBuwleMQDAUGpAak eqT6r/QzBo3s6sA8oxd87uNwwCd7PkST67pw+ow5Y+COYSe5mBFpXK7KWGy4J+sv46bcml89YdF3 A4Wvfjp/dn00xiVj0WRm94aLxvvsBpdVMuXWdS8vq6V3F7c2zauZcdPVNs8NVzSWNV07L3/r8nC4 uLa0vLJk3s7C4KTE5pGXbxyfozXX1dzV9APaWecp7kpPxUkKbvRLeM6OiLfBVp5Pf53F/P0BOJHP KQASbq6YYyJuVcl2A4A/VKk0MucPMkKsZhieI3MOdhf0N5ncLvwhCL1jEOZYW46iR7ecXOKN6o2h Dk6reiPr30lkBW8VT2GHlV4C0sKPM+YiBguBn1nvwH3sHnZvQBRjUeIGGdHMdXMMetlwPscoNOzl f32KVZlMsSioAJ4KxB9iueNj7zvOiD5zFK2XYvRhzWHNIe0nQUGMNZo7q+XYWn6d8H1+i/AIv1en naKltbqcuLnBEchpcrvg6/Y6iYSDHBdGUhYUd4pcl9gn7hN58S8mHCx155tMkrnN3G3eaRb6EGXM OHgmmWVzCtkh8wmz1gzsf6quytwVfb4la6kAYjCphSHPcGcvLIygaL31NldaPeunKhwFHpk3amMy H5BpnsHtIx630eTToRQUQjL1GL3wqWm8OB4EgGOAr0ouMPv3MBgHV8LX7vD5qUeXmNACkQXqgjaO 44M2BnRZJ61WQ8dvvu/WX/94+962PfOssttXZKGOkoqr05c88MCyqqoC7rMjf//VuR/21dbyh340 NU+KdA8XDP+xvOIXxzI/9eZARpkMGJoO7hGi/xrQCfQC/+DyvuXqUHmAxhm16rVdoe4Qx1xxqmsg BMPAGwcdkCKReeUw4yj+MvyhjzMg34nO+hfOqHb748zTt9+uelpWF5VUkgjbPZd5vsj5HHOE2eJs zRxtu7fdp10hrhP7SF/ooPdF+YR8inwg6sfhq7V57rm+RZEud5dvnbvXt81+m2Onbaf7Efowty9y AN/e/Vz7c8/HutO+T+Rz1K3hptvn27cHt8t9kbMRrU2mz+BjBxkhCIKBs8KMAKcAF12hvhBHQlJI DrWF2Lx2fsMueTZkDi33n4Qp4OfOqF6L6b01kJNmiVJjT2OSxtBrQRNtNe0wcaakpFqwu3BYeifJ 4NPKU0TPTNoceWJ13o15XFse3Z1H8wapSbGf1eD7Q0mT/Ws6oqYx3HiEuz2r7vb2zDzT2dsz3NN5 ukcFq0QCR4p6IA/19J62j6GYYbZ/qX+1n/+BH/S4pwO4UVNTgy8y2TEi2ktAshmBJJI77QXdO+xI i5KUptgw0EpQxqH9Upbg0QRArIcymRgH4Ej2LAA7+sKEF5hYVMc/aBs/PfrWjT/6iNKDW/6nrHh8 wGaMRCYumzDrwa1LLhpXSRce+hnVnHyLWnbMjCVjueuCgelLHnz4y8bS9Zh90+hpWFZug0JYwrWM wVYsCfIEpUQDezf8ZzpGhMaAjch+p0qwnEaMFOoJgydZVU9ktTdqP1eyuoebPUT2HYX7yM8YNUr+ oJ2RLsmh6C3QPXJIFBtXXMzAERgKypVEyDqSEhAwXpCGGBVjMsYF8nWxHXfBNc/z7FZft58q/i4Y vIJGPMboVGmYU2AECyPMYaksWK2IOUbNZDlZWqj2USeH7xY1yVKVqh1PZIkbc2AlGLl4p7PzOE4O uNL17zDqeYQkoR5OmVKZxAYpk+Dk7kpeJ1wnbhP6kvuSQ0mtkuxLciTpLMpNzBXn6uYk7tLiI1Eq J8cZphjmGe4RHi3qT2qHkmcTnCwTOXQU0A41VGmuk1vlS+XlhqvkDfJuslt+QntE+1KRMaZzxE0N 9oCjKdcfdzb4Av6mIG4zCsW56qoFi2lxcZA3BokxZMJZlxWKPbfL2efc5+SDzp1OzvmXwjYNxoq/ iFbJ0qdw5qixtHHTmCV35pnh3k4o3Oxi/hec9WTkUVLpI8kmKpnMiyUEXTwa0xXKJCEgKtBGZVok FquEkcnZzBMKAFfhGx7Rnk7wZ3BnxnCrKu1gxNnDECplzLJjlxipsjFzyxgMcz9v7Jt+16nPf7a+ FRQyL2GmthJryOktMY6cLdXULU22N1+SueqSFZMnfPnii3TKzMcfUAnll+88OMVni/S8TN9q6k63 rvzFK78DRLNzW7P5DA7M+vmNYxBdoHOC35msAEFiUROLSjAtuSmFUObc4ggOWOCDyNEhlVayjGJj tnT8gQZv1KYlWokdREQzewjLHGI0FUf6R99U70DmlacYNghlRiMAiJFX0Fd29gRpZ6cK1mDHyePw jF6AZn9uH+kHOeIv+NfUQWTfqGMvUfIZCEv4my8ZLT4t6ILg2K8VtHcIPxYGBJ69SoupMUyMMfjO yQkGME+WxWwB9my2SKA1ocpiCQa+zcITOP6BsXa+ADNeuTpWjJSBO6ysi9ydni7SlfMmL3pkH8Q0 X9oJg3uQjcrQOL1SF2QsghVxjrlSrZ5dVFrp1Xj07Y5LnYtwov2SPC1Ozmq0OKEv5k7TbOVu0Wwx bZM2+x/i9roPOd7g3rb+XjrH/ZN32Lu0XbpuzG6r/jntL6xnteB0WvNNHK9neKIBnkyv1k/mpuhb g3O4Ofol+G55q2Or517Hw/qHDYO6Q/qM4efcn7lTpnOGHN0JLSXaE1quh6Vs7XZi0TI4+7ZRyCEp Zy6bgQOegUW5m3J3557MFXJzvb8RKHbwBBgIko8GHCx5S5lqT7M1XuilDAa0r+mcBd601UlXOTc5 dzh557mcnD4dTel26riUbofupI6XdIoOM9FldKfwR3mesOQKZCuDK/xNK3vKws6E8MQiWWQLf9ZC LWwkeqylpTHQOCa5QAWYOYxDvhDw2VlfnMeGfow9AoIC13rhXmOy9qpcyNpQD9j5EbAesBgYzGpq 4EKjje0HNQSeo54OVTnATVmJ/AjR4m3GSNqklKTNCLAkDQ0UMOWZJYxGDHizJW+2baxkyJYM2Ta9 WlIs+nQuPCoe2ZY2IzDjDo7hf+Pq6OhwaLJWUtcYBwMtcOJcHLgX2Jfm93TZsi0LNpcEc1+5Z89f /n74vpeGt9DHRMmztHr2jdz419asWXptztb3KH37L1T76hO17fk1yvWQh1pxTHGDeAtJcLox7I6W qPyqRGGMqkTVq72wNVk0VGcppDrGxKgda/2Jgr/mxs212FkNQwzEGsaecMpBMejyowF8vwQn8CD1 Dtg17ITUmSFpqP44zg1nmRJY0pD0gvQS+0FgwmzHEPkIvkxh9+BAp1fxF2ry8SRdIVURkWoYBlJV rlaH8ZZiVLFRrcewfq/K1xZLSfEFFgQJOzGE1x8HB2I+Gq8ycbt8b+69Mb6JbzJN9WzmN5vE+wSa LNkU2ok/8Ldbt1u/S9ply5ToJQ3o1KKiRQnOp7McDOjuCNODAe0gr1OCkcDuwDEcF7PlR1000Qbl N1VUaLdpdFqDBAAfpBcf2AGFd5D7bIAWJQappJgLCqndapPusFppPgPWA11dlWpaW5tN6+uzaX6Z mipOX6hyp4UyEF9k6bYMWU5YNBZP8VFew2vHHAZMY01AywXoqrptHZIPO0/3qjakujocZq8fhmYL qqnyH3s0nuOMRXNjUWeBj8Rz8n1U9Twx7ZOdk+zphJD0DQMxTjrZIlUVOCcJ4Xzs2GRWYILml1uR Sx/xRSfOHn6nsGCSZ2Cg/VDP5e21lQFXxfRgMFaq+D7lZww/0hcuzs8vaFrCLZhat/XZtU0lNYGq 0NUOR9mKNydNZadkJ4xM5v8AmXw8mUY6+LuVG+zOtrtj91bzpES6hFtXtA6fDhZpSjUXb5eF+nGt l6watzbWfQk72Xqj6yb3jqptE29s3tHy/dYfun7ovrd1UDgiHnQddL9c+XLL0CUnLjl1ydlLvHly boVUlVMdvER8VDe9ut5LnHx1aLqXeBq//kpc73Dk6HUwOthxFOjdg3ZwJGSGDsCBzlIYkIz1u6P7 oseifHSQ7jrUnuiDsoWuipn1te8O7QsdC/HquT3co6a4JYS+invndDqdfTU0HQfF66cXM9SZ3pZD cwapTnGs0tFNOGUOLRSW6CrNvY20cZAvU0ye6Yakh7Z5+vBl0U+5X+NbCD0/E8eHyhSDRuvBX7Uo LrbOfJZPgeUGEKfJTD6lBGHBXpXakdqd4lNuxl9TJsb2UlXpUr5vDp3D5mYGtiLzykEJb1RrWBdk mJsaCDYHf3aRFrBJ41hD5Y4C2lrQXTBUcKJAKLCwnmjKWj+R+atiZ7JpwVr5ktQlyiX9WHPxEnar z2iqvMSy467JdLJqxZlcJjup1dntfB3EfnD0H4qN3ec0McHAqY4Rvo+fKo5762l9WYpv47k2Hn/p SGKfdmAbPP5KNcVTkZ5T9XuWeYrNkb98wSVH6bUkRA37t8JRnrW2Q6voHQZ+dPacSfSelhI9rBo8 oJdR/0SPdPocir2gSGNMYfhDxiLqpTO9OIkBKaNXYv3RGVzi4OuhkyEOfALeOQhl+NNJB1+Pnoyi pveCrRYU56tvrZBVMW5Dy/za5vwqn9/lpjAMlJdVlFWW8ZqGWGusNFoUmxed46O+8Thx2lI1UyaT aL1MJoj1PtJWMtNHLk7MkWmTe7KPzo3P99F58/21XnT3jiczyqbLtGV6VbXCNcqg4xOFOh+9KDnL R2YXzpJJs6sR31CySaompq8jFdtZvXoVQdxkF07eMWbXoxqbFEOpBBitwjGRUgDEfpwWQeeOC0eo XeA7jBLA9hOJjB2kVs1AzESEr41YC1OrqiqhTFWPUz18lB2vVtkX+wwJOtg3SihXzVlwvP/GrucT FnzNyFsT19S8sKdpSnEwlPJ1/3JC56orfvTlc5tbjLYq7aLKRJrmTl/WVNk2Y0lzxcjnyVTtsp8e 3FtRed979KLCH3Tc/IIiavSuPIOomdrddzgnls6xyVqBF/Xm7ot7lt4xv7za7Y5O0i8NlgUjl3Jb 1m3YNX9S74bdCyadv76iPZrKn7hpaqXTKYDp4wsmwv8T2lw1t2OMN/prwPRwEMRgM6iM0ODOZ2W3 6riDWfRz1RGFzKnseUC3hVmb3THGLYMM2GOhyqp4CQ3hIyZubkh9RqjEzZ5RwhwLrBaZz1STFTJZ HEPmU8XKbi9Rn1dCoYXhrwG/j798+z6JIhQgxEklGK+1SrVjVVWTuM1fLDArFs4WQg9UTxUCKMf0 QdXuJL3wUrn0gnrEEHohFETGhi9I0+2VQGvN3Co1xhvjlXgoe6QtblDZr0FluQaVLRvGLF1q1Zjt y10zjobUniG1OqT2DGE2Z1XLLzL4050gNsich7cEmZKacWNcW2XaY/njAD+CWUCNhHWM4RUUJa+S rFGKqgw1XZCbrVFrrK9mZ42QqRmqOVHDJzS0raarpptVKTVU1rkLA7ZBHp+yhksKA/HpYUNhQJoe CRUGYoO8RSmNVMVLGyoDVU1UjlcTdZYQq2w2yeBx5+t3GmjGQK2GbsNuw+sGwcCIFDxwofzSYElb SVdJd4nQV7KzhMuUUHCskqGSEyVCSde4R6AdwtAMgZJJlpBAv3k8Er4/nJAd+1Z2jDnn5PlEnSbq jflEj49qdXlaP2PPY5Yy1TAMPx/TB6mN8eOsSRYolz02CWxjnj4mDWpVS21uqArG2guV0BjpzFU3 NFzU7XVYDCllZGKuUm7gg02psium56Ynj9ROiOS4rcG83KSF2sXbhpdsaJ63UHli5Jn5sLPl58dj 0kW06a5Lk5WtI75LS4P5+Q5DzTx+QlZ7ZJ6ZOkRa4IuRhLkxz8wRkg9G4Gciot2sgrs5pFoyQm4m MIYcbh6+sr+qtByZUyrgI/OmikjI/PIwg3u9GTiVpfjIvK/2Ylh2Ad3ePMR6uWVmDnG1hlaFNoEN h1cBh7s0VKNKsqrWzrBRE9Y4IA2+CaJ+vFN6J6tKAvyZbSRxHCgBmpkAItCvMMEsqzgQUmP2nIMt LTB2sExDQzajeMaN08xVmKmrX8OxlxKYF8JaB5veZ4qPYZJenx8xq/hghpNQM9es4gObWRYfkPlM xQdWo+KD250f+QYOqNnjGPs7x+uPA5ww3jFU8OzMp1353fk78/vzz+aLcn5bPqewKJ8xzvLySjWt qc2mJalsGomqqVLqyasEgjimh82FATvQIu5pkAOhJpPH5NiJqaQJPiPTOuyGnTjVkmY8eKCxiiWK tb6Kv9JkMnvM+W4lkcbA4cWprq3c6aZtbtrl7nbvxCfpZ92ieyAy8JCKDmzY7Dt5MFh8E6uKqVDH MLWslWRsSpgaQD1rFmZGYXAU9rGO4yu4VsFaVX0YXBcWjR9fVFQ3/nuesoaRxsZSr14byPMVWGiO eBtrqCsqGj8SGpbnpQHIeXVz6eIfFssea343IGQCoNYKqM2lt2ep/BHiwpapMJtj0lDtmM4Dwxc0 Hw0j0fhKGKSLARMyn6hUG5ksWCLzpupaRObdQ+wek/hTkGcdghZ/sAInvx1f+Rq0bDMT5V+pRIwK M0cgtKJvUOK4Q4W8HNUAx1wN+P8ExrShrB6k2uTYoLKAhMz/1djVAMdRnufbvb+9vb/d+9+9vz3d z+p0p5NOdyf5ZIJWxLJsS8ICW7ZlIixiE0yAIEyNMdhYZRIICROrIZ3UcRq5TGnSdBobA8ZAKYJ6 0mQSB08DNMlMMkyGISa1icu4NAEs93m/PdmmTaeVvft9993et3/v937vz/O+H00czN1gEpLHE41c QUg4K7PDERt9di66ED2HuCyilIGVdSqN/ubyOhc96t3WOx7ljOh4dDo6g+CtQzjQ6SmmnGvauGLK oWeXnA+4JKdDtHA5L87NuqHSUBvL63MebtzDTXtmPHOeQ55zHrvnaOQKUgBrZDRwKWsA3MyAMeDK mEvg4++75RLg7lfqw4sDAxXVl46p7QgYsX/lw8ENy5Ls3VqNg8Nk+CdkigzsVjc0i43Wn7Zm8Ogk m8EnmV4blRlLkidGAVUw51pUfsteH7UYfnrH3SV2VKnat3LpKFTMo6jFyNBRKweHB9lxg4xQBhmh DI4CbspPjC79DhVzbkfF7ACVDwyFiGpUpG5GS+znJfbzEtKcw29NRNQnEQ/F59cMhhXqS1DH+AzB gn7dB4ss7amPPpn1IbM+ZNiQT5t9aN10DD6/YvahdVAf+PwLw019kFWXff4INIp+tIjS1TO0ipiq Nrx+wqBjuia4tRN3TuxDxPIGx3A1li+74eS2m94yhDuRpRdc9MIC/S3JGkTVjL0Sh71UbZE62kDv ZN8rwRJAnPeSIcC4Ct2jd7fT7lw/scEZqw7LjOJljRmltRITLEqsrdQ3yD4Nsk+Do7iv3zIuqmmb 8Jx+z2QOVqGhgcp77Nu+vk14B++y8YKKOYJQ+T37dnR0clNr4MBWhEukvYQrZxtuBnIJ48fQGSTY FrgjXqQfegluptOWIWxd2Lovnn5GjQG7FCO7Lv4m40ai7jw1+buIdRZT+SRJMLDSzk1CUNGKKYDL P3q6ra+YqqJiuNtGi6nhNW1yMRWFrPJ0tlRMwaXufTo7WEytRMW4Ojuhjw2uT02sEIp9Y0az2C5Y nPnhDRvpxeTLHtHtdNjszuGVVaDVxcloVJXkXKZb42a0IxoPY3fD8PcVK6Xcsu4+bqbvSB/fR22R sY2DudHR9Nj4GD87NjfGW8akMX4M4/pYKFIfm940eZzf/FQGUs5xbtsXSqVroTEt+QnPk6yDzAdM 5Ll26OYVhEijP+zxfwzPivKFsPjmSxlD8HRNI0WoLefxe/PZQs6Tgdvc3+bLXykHwT8OJDMZKiDx MDHojwhDpHuYUUSQhpzRy3zkUjMsmJdbzWMhOpFdnRvfFujcXtuwJ3zLV0ZW35WJeMXeTyxeFVye iYq2uL6hcdsoz4f7Vy5WR5tue6a8trexrlOpjiwuH+hR2cyj+7lQiT+zzV/o2Lbl3pGRif49i/ds 0CIQmqJSVh7nvjRTMRqr3KXFESZJ5XLy9WirGsly32J4c28cATrLJ7gbv17OtGYpD3SR/wQnq/GX OFmDcTJS7vmJKtv7BH8kSyyhQm3ZZK4oMJYkMH4gMH4gRJjK0sIaMl/TlVAmExaDlneNAo33iCXJ fpxkHSVZF8ki01iKTBkp0uCh06FyjsljqJhMDpUPDJF6KVoSfA5U+2vDVTXIdVXt8VJoJYVJtWGD DmO4cv5cj1Mtm573ri6msEjM//4xrQVGf6IUc6oE5zhB7ONj9kPjxq4ICVym3aPK6uwCqmb//pzA RC+BcQqBcQ0hwlxaEdYUgZMOLq8I3IRJdmSSNSTZl0l2o6SusAqdCJX3nqWfFIuNeotd/J8KDDSY /gY0GKFB47+7MY646ZnGXMPeaeMohnqmMYtPRxqOI41TDf5Ig5tGw0LDmhQixZTfVGaKxVRuTZtQ TPnWZJPFVNZUZqp6x2B3qroCKf57auyJ5rJZv98nRiM555zAHRE4P4zq88KryHNPyky8WEvmOtLF cUQEzxRts8W54pGi1VKUENVA87gLA744XTcVGjbK/38KTSCmWB22vGKNJjik0LGrS8MYFgeE+xFm EdFJpM/8r9oMRiSZI5dUnJaCw0bpyF99deR2LeJzV69ZXB40aqJtcGzXPW4fDcTQyio0mYQ5Ds++ MrLhqj2LuzemFabH+Ndyu/be9eBiciqSxEgb3satf2KVStIgD6YNjAnGmd+S5D0tmSEBMZAo3MOM 3BB3MUt6JAKYeVQ4Ns4z8qeKEaRGGzvMFgUGTcpD5iOrswkLMFWMyw4rF31Px6n04zjRlGoLMYoL eRA4AgkO0z726BxyAFVttpTHk2aOJzYV0TDAXMROQqbtocBsmPt25FgE6XldJ5I/dzkCvxG5Va6h yMbwF7hHXY/4fx53po2eho05nObT3PfDP1R5I82tFpauJoDTLRgl2IDWghRt3Cnaj9umbTO2OdsR m8N2Bm5994DhmQcU4JKvhbBWpOyWRo60I2n6+HWbn/SkVj+Ztq1Gxr0XCV1GCxbRClE0BX5y0z9Y VKQMt2HVn553pHfiV3zE7DDZuiHgYXu5ZACZcXgElYt5R0H2hzRLklM1LuJCLeZELeiVNC5uxS7s jmoWxY4dcQjyp7b+GLoKtAaqg0/HkHfyOx33iff57gvcG9kZ25kQgGk30eyuhCQ349jg2Tr3pNs0 foFETfN3y7TVi6gMsmLBCUOxwAXecuqB2+55dd+r992y98frGrddM//gTQ/cOmw9/K2HD9//0ewT X/77B/6wa3DgW3t+sPirQ/90/tFpKB0X/7C4xvo8aE23NPm2Fq0VlzMMY4/YQRIYmViwjwUVi2Yt BhkPDmoMwgjx5gOmB6PyEeO7qLSQTZq1vRSw+RwquWMQvm64IX5U8r7eSWSsYFzYwriwhQN1gsPC RgQrERgum5IZlcI3A6wTGCs+nbysizxn6bn40TNEiD0i0SRQCo4JUVzej6tjdBtkPDKIa6E5ABgB mknixCQ1DUe1O3w6Auh8uBg3XQ1dAI2PAck07VAuAZwRzPMUQ0WBuomqHxCXk3u0Ka2WbpAekW0P lbnl5YHlI+Ubyp+VP1u+W9gt7y5/XnjC+Y7wB5e3e/mm2mT99rrNWM51Cdb2YiAIsUp5qC0I4UrP WvTMWj1lWcEHSu1WW0Xq5ehKeIBGfW4l5uuppsU5kZ8WZ8XDolX8N41H2q5bjLimjQMyw8PkTxAa M5zPnpnuJ5AUzDwQdQghZeKjrsIdkVa7BAEolaw+ieQfZhLWuhpOr5CvFzyF7nzD2aNxXV7saq5e jau6KxoZblukC0ZJebmAApictOZrYZJ0TOMrmVj1JQGmFrnCzmM3GSaFUVO8FWABPKcWhvev/dKn 7vrizHfX9Lb3RJsji5rSpwfDUjYVy3N1l++Odduuvu5Txqburpy1ueON3Tfd/vnXzh7cF/Z3Lr5z Yy2FsM+Iu7rN+unJ7phv3+J378z2b7r2M8/9y13XxgKkacFWyj8LWm7nnmlRcnsHo2RHOirrTITQ Y2mupXBdqZ/A122qXqiYcgMq75q+gTRTn9JM0EArpGEaD2lOssYiygsg7pilAPL2rdXv1PfpVr3d GfPANTZwkvSQs9BCQE5XWjzJ4fj9JXlhydCZpe4K+O2drn2I70IHMQeulJGzzPQMGeemweaYQOW3 TFWgCvM0ptMdxctTPvqHcn3y5NQlUyXQvBCy/T18j9/gDf+DNqfRwW3p4NJEi0yqfyir69pgIaWv sIjuDjmkSZwtRsnlmhLykU0i9aATcvsWBwfzkqOSRq57i5xLp9MaN6vNabxFkyDHLwA+Ztemi39z CftqIvZ2AFnFFGz4NM5OgSBZto4WJIUZW3ZgFgZ7C9MUbBpaiGQuz7qE97zShjh69+6+VfVcdmM4 EO7sDnqvuXqxtLJNEe1eZA3TRS5sPfyTn3yyrPcOhYo3Lq4e1THF5iJM6t166BMJmmZBL9suvsW/ Dnqp2uotetFrjF5qQLLyEzzHrIQcsxJyfoRo6h5q1zN+MvvRbIzKeaOH6MFfdQq6P2MLlOzcbjt3 u52z57s4jutwKrtS3FbkkMhrKjetzqi8GgCaBPgMzFRdKFFMESiJpmcYAE++dlJ6zeR3l4x/PRm/ Ltg6IqlAxc53VJ1mN0pgxM7dZr/fztvzHc4VKW5b6k/gDM4H3Bxd4XsGPAKOCb+/1qMKPqoKOvzk jgldr/UwaoG13SxPYKabArJlako6cWJqQDpBSVWauCjie0VXWSnzgUDFcDfLQPLGQpOezYWD0tdy dtEJWG9xujZTm605/LXjnGY8DBb5I++PfCdyJ/L/mn0j9/Py27a3s2/n3im7AwPlqfLnOveW93P7 +f3W2fAs8g7NJh7p3F/xUvSfaHV5HAmx/IO2H2aFhDUSCiDDiVKMlw+4DogHtceyj+XcgZK3vbym vLa2pXZv8d7yQ77vZA/XTlvfTniKQjVleZFPcWmuC6F2x7nSUcuLleOcasgdsZTyYjylplVOUjW8 APpSeRFZx1SjLRCARdRt8+ussKe4f7ZUujqqCCPBQ1UfUBSsObLSCEW66MHyPw5wXICccL8jH6s1 ZLhnKMvbDDJTWoEy6DUUXVUqafhRy/M6N80CLawUdcHrz3Ma8g1qT5qoEPBqirFjNvkLhP+4mAH+ o9kFHOHRixyqhBB5C99jYiJL5VtXBN9BdhAhTee87pDX614KxZs0Y/GmdnwsGg/Q81YcRkVzeeuW 0iRj/4n2YlqTAJ5Oy1BvHUUhgSEMB6Cz3Z6gCDywfuaTw5UZrg+d70vvyx+2I+YOYEcMVTQq89w8 P2+dd3/DOxeeU+fic4kDbV/Pznd6IMRANWaYSORXwzJ6uS+XD+YOlpFfDTdnyO2a0nS1I6TXEJs8 NiAmF46KTYifC4YiNitoKrMNcQASQoR9Gu0w0QPLwgqlmTMBPVAzCdfjQQHIZTkWNPsKmH0hUpgz ECmMrawF6DfnYITHYf6mVfLiPN4mOjiHsBicx4tjsCEynTYmuC1Jbf+jxLMhtDqsJlnm6CA/YrSF S2BzHcILl+DC8FiwnE/RCIS0Pn4uU9j1qZUbtPSWr/7oxZ3rb8+Eo95MJvGtTw9tvGnxV52dB+/v HavJUsBjPbz4g8c+u6ZzWXuxMrz18b0HUqLKDT/6leuaQzfO9Tc33vUXUb8vBh4Wuvjv/FW2lxHh e6HFw/JJpA0BMJMhaNwepiZ7wkHOHmTVIJvIgkt+QlTOMxEOlXOmwzDoFsr+SAiZzpBMG06EgZMX kFLo7ImWJe2XS/jzyyYyJQrVH8oq24evqOPdnmY2L7xds6KgYoTo6BlkSfPHufCtIW41MAh0OgOk iHO745ydiXB2pvLa2SxoxwWSku+YoCtl8x8qHzALWTCYTFye/0oMATdw4dTU1IIEZ8oUc1DgNeK1 AvXpxQUMeppbuC08P5A8IB9QXgq/FDmunFac80nuERXw4rXeLZ4t3v+IQV8Mx3SkVQjHFNXK0S4U P8RZw92tq7V2IxbQ4WnQRUdeBfDsd2Fr+OZQ/McW93HujFFGJg5PpSt5BHBWrB1hs9lzofEgNxtE nJoUPBJcCJ4Kvhl0BKcTfwe8gCnAQX6jf1NI3AlzHnIJWQYuvEXJbKSz+OotDtOnBVsAvJm5yyGZ 7WDeuBoyQrK8YX01QmfB5w3UDAIpkDNozRtv1NozV8t6dnZFZVPHn/Xd3Rkt2l5e/OnKC9+bvLrY /umttS1b+e2ZyK2rCjfTzMhDA72AtYvyfHeLqiI6s/SAsZHmybm19pbdtiUPaSz2EJL2W0aQZkZN ZQeqAWYjRui+6ZZGxdQYUDnPHGaB3JKC4IvlHW7NF3Mkyz6AIMEPniEzjSBagCE+CWkWchRMnEhp RUPSzErDMMWXVQNjo9ME61kFEUujxnwARqFXs0s3JxD5cCIptS3fhaZCDCSNl75RRZoe1YAgFDRG eZqDGjStgKt9j9EeKqZ/jCqM9gIBJC5kCgOzy9KO7LLMOFtaIBVyAETIfMaQB6HGxI0Gp5O5RdNp fjii2+ruvnS/tiq9SrOrQnAt6QeZtam8nhV0btCZElZo7nwS6R+HjKAIpDCmJHpEPtEtut0ZBhT2 IT0/IuhnuHnEmds45hwOKCqsbOPI9sjPYodlAYnotBbZgegKr5jQ4UsWU7iHCT/MUimTcZQRIvSx Sz5iNnVI8YRfTvjVBCJC41ISkUTkHSbIMKIoiCteRgQv0SEcws5GpkWdcA/rDetWoIHTum/x3c57 9gyN3VVO9K3iBicHSneMNDdbv3bh9XmGA35l9prJR2e5A4M9cS5/4eDseO8o77y2j8+DRmXQ6FnQ qMa/bNLoMZfLogYcLF+aDLlcw8Zbf/0kEEtA9J85M9CFGaELL6AF6q/GRFdccLnaMvidO8RMdKGg Q+4gWpADDp61YHxrrKJRPydLl/9Tqmm8+F+ehN5Ir9UVWCduit2gWMHjkJSigYQbC8ZN4UZICalZ V5uYkbVALqYpmtrvaor9iJxsKP3qGmG1a4U4FBtSVqu3Ct8UDrj+Uv1GfL7tby3fEZ5wPa48rn4n /o+Awx4Tj8WeVZ5XX4gvtL0ee198P/ah2jnvQqYf8q5O11lZqpplqmiWQLezdl03y2zWLGWZlYah JOr+tj3ITbiDn7Hv0f7U/gV5f5urX6iLdcQyfN+xkPmZ6vyi+EjsYcXaF1gV44OxUCpoiWspS0CU UxgFDxlll6poMUXpdokhJAmKq2rOJaDGFjzBIpYpLhiA2GRxqIobdnpMT1tEpKDIAclwTHxNtIt7 XYAq3mJIhqPrkPCc8BPBKux1KTtVCgnULC7cnz9Qd9F9An5F5dGeBhXPehoW1wLUpePcS8ekNm4W CU9aR1F5zB+sZ4ixKkBQUW4oYhvqhdjbFOwaO6+epXJHDIKWmegEPJa4K7KdUGYD5OE0Q1z/WNo2 zCiQ2gGDMP8Y6cNZCPnmGVFDPCuY1+lnUbpykJehLEBKganiTUMMNgUNYgo2plxj7JDpcRLZPIGY gCARDDKFmUWyOqABIccnQR11mTuc0Ivh19+ICm4kfyjVQ9nE4gvFxeci7Wm5x/q1fEHLdi86eO+y pM/ldyPFm5xa+dG7Vntvl+QSMFqwCp31Nxgty6zvtTi6pyDG6gVbpyWRLnfBIPN0Z1DisQDfr49Z OlOyg6gdKcGkC6dOLbCdaZchQn84MCRy+737ffvlhwsP199wvxH9hf6LmstfgXXMnfPsEHe63+5x Jvor/s29tsqAfUAakJcVBtqb9e7+1e610lp5ZWp1YbR9pG70b1A25Mf7dzr3ufdJ++R9kX3RP3fO S/Pyt2MvFFI+u1/yy/5yWkrL6XJRLEa7+kWpf8K1uXe839Yaxzlc925E49CN3IMsH5VCPSbaLBW6 h1QlmWxWKv2kz3SBNROEZ4DuBKALujG2p3t6vBCLKbDx6vV6Q4Qnsgbm4HQqhTqW+GnkA/sjXXDx NiCJRDzJvco49Dnku8zuQ/Li/Vkuq+QrlWat871iUa+N42nvbXANu92ZV5zOXCMfajTynoiud9c8 oVrNg+CJmMsTrel5xb2sqxATrZ66s+EHpi6NN9FVodeA4SXLNGYqNgB4O1OppIis4EPP3Ils4hUA P31PaQoHPrMAka1hKEeUN5Vzio0aaKwoL/C9lhoc9LccbVR0oDufQubX2gv8y0Bn9vNjT2VOMnji FJQDCkstIWXHUgLDqaWxQIEkMCZhEpgiNsfEDjw30jYoPS1KZDVEhYsFmnu7YmeQ7IueMXK940EH gPadQovEPkp7zqDmFKSrkOsdNqi9J/Bz6aoTwgknCgGtUEoA/2NBeAg/xTB6DpE056AVuMkJ6kKo AnQA1E9TziDYRE8broQ84IVRjwWMP4UPGGanjSAyW9jJLuyMYddLtX48k2dRFtv91Nu5Y/5mXvPT cPzZUT8B4N9E0YPimBdfeFkLZRkqQGcoAAefx4bfUZYhGsJHA2YhmwM67m1KeAAytigUDUnyN5Ft EgpMmFITnTsabsKNRQU45QIKyMHnjGC42SuEm+1IelXEJgsRyj7/phGPNIuGjC3c7KENZ47S2bHR z59EQvAljvPx8r/rK5cOY18w9mKCH6NRMshd4i7OoJlL0jTT6Sx2h1ZJIKGxj4Atce5wMZN1RwZH VrUVuN5qrjqx9631q5qL451K0HjosRWdnYuv5+KFzQvfW3PdJ8CGEtFYj9S2fftWNZzM562xth3f Xjy+u2rN5UK+aHTqxIkb5JjO53L2UHLXxY9u78NYmeG+y3/GegiIrcpzFgf3/DGLwwv/MBKBr3vK pXiQln3dU5lv/jXwtNeeH7vQcuSOXQDFLNmKoGFxt21/7LHt2x/7qvUQFbTBGGhhfxczWNHsj/11 otGK+BzZErLQiidRmPKWVjfJwSIOxzpAzVVE+fdizcJlwJatsAxh/bNhrEC2GiuLjWAls7VIu3Kd 5XrLOqwsuQFrLm7COnA3YI1AkqID2OjPgX4t129ctXLVitL6W++4+e5rb951/Z133PS58XVj6y2W /wLwTOOFCmVuZHN0cmVhbQplbmRvYmoKMzE0IDAgb2JqCjI0ODkwCmVuZG9iagozMTUgMCBvYmoK PDwgL1R5cGUgL0ZvbnREZXNjcmlwdG9yIC9Bc2NlbnQgODkxIC9DYXBIZWlnaHQgNjYyIC9EZXNj ZW50IC0yMTYgL0ZsYWdzIDMyCi9Gb250QkJveCBbLTU2OCAtMzA3IDIwMDAgMTAwNl0gL0ZvbnRO YW1lIC9SV0hGSEQrVGltZXNOZXdSb21hblBTTVQgL0l0YWxpY0FuZ2xlCjAgL1N0ZW1WIDAgL0F2 Z1dpZHRoIDQwMSAvTGVhZGluZyA0MiAvTWF4V2lkdGggMjAwMCAvWEhlaWdodCA0NDcgL0ZvbnRG aWxlMgozMTMgMCBSID4+CmVuZG9iagozMTYgMCBvYmoKWyAyNTAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMzMzIDI1MCAwIDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMAo1MDAgMCAw IDAgMCAwIDAgMCA3MjIgMCAwIDcyMiAwIDAgMCA3MjIgMCAwIDAgNjExIDg4OSA3MjIgNzIyIDAg MCAwIDU1NiA2MTEKNzIyIDAgMCAwIDcyMiAwIDAgMCAwIDAgMCAwIDQ0NCA1MDAgNDQ0IDUwMCA0 NDQgMzMzIDUwMCA1MDAgMjc4IDAgMCAyNzggNzc4CjUwMCA1MDAgNTAwIDAgMzMzIDM4OSAyNzgg NTAwIDUwMCAwIDUwMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAKMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMzUwIF0KZW5kb2Jq CjExIDAgb2JqCjw8IC9UeXBlIC9Gb250IC9TdWJ0eXBlIC9UcnVlVHlwZSAvQmFzZUZvbnQgL1JX SEZIRCtUaW1lc05ld1JvbWFuUFNNVCAvRm9udERlc2NyaXB0b3IKMzE1IDAgUiAvV2lkdGhzIDMx NiAwIFIgL0ZpcnN0Q2hhciAzMiAvTGFzdENoYXIgMTY1IC9FbmNvZGluZyAvTWFjUm9tYW5FbmNv ZGluZwo+PgplbmRvYmoKMzE3IDAgb2JqCjw8IC9MZW5ndGggMzE4IDAgUiAvTGVuZ3RoMSA5OTUy IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AZ16C3xURZb3qbq3H2m6k5tO0nl0wr1N 0wmmExOaR3hkyE1IECYLCRC1AzJ2gMyAL4IEEFRAlAWCShwdZxwdibgGFR1uuhE7PIYo6+68HKLM A10f+Rwcx1F2+GbUmUHSvf+6HVBcf/v9vr3h1DlVdf5Vp06dqnurms5b17aTk7aQRPqym9s6yHw0 O5i+bF2nlspnlRHZFn274zs3p/IFO4gsN37npg3fTuW1FiLrlBXtbctTeboAPnkFClJ5NhF87Iqb O29L5dVPwLNvWrVspF6bjbzz5rbbRvqnt5DXbmm7uT2lXxwHH9exak3nSP5e8LKOW9tH9FmYKPP1 VN2XUgbZQn+hatpNVuKkUAVdDUvP85dRzsms57u3vqwduz6j+lN7vhg20d7fVxcJfkLu+O758xeG FbLnQDfN1BcVwNlmJObRTIXOnz+/UTFLRMWlx9LXsqXWJT1HB0DoGKkG6gHB0dJzMZsrpMfB3dkm j3qCof7kgPRcdNoEs7z8odCWo9J+up4moHh/9GpRvD+m1wv1/bEJ01O8YrzJo/ZUtS07pNYWAFYB 4pQxIjWB7wbtAR0HWWHQfnoXlARJ0tPS3ugsFQ0/hYYyarOlpzBEHelJUBIkwfqnMJan6M8jJTKs ejKW5hTdP2mivNKTQGUgVUBbQAdAJ0EWWoV0DygJkiDtRd1e4tJe6Ymooiq1Dulx2gzi0g8pgzFS 0foPYorpm0diGVkhvVaRvkfNIE6GNJcGQBzNPgDYA8Sh3hgtH2+6sDHmSA8p0N8Fo3fBkF3osgcp M/M6JKG/K5blEcbfHc3INHG3RysnpoSYkhdqhhduIya1S7eQn1RpE/ho8GXgReBLpeXkMu3UYxlK aAv6q4F6jZRDV6C6VvJQCLxeKiCvqbY2mp7qZ210XGkII54p5ZkqGZKLJkLVLtmiIVU7Iumm83fE 0kYJ+3ZElZzQMWmbZKNsaG2BVq6acUxyYI4d5khaYmmuUHetU2rBMFvgFhU2MnhZpLp0SxQN1WZK DVIheVB3o1REOeCzpNEm3yc9QbOQ/1GsuFAdOCI9aKK+KxpF9zNSoTUj5koPDdSmSTNQa0j3YwLu NzvvjhVPCVFtsTSOKkEcPt4MaTMkReqC1IVZ68JMdWGmumBUF6KPpJ2o2QmdCmkjdUjrqRu0B7II q5woHCoWQ0507LhQv5Qv5cExyhG4kqG0IJaWLizLi7qzTLW8mDM9VHNMWkNNII4hd8Zy80Krjkil 5lDKYnleAeiIIlyPSbmpqUFLHjElx6RCOEI4pkgaHc1RjVoVeRHIKjH+cz4onMRP8d+I6eYnkRf8 FyP81RH+qxRPDvDB1KLgrws+VFvI30dj1/O3aQ8kzo/wE1SJBt7kcTH7/A3eTzXgp5FfDt4PPgH8 cNT3UzXO4zEw2P5o1OURg+UnosGKEUENjAi53hHB7QnVBvjL/CUqRBO/Ax8L/hIfoDHgx8HzwAd4 J/0U/AU+iaaDHxzh/8qPihDnL/JDNAU8Fk0XJhhRm2AHolbBfhylVK65Qj3Kf8z3UwFUn48WF6Dy 6VjxWDXjCNpj/CneGS1S3bUO/gQLs0+g1EOnBSc33xutEo10R49qaj/v5t16XpUe0Mv1XqkyUFle 2StpAa1cq9J6tVqF348NZA/H+uW7kFaRxhE9IB3UzXdG5SqjdhhjEuPitAVpjylFkHaYEiFVTEnU njOlGr6NmkAcbWwCbQZtAd1FMtKNoNtBd4DuNEs6Ia0Frcdu0gFEBxAdQHSYiA4gOoDoAKLDRIie O4DoMBERICJARICImIgIEBEgIkBETISwNwJExEQ0A9EMRDMQzSaiGYhmIJqBaDYRzUA0A9FsInQg dCB0IHQToQOhA6EDoZsIHQgdCN1EVAJRCUQlEJUmohKISiAqgag0EZVAVAJRaSI0IDQgNCA0E6EB oQGhAaGZCA0IDQjNRChAKEAoQCgmQgFCAUIBQjERChAKEIqJGAJiCIghIIZMxBAQQ0AMATFkIoaA GAJiiK/vkwZrXwFkEJBBQAZNyCAgg4AMAjJoQgYBGQRkcGTowhEiYAaAHQB2ANgBEzsA7ACwA8AO mNgBaA4AO2BiDSAMIAwgDBNhAGEAYQBhmAgDCAMIw0T0ANEDRA8QPSaiB4geIHqA6DERPUD0ANFj IrqB6AaiG4huE9ENRDcQ3UB0m4huILqB6DYR/99Tw+9iYTvetXwLu8Lkm+ljk2+i0ya/k/pMfgf1 mvx22mryjVRl8vVUbHJMtck7SbWzqFqVUevBFtAEuh60CrQHdAB0HGQzpZOQ3gUl+SR9jJxha7Lt sR2wHbdZDtiGbDzD2mTdYz1gPW61HLAOWblW6+Uucx/F1kK7gWO0GemfQXiJIK0xpRo+Ef1OxD47 CX8T+UQ986z251J2spQdL2UHStnuUlabxq9isrnTaVTF4QAW1p3FM9TToKrikhnYme4/9HGuGi2e rMbZ0RS7Qg8i+zGoD9QL2gqqAoVA5aAASAVVFZcCFtbHjDR5FLwE5ANpoCryePCd6M606/3cxXpj r7goTfRTMg64I9GSSrB4tKQJ7MVoyVK1No0dohLxVcRewKLaD34gqp5B9fMp9lxUPYLc01F1ItiS aMmVYIujJa+qtS52NamygLaM8IWYcJFfEFWvgdr8qHoFWDBaUiy0S9FRALVX4Iv6DDhkEz021ZM/ qk6H9pioOlVo26lETDyzUrlpngWyyEsxGPTnfhaWmT5KPas+qH4Mez+CYxEeb2hxGexkIM6u0R3q 0fLHoVyrRmsdQh/vh74Rbgj+gtob2Kk+irZY4JD6iHqlen953I7i+2D3TrOLqLpVi/P9epa6Ra1U O8vPqGvUb6pt6gJ1SQDlUfU69agwk1pZmO8/pDajwTkYRSCqXhWALTBxlrpB1dUSdap2VPiXpoiu EcnlR4UHKJTqvQz+LQ2g96h6dVWcZeqltnO2bttiW51tus1vG2MbbSuyZdvddsWebnfaHXa73WqX 7dxO9ux4ckgPinNCttU8LlhlkZFNWeFCRoKUOLNz+iYZWVIjb1xYxxqNgWXUuFQzPlvojzPH/EWG xV/HDHcjNbbUGVOCjXFbcoFRFWw0bM2Lw32M3d+KUoPviDNqCcdZUhRt8xrumaikbfd5+4mx/G33 tbZSnmddTV6Ne0bm1Fn1X5NEzMJIffCLJ+/LYpHxcOPCsPFsUasREkKyqLXRuGuhdl24n2dwV0N9 P08XrDXcL3fwjIYFolzuqG+F2hlTDdGcDjUqEQxq9jrShBr2kzqhhjlK6RUDDj2fYNBzuKjY1Ct2 uEw9mQm9vtNaQ32fhgQ6AaLTps7pAH1JBxEDbH1fMRJo+TUWFlos7NdMw64wG1JVqJQjgQrD957Z kMrMzoyKL1QCIyqTLqlMMvuSUvaYzYgEzWSPu6iTPQ46Xzjyfye11wVZbPzaTSca2v0NEX9DOyhi 7Fq3Is/YslTT+jatFRWaIRVHli5bIXhbu7HW315vbPLXa33jTdxXqk+I6vH++j460dAS7juht9dH x+vjG/xt9a2xmupw7WV97bzUV7j6a/qqFo2FRV81Ju4rfdWK6hrRV63oq1b0VaPXmH01rBRx3xzu s1Nd60zMq+AxPsqBGI54fa11HqVjhgjo/um+vE3ewzKxp2lUsNVw+usMF0hUldeW14oqrDNRlY7i jJGqvE3Tfd7D7OmRKgXFmf46ujgRJPCNxqT5jYZv4aKwCBVDhwu+bs7WiMeszqOGlfX4h3ynSZ1r Oi+2KDgJzf/+dH7ds3bt2jWdSNYG1xA1GqULG43J82GJzYauIvWtKLvyYpkkmWV9aWkN8eQAKoMw gnWK7oQUZEF4UHeQlWy8x9pj4+IU0RkrKAqtOobvhs0gHIf5+iiuEkTV+tiYAE5LUKmYlOI4rop8 tMAXQg+xKkAFD6S4nlkOoTvQXd5d1RPoKe+psqL2UC8K1V7xKo1W9ErUGVxz0RkQO1vhbJgl+nsi WlhkdtwjhGCwNbiGmf66qP8FN8uR/cKxGKP5rDGbF/42PYxUiHC6qMV8pHpfK3LiSQkmFn42QSiF VipnFonkiwc5XCUdpkKT9lGhXIwzFiXPXKTEyuQZUSc4/xN2ctwgCRp5ovQc/Y6NYxrF2HnKpb+z fDae5iA6/4bzxAEapu/heN9CDzM3jcVp9Gqaw2ToBOle9mhyXfJD+gZ9l/YmX2Rbk8+ifjf9G/0d FryDN2YVzYP+1dROH0rvU2vyh2Sn7TSKptMC5qE2+i3+PoUdD9JD9BN2R/Lv6DWbtqK9aqql2uRL yQtUSvfK3ZbTaS/QA3SEWZPLkivxhTSGungw+dvku1RMrfQkPQebgmxAnk0+upG20Q9YvvRvkL5H /0IJ5uRLpJmW4+hpDl1Dt9B66qJn6efMzZotpy3nkrcnP0AUZtE42LSSPmST2Fz+lOxMzki+SYup n36K8Yq/AXmxvM+yOFGT/FHyZZy+X2QOdpS9ZAlZ7h++K/lE8se4ryym8fDIPPSzlO6ml+hn9H/p L3xzcjPNpoXo+RVWxDRWDI//lufzTXyTdIquxGiXwNq1tIcMitJhOkLH4Jv/oCF6n2UzL/smW8oe YH/hTr6cn5QelQ5Kv5aZ/Az87acAfNRJT9Eh+iW9SieZBe1XsmZ2A1vFvs9+xIa4wT/mf5Pt8t3y 5/KwpTgxlPg8OS/5Kc7cBfRPtJE2w7dPUowO0q/oN7iV/Ct9xhQ2ha1gTzCDDbGPeRofw5t4B38Y p+fnpXnSA9JL8iS5Tr5RflV+0/LPll22NlviQm/iwcTzideSLyZfQ+yko/1iXOCspLsQFU/RcTqF 1t+gt+k9ET9ofzpbxL6FXtawHewh9jx7hb3G/oRR4osDf2P4dF6PXlfxW+GnrfxB/hB6PyluOnBJ 8Tb/iH8qWaQx0mRptfSEZEhxaVD6g6zIxfKV8ni5SV4kJzEzIctVloWWpy37LS9bzlmrrcutHdY/ 2rba7rH/crh0+J0EJVYkjEQMsWtHJG2EJx4nXALCF0fo5/Dor2DxEH2CWShgPlYCu6eyWayRzWXX sutYO9vKtrPvsh+wR9le9mOMAGPgNtge5LV8IW/j7fwevp3fh7uMg/ww/xn/LS5UzsLyXMkvBaXx 0hxpkbRYugVj6MRV3j3w7APSs9JJ6ZT0gfRH6SxmLVceLa+VN8qPyPvkg/Jrln+y3Iy/vZbjlgHL a5YLlgtWbi2wFlorrDdYn7a+Z7PaJtuabTttv7b91d7BClkpLNcQ+5ceno81OJo/y7Plzewsiotw 6sjAyIOYh4VYFX+lGimBeUkX9bAth+fLWQJu1WUDH4Kd7AhNYq/QZiuX8GEoD1GUvcWH5BP8G/Qb FmH58j7pFsvPuY/2Yzfq5kf5EVZHB3k1v4Y/JhF7H2/F9xHvt9FD7Ea2hvazs2wau5NVsc30a+6R FrJ7qDq5l8ssjc1h5wgW0F3ycvrWpSF8rcCm4nb+w8Tjsku+A/tTnB7GjD5H77Jn6DyzJD/G7iZh N2rDLnMv4n0biV1vCdbZZqzHfOwgN1lP0kFmxR16lXWGvJHO0T/oQ8thRFQddtMPEivlx+XfJ6uS 5VhhWGX0NNbdCroKK+Z9RMkx5EXuOqx0B/YSXD5SMy3C5dmd2PUeSBrJx5J3JzckV9EvgD3Pyth5 1oMVEQeiGvdeP8UqeYPtwjq86muH9/8sTCynAfoTy2MBFsJ6OGtZZ+m2PGs5aPmJ5VXreHj7HnoU Ef0eotmBESyj1+hP9Ddmx9zkUxlNhL1TYHuYbuKt0jGayQqoA2t2HPbxupGRrEErW+G9x7Cej2Ft nMM+cR39BPdnnOViRMvQvx3tNMLP19Ma6sUM3s1iKFmOXbuUPsK409kUXA+UkY6WHsauNQCb3qI/ wNtJ064y7Av17Bq09Te6lpajh8nUzPowA4doKnbWeumX8PdYplAdG8P+BbgIVmg6Lr+nWn7POJUl 5iWn8JXSMbxjkijvwdvLS99gq2FFBsYxTDmsiSYlFsCGU0ySDfa6acUjvD25XVqfuIl+Qc9gTnR5 na2eSK9t0WtmfKN6+rSpU6omTZwQGl9ZcWV5WbD0inElxYGx/jE+TR1dVOgtyM/L9eRkZ7kzlYx0 l3OUI81us1pkiTMqa/DPimhGccSQi/2zZ5eLvL8NBW1fKogYGopmXa5jaALXhqrLNHVofvsrmnpK U7+kyRStmqrLy7QGv2a8Wu/X4mzRfJwmjPvq/a2acdaU55pytym7IPt8AGgNeSvqNYNFtAZj1roV XQ2R+vIy1jfKMdM/s91RXkZ9jlEQR0Eycv0dfSx3BjMFntswrY+T3YUhGgX++gYj3w8ompECDW3L jeb54YZ6r8/XWl5msJnL/EsNEl+/QVOFZprdGNaZhs3sRluJr1uDdml9ZQNd98YVWhoJOpf7l7dd FzakNrTRYGQG0W+9kbvxTN4XWTSO7+TtX671Sl0NeSs1odzVtV0zBuaHv4T1+kQLra1oA1gemBXp moWu78VMNYojlcG3tYYNtg1d4rAQMEeVGl/qJBOI3KAZaf46/4quGyKYmoIugxZs8EULCvT+5BAV NGhdLWG/z6jx+lvb6gv7sqlrwYZYvq7lX15TXtanZKYc25eeMSI4XV8W2uH0VJ0pmepCalxwybNM 2Oifg+9xQ1umwZKwH2OaIpL2KdS1bAomAE8rA8pYjhlZaaTNjHQp00Q5hsgMS0Dxa12fEiLAf/bj y0vaRkqsAeVTEpUiTi6FmsHaLspGMGiUlooQsc3EnMLGGWZ+UnnZujif7O9QcDcyGQdBaoZv21qn VcD9Pp+Y4F1xnZYiY2yZH07lNVrqjZJegfMSj4gaTGCqJudqUbPlYs0leMSPSD4o7i0ox7AXX/qX oXiyGlZMM5jnf6huT9U3LvQ34nSjNXRFRqK2seWyXKpeOBR+Q92IZGTNDEtejjIhca9k1iIor1t0 SQWZsNOQA/hnFUZjdUgISrOAabMMJTI7lbY6fL6RJfPfMXGb/UugePKcQJnsC9jIKIxpwRE7U1Yb 0y/LX2ads0tqbMGOwxtbFnV1OS6rm4W9rKtrll+b1RXpaosntyz1a4q/q5/v4/u6OhqwC6UmNJ48 vMtrzLq3FUNZwaYhbDnV9fnZjvl9OtuB42s/rpi0HS3hKGd8ZqSutbUcH+G4eVpDbtBc0GLQtZhA Zk4jfoeHQgh5P04JYmL/p0dcWkl404tnMr65f8a34mdGbMbih3eLqLNR3UHOElZbnNfoWWSRExI5 bHKCUb7daklw6SgrpjR8AOdRXlD5rHq4ep7ySfXc4WqqgaxcQDK+0pfpywwggd10QZMGLugW+pw0 eQCfSeROfiAvtpwSv7OyNn27Xba5Zztmp4cd4XRrnjOXZee4PCzb7fLwrNHOXJ6Vn1bAsovSCngW 2b0sW7J7eZbqzLUomS6PRUl3eawZo5y51ozCtAKLItu9FsWRVmDNsNm91oy0goI5Xnu212t3eTxz cp3ZubnOjPT0UaMcDpvNOgdtZKpqYaEsW+L8Mf16np2Tk5dHbA7PcrtHjy4qkji3e3JzCwq8DpfT mWan7KwsRcmY4XLuy/3Is8+l5xVMdOljiyfWuNhu1x4Xd83zWS0WzmZ40/YVfGTfV+nVvRGv5J2n 7b1D+GvJmeEz8Fe1Ug351mDwEzOLnPAf0hpRU+2eWmGqiMzwiPSZWSNqUWQypNstVwbvVP51+5V5 gmV85RlfyZZk+SdNAPmyJkgTBOX4QT7Jn+WX/AxFP9xxsPocK2oaanp77h+bu16s/mtiqOndue80 vcd+MP2daezmt1jJ2+yfExsFvZ14462UJO1MvMFKEG9zMZteywB+RX9DD23P+VkOv71wVyHvlZ6x 7Ms+JB22HMp+M+/tfLsnm93nuS+X+3AZKLPcLI9PdSlOR5yN1Z1NLqa7dsN5LuaJM65nqFkVWTxL d3smZvV6LQw3zy8osiZzGVcVegjFcm+Jy3AOOLnT6VFOb1Z3q3vUA+px1aIO2U43jWVjC4Ke07nr 2WnKLz31cl4QMTr37Cdn5ymfrQZfcjZzasUSqhkOrj5jJiK7+izLdE/NnEoiNf8tgf9WL1lCS7IC Hs+E0ORJE4v9Y2xVnpRgtQVm8Akh8XVj8yAh/5ixc5niunX+tetvXTC5Ub31tvCc2d8elRj23nxi w8k7v3Nq0/cTf3j93xPn2Tbfilvu6bjhjpz3pZXXfjO8PFK2bc/ie27a8dIa79FtLyXOiZ+gF8Ov kyy9OIUo+hX2dM1Z5W5wz8l/xPV4+vfdb6anuTOz3L5Mv3ub2wJ/uhxOp8udmRnnPbon3ZWdnu5y O7LFiVdnUjPrxofoZU580fSh1+WM80W6S3VUOLhDuNvRi5vvAX1Utmeill2ZrWdL2XG2X8/GMlEq FF6h1ChNiqQIVUX0lZWRkS5nKHD6YC7Tc1lugZoeZz7d7VrPjg4S03F2P4BdJX/0qX52FXYMTMQS MQVnMBWmIOJeGQ4uWS0WRPDSjCxZjTkQ0Z2OuGaXZsWckcumoyQL+4xt8oQQYR6smIPFLM+5bm54 44a2DZEz3fyD4f8s+9bSI0xeuTvxiySxDUXXr9rdvX37jT7+eeIf/6hInHvjhftffhP70rXweCki ORc76TF9+g2j1tq327+fv8+yz/5M+rNZ/emHMo9lDWSezHLlWCZn1isbPS/w15XBbNsROgm4zGx5 bsWreblXuHA0XOTtzXCpvgofh0M8E329NWlMTxtMS6ZJ+AGpKXaAMcyKTx+jyhWIbaEj9+ZYELTr R59ucjJnQSDvtDt/7KUAHgnfs2bkfrIEDjwbXF0DEpEr4lZELOKVWYoRqTjxTgi5zcCkTIUmhLCr Xgpjq5yROOdomdl6u7LyMePzxN9PvpN4j5X+577/GH5i0/x5Kzpa5nfIC0e3NPcM35H45Nf/J3GO tbKd7EG2/MiFD3d+b+Ou3dvE/xkxn2QJ/S4lfSXFCwXvJg9uPPIhMXKPvJ/ErRJdO2/BtVfXBWtv Xdl2U3ndqpuWz8V/SqP/Ak5/0c4KZW5kc3RyZWFtCmVuZG9iagozMTggMCBvYmoKNjc3MQplbmRv YmoKMzE5IDAgb2JqCjw8IC9UeXBlIC9Gb250RGVzY3JpcHRvciAvQXNjZW50IDkwNSAvQ2FwSGVp Z2h0IDcxNiAvRGVzY2VudCAtMjEyIC9GbGFncyAzMgovRm9udEJCb3ggWy02MjggLTM3NiAyMDAw IDEwMTFdIC9Gb250TmFtZSAvV05SV1VCK0FyaWFsLUJvbGRNVCAvSXRhbGljQW5nbGUKMCAvU3Rl bVYgMCAvQXZnV2lkdGggNDc5IC9MZWFkaW5nIDMzIC9NYXhXaWR0aCAyMDAwIC9YSGVpZ2h0IDUx OSAvRm9udEZpbGUyCjMxNyAwIFIgPj4KZW5kb2JqCjMyMCAwIG9iagpbIDU1NiAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCA1NTYgMCA1NTYgNTU2IF0KZW5kb2JqCjY3IDAgb2JqCjw8IC9U eXBlIC9Gb250IC9TdWJ0eXBlIC9UcnVlVHlwZSAvQmFzZUZvbnQgL1dOUldVQitBcmlhbC1Cb2xk TVQgL0ZvbnREZXNjcmlwdG9yCjMxOSAwIFIgL1dpZHRocyAzMjAgMCBSIC9GaXJzdENoYXIgMzUg L0xhc3RDaGFyIDU0IC9FbmNvZGluZyAvTWFjUm9tYW5FbmNvZGluZwo+PgplbmRvYmoKMzIxIDAg b2JqCjw8IC9MZW5ndGggMzIyIDAgUiAvTGVuZ3RoMSAxMDU0MCAvRmlsdGVyIC9GbGF0ZURlY29k ZSA+PgpzdHJlYW0KeAGNOgtAVGW63/+fc+acM88zT2YYdGYYARUQFPBJclTAlFR8wpijA0hAoSBq ifaQyiiwpNDMRyttbVltOWAZWK12t+21a7q311b3Vre1ta1c3bLc3WTmfv8ZNOvu3XvP8P3P7/z/ 93//9/r/w7qW9bVghM3AgVqzqqoZtMcxErPXaq5f50/U9fsB+OprmutWJeoWI9aP1DW2XpOoOxHP XllfW7UyUYcLmI+vx4ZEneRjPqJ+1boNibr9d5gva2yqGep3nMV67qqqDUPzw39g3b+6alVtAn+U hPmI5qa16xL1kWycruaW2iF8Ugkgz83f933qIoRiBJjVPRIIYiXB11AIS0AACgrkwBUA3EpyHNdL tH5adeX29PeXrrAUfgteNg3Aw77+F1n+66Q/fxLrHNwqxqUoVg0aPuvAccUbY3MBpOtinbF2MX6p h/WyJ0k1NI0jHz5f7lu1t9x3mPohIkGf7/VIP8tWRKaxFfnAT8fgqzlkDexDOIBwBOFjhDMIcQQR Z1sDCsIKhFsQtiEwTJ3WMw9L+xA4mqLmnh/vyz2vni8/33x+8/mu8z3nj56XFGxoOn/iPA/nlfO5 2Lf5vCAr5yPn6aR50+6mBuhC6EGIIhxF+ARBh5Sx5UZoMvYnM9ZhWoSwAqEJ4RaEbQj7ED5GkMCH KYFc6oFyhAjCZoQuhB6EKMIJhE8QziLoATBVEPwInNZ/FEsUmpC7tyBsQ9iHcADhCIIOVEyJVj6O JQrzSCP2NmJLI/KqEXjkZCO+0whRBA58mLKWFQg9CDzOZUUKraAilCPwuKZEDUfDUgShGWEztao+ 3ifME7YJRwTex8/jt/FHeL5IOCDQIv4AT02ytpMGlqnTfDLIiuyXc2V+UpfcI0flo/IJ+RP5rCzK FtEn5ohF4jxxhdgkipP2iQfEI+Jx8WPxjBgXRV7I9gkcGyXZJ1s4H5fDcZP2cQe4I9xx7mPuDBfn xA39pEytIRu6yYbTZMNNZEOIbNhENrSTDRXE55nnoT73PDcFj+Ip8qieZo8AbsVd5FbdzW5BBg8B N5FWOLc56QrHNgcFp+IscqpOHhyKo8ihOngZnAQcRPp1P/H2Cb5fv0C88ZOoMS7ySt/TnK+fvPLM 0yLnquwn8w7mSlqumrAApaUo6zabpPaT754FObRpKiI/1NcawGxfX+si3wtkFymiu3Er5va1pmDr VX2tkzGb1deqYjazr/UjzEpZNs1CpuEGMNypEBa/IS/g/JMgTAKgYklSTa3jfGda63x/aW3yfRHu p7sP+V5vzfW90obFPt/hRMvB1pm+3lat5UDbgPsuIf+Q6xc4195wP9dw8IhrT7ifBA6qrh0RDefO 1n4yp893e2KMWxO1jeFpMqMDNiRoh3WkSMjv863Bd3WqPNnVHP4i31XPkJ/zXRN+KdNVgz3TD850 oWIbhXxcwYMQ0vLdsElYSQxIf1lfqM43zUWugAouBh9hy0SoIBJMxpIO2rV1C1BB98N2bOGxVPfc Ha6zoZG+05sGkv+O87u+ah8w7qC7VYPr1dBHvmdCi3zbK7RVdFf0c3DwMddNieqqTVprI6upLt/K 0GjfsorYRFcpV8qXCoutslXuep78Hm1LF2lSrxC7fid2PSp23Sx21YpdVWLXErFrsThCSpX80nAp RUqW3JJLckg2SZHMklHSS5Kkk3iJSqj1JGrnymjZwumkLHq0Bsqq/dHvFgb7iX7+0qgQnE6itjIo WzTdHZ2YWYZCviA6IbMsKpZfXdlLyD2hKL2zn8AiFCwPq2/xRm0zKgeAkNQtd3tZHt9ydygErsz/ +bgvNZGy8tYB5PmCQ6Lva9HXIGJP2UJs6mJNXV+LXVqTe1j0/rKFldEnhoWi41ghPixUFm1a6F9W OUD+Rr4rKR4g51kWqhygQP5WsoC1UygOhcr6iUHDgwg5j3jQyjLEE8ZBhOFBRBiXwJuTwAvj+4hX xzLEQ1sd1vDCusR4dDfD622rKynurcMEcYzToU3DaTNO18YS8hO0FeG7xb1hTBAr6VNSpFFWlPQp YkFZdLw2UkUF4oQwCVX2fluBGL0V37JRorN/6N6kdQ+QBcAQBlD8FmgoR35AaU+gcE0XUbgmRCHN yIFvFlb2lQZKSzqLkR/cKVar0mp9rZHSkvpgSaT4X6PVhf8/aIehjRTBECZc2uTLCuSy8r8o1k4/ uPzNzp6SWqQsWFKLEIl2Xl/vjm6u9vt7O99kHf4olx6prqlneVVt9M1gbXG0M1js712uvfeT7h7W vTxY3As9JYsqe3vU2uK+5erykmBVcehg9R1Nu340112X5mq645/MdQcbrInNVa2995O5drHuajbX LjbXLjZXtVqtzUVKGpi+lVf2SjA9NAPliOUHqUGP2hPxBkLTXUrzVE2VpgTcN3sP80D2gyEzFDUG p0dNCEzLsqdlT2NdPEY22GXGZstQl/vmKQHvYbJ/qEvBZivq8hDjYfnatfi3bt3FfP3FZ/na5ZmZ 6zFlkJnJcMj6dWt//Me6163NRFir7R66/pL6fmosqY+qnZGoP1gc1bEG01BDarB4LYBwGDwIycJj 4OHTwQ0QP4XwOctjDfHPWT/L6YX4X4SXwEb/E/PDYIv/F0YKvwKbFpX9HwnXyDVivIgPvvlPH/IF HMKO+4fgn+PkwcNow3PgKbgSlsGN0A1t0INhyXvQiHH2MdIA62An7Ccp4MD+7bA//gwUQCtiShhj 7oA9MAPmY/sj+OajOMV2iMU/xRzfie+BnfHmeCfi7I+/CSmwGK6DW+k5cIIHMDiDrYi9j1i45Hg0 fgQy4WZseQAG4o/E+3EEO85YAwPwDZfEpXOvYQhVCldBPazGFd2Pcz0Bz8GL8b8yz4+0r4BuMpsK 9N/i3+C7MgyDaYi/CK5GSg4iH46SLWQfHc31xdch5SYw4/hjYCxcA7fDz+F94iY3km3kVfIeOUPT 6K/4ufE4jIBxsBD5sBpa4DZc3w7YBb+AKPTCcTgJn8EpUk5+Q17jb45fEZ8br0ZK2KijIRvfm4Cr rYMO6IQHkcNH4BOCfoLkkGWkkTxJniIfchijcJu5rdwO7lPezQ/Gvol74/vib8b/gGEjxYDQjr8k pGEkciYHcnHEiVAEM6EMFkAl7sVypP1apG4t7sVNyLvNuJI74B7oQq4+CPtwF3twZQ8jn9hvAH+H 4Xn4DbyN55VvMASViI04cd2FpJQswd8y0kKuJ63kDnInuRt58QD5JTmEv5fIcfIhclakNhqkU+lv 6H/RP3IKl8kVcku5v/I2fi6/l39XvDW2MPZI7PV4G1LPOGwDL0zCiIHRuwDPNIzmGuRJPdLcCOtR ztrhTrgLedQB25Dmh5DWh+FpeAZ/L8Mx+AA5/CUMItcy8DeajMdfCdI6h8wli8hipPc65OUWjNke w317m7xPviTf4e97SqhMvXQ49VE/zaLTaQkto3PoUrqcNtO19Fa6g+6kPfQMPUe/5Sycm0vlxnAq NxN/Vdx1XBv+XuIV3smv5Gv52/ko/64AQrGwQAhhQH1Wp9cZdVZdvm6hbpvuaymIUtGD1P/oodeS A2QPnENefwn/Rl9E+czCFS2FlXA7atQgVw+ryHayPtaJAXOcHoJjXC7qBeUrIZvbQT5DLizkUjhR +DNXJZylyYKH28G/Q+rob3kJ+XGUXAWgTimcMnnSxAn5eePG5uaMyc7KHD1qZEZ62ohgasDvGz4s xZvscSe5nA67zapYzCajQS9Lok7gOUogqyRYGvFH0yNRPj145ZXZrB6swoaqyxrQvGFT6Y9xon72 XhV2/QhTRcxrfoKpJjDVS5hE8RdCYXaWvyTojx4rDvr7ydL5lVi+uzgY8kdPa+U5WplP1yomrAQC +Ia/xF1f7I+SiL8kWnp9fQf67+ws0mvQzwjOqNVnZ0Gv3oBFA5aipcHmXlI6lWgFWloyuRcF0oRr jM4OFpdEZwXxVRyGSyupWhktn19ZUuwNBELZWVEyoyZYHQXmWzI1FJihTRPVzYiK2jT+higuBzr9 vVlHO7b2K1AdyTSuDK6sWlYZ5apwjJKoNTM6E73CzI0n3dlZ/eTRRZVReYYWNw7A7Pjm3lmbizFI wdnQrbVfju7lOkrcDX72dkdHuz/aM7/yssG8ATZkKISDZmeVLagMINXBkq3oiNMwPNJWgIMSdw4S ztrYMhMLTkQOaZFr/VE5OD1Y33FtBDcruSMKC1oDfcmz1YH4JzC7xN+xqDIYiBZ5g6Gq4pReB3Qs aD04S/XP+nFPdlavYk1wutdsGSoYTZcXanEXEn1aSUNnJaT6IqsJozE4K6qijNX4kZLKYJSmTWRJ 7UToqJmIO4JPiCBHG5B/kQ5lMq4uKqQpQX/Ht3hkjgRPf/XjlqqhFl2a8i2wTiYul0QuSqoulqOZ mdHRo5mkiDNwa5GyqVq9IDvr+mhZsFnxR8sw2ILySnwpNDkHWR4IsF3u7FehGivRzfMrE3U/VHv7 QM3BkIRGWM/Riz3Oxaxn88WeS69HgijOz6CJB3BGpfRLfxbFZS+pnxwlrn/RXZvoR/Up8ffyQlpH eWV6VUenNz3SsTWEUl2KWt3RURr0l3ZEOqr645urg34l2NFbVtbRXILamFhSf/xopzeqbg3VE2Rq NC/Bjah9RiXnpUwysUS9HJb+v+MdxvFKt4aiSkQbsmxhsGz+0kp/SUdkSLWGWti24rCe37izgbwF WQgs38Ny7lEoZGU+Eo/xL0A5T2E05m3YPnkIGsl6YFAv3ACrsa0RoYDlNAfLV0I+vh/AdygyN3Ff BnhbqEO/B+BH/8OY/r89zONe/mA0qT3C5Y3sGotdcv0fj4Txxz9/8CJJewxaakQvyR4zWPC2z6rF fSzqcWqtLi1NhVQohjXop68i79LV9DluOPcZX80fRZ+ULZzQjdFtFUeKD0jV0gn5l7jyLFx6LxLN IZ1e1SASnoDAyTxIyrvH8A9y8o7lHBubm2cNWNMC1kAW2RJ7goyM/UGA76GA72Gc24PJDPRXHGSr XroS9JSrJ0fhLNAeIM0YaFCYxa/f4s6cq5xrWRMunDNYCEWnccyCPOee/ceOsTEw0iVvCW/hGFeo yVi9hqMOjqOUEA7jRo7wdLZAZvHoAXpvdGd65ionlT9ZbZMmgbuosKiwXZgzJvMm5eWxuU6SR8iy G2IPe4Sv/uFgF2mF8VPcEuEoRhcZcFz1NXCtGETt5Xi/akybIck+401paXYP+b0F70Qo9BOz6hRu 8gi+m+wmOcVFDsNzqW2W2aNS8CbnWdeskdc/oK1jzum5yndzTp87jUTgYopOD4ZPYjHntG3S2NwZ req4YSNMbp0kplnTdW65Fvy21Foy3JFSCyNMWJKShFoSUHy1MMyJSdCcVqsdQIZOIW1tbTBrUeuh 9Ay9IUOf1k8WHBTSDUjCgj7Qy0QpzIRMRAkTMT0jPZgq6ripJG+czekwk2AqtSq2vHEu4nDljRtf kI/9Om5at3PUlIVtc2eQvN1Ltr1z3f7aQ199/eJdA4MD99dU3HVndWQbv9C8Jre0pyP2daQmNvh+ 95kWciW5hTxOGp6/8O6+lw7t2/vLJ5E/2l7jGYXJyww1Q7eSxwtnHa/HGJTjdGK9wPM/2Xnpsp1X 2N4XKviDoqLTCsqAHWWA0+Rg/34udOzYhceYPNB4DO/ga/CkIqK0/16tGgkZXERpNz9mfs58QhEB i2+ZuAaKu0lbOV4nSaIgy7wgG3nZKEhGnU4yGkWJiDJPHzES6idGUVwBBCWCUCPPr0iIl1HC4E/Q hWSpn7yhKqIq8jzHAb6HwZXC/Yq8DEYEP1LkBYvybbJnEDd40pDcsXUkK4OFgyiBtkntwpjM9pte bh/jZlkmCgP+tSsvvywWtr/cjplSiH9jcwmqQBClNMgFOHuAS8/QiZS8+ST56tDWmP72PrLzpsne pNHC4X+UkhdixXQpuf/59Xd3Mh0pj5/ib0Ad8cIJtdiTXDTsSnqleba1zFtpvtp6p3UP3W3dlbzX +yR9PPkpr5JBR5qzrGneCXSiudBa4H3SKmdKlrjyn7ZNRo7EFRywn7ykpnk28bJywPIwHFDxfBIh zWQz6cGYUSwiKwhVCFpGQvqJWzW5Wk9IJFcql5olThrAO/QU5buWNSj5uCLUBFQDVAJMTmoaMNzu Fgy6NEeaPt0tuKrAbsAkSfRUgVO2VaGgJ2RdE+MwSdLxwdR0WpBvG4GymyRSlFrqZII8nnuvpyB2 /lePnd65k9B9T/9j3N7yv26INrwdvfVFSsee/+ZhUv/t12Tek+//ezYZtyl24dXYW7G38H4NT1bA /VGTodXqHJBJrtwkN+MFNi/QEIa1IkjCGzr6BtGJRIwAmlR0BApG51H4BI2Xzo+HqCY4CidA6MKE yhHso5PwtCgxTV8eXt4SxoUzcT6pnARmhwbZ/obXoJ0sCDgDVnIoto4biLUIpqee+sc3SFEb7mAe UmSHdjVN4RWzYnvW8pxVUCw+a5GTS5PQ8hkMeqps0smEAo3Y+8ka1S4bjHpjRJFJ4iL+rMzLA+Q+ vOH+LrxGm/8cS5kZYsQgDWiAkjkbn25Otwr2KmIRjVVg45QqMEmYDLG+jYTRguRZHVSHRsPDSsPR ioy3ct09Cz98/C+n9029u/aJXcLhC73vxM78jKSQem7ehb5X+8JHCTobCpPjn3PL+KnocXLhgjpq l/1xy/6MAUt/hoBXvzLoudxxZDQ/mV9v32Lnh0lgzQK9oqf6w3hPnEayVRmVC4yKkRr7yRXqVWqw PNgUPBA8EhSCQTfnvNfnyMEr/I8dvOOctcIt+gP6rArOENjo948bnhs0ct7hpu+Hh9me7UN7hERE oBk36hN0u/0UVEXn2OjsGlVXriMW3WYd1Q3gpe5YFFkmrMogsu4zpTCJaWkOk13cv4tGPHw6vObc 6TD2aKy0ebxmxZKueEyLSbLXnGxdTDKZDUYTjJsNa8JpzOymF+RPJRPGF5F8ZpJ1YgYzycPJMLTD ScF0tI1m6mQmeSopoI/M7lly58+vuv2OZxaRjAktdde47/W9GL1r7yh7yu4k+/ye8OxRyxfOa1Nv mzP3kc5l95Tbk0eMWZWlLl7vfnJv3QP3nb1w29QJ5KORKcqosrFXXb3grtuGdiOMu2FH+3C/Ov6W YY8pzyno7O7idnHcWMmJ30Ac3WaLhfdU6EW4FxWbnLNV8AaH0wIbyVrnRjATcz/19Fk2igMoh6jc yI9LHk5TbWRV4eCahICNcHkFaxIKmGUxuA1OZI3sWAyKzrYYXEbPYuKVMMFLME3NL2r5D/7JZhUD TNxIQHNhOnr0gfRXuwc+O9X7+Kdk8Hp5+7WPxpaRP+nHzlxds5UsSXriKeIhMrGTQOxk7Jvcg4fI YEdxzS+YXWxEPR+radUmNc0ppUnjJc6r6iycHY+ulnadqDcY7HaURxu1y3qjPmzoJ42qHqid2MPM Dg7gVzGmTD/oEm49unVNm5hkWFEQmENWFcXKC1be0iAogq0BeO4HX5xnzbOyLXc5rUGr5nWd1sbu /NvmdT7UXb0k0i4cHvx61qzerwZX0Ic6Nux+efB5pkNIO8SRduZPQ2oe4Fc2Wo6f2DC+PEstuEeg E3QijyEVSlAYgzMQhFy+nO/huS6eKDzhGfESEt+yRiMX/RHmmjUqCl80SJqXRfoau7u7+S+PH//e yad//wHjXT3O/702/zR1NAi5gipw5UJUQM6xOC5McqEczR7XBUQBZhFVrAswQAqAV86xSVkwV6SZ PcaB+m7mudjIq5FUPcpjED5SF6fzGRI6AvN4foJUoB9vLuVnSiX6mWajkqamNaVtS9uXdiRNB2lF aZSTg752navdaGSOUadYrcnJXm8wiIGPJ4WjQYsStinWLiu19pMG1eD1JIdTFG+Xl3pZvQDo2tRg +DJit6F1OIJmQVbwOqwcbUQXrucEiPPQWCSKieWMSASng4UncV24qkSKgoB/Q6LAjCsz8wqGLtZJ KBNkDZpQXLZT2/ikH7Z/DBoE3WWCsPr2rI4Fy27x5rcvuKmrOzB7zIoN2+fPrF3Pp+9YuHTF1eHw E88PZtAHW1bk7/z54E7ad3vjw38YfH9ItnORiy5Yp6a6pPQh2bZxLhsKNvLHaDK5ULSpS28Mm01D gr3WxTiQEOwklI3CQVwUrimxlMQqcAUXhdru4AUHb2sQ7ILzfwi1trbhVFvM0LIat+R2Li29YdaI 7SMXT7z2Zj59Z2XFhNA93YNr6R3rG6f87OjgC0y2C9A/1CLtBryXrFftt3jIBMlZwYmWCtlgqwMd 0TFzY6xDaQL8qKuZGy2W1qzuaJKkSLbFxKw3LgakbjFxUSxZRbQ3JgMmSOxikkQwYVftCTNDwnYW M+AVFgYQ1H5ZCFxwqvfpL/7Ud+DPO+9vqt9xf1PDdqb+xB37PPa32Kexz9G62N58/be/O/b6G5pe xhq4CNJuxZvh99X0W3wYADlNaFW8aZJi4pzeCowadM4KkwHQieNJxequ0/fTZHUUCqCVWMNMb5g/ 2qwJWVSLI86CQUEF6gLu4uYM1xQX7c5JZRCPEkkoaWhvinBvhnxPsitZNEppLqMbDayISRKaWvDI XrZqtubESUFVUobxwjDe2yCk/MQwMbNlNjvsFmcD7zCj0bIoQ0YLmTUkusOJkzEsPcPKXcayxvZx G+fVPVr7x13F12eaO6qX39NRE7ov1iC82LHkqo1/PxD7a+zDUnXwe+6RN3/9xlsnXnsvIa+0ROPb I6qlXt4g01RVZ+CIQf5KOky2gAE/9sua4FpRofGeS5WbpRMSLZIIxuBPqWlWjqLsWjX5TfCQBWQs ChNB09gT+FGH2TwbCz41RWW6uiaciMDQh7Mj2ZBku4wWXjBbTBaqs/CGBsEoKD/I9+i2tku6myRq PhtVtnFL3uKC2XPGTcjPmauk8OkPNc+a/FjG9Cl16wbfxvXl42lSxPWNJMnqQoPCp3kVR9q61N8q rzjeo/9hfc9xin5hPeUwJaUSEsg0+VOnmMYFSgLr6Bbaaepw76B7TLvdO1N/QZ9wP0sPu18zvZr6 6sgPTKdS/2506wN+vOKcpU4w6h1GjPj8AW6UfqK+VL9Ef51+k/4V/dv6c3r5aqxs1N+l36Mf1OtC eqLXe/ikeze7iKufPK6O91TYRHIvk69zfEWGIWnjCuzpGlGniAREP/6Txscir+BBp0eMikfFE+In 4llREpndcKXUWbrIxlvgANrL4/AxnMFAKjYK7SAGAefCa1oGz7X8EOQnjru4A0mT2s1jMs14+iZj kO1htIn2Ccyz49kzIz1jDMb041kglGCx05HkSkJr4tAF/fn3mdZFIg3Zvht+uU59endV91xLl+Px yPJs75bnGgtfeiz2KrkipXnVillFQfeIgtk3zrvzidLrV7ufnlM4JdWRNaXkhgUPoJ0hEIh/TV4X dqGV6VJtfk8u/ptIOf6jyGZPl6fHI2Fw2aUGTIrcbdHr4Cty1NXOGcxWk80gGUWLopAu+NLGRLFA DYomm9EWBlERtyFzeFbwi7nIrXL8rxbGKRlDo/uZrRoKvC8UKt+dRHuKIsf8BLsK+BbjhcHCHDwE ERJOS8LYOj29wBosyLNOQG0LWpEBGPU867hi7JzlwcbG7h07TPZ8z0P7lCuu/RnFUEdsjN29dbB7 iWcEWxseSfin8LxtJavV8IPwoLBbt0O8T7rXtNfcbZVkRbJ6FDcGJPYce5F9s/2I/bg9bhevtHwA Hwof6t4W35HeMb1vlhy8Ii+Uu/guWaA8lS3KDH6GfBt/m/wW/5Ysn1Z0or8/Hjwom02Y+9UaHqx+ 4CndwP51BgVHMZv3yKJDlkWTbDBsMJpQQE3MN+/hdQ6e18n38shJngejwSCKOh1e3OisZrPJBHpR MRhl5sh5k1nG/0rKNarGciOH2xJS9f4i+YBMc2SC/J+vyjkKKVIOKFTRamour2Kow+GtT+gZ/xEM hgZIG9P7MJ7Dw8nuwTVhjOKTPRip56ETzsMN0Lw1+mu8FUo4a5ayH0au1kk5yskfn9KHDusXz+yZ mSjAa1pQgsMtAZJnT5pgTyR4WM/giDH23a6OvDEdD9yaNW5HV+zMrs4AftQY3HPyQ7p68IHfHqPX fP8BvfHZC8fZrrEnnqF9TU1ULk/xOyyhBG+1iEB0RMRvazLREwMxEhMxEwtRiBW/ttmJA7+4uUiS sLa5qqZW11zb0tC0UljbWLW2nlvbsEGoaWpsWk2mkRnaB64qUkvqSQN+5FpFVpMmPMi3kLVkHbmB zUzwthC9LD46dm+4YH7ZvPnzMqe1NFQ1zq1qaWm64b8BkbhHkQplbmRzdHJlYW0KZW5kb2JqCjMy MiAwIG9iago3NzIwCmVuZG9iagozMjMgMCBvYmoKPDwgL1R5cGUgL0ZvbnREZXNjcmlwdG9yIC9B c2NlbnQgOTM2IC9DYXBIZWlnaHQgNzI4IC9EZXNjZW50IC0yMTIgL0ZsYWdzIDMyCi9Gb250QkJv eCBbLTE4MiAtMzA3IDEwMDAgMTA4Nl0gL0ZvbnROYW1lIC9SUUtPUU8rQXJpYWxOYXJyb3cgL0l0 YWxpY0FuZ2xlCjAgL1N0ZW1WIDAgL0F2Z1dpZHRoIDM2MiAvTWF4V2lkdGggMTA1MiAvWEhlaWdo dCA1MzAgL0ZvbnRGaWxlMiAzMjEgMCBSID4+CmVuZG9iagozMjQgMCBvYmoKWyAyMjggMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAyMjggMjI4IDAgMCAwIDAgMCAwIDQ1NiAwIDAgMCAyMjggMCAw IDAgMAowIDAgNTQ3IDAgNTkyIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNTAxIDU5 MiAwIDAgMCAwIDAgMCAwIDAgMCAwCjAgNDU2IDAgMCAwIDQ1NiAwIDAgNDU2IDE4MiAwIDAgMTgy IDY4MyA0NTYgNDU2IDQ1NiAwIDI3MyA0MTAgMjI4IDAgMCA1OTIKXQplbmRvYmoKOSAwIG9iago8 PCAvVHlwZSAvRm9udCAvU3VidHlwZSAvVHJ1ZVR5cGUgL0Jhc2VGb250IC9SUUtPUU8rQXJpYWxO YXJyb3cgL0ZvbnREZXNjcmlwdG9yCjMyMyAwIFIgL1dpZHRocyAzMjQgMCBSIC9GaXJzdENoYXIg MzIgL0xhc3RDaGFyIDExOSAvRW5jb2RpbmcgL01hY1JvbWFuRW5jb2RpbmcKPj4KZW5kb2JqCjMy NSAwIG9iago8PCAvTGVuZ3RoIDMyNiAwIFIgL0xlbmd0aDEgMTI1MDQgL0ZpbHRlciAvRmxhdGVE ZWNvZGUgPj4Kc3RyZWFtCngBjXoLfFTF2ffMnNtes2c3yV6ym+xuNruBbDCQBMIlkhNIABvDNdFs TCABohBBEgKKihoqikYUaqtWrAWtVau2bC7QBfEl9da3KsJrra3UCir10tcIr5+iosl+/zkbEPr1 9/Y7J8/MMzPP3J7bPHM269aubyMW0k0Eoi1b3dpB9MfzM2TPL7t2XSBVtroJkeuu7LhqdaqcvooQ 6bOrVl1/ZaqctZmQzFMr2lqXp8rkO+STVqAiVaalyPNWrF63IVX2NCHXVq1ZNtqe1YJy7urWDaPz k3dQDlzTuroNOZ7xCSSBjjVd6/QiGc/zqo61baP0tIEQ83+k2s5LKXCVfE7KycNEIQx4EbmMEHGF mE0klHm7xLbd+/nW00ts5V8avAa986Mf5Bdw5AWxY/uZ3cNXqcRgQdGo0/MG9FOmj8wlM1VyZveZ G1S9hjece9R9pE4Y0x9x+48cEMaS4wAmjO2LZvv3CflCdt80v5YQQv2OzGJb5TghgBGL9DSAdA1g N+AgQCRLhBy0qkhvAXQDdgMOAo4AZEKQ8tYAYA1gJ+A4QBayBV9fwK9W5gse9PVgvzbBRU4CkgCB +JEWAeYBlgC2AXYCZJ2O16wB3AI4CDgFkIkmuPruLcHaXX136Vl/+6pivdiaKjY168X+y2OpvHZB Kq+6JEU2NUU2oTRVfdGMVJ5fmMod4eJuDN5vshYPVjoFJzbpxMI7kFL2IrFRSvxkl5BJ4gAmYKl6 jSY4+vMixTsPCiKhAhMoWU78yUGB9lntxZUmlmQniYP42WdsKNXChvrT7MU7K3/A3ie7AQcBAnsf 73vsPXILO855jrQCsBNwEHAYcBIgs+N4j+F9l71LbOxvpAhQAVgC2Ak4CDgJUNjfkKrsHa4xesrx CgBj7yBV2V+xrb8itbGjwI6yo8lB9se+sinF+3QkWjSK+MOjiMs7ijicxQn2Rt83Y6FREUgaGvWs kEumkxIhty88wZ8Q3H3lK/0J9kF/IOrfVTmevUniAIaVvImZ3yQBwHxAC6ADIAN7C9hbpBuwHbAL EAdAy5CqgAB7BfAa4C0yHqAB5gMM7Egfpkmww32RGf5KJ3ud/Z64wPFD7D/1/DX2sp6/yl7S8z8g z0H7K+zlvhw/qTSjnaCPilxFXoR2if2uP8/hT1ba2UFw0I+0CFABmAdYAtgGkNlBltu33O/AIM+S V2DDftZHPtHzx8mjBqK1+7XITChggCeRqRcDQ7IzsDPCtMj9D6LIk8g99wLjSWTzVmA8idywCRhP IquuBcaTyPJ2YDyJNC4BxpPIvDpgSBLs57/Ny/eXzbuaBipt7Dpw6Tpw6Tpw6Toisuv4S74R+Rof 6isoAMd2aNGxBf7u/bT7AO1eSLsfpd1ttPtm2r2JdpfT7sW0O0q7fbQ7h3ZrtPtZOhms6KbawAXF KZqbdr9Cu39Nu7tod4R2h2l3Hu0O0DItwYJ9l8DqkFXrWX8lNzoW7L94OryPjQXB0SB0PgifcBDp YUBSL2kgCuSmiD05PM/tL6hIlS+aWrymcg57AR1fgBheIMcAIgT0AtToBQzyAoazIa0ALAEMAk4C kgAZ1LnYxzY9tSEtAlQAlgBuAZwEyPpyTmIpjKxBype4W19YEdIKwDxeYi/gzcUbZEEtW/WpUXWO sM1HbTl0Xk4yh5URpxOO2WE32BPUuvcr69dfWYmx0sjuYdtINgSxfTTf1vdNtj9Bf9oXedZfmUkf IDkitI5OIREaRj6ZdOnlicRn4PWlxMeeRl7c57sM3Wx9kUL/fprGe+31f+M74f/El2BAP/Y96/9z ICHSPv+fUPP0Xv+bvjv9fyhKGFBzIJKgyPYHdNJ9vsn+X7+ik25Cw44+/8082+u/yTfbf7VPb2hL NSzuQkmz+RdGGv1zMF6Vb6lf68KYe/0VvsX+8hTVRN5nr388lhBNoQVY7FifPmkoRx+wvixBV2iF yv1KgzJPmaQUK4VKUPEr2YpXyTA4DKohzWAxmAwGg2wQDcxADBmJ5HEtyk+9DFk//GQoNCWijqvw MJS7GaSEUQMjPyDxdKGG1SyaQWvig8tIzdJA/PSiUIKaFjTGpdAMGnfUkJq6GfHJ0ZqEklwYL4vW xJX5VzT0UnpPDLVxdkeCkrqGBE3yqtu8ccfMhn2EUvttd3t5Pua2u2Mx4nZeW+GucEy3T5lV9S+S Fr2ypSr6/eP+Ho26o9nx+2sWNcSfyo7FizmSzI7VxH+8KNDUsI9+Tk9VV+2j/8OzWMM+YTr9vHoh rxemV8ViNQl6mU5HAvR/QAeNQQY6Aw5mTkcChpwU3Y4UXRj9QZfHM9AZjSSs04WNRp1OpJyutyuv uqo3DwloXAHSpdN0uQLn07wSBk0YCWic3eQVneYVZzeniU/Xh/H5QJKDBCQ0i/h0Eh/N0kn0lffq JEWjJHeeI7lTn0lIrUan4QmGsR4/S2M9DprzGPm/o20zolHaPy22rKm6LVTdEqpuA7TE77p2hTve vTQQ6F0W4w2BuBBpWbpsBc9b2+KxUFtVfFmoKtA7Te/3T81NvHlaqKqXNFXXNfQ2aW1VfdO0adWh 1qpY/+z5pWUXzHXnublK5/+LuebzwUr5XLP1fv80Vxlvns3nKuNzlfG5Zmuz9bmIruPzG3oNZEZs JuTH835mNkFfW7zB2Ayn2jFdV95pQffN3v2IVp4k5mgsbgnNiFsBXK/HVY6r5E2wKd6UhmrbaJP7 5mlB73765GiTimp7aAaJrlvftZ64q1dWpf668KBq3XouilQa5XX/8gFJdVxrreKxdU28YFFNvGJB Y0OvoqC2pSqGuqln68zm6kRyMFV5ESqnckJBOEfI68p5ndE4Svj/6oK+JlSDO/sQaDzbT7Ucuo50 xYR4Tk0dgyuoawQbmhob9iOW4odEVwwb7KJR2nV2NL4PHSepGoJtd52FdetHsVFerBvNddKuKIl2 nWXJ2eGinFl6ovNqXRSuTdpPPIAs6QniESME95/kR4CPeT6yMvkxb+c5+wccHb+dcCDkSfJrupL8 mhwkz9NT6LWb7CMDhIdAVeRnZCP5CdmCY60RNXeShXgl1P+EepIDuJk8ggPzEXIItJeTm8l+4qTu 5CfkFnKb8Ef0uo1YSS6pJPPJGnI3vTS5njSRY+KtpIxcSq4hHbQ72ZC8J3lv8jHyS7JP+M/kMDGT LLIM76HkZ9Jfku+QcehxH3mQHKP3GvcQDbN0g/JhspbsEJpFmrwqeQYrCJLrsAaR1JJDdJBFMXob +Yi66UZhJkb5RTKefBFUPtJMVpAdZD+dSGezoNSUrE0eIk7MsQGjPkj6yF68CfIcOUot0qnkY8lT xEMKySXYzwB5nQ4KI8ObRirAMQlcGkumoGUN+Q/ye3KEhujv2BrJIhVLmnRD8k2SQSaQeqz2CfT8 kH7FbsZ7i/CyOCs5g6SBLz/i3CYvkfdoFi2i8+hlbCxbw34urCUGzDgB73KyEvz+KUZ/F2q0l1nY YeEX4tPit3L2yPFkGiQSIQ+Rh8nvqBU7DdAu+kP6Fv2AzWRL2EPsfeEn4q/EN5RW7HoxWU3uJk+T r6iDTqYL6BV0Bd1It9Af0QfpIXqEfswqWR27mp0UVgidwnPiDLyLxC7xVul26S7545GGkRdH/mvk q2Rx8nayAPqwCau/j/wcO9tHDpO38R4j71OJmmka3gAN0np6I96b6d30Ufok/RUdwCxH6Pv0ExxJ X9JvGU5aJjMvgh8eAoXYWkSYP2E/Y4fxHmGfsm8El5ArRIWJQrkQE9ZgVVuE7Xj3CO+JWeJhMQk+ F0v3SzulJ6WnpeelU7JF+SHO+Ne++8VwwfC7I2TkjpH7R/pGBpLvkUzIEKcHrmDlWH0r3nbI+35o 3G7yR2oB77JoAZ1OLwVnltB22kk3gJOb6Q76S33tv6EHwKU/05NYs5X59DVfxCayGWwe3sWsjXUi GLuXDbC32BlBEcyCTcgUCoTZQrPQJqwTrhfuF+LCa8LfhPeF08J3eJOiSfSLuWJEjIqzxSXievHn 4kfiR1KT9Kr0d9kkr5ZvlxPy/yCqma7MVxYozco2Za/ypqEF2vkC2UN+q1vtaEKPC5uEamEPuYeV iB5cYV6HPi8hy4VaBk1lT9I72E10gOVJG+RpbBqdS06JEfD6ZbaTnWbThFpaQxeRdjYhNZycIT4F rFx8gQyJB7C31zHyBtlCb2YnZQvpQ4w0BTHSS8J4MSq8So4Kx6giPkL+Kpqoiw6xJ4T50ILnxOlS AwkKPyO/ETrpTWQPqybE9K1hK/R4Ln0KfqGOFtOvhSTC4LnQojLhA3IruZr9hQzBju8gD9Dl4lXk HlJCN5KPyOOwirHSNXKBnEn/wFaKPSydDhAm/gq7m0LzqCBlkM20Wdghn2Rvk/XksGgi7wrPYPWH 2W+EWvGUtJCugAXcRG4nnclN5HqpQXyDXkUEehkJi8fh3TYKxWIQ+S3wKk3waXth3fvhByqFWtS4 oTmXQi/q4SF24P0p/IQIDVoJG78cXux1MiDXsQS5Skqj8Dr4UvPqyELSmHycPJi8ilyTvJeMgz/Y ktyIEZ8kfyfbyJP0tpEbSQeukm/Dti+VZrHD0qzkONbD3maL2P0XyhfcDlM3+Qfe30Ay06VnSY/4 Z7KIVCS3Jv8E7R4DD/sgWYqA9QR2+RlmmCMMkpKRuaw3OUvowH6PkQXJJ5J+aiIrkqvIPHKA/FKR SKsShYzj9A3s90bSxhYm1wltIyvBh23gggZurYf/uVObWV9XqVVMv7h82tQpk8smlpYUTxhfdNG4 wmjB2DH5kXBeKDcY8Odk+7xZHrfLmZmR7rCrtjSrxWwyGhRZEgVGSWF1aFZLIB5piYuR0Jw543g5 1IqK1vMqWuIBVM26kCYe4P1a0XQBpQbKK/+JUktRaucoqRooJ+XjCgPVoUD8UFUokKCNCxqA310V igXiQzpeq+PbddwKPBhEh0C1e0VVIE5bAtXxWdeu6KluqRpXSHvNppmhmW2mcYWk12QGagYWd4U6 eqlrOtUR5qqe2suIwYotxrNCVdVxTwhdMYwQrm5dHp+/oKG6yhsMxsYVxunMZaGlccIjpahOQmbq 08TlmXFFnyawEjFOnNwV6C0c7NmaUMnSlqhleWh5a1NDXGjFGNVxexTzVsVdN5xwf1/E4IjJtpzf 6hV6qt0rA5y4p2dLIL5rQcN5fb1BPkIshjHQl4VntfTMwtRbIakaHovH2W2xhji9DVMisAzru0rt LxX1hlvaA3FjaEZoRU97C0ST1RMnC68P9mVlafuSx0lWdaCnriEUjFd4Q7HWKl9vBulZeH2/Rwt4 LmwZV9ir2lOM7U2zjSIW6/lIG5ieatMxnZxjNQvPcZbyNYYuQSQYDywLYCUNIexpMk/aJpOeZZMh ADwxil7x5ZDIyrhxZkuPOpXXY4s0LoXVUKDnSwINCA19emFN62iNHFa/JLyR68k5VYvT1rN4PBqN FxRwFVFmQqZY43S9PHFc4bUJFgp1qLg/80sDmQ/etsamFoH9wSAX8F0JjSxFId69oCFVDpCl3j6i FSG2Zi28ZfBsS2Y9b+k+23Kue0sImjzA77MkM26InPuzqc706hVT49T5vzS3pdprFoVqEBoHqnta RrW2pu6CUqqdMxR8Q9soFk+f2SB4Geo4xryC3pqKkM+SIFxusMTFMP5kXamXJxQDtFKvoYFZcbVl TiqNmYLBUZv5d50SyVO8l5593210G/Gp0dGFppYdn3ZB+YLlWXqEmjq4HIbIvqfHdEEbVC21yktG M2g8LvrBwMw4qYdlhvGHK8dkDjFvXAPL0FIHK9KrY97R4gWE3tFOMTxcO8cVzoLP7OmZFQrM6mnp aU0ku5eGAmqoZx97nj3f01ENb5dSnERy/13e+KytMXBsBZ0K82BkRm+I3rGgV6N3LGps2IdPHIE7 6hr6GGUzW2bEuFjYzLqGUbboAuGqDxniFxNoDD/j2VNk4yhUil2kEXA7bnDzkdcgv4P+ntwq4yxH mUMV6irQLw/qRnWlI/iFRsbpjrkRCXM1PP9hiMdTDzr+20f6txT/PwQyfk8hiK+/f4zEhBuHBbeU 1JNGbKNYJk7WepzXr9IqViJYhU+lydJe+XWl13Cv6UrT16DCscYvAliawMcN2oP2MBJ8USLfBYTB 7zSJfEsC4iDnx8aRBaxF+iN+y7lYM+Xb8JneoRhUNUFL+snONANyza7sTFtMBFUICILwjP3hre6o erp5+PSQenqIVJRXlE8YT5tphNlLyyaVlcgK3kyV0mP3vV7beGDT9fkXh6I0OrLgAP2apn12dPjb I7Ge+599bsQ/Erhg/jbNMoaNUZnRpFLiMPIVmHYKFPkAfkdZnAbLGVBVVg/k6wGbTUdODFitOvKp ZjOZWL0tzZ/G0p5xjK6R30j/aZ3pIWIvzY/gLXEiJlDZ8CYajeZenH/DpgONtYdHFtDj9L0D++7v aXzj2+Gjn418PmLAKitpgrWz1eBnoebpYB0Cq6W1jNEQYVlSBwg8Ysfd7uhc9USz+iEpqh2aMJ50 0ub0icHMSjaWJvbsgVRwTyWiBbzOQVy0WSvamnWXl23M2uhlS7PavOxqS2saa7TUpbFJaVVpzOsx KCJR8+12Yh2bQXNIgu3WQsHcYLnf5C/PzQ2UB4M5ZHHONabFrvY8dXHATu3tocsbdeFw0XwxpJar Q+XqMKlAerq8YsgxpeiE3TWFiwsPaYbQJnKZTWcTSyOhXFnJnzSppFjMzJCVNKYIE0sy6V9ojnNC 3rOTH7uua4d7n+erV/9MSeOtDZOyWOIQXZnnaK+dOi36y6VTV+7c/qDz0NF/PN7y6Lq5P2hZNfLA oUPY8e3Jj0U/7vYqycb39YeoZLHlSROlakmq8Mf9zO/P9ZX4Zvg6/Nv98tT0cmd51qXOS7OaDc3W Bluzc3FWu2GVdYXtGuc1WYP+ty1HXUc976d/6vrU80H2cX/S7wlIRbaijPFShU2TLrXNl66UjmZ/ KZ5RLWpmmigz4vXJCjVl+tLM7rwjZqqaNXOLudss+jWuNmYL1yKzW8cTydMDFguKXM3MZpkjX0DN dOQ4mlI1WpHVCmwdtZdAlqAnIq/Ar0RhxgYp3U530Tg9RUU/rcDdGeqbHNG1Fsh3WnZaGqunFj4h VXlv6jCbeQ2fEBRfg1RHvtOcfGrq5vPSDD4F9eTMLuMq9sW57yzR5s615bXqMGpOqMNnq5s7YZVD FfizT7E7IG3STEFIOoMhe4kdAs5hmSoJ5eYLGS5nSfGklOzpuCcG1vYu3d2pjXz+3IGrWWn9j659 5pfrr31G2j/85bZ5217pGjk58tbD9P6D9XcdevXIy4eg9POTHwtD4nSSRRt7GXfbWmnaLTZqM1MN 31U6YC2iw2dW3D4R9+9MxcB3r+i7Vyx894rKd68U8ZUfevNlvuoh9cXmYg4Txnu12UYL9ftmps90 LUpf5GpJb3E9xB4SdlgfUx/LshisHlM7Wym0S+stHdZu6+OWPca9pj0Wi9Nyu+UDJqTlLrGtsd1i E2yw3ae068fj4jCftGBZ28kucpycwg/QNpsZJnl2jT4sPS/NwJmdluvF/vLMUT9+D6WUarqANF06 c3SZZOkyucSXmXdYoX6lQmFKGidSTJxIcXAiZYK39EVuj9gfpKLn0ea1o4cbPrTzU3ho7RfRobX6 3mGf9ilFavMJ/HGxwYN0xqhLlkO5cFoOiM7pUiLcUjMzuOSE8t7sk785OvLV2k/u/PU7/t2eWxrv eOqxze330Ntcvz1Ms6npGco27X7Ee/WqF/741vM/5D6oBhaZA5llwiIXaS4/8WWyeqFZajbWm9uE q6U1xjazITOR5J5VrrcD0RZyLNvH03zH29KZjNNZ4gTHVM8EX6WjNqvSt8DR5Fnoa3Wszmr1bZA3 ZJ5mp90qPrfZrC7XfGeLswM/PPts29VdKlNV0eszKWQ/zm/s/qxlDIKz4BoODXpfOrTFpVkTyXd0 3w7kM30pQP6hmyGQQc2YX1Aat1Jrlh+l/nCklOdaZU6odLyf+p0lap6i5RWUcsHMUwQloCsarAnq ho0gTQnLp4vJybemeHJKz7ev5mjt8Im5amc0ehoQjdZyqxpuhqnpjrS5fLiznMK+pnATo/CmoKGd a8+KSyUlxcSeoQSdXFI0iBMHchMW7y/8bN8nIydpxjt/whep7z429d22bOvwUbbAMvmyOzf+il7m +sUA9cNxWOiYkXdHvlEDu/evoPfdPnPF49DIO3Ckfw1/amatmleGKWHd8mVyo1GwWf+PdFoWjBZ+ RMrcd/HNms4ixrOIkEh+rKm8Y71wnYk55EB6sNQAp9fvyC8F1akB5A5JrwjqFdpm1MiiKIlymXG2 KIXlcaYG03XCetNR4QNZeVymITmihA1T5MnGCus8a0yMyQ1KzHiTeL30oPFl+Q3xLfmE/InylfyN IdNhMkmCIDJZVoxGAwpGgyGsyBmKIguiGJZMGZJkMhlRMFBGRElWDAazmZhE/CCoGSW4XLleykVY YtOCAd3q4EfBhKztUAZzmLAwfDChFfiWwAh8rzaBOx2CDfOUs4SYuC4QOF64bd1McScGO4jHYn0v OPtK/IY196yLbe6Eex1Sh6AGp6PNtUOwVAQ8OFYR9FSU4yjdIl0UFW9SX0TujqYBUVRDuaFc0NNe WfeJ1hoj9Rs3C8zottpLCTxBDAqDK4ZmMhZmTzEasrPLIbB3+7KnIHuzL6BnvcEpXOuisWbS2Uw7 8WVe/8IvJwf7glMgxME+J8/e7VM5Oc/0kkXPes2pztEYYhveUXP8TaSGDCdmy8go1xP0Ot3n5p0/ 7fWmyGlzTFdjKHJzZ7QEpwUtofh+rNjvGKBPfTLSTg++O/LILdL+7w7Q+Mi1w8uZ/4aRK3gUeSuS MuilQD7YK03iDIYGDfaXTS7V89KJqXz8hFSeG9ZzLZzpKrVJfnwsPSaJ85CckgS/1CF1S0kJvw0T ExPCFGLUR+K5llkysXQnoYNw34yQADkCTy6ihZ+ckGoieSZ1yI4ezilZZ+iyRlQLKfPzWBd3IpnU 3QlqvtNMXInIXHH2/FF3rfOen6/RaPlwOamo4DbOS/zhnLl1QNp/Zhbf+xbcTCLwqCH6+33ECsPj w8OiUghM6i9ardlaGhZPiCeM77n+HpD+JJ0OMJchEDK6vQGjIIRyfHKmD4tUqBzK8qimI2G6Pbwr zMIuV1ZaeDsiO5Fvz+7mAQt88qeamau1PYMrNMofay7OczvjG7XDBSCVeQCBtjP6LoF8rS8Mv9k3 axZ3eLuXevXhvOeG8+rDofyZZufDeUU+nFc/0FA7opn5zryImpCCa/rAXj4e/qeoJBSmRwhsbxdh fsLtT+C8HpXG+faHYAeScuoy4aOMiuULLYMPTFKiSEuZZF44QTf0B7lYvrdKfpgi7hk+cV4o1Azb PPc0D8+tbqv6EDFPRXl5eUVFyohhrtxfc3c983otzZKRHsmw2L3UYc30UoIrSnTTqBuHfDN5JOx0 8STTHrKXpk5dHYMblzPtWx4pfrz92gf8N7/y86f6Q03TO34y0LD80k1Txch9c5csbdi/e+9wPnt4 1ZKp9z02/ADr27Bh/o4fDb89qi/Ch9AXJ71JS5cEOZ09qSbUD4SP0k8Jp9NlEa5XK4fCXK/Sn6pH 3MfdSbcYMGSkZTgdPgka4rSarGmWtDw3Dk1W70Zogqh1DMfNGVwrELh+qtn1oFaPUM25OgUUEqQQ qDmDcxxU36QEajZxvqN8WtPdoVkrmVSaNFP8mee6udFllU4qjbtPuVmHe5c77h50i26BlWQ6dds8 PWC3pyzvexN06U43FR+nTFBXJd087bqUmW5wqdiZT+HAnKdgTOdMeq4Ld0z94E2JFVb4RbmKmgtq 0Ya7DewTUh6yT6GjwnXKdqPJYFJMgqxG7HKal9pMjlEhF0DKcKfNnbqUIV9+DTxPxFseXf+3lkfm q6aBgqvndD0hRh7YXd1RW3zTcBe7/ZrVlfe+NnyAx1FViKPyIUUr8dCr92biEiHXp8MSdSOzcZPs 4lUevcGhmDyW2fIcw2VyzHCVvNJgKFWnOqY6J7qr1RpHjbPa3SQ1GReqzY5m50L3amm1cbm62rHa udx9Hc00ypL1CqFOqjNdYVkltEltplUWk8snKna4jIw8r36X8epqoCBG0sBgxDf6rWY0wOanOpc8 mk/p69MRLgcd0Q9QLoT0vHDpeIUSRVUCCJomHIOP4PWX8LAKeFoesaRhcOLQj1M9hidYBGr0cIqk rFb3P8SpS1jDkNwdMDIhi4dXEOo5Mx1CcNV8uvn7Cn664goAV9uJU48fW8ZF0iLjUmmpUeRnE++Z rpbBKAnuqDwqTtfj4NQNpuqxO1/6K3Xe+N93HRsZ2te35fa+/tu29OEnmfx7rh15b/jQf/+Q5lDr a6++9l8vvfoKVK0Ct5deSHC84NJuFHMzcqcaf2Csyrssty13o/Ee4+a8x9OfLnxesBpdWW7X+JrC t1ySl9UzphZTk7vJ0GRsMjWZmyxN1nZDu7Hd1G5ut7RbByID+bb8SF5+3thJeY2mmHl5ZPmYdaF1 ed15Pzb9zHLvmAcK7xv/mOlXll/kP4b/Z30p4hxz9qTIPYuEziJ5ZxGdhvNTp+GITsMRnYYj2YgC NEfOlEZDfthiErMCkUzRfFF2Fr/85HoKuZT8ngrPPM8Sz27PYY9s8/g9azzHPKLfs83DPM9BiJlQ bD0u13BiMoTjGmUqfh1lhKqU4X462J/hLOW5pqbZSym9qCl7VTbL9mUq8FpfQMdYPZAPdZfOES2d K5nou8jsz6JZeR4t3V1azLsXcR316OcPtxDgUBekAe6aPAHey6MHdh49Nvck2BV9Sl4Buu7xTTlS QIF9iOOH1QP5WP8YpCOcD0D+sZebXkGWPlUQN4WW4sFiVlHcXcyK+R0jj+hz8qgQB04gxWVWryN8 ARzRPHwRgTybfke16cuzBfhSYdxnNCyRf23iE9r0MNyWe+xs2OmZMHqRaO6sHT2VhqC5KnzV2rm6 C+OK3Ikbxfdnln4DRG3FUCdugfoJx+/0POQ4gUMLfzi7+KcbHF1a/rickJRRGLGrDjVdFeRca8BL jGMUL5XGIcnJQDGYFvKS3JDVYhhr8tIx+UaTHBW9xK9mcz8Y5TFsKuERYrQgumnTptH//kCR3zzX djanl+mXl4n8exl+Vy6dVKafit9fQl3wnS58TtCNMVLRZ7vzxo0bJoZ//PKD8yonF/xo0U3PNdrj lq6VG9udziLv5oMPXLby5ZsOv00v9l29tq3q4pA7XHzJprmzrx/jj8658Sr3wqaFZSFfdropr6Ry Y1Pjzsuf4edlXvJzViA9iP/j+Ms+YoIOhiL8XoLbHpBuD+7nFquJCsSpGqM2k+z0CWabmktyqdUR ttCkYqg2VrcoHUq3sh0f1ODZdilxZVA5gu+U/G7JD04g/FuPjnw+wA8v1PB4aRThmoaaM7piAzml mXXvKXP5o5zy+sp+1k7cdFIv7hCpuz5nLZj5xQl8hxsuV098gZNqqAKoHWGIvaRE/QMPK6PRsAvO LBKZaA9NLLGXIfoI2TM465madWn50lWFmzf379mTHh2T88hOdXrbo2zZVqqsGrl76/CPawuz+Gmk P8l8/O/Av3rwkR3RGP+arOLLYzWZReaQuYjQ5uO/DhbiP/gv1zvhoys/gPHI+D8QMntGXfWcH0Qr 165sXVVb938Bu96cjAplbmRzdHJlYW0KZW5kb2JqCjMyNiAwIG9iago4Nzc1CmVuZG9iagozMjcg MCBvYmoKPDwgL1R5cGUgL0ZvbnREZXNjcmlwdG9yIC9Bc2NlbnQgOTA1IC9DYXBIZWlnaHQgNzE2 IC9EZXNjZW50IC0yMTIgL0ZsYWdzIDMyCi9Gb250QkJveCBbLTY2NSAtMzI1IDIwMDAgMTAwNl0g L0ZvbnROYW1lIC9HQlRFSEorQXJpYWxNVCAvSXRhbGljQW5nbGUgMCAvU3RlbVYKMCAvQXZnV2lk dGggNDQxIC9MZWFkaW5nIDMzIC9NYXhXaWR0aCAyMDAwIC9YSGVpZ2h0IDUxOSAvRm9udEZpbGUy IDMyNSAwIFIKPj4KZW5kb2JqCjMyOCAwIG9iagpbIDI3OCAwIDAgMCAwIDAgMCAwIDMzMyAzMzMg MCAwIDAgMzMzIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA1NTYKMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCA1NTYgNTAwCjAgNTU2IDAgMCAwIDAgMCA1MDAgMjIyIDgzMyA1NTYgNTU2IDAgMCAwIDUwMCAy NzggXQplbmRvYmoKMTY0IDAgb2JqCjw8IC9UeXBlIC9Gb250IC9TdWJ0eXBlIC9UcnVlVHlwZSAv QmFzZUZvbnQgL0dCVEVISitBcmlhbE1UIC9Gb250RGVzY3JpcHRvcgozMjcgMCBSIC9XaWR0aHMg MzI4IDAgUiAvRmlyc3RDaGFyIDMyIC9MYXN0Q2hhciAxMTYgL0VuY29kaW5nIC9NYWNSb21hbkVu Y29kaW5nCj4+CmVuZG9iagozMjkgMCBvYmoKPDwgL0xlbmd0aCAzMzAgMCBSIC9MZW5ndGgxIDQx MzYgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBzVd9UFTXFT/33vcFLLB8CJQ18tYX 0MiuCGjAj+ICuyuwSQuC464xcT9AIWIkaBjRxCHRJGbBzrbSzORTTGKCRsxbMQk6tmNMscykndSZ JJNUk7QzZGLTkJlMY+y0RXrue8iobfp339nf+917zrnn3nPvffvu2975UAtYoAcYuCJbQh1gXCl+ pDmRru2qWReOAYjLNnZs2mLWEy4DCBs2tXdvNOspewHI4taWULNZh38h39mKCrNOFiPf3rpl+w6z nlKDbG3fGpm2p3B94pbQjun+4RLW1QdCW1pM/1Qez9Gxddv26foIsrujs2Xan+B4WRNcrhl4Ih0I 95H4jZcEYoEi2A8pQMGKpaWo/lrYgDYumBbAyGi/ZUPqiiuKTeGt4PDQgWuc3/nLczGAa/WJn8vF WLUY/tyA7eTia/UASX0AU+8nfj5j4VZ+CS4LeL1YSE9TXDXqCL3zRE0J0h6DyDGTXjfpiEmDJr1m 0ssmHTLpoEm1JtWYtMqkKpNcJlWYtMKkpSZJJgkmMZOI66c4pkuIi4g/Ij5CvIt4C/Em4g3EEOIY YhDxGuIg4kXEC4g+xB5EBLEBMULeMEMPmXTUpFdNOmzSKya9aJLbpEqTfmxSuUmySaJJ1CRwubCn TxAfIsYQv0WcR4wi3kacRAwjjiMGEL9AdCOaa0oyEzITymIjpMtVK8cOybEDcmy/HNsqx9rl2EY5 1iLH1suxdXIsIMf88u3KXEVV5iizlVwlR8lSMpV0xaqkKBYlUVEUSREUqoACegbzUV9jFfHpZyPg C6v6943aCElsWKeLWhXR033ga6rK0csLdbpvhECTf4RMxQn52eM2Pb3afwoImXp8v22aAwHIKvzP K+cmla+++wzkkTKQ8V46LOf9Rka7rxG1MUMb49qYoc0hJ+qhxBfqDd4GNwW5tUJuVfxgnXjaeLr1 /rgCVYHq9SYP06REzCdosweqsqwdFUZyy+05u22nBSCDkFQY0C1alZ6M4Hk7K52V3CTgY4SmFFSn Tptydi+3206TwWmTFdVpOJXGk/X/dLvwg4MphmKIED99lK7D0nMQxvuziGbEM9AP/XQYS+gDpQgd S3XwpTgGJdBp6EvhYWQ3/B0n7glDswLCaA+j9yhyBdoiyARtEegnfQY/Ansx9rd0mJ6j5wzrSoxb xz1MocPiGOp5z3vgOHxGzmKEXXAArafgAm+FkfthCK6S+Si95AsyQetRSwD7xzib0bsfx/tr+AT+ RjJJBYmSM+iTTh81xmL21oM+oygXjCg80t2knWwlneQpjDlOGV2CUbfSfXSA6vQcCwgV4piULpXJ 7RiF4D81gzTMkEf7CTRiz2F4EK5H5ZFH4Q+EkgbSRFrJ02QAxzBKJlC+o066Emedyy9ZULAIl8XN 4ksoY9Ia+QVFwtgivhxyQYV8WIxZebCPBsysGe6HnYbswhwfhkfgMTgIA3AIjkAcTsM7vE+4CJ/B VZydVBSeVxlZStaiBFA6yW6yF+ej9wbZT54nw+Q0ju898iHNw6xNacfszVHuoc/Sk/Q9+jv6OR2n X9FvGbAEtoGF2TZ2mB1l77P3hRphQDgkXBIuiUTUjZlKlzKle6VelD45Qd4s75V/Lr8gv5W4ELIx LwfmVQdrMatuzORh2AdRY9XimMlJeBNlDL7ieaBMTWfCs1lK3MRL1qAEyDoSJFvINrJjJqNXyKtk kJzEXD5E+ZhcJH8mfyXfGHKVSjSLFs7kV08b6Vq6mT5Nn6HP09dxRw7TM/Rj+hnmOE6vYI5JLJ3N YnOYh3lRmtg9bAfbw4bYOXaRTeC6WYQfCxXCGuFezP28MC5cxpWkIhPzxSXiMpRW8QFxt9grvog7 ekKckCy4f7hkSMulJ6WD0rD0iTQpz5Kz5LkoC+ViuVFul7vko/K4/KVyLKEyoS2hM9EBR2ERvH3L c/wm7u536b1SEeSSi7gbHmSp6KXifI5Si9ye0EaH+ejkRjIfV+pTuMoSwCech7XsHmgXwyxJ/hoG yTbhUfI688IxOCx3kTMsyCbYYTFfWm7uD/osOyp3y0H5Sxzpd+yA2CovJJViLxmkK/GJ7iQN8D25 Avdhz9vpAjgPT8E+0oUvnH7lGEnGJ3iU5pFe8SV2QhhgHnE3uQNX0CaOscdhCczC08p8mIt7XYRM fsZxlZWXLS4tKV5UtNDpKFxwx/x5Bfm3a3Ptat6c22bbcn+Uk501KzMjPc2ampJsSUpMUGRJFBgl 4PBo3qCqFwR1oUCrqXHyuhZCRegGRVBXUeW92UdXebsQmm7ydKHnxls8Xaana8aTWNUVsMLpUD2a qv/ereHRYl2DH8v73VpA1SeM8t1GWSgwKslYsduxherJaXWrOgmqHt3b1Rr1BN1OB4knJVZr1S2J TgfEE5OwmIQl3at1xIm3ghgF6vUsi1NQkjFHvU5ze/RaDZtiGJbvCTXr9Q1+j9tmtwecDp1UR7Sw DvydVWi4QLXRjS5V67LRjdqmYzrQq8YdZ6N9I1YIBwstzVpzaL1fZyGM4dHTCvVVmltftXM8x+kY Ia82+fWEauOEcArqpnritT1ud4D3hq/LJw33bHTP3jluY1FPTpuqYzUafVLVBxr8PNh1q537BAIY 1OnwrfbbcdSap0/laaz2GxlgUJJThAPnOp6mmXCL5uGa4P2qnqBVaa3R+4O4WLlRHVZ320/k1rlO Tf0J6jxqtMmv2fWVNi0Qcs+OZ0J0dfdwrUutvdnidMStaeZMx1NSpwuW5BsLLbgKps0oGe68hKO+ PtWEj0ir1V24xyIqjsSv6TS/nN9ayiEaKccVwStAcEbbcP6CUesyzE4X862aGr0CuBG0ia9v1oSm NVK+9QpwI98uM1tOJ6HrZb2wUF+wgO8UuRqXFkdWYdSXOB1duk/rsKq6D6cM6v3YKLCsCKfcbuer 3DvigjBW9J4Gv1lXIWw7Aa4iPOrQILecvW6ZtYZbeq5bZpoHNdzOJ/F1CDBLVwpmfqnWrAxP6zKd ZP0Pc4tpx8fHo8YFMT9a7y8IRXttBcFoXwB3tRef6mjUq6neaDAaGpnqCWuqVYvGfb5ohwefRjOl kamzvTbd1RdoJTipeqk5G3pGtZ/ZKN+ZWKI2FnDyU1yPVAv97AgMceCgze8r/t0k4ZcXgB3f6hS1 DMv8KsC3+mN4KgLU9uD3Ww+eTBgeaTVXqvwBET4gL+N31BSIU+wU+QKg6NqEdQJWfoP34kWlafa0 fHuavYfBZA+FayCO/aO8RxjjvfbDP8UpScX/vfy3U4mQnJouwggNvyWDIKcL5BRthOSiieylwG9F xYtItgRMluSCefMKCubdWVqSnZ0O4iXto8nvonXr7cmO2Ss2udrX3X1f3hGaLqklhybD1z4tceUV ba7seyKr84KX3EZzsd8hcoZOChZIgsxfAaNlkAASieDAJ6BosnhRxmIMjX+ykja3YGho567jx3fu GqLjO48P7do1NHRDe8bbE2yPc3K9PaacgSkP0XrspH5S53NmXFPleHL5bxcuCJ6QGBGUSGtLZHO4 vVmOtHVG2lsWy9sefCjU2cI/ybHX6e9lXKMcgMpVdwXuuqtwbdsDm5oR25yrWzY91B7qBPg3glLX YwplbmRzdHJlYW0KZW5kb2JqCjMzMCAwIG9iagoyNzAzCmVuZG9iagozMzEgMCBvYmoKPDwgL1R5 cGUgL0ZvbnREZXNjcmlwdG9yIC9Bc2NlbnQgODk5IC9DYXBIZWlnaHQgNzk5IC9EZXNjZW50IC0y MTEgL0ZsYWdzIDQKL0ZvbnRCQm94IFswIC0yMTEgMTM1OSA4OTldIC9Gb250TmFtZSAvQUdMWUxM K1dpbmdkaW5ncy1SZWd1bGFyIC9JdGFsaWNBbmdsZQowIC9TdGVtViAwIC9BdmdXaWR0aCA4OTAg L01heFdpZHRoIDE0NDMgL1hIZWlnaHQgNTk5IC9Gb250RmlsZTIgMzI5IDAgUiA+PgplbmRvYmoK MzMyIDAgb2JqClsgNDU4IDc4NiA0NTggXQplbmRvYmoKMzMzIDAgb2JqCjw8IC9MZW5ndGggMzM0 IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAFdkMFqwzAMhu9+Ch27Q4mTHsbA GEZLIYd2Y9kewLHlYFhs4ziHvP1kt+tgh//wS/rELzXH/tR7l6F5T0EPmME6bxIuYU0aYcTJedZ2 YJzOd1drelaRNQQP25Jx7r0NIAQDaD4IWXLaYPdqwohPpfaWDCbnJ9h9HYdaGdYYv3FGn4EzKcGg pXUXFa9qRmgquu8N9V3e9kT9TXxuEYESEdHeIulgcIlKY1J+QiY4l+J8lgy9+dc63IDR3ie7Vooi y1+sZKLryJIst7rYA1mS5eq5bvvlyuLygEdgvaZEWeuX6hklnvP4eGQMscSp+gEgbneWCmVuZHN0 cmVhbQplbmRvYmoKMzM0IDAgb2JqCjI0MwplbmRvYmoKMzAgMCBvYmoKPDwgL1R5cGUgL0ZvbnQg L1N1YnR5cGUgL1RydWVUeXBlIC9CYXNlRm9udCAvQUdMWUxMK1dpbmdkaW5ncy1SZWd1bGFyIC9G b250RGVzY3JpcHRvcgozMzEgMCBSIC9XaWR0aHMgMzMyIDAgUiAvRmlyc3RDaGFyIDMzIC9MYXN0 Q2hhciAzNSAvVG9Vbmljb2RlIDMzMyAwIFIgPj4KZW5kb2JqCjMzNSAwIG9iago8PCAvTGVuZ3Ro IDMzNiAwIFIgL0xlbmd0aDEgMzY0MDAgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngB rLx5YBRF2j9eVX3MfWbuTObIJBOSCQSSQAhE0hwBkVsIJEgkyA0iRwAvlOABiCjorngL3qCyDEnA gOwLKqvrweKq64EX6+L5irKK6AKZ/D5VMwF19/e+7x/fTKr66erq7jqeu57qpUuWzSRm0kwkok1f MG0REX+BLYTQm6YvXxpJn1t8hKgTZi2avSB9nnU5Icq3sy+/elb6PPhnQhbdNGfmtBnpc3IWxz5z UJA+p+U45s1ZsPSq9Ll/Cp4/5PKF0zPXg3kof2zBtKsy7ycf4jxyxbQFM9P1b7fz80ULm5amz28b iePBRUtmZurTOkJM//XG95HC9PVMTnEcR74nVeRBoiOM2EkJmUiIPEfOIQrO+XWFbbjz+/Wnptqq ftRn68WNj/yjoIgDL8qLNp7e0THbTvRmnBpEfX4B9+kGpEaTwXZyesfpa9A4/qRf/o3bQyZI3Vrj vvAb+6RCchSJSYUtiZzwHqlAymnpH9bapVir011qG9hdiuD+EpFHkC9E2oG0H0kmU6UQrtqRr0Rq RtqBtB/pDSSVEOT8agRpIdJmpKNIqpQjBVsiYfvAAsmPe/3or03yku+QOpEkEkZegjQGaSrSBqTN SKqox0sWIq1E2o90AkklmuRtubMMbfe23CoOrfMuLxWn09KnUxrEaeuk+vRx1Lj0ccjwdLV+6Wq9 ytPFPQaljwXF6aMzv7QZD281WkoPDPRIHnTSg4YvQk7ZQWKjlITJFslNkkhMQlNFiSY5W/PipZv3 SzKhEpMomUHCnQck2mJxlA40sk72HXGSMPuWHU9fYcdbrY7SzQMvYp+SHUj7kST2KX5/Z38nK9lR PubIq5E2I+1HOoz0HZLKjuL3CX4fs4+JjX1ESpCqkaYibUbaj/Qdko59hNzOPuT4IXIOVyMx9iFy O/sA3foAuY0dAXSEHek8wN5qqags3SOAREkGCOdnAG92BnB6StvZmy3/KgRGxTHTwKjnpFwygJRJ uS35vcLtkq+lam64nf2jNZIIbxnYk71NkkgMLXkbb36bRJDGIjUiLUJSAb0D6B3SjLQRaQtSEglY htyOFGGvIr2O9A7piaQhjUXSszda8Jp2drglPig80MP+wl4mXoz4IfZncXydvSSOr7E/ieMrOIZw /VX2UksoTAaacJ3gHjuOdhxLcF1hz7fmOcOdAx1sP0YwjLwEqRppDNJUpA1IKtvPcltmhJ14yHPk VdBwmLWQr8TxCfKInmjzwlp8MBAwwrN4vwsAIdsc2RxnWnzTvTjlWfz2OwHxLH7TekA8i1+zChDP 4pcvB8Sz+Ix5gHgWnzwVEM/iYyYAQtbOHno2ryBcMWY+jQy0sSsxSldilK7EKF1JZHYl/5F/ybyN 97cUFWHE7tMShUXh5r20eR9tvpg2P0KbZ9Lm62nzKtpcRZsvpc0J2hykzSHarNHm52hfDEUz1dp+ dVqp+Wjzq7R5O21uos1x2pxPm/Noc4RWaO0s2jIcVIdDjTi0DuREx6KtFwwA97GxKEY0CpyPgifs R34YqVOcaagUyU1X9of4Mbe1qDp93qNf6cKBF7IXceOLmIYXySdIMiboRaDRi3jIi3icDXk10lSk A0jfIXUiqaidi35sELkNeQlSNdJUpJVI3yGpojnfoSmMLETOm7hDNKwEeTXSGH7GXsQvF78oi2o5 9qA9Yb9Q2hCkthAdE+oMsQri8YA3Ox16Rzu17P7J8vNPFmIYaGC3sw0kBxOxMXPc0PKvnHA7vacl /lx4oJveTUIysI5WkjjNx7EvaRLnvUlQz8vLSZA9jWNpS3AibrO1xIvDe6mV37U7/K/gsfBXwXYG 8Mvgc+F3I+0ybQn/DSVP7w6/Hbwl/EpJux4l++LtFIe9EVF1T7BvePurouoqXLivJXw9P+wOXxcc Fp4fFBdmpi9c2oQzzRa+OD45fCGeNyR4WVhrwjN3h6uDl4ar0rV683t2h3uiCYk0WITGFgbFS2Mh 8cDainY6RyvWbdLV6cbo+uhKdcW6qC6sy9Fl61x6p96ut+rNeqNer1f1sp7pid7V3nlUS3Cp51KF 8FOB0JTIAraDw1DOZpATRvWMXESSWdIINmL8IDoieWA6GXFZJHlqfKydGsdNTiqxQTTpHEFGTBiU 7JsY0a7rvDhZkRiR1I29pG4npbfXozTJ1rZTMqGunXbyopuzk87BdXsIpY6bb8vmx24331ZfT3ye 5dW+aucAR+XQIf8haxSFjUMS5/9858GEL5GT3DRifF3yqZz6ZCkHOnPqRyR/Nz4ypW4P/Z6eqBmy h/6TH+rr9kgD6Pc1F/NyacCQ+voR7XSiqEci9J+oB4zBAfX0EMy8HonoQ+l696Xr5eN+1MvjB9Qz GEi+qJdvMIh6MuX1djbl1QzZmYcMdbwR0iTqNHkjv6zzaj7q5CNDHU8zeVXUedXTzOskB4jHBIOo EkKGKjRAgqJKkAZEFdHynaJKSabKLeeq3CLeJKVbI+rwDI+xHO2qYzmKOr8YyP8ZnDkokaCt/eun T6mZGatpjNXMRGpM3rp8ji/ZfFkksnN6Pb8QSUrxxsumz+HHaTOT9bGZQ5LTY0MiO/uL+35zeQq/ 3D82ZCeZUjOhbucUbeaQlv5a/5rYtCH1rcPGllf86l23nHtX+dj/8K6x/GHl/F3DxH2/eVcFvzyM v6uCv6uCv2uYNky8iwgcH1u3U08G1Q/G/PFjKzMZga+N2dH6QR77ogECeftHfddn74W2spWYEvVJ c2xQ0oLE8br7wO4D+SXQFL9kRbEtc8l3ff9o9l66NXPJjmJHbBBJLF3WtIz4auYOSf834Q9FS5fx qUjnCV72H/9QpSapTRvCdesRyaLxI5LV4ybX7dTpUNo4pB5l/brKTKaa9s4D6cIeKOzHK0rSuYq8 rIqXGQyZiv+OC6JNKMbo7IGi8Vwr1UJ0KWmql5KhERMYWMGEyRiGKZPr9kKX4kKiqR4dbKIJ2tT1 NN4PAZN0CUG3m7rS0mUZKDMWSzNHUbUpQRJNXUPS9bgEHyyRibFamgBrU/YSP1JAeZL45TiB/dP5 BdKX/Jia2/klv86P7GswuvZMImQr2U7nku1kP3mBnsBdO8ge0ka4CjSEPEBWkN+TNRBrk1FyC7kY PwXlv6f+zjZYJg9DYD5MDqHuJHI92Us81Nf5FVlJbpbewl03EwvJJQPJWLKQ3EZHdi4jU8gn8o2k gowkV5BFtLmzrvP2zjs7HyOPkz3Snzs7iIkEyHT8DnV+q7zX+SHpjjvuIveST+idhl1Ew1uaUfNB soTcJzXItHN252m0IEquRBtkMoocogdYAk+fSb6gPrpCGoynPNqZ7DyIWkHSQOaQ+8he2psOY1Fl SueozkPEg3dchafeS1rIbvzayR/JEWpWTnQ+1nmC+EkxGY7+tJG/0ANSqmNVqhrjpmCUCkklriwk /0VeJm/QGH2eLVTMSqmiKdd0vk1cpBepRWufxJ2f05/Y9fitlF6Sh3YOIlaMyx18tMmfyN9pgJbQ MXQiK2QL2UPSEqLHG3vhN4PMxXjfg6d/DDTazczssPSo/LR8Rs1JHe20Ykbi5H7yIHmeWtDTCG2i N9B36D/YYDaV3c8+lX4vb5Pf1E1Dry8lC8ht5GnyE3XSvnQcvYTOoSvoGnoHvZceom/QL9lANoHN Z99Jc6TF0h/lQfiNl5vkG5XVyq3ql6m61MHUX1M/dZZ2roZluoKsQuvvIg+hZ3vIYfI+fp+QT6lC TdSKX4RGaS29Fr/r6W30EbqVbqNteMsb9FP6FUTSj/QMg6RlKsuG8sNVoBhbAg3z9+wBdhi/N9g3 7F+SV8qVElJvqUqqlxaiVWukjfjtkv4uB+TDcifGuVTZpGxWtipPKy8oJ1Sz7gbI+NfPPtpR1PFx iqTWpjalWlJtnX8nbswhpAdMsCq0fhp+8zDfm4BxO8hb1IyxC9AiOoCOxMhMpfPoYnoVRvImeh99 XLT9D3QfRuld+h3abGFB0eYerDcbxMbgdymbyRZDGbuTtbF32GlJJ5kkm+SWiqRhUoM0U1oqXS1t kpLS69JH0qfSKeksfp2yUQ7LuXJcTsjD5KnyMvkh+Qv5C2WK8prymWpUF6ir1Xb1n9BqBujG6sbp GnQbdLt1b+sbgZ0vkl3kWWDguT96VFol1Ui7yO2sTPbDhPkL8HkqmSGNYsBUtpWuZdfRNpanXKX2 Z/3paHJCjmOsX2Kb2SnWXxpFR9DxZB7rlX6g6pKfAlQlv0iOy/vQt7/gyVepZno9+041kxboSJXQ kf4k9ZQT0mvkiPQJ1ckPkw9kI/XS4+xJaSyw4I/yAKWORKUHyB+kxfQ6sovVEGI8o18PPB5NnwJf mEBL6c9SJ9Tg0cCiCukf5EYyn71HjoOO15K76Qx5NrmdlNEV5AvyBKiiULlCLVLd9BU2V17Hsmgb YfI29K6S5lFJcZGbaIN0n/ode58sI4dlI/lYegatP8z+II2STygX0zmggOvIarK4cxW5WqmT36Sz iUQnknz5KLjbCqlUjuK4ElxlCnjablD3XvCBgdIolPiAOSOBF7XgEPfhdw/4hAwMmgsanwQu9hfS pk5g7WS2YqXgOvDUvJa6mEzufILc2zmbXNF5J+kOfrCmcwWeuJV8RjaQrfTm1LVkEUzJ90HbI5Wh 7LAytLM7W8feZ+PZpl/PL0Y7n/rI1/j9ATMzQHmOrJPfJeNJdef6zr8Bu7uBw95LLoPCegy9/BZv uFA6QMpSo9nOzqHSIvT3EzKu88nOMDWSOZ2XkzFkH3lcp5BpugTmOEnfRH+vJTPZxZ1LpZmpuRiH DRgFDaO1DPznFm1w7YSBWvWAC6r696vsW9G7vKy0V8+SHt2LE0WF3Qri+Xmx3GgkHMoJZgf8Pq/H 7cpyOuw2q8VsMhr0OlWRJUZJcU1saGMkGW9MyvHYhRd25+exaSiY9ouCxmQERUN/XScZ4fdNw6Vf 1dRQc9Zvamrpmtq5mtQeqSJV3YsjNbFI8tCQWKSdTh5XB/i2IbH6SPK4gEcJeKOALYCjUdwQqfHN GRJJ0sZITXLo8jnrahqHdC+mO03GwbHBM43di8lOowmgCVDSG1u0k3oHUAEwb02/nYzoLehiMhAb UpP0x3ArHiPl10ybkRw7rq5mSHY0Wt+9OEkHT49dliRcU0qIKmSweE1SHZzUiddE5kLHSZJbIzuL D6xb324nlzUmzDNiM6ZNqUtK0/CMmqQjgfcOSXqvOeY7f4qHQydb88ur2dK6Gt/cCK+8bt2aSHLL uLpf3Jsd5U+or8czcC/LH9q4bihevR4zNYLr4kl2c31dkt6MV0KxzBe9SvcvrfXmN86LJA2xQbE5 6+Y1YmoC65Lk4qujLYGAtqfzKAnURNZNqItFk9XZsfppQ4I7XWTdxVe3+rWI/9dXuhfvtDvSA7vT assAZssvgZkY9PQ1AYnqHBpx8bmRpbyNseHQBJOR6RG0pC6GPvXl2cy+ZN30vpgA/NVT3JWcgRmZ mzQMblxn78fL0UWaVPLtsci6HwkwIHb8m1+XTMuUqPn2Hwm/yPHkHKol6bQuOJlIJIuKOIroBmNO 0cYB4rx39+Ll7SwWW2SH/cyNBjIWYzutvl8Jhj8a5RN8a7tGLsNJsnlcXfo8Qi7LbiFaCXRr1siv HOi64q7lV5q7rpy7vTEGTG7j9ixxJ/Xxc/82uyerZk6/JPX8D5dnpq+PGB8bAdU4UrOuMYO1Iyb8 6ix9nQ8oxg3XMlAya3CdlM1QxiGWLYmraQ25qwrU5TpzUs7HvyqQeka7Tg+sFCU0MjRpb7wwndcb o9EMzfxvN7V3nuB3icP52zLdSPZLZBqabnay/6/Of9U88zppxASwHAbNft0646+uAdXSrRyeOQDj YehHI4OTpBaUmY9/mBx9earPTmoYMlyZACoSxfXZmdNfVczO3FSPP46d3YuHgmeuWzc0Fhm6rnHd tPbO5stiEXts3R72Anth3aIacLs04rR37r01Ozl0fT1GbA7tB/JgZNDOGF07bqdG146fXLcHLo7I 2gl1LYyywY2D6vm0sMET6jLDIiaEoz7mECsmwBgu49m75FK5ibjpGjKZPUVWiFRJnsJxIK7v5XVw vRbpE6QqpIlIASReNgppGhL0SFKLunuQnpKfIYuQlohjE5msTOzsUCaSTcrLZBbSQ4Afkf9BtqqV ZAHOH8M9+2E1VuAZm9SnyD0oewDXpqPeQzjW4fxhwFNwT88MbNDdBhtoIlFxz0VIq3H/WByHIo3A 87JwHIS0hr5M1tKXOx/BdRzJjXj+Gl6ONCRzvBB9vRnXq3FfHspuBBzAe7jjyIYURerGDpEFclPn WdQdjzQMz8I6EwYxvbpiJipdjvMIpCwvYbBD0n8yrAj4qPGng85vIEbYPmbYS1Ziw5qPgzhJFjQM N+wTL3QQrsMSkg09Noe7oPG8KOR+jOShNB+WQAH0gEJSRBKwHrqTHtBieuJKRqsDlP4rJWWknPQm fWCB9YX90o/0h1Z8ARzw1ZD4A8kgMhi2XQ0ZSoaRC2HdXERGdN36//TIV8L+3/+NwiNHQ7/BjIuH uzF6c2k/2kAfpCdYMbT1Bexx6Ubpn4qq/KA+qmvWz9c/bzSZ8k3jTS2mH8wJ8xXmLyz7rGtt+bZX 4JBd7Rjt+KtzsPNZ51nXHe5ZHuK50XudrzWgD0wN/DP76eCrOQ+G1fCPkcPRbblrY6V5RXln85fH WcHogte7HSt8uWhrYl1xbfF7PZ4pGdDT0itYNq58eu8NfW7ss63PnyomV5zoOwieRjRUwQ9YoQNC OaKOfGTwSpKzEenAWU0hZ0hEPsDx5lKplV0JC14BnizbA5P+59bc/HKlvfNnLTdeWG5SjVDq4OtV FNX0rUGvlyRGdPoqo83QbGAG8CLNbbGVGz6mklzFqGZxlFO/efGTvsRo+8lE1aiOKntHoqGqo4pU V9nx66hCRh3OykqeevWkiUSW1LvMLZWJfGPpoe4f9TrUU2ql3hMnUl+lc95Od+cXcr3yFnA1THtp a7rl9M1hBtmQwybZns16Nvhy1svBn3NUytzEIEsuYlBUB4GmaCcGk86ebTTr7D6LTWf3Wp2qw2vN klxeq4e5vVY/c/ssAebONgYlV7YxR3L5LCHV4bOEVUe20ZidnU8MLix4Wny+fK/V5fVa3SzfJUnE rst3qO10t9bXarVYjEYDyfb5vF5idLtcDvsAq05VJTaA+H5v8f7ekm/VHJVjrJutzLosavx9tuH3 eC4Gb5ejMgICbmcPt0a2zfEl7KcaEseP2Y+dO57k42UXeWYE0+No78BQOipLkK9ReiSusx9c08PH D7bf/GGIGxoWe7Nivcuyor2jWWUST2XumBR1R6VYVlTKimZFZ0/a9vJFqe9oyaRNk2j/SXdP2v7a COpJvT5p08TUS5OW0X4jUn/y06fuovPvottT43m6K3XXXamJ9KnURFZN56MTkzFpBQKT4pqbKBJV vgVbWhWhGymj81SOE+jWcVJ9XMx/r57piV/bQ0y388cfU9/iKStS41gj5tlOLtCMBTYsPTp1eru9 nZa1ks1WPY6aQ7fZeimR7FJEkqRnHA+uFw/uOHXcfgpPr6qu4n2mceYor+hTUabq8HPbKf3krr+M mrxv1dUFF8QSNJEat4/+TK3fHuk480b9uk3P/TEVTvGpOP/+mZq5G+tmZwajnRKngbfAuFmiOLZh bfhSK7SBNrud1QL4uc1mE8CxNotFAN9oNqOR1dqsYUz5M85MG7mX7TftzIoRR3lBHL8yD+wcO+tY BZrIvaDgmlX7Jo86nBpHj9K/79uzad3kN890HPk29X1Kj1Y+lfqY3gjflJGM3mUEkT8NTByrxalU xRg10ipixMKvVEXUvrp+Y2C3L4QVugU0vsX08D0YrZMNJ4/ZjwOzMBkcv47bO8Sk9OpZBlp0qbqC Pn0qdh8aO6m0so906NDiW+Oj/NMuwXsH0nY2jy0AXynW/IvYIomNoqPwyhhhAWURKvjlRbdx2j/W YP+clIw63qsnWUwbsnpH3QNZIW3ftYvLsL3I1qD1EsnXfIw3tirdxB1E3oLrW2TRylMNAlvSjdp7 6NAhfi98jqwS+CGR8XuI1Plxi6uStXd+rEVclXdLlEmbpR1Y9F5OKIgWeId6RulLwr7EvG3Dy+XW a9B/UNRxexpXOPU0gG44ziQSblpG6baNqTq/8s1pPIGRWvAdh3IA+JhDa3cyruBoxkBIVlwhi8UL BvilmHsOaH4++QYHMXNsIB6zGbmZl5ESTPwhZIcw4NUYlOyd6r8/6SSepNbiSZ8DiwTwreY3mQA5 iJ2XELvZzHNedu6R55/Zpkb89iDQsoVFTP8FA8mD5ESyYYnqMlldw9aa1tpesSoGncnHarJGui/y D86ekDXFPcV/cfZ83XzT9KzL3fP9jdlXsyvV5aZrbGvUe3Sb7K/4jrB31HdMH9gC5zreZNCisfKe BkoMdsiBjWFHE+dnmhWlEQh9RjaGXr5VEGYCdNmwOMEJn3edNiyGw7Qv/6NI9fVZdmefslKPxwnk V2O5BfEsu6estI/DHo/l6tTa+W9tWd6ydNC8tx5+++o79mxbsWLbtutXXNTA3qIyveCZqa2pziOp VOrF7fc8Sx9M3f3dCXgh5307dzXHlU8wgWcwd0ayQ4tIXDbNl1eyDexevfyMTA1EVZhkUKiZ0VeN ovVG3idCI7gXy3qCugF8rTnEhAbFhILZY0IxypqfT1fXnIj5CZgVDdIQ0jM9Ej0VGoHnlil+015a RW8madJYnAAnzHjcMTJcSpLqam8ldXCJ2EAaEtGYQ1V1vUGFZexM28C3Jtz9aclS+doBK8J/GPbq VN63KuCyDn0L0ZczuGRw2C2+rCy11tLeebLN4RDAt5rBbgcUcikhjqJeXiEU4ldDQSuuhICgyNvZ c5qZGb1eRMk4GIuEIZ5L3j7E80Ok5DhvbDXPD8JNk50hA/5Cs9PJxAs1g80BKP2eo5rJmcVqQy5e xp/dgkdzUjGZWC2AbzQxiv/pbZxG+Pv428TLtD79lf7qc8p+9Tndy/pXgrrh5nrzBOt88wzrNc5r sm5x7nN+Fvgs+0TAvN/0bBbLxqJ3jj1kV/8LbnYdkF+PowGzFQgZ7XpVfTUYcAWDAX0wAG6hDwQl S8jezh5rHeOgWBL37eI9IGI4bJSZjU3etzDaHNfpc2wV9GM77auZHbuq4Q5fyFYyme1leVBJNuxM Izv4yqkEZy8QRB1V1cc7Go45nHxmka2x9khYwWq4+ANf7KKAvqSBNiypr893R+MVmPE+fXqXA/UF EwZdgB1DgKk6WXe2gnnzH73vu633XnvDA3RP1s9/fevUhU++8MiU0PbtA6umH7j+4Gez5v/ugXVZ h9//envdU/seWzutFzBlYufnsgeYkqD1mYkz+X0ax2JfkFCOqgkzTmhhzGixmW0ho7HQHQrKocKg UmiJWcw+P8RfBKyH1UZ0cT6LvHq8hDO0QyX8R5yV1dUQIseBLcdfsr/krLQfTJTyBGTRuikWj6XG stoi1zgmOZZnSxd7LrfPc83wLLNc7VptWee6Jftxi1GJSHwl3WQyW6yyjuK9EDWPtWrowHNwVBYS C+3dZja7Zd9e9hjxszlaAVqpoJkWZ9PUyMIIi/g4JkeadU1xwZvilMTtcYYWn3yWX4lv7O5rp31b /G/RvbQvBMkBzXSeWxW30zszc5g4LmaR86yTCSGCMI+YRnTOLuYzPZ0gVbAwUCtdXJ9V4eE8S0yc ruIc2DWHfBJ1HuQklhuf2Ba+a/7KHY9cVzbS5TQ1ta+eN3e9qy369R+uenX+rBk3bEx9+c7znfRG 371rkjeseNj1ELvquuk33HRTZNfLs1tmTH2gR+iPtx9I/fg5WCxsN9kOjcuIwYlrfZx15jnm+8zb zK+YlZHSSMvvZckJHCdmVdIpRpOkI2YQ+6uSDPVVliyEmS2yTnoOgUJ6mAxbNCORZVQhrxrldjbr WUUxajnhcmMXJwTABROrBfCtkFDGdlqhWXRabqxc1xztrdtogyjGqFpc5YTZWYRJOD8q7gFwbDef BbbL2k7Xi5H+JpFoEIzwJGcvVfbPodSCD0LbPQXVlg9yZeWaHgk5rdViuMU6qQUy31kJHve2Ziqr lHK7V0pyTk4Vf0Q9JgN1NJdZM1Wam8dWmrV4pTk3iGP3Sl4hUQ8zqDctc0D/dUgOyjZ13MQe/N1L L7WletOpj0u7z170eOphEPVdHVyj5bI/qjwBHjsxTTmIr0D/LHwQaNBqDLndQSfnnCabLIeCFisl Oh/khdAIBCCojMt9TiVc/gGJOg6CMjhhFDoF77WJfETg6px1OZuynsx60fyO+YNsvSHLZy0KSIae Sk/TXvAxCdRhzzK6nVlZr1ptLmuWy2qzgES0LN4QzboFiqbVprlpplHP2mT6FicfcDUtwpvnmGpf aF9p32CX7SASnyASHyU+u4+hsWki8W2MOPfR3oglvAtI1bfFuus/EQtCfH5JLOfJpYFrlKAR0dEG 2CcNYAvH1uh7JBTMIhGMj0v9vnQxtK1fkQ1oJYubJNAFiNulgyYQr/2j+97Lb2jbvn7S+m7bbmfv dzw75qY7DlD90ttO/rmDNtvX3XrwkftaxlR72D+fSS2fkjr115fvaDnKtbZRmDk3eF4OKaJjMlwv bKNhLMVJNLtbSLNQiwUiMVvJDbksxhAl+XYMQVqDs4e8di7wvYLneTE9gDMa3KG3D9n/1DWTDcft Bxv4THaf76dDdJp7iH9IZLJzQmS+NEM3Qz/POSOyVL8seLN+dfAd/dsehy7CKaAgTRNqbUwwPF4U FRd0/EJBJBaJ8gsO3sqxFoZ2ZtO3pvKJBNMzdLUZ+mxfzUl25TfZxUTCRrHDGkEvTjzLtUT7xmIj Z3MhWql5qr1TvQu9K72yF0qpWuv18Jd621leayKtpIESj3PJJXheWlNLc7qSBq6y8Rnj5MO5XT3V wVrhqpmq64PJcnIBFcslDnsFzjzUdZ4TqtKZVl/x8PkTB9Zexgbum93WceUbN/09dezBW77c/lFH xZjbRy957JFrr3lKHm+d13NUzwHffji9MfXTm+uOX4/lwxV02/NbXzj7UcNT9e0P3bNjBwZgGvid B1EIFrJIsx60UBn/TC8bwMs4FfZkVDaYLU1wUfAhGSNEtMQCNn2T4b/JGMz9VCZV47CQroTy6Acj ElgMT0XD4qpRJ4+Ptp/i2hi3DLj0rnQIHoT+LxYWjEokVRfr43RWTJN2rU8dH9HHtke64Ydb5NPb 19+VcqbOtH+wnX5NX36A+13GAwP9wEAvvGk9GUnjYJuZZId6cB4JPYzV9ujhjIZUpVvIaQkZzFzA Qvk/CTYJIGHj9iVHQwBpxYkD4qLNB1mZNj4FwGsByKCvlOc2cz3LLZ7oFujrzqBv2gr5hSkCfpQ4 zh0xGYvkWdEQYXzwhgDgDTkmLBMOiLLM+7n6i9ee1XJ5Rf5ajlz8hTznPT3fvy6Swbuo4Ifplgib iFNQRW8PLfQM9wyPf27+qqdi6IkF3uvoCnmpfrFpiXmZ5RrvrWQdXS+v1q8y3WRebbnN+7rjpSxn LiilJRgJ8EMkUsIP3SOQ+Ee1UGHETEI+YkYztvSg51sSatpvoIZ2NluzJ5psWgQaP7wMNruN2drp HbtLfU1JmM643pLX5O5S5CNuzc3cG3udM2lOgvaBNdAQMgqCs7KhhHeOC60MxQg+17BkMVlcX0/j 8d7lnD5+oQkQlGS5PF16gyr9knTovEWXf77/wNfzF6y5LXXq/fdTp+64bPX8OTffMmv22n7DN45f tXX7DSuflLIL75m35cgnW2bdXVh8cO2+TkLpgQ3P0wlzbrpx6vQ1N53tHLVxzBPNNzy1tcuW5TgZ Alf8Q9pqeNYUhgjId0AAnBKTzCWBEO4ATmjd+Iz6HGJKHcL6dPgcxQlTtxD3bIyxSlari4ylVKiR FjusCsolDZiqImb8YKKhFCjWcLxUDAxmniOinXPRj/7EkU4Y1L9oxHnZqRUJ4ekQWPz/89Zfv+s3 r8Kbzr9IK+8XGOnRYpd4JsVmSZd7FgRmx64JXBdaH7g1dJ9nW2Bf4GvP55FTkawLPA95tnukfoUz VFbA5W4MyOSLRtRIt9AY61QuZIO8e/StsWmW3MYbgWDXSmICR3b8WqxuLOZ8uo2zacc5XHJoDubY mOG88Pdx8clRifPdc7Kzi+2SBvhPYCQLBXMA611ewLktjgTIhDVxbjLHqTAY3AKXFm33rJg2/rqx fWif5xbsPkt1L204fu01/3zkmSPstceXXtWybcV1D9Px9muuGLnyvUVm38T5VP/eJ9R+X+of8C19 kWr9w36p/P7dBx9YD5YLSQqXMF2NqC/uSe4LPQKrCzoDU6tkqYqqMjw30GsIi2AsHtZnfEuLOf+E NSCmXJBDFvfwIu2BE0eqP3To7JNw5rC0F0s8G7FLWkmT6UbT70yPmk6Y4IymcWOFcahxonGmcZfx U6POZLTq+Dt1VaqqWGXT01A+x2oxpUoWzVgFh7eqq5KNfU39lBK5WmYRmcoP27qaVAWHF3zRcHVx DbOj4zhA7vcSjST2VziTJ0sWdzX0nAvsUMYJ1tXqLlcY+ruIfCr3R0QLYtg08wapGc4ERZX0THmO TUahxCa3ME3dS8dCuR6rucnT9OmIzAJ6uUo4GJbpJk0W/pEqLneIvyQw6jj+fIFMq7zcRoTcoW5K 3Yuk186mJMZWbaX3tSJu6vlWPjdL6MNyPxmvwtwM0woUlco6BM9KNF9iunxZVvMhEjcjYIWx/QoJ GKhfz98J71zaOdewGN4/jIQYBnjkBeeCkxg6clTud7av9GeepEu3dtwP/vGbHjezDTI0ZQrbgvEe Y3UBPVY06ItjiZLusfo0XLRVKgnoIwpVMj3+vAH9rRp1nHf5P/SY0t78X+5/trdEz3ZKr7FVqWmt tJpWtaZm8V5PhhZghgcwhJWqm7QSUHA2WxFYkc0uC8zMZvPN06xsMhwErI91iJVl+/U6mdgLHA5i KXTREBSFHVosmhutChvDVbm5kapoNEQuDV1hvNQ7L89+aQRugHmxzMyALjlxYoywigHirEK7hWZ7 zMFnB471BihEcDX35p5mTpzQizI2n8wZvZXpONrT92jI0yvvub6PXdl0n2+P/6fX3oW7/Ma6PgHW fojOzXPOG9Wvf+Lxy/rN3bzxXs+hI18/0fjI0tEXNV6eupvTCeIXiVKv7MUsW+ns3dRqg9cZBtX3 bRngZ8GwUXJSq+cMm+sSaq0i8hJ7T/ts/RxDo32ttNH+ivKSesB+wm7SK/UIDhxrn2NK2n8w/2D5 wWqQzbJFtkoIsFFkGVa4XtXpzID1iIKD35WvCNmEByyiM7twiUkQ/j9rkPrQPiKy2YW7DCFF0YdU SW1nizQD9op9pWF1mO2lJggmk+Y0R8hMnXTxWATbfSJLG0GiiL7XTGPNB3SfmKWNZmrm53ab7rCO rdQ165jud7Z33hUe68V+yFv8+4CtAb8d3NJXXRU4Xn1MTM9x7sftWgbhR8F8gNFr7AcPWg8eXKOk j5i1EUkTYnNDCEBok22SXrcXDiIse3FpXU+XcLuE/8XgCcYaCVZHpHiBqpNY2V9Z3UdPd9z/8Pv0 n/cOzQ2WKXtPD6X7UkPYZLppz5W33cq1vk3Aza8wUw5heWTtITLmZBj318ry0NjE2KxYk+Emgzo3 sExZZAC/U240qQUeg+QrKAp5cgyGLGeoqKiwkARzQhi3MBx1RO+Lq2a+zqDC/tbKuK6nOrloVFU+ 8qqePx0gZlx1cdVLnZAfNwf5HWYjr2fmeOHmtcyB4pxQRHCfCL+OOeVCPwPwuig5DS/LOQD+Ta4G 4DmAGhL9p3COlR4gvqgHQsbJKLhJ0n9grtzrhQShD5qpqixx8IU+Cu8Xpxc8oswRha+3SwuyshiN lqZdXvEYGE9pmowAb2Lxra81zZp984ZJzc+vT/2OXrCq70Ujht7wUOoDuuDS+ODJ/SbctT61Xdlb v2fmpU+UFexrnr2zsZd0scMza9TwhYVntujMfecPvfhqLFZTMqvzC2U5eEYOeWvXdDYvh0Fh4Uq1 6N+X2lQORUipZTq4+tKcZnJTzkZyn/K09Lhlj9RmednyBjmW80OOw+rMceTkSEVqN0dRMBIeZpno muSe6J+jzM+51nmr8z7pXut9wa30MbbV8TcrX2cP2F32gAzK/LilW6VQkrp3q7TbCJWzs0JmKTsk G+xx20UkHoEOFQh74xE91UN7V2v1/tB0jDZfRW0YxSUEcu5VhA8hzXxgsnFPOoyyJdSryrHcPPAf Z15ZqezVxTkfYm6XkyuXctsLF6Re/Ox46t37d9DBL3xIi/vvL3vhd9v+MWXB56sf/ZSxXt+deZ5e 8eZnWN84+lr3LXc+kvrujudSX63bx7ntQ+A9k4HRNozdZ1pJJEwH69PY6bCHbESPJhtoWLgTDQKp DEaOUQY449LmDGcQYEmBcI79/4x6PwEHxdT83IV6od+iXgYNufadQblePQdfrfWRsnXYm6Ngd46s +n0BH1NNRtCBUVLdHpcnyyOp2ZI3Sp1WZD59MEo9RkcUsfNYdCvC3yrawDHUi7U4GLYM+JkfLc34 ZAuAlQ/Rfz09+fr6pU2jr7nj0M2pnbTyjsd71Yy6+/LR21OvK3vdOSMvSx0++GQqtW1a6fY+vWq+ euLzn4r4rtVHwBl4pLyJ3KW5VSWk1+t0RJI5mRsNIRPRw/o/gC1bznLdBOmiiDFiYcaARTb8n8eM 0+2vydXc/5I0AgnibODLDAKPTh5LnBu0DJ1ijc0B50smPSLnnX1ISpz9m3STsnd7qvqZlGU7pyIo AfLN6IOB3KYlRB826Oi5bqALD0Sw8sRYwPR/aLdmEnxGIDuYTOrfmm/kU87xP/13vv3H0uY5tys4 j/ll27dKH539jCU7xvJ299veMQutXgDa3wPaz6dZWiDble1mjQX0Un0WdUp5eSTq9LJ8gmngwx/h Q0ip6g1ZJVjmBkrjBfl50GHQr4JG4c7kpnBG+nIMB2kfEQxTSN9sfj9b0lxAC3LiESM1CpPJ6I9P z8wEiHiUvUFwUPQHjQdzPOcYTACRcc75JRJfIwBCD5Fj2cFA0B+UVHPcnu+Oh+P6fIS75vssOVHi sWVFUdmVFdHhLFfJj9KgCZjtciALGaJRkichE3tDgOFc6c0MJ9AduA7ndW+EMfySe3i8uh4M7IOv mrucMhhIhUMayRZsSL2x5b3U5rZWOvaDzZTeGd8RvWz3wptfuDLadw1ld1x/YgCrfoZ2HF3StIde +t47tKltdvvvey5qHjXupjFrNx9M/dw8rYI6MB+PgaPkCkp4bw+xYNQDWe5yWQoZjFuMbxiZUWHM pAcFR3Q6iLxvxXgD+B5+ZQy4KpxyOIdVxvmkSvmYqw3N8OgxU5pa+FQa8VDyP0i5DPoJ6Qn0+wXH 8aSFnTlioRE44Botiyxy/3offGNdog+sF1OVmUc4rkV0S3UVPAAohpyDkAM5IcWQP/YCO/3CCx2q srfjCTb59FDW2jEKo7AfBLUKoyCR13dRhPYyvmjY2vcCsXjYWlaePnbvmT52K0wfYyI050BrTih9 7guII2xle3lE2ajsUICrUNY2YLU/SeQSrMSOxTLoCaI4IyjcSCSxNilGEo7ftA7wTZcOwL36aWVA E6NMIkJCPiK/g+53dZ572Fuaoc411C9eUtWRUZfgvwdVclIsc+x/gatG6GNF5xfSNPTRQbZp9pls trqULVPXWtY6VIOgtzYTJ7d2GtBMcshmMMSNRn3cxB3ovGUC4A0CwLmDANJCm5dowpVpaohk0UiW ljU2qzFLzqJxzCUWqNIazNddPOXDjBgZ4dzd1ZPj9obFaU2G20CQq8cTaD4MrvRKTp/e6IhwbMb7 79Atmj58XrcX6p+/4flDdItv64rBTddL35/1t78672POF7nWV4R+KmSBZqYMuKwQPbc/29mTmk3H MCURVPsfsLGrxae6WnxO8Kn/Jvg+b0hz7/RgR92bXmBvYsB/2I5X3INISxtaYmfHulYs9J2n0riu t1qwGgs+hWkGAET4VuvGIbOTj5diM0v4rAPTG0xWojcwo0kVs4DIAzHyp3eLKbBjgD/vWhlPx72g 5Gwac7hzh7v0eExC9YED9jfeOMAXPhNY7gD3SZCusIewTmCWKnJJ5LLIFZHrObXHOO4xIR7A+jhf tfI8bdsYhb4LkZk2fXDDz1qY020cy/kRo7PcJjLFLBFqhXDVQ8ryjvNnCoA/yvgcm4h4SDubqFlI Wg6JF6E/6ccS7qpMnCyBCMKQV1eBO/POwOXPeyP+0rvusrWVhNn0Lpatl5ebV5v/jKE0DzcPt0mF cr6l2FonXSIvt1xlXWPRm5iir7T0sY5hIyQsGehHWQZZjfewe6VNuk36rdKTOtXJbFZrT4W5FIXp 4XnrqegB6s0X2y6mGowpvd6A6EKLxWrFxzgMrNHZ7GTOvWwr1mt6tSgRhEj10oxmgzGimVeaqGkv OmmlJlxh7TDBDHB2RmyL7BSr3hOfjSiNSrMCpsC2tjo4k/Pz2KCGKh/Ym7CyAAfOnRxrgM2FYRC+ k0wOd4WwvdZcJyLQcAAVnTex/kjMnWewBv8OzNh3hIU1ImmG+dUN5hfn/j/vtBq53ZVZ2nt7d7TS WhwVy3u7KyqtpRUC3NUdpZklvEQ9bDSyGGvm9fXgstTj7VNBo2C12CznuAc7dy7p6fFjNY8qz6Um 7kjVKXvPfH/HhWPvl86eHiq/dqa3fPQMJ0Y46ZUwKMVAr9vpBD9JSwy9z+wRvvQvtSiH9DByIzo9 zF09THlJb5AZM+j0shSBFwpxDIJzAsgIJyVNSRAnWoCjmtIQMdGIaayp0bTI1GxSTHroc0AvrCFC PP0vPCEjoWTBg38loTLmmJFPWBdbxlKqkEmLM4upGZkE9xuiSirXyD0SmJq0z5fHTR191uwo10eQ AYPre/XkCjDmoE2vDa2EWX9g99BKvVaaBksrdbl+EWW12w+wNA3y0lg69soUq9RZXUhZ/Pzk7iyA OWkwB6Cbgz/vdKeXYIWqzWlHkA6msIxySUkdD7wssb0vn01hwlbJKzFZzWeauQUyHfrbR8rbiGDO Jq9qYwM26rK7XNne7GxZtssuk9eULW/z7ra+ZJW8Xl82i+RojjFZY7xaoE6pM0yy1zqmZk32TvVN DEzKvtV7L7P7Q5LkDJkM7ngE6iuXF5zRAUjLPwAnBD8G8LXgGADSPnEAp4EY4B26QHMOzbHF+Ryq YobSrMMf7LLa0mZbWtcDz4C/6xfxTzDdsuwkWipzI0NoXxV2OHQRCshgupHpdC3t8xod+nRbavf+ w6m9W/9Mc979gGZf/dUdf0m9y16lC+iDL6Qe//CT1JZdf6aT/yv1U+owLafZrdT0u9RnaatN7gB2 WxDj3aIVz3TMd7ER9hGuS+yXuGSTGd57K/H6uPFB9M64HggFXBdxZWClJzWhx+oDkQDFf8Bn+V/l 12+U+X+3Rfy/FGNCfRptXywGhw9Ml8dAaE9QSoUJFoIBy6JRB8wxHlghrC9WeOeoy++s/zb1Smot vXbfQw0je92UukXZa3XO3L3guVRHxzMSXb9yyo1uC8cc7AJWvgXmYDcbnaPdNTWOj5z4fRVuZgpi pyT0alfYFVOLlO7eRLy/UuXtFx+pjPQOjzcotbG6+ELlWukaZb20XrkLu4IfI09LfyN/83xGPvN+ 5gsElQQpUvorcoNyp29T/G9xOd9TFC/3VMaH+4YHa8I1sRHxifo6R617cnByzsTwpMik3LnKLPf8 +LXx24O3xz/wfRj3m3wUK0xvt2RXgie8rfXNrpR9Ll+R0k+RmeTpJum6xX0eONzhhQoojJ8QJS8U sklMnxfSGQLxLB83RrK6MBdAWvcBcEJgLoA05nJAy+eYm3URC0SKmotYUTQO7mQSWrRJYK/JX/hb 7B2VMb8E9grXQ8Y68VYSR5n9FfsraWkIRyjYMmL7luTDgIDH7Bf+CI7jKO2TQW4Hx/SKeIH845ol lQ89+OifXk7t25GkNa9whL+i4/OtC54Gnr+f+pRmfzhnyiUzH2xIrKm89pIDdMqR9+mMvc+nHj+y K/XJbSUND9DKFmr8XerdFCqn/lLQn3/X6WHwdTiFgPe59KwWdZqs1NknODk8S78gDGcL1xH0IteJ PA+8ThC7CJrjGg53l4kSCIU04Gzv/LTVGSjH8URrbkE5VnI+bc0pKMdauzhiXVQccf291px4+jrq i+s48uvacAD51ouCF0XGm6YEFwSXGK6yXm272bjWdrdlm63d9qX1C5sdGk7EYXM5HDaHzWxwYidz wGNUscpjMSs+g8HjDfhDCJ87kA4LRbB5NFfQsA94YNWH4tYHYBilA1IBnBJKmTCVcnnPVJX3Xm2I 5C3Ka86T8nJ9/1e6TnO4/ySDYv23/puRnjGM/Md8wBqhJmToO8FXYCpLoERR+LB4OByPCoE2dc6I OKdTiTgeo16zVdrs/RzOfrhQTxcLLcGKaN+Av9IBmeREsmrBSnuuCymMdE7IcN2gy9EIb05WTOrB wEJigp2IQK3ow2zdwdevefWtUd1qR3aefKH2ikndoyP+Th++edPoux9N9VT2jvnz1Q+8k5OfN3pZ ajHtddP6viZdxzKprOLqYXNEfOkUrPH/NzwLPZlbK5guTZebpKWynF/QW6oMDpaG60bm1ISH5A0t GC/V66bkTOp2S5Y1xt32XNwA8dJAfhcQ7wIKugBUxhymK6cBVE4DqJwGUPmUNpRX6maJ57E8qSC/ jw1f7MivKZkcmRirzb/cNM8y3zrLNdN3tekayzW26+zL8pryV0vrTLdY1tlus9+cd2P+nZZNtk3u UCaQtHs07syOBwzxQphTpDDglEt7xfHpA0Ys3a/OviWbZed7LN1DBfk0X/FA+TmppdcbQt0NoZBH EnIuAQ9GQ9qZwQ8NcFJ4ET+X/iFgJj/PajEpUXgSs7GdF7t5VZqfl4syuJWyuwfwRFa7AbLnOL6j IFwzQrOy0wgdSxvpIuwpUGE4JrWs7vyVCl6NFl9kiJNCWsjFttXKagGc1Cz8SYWBUvSJxkGh34hL ADB8EHoAMssaCNuBLPf3yrhqGkYdA85hrUH4uM87XxEBmMBSYkPiJO8R0Bi9E/5tKFFYqxUILDLw wqyKEIP/JC298gpECACPAeAcknto3S6vByE53BvO+WV8yrOWqX++buFT48dO6Z+6fNzc2dd///tH /7Va2Wvbvi35cGVf+n5d8zWrzzz4cuqHe+m79itumzSoaUjN7Jh3WqLi0ZkLn58x9/VV1ltvX3XJ mLKy+d3671q+7HDT0q8IuoVdW/JecEUddl5bFBbCgMNdh23UCIRoahWmKqXPqhHKSnjwA6W7qDBZ wU00E0dXos+sE3wveCPk1addzoKzKBGOxxRKOIAn6nffe141hZcOZoS941jD59xySIv7Xj3FMiN8 jiwrlSOvS2Urlu3bT//AW/swND7uIXKR9zVj3FYn1+lf0csezvg80JvL5f76ofJF+uW2J5QvbToz YQ6E/7SpBlccimZaJweQ0cmZcGXg/KgW5Ioaa4h4aMQz1sMaPYs8zfiwnkW46vjTudPIKMx0GInp pREBcEwBcDqt5hiFSo7ztNMIQMZaNza4uUp+3meJqCq4+zKOhrQGKDanJOB3g3shrfkJT4MImnLI jS/MSJ15+y+p04teGLb9und2K3vP7vwodfbR26nlK2nM2Zb9uy57QexsgA+WKEMxRkY6IBPf5lQo 3EhcozMSxaBXKFNKPkKcxSFHWRnGvBqIyiNt8koUWkS6SfnGEnNPc6P5Fv0tho3mA+YTZlPEPNaM JV2TnmWCQwzUDOMZj6yuFutpuNtoMET0igsOOriAIkxxMaYY8KqvIkZYozP1dCaDCokg0G6VY/W0 Wb8RX8nia3oWpnWrnMroBnwhgsESpZojooxVWE9YoBuVA8oJRYEVurbV1AiBwq3QxcdATTz5+II4 BEnAfxwrfr/e7ZRZzHPBmmwhNszEP1sMTvCLf7bAGIdaBIsTf/Wo1g1GZx9hdCLwF7sOuNSBHdlQ H8VCn7Ahyygb2PHnN+l1PcK53en6lzrgxjrzbvOiq66SC+HO4swBmyqXc92CfqDFC0ncUeiM+ypJ H0els49vOBnmGO4c5qsjkxx1zkk++z36e2yZgdTK7DTgT7jLlXLzEGWIeYR7gjLBfIl7hjLDPN+9 VFlqvtZtU9zcW+HE90ZsTMwj5ozPmldwz8rKbC0kyfAJqDoMvhHec4PFarOZ8WUEp9vj9fmgSla1 4hMyEX40Ox38qE12w+TE1wNZBB8oowj2VPT6kNvncrt9TrPBEHI7ATod2LESsTtcdrvDaTDrfW7F hmgfwtAkRfIhGNKAnX/Y5sN8TidW0vUBrzdgH2ig40iEmJG7kTQs+o/bHeELWX5/O711Z1oxaAj4 R3XAhdAR8Hf4RtfMHPL5OZ2gy43A9QEwUc5IRYK5OkqYq3xL23m/QuYMzHWNFYu5yKp4JqBfZphs GybbwXHCaeSBTWkMyEdh0XkMyDgprChpNWuKhkocKZY0ACGy0giR5YRvIQvrwFgGUHWUPpS69uVP 8gJ98VWSr98cEwt2//zF1BXPpV4r0HldqVdAq9V33/XfedLHHYHUNz/c2ib9AUZsw/rIzGFnHgX2 qBmKNdN5u/WGfpLcH9F+X7Q6veUgmC80KwDZj0ziGS691+qL8kvvaf0ByN2QOeNyob7IWGKV59A5 6hzTx6qML2FIql5nUFWDKhmMZvBqQ8Rochnhv5NUA2z5U/CUohRrGBTESlWzScV3QQk1tTO/ZsDG RcSVEL21nfk0g9lwsWZshhO+ne7SLAjGjxDp4jHYMsNJdpeGBRECJMn4iE1CJIj4QiEPuKQF9/ft tlhfiHIyTggHK+f+CJxPHzD7cCABFr40TDsCvBN6aIEKn14BreHL9XZkI5JeTFkQE9SmNxvM8t7O k/BcnBTRqELaUqElGgzQAvVIMpZZd/q5l6FeSGCeRR3nydvB+ne89g2Njq0ZdCkNftrxLFsgjUoN XbGiaSPdcba143fcZryo80s5KA/AvucK1l0rNlgMRX5LoKjQUlQEt527Irtf0fCiBktD0TzL3KLG nussqwvv89wf2GZxd+OqN5cwUMmwF4xDT/if6rbb/1y3g/7D3d50f9RNP8RDsQ3npIaoNrXWCZ2m K0yjN5dPtfw87A37EsVF5ZVyZfFw+cLiifr6xCz93MRy8xoE9v/L8q+Eo6LcSmV7SV65tzTq8k0t XFjICoMl1mrrBuww7bQqm607rN8hNk/sQ8P2xLQ/HQDiAPhuIKuI57OqPIAT4WwSIoGf2u27C/ti dJjIk1pACPSaAmNpUDIVTrNPI7AcMLf5UWit33Spr9+kF2TyZD7vuHAMnRfASTEKKPmQ6w5qbZ54 Ec7TmkJeO7tEsxZofHdGJN4zviOuVEJiCL0Mau07u7nuFu/FyzRLCOGZlQcq2ZZKWgnL56Q2kD/R m+/LLcnbrx5WWVitVpkKRgj7RqCi6uPtAZajMTyHxYPNRsjFWpzaq+95j9lirKgnsA7A8bThXBAD /GiJzz7jWuwx7EJKb/wQ+IRwqcVgUJxHCXWWK3z8gohlJ4vzuRLHozyxXMx/CNXjSp6uYACUQOh8 HjcC9LyxOIKIrXBt8KV5VJKqZuyZt2PfsKYLe88/MpuW1axdeXVO0nfFG7esfWqs3eDN3Rf0XnZw 4ZTSBXPnPBLPubF26NM3j1412mW1BPLyjVd0v6B+sW/xrSO0aRf1uOrEmZsv6Es/6ha0dxtVcmHj JWMuuBIYvRoYzT2dfAdjs3Y/Vcy2PKW3UqMo1eFkmIXDiGUJDgouCm8Mq/2yqjxVCJQcGWjQN1jq bA2eSwPz9Jdb5tiu8FwROBB+33zEe8T/adY33m/8/8g5Gu4M+yNKia3E1VOptmnKSNtYZZZyJOdH +bTdbHdbZZWR7CBYp9EdtJp8eW+YqN2kwRvabJLTMQMmgaMmES0Ag5uvf4jVhrT7QpjgHEsBHBVq Ji/RSvh8mpbCb4hIMM50ZKF4lkn5jB2gsA220CQ9QeUwosbGIOCfrx9xrgXgrJbD0YsKVKFCNaRO jirQdIAqqPEzqgrgrObhr6bAJ+Qu/grqDw2r+JWCB8TBKhhWcuEngVkg8AQZUIUjEP5F/AvHFO4b IYuxsa/MARsAzi07NgMVYB86R4R05Bjt/mTbkp2X7Vispb7/4775rLz2juXPPL5s+TNYO/xxw5gN rzalvku98yDdtL/21kOvvfHSIUiVsZ1fSsfBrwJ0ckYPLLeutFGbifKlv0VYX5SdQZPOF5TxHTW3 Ts97rxO918FqAwyvH3K+0JE49PZLwnjDrgbs3moQu7eGGcw0HBycNdg7Pmu8tzGr0Xs/u1+6z/KY /bGAWW/xG+exudI8ZZl5kaXZ8oR5l2G3cZfZ7MEiyD+YZM2daltoW2mTbNjM9ZR2dU+xHtmIZm3E AuVRrEsaiM1mgnHS1cYgmp5n1fPBtuZmo395pkQYUgdahSYmSBOzc6GYk4CYk+FBd95hHQ3rqhEu ZuWVdEZeSSfYq65XdvnBjC2CWUkTf8OSzEdKxIaevvXHl5xMHF8i+o71eGxbsTccw7+w6DBv9Qiw AW3DOyt2qp6z3vjMSVU7c777w5HUT0u+umX7h+Ed/pWT1z712E3zbqc3e589THOo8RnKVu14OHv+ 5S++9c4LN3AZMxRz9gkoElFitFZ7zMhkS76l3DLEovR29Q5OYhOMF7vGB2ezGcpMw3RXY/BA+G3l b1kf+T/L+sz1nfe//Z8JyvOEw4kAJ9cRAU67WLXPs/Tw9GO9LSNYjWWoa3hwknGiZbblM/ULz2l6 0mqnbslqQvBRNvDBge8UgLn7ynjwty3fbn/DQe0ITG50NDtAmhwn0gTqcHLKgcsLQoszWYfKMQjf R4BAQCmMLD7iDisfcZx/K6gUwM/aID47jqXOvP2I5vtE16mT+RSN0Um6kEA5wad12EXNEVJMmxBL OiF9dP5Q+dhfUFrD4lHHz1EXpy+sT0GnQCjIcazMIZ2nM746FO3NeTGYcXrCQHPYl3KOzqS+Mw+u /NuyeW/f2LippLUj8syy5Y9vvfaqh1c/tP7Mo5uptG7cQGbFSr3z9Veff+nI6wf5nI0AFw2BztyY s/GaN0yCbuhUDUqDodY0U5qvLDTMNOmhgvMvAIiROKZdzKGcIM8LnO8rp12nAnIvZz9/r+BA56jA wOA4J/ZdB6c5FwSmBa9Sr3KfYqd8dnzq0mbxesd6uHUqeYK2jfYt2NZjl7ODRh2+j/MU34LWxc0O gBow7vi4Ab0rCxTu1eDG/FAY5gDSm/QApNfBARzQDAVF5UmESgTCOGvNj5fzozaQi9kwDXvK7Hk6 La+ovGumsByL2UnPFDoCOE1g2AoNAhOREnymfskTGxKjOo7BuQ/tT3hDhNnLwwQym8KqOhanPwDC zVEREsglKI9hEySWXgZx6aLCIqZRsddIlS7dW/ztnq/whQrXh3/D1yDPfmlsuXn6+o4jbJy578Rb VmyjE72PtmF/l4RPL3ZLfZz6lz2yY+8cetfqwXOeABfJwhQ2w1PnpRYt5DJQm7/E39OPTxj47zc/ YNlm0Qcs3SxJ/wG/7Ofj0S0QLs/RWySzLWikbpZwZcn4vr5xs4u6OrM02ZsvI7z7TrAlPoi9+pbz o5YIhss3EurXOJn4NQvIJKMsdxOKci4nHFIsNClBOEJ0uTjm436uowngc6wpCuC02MdFHvX599G9 JEpO4Ut7XTp1Rs5gVLkqLSK4jyMsgKvWfNcxQrlF8JALOzIMOlUPDckOdzJxqLZsipW+olX4yATo ZAkW3nqX8ehliCSwNe6TcvO9kS2bN2cFblw+ckp239KLhxw+LN23fvH88qGTnA8ahzZetv7sLFDE oNQ46WtQBN9NslBrNJkUV7Ep3zXSVONSDTn+nGJT3FUcqzT1cV1kGuqaqKszzTGdNv7otvaIFRcM iA0oGFmwsXhLsa5PtE9hdfFQ09BoTeGE6ITCubrp0emFjcXNxUcKvox+G/uuwOH1qO52trOtWzBL JySJPQKXFpcjzeQAeQNurXZ2nVaqBIM2Y01u0Gz0uMvyy4z5Pt8bXmr3at5Gb7NXLob7htUWi1hF r2BrQqMUbM0r2BrfGCc2qH+dZmu8Ft8ol2FrAM5qF3F69i610XySG87bbzts+8TWaZPDtmrbGAg6 QTE28DBs3MK+KOTC65Te5MnL1VqbP1G8NMrZW2J0ZnmFszdEmv+Gw3UcO8X3U4JwxLaQY+kvmyDo c7GXBygKBZKvtPDATz6BvbtCVn65q2jWDlPp4KXXrfVZ6fLkByeu+Ott+655YuYHW/7r63ufuG7F 1u3XXLW1LjAuv3TG5IrkrbTqo3soXX9P89l5Px++6mmp6K8H9r/+4ksvcu/HGgQ48whGF522B5+W ONDqhq3KzRahXufLvfG90L0WWRT18/rLvXqH2eGS4JWyBRWdC2GY+QatrE95p4EeMFAPRpjVesDA YLB2E7mLEwgM3280Bx84BKRjEA1YSBeliGLhpGJw8SlBrZ+5+QEI4abi/BTiUwCMFm5Cb3mf8qTn hIct8mzxJD2dHtnDXPnppXc72nAC/YHv4g3oIDKI77RgqBzQvIJK02olgsNAsV0L8KfT+iC2TeM9 +GgrXk5Gu4dhGs9ZFJBLmVX4RGZi04SKYu7BSquD3NkhqNOqWnX5VtWcTS160CU26CcSqwgW8tMB ZJhRuIYR2CB2Fahux5q26w8s/8OItmXzx95WBZXw+zsbHnugYyp7eM2142+/ruM50ORaTBQuQevT kUPapYY+vAdjDBsNWwxJwwHDJ4YTBh0xhA2L8PWmzZmio4ZOgzGML3ngm6v4HoYqXQ9fhYK9Paou H59+2ixvkZPyAfmorB6QT8iMyBH5DZzJclpXZrUAMuOGHQCYMhnhKcgFZ8O1NGcDkPYPAziL+BSM oTxa/9vRQ0CZ8A9nvhHETS0uJJYsToidOZDja9va2uT/Pnz4jFuOnzkCtt75CL6R00/02Un+ptXI Sr7SXy7DR4YVr15RdDJ2qShZhFpMTHKZ8S0Xk4730KTqgg7bRnB0+LKwLz7faNxoomFTtWmMSYKV cVqr4JhgSoc/CUPBJGxKE7QXWB8IyUeu5/3AJwuACyZ/lmt7lHfoHFULPQW2AcJuueNrMakexW0C 9Cq9iJp2d5WVrbHr4RZGsKdVb7fF9XZjNjVYddkI2+QYwT+fgz0kFZzeha9YB5Jf3Zaak9snXNGn rWzg3cPlr/76139de691+J3ylDNbDo6awekVuCD9jHExsWlaNreNIbHViepkg2Sz/KCcgreoa1tB epkT3tM0AOJKAyDlLzWxTForXWlkTjWSJTxSJ1qdBdxDdaINRydWgFAQFQXaTShRZXil1ArDMEyF 2t1YZ7xSWmY8Iv1D1T2h0pga1+XrK9W+hmrLGEu9XK/W6eoN18lXK/caXlLflN9Rj6lf6X5S/6V3 O41GhDPKDKGo8D/iBE7IfJ2KYBxVwjKbYkRYFNxXOOEuahn7v/SgWIKvF1AbNkoDF+FdyYX32aZF I8I6EC4AXWAjFCBTPmH5sBUJrca33RhoP6X1ErQvZpx/1gW0LzCZwEAErQtzAt9g5XTvN1v+Hh02 65dzzbcQc081VB/so+Z7Is6vfkI9xXondqjwbxng6BPfAdFh2vVVksgzS2+WEQimN9wkMcTP89Ac 2B7Afyx7akZDcU6lQY8vHWBB9+OWnP+vsSuBj6o69/ecWe4yd+beuXcySybLZJkkMNQgCWBCNFdF 2ZSAoBJIFBfUBJAdQRBxxa2oKAVf2wcidal9Dwhh0/pMrdqKUtMnatWH0J9oUUvL66O8WppJ/9+5 kxCX9/u9gdw5d5Y7M2f5znf+5//9vzrcHexIibsdJS61BvoH2INfAGKN2Cj193Z1lAgKT0eU7j7u MOnldCfOdHG3I5Dj5TSjs9EbHeuQlymRKD4tEmkQB7zrVEec3vzHHUn35aBfuegHgsIXCMIrgDYg pTJGKPvp59l29vLH2SdvByj6c7Y9u7Tnel58a3YG9cu7cBgpxusnu33CQKEHde0ceY5Laa0d7t4P Pdu9d9Xoupw0phsDlK1NvsM+bxMOJ3yeYt980Nd6fdCnI8Ur18DTldCcEKaDZ7NJYl1YZvKB1p5W +GhbGuMCDMiBCG5bu/4YFMfQyn0mC4Xevk2unO2SJnq/brvQVAvhjQnzRSaLzuhGhNi7OgUhFr8d c6i/Aj5TGfsVsd9cbgYwXreAIfU759JAsDbtPeo9qv4+9mnK967vVIrHlFSZGk+mVI+nrKjAn0cu hcz8ZYiD0rrT7JH05jRPw46F0o8gfs0rVmyCGoKFGGA66tbhCHVonEMDiMxzmFOnDgszBrcQcyie c3k7tHrLrWJYq6PH048kWVJcLtl/uaS4HM7/5ITpckkxSybFwhuPZt3JOQl0x385zl3kL7kX10MO q5qyNOuWMPY2S7wY4aNNmK/oPW5rDBx/wuJKUTH+6Cq5ZjnpRISTLKYRSfgfUqI8vZct2/lNC0zt gsiHo/1xBDDKZ6A+nPSITQlgM+Q8w4MWgxjDlTa8+iZqbLJURPRwklnBvL6JOrd0QfvmkfeMHQMc 3Ola+NEDJ+4nhz3dvnRD8ar9//rTnWUt581/vHPa9ZfcUe+tWD/x6munvbBtd08l//Gcq+vXb+3Z wDuWLZv0L4/2fEBjhXyuz9Bfouw2x/Z5/DZ/1txrfuL5g33Cc8r2Yy494TSgwyw32UazO34k3hv3 ppRIKBK14HMxfzSoBUN6qDwu/Ky48LkCwtsKCG8LE13O2wqIqTtQSo0pQDbhbQWEt4Xzr9wGDQhv C+enEMtHU59w6AKsF0SiidhqAZmfPK/4iTifH98c3x7vinvjiJ3Li4qxeQqyVO7IOzMEBzpc7hA8 43DBNccwdB0uF+Ojj7C+6cBNjIkAanfA4YhRiEURzBKFVQ+8geoN9wKtfBzSDrnGjfrDqqZoMiKE zAqgG0lmaFaukSlEAua0dYFo5RyKKxrWbeI1W5YcmvnkJFPrHDx77KJnvBUbtl00/9Jht/Us4vfe PPf8dW/1iBiq0cAOKtGKQSnBZu+G3iSmEBCyjolBBnbQMWcRPZQQT1iyltDH+McqV/iblRv9bYpS a9Zb9dHh8YvMCdaE6EXxFl+LepnZarVGL4vP9c1VrzfnWnOj18dvYXmq3xec4cHmojZDn+OZ5Zul zdG1WIFXDsNkRMqTYu2TFN1AhmfmQjqyAHNyQCDN6jTc8PQJ8f1EgdpBFKjRUehy7PJ07VDEhcqm nAKkc/Zh2Ah6fBxBCSiHyiU9hIWwJGIVIStE0ym+BI4CQsiNWmF/SCoP7ezgkmQOuHR2PkEKaNT+ xjsOQKEVgoD9D5zRkyO8h6YtdYpvinqt71rVS3MTvdAWkiRQkxHQwsBF0eit97/2EYuu+PLBw9nj +zrW3Nux8541HUgBULl2afb3PQe+vJMVseBbb77129fe3I8vtCbb5i1BC1rQU7nWWaub3zPPNSeY 3sbU9hQvTg3SywqH5Q0rvKBwfuqRlFIfq0+Oj41PNisz9JZYS7Jdma23mXNjs5NdqXcih+KH8t8p Oho5WnQk1ZuKlnkzZiZvuLfeBKfBnG5+GviyMGsGwiGAPwSd+6OAzqVQorxbY6bmaDOxP+dNiSZM ieaE3/YZFIhQ15poSJyTHc/pNFFbCs+OmhCFY04ZVba2mNk1vMZKS9J3I+Z9QLmwxjmgXEDF/UD5 KWGNBabuAuWCBQQTia7MEsUAytlAKoRriAGUfxMmx6qIxiMNxz6U3O4zqqDGCIGDyjDEMfrxuzVb 69fddF93+5LDK6Y/fFb46aXLnn9m8aId2TbfSw9MnvxQ78ansqcfvKS+57Rn64FX33z3zf3vE4I3 NtvmOYI2NKUCNsJZG+AZPjg+ik/gy3V/Y15jYkLikaLNRb5auzbZWDTaHp0E4J28zr4uObNoddFB /7vWZ/7P9S/i5iBeqmfAaR6uj+MX69N5G/9A/yj+SfTzxGfJf3ADqjSRfCCsIX8EiJwUioVqIC5k dhvMNBxjprHa8BYJIALyPgQPCCACRiCHrxoCiDAEEIFHMZFSUxpRmvnIVAg/RLy8kSraWBz+Nr5a TsOMcFQcBQYhiwEmC7xcThQWfR19+A5steckLcO+0TBQ8oQqocDBBV4EuOFrqOqQwRsufyn753nv rHptwZaekp8tW/T0tqVLnsq2cWXURHYWkzdn73p67d8v9PzbgQO//NXB935FM9w9aJrX0Sph6Q1n VLXNTC8r89Z6L0SqmBu8i71+Nayoihq0w2pQ8igsIIaEpKlVjyBSthTBPzYvDf/fK/t+X+9vTnjA yh6ERjEPDfAoRB+WXBa36+RPtMb07RwIs4PJpAGOROvJhRSBSH2WJBMEMQYKEmtCIvShdSFFkLo+ gYuoIY4ufM+W89oaZ1x13gUXjLoqUuSteHLB2PpnKsc0zlzYc5BqoRE7AjtQC0M9MWeFtzRSWq+O V0eXX1E6q3Slula9u/xp+/khr3iCaiw/Hhs6Ych7MV8SsTzcHMa0eIvSorZoLYEWvSXYrrSr7Vp7 oF1vD3ZWdFYalRXlleWDRpRP15oD11dcX7W4bDHIn49pP9LXVW0Ysn7oVu05/anKrcjP+lpFFFvY rida2lco6yuU9xXEa8iEiNdQQbyGCuI1VCjEKsOxiuqmK5VpXfPmpyryvIGzCvNpE6g0MYQqvzjR mGhKXJ3Ylng74TcSxYl5icMJb3Hi4QRPvIS2yUO/EFi3A4+cA+JG6IuJbD8gLpjQdcVUszMSraV7 xwxBdJqd1VI4p5AXFuTJ8IpoC1oAExSqBKSBTKRNFtBbcFagGLzC8oRjx2uH0durBV4r/FuagYHd YrTgmKJ3JlL0roRYOCYE3p3A9nWHXD4Yb91VUNc9mKH0mbC3KLjcW1GgekDhi900TAfni48qAfo+ c1jXMN44bPUwPoxw+3JJfGZO4DXl1jK/XBToC1DBVRpNlRvCABvi6xkpYT1oEYOvCAshoqNyMGPp 4b5lbeLsHDiPQd5H5UZnNkFtXDgxt/WdySwYEMNPzwB0xIsajy/AbhiBGAsF5ZHu4BTjf277G4iF U/m9ojIAvxVh0zJt0+MvDaaSklolJ5nvezgURXBaEipLSqWQdFQGAdqoqlQ1f8YLIW+zkPwsNypV hKbSCjQzOHPHHYDB+m6kfwNqeb/CYmVFJfIk1WLvnBzugVRKYKIUM0AmqqKxw7h/xcplw9OPvf5E 0/nnDH50ym0vTQ9v1xe1rWyPRquTd7+84Yq21297+wN2bsHshbNGn1sWTw8bd8fEMcurijNjV9wY v6zlspFlBYW2Vl5z/sqW6Zuu/BmN0/Lev/DBvieg6oXYVQ19sKyCcA/soKCwGkKZ2FjWmEeKmtDN 0jB1ewKGWQoqetBK66xXVi5SL5opz4eyxSOQJYHntFneLnfJ3dCoJpCZFm4okBCwKPxFkCLwCK3H xCN/Ez0NjxBk6fpkNPejJCwXnnC9SvkF3g6e2ogdwCjOwJNoSiH8DDLOUbLw2DcjFXG0aQ24/LRs zWTSMaq/iuG0MxAeKZQShS4VN/Mvabh2zpC77965a5edqSp6cpN53qwt/LqHmDwn+/2Heh67dEg+ 1dFdsGVHKE8ca9on5aNuVKzcecqOEhH+hFNjRWozNitX7KjO7GgA+yphVJNUE03HY7ScyBdrlZhY pcQsMtrA3XNkk5hYpQjYXqxPYhGqBZzn0OCYWHDi/BQRf/2X98ZYV4zFJkIgDHgALU3yT+Tz+fmb 87fn9+Z78wFJ0zMCEiYt45TarR6BrHwftEkFd+LIodFYobhoswsGq2JtogowWJ2Y+BokgOmCgky/ sQjBDEL1jmhhMXMI2C/fa4aCRpCYfSRdgIWIV09KQSXsQoBQJYBjhPGQ29WsROMA6Y+JHTIBCXoa V7571VNNZqAzEL558uS1ozp/1Dl2btPwRXxdz87vnz1m8pSH7+N1gEuZhCbyHEPraOyLHF8g5lMk TfEzfz9ttJy6n686M5A9Su5Zcs9wH5NKw3Ua2fdguE7FMrNWoQPIll/sxD0MsrjHK37nqEUltVIV Djg75qhAcqQoDjj70FlVdRbis3Ew9EFSFUJ/66Th2lhpjHYFdGmalWnqDewG3qa0qcukW9gtfLmy TL1FW8PW8Hs998v3KQ+oP5Y2qo9qP5O2aC9Je+Qd2hvSa9qH0rvaH6VPtNPSSW0Ifo4Wl6JalURS Uk0SIDSfY0VrfVjK1ubwNqg/S/TTJXynk45BplojyW6sRoA20mPCnSUyrXiU+3x6AAaw+lAGzFr8 HcgcyEjV/eTakRowyLSqRVRVwxYhEEbBugRMCZdFUCj9Mgh3EvNVQ+umVHEcx82jwJK7HEBZiAJn SUdNcYeVBr74Txq7CMPsae1pzY8fP0pMegzWun4GZViAimcokgALYTgFH6nPfCLOTnBcBaURXEb2 79k5/3E0DY7ZH/dlb/ZW9Nx947ypS/l9hKW7HMU96B2Wt7Avftgiz1RYH5cEJo6oroNCBhgzKxji JAgcTtERT4DJBTOGJzC1UinsiHMt7GGQopVR2wZqI6jDYCHaBiKsyFsXBpIj0CnX0IUx6xw4YL53 wDwoQolzPFjx6+iH0WBIYgRG2GDvII2PD88Ir4WeK6ZEscYhyVkx6bsF4FknHLW4pNYsQNQOhvQJ Z09xea3Xr6u2P6kmLB8SjPoDiHtWLFNCagi5QEkGCrGCTcuDlUwIqU3kemVUaLRnjN+RL1UmBC40 xoTHWzOMy6zZ0Pm80Vruv1VerOzzv2Dstv7qP61WBcJVUlWwMlRlVFrVkXOkkdYtyr3KRs8G/Rn2 LH82AKKMtNv/QujXwLs/UI95jxl/sE76/64WBESMji6OpjiGxNEQRyvXbZNayPBaUliRAYgb6RAt 40KyJ8j0NHb533NGkpUKovcNpgIyOUZsvxYIV2iZ8FTvZVpLeE54ZfiBsBbWvOiL1Bxuw5BbO5By XI3gZzfQAZJh+OfO/jgmHWzsERVZ9oFBqmCNopmIWtrbOwEMZAs+yzjnBs0IpX4ZlqHjELasDHYA sRkTQjung6EIopcVgDsZTQFRVSF+cm6kQCtNtryKEdZDQfH1LNhx0koh5qqFKKeQpEVOmUFGsgyr g57gXvaMo6WaNDZPu514q/xyR4WW97zw7RDZo7OA6WMzBU6MMGf2zC52yj6FSREk/cSlJ1tb4z2t C/CfBllr/Lu5yblRB18fY+//QU2WwUymPyIn09+E7cVTpnUGU3qK/xyCggx/od7uTmmokUL4yRHB ZxU09Qnba6cgKlrp7d4hk+gqchaXgAFbI0jLSu+RHXLKfdTCoyRgtY8utBuuIK4Na9XdIQ+lK3ZI 53CSLsQn9V9cXI3eFxPvC/ce2amlvClSIRe8Z7FjEOo9uNuqk4bgDwN8h01QfzMNOOEDuiG7IvKa ONKCG23HBEHaU+lhE7IvvvBco7fmuX2bhp+7e1u288XnBr0PA/PDo+H9/OaejW8e4Dec/pCv3PWP t2FpDMxD/w1LY7L/ys1DeQYL+L1cBVkhiB5pCI/cqEboPfVJEpBK7jEsZoDpS7sYzqRE3XTjB94f KBBdMrp8Xf4u+U1DNZxoXb7HVvOC+eZwVh+4g60NKNXWld5muTkwLbSBbdQ2BvbwvfqvA/tDb5kf et5Vfxv8yPxUs/oGV0BHfnQjHoRjgc85hu1tlAw/dnwlpPTwE35IMi2oG7H0Szo3INOLrKgqAweb 6NjwxzCfB5lhBM0AnAoeDHh0U/NDYVQzX5deV7mZSyrj4cHXsReV1rEzqXsQWgHpWj8QF4hwa00W s8YFV+mlmnGNX13lgJKd3OP4J/lXC3m1C51QyrOKlzahLseFV4qFautJd7LAXGF+Cg16oRRBjrUb hUcbUK25yYJSXpAcc51hrFFEL3WPryqvUtfFvhTmEtp46gzFC+sA+H7sBAqhpR2D4nZMnGNrCQGO iJnJq2OlJXUqwvBET8GhWYCmqJ/WZkw4NfDLR4wcSbtDnkpmsLuzT/z+qbMKhqR3vp99lD146MP6 7Oe8imW/GjP0gprTWb3nN2x8c7YVv6sEDJM/oY/ks//N9ZFCLWIgFWpBwrD8Ab/tWOBbOHoq11cS 1Zn8Q/nxA9gWoTuxSEdwATrOTqOAwTp97MwtqKuKXGFs05AOwkGDpKqG1pp0gNSdFQ3GrcpApV4Z HKGPCA4PPREOVFlV9thos9VsN+e1WW12W95y/9Lg8vCtkVvz7gk+EH7Iesi+P7JRezbwc/PF8AuR L7Q/RP4a7DG/ivQWFPX1qKgdKEh6jdHG3SCIJPq/vgsiuMFxFN4xEtEcCMCw4DkkIradtrQITiDJ H9bTAQ3LYA2hHjro+/T7pQKzgFcXvFzAC/byxl0G6sKJ7OVTnUCj5Vj8autlqELsZRfsNlipdFES hnGqW1sQORqqN+meSXqvziG3d8HOanAucY3OZGolDCMqr4d09tCJSGYvbp48mkA6lwXH8xGII0oQ gcDCgfoV9Sgi7/dvaVKXgslD/4HVC8HaxGFtXoQGxDEp0HuMjFeuW+2TIr0fQ+FBK4XKA0bZrjwE dLrBm+g9sDTQ4UP3sSsJ9RN86lxUBlwY+BBYotweGTWkYWwsXOELZOe+cihTWpz5pDM75/zyoSuv qM3e+JxZVZ6cbRR6q3qeWHLHyqV89ulfb7ugeQp5OVWwPQfRr0JsmxOEgPsbCrfYMDcQ4zeOigI7 D14rLOorzngUBvEqtdoEA10bxy7mFyvj1CazhU3lU5Xp6iRzDruOXwfYZQVbrKxQH2T3IKDqK3aS pCcr2CAlo9YpP1HeZzKNlj1mXi2HeYUTctApw0Ka16sax952mnGE53BGsov8Gl8GP1G7JihhNj/p qGI2z4Q0xGAYnZgMff4XObZSkd7ipCP2xoDybYb4fMgJzQytDp0I+QTXHzAgWLSLJW0VY5DPbkIW IOTGlUTAt5QwzMUlZDaIrZDbu0amrgUNR5EeiBqXBC/BLvsUS8RPBbmSGhvWA5EZOTkXAO804mEk diFSFCFLe3vd2lOoLnH2yh6qRapK8ULkSRARGzTDfdxhUCXk7o7tSWK3OZo8l5yzjhg9g5C6aB3H LjTPj54xLDXDsetZgmxCTB5RU5JXxbcumpZt8lzf84t5y9vZl+s8in/dLT1XrVB/SO08l3Xzm5BP OCAVQ/MCtM2Q6n+LmGNcWqJf2ZePqvo4UlH1aTNj6Tt3/U1t69e33bSe/6bt8cfbUMa1ev/B9nvn odY9UpFjsOGU7yiFj0iIhEID8x158O283kVs/6OPEuo8xfM/fDqYhwHCDJyWTQC8+J/lP9v8sHzY 5m/Lb9v8Zfllm2+Tt9l8k7zJ5g/LD9t8lbzK5qeV0xE+R5kT4dOV6RGuK3qER2xFxio3IHmMr0Ke r3goyJneEJQagoiHneRU2/Pk25HY2SMz+5xIAxLmNsBpcmL5taElTD5HQY42qcHjeRixXIk4peSC H+QqkSE+E0ABiVmhJDWSwhXYDDTKidVAUx3+A+cknACx/gsWMPyJG5Jt5ZUJCVRwOOWSAWUW+UVq 8IwhI2s97PG+kvfV3/7k3oZJgy6OzbjyTAk1NcbzOZ/oe0PU1EfORFFTJ5QTEc4UBC4dkY/YvFvu tnmX3GXz7fJ2m2+Rt9h8nbzO5nfKd9p8vjzf5rOUWRE+RZmSqylDD3ikyPM21Y0eRJWFUFlMeV6m B4YyVCCXGhgkVRt01FdlMHYeuEBUXcElnCOBFqqsUqKYtnZRW9iSyikJU1VhU5lUhTFQBBsZ0ozu /dcrq7+eFpDCsMvmQX4DkWOrBsyevvKVvyjOzBiCiJDf9RW8f0MFjZo8aEz06ilnStSz53g+Z+eK ulrsVLwjfyLzHfIvZf4XhT2mPKnwRcqdCgQ9ZiFmDyg5aiD3g4vED4YYawOycfb9OvHzEvqPl/d3 htyvQk8483ukvmandidCUt/XXvld35Z6vrj1VpI61nfcJuMxDxSzsPRGi+vwB787O+U3c1NiUfat vJSUlfJs6dtZKBu+lXXyEulSkctxEnK2X4Zs11Oly6UrkG97mtQMXeEZyFDdij33DmQPd/OhI/MN aptufujPSKMvGXPh5ImZ8xe2XTPn0qn/BGme0eIKZW5kc3RyZWFtCmVuZG9iagozMzYgMCBvYmoK MjU2ODEKZW5kb2JqCjMzNyAwIG9iago8PCAvVHlwZSAvRm9udERlc2NyaXB0b3IgL0FzY2VudCA5 MDUgL0NhcEhlaWdodCA3MTYgL0Rlc2NlbnQgLTIxMiAvRmxhZ3MgMzIKL0ZvbnRCQm94IFstNjY1 IC0zMjUgMjAwMCAxMDA2XSAvRm9udE5hbWUgL0RMR0NRTitBcmlhbE1UIC9JdGFsaWNBbmdsZSAw IC9TdGVtVgowIC9BdmdXaWR0aCA0NDEgL0xlYWRpbmcgMzMgL01heFdpZHRoIDIwMDAgL1hIZWln aHQgNTE5IC9Gb250RmlsZTIgMzM1IDAgUgo+PgplbmRvYmoKMzM4IDAgb2JqClsgMjc4IDAgMzU1 IDU1NiAwIDAgMCAxOTEgMzMzIDMzMyAwIDAgMjc4IDMzMyAyNzggMjc4IDU1NiA1NTYgNTU2IDU1 NiA1NTYKNTU2IDU1NiA1NTYgNTU2IDU1NiAyNzggMjc4IDU4NCA1ODQgNTg0IDU1NiAwIDY2NyA2 NjcgNzIyIDcyMiA2NjcgNjExIDc3OAo3MjIgMjc4IDUwMCAwIDU1NiA4MzMgNzIyIDc3OCA2Njcg Nzc4IDcyMiA2NjcgNjExIDcyMiA2NjcgOTQ0IDAgNjY3IDAgMCAwCjAgMCAwIDAgNTU2IDU1NiA1 MDAgNTU2IDU1NiAyNzggNTU2IDU1NiAyMjIgMjIyIDUwMCAyMjIgODMzIDU1NiA1NTYgNTU2IDU1 NgozMzMgNTAwIDI3OCA1NTYgNTAwIDcyMiA1MDAgNTAwIDUwMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwCjAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAzNTAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAKMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNTU2IDAgMzMzIDMzMwowIDIy MiBdCmVuZG9iagoxMyAwIG9iago8PCAvVHlwZSAvRm9udCAvU3VidHlwZSAvVHJ1ZVR5cGUgL0Jh c2VGb250IC9ETEdDUU4rQXJpYWxNVCAvRm9udERlc2NyaXB0b3IKMzM3IDAgUiAvV2lkdGhzIDMz OCAwIFIgL0ZpcnN0Q2hhciAzMiAvTGFzdENoYXIgMjEzIC9FbmNvZGluZyAvTWFjUm9tYW5FbmNv ZGluZwo+PgplbmRvYmoKMzM5IDAgb2JqCjw8IC9MZW5ndGggMzQwIDAgUiAvTGVuZ3RoMSAzMTAz MiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAHUvHl8VcX5Pz4zZ7vn7vua5N6bm41c QkJyQwhEcgIBwQgEQUzQSEB2qwRkUVSIyo4K1gXXEq2CgpVLIhC2ErWurYVWq9jWSltcayqflipV cu/vPecGxH76+v1ev+9/3wtzZuacec7MPPPMM892smTx0tnETNqJQLTrbpjRRvRftIgQuvq6ZUsi mbprICHKtDltc2/I1IPrCZGun/ujW+Zk6rGxhFxpnjd7xqxMnZxDPmQebmTqNIE8b94NS27O1MNn 8P7EjxZe1/8893ncf/yGGTf390/+iHrkxhk3zM60v8WOvKht4U1LMvWbpyA/3LZ4dn972kSI47c/ v7ZwwF2dbYWEnBtFSBxdoNV48g9SQzYTmTBiJ6XkSkLkb9nLREKdP5fY5jtfjhyZbqv5lyFg0F// 1F9rsnnhFbHtx99+e67PTgwetFX19vwB4JQRqQlklJ18++23KzA4/qaLf+P3TGmvswjPk91I6BjX CFIHEhAtPN+lWMq1buROt553euPlB9I9wvOdwyr0+yUPlLcfFnaR6aQCt3d1Xslv7+rS6nnzXV0V wzN56WA97zRkHivu8nBdEGClSIzY+ksTkW9G2oZ0FEnGgHaRj5DSSILwrPBU55gwXvwMXmSrcwvP YEIarseQ0kgCRv8M5vIM+ar/johR/bRLNfPuf6pDhYSfAsqGqx2pHWk30jEkiSzEdRtSGklA6Sk8 e4ow4SnhyU572F5nFH5CViEx4VFio5SE8faHu+w6bh7psrnKtTq78CBpRGIkKYwnPUgMr70PYPcR huYNnSWDdRQ2dBmt5Xa034RBb8JANqHLDlypXtdQ4u03dbm8fPB3ddocOtytnWWJTKHL7i9vBBZu JlSYLdxIYiQsrESeg/w65NnIZwqziEUfp9Zls5e3o79aNK8VPGQAHtcJXlKOvF4IkpDebGmnNdPP 0s6i4nLMeJTg15vYBAtJoKlBUDrLw5FDgqYjf32XauLjW99p95QfEdYICnGjVTta+cK2I4IRa2zU ZzKlS7WUb6kzC1MwzSlASxhjpMAyv2rCjZ14UZ1DGC1kES+eXS9kEw/yMUKOnu8QniRjUH+iqyAr 3HNIuF+H+jF/KbofkSGtEV0Wa3lPnSqMwNOkcC8W4F698y1dBUPLSV2BUETKkBhwvAqlVSjZhY0o bcSqbcRKbcRKbcSgNoL6iLABTzagTamwgrQJy8kWpG0oc7LydAKhfDN4OvOKyg8IAcEPxNgPAZUU d4NdqpWPzN/pdOnN/F1ma3ntEeEmMhGJYcpLunz+8oWHhGJ9KgO7/CEO0NYJcj0i+DJLgzd5+ZIc EbKACI6YbCGn0xNO1oVR54QcJpS9xY5zJLF32O/4crNjqPP8l/352/35rzN5uocdz2wK9luen6zL Yh/jZdPZh2QbSowdYq+QMrzg96ybrz77gB0gtchPoD4L+QHkFcgPdkbfCHez7i5kGPtjnRYvnyx7 pTNe2l8I5/cXfKH+gtNbXpfPXmYvkSy84n3kechfYj0kF/lR5H7kPWwJeQP5XlZJhiN/sT//BTvM SZztZ/vIUORdnVY+hGSnwrPdnTLPXugkmVpjafgwe4HtIkE0/VlnQRAPn+0qyAvbDuF9lD3DlnRm h511RvYkbaJn0KiDnOA5cbKnOqv4S7Z0Ho6ED7AtbIvmr9LytRJtu1CWX1ZStl2I5EdKIlWR7ZE6 O7sXDGQbw/5lm3CtIhEG6kHSkLawDZ1iVbKuD3Pi82KkHdcOvdSKa5teIrja9RJ/elov1bI1ZCIS wztWIq1Cake6g4i4rkC6Fek2pNv1O0tQWoq0HNykDRBtgGgDRJsO0QaINkC0AaJNh+A9twGiTYdo BUQrIFoB0apDtAKiFRCtgGjVIfh4WwHRqkM0AqIREI2AaNQhGgHRCIhGQDTqEI2AaAREow6hAUID hAYITYfQAKEBQgOEpkNogNAAoekQZYAoA0QZIMp0iDJAlAGiDBBlOkQZIMoAUaZDRAARAUQEEBEd IgKICCAigIjoEBFARAAR0SHsgLADwg4Iuw5hB4QdEHZA2HUIOyDsgLDrECcBcRIQJwFxUoc4CYiT gDgJiJM6xElAnATESbZ8j3C87lWAHAfIcYAc10GOA+Q4QI4D5LgOchwgxwFyvH/qHBGcYHoA2wPY HsD26LA9gO0BbA9ge3TYHrTsAWyPDpsERBIQSUAkdYgkIJKASAIiqUMkAZEERFKH6ABEByA6ANGh Q3QAogMQHYDo0CE6ANEBiA4dYgsgtgBiCyC26BBbALEFEFsAsUWH2AKILYDYokP8/14adgdtMuCs Ze10gJ6vIl/q+UpyQs9vJ3v0/DayXc9vJXfq+QpSpefLSYGeY6n1fAkJG2hnuMpW5wULmIg0HWkh 0jak3UhHkRS9dAylj5DSrFLLFW3KRGWbsls5qki7lZMKs8kT5W3ybvmoLO2WT8osUhdiFp2PgrWQ zYCjZBWuXyHhEMG1Vi/VsgT6TYDPVuJfgiU0R2/kq2J6rJgeLaa7i+nmYlqnskupqHO6CKliQABt 0swFI8InkKoKCkeAM92770tfuLNgSLibHs5kA7Q4ql8i7UHajnQnUhVSOVIJUj5SGKmqoBhgTVpu /ysPIy9EiiJFkKqI1wtR0ekwaAeYhW7vetVCVN5PYRHgDnUWliHr7iyciGx/Z+HMcJ1K95FCLhXR vdhUu5Dv7gyfwuOfZbLnO8OHUHu2M5xA1tJZOAjZ1Z2Fb4frLPRKEhY56JT+fDIWnNev6AxPRbNJ neEByOKdhQW8dTE6ysfTAZCoTyFHWYfOy/QU6wwPR+vcznA1b20ghXzhqUxK9OFJKPO60IUBfXWA NolUM4V7w/eHv8R4/wbEgjw+iHSLyI7ld9OpmjF8uOQnaFwX7qwz8vY4H/b050me7w1vz98Qfgzv ovn7wo+EB4XvLek24PY9GPcGvYvO8J2RbrZLc4Xbw2XhJSWnwjeFLwvPCF8RbsnH/c7wNeHDfJik mTaxXfvCjXjhOMwivzN8aT7GgiGOCd8S1sKF4erIYY5fMpR3DUouOcwxQMozvQ8Efovz0Xtn+Mqq burQipXTyhblamWkMlyJKblKjpKtuA1Og91gNZgNRoPBIBtEAzMQg7s7fVLTNRK3rKsLssiVBlEv 2xkv44IrYdTAyGUk6RIaWMPkkbQh2XMdaZgZSX49OdZNjZOmJaXYSJp0NpCGKSOTQ+MN3Ur6imRV vCGpNF7dtIfSe5txN8nWd1MypambpvmtNaGkcxQekjX3hA4QSgNr7mluJn7vslp/rXOEo3pM/X+5 tOo3W+vj3//8Fxezkw81TG5K7sxuTpbzQjq7uSF5x+TINU0HmI1ZRtcfYFaeNTcdENuYbfQV/L7Y Vt+MZqf0ZqBmK5qRQp6hmWEkifBm4CcjeTOsUaZdAcDRLsoztDNaSIHersBo0duJlLfbcyIyun5P BBe0ySfkhN7mRD65qA0oBrD1ewpwQatYhDbxVrQpFtEHNkB/UTiMJiW4oAmFvKe/KEz1zpKl3zfJ 729SeaFJpd6XkBmP/hp+wWvcRefbuIvQ5ntE/p+VZo+M067BS1e+Mnp2bHRrbPRspNbkpmXz/Mn2 mZHInpVL+YNIUihonXndPJ7PmJ1cGptdn1wZq4/sGazD/cfjV/jjwbH6PeSV0VOa9ryiza7vHKwN Hh2bUd/cVVvTVPeDvjZc6Kup5r/0VcNf1sT7qtXh/qOvOv64lvdVx/uq433VarV6X6Pnc7pvbNpj ICObR2Fded7FTEbQcGso2jzSa28bwQn6wPCof2XooEjos8QUb06aYyOTFiT+qKSupI4/wj7jj6y4 bet/5F85PBo6SJ/tf2THbUdsJDm/EITDNyQrJzUko5OnNXFSSWpAwX9bs5v4T3/sJ6Pn1+M/6kv0 tOSmJeffyHPCW/7v35L/9lu6dOlNS3BZGr+JkIZk8eSG5JBJGImioKvW+mbcG3T+niDo9/ao6uju dA8exjEIuoR3x0txGgcGNSORicI65A6FcS1iSVcwu3zhEcgNq5CgDrPlnTAl8EfLu3LzoS2hSWll Joe6yuudwWg5euiqAijP8zO55ihBYUv+lpItVR35HSUdVTKe7tuOm+Ht/CjtLN0ukCXxm84jA8Ul zUA2hsX7e7IzK1vvuIMX4vHm+E1Ux9f59t/n+n1Uv0cs5qj/btJfz/GtYxhXXgTS+VOsR6b3pbzG f5mCDgs860C4i1aZmn6LX77/oQZT0UGSpacdJEssgI5F0qfOp9T89Cn+jOfsC3ByWJB46v91kufJ +7SIRkgX/Zb4yFkaoIPJOFDnN9AndpM+8iDU+ynkIeokedBGryTjqIg2cXI3fSy9LP05uYT8mDyV 3k/vTO/E883kNXIWI/gTTswqMgHtrySzyefCx6Q5/SgxkHXERIaTK6iXzCDv4d+/MI77yQPk5/S2 9Fn06iZ34n01pI7UpV9KnyPF5G5xi3RC3UvuI4eonL4uPR8SUi7ZyOLp99IfkQLSTH5KnseY4rRH HEui5HqyhjxMA8JrKD1IniYpamYtwijpKHoaR6aSG8lyspHsJG9RJ22UTkin07emPwUVukgRxjSf fE4r6Xj2jGhOj0j/nlxNDpA3MF/+r0e8WtwhXZ2qTT+Rfhna935qpIfpS1K5dG/fHekn0y/AXllA BgMjE9DPTHIXeYm8Sf6H/IOtSq8iY8lk9PwqzaYRWgCMv8cCbCVbKbxDBmG2LRjtUrKNJEknOUgO kSPAzR/ISfIxddMQvYzOpPfRfzAzm8WOCY8JLwrvilR8DviOkXzgaAl5huwjvyJvk2NUwvvLaCNd QBfSrfQJepIl2ZfsG9Eg3iV+J/ZJBamTqe/SE9L/gs4dJJeTFWQVcPtT0kVeJL8mv4NV8p/ka2qn Q+k8+iRN0pP0S6ayXDaRtbGHoD3/TJgg3Ce8JFaKI8XrxbfF30trpU3KDCV1bnvq/tTPUr9J70// BrRjxfsLYMCZT+4AVTxDjpJ38PYPyIfkL5x+8P7hdBq9Fr3cRNfTB+jP6Kv0N/QLzBISB/7lsuGs Hr0uZIuBpzvZ/ewB9H6MWzpgpPiQ/Y39S5CEXGGIsEh4UkgK3cJx4RPRLhaIg8TB4kRxmpjGypRL l0qTpWelXdLL0mm5Rp4lt8mfKXcqqw2/6ivu+1OKpOalkqku0K4BlLQCmPgJgREQuDhE3gJGf40R nyRnsApBGqWFGHc1HUMb6Hh6Fb2GzqZ30nX0x/Rh+hh9ir6AGWAOTMHY46yOTWYz2Gy2mq1j98CW 8SI7yN5k78Gg0ouR+4SYEBcGC+OEacLVwo2YwxKY8lYDs/cJO4VjwjvCp8JnQi9WzSfmiEvFFeIj 4g7xRfE30uXSDfj3lHRU6pF+I52TzslMDspZcqm8QH5W/osiK0OURmWD8q7yT0MbzaLFGHkEtH/h xwLYgzlsJ3OLq2gvbmdD67Bh5nGsw2Tsin+SWiGFdbHy5xibhwVEFweXNTEJQXAJPUQq6atklcwE CIbiSdJJ/8hOiq+wS8jvaCsNiDuEG6W3WJTsAjfawg6zQ3QkeZHVsKnscYHQj3Eqfgx6v5k8QK+n N5FdtJcOo7fTKrqKvMu8wmS6mtSkn2IiVek4eppgBOQOcRa59sIU/muBVsM6/3nqJ6JFvA38qZs8 hBV9nnxEnyPfUin9JbibAG40A1zmbtD7GsK5Xgv22SrsxwA4yI/kY+RFKsOGXiWPEFeQ0+Tf5HPp IChqJLjpp6n54k/Ev6ar0iXYYdhl5Fnsu3nkUuyYj0ElR1DntWuw043gJTA+kkYyDcaz28H17ksn 04+n70rfkl5IfgnYb+lA+i3twI7oBkQN7F5vYJd8QDdhH176X6f3/3kzNYv0kC+on+bTcuyHXmmZ tEXaKb0o/Vx6Wx4MbK8mj4Gi/wJqNmIG15HfkC/IN9SAtQmQgSSB8Q7F2JvIj1izcISMokHShj1b BD4+sn8mN+EtdwJ7j2M/H8HeOA0+cQ35OexnjPowo+vQvwHvaQCep5ObyHas4F20C3dmgWsXk79h 3lY6FOaBgUTDmx4C1+rBmP5IPgG20/q4BoIv1NOpeNc35CoyCz0MIY10D1ZgH6kGZ60XfgV851E7 GUlz6dOAa8UOtcL4XS39lTIyMDUhPZTNF47gjEnjfgdOrxC5hC7CKGyYRx/x0ImkMnUFxvAOFcQk /a0+ikfY7PQ6YXnqR+SX5DmsiSYuU+oJ0eqmaLUjLqkZPqx6aFVloqJ8cFnpoJKB8eIBRYUF+Xmx 3GgknJOdFQoG/D6vx+1yOuw2q8VsMqoGRZZEgVEycHRsTGskWdCaFAtiY8eW8HpsBm7MuOhGazKC W2N+2CYZ4XAz8OgHLTW0nPMfLbVMS+1CS2qP1JCakoGR0bFI8u36WKSbTpsEbSJ5T32sOZLs1cvj 9fIWvWxBORoFQGS0f159JElbI6OTY5bN2zi6tb5kIN1jMo6KjZptLBlI9hhNKJpQSvpibXuobwTV C8w3etgeRgwWTDEZjNWPTgZiAMVrhPzRM2YlGyc1ja4PRaPNJQOTdNR1sZlJwqXfuN6EjNK7Scqj koreTWQ+pNsk2RTZM7Bn493ddjKzNW6eFZs145qmpDAD7xiddMTRb33St+KU//sqXg45ed3FT0PC xtH++RHeeOPGdZFkz6Smi2BDUf6G5ma8A7Asf0zrxjHo+m6sVANXqZJsTXNTkq5Bl1AW8vVZZeaX 0WTyWxdEkmpsZGzexgWtWJrgxiS54pZoZzCoHUifJMHRkY1TmmLRZG0o1jyjPmuPm2y84paugBYJ /PBJycA9dkcGsXustv6C2XJxYTaQnnmml/TmvNRwxQXMUj7G2DjI48nIdRGMpCmGOQ3ll9lDycbr hmIB8GumgErOworMT6qjWjfah/H7mCJNSvn2WGTjvwgoINb75Q/vzOi/I+fb/0X4Q04nF0gtSWec Lyfj8WRxMScRZRTWFGMcodcrSwYu62ZDYm122EaGQBEkjcDtjOZhpUB/NMoXeFO3Rmaikmyf1JSp R8jMUCfRSqEvsVb+BAuYeeK5kj9pP//kAnhrDJT8IrdbEE/SUHDhv83udY2eNyxJvf8vj2dnnjdM jjVAu4mM3tjaT7UNU35QyzznCAXe8Ky/lHSNahJCDPd4iYUE/SmI8pppF5qg0mROivn4L/NBY3cI IEr9Bo2MSdpbx2auzcZotH/L/G+YbsVwEVB3+jSH0rPvwfpnkRwW7x9nZtTJ4T+o/2B05o1CwxRw HNYwZdrGjcYfPBsDXrZx45hYZMzG1o0zutPtM2MRe2zjAbaD7djYNhpcKLOg3emDm0LJMXc3Yyrz 6DCQLSMj98To+kl7NLoe6usBmJgi66c0dTLKRrWObG4ugRAOa1M1JIqb4IvZSa5HGoX6UuQ3Ib8f 96ciPYVUgTQeqQDpaqSr+tNk5HVo/6b4PJmup7+SBcrb5BLpdehJr5OHkGYgPSBNJQ+KfyVb5Woy k9/H++8GbAzlR3D/CXknuQ/lh/G8mbflbZBfhmcDUb5fmppOK/cQBXWveFO6F7DjUF6H/ErkU/rH 4dfLfyU/5uNn1Wk+9g28rGSTlXh2H9IVSJuQroYDlMOXYfxh1O9B2YT+VeRmJCvsArno6xzy1Ujz 8Z7FIHCqkzmB9iHTZahHcJ5xwoeopl/5RYDUw38S17eRGxA1YIQcaIbX0Ipz0U4cxIn7XM5zQ7fx QlryQy7gXuIsnK3wv+G9UWheMeiB+ZDsCSmEbDAAp3ocJyn/lehXfhmEVAp34mBIQRWQLCrJEEgR Q3F+D4P2VwMNaQSphQRQB8liFKkno6EnXArZ4/+e3zgM9TLIOQQaFP8NIUOg2c2kO+hHTGb52A2f CYfEueIZ6WfypfIzyhKDz1Bv2GA4rl5qdBh/bbrTHDY/YP6npc5yyjrB+mPrn22v2c44cpzZzidd quuQ+2+eIZ7t3lG+Wf4S/6WBCYFfBRcE/xL6LGte9tTs93IKc+6HlXl6pDryQrQg+nRufu7WvGF5 b+WPyP+sMFQkF7064O4BzxVbipcXr4XdFsOT8A80oJCRLzKakpVuVqu5iCSmBGJUxBQlAYMspZhw mBYQFUqfn/jj9q9r+mom2M/UjO+rIbUo28/hMrgs6og68nGBlZiciwg95zSJfEciYg+nN2f6U/Fq 6R0eW0BnaOsMouIcaxxrbTI2WWW/2UfdHouXup0WL3PlmH3MFVCD1J2tBpmLGELULRhCzBU2+yS7 w+KV7FaLV7aZzD7ZlqUGJbtoCEl2oxqUbYohJNvUYHBcyOAOhQwWr3ecz+z2+cw2q9VkMhoVRR6H dzjC4awsUZS62ePadOb2ePx+Qscxl9OZk5OdLTBm8Pp8wWDIaDGbVQNxu1x2u22ExbzD9zfvDovm DyYsWl5BotZCN1u2WZhlQlSWJEZHhNQdwb8ZdpSFtFBrSAhNiDx1G8dXy6m+U8BXjb0G5cXx+Bm9 ihrHH661/EmNs7pUb8Irff2lr/Un/Clu6Rmu66RB8dvtv1g3yM8z23/8BpfRFlessgIp6qoQKnjy xJCiQswVE2IUtx5d/2LNaZo98eTED8d/1rhxf80/UycnfjT+TxP/Qh8e/qdh9IY/0sIP6drUCp4+ TH3wx0xJ2JD6gBaCh1yfmsTmYTXtZIxmLbLtEJhBRbyRnTgNR2guDzzClbAHNKP6T/NjEbFMZGI3 e6jL8cz1Oj56+8702ntJbS2fEh8wjRWwSrtrSFUFYx630+dls196pOO6qat7Nsy9pDKWmvQp/cfn ULTZySOp36Su+vvTqWcfm8M53CiMRNNHMk7zF7JC41w217gV2+xZq6IaEAiFMdn5mAjoVx/Ti4Z/ So+Z+WicC0bx0fT2nfrhYFwjhMoEEyq8To9bYcLoyfXDsuZsOLp1x8iG51OTOn9+9qOlf6fP0dL3 Uzlnf/NV6kzqOz6SpakD9BnKdejavarBJBuVbpqjheTH6VAQ3mJaoOTZdGZZhv0RMM9d5o9jE7WM P9UHRIzvPdNHHdXEUV09uMwV9bhlWSkcMqQqdjcNFC+dVnXlWLaeBt5ccU9bZEnWTISEUVJH17H5 rAO7t1yLllENqlYV9rJdiAhlgijUS3Yw5jI8DojP/Ij3daplvP2TFlLa24IusFfrWBGMFIHUp/xt 9+PyPEYvkDzNw4YSIyu4aLTihdH28bEOLqsA/P3c+MWhGZmK3W2VenBiRMj9WsPNxvXGHXSnslPd Yd2vvqEapjqavc3BqeG5jnneecG5YUM1q5aHqEMs49g4ebQ6xrJD/SV7U/6F+gvLB+wP8rvquxaH 3R/xMz9Ms1q+05vwbzdYwrZSG7NpqNm2Eyn7xETYuoK57hOmQPSdl3Vsju+dYP960XggtDe+iCdO W6SlhZb7vA67IsdyicNeNcSXKyuyw+71VpQPqRrisBcUsPLf3bx5y/LfvZf6FteKRm92YmJFJpN6 Hn4xNT3Vuu8hGB2205/se+jzuik3pPB7CTrgj4B29lIdMPgUkF8AHKhkqqZez25F8IcAqqcDuqZL FJzm2v0GVaLErMJe2QScUdaiWSQihsWImBRFMWA8iFOiAwyWk0XNeM5lwR5qa8609IIoSEs06pCV yiF5VRVCQerTR39zI2Vlp8TYltHpvDfX8jWsgIRkxgiyaa02fa9/X/BA6C3xdf9x//HA8aBhVGhU 1qjsqYHHxAf9O8XtWQY5GCFFclVwrDjKPyowKmjI8+cF8oKCt0CcKq73Px56POvx7J1ZO7MNTpJt z45kD85elr06e0v2e9mGbL4uXrcnkc3sZls2JzXGqU0DAXFbO9aIdLMnuxg127jbNBY2l5qZma+d ebtLUk94vVC2KQmGbSfsy1kg5/wCntFXsKZmPGcPffFFp3DAxFsW1Tic1dRREW/hRniSne7pdFTz MXTa9Eyz2qtFg71aMjiQO6ozdvDmPTIbNaVJM6mhQIiFXJRbq/Ai/G9p5pTRMKnpCAlBFctCyk6f HDp0aDNd1AJ6cUSHOKtAG5WJghiIJX9IXkU5tHiQjSgrovlcob3jy5/Hh81ubppnSH0WoIbXPjh7 6fiK1NeXeqmU+u4Bqv5hT+1VV147e8GtWZ+99cUL13XNrDvTCOGIkvHYKyGs0gDygVa+zvOmh92a tSmLbReek3a49wkHpX3u3/s/DBi8bnqP9x4fi8J5KFKfyxsNW+xmYzfN08wTLVSzbMbBY6Hebso0 W9hV6mIujl7X9pBEgfK9dtAV6A/rVI7b4vZCS9LcgzUwe+0nVoU3h7eFd4ePhqXwSeXExDyaF4x7 T/iW0xMkUHx+LXoziwHe1NLrqC5t6V8Qviq8uqiXcmSCaeko5VgFUoE+0uLK1/eWjj2lynsBjSNY BXYiuKoXFxLLzRtP7ZbFk65avviKIQ3hxTc3jRs7x5TqC93wyi3Hbp/7zsqtqU9++3rqW7omOu/G 1W0LbvN8LMy/6rKmWa0D12y7evWP1r90U+jwmpdSpz/GfgJyxXrg1QjJ9SOt2hyxVKvmgDlunmy+ 3vwXs9xrobLoFfPFIstYy9WWHZb9ltcsKmUGYpYtimQ0WRRiNlss3fQFLSiIbgFMlJlFi2BhopEo mqXHchyVQ7QIQjKjL+4joggAgtCJF6XNRoqVYZrTjrCQo4qgBG21bBVjLGA9SC+nY/VdfWoRjv/x 2Nt8Y9dCIOhrqeEodFbrOHRW84NdzBzp50m3xHyJebz5bfOHZolkiBbojUPKqqQVDpzrDuqgbGXf s+y2L/ftS51O7aaFXws/PXftN6kPWA79V8oEirsaFFcpbQdfsGsDDNaIuco52jku8IjlJ9atzt9b VafD5Yw6Ys41TrAjajECC06Ho5t1aF6rxW21WpxGN/cdaFRopFvA8H5AXvt16gpZcKRO0yxhY6mR GTkhGrcjhqBHM7m9iYi7zK25BXc33aW5IXzZS+2s1F5rn2gX7Lypnfflstmsos0Ocjzuo5qP+oJh azeNak7Lcnr4OKEavCC7wV7AKw7QS/vZJHj9mVPg+S28wNmlXecWuBHXmQe/tCwCjjlqrUCtfsjq 9KrT6g8ItdAFvCpDKsoJKBRnRd7V1G9eNr5pxS0zbmk9tYV92vf3gdfOPETF+ZtTv0wTekv29IWb t6xbd32UfZf6979LU6c/2Hvvy78HLV4FjBeDFn3Qio5owxeYlhrWGbYGdkg7DM9Zd7oOWPc5jrh6 HMdcFo80xFFvX+Hdy35rP+5WDpFjABep4nfaQxEwLY7CHKAotN1mCUdLowwI8Sai22tVqqnH1bQq IBRnYtduSrEqUS03LJZi1/M24naPhO28POfERDM1B/P9J5yBvAtbO3NOnskw2TMtQGD/ickJku9o vpdBalQq0DkgsAJpCFsWBygBL6Rufnhm2KNoS502ThnVfKt9/uPJ71Jnj/0p9Rda/Pcdf+h7cuWk CfPapkxqEyfnTGns6LstdebdP6dO02a6gd5PZx069/mGB1ds2rxmFaj0KuxfP6jURNYeQFjtSW2w zZEwmoKmYeJQ41hpqmmn6eemt00fmIxREzUJCgmbSk2s1FRrmmgSTHzGpoNcHKLP72eMigoCWrA1 u0oVCq2mVbOyiQIVghaoNOZ+LEAaX1SD/QiZhovgvTrp8Pnrc49DRvLIjPmiTmfVVcJLy7++g6b+ R+l9TXySSr9amros5XqZlrGb/w2anJz+RPRhvf3QgcuoZW+ZITucKOhOn9V+hMLrjtdd70vvK+JS +zL3artQQIrNQ8hw8xhyuflG8ToDpCLP8sJ1hVstD/uftjznfy64PWdH4faBz5UdCO7P8S13rXWt da8rFLdiHbcCU1mDHkYprvJyvjCIT7120MRBbNBBhJ5mgWDsXn+iLas9i3Vk0aws2VnEqUhFs7Ii rYgVwcetWZyW2tyJuSyXQ+fyO0FZCp9Ql8dPTLRRW7A8cEJYnn/CGxh8gWQunAa6eNVS29cSt+vn QLy3Ja6jjaNOp53+k4AsaonHaUFBZQLkox+fnO+LsdxCfst1EQkJF5Xp2Buu+/id33y6oHXFqlTf +2+seWLZgekTG1unT5jUGlzefNXiJc1zZwu+QU+2Pv3ee0/P2VY8+PCtv0zNv+3E8tfppCnXTp8y cXpr3yVL7rx92dzb7+XSaR1Wx92/G49rTcMdDY7ZphVQup+TnjNst2537SUHhL3WbseLrlfJW44e lyPhmmpqtkx3XOFqdckBabn3Ed+H9o/c0jwXlFu+OcOhUmxOjjtsTMkejWBjciTbcSe6vUylE9WP 1NP9m7MjszkvOpFDaIb9afGfmOikzmB+Zp+aL9qf55Gtn7n/bX/q7AsI7udgVeBXrDKBrck3aCy3 gOqSi0fHawu1G6eMvmqFY8G2n31H1bc/ojmp9756/l127e1XTJiL/bmQTs6Z3Nhx7lZqeu8j6kjt SC1N3Zh6fL+Qtf6hW+++d007sPgmhJe/wG/HrQWDtJAwlMryUNGo7oa6LBfQiFQmMWm34e1duobH zQI1X0MOr4W2wLUNivQm1xfggrfw/Nw/z+se08kO8XKIxjK5VrPLElUknzRdEmjE6kgwHodmQqEK 5hImVgnddKOmylUYhiyLqK3WTJp0Z4TRgDIe6hy3SwQD43uDfl2FxgD6MAAcmXHasigfLnwHpeLl 51xCb98odmQH3fsP2pX6K3Q4HgIB39R2cbyYxkjmaHYboyp88Y1MkPlIJD4SCx8JHL3vy4JQBeF+ o2akVRB62Z0RSeaDsRJREHTR9sJ4WrguPx76ezDQS/y1wYtHVIXhOKhnOvt530jh79vh0nejHkiN Pw2MLwBHXCu9yW0m5C6tWLZbXQnJbncmhvmHBTTpSs+c4C5FVr0uogXCCa6uMTItZ2iWrZvd32l/ FAfyEi3XRbOMWRSfBkA+sqtRuzfiZd5g1Ba126k9EHkmg7MWXXPCFUaIXq6UQ0DpO3PK3vdJSxzi ST8GY3zb/odULOpSsSxgedlXaXrF1/78uxZevyWUSplo6JN/0Jz5zzfH+6Aqrqgy39bxRnjw8CuW rrg90vVt37Mt2zdfNi3l1MmAkUtSk5TXpHf1KImfaHVqSMmXq3353mrveDngr7qE+etHxPLG5hcR R5m/jsTyGqQZwzeTihkW2nBHVMmTiTF+jafujmDQYywbS8cepEl4cq/X/GUzHCO4+MJosHHEHdkz q2aogYkLdJX4DKQGrnBAKkMBAi5OAXtvbS0nW/uZXvAz/M+IaNDM+xFBW/IroAhEI3kMWy0vWi7q doJobkEhNiFQVAVu56uKCrK++6qGOLEvoxDGYdgQK8rz9KOTKxf9x6cs/8/vZh3rTe1K7UtFvoCv 89d0wDm6/tgTr6Z+NXmKddmj2/+wuuPbziuhZWy1+uxll89ZmXo89VLqf1Lrjv6O3nH2K9p0rmzu 5dXlBfmV4+c3Tv3xZa5f3rT6I9oF+2+AfvzPX6S2vpf+dercsKGLP/75317+cv3Cvop6dyAw7HJK NnxNGz5MLfzgndT2bWtYZNXNWe74JV/MXnTLmq855+QWwqOIElKIkdYdIEr6hKZWVSfkIlwU/VAp qkzIGi6ondAao4V4hgusv5B/ioyl5qGkSqo1LyAL2GxhjjTPMNf4mWC7TIbYrVLBqKqiolIaIYob 3nVZFUVsI7ckyQajFsweYeRdmILZCWM+EwRZ5FHHmlVWmCQijMhgho0OWuYMxMPiHVjhdirQbpan qWGVlqntKlMPsjwiooUagQ4eMF17XUa7Ht8XgMRzpmWRv2/C6Nn1n2DhQfO1NeP5kpdC44zrRrZ1 t+tGNmSKvaZm3S9+kZHKX1QTqiVB4lyHbEiaENiWA3fQASKkU50G0XgwnQKmzu2RReiTGY0yo49G owL+0ahLEKSjqZ+39+27JfUaG06ri996jY5PdUkHz21kkb6TMCTAA06kmcC8i0RgRT+h1S4vpvOs Nxd/In4timrUo8pFA6P5XmfYM9HDyjy7Pczjccdy850uQ8SdD3dJqLBNbkcISENR4W5IC8Akvs9K gCfcDWvRIG1Q46DWQW2D2gdtGdQxyBAZVAbxwZ0bIRFXGRTJbrapq2Tw5POmiD6wr5ZFX8e5kN2C 0x/MnSf98NcVck+6vTO72oNOOoM8a9/j4jp4Mxqdlycv4MrGAwONEWjaXFGMludgX8i6QgiblyxF oeaXZ/ZGYUEMbKW/UhB7iF32wq510xZOX7ul5clll6U+Tllo0cs/K778qobLBv5mJ3V2xEdO1m55 SzqYfc0j0+c+Hy88vGrWkUUWAxNfS/1MUq+6tP5KVeo7kLpZNbdMGHlNMef4M9KfStfCfhgk72kT 1qob3Bu82+DceV19V3jX9C9BzVeLzEWWAe4B3qXSUnWtZFBcis/n8vkGsGIhX1KKpEekreqbwqsm qZZOBI+5wk7oSQQfMN0O4vDDDgLUG0Ev8LNrPn+JaLBqVmfC2jDdRrmopXn8CdhIirRcZ4lRsH1l nUq+IvqrgmUQ3zyFHQq1KWGlDFolVq8rtLJ/XbAaE+yQ3DkPg5hwBmaSU3Ge8wJEWAjv3JQhyWIs woWCaMTn9WXEedi+IL2LtTQ8MvX2l6k/ptbTFTRBLc/OKk/9IfjMsp/+8o2OZTtZ6OrTn9PNiMa6 kT647drkmMWrv0h9m/riSxAnQ2wekWaAQu04d1ZpFUXY7pf6ZouzzVKxr9o31tvsneeVqn1DQutC j0gPmaSwg5Oly5lvsxsChbu5WJ6hST4rzdUepZFoGcQohxNUaC+zM2iFm7oi/5UKL5Agn+Ui2Luj MCvo5lqQEFS3DBGNgEBUUAAqeoBl72+9o7u1pGrO+LtmPt33Di368LaqsdNran40ecRe6WBWwcup T3+9966O6xqKw+LL5yqtzqmv7ty5b47TymnkQZzDpzFTE9miXWKQoFrky86wRMuk3RB5JFUQ82EE NKr5JoLYjgaBjYUHjZqCEUuZRYPJQFQjYHFlnCQwI/PFM9IXEDpIja68/ue2krCfsqsheLRjW/Hs +20lSOBIuh3WA6VVTw+Ktec+Zyf7IkKFdPBs6tA3qUXfYPRbMfrVGL1KFmu1GL0s5SsRQ5nhqOEj g1hq2IJwfwPJTEHF+GvxJQuTrxBg4mDBiKnMxEw/HL/xv42/hevenCeAfcJa11fzv8a3FRLXcDar 73E+tmfO9t3HMTsTu+8Idl8EHG7M0JyGnKnKMsMy8xrDavMa3+qQKvvkkNPnDBU5ivxFwaIcw1jT 1eIUdZppgXiruMK/JLjPus/+uuU1+/v2T+1WIUuO8N2mhYPVEHgIVoV6s0pk1ck3nLNhoou6+G5z 8d1W7C2xIeaMRgLTcbvQOZWFIxEBU84tg1YUKOwwUpsxbCwzCka+66Irt2W4Yf+u484vSAjctFCK ufPdh83HzWQ1fYvi3FzZvwFpJcy2UHnyQIwwKVZEoCjqKrXH7uTm50qhlq1sSW3b+0lq5/M9B+75 LeS/ioGp34d3tb/88WeHWw6NYqFv+rqnbXiJzn3nYzpr+riP36r60e1f/yP1Xeq7cYmDmCc/K4p1 +vyplq+KklFgqjFfdO6GwgsxmXummGIwgDolQ0Q+pivEm7RczdJoabUIbZZ2C+Ok2gELl2hhpgyx 9uAQypDr0h8eA4u/hnFaN03rRyYufM31Y0DQ6VXIHAM8+w96PU+ykBUz/x6iRayeFqVO9B2WDvYd ZXXfjmF39K3CnO4GebyIOQlk4QGCfdBVnuASeE9XLF/PtVq3L0EkTWqU2qWTkhSWWqU26bQktktg wkwgBiZ8QAlJkpNE6OH8mO/A46iJ5EZx8PnFXNw/lVrdC7UIvrk4d23cTYukg9+OwThi6U+FtzEO J5mm5c037LCwKeocdb5lvn2+Y4V9g10xjjXdYSuBFIPt7YxQBpxpzjY3LXNTt+mrMOyCAVdfPwrH 9463L1r09fk+IWBniIRGHTA4ceGxMN/r0w0rbDstjMT/cuCDLyj1SZGymdddAfGgdd/M9sf++bfI ysTERZ0Y3SNY+Vf4ytP7tKBBpk6n0SgJTBBxlKqINDNKqkE1wg6yX4srshveT4GLWEaIWEajCpHK KKgCfFWyAokKaCMmk0ExwFU3q1Maa0CmORWdjbELdHGeifVLUnwuAc7F/JljKCNHgSgCoAqc/b5q ggTrm1+3bOoFA3deGuw1hl8I/FqTkar2qhGTJQGqeavTUAjpiotXZFSTFiiQC9Ut4sNyB9wkPaKy Wn5W/Ez8WoI0mD7ZVXVFAnmPlodCvnyJcYmwVnhEeER91LhTOCi8KRhfQvjvOaNwiXGkwBbDHkHj i1r4NxoHiJz+rMtpqkX0/2cwPppqxTKLFxezu1aMmJy1GMnxLlsgk1t9mRwt9PtopOf97Tqtrtr+ zzEyMf8Qbjgd0SjFf8XxCOh8Kr237wQbk7ojdQMOk76lbFPfq+fuYMl/pUZjJZ8Al35GeoFI5BIt 2KhwGhYhXxCDKAXhg7z4AJEHH/h+R06wpzjrxSpkSJj3GvU8gf5OSi98N+4bzmXBamHEOEjMzK+Z TEKBocAE2zbFBNo1NWtYwhgZNpxj8WRXf649nTUId3GRQUN/Vb80QuY0Gl0sS7SrYWOMDRQjailc rfPE2eoC43J2s/i0utO4Vz1o/Fr91ujdJm5RtxlfU980vs9OiO+pHxg/ZZ+JH6tfGC3L1ZuNd7G7 xbvUu41bmNJkms0WiHPVecZl7BZRqWcNYr3aYLzKcJXaZFT8xlJrgg0TE+pwY61V4eZ4WVWNHhYU farSbyIPA1FGVTIrSrlsNZdDeLbDHd1osCRM/KLP0grKMmjWwoSJX3Drcc3OCyaDwA06TDHCpg8d oBaM29fvPWqh0ITfhULgq4YVdrhWgl4iokFVyzPOAXzeYywXGPwEDK8RzCJjZmwqVTGErRSWa0sX j/M8CF8qZ19Xt2TYlm/ylIRUrmjKKgM1HFmFVThiipjMYBtDNSf4lYaGREMjUh7mYjteYxkM9mE/ AwNt3F7zdzvMCPa+RX2LaoJ+GLvjuGE/tQiD51p7bU1ms8W/11z6tRTXZFC8IX1yjynCVRIIhvjp /A7fnCzixApKzVCs4z56CFqoQg+nelMfwjjyJ3Aev/DZt2PEO79byRNo6mFwnhhoSqW/1qyqIBsC gs8gOsF1gV3C9xVyfdo814oxI6FcMYAFGQQDY4qgAl/AlSDyGYt8xmK5fEz3lG7SApqp0dRqEtpM 7SbWYeoxsYwkYuB7neNS3/PWyZMTarkuWp0/rYwcVxn/KVfioLZgkvqBhZouonB9BDypunrdIK6V AVEZOuLq20lNBVUYIhka6dkPLc+g6aoeV2YGl+ErLbRq32eqNLSbKvWJXRIclDBMxkUSvEK5oAni GGENhKoOQ6fhlCD/Qjhm+L0BLvlSQ0IYbpho+LGwzdAh7DYkhaMGU0aFrkCwgYYLajAwlZYnWIRf FHcl7mzV1OigBJuCi956TE4ENVwMTFH8TPApA1mhMpxVKBOYplzDpiqqm4WU8Wy08qiyS/kl/l7D Z+xT5d/MVMiKlMuUm5X1yvNMhjFsMT/sMj94yDOk0Ex0SuA8hDoephHWRF2p9/v2gABKhHe+HSMc PlfPZf9myG2fQm6zwTb1lHblVmmr4WHzw1bRQBWrwab4C/03q8udynLHzZ614gbDBvNa6xrnBvd6 z3rfev/aoFlxghKCHmfQHfR7goqrxKIGShTBW7jbSInRboxkpC4tUpatZbdmt2W3Z3dky5Hs09ks 217YQSg3dvHYBi6aZa185YJopuup3BnUb3kEoS+ClgmTDOwtFf1qEEGg0QXnRfOo8p/N3dCF0PI1 qZWpI6kDqZV08Cd79vz1w/37T7J3Tz7c1hkfBmPoo6knUguhDM37dyqdTp87i5gPpmsGZ7ELOB6W a/mydMB9wC9cKtG50nsSczryLVYrCdm5emAjBkzvP7Qebzi7rH9+UrbddjGXz7pYzIbYoGvfOgXr QjZE7H7dB1sXih23rnPNJxaAi1W3LEHveZD+gVqvWLlz5tYJC9586andy0ZdO7ayQzrojX64e133 fIen733x5VTroJl1jfMs+NssuiQJSQxxflFyVruz2jbOdpWywLTAzCM5OmL7rCdUo2yQjT6D1zjE OsY6BgFXdtXhtrptbvsQ6xDbpbal1lvs7xhNN6s3B5Zlr1fXB9Zmw0TpVhGBNdm61Lra+oD1p1bJ GrGY3RaL2Wb2WHzefJfdTVvdHW7mdpNIlKMLiPMQA9joYa2QWOxwdb8bKuyQk3KPfBw++HVtMRqJ lcVYLOq5GGu5gy+SS7jNoqXfYqEzx+/VE50LgAO0XOQT1GUxuK+B0HIdnzBK+FxRYRCLxRwwSpzH KgwRC//2u/aXX2q9fUFX6ifvLZ5y7ZyaP/xuQc3EsXkvfiodnPjWnc+8nzV07S54wWp3NUf7Hhcm 5DWNvOxquHDBOS+DN+If2DsD6XHtkgOO7ux9Ra8NFGFW8MCs4PHHZ0uzi5bIN1uWFH1gfi9mbjZe ab0ytzk2zzzHOTc6v2juwOXZa7MfipqdMX5i54QTPNdmB4KJSbmTYi/lvhQTF+Uuit2Re0fsz7l/ jslxY7ElLzcvVm1JxBqMDZb63FGxBZbZsVssK3I3WDbmbjfusDyb64K4aJFz5VjAGLB4c5XcmNGC qIOpfi0QSSz004X+bYjGOchmI16iRzNDwQrRUIlbIGMp5+/jgpEEdxA3Iuh7C+1ApGAPPiD5u6gF q+2I0ikpVv1fpeHT1Vy+hK9BKSwIDgoXdtiT0PIb6FeOjHYcKPltv2kDX2fvIdrQZt3eBPss8vhi buRYFD/TEj+VyRfHT+G0y7AuXaDLBT5C2SOAj+P9+V87XdW5QA8y3H2z08lrxzWbs9oScVYb9WTj 9z7TrGbcs1Qb/Tzp1qvz3BGsv1/U8AwzDrNU5lYCj+Mso3LHxLYbn8s16n75jBniQthDIcwOupPr e4VPgTnY5xV1yuIWmctoJLht3eb7Lrk8ceDvretWffUcbP8+JXXCdfvtd4wrHTiUJo8tvTtNjqa+ SL1HP8y6b/0tkxLjQs5Bw6fe8kLbK3P+8ZZl0XWVudWJ/NI5NxzZtPKP11PID/iqBJLkAexhBfp+ rFQtE8ukRrUN1tAtqiJTieUjrEEhBhXGU3EVP29piWaUFdhP8cEfpHtUHYK1EV/1tbMtTGQBQ9/z Gf6KcJk9DKvCfabgP7jAdnqqnydxawRtwcFRya0R9KPUePGe1ATx5bNnv+N/gul+nBh5GFWAbNSG KgZFVexgIuqlhktV5Sp1qv0h+1bHw57HvDvs+73vez6Wv5ZNiL2EUqXku1SzKWI5xoUq6Fa5WqiR B1e2hdpDLBIqC3WEekJiiEK/iwTKAj0BIcDV1uBFgoBuvbygtvbqtl4+2EXw92NJuL41pBJnnt3K oILxdbufFplcm29b2R6kRWV3nHjhtx+sdGfjEPzkyNBpN8x96AUhfi6VOvv7h5pnPHblSljKaToN eWgK5idTaxd80AZus3FWC1zEnhIclugxvIcPOz8QP5AkLujeLG2lD7FHxIelbQaDgGDuUgMXplsN y6kSIF55ACmQx5FL5auwinCvRShxY3EzyptuHxe62UzNJEOjh94GdikdZDP436LipG0S6SqxXfxI PImosm5q0oyr8Fe4PhJOQujHXt2LFhA7D1IT/uoILONlFH9eQbnIMo4d1nKmpSXu55bejFTZy8Mn vpcpv5eYerrsujzdsxdi0hQI03C0cbM4D6LCd4NxRK1ldCBm6jtD6/BJ51w6rO+f0sHvXhEvgYIN ylBg+d8EzJlpWnPGhbgcMVWYRCDSpAFx0M7au5BzTJ7POwOVkP8+1VTuGQjgAut2pkZ4TXfUNSOC T4zgokBhkM1B4lEHkHxV+dz4qfkb9d/Gb8zS69KbxtfNvyfvQj95z/wF+VhVd4k/lXYZnzEfEruk Q8a95jdEdZCYK5UaI+bHxPulx4wPmg2Zyb9ooFYLBtfTZY3ywcG/jgLUiygf8uNdGc3jcc3D9ZBZ vGaSYW5SoGzAyqbvmYt0Df04Cr34skmUIt3psi4ZqkZ3uly7RiDmyEUUYIQxp9xkdCOUWZUVmPFU t8GgiiazuV8pQSeCGaY70SwgogkRsLJBUaR+ItHVExyq2Pml0D66aZlmjMhHTEe0Uq4NomqOZBxl Act5eoAvta8FztS+YKCvxX/eWZKhCn7l//TRQ6LOuMiIg+v74y+mFx6p/D31gK9yEtEVkH75k2eL OKm4QC0unWTo7NRTtPRDasaJQv9Mi+Hyeg2G6g+xCx3CV+dgxoE+Mva7blCQFxzvCChIpXO4j+r0 Xlu1wqizn2mbGdgelaFpmIz8rOqKFCaQn9RCIFkqKLKGG3IEFewvIV8Ex+EL1FvbB00hHtcvmKGP uwKrQwiO5YinDBuSycUSg5IOy0k3K9Ag4Sn5WFwZppM2leoqSr5qTqjBfm3GJJZBQWgUWtHPFboI y0jAeK6fu+pclVtS4rCv9ZuD7Z9wm6r9/PbrV0EoJhGK8En0aDHucmt3VGp0rNxIZ9GFchtdJbfj b7JEokUJRUM7uNC3dzoqTbx5pT2QmKC0KNex+cpidrtyj7KXHVJURHEqJSyi1LKyfj2iUdnI2o2b TWfZacWG7cxXiG/uOHRHmMgoZ/M06vEKrO9KcfC5D4WRiMnZf/aTczHYnNO9qevF29NRCOhBzYyv gllQQhjyJQl+jpyyf0JKeQyxgFe4xC2p6/ft47L0uPRn+EJ7BImRcrpIm6cEDVlStjd4WWhs1rj8 P9g/cqhDAmMCVxXMCcwtWFvw48D9we0IcH09+EbILMsWj1cOeAvlAZ7mwHK2lm2X98qvyeajiQ/s LDuvfLBjoCVPiw9K5Gm5RbgEshML887lsbwxeiBrmdWWuCSb8ijXZPa/s8Xs7IG0gmi4m3GqXxnV shy1US1kxwXB/1F41veKitliHMgJCs/0HI/1HC0Gct+75jblDC4wDFCLLM1h8zYzg0afhlKvWREF G5yYoIlWUO+9nAFXDIhO99GPfHSib7pvoU/wBSrm1/VrNYsh/SzqbcmQxiJeO8XNrzAHxGFzh5qr y0S64T2eofnO0my6qLn3PJvOS/fsD2UnpuTNymMt8Wa+iqBlwQpzLD+0F8EPt4gi2hwxOl4PInF8 US696PbIjL8f37fyIDAEfHAhBuelHhpLZ6fjvz12uLtBCOWnvjDZFWHs0y1PH5n62I9fvbxxYcMU eu2QL/KqmuovH11hN7G/DHr0geYN+1Pdd6+5PKsqYBgzpnP9tHsasvIjWZNGD0/91lnuL6wZPrW8 oCpvNqhhHajhAexpG74yeuIAPh85qw02VVeFLg0x51R5qnGqd6q/OesbRa4Uh1uGuypDo8UGS4Nr dOgB5RHVaLbCgEaCWIROSXHztXCZTDZi9EUNwbYcmmMfwIQCON0GgDrbSDv6C2TXZvCNiLDevppP JkDj4lpkDQ8F4KY1hNrQFpgjTXPkOcY53jn++VlSC/Rl3V4M1OH7Xh52U+hxQaS4oF0ivv7OzpdT qb4DV+/RnIlxt7TctXru7LWw/51+IPVp6t+I2Pz91c2Ps+JnJrZt27XvSZgBKbkSc6/FTgiQP2uT mmzNTrjSbPOd8723+28JbGVbza/ZX/O/b3/P/7n8ueFz1+ees7JrqGuo5zLnZd4x/mbzfLMyzFnl rfILy6XltnXSWtuGwLPOHd4Dzn1e1cop1h9K8Hyv052wVlj4nUBOQs8Rc2c5iO/+jcCZ02EiGpoS De1IxRbQ6UGIISIeRXwK5XdplJRaeMESnQgBLRhSou5AsCmDyvMxJfEzvXHuIoGHJOOfRJ5RXoHT fmeIHqdUJXGi475KkKI4OPU363UT59++6vrGOR7qjp95+/PU36i39+WP2Zflk6fct/PI41cvLP35 y7QA3+grNH8H5yJTgDvuleR0s0UrcTbLzcZmZ4ZaHgZpnFXVtpz2HDZMSJiHeRKBy4R682We+sAj qsrppFMycarRrCbFasNSGH0DrJYChFYO0Gw2EtzMaSdqCGQ31eibk8+Q2/M5xehnOqeWfj0StGKZ L883zndmqEVuaY5GK/snCPuDDzaWi0lFnJH6rm7PtP3w67zceScN9DlL61fMWL967qx1j1/dTAuh T1lp4AFmP9e28/Ibn3l6/5PbMN86zLcQtOImWfSnB4gd+2SMqRr2b8tD9melHcZD6iFLd9BgcNOx 7FJ5jHFizrOWffK+4OvGN8zvGU+YzyrfWCxZtiyPBg7h0RDeZPMc9RzzCNyZ32XLqdVzmL893ewe DUq8s9HaamVWv5MfP/sCoQStcOou7uxIxtWdOyCTx0syuT9LzzUb2GkHUAqHMSPTnU6guUs0Of0c 3XkmhURpqSdDRKU503MW5mzLEXNsUYNmsSWA8H5uGP+Bz7sXap/m9mtF7lq/lmPDBSzYz3k1WFy8 ubZPVwudmAhaOPmE0EjP0Y7nneebIhSEg+h/4wd/UaAHsjufVCfcF93pZJdqHKFX66K1MJfi1ac4 B+VOL81t1YAlK+/UyruHc9+X8QU064EksLJBQKrQ9Q1wC7jj5VgEKgancSJEde3DxR2Ciuxj31L/ kM93p/62Zj51v9NLnXKfJtw5Y+S0QuHmqdfU1FB6RemjT+6970PQQjz1eurI7ZvG0h+tWDVq1E2c b/ixAT6BZcFLujV492mxGLFHHM1iu18yiEf9zON1MLfT67C68F2nFaGMduZWDTYTnW5Kw83LF8Io U4fNS9NefFeAao4d7z2NV8sut1GtqIUBsxH22yJ7qWO6gzm6qYiIOFcBc08nHd4eBJZxmoDI4w34 bj7A5meCtONgqfwLwXMtUBkDpxACV1PLfcRIiCFdVF3OP2DrP4dcsIPyg8in8APH4+ER7ghN9z9e /cjSm28qGDXiksrf/jb16eNiQePa1ZPzfmGvntTw4bn9Aj67xN5PTRJbdQmilE7QZi7PXpfNnGZL 2+C1lvbBYoTCWiSU0QpWIWh0FBslXG1rdjfnTx0wNd5cer3trOOsyzncUuEdXlQxEGYSb0NR/cDT 5j6f8V6c2SazxVRsthRavT5PicUMRd6fx3fAXn0H6BvA6tCJpMtkzuRFxZkNAI+l/nxwIrMRVE9I P/in46OgJZ1hWyHPrMYSjnCTR/EH5OIBpoKgnzMdNRAIBjcPpoPBgro1I6nIizoDZRe4Dw9e4/wH UWt9uiLOD6u+M/2W3fPnP+i5Cxtbp2Asjk6+VHfNcZGWJ1jxzh9xi3S+ZZvvnp8/d8Cc+PxS8C3S 4pN0v6R+7leCR/cTsA/ObTe05gii3i4O572F1hmyi6beWJXvsqzsee/2mZQefbWdKiPaDm1O/eMv 5+5qnXvv+nmz7xpTONSTE/UOjl372PN7N/+OmmjwZw+eu/TwwQU1B+61sruee+LJnzzT8QQI8MeQ 8ZvB172kU4vbaBh/bgcLaR9JRzr+RP9NVUXySnmsyTHPIUEwd7kdTpfgZhShkEu0bAHOUKPbY4Si YDIWGFQtkpfYrdI0hHSgGWKxNzcvscXf4Wdt/tN+9pUf37m6C7yc9Wk2tO3w0NMe6gn4ajNsH8Zy 7nGDRIbS1/21jE4HH0wvcOrTxSuDbhNBHI4DJI04J5AyAlJA2DIv0l3rj8x4fGJ26tPIpEvG3FiR gu2w7+NtY9vWb+67jw3eMa2yfsPavi8xadD2/diIz6PIo2+XHyAqRlbrMNZqaqPK2tWk2oOPAb5S pbDaqq5SO3BDEmQFH/IKOMU03e8tkBbIRLKE75eMTMGZyWenRvMSYsDQPy99VplzTN+eehCH7rSH kLiYB8TrYbz48I+H8Yr7qJg6991lYsF3+OYh/VRqEt2uj9BDNmnjvUqBEvENUfYZpHYf/pyKhI8q 8P2SXf3PEYkeeTpCUe9VbdRdwOywSAU3czmY+iwVduy8AKywB9n1JMoW7AH6de9OYPwpP8f++VCE 3hY9+gQcBdTsqPjBuPmoPQ5Yx7l0VnXe2nMPDVRuXVo8Y+hgd8wWr3JmJrPlu+9+ueNam+20KOUn 7hTwR8gQIgnKm455mcg/uffnwy6LQ/dtabcHShIKnI0u+KfnyLuNR41vqL80/t5onAwNj1kUvzpG vsqwTJb2qR+JveI58V+yNEGZYJgj3y7eLT4mPi49Kj+qPGowhkWnHBfjUrFcrBQbSi0NYoNkhKyd 8eDDTy+LJsTt8A+2uX8evhGjCT76G7SgVGqoDsOnMBvu+QLaTnicL75vqL21X3XQvfP4ysGPEDGu qWNtceW44n5C7oc/733nU3ujU432hzVy5yBZDE0BxvALXuwNCCcdR6elHoSr5Depf90FVfxruix1 W9+19MMNqefR9fdUOlmP2tAGcBpFjAZrl5L4u1THpa8yoRqrpA7cQGAKCNoIWZxy5qRTI/TE/0WN +uGwWB8LaK8/MmMlvNoPg9sX0uEHyABAt6AvnK5mj+w1J4SEIeFPxOrZaMNof33MDA/cgMlq64D2 AdsGPC3vULab98p7zckBxwecHGAlA0oHNOLB0QEfDZAHaMGsRC3q7fpDSYmKSjCbH4edRoVrflqO qOAT8sJQVlZBIfxVss1e4HRo0ypbHXQhNkg3G6PZgqGC7CzcW5hFWxHFh3sv5sO0yCXJTvyFBMy2 y6bW8lwbgnEXommhVodUg5RXmCjUhl2SKC08VvhRoWArDBe2FwqkMFJYVpguFAsDRX/NMKJ+tx0k kswZUIOo1jiO2q+hsCM7z5L40nPJFExf/7YH+FwMewsYUxzfGoM3eX269odP87DcicILLOp7brWS Cpt65jxUNuapa5Y+VQSelV04afi8QalPc2qH1M0rSX0qFtz33JQrr5wy/Zr6h/ua2fSfDKoZu+mh FGNjHps2cMzqR/rOgT4QiSA2Y828ZJvmV1w+1zTDPISbiBSrZa831Ns+tyOMnrNshwLzmtlk+n8a uxbgKK4r26+7p3v6N5+eT8+MhKQZSaMfskQ0Qh9jqw1YSPwk8x+7FGQC2DIGW7K1Jo4TSJY1Brwm 8QZQsFlINgksSdlYEkZyslXs2hVMvKk4dkhsQiWqLVI4VCjLKVvItai1572WQHE+tYOmPzNTXbzX 7913zz3n3oYLzpN0lGMmG5EFXORvmWxVS+sgjMr6wSvRfmWWWyej1Ib8meWmq+VfGm93Ykx770i2 vdV4KCpcAy5mnStF9zS0Pl4BA+jZ927H4bZ8Pu+Hm+rbd/U7+WL6xcEFD+76ErXXK+CXH0ZLDaC4 Q3bLB+SK93roekQ8x38AYjDuiSt8NrAmtCaajR3i+6Q+7yF9SLnA/8ZzSbmgg1yVPjACx71v8f8t ve79ie7p9e6RdnkFjC2MQs2iXRQW5XCDnOjMeRSZKL4kQp8zYJcLXl0wQoErXdWVrsBmYJGumEg6 sKRDNZkx0SzYZZqJmS5mEMxF+iv2Trz4Eck45//4vHN9Lyk4uG3bgQPbth3kU88Saa9z7sOPnNd3 TZ741xMnjr144gRt7z7nYfEQ2hsA7jps31YfagnxZkZoMBpCmZyFQqvRGlqY82mOQrH7NB4bkz/N QZ1jaSZOj2oa6mRN4/Rgmc/nTwcCDIBpn0Xqy66xqgjI//sMVmeJa9SPoVh9Bv6ieuMIHekUYtLl gEKw6E2wvo9INS89NEx458bwuv1tuMXR5zZv+NrTX3jgGdza9o3Ob50JZ8x5v3n1xB+E4YEfHBk4 /h2Kwe5D2zeg7UHUQzli15nz+IyRCc/LXcwvNBaGF+d6H80ns7wRK5P1ZNW1xppQ1kIy/Kzvq9/P HVfGjOthPcj5cuitFTXALBqskP0BKQagmWeWAXGng0EWrFD2Y6FM5LvuH81zn24/8hjoXKfeH3M5 KkB6E+bIebrUzaEuqyu+eRYcORKky2BJ2kXY1HubmSYktNZ9d/3p3r1EOPvQC/OI4Iz+08bNe3bd f//zzsN8dNHKZ46SAMEac+99RyAFGPy3o9859fILL9E1cjfHIR2G3v0TdukhD1F8ZKVns6fXI1SZ 63wP+h41kSjkR2kTfr8+qfNNehsSkYf4J+wyWcYMF3hJLeWUgFINokpUEjvMoya/3txhvmy+bYpm gEvT8HSZrfH8TpCLyPUJNg2TXBdeAF3cnNBjHfAMGMBAZ8A4NqAqGx0M3ShAa0GnX8u055+rx/DH BHfHggs1pCA5Ruf0gi0LO7NrF91x+4oqMX1oy8LaT26766TzEdpYjRkdQBvL+f+yz0pBqdBbYgWt wj6zL3yo5EC5Ioebw7z5I2PYdy75+8JxYywllRmrjU3GAe2QeTw1rMt3FdpFC9MPpDamd5u7w0+n /rFIqUvfLTVri402f3NyPljXopJ0nV6bpBxjbZEsqZ6gkowZJXoqlSqUi1L27Mf07eEvRv6hrLf8 mciu8sORA+WDqcFCYyfZbz0b+1b5v5efmi1ZyaidLMxE7VzU/46S3wHM1XiT7cX7i/liOzYrU5yg YUrbwrrTPptUzyZVs8nsvGQ1BlcNSTKsgrWJ7fETd2WmKph4xfYh6ljcwHrDYpJTDjDLC6ACkmvc VMy9lkbcSZSkU3OTzclVJGttJF3WGFRFFi8mkim+NGTofGliPbjh5lKtPUESzSEZaBB/bqidhttB 7nbnDHOpybcGgKWSQ+4ebC1o7yJ6PjKQX4TkRezBftNzOwcHWwwyN9Wc6jO+mXoj9cuUlEzphigi U8RFa1wNxW0DVmUT9gzas/NUsRtQn4XVn2PJzu1E7ERKySgBbxNgzLbIfhmK4peE2MugHFsvjiLd Fk2I2gCC0RrLxnUtG/ECy66ty1g05mzZxWXY4Lp+K5+Fd0VrdcIG5PAnSHtiMsFPNZ6R2+jbigqq 40d+CoT8DMrRaAPtDPbdFL/GdePV4epuiybP2wqkiP5SbJJDk3981WjQw3oDPezXKb999RWtgQkU IU/M3swapPUNEOnFoAPqpl4AC8ZNEdU0T5/6zNUkYW77wta64nCk1fnhfV+5+PuLvyx1rgfXr3uk uiA3Tf4zu+7jD9+fIFUVK1aX5lYVRMLBJXeu+dbeHz+3b86d8/OjhXmR3M2Llzz9/DunMIvyJz/g v+E5glXxZ3ZZAQdQrpb5G32LfVm/HI9wMSEa4SwzBCbcBMUSExRZlXVAYQJ6xTpmnbKETuzOIkKO 4EM/woKwlwNchFYuQtRO1yBLrEKNKbIeVoKGJ0pjQtoyV0eawkfDL4eFzvDO8NfDb4dHwx4uHAjT xHQRAcvtx6Zj7UtO1cFO3M7yecKTZynZTWMX4LoDH7PYBSwsVX4jxYJBjanYRQdBoCJMwUWdRTuN kshBFOGpLQ7yT57VSnJLFsc2PLX0yQZN+epXSUJMjzirvlaRm3OxvOaeu+ccID8fefe7zh70zz/D yqwU0/CQXrSttcEHggc9giLFpXn8vOASfknwCi8zTBsUtSinRsIIyyA2k45EQNyXgVhgfpIbwPk7 fpICfnrKQfKSUXCBf+4gzfSO3EXmJnBw/aMON5CJzF74i6zZLoMuLG/8j64tJ5eSeP6KppaechI/ unrD508e5I85sZFNt7f1XiZnARbRTg2e4L1oJ5IE7YinNFGVkelGohsv3YBTfW8AewZTC8AAHxaJ BMGmV9U1YHHeFBJKQk1xldo5DUUYJkftKCKQKufRwlxcQ/FjLcM1ars5xTVJgyoxdHYtTbEyyB5T CBIGkeVIESPLXga3Z2qcCpZQUUCpSzhWGmhM3I7llmY0I59lc4gG2NOA2qS2MYlata2JPBj3JhQW FiD2rIaLutP263jeRwHkMAKJ629gbEEhDVYdEukOuJ4dcUajsnPmoVP3HGmGiMMw6rwCCxaoc/pK ghG15iLqAk6UnHFWkZI3Gy3JF/gpSTrovYn/OX13tLKSz3P7VAEiqkef6nyJPQc9ixrqvCp7lBwu yueJQQiJw0qeGtR1RrMXag1Cg9QitEh9Qp/EeAF7++xF6EINlbFERVNFPYdLiFFPWImrEV0v5ErF Ek+lUqqW6HOQ1nenguJs/CJPi9yqPMFtF5/wQPSlPqHv5p4Rd3sg/VJ36+9z74sXPBfAsF8Aw35V vOy5DBXwZf1T7lNIuMflMVDxY3olKPt3bSWnMSOmsQFzepGdqfQMvrz7HUfPGOUeZ3qAs2ew12xs pm7xTUoeMJZR8hEcaECVt8h3iVa3o/h3mnynkKjhJvO+bIp5X2p/jjLvf49Nl1w2HQrlJoTDMSi8 eOwJrX8k8Vs5DW8bMhDfYAGJG28Mk4Trq1A2fYpMd7l0lnLKkAcdBPQf+w/RsBzLN6VkOsYBxgW1 3u6goJnM4GIRfB7UbKMBPTLeb1CpyTjMvmbr9JNRmH18Qnc4G+nHvcZuehGgQ4ul39HxFaJ/JIms 5axzigTPnSH+V94iEaSj/unMIMZYCz9E3/97kf/BxGrMXB0zt5PN3D57X6n8psj3ycPkErkgjxpI j0uIMQlVhbh6bwvKPDxFemU1TSrkuaRRbiaL5T5tXBqXlWIxLZerGbFRXSAuV18XvUvVVWJW3Shu VbeTL6vfFA/Kr6kXxEvqDdUQRBmhkCjK2ZSrNWKT2iwqEVRLalSXq1vU4+IZ8bw6JipQx44OmDFq L94bgK+N/Ygd0YMZIqKSHZVEYIfqhpBq45tXyyozk0wCP2L7o0UZIc1DN8srHkkDT86+HkUKF72G ha+1NOdBhqoH8gv4qtCAaxyCt1v7pRqFxmE076Y21IEbQa4XhDlb+/kaBNO32iaNnMMnpuo2kdt0 yxJ0s2SJOMSqU2kTrPAbi81QoU1F97Rawj3CkAAPQTfuQD+tFmBM0wa6AZvp4dHR3d2DsdHdU0PY fcUWahCyw/kGWfvjn5DFTh/Z4xx/7yJfyAvOJVLkKBO/IK3OGWqPfYidr8BdDZHMoFnqISHa9JgO 7iUKAkamG4luPFF8xlOrmA+bjHCLaGg+KcBzIUkMQYkvUJ1SqBOu5BB5GQbVb1T5SrmCSHWkMyLQ ICr1vVLpDIutmrl5mQjVoTUIdiyeoWr4IVJiKzw7g6yJnpmkgbNz52amNIJhak+ZOUUSL4wqtatu Ei/6rWdZ4GPEwa91VLnKJdhUtz4Rm1AyGG86kdxp1LHkVABLfSOW+n481ua1SdytydFXBFS4p1m7 jDryUGEg4n2hQCiOjRlrgqUaHcAJ3ffj3L1W1p1Esk8AuiqhiLLOB4ZmnBQ6exYUL1i7o/2e5fH5 tRs+H8eE8vF/usEPd2y4IxW8ZDyWpb2fAn76FXo/QJYNmudF1HKZnLTnBFD/hGAjE6/KXyfjKl+n LVIX6evwWKAu0sXvML2/E9/WPxRHdFGtEr8t/4h/HNIVlayyFQXSH1Klf5s5C/5AgFP3i0fhqhak b8PIIRWDiloT8NObAVef7u1i6uv7IUL2V/tt/w6/5E+g788CgfGm7K3hdupfp6ANw0LBNWTdomd4 DhNu+NRl2P4WYtCBGILbWSiSIgYK0zoqelCfAXgdajz6ycfzrlX0wB4HJj5BoS8K4z65TLrdUY7H /kCq6VNiGUhl1GrsVdlLq4swSQ5TEAHYwSh2s1vFwwNQtQYtoONtMGc3y9XUkrl1SG6iYhUU9klG UuS5DVVz2p09wjbnof29uWTgN+T8o5A/8X8458x+Qb6OuzF5g5wUH+GfQmgyedotrDfEf9lWXBXL v9DCAVMaFiTZUhGLKD5GTr7zDiIBu4QHhT2eN+HdWFw3MtVV2YyG/AhA1VtXkXWYhyIslFWu166y 4oCFksmh7GoRp/bwkOORNPeSESrSoz0+wzLSemf8gV/QYhqA+fOuQTczNkEXiGU4pOWjJsaudbAN XTHwB6SbZHINC6Fj4LgZx0ecKxWP31u3qhVFBC/guDfLjoUHz7sFBTeudK6c/9KztLbgxpU0mtMl ZIVuFvO2uK+AFHTbAQEIa4N8Vavn/ChcQs8qQleteqwJ+ox21M9sR32BXq1/CNgvAvHfPhD7Hgof ouLC/79RTNkOeUpdIQRHNwsjIjUh7jaE7HZKb1VJ9Lz20yef7S7oRUtI/OYh9Jm9whryPc+rKBwE GbZ4hFNYFegymAPaYvaaLOF+7R59ZrsM58ikxH3VoSygNXFDf7Uabj6XnFEJt2RGHdxK1L69Vfl2 Zt3bO7j5MyrdtrLqsUvxFODlXBuq0t/DrcDzQVahbv4aVEhax2Xx5ID7UIW+A88DGeROczDeGFAm 3vRFn1bCtS2cv7JlQcVdPV33P1w5/5GHNy5bha/+D1DEHfMKZW5kc3RyZWFtCmVuZG9iagozNDAg MCBvYmoKMjI2ODgKZW5kb2JqCjM0MSAwIG9iago8PCAvVHlwZSAvRm9udERlc2NyaXB0b3IgL0Fz Y2VudCA5MDUgL0NhcEhlaWdodCA3MTYgL0Rlc2NlbnQgLTIxMiAvRmxhZ3MgMzIKL0ZvbnRCQm94 IFstNjI4IC0zNzYgMjAwMCAxMDExXSAvRm9udE5hbWUgL09EQlNIQytBcmlhbC1Cb2xkTVQgL0l0 YWxpY0FuZ2xlCjAgL1N0ZW1WIDAgL0F2Z1dpZHRoIDQ3OSAvTGVhZGluZyAzMyAvTWF4V2lkdGgg MjAwMCAvWEhlaWdodCA1MTkgL0ZvbnRGaWxlMgozMzkgMCBSID4+CmVuZG9iagozNDIgMCBvYmoK WyAyNzggMCAwIDU1NiAwIDAgMCAwIDMzMyAzMzMgMCAwIDI3OCAzMzMgMjc4IDAgNTU2IDU1NiA1 NTYgNTU2IDU1NiA1NTYgNTU2CjU1NiA1NTYgNTU2IDMzMyAwIDU4NCAwIDU4NCA2MTEgOTc1IDcy MiA3MjIgNzIyIDcyMiA2NjcgNjExIDc3OCA3MjIgMjc4IDU1Ngo3MjIgNjExIDgzMyA3MjIgNzc4 IDY2NyAwIDcyMiA2NjcgNjExIDcyMiA2NjcgOTQ0IDAgMCA2MTEgMCAwIDAgMCA1NTYgMCA1NTYK NjExIDU1NiA2MTEgNTU2IDMzMyA2MTEgNjExIDI3OCAyNzggNTU2IDI3OCA4ODkgNjExIDYxMSA2 MTEgNjExIDM4OSA1NTYgMzMzCjYxMSA1NTYgNzc4IDU1NiA1NTYgNTAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAKMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMAowIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNTU2IDAgNTAwIDUwMCAw IDI3OCBdCmVuZG9iagoxNCAwIG9iago8PCAvVHlwZSAvRm9udCAvU3VidHlwZSAvVHJ1ZVR5cGUg L0Jhc2VGb250IC9PREJTSEMrQXJpYWwtQm9sZE1UIC9Gb250RGVzY3JpcHRvcgozNDEgMCBSIC9X aWR0aHMgMzQyIDAgUiAvRmlyc3RDaGFyIDMyIC9MYXN0Q2hhciAyMTMgL0VuY29kaW5nIC9NYWNS b21hbkVuY29kaW5nCj4+CmVuZG9iagozNDMgMCBvYmoKPDwgL0xlbmd0aCAzNDQgMCBSIC9MZW5n dGgxIDg2MzYgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBnVoLeFTVtV577zOPhCQz eRDyAM8JwySYSSSJQHhEMpOXj1QJEO0Map1A0oKipCaAogKiXHFQDIperVYiFqSCcnIGMeFRRqn9 rNWCtbXYa2u+FmtV+OS2WnspzNx/7xlArN+9370nrL3W3mv9e6299mPOPtp765IuyqBVJMg//+aO blKPfgqsaP7SXiNZz60gcsz9bvf3bk7Wi9YS2W763qLbv5usG7Bj31rQ1dGZrJPET16AhmSdTQQf t+Dm3tuSdf1zcOeixfNTeqMAdfvNHbel/NP7qBu3dNzclbQv2Qg+vntxT2+qvkjVb+1K2bMgUfav 3vxpPX/qtXr+PmgHiBisOP2V6ughskNy0wS6Go5O8lfJhrrU2/hDq1819t/gqvvCWehU3W/+U90Y KRzUuh8+efLUaTc5R8I2TdlLBXCOGfGrqNFNJ0+eXO5WLVJx9uED7asCmWIH7QTBMUoD1A9CosWO qCOzxj8InpOnuJXvqxlKxMQOa9rFqr1yY82qfWI73UAXo3m7dbVs3h71N0nz7dGLpyf5hGrFLWdS 7cir0QNFgE0AcXKlpJngD4E2gQ6A7AhoO30ASoCE2CY2Wy06Ot6CjlyBPLEFQ/SjPARKgASi34Kx bKHPUi0aono2mpYh3T+rUMXiWaBcKN2gVaCdoEMgGy1GuQmUAAlIm6HbTFxsFs9Ybt0dSBdP00oQ Fz8gF2Oko/fHo26Vmyeirtwaf8AtHqU2ECdTXEkxEEe3GwDbQBzmrVZltUphazQ9q8YN+3UIeh0C WQeX/SiZqvshSft10dx8Gfw9litb4e6wqiYmhai7oKYNWbiNmOgSt5CHdLEC/ALw+eBjwOeJTspU cfqjLnfNKvirh3m9GEkXQh0Q+VQD3iSKqFiZLbGykn6WWOPLazDiRlGgTFwikybC1CkcVo1u7BV+ lfy10bQRMr61lntkzX6xRjgoD1arYDVKd+0X6ZjjdDWS9mhaZk1fIEO0Y5jtSIuOGBmyLEu/uMVC R4Fs0SxGUz50N4kxNBK8RVyg+HPiGWpB/YfR0tF6bK94RKEelp3C/Yzk0poRzcyqiQXSxAxoTbEe E7BeOe+Llk6poUCpGE9VII4cr4S0EpJbRCBFMGsRzFQEMxVBUBGsPhL3Q3M/bCaI5dQtllEfaBNk uaxGWkio3AwjrXHja4ZEoShAYtx7kUqG1qJoWpaMrMDKyVVmBdGMrJr6/aKHZoI4htwbHVVQs3iv KFdDqYgWFEtAt4Xlul+MSk4NesqXU7JfjEYiZGLGiAuskboZ0FGXC1knxt/gh2WS+Dv8N3K6+SHU Jf9Fir+V4r9M8kSMH05uCv4ryYcDo/mH6OwG/nvaBInzvfwgVaGD3/FBOfv8PT5E9eBHUO8EHwK/ GHyPVfK6PsgHo2CI/UkrM18Olh+0fBNSgu5NCaOKU0JOfk3Ay1/lr9BodPFb8HHgr/AYjQU/AF4A HuO99Dr4S3wSTQffleI/5fvkEucv8900BTxqZckQTMsh2U7LLtmLFiVrbRP0ffxFvp2KYPqCVVoE 5bZo6TjdtRf9Mb6F91pj9JxAOn+GBdnnMOqnI5JTDt9s1cpO+qx9hj7E+3ifv6DW7/VX+reKKm9V ZdVWYXiNSqPW2GoE3Hw9DpBNHPuXr0NZSwbH6gH5QX38fkurNQOnMSY5Lk6rUPYrKYyyW0mE0q0k qT2hpHq+hmaCOPpYAVoJWgW6mzSUy0F3gO4E3aVaeiEtAS3DadINRDcQ3UB0K0Q3EN1AdAPRrRDS czcQ3QoRBiIMRBiIsEKEgQgDEQYirBAy3jAQYYVoA6INiDYg2hSiDYg2INqAaFOINiDagGhTCD8Q fiD8QPgVwg+EHwg/EH6F8APhB8KvEFVAVAFRBUSVQlQBUQVEFRBVClEFRBUQVQphAGEAYQBhKIQB hAGEAYShEAYQBhCGQriBcAPhBsKtEG4g3EC4gXArhBsINxBuhRgGYhiIYSCGFWIYiGEghoEYVohh IIaBGObLBsThwGuAHAbkMCCHFeQwIIcBOQzIYQU5DMhhQA6nhi4TIRdMDNgYsDFgYwobAzYGbAzY mMLGYBkDNqawJhAmECYQpkKYQJhAmECYCmECYQJhKkQ/EP1A9APRrxD9QPQD0Q9Ev0L0A9EPRL9C 9AHRB0QfEH0K0QdEHxB9QPQpRB8QfUD0KcT/eWr43SzoxG8tX8UuVHwlHVN8BR1R/C4aUPxO2qr4 HbRa8eVUq/gyKlUcU614L+lOZum1rkA+joCZoBtAi0GbQDtBB0AOJR2C9AEowSf5x2oux0zHJsdO xwGHbadj2MFd9pn2Tfad9gN22077sJ0bgWKeqc5RHC30EHCMVqL8DIQfEZT1SqrnE+F3Is7ZSfib yCf6s48bn5WzQ+XsQDnbWc4eKmeBNH4p09RJZ1AtRwJY0J9ROkM/AqotLZuBk2n97mOjdKt0sj7I 9iXZhX4fqsdAA6CtoNWgWlANqBLkBemg2tJywIL+saku94GXgUpABqiW8vPxnpiT7fQP8Uy2Nfpa JqVJP2XjgdtrlVWBDVplM8Fetsrm6YE0tpvK5FsRewmbajv4Tks/CvULSbbD0veits3SJ4Jdb5Vd BHatVfaWHshkV5OuSWh7is/BhMv6bEu/BmazLP1CMJ9VViqty+HIC+2FeKM+Cg5ZocclPXksfTqs x1r6VGntpDI58cxOlSo8G2RZF1EE9NkQC2rMP0I/rj+iH0O8nyKxWB7vGYMa2CHvILvGn67vq3wa xgHdCqRLe/w+DKS4KflL+lbv/fqT6It5d+tP6Bfp6ysHnWh+EHHfr1xY+mpjkG/35+qr9Cq9t/Ko 3qNfoXfos/XrvWi39Ov0fTJMCrEg375bb0OHl2MUXku/1ItYEGKLfrvu18v0qcY+mV+aIl1jJVfu kxmgmqT3CuS33Avvln517SDL9pc7Tjj6HNc6GhzTHR7HWMcFjjGOPGeO0+3McmY4051Op92pObmT nHmDiWG/T94T8uzqumDXZEVTsptLGQVK4szJ6Qoyc0Urb53TwFrN2HxqnWeYf5/jGWTps+aaNk8D M3NaqbW9wZziax10JGabtb5W09F2bXCAsfUhtJp87SCj9uAgS8imNcVmTiOUtObB4iFirHDNg6EQ FeQvrS+oz5mRPbWl6RuKsGoMN/nOPQVfFceYj7XOCZrPjwmZNVJIjAm1mnfPMa4LDnEXz2xuGuJZ koWCQ1o3dzXPlu1ad1MIZkeVGVZzFsyoTDKYORvIkGY4TxqkGeYoaVcKOOxKJINdeiaVKrvS9Exl pzFpN3DEaG4aMFDAxkt0RNkc8dJXbLBigG0aKEUBK4/BgtKKBT2GCuxC1ZGuw6QSBUwY3vdURzpT zswJ50y8KZNJZ00mKV8iGY/qRhboJm/8GZu88bA5l8j/n9TV4GPR6iUrDjZ3eZrDnuYuUNhct3RB gblqnmEMrFgiFYYpSsPz5i+QvKPLXOLpajJXeJqMgWqF+5r6oFRXe5oG6GBze3DgoL+ryar2Vzd7 OppC0fq6YOA8X/ef9RWs+wZfdbKzoPRVr3Bf8xWQ6nrpKyB9BaSven+98tW8UK77tuCAkxpCjZhX yaN8RDrWcLi4JNSQ7+6eIRf00PSSghXFezRi22iEL2RmeBrMTJBUVQYqA1KFfSZVWWh2pVQFK6aX FO9h21IqN5qzPQ10ZiJI4lvNSbNazZI5c4NyqZh+pOCb5qxHPkpdQM0Lm/AP9V5FvT29Z3qUnKTl vz693/QsWbKkpxfFEl8PUatZPqfVnDwLkTgccBVuCqHtojNtQqi2gbS05sFEDEofgmC90p2UfMyH DPrTyU4O3m/vd3B5i+iNFo2pWbwf7w0rQbgO82UWPiVI1bLoWC9uSzCZMCnJcV2VdauopAYeorWA Su5Ncn92JYQ+b19lX22/t7+yv9YO7e6taNS3yp9Sa8JWQb2+njPJgNgbQrIRlvT3jDV6jHLcLwWf L+TrYSpfZ+zPcdWO6rnEYozq6VHdy3yrDKOUIpIutZiPpPclsiafpKCwyLMCoRVWyZpqksW5BzV8 KtpDoxU9R6O1UtyxKHH0DMUXJo5KneT8E5zk+IIkKfVYtIN+y8Yzg6LsJI2if7BCVk2XY3V+ifvE TjpNj+J6306PsRwah9vo1XQ502DjowfYk4mliY/pEnqYNideZqsTz0P/EP2M/oEI/oBfzFq6CvZX Uxd9LD6kUOIH5KT7aARNp9ksnzroXfx9gTgeoY30E3Zn4h/wmker0V8dBSiQeCVxisrpAa3PdiTt JdpAe5k9MT+xEG9IYynCfYl3Ex9QKYXoWdqBmHwspl1GJXQTraHHWaH4GaRH6UcUZxn8etFoOwBP l9M1dAstowg9T2+wHNZmO2I7kbgj8RFWYS6NR0wL6WM2iV3Jt2gZiRmJ39G1NESvY7zyL6Zdqz1n uzZen/hh4lXcvl9m6Wwfe8VWY1t/+u7EM4kX8b2ylKqRkavgZx7dQ6/Qz+k/6a98ZWIlXUZz4Pk1 NoYZrBQZf5cX8hV8hXiHLsJor0e0S2gTmWTRHtpL+5Gb/6Bh+pDlsWJ2BZvHNrC/8gzeyQ+JJ8Uu 8WuNaT9Gvj3kRY56aQvtpjfpLTrEbOi/irWxG9li9u/sh2yYm/wY/1Jzavdo/9RO20rjw/F/Jq5K fIE7dxF9i5bTSuT2WYrSLvol/QZfJf9Gf2duNoUtYM8wkw2zYzyNj+UzeTd/DLfnF8RVYoN4RZuk NWg3aW9pv7P9m22do8MRP7U1/kj8hfjbiZcTb2PtZKH/UnzAWUh3Y1VsoQP0Dnp/j35Pf5TrB/1P Z3PZd+Clh61lG9kL7DX2NvsEo8QbB/7G8um8CV4X81uRp9X8Eb4R3g/JLx34SPF7/in/QtjEWDFZ fF88I0wxKA6LP2turVS7SKvWZmpztQRmpsZ2qW2ObZttu+1V2wl7nb3T3m3/i2O1417nm6fLT/8h TvEFcTMexdp1YiUtRyaeJnwERC720hvI6C8R8TB9jlkoYiWsDHFPZS2slV3Jvs2uY11sNbuPPcwe Z0+yzexFjABj4A7E7uMBPod38C5+L7+PP4hvGbv4Hv5z/i4+qBxH5KOER/hEtbhczBXXilswhl58 yrsXmd0gnheHxDviI/EXcRyzNkq7QFuiLdee0J7Tdmlv275luxl/m20HbDHb27ZTtlN2bi+yj7ZP sN9o32b/o8PumOxoc9zv+LXjb85uNpqVI3IDa//swwuxBy/gz/M8bSU7juYxuHW4MHIf5mEOdsXf qF7EMS9ZUo/YRvJCLVfC7X7NxItgL9tLk9hrtNLOBV4MtWGy2Pt8WDvIL6HfsDAr1J4Tt9je4CW0 HadRH9/H97IG2sXr+DX8KUHsQ/wqfoj1fhttZDexHtrOjrNp7C5Wy1bSr3m+mMPupbrEZq6xNHY5 O0GIgO7WOuk7Z4fwjQKbiq/zH8ef1jK1O3E+DdJjmNEd9AH7MZ1ktsQxnG4Cp1EHTpkHsN7XkDz1 rsc+W4n9WIgTZJH9EO1idnxDr7XP0JbTCfov+ti2ByuqAafpR/GF2tPanxK1iUrsMOwy2oZ9t4Au xY75EKtkP+qydh12ejrOEnx8pDaai49nd+HU25AwE08l7kncnlhMvwD2JKtgJ1k/dsQgEHX47vU6 dsl7bB324aXfOLz/tTHeSTH6hBUwL6vBfjhuW2rrsz1v22X7ie0tezWyfS89iRX9R6zmdIxgPr1N n9CXzIm5KaQKmoh4pyD2IC3iIbGfGlkRdWPPjsc53pAaSQ96WY3sPYX9vB974wTOievoJ/h+xtko jGg+/DvRTyvyfAP10FbM4D0sipZOnNrl9CnGncWm4PNABfnR02M4tWKI6X36M7KdUHFV4FxoYteg ry/p29QJD5OpjQ1gBnbTVJysTeJN5Hscc1MDG8t+BFwYOzQLH7+n2v7EOFXEr0pM4QvFfvzGJNDe j1+vYrqEfR9RuDCO0zSSzaRJ8dmI4R0mNJP9SkXxBO9K3CeWxRfRL+jHmBO/ttTRROQPtPvrZ1xS N33a1Cm1kyZeXFNdNeGiygpf+YXjy0q94zxjSwz9gjGji4sKC0blj8zLzcl2u7IyM0akpzkddpsm OKOKZk9L2DBLw6ZW6rnsskpZ93SgoeMrDWHTQFPL+TamIXEdUJ1n6Yfld79m6U9a+s9aMrdRR3WV FUazxzDfavIYg2zuLNwmzAebPCHDPK7kK5Xcp+RMyCUlABjNBQuaDJOFjWazZemCSHO4qbKCDYxI b/Q0dqVXVtBA+giIIyCZozzdA2zUDKYEPqp52gAnZyaGaBZ5mprNQg+g6EZ4mzs6zbZZweam4pKS UGWFyRrne+aZJN9+fcqEGpUb095oOpQbYyHebk1aZwxUxCIPDLppXtiX0enp7LguaIoO9NFsZvvg t8kctfxowbkqOsd78n1f1RaLSHPBQkMaRyL3GWZsVvAr2OIS2UMohD6A5d6WcKQFrh/ATLXKK5XJ 14SCJlsDl7gseNWokuNL3mS84RsNM83T4FkQuTGMqSmKmDT79hKrqMg/lBimomYj0h70lJj1xZ5Q R9PogTyKzL49Wug3Cs/XVFYMuLOTiR3IcqWEjMyvCl1IelKnJGUupdbZZzPLZIyey/E+bhrzDUQS 9GBMU2TRNYUi86dgAvCEGFBmJ2ZkoZnWGI64p8l2DJGZNq/bY0S+IKwAz/Fj57d0pFrsXvcXJJVy nZxdaibrOCObPp9ZXi6XiKMRc4oYZ6j6pMqKpYN8sqfbjW8jk3ERpDbktiM0bQLSX1IiJ3jdoJ/m oWKumhVM1g2aV2yRfwLuSzwsNZjApGbk1VKz6ozmLDzswUreJb9b0EjTWXr2n8udn9u8YJrJ8v8H dVdS3zrH04rbjdEcCadWbWv7ebWkXiYUeYMuJZm5jUFRzNEmJV4slBaL8rq5Z01QCWaYmhf/7DJo 7A6BRakamNFiusOXJctQeklJasv8K2bQ4fwKaDBxQqIUOwdLjcKc5kvFmYzanH5e/bzoMiKitR0n Dm9tnxuJpJ+na8FZFom0eIyWSDjSMZhYNc9juD2RIf4cfy7S3YxTKDmhg4k964rNlgdCGMoCNg3L llPDgIetnTXgZ2txfR3CJyZjbXvQ4ow3hhtCoUq8hOPLUyfeoAmCnDrCG7UdRHivP9OC/35PW9GC gxU3H/zhV91BDbs4i9sdg7zen0s2LS4o3aHFGRU67bY4F/tYKaXhZbaACnzuv9edrrvK/Xndlafr qB6y+xSK6qqS7JJsLwrEQKcMETvlt9E/ydBiMprqxEdajS2GW8IG/w2Um+G2MZ7mxvnudNscwumy p/M0l31EbobLnpWT6bJn52S6bXaXq8dty3O7bTa301kl/IKL2jT+Ym5mfc7MHJ5Tm5Gb6xJ2G7ld 6bk8w3kFL8x79qYCH4JDbG4ZXX1dds7UCXWnr6+TYV9fx3KmTr3vIt9d7p+6Uk91FatF1LkXC5QO kPDklmSzrU3xS3nhxnc2spHxSDPbe/roo4c2xj/ly4bwW70+fms8PhQ/He9hDzIh/18E9STK6LdJ 6Wul1D+k2hjlpGZG3pho9tzZVza2+wK3LuxYVNmweFHnle0w+29LLnn+CmVuZHN0cmVhbQplbmRv YmoKMzQ0IDAgb2JqCjU3MDIKZW5kb2JqCjM0NSAwIG9iago8PCAvVHlwZSAvRm9udERlc2NyaXB0 b3IgL0FzY2VudCA5MDUgL0NhcEhlaWdodCA3MTYgL0Rlc2NlbnQgLTIxMiAvRmxhZ3MgNAovRm9u dEJCb3ggWy02MjggLTM3NiAyMDAwIDEwMTFdIC9Gb250TmFtZSAvUlpSTUNUK0FyaWFsLUJvbGRN VCAvSXRhbGljQW5nbGUKMCAvU3RlbVYgMCAvQXZnV2lkdGggNDc5IC9MZWFkaW5nIDMzIC9NYXhX aWR0aCAyMDAwIC9YSGVpZ2h0IDUxOSAvRm9udEZpbGUyCjM0MyAwIFIgPj4KZW5kb2JqCjM0NiAw IG9iagpbIDU0OSBdCmVuZG9iagozNDcgMCBvYmoKPDwgL0xlbmd0aCAzNDggMCBSIC9GaWx0ZXIg L0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AV2QvW7EIBCEe55iy0txwnaRCiFFF53kIj+KkwfAsLaQ zgta48JvHyDORUqxBTPzwbDy0j/35BPIdw52wASTJ8e4ho0twoizJ9F24LxNx6lqdjFRyAwP+5pw 6WkKoJQAkB8ZWRPvcHpyYcSHor2xQ/Y0w+nrMlRl2GK84YKUoBFag8MpX/di4qtZEGRFz73Lvk/7 OVN/ic89IuRGmWh/KtngcI3GIhuaUaim0ep61QLJ/bMOYJyOZNdqVad7bGr+1ylo+eK9kt2Yc5u6 h1q0FPCE91XFEMuDdb4BcKJwGgplbmRzdHJlYW0KZW5kb2JqCjM0OCAwIG9iagoyMjQKZW5kb2Jq CjI3MyAwIG9iago8PCAvVHlwZSAvRm9udCAvU3VidHlwZSAvVHJ1ZVR5cGUgL0Jhc2VGb250IC9S WlJNQ1QrQXJpYWwtQm9sZE1UIC9Gb250RGVzY3JpcHRvcgozNDUgMCBSIC9XaWR0aHMgMzQ2IDAg UiAvRmlyc3RDaGFyIDMzIC9MYXN0Q2hhciAzMyAvVG9Vbmljb2RlIDM0NyAwIFIgPj4KZW5kb2Jq CjM0OSAwIG9iago8PCAvTGVuZ3RoIDM1MCAwIFIgL0xlbmd0aDEgMzA1MDAgL0ZpbHRlciAvRmxh dGVEZWNvZGUgPj4Kc3RyZWFtCngBvLx5fFTV/T98zr2zr3f2fe7sycxkMtkXCMnNhgEMBEUlSCSs sqiERRA3FkUEtWDdl1bccWkZJggBtKQurba20FWrVrDSRWvUfou2VTL5vc+d4NLn+3p+r9fzxzOT cz5n+Zxzzz3nfNZzJmtXX7mYGMgmwhNp4eXzB4j8idoBfrlw3dpQMW9/kBBNYsnApZcX8/6XCVHe dOllG5YU87FzCTkvuHTx/EXFPDkDWLcUBcU8rQGMLb187VXFfAT45NXLVi4cr4+eQn7J5fOvGn8+ eQf50BXzL19cxF93GrBiYOWateP5ywBvHli9eByfzibE1srqfvv8m6UBEkke/30kSSgKqsj/kCay k6gIRwSSJRfiTbq4l4kSeVav5Hbu//GR1nnmps80Hg3rgjzyfu1kBl9SXzX45fbRWwWiqQWuVsZn FWinDhc6yUUC+XL7FycEuYRVfPWp2jcrNKQwDBpMVQzmba6qIYV+sDQkmlsFhZVsQuCIGXELwjwE Xo4pkRTW/FXV0hDA6iK4ogiWF8Gsaul5oE8l1WPDCuugy13FcAd1hqpNDGq0LG/Jz6mWWrUKC16X 4VnI+UWY72G9WPLdrBcLOadYOtjRWWzVVixuHkeeUC22xoAWQpAQBhD2InyKoMLoLSSLsAthDEEh 5xjeRoSdCLsRTiKo2BDymmpzq08hoEaQ310gIlJZBJ70K9js5uTYrNBgVjRkBsJDCjVRKHR5cpl4 CJ3wg52dbKT8YLpchvnSZJVckff6q15Q8Nx9pISIwKR5p0+uIfm2tvFEXUMxMZjKVJ1o1SkI+QSB UxAFJaXFVoOl5VWfHkWe8gVippSV8mcGBTuexo8Omm1VUqvA/4f0IHAkx+8jwwgcWcl/RjYicEDf m89Usgfxewd1pioB+J+QEMImBJ7sRkzlvIQUw/9k0OZk3f81b7bI7U7kK2qKiUHBXdXTauffwXhe 439NokTk/wQYBPwpYADwJ/yrxCiP87FBs1C1Cc97FOiP8htIEtWP81eDBkR+D3898clof8ibis/5 Q740VdWq45/kr5VR1vCrSA1QL+NX5KvE0BH+MYxU4j8a1OrZ+D7KC46qF/gP+BXEDqxTwHKJ5hf4 K0gWgb3J0KDWWLWr1cAP4TWHMC0ixkjJQ3Is8b/OoyM87yl+E3Gi7hi/mTgAn+a35B3i8BH+X/Lz Pme94HmPYMcwMGg0VQ23avlHUJvj/wcz/j/y004PJhqqSGuCv5VUIHCY1PeReh8pgf8YqY+xTB9j aT7G0nyMUXyMTUv4EdSMACfLv0sG+LfJLoSHkFbgBTbkMYNs6TbkY6VVh/jr+GsxE8IRzB1F6fWD WhMb2bV5q01Gu5YReMsL/BtkBgKHyXqTUeTKI/x35FfZNej2sQa/zWsNmLprimuBnq5ma/ACv4nf Is/EZnkGcj9ClhIzf4PceGzQYKnaiNWfhexKxDsRjiN8gqAA2iy8wywyDwHMm+8ZNJmrzEf4OXLj KXlTtfgC34VX75JnqyvviMhjPmc8oTDnfcGqH4FWzCQDjlalMClU+aw48wg/DftnBj89v0jE2Gfm 0S+bk+mDDROqKo7w0+W5mJ4Xo8XivM0jJybntcV91T6os7CRdMiI6bzGJNenx0mSTw3aXVViq8BP kN+2GjHh67F89ViaetBJtbwYVYOCFbt/EV8lv1EV6UdqN0IOQYE1rgJ6Fda4ipyUS8x8HV63jowh 8FjbOvIpAtgsX0laEHYiHEU4iaCUS/uR4lBegSf0I96FwKHHLPICYgmhH2ETwm6EYYRPEdTkGJ/B czLArkC8CSGHcAJBgbUqwzjKUGflQ2QUQkUkG7n7pAl0I9lIN3Ib+Y2KjcqNwkaLRqqNl1VJy1lU zqJSRPX92gHtJi1foZW0PVpe0Ia03NDYcF49oRpAsqomVL/V/WH3F928tX6XapeaO9ZqoBZyAuET BJ4cowJyAnKCtI0/1nyi+ZNm/lj3ie5Puvlj755495N3+WOZE5lPMrzU7ZtQVT+PrqQb6U6qEGmW ttAZVDGPX8lv5HfyCpHP8i3YC4p+/YB+k56v0Ev6Hj0v6EN6bpd+tz6nH9Yf1ytzqmHVcdVJ1acq ZY+qXzWg2qTapdqtUonqrLpFLakUn7a2c29jUncjziFwZBPiXXJKQEzJMOLjcp6VYjkQD8h5CXGP nIoirmAphCj6egt4mxDvQgDxyfko4gqWR4iCu/8BOAOIdyFw3B8kf6QiJsU4IRaKcSRGP43R47GT MS4XG45xw60TuDeBvxtxDoGN8k20ZKko4gqWQohitG/IeG8AjxH+JsS75NRuxP9d1o+yAblWQtwj p6KIK1iKeyMfrTe3urgH0OM8xA8hnEDgSRZxC8JKOSciptwDiCXu/sGSMgh87v58AjwSIFIEwSLw y2DQ462a12rm7keX96PL+9Ely4kILSw3Nszdl+9guPflJxXBhOoTrfWQomwo95G9CByZgfghOZVF 3CKnWA1Y1Vf5HFIn5ZoBxLvlFGvHeoEcQHy2Lc/dj+99KDFzV6P0aknPEacTqpPVorEOcYfzy6zi ELc/XyoADBZBnoFWG8dj7o30Yzn+oRw/JMd3yvFFcmyW9FHjf6LGV6LGJ6PGVh03lcTQ6FM5/kCO l0ummPFvMeNPYsZHY8ZHYsYj9H0SAVJY8kaMf44Y/xgxHowYn44Y74gY50aMMyPGcyOsq1ISIkYu wGJ6iRz7JVfIeCZkfC9k/HnI+GrI+HDI2BsyTggBnf4PqQHig3J8jxzXHqwxijXGQI3xMAfORC/O m4n2CMfRi4mR1+VTzeIQr5UBF853xzED/nx3K4Av330egDffvRrAlu++Q2zVcma6D8qKyJnoPg2D hnxqM6r1RaDJpy5BTplPNYpDtJBPRQG+zC8JAHyRXxIE+Dy/pAbgMwaep/8kSzh0Q/+RX/J9dE8/ JKWsW/pXkuCeARzKd7cA+2Dx6XQ/aaZxFOehHTK0Z/MpDI7uyadKAZ7Mp2IATxTBo/mUiNzD+SXl AN/PL7kD4Hv5JacA7s+XXsYedx8plfu5lyRkuCbf7UP1qnw362gg350FWJnvrgVYkW/+BcCyfPMp 1vRSuo9iZ9MlJCWPdH5+SQrV88ZfpI+UytVzSa3c8zn5bjYlk1knrUbaOf4iHbSd6Xy0je6Te5Hy qQqgNedTCYBJxZlryi9JI9eQL8VU0/p86fcxc3XjD0iy9XmexjAM1lE0n3oGSGJ+SRIgmF/SCeBj LTFm2/hTraRZHpQln2JYQj4VEn9E9WSJPGQdSdD7D4ij6PfL5iF6YV78QhrS0Lz4r1KAA+JH3QvE v3cPQeMVPwQlP3NAPAHUd5uRlPTiO6lT4ttLIuLPUsCQfOJrqXLxpcQGcaj0iDjYHRT3YWC5JQvE vUvkHn6YQLO8uKd0iKNovXvJueK9qbR4TwKLdED8LpC3sWego62pDeKWxGbxSmzEtd3bxTWpgDhQ eom4vJQ9yCUuS50nLsWLXIo2i5dcKs5P3SH218ojviT1C/F8lsyL05bIbzSlWa7oWnKeOBkjQEUL q8AIJmJfVqFpee0RNkfQVNoHfyFeUP88BylMNyGslsrVL6ivVy9Qz1K3Qd6UqOPqsDqotmusGkFj 0hg0Oo1Go9IoNJyGaAhnHxo7KaWZyWZXyZabCkYAJTBDEAscixEhJhzVcDC0cjZ+Gjft/LZcfXra kHrsvFxDelpO03Px7H2UfqeXTssNLyTTFoRyn58fHaK6mXNyymgbzVmnkWmz2txAznE3D1Eya/YQ HWMttvpy1vbZhwilZVtv8zE4eettvb3Eua7F3WJttjRO7vhfon65sL+jsyP99cf9dRIpdzqQu3va +bNzTwd6c1UsMRbonZZLnh+aO/sQdxm3vLPjELeCgd7Zh+hS7rLO81g5XdrRC7SJMhpp5lYAjXQz ADRuLmlmaCif+w00ug/FHfuaETGkGXQfQwLRzJCR5sh90fZvIvG30HYZqZ2/RUb6fvGBKYwDD5QY QF/Ky0hKfmBKeZmM5mZo+xIJPG4Jot7Z+6oSQNiXqJKrZ35dXVqs/kGx+geseojSr+tr5fpD4OEM 4xBYWilwvjWF/z9nFrf9f3ggHZy07orZnYujnf3RzsUI/blb1i115zYtCIX2XbGOVYRyfKJ/wcKl DM5fnFsXXdyRuyLaEdo3SW73X9WzWfWkaMc+Mrtz1ux9s6XFHflJ0qTO6PyO3sHpmxtWfetZ2796 VsPm/+VZm1lnDexZ0+V2//WsVax6OnvWKvasVexZ06Xp8rOmnddGp/XM3qchbb3tWHMGBzm9DtTS 7wv3tjmFgWaZdCaG3df7DisI3UP06d6cIdqWMyIwqsq0ZlpZFUiaVZlQbB6vcl8/Mew7TPeMVwko tkTbyFp357IO/K3BZ+3aK/HBmqxZU1wYVsfK051yPRDWIoUYH2AizQIKvq5fS1gf4590uohL1qTb Z+/r7u50L+vwQYkfZHp3uncNSaeBKT+L4Jl4a1nRd8qKvl7lrP5d95+7P+vmh2UN/zi0+5Oyhj8M 7f44wklo+EF+uPl488lmfrj7ePdJ4L57/N2T7/LDmeOZkxm+fnwE7FG9FEP9+ntles2VrDhN5beV 3xs5lKxNr8EUIB6fBuRQsRaBzRKrY0nWNI3u5Mp08S1QUkzILdesRYY1kEvlItaGtbqSdc+q/x+f 8VKwYOV3iKg8Vw5+/k54L8jYewinEP5WmDp2RrmCRAvLx07yNrDrWDGMe+Di5EYoen8jd5OjpI/8 HHpjJy0ns+HpcRMPGHsjmYbpcxEl1cH1EyXTSA9cEVPJn6mR7CWV5EM6mWyGbjODPAi9cDqM9FZy O9lNzxn7gGwmv6HLyDNovYdKcDedS7vGTpCZpGfsIJ5ByERyD7mfmiCszqU6Gh17Fz2sIdvIYfJ7 MkbmkHuVu9FLDzmPXDF2kMwlv6Jz6MVjfjKFXEGuJ/eSh8kL5BS9mQ4rlGP9pJYsIKupmtpoKb9l bA9pUL6pfW7s5bHj8GZeAdzD5CMurZg89jGRyN8UdGwplHwbqcb3CvIIOUDeoW5ay7cTE9TPuZiL a8levhRj7CLb8W6H6TV0L28aewxvU08Wko3YUlfRYS6sfFP56djVxIr3q8FId5DHyI/JS+Tv6G0y ncVfXmgZgx8A8jRNOvGkG8lN5IeYuRfxfZmaaZhOQc8/pu/S9/gr+L+g5yfJCPmc/JuW0mX0eq6F 26KsGt089hxJ4A0l9DGFXEQuI8/SBJXoxWj7ILeeux6m8gH+HUWp4pOxhrGX4L6BSU62kKfxXr8k vyFvYL0m0276e+56flB509g1GG+WLMVb3EgeJ4fIZ1RJtdRA7TREq2k93uwaOkzf4wJclJvNL+D3 Km8d2zB2Gwljr/SRxWi5nNxAtpKD5Bj5E/k7GaFetMyiZQvtobfBRH6ZO8ZfxM/l71ZIirsVzyhe VJxRWpQvFn5VOIlZZ/1UkG58+8gScjXmegjfl8hblKc+GkRPk+hU9DSPLqHX0l30LvoofYIeoD+l x+kH9BP6H87N3crdyR3hXuGOccf5AJ/iO/iH+NcVYcVbii/V80cDhaOFT8b0Y+mx6rFdYw+OvT02 Iq+Cn8RJC2nH7lpBNuHtd5G7yPcw5/vJL8jvsO9OyN9T5FOswZdUhd3kwYgiNEpLaBne7iI6m66n O+gd9DH6E/oePUXPcIQzcBF8U1wdN5Wby23hPuLO8Do+yrfyV/H38L/mv1BsUFbh+4zyOeWnqlPq uOb1Mw+MvlsghWWFuwsPjNViL6qw82yguRrShj03Fau8iKzCdzVZR9Zjjq7GjD+InbOX5MkR8ip5 HXN/jLyNE4AT5JT8/QArcZqMkgLlsJ5KqsG3OPYKrEw7dks/XYy1LX6voVvodnovvg/Q79OHMb+/ or+mv6En6Pv0M7wT4TJcK3cO3qiHu5jrw3cet5DbzN3C7cf3l9zvube5P3Ff8AJv4UW+hO/kL+Vv 5nfwOX4//1v+d4qEolXRpVih+KniV3jzLuUU5TzlQuUtyoeVjypfVP5MeUo5prpD9YhqSPU3tU5d p+6BWrpd/ZT6iPod9ZimBPupG6NPjvMpBu6gFyuy3C46xg3hvX/EreV/zt1Jn/kGBlHuwAgWwZge 4l/gvnftLjiBn+W2EKLokLEmgYu9Tp4nryt/o3Ao/0Z+ynnJx+CHd/LzuR/B1HbTOn6iYqvidXCd DRjno9wJTs3tBcbfsRrzyAXUQ/5HcSH5BPN/TLkDczqZe5c+w/0EpnMfeZM8xh0hMOrJYlqP0S0i z5EvyO30EB+iB7DvNpLj5CNy8uvxKrKjbVyLys2tU03ACh2iM8d+yiXH/g6qf49uJW/zX2DvX0in 0yx5gryPVf8draGioqDwkV+B8wXJA9i1fyWDoMGfKWKgoM/IIb6GzFGcxH7Njr5W6FCu5W+gn3Ot WE6XzLlnMG4MHnwveBXjoyayF7QOLiJT9N/JL2gE8uQ3qrfI/WQnOcw7SJx/nNvEjfGvKkLku3AJ nounXgf+5MdZ1R5yOVmG2Q2N/aXwGHpYThpIA11A55AO1HSR4NjlGPkT4EXS2Nyx+5S9yjT5JT2X OshRcC83ZvFupbYwAsz9oMO3SRe9hQwWFpFhyBU3jdMq7KYR5TrlLuXTyv3KHyl/oaokV4FqH8Aq /omchtQI0YWYiw/Jv7DX20A9ZaCfVoyiCzLsMq6Xf4G0Uy8ZAA8sBd9uwxzMwUquQS9byK2gp8ch Q35JPqUCnUt+RN4E5bhA5wvxfA36mUYuwKqvIU+AO95AB1GyCEcKKdDZF9REG7i1eB7js3eDzw5j TO+Qv4BzjMnjKqMTaQdWbyH5F6NlPKGO9MAeIGMHSCMkZQf/OvkzHGsCaQN/eQzt+rE3TDiqaFS+ TzlSVpg+1sAt41+gTkhDE3bVLEj2SXQVRmHGe4wSB51BagvnoLdnwMt6lI9D+qYhGRycQ3GR8gKM +y1Isl+S1WOz6f1qUIDUdsEsqaV5UtPECY0N9bU11VWVFdnyTFk6lSwtScRj0Ug4JAYDfp/X43Y5 HXab1SKYTUaDXqfVqFVKnBpRUtYZndwfyiX6c4pEtKsrw/LR+SiY/42C/lwIRZO/jZMLsXbzUfUt TAmYS/4LUypiSl9hUiHURJoyZaHOaCj3i45oaIjOmTkb6ds6or2h3Iic7pbTu+S0EelwGA1Cne6l HaEc7Q915iavW7qjs78jU0b36XXt0fbFukwZ2afTI6lHKueKDuyjrmYqJzhX54R9HNEY8Yo5b7Sj M+eJoim64eOd8xflembO7uzwhcO9mbIcbV8YXZAjTIlOyyikXX5MTtWeU8uPCS3L4W3ILaF9ZcM7 bh0SyIL+tGFRdNH8ubNz/Hz00ZmzpPHcjpzr6lPur7PoHOr6tm/W+vgdUI9DDHnHjm2h3O6Zs7/R 1hdmPfT2og+05eKT+3dMxqNvxUpNYyZejtvaOztHt+KRMDni8lsV369oD8X7l4dy2mhbdOmO5f1Y Gu+OHDlvQzjv9UqHxk4Sb2dox6zZ0XCuxRftnd/h32cnO87bMOiRQp5v12TK9gmW4sTuM5nHEwbj NxOLMenFOjklo7PUtPO+mlnKxhidkpOwoxaGMJLZUbxTA4sWN5AdCxuwAPj0UrTKLcKKLMtp2/t3 CBNYOV6R5pRxIRra8RnBDoiOfPTtkvnjJaq48BlhlWyffLXVcnT+2XQunc6lUmyLqNuxphhjs5yv zZStG+Ieig4IIQCYk6QHczu/d0IW0x8OswW+ZUgiC5DJbZo5u5gPkQU+OAKzMLu4flYzfLbGcQGr 2XS25qvm/VHs5P3M00IcOU3iqz+z4LR1Lp2Qo87/l+rFxfpp50enzZwzO9S5o398106b9a1csZ5N KOYNdeOpnK19Nu/jUMZSnI+Xa7Ep5875CgWZ2YacIo4/lbypFw2pNdiVcgkNTc4J/V3FuFcXDo/T zP+t0dDYp6yVDL5uNv4auQnp8YEWh52b+K38t4Zn2MFPmwWWw02bNWfHDt236iaDme3YMTkamryj f8f8obFNC6IhIbrjEPSZkh0DnWBDxRUdGjt8iy83+dZevMpSOgH7liNt+6L05pn7JHrz+XNmH4JX LHTzrNl5jnLt/W29bL649lmzx8crTybbk5hcQlSN1M9hMRWElHJPk/MQPAhVKJvDNbKDdjIVYRtC FUIYoRqhE+FchC7g7lX+lAjKC0kacCZgUtVIzlffRpLIJxRryHKUTcWBmhX4c5FP87eR6YAzAGeg fRvKu5GfjOelADsA06qn0T/KUDcVsAS40/gAmQl81mcLym3o3wJoQZ0Dr4ALAIgJbsaoIAExB+Ti 8RL2gsUPz15U/iiBpYYtpCU6okcbI+QagTQjsNG++bHAPoGtiuNz7PhvVLDDj+LHRZh9yj7eYsG3 Yh/xQ47i8B/jCcOqjKI2Bg0sASutFKf9BDI8DdmdIeWwgwhskcrx9nWkjsboalhk73AKLst7+RsU JYpjygaVW3VU/UP1x5qXtUd0N+rXGq42rjVdZV5o/sjSan3B9pj9fMeFzrjzS3e3Z5PX75vj+0Ng cfApcUfolnBfZDS6JrY6viTxdsmbSfa2HPVDy/IrcZyL+Wjbz9GXVOohXiPZiFLxEk90asVLlHg0 KuVLHP88bSVaKEMXEnda+LxptGm6cLqpe7SJtCAtnEFUWRG2hC1xRNSvIGdC/PAZSUm+xHWUYTyL lI6d4t9QLmW3GuhK6cd6pT7oU/qCcBNroSkQLW9XEq3KgmVRC3qfTi0Y3Ea1YHaZ1ILVZVJZbC4T b3e6TJzD4zZyDq9Pxzn8Ph1vD7iNvD3oNqosok+nsuh8vhaixZppjW53i8tkd7lMFqs1GBRFpVLV olZrNHq9wWA2CyqT0ajTaQmvUPj9gYDNZm9xOJxOj8fr5SRKqc/tdrmIzmG3WyyCZPbUmAVRyAq8 UG1S8eyMVypDYQi0Vk3ce103Gfe2mKjJG9bd5NPe5NubhYKOY06ztYZ4Qiu3u9OYsXRf98gp4dR0 4XMkTo8Ip/vSTU1yLDQJbC4ZyPahrPjF1I5/i1XFWC77umqbsjx9nfDytnI3A+b/+lRW0D6XLVpb LYdqPmyr5qsdUTlEbWHeFraF51x48yMT//ivi26cTUsuvHH2rY83vffFhVsvLPxxzlqamFB4y0/3 bKWxLXRfAb7jwowthXe2FmbTPYXZXIbGQGnnFZZw34V/x0p6pNJtpoNmrl5xL3endg/3uFZJXyS8 4UWjzWgwgFIr7GY1O2fm1UPcXZJWEqhwoW3l3WxT9Y30YWexlyMtIy0jlRWkj/ZRh0qNrwWbwOly JIgFt5G+u7SyI1Fx0bSavn8U9tHpyhXlHa1zbttb+EnhzcLQ4sm1VTPpP6H1SpRZ2x6MrVce23lS pE6xTXmzecisuJu7T/sE95RWgdHZMDpQgKAOjY/KMoONyk4oNRiMFbbzsHbY7PKss0F+Y3S22rp6 fC0CV5IoqXWy0XmWVraXFAdHZxT2FZaUd7bOuTVHJ8CXco48uIKx8HzhxwXmBiNVdCW3gWsGBXol A/c2GImSehQ/uI3tllPCX0i2G/NAw7VhbsPoIe4cuvIYazVn7K/0SVg+ehLZT6ao9PwQtUn6kLZC y2k9huJeO4MdhpGidRWUaFU0kqitqaNk8vwFnZ3z59MaGXR2LmD9cWPvcS2YI57USQG8dgvH2zmO JzylnJ7fywa1lytTPN/JJmIEu5d13dTSNL7z8AyYelxLoX0TPapc8cU65Q5G8VNB8c+B4mEP0KmS R+tTiaq4NulSu32OkCPuTmrVGrpeE8AxTN6qLAEYVBmtriFeJ8WJFEvUECldjqi6DtHESTUS7I3d bKYyVnNEhK+DYZp2GqlRsjlqjJ6yz/7Bpu3z9Orukb722ZIrIsVKaiKskwjrJMI6WRmhq5gTsxeI cqJ7hB3vuODlBbKLeXuBL0M0YfA5tOp3jbcaX/v2DdICmgqFxTCnMpsEE6eKReNRTqU36Axag8ag UDmcdien8ri9bp+bV3FwKSkor0qlk2lOFbREFpCEGpHf5lpAS5WIwqbAAho1lCwgbidSaYoUGydl UWr8s5msoquoXW3isJzYcVjS+rq66iqny6kUWD4aUatAKy6ns7oKG5N/rjGy5rsXLvj+pLJwurn6 +Np1v6hoL7yu0CU8DWlP3Gs3N5RXeVIq7omf5y7bMXNRX8eq+x7946H7Hn345iPv0EUTb6kMuaP7 Rj8pnFxwTkWo4Uq2V7ZBXCzEqrrIDc8TE/0BrSUa+viByDz1SjVHcTrLStT0PxB3Tvo4MdN/wUSs JU6Ok0xmDVFq1AYUirBxcXQuCSZTj3mlea+ZF8zU7HGbfgSJreF+Qtyci56QZQ245em+vqZuYbSP ccgWa+NnI2foZ2nal8bGs9jxrtWOcG11VV1draUmweagJM494JzcLY7WxS6a6rVWhqqnWOk/lUu/ fOa6zrJ4vHTyJu7oJdlwKHZKpkG80YN4Iz/5mxS7mfsh9yzPlxju4jmdXqenROmz7nbud3JOP4cx 6fQa/xDtP2DNunIuzjVEI3lq1bBtozfWaIb42H6TkuJKHT0t+YhSUHLKd6y/MfvpUT/1e4O4o3gU ksUTOAwP3i68Hqi8bxVY36ru06N9p0hLywg7VpBsGslpbNFILhMijxmRsZFthF5MAuqL+xUY8j4F kgx9ggzzfkuLjHvK0thosTZShD5Lo7URWeE1TFkf6QuHa4m1tkaeK3kDgUWoVTSMOayv5nvO/Imu /N6WS+6/IF73zq5Ln+6furjwLI1f1pqKxJz0OVq+a9kt9xuHh/qfnLJ1+6HCc9Z0J5vH8Nj7/A7M Y5ock0S12WVemt6Q3urY6nzAdpfzKesTzsM2fcbf4ufsGjpEwfyZwoXlDutxut4PhSzMvY5jvl9C mdJgPo0WzCeg1QHI/fKAZFJ6jcSO2xT7Q5QqdYfpXURPvQeCxWkGMzho+Q1JCkkuyRiDxeyiLm/G HKRBxh6CnrJvzHkac74KXOI0RM7pUUtj1uMdaSLulhbvSDotjEJEWxuzfSPWxuJ00dpm7puzBX6q dmLKSDjCaBAUKFNcHXBodvVsacOcWxfEu97bcdvBCy6+8prCLwqFZ2c0tqXDAeGlC6YuH+b2RMON Vzadv/5O45N7nl0z7Zbaxiev/23hjcbSlvJWk+ahK+ds/ysmphr78geYTx001Pskd4sRXnEKNZZT a3VKjdFAFBqjUa8fonMlgVBoPFRPqFqjN1IFOULPECXRcYJk0FClxmAkOF3nNEd4LTpW037JnVW0 KDizQlRwCq+ZsCkiHlORg55iwriv+3STTHEtkH2fN2HzsI1kbdxWnlYU1Yzi3NhotQX6BFS/cH3Y Us3dePW11xZGCo758E+P8cvO3HOscJxWHONc2CGdkAiDOCOK0B6p3KSiWp1HV0pKeYVd5/A5/HyD aorqoJLXKynUO78iICAOKKhXwYOg2FtG8JYRcH9KIoIsALT7rTglUgzRTw5YQ/xRngNiZBD3A7y4 AiHpzDbRxtneMRi5Ie7VQforDTnCqaCKB+hnklfS9Gh2a3iNNyb8ameERtgcRDzR4hychhQ5hU0y AjF8GoQ50jcCTZcRn2TnJZAYL4HeeEahPKNVmeIKq2TixN3UQWAo2O4FkgyBJ0OgMpi3G+Qm6d6R PtZICkZYpxHWaYR1GmGdRiSgRSSrvoib7h0XuMRidbHlcGF/klV9dHXfKhrmw2oF85epFNGzuxJy wQVJgH0ZC0fUcBVes3j0w2rae/i+7xQK9z/R29yaLumZP6lMLDlvTWF34bSvTnluobDN+NANL133 yebmsoZ0W6gjJRiumpV7h92zOBfr96LM+0tA41o7T5c41zk53dDYvyWH1V6T4mOOnzr4Fo0y4naL Sm3C8QL3M+gTd8Ha0NL7n0skBKLEnRndfsEYeccwRN8bJN6ke4h77TmzV/RyXka4ejtbCLun9OxC gE5lneNzps+A/WdHhJFT8l5kO7KyAsK43BfX2WIJvy/g41TWuCkR10UW0KDFu4CEzEhF9YkF1GcT F5CwERGTrLJgTafSmzeTPsgSKJomTg1dDtIUc8j0JZC8NUZVDjtUTzaJkLDRCP/ic29vjJYFWtvu /fkVP1tz3W/Xv03vKLymqS0PZ8q72tNTSpVL/eW3H7svqLX/8ehNJ6/eTjUPnKLbPxi9Yoe0o1Co ia94jNqXdUCP6cJsDikXQpLGoAd2SaW8QWGzGOy2TsPSxIaEOk7rXRdWrVfcwN3oud/4QOxp49Ox Ic0Bu2Gfihn1kkvLO8ypyojPEHcTQ001AwqR3ddi+lQ5wD6VUVZYvtouPjh8cPJUY+DPN/TEFxrW GG4gyrjBaKxyx2LEYHbHKyPE4Yu7wVxU1ioaizEh7TBW2YFCY3ykylhpNsZolUL1jcfkVUb5mBwS 0DfEEyngqKh8R+J7+N08z3trisraO+aKlKQ11qQYhmmnlmrZMms91WyZmdI2kmbcGBR3ehRjhAFQ 3OOyDGvcZipPbzNd9/LZnc8EG5iR2iQ0bTMJL7/MTIXecYuBcWa2fmDM9Ykie2YlaugHNWwJsaJO HjYFg0Xq4A7vXPmv3772zsY7H774r6+9+KtVL8VjDamp7Zcsy4hGe6iiNztlEVdY9tyVj73/k52X P9ZxzYOX3nzs4Kb+OzRV107d0lk7v2vK9wqv+l3Rm6ZcsrFhRd+LoJW90NHP8C9CR3eRqkPEA3PR Y7XVqKYQtWGKVW/mp2jLjjoorNk3j8m2IRguM6dlywf63ze0dts30vRCaO9Mg+8Y1+T5F+UsikZX f63Tc8yXocyBVnHKSSukOyKC3tqyRFgnrI9uE26KPm08KKjvNg4aORqLciQSjYZ1Jn1A5wq7Ay49 FofTBLROiyPgpDEdiTjXRM1CKErCQpgLR7lwxiIwozjKRcNcqclsN5nM3DoYv7qrLTQMd73CGQ1b TJyCuqLmSKwUoonSU4IkmHkIStjcGrOTOg/TLSRKy6VoSOepSAwkNiV2J44nTibgCE2EElKiByW7 ErmEeuflmKBVQt9pj7d7FPaX+6wx7GU64Shk01cbvA+6jrxZNMwiNsEkRqLv5TRThRob3UQYocJw Me77ZkYtNDWpm+DDkG3ONA2rsTuYxRmuhUoEwctYqaxl1su7qKQEW3tWIdzoL/ctL0yackkn/bON fjA5E2keHfDNCDlVnH/5z47TLTe2pRt9giYe1y98QDHhyz3fT4rKeNwpBK02bds/6W8KGXAC3G9T miAXfeAElfQC6fZ7XdS62LeOW1fxpPuZssPBw2Wvq9/J/CerK6UNtItO8V3A9foWczdxN1bsoT8t +23ZX4J/i3we/Hfk3xWWLk0i7o/FSkyhgDYSMYcC9ki0Ih7kY6Q8VFGZIvFgDH4frd1fHo9r7bFy h8POpco1Gq2GhIQQF3rX8z2rwlsdqzSXiCVcScZs8lRVD1HFYHjSbFxhm87cPn3MhdHdPvsAKRfK ufLuD/p8+8q7R3pBwcyJAVEpjIBCsyMeFiNA+yxqoiBqdKIWTE1stsG6q9KZcNTpVqpd8UjCFVcl yuJRZyhLIyxKq8uzNOyOsSiKsmhGmYKrLC00nWXg4OSb8WHLxsSo9eqKDzJcoixd0RjpLbup7Pdq lcwaEGEFmZIL1fcrS6E2XCUzCyUrgemgtljUdsYS5By/88fTB665p3BydMYl7T5fRx+344MXB74z +t53tnWdc+N3aX1dz7au2fdzxzLSxbfft2hDPNpwBT9wRWMkfv7jfQvus0pr58xZ00RHHyx0V9XV n7Pt/Hn3NDE9eebYe8qLYG3HaOAQcY5tGtTqavzw+jKoGodGQKkXBQav1ldn6/be5LzFu9O33a9Z YVlh3WDZYN1ueVK1x/i466eun8Pt5SSJdmerf5Nzq+sm343+g4ojQV02sVRcr1pnXOe7yXbYrK6H GywWgG83QKF+22Hozwk/ZbGalMsDvGm5Q0vnZS3U4h1I0IQ1fsUhWiWbJ7CjtWadqON03R7PabbQ g8XUCCzoPrixmG7UMgLi+ug0aAtOLcKMjGnnb9hXpcHyxpx+ldGAhdVo1VpO5UsYnbo4UfkR6d2m ONF6lXGIYiaNU2wpad8qAm2GqVPUEmXWHDg1RDBblXoHk8sxWS4zlZsVKS8qKfv03o2/rWyZ+/KD m363bvW/Hv9DYe/Bn9PeF3c+NNcTyqqVKwqpoZe/u+6eQwcKv7tvYPuV61f8kE4eepHOHW6OZaFk U+aLVXwB+quk06URp8Kj5ULVFdUD1buq97jesL/h+ovrXy7tBt1ax7Xl2/nv2pXbdffy9+rucOzh 9+hUIXunQ6ruqd7AK3W8TsdVM6XtTsWD2scUP9Q+YVcaKFHPNBh+rgmoQ6GAOxJJz6ysfK8skFbN pPTnyoAqHAokI1GqIga1kTgEHJw603aHk3epXc5Ba7m7sjRJyw0Gd5Jza1Rqs3qGmmtBtFO9V31M fUKtMjPLW11VvTd9NM1l0y3pGel56ZXpjemd6YfSmvQNgnPAucvJO71SNa0mZqNo5IzN4ZCnatJz suBh9Ax3rryYfatAp32rVmchicZVLWFkpGmcv8KOlAk5jYX+iAij4+BslheU4yw0vaoPH3grLGyN qi3Rci5atNRZlmfWOvObwV6XvRbR2jBbawhnrty3ea2QSBi6l8y31UyY+aM/V8UnfXlZZmLMa9Ir db5EW0axMhFY1t9wv6Iw+uYj3x+dsPbO6sKWgapQbn9hZtxhiriX8NfOdURt/nhh5R2bglas7/lj J1Ux5WWkml4mOXWCMsbHTcmrxJvFG2M3xm9L3pzSRcfpzvBfdJhidNgOOlyqXqpfr18fO8T/SDGk Ohg7mDiY0nVEJyel1LbkTSnlfYl7Uk+qHlXv0b8S/3lSPdXkZqr8gJsGXw2450aYgS7ZUbLRRS2v BlyRaPU3SDFC5lQ8lQ6KVBCNLrc7oqxN88baiBb+RAtnaaZBby1rrzUINbXWUk9N7fP0fAj2K+hJ 0Cg4MuPEZq0I75/MibXgxNOF9OdN0JyLmlRjtgn6EkUgwlk6ZQ6UohOFMGrtZNRaFUqpzHqsRLwk VgIdKW6IauPEFBbaKH4LK6hSyOlKjHFiDhnbiCYp0y6Il/lGZQqWOfEqdIybiVj9aALH+SruLP3K 7hksNugYRG1hlgpb9VqBhMct6Hrl1nh74fRD9/5s1txf3FZ5aZ2zszLK3TFtoqDdUvjrPT8ee6l+ MgX5Lp5Z9orVX2EHcUdefv2Zwi8ffqnw1g6HnXp7sol4XCnGbFMLf5kwcdkzK3Y8Q6voE4JmWrJx nNbVS0HrdXSGtDrItCJ9kGqD1wS5iobOup6GJ8mrUIn9dXQ9We9fH7iJbPNvC9wX2BP4MPBFwDDQ cLKBE62iTbQLMSGuNFvNNrMdYjuurVPpQgEuEvGGAtZIpHxCIBGJ6EMBSyQqTgjEI9FsKFAbwT67 WWonAX8IJ1alfp/d7/eRujpCMoGgPRAIEloX8PMibovU1eJgIREP+PE7G0LqG3yCl3qbdcf0J/Sc 3tsg7wd/sEYeEHKbJK3DWdMQFEuz5azOwurKT5Zzw+XHIaE99Q1DdBZE+Dr3EG6ys03TtzrNDnCw UVanP4d/DUxAltZuSHD2YbFs8rsaNTD6lVCoAN1yArfX5Q9zAfTB+sS9o1VpSsMO5oBkS/u1V65I 5/APW6BPOWVPnRMqFaN9cHdsBv44HeBKy5piHrPe2dFYNtpUTI/+2z36qdJ4UV+hwpSZXqrnUJnm UvSX/PUg87B78ZktS2tK4uMkP/JlWvH6mc5FrqqWeJyKNVn9xfycS6tL4swTnYB+9QeseRQ/SLhK arnAu9p7r4PXRN3Rad5z/OdE5vsXRtRWOExUglJQKSqyl/rW+9ZHbo6+7vt59HhWc5/zt97/uL/0 fOlVZjWGIe53+wPqSITKCVUkakRCasSqR7GYPsHH+TLRiD0ajWyM3gIVmaT8Yd+myKnI6QgvRHoi xyP8cbgbXCl/JJqIl/uG6J8kFw4HVbFMuc1m5UK/DocjEZCIJhQeokqQPUkJKS71LlzjnOQ0xOJ4 qaILNWMw9MD/fV35pEO4FCYfojQxnVg+q4CqLMgHdHKO6WSj4ALZphFozEVlbNXqPqjFjOMz+6rP hCVmCyvrZaGSMrvXEfck8CNHeypLS7yI0s5MlibdiSzx+r7WwYrqV9ExWQpXgN7QmNYYGv1um6OZ shvKvcznWHTVQof+b/ULO2ZcvaY8kxdM+YpyIShco1PHFa91n5/adVnntXSy5EvWFS4oTOttvGXH jNsf5pYXbmQK19eqV8fBa+5e0CwWanudIh/nlnP3jf6weuuKB+5ktI/bx4owNK9GmpEa3RUXJdeH eZWJas3qtKrCbXalM+a0kLRkI6F0rKwuVZe+NLk9uT31VM1Q6nCNrfErjj1FcpA55jqxjqt7qhJU OycUEEMihUl8lTQ5OId4BfgynnIk02ZNwqw3m/16v1mxzrwu+YD5cf1z+pfNqnTSrFdElbWVfLTW oZ2BO6bFH3Uq6UUkISS4BH5YJJms3okSjOqJZo0I5x2K9ouV5Z4JQ7RxH1Rx+MW7T430MU4PRn+q yOotLohvRrYyq2cOznGl7COk5eS49yDE63kzF08m0sv1y8xX6zeYb0puTd9lflZ/RP8z/c/MRqhh skW9CodwtqImJptEslPJYWe8W7am1VFL9bgdDWZeDu2s7qw/tJ5/UZ8MvH/jkvWOgJR9+uPzzyv8 63Vp9YUVoneCNR4v+/L2ga3VS2889MhFHz/X1pzd5vMGjeDoTU8fu/ycTDRbHp515dKlNz39mTdm L01y5M33r55ZMWdm68Wbvj/vkVOCoTU0ia3qVFC3AdQdIs8eIhH43NzemgjjgRMFa00oIoHkhiOK CiQ4+ke1+gwUYHcoIEQi2lDADO78R6/3TDAgqr34uSAn4IxiANbqEE1JEU1RqDZ7BDcNuXvcu9y8 OySIkIU94kZxl6gQD9MUjip+OBi+AgsifH66b1WTgAASPF08rYB5elZLOqsmgWkyCSmrt5jBccVo 3LhkjFFmolGL0hALTe9IzFvsap+QGZ3AdCCzfsH25otcCbjpbt+4Mmz98sOvWaDCOWHm3XQlmxHr 2Hvqj5k+y6mkwZ3afye5Ke5lnqfcQ+5XPR94PkiqG91UXebCXYQ6MqNqXlVP9QqiMVcJ1UyPHaje BMV3d3WuWvsiPVb1PvknGatSrtGu8awt3aq9wbObPOnI4Zq01u1JkpLSbHUjmRKaXLka9961RICK s4lQrcej1sK7i/Mvr0YPu5Yjf1bQAG5sMIXGZQ1YQqXhQIjgnNVgDgiiF/NfmaoIVEqKpILoh8Zu HHTrdaGhsWukZUmNOoQTAea+1mSSpfZkstRA9AKkoD7jdtlxSK+FQ0FX6vYg7VGp1aXJFJBSLtwY VAilXg+7NuhWXZCiqSSuGLJbhQatSqevDInsMFmv06i11S6Xl7Tq6AvYREmuiUhY1BakhbHhA4Kl RmAWMHfpYBieiLPiM+31dI963aNez6h7eufijr/IYrMoOpnnytq4uhHEiOS27vI0Y61KJj2ZX0JO oKTvGynoSzJTbvR+y0nxv7gqin6Lz/q2CZomzXUvbxOaoMgVifpgKgQPW6iUwqUJ2oVs7luFu9vw EMsalxpSGH+gUlkFAzVTGwhWVshkd5jLZpO5b0mt+uNEjV3VWLiopJArfCdeaOuok7hzz8lWUt3v cGbY2sLd3hl0uDP/+mNUaJihPDfOx+KGnV8+zC8/c7fi/Ccnq+JxriSQuGb0Co7btW4GODTVqcMO 17rR67nOOW3+ZJaTJfPcsX/y7/Iv4eZLEzdVcqgEoVEREhqrpKaOmltq71A/UMs3M1KeP632QCO9 Xv1E5tmmg5mfZN4Mv5F5s/YvGW2tulM91TbVNaV2tmuJ5i7yQO3juKJ/QGOoxu8Nm+9T3J95sFJB mnuaFzr7m1e77nbspY9POEpPNus0zp7mtRP5Lg3nsDq4iewpL7saP5lIq6rhC1Gny0rTZfF0WbKp +pnqI9W8onpSdXf1ddW3VT9U/YPqF6p/Wf3H6pFq/QBsqol2TVizWHOlRsFpJmrO1Vyt2a55SPOE 5lXNHzRavcanGdDwdquGdxsTYho9JpdkJ3ZxVfeQvmyWc0vJdI3ZLbrnuVe6H3LvdR91q0+4P3Kf Aa9xSyahxs2Jak5vLhPLsmUtZYqyjmS7OS7GufiHhGS1LdqN2qNaRQiAI1oBJsAQPSIJUvOmZk5q 7m/mmvfAycjcs1JpT2nLmI/60qReqOfqq5RSNF6zUvmpkqtQSsoeZb9SofRMargAW7xyK5MufavS 3SOrTq9K/7gPTA2HsKuZcvE5kzSwDdNZ1EO1wDWWEWH09Cl4fJjsWS3bj+PHRThw1AhN8PUwH/vq 4ibdb3AH3Bxh7lpmcTRM8Ed1Aq8wxwOJcFyfaEyYgpYgMYS0Qfh7JvD1QSL4jUGqiyBqUEwMjnvv ZYODKaHM/UOxx+V9vgpmB8ri4/7fOPPqMHbKJNdXXmHIJ+YMkpXUqnoXcyokSiyyn4E5Fbgpz9zc s3yI1rqk0taU15+YMrHlgtWvX7H1AZdJZzd68X84VnT0zNFtmFgS9mSqdtyzbMaKZ75zyfL6ZMDq dojp0srOc6u7bpi8qi11T+EuKSzE3VPbp91FG8+ZWVdfHsUPoziSHjul8IFDu0gJnYk7QpM1xCW4 OOr2WGIiTpU/lnzRxI28OpjQ602rcVlJ7yJEYIdUaq81idXMT6tlQGrA7YSe5PEkV5GUkj3JgeTu ZC45nFQnTSZi9ogezpOyWHHLpgLe1x5hWDgODddTOn2VrCsWj6vA5AY94RYB3Q26QzLEv4phR069 TJA1ZgWYCuxY+hBJFlHZkxmqPJBx1M9l1x+UzFPMH5Tm4ZkHYyqusTeuMCrjsYTP6/dyKm0iFI8r IiU0YPAEidEk6pCOqhIl1GsMBklYEyz51hrLfiH4oaLXKQe0A6GNsbs1Tyqf0BxUaLZotmo5/HcO 3UZxY/xu5T0xFRTNVX291MKWmC24vLTQUOBnANcbt0FkFZPpLnTvulv7n+6/+vUbzl3X+EBErUtX 0xtVunMnVk+prCtpu1B57ujo1auO33zfFzdU1C1WPD7T5vdx8dHHCv0boxOnTHj25Bs9E5i8nY6T nHngYlHyD+nyz1Q0pqW92ieCr3CvRN+kH9I/cWqdhpZxKftF4hLtpeI67Trd6uA9tmdtz+I4+7D9 QPBw9JXgsbiFUIeN8Cb/cdzB5/CTwZMULnQ75WjY5nB73J/CP/d3d0KvDncp9Ga429OULUSVp4VB yae11OCCwW6aQwvv3vgn4BFmv+jn/FXqcTwGD5Sma46rKUvCtDDVqD2xhu/I2mQaWgk0SdkVBCrq PrVa9h6MrBLY8a8FxN3IVEvX2WsE7ORxVVymH2h9Z4/OZL2QzS6jOtAZNHpeEtteWXnk5JJr3rz9 mc6Gid1alcslVkRqZk2pn1Y5+x/uazdQ70+O3r73u3MaO6YvavF4qrsfuvEfE9PljFZmgFY6QStB WG9XS9F7jXuMh4wHnQqrtV5DgkKQc4kZrcb9iBh8Jcoul3Fq0M9++gj+n8kQvfigJn2jwaDRQzmf J3lcG8IJuxpd4ZYJ0yigvQluzp2SJ9CEmTTjH6pwOSiA3iwmCFTGwCCIjEF49kw1PdnjWW4guzvL ZUX4SiVGN5KDNT1LZccFheApb9gsT6rMRNmcgoZgZzOWijtk8k0WOEuZo1yQ77P0FUnmK6IpjaSM tlg8GseBZqK0JFnCqUzxiC1RQlJGRHFLuISWmNMyqRS9p6nNm0El2QHjgG0gMpDKZYezqgHTRus6 18boQPKazE2uHZl7jfc4Hyh7wolDhTLTJvN2C8fOj/vYL3gPkWyRuuU3BnXLEwDqZr33yvYbDHiX Q1nLqEq+9yAzUpm2orU2ecXPLnk9/2uVJtNQuPKclZMHl85a+tzS9qUTtYaKtm1TV8Td8WxNxlU6 e7ry3C9fv9weDinC3Xde2Lx7ywv3fHJ1TSv1rnAG/KnRm75jFx98eN/TCduO4i7g+0BjDhKitdJs lXWavc++0r7Usdi9wa6O657E759es/yK+xX/pvFNxz/5fxt1Gx3FQ/0L+SX8ysh6fmPkBv4m04fG vzm0Kc2Yk2q02jTbBiFcAuhThpyETnYO0dL9voRNrcT/fxg06LVOtrp6rK5T8kRqnMsI8gfYYoPs kRzUm2oYlNyWWuLNRloi8yKfRBSRULJooFfJXBX4MgxaizBRUSPvGgO203HowJ7wOAXKjrPi8Urf 5+k02yzpdPFQEIeDTNj2naLCa6tktgoxGYi7XR4Xp/JbxSDx2p247GLxBanLgQh2N1YOB9xQD9ki 44pAkRqLEo8toBVcUl0jm3EgVgffNzqmndM5v2lBQ+TcoQ3HV1w4+vR3fvVxNO6I1oQn0s8OX3Z+ +0XOBzbv3nz0Q+r44JGHrxKt1b0PRDEVbbir0gbLOkPT0lwpS1U2McaZcc9aVAlqRSqNA8CkRcAV UCsYflowG2Ki+pUIjYkq0KxP9LX4+L1QTaoSWxw0Y7qhDCiQx7osuwphzorZE1k+Cx2dutlcV3h8 Ne5gMiIBRnYls2+dyNDM7wlJjk96ynAcl8l+fxwc8vdGozUJp+7wIDpiUMomq2pChuMGDiqGocKw ybDLsNsA37tg6JeTxw2fGtQGHBxUZLny7M/Ch+kiuObhFlkFl9kqEHH3Kci4VadWQRWSU3/B4fXp H0NfYkYApppdjGxinrWWEdztwHUiqD/sdFE+8irGTC6CoJhLxOWsh+WH60UWXNGtLWG281eKCmxB yC12YO1yVDvoCXvowtE/tNTab76Z/mb/NeunTqqZpFIYBFeghNvBd46uv8QNNTxGfRXnctsXdGZ3 Dc9tyLTVhbV+i9mhM1fU7l2Pqw886S5M5t8GJVWQSfjN8+vSzLigN7eUxbdpb87ckXxOcUibTx4o /zT2WYdOV62tVTWqJoamKzUg26Q2KTaIXeKtmq2pB7RPZp5s10tdsbawMenGvwWcoI7Zm5PGrEHW 2L3Y7M2StbFZSpTUNEtBEZHDXVPRTFn1oNVd0zzEKyTcrpavewTq7zEYAlmOl7KVNfwQ75dwbpKu vCer7kwEzF2sCVy1DEo6jDbURbu63BOGxo7LrNc4gU6ocq/GBcTVoppmmXTjVVKyrE1CI0Tmlmwb NbeJbVxbV1hghYhQKFB2p5sThnilZE/UVIBQuRpqrhFruBopnEiXseeJKC2TSpM1ZUxhNpetLNtZ xveUHS/jytZ3Q11mt6WY0nmqia23MNIHKh6PR/tWncFuGZGLYeIx1QjXqtLMAZfF9bJ0dlwntkti uAaXgZgIxqdYiv/jgdeOY/owjHxArAEfZp4d2VAsQpa2NMq7CRowzq0dUabayopPiXzToboernV2 /QFMW74NUf/NixHqIg67IlSS4IsiGwKb5RLc9+jEwUqbe+XRqarVmUn1zT/49YxVSy/YvOf643M6 L9myfM1NV53M9U2d0DOjrqknE7pySbhx3aO3PGT2Xc4/eEVlad3ERXecr5yYjMH9LG294JZwZeVF FeVTPNLqzi0VlbuXbX+t+cqhu1Ze8dBga8WX/7CItdXnT233WIJOplFNxolcA2R+GT1xCP+Q8tO8 vlF2a2en1dYoJ3NcD/Nqq3Gh36lKqBRwVkVImWgUIkKZyrrXdNTE+SixxUTTEPe2ZImUxMRINKKN icZo1B8Tw0PcW9LCaGlMLItGqQ9NiXuJQh0Jh00mo04j4vpDym6Twq0tNqnznBqbNKnWJrUjNE5A pqISUUkponQGUSSGCLvbJsFRcMxGzTYash2zcYKN2pgpZh0up2J5rpzLlg+wmWiuZS8yiK5kiN5k iA5liJ5kWFYuQ8mESzLlpKjGpUpL2H40YWCfltBsyXDJcfxCiPVWP6FGhqAdGWJQMqo2EK4p8WSm F1URtrOwQ2VXv8Ay+IClwbBjfO2rT/Han+xDxn5lqp9cxTMGJp+yH8JVT1CwviXMhqPFcaeJnXnK ORuurZkY1zaxe6smdghmAlY+bB+/wyZ7g5lvYjU4IJzD0NWLyjrMMfm6BfOAyVabSs3Y4zfKoMC/ 1L2pc/Z1ydJJhUSVx2pN+0rPLTPbJhYSEz2Wkmbo6+/PbF+0bXfhjhW16lhMHfYupg+vnRiu7yzo F3kimlhMFXKu4A8sr9HEoVOkoF5GcS6ox93ftyVncJPF1WJmP/vxwzVkFfwqV0y0MmUyYoyJFpaI umOi/4j8L81UeHdLTV3NXhVVSYQa/CqrRadlM+JHadEWl/gkfmoin7im3C4J3bODwPyEWvnCbiha vGhuc8lQymYqanIuutNFZWPQdY0U7AlyYrA/uDuYCyqywZbgTiSGgyeDqsD0YTAeLBxuajLmAzWB +f3h7y1KIFxYZIVM0vzXZaJvzzPmNNE652JJmjPn9fL2gro5aC9vU14mF0jSxYWJo76F9YpYjIu4 FnIRJOOgzg5Q502gznL6kdTOhRyNh7gXTG9yH3BfGJUBrVef8EcikWi9/wLjIuMa43rLJuNtvtuN d5vvFp7y5o37zW8KfxPsHO58a71ea6lVWWR3UpgGU0l7siJLgwGzIq7JiOVED3JU2V2RuBhz4iYS O8R45ZVXWkZfwZ0D5mZj/DA72uST1uAQrhxncuUVUSXs5UDAHwya8PsFxCKuNok6p98lOpMxESeS uN0kah2CXXSIMTEajeI/n5VHo7zyxzhyo8NoNTlosqOhYDZfEvDjXM5vNgYDfvwMGf9kqkLE77V0 WhXMcuiI+cDFQeiMEu7PRZ0O3YmKTyq4jRW0AsqKo0NH34I7ZmAwqaO6Ibo3b1otHMa/GjHjSrLT 32MOiAEusB6/TDLjN2LYjamUbNILINosbPjjyZNJRdKTrXie8jjtnU5PFU978Zsh+TJ8E+TOqdFT p0/3jf5FOC37ICEDmPLh6RZOn3aPnmKqiGywsQM85oJUMBekfM7TRyzsIs437kN9M81ci02ygxEU zzyJ6BgeHEv9uHtQPsFV2yBqGHnK8oJXM2sPufGzPWysH/+hPVwm0Ueb5tyw5J2tUJ8LgVAgdaip tLkQGKfXMzf+rnWCzxfDBSm+etOiwo9edkew29wm/ADaPHGPTMXfIFnsPdyV4mLYewIBoVkZxfZb 8f+7qJn9rE8QcX4nCCo9FEuZbqFhQpMH3ULhFJCQnFG0VCl14wdoKYOeUSU8zowqGRjM1NTIENTJ oBQFeeb0dCd+CiB7na8RrbutOSuftbZYd1qHrSetSitrV1lTw+CBTHmNRSZOxly/RZ2yaniWKEG1 7ETs2zM2+DUJnvvluq8Ij391ASM8vD3+E7fqSuhuk7npkngOR61WUdIF6zVmG2kik0UbTITJKlpX 74mJcC28sT+SiYn473BvSPZIa0xsikbMMdEWjUolNBITS4a4Nw9GpYm0PiZORFpKRdti4uRoVB3J 1IXVVBFsqlqiCC7R6fB/nSermiaWlthtui4J+pCsiF0QjNSQrt1dua7hLkUXdrzJbBbNnDnl9UBk eph8fMhz1HPMw0uenfBEfRCOpMozqMrIVZmjmWP4p6aZnRku8wEx14twSqbaWtmcewORmv7Wk63c 7tZc63Arn0V0vJVv9ZzTNcSdPxhmAo0dYUNuydJMVsBw1DIOcZ2FKePgizI5sLPsFtAMHJVneYZ8 84FdgEinx+WabFLFspW+gN6oVFUk/IlKZXmQqtQBvTdIDcasqipIfYZg0bCC91F2QMp3z6bM2iBZ xZBGG4LrSilqwyUkFNaoKTt3hYSTzfJYf9fJLk5liBlqDFLX7/XKGcoZmunaGfrhLmUDN0M1w/AF /rMdbIJVq4vGeBe2lDMgT/Sg4GjBxbB/D0LIyhCiF7bMp0wEy9BiLJYDynmzvpgHlPPCeDtAlt+n x89sv/rASGTWvUMWw67/uzBmtsq4VxUC+r828GvdN0yfc3W4546e+WsyJaDzRp/Vng6kZ2csrtaC H7cJ7VlfaThbi7qgzAP4J6+Z1T7rwjk9vdvvLmy+rAYyWlnim0+/e11HuKWloFsM5yHET7TyPPrd jVLMIU4r6Ba2qGRJfhknyJK8qC/Wgy7SnILpi397Tt+oVdEM20sN02p7MlQJXTGu4v/A/Z7/nZd3 qGqhRfK/pyd8nNVsAndNiyYhLKT3mo+a8f9q/PaYaC7qjgnoi9GIDrqkrDviJ/ZvSY4oNMo07syG QmazSedZouQVapzjzxs8Ds/R0Nhz0oXuWroBXkyVTtYmcceSqZN27H2znYbsx+ycnamWdqiVdqZW 2qXaOkTQBu2MNuxMwbQz3dLOdEs70y0FO7UzhdIsZnIZLpsZANlAm2TvyLRJGaITGaIfGUKLlCF6 kyH6YlAyQ6vM+MfFTklJgpXJaiV+v5IYxi1cnhUxtVKGUCtlFG0gVpPwlH2tTsrapHzh4Ox2YucE Z9P/p6+rAY6jPM/77d7t/ezu3d7e/4/2Tro/nU7SSfbZlvyD1thItoVtAbaw4sg2tY2NwSBjnGIb Ry4ooVCKKQUH4skkpQwOnmkIkjEKZCZiSE2c6Qwekg5pO5NoWrehJqEGDIEaSX3eb0/C7t/NaL/d 0953u/d9++77Pu/zvMu9zTInJNCN+3J5H9zJpYR50YVBr6t9ygy+EBMaST/bp/STT8m3yKf0cySA fEo/+ZR+7HWNT4kQ6F7COACzERWlNps5yH+ViSWM6n/M2TdXjdy4+f6QjilZXBDVjXKif01xwXSx Nj0PruvZ2dv53PRTd3GXMh/fzr63f2n94Wnljg74mLg7zU5D3MNJ8/gq5qEm1LMNVuytBCuqzLjV 7StooAFGCy6PW6mzSAFiEdrosApI/kDAkgAxiNBG3vTYTRdvxjqXVeldKwfcdiJ7HmztrJXdlqVV ZHC+C4KJ30gbomGdVxi/caFf3qJras8AZFLixDw6erq4oAPIP+V28ONDIEq4ZM33JzUkl3XSAC2F bhTJmZUMyQsxnzYzpiiHguGgKMuFZCqRiqck2a8ZRZxlnckiHsMUYq66IguoviIzJZ/Jgt6oKaSc 0SK3NAQhAopqIigfGGV7I+tEybHV+kHVOSQPq8P6UPyofEw9ph+N/0w8m/YOu4Bi+odjx1xHtaP+ YzE3EUj2DcANAS8e0SwFs0QDjYImQ6kdgMxch0tYFps+9M7enYfe/cWFf397/uqoT1nV2mIWtVAh n5De/Pp7j771zedY45vnWLln7b/8/M7BnjXxhmVbWf2p4bowoc3F6TUO7IiAssLuA2W/4iYYSwgQ kKUH5GAFcBehV+RMKDUEqxYdIGfTMhJ1BQxEAnK+kFZk6BNKrGQloUG0x5caQpOptdpwFfa1n28X 29qt9r72oXZHu2HDhk2aAfyjTbXUPnUCYJVTjbddk7NR0Q1yNrDmPBFD7dU5mxrczFHddntX/s1A dfmBzOZsMAPIKcGI05IuSErbzGHQmUJzzIzny4U6MAKbY6UiK5hYNCVaiqwxlZ/DnvFBfpNbkrO6 eqpZWgzHhs3hwnCz477QcHyo7oHsUHG4/I3QY9njoW/FnjWfbTiReyH0YsOp3JnQj3PGyjDjODRx hfK4QDlPbM6RrA9j9cuEDiijfLxtcMzFXoq2dU+9zwMX9qft81f373px0+a/2bN2xbxF/X+0MFvt LFg7l2+dfn5VNYasdH10m/RPFMccXpWpPPivI4+/f7gh8fyhzg2/+2hgyZPkY/UCJLsbM6DEisCa CkqnElJ1+5KCQcYl9duxJLAY+unh86E9OppewDfrTPttv85bqxiKVPUyO648URaVOASNfqoHUUrX 6aZeklk4gvoCDchbcFc1ejYNKTRc1WwuXaLZVZf1zvNb5lJYvNSiLv8uusmgxIZZ5/UPCpA/boXy beurT7jOuyZJuM5esxSh5I+mIUttyhIBBvaEmrG2KufDjCUzNi8GbOrqRAMbmpXR/WPTOhvFsiNJ BJKIKX4P5Rt3WMkalMs0OUhtY88NhO21qBMuFnwp29zaCVY79UN4cpSuTG59baYvZeDODT62vGPF 8tYF61xerS5RCmeYS610TLuWld3eQpt08pd/sfWGrhVrVjrkSEPXbQfe7ejUk3HAms7OQ6KzL5IC XxxjdNPMBfGXGKN54inrq0pbGCo7XSuF9LqSQw5FQmfzZwv/oF/UP9ddJT3f1KEvbHpYeTr7dO5F 5a+z48rprALGkOYuhdUepVeVLQXie2NeWjghphmj+w7KKRtd36WbObsB9TBOGBW8Ua18XI6l4yeS 6UQCv+sZ7PIESJmobm2Z8RORjw3DWSi7DLNgKLXr2IJ4lW02gIxMnvaE5I20Ynk9IXGjLaVBL5ai +Kv2VgMhJdZi2O80FZLwV1mlur66tXpPdbj6UlWuGu4MdUJLcaPNCQOKWbXXGhKlRjoofNrfyGiV Z/ca4/PJ5JPFRzYBdDE0lMt9xZ3BbdRNu0XxEbcVqu9yLw1nsYjksYlzw4jjRTT/fZ/eS2mr2Y/W Z2y0Z9LyoI/6Lfg8TmxiDF3wFr3wFh1ROzrXV3ngQpmrHePMaozhR4bkkVl6EgtfFAstYn/pAIBS OkbTNP1d5vjMP4+pIbvFHrQ9it35wfH9fiQ44XIZ2NdpYkenib2codldiPCM2NWWJvyOy6v9Fcsb 6KpA2YAFzoVOk3ay96Jvzrfg0HCpnychJ1qcKlyPfAuALWz9wvJgJd8CvyQ/PvPhGMwp2guvwryq KZjlL73rAQG5Gm7aCJ29ikbnmAVpySVBNQ66hQF2xf1rTlGMNxaJT/kblj20vLQ4lGGFwXWP968Y MpX6SL3e0PKd7rZlS3c/23L9039+Y08yYERi0hvTbzy+e1EuGS+99Wf96473NSnzWN/IyJKmtu6e PR03b7/rpbzfD6YpEwozH4vHHVOoXvMMxHjKMVXkC0UV4uPsjBVnjlBICj8kMjmj0FMkJOVez06f QvJan1XnVM6oiSRz4LEmzjQk7k3BSPhgKBS08OsHaUrpiN8qwYng+aAUjCfIuhCdBBgVgAnuD8IB 5GUksCl0TV0YpCoy5BZeBluONOqoOQntAGTFXKKHjBXPKlOShORY47/+tb+gL19s3nRm4HDAe+jr L1/vmJo+tX3qJzdV6rZHJrYvazjOPs8O/BQuOBO6kD9ul04KDezJHwk5HN0LiAhy53OiR02qTepq 1dGpfjv1Ymo85fgPlNYRG4hzWU8LYApBIApBx29cbMbFCEzIZu0I2iRIOesEkhDf6UGdAKGhAT+A LMhNtTu4KZODL8Pjl+Hky+Tky+Tfy+Tay+Tay+Tpy+Tfyxw7lplfZhn5bVkED1kWAWC8bnlzFDfk 4Ofn6ApDJ7xFP7yFf0/taJP9b/TM30aX1FpxOBgTOZbO/TAnVnJDOTEHyIuFm/xkaMbQMW/h5fMW Xj616IwaKwhn/5KPVXwTvvM+yRfP1tz+muG3UeRZ75Euxv+GI+M2Ak297exzt5/7/CCnckiSpyTh rM9iIJRTRnoCkSXIabVRX7iIb0p/B7j3oRXfvGX94abidexIsJTM1TV2FK+TTk7lCCE60rf6tgef Y/spFpz6kx2LzWBiPbtciwyD8Mg/wOin2IiVMERUPTIEgznazIHoQKzPfFWdNC+ZLhiVo6PaAjQT ViGVrnZF1kf6Zcnlc6ehqmbRZCwdtUeFOdNyRA+nkRh+xNrjF1KZZCrV7ddDAB2ZIGzx+7DmS/mg QZf1DCyETtaS6Deinoz6kwARmTOFG6PLJcspQUn+QT/Y5rf8fX7JP+i7yEj3zW9BGTA58MSINHub SayPjmxs6foqP8Jktlg1Lc1f1Tk2PGk6dJP9EOch1sGXkMbq38AVR9A+jQpxTafilwcvx+yiLRR8 zSKn+BcRFG1wEOLyGEcJy9dQEGs6ydmG8OTyIBfbhQFjal0mWVBRD6S6GC0wdyZHQ528CVPz2Sgy bTwAIDPrZGTiwD+0SVkgHJLRsyUhjL0//bedmWgL+7ASiDV/+/CClk42r7mjA9pa8e8fyiY8+Xwg YuZvn/4rVnlwIdSJ+by8cGSqga7ywMwF5yjGuVm8FTUBAqwZ32ydhCgdGU+HElGiOp4RpDtclVAl Uol2hboiXdH1ofWR9dFNzk1Gv7nXebt3h7LbuDNyZ3SHeXv6a/oh40jkgeh+82Dm/uKx1mfKv5Lf E/7Nd7H5M+ET7yfKp74rzQXZKyuyz6E7Aw7Tau1r3dbqAeRsGIFgUPDqAJ3hPqdjDjA1yo3pop0T cAB7jgYzOLJgJB0FFypdsMZnvjYWkEREu/utO9JCc6bc3NydzoTS6UxQ8AhyWhS2pE1smg7JIzFp S4Drb4FWC2J3wIAW19BRGNPhaTaDBhPkgJJh72euQM1ZLqbLKKdJRTQdzNtcLMSiwK6bJVFQWmnO N9vpqEUddtopU2+nnWLxRLXVInIDzkl8qZW1At4rHsiARdNyxtoWGAKN93XWAoqsB1cMZ7+AgTgz 9xgkT7yldVzs5zNxljELw0Gc2cGrSbOcFVOD6WAk8JqbmvuwBkYhsWfnSLP75ni0X67RW+XyNbTZ 8rUS39rUtbm0NqrNIW3iRfAQyZyZpOwyOBmz7WdwEDoj7lBnFH/25MXURTHl2dlLYWcwiCzpHJf2 2qksXZgRrlQ/7yjG57NfteUyj4x4TWgnftNh1o3cnygsYuHWheXp/0yJP5i6WXzhRCXjy+ch9dk4 /Zdsb6y3RHh4PBrpxWbfqkQx58BMX/DAFIrNYaYjf/97zPQK2/4Kzy0h+pu0fgCxBZHF1ghrtFWJ gcRXkpta9yT2JHe3PpIcT/4s6WsMNoZQGDfRLXRru+Rdrl3qM5XvC99PvBvX0KtW0dSKT1ZB2AjH I+mwTrWbHWm4UZA6NYWLjbmyr1LpTsRDiUQcBQNi8LG0LVR2RPOB3FFfScRRo1VwhYsVIUerQNwS uYvlJ0x/7qKJLL8sO+WEoGxrn2y/1C5RFGppocZqO+aVP1yB6BGGy4o6S6VMsVpcibzmufqy4DwP 7yLe1v6lUQPoy0vlAHTiGG8ZHDUEr2TUAPCCckEIr50gB/m682F3a5nbNK4Fp6li06yN/08LDsqq G+Jk0KfLwiAM1v81xiLPqXO9A2VCbBCCfTT9zsrlrezD9sZ539u7pP061tm6eOX0Jzvbb9h9y66e 6rxljLnd/liycWFBfOU7qzDuYkOsMDT9JEt+a0m+GTbNuezlqd7pL5Zu2Lpi8Y3WClBA65qO08gD oMDj/k4KhtgEB12QIni83xXJoY3PvGd5wE2QMgk8qghbY2aG2ktWLygyi1E9ezceEHZAfVR8TDqu XSFuVK/Ura7UNkv96uvSzyWXqOPjB9SPRLHirngygYzRr76r/lb9A5hzokNNiiHVUcvSNaoisgBi QjwiPiq+IjpFjTnVsHpA/Yb6GoAKlBzv9spaN0OyDuOBoSDRKKguSNTh+SkGxr0z4O1yewJGAKeg asYO7T5tRHtKe147rZ3VLmifah5ti12BTGSSJnjUkIJHJkndimdcKlia4hUMHYCXwbyyQe80at2C eEZg3hClJgTgpGS5UPgvobjPQIawmUkHlJJRFmjS6aFOwYLx7UI9Y/Ee/KjjYn5UO8Dof14KnhD0 xYNAWntrt9F1IECvnSIydPkylewDY8/m+iAcwtxbi6zCBySVHdSXfsBV73SqdLa8Vs693MBoMCx0 wZCBgY+M9jUyOHwb4D5v/fz9yVFfcDbyevjIT6kv/Zx+TiA+v0CpXlAuydmqJeIldIgoBhbgkuXB 3VeMYYHuPng5iqw9Qo4yChAvYOAQyWDB1ocZBRXzpRVfvCOKx2/bUE1lpeC0aE2cKqci0obs2u1M T35x+m7gIISF8ddMPcQe/9trHt6kivFUQ1MX7GqZIczRCFjNVBczieqXdr3LRmTa2/DkgIWofr0Y 2eMbwO/oQXXs1dDu9CKntQ5PbuhDPfCb8eDTjUK/cCvqZg+gRjY9AYFeULTgj14y+hRWrd60bmVP ecMde3fuX7fzj2++Z+9td/fd0nL9PXftWLtB+C8Ye4ZHCmVuZHN0cmVhbQplbmRvYmoKMzUwIDAg b2JqCjIyNTg2CmVuZG9iagozNTEgMCBvYmoKPDwgL1R5cGUgL0ZvbnREZXNjcmlwdG9yIC9Bc2Nl bnQgODkxIC9DYXBIZWlnaHQgNjYyIC9EZXNjZW50IC0yMTYgL0ZsYWdzIDMyCi9Gb250QkJveCBb LTU1OCAtMzA3IDIwMDAgMTAyNl0gL0ZvbnROYW1lIC9ISVhOREcrVGltZXNOZXdSb21hblBTLUJv bGRNVCAvSXRhbGljQW5nbGUKMCAvU3RlbVYgMCAvQXZnV2lkdGggNDI3IC9MZWFkaW5nIDQyIC9N YXhXaWR0aCAyMDAwIC9YSGVpZ2h0IDQ1NyAvRm9udEZpbGUyCjM0OSAwIFIgPj4KZW5kb2JqCjM1 MiAwIG9iagpbIDI1MCAwIDAgNTAwIDAgMCAwIDAgMzMzIDMzMyAwIDAgMCAzMzMgMjUwIDI3OCA1 MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAKMCA1MDAgMCAzMzMgMCAwIDAgMCAwIDAgNzIyIDY2 NyA3MjIgMCA2NjcgMCA3NzggMCAwIDAgMCAwIDk0NCAwIDAgMCAwIDcyMgo1NTYgNjY3IDAgMCAx MDAwIDAgMCAwIDAgMCAwIDAgMCAwIDUwMCA1NTYgNDQ0IDU1NiA0NDQgMzMzIDUwMCA1NTYgMjc4 IDAgNTU2CjI3OCA4MzMgNTU2IDUwMCA1NTYgMCA0NDQgMzg5IDMzMyA1NTYgNTAwIDcyMiAwIDUw MCA0NDQgXQplbmRvYmoKMTIgMCBvYmoKPDwgL1R5cGUgL0ZvbnQgL1N1YnR5cGUgL1RydWVUeXBl IC9CYXNlRm9udCAvSElYTkRHK1RpbWVzTmV3Um9tYW5QUy1Cb2xkTVQKL0ZvbnREZXNjcmlwdG9y IDM1MSAwIFIgL1dpZHRocyAzNTIgMCBSIC9GaXJzdENoYXIgMzIgL0xhc3RDaGFyIDEyMiAvRW5j b2RpbmcKL01hY1JvbWFuRW5jb2RpbmcgPj4KZW5kb2JqCjM1MyAwIG9iagooNmxvd3BhbiBJRVRG IDcyKQplbmRvYmoKMzU0IDAgb2JqCihNYWMgT1MgWCAxMC42LjUgUXVhcnR6IFBERkNvbnRleHQp CmVuZG9iagozNTUgMCBvYmoKKENhcnN0ZW4gQm9ybWFubikKZW5kb2JqCjM1NiAwIG9iagooQXBw bGUgS2V5bm90ZSA1LjAuNCkKZW5kb2JqCjM1NyAwIG9iagooRDoyMDEwMTEyNDE0NDE0MlowMCcw MCcpCmVuZG9iagoxIDAgb2JqCjw8IC9UaXRsZSAzNTMgMCBSIC9BdXRob3IgMzU1IDAgUiAvUHJv ZHVjZXIgMzU0IDAgUiAvQ3JlYXRvciAzNTYgMCBSIC9DcmVhdGlvbkRhdGUKMzU3IDAgUiAvTW9k RGF0ZSAzNTcgMCBSID4+CmVuZG9iagp4cmVmCjAgMzU4CjAwMDAwMDAwMDAgNjU1MzUgZiAKMDAw MDM1NjQzMiAwMDAwMCBuIAowMDAwMDAxMDA0IDAwMDAwIG4gCjAwMDAxODk0NjIgMDAwMDAgbiAK MDAwMDAwMDAyMiAwMDAwMCBuIAowMDAwMDAwOTg1IDAwMDAwIG4gCjAwMDAwMDExMjMgMDAwMDAg biAKMDAwMDAwMjE3MyAwMDAwMCBuIAowMDAwMDAzMDY5IDAwMDAwIG4gCjAwMDAyNjIzMDUgMDAw MDAgbiAKMDAwMDIwMTMwNSAwMDAwMCBuIAowMDAwMjQ2NDEyIDAwMDAwIG4gCjAwMDAzNTYwMzcg MDAwMDAgbiAKMDAwMDMwMjIyNSAwMDAwMCBuIAowMDAwMzI1OTk3IDAwMDAwIG4gCjAwMDAxOTA4 MjUgMDAwMDAgbiAKMDAwMDAwMTI5NyAwMDAwMCBuIAowMDAwMTkzNTg4IDAwMDAwIG4gCjAwMDAx OTMzODQgMDAwMDAgbiAKMDAwMDE5MzIyNCAwMDAwMCBuIAowMDAwMTkzMDE0IDAwMDAwIG4gCjAw MDAwMDEzNDUgMDAwMDAgbiAKMDAwMDAwMjE1MyAwMDAwMCBuIAowMDAwMDAyMjA5IDAwMDAwIG4g CjAwMDAwMDMwNDkgMDAwMDAgbiAKMDAwMDAwNDE3NSAwMDAwMCBuIAowMDAwMDAzMTA1IDAwMDAw IG4gCjAwMDAwMDQxNTUgMDAwMDAgbiAKMDAwMDAwNDI4MiAwMDAwMCBuIAowMDAwMDAwMDAwIDAw MDAwIG4gCjAwMDAyNzU0NTcgMDAwMDAgbiAKMDAwMDE5MTUyNSAwMDAwMCBuIAowMDAwMDA2MDE5 IDAwMDAwIG4gCjAwMDAwMDQ0NzAgMDAwMDAgbiAKMDAwMDAwNTk5OCAwMDAwMCBuIAowMDAwMDA2 MTQxIDAwMDAwIG4gCjAwMDAxOTE4NTcgMDAwMDAgbiAKMDAwMDAwNjMyOSAwMDAwMCBuIAowMDAw MTkyODUzIDAwMDAwIG4gCjAwMDAxOTI2MjggMDAwMDAgbiAKMDAwMDAwNzU2NCAwMDAwMCBuIAow MDAwMDA2MzYzIDAwMDAwIG4gCjAwMDAwMDc1NDMgMDAwMDAgbiAKMDAwMDAwNzY3MSAwMDAwMCBu IAowMDAwMTkwNDkzIDAwMDAwIG4gCjAwMDAwMDkwNDcgMDAwMDAgbiAKMDAwMDAwNzgzMyAwMDAw MCBuIAowMDAwMDA5MDI2IDAwMDAwIG4gCjAwMDAwMDkxNTQgMDAwMDAgbiAKMDAwMDE5MTE5NiAw MDAwMCBuIAowMDAwMDA5ODkzIDAwMDAwIG4gCjAwMDAwMDkzMTYgMDAwMDAgbiAKMDAwMDAwOTg3 MyAwMDAwMCBuIAowMDAwMDEwMDAwIDAwMDAwIG4gCjAwMDAwMTAxNzUgMDAwMDAgbiAKMDAwMDAx MjYwMCAwMDAwMCBuIAowMDAwMjIwNTg2IDAwMDAwIG4gCjAwMDAxOTE0NDMgMDAwMDAgbiAKMDAw MDAxMzQ4MSAwMDAwMCBuIAowMDAwMDEyNjIxIDAwMDAwIG4gCjAwMDAwMTM0NjEgMDAwMDAgbiAK MDAwMDAxNDY2MSAwMDAwMCBuIAowMDAwMDEzNTE4IDAwMDAwIG4gCjAwMDAwMTQ2NDAgMDAwMDAg biAKMDAwMDAxNDc2OCAwMDAwMCBuIAowMDAwMDE0OTU2IDAwMDAwIG4gCjAwMDAwMTczODEgMDAw MDAgbiAKMDAwMDI1MzgwNyAwMDAwMCBuIAowMDAwMTkxMDcyIDAwMDAwIG4gCjAwMDAwMTg3OTEg MDAwMDAgbiAKMDAwMDAxNzQwMiAwMDAwMCBuIAowMDAwMDE4NzcwIDAwMDAwIG4gCjAwMDAwMTg4 OTggMDAwMDAgbiAKMDAwMDAxOTA3MyAwMDAwMCBuIAowMDAwMDIxNDk4IDAwMDAwIG4gCjAwMDAx OTEyNzggMDAwMDAgbiAKMDAwMDAyMjgwOSAwMDAwMCBuIAowMDAwMTg5NTg2IDAwMDAwIG4gCjAw MDAwMjE1MTkgMDAwMDAgbiAKMDAwMDAyMjc4OCAwMDAwMCBuIAowMDAwMDIyOTE3IDAwMDAwIG4g CjAwMDAwMjMwOTIgMDAwMDAgbiAKMDAwMDAyNTUxNyAwMDAwMCBuIAowMDAwMTkwODY0IDAwMDAw IG4gCjAwMDAwMjY5MzcgMDAwMDAgbiAKMDAwMDAyNTUzOCAwMDAwMCBuIAowMDAwMDI2OTE2IDAw MDAwIG4gCjAwMDAwMjcwNDUgMDAwMDAgbiAKMDAwMDAyNzIyMCAwMDAwMCBuIAowMDAwMDI5NjQ1 IDAwMDAwIG4gCjAwMDAxOTA1MzMgMDAwMDAgbiAKMDAwMDAzMDk3MCAwMDAwMCBuIAowMDAwMDI5 NjY2IDAwMDAwIG4gCjAwMDAwMzA5NDkgMDAwMDAgbiAKMDAwMDAzMTA3OCAwMDAwMCBuIAowMDAw MDMxMjUzIDAwMDAwIG4gCjAwMDAwMzM2NzggMDAwMDAgbiAKMDAwMDE5MTczMyAwMDAwMCBuIAow MDAwMDM0NDgwIDAwMDAwIG4gCjAwMDAwMzM2OTkgMDAwMDAgbiAKMDAwMDAzNDQ1OSAwMDAwMCBu IAowMDAwMDM0NTg5IDAwMDAwIG4gCjAwMDAwMzQ3NjYgMDAwMDAgbiAKMDAwMDAzNzE5MyAwMDAw MCBuIAowMDAwMTkxNDAyIDAwMDAwIG4gCjAwMDAwMzgwNzEgMDAwMDAgbiAKMDAwMDAzNzIxNSAw MDAwMCBuIAowMDAwMDM4MDUwIDAwMDAwIG4gCjAwMDAwMzgxODIgMDAwMDAgbiAKMDAwMDAzODM1 OSAwMDAwMCBuIAowMDAwMDQwNzg2IDAwMDAwIG4gCjAwMDAxOTEwMzAgMDAwMDAgbiAKMDAwMDA0 MjAzNCAwMDAwMCBuIAowMDAwMDQwODA4IDAwMDAwIG4gCjAwMDAwNDIwMTIgMDAwMDAgbiAKMDAw MDA0MjE0NSAwMDAwMCBuIAowMDAwMDQyMzIyIDAwMDAwIG4gCjAwMDAwNDQ3NDkgMDAwMDAgbiAK MDAwMDE5MDY1NyAwMDAwMCBuIAowMDAwMDQ2MjI5IDAwMDAwIG4gCjAwMDAwNDQ3NzEgMDAwMDAg biAKMDAwMDA0NjIwNyAwMDAwMCBuIAowMDAwMDQ2MzU2IDAwMDAwIG4gCjAwMDAwNDY1ODcgMDAw MDAgbiAKMDAwMDA0OTAxNCAwMDAwMCBuIAowMDAwMTkwMzI1IDAwMDAwIG4gCjAwMDAwNDY1MzQg MDAwMDAgbiAKMDAwMDE5MjQ2NiAwMDAwMCBuIAowMDAwMTkyMzA0IDAwMDAwIG4gCjAwMDAxOTIx NDIgMDAwMDAgbiAKMDAwMDE5MTg5NyAwMDAwMCBuIAowMDAwMDQ5ODI5IDAwMDAwIG4gCjAwMDAw NDkwMzYgMDAwMDAgbiAKMDAwMDA0OTgwOCAwMDAwMCBuIAowMDAwMDQ5OTQwIDAwMDAwIG4gCjAw MDAwNTAxMDUgMDAwMDAgbiAKMDAwMDA1MjUzMiAwMDAwMCBuIAowMDAwMTkxNjA3IDAwMDAwIG4g CjAwMDAwNTM3NzEgMDAwMDAgbiAKMDAwMDE4OTcxNiAwMDAwMCBuIAowMDAwMDUyNTU0IDAwMDAw IG4gCjAwMDAwNTM3NDkgMDAwMDAgbiAKMDAwMDA1Mzg4MyAwMDAwMCBuIAowMDAwMTkxODE1IDAw MDAwIG4gCjAwMDAwNTQ1NDUgMDAwMDAgbiAKMDAwMDA1NDA0NiAwMDAwMCBuIAowMDAwMDU0NTI0 IDAwMDAwIG4gCjAwMDAwNTQ2NTcgMDAwMDAgbiAKMDAwMDA1NDgzNSAwMDAwMCBuIAowMDAwMDU3 MjYyIDAwMDAwIG4gCjAwMDAxOTA2OTkgMDAwMDAgbiAKMDAwMDA1ODQzOCAwMDAwMCBuIAowMDAw MDU3Mjg0IDAwMDAwIG4gCjAwMDAwNTg0MTYgMDAwMDAgbiAKMDAwMDA1ODU1MCAwMDAwMCBuIAow MDAwMTkwMzY3IDAwMDAwIG4gCjAwMDAwNjA5MTggMDAwMDAgbiAKMDAwMDA1ODcyNiAwMDAwMCBu IAowMDAwMDYwODk2IDAwMDAwIG4gCjAwMDAwNjEwMzAgMDAwMDAgbiAKMDAwMDEzNTYxMyAwMDAw MCBuIAowMDAwMTM4MDQwIDAwMDAwIG4gCjAwMDAwNjEyMjQgMDAwMDAgbiAKMDAwMDEzNTU5MCAw MDAwMCBuIAowMDAwMjcxODQ1IDAwMDAwIG4gCjAwMDAxOTEzMTggMDAwMDAgbiAKMDAwMDEzODk4 NCAwMDAwMCBuIAowMDAwMTM4MDYyIDAwMDAwIG4gCjAwMDAxMzg5NjMgMDAwMDAgbiAKMDAwMDEz OTA5NiAwMDAwMCBuIAowMDAwMTkwOTA0IDAwMDAwIG4gCjAwMDAxNDEwMzQgMDAwMDAgbiAKMDAw MDEzOTI0NiAwMDAwMCBuIAowMDAwMTQxMDEyIDAwMDAwIG4gCjAwMDAxNDExNDYgMDAwMDAgbiAK MDAwMDE5MDU3MyAwMDAwMCBuIAowMDAwMTQyMDAyIDAwMDAwIG4gCjAwMDAxNDEzMzUgMDAwMDAg biAKMDAwMDE0MTk4MSAwMDAwMCBuIAowMDAwMTQyMTE0IDAwMDAwIG4gCjAwMDAxNDIyNzkgMDAw MDAgbiAKMDAwMDE0NDcwNiAwMDAwMCBuIAowMDAwMTkxNzczIDAwMDAwIG4gCjAwMDAxNDU5NDMg MDAwMDAgbiAKMDAwMDE0NDcyOCAwMDAwMCBuIAowMDAwMTQ1OTIxIDAwMDAwIG4gCjAwMDAxNDYw NTUgMDAwMDAgbiAKMDAwMDE5MDc4MyAwMDAwMCBuIAowMDAwMTQ2Nzk0IDAwMDAwIG4gCjAwMDAx ODk4NTEgMDAwMDAgbiAKMDAwMDE0NjIxOCAwMDAwMCBuIAowMDAwMTQ2NzczIDAwMDAwIG4gCjAw MDAxNDY5MDYgMDAwMDAgbiAKMDAwMDE0NzA4NCAwMDAwMCBuIAowMDAwMTQ5NTExIDAwMDAwIG4g CjAwMDAxOTA2MTUgMDAwMDAgbiAKMDAwMDE1MDU1NCAwMDAwMCBuIAowMDAwMTQ5NTMzIDAwMDAw IG4gCjAwMDAxNTA1MzMgMDAwMDAgbiAKMDAwMDE1MDY2NiAwMDAwMCBuIAowMDAwMTUwODMxIDAw MDAwIG4gCjAwMDAxNTMyNTggMDAwMDAgbiAKMDAwMDE5MDI4MyAwMDAwMCBuIAowMDAwMTU0NDU4 IDAwMDAwIG4gCjAwMDAxNTMyODAgMDAwMDAgbiAKMDAwMDE1NDQzNiAwMDAwMCBuIAowMDAwMTU0 NTcwIDAwMDAwIG4gCjAwMDAxNTQ3NDggMDAwMDAgbiAKMDAwMDE1NzE3NSAwMDAwMCBuIAowMDAw MTkxNTY1IDAwMDAwIG4gCjAwMDAxNTk0MjkgMDAwMDAgbiAKMDAwMDE1NzE5NyAwMDAwMCBuIAow MDAwMTU5NDA3IDAwMDAwIG4gCjAwMDAxNTk1NDEgMDAwMDAgbiAKMDAwMDE1OTcxOSAwMDAwMCBu IAowMDAwMTYyMTQ2IDAwMDAwIG4gCjAwMDAxOTEyMzYgMDAwMDAgbiAKMDAwMDE2MzE0OCAwMDAw MCBuIAowMDAwMTYyMTY4IDAwMDAwIG4gCjAwMDAxNjMxMjcgMDAwMDAgbiAKMDAwMDE2MzI2MCAw MDAwMCBuIAowMDAwMTYzNDM4IDAwMDAwIG4gCjAwMDAxNjU4NjUgMDAwMDAgbiAKMDAwMDE5MDc0 MSAwMDAwMCBuIAowMDAwMTY3Mjk5IDAwMDAwIG4gCjAwMDAxNjU4ODcgMDAwMDAgbiAKMDAwMDE2 NzI3NyAwMDAwMCBuIAowMDAwMTY3NDExIDAwMDAwIG4gCjAwMDAxNjc1ODkgMDAwMDAgbiAKMDAw MDE3MDAxNiAwMDAwMCBuIAowMDAwMTkwNDA5IDAwMDAwIG4gCjAwMDAxNzExNDEgMDAwMDAgbiAK MDAwMDE3MDAzOCAwMDAwMCBuIAowMDAwMTcxMTE5IDAwMDAwIG4gCjAwMDAxNzEyNTMgMDAwMDAg biAKMDAwMDE3MTQxOCAwMDAwMCBuIAowMDAwMTczODQ1IDAwMDAwIG4gCjAwMDAxOTE2NDkgMDAw MDAgbiAKMDAwMDE3NDcwMiAwMDAwMCBuIAowMDAwMTczODY3IDAwMDAwIG4gCjAwMDAxNzQ2ODEg MDAwMDAgbiAKMDAwMDE3NDgxNCAwMDAwMCBuIAowMDAwMTc0OTk0IDAwMDAwIG4gCjAwMDAxNzc0 MjEgMDAwMDAgbiAKMDAwMDIxMDEwOCAwMDAwMCBuIAowMDAwMTkxMzYwIDAwMDAwIG4gCjAwMDAx NzgxMDUgMDAwMDAgbiAKMDAwMDE4OTk4NiAwMDAwMCBuIAowMDAwMTc3NDQzIDAwMDAwIG4gCjAw MDAxNzgwODQgMDAwMDAgbiAKMDAwMDE3ODIxNyAwMDAwMCBuIAowMDAwMTc4MzgyIDAwMDAwIG4g CjAwMDAxODA4MDkgMDAwMDAgbiAKMDAwMDE5MDk0NiAwMDAwMCBuIAowMDAwMTgyMDQ2IDAwMDAw IG4gCjAwMDAxODA4MzEgMDAwMDAgbiAKMDAwMDE4MjAyNCAwMDAwMCBuIAowMDAwMTgyMTU4IDAw MDAwIG4gCjAwMDAxOTE0ODMgMDAwMDAgbiAKMDAwMDE4MzIwNCAwMDAwMCBuIAowMDAwMTgyMzIx IDAwMDAwIG4gCjAwMDAxODMxODMgMDAwMDAgbiAKMDAwMDE4MzMxNiAwMDAwMCBuIAowMDAwMTkw NDUxIDAwMDAwIG4gCjAwMDAxODQyODQgMDAwMDAgbiAKMDAwMDE4MzQ5MiAwMDAwMCBuIAowMDAw MTg0MjYzIDAwMDAwIG4gCjAwMDAxODQzOTYgMDAwMDAgbiAKMDAwMDE5MTExMiAwMDAwMCBuIAow MDAwMTg2MTA3IDAwMDAwIG4gCjAwMDAxODQ1NzIgMDAwMDAgbiAKMDAwMDE4NjA4NSAwMDAwMCBu IAowMDAwMTg2MjE5IDAwMDAwIG4gCjAwMDAzMzI1OTYgMDAwMDAgbiAKMDAwMDE5MTY5MSAwMDAw MCBuIAowMDAwMTg3NjU1IDAwMDAwIG4gCjAwMDAxODY0MjIgMDAwMDAgbiAKMDAwMDE4NzYzMyAw MDAwMCBuIAowMDAwMTg3NzY3IDAwMDAwIG4gCjAwMDAxOTExNTQgMDAwMDAgbiAKMDAwMDE4OTE3 MyAwMDAwMCBuIAowMDAwMTg3OTU3IDAwMDAwIG4gCjAwMDAxODkxNTEgMDAwMDAgbiAKMDAwMDE4 OTI4NSAwMDAwMCBuIAowMDAwMTkwOTg4IDAwMDAwIG4gCjAwMDAxOTAxMTMgMDAwMDAgbiAKMDAw MDE5MDIzMCAwMDAwMCBuIAowMDAwMTkyMDAxIDAwMDAwIG4gCjAwMDAxOTIwNTkgMDAwMDAgbiAK MDAwMDE5MjI0NiAwMDAwMCBuIAowMDAwMTkyNDA4IDAwMDAwIG4gCjAwMDAxOTI1NzAgMDAwMDAg biAKMDAwMDE5MjczMSAwMDAwMCBuIAowMDAwMTkyNzg5IDAwMDAwIG4gCjAwMDAxOTI5NTYgMDAw MDAgbiAKMDAwMDE5MzExNiAwMDAwMCBuIAowMDAwMTkzMTc0IDAwMDAwIG4gCjAwMDAxOTMzMjYg MDAwMDAgbiAKMDAwMDE5MzQ4NyAwMDAwMCBuIAowMDAwMTkzNTQ1IDAwMDAwIG4gCjAwMDAxOTM2 OTEgMDAwMDAgbiAKMDAwMDE5Mzc0OSAwMDAwMCBuIAowMDAwMjAwODEyIDAwMDAwIG4gCjAwMDAy MDA4MzQgMDAwMDAgbiAKMDAwMDIwMTA4MiAwMDAwMCBuIAowMDAwMjAxNDg5IDAwMDAwIG4gCjAw MDAyMDk0MjQgMDAwMDAgbiAKMDAwMDIwOTQ0NiAwMDAwMCBuIAowMDAwMjA5NjY5IDAwMDAwIG4g CjAwMDAyMTAyODQgMDAwMDAgbiAKMDAwMDIyMDA1MSAwMDAwMCBuIAowMDAwMjIwMDczIDAwMDAw IG4gCjAwMDAyMjAzMzEgMDAwMDAgbiAKMDAwMDIyMDc2OCAwMDAwMCBuIAowMDAwMjQ1NzUxIDAw MDAwIG4gCjAwMDAyNDU3NzQgMDAwMDAgbiAKMDAwMDI0NjAzNSAwMDAwMCBuIAowMDAwMjQ2NTk3 IDAwMDAwIG4gCjAwMDAyNTM0NjAgMDAwMDAgbiAKMDAwMDI1MzQ4MiAwMDAwMCBuIAowMDAwMjUz NzM4IDAwMDAwIG4gCjAwMDAyNTM5ODYgMDAwMDAgbiAKMDAwMDI2MTc5OSAwMDAwMCBuIAowMDAw MjYxODIxIDAwMDAwIG4gCjAwMDAyNjIwNjQgMDAwMDAgbiAKMDAwMDI2MjQ4MyAwMDAwMCBuIAow MDAwMjcxMzUxIDAwMDAwIG4gCjAwMDAyNzEzNzMgMDAwMDAgbiAKMDAwMDI3MTYyNCAwMDAwMCBu IAowMDAwMjcyMDIxIDAwMDAwIG4gCjAwMDAyNzQ4MTYgMDAwMDAgbiAKMDAwMDI3NDgzOCAwMDAw MCBuIAowMDAwMjc1MDgyIDAwMDAwIG4gCjAwMDAyNzUxMTUgMDAwMDAgbiAKMDAwMDI3NTQzNiAw MDAwMCBuIAowMDAwMjc1NjMyIDAwMDAwIG4gCjAwMDAzMDE0MDYgMDAwMDAgbiAKMDAwMDMwMTQy OSAwMDAwMCBuIAowMDAwMzAxNjgwIDAwMDAwIG4gCjAwMDAzMDI0MDAgMDAwMDAgbiAKMDAwMDMy NTE4MSAwMDAwMCBuIAowMDAwMzI1MjA0IDAwMDAwIG4gCjAwMDAzMjU0NjAgMDAwMDAgbiAKMDAw MDMyNjE3NyAwMDAwMCBuIAowMDAwMzMxOTcxIDAwMDAwIG4gCjAwMDAzMzE5OTMgMDAwMDAgbiAK MDAwMDMzMjI0OCAwMDAwMCBuIAowMDAwMzMyMjczIDAwMDAwIG4gCjAwMDAzMzI1NzUgMDAwMDAg biAKMDAwMDMzMjc2NyAwMDAwMCBuIAowMDAwMzU1NDQ2IDAwMDAwIG4gCjAwMDAzNTU0NjkgMDAw MDAgbiAKMDAwMDM1NTczNSAwMDAwMCBuIAowMDAwMzU2MjI3IDAwMDAwIG4gCjAwMDAzNTYyNjIg MDAwMDAgbiAKMDAwMDM1NjMxNSAwMDAwMCBuIAowMDAwMzU2MzUwIDAwMDAwIG4gCjAwMDAzNTYz ODkgMDAwMDAgbiAKdHJhaWxlcgo8PCAvU2l6ZSAzNTggL1Jvb3QgMjg2IDAgUiAvSW5mbyAxIDAg UiAvSUQgWyA8NWJkOTQ5MjhhYjI2NzVkN2RlNWVmNjZjY2MwZGYzOTI+Cjw1YmQ5NDkyOGFiMjY3 NWQ3ZGU1ZWY2NmNjYzBkZjM5Mj4gXSA+PgpzdGFydHhyZWYKMzU2NTU4CiUlRU9GCg== --Apple-Mail-35-917891435-- From pab@peoplepowerco.com Wed Nov 24 06:58:17 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7A4728C10D for ; Wed, 24 Nov 2010 06:58:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.994 X-Spam-Level: X-Spam-Status: No, score=-1.994 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5OJ+t4-UDLjo for ; Wed, 24 Nov 2010 06:58:17 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id 2081A3A6969 for ; Wed, 24 Nov 2010 06:58:17 -0800 (PST) Received: by pzk12 with SMTP id 12so393650pzk.31 for ; Wed, 24 Nov 2010 06:59:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.103.4 with SMTP id i4mr3100636fao.70.1290610755719; Wed, 24 Nov 2010 06:59:15 -0800 (PST) Received: by 10.223.70.198 with HTTP; Wed, 24 Nov 2010 06:59:15 -0800 (PST) Date: Wed, 24 Nov 2010 08:59:15 -0600 Message-ID: From: Peter Bigot To: core Content-Type: multipart/alternative; boundary=20cf30433f16a358410495cdbb3d Subject: [core] use of /.well-known/core X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 14:58:18 -0000 --20cf30433f16a358410495cdbb3d Content-Type: text/plain; charset=ISO-8859-1 A question has arisen regarding whether /.well-known/core is a namespace, and what that means. My understanding is that it is proposed to be a URI path prefix to allow access to resources with standardized purposes related to Constrained RESTful Environments. The most conservative interpretation of /.well-known/core reserves the unadorned prefix as the location for retrieving a list of (some of) the resources hosted in the server. The meaning of other URIs with the same prefix are left up to the server. In an aside, I'd proposed moving that to /.well-known/core/ld so that the same prefix can be shared for other purposes. Whether /.well-known/core/ld itself is specified to define (implicitly) the meaning of URIs where it is a prefix is a separate issue. The major impact of this is that existing implementations must recognize a slightly longer path as the entrypoint to the resource list. My opinion is there are a lot of other basic capabilities that are likely to be standardized for CoRE-relevant environments now and in the future, and keeping the option of putting them under /.well-known/core rather than having to obtain new paths from IESG for each of them makes a lot of sense. A standard set of resources related to network management and cross-vendor building automation standard entry-points are two examples. For extensibility, I think it should be treated as a namespace, with specific extensions reserved for specific standardized roles. One of those roles might be /.well-known/core/vendor in which the server could do whatever it wants, so as not to inhibit innovation and to allow prototyping of proposed roles. Peter --20cf30433f16a358410495cdbb3d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable A question has arisen regarding whether /.well-known/core is a namespace, a= nd what that means.=A0 My understanding is that it is proposed to be a URI = path prefix to allow access to resources with standardized purposes related= to Constrained RESTful Environments.

    The most conservative interpretation of /.well-known/core reserves the = unadorned prefix as the location for retrieving a list of (some of) the res= ources hosted in the server.=A0 The meaning of other URIs with the same pre= fix are left up to the server.

    In an aside, I'd proposed moving that to /.well-known/core/ld so th= at the same prefix can be shared for other purposes.=A0 Whether /.well-know= n/core/ld itself is specified to define (implicitly) the meaning of URIs wh= ere it is a prefix is a separate issue.=A0 The major impact of this is that= existing implementations must recognize a slightly longer path as the entr= ypoint to the resource list.

    My opinion is there are a lot of other basic capabilities that are like= ly to be standardized for CoRE-relevant environments now and in the future,= and keeping the option of putting them under /.well-known/core rather than= having to obtain new paths from IESG for each of them makes a lot of sense= .=A0 A standard set of resources related to network management and cross-ve= ndor building automation standard entry-points are two examples.

    For extensibility, I think it should be treated as a namespace, with sp= ecific extensions reserved for specific standardized roles.=A0 One of those= roles might be /.well-known/core/vendor in which the server could do whate= ver it wants, so as not to inhibit innovation and to allow prototyping of p= roposed roles.

    Peter
    --20cf30433f16a358410495cdbb3d-- From cabo@tzi.org Thu Nov 25 00:31:37 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1A353A69C7 for ; Thu, 25 Nov 2010 00:31:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.392 X-Spam-Level: X-Spam-Status: No, score=-106.392 tagged_above=-999 required=5 tests=[AWL=-0.143, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTOIo4Vn4LmK for ; Thu, 25 Nov 2010 00:31:34 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 831E53A6AB6 for ; Thu, 25 Nov 2010 00:31:33 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id oAP8WOgw005078 for ; Thu, 25 Nov 2010 09:32:24 +0100 (CET) Received: from [192.168.217.101] (p5489D53B.dip.t-dialin.net [84.137.213.59]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 6CA38177; Thu, 25 Nov 2010 09:32:23 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/mixed; boundary=Apple-Mail-7-981613673 From: Carsten Bormann In-Reply-To: <7925360F-9E9E-41F8-8053-9AF6F244C7A9@tzi.org> Date: Thu, 25 Nov 2010 09:32:22 +0100 Message-Id: <3D12C908-FD0A-41A3-93A7-5679EC70AE87@tzi.org> References: <7925360F-9E9E-41F8-8053-9AF6F244C7A9@tzi.org> To: Constrained RESTful Environments WG X-Mailer: Apple Mail (2.1082) Subject: Re: [core] CoRE WG webex call on Nov 24, 1500 UTC X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 08:31:37 -0000 --Apple-Mail-7-981613673 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I took some rough minutes from the call, which are attached. (Please note any corrections and additions to the list or directly to = myself.) Klaus has volunteered to generate/update tickets from this. Thanks = Klaus! Obviously, we'll need to validate those tickets on the mailing list. Gruesse, Carsten --Apple-Mail-7-981613673 Content-Disposition: attachment; filename=2010-11-24.txt Content-Type: text/plain; name="2010-11-24.txt" Content-Transfer-Encoding: quoted-printable 2010-11-24 CoRE WG Minutes from 2010-11-24 Webex phone call (taken by Carsten Bormann) (Consolidated slides have been sent to mailing list, see attachment to http://www.ietf.org/mail-archive/web/core/current/msg01278.html) 15:00 Meeting official start (Carsten scrambles with the host key and eventually gives up.) Carsten goes quickly through the regularia and hands the floor to Zach (slide 6). #53 (slide 8): Peter: You can't stop someone from putting state into the token. Carsten points back to the recent DNS discussion (DNS is another UDP-based protocol), where not having enough bits for correlating a response to a request has indeed turned out to be a problem. Assuming 2 bytes of sequence numbering, 6 bytes of protection should be = enough. Given that 18 bytes are needed for the transport address (IP address/port), 8 bytes also are not out of line. There is agreement in the call that 0 to 8 bytes is the right size. #71 (slide 9) No comment #72: Fielding's dissertation uses the term "gateway" for what is commonly known as "reverse proxy". Peter points out that the distinction between that and a "proxy" is important, as the client intentionally chooses to use a "proxy"; i.e. the choice of proxy is not reflected in the URI, while a "reverse proxy" is typically the authority identified in the client-visible URI. Carsten and Zach agree that the term gateway has too broad connotations, that actually the term "gateway brings up fear ...", so it would be good to have a term that is different from Fielding's. That makes two types of intermediaries, "proxy" and "reverse proxy" (term for the latter to be decided). It would also be good to have an encompassing term for a CoAP intermediary that performs caching (which can be true of both "proxies" and "reverse proxies"): 1) Client is configured to use "proxy" that, while proxying, also caches 2) Other intermediaries might also act as caches. -> Fix the terminology #73 No comment #75 No comment #79 No comment #81 Zach notes that the NCN "exchange" is not defined. To be fixed. #74 (slide 10) [We now use the pair immediate/deferred for what was sync/async:] For immediate exchanges, the match is on the TID. For deferred exchanges, the use of the token for matching is agreed for PUT/POST/DELETE. What about GET? Peter raises a related issue: There should be a way to ask a server to makes a special effort to send an immediate response. E.g., "reverse proxies" might have the capability to avoid sending deferred responses. Zach points out that there are also related network congestion/performance issues. Carsten points out that Peter's point conflates two possible requirements: 1) the requirement to obtain a response in a certain amount of time. This could be done with an option "please respond within 2 seconds". 2) the requirement to obtain the response in a specific form (immediate vs. deferred). Peter sees the need for 2, Carsten doesn't. This needs to be discussed further on the list. Zach also points out that in cellular networks delay is a serious issue; delay can be several seconds. Client might use special retransmission timeouts; server has a harder time to infer the client's timing and make appropriate decisions. While requirement 2 above is still open for discussion (as well as the question whether we want to cate for requirement 1 at all), all other requirements can be fulfilled by always using the token for correlation, and giving it a default value (e.g., numeric 0 =3D a zero-length byte string). More discussion needed on the list. #76 (slide 11) We cannot clean up the Web's MIME type mess here in CoRE. See also . But we'll add more explanatory text. Maybe remove video/... from the list. Keep some basic formats in there, though. #77 (slide 12) Response code semantics needs to be spelled out. -> Add one section per response code. -> We also need a ticket about response code numbering (see previous list discussion about x3x). #78 (slide 13) Zach is starting work with Brian on spelling this out. #80 (slide 14) Zach is working on the IANA section. Rule: Accept registering numeric request codes only after there are alphabetic registrations. Carsten: But what about the evolution of this space? A media type might turn up in alphabetic form first and be defined in numeric later. What do we do in the interim? Zach: We have experimental code. Peter: Could we correlate them to the alphabetic form in the = link-format? This is an interesting idea; take it to the list. #82 (slide 15) Klaus' strawman: Use new method codes for proxying Alternative way to achiece this: new option allow-proxy or request-proxy But there should not be a proxy and a server on the same port Carsten asks whether there should there be a link-format on a proxy. /.well-known/core would be on a server, pointing to a proxy on the same host. But how do you point to a proxy? There are no URIs for proxies. Peter: The danger is: if a server gets a request that is intended for a proxy, it might not evaluate the authority and Return the wrong = resource. Take it to the list... Quick ad-hoc discussion of #83 Consensus in the call: If the proxy/cache does not understand the critical option, it should reject the request. (I.e., we don't have a third category of "critical for client-server only", "not critical for proxy".) -> Carsten to add text. (slide 16) Zach: We'll need two weeks for -04. Carsten points out that this means schedule slippage. We agree that we will be hard-pressed to get out of last-call before christmas. Peter: possibly separate out the caching to accelerate this? Zach: I think that we have a pretty good idea forward already. Peter: I like the HTTPbis way of splitting up things. Carsten thinks they still will all go the IESG at the same time, anyway, so the splitting is not achieving any decoupling time-wise. * Link-Format (as Zach has to mute around 16:30 UTC, we skip forward to slide 25) #42 (slide 28) Title for human-readable names, n for "semantic name" id -- was meant as UUID, is this useful? (no positive reply on this = call) sz -- maximum size estimate -- server's buest estimate of what the size will be (to be used when size is > MTU, so requires block transfer). #84 (slide 29) Agreement that UTF-8 is the way forward. Zach: Carsten pointed out that we probably should specify the normalization format, i.e. NFC. Carsten: Yes, this should be a SHOULD. Zach: Is really all of RFC 5198 needed? Carsten: Probably not. We should explain that, unless there is a need to display information, all UTF-8 strings can be handled as byte strings (including things like finding & and =3D in query strings, as UTF-8 is alias-free). #85 (slide 30) Zach: the link relationships go out from the server -- the relationship could be called "hosts" (the verb). Peter: is it "A verb B" or "B verb A"? All very confusing. Enable default is rel=3D"hosts" (Size considerations: Zach's link-format is already 390 bytes on test server.) Easy to add relations to the server (e.g., version of server, info page, ...). How about relationships from specific resources? -- anchor works (practical: you have to query/search) -- sub-paths: have core be a name space... Zach: or a pattern. Carsten: This amounts to URI arithmetic to get the metadata for the = resource. Zach: Or should it be a query parameter? [?anchor=3D...] Peter: Adding a level to the path to provide access to the meta data. There may be additional metadata, as well. Zach: Maybe this isn't a namespace, but just one resource. There is nothing preventing a server to use /.well-known/core to use for = this. It should be possible to do a /.well-known/core/bacnet. Peter: make sure that nobody puts anything there that is not really = bacnet. Zach things that a revised link-format can get out next week. * -observe (There is not much time left in the call, so the rest of the agenda is now in a slightly more superficial mode:) Slide 19: Terminology Peter points out that out of the English language meanings of "observation", a single thing having being observed [Webster #2] is now more frequent than the action or process of "observation" [Webster #1]. (Otherwise, this is mostly Carsten and Klaus quickly going through slides 18..23. No further substantive comments.) * -block (This is mostly Carsten explaining slides 35..38. No further substantive comments.) * Planning Next phone call will be on 2011-01-26 (NO phone call on 2010-12-29). As there are still a number of security issues that need to be discussed before coap-04, we agree to do a phone call with an ad-hoc short-term design team on the security issues soon. Details to be discussed on the list. --Apple-Mail-7-981613673-- From trac@tools.ietf.org Thu Nov 25 09:12:35 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7288228C149 for ; Thu, 25 Nov 2010 09:12:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RS5U8mlOT1bk for ; Thu, 25 Nov 2010 09:12:34 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id B6F8828C13D for ; Thu, 25 Nov 2010 09:12:33 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PLfO2-0003I9-Qe; Thu, 25 Nov 2010 09:13:34 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: hartke@tzi.org X-Trac-Project: core Date: Thu, 25 Nov 2010 17:13:34 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/53#comment:1 Message-ID: <066.6f4fbea26c0f0b2beb3be88808ad2f58@tools.ietf.org> References: <057.3c2c33e201209462cb9746082696f761@tools.ietf.org> X-Trac-Ticket-ID: 53 In-Reply-To: <057.3c2c33e201209462cb9746082696f761@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hartke@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] coap #53 (new): Token length X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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 Nov 2010 17:12:35 -0000 #53: Token length Comment(by hartke@…): Since the value of the Token Option is an opaque byte sequence, no one can be stopped from putting state into it. Assuming 2 bytes of sequence numbering, 6 bytes of protection should be enough. Given that 18 bytes are needed for the transport address (IP address/port), 8 bytes also are not out of line. There is agreement that 0 to 8 bytes is the right size. -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: coap | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From trac@tools.ietf.org Thu Nov 25 09:14:24 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C46D28C127 for ; Thu, 25 Nov 2010 09:14:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2BpTXUNK+0fv for ; Thu, 25 Nov 2010 09:14:23 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id AE8E828C11D for ; Thu, 25 Nov 2010 09:14:23 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PLfPh-0003eK-Rz; Thu, 25 Nov 2010 09:15:17 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: brian@skyfoundry.com, hartke@tzi.org, zach@sensinode.com X-Trac-Project: core Date: Thu, 25 Nov 2010 17:15:17 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/72#comment:2 Message-ID: <062.5b77517ca6bd429e8409fdf5f5326deb@tools.ietf.org> References: <053.639894f29bddd032e710ff634d4068d3@tools.ietf.org> X-Trac-Ticket-ID: 72 In-Reply-To: <053.639894f29bddd032e710ff634d4068d3@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: brian@skyfoundry.com, hartke@tzi.org, zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] coap #72 (new): Proxy versus Reverse proxy (was: Proxy versus Gateway) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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 Nov 2010 17:14:24 -0000 #72: Proxy versus Reverse proxy Comment(by hartke@…): Fielding's dissertation uses the term "gateway" for what is commonly known as "reverse proxy". Carsten and Zach agree that the term gateway has too broad connotations, so it would be good to have a term that is different from Fielding's. That makes two types of intermediaries, "proxy" and "reverse proxy" (term for the latter to be decided). It would also be good to have an encompassing term for a CoAP intermediary that performs caching (which can be true of both "proxies" and "reverse proxies"). -- ----------------------------+----------------------------------------------- Reporter: hartke@… | Owner: brian@… Type: enhancement | Status: new Priority: minor | Milestone: Component: coap | Version: Severity: - | Keywords: ----------------------------+----------------------------------------------- Ticket URL: core From trac@tools.ietf.org Thu Nov 25 09:15:05 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EC7D28C127 for ; Thu, 25 Nov 2010 09:15:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.204 X-Spam-Level: X-Spam-Status: No, score=-102.204 tagged_above=-999 required=5 tests=[AWL=-0.388, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_SUB_NEED_REPLY=0.784, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zzRMDaq0jpUX for ; Thu, 25 Nov 2010 09:15:04 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id E50FF28C11D for ; Thu, 25 Nov 2010 09:15:03 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PLfQS-0005Dw-Gt; Thu, 25 Nov 2010 09:16:04 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com, hartke@tzi.org X-Trac-Project: core Date: Thu, 25 Nov 2010 17:16:04 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/74#comment:1 Message-ID: <062.7358c15daae41e3d6429d7c877b18681@tools.ietf.org> References: <053.554f6b2288336042158a0f86973c4d2f@tools.ietf.org> X-Trac-Ticket-ID: 74 In-Reply-To: <053.554f6b2288336042158a0f86973c4d2f@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, hartke@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] coap #74 (new): Rules for request/response matching X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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 Nov 2010 17:15:05 -0000 #74: Rules for request/response matching Comment(by hartke@…): Apart from the open question if clients should be able to obtain a response in a specific form (immediate or deferred), all requirements to request/response matching can be fulfilled by always using the token for correlation, and giving it a default value (e.g., a zero-length byte sequence). -- ----------------------------+----------------------------------------------- Reporter: hartke@… | Owner: zach@… Type: enhancement | Status: new Priority: minor | Milestone: Component: coap | Version: Severity: - | Keywords: ----------------------------+----------------------------------------------- Ticket URL: core From trac@tools.ietf.org Thu Nov 25 09:16:40 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC50728C11D for ; Thu, 25 Nov 2010 09:16:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.593 X-Spam-Level: X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gjRB9oZcP-Uq for ; Thu, 25 Nov 2010 09:16:39 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id DE1AB3A6983 for ; Thu, 25 Nov 2010 09:16:39 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PLfS1-0008Fn-0F; Thu, 25 Nov 2010 09:17:41 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: hartke@tzi.org X-Trac-Project: core Date: Thu, 25 Nov 2010 17:17:40 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/86 Message-ID: <053.c7f8bd862113c8c3e12141c8288869b9@tools.ietf.org> X-Trac-Ticket-ID: 86 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hartke@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] coap #86 (new): Response code numbering X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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 Nov 2010 17:16:41 -0000 #86: Response code numbering From RFC2616: HTTP status codes are extensible. HTTP applications are not required to understand the meaning of all registered status codes, though such understanding is obviously desirable. However, applications MUST understand the class of any status code, as indicated by the first digit, and treat any unrecognized response as being equivalent to the x00 status code of that class, with the exception that an unrecognized response MUST NOT be cached. For example, if an unrecognized status code of 431 is received by the client, it can safely assume that there was something wrong with its request and treat the response as if it had received a 400 status code. To maintain reasonable behavior as we introduce new status codes in CoAP, we want to have similar language in the base CoAP spec. This raises the question about how to number CoAP-specific error codes. The current draft specifies CoAP-specific error codes in the new 240-255 class. We don't want to treat all unknown CoAP errors as "240 Token Required." Possible solutions include: * Instead of using 6xx codes (240 base 10-10) for CoAP-specific applications, we might reserve x3x. So the set of CoAP-specific 400-kind codes would be 430, 431, etc. This still works with the [http://www.iana.org/assignments/http-status- codes HTTP assignments] so far. If somebody really comes up with an HTTP 43x and we want to use that, we can map it to a CoAP status code. * Taking advantage of what would be the nonsensical "0xx" status code range in HTTP: 1 - 9 : CoAP-specific 2xx-class responses 10 - 19: CoAP-specific 3xx-class responses 20 - 29: CoAP-specific 4xx-class responses 30 - 39: CoAP-specific 5xx-class responses Alternately, as it seems unlikely that CoAP-specific responses are unlikely to ever be in the 2xx or 3xx class, we could give ourselves more headroom by defining them as: 1 - 19: CoAP-specific 4xx-class responses 20 - 39 : CoAP-specific 5xx-class responses Since this conflicts with method codes, these would need to be moved to the 240-255 space, substantially reducing the headroom for future method codes. * Limit ourselves to a maximum of 20 methods, and take 20-29 for 4xx- like codes and 30-39 for 5xx-like codes. -- ----------------------------+----------------------------------------------- Reporter: hartke@… | Owner: Type: task | Status: new Priority: minor | Milestone: Component: coap | Version: Severity: - | Keywords: ----------------------------+----------------------------------------------- Ticket URL: core From trac@tools.ietf.org Thu Nov 25 09:17:39 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 431EE3A6A4A for ; Thu, 25 Nov 2010 09:17:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.593 X-Spam-Level: X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0cKU+Suwc6BA for ; Thu, 25 Nov 2010 09:17:38 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 97C2D3A6983 for ; Thu, 25 Nov 2010 09:17:38 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PLfSx-0001F7-Mg; Thu, 25 Nov 2010 09:18:39 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com, hartke@tzi.org X-Trac-Project: core Date: Thu, 25 Nov 2010 17:18:39 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/80#comment:1 Message-ID: <066.f35b7036bd63cf8371f97e97f973954b@tools.ietf.org> References: <057.92cfec853763e811014fc69193f53889@tools.ietf.org> X-Trac-Ticket-ID: 80 In-Reply-To: <057.92cfec853763e811014fc69193f53889@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, hartke@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] coap #80 (new): IANA section X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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 Nov 2010 17:17:39 -0000 #80: IANA section Comment(by hartke@…): Rule for the registration of future CoAP MIME types: Accept registering numeric request codes only after there are alphabetic registrations. However, a media type might turn up in alphabetic form first and be defined in numeric later. What do we do in the interim? Idea: Use codes in the experimental range and correlate them to the alphabetic form in the link-format. -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: enhancement | Status: new Priority: minor | Milestone: Component: coap | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From trac@tools.ietf.org Thu Nov 25 09:19:04 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3BF73A6A56 for ; Thu, 25 Nov 2010 09:19:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.593 X-Spam-Level: X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qsM5xDjjwPn4 for ; Thu, 25 Nov 2010 09:19:02 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 3EDCE3A6983 for ; Thu, 25 Nov 2010 09:19:02 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PLfUJ-0003kn-Ec; Thu, 25 Nov 2010 09:20:03 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com, hartke@tzi.org X-Trac-Project: core Date: Thu, 25 Nov 2010 17:20:03 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/82#comment:1 Message-ID: <062.8e7c67f7e17b65028bfa6fc703e80033@tools.ietf.org> References: <053.3048b61f06b5f9e56aebee58dc9e9ca0@tools.ietf.org> X-Trac-Ticket-ID: 82 In-Reply-To: <053.3048b61f06b5f9e56aebee58dc9e9ca0@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, hartke@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] coap #82 (new): Disambiguate between proxy and non-proxy requests X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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 Nov 2010 17:19:04 -0000 #82: Disambiguate between proxy and non-proxy requests Comment(by hartke@…): There is also the danger if a server gets a request that is intended for a proxy, and it does not evaluate the authority and returns the wrong resource. This needs to be addressed by a solution as well. A better name for the "Uri-Proxy" Option is "Allow-Proxy" or "Request- Proxy". -- ----------------------------+----------------------------------------------- Reporter: hartke@… | Owner: zach@… Type: enhancement | Status: new Priority: minor | Milestone: Component: coap | Version: Severity: - | Keywords: ----------------------------+----------------------------------------------- Ticket URL: core From trac@tools.ietf.org Thu Nov 25 09:20:04 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1B5328C127 for ; Thu, 25 Nov 2010 09:20:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.593 X-Spam-Level: X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UogN6+vqUj5k for ; Thu, 25 Nov 2010 09:20:03 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id B74C928C133 for ; Thu, 25 Nov 2010 09:20:03 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PLfVJ-0005rG-OS; Thu, 25 Nov 2010 09:21:05 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: cabo@tzi.org, hartke@tzi.org X-Trac-Project: core Date: Thu, 25 Nov 2010 17:21:05 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/83#comment:1 Message-ID: <062.0b0685b3a11403d6ee178c23b8f92cae@tools.ietf.org> References: <053.b061b9a9e179f3d95df711ee7014ee5b@tools.ietf.org> X-Trac-Ticket-ID: 83 In-Reply-To: <053.b061b9a9e179f3d95df711ee7014ee5b@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: cabo@tzi.org, hartke@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] coap #83 (new): Critical options in cached states X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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 Nov 2010 17:20:04 -0000 #83: Critical options in cached states Changes (by hartke@…): * owner: zach@… => cabo@… Comment: What to do when a caching intermediary (e.g., a proxy with a cache) does not understand a critical option, although the client and the server both do. Consensus in the call: If the caching intermediary does not understand a critical option in a request, it should reject the request. (Assuming that responses do not contain critical options other than those present in the request.) -- ----------------------------+----------------------------------------------- Reporter: hartke@… | Owner: cabo@… Type: defect | Status: new Priority: minor | Milestone: Component: coap | Version: Severity: - | Keywords: ----------------------------+----------------------------------------------- Ticket URL: core From trac@tools.ietf.org Thu Nov 25 09:39:58 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3EEF3A6A4A for ; Thu, 25 Nov 2010 09:39:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.593 X-Spam-Level: X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0IppZ5MCZrhE for ; Thu, 25 Nov 2010 09:39:57 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id D29613A6981 for ; Thu, 25 Nov 2010 09:39:57 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PLfoZ-0005t6-W9; Thu, 25 Nov 2010 09:41:00 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: hartke@tzi.org X-Trac-Project: core Date: Thu, 25 Nov 2010 17:40:59 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/33#comment:1 Message-ID: <066.c158e9eee2a2ea69da116e6b13082edc@tools.ietf.org> References: <057.511b2f10b38fa3e3e629a436c4d75ef2@tools.ietf.org> X-Trac-Ticket-ID: 33 In-Reply-To: <057.511b2f10b38fa3e3e629a436c4d75ef2@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hartke@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] observe #33 (new): s/Subscription/Observation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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 Nov 2010 17:39:59 -0000 #33: s/Subscription/Observation Comment(by hartke@…): Proposed terminology: - Verb: observe (the steady state) - Noun: Observation - these are about the relationship between client and server - Verb: Establish an Observation (client action) - Verb: Refresh an Observation (client action) - Verb: End an Observation (server or client action) - these are about the changes of that relationship Peter points out that out of the English language meanings of "observation", a single thing having being observed [Webster 2] is now more frequent than the action or process of "observation" [Webster 1]. From [http://www.merriam-webster.com/dictionary/observation Merriam- Webster]: ob·ser·va·tion (noun) 1. an act or instance of observing a custom, rule, or law 2. an act of recognizing and noting a fact or occurrence often involving measurement with instruments [...] -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: hartke@… Type: enhancement | Status: new Priority: minor | Milestone: Component: observe | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From trac@tools.ietf.org Thu Nov 25 09:40:36 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3FDE28C14E for ; Thu, 25 Nov 2010 09:40:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.517 X-Spam-Level: X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=-0.069, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUetscNL55EO for ; Thu, 25 Nov 2010 09:40:35 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 51D5428C0F7 for ; Thu, 25 Nov 2010 09:40:35 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PLfpA-0005ui-3q; Thu, 25 Nov 2010 09:41:36 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com, hartke@tzi.org X-Trac-Project: core Date: Thu, 25 Nov 2010 17:41:36 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/84#comment:1 Message-ID: <066.919b5dc211e012f6b5be004622632ce4@tools.ietf.org> References: <057.ae02b52e4b00896632b3e313777acfc7@tools.ietf.org> X-Trac-Ticket-ID: 84 In-Reply-To: <057.ae02b52e4b00896632b3e313777acfc7@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, hartke@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] link-format #84 (new): UTF-8 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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 Nov 2010 17:40:36 -0000 #84: UTF-8 Comment(by hartke@…): The normalization format should be specified, i.e. NFC. This should be a SHOULD. It should be explained that, unless there is a need to display information, all UTF-8 strings can be handled as byte strings (including things like finding & and = in query strings, as UTF-8 is alias-free). -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: enhancement | Status: new Priority: minor | Milestone: Component: link-format | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From pab@peoplepowerco.com Thu Nov 25 10:30:08 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0046F3A68E0 for ; Thu, 25 Nov 2010 10:30:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.693 X-Spam-Level: X-Spam-Status: No, score=-1.693 tagged_above=-999 required=5 tests=[AWL=-0.317, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwbBvij2hzKS for ; Thu, 25 Nov 2010 10:30:06 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 5696B3A68A9 for ; Thu, 25 Nov 2010 10:30:06 -0800 (PST) Received: by fxm9 with SMTP id 9so1037099fxm.31 for ; Thu, 25 Nov 2010 10:31:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.71.201 with SMTP id i9mr1089088faj.89.1290709867483; Thu, 25 Nov 2010 10:31:07 -0800 (PST) Received: by 10.223.70.198 with HTTP; Thu, 25 Nov 2010 10:31:07 -0800 (PST) In-Reply-To: <062.5b77517ca6bd429e8409fdf5f5326deb@tools.ietf.org> References: <053.639894f29bddd032e710ff634d4068d3@tools.ietf.org> <062.5b77517ca6bd429e8409fdf5f5326deb@tools.ietf.org> Date: Thu, 25 Nov 2010 12:31:07 -0600 Message-ID: From: Peter Bigot To: core issue tracker Content-Type: multipart/alternative; boundary=20cf30433ed028d0e30495e4cf43 Cc: brian@skyfoundry.com, core@ietf.org, hartke@tzi.org Subject: Re: [core] coap #72 (new): Proxy versus Reverse proxy (was: Proxy versus Gateway) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 18:30:08 -0000 --20cf30433ed028d0e30495e4cf43 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable The two distinct entities I want to make sure are not confused are: * That entity to which a client intentionally delegates the responsibility of executing a REST-layer transaction. The URI may influence the client'= s selection of an appropriate delegate, but its authority part does not resolve to that proxy, not even to the client. * Entities through which transaction messages pass due to network configuration, without visibility to the origin client or origin server. A CoAP client that is using an entity of the first type ("a Proxy") is specifically doing something different than a client that isn't, even if th= e only difference is the client placing the Request-Proxy option in the header. This type of proxy service embodies an application that is specifically different from an origin server. Conceptually, the same role could be applied by encapsulating the CoAP message in an envelope and using a different protocol to transmit it to the delegate. As outlined in my original email, a constrained device network is likely to have to delegate certain operations due to limited resources (DNS implementation, duty cycle, ...). Although dirty DNS and IP packet rewriting tricks could allow a client to operate in ignorance of this delegation, by introducing the concept that motivated what's now proposed a= s the Request-Proxy option CoAP has recognized this role. I think it's important to have a name for it. Referring to the Apache HTTP server glossary, we have: Proxy An intermediate server that sits between the client and the origin server. It accepts requests from clients, transmits those requests on t= o the origin server, and then returns the response from the origin server to the client. If several clients request the same content, the proxy can deliver that content from its cache, rather than requesting it from the origin server each time, thereby reducing response time. Reverse Proxy A proxy server that appears to the client as if it is an origin server. This is useful to hide the real origin server from the client for security reasons, or to load balance. These definitions seem more to be what people have in mind, but to my mind do not make clear the intentional configuration of a client to delegate responsibility for a transaction to another agent. Also, I think one reaso= n people have a problem with "gateway" as used by Fielding is that by his definition (or at least my interpretation of it) a gateway node might not even look at the CoAP layer to do its job (e.g., a NAT service at a 6lowpan border). Can we use Proxy for the first entity I describe, and Reverse Proxy for the second entity, with the understanding that Reverse Proxy refers to an entit= y operating at the CoAP level? This leaves us without a name for intermediar= y nodes that manipulate transactions below the CoAP level, but perhaps we don't need one. Peter On Thu, Nov 25, 2010 at 11:15 AM, core issue tracker w= rote: > #72: Proxy versus Reverse proxy > > > Comment(by hartke@=85): > > Fielding's dissertation uses the term "gateway" for what is commonly kno= wn > as "reverse proxy". Carsten and Zach agree that the term gateway has too > broad connotations, so it would be good to have a term that is different > from Fielding's. > > That makes two types of intermediaries, "proxy" and "reverse proxy" (ter= m > for the latter to be decided). > > It would also be good to have an encompassing term for a CoAP intermedia= ry > that performs caching (which can be true of both "proxies" and "reverse > proxies"). > > -- > > ----------------------------+--------------------------------------------= --- > Reporter: hartke@=85 | Owner: brian@=85 > Type: enhancement | Status: new > Priority: minor | Milestone: > Component: coap | Version: > Severity: - | Keywords: > > ----------------------------+--------------------------------------------= --- > > Ticket URL: > core > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --20cf30433ed028d0e30495e4cf43 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable The two distinct entities I want to make sure are not confused are:

    = * That entity to which a client intentionally delegates the responsibility<= br>=A0 of executing a REST-layer transaction.=A0 The URI may influence the = client's
    =A0 selection of an appropriate delegate, but its authority part does not=A0 resolve to that proxy, not even to the client.

    * Entities thro= ugh which transaction messages pass due to network
    =A0 configuration, wi= thout visibility to the origin client or origin server.

    A CoAP client that is using an entity of the first type ("a Proxy&= quot;) is
    specifically doing something different than a client that isn&= #39;t, even if the
    only difference is the client placing the Request-Pro= xy option in the
    header.=A0 This type of proxy service embodies an application that is
    sp= ecifically different from an origin server.=A0 Conceptually, the same role<= br>could be applied by encapsulating the CoAP message in an envelope and us= ing
    a different protocol to transmit it to the delegate.

    As outlined in = my original email, a constrained device network is likely to
    have to del= egate certain operations due to limited resources (DNS
    implementation, d= uty cycle, ...).=A0 Although dirty DNS and IP packet
    rewriting tricks could allow a client to operate in ignorance of this
    de= legation, by introducing the concept that motivated what's now proposed= as
    the Request-Proxy option CoAP has recognized this role.=A0 I think i= t's
    important to have a name for it.

    Referring to the Apache HTTP server= glossary, we have:

    Proxy
    =A0=A0=A0 An intermediate server that s= its between the client and the origin
    =A0=A0=A0 server. It accepts reque= sts from clients, transmits those requests on to
    =A0=A0=A0 the origin server, and then returns the response from the origin = server
    =A0=A0=A0 to the client. If several clients request the same cont= ent, the proxy
    =A0=A0=A0 can deliver that content from its cache, rather= than requesting it from
    =A0=A0=A0 the origin server each time, thereby reducing response time.
    <= br>Reverse Proxy
    =A0=A0=A0 A proxy server that appears to the client as = if it is an origin
    =A0=A0=A0 server. This is useful to hide the real ori= gin server from the client
    =A0=A0=A0 for security reasons, or to load balance.

    These definitio= ns seem more to be what people have in mind, but to my mind
    do not make = clear the intentional configuration of a client to delegate
    responsibili= ty for a transaction to another agent.=A0 Also, I think one reason
    people have a problem with "gateway" as used by Fielding is that = by his
    definition (or at least my interpretation of it) a gateway node m= ight not
    even look at the CoAP layer to do its job (e.g., a NAT service = at a 6lowpan
    border).

    Can we use Proxy for the first entity I describe, and Rever= se Proxy for the
    second entity, with the understanding that Reverse Prox= y refers to an entity
    operating at the CoAP level?=A0 This leaves us wit= hout a name for intermediary
    nodes that manipulate transactions below the CoAP level, but perhaps we
    = don't need one.

    Peter


    On T= hu, Nov 25, 2010 at 11:15 AM, core issue tracker <trac@tools.ietf.org> wrote= :
    #72: Proxy versus= Reverse proxy


    Comment(by hartke@=85):

    =A0Fielding's dissertation uses the term "gateway" for what i= s commonly known
    =A0as "reverse proxy". Carsten and Zach agree that the term gatew= ay has too
    =A0broad connotations, so it would be good to have a term that is different=
    =A0from Fielding's.

    =A0That makes two types of intermediaries, "proxy" and "reve= rse proxy" (term
    =A0for the latter to be decided).

    =A0It would also be good to have an encompassing term for a CoAP intermedia= ry
    =A0that performs caching (which can be true of both "proxies" and= "reverse
    =A0proxies").

    --
    ----------------------------+----------------------------------------------= -
    =A0Reporter: =A0hartke@=85 =A0 =A0 =A0 =A0| =A0 =A0 =A0 Owner: =A0brian@=85=
    =A0 =A0 Type: =A0enhancement =A0 =A0 | =A0 =A0 =A0Status: =A0new
    =A0Priority: =A0minor =A0 =A0 =A0 =A0 =A0 | =A0 Milestone:
    Component: =A0coap =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 Version:
    =A0Severity: =A0- =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0Keywords:
    ----------------------------+----------------------------------------------= -

    Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/tick= et/72#comment:2>
    core <http://t= ools.ietf.org/core/>

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

    --20cf30433ed028d0e30495e4cf43-- From pab@peoplepowerco.com Thu Nov 25 10:51:50 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64EE628C12E for ; Thu, 25 Nov 2010 10:51:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.681 X-Spam-Level: X-Spam-Status: No, score=-1.681 tagged_above=-999 required=5 tests=[AWL=-0.305, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ADWnSVwN5IpH for ; Thu, 25 Nov 2010 10:51:49 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 97B8D28C11F for ; Thu, 25 Nov 2010 10:51:48 -0800 (PST) Received: by fxm9 with SMTP id 9so1051790fxm.31 for ; Thu, 25 Nov 2010 10:52:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.71.201 with SMTP id i9mr1111707faj.89.1290711169431; Thu, 25 Nov 2010 10:52:49 -0800 (PST) Received: by 10.223.70.198 with HTTP; Thu, 25 Nov 2010 10:52:49 -0800 (PST) In-Reply-To: <066.c158e9eee2a2ea69da116e6b13082edc@tools.ietf.org> References: <057.511b2f10b38fa3e3e629a436c4d75ef2@tools.ietf.org> <066.c158e9eee2a2ea69da116e6b13082edc@tools.ietf.org> Date: Thu, 25 Nov 2010 12:52:49 -0600 Message-ID: From: Peter Bigot To: core issue tracker Content-Type: multipart/alternative; boundary=20cf30433ed0c2fd880495e51cdc Cc: core@ietf.org, hartke@tzi.org Subject: Re: [core] observe #33 (new): s/Subscription/Observation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 18:51:50 -0000 --20cf30433ed0c2fd880495e51cdc Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable > > Peter points out that out of the English language meanings of > "observation", a single thing having being observed [Webster 2] is now > more frequent than the action or process of "observation" [Webster 1]. > I'm not going to try to defend that as a rule, just saying that the propose= d use is not natural to me. While "subscription" clearly indicates a relation, "observation" primarily indicates information. - I have a subscription to The New Yorker, and the food issue was pretty good. - *The food issue subscription of The New Yorker was pretty good. - I observe the temperature on my back deck regularly, and this morning it was 3 degrees. - *I have an observation to the temperature on my back deck, and this morning it was 3 degrees. - The back deck temperature observation this morning was 3 degrees. (*: ungrammatical, ?: questionably grammatical) If you look at the examples at the Merriam Webster site, only one could be read as a use of "observation" to refer to a long-standing relation as opposed to a single act or instance, in my opinion. "Notification" is like "observation" to me, except it highlights the act of conveying the information, not the information itself. Since REST has influenced CoRE, I'd come to refer to the resource representations produced by whatever relation we're talking about as "observations", which are conveyed through "notifications" expressed as a new transaction. This migh= t explain why using "observation" for the relation makes me uncomfortable: I was using it for something else in this domain. At any rate, another opportunity for the working group to chime in. I'd have been comfortable sticking with "subscription" for the relationship. English doesn't seem to have any synonyms for the word that don't convey something different. Peter On Thu, Nov 25, 2010 at 11:40 AM, core issue tracker w= rote: > #33: s/Subscription/Observation > > > Comment(by hartke@=85): > > Proposed terminology: > > - Verb: observe (the steady state) > - Noun: Observation > - these are about the relationship between client and server > > - Verb: Establish an Observation (client action) > - Verb: Refresh an Observation (client action) > - Verb: End an Observation (server or client action) > - these are about the changes of that relationship > > Peter points out that out of the English language meanings of > "observation", a single thing having being observed [Webster 2] is now > more frequent than the action or process of "observation" [Webster 1]. > > From [http://www.merriam-webster.com/I don't dictionary/observationMerriam- > Webster]: ob=B7ser=B7va=B7tion (noun) > 1. an act or instance of observing a custom, rule, or law > 2. an act of recognizing and noting a fact or occurrence often > involving measurement with instruments > [...] > > -- > > --------------------------------+----------------------------------------= --- > Reporter: zach@=85 | Owner: hartke@=85 > Type: enhancement | Status: new > Priority: minor | Milestone: > Component: observe | Version: > Severity: - | Keywords: > > --------------------------------+----------------------------------------= --- > > Ticket URL: > core > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --20cf30433ed0c2fd880495e51cdc Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
    =A0Peter points o= ut that out of the English language meanings of
    =A0"observation", a single thing having being observed [Webster 2= ] is now
    =A0more frequent than the action or process of "observation" [Web= ster 1].

    I'm not going to try to defend that as a rule, just saying that the= proposed use is not natural to me.=A0 While "subscription" clear= ly indicates a relation, "observation" primarily indicates inform= ation.
    • I have a subscription to The New Yorker, and the food issue was pre= tty good.
    • *The food issue subscription of The New Yorker was pretty= good.
    • I observe the temperature on my back deck regularly, and thi= s morning it was 3 degrees.
    • *I have an observation to the temperature on my back deck, and thi= s morning it was 3 degrees.
    • The back deck temperature observation t= his morning was 3 degrees.
    (*: ungrammatical, ?: questionably gram= matical)

    If you look at the examples at the Merriam Webster site, only one could= be read as a use of "observation" to refer to a long-standing re= lation as opposed to a single act or instance, in my opinion.

    "= Notification" is like "observation" to me, except it highlig= hts the act of conveying the information, not the information itself.=A0 Since REST ha= s influenced CoRE, I'd come to refer to the resource representations pr= oduced by whatever relation we're talking about as "observations&q= uot;, which are conveyed through "notifications" expressed as a n= ew transaction.=A0 This might explain why using "observation" for= the relation makes me uncomfortable: I was using it for something else in = this domain.

    At any rate, another opportunity for the working group to chime in.=A0 = I'd have been comfortable sticking with "subscription" for th= e relationship.=A0 English doesn't seem to have any synonyms for the wo= rd that don't convey something different.

    Peter

    On Thu, Nov 25, 2010 at 11:40 AM, c= ore issue tracker <trac@tools.ietf.org> wrote:
    #33: s/Subscription/Observation


    Comment(by hartke@=85):

    =A0Proposed terminology:

    =A0 - Verb: observe (the steady state)
    =A0 - Noun: Observation
    =A0 =A0 - these are about the relationship between client and server

    =A0 - Verb: Establish an Observation (client action)
    =A0 - Verb: Refresh an Observation (client action)
    =A0 - Verb: End an Observation (server or client action)
    =A0 =A0 - these are about the changes of that relationship

    =A0Peter points out that out of the English language meanings of
    =A0"observation", a single thing having being observed [Webster 2= ] is now
    =A0more frequent than the action or process of "observation" [Web= ster 1].

    =A0From [http://www.merriam-webster.com/I don't dictionary/obs= ervation Merriam-
    =A0Webster]: ob=B7ser=B7va=B7tion (noun)
    =A0 =A01. an act or instance of observing a custom, rule, or law
    =A0 =A02. an act of recognizing and noting a fact or occurrence often
    =A0involving measurement with instruments
    =A0[...]

    --
    --------------------------------+------------------------------------------= -
    =A0Reporter: =A0zach@=85 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 Owner: = =A0hartke@=85
    =A0 =A0 Type: =A0enhancement =A0 =A0 =A0 =A0 | =A0 =A0 =A0Status: =A0new =A0Priority: =A0minor =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 Milestone:
    Component: =A0observe =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 Version:
    =A0Severity: =A0- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0Keywords: --------------------------------+------------------------------------------= -

    Ticket URL: <http://trac.tools.ietf.org/wg/core/tra= c/ticket/33#comment:1>
    core <http://tools.ietf.org/core/>

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

    --20cf30433ed0c2fd880495e51cdc-- From pab@peoplepowerco.com Thu Nov 25 11:01:24 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD6EE28C151 for ; Thu, 25 Nov 2010 11:01:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.97 X-Spam-Level: X-Spam-Status: No, score=-1.97 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RvIPd9Cw1wUZ for ; Thu, 25 Nov 2010 11:01:23 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id F03DB28C137 for ; Thu, 25 Nov 2010 11:01:22 -0800 (PST) Received: by fxm9 with SMTP id 9so1057521fxm.31 for ; Thu, 25 Nov 2010 11:02:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.104.198 with SMTP id q6mr1149935fao.13.1290711744448; Thu, 25 Nov 2010 11:02:24 -0800 (PST) Received: by 10.223.70.198 with HTTP; Thu, 25 Nov 2010 11:02:24 -0800 (PST) In-Reply-To: <053.c7f8bd862113c8c3e12141c8288869b9@tools.ietf.org> References: <053.c7f8bd862113c8c3e12141c8288869b9@tools.ietf.org> Date: Thu, 25 Nov 2010 13:02:24 -0600 Message-ID: From: Peter Bigot To: core issue tracker Content-Type: multipart/alternative; boundary=001636c5b5a20907640495e53fef Cc: core@ietf.org, hartke@tzi.org Subject: Re: [core] coap #86 (new): Response code numbering X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 19:01:24 -0000 --001636c5b5a20907640495e53fef Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Not to be more of a pain than I usually am, but I've never understood the desire to use decimal groupings for these types. They need to be recognize= d and processed on constrained nodes; if there's a value at all in assigning them to groups, wouldn't a bit-partitioning scheme make more sense than doing a series of range checks or dividing by ten? Maybe mask with 0x70 an= d shift right four bits to get the HTTP code class. That'd give us 32 codes in each class, plus a few classes left over for CoAP-specific needs. Just a thought. Peter On Thu, Nov 25, 2010 at 11:17 AM, core issue tracker w= rote: > #86: Response code numbering > > From RFC2616: > > HTTP status codes are extensible. HTTP applications are not required to > understand the meaning of all registered status codes, though such > understanding is obviously desirable. However, applications MUST > understand the class of any status code, as indicated by the first digit= , > and treat any unrecognized response as being equivalent to the x00 statu= s > code of that class, with the exception that an unrecognized response MUS= T > NOT be cached. For example, if an unrecognized status code of 431 is > received by the client, it can safely assume that there was something > wrong with its request and treat the response as if it had received a 40= 0 > status code. > > To maintain reasonable behavior as we introduce new status codes in CoAP= , > we want to have similar language in the base CoAP spec. > > This raises the question about how to number CoAP-specific error codes. > > The current draft specifies CoAP-specific error codes in the new 240-255 > class. We don't want to treat all unknown CoAP errors as "240 Token > Required." > > Possible solutions include: > > * Instead of using 6xx codes (240 base 10-10) for CoAP-specific > applications, we might reserve x3x. > So the set of CoAP-specific 400-kind codes would be 430, 431, etc. > > This still works with the [http://www.iana.org/assignments/http-status- > codes HTTP assignments] so far. If somebody really comes up with an HTTP > 43x and we want to use that, we can map it to a CoAP status code. > > * Taking advantage of what would be the nonsensical "0xx" status code > range in HTTP: > > 1 - 9 : CoAP-specific 2xx-class responses > 10 - 19: CoAP-specific 3xx-class responses > 20 - 29: CoAP-specific 4xx-class responses > 30 - 39: CoAP-specific 5xx-class responses > > Alternately, as it seems unlikely that CoAP-specific responses are > unlikely to ever be in the 2xx or 3xx class, we could give ourselves mor= e > headroom by defining them as: > > 1 - 19: CoAP-specific 4xx-class responses > 20 - 39 : CoAP-specific 5xx-class responses > > Since this conflicts with method codes, these would need to be moved to > the 240-255 space, substantially reducing the headroom for future method > codes. > > * Limit ourselves to a maximum of 20 methods, and take 20-29 for 4xx- > like codes and 30-39 for 5xx-like codes. > > -- > > ----------------------------+--------------------------------------------= --- > Reporter: hartke@=85 | Owner: > Type: task | Status: new > Priority: minor | Milestone: > Component: coap | Version: > Severity: - | Keywords: > > ----------------------------+--------------------------------------------= --- > > Ticket URL: > core > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --001636c5b5a20907640495e53fef Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Not to be more of a pain than I usually am, but I've never understood t= he desire to use decimal groupings for these types.=A0 They need to be reco= gnized and processed on constrained nodes; if there's a value at all in= assigning them to groups, wouldn't a bit-partitioning scheme make more= sense than doing a series of range checks or dividing by ten?=A0 Maybe mas= k with 0x70 and shift right four bits to get the HTTP code class.=A0 That&#= 39;d give us 32 codes in each class, plus a few classes left over for CoAP-= specific needs.

    Just a thought.

    Peter

    On Thu, = Nov 25, 2010 at 11:17 AM, core issue tracker <trac@tools.ietf.org> wrote:
    #86: Response code numbering

    =A0From RFC2616:

    =A0 HTTP status codes are extensible. HTTP applications are not required t= o
    =A0understand the meaning of all registered status codes, though such
    =A0understanding is obviously desirable. However, applications MUST
    =A0understand the class of any status code, as indicated by the first digit= ,
    =A0and treat any unrecognized response as being equivalent to the x00 statu= s
    =A0code of that class, with the exception that an unrecognized response MUS= T
    =A0NOT be cached. For example, if an unrecognized status code of 431 is
    =A0received by the client, it can safely assume that there was something =A0wrong with its request and treat the response as if it had received a 40= 0
    =A0status code.

    =A0To maintain reasonable behavior as we introduce new status codes in CoAP= ,
    =A0we want to have similar language in the base CoAP spec.

    =A0This raises the question about how to number CoAP-specific error codes.<= br>
    =A0The current draft specifies CoAP-specific error codes in the new 240-255=
    =A0class. We don't want to treat all unknown CoAP errors as "240 T= oken
    =A0Required."

    =A0Possible solutions include:

    =A0 * Instead of using 6xx codes (240 base 10-10) for CoAP-specific
    =A0applications, we might reserve x3x.
    =A0 So the set of CoAP-specific 400-kind codes would be 430, 431, etc.

    =A0 This still works with the [http://www.iana.org/assignments/http-status= -
    =A0codes HTTP assignments] so far. If somebody really comes up with an HTTP=
    =A043x and we want to use that, we can map it to a CoAP status code.

    =A0 * =A0Taking advantage of what would be the nonsensical "0xx"= status code
    =A0range in HTTP:

    =A0 =A0 =A0 1 - 9 : CoAP-specific 2xx-class responses
    =A0 =A0 =A0 10 - 19: CoAP-specific 3xx-class responses
    =A0 =A0 =A0 20 - 29: CoAP-specific 4xx-class responses
    =A0 =A0 =A0 30 - 39: CoAP-specific 5xx-class responses

    =A0 Alternately, as it seems unlikely that CoAP-specific responses are
    =A0unlikely to ever be in the 2xx or 3xx class, we could give ourselves mor= e
    =A0headroom by defining them as:

    =A0 =A0 =A0 1 - 19: CoAP-specific 4xx-class responses
    =A0 =A0 =A0 20 - 39 : CoAP-specific 5xx-class responses

    =A0 Since this conflicts with method codes, these would need to be moved t= o
    =A0the 240-255 space, substantially reducing the headroom for future method=
    =A0codes.

    =A0 * Limit ourselves to a maximum of 20 methods, and take 20-29 for 4xx-<= br> =A0like codes and 30-39 for 5xx-like codes.

    --
    ----------------------------+----------------------------------------------= -
    =A0Reporter: =A0hartke@=85 =A0 =A0 =A0 =A0| =A0 =A0 =A0 Owner:
    =A0 =A0 Type: =A0task =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0Status: =A0new =A0Priority: =A0minor =A0 =A0 =A0 =A0 =A0 | =A0 Milestone:
    Component: =A0coap =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 Version:
    =A0Severity: =A0- =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0Keywords:
    ----------------------------+----------------------------------------------= -

    Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/86&= gt;
    core <http://t= ools.ietf.org/core/>

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

    --001636c5b5a20907640495e53fef-- From pab@peoplepowerco.com Thu Nov 25 11:40:43 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 326C828C17C for ; Thu, 25 Nov 2010 11:40:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.579 X-Spam-Level: X-Spam-Status: No, score=-1.579 tagged_above=-999 required=5 tests=[AWL=-0.387, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SARE_SUB_NEED_REPLY=0.784] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2biTLDVpW0rd for ; Thu, 25 Nov 2010 11:40:42 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id F04C928C17D for ; Thu, 25 Nov 2010 11:40:41 -0800 (PST) Received: by fxm9 with SMTP id 9so1083057fxm.31 for ; Thu, 25 Nov 2010 11:41:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.71.201 with SMTP id i9mr1166362faj.89.1290714088261; Thu, 25 Nov 2010 11:41:28 -0800 (PST) Received: by 10.223.70.198 with HTTP; Thu, 25 Nov 2010 11:41:28 -0800 (PST) Date: Thu, 25 Nov 2010 13:41:28 -0600 Message-ID: From: Peter Bigot To: core Content-Type: multipart/alternative; boundary=20cf30433ed0bcd53a0495e5ca17 Subject: [core] Need WG input: request/response matching X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 19:40:43 -0000 --20cf30433ed0bcd53a0495e5ca17 Content-Type: text/plain; charset=ISO-8859-1 After the telecon yesterday there is a remaining issue in http://trac.tools.ietf.org/wg/core/trac/ticket/74: whether or not CoAP must provide a mechanism, such as presence/absence of the Token option in a request, to influence the server's decision to use an immediate or deferred response to a specific request. Carsten and I hold opposing positions, and I don't know which side Zack ended on. So, we really need group input on this: *Should clients be required to support deferred responses to their requests? * Carsten's position is "Yes", because this requirement has minimal impact on the client and so there is no need to provide such a mechanism. Depending on the approach, this could reduce message sizes, simplify the client by eliminating the need to re-transmit a request with "deferred-ok" flag if the server can't send an immediate response, and simplify the server implementation. My position is "No". While any end-point that can accept incoming requests should have this machinery, I believe extremely constrained clients might not want to incorporate that code (e.g., to send acknowledgements for incoming confirmable messages), or to support any sort of state associated with unfulfilled requests (e.g., correlating security contexts). Further, even if a client has the mechanism in place, there may be temporary reasons why the client does not want a deferred response for a specific request. For example, following an observation by Zack, certain schedule-based access policies might be difficult to implement if deferred responses, as currently drafted, were allowed. So, I think it's important to give the client the ability to prevent deferred responses. Carsten, please follow up if I've failed to explain your position adequately. Comments from anybody else? (This is a separate issue from a question of whether a client should be able to provide a deadline by which the server must provide either an immediate or deferred response, or to influence the retransmission delays e.g. due to use of a satellite link, although having a mechanism for these issues might make it a moot question. I don't expect we'll have such a mechanism defined within the time by which we expect to submit CoAP to IESG.) Peter --20cf30433ed0bcd53a0495e5ca17 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable After the telecon yesterday there is a remaining issue in http://trac.tools.ietf.org/wg/= core/trac/ticket/74: whether or not CoAP must provide a mechanism, such as presence/absence of the Token option in a request, to influence the server's decision to use an immediate or deferred response to a=20 specific request.

    Carsten and I hold opposing positions, and I don&#= 39;t know which side Zack ended on.=A0 So, we really need group input on th= is:

    Should clients be required = to support deferred responses to their requests?

    Carsten's position is "Yes", because this requireme= nt has minimal impact on the client and so there is no need to provide such= a mechanism.=A0 Depending on the approach, this could reduce message sizes= , simplify the client by eliminating the need to re-transmit a request with= "deferred-ok" flag if the server can't send an immediate res= ponse, and simplify the server implementation.

    My position is "No".=A0 While any end-point that can accept i= ncoming requests should have this machinery, I believe extremely constraine= d clients might not want to incorporate that code (e.g., to send acknowledg= ements for incoming confirmable messages), or to support any sort of state = associated with unfulfilled requests (e.g., correlating security contexts).= =A0 Further, even if a client has the mechanism in place, there may be temp= orary reasons why the client does not want a deferred response for a specif= ic request.=A0 For example, following an observation by Zack, certain sched= ule-based access policies might be difficult to implement if deferred respo= nses, as currently drafted, were allowed.=A0 So, I think it's important= to give the client the ability to prevent deferred responses.

    Carsten, please follow up if I've failed to explain your position a= dequately.

    Comments from anybody else?

    (This is a separate is= sue from a question of whether a client should be=20 able to provide a deadline by which the server must provide either an=20 immediate or deferred response, or to influence the retransmission=20 delays e.g. due to use of a satellite link, although having a mechanism for= these issues might make it a moot question.=A0 I don't expect we'l= l=20 have such a mechanism defined within the time by which we expect to=20 submit CoAP to IESG.)

    Peter
    --20cf30433ed0bcd53a0495e5ca17-- From cabo@tzi.org Thu Nov 25 14:47:25 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A887628C10E for ; Thu, 25 Nov 2010 14:47:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.289 X-Spam-Level: X-Spam-Status: No, score=-104.289 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zzqsJkZ7T6hL for ; Thu, 25 Nov 2010 14:47:25 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 6F58928C10B for ; Thu, 25 Nov 2010 14:47:23 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id oAPMmHUF000286 for ; Thu, 25 Nov 2010 23:48:18 +0100 (CET) Received: from [192.168.2.2] (ip-109-45-0-4.web.vodafone.de [109.45.0.4]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 18D1A5F5; Thu, 25 Nov 2010 23:48:16 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <066.6f4fbea26c0f0b2beb3be88808ad2f58@tools.ietf.org> Date: Thu, 25 Nov 2010 23:48:15 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0562357F-90DE-48B0-832A-4868E2C7BF60@tzi.org> References: <057.3c2c33e201209462cb9746082696f761@tools.ietf.org> <066.6f4fbea26c0f0b2beb3be88808ad2f58@tools.ietf.org> To: Constrained RESTful Environments WG X-Mailer: Apple Mail (2.1082) Cc: Klaus Hartke Subject: [core] Closing coap #53 (new): Token length X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 22:47:25 -0000 On Nov 25, 2010, at 18:13, core issue tracker wrote: > There is agreement that 0 to 8 bytes is the right size. Small clarification: There was agreement about this in Wednesday's phone = call. But we have to validate this on the list. Unless there is new discussion on the mailing list within the next week, = we'll consider this issue done. Gruesse, Carsten From klaus.hartke@googlemail.com Thu Nov 25 15:34:05 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C7053A6A8C for ; Thu, 25 Nov 2010 15:34:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5IgaVdcLiQ2F for ; Thu, 25 Nov 2010 15:34:03 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id B359F3A6997 for ; Thu, 25 Nov 2010 15:34:02 -0800 (PST) Received: by bwz12 with SMTP id 12so1444118bwz.31 for ; Thu, 25 Nov 2010 15:35:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=0cLNhJF60yvCc3RUM3FEW2IvWoFK+7jviGRU68oJXaI=; b=WN2vQaYHJdbdqu4QgYCZZYqRJxaUMClWMkMhaoD5PcyMCv1eRvyNE9ZmTsqVi0oL0A lilV8fm7cFJe5HHP7nONNN2LSlEjDiHWaELpkkfRLJ/nLmcaV5Gz1Sq9hMRqkckerANF 52T24miF07Ea7VFKaJTbnNYgsXh8/p1a/5YPw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=nHFvIoVA4TfThoCtIuLDzQv5cn5W/J/24Ehg1wjDJRXTeCsaQmNwVdiRFL3WNnJZE0 F/rdR/lVb0EUAZUWW0x166kOeufeBbcmwjhi12x0RLtHd542k1i2TdVqDipJ0ndw0tF6 mhQokXrLcWZAb1RvR7EI5g2cUa1TeXBKV1uOg= MIME-Version: 1.0 Received: by 10.204.127.94 with SMTP id f30mr1315099bks.1.1290728104336; Thu, 25 Nov 2010 15:35:04 -0800 (PST) Sender: klaus.hartke@googlemail.com Received: by 10.204.121.134 with HTTP; Thu, 25 Nov 2010 15:35:04 -0800 (PST) In-Reply-To: <053.9ea9efc3dcb9be1a7f2b477e72d5fadd@tools.ietf.org> References: <053.9ea9efc3dcb9be1a7f2b477e72d5fadd@tools.ietf.org> Date: Fri, 26 Nov 2010 00:35:04 +0100 X-Google-Sender-Auth: 6-Ts66p8hrpbs9wsnxjzRCuGu4c Message-ID: From: Klaus Hartke To: core@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [core] coap #77 (new): Response code semantics X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 23:34:05 -0000 I've extracted some text from draft-ietf-httpbis-p2-semantics-12 and adapted it to CoAP. # Response Codes Each response code is described below, including any options required in the response. ## Successful 2xx This class of status code indicates that the client's request was successfully received, understood, and accepted. ### 200 OK The semantics of the response are dependent on the method used in the request. - GET: The request has succeeded. The payload returned with the response is a representation of the target resource. The payload format is specified by the media type given in the Content-Type Option. The response is cacheable: Caches can use the Max-Age Option to determine freshness (freshness model) and (if present) the Etag Option for validation (validation model). ### 201 Created The semantics of the response are dependent on the method used in the request. - PUT: The representation enclosed in the request was successfully stored at the request URI, which resulted in a new resource being created. The payload returned with the response is empty. The Content-Type Option, the Max-Age Option and (if present) the Etag Option refer to the created resource and its current representation after the requested action. The response is not cacheable. However, caches can construct and store a 200 (OK) response from the representation enclosed in the request, and the Content-Type, Max-Age and (if present) Etag Option in the response. - POST: The request has resulted in a new resource being created. The newly created resource can be referenced by the Location Option. The origin server MUST create the resource before returning the 201 response. The payload returned with the response is empty. The response is not cacheable. ### 204 No Content The semantics of the response are dependent on the method used in the request. - PUT: The representation enclosed in the request was successfully stored at the request URI. The payload returned with the response is empty. The Content-Type Option, the Max-Age Option and (if present) the Etag Option refer to the target resource and its current representation after the requested action. The response is not cacheable. However, caches can construct and store a 200 (OK) response from the representation enclosed in the request, and the Content-Type, Max-Age and (if present) Etag Option in the response. - POST: The representation enclosed in the request was accepted and processed as data by the target resource. The payload returned with the response is empty. The response is not cacheable. - DELETE: The target resource was successfully deleted. The payload returned with the response is empty. The response is not cacheable. ## Redirection 3xx This class of response code indicates that further action needs to be taken by the client in order to fulfill the request. ### 304 Not Modified The semantics of the response are dependent on the method used in the request. - GET: The response to the request has not been modified since the response identified by the Etag Option in the request. The payload returned with the response is empty. When a cache receives a 304 response, it needs to created an updated response by combining the stored response with the 304 response, so that the updated response can be used to satisfy the request, and potentially update the cached response. This is detailed in section TBD. ## Client Error 4xx This class of response code is intended for cases in which the client seems to have erred. These response codes are applicable to any request method. The server SHOULD include an human-readable message as payload containing an explanation of the error situation. The format of the payload is plain/text (UTF-8). Responses of this class are cacheable: Caches can use the Max-Age Option to determine freshness (freshness model). They cannot be validated though. ### 400 Bad Request The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modification. ### 4xx The request could not be understood by the server due to one or more unknown critical option. The client SHOULD NOT repeat the request without modification. ### 403 Forbidden The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. ### 404 Not Found The server has not found anything matching the request URI. No indication is given of whether the condition is temporary or permanent. ### 405 Method Not Allowed The method specified in the request is not allowed for the target resource. ## Server Error 5xx This class of response code indicates cases in which the server is aware that it has erred or is incapable of performing the request. These response codes are applicable to any request method. The server SHOULD include an human-readable message as payload containing an explanation of the error situation. The format of the payload is plain/text (UTF-8). Responses of this class are cacheable: Caches can use the Max-Age Option to determine freshness (freshness model). They cannot be validated. ### 500 Internal Server Error The server encountered an unexpected condition which prevented it from fulfilling the request. ### 501 Not Implemented The server does not support the functionality required to fulfill the request. This is the appropriate response when the server does not recognize the request method and is not capable of supporting it for any resource. ### 502 Bad Gateway The end-point, while acting as a proxy or reverse proxy, received an invalid response from the upstream server it accessed in attempting to fulfill the request. ### 503 Service Unavailable The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication is that this is a temporary condition which will be alleviated after some delay. The length of the delay is indicated in the Max-Age Option. ### 504 Gateway Timeout The end-point, while acting as a proxy or reverse proxy, did not receive a timely response from the upstream server specified by the request URI (e.g., CoAP, HTTP) or some other auxiliary server (e.g., DNS) it needed to access in attempting to complete the request. From T.A.Butt@lboro.ac.uk Thu Nov 25 19:36:16 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B244A28C152 for ; Thu, 25 Nov 2010 19:36:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pAlS49Ae--sP for ; Thu, 25 Nov 2010 19:36:14 -0800 (PST) Received: from weed.lut.ac.uk (weed.lut.ac.uk [158.125.1.226]) by core3.amsl.com (Postfix) with ESMTP id 4F9DF28C14D for ; Thu, 25 Nov 2010 19:36:13 -0800 (PST) Received: from [158.125.4.16] (helo=ITSCASH-2.lunet.lboro.ac.uk) by weed.lut.ac.uk with esmtps (TLSv1:AES128-SHA:128) (Exim 4.72) id 1PLp7Z-0008CZ-Jt for core@ietf.org; Fri, 26 Nov 2010 03:37:14 +0000 Received: from staffmbx-1.lunet.lboro.ac.uk ([169.254.2.236]) by ITSCASH-2.lunet.lboro.ac.uk ([158.125.4.16]) with mapi; Fri, 26 Nov 2010 03:37:13 +0000 From: Talal Butt To: "core@ietf.org" Date: Fri, 26 Nov 2010 03:37:12 +0000 Thread-Topic: Draft needs Asynchronous transaction details Thread-Index: AQHLjRs2Afto+fs0eEqi70yPcakTcA== Message-ID: <234B6B562A62654E93691A30A71B12CB2119AEBDF2@STAFFMBX-1.lunet.lboro.ac.uk> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scan-Signature: 4b7674826ba02cc18ba12f6d0af70fa8 X-Lboro-Filtered: weed.lut.ac.uk, Fri, 26 Nov 2010 03:37:14 +0000 Subject: [core] Draft needs Asynchronous transaction details X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 03:36:17 -0000 I am actively following the list and working on a coap implementation for o= ur large scale sensinode network. I have implemented the basic coap with re= liable UDP as defined by the coap ID. Currently, I am planning to add the Asynchronous Logic into my implementati= on but have noticed that ID is not explaining any Asynchronous scenario in = detail.=20 As defined in the draft Client Server | | | CON tid=3D48 | | TOKEN =3D 3a | | GET http://n.. | +---------------->| | | | ACK tid=3D48 |------------> What code should be returned here?= ?? |<----------------+ | | ... Time Passes ... | | | CON tid=3D783 | | TOKEN =3D 3a | | 200 "| | | Figure 3: An asynchronous GET transaction So the client should keep the asynchronous waiting list, to match the recei= ved token with the waiting request. However, the question is what code in t= he ACK, will point out to wait?=20 In this scenario if we can use code=3D100 -> CONTINUE. This can be a solut= ion, but again this is not mentioned in the internet draft. Talal Ashraf Butt Research Student Loughborough University From klaus.hartke@googlemail.com Thu Nov 25 19:50:35 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C08E23A69E7 for ; Thu, 25 Nov 2010 19:50:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8oQDAbhqnq-4 for ; Thu, 25 Nov 2010 19:50:34 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 5F4423A69E4 for ; Thu, 25 Nov 2010 19:50:34 -0800 (PST) Received: by bwz12 with SMTP id 12so1582437bwz.31 for ; Thu, 25 Nov 2010 19:51:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=IXzvcBcyIa6fXbzOmX7qrD5rLa6f1mM2PAfg2deYPq8=; b=tjG2zlQ82U54x6QoGBI1z4Oqb6UWQkP24alfbQyHlzV8goQOlB7rKrSyYDWOpuCvvZ 5LcKoaJGag+GlhEZWcoVK+3jrUVtbp6pUeWnt7x750QuVz2jL1QM2lQGm10iV57osY9y ze/3qqF8A0nBCX3wSxFVp7cJUPBE4tburkeHM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=mfUQZqLYs1W1qFXGzpLYlpV/TVDzk5giUH6N+dJhUgXvkXaiP2Kp1a4PbaYgBaOUM4 yY6jzp7QM/rODVuhFvOuQiFlwZZhvn25ldWOc+suDttmEhX+Z5W9TIbG4QiPfKPiq9k3 X4w90sfKdDyJ+LBe4B8Bc6Kdq1d9I2e0Ndw6I= MIME-Version: 1.0 Received: by 10.204.52.138 with SMTP id i10mr1438927bkg.190.1290743496258; Thu, 25 Nov 2010 19:51:36 -0800 (PST) Sender: klaus.hartke@googlemail.com Received: by 10.204.121.134 with HTTP; Thu, 25 Nov 2010 19:51:36 -0800 (PST) In-Reply-To: <234B6B562A62654E93691A30A71B12CB2119AEBDF2@STAFFMBX-1.lunet.lboro.ac.uk> References: <234B6B562A62654E93691A30A71B12CB2119AEBDF2@STAFFMBX-1.lunet.lboro.ac.uk> Date: Fri, 26 Nov 2010 04:51:36 +0100 X-Google-Sender-Auth: sBQmy9evHSLhRCpTK8Mdhe7JWwA Message-ID: From: Klaus Hartke To: "core@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [core] Draft needs Asynchronous transaction details X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 03:50:35 -0000 Talal Butt wrote: > So the client should keep the asynchronous waiting list, to match the received token with the waiting request. We've just changed the terminology to refer to "immediate" and "deferred" responses, and updated how tokens a are used to correlate responses with requests. Immediate and deferred responses are very similar: In either case, the response contains the token that the client specified in the request. The difference is how they arrive. An immediate responses coincides with the ACK that signals that the CON request was received. A deferred responses arrives as an CON, separately from the ACK. The CON needs to be ACK'd by the client. > However, the question is what code in the ACK, will point out to wait? If the response arrives separately from the ACK (deferred response), the Code field in the header of the ACK is set to 0. Klaus From zach@sensinode.com Thu Nov 25 23:58:12 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1AC23A69CC for ; Thu, 25 Nov 2010 23:58:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.489 X-Spam-Level: X-Spam-Status: No, score=-3.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YXEdwCQTsX6B for ; Thu, 25 Nov 2010 23:58:10 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 4550F3A69A6 for ; Thu, 25 Nov 2010 23:58:09 -0800 (PST) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id oAQ7x8gT005138 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 26 Nov 2010 09:59:08 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-334-1066021600; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: Date: Fri, 26 Nov 2010 09:59:10 +0200 Message-Id: References: <053.639894f29bddd032e710ff634d4068d3@tools.ietf.org> <062.5b77517ca6bd429e8409fdf5f5326deb@tools.ietf.org> To: Peter Bigot X-Mailer: Apple Mail (2.1081) Cc: brian@skyfoundry.com, core issue tracker , core@ietf.org, hartke@tzi.org Subject: Re: [core] coap #72 (new): Proxy versus Reverse proxy (was: Proxy versus Gateway) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 07:58:12 -0000 --Apple-Mail-334-1066021600 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 25, 2010, at 8:31 PM, Peter Bigot wrote: > Proxy > An intermediate server that sits between the client and the origin > server. It accepts requests from clients, transmits those requests = on to > the origin server, and then returns the response from the origin = server > to the client. If several clients request the same content, the = proxy > can deliver that content from its cache, rather than requesting it = from > the origin server each time, thereby reducing response time. >=20 > Reverse Proxy > A proxy server that appears to the client as if it is an origin > server. This is useful to hide the real origin server from the = client > for security reasons, or to load balance.=20 >=20 > These definitions seem more to be what people have in mind, but to my = mind > do not make clear the intentional configuration of a client to = delegate > responsibility for a transaction to another agent. Also, I think one = reason > people have a problem with "gateway" as used by Fielding is that by = his > definition (or at least my interpretation of it) a gateway node might = not > even look at the CoAP layer to do its job (e.g., a NAT service at a = 6lowpan > border). >=20 > Can we use Proxy for the first entity I describe, and Reverse Proxy = for the > second entity, with the understanding that Reverse Proxy refers to an = entity > operating at the CoAP level? This leaves us without a name for = intermediary > nodes that manipulate transactions below the CoAP level, but perhaps = we > don't need one. Works for me. In my opinion we don't have the need to define/name (in = this document) an entity manipulating transactions below L5.=20 Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 --Apple-Mail-334-1066021600 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9 fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb 6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja 5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I 2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTEyNjA3NTkx MFowIwYJKoZIhvcNAQkEMRYEFMv5oLOxUbZajhXPJE1aSCVgjDQyMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBADDObUltasNz2AOCP1uryK+GAFsOGN53siSkcs8w1nBilqoIvjfEcTLn fHga9dsr3BmlNo1zk0DVNAP8878YJLFnvX6kzIB5a5BqATAWBnqQfP1NUP6LezKEDck0t4myP/ds JQnIrr3HYDo19GkjhraR5RE5jZ89C6bc84GYmNS2EiokiRhgxYoLmRcjHVEYb334t8slGdEWZ0rv G5um7IMlghW/GBBw0wYBQ6slZ4OCtis6NDhOIkz2UMLQ/lPhQWpEmAAb/mNNb6UoFLMKLH3q9DbH lnoDKYdmEC/8OgftHrf+Haj01o2PtX0bijsAbYWctQoAYf8SzcIXFY1N3kwAAAAAAAA= --Apple-Mail-334-1066021600-- From angelo.castellani@gmail.com Fri Nov 26 00:22:34 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C99E83A6A5A for ; Fri, 26 Nov 2010 00:22:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.777 X-Spam-Level: X-Spam-Status: No, score=-1.777 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4rxJ+KxUFtpC for ; Fri, 26 Nov 2010 00:22:34 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id E087D3A6A55 for ; Fri, 26 Nov 2010 00:22:33 -0800 (PST) Received: by qwg5 with SMTP id 5so484019qwg.31 for ; Fri, 26 Nov 2010 00:23:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=1tmSclKYc5s5unu8Zv+GBxqWklFRTqgg3/2N9/SCI/g=; b=k/ytC3aJK3hYY0zCMskJPSLHADPgvnG2Gk/XidFazovGXNJch1/V1PV6wp5zh4ewAW 2d8IweNW4JmPMefEF1DD6/5qQzaj+Av8KObgTclnSzgVcfq812q9S01awiHm+pH2+eDM QOJXMUGkI3IjZpYOsZtzA1ql6tFNMXWRERHjY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=BfOp6vg+B9bT/ngVow7fEoOwK1g1rGUC8351JSp51fzciaIjiEHDCVeELNqRoXAQpR UwAsBxf4xcJSrrIY6mjy+1aJwPqfNtIQbsB6CylxybqIpDf4pXNsCe2newlOb2WsjwoH e62WdqeuLHW1/zJ4TWvoIFDSHKaEj8V23qho8= Received: by 10.229.189.134 with SMTP id de6mr1607697qcb.51.1290759816229; Fri, 26 Nov 2010 00:23:36 -0800 (PST) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.229.183.130 with HTTP; Fri, 26 Nov 2010 00:23:16 -0800 (PST) In-Reply-To: <0562357F-90DE-48B0-832A-4868E2C7BF60@tzi.org> References: <057.3c2c33e201209462cb9746082696f761@tools.ietf.org> <066.6f4fbea26c0f0b2beb3be88808ad2f58@tools.ietf.org> <0562357F-90DE-48B0-832A-4868E2C7BF60@tzi.org> From: "Angelo P. Castellani" Date: Fri, 26 Nov 2010 09:23:16 +0100 X-Google-Sender-Auth: 9oWCzqVQSVntdDfedkE5gpB0Fc8 Message-ID: To: Carsten Bormann Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Nicola Bui , Klaus Hartke , Constrained RESTful Environments WG Subject: Re: [core] Closing coap #53 (new): Token length X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 08:22:34 -0000 PROS: a) you can put more information inside the token CONS: a) soft state information in a CoAP server for every request requires 8 bytes for token option, dynamic memory allocation is usually not done in these devices, especially for small data objects... so if 8 is the max, it will also be the allocated size b) matching a request by doing a search can be more complex (64-bit comparisons are more complex than 16-bit comparisons, especially because a lot of these devices have 16bit MCUs like MSP430) If Token is still to be used for *request/response matching* purposes the Pros aren't valuable, because I hardly imagine a 64-bit space of concurrent requests... If we have advantages in that size, the Cons can be handled and accepted because we obtain a benefit in having it that big. In my opinion Token with 8 bytes makes sense only if someone want to stuff some information in it (state), so it will be something similar to a reverse Cookie for CoAP. I currently cannot think any valid reason to believe that stuffing state in the server is the right approach in a REST protocol, please point me to some valid case if I'm wrong. In HTTP server stateless operation is always preserved, to handle "stateful" sessions of interaction Cookies have been introduced: preserving server stateless operation, but allowing to build stateful applications! Can we move to a Cookie approach? Letting the server define the "Token", and the client store it? There are a number of advantages in this: i) stateless server operation ii) HTTP compatibility/mapping iii) if the response has to be deferred, the server can send an ACK and a Cookie. The client can request again, or the server can send a new response with the same Cookie? Regards, Angelo On Thu, Nov 25, 2010 at 23:48, Carsten Bormann wrote: > On Nov 25, 2010, at 18:13, core issue tracker wrote: > >> There is agreement that 0 to 8 bytes is the right size. > > Small clarification: There was agreement about this in Wednesday's phone = call. =A0But we have to validate this on the list. > Unless there is new discussion on the mailing list within the next week, = we'll consider this issue done. > > Gruesse, Carsten > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From angelo.castellani@gmail.com Fri Nov 26 00:26:47 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFECC3A69A6 for ; Fri, 26 Nov 2010 00:26:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.81 X-Spam-Level: X-Spam-Status: No, score=-1.81 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CnIk7xYiwd0o for ; Fri, 26 Nov 2010 00:26:46 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 0D5493A6A0B for ; Fri, 26 Nov 2010 00:26:45 -0800 (PST) Received: by qwg5 with SMTP id 5so487542qwg.31 for ; Fri, 26 Nov 2010 00:27:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=Bqhr6kPvmuu67UD51Hy05uakxkY7rn7jlE7g0t8BNe8=; b=ET20iUzAWXlIoTKc5d8ymZWhVon7/TuudXmaXERgiDfLyJ4dFwTJa1iUyRXBrGU3u1 8U7BSIRVbdjGVGp4537o4yn6ZTdZc8EU9Lb6VWTcz31pzh1oZhZEMCD2zvPU7bpkt5Ri nfkxlZzHwoqblPKg26MtIBT43etz91Fio2sx4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=G1BQJ62/cepxrNqEDrOhaLzPA6imEJXgwkw0r06F3YvBrjUcJWA1W49KYQNzU1uufi hE2ExaPHi7GX+f9rL1m+Dx/MubgX9yrbUrgipfz/iVkSoLSO25rY+Y3/8kFUW4z4vakU dB48ZjSuOCqI+O4dy2+Fs9TfxgUIC7QuWXycM= Received: by 10.229.228.146 with SMTP id je18mr1618151qcb.13.1290760067972; Fri, 26 Nov 2010 00:27:47 -0800 (PST) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.229.183.130 with HTTP; Fri, 26 Nov 2010 00:27:27 -0800 (PST) In-Reply-To: References: <053.9ea9efc3dcb9be1a7f2b477e72d5fadd@tools.ietf.org> From: "Angelo P. Castellani" Date: Fri, 26 Nov 2010 09:27:27 +0100 X-Google-Sender-Auth: zrRem9uRWCau3teE3GD9u5Ke7Eg Message-ID: To: Klaus Hartke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: core@ietf.org Subject: Re: [core] coap #77 (new): Response code semantics X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 08:26:48 -0000 Cannot we simply link to that document and preserve the meanings in CoAP? If there are differences or exceptions, we can pinpoint them in the CoAP document... Mapping and interoperability will be obtained more easily. Regards, Angelo On Fri, Nov 26, 2010 at 00:35, Klaus Hartke wrote: > I've extracted some text from draft-ietf-httpbis-p2-semantics-12 and > adapted it to CoAP. > > > > # Response Codes > > Each response code is described below, including any options required in = the > response. > > > ## Successful 2xx > > This class of status code indicates that the client's request was success= fully > received, understood, and accepted. > > > ### 200 OK > > The semantics of the response are dependent on the method used in the req= uest. > > - GET: The request has succeeded. > > =A0The payload returned with the response is a representation of the targ= et > =A0resource. The payload format is specified by the media type given in t= he > =A0Content-Type Option. > > =A0The response is cacheable: Caches can use the Max-Age Option to determ= ine > =A0freshness (freshness model) and (if present) the Etag Option for valid= ation > =A0(validation model). > > > ### 201 Created > > The semantics of the response are dependent on the method used in the req= uest. > > - PUT: The representation enclosed in the request was successfully stored= at > =A0the request URI, which resulted in a new resource being created. > > =A0The payload returned with the response is empty. The Content-Type Opti= on, the > =A0Max-Age Option and (if present) the Etag Option refer to the created r= esource > =A0and its current representation after the requested action. > > =A0The response is not cacheable. However, caches can construct and store= a 200 > =A0(OK) response from the representation enclosed in the request, and the > =A0Content-Type, Max-Age and (if present) Etag Option in the response. > > - POST: The request has resulted in a new resource being created. The new= ly > =A0created resource can be referenced by the Location Option. The origin = server > =A0MUST create the resource before returning the 201 response. > > =A0The payload returned with the response is empty. > > =A0The response is not cacheable. > > > ### 204 No Content > > The semantics of the response are dependent on the method used in the req= uest. > > - PUT: The representation enclosed in the request was successfully stored= at > =A0the request URI. > > =A0The payload returned with the response is empty. The Content-Type Opti= on, the > =A0Max-Age Option and (if present) the Etag Option refer to the target re= source > =A0and its current representation after the requested action. > > =A0The response is not cacheable. However, caches can construct and store= a 200 > =A0(OK) response from the representation enclosed in the request, and the > =A0Content-Type, Max-Age and (if present) Etag Option in the response. > > - POST: The representation enclosed in the request was accepted and proce= ssed > =A0as data by the target resource. > > =A0The payload returned with the response is empty. > > =A0The response is not cacheable. > > - DELETE: The target resource was successfully deleted. > > =A0The payload returned with the response is empty. > > =A0The response is not cacheable. > > > ## Redirection 3xx > > This class of response code indicates that further action needs to be tak= en by > the client in order to fulfill the request. > > > ### 304 Not Modified > > The semantics of the response are dependent on the method used in the req= uest. > > - GET: The response to the request has not been modified since the respon= se > =A0identified by the Etag Option in the request. > > =A0The payload returned with the response is empty. > > =A0When a cache receives a 304 response, it needs to created an updated r= esponse > =A0by combining the stored response with the 304 response, so that the up= dated > =A0response can be used to satisfy the request, and potentially update th= e > =A0cached response. This is detailed in section TBD. > > > ## Client Error 4xx > > This class of response code is intended for cases in which the client see= ms > to have erred. These response codes are applicable to any request method. > > The server SHOULD include an human-readable message as payload containing= an > explanation of the error situation. The format of the payload is plain/te= xt > (UTF-8). > > Responses of this class are cacheable: Caches can use the Max-Age Option = to > determine freshness (freshness model). They cannot be validated though. > > > ### 400 Bad Request > > The request could not be understood by the server due to malformed syntax= . > The client SHOULD NOT repeat the request without modification. > > > ### 4xx > > The request could not be understood by the server due to one or more unkn= own > critical option. The client SHOULD NOT repeat the request without modific= ation. > > > ### 403 Forbidden > > The server understood the request, but is refusing to fulfill it. Authori= zation > will not help and the request SHOULD NOT be repeated. > > > ### 404 Not Found > > The server has not found anything matching the request URI. No indication= is > given of whether the condition is temporary or permanent. > > > ### 405 Method Not Allowed > > The method specified in the request is not allowed for the target resourc= e. > > > ## Server Error 5xx > > This class of response code indicates cases in which the server is aware = that > it has erred or is incapable of performing the request. These response co= des > are applicable to any request method. > > The server SHOULD include an human-readable message as payload containing= an > explanation of the error situation. The format of the payload is plain/te= xt > (UTF-8). > > Responses of this class are cacheable: Caches can use the Max-Age Option = to > determine freshness (freshness model). They cannot be validated. > > > ### 500 Internal Server Error > > The server encountered an unexpected condition which prevented it from > fulfilling the request. > > > ### 501 Not Implemented > > The server does not support the functionality required to fulfill the req= uest. > This is the appropriate response when the server does not recognize the r= equest > method and is not capable of supporting it for any resource. > > > ### 502 Bad Gateway > > The end-point, while acting as a proxy or reverse proxy, received an inva= lid > response from the upstream server it accessed in attempting to fulfill th= e > request. > > > ### 503 Service Unavailable > > The server is currently unable to handle the request due to a temporary > overloading or maintenance of the server. The implication is that this is= a > temporary condition which will be alleviated after some delay. The length= of > the delay is indicated in the Max-Age Option. > > > ### 504 Gateway Timeout > > The end-point, while acting as a proxy or reverse proxy, did not receive = a > timely response from the upstream server specified by the request URI (e.= g., > CoAP, HTTP) or some other auxiliary server (e.g., DNS) it needed to acces= s in > attempting to complete the request. > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From klaus.hartke@googlemail.com Fri Nov 26 03:14:23 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76DF73A6AA6 for ; Fri, 26 Nov 2010 03:14:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SuS8A-nqoxtn for ; Fri, 26 Nov 2010 03:14:22 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id CE8983A6A10 for ; Fri, 26 Nov 2010 03:14:21 -0800 (PST) Received: by bwz12 with SMTP id 12so1861653bwz.31 for ; Fri, 26 Nov 2010 03:15:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=qnoD3Ei+P53KfKKIT+jG1CjGuwAofawsuemJtILBr+U=; b=kBecMmo04Pkz8GLwQUkQRXHk6DLzT+gNt4bqnhbLdTLMTpg9GCCNl56PC6srPQ7Pdf l4yaCukmbbNCpnwrVCeMA0K/LKO26Qr0kqacSgHrDG6nzukaZ+xiuZv9wBfrpyrfb+2t XD+9ZjDDE1wkpXR/iW6ypJhJCzsYol24RRl58= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=F2VHfmZqIRROmhoz7e+Dq8lmg8tfWh6Rdc+IlyIqBFLsTN9PrzqaYasBJFYBFsD8yy y8NDO56tdP3ZyYk4TcsqiVCAc5NR816i7gIQNb42g3zm61z5AbZBPfs/F2VHCoxtM+40 p1HVNZrLvTpU+0B6Y8nl2jHk8V0TVo3M7DRCA= MIME-Version: 1.0 Received: by 10.204.72.140 with SMTP id m12mr1773187bkj.163.1290770123987; Fri, 26 Nov 2010 03:15:23 -0800 (PST) Sender: klaus.hartke@googlemail.com Received: by 10.204.121.134 with HTTP; Fri, 26 Nov 2010 03:15:23 -0800 (PST) In-Reply-To: References: <053.9ea9efc3dcb9be1a7f2b477e72d5fadd@tools.ietf.org> Date: Fri, 26 Nov 2010 12:15:23 +0100 X-Google-Sender-Auth: 9D6R5Q_4-yH0RffAb47X6oI9o68 Message-ID: From: Klaus Hartke To: core@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [core] coap #77 (new): Response code semantics X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 11:14:23 -0000 Angelo P. Castellani wrote: > Cannot we simply link to that document and preserve the meanings in CoAP? > > If there are differences or exceptions, we can pinpoint them in the > CoAP document... > > Mapping and interoperability will be obtained more easily. CoAP already defines its own versions of the method codes, which are compatible but subtly different to the methods defined in HTTP. The same applies to the response codes: They are compatible but slightly different. For example, we don't have conditional requests in CoAP. This changes the semantics of 304 (Not modified) which now is used to indicate that a cached representation is fresh when a client submits an Etag. If we simply link to HTTP and specify the differences, I believe the resulting text will not be much shorter than what I posted. So I'm more in favour of defining the response code semantics directly in CoAP. Klaus From pab@peoplepowerco.com Fri Nov 26 04:06:05 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4D0928C0D0 for ; Fri, 26 Nov 2010 04:06:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.958 X-Spam-Level: X-Spam-Status: No, score=-1.958 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C4bNsvhRuu16 for ; Fri, 26 Nov 2010 04:06:04 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 54BB13A6AC5 for ; Fri, 26 Nov 2010 04:06:04 -0800 (PST) Received: by fxm9 with SMTP id 9so1585534fxm.31 for ; Fri, 26 Nov 2010 04:07:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.103.4 with SMTP id i4mr1994512fao.70.1290773225902; Fri, 26 Nov 2010 04:07:05 -0800 (PST) Received: by 10.223.70.198 with HTTP; Fri, 26 Nov 2010 04:07:05 -0800 (PST) In-Reply-To: References: <053.9ea9efc3dcb9be1a7f2b477e72d5fadd@tools.ietf.org> Date: Fri, 26 Nov 2010 06:07:05 -0600 Message-ID: From: Peter Bigot To: Klaus Hartke Content-Type: multipart/alternative; boundary=20cf30433f169d91050495f38ff1 Cc: core@ietf.org Subject: Re: [core] coap #77 (new): Response code semantics X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 12:06:05 -0000 --20cf30433f169d91050495f38ff1 Content-Type: text/plain; charset=ISO-8859-1 A second proposal (in addition to not using decimal grouping): don't try to match HTTP response code values with CoAP ones if the semantics are different. Especially if they're subtly different. We'll confuse folks into thinking there's a rote mapping from one to the other. Peter On Fri, Nov 26, 2010 at 5:15 AM, Klaus Hartke wrote: > Angelo P. Castellani wrote: > > Cannot we simply link to that document and preserve the meanings in CoAP? > > > > If there are differences or exceptions, we can pinpoint them in the > > CoAP document... > > > > Mapping and interoperability will be obtained more easily. > > CoAP already defines its own versions of the method codes, which are > compatible but subtly different to the methods defined in HTTP. The > same applies to the response codes: They are compatible but slightly > different. > > For example, we don't have conditional requests in CoAP. This changes > the semantics of 304 (Not modified) which now is used to indicate that > a cached representation is fresh when a client submits an Etag. > > If we simply link to HTTP and specify the differences, I believe the > resulting text will not be much shorter than what I posted. So I'm > more in favour of defining the response code semantics directly in > CoAP. > > > Klaus > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --20cf30433f169d91050495f38ff1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable A second proposal (in addition to not using decimal grouping): don't tr= y to match HTTP response code values with CoAP ones if the semantics are di= fferent.=A0 Especially if they're subtly different.=A0 We'll confus= e folks into thinking there's a rote mapping from one to the other.

    Peter

    On Fri, Nov 26, 2010 at 5:15 AM= , Klaus Hartke <hart= ke@tzi.org> wrote:
    Angelo P. Castellani wrote:
    > Cannot we simply link to that document and preserve the meanings in Co= AP?
    >
    > If there are differences or exceptions, we can pinpoint them in the > CoAP document...
    >
    > Mapping and interoperability will be obtained more easily.

    CoAP already defines its own versions of the method codes, which are<= br> compatible but subtly different to the methods defined in HTTP. The
    same applies to the response codes: They are compatible but slightly
    different.

    For example, we don't have conditional requests in CoAP. This changes the semantics of 304 (Not modified) which now is used to indicate that
    a cached representation is fresh when a client submits an Etag.

    If we simply link to HTTP and specify the differences, I believe the
    resulting text will not be much shorter than what I posted. So I'm
    more in favour of defining the response code semantics directly in
    CoAP.


    Klaus
    __________________________________= _____________
    core mailing list
    core@ietf.org
    ht= tps://www.ietf.org/mailman/listinfo/core

    --20cf30433f169d91050495f38ff1-- From angelo.castellani@gmail.com Fri Nov 26 07:24:01 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48DD23A6B10 for ; Fri, 26 Nov 2010 07:24:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.834 X-Spam-Level: X-Spam-Status: No, score=-1.834 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rpxNfHD1tVr8 for ; Fri, 26 Nov 2010 07:24:00 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 249343A6A3F for ; Fri, 26 Nov 2010 07:23:59 -0800 (PST) Received: by vws7 with SMTP id 7so628094vws.31 for ; Fri, 26 Nov 2010 07:25:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=SAQK/QVUcH51bGyHAHPxYC/aPeZtlO1EmQ1ASgXYo+w=; b=CjjoZWUWMlJo0KCQ257WME8vqjuB8VYTrrkGOuUaM0e2ssU4EMCwBw3emXTHss2AyT 4W4CN74Rjj1uLeUT4jv3K7B/UkSMyorpotQQDMc7kvjZvsfIULgZUxzI66sJweJiq9X+ KHYnK9ksRAaTf/YSwIInOqqb0QSLGDBDfgTx0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=VhGOvLr4LBrevn1zoPGyInyG7NTaDguRKI9ge2q3t4TdwziK6vt+rXVGRU1tN1i8o5 M7FI4pRYHd5vUL7quMGRaZYqziW5S1dVG+tJwYqgD7xUmlAIFJbqlTuAnPep/JYjyYdk ie9ntGusJsdy6QAXW3XIncoAtwQQlCiplzuy4= Received: by 10.229.241.5 with SMTP id lc5mr1890792qcb.165.1290785103439; Fri, 26 Nov 2010 07:25:03 -0800 (PST) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.229.183.130 with HTTP; Fri, 26 Nov 2010 07:24:43 -0800 (PST) In-Reply-To: References: <053.9ea9efc3dcb9be1a7f2b477e72d5fadd@tools.ietf.org> From: "Angelo P. Castellani" Date: Fri, 26 Nov 2010 16:24:43 +0100 X-Google-Sender-Auth: Ew44kbADbBuK1XhvoVEI1CR30dI Message-ID: To: Peter Bigot Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: core@ietf.org, Klaus Hartke Subject: Re: [core] coap #77 (new): Response code semantics X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 15:24:01 -0000 To allow HTTP mapping the code equivalence should be preferred (until the differences are subtle, and no particular issue can be imagined). However to be better informed about the differences and the possible issues, is important at least that these differences are clearly described in the coap document. Angelo On Fri, Nov 26, 2010 at 13:07, Peter Bigot wrote: > A second proposal (in addition to not using decimal grouping): don't try = to > match HTTP response code values with CoAP ones if the semantics are > different.=A0 Especially if they're subtly different.=A0 We'll confuse fo= lks > into thinking there's a rote mapping from one to the other. > > Peter > > On Fri, Nov 26, 2010 at 5:15 AM, Klaus Hartke wrote: >> >> Angelo P. Castellani wrote: >> > Cannot we simply link to that document and preserve the meanings in >> > CoAP? >> > >> > If there are differences or exceptions, we can pinpoint them in the >> > CoAP document... >> > >> > Mapping and interoperability will be obtained more easily. >> >> CoAP already defines its own versions of the method codes, which are >> compatible but subtly different to the methods defined in HTTP. The >> same applies to the response codes: They are compatible but slightly >> different. >> >> For example, we don't have conditional requests in CoAP. This changes >> the semantics of 304 (Not modified) which now is used to indicate that >> a cached representation is fresh when a client submits an Etag. >> >> If we simply link to HTTP and specify the differences, I believe the >> resulting text will not be much shorter than what I posted. So I'm >> more in favour of defining the response code semantics directly in >> CoAP. >> >> >> Klaus >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > From klaus.hartke@googlemail.com Fri Nov 26 07:37:05 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48E2C3A6B15 for ; Fri, 26 Nov 2010 07:37:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DcfSwGt9q6So for ; Fri, 26 Nov 2010 07:37:04 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id E3B333A6B13 for ; Fri, 26 Nov 2010 07:37:03 -0800 (PST) Received: by bwz12 with SMTP id 12so2100425bwz.31 for ; Fri, 26 Nov 2010 07:38:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=lgW1BcGDB5BPKn4X/2n9atCA5lqrgr/yg2uJoBAlrxs=; b=qw8ikh+TLm6FecBN/kzMBMy7WcVAffzgf8Q01yv0RHtGo3qkQ27nesOpZr1ZtU5t5I KSzscdaY+K3KkqwuT1wMCSasU6bvFjYMH2F2vbZ1PVAruP0m8axOVfm7845gvJRTGjmu R/BuSWzawufQSZId6DvcfUAppKV+lkYKwJRns= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=pJODpvtRJPKZL6fX+quswBuSYoetjz2BKPv2lD2NEDT9nJd5rxrpoJcptl0UanrGH+ K420qjRsVWRgKufLGvMLntfDiikAheFagCcoHAceGng1flXup2/MLVfvHdEB45OuaAEz 4mPVO1vWGz8/j2IBDmdzazXsh+3bOIFGQXDPg= MIME-Version: 1.0 Received: by 10.204.98.15 with SMTP id o15mr2048324bkn.136.1290785886801; Fri, 26 Nov 2010 07:38:06 -0800 (PST) Sender: klaus.hartke@googlemail.com Received: by 10.204.121.134 with HTTP; Fri, 26 Nov 2010 07:38:06 -0800 (PST) In-Reply-To: References: <053.9ea9efc3dcb9be1a7f2b477e72d5fadd@tools.ietf.org> Date: Fri, 26 Nov 2010 16:38:06 +0100 X-Google-Sender-Auth: bRoTvGwwLmSYahyz8TJHTgQbCug Message-ID: From: Klaus Hartke To: core@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [core] coap #77 (new): Response code semantics X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 15:37:05 -0000 Angelo P. Castellani wrote: > To allow HTTP mapping the code equivalence should be preferred (until > the differences are subtle, and no particular issue can be imagined). > > However to be better informed about the differences and the possible > issues, is important at least that these differences are clearly > described in the coap document. So in Section 7 (HTTP Mapping) we'd need to point out that * a request from a CoAP client to an HTTP server that includes an Etag is mapped to a conditional request; * a request from an HTTP client to a CoAP server that is conditional is only supported if the request includes a If-None-Match header with exactly one Etag. If-Match, If-Modified-Since and If-Unmodified-Since are not supported, as is If-None-Match with more than one Etag; * the semantics of a CoAP 304 (Not modified) response include only a subset of the semantics of an HTTP 304 (Not Modified) response. Is that about right? Klaus From angelo.castellani@gmail.com Fri Nov 26 07:42:06 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4C8B3A6B15 for ; Fri, 26 Nov 2010 07:42:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.852 X-Spam-Level: X-Spam-Status: No, score=-1.852 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QGHU80wCJ7PW for ; Fri, 26 Nov 2010 07:42:06 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 20CB73A6B14 for ; Fri, 26 Nov 2010 07:42:06 -0800 (PST) Received: by qwg5 with SMTP id 5so905914qwg.31 for ; Fri, 26 Nov 2010 07:43:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=tTTaAXkixm9AZZjZ5q2EzEcrZUGWwqimTmc7gdRHeu4=; b=Yg/eRKpETwPVO4twHDj6mAMPiNwUSOvZCFEmdTtteBeiXHGaOwOhm99kL7rlomLeNg /1PmiwGRi+rKBrcOxX11aGihmiPO0TTFagOWgrbKgVJ/Js7iMkVgOznQqvAODiTvWECd KQ5D0hjqdMQyjMkIHoQyboCEayNLjWXyv3iAQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=vM8646hTCIxt948VOYcfJ4z8b7RcFfJUcqhOcsZuCei6MroZzRhggJX0XBYvIE2Cwi zAYvTllYqsiKQBE9gybvUPA4ObZP2PA04MPL0l85SY+XQm9GeIsC+mdjqH65pCnc7nxa l+FandzyaLz2YsGLqoOgKbeYKuFzdbQiPkZx8= Received: by 10.229.189.134 with SMTP id de6mr1959910qcb.51.1290786189499; Fri, 26 Nov 2010 07:43:09 -0800 (PST) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.229.183.130 with HTTP; Fri, 26 Nov 2010 07:42:49 -0800 (PST) In-Reply-To: References: <053.9ea9efc3dcb9be1a7f2b477e72d5fadd@tools.ietf.org> From: "Angelo P. Castellani" Date: Fri, 26 Nov 2010 16:42:49 +0100 X-Google-Sender-Auth: zG22w789XMqnXpmSGa3CEM1zrVc Message-ID: To: Klaus Hartke Content-Type: text/plain; charset=ISO-8859-1 Cc: core@ietf.org Subject: Re: [core] coap #77 (new): Response code semantics X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 15:42:07 -0000 On Fri, Nov 26, 2010 at 16:38, Klaus Hartke wrote: > So in Section 7 (HTTP Mapping) we'd need to point out that > > * a request from a CoAP client to an HTTP server that includes an Etag > is mapped to a conditional request; > > * a request from an HTTP client to a CoAP server that is conditional > is only supported if the request includes a If-None-Match header with > exactly one Etag. If-Match, If-Modified-Since and If-Unmodified-Since > are not supported, as is If-None-Match with more than one Etag; > > * the semantics of a CoAP 304 (Not modified) response include only a > subset of the semantics of an HTTP 304 (Not Modified) response. If the differences are only those you've listed above why not link to the HTTP definitions without redefining something already defined? A. From klaus.hartke@googlemail.com Fri Nov 26 07:51:44 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AA853A6B18 for ; Fri, 26 Nov 2010 07:51:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4n9ZAEb1IdaU for ; Fri, 26 Nov 2010 07:51:43 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 3453F28C0DD for ; Fri, 26 Nov 2010 07:51:43 -0800 (PST) Received: by bwz12 with SMTP id 12so2112991bwz.31 for ; Fri, 26 Nov 2010 07:52:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=W+vir2FQABwVZBuNNas8yAIiPv2hjdmiHQ1f0dmLLbQ=; b=mtBBxzXmv1+JxEG0ZFrn7KOuUhufKeesVAbBiRbk/WKiXEJRgIQ32B9WCw6nbzVe8o m8x6pXUUjMHXyN0MRIrTOGprjCwNmjufLqaJvHww4H3EQyQhEtWX/Cy7tU/OYnB+x5tf /2wA06IUkgg0dlf0KYL/09CmknMATJqQkivbE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=vug9R8xSsCRE8zKIi2Xy4Bq5esKCASiAMinYTaTI7wyRmmCxkAeCFqYTSJKiTQxGg1 ViBh27jYx8Wmcz5LBHAGy1M6/UuWLv50kOcpfYiX5Bp9sesGdatKTTaAL17BcC+3QBfF P/XdWkUtX7z4/II42JGS3QjSK0VbH5WKZJgYg= MIME-Version: 1.0 Received: by 10.204.98.15 with SMTP id o15mr2066578bkn.136.1290786766250; Fri, 26 Nov 2010 07:52:46 -0800 (PST) Sender: klaus.hartke@googlemail.com Received: by 10.204.121.134 with HTTP; Fri, 26 Nov 2010 07:52:46 -0800 (PST) In-Reply-To: References: <053.9ea9efc3dcb9be1a7f2b477e72d5fadd@tools.ietf.org> Date: Fri, 26 Nov 2010 16:52:46 +0100 X-Google-Sender-Auth: zHlLCaLxiENJw2GbkFg2Sb0j80E Message-ID: From: Klaus Hartke To: core@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [core] coap #77 (new): Response code semantics X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 15:51:44 -0000 Angelo P. Castellani wrote: > If the differences are only those you've listed above why not link to > the HTTP definitions without redefining something already defined? So you'd suggest that CoAP method codes and options should be defined also just in terms of differences to their respective HTTP counterparts? Klaus From angelo.castellani@gmail.com Fri Nov 26 07:57:40 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4417F3A6B19 for ; Fri, 26 Nov 2010 07:57:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.866 X-Spam-Level: X-Spam-Status: No, score=-1.866 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2TH7xT6XllXK for ; Fri, 26 Nov 2010 07:57:39 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 81BD43A6B18 for ; Fri, 26 Nov 2010 07:57:38 -0800 (PST) Received: by qwg5 with SMTP id 5so921554qwg.31 for ; Fri, 26 Nov 2010 07:58:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=iPZxGC8SU1pd/PsbQQ8/iQM4HakLJJy6WRy6YJXPvlw=; b=oYP0tbPikli5tQGya3DeoGcJF/9FN+MzmZdUoTM4C4DxIQDbiwfnhbnEjgGNMAt8y0 Pj30OhLzVzZo5GBhWccUoRl2rFgzZ/iiZ6XhJHkSGpgCYWpL8JvJ65mXlU6ncjvzcpdM HgNQcxDm12mF5iBO5MimhzfcWj5YmbDLz22lo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=Fv8gWv4oN//LmjKsG/kpxsDwVyYkR6j/yFmF9T/3HGpea8KrNJFw2vFFN0cnhEKH+5 cxF6o//0UQOmhZASKlqu6AeC5rppJpP7+uoJOn3/QejW/wkN6s9kYgKgLtp+KxM2biEu 838DkpV2GcKKIwTNNv9F4w4tI7JG5vxld5PuU= Received: by 10.229.189.134 with SMTP id de6mr1971771qcb.51.1290787121412; Fri, 26 Nov 2010 07:58:41 -0800 (PST) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.229.183.130 with HTTP; Fri, 26 Nov 2010 07:58:21 -0800 (PST) In-Reply-To: References: <053.9ea9efc3dcb9be1a7f2b477e72d5fadd@tools.ietf.org> From: "Angelo P. Castellani" Date: Fri, 26 Nov 2010 16:58:21 +0100 X-Google-Sender-Auth: 3QAORoiXvsRXMNvqs6lXXQ-wT6U Message-ID: To: Klaus Hartke Content-Type: text/plain; charset=ISO-8859-1 Cc: core@ietf.org Subject: Re: [core] coap #77 (new): Response code semantics X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 15:57:40 -0000 Yes. HTTP can be used as a reference, and we can explicitly tell when the HTTP definition isn't good for CoAP and clearly describe only the peculiarities/differences/new behaviours. On Fri, Nov 26, 2010 at 16:52, Klaus Hartke wrote: > Angelo P. Castellani wrote: >> If the differences are only those you've listed above why not link to >> the HTTP definitions without redefining something already defined? > > So you'd suggest that CoAP method codes and options should be defined > also just in terms of differences to their respective HTTP > counterparts? > > > Klaus > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From klaus.hartke@googlemail.com Fri Nov 26 08:16:15 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E38428C0D7 for ; Fri, 26 Nov 2010 08:16:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79Q6VjoVHuwS for ; Fri, 26 Nov 2010 08:16:14 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 54DE228C0DE for ; Fri, 26 Nov 2010 08:16:12 -0800 (PST) Received: by bwz12 with SMTP id 12so2143015bwz.31 for ; Fri, 26 Nov 2010 08:17:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=38GNTP6ksTheKlWEbwrOCnhgGmOHK6lr/18YIoGX1GA=; b=mBS+YlForrCGDuyz8BKWUxzUhZzRTgf5WC7ri5uWuGeK/9zkPZr4F4zhPF+1kLwWV7 yRkMhqjiNR5RhcG04ZInUkdZSlYMjg5rHTQEawRv98bnysu9WWXLKvPyI5xyFGCLIT7h aPdmKZwCC0E37WzVsA4s5Q3P8DjxwVvQBJR7M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=ceDFgklobhN6DArx471j32btfjxklWJpSwgeFx2BFdOivYdpjBBAok+BbA4Ui5Zqfy cj9HDTKpwvmYdrkbNvgI4jJS4pdFr28eyK+PzEMtgOefRDZv6zRFaFRmI3TJK+S5HSkr 1FNOUPUUhAjWRauwr+eO0HcOVh7EjVu+GWsCc= MIME-Version: 1.0 Received: by 10.204.72.140 with SMTP id m12mr2085292bkj.163.1290788235412; Fri, 26 Nov 2010 08:17:15 -0800 (PST) Sender: klaus.hartke@googlemail.com Received: by 10.204.121.134 with HTTP; Fri, 26 Nov 2010 08:17:15 -0800 (PST) In-Reply-To: References: <053.9ea9efc3dcb9be1a7f2b477e72d5fadd@tools.ietf.org> Date: Fri, 26 Nov 2010 17:17:15 +0100 X-Google-Sender-Auth: BKIaY5z9pIZPUKStfIz1CReVlOI Message-ID: From: Klaus Hartke To: core@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [core] coap #77 (new): Response code semantics X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 16:16:15 -0000 Angelo P. Castellani wrote: >> [define the protocol in terms of differences to HTTP] > > Yes. > > HTTP can be used as a reference, and we can explicitly tell when the > HTTP definition isn't good for CoAP and clearly describe only the > peculiarities/differences/new behaviours. Let's change the name to "Minified HTTP" then, so people don't get the wrong impression we're creating a new protocol here. Klaus From tianlinyi@huawei.com Fri Nov 26 18:44:43 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C70728C139 for ; Fri, 26 Nov 2010 18:44:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RI0v+swaXH4E for ; Fri, 26 Nov 2010 18:44:42 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 16FAC28C130 for ; Fri, 26 Nov 2010 18:44:42 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LCI00HPGVO027@szxga05-in.huawei.com> for core@ietf.org; Sat, 27 Nov 2010 10:45:36 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LCI00KNKVNZYJ@szxga05-in.huawei.com> for core@ietf.org; Sat, 27 Nov 2010 10:45:36 +0800 (CST) Received: from T34932F ([10.70.109.83]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LCI00K12VNZEQ@szxml04-in.huawei.com> for core@ietf.org; Sat, 27 Nov 2010 10:45:35 +0800 (CST) Date: Sat, 27 Nov 2010 10:45:35 +0800 From: Linyi Tian In-reply-to: To: 'Klaus Hartke' , core@ietf.org Message-id: <012f01cb8ddd$2aacaf00$80060d00$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: AcuNhWvcCRNvBNTpS0OCIdJhH+5ImAAVnldQ References: <053.9ea9efc3dcb9be1a7f2b477e72d5fadd@tools.ietf.org> Subject: Re: [core] coap #77 (new): Response code semantics X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Nov 2010 02:44:43 -0000 In general I agree with Angelo we can just refer to the same definition for status code from HTTP. If there is difference we should clearly describe the difference and why. We talked about the new codes defined by CoAP but we didn't discuss what code will not be used by CoAP, right? Since CoAP is for constrained devices and not for web, some status code may not be appropriate for CoAP. This should be described as well in our draft. Otherwise people may wondering whether this code can be used or not which will lead to interoperable problem as well. The section 4 in [HTTP 1.1 Part 2] is very helpful. It has the Status Code and Reason Phrase. We may need the same table as follows (just an example): Status-Code = / "200" ; [HTTP 1.1 Part2] Section 8.2.1: OK / "201" ; [HTTP 1.1 Part2] Section 8.2.2: Created ........... / "505" ; [HTTP 1.1 Part2] Section 8.5.6: HTTP Version not supported (not used by CoAP) / "xxx" ; [Link Format] Section x.x.x: xxxxxx [Defined by CoAP] Cheers, Linyi >>-----Original Message----- >>From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of >>Klaus Hartke >>Sent: Saturday, November 27, 2010 12:17 AM >>To: core@ietf.org >>Subject: Re: [core] coap #77 (new): Response code semantics >> >>Angelo P. Castellani wrote: >>>> [define the protocol in terms of differences to HTTP] >>> >>> Yes. >>> >>> HTTP can be used as a reference, and we can explicitly tell when the >>> HTTP definition isn't good for CoAP and clearly describe only the >>> peculiarities/differences/new behaviours. >> >>Let's change the name to "Minified HTTP" then, so people don't get the >>wrong impression we're creating a new protocol here. [Linyi Tian] Do you mean you will change the "CoAP" to "Minified HTTP"? >> >> >>Klaus >>_______________________________________________ >>core mailing list >>core@ietf.org >>https://www.ietf.org/mailman/listinfo/core From ngocthanhdinh@gmail.com Fri Nov 26 23:06:54 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 891A83A6B55 for ; Fri, 26 Nov 2010 23:06:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rIJPsCgZHaif for ; Fri, 26 Nov 2010 23:06:53 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 1459C3A6AEE for ; Fri, 26 Nov 2010 23:06:52 -0800 (PST) Received: by bwz12 with SMTP id 12so2668632bwz.31 for ; Fri, 26 Nov 2010 23:07:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=79CXaUkGb4MqRapSqTnXvnNmui5YhrjLkuk03gTB5rw=; b=Fwon+Tj19p6clME2BGccXSmDhkr7LVjN3rt31ex3iqroYjDjBWcuPGqiZIvZWDLrxf 0vzlGxJpipbV+GfcjUvwI0gTmI0g7eS+xXkpkWl88T1Ce+maiSo3kfWirjQ4cI7/sI7s PhNMhJuUhIKleaDThBHIEHjocR+/Fyrjhpnb0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=HFV5MdZxsBgqLTa8RcGcIFOhwMSr4hZrg3bvwSXwLo+jov/PB9+FI70ZDqz31VthJd UxiaLOH0eilg4960sOA+unpqq62yEMdk+GxjHSFyjWktQIvEB3uTChVwrFje+MTU8CO3 Cr4Nc7BQTUXHvnNLPaRh48+NxwvHpQJg2wSp4= MIME-Version: 1.0 Received: by 10.204.113.195 with SMTP id b3mr2686253bkq.210.1290841677219; Fri, 26 Nov 2010 23:07:57 -0800 (PST) Received: by 10.204.116.7 with HTTP; Fri, 26 Nov 2010 23:07:57 -0800 (PST) Date: Sat, 27 Nov 2010 16:07:57 +0900 Message-ID: From: Thanh Ngoc To: contiki-developers@lists.sourceforge.net, core@ietf.org Content-Type: multipart/alternative; boundary=00163669754da1c89e0496037f1f Subject: [core] Help for error in web server example in contiki2.x and 2.5 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Nov 2010 07:06:54 -0000 --00163669754da1c89e0496037f1f Content-Type: text/plain; charset=ISO-8859-1 Dear Every one, when i try to run webserver example. but it has an error as follow: "------------------------------------------------------------ user@instant-contiki:~/contiki-2.x/examples/sky-ip$ make sky-webserver.upload using saved target 'sky' msp430-gcc -DWITH_UIP=1 -I. -DCONTIKI=1 -DCONTIKI_TARGET_SKY=1 -Wall -mmcu=msp430x1611 -g -Os -DMAC_DRIVER=cxmac_driver -DMAC_CHANNEL_CHECK_RATE=8 -I. -I../../platform/sky/ .... ... msp430-gcc -mmcu=msp430x1611 -Wl,-Map=contiki-sky.map sky-webserver.coobj_sky/contiki-sky-main.o obj_sky/ajax-cgi.o contiki-sky.a -o sky-webserver.sky obj_sky/ajax-cgi.o: In function `make_neighbor': */home/user/contiki-2.x/examples/sky-ip/ajax-cgi.c:171: undefined reference to `collect_neighbor_get' obj_sky/ajax-cgi.o: In function `neighborscall': /home/user/contiki-2.x/examples/sky-ip/ajax-cgi.c:193: undefined reference to `collect_neighbor_num' /home/user/contiki-2.x/examples/sky-ip/ajax-cgi.c:195: undefined reference to `collect_neighbor_get' obj_sky/ajax-cgi.o: In function `received_announcement': /home/user/contiki-2.x/examples/sky-ip/ajax-cgi.c:213: undefined reference to `collect_neighbor_find' /home/user/contiki-2.x/examples/sky-ip/ajax-cgi.c:218: undefined reference to `collect_neighbor_update' /home/user/contiki-2.x/examples/sky-ip/ajax-cgi.c:216: undefined reference to `collect_neighbor_add' make: *** [sky-webserver.sky] Error 1 rm sky-webserver.co* user@instant-contiki:~/contiki-2.x/examples/sky-ip$ cd ../ "----------------------------------------------------- i opened the file ajax-cgi.c and saw this file refer to file net/rime/collect-neighbor.h #include "net/rime/collect-neighbor.h" but the file net/rime/collect-neighbor.h does not has functions such as: collect_neighbor_find(), collect_neighbor_add().... does it has any one know how to solve this problem, please help me to solve it. thank you very much and have a nice weekend, Ngoc Thanh* * --00163669754da1c89e0496037f1f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Every one,

    when i try to run webserver example.
    but it has a= n error as follow:

    "------------------------------------------= ------------------
    user@instant-contiki:~/contiki-2.x/examples/sky-ip$ m= ake sky-webserver.upload
    using saved target 'sky'
    msp430-gcc -DWITH_UIP=3D1 -I.=A0 -DCONT= IKI=3D1 -DCONTIKI_TARGET_SKY=3D1 -Wall -mmcu=3Dmsp430x1611 -g=A0 -Os -DMAC_= DRIVER=3Dcxmac_driver -DMAC_CHANNEL_CHECK_RATE=3D8 -I. -I../../platform/sky= /
    ....
    ...
    msp430-gcc -mmcu=3Dmsp430x1611 -Wl,-Map=3Dcontiki-sky.map=A0 sky-webserver.co obj_sky/contiki-sky-main.= o obj_sky/ajax-cgi.o contiki-sky.a=A0 -o sky-webserver.sky
    obj_sky/ajax-= cgi.o: In function `make_neighbor':
    /home/user/contiki-2.x/examples/sky-ip/ajax-cgi.c:171: undefined referen= ce to `collect_neighbor_get'
    obj_sky/ajax-cgi.o: In function `neighb= orscall':
    /home/user/contiki-2.x/examples/sky-ip/ajax-cgi.c:193: und= efined reference to `collect_neighbor_num'
    /home/user/contiki-2.x/examples/sky-ip/ajax-cgi.c:195: undefined reference = to `collect_neighbor_get'
    obj_sky/ajax-cgi.o: In function `received_= announcement':
    /home/user/contiki-2.x/examples/sky-ip/ajax-cgi.c:213= : undefined reference to `collect_neighbor_find'
    /home/user/contiki-2.x/examples/sky-ip/ajax-cgi.c:218: undefined reference = to `collect_neighbor_update'
    /home/user/contiki-2.x/examples/sky-ip/= ajax-cgi.c:216: undefined reference to `collect_neighbor_add'
    make: = *** [sky-webserver.sky] Error 1
    rm sky-webserver.co
    user@ins= tant-contiki:~/contiki-2.x/examples/sky-ip$ cd ../

    "-----------= ------------------------------------------

    i opened the file ajax-cg= i.c=A0 and saw this file refer to file net/rime/collect-neighbor.h

    #include "net/rime/collect-neighbor.h"

    but the file ne= t/rime/collect-neighbor.h does not has functions such as: collect_neighbor_= find(), collect_neighbor_add()....

    does it has any one know how to s= olve this problem, please help me to solve it.

    thank you very much and have a nice weekend,


    =A0=A0=A0=A0=A0= Ngoc Thanh
     --00163669754da1c89e0496037f1f-- From tianlinyi@huawei.com Sat Nov 27 00:00:32 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 504613A69FC for ; Sat, 27 Nov 2010 00:00:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yqNnUyTS4IKc for ; Sat, 27 Nov 2010 00:00:31 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 31C673A6990 for ; Sat, 27 Nov 2010 00:00:31 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LCJ00936AADM1@szxga05-in.huawei.com> for core@ietf.org; Sat, 27 Nov 2010 16:01:26 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LCJ00IJOAAC2S@szxga05-in.huawei.com> for core@ietf.org; Sat, 27 Nov 2010 16:01:25 +0800 (CST) Received: from T34932F ([10.70.109.83]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LCJ0040RAACSS@szxml06-in.huawei.com> for core@ietf.org; Sat, 27 Nov 2010 16:01:24 +0800 (CST) Date: Sat, 27 Nov 2010 16:01:24 +0800 From: Linyi Tian In-reply-to: To: "'Angelo P. Castellani'" , 'Carsten Bormann' Message-id: <014101cb8e09$497befa0$dc73cee0$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=iso-8859-1 Content-language: zh-cn Content-transfer-encoding: quoted-printable Thread-index: AcuNQ0f4J08XYLpZQcGC7tP/BG2KJwAwf7Qg References: <057.3c2c33e201209462cb9746082696f761@tools.ietf.org> <066.6f4fbea26c0f0b2beb3be88808ad2f58@tools.ietf.org> <0562357F-90DE-48B0-832A-4868E2C7BF60@tzi.org> Cc: 'Nicola Bui' , 'Constrained RESTful Environments WG' , 'Klaus Hartke' Subject: Re: [core] Closing coap #53 (new): Token length X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Nov 2010 08:00:32 -0000 Hi, All I need some clarification for the token discussion. (sorry for missed = the call). 1. Did we decide to put state into token and extend the usage for the = token? 2. If Token is only used as correlation for deferred message, the = current length (2 bytes) maybe enough. 3. If we want to use token for storing state, what is the use case?=20 I believe before we make a decision we need to understand in which = scenario we want to use this mechanism. Cheers, Linyi >>-----Original Message----- >>From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf = Of >>Angelo P. Castellani >>Sent: Friday, November 26, 2010 4:23 PM >>To: Carsten Bormann >>Cc: Nicola Bui; Klaus Hartke; Constrained RESTful Environments WG >>Subject: Re: [core] Closing coap #53 (new): Token length >> >>PROS: >>a) you can put more information inside the token >> >>CONS: >>a) soft state information in a CoAP server for every request requires >>8 bytes for token option, dynamic memory allocation is usually not >>done in these devices, especially for small data objects... so if 8 is >>the max, it will also be the allocated size >>b) matching a request by doing a search can be more complex (64-bit >>comparisons are more complex than 16-bit comparisons, especially >>because a lot of these devices have 16bit MCUs like MSP430) >> >>If Token is still to be used for *request/response matching* purposes >>the Pros aren't valuable, because I hardly imagine a 64-bit space of >>concurrent requests... If we have advantages in that size, the Cons >>can be handled and accepted because we obtain a benefit in having it >>that big. >> >>In my opinion Token with 8 bytes makes sense only if someone want to >>stuff some information in it (state), so it will be something similar >>to a reverse Cookie for CoAP. >> >>I currently cannot think any valid reason to believe that stuffing >>state in the server is the right approach in a REST protocol, please >>point me to some valid case if I'm wrong. >> >>In HTTP server stateless operation is always preserved, to handle >>"stateful" sessions of interaction Cookies have been introduced: >>preserving server stateless operation, but allowing to build stateful >>applications! >> >>Can we move to a Cookie approach? >> >>Letting the server define the "Token", and the client store it? >> >>There are a number of advantages in this: >>i) stateless server operation >>ii) HTTP compatibility/mapping >>iii) if the response has to be deferred, the server can send an ACK >>and a Cookie. The client can request again, or the server can send a >>new response with the same Cookie? >> >>Regards, >>Angelo >> >>On Thu, Nov 25, 2010 at 23:48, Carsten Bormann wrote: >>> On Nov 25, 2010, at 18:13, core issue tracker wrote: >>> >>>> There is agreement that 0 to 8 bytes is the right size. >>> >>> Small clarification: There was agreement about this in Wednesday's = phone >>call. =A0But we have to validate this on the list. >>> Unless there is new discussion on the mailing list within the next = week, we'll >>consider this issue done. >>> >>> Gruesse, Carsten >>> >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>> >>_______________________________________________ >>core mailing list >>core@ietf.org >>https://www.ietf.org/mailman/listinfo/core From tianlinyi@huawei.com Sat Nov 27 00:42:35 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68C7728C144 for ; Sat, 27 Nov 2010 00:42:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TsUqRke+MaIk for ; Sat, 27 Nov 2010 00:42:34 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 1354928C129 for ; Sat, 27 Nov 2010 00:42:34 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LCJ004F6C8G2N@szxga04-in.huawei.com> for core@ietf.org; Sat, 27 Nov 2010 16:43:28 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LCJ004D8C8GJM@szxga04-in.huawei.com> for core@ietf.org; Sat, 27 Nov 2010 16:43:28 +0800 (CST) Received: from T34932F ([10.70.109.83]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LCJ004N6C8GO6@szxml06-in.huawei.com> for core@ietf.org; Sat, 27 Nov 2010 16:43:28 +0800 (CST) Date: Sat, 27 Nov 2010 16:43:28 +0800 From: Linyi Tian In-reply-to: <234B6B562A62654E93691A30A71B12CB2119AEBDF2@STAFFMBX-1.lunet.lboro.ac.uk> To: 'Talal Butt' , core@ietf.org Message-id: <014901cb8e0f$29c597a0$7d50c6e0$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: AQHLjRs2Afto+fs0eEqi70yPcakTcJOE/cbg References: <234B6B562A62654E93691A30A71B12CB2119AEBDF2@STAFFMBX-1.lunet.lboro.ac.uk> Subject: Re: [core] Draft needs Asynchronous transaction details X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Nov 2010 08:42:35 -0000 Hi, Talal Ashraf Butt I believe the status code in ACK should be 202 "Accepted" instead of 100 "continue. Status code 100 is to allow a client that is sending a request message with a request body to determine if the origin server is willing to accept the request before the client send the request body. I hope this helps. The group is working on how to include status code description into R04 draft. You can read the emails with tile " [core] coap #77 (new): Response code semantics ". I quote the following description from HTTP 1.1 Part 2 (http://datatracker.ietf.org/doc/draft-ietf-httpbis-p2-semantics/): 8.2.3. 202 Accepted The request has been accepted for processing, but the processing has not been completed. The request might or might not eventually be acted upon, as it might be disallowed when processing actually takes place. There is no facility for re-sending a status code from an asynchronous operation such as this. The 202 response is intentionally non-committal. Its purpose is to allow a server to accept a request for some other process (perhaps a batch-oriented process that is only run once per day) without Fielding, et al. requiring that the user agent's connection to the server persist until the process is completed. The representation returned with this response SHOULD include an indication of the request's current status and either a pointer to a status monitor or some estimate of when the user can expect the request to be fulfilled. You can refer to 7.2.3 of HTTP 1.1 Part 1 (http://datatracker.ietf.org/doc/draft-ietf-httpbis-p1-messaging/) 7.2.3. Use of the 100 (Continue) Status The purpose of the 100 (Continue) status code (see Section 8.1.1 of [Part2]) is to allow a client that is sending a request message with a request body to determine if the origin server is willing to accept the request (based on the request header fields) before the client sends the request body. In some cases, it might either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without looking at the body. Requirements for HTTP/1.1 clients: o If a client will wait for a 100 (Continue) response before sending the request body, it MUST send an Expect request-header field (Section 9.2 of [Part2]) with the "100-continue" expectation. o A client MUST NOT send an Expect request-header field (Section 9.2 of [Part2]) with the "100-continue" expectation if it does not intend to send a request body. Cheers, Linyi >>-----Original Message----- >>From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of >>Talal Butt >>Sent: Friday, November 26, 2010 11:37 AM >>To: core@ietf.org >>Subject: [core] Draft needs Asynchronous transaction details >> >>I am actively following the list and working on a coap implementation for our >>large scale sensinode network. I have implemented the basic coap with reliable >>UDP as defined by the coap ID. >> >>Currently, I am planning to add the Asynchronous Logic into my implementation >>but have noticed that ID is not explaining any Asynchronous scenario in detail. >> >>As defined in the draft >> >> Client Server >> | | >> | CON tid=48 | >> | TOKEN = 3a | >> | GET http://n.. | >> +---------------->| >> | | >> | ACK tid=48 |------------> What code should be returned here??? >> |<----------------+ >> | | >> ... Time Passes ... >> | | >> | CON tid=783 | >> | TOKEN = 3a | >> | 200 "> |<----------------+ >> | | >> | ACK tid=783 | >> +---------------->| >> | | >> >> Figure 3: An asynchronous GET transaction >> >>So the client should keep the asynchronous waiting list, to match the received >>token with the waiting request. However, the question is what code in the ACK, >>will point out to wait? >> In this scenario if we can use code=100 -> CONTINUE. This can be a solution, >>but again this is not mentioned in the internet draft. >> >>Talal Ashraf Butt >>Research Student >>Loughborough University >> >>_______________________________________________ >>core mailing list >>core@ietf.org >>https://www.ietf.org/mailman/listinfo/core From tianlinyi@huawei.com Sat Nov 27 01:11:47 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04F4B28C152 for ; Sat, 27 Nov 2010 01:11:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.103 X-Spam-Level: X-Spam-Status: No, score=-4.103 tagged_above=-999 required=5 tests=[AWL=-0.393, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, SARE_SUB_NEED_REPLY=0.784] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WwkgESaO1+pW for ; Sat, 27 Nov 2010 01:11:35 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 276B628C141 for ; Sat, 27 Nov 2010 01:11:34 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LCJ00DLCDKSJW@szxga04-in.huawei.com> for core@ietf.org; Sat, 27 Nov 2010 17:12:29 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LCJ00JJSDKS2K@szxga04-in.huawei.com> for core@ietf.org; Sat, 27 Nov 2010 17:12:28 +0800 (CST) Received: from T34932F ([10.70.109.83]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LCJ004JODKSSW@szxml06-in.huawei.com> for core@ietf.org; Sat, 27 Nov 2010 17:12:28 +0800 (CST) Date: Sat, 27 Nov 2010 17:12:28 +0800 From: Linyi Tian In-reply-to: To: 'Peter Bigot' , 'core' Message-id: <014a01cb8e13$36e71db0$a4b55910$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_l4inguanwIvAhLtyDRK56w)" Content-language: zh-cn Thread-index: AcuM2M/1aJajyshfTROxMsv2YkG6TQBOYD1w References: Subject: Re: [core] Need WG input: request/response matching X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Nov 2010 09:11:48 -0000 ÕâÊÇÒ»·â MIME ¸ñʽµÄ¶à²¿·ÖÓʼþ¡£ --Boundary_(ID_l4inguanwIvAhLtyDRK56w) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, Peter My answer is "yes". Here is my observation: 1. Client will not know whether the server needs time to process the request. It will be hard for client to decide when to use negotiation mechanism. 2. The server chooses to use deferred message is because the server needs time to process the request. Even if the client wants to get the result immediately it may not be realistic. If the server can't do it in ACK, what the server can do? Simply reject the message? 3. If the end point can support the complex mechanism like scheduling, I can't imagine it can't store the state associated with Token for short of time. The main mechanism for the client needs is to store the Token and has a time-out mechanism. Maybe this is not a big issue for clients. Correct me if I am wrong. Cheers, Linyi From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Peter Bigot Sent: Friday, November 26, 2010 3:41 AM To: core Subject: [core] Need WG input: request/response matching After the telecon yesterday there is a remaining issue in http://trac.tools.ietf.org/wg/core/trac/ticket/74: whether or not CoAP must provide a mechanism, such as presence/absence of the Token option in a request, to influence the server's decision to use an immediate or deferred response to a specific request. Carsten and I hold opposing positions, and I don't know which side Zack ended on. So, we really need group input on this: Should clients be required to support deferred responses to their requests? Carsten's position is "Yes", because this requirement has minimal impact on the client and so there is no need to provide such a mechanism. Depending on the approach, this could reduce message sizes, simplify the client by eliminating the need to re-transmit a request with "deferred-ok" flag if the server can't send an immediate response, and simplify the server implementation. My position is "No". While any end-point that can accept incoming requests should have this machinery, I believe extremely constrained clients might not want to incorporate that code (e.g., to send acknowledgements for incoming confirmable messages), or to support any sort of state associated with unfulfilled requests (e.g., correlating security contexts). Further, even if a client has the mechanism in place, there may be temporary reasons why the client does not want a deferred response for a specific request. For example, following an observation by Zack, certain schedule-based access policies might be difficult to implement if deferred responses, as currently drafted, were allowed. So, I think it's important to give the client the ability to prevent deferred responses. Carsten, please follow up if I've failed to explain your position adequately. Comments from anybody else? (This is a separate issue from a question of whether a client should be able to provide a deadline by which the server must provide either an immediate or deferred response, or to influence the retransmission delays e.g. due to use of a satellite link, although having a mechanism for these issues might make it a moot question. I don't expect we'll have such a mechanism defined within the time by which we expect to submit CoAP to IESG.) Peter --Boundary_(ID_l4inguanwIvAhLtyDRK56w) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

    Hi, Peter

     

    My answer is “yes”. Here is my = observation:

    1.       Client will not know = whether the server needs time to process the request. It will be hard for client = to decide when to use negotiation mechanism.

    2.       The server chooses to = use deferred message is because the server needs time to process the request. Even if = the client wants to get the result immediately it may not be realistic. If = the server can’t do it in ACK, what the server can do? Simply reject = the message?

    3.        If the end point = can support the complex mechanism like scheduling, I can’t imagine it = can’t store the state associated with Token for short of time.

     

    The main mechanism for the client needs is to store the = Token and has a time-out mechanism. Maybe this is not a big issue for clients. Correct me if I am wrong.

     

    Cheers,

    Linyi

     

    From: core-bounces@ietf.org = [mailto:core-bounces@ietf.org] On Behalf Of Peter Bigot
    Sent: Friday, November 26, 2010 3:41 AM
    To: core
    Subject: [core] Need WG input: request/response = matching

     

    After the telecon yesterday there is a remaining issue in http://trac.to= ols.ietf.org/wg/core/trac/ticket/74: whether or not CoAP must provide a mechanism, such as presence/absence = of the Token option in a request, to influence the server's decision to use an immediate or deferred response to a specific request.

    Carsten and I hold opposing positions, and I don't know which side Zack = ended on.  So, we really need group input on this:

    Should clients be required to = support deferred responses to their requests?


    Carsten's position is "Yes", because this requirement has = minimal impact on the client and so there is no need to provide such a = mechanism.  Depending on the approach, this could reduce message sizes, simplify the = client by eliminating the need to re-transmit a request with = "deferred-ok" flag if the server can't send an immediate response, and simplify the = server implementation.

    My position is "No".  While any end-point that can accept incoming requests should have this machinery, I believe extremely = constrained clients might not want to incorporate that code (e.g., to send = acknowledgements for incoming confirmable messages), or to support any sort of state = associated with unfulfilled requests (e.g., correlating security contexts).  = Further, even if a client has the mechanism in place, there may be temporary = reasons why the client does not want a deferred response for a specific = request.  For example, following an observation by Zack, certain schedule-based access policies might be difficult to implement if deferred responses, as = currently drafted, were allowed.  So, I think it's important to give the = client the ability to prevent deferred responses.

    Carsten, please follow up if I've failed to explain your position = adequately.

    Comments from anybody else?

    (This is a separate issue from a question of whether a client should be = able to provide a deadline by which the server must provide either an immediate = or deferred response, or to influence the retransmission delays e.g. due to = use of a satellite link, although having a mechanism for these issues might = make it a moot question.  I don't expect we'll have such a mechanism defined = within the time by which we expect to submit CoAP to IESG.)

    Peter

    --Boundary_(ID_l4inguanwIvAhLtyDRK56w)-- From alexey.melnikov@isode.com Sat Nov 27 08:57:57 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F13C28C0DD for ; Sat, 27 Nov 2010 08:57:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j68qeA+wZzcQ for ; Sat, 27 Nov 2010 08:57:55 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 9229728C0D8 for ; Sat, 27 Nov 2010 08:57:55 -0800 (PST) Received: from [188.28.56.209] (188.28.56.209.threembb.co.uk [188.28.56.209]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sat, 27 Nov 2010 16:58:59 +0000 Message-ID: <4CF13897.2000206@isode.com> Date: Sat, 27 Nov 2010 16:57:59 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Zach Shelby References: <4CE38524.60106@isode.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: core WG Subject: Re: [core] Review of draft-ietf-core-coap-03.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Nov 2010 16:57:57 -0000 Zach Shelby wrote: >Alexey, > > Hi Zach, >Thanks for the review, very helpful. I will now be making tickets for these. Some comments in-line. > > I've trimmed my reply: >On Nov 17, 2010, at 9:32 AM, Alexey Melnikov wrote: > > >>Hi, >>I've decided to do IESG-type review of the document, as it seems to be getting close to being done. many of my comments are editorial in nature. In general I found the document to be well written. >> >>In Section 1 - the first reference to HTTP needs an Informative Reference. >> >>In Section 2.1.2 (Asynchronous response) - the first reference to "token option" needs a reference (either a cross reference, or an external reference). >> >> >> >>>2.5.1. Option Processing >>> >>> If no options are to be included, the Option Count field is set to 0 >>> below and the Payload (if any) immediately follows the Transaction >>> ID. If options are to be included, the following rules apply. The >>> number of options is placed in the Option Count field. Each option >>> is then placed in order of Type, immediately following the >>> Transaction ID with no padding. Upon reception, unknown options of >>> class "elective" MUST be silently skipped. Unknown options of class >>> "critical" in a Confirmable MUST cause the return of a response code >>> "Critical Option not supported (CoAP 242)" including a copy of the >>> critical option number in the payload of the response. >>> >>> >>Does this need a new payload (MIME) type registration? Options don't seem to be considered to be a part of a payload (assuming my reading of Sections 3 and 3.1 is correct). Or did you mean that the options need to be returned as TLVs? >> >> > >This payload is meant to be text/plain. We also have a ticket to include a human readable error message: http://trac.tools.ietf.org/wg/core/trac/ticket/50 > Ok. But this still doesn't answer how unknown critical options are expressed in error responses. Please clarify. [...] >>>10.2.1. SharedKey & MultiKey Modes >>> >>> When forming a connection to a new node, the system selects an >>> appropriate key based on which nodes it is trying to reach then forms >>> a DTLS session using a PSK (Pre-Shared Key) mode of DTLS. >>> Implementations SHOULD support the mandatory to implement cipher >>> >>> >>I think this needs to be a MUST, conditional on DTLS being supported by the node. >> >> >>> suite TLS_PSK_WITH_AES_128_CBC_SHA as specified in [RFC5246]. >>>10.2.2. Certificate Mode >>> >>> As with IPsec, DTLS should be configured with a cypher suite >>> compatible with any possible hardware engine on the node, for example >>> AES-CBC in the case of IEEE 802.15.4. Implementations SHOULD support >>> >>> >>As above, I think this needs to be a MUST. >> >>> the mandatory to implement cipher suite TLS_RSA_WITH_AES_128_CBC_SHA >>> as specified in [RFC5246]. >>> > >The thinking behind the SHOULD in for these default cipher suites was that not all constrained devices would have hardware for AES-CBC (or AES-CCM is actually our goal). > Interoperability demands that a mandatory to implement mechanism is defined, ideally a single one. >It is true for lots of IEEE 802.15.4 devices, but a different platform for e.g. industrial automation might need a totally different cipher suite for the encryption hardware it hassupport for. Should we require those industrial devices to support the default AES-CCM cipher suite also? > I would either define 1 cipher (possibly 2) that every implementation needs to support, and allow deployments in different industries to redefine the default if needed. (I suppose your use of SHOULD is such an attempt. But if you want to keep the SHOULD, I think you need to explain or demonstrate some cases of when violating the SHOULD would be Ok.) Alternatively you can argue that requirements of different deployments would be different and no single default applies. But this is a bit harder to sell to IESG. Although different IESGs might take different stance on this. Best Regards, Alexey From klaus.hartke@googlemail.com Sat Nov 27 13:02:29 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2B1828C0CE for ; Sat, 27 Nov 2010 13:02:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h6E5+5A4usfa for ; Sat, 27 Nov 2010 13:02:29 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id A50CC3A6AE1 for ; Sat, 27 Nov 2010 13:02:28 -0800 (PST) Received: by bwz12 with SMTP id 12so3089528bwz.31 for ; Sat, 27 Nov 2010 13:03:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=5UYVK5fY5xiI2X9apwczi/Oe//fPSuvPkkcYQimOVkc=; b=nQklFzCELd7HcnfD0mqi6O6ARXk0rfUS+dNXxp42ubt5gaSBq8JonvH6sRgywSkZZ3 Zna20BY6+cseK5inpAzpMEhXXU8TGgyr5r5U/zud4Zw9JQlQFkIAMYPUONXWjuLurKZC lQBU+7qsrQXoLIQcJJvDVCPfnpL/0/dMcBo2o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=lE85P+lK95fOMwbhml5dMStEKHa/+qC6UQf9ag73dRH4jt21NP7FmXr2cBMNvNYptj wO0r71ACXRHsAV+MzXz7pJavPWZq+y/O1voIKSDRasm5OKD+ODTZ+paAziTfDJx3iBjz dmrcofecmtdbCWI5M5+r0kGEecia35ARR5mE8= MIME-Version: 1.0 Received: by 10.204.98.15 with SMTP id o15mr3211009bkn.136.1290891813769; Sat, 27 Nov 2010 13:03:33 -0800 (PST) Sender: klaus.hartke@googlemail.com Received: by 10.204.121.134 with HTTP; Sat, 27 Nov 2010 13:03:33 -0800 (PST) In-Reply-To: <014901cb8e0f$29c597a0$7d50c6e0$@com> References: <234B6B562A62654E93691A30A71B12CB2119AEBDF2@STAFFMBX-1.lunet.lboro.ac.uk> <014901cb8e0f$29c597a0$7d50c6e0$@com> Date: Sat, 27 Nov 2010 22:03:33 +0100 X-Google-Sender-Auth: FvPgcKH2NGpUeH16cUp5uzh0XBQ Message-ID: From: Klaus Hartke To: core@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [core] Draft needs Asynchronous transaction details X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Nov 2010 21:02:29 -0000 Linyi Tian wrote: > I believe the status code in ACK should be 202 "Accepted" No. When a client sends a confirmable message with a request to a server, two things happen: 1. The server acknowledges that it received the confirmable message, so the client can stop retransmitting. 2. The server processes the request and sends a response. These two things are separate and not coupled in any way. But they can happen at the same time ("immediate response") or at different times ("deferred response"). If acknowledgement and response happen at different times, the acknowledgement does not carry a response. Message that carry neither request nor response have Code 0, no options and no payload. Klaus From cabo@tzi.org Sat Nov 27 13:15:15 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A02128C0D6 for ; Sat, 27 Nov 2010 13:15:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.374 X-Spam-Level: X-Spam-Status: No, score=-106.374 tagged_above=-999 required=5 tests=[AWL=-0.125, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z63ukWbGEPJt for ; Sat, 27 Nov 2010 13:15:14 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id D69B628C0CE for ; Sat, 27 Nov 2010 13:15:13 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id oARLGCE4016687; Sat, 27 Nov 2010 22:16:12 +0100 (CET) Received: from [192.168.217.101] (p5489A43A.dip.t-dialin.net [84.137.164.58]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id DBED3A48; Sat, 27 Nov 2010 22:16:11 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <4CF13897.2000206@isode.com> Date: Sat, 27 Nov 2010 22:16:10 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <165D2C63-2C32-4300-A653-B829734CC47B@tzi.org> References: <4CE38524.60106@isode.com> <4CF13897.2000206@isode.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.1082) Cc: core WG Subject: Re: [core] Review of draft-ietf-core-coap-03.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Nov 2010 21:15:15 -0000 On Nov 27, 2010, at 17:57, Alexey Melnikov wrote: > Interoperability demands that a mandatory to implement mechanism is = defined, ideally a single one. I'm not sure that is a realistic requirement for constrained nodes. We sure want to aid interoperability, but this may be too big a hammer. (And, as we have learned from "mandatory to implement" IPsec, having the = code but no keys is not useful at all.) Gruesse, Carsten From klaus.hartke@googlemail.com Sat Nov 27 13:24:12 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 880DE28C0D6 for ; Sat, 27 Nov 2010 13:24:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48TnDkd6msqt for ; Sat, 27 Nov 2010 13:24:05 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id BBBCC28C0CE for ; Sat, 27 Nov 2010 13:24:03 -0800 (PST) Received: by bwz12 with SMTP id 12so3100656bwz.31 for ; Sat, 27 Nov 2010 13:25:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=E3iiSM6KFNiCBCIe45cmRa6OeJJUTMkqXiOhz2w5QBA=; b=oqnNpjR+8YSGaUJSwaUOXSrjj06Ca1R14sE0fslHgyGMAc8A59ta3QybUfx5zeUe1z Nv0SQlPDZL3kHPfrIQOLPDoCaOHp1AgHGUpyTmbgc11QFhkImg+kuXm6ImEoZK/eXrWZ 2Kz0df7w/4KuZJoG8/0B29YL7h3nuBkjbzyOI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=LsT5le/dHMc4H0FI5aeRS40MWfFkjDMC0f1uDI09406FzT388JZcc3rsoN4pG9xxsJ 6kjLkABfUzTsKjGR3rcHvypJcJ5hJok3WSjzgxxC06db5zV320XzxAio+TW8A474csaB PFUqRRg6hpSwPUXNHuAgNSiWX6Z50aU3Oof8E= MIME-Version: 1.0 Received: by 10.204.72.140 with SMTP id m12mr3215900bkj.163.1290893109192; Sat, 27 Nov 2010 13:25:09 -0800 (PST) Sender: klaus.hartke@googlemail.com Received: by 10.204.121.134 with HTTP; Sat, 27 Nov 2010 13:25:09 -0800 (PST) In-Reply-To: <012f01cb8ddd$2aacaf00$80060d00$@com> References: <053.9ea9efc3dcb9be1a7f2b477e72d5fadd@tools.ietf.org> <012f01cb8ddd$2aacaf00$80060d00$@com> Date: Sat, 27 Nov 2010 22:25:09 +0100 X-Google-Sender-Auth: tY5y6kBTYK1QGmZ75AOOjancHZA Message-ID: From: Klaus Hartke To: core@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [core] coap #77 (new): Response code semantics X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Nov 2010 21:24:17 -0000 Linyi Tian wrote: > Do you mean you will change the "CoAP" to "Minified HTTP"? Only if we change the whole protocol to be defined in differences to HTTP. However, it was agreed on a long time ago that CoAP is a new protocol inspired by REST, which is easily mappable to HTTP, but not just "compressed" HTTP. So, no, we won't change the name, and we won't define CoAP in differences to HTTP. (References to HTTP are, of course, perfectly valid.) Klaus From alexey.melnikov@isode.com Sat Nov 27 14:35:20 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F45328C0CE for ; Sat, 27 Nov 2010 14:35:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DcsbPbcgyO3o for ; Sat, 27 Nov 2010 14:35:19 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id D40623A6B2A for ; Sat, 27 Nov 2010 14:35:16 -0800 (PST) Received: from [188.28.56.209] (188.28.56.209.threembb.co.uk [188.28.56.209]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sat, 27 Nov 2010 22:36:20 +0000 Message-ID: <4CF18792.2040302@isode.com> Date: Sat, 27 Nov 2010 22:34:58 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Carsten Bormann References: <4CE38524.60106@isode.com> <4CF13897.2000206@isode.com> <165D2C63-2C32-4300-A653-B829734CC47B@tzi.org> In-Reply-To: <165D2C63-2C32-4300-A653-B829734CC47B@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: core WG Subject: Re: [core] Review of draft-ietf-core-coap-03.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Nov 2010 22:35:20 -0000 Hi Carsten, Carsten Bormann wrote: >On Nov 27, 2010, at 17:57, Alexey Melnikov wrote: > > >>Interoperability demands that a mandatory to implement mechanism is defined, ideally a single one. >> >> >I'm not sure that is a realistic requirement for constrained nodes. > > Actually I stand by this statement and it is true for non security related mechanisms as well. If you don't believe in one mandatory to implement mechanism, why do you work on COAP protocol at all ;-). >We sure want to aid interoperability, but this may be too big a hammer. > > If you are talking about whether all nodes need to support DTLS or not, then I think you are missing my point. You might have a convincing argument why not all nodes need to support DTLS. (I haven't thought about whether not support DTLS is bad or good idea for COAP.) But if a node does support DTLS, then it is better implement the same DTLS cipher as every other node on the same network. >(And, as we have learned from "mandatory to implement" IPsec, having the code but no keys is not useful at all.) > > Well, one needs to mandate support for all necessary pieces. From ekr@rtfm.com Sun Nov 28 13:34:37 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14CF628C0D6 for ; Sun, 28 Nov 2010 13:34:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.483 X-Spam-Level: X-Spam-Status: No, score=-101.483 tagged_above=-999 required=5 tests=[AWL=-0.107, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9e83KFy9pee for ; Sun, 28 Nov 2010 13:34:36 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id AC9103A6BDB for ; Sun, 28 Nov 2010 13:34:35 -0800 (PST) Received: by gxk28 with SMTP id 28so1366440gxk.31 for ; Sun, 28 Nov 2010 13:35:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.91.19.13 with SMTP id w13mr7925321agi.151.1290980143341; Sun, 28 Nov 2010 13:35:43 -0800 (PST) Received: by 10.91.78.6 with HTTP; Sun, 28 Nov 2010 13:35:43 -0800 (PST) In-Reply-To: <066.34c8fead60f7ba790f916b74f04e04ab@tools.ietf.org> References: <057.cbcb8082fb49a1a254def976b454a663@tools.ietf.org> <066.34c8fead60f7ba790f916b74f04e04ab@tools.ietf.org> Date: Sun, 28 Nov 2010 13:35:43 -0800 Message-ID: From: Eric Rescorla To: core issue tracker Content-Type: multipart/alternative; boundary=001485f6d0dadb2052049623bcb2 Cc: core@ietf.org Subject: Re: [core] coap #55 (new): AES-CCM vs. AES-CBC X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Nov 2010 21:34:37 -0000 --001485f6d0dadb2052049623bcb2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I'm not sure that non-normative text really does the job here. If you're going to use CCM, you pretty much need automatic key management. Is that something you intend t require or not... -Ekr On Sun, Nov 21, 2010 at 12:42 AM, core issue tracker w= rote: > #55: AES-CCM vs. AES-CBC > > > Comment(by cabo@=85): > > Re IPsec, add a brief discussion (expanding the existing reference to > section 9 of RFC 4309) about the requirements AES-CCM places on key > establishment (i.e., the traditional manual keying approach does not wor= k > vert well here). > > More generally speaking, this text about key establishment should also > point out that anti-replay requires a protocol to manage keys and sequen= ce > numbers. > > (the above are channeling comments by Eric Rescorla in > http://www.ietf.org > /mail-archive/web/core/current/msg01061.html which discusses this in mor= e > detail and also contains text from RFC 4303 that we might use.) > > If Tero Kivinen's lightweight IKE draft becomes available in time; add a > reference to that (as relevant work in progress). > > -- > > --------------------------------+----------------------------------------= --- > Reporter: zach@=85 | Owner: > Type: enhancement | Status: new > Priority: trivial | Milestone: > Component: coap | Version: > Severity: - | Keywords: > > --------------------------------+----------------------------------------= --- > > Ticket URL: > core > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --001485f6d0dadb2052049623bcb2 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I'm not sure that non-normative text really does the job here. If you&#= 39;re going to use
    CCM, you pretty much need automatic key management. = Is that something you intend
    t require or not...

    -Ekr


    On Sun, Nov 21= , 2010 at 12:42 AM, core issue tracker <trac@tools.ietf.org> wrote:
    #55: AES-CCM vs. AES-CBC


    Comment(by cabo@=85):

    =A0Re IPsec, add a brief discussion (expanding the existing reference to =A0section 9 of RFC 4309) about the requirements AES-CCM places on key
    =A0establishment (i.e., the traditional manual keying approach does not wor= k
    =A0vert well here).

    =A0More generally speaking, this text about key establishment should also =A0point out that anti-replay requires a protocol to manage keys and sequen= ce
    =A0numbers.

    =A0(the above are channeling comments by Eric Rescorla in http://www.ietf.org
    =A0/mail-archive/web/core/current/msg01061.html which discusses this in mor= e
    =A0detail and also contains text from RFC 4303 that we might use.)

    =A0If Tero Kivinen's lightweight IKE draft becomes available in time; a= dd a
    =A0reference to that (as relevant work in progress).

    --
    --------------------------------+------------------------------------------= -
    =A0Reporter: =A0zach@=85 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 Owner: =A0 =A0 Type: =A0enhancement =A0 =A0 =A0 =A0 | =A0 =A0 =A0Status: =A0new =A0Priority: =A0trivial =A0 =A0 =A0 =A0 =A0 =A0 | =A0 Milestone:
    Component: =A0coap =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 Version:
    =A0Severity: =A0- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0Keywords: --------------------------------+------------------------------------------= -

    Ticket URL: <https://svn.tools.ietf.org/wg/core/tra= c/ticket/55#comment:3>
    core <http://tools.ietf.org/core/>

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

    --001485f6d0dadb2052049623bcb2-- From ngocthanhdinh@gmail.com Sun Nov 28 19:16:11 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9DC43A6BB0 for ; Sun, 28 Nov 2010 19:16:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.404 X-Spam-Level: X-Spam-Status: No, score=-1.404 tagged_above=-999 required=5 tests=[AWL=-0.897, BAYES_05=-1.11, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, NORMAL_HTTP_TO_IP=0.001, WEIRD_PORT=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nPwmO6VvC4r3 for ; Sun, 28 Nov 2010 19:16:10 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 51B8A3A6BAE for ; Sun, 28 Nov 2010 19:16:10 -0800 (PST) Received: by bwz12 with SMTP id 12so3942073bwz.31 for ; Sun, 28 Nov 2010 19:17:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=kKCXkEWLpWVJQwoDTGStUvTXO+LRqJIj74TI8Fdh0oI=; b=NJ/7YnK4VZuxJ7m+8WVoihsyy4YK+JeUYzwx4JIp6KaGFYx412bSEXkRN+xTT/vS2m Rne6Igj/oY4ir5H9j/67hbYlGdp7tNxkN5AaEK1Orgma+oqHqyygEaZB95LuMX1NmXrM UQhHWDnKHEOxYDcaVCfiCPxDxxD6BvWZwnTLI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=P7fVmjvH6NF3qvC7sk66xRUDTNDZdwTxavn3p8JDrg6bQfuX/0BtjHZF2dKQdxBT7/ zZAW/n2VCH2+Cbx/9M3yEuR2dpfPgl3/cFGFPa6dV+etwZ0DJQiCs02z+gSo5hS9sGaA 9ay33kFPtyN3ShUBfm6rHG7QXgzR3oG5aAhm8= MIME-Version: 1.0 Received: by 10.204.113.195 with SMTP id b3mr4333015bkq.210.1291000586122; Sun, 28 Nov 2010 19:16:26 -0800 (PST) Received: by 10.204.116.7 with HTTP; Sun, 28 Nov 2010 19:16:26 -0800 (PST) Date: Mon, 29 Nov 2010 12:16:26 +0900 Message-ID: From: Thanh Ngoc To: contiki-developers@lists.sourceforge.net, core@ietf.org Content-Type: multipart/alternative; boundary=00163669754d5734600496287fab Subject: [core] Help me!!! Problem: running rest-example/rest-server-example.csc but "curl" command to get resource but it said: couldn't connect to host X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2010 03:16:11 -0000 --00163669754d5734600496287fab Content-Type: text/plain; charset=ISO-8859-1 Dear Every one, *could you help to solve the problem? i run rest-server-example, but when i used "curl" command to get result from the IP address as readme.txt, it told me: couldn't connect to host even though i can ping to this address and run everything successful as redme.txt .* do you know why did that problem happen? this is my detail : 1. i run rest-server-example.csc successful: "------------------------- user@instant-contiki:~/contiki-2.x/examples/rest-example$ *make TARGET=cooja rest-server-example.csc* .... INFO [main] (SerialSocketServer.java:120) - Listening on port: 60001 INFO [Thread-3] (SerialSocketServer.java:179) - Forwarder: socket -> serial port "---------------------------- 2. i run route connect-router-cooja successful "----------------------------------- user@instant-contiki:~/contiki-2.x/examples/rest-example$ *make connect-router-cooja* sudo ../../tools/tunslip6 -a 127.0.0.1 aaaa::1/64 slip connected to ``127.0.0.1:60001'' opened tun device ``/dev/tun0'' ifconfig tun0 inet `hostname` up ifconfig tun0 add aaaa::1/64 ifconfig tun0 tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:127.0.1.1 P-t-P:127.0.1.1 Mask:255.255.255.255 inet6 addr: aaaa::1/64 Scope:Global UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) SIN: 104 SUT: 104 SIN: 104 SUT: 104 "------------------------------- 3. I ping6 to address successful "------------------------------------------- user@instant-contiki:~$* ping6 aaaa::0212:7402:0002:0202* PING aaaa::0212:7402:0002:0202(aaaa::212:7402:2:202) 56 data bytes 64 bytes from aaaa::212:7402:2:202: icmp_seq=1 ttl=63 time=187 ms 64 bytes from aaaa::212:7402:2:202: icmp_seq=2 ttl=63 time=177 ms 64 bytes from aaaa::212:7402:2:202: icmp_seq=3 ttl=63 time=165 ms "----------------------------------------------------- 4. but when i use curl command to get result. it can not connect to host: "------------------------------------- user@instant-contiki:~/contiki-2.x/examples/rest-example$ *curl -H "User-Agent: curl" aaaa::0212:7402:0002:0202:8080/helloworld #get curl: (7) couldn't connect to host* "------------------------------------------- thank you very much, Ngoc Thanh --00163669754d5734600496287fab Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Every one,

    could you help to solve the problem?
    =A0i run= rest-server-example, but when i used "curl" command to get resul= t from the IP address as readme.txt, it told me: couldn't connect to ho= st
    even though i can ping to this address and run everything successful as red= me.txt .
    do you know why did that problem=A0 happen?
    this is my d= etail :


    1. i run rest-server-example.csc successful:
    "--= -----------------------
    user@instant-contiki:~/contiki-2.x/examples/rest-example$ make TARGET=3D= cooja rest-server-example.csc
    ....
    INFO [main] (SerialSocketServe= r.java:120) - Listening on port: 60001
    =A0INFO [Thread-3] (SerialSocketS= erver.java:179) - Forwarder: socket -> serial port
    "----------------------------
    2. i run route connect-router-cooja s= uccessful
    "-----------------------------------
    user@instant-cont= iki:~/contiki-2.x/examples/rest-example$ make connect-router-cooja sudo ../../tools/tunslip6 -a 127.0.0.1 aaaa::1/64
    slip connected to ``127.0.0.1:60001''
    opened tu= n device ``/dev/tun0''
    ifconfig tun0 inet `hostname` up
    ifcon= fig tun0 add aaaa::1/64
    ifconfig tun0

    tun0=A0=A0=A0=A0=A0 Link encap:UNSPEC=A0 HWaddr 00-00-= 00-00-00-00-00-00-00-00-00-00-00-00-00-00=A0
    =A0=A0=A0=A0=A0=A0=A0=A0= =A0 inet addr:127.0.1.1=A0 P-t-P:127.0.1.1=A0 Mask:255.255.255.255
    =A0= =A0=A0=A0=A0=A0=A0=A0=A0 inet6 addr: aaaa::1/64 Scope:Global
    =A0=A0=A0=A0=A0=A0=A0=A0=A0 UP POINTOPOINT RUNNING NOARP MULTICAST=A0 MTU:1= 500=A0 Metric:1
    =A0=A0=A0=A0=A0=A0=A0=A0=A0 RX packets:0 errors:0 droppe= d:0 overruns:0 frame:0
    =A0=A0=A0=A0=A0=A0=A0=A0=A0 TX packets:0 errors:0= dropped:0 overruns:0 carrier:0
    =A0=A0=A0=A0=A0=A0=A0=A0=A0 collisions:0= txqueuelen:500
    =A0=A0=A0=A0=A0=A0=A0=A0=A0 RX bytes:0 (0.0 B)=A0 TX bytes:0 (0.0 B)
    SIN: 104
    SUT: 104
    SIN: 104
    SUT: 104

    "----------------= ---------------
    3. I ping6 to address successful

    "----------= ---------------------------------
    user@instant-contiki:~$ ping6 aaaa::0212:7402:0002:0202
    PING aaaa= ::0212:7402:0002:0202(aaaa::212:7402:2:202) 56 data bytes
    64 bytes from = aaaa::212:7402:2:202: icmp_seq=3D1 ttl=3D63 time=3D187 ms
    64 bytes from = aaaa::212:7402:2:202: icmp_seq=3D2 ttl=3D63 time=3D177 ms
    64 bytes from aaaa::212:7402:2:202: icmp_seq=3D3 ttl=3D63 time=3D165 ms
    =

    "-----------------------------------------------------

    = 4. but when i use curl command to get result. it can not connect to host: "-------------------------------------
    user@instant-contiki:~/conti= ki-2.x/examples/rest-example$ curl -H "User-Agent: curl" aaaa:= :0212:7402:0002:0202:8080/helloworld #get
    curl: (7) couldn't connect= to host
    "-------------------------------------------


    thank you very= much,

    =A0=A0=A0=A0 Ngoc Thanh
    --00163669754d5734600496287fab-- From koo@comnets.uni-bremen.de Sun Nov 28 20:53:47 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A2B028C136 for ; Sun, 28 Nov 2010 20:53:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vQjG9fhZFAg8 for ; Sun, 28 Nov 2010 20:53:45 -0800 (PST) Received: from bugs.comnets.uni-bremen.de (bugs.comnets.uni-bremen.de [134.102.186.10]) by core3.amsl.com (Postfix) with ESMTP id 9275C28C13C for ; Sun, 28 Nov 2010 20:53:45 -0800 (PST) Received: from koojanalaptop (unknown [10.8.0.42]) by bugs.comnets.uni-bremen.de (Postfix) with ESMTP id BA14FD405B8; Mon, 29 Nov 2010 05:54:49 +0100 (CET) From: "Koojana Kuladinithi" To: "'Zach Shelby'" , "'Alexey Melnikov'" References: <4CE38524.60106@isode.com> In-Reply-To: Date: Mon, 29 Nov 2010 05:54:55 +0100 Message-ID: <002401cb8f81$91172f40$b3458dc0$@uni-bremen.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcuK8N1QUi4yI7wfSIuGU6US1JI0UQEkG0iA Content-Language: en-us Cc: 'core WG' Subject: Re: [core] Review of draft-ietf-core-coap-03.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2010 04:53:47 -0000 Here is one more typo.. Section 9 - Figure 7 (I think the code should be 200 instead of 80) Koojana -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Zach Shelby Sent: Tuesday, November 23, 2010 10:29 AM To: Alexey Melnikov Cc: core WG Subject: Re: [core] Review of draft-ietf-core-coap-03.txt Alexey, Thanks for the review, very helpful. I will now be making tickets for these. Some comments in-line. On Nov 17, 2010, at 9:32 AM, Alexey Melnikov wrote: > Hi, > I've decided to do IESG-type review of the document, as it seems to be getting close to being done. many of my comments are editorial in nature. In general I found the document to be well written. > > In Section 1 - the first reference to HTTP needs an Informative Reference. > > In Section 2.1.2 (Asynchronous response) - the first reference to "token option" needs a reference (either a cross reference, or an external reference). > >> 2.5.1. Option Processing >> >> If no options are to be included, the Option Count field is set to 0 >> below and the Payload (if any) immediately follows the Transaction >> ID. If options are to be included, the following rules apply. The >> number of options is placed in the Option Count field. Each option >> is then placed in order of Type, immediately following the >> Transaction ID with no padding. Upon reception, unknown options of >> class "elective" MUST be silently skipped. Unknown options of class >> "critical" in a Confirmable MUST cause the return of a response code >> "Critical Option not supported (CoAP 242)" including a copy of the >> critical option number in the payload of the response. > Does this need a new payload (MIME) type registration? Options don't seem to be considered to be a part of a payload (assuming my reading of Sections 3 and 3.1 is correct). Or did you mean that the options need to be returned as TLVs? This payload is meant to be text/plain. We also have a ticket to include a human readable error message: http://trac.tools.ietf.org/wg/core/trac/ticket/50 > >> 3.2.8. Token Option >> >> This option MUST NOT occur ore than once in a header. > typo: more > >> 5.1. Cache control >> In general, the origin server end-point is responsible for >> determining cache age. However, in some cases a client may wish to >> determine its own tolerance for cache staleness. In this case, a >> client may specify the Max-Age header during a GET request. If the >> client's Max-Age is of a shorter duration than the age of a cached > "than the remaining age"? Yep, will fix that. >> resource, then the proxy or end-point SHOULD perform a cache refresh. >> If the client specifies a Max-Age of zero seconds, then the response >> MUST discard the cached representation and return a fresh > In Section 7 - the first references to XMPP and SIP require Informative References. > >> 7. HTTP Mapping >> >> The caching and proxying of CoAP is specified in Section 5. In a >> similar manner, caching and proxying MAY be performed between CoAP >> and HTTP by an intermediate node. A proxy SHOULD respond with a 502 >> (Bad Gateway) error to HTTP requests which can not be successfully >> mapped to CoAP. CoAP transaction messages are transparent to >> request/response exchanges and MUST have no affect on a proxy >> function. > I am not entirely sure about the meaning of the last sentence. Can you clarify? You can consider CoAP to have two layers: - A transaction layer with transaction messages and a TID. - A request/response layer with Method/Code and options. Responses in CoAP may be deferred for example. This sentence just clarifies that the underlying CoAP transaction model has to be transparent to proxy functionality. For example you don't send an error message to an HTTP client while waiting for a deferred CoAP response. This will be explained better in coap-04. >> 10. Security Considerations >> >> Certificate: The device has an asymmetric key pair with a X.509 >> [RFC5280] certificate that binds it to its Authority Name and is >> signed by a some common trust root. The device also has a list or >> root trust anchors that can be used for validating a certificate. >> There may be an optional shared key that all the nodes that >> communicate have access too. >> >> The Authority Name in the certificate is the name that would be used >> in the Authority part of a CoAP URI. It is worth noting that this >> would typically not be either an IP address or DNS name but would >> instead be a long term unique identifier for the device such as the >> EUI-64. > I think this needs a reference. >> The discovery process used in the system would build up the >> mapping between IP addresses of the given devices and the Authority >> Name for each device. Some devices could have more than one >> Authority and would need more than a single certificate. > >> 10.2. Securing CoAP with DTLS >> >> Devices SHOULD support the Server Name Indication (SNI) to indicate >> their Authority Name in the SNI HostName field as defined in Section >> 3 of draft-ietf-tls-rfc4366-bis. > That document was approved by IESG, so this needs to be converted to a proper Normative Reference. >> This is needed so that when a host >> that acts as a virtual server for multiple Authorities receives a new >> DTLS connection, it knows which keys to use for the DTLS session. > >> 10.2.1. SharedKey & MultiKey Modes >> >> When forming a connection to a new node, the system selects an >> appropriate key based on which nodes it is trying to reach then forms >> a DTLS session using a PSK (Pre-Shared Key) mode of DTLS. >> Implementations SHOULD support the mandatory to implement cipher > I think this needs to be a MUST, conditional on DTLS being supported by the node. >> suite TLS_PSK_WITH_AES_128_CBC_SHA as specified in [RFC5246]. >> 10.2.2. Certificate Mode >> >> As with IPsec, DTLS should be configured with a cypher suite >> compatible with any possible hardware engine on the node, for example >> AES-CBC in the case of IEEE 802.15.4. Implementations SHOULD support > As above, I think this needs to be a MUST. >> the mandatory to implement cipher suite TLS_RSA_WITH_AES_128_CBC_SHA >> as specified in [RFC5246]. > The thinking behind the SHOULD in for these default cipher suites was that not all constrained devices would have hardware for AES-CBC (or AES-CCM is actually our goal). It is true for lots of IEEE 802.15.4 devices, but a different platform for e.g. industrial automation might need a totally different cipher suite for the encryption hardware it has support for. Should we require those industrial devices to support the default AES-CCM cipher suite also? > In Section 11 - IANA registration policy for COAP status codes and COAP MIME types is not defined. I suggest Expert Review at minimum (because of code/MIME type space is so small). > > Also, the coap:// URI scheme needs to be registered using the URI registration template. > > Should COAP methods be registered with IANA together with COAP status codes (as they are used in the same field)? Yes they should, thanks for pointing that out. Zach > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core -- Zach Shelby, Chief Nerd, Sensinode Ltd. 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 angelo.castellani@gmail.com Sun Nov 28 23:57:56 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 342D03A6B41 for ; Sun, 28 Nov 2010 23:57:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.877 X-Spam-Level: X-Spam-Status: No, score=-1.877 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5aL1WUICI-v for ; Sun, 28 Nov 2010 23:57:55 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 599703A6806 for ; Sun, 28 Nov 2010 23:57:55 -0800 (PST) Received: by qwg5 with SMTP id 5so3011183qwg.31 for ; Sun, 28 Nov 2010 23:59:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=UTs+PFwd90m0D3HgLsxSrP2LYbiR+C9KFzmVtsU1/PI=; b=PYHjLFbJSAYIM1PHeKPcDfSKY9aq8PFjWnlU4UEeT+idEeWpx+gPmBC5JVfaE4I2cb Ja0YR68YuPdCqxTAFG0cv73FLNowXiV3K7z0uPRUBk8obch1ab8EJ+Odb0140+enwUFM nkgDcppV21ve9PEXL3NbMIFRROfUr7lHgUe4Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=kbRqmCc1B5+Tpx3+GngjJvyQw3xDECjOjMcpiJHF8zC3cR0815LoGf7I4EdBF/dE6n 3KzHmNhZhskPI7AFRRg9w5rgdsY4XuTkedBFEEl6pK853xeWg95kccIPHivBd+XKuQFV b8QIKo/m1bxpkhMqPRsxzbRNr7m80yqNON0KY= Received: by 10.229.82.80 with SMTP id a16mr4555996qcl.241.1291017544144; Sun, 28 Nov 2010 23:59:04 -0800 (PST) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.229.13.194 with HTTP; Sun, 28 Nov 2010 23:58:44 -0800 (PST) In-Reply-To: References: <053.9ea9efc3dcb9be1a7f2b477e72d5fadd@tools.ietf.org> <012f01cb8ddd$2aacaf00$80060d00$@com> From: "Angelo P. Castellani" Date: Mon, 29 Nov 2010 08:58:44 +0100 X-Google-Sender-Auth: Fyq-Ed2x2HbjfP0Mcb_OUnpFmjM Message-ID: To: Klaus Hartke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: core@ietf.org Subject: Re: [core] coap #77 (new): Response code semantics X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2010 07:57:56 -0000 On Sat, Nov 27, 2010 at 22:25, Klaus Hartke wrote: > However, it was agreed on a long time ago that CoAP is a new > protocol =A0inspired by REST, which is easily mappable to HTTP, but not > just "compressed" HTTP. Definitions borrowed from HTTP, doesn't belong to CoAP. GET, POST, PUT, DELETE... 200 OK, 100 Continue, 404 Resource not found, etc. etc. This is HTTP, there is no "new protocol" here in these definitions. To highlight the *novelty* in the CoAP protocol, reasoned differences from HTTP make much more sense. Redefining with some minor difference, is not "creating a new protocol" On Sat, Nov 27, 2010 at 22:25, Klaus Hartke wrote: > So, no, we won't change the name, and we won't > define CoAP in differences to HTTP. Why talk on the ML if you already know what will be done? Isn't this a working group? Regards, Angelo From zach@sensinode.com Mon Nov 29 00:42:01 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AAF03A69CD for ; Mon, 29 Nov 2010 00:42:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GxTdxnSYuW+Q for ; Mon, 29 Nov 2010 00:42:00 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 793003A6AEB for ; Mon, 29 Nov 2010 00:41:58 -0800 (PST) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id oAT8h2EY021486 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 29 Nov 2010 10:43:02 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-461--819628872; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: Date: Mon, 29 Nov 2010 10:43:03 +0200 Message-Id: <5F58F86A-FC47-4052-8A7E-41B30AE142CD@sensinode.com> References: <053.9ea9efc3dcb9be1a7f2b477e72d5fadd@tools.ietf.org> <012f01cb8ddd$2aacaf00$80060d00$@com> To: "Angelo P. Castellani" X-Mailer: Apple Mail (2.1081) Cc: core@ietf.org, Klaus Hartke Subject: Re: [core] coap #77 (new): Response code semantics X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2010 08:42:01 -0000 --Apple-Mail-461--819628872 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I don't understand exactly what you guys are debating about here. The = CoAP specification is already in pretty good shape, and we have found a = reasonable balance between being a new protocol and re-using HTTP = methods and codes. As Klaus mentioned, already long ago we decided = against calling this some kind of HTTP "light". Let's not waste energy = on that. You started out by debating what should be included in the Annex on = response codes. A ticket was made to better define (there is just a = table right now) the semantics of response codes. That is, how much text = should we write about each response code. I think the answer to that is = pretty simple: We make a sub-section for each response code. If the = semantic is exactly the same as in RFC2616, then just reference. If = there are some small differences, then explain them. OK? Zach On Nov 29, 2010, at 9:58 AM, Angelo P. Castellani wrote: > On Sat, Nov 27, 2010 at 22:25, Klaus Hartke wrote: >> However, it was agreed on a long time ago that CoAP is a new >> protocol inspired by REST, which is easily mappable to HTTP, but not >> just "compressed" HTTP. >=20 > Definitions borrowed from HTTP, doesn't belong to CoAP. >=20 > GET, POST, PUT, DELETE... 200 OK, 100 Continue, 404 Resource not > found, etc. etc. >=20 > This is HTTP, there is no "new protocol" here in these definitions. >=20 > To highlight the *novelty* in the CoAP protocol, reasoned differences > from HTTP make much more sense. >=20 > Redefining with some minor difference, is not "creating a new = protocol" >=20 > On Sat, Nov 27, 2010 at 22:25, Klaus Hartke wrote: >> So, no, we won't change the name, and we won't >> define CoAP in differences to HTTP. >=20 > Why talk on the ML if you already know what will be done? Isn't this a > working group? >=20 > Regards, > Angelo > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 --Apple-Mail-461--819628872 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9 fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb 6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja 5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I 2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTEyOTA4NDMw NFowIwYJKoZIhvcNAQkEMRYEFIVKDwRp81+6cHmGNMS1J3de6POHMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAFsY4/gsJrwWglT0SuE9EdCidGGxYt4uxQ8CP1eKWDVDzuTRJRAfoCtR nXH0ViIQ/MzLdWEPSKvyHFHefU6xCY4UoPBhTOjbI58RnPIhuIOEHgsl1HodUjZpP98BNBeOcjwv RNWRGTimcJyaR/VBvyR1sZtxhzu04k2d24sZKWss3V/s2SdVa3TNzDL43FRSJvjc4cLPs7+Mw4Vx THGiYmUgg1TXzKC7iMNYMU1beYfAw6/J+HIZNtPU2+B+67SnbMMsi92w//2yFgbXfGBk11SvWKTF T0D3btiYfLluqyGmBvpwT/d6nHRA6RDZhdyokMSw4HILCaZsJNgDqpaoFGQAAAAAAAA= --Apple-Mail-461--819628872-- From tianlinyi@huawei.com Mon Nov 29 00:53:57 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47D0A3A6B41 for ; Mon, 29 Nov 2010 00:53:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.706 X-Spam-Level: X-Spam-Status: No, score=-1.706 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VV+culTZhlE3 for ; Mon, 29 Nov 2010 00:53:56 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id CE1E43A69CD for ; Mon, 29 Nov 2010 00:53:55 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LCN00JWS210TM@szxga04-in.huawei.com> for core@ietf.org; Mon, 29 Nov 2010 16:53:24 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LCN00JUR210FQ@szxga04-in.huawei.com> for core@ietf.org; Mon, 29 Nov 2010 16:53:24 +0800 (CST) Received: from [172.24.1.3] (Forwarded-For: [59.50.41.2]) by szxmc04-in.huawei.com (mshttpd); Mon, 29 Nov 2010 16:53:24 +0800 Date: Mon, 29 Nov 2010 16:53:24 +0800 From: tianlinyi 00175029 In-reply-to: <5F58F86A-FC47-4052-8A7E-41B30AE142CD@sensinode.com> To: Zach Shelby Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: multipart/mixed; boundary="Boundary_(ID_pz5eJU9AXqHpAh2avmPXTQ)" Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal References: <053.9ea9efc3dcb9be1a7f2b477e72d5fadd@tools.ietf.org> <012f01cb8ddd$2aacaf00$80060d00$@com> <5F58F86A-FC47-4052-8A7E-41B30AE142CD@sensinode.com> Cc: Klaus Hartke , core@ietf.org Subject: Re: [core] coap #77 (new): Response code semantics X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2010 08:53:57 -0000 This is a multi-part message in MIME format. --Boundary_(ID_pz5eJU9AXqHpAh2avmPXTQ) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Content-disposition: inline Hi=2C Zach and all I agree with Zach=2E However you missed one point i made=3A If we list all codes from HTTP=2C we=27d better describe some codes are n= ot used by CoAP=2E If we just list part of them=2C then Zach=27s suggesti= on would be fine=2E Cheers=2C Linyi ----- =D4=AD=D3=CA=BC=FE ----- =B7=A2=BC=FE=C8=CB=3A Zach Shelby =3Czach=40sensinode=2Ecom=3E =C8=D5=C6=DA=3A =D0=C7=C6=DA=D2=BB=2C =CA=AE=D2=BB=D4=C2 29=C8=D5=2C 2010= =CF=C2=CE=E74=3A43 =D6=F7=CC=E2=3A Re=3A =5Bcore=5D coap =2377 (new)=3A Response code semant= ics =CA=D5=BC=FE=C8=CB=3A =22Angelo P=2E Castellani=22 =3Cangelo=40castellani= =2Enet=3E =B3=AD=CB=CD=3A core=40ietf=2Eorg=2C Klaus Hartke =3Chartke=40tzi=2Eorg=3E= =3E Hi=2C =3E = =3E I don=27t understand exactly what you guys are debating about here=2E= = =3E The CoAP specification is already in pretty good shape=2C and we = =3E have found a reasonable balance between being a new protocol and = =3E re-using HTTP methods and codes=2E As Klaus mentioned=2C already long= = =3E ago we decided against calling this some kind of HTTP =22light=22=2E = =3E Let=27s not waste energy on that=2E =3E = =3E You started out by debating what should be included in the Annex = =3E on response codes=2E A ticket was made to better define (there is = =3E just a table right now) the semantics of response codes=2E That is=2C= = =3E how much text should we write about each response code=2E I think = =3E the answer to that is pretty simple=3A We make a sub-section for = =3E each response code=2E If the semantic is exactly the same as in = =3E RFC2616=2C then just reference=2E If there are some small differences= =2C = =3E then explain them=2E OK=3F =3E = =3E Zach =3E = =3E On Nov 29=2C 2010=2C at 9=3A58 AM=2C Angelo P=2E Castellani wrote=3A =3E = =3E =3E On Sat=2C Nov 27=2C 2010 at 22=3A25=2C Klaus Hartke =3Chartke=40t= zi=2Eorg=3E wrote=3A =3E =3E=3E However=2C it was agreed on a long time ago that CoAP is a new= =3E =3E=3E protocol inspired by REST=2C which is easily mappable to HTTP= =2C = =3E but not =3E =3E=3E just =22compressed=22 HTTP=2E =3E =3E = =3E =3E Definitions borrowed from HTTP=2C doesn=27t belong to CoAP=2E =3E =3E = =3E =3E GET=2C POST=2C PUT=2C DELETE=2E=2E=2E 200 OK=2C 100 Continue=2C 4= 04 Resource not =3E =3E found=2C etc=2E etc=2E =3E =3E = =3E =3E This is HTTP=2C there is no =22new protocol=22 here in these defi= nitions=2E =3E =3E = =3E =3E To highlight the *novelty* in the CoAP protocol=2C reasoned = =3E differences=3E from HTTP make much more sense=2E =3E =3E = =3E =3E Redefining with some minor difference=2C is not =22creating a new= = =3E protocol=22=3E = =3E =3E On Sat=2C Nov 27=2C 2010 at 22=3A25=2C Klaus Hartke =3Chartke=40t= zi=2Eorg=3E wrote=3A =3E =3E=3E So=2C no=2C we won=27t change the name=2C and we won=27t =3E =3E=3E define CoAP in differences to HTTP=2E =3E =3E = =3E =3E Why talk on the ML if you already know what will be done=3F Isn=27= t = =3E this a =3E =3E working group=3F =3E =3E = =3E =3E Regards=2C =3E =3E Angelo =3E =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =3E =3E core mailing list =3E =3E core=40ietf=2Eorg =3E =3E https=3A//www=2Eietf=2Eorg/mailman/listinfo/core =3E = =3E -- = =3E Zach Shelby=2C Chief Nerd=2C Sensinode Ltd=2E =3E http=3A//zachshelby=2Eorg - My blog =22On the Internet of Things=22 =3E http=3A//6lowpan=2Enet - My book =226LoWPAN=3A The Wireless Embedded = Internet=22 =3E Mobile=3A +358 40 7796297 =3E = =3E --Boundary_(ID_pz5eJU9AXqHpAh2avmPXTQ) Content-type: text/x-vcard; name=t00175029.vcf; charset=gb2312 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=t00175029.vcf Content-description: Card for tianlinyi 00175029 begin:vcard n:34932;tianlinyi fn:tianlinyi 34932 version:2.1 email;internet:tianlinyi@huawei.com end:vcard --Boundary_(ID_pz5eJU9AXqHpAh2avmPXTQ)-- From zach@sensinode.com Mon Nov 29 00:58:36 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A7A83A6BDB for ; Mon, 29 Nov 2010 00:58:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.506 X-Spam-Level: X-Spam-Status: No, score=-3.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2MqfNBqG8nTO for ; Mon, 29 Nov 2010 00:58:35 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 19E713A6B4E for ; Mon, 29 Nov 2010 00:58:34 -0800 (PST) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id oAT8xXrb024452 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 29 Nov 2010 10:59:34 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-463--818637956; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: Date: Mon, 29 Nov 2010 10:59:34 +0200 Message-Id: <84C3824E-5EA8-4278-94E0-AF7C0A5F2C4B@sensinode.com> References: <053.9ea9efc3dcb9be1a7f2b477e72d5fadd@tools.ietf.org> <012f01cb8ddd$2aacaf00$80060d00$@com> <5F58F86A-FC47-4052-8A7E-41B30AE142CD@sensinode.com> To: tianlinyi 00175029 X-Mailer: Apple Mail (2.1081) Cc: Klaus Hartke , core@ietf.org Subject: Re: [core] coap #77 (new): Response code semantics X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2010 08:58:36 -0000 --Apple-Mail-463--818637956 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 29, 2010, at 10:53 AM, tianlinyi 00175029 wrote: > I agree with Zach. However you missed one point i made: > If we list all codes from HTTP, we'd better describe some codes are = not used by CoAP. If we just list part of them, then Zach's suggestion = would be fine. Good point. The intention is that only the codes Table 3 of Section 11.1 = are used by CoAP. A sub-section is planned for each code according to = this ticket. http://tools.ietf.org/html/draft-ietf-core-coap-03#section-11.1 We should also add a reference column to this table. Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 --Apple-Mail-463--818637956 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9 fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb 6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja 5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I 2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTEyOTA4NTkz NFowIwYJKoZIhvcNAQkEMRYEFFcPUAgLg7MwRcbFLOE1LcqMwJxnMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBADBLN4+QFktSUm7lOcCkC7uXYS5mvrtSv1PMiFGCmC9HLzup2KEeVfMU vieT+7TlQZg/NUEhF39RAro8H1gi9ZCnaqKbcQxoiso2K1/RUdb5K+qm/7xca8W2IMM5kIts83Sl or893eLRahpTOE1xiVEOkBo9Vqg4GItmWimGUr89qu+O3dzdk/72XZaS19SmyJxLXgoBTbHn0n/4 mML2cFM0P85wM5B48m4R5Dm6mNFlxhlJkb5S9F2pTROuRdWkWRhlS0vH7PsSMdA4bKEZQwgzxFNc qsaUrE7mcK4IfdD/b1RqDGSIm8cb3mr8K75IdRFT5WqReIajrJ9LGk32Y2wAAAAAAAA= --Apple-Mail-463--818637956-- From angelo.castellani@gmail.com Mon Nov 29 00:59:00 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9533F3A6BBD for ; Mon, 29 Nov 2010 00:59:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eAGRb4691Txk for ; Mon, 29 Nov 2010 00:58:59 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 567C93A6B4E for ; Mon, 29 Nov 2010 00:58:59 -0800 (PST) Received: by qyk11 with SMTP id 11so4514510qyk.10 for ; Mon, 29 Nov 2010 01:00:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=TAqRaI7ryZk6FegbT21l7YMw1+EsEyw9yPrrYzCzzRA=; b=nZbkwM0Pa+asThQ4qC7aWYvituBIKyLz6fLQjuLR2MWarmp+RewpFrK6VsXEk0AGPR TXYv13pOzfWegwCC9wDX3GuguP4c5oh+K+ScRYiUjBzDbPUCQLcDGMgtjWuXHK/1+tCx kDiS4gyuvHRWRIIr7NGW2KkDU3EQO5HxeWKMM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=BykXAMKJYF5a8gxJxRgduhqIUFYcuWSQH0EyZrzNr+mkkDvVFiM22OOBPai0asc8u7 0QZ8Ios2TRMD3rgUWYcl2ic5ojytdVuTYGj5CODXFB/IOtxT1PWG4c5nu9/U2Pl8BywK dSXAbUW+PKt0FsddUxKTVJ/SYFlPzTFRwP+N4= MIME-Version: 1.0 Received: by 10.229.74.65 with SMTP id t1mr4599999qcj.279.1291021208054; Mon, 29 Nov 2010 01:00:08 -0800 (PST) Sender: angelo.castellani@gmail.com Received: by 10.229.13.194 with HTTP; Mon, 29 Nov 2010 01:00:07 -0800 (PST) In-Reply-To: <5F58F86A-FC47-4052-8A7E-41B30AE142CD@sensinode.com> References: <053.9ea9efc3dcb9be1a7f2b477e72d5fadd@tools.ietf.org> <012f01cb8ddd$2aacaf00$80060d00$@com> <5F58F86A-FC47-4052-8A7E-41B30AE142CD@sensinode.com> Date: Mon, 29 Nov 2010 10:00:07 +0100 X-Google-Sender-Auth: DuNAooX99pzIxtJ-9gh0MPyYqKE Message-ID: From: "Angelo P. Castellani" To: Zach Shelby Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "core@ietf.org" , Klaus Hartke Subject: Re: [core] coap #77 (new): Response code semantics X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2010 08:59:00 -0000 Thanks Zach, defining the differences and referencing is the best solution in my opinion= too. Angelo On Monday, November 29, 2010, Zach Shelby wrote: > Hi, > > I don't understand exactly what you guys are debating about here. The CoA= P specification is already in pretty good shape, and we have found a reason= able balance between being a new protocol and re-using HTTP methods and cod= es. As Klaus mentioned, already long ago we decided against calling this so= me kind of HTTP "light". Let's not waste energy on that. > > You started out by debating what should be included in the Annex on respo= nse codes. A ticket was made to better define (there is just a table right = now) the semantics of response codes. That is, how much text should we writ= e about each response code. I think the answer to that is pretty simple: We= make a sub-section for each response code. If the semantic is exactly the = same as in RFC2616, then just reference. If there are some small difference= s, then explain them. OK? > > Zach > > On Nov 29, 2010, at 9:58 AM, Angelo P. Castellani wrote: > >> On Sat, Nov 27, 2010 at 22:25, Klaus Hartke wrote: >>> However, it was agreed on a long time ago that CoAP is a new >>> protocol =A0inspired by REST, which is easily mappable to HTTP, but not >>> just "compressed" HTTP. >> >> Definitions borrowed from HTTP, doesn't belong to CoAP. >> >> GET, POST, PUT, DELETE... 200 OK, 100 Continue, 404 Resource not >> found, etc. etc. >> >> This is HTTP, there is no "new protocol" here in these definitions. >> >> To highlight the *novelty* in the CoAP protocol, reasoned differences >> from HTTP make much more sense. >> >> Redefining with some minor difference, is not "creating a new protocol" >> >> On Sat, Nov 27, 2010 at 22:25, Klaus Hartke wrote: >>> So, no, we won't change the name, and we won't >>> define CoAP in differences to HTTP. >> >> Why talk on the ML if you already know what will be done? Isn't this a >> working group? >> >> Regards, >> Angelo >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core > > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://zachshelby.org =A0- My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 > > From salvatore.loreto@ericsson.com Mon Nov 29 01:23:51 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 776E828C11A for ; Mon, 29 Nov 2010 01:23:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.544 X-Spam-Level: X-Spam-Status: No, score=-106.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BgRNWVUIR3sq for ; Mon, 29 Nov 2010 01:23:50 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id D83C928C105 for ; Mon, 29 Nov 2010 01:23:49 -0800 (PST) X-AuditID: c1b4fb39-b7bafae000002a42-08-4cf37169b7ea Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 8D.7D.10818.96173FC4; Mon, 29 Nov 2010 10:24:58 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.2.234.1; Mon, 29 Nov 2010 10:24:56 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 2C18428DF for ; Mon, 29 Nov 2010 11:24:57 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id E458F500FB for ; Mon, 29 Nov 2010 11:24:56 +0200 (EET) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 9EE324FE7F for ; Mon, 29 Nov 2010 11:24:56 +0200 (EET) Message-ID: <4CF37168.2040105@ericsson.com> Date: Mon, 29 Nov 2010 11:24:56 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: core@ietf.org References: <053.9ea9efc3dcb9be1a7f2b477e72d5fadd@tools.ietf.org> <012f01cb8ddd$2aacaf00$80060d00$@com> <5F58F86A-FC47-4052-8A7E-41B30AE142CD@sensinode.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: Re: [core] coap #77 (new): Response code semantics X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2010 09:23:51 -0000 On 11/29/10 11:00 AM, Angelo P. Castellani wrote: > Thanks Zach, > defining the differences and referencing is the best solution in my opinion too. +1 /Sal > Angelo > > On Monday, November 29, 2010, Zach Shelby wrote: >> Hi, >> >> I don't understand exactly what you guys are debating about here. The CoAP specification is already in pretty good shape, and we have found a reasonable balance between being a new protocol and re-using HTTP methods and codes. As Klaus mentioned, already long ago we decided against calling this some kind of HTTP "light". Let's not waste energy on that. >> >> You started out by debating what should be included in the Annex on response codes. A ticket was made to better define (there is just a table right now) the semantics of response codes. That is, how much text should we write about each response code. I think the answer to that is pretty simple: We make a sub-section for each response code. If the semantic is exactly the same as in RFC2616, then just reference. If there are some small differences, then explain them. OK? >> >> Zach >> >> On Nov 29, 2010, at 9:58 AM, Angelo P. Castellani wrote: >> >>> On Sat, Nov 27, 2010 at 22:25, Klaus Hartke wrote: >>>> However, it was agreed on a long time ago that CoAP is a new >>>> protocol inspired by REST, which is easily mappable to HTTP, but not >>>> just "compressed" HTTP. >>> Definitions borrowed from HTTP, doesn't belong to CoAP. >>> >>> GET, POST, PUT, DELETE... 200 OK, 100 Continue, 404 Resource not >>> found, etc. etc. >>> >>> This is HTTP, there is no "new protocol" here in these definitions. >>> >>> To highlight the *novelty* in the CoAP protocol, reasoned differences >>> from HTTP make much more sense. >>> >>> Redefining with some minor difference, is not "creating a new protocol" >>> >>> On Sat, Nov 27, 2010 at 22:25, Klaus Hartke wrote: >>>> So, no, we won't change the name, and we won't >>>> define CoAP in differences to HTTP. >>> Why talk on the ML if you already know what will be done? Isn't this a >>> working group? >>> >>> Regards, >>> Angelo >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >> -- >> Zach Shelby, Chief Nerd, Sensinode Ltd. >> http://zachshelby.org - My blog "On the Internet of Things" >> http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" >> Mobile: +358 40 7796297 >> >> > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core -- Salvatore Loreto www.sloreto.com From cabo@tzi.org Mon Nov 29 01:37:05 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 313003A6BF9 for ; Mon, 29 Nov 2010 01:37:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.36 X-Spam-Level: X-Spam-Status: No, score=-106.36 tagged_above=-999 required=5 tests=[AWL=-0.111, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jkgxwwit0PDq for ; Mon, 29 Nov 2010 01:37:02 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 1C76C28C120 for ; Mon, 29 Nov 2010 01:36:59 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id oAT9c1eB010564; Mon, 29 Nov 2010 10:38:01 +0100 (CET) Received: from [192.168.217.101] (p5489A485.dip.t-dialin.net [84.137.164.133]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 817DBCA9; Mon, 29 Nov 2010 10:38:00 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Mon, 29 Nov 2010 10:37:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <057.cbcb8082fb49a1a254def976b454a663@tools.ietf.org> <066.34c8fead60f7ba790f916b74f04e04ab@tools.ietf.org> To: Eric Rescorla X-Mailer: Apple Mail (2.1082) Cc: core WG Subject: Re: [core] coap #55 (new): AES-CCM vs. AES-CBC X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2010 09:37:05 -0000 On Nov 28, 2010, at 22:35, Eric Rescorla wrote: > I'm not sure that non-normative text really does the job here. If = you're going to use > CCM, you pretty much need automatic key management. Is that something = you intend > t require or not... Interesting discussion. I view CoAP as a protocol standard, not a system standard. (And, yes, I'm fully aware that the security of a single protocol often = cannot be evaluated without speculating about the surrounding system -- = this has long been one of the unresolved dilemmas in IETF = standardization.) We are not defining new security mechanisms, we are pointing out ones = that CoAP would work well with. (Alexey's "must implement" discussion is relevant here, but somewhat = orthogonal to my current point.) To me, your comment reads a bit like "RFC 4309's security considerations = are insufficient, so let's fix them in CoAP". I'd rather reference them (possibly cite them, and maybe reinforce them = where they are worded a bit too cautiously) as opposed to = second-guess/"improve" them. Getting normative about the system (as opposed to the protocol) should = be avoided whenever possible. (But I don't have a strong opinion on the specific issue of ruling out = static keys for AES-CCM, which appears to remain a valid restriction = even while the system around the protocol changes.) Gruesse, Carsten PS.: Interestingly, RFC 4309 doesn't even spend a SHOULD: Therefore, AES CCM should not be used with statically configured keys. I'd like to know the history on that one. From tianlinyi@huawei.com Mon Nov 29 01:37:21 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39CBB28C11D for ; Mon, 29 Nov 2010 01:37:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.706 X-Spam-Level: X-Spam-Status: No, score=-1.706 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4DrAi7rjX5uB for ; Mon, 29 Nov 2010 01:37:17 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 6BA363A6BF9 for ; Mon, 29 Nov 2010 01:37:17 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LCN00BW4421QW@szxga03-in.huawei.com> for core@ietf.org; Mon, 29 Nov 2010 17:37:13 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LCN00LFG421UB@szxga03-in.huawei.com> for core@ietf.org; Mon, 29 Nov 2010 17:37:13 +0800 (CST) Received: from [172.24.1.3] (Forwarded-For: [59.50.41.2]) by szxmc04-in.huawei.com (mshttpd); Mon, 29 Nov 2010 17:37:13 +0800 Date: Mon, 29 Nov 2010 17:37:13 +0800 From: tianlinyi 00175029 In-reply-to: To: Klaus Hartke Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: multipart/mixed; boundary="Boundary_(ID_gxTcZhJauDRSa+OmTNPubg)" Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal References: <234B6B562A62654E93691A30A71B12CB2119AEBDF2@STAFFMBX-1.lunet.lboro.ac.uk> <014901cb8e0f$29c597a0$7d50c6e0$@com> Cc: core@ietf.org Subject: [core] :Re: Draft needs Asynchronous transaction details X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2010 09:37:21 -0000 This is a multi-part message in MIME format. --Boundary_(ID_gxTcZhJauDRSa+OmTNPubg) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Content-disposition: inline Hi=2C Klaus I fully understand the difference between purpose of Transaction ID and T= oken=2E I also understand the sync and async responses=2E However you didn=27t answer the question what code should be returned=2C = 100 or 202=3F I noticed that 202 was not defined in CoAP=2E There is also no discriptio= n what 100 means=2E So that=27s why i refer to HTTP spec=2E If we follow = the same definition=2C it looks like 100 is not appropriate and 202 shoul= d be used in first ACK (acknowledge the arriavl of the request and indica= tion a seperate response will be sent later)=2E Cheers=2C Linyi ----- =D4=AD=D3=CA=BC=FE ----- =B7=A2=BC=FE=C8=CB=3A Klaus Hartke =3Chartke=40tzi=2Eorg=3E =C8=D5=C6=DA=3A =D0=C7=C6=DA=C8=D5=2C =CA=AE=D2=BB=D4=C2 28=C8=D5=2C 2010= =C9=CF=CE=E75=3A03 =D6=F7=CC=E2=3A Re=3A =5Bcore=5D Draft needs Asynchronous transaction det= ails =CA=D5=BC=FE=C8=CB=3A core=40ietf=2Eorg =3E Linyi Tian wrote=3A =3E =3E I believe the status code in ACK should be 202 =22Accepted=22 =3E = =3E No=2E =3E = =3E When a client sends a confirmable message with a request to a server=2C= =3E two things happen=3A =3E = =3E 1=2E The server acknowledges that it received the confirmable message= =2C =3E so the client can stop retransmitting=2E =3E = =3E 2=2E The server processes the request and sends a response=2E =3E = =3E These two things are separate and not coupled in any way=2E But they = can =3E happen at the same time (=22immediate response=22) or at different ti= mes =3E (=22deferred response=22)=2E =3E = =3E If acknowledgement and response happen at different times=2C the =3E acknowledgement does not carry a response=2E =3E = =3E Message that carry neither request nor response have Code 0=2C no =3E options and no payload=2E =3E = =3E = =3E Klaus =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F =3E core mailing list =3E core=40ietf=2Eorg =3E https=3A//www=2Eietf=2Eorg/mailman/listinfo/core =3E --Boundary_(ID_gxTcZhJauDRSa+OmTNPubg) Content-type: text/x-vcard; name=t00175029.vcf; charset=gb2312 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=t00175029.vcf Content-description: Card for tianlinyi 00175029 begin:vcard n:34932;tianlinyi fn:tianlinyi 34932 version:2.1 email;internet:tianlinyi@huawei.com end:vcard --Boundary_(ID_gxTcZhJauDRSa+OmTNPubg)-- From matthieu.vial@fr.non.schneider-electric.com Mon Nov 29 02:17:21 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECC743A6C0D; Mon, 29 Nov 2010 02:17:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.183 X-Spam-Level: X-Spam-Status: No, score=-3.183 tagged_above=-999 required=5 tests=[AWL=0.415, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p5x5XukIHffu; Mon, 29 Nov 2010 02:17:21 -0800 (PST) Received: from mailX02.eud.schneider-electric.com (mailx02.eud.schneider-electric.com [205.167.7.38]) by core3.amsl.com (Postfix) with ESMTP id A52923A6BEB; Mon, 29 Nov 2010 02:17:20 -0800 (PST) Received: from ateui02.Schneider-Electric.com ([10.198.14.10]) by mailX02.eud.schneider-electric.com with ESMTP id 2010112910584389-135735 ; Mon, 29 Nov 2010 10:58:43 +0100 In-Reply-To: <84C3824E-5EA8-4278-94E0-AF7C0A5F2C4B@sensinode.com> To: Zach Shelby X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: matthieu.vial@fr.non.schneider-electric.com Date: Mon, 29 Nov 2010 11:18:25 +0100 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on ATEUI02.Schneider-Electric.com/T/SVR/Schneider at 29/11/2010 11:18:27, Itemize by SMTP Server on AXEU2OUT.schneider-electric.com/X/SVR/SEIxtra at 29/11/2010 10:58:43, Serialize by Router on AXEU2OUT.schneider-electric.com/X/SVR/SEIxtra at 29/11/2010 10:58:45, Serialize complete at 29/11/2010 10:58:45 Content-type: multipart/alternative; Boundary="0__=4EBBFD79DFA498378f9e8a93df938690918c4EBBFD79DFA49837" Content-Disposition: inline Cc: core-bounces@ietf.org, core@ietf.org Subject: Re: [core] coap #77 (new): Response code semantics X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2010 10:17:22 -0000 --0__=4EBBFD79DFA498378f9e8a93df938690918c4EBBFD79DFA49837 Content-transfer-encoding: quoted-printable Content-type: text/plain; charset=US-ASCII Zach, >The intention is that only the codes Table 3 of Section 11.1 are used = by CoAP. A sub-section is planned for each code according to this ticket. http://tools.ietf.org/html/draft-ietf-core-coap-03#section-11.1 We should also add a reference column to this table. Personnaly, I find a bit confusing the fact that CoAP specification use= s HTTP status code to describe its own behaviour because actually it is n= ot the real code that is sent/received and sometimes there are differences= with HTTP. I would prefer the text 2.3.1. GET The GET method retrieves the information of the resource identified by the request URI. Upon success a 200 (OK) response SHOULD be sent= . defined like that 2.3.1. GET The GET method retrieves the information of the resource identified by the request URI. Upon success a SUC_OK response SHOULD be sent. and then define Table 3 of Section 11.1 like that +-------------+------+------------------+----------------------+ | Class | Code | CoAP Label | HTTP Name | +-------------+------+------------------+----------------------+ | Success | 0x20 | SUC_OK | 200 OK (*) | | ... | ... | ... | ... | | Redirection | 0x40 | RED_NOT_MODIFIED | 304 Not modified (*) | | ... | ... | ... | ... | | Errror | 0x60 | ERR_BAD_REQUEST | 400 Bad Request | | ... | ... | ... | ... | (*) means the conversion is not necessarily straightforward Then explain the differences for each (*) in a section: Example: SUC_OK not supported for POST in CoAP I find it easier that way to optimize the extraction of a class of code= s and to introduce differences with HTTP or new codes. Does it make sense ? Matthieu= --0__=4EBBFD79DFA498378f9e8a93df938690918c4EBBFD79DFA49837 Content-transfer-encoding: quoted-printable Content-type: text/html; charset=US-ASCII Content-Disposition: inline

    Zach,

    >The intention is that only the codes Tab= le 3 of Section 11.1 are used by CoAP. A sub-section is planned for eac= h code according to this ticket.
    http://tools.ietf.org/html/draft-ietf-c= ore-coap-03#section-11.1
    We should also add a reference column to thi= s table.


    Personnaly, I find a bit confusing the fact = that CoAP specification uses HTTP status code to describe its own behav= iour because actually it is not the real code that is sent/received and= sometimes there are differences with HTTP.

    I would prefer the text
    2.3.1. GET
    The GET method retrieves the information = of the resource identified
    by the request URI. Upon success a 200 (= OK) response SHOULD be sent.

    defined like that
    2.3.1. GET
    The GET method retrieves the information = of the resource identified
    by the request URI. Upon success a SUC_O= K response SHOULD be sent.

    and then define Table 3 of Section 11.1 like= that
    +-------------+------+------------------+---= -------------------+
    | Class | Code | CoAP Label | HT= TP Name |
    +-------------+------+------------------+---= -------------------+
    | Success | 0x20 | SUC_OK | 20= 0 OK (*) |
    | ... | ... | ... | ..= . |
    | Redirection | 0x40 | RED_NOT_MODIFIED | 30= 4 Not modified (*) |
    | ... | ... | ... | ..= . |
    | Errror | 0x60 | ERR_BAD_REQUEST | 40= 0 Bad Request |
    | ... | ... | ... | ..= . |

    (*) means the conversion is not necessarily = straightforward

    Then explain the differences for each (*) in= a section:
    Example: SUC_OK not supported for POST in Co= AP

    I find it easier that way to optimize the ex= traction of a class of codes and to introduce differences with HTTP or = new codes.
    Does it make sense ?

    Matthieu= --0__=4EBBFD79DFA498378f9e8a93df938690918c4EBBFD79DFA49837-- From zach@sensinode.com Mon Nov 29 03:18:43 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1665C3A6A09; Mon, 29 Nov 2010 03:18:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.513 X-Spam-Level: X-Spam-Status: No, score=-3.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GLVEf0VApIeM; Mon, 29 Nov 2010 03:18:41 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 58A273A69A6; Mon, 29 Nov 2010 03:18:40 -0800 (PST) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id oATBJjhk019850 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 29 Nov 2010 13:19:46 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-478--810225230; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: Date: Mon, 29 Nov 2010 13:19:47 +0200 Message-Id: References: To: matthieu.vial@fr.non.schneider-electric.com X-Mailer: Apple Mail (2.1081) Cc: core-bounces@ietf.org, core@ietf.org Subject: Re: [core] coap #77 (new): Response code semantics X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2010 11:18:43 -0000 --Apple-Mail-478--810225230 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I like this proposal, and have noticed quite a few people confused by = the current use of e.g. 200 (OK) in the text.=20 Zach On Nov 29, 2010, at 12:18 PM, = matthieu.vial@fr.non.schneider-electric.com wrote: > Zach, >=20 > >The intention is that only the codes Table 3 of Section 11.1 are used = by CoAP. A sub-section is planned for each code according to this = ticket. > http://tools.ietf.org/html/draft-ietf-core-coap-03#section-11.1 > We should also add a reference column to this table. >=20 >=20 > Personnaly, I find a bit confusing the fact that CoAP specification = uses HTTP status code to describe its own behaviour because actually it = is not the real code that is sent/received and sometimes there are = differences with HTTP. >=20 > I would prefer the text > 2.3.1. GET > The GET method retrieves the information of the resource identified > by the request URI. Upon success a 200 (OK) response SHOULD be sent. >=20 > defined like that > 2.3.1. GET > The GET method retrieves the information of the resource identified > by the request URI. Upon success a SUC_OK response SHOULD be sent. >=20 > and then define Table 3 of Section 11.1 like that > +-------------+------+------------------+----------------------+ > | Class | Code | CoAP Label | HTTP Name | > +-------------+------+------------------+----------------------+ > | Success | 0x20 | SUC_OK | 200 OK (*) | > | ... | ... | ... | ... | > | Redirection | 0x40 | RED_NOT_MODIFIED | 304 Not modified (*) | > | ... | ... | ... | ... | > | Errror | 0x60 | ERR_BAD_REQUEST | 400 Bad Request | > | ... | ... | ... | ... | >=20 > (*) means the conversion is not necessarily straightforward >=20 > Then explain the differences for each (*) in a section: > Example: SUC_OK not supported for POST in CoAP >=20 > I find it easier that way to optimize the extraction of a class of = codes and to introduce differences with HTTP or new codes. > Does it make sense ? >=20 > Matthieu >=20 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 --Apple-Mail-478--810225230 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9 fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb 6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja 5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I 2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTEyOTExMTk0 N1owIwYJKoZIhvcNAQkEMRYEFN+XI+ESi8jVGbHGG5rEe666FahTMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAHRrr4rSIZd7/oonJP9fm3W5qcolfcVK83WoGS1hIe0XGwZ3eeNyejS8 J/XjptA4b5nhwt7axTso6XPTEu1xsBzGQWD3LcKnOCppgmXi1VrZS0epKt07GctPO9eKXa5Kxnwj 3/Vj2wB5fWR0O2ppG/xG0SFbTW47UxPy55VvhZQbOECDztMxbEGqMgH3FGdaLg41QI9Z7SFy7ONz EpjFA/a2ch/b+/Hse8nlO3c+lDgDlbM/YtX7C03nYJe9eJFgpTeeLMHauzKvjU4dWS7ec0T2o/jd OHmfVqq1xrf0mPlLG/6zO0h+6/cbxWzS7rysY3XPGWLBqpDuyIzuIaPTi+QAAAAAAAA= --Apple-Mail-478--810225230-- From hartke@tzi.org Mon Nov 29 05:42:04 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9118D28C12A for ; Mon, 29 Nov 2010 05:42:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GbQUs+DqWWMl for ; Mon, 29 Nov 2010 05:41:53 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 9B43828C126 for ; Mon, 29 Nov 2010 05:41:26 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from webmail.informatik.uni-bremen.de (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id oATDg7Ph028832 for ; Mon, 29 Nov 2010 14:42:12 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 29 Nov 2010 14:42:06 +0100 From: Klaus Hartke To: In-Reply-To: References: <234B6B562A62654E93691A30A71B12CB2119AEBDF2@STAFFMBX-1.lunet.lboro.ac.uk> <014901cb8e0f$29c597a0$7d50c6e0$@com> Message-ID: <55435af226a4a5495458aa0301560ae7@webmail.informatik.uni-bremen.de> X-Sender: hartke@tzi.org User-Agent: Roundcube Webmail/0.4.2 Subject: Re: [core] :Re: Draft needs Asynchronous transaction details X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2010 13:42:04 -0000 Linyi Tian wrote: > However you didn't answer the question what code should be returned, > 100 or 202? Neither 100 nor 202. Here's an example: C: CON + GET coap://server/resource (token=0x5f) S: ACK S: CON + S_OK (token=0x5f) "Hello World" C: ACK Both ACKs in this example do not carry a response. So the Code is 0. The messages are in detail: C: CON + GET coap://server/resource (token=0x5f) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | 0 | 3 | GET = 1 | TID=1234 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 5 | 6 | "server" (6 Octets) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4 | 8 | "resource" (8 Octets) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | 1 | 0x5f | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S: ACK 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | 2 | 0 | 0 | TID=1234 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S: CON + S_OK (token=0x5f) "Hello World" 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | 0 | 1 | S_OK = 80 | TID=5068 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 11 | 1 | 0x5f | "Hello World" (11 Octets) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C: ACK 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | 2 | 0 | 0 | TID=5068 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I agree this should be clarified in the draft, and the draft should have more examples for deferred responses. Klaus From ngocthanhdinh@gmail.com Mon Nov 29 06:25:12 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C49443A6C0F for ; Mon, 29 Nov 2010 06:25:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=0.298, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nMeI4VeWM67R for ; Mon, 29 Nov 2010 06:25:05 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id BFDBB3A6BC1 for ; Mon, 29 Nov 2010 06:25:04 -0800 (PST) Received: by bwz12 with SMTP id 12so4421551bwz.31 for ; Mon, 29 Nov 2010 06:26:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=UCBSvWfdT7PKJgg8W4DUJZAOO4aCTGPIryvhNjFuTMQ=; b=lmk+PH0aupMi1BsEazDEjwiICDqNyYOC1XHrGSz0ejjFEPIPiofpqfnrqZ6VwXwQ7m Wb8QWOFy+bVXh9+Y6g3kTqlxESfl/n1VuR4+B9dWUpyJ3EiTYhsV5WSmeol0vwVtiQIq iPSnMH7C1p922iJtHptKZEZXIqf4bZ1F8bBLk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=KQtWBjzhVOUsMoCL39aW1XRGhHhBAAH/8u+WEYT7N/lO5BeLv6Oe9D43MlpDmo92t/ 1JZGlr4GAWj1FOC8V5CnALrBGTmnAlR4gtR7Li/vLA3yGnBPMaKFHDmgStdx19yQInrk L3HxMrr02Zv8hMTvmdnsiyJZFYrvkH/jNOMfY= MIME-Version: 1.0 Received: by 10.204.54.130 with SMTP id q2mr4992271bkg.183.1291040773433; Mon, 29 Nov 2010 06:26:13 -0800 (PST) Received: by 10.204.116.7 with HTTP; Mon, 29 Nov 2010 06:26:13 -0800 (PST) Date: Mon, 29 Nov 2010 23:26:13 +0900 Message-ID: From: Thanh Ngoc To: contiki-developers@lists.sourceforge.net, core@ietf.org Content-Type: multipart/alternative; boundary=001636c5a6eab0ea57049631dadc Subject: [core] contiki rest-server-example problem -- how to solve it? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2010 14:25:12 -0000 --001636c5a6eab0ea57049631dadc Content-Type: text/plain; charset=ISO-8859-1 Hello Every one, i run contiki-2.x/examples/rest-example in real nodes and follow some command in Readme.txt //------------------------------ To run REST server on real nodes under Linux -------------------------------------------- 1. Program the nodes with the rest-server-example > make TARGET=sky rest-server-example.upload 2. Disconnect the nodes and program one node with the RPL border router > (cd ../ipv6/rpl-border-router && make TARGET=sky border-router.upload) 3. Connect to the border router using tunslip6: > make connect-router 4. Reconnect the motes, reboot them and note their IP addresses. -->* i don't know where can see note IP? in border-router terminal or where? i do not see any thing when i press button reset on node.* //----------------------- *i run successfully step 1,2,3. but step 4, i do not know how to get the result? if you know , could you help me to explain more clearly about that?* and *when i run this example with COOJA, it run successful but when i use: >curl -H "User-Agent: curl" aaaa::0212:7402:0002:0202:8080/helloworld #get it told me : "couldn't connect to host" do you know how to correct it?* oh, i asked this question many times but no one help me. i saw contiki implement very well but the document is too short and not clear. so it is diificult to develop for new member. *i make a plan to make document for contiki to make it easier for understanding.* does it have anyone make with me? thank you very much. Ngoc Thanh --001636c5a6eab0ea57049631dadc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello Every one,

    i run contiki-2.x/examples/rest-example in real nod= es and follow some command in Readme.txt
    //-----------------------------= -
    To run REST server on real nodes under Linux
    ----------------------= ----------------------

    1. Program the nodes with the rest-server-example
    > make TARGET= =3Dsky rest-server-example.upload

    2. Disconnect the nodes and progra= m one node with the RPL border router
    > (cd ../ipv6/rpl-border-router= && make TARGET=3Dsky border-router.upload)

    3. Connect to the border router using tunslip6:
    > make connect-ro= uter

    4. Reconnect the motes, reboot them and note their IP addresses= .=A0 --> i don't know where can see note IP? in border-router ter= minal or where? i do not see any thing when i press button reset on node.
    //-----------------------
    i run successfully step 1,2,3. but step 4, = i do not know how to get the result? if you know , could you help me to exp= lain more clearly about that?

    and

    when i run this exa= mple with COOJA, it run successful but when i use:

    >curl -H "User-Agent: curl" aaaa::0212:7402:0002:0202:8080= /helloworld #get
    it told me : "couldn't connect to host"
    do you know how to correct it?

    oh, i asked this question= =A0 many times but no one help me.
    i saw contiki implement very well but the document is too short and not cle= ar.
    so it is diificult to develop for new member.
    i make a plan to= make document for contiki to make it easier for understanding.
    does it have anyone make with me?

    thank you very much.

    =A0Ngo= c Thanh
    --001636c5a6eab0ea57049631dadc-- From matthieu.vial@fr.non.schneider-electric.com Mon Nov 29 06:53:46 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0E363A6BD2; Mon, 29 Nov 2010 06:53:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.225 X-Spam-Level: X-Spam-Status: No, score=-3.225 tagged_above=-999 required=5 tests=[AWL=0.374, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lOv4tFEXHjoc; Mon, 29 Nov 2010 06:53:45 -0800 (PST) Received: from mailX03.eud.schneider-electric.com (mailx03.eud.schneider-electric.com [205.167.7.41]) by core3.amsl.com (Postfix) with ESMTP id 2ED633A6B94; Mon, 29 Nov 2010 06:53:45 -0800 (PST) Received: from ateui02.Schneider-Electric.com ([10.198.14.10]) by mailX03.eud.schneider-electric.com with ESMTP id 2010112915402365-112321 ; Mon, 29 Nov 2010 15:40:23 +0100 In-Reply-To: <55435af226a4a5495458aa0301560ae7@webmail.informatik.uni-bremen.de> To: Klaus Hartke MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 From: matthieu.vial@fr.non.schneider-electric.com Message-ID: Date: Mon, 29 Nov 2010 15:54:44 +0100 X-MIMETrack: Serialize by Router on ATEUI02.Schneider-Electric.com/T/SVR/Schneider at 29/11/2010 15:54:51, Serialize complete at 29/11/2010 15:54:51, Itemize by SMTP Server on AXEU3OUT.schneider-electric.com/X/SVR/SEIxtra at 29/11/2010 15:40:23, Serialize by Router on AXEU3OUT.schneider-electric.com/X/SVR/SEIxtra at 29/11/2010 15:40:25, Serialize complete at 29/11/2010 15:40:25 Content-Type: text/plain; charset="US-ASCII" Cc: core-bounces@ietf.org, core@ietf.org Subject: Re: [core] :Re: Draft needs Asynchronous transaction details X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2010 14:53:46 -0000 >> However you didn't answer the question what code should be returned, >> 100 or 202? > Neither 100 nor 202. Here's an example: >C: CON + GET coap://server/resource (token=0x5f) >S: ACK >S: CON + S_OK (token=0x5f) "Hello World" >C: ACK But is it allowed for an HTTP/CoAP proxy to translate the first ACK with code 0 into a 202 Accepted response? If the answer is yes then code 0 should appear in the translation table for CoAP-HTTP codes. Matthieu From rstruik.ext@gmail.com Mon Nov 29 08:48:51 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B89AF28C0E1 for ; Mon, 29 Nov 2010 08:48:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.649 X-Spam-Level: X-Spam-Status: No, score=-0.649 tagged_above=-999 required=5 tests=[AWL=1.950, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EpXT95BsC94M for ; Mon, 29 Nov 2010 08:48:50 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 3A9E53A6C1E for ; Mon, 29 Nov 2010 08:48:50 -0800 (PST) Received: by vws7 with SMTP id 7so1314278vws.31 for ; Mon, 29 Nov 2010 08:49:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=f1PRUhUzqCeFdyFLT2I4KUp9IrIqbiWAYzqYt3l6O0M=; b=eJNvvgnHM/J5g45ksJMKNl+qgdl8Z1JzscPe538bLZyjQkDE57wDHQmv+WV91STvgJ 8icr6IxPCkCw64uwpYHShvCbF/bQ0n/m2QbjSMFjB/jYTguTxzsdzy9bJeR4xH3Va4IR lKwJxTePU3My8RLvxRM9sNugaO/Adfq9JNmEY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=bwwpukiAPVhStiBermII5sFHgHdAXyw2f1P5HqhAWHhWl+KPbBX/r9FRFtGsmBDnkR gaY8ziI4pHUBriQ2wgkVY2yuRqwAWCnmGg0BrBqbQLdkdSDL4wuokPuDhNPLILwsrkiL y0b4XhHcy4urwT1vXoBUZgaaI1V63G/dXIK8M= Received: by 10.220.95.204 with SMTP id e12mr1640471vcn.146.1291049398622; Mon, 29 Nov 2010 08:49:58 -0800 (PST) Received: from [192.168.1.101] (CPE0013100e2c51-CM00186851d6f6.cpe.net.cable.rogers.com [99.232.69.160]) by mx.google.com with ESMTPS id l5sm687118vcr.38.2010.11.29.08.49.57 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 29 Nov 2010 08:49:57 -0800 (PST) Message-ID: <4CF3D9B0.7020703@gmail.com> Date: Mon, 29 Nov 2010 11:49:52 -0500 From: Rene Struik User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Carsten Bormann References: <057.cbcb8082fb49a1a254def976b454a663@tools.ietf.org> <066.34c8fead60f7ba790f916b74f04e04ab@tools.ietf.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: core WG Subject: [core] (RFC 4309 problematic) Re: coap #55 (new): AES-CCM vs. AES-CBC X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2010 16:48:51 -0000 Dear Carsten: RFC 4309 specifies how to use CCM mode of operation with IPSec. Some brief observations below. (These comments suggest that the use of the CCM mode, as specified with RFC 4309, is highly problematic, both from a security perspective, from per-packet data expansion perspective, with regard to offered security services, and as to imposed key management constraints.) 1) Data expansion. Total per-packet data expansion is at least 12 bytes: a) Data authentication. According to Section 2 of RFC 4309, only authentication tags that are a multiple of 4 bytes are allowed; moreover, authentication tags of length M=4 bytes are not allowed. Thus, per-packet data expansion due to authentication is minimally 8 bytes. b) Initialization vector. According to Section 3 of RFC 4309, the ESP payload includes a 8-byte IV. Thus, per-packet security admin overhead is minimally 8 bytes. 2) Nonce construction. a) Small nonce space. According to Section 2 of RFC 4309, the CCM mode uses L=4, thus reducing the nonce space to 11 octets only. As comparison, both IEEE 802.15.4, ISA SP100.11a, and, e.g., IETF RoLL rpl specification use a 13-octet nonce. b) Problematic support for group key scenarios. Nonce construction does not seem to easily cater to scenarios where one has a group key shared with more than two devices. With IEEE 802.15.4, ISA SP100.11a, and, e.g., IETF RoLL rpl, the nonce values generated by different originators of a packet do not clash by design. With RFC 4309, by constrast, it is not trivial to assure a partition of the nonce space according to the originator of a secured packet (from description in Section 4 of RFC 4309, this would somehow require inter-device coordination of the 8-byte IV value and avoidance of clashes between 3-byte Salt values [which, due to the birthday paradox is bound to happen with probability 50% for 2^{12} generated random 24-bit values]). 3) Key management. a) Salt value. According to Section 7.1 of RFC 4309, Salt values are generated as a by-product of the establishment of keying material. This begs the question as to how these Salt values are distributed in group key settings. Example (hup-and-spoke trust model): a security manager function may distribute keys to all other nodes in a network. If two of those nodes now wish to communicate to each other, the recipient requires access to the originator's salt value (which is not included in the communicated packet). b) Use of keying material. According to Section 9 of RFC 4309, the CCM mode should not be used with statically configured keys. While this is indeed advisable from a key lifecycle management perspective, this requirement for secure operation of the CCM mode itself is more relaxed: One should simply not invoke the mechanism with the same nonce value during the lifetime of the key (thus, re-emphasizing the need to assure this in group key settings, e.g., via partitioning of the nonce space according to device id). c) Different salt values for channel A-to-B and channel B-to-A. According to Section 9 of RFC 4309, one must use different Salt values when communicating from A to B than when traversing this communication channel the other way around (from B to A). This begs the question as to how this should be realized. 4) Security services offered. a) Replay protection not supported. RFC 4309 does not seem to support replay protection. With IEEE 802.15.4, ISA SP100.11a, and, e.g., IETF RoLL rpl, replay protection is provided via maintenance of some local state information on a recipient device (a counter value of the originator) and use of monotonically increasing counters with the nonce, so as to be able to detect duplicates. Best regards, Rene On 29/11/2010 4:37 AM, Carsten Bormann wrote: > On Nov 28, 2010, at 22:35, Eric Rescorla wrote: > >> I'm not sure that non-normative text really does the job here. If you're going to use >> CCM, you pretty much need automatic key management. Is that something you intend >> t require or not... > Interesting discussion. > > I view CoAP as a protocol standard, not a system standard. > (And, yes, I'm fully aware that the security of a single protocol often cannot be evaluated without speculating about the surrounding system -- this has long been one of the unresolved dilemmas in IETF standardization.) > > We are not defining new security mechanisms, we are pointing out ones that CoAP would work well with. > (Alexey's "must implement" discussion is relevant here, but somewhat orthogonal to my current point.) > To me, your comment reads a bit like "RFC 4309's security considerations are insufficient, so let's fix them in CoAP". > I'd rather reference them (possibly cite them, and maybe reinforce them where they are worded a bit too cautiously) as opposed to second-guess/"improve" them. > Getting normative about the system (as opposed to the protocol) should be avoided whenever possible. > > (But I don't have a strong opinion on the specific issue of ruling out static keys for AES-CCM, which appears to remain a valid restriction even while the system around the protocol changes.) > > Gruesse, Carsten > > PS.: Interestingly, RFC 4309 doesn't even spend a SHOULD: > > Therefore, AES CCM should not be used with statically configured > keys. > > I'd like to know the history on that one. > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core -- email: rstruik.ext@gmail.com Skype: rstruik cell: +1 (647) 867-5658 USA Google voice: +1 (415) 690-7363 From tianlinyi@huawei.com Mon Nov 29 09:01:14 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DD3828C159; Mon, 29 Nov 2010 09:01:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[AWL=-0.605, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rE1iCcgH7tgr; Mon, 29 Nov 2010 09:01:13 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 4AEE128C102; Mon, 29 Nov 2010 09:01:13 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LCN00IU7ONOO8@szxga05-in.huawei.com>; Tue, 30 Nov 2010 01:02:12 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LCN00G4XONNZP@szxga05-in.huawei.com>; Tue, 30 Nov 2010 01:02:12 +0800 (CST) Received: from [172.24.1.3] (Forwarded-For: [59.50.41.2]) by szxmc04-in.huawei.com (mshttpd); Tue, 30 Nov 2010 01:02:11 +0800 Date: Tue, 30 Nov 2010 01:02:11 +0800 From: tianlinyi 00175029 In-reply-to: To: matthieu.vial@fr.non.schneider-electric.com Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: multipart/mixed; boundary="Boundary_(ID_P0fh9mr+feSd+Rh0LpQ1gw)" Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal References: <55435af226a4a5495458aa0301560ae7@webmail.informatik.uni-bremen.de> Cc: core@ietf.org, core-bounces@ietf.org, Klaus Hartke Subject: Re: [core] :Re: Draft needs Asynchronous transaction details X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2010 17:01:14 -0000 This is a multi-part message in MIME format. --Boundary_(ID_P0fh9mr+feSd+Rh0LpQ1gw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline Hi, Klaus Then what is 100? Is it same with HTTP 100? Why not use well understood code 202 instead of 0? What is the benefit to do so? Cheers, Linyi > >> However you didn't answer the question what code should be > returned,>> 100 or 202? > > > Neither 100 nor 202. Here's an example: > >C: CON + GET coap://server/resource (token=0x5f) > >S: ACK > >S: CON + S_OK (token=0x5f) "Hello World" > >C: ACK > > But is it allowed for an HTTP/CoAP proxy to translate the first > ACK with > code 0 into a 202 Accepted response? > If the answer is yes then code 0 should appear in the translation > table > for CoAP-HTTP codes. > > Matthieu > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --Boundary_(ID_P0fh9mr+feSd+Rh0LpQ1gw) Content-type: text/x-vcard; name=t00175029.vcf; charset=gb2312 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=t00175029.vcf Content-description: Card for tianlinyi 00175029 begin:vcard n:34932;tianlinyi fn:tianlinyi 34932 version:2.1 email;internet:tianlinyi@huawei.com end:vcard --Boundary_(ID_P0fh9mr+feSd+Rh0LpQ1gw)-- From fluffy@cisco.com Mon Nov 29 09:33:15 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15F9928C192 for ; Mon, 29 Nov 2010 09:33:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.568 X-Spam-Level: X-Spam-Status: No, score=-110.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uVrVnhIKPqa6 for ; Mon, 29 Nov 2010 09:33:14 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id F06F028C18B for ; Mon, 29 Nov 2010 09:33:13 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANpy80yrR7H+/2dsb2JhbACjBnGoApsahUcEhFyGBYMP X-IronPort-AV: E=Sophos;i="4.59,276,1288569600"; d="scan'208";a="627684877" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 29 Nov 2010 17:34:02 +0000 Received: from [192.168.4.2] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id oATHY1WX012465; Mon, 29 Nov 2010 17:34:02 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=windows-1252 From: Cullen Jennings In-Reply-To: <062.e005eebef68d9cfe38103602bef0a764@tools.ietf.org> Date: Mon, 29 Nov 2010 10:34:47 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <850DFBCD-5DF3-4D57-B34E-60C820024A8B@cisco.com> References: <053.48772f16e4210556e31256ce985ef8fc@tools.ietf.org> <062.e005eebef68d9cfe38103602bef0a764@tools.ietf.org> To: core issue tracker X-Mailer: Apple Mail (2.1082) Cc: core@ietf.org Subject: Re: [core] coap #76 (new): Media types X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2010 17:33:15 -0000 (in my individual contributor role ) I 90% agree with your suggestion - sounds like a reasonable path - few = comments inline... On Nov 23, 2010, at 1:39 AM, core issue tracker wrote: > #76: Media types >=20 > Changes (by zach@=85): >=20 > * priority: major =3D> minor > * type: defect =3D> enhancement >=20 >=20 > Comment: >=20 > Let's be very specific about what changes are suggested by this ticket = to > Section 11.2. The mail from Cullen below suggests making changes to = how > MIME types are used that is way beyond our scope. No- I am suggesting using them exactly as they were meant to be used. I = am just suggesting not registering the ones that have turned out not to = be usable.=20 > I think that is > something that needs to be fixed in the App area, and not in this = working > group. Although I see where Cullen is coming from, some basic MIME = types > are very useful when an application specific MIME type is not = available, > especially when getting started with a new application. For example > application/xml, text/plain, application/exi, application/json all = tell > you what kind of parser needs to be used on the payload, Really ? I doubt it. Let's say you know it is json and you want to parse = it. All the reason I can imagine for parsing it, other than checking = validity which no one does, require you to know far more than just it is = JSON to be able to parse it.=20 > or how the data > could be displayed to a human. Yes, but this protocol is not really for raw display to humans.=20 >=20 > That said, I do think we can do some of the things suggested by = Cullen: >=20 > 1. Add a column to the table pointing to a document describing what = the > payload means semantically. >=20 > 2. Remove some types from the table not really needed. Do we really = need > the image and video ones for example? application/x-bxml also is not a > standard nor widely deployed. I would argue that we need to keep (at = least > some of) the basic text and application types. Why keep text/plain? All this does is cause people not to register the = actually useful code point. I'm fine with having a code point that is = "unknown" or allowing the header to be missing. I just rather have the = mime type specify something that was a type with semantic meaning and = not be just a pointer to language the type was encoded with. Knowing if = the data is ASCII or EBCDIC is really of no use. I want something = useful.=20 BTW - I am fine with things that are not widely used being registered - = the code points here are very cheap.=20 >=20 > 3. We add a paragraph explaining how MIME types should be designed and > used for real applications as per Cullen's mail. For example something > like application/sep20+xml in the case of ZigBee smart energy. Or the > proposed application/dali, application/bacnet etc. from = draft-vanderstok- > core-bc. Sound good=20 >=20 > --=20 > = ----------------------------+---------------------------------------------= -- > Reporter: hartke@=85 | Owner: zach@=85 =20 > Type: enhancement | Status: new =20 > Priority: minor | Milestone: =20 > Component: coap | Version: =20 > Severity: - | Keywords: =20 > = ----------------------------+---------------------------------------------= -- >=20 > Ticket URL: = > core >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From fluffy@cisco.com Mon Nov 29 09:43:04 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0E9228C159 for ; Mon, 29 Nov 2010 09:43:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.569 X-Spam-Level: X-Spam-Status: No, score=-110.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jvw1bTPy5j5F for ; Mon, 29 Nov 2010 09:43:03 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id A790D28C155 for ; Mon, 29 Nov 2010 09:43:03 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADl180yrR7Hu/2dsb2JhbACjBnGoEZschUcEhFyGBYMP X-IronPort-AV: E=Sophos;i="4.59,276,1288569600"; d="scan'208";a="294331709" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 29 Nov 2010 17:44:13 +0000 Received: from [192.168.4.2] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id oATHiBcx028374; Mon, 29 Nov 2010 17:44:11 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Mon, 29 Nov 2010 10:44:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4FA83475-4D03-428E-8B12-C028BC614CEA@cisco.com> References: <057.cbcb8082fb49a1a254def976b454a663@tools.ietf.org> <066.34c8fead60f7ba790f916b74f04e04ab@tools.ietf.org> To: Carsten Bormann X-Mailer: Apple Mail (2.1082) Cc: core WG Subject: Re: [core] coap #55 (new): AES-CCM vs. AES-CBC X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2010 17:43:04 -0000 This all gets into a complicated area of how to split up protocols and = system but generally the protocol needs to provide security (obviously = security is also a system property but my point is it also often a = protocol property).=20 I would be very surprised to see the IESG approve CORE without = specifying at least one MTI keying scheme. Cullen On Nov 29, 2010, at 2:37 AM, Carsten Bormann wrote: > On Nov 28, 2010, at 22:35, Eric Rescorla wrote: >=20 >> I'm not sure that non-normative text really does the job here. If = you're going to use >> CCM, you pretty much need automatic key management. Is that something = you intend >> t require or not... >=20 > Interesting discussion. >=20 > I view CoAP as a protocol standard, not a system standard. > (And, yes, I'm fully aware that the security of a single protocol = often cannot be evaluated without speculating about the surrounding = system -- this has long been one of the unresolved dilemmas in IETF = standardization.) >=20 > We are not defining new security mechanisms, we are pointing out ones = that CoAP would work well with. > (Alexey's "must implement" discussion is relevant here, but somewhat = orthogonal to my current point.) > To me, your comment reads a bit like "RFC 4309's security = considerations are insufficient, so let's fix them in CoAP". > I'd rather reference them (possibly cite them, and maybe reinforce = them where they are worded a bit too cautiously) as opposed to = second-guess/"improve" them. > Getting normative about the system (as opposed to the protocol) should = be avoided whenever possible. >=20 > (But I don't have a strong opinion on the specific issue of ruling out = static keys for AES-CCM, which appears to remain a valid restriction = even while the system around the protocol changes.) >=20 > Gruesse, Carsten >=20 > PS.: Interestingly, RFC 4309 doesn't even spend a SHOULD: >=20 > Therefore, AES CCM should not be used with statically configured > keys. >=20 > I'd like to know the history on that one. >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From fluffy@cisco.com Mon Nov 29 09:49:18 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B269228C155 for ; Mon, 29 Nov 2010 09:49:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.269 X-Spam-Level: X-Spam-Status: No, score=-110.269 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wzmzRDhAVydN for ; Mon, 29 Nov 2010 09:49:18 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 00E0D28C0E1 for ; Mon, 29 Nov 2010 09:49:17 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFp280yrR7Ht/2dsb2JhbACjBnGoFZschUcEhFyGBYMP X-IronPort-AV: E=Sophos;i="4.59,276,1288569600"; d="scan'208";a="627696399" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 29 Nov 2010 17:50:28 +0000 Received: from [192.168.4.2] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oATHoRmq013791; Mon, 29 Nov 2010 17:50:27 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=windows-1252 From: Cullen Jennings In-Reply-To: <066.6f4fbea26c0f0b2beb3be88808ad2f58@tools.ietf.org> Date: Mon, 29 Nov 2010 10:51:13 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6365006A-6AF4-4A5A-8158-1FDC16354F31@cisco.com> References: <057.3c2c33e201209462cb9746082696f761@tools.ietf.org> <066.6f4fbea26c0f0b2beb3be88808ad2f58@tools.ietf.org> To: core issue tracker X-Mailer: Apple Mail (2.1082) Cc: core@ietf.org, hartke@tzi.org Subject: Re: [core] coap #53 (new): Token length X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2010 17:49:18 -0000 I was just sort of wondering about the 6 bytes should be enough = protection. It seems to me that 80 bits is a more typically used number. = The 2 byte index makes sense but seems like we might need a pointer to = how we choose rest. I also wonder if a 2 byte index is going to make = replay attacks too easy.=20 On Nov 25, 2010, at 10:13 AM, core issue tracker wrote: > #53: Token length >=20 >=20 > Comment(by hartke@=85): >=20 > Since the value of the Token Option is an opaque byte sequence, no one = can > be stopped from putting state into it. >=20 > Assuming 2 bytes of sequence numbering, 6 bytes of protection should = be > enough. Given that 18 bytes are needed for the transport address (IP > address/port), 8 bytes also are not out of line. >=20 > There is agreement that 0 to 8 bytes is the right size. >=20 > --=20 > = --------------------------------+-----------------------------------------= -- > Reporter: zach@=85 | Owner: =20 > Type: enhancement | Status: new > Priority: minor | Milestone: =20 > Component: coap | Version: =20 > Severity: - | Keywords: =20 > = --------------------------------+-----------------------------------------= -- >=20 > Ticket URL: = > core >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core