From trac+core@trac.tools.ietf.org Mon May 2 05:21:42 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ADB5E07ED for ; Mon, 2 May 2011 05:21:42 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DYXj8q73srAO for ; Mon, 2 May 2011 05:21:41 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id ED876E07EB for ; Mon, 2 May 2011 05:21:41 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QGs8C-0008F0-6W; Mon, 02 May 2011 05:21:40 -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: Mon, 02 May 2011 12:21:40 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/146 Message-ID: <057.5c77f580cde6ec344601d48b9b7ca866@trac.tools.ietf.org> X-Trac-Ticket-ID: 146 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] #146: Editorial & reference improvements X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2011 12:21:42 -0000 #146: Editorial & reference improvements Fix the editorial and reference issue from Alexey's April 13th review. -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: editorial | Status: new Priority: trivial | Milestone: Component: link-format | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From m.pouillot@watteco.com Mon May 2 07:55:31 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56986E073A for ; Mon, 2 May 2011 07:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.595 X-Spam-Level: X-Spam-Status: No, score=-2.595 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8b+5wzeEHC4n for ; Mon, 2 May 2011 07:55:30 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1outboundpool.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id 99661E072F for ; Mon, 2 May 2011 07:55:29 -0700 (PDT) Received: from mail86-ch1-R.bigfish.com (216.32.181.170) by CH1EHSOBE016.bigfish.com (10.43.70.66) with Microsoft SMTP Server id 14.1.225.8; Mon, 2 May 2011 14:55:29 +0000 Received: from mail86-ch1 (localhost.localdomain [127.0.0.1]) by mail86-ch1-R.bigfish.com (Postfix) with ESMTP id 31312EC845B for ; Mon, 2 May 2011 14:55:29 +0000 (UTC) X-SpamScore: -7 X-BigFish: VPS-7(zz14ffOzz1202hzz8275bh8275dhz2dh2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:IE2RD2HUB014.red002.local; RD:none; EFVD:NLI Received: from mail86-ch1 (localhost.localdomain [127.0.0.1]) by mail86-ch1 (MessageSwitch) id 1304348127929333_24033; Mon, 2 May 2011 14:55:27 +0000 (UTC) Received: from CH1EHSMHS035.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.242]) by mail86-ch1.bigfish.com (Postfix) with ESMTP id D692D88004C for ; Mon, 2 May 2011 14:55:27 +0000 (UTC) Received: from IE2RD2HUB014.red002.local (213.199.187.153) by CH1EHSMHS035.bigfish.com (10.43.70.35) with Microsoft SMTP Server (TLS) id 14.1.225.8; Mon, 2 May 2011 14:55:26 +0000 Received: from IE2RD2XVS151.red002.local ([10.43.202.15]) by IE2RD2HUB014.red002.local ([10.43.198.12]) with mapi; Mon, 2 May 2011 07:55:03 -0700 From: M Pouillot To: "core@ietf.org" Date: Mon, 2 May 2011 07:55:50 -0700 Thread-Topic: Coap - ask a non piggy-backed response Thread-Index: AcwIxGCRytIEB9IQQWqZa632qmzxcQAFJtPA Message-ID: <555DED900DD42348B2995D1005EF1662026011E080@IE2RD2XVS151.red002.local> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: multipart/alternative; boundary="_000_555DED900DD42348B2995D1005EF1662026011E080IE2RD2XVS151r_" MIME-Version: 1.0 X-OriginatorOrg: watteco.com Subject: [core] Coap - ask a non piggy-backed response X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 02 May 2011 14:55:31 -0000 --_000_555DED900DD42348B2995D1005EF1662026011E080IE2RD2XVS151r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: base64 SGVsbG8gYWxsLA0KDQpJcyB0aGVyZSBhIHBvc3NpYmlsaXR5IHRvIGFzayAgYSBzZXJ2ZXIgdG8g YW5zd2VyIHdpdGggYSBDT04gbm9uIHBpZ2d5LWJhY2tlZCBtZXNzYWdlPw0KRm9yIGV4YW1wbGUs IGl0IGNvdWxkIGJlIGludGVyZXN0aW5nIHRvIGhhdmUgdGhpcyBraW5kIG9mIGZlYXR1cmUgZm9y ICBhICBtdWx0aWNhc3QgbWVzc2FnZTogY2xpZW50IHNlbmRzIHRvIGZmMDI6OjEgYSBOT04gR0VU IG1lc3NhZ2UsIGFuZCBpbiByZXNwb25zZSBhbGwgdGhlIHNlcnZlciBhbnN3ZXIgd2l0aCBhIENP TiBtZXNzYWdlLi4uDQoNCk1hdGhpZXUNCg== --_000_555DED900DD42348B2995D1005EF1662026011E080IE2RD2XVS151r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXMtYXNjaWkiPjxtZXRhIG5hbWU9R2VuZXJhdG9yIGNv bnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj48c3R5bGU+PCEtLQ0K LyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxl IERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFs DQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4w cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1z b0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiVGV4dGUgZGUgYnVsbGVzIENhciI7DQoJbWFyZ2lu OjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V Uzt9DQpzcGFuLlRleHRlZGVidWxsZXNDYXINCgl7bXNvLXN0eWxlLW5hbWU6IlRleHRlIGRlIGJ1 bGxlcyBDYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiVGV4 dGUgZGUgYnVsbGVzIjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bh bi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxT dHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3 MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1GUiBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxk aXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29s b3I6IzFGNDk3RCc+SDwvc3Bhbj5lbGxvIGFsbCw8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPklzIHRoZXJlIGEg cG9zc2liaWxpdHkgdG8gYXNrICZuYnNwO2Egc2VydmVyIHRvIGFuc3dlciB3aXRoIGEgQ09OIG5v biBwaWdneS1iYWNrZWQgbWVzc2FnZT8gPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PkZvciBleGFtcGxlLCBpdCBjb3VsZCBiZSBpbnRlcmVzdGluZyB0byBoYXZlIHRoaXMga2luZCBv ZiBmZWF0dXJlIGZvciAmbmJzcDthICZuYnNwO211bHRpY2FzdCBtZXNzYWdlOiBjbGllbnQgc2Vu ZHMgdG8gZmYwMjo6MSBhIE5PTiBHRVQgbWVzc2FnZSwgYW5kIGluIHJlc3BvbnNlIGFsbCB0aGUg c2VydmVyIGFuc3dlciB3aXRoIGEgQ09OIG1lc3NhZ2UmIzgyMzA7PG86cD48L286cD48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5N YXRoaWV1PG86cD48L286cD48L3A+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_555DED900DD42348B2995D1005EF1662026011E080IE2RD2XVS151r_-- From zach@sensinode.com Tue May 3 01:32:33 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC423E06F9 for ; Tue, 3 May 2011 01:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVxLw-QPF0QF for ; Tue, 3 May 2011 01:32:33 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id CF95AE06E1 for ; Tue, 3 May 2011 01:32:30 -0700 (PDT) Received: from [213.145.205.245] ([213.145.205.245]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id p438WPw5022723 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 3 May 2011 11:32:26 +0300 From: Zach Shelby Content-Type: multipart/signed; boundary=Apple-Mail-164--313166838; protocol="application/pkcs7-signature"; micalg=sha1 Date: Tue, 3 May 2011 11:32:27 +0300 Message-Id: <8B55B68A-3EA2-45F6-8624-6617333C656D@sensinode.com> To: core WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [core] ABNF help X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 03 May 2011 08:32:34 -0000 --Apple-Mail-164--313166838 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I am trying to add decimal range limitations to the core-link-format ct=3D= and sz=3D attributes. If anyone knows the best way to do that in ABNF I = would appreciate some help. Current ABNF: link-extension =3D ( "rt" "=3D" quoted-string ) link-extension =3D ( "if" "=3D" quoted-string ) link-extension =3D ( "ct" "=3D" integer ) link-extension =3D ( "sz" "=3D" integer ) integer =3D 1*DIGIT Needs to be updated so that ct has a digit range of 0-65535 and sz has a = digit range of 0-4294967295.=20 Thanks, 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-164--313166838 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 ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDUwMzA4MzIy N1owIwYJKoZIhvcNAQkEMRYEFMubl6LhuiZsDopb90VNEo19NxDUMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAKcTtRuMlsaV2fthNoz4WmYeJh9+YGLyHE/ZSKlnetQrTvR1fcl9ekMc jz5G8KCQo4Zv5D+zTcIqfjWjOmSX/TnDVxDmspxlclptuhYfvNgtNkllq/vkkIyG6xYXYdVSYlAd yfTksjDjQ8wTC/d4gqN+vwL2g5LQ+3GjtsQ/l/oy746VnSQJvgMwuiOUjomh8z3h3mDLb/6BSgQ1 MNPqD886TpR50dcCbHvyMjrQJevedzVyLvcPofLKauGOOkiSUiLqGpTtIGSxoQG+I9Q6Gbvb3VUT 3GD1ZqfQrrQrtrk8dz7IOz2Pu7YGzw2Bb73Xe9hMq2TlBMLmUTRICjjaQX4AAAAAAAA= --Apple-Mail-164--313166838-- From cabo@tzi.org Tue May 3 01:53:01 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E23C9E070C for ; Tue, 3 May 2011 01:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.649 X-Spam-Level: X-Spam-Status: No, score=-105.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZvUgmmBHyUZo for ; Tue, 3 May 2011 01:53:01 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id EEBEDE073C for ; Tue, 3 May 2011 01:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id p438qqKk022149; Tue, 3 May 2011 10:52:52 +0200 (CEST) Received: from [192.168.217.101] (p5B3E613E.dip.t-dialin.net [91.62.97.62]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 348AE6BE; Tue, 3 May 2011 10:52:52 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <8B55B68A-3EA2-45F6-8624-6617333C656D@sensinode.com> Date: Tue, 3 May 2011 10:52:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6F58467D-2355-45FA-A32A-880302EEF22C@tzi.org> References: <8B55B68A-3EA2-45F6-8624-6617333C656D@sensinode.com> To: Zach Shelby X-Mailer: Apple Mail (2.1084) Cc: core WG Subject: Re: [core] ABNF help X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 03 May 2011 08:53:02 -0000 On May 3, 2011, at 10:32, Zach Shelby wrote: > I am trying to add decimal range limitations to the core-link-format = ct=3D and sz=3D attributes. If anyone knows the best way to do that in = ABNF I would appreciate some help. Current ABNF: >=20 > link-extension =3D ( "rt" "=3D" quoted-string ) > link-extension =3D ( "if" "=3D" quoted-string ) > link-extension =3D ( "ct" "=3D" integer ) > link-extension =3D ( "sz" "=3D" integer ) > integer =3D 1*DIGIT >=20 > Needs to be updated so that ct has a digit range of 0-65535 One way to do this is shown in a number of RFC including RFC 3986: IPv4address =3D dec-octet "." dec-octet "." dec-octet "." = dec-octet dec-octet =3D DIGIT ; 0-9 / %x31-39 DIGIT ; 10-99 / "1" 2DIGIT ; 100-199 / "2" %x30-34 DIGIT ; 200-249 / "25" %x30-35 ; 250-255 This extends in a straightforward way to any range of numbers. (Note that the technique used also nicely takes care of disallowing = leading zeros.) Is it reasonable to go to the trouble to encode this range limit in the = ABNF? (Doesn't make a difference to a small implementation, which will = probably do the range check in a different way.) > and sz has a digit range of 0-4294967295.=20 It is not even clear to me that we have a natural limit of < 4 GiB. Why not leave that open? If a node has an mp4 of the royal wedding, it = might not fit anyway :-) In summary, I certainly would not bother to make this change for sz, and = I probably wouldn't for ct. Gruesse, Carsten From alexey.melnikov@isode.com Tue May 3 01:59:06 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41103E0752 for ; Tue, 3 May 2011 01:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_37=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7DK8CC56Ik0 for ; Tue, 3 May 2011 01:59:01 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id CC7E9E073C for ; Tue, 3 May 2011 01:59:00 -0700 (PDT) Received: from [188.28.73.38] (188.28.73.38.threembb.co.uk [188.28.73.38]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 3 May 2011 09:58:59 +0100 Message-ID: <4DBFC3CA.5040505@isode.com> Date: Tue, 03 May 2011 09:58:50 +0100 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: <8B55B68A-3EA2-45F6-8624-6617333C656D@sensinode.com> <6F58467D-2355-45FA-A32A-880302EEF22C@tzi.org> In-Reply-To: <6F58467D-2355-45FA-A32A-880302EEF22C@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] ABNF help X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 03 May 2011 08:59:06 -0000 Hi Carsten, Carsten Bormann wrote: >On May 3, 2011, at 10:32, Zach Shelby wrote: > > >>I am trying to add decimal range limitations to the core-link-format ct= and sz= attributes. If anyone knows the best way to do that in ABNF I would appreciate some help. Current ABNF: >> >> link-extension = ( "rt" "=" quoted-string ) >> link-extension = ( "if" "=" quoted-string ) >> link-extension = ( "ct" "=" integer ) >> link-extension = ( "sz" "=" integer ) >> integer = 1*DIGIT >> >>Needs to be updated so that ct has a digit range of 0-65535 >> >> > >One way to do this is shown in a number of RFC including RFC 3986: > > IPv4address = dec-octet "." dec-octet "." dec-octet "." dec-octet > > dec-octet = DIGIT ; 0-9 > / %x31-39 DIGIT ; 10-99 > / "1" 2DIGIT ; 100-199 > / "2" %x30-34 DIGIT ; 200-249 > / "25" %x30-35 ; 250-255 > >This extends in a straightforward way to any range of numbers. >(Note that the technique used also nicely takes care of disallowing leading zeros.) > > Right. Stating restrictions in an ABNF comment is also acceptable, IMHO. >Is it reasonable to go to the trouble to encode this range limit in the ABNF? >(Doesn't make a difference to a small implementation, which will probably do the range check in a different way.) > > >>and sz has a digit range of 0-4294967295. >> >> >It is not even clear to me that we have a natural limit of < 4 GiB. >Why not leave that open? If a node has an mp4 of the royal wedding, it might not fit anyway :-) > >In summary, I certainly would not bother to make this change for sz, and I probably wouldn't for ct. > > If I were to implement this and I were to store these values as integers (as opposed to strings), I would need to know the possible upper limit. From zach@sensinode.com Tue May 3 02:01:17 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1639CE067A for ; Tue, 3 May 2011 02:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LGhRtQD6cEPp for ; Tue, 3 May 2011 02:01:15 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 2A01AE0708 for ; Tue, 3 May 2011 02:01:14 -0700 (PDT) Received: from [213.145.205.245] ([213.145.205.245]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id p4391BiT003987 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 May 2011 12:01:12 +0300 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-166--311440602; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: <6F58467D-2355-45FA-A32A-880302EEF22C@tzi.org> Date: Tue, 3 May 2011 12:01:13 +0300 Message-Id: References: <8B55B68A-3EA2-45F6-8624-6617333C656D@sensinode.com> <6F58467D-2355-45FA-A32A-880302EEF22C@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.1084) Cc: core WG Subject: Re: [core] ABNF help X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 03 May 2011 09:01:17 -0000 --Apple-Mail-166--311440602 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 3, 2011, at 11:52 AM, Carsten Bormann wrote: > Is it reasonable to go to the trouble to encode this range limit in = the ABNF? > (Doesn't make a difference to a small implementation, which will = probably do the range check in a different way.) Probably true. I was just working on Alexey's link-format review = comments and this was one of them. I can just include the range in the = text description of course. >> and sz has a digit range of 0-4294967295.=20 >=20 > It is not even clear to me that we have a natural limit of < 4 GiB. > Why not leave that open? If a node has an mp4 of the royal wedding, = it might not fit anyway :-) So you are a royalist? :-) You are probably right, we can just leave the = range for sz open. > In summary, I certainly would not bother to make this change for sz, = and I probably wouldn't for ct. Regarding ct I would prefer to keep the 0-65535 range in the text as = this is the valid range for the CoAP media type code.=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-166--311440602 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 ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDUwMzA5MDEx NFowIwYJKoZIhvcNAQkEMRYEFDkdCplTA1rTNStKrDB7QvlXQ+u/MIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAEbRzXR3S2UjuqQKcXNMh3Kz0n6WbxhpDeFr4B5M3LpNO1asBAKT5P1W 9H33dexdo7TCEdHmkPh8FMFIrOSs8vi8ivzSryBJeBBswE6ueap80NsN/bclzqBG0tYheVAcjRRL FO35AhtLLzgil6LYICuh8wZRdrx4W6jV3S2VoxVzfnyUj550pDWHnS1lLZ1IyjdPcrzY6rhONpYR LiDN+V2alGOlnXn1F5iYziofOe4nsgpmSp69UYRh9ml7SMvejpfDZVIUv7gSCC9PpCN3Wy6/Cv7x 6EEOwCyxMaBMLYdtu0t3rINHJtIABb68lNShUN1QKwRpRtZZCd/F9X2ZY10AAAAAAAA= --Apple-Mail-166--311440602-- From trac+core@trac.tools.ietf.org Tue May 3 02:16:38 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1268EE0735 for ; Tue, 3 May 2011 02:16:38 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yqvqjMNrj726 for ; Tue, 3 May 2011 02:16:37 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id A923EE0708 for ; Tue, 3 May 2011 02:16:37 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QHBie-0004nT-QB; Tue, 03 May 2011 02:16:36 -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: Tue, 03 May 2011 09:16:36 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/145#comment:1 Message-ID: <066.d59d85078fc8d0939af13d3d96dc16c5@trac.tools.ietf.org> References: <057.7012fc818d4796dca51ab6945aa77ea9@trac.tools.ietf.org> X-Trac-Ticket-ID: 145 In-Reply-To: <057.7012fc818d4796dca51ab6945aa77ea9@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #145: Remove attribute registry X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 09:16:38 -0000 #145: Remove attribute registry Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: Done in link-format-04. -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: task | Status: closed Priority: minor | Milestone: Component: link-format | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Tue May 3 02:17:04 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2A88E06AA for ; Tue, 3 May 2011 02:17: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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mBtdBhM0268C for ; Tue, 3 May 2011 02:17:04 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 69445E067A for ; Tue, 3 May 2011 02:17:04 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QHBj6-0004pO-Ae; Tue, 03 May 2011 02:17: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: zach@sensinode.com X-Trac-Project: core Date: Tue, 03 May 2011 09:17:04 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/144#comment:1 Message-ID: <066.23814dd8349fff690d9d51589dbab3bf@trac.tools.ietf.org> References: <057.47982ae8991872cb7dbe8b4078a3cfa7@trac.tools.ietf.org> X-Trac-Ticket-ID: 144 In-Reply-To: <057.47982ae8991872cb7dbe8b4078a3cfa7@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #144: Request CoAP Media Type ID for application/link-format X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 09:17:04 -0000 #144: Request CoAP Media Type ID for application/link-format Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: New section added in link-format-04. -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: task | Status: closed Priority: trivial | Milestone: Component: link-format | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Tue May 3 02:17:58 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CEFDE0770 for ; Tue, 3 May 2011 02:17: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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8urPAAFsxRkD for ; Tue, 3 May 2011 02:17:57 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id E5FE3E06AA for ; Tue, 3 May 2011 02:17:57 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QHBjx-0005s8-SO; Tue, 03 May 2011 02:17: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: Tue, 03 May 2011 09:17:57 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/146#comment:1 Message-ID: <066.c20db38c1decbba9f13ab5cf2a00d734@trac.tools.ietf.org> References: <057.5c77f580cde6ec344601d48b9b7ca866@trac.tools.ietf.org> X-Trac-Ticket-ID: 146 In-Reply-To: <057.5c77f580cde6ec344601d48b9b7ca866@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #146: Editorial & reference improvements X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 09:17:58 -0000 #146: Editorial & reference improvements Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: Done. -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: editorial | Status: closed Priority: trivial | Milestone: Component: link-format | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Ticket URL: core From zach@sensinode.com Tue May 3 02:28:31 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62BA6E06E1 for ; Tue, 3 May 2011 02:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WPTVRQgcLqXY for ; Tue, 3 May 2011 02:28:30 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 137F9E06AA for ; Tue, 3 May 2011 02:28:29 -0700 (PDT) Received: from [213.145.205.245] ([213.145.205.245]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id p439SPaB017404 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 May 2011 12:28:25 +0300 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-169--309806697; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: <4DA562B6.8000508@isode.com> Date: Tue, 3 May 2011 12:28:27 +0300 Message-Id: References: <4DA562B6.8000508@isode.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.1084) Cc: core@ietf.org Subject: Re: [core] Review of draft-ietf-core-link-format-03.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 09:28:31 -0000 --Apple-Mail-169--309806697 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks for your review Alexey. I have made these changes, a few answers = to your questions below as well. On Apr 13, 2011, at 11:45 AM, Alexey Melnikov wrote: >=20 > In Section 2: >=20 > The CoRE link format uses the ABNF description and associated rules > in Section 5 of [RFC5988]. In addition, the pchar rule is taken from > [RFC3986]. The "Link:" text is omitted as that is part of the HTTP > Link Header. As in [RFC5988], multiple link descriptions are > separated by commas. Note that commas can also occur in quoted > strings and URIs but do not end a description. >=20 > Does this mean that some comma escaping mechanism is needed? Not as far as I know, at least RFC5988 doesn't use comma escaping and we = haven't changed the format. > 3. CoRE link extensions >=20 > The following CoRE specific target attributes are defined. These > attributes describe information useful in accessing the target link > of the relation, and in some cases may be URIs. These URIs MUST be > treated as indicators, and are not meant to be actually retrieved > like a URL. >=20 > Are you trying to say that they are not resolvable? Right, I updated the language. >=20 > link-extension =3D ( "ct" "=3D" integer ) > link-extension =3D ( "sz" "=3D" integer ) > integer =3D 1*DIGIT >=20 > Are there any limits on allowed values? I generally think there should = be one. I added a range limit for ct as an ABNF comment and in the text. Let's = see what text we can agree on for sz.=20 >=20 > 3.1. Resource type 'rt' attribute >=20 > The resource type "rt" attribute is used to assign a semantically > important type to a resource. One can think of this as a noun > describing the resource. In the case of a temperature resource this > could be an application-specific semantic type like > "OutdoorTemperature", a Universal Resource Name (URN) like > "urn:temperature:outdoor" or a URI referencing a specific concept in > an ontology like > "http://sweet.jpl.nasa.gov/2.0/phys.owl#Temperature". >=20 > Is specific syntax important here, or are these values opaque? Opaque, I added text to make that clearer. >=20 > The interface description could be for example the URI of a Web > Application Description Language (WADL) definition of the target >=20 > I think an Informative reference is needed here. Done. > In Section 4.1: >=20 > If the decoded query-pattern does not end with "*", a link value > matches the query only if the value of the attribute or URI-reference > denoted by the resource-param is bytewise identical to the query- > pattern. If the decoded query-pattern ends with "*", it is > sufficient that the remainder of the query-pattern be a prefix of the > value denoted by the resource-param. >=20 > Does * match an empty string? Yes, I would assume so if that attribute present with an empty string.=20= > 6. Security Considerations >=20 > Multicast requests using CoAP for the well-known link-format > resources could be used to perform denial of service on a constrained > network. A multicast request SHOULD only be accepted if the request > is sufficiently authenticated and secured. >=20 > Is there a mechanism to satisfy the SHOULD? I added a mention of IPsec and object security, which would be the only = options.=20 > 7.1. Attribute Registry >=20 > This document defines a registry for the link extension attributes > defined for use with the CoRE Link Format. The name of the registry > is "CoRE Link Format Attributes". >=20 > Is it wise to limit this registry to CORE only? For example, if = another application using link relations is extended, how can conflicts = with this registry be avoided? We already had a ticket to remove this registry as Mark will work on a = general one, so agreed and done.=20 >=20 > 7.4. New link-format Internet media type >=20 > This memo registers the a new Internet media type for the CoRE link > format, application/link-format. >=20 > Type name: application >=20 > Subtype name: link-format >=20 > Required parameters: None >=20 > Optional parameters: The query string may contain uri=3D to match the > URI, or any other attribute defined for the link format to match that > attribute as defined in this document. >=20 > This is a wrong type of information here, as this is not talking about = MIME type parameters. So I think None should be specified in this field Fixed. >=20 > Encoding considerations: UTF-8 (NFC) >=20 > According to MIME type registration template this field should have = the value "8bit". The rest can be a comment in (). Fixed. >=20 > Security considerations: None >=20 > Are you sure :-). See RFC 4288. Oops, I added the same security considerations as in the security = section here as well, as they are valid.=20 >=20 > File extension(s): >=20 > Any reason not to define an extension here? I propose adding the extension *.clf (Core Link Format). An alternative = would be *.wlk (Web LinKing). Both seem to be free. 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-169--309806697 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 ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDUwMzA5Mjgy OFowIwYJKoZIhvcNAQkEMRYEFOJR6GHRKtcaqCkh70Zv87miNg+pMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAB56d11p7lxvrj3t1RmIevYkmqk0A5E12sboSJ6e6GRBZOmX9SpaFwll WOIwkrKj4xWC2zhfGfCwbWT+gZP4gIk+AdBOXp/H1XOgPlQqultwglwVVdAGUf9hEXPgO89wq5ck 5LPF2E7Q77TquPavf4Se1gx3F3a7s9BIOrWK7DH3eQYZoBUYa65C8ZtbB+dJgBreYHV/2g9zA/hG 4IT7HbMgAGkILNElY65akNcGpjW22M6Z8SF4/2BNagXABSTRHSgTpzh41Oe77Pl19RfHsjK1ADsu 3IqLB9mL7aISzPaMnn8FWAZzhF/RMOf64YDJDuqkvV8zXojt8jShGGJzkmcAAAAAAAA= --Apple-Mail-169--309806697-- From cabo@tzi.org Tue May 3 02:32:37 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33512E06AA for ; Tue, 3 May 2011 02:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.949 X-Spam-Level: X-Spam-Status: No, score=-105.949 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R7eSFYp1qTBk for ; Tue, 3 May 2011 02:32:36 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id DE74EE06F2 for ; Tue, 3 May 2011 02:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id p439WSgY019931; Tue, 3 May 2011 11:32:28 +0200 (CEST) Received: from [192.168.217.101] (p5B3E613E.dip.t-dialin.net [91.62.97.62]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 22D1771A; Tue, 3 May 2011 11:32:28 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <4DBFC3CA.5040505@isode.com> Date: Tue, 3 May 2011 11:32:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1A41D24B-92E6-49FB-9BFB-7BACD01E3391@tzi.org> References: <8B55B68A-3EA2-45F6-8624-6617333C656D@sensinode.com> <6F58467D-2355-45FA-A32A-880302EEF22C@tzi.org> <4DBFC3CA.5040505@isode.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.1084) Cc: core WG Subject: Re: [core] ABNF help X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 03 May 2011 09:32:37 -0000 On May 3, 2011, at 10:58, Alexey Melnikov wrote: > If I were to implement this and I were to store these values as = integers (as opposed to strings), I would need to know the possible = upper limit. This depends on what kind of integers you have... But seriously, for a producer of this format, the size of the resources = will fit nicely with its integer processing capabilities. For a = consumer, the only thing that may be needed is one representation for = "big", i.e. of a size that is so large that it is no longer relevant for = this kind of implementation. So not having a limit does not hurt. Not hard-wiring one limit is also the right thing to do, as it prevents = Content-Size-style disasters when that one limit turns out to be = overtaken by events. Note that link-format may be used beyond CoAP, so having videos within = the resources is not as unrealistic as one may think from the context of = this WG. Gruesse, Carsten From alexey.melnikov@isode.com Tue May 3 02:38:33 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E1D0E070C for ; Tue, 3 May 2011 02:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D6vGi9aZ2SNX for ; Tue, 3 May 2011 02:38:29 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id BC114E06F2 for ; Tue, 3 May 2011 02:38:28 -0700 (PDT) Received: from [188.28.73.38] (188.28.73.38.threembb.co.uk [188.28.73.38]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 3 May 2011 10:38:26 +0100 Message-ID: <4DBFCD09.90707@isode.com> Date: Tue, 03 May 2011 10:38:17 +0100 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: <8B55B68A-3EA2-45F6-8624-6617333C656D@sensinode.com> <6F58467D-2355-45FA-A32A-880302EEF22C@tzi.org> <4DBFC3CA.5040505@isode.com> <1A41D24B-92E6-49FB-9BFB-7BACD01E3391@tzi.org> In-Reply-To: <1A41D24B-92E6-49FB-9BFB-7BACD01E3391@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] ABNF help X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 03 May 2011 09:38:33 -0000 Carsten Bormann wrote: >On May 3, 2011, at 10:58, Alexey Melnikov wrote: > > >>If I were to implement this and I were to store these values as integers (as opposed to strings), I would need to know the possible upper limit. >> >> >This depends on what kind of integers you have... > > Usual 32bit/64bit C types which I don't want to overflow, if I am not careful. >But seriously, for a producer of this format, the size of the resources will fit nicely with its integer processing capabilities. For a consumer, the only thing that may be needed is one representation for "big", i.e. of a size that is so large that it is no longer relevant for this kind of implementation. So not having a limit does not hurt. > > I don't want a naive consumer to dump core because the producer decided to generate a 128bit size. And guess what, some malicious producers would do this on purpose to deny service. In IMAP I know that all sizes are limited to 32bit. If you want more, you need to defined & negotiate an extension. >Not hard-wiring one limit is also the right thing to do, as it prevents Content-Size-style disasters when that one limit turns out to be overtaken by events. > > If you choose your size carefully, I doubt that this will happen in our lifetime. >Note that link-format may be used beyond CoAP, so having videos within the resources is not as unrealistic as one may think from the context of this WG. > > Well, Ok. But I don't think this changes the gist of my argument. From cabo@tzi.org Tue May 3 02:55:00 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA1CE07A9 for ; Tue, 3 May 2011 02:55:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.099 X-Spam-Level: X-Spam-Status: No, score=-106.099 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9upnuqgFX-kT for ; Tue, 3 May 2011 02:54:59 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id B01B7E0750 for ; Tue, 3 May 2011 02:54: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 p439sprb003104; Tue, 3 May 2011 11:54:51 +0200 (CEST) Received: from [192.168.217.101] (p5B3E613E.dip.t-dialin.net [91.62.97.62]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 589D574A; Tue, 3 May 2011 11:54:51 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <4DBFCD09.90707@isode.com> Date: Tue, 3 May 2011 11:54:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6759ECAB-99C1-463D-8BC4-0B10AB2BE5AD@tzi.org> References: <8B55B68A-3EA2-45F6-8624-6617333C656D@sensinode.com> <6F58467D-2355-45FA-A32A-880302EEF22C@tzi.org> <4DBFC3CA.5040505@isode.com> <1A41D24B-92E6-49FB-9BFB-7BACD01E3391@tzi.org> <4DBFCD09.90707@isode.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.1084) Cc: core WG Subject: Re: [core] ABNF help X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 03 May 2011 09:55:00 -0000 >> But seriously, for a producer of this format, the size of the = resources will fit nicely with its integer processing capabilities. For = a consumer, the only thing that may be needed is one representation for = "big", i.e. of a size that is so large that it is no longer relevant for = this kind of implementation. So not having a limit does not hurt. >>=20 > I don't want a naive consumer to dump core because the producer = decided to generate a 128bit size. And guess what, some malicious = producers would do this on purpose to deny service. OK, so let's add something like: Note that there is no defined upper limit to the value of the sz = attribute. Implementations MUST be prepared to accept large values. =20 Implementation note: One implementation strategy is to convert = any value larger than a reasonable size limit for this implementation to = a special value "Big", which in further processing would indicate that a = size value was given that was so big that it cannot be processed by this = implementation. > In IMAP I know that all sizes are limited to 32bit. If you want more, = you need to defined & negotiate an extension. But in IMAP you actually need to process the values, as this is a = protocol that allows you to operate on the objects. Link-format is = descriptive only (and there is no IMAP connection to negotiate anything = on, either). >> Not hard-wiring one limit is also the right thing to do, as it = prevents Content-Size-style disasters when that one limit turns out to = be overtaken by events. >>=20 > If you choose your size carefully, I doubt that this will happen in = our lifetime. 1208925819614629174706175 (for an 80-bit integer)? I'm not sure that helps anyone... Gruesse, Carsten From zach@sensinode.com Tue May 3 03:36:26 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB81E07B3 for ; Tue, 3 May 2011 03:36:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.197 X-Spam-Level: X-Spam-Status: No, score=-3.197 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VaFkE+XOnU6R for ; Tue, 3 May 2011 03:36:25 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id E5371E073D for ; Tue, 3 May 2011 03:36:24 -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 p43AaGoo009621 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 May 2011 13:36:17 +0300 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-176--305735421; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: <6759ECAB-99C1-463D-8BC4-0B10AB2BE5AD@tzi.org> Date: Tue, 3 May 2011 13:36:18 +0300 Message-Id: References: <8B55B68A-3EA2-45F6-8624-6617333C656D@sensinode.com> <6F58467D-2355-45FA-A32A-880302EEF22C@tzi.org> <4DBFC3CA.5040505@isode.com> <1A41D24B-92E6-49FB-9BFB-7BACD01E3391@tzi.org> <4DBFCD09.90707@isode.com> <6759ECAB-99C1-463D-8BC4-0B10AB2BE5AD@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.1084) Cc: core WG Subject: Re: [core] ABNF help X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 03 May 2011 10:36:26 -0000 --Apple-Mail-176--305735421 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 3, 2011, at 12:54 PM, Carsten Bormann wrote: > OK, so let's add something like: >=20 > Note that there is no defined upper limit to the value of the sz = attribute. > Implementations MUST be prepared to accept large values. =20 > Implementation note: One implementation strategy is to convert = any value larger than a reasonable size limit for this implementation to = a special value "Big", which in further processing would indicate that a = size value was given that was so big that it cannot be processed by this = implementation. I would be OK with text like this. A constrained implementation would = work as described anyways.=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-176--305735421 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 ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDUwMzEwMzYx OVowIwYJKoZIhvcNAQkEMRYEFB9/Ot8Y2EbwyeFEfkqNtmwnfG/gMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAHVF6ITrvnIY9DsOkwIKBzyaV8b3/vvHEnTXyCDe1MiBkR8FZYN2IQQf 7RxWHRRl10o8dMCeB+vG1PCup14kZ411HULCIYAsJssawgGQ8ShaISLFRzB8kfoAAuXC32TJDUfj AtCLlVKhhY9C5GaSbYkqY1+DlA8SMrCZjxyaLiTSKvO+gLG66p0Fx0u1ARk4wIrVYjWdPLYgO6uV 71MZT1DqbCkAtK+xVZ4t7o9teRphMnzAWwUEzgoeNcmAMzZPG8uw01P2zhSHxFMKNwlGtEnEnfi8 e9sfyK2daKzfUTZTSSWBDQEnbelHiwuUXyg7tBw6U+bJJ0e8D7oomhIPbmUAAAAAAAA= --Apple-Mail-176--305735421-- From charles.palmer@onzo.com Tue May 3 03:45:02 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2829E07AB for ; Tue, 3 May 2011 03:45:01 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQf9KLF7QLRl for ; Tue, 3 May 2011 03:45:01 -0700 (PDT) Received: from service38.mimecast.com (service38.mimecast.com [195.130.217.47]) by ietfa.amsl.com (Postfix) with SMTP id 19554E06F2 for ; Tue, 3 May 2011 03:44:58 -0700 (PDT) Received: from onzosbs2k3.ONZO.local (217.138.5.2 [217.138.5.2]) by service38.mimecast.com; Tue, 03 May 2011 11:44:56 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 3 May 2011 11:42:34 +0100 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Edited CoRE IDs Thread-Index: AcwJdKebg7cHaTMfQyWHWda4zsrjJAACigNE References: From: "Charles Palmer" To: X-MC-Unique: 111050311445602002 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CC097F.2388F67A" Subject: [core] Edited CoRE IDs X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 03 May 2011 10:45:02 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC097F.2388F67A Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CC097F.2388F67A" ------_=_NextPart_002_01CC097F.2388F67A Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Dear all To bring myself up to date with CoRE I have read the four IDs. A bi-product= of this is that I have created edited versions of each document, containin= g typo corrections, some text changes that think improve clarity, plus a nu= mber of embedded questions where I did not inderstand what was meant, and r= equesting clarifications. At Zach's suggestion I am copying these to the WG in the hope that there mi= ght be of something of use in here. Regards - Charles Palmer -------------------------------- Onzo is a limited company number 06097997 registered in England & Wales. Th= e =20 registered office is 6 Great Newport Street, London, WC2H 7JB, United Kingd= om. This email message may contain confidential and/or privileged information, = and is intended solely for the addressee(s). If you have received this email in= =20 error, please notify Onzo immediately. Unauthorised copying, disclosure or= =20 distribution of the material in this email is forbidden. -------------------------------- ------_=_NextPart_002_01CC097F.2388F67A Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Edited CoRE IDs =20 =20

Dear all

To bring myself up to date with CoRE I have read the four IDs. A bi-product= of this is that I have created edited versions of each document, containin= g typo corrections, some text changes that think improve clarity, plus a nu= mber of embedded questions where I did not inderstand what was meant, and r= equesting clarifications.

At Zach's suggestion I am copying these to the WG in the hope that there mi= ght be of something of use in here.

Regards - Charles Palmer


--------------------------------
Onzo is a limited company nu= mber 06097997 registered in England & Wales. The
registered office is 6 Great Newport Street, London, WC2H 7JB, Un= ited Kingdom.

This email message may contain confidential and/or privileged inf= ormation, and
is intended solely for the addressee(s). If you have received thi= s email in
error, please notify Onzo im= mediately. Unauthorised copying, disclosure or
distribution of the material in this email is forbidden.
--------------------------------
 ------_=_NextPart_002_01CC097F.2388F67A-- ------_=_NextPart_001_01CC097F.2388F67A Content-Type: text/plain; name=draft-ietf-core-block-02_CGP.txt Content-Transfer-Encoding: base64 Content-Description: draft-ietf-core-block-02_CGP.txt Content-Disposition: attachment; filename="draft-ietf-core-block-02_CGP.txt" e0NoYW5nZXMgYnkgQ2hhcmxlcyBQYWxtZXIgY2hhcmxlcy5wYWxtZXJAb256by5jb20gCi0gVXNl IGEgZGlmZiB0b29sIHRvIGxvY2F0ZSB0aGUgY2hhbmdlcy4KLSBQcmVzdW1lZCBzdHJhaWdodC1m b3J3YXJkIGVkaXRvcmlhbCBjb3JyZWN0aW9ucyBvciByZXdvcmRpbmcgdG8KaW1wcm92ZSBjbGFy aXR5IGFyZSBwcm92aWRlZCB3aXRob3V0IGNvbW1lbnQgKGJ1dCBzaG91bGQgYmUgY2hlY2tlZCEp LgotIENvbW1lbnRzIGFuZCBxdWVzdGlvbnMgYXJlIGlkZW50aWZpZWQgYnkge3BhcmVudGhlc2Vz fS4KLSBNb3JlcyBzaWduaWZpY2FudCBpc3N1ZXMgaW5jbHVkZSB3aGV0aGVyIHJhbmRvbSBhY2Nl c3MgdG8gYmxvY2tzCmlzIHBlcm1pdHRlZCwgdXNlIG9mIHRoZSBNIGJpdCwgd2hhdCBpcyBtZWFu dCBieSAiZmluYWwgcmVzcG9uc2UsIAp1c2Ugb2YgRVRhZyBhbmQgVG9rZW4gb3B0aW9ucywgIn0K CgpDb1JFIFdvcmtpbmcgR3JvdXAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgWi4gU2hlbGJ5LCBFZC4KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgU2Vuc2lub2RlCkludGVuZGVkIHN0YXR1czogU3RhbmRh cmRzIFRyYWNrICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQy4gQm9ybWFubgpFeHBpcmVz OiBTZXB0ZW1iZXIgMTUsIDIwMTEgICAgICAgICAgICAgICAgICAgICAgVW5pdmVyc2l0YWV0IEJy ZW1lbiBUWkkKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIE1hcmNoIDE0LCAyMDExCgoKICAgICAgICAgICAgICAgICAgICAgIEJsb2Nrd2lz ZSB0cmFuc2ZlcnMgaW4gQ29BUAogICAgICAgICAgICAgICAgICAgICAgICBkcmFmdC1pZXRmLWNv cmUtYmxvY2stMDIKCkFic3RyYWN0CgogICBDb0FQIGlzIGEgUkVTVGZ1bCB0cmFuc2ZlciBwcm90 b2NvbCBmb3IgY29uc3RyYWluZWQgbm9kZXMgYW5kCiAgIG5ldHdvcmtzLiAgQ29BUCBpcyBiYXNl ZCBvbiBkYXRhZ3JhbSB0cmFuc3BvcnQsIHdoaWNoIGxpbWl0cyB0aGUKICAgbWF4aW11bSBzaXpl IG9mIHJlc291cmNlIHJlcHJlc2VudGF0aW9ucyB0aGF0IGNhbiBiZSB0cmFuc2ZlcnJlZAogICB3 aXRob3V0IHRvbyBtdWNoIGZyYWdtZW50YXRpb24uICBUaGUgQmxvY2sgT3B0aW9uIHByb3ZpZGVz IGEgc2ltcGxlCiAgIHdheSB0byB0cmFuc2ZlciBsYXJnZXIgcmVwcmVzZW50YXRpb25zIGluIGEg YmxvY2std2lzZSBmYXNoaW9uLCBzdWNoCiAgIHRoYXQgZWFjaCBibG9jayBjYW4gYmUgdHJhbnNm ZXJyZWQgaW4gYSBzaW5nbGUgbGluay1sYXllciBwYWNrZXQuIAogICB7Y29ycmVjdD99CgpTdGF0 dXMgb2YgdGhpcyBNZW1vCgogICBUaGlzIEludGVybmV0LURyYWZ0IGlzIHN1Ym1pdHRlZCBpbiBm dWxsIGNvbmZvcm1hbmNlIHdpdGggdGhlCiAgIHByb3Zpc2lvbnMgb2YgQkNQIDc4IGFuZCBCQ1Ag NzkuCgogICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRl cm5ldCBFbmdpbmVlcmluZwogICBUYXNrIEZvcmNlIChJRVRGKS4gIE5vdGUgdGhhdCBvdGhlciBn cm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZQogICB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5l dC1EcmFmdHMuICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LQogICBEcmFmdHMgaXMgYXQg aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RyYWZ0cy9jdXJyZW50Ly4KCiAgIEludGVybmV0 LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1v bnRocwogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3Ro ZXIgZG9jdW1lbnRzIGF0IGFueQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2Ug SW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQogICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0g b3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iCgogICBUaGlzIEludGVybmV0LURyYWZ0 IHdpbGwgZXhwaXJlIG9uIFNlcHRlbWJlciAxNSwgMjAxMS4KCkNvcHlyaWdodCBOb3RpY2UKCiAg IENvcHlyaWdodCAoYykgMjAxMSBJRVRGIFRydXN0IGFuZCB0aGUgcGVyc29ucyBpZGVudGlmaWVk IGFzIHRoZQogICBkb2N1bWVudCBhdXRob3JzLiAgQWxsIHJpZ2h0cyByZXNlcnZlZC4KCiAgIFRo aXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRydXN0J3MgTGVn YWwKICAgUHJvdmlzaW9ucyBSZWxhdGluZyB0byBJRVRGIERvY3VtZW50cwogICAoaHR0cDovL3Ry dXN0ZWUuaWV0Zi5vcmcvbGljZW5zZS1pbmZvKSBpbiBlZmZlY3Qgb24gdGhlIGRhdGUgb2YKICAg cHVibGljYXRpb24gb2YgdGhpcyBkb2N1bWVudC4gIFBsZWFzZSByZXZpZXcgdGhlc2UgZG9jdW1l bnRzCiAgIGNhcmVmdWxseSwgYXMgdGhleSBkZXNjcmliZSB5b3VyIHJpZ2h0cyBhbmQgcmVzdHJp Y3Rpb25zIHdpdGggcmVzcGVjdAogICB0byB0aGlzIGRvY3VtZW50LiAgQ29kZSBDb21wb25lbnRz IGV4dHJhY3RlZCBmcm9tIHRoaXMgZG9jdW1lbnQgbXVzdAogICBpbmNsdWRlIFNpbXBsaWZpZWQg QlNEIExpY2Vuc2UgdGV4dCBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiA0LmUgb2YKICAgdGhlIFRy dXN0IExlZ2FsIFByb3Zpc2lvbnMgYW5kIGFyZSBwcm92aWRlZCB3aXRob3V0IHdhcnJhbnR5IGFz CgoKClNoZWxieSAmIEJvcm1hbm4gICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMTUsIDIwMTEgICAg ICAgICAgICAgICBbUGFnZSAxXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgQmxvY2t3aXNlIHRy YW5zZmVycyBpbiBDb0FQICAgICAgICAgICAgTWFyY2ggMjAxMQoKCiAgIGRlc2NyaWJlZCBpbiB0 aGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZS4KCgpUYWJsZSBvZiBDb250ZW50cwoKICAgMS4gIElu dHJvZHVjdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICAzCiAgIDIuICBCbG9jay13aXNlIHRyYW5zZmVycyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAgNQogICAgIDIuMS4gIFRoZSBCbG9jayBPcHRpb24gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDUKICAgICAyLjIuICBVc2luZyB0 aGUgQmxvY2sgT3B0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA3CiAg IDMuICBFeGFtcGxlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAxMAogICAgIDMuMS4gIEhUVFAgTWFwcGluZyBDb25zaWRlcmF0aW9ucyAgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTUKICAgNC4gIElBTkEgQ29uc2lkZXJhdGlvbnMg IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE3CiAgIDUuICBTZWN1 cml0eSBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAxOAogICAgIDUuMS4gIE1pdGlnYXRpbmcgUmVzb3VyY2UgRXhoYXVzdGlvbiBBdHRhY2tzIC4g LiAuIC4gLiAuIC4gLiAuIC4gMTgKICAgICA1LjIuICBNaXRpZ2F0aW5nIEFtcGxpZmljYXRpb24g QXR0YWNrcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE5CiAgIDYuICBBY2tub3dsZWRnZW1l bnRzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyMAogICA3 LiAgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gMjEKICAgICA3LjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDIxCiAgICAgNy4yLiAgSW5mb3JtYXRpdmUgUmVmZXJl bmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyMQogICBBdXRob3JzJyBB ZGRyZXNzZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g MjIKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKClNoZWxieSAmIEJvcm1hbm4gICAgICAg RXhwaXJlcyBTZXB0ZW1iZXIgMTUsIDIwMTEgICAgICAgICAgICAgICBbUGFnZSAyXQoMCkludGVy bmV0LURyYWZ0ICAgICAgICAgQmxvY2t3aXNlIHRyYW5zZmVycyBpbiBDb0FQICAgICAgICAgICAg TWFyY2ggMjAxMQoKCjEuICBJbnRyb2R1Y3Rpb24KCiAgIFRoZSBDb1JFIFdHIGlzIHRhc2tlZCB3 aXRoIHN0YW5kYXJkaXppbmcgYW4gQXBwbGljYXRpb24gUHJvdG9jb2wgZm9yCiAgIENvbnN0cmFp bmVkIE5ldHdvcmtzL05vZGVzLCBDb0FQLiAgVGhpcyBwcm90b2NvbCBpcyBpbnRlbmRlZCB0bwog ICBwcm92aWRlIFJFU1RmdWwgW1JFU1RdIHNlcnZpY2VzIG5vdCB1bmxpa2UgSFRUUCBbUkZDMjYx Nl0sIHdoaWxlCiAgIHJlZHVjaW5nIHRoZSBjb21wbGV4aXR5IG9mIGltcGxlbWVudGF0aW9uIGFz IHdlbGwgYXMgdGhlIHNpemUgb2YKICAgcGFja2V0cyBleGNoYW5nZWQgaW4gb3JkZXIgdG8gbWFr ZSB0aGVzZSBzZXJ2aWNlcyB1c2VmdWwgaW4gYSBoaWdobHkKICAgY29uc3RyYWluZWQgbmV0d29y ayBvZiB0aGVtc2VsdmVzIGhpZ2hseSBjb25zdHJhaW5lZCBub2Rlcy4KCiAgIFRoaXMgb2JqZWN0 aXZlIHJlcXVpcmVzIHJlc3RyYWludCBpbiBhIG51bWJlciBvZiBzb21ldGltZXMKICAgY29uZmxp Y3Rpbmcgd2F5czoKCiAgIG8gIHJlZHVjaW5nIGltcGxlbWVudGF0aW9uIGNvbXBsZXhpdHkgaW4g b3JkZXIgdG8gbWluaW1pemUgY29kZSBzaXplLAoKICAgbyAgcmVkdWNpbmcgbWVzc2FnZSBzaXpl cyBpbiBvcmRlciB0byBtaW5pbWl6ZSB0aGUgbnVtYmVyIG9mCiAgICAgIGZyYWdtZW50cyBuZWVk ZWQgZm9yIGVhY2ggbWVzc2FnZSAoaW4gdHVybiB0byBtYXhpbWl6ZSB0aGUKICAgICAgcHJvYmFi aWxpdHkgb2YgZGVsaXZlcnkgb2YgdGhlIG1lc3NhZ2UpLCB0aGUgYW1vdW50IG9mCiAgICAgIHRy YW5zbWlzc2lvbiBwb3dlciBuZWVkZWQgYW5kIHRoZSBsb2FkaW5nIG9mIHRoZSBsaW1pdGVkLWJh bmR3aWR0aAogICAgICBjaGFubmVsLAoKICAgbyAgcmVkdWNpbmcgcmVxdWlyZW1lbnRzIG9uIHRo ZSBlbnZpcm9ubWVudCBzdWNoIGFzIHN0YWJsZSBzdG9yYWdlLAogICAgICBnb29kIHNvdXJjZXMg b2YgcmFuZG9tbmVzcyBvciB1c2VyIGludGVyYWN0aW9uIGNhcGFiaWxpdGllcy4KCiAgIENvQVAg aXMgYmFzZWQgb24gZGF0YWdyYW0gdHJhbnNwb3J0cyBzdWNoIGFzIFVEUCwgd2hpY2ggbGltaXQg dGhlCiAgIG1heGltdW0gc2l6ZSBvZiByZXNvdXJjZSByZXByZXNlbnRhdGlvbnMgdGhhdCBjYW4g YmUgdHJhbnNmZXJyZWQKICAgd2l0aG91dCBjcmVhdGluZyB1bnJlYXNvbmFibGUgbGV2ZWxzIG9m IElQIGZyYWdtZW50YXRpb24uICBJbgogICBhZGRpdGlvbiwgbm90IGFsbCByZXNvdXJjZSByZXBy ZXNlbnRhdGlvbnMgd2lsbCBmaXQgaW50byBhIHNpbmdsZQogICBsaW5rIGxheWVyIHBhY2tldCBv ZiBhIGNvbnN0cmFpbmVkIG5ldHdvcmssIHdoaWNoIG1heSBjYXVzZQogICBhZGFwdGF0aW9uIGxh eWVyIGZyYWdtZW50YXRpb24gZXZlbiBpZiBJUCBsYXllciBmcmFnbWVudGF0aW9uIGlzIG5vdAog ICByZXF1aXJlZC4gIFVzaW5nIGZyYWdtZW50YXRpb24gKGVpdGhlciBhdCB0aGUgYWRhcHRhdGlv biBsYXllciBvciBhdAogICB0aGUgSVAgbGF5ZXIpIHRvIGVuYWJsZSB0aGUgdHJhbnNwb3J0IG9m IGxhcmdlciByZXByZXNlbnRhdGlvbnMgaXMKICAgcG9zc2libGUgdXAgdG8gdGhlIG1heGltdW0g c2l6ZSBvZiB0aGUgdW5kZXJseWluZyBkYXRhZ3JhbSBwcm90b2NvbAogICAoc3VjaCBhcyBVRFAp LCBidXQgdGhlIGZyYWdtZW50YXRpb24vcmVhc3NlbWJseSBwcm9jZXNzIGxvYWRzIHRoZQogICBs b3dlciBsYXllcnMgd2l0aCBjb252ZXJzYXRpb24gc3RhdGUgdGhhdCBpcyBiZXR0ZXIgbWFuYWdl ZCBpbiB0aGUKICAgYXBwbGljYXRpb24gbGF5ZXIuCgogICBUaGlzIHNwZWNpZmljYXRpb24gZGVm aW5lcyBhIENvQVAgb3B0aW9uIHRvIGVuYWJsZSBfYmxvY2std2lzZV8KICAgYWNjZXNzIHRvIHJl c291cmNlIHJlcHJlc2VudGF0aW9ucy4gIFRoZSBCbG9jayBPcHRpb24gcHJvdmlkZXMgYQogICBt aW5pbWFsIHdheSB0byB0cmFuc2ZlciBsYXJnZXIgcmVzb3VyY2UgcmVwcmVzZW50YXRpb25zIGlu IGEgYmxvY2stCiAgIHdpc2UgZmFzaGlvbi4gIFRoZSBvdmVycmlkaW5nIG9iamVjdGl2ZSBpcyB0 byBhdm9pZCBjcmVhdGluZwogICBjb252ZXJzYXRpb24gc3RhdGUgYXQgdGhlIHNlcnZlciBmb3Ig YmxvY2std2lzZSBHRVQgcmVxdWVzdHMuICAoSXQgaXMKICAgaW1wb3NzaWJsZSB0byBmdWxseSBh dm9pZCBjcmVhdGluZyBjb252ZXJzYXRpb24gc3RhdGUgZm9yIFBPU1QvUFVULAogICBpZiB0aGUg Y3JlYXRpb24vcmVwbGFjZW1lbnQgb2YgcmVzb3VyY2VzIGlzIHRvIGJlIGF0b21pYzsgd2hlcmUg dGhhdAogICBwcm9wZXJ0eSBpcyBub3QgbmVlZGVkLCB0aGVyZSBpcyBubyBuZWVkIHRvIGNyZWF0 ZSBzZXJ2ZXIKICAgY29udmVyc2F0aW9uIHN0YXRlIGluIHRoaXMgY2FzZSwgZWl0aGVyLikKCiAg IEluIHN1bW1hcnksIHRoaXMgc3BlY2lmaWNhdGlvbiBhZGRzIGEgQmxvY2sgT3B0aW9uIHRvIENv QVAgdGhhdCBjYW4KICAgYmUgdXNlZCBmb3IgYmxvY2std2lzZSB0cmFuc2ZlcnMuICBCZW5lZml0 cyBvZiB1c2luZyB0aGlzIG9wdGlvbgoKCgpTaGVsYnkgJiBCb3JtYW5uICAgICAgIEV4cGlyZXMg U2VwdGVtYmVyIDE1LCAyMDExICAgICAgICAgICAgICAgW1BhZ2UgM10KDApJbnRlcm5ldC1EcmFm dCAgICAgICAgIEJsb2Nrd2lzZSB0cmFuc2ZlcnMgaW4gQ29BUCAgICAgICAgICAgIE1hcmNoIDIw MTEKCgogICBpbmNsdWRlOgoKICAgbyAgVHJhbnNmZXJzIGxhcmdlciB0aGFuIGNhbiBiZSBhY2Nv bW1vZGF0ZWQgaW4gY29uc3RyYWluZWQtbmV0d29yawogICAgICBsaW5rLWxheWVyIHBhY2tldHMg Y2FuIGJlIHBlcmZvcm1lZCBpbiBzbWFsbGVyIGJsb2Nrcy4KCiAgIG8gIE5vIGhhcmQtdG8tbWFu YWdlIGNvbnZlcnNhdGlvbiBzdGF0ZSBpcyBjcmVhdGVkIGF0IHRoZSBhZGFwdGF0aW9uCiAgICAg IGxheWVyIG9yIElQIGxheWVyIGZvciBmcmFnbWVudGF0aW9uLgoKICAgbyAgVGhlIHRyYW5zZmVy IG9mIGVhY2ggYmxvY2sgaXMgYWNrbm93bGVkZ2VkLCBlbmFibGluZwogICAgICByZXRyYW5zbWlz c2lvbiBpZiByZXF1aXJlZC4KCiAgIG8gIEJvdGggc2lkZXMgaGF2ZSBhIHNheSBpbiB0aGUgYmxv Y2sgc2l6ZSB0aGF0IGFjdHVhbGx5IHdpbGwgYmUKICAgICAgdXNlZC4KCiAgIG8gIFRoZSByZXN1 bHRpbmcgZXhjaGFuZ2VzIGFyZSBlYXN5IHRvIHVuZGVyc3RhbmQgdXNpbmcgcGFja2V0CiAgICAg IGFuYWx5emVyIHRvb2xzIGFuZCB0aHVzIHF1aXRlIGFjY2Vzc2libGUgdG8gZGVidWdnaW5nLgoK ICAgbyAgSWYgbmVlZGVkLCB0aGUgQmxvY2sgT3B0aW9uIGNhbiBhbHNvIGJlIHVzZWQgYXMgaXMg dG8gcHJvdmlkZQogICAgICByYW5kb20gYWNjZXNzIHRvIHBvd2VyLW9mLXR3byBzaXplZCBibG9j a3Mgd2l0aGluIGEgcmVzb3VyY2UKICAgICAgcmVwcmVzZW50YXRpb24uCgogICBUaGUga2V5IHdv cmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIs CiAgICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9Q VElPTkFMIiBpbiB0aGlzCiAgIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNj cmliZWQgaW4gUkZDIDIxMTksIEJDUCAxNAogICBbUkZDMjExOV0gYW5kIGluZGljYXRlIHJlcXVp cmVtZW50IGxldmVscyBmb3IgY29tcGxpYW50IENvQVAKICAgaW1wbGVtZW50YXRpb25zLgoKICAg SW4gdGhpcyBkb2N1bWVudCwgdGhlIHRlcm0gImJ5dGUiIGlzIHVzZWQgaW4gaXRzIG5vdyBjdXN0 b21hcnkgc2Vuc2UKICAgYXMgYSBzeW5vbnltIGZvciAib2N0ZXQiLgoKICAgV2hlcmUgYml0IGFy aXRobWV0aWMgaXMgZXhwbGFpbmVkLCB0aGlzIGRvY3VtZW50IHVzZXMgdGhlIG5vdGF0aW9uCiAg IGZhbWlsaWFyIGZyb20gdGhlIHByb2dyYW1taW5nIGxhbmd1YWdlIEMsIGV4Y2VwdCB0aGF0IHRo ZSBvcGVyYXRvcgogICAiXiIgc3RhbmRzIGZvciBleHBvbmVudGlhdGlvbi4KCgoKCgoKCgoKCgoK CgoKCgoKU2hlbGJ5ICYgQm9ybWFubiAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAxNSwgMjAxMSAg ICAgICAgICAgICAgIFtQYWdlIDRdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICBCbG9ja3dpc2Ug dHJhbnNmZXJzIGluIENvQVAgICAgICAgICAgICBNYXJjaCAyMDExCgoKMi4gIEJsb2NrLXdpc2Ug dHJhbnNmZXJzCgoyLjEuICBUaGUgQmxvY2sgT3B0aW9uCgogICAge0kgYWRkZWQgaW50cm9kdWN0 b3J5IHNlbnRlbmNlcyBmb3IgY29uc2lzdGVuY3kgd2l0aCB0aGUgb3RoZXIgb3B0aW9uIAogICAg ZGVmaW5pdGlvbnMgaW4gY29hcC0wNS4gUGxlYXNlIGNoZWNrISBBbHNvIC0gZm9yIGNvbnNpc3Rl bmN5IHdpdGgKICAgIGNvYXAtMDUgSSBoYXZlIGNoYW5nZWQgIkJsb2NrIG9wdGlvbiIgdG8gIkJs b2NrIE9wdGlvbiIgdGhyb3VnaG91dC59CiAgICAKICAgIFRoZSBCbG9jayBPcHRpb24gc3VwcG9y dHMgdGhlIHRyYW5zZmVyIG9mIGxlbmd0aHkgcmVzb3VyY2UgCiAgICByZXByZXNlbnRhdGlvbnMg aW4gYSBzZXF1ZW5jZSBvZiBzbWFsbGVyIGJsb2Nrcy4gSW1wbGVtZW50YXRpb24gb2YgdGhlIAog ICAgQmxvY2sgT3B0aW9uIGlzIG9wdGlvbmFsLiBIb3dldmVyLCB3aGVuIGl0IGlzIHByZXNlbnQg aW4gYSBDb0FQIAogICAgbWVzc2FnZSwgaXQgTVVTVCBiZSBwcm9jZXNzZWQsIG9yIHRoZSBtZXNz YWdlIHJlamVjdGVkLiBUaGVyZWZvcmUgCiAgICBpdCBpcyBpZGVudGlmaWVkIGFzIGEgImNyaXRp Y2FsIiBvcHRpb24uIEl0IE1VU1QgTk9UIG9jY3VyIG1vcmUgCiAgICB0aGFuIG9uY2UuCiAgICAK ICAgIHtmb3JtYXR0aW5nIGFkanVzdG1lbnRzIHRvIG1hdGNoIGNvYXAtMDUgVGFibGUgMX0KCiAg ICAgICAgKy0tLS0tLSstLS0tLS0tLS0tKy0tLS0tLS0rLS0tLS0tLS0tLS0rLS0tLS0tLS0rLS0t LS0tLS0tLS0tLS0tKwogICAgICAgIHwgVHlwZSB8IEMvRSAgICAgIHwgTmFtZSAgfCBGb3JtYXQg ICAgfCBMZW5ndGggfCBEZWZhdWx0ICAgICAgIHwKICAgICAgICArLS0tLS0tKy0tLS0tLS0tLS0r LS0tLS0tLSstLS0tLS0tLS0tLSstLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rCiAgICAgICAgfCAg IDEzIHwgQ3JpdGljYWwgfCBCbG9jayB8IHVpbnQgICAgICB8IDEtMyBCICB8IDAgKHNlZSBiZWxv dykgfAogICAgICAgICstLS0tLS0rLS0tLS0tLS0tLSstLS0tLS0tKy0tLS0tLS0tLS0tKy0tLS0t LS0tKy0tLS0tLS0tLS0tLS0tLSsKCiAgICAgICAgICAgICAgICAgICAgICBUYWJsZSAxOiBCbG9j ayBPcHRpb24KCiAgIFRoZSBzaXplIG9mIHRoZSBibG9ja3Mgc2hvdWxkIG5vdCBiZSBmaXhlZCBi eSB0aGUgcHJvdG9jb2wuICBPbiB0aGUKICAgb3RoZXIgaGFuZCwgaW1wbGVtZW50YXRpb24gc2hv dWxkIGJlIGFzIHNpbXBsZSBhcyBwb3NzaWJsZS4gIFRoZQogICBCbG9jayBPcHRpb24gdGhlcmVm b3JlIHN1cHBvcnRzIGEgc21hbGwgcmFuZ2Ugb2YgcG93ZXItb2YtdHdvIGJsb2NrCiAgIHNpemVz LCBmcm9tIDJeNCAoMTYpIHRvIDJeMTEgKDIwNDgpIGJ5dGVzLiAgVGhlc2UgZWlnaHQgdmFsdWVz CiAgIGNhbiBiZSBlbmNvZGVkIGluIHRocmVlIGJpdHMgKDAgZm9yIDJeNCB0byA3IGZvciAyXjEx IGJ5dGVzKSwgd2hpY2gKICAgd2UgY2FsbCB0aGUgIlNaWCIgKHNpemUgZXhwb25lbnQpLiBUaGUg YWN0dWFsIGJsb2NrIHNpemUgaXMgdGhlbgogICAyXihTWlgrNCkuIChUaGUgc2l6ZSBvZiB0aGUg ZmluYWwgYmxvY2sgbWF5IGJlIGxlc3MgdGhhbiB0aGlzLikKCiAgIFdoZW4gYSByZXNvdXJjZSBy ZXByZXNlbnRhdGlvbiBpcyBsYXJnZXIgdGhhbiBjYW4gYmUgY29tZm9ydGFibHkgCiAgIHRyYW5z ZmVycmVkCiAgIGluIGEgc2luZ2xlIFVEUCBkYXRhZ3JhbSwgdGhlIEJsb2NrIE9wdGlvbiBjYW4g YmUgdXNlZCB0byBpbmRpY2F0ZSBhCiAgIGJsb2NrLXdpc2UgdHJhbnNmZXIuICBUaGUgb3B0aW9u IHZhbHVlIGlzIGEgMS0sIDItIG9yIDMtYnl0ZSBpbnRlZ2VyLCAKICAgdGhlIGZvdXIKICAgbGVh c3Qgc2lnbmlmaWNhbnQgYml0cyBvZiB3aGljaCBpbmRpY2F0ZSB0aGUgYmxvY2sgc2l6ZSBhbmQg d2hldGhlciB0aGUKICAgY3VycmVudCBibG9jay13aXNlIHRyYW5zZmVyIGlzIHRoZSBsYXN0IGJs b2NrIGJlaW5nIHRyYW5zZmVycmVkIAogICAoSW5kaWNhdGVkIGJ5IHRoZSBNIG9yICJtb3JlIiBi aXQpLiAgVGhlIG9wdGlvbiB2YWx1ZSdzIE5VTSBmaWVsZCBpcyAKICAgdGhlIG51bWJlciBvZgog ICB0aGUgYmxvY2sgY3VycmVudGx5IGJlaW5nIHRyYW5zZmVycmVkLCBzdGFydGluZyBmcm9tIHpl cm8uIFRoZQogICBjdXJyZW50IHRyYW5zZmVyIGlzIHRoZXJlZm9yZSB0aGUgInNpemUiIGJ5dGVz IChhbHRob3VnaCBmZXdlciBieXRlcyAKICAgbWF5IGJlIHRyYW5zZmVycmVkIGluIHRoZSBmaW5h bCBibG9jaykgc3RhcnRpbmcgYXQgYnl0ZSAiYmxvY2sKICAgbnVtYmVyIDw8IChTWlggKyA0KSIu IAogICAKICAgVGhlIGRlZmF1bHQgdmFsdWUgb2YgdGhlIEJsb2NrIE9wdGlvbiBpcyB6ZXJvLAog ICBpbmRpY2F0aW5nIHRoYXQgdGhlIGN1cnJlbnQgYmxvY2sgaXMgdGhlIGZpcnN0IChibG9jayBu dW1iZXIgMCkgYW5kCiAgIG9ubHkgKE0gYml0IG5vdCBzZXQpIGJsb2NrIG9mIHRoZSB0cmFuc2Zl ci4gU2luY2UgdGhlIGZpbmFsIGJsb2NrIGNhbiAKICAgYmUgbGVzcyB0aGFuIHRoZSBzaXplIGRl ZmluZWQgYnkgU1pYLCB0aGVyZSBpcyBubyBleHBsaWNpdCBzaXplIGltcGxpZWQgCiAgIGJ5IHRo aXMgZGVmYXVsdCB2YWx1ZSwgdGhvdWdoIGl0IG11c3Qgbm90IGJlIGdyZWF0ZXIgdGhhbiAxNiBi eXRlcy4KICAgCiAgIFRoZSBCbG9jayBPcHRpb24gdmFsdWUgY2FuIGJlIDEsIDIgb3IgMyBieXRl cyBpbiBsZW5ndGgsIGFzIHNob3duIGluIAogICBGaWd1cmUgMS4KICAgCiAgIHtJcyB0aGVyZSBy ZWFsbHkgYSBuZWVkIGZvciB0aGUgMy1ieXRlIG9wdGlvbj8gRXZlbiBpZiBTWlggaXMgMCwgdGhl CiAgIHR3by1ieXRlIG9wdGlvbiBjYW4gYWxsb3cgZm9yIHRoZSB0cmFuc2ZlciBvZiA2NGsgYnl0 ZSBtZXNzYWdlcy4gV291bGQgCiAgIHRoZXJlIGV2ZXIgYmUgbGFyZ2VyIG1lc3NhZ2VzIHRvIHRy YW5zZmVyIHRoaXMgd2F5PyBDb2FwLTA1IHNheXMgYQogICBDb0FQIG1lc3NhZ2UgIk1VU1QgZml0 IHdpdGhpbiBhIHNpbmdsZSBJUCBkYXRhZ3JhbSIgd2hpY2ggSSB0aGluawogICBpcyA2NGsufQoK CgoKCgoKClNoZWxieSAmIEJvcm1hbm4gICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMTUsIDIwMTEg ICAgICAgICAgICAgICBbUGFnZSA1XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgQmxvY2t3aXNl IHRyYW5zZmVycyBpbiBDb0FQICAgICAgICAgICAgTWFyY2ggMjAxMQoKCiAgICAgICAgICAgMAog ICAgICAgICAgIDAgMSAyIDMgNCA1IDYgNwogICAgICAgICAgKy0rLSstKy0rLSstKy0rLSsKICAg ICAgICAgIHwgIE5VTSAgfE18IFNaWCB8CiAgICAgICAgICArLSstKy0rLSstKy0rLSstKwoKICAg ICAgICAgICAwICAgICAgICAgICAgICAgICAgIDEKICAgICAgICAgICAwIDEgMiAzIDQgNSA2IDcg OCA5IDAgMSAyIDMgNCA1CiAgICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSsKICAgICAgICAgIHwgICAgICAgICAgTlVNICAgICAgICAgIHxNfCBTWlggfAogICAgICAgICAg Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCgogICAgICAgICAgIDAgICAgICAgICAg ICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyCiAgICAgICAgICAgMCAxIDIgMyA0IDUgNiA3 IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMKICAgICAgICAgICstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgICAgICAgIHwgICAgICAgICAg ICAgICAgICAgTlVNICAgICAgICAgICAgICAgICB8TXwgU1pYIHwKICAgICAgICAgICstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKCiAgICAgICAgICAgICAg ICAgICAgICAgICAgRmlndXJlIDE6IEJsb2NrIE9wdGlvbgoKICAgKE5vdGUgdGhhdCwgYXMgYW4g aW1wbGVtZW50YXRpb24gY29udmVuaWVuY2UsIHRoZSBvcHRpb24gdmFsdWUgd2l0aAogICB0aGUg bGFzdCA0IGJpdHMgbWFza2VkIG91dCwgc2hpZnRlZCB0byB0aGUgbGVmdCBieSB0aGUgdmFsdWUg b2YgU1pYLAogICBnaXZlcyB0aGUgYnl0ZSBwb3NpdGlvbiBvZiB0aGUgYmxvY2suKQoKICAgTlVN OiAgQmxvY2sgTnVtYmVyLiAgVGhlIGJsb2NrIG51bWJlciBpcyBhIHZhcmlhYmxlLXNpemUgKDQs IDEyLCBvcgogICAgICAyMCBiaXQpIHVuc2lnbmVkIGludGVnZXIgaW5kaWNhdGluZyB0aGUgYmxv Y2sgbnVtYmVyIGJlaW5nCiAgICAgIHJlcXVlc3RlZCBvciBwcm92aWRlZC4gIEJsb2NrIG51bWJl ciAwIGluZGljYXRlcyB0aGUgZmlyc3QgYmxvY2sKICAgICAgb2YgYSByZXByZXNlbnRhdGlvbi4K CiAgIE06IE1vcmUgRmxhZy4gIFRoaXMgZmxhZywgaWYgdW5zZXQsIGluZGljYXRlcyB0aGF0IHRo aXMgYmxvY2sgaXMgdGhlCiAgICAgIGxhc3QgaW4gYSByZXByZXNlbnRhdGlvbi4gIFdoZW4gc2V0 IGl0IGluZGljYXRlcyB0aGF0IHRoZXJlIGFyZQogICAgICBvbmUgb3IgbW9yZSBhZGRpdGlvbmFs IGJsb2NrcyBhdmFpbGFibGUuICBXaGVuIHRoZSBCbG9jayBPcHRpb24gaXMKICAgICAgdXNlZCBp biBhIHJlcXVlc3QgdG8gcmV0cmlldmUgYSBzcGVjaWZpYyBibG9jayBudW1iZXIsIHRoZSBNIGJp dAogICAgICBNVVNUIGJlIHNlbnQgYXMgemVybyBhbmQgaWdub3JlZCBvbiByZWNlcHRpb24uCiAg ICAgIAogICAgICB7VHdvIHBvaW50cyBoZXJlOgogICAgICAKICAgICAgMS4gVGhpcyBsYXN0IHNl bnRlbmNlIGltcGxpZXMgdGhhdCBhIHJlcXVlc3QgbWF5IGJlIHVzZWQgdG8gdHJhbnNmZXIKICAg ICAgYW55IGJsb2NrLCB3aGVyZWFzIHRoZSByZXN0IG9mIHRoZSBkb2N1bWVudCBhbmQgdGhlIGV4 YW1wbGVzIGFsbAogICAgICBzaG93IHRoZSBibG9ja3MgYmVpbmcgZmV0Y2hlZCBpbiBzZXF1ZW5j ZSwgc3RhcnRpbmcgZnJvbSBibG9jayAwLgogICAgICBJZiB0aGVyZSBpcyBhbiBpbnRlbnRpb24g dGhhdCB0aGUgQmxvY2sgT3B0aW9uIGNhbiBiZSB1c2VkIHRvIGFsbG93CiAgICAgIHJhbmRvbSBh Y2Nlc3MgdG8gYmxvY2tzLCByYXRoZXIgdGhhbiBhbiBlbnRpcmUgcmVzb3VyY2UKICAgICAgcmVw cmVzZW50YXRpb24gaW4gYSBzZXF1ZW5jZSwgdGhlbiB0aGVyZSBzaG91bGQgYmUgZXhwbGljaXQg CiAgICAgIHRleHQgdG8gc2F5IHRoYXQgdGhpcyBpcyBwZXJtaXNzaWJsZS4gCiAgICAgIAogICAg ICAyLiBBbHNvIC0gaXMgdGhlcmUgRVZFUiBhIGNhc2Ugd2hlcmUgdGhlIE0gYml0IGlzIHNldCBp biBhIEdFVCAKICAgICAgcmVxdWVzdD8gVGhlcmUgaXMgbm9uZSBzaG93biBpbiB0aGUgZXhhbXBs ZXMuIElmIG5vdCB0aGVuIHRoZSAKICAgICAgd2hvbGUgZGVmaW5pdGlvbiBvZiB0aGUgTSBmbGFn IHNob3VsZCBiZSByZS13cml0dGVuIC0gcGVyaGFwcyAKICAgICAgYXMgZm9sbG93czoKICAgICAg CiAgIE06IE1vcmUgRmxhZy4gV2hlbiB0aGUgTSBmbGFnIGlzIHNldCBpbiBHRVQgcmVzcG9uc2Ug b3IgYSBQVVQgb3IgCiAgICAgIFBPU1QgcmVxdWVzdCwgaXQgaW5kaWNhdGVzIHRoYXQgdGhlcmUg YXJlIG9uZSBvciBtb3JlIGFkZGl0aW9uYWwKICAgICAgYmxvY2tzIHRoYXQgc2hvdWxkIGJlIHRy YW5zZmVycmVkIGJlZm9yZSB0aGUgY29tcGxldGUgcmVzb3VyY2UgCiAgICAgIHJlcHJlc2VudGF0 aW9uIGhhcyBiZWVuIHRyYW5zZmVycmVkLiBJdCBpcyBhbHdheXMgdW5zZXQgaW4gR0VUIAogICAg ICByZXF1ZXN0cy4gVGhlIG1lYW5pbmcgb2YgdGhlIE0gZmxhZyBpbiBQVVQgYW5kIFBPU1QgcmVz cG9uc2VzIGlzCiAgICAgIGRlc2NyaWJlZCBiZWxvdy4gCiAgICAgfQogICAgIAogICBTWlg6ICBC bG9jayBTaXplLiAgVGhlIGJsb2NrIHNpemUgaXMgYSB0aHJlZS1iaXQgdW5zaWduZWQgaW50ZWdl cgogICAgICBpbmRpY2F0aW5nIHRoZSBzaXplIG9mIGEgYmxvY2sgdG8gdGhlIHBvd2VyIG9mIHR3 by4gIFRodXMgYmxvY2sKICAgICAgc2l6ZSA9IDJeKFNaWCArIDQpLiAgQXMgdGhlcmUgYXJlIHRo cmVlIGJpdHMgYXZhaWxhYmxlIGZvciBTWlgsCiAgICAgIHRoZSBtaW5pbXVtIGJsb2NrIHNpemUg aXMgMl4oMCs0KSA9IDE2IGFuZCB0aGUgbWF4aW11bSBpcyAyXig3KzQpCiAgICAgID0gMjA0OC4K CiAgIFRoZSBCbG9jayBPcHRpb24gaXMgdXNlZCBpbiBvbmUgb2YgdGhyZWUgcm9sZXM6CgogICBv ICBJbiB0aGUgcmVxdWVzdCBmb3IgYSBHRVQsIHRoZSBCbG9jayBPcHRpb24gZ2l2ZXMgdGhlIGJs b2NrIG51bWJlcgogICAgICByZXF1ZXN0ZWQgYW5kIHN1Z2dlc3RzIGEgYmxvY2sgc2l6ZSAoaW4g dGhlIGNhc2Ugb2YgYmxvY2sgbnVtYmVyIDApCiAgICAgIG9yIGVjaG9lcyB0aGUKICAgICAgYmxv Y2sgc2l6ZSBvZiBwcmV2aW91cyBibG9ja3MgcmVjZWl2ZWQgKGluIHRoZSBjYXNlIG9mIGJsb2Nr IAogICAgICBudW1iZXJzIG90aGVyIHRoYW4gMCkuIFRoZSBNIGJpdCBNVVNUIGJlIHNldCB0byAw IGluIEdFVCByZXF1ZXN0cyAKICAgICAge2lzIHRoaXMgdHJ1ZT8gSXQgc2hvdWxkIGJlIGV4cGxp Y2l0bHkgZGVmaW5lZC59CgoKCgpTaGVsYnkgJiBCb3JtYW5uICAgICAgIEV4cGlyZXMgU2VwdGVt YmVyIDE1LCAyMDExICAgICAgICAgICAgICAgW1BhZ2UgNl0KDApJbnRlcm5ldC1EcmFmdCAgICAg ICAgIEJsb2Nrd2lzZSB0cmFuc2ZlcnMgaW4gQ29BUCAgICAgICAgICAgIE1hcmNoIDIwMTEKCgog ICAgICB7SSBmZWx0IHRoYXQgdGhlcmUgd2VyZSBqdXN0IGVub3VnaCBkaWZmZXJlbmNlcyBiZXR3 ZWVuIHRoZQogICAgICByZXNwb25zZSB0byBhIEdFVCBhbmQgdGhlIHJlcXVlc3QgZm9yIGEgUFVU IG9yIFBPU1QgdG8ganVzdGlmeQogICAgICBkZXNjcmliaW5nIHRoZXNlIHNlcGFyYXRlbHkuIFdo YXQgZG8geW91IHRoaW5rPyBNeSBhdHRlbXB0IGZvbGxvd3MufQogICAgICAKICAgbyAgSW4gdGhl IHJlc3BvbnNlIGZvciBhIEdFVCwgdGhlIEJsb2NrIE9wdGlvbiBpbmRpY3RlcyB3aGF0IGJsb2Nr IAogICAgICBudW1iZXIgaXMgY29udGFpbmVkIGluIHRoZSBwYXlsb2FkLCB0aGUgYmxvY2sgc2l6 ZSwgYW5kIHdoZXRoZXIgCiAgICAgIGZ1cnRoZXIgYmxvY2tzIGFyZSByZXF1aXJlZCB0byBjb21w bGV0ZSB0aGUgdHJhbnNmZXIgb2YgcmVzb3VyY2UKICAgICAgcmVwcmVzZW50YXRpb24gKGluZGlj YXRlZCBieSB0aGUgTSBiaXQpLiBJZiB0aGUgc2VydmVyIHNldHMgdGhlIAogICAgICBNIGJpdCB0 aGVuIHRoZSBzaXplIG9mIHRoZSBwYXlsb2FkIGJvZHkgTVVTVCBiZSB0aGUgc2l6ZSBnaXZlbiBi eSAKICAgICAgdGhlIFNaWCBmaWVsZCwgYW5kIHRoZSBzZXJ2ZXIgaXMgaW5kaWNhdGluZyB0aGF0 IGZ1cnRoZXIgYmxvY2tzIAogICAgICBhcmUgYXZhaWxhYmxlLiBJZiBzZXJ2ZXIgZG9lcyBub3Qg c2V0IHRoZSBNIGJpdCB0aGVuIHRoZSBzaXplIG9mIAogICAgICB0aGUgcGF5bG9hZCBib2R5IE1V U1QgTk9UIGV4Y2VlZCB0aGUgc2l6ZSBnaXZlbiBieSB0aGUgU1pYIGZpZWxkLAogICAgICBhbmQg dGhlIHNlcnZlciBpcyBpbmRpY2F0aW5nIHRoYXQgdGhlcmUgYXJlIG5vIGZ1cnRoZXIgYmxvY2tz IAogICAgICBhdmFpbGFibGUuIAogICAgICAKICAgICAgVGhlIGJsb2NrIHNpemUgcmV0dXJuZWQg YnkgdGhlIHNlcnZlciwgaW5kaWNhdGVkIGJ5IHRoZSBTWlggZmllbGQsCiAgICAgIGNhbiBiZSBu ZWdvdGlhdGVkIGJldHdlZW4gdGhlIGNsaWVudCBhbmQgdGhlIHNlcnZlciBlYXJseSBpbiB0aGUK ICAgICAgdHJhbnNmZXIgc2VxdWVuY2UsIGFjY29yZGluZyB0byBydWxlcyBnaXZlbiBiZWxvdy4g VGhlcmVhZnRlciwKICAgICAgYWxsIGJsb2NrcyBpbiB0aGUgdHJhbnNmZXIgc2VxdWVuY2UgTVVT VCB1c2UgdGhlIHNhbWUgU1pYIHZhbHVlLgogICAgICAKICAgbyAgSW4gdGhlIHJlcXVlc3QgZm9y IGEgUFVUIG9yIFBPU1QsIHRoZSBCbG9jayBPcHRpb24gaW5kaWNhdGVzIAogICAgICB3aGF0IGJs b2NrIG51bWJlciBpcyBjb250YWluZWQgaW4gdGhlIHBheWxvYWQsIHRoZSBibG9jayBzaXplLAog ICAgICBhbmQgd2hldGhlciBmdXJ0aGVyIGJsb2NrcyBhcmUgcmVxdWlyZWQgdG8gY29tcGxldGUg dGhlIHRyYW5zZmVyCiAgICAgIG9mIHRoZSByZXNvdXJjZSByZXByZXNlbnRhdGlvbiAoaW5kaWNh dGVkIGJ5IHRoZSBNIGJpdCkuIElmIHRoZQogICAgICBjbGllbnQgc2V0cyB0aGUgTSBiaXQgdGhl biB0aGUgc2l6ZSBvZiB0aGUgcGF5bG9hZCBib2R5IE1VU1QgYmUgCiAgICAgIHRoZSBzaXplIGdp dmVuIGJ5IHRoZSBTWlggZmllbGQsIGFuZCB0aGUgY2xpZW50IGlzIGluZGljYXRpbmcgCiAgICAg IHRoYXQgdGhlcmUgYXJlIGZ1cnRoZXIgYmxvY2tzIGluIHRoZSByZXNvdXJjZSByZXByZXNlbnRh dGlvbiwgCiAgICAgIHdoaWNoIHRoZSBzZXJ2ZXIgc2hvdWxkIGV4cGVjdCB0byByZWNlaXZlLiBJ ZiBjbGllbnQgZG9lcyBub3QgCiAgICAgIHNldCB0aGUgTSBiaXQgdGhlbiB0aGUgc2l6ZSBvZiB0 aGUgcGF5bG9hZCBib2R5IE1VU1QgTk9UIGV4Y2VlZCAKICAgICAgdGhlIHNpemUgZ2l2ZW4gYnkg dGhlIFNaWCBmaWVsZCwgYW5kIHRoZSBjbGllbnQgaXMgaW5kaWNhdGluZyAKICAgICAgdGhhdCBp dCBoYXMgZmluaXNoZWQgdHJhbnNmZXJyaW5nIHRoZSByZXNvdXJjZSByZXByZXNlbnRhdGlvbi4K ICAgICAgCiAgICAgIFRoZSBibG9jayBzaXplIHNlbnQgYnkgdGhlIGNsaWVudCwgaW5kaWNhdGVk IGJ5IHRoZSBTWlggZmllbGQsCiAgICAgIGNhbiBiZSBuZWdvdGlhdGVkIGJldHdlZW4gdGhlIGNs aWVudCBhbmQgdGhlIHNlcnZlciBlYXJseSBpbiB0aGUKICAgICAgdHJhbnNmZXIgc2VxdWVuY2Us IGFjY29yZGluZyB0byBydWxlcyBnaXZlbiBiZWxvdy4gVGhlcmVhZnRlciwKICAgICAgYWxsIGJs b2NrcyBpbiB0aGUgdHJhbnNmZXIgc2VxdWVuY2UgTVVTVCB1c2UgdGhlIHNhbWUgU1pYIHZhbHVl LgoKICAgbyAgSW4gdGhlIHJlc3BvbnNlIGZvciBhIFBVVCBvciBQT1NULCB0aGUgQmxvY2sgT3B0 aW9uIGluZGljYXRlcyB3aGF0CiAgICAgIGJsb2NrIG51bWJlciBpcyBiZWluZyBhY2tub3dsZWRn ZWQuICBJZiB0aGUgTSBiaXQgaXMgc2V0IGluIHRoZSAKICAgICAgcmVzcG9uc2UgaXQgaW5kaWNh dGVzIHRoYXQgdGhpcyByZXNwb25zZSBkb2VzIG5vdCBjYXJyeSB0aGUgZmluYWwKICAgICAgcmVz cG9uc2UgCiAgICAgIHtkb2VzICJmaW5hbCByZXNwb25zZSIgaGVyZSBtZWFuICJyZXNwb25zZSBj b2RlIiBvciBzb21ldGhpbmcgZWxzZT8KICAgICAgQ29hcC0wNSA1LjguMiBhbmQgNS44LjMgc3Vn Z2VzdHMgYSBQVVQgYW5kIFBPU1QgcmVzcG9uc2UgaXMgYSAKICAgICAgcmVzcG9uc2UgY29kZSBh bmQgcG9zc2libHkgc29tZSBMb2NhdGlvbi1QYXRoIE9wdGlvbnMgYW5kL29yIGEgCiAgICAgIExv Y2F0aW9uLVF1ZXJ5IE9wdGlvbi4gfSAKICAgICAgdG8gdGhlIHJlcXVlc3QgaW4gdGhpcyBzZXF1 ZW5jZSBvZiBibG9jay0KICAgICAgd2lzZSB0cmFuc2ZlcnM7IHRoaXMgY2FuIG9jY3VyIHdoZW4g dGhlIE0gYml0IHdhcyBzZXQgaW4KICAgICAgdGhlIHJlcXVlc3QgYW5kIHRoZSBzZXJ2ZXIgaW1w bGVtZW50cyBQVVQvUE9TVCBhdG9taWNhbGx5IChpLmUuLAogICAgICBhY3RzIG9ubHkgdXBvbiBy ZWNlcHRpb24gb2YgdGhlIGxhc3QgYmxvY2spLiAgQ29udmVyc2VseSwgaWYgdGhlIE0KICAgICAg Yml0IGlzIHVuc2V0IGluIHRoZSByZXNwb25zZSwgaXQgaW5kaWNhdGVzIHRoZSBibG9jay13aXNl IHJlcXVlc3QgCiAgICAgIGhhcyBiZWVuIHByb2Nlc3NlZCwgYW5kIHRoZSByZXNwb25zZSBjYXJy aWVzIHRoZSBmaW5hbCByZXNwb25zZSAKICAgICAgeyJyZXNwb25zZSBjb2RlIj99CiAgICAgICB0 byB0aGlzIHJlcXVlc3QgKGFuZAogICAgICB0byBhbnkgcHJldmlvdXMgb25lcyB3aXRoIHRoZSBN IGJpdCBzZXQgaW4gdGhpcyBzZXF1ZW5jZSBvZiBibG9jay0KICAgICAgd2lzZSB0cmFuc2ZlcnMp LiAgRmluYWxseSwgdGhlIGJsb2NrIHNpemUgZ2l2ZW4gaW4gdGhlIEJsb2NrCiAgICAgIE9wdGlv biBpbmRpY2F0ZXMgdGhlIGxhcmdlc3QgYmxvY2sgc2l6ZSBwcmVmZXJyZWQgYnkgdGhlIHNlcnZl cgogICAgICBmb3IgdHJhbnNmZXJzIHRvd2FyZCB0aGUgcmVzb3VyY2UuIFRoaXMgTVVTVCB0aGUg c2FtZSBvciBzbWFsbGVyIHRoYW4KICAgICAgdGhlIG9uZSB1c2VkIGluIHRoZSBpbml0aWFsIGV4 Y2hhbmdlOyB0aGUgY2xpZW50IFNIT1VMRCB1c2UgdGhpcwogICAgICBibG9jayBzaXplIG9yIGEg c21hbGxlciBvbmUgaW4gYWxsIGZ1cnRoZXIgUFVUL1BPU1QgcmVxdWVzdHMgaW4KICAgICAgdGhl IHRyYW5zZmVyIHNlcXVlbmNlLgoKMi4yLiAgVXNpbmcgdGhlIEJsb2NrIE9wdGlvbgoKICAgVXNp bmcgdGhlIEJsb2NrIE9wdGlvbiwgYSBzaW5nbGUgUkVTVCBvcGVyYXRpb24gY2FuIGJlIHNwbGl0 IGludG8KICAgbXVsdGlwbGUgQ29BUCBtZXNzYWdlIGV4Y2hhbmdlcy4gIEVhY2ggb2YgdGhlc2Ug bWVzc2FnZSBleGNoYW5nZXMKICAgdXNlcyB0aGVpciBvd24gQ29BUCBNZXNzYWdlIElELgoKICAg V2hlbiBhIEdFVCBpcyBhbnN3ZXJlZCB3aXRoIGEgcmVzcG9uc2UgY2FycnlpbmcgYSBCbG9jayBP cHRpb24gd2l0aAogICB0aGUgTSBiaXQgc2V0LCB0aGUgcmVxdWVzdGVyIG1heSByZXRyaWV2ZSBh ZGRpdGlvbmFsIGJsb2NrcyBvZiB0aGUKICAgcmVzb3VyY2UgcmVwcmVzZW50YXRpb24gYnkgc2Vu ZGluZyByZXF1ZXN0cyB3aXRoIGEgQmxvY2sgT3B0aW9uCiAgIGdpdmluZyB0aGUgYmxvY2sgbnVt YmVyIGRlc2lyZWQuICBJbiBzdWNoIGEgQmxvY2sgT3B0aW9uLCB0aGUgTSBiaXQKICAgTVVTVCBi ZSBzZW50IGFzIHplcm8gYW5kIGlnbm9yZWQgb24gcmVjZXB0aW9uLiAKICAgCiAgIHtJcyB0aGUg bGFzdCBzZW50ZW5jZSB0YWxraW5nIGFib3V0IHRoZSBHRVQgcmVxdWVzdD8gSXNuJ3QgdGhlIE0g Yml0CiAgIGFsd2F5cyB6ZXJvIGluIGEgR0VUIHJlcXVlc3Q/IFNob3VsZCB0aGUgbGFzdCBzZW50 ZW5jZSBiZSByZXdvcmRlZCAKICAgYXMgIkluIGEgQmxvY2sgT3B0aW9uIGNvbnRhaW5lZCBpbiBh IEdFVCByZXF1ZXN0LCB0aGUgY2xpZW50IE1VU1QgCiAgIHNldCB0aGUgTSBiaXQgdG8gemVybyBh bmQgdGhlIHNlcnZlciBNVVNUIGlnbm9yZSB0aGUgTSBiaXQuIn0KCiAgIFRvIGluZmx1ZW5jZSB0 aGUgYmxvY2sgc2l6ZSB1c2VkIGluIHJlc3BvbnNlIHRvIGEgR0VUIHJlcXVlc3QsIHRoZQogICBy ZXF1ZXN0ZXIgdXNlcyB0aGUgQmxvY2sgT3B0aW9uLCBnaXZpbmcgdGhlIGRlc2lyZWQgc2l6ZSwg YSBibG9jawogICBudW1iZXIgb2YgemVybyBhbmQgYW4gTSBiaXQgb2YgemVyby4gIEEgc2VydmVy IFNIT1VMRCB1c2UgdGhlIGJsb2NrCiAgIHNpemUgaW5kaWNhdGVkIG9yIGEgc21hbGxlciBzaXpl LiBUaGUgc2VydmVyIE1VU1QgTk9UIHVzZSBhIGxhcmdlcgogICBibG9jayBzaXplLiB7cmlnaHQ/ fSBBbnkgZnVydGhlciBibG9jay13aXNlIHJlcXVlc3RzCiAgIGZvciBibG9ja3MgYmV5b25kIHRo ZSBmaXJzdCBvbmUgTVVTVCBpbmRpY2F0ZSB0aGUgc2FtZSBibG9jayBzaXplCiAgIHRoYXQgd2Fz IHVzZWQgYnkgdGhlIHNlcnZlciBpbiB0aGUgcmVzcG9uc2UgZm9yIHRoZSBmaXJzdCByZXF1ZXN0 CiAgIHRoYXQgZ2F2ZSBhIGRlc2lyZWQgc2l6ZSB1c2luZyBhIEJsb2NrIE9wdGlvbi4KCiAgIE9u Y2UgdGhlIEJsb2NrIE9wdGlvbiBpcyB1c2VkIGJ5IHRoZSByZXF1ZXN0ZXIge2NsaWVudD99LCBh bGwgR0VUIHJlcXVlc3RzIGluIGEKICAgc2luZ2xlIHRyYW5zZmVyIE1VU1QgdWx0aW1hdGVseSB1 c2UgdGhlIHNhbWUgc2l6ZSwgZXhjZXB0IHRoYXQgdGhlcmUKICAgbWF5IG5vdCBiZSBlbm91Z2gg Y29udGVudCB0byBmaWxsIHRoZSBsYXN0IGJsb2NrICh0aGUgb25lIHJldHVybmVkCgoKClNoZWxi eSAmIEJvcm1hbm4gICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMTUsIDIwMTEgICAgICAgICAgICAg ICBbUGFnZSA3XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgQmxvY2t3aXNlIHRyYW5zZmVycyBp biBDb0FQICAgICAgICAgICAgTWFyY2ggMjAxMQoKCiAgIHdpdGggdGhlIE0gYml0IG5vdCBzZXQp LiAgKE5vdGUgdGhhdCB0aGUgY2xpZW50IG1heSBzdGFydCB1c2luZyB0aGUKICAgQmxvY2sgT3B0 aW9uIGluIGEgc2Vjb25kIHJlcXVlc3QgYWZ0ZXIgYSBmaXJzdCByZXF1ZXN0IHdpdGhvdXQgYQog ICBCbG9jayBPcHRpb24gcmVzdWx0ZWQgaW4gYSBCbG9jayBPcHRpb24gaW4gdGhlIHJlc3BvbnNl LikKICAgCiAgIHtTaG91bGQgdGhpcyBiZSAiTm90ZSB0aGF0IHRoZSBjbGllbnQgTVVTVCBzdGFy dCB1c2luZy4uLiBvciBbc29tZSB0ZXh0IHRvCiAgIGRlc2NyaWJlIGZsYWdnaW5nIGFuIGVycm9y XSI/IFByZXN1bWFibHkgaWYgdGhlIGNsaWVudCBkb2VzIGEgR0VUIAogICB3aXRob3V0IGEgQmxv Y2sgT3B0aW9uLCBhbmQgcmVjZWl2ZXMgYSByZXNwb25zZSBjb250YWluaW5nIGEgQmxvY2sgCiAg IE9wdGlvbiwgYW5kIGRvZXMgbm90IHJlY29nbmlzZSB0aGlzLCB0aGVuIGFuIGVycm9yIGhhcyBv Y2N1cmVkIGFuZCAKICAgbXVzdCBiZSBkZWFsdCB3aXRoLn0KICAgCiAgICAgVGhlIHNlcnZlcgog ICBTSE9VTEQgdXNlIHRoZSBibG9jayBzaXplIGluZGljYXRlZCBpbiB0aGUgcmVxdWVzdCBvcHRp b24gb3IgYQogICBzbWFsbGVyIHNpemUsIGJ1dCB0aGUgcmVxdWVzdGVyIE1VU1QgdGFrZSBub3Rl IG9mIHRoZSBhY3R1YWwgYmxvY2sKICAgc2l6ZSB1c2VkIGluIHRoZSByZXNwb25zZSBpdCByZWNl aXZlcyB0byBpdHMgaW5pdGlhbCBHRVQgYW5kIHByb2NlZWQKICAgdG8gdXNlIGl0IGluIHN1YnNl cXVlbnQgR0VUcy4gVGhlIHNlcnZlciBiZWhhdmlvciBNVVNUIGVuc3VyZSB0aGF0CiAgIHRoaXMg Y2xpZW50IGJlaGF2aW9yIHJlc3VsdHMgaW4gdGhlIHNhbWUgYmxvY2sgc2l6ZSBmb3IgYWxsIHJl c3BvbnNlcwogICBpbiBhIHNlcXVlbmNlIChleGNlcHQgZm9yIHRoZSBsYXN0IG9uZSB3aXRoIHRo ZSBNIGJpdCBub3Qgc2V0LCBhbmQKICAgcG9zc2libHkgdGhlIGZpcnN0IG9uZSBpZiB0aGUgaW5p dGlhbCByZXF1ZXN0IGRpZCBub3QgY29udGFpbiBhIEJsb2NrCiAgIG9wdGlvbikuCgogICBCbG9j ay13aXNlIHRyYW5zZmVycyBjYW4gYmUgdXNlZCB0byBHRVQgcmVzb3VyY2UgcmVwcmVzZW50YXRp b25zCiAgIHdoaWNoIGFyZSBlbnRpcmVseSBzdGF0aWMgKG5vdCBjaGFuZ2luZyBvdmVyIHRpbWUg YXQgYWxsLCBzdWNoIGFzCiAgIGluIGEgc2NoZW1hIGRlc2NyaWJpbmcgYSBkZXZpY2UpLiBCbG9j ay13aXNlIHRyYW5zZmVycyBjYW4gYWxzbyBiZSAKICAgdXNlZCB0byBHRVQgZHluYW1pY2FsbHkg Y2hhbmdpbmcKICAgcmVzb3VyY2VzLiAgSW4gdGhlIGxhdHRlciBjYXNlLCB0aGUgQmxvY2sgT3B0 aW9uIFNIT1VMRCBiZSB1c2VkIGluCiAgIGNvbmp1bmN0aW9uIHdpdGggdGhlIEVUYWcgb3B0aW9u LCB0byBlbnN1cmUgdGhhdCB0aGUgYmxvY2tzIGJlaW5nCiAgIHJlYXNzZW1ibGVkIGJ5IHRoZSBj bGllbnQgYXJlIGZyb20gdGhlIHNhbWUgdmVyc2lvbiBvZiB0aGUgcmVwcmVzZW50YXRpb24uCiAg IAogICB7UHJlc3VtYWJseSBpdCBpcyB0aGUgc2VydmVyIHRoYXQgcmV0dXJucyB0aGUgRVRhZyBv cHRpb24uIElmIHNvLCBjYW4KICAgd2UgYmUgZXhwbGljaXQgYWJvdXQgdGhpcz8gT3IgY2FuIGEg Y2xpZW50IGluY2x1ZGUgRVRhZyBvcHRpb24gaW4gYSBHRVQgCiAgIHJlcXVlc3Q/IEl0IGxvb2tz IGxpa2UgaXQgaXMgYWxsb3dlZCB0byBhcyBwYXJ0IG9mIGEgY2FjaGUgdmFsaWRhdGlvbgogICBw cm9jZXNzLiBJZiBhIGNsaWVudCBnZXRzIGJhY2sgYW4gRVRhZyBmcm9tIGEgc2VydmVyIGluIHRo ZSBzZXJ2ZXIncyAKICAgZmlyc3QgR0VUIHJlc3BvbnNlLCBkb2VzIHRoZSBjbGllbnQgaGF2ZSB0 byBpbmNsdWRlIHRoZSBFVGFnIG9wdGlvbiBpbgogICBpdHMgc3Vic2VxdWVudCByZXF1ZXN0cz8g T3IgZG9lcyBpdCBkbyBtb3JlIHJlcXVlc3RzIHdpdGhvdXQgdGhlIEVUYWcKICAgb3B0aW9uIGFu ZCBqdXN0IGNoZWNrIHRoZSBFVGFnIG9wdGlvbnMgaW4gdGhlIEdFVCByZXNwb25zZXMgYXJlIHRo ZSBzYW1lPwogICBJIHdlbnQgdG8gQ29BUC0wNSBmb3IgZXhhbXBsZXMsIGJ1dCBmaW5kIG5vIGV4 YW1wbGVzIG9mIHRoZSB1c2Ugb2YgRVRhZyAKICAgaW4gdGhlIEV4YW1wbGVzIGFwcGVuZGl4Ln0K ICAgCiAgICAgV2hlbgogICByZWFzc2VtYmxpbmcgdGhlIHJlcHJlc2VudGF0aW9uIGZyb20gdGhl IGJsb2NrcyBiZWluZyBleGNoYW5nZWQsIHRoZQogICBjbGllbnQgTVVTVCBjb21wYXJlIEVUYWcg b3B0aW9ucy4gIElmIHRoZSBFVGFnIG9wdGlvbnMgZG8gbm90CiAgIG1hdGNoIGluIGEgR0VUIHRy YW5zZmVyLCB0aGUgY2xpZW50IGhhcyB0aGUgb3B0aW9uIG9mIGF0dGVtcHRpbmcKICAgdG8gcmV0 cmlldmUgZnJlc2ggdmFsdWVzIGZvciB0aGUgYmxvY2tzIGl0IHJldHJpZXZlZCBmaXJzdC4KICAg CiAgIHtJcyB0aGlzIHNheWluZyB0aGF0IGlmIGEgY2xpZW50IHJlY2VpdmVzIGZvdXIgYmxvY2tz IDAsIDEsIDIgYW5kIDMgCiAgIHdpdGggRVRhZ3MgT2xkLCBPbGQsIE5ldywgTmV3IGl0IGNhbiB0 aGVuIGdvIGJhY2sgYW5kIHJlcXVlc3QganVzdCAKICAgYmxvY2tzIDAgYW5kIDEsIGFuZCBjaGVj ayB0aGF0IHRoZXNlIG5vdyBoYXZlIEVUYWdzIE5ldywgTmV3PyBDYW4gCiAgIGl0IGFsd2F5cyBh c3N1bWUgdGhhdCBhIGhpZ2hlci1udW1iZXIgYmxvY2sgZnJvbSB0aGUgc2VydmVyIHdpbGwgCiAg IG5ldmVyIGJlIG9sZGVyIHRoYW4gYSBsb3dlci1udW1iZXIgYmxvY2s/IGkuZS4gd2hhdCBoYXBw ZW5zIGlmIHRoZSAKICAgc2VydmVyIGRlbGl2ZXJzIGJsb2NrcyB3aXRoIEVUYWdzIE5ldywgTmV3 LCBPbGQsIE9sZCBhcyBpdCB1cGRhdGVzIAogICBpdHMgZHluYW1pYyByZXNvdXJjZT8gT3IgT2xk LCBOZXcsIE9sZCwgTmV3PyBJbiBnZW5lcmFsLCB0aGUgY2xpZW50IAogICB3b24ndCBiZSBhYmxl IHRvIHRlbGwgd2hpY2ggRVRhZyBjb3JyZXNwb25kcyB0byB0aGUgbmV3ZXIgdmFsdWVzLCAKICAg c28gd29uJ3Qga25vdyB3aGljaCBibG9ja3MgdG8gcmVxdWVzdCBhZ2Fpbi4gSSBzdXNwZWN0IHRo YXQgaW4gCiAgIHByYWN0aXNlIHRoZSBjbGllbnQgd2lsbCBoYXZlIHRvIGtlZXAgcmVhZGluZyBh bGwgdGhlIGJsb2NrcyB1bnRpbCBpdCAKICAgZ2V0cyBjb25zaXN0ZW50IEVUYWdzLiBXaGF0IGRv IHlvdSB0aGluaz99CiAgIAogICAgIFRvCiAgIG1pbmltaXplIHRoZSByZXN1bHRpbmcgaW5lZmZp Y2llbmN5LCB0aGUgc2VydmVyIE1BWSBjYWNoZSB0aGUgY3VycmVudAogICB2YWx1ZSBvZiBhIHJl cHJlc2VudGF0aW9uIGZvciBhbiBvbmdvaW5nIHNlcXVlbmNlIG9mIHJlcXVlc3RzLCBidXQKICAg dGhlcmUgaXMgbm8gcmVxdWlyZW1lbnQgZm9yIHRoZSBzZXJ2ZXIgdG8gZXN0YWJsaXNoIGFueSBz dGF0ZS4gIFRoZQogICBjbGllbnQgTUFZIGZhY2lsaXRhdGUgaWRlbnRpZnlpbmcgdGhlIHNlcXVl bmNlIGJ5IHVzaW5nIHRoZSBUb2tlbgogICBvcHRpb24gd2l0aCBhIG5vbi1kZWZhdWx0IHZhbHVl LgogICAKICAge0kgYW0gY29uZnVzZWQgaGVyZSAtIHRoaXMgaXMgdGhlIGZpcnN0IHRpbWUgdGhl IFRva2VuIG9wdGlvbiBoYXMgYmVlbiAKICAgbWVudGlvbmVkLCBhbmQgaXQgaXMgYmVpbmcgbWVu dGlvbmVkIGluIHRoZSBjb250ZXh0IG9mIHJlYWRpbmcgYSBkeW5hbWljIAogICByZXNvdXJjZS4g SG93IGRvZXMgYSBUb2tlbiBoZWxwIHRoZSBjbGllbnQgZGV0ZXJtaW5lIHdoZXRoZXIgYWxsIAog ICByZXNwb25zZSBibG9ja3MgYXJlIG9mIHRoZSBzYW1lIGFnZT99CgogICBJbiBhIFBVVCBvciBQ T1NUIHRyYW5zZmVyLCB0aGUgQmxvY2sgT3B0aW9uIHJlZmVycyB0byB0aGUgYm9keSBpbiB0aGUK ICAgcmVxdWVzdCwgaS5lLiwgdGhlcmUgaXMgbm8gd2F5IHRvIHBlcmZvcm0gYSBibG9jay13aXNl IHJldHJpZXZhbCBvZgogICB0aGUgYm9keSBvZiB0aGUgcmVzcG9uc2UuICBTZXJ2ZXJzIHRoYXQg ZG8gbmVlZCB0byBzdXBwbHkgbGFyZ2UKICAgYm9kaWVzIGluIHJlc3BvbnNlIHRvIFBVVC9QT1NU IFNIT1VMRCB0aGVyZWZvcmUgYmUgZW1wbG95aW5nCiAgIG1lY2hhbmlzbXMgc3VjaCBhcyBwcm92 aWRpbmcgYSBsb2NhdGlvbiBmb3IgYSByZXNvdXJjZSB0aGF0IGNhbiBiZQogICB1c2VkIGluIGEg R0VUIHRvIG9idGFpbiB0aGF0IGluZm9ybWF0aW9uLgoKICAgSW4gYSBQVVQgb3IgUE9TVCB0cmFu c2ZlciByZXNwb25zZSwgdGhlIGJsb2NrIHNpemUgZ2l2ZW4gaW4gdGhlIEJsb2NrCiAgIG9wdGlv biBpbmRpY2F0ZXMgdGhlIGJsb2NrIHNpemUgcHJlZmVyZW5jZSBvZiB0aGUgc2VydmVyIGZvciB0 aGlzCiAgIHJlc291cmNlLiAgT2J2aW91c2x5LCBhdCB0aGlzIHBvaW50IHRoZSBmaXJzdCBibG9j ayBoYXMgYWxyZWFkeSBiZWVuCiAgIHRyYW5zZmVycmVkIHdpdGhvdXQgYmVuZWZpdCBvZiB0aGlz IGtub3dsZWRnZS4gIFN0aWxsLCB0aGUgY2xpZW50CiAgIFNIT1VMRCBoZWVkIHRoZSBwcmVmZXJl bmNlIGFuZCB1c2UgdGhlIGJsb2NrIHNpemUgcHJlZmVycmVkIGJ5IHRoZQogICBzZXJ2ZXIgb3Ig YSBzbWFsbGVyIG9uZS4gIE5vdGUgdGhhdCBhbnkgcmVkdWN0aW9uIGluIHRoZSBibG9jayBzaXpl CiAgIG1heSBtZWFuIHRoYXQgdGhlIHNlY29uZCByZXF1ZXN0IHN0YXJ0cyB3aXRoIGEgYmxvY2sg bnVtYmVyIGxhcmdlcgogICB0aGFuIG9uZSwgYXMgdGhlIGZpcnN0IHJlcXVlc3QgYWxyZWFkeSB0 cmFuc2ZlcnJlZCBtdWx0aXBsZSBibG9ja3MgYXMKICAgY291bnRlZCBpbiB0aGUgc21hbGxlciBz aXplLgoKICAgSW4gYSBQVVQgb3IgUE9TVCB0cmFuc2ZlciB0aGF0IGlzIGludGVuZGVkIHRvIGJl IGltcGxlbWVudGVkIGluIGFuCiAgIGF0b21pYyBmYXNoaW9uIGF0IHRoZSBzZXJ2ZXIsIHRoZSBh Y3R1YWwgY3JlYXRpb24vcmVwbGFjZW1lbnQgdGFrZXMKICAgcGxhY2UgYXQgdGhlIHRpbWUgdGhl IGZpbmFsIGJsb2NrLCBpLmUuIGEgYmxvY2sgd2l0aCB0aGUgTSBiaXQgdW5zZXQsCgoKClNoZWxi eSAmIEJvcm1hbm4gICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMTUsIDIwMTEgICAgICAgICAgICAg ICBbUGFnZSA4XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgQmxvY2t3aXNlIHRyYW5zZmVycyBp biBDb0FQICAgICAgICAgICAgTWFyY2ggMjAxMQoKCiAgIGlzIHJlY2VpdmVkLiAgSWYgbm90IGFs bCBwcmV2aW91cyBibG9ja3MgYXJlIGF2YWlsYWJsZSBhdCB0aGUgc2VydmVyCiAgIGF0IHRoaXMg dGltZSwgdGhlIHRyYW5zZmVyIGZhaWxzIGFuZCBlcnJvciBjb2RlIDQuMDggKFJlcXVlc3QgRW50 aXR5CiAgIEluY29tcGxldGUpIE1VU1QgYmUgcmV0dXJuZWQuICBUaGUgZXJyb3IgY29kZSA0LjEz IChSZXF1ZXN0IEVudGl0eQogICBUb28gTGFyZ2UpIGNhbiBiZSByZXR1cm5lZCBhdCBhbnkgdGlt ZSBieSBhIHNlcnZlciB0aGF0IGRvZXMgbm90CiAgIGN1cnJlbnRseSBoYXZlIHRoZSByZXNvdXJj ZXMgdG8gc3RvcmUgYmxvY2tzIGZvciBhIGJsb2NrLXdpc2UgUFVUIG9yCiAgIFBPU1QgdHJhbnNm ZXIgdGhhdCBpdCB3b3VsZCBpbnRlbmQgdG8gaW1wbGVtZW50IGluIGFuIGF0b21pYyBmYXNoaW9u LgoKICAgSWYgbXVsdGlwbGUgY29uY3VycmVudGx5IHByb2NlZWRpbmcgYmxvY2std2lzZSBQVVQg b3IgUE9TVCBvcGVyYXRpb25zCiAgIGFyZSBwb3NzaWJsZSwgdGhlIHJlcXVlc3RlciBTSE9VTEQg dXNlIHRoZSBUb2tlbiBvcHRpb24gdG8gY2xlYXJseQogICBzZXBhcmF0ZSB0aGUgZGlmZmVyZW50 IHNlcXVlbmNlcy4gIEluIHRoaXMgY2FzZSwgd2hlbiByZWFzc2VtYmxpbmcKICAgdGhlIHJlcHJl c2VudGF0aW9uIGZyb20gdGhlIGJsb2NrcyBiZWluZyBleGNoYW5nZWQgdG8gZW5hYmxlIGF0b21p YwogICBwcm9jZXNzaW5nLCB0aGUgcmVhc3NlbWJsZXIgTVVTVCBjb21wYXJlIGFueSBUb2tlbiBv cHRpb25zIHByZXNlbnQKICAgKGFuZCwgYXMgdXN1YWwsIHRha2luZyBhbiBhYnNlbnQgVG9rZW4g b3B0aW9uIHRvIGRlZmF1bHQgdG8gdGhlIGVtcHR5CiAgIFRva2VuKS4gIElmIGF0b21pYyBwcm9j ZXNzaW5nIGlzIG5vdCBkZXNpcmVkLCB0aGVyZSBpcyBubyBuZWVkIHRvCiAgIHByb2Nlc3MgdGhl IFRva2VuIG9wdGlvbiAoYnV0IGl0IGlzIHN0aWxsIHJldHVybmVkIGluIHRoZSByZXNwb25zZSBh cwogICB1c3VhbCkuCiAgIAogICB7SXMgaXQgY2xlYXIgd2hhdCBzaG91bGQgaGFwcGVuIGlmIHRo ZSBjbGllbnQgb3Igc2VydmVyIHNlbmRzIGEgQmxvY2sKICAgb3B0aW9uIGFuZCB0aGUgb3RoZXIg bm9kZSBpcyB1bmFibGUgdG8gcHJvY2VzcyBpdD8gY29hcC0wNSA1LjQuMSBzZWVtcwogICB0byBz cGVjaWZ5IHRoaXMuIFNob3VsZCB0aGlzIGRvY3VtZW50IHJlcGVhdCB0aGF0IGluZm9ybWF0aW9u PyBvcgogICByZWZlciByZWFkZXJzIHRvIGNvYXAtMDUgNS40LjE/fQogICAKICAge1NpbmNlIHRo ZSBibG9jayBtZWNoYW5pbSBoZXJlIGFwcGxpZXMgb25seSB0byBwYXlsb2FkcyBhbmQgbm90CiAg IHRoZSBoZWFkZXIgYW5kIG9wdGlvbiBmaWVsZHMsIGFuZCBzaW5jZSBvcHRpb24gdmFsdWVzIGNh biBiZSBxdWl0ZSBsb25nCiAgICh1cCB0byAyNzAgYnl0ZXMpIGl0IGlzIHBvc3NpYmxlIHRoYXQg Y2VydGFpbiBtZXNzYWdlcyBjb3VsZCBub3QgYmUgCiAgIHNwbGl0IGludG8gcGljZXMgdGhhdCB3 b3VsZCBmaXQgaW50byBsaW5rLWxheWVyIHBhY2tldHMsIGJlY2F1c2UKICAgb2YgdmVyYm9zZSBv cHRpb25zLiBJcyBpdCB3b3J0aCBtYWtpbmcgdGhpcyBwb2ludCBoZXJlP30KCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpTaGVsYnkgJiBCb3JtYW5uICAgICAgIEV4cGlyZXMgU2Vw dGVtYmVyIDE1LCAyMDExICAgICAgICAgICAgICAgW1BhZ2UgOV0KDApJbnRlcm5ldC1EcmFmdCAg ICAgICAgIEJsb2Nrd2lzZSB0cmFuc2ZlcnMgaW4gQ29BUCAgICAgICAgICAgIE1hcmNoIDIwMTEK CgozLiAgRXhhbXBsZXMKCiAgIFRoaXMgc2VjdGlvbiBnaXZlcyBhIG51bWJlciBvZiBzaG9ydCBl eGFtcGxlcyB3aXRoIG1lc3NhZ2UgZmxvd3MgZm9yCiAgIGEgYmxvY2std2lzZSBHRVQsIGFuZCBm b3IgYSBQVVQgb3IgUE9TVC4gIFRoZXNlIGV4YW1wbGVzIGRlbW9uc3RyYXRlCiAgIHRoZSBiYXNp YyBvcGVyYXRpb24sIHRoZSBvcGVyYXRpb24gaW4gdGhlIHByZXNlbmNlIG9mCiAgIHJldHJhbnNt aXNzaW9ucywgYW5kIGV4YW1wbGVzIGZvciB0aGUgb3BlcmF0aW9uIG9mIHRoZSBibG9jayBzaXpl CiAgIG5lZ290aWF0aW9uLgoKICAgSW4gYWxsIHRoZXNlIGV4YW1wbGVzLCBhIEJsb2NrIE9wdGlv biBpcyBzaG93biBpbiBhIGRlY29tcG9zZWQgd2F5CiAgIHNlcGFyYXRpbmcgdGhlIGJsb2NrIG51 bWJlciAoTlVNKSwgbW9yZSBiaXQgKE0pLCBhbmQgYmxvY2sgc2l6ZQogICBleHBvbmVudCAoMl4o U1pYKzQpKSBieSBzbGFzaGVzLiAgRS5nLiwgYSBCbG9jayBPcHRpb24gdmFsdWUgb2YgMzMKICAg d291bGQgYmUgc2hvd24gYXMgMi8wLzMyLCBvciBhIEJsb2NrIE9wdGlvbiB2YWx1ZSBvZiA1OSB3 b3VsZCBiZQogICBzaG93biBhcyAzLzEvMTI4LgoKICAgVGhlIGZpcnN0IGV4YW1wbGUgKEZpZ3Vy ZSAyKSBzaG93cyBhIEdFVCByZXF1ZXN0IHRoYXQgaXMgc3BsaXQgaW50bwogICB0aHJlZSBibG9j a3MuICBUaGUgc2VydmVyIHByb3Bvc2VzIGEgYmxvY2sgc2l6ZSBvZiAxMjgsIGFuZCB0aGUKICAg Y2xpZW50IGFncmVlcy4gIFRoZSBmaXJzdCB0d28gQUNLcyBjb250YWluIDEyOCBieXRlcyBvZiBw YXlsb2FkIGVhY2gsCiAgIGFuZCB0aGlyZCBBQ0sgY29udGFpbnMgYmV0d2VlbiAxIGFuZCAxMjgg Ynl0ZXMuCgogICBDTElFTlQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIFNFUlZFUgogICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgIHwgQ09OIFtNSUQ9MTIzNF0sIEdFVCwg L3N0YXR1cyAgICAgICAgICAgICAgICAgICAgIC0tLS0tLT4gfAogICAgIHwgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgIHwgPC0t LS0tLSAgIEFDSyBbTUlEPTEyMzRdLCAyLjAwIE9LLCAwLzEvMTI4ICAgICAgICAgICAgICAgfAog ICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfAogICAgIHwgQ09OIFtNSUQ9MTIzNV0sIEdFVCwgL3N0YXR1cywgMS8wLzEyOCAgICAg ICAgICAgIC0tLS0tLT4gfAogICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgIHwgPC0tLS0tLSAgIEFDSyBbTUlEPTEyMzVd LCAyLjAwIE9LLCAxLzEvMTI4ICAgICAgICAgICAgICAgfAogICAgIHwgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgIHwgQ09OIFtN SUQ9MTIzNl0sIEdFVCwgL3N0YXR1cywgMi8wLzEyOCAgICAgICAgICAgIC0tLS0tLT4gfAogICAg IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfAogICAgIHwgPC0tLS0tLSAgIEFDSyBbTUlEPTEyMzZdLCAyLjAwIE9LLCAyLzAvMTI4ICAg ICAgICAgICAgICAgfAoKICAgICAgICAgICAgICAgICAgICAgIEZpZ3VyZSAyOiBTaW1wbGUgYmxv Y2t3aXNlIEdFVAoKICAgSW4gdGhlIHNlY29uZCBleGFtcGxlIChGaWd1cmUgMyksIHRoZSBjbGll bnQgYW50aWNpcGF0ZXMgdGhlCiAgIGJsb2Nrd2lzZSB0cmFuc2ZlciAoZS5nLiwgYmVjYXVzZSBv ZiBhIHNpemUgaW5kaWNhdGlvbiBpbiB0aGUgbGluay0KICAgZm9ybWF0IGRlc2NyaXB0aW9uKSBh bmQgc2VuZHMgYSBzaXplIHByb3Bvc2FsLiAgQWxsIEFDSyBtZXNzYWdlcwogICBleGNlcHQgZm9y IHRoZSBsYXN0IGNhcnJ5IDY0IGJ5dGVzIG9mIHBheWxvYWQ7IHRoZSBsYXN0IG9uZSBjYXJyaWVz CiAgIGJldHdlZW4gMSBhbmQgNjQgYnl0ZXMuCgoKCgoKCgoKCgoKU2hlbGJ5ICYgQm9ybWFubiAg ICAgICBFeHBpcmVzIFNlcHRlbWJlciAxNSwgMjAxMSAgICAgICAgICAgICAgW1BhZ2UgMTBdCgwK SW50ZXJuZXQtRHJhZnQgICAgICAgICBCbG9ja3dpc2UgdHJhbnNmZXJzIGluIENvQVAgICAgICAg ICAgICBNYXJjaCAyMDExCgoKICAgQ0xJRU5UICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBTRVJWRVIKICAgICB8ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICB8IENPTiBbTUlEPTEy MzRdLCBHRVQsIC9zdGF0dXMsIDAvMC82NCAgICAgICAgICAgICAtLS0tLS0+IHwKICAgICB8ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwK ICAgICB8IDwtLS0tLS0gICBBQ0sgW01JRD0xMjM0XSwgMi4wMCBPSywgMC8xLzY0ICAgICAgICAg ICAgICAgIHwKICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwKICAgICB8IENPTiBbTUlEPTEyMzVdLCBHRVQsIC9zdGF0dXMsIDEv MC82NCAgICAgICAgICAgICAtLS0tLS0+IHwKICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICB8IDwtLS0tLS0gICBBQ0sg W01JRD0xMjM1XSwgMi4wMCBPSywgMS8xLzY0ICAgICAgICAgICAgICAgIHwKICAgICA6ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDoKICAg ICA6ICAgICAgICAgICAgICAgICAgICAgICAgICAuLi4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgIDoKICAgICA6ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIDoKICAgICB8IENPTiBbTUlEPTEyMzhdLCBHRVQsIC9zdGF0dXMsIDQvMC82 NCAgICAgICAgICAgICAtLS0tLS0+IHwKICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICB8IDwtLS0tLS0gICBBQ0sgW01J RD0xMjM4XSwgMi4wMCBPSywgNC8xLzY0ICAgICAgICAgICAgICAgIHwKICAgICB8ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICB8 IENPTiBbTUlEPTEyMzldLCBHRVQsIC9zdGF0dXMsIDUvMC82NCAgICAgICAgICAgICAtLS0tLS0+ IHwKICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwKICAgICB8IDwtLS0tLS0gICBBQ0sgW01JRD0xMjM5XSwgMi4wMCBPSywgNS8w LzY0ICAgICAgICAgICAgICAgIHwKCiAgICAgICAgICAgICAgRmlndXJlIDM6IEJsb2Nrd2lzZSBH RVQgd2l0aCBlYXJseSBuZWdvdGlhdGlvbgoKICAgSW4gdGhlIHRoaXJkIGV4YW1wbGUgKEZpZ3Vy ZSA0KSwgdGhlIGNsaWVudCBpcyBzdXJwcmlzZWQgYnkgdGhlIG5lZWQKICAgZm9yIGEgYmxvY2t3 aXNlIHRyYW5zZmVyLCBhbmQgdW5oYXBweSB3aXRoIHRoZSBzaXplIGNob3NlbgogICB1bmlsYXRl cmFsbHkgYnkgdGhlIHNlcnZlci4gIEFzIGl0IGRpZCBub3Qgc2VuZCBhIHNpemUgcHJvcG9zYWwK ICAgaW5pdGlhbGx5LCB0aGUgbmVnb3RpYXRpb24gb25seSBpbmZsdWVuY2VzIHRoZSBzaXplIGZy b20gdGhlIHNlY29uZAogICBtZXNzYWdlIGV4Y2hhbmdlLiAgU2luY2UgdGhlIGNsaWVudCBhbHJl YWR5IG9idGFpbmVkIGJvdGggdGhlIGZpcnN0CiAgIGFuZCBzZWNvbmQgNjQtYnl0ZSBibG9jayBp biB0aGUgZmlyc3QgMTI4LWJ5dGUgZXhjaGFuZ2UsIGl0IGdvZXMgb24KICAgcmVxdWVzdGluZyB0 aGUgdGhpcmQgNjQtYnl0ZSBibG9jayAoIjIvMC82NCIpLiAgTm9uZSBvZiB0aGlzIGlzIChvcgog ICBuZWVkcyB0byBiZSkgdW5kZXJzdG9vZCBieSB0aGUgc2VydmVyLCB3aGljaCBzaW1wbHkgcmVz cG9uZHMgdG8gdGhlCiAgIHJlcXVlc3RzIGFzIGl0IGJlc3QgY2FuLgoKCgoKCgoKCgoKCgoKCgoK CgoKClNoZWxieSAmIEJvcm1hbm4gICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMTUsIDIwMTEgICAg ICAgICAgICAgIFtQYWdlIDExXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgQmxvY2t3aXNlIHRy YW5zZmVycyBpbiBDb0FQICAgICAgICAgICAgTWFyY2ggMjAxMQoKCiAgIENMSUVOVCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgU0VSVkVSCiAgICAg fCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8CiAgICAgfCBDT04gW01JRD0xMjM0XSwgR0VULCAvc3RhdHVzICAgICAgICAgICAgICAgICAg ICAgLS0tLS0tPiB8CiAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB8CiAgICAgfCA8LS0tLS0tICAgQUNLIFtNSUQ9MTIzNF0sIDIu MDAgT0ssIDAvMS8xMjggICAgICAgICAgICAgICB8CiAgICAgfCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgfCBDT04gW01JRD0x MjM1XSwgR0VULCAvc3RhdHVzLCAyLzAvNjQgICAgICAgICAgICAgLS0tLS0tPiB8CiAgICAgfCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 CiAgICAgfCA8LS0tLS0tICAgQUNLIFtNSUQ9MTIzNV0sIDIuMDAgT0ssIDIvMS82NCAgICAgICAg ICAgICAgICB8CiAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB8CiAgICAgfCBDT04gW01JRD0xMjM2XSwgR0VULCAvc3RhdHVzLCAz LzAvNjQgICAgICAgICAgICAgLS0tLS0tPiB8CiAgICAgfCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgfCA8LS0tLS0tICAgQUNL IFtNSUQ9MTIzNl0sIDIuMDAgT0ssIDMvMS82NCAgICAgICAgICAgICAgICB8CiAgICAgfCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAg ICAgfCBDT04gW01JRD0xMjM3XSwgR0VULCAvc3RhdHVzLCA0LzAvNjQgICAgICAgICAgICAgLS0t LS0tPiB8CiAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8CiAgICAgfCA8LS0tLS0tICAgQUNLIFtNSUQ9MTIzN10sIDIuMDAgT0ss IDQvMS82NCAgICAgICAgICAgICAgICB8CiAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgfCBDT04gW01JRD0xMjM4XSwg R0VULCAvc3RhdHVzLCA1LzAvNjQgICAgICAgICAgICAgLS0tLS0tPiB8CiAgICAgfCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAg fCA8LS0tLS0tICAgQUNLIFtNSUQ9MTIzOF0sIDIuMDAgT0ssIDUvMC82NCAgICAgICAgICAgICAg ICB8CgogICAgICAgICAgICAgICBGaWd1cmUgNDogQmxvY2t3aXNlIEdFVCB3aXRoIGxhdGUgbmVn b3RpYXRpb24KCiAgIEluIGFsbCB0aGVzZSAoYW5kIHRoZSBmb2xsb3dpbmcpIGNhc2VzLCByZXRy YW5zbWlzc2lvbnMgYXJlIGhhbmRsZWQKICAgYnkgdGhlIENvQVAgbWVzc2FnZSBleGNoYW5nZSBs YXllciwgc28gdGhleSBkb24ndCBpbmZsdWVuY2UgdGhlIGJsb2NrCiAgIG9wZXJhdGlvbnMgKEZp Z3VyZSA1LCBGaWd1cmUgNikuCgogICBDTElFTlQgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIFNFUlZFUgogICAgIHwgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgIHwgQ09OIFtNSUQ9 MTIzNF0sIEdFVCwgL3N0YXR1cyAgICAgICAgICAgICAgICAgICAgIC0tLS0tLT4gfAogICAgIHwg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg fAogICAgIHwgPC0tLS0tLSAgIEFDSyBbTUlEPTEyMzRdLCAyLjAwIE9LLCAwLzEvMTI4ICAgICAg ICAgICAgICAgfAogICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfAogICAgIHwgQ09OIFtNSUQ9MTIzNV0sIEdFLy8vLy8vLy8vLy8v Ly8vLy8vLy8vLy8vLyAgICAgICAgICAgICAgfAogICAgIHwgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgIHwgKHRpbWVvdXQpICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgIHwgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAog ICAgIHwgQ09OIFtNSUQ9MTIzNV0sIEdFVCwgL3N0YXR1cywgMi8wLzY0ICAgICAgICAgICAgIC0t LS0tLT4gfAogICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgfAogICAgIHwgPC0tLS0tLSAgIEFDSyBbTUlEPTEyMzVdLCAyLjAwIE9L LCAyLzEvNjQgICAgICAgICAgICAgICAgfAogICAgIDogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgOgogICAgIDogICAgICAgICAgICAgICAg ICAgICAgICAgIC4uLiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgOgogICAgIDogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgOgogICAg IHwgQ09OIFtNSUQ9MTIzOF0sIEdFVCwgL3N0YXR1cywgNS8wLzY0ICAgICAgICAgICAgIC0tLS0t LT4gfAogICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfAogICAgIHwgPC0tLS0tLSAgIEFDSyBbTUlEPTEyMzhdLCAyLjAwIE9LLCA1 LzAvNjQgICAgICAgICAgICAgICAgfAoKe0NhbiBJIHN1Z2dlc3QgdGhhdCBsb3N0IHBhY2tldHMg YXJlIHNob3duIHRoZSBzYW1lIHdheSBhcyBpbiB0aGUgY29hcC0wNSBleGFtcGxlcy59CgoKU2hl bGJ5ICYgQm9ybWFubiAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAxNSwgMjAxMSAgICAgICAgICAg ICAgW1BhZ2UgMTJdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICBCbG9ja3dpc2UgdHJhbnNmZXJz IGluIENvQVAgICAgICAgICAgICBNYXJjaCAyMDExCgoKICAgICAgICBGaWd1cmUgNTogQmxvY2t3 aXNlIEdFVCB3aXRoIGxhdGUgbmVnb3RpYXRpb24gYW5kIGxvc3QgQ09OCgoKICAgQ0xJRU5UICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTRVJWRVIK ICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwKICAgICB8IENPTiBbTUlEPTEyMzRdLCBHRVQsIC9zdGF0dXMgICAgICAgICAgICAg ICAgICAgICAtLS0tLS0+IHwKICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICB8IDwtLS0tLS0gICBBQ0sgW01JRD0xMjM0 XSwgMi4wMCBPSywgMC8xLzEyOCAgICAgICAgICAgICAgIHwKICAgICB8ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICB8IENPTiBb TUlEPTEyMzVdLCBHRVQsIC9zdGF0dXMsIDIvMC82NCAgICAgICAgICAgICAtLS0tLS0+IHwKICAg ICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwKICAgICB8IC8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vL09LLCAyLzEvNjQg ICAgICAgICAgICAgIHwKICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwKICAgICB8ICh0aW1lb3V0KSAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICB8ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICB8IENPTiBbTUlE PTEyMzVdLCBHRVQsIC9zdGF0dXMsIDIvMC82NCAgICAgICAgICAgICAtLS0tLS0+IHwKICAgICB8 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwKICAgICB8IDwtLS0tLS0gICBBQ0sgW01JRD0xMjM1XSwgMi4wMCBPSywgMi8xLzY0ICAgICAg ICAgICAgICAgIHwKICAgICA6ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIDoKICAgICA6ICAgICAgICAgICAgICAgICAgICAgICAgICAuLi4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDoKICAgICA6ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDoKICAgICB8IENPTiBbTUlEPTEy MzhdLCBHRVQsIC9zdGF0dXMsIDUvMC82NCAgICAgICAgICAgICAtLS0tLS0+IHwKICAgICB8ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwK ICAgICB8IDwtLS0tLS0gICBBQ0sgW01JRD0xMjM4XSwgMi4wMCBPSywgNS8wLzY0ICAgICAgICAg ICAgICAgIHwKCiAgICAgICAgRmlndXJlIDY6IEJsb2Nrd2lzZSBHRVQgd2l0aCBsYXRlIG5lZ290 aWF0aW9uIGFuZCBsb3N0IEFDSwoKICAgVGhlIGZvbGxvd2luZyBleGFtcGxlcyBkZW1vbnN0cmF0 ZSBhIFBVVCBleGNoYW5nZTsgYSBQT1NUIGV4Y2hhbmdlCiAgIGxvb2tzIHRoZSBzYW1lLCB3aXRo IGRpZmZlcmVudCByZXF1aXJlbWVudHMgb24gYXRvbWljaXR5L2lkZW1wb3RlbmNlLgogICBUbyBl bnN1cmUgdGhhdCB0aGUgYmxvY2tzIHJlbGF0ZSB0byB0aGUgc2FtZSB2ZXJzaW9uIG9mIHRoZSBy ZXNvdXJjZQogICByZXByZXNlbnRhdGlvbiBjYXJyaWVkIGluIHRoZSByZXF1ZXN0LCB0aGUgY2xp ZW50IGluIEZpZ3VyZSA3IHNldHMKICAgdGhlIFRva2VuIHRvICJ2MTciIGluIGFsbCByZXF1ZXN0 cy4gIE5vdGUgdGhhdCwgYXMgd2l0aCB0aGUgR0VULCB0aGUKICAgcmVzcG9uc2VzIHRvIHRoZSBy ZXF1ZXN0cyB0aGF0IGhhdmUgYSBtb3JlIGJpdCBpbiB0aGUgcmVxdWVzdCBibG9jawogICBvcHRp b24gYXJlIHByb3Zpc2lvbmFsOyBvbmx5IHRoZSBmaW5hbCByZXNwb25zZSB0ZWxscyB0aGUgY2xp ZW50IHRoYXQKICAgdGhlIFBVVCBzdWNjZWVkZWQuCiAgIAogICB7V2hhdCBkb2VzICJwcm92aXNp b25hbCIgbWVhbiBleGFjdGx5PyBEb2VzIGl0IG1lYW4gdGhhdCB0aGUgY2xpZW50IAogICBzaG91 bGQgaWdub3JlIHRoZSAiMi4wNCBDaGFuZ2VkIiB3aGVuIE09MSwgYW5kIG9ubHkgdGFrZSBub3Qg b2YgCiAgICIyLjA0IENoYW5nZWQgd2hlbiBNPTA/Ii4gSWYgc28sIHByZXN1bWFibHkgdGhlIGNs aWVudCBpZ25vcmVzIGFueSAKICAgMi54eCByZXNwb25zZSBjb2RlcyB3aXRoIE09MS4gUHJlc3Vt YWJseSBpdCBkb2VzIHN0aWxsIGhhdmUgdG8gbG9vayAKICAgb3V0IGZvciBlcnJvciByZXNwb25z ZSBjb2Rlcy4gRG8geW91IG5lZWQgdG8gc3BlY2lmeSB0aGUgY29udGVudHMgb2YgCiAgIHRoZSBN IGJpdCBpZiB0aGUgc2VydmVyIHJlc3BvbmRzIHdpdGggYW4gZXJyb3IgY29kZT99CiAgIAogICB7 SW4gdGhlIGNvYXAtMDUgZXhhbXBsZXMgdGhlIFRva2VuIGlzIGFsd2F5cyBpbiB0aGUgZm9ybSAi VG9rZW46IDB4ODYiCiAgIGNhbiBJIHN1Z2dlc3QgdGhhdCB0aGUgc2FtZSBpcyBkb25lIGhlcmUs IGZvciBjb25zaXN0ZW5jeSBhbmQgY2xhcml0eS4KICAgSW5kZWVkLCB0aGUgbmV3IGV4YW1wbGUg ZmlndXJlIHN0eWxlIGZyb20gY29hcC0wNSBzaG91bGQgYmUgdXNlZCAKICAgaW4gdGhpcyBkb2N1 bWVudCBhcyB3ZWxsLiB9CgoKCgoKCgoKCgoKCgoKCgpTaGVsYnkgJiBCb3JtYW5uICAgICAgIEV4 cGlyZXMgU2VwdGVtYmVyIDE1LCAyMDExICAgICAgICAgICAgICBbUGFnZSAxM10KDApJbnRlcm5l dC1EcmFmdCAgICAgICAgIEJsb2Nrd2lzZSB0cmFuc2ZlcnMgaW4gQ29BUCAgICAgICAgICAgIE1h cmNoIDIwMTEKCgogICBDTElFTlQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFNFUlZFUgogICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgIHwgQ09OIFtNSUQ9MTIzNF0sIFBV VCwgL29wdGlvbnMsIHYxNywgMC8xLzEyOCAgICAgIC0tLS0tLT4gfAogICAgIHwgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgIHwg PC0tLS0tLSAgIEFDSyBbTUlEPTEyMzRdLCAyLjA0IENoYW5nZWQsIDAvMS8xMjggICAgICAgICAg fAogICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfAogICAgIHwgQ09OIFtNSUQ9MTIzNV0sIFBVVCwgL29wdGlvbnMsIHYxNywgMS8x LzEyOCAgICAgIC0tLS0tLT4gfAogICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgIHwgPC0tLS0tLSAgIEFDSyBbTUlEPTEy MzVdLCAyLjA0IENoYW5nZWQsIDEvMS8xMjggICAgICAgICAgfAogICAgIHwgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgIHwgQ09O IFtNSUQ9MTIzNl0sIFBVVCwgL29wdGlvbnMsIHYxNywgMi8wLzEyOCAgICAgIC0tLS0tLT4gfAog ICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfAogICAgIHwgPC0tLS0tLSAgIEFDSyBbTUlEPTEyMzZdLCAyLjA0IENoYW5nZWQsIDIv MC8xMjggICAgICAgICAgfAoKICAgICAgICAgICAgICAgICAgIEZpZ3VyZSA3OiBTaW1wbGUgYXRv bWljIGJsb2Nrd2lzZSBQVVQKCiAgIEEgc3RhdGVsZXNzIHNlcnZlciB0aGF0IHNpbXBseSBidWls ZHMvdXBkYXRlcyB0aGUgcmVzb3VyY2UgaW4gcGxhY2UKICAgKHN0YXRlbGVzc2x5KSBtYXkgaW5k aWNhdGUgdGhpcyBieSBub3Qgc2V0dGluZyB0aGUgbW9yZSBiaXQgaW4gdGhlCiAgIHJlc3BvbnNl IChGaWd1cmUgOCk7IGluIHRoaXMgY2FzZSwgdGhlIHJlc3BvbnNlIGNvZGVzIGFyZSB2YWxpZAog ICBzZXBhcmF0ZWx5IGZvciBlYWNoIGJsb2NrIGJlaW5nIHVwZGF0ZWQuICBUaGlzIGlzIG9mIGNv dXJzZSBvbmx5IGFuCiAgIGFjY2VwdGFibGUgYmVoYXZpb3Igb2YgdGhlIHNlcnZlciBpZiB0aGUg cG90ZW50aWFsIGluY29uc2lzdGVuY3kKICAgcHJlc2VudCBkdXJpbmcgdGhlIHJ1biBvZiB0aGUg bWVzc2FnZSBleGNoYW5nZSBzZXF1ZW5jZSBkb2VzIG5vdCBsZWFkCiAgIHRvIHByb2JsZW1zLCBl LmcuIGJlY2F1c2UgdGhlIHJlc291cmNlIGJlaW5nIGNyZWF0ZWQgb3IgY2hhbmdlZCBpcwogICBu b3QgeWV0IG9yIG5vdCBjdXJyZW50bHkgaW4gdXNlLgoKICAgQ0xJRU5UICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTRVJWRVIKICAgICB8ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAg ICB8IENPTiBbTUlEPTEyMzRdLCBQVVQsIC9vcHRpb25zLCB2MTcsIDAvMS8xMjggICAgICAtLS0t LS0+IHwKICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwKICAgICB8IDwtLS0tLS0gICBBQ0sgW01JRD0xMjM0XSwgMi4wNCBDaGFu Z2VkLCAwLzAvMTI4ICAgICAgICAgIHwKICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICB8IENPTiBbTUlEPTEyMzVdLCBQ VVQsIC9vcHRpb25zLCB2MTcsIDEvMS8xMjggICAgICAtLS0tLS0+IHwKICAgICB8ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICB8 IDwtLS0tLS0gICBBQ0sgW01JRD0xMjM1XSwgMi4wNCBDaGFuZ2VkLCAxLzAvMTI4ICAgICAgICAg IHwKICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwKICAgICB8IENPTiBbTUlEPTEyMzZdLCBQVVQsIC9vcHRpb25zLCB2MTcsIDIv MC8xMjggICAgICAtLS0tLS0+IHwKICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICB8IDwtLS0tLS0gICBBQ0sgW01JRD0x MjM2XSwgMi4wNCBDaGFuZ2VkLCAyLzAvMTI4ICAgICAgICAgIHwKCiAgICAgICAgICAgICAgICAg RmlndXJlIDg6IFNpbXBsZSBzdGF0ZWxlc3MgYmxvY2t3aXNlIFBVVAoKICAgRmluYWxseSwgYSBz ZXJ2ZXIgcmVjZWl2aW5nIGEgYmxvY2t3aXNlIFBVVCBvciBQT1NUIG1heSB3YW50IHRvCiAgIGlu ZGljYXRlIGEgc21hbGxlciBibG9jayBzaXplIHByZWZlcmVuY2UgKEZpZ3VyZSA5KS4gIEluIHRo aXMgY2FzZSwKICAgdGhlIGNsaWVudCBTSE9VTEQgY29udGludWUgd2l0aCBhIHNtYWxsZXIgYmxv Y2sgc2l6ZTsgaWYgaXQgZG9lcywgaXQKICAgTVVTVCBhZGp1c3QgdGhlIGJsb2NrIG51bWJlciB0 byBwcm9wZXJseSBjb3VudCBpbiB0aGF0IHNtYWxsZXIgc2l6ZS4KCgoKCgoKU2hlbGJ5ICYgQm9y bWFubiAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAxNSwgMjAxMSAgICAgICAgICAgICAgW1BhZ2Ug MTRdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICBCbG9ja3dpc2UgdHJhbnNmZXJzIGluIENvQVAg ICAgICAgICAgICBNYXJjaCAyMDExCgoKICAgQ0xJRU5UICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTRVJWRVIKICAgICB8ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICB8IENPTiBb TUlEPTEyMzRdLCBQVVQsIC9vcHRpb25zLCB2MTcsIDAvMS8xMjggICAgICAtLS0tLS0+IHwKICAg ICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwKICAgICB8IDwtLS0tLS0gICBBQ0sgW01JRD0xMjM0XSwgMi4wNCBDaGFuZ2VkLCAwLzEv MzIgICAgICAgICAgIHwKICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwKICAgICB8IENPTiBbTUlEPTEyMzVdLCBQVVQsIC9vcHRp b25zLCB2MTcsIDQvMS8zMiAgICAgICAtLS0tLS0+IHwKICAgICB8ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICB8IDwtLS0tLS0g ICBBQ0sgW01JRD0xMjM1XSwgMi4wNCBDaGFuZ2VkLCA0LzEvMzIgICAgICAgICAgIHwKICAgICB8 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwKICAgICB8IENPTiBbTUlEPTEyMzZdLCBQVVQsIC9vcHRpb25zLCB2MTcsIDUvMS8zMiAgICAg ICAtLS0tLS0+IHwKICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwKICAgICB8IDwtLS0tLS0gICBBQ0sgW01JRD0xMjM1XSwgMi4w NCBDaGFuZ2VkLCA1LzEvMzIgICAgICAgICAgIHwKICAgICB8ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICB8IENPTiBbTUlEPTEy MzddLCBQVVQsIC9vcHRpb25zLCB2MTcsIDYvMC8zMiAgICAgICAtLS0tLS0+IHwKICAgICB8ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwK ICAgICB8IDwtLS0tLS0gICBBQ0sgW01JRD0xMjM2XSwgMi4wNCBDaGFuZ2VkLCA2LzAvMzIgICAg ICAgICAgIHwKCiAgICAgICAgICBGaWd1cmUgOTogU2ltcGxlIGF0b21pYyBibG9ja3dpc2UgUFVU IHdpdGggbmVnb3RpYXRpb24KCjMuMS4gIEhUVFAgTWFwcGluZyBDb25zaWRlcmF0aW9ucwoKICAg SW4gdGhpcyBzdWJzZWN0aW9uLCB3ZSBnaXZlIHNvbWUgYnJpZWYgZXhhbXBsZXMgZm9yIHRoZSBp bmZsdWVuY2UgdGhlCiAgIEJsb2NrIE9wdGlvbiBtaWdodCBoYXZlIG9uIGludGVybWVkaWFyaWVz IHRoYXQgbWFwIGJldHdlZW4gQ29BUCBhbmQKICAgSFRUUC4KCiAgIEZvciBtYXBwaW5nIENvQVAg cmVxdWVzdHMgdG8gSFRUUCwgdGhlIGludGVybWVkaWFyeSBtYXkgd2FudCB0byBtYXAKICAgdGhl IGJsb2NrLXdpc2UgdHJhbnNmZXIgaW50byBhIHNpbmdsZSBIVFRQIHRyYW5zZmVyLiAgRS5nLiwg Zm9yIGEgR0VUCiAgIHJlcXVlc3QsIHRoZSBpbnRlcm1lZGlhcnkgY291bGQgcGVyZm9ybSB0aGUg SFRUUCByZXF1ZXN0IG9uY2UgdGhlCiAgIGZpcnN0IGJsb2NrIGhhcyBiZWVuIHJlcXVlc3RlZCBh bmQgY291bGQgdGhlbiBmdWxmaWxsIGFsbCBmdXJ0aGVyCiAgIGJsb2NrIHJlcXVlc3RzIG91dCBv ZiBpdHMgY2FjaGUuICBBIGNvbnN0cmFpbmVkIGltcGxlbWVudGF0aW9uIG1heQogICBub3QgYmUg YWJsZSB0byBjYWNoZSB0aGUgZW50aXJlIG9iamVjdCBhbmQgbWF5IHVzZSBhIGNvbWJpbmF0aW9u IG9mCiAgIFRDUCBmbG93IGNvbnRyb2wgYW5kIChpbiBwYXJ0aWN1bGFyIGlmIHRpbWVvdXRzIG9j Y3VyKSBIVFRQIHJhbmdlCiAgIHJlcXVlc3RzIHRvIG9idGFpbiB0aGUgaW5mb3JtYXRpb24gbmVj ZXNzYXJ5IGZvciB0aGUgbmV4dCBibG9jawogICB0cmFuc2ZlciBhdCB0aGUgcmlnaHQgdGltZS4K CiAgIEZvciBQVVQgb3IgUE9TVCByZXF1ZXN0cywgdGhlcmUgaXMgbW9yZSB2YXJpYXRpb24gaW4g aG93IEhUVFAgc2VydmVycwogICBtaWdodCBpbXBsZW1lbnQgcmFuZ2VzLiAgU29tZSBXZWJEQVYg c2VydmVycyBkbywgYnV0IGluIGdlbmVyYWwgdGhlCiAgIENvQVAtdG8tSFRUUCBpbnRlcm1lZGlh cnkgd2lsbCBoYXZlIHRvIHRyeSBzZW5kaW5nIHRoZSBwYXlsb2FkIG9mIGFsbAogICB0aGUgYmxv Y2tzIG9mIGEgYmxvY2std2lzZSB0cmFuc2ZlciB3aXRoaW4gb25lIEhUVFAgcmVxdWVzdC4gIElm CiAgIGVub3VnaCBidWZmZXJpbmcgaXMgYXZhaWxhYmxlLCB0aGlzIHJlcXVlc3QgY2FuIGJlIHN0 YXJ0ZWQgd2hlbiB0aGUKICAgbGFzdCBDb0FQIGJsb2NrIGlzIHJlY2VpdmVkLiAgQSBjb25zdHJh aW5lZCBpbXBsZW1lbnRhdGlvbiBtYXkgd2FudAogICB0byByZWxpZXZlIGl0cyBidWZmZXJpbmcg YnkgYWxyZWFkeSBzdGFydGluZyB0byBzZW5kIHRoZSBIVFRQIHJlcXVlc3QKICAgYXQgdGhlIHRp bWUgdGhlIGZpcnN0IENvQVAgYmxvY2sgaXMgcmVjZWl2ZWQ7IGFueSBIVFRQIDQwOCBzdGF0dXMK ICAgY29kZSB0aGF0IGluZGljYXRlcyB0aGF0IHRoZSBIVFRQIHNlcnZlciBiZWNhbWUgaW1wYXRp ZW50IHdpdGggdGhlCiAgIHJlc3VsdGluZyB0cmFuc2ZlciBjYW4gdGhlbiBiZSBtYXBwZWQgaW50 byBhIENvQVAgNC4wOCByZXNwb25zZSBjb2RlCiAgIChzaW1pbGFybHksIDQxMyBtYXBzIHRvIDQu MTMpLgoKCgoKU2hlbGJ5ICYgQm9ybWFubiAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAxNSwgMjAx MSAgICAgICAgICAgICAgW1BhZ2UgMTVdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICBCbG9ja3dp c2UgdHJhbnNmZXJzIGluIENvQVAgICAgICAgICAgICBNYXJjaCAyMDExCgoKICAgRm9yIG1hcHBp bmcgSFRUUCB0byBDb0FQLCB0aGUgaW50ZXJtZWRpYXJ5IG1heSB3YW50IHRvIG1hcCBhIHNpbmds ZQogICBIVFRQIHRyYW5zZmVyIGludG8gYSBibG9jay13aXNlIHRyYW5zZmVyLiAgSWYgdGhlIEhU VFAgY2xpZW50IGlzIHRvbwogICBzbG93IGRlbGl2ZXJpbmcgYSByZXF1ZXN0IGJvZHkgb24gYSBQ VVQgb3IgUE9TVCwgdGhlIENvQVAgc2VydmVyCiAgIG1pZ2h0IHRpbWUgb3V0IGFuZCByZXR1cm4g YSA0LjA4IHJlc3BvbnNlIGNvZGUsIHdoaWNoIGluIHR1cm4gbWFwcwogICB3ZWxsIHRvIGFuIEhU VFAgNDA4IHN0YXR1cyBjb2RlIChhZ2FpbiwgNC4xMyBtYXBzIHRvIDQxMykuICBIVFRQCiAgIHJh bmdlIHJlcXVlc3RzIHJlY2VpdmVkIG9uIHRoZSBIVFRQIHNpZGUgbWF5IGJlIHNlcnZlZCBvdXQg b2YgYSBjYWNoZQogICBhbmQvb3IgbWFwcGVkIHRvIEdFVCByZXF1ZXN0cyB0aGF0IHJlcXVlc3Qg YSBzZXF1ZW5jZSBvZiBibG9ja3MKICAgb3ZlcmxhcHBpbmcgdGhlIHJhbmdlLgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKU2hlbGJ5ICYgQm9ybWFubiAgICAgICBF eHBpcmVzIFNlcHRlbWJlciAxNSwgMjAxMSAgICAgICAgICAgICAgW1BhZ2UgMTZdCgwKSW50ZXJu ZXQtRHJhZnQgICAgICAgICBCbG9ja3dpc2UgdHJhbnNmZXJzIGluIENvQVAgICAgICAgICAgICBN YXJjaCAyMDExCgoKNC4gIElBTkEgQ29uc2lkZXJhdGlvbnMKCiAgIFRoaXMgZHJhZnQgYWRkcyB0 aGUgZm9sbG93aW5nIG9wdGlvbiBudW1iZXIgdG8gdGhlIENvQVAgT3B0aW9uCiAgIE51bWJlcnMg cmVnaXN0cnkgb2YgW0ktRC5pZXRmLWNvcmUtY29hcF06CgogICAgICAgICAgICAgICAgICAgICAg Ky0tLS0tLS0tKy0tLS0tLS0rLS0tLS0tLS0tLS0rCiAgICAgICAgICAgICAgICAgICAgICB8IE51 bWJlciB8IE5hbWUgIHwgUmVmZXJlbmNlIHwKICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0t LSstLS0tLS0tKy0tLS0tLS0tLS0tKwogICAgICAgICAgICAgICAgICAgICAgfCAgICAgMTMgfCBC bG9jayB8IFtSRkNYWFhYXSB8CiAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0rLS0tLS0t LSstLS0tLS0tLS0tLSsKCiAgICAgICAgICAgICAgICAgICAgICAgVGFibGUgMjogQ29BUCBPcHRp b24gTnVtYmVycwoKICAgVGhpcyBkcmFmdCBhZGRzIHRoZSBmb2xsb3dpbmcgcmVzcG9uc2UgY29k ZSB0byB0aGUgQ29BUCBSZXNwb25zZQogICBDb2RlcyByZWdpc3RyeSBvZiBbSS1ELmlldGYtY29y ZS1jb2FwXToKCiAgICAgICAgICAgKy0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSstLS0tLS0tLS0tLSsKICAgICAgICAgICB8IENvZGUgfCBEZXNjcmlwdGlvbiAgICAgICAg ICAgICAgICAgICAgfCBSZWZlcmVuY2UgfAogICAgICAgICAgICstLS0tLS0rLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0rCiAgICAgICAgICAgfCAgMTM2IHwgNC4w OCBSZXF1ZXN0IEVudGl0eSBJbmNvbXBsZXRlIHwgW1JGQ1hYWFhdIHwKICAgICAgICAgICArLS0t LS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tKwoKICAgICAg ICAgICAgICAgICAgICAgICBUYWJsZSAzOiBDb0FQIFJlc3BvbnNlIENvZGVzCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgpTaGVsYnkgJiBCb3JtYW5uICAgICAgIEV4cGlyZXMgU2VwdGVtYmVy IDE1LCAyMDExICAgICAgICAgICAgICBbUGFnZSAxN10KDApJbnRlcm5ldC1EcmFmdCAgICAgICAg IEJsb2Nrd2lzZSB0cmFuc2ZlcnMgaW4gQ29BUCAgICAgICAgICAgIE1hcmNoIDIwMTEKCgo1LiAg U2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMKCiAgIFByb3ZpZGluZyBhY2Nlc3MgdG8gYmxvY2tzIHdp dGhpbiBhIHJlc291cmNlIG1heSBsZWFkIHRvIHN1cnByaXNpbmcKICAgdnVsbmVyYWJpbGl0aWVz LiAgV2hlcmUgcmVxdWVzdHMgYXJlIG5vdCBpbXBsZW1lbnRlZCBhdG9taWNhbGx5LCBhbgogICBh dHRhY2tlciBtYXkgYmUgYWJsZSB0byBleHBsb2l0IGEgcmFjZSBjb25kaXRpb24gb3IgY29uZnVz ZSBhIHNlcnZlcgogICBieSBpbmR1Y2luZyBpdCB0byB1c2UgYSBwYXJ0aWFsbHkgdXBkYXRlZCBy ZXNvdXJjZSByZXByZXNlbnRhdGlvbi4KICAgUGFydGlhbCB0cmFuc2ZlcnMgbWF5IGFsc28gbWFr ZSBjZXJ0YWluIHByb2JsZW1hdGljIGRhdGEgaW52aXNpYmxlIHRvCiAgIGludHJ1c2lvbiBkZXRl Y3Rpb24gc3lzdGVtczsgaXQgaXMgUkVDT01NRU5ERUQgdGhhdCBhbiBpbnRydXNpb24KICAgZGV0 ZWN0aW9uIHN5c3RlbSAoSURTKSB0aGF0IGFuYWx5emVzIHJlc291cmNlIHJlcHJlc2VudGF0aW9u cwogICB0cmFuc2ZlcnJlZCBieSBDb0FQIGltcGxlbWVudCB0aGUgQmxvY2sgT3B0aW9uIHRvIGdh aW4gYWNjZXNzIHRvCiAgIGVudGlyZSByZXNvdXJjZSByZXByZXNlbnRhdGlvbnMuICBTdGlsbCwg YXBwcm9hY2hlcyBzdWNoIGFzCiAgIHRyYW5zZmVycmluZyBldmVuLW51bWJlcmVkIGJsb2NrcyBv biBvbmUgcGF0aCBhbmQgb2RkLW51bWJlcmVkIGJsb2NrcwogICBvbiBhbm90aGVyIHBhdGgsIG9y IGV2ZW4gdHJhbnNmZXJyaW5nIGJsb2NrcyBtdWx0aXBsZSB0aW1lcyB3aXRoCiAgIGRpZmZlcmVu dCBjb250ZW50IGFuZCBvYnRhaW5pbmcgYSBkaWZmZXJlbnQgaW50ZXJwcmV0YXRpb24gb2YKICAg dGVtcG9yYWwgb3JkZXIgYXQgdGhlIElEUyB0aGFuIGF0IHRoZSBzZXJ2ZXIsIG1heSBwcmV2ZW50 IGFuIElEUyBmcm9tCiAgIHNlZWluZyB0aGUgd2hvbGUgcGljdHVyZS4gIFRoZXNlIGtpbmRzIG9m IGF0dGFja3MgYXJlIHdlbGwgdW5kZXJzdG9vZAogICBmcm9tIElQIGZyYWdtZW50YXRpb24gYW5k IFRDUCBzZWdtZW50YXRpb247IENvQVAgZG9lcyBub3QgYWRkCiAgIGZ1bmRhbWVudGFsbHkgbmV3 IGNvbnNpZGVyYXRpb25zLgoKICAgV2hlcmUgYWNjZXNzIHRvIGEgcmVzb3VyY2UgaXMgb25seSBn cmFudGVkIHRvIGNsaWVudHMgbWFraW5nIHVzZSBvZiBhCiAgIHNwZWNpZmljIHNlY3VyaXR5IGFz c29jaWF0aW9uLCBhbGwgYmxvY2tzIG9mIHRoYXQgcmVzb3VyY2UgTVVTVCBiZQogICBzdWJqZWN0 IHRvIHRoZSBzYW1lIHNlY3VyaXR5IGNoZWNrczsgaXQgTVVTVCBOT1QgYmUgcG9zc2libGUgZm9y CiAgIHVucHJvdGVjdGVkIGV4Y2hhbmdlcyB0byBpbmZsdWVuY2UgYmxvY2tzIG9mIGFuIG90aGVy d2lzZSBwcm90ZWN0ZWQKICAgcmVzb3VyY2UuICBBcyBhIHJlbGF0ZWQgY29uc2lkZXJhdGlvbiwg d2hlcmUgb2JqZWN0IHNlY3VyaXR5IGlzCiAgIGVtcGxveWVkLCBQVVQvUE9TVCBzaG91bGQgYmUg aW1wbGVtZW50ZWQgaW4gdGhlIGF0b21pYyBmYXNoaW9uLAogICB1bmxlc3MgdGhlIG9iamVjdCBz ZWN1cml0eSBvcGVyYXRpb24gaXMgcGVyZm9ybWVkIG9uIGVhY2ggYWNjZXNzIGFuZAogICB0aGUg Y3JlYXRpb24gb2YgdW51c2FibGUgcmVzb3VyY2VzIGNhbiBiZSB0b2xlcmF0ZWQuCgo1LjEuICBN aXRpZ2F0aW5nIFJlc291cmNlIEV4aGF1c3Rpb24gQXR0YWNrcwoKICAgQ2VydGFpbiBibG9ja3dp c2UgcmVxdWVzdHMgbWF5IGluZHVjZSB0aGUgc2VydmVyIHRvIGNyZWF0ZSBzdGF0ZSwKICAgZS5n LiB0byBjcmVhdGUgYSBzbmFwc2hvdCBmb3IgdGhlIGJsb2Nrd2lzZSBHRVQgb2YgYSBmYXN0LWNo YW5naW5nCiAgIHJlc291cmNlIHRvIGVuYWJsZSBjb25zaXN0ZW50IGFjY2VzcyB0byB0aGUgc2Ft ZSB2ZXJzaW9uIG9mIGEKICAgcmVzb3VyY2UgZm9yIGFsbCBibG9ja3MsIG9yIHRvIGNyZWF0ZSB0 ZW1wb3JhcnkgcmVzb3VyY2UKICAgcmVwcmVzZW50YXRpb25zIHRoYXQgYXJlIGNvbGxlY3RlZCB1 bnRpbCBwcmVzc2VkIGludG8gc2VydmljZSBieSBhCiAgIGZpbmFsIFBVVCBvciBQT1NUIHdpdGgg dGhlIG1vcmUgYml0IHVuc2V0LiAgQWxsIG1lY2hhbmlzbXMgdGhhdAogICBpbmR1Y2UgYSBzZXJ2 ZXIgdG8gY3JlYXRlIHN0YXRlIHRoYXQgY2Fubm90IHNpbXBseSBiZSBjbGVhbmVkIHVwCiAgIGNy ZWF0ZSBvcHBvcnR1bml0aWVzIGZvciBkZW5pYWwtb2Ytc2VydmljZSBhdHRhY2tzLiAgU2VydmVy cyBTSE9VTEQKICAgYXZvaWQgYmVpbmcgc3ViamVjdCB0byByZXNvdXJjZSBleGhhdXN0aW9uIGJh c2VkIG9uIHN0YXRlIGNyZWF0ZWQgYnkKICAgdW50cnVzdGVkIHNvdXJjZXMuICBCdXQgZXZlbiBp ZiB0aGlzIGlzIGRvbmUsIHRoZSBtaXRpZ2F0aW9uIG1heQogICBjYXVzZSBhIGRlbmlhbC1vZi1z ZXJ2aWNlIHRvIGEgbGVnaXRpbWF0ZSByZXF1ZXN0IHdoZW4gaXQgaXMgZHJvd25lZAogICBvdXQg Ynkgb3RoZXIgc3RhdGUtY3JlYXRpbmcgcmVxdWVzdHMuICBXaGVyZXZlciBwb3NzaWJsZSwgc2Vy dmVycwogICBzaG91bGQgdGhlcmVmb3JlIG1pbmltaXplIHRoZSBvcHBvcnR1bml0aWVzIHRvIGNy ZWF0ZSBzdGF0ZSBmb3IKICAgdW50cnVzdGVkIHNvdXJjZXMsIGUuZy4gYnkgdXNpbmcgc3RhdGVs ZXNzIGFwcHJvYWNoZXMuCgogICBQZXJmb3JtaW5nIHNlZ21lbnRhdGlvbiBhdCB0aGUgYXBwbGlj YXRpb24gbGF5ZXIgaXMgYWxtb3N0IGFsd2F5cwogICBiZXR0ZXIgaW4gdGhpcyByZXNwZWN0IHRo YW4gYXQgdGhlIHRyYW5zcG9ydCBsYXllciBvciBsb3dlciAoSVAKICAgZnJhZ21lbnRhdGlvbiwg YWRhcHRhdGlvbiBsYXllciBmcmFnbWVudGF0aW9uKSwgZS5nLiBiZWNhdXNlIHRoZXJlIGlzCgoK ClNoZWxieSAmIEJvcm1hbm4gICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMTUsIDIwMTEgICAgICAg ICAgICAgIFtQYWdlIDE4XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgQmxvY2t3aXNlIHRyYW5z ZmVycyBpbiBDb0FQICAgICAgICAgICAgTWFyY2ggMjAxMQoKCiAgIGFwcGxpY2F0aW9uIGxheWVy IHNlbWFudGljcyB0aGF0IGNhbiBiZSB1c2VkIGZvciBtaXRpZ2F0aW9uIG9yCiAgIGJlY2F1c2Ug bG93ZXIgbGF5ZXJzIHByb3ZpZGUgc2VjdXJpdHkgYXNzb2NpYXRpb25zIHRoYXQgY2FuIHByZXZl bnQKICAgYXR0YWNrcy4gIEhvd2V2ZXIsIGl0IGlzIGxlc3MgY29tbW9uIHRvIGFwcGx5IHRpbWVv dXRzIGFuZCBrZWVwYWxpdmUKICAgbWVjaGFuaXNtcyBhdCB0aGUgYXBwbGljYXRpb24gbGF5ZXIg dGhhbiBhdCBsb3dlciBsYXllcnMuICBTZXJ2ZXJzCiAgIE1BWSB3YW50IHRvIGNsZWFuIHVwIGFj Y3JldGVkIHN0YXRlIGJ5IHRpbWluZyBpdCBvdXQgKGNmLiByZXNwb25zZQogICBjb2RlIDQuMDgp LCBhbmQgY2xpZW50cyBTSE9VTEQgYmUgcHJlcGFyZWQgdG8gcnVuIGJsb2Nrd2lzZSB0cmFuc2Zl cnMKICAgaW4gYW4gZXhwZWRpZW50IHdheSB0byBtaW5pbWl6ZSB0aGUgbGlrZWxpaG9vZCBvZiBy dW5uaW5nIGludG8gc3VjaCBhCiAgIHRpbWVvdXQuCgo1LjIuICBNaXRpZ2F0aW5nIEFtcGxpZmlj YXRpb24gQXR0YWNrcwoKICAgW0ktRC5pZXRmLWNvcmUtY29hcF0gZGlzY3Vzc2VzIHRoZSBzdXNj ZXB0aWJpbGl0eSBvZiBDb0FQIGVuZC1wb2ludHMKICAgZm9yIHVzZSBpbiBhbXBsaWZpY2F0aW9u IGF0dGFja3MuCgogICBBIENvQVAgc2VydmVyIGNhbiByZWR1Y2UgdGhlIGFtb3VudCBvZiBhbXBs aWZpY2F0aW9uIGl0IHByb3ZpZGVzIHRvCiAgIGFuIGF0dGFja2VyIGJ5IG9mZmVyaW5nIGxhcmdl IHJlc291cmNlIHJlcHJlc2VudGF0aW9ucyBvbmx5IGluCiAgIHJlbGF0aXZlbHkgc21hbGwgYmxv Y2tzLiAgV2l0aCB0aGlzLCBlLmcuLCBmb3IgYSAxMDAwIGJ5dGUgcmVzb3VyY2UsCiAgIGEgMTAt Ynl0ZSByZXF1ZXN0IG1pZ2h0IHJlc3VsdCBpbiBhbiA4MC1ieXRlIHJlc3BvbnNlICh3aXRoIGEg NjQtYnl0ZQogICBibG9jaykgaW5zdGVhZCBvZiBhIDEwMTYtYnl0ZSByZXNwb25zZSwgY29uc2lk ZXJhYmx5IHJlZHVjaW5nIHRoZQogICBhbXBsaWZpY2F0aW9uIHByb3ZpZGVkLgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKU2hlbGJ5ICYgQm9ybWFubiAgICAgICBFeHBpcmVzIFNlcHRl bWJlciAxNSwgMjAxMSAgICAgICAgICAgICAgW1BhZ2UgMTldCgwKSW50ZXJuZXQtRHJhZnQgICAg ICAgICBCbG9ja3dpc2UgdHJhbnNmZXJzIGluIENvQVAgICAgICAgICAgICBNYXJjaCAyMDExCgoK Ni4gIEFja25vd2xlZGdlbWVudHMKCiAgIE11Y2ggb2YgdGhlIGNvbnRlbnQgb2YgdGhpcyBkcmFm dCBpcyB0aGUgcmVzdWx0IG9mIGRpc2N1c3Npb25zIHdpdGgKICAgdGhlIFtJLUQuaWV0Zi1jb3Jl LWNvYXBdIGF1dGhvcnMsIGFuZCB2aWEgbWFueSBDb1JFIFdHIGRpc2N1c3Npb25zLgogICBUb2tl bnMgd2VyZSBzdWdnZXN0ZWQgYnkgR2lsbWFuIFRvbGxlIGFuZCByZWZpbmVkIGJ5IEtsYXVzIEhh cnRrZS4KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKClNoZWxi eSAmIEJvcm1hbm4gICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMTUsIDIwMTEgICAgICAgICAgICAg IFtQYWdlIDIwXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgQmxvY2t3aXNlIHRyYW5zZmVycyBp biBDb0FQICAgICAgICAgICAgTWFyY2ggMjAxMQoKCjcuICBSZWZlcmVuY2VzCgo3LjEuICBOb3Jt YXRpdmUgUmVmZXJlbmNlcwoKICAgW0ktRC5pZXRmLWNvcmUtY29hcF0KICAgICAgICAgICAgICBT aGVsYnksIFouLCBIYXJ0a2UsIEsuLCBCb3JtYW5uLCBDLiwgYW5kIEIuIEZyYW5rLAogICAgICAg ICAgICAgICJDb25zdHJhaW5lZCBBcHBsaWNhdGlvbiBQcm90b2NvbCAoQ29BUCkiLAogICAgICAg ICAgICAgIGRyYWZ0LWlldGYtY29yZS1jb2FwLTA1ICh3b3JrIGluIHByb2dyZXNzKSwgTWFyY2gg MjAxMS4KCiAgIFtSRkMyMTE5XSAgQnJhZG5lciwgUy4sICJLZXkgd29yZHMgZm9yIHVzZSBpbiBS RkNzIHRvIEluZGljYXRlCiAgICAgICAgICAgICAgUmVxdWlyZW1lbnQgTGV2ZWxzIiwgQkNQIDE0 LCBSRkMgMjExOSwgTWFyY2ggMTk5Ny4KCiAgIFtSRkMyNjE2XSAgRmllbGRpbmcsIFIuLCBHZXR0 eXMsIEouLCBNb2d1bCwgSi4sIEZyeXN0eWssIEguLAogICAgICAgICAgICAgIE1hc2ludGVyLCBM LiwgTGVhY2gsIFAuLCBhbmQgVC4gQmVybmVycy1MZWUsICJIeXBlcnRleHQKICAgICAgICAgICAg ICBUcmFuc2ZlciBQcm90b2NvbCAtLSBIVFRQLzEuMSIsIFJGQyAyNjE2LCBKdW5lIDE5OTkuCgo3 LjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzCgogICBbUkVTVF0gICAgIEZpZWxkaW5nLCBSLiwg IkFyY2hpdGVjdHVyYWwgU3R5bGVzIGFuZCB0aGUgRGVzaWduIG9mCiAgICAgICAgICAgICAgTmV0 d29yay1iYXNlZCBTb2Z0d2FyZSBBcmNoaXRlY3R1cmVzIiwgMjAwMC4KCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKClNoZWxieSAmIEJvcm1hbm4gICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIg MTUsIDIwMTEgICAgICAgICAgICAgIFtQYWdlIDIxXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAg QmxvY2t3aXNlIHRyYW5zZmVycyBpbiBDb0FQICAgICAgICAgICAgTWFyY2ggMjAxMQoKCkF1dGhv cnMnIEFkZHJlc3NlcwoKICAgWmFjaCBTaGVsYnkgKGVkaXRvcikKICAgU2Vuc2lub2RlCiAgIEtp ZGVrdWphIDIKICAgVnVva2F0dGkgIDg4NjAwCiAgIEZpbmxhbmQKCiAgIFBob25lOiArMzU4NDA3 Nzk2Mjk3CiAgIEVtYWlsOiB6YWNoQHNlbnNpbm9kZS5jb20KCgogICBDYXJzdGVuIEJvcm1hbm4K ICAgVW5pdmVyc2l0YWV0IEJyZW1lbiBUWkkKICAgUG9zdGZhY2ggMzMwNDQwCiAgIEJyZW1lbiAg RC0yODM1OQogICBHZXJtYW55CgogICBQaG9uZTogKzQ5LTQyMS0yMTgtNjM5MjEKICAgRmF4OiAg ICs0OS00MjEtMjE4LTcwMDAKICAgRW1haWw6IGNhYm9AdHppLm9yZwoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgpTaGVsYnkgJiBCb3JtYW5uICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDE1 LCAyMDExICAgICAgICAgICAgICBbUGFnZSAyMl0KDAo= ------_=_NextPart_001_01CC097F.2388F67A Content-Type: text/plain; name=draft-ietf-core-coap-05_CGP.txt Content-Transfer-Encoding: base64 Content-Description: draft-ietf-core-coap-05_CGP.txt Content-Disposition: attachment; filename="draft-ietf-core-coap-05_CGP.txt" e0NoYW5nZXMgYnkgQ2hhcmxlcyBQYWxtZXIgY2hhcmxlcy5wYWxtZXJAb256by5jb20gCi0gVXNl IGEgZGlmZiB0b29sIHRvIGxvY2F0ZSB0aGUgY2hhbmdlcy4KLSBQcmVzdW1lZCBzdHJhaWdodC1m b3J3YXJkIGVkaXRvcmlhbCBjb3JyZWN0aW9ucyBhcmUgcHJvdmlkZWQgd2l0aG91dCBjb21tZW50 LgotIENvbW1lbnRzIGFuZCBxdWVzdGlvbnMgYXJlIGlkZW50aWVkIGJ5IHtwYXJlbnRoZXNlc30u fQoKCgpDb1JFIFdvcmtpbmcgR3JvdXAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBaLiBTaGVsYnkKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgU2Vuc2lub2RlCkludGVuZGVkIHN0YXR1czogU3Rh bmRhcmRzIFRyYWNrICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEsuIEhhcnRrZQpFeHBp cmVzOiBTZXB0ZW1iZXIgMTUsIDIwMTEgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IEMuIEJvcm1hbm4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIFVuaXZlcnNpdGFldCBCcmVtZW4gVFpJCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBCLiBGcmFuawogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFNreUZvdW5k cnkKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIE1hcmNoIDE0LCAyMDExCgoKICAgICAgICAgICAgICAgIENvbnN0cmFpbmVkIEFwcGxpY2F0 aW9uIFByb3RvY29sIChDb0FQKQogICAgICAgICAgICAgICAgICAgICAgICBkcmFmdC1pZXRmLWNv cmUtY29hcC0wNQoKQWJzdHJhY3QKCiAgIFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIHRoZSBDb25z dHJhaW5lZCBBcHBsaWNhdGlvbiBQcm90b2NvbCAoQ29BUCksCiAgIGEgc3BlY2lhbGl6ZWQgd2Vi IHRyYW5zZmVyIHByb3RvY29sIGZvciB1c2Ugd2l0aCBjb25zdHJhaW5lZCBuZXR3b3JrcwogICBh bmQgbm9kZXMgZm9yIG1hY2hpbmUtdG8tbWFjaGluZSBhcHBsaWNhdGlvbnMgc3VjaCBhcyBzbWFy dCBlbmVyZ3kKICAgYW5kIGJ1aWxkaW5nIGF1dG9tYXRpb24uICBUaGVzZSBjb25zdHJhaW5lZCBu b2RlcyBvZnRlbiBoYXZlIDgtYml0CiAgIG1pY3JvY29udHJvbGxlcnMgd2l0aCBzbWFsbCBhbW91 bnRzIG9mIFJPTSBhbmQgUkFNLCB3aGlsZSBuZXR3b3JrcwogICBzdWNoIGFzIDZMb1dQQU4gb2Z0 ZW4gaGF2ZSBoaWdoIHBhY2tldCBlcnJvciByYXRlcyBhbmQgYSB0eXBpY2FsCiAgIHRocm91Z2hw dXQgb2YgMTBzIG9mIGtiaXQvcy4gIENvQVAgcHJvdmlkZXMgYSBtZXRob2QvcmVzcG9uc2UKICAg aW50ZXJhY3Rpb24gbW9kZWwgYmV0d2VlbiBhcHBsaWNhdGlvbiBlbmQtcG9pbnRzLCBzdXBwb3J0 cyBidWlsdC1pbgogICByZXNvdXJjZSBkaXNjb3ZlcnksIGFuZCBpbmNsdWRlcyBrZXkgd2ViIGNv bmNlcHRzIHN1Y2ggYXMgVVJJcyBhbmQKICAgY29udGVudC10eXBlcy4gIENvQVAgZWFzaWx5IHRy YW5zbGF0ZXMgdG8gSFRUUCBmb3IgaW50ZWdyYXRpb24gd2l0aAogICB0aGUgd2ViIHdoaWxlIG1l ZXRpbmcgc3BlY2lhbGl6ZWQgcmVxdWlyZW1lbnRzIHN1Y2ggYXMgbXVsdGljYXN0CiAgIHN1cHBv cnQsIHZlcnkgbG93IG92ZXJoZWFkIGFuZCBzaW1wbGljaXR5IGZvciBjb25zdHJhaW5lZAogICBl bnZpcm9ubWVudHMuCgpTdGF0dXMgb2YgdGhpcyBNZW1vCgogICBUaGlzIEludGVybmV0LURyYWZ0 IGlzIHN1Ym1pdHRlZCBpbiBmdWxsIGNvbmZvcm1hbmNlIHdpdGggdGhlCiAgIHByb3Zpc2lvbnMg b2YgQkNQIDc4IGFuZCBCQ1AgNzkuCgogICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9j dW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZwogICBUYXNrIEZvcmNlIChJRVRGKS4g IE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZQogICB3b3JraW5nIGRv Y3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0 LQogICBEcmFmdHMgaXMgYXQgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RyYWZ0cy9jdXJy ZW50Ly4KCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBh IG1heGltdW0gb2Ygc2l4IG1vbnRocwogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBv ciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQogICB0aW1lLiAgSXQgaXMgaW5h cHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQogICBtYXRlcmlh bCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iCgogICBU aGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIFNlcHRlbWJlciAxNSwgMjAxMS4KCkNv cHlyaWdodCBOb3RpY2UKCgoKClNoZWxieSwgZXQgYWwuICAgICAgICAgRXhwaXJlcyBTZXB0ZW1i ZXIgMTUsIDIwMTEgICAgICAgICAgICAgICBbUGFnZSAxXQoMCkludGVybmV0LURyYWZ0ICAgQ29u c3RyYWluZWQgQXBwbGljYXRpb24gUHJvdG9jb2wgKENvQVApICAgICAgTWFyY2ggMjAxMQoKCiAg IENvcHlyaWdodCAoYykgMjAxMSBJRVRGIFRydXN0IGFuZCB0aGUgcGVyc29ucyBpZGVudGlmaWVk IGFzIHRoZQogICBkb2N1bWVudCBhdXRob3JzLiAgQWxsIHJpZ2h0cyByZXNlcnZlZC4KCiAgIFRo aXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRydXN0J3MgTGVn YWwKICAgUHJvdmlzaW9ucyBSZWxhdGluZyB0byBJRVRGIERvY3VtZW50cwogICAoaHR0cDovL3Ry dXN0ZWUuaWV0Zi5vcmcvbGljZW5zZS1pbmZvKSBpbiBlZmZlY3Qgb24gdGhlIGRhdGUgb2YKICAg cHVibGljYXRpb24gb2YgdGhpcyBkb2N1bWVudC4gIFBsZWFzZSByZXZpZXcgdGhlc2UgZG9jdW1l bnRzCiAgIGNhcmVmdWxseSwgYXMgdGhleSBkZXNjcmliZSB5b3VyIHJpZ2h0cyBhbmQgcmVzdHJp Y3Rpb25zIHdpdGggcmVzcGVjdAogICB0byB0aGlzIGRvY3VtZW50LiAgQ29kZSBDb21wb25lbnRz IGV4dHJhY3RlZCBmcm9tIHRoaXMgZG9jdW1lbnQgbXVzdAogICBpbmNsdWRlIFNpbXBsaWZpZWQg QlNEIExpY2Vuc2UgdGV4dCBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiA0LmUgb2YKICAgdGhlIFRy dXN0IExlZ2FsIFByb3Zpc2lvbnMgYW5kIGFyZSBwcm92aWRlZCB3aXRob3V0IHdhcnJhbnR5IGFz CiAgIGRlc2NyaWJlZCBpbiB0aGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZS4KCgpUYWJsZSBvZiBD b250ZW50cwoKICAgMS4gIEludHJvZHVjdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuICA1CiAgICAgMS4xLiAgRmVhdHVyZXMgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNQogICAgIDEuMi4gIFRlcm1p bm9sb2d5ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDYK ICAgMi4gIENvbnN0cmFpbmVkIEFwcGxpY2F0aW9uIFByb3RvY29sIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICA3CiAgICAgMi4xLiAgTWVzc2FnaW5nIE1vZGVsICAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOAogICAgIDIuMi4gIFJlcXVlc3QvUmVzcG9u c2UgTW9kZWwgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDkKICAgICAyLjMu ICBJbnRlcm1lZGlhcmllcyBhbmQgQ2FjaGluZyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIDExCiAgICAgMi40LiAgUmVzb3VyY2UgRGlzY292ZXJ5IC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAxMQogICAzLiAgTWVzc2FnZSBTeW50YXggLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTIKICAgICAzLjEuICBNZXNzYWdl IEZvcm1hdCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEyCiAg ICAgICAzLjEuMS4gIE1lc3NhZ2UgU2l6ZSBJbXBsZW1lbnRhdGlvbiBDb25zaWRlcmF0aW9ucyAu IC4gLiAuIC4gLiAxMwogICAgIDMuMi4gIE9wdGlvbiBGb3JtYXQgIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTQKICAgNC4gIE1lc3NhZ2UgU2VtYW50aWNzICAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE1CiAgICAgNC4xLiAg UmVsaWFibGUgTWVzc2FnZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAxNgogICAgIDQuMi4gIFVucmVsaWFibGUgTWVzc2FnZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gMTcKICAgICA0LjMuICBNZXNzYWdlIFR5cGVzICAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE3CiAgICAgICA0LjMuMS4gIENvbmZp cm1hYmxlIChDT04pICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxOAogICAg ICAgNC4zLjIuICBOb24tQ29uZmlybWFibGUgKE5PTikgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gMTgKICAgICAgIDQuMy4zLiAgQWNrbm93bGVkZ2VtZW50IChBQ0spICAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE4CiAgICAgICA0LjMuNC4gIFJlc2V0IChSU1QpICAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxOAogICAgIDQuNC4gIE11 bHRpY2FzdCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g MTkKICAgICA0LjUuICBDb25nZXN0aW9uIENvbnRyb2wgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIDE5CiAgIDUuICBSZXF1ZXN0L1Jlc3BvbnNlIFNlbWFudGljcyAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxOQogICAgIDUuMS4gIFJlcXVlc3RzIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTkKICAgICA1 LjIuICBSZXNwb25zZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIDIwCiAgICAgICA1LjIuMS4gIFBpZ2d5LWJhY2tlZCAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyMQogICAgICAgNS4yLjIuICBTZXBhcmF0ZSAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjEKICAgICAgIDUuMi4zLiAg Tm9uLUNvbmZpcm1hYmxlICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDIy CiAgICAgNS4zLiAgUmVxdWVzdC9SZXNwb25zZSBNYXRjaGluZyAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAyMgogICAgIDUuNC4gIE9wdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjMKICAgICAgIDUuNC4xLiAgQ3JpdGljYWwv RWxlY3RpdmUgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDIzCiAgICAgICA1 LjQuMi4gIExlbmd0aCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAyNAoKCgpTaGVsYnksIGV0IGFsLiAgICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDE1LCAy MDExICAgICAgICAgICAgICAgW1BhZ2UgMl0KDApJbnRlcm5ldC1EcmFmdCAgIENvbnN0cmFpbmVk IEFwcGxpY2F0aW9uIFByb3RvY29sIChDb0FQKSAgICAgIE1hcmNoIDIwMTEKCgogICAgICAgNS40 LjMuICBEZWZhdWx0IFZhbHVlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gMjQKICAgICAgIDUuNC40LiAgUmVwZWF0aW5nIE9wdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIDI0CiAgICAgICA1LjQuNS4gIE9wdGlvbiBOdW1iZXJzIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyNAogICAgIDUuNS4gIFBheWxvYWQg IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjUKICAg ICA1LjYuICBDYWNoaW5nICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIDI1CiAgICAgICA1LjYuMS4gIEZyZXNobmVzcyBNb2RlbCAgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyNgogICAgICAgNS42LjIuICBWYWxpZGF0aW9uIE1v ZGVsIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjYKICAgICA1LjcuICBQ cm94eWluZyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IDI3CiAgICAgNS44LiAgTWV0aG9kIERlZmluaXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAyOAogICAgICAgNS44LjEuICBHRVQgIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjgKICAgICAgIDUuOC4yLiAgUE9TVCAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI4CiAgICAg ICA1LjguMy4gIFBVVCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAyOQogICAgICAgNS44LjQuICBERUxFVEUgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjkKICAgICA1LjkuICBSZXNwb25zZSBDb2RlIERlZmlu aXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDMwCiAgICAgICA1LjkuMS4g IFN1Y2Nlc3MgMi54eCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAz MAogICAgICAgNS45LjIuICBDbGllbnQgRXJyb3IgNC54eCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gMzEKICAgICAgIDUuOS4zLiAgU2VydmVyIEVycm9yIDUueHggIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDMyCiAgICAgNS4xMC4gT3B0aW9uIERlZmlu aXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzMwogICAgICAg NS4xMC4xLiBUb2tlbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gMzMKICAgICAgIDUuMTAuMi4gVXJpLUhvc3QsIFVyaS1Qb3J0LCBVcmktUGF0aCBhbmQg VXJpLVF1ZXJ5IC4gLiAuIC4gLiAuIDM0CiAgICAgICA1LjEwLjMuIFByb3h5LVVyaSAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzNQogICAgICAgNS4xMC40LiBD b250ZW50LVR5cGUgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMzUK ICAgICAgIDUuMTAuNS4gTWF4LUFnZSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIDM1CiAgICAgICA1LjEwLjYuIEVUYWcgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzNgogICAgICAgNS4xMC43LiBMb2NhdGlvbi1Q YXRoIGFuZCBMb2NhdGlvbi1RdWVyeSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMzYKICAgNi4gIENv QVAgVVJJcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIDM2CiAgICAgNi4xLiAgVVJJIFNjaGVtZSBTeW50YXggIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAzNwogICAgIDYuMi4gIE5vcm1hbGl6YXRpb24gYW5kIENvbXBh cmlzb24gUnVsZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMzcKICAgICA2LjMuICBQYXJzaW5n IFVSSXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDM4CiAg ICAgNi40LiAgQ29uc3RydWN0aW5nIFVSSXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAzOQogICA3LiAgRmluZGluZyBhbmQgQWRkcmVzc2luZyBDb0FQIEVuZC1Qb2lu dHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNDAKICAgICA3LjEuICBSZXNvdXJjZSBEaXNjb3Zl cnkgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDQwCiAgICAgNy4yLiAg RGVmYXVsdCBQb3J0IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiA0MAogICAgIDcuMy4gIE11bHRpcGxleGluZyBEVExTIGFuZCBDb0FQIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gNDEKICAgICAgIDcuMy4xLiAgRnV0dXJlLVByb29maW5nIHRoZSBN dWx0aXBsZXhpbmcgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDQxCiAgIDguICBIVFRQIE1hcHBpbmcg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0MgogICAg IDguMS4gIENvQVAtSFRUUCBNYXBwaW5nICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gNDMKICAgICA4LjIuICBIVFRQLUNvQVAgTWFwcGluZyAgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDQ3CiAgIDkuICBQcm90b2NvbCBDb25zdGFudHMgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0OQogICAxMC4gU2VjdXJp dHkgQ29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g NDkKICAgICAxMC4xLiBTZWN1cmluZyBDb0FQIHdpdGggSVBzZWMgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIDUwCiAgICAgMTAuMi4gU2VjdXJpbmcgQ29BUCB3aXRoIERUTFMgIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA1MQogICAgICAgMTAuMi4xLiBTaGFyZWRL ZXkgYW5kIE11bHRpS2V5IE1vZGVzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNTIKICAgICAg IDEwLjIuMi4gQ2VydGlmaWNhdGUgTW9kZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIDUyCiAgICAgMTAuMy4gVGhyZWF0IGFuYWx5c2lzIGFuZCBwcm90b2NvbCBsaW1pdGF0 aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiA1MwogICAgICAgMTAuMy4xLiBQcm90b2NvbCBQYXJzaW5n LCBQcm9jZXNzaW5nIFVSSXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gNTMKICAgICAgIDEwLjMuMi4g UHJveHlpbmcgYW5kIENhY2hpbmcgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDUz CiAgICAgICAxMC4zLjMuIFJpc2sgb2YgYW1wbGlmaWNhdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiA1NAoKCgpTaGVsYnksIGV0IGFsLiAgICAgICAgIEV4cGlyZXMgU2VwdGVt YmVyIDE1LCAyMDExICAgICAgICAgICAgICAgW1BhZ2UgM10KDApJbnRlcm5ldC1EcmFmdCAgIENv bnN0cmFpbmVkIEFwcGxpY2F0aW9uIFByb3RvY29sIChDb0FQKSAgICAgIE1hcmNoIDIwMTEKCgog ICAgICAgMTAuMy40LiBDcm9zcy1Qcm90b2NvbCBBdHRhY2tzIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gNTUKICAgMTEuIElBTkEgQ29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDU2CiAgICAgMTEuMS4gQ29BUCBDb2RlIFJlZ2lz dHJ5IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA1NwogICAgICAgMTEu MS4xLiBNZXRob2QgQ29kZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gNTcKICAgICAgIDExLjEuMi4gUmVzcG9uc2UgQ29kZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIDU4CiAgICAgMTEuMi4gT3B0aW9uIE51bWJlciBSZWdpc3RyeSAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA1OQogICAgIDExLjMuIE1lZGlhIFR5 cGUgUmVnaXN0cnkgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNjAKICAg ICAxMS40LiBVUkkgU2NoZW1lIFJlZ2lzdHJhdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIDYyCiAgICAgMTEuNS4gU2VydmljZSBOYW1lIGFuZCBQb3J0IE51bWJlciBSZWdp c3RyYXRpb24gIC4gLiAuIC4gLiAuIC4gLiA2MwogICAxMi4gQWNrbm93bGVkZ2VtZW50cyAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNjMKICAgMTMuIFJlZmVy ZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IDY0CiAgICAgMTMuMS4gTm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiA2NAogICAgIDEzLjIuIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNjYKICAgQXBwZW5kaXggQS4gIEludGVn ZXIgT3B0aW9uIFZhbHVlIEZvcm1hdCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDY3CiAgIEFw cGVuZGl4IEIuICBFeGFtcGxlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiA2OAogICBBcHBlbmRpeCBDLiAgVVJJIEV4YW1wbGVzICAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNzQKICAgQXBwZW5kaXggRC4gIENoYW5nZWxvZyAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDc2CiAgIEF1dGhvcnMnIEFk ZHJlc3NlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA4 MAoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpTaGVsYnksIGV0IGFsLiAgICAgICAg IEV4cGlyZXMgU2VwdGVtYmVyIDE1LCAyMDExICAgICAgICAgICAgICAgW1BhZ2UgNF0KDApJbnRl cm5ldC1EcmFmdCAgIENvbnN0cmFpbmVkIEFwcGxpY2F0aW9uIFByb3RvY29sIChDb0FQKSAgICAg IE1hcmNoIDIwMTEKCgoxLiAgSW50cm9kdWN0aW9uCgogICBUaGUgdXNlIG9mIHdlYiBzZXJ2aWNl cyBvbiB0aGUgSW50ZXJuZXQgaGFzIGJlY29tZSB1YmlxdWl0b3VzIGluIG1vc3QKICAgYXBwbGlj YXRpb25zLCBhbmQgZGVwZW5kcyBvbiB0aGUgZnVuZGFtZW50YWwgUmVwcmVzZW50YXRpb25hbCBT dGF0ZQogICBUcmFuc2ZlciAoUkVTVCkgYXJjaGl0ZWN0dXJlIG9mIHRoZSB3ZWIuCgogICBUaGUg Q29uc3RyYWluZWQgUkVTVGZ1bCBFbnZpcm9ubWVudHMgKENvUkUpIHdvcmtpbmcgZ3JvdXAgYWlt cyBhdAogICByZWFsaXppbmcgdGhlIFJFU1QgYXJjaGl0ZWN0dXJlIGluIGEgc3VpdGFibGUgZm9y bSBmb3IgdGhlIG1vc3QKICAgY29uc3RyYWluZWQgbm9kZXMgKGUuZy4gOC1iaXQgbWljcm9jb250 cm9sbGVycyB3aXRoIGxpbWl0ZWQgUkFNIGFuZAogICBST00pIGFuZCBuZXR3b3JrcyAoZS5nLiA2 TG9XUEFOKS4gIENvbnN0cmFpbmVkIG5ldHdvcmtzIGxpa2UgNkxvV1BBTgogICBzdXBwb3J0IHRo ZSBleHBlbnNpdmUgZnJhZ21lbnRhdGlvbiBvZiBJUHY2IHBhY2tldHMgaW50byBzbWFsbCBsaW5r LQogICBsYXllciBmcmFtZXMuICBPbmUgZGVzaWduIGdvYWwgb2YgQ29BUCBoYXMgYmVlbiB0byBr ZWVwIG1lc3NhZ2UKICAgb3ZlcmhlYWQgc21hbGwsIHRodXMgbGltaXRpbmcgdGhlIHVzZSBvZiBm cmFnbWVudGF0aW9uLgoKICAgT25lIG9mIHRoZSBtYWluIGdvYWxzIG9mIENvQVAgaXMgdG8gZGVz aWduIGEgZ2VuZXJpYyB3ZWIgcHJvdG9jb2wgZm9yCiAgIHRoZSBzcGVjaWFsIHJlcXVpcmVtZW50 cyBvZiB0aGlzIGNvbnN0cmFpbmVkIGVudmlyb25tZW50LCBlc3BlY2lhbGx5CiAgIGNvbnNpZGVy aW5nIGVuZXJneSwgYnVpbGRpbmcgYXV0b21hdGlvbiBhbmQgb3RoZXIgTTJNIGFwcGxpY2F0aW9u cy4KICAgVGhlIGdvYWwgb2YgQ29BUCBpcyBub3QgdG8gYmxpbmRseSBjb21wcmVzcyBIVFRQIFtS RkMyNjE2XSwgYnV0CiAgIHJhdGhlciB0byByZWFsaXplIGEgc3Vic2V0IG9mIFJFU1QgY29tbW9u IHdpdGggSFRUUCBidXQgb3B0aW1pemVkIGZvcgogICBNMk0gYXBwbGljYXRpb25zLiAgQWx0aG91 Z2ggQ29BUCBjb3VsZCBiZSB1c2VkIGZvciBjb21wcmVzc2luZyBzaW1wbGUKICAgSFRUUCBpbnRl cmZhY2VzLCBpdCBtb3JlIGltcG9ydGFudGx5IGFsc28gb2ZmZXJzIGZlYXR1cmVzIGZvciBNMk0K ICAgc3VjaCBhcyBidWlsdC1pbiBkaXNjb3ZlcnksIG11bHRpY2FzdCBzdXBwb3J0IGFuZCBhc3lu Y2hyb25vdXMKICAgbWVzc2FnZSBleGNoYW5nZXMuCgogICBUaGlzIGRvY3VtZW50IHNwZWNpZmll cyB0aGUgQ29uc3RyYWluZWQgQXBwbGljYXRpb24gUHJvdG9jb2wgKENvQVApLAogICB3aGljaCBl YXNpbHkgdHJhbnNsYXRlcyB0byBIVFRQIGZvciBpbnRlZ3JhdGlvbiB3aXRoIHRoZSBleGlzdGlu ZyB3ZWIKICAgd2hpbGUgbWVldGluZyBzcGVjaWFsaXplZCByZXF1aXJlbWVudHMgc3VjaCBhcyBt dWx0aWNhc3Qgc3VwcG9ydCwKICAgdmVyeSBsb3cgb3ZlcmhlYWQgYW5kIHNpbXBsaWNpdHkgZm9y IGNvbnN0cmFpbmVkIGVudmlyb25tZW50cyBhbmQgTTJNCiAgIGFwcGxpY2F0aW9ucy4KCjEuMS4g IEZlYXR1cmVzCgogICBDb0FQIGhhcyB0aGUgZm9sbG93aW5nIG1haW4gZmVhdHVyZXM6CgogICBv ICBDb25zdHJhaW5lZCB3ZWIgcHJvdG9jb2wgZnVsZmlsbGluZyBNMk0gcmVxdWlyZW1lbnRzLgoK ICAgbyAgQSBzdGF0ZWxlc3MgSFRUUCBtYXBwaW5nLCBhbGxvd2luZyBwcm94aWVzIHRvIGJlIGJ1 aWx0IHByb3ZpZGluZwogICAgICBhY2Nlc3MgdG8gQ29BUCByZXNvdXJjZXMgdmlhIEhUVFAgaW4g YSB1bmlmb3JtIHdheSBvciBmb3IgSFRUUAogICAgICBzaW1wbGUgaW50ZXJmYWNlcyB0byBiZSBy ZWFsaXplZCBhbHRlcm5hdGl2ZWx5IG92ZXIgQ29BUC4KCiAgIG8gIFVEUCBiaW5kaW5nIHdpdGgg cmVsaWFibGUgdW5pY2FzdCBhbmQgYmVzdC1lZmZvcnQgbXVsdGljYXN0CiAgICAgIHN1cHBvcnQu CgogICBvICBBc3luY2hyb25vdXMgbWVzc2FnZSBleGNoYW5nZXMuCgogICBvICBMb3cgaGVhZGVy IG92ZXJoZWFkIGFuZCBwYXJzaW5nIGNvbXBsZXhpdHkuCgoKCgoKU2hlbGJ5LCBldCBhbC4gICAg ICAgICBFeHBpcmVzIFNlcHRlbWJlciAxNSwgMjAxMSAgICAgICAgICAgICAgIFtQYWdlIDVdCgwK SW50ZXJuZXQtRHJhZnQgICBDb25zdHJhaW5lZCBBcHBsaWNhdGlvbiBQcm90b2NvbCAoQ29BUCkg ICAgICBNYXJjaCAyMDExCgoKICAgbyAgVVJJIGFuZCBDb250ZW50LXR5cGUgc3VwcG9ydC4KCiAg IG8gIFNpbXBsZSBwcm94eSBhbmQgY2FjaGluZyBjYXBhYmlsaXRpZXMuCgogICBvICBPcHRpb25h bCByZXNvdXJjZSBkaXNjb3ZlcnkuCgoxLjIuICBUZXJtaW5vbG9neQoKICAgVGhlIGtleSB3b3Jk cyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLAog ICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kICJPUFRJ T05BTCIgaW4gdGhpcwogICBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3Jp YmVkIGluIFtSRkMyMTE5XS4KCiAgIFRoaXMgc3BlY2lmaWNhdGlvbiByZXF1aXJlcyByZWFkZXJz IHRvIGJlIGZhbWlsaWFyIHdpdGggYWxsIHRoZSB0ZXJtcwogICBhbmQgY29uY2VwdHMgdGhhdCBh cmUgZGlzY3Vzc2VkIGluIFtSRkMyNjE2XS4gIEluIGFkZGl0aW9uLCB0aGlzCiAgIHNwZWNpZmlj YXRpb24gZGVmaW5lcyB0aGUgZm9sbG93aW5nIHRlcm1pbm9sb2d5OgoKICAgUGlnZ3ktYmFja2Vk IFJlc3BvbnNlCiAgICAgIEEgUGlnZ3ktYmFja2VkIFJlc3BvbnNlIGlzIGluY2x1ZGVkIHJpZ2h0 IGluIGEgQ29BUAogICAgICBBY2tub3dsZWRnZW1lbnQgKEFDSykgbWVzc2FnZSB0aGF0IGlzIHNl bnQgdG8gYWNrbm93bGVkZ2UgcmVjZWlwdAogICAgICBvZiB0aGUgUmVxdWVzdCBmb3IgdGhpcyBS ZXNwb25zZSAoU2VjdGlvbiA1LjIuMSkuCgogICBTZXBhcmF0ZSBSZXNwb25zZQogICAgICBXaGVu IGEgQ29uZmlybWFibGUgbWVzc2FnZSBjYXJyeWluZyBhIFJlcXVlc3QgaXMgYWNrbm93bGVkZ2Vk IHdpdGgKICAgICAgYW4gZW1wdHkgbWVzc2FnZSAoZS5nLiwgYmVjYXVzZSB0aGUgc2VydmVyIGRv ZXNuJ3QgaGF2ZSB0aGUgYW5zd2VyCiAgICAgIHJpZ2h0IGF3YXkpLCBhIFNlcGFyYXRlIFJlc3Bv bnNlIGlzIHNlbnQgaW4gYSBzZXBhcmF0ZSBtZXNzYWdlCiAgICAgIGV4Y2hhbmdlIChTZWN0aW9u IDUuMi4yKS4KCiAgIENyaXRpY2FsIE9wdGlvbgogICAgICBBbiBvcHRpb24gdGhhdCB3b3VsZCBu ZWVkIHRvIGJlIHVuZGVyc3Rvb2QgYnkgdGhlIGVuZC1wb2ludAogICAgICByZWNlaXZpbmcgdGhl IG1lc3NhZ2UgaW4gb3JkZXIgdG8gcHJvcGVybHkgcHJvY2VzcyB0aGUgbWVzc2FnZQogICAgICAo U2VjdGlvbiA1LjQuMSkuICBOb3RlIHRoYXQgdGhlIGltcGxlbWVudGF0aW9uIG9mIGNyaXRpY2Fs IG9wdGlvbnMKICAgICAgaXMsIGFzIHRoZSBuYW1lICJPcHRpb24iIGltcGxpZXMsIGdlbmVyYWxs eSBvcHRpb25hbDogdW5zdXBwb3J0ZWQKICAgICAgY3JpdGljYWwgb3B0aW9ucyBsZWFkIHRvIHJl amVjdGlvbiBvZiB0aGUgbWVzc2FnZS4KCiAgIEVsZWN0aXZlIE9wdGlvbgogICAgICBBbiBvcHRp b24gdGhhdCBpcyBpbnRlbmRlZCBiZSBpZ25vcmVkIGJ5IGFuIGVuZC1wb2ludCB0aGF0IGRvZXMK ICAgICAgbm90IHVuZGVyc3RhbmQgaXQsIHdoaWNoIG5vbmV0aGVsZXNzIHN0aWxsIGNhbiBjb3Jy ZWN0bHkgcHJvY2VzcwogICAgICB0aGUgbWVzc2FnZSAoU2VjdGlvbiA1LjQuMSkuCgogICBSZXNv dXJjZSBEaXNjb3ZlcnkKICAgICAgVGhlIHByb2Nlc3Mgd2hlcmUgYSBDb0FQIGNsaWVudCBxdWVy aWVzIGEgc2VydmVyIGZvciBpdHMgbGlzdCBvZgogICAgICBob3N0ZWQgcmVzb3VyY2VzIChpLmUu LCBsaW5rcywgU2VjdGlvbiA3LjEpLgoKICAgSW50ZXJtZWRpYXJ5CiAgICAgIHtBbiBpbnRlcm1l ZGlhcnkgaXMgYSAuLi53aGF0PyBXZSBzaG91bGQgc2F5IHdoYXQgdGhleSBhcmUgYmVmb3JlCiAg ICAgIHRhbGtpbmcgYWJvdXQgdHdvIGNvbW1vbiBmb3JtcyBvZiB0aGVtLn0KICAgICAgVGhlcmUg YXJlIHR3byBjb21tb24gZm9ybXMgb2YgaW50ZXJtZWRpYXJ5OiBwcm94eSBhbmQgcmV2ZXJzZQog ICAgICBwcm94eS4gIEluIHNvbWUgY2FzZXMsIGEgc2luZ2xlIGludGVybWVkaWFyeSBtaWdodCBh Y3QgYXMgYW4KICAgICAgb3JpZ2luIHNlcnZlciwgcHJveHksIG9yIHJldmVyc2UgcHJveHksIHN3 aXRjaGluZyBiZWhhdmlvciBiYXNlZAogICAgICBvbiB0aGUgbmF0dXJlIG9mIGVhY2ggcmVxdWVz dC4KCgoKU2hlbGJ5LCBldCBhbC4gICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAxNSwgMjAxMSAg ICAgICAgICAgICAgIFtQYWdlIDZdCgwKSW50ZXJuZXQtRHJhZnQgICBDb25zdHJhaW5lZCBBcHBs aWNhdGlvbiBQcm90b2NvbCAoQ29BUCkgICAgICBNYXJjaCAyMDExCgoKICAgUHJveHkKICAgICAg QSAicHJveHkiIGlzIGFuIGVuZC1wb2ludCBzZWxlY3RlZCBieSBhIGNsaWVudCwgdXN1YWxseSB2 aWEgbG9jYWwKICAgICAgY29uZmlndXJhdGlvbiBydWxlcywgdG8gcGVyZm9ybSByZXF1ZXN0cyBv biBiZWhhbGYgb2YgdGhlIGNsaWVudCwKICAgICAgZG9pbmcgYW55IG5lY2Vzc2FyeSB0cmFuc2xh dGlvbnMuICBTb21lIHRyYW5zbGF0aW9ucyBhcmUgbWluaW1hbCwKICAgICAgc3VjaCBhcyBmb3Ig cHJveHkgcmVxdWVzdHMgZm9yICJjb2FwIiBVUklzLCB3aGVyZWFzIG90aGVyIHJlcXVlc3RzCiAg ICAgIG1pZ2h0IHJlcXVpcmUgdHJhbnNsYXRpb24gdG8gYW5kIGZyb20gZW50aXJlbHkgZGlmZmVy ZW50CiAgICAgIGFwcGxpY2F0aW9uLWxheWVyIHByb3RvY29scy4KCiAgIFJldmVyc2UgUHJveHkK ICAgICAgQSAicmV2ZXJzZSBwcm94eSIgaXMgYW4gZW5kLXBvaW50IHRoYXQgYWN0cyBhcyBhIGxh eWVyIGFib3ZlIHNvbWUKICAgICAgb3RoZXIgc2VydmVyKHMpIGFuZCBzYXRpc2ZpZXMgcmVxdWVz dHMgb24gYmVoYWxmIG9mIHRoZXNlLCBkb2luZwogICAgICBhbnkgbmVjZXNzYXJ5IHRyYW5zbGF0 aW9ucy4gIFVubGlrZSBhIHByb3h5LCBhIHJldmVyc2UgcHJveHkKICAgICAgcmVjZWl2ZXMgcmVx dWVzdHMgYXMgaWYgaXQgd2FzIHRoZSBvcmlnaW4gc2VydmVyIGZvciB0aGUgdGFyZ2V0CiAgICAg IHJlc291cmNlOyB0aGUgcmVxdWVzdGluZyBjbGllbnQgd2lsbCBub3QgYmUgYXdhcmUgdGhhdCBp dCBpcwogICAgICBjb21tdW5pY2F0aW5nIHdpdGggYSByZXZlcnNlIHByb3h5LgoKICAgSW4gdGhp cyBzcGVjaWZpY2F0aW9uLCB0aGUgdGVybSAiYnl0ZSIgaXMgdXNlZCBpbiBpdHMgbm93IGN1c3Rv bWFyeQogICBzZW5zZSBhcyBhIHN5bm9ueW0gZm9yICJvY3RldCIuCgogICBJbiB0aGlzIHNwZWNp ZmljYXRpb24sIHRoZSBvcGVyYXRvciAiXiIgc3RhbmRzIGZvciBleHBvbmVudGlhdGlvbi4KCgoy LiAgQ29uc3RyYWluZWQgQXBwbGljYXRpb24gUHJvdG9jb2wKCiAgIFRoZSBpbnRlcmFjdGlvbiBt b2RlbCBvZiBDb0FQIGlzIHNpbWlsYXIgdG8gdGhlIGNsaWVudC9zZXJ2ZXIgbW9kZWwKICAgb2Yg SFRUUC4gIEhvd2V2ZXIsIG1hY2hpbmUtdG8tbWFjaGluZSBpbnRlcmFjdGlvbnMgdHlwaWNhbGx5 IHJlc3VsdAogICBpbiBhIENvQVAgaW1wbGVtZW50YXRpb24gYWN0aW5nIGluIGJvdGggY2xpZW50 IGFuZCBzZXJ2ZXIgcm9sZXMKICAgKGNhbGxlZCBhbiBlbmQtcG9pbnQpLiAgQSBDb0FQIHJlcXVl c3QgaXMgZXF1aXZhbGVudCB0byB0aGF0IG9mIEhUVFAsCiAgIGFuZCBpcyBzZW50IGJ5IGEgY2xp ZW50IHRvIHJlcXVlc3QgYW4gYWN0aW9uICh1c2luZyBhIG1ldGhvZCBjb2RlKSBvbgogICBhIHJl c291cmNlIChpZGVudGlmaWVkIGJ5IGEgVVJJKSBvbiBhIHNlcnZlci4gIFRoZSBzZXJ2ZXIgdGhl biBzZW5kcwogICBhIHJlc3BvbnNlIHdpdGggYSByZXNwb25zZSBjb2RlOyB0aGlzIHJlc3BvbnNl IG1heSBpbmNsdWRlIGEgcmVzb3VyY2UKICAgcmVwcmVzZW50YXRpb24uCiAgIAogICB7SSBhbSBn b2luZyB0byBhbm5veSBwZW9wbGUgYnkgYmVpbmcgcGVkYW50aWMgaGVyZS4gVGhpcyBkb2N1bWVu dCB1c2VzIAogICB0aGUgdGVybXMgImVuZC1wb2ludCIsICJub2RlIiBhbmQgImRldmljZSIgZmFp cmx5IGludGVyY2hhbmdlYWJseS4gCiAgIEkgaGF2ZSBqdXN0IGJlZW4gcmUtcmVhZGluZyB0aGUg Q29SRSBjaGFydGVyIHdoaWNoIHNheXMgIlRoZSBnZW5lcmFsIAogICBhcmNoaXRlY3R1cmUgY29u c2lzdHMgb2Ygbm9kZXMgb24gdGhlIGNvbnN0cmFpbmVkIG5ldHdvcmssIGNhbGxlZCAKICAgRGV2 aWNlcy4iIChub3RlIHRoZSB1cHBlciBjYXNlICJEIi4pIENhbiBJIHN1Z2dlc3QgdGhhdCBhIG1p bmltYWwgc2V0IG9mIHRlcm1zIAogICBhcmUgY2hvc2VuIGFuZCB1c2VkIHRocm91Z2hvdXQ/IExl dCdzIGRlZmluZSB3aGF0IHdlIG1lYW4gYnkKICAgdGhlc2UgdGVybXMgaW4gdGhlIFRlcm1pbm9s b2d5IHNlY3Rpb24uIE90aGVyd2lzZSB3ZSBiZWcgcXVlc3Rpb25zIAogICBsaWtlICJ3aGF0IGlz IHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gYSBkZXZpY2UgYW5kIGFuIGVuZC1wb2ludD8iCiAgIEFs c28gLSBTZWN0aW9uIDIuMyB0YWxrcyBhYm91dCAiZW5kLXBvaW50IG9yIGFuIGludGVybWVkaWFy eSIgYXMgCiAgIHRob3VnaCB0aGV5IGFyZSBkaWZmZXJlbnQuIEJ1dCB0aGUgVGVybWlub2xvZ3kg c2VjdGlvbiBzYXlzIGEgcHJveHkgCiAgIGlzIGFuIGludGVybWVkaWFyeSwgYW5kIGFsc28gc2F5 cyB0aGF0IGEgcHJveHkgaXMgYW4gZW5kLXBvaW50LiAKICAgU28gd2hhdCBkaXN0aW5jdGlvbnMg bmVlZCBiZSBtYWRlIGJldHdlZW4gaW50ZXJtZWRpYXJpZXMgYW5kIGVuZC1wb2ludHM/fQoKICAg VW5saWtlIEhUVFAsIENvQVAgZGVhbHMgd2l0aCB0aGVzZSBpbnRlcmNoYW5nZXMgYXN5bmNocm9u b3VzbHkgb3ZlciBhCiAgIGRhdGFncmFtLW9yaWVudGVkIHRyYW5zcG9ydCBzdWNoIGFzIFVEUC4g IFRoaXMgaXMgZG9uZSB1c2luZyBhIGxheWVyCiAgIG9mIG1lc3NhZ2VzIHRoYXQgc3VwcG9ydHMg b3B0aW9uYWwgcmVsaWFiaWxpdHkgKHdpdGggZXhwb25lbnRpYWwKICAgYmFjay1vZmYpLiAgQ29B UCBkZWZpbmVzIGZvdXIgdHlwZXMgb2YgbWVzc2FnZXM6IENvbmZpcm1hYmxlLCBOb24tCiAgIENv bmZpcm1hYmxlLCBBY2tub3dsZWRnZW1lbnQsIFJlc2V0OyBtZXRob2QgY29kZXMgYW5kIHJlc3Bv bnNlIGNvZGVzCiAgIGluY2x1ZGVkIGluIHNvbWUgb2YgdGhlc2UgbWVzc2FnZXMgbWFrZSB0aGVt IGNhcnJ5IHJlcXVlc3RzIG9yCiAgIHJlc3BvbnNlcy4gIFRoZSBiYXNpYyBleGNoYW5nZXMgb2Yg dGhlIGZvdXIgdHlwZXMgb2YgbWVzc2FnZXMgYXJlCiAgIHRyYW5zcGFyZW50IHRvIHRoZSByZXF1 ZXN0L3Jlc3BvbnNlIGludGVyYWN0aW9ucy4KCiAgIE9uZSBjb3VsZCB0aGluayBvZiBDb0FQIGFz IHVzaW5nIGEgdHdvLWxheWVyIGFwcHJvYWNoLCBhIENvQVAKICAgbWVzc2FnaW5nIGxheWVyIHVz ZWQgdG8gZGVhbCB3aXRoIFVEUCBhbmQgdGhlIGFzeW5jaHJvbm91cyBuYXR1cmUgb2YKICAgdGhl IGludGVyYWN0aW9ucywgYW5kIHRoZSByZXF1ZXN0L3Jlc3BvbnNlIGludGVyYWN0aW9ucyB1c2lu ZyBNZXRob2QKICAgYW5kIFJlc3BvbnNlIGNvZGVzIChzZWUgRmlndXJlIDEpLgoKCgoKClNoZWxi eSwgZXQgYWwuICAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMTUsIDIwMTEgICAgICAgICAgICAg ICBbUGFnZSA3XQoMCkludGVybmV0LURyYWZ0ICAgQ29uc3RyYWluZWQgQXBwbGljYXRpb24gUHJv dG9jb2wgKENvQVApICAgICAgTWFyY2ggMjAxMQoKCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwg ICAgICBBcHBsaWNhdGlvbiAgICAgfAogICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0t LS0tLS0tLS0tLS0tLS0tLS0rCiAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0t LS0tLS0tLS0tLS0tLSsKICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgIFJlcXVlc3RzL1Jl c3BvbnNlcyAgfAogICAgICAgICAgICAgICAgICAgICAgICAgICAgfC0tLS0tLS0tLS0tLS0tLS0t LS0tLS18ICBDb0FQCiAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgIE1lc3NhZ2Vz ICAgICAgIHwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0t LS0tKwogICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0r CiAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgIFVEUCAgICAgICAgIHwKICAg ICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwoKICAgICAg ICAgICAgICAgICAgICBGaWd1cmUgMTogQWJzdHJhY3QgbGF5ZXJpbmcgb2YgQ29BUAoKMi4xLiAg TWVzc2FnaW5nIE1vZGVsCgogICBUaGUgQ29BUCBtZXNzYWdpbmcgbW9kZWwgaXMgYmFzZWQgb24g dGhlIGV4Y2hhbmdlIG9mIG1lc3NhZ2VzIG92ZXIKICAgVURQIGJldHdlZW4gZW5kLXBvaW50cy4K CiAgIENvQVAgdXNlcyBhIHNob3J0IGZpeGVkLWxlbmd0aCBiaW5hcnkgaGVhZGVyICg0IGJ5dGVz KSB0aGF0IG1heSBiZQogICBmb2xsb3dlZCBieSBjb21wYWN0IGJpbmFyeSBvcHRpb25zIGFuZCBh IHBheWxvYWQuICBUaGlzIG1lc3NhZ2UKICAgZm9ybWF0IGlzIHNoYXJlZCBieSByZXF1ZXN0cyBh bmQgcmVzcG9uc2VzLiAgVGhlIENvQVAgbWVzc2FnZSBmb3JtYXQKICAgaXMgc3BlY2lmaWVkIGlu IFNlY3Rpb24gMy4gIEVhY2ggbWVzc2FnZSBjb250YWlucyBhIE1lc3NhZ2UgSUQgdXNlZAogICB0 byBkZXRlY3QgZHVwbGljYXRlcyBhbmQgZm9yIG9wdGlvbmFsIHJlbGlhYmlsaXR5LgoKICAgUmVs aWFiaWxpdHkgaXMgcHJvdmlkZWQgYnkgbWFya2luZyBhIG1lc3NhZ2UgYXMgQ29uZmlybWFibGUg KENPTikuICBBCiAgIENvbmZpcm1hYmxlIG1lc3NhZ2UgaXMgcmV0cmFuc21pdHRlZCB1c2luZyBh IGRlZmF1bHQgdGltZW91dCBhbmQKICAgZXhwb25lbnRpYWwgYmFjay1vZmYgYmV0d2VlbiByZXRy YW5zbWlzc2lvbnMsIHVudGlsIHRoZSByZWNpcGllbnQKICAgc2VuZHMgYW4gQWNrbm93bGVkZ2Vt ZW50IG1lc3NhZ2UgKEFDSykgd2l0aCB0aGUgc2FtZSBNZXNzYWdlIElEIChmb3IKICAgZXhhbXBs ZSwgMHg3ZDM0KTsgc2VlIEZpZ3VyZSAyLiAgV2hlbiBhIHJlY2lwaWVudCBpcyBub3QgYWJsZSB0 bwogICBwcm9jZXNzIGEgQ29uZmlybWFibGUgbWVzc2FnZSwgaXQgcmVwbGllcyB3aXRoIGEgUmVz ZXQgbWVzc2FnZSAoUlNUKQogICBpbnN0ZWFkIG9mIGFuIEFja25vd2xlZGdlbWVudCAoQUNLKS4K CiAgIENsaWVudCAgICAgICAgICAgICAgU2VydmVyCiAgICAgIHwgICAgICAgICAgICAgICAgICB8 CiAgICAgIHwgICBDT04gWzB4N2QzNF0gICB8CiAgICAgICstLS0tLS0tLS0tLS0tLS0tLT58CiAg ICAgIHwgICAgICAgICAgICAgICAgICB8CiAgICAgIHwgICBBQ0sgWzB4N2QzNF0gICB8CiAgICAg IHw8LS0tLS0tLS0tLS0tLS0tLS0rCiAgICAgIHwgICAgICAgICAgICAgICAgICB8CgogICAgICAg ICAgICAgICAgICAgIEZpZ3VyZSAyOiBSZWxpYWJsZSBtZXNzYWdlIGRlbGl2ZXJ5CgogICBBIG1l c3NhZ2UgdGhhdCBkb2VzIG5vdCByZXF1aXJlIHJlbGlhYmxlIGRlbGl2ZXJ5LCBmb3IgZXhhbXBs ZSBlYWNoCiAgIHNpbmdsZSBtZWFzdXJlbWVudCBvdXQgb2YgYSBzdHJlYW0gb2Ygc2Vuc29yIGRh dGEsIGNhbiBiZSBzZW50IGFzIGEKICAgTm9uLWNvbmZpcm1hYmxlIG1lc3NhZ2UgKE5PTikuICBU aGVzZSBhcmUgbm90IGFja25vd2xlZGdlZCwgYnV0IHN0aWxsCiAgIGhhdmUgYSBNZXNzYWdlIElE IGZvciBkdXBsaWNhdGUgZGV0ZWN0aW9uIChGaWd1cmUgMykuCgoKClNoZWxieSwgZXQgYWwuICAg ICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMTUsIDIwMTEgICAgICAgICAgICAgICBbUGFnZSA4XQoM CkludGVybmV0LURyYWZ0ICAgQ29uc3RyYWluZWQgQXBwbGljYXRpb24gUHJvdG9jb2wgKENvQVAp ICAgICAgTWFyY2ggMjAxMQoKCiAgIENsaWVudCAgICAgICAgICAgICAgU2VydmVyCiAgICAgIHwg ICAgICAgICAgICAgICAgICB8CiAgICAgIHwgICBOT04gWzB4MDFhMF0gICB8CiAgICAgICstLS0t LS0tLS0tLS0tLS0tLT58CiAgICAgIHwgICAgICAgICAgICAgICAgICB8CgogICAgICAgICAgICAg ICAgICAgRmlndXJlIDM6IFVucmVsaWFibGUgbWVzc2FnZSBkZWxpdmVyeQoKICAgU2VlIFNlY3Rp b24gNCBmb3IgZGV0YWlscyBvZiBDb0FQIG1lc3NhZ2VzLgoKICAgQXMgQ29BUCBpcyBiYXNlZCBv biBVRFAsIGl0IGFsc28gc3VwcG9ydHMgdGhlIHVzZSBvZiBtdWx0aWNhc3QgSVAKICAgZGVzdGlu YXRpb24gYWRkcmVzc2VzLCBlbmFibGluZyBtdWx0aWNhc3QgQ29BUCByZXF1ZXN0cy4gIFNlY3Rp b24gNC40CiAgIGRpc2N1c3NlcyB0aGUgcHJvcGVyIHVzZSBvZiBDb0FQIG1lc3NhZ2VzIHdpdGgg bXVsdGljYXN0IGFkZHJlc3NlcwogICBhbmQgcHJlY2F1dGlvbnMgZm9yIGF2b2lkaW5nIHJlc3Bv bnNlIGNvbmdlc3Rpb24uCgogICBTZXZlcmFsIHNlY3VyaXR5IG1vZGVzIGFyZSBkZWZpbmVkIGZv ciBDb0FQIGluIFNlY3Rpb24gMTAgcmFuZ2luZwogICBmcm9tIG5vIHNlY3VyaXR5IHRvIGNlcnRp ZmljYXRlLWJhc2VkIHNlY3VyaXR5LiAgVGhlIHVzZSBvZiBJUHNlYwogICBhbG9uZyB3aXRoIGEg YmluZGluZyB0byBEVExTIGFyZSBzcGVjaWZpZWQgZm9yIHNlY3VyaW5nIHRoZSBwcm90b2NvbC4K CjIuMi4gIFJlcXVlc3QvUmVzcG9uc2UgTW9kZWwKCiAgIENvQVAgcmVxdWVzdCBhbmQgcmVzcG9u c2Ugc2VtYW50aWNzIGFyZSBjYXJyaWVkIGluIENvQVAgbWVzc2FnZXMsCiAgIHdoaWNoIGluY2x1 ZGUgZWl0aGVyIGEgbWV0aG9kIGNvZGUgb3IgcmVzcG9uc2UgY29kZSwgcmVzcGVjdGl2ZWx5Lgog ICBPcHRpb25hbCAob3IgZGVmYXVsdCkgcmVxdWVzdCBhbmQgcmVzcG9uc2UgaW5mb3JtYXRpb24s IHN1Y2ggYXMgdGhlCiAgIFVSSSBhbmQgcGF5bG9hZCBjb250ZW50LXR5cGUgYXJlIGNhcnJpZWQg YXMgQ29BUCBvcHRpb25zLiAgQSBUb2tlbgogICBPcHRpb24gaXMgdXNlZCB0byBtYXRjaCByZXNw b25zZXMgdG8gcmVxdWVzdHMgaW5kZXBlbmRlbnRseSBmcm9tIHRoZQogICB1bmRlcmx5aW5nIG1l c3NhZ2VzIChTZWN0aW9uIDUuMykuCgogICBBIHJlcXVlc3QgaXMgY2FycmllZCBpbiBhIENvbmZp cm1hYmxlIChDT04pIG9yIE5vbi1jb25maXJtYWJsZSAoTk9OKQogICBtZXNzYWdlLCBhbmQgaWYg aW1tZWRpYXRlbHkgYXZhaWxhYmxlLCB0aGUgcmVzcG9uc2UgdG8gYSByZXF1ZXN0CiAgIGNhcnJp ZWQgaW4gYSBDb25maXJtYWJsZSBtZXNzYWdlIGlzIGNhcnJpZWQgaW4gdGhlIHJlc3VsdGluZwog ICBBY2tub3dsZWRnZW1lbnQgKEFDSykgbWVzc2FnZS4gIFRoaXMgaXMgY2FsbGVkIGEgcGlnZ3kt YmFja2VkCiAgIHJlc3BvbnNlLCBkZXRhaWxlZCBpbiBTZWN0aW9uIDUuMi4xLiAgVHdvIGV4YW1w bGVzIGZvciBhIGJhc2ljIEdFVAogICByZXF1ZXN0IHdpdGggcGlnZ3ktYmFja2VkIHJlc3BvbnNl IGFyZSBzaG93biBpbiBGaWd1cmUgNC4KCgoKCgoKCgoKCgoKCgoKCgpTaGVsYnksIGV0IGFsLiAg ICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDE1LCAyMDExICAgICAgICAgICAgICAgW1BhZ2UgOV0K DApJbnRlcm5ldC1EcmFmdCAgIENvbnN0cmFpbmVkIEFwcGxpY2F0aW9uIFByb3RvY29sIChDb0FQ KSAgICAgIE1hcmNoIDIwMTEKCgogICBDbGllbnQgICAgICAgICAgICAgIFNlcnZlciAgICAgICBD bGllbnQgICAgICAgICAgICAgIFNlcnZlcgogICAgICB8ICAgICAgICAgICAgICAgICAgfCAgICAg ICAgICAgICB8ICAgICAgICAgICAgICAgICAgfAogICAgICB8ICAgQ09OIFsweGJjOTBdICAgfCAg ICAgICAgICAgICB8ICAgQ09OIFsweGJjOTFdICAgfAogICAgICB8IEdFVCAvdGVtcGVyYXR1cmUg fCAgICAgICAgICAgICB8IEdFVCAvdGVtcGVyYXR1cmUgfAogICAgICB8ICAgKFRva2VuIDB4NzEp ICAgfCAgICAgICAgICAgICB8ICAgKFRva2VuIDB4NzIpICAgfAogICAgICArLS0tLS0tLS0tLS0t LS0tLS0+fCAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0+fAogICAgICB8ICAgICAgICAg ICAgICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgfAogICAgICB8ICAgQUNL IFsweGJjOTBdICAgfCAgICAgICAgICAgICB8ICAgQUNLIFsweGJjOTFdICAgfAogICAgICB8ICAg Mi4wNSBDb250ZW50ICAgfCAgICAgICAgICAgICB8ICA0LjA0IE5vdCBGb3VuZCAgfAogICAgICB8 ICAgKFRva2VuIDB4NzEpICAgfCAgICAgICAgICAgICB8ICAgKFRva2VuIDB4NzIpICAgfAogICAg ICB8ICAgICAiMjIuNSBDIiAgICAgfCAgICAgICAgICAgICB8ICAgIk5vdCBmb3VuZCIgICAgfAog ICAgICB8PC0tLS0tLS0tLS0tLS0tLS0tKyAgICAgICAgICAgICB8PC0tLS0tLS0tLS0tLS0tLS0t KwogICAgICB8ICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgICAg ICAgfAoKICAgICAgICBGaWd1cmUgNDogVHdvIEdFVCByZXF1ZXN0cyB3aXRoIHBpZ2d5LWJhY2tl ZCByZXNwb25zZXMsIG9uZQogICAgICAgICAgICAgICAgICAgICAgICAgc3VjY2Vzc2Z1bCwgb25l IG5vdCBmb3VuZAoKICAgSWYgdGhlIHNlcnZlciBpcyBub3QgYWJsZSB0byByZXNwb25kIGltbWVk aWF0ZWx5IHRvIGEgcmVxdWVzdCBjYXJyaWVkCiAgIGluIGEgQ29uZmlybWFibGUgbWVzc2FnZSwg aXQgc2ltcGx5IHJlc3BvbmRzIHdpdGggYW4gZW1wdHkKICAgQWNrbm93bGVkZ2VtZW50IG1lc3Nh Z2Ugc28gdGhhdCB0aGUgY2xpZW50IGNhbiBzdG9wIHJldHJhbnNtaXR0aW5nCiAgIHRoZSByZXF1 ZXN0LiAgV2hlbiB0aGUgcmVzcG9uc2UgaXMgcmVhZHksIHRoZSBzZXJ2ZXIgc2VuZHMgaXQgaW4g YQogICBuZXcgQ29uZmlybWFibGUgbWVzc2FnZSAod2hpY2ggdGhlbiBpbiB0dXJuIG5lZWRzIHRv IGJlIGFja25vd2xlZGdlZAogICBieSB0aGUgY2xpZW50KS4gIFRoaXMgaXMgY2FsbGVkIGEgc2Vw YXJhdGUgcmVzcG9uc2UsIGFzIGlsbHVzdHJhdGVkCiAgIGluIEZpZ3VyZSA1IGFuZCBkZXNjcmli ZWQgaW4gbW9yZSBkZXRhaWwgaW4gU2VjdGlvbiA1LjIuMi4KCiAgIENsaWVudCAgICAgICAgICAg ICAgU2VydmVyCiAgICAgIHwgICAgICAgICAgICAgICAgICB8CiAgICAgIHwgICBDT04gWzB4N2Ex MF0gICB8CiAgICAgIHwgR0VUIC90ZW1wZXJhdHVyZSB8CiAgICAgIHwgICAoVG9rZW4gMHg3Mykg ICB8CiAgICAgICstLS0tLS0tLS0tLS0tLS0tLT58CiAgICAgIHwgICAgICAgICAgICAgICAgICB8 CiAgICAgIHwgICBBQ0sgWzB4N2ExMF0gICB8CiAgICAgIHw8LS0tLS0tLS0tLS0tLS0tLS0rCiAg ICAgIHwgICAgICAgICAgICAgICAgICB8CiAgICAgIC4uLiBUaW1lIFBhc3NlcyAgLi4uCiAgICAg IHwgICAgICAgICAgICAgICAgICB8CiAgICAgIHwgICBDT04gWzB4MjNiYl0gICB8CiAgICAgIHwg ICAyLjA1IENvbnRlbnQgICB8CiAgICAgIHwgICAoVG9rZW4gMHg3MykgICB8CiAgICAgIHwgICAg ICIyMi41IEMiICAgICB8CiAgICAgIHw8LS0tLS0tLS0tLS0tLS0tLS0rCiAgICAgIHwgICAgICAg ICAgICAgICAgICB8CiAgICAgIHwgICBBQ0sgWzB4MjNiYl0gICB8CiAgICAgICstLS0tLS0tLS0t LS0tLS0tLT58CiAgICAgIHwgICAgICAgICAgICAgICAgICB8CgogICAgICAgICAgICAgRmlndXJl IDU6IEEgR0VUIHJlcXVlc3Qgd2l0aCBhIHNlcGFyYXRlIHJlc3BvbnNlCgoKClNoZWxieSwgZXQg YWwuICAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMTUsIDIwMTEgICAgICAgICAgICAgIFtQYWdl IDEwXQoMCkludGVybmV0LURyYWZ0ICAgQ29uc3RyYWluZWQgQXBwbGljYXRpb24gUHJvdG9jb2wg KENvQVApICAgICAgTWFyY2ggMjAxMQoKCiAgIENvQVAgbWFrZXMgdXNlIG9mIEdFVCwgUFVULCBQ T1NUIGFuZCBERUxFVEUgbWV0aG9kcyBpbiBhIHNpbWlsYXIKICAgbWFubmVyIHRvIEhUVFAsIHdp dGggdGhlIHNlbWFudGljcyBzcGVjaWZpZWQgaW4gU2VjdGlvbiA1LjguICAoTm90ZQogICB0aGF0 IHRoZSBkZXRhaWxlZCBzZW1hbnRpY3Mgb2YgQ29BUCBtZXRob2RzIGFyZSAiYWxtb3N0LCBidXQg bm90CiAgIGVudGlyZWx5IHVubGlrZSIgdGhvc2Ugb2YgSFRUUCBtZXRob2RzOiBJbnR1aXRpb24g dGFrZW4gZnJvbSBIVFRQCiAgIGV4cGVyaWVuY2UgZ2VuZXJhbGx5IGRvZXMgYXBwbHkgd2VsbCwg YnV0IHRoZXJlIGFyZSBlbm91Z2gKICAgZGlmZmVyZW5jZXMgdGhhdCBtYWtlIGl0IHdvcnRod2hp bGUgdG8gYWN0dWFsbHkgcmVhZCB0aGUgcHJlc2VudAogICBzcGVjaWZpY2F0aW9uLikKCiAgIFVS SSBzdXBwb3J0IGluIGEgc2VydmVyIGlzIHNpbXBsaWZpZWQgYXMgdGhlIGNsaWVudCBhbHJlYWR5 IHBhcnNlcwogICB0aGUgVVJJIGFuZCBzcGxpdHMgaXQgaW50byBob3N0LCBwb3J0LCBwYXRoIGFu ZCBxdWVyeSBjb21wb25lbnRzLAogICBtYWtpbmcgdXNlIG9mIGRlZmF1bHQgdmFsdWVzIGZvciBl ZmZpY2llbmN5LiAgUmVzcG9uc2UgY29kZXMKICAgY29ycmVzcG9uZCB0byBhIHNtYWxsIHN1YnNl dCBvZiBIVFRQIHJlc3BvbnNlIGNvZGVzIHdpdGggYSBmZXcgQ29BUAogICBzcGVjaWZpYyBjb2Rl cyBhZGRlZCwgYXMgZGVmaW5lZCBpbiBTZWN0aW9uIDUuOS4KCjIuMy4gIEludGVybWVkaWFyaWVz IGFuZCBDYWNoaW5nCgogICBUaGUgcHJvdG9jb2wgc3VwcG9ydHMgdGhlIGNhY2hpbmcgb2YgcmVz cG9uc2VzIGluIG9yZGVyIHRvCiAgIGVmZmljaWVudGx5IGZ1bGZpbGwgcmVxdWVzdHMuICBTaW1w bGUgY2FjaGluZyBpcyBlbmFibGVkIHVzaW5nCiAgIGZyZXNobmVzcyBhbmQgdmFsaWRpdHkgaW5m b3JtYXRpb24gY2FycmllZCB3aXRoIENvQVAgcmVzcG9uc2VzLiAgQQogICBjYWNoZSBjb3VsZCBi ZSBsb2NhdGVkIGluIGFuIGVuZC1wb2ludCBvciBhbiBpbnRlcm1lZGlhcnkuICBDYWNoaW5nCiAg IGZ1bmN0aW9uYWxpdHkgaXMgc3BlY2lmaWVkIGluIFNlY3Rpb24gNS42LgoKICAgUHJveHlpbmcg aXMgdXNlZnVsIGluIGNvbnN0cmFpbmVkIG5ldHdvcmtzIGZvciBzZXZlcmFsIHJlYXNvbnMsCiAg IGluY2x1ZGluZyBuZXR3b3JrIHRyYWZmaWMgbGltaXRpbmcsIHRvIGltcHJvdmUgcGVyZm9ybWFu Y2UsIHRvIGFjY2VzcwogICByZXNvdXJjZXMgb2Ygc2xlZXBpbmcgZGV2aWNlcyBvciBmb3Igc2Vj dXJpdHkgcmVhc29ucy4gIFRoZSBwcm94eWluZwogICBvZiByZXF1ZXN0cyBvbiBiZWhhbGYgb2Yg YW5vdGhlciBDb0FQIGVuZC1wb2ludCBpcyBzdXBwb3J0ZWQgaW4gdGhlCiAgIHByb3RvY29sLiAg VGhlIFVSSSBvZiB0aGUgcmVzb3VyY2UgdG8gcmVxdWVzdCBpcyBpbmNsdWRlZCBpbiB0aGUKICAg cmVxdWVzdCwgd2hpbGUgdGhlIGRlc3RpbmF0aW9uIElQIGFkZHJlc3MgaXMgc2V0IHRvIHRoZSBw cm94eS4gIFNlZQogICBTZWN0aW9uIDUuNyBmb3IgbW9yZSBpbmZvcm1hdGlvbiBvbiBwcm94eSBm dW5jdGlvbmFsaXR5LgoKICAgQXMgQ29BUCB3YXMgZGVzaWduZWQgYWNjb3JkaW5nIHRvIHRoZSBS RVNUIGFyY2hpdGVjdHVyZSBhbmQgdGh1cwogICBleGhpYml0cyBmdW5jdGlvbmFsaXR5IHNpbWls YXIgdG8gdGhhdCBvZiB0aGUgSFRUUCBwcm90b2NvbCwgaXQgaXMKICAgcXVpdGUgc3RyYWlnaHRm b3J3YXJkIHRvIG1hcCBiZXR3ZWVuIEhUVFAtQ29BUCBvciBDb0FQLUhUVFAuICBTdWNoIGEKICAg bWFwcGluZyBtYXkgYmUgdXNlZCB0byByZWFsaXplIGFuIEhUVFAgUkVTVCBpbnRlcmZhY2UgdXNp bmcgQ29BUCwgb3IKICAgZm9yIGNvbnZlcnRpbmcgYmV0d2VlbiBIVFRQIGFuZCBDb0FQLiAgVGhp cyBjb252ZXJzaW9uIGNhbiBiZSBjYXJyaWVkCiAgIG91dCBieSBhIHByb3h5LCB3aGljaCBjb252 ZXJ0cyB0aGUgbWV0aG9kIG9yIHJlc3BvbnNlIGNvZGUsIGNvbnRlbnQtCiAgIHR5cGUgYW5kIG9w dGlvbnMgdG8gdGhlIGNvcnJlc3BvbmRpbmcgSFRUUCBmZWF0dXJlLiAgU2VjdGlvbiA4CiAgIHBy b3ZpZGVzIG1vcmUgZGV0YWlsIGFib3V0IEhUVFAgbWFwcGluZy4KCjIuNC4gIFJlc291cmNlIERp c2NvdmVyeQoKICAgUmVzb3VyY2UgZGlzY292ZXJ5IGlzIGltcG9ydGFudCBmb3IgbWFjaGluZS10 by1tYWNoaW5lIGludGVyYWN0aW9ucywKICAgYW5kIGlzIHN1cHBvcnRlZCB1c2luZyB0aGUgQ29S RSBMaW5rIEZvcm1hdAogICBbSS1ELmlldGYtY29yZS1saW5rLWZvcm1hdF0gYXMgZGlzY3Vzc2Vk IGluIFNlY3Rpb24gNy4xLgoKCgoKCgoKU2hlbGJ5LCBldCBhbC4gICAgICAgICBFeHBpcmVzIFNl cHRlbWJlciAxNSwgMjAxMSAgICAgICAgICAgICAgW1BhZ2UgMTFdCgwKSW50ZXJuZXQtRHJhZnQg ICBDb25zdHJhaW5lZCBBcHBsaWNhdGlvbiBQcm90b2NvbCAoQ29BUCkgICAgICBNYXJjaCAyMDEx CgoKMy4gIE1lc3NhZ2UgU3ludGF4CgogICBDb0FQIGlzIGJhc2VkIG9uIHRoZSBleGNoYW5nZSBv ZiBzaG9ydCBtZXNzYWdlcyB3aGljaCwgYnkgZGVmYXVsdCwKICAgYXJlIHRyYW5zcG9ydGVkIG92 ZXIgVURQIChpLmUuIGVhY2ggQ29BUCBtZXNzYWdlIG9jY3VwaWVzIHRoZSBkYXRhCiAgIHNlY3Rp b24gb2Ygb25lIFVEUCBkYXRhZ3JhbSkuICBDb0FQIG1heSBiZSB1c2VkIHdpdGggRGF0YWdyYW0K ICAgVHJhbnNwb3J0IExheWVyIFNlY3VyaXR5IChEVExTKSAoc2VlIFNlY3Rpb24gMTAuMikuICBJ dCBjb3VsZCBhbHNvIGJlCiAgIHVzZWQgb3ZlciBvdGhlciB0cmFuc3BvcnRzIHN1Y2ggYXMgVENQ IG9yIFNDVFAsIHRoZSBzcGVjaWZpY2F0aW9uIG9mCiAgIHdoaWNoIGlzIG91dCBvZiB0aGlzIGRv Y3VtZW50J3Mgc2NvcGUuCgozLjEuICBNZXNzYWdlIEZvcm1hdAoKICAgQ29BUCBtZXNzYWdlcyBh cmUgZW5jb2RlZCBpbiBhIHNpbXBsZSBiaW5hcnkgZm9ybWF0LiAgQSBtZXNzYWdlCiAgIGNvbnNp c3RzIG9mIGEgZml4ZWQtc2l6ZWQgQ29BUCBIZWFkZXIgZm9sbG93ZWQgYnkgb3B0aW9ucyBpbiBU eXBlLQogICBMZW5ndGgtVmFsdWUgKFRMVikgZm9ybWF0IGFuZCBhIHBheWxvYWQuICBUaGUgbnVt YmVyIG9mIG9wdGlvbnMgaXMKICAgZGV0ZXJtaW5lZCBieSB0aGUgaGVhZGVyLiAgVGhlIHBheWxv YWQgaXMgbWFkZSB1cCBvZiB0aGUgYnl0ZXMgYWZ0ZXIKICAgdGhlIG9wdGlvbnMsIGlmIGFueTsg aXRzIGxlbmd0aCBpcyBjYWxjdWxhdGVkIGZyb20gdGhlIGRhdGFncmFtCiAgIGxlbmd0aC4KCiAg ICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAg ICAgICAgMwogICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAy IDMgNCA1IDYgNyA4IDkgMCAxCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHxWZXJ8IFQgfCAgT0MgICB8ICAgICAg Q29kZSAgICAgfCAgICAgICAgICBNZXNzYWdlIElEICAgICAgICAgICB8CiAgICstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAg IHwgICBPcHRpb25zIChpZiBhbnkpIC4uLgogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICB8ICAgUGF5bG9hZCAoaWYg YW55KSAuLi4KICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSsKCiAgICAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUgNjog TWVzc2FnZSBGb3JtYXQKCiAgIFRoZSBmaWVsZHMgaW4gdGhlIGhlYWRlciBhcmUgZGVmaW5lZCBh cyBmb2xsb3dzOgoKICAgVmVyc2lvbiAoVmVyKTogIDItYml0IHVuc2lnbmVkIGludGVnZXIuICBJ bmRpY2F0ZXMgdGhlIENvQVAgdmVyc2lvbgogICAgICBudW1iZXIuICBJbXBsZW1lbnRhdGlvbnMg b2YgdGhpcyBzcGVjaWZpY2F0aW9uIE1VU1Qgc2V0IHRoaXMgZmllbGQKICAgICAgdG8gMS4gIE90 aGVyIHZhbHVlcyBhcmUgcmVzZXJ2ZWQgZm9yIGZ1dHVyZSB2ZXJzaW9ucyAoc2VlIGFsc28KICAg ICAgU2VjdGlvbiA3LjMuMSkuCgogICBUeXBlIChUKTogIDItYml0IHVuc2lnbmVkIGludGVnZXIu ICBJbmRpY2F0ZXMgaWYgdGhpcyBtZXNzYWdlIGlzIG9mCiAgICAgIHR5cGUgQ29uZmlybWFibGUg KDApLCBOb24tQ29uZmlybWFibGUgKDEpLCBBY2tub3dsZWRnZW1lbnQgKDIpIG9yCiAgICAgIFJl c2V0ICgzKS4gIFNlZSBTZWN0aW9uIDQgZm9yIHRoZSBzZW1hbnRpY3Mgb2YgdGhlc2UgbWVzc2Fn ZQogICAgICB0eXBlcy4KCiAgIE9wdGlvbiBDb3VudCAoT0MpOiAgNC1iaXQgdW5zaWduZWQgaW50 ZWdlci4gIEluZGljYXRlcyB0aGUgbnVtYmVyIG9mCiAgICAgIG9wdGlvbnMgYWZ0ZXIgdGhlIGhl YWRlci4gIElmIHNldCB0byAwLCB0aGVyZSBhcmUgbm8gb3B0aW9ucyBhbmQKICAgICAgdGhlIHBh eWxvYWQgKGlmIGFueSkgaW1tZWRpYXRlbHkgZm9sbG93cyB0aGUgaGVhZGVyLiAgVGhlIGZvcm1h dAogICAgICBvZiBvcHRpb25zIGlzIGRlZmluZWQgYmVsb3cuCgoKCgoKU2hlbGJ5LCBldCBhbC4g ICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAxNSwgMjAxMSAgICAgICAgICAgICAgW1BhZ2UgMTJd CgwKSW50ZXJuZXQtRHJhZnQgICBDb25zdHJhaW5lZCBBcHBsaWNhdGlvbiBQcm90b2NvbCAoQ29B UCkgICAgICBNYXJjaCAyMDExCgoKICAgQ29kZTogIDgtYml0IHVuc2lnbmVkIGludGVnZXIuICBJ bmRpY2F0ZXMgaWYgdGhlIG1lc3NhZ2UgY2FycmllcyBhCiAgICAgIHJlcXVlc3QgKDEtMzEpIG9y IGEgcmVzcG9uc2UgKDY0LTE5MSksIG9yIGlzIGVtcHR5ICgwKS4gIChBbGwKICAgICAgb3RoZXIg Y29kZSB2YWx1ZXMgYXJlIHJlc2VydmVkLikgIEluIGNhc2Ugb2YgYSByZXF1ZXN0LCB0aGUgQ29k ZQogICAgICBmaWVsZCBpbmRpY2F0ZXMgdGhlIFJlcXVlc3QgTWV0aG9kOyBpbiBjYXNlIG9mIGEg cmVzcG9uc2UgYQogICAgICBSZXNwb25zZSBDb2RlLiAgUG9zc2libGUgdmFsdWVzIGFyZSBtYWlu dGFpbmVkIGluIHRoZSBDb0FQIENvZGUKICAgICAgUmVnaXN0cnkgKFNlY3Rpb24gMTEuMSkuICBT ZWUgU2VjdGlvbiA1IGZvciB0aGUgc2VtYW50aWNzIG9mCiAgICAgIHJlcXVlc3RzIGFuZCByZXNw b25zZXMuCgogICBNZXNzYWdlIElEOiAgMTYtYml0IHVuc2lnbmVkIGludGVnZXIuICBVc2VkIGZv ciB0aGUgZGV0ZWN0aW9uIG9mCiAgICAgIG1lc3NhZ2UgZHVwbGljYXRpb24sIGFuZCB0byBtYXRj aCBtZXNzYWdlcyBvZiB0eXBlCiAgICAgIEFja25vd2xlZGdlbWVudC9SZXNldCBhbmQgbWVzc2Fn ZXMgb2YgdHlwZSBDb25maXJtYWJsZS4gIFNlZQogICAgICBTZWN0aW9uIDQgZm9yIE1lc3NhZ2Ug SUQgZ2VuZXJhdGlvbiBydWxlcyBhbmQgaG93IG1lc3NhZ2VzIGFyZQogICAgICBtYXRjaGVkLgoK ICAgV2hpbGUgc3BlY2lmaWMgbGluayBsYXllcnMgbWFrZSBpdCBiZW5lZmljaWFsIHRvIGtlZXAg Q29BUCBtZXNzYWdlcwogICBzbWFsbCBlbm91Z2ggdG8gZml0IGludG8gdGhlaXIgbGluayBsYXll ciBwYWNrZXRzIChzZWUgU2VjdGlvbiAxKSwKICAgdGhpcyBpcyBhIG1hdHRlciBvZiBpbXBsZW1l bnRhdGlvbiBxdWFsaXR5LiAgVGhlIENvQVAgc3BlY2lmaWNhdGlvbgogICBpdHNlbGYgcHJvdmlk ZXMgb25seSBhbiB1cHBlciBib3VuZCB0byB0aGUgbWVzc2FnZSBzaXplLiAgTWVzc2FnZXMKICAg bGFyZ2VyIHRoYW4gYW4gSVAgZnJhZ21lbnQgcmVzdWx0IGluIHVuZGVzaXJlZCBwYWNrZXQgZnJh Z21lbnRhdGlvbi4KICAgQSBDb0FQIG1lc3NhZ2UsIGFwcHJvcHJpYXRlbHkgZW5jYXBzdWxhdGVk LCBTSE9VTEQgZml0IHdpdGhpbiBhCiAgIHNpbmdsZSBJUCBwYWNrZXQgKGkuZS4sIGF2b2lkIElQ IGZyYWdtZW50YXRpb24pIGFuZCBNVVNUIGZpdCB3aXRoaW4gYQogICBzaW5nbGUgSVAgZGF0YWdy YW0uICBJZiB0aGUgUGF0aCBNVFUgaXMgbm90IGtub3duIGZvciBhIGRlc3RpbmF0aW9uLAogICBh biBJUCBNVFUgb2YgMTI4MCBieXRlcyBTSE9VTEQgYmUgYXNzdW1lZDsgaWYgbm90aGluZyBpcyBr bm93biBhYm91dAogICB0aGUgc2l6ZSBvZiB0aGUgaGVhZGVycywgZ29vZCB1cHBlciBib3VuZHMg YXJlIDExNTIgYnl0ZXMgZm9yIHRoZQogICBtZXNzYWdlIHNpemUgYW5kIDEwMjQgYnl0ZXMgZm9y IHRoZSBwYXlsb2FkIHNpemUuCgozLjEuMS4gIE1lc3NhZ2UgU2l6ZSBJbXBsZW1lbnRhdGlvbiBD b25zaWRlcmF0aW9ucwoKICAgTm90ZSB0aGF0IENvQVAncyBjaG9pY2Ugb2YgbWVzc2FnZSBzaXpl IHBhcmFtZXRlcnMgd29ya3Mgd2VsbCB3aXRoCiAgIElQdjYgYW5kIHdpdGggbW9zdCBvZiB0b2Rh eSdzIElQdjQgcGF0aHMuICAoSG93ZXZlciwgd2l0aCBJUHY0LCBpdCBpcwogICBoYXJkZXIgdG8g YWJzb2x1dGVseSBlbnN1cmUgdGhhdCB0aGVyZSBpcyBubyBJUCBmcmFnbWVudGF0aW9uLiAgSWYK ICAgSVB2NCBzdXBwb3J0IG9uIHVudXN1YWwgbmV0d29ya3MgaXMgYSBjb25zaWRlcmF0aW9uLCBp bXBsZW1lbnRhdGlvbnMKICAgbWF5IHdhbnQgdG8gbGltaXQgdGhlbXNlbHZlcyB0byBtb3JlIGNv bnNlcnZhdGl2ZSBJUHY0IGRhdGFncmFtIHNpemVzCiAgIHN1Y2ggYXMgNTc2IGJ5dGVzOyB3b3Jz ZSwgdGhlIGFic29sdXRlIG1pbmltdW0gdmFsdWUgb2YgdGhlIElQIE1UVQogICBmb3IgSVB2NCBp cyBhcyBsb3cgYXMgNjggYnl0ZXMsIHdoaWNoIHdvdWxkIGxlYXZlIG9ubHkgNDAgYnl0ZXMgbWlu dXMKICAgc2VjdXJpdHkgb3ZlcmhlYWQgZm9yIGEgVURQIHBheWxvYWQuICBJbXBsZW1lbnRhdGlv bnMgZXh0cmVtZWx5CiAgIGZvY3VzZWQgb24gdGhpcyBwcm9ibGVtIHNldCBtaWdodCBhbHNvIHNl dCB0aGUgSVB2NCBERiBiaXQgYW5kCiAgIHBlcmZvcm0gc29tZSBmb3JtIG9mIHBhdGggTVRVIGRp c2NvdmVyeTsgdGhpcyBzaG91bGQgZ2VuZXJhbGx5IGJlCiAgIHVubmVjZXNzYXJ5IGluIG1vc3Qg cmVhbGlzdGljIHVzZSBjYXNlcyBmb3IgQ29BUCwgaG93ZXZlci4pICBBIG1vcmUKICAgaW1wb3J0 YW50IGtpbmQgb2YgZnJhZ21lbnRhdGlvbiBpbiBtYW55IGNvbnN0cmFpbmVkIG5ldHdvcmtzIGlz IHRoYXQKICAgb24gdGhlIGFkYXB0YXRpb24gbGF5ZXIgKGUuZy4sIDZMb1dQQU4gTDIgcGFja2V0 cyBhcmUgbGltaXRlZCB0byAxMjcKICAgYnl0ZXMgaW5jbHVkaW5nIHZhcmlvdXMgb3ZlcmhlYWRz KTsgdGhpcyBtYXkgbW90aXZhdGUgaW1wbGVtZW50YXRpb25zCiAgIHRvIGJlIGZydWdhbCBpbiB0 aGVpciBwYWNrZXQgc2l6ZXMgYW5kIHRvIG1vdmUgdG8gYmxvY2std2lzZQogICB0cmFuc2ZlcnMg W0ktRC5pZXRmLWNvcmUtYmxvY2tdIHdoZW4gYXBwcm9hY2hpbmcgdGhyZWUtZGlnaXQgbWVzc2Fn ZQogICBzaXplcy4KCiAgIE5vdGUgdGhhdCBtZXNzYWdlIHNpemVzIGFyZSBhbHNvIG9mIGNvbnNp ZGVyYWJsZSBpbXBvcnRhbmNlIHRvCiAgIGltcGxlbWVudGF0aW9ucyBvbiBjb25zdHJhaW5lZCBu b2Rlcy4gIE1hbnkgaW1wbGVtZW50YXRpb25zIHdpbGwgbmVlZAoKCgpTaGVsYnksIGV0IGFsLiAg ICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDE1LCAyMDExICAgICAgICAgICAgICBbUGFnZSAxM10K DApJbnRlcm5ldC1EcmFmdCAgIENvbnN0cmFpbmVkIEFwcGxpY2F0aW9uIFByb3RvY29sIChDb0FQ KSAgICAgIE1hcmNoIDIwMTEKCgogICB0byBhbGxvY2F0ZSBhIGJ1ZmZlciBmb3IgaW5jb21pbmcg bWVzc2FnZXMuICBJZiBhbiBpbXBsZW1lbnRhdGlvbiBpcwogICB0b28gY29uc3RyYWluZWQgdG8g YWxsb3cgZm9yIGFsbG9jYXRpbmcgdGhlIGFib3ZlLW1lbnRpb25lZCB1cHBlcgogICBib3VuZCwg aXQgY291bGQgYXBwbHkgdGhlIGZvbGxvd2luZyBpbXBsZW1lbnRhdGlvbiBzdHJhdGVneToKICAg SW1wbGVtZW50YXRpb25zIHJlY2VpdmluZyBhIGRhdGFncmFtIGludG8gYSBidWZmZXIgdGhhdCBp cyB0b28gc21hbGwKICAgYXJlIHVzdWFsbHkgYWJsZSB0byBkZXRlcm1pbmUgaWYgdGhlIHRyYWls aW5nIHBvcnRpb24gb2YgYSBkYXRhZ3JhbQogICB3YXMgZGlzY2FyZGVkIGFuZCB0byByZXRyaWV2 ZSB0aGUgaW5pdGlhbCBwb3J0aW9uLiAgU28sIGlmIG5vdCBhbGwgb2YKICAgdGhlIHBheWxvYWQs IGF0IGxlYXN0IHRoZSBDb0FQIGhlYWRlciBhbmQgb3B0aW9ucyBhcmUgbGlrZWx5IHRvIGZpdAog ICB3aXRoaW4gdGhlIGJ1ZmZlci4gIEEgc2VydmVyIGNhbiB0aHVzIGZ1bGx5IGludGVycHJldCBh IHJlcXVlc3QgYW5kCiAgIHJldHVybiBhIDQuMTMgKFJlcXVlc3QgRW50aXR5IFRvbyBMYXJnZSkg cmVzcG9uc2UgY29kZSBpZiB0aGUgcGF5bG9hZAogICB3YXMgdHJ1bmNhdGVkLiAgQSBjbGllbnQg c2VuZGluZyBhbiBpZGVtcG90ZW50IHJlcXVlc3QgYW5kIHJlY2VpdmluZwogICBhIHJlc3BvbnNl IGxhcmdlciB0aGFuIHdvdWxkIGZpdCBpbiB0aGUgYnVmZmVyIGNhbiByZXBlYXQgdGhlIHJlcXVl c3QKICAgd2l0aCBhIHN1aXRhYmxlIHZhbHVlIGZvciB0aGUgQmxvY2sgT3B0aW9uIFtJLUQuaWV0 Zi1jb3JlLWJsb2NrXS4KCjMuMi4gIE9wdGlvbiBGb3JtYXQKCiAgIE9wdGlvbnMgTVVTVCBhcHBl YXIgaW4gb3JkZXIgb2YgdGhlaXIgT3B0aW9uIE51bWJlciAoc2VlCiAgIFNlY3Rpb24gNS40LjUp LiAgQSBkZWx0YSBlbmNvZGluZyBpcyB1c2VkIGJldHdlZW4gb3B0aW9ucywgd2l0aCB0aGUKICAg T3B0aW9uIE51bWJlciBmb3IgZWFjaCBPcHRpb24gY2FsY3VsYXRlZCBhcyB0aGUgc3VtIG9mIGl0 cyBPcHRpb24KICAgRGVsdGEgZmllbGQgYW5kIHRoZSBPcHRpb24gTnVtYmVyIG9mIHRoZSBwcmVj ZWRpbmcgT3B0aW9uIGluIHRoZQogICBtZXNzYWdlLCBpZiBhbnksIG9yIHplcm8gb3RoZXJ3aXNl LiAgTXVsdGlwbGUgb3B0aW9ucyB3aXRoIHRoZSBzYW1lCiAgIE9wdGlvbiBOdW1iZXIgY2FuIGJl IGluY2x1ZGVkIGJ5IHVzaW5nIGFuIE9wdGlvbiBEZWx0YSBvZiB6ZXJvLgogICBGb2xsb3dpbmcg dGhlIE9wdGlvbiBEZWx0YSwgZWFjaCBvcHRpb24gaGFzIGEgTGVuZ3RoIGZpZWxkIHdoaWNoCiAg IHNwZWNpZmllcyB0aGUgbGVuZ3RoIG9mIHRoZSBPcHRpb24gVmFsdWUsIGluIGJ5dGVzLiAgVGhl IExlbmd0aCBmaWVsZAogICBjYW4gYmUgZXh0ZW5kZWQgYnkgb25lIGJ5dGUgZm9yIG9wdGlvbnMg d2l0aCB2YWx1ZXMgbG9uZ2VyIHRoYW4gMTQKICAgYnl0ZXMuICBUaGUgT3B0aW9uIFZhbHVlIGlt bWVkaWF0ZWx5IGZvbGxvd3MgdGhlIExlbmd0aCBmaWVsZC4KCiAgICAgMCAgIDEgICAyICAgMyAg IDQgICA1ICAgNiAgIDcKICAgKy0tLSstLS0rLS0tKy0tLSstLS0rLS0tKy0tLSstLS0rCiAgIHwg T3B0aW9uIERlbHRhICB8ICAgIExlbmd0aCAgICAgfCBmb3IgMC4uMTQKICAgKy0tLSstLS0rLS0t Ky0tLSstLS0rLS0tKy0tLSstLS0rCiAgIHwgICBPcHRpb24gVmFsdWUgLi4uCiAgICstLS0rLS0t Ky0tLSstLS0rLS0tKy0tLSstLS0rLS0tKwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIGZvciAxNS4uMjcwOgogICArLS0tKy0tLSstLS0rLS0tKy0tLSstLS0r LS0tKy0tLSstLS0rLS0tKy0tLSstLS0rLS0tKy0tLSstLS0rLS0tKwogICB8IE9wdGlvbiBEZWx0 YSAgfCAxICAgMSAgIDEgICAxIHwgICAgICAgICAgTGVuZ3RoIC0gMTUgICAgICAgICAgfAogICAr LS0tKy0tLSstLS0rLS0tKy0tLSstLS0rLS0tKy0tLSstLS0rLS0tKy0tLSstLS0rLS0tKy0tLSst LS0rLS0tKwogICB8ICAgT3B0aW9uIFZhbHVlIC4uLgogICArLS0tKy0tLSstLS0rLS0tKy0tLSst LS0rLS0tKy0tLSstLS0rLS0tKy0tLSstLS0rLS0tKy0tLSstLS0rLS0tKwoKICAgICAgICAgICAg ICAgICAgICAgICAgICBGaWd1cmUgNzogT3B0aW9uIEZvcm1hdAoKICAgVGhlIGZpZWxkcyBpbiBh biBvcHRpb24gYXJlIGRlZmluZWQgYXMgZm9sbG93czoKCiAgIE9wdGlvbiBEZWx0YTogIDQtYml0 IHVuc2lnbmVkIGludGVnZXIuICBJbmRpY2F0ZXMgdGhlIGRpZmZlcmVuY2UKICAgICAgYmV0d2Vl biB0aGUgT3B0aW9uIE51bWJlciBvZiB0aGlzIG9wdGlvbiBhbmQgdGhlIHByZXZpb3VzIG9wdGlv bgogICAgICAob3IgemVybyBmb3IgdGhlIGZpcnN0IG9wdGlvbikuICBJbiBvdGhlciB3b3Jkcywg dGhlIE9wdGlvbiBOdW1iZXIKICAgICAgaXMgY2FsY3VsYXRlZCBieSBzaW1wbHkgc3VtbWluZyB0 aGUgT3B0aW9uIERlbHRhIGZpZWxkcyBvZiB0aGlzCiAgICAgIGFuZCBwcmV2aW91cyBvcHRpb25z IGJlZm9yZSBpdC4gIFRoZSBPcHRpb24gTnVtYmVycyAxNCwgMjgsIDQyLAoKCgpTaGVsYnksIGV0 IGFsLiAgICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDE1LCAyMDExICAgICAgICAgICAgICBbUGFn ZSAxNF0KDApJbnRlcm5ldC1EcmFmdCAgIENvbnN0cmFpbmVkIEFwcGxpY2F0aW9uIFByb3RvY29s IChDb0FQKSAgICAgIE1hcmNoIDIwMTEKCgogICAgICAuLi4gYXJlIHJlc2VydmVkIGZvciBuby1v cCBvcHRpb25zIHdoZW4gdGhleSBhcmUgc2VudCB3aXRoIGFuCiAgICAgIGVtcHR5IHZhbHVlICh0 aGV5IGFyZSBpZ25vcmVkKSBhbmQgY2FuIGJlIHVzZWQgYXMgImZlbmNlcG9zdHMiIGlmCiAgICAg IGRlbHRhcyBsYXJnZXIgdGhhbiAxNSB3b3VsZCBvdGhlcndpc2UgYmUgcmVxdWlyZWQuCgogICBM ZW5ndGg6ICBJbmRpY2F0ZXMgdGhlIGxlbmd0aCBvZiB0aGUgT3B0aW9uIFZhbHVlLCBpbiBieXRl cy4KICAgICAgTm9ybWFsbHkgTGVuZ3RoIGlzIGEgNC1iaXQgdW5zaWduZWQgaW50ZWdlciBhbGxv d2luZyB2YWx1ZSBsZW5ndGhzCiAgICAgIG9mIDAtMTQgYnl0ZXMuICBXaGVuIHRoZSBMZW5ndGgg ZmllbGQgaXMgc2V0IHRvIDE1LCBhbm90aGVyIGJ5dGUKICAgICAgaXMgYWRkZWQgYXMgYW4gOC1i aXQgdW5zaWduZWQgaW50ZWdlciB3aG9zZSB2YWx1ZSBpcyBhZGRlZCB0byB0aGUKICAgICAgMTUs IGFsbG93aW5nIG9wdGlvbiB2YWx1ZSBsZW5ndGhzIG9mIDE1LTI3MCBieXRlcy4KCiAgIFRoZSBs ZW5ndGggYW5kIGZvcm1hdCBvZiB0aGUgT3B0aW9uIFZhbHVlIGRlcGVuZHMgb24gdGhlIHJlc3Bl Y3RpdmUKICAgb3B0aW9uLCB3aGljaCBNQVkgZGVmaW5lIHZhcmlhYmxlIGxlbmd0aCB2YWx1ZXMu ICBPcHRpb25zIGRlZmluZWQgaW4KICAgdGhpcyBkb2N1bWVudCBtYWtlIHVzZSBvZiB0aGUgZm9s bG93aW5nIGZvcm1hdHMgZm9yIG9wdGlvbiB2YWx1ZXM6CgogICB1aW50OiAgQSBub24tbmVnYXRp dmUgaW50ZWdlciB3aGljaCBpcyByZXByZXNlbnRlZCBpbiBuZXR3b3JrIGJ5dGUKICAgICAgICAg IG9yZGVyIHVzaW5nIGEgdmFyaWFibGUgbnVtYmVyIG9mIGJ5dGVzIChzZWUgQXBwZW5kaXggQSku CgogICBzdHJpbmc6ICBBIFVuaWNvZGUgc3RyaW5nIHdoaWNoIGlzIGVuY29kZWQgdXNpbmcgVVRG LTggW1JGQzM2MjldIGluCiAgICAgICAgICBOZXQtVW5pY29kZSBmb3JtIFtSRkM1MTk4XS4KCiAg IG9wYXF1ZTogIEFuIG9wYXF1ZSBzZXF1ZW5jZSBvZiBieXRlcy4KCiAgIE9wdGlvbiBOdW1iZXJz IGFyZSBtYWludGFpbmVkIGluIHRoZSBDb0FQIE9wdGlvbiBOdW1iZXIgUmVnaXN0cnkKICAgKFNl Y3Rpb24gMTEuMikuICBTZWUgU2VjdGlvbiA1LjEwIGZvciB0aGUgc2VtYW50aWNzIG9mIHRoZSBv cHRpb25zCiAgIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudC4KCgo0LiAgTWVzc2FnZSBTZW1hbnRp Y3MKCiAgIENvQVAgbWVzc2FnZXMgYXJlIGV4Y2hhbmdlZCBhc3luY2hyb25vdXNseSBiZXR3ZWVu IENvQVAgZW5kLXBvaW50cy4KICAgVGhleSBhcmUgdXNlZCB0byB0cmFuc3BvcnQgQ29BUCByZXF1 ZXN0cyBhbmQgcmVzcG9uc2VzLCB0aGUgc2VtYW50aWNzCiAgIG9mIHdoaWNoIGFyZSBkZWZpbmVk IGluIFNlY3Rpb24gNS4KCiAgIEFzIENvQVAgaXMgYm91bmQgdG8gbm9uLXJlbGlhYmxlIHRyYW5z cG9ydHMgc3VjaCBhcyBVRFAsIENvQVAKICAgbWVzc2FnZXMgbWF5IGFycml2ZSBvdXQgb2Ygb3Jk ZXIsIGFwcGVhciBkdXBsaWNhdGVkLCBvciBnbyBtaXNzaW5nCiAgIHdpdGhvdXQgbm90aWNlLiAg Rm9yIHRoaXMgcmVhc29uLCBDb0FQIGltcGxlbWVudHMgYSBsaWdodHdlaWdodAogICByZWxpYWJp bGl0eSBtZWNoYW5pc20sIHdpdGhvdXQgdHJ5aW5nIHRvIHJlLWNyZWF0ZSB0aGUgZnVsbCBmZWF0 dXJlCiAgIHNldCBvZiBhIHRyYW5zcG9ydCBsaWtlIFRDUC4gIEl0IGhhcyB0aGUgZm9sbG93aW5n IGZlYXR1cmVzOgoKICAgbyAgU2ltcGxlIHN0b3AtYW5kLXdhaXQgcmV0cmFuc21pc3Npb24gcmVs aWFiaWxpdHkgd2l0aCBleHBvbmVudGlhbAogICAgICBiYWNrLW9mZiBmb3IgImNvbmZpcm1hYmxl IiBtZXNzYWdlcy4KCiAgIG8gIER1cGxpY2F0ZSBkZXRlY3Rpb24gZm9yIGJvdGggImNvbmZpcm1h YmxlIiBhbmQgIm5vbi1jb25maXJtYWJsZSIKICAgICAgbWVzc2FnZXMuCgogICBvICBNdWx0aWNh c3Qgc3VwcG9ydC4KCgoKCgpTaGVsYnksIGV0IGFsLiAgICAgICAgIEV4cGlyZXMgU2VwdGVtYmVy IDE1LCAyMDExICAgICAgICAgICAgICBbUGFnZSAxNV0KDApJbnRlcm5ldC1EcmFmdCAgIENvbnN0 cmFpbmVkIEFwcGxpY2F0aW9uIFByb3RvY29sIChDb0FQKSAgICAgIE1hcmNoIDIwMTEKCgo0LjEu ICBSZWxpYWJsZSBNZXNzYWdlcwoKICAgVGhlIHJlbGlhYmxlIHRyYW5zbWlzc2lvbiBvZiBhIG1l c3NhZ2UgaXMgaW5pdGlhdGVkIGJ5IG1hcmtpbmcgdGhlCiAgIG1lc3NhZ2UgYXMgImNvbmZpcm1h YmxlIiBpbiB0aGUgQ29BUCBoZWFkZXIuICBBIHJlY2lwaWVudCBNVVNUCiAgIGFja25vd2xlZGdl IHN1Y2ggYSBtZXNzYWdlIHdpdGggYW4gYWNrbm93bGVkZ2VtZW50IG1lc3NhZ2UgKG9yLCBpZiBp dAogICBsYWNrcyBjb250ZXh0IHRvIHByb2Nlc3MgdGhlIG1lc3NhZ2UgcHJvcGVybHksIE1VU1Qg cmVqZWN0IGl0IHdpdGggYQogICByZXNldCBtZXNzYWdlKS4gIFRoZSBzZW5kZXIgcmV0cmFuc21p dHMgdGhlIGNvbmZpcm1hYmxlIG1lc3NhZ2UgYXQKICAgZXhwb25lbnRpYWxseSBpbmNyZWFzaW5n IGludGVydmFscywgdW50aWwgaXQgcmVjZWl2ZXMgYW4KICAgYWNrbm93bGVkZ2VtZW50IChvciBy ZXNldCBtZXNzYWdlKSwgb3IgcnVucyBvdXQgb2YgYXR0ZW1wdHMuCgogICBSZXRyYW5zbWlzc2lv biBpcyBjb250cm9sbGVkIGJ5IHR3byB0aGluZ3MgdGhhdCBhIENvQVAgZW5kLXBvaW50IE1VU1QK ICAga2VlcCB0cmFjayBvZiBmb3IgZWFjaCBjb25maXJtYWJsZSBtZXNzYWdlIGl0IHNlbmRzIHdo aWxlIHdhaXRpbmcgZm9yCiAgIGFuIGFja25vd2xlZGdlbWVudCAob3IgcmVzZXQpOiBhIHRpbWVv dXQgYW5kIGEgcmV0cmFuc21pc3Npb24KICAgY291bnRlci4gIEZvciBhIG5ldyBjb25maXJtYWJs ZSBtZXNzYWdlLCB0aGUgaW5pdGlhbCB0aW1lb3V0IGlzIHNldAogICB0byBSRVNQT05TRV9USU1F T1VUIGFuZCB0aGUgcmV0cmFuc21pc3Npb24gY291bnRlciBpcyBzZXQgdG8gMC4gIFdoZW4KICAg dGhlIHRpbWVvdXQgaXMgdHJpZ2dlcmVkIGFuZCB0aGUgcmV0cmFuc21pc3Npb24gY291bnRlciBp cyBsZXNzIHRoYW4KICAgTUFYX1JFVFJBTlNNSVQsIHRoZSBtZXNzYWdlIGlzIHJldHJhbnNtaXR0 ZWQsIHRoZSByZXRyYW5zbWlzc2lvbgogICBjb3VudGVyIGlzIGluY3JlbWVudGVkLCBhbmQgdGhl IHRpbWVvdXQgaXMgZG91YmxlZC4gIElmIHRoZQogICByZXRyYW5zbWlzc2lvbiBjb3VudGVyIHJl YWNoZXMgTUFYX1JFVFJBTlNNSVQgb24gYSB0aW1lb3V0LCBvciBpZiB0aGUKICAgZW5kLXBvaW50 IHJlY2VpdmVzIGEgcmVzZXQgbWVzc2FnZSwgdGhlbiB0aGUgYXR0ZW1wdCB0byB0cmFuc21pdCB0 aGUKICAgbWVzc2FnZSBpcyBjYW5jZWxsZWQgYW5kIHRoZSBhcHBsaWNhdGlvbiBwcm9jZXNzIGlu Zm9ybWVkIG9mIGZhaWx1cmUuCiAgIE9uIHRoZSBvdGhlciBoYW5kLCBpZiB0aGUgZW5kLXBvaW50 IHJlY2VpdmVzIGFuIGFja25vd2xlZGdlbWVudAogICBtZXNzYWdlIGluIHRpbWUsIHRyYW5zbWlz c2lvbiBpcyBjb25zaWRlcmVkIHN1Y2Nlc3NmdWwuCgogICBBbiBhY2tub3dsZWRnZW1lbnQgb3Ig cmVzZXQgbWVzc2FnZSBpcyByZWxhdGVkIHRvIGEgY29uZmlybWFibGUKICAgbWVzc2FnZSBieSBt ZWFucyBvZiBhIE1lc3NhZ2UgSUQuICBUaGUgTWVzc2FnZSBJRCBpcyBhIDE2LWJpdAogICB1bnNp Z25lZCBpbnRlZ2VyIHRoYXQgaXMgZ2VuZXJhdGVkIGJ5IHRoZSBzZW5kZXIgb2YgYSBjb25maXJt YWJsZQogICBtZXNzYWdlIGFuZCBpbmNsdWRlZCBpbiB0aGUgQ29BUCBoZWFkZXIuICBUaGUgTWVz c2FnZSBJRCBNVVNUIGJlCiAgIGVjaG9lZCBpbiB0aGUgYWNrbm93bGVkZ2VtZW50IG9yIHJlc2V0 IG1lc3NhZ2UgYnkgdGhlIHJlY2lwaWVudC4gIEEKICAgQ29BUCBlbmQtcG9pbnQgZ2VuZXJhdGVz IE1lc3NhZ2UgSURzIGJ5IGtlZXBpbmcgYSBzaW5nbGUgTWVzc2FnZSBJRAogICB2YXJpYWJsZSwg d2hpY2ggaXMgY2hhbmdlZCBlYWNoIHRpbWUgYSBuZXcgY29uZmlybWFibGUgbWVzc2FnZSBpcwog ICBzZW50IHJlZ2FyZGxlc3Mgb2YgdGhlIGRlc3RpbmF0aW9uIGFkZHJlc3Mgb3IgcG9ydC4gIFRo ZSBpbml0aWFsCiAgIHZhcmlhYmxlIHZhbHVlIFNIT1VMRCBiZSByYW5kb21pemVkLiAgVGhlIHNh bWUgTWVzc2FnZSBJRCBNVVNUIE5PVCBiZQogICByZS11c2VkIHdpdGhpbiB0aGUgcG90ZW50aWFs IHJldHJhbnNtaXNzaW9uIHdpbmRvdywgY2FsY3VsYXRlZCBhcwogICBSRVNQT05TRV9USU1FT1VU ICogKDIgXiBNQVhfUkVUUkFOU01JVCAtIDEpIHBsdXMgdGhlIGV4cGVjdGVkIG1heGltdW0KICAg cm91bmQgdHJpcCB0aW1lLgoKICAgQSByZWNpcGllbnQgTVVTVCBiZSBwcmVwYXJlZCB0byByZWNl aXZlIHRoZSBzYW1lIGNvbmZpcm1hYmxlIG1lc3NhZ2UKICAgKGFzIGluZGljYXRlZCBieSB0aGUg TWVzc2FnZSBJRCkgbXVsdGlwbGUgdGltZXMsIGZvciBleGFtcGxlLCB3aGVuCiAgIGl0cyBhY2tu b3dsZWRnZW1lbnQgd2VudCBtaXNzaW5nIG9yIGRpZG4ndCByZWFjaCB0aGUgb3JpZ2luYWwgc2Vu ZGVyCiAgIGJlZm9yZSB0aGUgZmlyc3QgdGltZW91dC4gIFRoZSByZWNpcGllbnQgU0hPVUxEIGFj a25vd2xlZGdlIGVhY2gKICAgZHVwbGljYXRlIGNvcHkgb2YgYSBjb25maXJtYWJsZSBtZXNzYWdl IHVzaW5nIHRoZSBzYW1lCiAgIGFja25vd2xlZGdlbWVudCBvciByZXNldCBtZXNzYWdlLCBidXQg U0hPVUxEIHByb2Nlc3MgYW55IHJlcXVlc3Qgb3IKICAgcmVzcG9uc2UgaW4gdGhlIG1lc3NhZ2Ug b25seSBvbmNlLiAgVGhpcyBydWxlIE1BWSBiZSByZWxheGVkIGluIGNhc2UKICAgdGhlIGNvbmZp cm1hYmxlIG1lc3NhZ2UgdHJhbnNwb3J0cyBhIHJlcXVlc3QgdGhhdCBpcyBpZGVtcG90ZW50IChz ZWUKICAgU2VjdGlvbiA1LjEpLiAgRXhhbXBsZXMgZm9yIHJlbGF4ZWQgbWVzc2FnZSBkZWR1cGxp Y2F0aW9uOgoKCgoKClNoZWxieSwgZXQgYWwuICAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMTUs IDIwMTEgICAgICAgICAgICAgIFtQYWdlIDE2XQoMCkludGVybmV0LURyYWZ0ICAgQ29uc3RyYWlu ZWQgQXBwbGljYXRpb24gUHJvdG9jb2wgKENvQVApICAgICAgTWFyY2ggMjAxMQoKCiAgIG8gIEEg c2VydmVyIE1BWSByZWxheCB0aGUgcmVxdWlyZW1lbnQgdG8gYW5zd2VyIGFsbCByZXRyYW5zbWlz c2lvbnMKICAgICAgb2YgYW4gaWRlbXBvdGVudCByZXF1ZXN0IHdpdGggdGhlIHNhbWUgcmVzcG9u c2UgKFNlY3Rpb24gNC4xKSwgc28KICAgICAgdGhhdCBpdCBkb2VzIG5vdCBoYXZlIHRvIG1haW50 YWluIHN0YXRlIGZvciBNZXNzYWdlIElEcy4gIEZvcgogICAgICBleGFtcGxlLCBhbiBpbXBsZW1l bnRhdGlvbiBtaWdodCB3YW50IHRvIHByb2Nlc3MgZHVwbGljYXRlCiAgICAgIHRyYW5zbWlzc2lv bnMgb2YgYSBHRVQsIFBVVCBvciBERUxFVEUgcmVxdWVzdCBhcyBzZXBhcmF0ZSByZXF1ZXN0cwog ICAgICBpZiB0aGUgZWZmb3J0IGluY3VycmVkIGJ5IGR1cGxpY2F0ZSBwcm9jZXNzaW5nIGlzIGxl c3MgZXhwZW5zaXZlCiAgICAgIHRoYW4ga2VlcGluZyB0cmFjayBvZiBwcmV2aW91cyByZXNwb25z ZXMgd291bGQgYmUuCgogICBvICAoQXMgYW4gaW1wbGVtZW50YXRpb24gY29uc2lkZXJhdGlvbiwg YSBjb25zdHJhaW5lZCBzZXJ2ZXIgTUFZIGV2ZW4KICAgICAgd2FudCB0byByZWxheCB0aGlzIHJl cXVpcmVtZW50IGZvciBjZXJ0YWluIG5vbi1pZGVtcG90ZW50IHJlcXVlc3RzCiAgICAgIGlmIHRo ZSBhcHBsaWNhdGlvbiBzZW1hbnRpY3MgbWFrZSB0aGlzIHRyYWRlLW9mZiBmYXZvcmFibGUuICBG b3IKICAgICAgZXhhbXBsZSwgaWYgdGhlIHJlc3VsdCBvZiBhIFBPU1QgcmVxdWVzdCBpcyBqdXN0 IHRoZSBjcmVhdGlvbiBvZgogICAgICBzb21lIHNob3J0LWxpdmVkIHN0YXRlIGF0IHRoZSBzZXJ2 ZXIsIGl0IG1heSBiZSBsZXNzIGV4cGVuc2l2ZSB0bwogICAgICBpbmN1ciB0aGlzIGVmZm9ydCBt dWx0aXBsZSB0aW1lcyBmb3IgYSByZXF1ZXN0IHRoYW4ga2VlcGluZyB0cmFjawogICAgICBvZiB3 aGV0aGVyIGEgcHJldmlvdXMgdHJhbnNtaXNzaW9uIG9mIHRoZSBzYW1lIHJlcXVlc3QgYWxyZWFk eSB3YXMKICAgICAgcHJvY2Vzc2VkLikKCjQuMi4gIFVucmVsaWFibGUgTWVzc2FnZXMKCiAgIEFz IGEgbW9yZSBsaWdodHdlaWdodCBhbHRlcm5hdGl2ZSwgYSBtZXNzYWdlIGNhbiBiZSB0cmFuc21p dHRlZCBsZXNzCiAgIHJlbGlhYmx5IGJ5IG1hcmtpbmcgdGhlIG1lc3NhZ2UgYXMgIm5vbi1jb25m aXJtYWJsZSIuICBBIG5vbi0KICAgY29uZmlybWFibGUgbWVzc2FnZSBNVVNUIE5PVCBiZSBhY2tu b3dsZWRnZWQgb3IgYmUgcmVqZWN0ZWQgYnkgdGhlCiAgIHJlY2lwaWVudC4gIElmIGEgcmVjaXBp ZW50IGxhY2tzIGNvbnRleHQgdG8gcHJvY2VzcyB0aGUgbWVzc2FnZQogICBwcm9wZXJseSwgdGhl IG1lc3NhZ2UgTVVTVCBiZSBzaWxlbnRseSBpZ25vcmVkLgoKICAgVGhlcmUgaXMgbm8gd2F5IHRv IGRldGVjdCBpZiBhIG5vbi1jb25maXJtYWJsZSBtZXNzYWdlIHdhcyByZWNlaXZlZAogICBvciBu b3QgYXQgdGhlIENvQVAtbGV2ZWwuICBBIHNlbmRlciBNQVkgY2hvb3NlIHRvIHRyYW5zbWl0IGEg bm9uLQogICBjb25maXJtYWJsZSBtZXNzYWdlIG11bHRpcGxlIHRpbWVzIHdoaWNoLCBmb3IgdGhp cyBwdXJwb3NlLCBzcGVjaWZpZXMKICAgYSBNZXNzYWdlIElEIGFzIHdlbGwuICBUaGUgc2FtZSBy dWxlcyBmb3IgZ2VuZXJhdGluZyB0aGUgTWVzc2FnZSBJRAogICBhcHBseS4KCiAgIEEgcmVjaXBp ZW50IE1VU1QgYmUgcHJlcGFyZWQgdG8gcmVjZWl2ZSB0aGUgc2FtZSBub24tY29uZmlybWFibGUK ICAgbWVzc2FnZSAoYXMgaW5kaWNhdGVkIGJ5IHRoZSBNZXNzYWdlIElEKSBtdWx0aXBsZSB0aW1l cy4gIEFzIGEKICAgZ2VuZXJhbCBydWxlIHRoYXQgbWF5IGJlIHJlbGF4ZWQgYmFzZWQgb24gdGhl IHNwZWNpZmljIHNlbWFudGljcyBvZiBhCiAgIG1lc3NhZ2UsIHRoZSByZWNpcGllbnQgU0hPVUxE IHNpbGVudGx5IGlnbm9yZSBhbnkgZHVwbGljYXRlZCBub24tCiAgIGNvbmZpcm1hYmxlIG1lc3Nh Z2UsIGFuZCBTSE9VTEQgcHJvY2VzcyBhbnkgcmVxdWVzdCBvciByZXNwb25zZSBpbgogICB0aGUg bWVzc2FnZSBvbmx5IG9uY2UuCgo0LjMuICBNZXNzYWdlIFR5cGVzCgogICBUaGUgZGlmZmVyZW50 IHR5cGVzIG9mIG1lc3NhZ2VzIGFyZSBzdW1tYXJpemVkIGJlbG93LiAgVGhlIHR5cGUgb2YgYQog ICBtZXNzYWdlIGlzIHNwZWNpZmllZCBieSB0aGUgVCBmaWVsZCBvZiB0aGUgQ29BUCBoZWFkZXIu CgogICBTZXBhcmF0ZSBmcm9tIHRoZSBtZXNzYWdlIHR5cGUsIGEgbWVzc2FnZSBtYXkgY2Fycnkg YSByZXF1ZXN0LCBhCiAgIHJlc3BvbnNlLCBvciBiZSBlbXB0eS4gIFRoaXMgaXMgc2lnbmFsbGVk IGJ5IHRoZSBDb2RlIGZpZWxkIGluIHRoZQogICBDb0FQIGhlYWRlciBhbmQgaXMgcmVsZXZhbnQg dG8gdGhlIHJlcXVlc3QvcmVzcG9uc2UgbW9kZWwuICBQb3NzaWJsZQogICB2YWx1ZXMgZm9yIHRo ZSBDb2RlIGZpZWxkIGFyZSBtYWludGFpbmVkIGJ5IHRoZSBDb0FQIENvZGUgUmVnaXN0cnkKICAg KFNlY3Rpb24gMTEuMSkuCgoKClNoZWxieSwgZXQgYWwuICAgICAgICAgRXhwaXJlcyBTZXB0ZW1i ZXIgMTUsIDIwMTEgICAgICAgICAgICAgIFtQYWdlIDE3XQoMCkludGVybmV0LURyYWZ0ICAgQ29u c3RyYWluZWQgQXBwbGljYXRpb24gUHJvdG9jb2wgKENvQVApICAgICAgTWFyY2ggMjAxMQoKCiAg IEFuIGVtcHR5IG1lc3NhZ2UgaGFzIHRoZSBDb2RlIGZpZWxkIHNldCB0byAwLiAgVGhlIE9DIGZp ZWxkIFNIT1VMRCBiZQogICBzZXQgdG8gMCBhbmQgbm8gYnl0ZXMgU0hPVUxEIGJlIHByZXNlbnQg YWZ0ZXIgdGhlIE1lc3NhZ2UgSUQgZmllbGQuCiAgIFRoZSBPQyBmaWVsZCBhbmQgYW55IHRob3Nl IGJ5dGVzIE1VU1QgYmUgaWdub3JlZCBieSBhbnkgcmVjaXBpZW50LgoKNC4zLjEuICBDb25maXJt YWJsZSAoQ09OKQoKICAgU29tZSBtZXNzYWdlcyByZXF1aXJlIGFuIGFja25vd2xlZGdlbWVudC4g IFRoZXNlIG1lc3NhZ2VzIGFyZSBjYWxsZWQKICAgIkNvbmZpcm1hYmxlIi4gIFdoZW4gbm8gcGFj a2V0cyBhcmUgbG9zdCwgZWFjaCBjb25maXJtYWJsZSBtZXNzYWdlCiAgIGVsaWNpdHMgZXhhY3Rs eSBvbmUgcmV0dXJuIG1lc3NhZ2Ugb2YgdHlwZSBBY2tub3dsZWRnZW1lbnQgb3IgdHlwZQogICBS ZXNldC4KCiAgIEEgY29uZmlybWFibGUgbWVzc2FnZSBhbHdheXMgY2FycmllcyBlaXRoZXIgYSBy ZXF1ZXN0IG9yIHJlc3BvbnNlIGFuZAogICBNVVNUIE5PVCBiZSBlbXB0eS4KCjQuMy4yLiAgTm9u LUNvbmZpcm1hYmxlIChOT04pCgogICBTb21lIG90aGVyIG1lc3NhZ2VzIGRvIG5vdCByZXF1aXJl IGFuIGFja25vd2xlZGdlbWVudC4gIFRoaXMgaXMKICAgcGFydGljdWxhcmx5IHRydWUgZm9yIG1l c3NhZ2VzIHRoYXQgYXJlIHJlcGVhdGVkIHJlZ3VsYXJseSBmb3IKICAgYXBwbGljYXRpb24gcmVx dWlyZW1lbnRzLCBzdWNoIGFzIHJlcGVhdGVkIHJlYWRpbmdzIGZyb20gYSBzZW5zb3IKICAgd2hl cmUgZXZlbnR1YWwgYXJyaXZhbCBpcyBzdWZmaWNpZW50LgoKICAgQSBub24tY29uZmlybWFibGUg bWVzc2FnZSBhbHdheXMgY2FycmllcyBlaXRoZXIgYSByZXF1ZXN0IG9yCiAgIHJlc3BvbnNlLCBh cyB3ZWxsLCBhbmQgTVVTVCBOT1QgYmUgZW1wdHkuCgo0LjMuMy4gIEFja25vd2xlZGdlbWVudCAo QUNLKQoKICAgQW4gQWNrbm93bGVkZ2VtZW50IG1lc3NhZ2UgYWNrbm93bGVkZ2VzIHRoYXQgYSBz cGVjaWZpYyBjb25maXJtYWJsZQogICBtZXNzYWdlIChpZGVudGlmaWVkIGJ5IGl0cyBNZXNzYWdl IElEKSBhcnJpdmVkLiAgSXQgZG9lcyBub3QgaW5kaWNhdGUKICAgc3VjY2VzcyBvciBmYWlsdXJl IG9mIGFueSBlbmNhcHN1bGF0ZWQgcmVxdWVzdC4KCiAgIFRoZSBhY2tub3dsZWRnZW1lbnQgbWVz c2FnZSBNVVNUIGVjaG8gdGhlIE1lc3NhZ2UgSUQgb2YgdGhlCiAgIGNvbmZpcm1hYmxlIG1lc3Nh Z2UsIGFuZCBNVVNUIGNhcnJ5IGEgcmVzcG9uc2Ugb3IgYmUgZW1wdHkgKHNlZQogICBTZWN0aW9u IDUuMi4xIGFuZCBTZWN0aW9uIDUuMi4yKS4KCjQuMy40LiAgUmVzZXQgKFJTVCkKCiAgIEEgUmVz ZXQgbWVzc2FnZSBpbmRpY2F0ZXMgdGhhdCBhIHNwZWNpZmljIGNvbmZpcm1hYmxlIG1lc3NhZ2Ug d2FzCiAgIHJlY2VpdmVkLCBidXQgc29tZSBjb250ZXh0IGlzIG1pc3NpbmcgdG8gcHJvcGVybHkg cHJvY2VzcyBpdC4gIFRoaXMKICAgY29uZGl0aW9uIGlzIHVzdWFsbHkgY2F1c2VkIHdoZW4gdGhl IHJlY2VpdmluZyBub2RlIGhhcyByZWJvb3RlZCBhbmQKICAgaGFzIGZvcmdvdHRlbiBzb21lIHN0 YXRlIHRoYXQgd291bGQgYmUgcmVxdWlyZWQgdG8gaW50ZXJwcmV0IHRoZQogICBtZXNzYWdlLgoK ICAgQSByZXNldCBtZXNzYWdlIE1VU1QgZWNobyB0aGUgTWVzc2FnZSBJRCBvZiB0aGUgY29uZmly bWFibGUgbWVzc2FnZSwKICAgYW5kIE1VU1QgYmUgZW1wdHkuCgoKCgoKCgpTaGVsYnksIGV0IGFs LiAgICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDE1LCAyMDExICAgICAgICAgICAgICBbUGFnZSAx OF0KDApJbnRlcm5ldC1EcmFmdCAgIENvbnN0cmFpbmVkIEFwcGxpY2F0aW9uIFByb3RvY29sIChD b0FQKSAgICAgIE1hcmNoIDIwMTEKCgo0LjQuICBNdWx0aWNhc3QKCiAgIENvQVAgc3VwcG9ydHMg c2VuZGluZyBtZXNzYWdlcyB0byBtdWx0aWNhc3QgZGVzdGluYXRpb24gYWRkcmVzc2VzLgogICBT dWNoIG11bHRpY2FzdCBtZXNzYWdlcyBNVVNUIGJlIE5vbi1Db25maXJtYWJsZS4gIE1lY2hhbmlz bXMgZm9yCiAgIGF2b2lkaW5nIGNvbmdlc3Rpb24gZnJvbSBtdWx0aWNhc3QgcmVxdWVzdHMgYXJl IGJlaW5nIGNvbnNpZGVyZWQgaW4KICAgW0ktRC5lZ2dlcnQtY29yZS1jb25nZXN0aW9uLWNvbnRy b2xdLgoKNC41LiAgQ29uZ2VzdGlvbiBDb250cm9sCgogICBCYXNpYyBjb25nZXN0aW9uIGNvbnRy b2wgZm9yIENvQVAgaXMgcHJvdmlkZWQgYnkgdGhlIGV4cG9uZW50aWFsCiAgIGJhY2stb2ZmIG1l Y2hhbmlzbSBpbiBTZWN0aW9uIDQuMS4gIEZ1cnRoZXIgY29uZ2VzdGlvbiBjb250cm9sCiAgIG9w dGltaXphdGlvbnMgYXJlIGJlaW5nIGNvbnNpZGVyZWQgYW5kIHRlc3RlZCBmb3IgQ29BUAogICBb SS1ELmVnZ2VydC1jb3JlLWNvbmdlc3Rpb24tY29udHJvbF0uCgoKNS4gIFJlcXVlc3QvUmVzcG9u c2UgU2VtYW50aWNzCgogICBDb0FQIG9wZXJhdGVzIHVuZGVyIGEgc2ltaWxhciByZXF1ZXN0L3Jl c3BvbnNlIG1vZGVsIGFzIEhUVFA6IGEgQ29BUAogICBlbmQtcG9pbnQgaW4gdGhlIHJvbGUgb2Yg YSAiY2xpZW50IiBzZW5kcyBvbmUgb3IgbW9yZSBDb0FQIHJlcXVlc3RzCiAgIHRvIGEgInNlcnZl ciIsIHdoaWNoIHNlcnZpY2VzIHRoZSByZXF1ZXN0cyBieSBzZW5kaW5nIENvQVAgcmVzcG9uc2Vz LgogICBVbmxpa2UgSFRUUCwgcmVxdWVzdHMgYW5kIHJlc3BvbnNlcyBhcmUgbm90IHNlbnQgb3Zl ciBhIHByZXZpb3VzbHkKICAgZXN0YWJsaXNoZWQgY29ubmVjdGlvbiwgYnV0IGV4Y2hhbmdlZCBh c3luY2hyb25vdXNseSBvdmVyIENvQVAKICAgbWVzc2FnZXMuCgo1LjEuICBSZXF1ZXN0cwoKICAg QSBDb0FQIHJlcXVlc3QgY29uc2lzdHMgb2YgdGhlIG1ldGhvZCB0byBiZSBhcHBsaWVkIHRvIHRo ZSByZXNvdXJjZSwKICAgdGhlIGlkZW50aWZpZXIgb2YgdGhlIHJlc291cmNlLCBhIHBheWxvYWQg YW5kIEludGVybmV0IG1lZGlhIHR5cGUgKGlmCiAgIGFueSksIGFuZCBvcHRpb25hbCBtZXRhLWRh dGEgYWJvdXQgdGhlIHJlcXVlc3QuCgogICBDb0FQIHN1cHBvcnRzIHRoZSBiYXNpYyBtZXRob2Rz IG9mIEdFVCwgUE9TVCwgUFVULCBERUxFVEUsIHdoaWNoIGFyZQogICBlYXNpbHkgbWFwcGVkIHRv IEhUVFAuICBUaGV5IGhhdmUgdGhlIHNhbWUgcHJvcGVydGllcyBvZiBzYWZlIChvbmx5CiAgIHJl dHJpZXZhbCkgYW5kIGlkZW1wb3RlbnQgKHlvdSBjYW4gaW52b2tlIGl0IG11bHRpcGxlIHRpbWVz IHdpdGggdGhlCiAgIHNhbWUgZWZmZWN0cykgYXMgSFRUUCAoc2VlIFNlY3Rpb24gOS4xIG9mIFtS RkMyNjE2XSkuICBUaGUgR0VUIG1ldGhvZAogICBpcyBzYWZlLCB0aGVyZWZvcmUgaXQgTVVTVCBO T1QgdGFrZSBhbnkgb3RoZXIgYWN0aW9uIG9uIGEgcmVzb3VyY2UKICAgb3RoZXIgdGhhbiByZXRy aWV2YWwuICBUaGUgR0VULCBQVVQgYW5kIERFTEVURSBtZXRob2RzIE1VU1QgYmUKICAgcGVyZm9y bWVkIGluIHN1Y2ggYSB3YXkgdGhhdCB0aGV5IGFyZSBpZGVtcG90ZW50LiAgUE9TVCBpcyBub3QK ICAgaWRlbXBvdGVudCwgYmVjYXVzZSBpdHMgZWZmZWN0IGlzIGRldGVybWluZWQgYnkgdGhlIG9y aWdpbiBzZXJ2ZXIgYW5kCiAgIGRlcGVuZGVudCBvbiB0aGUgdGFyZ2V0IHJlc291cmNlOyBpdCB1 c3VhbGx5IHJlc3VsdHMgaW4gYSBuZXcKICAgcmVzb3VyY2UgYmVpbmcgY3JlYXRlZCBvciB0aGUg dGFyZ2V0IHJlc291cmNlIGJlaW5nIHVwZGF0ZWQuCgogICBBIHJlcXVlc3QgaXMgaW5pdGlhdGVk IGJ5IHNldHRpbmcgdGhlIENvZGUgZmllbGQgaW4gdGhlIENvQVAgaGVhZGVyCiAgIG9mIGEgY29u ZmlybWFibGUgb3IgYSBub24tY29uZmlybWFibGUgbWVzc2FnZSB0byBhIE1ldGhvZCBDb2RlIGFu ZAogICBpbmNsdWRpbmcgcmVxdWVzdCBpbmZvcm1hdGlvbi4KCiAgIFRoZSBtZXRob2RzIHVzZWQg aW4gcmVxdWVzdHMgYXJlIGRlc2NyaWJlZCBpbiBkZXRhaWwgaW4gU2VjdGlvbiA1LjguCgoKCgoK U2hlbGJ5LCBldCBhbC4gICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAxNSwgMjAxMSAgICAgICAg ICAgICAgW1BhZ2UgMTldCgwKSW50ZXJuZXQtRHJhZnQgICBDb25zdHJhaW5lZCBBcHBsaWNhdGlv biBQcm90b2NvbCAoQ29BUCkgICAgICBNYXJjaCAyMDExCgoKNS4yLiAgUmVzcG9uc2VzCgogICBB ZnRlciByZWNlaXZpbmcgYW5kIGludGVycHJldGluZyBhIHJlcXVlc3QsIGEgc2VydmVyIHJlc3Bv bmRzIHdpdGggYQogICBDb0FQIHJlc3BvbnNlLCB3aGljaCBjYW4gYmUgbWF0Y2hlZCB0byB0aGUg cmVxdWVzdCBieSBtZWFucyBvZiBhCiAgIGNsaWVudC1nZW5lcmF0ZWQgdG9rZW4uCgogICBBIHJl c3BvbnNlIGlzIGlkZW50aWZpZWQgYnkgdGhlIENvZGUgZmllbGQgaW4gdGhlIENvQVAgaGVhZGVy IGJlaW5nCiAgIHNldCB0byBhIFJlc3BvbnNlIENvZGUuICBTaW1pbGFyIHRvIHRoZSBIVFRQIFN0 YXR1cyBDb2RlLCB0aGUgQ29BUAogICBSZXNwb25zZSBDb2RlIGluZGljYXRlcyB0aGUgcmVzdWx0 IG9mIHRoZSBhdHRlbXB0IHRvIHVuZGVyc3RhbmQgYW5kCiAgIHNhdGlzZnkgdGhlIHJlcXVlc3Qu ICBUaGVzZSBjb2RlcyBhcmUgZnVsbHkgZGVmaW5lZCBpbiBTZWN0aW9uIDUuOS4KICAgVGhlIFJl c3BvbnNlIENvZGUgbnVtYmVycyB0byBiZSBzZXQgaW4gdGhlIENvZGUgZmllbGQgb2YgdGhlIENv QVAKICAgaGVhZGVyIGFyZSBtYWludGFpbmVkIGluIHRoZSBDb0FQIFJlc3BvbnNlIENvZGUgUmVn aXN0cnkKICAgKFNlY3Rpb24gMTEuMS4yKS4KCiAgICAgICAgICAwCiAgICAgICAgICAwIDEgMiAz IDQgNSA2IDcKICAgICAgICAgKy0rLSstKy0rLSstKy0rLSsKICAgICAgICAgfGNsYXNzfCAgZGV0 YWlsIHwKICAgICAgICAgKy0rLSstKy0rLSstKy0rLSsKCiAgICAgICAgICAgICAgICAgIEZpZ3Vy ZSA4OiBTdHJ1Y3R1cmUgb2YgYSBSZXNwb25zZSBDb2RlCgogICBUaGUgdXBwZXIgdGhyZWUgYml0 cyBvZiB0aGUgOC1iaXQgUmVzcG9uc2UgQ29kZSBudW1iZXIgZGVmaW5lIHRoZQogICBjbGFzcyBv ZiByZXNwb25zZS4gIFRoZSBsb3dlciBmaXZlIGJpdHMgZG8gbm90IGhhdmUgYW55CiAgIGNhdGVn b3JpemF0aW9uIHJvbGU7IHRoZXkgZ2l2ZSBhZGRpdGlvbmFsIGRldGFpbCB0byB0aGUgb3ZlcmFs bCBjbGFzcwogICAoRmlndXJlIDgpLiAgVGhlcmUgYXJlIDMgY2xhc3NlczoKCiAgIDIgLSBTdWNj ZXNzOiAgVGhlIHJlcXVlc3Qgd2FzIHN1Y2Nlc3NmdWxseSByZWNlaXZlZCwgdW5kZXJzdG9vZCwg YW5kCiAgICAgIGFjY2VwdGVkLgoKICAgNCAtIENsaWVudCBFcnJvcjogIFRoZSByZXF1ZXN0IGNv bnRhaW5zIGJhZCBzeW50YXggb3IgY2Fubm90IGJlCiAgICAgIGZ1bGZpbGxlZC4KCiAgIDUgLSBT ZXJ2ZXIgRXJyb3I6ICBUaGUgc2VydmVyIGZhaWxlZCB0byBmdWxmaWxsIGFuIGFwcGFyZW50bHkg dmFsaWQKICAgICAgcmVxdWVzdC4KCiAgIFRoZSByZXNwb25zZSBjb2RlcyBhcmUgZGVzaWduZWQg dG8gYmUgZXh0ZW5zaWJsZTogUmVzcG9uc2UgQ29kZXMgaW4KICAgdGhlIENsaWVudCBFcnJvciBh bmQgU2VydmVyIEVycm9yIGNsYXNzIHRoYXQgYXJlIHVucmVjb2duaXplZCBieSBhbgogICBlbmQt cG9pbnQgTVVTVCBiZSB0cmVhdGVkIGFzIGJlaW5nIGVxdWl2YWxlbnQgdG8gdGhlIGdlbmVyaWMg UmVzcG9uc2UKICAgQ29kZSBvZiB0aGF0IGNsYXNzLiAgSG93ZXZlciwgdGhlcmUgaXMgbm8gZ2Vu ZXJpYyBSZXNwb25zZSBDb2RlCiAgIGluZGljYXRpbmcgc3VjY2Vzcywgc28gYSBSZXNwb25zZSBD b2RlIGluIHRoZSBTdWNjZXNzIGNsYXNzIHRoYXQgaXMKICAgdW5yZWNvZ25pemVkIGJ5IGFuIGVu ZC1wb2ludCBjYW4gb25seSBiZSB1c2VkIHRvIGRldGVybWluZSB0aGF0IHRoZQogICByZXF1ZXN0 IHdhcyBzdWNjZXNzZnVsIHdpdGhvdXQgYW55IGZ1cnRoZXIgZGV0YWlscy4KCiAgIEFzIGEgaHVt YW4gcmVhZGFibGUgbm90YXRpb24gZm9yIHNwZWNpZmljYXRpb25zIGFuZCBwcm90b2NvbAogICBk aWFnbm9zdGljcywgdGhlIG51bWVyaWMgdmFsdWUgb2YgYSByZXNwb25zZSBjb2RlIGlzIGluZGlj YXRlZCBieQogICBnaXZpbmcgdGhlIHVwcGVyIHRocmVlIGJpdHMgaW4gZGVjaW1hbCwgZm9sbG93 ZWQgYnkgYSBkb3QgYW5kIHRoZW4KICAgdGhlIGxvd2VyIGZpdmUgYml0cyBpbiBhIHR3by1kaWdp dCBkZWNpbWFsLiAgRS5nLiwgIk5vdCBGb3VuZCIgaXMKCgoKU2hlbGJ5LCBldCBhbC4gICAgICAg ICBFeHBpcmVzIFNlcHRlbWJlciAxNSwgMjAxMSAgICAgICAgICAgICAgW1BhZ2UgMjBdCgwKSW50 ZXJuZXQtRHJhZnQgICBDb25zdHJhaW5lZCBBcHBsaWNhdGlvbiBQcm90b2NvbCAoQ29BUCkgICAg ICBNYXJjaCAyMDExCgoKICAgd3JpdHRlbiBhcyA0LjA0IC0tIGluZGljYXRpbmcgYSB2YWx1ZSBv ZiBoZXhhZGVjaW1hbCAweDg0IG9yIGRlY2ltYWwKICAgMTMyLiAgSW4gb3RoZXIgd29yZHMsIHRo ZSBkb3QgIi4iIGZ1bmN0aW9ucyBhcyBhIHNob3J0LWN1dCBmb3IKICAgIiozMisiLgoKICAgVGhl IHBvc3NpYmxlIHJlc3BvbnNlIGNvZGVzIGFyZSBkZXNjcmliZWQgaW4gZGV0YWlsIGluIFNlY3Rp b24gNS45LgoKICAgUmVzcG9uc2VzIGNhbiBiZSBzZW50IGluIG11bHRpcGxlIHdheXMsIHdoaWNo IGFyZSBkZWZpbmVkIGJlbG93LgoKNS4yLjEuICBQaWdneS1iYWNrZWQKCiAgIEluIHRoZSBtb3N0 IGJhc2ljIGNhc2UsIHRoZSByZXNwb25zZSBpcyBjYXJyaWVkIGRpcmVjdGx5IGluIHRoZQogICBh Y2tub3dsZWRnZW1lbnQgbWVzc2FnZSB0aGF0IGFja25vd2xlZGdlcyB0aGUgcmVxdWVzdCAod2hp Y2ggcmVxdWlyZXMKICAgdGhhdCB0aGUgcmVxdWVzdCB3YXMgY2FycmllZCBpbiBhIGNvbmZpcm1h YmxlIG1lc3NhZ2UpLiAgVGhpcyBpcwogICBjYWxsZWQgYSAiUGlnZ3ktYmFja2VkIiBSZXNwb25z ZS4KCiAgIFRoZSByZXNwb25zZSBpcyByZXR1cm5lZCBpbiB0aGUgYWNrbm93bGVkZ2VtZW50IG1l c3NhZ2UgaW5kZXBlbmRlbnQKICAgb2Ygd2hldGhlciB0aGUgcmVzcG9uc2UgaW5kaWNhdGVzIHN1 Y2Nlc3Mgb3IgZmFpbHVyZS4gIEluIGVmZmVjdCwgdGhlCiAgIHJlc3BvbnNlIGlzIHBpZ2d5LWJh Y2tlZCBvbiB0aGUgYWNrbm93bGVkZ2VtZW50IG1lc3NhZ2UsIHNvIG5vCiAgIHNlcGFyYXRlIG1l c3NhZ2UgaXMgcmVxdWlyZWQgdG8gYm90aCBhY2tub3dsZWRnZSB0aGF0IHRoZSByZXF1ZXN0IHdh cwogICByZWNlaXZlZCBhbmQgcmV0dXJuIHRoZSByZXNwb25zZS4KCjUuMi4yLiAgU2VwYXJhdGUK CiAgIEl0IG1heSBub3QgYmUgcG9zc2libGUgdG8gcmV0dXJuIGEgcGlnZ3ktYmFja2VkIHJlc3Bv bnNlIGluIGFsbAogICBjYXNlcy4gIEZvciBleGFtcGxlLCBhIHNlcnZlciBtaWdodCBuZWVkIGxv bmdlciB0byBvYnRhaW4gdGhlCiAgIHJlcHJlc2VudGF0aW9uIG9mIHRoZSByZXNvdXJjZSByZXF1 ZXN0ZWQgdGhhbiBpdCBjYW4gd2FpdCBzZW5kaW5nCiAgIGJhY2sgdGhlIGFja25vd2xlZGdlbWVu dCBtZXNzYWdlLCB3aXRob3V0IHJpc2tpbmcgdGhlIGNsaWVudCB0bwogICByZXBlYXRlZGx5IHJl dHJhbnNtaXQgdGhlIHJlcXVlc3QgbWVzc2FnZS4KCiAgIFRoZSBzZXJ2ZXIgbWF5YmUgaW5pdGlh dGVzIHRoZSBhdHRlbXB0IHRvIG9idGFpbiB0aGUgcmVzb3VyY2UKICAgcmVwcmVzZW50YXRpb24g YW5kIHRpbWVzIG91dCBhbiBhY2tub3dsZWRnZW1lbnQgdGltZXIsIG9yIGl0CiAgIGltbWVkaWF0 ZWx5IHNlbmRzIGFuIGFja25vd2xlZGdlbWVudCBrbm93aW5nIGluIGFkdmFuY2UgdGhhdCB0aGVy ZQogICB3aWxsIGJlIG5vIHBpZ2d5LWJhY2tlZCByZXNwb25zZS4gIFRoZSBhY2tub3dsZWRnZW1l bnQgZWZmZWN0aXZlbHkgaXMKICAgYSBwcm9taXNlIHRoYXQgdGhlIHJlcXVlc3Qgd2lsbCBiZSBh Y3RlZCB1cG9uLgoKICAgV2hlbiB0aGUgc2VydmVyIGZpbmFsbHkgaGFzIG9idGFpbmVkIHRoZSBy ZXNvdXJjZSByZXByZXNlbnRhdGlvbiwgaXQKICAgc2VuZHMgdGhlIHJlc3BvbnNlLiAgVG8gZW5z dXJlIHRoYXQgdGhpcyBtZXNzYWdlIGlzIG5vdCBsb3N0LCBpdCBpcwogICBhZ2FpbiBzZW50IGFz IGEgY29uZmlybWFibGUgbWVzc2FnZSBhbmQgYW5zd2VyZWQgYnkgdGhlIGNsaWVudCB3aXRoCiAg IGFuIGFja25vd2xlZGdlbWVudCwgZWNob2luZyB0aGUgbmV3IE1lc3NhZ2UgSUQgY2hvc2VuIGJ5 IHRoZSBzZXJ2ZXIuCgogICAoTm90ZSB0aGF0LCBhcyB0aGUgdW5kZXJseWluZyBkYXRhZ3JhbSB0 cmFuc3BvcnQgbWF5IG5vdCBiZSBzZXF1ZW5jZS0KICAgcHJlc2VydmluZywgdGhlIGNvbmZpcm1h YmxlIG1lc3NhZ2UgY2FycnlpbmcgdGhlIHJlc3BvbnNlIG1heQogICBhY3R1YWxseSBhcnJpdmUg YmVmb3JlIG9yIGFmdGVyIHRoZSBhY2tub3dsZWRnZW1lbnQgbWVzc2FnZSBmb3IgdGhlCiAgIHJl cXVlc3QuKQoKICAgRm9yIGEgc2VwYXJhdGUgZXhjaGFuZ2UsIGJvdGggdGhlIGFja25vd2xlZGdl bWVudCB0byB0aGUgY29uZmlybWFibGUKICAgcmVxdWVzdCBhbmQgdGhlIGFja25vd2xlZGdlbWVu dCB0byB0aGUgY29uZmlybWFibGUgcmVzcG9uc2UgTVVTVCBiZQogICBhbiBlbXB0eSBtZXNzYWdl LCBpLmUuIG9uZSB0aGF0IGNhcnJpZXMgbmVpdGhlciBhIHJlcXVlc3Qgbm9yIGEKCgoKU2hlbGJ5 LCBldCBhbC4gICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAxNSwgMjAxMSAgICAgICAgICAgICAg W1BhZ2UgMjFdCgwKSW50ZXJuZXQtRHJhZnQgICBDb25zdHJhaW5lZCBBcHBsaWNhdGlvbiBQcm90 b2NvbCAoQ29BUCkgICAgICBNYXJjaCAyMDExCgoKICAgcmVzcG9uc2UuCgo1LjIuMy4gIE5vbi1D b25maXJtYWJsZQoKICAgSWYgdGhlIHJlcXVlc3QgbWVzc2FnZSBpcyBub24tY29uZmlybWFibGUs IHRoZW4gdGhlIHJlc3BvbnNlIFNIT1VMRAogICBiZSByZXR1cm5lZCBpbiBhIG5vbi1jb25maXJt YWJsZSBtZXNzYWdlIGFzIHdlbGwuICBIb3dldmVyLCBhbiBlbmQtCiAgIHBvaW50IE1VU1QgYmUg cHJlcGFyZWQgdG8gcmVjZWl2ZSBhIG5vbi1jb25maXJtYWJsZSByZXNwb25zZQogICAocHJlY2Vk ZWQgb3IgZm9sbG93ZWQgYW4gZW1wdHkgYWNrbm93bGVkZ2VtZW50IG1lc3NhZ2UpIGluIHJlcGx5 IHRvIGEKICAgY29uZmlybWFibGUgcmVxdWVzdCwgb3IgYSBjb25maXJtYWJsZSByZXNwb25zZSBp biByZXBseSB0byBhIG5vbi0KICAgY29uZmlybWFibGUgcmVxdWVzdC4KCjUuMy4gIFJlcXVlc3Qv UmVzcG9uc2UgTWF0Y2hpbmcKCiAgIFJlZ2FyZGxlc3Mgb2YgaG93IGEgcmVzcG9uc2UgaXMgc2Vu dCwgaXQgaXMgbWF0Y2hlZCB0byB0aGUgcmVxdWVzdCBieQogICBtZWFucyBvZiBhIHRva2VuIHRo YXQgaXMgaW5jbHVkZWQgYnkgdGhlIGNsaWVudCBpbiB0aGUgcmVxdWVzdCBhcyBvbmUKICAgb2Yg dGhlIG9wdGlvbnMuICBUaGUgdG9rZW4gTVVTVCBiZSBlY2hvZWQgYnkgdGhlIHNlcnZlciBpbiBh bnkKICAgcmVzdWx0aW5nIHJlc3BvbnNlIHdpdGhvdXQgbW9kaWZpY2F0aW9uLgoKICAgVGhlIGV4 YWN0IHJ1bGVzIGZvciBtYXRjaGluZyBhIHJlc3BvbnNlIHRvIGEgcmVxdWVzdCBhcmUgYXMgZm9s bG93czoKCiAgIDEuICBGb3IgcmVxdWVzdHMgc2VudCBpbiBhIHVuaWNhc3QgbWVzc2FnZSwgdGhl IHNvdXJjZSBvZiB0aGUKICAgICAgIHJlc3BvbnNlIE1VU1QgbWF0Y2ggdGhlIGRlc3RpbmF0aW9u IG9mIHRoZSBvcmlnaW5hbCByZXF1ZXN0LiAgSG93CiAgICAgICB0aGlzIGlzIGRldGVybWluZWQg ZGVwZW5kcyBvbiB0aGUgc2VjdXJpdHkgbW9kZSB1c2VkIChzZWUKICAgICAgIFNlY3Rpb24gMTAp OiBXaXRoIE5vU2VjLCB0aGUgSVAgYWRkcmVzcyBhbmQgcG9ydCBudW1iZXIgb2YgdGhlCiAgICAg ICByZXF1ZXN0IGRlc3RpbmF0aW9uIGFuZCByZXNwb25zZSBzb3VyY2UgbXVzdCBtYXRjaC4gIFdp dGggb3RoZXIKICAgICAgIHNlY3VyaXR5IG1vZGVzLCBpbiBhZGRpdGlvbiB0byB0aGUgSVAgYWRk cmVzcyBhbmQgVURQIHBvcnQKICAgICAgIG1hdGNoaW5nLCB0aGUgcmVxdWVzdCBhbmQgcmVzcG9u c2UgTVVTVCBoYXZlIHRoZSBzYW1lIHNlY3VyaXR5CiAgICAgICBjb250ZXh0LgoKICAgMi4gIElu IGEgcGlnZ3ktYmFja2VkIHJlc3BvbnNlLCBib3RoIHRoZSBNZXNzYWdlIElEIG9mIHRoZQogICAg ICAgY29uZmlybWFibGUgcmVxdWVzdCBhbmQgdGhlIGFja25vd2xlZGdlbWVudCwgYW5kIHRoZSB0 b2tlbiBvZiB0aGUKICAgICAgIHJlc3BvbnNlIGFuZCBvcmlnaW5hbCByZXF1ZXN0IE1VU1QgbWF0 Y2guICBJbiBhIHNlcGFyYXRlCiAgICAgICByZXNwb25zZSwganVzdCB0aGUgdG9rZW4gb2YgdGhl IHJlc3BvbnNlIGFuZCBvcmlnaW5hbCByZXF1ZXN0CiAgICAgICBNVVNUIG1hdGNoLgoKICAgVGhl IGNsaWVudCBTSE9VTEQgZ2VuZXJhdGUgdG9rZW5zIGluIGEgd2F5IHRoYXQgdG9rZW5zIGN1cnJl bnRseSBpbgogICB1c2UgZm9yIGEgZ2l2ZW4gc291cmNlL2Rlc3RpbmF0aW9uIHBhaXIgYXJlIHVu aXF1ZS4gIChOb3RlIHRoYXQgYQogICBjbGllbnQgY2FuIHVzZSB0aGUgc2FtZSB0b2tlbiBmb3Ig YW55IHJlcXVlc3QgaWYgaXQgdXNlcyBhIGRpZmZlcmVudAogICBzb3VyY2UgcG9ydCBudW1iZXIg ZWFjaCB0aW1lLikKCiAgIEFuIGVuZC1wb2ludCByZWNlaXZpbmcgYSB0b2tlbiBNVVNUIHRyZWF0 IGl0IGFzIG9wYXF1ZSBhbmQgbWFrZSBubwogICBhc3N1bXB0aW9ucyBhYm91dCBpdHMgZm9ybWF0 LiAgKE5vdGUgdGhhdCB0aGVyZSBpcyBhIGRlZmF1bHQgdmFsdWUKICAgZm9yIHRoZSBUb2tlbiBP cHRpb24sIHNvIGV2ZXJ5IG1lc3NhZ2UgY2FycmllcyBhIHRva2VuLCBldmVuIGlmIGl0IGlzCiAg IG5vdCBleHBsaWNpdGx5IGV4cHJlc3NlZCBpbiBhIENvQVAgb3B0aW9uLikKCiAgIEluIGNhc2Ug YSBjb25maXJtYWJsZSBtZXNzYWdlIGNhcnJ5aW5nIGEgcmVzcG9uc2UgaXMgdW5leHBlY3RlZCAo aS5lLgogICB0aGUgY2xpZW50IGlzIG5vdCB3YWl0aW5nIGZvciBhIHJlc3BvbnNlIHdpdGggdGhl IHNwZWNpZmllZCBhZGRyZXNzCiAgIGFuZC9vciB0b2tlbiksIHRoZSBjb25maXJtYWJsZSByZXNw b25zZSBTSE9VTEQgYmUgcmVqZWN0ZWQgd2l0aCBhCgoKClNoZWxieSwgZXQgYWwuICAgICAgICAg RXhwaXJlcyBTZXB0ZW1iZXIgMTUsIDIwMTEgICAgICAgICAgICAgIFtQYWdlIDIyXQoMCkludGVy bmV0LURyYWZ0ICAgQ29uc3RyYWluZWQgQXBwbGljYXRpb24gUHJvdG9jb2wgKENvQVApICAgICAg TWFyY2ggMjAxMQoKCiAgIHJlc2V0IG1lc3NhZ2UgYW5kIE1VU1QgTk9UIGJlIGFja25vd2xlZGdl ZC4KCjUuNC4gIE9wdGlvbnMKCiAgIEJvdGggcmVxdWVzdHMgYW5kIHJlc3BvbnNlcyBtYXkgaW5j bHVkZSBhIGxpc3Qgb2Ygb25lIG9yIG1vcmUKICAgb3B0aW9ucy4gIEZvciBleGFtcGxlLCB0aGUg VVJJIGluIGEgcmVxdWVzdCBpcyB0cmFuc3BvcnRlZCBpbiBzZXZlcmFsCiAgIG9wdGlvbnMsIGFu ZCBtZXRhLWRhdGEgdGhhdCB3b3VsZCBiZSBjYXJyaWVkIGluIGFuIEhUVFAgaGVhZGVyIGluCiAg IEhUVFAgaXMgc3VwcGxpZWQgYXMgb3B0aW9ucyBhcyB3ZWxsLgoKICAgQ29BUCBkZWZpbmVzIGEg c2luZ2xlIHNldCBvZiBvcHRpb25zIHRoYXQgYXJlIHVzZWQgaW4gYm90aCByZXF1ZXN0cwogICBh bmQgcmVzcG9uc2VzOgoKICAgbyAgQ29udGVudC1UeXBlCgogICBvICBFVGFnCgogICBvICBMb2Nh dGlvbi1QYXRoCgogICBvICBMb2NhdGlvbi1RdWVyeQoKICAgbyAgTWF4LUFnZQoKICAgbyAgUHJv eHktVXJpCgogICBvICBUb2tlbgoKICAgbyAgVXJpLUhvc3QKCiAgIG8gIFVyaS1QYXRoCgogICBv ICBVcmktUG9ydAoKICAgbyAgVXJpLVF1ZXJ5CgogICBUaGUgc2VtYW50aWNzIG9mIHRoZXNlIG9w dGlvbnMgYWxvbmcgd2l0aCB0aGVpciBwcm9wZXJ0aWVzIGFyZQogICBkZWZpbmVkIGluIGRldGFp bCBpbiBTZWN0aW9uIDUuMTAuCgogICBOb3QgYWxsIG9wdGlvbnMgaGF2ZSBtZWFuaW5nIHdpdGgg YWxsIG1ldGhvZHMgYW5kIHJlc3BvbnNlIGNvZGVzLgogICBUaGUgcG9zc2libGUgb3B0aW9ucyBm b3IgbWV0aG9kcyBhbmQgcmVzcG9uc2UgY29kZXMgYXJlIGRlZmluZWQgaW4KICAgU2VjdGlvbiA1 LjggYW5kIFNlY3Rpb24gNS45IHJlc3BlY3RpdmVseS4gIEluIGNhc2UgYW4gb3B0aW9uIGhhcyBu bwogICBtZWFuaW5nLCBpdCBTSE9VTEQgTk9UIGJlIGluY2x1ZGVkIGJ5IHRoZSBzZW5kZXIgYW5k IE1VU1QgYmUgaWdub3JlZAogICBieSB0aGUgcmVjaXBpZW50LgoKNS40LjEuICBDcml0aWNhbC9F bGVjdGl2ZQoKICAgT3B0aW9ucyBmYWxsIGludG8gb25lIG9mIHR3byBjbGFzc2VzOiAiY3JpdGlj YWwiIG9yICJlbGVjdGl2ZSIuICBUaGUKICAgZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZXNlIGlzIGhv dyBhbiBvcHRpb24gdW5yZWNvZ25pemVkIGJ5IGFuIGVuZC0KICAgcG9pbnQgaXMgaGFuZGxlZDoK CgoKU2hlbGJ5LCBldCBhbC4gICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAxNSwgMjAxMSAgICAg ICAgICAgICAgW1BhZ2UgMjNdCgwKSW50ZXJuZXQtRHJhZnQgICBDb25zdHJhaW5lZCBBcHBsaWNh dGlvbiBQcm90b2NvbCAoQ29BUCkgICAgICBNYXJjaCAyMDExCgoKICAgbyAgVXBvbiByZWNlcHRp b24sIHVucmVjb2duaXplZCBvcHRpb25zIG9mIGNsYXNzICJlbGVjdGl2ZSIgTVVTVCBiZQogICAg ICBzaWxlbnRseSBpZ25vcmVkLgoKICAgbyAgVW5yZWNvZ25pemVkIG9wdGlvbnMgb2YgY2xhc3Mg ImNyaXRpY2FsIiB0aGF0IG9jY3VyIGluIGEKICAgICAgY29uZmlybWFibGUgcmVxdWVzdCBNVVNU IGNhdXNlIHRoZSByZXR1cm4gb2YgYSA0LjAyIChCYWQgT3B0aW9uKQogICAgICByZXNwb25zZS4g IFRoaXMgcmVzcG9uc2UgU0hPVUxEIGluY2x1ZGUgYSBodW1hbi1yZWFkYWJsZSBlcnJvcgogICAg ICBtZXNzYWdlIGRlc2NyaWJpbmcgdGhlIHVucmVjb2duaXplZCBvcHRpb24ocykgKHNlZSBTZWN0 aW9uIDUuNSkuCgogICBvICBVbnJlY29nbml6ZWQgb3B0aW9ucyBvZiBjbGFzcyAiY3JpdGljYWwi IHRoYXQgb2NjdXIgaW4gYQogICAgICBjb25maXJtYWJsZSByZXNwb25zZSBTSE9VTEQgY2F1c2Ug dGhlIHJlc3BvbnNlIHRvIGJlIHJlamVjdGVkIHdpdGgKICAgICAgYSByZXNldCBtZXNzYWdlLgoK ICAgbyAgVW5yZWNvZ25pemVkIG9wdGlvbnMgb2YgY2xhc3MgImNyaXRpY2FsIiB0aGF0IG9jY3Vy IGluIGEgbm9uLQogICAgICBjb25maXJtYWJsZSBtZXNzYWdlIE1VU1QgY2F1c2UgdGhlIG1lc3Nh Z2UgYmUgc2lsZW50bHkgaWdub3JlZC4KCiAgIE5vdGUgdGhhdCwgd2hldGhlciBjcml0aWNhbCBv ciBlbGVjdGl2ZSwgYW4gb3B0aW9uIGlzIG5ldmVyCiAgICJtYW5kYXRvcnkiIChpdCBpcyBhbHdh eXMgb3B0aW9uYWwpOiBUaGVzZSBydWxlcyBhcmUgZGVmaW5lZCBpbiBvcmRlcgogICB0byBlbmFi bGUgaW1wbGVtZW50YXRpb25zIHRvIHJlamVjdCBvcHRpb25zIHRoZXkgZG8gbm90IHVuZGVyc3Rh bmQgb3IKICAgaW1wbGVtZW50LgoKNS40LjIuICBMZW5ndGgKCiAgIE9wdGlvbiB2YWx1ZXMgYXJl IGRlZmluZWQgdG8gaGF2ZSBhIHNwZWNpZmljIGxlbmd0aCwgb2Z0ZW4gaW4gdGhlCiAgIGZvcm0g b2YgYW4gdXBwZXIgYW5kIGxvd2VyIGJvdW5kLiAgSWYgdGhlIGxlbmd0aCBvZiBhbiBvcHRpb24g dmFsdWUKICAgaW4gYSByZXF1ZXN0IGlzIG91dHNpZGUgdGhlIGRlZmluZWQgcmFuZ2UsIHRoYXQg b3B0aW9uIE1VU1QgYmUKICAgdHJlYXRlZCBsaWtlIGFuIHVucmVjb2duaXplZCBvcHRpb24gKHNl ZSBTZWN0aW9uIDUuNC4xKS4KCjUuNC4zLiAgRGVmYXVsdCBWYWx1ZXMKCiAgIE9wdGlvbnMgbWF5 IGJlIGRlZmluZWQgdG8gaGF2ZSBhIGRlZmF1bHQgdmFsdWUuICBJZiB0aGUgdmFsdWUgb2YKICAg b3B0aW9uIGlzIGludGVuZGVkIHRvIGJlIHRoaXMgZGVmYXVsdCB2YWx1ZSwgdGhlIG9wdGlvbiBT SE9VTEQgTk9UIGJlCiAgIGluY2x1ZGVkIGluIHRoZSBtZXNzYWdlLiAgSWYgdGhlIG9wdGlvbiBp cyBub3QgcHJlc2VudCwgdGhlIGRlZmF1bHQKICAgdmFsdWUgTVVTVCBiZSBhc3N1bWVkLgoKNS40 LjQuICBSZXBlYXRpbmcgT3B0aW9ucwoKICAgRWFjaCBkZWZpbml0aW9uIG9mIGFuIG9wdGlvbiBz cGVjaWZpZXMgd2hldGhlciBpdCBpcyBkZWZpbmVkIHRvIG9jY3VyCiAgIG9ubHkgYXQgbW9zdCBv bmNlIG9yIHdoZXRoZXIgaXQgY2FuIG9jY3VyIG11bHRpcGxlIHRpbWVzLiAgSWYgYQogICBtZXNz YWdlIGluY2x1ZGVzIGFuIG9wdGlvbiB3aXRoIG1vcmUgaW5zdGFuY2VzIHRoYW4gdGhlIG9wdGlv biBpcwogICBkZWZpbmVkIGZvciwgdGhlIGFkZGl0aW9uYWwgb3B0aW9uIGluc3RhbmNlcyBNVVNU IGJlIHRyZWF0ZWQgbGlrZSBhbgogICB1bnJlY29nbml6ZWQgb3B0aW9uIChzZWUgU2VjdGlvbiA1 LjQuMSkuCgo1LjQuNS4gIE9wdGlvbiBOdW1iZXJzCgogICBPcHRpb25zIGFyZSBpZGVudGlmaWVk IGJ5IGFuIG9wdGlvbiBudW1iZXIuICBPZGQgbnVtYmVycyBpbmRpY2F0ZSBhCiAgIGNyaXRpY2Fs IG9wdGlvbiwgd2hpbGUgZXZlbiBudW1iZXJzIGluZGljYXRlIGFuIGVsZWN0aXZlIG9wdGlvbi4K ICAgKE5vdGUgdGhhdCB0aGlzIGlzIG5vdCBqdXN0IGEgY29udmVudGlvbiwgaXQgaXMgYSBmZWF0 dXJlIG9mIHRoZQogICBwcm90b2NvbDogV2hldGhlciBhbiBvcHRpb24gaXMgZWxlY3RpdmUgb3Ig Y3JpdGljYWwgaXMgZW50aXJlbHkKCgoKU2hlbGJ5LCBldCBhbC4gICAgICAgICBFeHBpcmVzIFNl cHRlbWJlciAxNSwgMjAxMSAgICAgICAgICAgICAgW1BhZ2UgMjRdCgwKSW50ZXJuZXQtRHJhZnQg ICBDb25zdHJhaW5lZCBBcHBsaWNhdGlvbiBQcm90b2NvbCAoQ29BUCkgICAgICBNYXJjaCAyMDEx CgoKICAgZGV0ZXJtaW5lZCBieSB3aGV0aGVyIGl0cyBvcHRpb24gbnVtYmVyIGlzIGV2ZW4gb3Ig b2RkLikKCiAgIFRoZSBudW1iZXJzIDE0LCAyOCwgNDIsIC4uLiBhcmUgcmVzZXJ2ZWQgZm9yICJm ZW5jZXBvc3RpbmciLCBhcwogICBkZXNjcmliZWQgaW4gU2VjdGlvbiAzLjIuICBBcyB0aGVzZSBv cHRpb24gbnVtYmVycyBhcmUgZXZlbiwgdGhleQogICBzdGFuZCBmb3IgZWxlY3RpdmUgb3B0aW9u cywgYW5kIHVubGVzcyBhc3NpZ25lZCBhIG1lYW5pbmcsIHRoZXNlIE1VU1QKICAgYmUgc2lsZW50 bHkgaWdub3JlZC4KCiAgIFRoZSBvcHRpb24gbnVtYmVycyBmb3IgdGhlIG9wdGlvbnMgZGVmaW5l ZCBpbiB0aGlzIGRvY3VtZW50IGFyZQogICBsaXN0ZWQgaW4gdGhlIENvQVAgT3B0aW9uIE51bWJl ciBSZWdpc3RyeSAoU2VjdGlvbiAxMS4yKS4KCjUuNS4gIFBheWxvYWQKCiAgIEJvdGggcmVxdWVz dHMgYW5kIHJlc3BvbnNlcyBtYXkgaW5jbHVkZSBwYXlsb2FkLCBkZXBlbmRpbmcgb24gdGhlCiAg IG1ldGhvZCBvciByZXNwb25zZSBjb2RlIHJlc3BlY3RpdmVseS4gIE1ldGhvZHMgd2l0aCBwYXls b2FkIGFyZSBQVVQKICAgYW5kIFBPU1QsIGFuZCB0aGUgcmVzcG9uc2UgY29kZXMgd2l0aCBwYXls b2FkIGFyZSAyLjA1IChDb250ZW50KSBhbmQKICAgdGhlIGVycm9yIGNvZGVzLgoKICAgVGhlIHBh eWxvYWQgb2YgUFVULCBQT1NUIGFuZCAyLjA1IChDb250ZW50KSBpcyB0eXBpY2FsbHkgYSByZXNv dXJjZQogICByZXByZXNlbnRhdGlvbi4gIEl0cyBmb3JtYXQgaXMgc3BlY2lmaWVkIGJ5IHRoZSBJ bnRlcm5ldCBtZWRpYSB0eXBlCiAgIGdpdmVuIGJ5IHRoZSBDb250ZW50LVR5cGUgT3B0aW9uLiAg QSBkZWZhdWx0IHZhbHVlIG9mICJ0ZXh0L3BsYWluOwogICBjaGFyc2V0PXV0Zi04IiBpcyBhc3N1 bWVkIGluIHRoZSBhYnNlbmNlIG9mIHRoaXMgb3B0aW9uLgoKICAgQSByZXNwb25zZSB3aXRoIGEg Y29kZSBpbmRpY2F0aW5nIGEgQ2xpZW50IG9yIFNlcnZlciBFcnJvciBTSE9VTEQKICAgaW5jbHVk ZSBhIGJyaWVmIGh1bWFuLXJlYWRhYmxlIGRpYWdub3N0aWMgbWVzc2FnZSBhcyBwYXlsb2FkLAog ICBleHBsYWluaW5nIHRoZSBlcnJvciBzaXR1YXRpb24uICBUaGlzIGRpYWdub3N0aWMgbWVzc2Fn ZSBNVVNUIGJlCiAgIGVuY29kZWQgdXNpbmcgVVRGLTggW1JGQzM2MjldLCBtb3JlIHNwZWNpZmlj YWxseSB1c2luZyBOZXQtVW5pY29kZQogICBmb3JtIFtSRkM1MTk4XS4gIFRoZSBDb250ZW50LVR5 cGUgT3B0aW9uIGhhcyBubyBtZWFuaW5nIGFuZCBTSE9VTEQKICAgTk9UIGJlIGluY2x1ZGVkLiAg KFNpbWlsYXIgdG8gd2hhdCBvbmUgd291bGQgZmluZCBhcyBhIFJlYXNvbi1QaHJhc2UKICAgb24g YW4gSFRUUCBzdGF0dXMgbGluZSwgdGhlIG1lc3NhZ2UgaXMgbm90IGludGVuZGVkIGZvciBlbmQt dXNlcnMgYnV0CiAgIGZvciBzb2Z0d2FyZSBlbmdpbmVlcnMgdGhhdCBkdXJpbmcgZGVidWdnaW5n IG5lZWQgdG8gaW50ZXJwcmV0IGl0IGluCiAgIHRoZSBjb250ZXh0IG9mIHRoZSBwcmVzZW50LCBF bmdsaXNoLWxhbmd1YWdlIHNwZWNpZmljYXRpb247IHRoZXJlZm9yZQogICBubyBsYW5ndWFnZSB0 YWdnaW5nIGlzIGZvcmVzZWVuLikKCiAgIElmIGEgbWV0aG9kIG9yIHJlc3BvbnNlIGNvZGUgaXMg bm90IGRlZmluZWQgdG8gaGF2ZSBhIHBheWxvYWQsIHRoZW4KICAgdGhlIHNlbmRlciBTSE9VTEQg Tk9UIGluY2x1ZGUgb25lLCBhbmQgdGhlIHJlY2lwaWVudCBNVVNUIGlnbm9yZSBpdC4KCjUuNi4g IENhY2hpbmcKCiAgIENvQVAgZW5kLXBvaW50cyBNQVkgY2FjaGUgcmVzcG9uc2VzIGluIG9yZGVy IHRvIHJlZHVjZSB0aGUgcmVzcG9uc2UKICAgdGltZSBhbmQgbmV0d29yayBiYW5kd2lkdGggY29u c3VtcHRpb24gb24gZnV0dXJlLCBlcXVpdmFsZW50CiAgIHJlcXVlc3RzLgoKICAgVGhlIGdvYWwg b2YgY2FjaGluZyBpbiBDb0FQIGlzIHRvIHJldXNlIGEgcHJpb3IgcmVzcG9uc2UgbWVzc2FnZSB0 bwogICBzYXRpc2Z5IGEgY3VycmVudCByZXF1ZXN0LiAgSW4gc29tZSBjYXNlcywgYSBzdG9yZWQg cmVzcG9uc2UgY2FuIGJlCiAgIHJldXNlZCB3aXRob3V0IHRoZSBuZWVkIGZvciBhIG5ldHdvcmsg cmVxdWVzdCwgcmVkdWNpbmcgbGF0ZW5jeSBhbmQKICAgbmV0d29yayByb3VuZC10cmlwczsgYSAi ZnJlc2huZXNzIiBtZWNoYW5pc20gaXMgdXNlZCBmb3IgdGhpcyBwdXJwb3NlCiAgIChzZWUgU2Vj dGlvbiA1LjYuMSkuICBFdmVuIHdoZW4gYSBuZXcgcmVxdWVzdCBpcyByZXF1aXJlZCwgaXQgaXMK ICAgb2Z0ZW4gcG9zc2libGUgdG8gcmV1c2UgdGhlIHBheWxvYWQgb2YgYSBwcmlvciByZXNwb25z ZSB0byBzYXRpc2Z5CgoKClNoZWxieSwgZXQgYWwuICAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIg MTUsIDIwMTEgICAgICAgICAgICAgIFtQYWdlIDI1XQoMCkludGVybmV0LURyYWZ0ICAgQ29uc3Ry YWluZWQgQXBwbGljYXRpb24gUHJvdG9jb2wgKENvQVApICAgICAgTWFyY2ggMjAxMQoKCiAgIHRo ZSByZXF1ZXN0LCB0aGVyZWJ5IHJlZHVjaW5nIG5ldHdvcmsgYmFuZHdpZHRoIHVzYWdlOyBhICJ2 YWxpZGF0aW9uIgogICBtZWNoYW5pc20gaXMgdXNlZCBmb3IgdGhpcyBwdXJwb3NlIChzZWUgU2Vj dGlvbiA1LjYuMikuCgogICBVbmxpa2UgSFRUUCwgdGhlIGNhY2hlYWJpbGl0eSBvZiBDb0FQIHJl c3BvbnNlcyBkb2VzIG5vdCBkZXBlbmQgb24KICAgdGhlIHJlcXVlc3QgbWV0aG9kLCBidXQgdGhl IFJlc3BvbnNlIENvZGUuICBUaGUgY2FjaGVhYmlsaXR5IG9mIGVhY2gKICAgUmVzcG9uc2UgQ29k ZSBpcyBkZWZpbmVkIGFsb25nIHRoZSBSZXNwb25zZSBDb2RlIGRlZmluaXRpb25zIGluCiAgIFNl Y3Rpb24gNS45LiAgUmVzcG9uc2UgQ29kZXMgdGhhdCBpbmRpY2F0ZSBzdWNjZXNzIGFuZCBhcmUK ICAgdW5yZWNvZ25pemVkIGJ5IGFuIGVuZC1wb2ludCBNVVNUIE5PVCBiZSBjYWNoZWQuCgogICBG b3IgYSBwcmVzZW50ZWQgcmVxdWVzdCwgYSBDb0FQIGVuZC1wb2ludCBNVVNUIE5PVCB1c2UgYSBz dG9yZWQKICAgcmVzcG9uc2UsIHVubGVzczoKCiAgIG8gIHRoZSBwcmVzZW50ZWQgcmVxdWVzdCBt ZXRob2QgYW5kIHRoYXQgdXNlZCB0byBvYnRhaW4gdGhlIHN0b3JlZAogICAgICByZXNwb25zZSBt YXRjaCwKCiAgIG8gIGFsbCBvcHRpb25zIG1hdGNoIGJldHdlZW4gdGhvc2UgaW4gdGhlIHByZXNl bnRlZCByZXF1ZXN0IGFuZCB0aG9zZQogICAgICBvZiB0aGUgcmVxdWVzdCB1c2VkIHRvIG9idGFp biB0aGUgc3RvcmVkIHJlc3BvbnNlICh3aGljaCBpbmNsdWRlcwogICAgICB0aGUgcmVxdWVzdCBV UkkpLCBleGNlcHQgdGhhdCB0aGVyZSBpcyBubyBuZWVkIGZvciBhIG1hdGNoIG9mIHRoZQogICAg ICBUb2tlbiwgTWF4LUFnZSwgb3IgRVRhZyByZXF1ZXN0IG9wdGlvbihzKSwgYW5kCgogICBvICB0 aGUgc3RvcmVkIHJlc3BvbnNlIGlzIGVpdGhlciBmcmVzaCBvciBzdWNjZXNzZnVsbHkgdmFsaWRh dGVkIGFzCiAgICAgIGRlZmluZWQgYmVsb3cuCgo1LjYuMS4gIEZyZXNobmVzcyBNb2RlbAoKICAg V2hlbiBhIHJlc3BvbnNlIGlzICJmcmVzaCIgaW4gdGhlIGNhY2hlLCBpdCBjYW4gYmUgdXNlZCB0 byBzYXRpc2Z5CiAgIHN1YnNlcXVlbnQgcmVxdWVzdHMgd2l0aG91dCBjb250YWN0aW5nIHRoZSBv cmlnaW4gc2VydmVyLCB0aGVyZWJ5CiAgIGltcHJvdmluZyBlZmZpY2llbmN5LgoKICAgVGhlIG1l Y2hhbmlzbSBmb3IgZGV0ZXJtaW5pbmcgZnJlc2huZXNzIGlzIGZvciBhbiBvcmlnaW4gc2VydmVy IHRvCiAgIHByb3ZpZGUgYW4gZXhwbGljaXQgZXhwaXJhdGlvbiB0aW1lIGluIHRoZSBmdXR1cmUs IHVzaW5nIHRoZSBNYXgtQWdlCiAgIE9wdGlvbiAoc2VlIFNlY3Rpb24gNS4xMC41KS4gIFRoZSBN YXgtQWdlIE9wdGlvbiBpbmRpY2F0ZXMgdGhhdCB0aGUKICAgcmVzcG9uc2UgaXMgdG8gYmUgY29u c2lkZXJlZCBub3QgZnJlc2ggYWZ0ZXIgaXRzIGFnZSBpcyBncmVhdGVyIHRoYW4KICAgdGhlIHNw ZWNpZmllZCBudW1iZXIgb2Ygc2Vjb25kcy4KCiAgIEFzIHRoZSBNYXgtQWdlIE9wdGlvbiBkZWZh dWx0cyB0byBhIHZhbHVlIG9mIDYwLCBpZiBpdCBpcyBub3QgcHJlc2VudAogICBpbiBhIGNhY2hl YWJsZSByZXNwb25zZSwgdGhlbiB0aGUgcmVzcG9uc2UgaXMgY29uc2lkZXJlZCBub3QgZnJlc2gK ICAgYWZ0ZXIgaXRzIGFnZSBpcyBncmVhdGVyIHRoYW4gNjAgc2Vjb25kcy4gIElmIGFuIG9yaWdp biBzZXJ2ZXIgd2lzaGVzCiAgIHRvIHByZXZlbnQgY2FjaGluZywgaXQgTVVTVCBleHBsaWNpdGx5 IGluY2x1ZGUgYSBNYXgtQWdlIE9wdGlvbiB3aXRoCiAgIGEgdmFsdWUgb2YgemVybyBzZWNvbmRz LgoKNS42LjIuICBWYWxpZGF0aW9uIE1vZGVsCgogICBXaGVuIGFuIGVuZC1wb2ludCBoYXMgb25l IG9yIG1vcmUgc3RvcmVkIHJlc3BvbnNlcyBmb3IgYSBHRVQgcmVxdWVzdCwKICAgYnV0IGNhbm5v dCB1c2UgYW55IG9mIHRoZW0gKGUuZy4sIGJlY2F1c2UgdGhleSBhcmUgbm90IGZyZXNoKSwgaXQg Y2FuCiAgIHVzZSB0aGUgRVRhZyBPcHRpb24gaW4gdGhlIEdFVCByZXF1ZXN0IHRvIGdpdmUgdGhl IG9yaWdpbiBzZXJ2ZXIgYW4KICAgb3Bwb3J0dW5pdHkgdG8gYm90aCBzZWxlY3QgYSBzdG9yZWQg cmVzcG9uc2UgdG8gYmUgdXNlZCwgYW5kIHRvCiAgIHVwZGF0ZSBpdHMgZnJlc2huZXNzLiAgVGhp cyBwcm9jZXNzIGlzIGtub3duIGFzICJ2YWxpZGF0aW5nIiBvcgoKCgpTaGVsYnksIGV0IGFsLiAg ICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDE1LCAyMDExICAgICAgICAgICAgICBbUGFnZSAyNl0K DApJbnRlcm5ldC1EcmFmdCAgIENvbnN0cmFpbmVkIEFwcGxpY2F0aW9uIFByb3RvY29sIChDb0FQ KSAgICAgIE1hcmNoIDIwMTEKCgogICAicmV2YWxpZGF0aW5nIiB0aGUgc3RvcmVkIHJlc3BvbnNl LgoKICAgV2hlbiBzZW5kaW5nIHN1Y2ggYSByZXF1ZXN0LCB0aGUgZW5kLXBvaW50IFNIT1VMRCBh ZGQgYW4gRVRhZyBPcHRpb24KICAgc3BlY2lmeWluZyB0aGUgZW50aXR5LXRhZyBvZiBlYWNoIHN0 b3JlZCByZXNwb25zZSB0aGF0IGlzIGFwcGxpY2FibGUuCgogICBBIDIuMDMgKFZhbGlkKSByZXNw b25zZSBpbmRpY2F0ZXMgdGhlIHN0b3JlZCByZXNwb25zZSBpZGVudGlmaWVkIGJ5CiAgIHRoZSBl bnRpdHktdGFnIGdpdmVuIGluIHRoZSByZXNwb25zZSdzIEVUYWcgT3B0aW9uIGNhbiBiZSByZXVz ZWQsCiAgIGFmdGVyIHVwZGF0aW5nIGl0cyBmcmVzaG5lc3Mgd2l0aCB0aGUgdmFsdWUgb2YgdGhl IE1heC1BZ2UgT3B0aW9uCiAgIHRoYXQgaXMgaW5jbHVkZWQgd2l0aCB0aGUgcmVzcG9uc2UgKHNl ZSBTZWN0aW9uIDUuOS4xLjMpLgoKICAgQW55IG90aGVyIHJlc3BvbnNlIGNvZGUgaW5kaWNhdGVz IHRoYXQgbm9uZSBvZiB0aGUgc3RvcmVkIHJlc3BvbnNlcwogICBub21pbmF0ZWQgaW4gdGhlIHJl cXVlc3QgaXMgc3VpdGFibGUuICBJbnN0ZWFkLCB0aGUgcmVzcG9uc2UgU0hPVUxECiAgIGJlIHVz ZWQgdG8gc2F0aXNmeSB0aGUgcmVxdWVzdCBhbmQgTUFZIHJlcGxhY2UgdGhlIHN0b3JlZCByZXNw b25zZS4KCjUuNy4gIFByb3h5aW5nCgogICB7U2VjdGlvbiA4IGRlc2NyaWJlcyB0aGUgdXNlIG9m IHByb3hpZXMgZm9yIGNvYXAtaHR0cCBtYXBwaW5nLCBidXQKICAgSSBjYW4ndCBzZWUgYW55d2hl cmUgZWxzZSB3aGVyZSB0aGUgdXNlIG9mIHByb3hpZXMgaXMgZW52aXNhZ2VkLgogICBJbmRlZWQs IHRoZSBmYWN0IHRoYXQgYSBQcm94eS1VcmkgaXMgbm90IGJyb2tlbiBkb3duIGludG8gVXJpLUhv c3QsIAogICBVcmktUG9ydCwgVXJpLVBhdGggYW5kIFVyaS1RdWVyeSBvcHRpb25zIHN1Z2dlc3Rz IHRvIG1lIHRoYXQgdGhlCiAgIGF1dGhvcnMgd2VyZSBub3QgZW52aXNhZ2luZyB0aGUgdXNlIG9m IGNvYXAtY29hcCBwcm94aWVzLiBFaXRoZXIKICAgd2F5LCBJIGZlZWwgdGhhdCBpdCB3b3VsZCBi ZSB1c2VmdWwgdG8gcHJvdmlkZSBzb21lIHRleHQgaGVyZQogICBnaXZpbmcgZXhhbXBsZXMgb2Yg d2hlcmUgcHJveGllcyBtaWdodCBiZSB1c2VkLCBpZiBvdGhlciB0aGFuIHRoYW4gCiAgIHRoZSBj b2FwLWh0dHAgbWFwcGluZy4KICAgCiAgIE9uIHRoZSBvdGhlciBoYW5kLCBpZiBjb2FwLWNvYXAg cHJveGllcyBhcmUgZW52aXNhZ2VkLCB0aGVuIHNob3VsZCAKICAgUHJveHktVXJpIGJlIHJlcGxh Y2VkIGJ5IFByb3h5LVVyaS1Ib3N0LCBQcm94eS1VcmktUG9ydCwgCiAgIFByb3h5LVVyaS1QYXRo IGFuZCBQcm94eS1VcmktUXVlcnkgb3B0aW9ucyBzbyB0aGF0IGNvYXAgZGV2aWNlcyBkb24ndAog ICBoYXZlIHRvIHBhcnNlIHRoZSBQcm94eS1Vcmkgc3RyaW5nPwogICAKICAgT3IgbWF5YmUgdGhp cyBzZWN0aW9uIGlzIHJlYWxseSBqdXN0IGFib3V0ICJDb0FQLUNvQVAiIHByb3h5aW5nLiAKICAg U2hvdWxkIHdlIHNheSBzbz99CgogICBDb0FQIGRpc3Rpbmd1aXNoZXMgYmV0d2VlbiByZXF1ZXN0 cyB0byBhbiBvcmlnaW4gc2VydmVyIGFuZCBhIHJlcXVlc3QKICAgbWFkZSB0aHJvdWdoIGEgcHJv eHkuICBBIHByb3h5IGlzIGEgQ29BUCBlbmQtcG9pbnQgdGhhdCBjYW4gYmUgdGFza2VkCiAgIGJ5 IENvQVAgY2xpZW50cyB0byBwZXJmb3JtIHJlcXVlc3RzIG9uIHRoZWlyIGJlaGFsZi4gIFRoaXMg bWF5IGJlCiAgIHVzZWZ1bCwgZm9yIGV4YW1wbGUsIHdoZW4gdGhlIHJlcXVlc3QgY291bGQgb3Ro ZXJ3aXNlIG5vdCBiZSBtYWRlLCBvcgogICB0byBzZXJ2aWNlIHRoZSByZXNwb25zZSBmcm9tIGEg Y2FjaGUgaW4gb3JkZXIgdG8gcmVkdWNlIHJlc3BvbnNlIHRpbWUKICAgYW5kIG5ldHdvcmsgYmFu ZHdpZHRoIG9yIGVuZXJneSBjb25zdW1wdGlvbi4KCiAgIENvQVAgcmVxdWVzdHMgdG8gYSBwcm94 eSBhcmUgbWFkZSBhcyBub3JtYWwgY29uZmlybWFibGUgb3Igbm9uLQogICBjb25maXJtYWJsZSBy ZXF1ZXN0cyB0byB0aGUgcHJveHkgZW5kLXBvaW50LCBidXQgc3BlY2lmeSB0aGUgcmVxdWVzdAog ICBVUkkgaW4gYSBkaWZmZXJlbnQgd2F5OiBUaGUgcmVxdWVzdCBVUkkgaW4gYSBwcm94eSByZXF1 ZXN0IGlzCiAgIHNwZWNpZmllZCBhcyBhIHN0cmluZyBpbiB0aGUgUHJveHktVXJpIE9wdGlvbiAo c2VlIFNlY3Rpb24gNS4xMC4zKSwKICAgd2hpbGUgdGhlIHJlcXVlc3QgVVJJIGluIGEgcmVxdWVz dCB0byBhbiBvcmlnaW4gc2VydmVyIGlzIHNwbGl0IGludG8KICAgdGhlIFVyaS1Ib3N0LCBVcmkt UG9ydCwgVXJpLVBhdGggYW5kIFVyaS1RdWVyeSBPcHRpb25zIChzZWUKICAgU2VjdGlvbiA1LjEw LjIpLgoKICAgV2hlbiBhIHByb3h5IHJlcXVlc3QgaXMgbWFkZSB0byBhbiBlbmQtcG9pbnQgYW5k IHRoZSBlbmQtcG9pbnQgaXMKICAgdW53aWxsaW5nIG9yIHVuYWJsZSB0byBhY3QgYXMgcHJveHkg Zm9yIHRoZSByZXF1ZXN0IFVSSSwgaXQgTVVTVAogICByZXR1cm4gYSA1LjA1IChQcm94eWluZyBO b3QgU3VwcG9ydGVkKSByZXNwb25zZS4gIElmIHRoZSBhdXRob3JpdHkKICAgKGhvc3QgYW5kIHBv cnQpIGlzIHJlY29nbml6ZWQgYXMgaWRlbnRpZnlpbmcgdGhlIHByb3h5IGVuZC1wb2ludCwKICAg dGhlbiB0aGUgcmVxdWVzdCBNVVNUIGJlIHRyZWF0ZWQgYXMgYSBsb2NhbCByZXF1ZXN0LgoKICAg VW5sZXNzIGEgcHJveHkgaXMgY29uZmlndXJlZCB0byBmb3J3YXJkIHRoZSBwcm94eSByZXF1ZXN0 IHRvIGFub3RoZXIKICAgcHJveHksIGl0IE1VU1QgdHJhbnNsYXRlIHRoZSByZXF1ZXN0IGFzIGZv bGxvd3M6IFRoZSBvcmlnaW4gc2VydmVyJ3MKICAgSVAgYWRkcmVzcyBhbmQgcG9ydCBhcmUgZGV0 ZXJtaW5lZCBieSB0aGUgYXV0aG9yaXR5IGNvbXBvbmVudCBvZiB0aGUKICAgcmVxdWVzdCBVUkks IGFuZCB0aGUgcmVxdWVzdCBVUkkgaXMgZGVjb2RlZCBhbmQgc3BsaXQgaW50byB0aGUgVXJpLQog ICBIb3N0LCBVcmktUG9ydCwgVXJpLVBhdGggYW5kIFVyaS1RdWVyeSBPcHRpb25zLgoKICAgQWxs IG9wdGlvbnMgcHJlc2VudCBpbiBhIHByb3h5IHJlcXVlc3QgTVVTVCBiZSBwcm9jZXNzZWQgYXQg dGhlCiAgIHByb3h5LiAgQ3JpdGljYWwgb3B0aW9ucyBpbiBhIHJlcXVlc3QgdGhhdCBhcmUgbm90 IHJlY29nbml6ZWQgYnkgdGhlCiAgIHByb3h5IE1VU1QgbGVhZCB0byBhIDQuMDIgKEJhZCBPcHRp b24pIHJlc3BvbnNlIGJlaW5nIHJldHVybmVkIGJ5IHRoZQogICBwcm94eS4gIEVsZWN0aXZlIG9w dGlvbnMgbm90IHJlY29nbml6ZWQgYnkgdGhlIHByb3h5IE1VU1QgTk9UIGJlCiAgIGZvcndhcmRl ZCB0byB0aGUgb3JpZ2luIHNlcnZlci4gIFNpbWlsYXJseSwgY3JpdGljYWwgb3B0aW9ucyBpbiBh CgoKClNoZWxieSwgZXQgYWwuICAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMTUsIDIwMTEgICAg ICAgICAgICAgIFtQYWdlIDI3XQoMCkludGVybmV0LURyYWZ0ICAgQ29uc3RyYWluZWQgQXBwbGlj YXRpb24gUHJvdG9jb2wgKENvQVApICAgICAgTWFyY2ggMjAxMQoKCiAgIHJlc3BvbnNlIHRoYXQg YXJlIG5vdCByZWNvZ25pemVkIGJ5IHRoZSBwcm94eSBzZXJ2ZXIgTVVTVCBsZWFkIHRvIGEKICAg NS4wMiAoQmFkIEdhdGV3YXkpIHJlc3BvbnNlLiAgQWdhaW4sIGVsZWN0aXZlIG9wdGlvbnMgdGhh dCBhcmUgbm90CiAgIHJlY29nbml6ZWQgTVVTVCBOT1QgYmUgZm9yd2FyZGVkLgoKICAgSWYgdGhl IHByb3h5IGRvZXMgbm90IGVtcGxveSBhIGNhY2hlLCB0aGVuIGl0IHNpbXBseSBmb3J3YXJkcyB0 aGUKICAgdHJhbnNsYXRlZCByZXF1ZXN0IHRvIHRoZSBkZXRlcm1pbmVkIGRlc3RpbmF0aW9uLiAg T3RoZXJ3aXNlLCBpZiBpdAogICBkb2VzIGVtcGxveSBhIGNhY2hlIGJ1dCBkb2VzIG5vdCBoYXZl IGEgc3RvcmVkIHJlc3BvbnNlIHRoYXQgbWF0Y2hlcwogICB0aGUgdHJhbnNsYXRlZCByZXF1ZXN0 IGFuZCBpcyBjb25zaWRlcmVkIGZyZXNoLCB0aGVuIGl0IG5lZWRzIHRvCiAgIHJlZnJlc2ggaXRz IGNhY2hlIGFjY29yZGluZyB0byBTZWN0aW9uIDUuNi4KCiAgIElmIHRoZSByZXF1ZXN0IHRvIHRo ZSBkZXN0aW5hdGlvbiB0aW1lcyBvdXQsIHRoZW4gYSA1LjA0IChHYXRld2F5CiAgIFRpbWVvdXQp IHJlc3BvbnNlIE1VU1QgYmUgcmV0dXJuZWQuICBJZiB0aGUgcmVxdWVzdCB0byB0aGUKICAgZGVz dGluYXRpb24gcmV0dXJucyBhbiByZXNwb25zZSB0aGF0IGNhbm5vdCBiZSBwcm9jZXNzZWQgYnkg dGhlCiAgIHByb3h5LCB0aGVuIGEgNS4wMiAoQmFkIEdhdGV3YXkpIHJlc3BvbnNlIE1VU1QgYmUg cmV0dXJuZWQuCiAgIE90aGVyd2lzZSwgdGhlIHByb3h5IHJldHVybnMgdGhlIHJlc3BvbnNlIHRv IHRoZSBjbGllbnQuCgogICBJZiBhIHJlc3BvbnNlIGlzIGdlbmVyYXRlZCBvdXQgb2YgYSBjYWNo ZSwgaXQgTVVTVCBiZSBnZW5lcmF0ZWQgd2l0aAogICBhIE1heC1BZ2UgT3B0aW9uIHRoYXQgZG9l cyBub3QgZXh0ZW5kIHRoZSBtYXgtYWdlIG9yaWdpbmFsbHkgc2V0IGJ5CiAgIHRoZSBzZXJ2ZXIs IGNvbnNpZGVyaW5nIHRoZSB0aW1lIHRoZSByZXNvdXJjZSByZXByZXNlbnRhdGlvbiBzcGVudCBp bgogICB0aGUgY2FjaGUuICBFLmcuLCB0aGUgTWF4LUFnZSBPcHRpb24gY291bGQgYmUgYWRqdXN0 ZWQgYnkgdGhlIHByb3h5CiAgIGZvciBlYWNoIHJlc3BvbnNlIHVzaW5nIHRoZSBmb3JtdWxhOiBw cm94eS1tYXgtYWdlID0gb3JpZ2luYWwtbWF4LWFnZQogICAtIGNhY2hlLWFnZS4gIEZvciBleGFt cGxlIGlmIGEgcmVxdWVzdCBpcyBtYWRlIHRvIGEgcHJveGllZCByZXNvdXJjZQogICB0aGF0IHdh cyByZWZyZXNoZWQgMjAgc2Vjb25kcyBhZ28gYW5kIGhhZCBhbiBvcmlnaW5hbCBNYXgtQWdlIG9m IDYwCiAgIHNlY29uZHMsIHRoZW4gdGhhdCByZXNvdXJjZSdzIHByb3hpZWQgTWF4LUFnZSBpcyBu b3cgNDAgc2Vjb25kcy4KCjUuOC4gIE1ldGhvZCBEZWZpbml0aW9ucwoKICAgSW4gdGhpcyBzZWN0 aW9uIGVhY2ggbWV0aG9kIGlzIGRlZmluZWQgYWxvbmcgd2l0aCBpdHMgYmVoYXZpb3IuICBBCiAg IHJlcXVlc3Qgd2l0aCBhbiB1bnJlY29nbml6ZWQgb3IgdW5zdXBwb3J0ZWQgTWV0aG9kIENvZGUg TVVTVCBnZW5lcmF0ZQogICBhIDQuMDUgKE1ldGhvZCBOb3QgQWxsb3dlZCkgcmVzcG9uc2UuCgo1 LjguMS4gIEdFVAoKICAgVGhlIEdFVCBtZXRob2QgcmV0cmlldmVzIGEgcmVwcmVzZW50YXRpb24g Zm9yIHRoZSBpbmZvcm1hdGlvbiB0aGF0CiAgIGN1cnJlbnRseSBjb3JyZXNwb25kcyB0byB0aGUg cmVzb3VyY2UgaWRlbnRpZmllZCBieSB0aGUgcmVxdWVzdCBVUkkuCiAgIElmIHRoZSByZXF1ZXN0 IGluY2x1ZGVzIGFuIEVUYWcgT3B0aW9uLCB0aGUgR0VUIG1ldGhvZCByZXF1ZXN0cyB0aGF0CiAg IEVUYWcgYmUgdmFsaWRhdGVkIGFuZCB0aGF0IHRoZSByZXByZXNlbnRhdGlvbiBiZSB0cmFuc2Zl cnJlZCBvbmx5IGlmCiAgIHZhbGlkYXRpb24gZmFpbGVkLiAgVXBvbiBzdWNjZXNzIGEgMi4wNSAo Q29udGVudCkgb3IgMi4wMyAoVmFsaWQpCiAgIHJlc3BvbnNlIFNIT1VMRCBiZSBzZW50LgoKICAg VGhlIEdFVCBtZXRob2QgaXMgc2FmZSBhbmQgaWRlbXBvdGVudC4KCjUuOC4yLiAgUE9TVAoKICAg VGhlIFBPU1QgbWV0aG9kIHJlcXVlc3RzIHRoYXQgdGhlIHJlcHJlc2VudGF0aW9uIGVuY2xvc2Vk IGluIHRoZQogICByZXF1ZXN0IGJlIHByb2Nlc3NlZC4gIFRoZSBhY3R1YWwgZnVuY3Rpb24gcGVy Zm9ybWVkIGJ5IHRoZSBQT1NUCiAgIG1ldGhvZCBpcyBkZXRlcm1pbmVkIGJ5IHRoZSBvcmlnaW4g c2VydmVyIGFuZCBkZXBlbmRlbnQgb24gdGhlIHRhcmdldAogICByZXNvdXJjZS4gIEl0IHVzdWFs bHkgcmVzdWx0cyBpbiBhIG5ldyByZXNvdXJjZSBiZWluZyBjcmVhdGVkIG9yIHRoZQoKCgpTaGVs YnksIGV0IGFsLiAgICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDE1LCAyMDExICAgICAgICAgICAg ICBbUGFnZSAyOF0KDApJbnRlcm5ldC1EcmFmdCAgIENvbnN0cmFpbmVkIEFwcGxpY2F0aW9uIFBy b3RvY29sIChDb0FQKSAgICAgIE1hcmNoIDIwMTEKCgogICB0YXJnZXQgcmVzb3VyY2UgYmVpbmcg dXBkYXRlZC4KCiAgIElmIGEgcmVzb3VyY2UgaGFzIGJlZW4gY3JlYXRlZCBvbiB0aGUgc2VydmVy LCBhIDIuMDEgKENyZWF0ZWQpCiAgIHJlc3BvbnNlIHRoYXQgaW5jbHVkZXMgdGhlIFVSSSBvZiB0 aGUgbmV3IHJlc291cmNlIGluIGEgc2VxdWVuY2Ugb2YKICAgb25lIG9yIG1vcmUgTG9jYXRpb24t UGF0aCBPcHRpb25zIGFuZC9vciBhIExvY2F0aW9uLVF1ZXJ5IE9wdGlvbgogICBTSE9VTEQgYmUg cmV0dXJuZWQuICBJZiB0aGUgUE9TVCBzdWNjZWVkcyBidXQgZG9lcyBub3QgcmVzdWx0IGluIGEK ICAgbmV3IHJlc291cmNlIGJlaW5nIGNyZWF0ZWQgb24gdGhlIHNlcnZlciwgYSAyLjA0IChDaGFu Z2VkKSByZXNwb25zZQogICBTSE9VTEQgYmUgcmV0dXJuZWQuICBJZiB0aGUgUE9TVCBzdWNjZWVk cyBhbmQgcmVzdWx0cyBpbiB0aGUgdGFyZ2V0CiAgIHJlc291cmNlIGJlaW5nIGRlbGV0ZWQsIGEg Mi4wMiAoRGVsZXRlZCkgcmVzcG9uc2UgU0hPVUxEIGJlIHJldHVybmVkLgoKICAgSWYgdGhlIHJl cXVlc3QgcGFzc2VzIHRocm91Z2ggYSBjYWNoZSB0aGF0IGhhcyBvbmUgb3IgbW9yZSBzdG9yZWQK ICAgcmVzcG9uc2VzIGZvciB0aGUgcmVxdWVzdCBVUkksIHRob3NlIHN0b3JlZCByZXNwb25zZXMg U0hPVUxEIGJlCiAgIG1hcmtlZCBhcyBzdGFsZS4KCiAgIFBPU1QgaXMgbmVpdGhlciBzYWZlIG5v ciBpZGVtcG90ZW50LgoKNS44LjMuICBQVVQKCiAgIFRoZSBQVVQgbWV0aG9kIHJlcXVlc3RzIHRo YXQgdGhlIHJlc291cmNlIGlkZW50aWZpZWQgYnkgdGhlIHJlcXVlc3QKICAgVVJJIGJlIHVwZGF0 ZWQgb3IgY3JlYXRlZCB3aXRoIHRoZSBlbmNsb3NlZCByZXByZXNlbnRhdGlvbi4gIFRoZQogICBy ZXByZXNlbnRhdGlvbiBmb3JtYXQgaXMgc3BlY2lmaWVkIGJ5IHRoZSBtZWRpYSB0eXBlIGdpdmVu IGluIHRoZQogICBDb250ZW50LVR5cGUgT3B0aW9uLgoKICAgSWYgYSByZXNvdXJjZSBleGlzdHMg YXQgdGhlIHJlcXVlc3QgVVJJIHRoZSBlbmNsb3NlZCByZXByZXNlbnRhdGlvbgogICBTSE9VTEQg YmUgY29uc2lkZXJlZCBhIG1vZGlmaWVkIHZlcnNpb24gb2YgdGhhdCByZXNvdXJjZSwgYW5kIGEg Mi4wNAogICAoQ2hhbmdlZCkgcmVzcG9uc2UgU0hPVUxEIGJlIHJldHVybmVkLiAgSWYgbm8gcmVz b3VyY2UgZXhpc3RzIHRoZW4KICAgdGhlIHNlcnZlciBNQVkgY3JlYXRlIGEgbmV3IHJlc291cmNl IHdpdGggdGhhdCBVUkksIHJlc3VsdGluZyBpbiBhCiAgIDIuMDEgKENyZWF0ZWQpIHJlc3BvbnNl LiAgSWYgdGhlIHJlc291cmNlIGNvdWxkIG5vdCBiZSBjcmVhdGVkIG9yCiAgIG1vZGlmaWVkLCB0 aGVuIGFuIGFwcHJvcHJpYXRlIGVycm9yIHJlc3BvbnNlIGNvZGUgU0hPVUxEIGJlIHNlbnQuCiAg IAogICB7UXVlc3Rpb246IHNob3VsZCBQVVQgYmVoYXZlIHRoZSBzYW1lIHdheSBhcyBQT1NUIHdp dGggcmVzcGVjdCB0bwogICByZXR1cm5pbmcgdGhlIExvY2F0aW9uLVBhdGggT3B0aW9ucyBhbmQv b3IgYSBMb2NhdGlvbi1RdWVyeSBPcHRpb24KICAgaWYgYSBuZXcgcmVzb3VyY2UgaXMgY3JlYXRl ZD99CgogICBJZiB0aGUgcmVxdWVzdCBwYXNzZXMgdGhyb3VnaCBhIGNhY2hlIHRoYXQgaGFzIG9u ZSBvciBtb3JlIHN0b3JlZAogICByZXNwb25zZXMgZm9yIHRoZSByZXF1ZXN0IFVSSSwgdGhvc2Ug c3RvcmVkIHJlc3BvbnNlcyBTSE9VTEQgYmUKICAgbWFya2VkIGFzIHN0YWxlLgoKICAgUFVUIGlz IG5vdCBzYWZlLCBidXQgaWRlbXBvdGVudC4KCjUuOC40LiAgREVMRVRFCgogICBUaGUgREVMRVRF IG1ldGhvZCByZXF1ZXN0cyB0aGF0IHRoZSByZXNvdXJjZSBpZGVudGlmaWVkIGJ5IHRoZQogICBy ZXF1ZXN0IFVSSSBiZSBkZWxldGVkLiAgQSAyLjAyIChEZWxldGVkKSByZXNwb25zZSBTSE9VTEQg YmUgc2VudCBvbgogICBzdWNjZXNzIG9yIGluIGNhc2UgdGhlIHJlc291cmNlIGRpZCBub3QgZXhp c3QgYmVmb3JlIHRoZSByZXF1ZXN0LgoKICAgSWYgdGhlIHJlcXVlc3QgcGFzc2VzIHRocm91Z2gg YSBjYWNoZSBhbmQgdGhlIHJlcXVlc3QgVVJJIGlkZW50aWZpZXMKICAgb25lIG9yIG1vcmUgY3Vy cmVudGx5IHN0b3JlZCByZXNwb25zZXMsIHRob3NlIGVudHJpZXMgU0hPVUxEIGJlCiAgIG1hcmtl ZCBhcyBzdGFsZS4KCiAgIERFTEVURSBpcyBub3Qgc2FmZSwgYnV0IGlkZW1wb3RlbnQuCgoKCgpT aGVsYnksIGV0IGFsLiAgICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDE1LCAyMDExICAgICAgICAg ICAgICBbUGFnZSAyOV0KDApJbnRlcm5ldC1EcmFmdCAgIENvbnN0cmFpbmVkIEFwcGxpY2F0aW9u IFByb3RvY29sIChDb0FQKSAgICAgIE1hcmNoIDIwMTEKCgo1LjkuICBSZXNwb25zZSBDb2RlIERl ZmluaXRpb25zCgogICBFYWNoIHJlc3BvbnNlIGNvZGUgaXMgZGVzY3JpYmVkIGJlbG93LCBpbmNs dWRpbmcgYW55IG9wdGlvbnMgcmVxdWlyZWQKICAgaW4gdGhlIHJlc3BvbnNlLiAgV2hlcmUgYXBw cm9wcmlhdGUsIHNvbWUgb2YgdGhlIGNvZGVzIHdpbGwgYmUKICAgc3BlY2lmaWVkIGluIHJlZ2Fy ZHMgdG8gcmVsYXRlZCByZXNwb25zZSBjb2RlcyBpbiBIVFRQIFtSRkMyNjE2XTsKICAgdGhpcyBk b2VzIG5vdCBtZWFuIHRoYXQgYW55IHN1Y2ggcmVsYXRpb25zaGlwIG1vZGlmaWVzIHRoZSBIVFRQ CiAgIG1hcHBpbmcgc3BlY2lmaWVkIGluIFNlY3Rpb24gOC4KCjUuOS4xLiAgU3VjY2VzcyAyLnh4 CgogICBUaGlzIGNsYXNzIG9mIHN0YXR1cyBjb2RlIGluZGljYXRlcyB0aGF0IHRoZSBjbGllbnRz IHJlcXVlc3Qgd2FzCiAgIHN1Y2Nlc3NmdWxseSByZWNlaXZlZCwgdW5kZXJzdG9vZCwgYW5kIGFj Y2VwdGVkLgoKNS45LjEuMS4gIDIuMDEgQ3JlYXRlZAoKICAgTGlrZSBIVFRQIDIwMSAiQ3JlYXRl ZCIsIGJ1dCBvbmx5IHVzZWQgaW4gcmVzcG9uc2UgdG8gUE9TVCBhbmQgUFVUCiAgIHJlcXVlc3Rz LgoKICAgSWYgdGhlIHJlc3BvbnNlIGluY2x1ZGVzIG9uZSBvciBtb3JlIExvY2F0aW9uLVBhdGgg T3B0aW9ucyBhbmQvb3IgYQogICBMb2NhdGlvbi1RdWVyeSBPcHRpb24sIHRoZSB2YWx1ZXMgb2Yg dGhlc2Ugb3B0aW9ucyBzcGVjaWZ5IHRoZQogICBsb2NhdGlvbiBhdCB3aGljaCB0aGUgcmVzb3Vy Y2Ugd2FzIGNyZWF0ZWQuICBPdGhlcndpc2UsIHRoZSByZXNvdXJjZQogICB3YXMgY3JlYXRlZCBh dCB0aGUgcmVxdWVzdCBVUkkuICBBIGNhY2hlIFNIT1VMRCBtYXJrIGFueSBzdG9yZWQKICAgcmVz cG9uc2UgZm9yIHRoZSBsb2NhdGlvbiBhcyBub3QgZnJlc2guCiAgIAogICB7UGVkYW50aWNhbGx5 LCBwcmVzdWFtYmx5IHRoZSBMb2NhdGlvbi1RdWVyeSBkb2VzIG5vdCAic3BlY2lmeSB0aGUKICAg bG9jYXRpb24gYXQgd2hpY2ggdGhlIHJlc291cmNlIHdhcyBjcmVhdGVkIi4gU2hvdWxkIGl0IGJl IGdpdmVuIGEgCiAgIGRpZmZlcmVudCBkZXNjcmlwdGlvbj99CgogICBUaGlzIHJlc3BvbnNlIGlz IG5vdCBjYWNoZWFibGUuCgo1LjkuMS4yLiAgMi4wMiBEZWxldGVkCgogICBMaWtlIEhUVFAgMjA0 ICJObyBDb250ZW50IiwgYnV0IG9ubHkgdXNlZCBpbiByZXNwb25zZSB0byBERUxFVEUKICAgcmVx dWVzdHMuCgogICBUaGlzIHJlc3BvbnNlIGlzIG5vdCBjYWNoZWFibGUuCgo1LjkuMS4zLiAgMi4w MyBWYWxpZAoKICAgUmVsYXRlZCB0byBIVFRQIDMwNCAiTm90IE1vZGlmaWVkIiwgYnV0IG9ubHkg dXNlZCB0byBpbmRpY2F0ZSB0aGF0CiAgIHRoZSByZXNwb25zZSBpZGVudGlmaWVkIGJ5IHRoZSBl bnRpdHktdGFnIGlkZW50aWZpZWQgYnkgdGhlIGluY2x1ZGVkCiAgIEVUYWcgT3B0aW9uIGlzIHZh bGlkLiAgQWNjb3JkaW5nbHksIHRoZSByZXNwb25zZSBNVVNUIGluY2x1ZGUgYW4gRVRhZwogICBP cHRpb24uCgogICBXaGVuIGEgY2FjaGUgcmVjZWl2ZXMgYSAyLjAzIChWYWxpZCkgcmVzcG9uc2Us IGl0IG5lZWRzIHRvIHVwZGF0ZSB0aGUKICAgc3RvcmVkIHJlc3BvbnNlIHdpdGggdGhlIHZhbHVl IG9mIHRoZSBNYXgtQWdlIE9wdGlvbiBpbmNsdWRlZCBpbiB0aGUKICAgcmVzcG9uc2UgKHNlZSBT ZWN0aW9uIDUuNi4yKS4KCjUuOS4xLjQuICAyLjA0IENoYW5nZWQKCiAgIExpa2UgSFRUUCAyMDQg Ik5vIENvbnRlbnQiLCBidXQgb25seSB1c2VkIGluIHJlc3BvbnNlIHRvIFBPU1QgYW5kIFBVVAog ICByZXF1ZXN0cy4KCgoKU2hlbGJ5LCBldCBhbC4gICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAx NSwgMjAxMSAgICAgICAgICAgICAgW1BhZ2UgMzBdCgwKSW50ZXJuZXQtRHJhZnQgICBDb25zdHJh aW5lZCBBcHBsaWNhdGlvbiBQcm90b2NvbCAoQ29BUCkgICAgICBNYXJjaCAyMDExCgoKICAgVGhp cyByZXNwb25zZSBpcyBub3QgY2FjaGVhYmxlLgoKNS45LjEuNS4gIDIuMDUgQ29udGVudAoKICAg TGlrZSBIVFRQIDIwMCAiT0siLCBidXQgb25seSB1c2VkIGluIHJlc3BvbnNlIHRvIEdFVCByZXF1 ZXN0cy4KCiAgIFRoZSBwYXlsb2FkIHJldHVybmVkIHdpdGggdGhlIHJlc3BvbnNlIGlzIGEgcmVw cmVzZW50YXRpb24gb2YgdGhlCiAgIHRhcmdldCByZXNvdXJjZS4gIFRoZSByZXByZXNlbnRhdGlv biBmb3JtYXQgaXMgc3BlY2lmaWVkIGJ5IHRoZSBtZWRpYQogICB0eXBlIGdpdmVuIGluIHRoZSBD b250ZW50LVR5cGUgT3B0aW9uLgoKICAgVGhpcyByZXNwb25zZSBpcyBjYWNoZWFibGU6IENhY2hl cyBjYW4gdXNlIHRoZSBNYXgtQWdlIE9wdGlvbiB0bwogICBkZXRlcm1pbmUgZnJlc2huZXNzIChz ZWUgU2VjdGlvbiA1LjYuMSkgYW5kIChpZiBwcmVzZW50KSB0aGUgRVRhZwogICBPcHRpb24gZm9y IHZhbGlkYXRpb24gKHNlZSBTZWN0aW9uIDUuNi4yKS4KCjUuOS4yLiAgQ2xpZW50IEVycm9yIDQu eHgKCiAgIFRoaXMgY2xhc3Mgb2YgcmVzcG9uc2UgY29kZSBpcyBpbnRlbmRlZCBmb3IgY2FzZXMg aW4gd2hpY2ggdGhlIGNsaWVudAogICBzZWVtcyB0byBoYXZlIGVycmVkLiAgVGhlc2UgcmVzcG9u c2UgY29kZXMgYXJlIGFwcGxpY2FibGUgdG8gYW55CiAgIHJlcXVlc3QgbWV0aG9kLgoKICAgVGhl IHNlcnZlciBTSE9VTEQgaW5jbHVkZSBhIGJyaWVmIGh1bWFuLXJlYWRhYmxlIG1lc3NhZ2UgYXMg cGF5bG9hZCwKICAgYXMgZGV0YWlsZWQgaW4gU2VjdGlvbiA1LjUuCgogICBSZXNwb25zZXMgb2Yg dGhpcyBjbGFzcyBhcmUgY2FjaGVhYmxlOiBDYWNoZXMgY2FuIHVzZSB0aGUgTWF4LUFnZQogICBP cHRpb24gdG8gZGV0ZXJtaW5lIGZyZXNobmVzcyAoc2VlIFNlY3Rpb24gNS42LjEpLiAgVGhleSBj YW5ub3QgYmUKICAgdmFsaWRhdGVkLgoKNS45LjIuMS4gIDQuMDAgQmFkIFJlcXVlc3QKCiAgIExp a2UgSFRUUCA0MDAgIkJhZCBSZXF1ZXN0Ii4KCjUuOS4yLjIuICA0LjAxIFVuYXV0aG9yaXplZAoK ICAgVGhlIGNsaWVudCBpcyBub3QgYXV0aG9yaXplZCB0byBwZXJmb3JtIHRoZSByZXF1ZXN0ZWQg YWN0aW9uLiAgVGhlCiAgIGNsaWVudCBTSE9VTEQgTk9UIHJlcGVhdCB0aGUgcmVxdWVzdCB3aXRo b3V0IHByZXZpb3VzbHkgaW1wcm92aW5nIGl0cwogICBhdXRoZW50aWNhdGlvbiBzdGF0dXMgdG8g dGhlIHNlcnZlci4gIFdoaWNoIHNwZWNpZmljIG1lY2hhbmlzbSBjYW4gYmUKICAgdXNlZCBmb3Ig dGhpcyBpcyBvdXRzaWRlIHRoaXMgZG9jdW1lbnQncyBzY29wZTsgc2VlIGFsc28gU2VjdGlvbiAx MC4KCjUuOS4yLjMuICA0LjAyIEJhZCBPcHRpb24KCiAgIFRoZSByZXF1ZXN0IGNvdWxkIG5vdCBi ZSB1bmRlcnN0b29kIGJ5IHRoZSBzZXJ2ZXIgZHVlIHRvIG9uZSBvciBtb3JlCiAgIHVucmVjb2du aXplZCBvciBtYWxmb3JtZWQgY3JpdGljYWwgb3B0aW9ucy4gIFRoZSBjbGllbnQgU0hPVUxEIE5P VAogICByZXBlYXQgdGhlIHJlcXVlc3Qgd2l0aG91dCBtb2RpZmljYXRpb24uCgo1LjkuMi40LiAg NC4wMyBGb3JiaWRkZW4KCiAgIExpa2UgSFRUUCA0MDMgIkZvcmJpZGRlbiIuCgoKClNoZWxieSwg ZXQgYWwuICAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMTUsIDIwMTEgICAgICAgICAgICAgIFtQ YWdlIDMxXQoMCkludGVybmV0LURyYWZ0ICAgQ29uc3RyYWluZWQgQXBwbGljYXRpb24gUHJvdG9j b2wgKENvQVApICAgICAgTWFyY2ggMjAxMQoKCjUuOS4yLjUuICA0LjA0IE5vdCBGb3VuZAoKICAg TGlrZSBIVFRQIDQwNCAiTm90IEZvdW5kIi4KCjUuOS4yLjYuICA0LjA1IE1ldGhvZCBOb3QgQWxs b3dlZAoKICAgTGlrZSBIVFRQIDQwNSAiTWV0aG9kIE5vdCBBbGxvd2VkIiwgYnV0IHdpdGggbm8g cGFyYWxsZWwgdG8gdGhlCiAgICJBY2NlcHQiIGhlYWRlciBmaWVsZC4KCjUuOS4yLjcuICA0LjEz IFJlcXVlc3QgRW50aXR5IFRvbyBMYXJnZQoKICAgTGlrZSBIVFRQIDQxMyAiUmVxdWVzdCBFbnRp dHkgVG9vIExhcmdlIi4KCjUuOS4yLjguICA0LjE1IFVuc3VwcG9ydGVkIE1lZGlhIFR5cGUKCiAg IExpa2UgSFRUUCA0MTUgIlVuc3VwcG9ydGVkIE1lZGlhIFR5cGUiLgoKNS45LjMuICBTZXJ2ZXIg RXJyb3IgNS54eAoKICAgVGhpcyBjbGFzcyBvZiByZXNwb25zZSBjb2RlIGluZGljYXRlcyBjYXNl cyBpbiB3aGljaCB0aGUgc2VydmVyIGlzCiAgIGF3YXJlIHRoYXQgaXQgaGFzIGVycmVkIG9yIGlz IGluY2FwYWJsZSBvZiBwZXJmb3JtaW5nIHRoZSByZXF1ZXN0LgogICBUaGVzZSByZXNwb25zZSBj b2RlcyBhcmUgYXBwbGljYWJsZSB0byBhbnkgcmVxdWVzdCBtZXRob2QuCgogICBUaGUgc2VydmVy IFNIT1VMRCBpbmNsdWRlIGEgaHVtYW4tcmVhZGFibGUgbWVzc2FnZSBhcyBwYXlsb2FkLCBhcwog ICBkZXRhaWxlZCBpbiBTZWN0aW9uIDUuNS4KCiAgIFJlc3BvbnNlcyBvZiB0aGlzIGNsYXNzIGFy ZSBjYWNoZWFibGU6IENhY2hlcyBjYW4gdXNlIHRoZSBNYXgtQWdlCiAgIE9wdGlvbiB0byBkZXRl cm1pbmUgZnJlc2huZXNzIChzZWUgU2VjdGlvbiA1LjYuMSkuICBUaGV5IGNhbm5vdCBiZQogICB2 YWxpZGF0ZWQuCgo1LjkuMy4xLiAgNS4wMCBJbnRlcm5hbCBTZXJ2ZXIgRXJyb3IKCiAgIExpa2Ug SFRUUCA1MDAgIkludGVybmFsIFNlcnZlciBFcnJvciIuCgo1LjkuMy4yLiAgNS4wMSBOb3QgSW1w bGVtZW50ZWQKCiAgIExpa2UgSFRUUCA1MDEgIk5vdCBJbXBsZW1lbnRlZCIuCgo1LjkuMy4zLiAg NS4wMiBCYWQgR2F0ZXdheQoKICAgTGlrZSBIVFRQIDUwMiAiQmFkIEdhdGV3YXkiLgoKNS45LjMu NC4gIDUuMDMgU2VydmljZSBVbmF2YWlsYWJsZQoKICAgTGlrZSBIVFRQIDUwMyAiU2VydmljZSBV bmF2YWlsYWJsZSIsIGJ1dCB1c2luZyB0aGUgTWF4LUFnZSBPcHRpb24gaW4KICAgcGxhY2Ugb2Yg dGhlICJSZXRyeS1BZnRlciIgaGVhZGVyIGZpZWxkLgoKCgoKClNoZWxieSwgZXQgYWwuICAgICAg ICAgRXhwaXJlcyBTZXB0ZW1iZXIgMTUsIDIwMTEgICAgICAgICAgICAgIFtQYWdlIDMyXQoMCklu dGVybmV0LURyYWZ0ICAgQ29uc3RyYWluZWQgQXBwbGljYXRpb24gUHJvdG9jb2wgKENvQVApICAg ICAgTWFyY2ggMjAxMQoKCjUuOS4zLjUuICA1LjA0IEdhdGV3YXkgVGltZW91dAoKICAgTGlrZSBI VFRQIDUwNCAiR2F0ZXdheSBUaW1lb3V0Ii4KCjUuOS4zLjYuICA1LjA1IFByb3h5aW5nIE5vdCBT dXBwb3J0ZWQKCiAgIFRoZSBzZXJ2ZXIgaXMgdW5hYmxlIG9yIHVud2lsbGluZyB0byBhY3QgYXMg YSBwcm94eSBmb3IgdGhlIFVSSQogICBzcGVjaWZpZWQgaW4gdGhlIFByb3h5LVVyaSBPcHRpb24g KHNlZSBTZWN0aW9uIDUuMTAuMykuCgo1LjEwLiAgT3B0aW9uIERlZmluaXRpb25zCgogICBUaGUg aW5kaXZpZHVhbCBDb0FQIG9wdGlvbnMgYXJlIHN1bW1hcml6ZWQgaW4gVGFibGUgMSBhbmQgZXhw bGFpbmVkCiAgIGJlbG93LgoKICAgKy0tLS0tKy0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLSst LS0tLS0tLSstLS0tLS0tLS0rLS0tLS0tLS0tLS0tLSsKICAgfCBOby4gfCBDL0UgICAgICB8IE5h bWUgICAgICAgICAgIHwgRm9ybWF0IHwgTGVuZ3RoICB8IERlZmF1bHQgICAgIHwKICAgKy0tLS0t Ky0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLSstLS0tLS0tLS0rLS0tLS0tLS0t LS0tLSsKICAgfCAgIDEgfCBDcml0aWNhbCB8IENvbnRlbnQtVHlwZSAgIHwgdWludCAgIHwgMS0y IEIgICB8IDAgICAgICAgICAgIHwKICAgfCAgIDIgfCBFbGVjdGl2ZSB8IE1heC1BZ2UgICAgICAg IHwgdWludCAgIHwgMC00IEIgICB8IDYwICAgICAgICAgIHwKICAgfCAgIDMgfCBDcml0aWNhbCB8 IFByb3h5LVVyaSAgICAgIHwgc3RyaW5nIHwgMS0yNzAgQiB8IChub25lKSAgICAgIHwKICAgfCAg IDQgfCBFbGVjdGl2ZSB8IEVUYWcgICAgICAgICAgIHwgb3BhcXVlIHwgMS04IEIgICB8IChub25l KSAgICAgIHwKICAgfCAgIDUgfCBDcml0aWNhbCB8IFVyaS1Ib3N0ICAgICAgIHwgc3RyaW5nIHwg MS0yNzAgQiB8IChzZWUgYmVsb3cpIHwKICAgfCAgIDYgfCBFbGVjdGl2ZSB8IExvY2F0aW9uLVBh dGggIHwgc3RyaW5nIHwgMS0yNzAgQiB8IChub25lKSAgICAgIHwKICAgfCAgIDcgfCBDcml0aWNh bCB8IFVyaS1Qb3J0ICAgICAgIHwgdWludCAgIHwgMC0yIEIgICB8IChzZWUgYmVsb3cpIHwKICAg fCAgIDggfCBFbGVjdGl2ZSB8IExvY2F0aW9uLVF1ZXJ5IHwgc3RyaW5nIHwgMS0yNzAgQiB8IChu b25lKSAgICAgIHwKICAgfCAgIDkgfCBDcml0aWNhbCB8IFVyaS1QYXRoICAgICAgIHwgc3RyaW5n IHwgMS0yNzAgQiB8IChub25lKSAgICAgIHwKICAgfCAgMTEgfCBDcml0aWNhbCB8IFRva2VuICAg ICAgICAgIHwgb3BhcXVlIHwgMS04IEIgICB8IChlbXB0eSkgICAgIHwKICAgfCAgMTUgfCBDcml0 aWNhbCB8IFVyaS1RdWVyeSAgICAgIHwgc3RyaW5nIHwgMS0yNzAgQiB8IChub25lKSAgICAgIHwK ICAgKy0tLS0tKy0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLSstLS0tLS0tLS0r LS0tLS0tLS0tLS0tLSsKCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVGFibGUgMTogT3B0 aW9ucwoKNS4xMC4xLiAgVG9rZW4KCiAgIFRoZSBUb2tlbiBPcHRpb24gaXMgdXNlZCB0byBtYXRj aCBhIHJlc3BvbnNlIHdpdGggYSByZXF1ZXN0LiAgRXZlcnkKICAgcmVxdWVzdCBoYXMgYSBjbGll bnQtZ2VuZXJhdGVkIHRva2VuIHdoaWNoIHRoZSBzZXJ2ZXIgTVVTVCBlY2hvIGluCiAgIGFueSBy ZXNwb25zZS4KCiAgIEEgdG9rZW4gaXMgaW50ZW5kZWQgZm9yIHVzZSBhcyBhIGNsaWVudC1sb2Nh bCBpZGVudGlmaWVyIGZvcgogICBkaWZmZXJlbnRpYXRpbmcgYmV0d2VlbiBjb25jdXJyZW50IHJl cXVlc3RzLiAgQSBjbGllbnQgU0hPVUxECiAgIGdlbmVyYXRlIHRva2VucyBpbiBhIHdheSB0aGF0 IHRva2VucyBjdXJyZW50bHkgaW4gdXNlIGZvciBhIGdpdmVuCiAgIHNvdXJjZS9kZXN0aW5hdGlv biBwYWlyIGFyZSB1bmlxdWUuICBBbiBlbmQtcG9pbnQgcmVjZWl2aW5nIGEgdG9rZW4KICAgTVVT VCB0cmVhdCBpdCBhcyBvcGFxdWUgYW5kIG1ha2Ugbm8gYXNzdW1wdGlvbnMgYWJvdXQgaXRzIGZv cm1hdC4KCiAgIEEgZGVmYXVsdCB2YWx1ZSBvZiBhIHplcm8tbGVuZ3RoIHRva2VuIGlzIGFzc3Vt ZWQgaW4gdGhlIGFic2VuY2Ugb2YKICAgdGhlIG9wdGlvbi4KCiAgIFRoaXMgb3B0aW9uIGlzICJj cml0aWNhbCIuICBJdCBNVVNUIE5PVCBvY2N1ciBtb3JlIHRoYW4gb25jZS4KCgoKU2hlbGJ5LCBl dCBhbC4gICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAxNSwgMjAxMSAgICAgICAgICAgICAgW1Bh Z2UgMzNdCgwKSW50ZXJuZXQtRHJhZnQgICBDb25zdHJhaW5lZCBBcHBsaWNhdGlvbiBQcm90b2Nv bCAoQ29BUCkgICAgICBNYXJjaCAyMDExCgoKNS4xMC4yLiAgVXJpLUhvc3QsIFVyaS1Qb3J0LCBV cmktUGF0aCBhbmQgVXJpLVF1ZXJ5CgogICBUaGUgVXJpLUhvc3QsIFVyaS1Qb3J0LCBVcmktUGF0 aCBhbmQgVXJpLVF1ZXJ5IE9wdGlvbnMgYXJlIHVzZWQgdG8KICAgc3BlY2lmeSB0aGUgdGFyZ2V0 IHJlc291cmNlIG9mIGEgcmVxdWVzdCB0byBhIENvQVAgb3JpZ2luIHNlcnZlci4KICAgVGhlIG9w dGlvbnMgZW5jb2RlIHRoZSBkaWZmZXJlbnQgY29tcG9uZW50cyBvZiB0aGUgcmVxdWVzdCBVUkkg aW4gYQogICB3YXkgdGhhdCBubyBwZXJjZW50LWVuY29kaW5nIGlzIHZpc2libGUgaW4gdGhlIG9w dGlvbiB2YWx1ZXMgKGV4Y2VwdAogICBmb3IgVXJpLVF1ZXJ5KSBhbmQgdGhhdCB0aGUgZnVsbCBV UkkgY2FuIGJlIHJlY29uc3RydWN0ZWQgYXQgYW55CiAgIGludm9sdmVkIGVuZC1wb2ludC4gIFRo ZSBzeW50YXggb2YgQ29BUCBVUklzIGlzIGRlZmluZWQgaW4gU2VjdGlvbiA2LgoKICAgVGhlIHN0 ZXBzIGZvciBwYXJzaW5nIFVSSXMgaW50byBvcHRpb25zIGlzIGRlZmluZWQgaW4gU2VjdGlvbiA2 LjMuCiAgIFRoZXNlIHN0ZXBzIHJlc3VsdCBpbiB6ZXJvIG9yIG1vcmUgVXJpLUhvc3QsIFVyaS1Q b3J0LCBVcmktUGF0aCBhbmQKICAgVXJpLVF1ZXJ5IE9wdGlvbnMgYmVpbmcgaW5jbHVkZWQgaW4g YSByZXF1ZXN0LCB3aGVyZSBlYWNoIG9wdGlvbgogICBob2xkcyB0aGUgZm9sbG93aW5nIHZhbHVl czoKCiAgIG8gIHRoZSBVcmktSG9zdCBPcHRpb24gc3BlY2lmaWVzIHRoZSBJbnRlcm5ldCBob3N0 IG9mIHRoZSByZXNvdXJjZQogICAgICBiZWluZyByZXF1ZXN0ZWQsCgogICBvICB0aGUgVXJpLVBv cnQgT3B0aW9uIHNwZWNpZmllcyB0aGUgcG9ydCBudW1iZXIgb2YgdGhlIHJlc291cmNlLAoKICAg byAgZWFjaCBVcmktUGF0aCBPcHRpb24gc3BlY2lmaWVzIG9uZSBzZWdtZW50IG9mIHRoZSBhYnNv bHV0ZSBwYXRoIHRvCiAgICAgIHRoZSByZXNvdXJjZSwgYW5kCgogICBvICB0aGUgVXJpLVF1ZXJ5 IE9wdGlvbiBzcGVjaWZpZXMgdGhlIHF1ZXJ5LgoKICAgTm90ZTogRnJhZ21lbnRzIChbUkZDMzk4 Nl0sIFNlY3Rpb24gMy41KSBhcmUgbm90IHBhcnQgb2YgdGhlIHJlcXVlc3QKICAgVVJJIGFuZCB0 aHVzIHdpbGwgbm90IGJlIHRyYW5zbWl0dGVkIGluIGEgQ29BUCByZXF1ZXN0LgoKICAgVGhlIGRl ZmF1bHQgdmFsdWUgb2YgdGhlIFVyaS1Ib3N0IE9wdGlvbiBpcyB0aGUgSVAgbGl0ZXJhbAogICBy ZXByZXNlbnRpbmcgdGhlIGRlc3RpbmF0aW9uIElQIGFkZHJlc3Mgb2YgdGhlIHJlcXVlc3QgbWVz c2FnZS4KICAgTGlrZXdpc2UsIHRoZSBkZWZhdWx0IHZhbHVlIG9mIHRoZSBVcmktUG9ydCBPcHRp b24gaXMgdGhlIGRlc3RpbmF0aW9uCiAgIFVEUCBwb3J0LgoKICAgVGhlIFVyaS1QYXRoIE9wdGlv biBjYW4gY29udGFpbiBhbnkgY2hhcmFjdGVyIHNlcXVlbmNlLiAgTm8gcGVyY2VudC0KICAgZW5j b2RpbmcgaXMgcGVyZm9ybWVkLiAgVGhlIHZhbHVlIE1VU1QgTk9UIGJlICIuIiBvciAiLi4iIChh cyB0aGUKICAgcmVxdWVzdCBVUkkgbXVzdCBiZSByZXNvbHZlZCBiZWZvcmUgcGFyc2luZyBpdCBp bnRvIG9wdGlvbnMpLgoKICAgVGhlIHN0ZXBzIGZvciBjb25zdHJ1Y3RpbmcgdGhlIHJlcXVlc3Qg VVJJIGZyb20gdGhlIG9wdGlvbnMgYXJlCiAgIGRlZmluZWQgaW4gU2VjdGlvbiA2LjQuICBOb3Rl IHRoYXQgYW4gaW1wbGVtZW50YXRpb24gZG9lcyBub3QKICAgbmVjZXNzYXJpbHkgaGF2ZSB0byBj b25zdHJ1Y3QgdGhlIFVSSTsgaXQgY2FuIHNpbXBseSBsb29rIHVwIHRoZQogICB0YXJnZXQgcmVz b3VyY2UgYnkgbG9va2luZyBhdCB0aGUgaW5kaXZpZHVhbCBvcHRpb25zLgoKICAgRXhhbXBsZXMg Y2FuIGJlIGZvdW5kIGluIEFwcGVuZGl4IEMuCgogICBBbGwgb2YgdGhlIG9wdGlvbnMgYXJlICJj cml0aWNhbCIuICBVcmktSG9zdCwgVXJpLVBvcnQgYW5kIFVyaS1RdWVyeQogICBNVVNUIE5PVCBv Y2N1ciBtb3JlIHRoYW4gb25jZTsgVXJpLVBhdGggTUFZIG9jY3VyIG9uZSBvciBtb3JlIHRpbWVz LgoKCgoKCgpTaGVsYnksIGV0IGFsLiAgICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDE1LCAyMDEx ICAgICAgICAgICAgICBbUGFnZSAzNF0KDApJbnRlcm5ldC1EcmFmdCAgIENvbnN0cmFpbmVkIEFw cGxpY2F0aW9uIFByb3RvY29sIChDb0FQKSAgICAgIE1hcmNoIDIwMTEKCgo1LjEwLjMuICBQcm94 eS1VcmkKCiAgIFRoZSBQcm94eS1VcmkgT3B0aW9uIGlzIHVzZWQgdG8gbWFrZSBhIHJlcXVlc3Qg dG8gYSBwcm94eSAoc2VlCiAgIFNlY3Rpb24gNS43KS4gIFRoZSBwcm94eSBpcyByZXF1ZXN0ZWQg dG8gZm9yd2FyZCB0aGUgcmVxdWVzdCBvcgogICBzZXJ2aWNlIGl0IGZyb20gYSB2YWxpZCBjYWNo ZSwgYW5kIHJldHVybiB0aGUgcmVzcG9uc2UuCgogICBUaGUgb3B0aW9uIHZhbHVlIGlzIGFuIGFi c29sdXRlLVVSSSAoW1JGQzM5ODZdLCBTZWN0aW9uIDQuMykuICBJbgogICBjYXNlIHRoZSBhYnNv bHV0ZS1VUkkgZG9lc24ndCBmaXQgd2l0aGluIGEgc2luZ2xlIG9wdGlvbiwgdGhlIFByb3h5LQog ICBVcmkgT3B0aW9uIE1BWSBiZSBpbmNsdWRlZCBtdWx0aXBsZSB0aW1lcyBpbiBhIHJlcXVlc3Qg c3VjaCB0aGF0IHRoZQogICBjb25jYXRlbmF0aW9uIG9mIHRoZSB2YWx1ZXMgcmVzdWx0cyBpbiB0 aGUgc2luZ2xlIGFic29sdXRlLVVSSS4KCiAgIEFsbCBidXQgdGhlIGxhc3QgaW5zdGFuY2Ugb2Yg dGhlIFByb3h5LVVyaSBPcHRpb24gTVVTVCBoYXZlIGEgdmFsdWUKICAgd2l0aCBhIGxlbmd0aCBv ZiAyNzAgYnl0ZXMsIGFuZCB0aGUgbGFzdCBpbnN0YW5jZSBNVVNUIE5PVCBiZSBlbXB0eS4KCiAg IE5vdGUgdGhhdCB0aGUgcHJveHkgTUFZIGZvcndhcmQgdGhlIHJlcXVlc3Qgb24gdG8gYW5vdGhl ciBwcm94eSBvcgogICBkaXJlY3RseSB0byB0aGUgc2VydmVyIHNwZWNpZmllZCBieSB0aGUgYWJz b2x1dGUtVVJJLiAgSW4gb3JkZXIgdG8KICAgYXZvaWQgcmVxdWVzdCBsb29wcywgYSBwcm94eSBN VVNUIGJlIGFibGUgdG8gcmVjb2duaXplIGFsbCBvZiBpdHMKICAgc2VydmVyIG5hbWVzLCBpbmNs dWRpbmcgYW55IGFsaWFzZXMsIGxvY2FsIHZhcmlhdGlvbnMsIGFuZCB0aGUKICAgbnVtZXJpYyBJ UCBhZGRyZXNzZXMuCgogICBBbiBlbmQtcG9pbnQgcmVjZWl2aW5nIGEgcmVxdWVzdCB3aXRoIGEg UHJveHktVXJpIE9wdGlvbiB0aGF0IGlzCiAgIHVuYWJsZSBvciB1bndpbGxpbmcgdG8gYWN0IGFz IGEgcHJveHkgZm9yIHRoZSByZXF1ZXN0IE1VU1QgY2F1c2UgdGhlCiAgIHJldHVybiBvZiBhIDUu MDUgKFByb3h5aW5nIE5vdCBTdXBwb3J0ZWQpIHJlc3BvbnNlLgoKICAgVGhpcyBvcHRpb24gaXMg ImNyaXRpY2FsIi4gIEl0IE1BWSBvY2N1ciBvbmUgb3IgbW9yZSB0aW1lcyBhbmQgTVVTVAogICB0 YWtlIHByZWNlZGVuY2Ugb3ZlciBhbnkgb2YgdGhlIFVyaS1Ib3N0LCBVcmktUG9ydCwgVXJpLVBh dGggb3IgVXJpLQogICBRdWVyeSBvcHRpb25zICh3aGljaCBNVVNUIE5PVCBiZSBpbmNsdWRlZCBh dCB0aGUgc2FtZSB0aW1lKS4KICAgCiAgIHtDYW4gSSByZXBlYXQgdGhlIG9ic2VydmF0aW9uIHRo YXQgdGhlIHVzZSBvZiBhIChzaW5nbGUpIFByb3h5LVVyaSAKICAgb3B0aW9uIGlzIGluY29uc2lz dGVudCB3aXRoIHRoZSB1c2Ugb2YgKG11bHRpcGxlKSBVcmktSG9zdCwgVXJpLVBvcnQsIAogICBV cmktUGF0aCBhbmQgVXJpLVF1ZXJ5IG9wdGlvbnMuIFNvIGluIENvQVAtQ29BUCBwcm94aWVzIAog ICB0aGlzIHJlcXVpcmVzIGNvZGUgdG8gcGFyc2UgUHJveHktVXJpIGludG8gVXJpLUhvc3QsIFVy aS1Qb3J0LCAKICAgVXJpLVBhdGggb3IgVXJpLVF1ZXJ5IG9wdGlvbnMuIEFuZCBlbmQtcG9pbnRz IHRoYXQgd2FudCB0byBhY2Nlc3MKICAgYSBwcm94eSBtdXN0IGFsc28gaGF2ZSBjb2RlIHRvIGNy ZWF0ZSB0aGUgUHJveHktVXJpIGZyb20gdGhlIGNvbnN0aXR1ZW50CiAgIFVyaS1Ib3N0LCBVcmkt UG9ydCwgVXJpLVBhdGggYW5kIFVyaS1RdWVyeSBvcHRpb25zLiBJcyB0aGF0IHJpZ2h0P30KCjUu MTAuNC4gIENvbnRlbnQtVHlwZQoKICAgVGhlIENvbnRlbnQtVHlwZSBPcHRpb24gaW5kaWNhdGVz IHRoZSByZXByZXNlbnRhdGlvbiBmb3JtYXQgb2YgdGhlCiAgIG1lc3NhZ2UgcGF5bG9hZC4gIFRo ZSByZXByZXNlbnRhdGlvbiBmb3JtYXQgaXMgZ2l2ZW4gYXMgYSBudW1lcmljCiAgIG1lZGlhIHR5 cGUgaWRlbnRpZmllciB0aGF0IGlzIGRlZmluZWQgaW4gdGhlIENvQVAgTWVkaWEgVHlwZSByZWdp c3RyeQogICAoU2VjdGlvbiAxMS4zKS4gIEEgZGVmYXVsdCB2YWx1ZSBvZiAwIChtZWFuaW5nICJ0 ZXh0L3BsYWluOwogICBjaGFyc2V0PXV0Zi04IikgaXMgYXNzdW1lZCBpbiB0aGUgYWJzZW5jZSBv ZiB0aGUgb3B0aW9uLgoKICAgVGhpcyBvcHRpb24gaXMgImNyaXRpY2FsIi4gIEl0IE1VU1QgTk9U IG9jY3VyIG1vcmUgdGhhbiBvbmNlLgoKNS4xMC41LiAgTWF4LUFnZQoKICAgVGhlIE1heC1BZ2Ug T3B0aW9uIGluZGljYXRlcyB0aGUgbWF4aW11bSB0aW1lIGEgcmVzcG9uc2UgbWF5IGJlCiAgIGNh Y2hlZCBiZWZvcmUgaXQgTVVTVCBiZSBjb25zaWRlcmVkIG5vdCBmcmVzaCAoc2VlIFNlY3Rpb24g NS42LjEpLgoKICAgVGhlIG9wdGlvbiB2YWx1ZSBpcyBhbiBpbnRlZ2VyIG51bWJlciBvZiBzZWNv bmRzIGJldHdlZW4gMCBhbmQgMl4zMi0xCiAgIGluY2x1c2l2ZSAoYWJvdXQgMTM2LjEgeWVhcnMp LiAgQSBkZWZhdWx0IHZhbHVlIG9mIDYwIHNlY29uZHMgaXMKICAgYXNzdW1lZCBpbiB0aGUgYWJz ZW5jZSBvZiB0aGUgb3B0aW9uIGluIGEgcmVzcG9uc2UuCgogICBUaGlzIG9wdGlvbiBpcyAiZWxl Y3RpdmUiLiAgSXQgTVVTVCBOT1Qgb2NjdXIgbW9yZSB0aGFuIG9uY2UuCgoKClNoZWxieSwgZXQg YWwuICAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMTUsIDIwMTEgICAgICAgICAgICAgIFtQYWdl IDM1XQoMCkludGVybmV0LURyYWZ0ICAgQ29uc3RyYWluZWQgQXBwbGljYXRpb24gUHJvdG9jb2wg KENvQVApICAgICAgTWFyY2ggMjAxMQoKCjUuMTAuNi4gIEVUYWcKCiAgIFRoZSBFVGFnIE9wdGlv biBpbiBhIHJlc3BvbnNlIHByb3ZpZGVzIHRoZSBjdXJyZW50IHZhbHVlIG9mIHRoZQogICBlbnRp dHktdGFnIGZvciB0aGUgZW5jbG9zZWQgcmVwcmVzZW50YXRpb24gb2YgdGhlIHRhcmdldCByZXNv dXJjZS4KCiAgIEFuIGVudGl0eS10YWcgaXMgaW50ZW5kZWQgZm9yIHVzZSBhcyBhIHJlc291cmNl LWxvY2FsIGlkZW50aWZpZXIgZm9yCiAgIGRpZmZlcmVudGlhdGluZyBiZXR3ZWVuIHJlcHJlc2Vu dGF0aW9ucyBvZiB0aGUgc2FtZSByZXNvdXJjZSB0aGF0CiAgIHZhcnkgb3ZlciB0aW1lLiAgSXQg bWF5IGJlIGdlbmVyYXRlZCBpbiBhbnkgbnVtYmVyIG9mIHdheXMgaW5jbHVkaW5nCiAgIGEgdmVy c2lvbiwgY2hlY2tzdW0sIGhhc2ggb3IgdGltZS4gIEFuIGVuZC1wb2ludCByZWNlaXZpbmcgYW4g ZW50aXR5LQogICB0YWcgTVVTVCB0cmVhdCBpdCBhcyBvcGFxdWUgYW5kIG1ha2Ugbm8gYXNzdW1w dGlvbnMgYWJvdXQgaXRzIGZvcm1hdC4KICAgKEVuZC1wb2ludHMgZ2VuZXJhdGluZyBhbiBlbnRp dHktdGFnIGFyZSBlbmNvdXJhZ2VkIHRvIHVzZSB0aGUgbW9zdAogICBjb21wYWN0IHJlcHJlc2Vu dGF0aW9uIHBvc3NpYmxlLCBpbiBwYXJ0aWN1bGFyIGluIHJlZ2FyZHMgdG8gY2xpZW50cwogICBh bmQgaW50ZXJtZWRpYXJpZXMgdGhhdCBtYXkgd2FudCB0byBzdG9yZSBtdWx0aXBsZSBFVGFnIHZh bHVlcy4pCgogICBBbiBlbmQtcG9pbnQgdGhhdCBoYXMgb25lIG9yIG1vcmUgcmVwcmVzZW50YXRp b25zIHByZXZpb3VzbHkgb2J0YWluZWQKICAgZnJvbSB0aGUgcmVzb3VyY2UgY2FuIHNwZWNpZnkg dGhlIEVUYWcgT3B0aW9uIGluIGEgcmVxdWVzdCBmb3IgZWFjaAogICBzdG9yZWQgcmVzcG9uc2Ug dG8gZGV0ZXJtaW5lIGlmIGFueSBvZiB0aG9zZSByZXByZXNlbnRhdGlvbnMgaXMKICAgY3VycmVu dCAoc2VlIFNlY3Rpb24gNS42LjIpLgoKICAgVGhpcyBvcHRpb24gaXMgImVsZWN0aXZlIi4gIEl0 IE1VU1QgTk9UIG9jY3VyIG1vcmUgdGhhbiBvbmNlIGluIGEKICAgcmVzcG9uc2UsIGFuZCBNQVkg b2NjdXIgb25lIG9yIG1vcmUgdGltZXMgaW4gYSByZXF1ZXN0LgoKNS4xMC43LiAgTG9jYXRpb24t UGF0aCBhbmQgTG9jYXRpb24tUXVlcnkKCiAgIFRoZSBMb2NhdGlvbi1QYXRoIGFuZCBMb2NhdGlv bi1RdWVyeSBPcHRpb25zIGluZGljYXRlcyB0aGUgbG9jYXRpb24KICAgb2YgYSByZXNvdXJjZSBh cyBhbiBhYnNvbHV0ZSBwYXRoIFVSSS4gIFRoZSBMb2NhdGlvbi1QYXRoIE9wdGlvbiBpcwogICBz aW1pbGFyIHRvIHRoZSBVcmktUGF0aCBPcHRpb24sIGFuZCB0aGUgTG9jYXRpb24tUXVlcnkgT3B0 aW9uIHNpbWlsYXIKICAgdG8gdGhlIFVyaS1RdWVyeSBPcHRpb24uCiAgIAogICB7UGVkYW50aWNh bGx5LCBwcmVzdW1hYmx5IHRoZSBMb2NhdGlvbi1RdWVyeSBkb2VzIG5vdCAic3BlY2lmeSB0aGUK ICAgbG9jYXRpb24gYXQgd2hpY2ggdGhlIHJlc291cmNlIHdhcyBjcmVhdGVkIi4gU2hvdWxkIGl0 IGJlIGdpdmVuIGEgCiAgIGRpZmZlcmVudCBkZXNjcmlwdGlvbj99CgogICBUaGUgdHdvIG9wdGlv bnMgTUFZIGJlIGluY2x1ZGVkIGluIGEgcmVzcG9uc2UgdG8gaW5kaWNhdGUgdGhlCiAgIGxvY2F0 aW9uIG9mIGEgbmV3IHJlc291cmNlIGNyZWF0ZWQgd2l0aCBQT1NULiB7d2hhdCBhYm91dCBQVVQ/ fQoKICAgSWYgYSByZXNwb25zZSB3aXRoIGEgTG9jYXRpb24tUGF0aCBhbmQvb3IgTG9jYXRpb24t UXVlcnkgT3B0aW9uCiAgIHBhc3NlcyB0aHJvdWdoIGEgY2FjaGUgYW5kIHRoZSBpbXBsaWVkIFVS SSBpZGVudGlmaWVzIG9uZSBvciBtb3JlCiAgIGN1cnJlbnRseSBzdG9yZWQgcmVzcG9uc2VzLCB0 aG9zZSBlbnRyaWVzIFNIT1VMRCBiZSB0cmVhdGVkIGFzIHN0YWxlLgoKICAgQm90aCBvcHRpb25z IGFyZSAiZWxlY3RpdmUiLiAgTG9jYXRpb24tUGF0aCBNQVkgb2NjdXIgb25lIG9yIG1vcmUKICAg dGltZXMuICBMb2NhdGlvbi1RdWVyeSBNVVNUIE5PVCBvY2N1ciBtb3JlIHRoYW4gb25jZS4KCgo2 LiAgQ29BUCBVUklzCgogICBDb0FQIHVzZXMgdGhlICJjb2FwIiBVUkkgc2NoZW1lIGZvciBpZGVu dGlmeWluZyBDb0FQIHJlc291cmNlcyBhbmQKICAgcHJvdmlkaW5nIGEgbWVhbnMgb2YgbG9jYXRp bmcgdGhlIHJlc291cmNlLiAgUmVzb3VyY2VzIGFyZSBvcmdhbml6ZWQKICAgaGllcmFyY2hpY2Fs bHkgYW5kIGdvdmVybmVkIGJ5IGEgcG90ZW50aWFsIENvQVAgb3JpZ2luIHNlcnZlcgogICBsaXN0 ZW5pbmcgZm9yIENvQVAgcmVxdWVzdHMgb24gYSBnaXZlbiBVRFAgcG9ydC4gIFRoZSBDb0FQIHNl cnZlciBpcwogICBpZGVudGlmaWVkIHZpYSB0aGUgZ2VuZXJpYyBzeW50YXgncyBhdXRob3JpdHkg Y29tcG9uZW50LCB3aGljaAogICBpbmNsdWRlcyBhIGhvc3QgaWRlbnRpZmllciBhbmQgb3B0aW9u YWwgVURQIHBvcnQgbnVtYmVyLiAgVGhlCgoKClNoZWxieSwgZXQgYWwuICAgICAgICAgRXhwaXJl cyBTZXB0ZW1iZXIgMTUsIDIwMTEgICAgICAgICAgICAgIFtQYWdlIDM2XQoMCkludGVybmV0LURy YWZ0ICAgQ29uc3RyYWluZWQgQXBwbGljYXRpb24gUHJvdG9jb2wgKENvQVApICAgICAgTWFyY2gg MjAxMQoKCiAgIHJlbWFpbmRlciBvZiB0aGUgVVJJIGlzIGNvbnNpZGVyZWQgdG8gYmUgaWRlbnRp ZnlpbmcgYSByZXNvdXJjZSB3aGljaAogICBjYW4gYmUgb3BlcmF0ZWQgb24gYnkgdGhlIG1ldGhv ZHMgZGVmaW5lZCBieSB0aGUgQ29BUCBwcm90b2NvbC4gIENvQVAKICAgVVJJcyBjYW4gdGh1cyBi ZSBjb21wYXJlZCB0byB0aGUgImh0dHAiIFVSSSBzY2hlbWUuCgo2LjEuICBVUkkgU2NoZW1lIFN5 bnRheAoKICAgVGhlIHN5bnRheCBvZiB0aGUgImNvYXAiIFVSSSBzY2hlbWUgaXMgc3BlY2lmaWVk IGJlbG93IGluIEF1Z21lbnRlZAogICBCYWNrdXMtTmF1ciBGb3JtIChBQk5GKSBbUkZDNTIzNF0u ICBUaGUgZGVmaW5pdGlvbnMgb2YgImhvc3QiLAogICAicG9ydCIsICJwYXRoLWFiZW1wdHkiLCBh bmQgInF1ZXJ5IiwgInNlZ21lbnQiLCAiSVAtbGl0ZXJhbCIsCiAgICJJUHY0YWRkcmVzcyIgYW5k ICJyZWctbmFtZSIgYXJlIGFkb3B0ZWQgZnJvbSBbUkZDMzk4Nl0uCgogICBjb2FwLVVSSSA9ICJj b2FwOiIgIi8vIiBob3N0IFsgIjoiIHBvcnQgXSBwYXRoLWFiZW1wdHkgWyAiPyIgcXVlcnkgXQoK ICAgSWYgaG9zdCBpcyBwcm92aWRlZCBhcyBhbiBJUC1saXRlcmFsIG9yIElQdjRhZGRyZXNzLCB0 aGVuIHRoZSBDb0FQCiAgIHNlcnZlciBpcyBsb2NhdGVkIGF0IHRoYXQgSVAgYWRkcmVzcy4gIElm IGhvc3QgaXMgYSByZWdpc3RlcmVkIG5hbWUsCiAgIHRoZW4gdGhhdCBuYW1lIGlzIGNvbnNpZGVy ZWQgYW4gaW5kaXJlY3QgaWRlbnRpZmllciBhbmQgdGhlIGVuZC1wb2ludAogICBtaWdodCB1c2Ug YSBuYW1lIHJlc29sdXRpb24gc2VydmljZSwgc3VjaCBhcyBETlMsIHRvIGZpbmQgdGhlIGFkZHJl c3MKICAgb2YgdGhhdCBob3N0LiAgVGhlIGhvc3QgTVVTVCBOT1QgYmUgZW1wdHkuICBUaGUgcG9y dCBzdWJjb21wb25lbnQKICAgaW5kaWNhdGVzIHRoZSBVRFAgcG9ydCBhdCB3aGljaCB0aGUgQ29B UCBzZXJ2ZXIgaXMgbG9jYXRlZC4gIElmIGl0IGlzCiAgIGVtcHR5IG9yIG5vdCBnaXZlbiwgdGhl biB0aGUgZGVmYXVsdCBwb3J0IFtJQU5BX1RCRF9QT1JUXSBpcyBhc3N1bWVkLgoKICAgVGhlIHBh dGggaWRlbnRpZmllcyBhIHJlc291cmNlIHdpdGhpbiB0aGUgc2NvcGUgb2YgdGhlIGhvc3QgYW5k IHBvcnQuCiAgIEl0IGNvbnNpc3RzIG9mIGEgc2VxdWVuY2Ugb2YgcGF0aCBzZWdtZW50cyBzZXBh cmF0ZWQgYnkgYSBzbGFzaCAoIi8iKQogICBjaGFyYWN0ZXIuICBUaGUgcXVlcnkgc2VydmVzIHRv IGZ1cnRoZXIgcGFyYW1ldHJpemUgdGhlIHJlc291cmNlLAogICBvZnRlbiBpbiB0aGUgZm9ybSBv ZiAia2V5PXZhbHVlIiBwYWlycy4KCiAgIFRoZSAiY29hcCIgVVJJIHNjaGVtZSBzdXBwb3J0cyB0 aGUgcGF0aCBwcmVmaXggIi8ud2VsbC1rbm93bi8iCiAgIGRlZmluZWQgYnkgW1JGQzU3ODVdIGZv ciAid2VsbC1rbm93biBsb2NhdGlvbnMiIGluIHRoZSBuYW1lLXNwYWNlIG9mCiAgIGEgaG9zdC4g IFRoaXMgZW5hYmxlcyBkaXNjb3Zlcnkgb2YgcG9saWN5IG9yIG90aGVyIGluZm9ybWF0aW9uIGFi b3V0CiAgIGEgaG9zdCAoInNpdGUtd2lkZSBtZXRhZGF0YSIpLCBzdWNoIGFzIGhvc3RlZCByZXNv dXJjZXMgKHNlZQogICBTZWN0aW9uIDcuMSkuCgogICBBcHBsaWNhdGlvbiBkZXNpZ25lcnMgYXJl IGVuY291cmFnZWQgdG8gbWFrZSB1c2Ugb2Ygc2hvcnQsIGJ1dAogICBkZXNjcmlwdGl2ZSBVUklz LiAgQXMgdGhlIGVudmlyb25tZW50cyB0aGF0IENvQVAgaXMgdXNlZCBpbiBhcmUKICAgdXN1YWxs eSBjb25zdHJhaW5lZCBmb3IgYmFuZHdpZHRoIGFuZCBlbmVyZ3ksIHRoZSB0cmFkZS1vZmYgYmV0 d2VlbgogICB0aGVzZSB0d28gcXVhbGl0aWVzIHNob3VsZCBsZWFuIHRvd2FyZHMgdGhlIHNob3J0 bmVzcywgd2l0aG91dAogICBpZ25vcmluZyBkZXNjcmlwdGl2ZW5lc3MuCgo2LjIuICBOb3JtYWxp emF0aW9uIGFuZCBDb21wYXJpc29uIFJ1bGVzCgogICBTaW5jZSB0aGUgImNvYXAiIHNjaGVtZSBj b25mb3JtcyB0byB0aGUgVVJJIGdlbmVyaWMgc3ludGF4LCBVUklzIG9mCiAgIHRoaXMgc2NoZW1l IGFyZSBub3JtYWxpemVkIGFuZCBjb21wYXJlZCBhY2NvcmRpbmcgdG8gdGhlIGFsZ29yaXRobQog ICBkZWZpbmVkIGluIFtSRkMzOTg2XSwgU2VjdGlvbiA2LgoKICAgSWYgdGhlIHBvcnQgaXMgZXF1 YWwgdG8gdGhlIGRlZmF1bHQgcG9ydCBbSUFOQV9UQkRfUE9SVF0sIHRoZSBub3JtYWwKICAgZm9y bSBpcyB0byBlbGlkZSB0aGUgcG9ydCBjb21wb25lbnQuICBMaWtld2lzZSwgYW4gZW1wdHkgcGF0 aAogICBjb21wb25lbnQgaXMgZXF1aXZhbGVudCB0byBhbiBhYnNvbHV0ZSBwYXRoIG9mICIvIiwg c28gdGhlIG5vcm1hbAogICBmb3JtIGlzIHRvIHByb3ZpZGUgYSBwYXRoIG9mICIvIiBpbnN0ZWFk LiAgVGhlIHNjaGVtZSBhbmQgaG9zdCBhcmUKCgoKU2hlbGJ5LCBldCBhbC4gICAgICAgICBFeHBp cmVzIFNlcHRlbWJlciAxNSwgMjAxMSAgICAgICAgICAgICAgW1BhZ2UgMzddCgwKSW50ZXJuZXQt RHJhZnQgICBDb25zdHJhaW5lZCBBcHBsaWNhdGlvbiBQcm90b2NvbCAoQ29BUCkgICAgICBNYXJj aCAyMDExCgoKICAgY2FzZS1pbnNlbnNpdGl2ZSBhbmQgbm9ybWFsbHkgcHJvdmlkZWQgaW4gbG93 ZXJjYXNlOyBJUC1saXRlcmFscyBhcmUKICAgaW4gcmVjb21tZW5kZWQgZm9ybSBbUkZDNTk1Ml07 IGFsbCBvdGhlciBjb21wb25lbnRzIGFyZSBjb21wYXJlZCBpbiBhCiAgIGNhc2Utc2Vuc2l0aXZl IG1hbm5lci4gIENoYXJhY3RlcnMgb3RoZXIgdGhhbiB0aG9zZSBpbiB0aGUgInJlc2VydmVkIgog ICBzZXQgYXJlIGVxdWl2YWxlbnQgdG8gdGhlaXIgcGVyY2VudC1lbmNvZGVkIG9jdGV0cyAoc2Vl IFtSRkMzOTg2XSwKICAgU2VjdGlvbiAyLjEpOiB0aGUgbm9ybWFsIGZvcm0gaXMgdG8gbm90IGVu Y29kZSB0aGVtLgoKICAgRm9yIGV4YW1wbGUsIHRoZSBmb2xsb3dpbmcgdGhyZWUgVVJJcyBhcmUg ZXF1aXZhbGVudCwgYW5kIGNhdXNlIHRoZQogICBzYW1lIG9wdGlvbnMgYW5kIG9wdGlvbiB2YWx1 ZXMgdG8gYXBwZWFyIGluIHRoZSBDb0FQIG1lc3NhZ2VzOgoKICAgICAgY29hcDovL2V4YW1wbGUu Y29tOltJQU5BX1RCRF9QT1JUXS9+c2Vuc29ycy90ZW1wLnhtbAoKICAgICAgY29hcDovL0VYQU1Q TEUuY29tLyU3RXNlbnNvcnMvdGVtcC54bWwKCiAgICAgIGNvYXA6Ly9FWEFNUExFLmNvbTovJTdl c2Vuc29ycy90ZW1wLnhtbAoKNi4zLiAgUGFyc2luZyBVUklzCgogICBUaGUgc3RlcHMgdG8gcGFy c2UgYSByZXF1ZXN0J3Mgb3B0aW9ucyBmcm9tIGEgc3RyaW5nIC91cmwvIGFyZSBhcwogICBmb2xs b3dzLiAgVGhlc2Ugc3RlcHMgZWl0aGVyIHJlc3VsdCBpbiB6ZXJvIG9yIG1vcmUgb2YgdGhlIFVy aS1Ib3N0LAogICBVcmktUG9ydCwgVXJpLVBhdGggYW5kIFVyaS1RdWVyeSBPcHRpb25zIGJlaW5n IGluY2x1ZGVkIGluIHRoZQogICByZXF1ZXN0LCBvciB0aGV5IGZhaWwuCgogICAxLiAgSWYgdGhl IC91cmwvIHN0cmluZyBpcyBub3QgYW4gYWJzb2x1dGUgVVJJIChbUkZDMzk4Nl0pLCB0aGVuIGZh aWwKICAgICAgIHRoaXMgYWxnb3JpdGhtLgoKICAgMi4gIFJlc29sdmUgdGhlIC91cmwvIHN0cmlu ZyB1c2luZyB0aGUgcHJvY2VzcyBvZiByZWZlcmVuY2UKICAgICAgIHJlc29sdXRpb24gZGVmaW5l ZCBieSBbUkZDMzk4Nl0sIHdpdGggdGhlIFVSTCBjaGFyYWN0ZXIgZW5jb2RpbmcKICAgICAgIHNl dCB0byBVVEYtOCBbUkZDMzYyOV0uCgogICAgICAgTk9URTogSXQgZG9lc24ndCBtYXR0ZXIgd2hh dCBpdCBpcyByZXNvbHZlZCByZWxhdGl2ZSB0bywgc2luY2Ugd2UKICAgICAgIGFscmVhZHkga25v dyBpdCBpcyBhbiBhYnNvbHV0ZSBVUkwgYXQgdGhpcyBwb2ludC4KCiAgIDMuICBJZiAvdXJsLyBk b2VzIG5vdCBoYXZlIGEgPHNjaGVtZT4gY29tcG9uZW50IHdob3NlIHZhbHVlLCB3aGVuCiAgICAg ICBjb252ZXJ0ZWQgdG8gQVNDSUkgbG93ZXJjYXNlLCBpcyAiY29hcCIsIHRoZW4gZmFpbCB0aGlz CiAgICAgICBhbGdvcml0aG0uCgogICA0LiAgSWYgL3VybC8gaGFzIGEgPGZyYWdtZW50PiBjb21w b25lbnQsIHRoZW4gZmFpbCB0aGlzIGFsZ29yaXRobS4KCiAgIDUuICBJZiB0aGUgPGhvc3Q+IGNv bXBvbmVudCBvZiAvdXJsLyBkb2VzIG5vdCByZXByZXNlbnQgdGhlIHJlcXVlc3QncwogICAgICAg ZGVzdGluYXRpb24gSVAgYWRkcmVzcyBhcyBhbiBJUC1saXRlcmFsIG9yIElQdjRhZGRyZXNzLCBp bmNsdWRlIGEKICAgICAgIFVyaS1Ib3N0IE9wdGlvbiBhbmQgbGV0IHRoYXQgb3B0aW9uJ3MgdmFs dWUgYmUgdGhlIHZhbHVlIG9mIHRoZQogICAgICAgPGhvc3Q+IGNvbXBvbmVudCBvZiAvdXJsLywg Y29udmVydGVkIHRvIEFTQ0lJIGxvd2VyY2FzZSwgYW5kIHRoZW4KICAgICAgIGNvbnZlcnRpbmcg ZWFjaCBwZXJjZW50LWVuY29kaW5nICgiJSIgZm9sbG93ZWQgYnkgdHdvIGhleGFkZWNpbWFsCiAg ICAgICBkaWdpdHMpIHRvIHRoZSBjb3JyZXNwb25kaW5nIGJ5dGUuCgogICAgICAgTk9URTogSW4g dGhlIHVzdWFsIGNhc2Ugd2hlcmUgdGhlIHJlcXVlc3QncyBkZXN0aW5hdGlvbiBJUAogICAgICAg YWRkcmVzcyBpcyBkZXJpdmVkIGZyb20gdGhlIGhvc3QgcGFydCwgdGhpcyBlbnN1cmVzIHRoYXQg VXJpLUhvc3QKICAgICAgIE9wdGlvbnMgYXJlIG9ubHkgdXNlZCBmb3IgaG9zdCBwYXJ0cyBvZiB0 aGUgZm9ybSByZWctbmFtZS4KCgoKU2hlbGJ5LCBldCBhbC4gICAgICAgICBFeHBpcmVzIFNlcHRl bWJlciAxNSwgMjAxMSAgICAgICAgICAgICAgW1BhZ2UgMzhdCgwKSW50ZXJuZXQtRHJhZnQgICBD b25zdHJhaW5lZCBBcHBsaWNhdGlvbiBQcm90b2NvbCAoQ29BUCkgICAgICBNYXJjaCAyMDExCgoK ICAgNi4gIElmIC91cmwvIGhhcyBhIDxwb3J0PiBjb21wb25lbnQsIHRoZW4gbGV0IC9wb3J0LyBi ZSB0aGF0CiAgICAgICBjb21wb25lbnQncyB2YWx1ZSBpbnRlcnByZXRlZCBhcyBhIGRlY2ltYWwg aW50ZWdlcjsgb3RoZXJ3aXNlLAogICAgICAgbGV0IC9wb3J0LyBiZSB0aGUgZGVmYXVsdCBwb3J0 IFtJQU5BX1RCRF9QT1JUXS4KCiAgIDcuICBJZiAvcG9ydC8gZG9lcyBub3QgZXF1YWwgdGhlIHJl cXVlc3QncyBkZXN0aW5hdGlvbiBVRFAgcG9ydCwKICAgICAgIGluY2x1ZGUgYSBVcmktUG9ydCBP cHRpb24gYW5kIGxldCB0aGF0IG9wdGlvbidzIHZhbHVlIGJlIC9wb3J0Ly4KCiAgIDguICBJZiB0 aGUgdmFsdWUgb2YgdGhlIDxwYXRoPiBjb21wb25lbnQgb2YgL3VybC8gaXMgZW1wdHkgb3IKICAg ICAgIGNvbnNpc3RzIG9mIGEgc2luZ2xlIHNsYXNoIGNoYXJhY3RlciAoVSswMDJGIFNPTElEVVMg Ii8iKSwgdGhlbgogICAgICAgbW92ZSB0byB0aGUgbmV4dCBzdGVwLgoKICAgICAgIE90aGVyd2lz ZSwgZm9yIGVhY2ggc2VnbWVudCBpbiB0aGUgPHBhdGg+IGNvbXBvbmVudCwgaW5jbHVkZSBhCiAg ICAgICBVcmktUGF0aCBPcHRpb24gYW5kIGxldCB0aGF0IG9wdGlvbidzIHZhbHVlIGJlIHRoZSBz ZWdtZW50IChub3QKICAgICAgIGluY2x1ZGluZyB0aGUgZGVsaW1pdGluZyBzbGFzaCBjaGFyYWN0 ZXJzKSBhZnRlciBjb252ZXJ0aW5nIGVhY2gKICAgICAgIHBlcmNlbnQtZW5jb2RpbmcgKCIlIiBm b2xsb3dlZCBieSB0d28gaGV4YWRlY2ltYWwgZGlnaXRzKSB0byB0aGUKICAgICAgIGNvcnJlc3Bv bmRpbmcgYnl0ZS4KCiAgIDkuICBJZiAvdXJsLyBoYXMgYSA8cXVlcnk+IGNvbXBvbmVudCwgdGhl biBpbmNsdWRlIGEgVXJpLVF1ZXJ5IE9wdGlvbgogICAgICAgYW5kIGxldCB0aGF0IG9wdGlvbidz IHZhbHVlIGJlIHRoZSB2YWx1ZSBvZiB0aGUgPHF1ZXJ5PiBjb21wb25lbnQKICAgICAgIChub3Qg aW5jbHVkaW5nIHRoZSBkZWxpbWl0aW5nIHF1ZXN0aW9uIG1hcmspLiAgKE5vdGUgdGhhdCwgaW4K ICAgICAgIGNvbnRyYXN0IHRvIHRoZSBvdGhlciBjb21wb25lbnRzLCBwZXJjZW50LWVuY29kaW5n cyBzdGF5IGludGFjdAogICAgICAgaW4gdGhlIFVyaS1RdWVyeSBPcHRpb24uKQoKICAgTm90ZSB0 aGF0IHRoZXNlIHJ1bGVzIGNvbXBsZXRlbHkgcmVzb2x2ZSBhbnkgcGVyY2VudC1lbmNvZGluZyBl eGNlcHQKICAgaW4gYSByZWctbmFtZSBhbmQgaW4gYSBxdWVyeS4KCjYuNC4gIENvbnN0cnVjdGlu ZyBVUklzCgogICBUaGUgc3RlcHMgdG8gY29uc3RydWN0IGEgVVJJIGZyb20gYSByZXF1ZXN0J3Mg b3B0aW9ucyBhcmUgYXMgZm9sbG93cy4KICAgVGhlc2Ugc3RlcHMgZWl0aGVyIHJlc3VsdCBpbiBh IFVSSSwgb3IgdGhleSBmYWlsLiAgSW4gdGhlc2Ugc3RlcHMsCiAgIHBlcmNlbnQtZW5jb2Rpbmcg YSBjaGFyYWN0ZXIgbWVhbnMgcmVwbGFjaW5nIGVhY2ggb2YgaXRzIChVVEYtOAogICBlbmNvZGVk KSBieXRlcyBieSBhICIlIiBjaGFyYWN0ZXIgZm9sbG93ZWQgYnkgdHdvIGhleGFkZWNpbWFsIGRp Z2l0cwogICByZXByZXNlbnRpbmcgdGhlIGJ5dGUsIHdoZXJlIHRoZSBkaWdpdHMgQS1GIGFyZSBp biB1cHBlciBjYXNlIChhcwogICBkZWZpbmVkIGluIFtSRkMzOTg2XSBTZWN0aW9uIDIuMTsgdG8g cmVkdWNlIHZhcmlhYmlsaXR5LCB0aGUKICAgaGV4YWRlY2ltYWwgbm90YXRpb24gaW4gQ29BUCBV UklzIE1VU1QgdXNlIHVwcGVyY2FzZSBsZXR0ZXJzKS4KCiAgIDEuICAgTGV0IC91cmwvIGJlIHRo ZSBzdHJpbmcgImNvYXA6Ly8iLgoKICAgMi4gICBJZiB0aGUgcmVxdWVzdCBpbmNsdWRlcyBhIFVy aS1Ib3N0IE9wdGlvbiwgbGV0IC9ob3N0LyBiZSB0aGF0CiAgICAgICAgb3B0aW9uJ3MgdmFsdWUs IHdoZXJlIGFueSBub24tQVNDSUkgY2hhcmFjdGVycyBhcmUgcmVwbGFjZWQgYnkKICAgICAgICB0 aGVpciBjb3JyZXNwb25kaW5nIHBlcmNlbnQtZW5jb2RpbmcuICBJZiAvaG9zdC8gaXMgbm90IGEg dmFsaWQKICAgICAgICByZWctbmFtZSBvciBJUC1saXRlcmFsIG9yIElQdjRhZGRyZXNzLCBmYWls IHRoZSBhbGdvcml0aG0uCiAgICAgICAgT3RoZXJ3aXNlLCBsZXQgL2hvc3QvIGJlIHRoZSBJUC1s aXRlcmFsIChtYWtpbmcgdXNlIG9mIHRoZQogICAgICAgIGNvbnZlbnRpb25zIG9mIFtSRkM1OTUy XSkgb3IgSVB2NGFkZHJlc3MgcmVwcmVzZW50aW5nIHRoZQogICAgICAgIHJlcXVlc3QncyBkZXN0 aW5hdGlvbiBJUCBhZGRyZXNzLgoKICAgMy4gICBBcHBlbmQgL2hvc3QvIHRvIC91cmwvLgoKCgoK U2hlbGJ5LCBldCBhbC4gICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAxNSwgMjAxMSAgICAgICAg ICAgICAgW1BhZ2UgMzldCgwKSW50ZXJuZXQtRHJhZnQgICBDb25zdHJhaW5lZCBBcHBsaWNhdGlv biBQcm90b2NvbCAoQ29BUCkgICAgICBNYXJjaCAyMDExCgoKICAgNC4gICBJZiB0aGUgcmVxdWVz dCBpbmNsdWRlcyBhIFVyaS1Qb3J0IE9wdGlvbiwgbGV0IC9wb3J0LyBiZSB0aGF0CiAgICAgICAg b3B0aW9uJ3MgdmFsdWUuICBPdGhlcndpc2UsIGxldCAvcG9ydC8gYmUgdGhlIHJlcXVlc3Qncwog ICAgICAgIGRlc3RpbmF0aW9uIFVEUCBwb3J0LgoKICAgNS4gICBJZiAvcG9ydC8gaXMgbm90IHRo ZSBkZWZhdWx0IHBvcnQgW0lBTkFfVEJEX1BPUlRdLCB0aGVuIGFwcGVuZCBhCiAgICAgICAgc2lu Z2xlIFUrMDAzQSBDT0xPTiBjaGFyYWN0ZXIgKDopIGZvbGxvd2VkIGJ5IHRoZSBkZWNpbWFsCiAg ICAgICAgcmVwcmVzZW50YXRpb24gb2YgL3BvcnQvIHRvIC91cmwvLgoKICAgNi4gICBMZXQgL3Jl c291cmNlIG5hbWUvIGJlIHRoZSBlbXB0eSBzdHJpbmcuICBGb3IgZWFjaCBVcmktUGF0aAogICAg ICAgIE9wdGlvbiBpbiB0aGUgcmVxdWVzdCwgYXBwZW5kIGEgc2luZ2xlIGNoYXJhY3RlciBVKzAw MkYgU09MSURVUwogICAgICAgICgvKSBmb2xsb3dlZCBieSB0aGUgb3B0aW9uJ3MgdmFsdWUgdG8g L3Jlc291cmNlIG5hbWUvLCBhZnRlcgogICAgICAgIGNvbnZlcnRpbmcgYW55IGNoYXJhY3RlciB0 aGF0IGlzIG5vdCBlaXRoZXIgaW4gdGhlICJ1bnJlc2VydmVkIgogICAgICAgIHNldCwgInN1Yi1k ZWxpbXMiIHNldCwgYSBVKzAwM0EgQ09MT04gY2hhcmFjdGVyICg6KSBvciBVKzAwNDAKICAgICAg ICBDT01NRVJDSUFMIEFUIChAKSwgdG8gaXRzIHBlcmNlbnQtZW5jb2RlZCBmb3JtLgoKICAgNy4g ICBJZiAvcmVzb3VyY2UgbmFtZS8gaXMgdGhlIGVtcHR5IHN0cmluZywgc2V0IGl0IHRvIGEgc2lu Z2xlCiAgICAgICAgY2hhcmFjdGVyIFUrMDAyRiBTT0xJRFVTICgvKS4KCiAgIDguICAgQXBwZW5k IC9yZXNvdXJjZSBuYW1lLyB0byAvdXJsLy4KCiAgIDkuICAgSWYgdGhlIHJlcXVlc3QgaW5jbHVk ZXMgYSBVcmktUXVlcnkgT3B0aW9uLCBhcHBlbmQgYSBzaW5nbGUKICAgICAgICBVKzAwM0YgUVVF U1RJT04gTUFSSyBjaGFyYWN0ZXIgKD8pIHRvIC91cmwvLCBmb2xsb3dlZCBieSB0aGUKICAgICAg ICBvcHRpb24ncyB2YWx1ZS4KCiAgIDEwLiAgUmV0dXJuIC91cmwvLgoKICAgTm90ZSB0aGF0IHRo ZXNlIHN0ZXBzIGhhdmUgYmVlbiBkZXNpZ25lZCB0byBsZWFkIHRvIGEgVVJJIGluIG5vcm1hbAog ICBmb3JtIChzZWUgU2VjdGlvbiA2LjIpLgoKCjcuICBGaW5kaW5nIGFuZCBBZGRyZXNzaW5nIENv QVAgRW5kLVBvaW50cwoKNy4xLiAgUmVzb3VyY2UgRGlzY292ZXJ5CgogICBUaGUgZGlzY292ZXJ5 IG9mIHJlc291cmNlcyBvZmZlcmVkIGJ5IGEgQ29BUCBlbmQtcG9pbnQgaXMgZXh0cmVtZWx5CiAg IGltcG9ydGFudCBpbiBtYWNoaW5lLXRvLW1hY2hpbmUgYXBwbGljYXRpb25zIHdoZXJlIHRoZXJl IGFyZSBubwogICBodW1hbnMgaW4gdGhlIGxvb3AgYW5kIHN0YXRpYyBpbnRlcmZhY2VzIHJlc3Vs dCBpbiBmcmFnaWxpdHkuICBBIENvQVAKICAgZW5kLXBvaW50IFNIT1VMRCBzdXBwb3J0IHRoZSBD b1JFIExpbmsgRm9ybWF0IG9mIGRpc2NvdmVyYWJsZQogICByZXNvdXJjZXMgYXMgZGVzY3JpYmVk IGluIFtJLUQuaWV0Zi1jb3JlLWxpbmstZm9ybWF0XS4KCjcuMi4gIERlZmF1bHQgUG9ydAoKICAg VGhlIENvQVAgZGVmYXVsdCBwb3J0IG51bWJlciBbSUFOQV9UQkRfUE9SVF0gTVVTVCBiZSBzdXBw b3J0ZWQgYnkgYQogICBzZXJ2ZXIgZm9yIHJlc291cmNlIGRpc2NvdmVyeSBhbmQgU0hPVUxEIGJl IHN1cHBvcnRlZCBmb3IgcHJvdmlkaW5nCiAgIGFjY2VzcyB0byBvdGhlciByZXNvdXJjZXMuICBJ biBhZGRpdGlvbiBvdGhlciBlbmQtcG9pbnRzIG1heSBiZQogICBob3N0ZWQgaW4gdGhlIGR5bmFt aWMgcG9ydCBzcGFjZS4KCiAgIFdoZW4gYSBDb0FQIHNlcnZlciBpcyBob3N0ZWQgYnkgYSA2TG9X UEFOIG5vZGUsIGl0IFNIT1VMRCBhbHNvCgoKClNoZWxieSwgZXQgYWwuICAgICAgICAgRXhwaXJl cyBTZXB0ZW1iZXIgMTUsIDIwMTEgICAgICAgICAgICAgIFtQYWdlIDQwXQoMCkludGVybmV0LURy YWZ0ICAgQ29uc3RyYWluZWQgQXBwbGljYXRpb24gUHJvdG9jb2wgKENvQVApICAgICAgTWFyY2gg MjAxMQoKCiAgIHN1cHBvcnQgYSBwb3J0IGluIHRoZSA2MTYxNi02MTYzMSBjb21wcmVzc2VkIFVE UCBwb3J0IHNwYWNlIGRlZmluZWQKICAgaW4gW1JGQzQ5NDRdLgoKNy4zLiAgTXVsdGlwbGV4aW5n IERUTFMgYW5kIENvQVAKCiAgIFRoZSBDb0FQIGVuY29kaW5nIGhhcyBiZWVuIGNob3NlbiB0byBl bmFibGUgZGVtdWx0aXBsZXhpbmcgb2YgdHdvCiAgIGtpbmRzIG9mIHBhY2tldHMgdGhhdCBhcnJp dmUgb24gYSBzaW5nbGUgVURQIHBvcnQ6CgogICBvICBDb0FQIG1lc3NhZ2VzIGRpcmVjdGx5IHNl bnQgd2l0aGluIFVEUAoKICAgbyAgRFRMUyAxLjEgb3IgMS4yIG1lc3NhZ2VzICh3aGljaCBtaWdo dCBjb250YWluIENvQVAgbWVzc2FnZXMpIG9uCiAgICAgIFVEUAoKICAgUG9zc2libHkgbGVzcyBp bXBvcnRhbnRseSwgYSBkaXN0aW5jdGlvbiBjYW4gYWxzbyBiZSBtYWRlIGJldHdlZW4KICAgdGhl c2UgdHdvIGFuZDoKCiAgIG8gIFNUVU4gbWVzc2FnZXMgb24gVURQCgogICBUaGlzIGRlbXVsdGlw bGV4aW5nIGlzIHBvc3NpYmxlIGJlY2F1c2UgRFRMUyAxLjEgb3IgMS4yIFVEUCBwYXlsb2Fkcwog ICBiZWdpbiB3aXRoIGEgYnl0ZSBvdXQgb2Y6CgogICBlbnVtIHsKICAgICBjaGFuZ2VfY2lwaGVy X3NwZWMoMjApLCBhbGVydCgyMSksIGhhbmRzaGFrZSgyMiksCiAgICAgYXBwbGljYXRpb25fZGF0 YSgyMyksICgyNTUpCiAgIH0gQ29udGVudFR5cGU7CgogICAgICAgICAgICAgICAgICAgICAgICAg RmlndXJlIDk6IFRMUyBDb250ZW50VHlwZQoKICAgaS5lLiAweDE0IHRvIDB4MTcgaGV4IFtSRkM0 MzQ3XS4gIEluIGEgQ29BUCBtZXNzYWdlLCBzdWNoIGFuIGluaXRpYWwKICAgYnl0ZSB3b3VsZCBi ZSBkZWNvZGVkIGFzIGEgQ29BUCB2ZXJzaW9uIDAsIHdoaWNoIGlzIG5vdCBpbiB1c2UuCgo3LjMu MS4gIEZ1dHVyZS1Qcm9vZmluZyB0aGUgTXVsdGlwbGV4aW5nCgogICBUbyBtYWludGFpbiB0aGlz IHByb3BlcnR5LCBmdXR1cmUgdmVyc2lvbnMgb2YgQ29BUCB3aWxsIG5vdCB1c2UKICAgdmVyc2lv biBudW1iZXIgMC4gIE5vdGUgdGhhdCBmdXR1cmUgdmVyc2lvbnMgb2YgRFRMUyBtaWdodAogICB0 aGVvcmV0aWNhbGx5IHN0YXJ0IHRvIHVzZSAiQ29udGVudFR5cGUiIHZhbHVlcyB0aGF0IGZhbGwg aW50byB0aGUKICAgcmFuZ2Ugb2YgNjQgdG8gMTI3OyBDb0FQIGltcGxlbWVudGF0aW9ucyB3b3Vs ZCB0aGVuIG5vdCBiZSBhYmxlIHRvCiAgIHJlbGlhYmx5IG11bHRpcGxleCB0aGVzZSBuZXcga2lu ZHMgb2YgRFRMUyBkYXRhZ3JhbXMgd2l0aCBDb0FQCiAgIGRhdGFncmFtcyBvbiB0aGUgc2FtZSBV RFAgcG9ydC4gIFRvIG1haW50YWluIHRyYW5zcGFyZW5jeSBmb3IgdGhpcwogICBjYXNlLCBhbiBp bml0aWFsIGJ5dGUgb2YgMHgxMSAoMTcgZGVjaW1hbCkgaXMgaW5zZXJ0ZWQgb24KICAgdHJhbnNt aXNzaW9uIGFuZCBkaXNjYXJkZWQgdXBvbiByZWNlcHRpb247IHRoZSByZXN0IG9mIHRoZSBkYXRh Z3JhbQogICBpcyBpbnRlcnByZXRlZCBhcyB0aGUgRFRMUyBtZXNzYWdlLiAweDExIE1VU1QgTk9U IGJlIGZvbGxvd2VkIGJ5IDB4MTQKICAgdG8gMHgxNyBoZXgsIGkuZS4gdGhlIERUTFMgbWVzc2Fn ZXMgZGVmaW5lZCBieSBEVExTIDEuMSBhbmQgMS4yIGFyZQogICBhbHdheXMgc2VudCB1bmVzY2Fw ZWQuICBEYXRhZ3JhbXMgc3RhcnRpbmcgd2l0aCAweDExIGFuZCB0aGVuIDB4MTQgdG8KICAgMHgx NyBNVVNUIGJlIGRpc2NhcmRlZC4KCiAgIFNpbWlsYXJseSwgU1RVTiBtZXNzYWdlcyBiZWdpbiB3 aXRoIDAwbW1tbW1jIGJpbmFyeSAoTVNCcykgW1JGQzUzODldCiAgIGFuZCBzbyBmYXIgaGFwcGVu IHRvIHVzZSBhbiBlbmNvZGluZyBmb3IgbW1tbW1jIHRoYXQgYWxzbyBlbmFibGVzCgoKClNoZWxi eSwgZXQgYWwuICAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMTUsIDIwMTEgICAgICAgICAgICAg IFtQYWdlIDQxXQoMCkludGVybmV0LURyYWZ0ICAgQ29uc3RyYWluZWQgQXBwbGljYXRpb24gUHJv dG9jb2wgKENvQVApICAgICAgTWFyY2ggMjAxMQoKCiAgIHRoaXMgaW5pdGlhbCBieXRlIHRvIGJl IGRpc3Rpbmd1aXNoZWQgZnJvbSB2YWxpZCBEVExTIG1lc3NhZ2VzLgogICBBZ2FpbiwgZnV0dXJl IHZlcnNpb25zIG9mIENvQVAgd2lsbCBuZWVkIHRvIGF2b2lkIHVzaW5nIHZlcnNpb24KICAgbnVt YmVyIDAuICBTVFVOIG1lc3NhZ2VzIGFyZSBtb3N0IGxpa2VseSB0byBiZWdpbiB3aXRoIDB4MDAg YW5kIDB4MDEuCiAgIEFsbCBvdGhlciBTVFVOIG1lc3NhZ2VzIE1VU1QgYmUgZXNjYXBlZCB3aXRo IGFuIGluaXRpYWwgMHgxMCBieXRlICgxNgogICBkZWNpbWFsKS4gMHgxMCBNVVNUIE5PVCBiZSBm b2xsb3dlZCBieSAweDAwIG9yIDB4MDEgaGV4LCBpLmUuIHRoZQogICBtb3JlIGxpa2VseSBTVFVO IG1lc3NhZ2VzIGFyZSBhbHdheXMgc2VudCB1bmVzY2FwZWQuCgogICBGdXR1cmUgdmVyc2lvbnMg b2YgQ29BUCBjb3VsZCBwb3RlbnRpYWxseSBtYWtlIGNoYW5nZXMgdG8gdGhlIENvQVAKICAgaGVh ZGVyIHN0cnVjdHVyZSB0aGF0IGFyZSBub3QgYmFja3dhcmRzIGNvbXBhdGlibGUgdG8gdGhlIGN1 cnJlbnQKICAgdmVyc2lvbi4gIEluIG9yZGVyIHRvIGFsbG93IGRlbXVsdGlwbGV4aW5nIHRob3Nl IHBhY2tldHMgdGhhdCBhZGhlcmUKICAgdG8gdGhlIHByZXNlbnQgdmVyc2lvbiBvZiBDb0FQIGZy b20gdGhvc2UgdXNpbmcgdGhlIGZ1dHVyZSB2ZXJzaW9uLAogICB0aGUgbmV3IHZlcnNpb24gbWF5 IHdhbnQgdG8gaW5jcmVhc2UgdGhlIENvQVAgdmVyc2lvbiBudW1iZXIgaW4gdGhlCiAgIGhlYWRl ciAoZml4ZWQgYXQgIjEiIGluIHRoZSBwcmVzZW50IHNwZWNpZmljYXRpb24pIGFuZC9vciBtYWtl IG90aGVyCiAgIGNoYW5nZXMgaW4gdGhlIGluaXRpYWwgYnl0ZSBhbmQvb3IgdGhlIGVzY2FwaW5n IHJ1bGVzLiAgV2hhdGV2ZXIKICAgdGhlc2UgY2hhbmdlcyBtYXkgYmUsIHRoZWlyIG9iamVjdGl2 ZSB3aWxsIGJlIHRvIGVuYWJsZSBzZWFtbGVzcwogICBpbnRlcndvcmtpbmcgb2YgZXhpc3Rpbmcg YW5kIG5ldyBwcm90b2NvbCBpbXBsZW1lbnRhdGlvbnMgdG8gZW5hYmxlCiAgIGFuIG9yZGVybHkg dHJhbnNpdGlvbiB0byB0aGUgbmV3IHZlcnNpb24uCgogICBOb3RlIHRoYXQgdGhlIGVzY2FwaW5n IHJ1bGVzIGRlZmluZWQgaW4gdGhpcyBzZWN0aW9uIGFyZSBpbnN1cmFuY2UKICAgZm9yIHRoZSBm dXR1cmU7IHRoZXkgbmVlZCBubyBhZGRpdGlvbmFsIGNvZGUgaW4gaW1wbGVtZW50YXRpb25zIHRo YXQKICAgZG8gbm90IGltcGxlbWVudCBTVFVOIG9yIERUTFMgb3IgaW1wbGVtZW50IG9ubHkgdGhl IHZlcnNpb25zIGN1cnJlbnQKICAgYXQgdGhlIHRpbWUgb2Ygd3JpdGluZy4gIEZvciBlYXN5IHJl ZmVyZW5jZSwgVGFibGUgMiBzdW1tYXJpemVzIHRoZQogICBydWxlcyB1cG9uIHJlY2VwdGlvbi4K CiAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0t LS0tLSsKICAgICAgICAgICAgICB8IGluaXRpYWwgYnl0ZSB8IGRpc3Bvc2l0aW9uIHwgaW50ZXJw cmV0YXRpb24gfAogICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tLS0tLS0rCiAgICAgICAgICAgICAgfCAweDAwIG9yIDB4MDEgfCBrZWVwICAgICAg ICB8IFNUVU4gICAgICAgICAgIHwKICAgICAgICAgICAgICB8IDB4MTAgICAgICAgICB8IHJlbW92 ZSAgICAgIHwgU1RVTiAgICAgICAgICAgfAogICAgICAgICAgICAgIHwgMHgxMSAgICAgICAgIHwg cmVtb3ZlICAgICAgfCBEVExTICAgICAgICAgICB8CiAgICAgICAgICAgICAgfCAweDE0IHRvIDB4 MTcgfCBrZWVwICAgICAgICB8IERUTFMgICAgICAgICAgIHwKICAgICAgICAgICAgICB8IDB4NDAg dG8gMHg3RiB8IGtlZXAgICAgICAgIHwgQ29BUCAgICAgICAgICAgfAogICAgICAgICAgICAgIHwg YWxsIG90aGVycyAgIHwgICAgICAgICAgICAgfCAoaW52YWxpZCkgICAgICB8CiAgICAgICAgICAg ICAgKy0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLSsKCiAgICAg ICAgIFRhYmxlIDI6IEludGVycHJldGF0aW9uIG9mIGluaXRpYWwgYnl0ZSB3aGVuIG11bHRpcGxl eGluZwoKCjguICBIVFRQIE1hcHBpbmcKCiAgIENvQVAgc3VwcG9ydHMgYSBsaW1pdGVkIHN1YnNl dCBvZiBIVFRQIGZ1bmN0aW9uYWxpdHksIGFuZCB0aHVzIGEKICAgbWFwcGluZyB0byBIVFRQIGlz IHN0cmFpZ2h0Zm9yd2FyZC4gIFRoZXJlIG1pZ2h0IGJlIHNldmVyYWwgcmVhc29ucwogICBmb3Ig bWFwcGluZyBiZXR3ZWVuIENvQVAgYW5kIEhUVFAsIGZvciBleGFtcGxlIHdoZW4gZGVzaWduaW5n IGEgd2ViCiAgIGludGVyZmFjZSBmb3IgdXNlIG92ZXIgZWl0aGVyIHByb3RvY29sIG9yIHdoZW4g cmVhbGl6aW5nIGEgQ29BUC1IVFRQCiAgIHByb3h5LiAgTGlrZXdpc2UsIENvQVAgY291bGQgZXF1 YWxseSBiZSBtYXBwZWQgdG8gb3RoZXIgcHJvdG9jb2xzCiAgIHN1Y2ggYXMgWE1QUCBbUkZDMzky MF0gb3IgU0lQIFtSRkMzMjY0XSwgVGhlIGRlZmluaXRpb24gb2YgdGhlc2UKICAgbWFwcGluZ3Mg aXMgb3V0IG9mIHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbi4KCgoKClNoZWxieSwgZXQgYWwu ICAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMTUsIDIwMTEgICAgICAgICAgICAgIFtQYWdlIDQy XQoMCkludGVybmV0LURyYWZ0ICAgQ29uc3RyYWluZWQgQXBwbGljYXRpb24gUHJvdG9jb2wgKENv QVApICAgICAgTWFyY2ggMjAxMQoKCiAgIFRoaXMgc2VjdGlvbiBkaXNjdXNzZXMgdHdvIHdheXMg b2YgbWFwcGluZzoKCiAgIENvQVAtSFRUUCBNYXBwaW5nOiAgRW5hYmxlcyBDb0FQIGNsaWVudHMg dG8gYWNjZXNzIHJlc291cmNlcyBvbiBIVFRQCiAgICAgIHNlcnZlcnMgdGhyb3VnaCBhbiBpbnRl cm1lZGlhcnkuICBUaGlzIGlzIGluaXRpYXRlZCBieSBpbmNsdWRpbmcKICAgICAgdGhlIFByb3h5 LVVyaSBPcHRpb24gd2l0aCBhbiAiaHR0cCIgVVJJIGluIGEgQ29BUCByZXF1ZXN0IHRvIGEKICAg ICAgQ29BUC1IVFRQIHByb3h5LCBvciBieSBzZW5kaW5nIGEgQ29BUCByZXF1ZXN0IHRvIGEgcmV2 ZXJzZSBwcm94eQogICAgICB0aGF0IG1hcHMgQ29BUCB0byBIVFRQLgoKICAgSFRUUC1Db0FQIE1h cHBpbmc6ICBFbmFibGVzIEhUVFAgY2xpZW50cyB0byBhY2Nlc3MgcmVzb3VyY2VzIG9uIENvQVAK ICAgICAgc2VydmVycyB0aHJvdWdoIGFuIGludGVybWVkaWFyeS4gIFRoaXMgaXMgaW5pdGlhdGVk IGJ5IHNwZWNpZnlpbmcKICAgICAgYSAiY29hcCIgVVJJIGluIHRoZSBSZXF1ZXN0LUxpbmUgb2Yg YW4gSFRUUCByZXF1ZXN0IHRvIGFuIEhUVFAtCiAgICAgIENvQVAgcHJveHksIG9yIGJ5IHNlbmRp bmcgYW4gSFRUUCByZXF1ZXN0IHRvIGEgcmV2ZXJzZSBwcm94eSB0aGF0CiAgICAgIG1hcHMgSFRU UCB0byBDb0FQLgoKICAgRWl0aGVyIHdheSwgb25seSB0aGUgUmVxdWVzdC9SZXNwb25zZSBtb2Rl bCBvZiBDb0FQIGlzIG1hcHBlZCB0bwogICBIVFRQLiAgVGhlIHVuZGVybHlpbmcgbW9kZWwgb2Yg Y29uZmlybWFibGUgb3Igbm9uLWNvbmZpcm1hYmxlCiAgIG1lc3NhZ2VzLCBldGMuLCBpcyBpbnZp c2libGUgYW5kIE1VU1QgaGF2ZSBubyBlZmZlY3Qgb24gYSBwcm94eQogICBmdW5jdGlvbi4KCjgu MS4gIENvQVAtSFRUUCBNYXBwaW5nCgogICBUaGUgbWFwcGluZyBvZiBDb0FQIHRvIEhUVFAgaXMg YSByZWxhdGl2ZWx5IHN0cmFpZ2h0Zm9yd2FyZAogICBjb252ZXJzaW9uIG9mIHRoZSBDb0FQIG1l dGhvZCBvciByZXNwb25zZSBjb2RlLCBjb250ZW50LXR5cGUgYW5kCiAgIG9wdGlvbnMgdG8gdGhl IGNvcnJlc3BvbmRpbmcgSFRUUCBmZWF0dXJlLiAgVGhlIHBheWxvYWQgaXMgY2FycmllZCBpbgog ICBhbiBlcXVpdmFsZW50IHdheSBieSBib3RoIHByb3RvY29scy4KCiAgIEluIGEgc2ltaWxhciBt YW5uZXIgdG8gQ29BUC1Db0FQIHByb3h5aW5nIHtub3RlIHRoYXQgQ29BUC1Db0FQIHByb3h5aW5n IAogICBoYXMgbm90IGJlZW4gZGlzY3Vzc2VkIGFueXdoZXJlLCBzbyBpdCBpcyBwcm9iYWJseSBu b3QgZ29vZCB0bwogICBpbnZpdGUgcmVhZGVycyB0byBkcmF3IGNvbXBhcmlzb25zIHdpdGggaXR9 LCB0aGUgQ29BUC1IVFRQIHByb3h5IE1BWQogICBwZXJmb3JtIGNhY2hpbmcgb2YgSFRUUCByZXNw b25zZXMuICBJZiBubyBjYWNoaW5nIGlzIHBlcmZvcm1lZCwgYQogICBDb0FQIEdFVCByZXF1ZXN0 IHRoYXQgc3BlY2lmaWVzIGFuIGVudGl0eS10YWcgaW4gYW4gRVRhZyBPcHRpb24KICAgU0hPVUxE IGJlIG1hcHBlZCB0byBhIGNvbmRpdGlvbmFsIEhUVFAgcmVxdWVzdCB0aGF0IGluY2x1ZGVzIHRo ZQogICBlbnRpdHktdGFnIGluIHRoZSAiSWYtTm9uZS1NYXRjaCIgcmVxdWVzdC1oZWFkZXIgZmll bGQuICBJZiB0aGUKICAgZW50aXR5LXRhZyBtYXRjaGVzIHRoZSBlbnRpdHktdGFnIG9mIHRoZSBy ZXByZXNlbnRhdGlvbiwgdGhlIEhUVFAKICAgc2VydmVyIHJlc3BvbmRzIHdpdGggYW4gSFRUUCAz MDQgKE5vdCBNb2RpZmllZCkgcmVzcG9uc2Ugd2hpY2ggU0hPVUxECiAgIGJlIG1hcHBlZCB0byBh IENvQVAgMi4wMyAoVmFsaWQpIHJlc3BvbnNlIHdpdGggdGhlIEVUYWcgT3B0aW9uCiAgIHJlZmxl Y3RpbmcgdGhlIHJlc3BvbnNlJ3MgIkVUYWciIHJlc3BvbnNlLWhlYWRlciBmaWVsZC4gIFRoZSBt YXBwaW5nCiAgIG9mIG1heC1hZ2UgaXMgc3RyYWlnaHRmb3J3YXJkLgoKICAgSFRUUCBlbnRpdHkt dGFncyBjb25zaXN0IG9mIGNoYXJhY3RlcnMgaW4gYSBzdWJzZXQgb2YgdGhlIFVTLUFTQ0lJCiAg IGNoYXJhY3RlciBzZXQsIHdoaWNoIGNhbiBiZSBjYXJyaWVkIGRpcmVjdGx5IGluIGEgQ29BUCBF VGFnIE9wdGlvbi4KICAgV2VhayBlbnRpdHktdGFncyBhcmUgbm90IHN1cHBvcnRlZCBieSB0aGlz IG1hcHBpbmcuICBIb3dldmVyLCBhbgogICBlbnRpdHktdGFnIG1heSBub3QgZml0IHdpdGhpbiB0 aGUgQ29BUCBFVGFnIE9wdGlvbi4gIEluIHRoaXMgY2FzZSwKICAgdGhlIHByb3h5IE1BWSBtYXAg dGhlIGVudGl0eS10YWcgdG8gYSBzaG9ydGVyIHVuaXF1ZSBieXRlIHNlcXVlbmNlCiAgIGFuZCBr ZWVwIHN0YXRlLCBvciBNQVkgc2lsZW50bHkgaWdub3JlIHRoZSAiRVRhZyIgcmVzcG9uc2UtaGVh ZGVyCiAgIHdoZW4gbWFwcGluZyBhbiBIVFRQIHJlc3BvbnNlIHRvIENvQVAgKHNvIHRoZSBDb0FQ IGNsaWVudCB3aWxsIG5ldmVyCiAgIHNlbmQgYSBDb0FQIEdFVCByZXF1ZXN0IHdpdGggYW4gRVRh ZyBPcHRpb24pLgoKICAgUHJvdmlzaW9uYWwgcmVzcG9uc2VzIChIVFRQIFN0YXR1cyBDb2RlcyAx eHgpLCBhbmQgcmVzcG9uc2VzCiAgIGluZGljYXRpbmcgdGhhdCBmdXJ0aGVyIGFjdGlvbiBuZWVk cyB0byBiZSB0YWtlbiAoSFRUUCBTdGF0dXMgQ29kZXMKCgoKU2hlbGJ5LCBldCBhbC4gICAgICAg ICBFeHBpcmVzIFNlcHRlbWJlciAxNSwgMjAxMSAgICAgICAgICAgICAgW1BhZ2UgNDNdCgwKSW50 ZXJuZXQtRHJhZnQgICBDb25zdHJhaW5lZCBBcHBsaWNhdGlvbiBQcm90b2NvbCAoQ29BUCkgICAg ICBNYXJjaCAyMDExCgoKICAgM3h4KSwgU0hPVUxEIGNhdXNlIHRoZSBwcm94eSB0byBjb21wbGV0 ZSB0aGUgcmVxdWVzdCwgZS5nLiwgYnkKICAgZm9sbG93aW5nIHRoZSByZWRpcmVjdHMuICBJZiB0 aGUgcHJveHkgaXMgdW5hYmxlIHRvIGNvbXBsZXRlIHRoZQogICByZXF1ZXN0LCBpdCBTSE9VTEQg cmVzcG9uZCB3aXRoIGEgQ29BUCA1LjAyIChCYWQgR2F0ZXdheSkgZXJyb3IuCgogICBIVFRQIHJl c3BvbnNlcyBhcmUgbWFwcGVkIHRvIENvQVAgcmVzcG9uc2VzIGFzIGZvbGxvd3M6CgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpTaGVsYnksIGV0IGFsLiAgICAg ICAgIEV4cGlyZXMgU2VwdGVtYmVyIDE1LCAyMDExICAgICAgICAgICAgICBbUGFnZSA0NF0KDApJ bnRlcm5ldC1EcmFmdCAgIENvbnN0cmFpbmVkIEFwcGxpY2F0aW9uIFByb3RvY29sIChDb0FQKSAg ICAgIE1hcmNoIDIwMTEKCgogICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLSsKICAgfCBIVFRQIFN0YXR1cyBDb2RlICAg ICAgICAgICAgICB8IENvQVAgUmVzcG9uc2UgQ29kZSAgICAgICAgfCBOb3RlcyB8CiAgICstLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSst LS0tLS0tKwogICB8IDEwMCBDb250aW51ZSAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAg ICAgICAgICAgICAgICB8IDIgICAgIHwKICAgfCAxMDEgU3dpdGNoaW5nIFByb3RvY29scyAgICAg ICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAyICAgICB8CiAgIHwgMjAwIE9LICAgICAg ICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgMyAgICAgfAog ICB8IDIwMSBDcmVhdGVkICAgICAgICAgICAgICAgICAgIHwgMi4wMSBDcmVhdGVkICAgICAgICAg ICAgICB8ICAgICAgIHwKICAgfCAyMDIgQWNjZXB0ZWQgICAgICAgICAgICAgICAgICB8ICAgICAg ICAgICAgICAgICAgICAgICAgICAgfCA0ICAgICB8CiAgIHwgMjAzIE5vbi1BdXRob3JpdGF0aXZl ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgNCAgICAgfAogICB8IEluZm9y bWF0aW9uICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAg ICAgIHwKICAgfCAyMDQgTm8gQ29udGVudCAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAg ICAgICAgICAgICAgfCA2ICAgICB8CiAgIHwgMjA1IFJlc2V0IENvbnRlbnQgICAgICAgICAgICAg fCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgNCAgICAgfAogICB8IDIwNiBQYXJ0aWFsIENv bnRlbnQgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICB8IDIgICAgIHwKICAg fCAzMDAgTXVsdGlwbGUgQ2hvaWNlcyAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg ICAgfCAyICAgICB8CiAgIHwgMzAxIE1vdmVkIFBlcm1hbmVudGx5ICAgICAgICAgfCAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwgMiAgICAgfAogICB8IDMwMiBGb3VuZCAgICAgICAgICAgICAg ICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICB8IDIgICAgIHwKICAgfCAzMDMgU2Vl IE90aGVyICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAyICAg ICB8CiAgIHwgMzA0IE5vdCBNb2RpZmllZCAgICAgICAgICAgICAgfCAyLjAzIFZhbGlkICAgICAg ICAgICAgICAgIHwgNyAgICAgfAogICB8IDMwNSBVc2UgUHJveHkgICAgICAgICAgICAgICAgIHwg ICAgICAgICAgICAgICAgICAgICAgICAgICB8IDIgICAgIHwKICAgfCAzMDYgKFVudXNlZCkgICAg ICAgICAgICAgICAgICB8IDUuMDIgQmFkIEdhdGV3YXkgICAgICAgICAgfCAxICAgICB8CiAgIHwg MzA3IFRlbXBvcmFyeSBSZWRpcmVjdCAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAg IHwgMiAgICAgfAogICB8IDQwMCBCYWQgUmVxdWVzdCAgICAgICAgICAgICAgIHwgNC4wMCBCYWQg UmVxdWVzdCAgICAgICAgICB8ICAgICAgIHwKICAgfCA0MDEgVW5hdXRob3JpemVkICAgICAgICAg ICAgICB8IDQuMDEgVW5hdXRob3JpemVkICAgICAgICAgfCA1ICAgICB8CiAgIHwgNDAyIFBheW1l bnQgUmVxdWlyZWQgICAgICAgICAgfCA0LjAwIEJhZCBSZXF1ZXN0ICAgICAgICAgIHwgMSAgICAg fAogICB8IDQwMyBGb3JiaWRkZW4gICAgICAgICAgICAgICAgIHwgNC4wMyBGb3JiaWRkZW4gICAg ICAgICAgICB8ICAgICAgIHwKICAgfCA0MDQgTm90IEZvdW5kICAgICAgICAgICAgICAgICB8IDQu MDQgTm90IEZvdW5kICAgICAgICAgICAgfCAgICAgICB8CiAgIHwgNDA1IE1ldGhvZCBOb3QgQWxs b3dlZCAgICAgICAgfCA0LjA1IE1ldGhvZCBOb3QgQWxsb3dlZCAgIHwgOCAgICAgfAogICB8IDQw NiBOb3QgQWNjZXB0YWJsZSAgICAgICAgICAgIHwgNC4wMCBCYWQgUmVxdWVzdCAgICAgICAgICB8 IDEgICAgIHwKICAgfCA0MDcgUHJveHkgQXV0aGVudGljYXRpb24gICAgICB8IDQuMDAgQmFkIFJl cXVlc3QgICAgICAgICAgfCAxICAgICB8CiAgIHwgUmVxdWlyZWQgICAgICAgICAgICAgICAgICAg ICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgfAogICB8IDQwOCBSZXF1ZXN0 IFRpbWVvdXQgICAgICAgICAgIHwgNC4wMCBCYWQgUmVxdWVzdCAgICAgICAgICB8IDEgICAgIHwK ICAgfCA0MDkgQ29uZmxpY3QgICAgICAgICAgICAgICAgICB8IDQuMDAgQmFkIFJlcXVlc3QgICAg ICAgICAgfCAxICAgICB8CiAgIHwgNDEwIEdvbmUgICAgICAgICAgICAgICAgICAgICAgfCA0LjAw IEJhZCBSZXF1ZXN0ICAgICAgICAgIHwgMSAgICAgfAogICB8IDQxMSBMZW5ndGggUmVxdWlyZWQg ICAgICAgICAgIHwgNC4wMCBCYWQgUmVxdWVzdCAgICAgICAgICB8IDEgICAgIHwKICAgfCA0MTIg UHJlY29uZGl0aW9uIEZhaWxlZCAgICAgICB8IDQuMDAgQmFkIFJlcXVlc3QgICAgICAgICAgfCAx ICAgICB8CiAgIHwgNDEzIFJlcXVlc3QgRW50aXR5IFRvbyBMYXJnZSAgfCA0LjEzIFJlcXVlc3Qg RW50aXR5IFRvbyAgIHwgICAgICAgfAogICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwgTGFyZ2UgICAgICAgICAgICAgICAgICAgICB8ICAgICAgIHwKICAgfCA0MTQgVVJJIFRvbyBM b25nICAgICAgICAgICAgICB8IDQuMDAgQmFkIFJlcXVlc3QgICAgICAgICAgfCAxICAgICB8CiAg IHwgNDE1IFVuc3VwcG9ydGVkIE1lZGlhIFR5cGUgICAgfCA0LjE1IFVuc3VwcG9ydGVkIE1lZGlh ICAgIHwgICAgICAgfAogICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgVHlwZSAg ICAgICAgICAgICAgICAgICAgICB8ICAgICAgIHwKICAgfCA0MTYgUmVxdWVzdGVkIFJhbmdlIE5v dCAgICAgICB8IDQuMDAgQmFkIFJlcXVlc3QgICAgICAgICAgfCAxICAgICB8CiAgIHwgU2F0aXNm aWFibGUgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAg ICAgfAogICB8IDQxNyBFeHBlY3RhdGlvbiBGYWlsZWQgICAgICAgIHwgNC4wMCBCYWQgUmVxdWVz dCAgICAgICAgICB8IDEgICAgIHwKICAgfCA1MDAgSW50ZXJuYWwgU2VydmVyIEVycm9yICAgICB8 IDUuMDAgSW50ZXJuYWwgU2VydmVyICAgICAgfCAgICAgICB8CiAgIHwgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgfCBFcnJvciAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgfAogICB8 IDUwMSBOb3QgSW1wbGVtZW50ZWQgICAgICAgICAgIHwgNS4wMSBOb3QgSW1wbGVtZW50ZWQgICAg ICB8ICAgICAgIHwKICAgfCA1MDIgQmFkIEdhdGV3YXkgICAgICAgICAgICAgICB8IDUuMDIgQmFk IEdhdGV3YXkgICAgICAgICAgfCAgICAgICB8CiAgIHwgNTAzIFNlcnZpY2UgVW5hdmFpbGFibGUg ICAgICAgfCA1LjAzIFNlcnZpY2UgVW5hdmFpbGFibGUgIHwgOSAgICAgfAoKCgpTaGVsYnksIGV0 IGFsLiAgICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDE1LCAyMDExICAgICAgICAgICAgICBbUGFn ZSA0NV0KDApJbnRlcm5ldC1EcmFmdCAgIENvbnN0cmFpbmVkIEFwcGxpY2F0aW9uIFByb3RvY29s IChDb0FQKSAgICAgIE1hcmNoIDIwMTEKCgogICB8IDUwNCBHYXRld2F5IFRpbWVvdXQgICAgICAg ICAgIHwgNS4wNCBHYXRld2F5IFRpbWVvdXQgICAgICB8ICAgICAgIHwKICAgfCA1MDUgSFRUUCBW ZXJzaW9uIE5vdCAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAyICAgICB8 CiAgIHwgU3VwcG9ydGVkICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwgICAgICAgfAogICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLSsKCiAgICAgICAgICAgICAgICAgICAgICAg IFRhYmxlIDM6IENvQVAtSFRUUCBNYXBwaW5nCgogICBOb3RlczoKCiAgIDEuICBUaGVyZSBpcyBu byBlcXVpdmFsZW50IENvQVAgcmVzcG9uc2UuCgogICAyLiAgVGhlIHByb3h5IHNob3VsZCBwZXJm b3JtIHRoZSBhY3Rpb24gaW1wbGllZCBieSB0aGUgcmVzcG9uc2UgY29kZQogICAgICAgKGUuZy4s IGJ5IGZvbGxvd2luZyByZWRpcmVjdHMpOyBpLmUuIHRoaXMgcmVzcG9uc2UgaXMgbmV2ZXIKICAg ICAgIGZvcndhcmRlZCB0byB0aGUgQ29BUCBjbGllbnQuICBJZiB0aGUgcHJveHkgaXMgdW5hYmxl IG9yCiAgICAgICB1bndpbGxpbmcgdG8gcGVyZm9ybSB0aGlzIGZ1bmN0aW9uLCB0aGUgQ29BUCBy ZXNwb25zZSBjb2RlIDUuMDIKICAgICAgIChCYWQgR2F0ZXdheSkgY2FuIGJlIHJldHVybmVkLgoK ICAgMy4gIFRoZSBDb0FQIHJlc3BvbnNlIGNvZGUgZGVwZW5kcyBvbiB0aGUgcmVxdWVzdCBtZXRo b2QuICBGb3IgYSBHRVQKICAgICAgIHJlcXVlc3QsIHRoZSByZXNwb25zZSBjb2RlIFNIT1VMRCBi ZSAyLjA1IChDb250ZW50KS4gIEZvciBhIFBPU1QsCiAgICAgICBQVVQgb3IgREVMRVRFIHJlcXVl c3QsIHRoZSBtYXBwaW5nIGlzIG9ubHkgcGFydGlhbDogcmVzcG9uc2UKICAgICAgIGVudGl0aWVz IGFyZSBpZ25vcmVkLCBhbmQgdGhlIHJlc3BvbnNlIGNvZGUgZGVwZW5kcyBvbiB0aGUgbWV0aG9k CiAgICAgICBhcyBkZWZpbmVkIGluIFNlY3Rpb24gNS44LgoKICAgNC4gIChUaGUgbWFwcGluZyBm b3IgdGhlc2UgcmFyZWx5LXVzZWQgc3RhdHVzIGNvZGVzIGlzIG5vdCBkZWZpbmVkIGluCiAgICAg ICB0aGlzIHNwZWNpZmljYXRpb24uKQoKICAgNS4gIFRoZSBIVFRQICJXV1ctQXV0aGVudGljYXRl IiByZXNwb25zZS1oZWFkZXIgZmllbGQgaGFzIG5vCiAgICAgICBlcXVpdmFsZW50IG9wdGlvbiBp biBDb0FQIGFuZCBpcyBlaXRoZXIgcHJvY2Vzc2VkIGJ5IHRoZSBwcm94eSBieQogICAgICAgcGVy Zm9ybWluZyBhbiBhZGRpdGlvbmFsIHJlcXVlc3Qgb3Igc2lsZW50bHkgZHJvcHBlZC4KCiAgIDYu ICBUaGUgQ29BUCByZXNwb25zZSBjb2RlIGRlcGVuZHMgb24gdGhlIHJlcXVlc3QgbWV0aG9kLiAg Rm9yIGEgUE9TVAogICAgICAgb3IgUFVUIHJlcXVlc3QsIHRoZSByZXNwb25zZSBjb2RlIFNIT1VM RCBiZSAyLjA0IChDaGFuZ2VkKTsgZm9yIGEKICAgICAgIERFTEVURSByZXF1ZXN0LCAyLjAyIChE ZWxldGVkKS4KCiAgIDcuICBTaW5jZSBhIENvQVAgcmVxdWVzdCB3aXRoIEVUYWcgT3B0aW9uIGlz IG1hcHBlZCB0byBhIGNvbmRpdGlvbmFsCiAgICAgICBIVFRQIEdFVCByZXF1ZXN0IHdpdGggYSAi SWYtTm9uZS1NYXRjaCIgcmVxdWVzdC1oZWFkZXIgZmllbGQsIGFueQogICAgICAgSFRUUCAzMDQg KE5vdCBNb2RpZmllZCkgcmVzcG9uc2Ugd2lsbCBjb25maXJtIHRoYXQgdGhlIEVUYWcgaXMKICAg ICAgIHZhbGlkLiAgRXhjZXB0IGZvciB0aGUgbWF4LWFnZSBkaXJlY3RpdmUgb2YgdGhlIENhY2hl LUNvbnRyb2wKICAgICAgIGhlYWRlciBmaWVsZCwgYW55IGFkZGl0aW9uYWwgaGVhZGVycyBpbiB0 aGUgSFRUUCBOb3QgTW9kaWZpZWQKICAgICAgIHJlc3BvbnNlIGFyZSBub3QgY2FycmllZCB0aHJv dWdoIHRvIHRoZSBDb0FQIGNsaWVudCwgdGhvdWdoLgoKICAgOC4gIFRoZSBIVFRQICJBY2NlcHQi IHJlc3BvbnNlLWhlYWRlciBmaWVsZCBoYXMgbm8gZXF1aXZhbGVudCBvcHRpb24KICAgICAgIGlu IENvQVAgYW5kIGlzIHNpbGVudGx5IGRyb3BwZWQuCgogICA5LiAgVGhlIEhUVFAgIlJldHJ5LUFm dGVyIiByZXNwb25zZS1oZWFkZXIgZmllbGQgaGFzIG5vIGVxdWl2YWxlbnQKICAgICAgIG9wdGlv biBpbiBDb0FQLCBhbHRob3VnaCBpdCBtYXkgYmUgdXNlZCB0byBmaW5kIGEgdmFsdWUgZm9yIHRo ZQogICAgICAgTWF4LUFnZSBPcHRpb24uCgoKCgpTaGVsYnksIGV0IGFsLiAgICAgICAgIEV4cGly ZXMgU2VwdGVtYmVyIDE1LCAyMDExICAgICAgICAgICAgICBbUGFnZSA0Nl0KDApJbnRlcm5ldC1E cmFmdCAgIENvbnN0cmFpbmVkIEFwcGxpY2F0aW9uIFByb3RvY29sIChDb0FQKSAgICAgIE1hcmNo IDIwMTEKCgo4LjIuICBIVFRQLUNvQVAgTWFwcGluZwoKICAgVGhlIG1hcHBpbmcgb2YgSFRUUCB0 byBDb0FQIHJlcXVpcmVzIGNoZWNraW5nIGZvciBtZXRob2RzLCByZXNwb25zZQogICBjb2RlcyBh bmQgb3B0aW9ucyB0aGF0IGFyZSBub3Qgc3VwcG9ydGVkIGJ5IENvQVAuICBBIHByb3h5IFNIT1VM RAogICBhdHRlbXB0IHRvIG1hcCBvcHRpb25zLCByZXNwb25zZSBjb2RlcyBhbmQgY29udGVudC10 eXBlcyB0byBhCiAgIHN1aXRhYmxlIGFsdGVybmF0aXZlIGlmIHBvc3NpYmxlLiAgT3RoZXJ3aXNl IHRoZSB1bnN1cHBvcnRlZCBmZWF0dXJlCiAgIFNIT1VMRCBiZSBzaWxlbnRseSBkcm9wcGVkIGlm IHBvc3NpYmxlLCBvciBhbiBhcHByb3ByaWF0ZSBlcnJvciBjb2RlCiAgIGdlbmVyYXRlZCBvdGhl cndpc2UuCgogICBNYXBwaW5nIE1BWSBpbmNsdWRlIHBlcmZvcm1pbmcgcGF5bG9hZCBjb252ZXJz aW9uIChlLmcuLCBmcm9tIEVYSSB0bwogICBYTUwpLCB0aGUgZGVmaW5pdGlvbiBvZiB3aGljaCBp cyBvdXQgb2YgdGhpcyBkb2N1bWVudCdzIHNjb3BlLgoKICAgT25seSB0aG9zZSBDb25kaXRpb25h bCBIVFRQIHJlcXVlc3RzIGNhbiBiZSBtYXBwZWQgdG8gQ29BUCByZXF1ZXN0cwogICB0aGF0IGhh dmUgbWV0aG9kIEdFVCBhbmQgaW5jbHVkZSBhICJJZi1Ob25lLU1hdGNoIiByZXF1ZXN0LWhlYWRl cgogICBmaWVsZC4gIFRoZSAiSWYtTWF0Y2giLCAiSWYtTW9kaWZpZWQtU2luY2UiIGFuZCAiSWYt VW5tb2RpZmllZC1TaW5jZSIKICAgcmVxdWVzdC1oZWFkZXIgZmllbGRzIGFyZSBub3Qgc3VwcG9y dGVkIG9uIHRoZSBDb0FQIHNpZGUsIGJ1dCBjb3VsZAogICBiZSBpbXBsZW1lbnRlZCBsb2NhbGx5 IGJ5IGEgY2FjaGluZyBwcm94eS4gIEEgSFRUUC1Db0FQIHByb3h5IFNIT1VMRAogICBtYXAgRVRh Z3MgZ2VuZXJhdGVkIGJ5IGEgQ29BUCBzZXJ2ZXIgdG8gSFRUUC1mcmllbmRseSBFVGFncyBieSB1 c2luZwogICBCYXNlNjQgW1JGQzQ2NDhdLgogICAKICAge0l0IGlzIGNsZWFyZXIgdG8gc2F5IHRo aXMsIEkgdGhpbms6ICJPbmx5IHRob3NlIENvbmRpdGlvbmFsIEhUVFAgcmVxdWVzdHMgCiAgIHRo YXQgaGF2ZSBtZXRob2QgR0VUIGFuZCBpbmNsdWRlIGEgIklmLU5vbmUtTWF0Y2giIHJlcXVlc3Qt aGVhZGVyCiAgIGZpZWxkIGNhbiBiZSBtYXBwZWQgdG8gQ29BUCByZXF1ZXN0cy4ifQoKICAgQSBw cm94eSBTSE9VTEQgcmVzcG9uZCB3aXRoIGEgSFRUUCA1MDIgKEJhZCBHYXRld2F5KSBlcnJvciB0 byBIVFRQCiAgIHJlcXVlc3RzIHdoaWNoIGNhbiBub3QgYmUgc3VjY2Vzc2Z1bGx5IG1hcHBlZCB0 byBDb0FQLgoKICAgQSBwcm94eSBTSE9VTEQgZW1wbG95IGEgY2FjaGUgdG8gbGltaXQgdHJhZmZp YyBvbiB0aGUgY29uc3RyYWluZWQKICAgbmV0d29yay4KCiAgIENvQVAgcmVzcG9uc2VzIGFyZSBt YXBwZWQgdG8gSFRUUCByZXNwb25zZXMgYXMgZm9sbG93czoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKU2hlbGJ5LCBldCBhbC4gICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAxNSwgMjAxMSAgICAg ICAgICAgICAgW1BhZ2UgNDddCgwKSW50ZXJuZXQtRHJhZnQgICBDb25zdHJhaW5lZCBBcHBsaWNh dGlvbiBQcm90b2NvbCAoQ29BUCkgICAgICBNYXJjaCAyMDExCgoKICAgKy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0rCiAg IHwgQ29BUCBSZXNwb25zZSBDb2RlICAgICAgICAgIHwgSFRUUCBTdGF0dXMgQ29kZSAgICAgICAg ICAgIHwgTm90ZXMgfAogICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLSsKICAgfCAyLjAxIENyZWF0ZWQgICAgICAgICAg ICAgICAgfCAyMDEgQ3JlYXRlZCAgICAgICAgICAgICAgICAgfCAgICAgICB8CiAgIHwgMi4wMiBE ZWxldGVkICAgICAgICAgICAgICAgIHwgMjA0IE5vIENvbnRlbnQgICAgICAgICAgICAgIHwgICAg ICAgfAogICB8IDIuMDMgVmFsaWQgICAgICAgICAgICAgICAgICB8IDMwNCBOb3QgTW9kaWZpZWQg ICAgICAgICAgICB8IDEgICAgIHwKICAgfCAyLjA0IENoYW5nZWQgICAgICAgICAgICAgICAgfCAy MDQgTm8gQ29udGVudCAgICAgICAgICAgICAgfCAgICAgICB8CiAgIHwgMi4wNSBDb250ZW50ICAg ICAgICAgICAgICAgIHwgMjAwIE9LICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgfAogICB8 IDQuMDAgQmFkIFJlcXVlc3QgICAgICAgICAgICB8IDQwMCBCYWQgUmVxdWVzdCAgICAgICAgICAg ICB8ICAgICAgIHwKICAgfCA0LjAxIFVuYXV0aG9yaXplZCAgICAgICAgICAgfCA0MDAgQmFkIFJl cXVlc3QgICAgICAgICAgICAgfCAyICAgICB8CiAgIHwgNC4wMiBCYWQgT3B0aW9uICAgICAgICAg ICAgIHwgNDAwIEJhZCBSZXF1ZXN0ICAgICAgICAgICAgIHwgICAgICAgfAogICB8IDQuMDMgRm9y YmlkZGVuICAgICAgICAgICAgICB8IDQwMyBGb3JiaWRkZW4gICAgICAgICAgICAgICB8ICAgICAg IHwKICAgfCA0LjA0IE5vdCBGb3VuZCAgICAgICAgICAgICAgfCA0MDQgTm90IEZvdW5kICAgICAg ICAgICAgICAgfCAgICAgICB8CiAgIHwgNC4wNSBNZXRob2QgTm90IEFsbG93ZWQgICAgIHwgNDA1 IE1ldGhvZCBOb3QgQWxsb3dlZCAgICAgIHwgMyAgICAgfAogICB8IDQuMTMgUmVxdWVzdCBFbnRp dHkgVG9vICAgICB8IDQxMyBSZXF1ZXN0IEVudGl0eSBUb28gICAgICB8ICAgICAgIHwKICAgfCBM YXJnZSAgICAgICAgICAgICAgICAgICAgICAgfCBMYXJnZSAgICAgICAgICAgICAgICAgICAgICAg fCAgICAgICB8CiAgIHwgNC4xNSBVbnN1cHBvcnRlZCBNZWRpYSBUeXBlIHwgNDE1IFVuc3VwcG9y dGVkIE1lZGlhIFR5cGUgIHwgICAgICAgfAogICB8IDUuMDAgSW50ZXJuYWwgU2VydmVyIEVycm9y ICB8IDUwMCBJbnRlcm5hbCBTZXJ2ZXIgRXJyb3IgICB8ICAgICAgIHwKICAgfCA1LjAxIE5vdCBJ bXBsZW1lbnRlZCAgICAgICAgfCA1MDEgTm90IEltcGxlbWVudGVkICAgICAgICAgfCAgICAgICB8 CiAgIHwgNS4wMiBCYWQgR2F0ZXdheSAgICAgICAgICAgIHwgNTAyIEJhZCBHYXRld2F5ICAgICAg ICAgICAgIHwgICAgICAgfAogICB8IDUuMDMgU2VydmljZSBVbmF2YWlsYWJsZSAgICB8IDUwMyBT ZXJ2aWNlIFVuYXZhaWxhYmxlICAgICB8IDQgICAgIHwKICAgfCA1LjA0IEdhdGV3YXkgVGltZW91 dCAgICAgICAgfCA1MDQgR2F0ZXdheSBUaW1lb3V0ICAgICAgICAgfCAgICAgICB8CiAgIHwgNS4w NSBQcm94eWluZyBOb3QgU3VwcG9ydGVkIHwgNTAyIEJhZCBHYXRld2F5ICAgICAgICAgICAgIHwg ICAgICAgfAogICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0rLS0tLS0tLSsKCiAgICAgICAgICAgICAgICAgICAgICAgIFRhYmxlIDQ6 IEhUVFAtQ29BUCBNYXBwaW5nCgogICBOb3RlczoKCiAgIDEuICBBIENvQVAgMi4wMyAoVmFsaWQp IHJlc3BvbnNlIG9ubHkgKDEpIGNvbmZpcm1zIHRoYXQgdGhlIHJlcXVlc3QKICAgICAgIEVUYWcg aXMgdmFsaWQgYW5kICgyKSBwcm92aWRlcyBhIG5ldyBNYXgtQWdlIHZhbHVlLiAgSFRUUCAzMDQK ICAgICAgIChOb3QgTW9kaWZpZWQpIGFsc28gdXBkYXRlcyBzb21lIGhlYWRlciBmaWVsZHMgb2Yg YSBzdG9yZWQKICAgICAgIHJlc3BvbnNlLiAgQSBub24tY2FjaGluZyBwcm94eSBtYXkgbm90IGhh dmUgZW5vdWdoIGluZm9ybWF0aW9uIHRvCiAgICAgICBmaWxsIGluIHRoZSByZXF1aXJlZCB2YWx1 ZXMgaW4gdGhlIEhUVFAgMzA0IChOb3QgTW9kaWZpZWQpCiAgICAgICByZXNwb25zZSwgc28gaXQg bWF5IG5vdCBiZSBhZHZpc2FibGUgdG8gcHJvdm9rZSB0aGUgMi4wMyAoVmFsaWQpCiAgICAgICBy ZXNwb25zZSBieSBmb3J3YXJkaW5nIGFuIEVUYWcuICBBIGNhY2hpbmcgcHJveHkgd2lsbCBmaWxs IHRoZQogICAgICAgaW5mb3JtYXRpb24gb3V0IG9mIHRoZSBjYWNoZS4KCiAgIDIuICBUaGVyZSBp cyBubyBlcXVpdmFsZW50IEhUVFAgc3RhdHVzIGNvZGUuCgogICAzLiAgQ29BUCBkb2VzIG5vdCBw cm92aWRlIGVub3VnaCBpbmZvcm1hdGlvbiB0byBjb21wdXRlIGEgdmFsdWUgZm9yCiAgICAgICB0 aGUgcmVxdWlyZWQgIkFsbG93IiByZXNwb25zZS1oZWFkZXIgZmllbGQuICBJZiB0aGlzIHZpb2xh dGlvbiBvZgogICAgICAgW1JGQzI2MTZdIGNhbm5vdCBiZSB0b2xlcmF0ZWQsIHRoZSBwcm94eSBz aG91bGQgaW5zdGVhZCBzZW5kIGEKICAgICAgIDQuMDAgKEJhZCBSZXF1ZXN0KSByZXNwb25zZS4K CiAgIDQuICBUaGUgdmFsdWUgb2YgdGhlICJSZXRyeS1BZnRlciIgcmVzcG9uc2UtaGVhZGVyIGZp ZWxkIGlzIHRoZSB2YWx1ZQogICAgICAgb2YgdGhlIE1heC1BZ2UgT3B0aW9uLgoKCgoKU2hlbGJ5 LCBldCBhbC4gICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAxNSwgMjAxMSAgICAgICAgICAgICAg W1BhZ2UgNDhdCgwKSW50ZXJuZXQtRHJhZnQgICBDb25zdHJhaW5lZCBBcHBsaWNhdGlvbiBQcm90 b2NvbCAoQ29BUCkgICAgICBNYXJjaCAyMDExCgoKOS4gIFByb3RvY29sIENvbnN0YW50cwoKICAg VGhpcyBzZWN0aW9uIGRlZmluZXMgdGhlIHJlbGV2YW50IHByb3RvY29sIGNvbnN0YW50cyBkZWZp bmVkIGluIHRoaXMKICAgZG9jdW1lbnQ6CgogICBSRVNQT05TRV9USU1FT1VUICAyIHNlY29uZHMK CiAgIE1BWF9SRVRSQU5TTUlUICA0CgoKMTAuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucwoKe1N1 Z2dlc3Rpb24gdG8gZWRpdG9yOiBhZGQgbW9yZSBwYXJhZ3JhcGggYnJlYWtzIGluIFNlY3Rpb24g MTAuIEkgaGF2ZSAKc3VnZ2VzdGVkIHNvbWUuIEFsc28gLSBicmVhayBzb21lIHNlbnRlbmNlcyBp bnRvIHR3bz8gU29tZSBhcmUgdG9vCmxvbmcuIEFsc28gLSBjaGVjayB0aGF0IHlvdSBjYW4gcmVh bGx5IHVuZGVyc3RhbmQgZXZlcnkgc2VudGVuY2U6IAp0byBtZSBzb21lIGRvbid0IHJlYWQgdmVy eSBjbGVhcmx5Ln0KCntGb3JnaXZlIG1lIGZvciBiZWluZyBkaWZmaWN1bHQuIERvIHdlIGZlZWwg dGhhdCBTZWN0aW9uIDEwIGlzIGEgc3VmZmljaWVudApkZXNjcmlwdGlvbiBvZiBhcHBseWluZyBz ZWN1cml0eSB0byBDb0FQIG1lc3NhZ2VzIHRvIGFsbG93IHRoZSAKZGV2ZWxvcG1lbnQgb2YgaW50 ZXJvcGVyYWJsZSBpbXBsZW1lbnRhdGlvbnM/IFNlY3Rpb24gMTAgcmVhZHMgdG8gbWUKYXMgYSBn b29kIHN1bW1hcnkgb2YgYW4gYXBwcm9hY2ggdG8gaW1wbGVtZW50aW5nIHNlY3VyaXR5LCBidXQg bG9va3MKbGlrZSBpdCBpcyB3YWl0aW5nIGZvciBzb21lIG9mIHRoZSAic2hvdWxkcyIgdG8gYmUg ZmlybWVkIHVwLiAKQWxzbyB3aGF0IGFib3V0IEVDQyBhbmQgY2VydGlmaWNhdGUgZm9ybWF0cz99 CgogICBUaGlzIHNlY3Rpb24gZGVzY3JpYmVzIG1lY2hhbmlzbXMgdGhhdCBjYW4gYmUgdXNlZCB0 byBzZWN1cmUgQ29BUCBhbmQKICAgYW5hbHl6ZXMgdGhlIHBvc3NpYmxlIHRocmVhdHMgdG8gdGhl IHByb3RvY29sIGFuZCBpdHMgbGltaXRhdGlvbnMuCiAgIFNlY3VyaXR5IGJvb3RzdHJhcHBpbmcg KGF1dGhlbnRpY2F0aW5nIG5vZGVzIGFuZCBzZXR0aW5nIHVwIGtleXMpIGluCiAgIGNvbnN0cmFp bmVkIGVudmlyb25tZW50cyBpcyBjb25zaWRlcmVkIGluCiAgIFtJLUQub2ZseW5uLWNvcmUtYm9v dHN0cmFwcGluZ10uCgogICBEdXJpbmcgdGhlIGJvb3RzdHJhcCBhbmQgZW5yb2xsbWVudCBwaGFz ZXMsIGEgQ29BUCBkZXZpY2UgaXMgcHJvdmlkZWQKICAgd2l0aCB0aGUgc2VjdXJpdHkgaW5mb3Jt YXRpb24gdGhhdCBpdCBuZWVkcywgaW5jbHVkaW5nIGtleWluZwogICBtYXRlcmlhbHMuICBIb3cg dGhpcyBpcyBkb25lIGlzIG91dCBvZiBzY29wZSBmb3IgdGhpcyBzcGVjaWZpY2F0aW9uCiAgIGJ1 dCBhIGNvdXBsZSBvZiB3YXlzIG9mIGRvaW5nIHRoaXMgYXJlIGRlc2NyaWJlZCBpbgogICBbSS1E Lm9mbHlubi1jb3JlLWJvb3RzdHJhcHBpbmddLiAgQXQgdGhlIGVuZCBvZiB0aGUgZW5yb2xsbWVu dCBhbmQKICAgYm9vdHN0cmFwLCB0aGUgZGV2aWNlIHdpbGwgYmUgaW4gb25lIG9mIGZvdXIgc2Vj dXJpdHkgbW9kZXMgd2l0aCB0aGUKICAgZm9sbG93aW5nIGluZm9ybWF0aW9uIGZvciB0aGUgZ2l2 ZW4gbW9kZToKCiAgIE5vU2VjOiAgVGhlcmUgaXMgbm8gcHJvdG9jb2wgbGV2ZWwgc2VjdXJpdHku CgogICBTaGFyZWRLZXk6ICBUaGVyZSBpcyBvbmUgc2hhcmVkIGtleSBiZXR3ZWVuIGFsbCB0aGUg bm9kZXMgdGhhdCB0aGlzCiAgICAgIENvQVAgbm9kZSBuZWVkcyB0byBjb21tdW5pY2F0ZSB3aXRo LgoKICAgTXVsdGlLZXk6ICBUaGVyZSBpcyBhIGxpc3Qgb2Ygc2hhcmVkIGtleXMgYW5kIGVhY2gg a2V5IGluY2x1ZGVzIGEKICAgICAgbGlzdCBvZiB3aGljaCBub2RlcyBpdCBjYW4gYmUgdXNlZCB0 byBjb21tdW5pY2F0ZSB3aXRoLiAgQXQgdGhlCiAgICAgIGV4dHJlbWUgdGhlcmUgbWF5IGJlIG9u ZSBrZXkgZm9yIGVhY2ggbm9kZSB0aGlzIENvQVAgbm9kZSBuZWVkcyB0bwogICAgICBjb21tdW5p Y2F0ZSB3aXRoLgoKICAgQ2VydGlmaWNhdGU6ICBUaGUgZGV2aWNlIGhhcyBhbiBhc3ltbWV0cmlj IGtleSBwYWlyIHdpdGggYSBYLjUwOQogICAgICBbUkZDNTI4MF0gY2VydGlmaWNhdGUgdGhhdCBi aW5kcyBpdCB0byBpdHMgQXV0aG9yaXR5IE5hbWUgYW5kIGlzCiAgICAgIHNpZ25lZCBieSBhIHNv bWUgY29tbW9uIHRydXN0IHJvb3QuICBUaGUgZGV2aWNlIGFsc28gaGFzIGEgbGlzdCBvZgogICAg ICByb290IHRydXN0IGFuY2hvcnMgdGhhdCBjYW4gYmUgdXNlZCBmb3IgdmFsaWRhdGluZyBhIGNl cnRpZmljYXRlLgogICAgICBUaGVyZSBtYXkgYmUgYW4gb3B0aW9uYWwgc2hhcmVkIGtleSB0aGF0 IGFsbCB0aGUgbm9kZXMgdGhhdAogICAgICBjb21tdW5pY2F0ZSBoYXZlIGFjY2VzcyB0by4KCiAg IFRoZSBBdXRob3JpdHkgTmFtZSBpbiB0aGUgY2VydGlmaWNhdGUgaXMgdGhlIG5hbWUgdGhhdCB3 b3VsZCBiZSB1c2VkCiAgIGluIHRoZSBBdXRob3JpdHkgcGFydCBvZiBhIENvQVAgVVJJLiAgSXQg aXMgd29ydGggbm90aW5nIHRoYXQgdGhpcwogICB3b3VsZCB0eXBpY2FsbHkgbm90IGJlIGVpdGhl ciBhbiBJUCBhZGRyZXNzIG9yIEROUyBuYW1lIGJ1dCB3b3VsZAogICBpbnN0ZWFkIGJlIGEgbG9u ZyB0ZXJtIHVuaXF1ZSBpZGVudGlmaWVyIGZvciB0aGUgZGV2aWNlIHN1Y2ggYXMgdGhlCiAgIEVV SS02NCBbRVVJNjRdLiAgVGhlIGRpc2NvdmVyeSBwcm9jZXNzIHVzZWQgaW4gdGhlIHN5c3RlbSB3 b3VsZCBidWlsZAoKCgpTaGVsYnksIGV0IGFsLiAgICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDE1 LCAyMDExICAgICAgICAgICAgICBbUGFnZSA0OV0KDApJbnRlcm5ldC1EcmFmdCAgIENvbnN0cmFp bmVkIEFwcGxpY2F0aW9uIFByb3RvY29sIChDb0FQKSAgICAgIE1hcmNoIDIwMTEKCgogICB1cCB0 aGUgbWFwcGluZyBiZXR3ZWVuIElQIGFkZHJlc3NlcyBvZiB0aGUgZ2l2ZW4gZGV2aWNlcyBhbmQg dGhlCiAgIEF1dGhvcml0eSBOYW1lIGZvciBlYWNoIGRldmljZS4gIFNvbWUgZGV2aWNlcyBjb3Vs ZCBoYXZlIG1vcmUgdGhhbgogICBvbmUgQXV0aG9yaXR5IGFuZCB3b3VsZCBuZWVkIG1vcmUgdGhh biBhIHNpbmdsZSBjZXJ0aWZpY2F0ZS4KICAgCiAgIHtBbSBJIHJpZ2h0IGluIHN1Z2dlc3Rpbmcg dGhhdCB0aGUgY2VydGlmaWNhdGUgZGljb3ZlcnkgcHJvY2VzcwogICBkZXNjcmliZWQgaGVyZSB3 aWxsIGhhdmUgdG8gYmUgZG9jdW1lbnRlZD8gZS5nLiB3aGF0IGlzIHRoZSBmb3JtCiAgIG9mIGEg Q29SRSBMaW5rIEZvcm1hdCBsaW5rKHMpIHRoYXQgZGVhbHMgd2l0aCBjZXJ0aWZpY2F0ZXM/fQoK ICAgSW4gdGhlICJOb1NlYyIgbW9kZSwgdGhlIHN5c3RlbSBzaW1wbHkgc2VuZHMgdGhlIHBhY2tl dHMgb3ZlciBub3JtYWwKICAgVURQIG92ZXIgSVAuICBUaGUgc3lzdGVtIGlzIHNlY3VyZWQgb25s eSBieSBrZWVwaW5nIGF0dGFja2VycyBmcm9tCiAgIGJlaW5nIGFibGUgdG8gc2VuZCBvciByZWNl aXZlIHBhY2tldHMgZnJvbSB0aGUgbmV0d29yayB3aXRoIHRoZSBDb0FQCiAgIG5vZGVzOyBzZWUg U2VjdGlvbiAxMC4zLjQgZm9yIGFuIGFkZGl0aW9uYWwgY29tcGxpY2F0aW9uIHdpdGggdGhpcwog ICBhcHByb2FjaC4gIAogICAKICAgVGhlIG90aGVyIHRocmVlIHNlY3VyaXR5IG1vZGVzIGNhbiBi ZSBhY2hpZXZlZCB3aXRoIElQc2VjCiAgIG9yIERUTFMuICBUaGUgcmVzdWx0IGlzIGEgc2VjdXJp dHkgYXNzb2NpYXRpb24gdGhhdCBjYW4gYmUgdXNlZCB0bwogICBhdXRoZW50aWNhdGUgKHdpdGhp biB0aGUgbGltaXRzIG9mIHRoZSBzZWN1cml0eSBtb2RlbCkgYW5kLCBiYXNlZCBvbgogICB0aGlz IGF1dGhlbnRpY2F0aW9uLCBhdXRob3JpemUgdGhlIGNvbW11bmljYXRpb24gcGFydG5lci4gIENv QVAKICAgaXRzZWxmIGRvZXMgbm90IHByb3ZpZGUgcHJvdG9jb2wgcHJpbWl0aXZlcyBmb3IgYXV0 aGVudGljYXRpb24gb3IKICAgYXV0aG9yaXphdGlvbjsgd2hlcmUgdGhpcyBpcyByZXF1aXJlZCwg aXQgY2FuIGVpdGhlciBiZSBwcm92aWRlZCBieQogICBjb21tdW5pY2F0aW9uIHNlY3VyaXR5IChp LmUuLCBJUHNlYyBvciBEVExTKSBvciBieSBvYmplY3Qgc2VjdXJpdHkKICAgKHdpdGhpbiB0aGUg cGF5bG9hZCkuICAKICAgCiAgIERldmljZXMgdGhhdCByZXF1aXJlIGF1dGhvcml6YXRpb24gZm9y IGNlcnRhaW4KICAgb3BlcmF0aW9ucyBhcmUgZXhwZWN0ZWQgdG8gcmVxdWlyZSBvbmUgb2YgdGhl c2UgdHdvIGZvcm1zIG9mCiAgIHNlY3VyaXR5LiAgTmVjZXNzYXJpbHksIHdoZXJlIGFuIGludGVy bWVkaWFyeSBpcyBpbnZvbHZlZCwKICAgY29tbXVuaWNhdGlvbiBzZWN1cml0eSBvbmx5IHdvcmtz IHdoZW4gdGhhdCBpbnRlcm1lZGlhcnkgaXMgcGFydCBvZgogICB0aGUgdHJ1c3QgcmVsYXRpb25z aGlwczsgQ29BUCBkb2VzIG5vdCBwcm92aWRlIGEgd2F5IHRvIGZvcndhcmQKICAgZGlmZmVyZW50 IGxldmVscyBvZiBhdXRob3JpemF0aW9uIHRoYXQgY2xpZW50cyBtYXkgaGF2ZSB3aXRoIGFuCiAg IGludGVybWVkaWFyeSB0byBmdXJ0aGVyIGludGVybWVkaWFyaWVzIG9yIG9yaWdpbiBzZXJ2ZXJz LiBJdAogICB0aGVyZWZvcmUgbWF5IGJlIHJlcXVpcmVkIHRvIHBlcmZvcm0gYWxsIGF1dGhvcml6 YXRpb24gYXQgdGhlIGZpcnN0CiAgIGludGVybWVkaWFyeS4ge2RvZXMgdGhpcyBtZWFuICJUaGVy ZWZvcmUgaXQgbWF5IGJlIG5lY2Vzc2FyeSB0byBwZXJmb3JtIAogICBhbGwgYXV0aG9yaXphdGlv biBhdCB0aGUgZmlyc3QgaW50ZXJtZWRpYXJ5LiIgb3Igc29tZXRoaW5nIGVsc2U/CiAgIEFsc28g LSB3aGF0IGlzIGEgImZpcnN0IGludGVybWVkaWFyeSI/fQoKMTAuMS4gIFNlY3VyaW5nIENvQVAg d2l0aCBJUHNlYwoKICAgT25lIG1lY2hhbmlzbSB0byBzZWN1cmUgQ29BUCBpbiBjb25zdHJhaW5l ZCBlbnZpcm9ubWVudHMgaXMgdGhlIElQc2VjCiAgIEVuY2Fwc3VsYXRpbmcgU2VjdXJpdHkgUGF5 bG9hZCAoRVNQKSBbUkZDNDMwM10uICBVc2luZyBJUHNlYyBFU1Agd2l0aAogICB0aGUgYXBwcm9w cmlhdGUgY29uZmlndXJhdGlvbiwgaXQgaXMgcG9zc2libGUgZm9yIG1hbnkgY29uc3RyYWluZWQK ICAgZGV2aWNlcyB0byBzdXBwb3J0IGVuY3J5cHRpb24gd2l0aCBidWlsdC1pbiBsaW5rLWxheWVy IGVuY3J5cHRpb24KICAgaGFyZHdhcmUuICAKICAgCiAgIEZvciBleGFtcGxlLCBzb21lIElFRUUg ODAyLjE1LjQgcmFkaW8gY2hpcHMgYXJlIGNvbXBhdGlibGUKICAgd2l0aCBBRVMtQ0JDICh3aXRo IDEyOC1iaXQga2V5cykgW1JGQzM2MDJdIGFzIGRlZmluZWQgZm9yIHVzZSB3aXRoCiAgIElQc2Vj IGluIFtSRkM0ODM1XS4gIEFsdGVybmF0aXZlbHksIHBhcnRpY3VsYXJseSBvbiBtb3JlIGNvbW1v biBJRUVFCiAgIDgwMi4xNS40IGhhcmR3YXJlIHRoYXQgc3VwcG9ydHMgQUVTIGVuY3J5cHRpb24g YnV0IG5vdCBkZWNyeXB0aW9uLAogICBhbmQgdG8gYXZvaWQgdGhlIG5lZWQgZm9yIHBhZGRpbmcs IG5vZGVzIGNvdWxkIGRpcmVjdGx5IHVzZSB0aGUgbW9yZQogICB3aWRlbHkgc3VwcG9ydGVkIEFF Uy1DQ00gYXMgZGVmaW5lZCBmb3IgdXNlIHdpdGggSVBzZWMgaW4gW1JGQzQzMDldLAogICBpZiB0 aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgaW4gc2VjdGlvbiA5IG9mIHRoYXQgc3BlY2lmaWNh dGlvbiBjYW4KICAgYmUgZnVsZmlsbGVkLiAgCiAgIAogICBOZWNlc3NhcmlseSBmb3IgQUVTLUND TSwgYnV0IG11Y2ggcHJlZmVyYWJseSBhbHNvIGZvcgogICBBRVMtQ0JDLCBzdGF0aWMga2V5aW5n IHNob3VsZCBiZSBhdm9pZGVkIGFuZCB0aGUgaW5pdGlhbCBrZXlpbmcKICAgbWF0ZXJpYWwgYmUg ZGVyaXZlZCBpbnRvIHRyYW5zaWVudCBzZXNzaW9uIGtleXMgCiAgIHtkb2VzIHRoaXMgbWVhbiAi dHJhbnNpZW50IHNlc3Npb24ga2V5cyBTSE9VTEQgYmUgZGVyaXZlZCBmcm9tIGluaXRpYWwKICAg a2V5aW5nIG1hdGVyaWFsIj99LCBlLmcuIHVzaW5nIGEgbG93LQogICBvdmVyaGVhZCBtb2RlIG9m IElLRXYyIFtSRkM1OTk2XTsgc3VjaCBhIHByb3RvY29sIGZvciBtYW5hZ2luZyBrZXlzCiAgIGFu ZCBzZXF1ZW5jZSBudW1iZXJzIGlzIGFsc28gdGhlIG9ubHkgd2F5IHRvIGFjaGlldmUgYW50aS1y ZXBsYXkKICAgY2FwYWJpbGl0aWVzLiAgCiAgIAogICBIb3dldmVyLCBubyByZWNvbW1lbmRhdGlv biBjYW4gYmUgbWFkZSBhdCB0aGlzIHBvaW50CiAgIG9uIGhvdyB0byBtYW5hZ2UgZ3JvdXAga2V5 cyAoaS5lLiwgZm9yIG11bHRpY2FzdCkgaW4gYSBjb25zdHJhaW5lZAogICBlbnZpcm9ubWVudC4g IAogICAKICAgT25jZSBhbnkgaW5pdGlhbCBzZXR1cCBpcyBjb21wbGV0ZWQsIElQc2VjIEVTUCBh ZGRzIGFuIAogICBvdmVyaGVhZCBvZiBhcHByb3hpbWF0ZWx5IDEwIGJ5dGVzIHBlciBwYWNrZXQs IG5vdCBpbmNsdWRpbmcKICAgaW5pdGlhbGl6YXRpb24gdmVjdG9ycywgaW50ZWdyaXR5IGNoZWNr IHZhbHVlcyBhbmQgcGFkZGluZyByZXF1aXJlZAoKCgpTaGVsYnksIGV0IGFsLiAgICAgICAgIEV4 cGlyZXMgU2VwdGVtYmVyIDE1LCAyMDExICAgICAgICAgICAgICBbUGFnZSA1MF0KDApJbnRlcm5l dC1EcmFmdCAgIENvbnN0cmFpbmVkIEFwcGxpY2F0aW9uIFByb3RvY29sIChDb0FQKSAgICAgIE1h cmNoIDIwMTEKCgogICBieSB0aGUgY2lwaGVyIHN1aXRlLgoKICAgV2hlbiB1c2luZyBJUHNlYyB0 byBzZWN1cmUgQ29BUCwgYm90aCBhdXRoZW50aWNhdGlvbiBhbmQKICAgY29uZmlkZW50aWFsaXR5 IFNIT1VMRCBiZSBhcHBsaWVkIGFzIHJlY29tbWVuZGVkIGluIFtSRkM0MzAzXS4gIFRoZQogICB1 c2Ugb2YgSVBzZWMgYmV0d2VlbiBDb0FQIGVuZC1wb2ludHMgaXMgdHJhbnNwYXJlbnQgdG8gdGhl CiAgIGFwcGxpY2F0aW9uIGxheWVyIGFuZCBkb2VzIG5vdCByZXF1aXJlIHNwZWNpYWwgY29uc2lk ZXJhdGlvbiBmb3IgYQogICBDb0FQIGltcGxlbWVudGF0aW9uLgoKICAgSVBzZWMgbWF5IG5vdCBi ZSBhcHByb3ByaWF0ZSBmb3IgYWxsIGVudmlyb25tZW50cy4gIEZvciBleGFtcGxlLAogICBJUHNl YyBzdXBwb3J0IGlzIG5vdCBhdmFpbGFibGUgZm9yIG1hbnkgZW1iZWRkZWQgSVAgc3RhY2tzIGFu ZCBldmVuCiAgIGluIGZ1bGwgUEMgb3BlcmF0aW5nIHN5c3RlbXMgb3Igb24gYmFjay1lbmQgd2Vi IHNlcnZlcnMsIGFwcGxpY2F0aW9uCiAgIGRldmVsb3BlcnMgbWF5IG5vdCBoYXZlIHN1ZmZpY2ll bnQgYWNjZXNzIHRvIGNvbmZpZ3VyZSBvciBlbmFibGUKICAgSVBzZWMgb3IgdG8gYWRkIGEgc2Vj dXJpdHkgZ2F0ZXdheSB0byB0aGUgaW5mcmFzdHJ1Y3R1cmUuICBQcm9ibGVtcwogICB3aXRoIGZp cmV3YWxscyBhbmQgTkFUcyBtYXkgZnVydGhlcm1vcmUgbGltaXQgdGhlIHVzZSBvZiBJUHNlYy4K CjEwLjIuICBTZWN1cmluZyBDb0FQIHdpdGggRFRMUwoKICAgSnVzdCBhcyBIVFRQIG1heSBiZSBz ZWN1cmVkIHVzaW5nIFRyYW5zcG9ydCBMYXllciBTZWN1cml0eSAoVExTKSBvdmVyCiAgIFRDUCwg Q29BUCBtYXkgYmUgc2VjdXJlZCB1c2luZyBEYXRhZ3JhbSBUTFMgKERUTFMpIFtSRkM0MzQ3XSBv dmVyCiAgIFVEUC4gIFRoaXMgc2VjdGlvbiBnaXZlcyBhIHF1aWNrIG92ZXJ2aWV3IG9mIGhvdyB0 byBzZWN1cmUgQ29BUCB3aXRoCiAgIERUTFMsIGFsb25nIHdpdGggdGhlIG1pbmltYWwgY29uZmln dXJhdGlvbnMgYXBwcm9wcmlhdGUgZm9yCiAgIGNvbnN0cmFpbmVkIGVudmlyb25tZW50cy4gIERU TFMgaXMgaW4gcHJhY3RpY2UgVExTIHdpdGggYWRkZWQKICAgZmVhdHVyZXMgdG8gZGVhbCB3aXRo IHRoZSB1bnJlbGlhYmxlIG5hdHVyZSBvZiB0aGUgVURQIHRyYW5zcG9ydC4KCiAgIEluIHNvbWUg Y29uc3RyYWluZWQgbm9kZXMgKGxpbWl0ZWQgZmxhc2ggYW5kL29yIFJBTSkgYW5kIG5ldHdvcmtz CiAgIChsaW1pdGVkIGJhbmR3aWR0aCBvciBoaWdoIHNjYWxhYmlsaXR5IHJlcXVpcmVtZW50cyks IGFuZCBkZXBlbmRpbmcKICAgb24gdGhlIHNwZWNpZmljIGNpcGhlciBzdWl0ZXMgaW4gdXNlLCBE VExTIG1heSBub3QgYmUgYXBwbGljYWJsZS4KICAgU29tZSBvZiBEVExTJyBjaXBoZXIgc3VpdGVz IGNhbiBhZGQgc2lnbmlmaWNhbnQgaW1wbGVtZW50YXRpb24KICAgY29tcGxleGl0eSBhcyB3ZWxs IGFzIHNvbWUgaW5pdGlhbCBoYW5kc2hha2Ugb3ZlcmhlYWQgbmVlZGVkIHdoZW4KICAgc2V0dGlu ZyB1cCB0aGUgc2VjdXJpdHkgYXNzb2NpYXRpb24uICBPbmNlIHRoZSBpbml0aWFsIGhhbmRzaGFr ZSBpcwogICBjb21wbGV0ZWQsIERUTFMgYWRkcyBhIGxpbWl0ZWQgcGVyLWRhdGFncmFtIG92ZXJo ZWFkIG9mIGFwcHJveGltYXRlbHkKICAgMTMgYnl0ZXMsIG5vdCBpbmNsdWRpbmcgYW55IGluaXRp YWxpemF0aW9uIHZlY3RvcnMgKHdoaWNoIGFyZQogICBnZW5lcmFsbHkgaW1wbGljaXRseSBkZXJp dmVkIHdpdGggRFRMUyksIGludGVncml0eSBjaGVjayB2YWx1ZXMKICAgKGUuZy4sIDggYnl0ZXMg d2l0aCB0aGUgcHJvcG9zZWQgVExTX1BTS19XSVRIX0FFU18xMjhfQ0NNXzgKICAgW0ktRC5tY2dy ZXctdGxzLWFlcy1jY21dKSBhbmQgcGFkZGluZyByZXF1aXJlZCBieSB0aGUgY2lwaGVyIHN1aXRl LgogICAKICAgV2hldGhlciBEVExTIGlzIGFwcGxpY2FibGUgZm9yIGEgQ29BUC1iYXNlZCBhcHBs aWNhdGlvbiwgYW5kIHdoaWNoIAogICBtb2RlIGlzIGFwcGxpY2FibGUsIHNob3VsZCBiZSBjYXJl ZnVsbHkgd2VpZ2hlZCBjb25zaWRlcmluZyB0aGUgc3BlY2lmaWMKICAgY2lwaGVyIHN1aXRlcyB0 aGF0IG1heSBiZSBhcHBsaWNhYmxlLCBhbmQgd2hldGhlciB0aGUgc2Vzc2lvbgogICBtYWludGVu YW5jZSBtYWtlcyBpdCBjb21wYXRpYmxlIHdpdGggYXBwbGljYXRpb24gZmxvd3MgYW5kIHN1ZmZp Y2llbnQKICAgcmVzb3VyY2VzIGFyZSBhdmFpbGFibGUgb24gdGhlIGNvbnN0cmFpbmVkIG5vZGVz IGFuZCBmb3IgdGhlIGFkZGVkCiAgIG5ldHdvcmsgb3ZlcmhlYWQuICBEVExTIGlzIG5vdCBhcHBs aWNhYmxlIHRvIGdyb3VwIGtleWluZyAobXVsdGljYXN0CiAgIGNvbW11bmljYXRpb24pLiBIb3dl dmVyLCBpdCBtYXkgYmUgYSBjb21wb25lbnQgaW4gYSBmdXR1cmUgZ3JvdXAga2V5CiAgIG1hbmFn ZW1lbnQgcHJvdG9jb2wuCgogICBEZXZpY2VzIFNIT1VMRCBzdXBwb3J0IHRoZSBTZXJ2ZXIgTmFt ZSBJbmRpY2F0aW9uIChTTkkpIHRvIGluZGljYXRlCiAgIHRoZWlyIEF1dGhvcml0eSBOYW1lIGlu IHRoZSBTTkkgSG9zdE5hbWUgZmllbGQgYXMgZGVmaW5lZCBpbiBTZWN0aW9uCiAgIDMgb2YgW1JG QzYwNjZdLiAgVGhpcyBpcyBuZWVkZWQgc28gdGhhdCB3aGVuIGEgaG9zdCB0aGF0IGFjdHMgYXMg YQogICB2aXJ0dWFsIHNlcnZlciBmb3IgbXVsdGlwbGUgQXV0aG9yaXRpZXMgcmVjZWl2ZXMgYSBu ZXcgRFRMUwoKCgpTaGVsYnksIGV0IGFsLiAgICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDE1LCAy MDExICAgICAgICAgICAgICBbUGFnZSA1MV0KDApJbnRlcm5ldC1EcmFmdCAgIENvbnN0cmFpbmVk IEFwcGxpY2F0aW9uIFByb3RvY29sIChDb0FQKSAgICAgIE1hcmNoIDIwMTEKCgogICBjb25uZWN0 aW9uLCBpdCBrbm93cyB3aGljaCBrZXlzIHRvIHVzZSBmb3IgdGhlIERUTFMgc2Vzc2lvbi4KCiAg IERUTFMgY29ubmVjdGlvbnMgd2l0aCBjZXJ0aWZpY2F0ZXMgYXJlIHNldCB1cCB1c2luZyBtdXR1 YWwKICAgYXV0aGVudGljYXRpb24gc28gdGhleSBjYW4gcmVtYWluIHVwIGFuZCBiZSByZXVzZWQg Zm9yIGZ1dHVyZSBtZXNzYWdlCiAgIGV4Y2hhbmdlcyBpbiBlaXRoZXIgZGlyZWN0aW9uLiAgRGV2 aWNlcyBjYW4gY2xvc2UgYSBEVExTIGNvbm5lY3Rpb24KICAgd2hlbiB0aGV5IG5lZWQgdG8gcmVj b3ZlciByZXNvdXJjZXMgYnV0IGluIGdlbmVyYWwgdGhleSBzaG91bGQga2VlcAogICB0aGUgY29u bmVjdGlvbiB1cCBmb3IgYXMgbG9uZyBhcyBwb3NzaWJsZS4gIENsb3NpbmcgdGhlIERUTFMKICAg Y29ubmVjdGlvbiBhZnRlciBldmVyeSBDb0FQIG1lc3NhZ2UgZXhjaGFuZ2UgaXMgdmVyeSBpbmVm ZmljaWVudC4KCjEwLjIuMS4gIFNoYXJlZEtleSBhbmQgTXVsdGlLZXkgTW9kZXMKCiAgIFdoZW4g Zm9ybWluZyBhIGNvbm5lY3Rpb24gdG8gYSBuZXcgbm9kZSwgdGhlIHN5c3RlbSBzZWxlY3RzIGFu CiAgIGFwcHJvcHJpYXRlIGtleSBiYXNlZCBvbiB3aGljaCBub2RlcyBpdCBpcyB0cnlpbmcgdG8g cmVhY2ggdGhlbiBmb3JtcwogICBhIERUTFMgc2Vzc2lvbiB1c2luZyBhIFBTSyAoUHJlLVNoYXJl ZCBLZXkpIG1vZGUgb2YgRFRMUy4KICAgSW1wbGVtZW50YXRpb25zIFNIT1VMRCBzdXBwb3J0IHRo ZSBtYW5kYXRvcnkgdG8gaW1wbGVtZW50IGNpcGhlcgogICBzdWl0ZSBUTFNfUFNLX1dJVEhfQUVT XzEyOF9DQkNfU0hBIGFzIHNwZWNpZmllZCBpbiBbUkZDNDI3OV0uIE9uY2UKICAgVExTX1BTS19X SVRIX0FFU18xMjhfQ0NNXzggYXMgc3BlY2lmaWVkIGluIFtJLUQubWNncmV3LXRscy1hZXMtY2Nt XQogICAob3IgcmVsYXRlZCBjaXBoZXIgc3VpdGVzIHNwZWNpZmllZCBpbiBbSS1ELm1jZ3Jldy10 bHMtYWVzLWNjbS1lY2NdKQogICBpbiBjb25qdW5jdGlvbiB3aXRoIFtJLUQuaWV0Zi10bHMtcmZj NDM0Ny1iaXNdIGJlY29tZXMgYXZhaWxhYmxlLAogICB0aGlzIG1heSBiZSBlYXNpZXIgdG8gaW1w bGVtZW50IG9uIGNlcnRhaW4gY29udGVtcG9yYXJ5IGNoaXBzZXRzLgoKICAgVGhlIHNlY3VyaXR5 IGNvbnNpZGVyYXRpb25zIG9mIFtSRkM0Mjc5XSAoU2VjdGlvbiA3KSBhcHBseS4gIEluCiAgIHBh cnRpY3VsYXIsIGFwcGxpY2F0aW9ucyBzaG91bGQgY2FyZWZ1bGx5IHdlaWdoIHdoZXRoZXIgdGhl eSBuZWVkCiAgIFBlcmZlY3QgRm9yd2FyZCBTZWNyZWN5IChQRlMpIG9yIG5vdCBhbmQgc2VsZWN0 IGFuIGFwcHJvcHJpYXRlIGNpcGhlcgogICBzdWl0ZSAoNy4xKS4gIFRoZSBlbnRyb3B5IG9mIHRo ZSBQU0sgbXVzdCBiZSBzdWZmaWNpZW50IHRvIG1pdGlnYXRlCiAgIGFnYWluc3QgYnJ1dGUtZm9y Y2UgYW5kICh3aGVyZSB0aGUgUFNLIGlzIG5vdCBjaG9zZW4gcmFuZG9tbHkgYnV0IGJ5CiAgIGEg aHVtYW4pIGRpY3Rpb25hcnkgYXR0YWNrcyAoNy4yKS4gIFRoZSBjbGVhcnRleHQgY29tbXVuaWNh dGlvbiBvZgogICBjbGllbnQgaWRlbnRpdGllcyBtYXkgbGVhayBkYXRhIG9yIGNvbXByb21pc2Ug cHJpdmFjeSAoNy4zKS4KCjEwLjIuMi4gIENlcnRpZmljYXRlIE1vZGUKCiAgIEFzIHdpdGggSVBz ZWMsIERUTFMgc2hvdWxkIGJlIGNvbmZpZ3VyZWQgd2l0aCBhIGNpcGhlciBzdWl0ZQogICBjb21w YXRpYmxlIHdpdGggYW55IHBvc3NpYmxlIGhhcmR3YXJlIGVuZ2luZSBvbiB0aGUgbm9kZSwgZm9y IGV4YW1wbGUKICAgQUVTLUNCQyBpbiB0aGUgY2FzZSBvZiBJRUVFIDgwMi4xNS40LiAgSW1wbGVt ZW50YXRpb25zIFNIT1VMRCBzdXBwb3J0CiAgIHRoZSBtYW5kYXRvcnkgdG8gaW1wbGVtZW50IGNp cGhlciBzdWl0ZSBUTFNfUlNBX1dJVEhfQUVTXzEyOF9DQkNfU0hBCiAgIGFzIHNwZWNpZmllZCBp biBbUkZDNTI0Nl0uCgogICBXaGVuIGEgbmV3IGNvbm5lY3Rpb24gaXMgZm9ybWVkLCB0aGUgY2Vy dGlmaWNhdGUgZnJvbSB0aGUgcmVtb3RlCiAgIGRldmljZSBuZWVkcyB0byBiZSB2ZXJpZmllZC4g IElmIHRoZSBDb0FQIG5vZGUgaGFzIGEgc291cmNlIG9mCiAgIGFic29sdXRlIHRpbWUsIHRoZW4g dGhlIG5vZGUgU0hPVUxEIGNoZWNrIHRoZSB2YWxpZGl0eSBkYXRlcyBhcmUgb2YKICAgdGhlIGNl cnRpZmljYXRlIGFyZSB3aXRoaW4gcmFuZ2UuICBUaGUgY2VydGlmaWNhdGUgTVVTVCBhbHNvIGJl CiAgIHNpZ25lZCBieSBhbiBhcHByb3ByaWF0ZSBjaGFpbiBvZiB0cnVzdC4gIElmIHRoZSBjZXJ0 aWZpY2F0ZSBjb250YWlucwogICBhIFN1YmplY3RBbHROYW1lLCB0aGVuIHRoZSBBdXRob3JpdHkg TmFtZSBNVVNUIG1hdGNoIGF0IGxlYXN0IG9uZSBvZgogICB0aGUgYXV0aG9yaXR5IG5hbWVzIG9m IGFueSBDb0FQIFVSSSBmb3VuZCBpbiBhIFVSSSB0eXBlIGZpZWxkcyBpbiB0aGUKICAgU3ViamVj dEFsdE5hbWUgc2V0LiAgSWYgdGhlcmUgaXMgbm8gU3ViamVjdEFsdE5hbWUgaW4gdGhlCiAgIGNl cnRpZmljYXRlLCB0aGVuIHRoZSBBdXRob3JpdGF0aXZlIE5hbWUgbXVzdCBtYXRjaCB0aGUgQ04g Zm91bmQgaW4KICAgdGhlIGNlcnRpZmljYXRlIHVzaW5nIHRoZSBtYXRjaGluZyBydWxlcyBkZWZp bmVkIGluIFtSRkMyODE4XSB3aXRoCiAgIHRoZSBleGNlcHRpb24gdGhhdCBjZXJ0aWZpY2F0ZXMg d2l0aCB3aWxkY2FyZHMgYXJlIG5vdCBhbGxvd2VkLgoKCgpTaGVsYnksIGV0IGFsLiAgICAgICAg IEV4cGlyZXMgU2VwdGVtYmVyIDE1LCAyMDExICAgICAgICAgICAgICBbUGFnZSA1Ml0KDApJbnRl cm5ldC1EcmFmdCAgIENvbnN0cmFpbmVkIEFwcGxpY2F0aW9uIFByb3RvY29sIChDb0FQKSAgICAg IE1hcmNoIDIwMTEKCgogICBJZiB0aGUgc3lzdGVtIGhhcyBhIHNoYXJlZCBrZXkgaW4gYWRkaXRp b24gdG8gdGhlIGNlcnRpZmljYXRlLCB0aGVuIGEKICAgY2lwaGVyIHN1aXRlIHRoYXQgaW5jbHVk ZXMgdGhlIHNoYXJlZCBrZXkgc3VjaCBhcwogICBUTFNfUlNBX1BTS19XSVRIX0FFU18xMjhfQ0JD X1NIQSBTSE9VTEQgYmUgdXNlZC4KCjEwLjMuICBUaHJlYXQgYW5hbHlzaXMgYW5kIHByb3RvY29s IGxpbWl0YXRpb25zCgogICBUaGlzIHNlY3Rpb24gaXMgbWVhbnQgdG8gaW5mb3JtIHByb3RvY29s IGFuZCBhcHBsaWNhdGlvbiBkZXZlbG9wZXJzCiAgIGFib3V0IHRoZSBzZWN1cml0eSBsaW1pdGF0 aW9ucyBvZiBDb0FQIGFzIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50LgogICBBcyBDb0FQIHJl YWxpemVzIGEgc3Vic2V0IG9mIHRoZSBmZWF0dXJlcyBpbiBIVFRQLzEuMSwgdGhlIHNlY3VyaXR5 CiAgIGNvbnNpZGVyYXRpb25zIGluIFNlY3Rpb24gMTUgb2YgW1JGQzI2MTZdIGFyZSBhbHNvIHBl cnRpbmVudCB0byBDb0FQLgogICBUaGlzIHNlY3Rpb24gY29uY2VudHJhdGVzIG9uIGRlc2NyaWJp bmcgbGltaXRhdGlvbnMgc3BlY2lmaWMgdG8gQ29BUC4KCjEwLjMuMS4gIFByb3RvY29sIFBhcnNp bmcsIFByb2Nlc3NpbmcgVVJJcwoKICAgQSBuZXR3b3JrLWZhY2luZyBhcHBsaWNhdGlvbiBjYW4g ZXhoaWJpdCB2dWxuZXJhYmlsaXRpZXMgaW4gaXRzCiAgIHByb2Nlc3NpbmcgbG9naWMgZm9yIGlu Y29taW5nIHBhY2tldHMuICBDb21wbGV4IHBhcnNlcnMgYXJlIHdlbGwtCiAgIGtub3duIGFzIGEg bGlrZWx5IHNvdXJjZSBvZiBzdWNoIHZ1bG5lcmFiaWxpdGllcywgc3VjaCBhcyB0aGUgYWJpbGl0 eQogICB0byByZW1vdGVseSBjcmFzaCBhIG5vZGUsIG9yIGV2ZW4gcmVtb3RlbHkgZXhlY3V0ZSBh cmJpdHJhcnkgY29kZSBvbgogICBpdC4gIENvQVAgYXR0ZW1wdHMgdG8gbmFycm93IHRoZSBvcHBv cnR1bml0aWVzIGZvciBpbnRyb2R1Y2luZyBzdWNoCiAgIHZ1bG5lcmFiaWxpdGllcyBieSByZWR1 Y2luZyBwYXJzZXIgY29tcGxleGl0eSwgYnkgZ2l2aW5nIHRoZSBlbnRpcmUKICAgcmFuZ2Ugb2Yg ZW5jb2RhYmxlIHZhbHVlcyBhIG1lYW5pbmcgd2hlcmUgcG9zc2libGUsIGFuZCBieQogICBhZ2dy ZXNzaXZlbHkgcmVkdWNpbmcgY29tcGxleGl0eSB0aGF0IGlzIG9mdGVuIGNhdXNlZCBieSB1bm5l Y2Vzc2FyeQogICBjaG9pY2UgYmV0d2VlbiBtdWx0aXBsZSByZXByZXNlbnRhdGlvbnMgdGhhdCBt ZWFuIHRoZSBzYW1lIHRoaW5nLgogICBNdWNoIG9mIHRoZSBVUkkgcHJvY2Vzc2luZyBoYXMgYmVl biBtb3ZlZCB0byB0aGUgY2xpZW50cywgZnVydGhlcgogICByZWR1Y2luZyB0aGUgb3Bwb3J0dW5p dGllcyBmb3IgaW50cm9kdWNpbmcgdnVsbmVyYWJpbGl0aWVzIGludG8gdGhlCiAgIHNlcnZlcnMu ICBFdmVuIHNvLCB0aGUgVVJJIHByb2Nlc3NpbmcgY29kZSBpbiBDb0FQIGltcGxlbWVudGF0aW9u cyBpcwogICBsaWtlbHkgdG8gYmUgYSBsYXJnZSBzb3VyY2Ugb2YgcmVtYWluaW5nIHZ1bG5lcmFi aWxpdGllcyBhbmQgc2hvdWxkCiAgIGJlIGltcGxlbWVudGVkIHdpdGggc3BlY2lhbCBjYXJlLiAg VGhlIG1vc3QgY29tcGxleCBwYXJzZXIgcmVtYWluaW5nCiAgIGNvdWxkIGJlIHRoZSBvbmUgZm9y IHRoZSBsaW5rLWZvcm1hdCwgYWx0aG91Z2ggdGhpcyBhbHNvIGhhcyBiZWVuCiAgIGRlc2lnbmVk IHdpdGggYSBnb2FsIG9mIHJlZHVjZWQgaW1wbGVtZW50YXRpb24gY29tcGxleGl0eQogICBbSS1E LmlldGYtY29yZS1saW5rLWZvcm1hdF0uICAoU2VlIGFsc28gc2VjdGlvbiAxNS4yIG9mIFtSRkMy NjE2XS4pCgoxMC4zLjIuICBQcm94eWluZyBhbmQgQ2FjaGluZwoKICAgQXMgbWVudGlvbmVkIGlu IDE1Ljcgb2YgW1JGQzI2MTZdLCB3aGljaCBzZWUsIHByb3hpZXMgYXJlIGJ5IHRoZWlyCiAgIHZl cnkgbmF0dXJlIG1lbi1pbi10aGUtbWlkZGxlLCBicmVha2luZyBhbnkgSVBzZWMgb3IgRFRMUyBw cm90ZWN0aW9uCiAgIHRoYXQgYSBkaXJlY3QgQ29BUCBtZXNzYWdlIGV4Y2hhbmdlIG1pZ2h0IGhh dmUuICBUaGV5IGFyZSB0aGVyZWZvcmUKICAgaW50ZXJlc3RpbmcgdGFyZ2V0cyBmb3IgYnJlYWtp bmcgY29uZmlkZW50aWFsaXR5IG9yIGludGVncml0eSBvZiBDb0FQCiAgIG1lc3NhZ2UgZXhjaGFu Z2VzLiAgQXMgbm90ZWQgaW4gW1JGQzI2MTZdLCB0aGV5IGFyZSBhbHNvIGludGVyZXN0aW5nCiAg IHRhcmdldHMgZm9yIGJyZWFraW5nIGF2YWlsYWJpbGl0eS4KCiAgIFRoZSB0aHJlYXQgdG8gY29u ZmlkZW50aWFsaXR5IGFuZCBpbnRlZ3JpdHkgb2YgcmVxdWVzdC9yZXNwb25zZSBkYXRhCiAgIGlz IGFtcGxpZmllZCB3aGVyZSBwcm94aWVzIGFsc28gY2FjaGUuICBOb3RlIHRoYXQgQ29BUCBkb2Vz IG5vdAogICBkZWZpbmUgYW55IG9mIHRoZSBjYWNoZS1zdXBwcmVzc2luZyBDYWNoZS1Db250cm9s IG9wdGlvbnMgdGhhdAogICBIVFRQLzEuMSBwcm92aWRlcyB0byBiZXR0ZXIgcHJvdGVjdCBzZW5z aXRpdmUgZGF0YS4KCiAgIEZpbmFsbHksIGEgcHJveHkgdGhhdCBmYW5zIG91dCBTZXBhcmF0ZSBS ZXNwb25zZXMgKGFzIG9wcG9zZWQgdG8KICAgUGlnZ3ktYmFja2VkIFJlc3BvbnNlcykgdG8gbXVs dGlwbGUgb3JpZ2luYWwgcmVxdWVzdGVycyBtYXkgcHJvdmlkZQoKCgpTaGVsYnksIGV0IGFsLiAg ICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDE1LCAyMDExICAgICAgICAgICAgICBbUGFnZSA1M10K DApJbnRlcm5ldC1EcmFmdCAgIENvbnN0cmFpbmVkIEFwcGxpY2F0aW9uIFByb3RvY29sIChDb0FQ KSAgICAgIE1hcmNoIDIwMTEKCgogICBhZGRpdGlvbmFsIGFtcGxpZmljYXRpb24gKHNlZSBiZWxv dykuCgoxMC4zLjMuICBSaXNrIG9mIGFtcGxpZmljYXRpb24KCiAgIENvQVAgc2VydmVycyBnZW5l cmFsbHkgcmVwbHkgdG8gYSByZXF1ZXN0IHBhY2tldCB3aXRoIGEgcmVzcG9uc2UKICAgcGFja2V0 LiAgVGhpcyByZXNwb25zZSBwYWNrZXQgbWF5IGJlIHNpZ25pZmljYW50bHkgbGFyZ2VyIHRoYW4g dGhlCiAgIHJlcXVlc3QgcGFja2V0LiAgQW4gYXR0YWNrZXIgbWlnaHQgdXNlIENvQVAgbm9kZXMg dG8gdHVybiBhIHNtYWxsCiAgIGF0dGFjayBwYWNrZXQgaW50byBhIGxhcmdlciBhdHRhY2sgcGFj a2V0LCBhbiBhcHByb2FjaCBrbm93biBhcwogICBhbXBsaWZpY2F0aW9uLiAgVGhlcmUgaXMgdGhl cmVmb3JlIGEgZGFuZ2VyIHRoYXQgQ29BUCBub2RlcyBjb3VsZAogICBiZWNvbWUgaW1wbGljYXRl ZCBpbiBkZW5pYWwgb2Ygc2VydmljZSAoRG9TKSBhdHRhY2tzIGJ5IHVzaW5nIHRoZQogICBhbXBs aWZ5aW5nIHByb3BlcnRpZXMgb2YgdGhlIHByb3RvY29sLiBBbiBhdHRhY2tlciB0aGF0IGlzIGF0 dGVtcHRpbmcKICAgdG8gb3ZlcmxvYWQgYSB2aWN0aW0gYnV0IGlzIGxpbWl0ZWQgaW4gdGhlIGFt b3VudCBvZiB0cmFmZmljIGl0IGNhbgogICBnZW5lcmF0ZSBjYW4gdXNlIGFtcGxpZmljYXRpb24g dG8gZ2VuZXJhdGUgYSBsYXJnZXIgYW1vdW50IG9mCiAgIHRyYWZmaWMuCgogICBUaGlzIGlzIHBh cnRpY3VsYXJseSBhIHByb2JsZW0gaW4gbm9kZXMgdGhhdCBlbmFibGUgTm9TZWMgYWNjZXNzLAog ICB0aGF0IGFyZSBhY2Nlc3NpYmxlIGZyb20gYW4gYXR0YWNrZXIgYW5kIGNhbiBhY2Nlc3MgcG90 ZW50aWFsIHZpY3RpbXMKICAgKGUuZy4gb24gdGhlIGdlbmVyYWwgSW50ZXJuZXQpLCBhcyB0aGUg VURQIHByb3RvY29sIHByb3ZpZGVzIG5vIHdheQogICB0byB2ZXJpZnkgdGhlIHNvdXJjZSBhZGRy ZXNzIGdpdmVuIGluIHRoZSByZXF1ZXN0IHBhY2tldC4gIEFuCiAgIGF0dGFja2VyIG5lZWQgb25s eSBwbGFjZSB0aGUgSVAgYWRkcmVzcyBvZiB0aGUgdmljdGltIGluIHRoZSBzb3VyY2UKICAgYWRk cmVzcyBvZiBhIHN1aXRhYmxlIHJlcXVlc3QgcGFja2V0IHRvIGdlbmVyYXRlIGEgbGFyZ2VyIHBh Y2tldAogICBkaXJlY3RlZCBhdCB0aGUgdmljdGltLgoKICAgQXMgYSBtaXRpZ2F0aW5nIGZhY3Rv ciwgbWFueSBjb25zdHJhaW5lZCBuZXR3b3JrcyB3aWxsIG9ubHkgYmUgYWJsZSB0bwogICBnZW5l cmF0ZSBhIHNtYWxsIGFtb3VudCBvZiB0cmFmZmljLCB3aGljaCBtYXkgbWFrZSBDb0FQIG5vZGVz IGxlc3MKICAgYXR0cmFjdGl2ZSBmb3IgdGhpcyBhdHRhY2suICBIb3dldmVyLCB0aGUgbGltaXRl ZCBjYXBhY2l0eSBvZiB0aGUKICAgY29uc3RyYWluZWQgbmV0d29yayBtYWtlcyB0aGUgbmV0d29y ayBpdHNlbGYgYSBsaWtlbHkgdmljdGltIG9mIGFuCiAgIGFtcGxpZmljYXRpb24gYXR0YWNrLgoK ICAgQSBDb0FQIHNlcnZlciBjYW4gcmVkdWNlIHRoZSBhbW91bnQgb2YgYW1wbGlmaWNhdGlvbiBp dCBwcm92aWRlcyB0bwogICBhbiBhdHRhY2tlciBieSB1c2luZyBzbGljaW5nL2Jsb2NraW5nIG1v ZGVzIG9mIENvQVAKICAgW0ktRC5pZXRmLWNvcmUtYmxvY2tdIGFuZCBvZmZlcmluZyBsYXJnZSBy ZXNvdXJjZSByZXByZXNlbnRhdGlvbnMKICAgb25seSBpbiByZWxhdGl2ZWx5IHNtYWxsIHNsaWNl cy4gIEZvciBleGFtcGxlLCBmb3IgYSAxMDAwIGJ5dGUgcmVzb3VyY2UsIGEKICAgMTAtYnl0ZSBy ZXF1ZXN0IG1pZ2h0IHJlc3VsdCBpbiBhbiA4MC1ieXRlIHJlc3BvbnNlICh3aXRoIGEgNjQtYnl0 ZQogICBibG9jaykgaW5zdGVhZCBvZiBhIDEwMTYtYnl0ZSByZXNwb25zZSwgY29uc2lkZXJhYmx5 IHJlZHVjaW5nIHRoZQogICBhbXBsaWZpY2F0aW9uIHByb3ZpZGVkLgoKICAgQ29BUCBhbHNvIHN1 cHBvcnRzIHRoZSB1c2Ugb2YgbXVsdGljYXN0IElQIGFkZHJlc3NlcyBpbiByZXF1ZXN0cywgYW4K ICAgaW1wb3J0YW50IHJlcXVpcmVtZW50IGZvciBNMk0uIE11bHRpY2FzdCBDb0FQIHJlcXVlc3Rz IG1heSBiZSB0aGUKICAgc291cmNlIG9mIGFjY2lkZW50YWwgb3IgZGVsaWJlcmF0ZSBkZW5pYWwg b2Ygc2VydmljZSBhdHRhY2tzLAogICBlc3BlY2lhbGx5IG92ZXIgY29uc3RyYWluZWQgbmV0d29y a3MuICBUaGlzIHNwZWNpZmljYXRpb24gYXR0ZW1wdHMgdG8KICAgcmVkdWNlIHRoZSBhbXBsaWZp Y2F0aW9uIGVmZmVjdHMgb2YgbXVsdGljYXN0IHJlcXVlc3RzIGJ5IGxpbWl0aW5nCiAgIHdoZW4g YSByZXNwb25zZSBpcyByZXR1cm5lZC4gIFRvIGxpbWl0IHRoZSBwb3NzaWJpbGl0eSBvZiBtYWxp Y2lvdXMKICAgdXNlLCBDb0FQIHNlcnZlcnMgU0hPVUxEIE5PVCBhY2NlcHQgbXVsdGljYXN0IHJl cXVlc3RzIHRoYXQgY2FuIG5vdAogICBiZSBhdXRoZW50aWNhdGVkLiAgSWYgcG9zc2libGUgYSBD b0FQIHNlcnZlciBTSE9VTEQgbGltaXQgdGhlIHN1cHBvcnQKICAgZm9yIG11bHRpY2FzdCByZXF1 ZXN0cyB0byBzcGVjaWZpYyByZXNvdXJjZXMgd2hlcmUgdGhlIGZlYXR1cmUgaXMKICAgcmVxdWly ZWQuCgoKCgpTaGVsYnksIGV0IGFsLiAgICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDE1LCAyMDEx ICAgICAgICAgICAgICBbUGFnZSA1NF0KDApJbnRlcm5ldC1EcmFmdCAgIENvbnN0cmFpbmVkIEFw cGxpY2F0aW9uIFByb3RvY29sIChDb0FQKSAgICAgIE1hcmNoIDIwMTEKCgogICBPbiBzb21lIGdl bmVyYWwgcHVycG9zZSBvcGVyYXRpbmcgc3lzdGVtcyBwcm92aWRpbmcgYSBQb3NpeC1zdHlsZQog ICBBUEksIGl0IGlzIG5vdCBzdHJhaWdodGZvcndhcmQgdG8gZmluZCBvdXQgd2hldGhlciBhIHBh Y2tldCByZWNlaXZlZAogICB3YXMgYWRkcmVzc2VkIHRvIGEgbXVsdGljYXN0IGFkZHJlc3MuICBX aGlsZSBtYW55IGltcGxlbWVudGF0aW9ucwogICB3aWxsIGtub3cgd2hldGhlciB0aGV5IGhhdmUg am9pbmVkIGEgbXVsdGljYXN0IGdyb3VwLCB0aGlzIGNyZWF0ZXMgYQogICBwcm9ibGVtIGZvciBw YWNrZXRzIGFkZHJlc3NlZCB0byBtdWx0aWNhc3QgYWRkcmVzc2VzIG9mIHRoZSBmb3JtCiAgIEZG MHg6OjEsIHdoaWNoIGFyZSByZWNlaXZlZCBieSBldmVyeSBJUHY2IG5vZGUuICBJbXBsZW1lbnRh dGlvbnMKICAgU0hPVUxEIG1ha2UgdXNlIG9mIG1vZGVybiBBUElzIHN1Y2ggYXMgSVBWNl9SRUNW UEtUSU5GTyBbUkZDMzU0Ml0sIGlmCiAgIGF2YWlsYWJsZSwgdG8gbWFrZSB0aGlzIGRldGVybWlu YXRpb24uCgoxMC4zLjQuICBDcm9zcy1Qcm90b2NvbCBBdHRhY2tzCgogICBUaGUgYWJpbGl0eSB0 byBpbmNpdGUgYSBDb0FQIGVuZC1wb2ludCB0byBzZW5kIHBhY2tldHMgdG8gYSBmYWtlCiAgIHNv dXJjZSBhZGRyZXNzIGNhbiBiZSB1c2VkIG5vdCBvbmx5IGZvciBhbXBsaWZpY2F0aW9uLCBidXQg YWxzbyBmb3IKICAgY3Jvc3MtcHJvdG9jb2wgYXR0YWNrczoKCiAgIG8gIHRoZSBhdHRhY2tlciBz ZW5kcyBhIG1lc3NhZ2UgdG8gYSBDb0FQIGVuZC1wb2ludCB3aXRoIGEgZmFrZQogICAgICBzb3Vy Y2UgYWRkcmVzcywKCiAgIG8gIHRoZSBDb0FQIGVuZC1wb2ludCByZXBsaWVzIHdpdGggYSBtZXNz YWdlIHRvIHRoZSBnaXZlbiBzb3VyY2UKICAgICAgYWRkcmVzcywKCiAgIG8gIHRoZSB2aWN0aW0g YXQgdGhlIGdpdmVuIHNvdXJjZSBhZGRyZXNzIHJlY2VpdmVzIGEgVURQIHBhY2tldCB0aGF0CiAg ICAgIGl0IGludGVycHJldHMgYWNjb3JkaW5nIHRvIHRoZSBydWxlcyBvZiBhIGRpZmZlcmVudCBw cm90b2NvbC4KCiAgIFRoaXMgbWF5IGJlIHVzZWQgdG8gY2lyY3VtdmVudCBmaXJld2FsbCBydWxl cyB0aGF0IHByZXZlbnQgZGlyZWN0CiAgIGNvbW11bmljYXRpb24gZnJvbSB0aGUgYXR0YWNrZXIg dG8gdGhlIHZpY3RpbSwgYnV0IGhhcHBlbiB0byBhbGxvdwogICBjb21tdW5pY2F0aW9uIGZyb20g dGhlIENvQVAgZW5kLXBvaW50ICh3aGljaCBtYXkgYWxzbyBob3N0IGEgdmFsaWQKICAgcm9sZSBp biB0aGUgb3RoZXIgcHJvdG9jb2wpIHRvIHRoZSB2aWN0aW0uCgogICBBbHNvLCBDb0FQIGVuZC1w b2ludHMgbWF5IGJlIHRoZSB2aWN0aW0gb2YgYSBjcm9zcy1wcm90b2NvbCBhdHRhY2sKICAgZ2Vu ZXJhdGVkIHRocm91Z2ggYW4gZW5kLXBvaW50IG9mIGFub3RoZXIgVURQLWJhc2VkIHByb3RvY29s IHN1Y2ggYXMKICAgRE5TLiAgSW4gYm90aCBjYXNlcywgYXR0YWNrcyBhcmUgcG9zc2libGUgaWYg dGhlIHNlY3VyaXR5IHByb3BlcnRpZXMKICAgb2YgdGhlIGVuZC1wb2ludHMgcmVseSBvbiBjaGVj a2luZyBJUCBhZGRyZXNzZXMgKGFuZCBmaXJld2FsbGluZyBvZmYKICAgZGlyZWN0IGF0dGFja3Mg c2VudCBmcm9tIG91dHNpZGUgdXNpbmcgZmFrZSBJUCBhZGRyZXNzZXMpLiAgSW4KICAgZ2VuZXJh bCwgYmVjYXVzZSBvZiB0aGVpciBsYWNrIG9mIGNvbnRleHQsIFVEUC1iYXNlZCBwcm90b2NvbHMg YXJlCiAgIHJlbGF0aXZlbHkgZWFzeSB0YXJnZXRzIGZvciBjcm9zcy1wcm90b2NvbCBhdHRhY2tz LgoKICAgRmluYWxseSwgQ29BUCBVUklzIHRyYW5zcG9ydGVkIGJ5IG90aGVyIG1lYW5zIGNvdWxk IGJlIHVzZWQgdG8gaW5jaXRlCiAgIGNsaWVudHMgdG8gc2VuZCBtZXNzYWdlcyB0byBlbmQtcG9p bnRzIG9mIG90aGVyIHByb3RvY29scy4ge3doYXQgZG9lcwogICAidHJhbnNwb3J0ZWQgYnkgb3Ro ZXIgbWVhbnMiIG1lYW4/fQoKICAgT25lIG1pdGlnYXRpb24gYWdhaW5zdCBjcm9zcy1wcm90b2Nv bCBhdHRhY2tzIGlzIHN0cmljdCBjaGVja2luZyBvZgogICB0aGUgc3ludGF4IG9mIHBhY2tldHMg cmVjZWl2ZWQsIGNvbWJpbmVkIHdpdGggc3VmZmljaWVudCBkaWZmZXJlbmNlCiAgIGluIHN5bnRh eC4gIEFzIGFuIGV4YW1wbGUsIGl0IG1pZ2h0IGhlbHAgaWYgaXQgd2VyZSBkaWZmaWN1bHQgdG8K ICAgaW5jaXRlIGEgRE5TIHNlcnZlciB0byBzZW5kIGEgRE5TIHJlc3BvbnNlIHRoYXQgd291bGQg cGFzcyB0aGUgY2hlY2tzCiAgIG9mIGEgQ29BUCBlbmQtcG9pbnQuICBVbmZvcnR1bmF0ZWx5LCB0 aGUgZmlyc3QgdHdvIGJ5dGVzIG9mIGEgRE5TCiAgIHJlcGx5IGFyZSBhbiBJRCB0aGF0IGNhbiBi ZSBjaG9zZW4gYnkgdGhlIGF0dGFja2VyLCB3aGljaCBtYXAgaW50bwogICB0aGUgaW50ZXJlc3Rp bmcgcGFydCBvZiB0aGUgQ29BUCBoZWFkZXIsIGFuZCB0aGUgbmV4dCB0d28gYnl0ZXMgYXJlCiAg IHRoZW4gaW50ZXJwcmV0ZWQgYXMgQ29BUCdzIE1lc3NhZ2UgSUQgKGkuZS4sIGFueSB2YWx1ZSBp cwoKCgpTaGVsYnksIGV0IGFsLiAgICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDE1LCAyMDExICAg ICAgICAgICAgICBbUGFnZSA1NV0KDApJbnRlcm5ldC1EcmFmdCAgIENvbnN0cmFpbmVkIEFwcGxp Y2F0aW9uIFByb3RvY29sIChDb0FQKSAgICAgIE1hcmNoIDIwMTEKCgogICBhY2NlcHRhYmxlKS4g IFRoZSBETlMgY291bnQgd29yZHMgbWF5IGJlIGludGVycHJldGVkIGFzIG11bHRpcGxlCiAgIGlu c3RhbmNlcyBvZiBhIChub24tZXhpc3RlbnQsIGJ1dCBlbGVjdGl2ZSkgQ29BUCBvcHRpb24gMC4g IFRoZQogICBlY2hvZWQgcXVlcnkgZmluYWxseSBtYXkgYmUgbWFudWZhY3R1cmVkIGJ5IHRoZSBh dHRhY2tlciB0byBhY2hpZXZlIGEKICAgZGVzaXJlZCBlZmZlY3Qgb24gdGhlIENvQVAgZW5kLXBv aW50OyB0aGUgcmVzcG9uc2UgYWRkZWQgYnkgdGhlIHNlcnZlcgogICAoaWYgYW55KSBtaWdodCB0 aGVuIGp1c3QgYmUgaW50ZXJwcmV0ZWQgYXMgYWRkZWQgcGF5bG9hZC4KCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgMSAgMSAgMSAgMSAgMSAgMQogICAgIDAgIDEgIDIgIDMgIDQg IDUgIDYgIDcgIDggIDkgIDAgIDEgIDIgIDMgIDQgIDUKICAgKy0tKy0tKy0tKy0tKy0tKy0tKy0t Ky0tKy0tKy0tKy0tKy0tKy0tKy0tKy0tKy0tKwogICB8ICAgICAgICAgICAgICAgICAgICAgIElE ICAgICAgICAgICAgICAgICAgICAgICB8IFQsIE9DLCBjb2RlCiAgICstLSstLSstLSstLSstLSst LSstLSstLSstLSstLSstLSstLSstLSstLSstLSstLSsKICAgfFFSfCAgIE9wY29kZSAgfEFBfFRD fFJEfFJBfCAgIFogICAgfCAgIFJDT0RFICAgfCBtZXNzYWdlIGlkCiAgICstLSstLSstLSstLSst LSstLSstLSstLSstLSstLSstLSstLSstLSstLSstLSstLSsKICAgfCAgICAgICAgICAgICAgICAg ICAgUURDT1VOVCAgICAgICAgICAgICAgICAgICAgfCAob3B0aW9ucyAwKQogICArLS0rLS0rLS0r LS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rCiAgIHwgICAgICAgICAgICAg ICAgICAgIEFOQ09VTlQgICAgICAgICAgICAgICAgICAgIHwgKG9wdGlvbnMgMCkKICAgKy0tKy0t Ky0tKy0tKy0tKy0tKy0tKy0tKy0tKy0tKy0tKy0tKy0tKy0tKy0tKy0tKwogICB8ICAgICAgICAg ICAgICAgICAgICBOU0NPVU5UICAgICAgICAgICAgICAgICAgICB8IChvcHRpb25zIDApCiAgICst LSstLSstLSstLSstLSstLSstLSstLSstLSstLSstLSstLSstLSstLSstLSstLSsKICAgfCAgICAg ICAgICAgICAgICAgICAgQVJDT1VOVCAgICAgICAgICAgICAgICAgICAgfCAob3B0aW9ucyAwKQog ICArLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rCgogICAg ICAgICAgICAgICAgICBGaWd1cmUgMTA6IEROUyBIZWFkZXIgdnMuIENvQVAgTWVzc2FnZQoKICAg SW4gZ2VuZXJhbCwgZm9yIGFueSBwYWlyIG9mIHByb3RvY29scywgb25lIG9mIHRoZSBwcm90b2Nv bHMgY2FuIHZlcnkKICAgd2VsbCBoYXZlIGJlZW4gZGVzaWduZWQgaW4gYSB3YXkgdGhhdCBlbmFi bGVzIGFuIGF0dGFja2VyIHRvIGNhdXNlCiAgIHRoZSBnZW5lcmF0aW9uIG9mIHJlcGxpZXMgdGhh dCBsb29rIGxpa2UgbWVzc2FnZXMgb2YgdGhlIG90aGVyCiAgIHByb3RvY29sLiAgSXQgaXMgb2Z0 ZW4gbXVjaCBoYXJkZXIgdG8gZW5zdXJlIG9yIHByb3ZlIHRoZSBhYnNlbmNlIG9mCiAgIHZpYWJs ZSBhdHRhY2tzIHRoYW4gdG8gZ2VuZXJhdGUgZXhhbXBsZXMgdGhhdCBtYXkgbm90IHlldCBjb21w bGV0ZWx5CiAgIGVuYWJsZSBhbiBhdHRhY2sgYnV0IG1pZ2h0IGJlIGZ1cnRoZXIgZGV2ZWxvcGVk IGJ5IG1vcmUgY3JlYXRpdmUKICAgbWluZHMuICBDcm9zcy1wcm90b2NvbCBhdHRhY2tzIGNhbiB0 aGVyZWZvcmUgb25seSBiZSBjb21wbGV0ZWx5CiAgIG1pdGlnYXRlZCBpZiBlbmQtcG9pbnRzIGRv bid0IGF1dGhvcml6ZSBhY3Rpb25zIGRlc2lyZWQgYnkgYW4KICAgYXR0YWNrZXIganVzdCBiYXNl ZCBvbiB0cnVzdGluZyB0aGUgc291cmNlIElQIGFkZHJlc3Mgb2YgYSBwYWNrZXQuCiAgIENvbnZl cnNlbHksIGEgTm9TZWMgZW52aXJvbm1lbnQgdGhhdCBjb21wbGV0ZWx5IHJlbGllcyBvbiBhIGZp cmV3YWxsCiAgIGZvciBDb0FQIHNlY3VyaXR5IG5vdCBvbmx5IG5lZWRzIHRvIGZpcmV3YWxsIG9m ZiB0aGUgQ29BUCBlbmQtcG9pbnRzCiAgIGJ1dCBhbHNvIGFsbCBvdGhlciBlbmQtcG9pbnRzIHRo YXQgbWlnaHQgYmUgaW5jaXRlZCB0byBzZW5kIFVEUAogICBtZXNzYWdlcyB0byBDb0FQIGVuZC1w b2ludHMgdXNpbmcgc29tZSBvdGhlciBVRFAtYmFzZWQgcHJvdG9jb2wuCgogICBJbiBhZGRpdGlv biB0byB0aGUgY29uc2lkZXJhdGlvbnMgYWJvdmUsIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9u cwogICBmb3IgRFRMUyB3aXRoIHJlc3BlY3QgdG8gY3Jvc3MtcHJvdG9jb2wgYXR0YWNrcyBhcHBs eS4gIEUuZy4sIGlmIHRoZQogICBzYW1lIERUTFMgc2VjdXJpdHkgYXNzb2NpYXRpb24gKCJjb25u ZWN0aW9uIikgaXMgdXNlZCB0byBjYXJyeSBkYXRhCiAgIG9mIG11bHRpcGxlIHByb3RvY29scywg RFRMUyBubyBsb25nZXIgcHJvdmlkZXMgcHJvdGVjdGlvbiBhZ2FpbnN0CiAgIGNyb3NzLXByb3Rv Y29sIGF0dGFja3MgYmV0d2VlbiB0aGVzZSBwcm90b2NvbHMuCgoKMTEuICBJQU5BIENvbnNpZGVy YXRpb25zCgoKCgoKU2hlbGJ5LCBldCBhbC4gICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAxNSwg MjAxMSAgICAgICAgICAgICAgW1BhZ2UgNTZdCgwKSW50ZXJuZXQtRHJhZnQgICBDb25zdHJhaW5l ZCBBcHBsaWNhdGlvbiBQcm90b2NvbCAoQ29BUCkgICAgICBNYXJjaCAyMDExCgoKMTEuMS4gIENv QVAgQ29kZSBSZWdpc3RyeQoKICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgcmVnaXN0cnkgZm9y IHRoZSB2YWx1ZXMgb2YgdGhlIENvZGUgZmllbGQgaW4KICAgdGhlIENvQVAgaGVhZGVyLiAgVGhl IG5hbWUgb2YgdGhlIHJlZ2lzdHJ5IGlzICJDb0FQIENvZGVzIi4KCiAgIEFsbCB2YWx1ZXMgYXJl IGFzc2lnbmVkIGJ5IHN1Yi1yZWdpc3RyaWVzIGFjY29yZGluZyB0byB0aGUgZm9sbG93aW5nCiAg IHJhbmdlczoKCiAgIDAgICAgICAgICBJbmRpY2F0ZXMgYW4gZW1wdHkgbWVzc2FnZSAoc2VlIFNl Y3Rpb24gNC4zKS4KCiAgIDEtMzEgICAgICBJbmRpY2F0ZXMgYSByZXF1ZXN0LiAgVmFsdWVzIGlu IHRoaXMgcmFuZ2UgYXJlIGFzc2lnbmVkIGJ5CiAgICAgICAgICAgICB0aGUgIkNvQVAgTWV0aG9k IENvZGVzIiBzdWItcmVnaXN0cnkgKHNlZSBTZWN0aW9uIDExLjEuMSkuCgogICAzMi02MyAgICAg UmVzZXJ2ZWQKCiAgIDY0LTE5MSAgICBJbmRpY2F0ZXMgYSByZXNwb25zZS4gIFZhbHVlcyBpbiB0 aGlzIHJhbmdlIGFyZSBhc3NpZ25lZCBieQogICAgICAgICAgICAgdGhlICJDb0FQIFJlc3BvbnNl IENvZGVzIiBzdWItcmVnaXN0cnkgKHNlZQogICAgICAgICAgICAgU2VjdGlvbiAxMS4xLjIpLgoK ICAgMTkyLTI1NSAgIFJlc2VydmVkCgoxMS4xLjEuICBNZXRob2QgQ29kZXMKCiAgIFRoZSBuYW1l IG9mIHRoZSBzdWItcmVnaXN0cnkgaXMgIkNvQVAgTWV0aG9kIENvZGVzIi4KCiAgIEVhY2ggZW50 cnkgaW4gdGhlIHN1Yi1yZWdpc3RyeSBtdXN0IGluY2x1ZGUgdGhlIE1ldGhvZCBDb2RlIGluIHRo ZQogICByYW5nZSAxLTMxLCB0aGUgbmFtZSBvZiB0aGUgbWV0aG9kLCBhbmQgYSByZWZlcmVuY2Ug dG8gdGhlIG1ldGhvZCdzCiAgIGRvY3VtZW50YXRpb24uCgogICBJbml0aWFsIGVudHJpZXMgaW4g dGhpcyBzdWItcmVnaXN0cnkgYXJlIGFzIGZvbGxvd3M6CgogICAgICAgICAgICAgICAgICAgICAg ICstLS0tLS0rLS0tLS0tLS0rLS0tLS0tLS0tLS0rCiAgICAgICAgICAgICAgICAgICAgICAgfCBD b2RlIHwgTmFtZSAgIHwgUmVmZXJlbmNlIHwKICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0t Ky0tLS0tLS0tKy0tLS0tLS0tLS0tKwogICAgICAgICAgICAgICAgICAgICAgIHwgICAgMSB8IEdF VCAgICB8IFtSRkNYWFhYXSB8CiAgICAgICAgICAgICAgICAgICAgICAgfCAgICAyIHwgUE9TVCAg IHwgW1JGQ1hYWFhdIHwKICAgICAgICAgICAgICAgICAgICAgICB8ICAgIDMgfCBQVVQgICAgfCBb UkZDWFhYWF0gfAogICAgICAgICAgICAgICAgICAgICAgIHwgICAgNCB8IERFTEVURSB8IFtSRkNY WFhYXSB8CiAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLSstLS0tLS0tLSstLS0tLS0tLS0t LSsKCiAgICAgICAgICAgICAgICAgICAgICAgIFRhYmxlIDU6IENvQVAgTWV0aG9kIENvZGVzCgog ICBBbGwgb3RoZXIgTWV0aG9kIENvZGVzIGFyZSBVbmFzc2lnbmVkLgoKICAgVGhlIElBTkEgcG9s aWN5IGZvciBmdXR1cmUgYWRkaXRpb25zIHRvIHRoaXMgcmVnaXN0cnkgaXMgIklFVEYKICAgUmV2 aWV3IiBhcyBkZXNjcmliZWQgaW4gW1JGQzUyMjZdLgoKICAgVGhlIGRvY3VtZW50YXRpb24gb2Yg YSBtZXRob2QgY29kZSBzaG91bGQgc3BlY2lmeSB0aGUgc2VtYW50aWNzIG9mIGEKCgoKU2hlbGJ5 LCBldCBhbC4gICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAxNSwgMjAxMSAgICAgICAgICAgICAg W1BhZ2UgNTddCgwKSW50ZXJuZXQtRHJhZnQgICBDb25zdHJhaW5lZCBBcHBsaWNhdGlvbiBQcm90 b2NvbCAoQ29BUCkgICAgICBNYXJjaCAyMDExCgoKICAgcmVxdWVzdCB3aXRoIHRoYXQgY29kZSwg aW5jbHVkaW5nIHRoZSBmb2xsb3dpbmcgcHJvcGVydGllczoKCiAgIG8gIFRoZSByZXNwb25zZSBj b2RlcyB0aGUgbWV0aG9kIHJldHVybnMgaW4gdGhlIHN1Y2Nlc3MgY2FzZS4KCiAgIG8gIFdoZXRo ZXIgdGhlIG1ldGhvZCBpcyBpZGVtcG90ZW50LCBzYWZlLCBvciBib3RoLgoKICAgbyAgV2hldGhl ciB0aGUgcmVxdWVzdCBjYXVzZXMgYSBjYWNoZSB0byBtYXJrIHJlc3BvbnNlcyBzdG9yZWQgZm9y CiAgICAgIHRoZSByZXF1ZXN0IFVSSSBhcyBzdGFsZS4KCjExLjEuMi4gIFJlc3BvbnNlIENvZGVz CgogICBUaGUgbmFtZSBvZiB0aGUgc3ViLXJlZ2lzdHJ5IGlzICJDb0FQIFJlc3BvbnNlIENvZGVz Ii4KCiAgIEVhY2ggZW50cnkgaW4gdGhlIHN1Yi1yZWdpc3RyeSBtdXN0IGluY2x1ZGUgdGhlIFJl c3BvbnNlIENvZGUgaW4gdGhlCiAgIHJhbmdlIDY0LTE5MSwgYSBkZXNjcmlwdGlvbiBvZiB0aGUg UmVzcG9uc2UgQ29kZSwgYW5kIGEgcmVmZXJlbmNlIHRvCiAgIHRoZSBSZXNwb25zZSBDb2RlJ3Mg ZG9jdW1lbnRhdGlvbi4KCiAgIEluaXRpYWwgZW50cmllcyBpbiB0aGlzIHN1Yi1yZWdpc3RyeSBh cmUgYXMgZm9sbG93czoKCiAgICAgICAgICAgKy0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tKy0tLS0tLS0tLS0tKwogICAgICAgICAgIHwgQ29kZSB8IERlc2NyaXB0aW9uICAg ICAgICAgICAgICAgICAgIHwgUmVmZXJlbmNlIHwKICAgICAgICAgICArLS0tLS0tKy0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0rCiAgICAgICAgICAgfCAgIDY1IHwg Mi4wMSBDcmVhdGVkICAgICAgICAgICAgICAgICAgfCBbUkZDWFhYWF0gfAogICAgICAgICAgIHwg ICA2NiB8IDIuMDIgRGVsZXRlZCAgICAgICAgICAgICAgICAgIHwgW1JGQ1hYWFhdIHwKICAgICAg ICAgICB8ICAgNjcgfCAyLjAzIFZhbGlkICAgICAgICAgICAgICAgICAgICB8IFtSRkNYWFhYXSB8 CiAgICAgICAgICAgfCAgIDY4IHwgMi4wNCBDaGFuZ2VkICAgICAgICAgICAgICAgICAgfCBbUkZD WFhYWF0gfAogICAgICAgICAgIHwgICA2OSB8IDIuMDUgQ29udGVudCAgICAgICAgICAgICAgICAg IHwgW1JGQ1hYWFhdIHwKICAgICAgICAgICB8ICAxMjggfCA0LjAwIEJhZCBSZXF1ZXN0ICAgICAg ICAgICAgICB8IFtSRkNYWFhYXSB8CiAgICAgICAgICAgfCAgMTI5IHwgNC4wMSBVbmF1dGhvcml6 ZWQgICAgICAgICAgICAgfCBbUkZDWFhYWF0gfAogICAgICAgICAgIHwgIDEzMCB8IDQuMDIgQmFk IE9wdGlvbiAgICAgICAgICAgICAgIHwgW1JGQ1hYWFhdIHwKICAgICAgICAgICB8ICAxMzEgfCA0 LjAzIEZvcmJpZGRlbiAgICAgICAgICAgICAgICB8IFtSRkNYWFhYXSB8CiAgICAgICAgICAgfCAg MTMyIHwgNC4wNCBOb3QgRm91bmQgICAgICAgICAgICAgICAgfCBbUkZDWFhYWF0gfAogICAgICAg ICAgIHwgIDEzMyB8IDQuMDUgTWV0aG9kIE5vdCBBbGxvd2VkICAgICAgIHwgW1JGQ1hYWFhdIHwK ICAgICAgICAgICB8ICAxNDEgfCA0LjEzIFJlcXVlc3QgRW50aXR5IFRvbyBMYXJnZSB8IFtSRkNY WFhYXSB8CiAgICAgICAgICAgfCAgMTQzIHwgNC4xNSBVbnN1cHBvcnRlZCBNZWRpYSBUeXBlICAg fCBbUkZDWFhYWF0gfAogICAgICAgICAgIHwgIDE2MCB8IDUuMDAgSW50ZXJuYWwgU2VydmVyIEVy cm9yICAgIHwgW1JGQ1hYWFhdIHwKICAgICAgICAgICB8ICAxNjEgfCA1LjAxIE5vdCBJbXBsZW1l bnRlZCAgICAgICAgICB8IFtSRkNYWFhYXSB8CiAgICAgICAgICAgfCAgMTYyIHwgNS4wMiBCYWQg R2F0ZXdheSAgICAgICAgICAgICAgfCBbUkZDWFhYWF0gfAogICAgICAgICAgIHwgIDE2MyB8IDUu MDMgU2VydmljZSBVbmF2YWlsYWJsZSAgICAgIHwgW1JGQ1hYWFhdIHwKICAgICAgICAgICB8ICAx NjQgfCA1LjA0IEdhdGV3YXkgVGltZW91dCAgICAgICAgICB8IFtSRkNYWFhYXSB8CiAgICAgICAg ICAgfCAgMTY1IHwgNS4wNSBQcm94eWluZyBOb3QgU3VwcG9ydGVkICAgfCBbUkZDWFhYWF0gfAog ICAgICAgICAgICstLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0t LS0tLSsKCiAgICAgICAgICAgICAgICAgICAgICAgVGFibGUgNjogQ29BUCBSZXNwb25zZSBDb2Rl cwoKICAgVGhlIFJlc3BvbnNlIENvZGVzIDk2LTEyNyBhcmUgUmVzZXJ2ZWQgZm9yIGZ1dHVyZSB1 c2UuICBBbGwgb3RoZXIKICAgUmVzcG9uc2UgQ29kZXMgYXJlIFVuYXNzaWduZWQuCgoKCgpTaGVs YnksIGV0IGFsLiAgICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDE1LCAyMDExICAgICAgICAgICAg ICBbUGFnZSA1OF0KDApJbnRlcm5ldC1EcmFmdCAgIENvbnN0cmFpbmVkIEFwcGxpY2F0aW9uIFBy b3RvY29sIChDb0FQKSAgICAgIE1hcmNoIDIwMTEKCgogICBUaGUgSUFOQSBwb2xpY3kgZm9yIGZ1 dHVyZSBhZGRpdGlvbnMgdG8gdGhpcyByZWdpc3RyeSBpcyAiSUVURgogICBSZXZpZXciIGFzIGRl c2NyaWJlZCBpbiBbUkZDNTIyNl0uCgogICBUaGUgZG9jdW1lbnRhdGlvbiBvZiBhIHJlc3BvbnNl IGNvZGUgc2hvdWxkIHNwZWNpZnkgdGhlIHNlbWFudGljcyBvZgogICBhIHJlc3BvbnNlIHdpdGgg dGhhdCBjb2RlLCBpbmNsdWRpbmcgdGhlIGZvbGxvd2luZyBwcm9wZXJ0aWVzOgoKICAgbyAgVGhl IG1ldGhvZHMgdGhlIHJlc3BvbnNlIGNvZGUgYXBwbGllcyB0by4KCiAgIG8gIFdoZXRoZXIgcGF5 bG9hZCBpcyByZXF1aXJlZCwgb3B0aW9uYWwgb3Igbm90IGFsbG93ZWQuCgogICBvICBUaGUgc2Vt YW50aWNzIG9mIHRoZSBwYXlsb2FkLiAgRm9yIGV4YW1wbGUsIHRoZSBwYXlsb2FkIG9mIGEgMi4w NQogICAgICAoQ29udGVudCkgcmVzcG9uc2UgaXMgYSByZXByZXNlbnRhdGlvbiBvZiB0aGUgdGFy Z2V0IHJlc291cmNlOyB0aGUKICAgICAgcGF5bG9hZCBpbiBhbiBlcnJvciByZXNwb25zZSBpcyBh IGh1bWFuLXJlYWRhYmxlIGRpYWdub3N0aWMKICAgICAgbWVzc2FnZS4KCiAgIG8gIFRoZSBmb3Jt YXQgb2YgdGhlIHBheWxvYWQuICBGb3IgZXhhbXBsZSwgdGhlIGZvcm1hdCBpbiBhIDIuMDUKICAg ICAgKENvbnRlbnQpIHJlc3BvbnNlIGlzIGluZGljYXRlZCBieSB0aGUgQ29udGVudC1UeXBlIE9w dGlvbjsgdGhlCiAgICAgIGZvcm1hdCBvZiB0aGUgcGF5bG9hZCBpbiBhbiBlcnJvciByZXNwb25z ZSBpcyBhbHdheXMgTmV0LVVuaWNvZGUKICAgICAgdGV4dC4KCiAgIG8gIFdoZXRoZXIgdGhlIHJl c3BvbnNlIGlzIGNhY2hlYWJsZSBhY2NvcmRpbmcgdG8gdGhlIGZyZXNobmVzcwogICAgICBtb2Rl bC4KCiAgIG8gIFdoZXRoZXIgdGhlIHJlc3BvbnNlIGlzIHZhbGlkYXRhYmxlIGFjY29yZGluZyB0 byB0aGUgdmFsaWRhdGlvbgogICAgICBtb2RlbC4KCiAgIG8gIFdoZXRoZXIgdGhlIHJlc3BvbnNl IGNhdXNlcyBhIGNhY2hlIHRvIG1hcmsgcmVzcG9uc2VzIHN0b3JlZCBmb3IKICAgICAgdGhlIHJl cXVlc3QgVVJJIGFzIHN0YWxlLgoKMTEuMi4gIE9wdGlvbiBOdW1iZXIgUmVnaXN0cnkKCiAgIFRo aXMgZG9jdW1lbnQgZGVmaW5lcyBhIHJlZ2lzdHJ5IGZvciB0aGUgb3B0aW9uIG51bWJlcnMgdXNl ZCBpbiBDb0FQCiAgIG9wdGlvbnMuICBUaGUgbmFtZSBvZiB0aGUgcmVnaXN0cnkgaXMgIkNvQVAg T3B0aW9uIE51bWJlcnMiLgoKICAgRWFjaCBlbnRyeSBpbiB0aGUgcmVnaXN0cnkgbXVzdCBpbmNs dWRlIHRoZSBPcHRpb24gTnVtYmVyLCB0aGUgbmFtZQogICBvZiB0aGUgb3B0aW9uIGFuZCBhIHJl ZmVyZW5jZSB0byB0aGUgb3B0aW9uJ3MgZG9jdW1lbnRhdGlvbi4KCiAgIEluaXRpYWwgZW50cmll cyBpbiB0aGlzIHJlZ2lzdHJ5IGFyZSBhcyBmb2xsb3dzOgoKCgoKCgoKCgoKCgoKU2hlbGJ5LCBl dCBhbC4gICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAxNSwgMjAxMSAgICAgICAgICAgICAgW1Bh Z2UgNTldCgwKSW50ZXJuZXQtRHJhZnQgICBDb25zdHJhaW5lZCBBcHBsaWNhdGlvbiBQcm90b2Nv bCAoQ29BUCkgICAgICBNYXJjaCAyMDExCgoKICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tKy0t LS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0rCiAgICAgICAgICAgICAgICAgIHwgTnVtYmVyIHwg TmFtZSAgICAgICAgICAgfCBSZWZlcmVuY2UgfAogICAgICAgICAgICAgICAgICArLS0tLS0tLS0r LS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLSsKICAgICAgICAgICAgICAgICAgfCAgICAgIDEg fCBDb250ZW50LVR5cGUgICB8IFtSRkNYWFhYXSB8CiAgICAgICAgICAgICAgICAgIHwgICAgICAy IHwgTWF4LUFnZSAgICAgICAgfCBbUkZDWFhYWF0gfAogICAgICAgICAgICAgICAgICB8ICAgICAg MyB8IFByb3h5LVVyaSAgICAgIHwgW1JGQ1hYWFhdIHwKICAgICAgICAgICAgICAgICAgfCAgICAg IDQgfCBFVGFnICAgICAgICAgICB8IFtSRkNYWFhYXSB8CiAgICAgICAgICAgICAgICAgIHwgICAg ICA1IHwgVXJpLUhvc3QgICAgICAgfCBbUkZDWFhYWF0gfAogICAgICAgICAgICAgICAgICB8ICAg ICAgNiB8IExvY2F0aW9uLVBhdGggIHwgW1JGQ1hYWFhdIHwKICAgICAgICAgICAgICAgICAgfCAg ICAgIDcgfCBVcmktUG9ydCAgICAgICB8IFtSRkNYWFhYXSB8CiAgICAgICAgICAgICAgICAgIHwg ICAgICA4IHwgTG9jYXRpb24tUXVlcnkgfCBbUkZDWFhYWF0gfAogICAgICAgICAgICAgICAgICB8 ICAgICAgOSB8IFVyaS1QYXRoICAgICAgIHwgW1JGQ1hYWFhdIHwKICAgICAgICAgICAgICAgICAg fCAgICAgMTEgfCBUb2tlbiAgICAgICAgICB8IFtSRkNYWFhYXSB8CiAgICAgICAgICAgICAgICAg IHwgICAgIDE1IHwgVXJpLVF1ZXJ5ICAgICAgfCBbUkZDWFhYWF0gfAogICAgICAgICAgICAgICAg ICArLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLSsKCiAgICAgICAgICAgICAg ICAgICAgICAgVGFibGUgNzogQ29BUCBPcHRpb24gTnVtYmVycwoKICAgVGhlIE9wdGlvbiBOdW1i ZXIgMCBpcyBSZXNlcnZlZCBmb3IgZnV0dXJlIHVzZS4gIFRoZSBPcHRpb24gTnVtYmVycwogICAx NCwgMjgsIDQyLCAuLi4gYXJlIFJlc2VydmVkIGZvciAiZmVuY2Vwb3N0aW5nIiAoc2VlIFNlY3Rp b24gMy4yKS4KICAgQWxsIG90aGVyIE9wdGlvbiBOdW1iZXJzIGFyZSBVbmFzc2lnbmVkLgoKICAg VGhlIElBTkEgcG9saWN5IGZvciBmdXR1cmUgYWRkaXRpb25zIHRvIHRoaXMgcmVnaXN0cnkgaXMg IklFVEYKICAgUmV2aWV3IiBhcyBkZXNjcmliZWQgaW4gW1JGQzUyMjZdLgoKICAgVGhlIGRvY3Vt ZW50YXRpb24gb2YgYW4gT3B0aW9uIE51bWJlciBzaG91bGQgc3BlY2lmeSB0aGUgc2VtYW50aWNz IG9mCiAgIGFuIG9wdGlvbiB3aXRoIHRoYXQgbnVtYmVyLCBpbmNsdWRpbmcgdGhlIGZvbGxvd2lu ZyBwcm9wZXJ0aWVzOgoKICAgbyAgVGhlIG1lYW5pbmcgb2YgdGhlIG9wdGlvbiBpbiBhIHJlcXVl c3QuCgogICBvICBUaGUgbWVhbmluZyBvZiB0aGUgb3B0aW9uIGluIGEgcmVzcG9uc2UuCgogICBv ICBXaGV0aGVyIHRoZSBvcHRpb24gaXMgY3JpdGljYWwgb2YgZWxlY3RpdmUsIGFzIGRldGVybWlu ZWQgYnkgdGhlCiAgICAgIG9wdGlvbiBudW1iZXIuCgogICBvICBUaGUgZm9ybWF0IGFuZCBsZW5n dGggb2YgdGhlIG9wdGlvbidzIHZhbHVlLgoKICAgbyAgV2hldGhlciB0aGUgb3B0aW9uIG11c3Qg b2NjdXIgYXQgbW9zdCBvbmNlIG9yIHdoZXRoZXIgaXQgY2FuIG9jY3VyCiAgICAgIG11bHRpcGxl IHRpbWVzLgoKICAgbyAgVGhlIGRlZmF1bHQgdmFsdWUsIGlmIGFueS4KCjExLjMuICBNZWRpYSBU eXBlIFJlZ2lzdHJ5CgogICBNZWRpYSB0eXBlcyBhcmUgaWRlbnRpZmllZCBieSBhIHN0cmluZywg c3VjaCBhcyAiYXBwbGljYXRpb24veG1sIgogICBbUkZDMjA0Nl0uICBJbiBvcmRlciB0byBtaW5p bWl6ZSB0aGUgb3ZlcmhlYWQgb2YgdXNpbmcgdGhlc2UgbWVkaWEKICAgdHlwZXMgdG8gaW5kaWNh dGUgdGhlIGZvcm1hdCBvZiBwYXlsb2FkcywgdGhpcyBkb2N1bWVudCBkZWZpbmVzIGEKICAgcmVn aXN0cnkgZm9yIGEgc3Vic2V0IG9mIEludGVybmV0IG1lZGlhIHR5cGVzIHRvIGJlIHVzZWQgaW4g Q29BUCBhbmQKCgoKU2hlbGJ5LCBldCBhbC4gICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAxNSwg MjAxMSAgICAgICAgICAgICAgW1BhZ2UgNjBdCgwKSW50ZXJuZXQtRHJhZnQgICBDb25zdHJhaW5l ZCBBcHBsaWNhdGlvbiBQcm90b2NvbCAoQ29BUCkgICAgICBNYXJjaCAyMDExCgoKICAgYXNzaWdu cyBlYWNoIGEgbnVtZXJpYyBpZGVudGlmaWVyLiAgVGhlIG5hbWUgb2YgdGhlIHJlZ2lzdHJ5IGlz ICJDb0FQCiAgIE1lZGlhIFR5cGVzIi4KCiAgIEVhY2ggZW50cnkgaW4gdGhlIHJlZ2lzdHJ5IG11 c3QgaW5jbHVkZSB0aGUgbWVkaWEgdHlwZSByZWdpc3RlcmVkCiAgIHdpdGggSUFOQSwgdGhlIG51 bWVyaWMgaWRlbnRpZmllciBpbiB0aGUgcmFuZ2UgMC02NTUzNSB0byBiZSB1c2VkIGZvcgogICB0 aGF0IG1lZGlhIHR5cGUgaW4gQ29BUCwgYW5kIGEgcmVmZXJlbmNlIHRvIGEgZG9jdW1lbnQgZGVz Y3JpYmluZwogICB3aGF0IHBheWxvYWQgd2l0aCB0aGF0IG1lZGlhIHR5cGVzIG1lYW5zIHNlbWFu dGljYWxseS4KCiAgIEluaXRpYWwgZW50cmllcyBpbiB0aGlzIHJlZ2lzdHJ5IGFyZSBhcyBmb2xs b3dzOgoKICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLSstLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLSsKICAgfCBNZWRpYSB0eXBlICAgICAgICAgICAgICAgICAgIHwg SWQuIHwgUmVmZXJlbmNlICAgICAgICAgICAgICAgICAgIHwKICAgKy0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLSstLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKICAgfCB0 ZXh0L3BsYWluOyBjaGFyc2V0PXV0Zi04ICAgIHwgICAwIHwgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwKICAgfCB0ZXh0L3htbDsgY2hhcnNldD11dGYtOCAgICAgIHwgICAxIHwgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwKICAgfCB0ZXh0L2NzdjsgY2hhcnNldD11dGYtOCAgICAg IHwgICAyIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgfCB0ZXh0L2h0bWw7IGNo YXJzZXQ9dXRmLTggICAgIHwgICAzIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAg fCBhcHBsaWNhdGlvbi9saW5rLWZvcm1hdCAgICAgIHwgIDQwIHwgW0ktRC5pZXRmLWNvcmUtbGlu ay1mb3JtYXRdIHwKICAgfCBhcHBsaWNhdGlvbi94bWwgICAgICAgICAgICAgIHwgIDQxIHwgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgfCBhcHBsaWNhdGlvbi9vY3RldC1zdHJlYW0g ICAgIHwgIDQyIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgfCBhcHBsaWNhdGlv bi9yZGYreG1sICAgICAgICAgIHwgIDQzIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwK ICAgfCBhcHBsaWNhdGlvbi9zb2FwK3htbCAgICAgICAgIHwgIDQ0IHwgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwKICAgfCBhcHBsaWNhdGlvbi9hdG9tK3htbCAgICAgICAgIHwgIDQ1IHwg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgfCBhcHBsaWNhdGlvbi94bXBwK3htbCAg ICAgICAgIHwgIDQ2IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgfCBhcHBsaWNh dGlvbi9leGkgICAgICAgICAgICAgIHwgIDQ3IHwgW0VYSU1JTUVdICAgICAgICAgICAgICAgICAg IHwKICAgfCBhcHBsaWNhdGlvbi9mYXN0aW5mb3NldCAgICAgIHwgIDQ4IHwgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwKICAgfCBhcHBsaWNhdGlvbi9zb2FwK2Zhc3RpbmZvc2V0IHwgIDQ5 IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgfCBhcHBsaWNhdGlvbi9qc29uICAg ICAgICAgICAgIHwgIDUwIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgfCBhcHBs aWNhdGlvbi94LW9iaXgtYmluYXJ5ICAgIHwgIDUxIHwgW09CSVgxLjFdICAgICAgICAgICAgICAg ICAgIHwKICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLSstLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLSsKCiAgICAgICAgICAgICAgICAgICAgICAgICBUYWJsZSA4OiBD b0FQIE1lZGlhIFR5cGVzCgogICBUaGUgaWRlbnRpZmllcnMgYmV0d2VlbiAyMDEgYW5kIDI1NSBp bmNsdXNpdmUgYXJlIHJlc2VydmVkIGZvcgogICBQcml2YXRlIFVzZS4gVGhlIGlkZW50aWZpZXJz IGJldHdlZW4gMjU2IGFuZCA2NTUzNSBpbmNsdXNpdmUgYXJlCiAgIFJlc2VydmVkIGZvciBmdXR1 cmUgdXNlLiAgQWxsIG90aGVyIGlkZW50aWZpZXJzIGFyZSBVbmFzc2lnbmVkLgoKICAgQmVjYXVz ZSB0aGUgbmFtZSBzcGFjZSBpcyBzbyBzbWFsbCwgdGhlIElBTkEgcG9saWN5IGZvciBmdXR1cmUK ICAgYWRkaXRpb25zIHRvIHRoaXMgcmVnaXN0cnkgaXMgIkV4cGVydCBSZXZpZXciIGFzIGRlc2Ny aWJlZCBpbgogICBbUkZDNTIyNl0uCgogICBJbiBtYWNoaW5lIHRvIG1hY2hpbmUgYXBwbGljYXRp b25zLCBpdCBpcyBub3QgZXhwZWN0ZWQgdGhhdCBnZW5lcmljCiAgIEludGVybmV0IG1lZGlhIHR5 cGVzIHN1Y2ggYXMgdGV4dC9wbGFpbiwgYXBwbGljYXRpb24veG1sIG9yCiAgIGFwcGxpY2F0aW9u L29jdGV0LXN0cmVhbSBhcmUgdXNlZnVsIGZvciByZWFsIGFwcGxpY2F0aW9ucy4gIEl0IGlzCiAg IHJlY29tbWVuZGVkIHRoYXQgTTJNIGFwcGxpY2F0aW9ucyBtYWtpbmcgdXNlIG9mIENvQVAgd2ls bCByZXF1ZXN0IG5ldwogICBJbnRlcm5ldCBtZWRpYSB0eXBlcyBmcm9tIElBTkEgaW5kaWNhdGlu ZyBzZW1hbnRpYyBpbmZvcm1hdGlvbiBhYm91dAogICBob3cgdG8gY3JlYXRlIG9yIHBhcnNlIGEg cGF5bG9hZC4gIENvcnJlY3QgZXhhbXBsZXMgZnJvbSBUYWJsZSA4CiAgIGluY2x1ZGUgYXBwbGlj YXRpb24vbGluay1mb3JtYXQsIGFwcGxpY2F0aW9uL2F0b20reG1sIGFuZAoKCgpTaGVsYnksIGV0 IGFsLiAgICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDE1LCAyMDExICAgICAgICAgICAgICBbUGFn ZSA2MV0KDApJbnRlcm5ldC1EcmFmdCAgIENvbnN0cmFpbmVkIEFwcGxpY2F0aW9uIFByb3RvY29s IChDb0FQKSAgICAgIE1hcmNoIDIwMTEKCgogICBhcHBsaWNhdGlvbi94LW9iaXgtYmluYXJ5LiAg Rm9yIGV4YW1wbGUsIGEgU21hcnQgRW5lcmd5IGFwcGxpY2F0aW9uCiAgIHBheWxvYWQgY2Fycmll ZCBhcyBYTUwgd291bGQgcmVxdWVzdCBhIG1vcmUgc3BlY2lmaWMgdHlwZSBsaWtlCiAgIGFwcGxp Y2F0aW9uL3NlK3htbCBvciBhcHBsaWNhdGlvbi9zZStleGkuCgoxMS40LiAgVVJJIFNjaGVtZSBS ZWdpc3RyYXRpb24KCiAgIFRoaXMgZG9jdW1lbnQgcmVxdWVzdHMgdGhlIHJlZ2lzdHJhdGlvbiBv ZiB0aGUgVW5pZm9ybSBSZXNvdXJjZQogICBJZGVudGlmaWVyIChVUkkpIHNjaGVtZSAiY29hcCIu ICBUaGUgcmVnaXN0cmF0aW9uIHJlcXVlc3QgY29tcGxpZXMKICAgd2l0aCBbUkZDNDM5NV0uCgog ICBVUkkgc2NoZW1lIG5hbWUuCiAgICAgIGNvYXAKCiAgIFN0YXR1cy4KICAgICAgUGVybWFuZW50 LgoKICAgVVJJIHNjaGVtZSBzeW50YXguCiAgICAgIERlZmluZWQgaW4gU2VjdGlvbiA2LjEgb2Yg W1JGQ1hYWFhdLgoKICAgVVJJIHNjaGVtZSBzZW1hbnRpY3MuCiAgICAgIFRoZSAiY29hcCIgVVJJ IHNjaGVtZSBwcm92aWRlcyBhIHdheSB0byBpZGVudGlmeSByZXNvdXJjZXMgdGhhdAogICAgICBh cmUgcG90ZW50aWFsbHkgYWNjZXNzaWJsZSBvdmVyIHRoZSBDb25zdHJhaW5lZCBBcHBsaWNhdGlv bgogICAgICBQcm90b2NvbCAoQ29BUCkuICBUaGUgcmVzb3VyY2VzIGNhbiBiZSBsb2NhdGVkIGJ5 IGNvbnRhY3RpbmcgdGhlCiAgICAgIGdvdmVybmluZyBDb0FQIHNlcnZlciBhbmQgb3BlcmF0ZWQg b24gYnkgc2VuZGluZyBDb0FQIHJlcXVlc3RzIHRvCiAgICAgIHRoZSBzZXJ2ZXIuICBUaGlzIHNj aGVtZSBjYW4gdGh1cyBiZSBjb21wYXJlZCB0byB0aGUgImh0dHAiIFVSSQogICAgICBzY2hlbWUg W1JGQzI2MTZdLiAgU2VlIFNlY3Rpb24gNiBvZiBbUkZDWFhYWF0gZm9yIHRoZSBkZXRhaWxzIG9m CiAgICAgIG9wZXJhdGlvbi4KCiAgIEVuY29kaW5nIGNvbnNpZGVyYXRpb25zLgogICAgICBUaGUg c2NoZW1lIGVuY29kaW5nIGNvbmZvcm1zIHRvIHRoZSBlbmNvZGluZyBydWxlcyBlc3RhYmxpc2hl ZCBmb3IKICAgICAgVVJJcyBpbiBbUkZDMzk4Nl0sIGkuZS4gaW50ZXJuYXRpb25hbGl6ZWQgYW5k IHJlc2VydmVkIGNoYXJhY3RlcnMKICAgICAgYXJlIGV4cHJlc3NlZCB1c2luZyBVVEYtOC1iYXNl ZCBwZXJjZW50LWVuY29kaW5nLgoKICAgQXBwbGljYXRpb25zL3Byb3RvY29scyB0aGF0IHVzZSB0 aGlzIFVSSSBzY2hlbWUgbmFtZS4KICAgICAgVGhlIHNjaGVtZSBpcyB1c2VkIGJ5IENvQVAgZW5k LXBvaW50cyB0byBhY2Nlc3MgQ29BUCByZXNvdXJjZXMuCgogICBJbnRlcm9wZXJhYmlsaXR5IGNv bnNpZGVyYXRpb25zLgogICAgICBOb25lLgoKICAgU2VjdXJpdHkgY29uc2lkZXJhdGlvbnMuCiAg ICAgIFNlZSBTZWN0aW9uIDEwLjMuMSBvZiBbUkZDWFhYWF0uCgogICBDb250YWN0LgogICAgICBJ RVRGIENoYWlyIDxjaGFpckBpZXRmLm9yZz4KCgoKCgoKClNoZWxieSwgZXQgYWwuICAgICAgICAg RXhwaXJlcyBTZXB0ZW1iZXIgMTUsIDIwMTEgICAgICAgICAgICAgIFtQYWdlIDYyXQoMCkludGVy bmV0LURyYWZ0ICAgQ29uc3RyYWluZWQgQXBwbGljYXRpb24gUHJvdG9jb2wgKENvQVApICAgICAg TWFyY2ggMjAxMQoKCiAgIEF1dGhvci9DaGFuZ2UgY29udHJvbGxlci4KICAgICAgSUVTRyA8aWVz Z0BpZXRmLm9yZz4KCiAgIFJlZmVyZW5jZXMuCiAgICAgIFtSRkNYWFhYXQoKMTEuNS4gIFNlcnZp Y2UgTmFtZSBhbmQgUG9ydCBOdW1iZXIgUmVnaXN0cmF0aW9uCgogICBPbmUgb2YgdGhlIGZ1bmN0 aW9ucyBvZiBDb0FQIGlzIHJlc291cmNlIGRpc2NvdmVyeTogYSBDb0FQIGNsaWVudCBjYW4KICAg YXNrIGEgQ29BUCBzZXJ2ZXIgYWJvdXQgdGhlIHJlc291cmNlcyBvZmZlcmVkIGJ5IGl0IChzZWUK ICAgU2VjdGlvbiA3LjEpLiAgVG8gZW5hYmxlIHJlc291cmNlIGRpc2NvdmVyeSBqdXN0IGJhc2Vk IG9uIHRoZQogICBrbm93bGVkZ2Ugb2YgYW4gSVAgYWRkcmVzcywgdGhlIENvQVAgcG9ydCBmb3Ig cmVzb3VyY2UgZGlzY292ZXJ5CiAgIG5lZWRzIHRvIGJlIHN0YW5kYXJkaXplZC4KCiAgIFRoaXMg ZG9jdW1lbnQgcmVxdWVzdHMgdGhlIGFzc2lnbm1lbnQgb2YgdGhlIHBvcnQgbnVtYmVyIDU2ODMg YW5kIHRoZQogICBzZXJ2aWNlIG5hbWUgImNvYXAiLCBpbiBhY2NvcmRhbmNlIHdpdGggW0ktRC5p ZXRmLXRzdndnLWlhbmEtcG9ydHNdLgoKICAgQmVzaWRlcyB1bmljYXN0LCBDb0FQIGNhbiBiZSB1 c2VkIHdpdGggYm90aCBtdWx0aWNhc3QgYW5kIGFueWNhc3QuCgogICBTZXJ2aWNlIE5hbWUuCiAg ICAgIGNvYXAKCiAgIFRyYW5zcG9ydCBQcm90b2NvbC4KICAgICAgVURQCgogICBBc3NpZ25lZS4K ICAgICAgSUVTRyA8aWVzZ0BpZXRmLm9yZz4KCiAgIENvbnRhY3QuCiAgICAgIElFVEYgQ2hhaXIg PGNoYWlyQGlldGYub3JnPgoKICAgRGVzY3JpcHRpb24uCiAgICAgIENvbnN0cmFpbmVkIEFwcGxp Y2F0aW9uIFByb3RvY29sIChDb0FQKQoKICAgUmVmZXJlbmNlLgogICAgICBbUkZDWFhYWF0KCiAg IFBvcnQgTnVtYmVyLgogICAgICA1NjgzCgoKMTIuICBBY2tub3dsZWRnZW1lbnRzCgogICBTcGVj aWFsIHRoYW5rcyB0byBQZXRlciBCaWdvdCBhbmQgQ3VsbGVuIEplbm5pbmdzIGZvciBzdWJzdGFu dGlhbAogICBjb250cmlidXRpb25zIHRvIHRoZSBpZGVhcyBhbmQgdGV4dCBpbiB0aGUgZG9jdW1l bnQsIGFsb25nIHdpdGgKICAgY291bnRsZXNzIGRldGFpbGVkIHJldmlld3MgYW5kIGRpc2N1c3Np b25zLgoKICAgVGhhbmtzIHRvIE1pY2hhZWwgU3R1YmVyLCBSaWNoYXJkIEtlbHNleSwgR3VpZG8g TW9yaXR6LCBQZXRlciBWYW4gRGVyCgoKClNoZWxieSwgZXQgYWwuICAgICAgICAgRXhwaXJlcyBT ZXB0ZW1iZXIgMTUsIDIwMTEgICAgICAgICAgICAgIFtQYWdlIDYzXQoMCkludGVybmV0LURyYWZ0 ICAgQ29uc3RyYWluZWQgQXBwbGljYXRpb24gUHJvdG9jb2wgKENvQVApICAgICAgTWFyY2ggMjAx MQoKCiAgIFN0b2ssIEFkcmlhbm8gUGV6enV0bywgTGlzYSBEdXNzZWFsdCwgQWxleGV5IE1lbG5p a292LCBHaWxiZXJ0IENsYXJrLAogICBTYWx2YXRvcmUgTG9yZXRvLCBQZXRyaSBNdXRrYSwgU3p5 bW9uIFNhc2luLCBSb2JlcnQgUXVhdHRsZWJhdW0sCiAgIFJvYmVydCBDcmFnaWUsIEFuZ2VsbyBD YXN0ZWxsYW5pLCBUb20gSGVyYnN0LCBFZCBCZXJvc2V0LCBHaWxtYW4KICAgVG9sbGUsIFJvYmJ5 IFNpbXBzb24sIENvbGluIE8nRmx5bm4sIEVyaWMgUmVzY29ybGEsIE1hdHRoaWV1IFZpYWwsCiAg IExpbnlpIFRpYW4sIEtlcnJ5IEx5bm4sIERhbGUgU2VlZCwgQWtiYXIgUmFobWFuIGFuZCBEYXZp ZCBSeWFuIGZvcgogICBoZWxwZnVsIGNvbW1lbnRzIGFuZCBkaXNjdXNzaW9ucyB0aGF0IGhhdmUg c2hhcGVkIHRoZSBkb2N1bWVudC4KCiAgIFNvbWUgb2YgdGhlIHRleHQgaGFzIGJlZW4gbGlmdGVk IGZyb20gdGhlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZQogICBJRVRGIGh0dHBiaXMgd29ya2lu ZyBncm91cC4KCgoxMy4gIFJlZmVyZW5jZXMKCjEzLjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlcwoK ICAgW1JGQzIwNDZdICBGcmVlZCwgTi4gYW5kIE4uIEJvcmVuc3RlaW4sICJNdWx0aXB1cnBvc2Ug SW50ZXJuZXQgTWFpbAogICAgICAgICAgICAgIEV4dGVuc2lvbnMgKE1JTUUpIFBhcnQgVHdvOiBN ZWRpYSBUeXBlcyIsIFJGQyAyMDQ2LAogICAgICAgICAgICAgIE5vdmVtYmVyIDE5OTYuCgogICBb UkZDMjExOV0gIEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJbmRp Y2F0ZQogICAgICAgICAgICAgIFJlcXVpcmVtZW50IExldmVscyIsIEJDUCAxNCwgUkZDIDIxMTks IE1hcmNoIDE5OTcuCgogICBbUkZDMjYxNl0gIEZpZWxkaW5nLCBSLiwgR2V0dHlzLCBKLiwgTW9n dWwsIEouLCBGcnlzdHlrLCBILiwKICAgICAgICAgICAgICBNYXNpbnRlciwgTC4sIExlYWNoLCBQ LiwgYW5kIFQuIEJlcm5lcnMtTGVlLCAiSHlwZXJ0ZXh0CiAgICAgICAgICAgICAgVHJhbnNmZXIg UHJvdG9jb2wgLS0gSFRUUC8xLjEiLCBSRkMgMjYxNiwgSnVuZSAxOTk5LgoKICAgW1JGQzI4MThd ICBSZXNjb3JsYSwgRS4sICJIVFRQIE92ZXIgVExTIiwgUkZDIDI4MTgsIE1heSAyMDAwLgoKICAg W1JGQzM2MDJdICBGcmFua2VsLCBTLiwgR2xlbm4sIFIuLCBhbmQgUy4gS2VsbHksICJUaGUgQUVT LUNCQyBDaXBoZXIKICAgICAgICAgICAgICBBbGdvcml0aG0gYW5kIEl0cyBVc2Ugd2l0aCBJUHNl YyIsIFJGQyAzNjAyLAogICAgICAgICAgICAgIFNlcHRlbWJlciAyMDAzLgoKICAgW1JGQzM2Mjld ICBZZXJnZWF1LCBGLiwgIlVURi04LCBhIHRyYW5zZm9ybWF0aW9uIGZvcm1hdCBvZiBJU08KICAg ICAgICAgICAgICAxMDY0NiIsIFNURCA2MywgUkZDIDM2MjksIE5vdmVtYmVyIDIwMDMuCgogICBb UkZDMzk4Nl0gIEJlcm5lcnMtTGVlLCBULiwgRmllbGRpbmcsIFIuLCBhbmQgTC4gTWFzaW50ZXIs ICJVbmlmb3JtCiAgICAgICAgICAgICAgUmVzb3VyY2UgSWRlbnRpZmllciAoVVJJKTogR2VuZXJp YyBTeW50YXgiLCBTVEQgNjYsCiAgICAgICAgICAgICAgUkZDIDM5ODYsIEphbnVhcnkgMjAwNS4K CiAgIFtSRkM0Mjc5XSAgRXJvbmVuLCBQLiBhbmQgSC4gVHNjaG9mZW5pZywgIlByZS1TaGFyZWQg S2V5IENpcGhlcnN1aXRlcwogICAgICAgICAgICAgIGZvciBUcmFuc3BvcnQgTGF5ZXIgU2VjdXJp dHkgKFRMUykiLCBSRkMgNDI3OSwKICAgICAgICAgICAgICBEZWNlbWJlciAyMDA1LgoKICAgW1JG QzQzMDNdICBLZW50LCBTLiwgIklQIEVuY2Fwc3VsYXRpbmcgU2VjdXJpdHkgUGF5bG9hZCAoRVNQ KSIsCiAgICAgICAgICAgICAgUkZDIDQzMDMsIERlY2VtYmVyIDIwMDUuCgogICBbUkZDNDMwOV0g IEhvdXNsZXksIFIuLCAiVXNpbmcgQWR2YW5jZWQgRW5jcnlwdGlvbiBTdGFuZGFyZCAoQUVTKSBD Q00KICAgICAgICAgICAgICBNb2RlIHdpdGggSVBzZWMgRW5jYXBzdWxhdGluZyBTZWN1cml0eSBQ YXlsb2FkIChFU1ApIiwKCgoKU2hlbGJ5LCBldCBhbC4gICAgICAgICBFeHBpcmVzIFNlcHRlbWJl ciAxNSwgMjAxMSAgICAgICAgICAgICAgW1BhZ2UgNjRdCgwKSW50ZXJuZXQtRHJhZnQgICBDb25z dHJhaW5lZCBBcHBsaWNhdGlvbiBQcm90b2NvbCAoQ29BUCkgICAgICBNYXJjaCAyMDExCgoKICAg ICAgICAgICAgICBSRkMgNDMwOSwgRGVjZW1iZXIgMjAwNS4KCiAgIFtSRkM0MzQ3XSAgUmVzY29y bGEsIEUuIGFuZCBOLiBNb2RhZHVndSwgIkRhdGFncmFtIFRyYW5zcG9ydCBMYXllcgogICAgICAg ICAgICAgIFNlY3VyaXR5IiwgUkZDIDQzNDcsIEFwcmlsIDIwMDYuCgogICBbUkZDNDM5NV0gIEhh bnNlbiwgVC4sIEhhcmRpZSwgVC4sIGFuZCBMLiBNYXNpbnRlciwgIkd1aWRlbGluZXMgYW5kCiAg ICAgICAgICAgICAgUmVnaXN0cmF0aW9uIFByb2NlZHVyZXMgZm9yIE5ldyBVUkkgU2NoZW1lcyIs IEJDUCAzNSwKICAgICAgICAgICAgICBSRkMgNDM5NSwgRmVicnVhcnkgMjAwNi4KCiAgIFtSRkM0 NjQ4XSAgSm9zZWZzc29uLCBTLiwgIlRoZSBCYXNlMTYsIEJhc2UzMiwgYW5kIEJhc2U2NCBEYXRh CiAgICAgICAgICAgICAgRW5jb2RpbmdzIiwgUkZDIDQ2NDgsIE9jdG9iZXIgMjAwNi4KCiAgIFtS RkM0ODM1XSAgTWFucmFsLCBWLiwgIkNyeXB0b2dyYXBoaWMgQWxnb3JpdGhtIEltcGxlbWVudGF0 aW9uCiAgICAgICAgICAgICAgUmVxdWlyZW1lbnRzIGZvciBFbmNhcHN1bGF0aW5nIFNlY3VyaXR5 IFBheWxvYWQgKEVTUCkgYW5kCiAgICAgICAgICAgICAgQXV0aGVudGljYXRpb24gSGVhZGVyIChB SCkiLCBSRkMgNDgzNSwgQXByaWwgMjAwNy4KCiAgIFtSRkM1MTk4XSAgS2xlbnNpbiwgSi4gYW5k IE0uIFBhZGxpcHNreSwgIlVuaWNvZGUgRm9ybWF0IGZvciBOZXR3b3JrCiAgICAgICAgICAgICAg SW50ZXJjaGFuZ2UiLCBSRkMgNTE5OCwgTWFyY2ggMjAwOC4KCiAgIFtSRkM1MjI2XSAgTmFydGVu LCBULiBhbmQgSC4gQWx2ZXN0cmFuZCwgIkd1aWRlbGluZXMgZm9yIFdyaXRpbmcgYW4KICAgICAg ICAgICAgICBJQU5BIENvbnNpZGVyYXRpb25zIFNlY3Rpb24gaW4gUkZDcyIsIEJDUCAyNiwgUkZD IDUyMjYsCiAgICAgICAgICAgICAgTWF5IDIwMDguCgogICBbUkZDNTIzNF0gIENyb2NrZXIsIEQu IGFuZCBQLiBPdmVyZWxsLCAiQXVnbWVudGVkIEJORiBmb3IgU3ludGF4CiAgICAgICAgICAgICAg U3BlY2lmaWNhdGlvbnM6IEFCTkYiLCBTVEQgNjgsIFJGQyA1MjM0LCBKYW51YXJ5IDIwMDguCgog ICBbUkZDNTI0Nl0gIERpZXJrcywgVC4gYW5kIEUuIFJlc2NvcmxhLCAiVGhlIFRyYW5zcG9ydCBM YXllciBTZWN1cml0eQogICAgICAgICAgICAgIChUTFMpIFByb3RvY29sIFZlcnNpb24gMS4yIiwg UkZDIDUyNDYsIEF1Z3VzdCAyMDA4LgoKICAgW1JGQzUyODBdICBDb29wZXIsIEQuLCBTYW50ZXNz b24sIFMuLCBGYXJyZWxsLCBTLiwgQm9leWVuLCBTLiwKICAgICAgICAgICAgICBIb3VzbGV5LCBS LiwgYW5kIFcuIFBvbGssICJJbnRlcm5ldCBYLjUwOSBQdWJsaWMgS2V5CiAgICAgICAgICAgICAg SW5mcmFzdHJ1Y3R1cmUgQ2VydGlmaWNhdGUgYW5kIENlcnRpZmljYXRlIFJldm9jYXRpb24gTGlz dAogICAgICAgICAgICAgIChDUkwpIFByb2ZpbGUiLCBSRkMgNTI4MCwgTWF5IDIwMDguCgogICBb UkZDNTM4OV0gIFJvc2VuYmVyZywgSi4sIE1haHksIFIuLCBNYXR0aGV3cywgUC4sIGFuZCBELiBX aW5nLAogICAgICAgICAgICAgICJTZXNzaW9uIFRyYXZlcnNhbCBVdGlsaXRpZXMgZm9yIE5BVCAo U1RVTikiLCBSRkMgNTM4OSwKICAgICAgICAgICAgICBPY3RvYmVyIDIwMDguCgogICBbUkZDNTc4 NV0gIE5vdHRpbmdoYW0sIE0uIGFuZCBFLiBIYW1tZXItTGFoYXYsICJEZWZpbmluZyBXZWxsLUtu b3duCiAgICAgICAgICAgICAgVW5pZm9ybSBSZXNvdXJjZSBJZGVudGlmaWVycyAoVVJJcykiLCBS RkMgNTc4NSwKICAgICAgICAgICAgICBBcHJpbCAyMDEwLgoKICAgW1JGQzU5NTJdICBLYXdhbXVy YSwgUy4gYW5kIE0uIEthd2FzaGltYSwgIkEgUmVjb21tZW5kYXRpb24gZm9yIElQdjYKICAgICAg ICAgICAgICBBZGRyZXNzIFRleHQgUmVwcmVzZW50YXRpb24iLCBSRkMgNTk1MiwgQXVndXN0IDIw MTAuCgogICBbUkZDNTk5Nl0gIEthdWZtYW4sIEMuLCBIb2ZmbWFuLCBQLiwgTmlyLCBZLiwgYW5k IFAuIEVyb25lbiwKICAgICAgICAgICAgICAiSW50ZXJuZXQgS2V5IEV4Y2hhbmdlIFByb3RvY29s IFZlcnNpb24gMiAoSUtFdjIpIiwKICAgICAgICAgICAgICBSRkMgNTk5NiwgU2VwdGVtYmVyIDIw MTAuCgoKClNoZWxieSwgZXQgYWwuICAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMTUsIDIwMTEg ICAgICAgICAgICAgIFtQYWdlIDY1XQoMCkludGVybmV0LURyYWZ0ICAgQ29uc3RyYWluZWQgQXBw bGljYXRpb24gUHJvdG9jb2wgKENvQVApICAgICAgTWFyY2ggMjAxMQoKCiAgIFtSRkM2MDY2XSAg RWFzdGxha2UsIEQuLCAiVHJhbnNwb3J0IExheWVyIFNlY3VyaXR5IChUTFMpIEV4dGVuc2lvbnM6 CiAgICAgICAgICAgICAgRXh0ZW5zaW9uIERlZmluaXRpb25zIiwgUkZDIDYwNjYsIEphbnVhcnkg MjAxMS4KCjEzLjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzCgogICBbRVVJNjRdICAgICJHVUlE RUxJTkVTIEZPUiA2NC1CSVQgR0xPQkFMIElERU5USUZJRVIgKEVVSS02NCkKICAgICAgICAgICAg ICBSRUdJU1RSQVRJT04gQVVUSE9SSVRZIiwgQXByaWwgMjAxMCwgPGh0dHA6Ly8KICAgICAgICAg ICAgICBzdGFuZGFyZHMuaWVlZS5vcmcvcmVnYXV0aC9vdWkvdHV0b3JpYWxzL0VVSTY0Lmh0bWw+ LgoKICAgW0VYSU1JTUVdICAiRWZmaWNpZW50IFhNTCBJbnRlcmNoYW5nZSAoRVhJKSBGb3JtYXQg MS4wIiwKICAgICAgICAgICAgICBEZWNlbWJlciAyMDA5LCA8aHR0cDovL3d3dy53My5vcmcvVFIv MjAwOS8KICAgICAgICAgICAgICBDUi1leGktMjAwOTEyMDgvI21lZGlhVHlwZVJlZ2lzdHJhdGlv bj4uCgogICBbSS1ELmVnZ2VydC1jb3JlLWNvbmdlc3Rpb24tY29udHJvbF0KICAgICAgICAgICAg ICBFZ2dlcnQsIEwuLCAiQ29uZ2VzdGlvbiBDb250cm9sIGZvciB0aGUgQ29uc3RyYWluZWQKICAg ICAgICAgICAgICBBcHBsaWNhdGlvbiBQcm90b2NvbCAoQ29BUCkiLAogICAgICAgICAgICAgIGRy YWZ0LWVnZ2VydC1jb3JlLWNvbmdlc3Rpb24tY29udHJvbC0wMSAod29yayBpbgogICAgICAgICAg ICAgIHByb2dyZXNzKSwgSmFudWFyeSAyMDExLgoKICAgW0ktRC5pZXRmLWNvcmUtYmxvY2tdCiAg ICAgICAgICAgICAgU2hlbGJ5LCBaLiBhbmQgQy4gQm9ybWFubiwgIkJsb2Nrd2lzZSB0cmFuc2Zl cnMgaW4gQ29BUCIsCiAgICAgICAgICAgICAgZHJhZnQtaWV0Zi1jb3JlLWJsb2NrLTAxICh3b3Jr IGluIHByb2dyZXNzKSwgSmFudWFyeSAyMDExLgoKICAgW0ktRC5pZXRmLWNvcmUtbGluay1mb3Jt YXRdCiAgICAgICAgICAgICAgU2hlbGJ5LCBaLiwgIkNvUkUgTGluayBGb3JtYXQiLAogICAgICAg ICAgICAgIGRyYWZ0LWlldGYtY29yZS1saW5rLWZvcm1hdC0wMiAod29yayBpbiBwcm9ncmVzcyks CiAgICAgICAgICAgICAgRGVjZW1iZXIgMjAxMC4KCiAgIFtJLUQuaWV0Zi10bHMtcmZjNDM0Ny1i aXNdCiAgICAgICAgICAgICAgUmVzY29ybGEsIEUuIGFuZCBOLiBNb2RhZHVndSwgIkRhdGFncmFt IFRyYW5zcG9ydCBMYXllcgogICAgICAgICAgICAgIFNlY3VyaXR5IHZlcnNpb24gMS4yIiwgZHJh ZnQtaWV0Zi10bHMtcmZjNDM0Ny1iaXMtMDQgKHdvcmsKICAgICAgICAgICAgICBpbiBwcm9ncmVz cyksIEp1bHkgMjAxMC4KCiAgIFtJLUQuaWV0Zi10c3Z3Zy1pYW5hLXBvcnRzXQogICAgICAgICAg ICAgIENvdHRvbiwgTS4sIEVnZ2VydCwgTC4sIFRvdWNoLCBKLiwgV2VzdGVybHVuZCwgTS4sIGFu ZCBTLgogICAgICAgICAgICAgIENoZXNoaXJlLCAiSW50ZXJuZXQgQXNzaWduZWQgTnVtYmVycyBB dXRob3JpdHkgKElBTkEpCiAgICAgICAgICAgICAgUHJvY2VkdXJlcyBmb3IgdGhlIE1hbmFnZW1l bnQgb2YgdGhlIFNlcnZpY2UgTmFtZSBhbmQKICAgICAgICAgICAgICBUcmFuc3BvcnQgUHJvdG9j b2wgUG9ydCBOdW1iZXIgUmVnaXN0cnkiLAogICAgICAgICAgICAgIGRyYWZ0LWlldGYtdHN2d2ct aWFuYS1wb3J0cy0xMCAod29yayBpbiBwcm9ncmVzcyksCiAgICAgICAgICAgICAgRmVicnVhcnkg MjAxMS4KCiAgIFtJLUQubWNncmV3LXRscy1hZXMtY2NtXQogICAgICAgICAgICAgIE1jR3Jldywg RC4gYW5kIEQuIEJhaWxleSwgIkFFUy1DQ00gQ2lwaGVyIFN1aXRlcyBmb3IgVExTIiwKICAgICAg ICAgICAgICBkcmFmdC1tY2dyZXctdGxzLWFlcy1jY20tMDEgKHdvcmsgaW4gcHJvZ3Jlc3MpLAog ICAgICAgICAgICAgIE1hcmNoIDIwMTEuCgogICBbSS1ELm1jZ3Jldy10bHMtYWVzLWNjbS1lY2Nd CiAgICAgICAgICAgICAgTWNHcmV3LCBELiwgQmFpbGV5LCBELiwgQ2FtcGFnbmEsIE0uLCBhbmQg Ui4gRHVnYWwsICJBRVMtCgoKClNoZWxieSwgZXQgYWwuICAgICAgICAgRXhwaXJlcyBTZXB0ZW1i ZXIgMTUsIDIwMTEgICAgICAgICAgICAgIFtQYWdlIDY2XQoMCkludGVybmV0LURyYWZ0ICAgQ29u c3RyYWluZWQgQXBwbGljYXRpb24gUHJvdG9jb2wgKENvQVApICAgICAgTWFyY2ggMjAxMQoKCiAg ICAgICAgICAgICAgQ0NNIEVDQyBDaXBoZXIgU3VpdGVzIGZvciBUTFMiLAogICAgICAgICAgICAg IGRyYWZ0LW1jZ3Jldy10bHMtYWVzLWNjbS1lY2MtMDEgKHdvcmsgaW4gcHJvZ3Jlc3MpLAogICAg ICAgICAgICAgIEphbnVhcnkgMjAxMS4KCiAgIFtJLUQub2ZseW5uLWNvcmUtYm9vdHN0cmFwcGlu Z10KICAgICAgICAgICAgICBTYXJpa2F5YSwgQi4sIE9oYmEsIFkuLCBDYW8sIFouLCBhbmQgUi4g Q3JhZ2llLCAiU2VjdXJpdHkKICAgICAgICAgICAgICBCb290c3RyYXBwaW5nIG9mIFJlc291cmNl LUNvbnN0cmFpbmVkIERldmljZXMiLAogICAgICAgICAgICAgIGRyYWZ0LW9mbHlubi1jb3JlLWJv b3RzdHJhcHBpbmctMDMgKHdvcmsgaW4gcHJvZ3Jlc3MpLAogICAgICAgICAgICAgIE5vdmVtYmVy IDIwMTAuCgogICBbT0JJWDEuMV0gICJPQklYIFZlcnNpb24gMS4xIiwgSnVuZSAyMDEwLCA8aHR0 cDovL3d3dy5vYXNpcy1vcGVuLm9yZy8KICAgICAgICAgICAgICBjb21taXR0ZWVzL2Rvd25sb2Fk LnBocC8zODIxMi9vQklYLTEtMS1zcGVjLXdkMDYucGRmPi4KCiAgIFtSRkMzMjY0XSAgUm9zZW5i ZXJnLCBKLiBhbmQgSC4gU2NodWx6cmlubmUsICJBbiBPZmZlci9BbnN3ZXIgTW9kZWwKICAgICAg ICAgICAgICB3aXRoIFNlc3Npb24gRGVzY3JpcHRpb24gUHJvdG9jb2wgKFNEUCkiLCBSRkMgMzI2 NCwKICAgICAgICAgICAgICBKdW5lIDIwMDIuCgogICBbUkZDMzU0Ml0gIFN0ZXZlbnMsIFcuLCBU aG9tYXMsIE0uLCBOb3JkbWFyaywgRS4sIGFuZCBULiBKaW5tZWksCiAgICAgICAgICAgICAgIkFk dmFuY2VkIFNvY2tldHMgQXBwbGljYXRpb24gUHJvZ3JhbSBJbnRlcmZhY2UgKEFQSSkgZm9yCiAg ICAgICAgICAgICAgSVB2NiIsIFJGQyAzNTQyLCBNYXkgMjAwMy4KCiAgIFtSRkMzOTIwXSAgU2Fp bnQtQW5kcmUsIFAuLCBFZC4sICJFeHRlbnNpYmxlIE1lc3NhZ2luZyBhbmQgUHJlc2VuY2UKICAg ICAgICAgICAgICBQcm90b2NvbCAoWE1QUCk6IENvcmUiLCBSRkMgMzkyMCwgT2N0b2JlciAyMDA0 LgoKICAgW1JGQzQ5NDRdICBNb250ZW5lZ3JvLCBHLiwgS3VzaGFsbmFnYXIsIE4uLCBIdWksIEou LCBhbmQgRC4gQ3VsbGVyLAogICAgICAgICAgICAgICJUcmFuc21pc3Npb24gb2YgSVB2NiBQYWNr ZXRzIG92ZXIgSUVFRSA4MDIuMTUuNAogICAgICAgICAgICAgIE5ldHdvcmtzIiwgUkZDIDQ5NDQs IFNlcHRlbWJlciAyMDA3LgoKCkFwcGVuZGl4IEEuICBJbnRlZ2VyIE9wdGlvbiBWYWx1ZSBGb3Jt YXQKCiAgIE9wdGlvbnMgb2YgdHlwZSB1aW50IGNvbnRhaW4gYSBub24tbmVnYXRpdmUgaW50ZWdl ciB0aGF0IGlzCiAgIHJlcHJlc2VudGVkIGluIG5ldHdvcmsgYnl0ZSBvcmRlciB1c2luZyBhIHZh cmlhYmxlIG51bWJlciBvZiBieXRlcywKICAgYXMgc2hvd24gaW4gRmlndXJlIDExLgoKCgoKCgoK CgoKCgoKCgoKClNoZWxieSwgZXQgYWwuICAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMTUsIDIw MTEgICAgICAgICAgICAgIFtQYWdlIDY3XQoMCkludGVybmV0LURyYWZ0ICAgQ29uc3RyYWluZWQg QXBwbGljYXRpb24gUHJvdG9jb2wgKENvQVApICAgICAgTWFyY2ggMjAxMQoKCiAgIExlbmd0aCA9 IDAgICAgIChpbXBsaWVzIHZhbHVlIG9mIDApCgogICAgICAgICAgICAgICAgICAgMAogICAgICAg ICAgICAgICAgICAgMCAxIDIgMyA0IDUgNiA3CiAgICAgICAgICAgICAgICAgICstKy0rLSstKy0r LSstKy0rCiAgIExlbmd0aCA9IDEgICAgIHwgICAgIDAtMjU1ICAgICB8CiAgICAgICAgICAgICAg ICAgICstKy0rLSstKy0rLSstKy0rCgogICAgICAgICAgICAgICAgICAgMCAgICAgICAgICAgICAg ICAgICAxCiAgICAgICAgICAgICAgICAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1 CiAgICAgICAgICAgICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICBM ZW5ndGggPSAyICAgICB8ICAgICAgICAgICAgMC02NTUzNSAgICAgICAgICAgIHwKICAgICAgICAg ICAgICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCgogICBMZW5ndGggPSAz IGlzIDI0IGJpdHMsIExlbmd0aCA9IDQgaXMgMzIgYml0cyBldGMuCgogICAgICAgICAgICBGaWd1 cmUgMTE6IFZhcmlhYmxlLWxlbmd0aCB1bnNpZ25lZCBpbnRlZ2VyIGZvcm1hdAoKCkFwcGVuZGl4 IEIuICBFeGFtcGxlcwoKICAgVGhpcyBzZWN0aW9uIGdpdmVzIGEgbnVtYmVyIG9mIHNob3J0IGV4 YW1wbGVzIHdpdGggbWVzc2FnZSBmbG93cyBmb3IKICAgR0VUIHJlcXVlc3RzLiAgVGhlc2UgZXhh bXBsZXMgZGVtb25zdHJhdGUgdGhlIGJhc2ljIG9wZXJhdGlvbiwgdGhlCiAgIG9wZXJhdGlvbiBp biB0aGUgcHJlc2VuY2Ugb2YgcmV0cmFuc21pc3Npb25zLCBhbmQgbXVsdGljYXN0LgoKICAgRmln dXJlIDEyIHNob3dzIGEgYmFzaWMgR0VUIHJlcXVlc3QgY2F1c2luZyBhIHBpZ2d5LWJhY2tlZCBy ZXNwb25zZToKICAgVGhlIGNsaWVudCBzZW5kcyBhIENvbmZpcm1hYmxlIEdFVCByZXF1ZXN0IGZv ciB0aGUgcmVzb3VyY2UKICAgY29hcDovL3NlcnZlci90ZW1wZXJhdHVyZSB0byB0aGUgc2VydmVy IHdpdGggYSBNZXNzYWdlIElEIG9mIDB4N2QzNC4KICAgVGhlIHJlcXVlc3QgaW5jbHVkZXMgb25l IFVyaS1QYXRoIE9wdGlvbiAoRGVsdGEgMCArIDkgPSA5LCBMZW5ndGggMTEsCiAgIFZhbHVlICJ0 ZW1wZXJhdHVyZSIpOyB0aGUgVG9rZW4gaXMgbGVmdCBhdCBpdHMgZGVmYXVsdCB2YWx1ZSAoZW1w dHkpLgogICBUaGlzIHJlcXVlc3QgaXMgYSB0b3RhbCBvZiAxNiBieXRlcyBsb25nLiAgQSAyLjA1 IChDb250ZW50KSByZXNwb25zZQogICBpcyByZXR1cm5lZCBpbiB0aGUgQWNrbm93bGVkZ2VtZW50 IG1lc3NhZ2UgdGhhdCBhY2tub3dsZWRnZXMgdGhlCiAgIENvbmZpcm1hYmxlIHJlcXVlc3QsIGVj aG9pbmcgYm90aCB0aGUgTWVzc2FnZSBJRCAweDdkMzQgYW5kIHRoZQogICAoaW1wbGljaXRseSBl bXB0eSkgVG9rZW4gdmFsdWUuICBUaGUgcmVzcG9uc2UgaW5jbHVkZXMgYSBQYXlsb2FkIG9mCiAg ICIyMi4zIEMiIGFuZCBpcyAxMCBieXRlcyBsb25nLgoKCgoKCgoKCgoKCgoKCgoKU2hlbGJ5LCBl dCBhbC4gICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAxNSwgMjAxMSAgICAgICAgICAgICAgW1Bh Z2UgNjhdCgwKSW50ZXJuZXQtRHJhZnQgICBDb25zdHJhaW5lZCBBcHBsaWNhdGlvbiBQcm90b2Nv bCAoQ29BUCkgICAgICBNYXJjaCAyMDExCgoKICAgQ2xpZW50ICBTZXJ2ZXIKICAgICAgfCAgICAg IHwKICAgICAgfCAgICAgIHwKICAgICAgKy0tLS0tPnwgICAgIEhlYWRlcjogR0VUIChUPUNPTiwg Q29kZT0xLCBNSUQ9MHg3ZDM0KQogICAgICB8IEdFVCAgfCAgIFVyaS1QYXRoOiAidGVtcGVyYXR1 cmUiCiAgICAgIHwgICAgICB8CiAgICAgIHwgICAgICB8CiAgICAgIHw8LS0tLS0rICAgICBIZWFk ZXI6IDIuMDUgQ29udGVudCAoVD1BQ0ssIENvZGU9NjksIE1JRD0weDdkMzQpCiAgICAgIHwgMi4w NSB8ICAgIFBheWxvYWQ6ICIyMi4zIEMiCiAgICAgIHwgICAgICB8CgoKICAgIDAgICAgICAgICAg ICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMKICAgIDAg MSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5 IDAgMQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKwogICB8IDEgfCAwIHwgICAxICAgfCAgICAgR0VUPTEgICAgIHwgICAg ICAgICAgTUlEPTB4N2QzNCAgICAgICAgICAgfAogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICB8ICAgOSAgIHwgIDEx ICAgfCAgICAgICJ0ZW1wZXJhdHVyZSIgKDExIEIpIC4uLgogICArLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwoKICAgIDAgICAg ICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMK ICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2 IDcgOCA5IDAgMQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKwogICB8IDEgfCAyIHwgICAwICAgfCAgICAyLjA1PTY5ICAg IHwgICAgICAgICAgTUlEPTB4N2QzNCAgICAgICAgICAgfAogICArLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICB8ICAgICAg IjIyLjMgQyIgKDYgQikgLi4uCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCgogICAgICAgICAgIEZpZ3VyZSAxMjogQ29u ZmlybWFibGUgcmVxdWVzdDsgcGlnZ3ktYmFja2VkIHJlc3BvbnNlCgogICBGaWd1cmUgMTMgc2hv d3MgYSBzaW1pbGFyIGV4YW1wbGUsIGJ1dCB3aXRoIHRoZSBpbmNsdXNpb24gb2YgYW4KICAgZXhw bGljaXQgVG9rZW4gT3B0aW9uIChEZWx0YSA5ICsgMiA9IDExLCBMZW5ndGggMSwgVmFsdWUgMHgy MCkgaW4gdGhlCiAgIHJlcXVlc3QgYW5kIChEZWx0YSAxMSArIDAgPSAxMSkgaW4gdGhlIHJlc3Bv bnNlLCBpbmNyZWFzaW5nIHRoZSBzaXplcwogICB0byAxOCBhbmQgMTIgYnl0ZXMsIHJlc3BlY3Rp dmVseS4KCgoKCgoKCgoKCgoKCgoKCgpTaGVsYnksIGV0IGFsLiAgICAgICAgIEV4cGlyZXMgU2Vw dGVtYmVyIDE1LCAyMDExICAgICAgICAgICAgICBbUGFnZSA2OV0KDApJbnRlcm5ldC1EcmFmdCAg IENvbnN0cmFpbmVkIEFwcGxpY2F0aW9uIFByb3RvY29sIChDb0FQKSAgICAgIE1hcmNoIDIwMTEK CgogICBDbGllbnQgIFNlcnZlcgogICAgICB8ICAgICAgfAogICAgICB8ICAgICAgfAogICAgICAr LS0tLS0+fCAgICAgSGVhZGVyOiBHRVQgKFQ9Q09OLCBDb2RlPTEsIE1JRD0weDdkMzUpCiAgICAg IHwgR0VUICB8ICAgICAgVG9rZW46IDB4MjAKICAgICAgfCAgICAgIHwgICBVcmktUGF0aDogInRl bXBlcmF0dXJlIgogICAgICB8ICAgICAgfAogICAgICB8ICAgICAgfAogICAgICB8PC0tLS0tKyAg ICAgSGVhZGVyOiAyLjA1IENvbnRlbnQgKFQ9QUNLLCBDb2RlPTY5LCBNSUQ9MHg3ZDM1KQogICAg ICB8IDIuMDUgfCAgICAgIFRva2VuOiAweDIwCiAgICAgIHwgICAgICB8ICAgIFBheWxvYWQ6ICIy Mi4zIEMiCiAgICAgIHwgICAgICB8CgoKICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAg ICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMKICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkg MCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQogICArLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwog ICB8IDEgfCAwIHwgICAyICAgfCAgICAgR0VUPTEgICAgIHwgICAgICAgICAgTUlEPTB4N2QzNCAg ICAgICAgICAgfAogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKwogICB8ICAgOSAgIHwgIDExICAgfCAgICAgICJ0ZW1wZXJh dHVyZSIgKDExIEIpIC4uLgogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICB8ICAgMiAgIHwgICAxICAgfCAgICAgMHgy MCAgICAgIHwKICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCgoKICAgIDAgICAg ICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMK ICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2 IDcgOCA5IDAgMQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKwogICB8IDEgfCAyIHwgICAxICAgfCAgICAyLjA1PTY5ICAg IHwgICAgICAgICAgTUlEPTB4N2QzNCAgICAgICAgICAgfAogICArLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICB8ICAxMSAg IHwgICAxICAgfCAgICAgMHgyMCAgICAgIHwgICAgICAiMjIuMyBDIiAoNiBCKSAuLi4KICAgKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSsKCiAgICAgICAgICAgRmlndXJlIDEzOiBDb25maXJtYWJsZSByZXF1ZXN0OyBwaWdneS1i YWNrZWQgcmVzcG9uc2UKCiAgIEluIEZpZ3VyZSAxNCwgdGhlIENvbmZpcm1hYmxlIEdFVCByZXF1 ZXN0IGlzIGxvc3QuICBBZnRlcgogICBSRVNQT05TRV9USU1FT1VUIHNlY29uZHMsIHRoZSBjbGll bnQgcmV0cmFuc21pdHMgdGhlIHJlcXVlc3QsCiAgIHJlc3VsdGluZyBpbiBhIHBpZ2d5LWJhY2tl ZCByZXNwb25zZSBhcyBpbiB0aGUgcHJldmlvdXMgZXhhbXBsZS4KCgoKCgoKCgoKCgoKClNoZWxi eSwgZXQgYWwuICAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMTUsIDIwMTEgICAgICAgICAgICAg IFtQYWdlIDcwXQoMCkludGVybmV0LURyYWZ0ICAgQ29uc3RyYWluZWQgQXBwbGljYXRpb24gUHJv dG9jb2wgKENvQVApICAgICAgTWFyY2ggMjAxMQoKCiAgIENsaWVudCAgU2VydmVyCiAgICAgIHwg ICAgICB8CiAgICAgIHwgICAgICB8CiAgICAgICstLS0tWCB8ICAgICBIZWFkZXI6IEdFVCAoVD1D T04sIENvZGU9MSwgTUlEPTB4N2QzNikKICAgICAgfCBHRVQgIHwgICAgICBUb2tlbjogMHgzMQog ICAgICB8ICAgICAgfCAgIFVyaS1QYXRoOiAidGVtcGVyYXR1cmUiCiAgIFRJTUVPVVQgICB8CiAg ICAgIHwgICAgICB8CiAgICAgICstLS0tLT58ICAgICBIZWFkZXI6IEdFVCAoVD1DT04sIENvZGU9 MSwgTUlEPTB4N2QzNikKICAgICAgfCBHRVQgIHwgICAgICBUb2tlbjogMHgzMQogICAgICB8ICAg ICAgfCAgIFVyaS1QYXRoOiAidGVtcGVyYXR1cmUiCiAgICAgIHwgICAgICB8CiAgICAgIHwgICAg ICB8CiAgICAgIHw8LS0tLS0rICAgICBIZWFkZXI6IDIuMDUgQ29udGVudCAoVD1BQ0ssIENvZGU9 NjksIE1JRD0weDdkMzYpCiAgICAgIHwgMi4wNSB8ICAgICAgVG9rZW46IDB4MzEKICAgICAgfCAg ICAgIHwgICAgUGF5bG9hZDogIjIyLjMgQyIKICAgICAgfCAgICAgIHwKCiAgIEZpZ3VyZSAxNDog Q29uZmlybWFibGUgcmVxdWVzdCAocmV0cmFuc21pdHRlZCk7IHBpZ2d5LWJhY2tlZCByZXNwb25z ZQoKICAgSW4gRmlndXJlIDE1LCB0aGUgZmlyc3QgQWNrbm93bGVkZ2VtZW50IG1lc3NhZ2UgZnJv bSB0aGUgc2VydmVyIHRvCiAgIHRoZSBjbGllbnQgaXMgbG9zdC4gIEFmdGVyIFJFU1BPTlNFX1RJ TUVPVVQgc2Vjb25kcywgdGhlIGNsaWVudAogICByZXRyYW5zbWl0cyB0aGUgcmVxdWVzdC4KCiAg IENsaWVudCAgU2VydmVyCiAgICAgIHwgICAgICB8CiAgICAgIHwgICAgICB8CiAgICAgICstLS0t LT58ICAgICBIZWFkZXI6IEdFVCAoVD1DT04sIENvZGU9MSwgTUlEPTB4N2QzNykKICAgICAgfCBH RVQgIHwgICAgICBUb2tlbjogMHg0MgogICAgICB8ICAgICAgfCAgIFVyaS1QYXRoOiAidGVtcGVy YXR1cmUiCiAgICAgIHwgICAgICB8CiAgICAgIHwgICAgICB8CiAgICAgIHwgWC0tLS0rICAgICBI ZWFkZXI6IDIuMDUgQ29udGVudCAoVD1BQ0ssIENvZGU9NjksIE1JRD0weDdkMzcpCiAgICAgIHwg Mi4wNSB8ICAgICAgVG9rZW46IDB4NDIKICAgICAgfCAgICAgIHwgICAgUGF5bG9hZDogIjIyLjMg QyIKICAgVElNRU9VVCAgIHwKICAgICAgfCAgICAgIHwKICAgICAgKy0tLS0tPnwgICAgIEhlYWRl cjogR0VUIChUPUNPTiwgQ29kZT0xLCBNSUQ9MHg3ZDM3KQogICAgICB8IEdFVCAgfCAgICAgIFRv a2VuOiAweDQyCiAgICAgIHwgICAgICB8ICAgVXJpLVBhdGg6ICJ0ZW1wZXJhdHVyZSIKICAgICAg fCAgICAgIHwKICAgICAgfCAgICAgIHwKICAgICAgfDwtLS0tLSsgICAgIEhlYWRlcjogMi4wNSBD b250ZW50IChUPUFDSywgQ29kZT02OSwgTUlEPTB4N2QzNykKICAgICAgfCAyLjA1IHwgICAgICBU b2tlbjogMHg0MgogICAgICB8ICAgICAgfCAgICBQYXlsb2FkOiAiMjIuMyBDIgogICAgICB8ICAg ICAgfAoKICAgRmlndXJlIDE1OiBDb25maXJtYWJsZSByZXF1ZXN0OyBwaWdneS1iYWNrZWQgcmVz cG9uc2UgKHJldHJhbnNtaXR0ZWQpCgoKClNoZWxieSwgZXQgYWwuICAgICAgICAgRXhwaXJlcyBT ZXB0ZW1iZXIgMTUsIDIwMTEgICAgICAgICAgICAgIFtQYWdlIDcxXQoMCkludGVybmV0LURyYWZ0 ICAgQ29uc3RyYWluZWQgQXBwbGljYXRpb24gUHJvdG9jb2wgKENvQVApICAgICAgTWFyY2ggMjAx MQoKCiAgIEluIEZpZ3VyZSAxNiwgdGhlIHNlcnZlciBhY2tub3dsZWRnZXMgdGhlIENvbmZpcm1h YmxlIHJlcXVlc3QgYW5kCiAgIHNlbmRzIGEgMi4wNSAoQ29udGVudCkgcmVzcG9uc2Ugc2VwYXJh dGVseSBpbiBhIENvbmZpcm1hYmxlIG1lc3NhZ2UuCiAgIE5vdGUgdGhhdCB0aGUgQWNrbm93bGVk Z2VtZW50IG1lc3NhZ2UgYW5kIHRoZSBDb25maXJtYWJsZSByZXNwb25zZSBkbwogICBub3QgbmVj ZXNzYXJpbHkgYXJyaXZlIGluIHRoZSBzYW1lIG9yZGVyIGFzIHRoZXkgd2VyZSBzZW50LiAgVGhl CiAgIGNsaWVudCBhY2tub3dsZWRnZXMgdGhlIENvbmZpcm1hYmxlIHJlc3BvbnNlLgoKICAgQ2xp ZW50ICBTZXJ2ZXIKICAgICAgfCAgICAgIHwKICAgICAgfCAgICAgIHwKICAgICAgKy0tLS0tPnwg ICAgIEhlYWRlcjogR0VUIChUPUNPTiwgQ29kZT0xLCBNSUQ9MHg3ZDM4KQogICAgICB8IEdFVCAg fCAgICAgIFRva2VuOiAweDUzCiAgICAgIHwgICAgICB8ICAgVXJpLVBhdGg6ICJ0ZW1wZXJhdHVy ZSIKICAgICAgfCAgICAgIHwKICAgICAgfCAgICAgIHwKICAgICAgfDwtIC0gLSsgICAgIEhlYWRl cjogKFQ9QUNLLCBDb2RlPTAsIE1JRD0weDdkMzgpCiAgICAgIHwgICAgICB8CiAgICAgIHwgICAg ICB8CiAgICAgIHw8LS0tLS0rICAgICBIZWFkZXI6IDIuMDUgQ29udGVudCAoVD1DT04sIENvZGU9 NjksIE1JRD0weGFkN2IpCiAgICAgIHwgMi4wNSB8ICAgICAgVG9rZW46IDB4NTMKICAgICAgfCAg ICAgIHwgICAgUGF5bG9hZDogIjIyLjMgQyIKICAgICAgfCAgICAgIHwKICAgICAgfCAgICAgIHwK ICAgICAgKy0gLSAtPnwgICAgIEhlYWRlcjogKFQ9QUNLLCBDb2RlPTAsIE1JRD0weGFkN2IpCiAg ICAgIHwgICAgICB8CgogICAgICAgICAgICAgRmlndXJlIDE2OiBDb25maXJtYWJsZSByZXF1ZXN0 OyBzZXBhcmF0ZSByZXNwb25zZQoKICAge1doYXQgaGFwcGVucyBpZiB0aGUgZmlyc3QgQUNLIGlu IEZpZyAxNiBpcyBsb3N0PyBUaGUgQ2xpZW50IGlzCiAgIGV4cGVjdGluZyBhbiBBQ0sgKHdpdGgg b3Igd2l0aG91dCBwYXlsb2FkKSBmcm9tIHRoZSBzZXJ2ZXIuCiAgIEluc3RlYWQgaXQgZ2V0cyBh IENPTiAod2l0aCB0aGUgcGF5bG9hZCkuIElzIHRoZSBDbGllbnQgaGFwcHkgCiAgIHdpdGggdGhp cz8gT3IgZG9lcyBpdCBpZ25vcmUgdGhlIHJlc3VsdD8gU2VuZCBhIFJTVD99CiAgICAgICAgICAg ICAKICAgRmlndXJlIDE3IHNob3dzIGFuIGV4YW1wbGUgd2hlcmUgdGhlIGNsaWVudCBsb3NlcyBp dHMgc3RhdGUgKGUuZy4sCiAgIGNyYXNoZXMgYW5kIGlzIHJlYm9vdGVkKSByaWdodCBhZnRlciBz ZW5kaW5nIGEgQ29uZmlybWFibGUgcmVxdWVzdCwKICAgc28gdGhlIHNlcGFyYXRlIHJlc3BvbnNl IGFycml2aW5nIHNvbWUgdGltZSBsYXRlciBjb21lcyB1bmV4cGVjdGVkLgogICBJbiB0aGlzIGNh c2UsIHRoZSBjbGllbnQgcmVqZWN0cyB0aGUgQ29uZmlybWFibGUgcmVzcG9uc2Ugd2l0aCBhCiAg IFJlc2V0IG1lc3NhZ2UuICBOb3RlIHRoYXQgdGhlIHVuZXhwZWN0ZWQgQUNLIGlzIHNpbGVudGx5 IGlnbm9yZWQuCgoKCgoKCgoKCgoKCgoKCgoKCgpTaGVsYnksIGV0IGFsLiAgICAgICAgIEV4cGly ZXMgU2VwdGVtYmVyIDE1LCAyMDExICAgICAgICAgICAgICBbUGFnZSA3Ml0KDApJbnRlcm5ldC1E cmFmdCAgIENvbnN0cmFpbmVkIEFwcGxpY2F0aW9uIFByb3RvY29sIChDb0FQKSAgICAgIE1hcmNo IDIwMTEKCgogICBDbGllbnQgIFNlcnZlcgogICAgICB8ICAgICAgfAogICAgICB8ICAgICAgfAog ICAgICArLS0tLS0+fCAgICAgSGVhZGVyOiBHRVQgKFQ9Q09OLCBDb2RlPTEsIE1JRD0weDdkMzkp CiAgICAgIHwgR0VUICB8ICAgICAgVG9rZW46IDB4NjQKICAgICAgfCAgICAgIHwgICBVcmktUGF0 aDogInRlbXBlcmF0dXJlIgogICAgQ1JBU0ggICAgfAogICAgICB8ICAgICAgfAogICAgICB8PC0g LSAtKyAgICAgSGVhZGVyOiAoVD1BQ0ssIENvZGU9MCwgTUlEPTB4N2QzOSkKICAgICAgfCAgICAg IHwKICAgICAgfCAgICAgIHwKICAgICAgfDwtLS0tLSsgICAgIEhlYWRlcjogMi4wNSBDb250ZW50 IChUPUNPTiwgQ29kZT02OSwgTUlEPTB4YWQ3YykKICAgICAgfCAyLjA1IHwgICAgICBUb2tlbjog MHg2NAogICAgICB8ICAgICAgfCAgICBQYXlsb2FkOiAiMjIuMyBDIgogICAgICB8ICAgICAgfAog ICAgICB8ICAgICAgfAogICAgICArLSAtIC0+fCAgICAgSGVhZGVyOiAoVD1SU1QsIENvZGU9MCwg TUlEPTB4YWQ3YykKICAgICAgfCAgICAgIHwKCiAgICAgIEZpZ3VyZSAxNzogQ29uZmlybWFibGUg cmVxdWVzdDsgc2VwYXJhdGUgcmVzcG9uc2UgKHVuZXhwZWN0ZWQpCgogICBGaWd1cmUgMTggc2hv d3MgYSBiYXNpYyBHRVQgcmVxdWVzdCB3aGVyZSB0aGUgcmVxdWVzdCBhbmQgdGhlCiAgIHJlc3Bv bnNlIGFyZSBub24tY29uZmlybWFibGUsIHNvIGJvdGggbWF5IGJlIGxvc3Qgd2l0aG91dCBub3Rp Y2UuCgogICBDbGllbnQgIFNlcnZlcgogICAgICB8ICAgICAgfAogICAgICB8ICAgICAgfAogICAg ICArLS0tLS0+fCAgICAgSGVhZGVyOiBHRVQgKFQ9Tk9OLCBDb2RlPTEsIE1JRD0weDdkNDApCiAg ICAgIHwgR0VUICB8ICAgICAgVG9rZW46IDB4NzUKICAgICAgfCAgICAgIHwgICBVcmktUGF0aDog InRlbXBlcmF0dXJlIgogICAgICB8ICAgICAgfAogICAgICB8ICAgICAgfAogICAgICB8PC0tLS0t KyAgICAgSGVhZGVyOiAyLjA1IENvbnRlbnQgKFQ9Tk9OLCBDb2RlPTY5LCBNSUQ9MHhhZDdkKQog ICAgICB8IDIuMDUgfCAgICAgIFRva2VuOiAweDc1CiAgICAgIHwgICAgICB8ICAgIFBheWxvYWQ6 ICIyMi4zIEMiCiAgICAgIHwgICAgICB8CgogICAgICAgRmlndXJlIDE4OiBOb24tY29uZmlybWFi bGUgcmVxdWVzdDsgTm9uLWNvbmZpcm1hYmxlIHJlc3BvbnNlCgogICBJbiBGaWd1cmUgMTksIHRo ZSBjbGllbnQgc2VuZHMgYSBOb24tY29uZmlybWFibGUgR0VUIHJlcXVlc3QgdG8gYQogICBtdWx0 aWNhc3QgYWRkcmVzczogYWxsIG5vZGVzIGluIGxpbmstbG9jYWwgc2NvcGUuICBUaGVyZSBhcmUg MwogICBzZXJ2ZXJzIG9uIHRoZSBsaW5rOiBBLCBCIGFuZCBDLiBTZXJ2ZXJzIEEgYW5kIEIgaGF2 ZSBhIG1hdGNoaW5nCiAgIHJlc291cmNlLCB0aGVyZWZvcmUgdGhleSBzZW5kIGJhY2sgYSBOb24t Y29uZmlybWFibGUgMi4wNSAoQ29udGVudCkKICAgcmVzcG9uc2UuICBUaGUgcmVzcG9uc2Ugc2Vu dCBieSBCIGlzIGxvc3QuICBDIGRvZXMgbm90IGhhdmUgbWF0Y2hpbmcKICAgcmVzcG9uc2UsIHRo ZXJlZm9yZSBpdCBzZW5kcyBhIE5vbi1jb25maXJtYWJsZSA0LjA0IChOb3QgRm91bmQpCiAgIHJl c3BvbnNlLgoKCgoKClNoZWxieSwgZXQgYWwuICAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMTUs IDIwMTEgICAgICAgICAgICAgIFtQYWdlIDczXQoMCkludGVybmV0LURyYWZ0ICAgQ29uc3RyYWlu ZWQgQXBwbGljYXRpb24gUHJvdG9jb2wgKENvQVApICAgICAgTWFyY2ggMjAxMQoKCiBDbGllbnQg IGZmMDI6OjEgIEEgIEIgIEMKICAgIHwgICAgICAgfCAgICAgfCAgfCAgfAogICAgfCAgICAgICB8 ICAgICB8ICB8ICB8CiAgICArLS0tLS0tPnwgICAgIHwgIHwgIHwgICAgIEhlYWRlcjogR0VUIChU PU5PTiwgQ29kZT0xLCBNSUQ9MHg3ZDQxKQogICAgfCAgR0VUICB8ICAgICB8ICB8ICB8ICAgICAg VG9rZW46IDB4ODYKICAgIHwgICAgICAgICAgICAgfCAgfCAgfCAgIFVyaS1QYXRoOiAidGVtcGVy YXR1cmUiCiAgICB8ICAgICAgICAgICAgIHwgIHwgIHwKICAgIHwgICAgICAgICAgICAgfCAgfCAg fAogICAgfDwtLS0tLS0tLS0tLS0rICB8ICB8ICAgICBIZWFkZXI6IDIuMDUgKFQ9Tk9OLCBDb2Rl PTY5LCBNSUQ9MHg2MGIxKQogICAgfCAgICAgIDIuMDUgICB8ICB8ICB8ICAgICAgVG9rZW46IDB4 ODYKICAgIHwgICAgICAgICAgICAgfCAgfCAgfCAgICBQYXlsb2FkOiAiMjIuMyBDIgogICAgfCAg ICAgICAgICAgICB8ICB8ICB8CiAgICB8ICAgICAgICAgICAgIHwgIHwgIHwKICAgIHwgICBYLS0t LS0tLS0tLS0tKyAgfCAgICAgSGVhZGVyOiAyLjA1IChUPU5PTiwgQ29kZT02OSwgTUlEPTB4MDFh MCkKICAgIHwgICAgICAyLjA1ICAgfCAgfCAgfCAgICAgIFRva2VuOiAweDg2CiAgICB8ICAgICAg ICAgICAgIHwgIHwgIHwgICAgUGF5bG9hZDogIjIwLjkgQyIKICAgIHwgICAgICAgICAgICAgfCAg fCAgfAogICAgfCAgICAgICAgICAgICB8ICB8ICB8CiAgICB8PC0tLS0tLS0tLS0tLS0tLS0tLSsg ICAgIEhlYWRlcjogNC4wNCAoVD1OT04sIENvZGU9MTMyLCBNSUQ9MHg5NTJhKQogICAgfCAgICAg IDQuMDQgICB8ICB8ICB8ICAgICAgVG9rZW46IDB4ODYKICAgIHwgICAgICAgICAgICAgfCAgfCAg fAoKICAgICAgRmlndXJlIDE5OiBOb24tY29uZmlybWFibGUgcmVxdWVzdCAobXVsdGljYXN0KTsg Tm9uLWNvbmZpcm1hYmxlCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJlc3BvbnNl CgogICB7TW9yZSBleGFtcGxlcyB3b3VsZCBiZSB1c2VmdWwgLSBlc3BlY2lhbGx5IHNob3dpbmcg dGhlIHVzZSBvZiAKICAgcHJveGllcywgY2FjaGVzLCBjYWNoZSB2YWxpZGF0aW9ufQoKQXBwZW5k aXggQy4gIFVSSSBFeGFtcGxlcwoKICAgVGhlIGZvbGxvd2luZyBleGFtcGxlcyBkZW1vbnN0cmF0 ZSBkaWZmZXJlbnQgc2V0cyBvZiBVcmkgb3B0aW9ucywgYW5kCiAgIHRoZSByZXN1bHQgYWZ0ZXIg Y29uc3RydWN0aW5nIGFuIFVSSSBmcm9tIHRoZW0uCgogICBvICBjb2FwOi8vWzIwMDE6ZGI4Ojoy OjFdLwoKICAgICAgICAgRGVzdGluYXRpb24gSVAgQWRkcmVzcyA9IFsyMDAxOmRiODo6MjoxXQoK ICAgICAgICAgRGVzdGluYXRpb24gVURQIFBvcnQgPSBbSUFOQV9UQkRfUE9SVF0KCiAgIG8gIGNv YXA6Ly9leGFtcGxlLm5ldC8KCiAgICAgICAgIERlc3RpbmF0aW9uIElQIEFkZHJlc3MgPSBbMjAw MTpkYjg6OjI6MV0KCiAgICAgICAgIERlc3RpbmF0aW9uIFVEUCBQb3J0ID0gW0lBTkFfVEJEX1BP UlRdCgogICAgICAgICBVcmktSG9zdCA9ICJleGFtcGxlLm5ldCIKCiAgIG8gIGNvYXA6Ly9leGFt cGxlLm5ldC8ud2VsbC1rbm93bi9jb3JlCgoKCgoKU2hlbGJ5LCBldCBhbC4gICAgICAgICBFeHBp cmVzIFNlcHRlbWJlciAxNSwgMjAxMSAgICAgICAgICAgICAgW1BhZ2UgNzRdCgwKSW50ZXJuZXQt RHJhZnQgICBDb25zdHJhaW5lZCBBcHBsaWNhdGlvbiBQcm90b2NvbCAoQ29BUCkgICAgICBNYXJj aCAyMDExCgoKICAgICAgICAgRGVzdGluYXRpb24gSVAgQWRkcmVzcyA9IFsyMDAxOmRiODo6Mjox XQoKICAgICAgICAgRGVzdGluYXRpb24gVURQIFBvcnQgPSBbSUFOQV9UQkRfUE9SVF0KCiAgICAg ICAgIFVyaS1Ib3N0ID0gImV4YW1wbGUubmV0IgoKICAgICAgICAgVXJpLVBhdGggPSAiLndlbGwt a25vd24iCgogICAgICAgICBVcmktUGF0aCA9ICJjb3JlIgoKICAgbyAgY29hcDovLwogICAgICB4 bi0tMThqNGQuZXhhbXBsZS8lRTMlODElOTMlRTMlODIlOTMlRTMlODElQUIlRTMlODElQTElRTMl ODElQUYKCiAgICAgICAgIERlc3RpbmF0aW9uIElQIEFkZHJlc3MgPSBbMjAwMTpkYjg6OjI6MV0K CiAgICAgICAgIERlc3RpbmF0aW9uIFVEUCBQb3J0ID0gW0lBTkFfVEJEX1BPUlRdCgogICAgICAg ICBVcmktSG9zdCA9ICJ4bi0tMThqNGQuZXhhbXBsZSIKCiAgICAgICAgIFVyaS1QYXRoID0gdGhl IHN0cmluZyBjb21wb3NlZCBvZiB0aGUgVW5pY29kZSBjaGFyYWN0ZXJzIFUrMzA1MwogICAgICAg ICBVKzMwOTMgVSszMDZiIFUrMzA2MSBVKzMwNmYsIHVzdWFsbHkgcmVwcmVzZW50ZWQgaW4gVVRG LTggYXMKICAgICAgICAgRTM4MTkzRTM4MjkzRTM4MUFCRTM4MUExRTM4MUFGIGhleGFkZWNpbWFs CgogICBvICBjb2FwOi8vMTk4LjUxLjEwMC4xOjYxNjE2Ly8lMkYvLz8lMkYlMkYKCiAgICAgICAg IERlc3RpbmF0aW9uIElQIEFkZHJlc3MgPSAxOTguNTEuMTAwLjEKCiAgICAgICAgIERlc3RpbmF0 aW9uIFVEUCBQb3J0ID0gNjE2MTYKCiAgICAgICAgIFVyaS1QYXRoID0gIiIKCiAgICAgICAgIFVy aS1QYXRoID0gIi8iCgogICAgICAgICBVcmktUGF0aCA9ICIiCgogICAgICAgICBVcmktUGF0aCA9 ICIiCgogICAgICAgICBVcmktUXVlcnkgPSAiJTJGJTJGIgoKICAgbyAgY29hcDovL1syMDAxOmRi ODo6MjoxXS9zZW5zb3JzL3RlbXAKCiAgICAgICAgIERlc3RpbmF0aW9uIElQIEFkZHJlc3MgPSBb OjoxXQoKICAgICAgICAgRGVzdGluYXRpb24gVURQIFBvcnQgPSA2MTYxNgoKICAgICAgICAgVXJp LUhvc3QgPSAiWzIwMDE6ZGI4OjoyOjFdIgoKCgoKClNoZWxieSwgZXQgYWwuICAgICAgICAgRXhw aXJlcyBTZXB0ZW1iZXIgMTUsIDIwMTEgICAgICAgICAgICAgIFtQYWdlIDc1XQoMCkludGVybmV0 LURyYWZ0ICAgQ29uc3RyYWluZWQgQXBwbGljYXRpb24gUHJvdG9jb2wgKENvQVApICAgICAgTWFy Y2ggMjAxMQoKCiAgICAgICAgIFVyaS1Qb3J0ID0gW0lBTkFfVEJEX1BPUlRdCgogICAgICAgICBV cmktUGF0aCA9ICJzZW5zb3JzIgoKICAgICAgICAgVXJpLVBhdGggPSAidGVtcCIKCgpBcHBlbmRp eCBELiAgQ2hhbmdlbG9nCgogICBDaGFuZ2VkIGZyb20gaWV0Zi0wNCB0byBpZXRmLTA1OgoKICAg byAgUmVuYW1lZCBJbW1lZGlhdGUgaW50byBQaWdneS1iYWNrZWQgYW5kIERlZmVycmVkIGludG8g U2VwYXJhdGUgLS0KICAgICAgc2hvdWxkIGZpbmFsbHkgZW5kIHRoZSBjb25mdXNpb24gb24gd2hh dCB0aGlzIGlzIGFib3V0LgoKICAgbyAgR0VUIHJlcXVlc3RzIG5vdyByZXR1cm4gYSAyLjA1IChD b250ZW50KSByZXNwb25zZSBpbnN0ZWFkIG9mIDIuMDAKICAgICAgKE9LKSByZXNwb25zZSAoIzEw NCkuCgogICBvICBBZGRlZCB0ZXh0IHRvIGFsbG93IDIuMDIgKERlbGV0ZWQpIHJlc3BvbnNlcyBp biByZXBseSB0byBQT1NUCiAgICAgIHJlcXVlc3RzICgjMTA1KS4KCiAgIG8gIEltcHJvdmVkIG1l c3NhZ2UgZGVkdXBsaWNhdGlvbiBydWxlcyAoIzEwNikuCgogICBvICBTZWN0aW9uIGFkZGVkIG9u IG1lc3NhZ2Ugc2l6ZSBpbXBsZW1lbnRhdGlvbiBjb25zaWRlcmF0aW9ucwogICAgICAoIzEwMyku CgogICBvICBDbGFyaWZpY2F0aW9uIG1hZGUgb24gaHVtYW4gcmVhZGFibGUgZXJyb3IgcGF5bG9h ZHMgKCMxMDkpLgoKICAgbyAgRGVmaW5pdGlvbiBvZiBDb0FQIG1ldGhvZHMgaW1wcm92ZWQgKCMx MDgpLgoKICAgbyAgTWF4LUFnZSByZW1vdmVkIGZyb20gcmVxdWVzdHMgKCMxMDcpLgoKICAgbyAg Q2xhcmlmaWVkIHVuaXF1ZW5lc3Mgb2YgdG9rZW5zICgjMTEyKS4KCiAgIG8gIExvY2F0aW9uLVF1 ZXJ5IE9wdGlvbiBhZGRlZCAoIzExMykuCgogICBvICBFVGFnIGxlbmd0aCBzZXQgdG8gMS04IGJ5 dGVzICgjMTIzKS4KCiAgIG8gIENsYXJpZmllZCByZWxhdGlvbiBiZXR3ZWVuIGVsZWN0aXZlL2Ny aXRpY2FsIGFuZCBvcHRpb24gbnVtYmVycwogICAgICAoIzExMCkuCgogICBvICBEZWZpbmVkIHdo ZW4gdG8gdXBkYXRlIFZlcnNpb24gaGVhZGVyIGZpZWxkICgjMTExKS4KCiAgIG8gIFVSSSBzY2hl bWUgcmVnaXN0cmF0aW9uIGltcHJvdmVkICgjMTAyKS4KCiAgIG8gIEFkZGVkIHJldmlldyBndWlk ZWxpbmVzIGZvciBuZXcgQ29BUCBjb2RlcyBhbmQgbnVtYmVycy4KCiAgIENoYW5nZXMgZnJvbSBp ZXRmLTAzIHRvIGlldGYtMDQ6CgoKCgpTaGVsYnksIGV0IGFsLiAgICAgICAgIEV4cGlyZXMgU2Vw dGVtYmVyIDE1LCAyMDExICAgICAgICAgICAgICBbUGFnZSA3Nl0KDApJbnRlcm5ldC1EcmFmdCAg IENvbnN0cmFpbmVkIEFwcGxpY2F0aW9uIFByb3RvY29sIChDb0FQKSAgICAgIE1hcmNoIDIwMTEK CgogICBvICBNYWpvciBkb2N1bWVudCByZW9yZ2FuaXphdGlvbiAoIzUxLCAjNjMsICM3MSwgIzgx KS4KCiAgIG8gIE1heC1hZ2UgbGVuZ3RoIHNldCB0byAwLTQgYnl0ZXMgKCMzMCkuCgogICBvICBB ZGRlZCB2YXJpYWJsZSB1bnNpZ25lZCBpbnRlZ2VyIGRlZmluaXRpb24gKCMzMSkuCgogICBvICBD bGFyaWZpY2F0aW9uIG1hZGUgb24gaHVtYW4gcmVhZGFibGUgZXJyb3IgcGF5bG9hZHMgKCM1MCku CgogICBvICBEZWZpbml0aW9uIG9mIFBPU1QgaW1wcm92ZWQgKCM1MikuCgogICBvICBUb2tlbiBs ZW5ndGggY2hhbmdlZCB0byAwLTggYnl0ZXMgKCM1MykuCgogICBvICBTZWN0aW9uIGFkZGVkIG9u IG11bHRpcGxleGluZyBDb0FQLCBEVExTIGFuZCBTVFVOICgjNTYpLgoKICAgbyAgQWRkZWQgY3Jv c3MtcHJvdG9jb2wgYXR0YWNrIGNvbnNpZGVyYXRpb25zICgjNjEpLgoKICAgbyAgVXNlZCBuZXcg SW1tZWRpYXRlL0RlZmVycmVkIHJlc3BvbnNlIGRlZmluaXRpb25zICgjNzMpLgoKICAgbyAgSW1w cm92ZWQgcmVxdWVzdC9yZXNwb25zZSBtYXRjaGluZyBydWxlcyAoIzc0KS4KCiAgIG8gIFJlbW92 ZWQgdW5uZWNlc3NhcnkgbWVkaWEgdHlwZXMgYW5kIGFkZGVkIHJlY29tbWVuZGF0aW9ucyBmb3IK ICAgICAgdGhlaXIgdXNlIGluIE0yTSAoIzc2KS4KCiAgIG8gIFJlc3BvbnNlIGNvZGVzIGNoYW5n ZWQgdG8gYmFzZSAzMiBjb2RpbmcsIG5ldyBZLlhYIG5hbWluZyAoIzc3KS4KCiAgIG8gIFJlZmVy ZW5jZXMgdXBkYXRlZCBhcyBwZXIgQUQgcmV2aWV3ICgjNzkpLgoKICAgbyAgSUFOQSBzZWN0aW9u IGNvbXBsZXRlZCAoIzgwKS4KCiAgIG8gIFByb3h5LVVyaSBPcHRpb24gYWRkZWQgdG8gZGlhbWJp Z3VhdGUgYmV0d2VlbiBwcm94eSBhbmQgbm9uLXByb3h5CiAgICAgIHJlcXVlc3RzICgjODIpLgoK ICAgbyAgQWRkZWQgdGV4dCBvbiBjcml0aWNhbCBvcHRpb25zIGluIGNhY2hlZCBzdGF0ZXMgKCM4 MykuCgogICBvICBIVFRQIG1hcHBpbmcgc2VjdGlvbnMgaW1wcm92ZWQgKCM4OCkuCgogICBvICBB ZGRlZCB0ZXh0IG9uIHJldmVyc2UgcHJveGllcyAoIzcyKS4KCiAgIG8gIFNvbWUgc2VjdXJpdHkg dGV4dCBvbiBtdWx0aWNhc3QgYWRkZWQgKCM1NCkuCgogICBvICBUcnVzdCBtb2RlbCB0ZXh0IGFk ZGVkIHRvIGludHJvZHVjdGlvbiAoIzU4LCAjNjApLgoKICAgbyAgQUVTLUNDTSB2cy4gQUVTLUND QiB0ZXh0IGFkZGVkICgjNTUpLgoKICAgbyAgVGV4dCBhZGRlZCBhYm91dCBkZXZpY2UgY2FwYWJp bGl0aWVzICgjNTkpLgoKICAgbyAgRFRMUyBzZWN0aW9uIGltcHJvdmVtZW50cyAoIzg3KS4KCgoK ClNoZWxieSwgZXQgYWwuICAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMTUsIDIwMTEgICAgICAg ICAgICAgIFtQYWdlIDc3XQoMCkludGVybmV0LURyYWZ0ICAgQ29uc3RyYWluZWQgQXBwbGljYXRp b24gUHJvdG9jb2wgKENvQVApICAgICAgTWFyY2ggMjAxMQoKCiAgIG8gIENhY2hpbmcgc2VtYW50 aWNzIGFsaWduZWQgd2l0aCBSRkMyNjE2ICgjNzgpLgoKICAgbyAgVXJpLVBhdGggT3B0aW9uIHNw bGl0IGludG8gbXVsdGlwbGUgcGF0aCBzZWdtZW50cy4KCiAgIG8gIE1BWF9SRVRSQU5TTUlUIGNo YW5nZWQgdG8gNCB0byBhZGp1c3QgZm9yIFJFU1BPTlNFX1RJTUUgPSAyLgoKICAgQ2hhbmdlcyBm cm9tIGlldGYtMDIgdG8gaWV0Zi0wMzoKCiAgIG8gIFRva2VuIE9wdGlvbiBhbmQgcmVsYXRlZCB1 c2UgaW4gYXN5bmNocm9ub3VzIHJlcXVlc3RzIGFkZGVkICgjMjUpLgoKICAgbyAgQ29BUCBzcGVj aWZpYyBlcnJvciBjb2RlcyBhZGRlZCAoIzI2KS4KCiAgIG8gIEVycm9yaW5nIG91dCBvbiB1bmtu b3duIGNyaXRpY2FsIG9wdGlvbnMgY2hhbmdlZCB0byBhIE1VU1QgKCMyNykuCgogICBvICBVcmkt UXVlcnkgT3B0aW9uIGFkZGVkLgoKICAgbyAgVGVybWlub2xvZ3kgYW5kIGRlZmluaXRpb25zIG9m IFVSSXMgaW1wcm92ZWQuCgogICBvICBTZWN1cml0eSBzZWN0aW9uIGNvbXBsZXRlZCAoIzIyKS4K CiAgIENoYW5nZXMgZnJvbSBpZXRmLTAxIHRvIGlldGYtMDI6CgogICBvICBTZW5kaW5nIGFuIGVy cm9yIG9uIGEgY3JpdGljYWwgb3B0aW9uIGNsYXJpZmllZCAoIzE4KS4KCiAgIG8gIENsYXJpZmlj YXRpb24gb24gYmVoYXZpb3Igb2YgUFVUIGFuZCBpZGVtcG90ZW50IG9wZXJhdGlvbnMgKCMxOSku CgogICBvICBVc2Ugb2YgVXJpLUF1dGhvcml0eSBjbGFyaWZpZWQgYWxvbmcgd2l0aCBzZXJ2ZXIg cHJvY2Vzc2luZyBydWxlczsKICAgICAgVXJpLVNjaGVtZSBPcHRpb24gcmVtb3ZlZCAoIzIwLCAj MjMpLgoKICAgbyAgUmVzb3VyY2UgZGlzY292ZXJ5IHNlY3Rpb24gcmVtb3ZlZCB0byBhIHNlcGFy YXRlIENvUkUgTGluayBGb3JtYXQKICAgICAgZHJhZnQgKCMyMSkuCgogICBvICBJbml0aWFsIHNl Y3VyaXR5IHNlY3Rpb24gb3V0bGluZSBhZGRlZC4KCiAgIENoYW5nZXMgZnJvbSBpZXRmLTAwIHRv IGlldGYtMDE6CgogICBvICBOZXcgY2xlYW5lciB0cmFuc2FjdGlvbiBtZXNzYWdlIG1vZGVsIGFu ZCBoZWFkZXIgKCM1KS4KCiAgIG8gIFJlbW92ZWQgc3Vic2NyaXB0aW9uIHdoaWxlIGJlaW5nIGRl c2lnbmVkICgjMSkuCgogICBvICBTZWN0aW9uIDIgcmUtd3JpdHRlbiAoIzMpLgoKICAgbyAgVGV4 dCBhZGRlZCBhYm91dCB1c2Ugb2Ygc2hvcnQgVVJJcyAoIzQpLgoKICAgbyAgSW1wcm92ZWQgaGVh ZGVyIG9wdGlvbiBzY2hlbWUgKCM1LCAjMTQpLgoKICAgbyAgRGF0ZSBvcHRpb24gcmVtb3ZlZCB3 aGlsZWQgYmVpbmcgZGVzaWduZWQgKCM2KS4KCgoKClNoZWxieSwgZXQgYWwuICAgICAgICAgRXhw aXJlcyBTZXB0ZW1iZXIgMTUsIDIwMTEgICAgICAgICAgICAgIFtQYWdlIDc4XQoMCkludGVybmV0 LURyYWZ0ICAgQ29uc3RyYWluZWQgQXBwbGljYXRpb24gUHJvdG9jb2wgKENvQVApICAgICAgTWFy Y2ggMjAxMQoKCiAgIG8gIE5ldyB0ZXh0IGZvciBDb0FQIGRlZmF1bHQgcG9ydCAoIzcpLgoKICAg byAgQ29tcGxldGVkIHByb3h5aW5nIHNlY3Rpb24gKCM4KS4KCiAgIG8gIENvbXBsZXRlZCByZXNv dXJjZSBkaXNjb3Zlcnkgc2VjdGlvbiAoIzkpLgoKICAgbyAgQ29tcGxldGVkIEhUVFAgbWFwcGlu ZyBzZWN0aW9uICgjMTApLgoKICAgbyAgU2V2ZXJhbCBuZXcgZXhhbXBsZXMgYWRkZWQgKCMxMSku CgogICBvICBVUkkgc3BsaXQgaW50byAzIG9wdGlvbnMgKCMxMikuCgogICBvICBNSU1FIHR5cGUg ZGVmaW5lZCBmb3IgbGluay1mb3JtYXQgKCMxMywgIzE2KS4KCiAgIG8gIE5ldyB0ZXh0IG9uIG1h eGltdW0gbWVzc2FnZSBzaXplICgjMTUpLgoKICAgbyAgTG9jYXRpb24gT3B0aW9uIGFkZGVkLgoK ICAgQ2hhbmdlcyBmcm9tIHNoZWxieS0wMSB0byBpZXRmLTAwOgoKICAgbyAgUmVtb3ZlZCB0aGUg VENQIGJpbmRpbmcgc2VjdGlvbiwgbGVmdCBvcGVuIGZvciB0aGUgZnV0dXJlLgoKICAgbyAgRml4 ZWQgYSBidWcgaW4gdGhlIGV4YW1wbGUuCgogICBvICBNYXJrZWQgY3VycmVudCBTdWIvTm90aWZ5 IGFzIChFeHBlcmltZW50YWwpIHdoaWxlIHVuZGVyIFdHCiAgICAgIGRpc2N1c3Npb24uCgogICBv ICBGaXhlZCBtYXhpbXVtIGRhdGFncmFtIHNpemUgdG8gMTI4MCBmb3IgYm90aCBJUHY0IGFuZCBJ UHY2IChmb3IKICAgICAgQ29BUC1Db0FQIHByb3h5aW5nIHRvIHdvcmspLgoKICAgbyAgVGVtcG9y YXJpbHkgcmVtb3ZlZCB0aGUgTWFnaWMgQnl0ZSBoZWFkZXIgYXMgVENQIGlzIG5vIGxvbmdlcgog ICAgICBpbmNsdWRlZCBhcyBhIGJpbmRpbmcuCgogICBvICBSZW1vdmVkIHRoZSBVcmktY29kZSBP cHRpb24gYXMgZGlmZmVyZW50IFVSSSBlbmNvZGluZyBzY2hlbWVzIGFyZQogICAgICBiZWluZyBk aXNjdXNzZWQuCgogICBvICBDaGFuZ2VkIHRoZSByZWw9IGZpZWxkIHRvIGRlc2M9IGZvciByZXNv dXJjZSBkaXNjb3ZlcnkuCgogICBvICBDaGFuZ2VkIHRoZSBtYXhpbXVtIG1lc3NhZ2Ugc2l6ZSB0 byAxMDI0IGJ5dGVzIHRvIGFsbG93IGZvciBJUC9VRFAKICAgICAgaGVhZGVycy4KCiAgIG8gIE1h ZGUgdGhlIFVSSSBzbGFzaCBvcHRpbWl6YXRpb24gYW5kIG1ldGhvZCBpbXBvdGVuY2UgTVVTVHMK CiAgIG8gIE1pbm9yIGVkaXRpbmcgYW5kIGJ1ZyBmaXhpbmcuCgogICBDaGFuZ2VzIGZyb20gc2hl bGJ5LTAwIHRvIHNoZWxieS0wMToKCgoKCgpTaGVsYnksIGV0IGFsLiAgICAgICAgIEV4cGlyZXMg U2VwdGVtYmVyIDE1LCAyMDExICAgICAgICAgICAgICBbUGFnZSA3OV0KDApJbnRlcm5ldC1EcmFm dCAgIENvbnN0cmFpbmVkIEFwcGxpY2F0aW9uIFByb3RvY29sIChDb0FQKSAgICAgIE1hcmNoIDIw MTEKCgogICBvICBVbmlmaWVkIHRoZSBtZXNzYWdlIGhlYWRlciBhbmQgYWRkZWQgYSBub3RpZnkg bWVzc2FnZSB0eXBlLgoKICAgbyAgUmVuYW1lZCBtZXRob2RzIHdpdGggSFRUUCBuYW1lcyBhbmQg cmVtb3ZlZCB0aGUgTk9USUZZIG1ldGhvZC4KCiAgIG8gIEFkZGVkIGEgbnVtYmVyIG9mIG9wdGlv bnMgZmllbGQgdG8gdGhlIGhlYWRlci4KCiAgIG8gIENvbWJpbmVzIHRoZSBPcHRpb24gVHlwZSBh bmQgTGVuZ3RoIGludG8gYW4gOC1iaXQgZmllbGQuCgogICBvICBBZGRlZCB0aGUgbWFnaWMgYnl0 ZSBoZWFkZXIuCgogICBvICBBZGRlZCBuZXcgRVRhZyBPcHRpb24uCgogICBvICBBZGRlZCBuZXcg RGF0ZSBPcHRpb24uCgogICBvICBBZGRlZCBuZXcgU3Vic2NyaXB0aW9uIE9wdGlvbi4KCiAgIG8g IENvbXBsZXRlZCB0aGUgSFRUUCBDb2RlIC0gQ29BUCBDb2RlIG1hcHBpbmcgdGFibGUgYXBwZW5k aXguCgogICBvICBDb21wbGV0ZWQgdGhlIENvbnRlbnQtdHlwZSBJZGVudGlmaWVyIGFwcGVuZGl4 IGFuZCB0YWJsZXMuCgogICBvICBBZGRlZCBtb3JlIHNpbXBsaWZpY2F0aW9ucyBmb3IgVVJJIHN1 cHBvcnQuCgogICBvICBJbml0aWFsIHN1YnNjcmlwdGlvbiBhbmQgZGlzY292ZXJ5IHNlY3Rpb25z LgoKICAgbyAgQSBGbGFnIHJlcXVpcmVtZW50cyBzaW1wbGlmaWVkLgoKCkF1dGhvcnMnIEFkZHJl c3NlcwoKICAgWmFjaCBTaGVsYnkKICAgU2Vuc2lub2RlCiAgIEtpZGVrdWphIDIKICAgVnVva2F0 dGkgIDg4NjAwCiAgIEZpbmxhbmQKCiAgIFBob25lOiArMzU4NDA3Nzk2Mjk3CiAgIEVtYWlsOiB6 YWNoQHNlbnNpbm9kZS5jb20KCgoKCgoKCgoKCgoKCgpTaGVsYnksIGV0IGFsLiAgICAgICAgIEV4 cGlyZXMgU2VwdGVtYmVyIDE1LCAyMDExICAgICAgICAgICAgICBbUGFnZSA4MF0KDApJbnRlcm5l dC1EcmFmdCAgIENvbnN0cmFpbmVkIEFwcGxpY2F0aW9uIFByb3RvY29sIChDb0FQKSAgICAgIE1h cmNoIDIwMTEKCgogICBLbGF1cyBIYXJ0a2UKICAgVW5pdmVyc2l0YWV0IEJyZW1lbiBUWkkKICAg UG9zdGZhY2ggMzMwNDQwCiAgIEJyZW1lbiAgRC0yODM1OQogICBHZXJtYW55CgogICBQaG9uZTog KzQ5LTQyMS0yMTgtNjM5MDUKICAgRmF4OiAgICs0OS00MjEtMjE4LTcwMDAKICAgRW1haWw6IGhh cnRrZUB0emkub3JnCgoKICAgQ2Fyc3RlbiBCb3JtYW5uCiAgIFVuaXZlcnNpdGFldCBCcmVtZW4g VFpJCiAgIFBvc3RmYWNoIDMzMDQ0MAogICBCcmVtZW4gIEQtMjgzNTkKICAgR2VybWFueQoKICAg UGhvbmU6ICs0OS00MjEtMjE4LTYzOTIxCiAgIEZheDogICArNDktNDIxLTIxOC03MDAwCiAgIEVt YWlsOiBjYWJvQHR6aS5vcmcKCgogICBCcmlhbiBGcmFuawogICBTa3lGb3VuZHJ5CiAgIFJpY2ht b25kLCBWQQogICBVU0EKCiAgIFBob25lOgogICBFbWFpbDogYnJpYW5Ac2t5Zm91bmRyeS5jb20K CgoKCgoKCgoKCgoKCgoKCgoKCgoKClNoZWxieSwgZXQgYWwuICAgICAgICAgRXhwaXJlcyBTZXB0 ZW1iZXIgMTUsIDIwMTEgICAgICAgICAgICAgIFtQYWdlIDgxXQoMCg== ------_=_NextPart_001_01CC097F.2388F67A Content-Type: text/plain; name=draft-ietf-core-link-format-03_CGP.txt Content-Transfer-Encoding: base64 Content-Description: draft-ietf-core-link-format-03_CGP.txt Content-Disposition: attachment; filename="draft-ietf-core-link-format-03_CGP.txt" e0NoYW5nZXMgYnkgQ2hhcmxlcyBQYWxtZXIgY2hhcmxlcy5wYWxtZXJAb256by5jb20gCi0gVXNl IGEgZGlmZiB0b29sIHRvIGxvY2F0ZSB0aGUgY2hhbmdlcy4KLSBQcmVzdW1lZCBzdHJhaWdodC1m b3J3YXJkIGVkaXRvcmlhbCBjb3JyZWN0aW9ucyBvciByZXdvcmRpbmcgdG8KaW1wcm92ZSBjbGFy aXR5IGFyZSBwcm92aWRlZCB3aXRob3V0IGNvbW1lbnQgKGJ1dCBzaG91bGQgYmUgY2hlY2tlZCEp LgotIENvbW1lbnRzIGFuZCBxdWVzdGlvbnMgYXJlIGlkZW50aWZpZWQgYnkge3BhcmVudGhlc2Vz fS4KfQoKe1ByZXN1YWJseSB0aGlzIGRvY3VtZW50IGlzIHRoZSByZXN1bHQgb2YgbXVjaCB3b3Jr LCBhbmQgb3RoZXIgCmFwcHJvYWNoZXMgaGF2ZSBiZWVuIGNvbnNpZGVyZWQuIFRoZXJlZm9yZSBt eSBuZXdiZWUgYXBvbG9naWVzCmlmIEkgYW0gZ29pbmcgb3ZlciBvbGQgZ3JvdW5kLgoKVGhhdCBz YWlkOiBteSBndXQtZmVlbGluZyBpcyB0aGF0IGl0IGlzIG5vdAphcyBlbGVnYW50IGFzIHRoZSBy ZXN0IG9mIHRoZSBDb1JFIHdvcmsuIFdoZXJlYXMgYWxsIG9mIHRoZSBvdGhlcgp3b3JrIGhhcyBz dHJlc3NlZCBtaW5pbWFsIGJpbmFyeSBmb3JtYXRzLCB0aGlzIGRvY3VtZW50IHVzZXMgdGV4dAp0 aGF0IG11c3QgYmUgcGFyc2VkLiBJdCBhbHNvIHNlZW1zIHRvbyBjb21wbGV4IGFuZCB0b28gZmxl eGlibGUKZm9yIHVzZSBpbiB0aGUgImNvbnN0cmFpbmVkIiBkb21haW5zIHdlIGFyZSBhZGRyZXNz aW5nLgpUb28gY29tcGxleCAoZS5nLiB0aGUgYW5jaG9yIGFuZCByZWwgYXR0cmlidXRlcyk7IHRv byBtdWNoIGlzIGxlZnQKb3B0aW9uYWwsIGFuZCBpcyB0aHVzIHByb2JhYmx5IHJlZHVuZGFudCBX aHkgd291bGQgb25lIG5vZGUgc3VwcG9ydAphIGZlYXR1cmUgdGhhdCB0aGUgY29ycmVzcG9uZGlu ZyBub2RlIGRvZXMgbm90IChlLmcuIHRoZSByZWwgYW5kIGFuY2hvciAKYXR0cmlidXRlcyBhZ2Fp bik7IGFuZCAiaGludHMiIG9mIGNvbnRlbnQtdHlwZSBzZWVtIG9mIGxpdHRsZSB2YWx1ZTogCmlm IG9uZSBjb25zdHJhaW5lZCBub2RlIGNhbm5vdCByZWx5IG9uIHRoZSBjb250ZW50IHR5cGUgcmV2 ZWFsZWQgCmluIGEgZGlzY292ZXJ5IHJlcXVlc3QgZnJvbSBhbm90aGVyIGNvbnN0cmFpbmVkIG5v ZGUgdGhlbiB0aGVyZSAKc2VlbXMgbGl0dGxlIHBvaW50IGluIHRha2luZyBub3RlIG9mIGl0LgoK QWxzbyAtIHRoZSBhY3R1YWwgdXNlIG9mIHRoZSBsaW5rcyBhcmUgZ29pbmcgdG8gYmUgYXBwbGlj YXRpb24tc3BlY2lmaWMuClRoYXQgaXMsIGZvciBpbnRlcm9wZXJhYmlsaXR5IGVhY2ggZG9tYWlu IChzbWFydCBlbmVyZ3ksIGhvbWUgYXV0b21hdGlvbgpldGMpIHdpbGwgaGF2ZSB0byBkZWZpbmUg aXRzIG93biBydWxlcyAoZS5nLiBwYXRoIG5hbWVzLCByZXNvdXJjZSB0eXBlcywKaW50ZXJmYWNl IGRlc2NyaXB0aW9ucyBldGMpLiBJIHdvbmRlciBpZiB3ZSBtaWdodCBmaW5kIHRoYXQgdGhlIGxp bmsKbWVjaGFuaXNtIGRlc2NyaWJlZCBoZXJlIHByb3ZlcyBpbiBuZWVkIG9mIGNoYW5nZSBpbiBs aWdodCBvZgpleHBlcmllbmNlIGdhaW5lZCBkdXJpbmcgaW1wbGVtZW50YXRpb24uIEl0IGNvdWxk IGJlIHRoYXQgdGhlcmUgYXJlIApmZWF0dXJlcyBoZXJlIHRoYXQgYXJlIG5vdCByZXF1aXJlZCwg YW5kIGl0IGNvdWxkIGJlIHRoYXQgZmVhdHVyZXMgYXJlCnJlcXVpcmVkIHRoYXQgYXJlIG5vdCBk ZXNjcmliZWQgaW4gdGhpcyBkb2N1bWVudC4gSSB3b25kZXIgaWYgdGhpcyAKZG9jdW1lbnQgc2hv dWxkIHRoZXJlZm9yZSBiZSBwdXQgb24gb25lIHNpZGUgdW50aWwgYSBfcmVhbF8gYXBwbGljYXRp b24KZG9tYWluIGhhcyBiZWVuIGltcGxlbWVudGVkIHVzaW5nIENvQVAuIAoKVGhlcmUgYXJlIHR3 byBzdWNoIGRvbWFpbnMgdGhhdCBjb21lIHRvIG1pbmQ6CgoxIFNtYXJ0IEVuZXJneS4gWmlnQmVl IFNFMi4wIGFyZSB0YWtpbmcgYSBmcmVzaCBsb29rIGF0IENvQVAuIFRoZXkgaGF2ZQphIHJlYXNv bmFibHkgZ29vZCBpZGVhIGFib3V0IHRoZSByZXNvdXJjZXMgbmVlZGVkIG9uIHRoZWlyIGRldmlj ZXMsCmFuZCBpdCBjb3VsZCBiZSBxdWl0ZSBxdWljayB0byB0cnkgb3V0IHRoaXMgZG9jdW1lbnQg b24gdGhlaXIgCmFwcGxpY2F0aW9uIHNlcGNpZmljYXRpb24uCgoyIElFRUUxMTA3MyBQZXJzb25h bCBIZWFsdGggRGV2aWNlcy4gQWx0aG91Z2ggdGhpcyBpcyBhbHJlYWR5IHN1cHBvcnRlZApvbiBa aWdCZWUgKFpIUCkgaXQgd291bGQgZml0IHdlbGwgd2l0aGluIGEgQ29BUCBhcmNoaXRlY3R1cmUu IFRoZXkgCmFscmVhZHkgaGF2ZSBhIHdlbGwtZGVmaW5lZCwgZWZmaWNpZW50LCBiaW5hcnkgZGlz Y292ZXJ5IG1lY2hhbmlzbQphbmQgc28gcGVyaGFwcyB3b3VsZCBoYXZlIG5vIG5lZWQgZm9yIHRo ZSBsaW5rIGZvcm1hdCBkZXNjcmliZWQgaGVyZS4KQnV0IGl0IG1pZ2h0IGJlIGEgZ29vZCBleGVy Y2lzZSB0byBpbXBsZW1lbnQgMTEwNzMgaW4gQ29BUCB0byBzZWUKd2hhdCBsZXNzb25zIGl0IHRo cm93cyB1cC4gTXkgcGVyc29uYWwgdmlldyBpcyB0aGF0IHRoZSAxMTA3MwpkaXNjb3ZlcnkgbWVj aGFuaXNtIGlzIGFjdHVhbGx5IGEgZ29vZCBtb2RlbCB0aGF0IGNvdWxkIGJlIGV4dGVuZGVkIHRv CmFueSBNMk0gZG9tYWluLiBUaHVzIGl0IGNvdWxkIGJlIGEgZ29vZCBtb2RlbCBvbiB3aGljaCB0 byBiYXNlIGEgCkNvUkUgZGlzY292ZXJ5IG1lY2hhbmlzbS4KCkZpbmFsbHk6IHRoaXMgZG9jdW1l bnQgaXMgYWJvdXQgImRpc2NvdmVyeSIuIERvZXMgdGhlIHRlcm0gImxpbmsiCmFycml2ZSB2aWEg UkZDNTk4OD8gd2hhdCBhYm91dCB0aGUgbmFtZSAiQ29BUCBEaXNjb3ZlcnkiIGluIHBsYWNlIG9m CiJDb1JFIExpbmsgRm9ybWF0Ij8KfQoKCkNvUkUgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFouIFNoZWxieQpJbnRlcm5ldC1EcmFmdCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTZW5zaW5vZGUK SW50ZW5kZWQgc3RhdHVzOiBTdGFuZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgICAgICAg IE1hcmNoIDE0LCAyMDExCkV4cGlyZXM6IFNlcHRlbWJlciAxNSwgMjAxMQoKCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICBDb1JFIExpbmsgRm9ybWF0CiAgICAgICAgICAgICAgICAgICAgIGRy YWZ0LWlldGYtY29yZS1saW5rLWZvcm1hdC0wMwoKQWJzdHJhY3QKCiAgIFRoaXMgZG9jdW1lbnQg ZGVmaW5lcyBXZWIgTGlua2luZyB1c2luZyBhIGxpbmsgZm9ybWF0IGZvciB1c2UgYnkKICAgY29u c3RyYWluZWQgd2ViIHNlcnZlcnMgdG8gZGVzY3JpYmUgaG9zdGVkIHJlc291cmNlcywgdGhlaXIK ICAgYXR0cmlidXRlcyBhbmQgb3RoZXIgcmVsYXRpb25zaGlwcyBiZXR3ZWVuIGxpbmtzLiAgQmFz ZWQgb24gdGhlIEhUVFAKICAgTGluayBIZWFkZXIgZm9ybWF0IGRlZmluZWQgaW4gUkZDNTk4OCwg dGhlIENvUkUgTGluayBGb3JtYXQgaXMKICAgY2FycmllZCBhcyBhIHBheWxvYWQgYW5kIGlzIGFz c2lnbmVkIGFuIEludGVybmV0IG1lZGlhIHR5cGUuICBBIHdlbGwtCiAgIGtub3duIFVSSSBpcyBk ZWZpbmVkIGFzIGEgZGVmYXVsdCBlbnRyeS1wb2ludCBmb3IgcmVxdWVzdGluZyB0aGUKICAgbGlu a3MgaG9zdGVkIGJ5IGEgc2VydmVyLgoKU3RhdHVzIG9mIHRoaXMgTWVtbwoKICAgVGhpcyBJbnRl cm5ldC1EcmFmdCBpcyBzdWJtaXR0ZWQgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoIHRoZQogICBw cm92aXNpb25zIG9mIEJDUCA3OCBhbmQgQkNQIDc5LgoKICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3 b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcKICAgVGFzayBGb3Jj ZSAoSUVURikuICBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUKICAg d29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtRHJhZnRzLiAgVGhlIGxpc3Qgb2YgY3VycmVu dCBJbnRlcm5ldC0KICAgRHJhZnRzIGlzIGF0IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k cmFmdHMvY3VycmVudC8uCgogICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2 YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHMKICAgYW5kIG1heSBiZSB1cGRhdGVkLCBy ZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkKICAgdGltZS4g IEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UK ICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jl c3MuIgoKICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBTZXB0ZW1iZXIgMTUs IDIwMTEuCgpDb3B5cmlnaHQgTm90aWNlCgogICBDb3B5cmlnaHQgKGMpIDIwMTEgSUVURiBUcnVz dCBhbmQgdGhlIHBlcnNvbnMgaWRlbnRpZmllZCBhcyB0aGUKICAgZG9jdW1lbnQgYXV0aG9ycy4g IEFsbCByaWdodHMgcmVzZXJ2ZWQuCgogICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8gQkNQ IDc4IGFuZCB0aGUgSUVURiBUcnVzdCdzIExlZ2FsCiAgIFByb3Zpc2lvbnMgUmVsYXRpbmcgdG8g SUVURiBEb2N1bWVudHMKICAgKGh0dHA6Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbykg aW4gZWZmZWN0IG9uIHRoZSBkYXRlIG9mCiAgIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQu ICBQbGVhc2UgcmV2aWV3IHRoZXNlIGRvY3VtZW50cwogICBjYXJlZnVsbHksIGFzIHRoZXkgZGVz Y3JpYmUgeW91ciByaWdodHMgYW5kIHJlc3RyaWN0aW9ucyB3aXRoIHJlc3BlY3QKICAgdG8gdGhp cyBkb2N1bWVudC4gIENvZGUgQ29tcG9uZW50cyBleHRyYWN0ZWQgZnJvbSB0aGlzIGRvY3VtZW50 IG11c3QKICAgaW5jbHVkZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlIHRleHQgYXMgZGVzY3JpYmVk IGluIFNlY3Rpb24gNC5lIG9mCgoKClNoZWxieSAgICAgICAgICAgICAgICAgRXhwaXJlcyBTZXB0 ZW1iZXIgMTUsIDIwMTEgICAgICAgICAgICAgICBbUGFnZSAxXQoMCkludGVybmV0LURyYWZ0ICAg ICAgICAgICAgICBDb1JFIExpbmsgRm9ybWF0ICAgICAgICAgICAgICAgICAgTWFyY2ggMjAxMQoK CiAgIHRoZSBUcnVzdCBMZWdhbCBQcm92aXNpb25zIGFuZCBhcmUgcHJvdmlkZWQgd2l0aG91dCB3 YXJyYW50eSBhcwogICBkZXNjcmliZWQgaW4gdGhlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UuCgoK VGFibGUgb2YgQ29udGVudHMKCiAgIDEuICBJbnRyb2R1Y3Rpb24gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMwogICAgIDEuMS4gIFdlYiBMaW5raW5n IGluIENvUkUgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDMKICAgICAx LjIuICBVc2UgQ2FzZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICA0CiAgICAgICAxLjIuMS4gIERpc2NvdmVyeSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNAogICAgICAgMS4yLjIuICBSZXNvdXJjZSBDb2xsZWN0 aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDUKICAgICAgIDEuMi4zLiAg UmVzb3VyY2UgRGlyZWN0b3J5IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA1 CiAgICAgMS4zLiAgVGVybWlub2xvZ3kgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAgNQogICAyLiAgTGluayBGb3JtYXQgIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDYKICAgICAyLjEuICBUYXJnZXQgYW5kIGNv bnRleHQgVVJJcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA3CiAgICAgMi4y LiAgTGluayByZWxhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAgNwogICAgIDIuMy4gIFVzZSBvZiBhbmNob3JzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gIDgKICAgMy4gIENvUkUgbGluayBleHRlbnNpb25zIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA4CiAgICAgMy4xLiAgUmVzb3Vy Y2UgdHlwZSAncnQnIGF0dHJpYnV0ZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOAog ICAgIDMuMi4gIEludGVyZmFjZSBkZXNjcmlwdGlvbiAnaWYnIGF0dHJpYnV0ZSAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gIDkKICAgICAzLjMuICBDb250ZW50LXR5cGUgY29kZSAnY3QnIGF0dHJpYnV0 ZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA5CiAgICAgMy40LiAgTWF4aW11bSBzaXplIGVz dGltYXRlICdzeicgYXR0cmlidXRlIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOQogICA0LiAgV2Vs bC1rbm93biBJbnRlcmZhY2UgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gMTAKICAgICA0LjEuICBRdWVyeSBGaWx0ZXJpbmcgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIDEwCiAgIDUuICBFeGFtcGxlcyAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMQogICA2LiAgU2VjdXJpdHkgQ29u c2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTMKICAg Ny4gIElBTkEgQ29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIDEzCiAgICAgNy4xLiAgQXR0cmlidXRlIFJlZ2lzdHJ5IC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMwogICAgIDcuMi4gIFdlbGwta25vd24gJ2NvcmUn IFVSSSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTQKICAgICA3LjMuICBO ZXcgJ2hvc3RzJyByZWxhdGlvbiB0eXBlICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IDE0CiAgICAgNy40LiAgTmV3IGxpbmstZm9ybWF0IEludGVybmV0IG1lZGlhIHR5cGUgIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAxNQogICA4LiAgQWNrbm93bGVkZ21lbnRzICAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTUKICAgOS4gIENoYW5nZWxvZyAgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE2CiAgIDEw LiBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAxOAogICAgIDEwLjEuIE5vcm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTgKICAgICAxMC4yLiBJbmZvcm1hdGl2ZSBSZWZlcmVu Y2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE4CiAgIEF1dGhvcidzIEFk ZHJlc3MgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAx OQoKCgoKCgoKCgoKCgoKClNoZWxieSAgICAgICAgICAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIg MTUsIDIwMTEgICAgICAgICAgICAgICBbUGFnZSAyXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAg ICAgICBDb1JFIExpbmsgRm9ybWF0ICAgICAgICAgICAgICAgICAgTWFyY2ggMjAxMQoKCjEuICBJ bnRyb2R1Y3Rpb24KCiAgIFRoZSBDb25zdHJhaW5lZCBSRVNUZnVsIEVudmlyb25tZW50cyAoQ29S RSkgd29ya2luZyBncm91cCBhaW1zIGF0CiAgIHJlYWxpemluZyB0aGUgUmVwcmVzZW50YXRpb25h bCBTdGF0ZSBUcmFuc2ZlciAoUkVTVCkgYXJjaGl0ZWN0dXJlCiAgIFtSRVNUXSBpbiBhIHN1aXRh YmxlIGZvcm0gZm9yIHRoZSBtb3N0IGNvbnN0cmFpbmVkIG5vZGVzIChlLmcuIDgtYml0CiAgIG1p Y3JvY29udHJvbGxlcnMgd2l0aCBsaW1pdGVkIG1lbW9yeSkgYW5kIG5ldHdvcmtzIChlLmcuIDZM b1dQQU4KICAgW1JGQzQ5NDRdKS4gIENvUkUgaXMgYWltZWQgYXQgTWFjaGluZS10by1NYWNoaW5l IChNMk0pIGFwcGxpY2F0aW9ucwogICBzdWNoIGFzIHNtYXJ0IGVuZXJneSBhbmQgYnVpbGRpbmcg YXV0b21hdGlvbi4KICAgCiAgIHtJcyB0aGlzIGRvY3VtZW50IGFpbWVkIG9ubHkgYXQgQ29BUCBh cHBsaWNhdGlvbnMsIG9yIGRvZXMgaXQgYXR0ZW1wdAogICB0byBiZSBhIG1vcmUgZ2VuZXJhbC1w dXJwb3NlIHNwZWMgdGhhdCBjYW4gYmUgdXNlZCB3aXRoIENvQVAgYW5kIAogICB3aXRoIG90aGVy IHByb3RvY29scz8gVGhhdCBpcywgdG8gd2hhdCBleHRlbnQgKGlmIGFueSkgc2hvdWxkICJDb1JF IgogICBiZSByZXBsYWNlZCBieSAiQ29BUCIgaW4gdGhpcyBkb2N1bWVudD8gRnVydGhlciBkb3du IGluIHRoaXMgc2VjdGlvbiAKICAgaXQgc2F5cyAiVGhlIENvUkUgTGluayBGb3JtYXQgaXMgY2Fy cmllZCBhcyBhIHBheWxvYWQiIC0gcHJlc3VtYWJseQogICB0aGlzIG1ha2VzIHNlbnNlIGluIENv QVAgLSBpcyB0aGVyZSBhbnkgb3RoZXIgcHJvdGNvbCB3aGVyZSBDb3JlIAogICBMaW5rIEZvcm1h dCBtaWdodCByZWFsaXN0aWNhbGx5IGJlIGV4cGVjdGVkIHRvIGJlIHVzZWQ/IElmIG5vdCwgaXQg Y291bGQKICAgc2ltcGxpZnkgdGhpbmdzIGlmIHRoaXMgZG9jdW1lbnQgd2FzIHdyaXR0ZW4gYXNz dW1pbmcgdGhlIGV4Y2x1c2l2ZQogICB1c2UgYnkgQ29BUC4gV2UgY291bGQgbGVhdmUgaXQgdG8g b3RoZXJzIHRvIHBpY2sgdGhpcyB1cCBhbmQgZ2VuZXJhbGlzZQogICBpdCBsYXRlci59CgogICBU aGUgZGlzY292ZXJ5IG9mIHJlc291cmNlcyBob3N0ZWQgYnkgYSBjb25zdHJhaW5lZCBzZXJ2ZXIg aXMgdmVyeQogICBpbXBvcnRhbnQgaW4gbWFjaGluZS10by1tYWNoaW5lIGFwcGxpY2F0aW9ucyB3 aGVyZSB0aGVyZSBhcmUgbm8KICAgaHVtYW5zIGluIHRoZSBsb29wIGFuZCBzdGF0aWMgaW50ZXJm YWNlcyByZXN1bHQgaW4gZnJhZ2lsaXR5LiAgVGhlCiAgIGRpc2NvdmVyeSBvZiByZXNvdXJjZXMg cHJvdmlkZWQgYnkgYW4gSFRUUCBbUkZDMjYxNl0gV2ViIFNlcnZlciBpcwogICB0eXBpY2FsbHkg Y2FsbGVkIFdlYiBEaXNjb3ZlcnkgYW5kIHRoZSBkZXNjcmlwdGlvbiBvZiByZWxhdGlvbnMKICAg YmV0d2VlbiByZXNvdXJjZXMgaXMgY2FsbGVkIFdlYiBMaW5raW5nIFtSRkM1OTg4XS4gIEluIHRo aXMgZG9jdW1lbnQKICAgd2UgcmVmZXIgdG8gdGhlIGRpc2NvdmVyeSBvZiByZXNvdXJjZXMgaG9z dGVkIGJ5IGEgY29uc3RyYWluZWQgd2ViCiAgIHNlcnZlciwgdGhlaXIgYXR0cmlidXRlcyBhbmQg b3RoZXIgcmVzb3VyY2UgcmVsYXRpb25zIGFzIENvUkUKICAgUmVzb3VyY2UgRGlzY292ZXJ5LgoK ICAgVGhlIG1haW4gZnVuY3Rpb24gb2Ygc3VjaCBhIGRpc2NvdmVyeSBtZWNoYW5pc20gaXMgdG8g cHJvdmlkZQogICBVbml2ZXJzYWwgUmVzb3VyY2UgSW5kaWNhdG9ycyAoVVJJcywgY2FsbGVkIGxp bmtzKSBmb3IgdGhlIHJlc291cmNlcwogICBob3N0ZWQgYnkgdGhlIHNlcnZlciwgdG9nZXRoZXIg d2l0aCBhdHRyaWJ1dGVzIG9mIHRob3NlCiAgIHJlc291cmNlcyBhbmQgcG9zc2libGUgZnVydGhl ciBsaW5rIHJlbGF0aW9ucy4gIEluIENvUkUgUmVzb3VyY2UgCiAgIERpc2NvdmVyeSB0aGlzCiAg IGNvbGxlY3Rpb24gb2YgbGlua3MgaXMgYWNjZXNzZWQgYXMgYSByZXNvdXJjZSBvZiBpdHMgb3du IChpbiBjb250cmFzdAogICB0byBIVFRQIExpbmsgSGVhZGVyIEZvcm1hdCBbUkZDNTk4OF0gd2hl cmUgbGlua3MgYXJlIGRlbGl2ZXJlZCBpbgogICBIVFRQIGhlYWRlcnMpIHtJcyB0aGF0IHJpZ2h0 P30uICBUaGlzIGRvY3VtZW50CiAgIHNwZWNpZmllcyBhIGxpbmsgZm9ybWF0IGZvciB1c2UgaW4g Q29SRSBSZXNvdXJjZSBEaXNjb3ZlcnkgYnkKICAgZXh0ZW5kaW5nIHRoZSBIVFRQIExpbmsgSGVh ZGVyIEZvcm1hdCBbUkZDNTk4OF0gc3RhbmRhcmQgdG8gZGVzY3JpYmUgdGhlc2UKICAgbGluayBk ZXNjcmlwdGlvbnMuICBUaGUgQ29SRSBMaW5rIEZvcm1hdCBpcyBjYXJyaWVkIGFzIGEgcGF5bG9h ZCBhbmQKICAgaXMgYXNzaWduZWQgYW4gSW50ZXJuZXQgbWVkaWEgdHlwZS4gIEEgd2VsbC1rbm93 biBVUkkgIi8ud2VsbC1rbm93bi8KICAgY29yZSIgaXMgZGVmaW5lZCBhcyBhIGRlZmF1bHQgZW50 cnktcG9pbnQgZm9yIHJlcXVlc3RpbmcgdGhlIGxpc3Qgb2YKICAgbGlua3MgYWJvdXQgcmVzb3Vy Y2VzIGhvc3RlZCBieSBhIHNlcnZlciwgYW5kIHRodXMgcGVyZm9ybWluZyBDb1JFCiAgIFJlc291 cmNlIERpc2NvdmVyeS4KCjEuMS4gIFdlYiBMaW5raW5nIGluIENvUkUKCiAgIFdoYXQgaXMgdGhl IGRpZmZlcmVuY2UgYmV0d2VlbiB0aGUgQ29SRSBMaW5rIEZvcm1hdCBhbmQgW1JGQzU5ODhdPwog ICBUZWNobmljYWxseSB0aGUgQ29SRSBMaW5rIEZvcm1hdCBpcyBhIHNlcmlhbGl6YXRpb24gb2Yg YSB0eXBlZCBsaW5rCiAgIGFzIHNwZWNpZmllZCBpbiBbUkZDNTk4OF0sIHVzZWQgdG8gZGVzY3Jp YmUgcmVsYXRpb25zaGlwcyBiZXR3ZWVuCiAgIHJlc291cmNlcywgc28tY2FsbGVkICJXZWIgTGlu a2luZyIuICBJbiB0aGlzIHNwZWNpZmljYXRpb24gV2ViCiAgIExpbmtpbmcgaXMgZXh0ZW5kZWQg d2l0aCBzcGVjaWZpYyBjb25zdHJhaW5lZCBNMk0gYXR0cmlidXRlcywgbGlua3MKICAgYXJlIGNh cnJpZWQgYXMgYSBtZXNzYWdlIHBheWxvYWQgcmF0aGVyIHRoYW4gaW4gYW4gSFRUUCBMaW5rIEhl YWRlciwKICAgYW5kIGEgZGVmYXVsdCBpbnRlcmZhY2UgaXMgZGVmaW5lZCB0byBkaXNjb3ZlciBy ZXNvdXJjZXMgaG9zdGVkIGJ5IGEKICAgc2VydmVyLiAgVGhpcyBzcGVjaWZpY2F0aW9uIGFsc28g ZGVmaW5lcyBhIG5ldyByZWxhdGlvbiB0eXBlICJob3N0cyIsCiAgIHdoaWNoIGluZGljYXRlcyB0 aGF0IHRoZSByZXNvdXJjZSBpcyBob3N0ZWQgYnkgdGhlIHNlcnZlciBmcm9tIHdoaWNoCiAgIHRo ZSBsaW5rIGRvY3VtZW50IHdhcyByZXF1ZXN0ZWQuCgogICBXaHkgbm90IGp1c3QgdXNlIHRoZSBI VFRQIExpbmsgSGVhZGVyPyAgSW4gSFRUUCwgdGhlIExpbmsgSGVhZGVyIGNhbgogICBiZSB1c2Vk IHRvIGNhcnJ5IGxpbmsgaW5mb3JtYXRpb24gYWJvdXQgYSByZXNvdXJjZSBhbG9uZyB3aXRoIGFu IEhUVFAKCgoKU2hlbGJ5ICAgICAgICAgICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAxNSwgMjAx MSAgICAgICAgICAgICAgIFtQYWdlIDNdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIENv UkUgTGluayBGb3JtYXQgICAgICAgICAgICAgICAgICBNYXJjaCAyMDExCgoKICAgcmVzcG9uc2Uu ICBUaGlzIHdvcmtzIHdlbGwgZm9yIHRoZSB0eXBpY2FsIHVzZSBjYXNlIGZvciBhIHdlYiBzZXJ2 ZXIKICAgYW5kIGJyb3dzZXIsIHdoZXJlIGZ1cnRoZXIgaW5mb3JtYXRpb24gYWJvdXQgYSBwYXJ0 aWN1bGFyIHJlc291cmNlIGlzCiAgIHVzZWZ1bCBhZnRlciBhY2Nlc3NpbmcgaXQuICBJbiBDb1JF IHRoZSBtYWluIHVzZSBjYXNlIGZvciBXZWIgTGlua2luZwogICBpcyB0aGUgZGlzY292ZXJ5IG9m IHdoaWNoIHJlc291cmNlcyBhIHNlcnZlciBob3N0cyBpbiB0aGUgZmlyc3QKICAgcGxhY2UuICBB bHRob3VnaCBzb21lIHJlc291cmNlcyBtYXkgaGF2ZSBmdXJ0aGVyIGxpbmtzIGFzc29jaWF0ZWQK ICAgd2l0aCB0aGVtLCB0aGlzIGlzIGV4cGVjdGVkIHRvIGJlIGFuIGV4Y2VwdGlvbi4gIEZvciB0 aGF0IHJlYXNvbiB0aGUKICAgQ29SRSBMaW5rIEZvcm1hdCBzZXJpYWxpemF0aW9uIGlzIGNhcnJp ZWQgYXMgYSByZXNvdXJjZQogICByZXByZXNlbnRhdGlvbiBvZiBhIHdlbGwta25vd24gVVJJLiAg VGhlIENvUkUgTGluayBGb3JtYXQgZG9lcyByZS11c2UKICAgdGhlIGZvcm1hdCBvZiB0aGUgSFRU UCBMaW5rIEhlYWRlciBzZXJpYWxpemF0aW9uIGRlZmluZWQgaW4KICAgW1JGQzU5ODhdLgoKMS4y LiAgVXNlIENhc2VzCgogICBUeXBpY2FsIHVzZSBjYXNlcyBmb3IgV2ViIExpbmtpbmcgb24gdG9k YXkncyB3ZWIgaW5jbHVkZQogICBkZXNjcmliaW5nIHRoZSBhdXRob3Igb2YgYSB3ZWIgcGFnZSwg b3IgZGVzY3JpYmluZyByZWxhdGlvbnMgYmV0d2VlbgogICB3ZWIgcGFnZXMgKG5leHQgY2hhcHRl ciwgcHJldmlvdXMgY2hhcHRlciBldGMpLiAgV2ViIExpbmtpbmcgY2FuCiAgIGFsc28gYmUgYXBw bGllZCB0byBNMk0gYXBwbGljYXRpb25zLCB3aGVyZSB0eXBlZCBsaW5rcyBhcmUgdXNlZCB0bwog ICBhc3Npc3QgYSBtYWNoaW5lIGNsaWVudCBpbiBmaW5kaW5nIGFuZCB1bmRlcnN0YW5kaW5nIGhv dyB0byB1c2UKICAgcmVzb3VyY2VzIG9uIGEgc2VydmVyLiAgVGhpcyBzZWN0aW9uIHByZXNlbnRz IHNvbWUgdXNlIGNhc2VzIHRoYXQgZGVzY3JpYmUKICAgaG93IHRoZSBDb1JFIExpbmsgRm9ybWF0 IGNvdWxkIGJlIHVzZWQgaW4gTTJNIGFwcGxpY2F0aW9ucy4gRm9yCiAgIGZ1cnRoZXIgdGVjaG5p Y2FsIGV4YW1wbGVzIHNlZSBTZWN0aW9uIDUuICBBcyB0aGVyZSBhcmUgYSBsYXJnZSByYW5nZQog ICBvZiBNMk0gYXBwbGljYXRpb25zLCB0aGVzZSB1c2UgY2FzZXMgYXJlIHB1cnBvc2VseSBnZW5l cmljLiAgVGhpcwogICBkb2N1bWVudCBhc3N1bWVzIHRoYXQgZGlmZmVyZW50IGRlcGxveW1lbnRz IG9yIGFwcGxpY2F0aW9uIGRvbWFpbnMKICAgd2lsbCBkZWZpbmUgdGhlIGFwcHJvcHJpYXRlIFJF U1QgaW50ZXJmYWNlIGRlc2NyaXB0aW9ucyBhbG9uZyB3aXRoCiAgIFJlc291cmNlIFR5cGVzIHRv IG1ha2UgZGlzY292ZXJ5IG1lYW5pbmdmdWwuCiAgIHtTaG91bGQgY2FwaXRhbGlzYXRpb24gYmUg dXNlZCBmb3IgIlJlc291cmNlIFR5cGVzIj8gQm90aCAiUmVzb3VyY2UKICAgVHlwZXMiIGFuZCAi cmVzb3VyY2UgdHlwZXMiIGFyZSB1c2VkIGluIHRoaXMgZG9jdW1lbnQuIEkgc3VnZ2VzdCAKICAg ZWRpdGluZyB0byBhY2hpZXZlIGNvbnNpc3RlbmN5Ln0KCjEuMi4xLiAgRGlzY292ZXJ5CgogICBJ biBNMk0gYXBwbGljYXRpb25zLCBmb3IgZXhhbXBsZSBob21lIG9yIGJ1aWxkaW5nIGF1dG9tYXRp b24sIHRoZXJlIGlzCiAgIGEgbmVlZCBmb3IgbG9jYWwgY2xpZW50cyBhbmQgc2VydmVycyB0byBm aW5kIGFuZCBpbnRlcmFjdCB3aXRoIGVhY2gKICAgb3RoZXIgd2l0aG91dCBodW1hbiBpbnRlcnZl bnRpb24uICBUaGUgQ29SRSBMaW5rIEZvcm1hdCBjYW4gYmUgdXNlZAogICBieSBzZXJ2ZXJzIGlu IHN1Y2ggZW52aXJvbm1lbnRzIHRvIGVuYWJsZSBSZXNvdXJjZSBEaXNjb3Zlcnkgb2YgdGhlCiAg IHJlc291cmNlcyBob3N0ZWQgYnkgdGhlIHNlcnZlci4KCiAgIFJlc291cmNlIERpc2NvdmVyeSBj YW4gYmUgcGVyZm9ybWVkIGVpdGhlciB1bmljYXN0IG9yIG11bHRpY2FzdC4KICAgV2hlbiBhIHNl cnZlcidzIElQIGFkZHJlc3MgaXMgYWxyZWFkeSBrbm93biwgZWl0aGVyIGEgcHJpb3JpIG9yCiAg IHJlc29sdmVkIHZpYSB0aGUgRG9tYWluIE5hbWUgU3lzdGVtIChETlMpLCB1bmljYXN0IGRpc2Nv dmVyeSBpcwogICBwZXJmb3JtZWQgaW4gb3JkZXIgdG8gbG9jYXRlIHRoZSBlbnRyeSBwb2ludCB0 byB0aGUgcmVzb3VyY2Ugb2YKICAgaW50ZXJlc3QuICBUaGlzIGlzIHBlcmZvcm1lZCB1c2luZyBh IEdFVCB0byAvLndlbGwta25vd24vY29yZSBvbiB0aGUKICAgc2VydmVyLCB3aGljaCByZXR1cm5z IGEgcGF5bG9hZCBpbiB0aGUgQ29SRSBMaW5rIEZvcm1hdC4gIEEgY2xpZW50CiAgIHdvdWxkIHRo ZW4gbWF0Y2ggdGhlIGFwcHJvcHJpYXRlIFJlc291cmNlIFR5cGUsIEludGVyZmFjZSBEZXNjcmlw dGlvbgogICBhbmQgcG9zc2libGUgQ29udGVudC1UeXBlIGZvciBpdHMgYXBwbGljYXRpb24uICBU aGVzZSBhdHRyaWJ1dGVzIG1heQogICBhbHNvIGJlIGluY2x1ZGVkIGluIHRoZSBxdWVyeSBzdHJp bmcgaW4gb3JkZXIgdG8gZmlsdGVyIHRoZSBudW1iZXIgb2YKICAgbGlua3MgcmV0dXJuZWQgaW4g YSByZXNwb25zZS4KCiAgIE11bHRpY2FzdCByZXNvdXJjZSBkaXNjb3ZlcnkgaXMgdXNlZnVsIHdo ZW4gYSBjbGllbnQgbmVlZHMgdG8gbG9jYXRlCiAgIGEgcmVzb3VyY2Ugd2l0aGluIGEgbGltaXRl ZCBzY29wZSwgYW5kIHRoYXQgc2NvcGUgc3VwcG9ydHMgSVAKICAgbXVsdGljYXN0LiAgQSBHRVQg cmVxdWVzdCB0byB0aGUgYXBwcm9wcmlhdGUgbXVsdGljYXN0IGFkZHJlc3MgaXMKCgoKU2hlbGJ5 ICAgICAgICAgICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAxNSwgMjAxMSAgICAgICAgICAgICAg IFtQYWdlIDRdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIENvUkUgTGluayBGb3JtYXQg ICAgICAgICAgICAgICAgICBNYXJjaCAyMDExCgoKICAgbWFkZSBmb3IgLy53ZWxsLWtub3duL2Nv cmUuICBJbiBvcmRlciB0byBsaW1pdCB0aGUgbnVtYmVyIGFuZCBzaXplIG9yCiAgIHJlc3BvbnNl cywgYSBxdWVyeSBzdHJpbmcgd2l0aCB0aGUga25vd24gYXR0cmlidXRlcyBpcyByZWNvbW1lbmRl ZC4KICAgVHlwaWNhbGx5IGEgcmVzb3VyY2Ugd291bGQgYmUgZGlzY292ZXJlZCBiYXNlZCBvbiBp dHMgUmVzb3VyY2UgVHlwZQogICBhbmQvb3IgSW50ZXJmYWNlIERlc2NyaXB0aW9uLCBhbG9uZyB3 aXRoIHBvc3NpYmxlIGFwcGxpY2F0aW9uCiAgIHNwZWNpZmljIGF0dHJpYnV0ZXMuCgoxLjIuMi4g IFJlc291cmNlIENvbGxlY3Rpb25zCgogICBSRVNUZnVsIGRlc2lnbnMgb2YgTTJNIGludGVyZmFj ZXMgb2Z0ZW4gbWFrZSB1c2Ugb2YgY29sbGVjdGlvbnMgb2YKICAgcmVzb3VyY2VzLiAgCiAgIHtJ IGFkZGVkIGEgdmVyYiB0byB0aGUgbmV4dCBzZW50ZW5jZSAtIHBsZWFzZSBjaGVjayBmb3IgbWVh bmluZyF9CiAgIEZvciBleGFtcGxlIGEgY29sbGVjdGlvbiBjb3VsZCBiZSBhbiBpbmRleCBvZiB0 ZW1wZXJhdHVyZSBzZW5zb3JzIG9uIGEgZGF0YQogICBjb2xsZWN0aW9uIG5vZGUgb3IgYSBsaXN0 IG9mIGFsYXJtcyBvbiBhIGhvbWUgc2VjdXJpdHkgY29udHJvbGxlci4KICAgVGhlIENvUkUgTGlu ayBGb3JtYXQgY2FuIGJlIHVzZWQgdG8gZmluZCB0aGUKICAgZW50cnkgcG9pbnQgdG8gYSBjb2xs ZWN0aW9uIGFuZCB0byB0cmF2ZXJzZSBpdHMgbWVtYmVycy4gIFRoZSBlbnRyeQogICBwb2ludCBv ZiBhIGNvbGxlY3Rpb24gd291bGQgYWx3YXlzIGJlIGluY2x1ZGVkIGluIC8ud2VsbC1rbm93bi9j b3JlCiAgIHRvIGVuYWJsZSBpdHMgZGlzY292ZXJ5LiAgVGhlIG1lbWJlcnMgb2YgdGhlIGNvbGxl Y3Rpb24gY2FuIGJlCiAgIGRlZmluZWQgZWl0aGVyIHRocm91Z2ggdGhlIGludGVyZmFjZSBkZXNj cmlwdGlvbiBvZiB0aGUgcmVzb3VyY2UKICAgYWxvbmcgd2l0aCBhIHBhcmFtZXRlciByZXNvdXJj ZSBmb3IgdGhlIHNpemUgb2YgdGhlIGNvbGxlY3Rpb24sIG9yIGJ5CiAgIHVzaW5nIHRoZSBsaW5r IGZvcm1hdCB0byBkZXNjcmliZSBlYWNoIHJlc291cmNlIGluIHRoZSBjb2xsZWN0aW9uLgogICBU aGVzZSBsaW5rcyBjb3VsZCBiZSBsb2NhdGVkIHVuZGVyIC8ud2VsbC1rbm93bi9jb3JlIG9yIGhv c3RlZCBmb3IKICAgZXhhbXBsZSBpbiB0aGUgcm9vdCByZXNvdXJjZSBvZiB0aGUgY29sbGVjdGlv bi4KICAgCiAgIHtJIGFtIG5vdCBzdXJlIHRoaXMgZG9jdW1lbnQgaXMgc3VmZmljaWVudGx5IGNs ZWFyIGFib3V0IHdoYXQgaXMKICAgbWVhbnQgYnkgImluZGV4IiwgImxpc3QiIGFuZCAiY29sbGVj dGlvbiIgYXMgdXNkIGluIHRoZSBhYm92ZSBwYXJhZ3JhcGguCiAgIENhbiBmdWxsZXIgZGVzY3Jp cHRpb25zIGFuZCBleGFtcGxlcyBiZSBwcm92aWRlZD99CgoxLjIuMy4gIFJlc291cmNlIERpcmVj dG9yeQoKICAgSW4gbWFueSBkZXBsb3ltZW50IHNjZW5hcmlvcywgZm9yIGV4YW1wbGUgY29uc3Ry YWluZWQgbmV0d29ya3Mgd2l0aAogICBzbGVlcGluZyBzZXJ2ZXJzLCBvciBsYXJnZSBNMk0gZGVw bG95bWVudHMgd2l0aCBiYW5kd2lkdGggbGltaXRlZAogICBhY2Nlc3MgbmV0d29ya3MsIGl0IG1h a2VzIHNlbnNlIHRvIGRlcGxveSByZXNvdXJjZSBkaXJlY3RvcnkgZW50aXRpZXMKICAgd2hpY2gg c3RvcmUgbGlua3MgdG8gcmVzb3VyY2VzIHN0b3JlZCBvbiBvdGhlciBzZXJ2ZXJzLiAgVGhpbmsg b2YKICAgdGhpcyBhcyBhIGxpbWl0ZWQgc2VhcmNoIGVuZ2luZSBmb3IgY29uc3RyYWluZWQgTTJN IHJlc291cmNlcy4KCiAgIFRoZSBDb1JFIExpbmsgRm9ybWF0IGNhbiBiZSB1c2VkIGJ5IGEgc2Vy dmVyIHRvIHJlZ2lzdGVyIHJlc291cmNlcwogICB3aXRoIGEgcmVzb3VyY2UgZGlyZWN0b3J5LCBv ciB0byBhbGxvdyBhIHJlc291cmNlIGRpcmVjdG9yeSB0byBwb2xsCiAgIGZvciByZXNvdXJjZXMu ICBSZXNvdXJjZSBwb2xsaW5nIHVzZXMgdGhlIHNhbWUgcHJvY2VzcyBhcyB1bmljYXN0IG9yCiAg IG11bHRpY2FzdCBkaXNjb3ZlcnksIGhvd2V2ZXIgdXN1YWxseSB3aXRob3V0IGZpbHRlcmluZy4g IFJlc291cmNlCiAgIHJlZ2lzdHJhdGlvbiBjYW4gYmUgYWNoaXZlZCBieSBoYXZpbmcgZWFjaCBz ZXJ2ZXIgUE9TVCB0aGVpcgogICByZXNvdXJjZXMgdG8gLy53ZWxsLWtub3duL2NvcmUgb24gdGhl IHJlc291cmNlIGRpcmVjdG9yeS4gIFRoaXMgaW4KICAgdHVybiBhZGRzIGxpbmtzIHRvIHRoZSBy ZXNvdXJjZSBkaXJlY3RvcnkgdW5kZXIgYW4gYXBwcm9wcmlhdGUKICAgcmVzb3VyY2UuICBUaGVz ZSBsaW5rcyBjYW4gdGhlbiBiZSBkaXNjb3ZlcmVkIGJ5IGFueSBjbGllbnQgYnkgYQogICBwZXJm b3JtaW5nIGEgR0VUIG9uIHRoZSByZXNvdXJjZSBkaXJlY3RvcnkgdXNpbmcgYSBxdWVyeSBzdHJp bmcKICAgZmlsdGVyLgoKMS4zLiAgVGVybWlub2xvZ3kKCiAgIFRoZSBrZXkgd29yZHMgIk1VU1Qi LCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIiwKICAgIlNIT1VM RCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZCAiT1BUSU9OQUwiIGlu IHRoaXMKICAgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiBb UkZDMjExOV0uCgogICBUaGlzIHNwZWNpZmljYXRpb24gcmVxdWlyZXMgcmVhZGVycyB0byBiZSBm YW1pbGlhciB3aXRoIGFsbCB0aGUgdGVybXMKICAgYW5kIGNvbmNlcHRzIHRoYXQgYXJlIGRpc2N1 c3NlZCBpbiBbUkZDNTk4OF0uICBUaGlzIHNwZWNpZmljYXRpb24KCgoKU2hlbGJ5ICAgICAgICAg ICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAxNSwgMjAxMSAgICAgICAgICAgICAgIFtQYWdlIDVd CgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIENvUkUgTGluayBGb3JtYXQgICAgICAgICAg ICAgICAgICBNYXJjaCAyMDExCgoKICAgbWFrZXMgdXNlIG9mIHRoZSBmb2xsb3dpbmcgdGVybWlu b2xvZ3k6CgogICBXZWIgTGlua2luZwogICAgICBBIGZyYW1ld29yayBmb3IgaW5kaWNhdGluZyB0 aGUgcmVsYXRpb25zaGlwcyBiZXR3ZWVuIHdlYgogICAgICByZXNvdXJjZXMuCgogICBMaW5rCiAg ICAgIEFsc28gY2FsbGVkICJ0eXBlZCBsaW5rcyIgaW4gUkZDNTk4OC4gIEEgbGluayBpcyBhIHR5 cGVkCiAgICAgIGNvbm5lY3Rpb24gYmV0d2VlbiB0d28gcmVzb3VyY2VzIGlkZW50aWZpZWQgYnkg VVJJcy4gIEl0IGlzIG1hZGUgdXAgb2YgYQogICAgICBjb250ZXh0IFVSSSwgYSBsaW5rIHJlbGF0 aW9uIHR5cGUsIGEgdGFyZ2V0IFVSSSwgYW5kIG9wdGlvbmFsCiAgICAgIHRhcmdldCBhdHRyaWJ1 dGVzLiB7QSBzZWFyY2ggb2YgUkZDNTk4OCBkb2VzIG5vdCBzdWdnZXN0IHRoYXQKICAgICAgInR5 cGVkIGxpbmtzIiBpcyBtdWNoIHVzZWQgaW4gdGhhdCBkb2N1bWVudC4uLn0KCiAgIExpbmsgRm9y bWF0CiAgICAgIEEgcGFydGljdWxhciBzZXJpYWxpc2F0aW9uIG9mIHR5cGVkIGxpbmtzLgoKICAg Q29SRSBMaW5rIEZvcm1hdAogICAgICBBIHBhcnRpY3VsYXIgc2VyaWFsaXphdGlvbiBvZiB0eXBl ZCBsaW5rcyBiYXNlZCB0aGUgSFRUUCBMaW5rCiAgICAgIEhlYWRlciBzZXJpYWxpemF0aW9uIGRl ZmluZWQgaW4gU2VjdGlvbiA1IG9mIFJGQzU5ODgsIGJ1dCBjYXJyaWVkCiAgICAgIGFzIGEgcmVz b3VyY2UgcmVwcmVzZW50YXRpb24gd2l0aCBhbiAiYXBwbGljYXRpb24vbGluay1mb3JtYXQiCiAg ICAgIEludGVybmV0IG1lZGlhIHR5cGUuIAoKICAgQXR0cmlidXRlCiAgICAgIENhbGxlZCAiVGFy Z2V0IEF0dHJpYnV0ZSIgaW4gUkZDNTk4OC4gIEEgc2V0IG9mIGtleS92YWx1ZQogICAgICBwYWly cyB0aGF0IGRlc2NyaWJlIHRoZSBsaW5rIG9yIGl0cyB0YXJnZXQuCgogICBDb1JFIFJlc291cmNl IERpc2NvdmVyeQogICAgICBUaGUgcHJvY2VzcyBieSB3aGljaCBhIGNsaWVudCBkaXNjb3ZlcnMg dGhlIGxpc3Qgb2YgcmVzb3VyY2VzIGhvc3RlZAogICAgICBieSBhIHNlcnZlciwgdGhlaXIgYXR0 cmlidXRlcyBhbmQgb3RoZXIgbGluayByZWxhdGlvbnMgYnkgYWNjZXNzaW5nIAogICAgICAvLndl bGwta25vd24vY29yZS4KCgoyLiAgQ29SRSBMaW5rIEZvcm1hdAoKICAgVGhlIENvUkUgTGluayBG b3JtYXQgZXh0ZW5kcyB0aGUgSFRUUCBMaW5rIEhlYWRlciBmb3JtYXQgc3BlY2lmaWVkIGluCiAg IFNlY3Rpb24gNSBvZiBbUkZDNTk4OF0uIFRoZSBMaW5rIEhlYWRlciBmb3JtYXQgaXMgc3BlY2lm aWVkIGluIAogICBBdWdtZW50ZWQgQmFja3VzLU5hdXIgRm9ybSAoQUJORikKICAgbm90YXRpb24g W1JGQzUyMzRdLiAgVGhlIGZvcm1hdCBkb2VzIG5vdCByZXF1aXJlIHNwZWNpYWwgWE1MIG9yCiAg IGJpbmFyeSBwYXJzaW5nLCBpcyBmYWlybHkgY29tcGFjdCwgYW5kIGlzIGV4dGVuc2libGUgLSBh bGwgaW1wb3J0YW50CiAgIGNoYXJhY3RlcmlzdGljcyBmb3IgQ29SRS4gIEl0IHNob3VsZCBiZSBu b3RlZCB0aGF0IHRoZSBMaW5rIEhlYWRlciBmb3JtYXQKICAgaXMganVzdCBvbmUgc2VyaWFsaXph dGlvbiBvZiB0eXBlZCBsaW5rcyBkZWZpbmVkIGluIFtSRkM1OTg4XS4KICAgT3RoZXIgbGluayBm b3JtYXRzIGRlZmluZWQgaW4gW1JGQzU5ODhdCiAgIGluY2x1ZGUgSFRNTCBsaW5rIGFuZCBBdG9t IGZlZWQgbGlua3MgW1JGQzQyODddLiB7Y29ycmVjdD8gfQogICBJdCBpcyBleHBlY3RlZCB0aGF0 IHJlc291cmNlcyBkaXNjb3ZlcmVkIGluIHRoZSBDb1JFIExpbmsgRm9ybWF0IG1heQogICBhbHNv IGJlIG1hZGUgYXZhaWxhYmxlIGluIGFsdGVybmF0aXZlIGZvcm1hdHMgb24gdGhlIGdyZWF0ZXIK ICAgSW50ZXJuZXQuIHt3aGF0IGRvZXMgdGhhdCBtZWFuP30gVGhlIENvUkUgTGluayBGb3JtYXQg aXMgb25seSBleHBlY3RlZAogICB0byBiZSBzdXBwb3J0ZWQgaW4gY29uc3RyYWluZWQgbmV0d29y a3MgYW5kIE0yTSBzeXN0ZW1zLgoKICAgU2VjdGlvbiA1IG9mIFtSRkM1OTg4XSBkb2VzIG5vdCBy ZXF1aXJlIGFuIEludGVybmV0IG1lZGlhIHR5cGUgZm9yIHRoZQogICBkZWZpbmVkIGxpbmsgZm9y bWF0LCBhcyBpdCB3YXMgZGVmaW5lZCB0byBiZSBjYXJyaWVkIGluIGFuIEhUVFAKICAgaGVhZGVy LiAgVGhpcyBzcGVjaWZpY2F0aW9uIHRodXMgZGVmaW5lcyBhIG5ldyBJbnRlcm5ldCBtZWRpYSB0 eXBlIAogICAiYXBwbGljYXRpb24vbGluay1mb3JtYXQiIGZvciB0aGUgQ29SRSBMaW5rIEZvcm1h dCAoc2VlIFNlY3Rpb24gNy40KS4KCgoKU2hlbGJ5ICAgICAgICAgICAgICAgICBFeHBpcmVzIFNl cHRlbWJlciAxNSwgMjAxMSAgICAgICAgICAgICAgIFtQYWdlIDZdCgwKSW50ZXJuZXQtRHJhZnQg ICAgICAgICAgICAgIENvUkUgTGluayBGb3JtYXQgICAgICAgICAgICAgICAgICBNYXJjaCAyMDEx CgoKICAgVGhlIENvUkUgTGluayBGb3JtYXQgdXNlcyB0aGUgQUJORiBkZXNjcmlwdGlvbiBhbmQg YXNzb2NpYXRlZCBydWxlcwogICBkZWZpbmVkIGluIFNlY3Rpb24gNSBvZiBbUkZDNTk4OF0uICBJ biBhZGRpdGlvbiwgdGhlIHBjaGFyIHJ1bGUgaXMgdGFrZW4gZnJvbQogICBbUkZDMzk4Nl0uICBU aGUgIkxpbms6IiB0ZXh0IGlzIG9taXR0ZWQgYXMgdGhhdCBpcyBwYXJ0IG9mIHRoZSBIVFRQCiAg IExpbmsgSGVhZGVyLiAgQXMgaW4gW1JGQzU5ODhdLCBtdWx0aXBsZSBsaW5rIGRlc2NyaXB0aW9u cyBhcmUKICAgc2VwYXJhdGVkIGJ5IGNvbW1hcy4gIE5vdGUgdGhhdCBjb21tYXMgY2FuIGFsc28g b2NjdXIgaW4gcXVvdGVkCiAgIHN0cmluZ3MgYW5kIFVSSXMgYnV0IGRvIG5vdCBlbmQgYSBkZXNj cmlwdGlvbi4gIAogICAKICAge1dlIHNlZW0gdG8gYmUgc2F5aW5nIHRoYXQgQ29SRSBMaW5rIEZv cm1hdCBpcyB0aGUgc2FtZSBhcyAiVGhlIExpbmsgCiAgIEhlYWRlciBGaWVsZCIgZGVzY3JpYmVk IGluIHNlY3Rpb24gNSBvZiBSRkM1OTg4LCBidXQgd2l0aCBzb21lIGRpZmZlcmVuY2VzLgogICBX b3VsZCBpdCBiZSBpbiBvcmRlciB0byBleHBsaWNpdGx5IGRlZmluZSB0aGUgX2FjdHVhbF8gZm9y bWF0IG9mCiAgIENvUkUgTGluayBGb3JtYXQgaW4gX3RoaXNfIGRvY3VtZW50PyBGb3IgZXhhbXBs ZSBieSBhZGRpbmcgYSBtb2RpZmllZAogICB2ZXJzaW9uIG9mIHRoZSBBQk5GIGRpYWdyYW0gZnJv bSBTZWN0aW9uIDUgb2YgUkZDNTk4OC4gVGhhdCBtaWdodCBiZSAKICAgZWFzaWVyIHRvIHVuZGVy c3RhbmQgYW5kIHdvdWxkIGFsbG93IHRoZSBkaWZmZXJlbmNlcyB0byBiZSBzaG93bi59CiAgIAog ICBUaGUgQ29SRSBMaW5rIEZvcm1hdAogICBNVVNUIHVzZSBVVEYtOCBlbmNvZGluZywgd2hpY2gg U0hPVUxEIGJlIGluIE5GQyAoVW5pY29kZQogICBOb3JtYWxpemF0aW9uIEZvcm0gQykuICBTZWUg U2VjdGlvbiAzIG9mIFtSRkM1MTk4XSwgd2hpY2ggZXhwbGFpbnMKICAgd2h5IGl0IHVzZWZ1bCB0 byByZXByZXNlbnQgVW5pY29kZSBpbiBhIHNpbmdsZSB1bmlxdWUgZm9ybS4KICAge2NvYXAtMDUg cmVmZXJzIHRvICJBIFVuaWNvZGUgc3RyaW5nIHdoaWNoIGlzIGVuY29kZWQgdXNpbmcgVVRGLTgg CiAgIFtSRkMzNjI5XSBpbiBOZXQtVW5pY29kZSBmb3JtIFtSRkM1MTk4XS4iIC0gaXMgdGhpcyB0 aGUgc2FtZSBhcyAKICAgVW5pY29kZSBOb3JtYWxpemF0aW9uIEZvcm0gQz99CgoyLjEuICBUYXJn ZXQgYW5kIGNvbnRleHQgVVJJcwoKICAgRWFjaCBsaW5rIGNvbnZleXMgb25lIHRhcmdldCBVUkkg YXMgYSBVUkktcmVmZXJlbmNlIGluc2lkZSBhbmdsZQogICBicmFja2V0cyAoIjw+IikuICBUaGUg Y29udGV4dCBVUkkgb2YgYSBsaW5rIChhbHNvIGNhbGxlZCBiYXNlIFVSSSBpbgogICBbUkZDMzk4 Nl0pIGNvbnZleWVkIGluIHRoZSBDb1JFIExpbmsgRm9ybWF0IGlzIGJ5IGRlZmF1bHQgYnVpbHQg ZnJvbQogICB0aGUgc2NoZW1lIGFuZCBhdXRob3JpdHkgcGFydHMgb2YgdGhlIHRhcmdldCBVUkku ICBJbiB0aGUgYWJzZW5jZSBvZgogICB0aGlzIGluZm9ybWF0aW9uIGluIHRoZSB0YXJnZXQgVVJJ LCB0aGUgY29udGV4dCBVUkkgaXMgYnVpbHQgZnJvbSB0aGUKICAgc2NoZW1lIGFuZCBhdXRob3Jp dHkgdGhhdCB3YXMgdXNlZCBmb3IgcmVmZXJlbmNpbmcgdGhlIHJlc291cmNlCiAgIHJldHVybmlu ZyB0aGUgc2V0IG9mIGxpbmtzLCByZXBsYWNpbmcgdGhlIHBhdGggd2l0aCBhbiBlbXB0eSBwYXRo LgogICBUaHVzIGJ5IGRlZmF1bHQgbGlua3MgY2FuIGJlIHRob3VnaHQgb2YgYXMgZGVzY3JpYmlu ZyBhIHRhcmdldAogICByZXNvdXJjZSBob3N0ZWQgYnkgdGhlIHNlcnZlci4gIE90aGVyIHJlbGF0 aW9ucyBjYW4gYmUgZXhwcmVzc2VkIGJ5CiAgIGluY2x1ZGluZyBhbiBhbmNob3IgcGFyYW1ldGVy ICh3aGljaCBkZWZpbmVzIHRoZSBjb250ZXh0IFVSSSkgYWxvbmcKICAgd2l0aCBhbiBleHBsaWNp dCByZWxhdGlvbiBwYXJhbWV0ZXIuICBUaGlzIGlzIGFuIGltcG9ydGFudCBkaWZmZXJlbmNlCiAg IHRvIHRoZSB3YXkgdGhlIEhUVFAgTGluayBIZWFkZXIgZm9ybWF0IGlzIHVzZWQsIGFzIGl0IGlz IGluY2x1ZGVkIHt3aGF0CiAgIGlzIGluY2x1ZGVkP30gaW4KICAgdGhlIGhlYWRlciBvZiBhbiBI VFRQIHJlc3BvbnNlIGZvciBzb21lIFVSSSAodGhpcyBVUkkgaXMgYnkgZGVmYXVsdAogICB0aGUg Y29udGV4dCBVUkkpLiAgVGh1cyB0aGUgSFRUUCBMaW5rIEhlYWRlciBpcyBieSBkZWZhdWx0IHJl bGF0aW5nCiAgIHRoZSB0YXJnZXQgVVJJIHRvIHRoZSBVUkkgdGhhdCB3YXMgcmVxdWVzdGVkLiAg SW4gY29tcGFyaXNvbiwgdGhlCiAgIENvUkUgTGluayBGb3JtYXQgaW5jbHVkZXMgb25lIG9yIG1v cmUgbGlua3MsIGVhY2ggZGVzY3JpYmluZyBhCiAgIHJlc291cmNlIGhvc3RlZCBieSBhIHNlcnZl ciBieSBkZWZhdWx0LiAgT3RoZXIgcmVsYXRpb25zIGNhbiBiZQogICBleHByZXNzZWQgYnkgdXNp bmcgdGhlIGFuY2hvciBwYXJhbWV0ZXIuICBTZWUgU2VjdGlvbiA1IG9mIFtSRkMzOTg2XQogICBm b3IgYSBkZXNjcmlwdGlvbiBvZiBob3cgVVJJcyBhcmUgY29uc3RydWN0ZWQgZnJvbSBVUkkgcmVm ZXJlbmNlcy4KICAgCiAgIHtTb3JyeSAtIEkgZm91bmQgdGhhdCBwYXJhZ3JhcGggdmVyeSBkaWZm aWN1bHQgdG8gdW5kZXJzdGFuZC4gSSB0aGluayBpdCAKICAgd291bGQgYmVuZWZpdCBmcm9tIGVt YmVkZGVkIGV4YW1wbGVzLn0KCjIuMi4gIExpbmsgcmVsYXRpb25zCgogICBTaW5jZSBsaW5rcyBp biB0aGUgQ29SRSBMaW5rIEZvcm1hdCBhcmUgdHlwaWNhbGx5IHVzZWQge3R5cGljYWxseSB1c2Vk PwogICBPciBhbHdheXMgdXNlZD99IHRvIGRlc2NyaWJlCiAgIHJlc291cmNlcyBob3N0ZWQgYnkg YSBzZXJ2ZXIsIGFuZCB0aHVzIGluIHRoZSBhYnNlbmNlIG9mIHRoZSByZWxhdGlvbgogICBwYXJh bWV0ZXIgdGhlIG5ldyByZWxhdGlvbiB0eXBlICJob3N0cyIgaXMgYXNzdW1lZCAoc2VlIFNlY3Rp b24gNy4zKS4KICAgVGhlICJob3N0cyIgcmVsYXRpb24gdHlwZSBpbmRpY2F0ZXMgdGhhdCB0aGUg dGFyZ2V0IFVSSSBpcyBhIHJlc291cmNlCiAgIGhvc3RlZCBieSB0aGUgc2VydmVyIGdpdmVuIGJ5 IHRoZSBiYXNlIFVSSSwgb3IsIGlmIHByZXNlbnQsIHRoZQogICBhbmNob3IgcGFyYW1ldGVyLgoK ICAgVG8gZXhwcmVzcyBvdGhlciByZWxhdGlvbnMgYSBsaW5rIGNhbiBtYWtlIHVzZSBvZiBhbnkg cmVnaXN0ZXJlZAogICByZWxhdGlvbiBwYXJhbWV0ZXIgb3IgdGFyZ2V0IGF0dHJpYnV0ZXMgYnkg aW5jbHVkaW5nIHRoZSByZWxhdGlvbgogICBwYXJhbWV0ZXIuICBUaGUgY29udGV4dCBvZiBhIHJl bGF0aW9uIGNhbiBiZSBkZWZpbmVkIHVzaW5nIHRoZSBhbmNob3IKICAgcGFyYW1ldGVyLiAgSW4g dGhpcyB3YXksIHJlbGF0aW9ucyBiZXR3ZWVuIHJlc291cmNlcyBob3N0ZWQgb24gYQogICBzZXJ2 ZXIsIG9yIGJldHdlZW4gaG9zdGVkIHJlc291cmNlcyBhbmQgZXh0ZXJuYWwgcmVzb3VyY2VzIGNh biBiZQogICBleHByZXNzZWQuCgoKCgpTaGVsYnkgICAgICAgICAgICAgICAgIEV4cGlyZXMgU2Vw dGVtYmVyIDE1LCAyMDExICAgICAgICAgICAgICAgW1BhZ2UgN10KDApJbnRlcm5ldC1EcmFmdCAg ICAgICAgICAgICAgQ29SRSBMaW5rIEZvcm1hdCAgICAgICAgICAgICAgICAgIE1hcmNoIDIwMTEK CgoyLjMuICBVc2Ugb2YgYW5jaG9ycwoKICAgQXMgcGVyIFNlY3Rpb24gNS4yIG9mIFtSRkM1OTg4 XSBhIGxpbmsgZGVzY3JpcHRpb24gTUFZIGluY2x1ZGUgYW4KICAgImFuY2hvciIgYXR0cmlidXRl LCBpbiB3aGljaCBjYXNlIHRoZSBjb250ZXh0IGlzIHRoZSBVUkkgaW5jbHVkZWQgaW4KICAgdGhh dCBhdHRyaWJ1dGUuICBUaGlzIGlzIHVzZWQgdG8gZGVzY3JpYmUgYSByZWxhdGlvbnNoaXAgYmV0 d2VlbiB0d28KICAgcmVzb3VyY2VzLiAgQSBjb25zdW1pbmcgaW1wbGVtZW50YXRpb24gY2FuIGhv d2V2ZXIgY2hvb3NlIHRvIGlnbm9yZQogICBzdWNoIGxpbmtzLiAgSXQgaXMgbm90IGV4cGVjdGVk IHRoYXQgYWxsIGltcGxlbWVudGF0aW9ucyB3aWxsIGJlIGFibGUKICAgdG8gZGVyaXZlIHVzZWZ1 bCBpbmZvcm1hdGlvbiBmcm9tIGV4cGxpY2l0bHkgYW5jaG9yZWQgbGlua3MuCgoKMy4gIENvUkUg bGluayBleHRlbnNpb25zCgogICBUaGUgZm9sbG93aW5nIENvUkUtc3BlY2lmaWMgdGFyZ2V0IGF0 dHJpYnV0ZXMgYXJlIGRlZmluZWQuICBUaGVzZQogICBhdHRyaWJ1dGVzIGRlc2NyaWJlIGluZm9y bWF0aW9uIHVzZWZ1bCBpbiBhY2Nlc3NpbmcgdGhlIHRhcmdldCBsaW5rCiAgIG9mIHRoZSByZWxh dGlvbiwgYW5kIGluIHNvbWUgY2FzZXMgbWF5IGJlIFVSSXMuICBUaGVzZSBVUklzIE1VU1QgYmUK ICAgdHJlYXRlZCBhcyBpbmRpY2F0b3JzLCBhbmQgYXJlIG5vdCBtZWFudCB0byBiZSBhY3R1YWxs eSByZXRyaWV2ZWQKICAgbGlrZSBhIFVSTC4gIFdoZW4gYXR0cmlidXRlcyBhcmUgY29tcGFyZWQs IHRoZXkgTVVTVCBiZSBjb21wYXJlZCBhcwogICBzdHJpbmdzLiAgUmVsYXRpb25zaGlwcyB0byBy ZXNvdXJjZXMgdGhhdCBhcmUgbWVhbnQgdG8gYmUgcmV0cmlldmVkCiAgIHNob3VsZCBiZSBleHBy ZXNzZWQgYXMgc2VwYXJhdGUgbGlua3MgdXNpbmcgdGhlIGFuY2hvciBhdHRyaWJ1dGUgYW5kCiAg IHRoZSBhcHByb3ByaWF0ZSByZWxhdGlvbiB0eXBlLgoKCiAgICAgIGxpbmstZXh0ZW5zaW9uICAg ID0gKCAicnQiICI9IiBxdW90ZWQtc3RyaW5nICkKICAgICAgbGluay1leHRlbnNpb24gICAgPSAo ICJpZiIgIj0iIHF1b3RlZC1zdHJpbmcgKQogICAgICBsaW5rLWV4dGVuc2lvbiAgICA9ICggImN0 IiAiPSIgaW50ZWdlciApCiAgICAgIGxpbmstZXh0ZW5zaW9uICAgID0gKCAic3oiICI9IiBpbnRl Z2VyICkKICAgICAgaW50ZWdlciAgICAgICAgICAgPSAxKkRJR0lUCgoKMy4xLiAgUmVzb3VyY2Ug dHlwZSAncnQnIGF0dHJpYnV0ZQoKICAgVGhlIHJlc291cmNlIHR5cGUgInJ0IiBhdHRyaWJ1dGUg aXMgdXNlZCB0byBhc3NpZ24gYSBzZW1hbnRpY2FsbHkKICAgaW1wb3J0YW50IHR5cGUgdG8gYSBy ZXNvdXJjZS4ge3doYXQgaXMgYSAic2VtYW50aWNhbGx5IGltcG9ydGFudCB0eXBlP30gCiAgIE9u ZSBjYW4gdGhpbmsgb2YgdGhpcyBhcyBhIG5vdW4KICAgZGVzY3JpYmluZyB0aGUgcmVzb3VyY2Uu ICBGb3IgZXhhbXBsZSwgaW4gdGhlIGNhc2Ugb2YgYSB0ZW1wZXJhdHVyZSByZXNvdXJjZSB0aGlz CiAgIGNvdWxkIGJlIGFuIGFwcGxpY2F0aW9uLXNwZWNpZmljIHNlbWFudGljIHR5cGUgbGlrZQog ICAiT3V0ZG9vclRlbXBlcmF0dXJlIiwgYSBVbml2ZXJzYWwgUmVzb3VyY2UgTmFtZSAoVVJOKSBs aWtlCiAgICJ1cm46dGVtcGVyYXR1cmU6b3V0ZG9vciIgb3IgYSBVUkkgcmVmZXJlbmNpbmcgYSBz cGVjaWZpYyBjb25jZXB0IGluCiAgIGFuIG9udG9sb2d5IGxpa2UKICAgImh0dHA6Ly9zd2VldC5q cGwubmFzYS5nb3YvMi4wL3BoeXMub3dsI1RlbXBlcmF0dXJlIi4gIE11bHRpcGxlCiAgIHJlc291 cmNlIHR5cGUgYXR0cmlidXRlcyBNQVkgYXBwZWFyIGluIGEgbGluay4KCiAgIFRoZSByZXNvdXJj ZSB0eXBlIGF0dHJpYnV0ZSBpcyBub3QgbWVhbnQgdG8gdXNlZCB0byBhc3NpZ24gYSBodW1hbgog ICByZWFkYWJsZSBuYW1lIHRvIGEgcmVzb3VyY2UuICBUaGUgInRpdGxlIiBhdHRyaWJ1dGUgZGVm aW5lZCBpbgogICBbUkZDNTk4OF0gaXMgbWVhbnQgZm9yIHRoYXQgcHVycG9zZS4KICAgCiAgIHtU aGlzIGRvY3VtZW50IHNheXMgdGhhdCBpdCAiZXh0ZW5kcyIgUkZDNTk4OC4gRG9lcyB0aGlzIG1l YW4gdGhhdCAKICAgYW55IGF0dHJpYnV0ZSBkZWZpbmVkIGluIFJGQzU5ODggbWF5IGJlIHVzZWQg aW4gYSBDb1JFIExpbmsgRm9ybWF0PwogICBSRkM1OTg4IGRlZmluZXMgImhyZWZsYW5nIiwgIm1l ZGlhIiwgInRpdGxlIiwgInRpdGxlKiIsICJ0eXBlIiBpbiA1LjQuCiAgIEFyZSB0aGVzZSBhbGwg bWVhbmluZ2Z1bCBpbiBDb1JFIExpbmsgRm9ybWF0PyBXb3VsZCBpdCBiZSBoZWxwZnVsIHRvCiAg IGJlIGV4cGxpY2l0IGFib3V0IHRoaXM/IFNlZSB0aGUgbm90ZSBhYm92ZSBhYm91dCBkZWZpbmlu ZyB0aGUgQ29SRQogICBMaW5rIEZvcm1hdCBpbiBfdGhpc18gZG9jdW1lbnQufQoKCgoKU2hlbGJ5 ICAgICAgICAgICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAxNSwgMjAxMSAgICAgICAgICAgICAg IFtQYWdlIDhdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIENvUkUgTGluayBGb3JtYXQg ICAgICAgICAgICAgICAgICBNYXJjaCAyMDExCgoKMy4yLiAgSW50ZXJmYWNlIGRlc2NyaXB0aW9u ICdpZicgYXR0cmlidXRlCgogICBUaGUgaW50ZXJmYWNlIGRlc2NyaXB0aW9uICJpZiIgYXR0cmli dXRlIGlzIHVzZWQgdG8gcHJvdmlkZSBhIG5hbWUsCiAgIFVSSSBvciBVUk4gaW5kaWNhdGluZyBh IHNwZWNpZmljIGludGVyZmFjZSBkZWZpbml0aW9uIHVzZWQgdG8KICAgaW50ZXJhY3Qgd2l0aCB0 aGUgdGFyZ2V0IHJlc291cmNlLiAgT25lIGNhbiB0aGluayBvZiB0aGlzIGFzCiAgIGRlc2NyaWJp bmcgdmVyYnMgdXNhYmxlIG9uIGEgcmVzb3VyY2UuICBUaGUgaW50ZXJmYWNlIGRlc2NyaXB0aW9u CiAgIGF0dHJpYnV0ZSBpcyBtZWFudCB0byBkZXNjcmliZSB0aGUgZ2VuZXJpYyBSRVNUIGludGVy ZmFjZSB0byBpbnRlcmFjdAogICB3aXRoIGEgcmVzb3VyY2Ugb3IgYSBzZXQgb2YgcmVzb3VyY2Vz LiAgSXQgaXMgZXhwZWN0ZWQgdGhhdCBhbgogICBpbnRlcmZhY2UgZGVzY3JpcHRpb24gd2lsbCBi ZSByZS11c2VkIGJ5IGRpZmZlcmVudCByZXNvdXJjZSB0eXBlcy4KICAgRm9yIGV4YW1wbGUgdGhl IHJlc291cmNlIHR5cGVzICJPdXRkb29yVGVtcGVyYXR1cmUiLCAiRGV3UG9pbnQiIGFuZAogICAi UmVsSHVtaWRpdHkiIGNvdWxkIGFsbCBiZSBhY2Nlc3NpYmxlIHVzaW5nIHRoZSBpbnRlcmZhY2Ug ZGVzY3JpcHRpb24KICAgImh0dHA6Ly93d3cuZXhhbXBsZS5vcmcvbXlhcHAud2FkbCNzZW5zb3Ii LgoKICAgVGhlIGludGVyZmFjZSBkZXNjcmlwdGlvbiBjb3VsZCBiZSBmb3IgZXhhbXBsZSB0aGUg VVJJIG9mIGEgV2ViCiAgIEFwcGxpY2F0aW9uIERlc2NyaXB0aW9uIExhbmd1YWdlIChXQURMKSBk ZWZpbml0aW9uIG9mIHRoZSB0YXJnZXQKICAgcmVzb3VyY2UgImh0dHA6Ly93d3cuZXhhbXBsZS5v cmcvbXlhcHAud2FkbCNzZW5zb3IiLCBhIFVSTiBpbmRpY2F0aW5nCiAgIHRoZSB0eXBlIG9mIGlu dGVyZmFjZSB0byB0aGUgcmVzb3VyY2UgInVybjpteWFwcDpzZW5zb3IiLCBvciBhbgogICBhcHBs aWNhdGlvbi1zcGVjaWZpYyBuYW1lICJTZW5zb3IiLiAgTXVsdGlwbGUgaW50ZXJmYWNlIGRlc2Ny aXB0aW9uCiAgIGF0dHJpYnV0ZXMgTUFZIGFwcGVhciBpbiBhIGxpbmsuCgozLjMuICBDb250ZW50 LXR5cGUgY29kZSAnY3QnIGF0dHJpYnV0ZQoKICAgVGhlIENvbnRlbnQtdHlwZSBjb2RlICJjdCIg YXR0cmlidXRlIHByb3ZpZGVzIGEgaGludCBhYm91dCB0aGUKICAgSW50ZXJuZXQgbWVkaWEgdHlw ZSB0aGlzIHJlc291cmNlIHJldHVybnMuICBOb3RlIHRoYXQgdGhpcyBpcyBvbmx5IGEKICAgaGlu dCwgYW5kIGRvZXMgbm90IG92ZXJyaWRlIHRoZSBDb250ZW50LXR5cGUgT3B0aW9uIG9mIGEgQ29B UAogICByZXNwb25zZSBvYnRhaW5lZCBieSBhY3R1YWxseSBmb2xsb3dpbmcgdGhlIGxpbmsuICBU aGUgdmFsdWUgaXMgaW4KICAgdGhlIENvQVAgaWRlbnRpZmllciBjb2RlIGZvcm1hdCBhcyBhIGRl Y2ltYWwgQVNDSUkgaW50ZWdlcgogICBbSS1ELmlldGYtY29yZS1jb2FwXS4gIEZvciBleGFtcGxl IGFwcGxpY2F0aW9uL3htbCB3b3VsZCBiZSBpbmRpY2F0ZWQKICAgYXMgImN0PTQxIi4gIElmIG5v IENvbnRlbnQtdHlwZSBjb2RlIGF0dHJpYnV0ZSBpcyBwcmVzZW50IHRoZW4KICAgbm90aGluZyBh Ym91dCB0aGUgdHlwZSBjYW4gYmUgYXNzdW1lZC4gIFRoZSBDb250ZW50LXR5cGUgY29kZQogICBh dHRyaWJ1dGUgTVVTVCBOT1QgYXBwZWFyIG1vcmUgdGhhbiBvbmNlIGluIGEgbGluay4KICAgCiAg IHtXZSBhcmUgZGVhbGluZyB3aXRoIGNvbnN0cmFpbmVkIG5vZGVzIGluIChwcmVzdW1hYmx5KSBh IAogICB0aWdodGx5IGRlZmluZWQgYXBwbGljYXRpb24gZG9tYWluIChzbWFydCBlbmVyZ3ksIGhv bWUgYXV0b21hdGlvbiBldGMpLgogICBJIHdvdWxkIGhhdmUgaG9wZWQgdGhhdCBhIHNlcnZlciB3 b3VsZCBiZSBhYmxlIHRvIHJlc3BvbmQgd2l0aCBhCiAgICJmaXJtIiBjb250ZW50IHR5cGUgcmF0 aGVyIHRoYW4gYSAiaGludCIuIFdoYXQgdXNlIGlzIGEgdGVtcGVyYXR1cmUKICAgc2Vuc29yICJo aW50aW5nIiB0aGF0IGl0IHdpbGwgcmV0dXJuICJ0ZXh0L3htbCIgYnV0IHRoZW4gYWN0dWFsbHkK ICAgcmV0dXJuaW5nICJhcHBsaWNhdGlvbi9qc29uIiBpbiBhIHJlc3BvbnNlIHRvIGEgcmVxdWVz dCBmb3IgaXRzCiAgIHRlbXBlcmF0dXJlP30KCiAgIEFsdGVybmF0aXZlbHksIHRoZSAidHlwZSIg YXR0cmlidXRlIE1BWSBiZSB1c2VkIHRvIGluZGljYXRlIGFuCiAgIEludGVybmV0IG1lZGlhIHR5 cGUgYXMgYSBxdW90ZWQtc3RyaW5nIFtSRkM1OTg4XS4gIEl0IGlzIG5vdCBob3dldmVyCiAgIGV4 cGVjdGVkIHRoYXQgY29uc3RyYWluZWQgaW1wbGVtZW50YXRpb25zIGFyZSBhYmxlIHRvIHBhcnNl IHF1b3RlZC0KICAgc3RyaW5nIENvbnRlbnQtdHlwZSB2YWx1ZXMuICBBIGxpbmsgTUFZIGluY2x1 ZGUgZWl0aGVyIGEgY3QgYXR0cmlidXRlCiAgIG9yIGEgdHlwZSBhdHRyaWJ1dGUsIGJ1dCBNVVNU IE5PVCBpbmNsdWRlIGJvdGguCiAgIAogICB7QXMgYSBnZW5lcmFsIHJ1bGUsIGFsdGVybmF0aXZl cyBtYWtlIGZvciBjb21wbGV4aXR5IGFuZCBkb24ndCBoZWxwCiAgIGludGVyb3BlcmFiaWxpdHku IFlvdSBjb3VsZCBzYXkgc29tZXRoaW5nIGxpa2U6ICJJZiB0aGVyZSBpcyBhIG5lZWQKICAgdG8g ZGVzY3JpYmUgYSBjb250ZW50IHR5cGUgYW5kIGEgQ29BUCBjb250ZW50LXR5cGUgY29kZSBleGlz dHMgdGhlbiAKICAgdGhlICJjdCIgYXR0cmlidXRlIE1VU1QgYmUgdXNlZCBhbmQgdGhlIGNvcnJl c3BvbmRpbmcgInR5cGUiCiAgIGF0dHJpYnV0ZSBNVVNUIE5PVCBiZSB1c2VkLiJ9CgozLjQuICBN YXhpbXVtIHNpemUgZXN0aW1hdGUgJ3N6JyBhdHRyaWJ1dGUKCiAgIFRoZSBtYXhpbXVtIHNpemUg ZXN0aW1hdGUgYXR0cmlidXRlICJzeiIgZ2l2ZXMgYW4gaW5kaWNhdGlvbiBvZiB0aGUKICAgbWF4 aW11bSBzaXplIG9mIHRoZSByZXNvdXJjZSBpbmRpY2F0ZWQgYnkgdGhlIHRhcmdldCBVUkksIGlu IGJ5dGVzLiAgVGhpcwogICBhdHRyaWJ1dGUgaXMgbm90IGV4cGVjdGVkIHRvIGJlIGluY2x1ZGVk IGZvciBzbWFsbCByZXNvdXJjZXMgdGhhdCBjYW4KICAgY29tZm9ydGFibHkgYnkgY2FycmllZCBp biBhIHNpbmdsZSBNYXhpdW11bSBUcmFuc21pc3Npb24gVW5pdCAoTVRVKSwKICAgYnV0IFNIT1VM RCBiZSBpbmNsdWRlZCBmb3IgcmVzb3VyY2VzIGxhcmdlciB0aGFuIHRoYXQuICBUaGUgbWF4aW11 bQogICBzaXplIGVzdGltYXRlIGF0dHJpYnV0ZSBNVVNUIE5PVCBhcHBlYXIgbW9yZSB0aGFuIG9u Y2UgaW4gYSBsaW5rLgoKCgoKClNoZWxieSAgICAgICAgICAgICAgICAgRXhwaXJlcyBTZXB0ZW1i ZXIgMTUsIDIwMTEgICAgICAgICAgICAgICBbUGFnZSA5XQoMCkludGVybmV0LURyYWZ0ICAgICAg ICAgICAgICBDb1JFIExpbmsgRm9ybWF0ICAgICAgICAgICAgICAgICAgTWFyY2ggMjAxMQoKCjQu ICBXZWxsLWtub3duIEludGVyZmFjZQoKICAgUmVzb3VyY2UgZGlzY292ZXJ5IGluIENvUkUgaXMg YWNjb21wbGlzaGVkIHRocm91Z2ggdGhlIHVzZSBvZiBhIHdlbGwtCiAgIGtub3duIHJlc291cmNl IFVSSSB3aGljaCByZXR1cm5zIGEgbGlzdCBvZiBsaW5rcyBhYm91dCByZXNvdXJjZXMKICAgaG9z dGVkIGJ5IHRoYXQgc2VydmVyIGFuZCBvdGhlciBsaW5rIHJlbGF0aW9ucy4gIFdlbGwta25vd24g cmVzb3VyY2VzCiAgIGhhdmUgYSBwYXRoIGNvbXBvbmVudCB0aGF0IGJlZ2lucyB3aXRoICIvLndl bGwta25vd24vIiBhcyBzcGVjaWZpZWQKICAgaW4gW1JGQzU3ODVdLiAgVGhpcyBkb2N1bWVudCBk ZWZpbmVzIGEgbmV3IHdlbGwta25vd24gcmVzb3VyY2UgZm9yCiAgIENvUkUgUmVzb3VyY2UgRGlz Y292ZXJ5ICIvLndlbGwta25vd24vY29yZSIuCgogICBBIHNlcnZlciBpbXBsZW1lbnRpbmcgdGhp cyBzcGVjaWZpY2F0aW9uIE1VU1Qgc3VwcG9ydCB0aGlzIHJlc291cmNlCiAgIG9uIHRoZSBkZWZh dWx0IHBvcnQgYXBwcm9wcmlhdGUgZm9yIHRoZSBwcm90b2NvbCBmb3IgdGhlIHB1cnBvc2Ugb2YK ICAgcmVzb3VyY2UgZGlzY292ZXJ5LiAgSXQgaXMgaG93ZXZlciB1cCB0byB0aGUgYXBwbGljYXRp b24gd2hpY2ggbGlua3MKICAgYXJlIGluY2x1ZGVkIGFuZCBob3cgdGhleSBhcmUgb3JnYW5pemVk LiAgVGhlIHJlc291cmNlIC8ud2VsbC1rbm93bi8KICAgY29yZSBpcyBtZWFudCB0byBiZSB1c2Vk IHRvIHJldHVybiBsaW5rcyB0byB0aGUgZW50cnkgcG9pbnRzIG9mCiAgIHJlc291cmNlIGludGVy ZmFjZXMgb24gYSBzZXJ2ZXIuICBNb3JlIHNvcGhpc3RpY2F0ZWQgbGluawogICBvcmdhbml6YXRp b24gY2FuIGJlIGFjaGlldmVkIGJ5IGluY2x1ZGluZyBsaW5rcyB0byBDb1JFIExpbmsgRm9ybWF0 CiAgIHJlc291cmNlcyBsb2NhdGVkIGVsc2V3aGVyZSBvbiB0aGUgc2VydmVyLCBmb3IgZXhhbXBs ZSB0byBhY2hpZXZlIGFuCiAgIGluZGV4LiAgSW4gdGhlIGFic2VuY2Ugb2YgYW55IGxpbmtzLCBh IHplcm8tbGVuZ3RoIHBheWxvYWQgaXMKICAgcmV0dXJuZWQuICBUaGUgcmVzb3VyY2UgcmVwcmVz ZW50YXRpb24gb2YgdGhpcyByZXNvdXJjZSBNVVNUIGJlIHRoZQogICBDb1JFIExpbmsgRm9ybWF0 IGRlc2NyaWJlZCBpbiBTZWN0aW9uIDIuCgogICBUaGUgQ29SRSByZXNvdXJjZSBkaXNjb3Zlcnkg aW50ZXJmYWNlIHN1cHBvcnRzIHRoZSBmb2xsb3dpbmcKICAgaW50ZXJhY3Rpb25zOgoKICAgbyAg UGVyZm9ybWluZyBhIEdFVCBvbiAvLndlbGwta25vd24vY29yZSB0byB0aGUgZGVmYXVsdCBwb3J0 IHJldHVybnMKICAgICAgYSBzZXQgb2YgbGlua3MgYXZhaWxhYmxlIGZyb20gdGhlIHNlcnZlciAo aWYgYW55KSBpbiB0aGUgQ29SRSBMaW5rCiAgICAgIEZvcm1hdC4gIFRoZXNlIGxpbmtzIG1pZ2h0 IGRlc2NyaWJlIHJlc291cmNlcyBob3N0ZWQgb24gdGhhdAogICAgICBzZXJ2ZXIsIG9uIG90aGVy IHNlcnZlcnMsIG9yIGV4cHJlc3Mgb3RoZXIga2luZHMgb2YgbGluayByZWxhdGlvbnMKICAgICAg YXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gMi4KCiAgIG8gIEZpbHRlcmluZyBtYXkgYmUgcGVyZm9y bWVkIG9uIGFueSBvZiB0aGUgbGluayBmb3JtYXQgYXR0cmlidXRlcwogICAgICB1c2luZyBhIHF1 ZXJ5IHN0cmluZyBhcyBzcGVjaWZpZWQgaW4gU2VjdGlvbiA0LjEuICBGb3IgZXhhbXBsZQogICAg ICBbR0VUIC8ud2VsbC1rbm93bi9jb3JlP3J0PSJUZW1wZXJhdHVyZUMiXSB3b3VsZCByZXF1ZXN0 IHJlc291cmNlcwogICAgICB3aXRoIHRoZSBSZXNvdXJjZSBUeXBlICJUZW1wZXJhdHVyZUMiLiAg QSBzZXJ2ZXIgaXMgbm90IGhvd2V2ZXIgcmVxdWlyZWQgdG8KICAgICAgc3VwcG9ydCBmaWx0ZXJp bmcuIHtpcyB0aGUgcnQgbmFtZSBpbiBxdW90ZXMgb3Igbm90P30KCiAgIG8gIE1vcmUgY2FwYWJs ZSBzZXJ2ZXJzIHN1Y2ggYXMgcHJveGllcyBjb3VsZCBzdXBwb3J0IGEgcmVzb3VyY2UKICAgICAg ZGlyZWN0b3J5IGJ5IHJlcXVlc3RpbmcgdGhlIHJlc291cmNlIGRlc2NyaXB0aW9ucyBvZiBvdGhl ciBlbmQtCiAgICAgIHBvaW50cyBvciBhbGxvd2luZyBzZXJ2ZXJzIHRvIFBPU1QgcmVxdWVzdHMg dG8gLy53ZWxsLWtub3duL2NvcmUuCiAgICAgIFRoZSBkZXRhaWxzIG9mIHN1Y2ggcmVzb3VyY2Ug ZGlyZWN0b3J5IGZ1bmN0aW9uYWxpdHkgaXMgaG93ZXZlcgogICAgICBvdXQgb2Ygc2NvcGUgZm9y IHRoaXMgZG9jdW1lbnQsIGFuZCBpcyBleHBlY3RlZCB0byBiZSBzcGVjaWZpZWQKICAgICAgc2Vw YXJhdGVseS4ge1ByZXN1bWFibHkgdGhpcyBpcyBpbXBvcnRhbnQgaWYgc2xlZXBpbmcgbm9kZXMg YXJlCiAgICAgIHRvIGJlIHN1cHBvcnRlZC4gU28gZG9lcyBpdCBuZWVkIHRvIGJlIGRlYWx0IHdp dGggbm93PyBDb3VsZCBpdAogICAgICBub3QgYmUgZGVhbHQgd2l0aCBieSBleGlzdGluZyBjYWNo aW5nIHByb3Zpc2lvbnMgb2YgQ29BUD99Cgo0LjEuICBRdWVyeSBGaWx0ZXJpbmcKCiAgIEEgc2Vy dmVyIGltcGxlbWVudGluZyB0aGlzIGRvY3VtZW50IE1BWSByZWNvZ25pemUgdGhlIHF1ZXJ5IHBh cnQgb2YgYQogICByZXNvdXJjZSBkaXNjb3ZlcnkgVVJJIGFzIGEgZmlsdGVyIG9uIHRoZSByZXNv dXJjZXMgdG8gYmUgcmV0dXJuZWQuCiAgIFRoZSBxdWVyeSBwYXJ0IHNob3VsZCBjb25mb3JtIHRv IHRoZSBmb2xsb3dpbmcgc3ludGF4LiAgTm90ZSB0aGF0CgoKClNoZWxieSAgICAgICAgICAgICAg ICAgRXhwaXJlcyBTZXB0ZW1iZXIgMTUsIDIwMTEgICAgICAgICAgICAgIFtQYWdlIDEwXQoMCklu dGVybmV0LURyYWZ0ICAgICAgICAgICAgICBDb1JFIExpbmsgRm9ybWF0ICAgICAgICAgICAgICAg ICAgTWFyY2ggMjAxMQoKCiAgIHRoaXMgb25seSBkZWZpbmVzIHF1ZXJ5aW5nIGZvciBhIHNpbmds ZSBwYXJhbWV0ZXIgYXQgYSB0aW1lLgoKCiAgICAgZmlsdGVyLXF1ZXJ5ID0gcmVzb3VyY2UtcGFy YW0gIj0iIHF1ZXJ5LXBhdHRlcm4KICAgICByZXNvdXJjZS1wYXJhbSA9ICJ1cmkiIHwgcGFybW5h bWUKICAgICBxdWVyeS1wYXR0ZXJuID0gMSpwY2hhciBbICIqIiBdCgogICAge25vdGUgdGhhdCAi cGFybmFtZSIgaXMgbm90IGRlZmluZWQgaGVyZSBvciBpbiBSRkM1OTg4IC0gdGhvdWdoIAogICAg UkZDNTk4OCBzYXlzIGl0IGlzIGRlZmluZWQgaW4gUkZDNTk4NyAoYXMgInBhcm1uYW1lID0gMSph dHRyLWNoYXIiLgogICAgSXQgaXMgcHJlc3VhbWJseSBpbnRlbmRlZCB0byBiZSB0aGUgbGlzdCBv ZiBsZWdhbCBhdHRyaWJ1dGVzLgogICAgV291bGQgaXQgYmUgYmV0dGVyIHRvIGV4cHJlc3MgaXQg dGhpcyB3YXk/fQogICAgCiAgICB7SXMgdGhpcyB0aGUgcG9pbnQgdG8gbWFrZSB0aGUgZWFybGll ciByZWZlcmVuY2UgY29uY2VybmluZyBwY2hhcj99CiAgICAKICAgVGhlIHJlc291cmNlLXBhcmFt ICJ1cmkiIHJlZmVycyB0byB0aGUgVVJJLXJlZmVyZW5jZSBiZXR3ZWVuIHRoZSAiPCIKICAgYW5k ICI+IiBjaGFyYWN0ZXJzIG9mIGEgbGluay4gIE90aGVyIHJlc291cmNlLXBhcmFtIHZhbHVlcyBy ZWZlciB0bwogICB0aGUgbGluayBhdHRyaWJ1dGUgdGhleSBuYW1lLiAgRmlsdGVyaW5nIGlzIHBl cmZvcm1lZCBieSBjb21wYXJpbmcKICAgdGhlIHF1ZXJ5LXBhdHRlcm4gYWdhaW5zdCB0aGUgdmFs dWUgb2YgdGhlIGF0dHJpYnV0ZSBpZGVudGlmaWVkIGJ5CiAgIHRoZSByZXNvdXJjZS1wYXJhbSBm b3IgZWFjaCBsaW5rLXZhbHVlIGluIHRoZSBjb2xsZWN0aW9uIG9mIHJlc291cmNlcwogICBpZGVu dGlmaWVkIGJ5IHRoZSBVUkkgcGF0aC4KCiAgIElmIHRoZSBkZWNvZGVkIHF1ZXJ5LXBhdHRlcm4g ZG9lcyBub3QgZW5kIHdpdGggIioiLCBhIGxpbmsgdmFsdWUKICAgbWF0Y2hlcyB0aGUgcXVlcnkg b25seSBpZiB0aGUgdmFsdWUgb2YgdGhlIGF0dHJpYnV0ZSBvciBVUkktcmVmZXJlbmNlCiAgIGRl bm90ZWQgYnkgdGhlIHJlc291cmNlLXBhcmFtIGlzIGJ5dGV3aXNlIGlkZW50aWNhbCB0byB0aGUg cXVlcnktCiAgIHBhdHRlcm4uICBJZiB0aGUgZGVjb2RlZCBxdWVyeS1wYXR0ZXJuIGVuZHMgd2l0 aCAiKiIsIGl0IGlzCiAgIHN1ZmZpY2llbnQgdGhhdCB0aGUgcmVtYWluZGVyIG9mIHRoZSBxdWVy eS1wYXR0ZXJuIGJlIGEgcHJlZml4IG9mIHRoZQogICB2YWx1ZSBkZW5vdGVkIGJ5IHRoZSByZXNv dXJjZS1wYXJhbS4gIEl0IGlzIG5vdCBleHBlY3RlZCB0aGF0IHZlcnkKICAgY29uc3RyYWluZWQg bm9kZXMgc3VwcG9ydCBmaWx0ZXJpbmcuICBJbXBsZW1lbnRhdGlvbnMgbm90IHN1cHBvcnRpbmcK ICAgZmlsdGVyaW5nIE1VU1Qgc2ltcGx5IGlnbm9yZSB0aGUgcXVlcnkgc3RyaW5nIGFuZCByZXR1 cm4gdGhlIHdob2xlCiAgIHJlc291cmNlIGZvciB1bmljYXN0IHJlcXVlc3RzLgoKICAgV2hlbiB1 c2luZyBhIHRyYW5zZmVyIHByb3RvY29sIGxpa2UgdGhlIENvbnN0cmFpbmVkIEFwcGxpY2F0aW9u CiAgIFByb3RvY29sIChDb0FQKSB0aGF0IHN1cHBvcnRzIG11bHRpY2FzdCByZXF1ZXN0cywgc3Bl Y2lhbCBjYXJlIG11c3QgYmUKICAgdGFrZW4uICBBIG11bHRpY2FzdCByZXF1ZXN0IHdpdGggYSBx dWVyeSBzdHJpbmcgTVVTVCBub3QgYmUgcmVzcG9uZGVkCiAgIHRvIGlmIGZpbHRlcmluZyBpcyBu b3Qgc3VwcG9ydGVkICh0byBhdm9pZCBhIG5lZWRsZXNzIHJlc3BvbnNlCiAgIHN0b3JtKS4KCgo1 LiAgRXhhbXBsZXMKCiAgIEEgZmV3IGV4YW1wbGVzIG9mIHR5cGljYWwgbGluayBkZXNjcmlwdGlv bnMgaW4gdGhpcyBmb3JtYXQgZm9sbG93cy4KICAgTXVsdGlwbGUgcmVzb3VyY2UgZGVzY3JpcHRp b25zIGluIGEgcmVwcmVzZW50YXRpb24gYXJlIHNlcGFyYXRlZCBieQogICBjb21tYXMuICBMaW5l ZmVlZHMgbmV2ZXIgb2NjdXIgaW4gdGhlIGFjdHVhbCBmb3JtYXQsIGJ1dCBhcmUgc2hvd24gaW4K ICAgdGhlIGV4YW1wbGUgZm9yIHJlYWRhYmlsaXR5LgoKICAgVGhpcyBleGFtcGxlIGluY2x1ZGVz IGxpbmtzIHRvIHR3byBkaWZmZXJlbnQgc2Vuc29ycyBzaGFyaW5nIHRoZSBzYW1lCiAgIGludGVy ZmFjZSBkZXNjcmlwdGlvbi4KCiAgIFJFUTogR0VUIC8ud2VsbC1rbm93bi9jb3JlCgogICBSRVM6 IDIwMCBPSwogICA8L3NlbnNvcnMvdGVtcD47Y3Q9NDE7cnQ9IlRlbXBlcmF0dXJlQyI7aWY9InNl bnNvciIsCiAgIDwvc2Vuc29ycy9saWdodD47Y3Q9NDE7cnQ9IkxpZ2h0THV4IjtpZj0ic2Vuc29y IgoKCgoKU2hlbGJ5ICAgICAgICAgICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAxNSwgMjAxMSAg ICAgICAgICAgICAgW1BhZ2UgMTFdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIENvUkUg TGluayBGb3JtYXQgICAgICAgICAgICAgICAgICBNYXJjaCAyMDExCgoKICAgVGhpcyBleGFtcGxl IGFycmFuZ2VzIGxpbmsgZGVzY3JpcHRpb25zIGhpZXJhcmNoaWNhbGx5LCB3aXRoIHRoZQogICBl bnRyeSBwb2ludCBpbmNsdWRpbmcgYSBsaW5rIHRvIGEgc3ViLXJlc291cmNlIGNvbnRhaW5pbmcg bGlua3MgYWJvdXQKICAgdGhlIHNlbnNvcnMuCgogICBSRVE6IEdFVCAvLndlbGwta25vd24vY29y ZQoKICAgUkVTOiAyMDAgT0sKICAgPC9zZW5zb3JzPjtydD0iaW5kZXgiO2N0PTQwCgogICBSRVE6 IEdFVCAvc2Vuc29ycwoKICAgUkVTOiAyMDAgT0sKICAgPC9zZW5zb3JzL3RlbXA+O2N0PTQxO3J0 PSJUZW1wZXJhdHVyZUMiO2lmPSJzZW5zb3IiLAogICA8L3NlbnNvcnMvbGlnaHQ+O2N0PTQxO3J0 PSJMaWdodEx1eCI7aWY9InNlbnNvciIKCiAge0RvZXMgdGhpcyBtZWFuIHRoYXQgYSBydD0iaW5k ZXgiIGhhcyBhIHNwZWNpYWwgbWVhbmluZz8gSWYgc28sIGl0CiAgc2hvdWxkIGJlIGRlZmluZWQu IE9yIGlzIHRoZSB0aGUgY3Q9NDAgY29udGVudCB0eXBlIHRoYXQgdGVsbHMKICB0aGUgY2xpZW50 IHRoZXJlIGlzIGEgaGllcmFyY2h5P30KICAKICAgQW4gZXhhbXBsZSBxdWVyeSBmaWx0ZXIgbWF5 IGxvb2sgbGlrZToKCiAgIFJFUTogR0VUIC8ud2VsbC1rbm93bi9jb3JlP3J0PUxpZ2h0THV4IAog ICAKICAge1Nob3VsZCB0aGVyZSBiZSBxdW90ZXM6IHJ0PSJMaWdodEx1eCI/IFN1cmVseSBpZiB0 aGUgcXVvdGVzIGFyZSBub3QKICAgcmVxdWlyZWQgaW4gdGhlIHF1ZXJ5IHN0cmluZyB0aGV5IHdv dWxkIG5vdCBiZSByZXF1aXJlZCBpbiB0aGUKICAgbGluaywgYW5kIHZpY2UgdmVyc2EuIEl0IGlz IHdvcnRoIG1ha2luZyB0aGlzIGV4cGxpY2l0Ln0KCiAgIFJFUzogMjAwIE9LCiAgIDwvc2Vuc29y cy9saWdodD47Y3Q9NDE7cnQ9IkxpZ2h0THV4IjtpZj0ic2Vuc29yIgoKICAgVGhpcyBleGFtcGxl IHNob3dzIHRoZSB1c2Ugb2YgYW4gYW5jaG9yIGF0dHJpYnV0ZSB0byByZWxhdGUgdGhlCiAgIHRl bXBlcmF0dXJlIHNlbnNvciByZXNvdXJjZSB0byBhbiBleHRlcm5hbCBkZXNjcmlwdGlvbiBhbmQg dG8gYW4KICAgYWx0ZXJuYXRpdmUgVVJMLgoKICAgUkVROiBHRVQgLy53ZWxsLWtub3duL2NvcmUK CiAgIFJFUzogMjAwIE9LCiAgIDwvc2Vuc29ycz47Y3Q9NDA7cnQ9ImluZGV4IjtydD0iU2Vuc29y IEluZGV4IiwKICAgPC9zZW5zb3JzL3RlbXA+O3J0PSJUZW1wZXJhdHVyZUMiO2lmPSJzZW5zb3Ii LAogICA8L3NlbnNvcnMvbGlnaHQ+O2N0PTQxO3J0PSJMaWdodEx1eCI7aWY9InNlbnNvciIsCiAg IDxodHRwOi8vd3d3LmV4YW1wbGUuY29tL3NlbnNvcnMvdDEyMz47YW5jaG9yPSIvc2Vuc29ycy90 ZW1wIgogICA7cmVsPSJkZXNjcmliZWRieSIsCiAgIDwvdD47YW5jaG9yPSIvc2Vuc29ycy90ZW1w IjtyZWw9ImFsdGVybmF0ZSIKCiAge0hhbmcgb24uIEluIHRoZSBzZWNvbmQgZXhhbXBsZSBpbiB0 aGlzIHNlY3Rpb24gdGhlIHNlcnZlciByZXR1cm5zIAogIGEgc2luZ2xlIGxpbmssIGluY2x1ZGlu ZyBhbiBydD0iaW5kZXgiIGF0dHJpYnV0ZS4gSW4gdGhpcyBleGFtcGxlIHRoZSAKICBzZXJ2ZXIg cmV0dXJucyBzZXZlcmFsIGxpbmtzLiBXaGljaCBpcyB0aGUgY29ycmVjdCBiZWhhdmlvdXI/IEFs c28gLSAKICBhcmUgc3BhY2VzIGFsbG93ZWQgaW4gcnQ/IGFzIGluICJTZW5zb3IgSW5kZXgiIGFi b3ZlPyBQcm9iYWJseSwgYXMgdGhleQogIGFyZSAicXVvdGVkIHN0cmluZ3MiLiBUaGVuIHRoaXMg d291bGQgbWFrZSB0aGUgY2FzZSBmb3IgdXNpbmcgcXVvdGVzIAogIGluIHRoZSBxdWVyeSBzdHJp bmc6CiAgUkVROiBHRVQgLy53ZWxsLWtub3duL2NvcmU/cnQ9IlNlbnNvciBJbmRleCIKICB9Cgog ICBJZiBhIGNsaWVudCBpcyBpbnRlcmVzdGVkIHRvIGZpbmQgcmVsYXRpb25zIGFib3V0IGEgcGFy dGljdWxhcgogICByZXNvdXJjZSwgaXQgY2FuIHBlcmZvcm0gYSBxdWVyeSBvbiB0aGUgYW5jaG9y IHBhcmFtZXRlcjoKCiAgIFJFUTogR0VUIC8ud2VsbC1rbm93bi9jb3JlP2FuY2hvcj0vc2Vuc29y cy90ZW1wCgogICBSRVM6IDIwMCBPSwogICA8aHR0cDovL3d3dy5leGFtcGxlLmNvbS9zZW5zb3Jz L3RlbXAxMjM+O2FuY2hvcj0iL3NlbnNvcnMvdGVtcCIKICAgO3JlbD0iZGVzY3JpYmVkYnkiLAog ICA8L3Q+O2FuY2hvcj0iL3NlbnNvcnMvdGVtcCI7cmVsPSJhbHRlcm5hdGUiCgogICB7SXQgaXMg bm90IGNsZWFyIChmcm9tIHRoaXMgZG9jdW1lbnQgb3IgZnJvbSBSRkM1OTg4KSB3aGF0IHVzZQog ICB0aGUgcmVsIGF0dHJpYnV0ZSB3b3VsZCBiZS4gSWYgaXQgaXMgdG8gYmUgdXNlZnVsIHRoZW4g dGhlcmUKICAgbmVlZHMgdG8gYmUgc29tZSBkZXNjcmlwdGlvbiBvZiB3aGF0IHRoZSBjbGllbnQg aXMgdG8gdXNlIGl0CiAgIGZvciwgaWYgdGhlIHNlcnZlciBzZW5kcyBpdC59CgoKU2hlbGJ5ICAg ICAgICAgICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAxNSwgMjAxMSAgICAgICAgICAgICAgW1Bh Z2UgMTJdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIENvUkUgTGluayBGb3JtYXQgICAg ICAgICAgICAgICAgICBNYXJjaCAyMDExCgoKNi4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zCgog ICBUaGlzIGRvY3VtZW50IG5lZWRzIHRoZSBzYW1lIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGFz IGRlc2NyaWJlZCBpbgogICBTZWN0aW9uIDcgb2YgW1JGQzU5ODhdLiAgVGhlIC8ud2VsbC1rbm93 bi9jb3JlIHJlc291cmNlIG1heSBiZQogICBwcm90ZWN0ZWQgZS5nLiB1c2luZyBEVExTIHdoZW4g aG9zdGVkIG9uIGEgQ29BUCBzZXJ2ZXIgYXMgcGVyCiAgIFtJLUQuaWV0Zi1jb3JlLWNvYXBdIFNl Y3Rpb24gMTAuMi4KCiAgIE11bHRpY2FzdCByZXF1ZXN0cyB1c2luZyBDb0FQIGZvciB0aGUgd2Vs bC1rbm93biBsaW5rLWZvcm1hdAogICByZXNvdXJjZXMgY291bGQgYmUgdXNlZCB0byBwZXJmb3Jt IGRlbmlhbCBvZiBzZXJ2aWNlIG9uIGEgY29uc3RyYWluZWQKICAgbmV0d29yay4gIEEgbXVsdGlj YXN0IHJlcXVlc3QgU0hPVUxEIG9ubHkgYmUgYWNjZXB0ZWQgaWYgdGhlIHJlcXVlc3QKICAgaXMg c3VmZmljaWVudGx5IGF1dGhlbnRpY2F0ZWQgYW5kIHNlY3VyZWQuCgogICBDb1JFIExpbmsgRm9y bWF0IHBhcnNlcnMgc2hvdWxkIGJlIGF3YXJlIHRoYXQgYSBsaW5rIGRlc2NyaXB0aW9uIG1heQog ICBiZSBjeWNsaWNhbCwgaS5lLiwgY29udGFpbiBhIGxpbmsgdG8gaXRzZWxmLiAgVGhlc2UgY3lj bGljYWwgbGlua3MKICAgY291bGQgYmUgZGlyZWN0IG9yIGluZGlyZWN0IChpLmUuLCB0aHJvdWdo IHJlZmVyZW5jZWQgbGluawogICByZXNvdXJjZXMpLiAgQ2FyZSBzaG91bGQgYmUgdGFrZW4gd2hl biBwYXJzaW5nIGxpbmsgZGVzY3JpcHRpb25zIGFuZAogICBhY2Nlc3NpbmcgY3ljbGljYWwgbGlu a3MuCgoKNy4gIElBTkEgQ29uc2lkZXJhdGlvbnMKCjcuMS4gIEF0dHJpYnV0ZSBSZWdpc3RyeQoK ICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgcmVnaXN0cnkgZm9yIHRoZSBsaW5rIGV4dGVuc2lv biBhdHRyaWJ1dGVzCiAgIGRlZmluZWQgZm9yIHVzZSB3aXRoIHRoZSBDb1JFIExpbmsgRm9ybWF0 LiAgVGhlIG5hbWUgb2YgdGhlIHJlZ2lzdHJ5CiAgIGlzICJDb1JFIExpbmsgRm9ybWF0IEF0dHJp YnV0ZXMiLgoKICAgRWFjaCBlbnRyeSBpbiB0aGUgcmVnaXN0cnkgbXVzdCBpbmNsdWRlIHRoZSBh dHRyaWJ1dGUgbmFtZSwgdGhlCiAgIGF0dHJpYnV0ZSwgdGhlIGZvcm1hdCBvZiB0aGUgYXR0cmli dXRlIGFuZCBhIHJlZmVyZW5jZSB0byB0aGUKICAgYXR0cmlidXRlJ3MgZG9jdW1lbnRhdGlvbi4K CiAgIEluaXRpYWwgZW50cmllcyBpbiB0aGlzIHJlZ2lzdHJ5IGFyZSBhcyBmb2xsb3dzOgoKICAg ICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tKwogICAgIHwgICAgICAgICAgICAgICAgICBOYW1lIHwgQXR0cmlidXRlIHwgVHlw ZSAgICAgICAgICB8IFJlZmVyZW5jZSB8CiAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLSsKICAgICB8ICAgICAgICAgUmVz b3VyY2UgVHlwZSB8ICAgICAgICBydCB8IFF1b3RlZCBTdHJpbmcgfCAmU0VMRjsgICAgfAogICAg IHwgSW50ZXJmYWNlIERlc2NyaXB0aW9uIHwgICAgICAgIGlmIHwgUXVvdGVkIFN0cmluZyB8ICZT RUxGOyAgICB8CiAgICAgfCAgICAgICAgICBDb250ZW50LVR5cGUgfCAgICAgICAgY3QgfCBJbnRl Z2VyICAgICAgIHwgJlNFTEY7ICAgIHwKICAgICB8IE1heGltdW0gU2l6ZSBFc3RpbWF0ZSB8ICAg ICAgICBzeiB8IEludGVnZXIgICAgICAgfCAmU0VMRjsgICAgfAogICAgICstLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSstLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0rCgogICAg ICAgICAgICAgICAgICAgICAgIFRhYmxlIDE6IENvQVAgT3B0aW9uIE51bWJlcnMKCiAgIE5ldyBh dHRyaWJ1dGVzIGRlZmluZWQgZm9yIHRoZSBDb1JFIExpbmsgRm9ybWF0IE1VU1QgTk9UIGNvbGxp ZGUgd2l0aAogICBleGlzdGluZyBhdHRyaWJ1dGVzIGRlZmluZWQgaW4gW1JGQzU5ODhdLgoKICAg VGhlIElBTkEgcG9saWN5IGZvciBmdXR1cmUgYWRkaXRpb25zIHRvIHRoaXMgcmVnaXN0cnkgaXMg IklFVEYKCgoKU2hlbGJ5ICAgICAgICAgICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAxNSwgMjAx MSAgICAgICAgICAgICAgW1BhZ2UgMTNdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIENv UkUgTGluayBGb3JtYXQgICAgICAgICAgICAgICAgICBNYXJjaCAyMDExCgoKICAgUmV2aWV3IiBh cyBkZXNjcmliZWQgaW4gW1JGQzUyMjZdLgoKICAgVGhlIGRvY3VtZW50YXRpb24gb2YgYW4gYXR0 cmlidXRlIHNob3VsZCBzcGVjaWZ5IHRoZSBzZW1hbnRpY3Mgb2YgdGhlCiAgIGF0dHJpYnV0ZSwg aW5jbHVkaW5nIHRoZSBmb2xsb3dpbmcgcHJvcGVydGllczoKCiAgIG8gIFRoZSBtZWFuaW5nIG9m IHRoZSBhdHRyaWJ1dGUuCgogICBvICBUaGUgZm9ybWF0IG9mIHRoZSBhdHRyaWJ1dGUncyB2YWx1 ZS4KCiAgIG8gIFdoZXRoZXIgdGhlIGF0dHJpYnV0ZSBjYW4gb2NjdXIgbXVsdGlwbGUgdGltZXMu CgogICBvICBUaGUgZGVmYXVsdCB2YWx1ZSwgaWYgYW55LgoKNy4yLiAgV2VsbC1rbm93biAnY29y ZScgVVJJCgogICBUaGlzIG1lbW8gcmVnaXN0ZXJzIHRoZSAiY29yZSIgd2VsbC1rbm93biBVUkkg aW4gdGhlIFdlbGwtS25vd24gVVJJCiAgIFJlZ2lzdHJ5IGFzIGRlZmluZWQgYnkgW1JGQzU3ODVd LgoKICAgVVJJIHN1ZmZpeDogY29yZQoKICAgQ2hhbmdlIGNvbnRyb2xsZXI6IElFVEYKCiAgIFNw ZWNpZmljYXRpb24gZG9jdW1lbnQocyk6IFtbIHRoaXMgZG9jdW1lbnQgXV0KCiAgIFJlbGF0ZWQg aW5mb3JtYXRpb246IE5vbmUKCjcuMy4gIE5ldyAnaG9zdHMnIHJlbGF0aW9uIHR5cGUKCiAgIFRo aXMgbWVtbyByZWdpc3RlcnMgdGhlIG5ldyAiaG9zdHMiIFdlYiBMaW5raW5nIHJlbGF0aW9uIHR5 cGUgYXMgcGVyCiAgIFtSRkM1OTg4XS4KCiAgIFJlbGF0aW9uIE5hbWU6IGhvc3RzCgogICBEZXNj cmlwdGlvbjogUmVmZXJzIHRvIGEgcmVzb3VyY2UgaG9zdGVkIGJ5IHRoZSBzZXJ2ZXIgaW5kaWNh dGVkIGJ5CiAgIHRoZSBsaW5rIGNvbnRleHQuCgogICBSZWZlcmVuY2U6IFtbIHRoaXMgZG9jdW1l bnQgXV0KCiAgIE5vdGVzOiBUaGlzIHJlbGF0aW9uIGlzIHVzZWQgaW4gQ29SRSB3aGVyZSBsaW5r cyBhcmUgcmV0cmlldmVkIGFzIGEKICAgLy53ZWxsLWtub3duL2NvcmUgcmVzb3VyY2UgcmVwcmVz ZW50YXRpb24sIGFuZCBieSBkZWZhdWx0IHRoZSBjb250ZXh0CiAgIG9mIHRoZSBsaW5rcyBpcyB0 aGUgc2VydmVyIGF0IGNvYXA6Ly9hdXRob3JpdHkgZnJvbSB3aGljaCAvLndlbGwtCiAgIGtub3du L2NvcmUgd2FzIHJlcXVlc3RlZC4KCiAgIEFwcGxpY2F0aW9uIERhdGE6IE5vbmUKCiAge1NpbmNl IHRoaXMgImhvc3RzIiByZWxhdGlvbiBoYXMgYmVlbiBpbnRyb2R1Y2VkLCBpcyBpdCBpbiBvcmRl ciB0bwogIGFzayB0byBzZWUgaXQgdXNlZCBpbiB0aGUgRXhhbXBsZXMgc2VjdGlvbj8gQWxzbywg dGhlIG5ldyAic3oiIGF0dHJpYnV0ZQogIHNob3VsZCBiZSBzaG93biBpbiBhY3Rpb24gaW4gdGhl IEV4YW1wbGVzIHNlY3Rpb24ufQoKCgoKClNoZWxieSAgICAgICAgICAgICAgICAgRXhwaXJlcyBT ZXB0ZW1iZXIgMTUsIDIwMTEgICAgICAgICAgICAgIFtQYWdlIDE0XQoMCkludGVybmV0LURyYWZ0 ICAgICAgICAgICAgICBDb1JFIExpbmsgRm9ybWF0ICAgICAgICAgICAgICAgICAgTWFyY2ggMjAx MQoKCjcuNC4gIE5ldyBsaW5rLWZvcm1hdCBJbnRlcm5ldCBtZWRpYSB0eXBlCgogICBUaGlzIG1l bW8gcmVnaXN0ZXJzIHRoZSBhIG5ldyBJbnRlcm5ldCBtZWRpYSB0eXBlIGZvciB0aGUgQ29SRSBs aW5rCiAgIGZvcm1hdDogImFwcGxpY2F0aW9uL2xpbmstZm9ybWF0Ii4KCiAgIFR5cGUgbmFtZTog YXBwbGljYXRpb24KCiAgIFN1YnR5cGUgbmFtZTogbGluay1mb3JtYXQKCiAgIFJlcXVpcmVkIHBh cmFtZXRlcnM6IE5vbmUKCiAgIE9wdGlvbmFsIHBhcmFtZXRlcnM6IFRoZSBxdWVyeSBzdHJpbmcg bWF5IGNvbnRhaW4gdXJpPSB0byBtYXRjaCB0aGUKICAgVVJJLCBvciBhbnkgb3RoZXIgYXR0cmli dXRlIGRlZmluZWQgZm9yIHRoZSBsaW5rIGZvcm1hdCB0byBtYXRjaCB0aGF0CiAgIGF0dHJpYnV0 ZSBhcyBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQuCgogICBFbmNvZGluZyBjb25zaWRlcmF0aW9u czogVVRGLTggKE5GQykKCiAgIFNlY3VyaXR5IGNvbnNpZGVyYXRpb25zOiBOb25lCgogICBJbnRl cm9wZXJhYmlsaXR5IGNvbnNpZGVyYXRpb25zOgoKICAgUHVibGlzaGVkIHNwZWNpZmljYXRpb246 IFtbIHRoaXMgZG9jdW1lbnQgXV0KCiAgIEFwcGxpY2F0aW9ucyB0aGF0IHVzZSB0aGlzIG1lZGlh IHR5cGU6IENvQVAgc2VydmVyIGFuZCBjbGllbnQKICAgaW1wbGVtZW50YXRpb25zIGZvciByZXNv dXJjZSBkaXNjb3ZlcnkgYW5kIEhUVFAgYXBwbGljYXRpb25zIHRoYXQgdXNlCiAgIHRoZSBsaW5r LWZvcm1hdCBhcyBhIHBheWxvYWQuCgogICBBZGRpdGlvbmFsIGluZm9ybWF0aW9uOgoKICAgTWFn aWMgbnVtYmVyKHMpOgoKICAgRmlsZSBleHRlbnNpb24ocyk6CgogICBNYWNpbnRvc2ggZmlsZSB0 eXBlIGNvZGUocyk6CgogICBJbnRlbmRlZCB1c2FnZTogQ09NTU9OCgogICBSZXN0cmljdGlvbnMg b24gdXNhZ2U6IE5vbmUKCiAgIEF1dGhvcjogQ29SRSBXRwoKICAgQ2hhbmdlIGNvbnRyb2xsZXI6 IElFVEYKCgo4LiAgQWNrbm93bGVkZ21lbnRzCgogICBTcGVjaWFsIHRoYW5rcyB0byBQZXRlciBC aWdvdCwgd2hvIGhhcyBtYWRlIGEgY29uc2lkZXJhYmxlIG51bWJlcgogICByZXZpZXdzIGFuZCB0 ZXh0IGNvbnRyaWJ1dGlvbnMgdGhhdCBncmVhdGx5IGltcHJvdmVkIHRoZSBkb2N1bWVudC4KCgoK U2hlbGJ5ICAgICAgICAgICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAxNSwgMjAxMSAgICAgICAg ICAgICAgW1BhZ2UgMTVdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIENvUkUgTGluayBG b3JtYXQgICAgICAgICAgICAgICAgICBNYXJjaCAyMDExCgoKICAgSW4gcGFydGljdWxhciwgUGV0 ZXIgaXMgcmVzcG9uc2libGUgZm9yIHRoZSBBQk5GIGRlc2NyaXB0aW9ucyBhbmQgdGhlCiAgIGlk ZWEgZm9yIGEgbmV3ICJob3N0cyIgcmVsYXRpb24gdHlwZS4KCiAgIFRoYW5rcyB0byBNYXJrIE5v dHRpbmdoYW0gYW5kIEVyYW4gSGFtbWVyLUxhaGF2IGZvciB0aGUgZGlzY3Vzc2lvbnMKICAgYW5k IGlkZWFzIHRoYXQgbGVkIHRvIHRoaXMgZHJhZnQsIGFuZCB0byBDYXJzdGVuIEJvcm1hbm4sIE1h cnRpbgogICBUaG9tc29uIGFuZCBQZXRlciBTYWludC1BbmRyZSBmb3IgZXh0ZW5zaXZlIGNvbW1l bnRzIGFuZAogICBjb250cmlidXRpb25zIHRoYXQgaW1wcm92ZWQgdGhlIHRleHQuCgogICBUaGFu a3MgdG8gTWljaGFlbCBTdHViZXIsIFJpY2hhcmQgS2Vsc2V5LCBDdWxsZW4gSmVubmluZ3MsIEd1 aWRvCiAgIE1vcml0eiwgUGV0ZXIgVmFuIERlciBTdG9rLCBBZHJpYW5vIFBlenp1dG8sIExpc2Eg RHVzc2VhbHQsIEFsZXhleQogICBNZWxuaWtvdiwgR2lsYmVydCBDbGFyaywgU2FsdmF0b3JlIExv cmV0bywgUGV0cmkgTXV0a2EsIFN6eW1vbiBTYXNpbiwKICAgUm9iZXJ0IFF1YXR0bGViYXVtLCBS b2JlcnQgQ3JhZ2llLCBBbmdlbG8gQ2FzdGVsbGFuaSwgVG9tIEhlcmJzdCwgRWQKICAgQmVyb3Nl dCwgR2lsbWFuIFRvbGxlLCBSb2JieSBTaW1wc29uLCBDb2xpbiBPJ0ZseW5uIGFuZCBEYXZpZCBS eWFuCiAgIGZvciBoZWxwZnVsIGNvbW1lbnRzIGFuZCBkaXNjdXNzaW9ucyB0aGF0IGhhdmUgc2hh cGVkIHRoZSBkb2N1bWVudC4KCgo5LiAgQ2hhbmdlbG9nCgogICBDaGFuZ2VzIGZyb20gaWV0Zi0w MiB0byBpZXRmLTAzOgoKICAgICAgbyBSZW1vdmVkICdvYnMnIGF0dHJpYnV0ZSBkZWZpbml0aW9u LCBub3cgZGVmaW5lZCBpbiB0aGUgQ29BUAogICAgICBPYnNlcnZhdGlvbiBzcGVjICgjOTkpLgoK ICAgICAgbyBDaGFuZ2VkIFJlc291cmNlIG5hbWUgKG49KSB0byBSZXNvdXJjZSB0eXBlIChydD0p IGFuZCBkPSB0byBpZj0KICAgICAgKCMxMjEpLgoKICAgICAgbyBIaWVyYXJjaGljYWwgb3JnYW5p emF0aW9uIG9mIGxpbmtzIHVuZGVyIC8ud2VsbC1rbm93bi9jb3JlCiAgICAgIHJlbW92ZWQgKCM5 NSkuCgogICAgICBvIEJ1ZyBpbiBTZWN0aW9uIDMuMSBvbiBieXRlLXdpc2UgcXVlcnkgbWF0Y2hp bmcgZml4ZWQgKCM5MSkuCgogICAgICBvIEV4cGxhbmF0b3J5IHRleHQgYWRkZWQgYWJvdXQgYWx0 ZXJuYXRpdmUgV2ViIGxpbmsgZm9ybWF0cyAoIzkyKS4KCiAgICAgIG8gRml4ZWQgYSBidWcgaW4g U2VjdGlvbiAyLjIuNCAoIzkzKS4KCiAgICAgIG8gQWRkZWQgdXNlIGNhc2UgZXhhbXBsZXMgKCM4 OSkuCgogICAgICBvIENsYXJpZmllZCBob3cgdGhlIENvUkUgTGluayBGb3JtYXQgaXMgdXNlZCBh bmQgaG93IGl0IGRpZmZlcnMKICAgICAgZnJvbSBSRkM1OTg4ICgjOTAsICM5OCkuCgogICAgICBv IENoYW5nZWQgdGhlIEludGVyZmFjZSBkZWZpbml0aW9uIGZvcm1hdCB0byBxdW90ZWQtc3RyaW5n IHRvCiAgICAgIG1hdGNoIHRoZSByZXNvdXJjZSB0eXBlLgoKICAgICAgbyBBZGRlZCBhbiBJQU5B IHJlZ2lzdHJ5IGZvciBDb1JFIExpbmsgRm9ybWF0IGF0dHJpYnV0ZXMgKCMxMDApLgoKICAgQ2hh bmdlcyBmcm9tIGlldGYtMDEgdG8gaWV0Zi0wMjoKCgoKCgpTaGVsYnkgICAgICAgICAgICAgICAg IEV4cGlyZXMgU2VwdGVtYmVyIDE1LCAyMDExICAgICAgICAgICAgICBbUGFnZSAxNl0KDApJbnRl cm5ldC1EcmFmdCAgICAgICAgICAgICAgQ29SRSBMaW5rIEZvcm1hdCAgICAgICAgICAgICAgICAg IE1hcmNoIDIwMTEKCgogICAgICBvIEFkZGVkIHJlZmVyZW5jZXMgdG8gUkZDNTk4OCAoIzQxKS4K CiAgICAgIG8gUmVtb3ZlZCBzaCBhbmQgaWQgbGluay1leHRlbnNpb25zICgjNDIpLgoKICAgICAg byBEZWZpbmVkIHRoZSB1c2Ugb2YgVVRGLTggKCM4NCkuCgogICAgICBvIENoYW5nZWQgcXVlcnkg ZmlsdGVyIGRlZmluaXRpb24gZm9yIGFueSBwYXJhbWV0ZXIgKCM3MCkuCgogICAgICBvIEFkZGVk IG1vcmUgZXhhbXBsZSwgbm93IGFzIGEgc2VwYXJhdGUgc2VjdGlvbiAoIzQzKS4KCiAgICAgIG8g TWVudGlvbmVkIGN5Y2xpY2FsIGxpbmtzIGluIHRoZSBzZWN1cml0eSBzZWN0aW9uICgjNTcpLgoK ICAgICAgbyBSZW1vdmVkIHRoZSBzaCBhbmQgaWQgYXR0cmlidXRlcywgYWRkZWQgb2JzIGFuZCBz eiBhdHRyaWJ1dGVzCiAgICAgICgjNDIpLgoKICAgICAgbyBJbXByb3ZlZCB0aGUgY29udGV4dCBh bmQgcmVsYXRpb24gZGVzY3JpcHRpb24gd3J0IFJGQzU5ODggYW5kCiAgICAgIHJlcXVlc3RlZCBh IG5ldyAiaG9zdHMiIGRlZmF1bHQgcmVsYXRpb24gdHlwZSAoIzg1KS4KCiAgIENoYW5nZXMgZnJv bSBpZXRmLTAwIHRvIGlldGYtMDE6CgogICAgICBvIEVkaXRvcmlhbCBjaGFuZ2VzIHRvIGNvcnJl Y3QgcmVmZXJlbmNlcy4KCiAgICAgIG8gRm9ybWFsIGRlZmluaXRpb24gZm9yIGZpbHRlciBxdWVy eSBzdHJpbmcuCgogICAgICBvIFJlbW92ZWQgVVJJLXJlZmVyZW5jZSBvcHRpb24gZnJvbSAibiIg YW5kICJpZCIuCgogICAgICBvIEFkZGVkIHNlY3VyaXR5IHRleHQgYWJvdXQgbXVsdGljYXN0IHJl cXVlc3RzLgoKICAgQ2hhbmdlcyBmcm9tIHNoZWxieS0wMCB0byBpZXRmLTAwOgoKICAgICAgbyBG aXhlZCB0aGUgQUJORiBsaW5rLWV4dGVuc2lvbiBkZWZpbml0aW9ucyAocXVvdGVzIGFyb3VuZCBV UklzLAogICAgICBpbnRlZ2VyIGRlZmluaXRpb24pLgoKICAgICAgbyBDbGFyaWZpZWQgdGhhdCBm aWx0ZXJpbmcgaXMgb3B0aW9uYWwsIGFuZCB0aGUgcXVlcnkgc3RyaW5nIGlzIHRvCiAgICAgIGJl IGlnbm9yZWQgaWYgbm90IHN1cHBvcnRlZCAoYW5kIHRoZSBVUkwgcGF0aCBwcm9jZXNzZWQgYXMK ICAgICAgbm9ybWFsbHkpLgoKICAgICAgbyBSZXF1aXJlZCBzdXBwb3J0IG9mIHdpbGRjYXJkICog cHJvY2Vzc2luZyBpZiBmaWx0ZXJpbmcgaXMKICAgICAgc3VwcG9ydGVkLgoKICAgICAgbyBSZW1v dmVkIHRoZSBhdXNzdW1wdGlvbiBvZiBhIGRlZmF1bHQgY29udGVudC10eXBlIGFzc3VtcHRpb24u CgoKMTAuICBSZWZlcmVuY2VzCgoKCgoKCgpTaGVsYnkgICAgICAgICAgICAgICAgIEV4cGlyZXMg U2VwdGVtYmVyIDE1LCAyMDExICAgICAgICAgICAgICBbUGFnZSAxN10KDApJbnRlcm5ldC1EcmFm dCAgICAgICAgICAgICAgQ29SRSBMaW5rIEZvcm1hdCAgICAgICAgICAgICAgICAgIE1hcmNoIDIw MTEKCgoxMC4xLiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMKCiAgIFtSRkMyMTE5XSAgQnJhZG5lciwg Uy4sICJLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRlCiAgICAgICAgICAgICAg UmVxdWlyZW1lbnQgTGV2ZWxzIiwgQkNQIDE0LCBSRkMgMjExOSwgTWFyY2ggMTk5Ny4KCiAgIFtS RkMzOTg2XSAgQmVybmVycy1MZWUsIFQuLCBGaWVsZGluZywgUi4sIGFuZCBMLiBNYXNpbnRlciwg IlVuaWZvcm0KICAgICAgICAgICAgICBSZXNvdXJjZSBJZGVudGlmaWVyIChVUkkpOiBHZW5lcmlj IFN5bnRheCIsIFNURCA2NiwKICAgICAgICAgICAgICBSRkMgMzk4NiwgSmFudWFyeSAyMDA1LgoK ICAgW1JGQzUyMzRdICBDcm9ja2VyLCBELiBhbmQgUC4gT3ZlcmVsbCwgIkF1Z21lbnRlZCBCTkYg Zm9yIFN5bnRheAogICAgICAgICAgICAgIFNwZWNpZmljYXRpb25zOiBBQk5GIiwgU1REIDY4LCBS RkMgNTIzNCwgSmFudWFyeSAyMDA4LgoKICAgW1JGQzU5ODhdICBOb3R0aW5naGFtLCBNLiwgIldl YiBMaW5raW5nIiwgUkZDIDU5ODgsIE9jdG9iZXIgMjAxMC4KCjEwLjIuICBJbmZvcm1hdGl2ZSBS ZWZlcmVuY2VzCgogICBbSS1ELmlldGYtY29yZS1jb2FwXQogICAgICAgICAgICAgIFNoZWxieSwg Wi4sIEhhcnRrZSwgSy4sIEJvcm1hbm4sIEMuLCBhbmQgQi4gRnJhbmssCiAgICAgICAgICAgICAg IkNvbnN0cmFpbmVkIEFwcGxpY2F0aW9uIFByb3RvY29sIChDb0FQKSIsCiAgICAgICAgICAgICAg ZHJhZnQtaWV0Zi1jb3JlLWNvYXAtMDQgKHdvcmsgaW4gcHJvZ3Jlc3MpLCBKYW51YXJ5IDIwMTEu CgogICBbUkVTVF0gICAgIEZpZWxkaW5nLCAiQXJjaGl0ZWN0dXJhbCBTdHlsZXMgYW5kIHRoZSBE ZXNpZ24gb2YgTmV0d29yay0KICAgICAgICAgICAgICBiYXNlZCBTb2Z0d2FyZSBBcmNoaXRlY3R1 cmVzIiwgICwgMjAwMCwgPGh0dHA6Ly8KICAgICAgICAgICAgICB3d3cuaWNzLnVjaS5lZHUvfmZp ZWxkaW5nL3B1YnMvZGlzc2VydGF0aW9uL3RvcC5odG0+LgoKICAgW1JGQzI2MTZdICBGaWVsZGlu ZywgUi4sIEdldHR5cywgSi4sIE1vZ3VsLCBKLiwgRnJ5c3R5aywgSC4sCiAgICAgICAgICAgICAg TWFzaW50ZXIsIEwuLCBMZWFjaCwgUC4sIGFuZCBULiBCZXJuZXJzLUxlZSwgIkh5cGVydGV4dAog ICAgICAgICAgICAgIFRyYW5zZmVyIFByb3RvY29sIC0tIEhUVFAvMS4xIiwgUkZDIDI2MTYsIEp1 bmUgMTk5OS4KCiAgIFtSRkM0Mjg3XSAgTm90dGluZ2hhbSwgTS4sIEVkLiBhbmQgUi4gU2F5cmUs IEVkLiwgIlRoZSBBdG9tCiAgICAgICAgICAgICAgU3luZGljYXRpb24gRm9ybWF0IiwgUkZDIDQy ODcsIERlY2VtYmVyIDIwMDUuCgogICBbUkZDNDk0NF0gIE1vbnRlbmVncm8sIEcuLCBLdXNoYWxu YWdhciwgTi4sIEh1aSwgSi4sIGFuZCBELiBDdWxsZXIsCiAgICAgICAgICAgICAgIlRyYW5zbWlz c2lvbiBvZiBJUHY2IFBhY2tldHMgb3ZlciBJRUVFIDgwMi4xNS40CiAgICAgICAgICAgICAgTmV0 d29ya3MiLCBSRkMgNDk0NCwgU2VwdGVtYmVyIDIwMDcuCgogICBbUkZDNTE5OF0gIEtsZW5zaW4s IEouIGFuZCBNLiBQYWRsaXBza3ksICJVbmljb2RlIEZvcm1hdCBmb3IgTmV0d29yawogICAgICAg ICAgICAgIEludGVyY2hhbmdlIiwgUkZDIDUxOTgsIE1hcmNoIDIwMDguCgogICBbUkZDNTIyNl0g IE5hcnRlbiwgVC4gYW5kIEguIEFsdmVzdHJhbmQsICJHdWlkZWxpbmVzIGZvciBXcml0aW5nIGFu CiAgICAgICAgICAgICAgSUFOQSBDb25zaWRlcmF0aW9ucyBTZWN0aW9uIGluIFJGQ3MiLCBCQ1Ag MjYsIFJGQyA1MjI2LAogICAgICAgICAgICAgIE1heSAyMDA4LgoKICAgW1JGQzU3ODVdICBOb3R0 aW5naGFtLCBNLiBhbmQgRS4gSGFtbWVyLUxhaGF2LCAiRGVmaW5pbmcgV2VsbC1Lbm93bgogICAg ICAgICAgICAgIFVuaWZvcm0gUmVzb3VyY2UgSWRlbnRpZmllcnMgKFVSSXMpIiwgUkZDIDU3ODUs CiAgICAgICAgICAgICAgQXByaWwgMjAxMC4KCgoKCgpTaGVsYnkgICAgICAgICAgICAgICAgIEV4 cGlyZXMgU2VwdGVtYmVyIDE1LCAyMDExICAgICAgICAgICAgICBbUGFnZSAxOF0KDApJbnRlcm5l dC1EcmFmdCAgICAgICAgICAgICAgQ29SRSBMaW5rIEZvcm1hdCAgICAgICAgICAgICAgICAgIE1h cmNoIDIwMTEKCgpBdXRob3IncyBBZGRyZXNzCgogICBaYWNoIFNoZWxieQogICBTZW5zaW5vZGUK ICAgS2lkZWt1amEgMgogICBWdW9rYXR0aSAgODg2MDAKICAgRklOTEFORAoKICAgUGhvbmU6ICsz NTg0MDc3OTYyOTcKICAgRW1haWw6IHphY2hAc2Vuc2lub2RlLmNvbQoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKClNoZWxieSAgICAgICAgICAgICAgICAgRXhwaXJlcyBT ZXB0ZW1iZXIgMTUsIDIwMTEgICAgICAgICAgICAgIFtQYWdlIDE5XQoMCg== ------_=_NextPart_001_01CC097F.2388F67A Content-Type: text/plain; name=draft-ietf-core-observe-02_CGP.txt Content-Transfer-Encoding: base64 Content-Description: draft-ietf-core-observe-02_CGP.txt Content-Disposition: attachment; filename="draft-ietf-core-observe-02_CGP.txt" e0NoYW5nZXMgYnkgQ2hhcmxlcyBQYWxtZXIgY2hhcmxlcy5wYWxtZXJAb256by5jb20gCi0gVXNl IGEgZGlmZiB0b29sIHRvIGxvY2F0ZSB0aGUgY2hhbmdlcy4KLSBQcmVzdW1lZCBzdHJhaWdodC1m b3J3YXJkIGVkaXRvcmlhbCBjb3JyZWN0aW9ucyBvciByZXdvcmRpbmcgdG8KaW1wcm92ZSBjbGFy aXR5IGFyZSBwcm92aWRlZCB3aXRob3V0IGNvbW1lbnQgKGJ1dCBzaG91bGQgYmUgY2hlY2tlZCEp LgotIENvbW1lbnRzIGFuZCBxdWVzdGlvbnMgYXJlIGlkZW50aWZpZWQgYnkge3BhcmVudGhlc2Vz fS4KfQoKCkNvUkUgV29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIEsuIEhhcnRrZQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgVW5pdmVyc2l0YWV0IEJyZW1lbiBUWkkKSW50ZW5kZWQgc3RhdHVzOiBT dGFuZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgWi4gU2hlbGJ5CkV4 cGlyZXM6IFNlcHRlbWJlciAxNiwgMjAxMSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIFNlbnNpbm9kZQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgTWFyY2ggMTUsIDIwMTEKCgogICAgICAgICAgICAgICAgICAgICAgT2Jz ZXJ2aW5nIFJlc291cmNlcyBpbiBDb0FQCiAgICAgICAgICAgICAgICAgICAgICAgZHJhZnQtaWV0 Zi1jb3JlLW9ic2VydmUtMDIKCkFic3RyYWN0CgogICBDb0FQIGlzIGEgUkVTVGZ1bCBhcHBsaWNh dGlvbiBwcm90b2NvbCBmb3IgY29uc3RyYWluZWQgbm9kZXMgYW5kCiAgIG5ldHdvcmtzLiAgVGhl IHN0YXRlIG9mIGEgcmVzb3VyY2Ugb24gYSBDb0FQIHNlcnZlciBjYW4gY2hhbmdlIG92ZXIKICAg dGltZS4gIFRoaXMgc3BlY2lmaWNhdGlvbiBwcm92aWRlcyBhIHNpbXBsZSBleHRlbnNpb24gZm9y IENvQVAgdGhhdAogICBnaXZlcyBjbGllbnRzIHRoZSBhYmlsaXR5IHRvIG9ic2VydmUgc3VjaCBj aGFuZ2VzLgoKU3RhdHVzIG9mIHRoaXMgTWVtbwoKICAgVGhpcyBJbnRlcm5ldC1EcmFmdCBpcyBz dWJtaXR0ZWQgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoIHRoZQogICBwcm92aXNpb25zIG9mIEJD UCA3OCBhbmQgQkNQIDc5LgoKICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50 cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcKICAgVGFzayBGb3JjZSAoSUVURikuICBOb3Rl IHRoYXQgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUKICAgd29ya2luZyBkb2N1bWVu dHMgYXMgSW50ZXJuZXQtRHJhZnRzLiAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC0KICAg RHJhZnRzIGlzIGF0IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kcmFmdHMvY3VycmVudC8u CgogICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhp bXVtIG9mIHNpeCBtb250aHMKICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jz b2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkKICAgdGltZS4gIEl0IGlzIGluYXBwcm9w cmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UKICAgbWF0ZXJpYWwgb3Ig dG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIgoKICAgVGhpcyBJ bnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBTZXB0ZW1iZXIgMTYsIDIwMTEuCgpDb3B5cmln aHQgTm90aWNlCgogICBDb3B5cmlnaHQgKGMpIDIwMTEgSUVURiBUcnVzdCBhbmQgdGhlIHBlcnNv bnMgaWRlbnRpZmllZCBhcyB0aGUKICAgZG9jdW1lbnQgYXV0aG9ycy4gIEFsbCByaWdodHMgcmVz ZXJ2ZWQuCgogICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8gQkNQIDc4IGFuZCB0aGUgSUVU RiBUcnVzdCdzIExlZ2FsCiAgIFByb3Zpc2lvbnMgUmVsYXRpbmcgdG8gSUVURiBEb2N1bWVudHMK ICAgKGh0dHA6Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbykgaW4gZWZmZWN0IG9uIHRo ZSBkYXRlIG9mCiAgIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuICBQbGVhc2UgcmV2aWV3 IHRoZXNlIGRvY3VtZW50cwogICBjYXJlZnVsbHksIGFzIHRoZXkgZGVzY3JpYmUgeW91ciByaWdo dHMgYW5kIHJlc3RyaWN0aW9ucyB3aXRoIHJlc3BlY3QKICAgdG8gdGhpcyBkb2N1bWVudC4gIENv ZGUgQ29tcG9uZW50cyBleHRyYWN0ZWQgZnJvbSB0aGlzIGRvY3VtZW50IG11c3QKICAgaW5jbHVk ZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlIHRleHQgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNC5l IG9mCiAgIHRoZSBUcnVzdCBMZWdhbCBQcm92aXNpb25zIGFuZCBhcmUgcHJvdmlkZWQgd2l0aG91 dCB3YXJyYW50eSBhcwogICBkZXNjcmliZWQgaW4gdGhlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2Uu CgoKCkhhcnRrZSAmIFNoZWxieSAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMTYsIDIwMTEgICAg ICAgICAgICAgICBbUGFnZSAxXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgT2JzZXJ2aW5nIFJl c291cmNlcyBpbiBDb0FQICAgICAgICAgICAgTWFyY2ggMjAxMQoKClRhYmxlIG9mIENvbnRlbnRz CgogICAxLiAgSW50cm9kdWN0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gIDMKICAgMi4gIE92ZXJ2aWV3IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAzCiAgIDMuICBPYnNlcnZhdGlvbiBSZWxh dGlvbnNoaXBzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNQogICAgIDMu MS4gIEVzdGFibGlzaG1lbnQgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gIDUKICAgICAzLjIuICBNYWludGVuYW5jZSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuICA2CiAgICAgMy4zLiAgVGVybWluYXRpb24gIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNgogICA0LiAgTm90aWZpY2F0 aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDcK ICAgICA0LjEuICBTdHJhdGVnaWVzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICA4CiAgICAgNC4yLiAgUmV0cmFuc21pc3Npb24gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOAogICAgIDQuMy4gIFJlb3JkZXJpbmcgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDkKICAgICA0LjQu ICBDYWNoaW5nICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIDEwCiAgIDUuICBPYnNlcnZlIE9wdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAxMAogICA2LiAgSW50ZXJhY3Rpb25zIHdpdGggb3RoZXIgQ29B UCBmZWF0dXJlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTEKICAgICA2LjEuICBSZXF1ZXN0 IE1ldGhvZHMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDExCiAg ICAgNi4yLiAgQmxvY2std2lzZSBUcmFuc2ZlcnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAxMQogICAgIDYuMy4gIFJlc291cmNlIERpc2NvdmVyeSAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTIKICAgNy4gIFNlY3VyaXR5IENvbnNpZGVyYXRp b25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEyCiAgIDguICBJQU5B IENvbnNpZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAxMwogICA5LiAgQWNrbm93bGVkZ2VtZW50cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gMTMKICAgMTAuIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEzCiAgICAgMTAuMS4gTm9ybWF0aXZl IFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMwogICAg IDEwLjIuIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gMTQKICAgQXBwZW5kaXggQS4gIEV4YW1wbGVzICAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE1CiAgICAgQS4xLiAgUHJveHlpbmcgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNgogICBBcHBlbmRpeCBC LiAgQ2hhbmdlbG9nIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g MTgKICAgQXV0aG9ycycgQWRkcmVzc2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIDE5CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKSGFydGtlICYgU2hlbGJ5 ICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAxNiwgMjAxMSAgICAgICAgICAgICAgIFtQYWdlIDJd CgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICBPYnNlcnZpbmcgUmVzb3VyY2VzIGluIENvQVAgICAg ICAgICAgICBNYXJjaCAyMDExCgoKMS4gIEludHJvZHVjdGlvbgoKICAgQ29BUCBbSS1ELmlldGYt Y29yZS1jb2FwXSBpcyBhbiBBcHBsaWNhdGlvbiBQcm90b2NvbCBmb3IgQ29uc3RyYWluZWQKICAg Tm9kZXMvTmV0d29ya3MuICBJdCBpcyBpbnRlbmRlZCB0byBwcm92aWRlIFJFU1RmdWwgc2Vydmlj ZXMgW1JFU1RdCiAgIG5vdCB1bmxpa2UgSFRUUCBbUkZDMjYxNl0sIHdoaWxlIHJlZHVjaW5nIHRo ZSBjb21wbGV4aXR5IG9mCiAgIGltcGxlbWVudGF0aW9uIGFzIHdlbGwgYXMgdGhlIHNpemUgb2Yg cGFja2V0cyBleGNoYW5nZWQgaW4gb3JkZXIgdG8KICAgbWFrZSB0aGVzZSBzZXJ2aWNlcyB1c2Vm dWwgaW4gYSBoaWdobHkgY29uc3RyYWluZWQgbmV0d29yayBvZgogICB0aGVtc2VsdmVzIGhpZ2hs eSBjb25zdHJhaW5lZCBub2Rlcy4KCiAgIFRoZSBzdGF0ZSBvZiBhIHJlc291cmNlIG9uIGEgQ29B UCBzZXJ2ZXIgY2FuIGNoYW5nZSBvdmVyIHRpbWUuICBXZQogICB3YW50IHRvIGdpdmUgQ29BUCBj bGllbnRzIHRoZSBhYmlsaXR5IHRvIG9ic2VydmUgdGhpcyBjaGFuZ2UuCiAgIEhvd2V2ZXIsIGV4 aXN0aW5nIGFwcHJvYWNoZXMgZnJvbSB0aGUgSFRUUCB3b3JsZCwgc3VjaCBhcyByZXBlYXRlZAog ICBwb2xsaW5nIG9yIGxvbmctcG9sbHMsIGdlbmVyYXRlIHNpZ25pZmljYW50IGNvbXBsZXhpdHkg YW5kL29yCiAgIG92ZXJoZWFkIGFuZCB0aHVzIGFyZSBsZXNzIGFwcGxpY2FibGUgaW4gdGhlIGNv bnN0cmFpbmVkIENvQVAgd29ybGQuCiAgIEluc3RlYWQsIGEgbXVjaCBzaW1wbGVyIG1lY2hhbmlz bSBpcyBwcm92aWRlZCB0byBzb2x2ZSB0aGUgYmFzaWMKICAgcHJvYmxlbSBvZiByZXNvdXJjZSBv YnNlcnZhdGlvbi4gIE5vdGUgdGhhdCB0aGVyZSBpcyBubyBpbnRlbnRpb24gZm9yCiAgIHRoaXMg bWVjaGFuaXNtIHRvIHNvbHZlIHRoZSBmdWxsIHNldCBvZiBwcm9ibGVtcyB0aGF0IHRoZSBleGlz dGluZwogICBIVFRQIHNvbHV0aW9ucyBzb2x2ZSwgb3IgdG8gcmVwbGFjZSBwdWJsaXNoL3N1YnNj cmliZSBuZXR3b3JrcyB0aGF0CiAgIHNvbHZlIGEgbXVjaCBtb3JlIGdlbmVyYWwgcHJvYmxlbSBb UkZDNTk4OV0uCgogICBUaGlzIHNwZWNpZmljYXRpb24gZGVzY3JpYmVzIGFuIGFyY2hpdGVjdHVy ZSBhbmQgYSBwcm90b2NvbCBkZXNpZ24KICAgdGhhdCByZWFsaXplcyB0aGUgd2VsbC1rbm93biBz dWJqZWN0L29ic2VydmVyIGRlc2lnbiBwYXR0ZXJuIHdpdGhpbgogICB0aGUgUkVTVC1iYXNlZCBl bnZpcm9ubWVudCBvZiBDb0FQLgoKICAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIs ICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLAogICAiU0hPVUxEIiwgIlNIT1VMRCBO T1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kICJPUFRJT05BTCIgaW4gdGhpcwogICBkb2N1 bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIFtSRkMyMTE5XS4KCiAg IFdoZXJlIGFyaXRobWV0aWMgaXMgZXhwbGFpbmVkLCB0aGlzIGRvY3VtZW50IHVzZXMgdGhlIG5v dGF0aW9uCiAgIGZhbWlsaWFyIGZyb20gdGhlIHByb2dyYW1taW5nIGxhbmd1YWdlIEMsIGV4Y2Vw dCB0aGF0IHRoZSBvcGVyYXRvcgogICAiXiIgc3RhbmRzIGZvciBleHBvbmVudGlhdGlvbi4KCgoy LiAgT3ZlcnZpZXcKCiAgIEluIHRoZSBzdWJqZWN0L29ic2VydmVyIGRlc2lnbiBwYXR0ZXJuLCBh biBvYmplY3QsIGNhbGxlZCB0aGUKICAgc3ViamVjdCwgbWFpbnRhaW5zIGEgbGlzdCBvZiBpbnRl cmVzdGVkIHBhcnRpZXMsIGNhbGxlZCBvYnNlcnZlcnMsCiAgIGFuZCBub3RpZmllcyB0aGVtIGF1 dG9tYXRpY2FsbHkgd2hlbiBhIHByZWRlZmluZWQgY29uZGl0aW9uLCBldmVudCBvcgogICBzdGF0 ZSBjaGFuZ2Ugb2NjdXJzLiAgVGhlIHN1YmplY3QgcHJvdmlkZXMgYSB3YXkgZm9yIG9ic2VydmVy cyB0bwogICByZWdpc3RlciB0aGVtc2VsdmVzIHdpdGggdGhlIHN1YmplY3QuICBUaGlzIHBhdHRl cm4gc3VwcG9ydHMgYSBjbGVhbgogICBzZXBhcmF0aW9uIGJldHdlZW4gY29tcG9uZW50cywgc3Vj aCBhcyBkYXRhIHN0b3JhZ2UgYW5kIHVzZXIKICAgaW50ZXJmYWNlLgoKCgoKCgoKCgpIYXJ0a2Ug JiBTaGVsYnkgICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDE2LCAyMDExICAgICAgICAgICAgICAg W1BhZ2UgM10KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgIE9ic2VydmluZyBSZXNvdXJjZXMgaW4g Q29BUCAgICAgICAgICAgIE1hcmNoIDIwMTEKCgogICBPYnNlcnZlciAgICAgICAgICAgU3ViamVj dAogICAgICB8ICAgICAgICAgICAgICAgICAgfAogICAgICB8ICAgICBSZWdpc3RlciAgICAgfAog ICAgICArLS0tLS0tLS0tLS0tLS0tLS0+fAogICAgICB8ICAgICAgICAgICAgICAgICAgfAogICAg ICB8ICAgTm90aWZpY2F0aW9uICAgfAogICAgICB8PC0tLS0tLS0tLS0tLS0tLS0tKwogICAgICB8 ICAgICAgICAgICAgICAgICAgfAogICAgICB8ICAgTm90aWZpY2F0aW9uICAgfAogICAgICB8PC0t LS0tLS0tLS0tLS0tLS0tKwogICAgICB8ICAgICAgICAgICAgICAgICAgfAogICAgICB8ICAgTm90 aWZpY2F0aW9uICAgfAogICAgICB8PC0tLS0tLS0tLS0tLS0tLS0tKwogICAgICB8ICAgICAgICAg ICAgICAgICAgfAoKICAgICAgICAgICAgICAgICBGaWd1cmUgMTogU3ViamVjdC9PYnNlcnZlciBE ZXNpZ24gUGF0dGVybgoKICAgVGhlIGRlc2lnbiBwYXR0ZXJuIGlzIHJlYWxpemVkIGluIENvQVAg YXMgZm9sbG93czoKCiAgIFN1YmplY3Q6ICBJbiB0aGUgY29udGV4dCBvZiBDb0FQLCB0aGUgc3Vi amVjdCBpcyBhIHJlc291cmNlIGxvY2F0ZWQKICAgICAgYXQgc29tZSBDb0FQIHNlcnZlci4gIFRo ZSBzdGF0ZSBvZiB0aGUgcmVzb3VyY2UgbWF5IGNoYW5nZSBvdmVyCiAgICAgIHRpbWUsIHJhbmdp bmcgZnJvbSBpbmZyZXF1ZW50IHVwZGF0ZXMgdG8gY29udGludW91cyBzdGF0ZQogICAgICB0cmFu c2Zvcm1hdGlvbnMuCgogICBPYnNlcnZlcjogIFRoZSBvYnNlcnZlciBpcyBhIENvQVAgY2xpZW50 IHRoYXQgaXMgaW50ZXJlc3RlZCBpbiB0aGUKICAgICAgY3VycmVudCBzdGF0ZSBvZiB0aGUgcmVz b3VyY2UgYXQgYW55IGdpdmVuIHRpbWUuCgogICBPYnNlcnZhdGlvbiBSZWxhdGlvbnNoaXA6ICBB IGNsaWVudCByZWdpc3RlcnMgaXRzZWxmIHdpdGggYSByZXNvdXJjZQogICAgICBieSBzZW5kaW5n IGEgbW9kaWZpZWQgR0VUIHJlcXVlc3QgdG8gdGhlIHNlcnZlci4gIFRoZSByZXF1ZXN0CiAgICAg IGNhdXNlcyB0aGUgc2VydmVyIHRvIGVzdGFibGlzaCBhbiBvYnNlcnZhdGlvbiByZWxhdGlvbnNo aXAgYmV0d2VlbgogICAgICB0aGUgY2xpZW50IGFuZCB0aGUgcmVzb3VyY2UuICBUaGUgcmVzcG9u c2UgdG8gdGhlIEdFVCByZXF1ZXN0CiAgICAgIHN1cHBsaWVzIHRoZSBjbGllbnQgd2l0aCBhIHJl cHJlc2VudGF0aW9uIG9mIHRoZSBjdXJyZW50IHJlc291cmNlCiAgICAgIHN0YXRlLgoKICAgTm90 aWZpY2F0aW9uOiAgV2hlbmV2ZXIgdGhlIHN0YXRlIG9mIGEgcmVzb3VyY2UgY2hhbmdlcywgdGhl IHNlcnZlcgogICAgICBub3RpZmllcyBlYWNoIGNsaWVudCB0aGF0IGhhcyBhbiBvYnNlcnZhdGlv biByZWxhdGlvbnNoaXAgdG8gdGhhdAogICAgICByZXNvdXJjZS4gIFRoZSBub3RpZmljYXRpb24g aXMgYW4gYWRkaXRpb25hbCByZXNwb25zZSB0byB0aGUgR0VUCiAgICAgIHJlcXVlc3Q7IGl0IHN1 cHBsaWVzIHRoZSBjbGllbnQgd2l0aCBhIHJlcHJlc2VudGF0aW9uIG9mIHRoZSBuZXcKICAgICAg cmVzb3VyY2Ugc3RhdGUuICBUaGUgcmVzcG9uc2UgZWNob2VzIHRoZSB0b2tlbiBzcGVjaWZpZWQg aW4gdGhlCiAgICAgIHJlcXVlc3QsIHNvIHRoZSBjbGllbnQgY2FuIGVhc2lseSBjb3JyZWxhdGUg bm90aWZpY2F0aW9ucy4KICAgICAgCiAge1NlZSA0LjEgYmVsb3cgZm9yIGEgc3VnZ2VzdGlvbiBj b25jZXJuaW5nIHBlcmlvZGljIG5vdGlmaWNhdGlvbnMuIElmCiAgeW91IGZpbmQgdGhpcyBhY2Nl cHRhYmxlLCB0aGVuIGRvZXMgdGhlIGFib3ZlIGRlZmluaXRpb24gbmVlZCB0byBiZQogIGNobmFn ZWQgdG8gcmVhZCAiV2hlbmV2ZXIgdGhlIHN0YXRlIG9mIGEgcmVzb3VyY2UgY2hhbmdlcywgb3Ig b3RoZXJ3aXNlCiAgYnkgdGhlIGNob2ljZSBvZiB0aGUgc2VydmVyLCB0aGUgc2VydmVyIG5vdGlm aWVzLi4uIn0KCiAgIEZpZ3VyZSAyIHNob3dzIGFuIGV4YW1wbGUgb2YgYSBDb0FQIGNsaWVudCBl c3RhYmxpc2hpbmcgYW4KICAgb2JzZXJ2YXRpb24gcmVsYXRpb25zaGlwIHRvIGEgcmVzb3VyY2Ug b24gYSBDb0FQIHNlcnZlciBhbmQgYmVpbmcKICAgbm90aWZpZWQsIG9uY2UgdXBvbiByZWdpc3Ry YXRpb24gYW5kIHRoZW4gd2hlbmV2ZXIgdGhlIHN0YXRlIG9mIHRoZQogICByZXNvdXJjZSBjaGFu Z2VzLiAgVGhlIHJlcXVlc3QgdG8gZXN0YWJsaXNoIGFuIG9ic2VydmF0aW9uCiAgIHJlbGF0aW9u c2hpcCBhbmQgYWxsIG5vdGlmaWNhdGlvbnMgYXJlIGlkZW50aWZpZWQgYnkgdGhlIG5ldyBPYnNl cnZlCiAgIE9wdGlvbiBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQuCgoKCgpIYXJ0a2UgJiBTaGVs YnkgICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDE2LCAyMDExICAgICAgICAgICAgICAgW1BhZ2Ug NF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgIE9ic2VydmluZyBSZXNvdXJjZXMgaW4gQ29BUCAg ICAgICAgICAgIE1hcmNoIDIwMTEKCgogICBDbGllbnQgICAgICAgICAgICAgIFNlcnZlcgogICAg ICB8ICAgICAgICAgICAgICAgICAgfAogICAgICB8IEdFVCAvdGVtcGVyYXR1cmUgfAogICAgICB8 ICBPYnNlcnZlOiAwICAgICAgfCAgKGVzdGFibGlzaCBvYnNlcnZhdGlvbiByZWxhdGlvbnNoaXAp CiAgICAgIHwgICAgVG9rZW46IDB4NGEgICB8CiAgICAgICstLS0tLS0tLS0tLS0tLS0tLT58CiAg ICAgIHwgICAgICAgICAgICAgICAgICB8CiAgICAgIHwgICAyLjA1IENvbnRlbnQgICB8CiAgICAg IHwgIE9ic2VydmU6IDEyICAgICB8ICAoaW5pdGlhbCBub3RpZmljYXRpb24gb2YgY3VycmVudCBz dGF0ZSkKICAgICAgfCAgICBUb2tlbjogMHg0YSAgIHwKICAgICAgfCAgUGF5bG9hZDogMjIuOSBD IHwKICAgICAgfDwtLS0tLS0tLS0tLS0tLS0tLSsKICAgICAgfCAgICAgICAgICAgICAgICAgIHwK ICAgICAgfCAgIDIuMDUgQ29udGVudCAgIHwKICAgICAgfCAgT2JzZXJ2ZTogNDQgICAgIHwgIChu b3RpZmljYXRpb24gdXBvbiBzdGF0ZSBjaGFuZ2UpCiAgICAgIHwgICAgVG9rZW46IDB4NGEgICB8 CiAgICAgIHwgIFBheWxvYWQ6IDIyLjggQyB8CiAgICAgIHw8LS0tLS0tLS0tLS0tLS0tLS0rCiAg ICAgIHwgICAgICAgICAgICAgICAgICB8CiAgICAgIHwgICAyLjA1IENvbnRlbnQgICB8CiAgICAg IHwgIE9ic2VydmU6IDYwICAgICB8ICAobm90aWZpY2F0aW9uIHVwb24gc3RhdGUgY2hhbmdlKQog ICAgICB8ICAgIFRva2VuOiAweDRhICAgfAogICAgICB8ICBQYXlsb2FkOiAyMy4xIEMgfAogICAg ICB8PC0tLS0tLS0tLS0tLS0tLS0tKwogICAgICB8ICAgICAgICAgICAgICAgICAgfAoKICAgICAg ICAgICAgICAgICAgRmlndXJlIDI6IE9ic2VydmluZyBhIFJlc291cmNlIGluIENvQVAKCgozLiAg T2JzZXJ2YXRpb24gUmVsYXRpb25zaGlwcwoKMy4xLiAgRXN0YWJsaXNobWVudAoKICAgQSBjbGll bnQgcmVnaXN0ZXJzIGl0c2VsZiB3aXRoIGEgcmVzb3VyY2UgYnkgcGVyZm9ybWluZyBhIEdFVCBy ZXF1ZXN0CiAgIHRoYXQgaW5jbHVkZXMgYW4gT2JzZXJ2ZSBPcHRpb24uICAoU2VlIFNlY3Rpb24g NSBmb3IgdGhlIG9wdGlvbgogICBkZWZpbml0aW9uLikgIFdoZW4gYSBzZXJ2ZXIgcmVjZWl2ZXMg c3VjaCBhIHJlcXVlc3QsIGl0IHNlcnZpY2VzIHRoZQogICByZXF1ZXN0IGxpa2UgYSBHRVQgcmVx dWVzdCB3aXRob3V0IHRoaXMgb3B0aW9uIGFuZCwgaWYgdGhlIHJlc3VsdGluZwogICByZXNwb25z ZSBpbmRpY2F0ZXMgc3VjY2VzcywgZXN0YWJsaXNoZXMgYW4gb2JzZXJ2YXRpb24gcmVsYXRpb25z aGlwCiAgIGJldHdlZW4gdGhlIGNsaWVudCBhbmQgdGhlIHRhcmdldCByZXNvdXJjZS4KCiAgIFRo ZSB0b2tlbiBzcGVjaWZpZWQgYnkgdGhlIGNsaWVudCBpbiB0aGUgR0VUIHJlcXVlc3Qgd2lsbCBi ZSBlY2hvZWQKICAgYnkgdGhlIHNlcnZlciBpbiB0aGUgaW5pdGlhbCByZXNwb25zZSBhbmQgaW4g YWxsIG5vdGlmaWNhdGlvbnMgc2VudAogICB0byB0aGUgY2xpZW50IGFzIHBhcnQgb2YgdGhlIG9i c2VydmF0aW9uIHJlbGF0aW9uc2hpcC4gIFRoZSBzZXJ2ZXIKICAgd2lsbCBhbHNvIGluY2x1ZGUg YW4gT2JzZXJ2ZSBPcHRpb24gaW4gZWFjaCByZXNwb25zZS9ub3RpZmljYXRpb24gdG8KICAgaW5k aWNhdGUgdGhhdCB0aGUgb2JzZXJ2YXRpb24gcmVsYXRpb25zaGlwIHdhcyBzdWNjZXNzZnVsbHkK ICAgZXN0YWJsaXNoZWQuICAoU2VlIFNlY3Rpb24gNCBmb3IgdGhlIGRldGFpbHMgb2Ygbm90aWZp Y2F0aW9ucy4pCgogICBBIHNlcnZlciB0aGF0IGlzIHVuYWJsZSBvciB1bndpbGxpbmcgdG8gZXN0 YWJsaXNoIGFuIG9ic2VydmF0aW9uCgoKCkhhcnRrZSAmIFNoZWxieSAgICAgICAgRXhwaXJlcyBT ZXB0ZW1iZXIgMTYsIDIwMTEgICAgICAgICAgICAgICBbUGFnZSA1XQoMCkludGVybmV0LURyYWZ0 ICAgICAgICAgT2JzZXJ2aW5nIFJlc291cmNlcyBpbiBDb0FQICAgICAgICAgICAgTWFyY2ggMjAx MQoKCiAgIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIGEgY2xpZW50IGFuZCBhIHJlc291cmNlIE1VU1Qg c2lsZW50bHkgaWdub3JlIHRoZQogICBPYnNlcnZlIE9wdGlvbiBhbmQgcHJvY2VzcyB0aGUgR0VU IHJlcXVlc3QgYXMgdXN1YWwuICBUaGUgcmVzdWx0aW5nCiAgIHJlc3BvbnNlIHdpbGwgbm90IGlu Y2x1ZGUgYW4gT2JzZXJ2ZSBPcHRpb24sIGltcGx5aW5nIHRoYXQgbm8KICAgb2JzZXJ2YXRpb24g cmVsYXRpb25zaGlwIHdhcyBlc3RhYmxpc2hlZC4KCjMuMi4gIE1haW50ZW5hbmNlCgogICBBIGNs aWVudCBNQVkgcmVmcmVzaCBhbiBvYnNlcnZhdGlvbiByZWxhdGlvbnNoaXAgYXQgYW55IHRpbWUu ICAoRm9yCiAgIGV4YW1wbGUsIHdoZW4gaXQgZGlkbid0IHJlY2VpdmUgYSBub3RpZmljYXRpb24g Zm9yIHNvbWUgdGltZSwgaXQgaXMKICAgbm90IGNsZWFyIHdoZXRoZXIgdGhlIHJlc291cmNlIG5l dmVyIGNoYW5nZWQgb3IgdGhlIHNlcnZlciByZWJvb3RlZAogICBhbmQgbG9zdCBpdHMgc3RhdGUg LS0gdGhpcyBpcyBzaW1pbGFyIHRvIHRoZSBrZWVwLWFsaXZlIHByb2JsZW0gb2YKICAgdHJhbnNw b3J0IHByb3RvY29scywgc2VlIGUuZy4gdGhlIGRpc2N1c3Npb24gaW4gW1JGQzExMjJdLikgIEhv d2V2ZXIsCiAgIGl0IGlzIFJFQ09NTUVOREVEIHRoYXQgdGhlIGNsaWVudCBkb2VzIG5vdCByZWZy ZXNoIHRoZSByZWxhdGlvbnNoaXAKICAgZm9yIHRoZSB0aW1lIHNwZWNpZmllZCBpbiB0aGUgTWF4 LUFnZSBPcHRpb24gb2YgdGhlIG1vc3QgcmVjZW50CiAgIG5vdGlmaWNhdGlvbiByZWNlaXZlZCwg aW5jbHVkaW5nIHRoZSBpbml0aWFsIHJlc3BvbnNlLgoKICAgQSBjbGllbnQgcmVmcmVzaGVzIGFu IG9ic2VydmF0aW9uIHJlbGF0aW9uc2hpcCBzaW1wbHkgYnkgcmVwZWF0aW5nCiAgIHRoZSBHRVQg cmVxdWVzdCB3aXRoIHRoZSBPYnNlcnZlIE9wdGlvbi4gIFdoZW4gYSBzZXJ2ZXIgcmVjZWl2ZXMg c3VjaAogICBhIHJlcGVhdGVkIHJlcXVlc3QgKGkuZS4gYSBHRVQgcmVxdWVzdCBmcm9tIGEgY2xp ZW50IGZvciB3aGljaCBhbgogICBvYnNlcnZhdGlvbiByZWxhdGlvbnNoaXAgYWxyZWFkeSBleGlz dHMpLCBpdCBNVVNUIE5PVCBlc3RhYmxpc2ggYQogICBzZWNvbmQgcmVsYXRpb25zaGlwIGJ1dCBN VVNUIHJlcGxhY2Ugb3IgdXBkYXRlIHRoZSBleGlzdGluZyBvbmUuIElmIGEgR0VUCiAgIHJlcXVl c3QgZG9lcyBub3QgaW5jbHVkZSBhbiBPYnNlcnZlIE9wdGlvbiwgdGhlIHNlcnZlciBNVVNUIGVu ZCBhbnkKICAgcmVsYXRpb25zaGlwIHRoYXQgbWF5IGV4aXN0IGJldHdlZW4gdGhlIGNsaWVudCBh bmQgdGhlIHRhcmdldAogICByZXNvdXJjZS4KCiAgIFRoZSBleGFjdCBydWxlcyBmb3IgZGV0ZXJt aW5pbmcgaWYgdHdvIHJlcXVlc3RzIHJlbGF0ZSB0byB0aGUgc2FtZQogICBvYnNlcnZhdGlvbiBy ZWxhdGlvbnNoaXAgYXJlIGFzIGZvbGxvd3M6CgogICBvICBUaGUgcmVxdWVzdCBVUkkgb2YgdGhl IHR3byByZXF1ZXN0cyBNVVNUIG1hdGNoLgoKICAgbyAgVGhlIHNvdXJjZXMgb2YgdGhlIHR3byBy ZXF1ZXN0cyBNVVNUIG1hdGNoLiAgSG93IHRoaXMgaXMKICAgICAgZGV0ZXJtaW5lZCBkZXBlbmRz IG9uIHRoZSBzZWN1cml0eSBtb2RlIHVzZWQgKHNlZSBTZWN0aW9uIDEwIG9mCiAgICAgIFtJLUQu aWV0Zi1jb3JlLWNvYXBdKTogV2l0aCBOb1NlYywgdGhlIElQIGFkZHJlc3MgYW5kIHBvcnQgbnVt YmVyCiAgICAgIG9mIHRoZSByZXF1ZXN0IHNvdXJjZXMgbXVzdCBtYXRjaC4gIFdpdGggb3RoZXIg c2VjdXJpdHkgbW9kZXMsIGluCiAgICAgIGFkZGl0aW9uIHRvIHRoZSBJUCBhZGRyZXNzIGFuZCBV RFAgcG9ydCBudW1iZXIgbWF0Y2hpbmcsIHRoZQogICAgICByZXF1ZXN0cyBtdXN0IGhhdmUgdGhl IHNhbWUgc2VjdXJpdHkgY29udGV4dC4KCiAgIG8gIFRoZSBNZXNzYWdlIElEcyBhbmQgYW55IFRv a2VuIE9wdGlvbnMgaW4gdGhlIHR3byByZXF1ZXN0cyBNVVNUIE5PVAogICAgICBiZSB0YWtlbiBp bnRvIGFjY291bnQuCgozLjMuICBUZXJtaW5hdGlvbgoKICAgVGhlIG9ic2VydmF0aW9uIHJlbGF0 aW9uc2hpcCBiZXR3ZWVuIGEgY2xpZW50IGFuZCBhIHJlc291cmNlIGVuZHMKICAgd2hlbiBvbmUg b2YgdGhlIGZvbGxvd2luZyBjb25kaXRpb25zIG9jY3VyczoKCiAgIG8gIFRoZSBzZXJ2ZXIgc2Vu ZHMgYSBub3RpZmljYXRpb24gcmVzcG9uc2Ugd2l0aCBhbiBlcnJvciByZXNwb25zZQogICAgICBj b2RlICg0Lnh4IG9yIDUueHgpLgoKCgoKSGFydGtlICYgU2hlbGJ5ICAgICAgICBFeHBpcmVzIFNl cHRlbWJlciAxNiwgMjAxMSAgICAgICAgICAgICAgIFtQYWdlIDZdCgwKSW50ZXJuZXQtRHJhZnQg ICAgICAgICBPYnNlcnZpbmcgUmVzb3VyY2VzIGluIENvQVAgICAgICAgICAgICBNYXJjaCAyMDEx CgoKICAgbyAgVGhlIGNsaWVudCByZWplY3RzIGEgY29uZmlybWFibGUgbm90aWZpY2F0aW9uIHdp dGggYSBSU1QgbWVzc2FnZS4KCiAgIG8gIFRoZSBsYXN0IGF0dGVtcHQgb2YgdHJhbnNtaXR0aW5n IGEgY29uZmlybWFibGUgbm90aWZpY2F0aW9uIHRvIHRoZQogICAgICBjbGllbnQgdGltZXMgb3V0 LiAgKEluIHRoaXMgY2FzZSwgdGhlIHNlcnZlciBNQVkgYWxzbyBlbmQgYWxsCiAgICAgIG90aGVy IG9ic2VydmF0aW9uIHJlbGF0aW9uc2hpcHMgdGhhdCB0aGUgY2xpZW50IGhhcy4pCgogICBBIGNs aWVudCBNQVkgdGVybWluYXRlIGFuIG9ic2VydmF0aW9uIHJlbGF0aW9uc2hpcCBieSBwZXJmb3Jt aW5nIG9uZQogICBvZiB0aGUgZm9sbG93aW5nIGFjdGlvbnM6CgogICBvICBUaGUgY2xpZW50IHJl amVjdHMgYSBjb25maXJtYWJsZSBub3RpZmljYXRpb24gd2l0aCBhIFJTVCBtZXNzYWdlLgoKICAg byAgVGhlIGNsaWVudCBwZXJmb3JtcyBhIEdFVCByZXF1ZXN0IG9uIHRoZSByZXNvdXJjZSB3aXRo b3V0IGFuCiAgICAgIE9ic2VydmUgT3B0aW9uLgoKCjQuICBOb3RpZmljYXRpb25zCgogICBXaGVu IGFuIG9ic2VydmF0aW9uIHJlbGF0aW9uc2hpcCBpcyBlc3RhYmxpc2hlZCBiZXR3ZWVuIGEgY2xp ZW50IGFuZAogICBhIHJlc291cmNlLCB0aGUgY2xpZW50IGlzIG5vdGlmaWVkIG9mIHJlc291cmNl IHN0YXRlIGNoYW5nZXMgYnkKICAgYWRkaXRpb25hbCByZXNwb25zZXMgc2VudCBpbiByZXBseSB0 byB0aGUgR0VUIHJlcXVlc3QgdG8gdGhlIGNsaWVudC4KICAgRWFjaCBzdWNoIG5vdGlmaWNhdGlv biByZXNwb25zZSBNVVNUIGluY2x1ZGUgYW4gT2JzZXJ2ZSBPcHRpb24gYW5kCiAgIGVjaG8gdGhl IHRva2VuIHNwZWNpZmllZCBieSB0aGUgY2xpZW50IGluIHRoZSByZXF1ZXN0LiAgVGhlIG9yZGVy IGluCiAgIHdoaWNoIG9ic2VydmVycyBhcmUgbm90aWZpZWQgYWJvdXQgYSBzdGF0ZSBjaGFuZ2Ug aXMgbm90IGRlZmluZWQ7IHRoZQogICBzZXJ2ZXIgaXMgZnJlZSB0byB1c2UgYW55IG1ldGhvZCB0 byBkZXRlcm1pbmUgdGhlIG9yZGVyLgoKICAgQSBub3RpZmljYXRpb24gU0hPVUxEIGhhdmUgYSAy LjA1IChDb250ZW50KSBvciAyLjAzIChWYWxpZCkgcmVzcG9uc2UKICAgY29kZS4gIEhvd2V2ZXIs IGluIHRoZSBldmVudCB0aGF0IHRoZSBzdGF0ZSBvZiBhIHJlc291cmNlIGlzIGNoYW5nZWQKICAg aW4gYSB3YXkgdGhhdCB3b3VsZCBjYXVzZSBhIGJhc2ljIEdFVCByZXF1ZXN0IHRvIHJldHVybiBh biBlcnJvciAoZm9yCiAgIGV4YW1wbGUsIHdoZW4gdGhlIHJlc291cmNlIGlzIGRlbGV0ZWQpLCB0 aGUgc2VydmVyIFNIT1VMRCBub3RpZnkgdGhlCiAgIGNsaWVudCBieSBzZW5kaW5nIGEgbm90aWZp Y2F0aW9uIHdpdGggYW4gYXBwcm9wcmlhdGUgZXJyb3IgY29kZSBhbmQKICAgTVVTVCBlbmQgdGhl IG9ic2VydmF0aW9uIHJlbGF0aW9uc2hpcC4KCiAgIFRoZSByZXByZXNlbnRhdGlvbiBmb3JtYXQg KGkuZS4gdGhlIG1lZGlhIHR5cGUpIHVzZWQgaW4gYW55CiAgIG5vdGlmaWNhdGlvbiByZXN1bHRp bmcgZnJvbSBhbiBvYnNlcnZhdGlvbiByZWxhdGlvbnNoaXAgTVVTVCBiZSB0aGUKICAgc2FtZSBm b3JtYXQgdXNlZCBpbiB0aGUgaW5pdGlhbCByZXNwb25zZSB0byB0aGUgR0VUIHJlcXVlc3QuICBJ ZiB0aGUKICAgc2VydmVyIGlzIHVuYWJsZSB0byBjb250aW51ZSBzZW5kaW5nIG5vdGlmaWNhdGlv bnMgaW4gdGhpcyBmb3JtYXQsIGl0CiAgIFNIT1VMRCBzZW5kIGEgNS4wMCAoSW50ZXJuYWwgU2Vy dmVyIEVycm9yKSBub3RpZmljYXRpb24gcmVzcG9uc2UgYW5kCiAgIE1VU1QgZW5kIHRoZSBvYnNl cnZhdGlvbiByZWxhdGlvbnNoaXAuCgogICBBIG5vdGlmaWNhdGlvbiBjYW4gYmUgc2VudCBjb25m aXJtYWJsZSBvciBub24tY29uZmlybWFibGUuICBBIHNlcnZlcgogICBjYW4gZW1wbG95IGRpZmZl cmVudCBzdHJhdGVnaWVzIGZvciBub3RpZnlpbmcgYSBjbGllbnQ7IHNlZQogICBTZWN0aW9uIDQu MSBiZWxvdy4gIFRoZSBvYmplY3RpdmUgaXMgdGhhdCB0aGUgc3RhdGUgb2JzZXJ2ZWQgYnkgdGhl CiAgIGNsaWVudCBldmVudHVhbGx5IGJlY29tZXMgY29uc2lzdGVudCB3aXRoIHRoZSBhY3R1YWwg c3RhdGUgb2YgdGhlCiAgIHJlc291cmNlLgoKICAgSWYgYSBjbGllbnQgZG9lcyBub3QgcmVjb2du aXplIHRoZSB0b2tlbiBpbiBhIGNvbmZpcm1hYmxlCiAgIG5vdGlmaWNhdGlvbiwgaXQgTVVTVCBO T1QgYWNrbm93bGVkZ2UgdGhlIG1lc3NhZ2UgYW5kIFNIT1VMRCByZWplY3QKICAgdGhlIG1lc3Nh Z2Ugd2l0aCBhIFJTVCBtZXNzYWdlIChpbiB3aGljaCBjYXNlIHRoZSBzZXJ2ZXIgTVVTVCBlbmQg dGhlCgoKCkhhcnRrZSAmIFNoZWxieSAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMTYsIDIwMTEg ICAgICAgICAgICAgICBbUGFnZSA3XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgT2JzZXJ2aW5n IFJlc291cmNlcyBpbiBDb0FQICAgICAgICAgICAgTWFyY2ggMjAxMQoKCiAgIG9ic2VydmF0aW9u KS4gIE90aGVyd2lzZSwgdGhlIGNsaWVudCBNVVNUIGFja25vd2xlZGdlIHRoZSBtZXNzYWdlCiAg IHdpdGggYW4gQUNLIG1lc3NhZ2UgYXMgdXN1YWwuICBTZWUgU2VjdGlvbiA0LjIgZm9yIGRldGFp bHMgb24gdGhlCiAgIHJldHJhbnNtaXNzaW9uIG9mIGNvbmZpcm1hYmxlIG1lc3NhZ2VzLgoKICAg Tm90ZSB0aGF0IG5vdGlmaWNhdGlvbnMgbWF5IGFycml2ZSBpbiBhIGRpZmZlcmVudCBvcmRlciB0 aGFuIHNlbnQgYnkKICAgdGhlIHNlcnZlciBkdWUgdG8gbmV0d29yayBsYXRlbmN5LiAgSWYgYSBu b3RpZmljYXRpb24gYXJyaXZlcyBiZWZvcmUKICAgdGhlIGluaXRpYWwgcmVzcG9uc2UgdG8gYSBy ZXF1ZXN0LCB0aGUgY2xpZW50IGNhbiB0YWtlIHRoZQogICBub3RpZmljYXRpb24gYXMgaW5pdGlh bCByZXNwb25zZSBpbiBwbGFjZSBvZiB0aGUgYWN0dWFsIGluaXRpYWwKICAgcmVzcG9uc2UuICBU aGUgY2xpZW50IG11c3QgYmUgcHJlcGFyZWQgdG8gcmVjZWl2ZSBub3RpZmljYXRpb25zIGFmdGVy CiAgIGFuIGVycm9yIG5vdGlmaWNhdGlvbiBvciBhZnRlciB0aGUgY2xpZW50IGhhcyByZXF1ZXN0 ZWQgdGhlIHNlcnZlciB0bwogICBlbmQgdGhlIG9ic2VydmF0aW9uIHJlbGF0aW9uc2hpcC4gIFNl ZSBTZWN0aW9uIDQuMyBmb3IgZnVydGhlcgogICBkZXRhaWxzIG9uIG1lc3NhZ2UgcmVvcmRlcmlu Zy4KCiAgIE5vdGlmaWNhdGlvbnMgTUFZIGJlIGNhY2hlZCBieSBDb0FQIGVuZC1wb2ludHMgdW5k ZXIgdGhlIHNhbWUKICAgY29uZGl0aW9ucyBhcyB3aXRoIGFsbCByZXNwb25zZXMuICBUaGlzIGlz IGRldGFpbGVkIGluIFNlY3Rpb24gNC40LgoKNC4xLiAgU3RyYXRlZ2llcwoKICAgVGhlIG9iamVj dGl2ZSB3aGVuIG5vdGlmeWluZyBjbGllbnRzIG9mIHN0YXRlIGNoYW5nZXMgaXMgdGhhdCB0aGUK ICAgc3RhdGUgb2JzZXJ2ZWQgYnkgdGhlIGNsaWVudCBldmVudHVhbGx5IGJlY29tZXMgY29uc2lz dGVudCB3aXRoIHRoZQogICBhY3R1YWwgc3RhdGUgb2YgdGhlIHJlc291cmNlLiAgVGhpcyBhbGxv d3MgdGhlIHNlcnZlciBzb21lIGxpYmVydGllcwogICBpbiBob3cgaXQgc2VuZHMgbm90aWZpY2F0 aW9ucywgYXMgbG9uZyBhcyBpdCB3b3JrcyB0b3dhcmRzIHRoaXMKICAgb2JqZWN0aXZlLgoKICAg QSBub3RpZmljYXRpb24gY2FuIGJlIHNlbnQgY29uZmlybWFibGUgb3Igbm9uLWNvbmZpcm1hYmxl LiAgVGhlCiAgIG1lc3NhZ2UgdHlwZSB1c2VkIGlzIHR5cGljYWxseSBhcHBsaWNhdGlvbi1kZXBl bmRlbnQgYW5kIE1BWSBiZQogICBkZXRlcm1pbmVkIGJ5IHRoZSBzZXJ2ZXIgZm9yIGVhY2ggbm90 aWZpY2F0aW9uIGluZGl2aWR1YWxseS4gIEZvcgogICBleGFtcGxlLCBmb3IgcmVzb3VyY2VzIHRo YXQgY2hhbmdlIGluIGEgc29tZXdoYXQgcHJlZGljdGFibGUgb3IKICAgcmVndWxhciBmYXNoaW9u LCBub3RpZmljYXRpb25zIGNhbiBiZSBzZW50IGluIG5vbi1jb25maXJtYWJsZQogICBtZXNzYWdl cy4gIEZvciByZXNvdXJjZXMgdGhhdCBjaGFuZ2UgaW5mcmVxdWVudGx5LCBub3RpZmljYXRpb25z IGNhbgogICBiZSBzZW50IGluIGNvbmZpcm1hYmxlIG1lc3NhZ2VzLiAgVGhlIHNlcnZlciBjYW4g Y29tYmluZSB0aGVzZSB0d28KICAgYXBwcm9hY2hlcyBkZXBlbmRpbmcgb24gdGhlIGZyZXF1ZW5j eSBvZiBzdGF0ZSBjaGFuZ2VzIGFuZCB0aGUKICAgaW1wb3J0YW5jZSBvZiBpbmRpdmlkdWFsIG5v dGlmaWNhdGlvbnMuCgogICBBIHNlcnZlciBNQVkgY2hvb3NlIHRvIG9taXQgbm90aWZ5aW5nIGEg Y2xpZW50IG9mIGEgc3RhdGUgY2hhbmdlIGlmCiAgIGl0IGtub3dzIHRoYXQgaXQgd2lsbCBzZW5k IGFub3RoZXIgbm90aWZpY2F0aW9uIHNvb24gKGUuZy4sIHdoZW4gdGhlCiAgIHN0YXRlIGlzIGNo YW5naW5nIGZyZXF1ZW50bHkgb3IgbWF5YmUgZXZlbiBjb250aW51b3VzbHkpLiAgU2ltaWxhcmx5 LAogICBpdCBNQVkgY2hvb3NlIHRvIG5vdGlmeSBhIGNsaWVudCBhYm91dCB0aGUgc2FtZSBzdGF0 ZSBjaGFuZ2UgbW9yZQogICB0aGFuIG9uY2UuICBGb3IgZXhhbXBsZSwgd2hlbiBzdGF0ZSBjaGFu Z2VzIG9jY3VyIGluIGJ1cnN0cywgdGhlCiAgIHNlcnZlciBjYW4gb21pdCBzb21lIG5vdGlmaWNh dGlvbnMsIHNlbmQgb3RoZXJzIGluIG5vbi1jb25maXJtYWJsZQogICBtZXNzYWdlcywgYW5kIG1h a2Ugc3VyZSB0aGF0IHRoZSBjbGllbnQgb2JzZXJ2ZXMgdGhlIGxhdGVzdCBzdGF0ZQogICBjaGFu Z2UgYnkgcmVwZWF0aW5nIHRoZSBsYXN0IG5vdGlmaWNhdGlvbiBpbiBhIGNvbmZpcm1hYmxlIG1l c3NhZ2UKICAgd2hlbiB0aGUgYnVyc3QgaXMgb3Zlci4KICAgCiAgIHtJcyBpdCB3b3J0aCBhZGRp bmcgYW4gZXhwbGljaXQgcGFyYWdyYXBoIGFib3V0IHBlcmlvZGljIG5vdGlmaWNhdGlvbnM/CiAg IFRoZXNlIGNhbiBwcmVzdW1hYmx5IGJlIGFjY29tb2RhdGVkLiBIb3cgYWJvdXQgdGhpczogCiAg IAogICAiSW4gc29tZSBhcHBsaWNhdGlvbnMgaXQgbWF5IGJlIGFwcHJvcHJpYXRlIGZvciBhIHNl cnZlciB0byBzZW5kCiAgIG5vdGlmaWNhdGlvbnMgYXQgcmVndWxhciBpbnRlcnZhbHMsIHN1Y2gg YXMgb25jZSBldmVyeSBmaXZlIHNlY29uZHMsCiAgIG9yIG9uY2UgZXZlcnkgMzAgbWludXRlcy4g SW4gc3VjaCBjYXNlcyBhIG5vdGlmaWNhdGlvbiBNQVkgYmUgc2VudAogICBldmVuIGlmIHRoZSBy ZXNvdXJjZSBoYXMgbm90IGNoYW5nZWQuIFRoaXMgaXMgcGVybWlzc2FibGUgYmVoYXZpb3VyCiAg IGZvciB0aGUgc2VydmVyLCBhbmQgaXMgYXBwbGljYXRpb24tc3BlY2lmaWMuIgogICB9Cgo0LjIu ICBSZXRyYW5zbWlzc2lvbgoKICAgQWNjb3JkaW5nIHRvIHRoZSBjb3JlIENvQVAgcHJvdG9jb2ws IGNvbmZpcm1hYmxlIG1lc3NhZ2VzIGFyZQogICByZXRyYW5zbWl0dGVkIGluIGV4cG9uZW50aWFs bHkgaW5jcmVhc2luZyBpbnRlcnZhbHMgZm9yIGEgY2VydGFpbgoKCgpIYXJ0a2UgJiBTaGVsYnkg ICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDE2LCAyMDExICAgICAgICAgICAgICAgW1BhZ2UgOF0K DApJbnRlcm5ldC1EcmFmdCAgICAgICAgIE9ic2VydmluZyBSZXNvdXJjZXMgaW4gQ29BUCAgICAg ICAgICAgIE1hcmNoIDIwMTEKCgogICBudW1iZXIgb2YgYXR0ZW1wdHMgdW50aWwgdGhleSBhcmUg YWNrbm93bGVkZ2VkIGJ5IHRoZSBjbGllbnQuICBJbiB0aGUKICAgY29udGV4dCBvZiBvYnNlcnZp bmcgYSByZXNvdXJjZSwgaXQgaXMgdW5kZXNpcmFibGUgdG8gY29udGludWUKICAgdHJhbnNtaXR0 aW5nIHRoZSByZXByZXNlbnRhdGlvbiBvZiBhIHJlc291cmNlIHN0YXRlIHdoZW4gdGhlIHN0YXRl CiAgIGNoYW5nZWQgaW4gdGhlIG1lYW50aW1lLiAgVGhlcmUgYXJlIG1hbnkgcmVhc29ucyB3aHkg YSBjbGllbnQgbWlnaHQKICAgbm90IGFja25vd2xlZGdlIGEgY29uZmlybWFibGUgbWVzc2FnZSwg cmFuZ2luZyBmcm9tIHNob3J0CiAgIGludGVycnVwdGlvbnMgaW4gdGhlIG5ldHdvcmsgdG8gYSBw ZXJtYW5lbnQgZmFpbHVyZSBvZiB0aGUgY2xpZW50LgoKICAgV2hlbiBhIHNlcnZlciBpcyByZXRy YW5zbWl0dGluZyBhIGNvbmZpcm1hYmxlIG1lc3NhZ2Ugd2l0aCBhCiAgIG5vdGlmaWNhdGlvbiwg aXMgd2FpdGluZyBmb3IgYW4gYWNrbm93bGVkZ2VtZW50LCBhbmQgd2FudHMgdG8gbm90aWZ5CiAg IHRoZSBjbGllbnQgb2YgYSBzdGF0ZSBjaGFuZ2UgdXNpbmcgYSBuZXcgY29uZmlybWFibGUgbWVz c2FnZSwgaXQgTVVTVAogICBzdG9wIHJldHJhbnNtaXR0aW5nIHRoZSBvbGQgbm90aWZpY2F0aW9u IGFuZCBNVVNUIGF0dGVtcHQgdG8gdHJhbnNtaXQKICAgdGhlIG5ldyBub3RpZmljYXRpb24gd2l0 aCB0aGUgbnVtYmVyIG9mIGF0dGVtcHRzIHJlbWFpbmluZyBmcm9tIHRoZQogICBvbGQgbm90aWZp Y2F0aW9uLiAgV2hlbiB0aGUgbGFzdCBhdHRlbXB0IHRvIHJldHJhbnNtaXQgYSBjb25maXJtYWJs ZQogICBtZXNzYWdlIHdpdGggYSBub3RpZmljYXRpb24gZm9yIGEgcmVzb3VyY2UgdGltZXMgb3V0 LCB0aGUgb2JzZXJ2YXRpb24KICAgcmVsYXRpb25zaGlwIGlzIGVuZGVkLgoKNC4zLiAgUmVvcmRl cmluZwoKICAgTWVzc2FnZXMgd2l0aCBub3RpZmljYXRpb25zIGNhbiBhcnJpdmUgaW4gYSBkaWZm ZXJlbnQgb3JkZXIgdGhhbiB0aGV5CiAgIHdlcmUgc2VudC4gIFNpbmNlIHRoZSBvYmplY3RpdmUg aXMgZXZlbnR1YWwgY29uc2lzdGVuY3ksIGEgY2xpZW50IGNhbgogICBzYWZlbHkgZGlzY2FyZCBh IG5vdGlmaWNhdGlvbiB0aGF0IGFycml2ZXMgbGF0ZXIgdGhhbiBhIG5ld2VyCiAgIG5vdGlmaWNh dGlvbi4KCiAgIEZvciB0aGlzIHB1cnBvc2UsIHRoZSBzZXJ2ZXIga2VlcHMgYSBzaW5nbGUgMTYt Yml0IHVuc2lnbmVkIGludGVnZXIKICAgdmFyaWFibGUuICBUaGUgdmFyaWFibGUgaXMgaW5jcmVt ZW50ZWQgYXBwcm94aW1hdGVseSBldmVyeSBzZWNvbmQsCiAgIHdyYXBwaW5nIGFyb3VuZCBldmVy eSAyXjE2IHNlY29uZHMgKHJvdWdobHkgMTguMiBob3VycykuICBUaGUgc2VydmVyCiAgIE1VU1Qg aW5jbHVkZSB0aGUgY3VycmVudCB2YWx1ZSBvZiB0aGUgdmFyaWFibGUgYXMgdGhlIHZhbHVlIG9m IHRoZQogICBPYnNlcnZlIE9wdGlvbiBlYWNoIHRpbWUgaXQgc2VuZHMgYSBub3RpZmljYXRpb24u ICBUaGUgc2VydmVyIE1VU1QKICAgTk9UIHNlbmQgdHdvIG5vdGlmaWNhdGlvbnMgd2l0aCB0aGUg c2FtZSB2YWx1ZSBvZiB0aGUgdmFyaWFibGUgdGhhdAogICBwZXJ0YWluIHRvIHRoZSBzYW1lIHJl c291cmNlIHRvIHRoZSBzYW1lIGNsaWVudC4ge0RvZXMgdGhpcyBzZXQgYW4gCiAgIHVwcGVyIGxp bWl0IG9mIG9uZSBub3RpZmljYXRpb24gcGVyIHNlY29uZD8gT3IgaXMgaXQgcGVybWlzc2FibGUg Zm9yIAogICBhIHNlcnZlciB0byBzZW5kIG5vdGlmaWNhdGlvbnMgbW9yZSBmcmVxdWVudGx5IHRo YW4gb25jZSBwZXIgc2Vjb25kCiAgIHNvIGxvbmcgYXMgaXQgaW5jcmVtZW50cyB0aGUgb3B0aW9u IHZhbHVlPyBEbyB3ZSBuZWVkIHRvIGFkZCBzb21ldGhpbmcKICAgZXhwbGljaXQgb24gdGhpcz99 CgogICBBIGNsaWVudCBNQVkgZGlzY2FyZCBhIG5vdGlmaWNhdGlvbiBhcyBvdXRkYXRlZCAobm90 IGZyZXNoKSB1bmRlciB0aGUKICAgZm9sbG93aW5nIGNvbmRpdGlvbjoKCiAgICAgIChWMSAtIFYy KSAlICgyXjE2KSA8ICgyXjE1KSAgICBhbmQgICAgVDIgPCAoVDEgKyAoMl4xNCkpCgogICB3aGVy ZSBUMSBpcyBhIGNsaWVudC1sb2NhbCB0aW1lc3RhbXAgb2YgdGhlIGxhdGVzdCB2YWxpZCBub3Rp ZmljYXRpb24KICAgcmVjZWl2ZWQgZm9yIHRoaXMgcmVzb3VyY2UgKGluIHNlY29uZHMpLCBUMiBh IGNsaWVudC1sb2NhbCB0aW1lc3RhbXAKICAgb2YgdGhlIGN1cnJlbnQgbm90aWZpY2F0aW9uLCBW MSB0aGUgdmFsdWUgb2YgdGhlIE9ic2VydmUgT3B0aW9uIG9mCiAgIHRoZSBsYXRlc3QgdmFsaWQg bm90aWZpY2F0aW9uIHJlY2VpdmVkLCBhbmQgVjIgdGhlIHZhbHVlIG9mIHRoZQogICBPYnNlcnZl IE9wdGlvbiBvZiB0aGUgY3VycmVudCBub3RpZmljYXRpb24uICBUaGUgZmlyc3QgY29uZGl0aW9u CiAgIGVzc2VudGlhbGx5IHZlcmlmaWVzIHRoYXQgVjIgPiBWMSBob2xkcyBpbiAxNi1iaXQgc2Vx dWVuY2UgbnVtYmVyCiAgIGFyaXRobWV0aWMgW1JGQzE5ODJdLiAgVGhlIHNlY29uZCBjb25kaXRp b24gY2hlY2tzIHRoYXQgdGhlIHRpbWUKICAgZXhwaXJlZCBiZXR3ZWVuIHRoZSB0d28gaW5jb21p bmcgbWVzc2FnZXMgaXMgbm90IHNvIGxhcmdlIHRoYXQgdGhlCiAgIHNlcXVlbmNlIG51bWJlciBt aWdodCBoYXZlIHdyYXBwZWQgYXJvdW5kIGFuZCB0aGUgZmlyc3QgY2hlY2sgaXMKICAgdGhlcmVm b3JlIGludmFsaWQgKGJ1dCBpcyBub3QgbmVlZGVkIGFueSBtb3JlLCBiZWNhdXNlIHJlb3JkZXJp bmcgaXMKICAgbm90IGV4cGVjdGVkIHRvIG9jY3VyIG9uIHRoZSBvcmRlciBvZiAyXjE0IHNlY29u ZHMpLiAgTm90ZSB0aGF0IHRoZQogICBjb25zdGFudHMgb2YgMl4xNCBhbmQgMl4xNSBhcmUgbm9u LWNyaXRpY2FsLCBhcyBpcyB0aGUgZXZlbiBzcGVlZCBvZgogICB7Tm90IHN1cmUgaWYgdGhlcmUg aXMgYSB0eXBvIGhlcmUgLSBJIGRvbid0IGdldCAiZXZlbiBzcGVlZCJ9CgoKCkhhcnRrZSAmIFNo ZWxieSAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMTYsIDIwMTEgICAgICAgICAgICAgICBbUGFn ZSA5XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgT2JzZXJ2aW5nIFJlc291cmNlcyBpbiBDb0FQ ICAgICAgICAgICAgTWFyY2ggMjAxMQoKCiAgIHRoZSBjbG9ja3MgaW52b2x2ZWQ7IGUuZy4sIHRo ZSBzZWNvbmQgY2hlY2sgY2FuIGJlIGltcGxlbWVudGVkIGJ5CiAgIG1hcmtpbmcgYSByZXNwb25z ZSBhcyBmcmVzaCBvbiByZWNlcHRpb24gYW5kIGRvd25ncmFkaW5nIGFsbAogICByZXNwb25zZXMg cGVyaW9kaWNhbGx5IGV2ZXJ5LCBzYXksIDJeMTMgc2Vjb25kczsgb25jZSBpdCBoYXMgYmVlbgog ICBkb3duZ3JhZGVkIHR3aWNlLCBpdCBubyBsb25nZXIgcGFydGljaXBhdGVzIGluIGZyZXNobmVz cyBjaGVja3MuCgo0LjQuICBDYWNoaW5nCgogICBBcyBub3RpZmljYXRpb25zIGFyZSBqdXN0IGFk ZGl0aW9uYWwgcmVzcG9uc2VzIHRvIGEgR0VUIHJlcXVlc3QsIHRoZQogICBzYW1lIHJ1bGVzIG9u IGNhY2hpbmcgYXBwbHkgYXMgdG8gYWxsIHJlc3BvbnNlczogQ29BUCBlbmQtcG9pbnRzIE1BWQog ICBjYWNoZSB0aGUgcmVzcG9uc2VzIGFuZCB0aGVyZWJ5IHJlZHVjZSB0aGUgcmVzcG9uc2UgdGlt ZSBhbmQgbmV0d29yawogICBiYW5kd2lkdGggY29uc3VtcHRpb24uICBCb3RoIHRoZSBmcmVzaG5l c3MgbW9kZWwgYW5kIHRoZSB2YWxpZGF0aW9uCiAgIG1vZGVsIGFyZSBzdXBwb3J0ZWQuCgogICBX aGVuIGEgcmVzcG9uc2UgaXMgZnJlc2ggaW4gdGhlIGNhY2hlLCBHRVQgcmVxdWVzdHMgY2FuIGJl IHNhdGlzZmllZAogICB3aXRob3V0IGNvbnRhY3RpbmcgdGhlIG9yaWdpbiBzZXJ2ZXIuICBUaGlz IGlzIHBhcnRpY3VsYXJseSB1c2VmdWwKICAgd2hlbiB0aGUgY2FjaGUgaXMgbG9jYXRlZCBhdCBh biBDb0FQIGludGVybWVkaWFyeSBzdWNoIGFzIGEgcHJveHkgb3IKICAgcmV2ZXJzZSBwcm94eS4g IChOb3RlIHRoYXQgdGhlIGZyZXNobmVzcyBvZiB0aGUgc3RvcmVkIHJlc3BvbnNlIGlzCiAgIGRl dGVybWluZWQgYnkgaXRzIE1heC1BZ2UgT3B0aW9uLCBub3QgdGhlIGV4aXN0ZW5jZSBvZiBhbiBv YnNlcnZhdGlvbgogICByZWxhdGlvbnNoaXAuICBTbyBhIHJlcXVlc3QgY2FuIGNhdXNlIHRoZSBl bmQtcG9pbnQgdG8gcmVmcmVzaCBjYWNoZQogICBhbmQgb2JzZXJ2YXRpb24gcmVsYXRpb25zaGlw IGV2ZW4gd2hpbGUgaGF2aW5nIGFuIHJlbGF0aW9uc2hpcC4pCiAgIHtQbGVhc2UgcmUtY2hlY2sg dGhlIGxhc3Qgc2VudGVuY2UsIHdoaWNoIGRvZXMgbm90IHNjYW4uIEkgYW0gbm90CiAgIGNlcnRh aW4gd2hhdCBpcyBpbnRlbmRlZCBzbyBoYXZlIG5vdCBhdHRlbXB0ZWQgdG8gY29ycmVjdCBpdC59 CgogICBXaGVuIGFuIGVuZC1wb2ludCBoYXMgb25lIG9yIG1vcmUgcmVzcG9uc2VzIHN0b3JlZCwg aXQgY2FuIHVzZSB0aGUKICAgRVRhZyBPcHRpb24gdG8gZ2l2ZSB0aGUgb3JpZ2luIHNlcnZlciBh biBvcHBvcnR1bml0eSB0byBzZWxlY3QgYQogICBzdG9yZWQgcmVzcG9uc2UgdG8gYmUgdXNlZC4g IFRoZSBlbmQtcG9pbnQgU0hPVUxEIGFkZCBhbiBFVGFnIE9wdGlvbgogICBzcGVjaWZ5aW5nIHRo ZSBlbnRpdHktdGFnIG9mIGVhY2ggc3RvcmVkIHJlc3BvbnNlIHRoYXQgaXMgYXBwbGljYWJsZS4K ICAgSXQgTVVTVCBrZWVwIHRob3NlIHJlc3BvbnNlcyBpbiB0aGUgY2FjaGUgdW50aWwgaXQgdGVy bWluYXRlcyB0aGUKICAgb2JzZXJ2YXRpb24gcmVsYXRpb25zaGlwIG9yIHNlbmRzIGEgR0VUIHJl cXVlc3Qgd2l0aCBhIG5ldyBzZXQgb2YKICAgZW50aXR5LXRhZ3MuICBXaGVuIHRoZSBvYnNlcnZl ZCByZXNvdXJjZSBjaGFuZ2VzIGl0cyBzdGF0ZSBhbmQgdGhlCiAgIG9yaWdpbiBzZXJ2ZXIgaXMg YWJvdXQgdG8gc2VuZCBhIDIuMDUgKENvbnRlbnQpIG5vdGlmaWNhdGlvbiwgdGhlbiwKICAgd2hl bmV2ZXIgdGhhdCBub3RpZmljYXRpb24gaGFzIGFuIGVudGl0eS10YWcgaW4gdGhlIHNldCBvZiBl bnRpdHktCiAgIHRhZ3Mgc3BlY2lmaWVkIGJ5IHRoZSBjbGllbnQsIGl0IHNlbmRzIGEgMi4wMyAo VmFsaWQpIHJlc3BvbnNlIHdpdGgKICAgYW4gYXBwcm9wcmlhdGUgRVRhZyBPcHRpb24gaW5zdGVh ZC4gIFRoZSBzZXJ2ZXIgTVVTVCBOT1QgYXNzdW1lIHRoYXQKICAgdGhlIHJlY2lwaWVudCBoYXMg YW55IHJlc3BvbnNlIHN0b3JlZCBvdGhlciB0aGFuIHRob3NlIGlkZW50aWZpZWQgYnkKICAgdGhl IGVudGl0eS10YWdzIGluIHRoZSBtb3N0IHJlY2VudCByZXF1ZXN0LgoKCjUuICBPYnNlcnZlIE9w dGlvbgoKICAgICAgICAgKy0tLS0tKy0tLS0tLS0tLS0rLS0tLS0tLS0tKy0tLS0tLS0tKy0tLS0t LS0tKy0tLS0tLS0tLSsKICAgICAgICAgfCBOby4gfCBDL0UgICAgICB8IE5hbWUgICAgfCBGb3Jt YXQgfCBMZW5ndGggfCBEZWZhdWx0IHwKICAgICAgICAgKy0tLS0tKy0tLS0tLS0tLS0rLS0tLS0t LS0tKy0tLS0tLS0tKy0tLS0tLS0tKy0tLS0tLS0tLSsKICAgICAgICAgfCAgMTAgfCBFbGVjdGl2 ZSB8IE9ic2VydmUgfCB1aW50ICAgfCAwLTIgQiAgfCAobm9uZSkgIHwKICAgICAgICAgKy0tLS0t Ky0tLS0tLS0tLS0rLS0tLS0tLS0tKy0tLS0tLS0tKy0tLS0tLS0tKy0tLS0tLS0tLSsKCiAgICAg ICAgICAgICAgICAgICAgICAgICAgIFRhYmxlIDE6IE9ic2VydmUgT3B0aW9uCgogICBUaGUgT2Jz ZXJ2ZSBPcHRpb24sIHdoZW4gcHJlc2VudCwgbW9kaWZpZXMgdGhlIEdFVCBtZXRob2Qgc28gaXQg ZG9lcwogICBub3Qgb25seSByZXRyaWV2ZSBhIHJlcHJlc2VudGF0aW9uIG9mIHRoZSBjdXJyZW50 IHN0YXRlIG9mIHRoZQoKCgpIYXJ0a2UgJiBTaGVsYnkgICAgICAgIEV4cGlyZXMgU2VwdGVtYmVy IDE2LCAyMDExICAgICAgICAgICAgICBbUGFnZSAxMF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAg IE9ic2VydmluZyBSZXNvdXJjZXMgaW4gQ29BUCAgICAgICAgICAgIE1hcmNoIDIwMTEKCgogICBy ZXNvdXJjZSBpZGVudGlmaWVkIGJ5IHRoZSByZXF1ZXN0IFVSSSBvbmNlLCBidXQgYWxzbyBsZXRz IHRoZSBzZXJ2ZXIKICAgbm90aWZ5IHRoZSBjbGllbnQgb2Ygc3Vic2VxdWVudCBjaGFuZ2VzIHRv IHRoZSByZXNvdXJjZSBzdGF0ZS4KICAgCiAgIHtDaGVjayB0aGlzOgogICBJbiBhIEdFVCByZXF1 ZXN0IHRoZSB2YWx1ZSBvZiB0aGUgT2JzZXJ2ZSBPcHRpb24gU0hPVUxEIGJlIHNldCB0byAwCiAg IChlbmNvZGVkIGFzIGEgemVyby1sZW5ndGggdmFsdWUpIGJ5IHRoZSBjbGllbnQgYW5kIE1VU1Qg YmUgaWdub3JlZCAKICAgYnkgdGhlIHNlcnZlci4KICAgfQoKICAgSW4gYSBHRVQgcmVzcG9uc2Us IHRoZSBPYnNlcnZlIE9wdGlvbiBpbmRpY2F0ZXMgdGhhdCBhbiBvYnNlcnZhdGlvbgogICByZWxh dGlvbnNoaXAgaGFzIGJlZW4gZXN0YWJsaXNoZWQuICBUaGUgb3B0aW9uJ3MgdmFsdWUgaXMgYSBz ZXF1ZW5jZQogICBudW1iZXIgdGhhdCBjYW4gYmUgdXNlZCBmb3IgcmVvcmRlcmluZyBkZXRlY3Rp b24gKHNlZSBTZWN0aW9uIDQuMykuCiAgIFRoZSB2YWx1ZSBpcyBlbmNvZGVkIGFzIGEgdmFyaWFi bGUtbGVuZ3RoIHVuc2lnbmVkIGludGVnZXIgKHNlZQogICBBcHBlbmRpeCBBIG9mIFtJLUQuaWV0 Zi1jb3JlLWNvYXBdKS4KCiAgIFNpbmNlIHRoZSBPYnNlcnZlIE9wdGlvbiBpcyBlbGVjdGl2ZSwg YSBHRVQgcmVxdWVzdCB0aGF0IGluY2x1ZGVzIHRoZQogICBPYnNlcnZlIE9wdGlvbiB3aWxsIGF1 dG9tYXRpY2FsbHkgZmFsbCBiYWNrIHRvIGEgYmFzaWMgR0VUIHJlcXVlc3QgaWYKICAgdGhlIHNl cnZlciBkb2VzIG5vdCBzdXBwb3J0IG9ic2VydmF0aW9ucy4KICAgCiAgIHtmb3IgY29uc2lzdGVu Y3kgd2l0aCBvdGhlciBvcHRpb24gZGVmaW5pdGlvbnMgaW4gY29hcC0wNTp9CiAgIAogICBUaGUg T2JzZXJ2ZSBPcHRpb24gTVVTVCBOT1Qgb2NjdXIgbW9yZSB0aGFuIG9uY2UuCgoKNi4gIEludGVy YWN0aW9ucyB3aXRoIG90aGVyIENvQVAgZmVhdHVyZXMKCjYuMS4gIFJlcXVlc3QgTWV0aG9kcwoK ICAgSWYgYSBjbGllbnQgaGFzIGFuIG9ic2VydmF0aW9uIHJlbGF0aW9uc2hpcCB3aXRoIGEgcmVz b3VyY2UgYW5kCiAgIHBlcmZvcm1zIGEgUE9TVCwgUFVUIG9yIERFTEVURSByZXF1ZXN0IG9uIHRo YXQgcmVzb3VyY2UsIHRoZSByZXF1ZXN0CiAgIE1VU1QgTk9UIGFmZmVjdCB0aGUgb2JzZXJ2YXRp b24gcmVsYXRpb25zaGlwLiAgSG93ZXZlciwgc2luY2Ugc3VjaCBhCiAgIHJlcXVlc3QgY2FuIGFm ZmVjdCB0aGUgb2JzZXJ2ZWQgcmVzb3VyY2UsIGl0IGNhbiBjYXVzZSB0aGUgc2VydmVyIHRvCiAg IHNlbmQgYSBub3RpZmljYXRpb24gd2l0aCBhIHJlc291cmNlIHN0YXRlIHJlcHJlc2VudGF0aW9u IG9yIGVuZCB0aGUKICAgb2JzZXJ2YXRpb24gcmVsYXRpb25zaGlwIHdpdGggYW4gZXJyb3Igbm90 aWZpY2F0aW9uIChlLmcuLCB3aGVuIGEKICAgREVMRVRFIHJlcXVlc3QgaXMgc3VjY2Vzc2Z1bCBh bmQgYW4gb2JzZXJ2ZWQgcmVzb3VyY2Ugbm8gbG9uZ2VyCiAgIGV4aXN0cykuCgogICBOb3RlIHRo YXQgYSBjbGllbnQgY2Fubm90IHBlcmZvcm0gYSBHRVQgcmVxdWVzdCBvbiBhIHJlc291cmNlIHRv CiAgIHJldHJpZXZlIGEgcmVwcmVzZW50YXRpb24gb2YgdGhlIGN1cnJlbnQgcmVzb3VyY2Ugc3Rh dGUgd2l0aG91dAogICBhZmZlY3RpbmcgYW4gZXhpc3Rpbmcgb2JzZXJ2YXRpb24gcmVsYXRpb25z aGlwIHRvIHRoYXQgcmVzb3VyY2U6IHRoZQogICBjbGllbnQgaXMgYWxyZWFkeSBub3RpZmllZCBi eSB0aGUgc2VydmVyIHdpdGggYSBmcmVzaCByZXByZXNlbnRhdGlvbgogICB3aGVuZXZlciB0aGUg c3RhdGUgY2hhbmdlcy4gIElmIHRoZSBjbGllbnQgd2FudHMgdG8gbWFrZSBzdXJlIHRoYXQgaXMK ICAgaGFzIGEgZnJlc2ggcmVwcmVzZW50YXRpb24gYW5kIHdhbnRzIHRvIGNvbnRpbnVlIGJlaW5n IG5vdGlmaWVkLCBpdAogICBzaG91bGQgcmVmcmVzaCB0aGUgb2JzZXJ2YXRpb24gcmVsYXRpb25z aGlwIChzZWUgU2VjdGlvbiAzLjIpLiAgSWYKICAgdGhlIGNsaWVudCB3YW50cyB0byBtYWtlIHN1 cmUgaXQgaGFzIGEgZnJlc2ggcmVwcmVzZW50YXRpb24gYW5kIGRvZXMKICAgbm90IHdhbnQgdG8g Y29udGludWUgYmVpbmcgbm90aWZpZWQsIGl0IHNob3VsZCBwZXJmb3JtIGEgR0VUIHJlcXVlc3QK ICAgd2l0aG91dCBhbiBPYnNlcnZlIE9wdGlvbiAoc2VlIFNlY3Rpb24gMy4zKS4KCjYuMi4gIEJs b2NrLXdpc2UgVHJhbnNmZXJzCgogICBSZXNvdXJjZXMgdGhhdCBhcmUgdGhlIHN1YmplY3Qgb2Yg YW4gb2JzZXJ2YXRpb24gcmVsYXRpb25zaGlwIG1heSBiZQogICBsYXJnZXIgdGhhbiBjYW4gYmUg Y29tZm9ydGFibHkgcHJvY2Vzc2VkIG9yIHRyYW5zZmVycmVkIGluIG9uZSBDb0FQCiAgIG1lc3Nh Z2UuICBDb0FQIHByb3ZpZGVzIGEgYmxvY2std2lzZSB0cmFuc2ZlciBtZWNoYW5pc20gdG8gYWRk cmVzcwogICB0aGlzIHByb2JsZW0gW0ktRC5pZXRmLWNvcmUtYmxvY2tdLiAgVGhlIGZvbGxvd2lu ZyBydWxlcyBhcHBseSB0byB0aGUKICAgY29tYmluYXRpb24gb2YgYmxvY2std2lzZSB0cmFuc2Zl cnMgd2l0aCBub3RpZmljYXRpb25zOgoKICAgbyAgQXMgd2l0aCBiYXNpYyBHRVQgdHJhbnNmZXJz LCB0aGUgY2xpZW50IGNhbiBpbmRpY2F0ZSBpdHMgZGVzaXJlZAogICAgICBibG9jayBzaXplIGlu IGEgQmxvY2sgb3B0aW9uIGluIHRoZSBHRVQgcmVxdWVzdC4gIElmIHRoZSBzZXJ2ZXIKCgoKSGFy dGtlICYgU2hlbGJ5ICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAxNiwgMjAxMSAgICAgICAgICAg ICAgW1BhZ2UgMTFdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICBPYnNlcnZpbmcgUmVzb3VyY2Vz IGluIENvQVAgICAgICAgICAgICBNYXJjaCAyMDExCgoKICAgICAgc3VwcG9ydHMgYmxvY2std2lz ZSB0cmFuc2ZlcnMsIGl0IFNIT1VMRCB0YWtlIG5vdGUgb2YgdGhlIGJsb2NrCiAgICAgIHNpemUg bm90IGp1c3QgZm9yIHRoZSBpbml0aWFsIHJlc3BvbnNlIGJ1dCBhbHNvIGZvciBmdXJ0aGVyCiAg ICAgIG5vdGlmaWNhdGlvbnMgaW4gdGhpcyBvYnNlcnZhdGlvbiByZWxhdGlvbnNoaXAuCgogICBv ICBOb3RpZmljYXRpb24gcmVzcG9uc2VzIGNhbiBtYWtlIHVzZSBvZiB0aGUgQmxvY2sgT3B0aW9u LiAgVGhlCiAgICAgIGNsaWVudCBTSE9VTEQgdXNlIHRoZSBPYnNlcnZlIE9wdGlvbiB2YWx1ZSBm cm9tIHRoZSBsYXN0IGJsb2NrLgogICAgICBBbGwgYmxvY2tzIGluIGEgbm90aWZpY2F0aW9uIHJl c3BvbnNlIFNIT1VMRCBhbHNvIGNhcnJ5IGFuIEVUYWcKICAgICAgb3B0aW9uIHRvIGVuc3VyZSB0 aGV5IGFyZSByZWFzc2VtYmxlZCBjb3JyZWN0bHkuCgo2LjMuICBSZXNvdXJjZSBEaXNjb3ZlcnkK CiAgIENsaWVudHMgY2FuIGRpc2NvdmVyIHJlc291cmNlcyB0aGF0IGFyZSBpbnRlcmVzdGluZyB0 byBvYnNlcnZlIHVzaW5nCiAgIENvUkUgUmVzb3VyY2UgRGlzY292ZXJ5IFtJLUQuaWV0Zi1jb3Jl LWxpbmstZm9ybWF0XS4gIExpbmtzIHdpdGggdGhlCiAgICJvYnMiIGF0dHJpYnV0ZSBpbmRpY2F0 ZSByZXNvdXJjZXMgdGhhdCBNVVNUIHN1cHBvcnQgdGhlIG1lY2hhbmlzbSBpbgogICB0aGlzIGRv Y3VtZW50IGFuZCBhcmUgUkVDT01NRU5ERUQgdG8gY2hhbmdlIHRoZWlyIHN0YXRlIGF0IGxlYXN0 IG9uY2UKICAgaW4gYSB3aGlsZS4KCiAgIFRoZSAib2JzIiBhdHRyaWJ1dGUgaXMgdXNlZCBhcyBh IGZsYWcsIGFuZCB0aHVzIGl0IGhhcyBubyB2YWx1ZQogICBjb21wb25lbnQuICBUaGUgYXR0cmli dXRlIE1VU1QgTk9UIGFwcGVhciBtb3JlIHRoYW4gb25jZSBpbiBhIGxpbmsuCiAgIAogICB7Tm90 ZSB0aGF0IHRoZSBsaW5rLWZvcm1hdCBkb2N1bWVudCBkb2VzIG5vdCBtZW50aW9uICJvYnMiIGF0 dHJpYnV0ZS4KICAgVGhlIGNoYW5nZSBsb2cgaW4gdGhlIGxpbmstZm9ybWF0IGRvY3VtZW50IG1l bnRpb25zIHJlbW92aW5nIHRoZSBvYnMKICAgYXR0cmlidXRlIGFuZCBwbGFjaW5nIGl0IGhlcmUu IElmICJvYnMiIGlzIGludGVuZGVkIHRvIGJlIHVzZWQsIHN1cmVseQogICBpdCBzaG91bGQgdGFr ZSBpdHMgcGxhY2UgaW4gc2VjdGlvbiAzIG9mIHRoZSBsaW5rLWZvcm1hdCBkb2N1bWVudCBhbG9u ZwogICB3aXRoIHRoZSBvdGhlciBhdHRyaWJ1dGVzIGRlZmluZWQgZm9yIHVzZSBpbiBDb1JFIGFw cGxpY2F0aW9ucz8KICAgV2UgYWxzbyBuZWVkIGV4YW1wbGVzIG9mIHVzZSwgc2luY2UgdGhpcyBk b2N1bWVudCBzYXlzICJpdCBoYXMgbm8gCiAgIHZhbHVlIGNvbXBvbmVudCIgLSBidXQgdGhlIGxp bmsgZm9ybWF0IGRvY3VtZW50IGV4cGxpY2l0bHkgZGVmaW5lcyAKICAgYW4gYXR0cmlidXRlIGFz ICJzZXQgb2Yga2V5L3ZhbHVlIHBhaXJzIiAtIHNvIGFuIGF0dHJpYnV0ZSB3aXRob3V0IAogICBh IHZhbHVlIGlzIGlsbGVnYWwsIGFuZCB3b3VsZCB2aW9sYXRlIHRoZSBBQk5GIGRlZmluaXRpb24g aW4gUkZDNTk4OC4KICAgQW5kIGFuIGF0dHJpYnV0ZSB3aXRob3V0IGEgdmFsdWUgd291bGQgbm90 IHdvcmsgd2l0aCB0aGUgcXVlcnkgCiAgIGZpbHRlcmluZyBkZWZpbmVkIGluIHNlY3Rpb24gNC4x IG9mIHRoZSBsaW5rLWZvcm1hdCBkb2N1bWVudC59CgoKNy4gIFNlY3VyaXR5IENvbnNpZGVyYXRp b25zCgogICBUaGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgb2YgdGhlIGJhc2UgcHJvdG9jb2wg W0ktRC5pZXRmLWNvcmUtY29hcF0KICAgYXBwbHkuCgogICBOb3RlIHRoYXQgdGhlIGNvbnNpZGVy YXRpb25zIGFib3V0IGFtcGxpZmljYXRpb24gYXR0YWNrcyBhcmUgc29tZXdoYXQKICAgYW1wbGlm aWVkIGluIGFuIG9ic2VydmF0aW9uIHJlbGF0aW9uc2hpcC4gIEluIE5vU2VjIG1vZGUsIGEgc2Vy dmVyCiAgIE1VU1QgdGhlcmVmb3JlIHN0cmljdGx5IGxpbWl0IHRoZSBudW1iZXIgb2YgbWVzc2Fn ZXMgZ2VuZXJhdGVkIGZyb20KICAgYW4gb2JzZXJ2YXRpb24gcmVsYXRpb25zaGlwIHRoYXQgaXQg c2VuZHMgYmV0d2VlbiByZWNlaXZpbmcgcGFja2V0cwogICB0aGF0IGNvbmZpcm0gdGhlIGFjdHVh bCBpbnRlcmVzdCBvZiB0aGUgcmVjaXBpZW50IGluIHRoZSBkYXRhOyBpLmUuLAogICBhbnkgbm90 aWZpY2F0aW9ucyBzZW50IGluIE5vbi1Db25maXJtYWJsZSBtZXNzYWdlcyBNVVNUIGJlCiAgIGlu dGVyc3BlcnNlZCB3aXRoIENvbmZpcm1hYmxlIG1lc3NhZ2VzLiAgKEFuIEF0dGFja2VyIG1heSBz dGlsbCBzcG9vZgogICB0aGUgYWNrbm93bGVkZ2VtZW50cyBpZiB0aGUgQ29uZmlybWFibGUgbWVz c2FnZXMgYXJlIHN1ZmZpY2llbnRseQogICBwcmVkaWN0YWJsZS4pCgogICBBcyB3aXRoIGFueSBw cm90b2NvbCB0aGF0IGNyZWF0ZXMgc3RhdGUsIGF0dGFja2VycyBtYXkgYXR0ZW1wdCB0bwogICBl eGhhdXN0IHRoZSByZXNvdXJjZXMgdGhhdCB0aGUgc2VydmVyIGhhcyBhdmFpbGFibGUgZm9yIG1h aW50YWluaW5nCiAgIG9ic2VydmF0aW9uIHJlbGF0aW9uc2hpcHMuICBTZXJ2ZXJzIE1BWSB3YW50 IHRvIGFjY2Vzcy1jb250cm9sIHRoaXMKICAgY3JlYXRpb24gb2Ygc3RhdGUuICBBcyBkZWdyYWRl ZCBiZWhhdmlvciwgdGhlIHNlcnZlciBjYW4gYWx3YXlzIGZhbGwKICAgYmFjayB0byBhIGJhc2lj IEdFVCByZXF1ZXN0ICh3aXRob3V0IGFuIE9ic2VydmUgT3B0aW9uKSBpZiBpdCBpcwogICB1bndp bGxpbmcgb3IgdW5hYmxlIHRvIGVzdGFibGlzaCB0aGUgb2JzZXJ2YXRpb24gcmVsYXRpb25zaGlw LAogICBpbmNsdWRpbmcgaWYgcmVzb3VyY2VzIGZvciBzdGF0ZSBhcmUgZXhoYXVzdGVkIG9yIG5l YXJpbmcgZXhoYXVzdGlvbi4KCiAgIEludGVybWVkaWFyaWVzIE1VU1QgYmUgY2FyZWZ1bCB0byBl bnN1cmUgdGhhdCBub3RpZmljYXRpb25zIGNhbm5vdCBiZQogICBlbXBsb3llZCB0byBjcmVhdGUg YSBsb29wLiAgQSBzaW1wbGUgd2F5IHRvIGJyZWFrIGFueSBsb29wcyBpcyB0bwogICBlbXBsb3kg Y2FjaGVzIGZvciBmb3J3YXJkaW5nIG5vdGlmaWNhdGlvbnMgaW4gaW50ZXJtZWRpYXJpZXMuCgoK CgpIYXJ0a2UgJiBTaGVsYnkgICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDE2LCAyMDExICAgICAg ICAgICAgICBbUGFnZSAxMl0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgIE9ic2VydmluZyBSZXNv dXJjZXMgaW4gQ29BUCAgICAgICAgICAgIE1hcmNoIDIwMTEKCgo4LiAgSUFOQSBDb25zaWRlcmF0 aW9ucwoKICAgVGhlIGZvbGxvd2luZyBlbnRyeSBpcyBhZGRlZCB0byB0aGUgQ29BUCBPcHRpb24g TnVtYmVycyByZWdpc3RyeToKCiAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLSstLS0tLS0t LS0rLS0tLS0tLS0tLS0rCiAgICAgICAgICAgICAgICAgICAgIHwgTnVtYmVyIHwgTmFtZSAgICB8 IFJlZmVyZW5jZSB8CiAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLSstLS0tLS0tLS0rLS0t LS0tLS0tLS0rCiAgICAgICAgICAgICAgICAgICAgIHwgICAgIDEwIHwgT2JzZXJ2ZSB8IFtSRkNY WFhYXSB8CiAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLSstLS0tLS0tLS0rLS0tLS0tLS0t LS0rCgogICAgICAgICAgICAgICAgICAgICBUYWJsZSAyOiBOZXcgQ29BUCBPcHRpb24gTnVtYmVy cwoKICAgVGhlIGZvbGxvd2luZyBlbnRyeSBpcyBhZGRlZCB0byB0aGUgQ29SRSBMaW5rIEZvcm1h dCBBdHRyaWJ1dGUKICAgcmVnaXN0cnk6CgogICAgICAgICAgICAgICAgICAgICAgICAgICArLS0t LS0tKy0tLS0tLS0tLS0tKwogICAgICAgICAgICAgICAgICAgICAgICAgICB8IE5hbWUgfCBSZWZl cmVuY2UgfAogICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tKy0tLS0tLS0tLS0tKwog ICAgICAgICAgICAgICAgICAgICAgICAgICB8IG9icyAgfCBbUkZDWFhYWF0gfAogICAgICAgICAg ICAgICAgICAgICAgICAgICArLS0tLS0tKy0tLS0tLS0tLS0tKwoKICAgICAgICAgICAgICAgICBU YWJsZSAzOiBOZXcgQ29SRSBMaW5rIEZvcm1hdCBBdHRyaWJ1dGVzCgoKOS4gIEFja25vd2xlZGdl bWVudHMKCiAgIENhcnN0ZW4gQm9ybWFubiB3YXMgYW4gb3JpZ2luYWwgYXV0aG9yIG9mIHRoaXMg ZHJhZnQgYW5kIGlzCiAgIGFja25vd2xlZGdlZCBmb3Igc2lnbmlmaWNhbnQgY29udHJpYnV0aW9u IHRvIHRoaXMgZG9jdW1lbnQuCgogICBUaGFua3MgdG8gRGFuaWVsZSBBbGVzc2FuZHJlbGxpLCBQ ZXRlciBCaWdvdCwgQW5nZWxvIENhc3RlbGxhbmksCiAgIEdpbGJlcnQgQ2xhcmssIEVza28gRGlq aywgQnJpYW4gRnJhbmsgYW5kIFNhbHZhdG9yZSBMb3JldG8gZm9yCiAgIGhlbHBmdWwgY29tbWVu dHMgYW5kIGRpc2N1c3Npb25zIHRoYXQgaGF2ZSBzaGFwZWQgdGhlIGRvY3VtZW50LgoKICAgS2xh dXMgSGFydGtlIHdhcyBmdW5kZWQgYnkgdGhlIEtsYXVzIFRzY2hpcmEgRm91bmRhdGlvbi4KCgox MC4gIFJlZmVyZW5jZXMKCjEwLjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlcwoKICAgW0ktRC5pZXRm LWNvcmUtYmxvY2tdCiAgICAgICAgICAgICAgU2hlbGJ5LCBaLiBhbmQgQy4gQm9ybWFubiwgIkJs b2Nrd2lzZSB0cmFuc2ZlcnMgaW4gQ29BUCIsCiAgICAgICAgICAgICAgZHJhZnQtaWV0Zi1jb3Jl LWJsb2NrLTAyICh3b3JrIGluIHByb2dyZXNzKSwgTWFyY2ggMjAxMS4KCiAgIFtJLUQuaWV0Zi1j b3JlLWNvYXBdCiAgICAgICAgICAgICAgU2hlbGJ5LCBaLiwgSGFydGtlLCBLLiwgQm9ybWFubiwg Qy4sIGFuZCBCLiBGcmFuaywKICAgICAgICAgICAgICAiQ29uc3RyYWluZWQgQXBwbGljYXRpb24g UHJvdG9jb2wgKENvQVApIiwKICAgICAgICAgICAgICBkcmFmdC1pZXRmLWNvcmUtY29hcC0wNSAo d29yayBpbiBwcm9ncmVzcyksIE1hcmNoIDIwMTEuCgoKCkhhcnRrZSAmIFNoZWxieSAgICAgICAg RXhwaXJlcyBTZXB0ZW1iZXIgMTYsIDIwMTEgICAgICAgICAgICAgIFtQYWdlIDEzXQoMCkludGVy bmV0LURyYWZ0ICAgICAgICAgT2JzZXJ2aW5nIFJlc291cmNlcyBpbiBDb0FQICAgICAgICAgICAg TWFyY2ggMjAxMQoKCiAgIFtJLUQuaWV0Zi1jb3JlLWxpbmstZm9ybWF0XQogICAgICAgICAgICAg IFNoZWxieSwgWi4sICJDb1JFIExpbmsgRm9ybWF0IiwKICAgICAgICAgICAgICBkcmFmdC1pZXRm LWNvcmUtbGluay1mb3JtYXQtMDMgKHdvcmsgaW4gcHJvZ3Jlc3MpLAogICAgICAgICAgICAgIE1h cmNoIDIwMTEuCgogICBbUkZDMjExOV0gIEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1c2Ug aW4gUkZDcyB0byBJbmRpY2F0ZQogICAgICAgICAgICAgIFJlcXVpcmVtZW50IExldmVscyIsIEJD UCAxNCwgUkZDIDIxMTksIE1hcmNoIDE5OTcuCgoxMC4yLiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNl cwoKICAgW1JFU1RdICAgICBGaWVsZGluZywgUi4sICJBcmNoaXRlY3R1cmFsIFN0eWxlcyBhbmQg dGhlIERlc2lnbiBvZgogICAgICAgICAgICAgIE5ldHdvcmstYmFzZWQgU29mdHdhcmUgQXJjaGl0 ZWN0dXJlcyIsIDIwMDAsIDxodHRwOi8vCiAgICAgICAgICAgICAgd3d3Lmljcy51Y2kuZWR1L35m aWVsZGluZy9wdWJzL2Rpc3NlcnRhdGlvbi90b3AuaHRtPi4KCiAgIFtSRkMxMTIyXSAgQnJhZGVu LCBSLiwgIlJlcXVpcmVtZW50cyBmb3IgSW50ZXJuZXQgSG9zdHMgLQogICAgICAgICAgICAgIENv bW11bmljYXRpb24gTGF5ZXJzIiwgU1REIDMsIFJGQyAxMTIyLCBPY3RvYmVyIDE5ODkuCgogICBb UkZDMTk4Ml0gIEVseiwgUi4gYW5kIFIuIEJ1c2gsICJTZXJpYWwgTnVtYmVyIEFyaXRobWV0aWMi LCBSRkMgMTk4MiwKICAgICAgICAgICAgICBBdWd1c3QgMTk5Ni4KCiAgIFtSRkMyNjE2XSAgRmll bGRpbmcsIFIuLCBHZXR0eXMsIEouLCBNb2d1bCwgSi4sIEZyeXN0eWssIEguLAogICAgICAgICAg ICAgIE1hc2ludGVyLCBMLiwgTGVhY2gsIFAuLCBhbmQgVC4gQmVybmVycy1MZWUsICJIeXBlcnRl eHQKICAgICAgICAgICAgICBUcmFuc2ZlciBQcm90b2NvbCAtLSBIVFRQLzEuMSIsIFJGQyAyNjE2 LCBKdW5lIDE5OTkuCgogICBbUkZDNTk4OV0gIFJvYWNoLCBBLiwgIkEgU0lQIEV2ZW50IFBhY2th Z2UgZm9yIFN1YnNjcmliaW5nIHRvIENoYW5nZXMKICAgICAgICAgICAgICB0byBhbiBIVFRQIFJl c291cmNlIiwgUkZDIDU5ODksIE9jdG9iZXIgMjAxMC4KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CkhhcnRrZSAmIFNoZWxieSAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMTYsIDIwMTEgICAgICAg ICAgICAgIFtQYWdlIDE0XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgT2JzZXJ2aW5nIFJlc291 cmNlcyBpbiBDb0FQICAgICAgICAgICAgTWFyY2ggMjAxMQoKCkFwcGVuZGl4IEEuICBFeGFtcGxl cwoKICAgQ2xpZW50ICBTZXJ2ZXIKICAgICAgfCAgICAgIHwKICAgICAgfCAgICAgIHwKICAgICAg Ky0tLS0tPnwgICAgIEhlYWRlcjogR0VUIChUPUNPTiwgQ29kZT0xLCBNSUQ9MHgxNjMzKQogICAg ICB8IEdFVCAgfCAgICAgIFRva2VuOiAweDRhCiAgICAgIHwgICAgICB8ICAgICAgICBVcmk6IGNv YXA6Ly9zZW5zb3IuZXhhbXBsZS90ZW1wZXJhdHVyZQogICAgICB8ICAgICAgfCAgICBPYnNlcnZl OiAwCiAgICAgIHwgICAgICB8CiAgICAgIHwgICAgICB8CiAgICAgIHw8LS0tLS0rICAgICBIZWFk ZXI6IDIuMDUgQ29udGVudCAoVD1BQ0ssIENvZGU9NjksIE1JRD0weDE2MzMpCiAgICAgIHwgMi4w NSB8ICAgICAgVG9rZW46IDB4NGEKICAgICAgfCAgICAgIHwgICAgT2JzZXJ2ZTogMjcKICAgICAg fCAgICAgIHwgICAgUGF5bG9hZDogIjIyLjkgQyIKICAgICAgfCAgICAgIHwKICAgICAgfCAgICAg IHwKICAgICAgfDwtLS0tLSsgICAgIEhlYWRlcjogMi4wNSBDb250ZW50IChUPU5PTiwgQ29kZT02 OSwgTUlEPTB4N2I1MCkKICAgICAgfCAyLjA1IHwgICAgICBUb2tlbjogMHg0YQogICAgICB8ICAg ICAgfCAgICBPYnNlcnZlOiAyOAogICAgICB8ICAgICAgfCAgICBQYXlsb2FkOiAiMjIuOCBDIgog ICAgICB8ICAgICAgfAogICAgICB8ICAgICAgfAogICAgICB8PC0tLS0tKyAgICAgSGVhZGVyOiAy LjA1IENvbnRlbnQgKFQ9Tk9OLCBDb2RlPTY5LCBNSUQ9MHg3YjUxKQogICAgICB8IDIuMDUgfCAg ICAgIFRva2VuOiAweDRhCiAgICAgIHwgICAgICB8ICAgIE9ic2VydmU6IDI5CiAgICAgIHwgICAg ICB8ICAgIFBheWxvYWQ6ICIyMi41IEMiCiAgICAgIHwgICAgICB8CgogICAgICBGaWd1cmUgMzog U2ltcGxlIG9ic2VydmF0aW9uIHdpdGggbm9uLWNvbmZpcm1hYmxlIG5vdGlmaWNhdGlvbnMKCgoK CgoKCgoKCgoKCgoKCgoKCgoKSGFydGtlICYgU2hlbGJ5ICAgICAgICBFeHBpcmVzIFNlcHRlbWJl ciAxNiwgMjAxMSAgICAgICAgICAgICAgW1BhZ2UgMTVdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAg ICBPYnNlcnZpbmcgUmVzb3VyY2VzIGluIENvQVAgICAgICAgICAgICBNYXJjaCAyMDExCgoKQS4x LiAgUHJveHlpbmcKCkNsaWVudCAgUHJveHkgIFNlcnZlcgogICB8ICAgICAgfCAgICAgIHwKICAg fCAgICAgIHwgICAgICB8CiAgIHwgICAgICArLS0tLS0+fCAgICAgSGVhZGVyOiBHRVQgKFQ9Q09O LCBDb2RlPTEsIE1JRD0weDVmYjgpCiAgIHwgICAgICB8IEdFVCAgfCAgICAgIFRva2VuOiAweDFh CiAgIHwgICAgICB8ICAgICAgfCAgICAgICAgVXJpOiBjb2FwOi8vc2Vuc29yLmV4YW1wbGUvc3Rh dHVzCiAgIHwgICAgICB8ICAgICAgfCAgICBPYnNlcnZlOiAwCiAgIHwgICAgICB8ICAgICAgfAog ICB8ICAgICAgfCAgICAgIHwKICAgfCAgICAgIHw8LS0tLS0rICAgICBIZWFkZXI6IDIuMDUgQ29u dGVudCAoVD1BQ0ssIENvZGU9NjksIE1JRD0weDVmYjgpCiAgIHwgICAgICB8IDIuMDUgfCAgICAg IFRva2VuOiAweDFhCiAgIHwgICAgICB8ICAgICAgfCAgICBPYnNlcnZlOiA0MgogICB8ICAgICAg fCAgICAgIHwgICAgTWF4LUFnZTogMTIwIHNlYwogICB8ICAgICAgfCAgICAgIHwgICAgUGF5bG9h ZDogInJlYWR5IgogICB8ICAgICAgfCAgICAgIHwKICAgfCAgICAgIHwgICAgICB8CiAgICstLS0t LT58ICAgICAgfCAgICAgSGVhZGVyOiBHRVQgKFQ9Q09OLCBDb2RlPTEsIE1JRD0weDE2MzMpCiAg IHwgR0VUICB8ICAgICAgfCAgICAgIFRva2VuOiAweDlhCiAgIHwgICAgICB8ICAgICAgfCAgUHJv eHktVXJpOiBjb2FwOi8vc2Vuc29yLmV4YW1wbGUvc3RhdHVzCiAgIHwgICAgICB8ICAgICAgfAog ICB8ICAgICAgfCAgICAgIHwKICAgfDwtLS0tLSsgICAgICB8ICAgICBIZWFkZXI6IDIuMDUgQ29u dGVudCAoVD1BQ0ssIENvZGU9NjksIE1JRD0weDE2MzMpCiAgIHwgMi4wNSB8ICAgICAgfCAgICAg IFRva2VuOiAweDlhCiAgIHwgICAgICB8ICAgICAgfCAgICBNYXgtQWdlOiAxMTMgc2VjCiAgIHwg ICAgICB8ICAgICAgfCAgICBQYXlsb2FkOiAicmVhZHkiCiAgIHwgICAgICB8ICAgICAgfAogICB8 ICAgICAgfCAgICAgIHwKICAgfCAgICAgIHw8LS0tLS0rICAgICBIZWFkZXI6IDIuMDUgQ29udGVu dCAoVD1OT04sIENvZGU9NjksIE1JRD0weDVmYzApCiAgIHwgICAgICB8IDIuMDUgfCAgICAgIFRv a2VuOiAweDFhCiAgIHwgICAgICB8ICAgICAgfCAgICBPYnNlcnZlOiAxNzgwCiAgIHwgICAgICB8 ICAgICAgfCAgICBNYXgtQWdlOiAxMjAgc2VjCiAgIHwgICAgICB8ICAgICAgfCAgICBQYXlsb2Fk OiAiYnVzeSIKICAgfCAgICAgIHwgICAgICB8CiAgIHwgICAgICB8ICAgICAgfAogICArLS0tLS0+ fCAgICAgIHwgICAgIEhlYWRlcjogR0VUIChUPUNPTiwgQ29kZT0xLCBNSUQ9MHgxNjM0KQogICB8 IEdFVCAgfCAgICAgIHwgICAgICBUb2tlbjogMHg5YgogICB8ICAgICAgfCAgICAgIHwgIFByb3h5 LVVyaTogY29hcDovL3NlbnNvci5leGFtcGxlL3N0YXR1cwogICB8ICAgICAgfCAgICAgIHwKICAg fCAgICAgIHwgICAgICB8CiAgIHw8LS0tLS0rICAgICAgfCAgICAgSGVhZGVyOiAyLjA1IENvbnRl bnQgKFQ9QUNLLCBDb2RlPTY5LCBNSUQ9MHgxNjM0KQogICB8IDIuMDUgfCAgICAgIHwgICAgICBU b2tlbjogMHg5YgogICB8ICAgICAgfCAgICAgIHwgICAgTWF4LUFnZTogODkgc2VjCiAgIHwgICAg ICB8ICAgICAgfCAgICBQYXlsb2FkOiAiYnVzeSIKICAgfCAgICAgIHwgICAgICB8CgogICAgRmln dXJlIDQ6IEEgcHJveHkgb2JzZXJ2ZXMgYSByZXNvdXJjZSB0byBrZWVwIGl0cyBjYWNoZSB1cCB0 byBkYXRlCgoKCkhhcnRrZSAmIFNoZWxieSAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMTYsIDIw MTEgICAgICAgICAgICAgIFtQYWdlIDE2XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgT2JzZXJ2 aW5nIFJlc291cmNlcyBpbiBDb0FQICAgICAgICAgICAgTWFyY2ggMjAxMQoKCkNsaWVudCAgUHJv eHkgIFNlcnZlcgogICB8ICAgICAgfCAgICAgIHwKICAgfCAgICAgIHwgICAgICB8CiAgICstLS0t LT58ICAgICAgfCAgICAgSGVhZGVyOiBHRVQgKFQ9Q09OLCBDb2RlPTEsIE1JRD0weDE2MzMpCiAg IHwgR0VUICB8ICAgICAgfCAgICAgIFRva2VuOiAweDZhCiAgIHwgICAgICB8ICAgICAgfCAgUHJv eHktVXJpOiBjb2FwOi8vc2Vuc29yLmV4YW1wbGUvc3RhdHVzCiAgIHwgICAgICB8ICAgICAgfCAg ICBPYnNlcnZlOiAwCiAgIHwgICAgICB8ICAgICAgfAogICB8ICAgICAgfCAgICAgIHwKICAgfDwt IC0gLSsgICAgICB8ICAgICBIZWFkZXI6IChUPUFDSywgQ29kZT0wLCBNSUQ9MHgxNjMzKQogICB8 ICAgICAgfCAgICAgIHwKICAgfCAgICAgIHwgICAgICB8CiAgIHwgICAgICArLS0tLS0+fCAgICAg SGVhZGVyOiBHRVQgKFQ9Q09OLCBDb2RlPTEsIE1JRD0weGFmOTApCiAgIHwgICAgICB8IEdFVCAg fCAgICAgIFRva2VuOiAweGFhCiAgIHwgICAgICB8ICAgICAgfCAgICAgICAgVXJpOiBjb2FwOi8v c2Vuc29yLmV4YW1wbGUvc3RhdHVzCiAgIHwgICAgICB8ICAgICAgfCAgICBPYnNlcnZlOiAwCiAg IHwgICAgICB8ICAgICAgfAogICB8ICAgICAgfCAgICAgIHwKICAgfCAgICAgIHw8LS0tLS0rICAg ICBIZWFkZXI6IDIuMDUgQ29udGVudCAoVD1BQ0ssIENvZGU9NjksIE1JRD0weGFmOTApCiAgIHwg ICAgICB8IDIuMDUgfCAgICAgIFRva2VuOiAweGFhCiAgIHwgICAgICB8ICAgICAgfCAgICBPYnNl cnZlOiA2NwogICB8ICAgICAgfCAgICAgIHwgICAgUGF5bG9hZDogInJlYWR5IgogICB8ICAgICAg fCAgICAgIHwKICAgfCAgICAgIHwgICAgICB8CiAgIHw8LS0tLS0rICAgICAgfCAgICAgSGVhZGVy OiAyLjA1IENvbnRlbnQgKFQ9Q09OLCBDb2RlPTY5LCBNSUQ9MHhhZjk0KQogICB8IDIuMDUgfCAg ICAgIHwgICAgICBUb2tlbjogMHg2YQogICB8ICAgICAgfCAgICAgIHwgICAgT2JzZXJ2ZTogMzQ2 CiAgIHwgICAgICB8ICAgICAgfCAgICBQYXlsb2FkOiAicmVhZHkiCiAgIHwgICAgICB8ICAgICAg fAogICB8ICAgICAgfCAgICAgIHwKICAgKy0gLSAtPnwgICAgICB8ICAgICBIZWFkZXI6IChUPUFD SywgQ29kZT0wLCBNSUQ9MHhhZjk0KQogICB8ICAgICAgfCAgICAgIHwKICAgfCAgICAgIHwgICAg ICB8CiAgIHwgICAgICB8PC0tLS0tKyAgICAgSGVhZGVyOiAyLjA1IENvbnRlbnQgKFQ9Q09OLCBD b2RlPTY5LCBNSUQ9MHg1YTIwKQogICB8ICAgICAgfCAyLjA1IHwgICAgICBUb2tlbjogMHhhYQog ICB8ICAgICAgfCAgICAgIHwgICAgT2JzZXJ2ZTogMTQ2MAogICB8ICAgICAgfCAgICAgIHwgICAg UGF5bG9hZDogImJ1c3kiCiAgIHwgICAgICB8ICAgICAgfAogICB8ICAgICAgfCAgICAgIHwKICAg fCAgICAgICstIC0gLT58ICAgICBIZWFkZXI6IChUPUFDSywgQ29kZT0wLCBNSUQ9MHg1YTIwKQog ICB8ICAgICAgfCAgICAgIHwKICAgfCAgICAgIHwgICAgICB8CiAgIHw8LS0tLS0rICAgICAgfCAg ICAgSGVhZGVyOiAyLjA1IENvbnRlbnQgKFQ9Q09OLCBDb2RlPTY5LCBNSUQ9MHhhZjliKQogICB8 IDIuMDUgfCAgICAgIHwgICAgICBUb2tlbjogMHg2YQogICB8ICAgICAgfCAgICAgIHwgICAgT2Jz ZXJ2ZTogMjAxMQogICB8ICAgICAgfCAgICAgIHwgICAgUGF5bG9hZDogImJ1c3kiCiAgIHwgICAg ICB8ICAgICAgfAogICB8ICAgICAgfCAgICAgIHwKCgoKSGFydGtlICYgU2hlbGJ5ICAgICAgICBF eHBpcmVzIFNlcHRlbWJlciAxNiwgMjAxMSAgICAgICAgICAgICAgW1BhZ2UgMTddCgwKSW50ZXJu ZXQtRHJhZnQgICAgICAgICBPYnNlcnZpbmcgUmVzb3VyY2VzIGluIENvQVAgICAgICAgICAgICBN YXJjaCAyMDExCgoKICAgKy0gLSAtPnwgICAgICB8ICAgICBIZWFkZXI6IChUPUFDSywgQ29kZT0w LCBNSUQ9MHhhZjliKQogICB8ICAgICAgfCAgICAgIHwKCiAgICAgICAgICBGaWd1cmUgNTogQSBj bGllbnQgb2JzZXJ2ZXMgYSByZXNvdXJjZSB0aHJvdWdoIGEgcHJveHkKCntDYW4geW91IGNoZWNr L2V4cGxhaW4gdGhlIHZhbHVlIG9mIE9ic2VydmUgaW4gdGhlIEZpZ3VyZSA1IGV4YW1wbGU/IFRo ZSAKc2VydmVyIHJldHVybnMgNjcgYnV0IHRoZSBwcm94eSByZXR1cm5zIDM0Ni4gSXMgdGhpcyB0 aGUgdmFsdWUgb2YgYSBPYnNlcnZlCmNvdW50ZXIgbWFpbnRhaW5lZCBieSB0aGUgUHJveHk/IElz IGl0IE9LIGZvciB0aGUgUHJveHkgdG8gcmV0dXJuIGl0cyBvd24KY291bnRlciByYXRoZXIgdGhh biBwYXNzaW5nIG9uIHRoZSBzZXJ2ZXIncyBjb3VudGVyPyBUaGlzIHNob3VsZCBiZSAKZXhwbGlj aXQsIEkgdGhpbmssIGluIHNlY3Rpb24gNC40LiBJbiBhbnkgZXZlbnQsIGJvdGggCnNob3VsZCBh ZHZhbmNlIGJ5IG9uZSBhYm91dCBldmVyeSBzZWNvbmQsIHNvIEkgd291bGQgZXhwZWN0IHRoYXQg aW4gdGhlCnNlY29uZCByZXNwb25zZSB0byB0aGUgY2xpZW50IHRoZSBPYnNlcnZlIHZhbHVlIHNo b3VsZCBiZSAxNDYwICsgKDM0Ni02NykKPSAxNzM5LCBub3QgMjAxMS4gT3IgYW0gSSBtaXNzaW5n IHNvbWV0aGluZz8KfQoKQXBwZW5kaXggQi4gIENoYW5nZWxvZwoKICAgQ2hhbmdlcyBmcm9tIGll dGYtMDEgdG8gaWV0Zi0wMjoKCiAgIG8gIFJlbW92ZWQgdGhlIHJlcXVpcmVtZW50IG9mIHBlcmlv ZGljIHJlZnJlc2hpbmcgKCMxMjYpLgoKICAgbyAgVGhlIG5ldyAiT2JzZXJ2ZSIgT3B0aW9uIHJl cGxhY2VzIHRoZSAiTGlmZXRpbWUiIE9wdGlvbi4KCiAgIG8gIE5ldyBtZWNoYW5pc20gdG8gZGV0 ZWN0IG1lc3NhZ2UgcmVvcmRlcmluZy4KCiAgIG8gIENoYW5nZWQgMi4wMCAoT0spIG5vdGlmaWNh dGlvbnMgdG8gMi4wNSAoQ29udGVudCkgbm90aWZpY2F0aW9ucy4KCiAgIENoYW5nZXMgZnJvbSBp ZXRmLTAwIHRvIGlldGYtMDE6CgogICBvICBDaGFuZ2VkIHRlcm1pbm9sb2d5IGZyb20gInN1YnNj cmlwdGlvbnMiIHRvICJvYnNlcnZhdGlvbgogICAgICByZWxhdGlvbnNoaXBzIiAoIzMzKS4KCiAg IG8gIENoYW5nZWQgdGhlIG5hbWUgb2YgdGhlIG9wdGlvbiB0byAiTGlmZXRpbWUiLgoKICAgbyAg Q2xhcmlmaWVkIGVzdGFibGlzaG1lbnQgb2Ygb2JzZXJ2YXRpb24gcmVsYXRpb25zaGlwcy4KCiAg IG8gIENsYXJpZmllZCB0aGF0IGFuIG9ic2VydmF0aW9uIGlzIG9ubHkgaWRlbnRpZmllZCBieSB0 aGUgVVJJIG9mIHRoZQogICAgICBvYnNlcnZlZCByZXNvdXJjZSBhbmQgdGhlIGlkZW50aXR5IG9m IHRoZSBjbGllbnQgKCM2NikuCgogICBvICBDbGFyaWZpZWQgcnVsZXMgZm9yIGVzdGFibGlzaGlu ZyBvYnNlcnZhdGlvbiByZWxhdGlvbnNoaXBzICgjNjgpLgoKICAgbyAgQ2xhcmlmaWVkIGNvbmRp dGlvbnMgdW5kZXIgd2hpY2ggYW4gb2JzZXJ2YXRpb24gcmVsYXRpb25zaGlwIGlzCiAgICAgIHRl cm1pbmF0ZWQuCgogICBvICBBZGRlZCBleHBsYW5hdGlvbiBvbiBob3cgY2xpZW50cyBjYW4gdGVy bWluYXRlIGFuIG9ic2VydmF0aW9uCiAgICAgIHJlbGF0aW9uc2hpcCBiZWZvcmUgdGhlIGxpZmV0 aW1lIGVuZHMgKCMzNCkuCgogICBvICBDbGFyaWZpZWQgdGhhdCB0aGUgb3ZlcnJpZGluZyBvYmpl Y3RpdmUgZm9yIG5vdGlmaWNhdGlvbnMgaXMKICAgICAgZXZlbnR1YWwgY29uc2lzdGVuY3kgb2Yg dGhlIGFjdHVhbCBhbmQgdGhlIG9ic2VydmVkIHN0YXRlICgjNjcpLgoKICAgbyAgU3BlY2lmaWVk IGhvdyBhIHNlcnZlciBuZWVkcyB0byBkZWFsIHdpdGggY2xpZW50cyBub3QKICAgICAgYWNrbm93 bGVkZ2luZyBjb25maXJtYWJsZSBtZXNzYWdlcyBjYXJyeWluZyBub3RpZmljYXRpb25zICgjNjkp LgoKICAgbyAgQWRkZWQgYSBtZWNoYW5pc20gdG8gZGV0ZWN0IG1lc3NhZ2UgcmVvcmRlcmluZyAo IzM1KS4KCiAgIG8gIEFkZGVkIGFuIGV4cGxhbmF0aW9uIG9mIGhvdyBub3RpZmljYXRpb25zIGNh biBiZSBjYWNoZWQsCiAgICAgIHN1cHBvcnRpbmcgYm90aCB0aGUgZnJlc2huZXNzIGFuZCB0aGUg dmFsaWRhdGlvbiBtb2RlbCAoIzM5LCAjNjQpLgoKCgpIYXJ0a2UgJiBTaGVsYnkgICAgICAgIEV4 cGlyZXMgU2VwdGVtYmVyIDE2LCAyMDExICAgICAgICAgICAgICBbUGFnZSAxOF0KDApJbnRlcm5l dC1EcmFmdCAgICAgICAgIE9ic2VydmluZyBSZXNvdXJjZXMgaW4gQ29BUCAgICAgICAgICAgIE1h cmNoIDIwMTEKCgogICBvICBDbGFyaWZpZWQgdGhhdCBub24tR0VUIHJlcXVlc3RzIGRvIG5vdCBh ZmZlY3Qgb2JzZXJ2YXRpb24KICAgICAgcmVsYXRpb25zaGlwcywgYW5kIHRoYXQgR0VUIHJlcXVl c3RzIHdpdGhvdXQgIkxpZmV0aW1lIiBPcHRpb24KICAgICAgYWZmZWN0aW5nIHJlbGF0aW9uc2hp cHMgaXMgYnkgZGVzaWduICgjNjUpLgoKICAgbyAgRGVzY3JpYmVkIGludGVyYWN0aW9uIHdpdGgg YmxvY2std2lzZSB0cmFuc2ZlcnMgKCMzNikuCgogICBvICBBZGRlZCBSZXNvdXJjZSBEaXNjb3Zl cnkgc2VjdGlvbiAoIzk5KS4KCiAgIG8gIEFkZGVkIElBTkEgQ29uc2lkZXJhdGlvbnMuCgogICBv ICBBZGRlZCBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAoIzQwKS4KCiAgIG8gIEFkZGVkIGV4YW1w bGVzICgjMzgpLgoKCkF1dGhvcnMnIEFkZHJlc3NlcwoKICAgS2xhdXMgSGFydGtlCiAgIFVuaXZl cnNpdGFldCBCcmVtZW4gVFpJCiAgIFBvc3RmYWNoIDMzMDQ0MAogICBCcmVtZW4gIEQtMjgzNTkK ICAgR2VybWFueQoKICAgUGhvbmU6ICs0OS00MjEtMjE4LTYzOTA1CiAgIEZheDogICArNDktNDIx LTIxOC03MDAwCiAgIEVtYWlsOiBoYXJ0a2VAdHppLm9yZwoKCiAgIFphY2ggU2hlbGJ5CiAgIFNl bnNpbm9kZQogICBLaWRla3VqYSAyCiAgIFZ1b2thdHRpICA4ODYwMAogICBGaW5sYW5kCgogICBQ aG9uZTogKzM1ODQwNzc5NjI5NwogICBFbWFpbDogemFjaEBzZW5zaW5vZGUuY29tCgoKCgoKCgoK CgoKCgoKCkhhcnRrZSAmIFNoZWxieSAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMTYsIDIwMTEg ICAgICAgICAgICAgIFtQYWdlIDE5XQoMCg== ------_=_NextPart_001_01CC097F.2388F67A-- From alexey.melnikov@isode.com Tue May 3 03:51:39 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D61AE07B5 for ; Tue, 3 May 2011 03:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.399 X-Spam-Level: X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZTI7zO4LJF7I for ; Tue, 3 May 2011 03:51:38 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 4EDD9E069E for ; Tue, 3 May 2011 03:51:38 -0700 (PDT) Received: from [188.28.73.38] (188.28.73.38.threembb.co.uk [188.28.73.38]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 3 May 2011 11:51:36 +0100 Message-ID: <4DBFDE26.6090107@isode.com> Date: Tue, 03 May 2011 11:51:18 +0100 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: <8B55B68A-3EA2-45F6-8624-6617333C656D@sensinode.com> <6F58467D-2355-45FA-A32A-880302EEF22C@tzi.org> <4DBFC3CA.5040505@isode.com> <1A41D24B-92E6-49FB-9BFB-7BACD01E3391@tzi.org> <4DBFCD09.90707@isode.com> <6759ECAB-99C1-463D-8BC4-0B10AB2BE5AD@tzi.org> In-Reply-To: <6759ECAB-99C1-463D-8BC4-0B10AB2BE5AD@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] ABNF help X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 03 May 2011 10:51:39 -0000 Carsten Bormann wrote: >>>But seriously, for a producer of this format, the size of the resources will fit nicely with its integer processing capabilities. For a consumer, the only thing that may be needed is one representation for "big", i.e. of a size that is so large that it is no longer relevant for this kind of implementation. So not having a limit does not hurt. >>> >>> >>I don't want a naive consumer to dump core because the producer decided to generate a 128bit size. And guess what, some malicious producers would do this on purpose to deny service. >> >> > >OK, so let's add something like: > > Note that there is no defined upper limit to the value of the sz attribute. > Implementations MUST be prepared to accept large values. > Implementation note: One implementation strategy is to convert any value larger than a reasonable size limit for this implementation to a special value "Big", which in further processing would indicate that a size value was given that was so big that it cannot be processed by this implementation. > > I can live with this. Can the document can also contain an example with a big value, because implementors frequently implement from examples... >>In IMAP I know that all sizes are limited to 32bit. If you want more, you need to defined & negotiate an extension. >> >> >But in IMAP you actually need to process the values, as this is a protocol that allows you to operate on the objects. Link-format is descriptive only (and there is no IMAP connection to negotiate anything on, either). > > >>>Not hard-wiring one limit is also the right thing to do, as it prevents Content-Size-style disasters when that one limit turns out to be overtaken by events. >>> >>If you choose your size carefully, I doubt that this will happen in our lifetime. >> >> >1208925819614629174706175 (for an 80-bit integer)? > Good example :-). >I'm not sure that helps anyone... > > From zach@sensinode.com Tue May 3 04:06:13 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E5ECE07AB for ; Tue, 3 May 2011 04:06:13 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5bNi4hCuo8g for ; Tue, 3 May 2011 04:06:12 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id A6FE6E0708 for ; Tue, 3 May 2011 04:06:11 -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 p43B67qQ002730 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 May 2011 14:06:08 +0300 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-179--303944579; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: <4DBFDE26.6090107@isode.com> Date: Tue, 3 May 2011 14:06:09 +0300 Message-Id: References: <8B55B68A-3EA2-45F6-8624-6617333C656D@sensinode.com> <6F58467D-2355-45FA-A32A-880302EEF22C@tzi.org> <4DBFC3CA.5040505@isode.com> <1A41D24B-92E6-49FB-9BFB-7BACD01E3391@tzi.org> <4DBFCD09.90707@isode.com> <6759ECAB-99C1-463D-8BC4-0B10AB2BE5AD@tzi.org> <4DBFDE26.6090107@isode.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.1084) Cc: core WG Subject: Re: [core] ABNF help X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 03 May 2011 11:06:13 -0000 --Apple-Mail-179--303944579 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 3, 2011, at 1:51 PM, Alexey Melnikov wrote: >> OK, so let's add something like: >>=20 >> Note that there is no defined upper limit to the value of the sz = attribute. >> Implementations MUST be prepared to accept large values. = Implementation note: One implementation strategy is to convert any value = larger than a reasonable size limit for this implementation to a special = value "Big", which in further processing would indicate that a size = value was given that was so big that it cannot be processed by this = implementation. >>=20 > I can live with this. >=20 > Can the document can also contain an example with a big value, because = implementors frequently implement from examples... Done. 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-179--303944579 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 ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDUwMzExMDYx MFowIwYJKoZIhvcNAQkEMRYEFF7UApUHXRLVJb5y+ibw8QbdiBqrMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBABPVazwEN9Ez4y68ko1kNHzPDlmr0s+PNZusfJNZfgR1ec63IsgB/voD y+/wn2lBhA+oRww+IhEoSPzvNRvkzQNeji1PUCbcJjhxuQy5+qTju3JZ1I72G9oSlghFzCgrNvwZ NX8LK3fdhF3MWCNpFNAuHuJUuBp8IrQkbfeNeBdKlYisBZc6kJMW1cVRmMP8qdnEiN5+r3V03Q0Y +ZgHGJSnJSAYosrVZwzyIGVvW9k3XtXmLOUoLLM59CueOw7g0kZB/tFUW6deGRHVj2KLfROJ8HDZ zT125ksTwNWbvd+3r/GYA+sIFAbuAwgNfmXVK/b33hPPrQwatKdqTMS9FBAAAAAAAAA= --Apple-Mail-179--303944579-- From alexey.melnikov@isode.com Tue May 3 04:08:10 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85FC4E07BE for ; Tue, 3 May 2011 04:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6OndyL1++cz for ; Tue, 3 May 2011 04:08:09 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 57680E073F for ; Tue, 3 May 2011 04:08:09 -0700 (PDT) Received: from [188.28.73.38] (188.28.73.38.threembb.co.uk [188.28.73.38]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 3 May 2011 12:08:06 +0100 Message-ID: <4DBFE205.5030608@isode.com> Date: Tue, 03 May 2011 12:07:49 +0100 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: <4DA562B6.8000508@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@ietf.org Subject: Re: [core] Review of draft-ietf-core-link-format-03.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 11:08:10 -0000 Zach Shelby wrote: >Thanks for your review Alexey. I have made these changes, a few answers to your questions below as well. > > Hi Zach, I am mostly happy with your replies, so I deleted your relies where we are in agreement. A few remaining issues below: >On Apr 13, 2011, at 11:45 AM, Alexey Melnikov wrote: > > >>In Section 2: >> >> The CoRE link format uses the ABNF description and associated rules >> in Section 5 of [RFC5988]. In addition, the pchar rule is taken from >> [RFC3986]. The "Link:" text is omitted as that is part of the HTTP >> Link Header. As in [RFC5988], multiple link descriptions are >> separated by commas. Note that commas can also occur in quoted >> strings and URIs but do not end a description. >> >>Does this mean that some comma escaping mechanism is needed? >> > >Not as far as I know, at least RFC5988 doesn't use comma escaping and we haven't changed the format. > Ok, commas inside <> (i.e. inside URIs) or inside quoted strings are Ok. But I am still not clear what the last quoted sentence is trying to say? It doesn't look like you allow for multiple URIs to be listed on a single line, so what has comma to do with anything? Which brings me to a related issue: there is no ABNF of the format defined in the document. There are only ABNFs for pieces of the Link format. [...] >>In Section 4.1: >> >> If the decoded query-pattern does not end with "*", a link value >> matches the query only if the value of the attribute or URI-reference >> denoted by the resource-param is bytewise identical to the query- >> pattern. If the decoded query-pattern ends with "*", it is >> sufficient that the remainder of the query-pattern be a prefix of the >> value denoted by the resource-param. >> >>Does * match an empty string? >> > >Yes, I would assume so if that attribute present with an empty string. > > I suggest stating that explicitly. >> File extension(s): >> >>Any reason not to define an extension here? >> >> > >I propose adding the extension *.clf (Core Link Format). An alternative would be *.wlk (Web LinKing). Both seem to be free. > I think .wlk is a bit better, because .clf is already in use (according to Google search). From alexey.melnikov@isode.com Tue May 3 04:10:30 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE21E07EB for ; Tue, 3 May 2011 04:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.479 X-Spam-Level: X-Spam-Status: No, score=-102.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id isnJt+BMIJpO for ; Tue, 3 May 2011 04:10:29 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF2BE07AB for ; Tue, 3 May 2011 04:10:29 -0700 (PDT) Received: from [188.28.73.38] (188.28.73.38.threembb.co.uk [188.28.73.38]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 3 May 2011 12:10:27 +0100 Message-ID: <4DBFE294.3040803@isode.com> Date: Tue, 03 May 2011 12:10:12 +0100 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: <4DA562B6.8000508@isode.com> <4DBFE205.5030608@isode.com> In-Reply-To: <4DBFE205.5030608@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: core@ietf.org Subject: Re: [core] Review of draft-ietf-core-link-format-03.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 11:10:30 -0000 Alexey Melnikov wrote: > Zach Shelby wrote: > >> On Apr 13, 2011, at 11:45 AM, Alexey Melnikov wrote: > >>> File extension(s): >>> >>> Any reason not to define an extension here? >> >> I propose adding the extension *.clf (Core Link Format). An >> alternative would be *.wlk (Web LinKing). Both seem to be free. > > I think .wlk is a bit better, because .clf is already in use > (according to Google search). Sorry, both are used according to . But I don't think reuse is a big deal. From zach@sensinode.com Tue May 3 04:25:07 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3EE5E07FB for ; Tue, 3 May 2011 04:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.358 X-Spam-Level: X-Spam-Status: No, score=-3.358 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZzhLuuHMJUN7 for ; Tue, 3 May 2011 04:25:07 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 7901EE07F9 for ; Tue, 3 May 2011 04:25:05 -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 p43BP1GX020426 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 May 2011 14:25:02 +0300 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-180--302810331; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: <4DBFE205.5030608@isode.com> Date: Tue, 3 May 2011 14:25:03 +0300 Message-Id: <0D8AA6B5-E43F-4836-98FC-EF32EFC4C4C1@sensinode.com> References: <4DA562B6.8000508@isode.com> <4DBFE205.5030608@isode.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.1084) Cc: core@ietf.org Subject: Re: [core] Review of draft-ietf-core-link-format-03.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 11:25:07 -0000 --Apple-Mail-180--302810331 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 3, 2011, at 2:07 PM, Alexey Melnikov wrote: > Zach Shelby wrote: >=20 >> Thanks for your review Alexey. I have made these changes, a few = answers to your questions below as well. >>=20 > Hi Zach, > I am mostly happy with your replies, so I deleted your relies where we = are in agreement. A few remaining issues below: >=20 >> On Apr 13, 2011, at 11:45 AM, Alexey Melnikov wrote: >>=20 >>> In Section 2: >>>=20 >>> The CoRE link format uses the ABNF description and associated rules >>> in Section 5 of [RFC5988]. In addition, the pchar rule is taken = from >>> [RFC3986]. The "Link:" text is omitted as that is part of the HTTP >>> Link Header. As in [RFC5988], multiple link descriptions are >>> separated by commas. Note that commas can also occur in quoted >>> strings and URIs but do not end a description. >>>=20 >>> Does this mean that some comma escaping mechanism is needed? >>>=20 >>=20 >> Not as far as I know, at least RFC5988 doesn't use comma escaping and = we haven't changed the format. >>=20 > Ok, commas inside <> (i.e. inside URIs) or inside quoted strings are = Ok. But I am still not clear what the last quoted sentence is trying to = say? > It doesn't look like you allow for multiple URIs to be listed on a = single line, so what has comma to do with anything? Don't be fooled by the example. In the RFC5988 format linefeed is not = used for delimiting multiple entries, but instead a comma.=20 "5. Examples A few examples of typical link descriptions in this format follows. Multiple resource descriptions in a representation are separated by commas. Linefeeds never occur in the actual format, but are shown in the example for readability." >=20 > Which brings me to a related issue: there is no ABNF of the format = defined in the document. There are only ABNFs for pieces of the Link = format. RFC5988 describes the ABNF for the format. We are simply reusing that. = Originally we did repeat that ABNF in the CoRE Link Format, but were = encouraged by Martin and Mark to take that out. I agree with them that = repeating it is not worthwhile.=20 > [...] >=20 >>> In Section 4.1: >>>=20 >>> If the decoded query-pattern does not end with "*", a link value >>> matches the query only if the value of the attribute or = URI-reference >>> denoted by the resource-param is bytewise identical to the query- >>> pattern. If the decoded query-pattern ends with "*", it is >>> sufficient that the remainder of the query-pattern be a prefix of = the >>> value denoted by the resource-param. >>>=20 >>> Does * match an empty string? =20 >>=20 >> Yes, I would assume so if that attribute present with an empty = string. =20 > I suggest stating that explicitly. Done. >=20 >>> File extension(s): >>>=20 >>> Any reason not to define an extension here? >>> =20 >>=20 >> I propose adding the extension *.clf (Core Link Format). An = alternative would be *.wlk (Web LinKing). Both seem to be free. >>=20 > I think .wlk is a bit better, because .clf is already in use = (according to Google search). >=20 .wlnk is free, will go for that.=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-180--302810331 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 ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDUwMzExMjUw NFowIwYJKoZIhvcNAQkEMRYEFLsaq87WgIq70Ee/Qcg5AZc24pOwMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAFbldfBzxXnnTjugfYQHZ4BxgD8Qk3I5Lh+4fpXMpHl7yRQfL5mhjG9e PxJFjypsBkX7X1+9hQvVK58G/YJyUfnsSTJ+4fURoRlz38Dv68dFmeY+N3aVyWYMh2rTIVlONGgj /2EN7uTGJZUNX9Z92snyOAc+PfvlRuR39/tiWKhr8O3cw9PZ7+blN8oZxfAEPL5ImBB+21c3HuDA 2LSQMGT+HQQzSWQt+4IJ4uNVWYM3lqbl+Q9VyqXNcMA89u7R7YzU7henJUWDwxQYAsDFfKlt3ORh EYVfN8ZZ1kRIisO1bUdxChvL1uH4CL5DzCi6yXIgOwFu/Qdq76ZkYhqfZ7gAAAAAAAA= --Apple-Mail-180--302810331-- From alexey.melnikov@isode.com Tue May 3 04:31:43 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4158E0760 for ; Tue, 3 May 2011 04:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.513 X-Spam-Level: X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OIjooXI0d7RE for ; Tue, 3 May 2011 04:31:42 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 0E98AE073D for ; Tue, 3 May 2011 04:31:41 -0700 (PDT) Received: from [188.28.73.38] (188.28.73.38.threembb.co.uk [188.28.73.38]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 3 May 2011 12:31:40 +0100 Message-ID: <4DBFE788.4030909@isode.com> Date: Tue, 03 May 2011 12:31:20 +0100 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: <4DA562B6.8000508@isode.com> <4DBFE205.5030608@isode.com> <0D8AA6B5-E43F-4836-98FC-EF32EFC4C4C1@sensinode.com> In-Reply-To: <0D8AA6B5-E43F-4836-98FC-EF32EFC4C4C1@sensinode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: core@ietf.org Subject: Re: [core] Review of draft-ietf-core-link-format-03.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 11:31:43 -0000 Zach Shelby wrote: >On May 3, 2011, at 2:07 PM, Alexey Melnikov wrote: > > > >>Zach Shelby wrote: >> >> >> >>>Thanks for your review Alexey. I have made these changes, a few answers to your questions below as well. >>> >>> >>> >>Hi Zach, >>I am mostly happy with your replies, so I deleted your relies where we are in agreement. A few remaining issues below: >> >> >> >>>On Apr 13, 2011, at 11:45 AM, Alexey Melnikov wrote: >>> >>> >>> >>>>In Section 2: >>>> >>>>The CoRE link format uses the ABNF description and associated rules >>>>in Section 5 of [RFC5988]. In addition, the pchar rule is taken from >>>>[RFC3986]. The "Link:" text is omitted as that is part of the HTTP >>>>Link Header. As in [RFC5988], multiple link descriptions are >>>>separated by commas. Note that commas can also occur in quoted >>>>strings and URIs but do not end a description. >>>> >>>>Does this mean that some comma escaping mechanism is needed? >>>> >>>> >>>Not as far as I know, at least RFC5988 doesn't use comma escaping and we haven't changed the format. >>> >>> >>Ok, commas inside <> (i.e. inside URIs) or inside quoted strings are Ok. But I am still not clear what the last quoted sentence is trying to say? >>It doesn't look like you allow for multiple URIs to be listed on a single line, so what has comma to do with anything? >> >> >Don't be fooled by the example. In the RFC5988 format linefeed is not used for delimiting multiple entries, but instead a comma. > >"5. Examples > > A few examples of typical link descriptions in this format follows. > Multiple resource descriptions in a representation are separated by > commas. Linefeeds never occur in the actual format, but are shown in > the example for readability." > > Ok, I must have forgotten about this. It would be nice to see an example with no line folding though. >>Which brings me to a related issue: there is no ABNF of the format defined in the document. There are only ABNFs for pieces of the Link format. >> >> > >RFC5988 describes the ABNF for the format. We are simply reusing that. Originally we did repeat that ABNF in the CoRE Link Format, but were encouraged by Martin and Mark to take that out. I agree with them that repeating it is not worthwhile. > > I suggest you actually point to the specific ABNF production in RFC 5988. That way you wouldn't have to repeat ABNF from it. >>>>File extension(s): >>>> >>>>Any reason not to define an extension here? >>>> >>>> >>>I propose adding the extension *.clf (Core Link Format). An alternative would be *.wlk (Web LinKing). Both seem to be free. >>> >>> >>I think .wlk is a bit better, because .clf is already in use (according to Google search). >> >> > >.wlnk is free, will go for that. > > Ok. From zach@sensinode.com Tue May 3 04:43:17 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5491DE0724 for ; Tue, 3 May 2011 04:43:17 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lnt2UAukCTtX for ; Tue, 3 May 2011 04:43:16 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 35BB4E06A4 for ; Tue, 3 May 2011 04:43:15 -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 p43BhBcw004089 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 May 2011 14:43:11 +0300 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-182--301720775; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: <4DBFE788.4030909@isode.com> Date: Tue, 3 May 2011 14:43:13 +0300 Message-Id: <36CC0B2D-404C-49AC-88B3-92D1B4A6319B@sensinode.com> References: <4DA562B6.8000508@isode.com> <4DBFE205.5030608@isode.com> <0D8AA6B5-E43F-4836-98FC-EF32EFC4C4C1@sensinode.com> <4DBFE788.4030909@isode.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.1084) Cc: core@ietf.org Subject: Re: [core] Review of draft-ietf-core-link-format-03.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 11:43:17 -0000 --Apple-Mail-182--301720775 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 3, 2011, at 2:31 PM, Alexey Melnikov wrote: >>>>=20 >>> Ok, commas inside <> (i.e. inside URIs) or inside quoted strings are = Ok. But I am still not clear what the last quoted sentence is trying to = say? >>> It doesn't look like you allow for multiple URIs to be listed on a = single line, so what has comma to do with anything? >>> =20 >> Don't be fooled by the example. In the RFC5988 format linefeed is not = used for delimiting multiple entries, but instead a comma.=20 >> "5. Examples >>=20 >> A few examples of typical link descriptions in this format follows. >> Multiple resource descriptions in a representation are separated by >> commas. Linefeeds never occur in the actual format, but are shown = in >> the example for readability." >>=20 > Ok, I must have forgotten about this. >=20 > It would be nice to see an example with no line folding though. Sure, good idea. >=20 >>> Which brings me to a related issue: there is no ABNF of the format = defined in the document. There are only ABNFs for pieces of the Link = format. >>> =20 >>=20 >> RFC5988 describes the ABNF for the format. We are simply reusing = that. Originally we did repeat that ABNF in the CoRE Link Format, but = were encouraged by Martin and Mark to take that out. I agree with them = that repeating it is not worthwhile. =20 > I suggest you actually point to the specific ABNF production in RFC = 5988. That way you wouldn't have to repeat ABNF from it. The draft currently states "The CoRE link format uses the ABNF description and associated rules in Section 5 of [RFC5988]. In addition, the pchar rule is taken from [RFC3986]. " Is there a way to also indicate this in the ABNF of the new attributes. = Some kind of "Import everything from Section 5 of RFC5988"? I can = mention that in the first sentence of Section 3, but it would be nice to = have that explicit in the ABNF. 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-182--301720775 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 ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDUwMzExNDMx NFowIwYJKoZIhvcNAQkEMRYEFLq3A9QdQGUDgm5a5yIbFiScXkgFMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAD3C6Zjr5Rm7qEeC/GOUDHxwNRDXSEDs9nf8Vu0QNq/pjzyCuz+YlSO6 5I9zDGSJ1lRKXvXmReaF19vE8Gvm4jc+QN8A4SMz6SaSvRsldgVOLwQZQqRJUH6Uaa0MuN62aYax kzmqBapLckGrQwMWariGFRa7sKATwU0AiJIl1WPBSV5hHqy934EGHHn0/+Jfrpxi3TkaIlZOMLte rXET47HiG7bKMpDhc8dlFAVuFP3W6/yVCt51gNdPp9PVOCFrDmM0GDRd+py+xq/GrCN5DupyUtOs hpep/ntEQq8LIvc8MF7GgCaZqOWhG2cwESYApE00SlAa2Xj1ziI+AxGkSdwAAAAAAAA= --Apple-Mail-182--301720775-- From trac+core@trac.tools.ietf.org Tue May 3 05:07:15 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F00DE073D for ; Tue, 3 May 2011 05:07: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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ld8zgaKnKTt8 for ; Tue, 3 May 2011 05:07:15 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 0E1D6E06A4 for ; Tue, 3 May 2011 05:07:15 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QHENl-00015g-VR; Tue, 03 May 2011 05:07:13 -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 X-Trac-Project: core Date: Tue, 03 May 2011 12:07:13 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/133#comment:1 Message-ID: <062.5d8695b62003f08fa7892d21e39a70d5@trac.tools.ietf.org> References: <053.2c1b100dfa74bde1c8fd4c59ac50b3d3@trac.tools.ietf.org> X-Trac-Ticket-ID: 133 In-Reply-To: <053.2c1b100dfa74bde1c8fd4c59ac50b3d3@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hartke@tzi.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@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] #133: RST in reply to NON X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 12:07:15 -0000 #133: RST in reply to NON Changes (by hartke@…): * status: new => closed * resolution: => fixed Comment: Fixed in coap-06. (Thanks, Angelo!) -- ----------------------------------+----------------------------------------- Reporter: hartke@… | Owner: hartke@… Type: protocol enhancement | Status: closed Priority: minor | Milestone: Component: coap | Version: Severity: Active WG Document | Resolution: fixed Keywords: | ----------------------------------+----------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Tue May 3 05:18:24 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 426C7E0804 for ; Tue, 3 May 2011 05:18: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=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QOsEyfnUlXIQ for ; Tue, 3 May 2011 05:18:23 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id D8741E073D for ; Tue, 3 May 2011 05:18:23 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QHEYZ-00047A-Of; Tue, 03 May 2011 05:18:23 -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 X-Trac-Project: core Date: Tue, 03 May 2011 12:18:23 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/134#comment:1 Message-ID: <062.1146ea7484bf56461561da28dd8d4659@trac.tools.ietf.org> References: <053.682597724d90a0867039a7a256f448a6@trac.tools.ietf.org> X-Trac-Ticket-ID: 134 In-Reply-To: <053.682597724d90a0867039a7a256f448a6@trac.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+core@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] #134: Cache Invalidation only happens upon successful responses X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 12:18:24 -0000 #134: Cache Invalidation only happens upon successful responses Changes (by hartke@…): * status: new => closed * resolution: => fixed Comment: Fixed in coap-06 -- --------------------------------+------------------------------------------- Reporter: hartke@… | Owner: hartke@… Type: protocol defect | Status: closed Priority: minor | Milestone: Component: coap | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Tue May 3 05:34:39 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD23FE0812 for ; Tue, 3 May 2011 05:34:39 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mjkedyn9gxs7 for ; Tue, 3 May 2011 05:34:39 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 4AFB3E080B for ; Tue, 3 May 2011 05:34:39 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QHEoG-0007bn-OD; Tue, 03 May 2011 05:34:36 -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: Tue, 03 May 2011 12:34:36 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/141#comment:1 Message-ID: <066.25c7217e0e98c4af92e64d1627abeda8@trac.tools.ietf.org> References: <057.b32d73525fa5927244dc93723f5db76b@trac.tools.ietf.org> X-Trac-Ticket-ID: 141 In-Reply-To: <057.b32d73525fa5927244dc93723f5db76b@trac.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+core@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] #141: DTLS and resource access control X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 12:34:39 -0000 #141: DTLS and resource access control Changes (by zach@…): * status: new => closed * resolution: => wontfix Comment: After the authors examined the current Section 10 text, it was concluded that what is already there is sufficient for the protocol specification. Further implementation advice could be provided in a separate draft. -- ----------------------------------+----------------------------------------- Reporter: zach@… | Owner: cabo@… Type: protocol enhancement | Status: closed Priority: minor | Milestone: Component: coap | Version: Severity: - | Resolution: wontfix Keywords: | ----------------------------------+----------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Tue May 3 05:37:10 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72189E06D8 for ; Tue, 3 May 2011 05:37:10 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jkLsYo6TwBvU for ; Tue, 3 May 2011 05:37:10 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 02E10E0593 for ; Tue, 3 May 2011 05:37:10 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QHEqj-00063n-UD; Tue, 03 May 2011 05:37:09 -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: Tue, 03 May 2011 12:37:09 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/143#comment:1 Message-ID: <066.1f956876b2f8744c41ed3b4efca84bb6@trac.tools.ietf.org> References: <057.4ba78d626fe08468e6b5ac52b67e5b8b@trac.tools.ietf.org> X-Trac-Ticket-ID: 143 In-Reply-To: <057.4ba78d626fe08468e6b5ac52b67e5b8b@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #143: Retransmit timeout adaptation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 12:37:10 -0000 #143: Retransmit timeout adaptation Changes (by zach@…): * status: new => closed * resolution: => wontfix Comment: In our opinion it is premature to work on the kind of adaptive retransmit timeout for CoAP, and instead this should be considered in e.g. draft- eggert-core-congestion-control. However, text was added to indicate that we do expect that future specifications to enable the initial timeout to be set in other ways. -- ----------------------------------+----------------------------------------- Reporter: zach@… | Owner: zach@… Type: protocol enhancement | Status: closed Priority: minor | Milestone: Component: coap | Version: Severity: - | Resolution: wontfix Keywords: | ----------------------------------+----------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Tue May 3 08:08:59 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AAB8E0842 for ; Tue, 3 May 2011 08:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L1Ap1Gh43k2x for ; Tue, 3 May 2011 08:08:59 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 10397E083E for ; Tue, 3 May 2011 08:08:59 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QHHDe-0008Cz-VR; Tue, 03 May 2011 08:08:58 -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: Tue, 03 May 2011 15:08:58 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/130#comment:2 Message-ID: <067.bf13c3b3e40789673ef1d5a494f420c8@trac.tools.ietf.org> References: <058.fe9fab1a8b279081bb03524d790d9604@trac.tools.ietf.org> X-Trac-Ticket-ID: 130 In-Reply-To: <058.fe9fab1a8b279081bb03524d790d9604@trac.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+core@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] #130: [Block] 4.08 Response Code X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 15:08:59 -0000 #130: [Block] 4.08 Response Code Changes (by cabo@…): * status: new => closed * resolution: => fixed Comment: Fixed in [307]: Add explanatory text to close #130. -- ---------------------------------+------------------------------------------ Reporter: likepeng@… | Owner: cabo@… Type: editorial | Status: closed Priority: minor | Milestone: ietf80 Component: block | Version: Severity: Active WG Document | Resolution: fixed Keywords: | ---------------------------------+------------------------------------------ Ticket URL: core From cabo@tzi.org Tue May 3 11:21:04 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ECE2E06D6 for ; Tue, 3 May 2011 11:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.149 X-Spam-Level: X-Spam-Status: No, score=-106.149 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2+sQKKTaeBBA for ; Tue, 3 May 2011 11:21:03 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 02E73E06B1 for ; Tue, 3 May 2011 11:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id p43IKpBE021287; Tue, 3 May 2011 20:20:51 +0200 (CEST) Received: from [192.168.217.112] (p5B3E613E.dip.t-dialin.net [91.62.97.62]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 7D822A99; Tue, 3 May 2011 20:20:50 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <55877B3AFB359744BA0F2140E36F52B50841DBA2@MBX20.d.ethz.ch> Date: Tue, 3 May 2011 20:20:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7F64A4BC-8AAC-41CE-9449-F6F4DEE3DF1E@tzi.org> References: <55877B3AFB359744BA0F2140E36F52B50841DBA2@MBX20.d.ethz.ch> To: "Kovatsch Matthias" X-Mailer: Apple Mail (2.1084) Cc: "core@ietf.org" Subject: Re: [core] CoAP block sizes: power of two might not be optimal X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 03 May 2011 18:21:04 -0000 Hi Matthias, thanks for the feedback (and sorry for the delayed response). Indeed, Block currently is strongly biased towards simplicity, as = opposed to ultimate efficiency. The assumption is that most transfers will be simple, and block-wise is = more the exception for special things such as discovery and firmware = updates. So, on a 6LoWPAN device, 64 will indeed be close enough for most = applications. Gruesse, Carsten (Oh, and:) > While 64 appears to be a good choice for 15.4 frames, the next larger = size 128 might already be too large for devices with very constrained = memory. =46rom 256 onwards, it becomes demanding for the IP = fragmentation buffer of every hop. JFYI, the size of the L3 packet is not very relevant for the adaptation = layer fragmentation buffers (did you mean these?) of 6LoWPAN routers, as = is documented in the LWIG Guidance Internet-Draft soon to be out (or in = the 6LoWPAN book). Excerpt: 3.1.1. Fragmentation in a 6LoWPAN Route-Over Configuration [...] 6LoWPAN [RFC4944] is an adaptation layer that maps IPv6 with its minimum MTU of 1280 bytes to IEEE 802.15.4, which has a physical layer MTU of only 127 bytes (some of which are taken by MAC layer and adaptation layer headers). Therefore, the adaptation layer provides a fragmentation and reassembly scheme that can fragment a single IPv6 packet of up to 1280 bytes into multiple adaptation layer fragments of up to 127 bytes each (including MAC and adaptation layer overhead). In a route-over configuration, implementing this adaptation layer fragmentation scheme straightforwardly means that reassembly and then fragmentation are performed at each forwarding hop. As fragments from several packets may be arriving interleaved with each other, this approach requires buffer space for multiple MTU-size IPv6 packets. In a mesh-under configuration, adaptation layer fragments can be forwarded independently of each other. It would be preferable if something similar were possible for route-over. Complete independence in adaptation layer fragment forwarding is not possible for route-over, however, as the layer-3 addresses needed for forwarding are in the initial bytes of the IPv6 header, which is present only in the first fragment of a larger packet. Instead of performing a full reassembly, implementations may be able to optimize this process by not keeping a full reassembly buffer, but just a runt buffer for each packet that caches just the datagram_tag field (as usual combined with the sender's link layer address, the destination's link layer address and the datagram_size field) and the IPv6 header including the relevant addresses. Initial fragments are then forwarded independently (after header decompression/compression) and create a runt reassembly buffer. Non-initial fragments (which don't require header decompression/compression in 6LoWPAN) are matched against the runt buffers by datagram_tag etc. and forwarded if an IPv6 address is available. (This simple scheme may be complicated a bit if header decompression/compression of the initial fragment causes an overflow of the physical MTU; in this case some overflow data may need to be stored in the runt buffers to be combined with further fragments or may simply be forwarded as a separate additional fragment.) If non-initial fragments arrive out of order before the initial fragment, a route-over router may want to keep the contents of the non-initial fragments until the initial fragment is available, which does need some buffer space. If that is not available, a more constrained route-over router may simply discard out-of order non- initial fragments, possibly taking note that there is no point in forwarding any more fragments with the same combination of 6LoWPAN datagram_tag field, L2 addresses and datagram_size. Runt buffers should time out like full reassembly buffers, and may either keep a map of fragments forwarded or they may simply be removed upon forwarding the final fragment, assuming that no out-of- order fragments will follow. From cabo@tzi.org Tue May 3 11:22:47 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 323F2E087C for ; Tue, 3 May 2011 11:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.174 X-Spam-Level: X-Spam-Status: No, score=-106.174 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iSXwKsxtIi3p for ; Tue, 3 May 2011 11:22:46 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC9FE06B1 for ; Tue, 3 May 2011 11:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id p43IMclJ021665; Tue, 3 May 2011 20:22:38 +0200 (CEST) Received: from [192.168.217.112] (p5B3E613E.dip.t-dialin.net [91.62.97.62]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 8C234A9B; Tue, 3 May 2011 20:22:38 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Tue, 3 May 2011 20:22:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <05CDE379-CF49-4905-A88F-00D64ACB5D63@tzi.org> References: <55877B3AFB359744BA0F2140E36F52B50841DBA2@MBX20.d.ethz.ch> To: "Charles Palmer" X-Mailer: Apple Mail (2.1084) Cc: core@ietf.org Subject: Re: [core] CoAP block sizes: power of two might not be optimal X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 03 May 2011 18:22:47 -0000 On Apr 29, 2011, at 18:33, Charles Palmer wrote: > In particular, would there ever be a need for a 3-byte Block Option, = with a 20-bit block number field? Two bytes with a 12-bit NUM field = supports 64k byte resource representations even with the smallest = 16-byte block size. 64KiB may not be enough for one application that is often mentioned: = Firmware upgrades. So we put in the 3-byte version to be on the safe side. Of course, if = all your resources are smaller, you don't have to implement it! Gruesse, Carsten From trac+core@trac.tools.ietf.org Tue May 3 11:36:20 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0929CE07B7 for ; Tue, 3 May 2011 11:36:20 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8IoZfAOUGg8l for ; Tue, 3 May 2011 11:36:19 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id AACCFE06A3 for ; Tue, 3 May 2011 11:36:19 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QHKSE-0003yy-Hf; Tue, 03 May 2011 11:36:14 -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: Tue, 03 May 2011 18:36:14 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/137#comment:1 Message-ID: <066.9485e0de13f659680e2491824b0da83c@trac.tools.ietf.org> References: <057.31eabd9f67f0e13110575395fd280e01@trac.tools.ietf.org> X-Trac-Ticket-ID: 137 In-Reply-To: <057.31eabd9f67f0e13110575395fd280e01@trac.tools.ietf.org> 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+core@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] #137: HTTP mapping section improvements X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 18:36:20 -0000 #137: HTTP mapping section improvements Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: Done in coap-06. -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: hartke@… Type: task | Status: closed Priority: minor | Milestone: Component: coap | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Tue May 3 11:43:53 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 088FCE0879 for ; Tue, 3 May 2011 11:43:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=-0.076, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVC6+gRR9J3u for ; Tue, 3 May 2011 11:43:52 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 9269FE0883 for ; Tue, 3 May 2011 11:43:52 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QHKZc-0002rj-FG; Tue, 03 May 2011 11:43:52 -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, hartke@tzi.org X-Trac-Project: core Date: Tue, 03 May 2011 18:43:51 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/136#comment:3 Message-ID: <066.cca756550c3314c9c36f476f1948759e@trac.tools.ietf.org> References: <057.65b7d09ad2ff8ea19af2be8c7d36e358@trac.tools.ietf.org> X-Trac-Ticket-ID: 136 In-Reply-To: <057.65b7d09ad2ff8ea19af2be8c7d36e358@trac.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+core@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] #136: UTF-8 matching clarification X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 18:43:53 -0000 #136: UTF-8 matching clarification Changes (by hartke@…): * status: assigned => closed * resolution: => fixed Comment: Done in coap-06. -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: cabo@… Type: protocol defect | Status: closed Priority: minor | Milestone: Component: coap | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Ticket URL: core From charles.palmer@onzo.com Tue May 3 12:27:42 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 790B4E066E for ; Tue, 3 May 2011 12:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6RQSDZncCuE for ; Tue, 3 May 2011 12:27:41 -0700 (PDT) Received: from service38.mimecast.com (service38.mimecast.com [195.130.217.47]) by ietfa.amsl.com (Postfix) with SMTP id 2E829E06AA for ; Tue, 3 May 2011 12:27:39 -0700 (PDT) Received: from onzosbs2k3.ONZO.local (217.138.5.2 [217.138.5.2]) by service38.mimecast.com; Tue, 03 May 2011 20:27:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 3 May 2011 20:27:36 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] CoAP block sizes: power of two might not be optimal Thread-Index: AcwJvx3bUFq92kR+RP2suJ26Yu80kgABrirQ References: <55877B3AFB359744BA0F2140E36F52B50841DBA2@MBX20.d.ethz.ch> <05CDE379-CF49-4905-A88F-00D64ACB5D63@tzi.org> From: "Charles Palmer" To: "Carsten Bormann" X-MC-Unique: 111050320273801102 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC09C8.2862A542" Cc: core@ietf.org Subject: Re: [core] CoAP block sizes: power of two might not be optimal X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 03 May 2011 19:27:42 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC09C8.2862A542 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Hi Carsten OK - I've re-read the documents. A 3-byte Block Option does not violate the= constraint "A CoAP message...MUST fit within a single IP datagram" because= we are transferring large "resource representations" rather than large "me= ssages". (Each block has a different Message ID, though the same Token...) = With respect to your comment on firmware upgrades, I guess the Block Option= is almost providing TFTP.=20 Hmmm... Google led me on to the "Sorcerer's Apprentice Syndrome" - which I = trust is a problem we don't have ;-) Too late for me to figure this out.... http://en.wikipedia.org/wiki/Sorcerer%27s_Apprentice_Syndrome Regards - Charles -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org] Sent: Tue 03/05/2011 19:22 To: Charles Palmer Cc: Kovatsch Matthias; core@ietf.org Subject: Re: [core] CoAP block sizes: power of two might not be optimal =20 On Apr 29, 2011, at 18:33, Charles Palmer wrote: > In particular, would there ever be a need for a 3-byte Block Option, with= a 20-bit block number field? Two bytes with a 12-bit NUM field supports 64= k byte resource representations even with the smallest 16-byte block size. 64KiB may not be enough for one application that is often mentioned: Firmwa= re upgrades. So we put in the 3-byte version to be on the safe side. Of course, if all = your resources are smaller, you don't have to implement it! Gruesse, Carsten -------------------------------- Onzo is a limited company number 06097997 registered in England & Wales. Th= e =20 registered office is 6 Great Newport Street, London, WC2H 7JB, United Kingd= om. This email message may contain confidential and/or privileged information, = and is intended solely for the addressee(s). If you have received this email in= =20 error, please notify Onzo immediately. Unauthorised copying, disclosure or= =20 distribution of the material in this email is forbidden. -------------------------------- ------_=_NextPart_001_01CC09C8.2862A542 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable RE: [core] CoAP block sizes: power of two might not be optimal</TITL= E> </HEAD> <BODY> =20 =20 <!-- Converted from text/plain format --> <P><FONT SIZE=3D2>Hi Carsten<BR> <BR> OK - I've re-read the documents. A 3-byte Block Option does not violate the= constraint "A CoAP message...MUST fit within a single IP datagram&quo= t; because we are transferring large "resource representations" r= ather than large "messages". (Each block has a different Message = ID, though the same Token...) With respect to your comment on firmware upgr= ades, I guess the Block Option is almost providing TFTP.<BR> <BR> Hmmm... Google led me on to the "Sorcerer's Apprentice Syndrome" = - which I trust is a problem we don't have ;-) Too late for me to figure th= is out....<BR> <A HREF=3D"http://en.wikipedia.org/wiki/Sorcerer%27s_Apprentice_Syndrome">h= ttp://en.wikipedia.org/wiki/Sorcerer%27s_Apprentice_Syndrome</A><BR> <BR> Regards - Charles<BR> <BR> <BR> -----Original Message-----<BR> From: Carsten Bormann [<A HREF=3D"mailto:cabo@tzi.org">mailto:cabo@tzi.org<= /A>]<BR> Sent: Tue 03/05/2011 19:22<BR> To: Charles Palmer<BR> Cc: Kovatsch  Matthias; core@ietf.org<BR> Subject: Re: [core] CoAP block sizes: power of two might not be optimal<BR> <BR> On Apr 29, 2011, at 18:33, Charles Palmer wrote:<BR> <BR> > In particular, would there ever be a need for a 3-byte Block Option, w= ith a 20-bit block number field? Two bytes with a 12-bit NUM field supports= 64k byte resource representations even with the smallest 16-byte block siz= e.<BR> <BR> 64KiB may not be enough for one application that is often mentioned: Firmwa= re upgrades.<BR> So we put in the 3-byte version to be on the safe side.  Of course, if= all your resources are smaller, you don't have to implement it!<BR> <BR> Gruesse, Carsten<BR> <BR> <BR> <BR> </FONT> </P> <BR> <span style=3D"font-family:Arial; Font-size:8pt"> --------------------------------<br/> <a href=3D"http://www.onzo.com/">Onzo</a> is a limited company nu= mber 06097997 registered in England & Wales. The<br/> registered office is 6 Great Newport Street, London, WC2H 7JB, Un= ited Kingdom.<br/><br/> This email message may contain confidential and/or privileged inf= ormation, and<br/> is intended solely for the addressee(s). If you have received thi= s email in<br/> error, please notify <a href=3D"http://www.onzo.com/">Onzo</a> im= mediately. Unauthorised copying, disclosure or<br/> distribution of the material in this email is forbidden.<br/> --------------------------------<br/> </span> </BODY> </HTML> ------_=_NextPart_001_01CC09C8.2862A542-- From kovatsch@inf.ethz.ch Tue May 3 12:29:32 2011 Return-Path: <kovatsch@inf.ethz.ch> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 358ABE07E6 for <core@ietfa.amsl.com>; Tue, 3 May 2011 12:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, GB_AFFORDABLE=1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6eLQajmTE3vH for <core@ietfa.amsl.com>; Tue, 3 May 2011 12:29:31 -0700 (PDT) Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) by ietfa.amsl.com (Postfix) with ESMTP id 1F6B5E07E4 for <core@ietf.org>; Tue, 3 May 2011 12:29:29 -0700 (PDT) Received: from CAS20.d.ethz.ch (172.31.51.110) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.1.289.1; Tue, 3 May 2011 21:29:24 +0200 Received: from MBX20.d.ethz.ch ([fe80::81a7:b7a5:50c0:df0d]) by CAS20.d.ethz.ch ([fe80::2cd8:4907:7776:c56d%11]) with mapi id 14.01.0289.001; Tue, 3 May 2011 21:29:28 +0200 From: "Kovatsch Matthias" <kovatsch@inf.ethz.ch> To: Carsten Bormann <cabo@tzi.org> Thread-Topic: [core] CoAP block sizes: power of two might not be optimal Thread-Index: AcwGfcHsDp9xn7EdT4OrSVjR+tAo4QDME5qAAAYBFtA= Date: Tue, 3 May 2011 19:29:27 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B508420C33@MBX20.d.ethz.ch> References: <55877B3AFB359744BA0F2140E36F52B50841DBA2@MBX20.d.ethz.ch> <7F64A4BC-8AAC-41CE-9449-F6F4DEE3DF1E@tzi.org> In-Reply-To: <7F64A4BC-8AAC-41CE-9449-F6F4DEE3DF1E@tzi.org> Accept-Language: en-US, de-CH Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [193.10.67.50] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "core@ietf.org" <core@ietf.org> Subject: Re: [core] CoAP block sizes: power of two might not be optimal X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 03 May 2011 19:29:32 -0000 Hello Carsten Okay, thanks. Yes, for such an implementation only the fragmentation buffer= size at the endpoints and border router is affected. In general, I prefer = fragmentation over blockwise transfer where possible, as half of the messag= es can be saved... More flexible sizes would just allow to make the best out of the message bu= ffer a device can provide. I guess it is one of the most important tweaking= parameters to make an application fit the constrained RAM. Maybe to add another use case: I can imagine configuration updates with mul= tiple JSON-encoded parameters that won't fit the affordable buffer. These m= ight happen much more frequently than the 'famous' firmware updates. Bye Matthias > -----Urspr=FCngliche Nachricht----- > Von: Carsten Bormann [mailto:cabo@tzi.org] > Gesendet: Dienstag, 3. Mai 2011 20:21 > An: Kovatsch Matthias > Cc: core@ietf.org > Betreff: Re: [core] CoAP block sizes: power of two might not be optimal >=20 > Hi Matthias, >=20 > thanks for the feedback (and sorry for the delayed response). > Indeed, Block currently is strongly biased towards simplicity, as opposed= to > ultimate efficiency. > The assumption is that most transfers will be simple, and block-wise is m= ore > the exception for special things such as discovery and firmware updates. > So, on a 6LoWPAN device, 64 will indeed be close enough for most > applications. >=20 > Gruesse, Carsten >=20 > (Oh, and:) >=20 > > While 64 appears to be a good choice for 15.4 frames, the next larger s= ize > 128 might already be too large for devices with very constrained memory. > From 256 onwards, it becomes demanding for the IP fragmentation buffer of > every hop. >=20 > JFYI, the size of the L3 packet is not very relevant for the adaptation l= ayer > fragmentation buffers (did you mean these?) of 6LoWPAN routers, as is > documented in the LWIG Guidance Internet-Draft soon to be out (or in the > 6LoWPAN book). Excerpt: >=20 > 3.1.1. Fragmentation in a 6LoWPAN Route-Over Configuration >=20 > [...] >=20 > 6LoWPAN [RFC4944] is an adaptation layer that maps IPv6 with its > minimum MTU of 1280 bytes to IEEE 802.15.4, which has a physical > layer MTU of only 127 bytes (some of which are taken by MAC layer and > adaptation layer headers). Therefore, the adaptation layer provides > a fragmentation and reassembly scheme that can fragment a single IPv6 > packet of up to 1280 bytes into multiple adaptation layer fragments > of up to 127 bytes each (including MAC and adaptation layer > overhead). >=20 > In a route-over configuration, implementing this adaptation layer > fragmentation scheme straightforwardly means that reassembly and then > fragmentation are performed at each forwarding hop. As fragments > from several packets may be arriving interleaved with each other, > this approach requires buffer space for multiple MTU-size IPv6 > packets. >=20 > In a mesh-under configuration, adaptation layer fragments can be > forwarded independently of each other. It would be preferable if > something similar were possible for route-over. Complete > independence in adaptation layer fragment forwarding is not possible > for route-over, however, as the layer-3 addresses needed for > forwarding are in the initial bytes of the IPv6 header, which is > present only in the first fragment of a larger packet. >=20 > Instead of performing a full reassembly, implementations may be able > to optimize this process by not keeping a full reassembly buffer, but > just a runt buffer for each packet that caches just the datagram_tag > field (as usual combined with the sender's link layer address, the > destination's link layer address and the datagram_size field) and the > IPv6 header including the relevant addresses. Initial fragments are > then forwarded independently (after header decompression/compression) > and create a runt reassembly buffer. Non-initial fragments (which > don't require header decompression/compression in 6LoWPAN) are > matched against the runt buffers by datagram_tag etc. and forwarded > if an IPv6 address is available. (This simple scheme may be > complicated a bit if header decompression/compression of the initial > fragment causes an overflow of the physical MTU; in this case some > overflow data may need to be stored in the runt buffers to be > combined with further fragments or may simply be forwarded as a > separate additional fragment.) >=20 > If non-initial fragments arrive out of order before the initial > fragment, a route-over router may want to keep the contents of the > non-initial fragments until the initial fragment is available, which > does need some buffer space. If that is not available, a more > constrained route-over router may simply discard out-of order non- > initial fragments, possibly taking note that there is no point in > forwarding any more fragments with the same combination of 6LoWPAN > datagram_tag field, L2 addresses and datagram_size. >=20 > Runt buffers should time out like full reassembly buffers, and may > either keep a map of fragments forwarded or they may simply be > removed upon forwarding the final fragment, assuming that no out-of- > order fragments will follow. >=20 From cabo@tzi.org Tue May 3 12:36:40 2011 Return-Path: <cabo@tzi.org> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B799E089C for <core@ietfa.amsl.com>; Tue, 3 May 2011 12:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.189 X-Spam-Level: X-Spam-Status: No, score=-106.189 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6YKUwDfGgzY for <core@ietfa.amsl.com>; Tue, 3 May 2011 12:36:39 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 142CCE089B for <core@ietf.org>; Tue, 3 May 2011 12:36:37 -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 p43JaU9Y012347; Tue, 3 May 2011 21:36:30 +0200 (CEST) Received: from [192.168.217.112] (p5B3E613E.dip.t-dialin.net [91.62.97.62]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id F32A2ACC; Tue, 3 May 2011 21:36:29 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann <cabo@tzi.org> In-Reply-To: <E4DBD8AB11D2E54F89B23D7CD1065D8C01D4D8A8@onzosbs2k3.ONZO.local> Date: Tue, 3 May 2011 21:36:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7A7E8907-3662-41E9-836B-33E9E3C8057F@tzi.org> References: <55877B3AFB359744BA0F2140E36F52B50841DBA2@MBX20.d.ethz.ch> <E4DBD8AB11D2E54F89B23D7CD1065D8C01D4D86F@onzosbs2k3.ONZO.local> <05CDE379-CF49-4905-A88F-00D64ACB5D63@tzi.org> <E4DBD8AB11D2E54F89B23D7CD1065D8C01D4D8A8@onzosbs2k3.ONZO.local> To: "Charles Palmer" <charles.palmer@onzo.com> X-Mailer: Apple Mail (2.1084) Cc: core@ietf.org Subject: Re: [core] CoAP block sizes: power of two might not be optimal X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 03 May 2011 19:36:40 -0000 On May 3, 2011, at 21:27, Charles Palmer wrote: > I guess the Block Option is almost providing TFTP. Well, it is solving a related problem, but not using the stateful = mechanics of TFTP. > Hmmm... Google led me on to the "Sorcerer's Apprentice Syndrome" - = which I trust is a problem we don't have ;-) No, the protocol doesn't. (An improperly done implementation might still have it.) Gruesse, Carsten From paduffy@cisco.com Tue May 3 12:40:38 2011 Return-Path: <paduffy@cisco.com> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 732E7E0892 for <core@ietfa.amsl.com>; Tue, 3 May 2011 12:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJ6MDVanGkZk for <core@ietfa.amsl.com>; Tue, 3 May 2011 12:40:37 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 32961E0777 for <core@ietf.org>; Tue, 3 May 2011 12:40:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paduffy@cisco.com; l=4774; q=dns/txt; s=iport; t=1304451637; x=1305661237; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to:content-transfer-encoding; bh=/21Z9U9DW+FhtkEQiOuW+RRIBTxGE4YJ1TmO67spYfs=; b=DXNupMSsTluIHhGYsVQo0dbvPRyn70JeJLqLSUxJ3v08NdFNQp1xPzRg ZmHTJjNM7vRQ8zvZw7mILrSxa+Jh4JsTi3lg79Nf1JiEIT9axuKr27Zuo FWI3FNpfQa7CH+aXsH6BIeYa9hyDj/99mkNTeHhS5t1puifqV8AW+BC8+ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGpZwE2tJXG+/2dsb2JhbACmHXenQIJ4DwGZeIYCBI8YhBqKNA X-IronPort-AV: E=Sophos;i="4.64,310,1301875200"; d="scan'208";a="349633047" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by sj-iport-2.cisco.com with ESMTP; 03 May 2011 19:40:36 +0000 Received: from [161.44.66.248] (dhcp-161-44-66-248.cisco.com [161.44.66.248]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p43Jeagc018854 for <core@ietf.org>; Tue, 3 May 2011 19:40:36 GMT Message-ID: <4DC05A34.5020703@cisco.com> Date: Tue, 03 May 2011 15:40:36 -0400 From: Paul Duffy <paduffy@cisco.com> Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: core@ietf.org References: <057.ca63b30ac3e3ffdf9aad52c02fa3ebc8@trac.tools.ietf.org> <4D9AF230.6020805@labs.htt-consult.com> <CEB68E91-5CC6-451D-A581-8248189D9FA0@tzi.org> <4D9B0750.8010408@labs.htt-consult.com> <BANLkTi=qot=6wJU1OAFzpxm+2CzddHCyoA@mail.gmail.com> <BANLkTimPb5qM8y9dxdXb9dDm4Nq8_f1g3Q@mail.gmail.com> <99AAB914-B0BB-445B-8DCF-75B23D6A1D5E@tzi.org> <4D9F357C.8040708@labs.htt-consult.com> <BANLkTinUyxpRx9MZD5H7r6_x+Jqy5JKQpg@mail.gmail.com> <4DD1DBC7-6868-4246-9184-441B59F35D3D@iki.fi> In-Reply-To: <4DD1DBC7-6868-4246-9184-441B59F35D3D@iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [core] #138: DTLS Clarification X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: paduffy@cisco.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 03 May 2011 19:40:38 -0000 Channeling Dave McGrew... What security claims are being made for a CMAC based PRF, and what analysis shows that they are valid? Blockcipher-based constructions for extracting a secret key from a DH or ECDH shared secret are problematic. As far as I know, they all rely on the ideal-cipher assumption, which is not very realistic, and which is shown to be a bad assumption for AES from the recent related key attacks. Re: the ECC curves and Suite B...yes, Zigbee SE2.0 requires 128-bit security, and the ccm-ecc draft reflects a rough consensus of that group. On 4/12/2011 2:25 AM, Juho Vähä-Herttua wrote: > On Apr 12, 2011, at 12:56 AM, Eric Rescorla wrote: >> On Fri, Apr 8, 2011 at 9:19 AM, Robert Moskowitz >> <rgm@labs.htt-consult.com> wrote: >>> On 04/07/2011 11:34 PM, Carsten Bormann wrote: >>> >>> On Apr 8, 2011, at 00:34, Robert Cragie wrote: >>> >>> In my experience both SHA-256 and HMAC are not expensive. >>> >>> Clearly SHA-256 (and especially HMAC) are not particularly expensive in >>> execution time when used as the PRF for establishing TLS connections. >>> >>> Still, on a highly constrained device, all other things being the same, it >>> would be preferable not to spend the code space if existing AES encryption >>> hardware (or even software) can be employed. >> The problem is that all else isn't equal here: we have a well-understood PRF >> that is already standardized. Not using that PRF reduces the general >> applicability >> of the proposed CCM modes. So, I think before making a change like that it >> would be better to demonstrate that the SHA-256 code is actually an important >> contributor to code size > I'm new on this list, but thought to express some motivation behind this. I implemented Robert's HIP DEX protocol where he had successfully removed cryptographic hash functions, and in the progress mentioned it would be easy to make TLS similar by just using static ECDH or ECDH_anon and CMAC based PRF, possibly even easier than implementing the HIP DEX itself. > > I can't speak for anyone else, but I think you're misunderstanding my idea here. Currently draft-mcgrew-tls-aes-ccm-eec-01 defines only ECDSA_ECDHE cipher suites (which are written as ECDHE_ECDSA in the draft by the way, that is completely wrong order) and if one wants to use them they have to have a cryptographic hash function available anyway for signing the ephemeral Diffie-Hellman keys. Changing the PRF to AES based has no point there. > > However, using a CMAC based PRF that doesn't have a hash function would be useful as an _optional_ feature in the ECDH_anon and PSK-ECDHE cipher suites, which are apparently not defined yet. Just like the AES-GCM cipher suites are defining two PRFs (SHA-256 and SHA-384 based HMAC), the AES-CCM modes that don't use signing could define an additional PRF for low class devices. I would probably need some data about SHA-256 code space, because I very much agree that it is not expensive in execution time, have to get back to it. But it's clear that already the lookup tables of SHA-256 take some amount of space. > > I should probably also contact David McGrew about the same AES-CCM draft related to the elliptic curves requirement. It has the sentence and a list "The ECDHE_ECDSA key exchange is performed as defined in [RFC4492] with the following additional stipulations", where I disagree with most of the additional stipulations. They greatly reduce the general applicability of the proposed CCM modes, as you just said. I'm especially worried about that secp256r1 and secp384r1 MUST be supported, because I have already demonstrated that my wireless sensor node is NOT capable of even performing a secp256r1 handshake. The secp224r1 on the other hand works reasonably well, difference between those two is huge because of the different pseudo-Mersenne primes used in modular reduction. > > Only reason why I see the two curves required there is NSA Suite B and maybe something that's happening in the Zigbee group, but that shouldn't affect the generalness of AES-CCM cipher suites in TLS. I remember writing about this to David earlier, but apparently it wasn't changed when the draft was updated. Before this kind of major problems with general applicability are solved, I don't know how relevant it is to fight about PRFs. But I don't think a CMAC PRF in addition to HMAC PRF in some cipher suites would be a bad idea at all. What was the motivation behind making the PRF selectable in TLS 1.2 if you are going to argue against cipher suites selecting a different PRF as an option anyway? > > > Juho > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From cabo@tzi.org Tue May 3 12:44:02 2011 Return-Path: <cabo@tzi.org> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F9CAE08A9 for <core@ietfa.amsl.com>; Tue, 3 May 2011 12:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.699 X-Spam-Level: X-Spam-Status: No, score=-105.699 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, GB_AFFORDABLE=1, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ms62NndTilBC for <core@ietfa.amsl.com>; Tue, 3 May 2011 12:44:01 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 0578FE07E4 for <core@ietf.org>; Tue, 3 May 2011 12:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id p43JhrJP014347; Tue, 3 May 2011 21:43:53 +0200 (CEST) Received: from [192.168.217.112] (p5B3E613E.dip.t-dialin.net [91.62.97.62]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id A0323ACF; Tue, 3 May 2011 21:43:52 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann <cabo@tzi.org> In-Reply-To: <55877B3AFB359744BA0F2140E36F52B508420C33@MBX20.d.ethz.ch> Date: Tue, 3 May 2011 21:43:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <637DB85D-884A-45A5-86BA-88B7B483E758@tzi.org> References: <55877B3AFB359744BA0F2140E36F52B50841DBA2@MBX20.d.ethz.ch> <7F64A4BC-8AAC-41CE-9449-F6F4DEE3DF1E@tzi.org> <55877B3AFB359744BA0F2140E36F52B508420C33@MBX20.d.ethz.ch> To: "Kovatsch Matthias" <kovatsch@inf.ethz.ch> X-Mailer: Apple Mail (2.1084) Cc: "core@ietf.org" <core@ietf.org> Subject: Re: [core] CoAP block sizes: power of two might not be optimal X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 03 May 2011 19:44:02 -0000 On May 3, 2011, at 21:29, Kovatsch Matthias wrote: > Maybe to add another use case: I can imagine configuration updates = with multiple JSON-encoded parameters that won't fit the affordable = buffer. These might happen much more frequently than the 'famous' = firmware updates. Can you give me an idea of the Probability Distribution of the size of = those representations? What is your favorite payload block size? (You could always fragment multiple JSON parameters on the application = layer, BTW. But that, of course, means that you have to add any crypto = you may need to each of the fragments.) Gruesse, Carsten From alexey.melnikov@isode.com Tue May 3 12:47:50 2011 Return-Path: <alexey.melnikov@isode.com> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C635E0878 for <core@ietfa.amsl.com>; Tue, 3 May 2011 12:47:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.041 X-Spam-Level: X-Spam-Status: No, score=-103.041 tagged_above=-999 required=5 tests=[AWL=-0.442, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qWydWITWuC0X for <core@ietfa.amsl.com>; Tue, 3 May 2011 12:47:49 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id BB14AE0758 for <core@ietf.org>; Tue, 3 May 2011 12:47:47 -0700 (PDT) Received: from [192.168.1.124] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id <TcBb4QBK46-F@rufus.isode.com>; Tue, 3 May 2011 20:47:46 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4DC05BE9.4000006@isode.com> Date: Tue, 03 May 2011 20:47:53 +0100 From: Alexey Melnikov <alexey.melnikov@isode.com> 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 <zach@sensinode.com> References: <4DA562B6.8000508@isode.com> <FE154C25-7C17-48FF-905A-DEAC8343B9A0@sensinode.com> <4DBFE205.5030608@isode.com> <0D8AA6B5-E43F-4836-98FC-EF32EFC4C4C1@sensinode.com> <4DBFE788.4030909@isode.com> <36CC0B2D-404C-49AC-88B3-92D1B4A6319B@sensinode.com> In-Reply-To: <36CC0B2D-404C-49AC-88B3-92D1B4A6319B@sensinode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: core@ietf.org Subject: Re: [core] Review of draft-ietf-core-link-format-03.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 03 May 2011 19:47:50 -0000 Zach Shelby wrote: >On May 3, 2011, at 2:31 PM, Alexey Melnikov wrote: > [...] >>>>Which brings me to a related issue: there is no ABNF of the format defined in the document. There are only ABNFs for pieces of the Link format. >>>> >>>RFC5988 describes the ABNF for the format. We are simply reusing that. Originally we did repeat that ABNF in the CoRE Link Format, but were encouraged by Martin and Mark to take that out. I agree with them that repeating it is not worthwhile. >>> >>> >>I suggest you actually point to the specific ABNF production in RFC 5988. That way you wouldn't have to repeat ABNF from it. >> > >The draft currently states > >"The CoRE link format uses the ABNF description and associated rules > in Section 5 of [RFC5988]. In addition, the pchar rule is taken from > [RFC3986]. " > >Is there a way to also indicate this in the ABNF of the new attributes. Some kind of "Import everything from Section 5 of RFC5988"? > One way of doing this is by defining rules like: link-param = <Defined in RFC 5988> and then: link-param =/ ...your new value goes there... >I can mention that in the first sentence of Section 3, but it would be nice to have that explicit in the ABNF. > From kovatsch@inf.ethz.ch Tue May 3 12:55:46 2011 Return-Path: <kovatsch@inf.ethz.ch> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCC7FE0758 for <core@ietfa.amsl.com>; Tue, 3 May 2011 12:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, GB_AFFORDABLE=1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B7edYx3m-ZaG for <core@ietfa.amsl.com>; Tue, 3 May 2011 12:55:46 -0700 (PDT) Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) by ietfa.amsl.com (Postfix) with ESMTP id BAFA2E0744 for <core@ietf.org>; Tue, 3 May 2011 12:55:45 -0700 (PDT) Received: from CAS10.d.ethz.ch (172.31.38.210) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.1.289.1; Tue, 3 May 2011 21:55:40 +0200 Received: from MBX20.d.ethz.ch ([fe80::81a7:b7a5:50c0:df0d]) by CAS10.d.ethz.ch ([fe80::cce:fc66:7b56:a06a%11]) with mapi id 14.01.0289.001; Tue, 3 May 2011 21:55:44 +0200 From: "Kovatsch Matthias" <kovatsch@inf.ethz.ch> To: Carsten Bormann <cabo@tzi.org> Thread-Topic: AW: [core] CoAP block sizes: power of two might not be optimal Thread-Index: AcwGfcHsDp9xn7EdT4OrSVjR+tAo4QDME5qAAAYBFtD//+cqgP//3eVA Date: Tue, 3 May 2011 19:55:44 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B508420C6D@MBX20.d.ethz.ch> References: <55877B3AFB359744BA0F2140E36F52B50841DBA2@MBX20.d.ethz.ch> <7F64A4BC-8AAC-41CE-9449-F6F4DEE3DF1E@tzi.org> <55877B3AFB359744BA0F2140E36F52B508420C33@MBX20.d.ethz.ch> <637DB85D-884A-45A5-86BA-88B7B483E758@tzi.org> In-Reply-To: <637DB85D-884A-45A5-86BA-88B7B483E758@tzi.org> Accept-Language: en-US, de-CH Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [193.10.67.50] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "core@ietf.org" <core@ietf.org> Subject: Re: [core] CoAP block sizes: power of two might not be optimal X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 03 May 2011 19:55:46 -0000 Hi > > Maybe to add another use case: I can imagine configuration updates with > multiple JSON-encoded parameters that won't fit the affordable buffer. > These might happen much more frequently than the 'famous' firmware > updates. >=20 > Can you give me an idea of the Probability Distribution of the size of th= ose > representations? Sorry, for that I don't have enough different applications so far. > What is your favorite payload block size? The 160 B block would be a nice one as it is roughly the buffer size the co= mmon 8-10 kB RAM platforms can afford and it roughly maxs out two fragments= for 15.4 frames. >=20 > (You could always fragment multiple JSON parameters on the application > layer, BTW. But that, of course, means that you have to add any crypto y= ou > may need to each of the fragments.) Yes, splitting the parameters is always an option. Keeping the configuratio= n together in one set/file, however, is very convenient. Ciao Matthias From zach@sensinode.com Tue May 3 13:03:21 2011 Return-Path: <zach@sensinode.com> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 837A4E06D6 for <core@ietfa.amsl.com>; Tue, 3 May 2011 13:03:21 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKzWsuuLCOeZ for <core@ietfa.amsl.com>; Tue, 3 May 2011 13:03:20 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD48E0680 for <core@ietf.org>; Tue, 3 May 2011 13:03:19 -0700 (PDT) Received: from [192.168.0.102] (line-12346.dyn.kponet.fi [85.29.94.169]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id p43K36Hi003250 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <core@ietf.org>; Tue, 3 May 2011 23:03:08 +0300 From: Zach Shelby <zach@sensinode.com> Content-Type: multipart/signed; boundary=Apple-Mail-214--271725549; protocol="application/pkcs7-signature"; micalg=sha1 Date: Tue, 3 May 2011 23:03:08 +0300 Message-Id: <AB60E477-A082-4948-88CD-B6170D303E9C@sensinode.com> To: core WG <core@ietf.org> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [core] New version of core-link-format X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 03 May 2011 20:03:21 -0000 --Apple-Mail-214--271725549 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, A new version of the CoRE Link Format (-04) is now available: http://tools.ietf.org/html/draft-ietf-core-link-format-04 This now closes the WGLC tickets that were presented in Prague, along = with the great review help from Alexey (thanks!).=20 Change log: o Removed the attribute registry (#145). o Requested a CoAP media type for application/link-format (#144). o Editorial and reference improvements from AD review (#146). o Added a range limitation for ct attribute. o Added security considerations and file extension for application/link-format registration. 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-214--271725549 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 ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDUwMzIwMDMw OVowIwYJKoZIhvcNAQkEMRYEFL8+JGvt9+FC6t4cfqi17js5ZqJdMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBADZICOzPK7CNMAak1i4kzNETowMLKxr4I0BjVTm698bYX4WOKcvY7Gcj L0/wcZS3JI4vfIOb9WiBDO3uULpTWt1cS7ZvE7a6Byh0QXKIAq9UA1jw5DO94xWfJVFJnUYQpfFZ 3/z25X0/wj8DpIzKn0bVvk729NSTGVJEZxp94KNcYVV+UeBhoeS+aJN24f5v32/syKdmJJ4tZzNz cNgecrKULXMP2M+isah6itzv3dYY4w7YaM2DRYEfMeHYvDt3elviA41DMPYOY8Pn+DBB45XznCU1 FsLepIG0SGGuCyZyE7LPy8rNDmH7nLvLVC67+GSzEYoBuOS12QP60B24wBwAAAAAAAA= --Apple-Mail-214--271725549-- From cabo@tzi.org Tue May 3 13:04:27 2011 Return-Path: <cabo@tzi.org> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64BE3E06D6 for <core@ietfa.amsl.com>; Tue, 3 May 2011 13:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.135 X-Spam-Level: X-Spam-Status: No, score=-106.135 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dSyuD1U0bI2w for <core@ietfa.amsl.com>; Tue, 3 May 2011 13:04:26 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 611DCE0680 for <core@ietf.org>; Tue, 3 May 2011 13:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id p43K4FGu019599; Tue, 3 May 2011 22:04:15 +0200 (CEST) Received: from [192.168.217.112] (p5B3E613E.dip.t-dialin.net [91.62.97.62]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 9DAF9ADB; Tue, 3 May 2011 22:04:14 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann <cabo@tzi.org> In-Reply-To: <4DC05A34.5020703@cisco.com> Date: Tue, 3 May 2011 22:04:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <F6CF216A-9824-450E-B286-A2B760F6FDE8@tzi.org> References: <057.ca63b30ac3e3ffdf9aad52c02fa3ebc8@trac.tools.ietf.org> <4D9AF230.6020805@labs.htt-consult.com> <CEB68E91-5CC6-451D-A581-8248189D9FA0@tzi.org> <4D9B0750.8010408@labs.htt-consult.com> <BANLkTi=qot=6wJU1OAFzpxm+2CzddHCyoA@mail.gmail.com> <BANLkTimPb5qM8y9dxdXb9dDm4Nq8_f1g3Q@mail.gmail.com> <99AAB914-B0BB-445B-8DCF-75B23D6A1D5E@tzi.org> <4D9F357C.8040708@labs.htt-consult.com> <BANLkTinUyxpRx9MZD5H7r6_x+Jqy5JKQpg@mail.gmail.com> <4DD1DBC7-6868-4246-9184-441B59F35D3D@iki.fi> <4DC05A34.5020703@cisco.com> To: paduffy@cisco.com X-Mailer: Apple Mail (2.1084) Cc: core@ietf.org Subject: Re: [core] #138: DTLS Clarification X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 03 May 2011 20:04:27 -0000 On May 3, 2011, at 21:40, Paul Duffy wrote: > Channeling Dave McGrew... >=20 > What security claims are being made for a CMAC based PRF, and what = analysis shows that they are valid? =20 I don't think there are being claims made yet. However, the numbers we have show that it may be useful to have a = block-cipher based KDF available in our toolkit from an implementation = cost point of view. That's why we'd like to explore/better understand = this space. > Blockcipher-based constructions for extracting a secret key from a DH = or ECDH shared secret are problematic. As far as I know, they all rely = on the ideal-cipher assumption, which is not very realistic, and which = is shown to be a bad assumption for AES from the recent related key = attacks. I'm not a cryptographer, so I have to ask: does this invalidate the = recommendations made in sp800-108? Or are you saying that the problem is that "For a given KDF using HMAC = or CMAC, the key KI is assumed to be computationally indistinguishable = from one that has been selected uniformly at random from the set of all = the binary strings with length of |KI|." from section 4 of that document = is simply not fulfilled for DH/ECDH shared secrets? I could see why = this would be a bigger problem for CMAC than for HMAC. > Re: the ECC curves and Suite B...yes, Zigbee SE2.0 requires 128-bit = security, and the ccm-ecc draft reflects a rough consensus of that = group. For SE2.0, the complexity is already high enough that having to support = SHA256 does not hurt that much (these devices have been called "class 2" = devices in recent discussion). For much simpler devices ("class 1"), we were interested in being able = to support very basic PSK schemes. Those PSKs wouldn't have to have the = same properties that DH/ECDH shared secrets have, so CMAC may be more = appropriate for this specific case. For a tentative definition of "class 1" and "class 2", see the below = excerpt of the draft LWIG Guidance document (to be submitted as an I-D = any day now). Gruesse, Carsten 2.1. Classes of Devices Despite the overwhelming variety of Internet-connected devices that can be envisioned, it may, be worthwhile to have some succinct terminology for different classes of constrained devices. In this document, the following class designations may be used as rough indications of device capabilities: +---------+-----------------------+-------------------------+ | Name | data size (e.g., RAM) | code size (e.g., Flash) | +---------+-----------------------+-------------------------+ | Class 1 | ~ 10 KiB | ~ 100 KiB | | | | | | Class 2 | ~ 50 KiB | ~ 250 KiB | +---------+-----------------------+-------------------------+ As of the writing of this document, these characteristics correspond to distinguishable sets of commercially available chips and design cores for constrained devices. While it is expected that the boundaries of these classes will move over time, Moore's law tends to be less effective in the embedded space than in personal computing devices: Gains made available by increases in transistor count and density are more likely to be invested in reductions of cost and power requirements than into continual increases in computing power. From cabo@tzi.org Tue May 3 13:06:58 2011 Return-Path: <cabo@tzi.org> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2F18E06F8 for <core@ietfa.amsl.com>; Tue, 3 May 2011 13:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.149 X-Spam-Level: X-Spam-Status: No, score=-106.149 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qeeB51cMkMjD for <core@ietfa.amsl.com>; Tue, 3 May 2011 13:06:58 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id CE4EBE0680 for <core@ietf.org>; Tue, 3 May 2011 13:06:57 -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 p43K6mku020035; Tue, 3 May 2011 22:06:48 +0200 (CEST) Received: from [192.168.217.112] (p5B3E613E.dip.t-dialin.net [91.62.97.62]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id D1E0AADC; Tue, 3 May 2011 22:06:47 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann <cabo@tzi.org> In-Reply-To: <55877B3AFB359744BA0F2140E36F52B508420C6D@MBX20.d.ethz.ch> Date: Tue, 3 May 2011 22:06:46 +0200 Content-Transfer-Encoding: 7bit Message-Id: <714A57FA-B626-46BD-90C7-C9C17E22500B@tzi.org> References: <55877B3AFB359744BA0F2140E36F52B50841DBA2@MBX20.d.ethz.ch> <7F64A4BC-8AAC-41CE-9449-F6F4DEE3DF1E@tzi.org> <55877B3AFB359744BA0F2140E36F52B508420C33@MBX20.d.ethz.ch> <637DB85D-884A-45A5-86BA-88B7B483E758@tzi.org> <55877B3AFB359744BA0F2140E36F52B508420C6D@MBX20.d.ethz.ch> To: "Kovatsch Matthias" <kovatsch@inf.ethz.ch> X-Mailer: Apple Mail (2.1084) Cc: "core@ietf.org" <core@ietf.org> Subject: Re: [core] CoAP block sizes: power of two might not be optimal X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 03 May 2011 20:06:58 -0000 On May 3, 2011, at 21:55, Kovatsch Matthias wrote: > 160 B That's only 25 % larger than 128. My "premature optimization" warning bell just went off :-) Gruesse, Carsten From kovatsch@inf.ethz.ch Tue May 3 13:10:02 2011 Return-Path: <kovatsch@inf.ethz.ch> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48672E073C for <core@ietfa.amsl.com>; Tue, 3 May 2011 13:10:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PPZZV6F9PQTV for <core@ietfa.amsl.com>; Tue, 3 May 2011 13:09:48 -0700 (PDT) Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) by ietfa.amsl.com (Postfix) with ESMTP id 70207E0680 for <core@ietf.org>; Tue, 3 May 2011 13:09:48 -0700 (PDT) Received: from CAS11.d.ethz.ch (172.31.38.211) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.1.289.1; Tue, 3 May 2011 22:09:43 +0200 Received: from MBX20.d.ethz.ch ([fe80::81a7:b7a5:50c0:df0d]) by CAS11.d.ethz.ch ([fe80::ecc9:4e2d:b26b:1614%11]) with mapi id 14.01.0289.001; Tue, 3 May 2011 22:09:48 +0200 From: "Kovatsch Matthias" <kovatsch@inf.ethz.ch> To: Carsten Bormann <cabo@tzi.org> Thread-Topic: AW: AW: [core] CoAP block sizes: power of two might not be optimal Thread-Index: AcwGfcHsDp9xn7EdT4OrSVjR+tAo4QDME5qAAAYBFtD//+cqgP//3eVAgAAoggD//93+IA== Date: Tue, 3 May 2011 20:09:46 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B508420C96@MBX20.d.ethz.ch> References: <55877B3AFB359744BA0F2140E36F52B50841DBA2@MBX20.d.ethz.ch> <7F64A4BC-8AAC-41CE-9449-F6F4DEE3DF1E@tzi.org> <55877B3AFB359744BA0F2140E36F52B508420C33@MBX20.d.ethz.ch> <637DB85D-884A-45A5-86BA-88B7B483E758@tzi.org> <55877B3AFB359744BA0F2140E36F52B508420C6D@MBX20.d.ethz.ch> <714A57FA-B626-46BD-90C7-C9C17E22500B@tzi.org> In-Reply-To: <714A57FA-B626-46BD-90C7-C9C17E22500B@tzi.org> Accept-Language: en-US, de-CH Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [193.10.67.50] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "core@ietf.org" <core@ietf.org> Subject: Re: [core] CoAP block sizes: power of two might not be optimal X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 03 May 2011 20:10:02 -0000 > > 160 B >=20 > That's only 25 % larger than 128. >=20 > My "premature optimization" warning bell just went off :-) Ok, fine. Let's see what the future holds! :) From juhovh@iki.fi Tue May 3 13:34:32 2011 Return-Path: <juhovh@iki.fi> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF6E2E0800 for <core@ietfa.amsl.com>; Tue, 3 May 2011 13:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d-03vXQoSTTb for <core@ietfa.amsl.com>; Tue, 3 May 2011 13:34:32 -0700 (PDT) Received: from kirsi1.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 80124E069B for <core@ietf.org>; Tue, 3 May 2011 13:34:31 -0700 (PDT) Received: from mail.visino.fi (84.251.121.70) by kirsi1.inet.fi (8.5.133) id 4D9982B1014F3525; Tue, 3 May 2011 23:34:28 +0300 Received: from [192.168.1.100] (dsl-hkibrasgw3-ff2cc000-252.dhcp.inet.fi [88.192.44.252]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: juhovh) by mail.visino.fi (Postfix) with ESMTPSA id 53561201C5; Tue, 3 May 2011 23:34:12 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-1--269865323; protocol="application/pkcs7-signature"; micalg=sha1 From: =?iso-8859-1?Q?Juho_V=E4h=E4-Herttua?= <juhovh@iki.fi> In-Reply-To: <4DC05A34.5020703@cisco.com> Date: Tue, 3 May 2011 23:34:08 +0300 Message-Id: <856CAFE5-6FCB-45BD-8A96-7194F19A57EE@iki.fi> References: <057.ca63b30ac3e3ffdf9aad52c02fa3ebc8@trac.tools.ietf.org> <4D9AF230.6020805@labs.htt-consult.com> <CEB68E91-5CC6-451D-A581-8248189D9FA0@tzi.org> <4D9B0750.8010408@labs.htt-consult.com> <BANLkTi=qot=6wJU1OAFzpxm+2CzddHCyoA@mail.gmail.com> <BANLkTimPb5qM8y9dxdXb9dDm4Nq8_f1g3Q@mail.gmail.com> <99AAB914-B0BB-445B-8DCF-75B23D6A1D5E@tzi.org> <4D9F357C.8040708@labs.htt-consult.com> <BANLkTinUyxpRx9MZD5H7r6_x+Jqy5JKQpg@mail.gmail.com> <4DD1DBC7-6868-4246-9184-441B59F35D3D@iki.fi> <4DC05A34.5020703@cisco.com> To: paduffy@cisco.com X-Mailer: Apple Mail (2.1084) Cc: core@ietf.org Subject: Re: [core] #138: DTLS Clarification X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 03 May 2011 20:34:32 -0000 --Apple-Mail-1--269865323 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On May 3, 2011, at 10:40 PM, Paul Duffy wrote: > Channeling Dave McGrew... >=20 > What security claims are being made for a CMAC based PRF, and what = analysis shows that they are valid? Blockcipher-based constructions = for extracting a secret key from a DH or ECDH shared secret are = problematic. As far as I know, they all rely on the ideal-cipher = assumption, which is not very realistic, and which is shown to be a bad = assumption for AES from the recent related key attacks. It starts to look like this has been discussed before, partly by the = same people. I found this mailing list message from 2009 = http://www6.ietf.org/mail-archive/web/tcpm/current/msg04730.html which = discusses AES-128-CMAC based KDF. (with McGrew mentioned and Rescorla = replying) The people involved might know more details, it seems that the = suggestion resulted in KDF_AES_128_CMAC alternative to HMAC in RFC 5926 = with very similar motivation to the one presented here. > Re: the ECC curves and Suite B...yes, Zigbee SE2.0 requires 128-bit = security, and the ccm-ecc draft reflects a rough consensus of that = group. I think it is simply wrong that Zigbee SE2.0 security requirements = direct the (general) specification of TLS cipher suites. I have had = trouble getting Suite B handshakes to run in real time on some devices, = although problems have been mostly CPU bound not so much memory related. = Does anyone have data of secp256r1 ECDH performance on target device = classes? With well optimized libraries it might still be valid, but as = mentioned the difference between secp224r1 and secp256r1 can be very = big. Juho > On 4/12/2011 2:25 AM, Juho V=E4h=E4-Herttua wrote: >> On Apr 12, 2011, at 12:56 AM, Eric Rescorla wrote: >>> On Fri, Apr 8, 2011 at 9:19 AM, Robert Moskowitz >>> <rgm@labs.htt-consult.com> wrote: >>>> On 04/07/2011 11:34 PM, Carsten Bormann wrote: >>>>=20 >>>> On Apr 8, 2011, at 00:34, Robert Cragie wrote: >>>>=20 >>>> In my experience both SHA-256 and HMAC are not expensive. >>>>=20 >>>> Clearly SHA-256 (and especially HMAC) are not particularly = expensive in >>>> execution time when used as the PRF for establishing TLS = connections. >>>>=20 >>>> Still, on a highly constrained device, all other things being the = same, it >>>> would be preferable not to spend the code space if existing AES = encryption >>>> hardware (or even software) can be employed. >>> The problem is that all else isn't equal here: we have a = well-understood PRF >>> that is already standardized. Not using that PRF reduces the general >>> applicability >>> of the proposed CCM modes. So, I think before making a change like = that it >>> would be better to demonstrate that the SHA-256 code is actually an = important >>> contributor to code size >> I'm new on this list, but thought to express some motivation behind = this. I implemented Robert's HIP DEX protocol where he had successfully = removed cryptographic hash functions, and in the progress mentioned it = would be easy to make TLS similar by just using static ECDH or ECDH_anon = and CMAC based PRF, possibly even easier than implementing the HIP DEX = itself. >>=20 >> I can't speak for anyone else, but I think you're misunderstanding my = idea here. Currently draft-mcgrew-tls-aes-ccm-eec-01 defines only = ECDSA_ECDHE cipher suites (which are written as ECDHE_ECDSA in the draft = by the way, that is completely wrong order) and if one wants to use them = they have to have a cryptographic hash function available anyway for = signing the ephemeral Diffie-Hellman keys. Changing the PRF to AES based = has no point there. >>=20 >> However, using a CMAC based PRF that doesn't have a hash function = would be useful as an _optional_ feature in the ECDH_anon and PSK-ECDHE = cipher suites, which are apparently not defined yet. Just like the = AES-GCM cipher suites are defining two PRFs (SHA-256 and SHA-384 based = HMAC), the AES-CCM modes that don't use signing could define an = additional PRF for low class devices. I would probably need some data = about SHA-256 code space, because I very much agree that it is not = expensive in execution time, have to get back to it. But it's clear that = already the lookup tables of SHA-256 take some amount of space. >>=20 >> I should probably also contact David McGrew about the same AES-CCM = draft related to the elliptic curves requirement. It has the sentence = and a list "The ECDHE_ECDSA key exchange is performed as defined in = [RFC4492] with the following additional stipulations", where I disagree = with most of the additional stipulations. They greatly reduce the = general applicability of the proposed CCM modes, as you just said. I'm = especially worried about that secp256r1 and secp384r1 MUST be supported, = because I have already demonstrated that my wireless sensor node is NOT = capable of even performing a secp256r1 handshake. The secp224r1 on the = other hand works reasonably well, difference between those two is huge = because of the different pseudo-Mersenne primes used in modular = reduction. >>=20 >> Only reason why I see the two curves required there is NSA Suite B = and maybe something that's happening in the Zigbee group, but that = shouldn't affect the generalness of AES-CCM cipher suites in TLS. I = remember writing about this to David earlier, but apparently it wasn't = changed when the draft was updated. Before this kind of major problems = with general applicability are solved, I don't know how relevant it is = to fight about PRFs. But I don't think a CMAC PRF in addition to HMAC = PRF in some cipher suites would be a bad idea at all. What was the = motivation behind making the PRF selectable in TLS 1.2 if you are going = to argue against cipher suites selecting a different PRF as an option = anyway? >>=20 >>=20 >> Juho >>=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 --Apple-Mail-1--269865323 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM+DCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIGvDCCBaSg AwIBAgICC7kwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MDEwMDkxODQ4MjVaFw0xMjEwMDkyMzA0MjZaMIG6MSAwHgYDVQQNExcyNzE5OTktNTRMRzc2dUow TXMwQWs4eDELMAkGA1UEBhMCRkkxEDAOBgNVBAgTB1V1c2ltYWExDjAMBgNVBAcTBUVzcG9vMS0w KwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEUp1 aG8gVmFoYS1IZXJ0dHVhMRwwGgYJKoZIhvcNAQkBFg1qdWhvdmhAaWtpLmZpMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsgecI8+NNG/D0e/PpHHJDPlVhR4mmAPZZUBA22yAf6OageO6 H9GUuuNq787QHvF87ySXb8uZMpC1EDqdkEweHdRMd8fPvHmhgLj4w3xO/pFG/d/ZUpQ3nUEF7yqm 94mgG1yW1ps3Q5eKuUE7m5XT3MKxDugb2GX/5u4LmVrC3YM6DDqdf7Fzof9F3I44EpeQfJx5jp8Y KerCRGEVTVfxcA8JxHT5ZAi3xG3lVBkYb45zHzKCGz32ol34L65IRkTt9wkNnkZYzDv3E8sweQpL 5U24kHUMxclWmGpvNuXyWdaFeg68bUXujoUfoTzSf3p1vx7PWMAHd4PnCuX5e4rAWwIDAQABo4IC 9jCCAvIwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUF BwMEMB0GA1UdDgQWBBQOC6ocoJ57B8gH/dYfGyjmOl92tDAfBgNVHSMEGDAWgBSuVYNv7DHKufcd +q9rMfPIHeOsuzAYBgNVHREEETAPgQ1qdWhvdmhAaWtpLmZpMIIBQgYDVR0gBIIBOTCCATUwggEx BgsrBgEEAYG1NwECAjCCASAwLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0 ZS5wZGYwgbcGCCsGAQUFBwICMIGqMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBkUxpbWl0ZWQgTGlh YmlsaXR5LCBzZWUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93d3cuc3Rh cnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3dy5zdGFydHNz bC5jb20vY3J0dTItY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTIt Y3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRz c2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDov L3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQCunEi6zUK6IXC5vcyRBFVcZdpE QsYKVVKwS6T1NPxMVlLriKu27lG3tuxgwW4mR/FpyXf30RmP2/l3BMcrnBMVKqY9KQle7pzv1nDG Om2QSHUbgjMaOyvNeSwjkjP/2zfZ2gdot1S3K6PZl4SKx1H6tOqePPJAfCYb4WBj/vlIREmXzozd pzQu8G7fEuIni76Z0xIJVC50KDcry1lIsuZGUQ+fXuVkbNv7EO8tID6ylX/EWIMd2Pz/gq+0Jppz hIqo03Y03cPZAsqFtg+ZqukM/zdmapHK/ayVJaHsRbS7fvbC8aE6o0T6p5KwqQI0lcDyvugOw/pg FHSf/UgeAE2MMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICC7kw CQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTEwNTAzMjAzNDA5WjAjBgkqhkiG9w0BCQQxFgQUQGLt+szPYC8SU3qOtuDgojy4OpcwgaQGCSsG AQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgILuTCBpgYLKoZIhvcN AQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENv bSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICC7kwDQYJKoZIhvcNAQEB BQAEggEAY7zTNIY8d0szTb+ubM2+W27AWDGJZDpvQCht9M35ACv767xS/KnFVhPuXKiiKTU0r8wc ryMPePY2UaHXGaJSkHXyV/8gIBZDYQ2PX7zy0DVv2SnNokEdrLe6lm3zsveVVA42Nna6kh2pPVdg KKys1lb3910AWTRm9Yn1ob5mv95i79r1bHBCpBIYWLxQ49IVOjIgjk9/EzyeX8F5xM0JpXti5UX3 3oW8oJFpkuza9lKUZT4jXq3g+Pkcv87afx1+9hDTX8GJWOLS64ZmaEP8fdWmRShCwpbY6I3OILgm 7My7QJC6uW+lyIaqhW19tccz+mpTjZ1+fJnE5CFdp3cNPgAAAAAAAA== --Apple-Mail-1--269865323-- From trac+core@trac.tools.ietf.org Tue May 3 13:44:56 2011 Return-Path: <trac+core@trac.tools.ietf.org> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED99E0769 for <core@ietfa.amsl.com>; Tue, 3 May 2011 13:44:56 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KOYMjH3Mnxfu for <core@ietfa.amsl.com>; Tue, 3 May 2011 13:44:55 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 28E2AE069A for <core@ietf.org>; Tue, 3 May 2011 13:44:54 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from <trac+core@trac.tools.ietf.org>) id 1QHMSg-0007J6-MF; Tue, 03 May 2011 13:44:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" <trac+core@trac.tools.ietf.org> 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, cabo@tzi.org X-Trac-Project: core Date: Tue, 03 May 2011 20:44:50 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/142#comment:2 Message-ID: <066.5f27196c4a92b3e6233a8cca43f8a4e8@trac.tools.ietf.org> References: <057.1785b085f639645bb771c4ab0a053779@trac.tools.ietf.org> X-Trac-Ticket-ID: 142 In-Reply-To: <057.1785b085f639645bb771c4ab0a053779@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@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] #142: Retransmit timeout jitter X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 03 May 2011 20:44:56 -0000 #142: Retransmit timeout jitter Comment(by cabo@…): From [323]: Make sure we consider RESPONSE_RANDOM_FACTOR in the potential retransmission window (re #142). -- ----------------------------------+----------------------------------------- Reporter: zach@… | Owner: zach@… Type: protocol enhancement | Status: closed Priority: minor | Milestone: Component: coap | Version: Severity: - | Resolution: fixed Keywords: | ----------------------------------+----------------------------------------- Ticket URL: </ticket/142#comment:2> core <http://tools.ietf.org/core/> From trac+core@trac.tools.ietf.org Tue May 3 13:45:01 2011 Return-Path: <trac+core@trac.tools.ietf.org> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE18E0895 for <core@ietfa.amsl.com>; Tue, 3 May 2011 13:45:01 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTfw7-Fok-x8 for <core@ietfa.amsl.com>; Tue, 3 May 2011 13:45:01 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 391C5E0891 for <core@ietf.org>; Tue, 3 May 2011 13:45:01 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from <trac+core@trac.tools.ietf.org>) id 1QHMSq-0007JV-2j; Tue, 03 May 2011 13:45:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" <trac+core@trac.tools.ietf.org> 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: Tue, 03 May 2011 20:45:00 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/141#comment:2 Message-ID: <066.a1f1496eb2ebd299bd1a41a92e551142@trac.tools.ietf.org> References: <057.b32d73525fa5927244dc93723f5db76b@trac.tools.ietf.org> X-Trac-Ticket-ID: 141 In-Reply-To: <057.b32d73525fa5927244dc93723f5db76b@trac.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+core@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] #141: DTLS and resource access control X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 03 May 2011 20:45:01 -0000 #141: DTLS and resource access control Comment(by cabo@…): From [324]: Various typos (re #139, #141, redundant example) -- ----------------------------------+----------------------------------------- Reporter: zach@… | Owner: cabo@… Type: protocol enhancement | Status: closed Priority: minor | Milestone: Component: coap | Version: Severity: - | Resolution: wontfix Keywords: | ----------------------------------+----------------------------------------- Ticket URL: </ticket/141#comment:2> core <http://tools.ietf.org/core/> From trac+core@trac.tools.ietf.org Tue May 3 13:45:01 2011 Return-Path: <trac+core@trac.tools.ietf.org> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D68F5E0891 for <core@ietfa.amsl.com>; Tue, 3 May 2011 13:45:01 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5wggTDl4k8Yc for <core@ietfa.amsl.com>; Tue, 3 May 2011 13:45:01 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 548F6E0894 for <core@ietf.org>; Tue, 3 May 2011 13:45:01 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from <trac+core@trac.tools.ietf.org>) id 1QHMSq-0007JR-0L; Tue, 03 May 2011 13:45:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" <trac+core@trac.tools.ietf.org> 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, cabo@tzi.org X-Trac-Project: core Date: Tue, 03 May 2011 20:44:59 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/139#comment:2 Message-ID: <066.91f5da1b165404d67684d671c5a6d2e0@trac.tools.ietf.org> References: <057.5bc247d3d7b326d31ef9028a964e0298@trac.tools.ietf.org> X-Trac-Ticket-ID: 139 In-Reply-To: <057.5bc247d3d7b326d31ef9028a964e0298@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@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] #139: Must-implement cipher suites X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 03 May 2011 20:45:01 -0000 #139: Must-implement cipher suites Comment(by cabo@…): From [324]: Various typos (re #139, #141, redundant example) -- ----------------------------------+----------------------------------------- Reporter: zach@… | Owner: zach@… Type: protocol enhancement | Status: closed Priority: minor | Milestone: Component: coap | Version: Severity: - | Resolution: fixed Keywords: | ----------------------------------+----------------------------------------- Ticket URL: </ticket/139#comment:2> core <http://tools.ietf.org/core/> From paduffy@cisco.com Tue May 3 13:48:47 2011 Return-Path: <paduffy@cisco.com> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D96AE088C for <core@ietfa.amsl.com>; Tue, 3 May 2011 13:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id whSdhdJV8r+w for <core@ietfa.amsl.com>; Tue, 3 May 2011 13:48:46 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 93375E069A for <core@ietf.org>; Tue, 3 May 2011 13:48:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paduffy@cisco.com; l=5120; q=dns/txt; s=iport; t=1304455725; x=1305665325; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=F2pzl1mJBeaK3RUL23Ug1FCjk6JEhh/dyyOfwkgUCew=; b=JdpL7i82+NfPqgyODPuGW44fBueIQ1TElE4djrF/dRokCpvJz6wRQfIX yEqBiQp8Rni+BJBDm8Dmdmf6qO0NhBgouVHNNOUjlIeLHOr5xEMa40FTg XEx0MHH0VAqqFua6Eav+13RfMtBT71KTPzR9bujVwFW9SLqMepZL4aoy7 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoAEAA5qwE2Q/khLgWdsb2JhbACmHBQBARYmJYhynmmCeA8BmxOGAgSPGIQaijQ X-IronPort-AV: E=Sophos;i="4.64,311,1301875200"; d="scan'208";a="86615677" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 03 May 2011 20:48:37 +0000 Received: from [161.44.66.248] (dhcp-161-44-66-248.cisco.com [161.44.66.248]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p43KmbGC006599; Tue, 3 May 2011 20:48:37 GMT Message-ID: <4DC06A24.4070803@cisco.com> Date: Tue, 03 May 2011 16:48:36 -0400 From: Paul Duffy <paduffy@cisco.com> Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Juho_V=E4h=E4-Herttua?= <juhovh@iki.fi> References: <057.ca63b30ac3e3ffdf9aad52c02fa3ebc8@trac.tools.ietf.org> <4D9AF230.6020805@labs.htt-consult.com> <CEB68E91-5CC6-451D-A581-8248189D9FA0@tzi.org> <4D9B0750.8010408@labs.htt-consult.com> <BANLkTi=qot=6wJU1OAFzpxm+2CzddHCyoA@mail.gmail.com> <BANLkTimPb5qM8y9dxdXb9dDm4Nq8_f1g3Q@mail.gmail.com> <99AAB914-B0BB-445B-8DCF-75B23D6A1D5E@tzi.org> <4D9F357C.8040708@labs.htt-consult.com> <BANLkTinUyxpRx9MZD5H7r6_x+Jqy5JKQpg@mail.gmail.com> <4DD1DBC7-6868-4246-9184-441B59F35D3D@iki.fi> <4DC05A34.5020703@cisco.com> <856CAFE5-6FCB-45BD-8A96-7194F19A57EE@iki.fi> In-Reply-To: <856CAFE5-6FCB-45BD-8A96-7194F19A57EE@iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: core@ietf.org Subject: Re: [core] #138: DTLS Clarification X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: paduffy@cisco.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 03 May 2011 20:48:47 -0000 > I think it is simply wrong that Zigbee SE2.0 security requirements direct the (general) specification of TLS cipher suites. To be more accurate, Zigbee SE 2 had to have a Suite B compliant solution. This due to US federal regulations re: cyber security requirements for critical infrastructure. > I have had trouble getting Suite B handshakes to run in real time on some devices, although problems have been mostly CPU bound not so much memory related. Does anyone have data of secp256r1 ECDH performance on target device classes? With well optimized libraries it might still be valid, but as mentioned the difference between secp224r1 and secp256r1 can be very big. > > > Juho > > > >> On 4/12/2011 2:25 AM, Juho Vähä-Herttua wrote: >>> On Apr 12, 2011, at 12:56 AM, Eric Rescorla wrote: >>>> On Fri, Apr 8, 2011 at 9:19 AM, Robert Moskowitz >>>> <rgm@labs.htt-consult.com> wrote: >>>>> On 04/07/2011 11:34 PM, Carsten Bormann wrote: >>>>> >>>>> On Apr 8, 2011, at 00:34, Robert Cragie wrote: >>>>> >>>>> In my experience both SHA-256 and HMAC are not expensive. >>>>> >>>>> Clearly SHA-256 (and especially HMAC) are not particularly expensive in >>>>> execution time when used as the PRF for establishing TLS connections. >>>>> >>>>> Still, on a highly constrained device, all other things being the same, it >>>>> would be preferable not to spend the code space if existing AES encryption >>>>> hardware (or even software) can be employed. >>>> The problem is that all else isn't equal here: we have a well-understood PRF >>>> that is already standardized. Not using that PRF reduces the general >>>> applicability >>>> of the proposed CCM modes. So, I think before making a change like that it >>>> would be better to demonstrate that the SHA-256 code is actually an important >>>> contributor to code size >>> I'm new on this list, but thought to express some motivation behind this. I implemented Robert's HIP DEX protocol where he had successfully removed cryptographic hash functions, and in the progress mentioned it would be easy to make TLS similar by just using static ECDH or ECDH_anon and CMAC based PRF, possibly even easier than implementing the HIP DEX itself. >>> >>> I can't speak for anyone else, but I think you're misunderstanding my idea here. Currently draft-mcgrew-tls-aes-ccm-eec-01 defines only ECDSA_ECDHE cipher suites (which are written as ECDHE_ECDSA in the draft by the way, that is completely wrong order) and if one wants to use them they have to have a cryptographic hash function available anyway for signing the ephemeral Diffie-Hellman keys. Changing the PRF to AES based has no point there. >>> >>> However, using a CMAC based PRF that doesn't have a hash function would be useful as an _optional_ feature in the ECDH_anon and PSK-ECDHE cipher suites, which are apparently not defined yet. Just like the AES-GCM cipher suites are defining two PRFs (SHA-256 and SHA-384 based HMAC), the AES-CCM modes that don't use signing could define an additional PRF for low class devices. I would probably need some data about SHA-256 code space, because I very much agree that it is not expensive in execution time, have to get back to it. But it's clear that already the lookup tables of SHA-256 take some amount of space. >>> >>> I should probably also contact David McGrew about the same AES-CCM draft related to the elliptic curves requirement. It has the sentence and a list "The ECDHE_ECDSA key exchange is performed as defined in [RFC4492] with the following additional stipulations", where I disagree with most of the additional stipulations. They greatly reduce the general applicability of the proposed CCM modes, as you just said. I'm especially worried about that secp256r1 and secp384r1 MUST be supported, because I have already demonstrated that my wireless sensor node is NOT capable of even performing a secp256r1 handshake. The secp224r1 on the other hand works reasonably well, difference between those two is huge because of the different pseudo-Mersenne primes used in modular reduction. >>> >>> Only reason why I see the two curves required there is NSA Suite B and maybe something that's happening in the Zigbee group, but that shouldn't affect the generalness of AES-CCM cipher suites in TLS. I remember writing about this to David earlier, but apparently it wasn't changed when the draft was updated. Before this kind of major problems with general applicability are solved, I don't know how relevant it is to fight about PRFs. But I don't think a CMAC PRF in addition to HMAC PRF in some cipher suites would be a bad idea at all. What was the motivation behind making the PRF selectable in TLS 1.2 if you are going to argue against cipher suites selecting a different PRF as an option anyway? >>> >>> >>> Juho >>> >>> _______________________________________________ >>> 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 cabo@tzi.org Tue May 3 15:40:49 2011 Return-Path: <cabo@tzi.org> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A539AE06AB for <core@ietfa.amsl.com>; Tue, 3 May 2011 15:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.169 X-Spam-Level: X-Spam-Status: No, score=-106.169 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qn9-yw0xxPYC for <core@ietfa.amsl.com>; Tue, 3 May 2011 15:40:49 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id B4260E0678 for <core@ietf.org>; Tue, 3 May 2011 15:40:48 -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 p43MeeHK029411 for <core@ietf.org>; Wed, 4 May 2011 00:40:40 +0200 (CEST) Received: from [192.168.217.112] (p5B3E613E.dip.t-dialin.net [91.62.97.62]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 284A3B15; Wed, 4 May 2011 00:40:40 +0200 (CEST) From: Carsten Bormann <cabo@tzi.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 4 May 2011 00:40:39 +0200 To: "core@ietf.org WG" <core@ietf.org> Message-Id: <B27AE304-B22E-4085-824C-768E746B53B8@tzi.org> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [core] New version of core-block: -03 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 03 May 2011 22:40:49 -0000 A new version of the CoRE Block specification (-03) is now available: http://tools.ietf.org/html/draft-ietf-core-block-03 This closes all outstanding editorial tickets, and makes the two = technical changes discussed in Prague: -- Remove the block size 2048 (leaving us with 16 to 1024) -- Split the Block option into Block1 (for request payloads) and Block2 = (for response payloads), cleaning up the rules and enabling block-wise = transfer of PUT/POST responses. The draft still references coap-05 for logistical reasons, but is meant = to work with the upcoming coap-06 as well. Gruesse, Carsten From zach@sensinode.com Tue May 3 15:54:25 2011 Return-Path: <zach@sensinode.com> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83AE4E06ED for <core@ietfa.amsl.com>; Tue, 3 May 2011 15:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9INzyUJw0Bd for <core@ietfa.amsl.com>; Tue, 3 May 2011 15:54:24 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 174B8E06A5 for <core@ietf.org>; Tue, 3 May 2011 15:54:23 -0700 (PDT) Received: from [192.168.0.102] (line-12346.dyn.kponet.fi [85.29.94.169]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id p43Mrjqt027819 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <core@ietf.org>; Wed, 4 May 2011 01:53:47 +0300 From: Zach Shelby <zach@sensinode.com> Content-Type: multipart/signed; boundary=Apple-Mail-230--261489033; protocol="application/pkcs7-signature"; micalg=sha1 Date: Wed, 4 May 2011 01:53:45 +0300 Message-Id: <4E03477E-B274-453F-BC29-61D203B0160E@sensinode.com> To: core WG <core@ietf.org> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [core] New version of CoAP available X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 03 May 2011 22:54:25 -0000 --Apple-Mail-230--261489033 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Version -06 of CoAP is now available: http://www.ietf.org/id/draft-ietf-core-coap-06.txt This version of the drafts closes all the open tickets that were agreed = upon in Prague, and in addition we managed to take some of Charles = Palmer's review comments into account as well (thanks!). =20 Change log: o HTTP mapping section improved with the minimal protocol standard text for CoAP-HTTP and HTTP-CoAP forward proxying (#137). o Eradicated percent-encoding by including one Uri-Query Option per &-delimited argument in a query. o Allowed RST message in reply to a NON message with unexpected token (#134). o Cache Invalidation only happens upon successful responses (#135). o 50% jitter added to the initial retransmit timer (#142). o DTLS cipher suites aligned with ZigBee IP, DTLS clarified as default CoAP security mechanism (#138, #139) o Added a minimal reference to draft-kivinen-ipsecme-ikev2-minimal (#140). o Clarified the comparison of UTF-8s (#136). o Minimized the initial media type registry (#101). --=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-230--261489033 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 ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDUwMzIyNTM0 NVowIwYJKoZIhvcNAQkEMRYEFJBvFMLsygg85SabY3iS8A9OxeYoMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAAT/qFZYiCcVPNU77TqLF9TTKJ3IIO64PLVFibPK5GuU5+GvQsCHqiNn lCCnNokXwXfXDYO8wc0b75Ff7+/HS/4Ux9t0au/YtTbbivPWK/dTorcmCmJL8TCJFXQ2Gez0ghpf SRdf8TYuKosiixJf32W/H3xDykopag+CM+9jTHZpHZ8ILshrycF5ntKjxwl6PCg65amy2SDcHJOV 76Tbgs6rUXwIaSCuakrRMkid0aSY9Y941yu0F36tHF14r/6tFpvpEPyUsxE/JvoPipv7Zh+kHw72 koB99Jv6VvGOA1OTyrs944QD2VC0sSXsgaS2RlLjt4YYguulWddF/JB81aUAAAAAAAA= --Apple-Mail-230--261489033-- From paduffy@cisco.com Wed May 4 08:00:30 2011 Return-Path: <paduffy@cisco.com> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1977E06FA for <core@ietfa.amsl.com>; Wed, 4 May 2011 08:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.524 X-Spam-Level: X-Spam-Status: No, score=-10.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1U1aj-U+i76h for <core@ietfa.amsl.com>; Wed, 4 May 2011 08:00:30 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 481BEE06B6 for <core@ietf.org>; Wed, 4 May 2011 08:00:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paduffy@cisco.com; l=403; q=dns/txt; s=iport; t=1304521230; x=1305730830; h=message-id:date:from:reply-to:mime-version:to:subject: content-transfer-encoding; bh=vgoqWnBqE63lPQAWmGww3AYA4+7AAhvxgV4Zu8+gISs=; b=YL1qhmJaohnb+b6TFb/daw0XeUbS29v7CYyoVP4CH5mSwrhSQlez6auC o1CH6A/MywhW715H87qDejQh/YycpzYyT7t4WkH+RTVAapxomQoifBXLu Fz0nwj9Hv8UJp6UsIJluqu4qR7IEj17J+5FDxdHOaD/HAf86Y10ekQR04 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFBpwU2rRDoJ/2dsb2JhbACmGHemFYEdgngPAZsshgcEjzWEHIo6 X-IronPort-AV: E=Sophos;i="4.64,314,1301875200"; d="scan'208";a="691808069" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-6.cisco.com with ESMTP; 04 May 2011 15:00:30 +0000 Received: from [161.44.66.248] (dhcp-161-44-66-248.cisco.com [161.44.66.248]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p44F0T9o026935 for <core@ietf.org>; Wed, 4 May 2011 15:00:29 GMT Message-ID: <4DC16A0D.5000407@cisco.com> Date: Wed, 04 May 2011 11:00:29 -0400 From: Paul Duffy <paduffy@cisco.com> Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: core <core@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [core] TOKEN option clarification X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: paduffy@cisco.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 04 May 2011 15:00:30 -0000 Folks, I'm not quite able to get to clarity re: normative requirements of the TOKEN option. There seems no MUST or SHOULD language about its inclusion in requests. My concern is that a client does not have prior knowledge if a request will result in a separate response, thus no guidance re: when it needs to include a TOKEN option. ? Feel free to point me to old threads Cheers From cabo@tzi.org Wed May 4 08:20:21 2011 Return-Path: <cabo@tzi.org> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68E9CE0750 for <core@ietfa.amsl.com>; Wed, 4 May 2011 08:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.176 X-Spam-Level: X-Spam-Status: No, score=-106.176 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TnZ6pmhiBmjD for <core@ietfa.amsl.com>; Wed, 4 May 2011 08:20:20 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 6D345E06B6 for <core@ietf.org>; Wed, 4 May 2011 08:20:20 -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 p44FK8b5008544; Wed, 4 May 2011 17:20:08 +0200 (CEST) Received: from [192.168.217.112] (p5B3E62EC.dip.t-dialin.net [91.62.98.236]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id C670AF4C; Wed, 4 May 2011 17:20:07 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann <cabo@tzi.org> In-Reply-To: <4DC16A0D.5000407@cisco.com> Date: Wed, 4 May 2011 17:20:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4FCD010E-8CEE-473A-90BD-D02379D2DB23@tzi.org> References: <4DC16A0D.5000407@cisco.com> To: paduffy@cisco.com X-Mailer: Apple Mail (2.1084) Cc: core <core@ietf.org> Subject: Re: [core] TOKEN option clarification X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 04 May 2011 15:20:21 -0000 On May 4, 2011, at 17:00, Paul Duffy wrote: > Folks, >=20 > I'm not quite able to get to clarity re: normative requirements of the = TOKEN option. There seems no MUST or SHOULD language about its = inclusion in requests. My concern is that a client does not have prior = knowledge if a request will result in a separate response, thus no = guidance re: when it needs to include a TOKEN option. 5.3. Request/Response Matching [...] The client SHOULD generate tokens in a way that tokens currently in use for a given source/destination pair are unique. (Note that a client can use the same token for any request if it uses a different source port number each time.) Some more text about this should be written; this could e.g. go into the = LWIG Guidance document. See slide 6 of http://www.ietf.org/proceedings/80/slides/lwig-1.pdf for = what this should cover. Gruesse, Carsten From paduffy@cisco.com Wed May 4 08:27:58 2011 Return-Path: <paduffy@cisco.com> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB36E0753 for <core@ietfa.amsl.com>; Wed, 4 May 2011 08:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.549 X-Spam-Level: X-Spam-Status: No, score=-10.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28gdFLbFytoC for <core@ietfa.amsl.com>; Wed, 4 May 2011 08:27:57 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by ietfa.amsl.com (Postfix) with ESMTP id 56715E0740 for <core@ietf.org>; Wed, 4 May 2011 08:27:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paduffy@cisco.com; l=1145; q=dns/txt; s=iport; t=1304522877; x=1305732477; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=CvQfVvVL0GRTyMTwLqDtotyqAs5fRumCOi9K1YU5eHM=; b=fSlqppC5gTZMw2ySafaRy4qI9qoRVaPLeuhx06jdo6flwEyBohM9997g xfqU3yVS3qVo5W/zFTwXhjD4gID+lMFZotxWQaRLNreOMpfG/NoW8px0V odI7CqMC5cEYuCFVD5tfXqrQcWis8hCm5YjMEBTQHfvTEeRCD9TkJD41L Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGRvwU2tJV2c/2dsb2JhbACmGXenNoJ4DwGbLIYHBI81hByKOg X-IronPort-AV: E=Sophos;i="4.64,314,1301875200"; d="scan'208";a="355450683" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by sj-iport-5.cisco.com with ESMTP; 04 May 2011 15:27:56 +0000 Received: from [161.44.66.248] (dhcp-161-44-66-248.cisco.com [161.44.66.248]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p44FRuQ6014495; Wed, 4 May 2011 15:27:56 GMT Message-ID: <4DC1707C.5070504@cisco.com> Date: Wed, 04 May 2011 11:27:56 -0400 From: Paul Duffy <paduffy@cisco.com> Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Carsten Bormann <cabo@tzi.org> References: <4DC16A0D.5000407@cisco.com> <4FCD010E-8CEE-473A-90BD-D02379D2DB23@tzi.org> In-Reply-To: <4FCD010E-8CEE-473A-90BD-D02379D2DB23@tzi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: core <core@ietf.org> Subject: Re: [core] TOKEN option clarification X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: paduffy@cisco.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 04 May 2011 15:27:58 -0000 Thanks Carsten, I reviewed the deck, still not clear, Seems a few normative statement re: TOKEN usage in requests and responses is needed. On 5/4/2011 11:20 AM, Carsten Bormann wrote: > On May 4, 2011, at 17:00, Paul Duffy wrote: > >> Folks, >> >> I'm not quite able to get to clarity re: normative requirements of the TOKEN option. There seems no MUST or SHOULD language about its inclusion in requests. My concern is that a client does not have prior knowledge if a request will result in a separate response, thus no guidance re: when it needs to include a TOKEN option. > 5.3. Request/Response Matching > > [...] > > The client SHOULD generate tokens in a way that tokens currently in > use for a given source/destination pair are unique. (Note that a > client can use the same token for any request if it uses a different > source port number each time.) > > Some more text about this should be written; this could e.g. go into the LWIG Guidance document. > See slide 6 of http://www.ietf.org/proceedings/80/slides/lwig-1.pdf for what this should cover. > > Gruesse, Carsten > > From paduffy@cisco.com Wed May 4 08:34:21 2011 Return-Path: <paduffy@cisco.com> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C09DE07AD for <core@ietfa.amsl.com>; Wed, 4 May 2011 08:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.561 X-Spam-Level: X-Spam-Status: No, score=-10.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KgjcfXSiF2T1 for <core@ietfa.amsl.com>; Wed, 4 May 2011 08:34:20 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB77E06E4 for <core@ietf.org>; Wed, 4 May 2011 08:34:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paduffy@cisco.com; l=97; q=dns/txt; s=iport; t=1304523260; x=1305732860; h=message-id:date:from:reply-to:mime-version:to:subject: content-transfer-encoding; bh=C4FaznqC4uUE4SWd+XIqlILShvBDcH9xlEgDyWJpNHk=; b=eQoqjZqbS3SaFlhqk1aXy8Nnd+TaVf+R0HH0H7/FP6i7+RR2JRnd9dAi nm9sAgx3pP05f5ySiz8znbP5cBzPcvufklczYYHcUoHsk8erB6VlJPmtO eyUG5uN1OX17ZK2ty5CkMF1E4pFFMv+KL3Jyhk4G8mfO3B5VF9sT6Yghc M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABVxwU2rRDoJ/2dsb2JhbACmGXeIa50xgR2CeA8Bmy+GBwSPNYQcijo X-IronPort-AV: E=Sophos;i="4.64,314,1301875200"; d="scan'208";a="308272797" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 04 May 2011 15:34:19 +0000 Received: from [161.44.66.248] (dhcp-161-44-66-248.cisco.com [161.44.66.248]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p44FYJ1J030993 for <core@ietf.org>; Wed, 4 May 2011 15:34:19 GMT Message-ID: <4DC171FB.9090708@cisco.com> Date: Wed, 04 May 2011 11:34:19 -0400 From: Paul Duffy <paduffy@cisco.com> Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: core <core@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [core] How is the TOKEN option mapped between HTTP and COAP? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: paduffy@cisco.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 04 May 2011 15:34:21 -0000 Ideally this would be carried opaquely, end to end, through a request/response exchange. ? From pabigot@gmail.com Wed May 4 08:36:24 2011 Return-Path: <pabigot@gmail.com> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B20FE06E4 for <core@ietfa.amsl.com>; Wed, 4 May 2011 08:36:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cMzVIDuQfwlI for <core@ietfa.amsl.com>; Wed, 4 May 2011 08:36:23 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id AAAD1E0792 for <core@ietf.org>; Wed, 4 May 2011 08:36:23 -0700 (PDT) Received: by qwc23 with SMTP id 23so976784qwc.31 for <core@ietf.org>; Wed, 04 May 2011 08:36:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=JoyjuYa7KqiIADZnB6gJxYeDv3Y1+kMsU5aMMbENKcw=; b=gSyLlCzfk5f9bw2I3UP+W3BcyGcgYzjnz16OIvRhNz3tPGRsFBYaAz8F74FH7qOzq2 3hgXAjDg0MSPMw/AM8w8fF+codgVf8MzxXmgjMAIL8pDjQzx0hgIbEftCjxjAbH4POEC IHHq3pS5EHktsVjY9F8f0yhnhIQbsO2v3eSiI= 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=Ga5xjuVGR2rgV5RtRRJh04u/0+BAxt/+Wzt3VovybrbUqwRFoVORtuzVuldyiku5mh eEHjVIl4yvBl9IuCeSkPrf6iG7JJuCHzo+9NTBZGw+RfFoZE9HqQSA/maSJCkIKdN7I4 1lcHhMyqdAY+tFY3XxBqC7wuLXxedylBsoCcI= MIME-Version: 1.0 Received: by 10.52.110.70 with SMTP id hy6mr1628099vdb.21.1304523381509; Wed, 04 May 2011 08:36:21 -0700 (PDT) Sender: pabigot@gmail.com Received: by 10.52.107.196 with HTTP; Wed, 4 May 2011 08:36:21 -0700 (PDT) In-Reply-To: <4DC16A0D.5000407@cisco.com> References: <4DC16A0D.5000407@cisco.com> Date: Wed, 4 May 2011 10:36:21 -0500 X-Google-Sender-Auth: mBbu4Oo4NuqqPR_7j--ji6A1Pjo Message-ID: <BANLkTi=sjWcfQqHt7dNHd_d-LNeybLbTcg@mail.gmail.com> From: Peter Bigot <bigotp@acm.org> To: paduffy@cisco.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: core <core@ietf.org> Subject: Re: [core] TOKEN option clarification X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 04 May 2011 15:36:24 -0000 You might find material of interest in http://www.ietf.org/mail-archive/web/core/current/msg01603.html and related discussion. Peter On Wed, May 4, 2011 at 10:00 AM, Paul Duffy <paduffy@cisco.com> wrote: > Folks, > > I'm not quite able to get to clarity re: normative requirements of the TO= KEN > option. =A0There seems no MUST or SHOULD language about its inclusion in > requests. =A0My concern is that a client does not have prior knowledge if= a > request will result in a separate response, thus no guidance re: when it > needs to =A0include a TOKEN option. > > ? > > Feel free to point me to old threads > > Cheers > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From cabo@tzi.org Wed May 4 08:38:05 2011 Return-Path: <cabo@tzi.org> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78752E0792 for <core@ietfa.amsl.com>; Wed, 4 May 2011 08:38:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.182 X-Spam-Level: X-Spam-Status: No, score=-106.182 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CkxjLantWuad for <core@ietfa.amsl.com>; Wed, 4 May 2011 08:38:04 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 64B2FE06E4 for <core@ietf.org>; Wed, 4 May 2011 08:38:03 -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 p44Fbsjb014399; Wed, 4 May 2011 17:37:54 +0200 (CEST) Received: from [192.168.217.112] (p5B3E62EC.dip.t-dialin.net [91.62.98.236]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 0EE9DF5E; Wed, 4 May 2011 17:37:53 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann <cabo@tzi.org> In-Reply-To: <4DC1707C.5070504@cisco.com> Date: Wed, 4 May 2011 17:37:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <59F6A082-37F5-4D88-B23C-B8FC6AD4EC67@tzi.org> References: <4DC16A0D.5000407@cisco.com> <4FCD010E-8CEE-473A-90BD-D02379D2DB23@tzi.org> <4DC1707C.5070504@cisco.com> To: paduffy@cisco.com X-Mailer: Apple Mail (2.1084) Cc: core <core@ietf.org> Subject: Re: [core] TOKEN option clarification X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 04 May 2011 15:38:05 -0000 On May 4, 2011, at 17:27, Paul Duffy wrote: > Seems a few normative statement re: TOKEN usage in requests and = responses is needed. But that's right there in the section of 5.3 I cited (see also 5.10.1). What am I missing? Note that Token has a default value, so indeed you don't have to include = it if the actual value matches the default value. The additional text that I think might be useful would explain = implementation strategies. Gruesse, Carsten From cabo@tzi.org Wed May 4 08:45:30 2011 Return-Path: <cabo@tzi.org> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43695E0794 for <core@ietfa.amsl.com>; Wed, 4 May 2011 08:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.187 X-Spam-Level: X-Spam-Status: No, score=-106.187 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gHJ5-cVRh4aP for <core@ietfa.amsl.com>; Wed, 4 May 2011 08:45:29 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 38037E06E4 for <core@ietf.org>; Wed, 4 May 2011 08:45:28 -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 p44FjJ3I017283; Wed, 4 May 2011 17:45:19 +0200 (CEST) Received: from [192.168.217.112] (p5B3E62EC.dip.t-dialin.net [91.62.98.236]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 0749FF6B; Wed, 4 May 2011 17:45:18 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann <cabo@tzi.org> In-Reply-To: <4DC171FB.9090708@cisco.com> Date: Wed, 4 May 2011 17:45:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <78E5CCF5-4DA3-40C3-8398-892B9F7D8EAC@tzi.org> References: <4DC171FB.9090708@cisco.com> To: paduffy@cisco.com X-Mailer: Apple Mail (2.1084) Cc: core <core@ietf.org> Subject: Re: [core] How is the TOKEN option mapped between HTTP and COAP? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 04 May 2011 15:45:30 -0000 On May 4, 2011, at 17:34, Paul Duffy wrote: > Ideally this would be carried opaquely, end to end, through a = request/response exchange. HTTP does not need, nor have, a concept like CoAP's Token option, as = HTTP's request/response matching is implicit in the order of messages in = the TCP connection. =20 CoAP does not have a connection (apart from the ephemeral binding in the = message ID of a CON/ACK pair), so it needs Token once a simple CON/ACK = pair does not suffice. But there is no end-to-end significance of the = Token. In summary, there is no need for a HTTP/CoAP mapping of Tokens, as = Tokens are always handled fully locally in each CoAP leg. Gruesse, Carsten From paduffy@cisco.com Wed May 4 08:54:48 2011 Return-Path: <paduffy@cisco.com> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93377E0786 for <core@ietfa.amsl.com>; Wed, 4 May 2011 08:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.569 X-Spam-Level: X-Spam-Status: No, score=-10.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4n9VdIXkd1Aj for <core@ietfa.amsl.com>; Wed, 4 May 2011 08:54:47 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by ietfa.amsl.com (Postfix) with ESMTP id BEBE2E0750 for <core@ietf.org>; Wed, 4 May 2011 08:54:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paduffy@cisco.com; l=879; q=dns/txt; s=iport; t=1304524487; x=1305734087; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=2XusB9X4DHXA3MZjonwpnBNfyOCeL2FL2oRqOuEC+PU=; b=bTRgceGs7STmnXnyeYoXqj0S6/x8pqf2HX8Vp1XXgqNBIK00cISJSP4Z TmVfEE+L/ia61//sEKerTU5wkYbR+F5SiE4FMZioZQGiAqmDFNimlC44U 6xkcf+QOs2fZjIvkL8/qXW8x37HkawAKOTq6VGWlYF5FUL05Nf+pQR+L0 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGt2wU2tJXHA/2dsb2JhbACmGneIcp4zgngPAZsvhgcEjzWEHIo6 X-IronPort-AV: E=Sophos;i="4.64,315,1301875200"; d="scan'208";a="355452911" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by sj-iport-5.cisco.com with ESMTP; 04 May 2011 15:54:47 +0000 Received: from [161.44.66.248] (dhcp-161-44-66-248.cisco.com [161.44.66.248]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id p44FskWg027436; Wed, 4 May 2011 15:54:46 GMT Message-ID: <4DC176C6.6000303@cisco.com> Date: Wed, 04 May 2011 11:54:46 -0400 From: Paul Duffy <paduffy@cisco.com> Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Carsten Bormann <cabo@tzi.org> References: <4DC16A0D.5000407@cisco.com> <4FCD010E-8CEE-473A-90BD-D02379D2DB23@tzi.org> <4DC1707C.5070504@cisco.com> <59F6A082-37F5-4D88-B23C-B8FC6AD4EC67@tzi.org> In-Reply-To: <59F6A082-37F5-4D88-B23C-B8FC6AD4EC67@tzi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: core <core@ietf.org> Subject: Re: [core] TOKEN option clarification X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: paduffy@cisco.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 04 May 2011 15:54:48 -0000 On 5/4/2011 11:37 AM, Carsten Bormann wrote: > On May 4, 2011, at 17:27, Paul Duffy wrote: > >> Seems a few normative statement re: TOKEN usage in requests and responses is needed. > But that's right there in the section of 5.3 I cited (see also 5.10.1). > What am I missing? I see it now. But let me suggest a change. Second line of 5.10.1 "Every request MUST contain a client-generated token ..." > Note that Token has a default value, so indeed you don't have to include it if the actual value matches the default value. Non inclusion and default TOKEN value smells like trouble. It opens up the possibility of multiple outstanding requests getting incorrectly matched up to responses sharing the same default TOKEN value. > The additional text that I think might be useful would explain implementation strategies. > > Gruesse, Carsten > > From paduffy@cisco.com Wed May 4 09:00:13 2011 Return-Path: <paduffy@cisco.com> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2CA2E07CA for <core@ietfa.amsl.com>; Wed, 4 May 2011 09:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.574 X-Spam-Level: X-Spam-Status: No, score=-10.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYrbrrVKUwaR for <core@ietfa.amsl.com>; Wed, 4 May 2011 09:00:12 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id B85DBE0794 for <core@ietf.org>; Wed, 4 May 2011 08:59:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paduffy@cisco.com; l=955; q=dns/txt; s=iport; t=1304524796; x=1305734396; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=pn5rZQmvscstINAuQWVco64akhPzIbR479uaVrqlt3s=; b=jzsk5EH5ODemAUeXPHLOPAogcdHCe+3rlVgSMdsLjljGv35jMSpjXaJC udjOslwo94SNp1uJ7w/YfNy6iUMGndkTIIVIS+BTxXtRLjDxYwA1EY/7g O9FxwTpaL+EaWzymsRW+c5uOpji4QiE7bGnAQUYTDD5ZBeRnxdrfH2Rff c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGN3wU2tJXG+/2dsb2JhbACmGneIcp4jgngPAZsuhgcEjzWEHIo6 X-IronPort-AV: E=Sophos;i="4.64,315,1301875200"; d="scan'208";a="691850372" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by sj-iport-6.cisco.com with ESMTP; 04 May 2011 15:59:56 +0000 Received: from [161.44.66.248] (dhcp-161-44-66-248.cisco.com [161.44.66.248]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p44FxtTv023492; Wed, 4 May 2011 15:59:55 GMT Message-ID: <4DC177FB.3080909@cisco.com> Date: Wed, 04 May 2011 11:59:55 -0400 From: Paul Duffy <paduffy@cisco.com> Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Carsten Bormann <cabo@tzi.org> References: <4DC171FB.9090708@cisco.com> <78E5CCF5-4DA3-40C3-8398-892B9F7D8EAC@tzi.org> In-Reply-To: <78E5CCF5-4DA3-40C3-8398-892B9F7D8EAC@tzi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: core <core@ietf.org> Subject: Re: [core] How is the TOKEN option mapped between HTTP and COAP? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: paduffy@cisco.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 04 May 2011 16:00:13 -0000 On 5/4/2011 11:45 AM, Carsten Bormann wrote: > On May 4, 2011, at 17:34, Paul Duffy wrote: > >> Ideally this would be carried opaquely, end to end, through a request/response exchange. > HTTP does not need, nor have, a concept like CoAP's Token option, as HTTP's request/response matching is implicit in the order of messages in the TCP connection. Agreed, which is why I'm asking. > > > CoAP does not have a connection (apart from the ephemeral binding in the message ID of a CON/ACK pair), so it needs Token once a simple CON/ACK pair does not suffice. Agreed, TOKEN conceptually implements an application "session" > But there is no end-to-end significance of the Token. > > In summary, there is no need for a HTTP/CoAP mapping of Tokens, as Tokens are always handled fully locally in each CoAP leg. But there does appear the need for a stateful mapping of the TOKEN to HTTP connection, correct? > Gruesse, Carsten > > From cabo@tzi.org Wed May 4 09:34:10 2011 Return-Path: <cabo@tzi.org> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19108E07B0 for <core@ietfa.amsl.com>; Wed, 4 May 2011 09:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.192 X-Spam-Level: X-Spam-Status: No, score=-106.192 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2lu64u4+Uep for <core@ietfa.amsl.com>; Wed, 4 May 2011 09:34:09 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [134.102.201.18]) by ietfa.amsl.com (Postfix) with ESMTP id 32B96E0688 for <core@ietf.org>; Wed, 4 May 2011 09:34:08 -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 p44GXchE004610; Wed, 4 May 2011 18:33:38 +0200 (CEST) Received: from [192.168.217.112] (p5B3E62EC.dip.t-dialin.net [91.62.98.236]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 1782BF99; Wed, 4 May 2011 18:33:38 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann <cabo@tzi.org> In-Reply-To: <4DC177FB.3080909@cisco.com> Date: Wed, 4 May 2011 18:33:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8DE95485-C159-45E0-9442-8586EF9179DF@tzi.org> References: <4DC171FB.9090708@cisco.com> <78E5CCF5-4DA3-40C3-8398-892B9F7D8EAC@tzi.org> <4DC177FB.3080909@cisco.com> To: paduffy@cisco.com X-Mailer: Apple Mail (2.1084) Cc: core <core@ietf.org> Subject: Re: [core] How is the TOKEN option mapped between HTTP and COAP? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 04 May 2011 16:34:10 -0000 On May 4, 2011, at 17:59, Paul Duffy wrote: > But there does appear the need for a stateful mapping of the TOKEN to = HTTP connection, correct? Yes, but that is an implementation issue. Once you implement both protocols, there is very little remaining to = talk about wrt the mapping aspect. (Originally, we were trying to have more details about possible = implementations in the mapping sections, but that grew out of hand = quickly. It appears to be much better for a spec to say just what needs = to be said. We can always add implementation guidance documents later.) Gruesse, Carsten From cabo@tzi.org Wed May 4 09:49:56 2011 Return-Path: <cabo@tzi.org> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F923E0753 for <core@ietfa.amsl.com>; Wed, 4 May 2011 09:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.196 X-Spam-Level: X-Spam-Status: No, score=-106.196 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Z1ZGnUHKKOZ for <core@ietfa.amsl.com>; Wed, 4 May 2011 09:49:55 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [134.102.201.18]) by ietfa.amsl.com (Postfix) with ESMTP id BED60E0684 for <core@ietf.org>; Wed, 4 May 2011 09:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id p44GnMvB008597; Wed, 4 May 2011 18:49:22 +0200 (CEST) Received: from [192.168.217.112] (p5B3E62EC.dip.t-dialin.net [91.62.98.236]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id AEF51FA8; Wed, 4 May 2011 18:49:22 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann <cabo@tzi.org> In-Reply-To: <4DC176C6.6000303@cisco.com> Date: Wed, 4 May 2011 18:49:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8BD522CB-8BF8-4023-9A9A-62232E289C76@tzi.org> References: <4DC16A0D.5000407@cisco.com> <4FCD010E-8CEE-473A-90BD-D02379D2DB23@tzi.org> <4DC1707C.5070504@cisco.com> <59F6A082-37F5-4D88-B23C-B8FC6AD4EC67@tzi.org> <4DC176C6.6000303@cisco.com> To: paduffy@cisco.com X-Mailer: Apple Mail (2.1084) Cc: core <core@ietf.org> Subject: Re: [core] TOKEN option clarification X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 04 May 2011 16:49:56 -0000 > I see it now. But let me suggest a change. Second line of 5.10.1 >=20 > "Every request MUST contain a client-generated token ..." It is impossible not to include a Token as that option has a default = value. So independent of whether you include the actual option, you do have a = Token. > Non inclusion and default TOKEN value smells like trouble. It opens = up the possibility of multiple outstanding requests getting incorrectly = matched up to responses sharing the same default TOKEN value. If that bothers you :-), don't have multiple requests outstanding with = the same Token on the same socketpair (pair of IP address/port number = pairs), i.e., vary the source port number, the Token, or both. (Note that if the requests are exactly the same, you may not even care = -- that is clearly the less likely case, but that is why the language in = 5.3 is a SHOULD.) Gruesse, Carsten From paduffy@cisco.com Wed May 4 10:05:51 2011 Return-Path: <paduffy@cisco.com> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F96EE07C9 for <core@ietfa.amsl.com>; Wed, 4 May 2011 10:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.578 X-Spam-Level: X-Spam-Status: No, score=-10.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wp9vsyNb+J+c for <core@ietfa.amsl.com>; Wed, 4 May 2011 10:05:50 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id E7B2AE0684 for <core@ietf.org>; Wed, 4 May 2011 10:05:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paduffy@cisco.com; l=855; q=dns/txt; s=iport; t=1304528750; x=1305738350; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=zrtuNI2HLvCE0ag6pw8RO8fTXNyChNJTe+AfmTGTQno=; b=f8q93jnQR7Uw+YIGBidoqfZZ7n0jM7zXQ12JmxfttTkcihojKnWuUwsM Twuu42T3AznV2ZMhyExHa7rJc4Yhtaat8k3xqgyXTZ0sErqSJ2oIP9wpm pCOB/+i2Y/aWVBkg/4yw3Wh4g2HIJQCouv3MD/IOWqmjFQWg3JFdyh2if w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJ6GwU2rRDoI/2dsb2JhbACmHHeIcp19gngPAZsxhgcEjzWEHIo6 X-IronPort-AV: E=Sophos;i="4.64,315,1301875200"; d="scan'208";a="691894155" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-6.cisco.com with ESMTP; 04 May 2011 17:05:50 +0000 Received: from [161.44.66.248] (dhcp-161-44-66-248.cisco.com [161.44.66.248]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p44H5nMe021490; Wed, 4 May 2011 17:05:49 GMT Message-ID: <4DC1876D.80302@cisco.com> Date: Wed, 04 May 2011 13:05:49 -0400 From: Paul Duffy <paduffy@cisco.com> Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Carsten Bormann <cabo@tzi.org> References: <4DC16A0D.5000407@cisco.com> <4FCD010E-8CEE-473A-90BD-D02379D2DB23@tzi.org> <4DC1707C.5070504@cisco.com> <59F6A082-37F5-4D88-B23C-B8FC6AD4EC67@tzi.org> <4DC176C6.6000303@cisco.com> <8BD522CB-8BF8-4023-9A9A-62232E289C76@tzi.org> In-Reply-To: <8BD522CB-8BF8-4023-9A9A-62232E289C76@tzi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: core <core@ietf.org> Subject: Re: [core] TOKEN option clarification X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: paduffy@cisco.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 04 May 2011 17:05:51 -0000 >> Non inclusion and default TOKEN value smells like trouble. It opens up the possibility of multiple outstanding requests getting incorrectly matched up to responses sharing the same default TOKEN value. > If that bothers you :-), don't have multiple requests outstanding with the same Token on the same socketpair (pair of IP address/port number pairs), i.e., vary the source port number, the Token, or both. > (Note that if the requests are exactly the same, you may not even care -- that is clearly the less likely case, but that is why the language in 5.3 is a SHOULD.) Recommend then adding normative requirement prohibiting multiple outstanding requests w/ same TOKEN on same socket (accommodating conflicting default TOKENs) OR simply require explicit TOKEN per request (seems the simpler way to go). > Gruesse, Carsten > > From fluffy@cisco.com Wed May 4 10:29:11 2011 Return-Path: <fluffy@cisco.com> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E053E07CE for <core@ietfa.amsl.com>; Wed, 4 May 2011 10:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.602 X-Spam-Level: X-Spam-Status: No, score=-110.602 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eKyVXgfDqbWB for <core@ietfa.amsl.com>; Wed, 4 May 2011 10:29:10 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id E66C3E0695 for <core@ietf.org>; Wed, 4 May 2011 10:29:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=3491; q=dns/txt; s=iport; t=1304530150; x=1305739750; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=YXwaGxcCHdWoNr5aE87hnRqTQgxR075tLknOVcAG+YA=; b=EB7k0Vxq6jxZP5JpTZ30n6QpVTdnC0/Yo0seTWvPIB52WSslJNfG+p2L BQQGtGDWk60/FsKrOMo718lc+t46DI65Kf/Q/xTw9jFbN922/vCdVhRkj sIe4Zk6mXkm0ZFd3ksSt20svqw8gzSAIa/R1hOpMIX0sEZaNSgFO3RA3Y U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHqMwU2rRDoH/2dsb2JhbACmHHelRIEdnjmGBwSGL4kGhByKPQ X-IronPort-AV: E=Sophos;i="4.64,315,1301875200"; d="scan'208";a="691909342" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-6.cisco.com with ESMTP; 04 May 2011 17:29:10 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p44HT9sJ007802 for <core@ietf.org>; Wed, 4 May 2011 17:29:10 GMT From: Cullen Jennings <fluffy@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 4 May 2011 11:29:09 -0600 Message-Id: <9CF83338-EB7C-4831-8A44-8DEEF0C42D54@cisco.com> To: core WG <core@ietf.org> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [core] Comments on draft-ietf-core-link-format-04 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 04 May 2011 17:29:11 -0000 Mediums sized issue: I'm confused by the Encoding considerations in link-format-04 which are = listed as "8bit (UTF-8 (NFC))". I suspect this should just say "binary". = If this is really NFC, then does it mean constrained nodes need to do = the canonicalization? Most places in the draft it makes it clear that = you processes the data as binary data. Every implementation I have = seen treats this as binary data - even section 4.1 describes a bitwise = identical comparison. We also have the issue that RFC 2045 says=20 "8bit data" refers to data that is all represented as relatively short lines with 998 octets or less between CRLF line separation and "Binary data" refers to data where any sequence of octets whatsoever is allowed. I think what we have here is binary data which seems fine. This is meant = to be be machine readable and it's not like we have to enforce that no = lines is longer than 1000 octets. Yes, many of the strings in the binary = blob of data may happen to be UTF-8 strings that are even in Normalized = Form C but unless we get more specific about when and where this gets = normalized I don't see how specifying this is NFC data helps. In fact = most, if not all, of this is from a far more restricted grammar than = UTF-8 NFC.=20 Related to this, where it says the CoRE link format MUST be in UTF-8 and = SHOULD be NFC. This seems wrong unless we are updating RFC5988. RFC5988 = makes it clear the links are as defined in rfc3986. We don't need to say = any more or less than RFC5988. Unless someone can tell me how my = implementation and interoperability changes by specifying UTF-8 and NFC, = I'd like to see that removed. The phrase "MUST be compared as strings" = is pretty vague when discussing UTF-8 strings. If people disagree here, = I'm going to argue that unicode has a perfectly good symbol for angstrom = and if someone wants to use that, I think they should be able to use it. = Given this is format is for machine readability, an angstrom is not the = same as a character that might look the same when printed on paper and = that difference should not be lost. =20 All in all, the documents this depends on, such as 5988 deal with the = right level of using UTF-8. This draft should just be silent on the = issue and you can probably remove all mention of UTF-8. Regardless of = the UTF-8 issues, it seems the media type registration should have = binary not 8bit.=20 Minor Issues: The ABNF you are using for integer allows leading zero. Not sure you = want that if you don't want to deal with if 041 matches 41.=20 Has an review request been sent to ietf-types? I could not find one. You = could even put the data of the review request was sent in the draft with = a note to the RFC editor to remove that before publication. That makes = things easier for future reviews as this goes through LC and IESG.=20 It's never 100% clear to me how to till out the templates but I suspect = that the template should have an=20 Author: Zach Shelby <your email> and a=20 Change controller: IETF CORE Working Group delegated from the IESG. Don't worry - if we get that wrong, it will get fixed when IANA does = their LC review.=20 We should consider removing section 7.4 and this draft is ahead of coap. = The coap draft can just register this type with no need to mention it = here.=20 Cullen <with my individual contributor hat on>= From cabo@tzi.org Wed May 4 13:14:43 2011 Return-Path: <cabo@tzi.org> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE21E07B5 for <core@ietfa.amsl.com>; Wed, 4 May 2011 13:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.199 X-Spam-Level: X-Spam-Status: No, score=-106.199 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LLbgP7SBPh6G for <core@ietfa.amsl.com>; Wed, 4 May 2011 13:14:42 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id B0424E06DE for <core@ietf.org>; Wed, 4 May 2011 13:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id p44KEUfd006657; Wed, 4 May 2011 22:14:30 +0200 (CEST) Received: from [192.168.217.101] (p5B3E62EC.dip.t-dialin.net [91.62.98.236]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id E219861; Wed, 4 May 2011 22:14:29 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann <cabo@tzi.org> In-Reply-To: <4DC1876D.80302@cisco.com> Date: Wed, 4 May 2011 22:14:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <900CB1F6-3E11-485B-985D-FDF4EB45BC17@tzi.org> References: <4DC16A0D.5000407@cisco.com> <4FCD010E-8CEE-473A-90BD-D02379D2DB23@tzi.org> <4DC1707C.5070504@cisco.com> <59F6A082-37F5-4D88-B23C-B8FC6AD4EC67@tzi.org> <4DC176C6.6000303@cisco.com> <8BD522CB-8BF8-4023-9A9A-62232E289C76@tzi.org> <4DC1876D.80302@cisco.com> To: paduffy@cisco.com X-Mailer: Apple Mail (2.1084) Cc: core <core@ietf.org> Subject: Re: [core] TOKEN option clarification X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 04 May 2011 20:14:43 -0000 > Recommend then adding normative requirement prohibiting multiple = outstanding requests w/ same TOKEN on same socket (accommodating = conflicting default TOKENs) Yes. That's why 5.3 says: The client SHOULD generate tokens in a way that tokens currently in use for a given source/destination pair are unique. (Note that a client can use the same token for any request if it uses a different source port number each time.) and 5.10.1 concurs: A token is intended for use as a client-local identifier for differentiating between concurrent requests. A client SHOULD generate tokens in a way that tokens currently in use for a given source/destination pair are unique. An end-point receiving a token MUST treat it as opaque and make no assumptions about its format. Anything else we need to do? (Except maybe remove the redundancy, but I don't think that = single-sentence repetition hurts here.) > OR simply require explicit TOKEN per request (seems the simpler way to = go). If you mean explicit Token Option: That would be wrong, as many clients don't ever need anything but the = default value. Gruesse, Carsten From paduffy@cisco.com Wed May 4 13:49:01 2011 Return-Path: <paduffy@cisco.com> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3492E081B for <core@ietfa.amsl.com>; Wed, 4 May 2011 13:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.58 X-Spam-Level: X-Spam-Status: No, score=-10.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YtG3EspoJ8sO for <core@ietfa.amsl.com>; Wed, 4 May 2011 13:49:01 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by ietfa.amsl.com (Postfix) with ESMTP id 0253AE081A for <core@ietf.org>; Wed, 4 May 2011 13:49:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paduffy@cisco.com; l=1489; q=dns/txt; s=iport; t=1304542140; x=1305751740; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=ffoP9DE96tm1xKrH6mWRqGAFOXtPxeZo/Snn+TrA++Y=; b=NPaokQhkm19Rr8A+GJd7Sh9NxhVXsdfafQT6CPi8UQBzOsY3Q80kUZYg NS3jBjH1D1TK2i/R8TvbeycGT3Yo3763/Y6QwGkXMJ2/GROlSUpY2Oa5H N1lQoMO18T8eZnMZA842087+rTs17uMVrOAwy9TiRql9aObrIULIlnnhb 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJO7wU2tJV2d/2dsb2JhbACmHneoUoJ4DwGbKYYHBI81hByKOg X-IronPort-AV: E=Sophos;i="4.64,316,1301875200"; d="scan'208";a="355475547" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by sj-iport-5.cisco.com with ESMTP; 04 May 2011 20:48:52 +0000 Received: from [161.44.66.248] (dhcp-161-44-66-248.cisco.com [161.44.66.248]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id p44KmqU5017674; Wed, 4 May 2011 20:48:52 GMT Message-ID: <4DC1BBB4.5070603@cisco.com> Date: Wed, 04 May 2011 16:48:52 -0400 From: Paul Duffy <paduffy@cisco.com> Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Carsten Bormann <cabo@tzi.org> References: <4DC16A0D.5000407@cisco.com> <4FCD010E-8CEE-473A-90BD-D02379D2DB23@tzi.org> <4DC1707C.5070504@cisco.com> <59F6A082-37F5-4D88-B23C-B8FC6AD4EC67@tzi.org> <4DC176C6.6000303@cisco.com> <8BD522CB-8BF8-4023-9A9A-62232E289C76@tzi.org> <4DC1876D.80302@cisco.com> <900CB1F6-3E11-485B-985D-FDF4EB45BC17@tzi.org> In-Reply-To: <900CB1F6-3E11-485B-985D-FDF4EB45BC17@tzi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: core <core@ietf.org> Subject: Re: [core] TOKEN option clarification X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: paduffy@cisco.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 04 May 2011 20:49:01 -0000 Recommend addition of an explicit warning that the the default TOKEN value violates the normative requirements you cite below. Also, 5.3 SHOULD seems better stated as a MUST. Same for the SHOULD in 5.10.1 On 5/4/2011 4:14 PM, Carsten Bormann wrote: >> Recommend then adding normative requirement prohibiting multiple outstanding requests w/ same TOKEN on same socket (accommodating conflicting default TOKENs) > Yes. > > That's why 5.3 says: > > The client SHOULD generate tokens in a way that tokens currently in > use for a given source/destination pair are unique. (Note that a > client can use the same token for any request if it uses a different > source port number each time.) > > and 5.10.1 concurs: > > A token is intended for use as a client-local identifier for > differentiating between concurrent requests. A client SHOULD > generate tokens in a way that tokens currently in use for a given > source/destination pair are unique. An end-point receiving a token > MUST treat it as opaque and make no assumptions about its format. > > Anything else we need to do? > (Except maybe remove the redundancy, but I don't think that single-sentence repetition hurts here.) > >> OR simply require explicit TOKEN per request (seems the simpler way to go). > If you mean explicit Token Option: > That would be wrong, as many clients don't ever need anything but the default value. > > Gruesse, Carsten > > From cabo@tzi.org Wed May 4 14:20:27 2011 Return-Path: <cabo@tzi.org> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37F5BE07AA for <core@ietfa.amsl.com>; Wed, 4 May 2011 14:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.202 X-Spam-Level: X-Spam-Status: No, score=-106.202 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jiQKnqDnAa46 for <core@ietfa.amsl.com>; Wed, 4 May 2011 14:20:26 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 47C30E06C3 for <core@ietf.org>; Wed, 4 May 2011 14:20:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id p44LKG06023747; Wed, 4 May 2011 23:20:16 +0200 (CEST) Received: from [192.168.217.101] (p5B3E62EC.dip.t-dialin.net [91.62.98.236]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 5A6C988; Wed, 4 May 2011 23:20:16 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann <cabo@tzi.org> In-Reply-To: <4DC1BBB4.5070603@cisco.com> Date: Wed, 4 May 2011 23:20:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <CB094D9C-AC80-479B-AC6E-D979821313F2@tzi.org> References: <4DC16A0D.5000407@cisco.com> <4FCD010E-8CEE-473A-90BD-D02379D2DB23@tzi.org> <4DC1707C.5070504@cisco.com> <59F6A082-37F5-4D88-B23C-B8FC6AD4EC67@tzi.org> <4DC176C6.6000303@cisco.com> <8BD522CB-8BF8-4023-9A9A-62232E289C76@tzi.org> <4DC1876D.80302@cisco.com> <900CB1F6-3E11-485B-985D-FDF4EB45BC17@tzi.org> <4DC1BBB4.5070603@cisco.com> To: paduffy@cisco.com X-Mailer: Apple Mail (2.1084) Cc: core <core@ietf.org> Subject: Re: [core] TOKEN option clarification X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 04 May 2011 21:20:27 -0000 On May 4, 2011, at 22:48, Paul Duffy wrote: > Recommend addition of an explicit warning that the the default TOKEN = value violates the normative requirements you cite below. Whether it does or not depends on how many outstanding requests you have = per socketpair, that's why the existing text hinges on that number = instead of whether the value happens to be the default one. But yes, it probably doesn't hurt to add more explanatory text. (Except that we are already at 80 pages for a protocol that you can = implement in an afternoon.) > Also, 5.3 SHOULD seems better stated as a MUST. Same for the SHOULD = in 5.10.1 I don't have a strong opinion on that. (The servers don't break if clients don't actually do that. =20 So if the client has some other way to disambiguate...) RFC2119 defines SHOULD rather strongly already: 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. Gruesse, Carsten From paduffy@cisco.com Wed May 4 14:27:45 2011 Return-Path: <paduffy@cisco.com> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34B5DE07D3 for <core@ietfa.amsl.com>; Wed, 4 May 2011 14:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.582 X-Spam-Level: X-Spam-Status: No, score=-10.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Thi3SfK-K3k for <core@ietfa.amsl.com>; Wed, 4 May 2011 14:27:44 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 6E983E06A3 for <core@ietf.org>; Wed, 4 May 2011 14:27:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paduffy@cisco.com; l=1323; q=dns/txt; s=iport; t=1304544464; x=1305754064; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=x2dIrq5L2mMBbBagUw1vS7bm9cMXy78H4PfUKXpzyck=; b=Ce+yFDCW/BgaN2yhy1qNGAG+HIj+p0OHNwOYobkk5eAyZgSWHDyPyBG4 bf3fS4PGtb6OZbYmcQNf/spkBicWPy8GcvUFmorWy3Wp2b88Pl+eDBAy/ notz8D6W8v+txDRJ6fYQfSIM15aHORjQS1eq7yd94RyzvVui5EsEq3juk c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJTDwU2rRDoJ/2dsb2JhbACmHnepAoJ4DwGbJ4YHBI81hByKOg X-IronPort-AV: E=Sophos;i="4.64,316,1301875200"; d="scan'208";a="350514490" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-2.cisco.com with ESMTP; 04 May 2011 21:27:44 +0000 Received: from [161.44.66.248] (dhcp-161-44-66-248.cisco.com [161.44.66.248]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p44LRhHl005462; Wed, 4 May 2011 21:27:43 GMT Message-ID: <4DC1C4CF.7020504@cisco.com> Date: Wed, 04 May 2011 17:27:43 -0400 From: Paul Duffy <paduffy@cisco.com> Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Carsten Bormann <cabo@tzi.org> References: <4DC16A0D.5000407@cisco.com> <4FCD010E-8CEE-473A-90BD-D02379D2DB23@tzi.org> <4DC1707C.5070504@cisco.com> <59F6A082-37F5-4D88-B23C-B8FC6AD4EC67@tzi.org> <4DC176C6.6000303@cisco.com> <8BD522CB-8BF8-4023-9A9A-62232E289C76@tzi.org> <4DC1876D.80302@cisco.com> <900CB1F6-3E11-485B-985D-FDF4EB45BC17@tzi.org> <4DC1BBB4.5070603@cisco.com> <CB094D9C-AC80-479B-AC6E-D979821313F2@tzi.org> In-Reply-To: <CB094D9C-AC80-479B-AC6E-D979821313F2@tzi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: core <core@ietf.org> Subject: Re: [core] TOKEN option clarification X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: paduffy@cisco.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 04 May 2011 21:27:45 -0000 Keep it simple, understandable, and explicit. In the general case, IMO default TOKEN value is a problem. On 5/4/2011 5:20 PM, Carsten Bormann wrote: > On May 4, 2011, at 22:48, Paul Duffy wrote: > >> Recommend addition of an explicit warning that the the default TOKEN value violates the normative requirements you cite below. > Whether it does or not depends on how many outstanding requests you have per socketpair, that's why the existing text hinges on that number instead of whether the value happens to be the default one. > But yes, it probably doesn't hurt to add more explanatory text. > (Except that we are already at 80 pages for a protocol that you can implement in an afternoon.) > >> Also, 5.3 SHOULD seems better stated as a MUST. Same for the SHOULD in 5.10.1 > I don't have a strong opinion on that. > (The servers don't break if clients don't actually do that. > So if the client has some other way to disambiguate...) > > RFC2119 defines SHOULD rather strongly already: > 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there > may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course. > > Gruesse, Carsten > > > From paduffy@cisco.com Wed May 4 16:09:27 2011 Return-Path: <paduffy@cisco.com> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3D9FE0796 for <core@ietfa.amsl.com>; Wed, 4 May 2011 16:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.584 X-Spam-Level: X-Spam-Status: No, score=-10.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2wzM-xkCXV9U for <core@ietfa.amsl.com>; Wed, 4 May 2011 16:09:22 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 82500E07B7 for <core@ietf.org>; Wed, 4 May 2011 16:09:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paduffy@cisco.com; l=366; q=dns/txt; s=iport; t=1304550562; x=1305760162; h=message-id:date:from:reply-to:mime-version:to:subject: content-transfer-encoding; bh=u8gWofv2F4WkaaPQd0OlEKsfDc0cD67BHNdHHelHEfA=; b=gDt1aDZwWvTkwo+HrOWKmdSP2dwVtttK77oBi/qe58xvmjPZeGDKSing HlLqPsExiOfRF7bwOJMAmbri1M4qmurSi+8v/1H93ZLYZN/P1qCKrfph0 cVWrKxMIQcMCyrThXBeuF05wDMdqbjN2O3WA7vyC15FzkTwb0mSfk5cwZ Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlQEAGTcwU2Q/khLgWdsb2JhbACmHxQBARYmJahHgR2CeA8BmyGGBwSPNYQcijo X-IronPort-AV: E=Sophos;i="4.64,316,1301875200"; d="scan'208";a="86829475" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 04 May 2011 23:09:21 +0000 Received: from [161.44.66.248] (dhcp-161-44-66-248.cisco.com [161.44.66.248]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p44N9KIZ004621 for <core@ietf.org>; Wed, 4 May 2011 23:09:20 GMT Message-ID: <4DC1DCA0.6010608@cisco.com> Date: Wed, 04 May 2011 19:09:20 -0400 From: Paul Duffy <paduffy@cisco.com> Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: core <core@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [core] Client / server requirements for separate messaging X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: paduffy@cisco.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 04 May 2011 23:09:27 -0000 This is going to sound confusing given the usage of client and server in core-coap. Do I assume correctly that a device MUST implement both a COAP client and server? Meaning not only MUST a device implement a client to send requests, but MUST also implement a server to process COAP requests? This to support the separate messaging pattern Cheers From fluffy@cisco.com Wed May 4 19:44:22 2011 Return-Path: <fluffy@cisco.com> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8C82E064A for <core@ietfa.amsl.com>; Wed, 4 May 2011 19:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.602 X-Spam-Level: X-Spam-Status: No, score=-110.602 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nslRghfZnrX8 for <core@ietfa.amsl.com>; Wed, 4 May 2011 19:44:22 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 2663FE06D1 for <core@ietf.org>; Wed, 4 May 2011 19:44:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=123; q=dns/txt; s=iport; t=1304563462; x=1305773062; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=EJR71dKzXNKIyiVeC/1orPp+MJrpPqpBprerTi5e4js=; b=P9rXjflemGOXFd3JAvUU5m9Rs4nVC7eL8IeFLxkV0+Ik+iLE5DDa4/T3 JOhkHmmSdjANUJXv/7mRHoPTEcmYTtBNfxhTZqsV4jDvch7c60X6sufKr fQO79wfQVpnFfrP2WHZKZbfDfBzOHUHaTqgrD+wr8wSGMqU1JSlmSEZFp Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEACEOwk2rRDoH/2dsb2JhbACmH3enaIEdnh+GBwSGL4kGhByKPQ X-IronPort-AV: E=Sophos;i="4.64,318,1301875200"; d="scan'208";a="442000801" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-1.cisco.com with ESMTP; 05 May 2011 02:43:15 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p452gehG011751 for <core@ietf.org>; Thu, 5 May 2011 02:43:15 GMT From: Cullen Jennings <fluffy@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 4 May 2011 20:43:14 -0600 Message-Id: <F1D9FBC7-129A-4B1F-B03E-55F7B470719C@cisco.com> To: core WG <core@ietf.org> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [core] draft-ietf-core-coap-06 Multicast Address X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 05 May 2011 02:44:22 -0000 I think it would be a good idea to get a default multicast address Cullen <in my role as an individual contributor> From fluffy@cisco.com Wed May 4 19:46:08 2011 Return-Path: <fluffy@cisco.com> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47E33E0747 for <core@ietfa.amsl.com>; Wed, 4 May 2011 19:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.602 X-Spam-Level: X-Spam-Status: No, score=-110.602 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7SEKWs9TPNvj for <core@ietfa.amsl.com>; Wed, 4 May 2011 19:46:07 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD0EE06F6 for <core@ietf.org>; Wed, 4 May 2011 19:46:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=311; q=dns/txt; s=iport; t=1304563567; x=1305773167; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=c6ADaP9DQByDHZgBWPm7OrLdQNE/ZtFEPe+aqRuxDjw=; b=l9NKKZvv9rlDHgvhgL88Kwcc1ngQdjz+4K0zDQgsh2dSiRUq6sUKyi/N 6//J1mMZLWoJmqsGrwUkz13sG25S8iBeAxlzRN0lZX90uO0ib22AW8FLA qW4zTGWqwMjwJChGVcAsIAfc0X0BP1Fh16h56KY4pxbLXebrrMTAakF3/ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAE4Pwk2rRDoJ/2dsb2JhbACmH3enXYEdniKGBwSGL4kGhByKPQ X-IronPort-AV: E=Sophos;i="4.64,318,1301875200"; d="scan'208";a="442001482" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-1.cisco.com with ESMTP; 05 May 2011 02:45:59 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p452jiSH008250 for <core@ietf.org>; Thu, 5 May 2011 02:45:59 GMT From: Cullen Jennings <fluffy@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 4 May 2011 20:45:59 -0600 Message-Id: <7AF814A1-3C9B-49A3-8150-079BED29F826@cisco.com> To: core WG <core@ietf.org> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [core] draft-ietf-core-coap-06 Where do responses get sent X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 05 May 2011 02:46:08 -0000 I assume that responses get sent to the ip/port that the request was = received from. Similarly with ACKs. I probably just missed it but could = not find that text. There's so many NATs when using IPv6 that we need to = make sure we get this right :-) Cullen <in my role as an individual contributor>= From fluffy@cisco.com Wed May 4 19:46:08 2011 Return-Path: <fluffy@cisco.com> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 738A8E06F6 for <core@ietfa.amsl.com>; Wed, 4 May 2011 19:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.602 X-Spam-Level: X-Spam-Status: No, score=-110.602 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4E0YS8FyV2M for <core@ietfa.amsl.com>; Wed, 4 May 2011 19:46:08 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 2254CE073B for <core@ietf.org>; Wed, 4 May 2011 19:46:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=338; q=dns/txt; s=iport; t=1304563568; x=1305773168; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=ZopNlnMLKD+BoKkqvaB01r/9d5dUKxNFs1qQdNLXWLg=; b=f67lm5N+wbzIjK+/DE4DqvMr1HD3DkHbbOxi3oVUXTe5M4GjWTX36Wd7 g2IlumSKvh7PvdPBr6xc9AQQs01ulPXfezqIN4pmCVl2Ohw+HM8z7o7EF 6Aoi2ZpDkpS/aEZpV5xSSgdoORCFKtkt6AwBKxJZLbG82V+7R9H5yFREB 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMgOwk2rRDoJ/2dsb2JhbACmH3enWoEdniGGBwSGL4kGhByKPQ X-IronPort-AV: E=Sophos;i="4.64,318,1301875200"; d="scan'208";a="692199206" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-6.cisco.com with ESMTP; 05 May 2011 02:46:07 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p452jiSI008250 for <core@ietf.org>; Thu, 5 May 2011 02:46:07 GMT From: Cullen Jennings <fluffy@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 4 May 2011 20:46:07 -0600 Message-Id: <D91E8A15-A1D7-4B2E-9C90-FBC0906A934E@cisco.com> To: core WG <core@ietf.org> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [core] draft-ietf-core-coap-06 What messages needs a Token X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 05 May 2011 02:46:08 -0000 As far as I can tell, all request and response need a token as that is = the only way to match them or suppress duplicates. Is this correct? I = could not find the text in the draft that really told me when a Token = was needed. The thread on the list did not enlighten me.=20 Cullen <in my role as an individual contributor>= From fluffy@cisco.com Wed May 4 19:46:09 2011 Return-Path: <fluffy@cisco.com> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4E6E073B for <core@ietfa.amsl.com>; Wed, 4 May 2011 19:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.602 X-Spam-Level: X-Spam-Status: No, score=-110.602 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3VrsaRdIduKA for <core@ietfa.amsl.com>; Wed, 4 May 2011 19:46:08 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id A2ABDE06F6 for <core@ietf.org>; Wed, 4 May 2011 19:46:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=867; q=dns/txt; s=iport; t=1304563568; x=1305773168; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=faFobXbVg0z+1kkt5ZRGYv2L3NAh76t1YSXpuP4SNxc=; b=hZmtWddfDVdyU6K0C3/fVZjeNo2YLjB5ch54n7udpUdFpBkRZhnc82+a OG+7LIm98NS436/GsaTm4XFHGS90vRF8PW1yU/Zt6N2XYMKJWsOR60lJ5 3EUmBjsOhx78AYAZw+Fe3UOwN7hcUFLrklcT4S+IncrU09aX2/qWf5oiV A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJ8Owk2rRDoH/2dsb2JhbACmH3epB54hhgcEhi+JBoQcij0 X-IronPort-AV: E=Sophos;i="4.64,318,1301875200"; d="scan'208";a="350678372" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-2.cisco.com with ESMTP; 05 May 2011 02:42:41 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p452gehE011751 for <core@ietf.org>; Thu, 5 May 2011 02:42:40 GMT From: Cullen Jennings <fluffy@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 4 May 2011 20:42:40 -0600 Message-Id: <DF92BCFD-B081-4F06-9F13-C3FE3FB44239@cisco.com> To: core WG <core@ietf.org> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [core] draft-ietf-core-coap-06 Reliability X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 05 May 2011 02:46:09 -0000 A response-timeout of 2 seconds it two slow for real time applications. = Imagine I have a light controlled by a light switch. If I hit the = switch, and the initial packet is lost, then the sends packets happens 2 = seconds later, the user is going to hate that system. It's too slow. A = number like 200 ms would be more appropriate.=20 The max retransmits of 4 may be too small for one particular scenario. = Imagine a large number of devices that all connect to the same proxy. A = power outage causes all of theses devices to simultaneously re register = to the same proxy at the same time. Only have 4 retries per device could = easily end up with many devices failing in use case like this. Moving = from 4 to 6 would significantly improve the ability to deal with an = avalanche restart.=20 Cullen <in my role as an individual contributor> From fluffy@cisco.com Wed May 4 19:46:28 2011 Return-Path: <fluffy@cisco.com> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0768BE06F6 for <core@ietfa.amsl.com>; Wed, 4 May 2011 19:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.602 X-Spam-Level: X-Spam-Status: No, score=-110.602 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e06d3PRs61g5 for <core@ietfa.amsl.com>; Wed, 4 May 2011 19:46:27 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 6A0F7E064A for <core@ietf.org>; Wed, 4 May 2011 19:46:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=755; q=dns/txt; s=iport; t=1304563587; x=1305773187; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=ncdYBLtp3M6LN5c252e5Gzi8J4f21Cvvv3LfZ4YoTg4=; b=CT/FyO6JJZ3hXHo7sOQmMr5ak9eYQRJqHGDSB0pNgw3XZhnn0W0RvL28 Xki7SL5amWQRG1kEkbFz4H1mUFzsFSZqIe07EDX8F9PsfBul86YRsfoJX +uW1/Hxkk+UTkZmrRfOXZ6Hr+mk5oj64hH2VpnAADOHBdDHf6gEmYwH1E g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJ8Owk2rRDoH/2dsb2JhbACmH3epB54hhgcEhi+JBoQcij0 X-IronPort-AV: E=Sophos;i="4.64,318,1301875200"; d="scan'208";a="350678426" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-2.cisco.com with ESMTP; 05 May 2011 02:43:07 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p452gehF011751 for <core@ietf.org>; Thu, 5 May 2011 02:43:07 GMT From: Cullen Jennings <fluffy@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 4 May 2011 20:43:06 -0600 Message-Id: <F5CFF5DB-54B8-40CD-8897-7186C7605AE4@cisco.com> To: core WG <core@ietf.org> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [core] draft-ietf-core-coap-06 Congestion Control X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 05 May 2011 02:46:28 -0000 It's not clear to me that the drafts is a stop and wait congestion = control. I can't see what stops parallel transaction to the same = destination. Related to this, when doing non confirmable transaction, it = does not seem clear how the congestion control works. Given the schema = is stop and wait, I expect that this means one a request has been sent, = a parallel request can not be initiated until a responses is received = but I don't see text to that effect. The draft also needs some sort of = request timeout definition. Should address things like if A has an = outstanding request to B, and A receives separate request from B, what = happens. We don't want any glare problems.=20 Cullen <in my role as an individual contributor> From fluffy@cisco.com Wed May 4 19:47:52 2011 Return-Path: <fluffy@cisco.com> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02E0AE06F6 for <core@ietfa.amsl.com>; Wed, 4 May 2011 19:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.602 X-Spam-Level: X-Spam-Status: No, score=-110.602 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42Smg7m5sPl7 for <core@ietfa.amsl.com>; Wed, 4 May 2011 19:47:51 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 66139E064A for <core@ietf.org>; Wed, 4 May 2011 19:47:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1505; q=dns/txt; s=iport; t=1304563671; x=1305773271; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=uIvjHZmkN4mbcsvsK3XklpgxztkkgH8yFKBdiYJZrjU=; b=LS0rN8j7WKbcxLf/R12YOeM/LgPi41PScIkYYrxILXCBw0V3N/3kY2qw rmEeqMkzqtFZHiZ/6tNr/7tgramGMfFfKQAZg0SrWApSP6S3Jn4odqSCr MxUp0IRw8iiUmD4vbx9uih2fOluFlmBvBp7TM3g/8yOgKa3MDS4Pw8f22 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJ8Owk2rRDoJ/2dsb2JhbACmH3epB54hhgcEhi+JBoQcij0 X-IronPort-AV: E=Sophos;i="4.64,318,1301875200"; d="scan'208";a="350679312" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-2.cisco.com with ESMTP; 05 May 2011 02:45:45 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p452jiSG008250 for <core@ietf.org>; Thu, 5 May 2011 02:45:45 GMT From: Cullen Jennings <fluffy@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 4 May 2011 20:45:44 -0600 Message-Id: <74924760-605F-40DA-8C1A-D9633BF1EE04@cisco.com> To: core WG <core@ietf.org> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [core] draft-ietf-core-coap-06 Fragmentation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 05 May 2011 02:47:52 -0000 Right now a node on fast v6 network will end up sending packets a bit = over 1024 in size. If this packet is then sent to an 802.15.4 network, = it could be fragmenting it down in 8 packets, each sent over multiple = hops, each with say a packet loss of a few percent. This does not seem = like it is going to work very well. This protocol is meant to work well = on constrained networks and 15.4 is certainly one of the targets = environments.=20 I can see two ways to fix this. 1) mandate path MTU discover or 2) use a = smaller MTU. I think 1 (PMTUD) would be hard, add complexity, and make = things slower to get going - I don't like that so I prefer the using a = smaller packet size. It''s hard to pick a number, but lets just say you = 240 or something like that. That would make it so the packet would = probably not result in more than 2 fragments on an 15.4 network. For = doing bulk transfers of something like firmware using block, the = difference in efficiency between the 1023 and 240 seems pretty small to = me so I don't see a big downside of using smaller packets. (240 was just = pulled out of thin air - I'm sure a little thought would lead to a = better number). I don't have a strong opinion on how to fix this or if = 240 is the right number, but I feel strongly that a CoAP node on a = server with fast ethernet needs to be able to talk to a CoAP node on = 15.4 mesh network and have that work well.=20 Cullen <in my role as an individual contributor>= From fluffy@cisco.com Wed May 4 19:48:11 2011 Return-Path: <fluffy@cisco.com> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 497C5E06F6 for <core@ietfa.amsl.com>; Wed, 4 May 2011 19:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.445 X-Spam-Level: X-Spam-Status: No, score=-108.445 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_BELOW2=2.154, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NaQHuR97dlYK for <core@ietfa.amsl.com>; Wed, 4 May 2011 19:48:10 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 59A88E064A for <core@ietf.org>; Wed, 4 May 2011 19:48:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=2076; q=dns/txt; s=iport; t=1304563690; x=1305773290; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=mVXCF8zIfFyjHuXTHkGAbQX2tGWXQu4EvSw4pXIXqrQ=; b=eN2eOiiM+uu4JKZqUDZrd5LE8Ua6B589zFeNN2uoW2dSgC6/WFbWr/qv 7WMqSXmo+4C9bm+j/mrut9mehQkgywp7sEZNzlyd7En2KbKApLxVpnpJi 9Xhk9m1pk2Aq85vPBO9/GLK0jqq4l/c4cCRshMZEOCISyJwKMtNDHWtaA 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlQEAIUPwk2Q/khLgWdsb2JhbACmIBQBARYmJaddgR2eIoIrg1wEhi+JBoQcij0 X-IronPort-AV: E=Sophos;i="4.64,318,1301875200"; d="scan'208";a="28713969" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 05 May 2011 02:48:09 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p452m8p2012030 for <core@ietf.org>; Thu, 5 May 2011 02:48:08 GMT From: Cullen Jennings <fluffy@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 4 May 2011 20:48:07 -0600 Message-Id: <1FFCF0B6-2DF8-4776-BC6B-47069737AD50@cisco.com> To: core WG <core@ietf.org> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [core] draft-ietf-core-coap-06 The CoAP/DTLS/CoAP Turkey Sandwich layer violation train wreck X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 05 May 2011 02:48:11 -0000 The draft requires CoAP to be both a layer bellow DTLS and a layer above = it. This type of layer violation will really complicate things in the = future. For example, imagine that we were trying to do CoAP over DTLS = over DCCP over UDP. Where does the wacky COAP shim go, below DTLS or = above DCCP. If an underlying hardware implication provided DTLS offload = over UDP, it could not be used because CoAP has to be inserted in = between DTLS and UDP. If we wanted to tie the DTLS compression to the = underling link layer hardware compression it would not work. If = something clever was happing between the DTLS over HIP and the HIP = layer, this might confuse it. Some layer violation are well worth it, = this is not one of them. As far as I can tell there is pretty much no = reason for doing this. The obvious thing to do is be the same as HTTP = and use two ports one for DTLS and one for CoAP with DTLS.=20 I want to put particular focus on the point that most people that build = large scale systems that use TLS fast crypto hardware to terminate the = TLS at the aggregation points then pass the data on to the servers = behind that. Some vendors do have support for DTLS acceleration as well = as TLS but asking for a custom hardware support for CoAP is pretty to = hard to ask for until the market for this is all a lot larger than it = currently is.=20 Lots of protocol look like protocol X on top of DTLS on top of UDP. = Asking for X on top of DTLS on top of X on top UDP is not reasonable.=20 Cullen <in my role as an individual contributor> PS - Oh, and I'd also like to make the point and that many CoAP = implementations will be using dynamically linked library to get DTLS so = the CoAP application calling the library may not even be able to tell if = the DTLS implementation uses code points other than the ones defined in = DTLS 1.2. So implications like this have to check every packet the DTLS = stack sends to the UDP stack and see if it needs escaping. It's not a = future problem, it's a "now" problem.=20 From fluffy@cisco.com Wed May 4 19:48:26 2011 Return-Path: <fluffy@cisco.com> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50AC1E07BA for <core@ietfa.amsl.com>; Wed, 4 May 2011 19:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.522 X-Spam-Level: X-Spam-Status: No, score=-109.522 tagged_above=-999 required=5 tests=[AWL=1.077, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mt3ioG4Ag3jh for <core@ietfa.amsl.com>; Wed, 4 May 2011 19:48:25 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 42593E06D1 for <core@ietf.org>; Wed, 4 May 2011 19:48:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=302; q=dns/txt; s=iport; t=1304563705; x=1305773305; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=DYBARaxe3pHvDNsVWKGnau/E8Sx/NQXn9pjNgG4eGd4=; b=OFZRdXh/w/UTvD9Z4vabVohLirnuGC0sdZ0DQBK9DsjirSxdXqqKYDrz bm6F/sg+8i/JCoFW/FIrwDC5ekrs/YW8Yc8tI5ccM3qCNFyIfb4Ko0ckI XUUyAkVvN4QmSzdtWmVJN9E2L7hZDWhZDs4PKbyp/FIWqf/GkeRMV29Nj o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlQEAIUPwk2Q/khLgWdsb2JhbACmIBQBARYmJaddgR2eIoYHBIYviQaEHIo9 X-IronPort-AV: E=Sophos;i="4.64,318,1301875200"; d="scan'208";a="28713986" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 05 May 2011 02:48:24 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p452m8p3012030 for <core@ietf.org>; Thu, 5 May 2011 02:48:24 GMT From: Cullen Jennings <fluffy@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 4 May 2011 20:48:23 -0600 Message-Id: <DBA973AE-79E6-4D6C-A866-639A5B286EBF@cisco.com> To: core WG <core@ietf.org> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [core] draft-ietf-core-coap-06 Server Name Indication X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 05 May 2011 02:48:26 -0000 For devices that do Certificate mode, I think this should be a MUST not = a SHOULD. It is a very hard to migrate to this if some servers don't = support it as we have seen in HTTP. We don't have to repeat that pain in = CoAP so lets not.=20 Cullen <in my role as an individual contributor>= From fluffy@cisco.com Wed May 4 19:48:55 2011 Return-Path: <fluffy@cisco.com> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A59CEE06D1 for <core@ietfa.amsl.com>; Wed, 4 May 2011 19:48:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.061 X-Spam-Level: X-Spam-Status: No, score=-110.061 tagged_above=-999 required=5 tests=[AWL=0.538, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PaRXpqR-LvTp for <core@ietfa.amsl.com>; Wed, 4 May 2011 19:48:55 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id BAD85E06F6 for <core@ietf.org>; Wed, 4 May 2011 19:48:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=138; q=dns/txt; s=iport; t=1304563734; x=1305773334; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=KBxKe4CRWlLJmI/C+5/1Q2b04+uk8hmP9/PtI1jJ2Lw=; b=R4+eLGDWPE2Zikbf2VGsyqeRWL3qWwp5fvgjs7NOUUGtJWLGfUMu0ue6 75FJ6ceZ3S+xsp5Sp2pK++Gr8he/vfDhjLdwfHKuzBo2aioQN9UAqSQNQ srYZpzd4JciufJu7+YSKexnqYyA9XKR0aXGkoP6CjT6NFWDGFrPjS6isu s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlQEAO8Pwk2Q/khLgWdsb2JhbACmIBQBARYmJadagR2eIoYHBIYviQaEHIo9 X-IronPort-AV: E=Sophos;i="4.64,318,1301875200"; d="scan'208";a="86846310" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 05 May 2011 02:48:35 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p452m8p4012030 for <core@ietf.org>; Thu, 5 May 2011 02:48:34 GMT From: Cullen Jennings <fluffy@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 4 May 2011 20:48:34 -0600 Message-Id: <292C0DCB-2B12-4F30-9FCD-370D4D20FD4B@cisco.com> To: core WG <core@ietf.org> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [core] draft-ietf-core-coap-06 What protocol X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 05 May 2011 02:48:55 -0000 Given a CoAP URI like coap:1.2.3.4/temp, do I try to connect with DTLS = or UDP? Cullen <in my role as an individual contributor>= From fluffy@cisco.com Wed May 4 19:49:08 2011 Return-Path: <fluffy@cisco.com> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 531A1E07FF for <core@ietfa.amsl.com>; Wed, 4 May 2011 19:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.24 X-Spam-Level: X-Spam-Status: No, score=-110.24 tagged_above=-999 required=5 tests=[AWL=0.359, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bea8HwPQiHeV for <core@ietfa.amsl.com>; Wed, 4 May 2011 19:49:07 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 72E74E06D1 for <core@ietf.org>; Wed, 4 May 2011 19:49:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=969; q=dns/txt; s=iport; t=1304563747; x=1305773347; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=IsVIrKcljVtPiXwvAtqTJrtCN/hU3cGB/xybv1Q41fw=; b=bCbhyqzwUYn6eZ8hjzny2bFu1DYxGgFHb3+K7J7m+CRgyy7r+pvyXFGP lKdijNu2g3jMNlEhfShUJtW1/s6LBlr4tLMsaevxHW5upchBoRVwQw1jo jyGBC5o/9fULdpvmu/QqunuazQPP5Mmeu9ASgV5wbj77C8PdI2OS54MV5 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlQEAIUPwk2Q/khLgWdsb2JhbACmIBQBARYmJaddgR2eIoYHBIYviQaEHIo9 X-IronPort-AV: E=Sophos;i="4.64,318,1301875200"; d="scan'208";a="28714025" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 05 May 2011 02:49:06 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p452m8p5012030 for <core@ietf.org>; Thu, 5 May 2011 02:49:05 GMT From: Cullen Jennings <fluffy@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 4 May 2011 20:49:05 -0600 Message-Id: <FE6FA200-EA46-4442-BCD9-79E7BFFD488E@cisco.com> To: core WG <core@ietf.org> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [core] draft-ietf-core-coap-06 Cache-Control X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 05 May 2011 02:49:08 -0000 I worry about the privacy implication of CoAP not having the equivalent = of HTTP "Cache-Control : private". In a perfect rest world, a GET to a = given URL would return same result regardless of who request it but = practically speaking, that's ship sailed long ago and different results = get returned depending on who asked. There is lots of good use cases for = this - particularly when we start talking about privacy. Just saying = that something can not be cached by using Mac-Age =3D 0 is seems far too = limiting. Clearly many constrained devices would not need to use and = "Cache-Control : private " options but it seems like something that = caching proxies need to support.=20 I suspect someone from the IETF Privacy Directorate might tell us that = if we are doing caching of sensitive data, we really need to have some = way to limit access to that that is better than "don't do that" Cullen <in my role as an individual contributor>= From fluffy@cisco.com Wed May 4 19:49:33 2011 Return-Path: <fluffy@cisco.com> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45CFDE06F6 for <core@ietfa.amsl.com>; Wed, 4 May 2011 19:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.33 X-Spam-Level: X-Spam-Status: No, score=-110.33 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmlVxwNTaAgb for <core@ietfa.amsl.com>; Wed, 4 May 2011 19:49:32 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 7F9B1E06D1 for <core@ietf.org>; Wed, 4 May 2011 19:49:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1725; q=dns/txt; s=iport; t=1304563772; x=1305773372; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=aNFIOiUt7ZQoWwmth5XLBxYQ0sGyLggHSyBeqBK/6ic=; b=DytgjZv0u28v85mVzhBFwi64iVwVL6GrrUL/GyZ/M7e1x2ggZM3a/LKW H9Ur+UawzduiLFQKwr006TTBWAN7vLcuOThtLsyNF5eFqNnJWD58Gufj+ RDMxFuTmZCAEdmWOu4eDQfmnLcedni7lE0sZVm8kBbdITa4Atp3+ycCaT g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlQEAIUPwk2Q/khLgWdsb2JhbACmIBQBARYmJaddgR2eIoYHBIYviQaEHIo9 X-IronPort-AV: E=Sophos;i="4.64,318,1301875200"; d="scan'208";a="28714057" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 05 May 2011 02:49:31 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p452m8p6012030 for <core@ietf.org>; Thu, 5 May 2011 02:49:30 GMT From: Cullen Jennings <fluffy@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 4 May 2011 20:49:30 -0600 Message-Id: <D792B290-CAD9-437E-9DF3-5E79C5928FF3@cisco.com> To: core WG <core@ietf.org> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [core] draft-ietf-core-coap-06 Unicode Normalization X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 05 May 2011 02:49:33 -0000 I don't think this draft needs to say anything about unicode or UTF-8. = The format of the relevant parts is defined by reference to the ABNF = used in HTTP. What implementations do is treat this all as binary data = and I think the is the exactly right thing to do. The spec should just = say it is binary data. All references to UTF-8 and NFC can be removed as = well as the string time can just be changed to the opaque type. I think = doing this change will up the odds of interoperability. The HTTP specs = will already take care of the parts of of HTTP that are UTF-8 and the = way we reduce the ABNF ensure an good mapping between CoAP and HTTP. The = way I would interpret the draft as the current text stands would cause = me to use normalized form C where other people would not resulting in = really hard to debug interoperability problems as the management tools = would probably print things in way in the debugging information where = two things that were actually different looked the same when you looked = at them in the management tool. It all seems like a huge hassle with no = gain. I have asked several people what we get by specifying UTF-* over = binary data and everyone says, oh, but we are really just processing it = as binary data. The real problem I see with saying NFC, or even UTF-8, = is what happens when you get data that is not. Do you return an error or = do the canonicalization. Either answer results in needing to do = something that I really don't want to do on a constrained system so I = prefer the answer of of do neither and just ignore it. But at hat point = we are doing binary data not NFC UTF-8.=20 Cullen <in my role as an individual contributor>= From fluffy@cisco.com Wed May 4 19:49:39 2011 Return-Path: <fluffy@cisco.com> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 753B6E0837 for <core@ietfa.amsl.com>; Wed, 4 May 2011 19:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.384 X-Spam-Level: X-Spam-Status: No, score=-110.384 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZPnd83Lchzs6 for <core@ietfa.amsl.com>; Wed, 4 May 2011 19:49:39 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id AC2A0E0835 for <core@ietf.org>; Wed, 4 May 2011 19:49:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=441; q=dns/txt; s=iport; t=1304563778; x=1305773378; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=kbadVE96PvLhIsb9Z49AxiCVm/LwQeVDteDLKr6SQxI=; b=XrrsnzMTsjno9FPI2Iqf9sOTjHhui27zVvhAiBwb1eVD9Hcq4+/RL0u1 6or3AavDrvr/3Gcl3slu4dmiiJbOWsSMtwt2oMD1W5gyU4hdB+IxbatGk ptj61w21StX8gdRBUGsX5z/z2nE7qWJa8UlqXXbuQFWYbxSgkh5LQ6RW9 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlQEAO8Pwk2Q/khLgWdsb2JhbACmIBQBARYmJadagR2eIoYHBIYviQaEHIo9 X-IronPort-AV: E=Sophos;i="4.64,318,1301875200"; d="scan'208";a="86846379" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 05 May 2011 02:49:37 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p452m8p7012030 for <core@ietf.org>; Thu, 5 May 2011 02:49:37 GMT From: Cullen Jennings <fluffy@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 4 May 2011 20:49:37 -0600 Message-Id: <272CCB8D-3154-4239-9576-0F1FDFEFFE1C@cisco.com> To: core WG <core@ietf.org> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [core] draft-ietf-core-coap-06 Critical options and Reset X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 05 May 2011 02:49:39 -0000 The draft says that reviving a critical option that is not understood = should cause the sending of a reset. This does not sound right to me. = It's not the transport that failed, it's the request that failed so the = error should be transaction layer not the transport layer. It seems like = it MUST send a 4.02 (as the draft says) but I don't think is should send = a reset.=20 Cullen <in my role as an individual contributor>= From fluffy@cisco.com Wed May 4 19:49:49 2011 Return-Path: <fluffy@cisco.com> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4998FE06F5 for <core@ietfa.amsl.com>; Wed, 4 May 2011 19:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.419 X-Spam-Level: X-Spam-Status: No, score=-110.419 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4E1vwTv3O4c9 for <core@ietfa.amsl.com>; Wed, 4 May 2011 19:49:48 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 55777E082C for <core@ietf.org>; Wed, 4 May 2011 19:49:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=935; q=dns/txt; s=iport; t=1304563782; x=1305773382; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=uA3hGZxNWn2xLrhKnPg3TCtTHNKfkBhOj6WMM8cYIug=; b=TfrlVPx28gpG3TQMComn78RnUBrjK/ZoJ5gJu08zdxzraFGqsMHcNxSd 1eIsvrI0JE5MjsMc7Cz7yVKFSwUpu2b2xgOjeNQTAjx94DtvWefWqi1Yi vFrwAtabh/GyjQxQqy5Trb3o29cecFhYtPlKnfBrp/rWsfx8NbO6da11y s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlQEAIUPwk2Q/khLgWdsb2JhbACmIBQBARYmJaddgR2eIoYHBIYviQaEHIo9 X-IronPort-AV: E=Sophos;i="4.64,318,1301875200"; d="scan'208";a="28714069" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 05 May 2011 02:49:41 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p452m8p8012030 for <core@ietf.org>; Thu, 5 May 2011 02:49:40 GMT From: Cullen Jennings <fluffy@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 4 May 2011 20:49:40 -0600 Message-Id: <770C6CBC-E55E-41B2-BA92-1B161C8282A7@cisco.com> To: core WG <core@ietf.org> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [core] draft-ietf-core-coap-06 IF-Match Option X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 05 May 2011 02:49:49 -0000 Imagine a care where you care controlling some actuator and you want to = change it's value in a relative way. The typical way to do this is GET = the current value, then PUT a new absolute value. However, to do this, = you need to know the value did not change in between the GET and PUT. = This can be solved by getting and ETag in the GET, then including that = ETAG in an If-Match option of the PUT. If, at the time the PUT is = received, the current ETAG for the resource does not match the value in = the IF-Match option, then the PUT is not performed and returns an error. = The client can then retry the GET / PUT pair. You can imagine this case = coming up with an example of light dimmer and trying to increase the = level of light by say 10%.=20 I think this is an important use case that should be supported and we = should add an IF-Match option.=20 Cullen <in my role as an individual contributor>= From fluffy@cisco.com Wed May 4 19:49:49 2011 Return-Path: <fluffy@cisco.com> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D740FE06F5 for <core@ietfa.amsl.com>; Wed, 4 May 2011 19:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.445 X-Spam-Level: X-Spam-Status: No, score=-110.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQi7iJ6K37ze for <core@ietfa.amsl.com>; Wed, 4 May 2011 19:49:49 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 96A1AE083A for <core@ietf.org>; Wed, 4 May 2011 19:49:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=461; q=dns/txt; s=iport; t=1304563786; x=1305773386; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=MWS5dr1QbQkOePTfJ+fEuw7KLmlzG453/yNm23lB7ww=; b=MhXQqAsBAk/6HC95EbiH6jm8fcMopR7ytfBERkRshwVV6uBUhonak7i5 ZtBI8iahoExdyjtrXkf9seiS8TnlSLjgq6nGJhUkAm99NFmfzQwlp1kp2 xGSYBG23Pf2BQ59MnULvSF2c697XHMMXtNLJB7GijxMtHFGAUG1FKxC/1 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlQEAO8Pwk2Q/khLgWdsb2JhbACmIBQBARYmJadagR2eIoYHBIYviQaEHIo9 X-IronPort-AV: E=Sophos;i="4.64,318,1301875200"; d="scan'208";a="86846390" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 05 May 2011 02:49:45 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p452m8p9012030 for <core@ietf.org>; Thu, 5 May 2011 02:49:45 GMT From: Cullen Jennings <fluffy@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 4 May 2011 20:49:45 -0600 Message-Id: <CD5C8BF9-A967-41D3-830F-D8684DF764D9@cisco.com> To: core WG <core@ietf.org> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [core] draft-ietf-core-coap-06 What's a resource X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 05 May 2011 02:49:50 -0000 Consider two paths "/a?1" and "/a?2" Does this refer to one resource = called "a" with two different query parameters. Or do these refer to two = different resources. The draft seems to be a little lax on this and = treat it both ways. The debate of what a resource was turned out to be = incredibly important in webdav so I would prefer as crisp a definition = of resource as possible in CoAP.=20 Cullen <in my role as an individual contributor>= From fluffy@cisco.com Wed May 4 19:50:02 2011 Return-Path: <fluffy@cisco.com> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCB53E06F5 for <core@ietfa.amsl.com>; Wed, 4 May 2011 19:50:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.464 X-Spam-Level: X-Spam-Status: No, score=-110.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V+v1Xg86ZiQ9 for <core@ietfa.amsl.com>; Wed, 4 May 2011 19:49:59 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id E256AE06D1 for <core@ietf.org>; Wed, 4 May 2011 19:49:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=197; q=dns/txt; s=iport; t=1304563798; x=1305773398; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=ZnvhWJcfPb3FxDJUWQmdsVRYw/JQ2VYS/0dLXQsOqZQ=; b=bKnp12iWIYtyroZIuowdzccxUxIlw+nitZ5I+vG8YbzbBiYa1Rhqf+Ed BfM/iWrCB5GH11QfivyNO0A8J8X/+ZLqF6ZIDqIgvi98zDXhr5760mMJQ ATN80huPfpmkgBZjNQt7F8LSJ3ft2LsjNHf4gWEIeKhpqPplBpaoy/o0B M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlQEAIUPwk2Q/khLgWdsb2JhbACmIBQBARYmJaddgR2eIoYHBIYviQaEHIo9 X-IronPort-AV: E=Sophos;i="4.64,318,1301875200"; d="scan'208";a="28714107" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 05 May 2011 02:49:57 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p452m8pA012030 for <core@ietf.org>; Thu, 5 May 2011 02:49:56 GMT From: Cullen Jennings <fluffy@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 4 May 2011 20:49:56 -0600 Message-Id: <B0FC5943-2608-4633-8B2F-1283B2E53665@cisco.com> To: core WG <core@ietf.org> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [core] draft-ietf-core-coap-06 Mapping HTTP Trace request to CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 05 May 2011 02:50:03 -0000 If you google "HTTP Trace" most the post are about how to disable it. I = think we can have the proxy instantly return a 405 to a trace.=20 Cullen <in my role as an individual contributor>= From fluffy@cisco.com Wed May 4 19:50:12 2011 Return-Path: <fluffy@cisco.com> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16C42E06F6 for <core@ietfa.amsl.com>; Wed, 4 May 2011 19:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.479 X-Spam-Level: X-Spam-Status: No, score=-110.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TUxVuSMTI-gI for <core@ietfa.amsl.com>; Wed, 4 May 2011 19:50:11 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 8C3DEE077D for <core@ietf.org>; Wed, 4 May 2011 19:50:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=229; q=dns/txt; s=iport; t=1304563808; x=1305773408; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=Te71nOEgoR3SLKa25i24eX1m/MMiwA4Op4Ve7vbZAdM=; b=ByZpw7dmE3X/J5pz3UeN6yTOhbvHHL13gKD26CExs73elC5dOv1Tl8yb ej+++z+FT99iPXRdSYNQKimygEZ9LyJE5MR4+elm0pxwg3iHlkFJ5gDtG HufIRue0n6co9+1+AiIoMWnG5/Q5TJMW7F8sKY3Gjk2gdZWvIt3riD/rm Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlQEAO8Pwk2Q/khLgWdsb2JhbACmIBQBARYmJadagR2eIoYHBIYviQaEHIo9 X-IronPort-AV: E=Sophos;i="4.64,318,1301875200"; d="scan'208";a="86846472" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 05 May 2011 02:50:07 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p452m8pB012030 for <core@ietf.org>; Thu, 5 May 2011 02:50:07 GMT From: Cullen Jennings <fluffy@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 4 May 2011 20:50:07 -0600 Message-Id: <8F7193F8-5D8B-4D6B-B86B-5F48B88CE5C7@cisco.com> To: core WG <core@ietf.org> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [core] draft-ietf-core-coap-06 Mapping HTTP Options request to CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 05 May 2011 02:50:12 -0000 We should consider if we can support this. The proxy would know what = methods are supported. Seems like that might be enough to return in the = HTTP options response.=20 Cullen <in my role as an individual contributor>= From fluffy@cisco.com Wed May 4 19:50:19 2011 Return-Path: <fluffy@cisco.com> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7BEE0843 for <core@ietfa.amsl.com>; Wed, 4 May 2011 19:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.491 X-Spam-Level: X-Spam-Status: No, score=-110.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zri-2ryE2hf2 for <core@ietfa.amsl.com>; Wed, 4 May 2011 19:50:19 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id A20A2E06F6 for <core@ietf.org>; Wed, 4 May 2011 19:50:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1132; q=dns/txt; s=iport; t=1304563818; x=1305773418; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=EBAByzab4ijKceHaH6pENwIcpsxIQ6xTo0ZG5D/ZvSg=; b=Rc/RQwr9+XhmNCiMzoFJ61DRjGmf7Mc2WAAXyUuf6GTST053KEWmDQ0S OHvo4benRteR4sCSOcmiwggjz32r4g2109kwFlyMKJGNo+Lkkjce/sFSb Jdk2woIaByll1yLesIB91l8E5VyHdlPo32pftIJx3Zd/6x2FJ7EJlpMh8 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlQEAIUPwk2Q/khLgWdsb2JhbACmIBQBARYmJaddgR2eIoYHBIYviQaEHIo9 X-IronPort-AV: E=Sophos;i="4.64,318,1301875200"; d="scan'208";a="28714136" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 05 May 2011 02:50:17 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p452m8pC012030 for <core@ietf.org>; Thu, 5 May 2011 02:50:17 GMT From: Cullen Jennings <fluffy@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 4 May 2011 20:50:16 -0600 Message-Id: <01DE3DF2-5C84-4353-9902-482816F1DB57@cisco.com> To: core WG <core@ietf.org> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [core] draft-ietf-core-coap-06 Critical / Elective options and proxies X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 05 May 2011 02:50:19 -0000 Saying that proxies have to understand and process all critical options = is going to make it very difficult to get anyone to agree to deploy new = options. The problem is the endpoints won't use new critical options = because they won't work because the proxies does implement them and the = proxies won't implement them because no end points use them. (yes, I'm a = huge fan of Handley's internet only just works paper. My suggestion = would be to have three classes, elective, critical, and proxy critical. = Proxy critical means it is critical for proxies and end points. The proxy would forward elective and critical requests regardless of it = the proxy understood them or not while proxy critical options that were = not understood would result in an error. I might suggest the rule for = determining if an option was proxy critical or not might be that for = option numbers greater than 16, if the option number mod 8 was 7, then = it was proxy critical. Or some rule along these lines and just special = case the options numbers already in use.=20 Cullen <in my role as an individual contributor>= From fluffy@cisco.com Wed May 4 19:51:09 2011 Return-Path: <fluffy@cisco.com> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CEDDE06F5 for <core@ietfa.amsl.com>; Wed, 4 May 2011 19:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.501 X-Spam-Level: X-Spam-Status: No, score=-110.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qjQYuNtZKq0 for <core@ietfa.amsl.com>; Wed, 4 May 2011 19:51:08 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 58A8BE06D1 for <core@ietf.org>; Wed, 4 May 2011 19:51:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=777; q=dns/txt; s=iport; t=1304563868; x=1305773468; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=1qSPwbe8/RR61kruWUBqo+j4Lw6l4EzJm48tfCvmXRY=; b=GhCi+3Qplvwk9wD9q5OdVOam/DyQGLfWtKZC2kqrnnQM9BknXOtQp/nZ ctLGbdgU9UnGQaTT160GfhuQVXoRbmGinyXTtZSD4Olu+8isun3nc8PU4 cshd06IRLNpCGRQPgCuBdyBVPlf2JEgs0fYu8LX0tH6suziyQfglGr4Sd I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmcFAO8Pwk2Q/khLgWdsb2JhbAAgpgAUAQEWJiWnWoEdniKGBwSGL4kGhByKPQ X-IronPort-AV: E=Sophos;i="4.64,318,1301875200"; d="scan'208";a="86846541" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 05 May 2011 02:51:07 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p452m8pE012030 for <core@ietf.org>; Thu, 5 May 2011 02:51:07 GMT From: Cullen Jennings <fluffy@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 4 May 2011 20:51:06 -0600 Message-Id: <239072CD-ACC0-454D-8BD6-30AC28D425D9@cisco.com> To: core WG <core@ietf.org> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [core] draft-ietf-core-coap-06 Security X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 05 May 2011 02:51:09 -0000 I think it will be very hard to leave keying for the security out of = scope of this specification. I realize there are other drafts in = progress on this and I look forward to their rapid arrival. Even when = using DTLS Certificate mode, any connection can have a man in the middle = attack as their is not binding of who we are trying to connect to = material in the certificate. This seems like a big problem. Related to = this, for many protocols the assumption that someone with a keyboard and = screen will manually type something into the device as out of band = security configuration is reasonable. Give the use cases this WG was = formed to solve, it is not an reasonable assumption for this WG.=20 Cullen <in my role as an individual contributor> From fluffy@cisco.com Wed May 4 19:51:27 2011 Return-Path: <fluffy@cisco.com> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E147FE082C for <core@ietfa.amsl.com>; Wed, 4 May 2011 19:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.509 X-Spam-Level: X-Spam-Status: No, score=-110.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UnTqkLw9rFzJ for <core@ietfa.amsl.com>; Wed, 4 May 2011 19:51:27 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 2FB18E0835 for <core@ietf.org>; Wed, 4 May 2011 19:51:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=317; q=dns/txt; s=iport; t=1304563887; x=1305773487; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=ykofcDDmh/Tkku0a5bSNYzsgorT9Coy+0kMaRORutg8=; b=LDY2/pgV3evXDnOcExJ8OXJzP4r8gvPBmiWpltqOBWH8jxPfTbKtND5H WVUinRJ3/Li7c02RJ53SDHerCDAqH6txDuJscuEL4n3Tutdu9iaFb6q0p 8luX/92Mvq4VxpsEBbPMyGepgu+Hu8STBYsgU3ToZ4JHeSnN3jhWneg37 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlQEAIUPwk2Q/khLgWdsb2JhbACmIBQBARYmJaddgR2eIoYHBIYviQaEHIo9 X-IronPort-AV: E=Sophos;i="4.64,318,1301875200"; d="scan'208";a="28714148" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 05 May 2011 02:50:25 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p452m8pD012030 for <core@ietf.org>; Thu, 5 May 2011 02:50:24 GMT From: Cullen Jennings <fluffy@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 4 May 2011 20:50:24 -0600 Message-Id: <3C6D8B57-A90B-467A-9353-1CCBF080257C@cisco.com> To: core WG <core@ietf.org> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [core] draft-ietf-core-coap-06 Default Port X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 05 May 2011 02:51:28 -0000 The current drafts has MUST support certain things on the default port. = I'd prefer this as a should because many of the IPv6 deployments = strategies involve NAT like things that might it hard for a given node = to control which ports it is able to use.=20 Cullen <in my role as an individual contributor> From fluffy@cisco.com Wed May 4 19:51:42 2011 Return-Path: <fluffy@cisco.com> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55B7DE06F5 for <core@ietfa.amsl.com>; Wed, 4 May 2011 19:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.516 X-Spam-Level: X-Spam-Status: No, score=-110.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d7qjlaefO0eM for <core@ietfa.amsl.com>; Wed, 4 May 2011 19:51:42 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id A7868E06D1 for <core@ietf.org>; Wed, 4 May 2011 19:51:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=442; q=dns/txt; s=iport; t=1304563901; x=1305773501; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=NED4UjKy07xJYOzTb3QH7Kswku24/DIbn//xOY6HxJE=; b=f1x7XvoeRy6K/qyNZfMyoKD2U7UWjGFIIQqZApF7Je2JMU0vl2T5UM/i JeQCEXRBDGxv6kPrBX1/jQLMa1cNoDsfJD2knQxAgSy79kU9/8PO6HCN6 YwByuXcR74i1S5XLz2YrMCT9FT5t/9IPK7E58qabyB4f2i16qZGnl+kV1 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlQEAIUPwk2Q/khLgWdsb2JhbACmIBQBARYmJaddgR2eIoYHBIYviQaEHIo9 X-IronPort-AV: E=Sophos;i="4.64,318,1301875200"; d="scan'208";a="28714227" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 05 May 2011 02:51:40 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p452m8pF012030 for <core@ietf.org>; Thu, 5 May 2011 02:51:40 GMT From: Cullen Jennings <fluffy@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 4 May 2011 20:51:39 -0600 Message-Id: <B6AF3744-F773-49FD-ADF2-F3093D912ABF@cisco.com> To: core WG <core@ietf.org> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [core] draft-ietf-core-coap-06 Mandatory to Implement Crypto Suites X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 05 May 2011 02:51:42 -0000 My key concern is that we do pick something. The choice of AES, SHA1 and = SHA256 all seem pretty easy. (I include the SHA1 and SHA256 because I = assume they would be needed to verify a certificate chain even if the = transport integrity did not use them). I see the latest draft has = Elliptic Curve for asymmetric crypto. Given the direction of Zigbee, I'm = fine with that.=20 Cullen <in my role as an individual contributor>= From fluffy@cisco.com Wed May 4 19:51:48 2011 Return-Path: <fluffy@cisco.com> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF79FE083F for <core@ietfa.amsl.com>; Wed, 4 May 2011 19:51:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.522 X-Spam-Level: X-Spam-Status: No, score=-110.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ugXTZeOpYVd9 for <core@ietfa.amsl.com>; Wed, 4 May 2011 19:51:48 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD5EE082C for <core@ietf.org>; Wed, 4 May 2011 19:51:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=387; q=dns/txt; s=iport; t=1304563908; x=1305773508; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=538QVEXuHX6TNis60EHlA93pRnwxC/CisDLNc6+wn+4=; b=IJy71zJeCzE8hLKynLiy5RqtYdDLjoSyn4U9H+UiagjgWWq2SOG72C/Q kVH9UuzJo8qugOyizIk/nehv6mK6dvhqVTuz9i1aQ18WrDBj8jqpfMSMK JFme+PlbJqcsMWRlMSmfL/Sj913mJsusCgMfmpCfa213eOtAjMOIL0R8q s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq0GAO8Pwk2Q/khLgWdsb2JhbAAhpX8UAQEWJiWnWoEdniKGBwSGL4kGhByKPQ X-IronPort-AV: E=Sophos;i="4.64,318,1301875200"; d="scan'208";a="86846585" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 05 May 2011 02:51:47 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p452m8pG012030 for <core@ietf.org>; Thu, 5 May 2011 02:51:47 GMT From: Cullen Jennings <fluffy@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 4 May 2011 20:51:46 -0600 Message-Id: <A7ACA016-F9CF-4DF8-8C61-8FD725832ECA@cisco.com> To: core WG <core@ietf.org> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [core] draft-ietf-core-coap-06 Mandatory To Implement Security Modes X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 05 May 2011 02:51:49 -0000 The draft needs to be clear on which of the four modes in section 10 are = mandatory to implement. I need to be clear, I'm not talking about = mandatory to use, it's fine if people have a deployment that does not = need to enable security or want to use a very different option. But for = interoperability, we need to have something that two given devices = implement in common. From fluffy@cisco.com Wed May 4 19:52:59 2011 Return-Path: <fluffy@cisco.com> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB41AE06F5 for <core@ietfa.amsl.com>; Wed, 4 May 2011 19:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.602 X-Spam-Level: X-Spam-Status: No, score=-110.602 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PtJx9iCzo5PH for <core@ietfa.amsl.com>; Wed, 4 May 2011 19:52:58 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id D0C35E06D1 for <core@ietf.org>; Wed, 4 May 2011 19:52:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=2468; q=dns/txt; s=iport; t=1304563978; x=1305773578; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=nIpWFmTCZsxFch9YBVgY/Kw1v8kDSfbIXInD/YR5kbU=; b=aN+MUw69OU9kywxzJ2XpFdSqrwRhO6Rumz3LmAGruLRtBJc5pTEHG1nx sLadpzB1XivugH2w/cCegZrO7glIwfdD1+nUgJnejl12WHnvzH9EmFTcZ 4IZD81K0W2igPKon+7BT9TpOtPHPuHvqLI7l+oD+r06yxVV5GW1YmugCd M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALkPwk2rRDoJ/2dsb2JhbACmIHenWoEdniKGBwSGL4kGhByKPQ X-IronPort-AV: E=Sophos;i="4.64,318,1301875200"; d="scan'208";a="350681621" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-2.cisco.com with ESMTP; 05 May 2011 02:52:58 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p452qvxr013255 for <core@ietf.org>; Thu, 5 May 2011 02:52:58 GMT From: Cullen Jennings <fluffy@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 4 May 2011 20:52:57 -0600 Message-Id: <A4B8F69A-6061-4D74-91B7-0675C10B6BC0@cisco.com> To: core WG <core@ietf.org> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [core] draft-ietf-core-coap-06 Miscellaneous Things X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 05 May 2011 02:52:59 -0000 I think you need to describe how to mapping large HTTP ETags to CoAP = ETag options. You also should address the differences of strong and weak = etags. All CoAP ETags are strong.=20 Section 6.1 on URL syntax. The ABNF seems fine but some of the text = seem pretty redundant. I would probably drop section 6.3 and 6.4 all = together other than discussing the % encoding issue. Fine advice for = implementers but I think most people can parse a URL given the ABNF.=20 Drop the text "MUST fit within single IP datagram". I will just confuse = people and follows from other constraints.=20 Move the constants in section 9 up to section 4 to reduce reader = confusion.=20 I'm not a fan of the human readable error messages fields. They seldom = have anything of use for humans and they get used be vendors to stuff in = proprietary stuff that should have been in an option. I view them as = more harm than good. I expect I am in the "rough" on this so I would = prefer if they were not there but if other folks want them in, I don't = really care. They are often filled with bandwidth waisting text with = zero information content.=20 The term "origin server" is never defined. I would either just user = server or define what an origin server is.=20 The draft uses the term "safe" but it's not clear what changes because = of this. Some things are safe or not but no behavior changes based on = that so it seems a bit like mention some requests start with G and = others don't. You might consider dropping it.=20 For the responses codes that are like a HTTP response code. I'd rather = see this specification define what they mean in the context of CoAP = instead of reusing the HTTP ones. I worry about how an update to HTTP = might impact CoAP. In several places in the draft we have things like (U+0026 AMPERSAND). = These are for ascii characters in an ascii document. They should all be = removed to be consisted with the style of RFCs.=20 We need to pass of figuring out which references are normative and = informative. A few looked like they might be off to me but I did not = spend the time to check. This can happen a bit later but I did want to = flag it.=20 I plan to propose something new for the registration process for new = entries in in the CoAP Media Type Registry. Right now it looks too hard = to get a new entry in this this table.=20 Cullen <in my role as an individual contributor>= From fluffy@cisco.com Wed May 4 19:54:32 2011 Return-Path: <fluffy@cisco.com> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E169E06F5 for <core@ietfa.amsl.com>; Wed, 4 May 2011 19:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.602 X-Spam-Level: X-Spam-Status: No, score=-110.602 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lz7v-sbvG8GW for <core@ietfa.amsl.com>; Wed, 4 May 2011 19:54:31 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED37E06D1 for <core@ietf.org>; Wed, 4 May 2011 19:54:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=321; q=dns/txt; s=iport; t=1304564071; x=1305773671; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=ZemWlLHo0w4/KboXzL4syWhqzgdLsyaXNMKR4yYIOZ0=; b=FHWZRoGSsXs2tUu4xh/KoiN0Dr6q9ApzF/R7n8+PVjkRUpV/tDGaS5Pw 0aqMyUmT1J+VRq+uLb+sqnkL9L6o3V24RmF7yZ538YGqoUQEidk5k/qpo CUwE2E/qk3avwlTNQ08NXQ85bKwaYkJS3JvMdzcgx0amsFT5bbfZcduGA 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHIQwk2rRDoG/2dsb2JhbACmIHenT4EdniKGBwSGL4kGhByKPQ X-IronPort-AV: E=Sophos;i="4.64,318,1301875200"; d="scan'208";a="308710648" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-3.cisco.com with ESMTP; 05 May 2011 02:54:31 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p452sUtn006884 for <core@ietf.org>; Thu, 5 May 2011 02:54:30 GMT From: Cullen Jennings <fluffy@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 4 May 2011 20:54:30 -0600 Message-Id: <362C147D-48FB-490E-B5B1-E12474EA9C5E@cisco.com> To: core WG <core@ietf.org> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [core] Getting ready for WGLC of draft-ietf-core-coap X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 05 May 2011 02:54:32 -0000 There are not many remaining open issues for draft-ietf-core-coap. I = expect that this draft will be ready for a working group last call some = time soon. If people have concerns that could result in changes to the = on the wire protocol, now would be a good time to bring them up.=20 Cullen <CORE WG Co-Chair> From fluffy@cisco.com Wed May 4 20:10:21 2011 Return-Path: <fluffy@cisco.com> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B6C6E084C for <core@ietfa.amsl.com>; Wed, 4 May 2011 20:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.602 X-Spam-Level: X-Spam-Status: No, score=-110.602 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F0C6PfR9OYwH for <core@ietfa.amsl.com>; Wed, 4 May 2011 20:10:07 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id B43B4E06F5 for <core@ietf.org>; Wed, 4 May 2011 20:10:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1377; q=dns/txt; s=iport; t=1304565007; x=1305774607; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=LahX/kmprSLyAZTe9P/XDRhOWws0oRJPgmxNAqkv/5o=; b=Y9ZUXJwd1piikv0ypwVwVj/A+8/PMCyiPZ7V4TnQfwwbt5RMXlFWcBuX mepgeKaCzYaikezo8UXQm5mZwILEZcyjKZH6G7uJQ2zJlcJ/uJV4w1Xz1 2Np6iUY3OuW3eqplprQ/KJJh+Qvjbf53R0dymRU6ZQqNKnjxgdxWDWCgL M=; X-IronPort-AV: E=Sophos;i="4.64,318,1301875200"; d="scan'208";a="692205446" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-6.cisco.com with ESMTP; 05 May 2011 03:10:07 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p453A6Mu027064; Thu, 5 May 2011 03:10:07 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings <fluffy@cisco.com> In-Reply-To: <4DC1DCA0.6010608@cisco.com> Date: Wed, 4 May 2011 21:10:06 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <55A4B179-1559-4199-8CB3-E50C4B163B9D@cisco.com> References: <4DC1DCA0.6010608@cisco.com> To: paduffy@cisco.com X-Mailer: Apple Mail (2.1084) Cc: core <core@ietf.org> Subject: Re: [core] Client / server requirements for separate messaging X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 05 May 2011 03:10:21 -0000 I don't think this it has to do both. The confusing comes from it has to = be able to both send and receive CON messages and deal with the ACKS for = them. This is the same as an HTTP server needs to be able to deal with = sending data both ways on the TCP connection and ACKs both ways at the = TCP level. My understanding of the draft is that a node could act as a = CoAP server and only receive Requests and only send Responses. Just like = a HTTP server. But again, just like a HTTP server, at the transport = level it deals with receiving and sending ACKs. Similarly an end point = could only act as a client and only send Requests and get Responses. I = think some end points, particular ones doing pub/sub type stuff will = want to act as both a client and server.=20 On May 4, 2011, at 5:09 PM, Paul Duffy wrote: > This is going to sound confusing given the usage of client and server = in core-coap. >=20 > Do I assume correctly that a device MUST implement both a COAP client = and server? >=20 > Meaning not only MUST a device implement a client to send requests, = but MUST also implement a server to process COAP requests? >=20 > This to support the separate messaging pattern >=20 > Cheers >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From trac+core@trac.tools.ietf.org Wed May 4 22:10:53 2011 Return-Path: <trac+core@trac.tools.ietf.org> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CDF3E06C0 for <core@ietfa.amsl.com>; Wed, 4 May 2011 22:10:53 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J7GN4e2ww93T for <core@ietfa.amsl.com>; Wed, 4 May 2011 22:10:52 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 89D3DE0698 for <core@ietf.org>; Wed, 4 May 2011 22:10:52 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from <trac+core@trac.tools.ietf.org>) id 1QHqpv-0005qP-5z; Wed, 04 May 2011 22:10:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" <trac+core@trac.tools.ietf.org> 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: Thu, 05 May 2011 05:10:51 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/147 Message-ID: <051.8351ef873fe53636c3dcd4f8d8ba4313@trac.tools.ietf.org> X-Trac-Ticket-ID: 147 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] #147: Explain the difference between a Token and the Token Option X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 05 May 2011 05:10:53 -0000 #147: Explain the difference between a Token and the Token Option Explain more candidly that there is always a Token. Explain that a Token Option needs to be included if and only if the Token is different from the Token Option default value (empty string). Point to match rules (5.3) from Token Option (5.10.1). Expand on the text that explains the requirements for selecting a good Token value, and add that there are multiple implementation strategies for fulfilling these requirements. -- --------------------------------+------------------------------------------- Reporter: cabo@… | Owner: cabo@… Type: editorial | Status: new Priority: minor | Milestone: Component: coap | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/147> core <http://tools.ietf.org/core/> From cabo@tzi.org Wed May 4 22:12:03 2011 Return-Path: <cabo@tzi.org> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71526E06C0 for <core@ietfa.amsl.com>; Wed, 4 May 2011 22:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.205 X-Spam-Level: X-Spam-Status: No, score=-106.205 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e2wtVpCxCINK for <core@ietfa.amsl.com>; Wed, 4 May 2011 22:12:03 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 7B235E0698 for <core@ietf.org>; Wed, 4 May 2011 22:12:02 -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 p455BpbO006297; Thu, 5 May 2011 07:11:51 +0200 (CEST) Received: from [192.168.217.101] (p5B3E63AF.dip.t-dialin.net [91.62.99.175]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 5716EC8; Thu, 5 May 2011 07:11:51 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann <cabo@tzi.org> In-Reply-To: <D91E8A15-A1D7-4B2E-9C90-FBC0906A934E@cisco.com> Date: Thu, 5 May 2011 07:11:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0C28BC7D-1333-4ACD-BB19-A30373867BF0@tzi.org> References: <D91E8A15-A1D7-4B2E-9C90-FBC0906A934E@cisco.com> To: Cullen Jennings <fluffy@cisco.com> X-Mailer: Apple Mail (2.1084) Cc: core WG <core@ietf.org> Subject: Re: [core] draft-ietf-core-coap-06 What messages needs a Token X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 05 May 2011 05:12:03 -0000 On May 5, 2011, at 04:46, Cullen Jennings wrote: >=20 > As far as I can tell, all request and response need a token Yes. =20 Note that the Token Option has a default value (empty string), so all = requests and responses do have a Token, regardless of whether the option = is in a message or not. > as that is the only way to match them The match rules are defined in 5.3. They use more information than the = Token. > or suppress duplicates. Is this correct? No. Duplicate suppression is done using message IDs. > I could not find the text in the draft that really told me when a = Token was needed. Since there always is a Token, there is no such text. The text in 5.3 and 5.10.1 is meant to describe what the rules are for = choosing a value for the Token (where choosing a value different from = the empty string happens to mean that a Token Option needs to be in the = message). > The thread on the list did not enlighten me.=20 Clearly, we have an editorial issue here. I have created ticket #147. Gruesse, Carsten From trac+core@trac.tools.ietf.org Wed May 4 22:35:58 2011 Return-Path: <trac+core@trac.tools.ietf.org> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F07BE06BE for <core@ietfa.amsl.com>; Wed, 4 May 2011 22:35:58 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QRXjl5ekHkHu for <core@ietfa.amsl.com>; Wed, 4 May 2011 22:35:57 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id E3DB0E06AF for <core@ietf.org>; Wed, 4 May 2011 22:35:57 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from <trac+core@trac.tools.ietf.org>) id 1QHrED-0000BU-Sr; Wed, 04 May 2011 22:35:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" <trac+core@trac.tools.ietf.org> 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: Thu, 05 May 2011 05:35:57 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/148 Message-ID: <051.46ad6891968ef77f92643e00277adff8@trac.tools.ietf.org> X-Trac-Ticket-ID: 148 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] #148: Explain that message sizes should be chosen consciously X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 05 May 2011 05:35:58 -0000 #148: Explain that message sizes should be chosen consciously While CoAP defines message sizes up to slightly more than 1 KiB, these sizes are not appropriate for all applications. Explain more candidly that just because CoAP allows a range of messages sizes, this does not mean a non-constrained node should automatically choose large messages. Point to the -block specification to explain how to send smaller messages. -- --------------------------------+------------------------------------------- Reporter: cabo@… | Owner: cabo@… Type: editorial | Status: new Priority: minor | Milestone: Component: coap | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/148> core <http://tools.ietf.org/core/> From cabo@tzi.org Wed May 4 22:41:03 2011 Return-Path: <cabo@tzi.org> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E55DE0692 for <core@ietfa.amsl.com>; Wed, 4 May 2011 22:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.207 X-Spam-Level: X-Spam-Status: No, score=-106.207 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Myz5nUzepEq for <core@ietfa.amsl.com>; Wed, 4 May 2011 22:41:03 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 509D5E065A for <core@ietf.org>; Wed, 4 May 2011 22:41:01 -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 p455ep3E014331; Thu, 5 May 2011 07:40:51 +0200 (CEST) Received: from [192.168.217.101] (p5B3E63AF.dip.t-dialin.net [91.62.99.175]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 8AAFFCE; Thu, 5 May 2011 07:40:51 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann <cabo@tzi.org> In-Reply-To: <74924760-605F-40DA-8C1A-D9633BF1EE04@cisco.com> Date: Thu, 5 May 2011 07:40:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <E0A52131-8F8E-4B17-B400-E2D074DFFFD1@tzi.org> References: <74924760-605F-40DA-8C1A-D9633BF1EE04@cisco.com> To: Cullen Jennings <fluffy@cisco.com> X-Mailer: Apple Mail (2.1084) Cc: core WG <core@ietf.org> Subject: Re: [core] draft-ietf-core-coap-06 Fragmentation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 05 May 2011 05:41:03 -0000 On May 5, 2011, at 04:45, Cullen Jennings wrote: > Right now a node on fast v6 network will end up sending packets a bit = over 1024 in size.=20 I don't agree with that premise. The fact that the protocol allows you to use large messages does not = mean that end-points are forced to do that. Completely outlawing large messages is the wrong solution to this = problem. The more interesting question is how does a node that would like to use = large messages find out that this would be appropriate. Indeed, we = don't have a good answer on that. Worse, the way adaptation layer = (6LoWPAN) fragmentation is transparent means that there is absolutely no = way to find out how to avoid adaptation fragmentation (see section 2.7.2 = of the 6LoWPAN book). I think this is a separate issue that we won't solve in this protocol. On the editorial level, it probably wouldn't hurt to have text that = guides the implementer to not blindly send large messages. I have = created ticket #148. Gruesse, Carsten From cabo@tzi.org Wed May 4 22:55:10 2011 Return-Path: <cabo@tzi.org> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42E80E06C0 for <core@ietfa.amsl.com>; Wed, 4 May 2011 22:55:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.209 X-Spam-Level: X-Spam-Status: No, score=-106.209 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dVNEKuCwkhD7 for <core@ietfa.amsl.com>; Wed, 4 May 2011 22:55:09 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id F30ADE0692 for <core@ietf.org>; Wed, 4 May 2011 22:55:08 -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 p455svS7017236; Thu, 5 May 2011 07:54:57 +0200 (CEST) Received: from [192.168.217.101] (p5B3E63AF.dip.t-dialin.net [91.62.99.175]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id DF169D6; Thu, 5 May 2011 07:54:56 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann <cabo@tzi.org> In-Reply-To: <1FFCF0B6-2DF8-4776-BC6B-47069737AD50@cisco.com> Date: Thu, 5 May 2011 07:54:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2ECE1C68-6650-43D4-97B6-2D405143C845@tzi.org> References: <1FFCF0B6-2DF8-4776-BC6B-47069737AD50@cisco.com> To: Cullen Jennings <fluffy@cisco.com> X-Mailer: Apple Mail (2.1084) Cc: core WG <core@ietf.org> Subject: Re: [core] draft-ietf-core-coap-06 The CoAP/DTLS/CoAP Turkey Sandwich layer violation train wreck X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 05 May 2011 05:55:10 -0000 I don't get it. You can use any layering you want. All section 7.3 does is ensure DTLS (and STUN) and CoAP *can* coexist on = a single port if you want to. If your implementation techniques make you not want this, don't do that = then. Yes, the problems with, e.g., OpenSSL are real. But in our = implementations so far we need to insert a BIO shim there anyway because = OpenSSL makes assumptions about DTLS that aren't quite right. I read this as a rant that we should get a second port allocation for = CoAP over DTLS over UDP. I'm certainly fine with that. (This issue is, of course, related to the question on how to specify = security in a URI. See there.) Gruesse, Carsten From cabo@tzi.org Wed May 4 23:16:50 2011 Return-Path: <cabo@tzi.org> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 537B6E0791 for <core@ietfa.amsl.com>; Wed, 4 May 2011 23:16:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.211 X-Spam-Level: X-Spam-Status: No, score=-106.211 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EcuQqYy5qXni for <core@ietfa.amsl.com>; Wed, 4 May 2011 23:16:47 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 55728E0761 for <core@ietf.org>; Wed, 4 May 2011 23:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id p456Ganb023302; Thu, 5 May 2011 08:16:36 +0200 (CEST) Received: from [192.168.217.101] (p5B3E63AF.dip.t-dialin.net [91.62.99.175]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 2E5C9E9; Thu, 5 May 2011 08:16:36 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann <cabo@tzi.org> In-Reply-To: <292C0DCB-2B12-4F30-9FCD-370D4D20FD4B@cisco.com> Date: Thu, 5 May 2011 08:16:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <21B4A96E-6BC1-4E4C-B917-B5C5DBB43F46@tzi.org> References: <292C0DCB-2B12-4F30-9FCD-370D4D20FD4B@cisco.com> To: Cullen Jennings <fluffy@cisco.com> X-Mailer: Apple Mail (2.1084) Cc: core WG <core@ietf.org> Subject: Re: [core] draft-ietf-core-coap-06 What protocol X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 05 May 2011 06:16:50 -0000 On May 5, 2011, at 04:48, Cullen Jennings wrote: >=20 > Given a CoAP URI like coap:1.2.3.4/temp, do I try to connect with DTLS = or UDP? That depends on your security requirements. This is one of the places where CoAP is almost but not entirely unlike = HTTP. In HTTP, we have exactly two security models: no security, which we map = to http://, and security based on server certificates with a somewhat = volatile but well-known set of roots and TLS, which we map to https:// This model already breaks in practice with client certificates -- these = require lots of local configuration in the client that supplement the = information in the URI, which is one of the reasons client certificates = are rarely used. Where https:// is used with a different security model than the usual = global set of roots, this requires more configuration (often on both = sides). In CoAP, we have more ways to do security, and in particular more = security models (it is indeed rather unlikely that the usual global set = of roots model will be useful for a constrained device). So how do we hope to encode the desired selection of security parameters = in the URI? Having two schemes (a la coap/coaps) is not going to cut it = here. Even if I know that I should be using DTLS, which PSK identity do = I choose? As of today, this requires local configuration. I trust = that, over time, we will come up with extensions to the URI model that = will relieve us of some of this need -- but some configuration will = always be required for security. A related issue is the indication of the port number. In HTTP, http:// implies 80 and https:// implies 443, unless the port = number is explicitly given. These are completely separate resource spaces, i.e. http://a/foo is = completely unrelated to https://a/foo (even though it is often a good = idea to populate the spaces in parallel). In CoAP, a single resource may be accessible using multiple security = models. If you don't want to multiplex all those protocols on one port, = you would need to indicate the set of ports, one choice per security = protocol, in the URI. This hasn't been done before. Gruesse, Carsten From prvs=610604DACA=guido.moritz@uni-rostock.de Thu May 5 05:21:51 2011 Return-Path: <prvs=610604DACA=guido.moritz@uni-rostock.de> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5649AE0721 for <core@ietfa.amsl.com>; Thu, 5 May 2011 05:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.876 X-Spam-Level: X-Spam-Status: No, score=-0.876 tagged_above=-999 required=5 tests=[AWL=0.514, BAYES_20=-0.74, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jnc+l1-Sibp7 for <core@ietfa.amsl.com>; Thu, 5 May 2011 05:21:48 -0700 (PDT) Received: from mailrelay1.uni-rostock.de (mailrelay1.uni-rostock.de [139.30.8.201]) by ietfa.amsl.com (Postfix) with ESMTP id BAA07E073A for <core@ietf.org>; Thu, 5 May 2011 05:21:46 -0700 (PDT) From: Guido Moritz <guido.moritz@uni-rostock.de> To: 'core' <core@ietf.org> Date: Thu, 5 May 2011 14:21:48 +0200 Message-ID: <008d01cc0b1f$015d3880$0417a980$@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: AcwLHrwKJmFCcWV8QBCrrCGiYzHAqg== Content-Language: de X-Originating-IP: [139.30.201.226] Subject: [core] Payload for PUT or POST in coap-06 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 05 May 2011 12:21:51 -0000 Dear all, in Prague we discussed (and i guess we agreed), to enable payload with 2.04, 2.01 and/or provide a generic 2.00 OK for generic POST responses. See slide 31 in http://www.ietf.org/proceedings/80/slides/core-0.pdf . But I don't see any of these in the text and hence still no response payload for POST in coap-06!? Best, Guido From prvs=0106EF68B6=guido.moritz@uni-rostock.de Thu May 5 06:07:42 2011 Return-Path: <prvs=0106EF68B6=guido.moritz@uni-rostock.de> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD7AE0724 for <core@ietfa.amsl.com>; Thu, 5 May 2011 06:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[AWL=1.315, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sm-FYx33mUTR for <core@ietfa.amsl.com>; Thu, 5 May 2011 06:07:41 -0700 (PDT) Received: from mailrelay1.uni-rostock.de (mailrelay1.uni-rostock.de [139.30.8.201]) by ietfa.amsl.com (Postfix) with ESMTP id 30967E073A for <core@ietf.org>; Thu, 5 May 2011 06:07:40 -0700 (PDT) From: Guido Moritz <guido.moritz@uni-rostock.de> To: 'core' <core@ietf.org> Date: Thu, 5 May 2011 15:07:42 +0200 Message-ID: <009101cc0b25$6b34f530$419edf90$@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: AcwLG4ztt4tMhpXpQraPYl3dCFu8xg== Content-Language: de X-Originating-IP: [139.30.201.226] Subject: [core] block-03 parallel usage example X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 05 May 2011 13:07:42 -0000 Dear block-03 authors, I read through the block-03 draft and to be honest, section 2 (especially 2.2) is quite hard to follow... Very much compressed information. As far as I see, there is still a possibility to use blockwise transfer for both request and response at the same time. May we have an example of this in the draft? As far as I understand, there are two different CoAP message exchanges required: (1) The first message exchange using B1 in the REQ to indicate which block of the REQ is carried in the payload. The ACK is using B1 to ACK the according block, setting M=1. (2) Another message exchange as RES with B2, indicating the current block in the RES and B1 to ACK, with M bit of B1 to ignore. I am not sure if B1 of block-03 is allowed to be used for this case? I tried to put this in a figure. Nevertheless, since POST still has no response code carrying payload (see my mail a few minutes ago), I just used 2.00 OK for this. Comments are welcome... CLIENT SERVER | | | CON [MID=1234], POST, /options, v17, 1/0/1/128 ------> | | | | <------ ACK [MID=1234], 1/0/1/128 | | | | CON [MID=1235], POST, /options, v17, 1/1/1/128 ------> | | | | <------ ACK [MID=1235], 1/1/1/128 | | | | CON [MID=1236], POST, /options, v17, 1/2/0/128 ------> | | | | <------ ACK [MID=1236], 1/2/1/128 | | | ...time passes... | | | <------ CON [MID=2345], 2.00 OK, v17, 2/0/1/128 | | | | ACK [MID=2345], 1/0/x/128 ------> | | | | <------ CON [MID=2346], 2.00 OK, v17, 2/1/1/128 | | | | ACK [MID=2346], 1/1/x/128 ------> | | | | <------ CON [MID=2347], 2.00 OK, v17, 2/2/0/128 | | | | ACK [MID=2347], 1/2/x/128 ------> | Best, Guido From alper.yegin@yegin.org Thu May 5 08:04:01 2011 Return-Path: <alper.yegin@yegin.org> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C24DEE0719 for <core@ietfa.amsl.com>; Thu, 5 May 2011 08:04:01 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qhCVDNW7ntYY for <core@ietfa.amsl.com>; Thu, 5 May 2011 08:04:00 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id BAE8BE06A6 for <core@ietf.org>; Thu, 5 May 2011 08:04:00 -0700 (PDT) Received: from ibm (dsl88-247-34762.ttnet.net.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0LpbRu-1Pnb1L3N1K-00f8b2; Thu, 05 May 2011 11:03:56 -0400 From: "Alper Yegin" <alper.yegin@yegin.org> To: "'Cullen Jennings'" <fluffy@cisco.com>, "'core WG'" <core@ietf.org> References: <239072CD-ACC0-454D-8BD6-30AC28D425D9@cisco.com> In-Reply-To: <239072CD-ACC0-454D-8BD6-30AC28D425D9@cisco.com> Date: Thu, 5 May 2011 18:03:50 +0300 Message-ID: <059f01cc0b35$a785fc90$f691f5b0$@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: AcwKz03/xuvBPdjOQGSMTrJfBoD+6gAZZurQ Content-Language: en-us X-Provags-ID: V02:K0:1Mfma6JaMdv7AtrnfVdmyRLI4s/uaJUwNJVWagoYL9H 7oCb0BRLSxtKCW+hTtKuGdwQW21vcyR2/PnfRR/xpueGgExpp1 o1QPO9dD+rZKRycXO0DLG0v8VWviV9loVnx0Usg5JqzzKhDLS+ UJifgN0ibYlkzD94XX9j77ozNAHBawkw+k9xsIvkInk1hZbJ5p /x1zxULr3+aiRyLXuqibc5IDyicRwbABPVGrr6uu7c= Subject: Re: [core] draft-ietf-core-coap-06 Security X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 05 May 2011 15:04:01 -0000 Hi Cullen, I think it is essential that the protocol can be secured when there are pre-provisioned credentials on the devices. I think we are covered on that front. If you are talking about specifying mechanisms about how those credentials got on the devices, the simplest is to say they are burned in by the manufacturer. If you want to take one more step, i.e. specifying some dynamic over-the-air provisioning of credentials, I think this is getting beyond Core scope. That by itself is a large problem and not that specific to Core. It needs to be scoped in very detail, and most possibly it already applies to non-core scenarios as well. My 0.02 cents. Alper > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of > Cullen Jennings > Sent: Thursday, May 05, 2011 5:51 AM > To: core WG > Subject: [core] draft-ietf-core-coap-06 Security > > > > I think it will be very hard to leave keying for the security out of > scope of this specification. I realize there are other drafts in > progress on this and I look forward to their rapid arrival. Even when > using DTLS Certificate mode, any connection can have a man in the > middle attack as their is not binding of who we are trying to connect > to material in the certificate. This seems like a big problem. Related > to this, for many protocols the assumption that someone with a keyboard > and screen will manually type something into the device as out of band > security configuration is reasonable. Give the use cases this WG was > formed to solve, it is not an reasonable assumption for this WG. > > > Cullen <in my role as an individual contributor> > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From fluffy@cisco.com Thu May 5 10:46:56 2011 Return-Path: <fluffy@cisco.com> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC77FE08E5 for <core@ietfa.amsl.com>; Thu, 5 May 2011 10:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.602 X-Spam-Level: X-Spam-Status: No, score=-110.602 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCcXsMKQqRgN for <core@ietfa.amsl.com>; Thu, 5 May 2011 10:46:56 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id F2E9CE08D8 for <core@ietf.org>; Thu, 5 May 2011 10:46:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1287; q=dns/txt; s=iport; t=1304617616; x=1305827216; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=bRBkArHelhiLuIP3HbSVkfm7b2b7BK93YovrFd58TpA=; b=AXsNH4xjsblzHL6iFsUgRQ2MiQUI/xRUAAFwyOBnoIXre12MPTmzdw/K uuUl8vE74ZHHNBNYONb8SZAUzoOuu/9T3OfhrwgRu3Wi00Ig91QbPXP77 ugCImND9qh43FPQD3U85AbqQqJr7msYxDGR0BykateE+BDO6Ln9VjJpun 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEDiwk2rRDoI/2dsb2JhbACmPXenGJ48hgcEhjiJEoQjiks X-IronPort-AV: E=Sophos;i="4.64,321,1301875200"; d="scan'208";a="309254437" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-3.cisco.com with ESMTP; 05 May 2011 17:46:55 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p45HkqhX001660; Thu, 5 May 2011 17:46:53 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings <fluffy@cisco.com> In-Reply-To: <B94FCCE0-D974-476A-A5BD-36C3ECBFBCAD@sensinode.com> Date: Thu, 5 May 2011 11:46:52 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <2E134EBF-4C6C-4ACE-84B9-2575C7AE6159@cisco.com> References: <8B55B68A-3EA2-45F6-8624-6617333C656D@sensinode.com> <6F58467D-2355-45FA-A32A-880302EEF22C@tzi.org> <B94FCCE0-D974-476A-A5BD-36C3ECBFBCAD@sensinode.com> To: Zach Shelby <zach@sensinode.com> X-Mailer: Apple Mail (2.1084) Cc: core WG <core@ietf.org> Subject: Re: [core] ABNF help X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 05 May 2011 17:46:56 -0000 On May 3, 2011, at 3:01 AM, Zach Shelby wrote: >>>=20 >>> and sz has a digit range of 0-4294967295.=20 >>=20 >> It is not even clear to me that we have a natural limit of < 4 GiB. >> Why not leave that open? If a node has an mp4 of the royal wedding, = it might not fit anyway :-) >=20 > So you are a royalist? :-) You are probably right, we can just leave = the range for sz open. I don't care if you set the limit at 128 bits but I really prefer some = limit. When I go to implement this, I need to assume something. I = understand the idea of just having some way to represent "big" numbers = but that does not work well for many situations. For example, firewalls = often check that messages are compliant with the syntax and = "reasonable", they will choose to enforce what they believe is a = "reasonable" upper limit. If you specify one, they will use that, if you = don't specify one, they will choose something you may not like. Same for = someone writing a library. I can easily imaging many library = implementers thinking they could use 16 bits for this while others might = choose 32.=20 As far as the ABNF, I'd be fine with a comment such as=20 integer32 =3D 1*DIGIT ; Must be in range of 0-4294967295 with = no leading zero=20 From fluffy@cisco.com Thu May 5 11:13:43 2011 Return-Path: <fluffy@cisco.com> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1015E079C for <core@ietfa.amsl.com>; Thu, 5 May 2011 11:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.601 X-Spam-Level: X-Spam-Status: No, score=-110.601 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92q9xRkmIqJC for <core@ietfa.amsl.com>; Thu, 5 May 2011 11:13:42 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id EA40EE0688 for <core@ietf.org>; Thu, 5 May 2011 11:13:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=3815; q=dns/txt; s=iport; t=1304619222; x=1305828822; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=UcJdWcLPaSy2AZbe33iKmRGfx3Pz4VAlZIn5FDP+QEg=; b=ET6dWG8y/0bXog9qT7JVO18PcpPgmhF95TXrxidAgx4rxzIqz2/wSnb2 S/1iPhufgfPJvL/ftBIAAfYRm+hHR0I5WTfN3vEaovCMs1MaHR0t6urjR gYyW/mv1UbnSvZ+zY/AC8h/go5nswsWnQtk6AyJPVvZDkiryQe9SfZndZ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj8BAILowk2rRDoI/2dsb2JhbACYFo4nd4hyniyeQIYHBIY4iRKEI4pL X-IronPort-AV: E=Sophos;i="4.64,321,1301875200"; d="scan'208";a="351200234" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 05 May 2011 18:13:42 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p45IDf4A024846; Thu, 5 May 2011 18:13:41 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings <fluffy@cisco.com> In-Reply-To: <059f01cc0b35$a785fc90$f691f5b0$@yegin@yegin.org> Date: Thu, 5 May 2011 12:13:40 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <720981EA-6411-4A5C-AC8C-675ADA1A2DE5@cisco.com> References: <239072CD-ACC0-454D-8BD6-30AC28D425D9@cisco.com> <059f01cc0b35$a785fc90$f691f5b0$@yegin@yegin.org> To: Alper Yegin <alper.yegin@yegin.org> X-Mailer: Apple Mail (2.1084) Cc: 'core WG' <core@ietf.org> Subject: Re: [core] draft-ietf-core-coap-06 Security X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 05 May 2011 18:13:43 -0000 On May 5, 2011, at 9:03 AM, Alper Yegin wrote: > Hi Cullen, >=20 > I think it is essential that the protocol can be secured when there = are > pre-provisioned credentials on the devices. I think we are covered on = that > front. In the Certificate mode, I do not see how we are covered from on path = attackers - but I could easily be missing some critical part of the = draft - I just don't see how the security works yet. For example if A = wants to send a message to B and E is an on path attacker. E can MITM = the DTLS and do whatever they want to the messaging. People keep telling = me that solving that problem is out of scope for CoAP. Just about all = the other IETF protocols I have worked on consider that problem in = scope. I have a hard time imagining this draft getting past IESG with = that out of scope. =20 I'm not trying to push any particular solution to this - I just think we = need some solution to it. Given out deployment environment, I don't see = how to easily to solve without also dealing with some of the issues = people wish were out of scope.=20 >=20 > If you are talking about specifying mechanisms about how those = credentials > got on the devices, the simplest is to say they are burned in by the > manufacturer. I think it's worth breaking this into two cases. One where the = credentials was a shared symmetric key of some sort and are the same = across all devices. Then there is the case where the credential is a = manufacture installed certificate. Those are pretty different. In the = first case, the security is not really there and in the second case, I = still don't see how CoAP solves the attack I mentioned above.=20 I may have misread the current draft and I could easily be confused = about the how things work. So lets start with where you have a different = point of view than me.=20 I guess the first is question is if we need to actually protect against = attacks such as the on path MITM? The second would be are you thinking manufacture installed certs would = do this and if so how? or is there a different type of credential you = were thinking of for this?=20 >=20 > If you want to take one more step, i.e. specifying some dynamic = over-the-air > provisioning of credentials, I think this is getting beyond Core = scope. That > by itself is a large problem and not that specific to Core. It needs = to be > scoped in very detail, and most possibly it already applies to = non-core > scenarios as well. >=20 > My 0.02 cents. >=20 > Alper >=20 >=20 >=20 >=20 >> -----Original Message----- >> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf = Of >> Cullen Jennings >> Sent: Thursday, May 05, 2011 5:51 AM >> To: core WG >> Subject: [core] draft-ietf-core-coap-06 Security >>=20 >>=20 >>=20 >> I think it will be very hard to leave keying for the security out of >> scope of this specification. I realize there are other drafts in >> progress on this and I look forward to their rapid arrival. Even when >> using DTLS Certificate mode, any connection can have a man in the >> middle attack as their is not binding of who we are trying to connect >> to material in the certificate. This seems like a big problem. = Related >> to this, for many protocols the assumption that someone with a = keyboard >> and screen will manually type something into the device as out of = band >> security configuration is reasonable. Give the use cases this WG was >> formed to solve, it is not an reasonable assumption for this WG. >>=20 >>=20 >> Cullen <in my role as an individual contributor> >>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >=20 From fluffy@cisco.com Thu May 5 11:18:54 2011 Return-Path: <fluffy@cisco.com> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F299DE0916 for <core@ietfa.amsl.com>; Thu, 5 May 2011 11:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.601 X-Spam-Level: X-Spam-Status: No, score=-110.601 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JDh+yiPrCcex for <core@ietfa.amsl.com>; Thu, 5 May 2011 11:18:54 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id DFDCFE08F8 for <core@ietf.org>; Thu, 5 May 2011 11:18:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1371; q=dns/txt; s=iport; t=1304619532; x=1305829132; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=t17fwd7l1dgrpGEtEZAus1L4WiPoV3tCdCN31acroX0=; b=KynJ+4Ua4L3fgNsSaGbCmIGJ8sXcra9VKLaqqePumfY4h8iu+NvvfUD+ QQHb5oS+3Rg2k2c1rSveuH3wETTZIFjWZrRJo529VCM+V4Wb+Dev9ALjU +MQZ9fuMjB8ACY0/CY+l1W4Qb6+YBPUD7KLQv3/W1pAbr7lrGAGUCl4OK 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALXpwk2rRDoH/2dsb2JhbACmPXeIcp4hnkCGBwSGOIkShCOKSw X-IronPort-AV: E=Sophos;i="4.64,322,1301875200"; d="scan'208";a="351203860" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-2.cisco.com with ESMTP; 05 May 2011 18:18:52 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p45IIp1N000984; Thu, 5 May 2011 18:18:52 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings <fluffy@cisco.com> In-Reply-To: <0C28BC7D-1333-4ACD-BB19-A30373867BF0@tzi.org> Date: Thu, 5 May 2011 12:18:51 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <D501C905-2E7F-4634-BFA3-0D6E7C62BAD3@cisco.com> References: <D91E8A15-A1D7-4B2E-9C90-FBC0906A934E@cisco.com> <0C28BC7D-1333-4ACD-BB19-A30373867BF0@tzi.org> To: Carsten Bormann <cabo@tzi.org> X-Mailer: Apple Mail (2.1084) Cc: core WG <core@ietf.org> Subject: Re: [core] draft-ietf-core-coap-06 What messages needs a Token X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 05 May 2011 18:18:55 -0000 I went back and reread section 5.3 after reading your email and I see = what you are saying. Draft looks like it has the right normative = statements in it. On May 4, 2011, at 11:11 PM, Carsten Bormann wrote: > On May 5, 2011, at 04:46, Cullen Jennings wrote: >=20 >>=20 >> As far as I can tell, all request and response need a token >=20 > Yes. =20 >=20 > Note that the Token Option has a default value (empty string), so all = requests and responses do have a Token, regardless of whether the option = is in a message or not. >=20 >> as that is the only way to match them >=20 > The match rules are defined in 5.3. They use more information than = the Token. >=20 >> or suppress duplicates. Is this correct? >=20 > No. Duplicate suppression is done using message IDs. >=20 >> I could not find the text in the draft that really told me when a = Token was needed. >=20 > Since there always is a Token, there is no such text. > The text in 5.3 and 5.10.1 is meant to describe what the rules are for = choosing a value for the Token (where choosing a value different from = the empty string happens to mean that a Token Option needs to be in the = message). >=20 >> The thread on the list did not enlighten me.=20 >=20 > Clearly, we have an editorial issue here. I have created ticket #147. >=20 > Gruesse, Carsten >=20 >=20 From cabo@tzi.org Thu May 5 11:26:20 2011 Return-Path: <cabo@tzi.org> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A4F0E0942 for <core@ietfa.amsl.com>; Thu, 5 May 2011 11:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.213 X-Spam-Level: X-Spam-Status: No, score=-106.213 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GtrNBKsgakHW for <core@ietfa.amsl.com>; Thu, 5 May 2011 11:26:19 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 50D8FE093C for <core@ietf.org>; Thu, 5 May 2011 11:26:18 -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 p45IQ9JP027240; Thu, 5 May 2011 20:26:09 +0200 (CEST) Received: from [192.168.217.112] (p5B3E63AF.dip.t-dialin.net [91.62.99.175]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 46EE353C; Thu, 5 May 2011 20:26:09 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann <cabo@tzi.org> In-Reply-To: <720981EA-6411-4A5C-AC8C-675ADA1A2DE5@cisco.com> Date: Thu, 5 May 2011 20:26:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0C0F0EC0-190D-402A-B894-A5213B33934A@tzi.org> References: <239072CD-ACC0-454D-8BD6-30AC28D425D9@cisco.com> <059f01cc0b35$a785fc90$f691f5b0$@yegin@yegin.org> <720981EA-6411-4A5C-AC8C-675ADA1A2DE5@cisco.com> To: Cullen Jennings <fluffy@cisco.com> X-Mailer: Apple Mail (2.1084) Cc: 'core WG' <core@ietf.org> Subject: Re: [core] draft-ietf-core-coap-06 Security X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 05 May 2011 18:26:20 -0000 Maybe I don't fully understand this discussion. Let me try. > For example if A wants to send a message to B and E is an on path = attacker. E can MITM the DTLS and do whatever they want to the = messaging. Yes. However, if A or B do care about B's or A's identity, they can = check it. (I'm talking about certificates. That MITM is not possible with = pairwise PSKs.) > I guess the first is question is if we need to actually protect = against attacks such as the on path MITM? I do think we need to be able to. > The second would be are you thinking manufacture installed certs would = do this and if so how? or is there a different type of credential you = were thinking of for this?=20 Again, if A cares about B's identity, and that identity is in the cert, = we're fine. Of course, that doesn't help with bootstrapping communication to an = entity that you don't know the identity of yet, which may be more = relevant in the Home Control scenario. So, if I buy a lightbulb, my = phone can easily find out that its certificate is chained to its = manufacturer, but that doesn't help against a neighbor bringing up a = lightbulb from the same manufacturer at the same time. That's where you = either need leap-of-faith or identity labels or other OOB mechanisms. = (And if I use those, I might as well get rid of certificates. But that = is a separate discussion.) Gruesse, Carsten From fluffy@cisco.com Thu May 5 11:29:21 2011 Return-Path: <fluffy@cisco.com> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82F3FE093C for <core@ietfa.amsl.com>; Thu, 5 May 2011 11:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.601 X-Spam-Level: X-Spam-Status: No, score=-110.601 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0l-a8cdJDP6v for <core@ietfa.amsl.com>; Thu, 5 May 2011 11:29:20 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id D1FEDE07B3 for <core@ietf.org>; Thu, 5 May 2011 11:29:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=2180; q=dns/txt; s=iport; t=1304620160; x=1305829760; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=+3soHU70b/Okfh+7vHanLZ7bRt7b4nIELY8q4F5FZPw=; b=A8lrDrl0NoibVQr5NToDK+YJl0eCAt6y/s7IARvG+EAhYo0UnSZs/khg Ga6v1W15butmlz/b0TjU25onzFaF1OsVEQYhovOsKzp/QcV6uv57YE7e/ Ryk7DMrRnG9/xDqOgwBbGD4M5psu1MdNSZrmY1zjbQNSdxhaGuIHv1i4e w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAnswk2rRDoH/2dsb2JhbACmPXeIcp4xnj2GBwSGOIkShCOKSw X-IronPort-AV: E=Sophos;i="4.64,322,1301875200"; d="scan'208";a="351211627" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-2.cisco.com with ESMTP; 05 May 2011 18:29:18 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p45ITFcc010792; Thu, 5 May 2011 18:29:16 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings <fluffy@cisco.com> In-Reply-To: <E0A52131-8F8E-4B17-B400-E2D074DFFFD1@tzi.org> Date: Thu, 5 May 2011 12:29:15 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <08E23464-B9FD-4DBE-84F2-C619E802D7D7@cisco.com> References: <74924760-605F-40DA-8C1A-D9633BF1EE04@cisco.com> <E0A52131-8F8E-4B17-B400-E2D074DFFFD1@tzi.org> To: Carsten Bormann <cabo@tzi.org> X-Mailer: Apple Mail (2.1084) Cc: core WG <core@ietf.org> Subject: Re: [core] draft-ietf-core-coap-06 Fragmentation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 05 May 2011 18:29:21 -0000 On May 4, 2011, at 11:40 PM, Carsten Bormann wrote: > On May 5, 2011, at 04:45, Cullen Jennings wrote: >=20 >> Right now a node on fast v6 network will end up sending packets a bit = over 1024 in size.=20 >=20 > I don't agree with that premise. Bottom of page 13 has a if the path mtu is not known, assume 1280 and = then goes on to tell implementers to use 11152 and 1024. Have a look, = perhaps I am just reading this the wrong way.=20 >=20 > The fact that the protocol allows you to use large messages does not = mean that end-points are forced to do that. The spec can tell you the limits on what you may do but it also needs to = tell you what to do such that if you implement the spec it will be = useful.=20 >=20 > Completely outlawing large messages is the wrong solution to this = problem. I was not proposing outlawing large message if you had something like = path mtu discover, I was saying that when you did not have PTMUD, we had = already outlawed larges messages by setting the limit to 1280 but that = the number 1280 was too large and we needed a smaller number. We already = had outlawed large messages when there is no PTMUD, we are just = discussing the price, I mean size.=20 >=20 > The more interesting question is how does a node that would like to = use large messages find out that this would be appropriate. Indeed, we = don't have a good answer on that. Worse, the way adaptation layer = (6LoWPAN) fragmentation is transparent means that there is absolutely no = way to find out how to avoid adaptation fragmentation (see section 2.7.2 = of the 6LoWPAN book). >=20 > I think this is a separate issue that we won't solve in this protocol. Agree, I'm not a fan of trying to define a workable PTMUD algorithm in = this specification. >=20 > On the editorial level, it probably wouldn't hurt to have text that = guides the implementer to not blindly send large messages. I have = created ticket #148. What I am looking for is enough advice in the spec that an implementor = will end up implementing something that works in the use case I = mentioned.=20 >=20 > Gruesse, Carsten >=20 From fluffy@cisco.com Thu May 5 11:46:30 2011 Return-Path: <fluffy@cisco.com> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0929E0939 for <core@ietfa.amsl.com>; Thu, 5 May 2011 11:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.601 X-Spam-Level: X-Spam-Status: No, score=-110.601 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bxg4TR8iBbcP for <core@ietfa.amsl.com>; Thu, 5 May 2011 11:46:30 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 458FDE0947 for <core@ietf.org>; Thu, 5 May 2011 11:46:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=4207; q=dns/txt; s=iport; t=1304621188; x=1305830788; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=zVIocTYBtZhlGkd8IYvdZlAuNETy5Oi/j0cRqccdxnY=; b=aAsm/OMtQVo9BvgEuKp0x/4f/aomTxmsPqWBoPOvf1tkkXS7z0/dV69N lVUQ+WQe9RbqoSUSqALC5NwtwKqDMu5fZ8iSOrjh0WKXbClcZ0C4NTgLN hC/5aYc+jJXU6GSpfOw7yNUgbhwuRqlYpluz1+v7g+QRKKhXkt8t1rG1m 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEjwwk2rRDoG/2dsb2JhbACmPXeIcp4rnjyDC4J8BIY4iRKEI4pL X-IronPort-AV: E=Sophos;i="4.64,322,1301875200"; d="scan'208";a="442514837" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-1.cisco.com with ESMTP; 05 May 2011 18:46:09 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p45Ik8x0023667; Thu, 5 May 2011 18:46:09 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings <fluffy@cisco.com> In-Reply-To: <21B4A96E-6BC1-4E4C-B917-B5C5DBB43F46@tzi.org> Date: Thu, 5 May 2011 12:46:08 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <DC19862A-8717-4E36-960A-4A62AD8C7708@cisco.com> References: <292C0DCB-2B12-4F30-9FCD-370D4D20FD4B@cisco.com> <21B4A96E-6BC1-4E4C-B917-B5C5DBB43F46@tzi.org> To: Carsten Bormann <cabo@tzi.org> X-Mailer: Apple Mail (2.1084) Cc: core WG <core@ietf.org> Subject: Re: [core] draft-ietf-core-coap-06 What protocol X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 05 May 2011 18:46:30 -0000 Configuration is fine for a private network but CoAP is being designed = to also be used on the internet and assuming that every node knows about = the configuration of every other node does not an assumption I want to = make. I'd like to see it such we have a reasonable algorithm for = resolving an URL. I'm fine with also supporting configuration for other = types of deployments - obviously private networks are also a huge use = case for CoAP - but I'm mostly concerned with the internet case.=20 On May 5, 2011, at 12:16 AM, Carsten Bormann wrote: > On May 5, 2011, at 04:48, Cullen Jennings wrote: >=20 >>=20 >> Given a CoAP URI like coap:1.2.3.4/temp, do I try to connect with = DTLS or UDP? >=20 > That depends on your security requirements. >=20 > This is one of the places where CoAP is almost but not entirely unlike = HTTP. >=20 > In HTTP, we have exactly two security models: no security, which we = map to http://, and security based on server certificates with a = somewhat volatile but well-known set of roots and TLS, which we map to = https:// >=20 > This model already breaks in practice with client certificates -- = these require lots of local configuration in the client that supplement = the information in the URI, which is one of the reasons client = certificates are rarely used. we disagree here but probably not really relevant to current discussion. >=20 > Where https:// is used with a different security model than the usual = global set of roots, this requires more configuration (often on both = sides). >=20 > In CoAP, we have more ways to do security, and in particular more = security models (it is indeed rather unlikely that the usual global set = of roots model will be useful for a constrained device). Well this is still a ways from nailed down but I would hope that NoSec = and Certificate mode deployments were usable in a internet context while = SharedKey and MultKey are restrict more or less by definition. Note the = resolution approach for Shared / Mult Key / certificate is pretty easy = if you know you are not doing NoSec. If you have a Shared or MultiKey = configured to the destination, you use it, otherwise you use the = Certificate. TLS is already good at negotiating all this sort of stuff. = The questions is how you know if you are in the UDP mode or a mode that = use DTLS. Having a coap & coaps scheme is probably the obvious way to do = this given we can't use DNS SRV. It nicely mirrors HTTP, is easy to = understand and I can't see any reason it would not work. We could do = with other ways too.=20 >=20 > So how do we hope to encode the desired selection of security = parameters in the URI? Having two schemes (a la coap/coaps) is not = going to cut it here. Even if I know that I should be using DTLS, which = PSK identity do I choose? As of today, this requires local = configuration. I trust that, over time, we will come up with extensions = to the URI model that will relieve us of some of this need -- but some = configuration will always be required for security. >=20 > A related issue is the indication of the port number. I view this as not related - even if we had two schemes, we could given = the different or the same default port numbers.=20 >=20 > In HTTP, http:// implies 80 and https:// implies 443, unless the port = number is explicitly given. > These are completely separate resource spaces, i.e. http://a/foo is = completely unrelated to https://a/foo (even though it is often a good = idea to populate the spaces in parallel). Not sure where you are going - here... clearly the resource returned can = be different in CoAP depending on any characteristic of the request = including who made it, how it was authenticated, of if it was over DTLS = or not.=20 >=20 > In CoAP, a single resource may be accessible using multiple security = models. If you don't want to multiplex all those protocols on one port, = you would need to indicate the set of ports, one choice per security = protocol, in the URI. This hasn't been done before. >=20 > Gruesse, Carsten >=20 Cullen <in my individual contributor role> From cabo@tzi.org Thu May 5 11:50:06 2011 Return-Path: <cabo@tzi.org> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FBF8E07B3 for <core@ietfa.amsl.com>; Thu, 5 May 2011 11:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.214 X-Spam-Level: X-Spam-Status: No, score=-106.214 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M9Vgm0SaGncs for <core@ietfa.amsl.com>; Thu, 5 May 2011 11:50:05 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id F14B7E08C2 for <core@ietf.org>; Thu, 5 May 2011 11:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id p45InrLI003245; Thu, 5 May 2011 20:49:53 +0200 (CEST) Received: from [192.168.217.112] (p5B3E63AF.dip.t-dialin.net [91.62.99.175]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 031FE556; Thu, 5 May 2011 20:49:52 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann <cabo@tzi.org> In-Reply-To: <2E134EBF-4C6C-4ACE-84B9-2575C7AE6159@cisco.com> Date: Thu, 5 May 2011 20:49:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0BB25274-EA3E-400A-8383-1BDB8DD0FB94@tzi.org> References: <8B55B68A-3EA2-45F6-8624-6617333C656D@sensinode.com> <6F58467D-2355-45FA-A32A-880302EEF22C@tzi.org> <B94FCCE0-D974-476A-A5BD-36C3ECBFBCAD@sensinode.com> <2E134EBF-4C6C-4ACE-84B9-2575C7AE6159@cisco.com> To: Cullen Jennings <fluffy@cisco.com> X-Mailer: Apple Mail (2.1084) Cc: core WG <core@ietf.org> Subject: Re: [core] ABNF help X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 05 May 2011 18:50:06 -0000 > I really prefer some limit.=20 Note that there has been a brief discussion about artificial limitations = like this going on in httpbis. http://lists.w3.org/Archives/Public/ietf-http-wg/2011AprJun/0137.html (Unfortunately, that then quickly ratholed into a discussion about the = User-Agent header field.) I don't think there is any proposal to change Content-Length =3D 1*DIGIT in draft-ietf-httpbis-p1-messaging. I believe we should follow HTTP's lead here. Any artificial limitation we come up with will be so high that most = people will need to do the "Big" thing anyway. (If we have to, I'd = stick with 1208925819614629174706175, which takes 288 years to transfer = on a Pbit/s link, which sounds about right. For this century. = 9223372036854775807 might do in a pinch.) (But, yes, I'd like to see the link-format ABNF for ct and sz as integer =3D "0"=20 / %x31-39 *DIGIT=20 please -- "integer" could also be renamed to a term for non-negative = integers, such as "cardinal".) Gruesse, Carsten From fluffy@cisco.com Thu May 5 11:50:52 2011 Return-Path: <fluffy@cisco.com> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A26EE08C2 for <core@ietfa.amsl.com>; Thu, 5 May 2011 11:50:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.601 X-Spam-Level: X-Spam-Status: No, score=-110.601 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6iAxJU20OphA for <core@ietfa.amsl.com>; Thu, 5 May 2011 11:50:51 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 43892E07B3 for <core@ietf.org>; Thu, 5 May 2011 11:50:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1164; q=dns/txt; s=iport; t=1304621451; x=1305831051; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=oOpuyBo487rPlXWa/RiUnB8CR5WCXdmC/LSOmM6Ofqg=; b=MAjg9VDLmmieyszFIuXwbzkvo3g0YAjaI2DVdTEcwKdC5u97J0BuGid5 sS1iYQonyx05Mgx3C1ksbM0CLJUwjMxBD+EWigGbERxVZuaOOSNVuXoAh aviFN00AwQrJwGuLmG6iELK3CoSxj9G5gsin0VEzn4oU1PiQ4fimzbmzb U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEjwwk2rRDoJ/2dsb2JhbACmPXeIcp4rnjyCK4NcBIY4iRKEI4pL X-IronPort-AV: E=Sophos;i="4.64,322,1301875200"; d="scan'208";a="309303342" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 05 May 2011 18:50:49 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p45Iomca026468; Thu, 5 May 2011 18:50:49 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings <fluffy@cisco.com> In-Reply-To: <2ECE1C68-6650-43D4-97B6-2D405143C845@tzi.org> Date: Thu, 5 May 2011 12:50:48 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <18AE2340-976B-4124-AE8F-B7474BDCFC6E@cisco.com> References: <1FFCF0B6-2DF8-4776-BC6B-47069737AD50@cisco.com> <2ECE1C68-6650-43D4-97B6-2D405143C845@tzi.org> To: Carsten Bormann <cabo@tzi.org> X-Mailer: Apple Mail (2.1084) Cc: core WG <core@ietf.org> Subject: Re: [core] draft-ietf-core-coap-06 The CoAP/DTLS/CoAP Turkey Sandwich layer violation train wreck X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 05 May 2011 18:50:52 -0000 On May 4, 2011, at 11:54 PM, Carsten Bormann wrote: > I don't get it. >=20 > You can use any layering you want. >=20 > All section 7.3 does is ensure DTLS (and STUN) and CoAP *can* coexist = on a single port if you want to. >=20 > If your implementation techniques make you not want this, don't do = that then. >=20 > Yes, the problems with, e.g., OpenSSL are real. But in our = implementations so far we need to insert a BIO shim there anyway because = OpenSSL makes assumptions about DTLS that aren't quite right. >=20 > I read this as a rant that we should get a second port allocation for = CoAP over DTLS over UDP. > I'm certainly fine with that. A second port - one for UDP and one for DTLS would certainly solve all = my problem with this. I don't see any problem with that choice. And if = we do this, the topic of if we need a coaps URL scheme or not seems like = a separable problem to me. Just because we have two ports, we still = might decide to only have one scheme.=20 >=20 > (This issue is, of course, related to the question on how to specify = security in a URI. See there.) >=20 > Gruesse, Carsten >=20 From cabo@tzi.org Thu May 5 12:07:34 2011 Return-Path: <cabo@tzi.org> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D94FE08C2 for <core@ietfa.amsl.com>; Thu, 5 May 2011 12:07:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.216 X-Spam-Level: X-Spam-Status: No, score=-106.216 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJqkR40PJu+F for <core@ietfa.amsl.com>; Thu, 5 May 2011 12:07:33 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 674E5E07D0 for <core@ietf.org>; Thu, 5 May 2011 12:07:32 -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 p45J7MvF007722; Thu, 5 May 2011 21:07:22 +0200 (CEST) Received: from [192.168.217.112] (p5B3E63AF.dip.t-dialin.net [91.62.99.175]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 96E3B561; Thu, 5 May 2011 21:07:22 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann <cabo@tzi.org> In-Reply-To: <770C6CBC-E55E-41B2-BA92-1B161C8282A7@cisco.com> Date: Thu, 5 May 2011 21:07:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <E9E418D6-4C82-41D7-BFD8-5E188D5FF300@tzi.org> References: <770C6CBC-E55E-41B2-BA92-1B161C8282A7@cisco.com> To: Cullen Jennings <fluffy@cisco.com> X-Mailer: Apple Mail (2.1084) Cc: core WG <core@ietf.org> Subject: Re: [core] draft-ietf-core-coap-06 IF-Match Option X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 05 May 2011 19:07:34 -0000 > I think this is an important use case that should be supported and we = should add an IF-Match option.=20 I just submitted coap-misc-08 with a proposal for that option. I didn't try to tackle If-None-Match, which (with the ETag functionality = we already have) is probably mostly relevant for the single case If-None-Match: * Do you think there are good use cases for this, too? Gruesse, Carsten From Internet-Drafts@ietf.org Thu May 5 12:30:05 2011 Return-Path: <Internet-Drafts@ietf.org> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24FD7E096C; Thu, 5 May 2011 12:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BymZebCNLDeF; Thu, 5 May 2011 12:30:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FE84E096E; Thu, 5 May 2011 12:30:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.53 Message-ID: <20110505193004.28927.68438.idtracker@ietfa.amsl.com> Date: Thu, 05 May 2011 12:30:04 -0700 Cc: core@ietf.org Subject: [core] I-D ACTION:draft-ietf-core-link-format-04.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 05 May 2011 19:30:05 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments Working Group of the IETF. Title : CoRE Link Format Author(s) : Z. Shelby Filename : draft-ietf-core-link-format-04.txt Pages : 19 Date : 2011-05-03 This document defines Web Linking using a link format for use by constrained web servers to describe hosted resources, their attributes and other relationships between links. Based on the HTTP Link Header format defined in RFC5988, the CoRE Link Format is carried as a payload and is assigned an Internet media type. A well- known URI is defined as a default entry-point for requesting the links hosted by a server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-core-link-format-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-core-link-format-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-05-05122404.I-D@ietf.org> --NextPart-- From cabo@tzi.org Thu May 5 12:38:17 2011 Return-Path: <cabo@tzi.org> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55292E0993 for <core@ietfa.amsl.com>; Thu, 5 May 2011 12:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.217 X-Spam-Level: X-Spam-Status: No, score=-106.217 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cH+lAvwWevq4 for <core@ietfa.amsl.com>; Thu, 5 May 2011 12:38:16 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id D56D4E0961 for <core@ietf.org>; Thu, 5 May 2011 12:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id p45Jc4YN017459; Thu, 5 May 2011 21:38:04 +0200 (CEST) Received: from [192.168.217.112] (p5B3E63AF.dip.t-dialin.net [91.62.99.175]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id E1AC156B; Thu, 5 May 2011 21:38:03 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann <cabo@tzi.org> In-Reply-To: <F5CFF5DB-54B8-40CD-8897-7186C7605AE4@cisco.com> Date: Thu, 5 May 2011 21:38:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5756DA0A-5F11-4E70-BD8A-C521495E9665@tzi.org> References: <F5CFF5DB-54B8-40CD-8897-7186C7605AE4@cisco.com> To: Cullen Jennings <fluffy@cisco.com> X-Mailer: Apple Mail (2.1084) Cc: core WG <core@ietf.org> Subject: Re: [core] draft-ietf-core-coap-06 Congestion Control X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 05 May 2011 19:38:17 -0000 > It's not clear to me that the drafts is a stop and wait congestion = control. I can't see what stops parallel transaction to the same = destination. Related to this, when doing non confirmable transaction, it = does not seem clear how the congestion control works. Given the schema = is stop and wait, I expect that this means one a request has been sent, = a parallel request can not be initiated until a responses is received = but I don't see text to that effect.=20 I think this is related to being able to open multiple TCP connections = at the same time. RFC2616 had a "SHOULD" limit of up to two simultaneous TCP connections = to the same server from one client. This has become unpopular. draft-ietf-httpbis-p1-messaging-14.txt says this (and has been saying it = for a while): Clients (including proxies) SHOULD limit the number of simultaneous connections that they maintain to a given server (including proxies). Previous revisions of HTTP gave a specific number of connections as a ceiling, but this was found to be impractical for many applications. As a result, this specification does not mandate a particular maximum number of connections, but instead encourages clients to be conservative when opening multiple connections. I would expect us to come up with similar text, but not limiting = connections, but simultaneously outstanding interactions, where these = are either CON/ACK interactions (message layer) or NON-based = request/response interactions. Section 3.2 of draft-eggert-core-congestion-control-01.txt suggests a = possible direction for developing an algorithm that might be used, but = as with TCP, I'd rather keep the algorithm separate from the protocol. The remaining issue is how to congestion-control responses that are not = 1:1 with requests, e.g. NON responses with mechanisms such as observe = and responses to multicast requests. > The draft also needs some sort of request timeout definition. Should = address things like if A has an outstanding request to B, and A receives = separate request from B, what happens. We don't want any glare problems. I'm not sure I understand that part. Yes, the cc state for NON-based = request/response interactions has to time out (the one for CON/ACK does = so automatically), say, at 4*MSL. And, yes, if I send 20 NON requests, = one each hour, the server might send all 20 responses at midnight at = once. This temporal decoupling is a variation of the non-1:1 aspect = above and could be solved the same way. Gruesse, Carsten From cabo@tzi.org Thu May 5 12:55:38 2011 Return-Path: <cabo@tzi.org> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5643DE095C for <core@ietfa.amsl.com>; Thu, 5 May 2011 12:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.218 X-Spam-Level: X-Spam-Status: No, score=-106.218 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ww9sx7pc-W-M for <core@ietfa.amsl.com>; Thu, 5 May 2011 12:55:37 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id A65E1E08C7 for <core@ietf.org>; Thu, 5 May 2011 12:54: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 p45JsifV022139 for <core@ietf.org>; Thu, 5 May 2011 21:54:44 +0200 (CEST) Received: from [192.168.217.112] (p5B3E63AF.dip.t-dialin.net [91.62.99.175]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id C3C81573; Thu, 5 May 2011 21:54:44 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann <cabo@tzi.org> In-Reply-To: <20110505193004.28927.68438.idtracker@ietfa.amsl.com> Date: Thu, 5 May 2011 21:54:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3DB90432-E1A7-4947-8029-FCF423CD121D@tzi.org> References: <20110505193004.28927.68438.idtracker@ietfa.amsl.com> To: core WG <core@ietf.org> X-Mailer: Apple Mail (2.1084) Subject: Re: [core] I-D ACTION:draft-ietf-core-link-format-04.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 05 May 2011 19:55:38 -0000 Just in case you wonder: This isn't yet another new version, it is just the I-D-announcer getting = unstuck after a week or so of being partially stuck. Gruesse, Carsten On May 5, 2011, at 21:30, Internet-Drafts@ietf.org wrote: > A new Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Constrained RESTful Environments = Working Group of the IETF. >=20 > Title : CoRE Link Format > Author(s) : Z. Shelby > Filename : draft-ietf-core-link-format-04.txt > Pages : 19 > Date : 2011-05-03 > [...] From ekr@rtfm.com Thu May 5 17:51:23 2011 Return-Path: <ekr@rtfm.com> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA716E06CF for <core@ietfa.amsl.com>; Thu, 5 May 2011 17:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.343 X-Spam-Level: X-Spam-Status: No, score=-102.343 tagged_above=-999 required=5 tests=[AWL=0.634, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q5R6VN6zKvYv for <core@ietfa.amsl.com>; Thu, 5 May 2011 17:51:23 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 27C03E06B7 for <core@ietf.org>; Thu, 5 May 2011 17:51:23 -0700 (PDT) Received: by iwn39 with SMTP id 39so2844144iwn.31 for <core@ietf.org>; Thu, 05 May 2011 17:51:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.148.132 with SMTP id r4mr1746926icv.127.1304643082489; Thu, 05 May 2011 17:51:22 -0700 (PDT) Received: by 10.43.65.206 with HTTP; Thu, 5 May 2011 17:51:22 -0700 (PDT) In-Reply-To: <2ECE1C68-6650-43D4-97B6-2D405143C845@tzi.org> References: <1FFCF0B6-2DF8-4776-BC6B-47069737AD50@cisco.com> <2ECE1C68-6650-43D4-97B6-2D405143C845@tzi.org> Date: Thu, 5 May 2011 17:51:22 -0700 Message-ID: <BANLkTin_gwk+eGxwcRRPb8YcVpvQe1UgxQ@mail.gmail.com> From: Eric Rescorla <ekr@rtfm.com> To: Carsten Bormann <cabo@tzi.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: core WG <core@ietf.org> Subject: Re: [core] draft-ietf-core-coap-06 The CoAP/DTLS/CoAP Turkey Sandwich layer violation train wreck X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 06 May 2011 00:51:23 -0000 On Wed, May 4, 2011 at 10:54 PM, Carsten Bormann <cabo@tzi.org> wrote: > I don't get it. > > You can use any layering you want. > > All section 7.3 does is ensure DTLS (and STUN) and CoAP *can* coexist on = a single port if you want to. I'm not sure I understand why this is a desirable property. We've done pretty well in the HTTP case by simply using separate ports and it's not clear to me why on ought to deviate from that. I realize that some people are concerned about port depletion, but refusing a second port isn't any kind of IETF policy and this seems like a case where it fairly obviously makes a difference. With that said, if you *do* want to demux on the same port, the particular mechanism described here doesn't seem that great. If you're doing DTLS (or pretty much any crypto protocol) you've already accepted a fair amount of overhead, minimally the record framing, record sequence number, and framing, so the additional byte doesn't seem to have that big an impact (< 6% increase in packet size) when compared to the complexity of conditionally escaping. Moreover, it seems unwise to escape STUN since it is likely that future NATs will want to do stuff with it. My suggestion would be: 1. Use STUN as-is. 2. Use a leading framing byte to distinguish DTLS and CoAP from STUN. If you're really worried about compactiness, then pick only a single value to distinguish DTLS (e.g., 0xffffffff) and use all the remaining values to give you a little more room in the rest of the pack= et. > If your implementation techniques make you not want this, don't do that t= hen. > > Yes, the problems with, e.g., OpenSSL are real. =A0But in our implementat= ions so far we need to insert a BIO shim there anyway because OpenSSL makes= assumptions about DTLS that aren't quite right. I'd be interested in hearing more about this, perhaps offline, so I can get the right fixes into OpenSSL. -Ekr From cabo@tzi.org Thu May 5 18:24:33 2011 Return-Path: <cabo@tzi.org> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16D10E075C for <core@ietfa.amsl.com>; Thu, 5 May 2011 18:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.219 X-Spam-Level: X-Spam-Status: No, score=-106.219 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PWjNAYg56dF2 for <core@ietfa.amsl.com>; Thu, 5 May 2011 18:24:32 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id CFEC2E075F for <core@ietf.org>; Thu, 5 May 2011 18:24:31 -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 p461OK0N006523; Fri, 6 May 2011 03:24:20 +0200 (CEST) Received: from [192.168.217.101] (p5B3E6398.dip.t-dialin.net [91.62.99.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 0EE225C8; Fri, 6 May 2011 03:24:19 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann <cabo@tzi.org> In-Reply-To: <BANLkTin_gwk+eGxwcRRPb8YcVpvQe1UgxQ@mail.gmail.com> Date: Fri, 6 May 2011 03:24:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <EAE9DFEE-01E9-4BE7-8CA2-136945CB6340@tzi.org> References: <1FFCF0B6-2DF8-4776-BC6B-47069737AD50@cisco.com> <2ECE1C68-6650-43D4-97B6-2D405143C845@tzi.org> <BANLkTin_gwk+eGxwcRRPb8YcVpvQe1UgxQ@mail.gmail.com> To: Eric Rescorla <ekr@rtfm.com> X-Mailer: Apple Mail (2.1084) Cc: core WG <core@ietf.org> Subject: Re: [core] draft-ietf-core-coap-06 The CoAP/DTLS/CoAP Turkey Sandwich layer violation train wreck X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 06 May 2011 01:24:33 -0000 On May 6, 2011, at 02:51, Eric Rescorla wrote: > 1. Use STUN as-is. Yep, we are doing that. (The escaping stuff is insurance for a case that is rather unlikely. We = could take it out.) What is the status about STUN coexisting with DTLS? > 2. Use a leading framing byte to distinguish DTLS and CoAP from STUN. > If you're really worried > about compactiness, (Yes, we are.) > then pick only a single value to distinguish DTLS > (e.g., 0xffffffff) (That would be a bit long.) > and use all > the remaining values to give you a little more room in the rest of the = packet. Sure, we could do that. It would mean spending another byte for all = DTLS packets. More importantly, it also means DTLS packets no longer look like DTLS = packets, which complicates debugging. I would like to learn more about your plans to expand the DTLS = ContentType space. This hasn't changed since 1996. Of course, it could, next month. Again, the escaping stuff is insurance for this case. We could take it = out. Gruesse, Carsten From paduffy@cisco.com Thu May 5 21:24:37 2011 Return-Path: <paduffy@cisco.com> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DBB5E06BB for <core@ietfa.amsl.com>; Thu, 5 May 2011 21:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.207 X-Spam-Level: X-Spam-Status: No, score=-10.207 tagged_above=-999 required=5 tests=[AWL=-0.392, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_NEED_REPLY=0.784] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZRbepMccQJ6x for <core@ietfa.amsl.com>; Thu, 5 May 2011 21:24:36 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 890C0E06B2 for <core@ietf.org>; Thu, 5 May 2011 21:24:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paduffy@cisco.com; l=697; q=dns/txt; s=iport; t=1304655876; x=1305865476; h=message-id:date:from:reply-to:mime-version:to:subject: content-transfer-encoding; bh=qBn/b1mV73Bh1H5jIdrI3bMWtiySI382Cq2Vd3cZyfE=; b=Wvcrw/pn7G6a3381F+FdKYC/xW51EHQlqbujHA8lTQJ7G+CuPwIWEz2j 8CgNAcNE8+8u6BZ3rPSC+q+bNi+aKAiifn+Z7kw8wlAbCVQ5cyGp/XmgT tEGJGM9KYkc3qTxgDXykloQxLhatE4O2Zl0483otirdMeSZMK6TR90idE Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHd3w02tJV2b/2dsb2JhbACmQXemPYEdgngPAZsUhgkEj1WEI4pM X-IronPort-AV: E=Sophos;i="4.64,324,1301875200"; d="scan'208";a="351534216" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by sj-iport-2.cisco.com with ESMTP; 06 May 2011 04:24:36 +0000 Received: from [10.86.246.175] ([10.86.246.175]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p464OZSn026887 for <core@ietf.org>; Fri, 6 May 2011 04:24:35 GMT Message-ID: <4DC37803.5070402@cisco.com> Date: Fri, 06 May 2011 00:24:35 -0400 From: Paul Duffy <paduffy@cisco.com> Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: core <core@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [core] draft-ietf-core-coap-06 2.2 Request/ Response model.... X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: paduffy@cisco.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 06 May 2011 04:24:37 -0000 States... "CoAP makes use of GET, PUT, POST and DELETE methods in a similar manner to HTTP, with the semantics specified in Section 5.8. (Note that the detailed semantics of CoAP methods are "almost, but not entirely unlike" those of HTTP methods: Intuition taken from HTTP experience generally does apply well, but there are enough differences that make it worthwhile to actually read the present specification.)" Sort of , kind of, but not fully equivalent to HTTP? It is not specifically clear how the methods behavior differs from those of HTTP, nor is this apparent from any discussion section 5.8. Are there issues mapping these methods between HTTP and COAP? Cheers From ekr@rtfm.com Fri May 6 00:49:44 2011 Return-Path: <ekr@rtfm.com> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A3A7E069C for <core@ietfa.amsl.com>; Fri, 6 May 2011 00:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.327 X-Spam-Level: X-Spam-Status: No, score=-101.327 tagged_above=-999 required=5 tests=[AWL=-0.649, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MANGLED_BEST=2.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TnLVuBTDDKEo for <core@ietfa.amsl.com>; Fri, 6 May 2011 00:49:43 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2E0ECE0663 for <core@ietf.org>; Fri, 6 May 2011 00:49:43 -0700 (PDT) Received: by gwb20 with SMTP id 20so1300909gwb.31 for <core@ietf.org>; Fri, 06 May 2011 00:49:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.91.63.8 with SMTP id q8mr220633agk.80.1304668182266; Fri, 06 May 2011 00:49:42 -0700 (PDT) Received: by 10.91.162.16 with HTTP; Fri, 6 May 2011 00:49:42 -0700 (PDT) In-Reply-To: <EAE9DFEE-01E9-4BE7-8CA2-136945CB6340@tzi.org> References: <1FFCF0B6-2DF8-4776-BC6B-47069737AD50@cisco.com> <2ECE1C68-6650-43D4-97B6-2D405143C845@tzi.org> <BANLkTin_gwk+eGxwcRRPb8YcVpvQe1UgxQ@mail.gmail.com> <EAE9DFEE-01E9-4BE7-8CA2-136945CB6340@tzi.org> Date: Fri, 6 May 2011 00:49:42 -0700 Message-ID: <BANLkTik0MYry5_skJo8CwLAeDAxTxjRFSA@mail.gmail.com> From: Eric Rescorla <ekr@rtfm.com> To: Carsten Bormann <cabo@tzi.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: core WG <core@ietf.org> Subject: Re: [core] draft-ietf-core-coap-06 The CoAP/DTLS/CoAP Turkey Sandwich layer violation train wreck X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 06 May 2011 07:49:44 -0000 On Thu, May 5, 2011 at 6:24 PM, Carsten Bormann <cabo@tzi.org> wrote: > On May 6, 2011, at 02:51, Eric Rescorla wrote: > >> 1. Use STUN as-is. > > Yep, we are doing that. > (The escaping stuff is insurance for a case that is rather unlikely. =A0W= e could take it out.) > > What is the status about STUN coexisting with DTLS? As far as I know, there's no problem, since the leading bytes plus cookies = make collisions very unlikely. >> 2. Use a leading framing byte to distinguish DTLS and CoAP from STUN. >> If you're really worried >> about compactiness, > > (Yes, we are.) > >> then pick only a single value to distinguish DTLS >> (e.g., 0xffffffff) > > (That would be a bit long.) Sorry, brain failure. 0xff >> and use all >> the remaining values to give you a little more room in the rest of the p= acket. > > Sure, we could do that. =A0It would mean spending another byte for all DT= LS packets. Right. My argument is that that's not that big a deal because it only increases space by ~5%. > More importantly, it also means DTLS packets no longer look like DTLS pac= kets, which complicates debugging. Yes, I agree that that's suboptimal. That's why I prefer separate ports... The material you're quoting above is just some other thoughts for dealing w= ith the same port if people insist. > I would like to learn more about your plans to expand the DTLS ContentTyp= e space. > This hasn't changed since 1996. =A0Of course, it could, next month. > Again, the escaping stuff is insurance for this case. =A0We could take it= out. I don't think there are any immediate plans to do so--though note that http://tools.ietf.org/html/draft-seggelmann-tls-dtls-heartbeat-01 does contemplate one addition. And I would assume that we intend to assign the content-types towards the bottom of the range first. That said, I don't think TLS-WG has by any means decided to commit to not assigning a bunch more types. Bes,t -Ekr From cabo@tzi.org Fri May 6 02:05:19 2011 Return-Path: <cabo@tzi.org> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13272E06F6 for <core@ietfa.amsl.com>; Fri, 6 May 2011 02:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.465 X-Spam-Level: X-Spam-Status: No, score=-105.465 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, SARE_SUB_NEED_REPLY=0.784, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7OiTrmg5gJVt for <core@ietfa.amsl.com>; Fri, 6 May 2011 02:05:18 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 79C3DE0706 for <core@ietf.org>; Fri, 6 May 2011 02:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id p4695AqQ015323; Fri, 6 May 2011 11:05:10 +0200 (CEST) Received: from eduroam-0821.wlan.uni-bremen.de (eduroam-0821.wlan.uni-bremen.de [134.102.19.53]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 825196EC; Fri, 6 May 2011 11:05:10 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann <cabo@tzi.org> In-Reply-To: <4DC37803.5070402@cisco.com> Date: Fri, 6 May 2011 11:05:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3940709B-25B8-46B5-A16F-516D865926DD@tzi.org> References: <4DC37803.5070402@cisco.com> To: paduffy@cisco.com X-Mailer: Apple Mail (2.1084) Cc: core <core@ietf.org> Subject: Re: [core] draft-ietf-core-coap-06 2.2 Request/ Response model.... X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 06 May 2011 09:05:19 -0000 On May 6, 2011, at 06:24, Paul Duffy wrote: > States... >=20 > "CoAP makes use of GET, PUT, POST and DELETE methods in a similar > manner to HTTP, with the semantics specified in Section 5.8. (Note > that the detailed semantics of CoAP methods are "almost, but not > entirely unlike" those of HTTP methods: Intuition taken from HTTP > experience generally does apply well, but there are enough > differences that make it worthwhile to actually read the present > specification.)" >=20 > Sort of , kind of, but not fully equivalent to HTTP? Yes. The point of CoAP is to provide REST functionality without all the = complexities of HTTP. It is impossible to have a trivial one-to-one correspondence of features = if you don't have all the features and in particular try to avoid most = of the historical baggage. The text you cite is there to alert readers that they shouldn't just = assume that every little detail they know from HTTP simply transfers to = CoAP. I.e., in shorter words, "do read the spec, please". > It is not specifically clear how the methods behavior differs from = those of HTTP, nor is this apparent from any discussion section 5.8. We seem to be oscillating between "describe CoAP as a protocol" and = "describe CoAP as a diff from HTTP". The latter is easier to access for the small number of people who really = know HTTP, but is dangerous as it starts out with all of HTTPs = complexities and assumptions many of which aren't there in CoAP. So = section 5 is mostly just describing CoAP and using fewer HTTP analogies = than some previous versions of the description. You have to study both protocols to derive conclusively in what details = they differ. I trust there will be research papers, websites, books, = informational RFCs etc. that do this in much more detail than a spec = ever could. > Are there issues mapping these methods between HTTP and COAP? On what level do you need this question answered? "Are there issues" as in=20 "are there tickets in the tracker that pertain to the mapping"? Not right now -- all tickets have been closed in creating -06. (Guido's report from yesterday will lead to a new one that also will = need to address mapping. Some of Cullen's comments might, too. Please do report any other issues you find.) "Are there issues" as in=20 "do you need to spend more than five minutes to understand how to write = a generic mapper"? Absolutely. That's why we have a whole section 8. Also, Angelo and = Klaus have written documents that discuss some of the more esoteric = points, also about implementation. There is plenty of interesting work = in exploring this entire space. "Are there issues" as in=20 "CoAP has issues. Don't touch it with a ten-foot pole!"? Most people in this WG have an opinion on this :-) Gruesse, Carsten From alper.yegin@yegin.org Fri May 6 03:27:35 2011 Return-Path: <alper.yegin@yegin.org> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0613E06FF for <core@ietfa.amsl.com>; Fri, 6 May 2011 03:27:35 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N946DjFWo+rd for <core@ietfa.amsl.com>; Fri, 6 May 2011 03:27:35 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 07B10E06FD for <core@ietf.org>; Fri, 6 May 2011 03:27:34 -0700 (PDT) Received: from ibm (dsl88-247-34762.ttnet.net.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0MfFA2-1Q6gcV45pC-00OsyM; Fri, 06 May 2011 06:27:33 -0400 From: "Alper Yegin" <alper.yegin@yegin.org> To: "'Cullen Jennings'" <fluffy@cisco.com> References: <239072CD-ACC0-454D-8BD6-30AC28D425D9@cisco.com> <059f01cc0b35$a785fc90$f691f5b0$@yegin@yegin.org> <720981EA-6411-4A5C-AC8C-675ADA1A2DE5@cisco.com> In-Reply-To: <720981EA-6411-4A5C-AC8C-675ADA1A2DE5@cisco.com> Date: Fri, 6 May 2011 13:27:25 +0300 Message-ID: <07a401cc0bd8$34e5ab10$9eb10130$@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: AcwLUCth4KMJrwHuTjamskYzPgp8cQAhg/kA Content-Language: en-us X-Provags-ID: V02:K0:OX8KcRyCYRB/fDyPvGHljhIcaG5GeWMk64B+6FBK+3M JHG8E8CFuBaZQA/rC8FdCAVCE2TLVS8dEPMM39SAjRUjSqtUZw e13NigpeCTaWxoRTzyqwMo9WYtf98iRpevCpy0HDzqvN+67Px5 eZaxThknlIq1m2rp/6JikE6lf7R8gyeLiVquQaVGKNKuFWvI1p gvwNzX0wuCkNZGYZ9UYn9NfYyE953PuZgI6ZN0Y71Y= Cc: 'core WG' <core@ietf.org> Subject: Re: [core] draft-ietf-core-coap-06 Security X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 06 May 2011 10:27:36 -0000 > > Hi Cullen, > > > > I think it is essential that the protocol can be secured when there > are > > pre-provisioned credentials on the devices. I think we are covered on > that > > front. > > In the Certificate mode, I do not see how we are covered from on path > attackers - but I could easily be missing some critical part of the > draft - I just don't see how the security works yet. For example if A > wants to send a message to B and E is an on path attacker. E can MITM > the DTLS and do whatever they want to the messaging. People keep > telling me that solving that problem is out of scope for CoAP. Just > about all the other IETF protocols I have worked on consider that > problem in scope. I have a hard time imagining this draft getting past > IESG with that out of scope. Performing mutual TLS authentication leaves no room for a MitM. I don't quite understand the threat you are mentioning. > I'm not trying to push any particular solution to this - I just think > we need some solution to it. Given out deployment environment, I don't > see how to easily to solve without also dealing with some of the issues > people wish were out of scope. > > > > > If you are talking about specifying mechanisms about how those > credentials > > got on the devices, the simplest is to say they are burned in by the > > manufacturer. > > I think it's worth breaking this into two cases. One where the > credentials was a shared symmetric key of some sort and are the same > across all devices. What do you mean by "the same"? Hopefully not the same key. > Then there is the case where the credential is a > manufacture installed certificate. Those are pretty different. In the > first case, the security is not really there and in the second case, I > still don't see how CoAP solves the attack I mentioned above. Sorry, I don't understand why you say "security is not there." > I may have misread the current draft and I could easily be confused > about the how things work. So lets start with where you have a > different point of view than me. > > I guess the first is question is if we need to actually protect against > attacks such as the on path MITM? Yes. > The second would be are you thinking manufacture installed certs would > do this and if so how? Sure. Why not? OK, let me write this and see if this sheds some light to a possible disconnect. Let's look at this scenario: Each device comes with a certificate bound to a device identifier. If you get a new device and want to join it to your network, you include that device's identifier in the ACL (access control list, i.e., a white list) of the network. Now that network knows the identifier of the device, still needs to authenticate when a device claims that identity. How that identifier is entered in the ACL DB can be out-of scope for this WG. Now the device discovers the network (and its identifier). I guess this is also out-of scope right now. (Could be in scope....) Given that the two end-points know each other's "claimed" identifiers, they proceed to authenticating that claim using the certificates. TLS does that. What do you think? Alper > or is there a different type of credential you > were thinking of for this? > > > > > If you want to take one more step, i.e. specifying some dynamic over- > the-air > > provisioning of credentials, I think this is getting beyond Core > scope. That > > by itself is a large problem and not that specific to Core. It needs > to be > > scoped in very detail, and most possibly it already applies to non- > core > > scenarios as well. > > > > My 0.02 cents. > > > > Alper > > > > > > > > > >> -----Original Message----- > >> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf > Of > >> Cullen Jennings > >> Sent: Thursday, May 05, 2011 5:51 AM > >> To: core WG > >> Subject: [core] draft-ietf-core-coap-06 Security > >> > >> > >> > >> I think it will be very hard to leave keying for the security out of > >> scope of this specification. I realize there are other drafts in > >> progress on this and I look forward to their rapid arrival. Even > when > >> using DTLS Certificate mode, any connection can have a man in the > >> middle attack as their is not binding of who we are trying to > connect > >> to material in the certificate. This seems like a big problem. > Related > >> to this, for many protocols the assumption that someone with a > keyboard > >> and screen will manually type something into the device as out of > band > >> security configuration is reasonable. Give the use cases this WG was > >> formed to solve, it is not an reasonable assumption for this WG. > >> > >> > >> Cullen <in my role as an individual contributor> > >> > >> _______________________________________________ > >> core mailing list > >> core@ietf.org > >> https://www.ietf.org/mailman/listinfo/core > > From cabo@tzi.org Fri May 6 03:43:17 2011 Return-Path: <cabo@tzi.org> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74EEDE06FF for <core@ietfa.amsl.com>; Fri, 6 May 2011 03:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.857 X-Spam-Level: X-Spam-Status: No, score=-105.857 tagged_above=-999 required=5 tests=[AWL=0.392, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3s3Lz67R0Zoq for <core@ietfa.amsl.com>; Fri, 6 May 2011 03:43:16 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 78CB5E0691 for <core@ietf.org>; Fri, 6 May 2011 03:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id p46Ah4CG020409; Fri, 6 May 2011 12:43:04 +0200 (CEST) Received: from eduroam-0821.wlan.uni-bremen.de (eduroam-0821.wlan.uni-bremen.de [134.102.19.53]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 9AF4C79E; Fri, 6 May 2011 12:43:04 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann <cabo@tzi.org> In-Reply-To: <07a401cc0bd8$34e5ab10$9eb10130$@yegin@yegin.org> Date: Fri, 6 May 2011 12:43:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <09DFFAC9-BB9F-45AD-A7B8-3B2BB9B804BC@tzi.org> References: <239072CD-ACC0-454D-8BD6-30AC28D425D9@cisco.com> <059f01cc0b35$a785fc90$f691f5b0$@yegin@yegin.org> <720981EA-6411-4A5C-AC8C-675ADA1A2DE5@cisco.com> <07a401cc0bd8$34e5ab10$9eb10130$@yegin@yegin.org> To: "Alper Yegin" <alper.yegin@yegin.org> X-Mailer: Apple Mail (2.1084) Cc: 'core WG' <core@ietf.org> Subject: Re: [core] draft-ietf-core-coap-06 Security X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 06 May 2011 10:43:17 -0000 I think some of the confusion comes from looking at only part of the = picture. I'll try to get the rest filled in by asking a couple of questions. On May 6, 2011, at 12:27, Alper Yegin wrote: > Each device comes with a certificate bound to a device identifier. (That is fine for a class of devices. Let's focus on this class for now.) Who signs this certificate? What is the trust model? What are our assumptions with respect to the lifecycle of roots that are = common between devices? (Note that some devices have a rather long expected service life.) > If you > get a new device and want to join it to your network, you include that > device's identifier in the ACL (access control list, i.e., a white = list) of > the network. I don't know what "the network" is other than a collection of nodes we = call the Internet. Which nodes keep this ACL? How is the updating done securely? How is the information disseminated securely to the other nodes? How does my new lightbulb know all this? > Now that network knows the identifier of the device, still > needs to authenticate when a device claims that identity. How that > identifier is entered in the ACL DB can be out-of scope for this WG. But a framework for that is the essence of security bootstrapping. > Now the device discovers the network (and its identifier). I guess = this is > also out-of scope right now. (Could be in scope....) >=20 > Given that the two end-points know each other's "claimed" identifiers, = they > proceed to authenticating that claim using the certificates. TLS does = that. That is the part that is relatively well-understood, I agree. Gruesse, Carsten From paduffy@cisco.com Fri May 6 07:18:05 2011 Return-Path: <paduffy@cisco.com> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5D61E0758 for <core@ietfa.amsl.com>; Fri, 6 May 2011 07:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.011 X-Spam-Level: X-Spam-Status: No, score=-10.011 tagged_above=-999 required=5 tests=[AWL=-0.196, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_NEED_REPLY=0.784] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTcw+7zfljgD for <core@ietfa.amsl.com>; Fri, 6 May 2011 07:18:05 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3EDEEE0756 for <core@ietf.org>; Fri, 6 May 2011 07:18:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paduffy@cisco.com; l=3267; q=dns/txt; s=iport; t=1304691485; x=1305901085; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=qFJ9cJmJc7YZgHSE4bBfOuU1UFjEJKP8QjfhXMDROVc=; b=H0spni0t/tx/4xqe+zIVvuQxLiMUkfl/S2Pk8r5Aj3G41dFLoYlPQ3NM SzeWpAky4KK51O1KYgHhLi6Crbh55237sSpY4CSB1cX/3+O2rG7Ah2hom 0Eo2+D25pBeb9/9KmYDlvg6TqJICQZ5T51TJ4IdMv4XN4e/005TZ9F3Ty g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIICxE2tJXG9/2dsb2JhbACmQnenJYJ4DwGbB4YJBI9YhCSKTA X-IronPort-AV: E=Sophos;i="4.64,326,1301875200"; d="scan'208";a="309949892" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by sj-iport-3.cisco.com with ESMTP; 06 May 2011 14:18:04 +0000 Received: from [10.86.250.76] (bxb-vpn3-588.cisco.com [10.86.250.76]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p46EI3De011738; Fri, 6 May 2011 14:18:03 GMT Message-ID: <4DC4031A.1030005@cisco.com> Date: Fri, 06 May 2011 10:18:02 -0400 From: Paul Duffy <paduffy@cisco.com> Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Carsten Bormann <cabo@tzi.org> References: <4DC37803.5070402@cisco.com> <3940709B-25B8-46B5-A16F-516D865926DD@tzi.org> In-Reply-To: <3940709B-25B8-46B5-A16F-516D865926DD@tzi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: core <core@ietf.org> Subject: Re: [core] draft-ietf-core-coap-06 2.2 Request/ Response model.... X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: paduffy@cisco.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 06 May 2011 14:18:05 -0000 "On what level do you need this question answered?" Specifics re: where the COAP methods diverge from HTTP semantics. The text non specifically suggests there are differences, refers to another section, and does not address the issue. Ultimately what I'm after are any special details that need to be handled by a COAP/HTTP translation. Cheers On 5/6/2011 5:05 AM, Carsten Bormann wrote: > On May 6, 2011, at 06:24, Paul Duffy wrote: > >> States... >> >> "CoAP makes use of GET, PUT, POST and DELETE methods in a similar >> manner to HTTP, with the semantics specified in Section 5.8. (Note >> that the detailed semantics of CoAP methods are "almost, but not >> entirely unlike" those of HTTP methods: Intuition taken from HTTP >> experience generally does apply well, but there are enough >> differences that make it worthwhile to actually read the present >> specification.)" >> >> Sort of , kind of, but not fully equivalent to HTTP? > Yes. The point of CoAP is to provide REST functionality without all the complexities of HTTP. > It is impossible to have a trivial one-to-one correspondence of features if you don't have all the features and in particular try to avoid most of the historical baggage. > > The text you cite is there to alert readers that they shouldn't just assume that every little detail they know from HTTP simply transfers to CoAP. I.e., in shorter words, "do read the spec, please". > >> It is not specifically clear how the methods behavior differs from those of HTTP, nor is this apparent from any discussion section 5.8. > We seem to be oscillating between "describe CoAP as a protocol" and "describe CoAP as a diff from HTTP". > The latter is easier to access for the small number of people who really know HTTP, but is dangerous as it starts out with all of HTTPs complexities and assumptions many of which aren't there in CoAP. So section 5 is mostly just describing CoAP and using fewer HTTP analogies than some previous versions of the description. > You have to study both protocols to derive conclusively in what details they differ. I trust there will be research papers, websites, books, informational RFCs etc. that do this in much more detail than a spec ever could. > >> Are there issues mapping these methods between HTTP and COAP? > On what level do you need this question answered? > > "Are there issues" as in > "are there tickets in the tracker that pertain to the mapping"? > Not right now -- all tickets have been closed in creating -06. > (Guido's report from yesterday will lead to a new one that also will need to address mapping. > Some of Cullen's comments might, too. > Please do report any other issues you find.) > > "Are there issues" as in > "do you need to spend more than five minutes to understand how to write a generic mapper"? > Absolutely. That's why we have a whole section 8. Also, Angelo and Klaus have written documents that discuss some of the more esoteric points, also about implementation. There is plenty of interesting work in exploring this entire space. > > "Are there issues" as in > "CoAP has issues. Don't touch it with a ten-foot pole!"? > Most people in this WG have an opinion on this :-) > > Gruesse, Carsten > > From charles.palmer@onzo.com Fri May 6 07:43:49 2011 Return-Path: <charles.palmer@onzo.com> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61A05E073C for <core@ietfa.amsl.com>; Fri, 6 May 2011 07:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.206 X-Spam-Level: X-Spam-Status: No, score=-3.206 tagged_above=-999 required=5 tests=[AWL=-0.392, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_NEED_REPLY=0.784] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xdk5fbrCfrwn for <core@ietfa.amsl.com>; Fri, 6 May 2011 07:43:48 -0700 (PDT) Received: from service38.mimecast.com (service38.mimecast.com [195.130.217.47]) by ietfa.amsl.com (Postfix) with SMTP id 56B0AE06DD for <core@ietf.org>; Fri, 6 May 2011 07:43:46 -0700 (PDT) Received: from onzosbs2k3.ONZO.local (217.138.5.2 [217.138.5.2]) by service38.mimecast.com; Fri, 06 May 2011 15:43:45 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 6 May 2011 15:43:44 +0100 Message-ID: <E4DBD8AB11D2E54F89B23D7CD1065D8C01D4D8EE@onzosbs2k3.ONZO.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] draft-ietf-core-coap-06 2.2 Request/ Response model.... Thread-Index: AcwL+HDFRFVyulBhRo+3Ung532J4zQAAIuja References: <4DC37803.5070402@cisco.com><3940709B-25B8-46B5-A16F-516D865926DD@tzi.org> <4DC4031A.1030005@cisco.com> From: "Charles Palmer" <charles.palmer@onzo.com> To: <paduffy@cisco.com>, "Carsten Bormann" <cabo@tzi.org> X-MC-Unique: 111050615434504202 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC0BFB.FFAA274C" Cc: core <core@ietf.org> Subject: Re: [core] draft-ietf-core-coap-06 2.2 Request/ Response model.... X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 06 May 2011 14:43:49 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC0BFB.FFAA274C Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable One approach would be to take the GET, PUT, POST and DELETE text from RFC26= 16, edit this text and place it into CoAP. The edit could be done in such a= way that where HTTP and CoAP were the same the text stayed the same; and w= here there was a difference (and only then) the text would be changed. This= would have the advantage of obliging the CoAP authors to think carefully a= bout the similarities and differences. Comparison of the two documents woul= d allow facilitate HTTP/CoAP translation etc. I would also be more comfortable if the same could be done with the respons= e codes, which again are expressed in terms of their similarity, or otherwi= se, with RFC2616. I guess it depends on your philiosphical view as to whether it is better to= refer to other documents or to replicate their text. -----Original Message----- From: core-bounces@ietf.org on behalf of Paul Duffy Sent: Fri 06/05/2011 15:18 To: Carsten Bormann Cc: core Subject: Re: [core] draft-ietf-core-coap-06 2.2 Request/ Response model.... =20 "On what level do you need this question answered?" Specifics re: where the COAP methods diverge from HTTP semantics. The text= non specifically suggests there are differences, refers to another section= , and does not address the issue. Ultimately what I'm after are any special details that need to be handled b= y a COAP/HTTP translation. Cheers On 5/6/2011 5:05 AM, Carsten Bormann wrote: > On May 6, 2011, at 06:24, Paul Duffy wrote: > >> States... >> >> "CoAP makes use of GET, PUT, POST and DELETE methods in a similar >> manner to HTTP, with the semantics specified in Section 5.8. (Note >> that the detailed semantics of CoAP methods are "almost, but not >> entirely unlike" those of HTTP methods: Intuition taken from HTTP >> experience generally does apply well, but there are enough >> differences that make it worthwhile to actually read the present >> specification.)" >> >> Sort of , kind of, but not fully equivalent to HTTP? > Yes. The point of CoAP is to provide REST functionality without all the = complexities of HTTP. > It is impossible to have a trivial one-to-one correspondence of features = if you don't have all the features and in particular try to avoid most of t= he historical baggage. > > The text you cite is there to alert readers that they shouldn't just assu= me that every little detail they know from HTTP simply transfers to CoAP. = I.e., in shorter words, "do read the spec, please". > >> It is not specifically clear how the methods behavior differs from those= of HTTP, nor is this apparent from any discussion section 5.8. > We seem to be oscillating between "describe CoAP as a protocol" and "desc= ribe CoAP as a diff from HTTP". > The latter is easier to access for the small number of people who really = know HTTP, but is dangerous as it starts out with all of HTTPs complexities= and assumptions many of which aren't there in CoAP. So section 5 is mostl= y just describing CoAP and using fewer HTTP analogies than some previous ve= rsions of the description. > You have to study both protocols to derive conclusively in what details t= hey differ. I trust there will be research papers, websites, books, inform= ational RFCs etc. that do this in much more detail than a spec ever could. > >> Are there issues mapping these methods between HTTP and COAP? > On what level do you need this question answered? > > "Are there issues" as in > "are there tickets in the tracker that pertain to the mapping"? > Not right now -- all tickets have been closed in creating -06. > (Guido's report from yesterday will lead to a new one that also will need= to address mapping. > Some of Cullen's comments might, too. > Please do report any other issues you find.) > > "Are there issues" as in > "do you need to spend more than five minutes to understand how to write a= generic mapper"? > Absolutely. That's why we have a whole section 8. Also, Angelo and Klau= s have written documents that discuss some of the more esoteric points, als= o about implementation. There is plenty of interesting work in exploring t= his entire space. > > "Are there issues" as in > "CoAP has issues. Don't touch it with a ten-foot pole!"? > Most people in this WG have an opinion on this :-) > > Gruesse, Carsten > > _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core -------------------------------- Onzo is a limited company number 06097997 registered in England & Wales. Th= e =20 registered office is 6 Great Newport Street, London, WC2H 7JB, United Kingd= om. This email message may contain confidential and/or privileged information, = and is intended solely for the addressee(s). If you have received this email in= =20 error, please notify Onzo immediately. Unauthorised copying, disclosure or= =20 distribution of the material in this email is forbidden. -------------------------------- ------_=_NextPart_001_01CC0BFB.FFAA274C Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Diso-8859-= 1"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version 6.5.7638.1"> <TITLE>RE: [core] draft-ietf-core-coap-06 2.2 Request/ Response model....</= TITLE> </HEAD> <BODY> =20 =20 <!-- Converted from text/plain format --> <P><FONT SIZE=3D2>One approach would be to take the GET, PUT, POST and DELE= TE text from RFC2616, edit this text and place it into CoAP. The edit could= be done in such a way that where HTTP and CoAP were the same the text stay= ed the same; and where there was a difference (and only then) the text woul= d be changed. This would have the advantage of obliging the CoAP authors to= think carefully about the similarities and differences. Comparison of the = two documents would allow facilitate HTTP/CoAP translation etc.<BR> <BR> I would also be more comfortable if the same could be done with the respons= e codes, which again are expressed in terms of their similarity, or otherwi= se, with RFC2616.<BR> <BR> I guess it depends on your philiosphical view as to whether it is better to= refer to other documents or to replicate their text.<BR> <BR> <BR> -----Original Message-----<BR> From: core-bounces@ietf.org on behalf of Paul Duffy<BR> Sent: Fri 06/05/2011 15:18<BR> To: Carsten Bormann<BR> Cc: core<BR> Subject: Re: [core] draft-ietf-core-coap-06 2.2 Request/ Response model....= <BR> <BR> "On what level do you need this question answered?"<BR> <BR> Specifics re: where the COAP methods diverge from HTTP semantics.  The= text non specifically suggests there are differences, refers to another se= ction, and does not address the issue.<BR> <BR> Ultimately what I'm after are any special details that need to be handled b= y a COAP/HTTP translation.<BR> <BR> Cheers<BR> <BR> <BR> <BR> On 5/6/2011 5:05 AM, Carsten Bormann wrote:<BR> > On May 6, 2011, at 06:24, Paul Duffy wrote:<BR> ><BR> >> States...<BR> >><BR> >> "CoAP makes use of GET, PUT, POST and DELETE methods in a sim= ilar<BR> >> manner to HTTP, with the semantics specified in Section 5.8. (Note= <BR> >> that the detailed semantics of CoAP methods are "almost, but = not<BR> >> entirely unlike" those of HTTP methods: Intuition taken from = HTTP<BR> >> experience generally does apply well, but there are enough<BR> >> differences that make it worthwhile to actually read the present<B= R> >> specification.)"<BR> >><BR> >> Sort of , kind of, but not fully equivalent to HTTP?<BR> > Yes.  The point of CoAP is to provide REST functionality without = all the complexities of HTTP.<BR> > It is impossible to have a trivial one-to-one correspondence of featur= es if you don't have all the features and in particular try to avoid most o= f the historical baggage.<BR> ><BR> > The text you cite is there to alert readers that they shouldn't just a= ssume that every little detail they know from HTTP simply transfers to CoAP= .  I.e., in shorter words, "do read the spec, please".<BR> ><BR> >> It is not specifically clear how the methods behavior differs from= those of HTTP, nor is this apparent from any discussion section 5.8.<BR> > We seem to be oscillating between "describe CoAP as a protocol&qu= ot; and "describe CoAP as a diff from HTTP".<BR> > The latter is easier to access for the small number of people who real= ly know HTTP, but is dangerous as it starts out with all of HTTPs complexit= ies and assumptions many of which aren't there in CoAP.  So section 5 = is mostly just describing CoAP and using fewer HTTP analogies than some pre= vious versions of the description.<BR> > You have to study both protocols to derive conclusively in what detail= s they differ.  I trust there will be research papers, websites, books= , informational RFCs etc. that do this in much more detail than a spec ever= could.<BR> ><BR> >> Are there issues mapping these methods between HTTP and COAP?<BR> > On what level do you need this question answered?<BR> ><BR> > "Are there issues" as in<BR> > "are there tickets in the tracker that pertain to the mapping&quo= t;?<BR> > Not right now -- all tickets have been closed in creating -06.<BR> > (Guido's report from yesterday will lead to a new one that also will n= eed to address mapping.<BR> > Some of Cullen's comments might, too.<BR> > Please do report any other issues you find.)<BR> ><BR> > "Are there issues" as in<BR> > "do you need to spend more than five minutes to understand how to= write a generic mapper"?<BR> > Absolutely.  That's why we have a whole section 8.  Also, An= gelo and Klaus have written documents that discuss some of the more esoteri= c points, also about implementation.  There is plenty of interesting w= ork in exploring this entire space.<BR> ><BR> > "Are there issues" as in<BR> > "CoAP has issues.  Don't touch it with a ten-foot pole!"= ;?<BR> > Most people in this WG have an opinion on this :-)<BR> ><BR> > Gruesse, Carsten<BR> ><BR> ><BR> <BR> _______________________________________________<BR> core mailing list<BR> core@ietf.org<BR> <A HREF=3D"https://www.ietf.org/mailman/listinfo/core">https://www.ietf.org= /mailman/listinfo/core</A><BR> <BR> <BR> <BR> </FONT> </P> <BR> <span style=3D"font-family:Arial; Font-size:8pt"> --------------------------------<br/> <a href=3D"http://www.onzo.com/">Onzo</a> is a limited company nu= mber 06097997 registered in England & Wales. The<br/> registered office is 6 Great Newport Street, London, WC2H 7JB, Un= ited Kingdom.<br/><br/> This email message may contain confidential and/or privileged inf= ormation, and<br/> is intended solely for the addressee(s). If you have received thi= s email in<br/> error, please notify <a href=3D"http://www.onzo.com/">Onzo</a> im= mediately. Unauthorised copying, disclosure or<br/> distribution of the material in this email is forbidden.<br/> --------------------------------<br/> </span> </BODY> </HTML> ------_=_NextPart_001_01CC0BFB.FFAA274C-- From paduffy@cisco.com Fri May 6 07:50:10 2011 Return-Path: <paduffy@cisco.com> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55651E076C for <core@ietfa.amsl.com>; Fri, 6 May 2011 07:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.338 X-Spam-Level: X-Spam-Status: No, score=-10.338 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tx6Nh8QBKazT for <core@ietfa.amsl.com>; Fri, 6 May 2011 07:50:09 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id EB459E076B for <core@ietf.org>; Fri, 6 May 2011 07:50:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paduffy@cisco.com; l=2; q=dns/txt; s=iport; t=1304693406; x=1305903006; h=message-id:date:from:reply-to:mime-version:to:subject: content-transfer-encoding; bh=frcCV1k9oG9oKj3dpUqdJg1PxRT2RSN/XKdLCPjaYaY=; b=eFfpzxSTzyb16m1OQhsuqYy+mmNkCsmsT+irOsAeaShpkVNdWk4CzifV JnOfVWYsznSzci9LZzQ98GATtsewp6IGOziSKJBiE3M/crcjxxUREp1hL gkewj+Bk70KhVpgYcwlgDP71JXfu1BVoKf4vM1nQ4Dta62uim8ZLUHRcU 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAIAJxE2tJV2Y/2dsb2JhbACHEJ8yd4hqnQaBHYJ4DwGbAoYJBI9YhCSKTA X-IronPort-AV: E=Sophos;i="4.64,326,1301875200"; d="scan'208";a="309972473" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by sj-iport-3.cisco.com with ESMTP; 06 May 2011 14:50:06 +0000 Received: from [10.86.250.76] (bxb-vpn3-588.cisco.com [10.86.250.76]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p46Eo5q0006316 for <core@ietf.org>; Fri, 6 May 2011 14:50:06 GMT Message-ID: <4DC40A9D.3060208@cisco.com> Date: Fri, 06 May 2011 10:50:05 -0400 From: Paul Duffy <paduffy@cisco.com> Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: core <core@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [core] Suggestions re: how to implement HEAD semantics within COAP? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: paduffy@cisco.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 06 May 2011 14:50:10 -0000 From alper.yegin@yegin.org Fri May 6 08:12:17 2011 Return-Path: <alper.yegin@yegin.org> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E60EBE06E6 for <core@ietfa.amsl.com>; Fri, 6 May 2011 08:12:17 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IluqkUUYVuFp for <core@ietfa.amsl.com>; Fri, 6 May 2011 08:12:17 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 41059E06BB for <core@ietf.org>; Fri, 6 May 2011 08:12:17 -0700 (PDT) Received: from ibm (dsl88-247-34762.ttnet.net.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0Lm30z-1PjZuO0zdR-00ZZMv; Fri, 06 May 2011 11:12:01 -0400 From: "Alper Yegin" <alper.yegin@yegin.org> To: "'Carsten Bormann'" <cabo@tzi.org> References: <239072CD-ACC0-454D-8BD6-30AC28D425D9@cisco.com> <059f01cc0b35$a785fc90$f691f5b0$@yegin@yegin.org> <720981EA-6411-4A5C-AC8C-675ADA1A2DE5@cisco.com> <07a401cc0bd8$34e5ab10$9eb10130$@yegin@yegin.org> <09DFFAC9-BB9F-45AD-A7B8-3B2BB9B804BC@tzi.org> In-Reply-To: <09DFFAC9-BB9F-45AD-A7B8-3B2BB9B804BC@tzi.org> Date: Fri, 6 May 2011 18:11:52 +0300 Message-ID: <07ee01cc0bff$f2651aa0$d72f4fe0$@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: AcwL2mkKQFQ6LZuWR42yjLfOkbT42AAJHJjw Content-Language: en-us X-Provags-ID: V02:K0:9ECsZVOfdsub0nteKHGV+H9cOjhH3bqRZ22rc70FaGV Si3AVhFc8hdXaTAE1s9rGBCJa99rMjtxvcZP8KmHH1Q8FYA0y3 x9xjNRokUpc1nJjU+lDZOiaBJyuisH0Wft/u5vnmsa4EtHfzBX OW2V0FZaWACWpL4zjz/CUIhNJFcGWmUyBHZ/L53H+dX5TCvNT4 5WkMm7en2UKO9Ov2BItT+85lt1Cqo1uLK38Dkga7Rs= Cc: 'core WG' <core@ietf.org> Subject: Re: [core] draft-ietf-core-coap-06 Security X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 06 May 2011 15:12:18 -0000 Hi Carsten, > I think some of the confusion comes from looking at only part of the > picture. > I'll try to get the rest filled in by asking a couple of questions. > > On May 6, 2011, at 12:27, Alper Yegin wrote: > > > Each device comes with a certificate bound to a device identifier. > > (That is fine for a class of devices. > Let's focus on this class for now.) > > Who signs this certificate? What is the trust model? > What are our assumptions with respect to the lifecycle of roots that > are common between devices? > (Note that some devices have a rather long expected service life.) Good questions, but not for the protocol designers. For example, IEEE has designed IEEE 802.16e such that it can use certificates for mutually authenticating devices (mobile terminals) and networks to each other. The questions about who the root CA vendors are, what properties the exact certs have, etc. are answered by the WiMAX Forum in its own specs, not in IEEE specs. > > If you > > get a new device and want to join it to your network, you include > that > > device's identifier in the ACL (access control list, i.e., a white > list) of > > the network. > > I don't know what "the network" is other than a collection of nodes we > call the Internet. > Which nodes keep this ACL? How is the updating done securely? > How is the information disseminated securely to the other nodes? These are system and architecture questions. They are answerable only if we start talking about specific ones... > How does my new lightbulb know all this? > > > Now that network knows the identifier of the device, still > > needs to authenticate when a device claims that identity. How that > > identifier is entered in the ACL DB can be out-of scope for this WG. > > But a framework for that is the essence of security bootstrapping. But is it essential for the basic protocol design? Again, these are system/arch issues. These are useful to discuss and understand, but not necessarily for CoAP to solve, IMHO. > > Now the device discovers the network (and its identifier). I guess > this is > > also out-of scope right now. (Could be in scope....) > > > > Given that the two end-points know each other's "claimed" > identifiers, they > > proceed to authenticating that claim using the certificates. TLS does > that. > > That is the part that is relatively well-understood, I agree. > > Gruesse, Carsten From cabo@tzi.org Fri May 6 08:14:33 2011 Return-Path: <cabo@tzi.org> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0014E06BB for <core@ietfa.amsl.com>; Fri, 6 May 2011 08:14:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.053 X-Spam-Level: X-Spam-Status: No, score=-106.053 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-lJsvtt7819 for <core@ietfa.amsl.com>; Fri, 6 May 2011 08:14:32 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 67171E0691 for <core@ietf.org>; Fri, 6 May 2011 08:14:31 -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 p46FEJ4Y024234; Fri, 6 May 2011 17:14:19 +0200 (CEST) Received: from [10.0.1.2] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id CBB7F8F3; Fri, 6 May 2011 17:14:19 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann <cabo@tzi.org> In-Reply-To: <4DC40A9D.3060208@cisco.com> Date: Fri, 6 May 2011 17:14:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <EED8658B-8287-4AD8-993D-FC77425D0D8B@tzi.org> References: <4DC40A9D.3060208@cisco.com> To: paduffy@cisco.com X-Mailer: Apple Mail (2.1084) Cc: core <core@ietf.org> Subject: Re: [core] Suggestions re: how to implement HEAD semantics within COAP? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 06 May 2011 15:14:33 -0000 There is no need to do HEAD in CoAP. A HTTP-to-CoAP mapper can map HTTP HEAD to CoAP GET. Of course you can argue that this is not very efficient. I would argue that HEAD is not used enough to make optimizing this = worthwhile at all. If you have numbers to the contrary, I'd like to hear them. (If you want to optimize it a bit, send a Block2 with SZX=3D0.) Gruesse, Carsten From cabo@tzi.org Fri May 6 08:37:52 2011 Return-Path: <cabo@tzi.org> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6E27E0704 for <core@ietfa.amsl.com>; Fri, 6 May 2011 08:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.726 X-Spam-Level: X-Spam-Status: No, score=-105.726 tagged_above=-999 required=5 tests=[AWL=-0.261, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, SARE_SUB_NEED_REPLY=0.784, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id syP9wwO7yO6e for <core@ietfa.amsl.com>; Fri, 6 May 2011 08:37:52 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 9A6FCE0694 for <core@ietf.org>; Fri, 6 May 2011 08:37: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 p46FbdDr000044; Fri, 6 May 2011 17:37:39 +0200 (CEST) Received: from [10.0.1.2] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 9F98A901; Fri, 6 May 2011 17:37:39 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann <cabo@tzi.org> In-Reply-To: <E4DBD8AB11D2E54F89B23D7CD1065D8C01D4D8EE@onzosbs2k3.ONZO.local> Date: Fri, 6 May 2011 17:37:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <199B0DAA-EB87-405F-9BD3-14B95B382803@tzi.org> References: <4DC37803.5070402@cisco.com><3940709B-25B8-46B5-A16F-516D865926DD@tzi.org> <4DC4031A.1030005@cisco.com> <E4DBD8AB11D2E54F89B23D7CD1065D8C01D4D8EE@onzosbs2k3.ONZO.local> To: "Charles Palmer" <charles.palmer@onzo.com> X-Mailer: Apple Mail (2.1084) Cc: core <core@ietf.org> Subject: Re: [core] draft-ietf-core-coap-06 2.2 Request/ Response model.... X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 06 May 2011 15:37:52 -0000 On May 6, 2011, at 16:43, Charles Palmer wrote: > One approach would be to take the GET, PUT, POST and DELETE text from = RFC2616 But that text is obsolete. If you think you know what HTTP is, you won't necessarily find it in = RFC2616. That text is being fixed in HTTPBIS, but that is an ongoing process. We can't wait with CoAP until HTTPBIS is done. We also don't have to, as CoAP is much simpler. So the consensus so far was to not import large gobs of text from either = RFC2616 or the HTTPBIS drafts. (see, e.g., = http://www.ietf.org/mail-archive/web/core/current/msg01326.html). We are violating this a bit in the response codes, as it is indeed = simpler to just reference them from HTTP (and there are some that = haven't changed much since RFC 2616). > This would have the advantage of obliging the CoAP authors to think = carefully about the similarities and differences.=20 I can assure you all of them already feel obliged to do that... We just don't feel obliged to recreate every nook and cranny of HTTP in = CoAP. CoAP is a REST protocol, not an HTTP emulator. > Comparison of the two documents would allow facilitate HTTP/CoAP = translation etc. Yes. Please do. (There seems to be an underlying assumption in the previous messages as = if there was going to be a standard way to map the two protocols. Not = so. How you map depends a lot on what your implementation is trying to = do, e.g., whether it has a cache, what it optimizes for, etc. = Specifying all these implementation variants in a protocol spec would be = rather elusive and ultimately futile. What we probably should specify = is what we expect a (forward) proxy to do. That's section 8. There are = also lots of other intermediaries that you can cook up that will do = interesting things. All outside the scope.) Gruesse, Carsten From paduffy@cisco.com Fri May 6 08:54:28 2011 Return-Path: <paduffy@cisco.com> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E837EE06F4 for <core@ietfa.amsl.com>; Fri, 6 May 2011 08:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.403 X-Spam-Level: X-Spam-Status: No, score=-10.403 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ExvVXvBwDxj for <core@ietfa.amsl.com>; Fri, 6 May 2011 08:54:28 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by ietfa.amsl.com (Postfix) with ESMTP id 32753E06EA for <core@ietf.org>; Fri, 6 May 2011 08:54:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paduffy@cisco.com; l=578; q=dns/txt; s=iport; t=1304697268; x=1305906868; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=x5lb2Atuxr0sCY+fUcIGGxZqTS6SMxMKKTGieBq3/So=; b=QqkWnf/psvrlE5kkO01m6uSJLkOpZPw7/++F90OalTF9x+xewgFL0aOw ddlEocoxMXEV2TqBFtaL5lzFDxeEKs2yqESu1afZFt0IYt1LCURkb7AsD Pl3fiOmNhGsLIu6XcVVVQrKHUHWnoxLKaziyeHafeR/gLQv8v/wKMPn41 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADUZxE2tJV2d/2dsb2JhbACmTHemMoJ4DwGbAYYJBI9YhCSKTA X-IronPort-AV: E=Sophos;i="4.64,326,1301875200"; d="scan'208";a="232162145" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rtp-iport-1.cisco.com with ESMTP; 06 May 2011 15:54:27 +0000 Received: from [10.86.250.76] (bxb-vpn3-588.cisco.com [10.86.250.76]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id p46FsQ3Z032177; Fri, 6 May 2011 15:54:27 GMT Message-ID: <4DC419B2.5080306@cisco.com> Date: Fri, 06 May 2011 11:54:26 -0400 From: Paul Duffy <paduffy@cisco.com> Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Carsten Bormann <cabo@tzi.org> References: <4DC40A9D.3060208@cisco.com> <EED8658B-8287-4AD8-993D-FC77425D0D8B@tzi.org> In-Reply-To: <EED8658B-8287-4AD8-993D-FC77425D0D8B@tzi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: core <core@ietf.org> Subject: Re: [core] Suggestions re: how to implement HEAD semantics within COAP? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: paduffy@cisco.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 06 May 2011 15:54:29 -0000 The use case is HTTP HEAD into a COAP network to determine the size of a resource. Determien the size of a resource On 5/6/2011 11:14 AM, Carsten Bormann wrote: > There is no need to do HEAD in CoAP. > > A HTTP-to-CoAP mapper can map HTTP HEAD to CoAP GET. > > Of course you can argue that this is not very efficient. > I would argue that HEAD is not used enough to make optimizing this worthwhile at all. > If you have numbers to the contrary, I'd like to hear them. > (If you want to optimize it a bit, send a Block2 with SZX=0.) > > Gruesse, Carsten > > From cabo@tzi.org Fri May 6 09:21:10 2011 Return-Path: <cabo@tzi.org> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78BD7E06D0 for <core@ietfa.amsl.com>; Fri, 6 May 2011 09:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.053 X-Spam-Level: X-Spam-Status: No, score=-106.053 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6jJs0svTGaeN for <core@ietfa.amsl.com>; Fri, 6 May 2011 09:21:07 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 1CEBCE0726 for <core@ietf.org>; Fri, 6 May 2011 09:21:06 -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 p46GKtMq013814; Fri, 6 May 2011 18:20:55 +0200 (CEST) Received: from [10.0.1.2] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 79B56924; Fri, 6 May 2011 18:20:55 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann <cabo@tzi.org> In-Reply-To: <4DC419B2.5080306@cisco.com> Date: Fri, 6 May 2011 18:20:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <C70FDB25-1CCD-4FBE-96D5-939B53DB38E6@tzi.org> References: <4DC40A9D.3060208@cisco.com> <EED8658B-8287-4AD8-993D-FC77425D0D8B@tzi.org> <4DC419B2.5080306@cisco.com> To: paduffy@cisco.com X-Mailer: Apple Mail (2.1084) Cc: core <core@ietf.org> Subject: Re: [core] Suggestions re: how to implement HEAD semantics within COAP? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 06 May 2011 16:21:10 -0000 On May 6, 2011, at 17:54, Paul Duffy wrote: > The use case is HTTP HEAD into a COAP network to determine the size of = a resource. HTTP HEAD gives you a content-length only if HTTP GET would have given = you a content-length. So this usage of HTTP HEAD is a bit on thin ice on the HTTP side = already. Can you explain the use case for "HTTP HEAD into a COAP network to = determine the size of a resource"? Why would you ever want to do that? And does this use case occur often enough to warrant any optimization? Gruesse, Carsten From therbst@silverspringnet.com Fri May 6 11:39:33 2011 Return-Path: <therbst@silverspringnet.com> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 268A8E080B for <core@ietfa.amsl.com>; Fri, 6 May 2011 11:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eB3HHYrkP2q7 for <core@ietfa.amsl.com>; Fri, 6 May 2011 11:39:32 -0700 (PDT) Received: from it-ipcorp-01.silverspringnet.com (it-ipcorp-01.silverspringnet.com [74.121.22.25]) by ietfa.amsl.com (Postfix) with ESMTP id 8026EE07F7 for <core@ietf.org>; Fri, 6 May 2011 11:39:32 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAGo/xE0KyAE8/2dsb2JhbACnFMQ9hgkEhj2NXIoz X-IronPort-AV: E=Sophos;i="4.64,327,1301900400"; d="scan'208";a="4321259" Received: from unknown (HELO IT-EXCA-01.silverspringnet.com) ([10.200.1.60]) by it-ipcorp-01.silverspringnet.com with ESMTP/TLS/AES128-SHA; 06 May 2011 11:39:32 -0700 Received: from IT-EXMB-01.silverspringnet.com ([fe80::b81e:2d5b:d263:6c44]) by IT-EXCA-01.silverspringnet.com ([::1]) with mapi; Fri, 6 May 2011 11:39:31 -0700 From: Thomas Herbst <therbst@silverspringnet.com> To: Carsten Bormann <cabo@tzi.org>, Paul Duffy <paduffy@cisco.com> Date: Fri, 6 May 2011 11:39:30 -0700 Thread-Topic: [core] Suggestions re: how to implement HEAD semantics within COAP? Thread-Index: AcwMHO/7r2XuYwW7TrWQJEkvggIiPg== Message-ID: <C9E98E13.A74D%therbst@silverspringnet.com> In-Reply-To: <C70FDB25-1CCD-4FBE-96D5-939B53DB38E6@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: core <core@ietf.org> Subject: Re: [core] Suggestions re: how to implement HEAD semantics within COAP? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 06 May 2011 18:39:33 -0000 Carsten - Are you suggesting there is no value in a constrained device having information about the size of a payload before making the request for that payload? tom On 5/6/11 9:20 AM, "Carsten Bormann" <cabo@tzi.org> wrote: >On May 6, 2011, at 17:54, Paul Duffy wrote: > >> The use case is HTTP HEAD into a COAP network to determine the size of >>a resource. > >HTTP HEAD gives you a content-length only if HTTP GET would have given >you a content-length. >So this usage of HTTP HEAD is a bit on thin ice on the HTTP side already. > >Can you explain the use case for "HTTP HEAD into a COAP network to >determine the size of a resource"? >Why would you ever want to do that? >And does this use case occur often enough to warrant any optimization? > >Gruesse, Carsten > >_______________________________________________ >core mailing list >core@ietf.org >https://www.ietf.org/mailman/listinfo/core From cabo@tzi.org Fri May 6 14:46:54 2011 Return-Path: <cabo@tzi.org> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9396E0852 for <core@ietfa.amsl.com>; Fri, 6 May 2011 14:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.22 X-Spam-Level: X-Spam-Status: No, score=-106.22 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PUEfDoQxoHZd for <core@ietfa.amsl.com>; Fri, 6 May 2011 14:46:53 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 75FA7E079C for <core@ietf.org>; Fri, 6 May 2011 14:46: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 p46Lkdt8003710; Fri, 6 May 2011 23:46:39 +0200 (CEST) Received: from [192.168.217.101] (p5B3E6398.dip.t-dialin.net [91.62.99.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id B2658994; Fri, 6 May 2011 23:46:38 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann <cabo@tzi.org> In-Reply-To: <C9E98E13.A74D%therbst@silverspringnet.com> Date: Fri, 6 May 2011 23:46:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <FE8FCF1B-02E5-4328-9DD5-B487A237C0DF@tzi.org> References: <C9E98E13.A74D%therbst@silverspringnet.com> To: Thomas Herbst <therbst@silverspringnet.com> X-Mailer: Apple Mail (2.1084) Cc: core <core@ietf.org> Subject: Re: [core] Suggestions re: how to implement HEAD semantics within COAP? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 06 May 2011 21:46:54 -0000 On May 6, 2011, at 20:39, Thomas Herbst wrote: > Carsten - >=20 > Are you suggesting there is no value in a constrained device having > information about the size of a payload before making the request for = that > payload? No, I'm not suggesting that -- that's exactly why link-format has the sz = attribute. There is also a proposal to provide an Option for CoAP to carry size = information, draft-li-core-coap-size-option-00.txt -- we haven't had a = discussion yet on whether this Option should be standardized or not. I'm just not seeing that many HEAD requests out there outside link = checkers/crawlers/performance monitors. I this specific context, I'm trying to understand the use-case where = somebody from the HTTP side (non-/less-constrained) would want to = request through to the CoAP side to get a representation size first, = instead of simply getting the resource representation. =20 Is it worth spending energy on supporting a HEAD-style request in CoAP? So far, all indications have been that GET does what's needed, as CoAP = resource representations are small. If they aren't, you are getting the first block only (which is helped = with Block2(SZX=3D0)); this contains crucial information such as = Content-Type, just not size. If size is indeed needed, Kepeng's draft may be the way to go. But there never seemed to be a need for an outright HEAD in CoAP; this = would be irrelevant optimization. That's why I'm asking for use-cases -- theoretical needs are irrelevant = for justifying the additional complexity. Gruesse, Carsten >=20 > tom >=20 > On 5/6/11 9:20 AM, "Carsten Bormann" <cabo@tzi.org> wrote: >=20 >> On May 6, 2011, at 17:54, Paul Duffy wrote: >>=20 >>> The use case is HTTP HEAD into a COAP network to determine the size = of >>> a resource. >>=20 >> HTTP HEAD gives you a content-length only if HTTP GET would have = given >> you a content-length. >> So this usage of HTTP HEAD is a bit on thin ice on the HTTP side = already. >>=20 >> Can you explain the use case for "HTTP HEAD into a COAP network to >> determine the size of a resource"? >> Why would you ever want to do that? >> And does this use case occur often enough to warrant any = optimization? >>=20 >> Gruesse, Carsten >>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core From cabo@tzi.org Fri May 6 15:09:59 2011 Return-Path: <cabo@tzi.org> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3B2CE072D for <core@ietfa.amsl.com>; Fri, 6 May 2011 15:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.221 X-Spam-Level: X-Spam-Status: No, score=-106.221 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15Vhj8plrOJs for <core@ietfa.amsl.com>; Fri, 6 May 2011 15:09:58 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 6836FE06B1 for <core@ietf.org>; Fri, 6 May 2011 15:09:57 -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 p46M9lLm008864; Sat, 7 May 2011 00:09:47 +0200 (CEST) Received: from [192.168.217.101] (p5B3E6398.dip.t-dialin.net [91.62.99.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 9D0EF997; Sat, 7 May 2011 00:09:46 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann <cabo@tzi.org> In-Reply-To: <07ee01cc0bff$f2651aa0$d72f4fe0$@yegin@yegin.org> Date: Sat, 7 May 2011 00:09:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <08C69F93-9AB8-4BC2-B71A-1BADD807661A@tzi.org> References: <239072CD-ACC0-454D-8BD6-30AC28D425D9@cisco.com> <059f01cc0b35$a785fc90$f691f5b0$@yegin@yegin.org> <720981EA-6411-4A5C-AC8C-675ADA1A2DE5@cisco.com> <07a401cc0bd8$34e5ab10$9eb10130$@yegin@yegin.org> <09DFFAC9-BB9F-45AD-A7B8-3B2BB9B804BC@tzi.org> <07ee01cc0bff$f2651aa0$d72f4fe0$@yegin@yegin.org> To: "Alper Yegin" <alper.yegin@yegin.org> X-Mailer: Apple Mail (2.1084) Cc: 'core WG' <core@ietf.org> Subject: Re: [core] draft-ietf-core-coap-06 Security X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 06 May 2011 22:10:00 -0000 On May 6, 2011, at 17:11, Alper Yegin wrote: > Good questions, but not for the protocol designers. Not for the CoAP protocol proper, but according to our charter, maybe = for the WG. > For example, IEEE has designed IEEE 802.16e such that ... That was easy: This is for use in a specific environment. We are, however, designing a protocol for the Internet. > These are system and architecture questions. They are answerable only = if we > start talking about specific ones...=20 I'm afraid this cannot be solved if we try to discuss it at the level of = generalities. That's why I always bring up my lightbulb: If we don't even know how to = do this, we won't be able to solve more general cases. > These are useful to discuss and understand, but not necessarily for = CoAP to > solve, IMHO. I agree completely -- CoAP is not the protocol that provides the = mechanics for this. coap-06 is essentially complete from my point of view. The question is what we write into the companion security bootstrapping = document: what is our MTI (mandatory to implement) security setup that = we expect every CoAP node to implement? ("MTI" is not "mandatory to use" -- specific deployments may always = provide more specialized ways to set up security.) Saying "CoAP can be used in a perfectly secure way, but we don't really = know how to make it so in a realistic Internet use case" is not really = going to cut it. Let's try to go that last mile. Gruesse, Carsten From alper.yegin@yegin.org Fri May 6 16:21:46 2011 Return-Path: <alper.yegin@yegin.org> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8186E06B5 for <core@ietfa.amsl.com>; Fri, 6 May 2011 16:21:46 -0700 (PDT) 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=[AWL=-0.000, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kpmCSt+IV0HO for <core@ietfa.amsl.com>; Fri, 6 May 2011 16:21:46 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 1105CE0680 for <core@ietf.org>; Fri, 6 May 2011 16:21:45 -0700 (PDT) Received: from ibm (dsl88-247-34762.ttnet.net.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0Lmrp6-1PogQL0rS0-00ht0p; Fri, 06 May 2011 19:21:29 -0400 From: "Alper Yegin" <alper.yegin@yegin.org> To: "'Carsten Bormann'" <cabo@tzi.org> References: <239072CD-ACC0-454D-8BD6-30AC28D425D9@cisco.com> <059f01cc0b35$a785fc90$f691f5b0$@yegin@yegin.org> <720981EA-6411-4A5C-AC8C-675ADA1A2DE5@cisco.com> <07a401cc0bd8$34e5ab10$9eb10130$@yegin@yegin.org> <09DFFAC9-BB9F-45AD-A7B8-3B2BB9B804BC@tzi.org> <07ee01cc0bff$f2651aa0$d72f4fe0$@yegin@yegin.org> <08C69F93-9AB8-4BC2-B71A-1BADD807661A@tzi.org> In-Reply-To: <08C69F93-9AB8-4BC2-B71A-1BADD807661A@tzi.org> Date: Sat, 7 May 2011 02:21:19 +0300 Message-ID: <096f01cc0c44$531646a0$f942d3e0$@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: AcwMOlfx0bL/OyMmQni5CXPFFK74EwAB0J/A Content-Language: en-us X-Provags-ID: V02:K0:E3G0uqyct3zZFxDVoBwbpwpYDYvJs6oJ9tow5h6BG2s uZDxWILiaCVSwdc9zMMVGjauMP5NiyYJvJ6gauOGG1S2c55yML CNilc1FV590ArWZUQVoaDFfscSDs4Y6HWa7aE+w9gdRBRtfvrH zCJIhdkJghaegsmEzBqJhBmmz0mxwC3uvr0p+ZcHORJHZIrsOU qCEWdINgQSTexYLG5cMg//0ktxQQlinN1FPdxmp2q8= Cc: 'core WG' <core@ietf.org> Subject: Re: [core] draft-ietf-core-coap-06 Security X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 06 May 2011 23:21:47 -0000 > > Good questions, but not for the protocol designers. > > Not for the CoAP protocol proper, but according to our charter, maybe > for the WG. I think that charter statement deserves a discussion, like the one we are having now. IMHO, it should have been put in there after such a discussion and with good scoping. > > For example, IEEE has designed IEEE 802.16e such that ... > > That was easy: This is for use in a specific environment. > We are, however, designing a protocol for the Internet. Right. But then it will also get used in specific environments, which will have its own characteristics that'll drive various design/use considerations. > > These are system and architecture questions. They are answerable only > if we > > start talking about specific ones... > > I'm afraid this cannot be solved if we try to discuss it at the level > of generalities. > That's why I always bring up my lightbulb: If we don't even know how > to do this, we won't be able to solve more general cases. OK, here we go: Your light bulb will be compliant with "Lighting Forum (LF)" which dictates the manufacturer the type of cert profile and the specific root CA to be used when pre-provisioning the bulb at the time of manufacturing. Obviously, LF also says "use CoAP with DTLS". Whatever the controller LF defines also needs to be compliant with the same. LF will determine a mechanism for controllers to be provisioned with ACLs (whitelist of lightbulb IDs). [In Release 1, they'll say "by some out of scope mechanism". In Release 2, they'll try to invent/adopt some standard mechanism for that :)] The bulb also needs to know the ID of the controller. A discovery mechanism is needed. Like I said before, IETF CORE WG can take a stab at this. If not done in IETF, or if the LF does not like it or thinks they can do better, LF will invent/adopt some other standard mechanism. Something like that... > > > These are useful to discuss and understand, but not necessarily for > CoAP to > > solve, IMHO. > > I agree completely -- CoAP is not the protocol that provides the > mechanics for this. > coap-06 is essentially complete from my point of view. > > The question is what we write into the companion security bootstrapping > document: what is our MTI (mandatory to implement) security setup that > we expect every CoAP node to implement? > ("MTI" is not "mandatory to use" -- specific deployments may always > provide more specialized ways to set up security.) Honestly, it may not even be "implemented" in reality. If the SDO/Forum defining the bulb spec decides to use something other than the CORE WG's MTI mechanism, they'll not use up their precise memory footprint for the sake of RFC compliance. They'll do a profiling. > Saying "CoAP can be used in a perfectly secure way, but we don't really > know how to make it so in a realistic Internet use case" is not really > going to cut it. Let's try to go that last mile. Alper > > Gruesse, Carsten From likepeng@huawei.com Fri May 6 19:56:15 2011 Return-Path: <likepeng@huawei.com> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB519E0711 for <core@ietfa.amsl.com>; Fri, 6 May 2011 19:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.555 X-Spam-Level: X-Spam-Status: No, score=0.555 tagged_above=-999 required=5 tests=[AWL=-1.049, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aVBcG-RcpDL5 for <core@ietfa.amsl.com>; Fri, 6 May 2011 19:56:15 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 044F4E0705 for <core@ietf.org>; Fri, 6 May 2011 19:56:15 -0700 (PDT) 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 <0LKT00IZB1HLVP@szxga05-in.huawei.com> for core@ietf.org; Sat, 07 May 2011 10:56:09 +0800 (CST) Received: from szxeml205-edg.china.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 <0LKT00E1C1HKB8@szxga05-in.huawei.com> for core@ietf.org; Sat, 07 May 2011 10:56:09 +0800 (CST) Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Sat, 07 May 2011 10:56:01 +0800 Received: from SZXEML506-MBS.china.huawei.com ([169.254.3.27]) by SZXEML401-HUB.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0270.001; Sat, 07 May 2011 10:56:08 +0800 Date: Sat, 07 May 2011 02:56:08 +0000 From: Likepeng <likepeng@huawei.com> In-reply-to: <FE8FCF1B-02E5-4328-9DD5-B487A237C0DF@tzi.org> X-Originating-IP: [172.24.2.40] To: Carsten Bormann <cabo@tzi.org>, Thomas Herbst <therbst@silverspringnet.com> Message-id: <34966E97BE8AD64EAE9D3D6E4DEE36F2287166@SZXEML506-MBS.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [core] Suggestions re: how to implement HEAD semantics within COAP? Thread-index: AQHMDDcmrlDPWPWG3EaxVp9BYFWhbpSAqm2d X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <C9E98E13.A74D%therbst@silverspringnet.com> <FE8FCF1B-02E5-4328-9DD5-B487A237C0DF@tzi.org> Cc: core <core@ietf.org> Subject: Re: [core] Suggestions re: how to implement HEAD semantics within COAP? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 07 May 2011 02:56:15 -0000 PiBUaGVyZSBpcyBhbHNvIGEgcHJvcG9zYWwgdG8gcHJvdmlkZSBhbiBPcHRpb24gZm9yIENvQVAg dG8gY2Fycnkgc2l6ZSBpbmZvcm1hdGlvbiwgZHJhZnQtbGktY29yZS1jb2FwLXNpemUtb3B0aW9u LTAwLnR4dCAtLSB3ZSBoYXZlbid0IGhhZCBhIGRpc2N1c3Npb24geWV0IG9uIHdoZXRoZXIgdGhp cyBPcHRpb24gc2hvdWxkIGJlIHN0YW5kYXJkaXplZCBvciBub3QuDQo+SWYgc2l6ZSBpcyBpbmRl ZWQgbmVlZGVkLCBLZXBlbmcncyBkcmFmdCBtYXkgYmUgdGhlIHdheSB0byBnby4NCg0KWWVzLCBw ZW9wbGUgd2hvIGhhdmUgaW50ZXJlc3Qgb24gdGhpcyBpc3N1ZSBjYW4gcmV2aWV3IG15IGRyYWZ0 IGFuZCBwcm92aWRlIGZlZWRiYWNrOg0KIGh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1s aS1jb3JlLWNvYXAtc2l6ZS1vcHRpb24tMDAudHh0DQoNClRoYW5rcywNCktpbmQgUmVnYXJkcw0K S2VwZW5nDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6 IGNvcmUtYm91bmNlc0BpZXRmLm9yZyBbY29yZS1ib3VuY2VzQGlldGYub3JnXSC0+rHtIENhcnN0 ZW4gQm9ybWFubiBbY2Fib0B0emkub3JnXQ0Kt6LLzcqxvOQ6IDIwMTHE6jXUwjfI1SA1OjQ2DQq1 vTogVGhvbWFzIEhlcmJzdA0KQ2M6IGNvcmUNCtb3zOI6IFJlOiBbY29yZV0gU3VnZ2VzdGlvbnMg cmU6IGhvdyB0byBpbXBsZW1lbnQgSEVBRCBzZW1hbnRpY3Mgd2l0aGluICBDT0FQPw0KDQpPbiBN YXkgNiwgMjAxMSwgYXQgMjA6MzksIFRob21hcyBIZXJic3Qgd3JvdGU6DQoNCj4gQ2Fyc3RlbiAt DQo+DQo+IEFyZSB5b3Ugc3VnZ2VzdGluZyB0aGVyZSBpcyBubyB2YWx1ZSBpbiBhIGNvbnN0cmFp bmVkIGRldmljZSBoYXZpbmcNCj4gaW5mb3JtYXRpb24gYWJvdXQgdGhlIHNpemUgb2YgYSBwYXls b2FkIGJlZm9yZSBtYWtpbmcgdGhlIHJlcXVlc3QgZm9yIHRoYXQNCj4gcGF5bG9hZD8NCg0KTm8s IEknbSBub3Qgc3VnZ2VzdGluZyB0aGF0IC0tIHRoYXQncyBleGFjdGx5IHdoeSBsaW5rLWZvcm1h dCBoYXMgdGhlIHN6IGF0dHJpYnV0ZS4NClRoZXJlIGlzIGFsc28gYSBwcm9wb3NhbCB0byBwcm92 aWRlIGFuIE9wdGlvbiBmb3IgQ29BUCB0byBjYXJyeSBzaXplIGluZm9ybWF0aW9uLCBkcmFmdC1s aS1jb3JlLWNvYXAtc2l6ZS1vcHRpb24tMDAudHh0IC0tIHdlIGhhdmVuJ3QgaGFkIGEgZGlzY3Vz c2lvbiB5ZXQgb24gd2hldGhlciB0aGlzIE9wdGlvbiBzaG91bGQgYmUgc3RhbmRhcmRpemVkIG9y IG5vdC4NCg0KSSdtIGp1c3Qgbm90IHNlZWluZyB0aGF0IG1hbnkgSEVBRCByZXF1ZXN0cyBvdXQg dGhlcmUgb3V0c2lkZSBsaW5rIGNoZWNrZXJzL2NyYXdsZXJzL3BlcmZvcm1hbmNlIG1vbml0b3Jz Lg0KDQpJIHRoaXMgc3BlY2lmaWMgY29udGV4dCwgSSdtIHRyeWluZyB0byB1bmRlcnN0YW5kIHRo ZSB1c2UtY2FzZSB3aGVyZSBzb21lYm9keSBmcm9tIHRoZSBIVFRQIHNpZGUgKG5vbi0vbGVzcy1j b25zdHJhaW5lZCkgd291bGQgd2FudCB0byByZXF1ZXN0IHRocm91Z2ggdG8gdGhlIENvQVAgc2lk ZSB0byBnZXQgYSByZXByZXNlbnRhdGlvbiBzaXplIGZpcnN0LCBpbnN0ZWFkIG9mIHNpbXBseSBn ZXR0aW5nIHRoZSByZXNvdXJjZSByZXByZXNlbnRhdGlvbi4NCg0KSXMgaXQgd29ydGggc3BlbmRp bmcgZW5lcmd5IG9uIHN1cHBvcnRpbmcgYSBIRUFELXN0eWxlIHJlcXVlc3QgaW4gQ29BUD8NClNv IGZhciwgYWxsIGluZGljYXRpb25zIGhhdmUgYmVlbiB0aGF0IEdFVCBkb2VzIHdoYXQncyBuZWVk ZWQsIGFzIENvQVAgcmVzb3VyY2UgcmVwcmVzZW50YXRpb25zIGFyZSBzbWFsbC4NCklmIHRoZXkg YXJlbid0LCB5b3UgYXJlIGdldHRpbmcgdGhlIGZpcnN0IGJsb2NrIG9ubHkgKHdoaWNoIGlzIGhl bHBlZCB3aXRoIEJsb2NrMihTWlg9MCkpOyB0aGlzIGNvbnRhaW5zIGNydWNpYWwgaW5mb3JtYXRp b24gc3VjaCBhcyBDb250ZW50LVR5cGUsIGp1c3Qgbm90IHNpemUuDQpJZiBzaXplIGlzIGluZGVl ZCBuZWVkZWQsIEtlcGVuZydzIGRyYWZ0IG1heSBiZSB0aGUgd2F5IHRvIGdvLg0KQnV0IHRoZXJl IG5ldmVyIHNlZW1lZCB0byBiZSBhIG5lZWQgZm9yIGFuIG91dHJpZ2h0IEhFQUQgaW4gQ29BUDsg dGhpcyB3b3VsZCBiZSBpcnJlbGV2YW50IG9wdGltaXphdGlvbi4NClRoYXQncyB3aHkgSSdtIGFz a2luZyBmb3IgdXNlLWNhc2VzIC0tIHRoZW9yZXRpY2FsIG5lZWRzIGFyZSBpcnJlbGV2YW50IGZv ciBqdXN0aWZ5aW5nIHRoZSBhZGRpdGlvbmFsIGNvbXBsZXhpdHkuDQoNCkdydWVzc2UsIENhcnN0 ZW4NCg0KDQo+DQo+IHRvbQ0KPg0KPiBPbiA1LzYvMTEgOToyMCBBTSwgIkNhcnN0ZW4gQm9ybWFu biIgPGNhYm9AdHppLm9yZz4gd3JvdGU6DQo+DQo+PiBPbiBNYXkgNiwgMjAxMSwgYXQgMTc6NTQs IFBhdWwgRHVmZnkgd3JvdGU6DQo+Pg0KPj4+IFRoZSB1c2UgY2FzZSBpcyBIVFRQIEhFQUQgaW50 byBhIENPQVAgbmV0d29yayB0byBkZXRlcm1pbmUgdGhlIHNpemUgb2YNCj4+PiBhIHJlc291cmNl Lg0KPj4NCj4+IEhUVFAgSEVBRCBnaXZlcyB5b3UgYSBjb250ZW50LWxlbmd0aCBvbmx5IGlmIEhU VFAgR0VUIHdvdWxkIGhhdmUgZ2l2ZW4NCj4+IHlvdSBhIGNvbnRlbnQtbGVuZ3RoLg0KPj4gU28g dGhpcyB1c2FnZSBvZiBIVFRQIEhFQUQgaXMgYSBiaXQgb24gdGhpbiBpY2Ugb24gdGhlIEhUVFAg c2lkZSBhbHJlYWR5Lg0KPj4NCj4+IENhbiB5b3UgZXhwbGFpbiB0aGUgdXNlIGNhc2UgZm9yICJI VFRQIEhFQUQgaW50byBhIENPQVAgbmV0d29yayB0bw0KPj4gZGV0ZXJtaW5lIHRoZSBzaXplIG9m IGEgcmVzb3VyY2UiPw0KPj4gV2h5IHdvdWxkIHlvdSBldmVyIHdhbnQgdG8gZG8gdGhhdD8NCj4+ IEFuZCBkb2VzIHRoaXMgdXNlIGNhc2Ugb2NjdXIgb2Z0ZW4gZW5vdWdoIHRvIHdhcnJhbnQgYW55 IG9wdGltaXphdGlvbj8NCj4+DQo+PiBHcnVlc3NlLCBDYXJzdGVuDQo+Pg0KPj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IGNvcmUgbWFpbGluZyBs aXN0DQo+PiBjb3JlQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2NvcmUNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCmNvcmUgbWFpbGluZyBsaXN0DQpjb3JlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmU= From paduffy@cisco.com Fri May 6 21:27:17 2011 Return-Path: <paduffy@cisco.com> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2620AE071B for <core@ietfa.amsl.com>; Fri, 6 May 2011 21:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.442 X-Spam-Level: X-Spam-Status: No, score=-10.442 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHWXJdP9gpQX for <core@ietfa.amsl.com>; Fri, 6 May 2011 21:27:16 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by ietfa.amsl.com (Postfix) with ESMTP id 975C5E0718 for <core@ietf.org>; Fri, 6 May 2011 21:27:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paduffy@cisco.com; l=797; q=dns/txt; s=iport; t=1304742436; x=1305952036; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=lAMMK3iIFoMI8ut++jTjgQiQusoWVVHtOQqPW2UBX9g=; b=X8hpAewOwmTDdpUnz4A2vszZKLx7VyB4pOAi72sXFUQrim02dcDutHT1 3rkmGLgGgz/AhGX6zc8rDZo+jVLe7Eaysu21QHbLf6LBDEsNoz2OZiWg6 LhWDCo5ED/58HJ7Ld5huzgVmHMZZbFRX/x97ruUvm009MSGfa29+acIra E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALXJxE2tJV2c/2dsb2JhbACmHneIcZ9CgngPAZpvhgsEj2GEJopR X-IronPort-AV: E=Sophos;i="4.64,329,1301875200"; d="scan'208";a="284555334" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by sj-iport-4.cisco.com with ESMTP; 07 May 2011 04:27:15 +0000 Received: from [10.86.242.61] (che-vpn-cluster-2-61.cisco.com [10.86.242.61]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p474REL7021842; Sat, 7 May 2011 04:27:14 GMT Message-ID: <4DC4CA21.2000902@cisco.com> Date: Sat, 07 May 2011 00:27:13 -0400 From: Paul Duffy <paduffy@cisco.com> Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Carsten Bormann <cabo@tzi.org> References: <4DC40A9D.3060208@cisco.com> <EED8658B-8287-4AD8-993D-FC77425D0D8B@tzi.org> <4DC419B2.5080306@cisco.com> <C70FDB25-1CCD-4FBE-96D5-939B53DB38E6@tzi.org> In-Reply-To: <C70FDB25-1CCD-4FBE-96D5-939B53DB38E6@tzi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: core <core@ietf.org> Subject: Re: [core] Suggestions re: how to implement HEAD semantics within COAP? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: paduffy@cisco.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 07 May 2011 04:27:17 -0000 On 5/6/2011 12:20 PM, Carsten Bormann wrote: > On May 6, 2011, at 17:54, Paul Duffy wrote: > >> The use case is HTTP HEAD into a COAP network to determine the size of a resource. > HTTP HEAD gives you a content-length only if HTTP GET would have given you a content-length. > So this usage of HTTP HEAD is a bit on thin ice on the HTTP side already. > > Can you explain the use case for "HTTP HEAD into a COAP network to determine the size of a resource"? The example is probably better expressed in the opposite direction. A COAP based element needing to determine the size of a large resource before loading it from an HTTP network. > Why would you ever want to do that? > And does this use case occur often enough to warrant any optimization? > > Gruesse, Carsten > > From charles.palmer@onzo.com Sat May 7 03:26:04 2011 Return-Path: <charles.palmer@onzo.com> X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0056E06D1 for <core@ietfa.amsl.com>; Sat, 7 May 2011 03:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.467 X-Spam-Level: X-Spam-Status: No, score=-3.467 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQhteKDAYbtd for <core@ietfa.amsl.com>; Sat, 7 May 2011 03:26:04 -0700 (PDT) Received: from service38.mimecast.com (service38.mimecast.com [195.130.217.47]) by ietfa.amsl.com (Postfix) with SMTP id 8CD6BE06C8 for <core@ietf.org>; Sat, 7 May 2011 03:26:03 -0700 (PDT) Received: from onzosbs2k3.ONZO.local (217.138.5.2 [217.138.5.2]) by service38.mimecast.com; Sat, 07 May 2011 11:26:01 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 7 May 2011 11:25:58 +0100 Message-ID: <E4DBD8AB11D2E54F89B23D7CD1065D8C01D4D8F8@onzosbs2k3.ONZO.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] Suggestions re: how to implement HEAD semantics within COAP? Thread-Index: AcwMiq+P6L/bQIS4SNaAhqylMbMnowAFLfh+ References: <4DC40A9D.3060208@cisco.com><EED8658B-8287-4AD8-993D-FC77425D0D8B@tzi.org><4DC419B2.5080306@cisco.com><C70FDB25-1CCD-4FBE-96D5-939B53DB38E6@tzi.org> <4DC4CA21.2000902@cisco.com> From: "Charles Palmer" <charles.palmer@onzo.com> To: <paduffy@cisco.com>, "Carsten Bormann" <cabo@tzi.org> X-MC-Unique: 111050711260100802 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC0CA1.27F2AC45" Cc: core <core@ietf.org> Subject: Re: [core] Suggestions re: how to implement HEAD semantics within COAP? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/core> List-Post: <mailto:core@ietf.org> List-Help: <mailto:core-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 07 May 2011 10:26:04 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC0CA1.27F2AC45 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable I guess the Size option from draft-li-core-coap-size-option-00 could be ext= ended such that a CoAP GET request including Size=3D0 is treated as a reque= st to get the size of the resource representation (but not the resource pay= load) and so could be translated to and from an HTTP HEAD (and could return= Content-Length to a CoAP requester). -----Original Message----- From: core-bounces@ietf.org on behalf of Paul Duffy Sent: Sat 07/05/2011 05:27 To: Carsten Bormann Cc: core Subject: Re: [core] Suggestions re: how to implement HEAD semantics within = COAP? =20 On 5/6/2011 12:20 PM, Carsten Bormann wrote: > On May 6, 2011, at 17:54, Paul Duffy wrote: > >> The use case is HTTP HEAD into a COAP network to determine the size of a= resource. > HTTP HEAD gives you a content-length only if HTTP GET would have given yo= u a content-length. > So this usage of HTTP HEAD is a bit on thin ice on the HTTP side already. > > Can you explain the use case for "HTTP HEAD into a COAP network to determ= ine the size of a resource"? The example is probably better expressed in the opposite direction. A COAP based element needing to determine the size of a large resource=20 before loading it from an HTTP network. > Why would you ever want to do that? > And does this use case occur often enough to warrant any optimization? > > Gruesse, Carsten > > _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core -------------------------------- Onzo is a limited company number 06097997 registered in England & Wales. Th= e =20 registered office is 6 Great Newport Street, London, WC2H 7JB, United Kingd= om. This email message may contain confidential and/or privileged information, = and is intended solely for the addressee(s). If you have received this email in= =20 error, please notify Onzo immediately. Unauthorised copying, disclosure or= =20 distribution of the material in this email is forbidden. -------------------------------- ------_=_NextPart_001_01CC0CA1.27F2AC45 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Diso-8859-= 1"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version 6.5.7638.1"> <TITLE>RE: [core] Suggestions re: how to implement HEAD semantics within CO= AP? =20 =20

I guess the Size option from draft-li-core-coap-size-opti= on-00 could be extended such that a CoAP GET request including Size=3D0 is = treated as a request to get the size of the resource representation (but no= t the resource payload) and so could be translated to and from an HTTP HEAD= (and could return Content-Length to a CoAP requester).

-----Original Message-----
From: core-bounces@ietf.org on behalf of Paul Duffy
Sent: Sat 07/05/2011 05:27
To: Carsten Bormann
Cc: core
Subject: Re: [core] Suggestions re: how to implement HEAD semantics within = COAP?

On 5/6/2011 12:20 PM, Carsten Bormann wrote:
> On May 6, 2011, at 17:54, Paul Duffy wrote:
>
>> The use case is HTTP HEAD into a COAP network to determine the siz= e of a resource.
> HTTP HEAD gives you a content-length only if HTTP GET would have given= you a content-length.
> So this usage of HTTP HEAD is a bit on thin ice on the HTTP side alrea= dy.
>
> Can you explain the use case for "HTTP HEAD into a COAP network t= o determine the size of a resource"?

The example is probably better expressed in the opposite direction.

A COAP based element needing to determine the size of a large resource
before loading it from an HTTP network.


> Why would you ever want to do that?
> And does this use case occur often enough to warrant any optimization?=
>
> Gruesse, Carsten
>
>

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


--------------------------------
Onzo is a limited company nu= mber 06097997 registered in England & Wales. The
registered office is 6 Great Newport Street, London, WC2H 7JB, Un= ited Kingdom.

This email message may contain confidential and/or privileged inf= ormation, and
is intended solely for the addressee(s). If you have received thi= s email in
error, please notify Onzo im= mediately. Unauthorised copying, disclosure or
distribution of the material in this email is forbidden.
--------------------------------
 ------_=_NextPart_001_01CC0CA1.27F2AC45-- From fluffy@cisco.com Sat May 7 08:35:07 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B33ABE069E for ; Sat, 7 May 2011 08:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.549 X-Spam-Level: X-Spam-Status: No, score=-109.549 tagged_above=-999 required=5 tests=[AWL=-1.054, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7xWf2pMuIvP for ; Sat, 7 May 2011 08:35:07 -0700 (PDT) Received: from sj-iport-1.cisco.com (unknown [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 1D2B9E0682 for ; Sat, 7 May 2011 08:35:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=891; q=dns/txt; s=iport; t=1304782507; x=1305992107; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=FRuOf/RN+MrxGUMnlC6bRfmkDZr7nenv2pjWcHY4E5A=; b=G5/rSnrTDHQexfRVgNR79yNnuBy0156Ju3QNQtUEWm1tNaZFbkligxD3 qQq+Wmsp+nOk3jlXU8QntixeHfHPGiX/MTLrKtYLvIwOSPOJ0m7rFE99f eTd/ZYggRNGEwy0JxRP2rRPfqtyESfFJCDFOqm1BWuPYMAF1KoiTfiH3R E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKVlxU2rRDoI/2dsb2JhbACmJXeIcZ1lnTSGDASGQIkljn0 X-IronPort-AV: E=Sophos;i="4.64,331,1301875200"; d="scan'208";a="443573622" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-1.cisco.com with ESMTP; 07 May 2011 15:35:06 +0000 Received: from sjc-vpn5-683.cisco.com (sjc-vpn5-683.cisco.com [10.21.90.171]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p47FZ6gr013369; Sat, 7 May 2011 15:35:06 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Sat, 7 May 2011 08:35:05 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1DA0334E-AD93-4494-A34D-B817A16A60DD@cisco.com> References: <770C6CBC-E55E-41B2-BA92-1B161C8282A7@cisco.com> To: Carsten Bormann X-Mailer: Apple Mail (2.1084) Cc: core WG Subject: Re: [core] draft-ietf-core-coap-06 IF-Match Option X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2011 15:35:07 -0000 I read the text you have in the misc draft on if-match and thought it = looked just right. As an individual contributor, I would suggest we take = this text and move it to CoAP. I don't see a compelling reasons to add = the If-None-Match. On May 5, 2011, at 12:07 , Carsten Bormann wrote: >> I think this is an important use case that should be supported and we = should add an IF-Match option.=20 >=20 > I just submitted coap-misc-08 with a proposal for that option. >=20 > I didn't try to tackle If-None-Match, which (with the ETag = functionality we already have) is probably mostly relevant for the = single case >=20 > If-None-Match: * >=20 > Do you think there are good use cases for this, too? >=20 > Gruesse, Carsten >=20 Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From fluffy@cisco.com Sat May 7 08:50:31 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 852E9E06BA for ; Sat, 7 May 2011 08:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.526 X-Spam-Level: X-Spam-Status: No, score=-109.526 tagged_above=-999 required=5 tests=[AWL=-1.031, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q5iQfxpvw-D9 for ; Sat, 7 May 2011 08:50:29 -0700 (PDT) Received: from sj-iport-2.cisco.com (unknown [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE8BE0682 for ; Sat, 7 May 2011 08:50:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=2875; q=dns/txt; s=iport; t=1304783429; x=1305993029; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=oF9OhwhGI9XliNcwlF7hH/4kcRkcpc9StScyhTTTSvc=; b=RVBtLsFFrZ6g6MsdGkaJwheyd1m+vU5IyO0J+iLDF0TO5jFWYHoUbfbY 0jmPn72JflWdaABtQcLHBcEJqAXW1hIBNoLo1fenWuhbsJ3kNtBkuUelU BNrSxa6z3JLxbsTnnsMXiqK6IDAOxY5cOdukDdeKLJpq0PMg1I1UBemYx g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAINpxU2rRDoI/2dsb2JhbACmJXeIcZ1nnTSGDASGQIkljn0 X-IronPort-AV: E=Sophos;i="4.64,331,1301875200"; d="scan'208";a="352407236" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 07 May 2011 15:50:29 +0000 Received: from sjc-vpn5-683.cisco.com (sjc-vpn5-683.cisco.com [10.21.90.171]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p47FoSN1020135; Sat, 7 May 2011 15:50:29 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <07a401cc0bd8$34e5ab10$9eb10130$@yegin@yegin.org> Date: Sat, 7 May 2011 08:50:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8BCD950E-FB93-40EE-848C-466E5152DA7C@cisco.com> References: <239072CD-ACC0-454D-8BD6-30AC28D425D9@cisco.com> <059f01cc0b35$a785fc90$f691f5b0$@yegin@yegin.org> <720981EA-6411-4A5C-AC8C-675ADA1A2DE5@cisco.com> <07a401cc0bd8$34e5ab10$9eb10130$@yegin@yegin.org> To: Alper Yegin X-Mailer: Apple Mail (2.1084) Cc: 'core WG' Subject: Re: [core] draft-ietf-core-coap-06 Security X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2011 15:50:31 -0000 On May 6, 2011, at 3:27 , Alper Yegin wrote: >> In the Certificate mode, I do not see how we are covered from on path >> attackers - but I could easily be missing some critical part of the >> draft - I just don't see how the security works yet. For example if = A >> wants to send a message to B and E is an on path attacker. E can MITM >> the DTLS and do whatever they want to the messaging. People keep >> telling me that solving that problem is out of scope for CoAP. Just >> about all the other IETF protocols I have worked on consider that >> problem in scope. I have a hard time imagining this draft getting = past >> IESG with that out of scope. >=20 > Performing mutual TLS authentication leaves no room for a MitM. I = don't > quite understand the threat you are mentioning.=20 So say A has a certificate with device identifier cert-a in SAN of the = cert, E has one with cert-e, and B has one with cert-b. After the = attack, A thinks they are talking to someone with a cert-e. Most other = IETF protocols have a normative way to make sure that when an = application is trying to form a TLS connection to B, you don't end up = accepting an certificate that has cert-e in it. CoAP does not have = something like that in it. You suggest an ACL solution to this which is = fine, but my point is that to have a security story of how the CoAP = protocol protects from given attacks, we need this defined somewhere. I = do not think the IETF is likely to approve CoAP approved without a = normative reference to a document that deal with these sort of issues.=20= If the direction the WG wanted to take to solve this was there was an = ACL list that said when trying to talk to B, expect a cert that says = cert-b, and we had a secure way to distribute that ACL, then we then we = could probably solve all of this without using asymmetric crypto. I agree security design has both protocol and system implications. The = overall way I am looking at the solution, is that if two different = vendors read the CoAP spec and build devices from it, we should be able = to deploy theses devices in some of a bunch (if not all) our use case we = have the the WG and have them work together. I realize that some other = SDOs separate the security much more into the systems design but the = IETF found that when they did that the protocols ended up with no = security and has pushed the security design into the protocols more than = some other SDOs.=20 The most important part of this email is when using TLS, the integrity = and authentication part of it are sort of useless to on path attacks = unless you also have the authentication part of it. Other IETF protocols = define how to do the authentication part of it - I believe we will also = need to say how to make the authentication part of TLS work in CoAP.=20 From cabo@tzi.org Sat May 7 09:21:08 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CFC1E06EC for ; Sat, 7 May 2011 09:21:08 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l0mKcuXbSft0 for ; Sat, 7 May 2011 09:21:07 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 202F5E06BA for ; Sat, 7 May 2011 09:21:06 -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 p47G8bT5026698; Sat, 7 May 2011 18:08:37 +0200 (CEST) Received: from [192.168.217.112] (p54899ADF.dip.t-dialin.net [84.137.154.223]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 238D0A28; Sat, 7 May 2011 18:08:37 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <1DA0334E-AD93-4494-A34D-B817A16A60DD@cisco.com> Date: Sat, 7 May 2011 18:08:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <770C6CBC-E55E-41B2-BA92-1B161C8282A7@cisco.com> <1DA0334E-AD93-4494-A34D-B817A16A60DD@cisco.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1084) Cc: core WG Subject: Re: [core] draft-ietf-core-coap-06 IF-Match Option X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2011 16:21:08 -0000 On May 7, 2011, at 17:35, Cullen Jennings wrote: >=20 > I read the text you have in the misc draft on if-match and thought it = looked just right. As an individual contributor, I would suggest we take = this text and move it to CoAP. I don't see a compelling reasons to add = the If-None-Match. The only one that sounds useful is "If-None-Match: *", which allows to = restrict a PUT to a "Create", similar to the way "If-Match: *" restricts = it to a "Replace". "Create" actually is much more useful than "Replace" = -- if you do the latter, you probably know what you are replacing, so = you could give the ETag for a full "If-Match: ___". Just a thought. Gruesse, Carsten From trac+core@trac.tools.ietf.org Sat May 7 13:07:22 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18A4CE0737 for ; Sat, 7 May 2011 13:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.596 X-Spam-Level: X-Spam-Status: No, score=-104.596 tagged_above=-999 required=5 tests=[AWL=2.003, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VW0b0xtLy-PO for ; Sat, 7 May 2011 13:07:09 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) by ietfa.amsl.com (Postfix) with ESMTP id 8CFBFE0735 for ; Sat, 7 May 2011 13:07:09 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QInmN-0007Pl-UD; Sat, 07 May 2011 13:07:07 -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, 07 May 2011 20:07:07 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/149 Message-ID: <051.da85a5b3711b520f501e5bff6373fa2b@trac.tools.ietf.org> X-Trac-Ticket-ID: 149 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] #149: Text for PUT/POST response payloads is missing X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2011 20:07:22 -0000 #149: Text for PUT/POST response payloads is missing (Add as third paragraph of 5.5:) 2.01 (Created), 2.02 (Deleted), 2.04 (Changed) MAY include payload that is describing the result of the action. Again, the format of this payload is specified by the Internet media type given by the Content-Type Option; no default value is assumed in the absence of this option. (+ 1 sentence each at the three response codes in 5.9.1.1, 5.9.1.2, 5.9.1.4:) The payload returned with the response, if any, is a representation of the action result. The representation format is specified by the media type given in the Content-Type Option. Thanks for the heads-up, Guido! -- --------------------------------+------------------------------------------- Reporter: cabo@… | Owner: cabo@… Type: protocol defect | Status: new Priority: major | Milestone: Component: coap | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From alper.yegin@yegin.org Sat May 7 13:34:52 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EBCFE06F1 for ; Sat, 7 May 2011 13:34:52 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jxXrE+PqevWM for ; Sat, 7 May 2011 13:34:52 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id E3E29E066E for ; Sat, 7 May 2011 13:34:51 -0700 (PDT) Received: from ibm (dsl88-247-34762.ttnet.net.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0M6iYm-1PVFtj1m8i-00wIxW; Sat, 07 May 2011 16:34:50 -0400 From: "Alper Yegin" To: "'Cullen Jennings'" References: <239072CD-ACC0-454D-8BD6-30AC28D425D9@cisco.com> <059f01cc0b35$a785fc90$f691f5b0$@yegin@yegin.org> <720981EA-6411-4A5C-AC8C-675ADA1A2DE5@cisco.com> <07a401cc0bd8$34e5ab10$9eb10130$@yegin@yegin.org> <8BCD950E-FB93-40EE-848C-466E5152DA7C@cisco.com> In-Reply-To: <8BCD950E-FB93-40EE-848C-466E5152DA7C@cisco.com> Date: Sat, 7 May 2011 23:34:43 +0300 Message-ID: <09b901cc0cf6$35877660$a0966320$@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: AcwMzn3IiSkX6HdoTu+5q9GjTPzNlgAJh5yg Content-Language: en-us X-Provags-ID: V02:K0:eNZL4VsGvE/dl9leWVPcgsKnwXWLZAdXD5xjeiaIbEH FffH1QWEmHkLmOtoGxGMXPrviXpKR0sT5t9KYL6Qme6WcCjdDb 74jQ6V08HsiOMt6oDfXARLUs0VwyQDycgE9a8wKdYRcj5dYMLs UFyzjOxdw2lY/zEJ7oFv2NZrfAwCkWwdJaK7mSanKuwwFVc2MF 1SX9PjAQFA1Byzl0UmGRriztZoIS+2GNHDRGAprBCg= Cc: 'core WG' Subject: Re: [core] draft-ietf-core-coap-06 Security X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2011 20:34:52 -0000 Cullen, > On May 6, 2011, at 3:27 , Alper Yegin wrote: > > >> In the Certificate mode, I do not see how we are covered from on > path > >> attackers - but I could easily be missing some critical part of the > >> draft - I just don't see how the security works yet. For example if > A > >> wants to send a message to B and E is an on path attacker. E can > MITM > >> the DTLS and do whatever they want to the messaging. People keep > >> telling me that solving that problem is out of scope for CoAP. Just > >> about all the other IETF protocols I have worked on consider that > >> problem in scope. I have a hard time imagining this draft getting > past > >> IESG with that out of scope. > > > > Performing mutual TLS authentication leaves no room for a MitM. I > don't > > quite understand the threat you are mentioning. > > So say A has a certificate with device identifier cert-a in SAN of the > cert, E has one with cert-e, and B has one with cert-b. After the > attack, A thinks they are talking to someone with a cert-e. Most other > IETF protocols have a normative way to make sure that when an > application is trying to form a TLS connection to B, you don't end up > accepting an certificate that has cert-e in it. CoAP does not have > something like that in it. You suggest an ACL solution to this which is > fine, but my point is that to have a security story of how the CoAP > protocol protects from given attacks, we need this defined somewhere. I > do not think the IETF is likely to approve CoAP approved without a > normative reference to a document that deal with these sort of issues. There needs to be a binding between the CoAP and DTLS. Whatever identifier is used at CoAP layer has to match the identifier that got authenticated at the DTLS layer. Otherwise, yes, what you are describing can happen. > If the direction the WG wanted to take to solve this was there was an > ACL list that said when trying to talk to B, expect a cert that says > cert-b, and we had a secure way to distribute that ACL, then we then we > could probably solve all of this without using asymmetric crypto. I'm not sure the symmetric vs. asymmetric crypto is a factor here. I think the issue is, the end-point authentication is happening at a layer other than the one using the associated identifiers. There needs to be a binding between the two. > I agree security design has both protocol and system implications. The > overall way I am looking at the solution, is that if two different > vendors read the CoAP spec and build devices from it, we should be able > to deploy theses devices in some of a bunch (if not all) our use case > we have the the WG and have them work together. I realize that some > other SDOs separate the security much more into the systems design but > the IETF found that when they did that the protocols ended up with no > security and has pushed the security design into the protocols more > than some other SDOs. > > The most important part of this email is when using TLS, the integrity > and authentication part of it are sort of useless to on path attacks > unless you also have the authentication part of it. TLS provides end-point authentication, followed by creating a secure transport that provides integrity and replay protection, data origin authentication, and privacy for the data. > Other IETF > protocols define how to do the authentication part of it - I believe we > will also need to say how to make the authentication part of TLS work > in CoAP. By the way, I wonder why this WG chose to use TLS. Why not define a CoAP-layer security extension. We can do something similar to what was done for Mobile IPv4, another UDP-based protocol. Define an option that carries a keyed hash of the CoAP header + payloads. And you get data origin auth, integrity and replay protection. And define another option to encrypt the ones that require privacy. (encryption part not in Mobile IPv4). Alper Alper From likepeng@huawei.com Sat May 7 23:01:10 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F393E06B0 for ; Sat, 7 May 2011 23:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.92 X-Spam-Level: X-Spam-Status: No, score=-0.92 tagged_above=-999 required=5 tests=[AWL=1.475, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id odNh1m9ZQJRT for ; Sat, 7 May 2011 23:00:57 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 5B5BDE0662 for ; Sat, 7 May 2011 23:00:57 -0700 (PDT) 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 <0LKV004674PDUZ@szxga04-in.huawei.com> for core@ietf.org; Sun, 08 May 2011 14:00:49 +0800 (CST) Received: from szxeml202-edg.china.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 <0LKV00E644PDYH@szxga04-in.huawei.com> for core@ietf.org; Sun, 08 May 2011 14:00:49 +0800 (CST) Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Sun, 08 May 2011 14:00:31 +0800 Received: from SZXEML506-MBS.china.huawei.com ([169.254.3.27]) by szxeml403-hub.china.huawei.com ([169.254.173.75]) with mapi id 14.01.0270.001; Sun, 08 May 2011 14:00:48 +0800 Date: Sun, 08 May 2011 06:00:47 +0000 From: Likepeng In-reply-to: X-Originating-IP: [172.24.2.40] To: Charles Palmer , "paduffy@cisco.com" , Carsten Bormann Message-id: <34966E97BE8AD64EAE9D3D6E4DEE36F22872CF@SZXEML506-MBS.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_f4UJJ0g685Y1sTL1ByEJXA)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: [core] Suggestions re: how to implement HEAD semantics within COAP? Thread-index: AQHMDKE8AsUHravVjkyl8utZN2pH4ZSCcIYk X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <4DC40A9D.3060208@cisco.com> <4DC419B2.5080306@cisco.com> <4DC4CA21.2000902@cisco.com> Cc: core Subject: Re: [core] Suggestions re: how to implement HEAD semantics within COAP? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 May 2011 06:01:10 -0000 --Boundary_(ID_f4UJJ0g685Y1sTL1ByEJXA) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 PiBJIGd1ZXNzIHRoZSBTaXplIG9wdGlvbiBmcm9tIGRyYWZ0LWxpLWNvcmUtY29hcC1zaXplLW9w dGlvbi0wMCBjb3VsZCBiZSBleHRlbmRlZCBzdWNoIHRoYXQgYSBDb0FQIEdFVCByZXF1ZXN0IGlu Y2x1ZGluZyBTaXplPTAgaXMgdHJlYXRlZCBhcyBhIHJlcXVlc3QgdG8gZ2V0IHRoZSBzaXplIG9m IHRoZSByZXNvdXJjZSByZXByZXNlbnRhdGlvbiAoYnV0IG5vdCB0aGUgcmVzb3VyY2UgcGF5bG9h ZCkgYW5kIHNvIGNvdWxkIGJlIHRyYW5zbGF0ZWQgdG8gYW5kIGZyb20gYW4gSFRUUCBIRUFEIChh bmQgY291bGQgcmV0dXJuIENvbnRlbnQtTGVuZ3RoIHRvIGEgQ29BUCByZXF1ZXN0ZXIpLg0KDQoN Cg0KR29vZCBzdWdnZXN0aW9uLiBJIHdpbGwgYWRkIHRoaXMgaW4gLTAxLCBpZiB0aGVyZSBhcmUg bm8gb3RoZXIgb3BpbmlvbnMuDQoNCg0KDQpUaGFua3MsDQoNCktpbmQgUmVnYXJkcw0KDQpLZXBl bmcNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCreivP7IyzogY29yZS1ib3Vu Y2VzQGlldGYub3JnIFtjb3JlLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gQ2hhcmxlcyBQYWxtZXIg W2NoYXJsZXMucGFsbWVyQG9uem8uY29tXQ0Kt6LLzcqxvOQ6IDIwMTHE6jXUwjfI1SAxODoyNQ0K tb06IHBhZHVmZnlAY2lzY28uY29tOyBDYXJzdGVuIEJvcm1hbm4NCkNjOiBjb3JlDQrW98ziOiBS ZTogW2NvcmVdIFN1Z2dlc3Rpb25zIHJlOiBob3cgdG8gaW1wbGVtZW50IEhFQUQgc2VtYW50aWNz IHdpdGhpbiBDT0FQPw0KDQoNCg0KSSBndWVzcyB0aGUgU2l6ZSBvcHRpb24gZnJvbSBkcmFmdC1s aS1jb3JlLWNvYXAtc2l6ZS1vcHRpb24tMDAgY291bGQgYmUgZXh0ZW5kZWQgc3VjaCB0aGF0IGEg Q29BUCBHRVQgcmVxdWVzdCBpbmNsdWRpbmcgU2l6ZT0wIGlzIHRyZWF0ZWQgYXMgYSByZXF1ZXN0 IHRvIGdldCB0aGUgc2l6ZSBvZiB0aGUgcmVzb3VyY2UgcmVwcmVzZW50YXRpb24gKGJ1dCBub3Qg dGhlIHJlc291cmNlIHBheWxvYWQpIGFuZCBzbyBjb3VsZCBiZSB0cmFuc2xhdGVkIHRvIGFuZCBm cm9tIGFuIEhUVFAgSEVBRCAoYW5kIGNvdWxkIHJldHVybiBDb250ZW50LUxlbmd0aCB0byBhIENv QVAgcmVxdWVzdGVyKS4NCg0KDQo= --Boundary_(ID_f4UJJ0g685Y1sTL1ByEJXA) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

> I guess the Size option from draft-li-core-coap-size-option-00 coul= d be extended such that a CoAP GET request including Size=3D0 is treated as= a request to get the size of the resource representation (but not the reso= urce payload) and so could be translated to and from an HTTP HEAD (and could return Content-Length to a CoAP reques= ter).

 

Good suggestion. I will add this in -01, if there are no other opinions.=

 

Thanks,

Kind Regards

Kepeng

=B7=A2=BC=FE=C8=CB: core-bounces@ietf.org = [core-bounces@ietf.org] =B4=FA=B1=ED Charles Palmer [charles.palmer@onzo.co= m]
=B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA5=D4=C27=C8=D5 18:25
=B5=BD: paduffy@cisco.com; Carsten Bormann
Cc: core
=D6=F7=CC=E2: Re: [core] Suggestions re: how to implement HEAD seman= tics within COAP?


I guess the Size option from draft-li-core-coap-size-op= tion-00 could be extended such that a CoAP GET request including Size=3D0 i= s treated as a request to get the size of the resource representation (but = not the resource payload) and so could be translated to and from an HTTP HEAD (and could return Content-Length to= a CoAP requester).

 

--Boundary_(ID_f4UJJ0g685Y1sTL1ByEJXA)-- From cabo@tzi.org Sun May 8 05:51:11 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8053AE0756 for ; Sun, 8 May 2011 05:51: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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPfxJkoJ8EFJ for ; Sun, 8 May 2011 05:51:11 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 73A74E0663 for ; Sun, 8 May 2011 05:51:09 -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 p48C13E9021402; Sun, 8 May 2011 14:01:03 +0200 (CEST) Received: from [192.168.217.101] (p5489A52D.dip.t-dialin.net [84.137.165.45]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id C685DAD9; Sun, 8 May 2011 14:01:00 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <34966E97BE8AD64EAE9D3D6E4DEE36F22872CF@SZXEML506-MBS.china.huawei.com> Date: Sun, 8 May 2011 14:01:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DC40A9D.3060208@cisco.com> <4DC419B2.5080306@cisco.com> <4DC4CA21.2000902@cisco.com> <34966E97BE8AD64EAE9D3D6E4DEE36F22872CF@SZXEML506-MBS.china.huawei.com> To: Likepeng X-Mailer: Apple Mail (2.1084) Cc: core Subject: Re: [core] Suggestions re: how to implement HEAD semantics within COAP? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 May 2011 12:51:11 -0000 A couple of observations: -- The Size Option is defined to be Elective. That means that any usage = in a request to influence the semantics of GET will also be Elective. I = think that is OK, but it calls for some additional thought. -- Size has a similar dependency on the method that Block had before we = split it in Block1/Block2. That need not be a problem (the old Block = was fine for its intended area of application), but it also means that = there will be no way to provide the new semantics for controlling the = responses of PUT/POST. Probably also OK. Generally, using the same option with two different semantics depending = on its context (here: indication of the full size of a block-wise = transfer vs. controlling the size of the block) requires a lot of care = to ensure this doesn't bite back. Note that the Block2 option already = can control the size of the payload slice coming back from a GET; maybe = we want to extend that option with the new semantics instead of Size. = I'm not sure. Also, reading -00, I cannot reconcile If the Size option is specified it MUST be accurate at that time, and MUST NOT be an estimate. But due to the dynamic change of the resource data, the Size may not be accurate. If the value of Size option is not the same as the ... The point of a MUST is to give one of the parties in a protocol = something that this party can rely on. The second paragraph takes the reliability of this property away again, = so is appears there is no useful effect from the MUST. If that train of thought is correct, the MUST *should* be a SHOULD. Finally, it's probably important to consider that HTTP has developed = chunked transfer-coding precisely to enable the start of a transfer = *without* knowing the size in advance. We should not expect our = constrained nodes to be able do better than HTTP end-points here, so: The Size option is not expected to be included for small resources that can easily be carried in a single MTU, but SHOULD be included for resources larger than that. ... the SHOULD here clearly is qualified by the availability of the = size. E.g., I wouldn't want to read this as "a CoAP to HTTP mapper = SHOULD retrieve the entire resource representation from HTTP if that is = provided in chunked transfer-coding, in order to have a size estimate" = -- instead, many mappers will best (unless there is a cached value) omit = the size option. Gruesse, Carsten From likepeng@huawei.com Sun May 8 20:24:13 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DACDE06E4 for ; Sun, 8 May 2011 20:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.514 X-Spam-Level: X-Spam-Status: No, score=-3.514 tagged_above=-999 required=5 tests=[AWL=3.085, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YwjuSjM+LlEC for ; Sun, 8 May 2011 20:24:12 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 2A803E069A for ; Sun, 8 May 2011 20:24:12 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKW00LW6S48C7@szxga03-in.huawei.com> for core@ietf.org; Mon, 09 May 2011 11:24:09 +0800 (CST) Received: from szxeml202-edg.china.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 <0LKW00AMKS484S@szxga03-in.huawei.com> for core@ietf.org; Mon, 09 May 2011 11:24:08 +0800 (CST) Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 09 May 2011 11:24:07 +0800 Received: from SZXEML506-MBS.china.huawei.com ([169.254.3.27]) by SZXEML401-HUB.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0270.001; Mon, 09 May 2011 11:24:07 +0800 Date: Mon, 09 May 2011 03:24:07 +0000 From: Likepeng In-reply-to: X-Originating-IP: [10.70.109.110] To: Carsten Bormann Message-id: <34966E97BE8AD64EAE9D3D6E4DEE36F2287481@SZXEML506-MBS.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [core] Suggestions re: how to implement HEAD semantics within COAP? Thread-index: AQHMDfiNWaobSuveY0ei6lVAXGb1Xw== X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <4DC40A9D.3060208@cisco.com> <4DC419B2.5080306@cisco.com> <4DC4CA21.2000902@cisco.com> <34966E97BE8AD64EAE9D3D6E4DEE36F22872CF@SZXEML506-MBS.china.huawei.com> Cc: core Subject: Re: [core] Suggestions re: how to implement HEAD semantics within COAP? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 03:24:13 -0000 Thanks for the review. > Generally, using the same option with two different semantics depending on its context (here: indication of the full size of a block-wise transfer vs. controlling the size of the block) requires a lot of care to ensure this doesn't bite back. They use different options, so it would be fine. That is, Size option to indicate the whole size of the resource payload, but SZX field in Block option to indicate the block size. > If that train of thought is correct, the MUST *should* be a SHOULD. Agree, will change it in -01. > ..the SHOULD here clearly is qualified by the availability of the size Will change it to "..but SHOULD be included for resources larger than that, if the size information is available." Kind Regards Kepeng -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org] Sent: Sunday, May 08, 2011 8:01 PM To: Likepeng Cc: Charles Palmer; paduffy@cisco.com; core Subject: Re: [core] Suggestions re: how to implement HEAD semantics within COAP? A couple of observations: -- The Size Option is defined to be Elective. That means that any usage in a request to influence the semantics of GET will also be Elective. I think that is OK, but it calls for some additional thought. -- Size has a similar dependency on the method that Block had before we split it in Block1/Block2. That need not be a problem (the old Block was fine for its intended area of application), but it also means that there will be no way to provide the new semantics for controlling the responses of PUT/POST. Probably also OK. Generally, using the same option with two different semantics depending on its context (here: indication of the full size of a block-wise transfer vs. controlling the size of the block) requires a lot of care to ensure this doesn't bite back. Note that the Block2 option already can control the size of the payload slice coming back from a GET; maybe we want to extend that option with the new semantics instead of Size. I'm not sure. Also, reading -00, I cannot reconcile If the Size option is specified it MUST be accurate at that time, and MUST NOT be an estimate. But due to the dynamic change of the resource data, the Size may not be accurate. If the value of Size option is not the same as the ... The point of a MUST is to give one of the parties in a protocol something that this party can rely on. The second paragraph takes the reliability of this property away again, so is appears there is no useful effect from the MUST. If that train of thought is correct, the MUST *should* be a SHOULD. Finally, it's probably important to consider that HTTP has developed chunked transfer-coding precisely to enable the start of a transfer *without* knowing the size in advance. We should not expect our constrained nodes to be able do better than HTTP end-points here, so: The Size option is not expected to be included for small resources that can easily be carried in a single MTU, but SHOULD be included for resources larger than that. ... the SHOULD here clearly is qualified by the availability of the size. E.g., I wouldn't want to read this as "a CoAP to HTTP mapper SHOULD retrieve the entire resource representation from HTTP if that is provided in chunked transfer-coding, in order to have a size estimate" -- instead, many mappers will best (unless there is a cached value) omit the size option. Gruesse, Carsten From zach@sensinode.com Mon May 9 05:01:28 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B10FEE06F6 for ; Mon, 9 May 2011 05:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 397jhTO6e6Xy for ; Mon, 9 May 2011 05:01:27 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 26B51E068D for ; Mon, 9 May 2011 05:01:26 -0700 (PDT) Received: from 87-95-150-53.bb.dnainternet.fi (87-95-150-53.bb.dnainternet.fi [87.95.150.53]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id p49C1Gqo029746 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 9 May 2011 15:01:18 +0300 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-42-217763437; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: <9CF83338-EB7C-4831-8A44-8DEEF0C42D54@cisco.com> Date: Mon, 9 May 2011 15:01:17 +0300 Message-Id: <9DC0A259-3170-4C40-BAB3-697B30FB548C@sensinode.com> References: <9CF83338-EB7C-4831-8A44-8DEEF0C42D54@cisco.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1084) Cc: core WG Subject: Re: [core] Comments on draft-ietf-core-link-format-04 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 12:01:28 -0000 --Apple-Mail-42-217763437 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Cullen, Thanks for the review, comments in-line. Would like to have Alexey's = opinion on these too. On May 4, 2011, at 8:29 PM, Cullen Jennings wrote: >=20 > Mediums sized issue: >=20 > I'm confused by the Encoding considerations in link-format-04 which = are listed as "8bit (UTF-8 (NFC))". I suspect this should just say = "binary". If this is really NFC, then does it mean constrained nodes = need to do the canonicalization? Most places in the draft it makes it = clear that you processes the data as binary data. Every implementation = I have seen treats this as binary data - even section 4.1 describes a = bitwise identical comparison. We also have the issue that RFC 2045 says=20= >=20 > "8bit data" refers to data that is all represented as relatively > short lines with 998 octets or less between CRLF line separation >=20 > and >=20 > "Binary data" refers to data where any sequence of octets whatsoever > is allowed. >=20 > I think what we have here is binary data which seems fine. This is = meant to be be machine readable and it's not like we have to enforce = that no lines is longer than 1000 octets. Yes, many of the strings in = the binary blob of data may happen to be UTF-8 strings that are even in = Normalized Form C but unless we get more specific about when and where = this gets normalized I don't see how specifying this is NFC data helps. = In fact most, if not all, of this is from a far more restricted grammar = than UTF-8 NFC.=20 The 8bit was suggested by Alexey. I would be fine with "Binary data", = your point makes sense. I will make a ticket if I don't hear any = objections.=20 >=20 > Related to this, where it says the CoRE link format MUST be in UTF-8 = and SHOULD be NFC. This seems wrong unless we are updating RFC5988. = RFC5988 makes it clear the links are as defined in rfc3986. We don't = need to say any more or less than RFC5988. Unless someone can tell me = how my implementation and interoperability changes by specifying UTF-8 = and NFC, I'd like to see that removed. The phrase "MUST be compared as = strings" is pretty vague when discussing UTF-8 strings. If people = disagree here, I'm going to argue that unicode has a perfectly good = symbol for angstrom and if someone wants to use that, I think they = should be able to use it. Given this is format is for machine = readability, an angstrom is not the same as a character that might look = the same when printed on paper and that difference should not be lost. =20= >=20 > All in all, the documents this depends on, such as 5988 deal with the = right level of using UTF-8. This draft should just be silent on the = issue and you can probably remove all mention of UTF-8. Regardless of = the UTF-8 issues, it seems the media type registration should have = binary not 8bit.=20 This is how I started out, but in a couple review's a couple versions = back it was suggested that we specify UTF-8 and we made a ticket for = that. The intention is definitely to be in line with RFC5988, so I would = be more than happy to have no mention of UTF-8 in the document and = instead just say "the links are as defined in rfc3986". Again, will make = a ticket if I hear no objections. > Minor Issues: >=20 > The ABNF you are using for integer allows leading zero. Not sure you = want that if you don't want to deal with if 041 matches 41.=20 Yep, will fix that.=20 > Has an review request been sent to ietf-types? I could not find one. Not yet, I have an AP to do that. > You could even put the data of the review request was sent in the = draft with a note to the RFC editor to remove that before publication. = That makes things easier for future reviews as this goes through LC and = IESG.=20 >=20 >=20 > It's never 100% clear to me how to till out the templates but I = suspect that the template should have an=20 >=20 > Author: Zach Shelby >=20 > and a=20 >=20 > Change controller: IETF CORE Working Group delegated from the IESG. >=20 > Don't worry - if we get that wrong, it will get fixed when IANA does = their LC review.=20 Thanks. >=20 > We should consider removing section 7.4 and this draft is ahead of = coap. The coap draft can just register this type with no need to mention = it here.=20 Sure, this makes sense in my opinion.=20 Zach >=20 >=20 > Cullen > _______________________________________________ > 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-42-217763437 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 ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDUwOTEyMDEx OFowIwYJKoZIhvcNAQkEMRYEFOl4rAvenf00Qc0nhz0SpcId5GeRMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAJAEgNoagiOIlaKVBVD1abJGlrqYJi68dkztn3u+a9OXw3wYjuMsAMbE Acs3nYt2DVSyrZLxeKxpimDdDV74/8QDh82StSLBHzeJJHPDm2+KUKh76BF18vqyLCOSq2uiEuL0 AtDMf9+Ez5Pji03+yMbpGkLUhx+q2I/meVyWXybm36fb1cbbcxC46NfrsYhH0bDRdk9W8jBhiGHP i67CyqWQ430ncHt2LcTKp02bUBld4ILc066AXYU6tbH+2ghKrs/INBUB9NqxmSYNcEiAO4Z2UHqp XnKvxUSFA4vledTTNRh4as1HK07HQN40wCy+QXgB2JG8kVGEMqGDJ7l1nsYAAAAAAAA= --Apple-Mail-42-217763437-- From Internet-Drafts@ietf.org Mon May 9 09:30:08 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD3E6E0857; Mon, 9 May 2011 09:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LlaedN8vT+aM; Mon, 9 May 2011 09:30:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6579FE0858; Mon, 9 May 2011 09:30:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.53 Message-ID: <20110509163003.30973.15017.idtracker@ietfa.amsl.com> Date: Mon, 09 May 2011 09:30:03 -0700 Cc: core@ietf.org Subject: [core] I-D ACTION:draft-ietf-core-block-03.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 16:30:08 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments Working Group of the IETF. Title : Blockwise transfers in CoAP Author(s) : C. Bormann, et al Filename : draft-ietf-core-block-03.txt Pages : 23 Date : 2011-05-03 CoAP is a RESTful transfer protocol for constrained nodes and networks. CoAP is based on datagram transport, which limits the maximum size of resource representations that can be transferred without too much fragmentation. The Block options provide a minimal way to transfer larger representations in a block-wise fashion. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-core-block-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-core-block-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-05-09092234.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Mon May 9 09:30:11 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB583E0873; Mon, 9 May 2011 09:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vvzbx9kDqBFs; Mon, 9 May 2011 09:30:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95D58E0864; Mon, 9 May 2011 09:30:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.53 Message-ID: <20110509163003.30973.43147.idtracker@ietfa.amsl.com> Date: Mon, 09 May 2011 09:30:03 -0700 Cc: core@ietf.org Subject: [core] I-D ACTION:draft-ietf-core-coap-06.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 16:30:11 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments Working Group of the IETF. Title : Constrained Application Protocol (CoAP) Author(s) : Z. Shelby, et al Filename : draft-ietf-core-coap-06.txt Pages : 80 Date : 2011-05-03 This document specifies the Constrained Application Protocol (CoAP), a specialized web transfer protocol for use with constrained networks and nodes for machine-to-machine applications such as smart energy and building automation. These constrained nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while networks such as 6LoWPAN often have high packet error rates and a typical throughput of 10s of kbit/s. CoAP provides a method/response interaction model between application end-points, supports built-in resource discovery, and includes key web concepts such as URIs and content-types. CoAP easily translates to HTTP for integration with the web while meeting specialized requirements such as multicast support, very low overhead and simplicity for constrained environments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-core-coap-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-core-coap-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-05-09092547.I-D@ietf.org> --NextPart-- From fluffy@cisco.com Mon May 9 12:04:45 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93A16E0782 for ; Mon, 9 May 2011 12:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.556 X-Spam-Level: X-Spam-Status: No, score=-110.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6YRFvBNDzsW for ; Mon, 9 May 2011 12:04:41 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id CD80CE0795 for ; Mon, 9 May 2011 12:04:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1225; q=dns/txt; s=iport; t=1304967880; x=1306177480; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=s6gaie6DpsXx2RDatTIjCtFmapw1sDMe7Pas3frQ5Qw=; b=TH7n76jsZLjvKkzar60aOFLmQNnMhylfO+kPfFGv8vhqwWQYcrntx5at s47G5FFfC5Yu1xZXYhSMs5BqdA2eqa04jga3lsldC+Kj7YOL3Df7CVCWo hrea92Y5aAI4/xM4FHcl9j2bzZ3vrNrJMdbAP5mqqpm8d6iJCWwqLCWSs M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuoHANI5yE2rRDoH/2dsb2JhbACYEo1vd6h/nh+GDASGQIkljn0 X-IronPort-AV: E=Sophos;i="4.64,341,1301875200"; d="scan'208";a="311754697" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-3.cisco.com with ESMTP; 09 May 2011 19:04:40 +0000 Received: from dhcp-171-68-21-134.cisco.com (dhcp-171-68-21-134.cisco.com [171.68.21.134]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p49J4e7m001190; Mon, 9 May 2011 19:04:40 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Cullen Jennings In-Reply-To: <053.23fd175ad3e8fb1a4a7303089729c32f@trac.tools.ietf.org> Date: Mon, 9 May 2011 09:14:23 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <053.23fd175ad3e8fb1a4a7303089729c32f@trac.tools.ietf.org> To: trac+core@trac.tools.ietf.org X-Mailer: Apple Mail (2.1084) Cc: core@ietf.org, hartke@tzi.org Subject: Re: [core] #132: Separate response implicitly acks confirmable request X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 19:04:45 -0000 Do you MAY stop or SHOULD stop or MUST stop ? On Mar 29, 2011, at 10:30 , core issue tracker wrote: > #132: Separate response implicitly acks confirmable request >=20 > Implementation note: When a client receives a separate response (CON) = but > hasn't received an ACK for the confirmable request yet, then the = client > can stop retransmitting the request. >=20 > --=20 > = --------------------------------+-----------------------------------------= -- > Reporter: hartke@=85 | Owner: =20 > Type: editorial | Status: new > Priority: minor | Milestone: =20 > Component: coap | Version: =20 > Severity: Active WG Document | Keywords: =20 > = --------------------------------+-----------------------------------------= -- >=20 > Ticket URL: > core >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From fluffy@cisco.com Mon May 9 12:27:42 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B22EE081A for ; Mon, 9 May 2011 12:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.557 X-Spam-Level: X-Spam-Status: No, score=-110.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5LGC-+6+sQGt for ; Mon, 9 May 2011 12:27:41 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 78F57E06DB for ; Mon, 9 May 2011 12:27:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=4539; q=dns/txt; s=iport; t=1304969261; x=1306178861; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=nvHHUkWmZA5qVL2rVnc7b9MQtGsGNSdi0wHXjRO1t2Q=; b=koGf4K7rTIN4AD/gCqFFwimdVO+QqbgRUYSHzGEOKJf8uQFk64V14SXf oOA21uSDDSLtp8updy/vJkyW5jak5UyBeJrpcYHCdpMfpY8d/VeRWBDcE cHCwvqQVrAmNxguWa7uKFa/7q45stsH7PlBX5P5iGQaklMv2TfkYYFyso U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEACw/yE2rRDoI/2dsb2JhbACmAXeobp4ghgwEhkCJJY59 X-IronPort-AV: E=Sophos;i="4.64,342,1301875200"; d="scan'208";a="694391178" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-6.cisco.com with ESMTP; 09 May 2011 19:27:41 +0000 Received: from dhcp-171-68-21-134.cisco.com (dhcp-171-68-21-134.cisco.com [171.68.21.134]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p49JRf0c026980; Mon, 9 May 2011 19:27:41 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 9 May 2011 12:27:43 -0700 Message-Id: <65C046E2-65E4-4C20-B1AB-CBE12C9B8164@cisco.com> To: core WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [core] draft-ietf-core-block-03 review X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 19:27:42 -0000 What happens if the resource changes part way through a GET? For = devices that make a virtual snapshot of the resource, I'd like the it so = that if the resources changes while the transfer is happing, the value = the client receives is the value of resources when the server received = the first get. There need to be some sort of minimum timeout so that the = client knows the server will not discard the snapshot while the transfer = is happening. For servers that don't do a snapshot, then I think an ETAG = should be mandatory. Current draft seems to say the client MUST check it = but it only has an SHOULD on the server sending it.=20 More complicated is the PUT / POST. On these, I think they should be = required to be atomic. Designing systems with clients that can deal with = non atomic requests is very hard. I understand this has consequences on = servers but not saying that has consequences on clients and overall = system stability. A node may be willing to have some resource in an = inconsistent state, but another node that does a GET of that resource = may not be able to deal with the inconsistent state. Again with PUT/ = POST, need some sort of overall timeout where the server can discard the = state if the client dies.=20 I think the client should explicitly signal support for blocks to the = sever before the server starts using this extension.=20 I think we need a provisional response code that indicates the far end = is simply buffering. Using 2.04 until the block m=3D0 seems like lots of = things could go wrong in a bad way.=20 Can you use non confirmed requests when doing block? The way 4.08 works, = this is going to be pretty dicey. I'm a bit confused around if the 4.08 = is a missing fragment error or a timeout error. Needs some clarification = and perhaps two codes.=20 Imagine a large download such as an XML or JSON config for a device or = the firmware example. Should there be any advice on trickling or slowing = down large transfers? If 20 devices on a small 802.15.4 mesh network = with only one link the rest of the internet started doing a firmware = download at the same time, I suspect that it badly impact the other = traffic on this network.=20 On the size of the blocks ... given MTU are raising and make a huge = difference to high performance networks, I'd prefer to see support for = 8K or 16K block size as well as the smaller ones. I'm also sympathetic = to the power of 2 are not optimal given we can pick any number we want. = It might be a good idea to pick some sizes that seemed optimal for MTU = we would get on 802.15.4 network, some of the cellular data networks, an = 1280 MTU network, and something in the Jumbo gram space. I also get the = point this looks like over optimization, I'm on the fence :-)=20 Need an example where we have block transfer in request and responses. = Like it if it showed ETags and Tokens too.=20 In mention you use C pseudo code, I'd just remove that part as it can = bring up old arguments from other WG and your mathematical formulas are = perfectly clear without mentioning C.=20 You say the block options are optional to implement but that's not the = right way to think about it. The draft is an extensions to CoAP and it's = optional if you decide to implement the RFC this becomes or not, but if = you implement this RFC, then you MUST implement these so they are not = optional in the context of this draft.=20 The three bullet points paragraphs at the end of section 2.1 are very = hard to understand.=20 When you say that future requests have to have the same block size as = the earlier one, who is responsible for enforcing this. Does the server = need to remember and reject or is it the responsibility of the client to = do the right thing. I don't like the "m" nomenclature - I know where it comes from but it = seems meaningless. I'd prefer a LastBlock field or something like that. In the HTTP mapping section, I'd delete the stuff about problems of = implementing HTTP (and the HTTP to CoAP mapping) on a constrained node. = I don't think our goal is to make HTTP work on the constrained node.=20 In section 5.1, the advice to not create state seems sort of useless. = I'd rather see the draft get clear about where implementations SHOULD = create state and where they don't need to and more importantly, how to = clean up and timeout any state that does get created.=20 Cullen (in my individual contributor role) From fluffy@cisco.com Mon May 9 12:28:31 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73216E0842 for ; Mon, 9 May 2011 12:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.558 X-Spam-Level: X-Spam-Status: No, score=-110.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eG9koF68lxnC for ; Mon, 9 May 2011 12:28:30 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id E592DE0839 for ; Mon, 9 May 2011 12:28:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=2952; q=dns/txt; s=iport; t=1304969310; x=1306178910; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=hKIOciVnd36NIlvpE7AYVJpBrCX4YbAhGNPZD7LWD1c=; b=WpDmge6jRz+V3dLwH9OgvYIquTdpDrRR9F4kZNIQHftW/qrQgZ420kPT IDa7tRUDyp2tlRqal7eg1TvBxH05mzLlKp75pWtZkjrx+/Vd3OcRkW6dx 27Q3Lq3TY64DYkuxcTrkS5VnI//1ZBAbH+T89+/Lg8BHHKOitkXiPyoCI o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALY/yE2rRDoI/2dsb2JhbACmAXeIcZ9qniGGDASGQIkljn0 X-IronPort-AV: E=Sophos;i="4.64,342,1301875200"; d="scan'208";a="444444360" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-1.cisco.com with ESMTP; 09 May 2011 19:28:30 +0000 Received: from dhcp-171-68-21-134.cisco.com (dhcp-171-68-21-134.cisco.com [171.68.21.134]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p49JRf0d026980; Mon, 9 May 2011 19:28:30 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <5756DA0A-5F11-4E70-BD8A-C521495E9665@tzi.org> Date: Mon, 9 May 2011 12:28:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5756DA0A-5F11-4E70-BD8A-C521495E9665@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.1084) Cc: core WG Subject: Re: [core] draft-ietf-core-coap-06 Congestion Control X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 19:28:31 -0000 On May 5, 2011, at 12:38 , Carsten Bormann wrote: >> It's not clear to me that the drafts is a stop and wait congestion = control. I can't see what stops parallel transaction to the same = destination. Related to this, when doing non confirmable transaction, it = does not seem clear how the congestion control works. Given the schema = is stop and wait, I expect that this means one a request has been sent, = a parallel request can not be initiated until a responses is received = but I don't see text to that effect.=20 >=20 > I think this is related to being able to open multiple TCP connections = at the same time. >=20 > RFC2616 had a "SHOULD" limit of up to two simultaneous TCP connections = to the same server from one client. This has become unpopular. >=20 > draft-ietf-httpbis-p1-messaging-14.txt says this (and has been saying = it for a while): >=20 > Clients (including proxies) SHOULD limit the number of simultaneous > connections that they maintain to a given server (including = proxies). >=20 > Previous revisions of HTTP gave a specific number of connections as = a > ceiling, but this was found to be impractical for many applications. > As a result, this specification does not mandate a particular = maximum > number of connections, but instead encourages clients to be > conservative when opening multiple connections. >=20 > I would expect us to come up with similar text, but not limiting = connections, but simultaneously outstanding interactions, where these = are either CON/ACK interactions (message layer) or NON-based = request/response interactions. Makes sense - That text need to be in in this draft, not somewhere else, = or else this draft does not have a congestion control story. For it to = be stop and wait, I'm sort of assuming the limit will be 1.=20 > Section 3.2 of draft-eggert-core-congestion-control-01.txt suggests a = possible direction for developing an algorithm that might be used, but = as with TCP, I'd rather keep the algorithm separate from the protocol. >=20 > The remaining issue is how to congestion-control responses that are = not 1:1 with requests, e.g. NON responses with mechanisms such as = observe and responses to multicast requests. >=20 >> The draft also needs some sort of request timeout definition. Should = address things like if A has an outstanding request to B, and A receives = separate request from B, what happens. We don't want any glare problems. >=20 > I'm not sure I understand that part. Yes, the cc state for NON-based = request/response interactions has to time out (the one for CON/ACK does = so automatically), say, at 4*MSL. And, yes, if I send 20 NON requests, = one each hour, the server might send all 20 responses at midnight at = once. This temporal decoupling is a variation of the non-1:1 aspect = above and could be solved the same way. >=20 > Gruesse, Carsten >=20 From fluffy@cisco.com Mon May 9 12:29:02 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFC25E0839 for ; Mon, 9 May 2011 12:29:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.559 X-Spam-Level: X-Spam-Status: No, score=-110.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RK8j3ZLxlPAB for ; Mon, 9 May 2011 12:29:02 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 37D55E082F for ; Mon, 9 May 2011 12:29:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=217; q=dns/txt; s=iport; t=1304969342; x=1306178942; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=idDhYuG0tgcPphoxUWsfcOgGcsnLY6z834H3cUyET7g=; b=WNFWr0xowNRtj2E1kge6wK/l7lPlmUvNr6WNxtyBsGX/a1oXzNr3/i8C Hv5ebNqKUerIGTx7pkp3heuj1xsO/feJgaHzCqNzgui5FceSBjcb7qvy5 lyks9M0A0kp/YhYv0kQsmkOImm29aG7tzr9sHNxTS/XM43rivycPQH9N8 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFJAyE2rRDoI/2dsb2JhbACmAXenNoEdniGGDASGQIkljn0 X-IronPort-AV: E=Sophos;i="4.64,342,1301875200"; d="scan'208";a="353427017" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 09 May 2011 19:28:37 +0000 Received: from dhcp-171-68-21-134.cisco.com (dhcp-171-68-21-134.cisco.com [171.68.21.134]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p49JRf0e026980 for ; Mon, 9 May 2011 19:28:37 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 9 May 2011 12:28:40 -0700 Message-Id: <76503846-BE4E-435B-A7B2-9AA679D17B11@cisco.com> To: core WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [core] draft-ietf-core-coap-06 Request Timeout X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 19:29:03 -0000 If a client sends a request such as a GET, what is the default timeout = after which it should consider there was an error if it has not received = a response? Cullen From fluffy@cisco.com Mon May 9 12:29:19 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6CAE0839 for ; Mon, 9 May 2011 12:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.56 X-Spam-Level: X-Spam-Status: No, score=-110.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PikZs6JEjlXl for ; Mon, 9 May 2011 12:29:14 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 0FADAE082F for ; Mon, 9 May 2011 12:29:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=4935; q=dns/txt; s=iport; t=1304969353; x=1306178953; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=j2FzRv/wiHvBEIuYMQaRK97QVggVVfSSvLC7Zjl6jrA=; b=RZ0BvfORkg1auG/bCbmvFhwiM6Y3HsV1kY4XQTRSOElfhCE+eXXDky/O b3umAkPeeiTJjNRQr/+VP+wVR60L6GWv3Ug3XGdM+iA6Mh1vtJYt91kFJ 8efgLHZ5fzsRKPCfB1qrberCp7ZhrwAKIOrZ/Imy6F88au9gDtWpekVa8 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFJAyE2rRDoI/2dsb2JhbACmAXeIcZ9iniGGDASGQIkljn0 X-IronPort-AV: E=Sophos;i="4.64,342,1301875200"; d="scan'208";a="353427341" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 09 May 2011 19:29:13 +0000 Received: from dhcp-171-68-21-134.cisco.com (dhcp-171-68-21-134.cisco.com [171.68.21.134]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p49JRf0f026980; Mon, 9 May 2011 19:29:13 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <09b901cc0cf6$35877660$a0966320$@yegin@yegin.org> Date: Mon, 9 May 2011 12:29:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <223489D8-F2DC-45D1-A690-13480534C1B2@cisco.com> References: <239072CD-ACC0-454D-8BD6-30AC28D425D9@cisco.com> <059f01cc0b35$a785fc90$f691f5b0$@yegin@yegin.org> <720981EA-6411-4A5C-AC8C-675ADA1A2DE5@cisco.com> <07a401cc0bd8$34e5ab10$9eb10130$@yegin@yegin.org> <8BCD950E-FB93-40EE-848C-466E5152DA7C@cisco.com> <09b901cc0cf6$35877660$a0966320$@yegin@yegin.org> To: Alper Yegin X-Mailer: Apple Mail (2.1084) Cc: 'core WG' Subject: Re: [core] draft-ietf-core-coap-06 Security X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 19:29:19 -0000 inline ... On May 7, 2011, at 13:34 , Alper Yegin wrote: > Cullen, >=20 >> On May 6, 2011, at 3:27 , Alper Yegin wrote: >>=20 >>>> In the Certificate mode, I do not see how we are covered from on >> path >>>> attackers - but I could easily be missing some critical part of the >>>> draft - I just don't see how the security works yet. For example = if >> A >>>> wants to send a message to B and E is an on path attacker. E can >> MITM >>>> the DTLS and do whatever they want to the messaging. People keep >>>> telling me that solving that problem is out of scope for CoAP. Just >>>> about all the other IETF protocols I have worked on consider that >>>> problem in scope. I have a hard time imagining this draft getting >> past >>>> IESG with that out of scope. >>>=20 >>> Performing mutual TLS authentication leaves no room for a MitM. I >> don't >>> quite understand the threat you are mentioning. >>=20 >> So say A has a certificate with device identifier cert-a in SAN of = the >> cert, E has one with cert-e, and B has one with cert-b. After the >> attack, A thinks they are talking to someone with a cert-e. Most = other >> IETF protocols have a normative way to make sure that when an >> application is trying to form a TLS connection to B, you don't end up >> accepting an certificate that has cert-e in it. CoAP does not have >> something like that in it. You suggest an ACL solution to this which = is >> fine, but my point is that to have a security story of how the CoAP >> protocol protects from given attacks, we need this defined somewhere. = I >> do not think the IETF is likely to approve CoAP approved without a >> normative reference to a document that deal with these sort of = issues. >=20 > There needs to be a binding between the CoAP and DTLS. Whatever = identifier > is used at CoAP layer has to match the identifier that got = authenticated at > the DTLS layer. Otherwise, yes, what you are describing can happen.=20 >=20 >> If the direction the WG wanted to take to solve this was there was an >> ACL list that said when trying to talk to B, expect a cert that says >> cert-b, and we had a secure way to distribute that ACL, then we then = we >> could probably solve all of this without using asymmetric crypto. >=20 > I'm not sure the symmetric vs. asymmetric crypto is a factor here. I = think > the issue is, the end-point authentication is happening at a layer = other > than the one using the associated identifiers. There needs to be a = binding > between the two. >=20 100% agree - in my mind this is probably the largest remaining issues in = the draft >=20 >> I agree security design has both protocol and system implications. = The >> overall way I am looking at the solution, is that if two different >> vendors read the CoAP spec and build devices from it, we should be = able >> to deploy theses devices in some of a bunch (if not all) our use case >> we have the the WG and have them work together. I realize that some >> other SDOs separate the security much more into the systems design = but >> the IETF found that when they did that the protocols ended up with no >> security and has pushed the security design into the protocols more >> than some other SDOs. >>=20 >> The most important part of this email is when using TLS, the = integrity >> and authentication part of it are sort of useless to on path attacks >> unless you also have the authentication part of it.=20 >=20 > TLS provides end-point authentication, followed by creating a secure > transport that provides integrity and replay protection, data origin > authentication, and privacy for the data. >=20 >=20 >> Other IETF >> protocols define how to do the authentication part of it - I believe = we >> will also need to say how to make the authentication part of TLS work >> in CoAP. >=20 > By the way, I wonder why this WG chose to use TLS. Why not define a > CoAP-layer security extension. We can do something similar to what was = done > for Mobile IPv4, another UDP-based protocol. Define an option that = carries a > keyed hash of the CoAP header + payloads. And you get data origin = auth, > integrity and replay protection. And define another option to encrypt = the > ones that require privacy. (encryption part not in Mobile IPv4).=20 well some protocols have a strong need for the integrity to cover a = different part of the packet than the encryption. Mobile IP and SRTP = seem to be examples of that. However, CoAP seems like you can encrypt = the whole CoAP packet because there is not an need for some = intermediaries to be able to read some of the packet but not others = parts >=20 > Alper >=20 >=20 >=20 >=20 > Alper >=20 >=20 >=20 >=20 Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From cabo@tzi.org Mon May 9 12:30:21 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A47BBE069C for ; Mon, 9 May 2011 12:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.222 X-Spam-Level: X-Spam-Status: No, score=-106.222 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V5TRkHnhjp0P for ; Mon, 9 May 2011 12:30:20 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 044E8E065A for ; Mon, 9 May 2011 12:30:18 -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 p49JU73b028370; Mon, 9 May 2011 21:30:07 +0200 (CEST) Received: from [192.168.217.101] (p5B3E6433.dip.t-dialin.net [91.62.100.51]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 5EDD3160; Mon, 9 May 2011 21:30:06 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Mon, 9 May 2011 21:30:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7ED3C4B5-1A48-4DFA-A765-D3C2CD0ADE16@tzi.org> References: <053.23fd175ad3e8fb1a4a7303089729c32f@trac.tools.ietf.org> To: Cullen Jennings X-Mailer: Apple Mail (2.1084) Cc: core@ietf.org, trac+core@zinfandel.tools.ietf.org, hartke@tzi.org Subject: Re: [core] #132: Separate response implicitly acks confirmable request X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 19:30:21 -0000 On May 9, 2011, at 18:14, Cullen Jennings wrote: >=20 > Do you MAY stop or SHOULD stop or MUST stop ? MAY. 4.1 now ends with: Implementation notes: Note that a CoAP end-point that sent a confirmable message MAY give up in attempting to obtain an ACK even before the MAX_RETRANSMIT counter value is reached: E.g., the application has canceled the request as it no longer needs a response, or there is some other indication that the CON message did arrive. In particular, a CoAP request message may have elicited a separate response, in which case it is clear to the requester that only the ACK was lost and a retransmission of the request would serve no purpose. However, a responder MUST NOT in turn rely on this cross-layer behavior from a requester, i.e. it SHOULD retain the state to create the ACK for the request, if needed, even if a confirmable response was already acknowledged by the requester. Do you think there is a reason for SHOULD/MUST? I think that would create too much imposition on the implementation for = little gain. Gruesse, Carsten From fluffy@cisco.com Mon May 9 12:31:57 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA261E0847 for ; Mon, 9 May 2011 12:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.56 X-Spam-Level: X-Spam-Status: No, score=-110.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-COoGtRffxA for ; Mon, 9 May 2011 12:31:56 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 75A49E0839 for ; Mon, 9 May 2011 12:31:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1490; q=dns/txt; s=iport; t=1304969516; x=1306179116; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=uR8AF0NJbF1zshUh+PhvnilHr6qMpvIfedNyEjvKu1g=; b=Z4Y/wnjemBr/kMOZeavBy8l7uHG52OlEcXHLNmScsVB+uoAYiGhH+z4T aGic00IzEYoQOREZMmUGrnGQmdPf62E20daDBqvNRPLtchFoqYSRUe29K NZgsvvEtO9uyVk26G4w4w0SYhvhP2MvoF9h6Go/Yn1BR4e99W6uG8x4T4 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFJAyE2rRDoG/2dsb2JhbACmAXeIcZ9iniGGDASGQIkljn0 X-IronPort-AV: E=Sophos;i="4.64,342,1301875200"; d="scan'208";a="353429406" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-2.cisco.com with ESMTP; 09 May 2011 19:31:55 +0000 Received: from dhcp-171-68-21-134.cisco.com (dhcp-171-68-21-134.cisco.com [171.68.21.134]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p49JVtLb016724; Mon, 9 May 2011 19:31:55 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <7ED3C4B5-1A48-4DFA-A765-D3C2CD0ADE16@tzi.org> Date: Mon, 9 May 2011 12:31:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <053.23fd175ad3e8fb1a4a7303089729c32f@trac.tools.ietf.org> <7ED3C4B5-1A48-4DFA-A765-D3C2CD0ADE16@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.1084) Cc: core@ietf.org, trac+core@zinfandel.tools.ietf.org, hartke@tzi.org Subject: Re: [core] #132: Separate response implicitly acks confirmable request X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 19:31:57 -0000 That looks fine to me. Key thing I was worried about was that devices = don't rely on this cross layer behavior.=20 On May 9, 2011, at 12:30 , Carsten Bormann wrote: > On May 9, 2011, at 18:14, Cullen Jennings wrote: >=20 >>=20 >> Do you MAY stop or SHOULD stop or MUST stop ? >=20 > MAY. >=20 > 4.1 now ends with: >=20 > Implementation notes: Note that a CoAP end-point that sent a > confirmable message MAY give up in attempting to obtain an ACK even > before the MAX_RETRANSMIT counter value is reached: E.g., the > application has canceled the request as it no longer needs a > response, or there is some other indication that the CON message did > arrive. In particular, a CoAP request message may have elicited a > separate response, in which case it is clear to the requester that > only the ACK was lost and a retransmission of the request would = serve > no purpose. However, a responder MUST NOT in turn rely on this > cross-layer behavior from a requester, i.e. it SHOULD retain the > state to create the ACK for the request, if needed, even if a > confirmable response was already acknowledged by the requester. >=20 > Do you think there is a reason for SHOULD/MUST? > I think that would create too much imposition on the implementation = for little gain. >=20 > Gruesse, Carsten >=20 Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From zach@sensinode.com Mon May 9 13:47:59 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC61E0817 for ; Mon, 9 May 2011 13:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id phThozalh0lx for ; Mon, 9 May 2011 13:47:58 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 5D464E0957 for ; Mon, 9 May 2011 13:47:56 -0700 (PDT) Received: from 87-95-202-0.bb.dnainternet.fi (87-95-202-0.bb.dnainternet.fi [87.95.202.0]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id p49KCVu4023318 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 9 May 2011 23:12:33 +0300 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-71-247239806; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: <1DA0334E-AD93-4494-A34D-B817A16A60DD@cisco.com> Date: Mon, 9 May 2011 23:12:34 +0300 Message-Id: <32FC5740-FDE6-4C3B-AB12-78202FF330CE@sensinode.com> References: <770C6CBC-E55E-41B2-BA92-1B161C8282A7@cisco.com> <1DA0334E-AD93-4494-A34D-B817A16A60DD@cisco.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1084) Cc: core WG Subject: Re: [core] draft-ietf-core-coap-06 IF-Match Option X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 20:47:59 -0000 --Apple-Mail-71-247239806 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 7, 2011, at 6:35 PM, Cullen Jennings wrote: > I read the text you have in the misc draft on if-match and thought it = looked just right. As an individual contributor, I would suggest we take = this text and move it to CoAP. I don't see a compelling reasons to add = the If-None-Match. +1 Zach >=20 > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html >=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-71-247239806 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 ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDUwOTIwMTIz NFowIwYJKoZIhvcNAQkEMRYEFEiOc4Y3CW9C4cQwtuRbcwGwSMD/MIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAJ+LxgRc/w/5E8gxq2SnVizQAvmOp0nGwcAQHWbzbgKbARBO6+vJjNH+ KdQaorZAyGKzNU6Q012NZqABRu6wCDMNQckJUjN6GZvjpjynhBd0EJkphYvvhSCdVPwH/pRHuP5G C3rDklpw2LWYlHR48DlC311a9wkoMo3zNnBSOIWjkwARa5Y+NJlA+w4UgGATA2n8n1PMWgf497yB 1QHfebt3zJSn/1tQPQAIkrMywuGbHHl3zS8fGuRdg5aPHHd45dLigPrzUxHQWrc3HfwgWyPHCkf5 uHGZBHGiAYQ7aMnpbPSMPxw6x8iYRbQBowkLNHGLAt4Y/g+A32194qWFQ5EAAAAAAAA= --Apple-Mail-71-247239806-- From cabo@tzi.org Mon May 9 14:21:11 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4F3E06F3 for ; Mon, 9 May 2011 14:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.223 X-Spam-Level: X-Spam-Status: No, score=-106.223 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2CYfisyPb4i for ; Mon, 9 May 2011 14:21:10 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 00443E06CF for ; Mon, 9 May 2011 14:21:09 -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 p49K7Nk4006821; Mon, 9 May 2011 22:07:23 +0200 (CEST) Received: from [192.168.217.101] (p5B3E6433.dip.t-dialin.net [91.62.100.51]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 964FC176; Mon, 9 May 2011 22:07:22 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <65C046E2-65E4-4C20-B1AB-CBE12C9B8164@cisco.com> Date: Mon, 9 May 2011 22:07:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <65C046E2-65E4-4C20-B1AB-CBE12C9B8164@cisco.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1084) Cc: core WG Subject: Re: [core] draft-ietf-core-block-03 review X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 21:21:11 -0000 > What happens if the resource changes part way through a GET? For = devices that make a virtual snapshot of the resource, I'd like the it so = that if the resources changes while the transfer is happing, the value = the client receives is the value of resources when the server received = the first get. There need to be some sort of minimum timeout so that the = client knows the server will not discard the snapshot while the transfer = is happening. For servers that don't do a snapshot, then I think an ETAG = should be mandatory. Current draft seems to say the client MUST check it = but it only has an SHOULD on the server sending it.=20 The philosophy behind CoAP is to leave many decisions up to the server. E.g., whether a frozen copy is made when a block-wise transfer starts or = the server simply operates in a stateless fashion. Yes, you can implement a server that makes it really hard to get a = resource representation. We can try to create a jungle of MUSTs and SHOULDs here, which in the = end will do the wrong things for some specific situation. Leave that up to the server, I'd say. > More complicated is the PUT / POST. On these, I think they should be = required to be atomic. Designing systems with clients that can deal with = non atomic requests is very hard. I understand this has consequences on = servers but not saying that has consequences on clients and overall = system stability. A node may be willing to have some resource in an = inconsistent state, but another node that does a GET of that resource = may not be able to deal with the inconsistent state. Again with PUT/ = POST, need some sort of overall timeout where the server can discard the = state if the client dies.=20 That depends, again. A server that provides a REST protocol that creates a specific instance = for each client to PUT into does not need to do any of this. I have no idea how to come up with a reasonable value for such a = timeout. Different applications will need quite different values. Leave all that up to the server, I'd say. > I think the client should explicitly signal support for blocks to the = sever before the server starts using this extension.=20 (See last message.) > I think we need a provisional response code that indicates the far end = is simply buffering. Using 2.04 until the block m=3D0 seems like lots of = things could go wrong in a bad way.=20 The echoed m bit in the Block1 option is that provisional code. (Yes, that could be re-enforced with a different response code as well, = but that we'd lose the distinction between 2.01 and 2.04.) > Can you use non confirmed requests when doing block? The way 4.08 = works, this is going to be pretty dicey. I'm a bit confused around if = the 4.08 is a missing fragment error or a timeout error. Needs some = clarification and perhaps two codes.=20 We need a ton more examples. 4.08 is a missing fragment error. A timeout simply isn't signalled = (where would you signal it) and then leads to a missing fragment error. = So, in the end, 4.08 also is a timeout error. > Imagine a large download such as an XML or JSON config for a device or = the firmware example. Should there be any advice on trickling or slowing = down large transfers? If 20 devices on a small 802.15.4 mesh network = with only one link the rest of the internet started doing a firmware = download at the same time, I suspect that it badly impact the other = traffic on this network.=20 That's handled by the lock-step congestion control. > On the size of the blocks ... given MTU are raising and make a huge = difference to high performance networks, I'd prefer to see support for = 8K or 16K block size as well as the smaller ones. I'm also sympathetic = to the power of 2 are not optimal given we can pick any number we want. = It might be a good idea to pick some sizes that seemed optimal for MTU = we would get on 802.15.4 network, some of the cellular data networks, an = 1280 MTU network, and something in the Jumbo gram space. I also get the = point this looks like over optimization, I'm on the fence :-)=20 We just killed 2048, and I think that was the right decision = (high-performance networks are out of scope). I tried to define a size that would be optimal, but there are so many = variables in header compression efficiency, security overhead etc., that = this doesn't work too well (well, actually 64 is pretty good in most = cases -- anything beyond that is premature optimization). > Need an example where we have block transfer in request and responses. = Like it if it showed ETags and Tokens too.=20 Yes, we need a ton more examples! This one was already requested by Guido, and we definitely need to put = it in. > In mention you use C pseudo code, I'd just remove that part as it can = bring up old arguments from other WG and your mathematical formulas are = perfectly clear without mentioning C.=20 Without that sentence, the formulae are not well-defined. (Let's fight that windmill when we encounter it :-) > You say the block options are optional to implement but that's not the = right way to think about it. The draft is an extensions to CoAP and it's = optional if you decide to implement the RFC this becomes or not, but if = you implement this RFC, then you MUST implement these so they are not = optional in the context of this draft.=20 I hate the word optional, because it never means anything useful. But, now, a node might implement Block2 and not Block1, so some text to = this effect is actually required. > The three bullet points paragraphs at the end of section 2.1 are very = hard to understand.=20 Yes, they need a serious editorial round. > When you say that future requests have to have the same block size as = the earlier one, who is responsible for enforcing this. Does the server = need to remember and reject or is it the responsibility of the client to = do the right thing. This is a mandate to make some potential server implementations simpler, = not to complicate them. Note that there are no error codes defined... (I would be prepared to completely delete that mandate, by the way.) > I don't like the "m" nomenclature - I know where it comes from but it = seems meaningless. I'd prefer a LastBlock field or something like that. Well, it would be NotLastBlock (otherwise we would change the wire = protocol). Is that better than "m"? > In the HTTP mapping section, I'd delete the stuff about problems of = implementing HTTP (and the HTTP to CoAP mapping) on a constrained node. = I don't think our goal is to make HTTP work on the constrained node.=20 Well, the whole section is implementation advice, and it is not about = implementing HTTP, but about what a mapper might need to do to do Block. But, apart from this advice, it helps in understanding why the protocol = is defined as it is. Deleting the text would go some way towards the typical trapdoor = standard (i.e., we'll tell you how it works if you already understand = that). > In section 5.1, the advice to not create state seems sort of useless. = I'd rather see the draft get clear about where implementations SHOULD = create state and where they don't need to and more importantly, how to = clean up and timeout any state that does get created.=20 If you want to counter resource exhaustion, not creating state is the = best defense there is -- yes, that's trivial, but it is still good = advice. Apart from that, leave that up to the server, I'd say. Gruesse, Carsten From cabo@tzi.org Mon May 9 14:21:12 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB04E06F3 for ; Mon, 9 May 2011 14:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.224 X-Spam-Level: X-Spam-Status: No, score=-106.224 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bpNkMI9c2e-g for ; Mon, 9 May 2011 14:21:12 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 96384E06CF for ; Mon, 9 May 2011 14:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id p49JYs0Y029492; Mon, 9 May 2011 21:34:54 +0200 (CEST) Received: from [192.168.217.101] (p5B3E6433.dip.t-dialin.net [91.62.100.51]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 2B799163; Mon, 9 May 2011 21:34:54 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <76503846-BE4E-435B-A7B2-9AA679D17B11@cisco.com> Date: Mon, 9 May 2011 21:34:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <76503846-BE4E-435B-A7B2-9AA679D17B11@cisco.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1084) Cc: core WG Subject: Re: [core] draft-ietf-core-coap-06 Request Timeout X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 21:21:12 -0000 On May 9, 2011, at 21:28, Cullen Jennings wrote: >=20 > If a client sends a request such as a GET, what is the default timeout = after which it should consider there was an error if it has not received = a response? The same answer as for HTTP. (There is no such defined value.) Assuming that there were such a default value: What should a server do when it is getting close to that value and still = does not have an answer? Since there is no good answer to that, I don't think there is a good = reason to have such a default value. Gruesse, Carsten From cabo@tzi.org Mon May 9 14:21:14 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D950E0908 for ; Mon, 9 May 2011 14:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.225 X-Spam-Level: X-Spam-Status: No, score=-106.225 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5cnVbpysbJGF for ; Mon, 9 May 2011 14:21:13 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 0C703E087A for ; Mon, 9 May 2011 14:21: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 p49JeG5s001231; Mon, 9 May 2011 21:40:16 +0200 (CEST) Received: from [192.168.217.101] (p5B3E6433.dip.t-dialin.net [91.62.100.51]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 7233C166; Mon, 9 May 2011 21:40:16 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <65C046E2-65E4-4C20-B1AB-CBE12C9B8164@cisco.com> Date: Mon, 9 May 2011 21:40:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <65C046E2-65E4-4C20-B1AB-CBE12C9B8164@cisco.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1084) Cc: core WG Subject: Re: [core] draft-ietf-core-block-03 review X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 21:21:14 -0000 On May 9, 2011, at 21:27, Cullen Jennings wrote: > I think the client should explicitly signal support for blocks to the = sever before the server starts using this extension.=20 We had that discussion a couple of times. I find it interesting that = this specific case runs counter to the intuition of most experienced = protocol designers (it sure did when I thought this through the first = time). What would a server do if there is no such signal and it needs to split? Send an error. As defined now, it sends a critical option not implemented by the = client, which is an error. (Yes, there is also a payload sent that would be saved by having a = special kind of error. Trying to get rid of that payload is a typical = case of premature optimization.) So what's the point? Since most clients will implement Block, most clients will always send = this signal, for zero gain. Really bad design. Gruesse, Carsten From likepeng@huawei.com Mon May 9 18:17:37 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA63E07F2 for ; Mon, 9 May 2011 18:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.285 X-Spam-Level: X-Spam-Status: No, score=-4.285 tagged_above=-999 required=5 tests=[AWL=2.314, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XIa9kLpa+D4v for ; Mon, 9 May 2011 18:17:36 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 31BCBE0681 for ; Mon, 9 May 2011 18:17:36 -0700 (PDT) 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 <0LKY00535GXAKX@szxga04-in.huawei.com> for core@ietf.org; Tue, 10 May 2011 09:17:35 +0800 (CST) Received: from szxeml203-edg.china.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 <0LKY00EU2GX9YH@szxga04-in.huawei.com> for core@ietf.org; Tue, 10 May 2011 09:17:34 +0800 (CST) Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 10 May 2011 09:17:32 +0800 Received: from SZXEML506-MBS.china.huawei.com ([169.254.3.27]) by SZXEML401-HUB.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0270.001; Tue, 10 May 2011 09:17:34 +0800 Date: Tue, 10 May 2011 01:17:32 +0000 From: Likepeng In-reply-to: X-Originating-IP: [10.70.109.110] To: Carsten Bormann , Cullen Jennings Message-id: <34966E97BE8AD64EAE9D3D6E4DEE36F228783B@SZXEML506-MBS.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [core] draft-ietf-core-coap-06 Request Timeout Thread-index: AQHMDn9t/oSsCAWo/0WQe+ocxEOsBZSEXTuAgADb1fA= X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <76503846-BE4E-435B-A7B2-9AA679D17B11@cisco.com> Cc: core WG Subject: Re: [core] draft-ietf-core-coap-06 Request Timeout X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 01:17:37 -0000 I have a draft to let the client to define a timeout in the request: http://tools.ietf.org/id/draft-li-core-coap-response-mode-option-00.txt I think it is better than the default value. I notice that in Hybi group, there is a similar proposal for HTTP: http://www.ietf.org/id/draft-thomson-hybi-http-timeout-00.txt I would like to get feedback from you on the draft. Thanks, Kind Regards Kepeng -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Carsten Bormann Sent: Tuesday, May 10, 2011 3:35 AM To: Cullen Jennings Cc: core WG Subject: Re: [core] draft-ietf-core-coap-06 Request Timeout On May 9, 2011, at 21:28, Cullen Jennings wrote: > > If a client sends a request such as a GET, what is the default timeout after which it should consider there was an error if it has not received a response? The same answer as for HTTP. (There is no such defined value.) Assuming that there were such a default value: What should a server do when it is getting close to that value and still does not have an answer? Since there is no good answer to that, I don't think there is a good reason to have such a default value. Gruesse, Carsten _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From fluffy@cisco.com Mon May 9 18:24:39 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FCA1E09A0 for ; Mon, 9 May 2011 18:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.561 X-Spam-Level: X-Spam-Status: No, score=-110.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tKeThKjhDLYK for ; Mon, 9 May 2011 18:24:38 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7039DE0931 for ; Mon, 9 May 2011 18:24:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=2278; q=dns/txt; s=iport; t=1304990678; x=1306200278; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=1WPEeG5i66MxTkmrmEhcMAs3zye/RzvxZP4bNUDYWLk=; b=ApAsWsKJ+x8g1nispEOeAotErUJrfnrnhTOJhCOtZiyaLDKYaJsW2N7W Xm2IBahkoA0hc/RkmoWQG+s2VnlPbaiJ6ECG6rUyqPHFO41Qna9JTS0oZ 9QwV3sOae27HQF1W5vXgTOA7cTMOwuxfMpcyKZpZF5wj1m/QDZ8vRirsE M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOCSyE2rRDoI/2dsb2JhbACmAneIcZ5DnjCGDASGQIkkjn4 X-IronPort-AV: E=Sophos;i="4.64,343,1301875200"; d="scan'208";a="311973484" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-3.cisco.com with ESMTP; 10 May 2011 01:24:37 +0000 Received: from dhcp-171-68-21-134.cisco.com (dhcp-171-68-21-134.cisco.com [171.68.21.134]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p4A1Ob2X008131; Tue, 10 May 2011 01:24:37 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Mon, 9 May 2011 18:24:40 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <97FFAAA8-393C-4AC9-9C6C-5520273B59A0@cisco.com> References: <65C046E2-65E4-4C20-B1AB-CBE12C9B8164@cisco.com> To: Carsten Bormann X-Mailer: Apple Mail (2.1084) Cc: core WG Subject: Re: [core] draft-ietf-core-block-03 review X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 01:24:39 -0000 lets think about the case with IP level fragmentation a bit. Let's say = the client has a MTU of 1280 and the server has a MTU of 128. The = client requests a resources which is 300 bytes long. I doubt the server = sends an error - I suspect it tries to send the the result as a single = response that gets fragmented at the IP layer. Having the GET come along = with with an indication that the client supports block and would prefer = less than 1250 or so then having the server send the result in three = responses that are have an size under the 128 MTU seems like an OK = design. A design like with would also avoid the latency of a full round = trip when the client supports block and the server does not.=20 I also question the assumption that most servers would implement block = - it's true that the current design more or less forces them to = implement it or the clients get a constant flow of errors. I suspect = that the reason a server would not want to implement block would have to = do with the buffering that the implementation will probably require.=20 On May 9, 2011, at 12:40 , Carsten Bormann wrote: > On May 9, 2011, at 21:27, Cullen Jennings wrote: >=20 > > I think the client should explicitly signal support for blocks to = the sever before the server starts using this extension. >=20 > We had that discussion a couple of times. I find it interesting that = this specific case runs counter to the intuition of most experienced = protocol designers (it sure did when I thought this through the first = time). >=20 > What would a server do if there is no such signal and it needs to = split? > Send an error. > As defined now, it sends a critical option not implemented by the = client, which is an error. > (Yes, there is also a payload sent that would be saved by having a = special kind of error. Trying to get rid of that payload is a typical = case of premature optimization.) >=20 > So what's the point? > Since most clients will implement Block, most clients will always send = this signal, for zero gain. > Really bad design. >=20 > Gruesse, Carsten >=20 >=20 Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From fluffy@cisco.com Mon May 9 18:25:03 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3108EE09AA for ; Mon, 9 May 2011 18:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.562 X-Spam-Level: X-Spam-Status: No, score=-110.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UhN9zd+aWbQW for ; Mon, 9 May 2011 18:25:01 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id E78A2E09A8 for ; Mon, 9 May 2011 18:24:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=9492; q=dns/txt; s=iport; t=1304990684; x=1306200284; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=lroOxPdO9fgZfJAGso1bsR9FjJJvHULqtc0uL8/SipM=; b=nH3M11cAaY83zD/nafAp1/xDMgrcHOq6Zm3HV1kaamAb27VrOJvc/gyD zML3/xB2iFzKk46H19ngpxPdzYkjmyuoPZYTz+zVdnozThzB6BP849D5J CVC2THy5a8C58Y3kklEXY+aqcLFXsyzUiYH0HF13IFnsaQJFPZh96B+9v k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOCSyE2rRDoI/2dsb2JhbACmAneIcZ5DnjCGDASGQIkkjn4 X-IronPort-AV: E=Sophos;i="4.64,343,1301875200"; d="scan'208";a="444616922" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-1.cisco.com with ESMTP; 10 May 2011 01:24:44 +0000 Received: from dhcp-171-68-21-134.cisco.com (dhcp-171-68-21-134.cisco.com [171.68.21.134]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p4A1Ob2Y008131; Tue, 10 May 2011 01:24:44 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Mon, 9 May 2011 18:24:46 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <348BAAE6-E026-46F6-B76F-5CF099C42441@cisco.com> References: <65C046E2-65E4-4C20-B1AB-CBE12C9B8164@cisco.com> To: "Carsten Bormann" X-Mailer: Apple Mail (2.1084) Cc: core WG Subject: Re: [core] draft-ietf-core-block-03 review X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 01:25:03 -0000 On May 9, 2011, at 13:07 , Carsten Bormann wrote: > > What happens if the resource changes part way through a GET? For = devices that make a virtual snapshot of the resource, I'd like the it so = that if the resources changes while the transfer is happing, the value = the client receives is the value of resources when the server received = the first get. There need to be some sort of minimum timeout so that the = client knows the server will not discard the snapshot while the transfer = is happening. For servers that don't do a snapshot, then I think an ETAG = should be mandatory. Current draft seems to say the client MUST check it = but it only has an SHOULD on the server sending it. >=20 > The philosophy behind CoAP is to leave many decisions up to the = server. > E.g., whether a frozen copy is made when a block-wise transfer starts = or the server simply operates in a stateless fashion. > Yes, you can implement a server that makes it really hard to get a = resource representation. > We can try to create a jungle of MUSTs and SHOULDs here, which in the = end will do the wrong things for some specific situation. > Leave that up to the server, I'd say. well, the same problem applies of how does the client know if it got a = atomic representation of the state or some broken intermediate = representation. I don't think you can leave this up to the server and = still build systems that function in the way you want the system to = function.=20 >=20 > > More complicated is the PUT / POST. On these, I think they should be = required to be atomic. Designing systems with clients that can deal with = non atomic requests is very hard. I understand this has consequences on = servers but not saying that has consequences on clients and overall = system stability. A node may be willing to have some resource in an = inconsistent state, but another node that does a GET of that resource = may not be able to deal with the inconsistent state. Again with PUT/ = POST, need some sort of overall timeout where the server can discard the = state if the client dies. >=20 > That depends, again. > A server that provides a REST protocol that creates a specific = instance for each client to PUT into does not need to do any of this. Could you expand a bit more on how this solves the problem, I'm not = getting it.=20 > I have no idea how to come up with a reasonable value for such a = timeout. The problem here is that unless that client and server have a = coordinated view of the timeouts, the system is not going to = interoperate. If the client thinks it should wait 30 seconds to time out = a single request that did not get a responses, and the server thinks it = should through away the state of any block buffer after 25 seconds, we = have a problem. (I also am not a fan of situation where the implementor = of a protocol, with even less information than the designers of the = protocol, has to figure out how to do something the designers could not = figure out.) > Different applications will need quite different values. > Leave all that up to the server, I'd say. >=20 > > I think the client should explicitly signal support for blocks to = the sever before the server starts using this extension. >=20 > (See last message.) >=20 > > I think we need a provisional response code that indicates the far = end is simply buffering. Using 2.04 until the block m=3D0 seems like = lots of things could go wrong in a bad way. >=20 > The echoed m bit in the Block1 option is that provisional code. > (Yes, that could be re-enforced with a different response code as = well, but that we'd lose the distinction between 2.01 and 2.04.) hmm - I missed that in my read of the draft. It's an interesting point, = so you are saying the first block could have a 2.01 with a location = returned yet the last block may still result in an error. Probably need = to specify what happens to the location returned validity in that case. = Seems like one more good reason to have PUT be atomic.=20 >=20 > > Can you use non confirmed requests when doing block? The way 4.08 = works, this is going to be pretty dicey. I'm a bit confused around if = the 4.08 is a missing fragment error or a timeout error. Needs some = clarification and perhaps two codes. >=20 > We need a ton more examples. >=20 > 4.08 is a missing fragment error. A timeout simply isn't signalled = (where would you signal it) and then leads to a missing fragment error. = So, in the end, 4.08 also is a timeout error. When using proxies, you often need to signal timeouts so if it is useful = for the client to understand if the error was a timeout or a missing = fragment, it would probably be best to have an explicit error code for = it.=20 >=20 > > Imagine a large download such as an XML or JSON config for a device = or the firmware example. Should there be any advice on trickling or = slowing down large transfers? If 20 devices on a small 802.15.4 mesh = network with only one link the rest of the internet started doing a = firmware download at the same time, I suspect that it badly impact the = other traffic on this network. >=20 > That's handled by the lock-step congestion control. >=20 > > On the size of the blocks ... given MTU are raising and make a huge = difference to high performance networks, I'd prefer to see support for = 8K or 16K block size as well as the smaller ones. I'm also sympathetic = to the power of 2 are not optimal given we can pick any number we want. = It might be a good idea to pick some sizes that seemed optimal for MTU = we would get on 802.15.4 network, some of the cellular data networks, an = 1280 MTU network, and something in the Jumbo gram space. I also get the = point this looks like over optimization, I'm on the fence :-) >=20 > We just killed 2048, and I think that was the right decision = (high-performance networks are out of scope). > I tried to define a size that would be optimal, but there are so many = variables in header compression efficiency, security overhead etc., that = this doesn't work too well (well, actually 64 is pretty good in most = cases -- anything beyond that is premature optimization). >=20 > > Need an example where we have block transfer in request and = responses. Like it if it showed ETags and Tokens too. >=20 > Yes, we need a ton more examples! > This one was already requested by Guido, and we definitely need to put = it in. >=20 > > In mention you use C pseudo code, I'd just remove that part as it = can bring up old arguments from other WG and your mathematical formulas = are perfectly clear without mentioning C. >=20 > Without that sentence, the formulae are not well-defined. > (Let's fight that windmill when we encounter it :-) >=20 > > You say the block options are optional to implement but that's not = the right way to think about it. The draft is an extensions to CoAP and = it's optional if you decide to implement the RFC this becomes or not, = but if you implement this RFC, then you MUST implement these so they are = not optional in the context of this draft. >=20 > I hate the word optional, because it never means anything useful. > But, now, a node might implement Block2 and not Block1, so some text = to this effect is actually required. >=20 > > The three bullet points paragraphs at the end of section 2.1 are = very hard to understand. >=20 > Yes, they need a serious editorial round. >=20 > > When you say that future requests have to have the same block size = as the earlier one, who is responsible for enforcing this. Does the = server need to remember and reject or is it the responsibility of the = client to do the right thing. >=20 > This is a mandate to make some potential server implementations = simpler, not to complicate them. > Note that there are no error codes defined... > (I would be prepared to completely delete that mandate, by the way.) >=20 > > I don't like the "m" nomenclature - I know where it comes from but = it seems meaningless. I'd prefer a LastBlock field or something like = that. >=20 > Well, it would be NotLastBlock (otherwise we would change the wire = protocol). > Is that better than "m"? >=20 > > In the HTTP mapping section, I'd delete the stuff about problems of = implementing HTTP (and the HTTP to CoAP mapping) on a constrained node. = I don't think our goal is to make HTTP work on the constrained node. >=20 > Well, the whole section is implementation advice, and it is not about = implementing HTTP, but about what a mapper might need to do to do Block. > But, apart from this advice, it helps in understanding why the = protocol is defined as it is. > Deleting the text would go some way towards the typical trapdoor = standard (i.e., we'll tell you how it works if you already understand = that). >=20 > > In section 5.1, the advice to not create state seems sort of = useless. I'd rather see the draft get clear about where implementations = SHOULD create state and where they don't need to and more importantly, = how to clean up and timeout any state that does get created. >=20 > If you want to counter resource exhaustion, not creating state is the = best defense there is -- yes, that's trivial, but it is still good = advice. > Apart from that, leave that up to the server, I'd say. >=20 > Gruesse, Carsten >=20 >=20 From likepeng@huawei.com Mon May 9 19:01:48 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3382EE09D8 for ; Mon, 9 May 2011 19:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.696 X-Spam-Level: X-Spam-Status: No, score=-3.696 tagged_above=-999 required=5 tests=[AWL=0.799, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Culuu-PWc6oy for ; Mon, 9 May 2011 19:01:47 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 81F62E06B7 for ; Mon, 9 May 2011 19:01:46 -0700 (PDT) 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 <0LKY005DNIYXKX@szxga04-in.huawei.com> for core@ietf.org; Tue, 10 May 2011 10:01:45 +0800 (CST) Received: from szxeml206-edg.china.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 <0LKY00EUUIYXYH@szxga04-in.huawei.com> for core@ietf.org; Tue, 10 May 2011 10:01:45 +0800 (CST) Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 10 May 2011 10:01:43 +0800 Received: from SZXEML506-MBS.china.huawei.com ([169.254.3.27]) by SZXEML401-HUB.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0270.001; Tue, 10 May 2011 10:01:44 +0800 Date: Tue, 10 May 2011 02:01:44 +0000 From: Likepeng In-reply-to: <348BAAE6-E026-46F6-B76F-5CF099C42441@cisco.com> X-Originating-IP: [10.70.109.110] To: Cullen Jennings , Carsten Bormann Message-id: <34966E97BE8AD64EAE9D3D6E4DEE36F22878F2@SZXEML506-MBS.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [core] draft-ietf-core-block-03 review Thread-index: AQHMDn82dVfHrRXSckSQfxNRqPAdz5SEZk2AgABYsACAAIyYYA== X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <65C046E2-65E4-4C20-B1AB-CBE12C9B8164@cisco.com> <348BAAE6-E026-46F6-B76F-5CF099C42441@cisco.com> Cc: core WG Subject: Re: [core] draft-ietf-core-block-03 review X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 02:01:48 -0000 > The problem here is that unless that client and server have a coordinated view of the timeouts, the system is not going to interoperate. If the client thinks it should wait 30 seconds to time out a single request that did not get a responses, and the server thinks it should through away the state of any block buffer after 25 seconds, we have a problem. +1. The client does not know how long it should wait for the response, and has to keep the state for the request. It can choose to give up the request after its own defined timeout, then the received response after the timeout will be useless. Kind Regards Kepeng -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Cullen Jennings Sent: Tuesday, May 10, 2011 9:25 AM To: Carsten Bormann Cc: core WG Subject: Re: [core] draft-ietf-core-block-03 review On May 9, 2011, at 13:07 , Carsten Bormann wrote: > > What happens if the resource changes part way through a GET? For devices that make a virtual snapshot of the resource, I'd like the it so that if the resources changes while the transfer is happing, the value the client receives is the value of resources when the server received the first get. There need to be some sort of minimum timeout so that the client knows the server will not discard the snapshot while the transfer is happening. For servers that don't do a snapshot, then I think an ETAG should be mandatory. Current draft seems to say the client MUST check it but it only has an SHOULD on the server sending it. > > The philosophy behind CoAP is to leave many decisions up to the server. > E.g., whether a frozen copy is made when a block-wise transfer starts or the server simply operates in a stateless fashion. > Yes, you can implement a server that makes it really hard to get a resource representation. > We can try to create a jungle of MUSTs and SHOULDs here, which in the end will do the wrong things for some specific situation. > Leave that up to the server, I'd say. well, the same problem applies of how does the client know if it got a atomic representation of the state or some broken intermediate representation. I don't think you can leave this up to the server and still build systems that function in the way you want the system to function. > > > More complicated is the PUT / POST. On these, I think they should be required to be atomic. Designing systems with clients that can deal with non atomic requests is very hard. I understand this has consequences on servers but not saying that has consequences on clients and overall system stability. A node may be willing to have some resource in an inconsistent state, but another node that does a GET of that resource may not be able to deal with the inconsistent state. Again with PUT/ POST, need some sort of overall timeout where the server can discard the state if the client dies. > > That depends, again. > A server that provides a REST protocol that creates a specific instance for each client to PUT into does not need to do any of this. Could you expand a bit more on how this solves the problem, I'm not getting it. > I have no idea how to come up with a reasonable value for such a timeout. The problem here is that unless that client and server have a coordinated view of the timeouts, the system is not going to interoperate. If the client thinks it should wait 30 seconds to time out a single request that did not get a responses, and the server thinks it should through away the state of any block buffer after 25 seconds, we have a problem. (I also am not a fan of situation where the implementor of a protocol, with even less information than the designers of the protocol, has to figure out how to do something the designers could not figure out.) > Different applications will need quite different values. > Leave all that up to the server, I'd say. > > > I think the client should explicitly signal support for blocks to the sever before the server starts using this extension. > > (See last message.) > > > I think we need a provisional response code that indicates the far end is simply buffering. Using 2.04 until the block m=0 seems like lots of things could go wrong in a bad way. > > The echoed m bit in the Block1 option is that provisional code. > (Yes, that could be re-enforced with a different response code as well, but that we'd lose the distinction between 2.01 and 2.04.) hmm - I missed that in my read of the draft. It's an interesting point, so you are saying the first block could have a 2.01 with a location returned yet the last block may still result in an error. Probably need to specify what happens to the location returned validity in that case. Seems like one more good reason to have PUT be atomic. > > > Can you use non confirmed requests when doing block? The way 4.08 works, this is going to be pretty dicey. I'm a bit confused around if the 4.08 is a missing fragment error or a timeout error. Needs some clarification and perhaps two codes. > > We need a ton more examples. > > 4.08 is a missing fragment error. A timeout simply isn't signalled (where would you signal it) and then leads to a missing fragment error. So, in the end, 4.08 also is a timeout error. When using proxies, you often need to signal timeouts so if it is useful for the client to understand if the error was a timeout or a missing fragment, it would probably be best to have an explicit error code for it. > > > Imagine a large download such as an XML or JSON config for a device or the firmware example. Should there be any advice on trickling or slowing down large transfers? If 20 devices on a small 802.15.4 mesh network with only one link the rest of the internet started doing a firmware download at the same time, I suspect that it badly impact the other traffic on this network. > > That's handled by the lock-step congestion control. > > > On the size of the blocks ... given MTU are raising and make a huge difference to high performance networks, I'd prefer to see support for 8K or 16K block size as well as the smaller ones. I'm also sympathetic to the power of 2 are not optimal given we can pick any number we want. It might be a good idea to pick some sizes that seemed optimal for MTU we would get on 802.15.4 network, some of the cellular data networks, an 1280 MTU network, and something in the Jumbo gram space. I also get the point this looks like over optimization, I'm on the fence :-) > > We just killed 2048, and I think that was the right decision (high-performance networks are out of scope). > I tried to define a size that would be optimal, but there are so many variables in header compression efficiency, security overhead etc., that this doesn't work too well (well, actually 64 is pretty good in most cases -- anything beyond that is premature optimization). > > > Need an example where we have block transfer in request and responses. Like it if it showed ETags and Tokens too. > > Yes, we need a ton more examples! > This one was already requested by Guido, and we definitely need to put it in. > > > In mention you use C pseudo code, I'd just remove that part as it can bring up old arguments from other WG and your mathematical formulas are perfectly clear without mentioning C. > > Without that sentence, the formulae are not well-defined. > (Let's fight that windmill when we encounter it :-) > > > You say the block options are optional to implement but that's not the right way to think about it. The draft is an extensions to CoAP and it's optional if you decide to implement the RFC this becomes or not, but if you implement this RFC, then you MUST implement these so they are not optional in the context of this draft. > > I hate the word optional, because it never means anything useful. > But, now, a node might implement Block2 and not Block1, so some text to this effect is actually required. > > > The three bullet points paragraphs at the end of section 2.1 are very hard to understand. > > Yes, they need a serious editorial round. > > > When you say that future requests have to have the same block size as the earlier one, who is responsible for enforcing this. Does the server need to remember and reject or is it the responsibility of the client to do the right thing. > > This is a mandate to make some potential server implementations simpler, not to complicate them. > Note that there are no error codes defined... > (I would be prepared to completely delete that mandate, by the way.) > > > I don't like the "m" nomenclature - I know where it comes from but it seems meaningless. I'd prefer a LastBlock field or something like that. > > Well, it would be NotLastBlock (otherwise we would change the wire protocol). > Is that better than "m"? > > > In the HTTP mapping section, I'd delete the stuff about problems of implementing HTTP (and the HTTP to CoAP mapping) on a constrained node. I don't think our goal is to make HTTP work on the constrained node. > > Well, the whole section is implementation advice, and it is not about implementing HTTP, but about what a mapper might need to do to do Block. > But, apart from this advice, it helps in understanding why the protocol is defined as it is. > Deleting the text would go some way towards the typical trapdoor standard (i.e., we'll tell you how it works if you already understand that). > > > In section 5.1, the advice to not create state seems sort of useless. I'd rather see the draft get clear about where implementations SHOULD create state and where they don't need to and more importantly, how to clean up and timeout any state that does get created. > > If you want to counter resource exhaustion, not creating state is the best defense there is -- yes, that's trivial, but it is still good advice. > Apart from that, leave that up to the server, I'd say. > > Gruesse, Carsten > > _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From zach@sensinode.com Mon May 9 23:08:03 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E58E0E077B for ; Mon, 9 May 2011 23:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tc1lrg3GAuKN for ; Mon, 9 May 2011 23:08:00 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 5698FE07F1 for ; Mon, 9 May 2011 23:07:58 -0700 (PDT) Received: from [213.145.205.244] ([213.145.205.244]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id p4A67pjF001766 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 10 May 2011 09:07:51 +0300 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-72-282958638; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: Date: Tue, 10 May 2011 09:07:52 +0300 Message-Id: References: <76503846-BE4E-435B-A7B2-9AA679D17B11@cisco.com> To: Carsten Bormann X-Mailer: Apple Mail (2.1084) Cc: core WG Subject: Re: [core] draft-ietf-core-coap-06 Request Timeout X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 06:08:04 -0000 --Apple-Mail-72-282958638 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 9, 2011, at 10:34 PM, Carsten Bormann wrote: > On May 9, 2011, at 21:28, Cullen Jennings wrote: >=20 >>=20 >> If a client sends a request such as a GET, what is the default = timeout after which it should consider there was an error if it has not = received a response? >=20 > The same answer as for HTTP. > (There is no such defined value.) >=20 > Assuming that there were such a default value: > What should a server do when it is getting close to that value and = still does not have an answer? > Since there is no good answer to that, I don't think there is a good = reason to have such a default value. I agree, this is implementation specific. Zach >=20 > Gruesse, Carsten >=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-72-282958638 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 ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDUxMDA2MDc1 M1owIwYJKoZIhvcNAQkEMRYEFI3CZS+YWJRvr2mvlR0aeOqEHI6iMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAF+FpseP/Ddl9f9+ZJ2R8SX6P6MtWJHGKeDg4re1Hu0tvL740XHgsV8D 2wnF+8rP1GfwqjB+ddHw0gx3VR4Pk3Elp1TLQ4jNPVRl2NK432B/hRuROvW0RWV09RbuHaP2ATRk 78IvTKTHlYaB9IDWbrUZSEyqHPG7y2LOyuBnUjJ5v+23u3D9+gVvuY9dnPXpB6oEhLqbnfVNpr1G 5elKJeZV1crCg5UkfLLAl49AOuaPJwn44plpc4CA2OjfNrVq+kM3bNZEDEiZUe4d5TOvGYg306j5 lcTLTLZ3xGeDmiMi7mh9uQH3mv1L5InQ0yvvV22/SaJUBzcF1RieUTFOc04AAAAAAAA= --Apple-Mail-72-282958638-- From angelo.castellani@gmail.com Tue May 10 00:36:51 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2D6FE07EA for ; Tue, 10 May 2011 00:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.31 X-Spam-Level: X-Spam-Status: No, score=-2.31 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HxCbs7cuGusm for ; Tue, 10 May 2011 00:36:50 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 40B40E07DB for ; Tue, 10 May 2011 00:36:49 -0700 (PDT) Received: by qyk7 with SMTP id 7so4554208qyk.10 for ; Tue, 10 May 2011 00:36:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=FZbBVI/GY4xreRwi+JiK3kM21Wv7PeRqWuONwsPnPeA=; b=jKg7aAE3FbtXqWulsvhbDXZOH0WSYOGnNFESt9qom+1nbqZIyz/NHJTCBaTMSAbb28 TgqQUiYoF3ioAa8fyJ+Dqu7KHpoaR/m63xNhyojiT87XCgOZW1wWV/+aUlq/LqiJYeaM QZhJlD+N54ooCrhmufqU4tmGFzyXRD2vXqr8Y= 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=NLaOevKcqcSJHrdBrD9yJ1h+nvwTwN2XdGleSZzzwbm7v79qmrXGLdcvlNAYcisdRA lp5YUxYYqaZgP9y3W9r31g6/R4LW1paBQc1BxmxHDqh0kAvy83/iMLnH+YCg4CsMgpNc /5eqNZQ5Lkl9z1Hfn7EMqMMjDkC3UUK+KrKuU= Received: by 10.229.114.80 with SMTP id d16mr5932252qcq.18.1305013009070; Tue, 10 May 2011 00:36:49 -0700 (PDT) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.229.215.79 with HTTP; Tue, 10 May 2011 00:36:29 -0700 (PDT) In-Reply-To: <348BAAE6-E026-46F6-B76F-5CF099C42441@cisco.com> References: <65C046E2-65E4-4C20-B1AB-CBE12C9B8164@cisco.com> <348BAAE6-E026-46F6-B76F-5CF099C42441@cisco.com> From: "Angelo P. Castellani" Date: Tue, 10 May 2011 09:36:29 +0200 X-Google-Sender-Auth: lC1z15tbr3ofvXlwpyFSIcCycYk Message-ID: To: Cullen Jennings Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: core WG Subject: Re: [core] draft-ietf-core-block-03 review X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 07:36:51 -0000 On Tue, May 10, 2011 at 03:24, Cullen Jennings wrote: > well, the same problem applies of how does the client know if it got a at= omic representation of the state or some broken intermediate representation= . I don't think you can leave this up to the server and still build systems= that function in the way you want the system to function. > > The problem here is that unless that client and server have a coordinated= view of the timeouts, the system is not going to interoperate. If the clie= nt thinks it should wait 30 seconds to time out a single request that did n= ot get a responses, and the server thinks it should through away the state = of any block buffer after 25 seconds, we have a problem. +1 From cabo@tzi.org Tue May 10 05:24:57 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A276E0708 for ; Tue, 10 May 2011 05:24:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.092 X-Spam-Level: X-Spam-Status: No, score=-106.092 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KekSZB8kZN7m for ; Tue, 10 May 2011 05:24:56 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 62080E06E0 for ; Tue, 10 May 2011 05:24:55 -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 p4ACOEcM011778; Tue, 10 May 2011 14:24:14 +0200 (CEST) Received: from eduroam-0382.wlan.uni-bremen.de (eduroam-0382.wlan.uni-bremen.de [134.102.17.126]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 58D5B4DA; Tue, 10 May 2011 14:24:14 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <348BAAE6-E026-46F6-B76F-5CF099C42441@cisco.com> Date: Tue, 10 May 2011 14:24:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0C2CC0AF-0A75-45F7-8808-7D62C10E4803@tzi.org> References: <65C046E2-65E4-4C20-B1AB-CBE12C9B8164@cisco.com> <348BAAE6-E026-46F6-B76F-5CF099C42441@cisco.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1084) Cc: core WG Subject: Re: [core] draft-ietf-core-block-03 review X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 12:24:57 -0000 On May 10, 2011, at 03:24, Cullen Jennings wrote: > The problem here is that unless that client and server have a = coordinated view of the timeouts, the system is not going to = interoperate. If the client thinks it should wait 30 seconds to time out = a single request that did not get a responses, Wait a minute -- *why* did that request not get a response? If I'm a client in a block-wise transfer and I never get a response for = my request for block 37, this block-wise transfer is hosed. (Note that we have a message layer below that that makes sure this is = not just happening because of a random packet loss.) This is like a TCP connection going away mid-transfer. Of course, in CoAP, I can simply request block 37 again whenever I want, = but then I get whatever the server has at that later point in time -- if = the ETags match, I can recover the transfer, otherwise I can't. > and the server thinks it should through away the state of any block = buffer after 25 seconds, we have a problem.=20 General comment: Much of this becomes clearer when you think about HTTP and how an HTTP = client does *not* set the parameters for the server-side TCP = implementation. Somehow, HTTP still works pretty well. Gruesse, Carsten From cabo@tzi.org Tue May 10 06:07:23 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 009EFE06D8 for ; Tue, 10 May 2011 06:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.118 X-Spam-Level: X-Spam-Status: No, score=-106.118 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J4GA6m2RTDle for ; Tue, 10 May 2011 06:07:22 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id D5BCFE071E for ; Tue, 10 May 2011 06:07:20 -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 p4AD6qwn028672; Tue, 10 May 2011 15:06:52 +0200 (CEST) Received: from eduroam-0382.wlan.uni-bremen.de (eduroam-0382.wlan.uni-bremen.de [134.102.17.126]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id C23A753E; Tue, 10 May 2011 15:06:49 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <34966E97BE8AD64EAE9D3D6E4DEE36F228783B@SZXEML506-MBS.china.huawei.com> Date: Tue, 10 May 2011 15:06:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <76503846-BE4E-435B-A7B2-9AA679D17B11@cisco.com> <34966E97BE8AD64EAE9D3D6E4DEE36F228783B@SZXEML506-MBS.china.huawei.com> To: Likepeng X-Mailer: Apple Mail (2.1084) Cc: core WG Subject: Re: [core] draft-ietf-core-coap-06 Request Timeout X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 13:07:23 -0000 On May 10, 2011, at 03:17, Likepeng wrote: > I have a draft to let the client to define a timeout in the request: > = http://tools.ietf.org/id/draft-li-core-coap-response-mode-option-00.txt >=20 > [...] > I would like to get feedback from you on the draft. Sure. 1) Get rid of the P bit. Influencing this is none of the client's business. It is not even useful for a client -- since the option is elective, = the client cannot even rely on it being heeded. There is no option in TCP to control whether the peer should send its = data piggybacked on an ACK either. 2) I think I like the T part of the option. However, it should be rephrased as "indicates the length of time from the time of request the = response would be useful for the client". Because that's all we can say. If the server doesn't have the data, = it doesn't have it. Representing T in exponential form sounds fine to me (but we have had = some arguments on duration representation before). I would deliberately = keep the spec open on whether the base is milliseconds or 1024s of a = second -- the clocks are not going to be that precise anyway, and this = might help some implementations that count in 1024s ("mibiseconds") or = in whole seconds. 3) T should not have a default value. (I'm not going to repeat why that would be a mistake, see my previous = messages.) 4) We also need a new response code, "can't provide the data in time". This is a code that a server that already knows it won't be able to = meet the deadline can send early on. (Note that the client cannot rely on getting the response code, = because the server might have failed in the meantime.) We haven't really discussed the difference between what is = Connection-Timeout in draft-thomson-hybi-http-timeout-00 and this = option, which is similar to Request-Timeout in that draft. Gruesse, Carsten From cabo@tzi.org Tue May 10 06:22:03 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69B39E07C9 for ; Tue, 10 May 2011 06:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.137 X-Spam-Level: X-Spam-Status: No, score=-106.137 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2MveCXqyBRV for ; Tue, 10 May 2011 06:22:02 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 9449EE071E for ; Tue, 10 May 2011 06:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id p4ACX1K5015100; Tue, 10 May 2011 14:33:01 +0200 (CEST) Received: from eduroam-0382.wlan.uni-bremen.de (eduroam-0382.wlan.uni-bremen.de [134.102.17.126]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 8C7EF4E5; Tue, 10 May 2011 14:33:01 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Tue, 10 May 2011 14:33:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <770C6CBC-E55E-41B2-BA92-1B161C8282A7@cisco.com> <1DA0334E-AD93-4494-A34D-B817A16A60DD@cisco.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1084) Cc: core WG Subject: Re: [core] draft-ietf-core-coap-06 IF-Match Option X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Carsten Bormann List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 13:22:03 -0000 >> I read the text you have in the misc draft on if-match and thought it = looked just right. As an individual contributor, I would suggest we take = this text and move it to CoAP. I don't see a compelling reasons to add = the If-None-Match. >=20 > The only one that sounds useful is "If-None-Match: *", which allows to = restrict a PUT to a "Create", similar to the way "If-Match: *" restricts = it to a "Replace". "Create" actually is much more useful than "Replace" = -- if you do the latter, you probably know what you are replacing, so = you could give the ETag for a full "If-Match: ___". >=20 > Just a thought. Another thought is to not have an option for the * cases, but instead = have two new methods: CREATE is like PUT with If-None-Match: * (fails if resource = exists) UPDATE is like PUT with If-Match: * (fails if resource does not = exist). (and, of course, the PUT that doesn't care whether the resource exists). This leaves us with a clean If-Match Option for the UPDATE case where we = do care about the ETag. Just a thought, bis. (Note that none of these need to be in the base spec, by the way. There = is a reason we have moved block and observe to separate documents...) Gruesse, Carsten From cabo@tzi.org Tue May 10 06:22:03 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBE6FE071E for ; Tue, 10 May 2011 06:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.151 X-Spam-Level: X-Spam-Status: No, score=-106.151 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IG5d0CyfJ11h for ; Tue, 10 May 2011 06:22:03 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 08D90E07C5 for ; Tue, 10 May 2011 06:22:02 -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 p4ACjU0F019429; Tue, 10 May 2011 14:45:30 +0200 (CEST) Received: from eduroam-0382.wlan.uni-bremen.de (eduroam-0382.wlan.uni-bremen.de [134.102.17.126]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id A20C1500; Tue, 10 May 2011 14:45:30 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <348BAAE6-E026-46F6-B76F-5CF099C42441@cisco.com> Date: Tue, 10 May 2011 14:45:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7D357C87-FC1E-4365-BF28-BE634C460B0E@tzi.org> References: <65C046E2-65E4-4C20-B1AB-CBE12C9B8164@cisco.com> <348BAAE6-E026-46F6-B76F-5CF099C42441@cisco.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1084) Cc: core WG Subject: Re: [core] draft-ietf-core-block-03 review X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 13:22:04 -0000 On May 10, 2011, at 03:24, Cullen Jennings wrote: >>> More complicated is the PUT / POST. On these, I think they should be = required to be atomic. Designing systems with clients that can deal with = non atomic requests is very hard. I understand this has consequences on = servers but not saying that has consequences on clients and overall = system stability. A node may be willing to have some resource in an = inconsistent state, but another node that does a GET of that resource = may not be able to deal with the inconsistent state. Again with PUT/ = POST, need some sort of overall timeout where the server can discard the = state if the client dies. >>=20 >> That depends, again. >> A server that provides a REST protocol that creates a specific = instance for each client to PUT into does not need to do any of this. >=20 > Could you expand a bit more on how this solves the problem, I'm not = getting it.=20 If there is no way for two clients to interfere because they are using = different resources, there is no need to provide atomicity. Example 1: You put into a resource the name of which is derived from a = hash of the resource representation. Example 2: You ask the server for a resource name before starting to put = into it. Example 3: Only one client is authorized to access the resource and that = client knows what it is doing. These are just examples. All I'm trying to say is that making = requirements on the protocol that are not needed by the application is = not helpful. (All this kind of feels like locking the whole table = before executing an SQL statement... There are many strategies, and the = protocol should not limit the choice.) Gruesse, Carsten From robert.cragie@gridmerge.com Tue May 10 06:55:58 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1B61E0693 for ; Tue, 10 May 2011 06:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.302 X-Spam-Level: X-Spam-Status: No, score=0.302 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, MANGLED_BEST=2.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XF3CuN-mLEfb for ; Tue, 10 May 2011 06:55:57 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by ietfa.amsl.com (Postfix) with ESMTP id 7FED1E0593 for ; Tue, 10 May 2011 06:55:50 -0700 (PDT) Received: from client-86-23-111-162.brhm.adsl.virginmedia.com ([86.23.111.162] helo=[192.168.1.80]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.73) id 1QJnPg-000498-Cc for core@ietf.org; Tue, 10 May 2011 14:55:48 +0100 Message-ID: <4DC943E8.2040901@gridmerge.com> Date: Tue, 10 May 2011 14:55:52 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: core@ietf.org References: <1FFCF0B6-2DF8-4776-BC6B-47069737AD50@cisco.com> <2ECE1C68-6650-43D4-97B6-2D405143C845@tzi.org> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010608060004000005060906" X-Authenticated-As: robert.cragie@gridmerge.com Subject: Re: [core] draft-ietf-core-coap-06 The CoAP/DTLS/CoAP Turkey Sandwich layer violation train wreck X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 13:55:58 -0000 This is a cryptographically signed message in MIME format. --------------ms010608060004000005060906 Content-Type: multipart/alternative; boundary="------------090006060604010603060409" This is a multi-part message in MIME format. --------------090006060604010603060409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable I have never seen what the issue is with using two ports like HTTPS: * One port for CoAP over UDP * One port for CoAP over DTLS over UDP 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 06/05/2011 8:49 AM, Eric Rescorla wrote: > On Thu, May 5, 2011 at 6:24 PM, Carsten Bormann wrote: >> On May 6, 2011, at 02:51, Eric Rescorla wrote: >> >>> 1. Use STUN as-is. >> Yep, we are doing that. >> (The escaping stuff is insurance for a case that is rather unlikely. = We could take it out.) >> >> What is the status about STUN coexisting with DTLS? > As far as I know, there's no problem, since the leading bytes plus cook= ies make > collisions very unlikely. > > >>> 2. Use a leading framing byte to distinguish DTLS and CoAP from STUN.= >>> If you're really worried >>> about compactiness, >> (Yes, we are.) >> >>> then pick only a single value to distinguish DTLS >>> (e.g., 0xffffffff) >> (That would be a bit long.) > Sorry, brain failure. 0xff > > >>> and use all >>> the remaining values to give you a little more room in the rest of th= e packet. >> Sure, we could do that. It would mean spending another byte for all D= TLS packets. > Right. My argument is that that's not that big a deal because it only > increases space > by ~5%. > > >> More importantly, it also means DTLS packets no longer look like DTLS = packets, which complicates debugging. > Yes, I agree that that's suboptimal. That's why I prefer separate ports= =2E.. > The material you're quoting above is just some other thoughts for deali= ng with > the same port if people insist. > > >> I would like to learn more about your plans to expand the DTLS Content= Type space. >> This hasn't changed since 1996. Of course, it could, next month. >> Again, the escaping stuff is insurance for this case. We could take i= t out. > I don't think there are any immediate plans to do so--though note that > http://tools.ietf.org/html/draft-seggelmann-tls-dtls-heartbeat-01 > does contemplate one addition. And I would assume that we intend to > assign the content-types towards the bottom of the range first. That sa= id, > I don't think TLS-WG has by any means decided to commit to not > assigning a bunch more types. > > Bes,t > -Ekr > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --------------090006060604010603060409 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I have never seen what the issue is with using two ports like HTTPS:<= br>
  • One port for CoAP over UDP
  • One port for CoAP over DTLS over UDP

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 06/05/2011 8:49 AM, Eric Rescorla wrote: 
On Thu, May 5, 2011 at 6:24 PM, Carsten Bormann <cabo@tzi.=
org> wrote:

On May 6, 2011, at 02:51, Eric Rescorla wrote:


1. Use STUN as-is.

Yep, we are doing that.
(The escaping stuff is insurance for a case that is rather unlikely. &nbs=
p;We could take it out.)

What is the status about STUN coexisting with DTLS?

As far as I know, there's no problem, since the leading bytes plus cookie=
s make
collisions very unlikely.



2. Use a leading framing byte to distinguish DTL=
S and CoAP from STUN.
If you're really worried
about compactiness,

(Yes, we are.)


then pick only a single value to distinguish DTL=
S
(e.g., 0xffffffff)

(That would be a bit long.)

Sorry, brain failure. 0xff



and use all
the remaining values to give you a little more room in the rest of the pa=
cket.

Sure, we could do that.  It would mean spending another byte for all=
 DTLS packets.

Right. My argument is that that's not that big a deal because it only
increases space
by ~5%.



More importantly, it also means DTLS packets no lo=
nger look like DTLS packets, which complicates debugging.

Yes, I agree that that's suboptimal. That's why I prefer separate ports..=
=2E
The material you're quoting above is just some other thoughts for dealing=
 with
the same port if people insist.



I would like to learn more about your plans to exp=
and the DTLS ContentType space.
This hasn't changed since 1996.  Of course, it could, next month.
Again, the escaping stuff is insurance for this case.  We could take=
 it out.

I don't think there are any immediate plans to do so--though note that
http://tools.ietf.org/html/draft-seg=
gelmann-tls-dtls-heartbeat-01
does contemplate one addition. And I would assume that we intend to
assign the content-types towards the bottom of the range first. That said=
,
I don't think TLS-WG has by any means decided to commit to not
assigning a bunch more types.

Bes,t
-Ekr
_______________________________________________
core mailing list
core@=
ietf.org
https://www.ietf.org/mailman/listinfo/core
--------------090006060604010603060409-- --------------ms010608060004000005060906 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIREjCC BIowggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w NTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMC VVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l dHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVN NRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQy lbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXq vgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6 hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu 9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0G A1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/ BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9BZGRU cnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8ubmV0L0Fk ZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyispgCi 54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0 g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHd WTBK322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftz Mizpm4QkLdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsy XEFs/vVdoOr/0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIGPjCCBSagAwIBAgIRALZcFI008b3q kGPLKBbwWBIwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEX MBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29y azEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMTAwODMwMDAwMDAw WhcNMTEwODMwMjM1OTU5WjCB5DE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQ RVJTT05BIE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9m IHVzZTogaHR0cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIw MDMgQ29tb2RvIExpbWl0ZWQxFjAUBgNVBAMTDVJvYmVydCBDcmFnaWUxKjAoBgkqhkiG9w0B CQEWG3JvYmVydC5jcmFnaWVAZ3JpZG1lcmdlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALQCfpvU4Hd5YvAYACEbYRrbYd2HAm4Sz43wHJwynBBkq5GamqO/SYNrg1ut iDsDQqvWnt1cHgZb4N1FFbvLqV84A0f4xc+EtWTZNYn+lfUBIsgR3RNajFEHnsrXnZN6sPdw lObJ1ol4FUWnFPB/A7/liT7G+FmAB+DAc2iTCNjfxOVxhmKShY/b8ZxIkO4fN418cNxHtq1w gm4SRHIv7VJfgseNKQd5u55RHQEmPgN7aiSyIhvAK4H9Pm1msZrklIoSqGpIR0K7gMpVmPRF bWyoPEgAmGYXRwsdvmUkq8W2wCkr9HA5NNL0D74B+RhIus0gfUL6lgnQR/6y9F31eY0CAwEA AaOCAh0wggIZMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBRp GoTqjgTJPeVwG/HaXEXWnn/AGDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNV HSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1Ud IAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNv bW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2Eu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRp Y2F0aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDov L2NydC5jb21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC5jb21vZG9jYS5jb20wJgYDVR0RBB8wHYEbcm9iZXJ0LmNyYWdpZUBncmlkbWVy Z2UuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQA3I0iUCoFSHw/yM7Ra4cdmKkfZirA7N12pCneI VKHrpx4LJImjCEGNinH6G+PDrs632O96zXzaGqq+S2cA3lX5TJ2XdKz3EwPawB6uZf6sHUrW t5NMbwbotDQLTq0gXW6guL4ICyrmb6EdqO5km8UkgWR7lSzm8fxORPg+X41gu33zb6/cv7hV 3gmBbDPh3PVTyGfnAGOyUBSRCvzbrYtkByCMXUfdTdrx7jV1iD0TjxTJe8vJbTv3zjcIcTHG NnR+CZAx+qXTczLc8pL7DtDXokR5zZUuCgPGg/UWgUfBTUB6vibrAtrX9danRwaR61QCu3R6 HSg520a9rfVXa1NqMIIGPjCCBSagAwIBAgIRALZcFI008b3qkGPLKBbwWBIwDQYJKoZIhvcN AQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtl IENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDov L3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMTAwODMwMDAwMDAwWhcNMTEwODMwMjM1OTU5WjCB 5DE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05BIE5PVCBWQUxJREFU RUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0cDovL3d3dy5j b21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExpbWl0ZWQx FjAUBgNVBAMTDVJvYmVydCBDcmFnaWUxKjAoBgkqhkiG9w0BCQEWG3JvYmVydC5jcmFnaWVA Z3JpZG1lcmdlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALQCfpvU4Hd5 YvAYACEbYRrbYd2HAm4Sz43wHJwynBBkq5GamqO/SYNrg1utiDsDQqvWnt1cHgZb4N1FFbvL qV84A0f4xc+EtWTZNYn+lfUBIsgR3RNajFEHnsrXnZN6sPdwlObJ1ol4FUWnFPB/A7/liT7G +FmAB+DAc2iTCNjfxOVxhmKShY/b8ZxIkO4fN418cNxHtq1wgm4SRHIv7VJfgseNKQd5u55R HQEmPgN7aiSyIhvAK4H9Pm1msZrklIoSqGpIR0K7gMpVmPRFbWyoPEgAmGYXRwsdvmUkq8W2 wCkr9HA5NNL0D74B+RhIus0gfUL6lgnQR/6y9F31eY0CAwEAAaOCAh0wggIZMB8GA1UdIwQY MBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBRpGoTqjgTJPeVwG/HaXEXWnn/A GDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYL KwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQEC AQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNV HR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL1VUTi1VU0VSRmlyc3Qt Q2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBIoEaGRGh0dHA6Ly9jcmwuY29t b2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3Js MGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5jb21vZG9jYS5jb20v VVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5j b20wJgYDVR0RBB8wHYEbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQA3I0iUCoFSHw/yM7Ra4cdmKkfZirA7N12pCneIVKHrpx4LJImjCEGNinH6G+PD rs632O96zXzaGqq+S2cA3lX5TJ2XdKz3EwPawB6uZf6sHUrWt5NMbwbotDQLTq0gXW6guL4I Cyrmb6EdqO5km8UkgWR7lSzm8fxORPg+X41gu33zb6/cv7hV3gmBbDPh3PVTyGfnAGOyUBSR CvzbrYtkByCMXUfdTdrx7jV1iD0TjxTJe8vJbTv3zjcIcTHGNnR+CZAx+qXTczLc8pL7DtDX okR5zZUuCgPGg/UWgUfBTUB6vibrAtrX9danRwaR61QCu3R6HSg520a9rfVXa1NqMYIEYDCC BFwCAQEwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBM YWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0 cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBB dXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQC2XBSNNPG96pBjyygW8FgSMAkGBSsOAwIaBQCg ggJwMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDUxMDEz NTU1MlowIwYJKoZIhvcNAQkEMRYEFHtgqZMRUAuJK+f4WZV4t0zM1qWkMF8GCSqGSIb3DQEJ DzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG 9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB1QYJKwYBBAGCNxAEMYHHMIHEMIGu MQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4w HAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNl cnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRp b24gYW5kIEVtYWlsAhEAtlwUjTTxveqQY8soFvBYEjCB1wYLKoZIhvcNAQkQAgsxgceggcQw ga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkx HjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51 c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgRW1haWwCEQC2XBSNNPG96pBjyygW8FgSMA0GCSqGSIb3DQEBAQUABIIBAJs+ 1eq5RGwl2I31VPtgvkWK4Gj5ne8KnyOrzQ97Wr14LBoNQFlvovlFARgPPRyRvjd+8a53Pi82 Mbq+d3Gp5vnKWrr+vvduQH1aXTCgiOpjRow8M96sF+pbDNywJEgoKZPYxpqIzYolUdNcS7Xz bTQqCxTIiLUf6TTovA3JFZO3GzOoO7Q/tCc1EGf67aiev5N9wfxIuKQ6NzpAEihercootBWA W9jLVJHZNsPco1I7qmL+eoHMaUlryHDO4KKwss9xxfbvBC1bU2BfjRDTA0IBS1EGgdTbT2xM genpOXWr1pdhiSIYWM/2iQcCjsflxW9QaFd2jn4xLUz1vO6xq2kAAAAAAAA= --------------ms010608060004000005060906-- From fluffy@cisco.com Tue May 10 07:12:52 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3274E06CC for ; Tue, 10 May 2011 07:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.563 X-Spam-Level: X-Spam-Status: No, score=-110.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Qd7S50p1C-k for ; Tue, 10 May 2011 07:12:51 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 66ADDE0593 for ; Tue, 10 May 2011 07:12:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=635; q=dns/txt; s=iport; t=1305036771; x=1306246371; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=ujOsrseI6zfYRi30Mb6g2OUAIpANiPpZHZiKWjMLzns=; b=BQPo7tg2l+YJ+x01N6soHPfjNsn5CSLiGVJd8xpw+fqj7detjjaJCKo3 3M3pH0jM8N05gaCNN4lhd164a4BfY0Myi0epwsjTr8UvEO4SOuWaikHsN /3amjH+Gq0wdYef6n6fzAO/GGH6Moj/HUretp+txpNEfdIunZyEaiTeGR 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEHAFBHyU2rRDoJ/2dsb2JhbAAipVx3pkGBHZ5Thg8EhkKJLo5+ X-IronPort-AV: E=Sophos;i="4.64,346,1301875200"; d="scan'208";a="694887121" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-6.cisco.com with ESMTP; 10 May 2011 14:12:50 +0000 Received: from dhcp-171-68-21-134.cisco.com (dhcp-171-68-21-134.cisco.com [171.68.21.134]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p4AECodo032240 for ; Tue, 10 May 2011 14:12:50 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 10 May 2011 07:12:54 -0700 Message-Id: <9F80F0D3-E449-415F-B773-2EC553AAD802@cisco.com> To: core WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [core] draft-bormann-coap-misc-08 - Payload-Length options X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 14:12:52 -0000 I'd like to propose that we take the text from section 6 of this draft = defining an option to use Payload-Length options and move it to CoAP. = The main reasons I think it needs to be in the base draft is it is hard = to add later and easy to implement. Having this makes it much easier for = us to be future proof for use on non datagram transports or have = aggregation of multiple CoAP messages into a single IP datagram.=20 It also makes it easy to figure out to use CoAP in a situation where you = have a serial line between the host and proxy that is IP connected.=20 Cullen From fluffy@cisco.com Tue May 10 07:56:31 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECF2EE06AE for ; Tue, 10 May 2011 07:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.511 X-Spam-Level: X-Spam-Status: No, score=-109.511 tagged_above=-999 required=5 tests=[AWL=-1.016, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id obsv2GpuT2eh for ; Tue, 10 May 2011 07:56:31 -0700 (PDT) Received: from sj-iport-3.cisco.com (unknown [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id EFDCDE0659 for ; Tue, 10 May 2011 07:56:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=2919; q=dns/txt; s=iport; t=1305039390; x=1306248990; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=a/D2t5d11JwPa4uFu8FhOEW8+tuavFMDDV+C0bK4xbE=; b=Cl7uFdpNCU/YpWlIpUId4Da4wowXuDHLjN6xa5e+3yEXMaN1xgTBkrBm K3cnGcjRnL/+VK/nLOasHdJXv70XtVIrkMiSjhvUKid2brAkSUuV2U6Nr Ktj80Yu+5j/EMcviQmKkHinL0XX59hd+/HtbiXwTqJNoV2TgyHXDdm3DZ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMhQyU2rRDoG/2dsb2JhbAClfnemYoEdnlOGDwSGQokujn4 X-IronPort-AV: E=Sophos;i="4.64,346,1301875200"; d="scan'208";a="312446522" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-3.cisco.com with ESMTP; 10 May 2011 14:56:30 +0000 Received: from dhcp-171-68-21-134.cisco.com (dhcp-171-68-21-134.cisco.com [171.68.21.134]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p4AEuUD6022972 for ; Tue, 10 May 2011 14:56:30 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 10 May 2011 07:56:33 -0700 Message-Id: To: core WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [core] review draft-ietf-core-observe-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 14:56:32 -0000 My largest concern with this draft is around the state management. Both = how often refreshes need to be done and when state can be removed.=20 Consider a case of a light bulb that is subscribed to the value of a = light switch. The max-age for that data is likely to be under 1 second. = I would not want to see an implementation that thought it should refresh = the subscription ever 1 second. I know the draft does not say this, but = given what it does say, I can imagine implementers doing this. The = really issues is when should the refresh be done. I don't think we are = going to be able to define a default value for this that works in a wide = range of cases so I think that the set up of the observation needs to = negotiate a lower bound on the time.=20 I understand the current draft tries to use error on notification as the = signal that a subject can stop sending notifications. If there were no = intermediaries and the addresses were not reused, I see how this would = work but I can imagine cases where it will not work out well. One is = when the notification goes to a proxy that always ACKs the notify. The = proxy would then try to send the notify on and perhaps get an error but = would have no way to communicate that back to the Subject. I can imagine = a long list of other ways this could go wrong and result in subscription = state that never got cleaned up.=20 A observation implies substantial traffic over time - the overhead of = having the initial set up negotiate an refresh does not seem like it = uses up too many resources. I'd suggest the Observer suggests a time, = then the Subject provides a time that is less than or equal to the = suggestion. The Observer need to refresh before that point in time.=20 Some smaller points ...=20 When you talk about matching in section 3.2, I get what you mean by = "same security context" but this needs to be carefully defined so there = is no confusion. I think the client, not the server, needs to be in control of if the = notifications are sent confirmable or not. It's the client that = understands what it is doing with this system and how important it is = that it gets all the changes.=20 section 3.2 - need to copy retransmission timer as well as the remaining = attempts=20 Reordering=20 This is too much details that constrains the implementations more than = needed. I would say that the counter MUST increate in modulo arithmetic = and never increase my more than 2^15 in any 32 second period. Then go on = to say one way to implement this for devices where the values did not = change more frequently than 1ms was use use a 1kHz counter - or = something like that. I'm just looking to see a normative statement = around the real constraint and then an example of one simple strategy to = implement that.=20 Cullen From fluffy@cisco.com Tue May 10 07:56:32 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09AD0E0659 for ; Tue, 10 May 2011 07:56:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.545 X-Spam-Level: X-Spam-Status: No, score=-110.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-6g6EI3sFPe for ; Tue, 10 May 2011 07:56:31 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 43C3FE0681 for ; Tue, 10 May 2011 07:56:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=618; q=dns/txt; s=iport; t=1305039391; x=1306248991; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=u5Xq9gnHH3HqrhkLh7WTCVVPOHa5eRSGDaVI2Xn9yCE=; b=maBODc94IlqDYB4YLxFiyJVL6JrLwQSovFIYfw2dK9RJCU9ark0LQRTD MsxRfGkjp1q0VIQNLBykfaCCOybiMD0ck7PcoH5nw+VXDdM6Nj3TC6FZY 7k4UbOPBbRfm2XqTYQxxMVjerNbH2/lyCGiWhD/Ogt/xYPvUOK7l0Sj2l M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGhRyU2rRDoG/2dsb2JhbAClfnemaYEdnlOGDwSGQokujn4 X-IronPort-AV: E=Sophos;i="4.64,346,1301875200"; d="scan'208";a="354046492" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-2.cisco.com with ESMTP; 10 May 2011 14:56:30 +0000 Received: from dhcp-171-68-21-134.cisco.com (dhcp-171-68-21-134.cisco.com [171.68.21.134]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p4AEuUD7022972 for ; Tue, 10 May 2011 14:56:30 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 10 May 2011 07:56:35 -0700 Message-Id: <1C740476-7686-4C8E-B50D-9666A6A54D9B@cisco.com> To: core WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [core] draft-ietf-core-coap-06 Max-Age Resolution X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 14:56:32 -0000 The smallest Max-Age we can represent is 1 second. This seem too large = for many situations given many of things that involved human actions and = perception you would not want to cache this long. For example, the value = of a light switch. Yet on the other hand, not cacheing the value at all = could be really bad for some systems - particular in design where a = multicast signal causes many devices to simultaneously go and fetch the = current value of some other resource. What do people think of changing = the Max-Age resolution from 1 second to 10 ms? Cullen From fluffy@cisco.com Tue May 10 07:57:25 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65A68E0681 for ; Tue, 10 May 2011 07:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.494 X-Spam-Level: X-Spam-Status: No, score=-109.494 tagged_above=-999 required=5 tests=[AWL=-0.999, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iDNiLUj+ns3m for ; Tue, 10 May 2011 07:57:24 -0700 (PDT) Received: from sj-iport-3.cisco.com (unknown [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id C6765E0659 for ; Tue, 10 May 2011 07:57:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=608; q=dns/txt; s=iport; t=1305039444; x=1306249044; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=Dn7K8ChxZBzADdxGbWvdlsGO9TlP52UC/ri1NdCuC1k=; b=FA6uu1Gjqg8v1pGu5FFNQIxe5NWxPvFQSb1r6zqh5csQ03qzUTdtxwHd iKCUoUaYFMKW0uK8nLNzLcyBpGUBD178PyjLwC+TORdhlTsbAxKzqwrSt j9mHRZOAVVfc7iWOea2diESWE5svC4gN5fpRFT94Mf04rCWYNxSso2nme M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAN9RyU2rRDoG/2dsb2JhbAClfneoCZ5Thg8EhkKJLo5+ X-IronPort-AV: E=Sophos;i="4.64,346,1301875200"; d="scan'208";a="312446564" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-3.cisco.com with ESMTP; 10 May 2011 14:56:33 +0000 Received: from dhcp-171-68-21-134.cisco.com (dhcp-171-68-21-134.cisco.com [171.68.21.134]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p4AEuUD8022972 for ; Tue, 10 May 2011 14:56:33 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 10 May 2011 07:56:37 -0700 Message-Id: <21FB195E-D794-4B52-9B0F-43A675CB6030@cisco.com> To: core WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [core] Token or source port X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 14:57:25 -0000 When a client has multiple outstanding transactions, one approach would = be to include a token in each one, a different approach would be to do = each transaction from a different source port. WHen using DTLS, the = token is probably preferable but for UDP deployments, what should = implementors do? Creating a new flow for every transaction has the = potential to create a huge amount of state on the NATs as, unlike TCP, = there is no FIN to clean up the state on the middle boxes.=20 Thoughts on what advice the draft should offer implementors? Cullen From paduffy@cisco.com Tue May 10 08:52:33 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81A08E0691 for ; Tue, 10 May 2011 08:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.468 X-Spam-Level: X-Spam-Status: No, score=-10.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLNketEgpzKU for ; Tue, 10 May 2011 08:52:32 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id E41E2E065A for ; Tue, 10 May 2011 08:52:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paduffy@cisco.com; l=1651; q=dns/txt; s=iport; t=1305042752; x=1306252352; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to:content-transfer-encoding; bh=WcB0gI47iv6xp65NNkafxDTv+QzxkVkwXRzDFL2nNGE=; b=KRdD6EI7Sg9mHa6JFBQtYQDuxBVbrbIUOluOXrv6Sc25wvk/DcEOPiDl A5MaW/uL0mW+selbpyfziMmDjfeEMUiFTU+D7PgUO2Km4+rNLC2ssemos 6jehoVgnGpCf+Z0dcVDIsVt6BzKBs/sxYhFifuyqftMZVU6C+3vxQ6OBJ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoAIAEReyU2tJV2a/2dsb2JhbACYGo1vd6hDgngPAZtGhg8Ej3CEJ4pT X-IronPort-AV: E=Sophos;i="4.64,346,1301875200"; d="scan'208";a="354094522" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by sj-iport-2.cisco.com with ESMTP; 10 May 2011 15:52:32 +0000 Received: from [10.86.247.57] ([10.86.247.57]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p4AFqVAp029267 for ; Tue, 10 May 2011 15:52:32 GMT Message-ID: <4DC95F3F.8090905@cisco.com> Date: Tue, 10 May 2011 11:52:31 -0400 From: Paul Duffy Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: core@ietf.org References: <770C6CBC-E55E-41B2-BA92-1B161C8282A7@cisco.com> <1DA0334E-AD93-4494-A34D-B817A16A60DD@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [core] draft-ietf-core-coap-06 IF-Match Option X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: paduffy@cisco.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 15:52:33 -0000 Hi Carsten, My strong preference is to align options and methods with existing HTTP mechanisms. It goes to the translation issues. Every step taken away from HTTP means more complexity in the translation. Cheers On 5/10/2011 8:33 AM, Carsten Bormann wrote: >>> I read the text you have in the misc draft on if-match and thought it looked just right. As an individual contributor, I would suggest we take this text and move it to CoAP. I don't see a compelling reasons to add the If-None-Match. >> The only one that sounds useful is "If-None-Match: *", which allows to restrict a PUT to a "Create", similar to the way "If-Match: *" restricts it to a "Replace". "Create" actually is much more useful than "Replace" -- if you do the latter, you probably know what you are replacing, so you could give the ETag for a full "If-Match: ___". >> >> Just a thought. > Another thought is to not have an option for the * cases, but instead have two new methods: > > CREATE is like PUT with If-None-Match: * (fails if resource exists) > UPDATE is like PUT with If-Match: * (fails if resource does not exist). > > (and, of course, the PUT that doesn't care whether the resource exists). > > This leaves us with a clean If-Match Option for the UPDATE case where we do care about the ETag. > > Just a thought, bis. > > (Note that none of these need to be in the base spec, by the way. There is a reason we have moved block and observe to separate documents...) > > Gruesse, Carsten > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From kovatsch@inf.ethz.ch Tue May 10 11:14:25 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C908DE0874 for ; Tue, 10 May 2011 11:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KpRzI4FJarZi for ; Tue, 10 May 2011 11:14:25 -0700 (PDT) Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) by ietfa.amsl.com (Postfix) with ESMTP id 084D9E06FB for ; Tue, 10 May 2011 11:14:23 -0700 (PDT) Received: from CAS12.d.ethz.ch (172.31.38.212) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.1.289.1; Tue, 10 May 2011 20:14:17 +0200 Received: from MBX20.d.ethz.ch ([fe80::81a7:b7a5:50c0:df0d]) by CAS12.d.ethz.ch ([fe80::7861:4ecb:7c42:cad4%11]) with mapi id 14.01.0289.001; Tue, 10 May 2011 20:14:21 +0200 From: "Kovatsch Matthias" To: core WG Thread-Topic: zero-length options Thread-Index: AcwPO12oVqftvEC2R1yz0gUtRBkpAA== Date: Tue, 10 May 2011 18:14:20 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B5084231FC@MBX20.d.ethz.ch> Accept-Language: en-US, de-CH Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [193.10.67.50] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [core] zero-length options X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 18:14:25 -0000 Hi I guess the purpose of zero-length options is to represent a value of zero = with zero bytes. Is that right? If yes, why is it inconsistent then? Content-Type and ETag could also be zero, but their lengths must be one at = least. Uri-Port on the other hand can have a zero length, although port zer= o does not make much sense for me. Regards Matthias From trac+core@trac.tools.ietf.org Tue May 10 13:17:30 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A297E06CF for ; Tue, 10 May 2011 13:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.676 X-Spam-Level: X-Spam-Status: No, score=-104.676 tagged_above=-999 required=5 tests=[AWL=1.923, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJb-mN4gWzea for ; Tue, 10 May 2011 13:17:28 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) by ietfa.amsl.com (Postfix) with ESMTP id D3D83E067C for ; Tue, 10 May 2011 13:17:28 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QJtN2-0000Sz-4o; Tue, 10 May 2011 13:17: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 X-Trac-Project: core Date: Tue, 10 May 2011 20:17:28 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/150 Message-ID: <051.11e19e815bf80765c13befd499cd1255@trac.tools.ietf.org> X-Trac-Ticket-ID: 150 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] #150: Allow zero-length Content-Type X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 20:17:30 -0000 #150: Allow zero-length Content-Type Content-Type is listed as 1-2B. Previously, 0B did not make sense as this would represent a zero and that was the default value. Now, Content-Type no longer has a default value; hence 0 Bytes should again be allowed. Thanks Matthias! -- --------------------------------+------------------------------------------- Reporter: cabo@… | Owner: cabo@… Type: protocol defect | Status: new Priority: trivial | Milestone: Component: coap | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From cabo@tzi.org Tue May 10 13:21:23 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAD41E06CF for ; Tue, 10 May 2011 13:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.225 X-Spam-Level: X-Spam-Status: No, score=-106.225 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EMMJWGcZhnkF for ; Tue, 10 May 2011 13:21:23 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id C363AE06C3 for ; Tue, 10 May 2011 13:21: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 p4AKBMR2014513; Tue, 10 May 2011 22:11:22 +0200 (CEST) Received: from [192.168.217.101] (p5B3E63BB.dip.t-dialin.net [91.62.99.187]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 4A59F71D; Tue, 10 May 2011 22:11:22 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <55877B3AFB359744BA0F2140E36F52B5084231FC@MBX20.d.ethz.ch> Date: Tue, 10 May 2011 22:11:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <55877B3AFB359744BA0F2140E36F52B5084231FC@MBX20.d.ethz.ch> To: "Kovatsch Matthias" X-Mailer: Apple Mail (2.1084) Cc: core WG Subject: Re: [core] zero-length options X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 20:21:23 -0000 Good catch! > I guess the purpose of zero-length options is to represent a value of = zero with zero bytes. Is that right? It could also be a boolean option, but we don't have any yet. > Content-Type and ETag could also be zero, but their lengths must be = one at least. Content-Type: Bug. This was from the time we still had a default of 0: = In that case, it didn't make sense to send a zero-length zero. Now we = should enable that again. (Currently, we don't disallow leading zeros = in uints. Maybe we should fix that.) ETag is not a uint, but an opaque string. Here, we do exclude the zero-length string. (There is no strong reason for that, but it does enable an = implementation to represent the absence of an ETag with a zero-length = string.) > Uri-Port on the other hand can have a zero length, although port zero = does not make much sense for me. Right. Port 0 is somewhat unusual as it is usurped by some APIs. Probably not = a great choice of port number. Should we explicitly exclude it? RFC 3986 doesn't. Gruesse, Carsten From likepeng@huawei.com Tue May 10 18:10:37 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BEB3E06A6 for ; Tue, 10 May 2011 18:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NUIme7HsWWhN for ; Tue, 10 May 2011 18:10:36 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 82608E06A2 for ; Tue, 10 May 2011 18:10:36 -0700 (PDT) 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 <0LL000B4NB9K11@szxga05-in.huawei.com> for core@ietf.org; Wed, 11 May 2011 09:10:33 +0800 (CST) Received: from szxeml206-edg.china.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 <0LL000MGXB9K9Z@szxga05-in.huawei.com> for core@ietf.org; Wed, 11 May 2011 09:10:32 +0800 (CST) Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 11 May 2011 09:10:29 +0800 Received: from SZXEML506-MBS.china.huawei.com ([169.254.3.27]) by szxeml404-hub.china.huawei.com ([fe80::75b7:3db9:fedc:a56d%13]) with mapi id 14.01.0270.001; Wed, 11 May 2011 09:10:31 +0800 Date: Wed, 11 May 2011 01:10:31 +0000 From: Likepeng In-reply-to: <9F80F0D3-E449-415F-B773-2EC553AAD802@cisco.com> X-Originating-IP: [10.70.109.110] To: Cullen Jennings , core WG Message-id: <34966E97BE8AD64EAE9D3D6E4DEE36F2287DCB@SZXEML506-MBS.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [core] draft-bormann-coap-misc-08 - Payload-Length options Thread-index: AQHMDxyGAgtW72J5gUi9AwGHGxkb1ZSGzM1A X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <9F80F0D3-E449-415F-B773-2EC553AAD802@cisco.com> Subject: Re: [core] draft-bormann-coap-misc-08 - Payload-Length options X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 01:10:37 -0000 I agree that it is quite useful for some cases, but I prefer it to be a separate draft. (1) Because it is not needed (or at least optional) if we use UDP as transport, which is the major transport under consideration now. The information will be redundant if we can get the information from the Payload-Length Option and from the UDP layer. And it may cause problem if they are inconsistent. (2) I don't think it is good to pack more than one CoAP message into one UDP payload. It will add the complexity and I can't see too much benefit. (3) I remember it was in the base draft before, but it was removed for some reasons. FYI, this is the justification from the misc-08 for the Payload-Length: Not all transport mappings may provide an unambiguous length of the CoAP message. For UDP, it may also be desirable to pack more than one CoAP message into one UDP payload (aggregation); in that case, for all but the last message there needs to be a way to delimit the payload of that message. Kind Regards Kepeng -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Cullen Jennings Sent: Tuesday, May 10, 2011 10:13 PM To: core WG Subject: [core] draft-bormann-coap-misc-08 - Payload-Length options I'd like to propose that we take the text from section 6 of this draft defining an option to use Payload-Length options and move it to CoAP. The main reasons I think it needs to be in the base draft is it is hard to add later and easy to implement. Having this makes it much easier for us to be future proof for use on non datagram transports or have aggregation of multiple CoAP messages into a single IP datagram. It also makes it easy to figure out to use CoAP in a situation where you have a serial line between the host and proxy that is IP connected. Cullen _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From paduffy@cisco.com Tue May 10 19:32:25 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E373BE06B5 for ; Tue, 10 May 2011 19:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8 X-Spam-Level: X-Spam-Status: No, score=-8 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJTXF26h1WIh for ; Tue, 10 May 2011 19:32:25 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 895E8E0692 for ; Tue, 10 May 2011 19:32:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paduffy@cisco.com; l=210; q=dns/txt; s=iport; t=1305081145; x=1306290745; h=message-id:date:from:reply-to:mime-version:to:subject: content-transfer-encoding; bh=AFRbDsimdKz2xTsuiXfaW3CIEDjDzvFRwUeO4tpMZ0g=; b=Eido2yaawHWDf9rRTmR83GyraLTkRquXUl4hNzwoqRCzSoEavV7FmMF2 RXquDiQAu2PfwYTCa8emiiFnifYtmB+mibNFLES/Eq9uYNCIxM/gkI3KN ceUdHSoHc7mtBm29SXd/ch8ri8DKgk4/98UajfOEKsQOpmeQdXl/g3cIN k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAM70yU2rRDoH/2dsb2JhbACmDHeoO4EdgngPAZsLhg8Ej26EJ4pW X-IronPort-AV: E=Sophos;i="4.64,350,1301875200"; d="scan'208";a="312894585" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-3.cisco.com with ESMTP; 11 May 2011 02:32:15 +0000 Received: from [10.86.245.214] ([10.86.245.214]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p4B2WEoA006114 for ; Wed, 11 May 2011 02:32:15 GMT Message-ID: <4DC9F52B.1050805@cisco.com> Date: Tue, 10 May 2011 22:32:11 -0400 From: Paul Duffy Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: core Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [core] Why BLOCK option and not simply TFTP? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: paduffy@cisco.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 02:32:26 -0000 Zach / Carsten, Much appreciated if you could enlighten me re: the subject question. Feel free to point me to a prior thread. I have searched the mailer, can't seem to locate the reasoning. Cheers From likepeng@huawei.com Tue May 10 20:45:23 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34FCCE0724 for ; Tue, 10 May 2011 20:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[AWL=2.000, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1C8L9aiqyyi0 for ; Tue, 10 May 2011 20:45:22 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 2FDB8E06DB for ; Tue, 10 May 2011 20:45:22 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LL000AZHIFIQN@szxga03-in.huawei.com> for core@ietf.org; Wed, 11 May 2011 11:45:18 +0800 (CST) Received: from szxeml208-edg.china.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 <0LL000JPDIFI1J@szxga03-in.huawei.com> for core@ietf.org; Wed, 11 May 2011 11:45:18 +0800 (CST) Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 11 May 2011 11:45:14 +0800 Received: from SZXEML506-MBS.china.huawei.com ([169.254.3.27]) by SZXEML401-HUB.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0270.001; Wed, 11 May 2011 11:45:17 +0800 Date: Wed, 11 May 2011 03:45:17 +0000 From: Likepeng In-reply-to: X-Originating-IP: [10.70.109.110] To: Carsten Bormann Message-id: <34966E97BE8AD64EAE9D3D6E4DEE36F2287ED4@SZXEML506-MBS.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [core] draft-ietf-core-coap-06 Request Timeout Thread-index: AQHMDn9t/oSsCAWo/0WQe+ocxEOsBZSEXTuAgADb1fCAAEoSAIABeeeQ X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <76503846-BE4E-435B-A7B2-9AA679D17B11@cisco.com> <34966E97BE8AD64EAE9D3D6E4DEE36F228783B@SZXEML506-MBS.china.huawei.com> Cc: core WG Subject: Re: [core] draft-ietf-core-coap-06 Request Timeout X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 03:45:23 -0000 Thanks for the review. The suggestions are quite reasonable. And I will include the changes in -01. > We haven't really discussed the difference between what is Connection-Timeout in draft-thomson-hybi-http-timeout-00 and this option, which is similar to Request-Timeout in that draft. I think it is not necessary to have Connection-Timeout in CoAP, because CoAP is based on UDP, and we don't need to maintain an idle connection. Kind Regards Kepeng -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org] Sent: Tuesday, May 10, 2011 9:07 PM To: Likepeng Cc: Cullen Jennings; core WG Subject: Re: [core] draft-ietf-core-coap-06 Request Timeout On May 10, 2011, at 03:17, Likepeng wrote: > I have a draft to let the client to define a timeout in the request: > http://tools.ietf.org/id/draft-li-core-coap-response-mode-option-00.txt > > [...] > I would like to get feedback from you on the draft. Sure. 1) Get rid of the P bit. Influencing this is none of the client's business. It is not even useful for a client -- since the option is elective, the client cannot even rely on it being heeded. There is no option in TCP to control whether the peer should send its data piggybacked on an ACK either. 2) I think I like the T part of the option. However, it should be rephrased as "indicates the length of time from the time of request the response would be useful for the client". Because that's all we can say. If the server doesn't have the data, it doesn't have it. Representing T in exponential form sounds fine to me (but we have had some arguments on duration representation before). I would deliberately keep the spec open on whether the base is milliseconds or 1024s of a second -- the clocks are not going to be that precise anyway, and this might help some implementations that count in 1024s ("mibiseconds") or in whole seconds. 3) T should not have a default value. (I'm not going to repeat why that would be a mistake, see my previous messages.) 4) We also need a new response code, "can't provide the data in time". This is a code that a server that already knows it won't be able to meet the deadline can send early on. (Note that the client cannot rely on getting the response code, because the server might have failed in the meantime.) We haven't really discussed the difference between what is Connection-Timeout in draft-thomson-hybi-http-timeout-00 and this option, which is similar to Request-Timeout in that draft. Gruesse, Carsten From cabo@tzi.org Wed May 11 01:17:25 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F4D7E0686 for ; Wed, 11 May 2011 01:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A6QXnYZkDehg for ; Wed, 11 May 2011 01:17:24 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 428B7E067B for ; Wed, 11 May 2011 01:17:20 -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 p4B8H8g2029082; Wed, 11 May 2011 10:17:08 +0200 (CEST) Received: from [192.168.217.101] (p5489A8DA.dip.t-dialin.net [84.137.168.218]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 92D8C831; Wed, 11 May 2011 10:17:08 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <4DC9F52B.1050805@cisco.com> Date: Wed, 11 May 2011 10:17:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <467DDCB8-C1E7-49AD-9D44-F5F492883E5D@tzi.org> References: <4DC9F52B.1050805@cisco.com> To: paduffy@cisco.com X-Mailer: Apple Mail (2.1084) Cc: core Subject: Re: [core] Why BLOCK option and not simply TFTP? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 08:17:25 -0000 Yep, comes up repeatedly. There are a couple of reasons: 1) TFTP is trying to solve a different problem (file transfer vs. = resource access). CoAP is providing access to resources, and it is useful not to have = an artificial upper limit to the size of their representations, as well = as have a way to avoid adaptation layer fragmentation if desired. 2) TFTP is more complex and requires more state than CoAP, so I have no = idea where the "simply" comes from (unless you already had to implement = it for some other reason -- then of course just using that = implementation is "simple"). For more details, Google gives you e.g. these threads: http://www.ietf.org/mail-archive/web/core/current/msg00065.html http://www.ietf.org/mail-archive/web/core/current/msg00141.html http://www.ietf.org/mail-archive/web/core/current/msg00986.html http://www.ietf.org/mail-archive/web/core/current/msg01887.html There are links "Thread next" in the mailman archive interface, so you = can follow the thread and find the messages that discuss TFTP = specifically. BTW, if you are looking for discussions on any subject in the mailing = list, Google allows you to search within a site, e.g.: = http://www.google.com/search?q=3Dtftp+site%3Ahttp%3A%2F%2Fwww.ietf.org%2Fm= ail-archive%2Fweb%2Fcore Also, there are only about 2000 messages in the mailing list, so if you = want to become familiar with CoAP, simply scanning them is indeed a = viable option. Gruesse, Carsten From pabigot@gmail.com Wed May 11 03:44:19 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 262C5E0720 for ; Wed, 11 May 2011 03:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gmvahhtffo5k for ; Wed, 11 May 2011 03:44:18 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 55B4CE0679 for ; Wed, 11 May 2011 03:44:18 -0700 (PDT) Received: by vxg33 with SMTP id 33so289060vxg.31 for ; Wed, 11 May 2011 03:44:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=fs5t2L2HjxP1gtv+x5Lr7of4X9EOcu1y0rCKywwRquI=; b=lMnuhcCgSXgk7Bd3oijCCUMy7oVEFjl9nI9UakzG5zA+Jf0j1nOfv7DT4UEVWG1BP/ z4535pJnRr2chneh/QO1eI5FAefwpcAI2oBGvjs9rQpXM1zaHFzrbxnerwiHkjmlyrWQ lEN+Z7YvokH6XF+rX96zhb1MEsUFHm+ro+n0U= 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; b=rcHC09Fz8zxF4NH+Bo/HkhoAU3qjiAM8DfyLbI1iKyqA1601uDhhkeF0NkperK5PNy pOGJl7y81IwDU5y3MhLSRVIY/o4PcjUgdDptJH85Zot6KHBpYot21NA/1qp7yBcGikOt TTSdO/5Gm9Cc6o+m8yZ/jrkfUlSf5bHt6PWS4= MIME-Version: 1.0 Received: by 10.52.110.233 with SMTP id id9mr5851296vdb.111.1305110656782; Wed, 11 May 2011 03:44:16 -0700 (PDT) Sender: pabigot@gmail.com Received: by 10.52.113.194 with HTTP; Wed, 11 May 2011 03:44:16 -0700 (PDT) In-Reply-To: <467DDCB8-C1E7-49AD-9D44-F5F492883E5D@tzi.org> References: <4DC9F52B.1050805@cisco.com> <467DDCB8-C1E7-49AD-9D44-F5F492883E5D@tzi.org> Date: Wed, 11 May 2011 05:44:16 -0500 X-Google-Sender-Auth: mniU6O9I8YjRKHa_3yuk1HLFKqc Message-ID: From: Peter Bigot To: Carsten Bormann Content-Type: multipart/alternative; boundary=bcaec548a14d170fef04a2fdc12b Cc: core Subject: Re: [core] Why BLOCK option and not simply TFTP? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 10:44:19 -0000 --bcaec548a14d170fef04a2fdc12b Content-Type: text/plain; charset=ISO-8859-1 Perhaps the reason he couldn't find them with a search is that the reasons were never given before, at least not so clearly. Thanks for answering this. On Wed, May 11, 2011 at 3:17 AM, Carsten Bormann wrote: > Yep, comes up repeatedly. > > There are a couple of reasons: > > 1) TFTP is trying to solve a different problem (file transfer vs. resource > access). > CoAP is providing access to resources, and it is useful not to have an > artificial upper limit to the size of their representations, as well as have > a way to avoid adaptation layer fragmentation if desired. > Where does tftp artificially limit the size of the representations it could transfer? In what way is its block fragmentation solution architecturally different from CoAP's? > 2) TFTP is more complex and requires more state than CoAP, so I have no > idea where the "simply" comes from (unless you already had to implement it > for some other reason -- then of course just using that implementation is > "simple"). > I'm really not seeing this. You yourself complained that the latest base CoAP draft was 80 pages for a "protocol you could implement in an afternoon" (a claim I view with extreme doubt). RFCs 1350, 2347, and 2349 combined are 22 pages, just less than the 23 for CoAP Block which requires a CoAP implementation behind it to work. Plus, 20 years proven success at its function? IMO, it's a shame TFTP wasn't considered more seriously for CoAP's large-representation transfer needs. Peter --bcaec548a14d170fef04a2fdc12b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Perhaps the reason he couldn't find them with a search is that the reas= ons were never given before, at least not so clearly.=A0 Thanks for answeri= ng this.

On Wed, May 11, 2011 at 3:17 AM,= Carsten Bormann <cabo= @tzi.org> wrote:
Yep, comes up repeatedly.

There are a couple of reasons:

1) TFTP is trying to solve a different problem (file transfer vs. resource = access).
=A0 CoAP is providing access to resources, and it is useful not to have an= artificial upper limit to the size of their representations, as well as ha= ve a way to avoid adaptation layer fragmentation if desired.

Where does tftp artificially limit the size of the representations= it could transfer?=A0 In what way is its block fragmentation solution arch= itecturally different from CoAP's?
=A0
2) TFTP is more complex and requires more state than CoAP, so I have no ide= a where the "simply" comes from (unless you already had to implem= ent it for some other reason -- then of course just using that implementati= on is "simple").

I'm really not seeing this.=A0 You yourself compl= ained that the latest base CoAP draft was 80 pages for a=A0 "protocol = you could implement in an afternoon" (a claim I view with extreme doub= t).=A0 RFCs 1350, 2347, and 2349 combined are 22 pages, just less than the = 23 for CoAP Block which requires a CoAP implementation behind it to work.
Plus, 20 years proven success at its function?=A0 IMO, it's a shame= TFTP wasn't considered more seriously for CoAP's large-representat= ion transfer needs.

Peter
--bcaec548a14d170fef04a2fdc12b-- From zach@sensinode.com Wed May 11 04:05:10 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADDF6E07EA for ; Wed, 11 May 2011 04:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hdYExsoxOzQC for ; Wed, 11 May 2011 04:05:09 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 2856CE078C for ; Wed, 11 May 2011 04:05:08 -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 p4BB4xft028447 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 11 May 2011 14:05:00 +0300 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-192-387187658; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: Date: Wed, 11 May 2011 14:05:01 +0300 Message-Id: References: <4DC9F52B.1050805@cisco.com> <467DDCB8-C1E7-49AD-9D44-F5F492883E5D@tzi.org> To: Peter Bigot X-Mailer: Apple Mail (2.1084) Cc: core Subject: Re: [core] Why BLOCK option and not simply TFTP? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 11:05:10 -0000 --Apple-Mail-192-387187658 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 11, 2011, at 1:44 PM, Peter Bigot wrote: > Perhaps the reason he couldn't find them with a search is that the = reasons were never given before, at least not so clearly. Thanks for = answering this. >=20 > On Wed, May 11, 2011 at 3:17 AM, Carsten Bormann wrote: > Yep, comes up repeatedly. >=20 > There are a couple of reasons: >=20 > 1) TFTP is trying to solve a different problem (file transfer vs. = resource access). > CoAP is providing access to resources, and it is useful not to have = an artificial upper limit to the size of their representations, as well = as have a way to avoid adaptation layer fragmentation if desired. >=20 > Where does tftp artificially limit the size of the representations it = could transfer? In what way is its block fragmentation solution = architecturally different from CoAP's? That wasn't the point. The reason why CoAP provides an (optional) block = transfer mode is not to have an artificial upper limit (1024 bytes) to = the size of CoAP representations. In 6LoWPAN networks it is even more = important to keep the block size smaller for performance reasons. This = is also important when proxying to/from HTTP where there are no such = limits.=20 I find the TFTP conversation to be a bit silly. Why doesn't everyone on = the web use FTP for access resources and implementing REST interfaces?=20= > 2) TFTP is more complex and requires more state than CoAP, so I have = no idea where the "simply" comes from (unless you already had to = implement it for some other reason -- then of course just using that = implementation is "simple"). >=20 > I'm really not seeing this. You yourself complained that the latest = base CoAP draft was 80 pages for a "protocol you could implement in an = afternoon" (a claim I view with extreme doubt). RFCs 1350, 2347, and = 2349 combined are 22 pages, just less than the 23 for CoAP Block which = requires a CoAP implementation behind it to work. The length of the document has little to do with its complexity. There = is a ton of explanatory, tutorial and IANA etc. related information that = makes what we are doing in CoRE easier to learn for people. Anyways, it = doesn't matter as these are two different protocols. > Plus, 20 years proven success at its function? IMO, it's a shame TFTP = wasn't considered more seriously for CoAP's large-representation = transfer needs. Wait a second. TFTP and CoAP are separate protocols, and for different = purposes. If you want to transfer large *files* then I recommend that = you (you have to make that decision) go ahead and use TFTP. But TFTP = helps no more to realize resource manipulation than FTP does.=20 This is really a system design issue in the end. You may very well use = core-coap for resource access on a device, and then invoke TFTP (or = whatever) for transferring e.g. a large firmware. They are not in any = way mutually exclusive.=20 Zach=20 >=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-192-387187658 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 ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDUxMTExMDUw MlowIwYJKoZIhvcNAQkEMRYEFOYpV7ewsFb1aCwpwJhOxNS7a02+MIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAFYjfLxb6zTlKcMkpPjDdrU9BcUc7uyfiN8bnXNMD8PblVMwv+fvIcOu 0N0ZBirqZ0uMddT95dRpNXOoKpYf3OETJV4BiEHG0Kfy90XItVTr1lyPB4vFmhor4zx1MitSqzDf Xo1EE/gUEFI5jo9F9AG4drGTEIWr6NWmNCpGAYd64wxRo0Iv9YihyphMw8x4baciuEGQpGf3DLkn i/tsyrzqkspcDozM1pb/Ii78kp01qrwzgq36b69EQFpyIJjLclNvHuIh+V3L4LIs0QxtOzpF2LHb B6t2kUlcy7Yc4BdbigtvM/YHnHMpC/QuGfAsc2kLsKJG1boL9ViPz61r4UAAAAAAAAA= --Apple-Mail-192-387187658-- From pabigot@gmail.com Wed May 11 04:50:41 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD153E06F5 for ; Wed, 11 May 2011 04:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7p5JgHdDRtCm for ; Wed, 11 May 2011 04:50:40 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8FC5BE06EF for ; Wed, 11 May 2011 04:50:40 -0700 (PDT) Received: by vxg33 with SMTP id 33so331328vxg.31 for ; Wed, 11 May 2011 04:50:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ZfoR2KIYM5UPYSZK5/RfbcgtEa+y3SjnZpNa46lC9qM=; b=WOJUVW44/2ODS+/pZfIv12UF0Vq9G7+Ubh0heEAccUa3tnh6qX1JwVJpa3q7GZLPzK 0PuZXKebGR6BUQUje8uwrmAvxkkfndkoy1QLYA0Q6syYylKXrlI7UsF9zQq/gSBpmHyX +T7lXto9UGfoOB2Jeceter04W1Wq+yz1QBe+g= 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; b=x9Y/cUnbdpJX58gzsqQo5lq4fyfW929H4maoAIoWgAwQCQkFL+GECaY9zw3xxnHZxA 1kpjGxwyPTmz3+IOg6tRnnKtakXHAiD+Q+id3T8vzEYJv9tfob+FRgE5sCdbswYMnTJq i5FD6k1RVXyXY724Xw49T8RrstgUXctB7N2QI= MIME-Version: 1.0 Received: by 10.52.75.170 with SMTP id d10mr3487517vdw.231.1305114639733; Wed, 11 May 2011 04:50:39 -0700 (PDT) Sender: pabigot@gmail.com Received: by 10.52.113.194 with HTTP; Wed, 11 May 2011 04:50:39 -0700 (PDT) In-Reply-To: References: <4DC9F52B.1050805@cisco.com> <467DDCB8-C1E7-49AD-9D44-F5F492883E5D@tzi.org> Date: Wed, 11 May 2011 06:50:39 -0500 X-Google-Sender-Auth: lnt77kRRQSdMIE0DEbfiAj7PZic Message-ID: From: Peter Bigot To: Zach Shelby Content-Type: multipart/alternative; boundary=20cf3071cc727e138a04a2feae36 Cc: core Subject: Re: [core] Why BLOCK option and not simply TFTP? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 11:50:42 -0000 --20cf3071cc727e138a04a2feae36 Content-Type: text/plain; charset=ISO-8859-1 I don't want to keep rehashing things that I've failed to communicate multiple times, so one last perspective: The suite of Internet protocols has been a runaway success because the architecture encourages use of specific protocols for specific tasks that are as simple as the task allows. CoAP appears to be intended to provide an application layer for interoperable REST communications over a datagram transport. I can see no reason why it should be obliged to also supply a solution for transferring data that is larger than a datagram, when there are existing protocols that accommodate that need. Transferring a representation by reference (e.g., tftp://server/path/to/resource) is a perfectly sensible approach that allows adaptation and specialization, and is used by HTTP-based systems where appropriate (e.g., rtsp). From previous discussions the sense of the working group was that CoAP will not support redirection to other protocols. If this has not changed, I believe it to be a fundamental architectural mistake. If it has changed, TFTP is a viable alternative to CoAP Block for systems where the resource representation can exceed the datagram size. Peter On Wed, May 11, 2011 at 6:05 AM, Zach Shelby wrote: > On May 11, 2011, at 1:44 PM, Peter Bigot wrote: > > > Perhaps the reason he couldn't find them with a search is that the > reasons were never given before, at least not so clearly. Thanks for > answering this. > > > > On Wed, May 11, 2011 at 3:17 AM, Carsten Bormann wrote: > > Yep, comes up repeatedly. > > > > There are a couple of reasons: > > > > 1) TFTP is trying to solve a different problem (file transfer vs. > resource access). > > CoAP is providing access to resources, and it is useful not to have an > artificial upper limit to the size of their representations, as well as have > a way to avoid adaptation layer fragmentation if desired. > > > > Where does tftp artificially limit the size of the representations it > could transfer? In what way is its block fragmentation solution > architecturally different from CoAP's? > > That wasn't the point. The reason why CoAP provides an (optional) block > transfer mode is not to have an artificial upper limit (1024 bytes) to the > size of CoAP representations. In 6LoWPAN networks it is even more important > to keep the block size smaller for performance reasons. This is also > important when proxying to/from HTTP where there are no such limits. > > I find the TFTP conversation to be a bit silly. Why doesn't everyone on the > web use FTP for access resources and implementing REST interfaces? > > > 2) TFTP is more complex and requires more state than CoAP, so I have no > idea where the "simply" comes from (unless you already had to implement it > for some other reason -- then of course just using that implementation is > "simple"). > > > > I'm really not seeing this. You yourself complained that the latest base > CoAP draft was 80 pages for a "protocol you could implement in an > afternoon" (a claim I view with extreme doubt). RFCs 1350, 2347, and 2349 > combined are 22 pages, just less than the 23 for CoAP Block which requires a > CoAP implementation behind it to work. > > The length of the document has little to do with its complexity. There is a > ton of explanatory, tutorial and IANA etc. related information that makes > what we are doing in CoRE easier to learn for people. Anyways, it doesn't > matter as these are two different protocols. > > > Plus, 20 years proven success at its function? IMO, it's a shame TFTP > wasn't considered more seriously for CoAP's large-representation transfer > needs. > > Wait a second. TFTP and CoAP are separate protocols, and for different > purposes. If you want to transfer large *files* then I recommend that you > (you have to make that decision) go ahead and use TFTP. But TFTP helps no > more to realize resource manipulation than FTP does. > > This is really a system design issue in the end. You may very well use > core-coap for resource access on a device, and then invoke TFTP (or > whatever) for transferring e.g. a large firmware. They are not in any way > mutually exclusive. > > Zach > > > > > 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 > > --20cf3071cc727e138a04a2feae36 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I don't want to keep rehashing things that I've failed to communica= te multiple times, so one last perspective:

The suite of Internet pr= otocols has been a runaway success because the architecture encourages use = of specific protocols for specific tasks that are as simple as the task all= ows.=A0 CoAP appears to be intended to provide an application layer for int= eroperable REST communications over a datagram transport.=A0 I can see no r= eason why it should be obliged to also supply a solution for transferring d= ata that is larger than a datagram, when there are existing protocols that = accommodate that need.

Transferring a representation by reference (e.g., tftp://server/path/to= /resource) is a perfectly sensible approach that allows adaptation and spec= ialization, and is used by HTTP-based systems where appropriate (e.g., rtsp= ).=A0 From previous discussions the sense of the working group was that CoA= P will not support redirection to other protocols.=A0 If this has not chang= ed, I believe it to be a fundamental architectural mistake.=A0 If it has ch= anged, TFTP is a viable alternative to CoAP Block for systems where the res= ource representation can exceed the datagram size.

Peter

On Wed, May 11, 2011 at 6:05 AM= , Zach Shelby <z= ach@sensinode.com> wrote:
On May 11, 2011, at 1:44 PM, Peter Bigot wrote:

> Perhaps the reason he couldn't find them with a search is that the= reasons were never given before, at least not so clearly. =A0Thanks for an= swering this.
>
> On Wed, May 11, 2011 at 3:17 AM, Carsten Bormann <cabo@tzi.org> wrote:
> Yep, comes up repeatedly.
>
> There are a couple of reasons:
>
> 1) TFTP is trying to solve a different problem (file transfer vs. reso= urce access).
> =A0 CoAP is providing access to resources, and it is useful not to hav= e an artificial upper limit to the size of their representations, as well a= s have a way to avoid adaptation layer fragmentation if desired.
>
> Where does tftp artificially limit the size of the representations it = could transfer? =A0In what way is its block fragmentation solution architec= turally different from CoAP's?

That wasn't the point. The reason why CoAP provides an (optional)= block transfer mode is not to have an artificial upper limit (1024 bytes) = to the size of CoAP representations. In 6LoWPAN networks it is even more im= portant to keep the block size smaller for performance reasons. This is als= o important when proxying to/from HTTP where there are no such limits.

I find the TFTP conversation to be a bit silly. Why doesn't everyone on= the web use FTP for access resources and implementing REST interfaces?

> 2) TFTP is more complex and requires more state than CoAP, so I have n= o idea where the "simply" comes from (unless you already had to i= mplement it for some other reason -- then of course just using that impleme= ntation is "simple").
>
> I'm really not seeing this. =A0You yourself complained that the la= test base CoAP draft was 80 pages for a =A0"protocol you could impleme= nt in an afternoon" (a claim I view with extreme doubt). =A0RFCs 1350,= 2347, and 2349 combined are 22 pages, just less than the 23 for CoAP Block= which requires a CoAP implementation behind it to work.

The length of the document has little to do with its complexity. Ther= e is a ton of explanatory, tutorial and IANA etc. related information that = makes what we are doing in CoRE easier to learn for people. Anyways, it doe= sn't matter as these are two different protocols.

> Plus, 20 years proven success at its function? =A0IMO, it's a sham= e TFTP wasn't considered more seriously for CoAP's large-representa= tion transfer needs.

Wait a second. =A0TFTP and CoAP are separate protocols, and for diffe= rent purposes. If you want to transfer large *files* then I recommend that = you (you have to make that decision) go ahead and use TFTP. But TFTP helps = no more to realize resource manipulation than FTP does.

This is really a system design issue in the end. You may very well use core= -coap for resource access on a device, and then invoke TFTP (or whatever) f= or transferring e.g. a large firmware. They are not in any way mutually exc= lusive.

Zach

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


--20cf3071cc727e138a04a2feae36-- From cabo@tzi.org Wed May 11 07:10:05 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E63F0E074B for ; Wed, 11 May 2011 07:10:05 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B2RIKOSgJ9Vo for ; Wed, 11 May 2011 07:10:02 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id ACDADE074A for ; Wed, 11 May 2011 07:10:01 -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 p4BE9p9U025935; Wed, 11 May 2011 16:09:51 +0200 (CEST) Received: from [10.0.1.2] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 54AA2AE4; Wed, 11 May 2011 16:09:51 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Wed, 11 May 2011 16:09:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DC9F52B.1050805@cisco.com> <467DDCB8-C1E7-49AD-9D44-F5F492883E5D@tzi.org> To: Peter Bigot X-Mailer: Apple Mail (2.1084) Cc: core Subject: Re: [core] Why BLOCK option and not simply TFTP? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 14:10:06 -0000 Yes, the Web architecture has URIs to enable match-and-pick between = multiple protocols. However, match-and-pick should not turn into a game of Tetris. Trying to build a larger system out of one protocol that is about = manipulating resources, but cannot manipulate large objects (i.e., CoAP = without Block), with another that can handle large objects but only can = do stateful file transfer and no other methods, just creates pain. (Imagine a Web where you can't use HTTP for anything larger than, say, = 64 KiB, and need to use FTP instead. Imagine running SOAP over FTP once = you hit 64 KiB...) So, having Block in CoAP is a good thing, independent of whether TFTP = has good applications in your system design or not. As of today, we haven't put any redirect function into CoAP at all. If and when we do, we'll certainly have to look at use cases and make = sure we cover what we need. (Note that you can always carry any kind of URI in your payload. The one place where we do carry long-form URIs in a CoAP option, = Uri-Proxy, certainly does support tftp:// URIs, if you need them.) Gruesse, Carsten From kovatsch@inf.ethz.ch Wed May 11 10:12:20 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 087DFE0718 for ; Wed, 11 May 2011 10:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8eC-ZW4BY1Pk for ; Wed, 11 May 2011 10:12:18 -0700 (PDT) Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) by ietfa.amsl.com (Postfix) with ESMTP id 379C4E072B for ; Wed, 11 May 2011 10:12:14 -0700 (PDT) Received: from CAS20.d.ethz.ch (172.31.51.110) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.1.289.1; Wed, 11 May 2011 19:12:06 +0200 Received: from MBX20.d.ethz.ch ([fe80::81a7:b7a5:50c0:df0d]) by CAS20.d.ethz.ch ([fe80::2cd8:4907:7776:c56d%11]) with mapi id 14.01.0289.001; Wed, 11 May 2011 19:12:12 +0200 From: "Kovatsch Matthias" To: core Thread-Topic: draft-ietf-core-coap-06: Proxying and Uri-Port Thread-Index: AcwP+nL0paE8XWDgTyCDzhrdoyp+eQ== Date: Wed, 11 May 2011 17:12:11 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B508423876@MBX20.d.ethz.ch> Accept-Language: en-US, de-CH Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [193.10.67.50] Content-Type: multipart/alternative; boundary="_000_55877B3AFB359744BA0F2140E36F52B508423876MBX20dethzch_" MIME-Version: 1.0 Subject: [core] draft-ietf-core-coap-06: Proxying and Uri-Port X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 17:12:20 -0000 --_000_55877B3AFB359744BA0F2140E36F52B508423876MBX20dethzch_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hey there >From the text in the coap-06 draft I do not really get how the Proxy-Uri op= tion relates to the normal Uri options and what the Uri-Port option is used= for. Also the mail archive did not help much. I understood proxying this way: To issue a request via proxy, the client sets the URI in the Proxy-Uri opti= on and the proxy takes on then (forward/request to server/check if Proxy-Ur= i points to itself). Not splitting into separate options as usual is nice b= ecause any URI can be requested by CoAP clients (protocol translation...). What about the normal Uri options when the Proxy-Uri is set? Can they be of use in this case? SHOULD or MUST they be empty? What is the Uri-Port option for? Uri-Host is clear, as it enables CoAP vhosts. But there are no virtual name= s for ports!? Is it to forward requests sent to the compressed port range of 6LoWPAN to t= he "normal" server running at a different port, e.g. 5683? But in such a ca= se the server would simply listen on both ports, no? I think, I read this before and must agree, "origin server" is a quite conf= using term in the draft. Ciao Matthias --_000_55877B3AFB359744BA0F2140E36F52B508423876MBX20dethzch_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hey there

 <= /p>

From the t= ext in the coap-06 draft I do not really get how the Proxy-Uri option relat= es to the normal Uri options and what the Uri-Port option is used for. Also the mail archive did not help much.

 = ;

 = ;

I understo= od proxying this way:

To issue a= request via proxy, the client sets the URI in the Proxy-Uri option and the= proxy takes on then (forward/request to server/check if Proxy-Uri points to itself). Not splitting into separate options as usual is nice be= cause any URI can be requested by CoAP clients (protocol translation...).

What about= the normal Uri options when the Proxy-Uri is set?

Can they b= e of use in this case?

SHOULD or = MUST they be empty?

 = ;

 = ;

What is th= e Uri-Port option for?

Uri-Host i= s clear, as it enables CoAP vhosts. But there are no virtual names for port= s!?

Is it to f= orward requests sent to the compressed port range of 6LoWPAN to the “= normal” server running at a different port, e.g. 5683? But in such a case the server would simply listen on both ports, no?=

 = ;

 = ;

I think, I= read this before and must agree, “origin server” is a quite co= nfusing term in the draft.

 = ;

Ciao<= /o:p>

Matthias

 = ;

--_000_55877B3AFB359744BA0F2140E36F52B508423876MBX20dethzch_-- From paduffy@cisco.com Wed May 11 10:38:33 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BAA0E085D for ; Wed, 11 May 2011 10:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fJ42sPLjFS7n for ; Wed, 11 May 2011 10:38:31 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id BA660E0704 for ; Wed, 11 May 2011 10:38:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paduffy@cisco.com; l=6633; q=dns/txt; s=iport; t=1305135511; x=1306345111; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=cOfSqWBBj7/iqJcy1fsvCpmF+qPMMMUkXM9xS9/sFQc=; b=TsDkYeFtslHuWF5kZBZ+BHeWwsrgcaC7T90wrI28gDOfYOD45Wa0z/fI qZjIj9vEN+5WEyj5Jz0wzC5LiDZUdQ2L7WlxbvgHGQq7BRqEhCgxKTsJj zuMs+nTYpZYsUEl3OfaKEnaZrc4Hw2RZtOvj4rHDCVu32YbqIbqMPg9PM A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANzIyk2rRDoJ/2dsb2JhbACmA3eqHYJ4DwGbJYYQBI9whCeKVg X-IronPort-AV: E=Sophos;i="4.64,353,1301875200"; d="scan'208,217";a="313439608" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 11 May 2011 17:38:31 +0000 Received: from [161.44.66.248] (dhcp-161-44-66-248.cisco.com [161.44.66.248]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p4BHcUOJ019896; Wed, 11 May 2011 17:38:30 GMT Message-ID: <4DCAC997.5080504@cisco.com> Date: Wed, 11 May 2011 13:38:31 -0400 From: Paul Duffy Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Carsten Bormann References: <4DC9F52B.1050805@cisco.com> <467DDCB8-C1E7-49AD-9D44-F5F492883E5D@tzi.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070205050002030508090203" Cc: core Subject: Re: [core] Why BLOCK option and not simply TFTP? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: paduffy@cisco.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 17:38:33 -0000 This is a multi-part message in MIME format. --------------070205050002030508090203 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Thanks Carsten, This was the same info I'd previously read ;) At first glance, COAP BLOCK option smells an awful lot like a TFTP implementation. - I don't see TFTP being any more or less stateful that COAP. - I don't see any difference between a "resource" and "file" designation. They are all resources. - TFTP does provide the Blocksize option to control fragmentation. That said, what does appear compelling about the BLOCK option ... - all the RESTful methods are available via COAP versus just read/write of TFTP. I can delete a large resource using COAP, I can't do that via TFTP. - Using BLOCK, whatever COAP security mechanisms are in place can be applied to the resource transfer. Cheers On 5/11/2011 6:44 AM, Peter Bigot wrote: > Perhaps the reason he couldn't find them with a search is that the > reasons were never given before, at least not so clearly. Thanks for > answering this. > > On Wed, May 11, 2011 at 3:17 AM, Carsten Bormann > wrote: > > Yep, comes up repeatedly. > > There are a couple of reasons: > > 1) TFTP is trying to solve a different problem (file transfer vs. > resource access). > CoAP is providing access to resources, and it is useful not to > have an artificial upper limit to the size of their > representations, as well as have a way to avoid adaptation layer > fragmentation if desired. > > > Where does tftp artificially limit the size of the representations it > could transfer? In what way is its block fragmentation solution > architecturally different from CoAP's? > > 2) TFTP is more complex and requires more state than CoAP, so I > have no idea where the "simply" comes from (unless you already had > to implement it for some other reason -- then of course just using > that implementation is "simple"). > > > I'm really not seeing this. You yourself complained that the latest > base CoAP draft was 80 pages for a "protocol you could implement in > an afternoon" (a claim I view with extreme doubt). RFCs 1350, 2347, > and 2349 combined are 22 pages, just less than the 23 for CoAP Block > which requires a CoAP implementation behind it to work. > > Plus, 20 years proven success at its function? IMO, it's a shame TFTP > wasn't considered more seriously for CoAP's large-representation > transfer needs. > > Peter --------------070205050002030508090203 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Thanks Carsten,

This was the same info I'd previously read ;)

At first glance, COAP BLOCK option smells an awful lot like a TFTP implementation.

- I don't see TFTP being any more or less stateful that COAP.
- I don't see any difference between a "resource" and "file" designation.  They are all resources.
- TFTP does provide the Blocksize option to control fragmentation.

That said, what does appear compelling about the BLOCK option ...

- all the RESTful methods are available via COAP versus just read/write of TFTP.  I can delete a large resource using COAP, I can't do that via TFTP.
- Using BLOCK, whatever COAP security mechanisms are in place can be applied to the resource transfer.

Cheers


On 5/11/2011 6:44 AM, Peter Bigot wrote:
Perhaps the reason he couldn't find them with a search is that the reasons were never given before, at least not so clearly.  Thanks for answering this.

On Wed, May 11, 2011 at 3:17 AM, Carsten Bormann <cabo@tzi.org> wrote:
Yep, comes up repeatedly.

There are a couple of reasons:

1) TFTP is trying to solve a different problem (file transfer vs. resource access).
  CoAP is providing access to resources, and it is useful not to have an artificial upper limit to the size of their representations, as well as have a way to avoid adaptation layer fragmentation if desired.

Where does tftp artificially limit the size of the representations it could transfer?  In what way is its block fragmentation solution architecturally different from CoAP's?
 
2) TFTP is more complex and requires more state than CoAP, so I have no idea where the "simply" comes from (unless you already had to implement it for some other reason -- then of course just using that implementation is "simple").

I'm really not seeing this.  You yourself complained that the latest base CoAP draft was 80 pages for a  "protocol you could implement in an afternoon" (a claim I view with extreme doubt).  RFCs 1350, 2347, and 2349 combined are 22 pages, just less than the 23 for CoAP Block which requires a CoAP implementation behind it to work.

Plus, 20 years proven success at its function?  IMO, it's a shame TFTP wasn't considered more seriously for CoAP's large-representation transfer needs.

Peter

--------------070205050002030508090203-- From prvs=2112fb0a35=fewilhoit@aep.com Wed May 11 10:42:30 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4C4CE06D5 for ; Wed, 11 May 2011 10:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bf5xk+n2o1q9 for ; Wed, 11 May 2011 10:42:30 -0700 (PDT) Received: from mail7.aep.com (mail7.aep.com [167.239.223.109]) by ietfa.amsl.com (Postfix) with ESMTP id E65A2E06C6 for ; Wed, 11 May 2011 10:42:29 -0700 (PDT) Received: from pps.filterd (mail7 [127.0.0.1]) by mail7 (8.14.3/8.14.3) with SMTP id p4BHZ6cI012340 for ; Wed, 11 May 2011 13:42:28 -0400 Received: from dsml1dev.aepsc.com ([10.97.175.251]) by mail7.aepsc.com with ESMTP id w7w5594pd-1 for ; Wed, 11 May 2011 13:42:28 -0400 X-KeepSent: A3C8300A:183D9E63-8525788D:005F8F8E; type=4; name=$KeepSent To: core X-Mailer: Lotus Notes Release 8.5.2 August 10, 2010 From: fewilhoit@aep.com Message-ID: Date: Wed, 11 May 2011 13:42:06 -0400 X-MIMETrack: Serialize by Router on DSML1DEV/SERVERS/AEPIN(Release 8.5.1FP4|July 25, 2010) at 05/11/2011 13:42:27 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-05-11_07:2011-05-11, 2011-05-11, 1970-01-01 signatures=0 Subject: [core] comments on draft-ietf-core-coap-06 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 17:42:30 -0000 Detailed comments in document order: Abstract: "...a specialized web transfer protocol..." CoAP is a pair of protocols, one of which is a transfer protocol; cf. Section 2 and see below. Section 3.1. : 16-bit message ID will be insufficient. Here is a hypothetical but realistic example. The physical layer is a RF mesh network with a single-hop timeout of five minutes, such that a round trip might take as much as ten minutes + slop. A central actor (think an AMI head-end system) polls a group of >= 65537 meters, transmitting one request message every nine milliseconds. Section 3.2. : The option-number delta scheme is reminiscent of ISO 8583. It complicates parser design significantly, in exchange for a very small savings of bandwidth. Section 4.1., third graf : Somewhere in here, the strategy for handling duplicate and orphan ACKs or RSTs should be defined explicitly. Section 4.2., second graf : "A sender MAY choose to transmit a non-confirmable message multiple times which, for this purpose, specifies a Message ID as well. The same rules for generating the Message ID apply." These two sentences, taken together, are entirely unclear. I think you mean that the retransmissions MUST have the same Message ID, but it is easy to read the passage in the opposite sense. Section 4.3.4. : The example implies -- correctly! -- that the sole purpose of RST is to indicate a failure within the protocol-terminating component, such that the message cannot even be passed on to an application. In other words, RST is not to be used to report application errors. A well-formed message that is received and processed by an application, but which (for example) contains nonsense actuals and is therefore rejected by the application logic, would NOT be replied to with an RST, but with an ACK with a response code in the > 128 range . This is the correct strategy and should be stated explicitly and prescriptively here. passim, the Token option : The token is a correlator and may as well be named so; the word "token" is nonspecific, but this thing has only one purpose. It is not clear why a correlator should be allowed to be up to four times wider than the message ID. Perhaps it is intended to be potentially human-readable? Section 5.2.2, second graf : Grammar. "The server may either initiate ...or immediately send..." Section 5.3., last graf : I would have expected the guidance to be at least "SHOULD silently discard", if not MUST, as the RST is a security leak. Section 5.4.1., page 24, second bullet : (Quite generally, a "must understand" semantic is bad magic.) This is, again, a security leak. All an attacker has to do is define an option with a high odd number and collect his "human-readable" error message, from which lots of things (implementation platform/tool chain, etc.) might be deducible. Better to say "bad option" and nothing more. (This reasoning also applies to all of the unhappy response codes defined in 5.9.2 and 5.9.3. A debug mode, including informative error messages, could be defined for trusted environments, including field service using physically isolated ports.) Global comments: What is the problem? Is it constrainedness, or it is connectedness, or is it bandwidth, or it is some pair of those three, or is it all three? I have been lurking on the ZigBee mailing lists and it appears to me that the problem with TCP in the ZigBee context is primarily a connectedness problem. TCP made very few assumptions for a thing of its kind, but the assumptions it did make (of course, silently and unawares) have to do with connectedness and the ZigBee scenarios are a poor fit with those assumptions. So: ZigBee sems to need an alternative to TCP at layer 4. CoAP is two protocols; let us call them Constrained Transfer Protocol (CoTP) and Constrained Session Protocol (CoSP), where CoTP is the TCP replacement and CoSP is the featherweight quasi-HTTP . When you say that HTTP could ride over CoAP, you are really saying that it could ride over CoTP; when you say that CoAP could ride on top of TCP, you are really talking about CoSP. These distinctions deserve to be made. BUT: if connectedness is the problem, then CoAP versus TCP may be a tossup, because CoAP assumes a competent name service and a lot of the connectedness issues that arise in the ZigBee context seem to have to do with name service over a semi-connected network. The version field and the message ID both need to be wider and widening them isn't going to have any crippling effects. The option-numbering scheme is ugly. I haven't taken the time to prove this, but I think it is going to make it impossible to generate a parser from an abstract grammar. I wasn't able to generate a parser for ISO 8583 and I think you are going to have the same kind of problem. (ISO 8583 has a bitmask of possible options, then *some* of the options are length-tagged and others are fixed-length. You're not quite that badly off, but it is a similar kind of thing.) This is tied in with the two-bit (in all senses) version number, because that is why you have to have the option registry. Adding options is versioning the protocol, but there can only ever be three versions of the protocol and there will obviously be more than three new options added over time. Because CoAP breaks new ground, versioning the protocol must be easy and safe. The must-understand semantic is another needless complication here; it prevents a clear understanding of compatible change. But in any case, factoring the options out into a registry doesn't help; adding an option is still a version, because the option set is an enumerated type and adding a value to an enumerated type is not a compatible change. Thanks, Frank Wilhoit Information Architect Enterprise Architecture and Strategy American Electric Power Direct Dial 614.716.3878 Audinet 8.200.3878 Scraping the bottom of a different barrel, since 1958. From paduffy@cisco.com Wed May 11 10:48:27 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A12F5E087C for ; Wed, 11 May 2011 10:48:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5GLvL6EfF2Et for ; Wed, 11 May 2011 10:48:26 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 77ABBE0878 for ; Wed, 11 May 2011 10:48:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paduffy@cisco.com; l=6535; q=dns/txt; s=iport; t=1305136106; x=1306345706; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to:content-transfer-encoding; bh=AyP/44pSo3hzM5qqiVfgzrhowKCXlmHg/BjorSMesqg=; b=E47JKztYo4EwvILbyqgPsMnOjejUN9QuXLpOCM8Et1ioBCqKa2pr1iKq ThMDYewUQV6ykz7u4XuyJWRdkdJG+3ANc4KTspms0e6EyTr2m1kj4iYse 4JzGWR4OeFQUi8TCYEeLcgMVKYuGQOt82tm8bRSAgBTixCdXo8AnaTjNi o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAC/Lyk2rRDoH/2dsb2JhbACmA3eIcKE2gngPAZslgyaCagSPcIQnilY X-IronPort-AV: E=Sophos;i="4.64,353,1301875200"; d="scan'208";a="313446177" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-3.cisco.com with ESMTP; 11 May 2011 17:48:26 +0000 Received: from [161.44.66.248] (dhcp-161-44-66-248.cisco.com [161.44.66.248]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p4BHmOlS009644 for ; Wed, 11 May 2011 17:48:24 GMT Message-ID: <4DCACBE9.1030502@cisco.com> Date: Wed, 11 May 2011 13:48:25 -0400 From: Paul Duffy Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: core@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [core] comments on draft-ietf-core-coap-06 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: paduffy@cisco.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 17:48:27 -0000 On 5/11/2011 1:42 PM, fewilhoit@aep.com wrote: > Detailed comments in document order: > > Abstract: "...a specialized web transfer protocol..." CoAP is a pair of > protocols, one of which is a transfer protocol; cf. Section 2 and see > below. > > Section 3.1. : 16-bit message ID will be insufficient. Here is a > hypothetical but realistic example. The physical layer is a RF mesh > network with a single-hop timeout of five minutes, such that a round trip > might take as much as ten minutes + slop. A central actor (think an AMI > head-end system) polls a group of>= 65537 meters, transmitting one request > message every nine milliseconds. > > Section 3.2. : The option-number delta scheme is reminiscent of ISO 8583. > It complicates parser design significantly, in exchange for a very small > savings of bandwidth. I also found the option-number delta scheme to be overly clever ;) > Section 4.1., third graf : Somewhere in here, the strategy for handling > duplicate and orphan ACKs or RSTs should be defined explicitly. > > Section 4.2., second graf : "A sender MAY choose to transmit a > non-confirmable message multiple times which, for this purpose, specifies a > Message ID as well. The same rules for generating the Message ID apply." > These two sentences, taken together, are entirely unclear. I think you > mean that the retransmissions MUST have the same Message ID, but it is easy > to read the passage in the opposite sense. > > Section 4.3.4. : The example implies -- correctly! -- that the sole > purpose of RST is to indicate a failure within the protocol-terminating > component, such that the message cannot even be passed on to an > application. In other words, RST is not to be used to report application > errors. A well-formed message that is received and processed by an > application, but which (for example) contains nonsense actuals and is > therefore rejected by the application logic, would NOT be replied to with > an RST, but with an ACK with a response code in the> 128 range . This is > the correct strategy and should be stated explicitly and prescriptively > here. > > passim, the Token option : The token is a correlator and may as well be > named so; the word "token" is nonspecific, but this thing has only one > purpose. It is not clear why a correlator should be allowed to be up to > four times wider than the message ID. Perhaps it is intended to be > potentially human-readable? > > Section 5.2.2, second graf : Grammar. "The server may either initiate > ...or immediately send..." > > Section 5.3., last graf : I would have expected the guidance to be at > least "SHOULD silently discard", if not MUST, as the RST is a security > leak. > > Section 5.4.1., page 24, second bullet : (Quite generally, a "must > understand" semantic is bad magic.) This is, again, a security leak. All > an attacker has to do is define an option with a high odd number and > collect his "human-readable" error message, from which lots of things > (implementation platform/tool chain, etc.) might be deducible. Better to > say "bad option" and nothing more. (This reasoning also applies to all of > the unhappy response codes defined in 5.9.2 and 5.9.3. A debug mode, > including informative error messages, could be defined for trusted > environments, including field service using physically isolated ports.) > > Global comments: > > What is the problem? Is it constrainedness, or it is connectedness, or is > it bandwidth, or it is some pair of those three, or is it all three? I > have been lurking on the ZigBee mailing lists and it appears to me that the > problem with TCP in the ZigBee context is primarily a connectedness > problem. TCP made very few assumptions for a thing of its kind, but the > assumptions it did make (of course, silently and unawares) have to do with > connectedness and the ZigBee scenarios are a poor fit with those > assumptions. > > So: ZigBee sems to need an alternative to TCP at layer 4. CoAP is two > protocols; let us call them Constrained Transfer Protocol (CoTP) and > Constrained Session Protocol (CoSP), where CoTP is the TCP replacement and > CoSP is the featherweight quasi-HTTP . When you say that HTTP could ride > over CoAP, you are really saying that it could ride over CoTP; when you say > that CoAP could ride on top of TCP, you are really talking about CoSP. > These distinctions deserve to be made. > > BUT: if connectedness is the problem, then CoAP versus TCP may be a tossup, > because CoAP assumes a competent name service and a lot of the > connectedness issues that arise in the ZigBee context seem to have to do > with name service over a semi-connected network. > > The version field and the message ID both need to be wider and widening > them isn't going to have any crippling effects. > > The option-numbering scheme is ugly. I haven't taken the time to prove > this, but I think it is going to make it impossible to generate a parser > from an abstract grammar. I wasn't able to generate a parser for ISO 8583 > and I think you are going to have the same kind of problem. (ISO 8583 has > a bitmask of possible options, then *some* of the options are length-tagged > and others are fixed-length. You're not quite that badly off, but it is a > similar kind of thing.) > > This is tied in with the two-bit (in all senses) version number, because > that is why you have to have the option registry. Adding options is > versioning the protocol, but there can only ever be three versions of the > protocol and there will obviously be more than three new options added over > time. Because CoAP breaks new ground, versioning the protocol must be easy > and safe. The must-understand semantic is another needless complication > here; it prevents a clear understanding of compatible change. But in any > case, factoring the options out into a registry doesn't help; adding an > option is still a version, because the option set is an enumerated type and > adding a value to an enumerated type is not a compatible change. > > Thanks, > > Frank Wilhoit > Information Architect > Enterprise Architecture and Strategy > American Electric Power > Direct Dial 614.716.3878 > Audinet 8.200.3878 > > Scraping the bottom of a different barrel, since 1958. > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From therbst@silverspringnet.com Wed May 11 11:27:01 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E999BE0866 for ; Wed, 11 May 2011 11:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jEkxwgUv3d71 for ; Wed, 11 May 2011 11:27:01 -0700 (PDT) Received: from it-ipcorp-01.silverspringnet.com (it-ipcorp-01.silverspringnet.com [74.121.22.25]) by ietfa.amsl.com (Postfix) with ESMTP id 822F3E0849 for ; Wed, 11 May 2011 11:27:01 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au0GAJnUyk0KyAE+/2dsb2JhbACCZYcWnH/IOIYQBIZDjXGKPQ X-IronPort-AV: E=Sophos;i="4.64,354,1301900400"; d="scan'208,217";a="4389712" Received: from unknown (HELO IT-EXCA-02.silverspringnet.com) ([10.200.1.62]) by it-ipcorp-01.silverspringnet.com with ESMTP/TLS/AES128-SHA; 11 May 2011 11:27:00 -0700 Received: from IT-EXMB-01.silverspringnet.com ([fe80::b81e:2d5b:d263:6c44]) by IT-EXCA-02.silverspringnet.com ([::1]) with mapi; Wed, 11 May 2011 11:27:00 -0700 From: Thomas Herbst To: core Date: Wed, 11 May 2011 11:26:59 -0700 Thread-Topic: draft-ietf-core-coap-06: separate response Thread-Index: AcwQCQRArnx1hN4qTGqNWMZXgMY5NQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C9F02303AB1Ctherbstsilverspringnetcom_" MIME-Version: 1.0 Subject: [core] draft-ietf-core-coap-06: separate response X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 18:27:02 -0000 --_000_C9F02303AB1Ctherbstsilverspringnetcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Two comments - First, it doesn=92t seem to proxy to http cleanly. If the coap server does= not provide a response in bounded time, how is the http proxy to provide a= response to its client? Ignoring the proxy issue for a minute, an open ended response time seems pr= oblematic for battery powered radio devices staying on for the response. Could it either be bounded or give a specific time window in the future whe= n the response might be returned so the battery device might sleep until th= e server replies? tom --_000_C9F02303AB1Ctherbstsilverspringnetcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Two comments - 
=
First, it doesn=92t seem to proxy to http cleanly.  If = the coap server does not provide a response in bounded time, how is the htt= p proxy to provide a response to its client?

Ignor= ing the proxy issue for a minute, an open ended response time seems problem= atic for battery powered radio devices staying on for the response.
Could it either be bounded or give a specific time window in the future = when the response might be returned so the battery device might sleep until= the server replies?

tom

--_000_C9F02303AB1Ctherbstsilverspringnetcom_-- From therbst@silverspringnet.com Wed May 11 11:28:33 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75949E0823 for ; Wed, 11 May 2011 11:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.148 X-Spam-Level: X-Spam-Status: No, score=-1.148 tagged_above=-999 required=5 tests=[AWL=-1.450, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, MANGLED_BEST=2.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VM7MEt33Juez for ; Wed, 11 May 2011 11:28:32 -0700 (PDT) Received: from it-ipcorp-01.silverspringnet.com (it-ipcorp-01.silverspringnet.com [74.121.22.25]) by ietfa.amsl.com (Postfix) with ESMTP id 73594E07EB for ; Wed, 11 May 2011 11:28:32 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAJnUyk0KyAE8/2dsb2JhbACCZaQVyDiCLXmCagSGQ41xij0 X-IronPort-AV: E=Sophos;i="4.64,354,1301900400"; d="scan'208,217";a="4389739" Received: from unknown (HELO IT-EXCA-01.silverspringnet.com) ([10.200.1.60]) by it-ipcorp-01.silverspringnet.com with ESMTP/TLS/AES128-SHA; 11 May 2011 11:28:32 -0700 Received: from IT-EXMB-01.silverspringnet.com ([fe80::b81e:2d5b:d263:6c44]) by IT-EXCA-01.silverspringnet.com ([::1]) with mapi; Wed, 11 May 2011 11:28:31 -0700 From: Thomas Herbst To: "robert.cragie@gridmerge.com" , "core@ietf.org" Date: Wed, 11 May 2011 11:28:30 -0700 Thread-Topic: [core] draft-ietf-core-coap-06 The CoAP/DTLS/CoAP Turkey Sandwich layer violation train wreck Thread-Index: AcwQCTrHjCKz4vHiTxmnUhmcxV5wog== Message-ID: In-Reply-To: <4DC943E8.2040901@gridmerge.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C9F02359AB1Ftherbstsilverspringnetcom_" MIME-Version: 1.0 Subject: Re: [core] draft-ietf-core-coap-06 The CoAP/DTLS/CoAP Turkey Sandwich layer violation train wreck X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 18:28:33 -0000 --_000_C9F02359AB1Ftherbstsilverspringnetcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 From: Robert Cragie > Reply-To: "robert.cragie@gridmerge.com"= > Date: Tue, 10 May 2011 06:55:52 -0700 To: "core@ietf.org" > Subject: Re: [core] draft-ietf-core-coap-06 The CoAP/DTLS/CoAP Turkey Sandw= ich layer violation train wreck I have never seen what the issue is with using two ports like HTTPS: * One port for CoAP over UDP * One port for CoAP over DTLS over UDP 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 06/05/2011 8:49 AM, Eric Rescorla wrote: On Thu, May 5, 2011 at 6:24 PM, Carsten Bormann wrote: On May 6, 2011, at 02:51, Eric Rescorla wrote: 1. Use STUN as-is. Yep, we are doing that. (The escaping stuff is insurance for a case that is rather unlikely. We co= uld take it out.) What is the status about STUN coexisting with DTLS? As far as I know, there's no problem, since the leading bytes plus cookies = make collisions very unlikely. 2. Use a leading framing byte to distinguish DTLS and CoAP from STUN. If you're really worried about compactiness, (Yes, we are.) then pick only a single value to distinguish DTLS (e.g., 0xffffffff) (That would be a bit long.) Sorry, brain failure. 0xff and use all the remaining values to give you a little more room in the rest of the pack= et. Sure, we could do that. It would mean spending another byte for all DTLS p= ackets. Right. My argument is that that's not that big a deal because it only increases space by ~5%. More importantly, it also means DTLS packets no longer look like DTLS packe= ts, which complicates debugging. Yes, I agree that that's suboptimal. That's why I prefer separate ports... The material you're quoting above is just some other thoughts for dealing w= ith the same port if people insist. I would like to learn more about your plans to expand the DTLS ContentType = space. This hasn't changed since 1996. Of course, it could, next month. Again, the escaping stuff is insurance for this case. We could take it out= . I don't think there are any immediate plans to do so--though note that http://tools.ietf.org/html/draft-seggelmann-tls-dtls-heartbeat-01 does contemplate one addition. And I would assume that we intend to assign the content-types towards the bottom of the range first. That said, I don't think TLS-WG has by any means decided to commit to not assigning a bunch more types. Bes,t -Ekr _______________________________________________ core mailing list core@ietf.orghttps://www.ietf.org/mailman/listinfo/co= re --_000_C9F02359AB1Ftherbstsilverspringnetcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
+1

<= span id=3D"OLK_SRC_BODY_SECTION">
From: Robert Cragie <robert.cragie@gridmerge.com>= ;
Reply-To: "robert.cragie@gridmerge.com" <robert.cragie@gridmerge.com>=
Date: Tue, 10 May 2011 06:55:5= 2 -0700
To: "core@ietf.org" <core= @ietf.org>
Subject: Re: = [core] draft-ietf-core-coap-06 The CoAP/DTLS/CoAP Turkey Sandwich layer vio= lation train wreck

=20 =20 =20
I have never seen what the issue is with using two ports like HTTPS:
  • One port for CoAP over UDP
  • One port for CoAP over DTLS over UDP

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<= /p>


On 06/05/2011 8:49 AM, Eric Rescorla wrote: 
On Thu, May 5, 2011 at 6:24 PM, Carsten Bormann <cabo@tzi.org&=
gt; wrote:

On May 6, 2011, at 02:51, Eric Rescorla wrote:


1. Use STUN as-is.

Yep, we are doing that.
(The escaping stuff is insurance for a case that is rather unlikely.  =
We could take it out.)

What is the status about STUN coexisting with DTLS?

As far as I know, there's no problem, since the leadin=
g bytes plus cookies make
collisions very unlikely.



2. Use a leading framing byte to distinguish DTLS =
and CoAP from STUN.
If you're really worried
about compactiness,

(Yes, we are.)


then pick only a single value to distinguish DTLS
(e.g., 0xffffffff)

(That would be a bit long.)

Sorry, brain failure. 0xff



and use all
the remaining values to give you a little more room in the rest of the pack=
et.

Sure, we could do that.  It would mean spending=
 another byte for all DTLS packets.

Right. My argument is that that's not that big a deal =
because it only
increases space
by ~5%.



More importantly, it also means DTLS packets no long=
er look like DTLS packets, which complicates debugging.

Yes, I agree that that's suboptimal. That's why I pref=
er separate ports...
The material you're quoting above is just some other thoughts for dealing w=
ith
the same port if people insist.



I would like to learn more about your plans to expan=
d the DTLS ContentType space.
This hasn't changed since 1996.  Of course, it could, next month.
Again, the escaping stuff is insurance for this case.  We could take i=
t out.

I don't think there are any immediate plans to do so--=
though note that
http://tools.ietf.org/html/draft-seggelm=
ann-tls-dtls-heartbeat-01
does contemplate one addition. And I would assume that we intend to
assign the content-types towards the bottom of the range first. That said,
I don't think TLS-WG has by any means decided to commit to not
assigning a bunch more types.

Bes,t
-Ekr
_______________________________________________
core mailing list
core@ie=
tf.orghttps://www.ietf.org/mailman/listinfo/core
--_000_C9F02359AB1Ftherbstsilverspringnetcom_-- From cabo@tzi.org Wed May 11 12:13:36 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98D66E0866 for ; Wed, 11 May 2011 12:13:36 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GllMjUsIbR+T for ; Wed, 11 May 2011 12:13:35 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 138BFE066E for ; Wed, 11 May 2011 12:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id p4BJDQPd009431; Wed, 11 May 2011 21:13:26 +0200 (CEST) Received: from [192.168.217.112] (p5489A8DA.dip.t-dialin.net [84.137.168.218]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 4C0FEC42; Wed, 11 May 2011 21:13:26 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: Date: Wed, 11 May 2011 21:13:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Thomas Herbst X-Mailer: Apple Mail (2.1084) Cc: core Subject: Re: [core] draft-ietf-core-coap-06: separate response X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 19:13:36 -0000 > First, it doesn=92t seem to proxy to http cleanly. If the coap server = does not provide a response in bounded time, how is the http proxy to = provide a response to its client? The answer to this question is unrelated to the subject of this message = (see PS). HTTP does not make any promises with respect to the speed of response. = Neither does CoAP. Maps perfectly. (Excepting the special case of HTTP long poll, which we don't need in = CoAP since we have -observe:) The assumption, of course, is that the response will come reasonably = fast. Whatever is reasonable for the application. > Ignoring the proxy issue for a minute, an open ended response time = seems problematic for battery powered radio devices staying on for the = response. > Could it either be bounded or give a specific time window in the = future when the response might be returned so the battery device might = sleep until the server replies? Kepeng's draft gives a way to provide a bound. Of course, this is = supplied from the client side. A bound (or time window) supplied from the server side is more = interesting for the problem you describe. However, doing it the way you describe it would require an extension of = the simple request-response state machine. One different way to do this is: 5.9.3.4. 5.03 Service Unavailable Like HTTP 503 "Service Unavailable", but using the Max-Age Option in place of the "Retry-After" header field. (This, of course, requires another request after the max-age times out, = so it is not exactly what you are asking for. Extending -observe to be = able to catch up after a 5.03 or a special variant of it would solve = this.) Gruesse, Carsten PS.: As a protocol designer and spec writer, I find it interesting that all = these questions about timing regularly come up in the context of = separate responses, which don't really change much in the timing, but = just provide a way for the server to forego piggybacking in order to = enable the client to stop retransmitting while waiting... Somebody = should write a thesis about what we can learn from this aspect of spec = reception. From cabo@tzi.org Wed May 11 12:15:18 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 453F7E066E for ; Wed, 11 May 2011 12:15:18 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LGvfWP6X0APW for ; Wed, 11 May 2011 12:15:17 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 13E1EE0740 for ; Wed, 11 May 2011 12:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id p4BJF6kX011577; Wed, 11 May 2011 21:15:06 +0200 (CEST) Received: from [192.168.217.112] (p5489A8DA.dip.t-dialin.net [84.137.168.218]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 0F5BAC43; Wed, 11 May 2011 21:15:05 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Wed, 11 May 2011 21:15:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <99F6E31B-6620-4875-A95C-4F0FA1BB445E@tzi.org> References: To: Cullen Jennings X-Mailer: Apple Mail (2.1084) Cc: core WG Subject: Re: [core] draft-ietf-core-coap-06 Miscellaneous Things X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 19:15:18 -0000 On May 5, 2011, at 04:52, Cullen Jennings wrote: > I think you need to describe how to mapping large HTTP ETags > to CoAP ETag options. You also should address the differences > of strong and weak etags. All CoAP ETags are strong. If we assume that a client always uses the same intermediary to access a server, it is not necessary to define this (the mapping becomes a local implementation detail). Can we assume that? For forward proxies, that may be fine. For reverse proxies, it is the job of the reverse proxies to coordinate their ETags. (In section 8.1, there should also be a single sentence that we don't address weak ETags, i.e. the response to the CoAP-side request is not influenced by the presence of absence of weak ETags on the HTTP side. In section 8.2, there is no need to discuss weak ETags, as there is no way to get any.) > Section 6.1 on URL syntax. The ABNF seems fine but some of > the text seem pretty redundant. I would probably drop section > 6.3 and 6.4 all together other than discussing the % encoding > issue. Fine advice for implementers but I think most people > can parse a URL given the ABNF. 1) Redundancy is fine. We have enough places where the necessary other half of the definition is implicitly referred to and can easily be found in some town hall on Alpha Centauri. 2) What sections 6.3 and 6.4 tell you is how to convert the information in a URI into CoAP options and back. We need to fix the section headings to indicate that. There is no other place where this is defined, so there is no redundancy that I can see. 3) An equivalent for the rest of section 6 is in RFC 2616 (potentially as fixed by httpbis), so I see no way how to get rid of this unless the same is decided for HTTP. > Drop the text "MUST fit within single IP datagram". I will > just confuse people and follows from other constraints. Oh. 1 MUST =3D 1. We don't need to say that, indeed. > Move the constants in section 9 up to section 4 to reduce > reader confusion. I don't care. At the end of 4.1? > I'm not a fan of the human readable error messages > fields. They seldom have anything of use for humans and they > get used be vendors to stuff in proprietary stuff that should > have been in an option. I view them as more harm than good. I > expect I am in the "rough" on this so I would prefer if they > were not there but if other folks want them in, I don't really > care. They are often filled with bandwidth waisting text with > zero information content. There should be some admonition about not wasting bandwidth. > The term "origin server" is never defined. I would either just > user server or define what an origin server is. (TODO for terminology section.) > The draft uses the term "safe" but it's not clear what changes > because of this. Some things are safe or not but no behavior > changes based on that so it seems a bit like mention some > requests start with G and others don't. You might consider > dropping it. We point to RFC 2616, section 9.1 here. (This is a place where I'd indeed would like to avoid redundancy, if = possible.) > For the responses codes that are like a HTTP response > code. I'd rather see this specification define what they mean > in the context of CoAP instead of reusing the HTTP ones. I > worry about how an update to HTTP might impact CoAP. We probably should do that at some point, indeed. For now, I did think we might get away with what we have. > In several places in the draft we have things like (U+0026 > AMPERSAND). These are for ascii characters in an ascii > document. They should all be removed to be consisted with the > style of RFCs. Actually, they are about characters in URIs. Yes, we should be consistent with RFC 3986 here. (This was emulating section 3.1/3.2 of draft-ietf-hybi-thewebsocketprotocol-07.txt, which probably also needs to be fixed then.) > We need to pass of figuring out which references are normative > and informative. A few looked like they might be off to me but > I did not spend the time to check. This can happen a bit later > but I did want to flag it. Yes, making sure we don't get a late reclassification of informative references to normative is important to avoid missrefs. [I-D.mcgrew-tls-aes-ccm] is the only one I'm worrying about. (For those who want to help with this: Read section 1.1 of RFC3967.) In the other direction, we probably want to move to informative: RFC3023 RFC3602 RFC3676 RFC4627 What about, e.g., RFC4303, RFC4309, RFC4835, RFC5996? > I plan to propose something new for the registration process > for new entries in in the CoAP Media Type Registry. Right now > it looks too hard to get a new entry in this this table. +1 Gruesse, Carsten (with some help from Klaus) From kovatsch@inf.ethz.ch Wed May 11 12:30:59 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E30AAE0886 for ; Wed, 11 May 2011 12:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8NqJ1fX3vqr for ; Wed, 11 May 2011 12:30:59 -0700 (PDT) Received: from edge10.ethz.ch (edge10.ethz.ch [82.130.75.186]) by ietfa.amsl.com (Postfix) with ESMTP id 0F909E066E for ; Wed, 11 May 2011 12:30:59 -0700 (PDT) Received: from CAS20.d.ethz.ch (172.31.51.110) by edge10.ethz.ch (82.130.75.186) with Microsoft SMTP Server (TLS) id 14.1.289.1; Wed, 11 May 2011 21:30:51 +0200 Received: from MBX20.d.ethz.ch ([fe80::81a7:b7a5:50c0:df0d]) by CAS20.d.ethz.ch ([fe80::2cd8:4907:7776:c56d%11]) with mapi id 14.01.0289.001; Wed, 11 May 2011 21:30:58 +0200 From: "Kovatsch Matthias" To: Carsten Bormann , core WG Thread-Topic: [core] draft-ietf-core-block-03 review Thread-Index: AQHMDn8zvD0IMpxHzU6SGkOyqf6FAJSEyuOAgABYrwCAAL4yAIACI8lQ Date: Wed, 11 May 2011 19:30:56 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B5084238DD@MBX20.d.ethz.ch> References: <65C046E2-65E4-4C20-B1AB-CBE12C9B8164@cisco.com> <348BAAE6-E026-46F6-B76F-5CF099C42441@cisco.com> <7D357C87-FC1E-4365-BF28-BE634C460B0E@tzi.org> In-Reply-To: <7D357C87-FC1E-4365-BF28-BE634C460B0E@tzi.org> Accept-Language: en-US, de-CH Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [193.10.67.50] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [core] draft-ietf-core-block-03 review X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 19:31:00 -0000 Would it be possible to provide meaningful names for the Block options? 1 a= nd 2 in the order 2 (=3D17), 1 (=3D19) might cause a lot of confusion... Block2 corresponds to server-side generated blocks and Block1 to client-sid= e generated blocks, right? So, what about Block-Server and Block-Client or suchlike instead? Regards Matthias From zach@sensinode.com Wed May 11 12:38:20 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 558D4E066E for ; Wed, 11 May 2011 12:38: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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DW2tPTYqLMLm for ; Wed, 11 May 2011 12:38:19 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id E6BADE07F1 for ; Wed, 11 May 2011 12:38:18 -0700 (PDT) Received: from [10.0.2.2] (87-93-208-90.bb.dnainternet.fi [87.93.208.90]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id p4BJcBlo002715 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 11 May 2011 22:38:12 +0300 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-201-417978292; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: <55877B3AFB359744BA0F2140E36F52B5084238DD@MBX20.d.ethz.ch> Date: Wed, 11 May 2011 22:38:12 +0300 Message-Id: <55258A19-9722-4F13-9D1C-30B0CE543523@sensinode.com> References: <65C046E2-65E4-4C20-B1AB-CBE12C9B8164@cisco.com> <348BAAE6-E026-46F6-B76F-5CF099C42441@cisco.com> <7D357C87-FC1E-4365-BF28-BE634C460B0E@tzi.org> <55877B3AFB359744BA0F2140E36F52B5084238DD@MBX20.d.ethz.ch> To: "Kovatsch Matthias" X-Mailer: Apple Mail (2.1084) Cc: core WG Subject: Re: [core] draft-ietf-core-block-03 review X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 19:38:20 -0000 --Apple-Mail-201-417978292 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On May 11, 2011, at 10:30 PM, Kovatsch Matthias wrote: > So, what about Block-Server and Block-Client or suchlike instead? Good idea! Zach -- 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-201-417978292 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 ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDUxMTE5Mzgx M1owIwYJKoZIhvcNAQkEMRYEFMNTkaWz8bxMwu4ntAug+I5bdbcYMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAFKs/uX7jwPTPR7LTAEoL9ZGgL8EgJnpRo3513q4LeOBtcYwT9PsHJsq 3aMDOss3EvSd+ofQ8LmRoK/Y2E12DX11i45IAdAzWEyP8djoZn/x560VmWJT5Qem/1SRtEIrSuT0 adj4NhQ2qevwEG7uc7yN7DO403518jsJ1ms4BjY6EdAcNK1N0es7QsVgFYdoaS86VJVJRO7xHV+w 8+Im0WFb7u+OcMyNFnuz2Lt1m+Jf2MJSABMyBQN2WMPF1szEKSd1wWNPJ7ZmcEDrd+RzZ1DIDNKK jQ0doHoOwKdc6gRD+cCeRWDUM7MOJkG9CGKZ1lv28JKoRXoQ0e+k+mQJolcAAAAAAAA= --Apple-Mail-201-417978292-- From cabo@tzi.org Wed May 11 12:44:56 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 538B5E066E for ; Wed, 11 May 2011 12:44:56 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B0dSrzNy8YLr for ; Wed, 11 May 2011 12:44:55 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 81F17E069C for ; Wed, 11 May 2011 12:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id p4BJik0Z025785; Wed, 11 May 2011 21:44:46 +0200 (CEST) Received: from [192.168.217.112] (p5489A8DA.dip.t-dialin.net [84.137.168.218]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3087AC57; Wed, 11 May 2011 21:44:46 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <55877B3AFB359744BA0F2140E36F52B5084238DD@MBX20.d.ethz.ch> Date: Wed, 11 May 2011 21:44:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <098905EC-2806-4363-9F6C-C6B8A9D2F357@tzi.org> References: <65C046E2-65E4-4C20-B1AB-CBE12C9B8164@cisco.com> <348BAAE6-E026-46F6-B76F-5CF099C42441@cisco.com> <7D357C87-FC1E-4365-BF28-BE634C460B0E@tzi.org> <55877B3AFB359744BA0F2140E36F52B5084238DD@MBX20.d.ethz.ch> To: "Kovatsch Matthias" X-Mailer: Apple Mail (2.1084) Cc: core WG Subject: Re: [core] draft-ietf-core-block-03 review X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 19:44:56 -0000 On May 11, 2011, at 21:30, Kovatsch Matthias wrote: > So, what about Block-Server and Block-Client or suchlike instead? As long as people don't start to think Block-Server options are always = sent from the server and Block-Client options are sent from a client... We went through a couple of these (Block-Request, Block-Response...) and = decided Block1 and Block2 actually had the smallest confusion factor. = But I'm open to any suggestion. If people like B-S and B-C, I'm all for = it. (Spec reception, again, is a funny thing.) But let's brainstorm = for good names for a little more. Now, why did we propose to number Block1 19 and Block2 17? Because = Block2 is more likely, and 17 might mean fewer fenceposts than 19 (this = is more of an issue for responses, since requests usually at least have = an Uri-Path). But this is rather theoretical... Gruesse, Carsten From alper.yegin@yegin.org Wed May 11 12:47:08 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B46A1E06F1 for ; Wed, 11 May 2011 12:47:08 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1jC-RUUpimcc for ; Wed, 11 May 2011 12:47:08 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 2ED16E066E for ; Wed, 11 May 2011 12:47:08 -0700 (PDT) Received: from ibm ([12.166.168.10]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MKYcZ-1QL43T0x4Z-0028CG; Wed, 11 May 2011 15:47:06 -0400 From: "Alper Yegin" To: "'Cullen Jennings'" References: <239072CD-ACC0-454D-8BD6-30AC28D425D9@cisco.com> <059f01cc0b35$a785fc90$f691f5b0$@yegin@yegin.org> <720981EA-6411-4A5C-AC8C-675ADA1A2DE5@cisco.com> <07a401cc0bd8$34e5ab10$9eb10130$@yegin@yegin.org> <8BCD950E-FB93-40EE-848C-466E5152DA7C@cisco.com> <09b901cc0cf6$35877660$a0966320$@yegin@yegin.org> <223489D8-F2DC-45D1-A690-13480534C1B2@cisco.com> In-Reply-To: <223489D8-F2DC-45D1-A690-13480534C1B2@cisco.com> Date: Wed, 11 May 2011 22:47:01 +0300 Message-ID: <02d901cc1014$350126c0$9f037440$@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: AcwOf2EfG5ni0obhQyGe6LMLYvWcuQBlH6tw Content-Language: en-us X-Provags-ID: V02:K0:liouYMz0yaVCbYp8sZsUEqZ+TcqXyiYfiCOGSOj3KY9 X3GiYxh9h9ejev0zjm4PKaQqyn9yCc/kQTRohrBjXJbZDvuErV 1of24nGLzpHJgGC6wv2VZZbjv4Peb5VRlLvlbpmEHumPVnmpTV Auyz6jMvKU/+Sih2ARnFWfgD45Y7XmtyrQ3G9kyQpmbcSgfUNv h8kb8ix+c/Lk/ODIE0TXhLPpOHnoJXx3M9PoLNBSzw= Cc: 'core WG' Subject: Re: [core] draft-ietf-core-coap-06 Security X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 19:47:08 -0000 > > By the way, I wonder why this WG chose to use TLS. Why not define a > > CoAP-layer security extension. We can do something similar to what > was done > > for Mobile IPv4, another UDP-based protocol. Define an option that > carries a > > keyed hash of the CoAP header + payloads. And you get data origin > auth, > > integrity and replay protection. And define another option to encrypt > the > > ones that require privacy. (encryption part not in Mobile IPv4). > > well some protocols have a strong need for the integrity to cover a > different part of the packet than the encryption. Mobile IP and SRTP > seem to be examples of that. However, CoAP seems like you can encrypt > the whole CoAP packet because there is not an need for some > intermediaries to be able to read some of the packet but not others > parts Sure you can encrypt the whole payload e2e. But do you have to? That's the issue. In case you don't have to encrypt the whole packet, then there is an unjustified overhead of doing so (when you use transport-layer security). Alper From kovatsch@inf.ethz.ch Wed May 11 13:15:09 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BAE4E087B for ; Wed, 11 May 2011 13:15:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id si0t8f10O2JT for ; Wed, 11 May 2011 13:15:09 -0700 (PDT) Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) by ietfa.amsl.com (Postfix) with ESMTP id B3BD8E0717 for ; Wed, 11 May 2011 13:15:07 -0700 (PDT) Received: from CAS12.d.ethz.ch (172.31.38.212) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.1.289.1; Wed, 11 May 2011 22:15:00 +0200 Received: from MBX20.d.ethz.ch ([fe80::81a7:b7a5:50c0:df0d]) by CAS12.d.ethz.ch ([fe80::7861:4ecb:7c42:cad4%11]) with mapi id 14.01.0289.001; Wed, 11 May 2011 22:15:07 +0200 From: "Kovatsch Matthias" To: Carsten Bormann Thread-Topic: AW: [core] draft-ietf-core-block-03 review Thread-Index: AQHMDn8zvD0IMpxHzU6SGkOyqf6FAJSEyuOAgABYrwCAAL4yAIACI8lQ///jr4CAACkgMA== Date: Wed, 11 May 2011 20:15:06 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B50842391C@MBX20.d.ethz.ch> References: <65C046E2-65E4-4C20-B1AB-CBE12C9B8164@cisco.com> <348BAAE6-E026-46F6-B76F-5CF099C42441@cisco.com> <7D357C87-FC1E-4365-BF28-BE634C460B0E@tzi.org> <55877B3AFB359744BA0F2140E36F52B5084238DD@MBX20.d.ethz.ch> <098905EC-2806-4363-9F6C-C6B8A9D2F357@tzi.org> In-Reply-To: <098905EC-2806-4363-9F6C-C6B8A9D2F357@tzi.org> Accept-Language: en-US, de-CH Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [213.114.148.63] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: core WG Subject: Re: [core] draft-ietf-core-block-03 review X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 20:15:09 -0000 > As long as people don't start to think Block-Server options are always se= nt > from the server and Block-Client options are sent from a client... Also a good point. How about the classic Block-Down(stream/load/{}) and Block-Up(stream/load/{= })? > Now, why did we propose to number Block1 19 and Block2 17? Because > Block2 is more likely, and 17 might mean fewer fenceposts than 19 (this i= s > more of an issue for responses, since requests usually at least have an U= ri- > Path). But this is rather theoretical... Yes, I saw it that way. I wondered why the more likely one got second, thou= gh ;) Bye Matthias From ekr@rtfm.com Thu May 12 06:44:28 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E223BE07BE for ; Thu, 12 May 2011 06:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id faS348QvNHx8 for ; Thu, 12 May 2011 06:44:23 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 70768E0694 for ; Thu, 12 May 2011 06:44:23 -0700 (PDT) Received: by iyn15 with SMTP id 15so1622865iyn.31 for ; Thu, 12 May 2011 06:44:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.43.132.6 with SMTP id hs6mr222647icc.385.1305207862945; Thu, 12 May 2011 06:44:22 -0700 (PDT) Received: by 10.42.217.195 with HTTP; Thu, 12 May 2011 06:44:22 -0700 (PDT) In-Reply-To: <-3335568933846752161@unknownmsgid> References: <239072CD-ACC0-454D-8BD6-30AC28D425D9@cisco.com> <720981EA-6411-4A5C-AC8C-675ADA1A2DE5@cisco.com> <8BCD950E-FB93-40EE-848C-466E5152DA7C@cisco.com> <223489D8-F2DC-45D1-A690-13480534C1B2@cisco.com> <-3335568933846752161@unknownmsgid> Date: Thu, 12 May 2011 06:44:22 -0700 Message-ID: From: Eric Rescorla To: Alper Yegin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: core WG Subject: Re: [core] draft-ietf-core-coap-06 Security X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2011 13:44:29 -0000 On Wed, May 11, 2011 at 12:47 PM, Alper Yegin wrote= : >> > By the way, I wonder why this WG chose to use TLS. Why not define a >> > CoAP-layer security extension. We can do something similar to what >> was done >> > for Mobile IPv4, another UDP-based protocol. Define an option that >> carries a >> > keyed hash of the CoAP header + payloads. And you get data origin >> auth, >> > integrity and replay protection. And define another option to encrypt >> the >> > ones that require privacy. (encryption part not in Mobile IPv4). >> >> well some protocols have a strong need for the integrity to cover a >> different part of the packet than the encryption. =A0Mobile IP and SRTP >> seem to be examples of that. However, CoAP seems like you can encrypt >> the whole CoAP packet because there is not an need for some >> intermediaries to be able to read some of the packet but not others >> parts > > Sure you can encrypt the whole payload e2e. But do you have to? That's th= e > issue. In case you don't have to encrypt the whole packet, then there is = an > unjustified overhead of doing so (when you use transport-layer security). TLS has cipher suites that only do integrity. -Ekr From alper.yegin@yegin.org Thu May 12 11:51:24 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2935E073C for ; Thu, 12 May 2011 11:51:24 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2B+RmbCo2LlB for ; Thu, 12 May 2011 11:51:24 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 481E9E06C8 for ; Thu, 12 May 2011 11:51:24 -0700 (PDT) Received: from ibm ([12.166.168.253]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0MGj0L-1QY3N81q9x-00DoWC; Thu, 12 May 2011 14:51:23 -0400 From: "Alper Yegin" To: "'Eric Rescorla'" References: <239072CD-ACC0-454D-8BD6-30AC28D425D9@cisco.com> <720981EA-6411-4A5C-AC8C-675ADA1A2DE5@cisco.com> <8BCD950E-FB93-40EE-848C-466E5152DA7C@cisco.com> <223489D8-F2DC-45D1-A690-13480534C1B2@cisco.com> <-3335568933846752161@unknownmsgid> In-Reply-To: Date: Thu, 12 May 2011 21:51:14 +0300 Message-ID: <005101cc10d5$9697a1e0$c3c6e5a0$@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: AcwQqrOQLg1zxxgRQ2WlLHQNQfqOfQAKjMOA Content-Language: en-us X-Provags-ID: V02:K0:ZCrxwPiwE/j69SeWWCW3Ki6ku3/Tski+hGPuZ1m5rDe kJIuepDbZa5htaVSD3hQKsQzwL3IMtmXk//7KToiKP50Pt1gwX 5KbJjK2dmq6sBYRuTRqZoCXmoYC4Krprt9aVdNkRfP90FqQjAu zXvvjygnGnV8SiOxKdTvnMQ+YAlBcz9L/wCH54SGulzlLxlM8h z6Agtz8846nUDSp3/p0KIKAITPxbPQIYJPRS3Lscfc= Cc: 'core WG' Subject: Re: [core] draft-ietf-core-coap-06 Security X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2011 18:51:24 -0000 > > Sure you can encrypt the whole payload e2e. But do you have to? > That's the > > issue. In case you don't have to encrypt the whole packet, then there > is an > > unjustified overhead of doing so (when you use transport-layer > security). > > TLS has cipher suites that only do integrity. I can understand that the TLS channel can be just integrity protected. If just some of the application data needs to be encrypted, can it be done? I think the channel is either only integrity protected, or both integrity protected and encrypted. If my application relies on TLS, and if some bit of data requires privacy, I always need to be using an encrypted channel which applies to the whole communication. I'm not singling out TLS here. I think this is a fundamental distinction between channel security vs object-level security. Alper From robert.cragie@gridmerge.com Thu May 12 13:40:38 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ABAEE07AA for ; Thu, 12 May 2011 13:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NnmgCJvPefXz for ; Thu, 12 May 2011 13:40:38 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by ietfa.amsl.com (Postfix) with ESMTP id A3061E067C for ; Thu, 12 May 2011 13:40:37 -0700 (PDT) Received: from client-86-23-5-208.brhm.adsl.virginmedia.com ([86.23.5.208] helo=[192.168.1.80]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.73) id 1QKcgV-0003Im-DV for core@ietf.org; Thu, 12 May 2011 21:40:35 +0100 Message-ID: <4DCC45D3.2020304@gridmerge.com> Date: Thu, 12 May 2011 21:40:51 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: core@ietf.org References: <239072CD-ACC0-454D-8BD6-30AC28D425D9@cisco.com> <720981EA-6411-4A5C-AC8C-675ADA1A2DE5@cisco.com> <8BCD950E-FB93-40EE-848C-466E5152DA7C@cisco.com> <223489D8-F2DC-45D1-A690-13480534C1B2@cisco.com> <-3335568933846752161@unknownmsgid> <005101cc10d5$9697a1e0$c3c6e5a0$@yegin@yegin.org> In-Reply-To: <005101cc10d5$9697a1e0$c3c6e5a0$@yegin@yegin.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030907090708000400090002" X-Authenticated-As: robert.cragie@gridmerge.com Subject: Re: [core] draft-ietf-core-coap-06 Security X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2011 20:40:38 -0000 This is a cryptographically signed message in MIME format. --------------ms030907090708000400090002 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable >>> Sure you can encrypt the whole payload e2e. But do you have to? >> That's the >>> issue. In case you don't have to encrypt the whole packet, then there= >> is an >>> unjustified overhead of doing so (when you use transport-layer >> security). >> >> TLS has cipher suites that only do integrity. > I can understand that the TLS channel can be just integrity protected. > > If just some of the application data needs to be encrypted, can it be d= one? > I think the channel is either only integrity protected, or both integri= ty > protected and encrypted. > > If my application relies on TLS, and if some bit of data requires priva= cy, I > always need to be using an encrypted channel which applies to the whole= > communication. > > I'm not singling out TLS here. I think this is a fundamental distinctio= n > between channel security vs object-level security. It seems fundamentally easier to encrypt on a channel basis as the same=20 end-point credentials are used to derive keying information which can=20 encrypt and integrity protect simultaneously, e.g. most efficiently=20 using an AEAD cipher like AES-CCM or AES-GCM. If you start to make the=20 encryption more granular, what do you then use as the cryptographic=20 basis for secrecy between the transacting objects? Asymmetric or=20 symmetric? Would you use the same granularity as the channel end points? = Or be more granular? All I'm saying is there is probably more to this than meets the eye. Robert --------------ms030907090708000400090002 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIREjCC BIowggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w NTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMC VVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l dHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVN NRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQy lbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXq vgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6 hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu 9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0G A1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/ BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9BZGRU cnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8ubmV0L0Fk ZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyispgCi 54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0 g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHd WTBK322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftz Mizpm4QkLdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsy XEFs/vVdoOr/0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIGPjCCBSagAwIBAgIRALZcFI008b3q kGPLKBbwWBIwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEX MBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29y azEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMTAwODMwMDAwMDAw WhcNMTEwODMwMjM1OTU5WjCB5DE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQ RVJTT05BIE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9m IHVzZTogaHR0cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIw MDMgQ29tb2RvIExpbWl0ZWQxFjAUBgNVBAMTDVJvYmVydCBDcmFnaWUxKjAoBgkqhkiG9w0B CQEWG3JvYmVydC5jcmFnaWVAZ3JpZG1lcmdlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALQCfpvU4Hd5YvAYACEbYRrbYd2HAm4Sz43wHJwynBBkq5GamqO/SYNrg1ut iDsDQqvWnt1cHgZb4N1FFbvLqV84A0f4xc+EtWTZNYn+lfUBIsgR3RNajFEHnsrXnZN6sPdw lObJ1ol4FUWnFPB/A7/liT7G+FmAB+DAc2iTCNjfxOVxhmKShY/b8ZxIkO4fN418cNxHtq1w gm4SRHIv7VJfgseNKQd5u55RHQEmPgN7aiSyIhvAK4H9Pm1msZrklIoSqGpIR0K7gMpVmPRF bWyoPEgAmGYXRwsdvmUkq8W2wCkr9HA5NNL0D74B+RhIus0gfUL6lgnQR/6y9F31eY0CAwEA AaOCAh0wggIZMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBRp GoTqjgTJPeVwG/HaXEXWnn/AGDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNV HSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1Ud IAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNv bW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2Eu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRp Y2F0aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDov L2NydC5jb21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC5jb21vZG9jYS5jb20wJgYDVR0RBB8wHYEbcm9iZXJ0LmNyYWdpZUBncmlkbWVy Z2UuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQA3I0iUCoFSHw/yM7Ra4cdmKkfZirA7N12pCneI VKHrpx4LJImjCEGNinH6G+PDrs632O96zXzaGqq+S2cA3lX5TJ2XdKz3EwPawB6uZf6sHUrW t5NMbwbotDQLTq0gXW6guL4ICyrmb6EdqO5km8UkgWR7lSzm8fxORPg+X41gu33zb6/cv7hV 3gmBbDPh3PVTyGfnAGOyUBSRCvzbrYtkByCMXUfdTdrx7jV1iD0TjxTJe8vJbTv3zjcIcTHG NnR+CZAx+qXTczLc8pL7DtDXokR5zZUuCgPGg/UWgUfBTUB6vibrAtrX9danRwaR61QCu3R6 HSg520a9rfVXa1NqMIIGPjCCBSagAwIBAgIRALZcFI008b3qkGPLKBbwWBIwDQYJKoZIhvcN AQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtl IENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDov L3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMTAwODMwMDAwMDAwWhcNMTEwODMwMjM1OTU5WjCB 5DE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05BIE5PVCBWQUxJREFU RUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0cDovL3d3dy5j b21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExpbWl0ZWQx FjAUBgNVBAMTDVJvYmVydCBDcmFnaWUxKjAoBgkqhkiG9w0BCQEWG3JvYmVydC5jcmFnaWVA Z3JpZG1lcmdlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALQCfpvU4Hd5 YvAYACEbYRrbYd2HAm4Sz43wHJwynBBkq5GamqO/SYNrg1utiDsDQqvWnt1cHgZb4N1FFbvL qV84A0f4xc+EtWTZNYn+lfUBIsgR3RNajFEHnsrXnZN6sPdwlObJ1ol4FUWnFPB/A7/liT7G +FmAB+DAc2iTCNjfxOVxhmKShY/b8ZxIkO4fN418cNxHtq1wgm4SRHIv7VJfgseNKQd5u55R HQEmPgN7aiSyIhvAK4H9Pm1msZrklIoSqGpIR0K7gMpVmPRFbWyoPEgAmGYXRwsdvmUkq8W2 wCkr9HA5NNL0D74B+RhIus0gfUL6lgnQR/6y9F31eY0CAwEAAaOCAh0wggIZMB8GA1UdIwQY MBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBRpGoTqjgTJPeVwG/HaXEXWnn/A GDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYL KwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQEC AQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNV HR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL1VUTi1VU0VSRmlyc3Qt Q2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBIoEaGRGh0dHA6Ly9jcmwuY29t b2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3Js MGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5jb21vZG9jYS5jb20v VVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5j b20wJgYDVR0RBB8wHYEbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQA3I0iUCoFSHw/yM7Ra4cdmKkfZirA7N12pCneIVKHrpx4LJImjCEGNinH6G+PD rs632O96zXzaGqq+S2cA3lX5TJ2XdKz3EwPawB6uZf6sHUrWt5NMbwbotDQLTq0gXW6guL4I Cyrmb6EdqO5km8UkgWR7lSzm8fxORPg+X41gu33zb6/cv7hV3gmBbDPh3PVTyGfnAGOyUBSR CvzbrYtkByCMXUfdTdrx7jV1iD0TjxTJe8vJbTv3zjcIcTHGNnR+CZAx+qXTczLc8pL7DtDX okR5zZUuCgPGg/UWgUfBTUB6vibrAtrX9danRwaR61QCu3R6HSg520a9rfVXa1NqMYIEYDCC BFwCAQEwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBM YWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0 cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBB dXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQC2XBSNNPG96pBjyygW8FgSMAkGBSsOAwIaBQCg ggJwMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDUxMjIw NDA1MVowIwYJKoZIhvcNAQkEMRYEFFeXCBdOq7c0FARq81SAqjCKdUNcMF8GCSqGSIb3DQEJ DzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG 9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB1QYJKwYBBAGCNxAEMYHHMIHEMIGu MQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4w HAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNl cnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRp b24gYW5kIEVtYWlsAhEAtlwUjTTxveqQY8soFvBYEjCB1wYLKoZIhvcNAQkQAgsxgceggcQw ga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkx HjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51 c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgRW1haWwCEQC2XBSNNPG96pBjyygW8FgSMA0GCSqGSIb3DQEBAQUABIIBAKtf /95zyyYSzPlbPacrJxYW94IjQXoO9kXv5FFlXsrDBCS0MlCmv2htK89MAsguJBsDOJRzw8Tr XrE6ayiOviINcBOOO8u+KI0QruYurQ2YGh36d6RfdZ/i3FL067EyznGJBYUUUKjbXWZoWBO8 cluZLYlQZF6Plxdl31nkCf3wP9gNUT6VJbfUD4SqUv37b56qOYnGBvHjx7ALFrHeetancBrO oTrN0QSbfSzZAfa8yxuLzy1SsukC8Dh0PR8o3qWOL0BF3N9xUMTQHT/ipCDNIv/4uWWO1Ma8 wiHTb9ZMrW3QM6ELCeIy7EjJkHBEYwucr+Z9zS9FkgsJTg0g9sIAAAAAAAA= --------------ms030907090708000400090002-- From alper.yegin@yegin.org Thu May 12 18:39:13 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 682E9E0693 for ; Thu, 12 May 2011 18:39:13 -0700 (PDT) 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=[AWL=-0.000, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9Mst6+HpnWp for ; Thu, 12 May 2011 18:39:12 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id BFDD6E0680 for ; Thu, 12 May 2011 18:39:12 -0700 (PDT) Received: from ibm ([12.166.168.10]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MWTP0-1QEl3w2rBC-00Xkel; Thu, 12 May 2011 21:39:09 -0400 From: "Alper Yegin" To: , References: <239072CD-ACC0-454D-8BD6-30AC28D425D9@cisco.com> <720981EA-6411-4A5C-AC8C-675ADA1A2DE5@cisco.com> <8BCD950E-FB93-40EE-848C-466E5152DA7C@cisco.com> <223489D8-F2DC-45D1-A690-13480534C1B2@cisco.com> <-3335568933846752161@unknownmsgid> <005101cc10d5$9697a1e0$c3c6e5a0$@yegin@yegin.org> <4DCC45D3.2020304@gridmerge.com> In-Reply-To: <4DCC45D3.2020304@gridmerge.com> Date: Fri, 13 May 2011 04:39:05 +0300 Message-ID: <00bb01cc110e$8e3cb7e0$aab627a0$@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: AcwQ5OD6u+raeETeRI62lTJGsiNKBgAKT3qA Content-Language: en-us X-Provags-ID: V02:K0:m9ql0o6jhpvYmqaNTBwYfjk5iUnqPWa2N48QeSegNJI 4sgnI0HG3h5MAt3bOQMLy9muvCipxAKmGkQ+N6EyZOad5eqk5t K5wydvzPMoye0gXBwDFrFRhsX26msb9jXKDg2pMEEQy2pF9vHI e0H1lOK09UfgVPoXKdb01n8zW0lY2z5I4w19XliIFTMMNJkhN6 Tru9ecC+ip0KHudVGWgj6/4iLy6z/2Y9YXRUcggbQo= Subject: Re: [core] draft-ietf-core-coap-06 Security X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 01:39:13 -0000 > > I'm not singling out TLS here. I think this is a fundamental > > distinction between channel security vs object-level security. > It seems fundamentally easier to encrypt on a channel basis as the same > end-point credentials are used to derive keying information which can > encrypt and integrity protect simultaneously, Using object-level security does not change that. > e.g. most efficiently > using an AEAD cipher like AES-CCM or AES-GCM. If you start to make the > encryption more granular, what do you then use as the cryptographic > basis for secrecy between the transacting objects? Asymmetric or > symmetric? Symmetric. > Would you use the same granularity as the channel end > points? > Or be more granular? Not sure I understand. Can you elaborate? > All I'm saying is there is probably more to this than meets the eye. Let's find out. Alper From prvs=011402B8CB=guido.moritz@uni-rostock.de Fri May 13 01:14:51 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5666E06FB for ; Fri, 13 May 2011 01:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FDUAMqISv25l for ; Fri, 13 May 2011 01:14:51 -0700 (PDT) Received: from mailrelay1.uni-rostock.de (mailrelay1.uni-rostock.de [139.30.8.201]) by ietfa.amsl.com (Postfix) with ESMTP id C2208E066A for ; Fri, 13 May 2011 01:14:49 -0700 (PDT) From: Guido Moritz To: 'core' Date: Fri, 13 May 2011 10:15:07 +0200 Message-ID: <005801cc1145$de8fe690$9bafb3b0$@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: AcwRRMu8uhiIwVfmR8SQn6+/UHl7Qg== Content-Language: de X-Originating-IP: [139.30.201.226] Subject: [core] Duplicates Dedection X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 08:14:51 -0000 For duplicates detection, coap-06 defines that matching can be made through the Message ID. Wouldn't it be useful also to have a few words that for matching purposes the source address should be considered as well. (Not the port since each MID must be unique for the same address) We have a scenario in mind with a huge amount of sensor nodes, all from the same vendor, all with the same firmware. All are starting and using the same (not optimal) randomize algorithm for the initial MID and suddenly there is a high probability for the same MID to be received from to different endpoints. In this case duplicates cannot only be detected on the CoAP level. This might be too implementation specific, but having a few words on using also the address might be helpful. Best, Guido From robert.cragie@gridmerge.com Fri May 13 02:03:53 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEB89E068B for ; Fri, 13 May 2011 02:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id amQYKwjSV3MQ for ; Fri, 13 May 2011 02:03:52 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by ietfa.amsl.com (Postfix) with ESMTP id 38905E0665 for ; Fri, 13 May 2011 02:03:51 -0700 (PDT) Received: from client-86-23-5-208.brhm.adsl.virginmedia.com ([86.23.5.208] helo=[192.168.1.80]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.73) id 1QKoHm-00024e-Bn; Fri, 13 May 2011 10:03:50 +0100 Message-ID: <4DCCF405.2050500@gridmerge.com> Date: Fri, 13 May 2011 10:04:05 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Alper Yegin References: <239072CD-ACC0-454D-8BD6-30AC28D425D9@cisco.com> <720981EA-6411-4A5C-AC8C-675ADA1A2DE5@cisco.com> <8BCD950E-FB93-40EE-848C-466E5152DA7C@cisco.com> <223489D8-F2DC-45D1-A690-13480534C1B2@cisco.com> <-3335568933846752161@unknownmsgid> <005101cc10d5$9697a1e0$c3c6e5a0$@yegin@yegin.org> <4DCC45D3.2020304@gridmerge.com> <00bb01cc110e$8e3cb7e0$aab627a0$@yegin@yegin.org> In-Reply-To: <00bb01cc110e$8e3cb7e0$aab627a0$@yegin@yegin.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000505060900080602030908" X-Authenticated-As: robert.cragie@gridmerge.com Cc: core@ietf.org Subject: Re: [core] draft-ietf-core-coap-06 Security X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 09:03:54 -0000 This is a cryptographically signed message in MIME format. --------------ms000505060900080602030908 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 13/05/2011 2:39 AM, Alper Yegin wrote: >>> I'm not singling out TLS here. I think this is a fundamental >>> distinction between channel security vs object-level security. >> It seems fundamentally easier to encrypt on a channel basis as the sam= e >> end-point credentials are used to derive keying information which can >> encrypt and integrity protect simultaneously, > Using object-level security does not change that. Perhaps I misunderstood what you meant by object-level security. The way = you described it seemed to suggest that elements of data transacted=20 within the channel could be individually encrypted. My questions=20 surround what security material is used to perform the encryption in=20 each case. >> e.g. most efficiently >> using an AEAD cipher like AES-CCM or AES-GCM. If you start to make the= >> encryption more granular, what do you then use as the cryptographic >> basis for secrecy between the transacting objects? Asymmetric or >> symmetric? > Symmetric. > >> Would you use the same granularity as the channel end >> points? >> Or be more granular? > Not sure I understand. Can you elaborate? As above - what security material would you use to encrypt? The same=20 security material as is used for channel encryption? Or something more=20 granular, i.e. would each distinct element of encrypted data have its=20 own security material? What is the distinction? If communicating objects = multiplex their transactions on a single channel, this could be the case.= >> All I'm saying is there is probably more to this than meets the eye. > Let's find out. > > Alper > > > > --------------ms000505060900080602030908 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIREjCC BIowggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w NTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMC VVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l dHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVN NRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQy lbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXq vgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6 hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu 9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0G A1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/ BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9BZGRU cnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8ubmV0L0Fk ZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyispgCi 54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0 g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHd WTBK322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftz Mizpm4QkLdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsy XEFs/vVdoOr/0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIGPjCCBSagAwIBAgIRALZcFI008b3q kGPLKBbwWBIwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEX MBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29y azEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMTAwODMwMDAwMDAw WhcNMTEwODMwMjM1OTU5WjCB5DE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQ RVJTT05BIE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9m IHVzZTogaHR0cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIw MDMgQ29tb2RvIExpbWl0ZWQxFjAUBgNVBAMTDVJvYmVydCBDcmFnaWUxKjAoBgkqhkiG9w0B CQEWG3JvYmVydC5jcmFnaWVAZ3JpZG1lcmdlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALQCfpvU4Hd5YvAYACEbYRrbYd2HAm4Sz43wHJwynBBkq5GamqO/SYNrg1ut iDsDQqvWnt1cHgZb4N1FFbvLqV84A0f4xc+EtWTZNYn+lfUBIsgR3RNajFEHnsrXnZN6sPdw lObJ1ol4FUWnFPB/A7/liT7G+FmAB+DAc2iTCNjfxOVxhmKShY/b8ZxIkO4fN418cNxHtq1w gm4SRHIv7VJfgseNKQd5u55RHQEmPgN7aiSyIhvAK4H9Pm1msZrklIoSqGpIR0K7gMpVmPRF bWyoPEgAmGYXRwsdvmUkq8W2wCkr9HA5NNL0D74B+RhIus0gfUL6lgnQR/6y9F31eY0CAwEA AaOCAh0wggIZMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBRp GoTqjgTJPeVwG/HaXEXWnn/AGDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNV HSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1Ud IAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNv bW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2Eu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRp Y2F0aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDov L2NydC5jb21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC5jb21vZG9jYS5jb20wJgYDVR0RBB8wHYEbcm9iZXJ0LmNyYWdpZUBncmlkbWVy Z2UuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQA3I0iUCoFSHw/yM7Ra4cdmKkfZirA7N12pCneI VKHrpx4LJImjCEGNinH6G+PDrs632O96zXzaGqq+S2cA3lX5TJ2XdKz3EwPawB6uZf6sHUrW t5NMbwbotDQLTq0gXW6guL4ICyrmb6EdqO5km8UkgWR7lSzm8fxORPg+X41gu33zb6/cv7hV 3gmBbDPh3PVTyGfnAGOyUBSRCvzbrYtkByCMXUfdTdrx7jV1iD0TjxTJe8vJbTv3zjcIcTHG NnR+CZAx+qXTczLc8pL7DtDXokR5zZUuCgPGg/UWgUfBTUB6vibrAtrX9danRwaR61QCu3R6 HSg520a9rfVXa1NqMIIGPjCCBSagAwIBAgIRALZcFI008b3qkGPLKBbwWBIwDQYJKoZIhvcN AQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtl IENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDov L3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMTAwODMwMDAwMDAwWhcNMTEwODMwMjM1OTU5WjCB 5DE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05BIE5PVCBWQUxJREFU RUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0cDovL3d3dy5j b21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExpbWl0ZWQx FjAUBgNVBAMTDVJvYmVydCBDcmFnaWUxKjAoBgkqhkiG9w0BCQEWG3JvYmVydC5jcmFnaWVA Z3JpZG1lcmdlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALQCfpvU4Hd5 YvAYACEbYRrbYd2HAm4Sz43wHJwynBBkq5GamqO/SYNrg1utiDsDQqvWnt1cHgZb4N1FFbvL qV84A0f4xc+EtWTZNYn+lfUBIsgR3RNajFEHnsrXnZN6sPdwlObJ1ol4FUWnFPB/A7/liT7G +FmAB+DAc2iTCNjfxOVxhmKShY/b8ZxIkO4fN418cNxHtq1wgm4SRHIv7VJfgseNKQd5u55R HQEmPgN7aiSyIhvAK4H9Pm1msZrklIoSqGpIR0K7gMpVmPRFbWyoPEgAmGYXRwsdvmUkq8W2 wCkr9HA5NNL0D74B+RhIus0gfUL6lgnQR/6y9F31eY0CAwEAAaOCAh0wggIZMB8GA1UdIwQY MBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBRpGoTqjgTJPeVwG/HaXEXWnn/A GDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYL KwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQEC AQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNV HR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL1VUTi1VU0VSRmlyc3Qt Q2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBIoEaGRGh0dHA6Ly9jcmwuY29t b2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3Js MGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5jb21vZG9jYS5jb20v VVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5j b20wJgYDVR0RBB8wHYEbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQA3I0iUCoFSHw/yM7Ra4cdmKkfZirA7N12pCneIVKHrpx4LJImjCEGNinH6G+PD rs632O96zXzaGqq+S2cA3lX5TJ2XdKz3EwPawB6uZf6sHUrWt5NMbwbotDQLTq0gXW6guL4I Cyrmb6EdqO5km8UkgWR7lSzm8fxORPg+X41gu33zb6/cv7hV3gmBbDPh3PVTyGfnAGOyUBSR CvzbrYtkByCMXUfdTdrx7jV1iD0TjxTJe8vJbTv3zjcIcTHGNnR+CZAx+qXTczLc8pL7DtDX okR5zZUuCgPGg/UWgUfBTUB6vibrAtrX9danRwaR61QCu3R6HSg520a9rfVXa1NqMYIEYDCC BFwCAQEwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBM YWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0 cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBB dXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQC2XBSNNPG96pBjyygW8FgSMAkGBSsOAwIaBQCg ggJwMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDUxMzA5 MDQwNVowIwYJKoZIhvcNAQkEMRYEFD0Y0NlMWHa9kqsre8GOBXTAoKCbMF8GCSqGSIb3DQEJ DzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG 9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB1QYJKwYBBAGCNxAEMYHHMIHEMIGu MQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4w HAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNl cnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRp b24gYW5kIEVtYWlsAhEAtlwUjTTxveqQY8soFvBYEjCB1wYLKoZIhvcNAQkQAgsxgceggcQw ga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkx HjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51 c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgRW1haWwCEQC2XBSNNPG96pBjyygW8FgSMA0GCSqGSIb3DQEBAQUABIIBAGUM NIVub23Hsgh+1F4PzEcryvvNoBNr5Ds4vORWq26E6qYTSTRYrOz7XkkmfZ/fqXHhACBsktqH PdusvOB4DcUNlcgZVg1/SZvTv7Tdeoa0b4FUj+16FNaA5PO02FRXOD3SEutr0K3RBTZaTrc0 rhpGRGHRcnvXgmOoAEHwGLdkk1ouIYntpGXMfCjLVNn9GfFGtS3AGo6pMNO20zCZu6bGVKeR uGAbI3m09UXFauy9sdBJAQBAGFmo/nE/1FIQaOyPcB7kqA+iRBGsJVCLUo9P1hboJlKmbJO/ PbPFJDttd380xdgUBPP+XfSpPPs5iSYzj7iCiBmv3f2OO/jiheYAAAAAAAA= --------------ms000505060900080602030908-- From robert.cragie@gridmerge.com Fri May 13 02:31:04 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1332CE0695 for ; Fri, 13 May 2011 02:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNkCRwpKK9Zw for ; Fri, 13 May 2011 02:31:03 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by ietfa.amsl.com (Postfix) with ESMTP id 32B17E067B for ; Fri, 13 May 2011 02:31:03 -0700 (PDT) Received: from client-86-23-5-208.brhm.adsl.virginmedia.com ([86.23.5.208] helo=[192.168.1.80]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.73) id 1QKoi5-0005Hd-HP for core@ietf.org; Fri, 13 May 2011 10:31:02 +0100 Message-ID: <4DCCFA65.2040702@gridmerge.com> Date: Fri, 13 May 2011 10:31:17 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: core Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060805040800040806080802" X-Authenticated-As: robert.cragie@gridmerge.com Subject: [core] Block names X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 09:31:04 -0000 This is a cryptographically signed message in MIME format. --------------ms060805040800040806080802 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Block1 and Block2 are not very helpful names. As they are tied to=20 request and response, how about something like BlockFromReq for Block1=20 and BlockFromRsp for Block2 or something? BlockFromRsp in Request -> (expecting) A block in response BlockFromRsp in Response -> A block in response BlockFromReq in Request -> A block in request BlockFromReq in Response -> (received) A block in request Robert --------------ms060805040800040806080802 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIREjCC BIowggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w NTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMC VVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l dHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVN NRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQy lbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXq vgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6 hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu 9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0G A1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/ BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9BZGRU cnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8ubmV0L0Fk ZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyispgCi 54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0 g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHd WTBK322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftz Mizpm4QkLdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsy XEFs/vVdoOr/0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIGPjCCBSagAwIBAgIRALZcFI008b3q kGPLKBbwWBIwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEX MBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29y azEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMTAwODMwMDAwMDAw WhcNMTEwODMwMjM1OTU5WjCB5DE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQ RVJTT05BIE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9m IHVzZTogaHR0cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIw MDMgQ29tb2RvIExpbWl0ZWQxFjAUBgNVBAMTDVJvYmVydCBDcmFnaWUxKjAoBgkqhkiG9w0B CQEWG3JvYmVydC5jcmFnaWVAZ3JpZG1lcmdlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALQCfpvU4Hd5YvAYACEbYRrbYd2HAm4Sz43wHJwynBBkq5GamqO/SYNrg1ut iDsDQqvWnt1cHgZb4N1FFbvLqV84A0f4xc+EtWTZNYn+lfUBIsgR3RNajFEHnsrXnZN6sPdw lObJ1ol4FUWnFPB/A7/liT7G+FmAB+DAc2iTCNjfxOVxhmKShY/b8ZxIkO4fN418cNxHtq1w gm4SRHIv7VJfgseNKQd5u55RHQEmPgN7aiSyIhvAK4H9Pm1msZrklIoSqGpIR0K7gMpVmPRF bWyoPEgAmGYXRwsdvmUkq8W2wCkr9HA5NNL0D74B+RhIus0gfUL6lgnQR/6y9F31eY0CAwEA AaOCAh0wggIZMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBRp GoTqjgTJPeVwG/HaXEXWnn/AGDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNV HSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1Ud IAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNv bW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2Eu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRp Y2F0aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDov L2NydC5jb21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC5jb21vZG9jYS5jb20wJgYDVR0RBB8wHYEbcm9iZXJ0LmNyYWdpZUBncmlkbWVy Z2UuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQA3I0iUCoFSHw/yM7Ra4cdmKkfZirA7N12pCneI VKHrpx4LJImjCEGNinH6G+PDrs632O96zXzaGqq+S2cA3lX5TJ2XdKz3EwPawB6uZf6sHUrW t5NMbwbotDQLTq0gXW6guL4ICyrmb6EdqO5km8UkgWR7lSzm8fxORPg+X41gu33zb6/cv7hV 3gmBbDPh3PVTyGfnAGOyUBSRCvzbrYtkByCMXUfdTdrx7jV1iD0TjxTJe8vJbTv3zjcIcTHG NnR+CZAx+qXTczLc8pL7DtDXokR5zZUuCgPGg/UWgUfBTUB6vibrAtrX9danRwaR61QCu3R6 HSg520a9rfVXa1NqMIIGPjCCBSagAwIBAgIRALZcFI008b3qkGPLKBbwWBIwDQYJKoZIhvcN AQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtl IENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDov L3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMTAwODMwMDAwMDAwWhcNMTEwODMwMjM1OTU5WjCB 5DE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05BIE5PVCBWQUxJREFU RUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0cDovL3d3dy5j b21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExpbWl0ZWQx FjAUBgNVBAMTDVJvYmVydCBDcmFnaWUxKjAoBgkqhkiG9w0BCQEWG3JvYmVydC5jcmFnaWVA Z3JpZG1lcmdlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALQCfpvU4Hd5 YvAYACEbYRrbYd2HAm4Sz43wHJwynBBkq5GamqO/SYNrg1utiDsDQqvWnt1cHgZb4N1FFbvL qV84A0f4xc+EtWTZNYn+lfUBIsgR3RNajFEHnsrXnZN6sPdwlObJ1ol4FUWnFPB/A7/liT7G +FmAB+DAc2iTCNjfxOVxhmKShY/b8ZxIkO4fN418cNxHtq1wgm4SRHIv7VJfgseNKQd5u55R HQEmPgN7aiSyIhvAK4H9Pm1msZrklIoSqGpIR0K7gMpVmPRFbWyoPEgAmGYXRwsdvmUkq8W2 wCkr9HA5NNL0D74B+RhIus0gfUL6lgnQR/6y9F31eY0CAwEAAaOCAh0wggIZMB8GA1UdIwQY MBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBRpGoTqjgTJPeVwG/HaXEXWnn/A GDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYL KwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQEC AQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNV HR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL1VUTi1VU0VSRmlyc3Qt Q2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBIoEaGRGh0dHA6Ly9jcmwuY29t b2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3Js MGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5jb21vZG9jYS5jb20v VVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5j b20wJgYDVR0RBB8wHYEbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQA3I0iUCoFSHw/yM7Ra4cdmKkfZirA7N12pCneIVKHrpx4LJImjCEGNinH6G+PD rs632O96zXzaGqq+S2cA3lX5TJ2XdKz3EwPawB6uZf6sHUrWt5NMbwbotDQLTq0gXW6guL4I Cyrmb6EdqO5km8UkgWR7lSzm8fxORPg+X41gu33zb6/cv7hV3gmBbDPh3PVTyGfnAGOyUBSR CvzbrYtkByCMXUfdTdrx7jV1iD0TjxTJe8vJbTv3zjcIcTHGNnR+CZAx+qXTczLc8pL7DtDX okR5zZUuCgPGg/UWgUfBTUB6vibrAtrX9danRwaR61QCu3R6HSg520a9rfVXa1NqMYIEYDCC BFwCAQEwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBM YWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0 cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBB dXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQC2XBSNNPG96pBjyygW8FgSMAkGBSsOAwIaBQCg ggJwMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDUxMzA5 MzExN1owIwYJKoZIhvcNAQkEMRYEFBMRDyRnLsLAswMwqFjEsYL5yiKtMF8GCSqGSIb3DQEJ DzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG 9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB1QYJKwYBBAGCNxAEMYHHMIHEMIGu MQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4w HAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNl cnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRp b24gYW5kIEVtYWlsAhEAtlwUjTTxveqQY8soFvBYEjCB1wYLKoZIhvcNAQkQAgsxgceggcQw ga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkx HjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51 c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgRW1haWwCEQC2XBSNNPG96pBjyygW8FgSMA0GCSqGSIb3DQEBAQUABIIBAEDS jtcjXOjN6IVwYei4WZ9VWttYFx860hh+XGIs8gWMHwlzOn1QalynYG4w3z3+1rPg82kPjucO 79TskmMLW1bu3HheN1rqKr/IQilUD6pFIi/5EKvt56cAfBPNx+MHcU0fIafSJ4s2yYFYIiDH KmGm8KeLBHnpLMLS+WoPHs6Ib24/wL6HnbWvT8Bfd0Upil0NtKoQSDsG2I0WzImLk/LL6Wdi wlw9pH4sfURerLzXRGRwUEC5lldmlOafFfpmepPEbLoZp/cVT4rVVcxG4JNWOktkljwO1dm0 Ig1bJk41M4Ku1J/+NMD+ceRKDQ8dW8Gw1t+S6UUif3uBwotDot4AAAAAAAA= --------------ms060805040800040806080802-- From likepeng@huawei.com Fri May 13 02:40:15 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0E17E06BB for ; Fri, 13 May 2011 02:40:15 -0700 (PDT) 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.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oKHI7bIdFRG3 for ; Fri, 13 May 2011 02:40:15 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE1BE067B for ; Fri, 13 May 2011 02:40:15 -0700 (PDT) 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 <0LL400G2FO549D@szxga05-in.huawei.com> for core@ietf.org; Fri, 13 May 2011 17:39:04 +0800 (CST) Received: from szxeml201-edg.china.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 <0LL4005N3O4WH8@szxga05-in.huawei.com> for core@ietf.org; Fri, 13 May 2011 17:39:04 +0800 (CST) Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 13 May 2011 17:38:48 +0800 Received: from SZXEML506-MBX.china.huawei.com ([169.254.4.115]) by szxeml403-hub.china.huawei.com ([169.254.173.75]) with mapi id 14.01.0270.001; Fri, 13 May 2011 17:38:56 +0800 Date: Fri, 13 May 2011 09:38:56 +0000 From: Likepeng In-reply-to: <4DCCFA65.2040702@gridmerge.com> X-Originating-IP: [10.70.109.110] To: "robert.cragie@gridmerge.com" , core Message-id: <34966E97BE8AD64EAE9D3D6E4DEE36F2294258@szxeml506-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [core] Block names Thread-index: AQHMEVDtApV0VCNJBkahNCDkeVc1UJSKf5HQ X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <4DCCFA65.2040702@gridmerge.com> Subject: Re: [core] Block names X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 09:40:15 -0000 > Block1 and Block2 are not very helpful names. +1. When I read Block draft, I have to take notes to remind me from time to time which one is for what purpose. > BlockFromReq for Block1 and BlockFromRsp for Block2 or something? How about BlockReq and BlockRsp? BlockReq is for Put/Pust, and BlockRsp for Get. Kind Regards Kepeng -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Robert Cragie Sent: Friday, May 13, 2011 5:31 PM To: core Subject: [core] Block names Block1 and Block2 are not very helpful names. As they are tied to request and response, how about something like BlockFromReq for Block1 and BlockFromRsp for Block2 or something? BlockFromRsp in Request -> (expecting) A block in response BlockFromRsp in Response -> A block in response BlockFromReq in Request -> A block in request BlockFromReq in Response -> (received) A block in request Robert From zach@sensinode.com Fri May 13 03:31:26 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0331BE06BA for ; Fri, 13 May 2011 03:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id elldCGAAJben for ; Fri, 13 May 2011 03:31:25 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id C7943E06B4 for ; Fri, 13 May 2011 03:31:24 -0700 (PDT) Received: from [10.0.2.2] (87-93-144-167.bb.dnainternet.fi [87.93.144.167]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id p4DAVItv031191 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 13 May 2011 13:31:19 +0300 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-290-557964397; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: <005801cc1145$de8fe690$9bafb3b0$@uni-rostock.de> Date: Fri, 13 May 2011 13:31:18 +0300 Message-Id: References: <005801cc1145$de8fe690$9bafb3b0$@uni-rostock.de> To: Guido Moritz X-Mailer: Apple Mail (2.1084) Cc: 'core' Subject: Re: [core] Duplicates Dedection X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 10:31:26 -0000 --Apple-Mail-290-557964397 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Guido, On May 13, 2011, at 11:15 AM, Guido Moritz wrote: > For duplicates detection, coap-06 defines that matching can be made = through > the Message ID. Wouldn't it be useful also to have a few words that = for > matching purposes the source address should be considered as well. = (Not the > port since each MID must be unique for the same address) Yes, we have been meaning to add a few words related to this but for a = different problem. >=20 > We have a scenario in mind with a huge amount of sensor nodes, all = from the > same vendor, all with the same firmware. All are starting and using = the same > (not optimal) randomize algorithm for the initial MID and suddenly = there is > a high probability for the same MID to be received from to different > endpoints. In this case duplicates cannot only be detected on the CoAP > level. Right, so you are referring to this text: " A recipient MUST be prepared to receive the same confirmable message (as indicated by the Message ID) multiple times, for example, when its acknowledgement went missing or didn't reach the original sender before the first timeout. The recipient SHOULD acknowledge each duplicate copy of a confirmable message using the same acknowledgement or reset message, but SHOULD process any request or response in the message only once." The intention is that this should be per source IP address, so we should = change: (as indicated by the Message ID) -> (as indicated by the Message ID and = source IP address) In addition... you do run into a problem with a very large M2M service = which is making requests to a large number of M2M devices running CoAP = servers. If you keep a single MID pool here you can easily run out. One = implementation strategy to deal with that is to keep a separate MID for = each destination IP address, or for example for groups of nodes. I = think we need some text about that as well. > This might be too implementation specific, but having a few words on = using > also the address might be helpful. Will make a ticket to clarify these. Zach >=20 > Best, > Guido >=20 >=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-290-557964397 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 ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDUxMzEwMzEx OVowIwYJKoZIhvcNAQkEMRYEFGWOBe3m0mE6fGgyNbIUhIXUACcrMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBACWQn4MHJXk1JJ1UJ7Q0vC3LifgaXRIQ5ooKDyPm141sfer1fVfOWPYm HWaXTs+PjEtF4ZWLk0OyaQ2/U+gIVhe4MtgBPum1rv2/+M/1hfKRVdYpL/QyHMt6QXcaoaCXHXgw edPf4gK91I+vnRUdyi6LpfbpuPP4YgVRbGwzuV8Dm+EZXswg4RUHm2l3AOWMDzv6P+bMIbWnHTy/ W8BFalnWlO8nxaVzlAlnV2RgiJjWcXRpnejiWC6K6Zz4w+z6lJ3S51NJL2lJ8vgTa3ligp0DmSep W8Aci+F+5olF78m+vbFz305leS5X4nIqv4AwqTeLv3nbGoMKViqNdi4OCUYAAAAAAAA= --Apple-Mail-290-557964397-- From prvs=81145D58B7=guido.moritz@uni-rostock.de Fri May 13 03:49:31 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2639E07BE for ; Fri, 13 May 2011 03:49:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QHBOYojKJWGf for ; Fri, 13 May 2011 03:49:31 -0700 (PDT) Received: from mailrelay1.uni-rostock.de (mailrelay1.uni-rostock.de [139.30.8.201]) by ietfa.amsl.com (Postfix) with ESMTP id 7A31AE0754 for ; Fri, 13 May 2011 03:49:30 -0700 (PDT) From: Guido Moritz To: 'Zach Shelby' References: <005801cc1145$de8fe690$9bafb3b0$@uni-rostock.de> In-Reply-To: Date: Fri, 13 May 2011 12:49:47 +0200 Message-ID: <008b01cc115b$7a0780f0$6e1682d0$@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: AQCbYBWaOfrbYscGNNwxunUlAbkSBwLhfzjKltTp52A= Content-Language: de X-Originating-IP: [139.30.201.226] Cc: 'core' Subject: Re: [core] Duplicates Dedection X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 10:49:31 -0000 > (as indicated by the Message ID) -> (as indicated by the Message ID = and > source IP address) Most platforms surely will provide mechanisms to extract the IP source address. But should CoAP rely on? Maybe a bit more relaxed wording would = be: (as indicated by the Message ID and if required supplemented by = additional information like the source IP address) Guido > -----Urspr=FCngliche Nachricht----- > Von: Zach Shelby [mailto:zach@sensinode.com] > Gesendet: Freitag, 13. Mai 2011 12:31 > An: Guido Moritz > Cc: 'core' > Betreff: Re: [core] Duplicates Dedection >=20 > Guido, >=20 > On May 13, 2011, at 11:15 AM, Guido Moritz wrote: >=20 > > For duplicates detection, coap-06 defines that matching can be made > through > > the Message ID. Wouldn't it be useful also to have a few words that = for > > matching purposes the source address should be considered as well. = (Not > the > > port since each MID must be unique for the same address) >=20 > Yes, we have been meaning to add a few words related to this but for a > different problem. >=20 > > > > We have a scenario in mind with a huge amount of sensor nodes, all = from > the > > same vendor, all with the same firmware. All are starting and using = the > same > > (not optimal) randomize algorithm for the initial MID and suddenly = there is > > a high probability for the same MID to be received from to different > > endpoints. In this case duplicates cannot only be detected on the = CoAP > > level. >=20 > Right, so you are referring to this text: >=20 > " A recipient MUST be prepared to receive the same confirmable message > (as indicated by the Message ID) multiple times, for example, when > its acknowledgement went missing or didn't reach the original = sender > before the first timeout. The recipient SHOULD acknowledge each > duplicate copy of a confirmable message using the same > acknowledgement or reset message, but SHOULD process any request or > response in the message only once." >=20 > The intention is that this should be per source IP address, so we = should > change: >=20 > (as indicated by the Message ID) -> (as indicated by the Message ID = and > source IP address) >=20 > In addition... you do run into a problem with a very large M2M service which > is making requests to a large number of M2M devices running CoAP = servers. > If you keep a single MID pool here you can easily run out. One > implementation strategy to deal with that is to keep a separate MID = for each > destination IP address, or for example for groups of nodes. I think = we need > some text about that as well. >=20 > > This might be too implementation specific, but having a few words on using > > also the address might be helpful. >=20 > Will make a ticket to clarify these. >=20 > Zach >=20 > > > > Best, > > Guido > > > > > > > > _______________________________________________ > > 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 From cabo@tzi.org Fri May 13 03:57:27 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6D99E0701 for ; Fri, 13 May 2011 03:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X9iuLHtW6WcP for ; Fri, 13 May 2011 03:57:27 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id DAA1AE068C for ; Fri, 13 May 2011 03:57:26 -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 p4DAvIvY010795; Fri, 13 May 2011 12:57:18 +0200 (CEST) Received: from [10.0.1.2] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id CF1DF3E0; Fri, 13 May 2011 12:57:18 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <008b01cc115b$7a0780f0$6e1682d0$@uni-rostock.de> Date: Fri, 13 May 2011 12:57:17 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <005801cc1145$de8fe690$9bafb3b0$@uni-rostock.de> <008b01cc115b$7a0780f0$6e1682d0$@uni-rostock.de> To: Guido Moritz X-Mailer: Apple Mail (2.1084) Cc: 'core' Subject: Re: [core] Duplicates Dedection X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 10:57:27 -0000 On May 13, 2011, at 12:49, Guido Moritz wrote: > Most platforms surely will provide mechanisms to extract the IP source > address. (And port...) If they don't -- how do you send packets back? Destination address/port is harder. (See also the last paragraph of 10.3.3.) Gruesse, Carsten From prvs=011402B8CB=guido.moritz@uni-rostock.de Fri May 13 04:09:19 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03FC4E06AD for ; Fri, 13 May 2011 04:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f5M2WOfcqa7L for ; Fri, 13 May 2011 04:09:18 -0700 (PDT) Received: from mailrelay1.uni-rostock.de (mailrelay1.uni-rostock.de [139.30.8.201]) by ietfa.amsl.com (Postfix) with ESMTP id 49CD5E0684 for ; Fri, 13 May 2011 04:09:18 -0700 (PDT) From: Guido Moritz To: 'Carsten Bormann' References: <005801cc1145$de8fe690$9bafb3b0$@uni-rostock.de> <008b01cc115b$7a0780f0$6e1682d0$@uni-rostock.de> In-Reply-To: Date: Fri, 13 May 2011 13:09:36 +0200 Message-ID: <009001cc115e$3e8f52c0$bbadf840$@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: AQCbYBWaOfrbYscGNNwxunUlAbkSBwLhfzjKAbq4AI8Cr/OtBpaxmX+A Content-Language: de X-Originating-IP: [139.30.201.226] Cc: 'core' Subject: Re: [core] Duplicates Dedection X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 11:09:19 -0000 > (And port...) The port has no new information, since each MID is unique for each = message from the same source. This is only required if there is the same MID = from different sources. The source port can still be the same for both. > If they don't -- how do you send packets back? You can't. In the best case only one of the duplicates is answered and timeouts and retries have to solve it. Guido > -----Urspr=FCngliche Nachricht----- > Von: Carsten Bormann [mailto:cabo@tzi.org] > Gesendet: Freitag, 13. Mai 2011 12:57 > An: Guido Moritz > Cc: 'Zach Shelby'; 'core' > Betreff: Re: [core] Duplicates Dedection >=20 > On May 13, 2011, at 12:49, Guido Moritz wrote: >=20 > > Most platforms surely will provide mechanisms to extract the IP = source > > address. >=20 > (And port...) > If they don't -- how do you send packets back? > Destination address/port is harder. > (See also the last paragraph of 10.3.3.) >=20 > Gruesse, Carsten From kovatsch@inf.ethz.ch Fri May 13 04:34:27 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D291E0684 for ; Fri, 13 May 2011 04:34:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f51mtaVK39Db for ; Fri, 13 May 2011 04:34:26 -0700 (PDT) Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD99E0675 for ; Fri, 13 May 2011 04:34:25 -0700 (PDT) Received: from CAS10.d.ethz.ch (172.31.38.210) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.1.289.1; Fri, 13 May 2011 13:34:14 +0200 Received: from MBX20.d.ethz.ch ([fe80::81a7:b7a5:50c0:df0d]) by CAS10.d.ethz.ch ([fe80::cce:fc66:7b56:a06a%11]) with mapi id 14.01.0289.001; Fri, 13 May 2011 13:34:24 +0200 From: "Kovatsch Matthias" To: Likepeng , "robert.cragie@gridmerge.com" , core Thread-Topic: [core] Block names Thread-Index: AQHMEVCAIFrRp7OJ6UyrxDudxc03U5SKXv8AgAA+S2A= Date: Fri, 13 May 2011 11:34:23 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B508424562@MBX20.d.ethz.ch> References: <4DCCFA65.2040702@gridmerge.com> <34966E97BE8AD64EAE9D3D6E4DEE36F2294258@szxeml506-mbx.china.huawei.com> In-Reply-To: <34966E97BE8AD64EAE9D3D6E4DEE36F2294258@szxeml506-mbx.china.huawei.com> Accept-Language: en-US, de-CH Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [193.10.67.50] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [core] Block names X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 11:34:27 -0000 Hi I also had comment on that and just want to merge them. My idea would be Block2 --> Block-Down(stream/load/{}) and Block1 --> Block= -Up(stream/load/{}). Matthias wrote: > > > Would it be possible to provide meaningful names for the Block option= s? 1 and 2 in the order 2 (=3D17), 1 (=3D19) might cause a lot of confusion= ... > > > Block2 corresponds to server-side generated blocks and Block1 to clie= nt-side > > > generated blocks, right? > > >=20 > > > So, what about Block-Server and Block-Client or suchlike instead? Carsten wrote: > > As long as people don't start to think Block-Server options are always > > sent from the server and Block-Client options are sent from a client...= =20 > >=20 > > We went through a couple of these (Block-Request, Block-Response...) an= d > > decided Block1 and Block2 actually had the smallest confusion factor. = But I'm > > open to any suggestion. If people like B-S and B-C, I'm all for it. (= Spec > > reception, again, is a funny thing.) But let's brainstorm for good nam= es for a > > little more. Bye Matthias From robert.cragie@gridmerge.com Fri May 13 05:08:07 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E85C7E0700 for ; Fri, 13 May 2011 05:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKoXKmSld18U for ; Fri, 13 May 2011 05:08:07 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB1FE06D0 for ; Fri, 13 May 2011 05:08:07 -0700 (PDT) Received: from client-86-23-5-208.brhm.adsl.virginmedia.com ([86.23.5.208] helo=[192.168.1.80]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.73) id 1QKrA5-0003fY-Eh; Fri, 13 May 2011 13:08:05 +0100 Message-ID: <4DCD1F34.5030904@gridmerge.com> Date: Fri, 13 May 2011 13:08:20 +0100 From: Robert Cragie User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Likepeng References: <4DCCFA65.2040702@gridmerge.com> <34966E97BE8AD64EAE9D3D6E4DEE36F2294258@szxeml506-mbx.china.huawei.com> In-Reply-To: <34966E97BE8AD64EAE9D3D6E4DEE36F2294258@szxeml506-mbx.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-As: robert.cragie@gridmerge.com Cc: core Subject: Re: [core] Block names X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 12:08:08 -0000 I put the 'From' in as both options can be used in either request or response, so BlockReq might seem as that's what only you use in a request. I think the same could apply to your Size option for consistency: SizeFromRsp in Request -> (expecting) A (maximum) size in response SizeFromRsp in Response -> A size in response SizeFromReq in Request -> A size in request SizeFromReq in Response -> (would not typically occur as it's meaningless) In this way, the SizeFromRsp option in a request could be used to inform the responder that the requester cannot handle any more than the size in the option (even if it is sent in blocks) and the responder can then simply respond with a 4.13 (Request Entity Too Large) if it knows the resource is too large, although it may be better to relax the name to just 4.13 (Entity Too Large) in this case. Robert On 13/05/2011 10:38 AM, Likepeng wrote: >> Block1 and Block2 are not very helpful names. > +1. When I read Block draft, I have to take notes to remind me from time to time which one is for what purpose. > >> BlockFromReq for Block1 and BlockFromRsp for Block2 or something? > How about BlockReq and BlockRsp? BlockReq is for Put/Pust, and BlockRsp for Get. > > Kind Regards > Kepeng > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Robert Cragie > Sent: Friday, May 13, 2011 5:31 PM > To: core > Subject: [core] Block names > > Block1 and Block2 are not very helpful names. As they are tied to request and response, how about something like BlockFromReq for Block1 and BlockFromRsp for Block2 or something? > > BlockFromRsp in Request -> (expecting) A block in response BlockFromRsp in Response -> A block in response BlockFromReq in Request -> A block in request BlockFromReq in Response -> (received) A block in request > > Robert > From cabo@tzi.org Fri May 13 05:59:02 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8863E06D0 for ; Fri, 13 May 2011 05:59:02 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qj6DoJzCZ33t for ; Fri, 13 May 2011 05:59:02 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id D85DDE06B0 for ; Fri, 13 May 2011 05:59:01 -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 p4DCwjHj026829; Fri, 13 May 2011 14:58:45 +0200 (CEST) Received: from [10.0.1.2] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id C823548C; Fri, 13 May 2011 14:58:45 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <55877B3AFB359744BA0F2140E36F52B508424562@MBX20.d.ethz.ch> Date: Fri, 13 May 2011 14:58:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <684EB4DE-6A7C-4CC0-ABE6-94B433123F63@tzi.org> References: <4DCCFA65.2040702@gridmerge.com> <34966E97BE8AD64EAE9D3D6E4DEE36F2294258@szxeml506-mbx.china.huawei.com> <55877B3AFB359744BA0F2140E36F52B508424562@MBX20.d.ethz.ch> To: "Kovatsch Matthias" X-Mailer: Apple Mail (2.1084) Cc: core Subject: Re: [core] Block names X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 12:59:02 -0000 On May 13, 2011, at 13:34, Kovatsch Matthias wrote: > My idea would be Block2 --> Block-Down(stream/load/{}) and Block1 --> = Block-Up(stream/load/{}). If we have Up and Down, we inevitably will also get Charm, Strange, Top = and Bottom. (However, the latter four are much heavier, and therefore maybe not = appropriate for a lightweight protocol.) Gruesse, Carsten From kovatsch@inf.ethz.ch Fri May 13 06:09:59 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D9A4E06EE for ; Fri, 13 May 2011 06:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHS8+rlbVmp6 for ; Fri, 13 May 2011 06:09:56 -0700 (PDT) Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) by ietfa.amsl.com (Postfix) with ESMTP id DAAF2E06D0 for ; Fri, 13 May 2011 06:09:55 -0700 (PDT) Received: from CAS21.d.ethz.ch (172.31.51.111) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.1.289.1; Fri, 13 May 2011 15:09:44 +0200 Received: from MBX20.d.ethz.ch ([fe80::81a7:b7a5:50c0:df0d]) by CAS21.d.ethz.ch ([fe80::55ba:c4a5:d8a7:ab62%11]) with mapi id 14.01.0289.001; Fri, 13 May 2011 15:09:55 +0200 From: "Kovatsch Matthias" To: Carsten Bormann Thread-Topic: [core] Block names Thread-Index: AQHMEVCAIFrRp7OJ6UyrxDudxc03U5SKXv8AgAA+S2D///mJgIAAIpYw Date: Fri, 13 May 2011 13:09:54 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B508424601@MBX20.d.ethz.ch> References: <4DCCFA65.2040702@gridmerge.com> <34966E97BE8AD64EAE9D3D6E4DEE36F2294258@szxeml506-mbx.china.huawei.com> <55877B3AFB359744BA0F2140E36F52B508424562@MBX20.d.ethz.ch> <684EB4DE-6A7C-4CC0-ABE6-94B433123F63@tzi.org> In-Reply-To: <684EB4DE-6A7C-4CC0-ABE6-94B433123F63@tzi.org> Accept-Language: en-US, de-CH Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [193.10.67.50] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: core Subject: Re: [core] Block names X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 13:10:00 -0000 > > My idea would be Block2 --> Block-Down(stream/load/{}) and Block1 --> > Block-Up(stream/load/{}). >=20 > If we have Up and Down, we inevitably will also get Charm, Strange, Top a= nd > Bottom. > (However, the latter four are much heavier, and therefore maybe not > appropriate for a lightweight protocol.) Is it just a problem with the abbreviations that one's mind could get tunne= led to physics, or is there a real problem naming the the options according= to whether they define an upstream or a downstream block? These are the tw= o kinds of blocks we have, right? Regards Matthias From robert.cragie@gridmerge.com Fri May 13 06:50:50 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F09FE06C2 for ; Fri, 13 May 2011 06:50:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zjdz-Ta2yY8k for ; Fri, 13 May 2011 06:50:50 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by ietfa.amsl.com (Postfix) with ESMTP id 943C6E069B for ; Fri, 13 May 2011 06:50:49 -0700 (PDT) Received: from client-86-23-5-208.brhm.adsl.virginmedia.com ([86.23.5.208] helo=[192.168.1.80]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.73) id 1QKslK-0001us-Ry; Fri, 13 May 2011 14:50:39 +0100 Message-ID: <4DCD373D.1090603@gridmerge.com> Date: Fri, 13 May 2011 14:50:53 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Kovatsch Matthias References: <4DCCFA65.2040702@gridmerge.com> <34966E97BE8AD64EAE9D3D6E4DEE36F2294258@szxeml506-mbx.china.huawei.com> <55877B3AFB359744BA0F2140E36F52B508424562@MBX20.d.ethz.ch> <684EB4DE-6A7C-4CC0-ABE6-94B433123F63@tzi.org> <55877B3AFB359744BA0F2140E36F52B508424601@MBX20.d.ethz.ch> In-Reply-To: <55877B3AFB359744BA0F2140E36F52B508424601@MBX20.d.ethz.ch> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090500090404080701050106" X-Authenticated-As: robert.cragie@gridmerge.com Cc: core Subject: Re: [core] Block names X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 13:50:50 -0000 This is a cryptographically signed message in MIME format. --------------ms090500090404080701050106 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable There is no use of 'up(stream/load)' and 'down(stream/load)' in CoAP.=20 Hence suggesting using Req (Request) and Rsp (Response), which are of=20 course central to CoAP. Robert On 13/05/2011 2:09 PM, Kovatsch Matthias wrote: >>> My idea would be Block2 --> Block-Down(stream/load/{}) and Block1 --= > >> Block-Up(stream/load/{}). >> >> If we have Up and Down, we inevitably will also get Charm, Strange, To= p and >> Bottom. >> (However, the latter four are much heavier, and therefore maybe not >> appropriate for a lightweight protocol.) > Is it just a problem with the abbreviations that one's mind could get t= unneled to physics, or is there a real problem naming the the options acc= ording to whether they define an upstream or a downstream block? These ar= e the two kinds of blocks we have, right? > > Regards > Matthias > --------------ms090500090404080701050106 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIREjCC BIowggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w NTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMC VVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l dHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVN NRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQy lbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXq vgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6 hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu 9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0G A1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/ BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9BZGRU cnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8ubmV0L0Fk ZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyispgCi 54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0 g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHd WTBK322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftz Mizpm4QkLdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsy XEFs/vVdoOr/0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIGPjCCBSagAwIBAgIRALZcFI008b3q kGPLKBbwWBIwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEX MBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29y azEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMTAwODMwMDAwMDAw WhcNMTEwODMwMjM1OTU5WjCB5DE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQ RVJTT05BIE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9m IHVzZTogaHR0cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIw MDMgQ29tb2RvIExpbWl0ZWQxFjAUBgNVBAMTDVJvYmVydCBDcmFnaWUxKjAoBgkqhkiG9w0B CQEWG3JvYmVydC5jcmFnaWVAZ3JpZG1lcmdlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALQCfpvU4Hd5YvAYACEbYRrbYd2HAm4Sz43wHJwynBBkq5GamqO/SYNrg1ut iDsDQqvWnt1cHgZb4N1FFbvLqV84A0f4xc+EtWTZNYn+lfUBIsgR3RNajFEHnsrXnZN6sPdw lObJ1ol4FUWnFPB/A7/liT7G+FmAB+DAc2iTCNjfxOVxhmKShY/b8ZxIkO4fN418cNxHtq1w gm4SRHIv7VJfgseNKQd5u55RHQEmPgN7aiSyIhvAK4H9Pm1msZrklIoSqGpIR0K7gMpVmPRF bWyoPEgAmGYXRwsdvmUkq8W2wCkr9HA5NNL0D74B+RhIus0gfUL6lgnQR/6y9F31eY0CAwEA AaOCAh0wggIZMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBRp GoTqjgTJPeVwG/HaXEXWnn/AGDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNV HSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1Ud IAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNv bW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2Eu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRp Y2F0aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDov L2NydC5jb21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC5jb21vZG9jYS5jb20wJgYDVR0RBB8wHYEbcm9iZXJ0LmNyYWdpZUBncmlkbWVy Z2UuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQA3I0iUCoFSHw/yM7Ra4cdmKkfZirA7N12pCneI VKHrpx4LJImjCEGNinH6G+PDrs632O96zXzaGqq+S2cA3lX5TJ2XdKz3EwPawB6uZf6sHUrW t5NMbwbotDQLTq0gXW6guL4ICyrmb6EdqO5km8UkgWR7lSzm8fxORPg+X41gu33zb6/cv7hV 3gmBbDPh3PVTyGfnAGOyUBSRCvzbrYtkByCMXUfdTdrx7jV1iD0TjxTJe8vJbTv3zjcIcTHG NnR+CZAx+qXTczLc8pL7DtDXokR5zZUuCgPGg/UWgUfBTUB6vibrAtrX9danRwaR61QCu3R6 HSg520a9rfVXa1NqMIIGPjCCBSagAwIBAgIRALZcFI008b3qkGPLKBbwWBIwDQYJKoZIhvcN AQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtl IENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDov L3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMTAwODMwMDAwMDAwWhcNMTEwODMwMjM1OTU5WjCB 5DE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05BIE5PVCBWQUxJREFU RUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0cDovL3d3dy5j b21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExpbWl0ZWQx FjAUBgNVBAMTDVJvYmVydCBDcmFnaWUxKjAoBgkqhkiG9w0BCQEWG3JvYmVydC5jcmFnaWVA Z3JpZG1lcmdlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALQCfpvU4Hd5 YvAYACEbYRrbYd2HAm4Sz43wHJwynBBkq5GamqO/SYNrg1utiDsDQqvWnt1cHgZb4N1FFbvL qV84A0f4xc+EtWTZNYn+lfUBIsgR3RNajFEHnsrXnZN6sPdwlObJ1ol4FUWnFPB/A7/liT7G +FmAB+DAc2iTCNjfxOVxhmKShY/b8ZxIkO4fN418cNxHtq1wgm4SRHIv7VJfgseNKQd5u55R HQEmPgN7aiSyIhvAK4H9Pm1msZrklIoSqGpIR0K7gMpVmPRFbWyoPEgAmGYXRwsdvmUkq8W2 wCkr9HA5NNL0D74B+RhIus0gfUL6lgnQR/6y9F31eY0CAwEAAaOCAh0wggIZMB8GA1UdIwQY MBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBRpGoTqjgTJPeVwG/HaXEXWnn/A GDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYL KwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQEC AQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNV HR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL1VUTi1VU0VSRmlyc3Qt Q2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBIoEaGRGh0dHA6Ly9jcmwuY29t b2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3Js MGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5jb21vZG9jYS5jb20v VVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5j b20wJgYDVR0RBB8wHYEbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQA3I0iUCoFSHw/yM7Ra4cdmKkfZirA7N12pCneIVKHrpx4LJImjCEGNinH6G+PD rs632O96zXzaGqq+S2cA3lX5TJ2XdKz3EwPawB6uZf6sHUrWt5NMbwbotDQLTq0gXW6guL4I Cyrmb6EdqO5km8UkgWR7lSzm8fxORPg+X41gu33zb6/cv7hV3gmBbDPh3PVTyGfnAGOyUBSR CvzbrYtkByCMXUfdTdrx7jV1iD0TjxTJe8vJbTv3zjcIcTHGNnR+CZAx+qXTczLc8pL7DtDX okR5zZUuCgPGg/UWgUfBTUB6vibrAtrX9danRwaR61QCu3R6HSg520a9rfVXa1NqMYIEYDCC BFwCAQEwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBM YWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0 cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBB dXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQC2XBSNNPG96pBjyygW8FgSMAkGBSsOAwIaBQCg ggJwMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDUxMzEz NTA1M1owIwYJKoZIhvcNAQkEMRYEFNa6PYHIVJx+vB9gulbLzOZJYnaWMF8GCSqGSIb3DQEJ DzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG 9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB1QYJKwYBBAGCNxAEMYHHMIHEMIGu MQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4w HAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNl cnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRp b24gYW5kIEVtYWlsAhEAtlwUjTTxveqQY8soFvBYEjCB1wYLKoZIhvcNAQkQAgsxgceggcQw ga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkx HjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51 c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgRW1haWwCEQC2XBSNNPG96pBjyygW8FgSMA0GCSqGSIb3DQEBAQUABIIBAIds aPPUX8lP+4Q7dAGPz2WRSOlupfCVnIeEXvXEBJAaXVVttAe/q64TOJVo5lmTIli28IVLpCAx tvEZmLS13rocFN05M3I51Ko66cdpy2oX7P9E5cJ4pizmD+2bMCF2zYn3jvLnad0isaGhXZ/F uSFpL3wfF3PQrdNGiZmT/vK2v6Q9LjynjLEzaaEdqV7OIX8maXuOR91u6CkzdmSqVg7zILAh zNdo47JvW5FCY3yD85moZoFTz86/bDHkvZQMvCntpnT24zgEfc/eyCCyaec6qaPuxUsmrKFB NBPPT/YstHAw2ZDk6qNkIy8EjfsJF+QflYuas8Mi6iIrg9aBhugAAAAAAAA= --------------ms090500090404080701050106-- From kovatsch@inf.ethz.ch Fri May 13 06:58:24 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6D12E06D6 for ; Fri, 13 May 2011 06:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RceQ8I8jDLpv for ; Fri, 13 May 2011 06:58:24 -0700 (PDT) Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) by ietfa.amsl.com (Postfix) with ESMTP id 00805E069B for ; Fri, 13 May 2011 06:58:23 -0700 (PDT) Received: from CAS20.d.ethz.ch (172.31.51.110) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.1.289.1; Fri, 13 May 2011 15:58:13 +0200 Received: from MBX20.d.ethz.ch ([fe80::81a7:b7a5:50c0:df0d]) by CAS20.d.ethz.ch ([fe80::2cd8:4907:7776:c56d%11]) with mapi id 14.01.0289.001; Fri, 13 May 2011 15:58:23 +0200 From: "Kovatsch Matthias" To: "robert.cragie@gridmerge.com" Thread-Topic: AW: [core] Block names Thread-Index: AQHMEVCAIFrRp7OJ6UyrxDudxc03U5SKXv8AgAA+S2D///mJgIAAIpYw///r+4CAACHrEA== Date: Fri, 13 May 2011 13:58:22 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B508424652@MBX20.d.ethz.ch> References: <4DCCFA65.2040702@gridmerge.com> <34966E97BE8AD64EAE9D3D6E4DEE36F2294258@szxeml506-mbx.china.huawei.com> <55877B3AFB359744BA0F2140E36F52B508424562@MBX20.d.ethz.ch> <684EB4DE-6A7C-4CC0-ABE6-94B433123F63@tzi.org> <55877B3AFB359744BA0F2140E36F52B508424601@MBX20.d.ethz.ch> <4DCD373D.1090603@gridmerge.com> In-Reply-To: <4DCD373D.1090603@gridmerge.com> Accept-Language: en-US, de-CH Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [193.10.67.50] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: core Subject: Re: [core] Block names X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 13:58:24 -0000 > There is no use of 'up(stream/load)' and 'down(stream/load)' in CoAP. > Hence suggesting using Req (Request) and Rsp (Response), which are of > course central to CoAP. But we have servers and clients and upstream usually means client->server a= nd downstream server->client. I must +1 Carsten's opinion that Block-Req could be confused with "that opt= ion is to be set in a request and Block-Rsp in a response". From trac+core@trac.tools.ietf.org Fri May 13 07:03:27 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20729E06D6 for ; Fri, 13 May 2011 07:03:27 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id unMlW4J+pkdF for ; Fri, 13 May 2011 07:03:26 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id BF8B9E069B for ; Fri, 13 May 2011 07:03:26 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QKsxf-00015R-2E; Fri, 13 May 2011 07:03:23 -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: Fri, 13 May 2011 14:03:23 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/151 Message-ID: <057.a0dfde1ed2d36d2bf749f251f2a956f4@trac.tools.ietf.org> X-Trac-Ticket-ID: 151 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+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] #151: Clarify matching rules for messages and tokens X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 14:03:27 -0000 #151: Clarify matching rules for messages and tokens It was brought up that the matching rules for messages should be clarified as the current Section 4.1 text: " A recipient MUST be prepared to receive the same confirmable message (as indicated by the Message ID) multiple times, for example, when its acknowledgement went missing or didn't reach the original sender before the first timeout. The recipient SHOULD acknowledge each duplicate copy of a confirmable message using the same acknowledgement or reset message, but SHOULD process any request or response in the message only once." is not clear that the ACK is matched with the MID and additional address information. This ticket is to further clarify the above text and ensure similar matching rules are defined in Section 5 for tokens. -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: cabo@… Type: protocol defect | Status: new Priority: minor | Milestone: Component: coap | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From robert.cragie@gridmerge.com Fri May 13 07:06:16 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 168CAE06D6 for ; Fri, 13 May 2011 07:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cIrivgxOfNfj for ; Fri, 13 May 2011 07:06:15 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by ietfa.amsl.com (Postfix) with ESMTP id 402CDE069B for ; Fri, 13 May 2011 07:06:15 -0700 (PDT) Received: from client-86-23-5-208.brhm.adsl.virginmedia.com ([86.23.5.208] helo=[192.168.1.80]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.73) id 1QKt04-0000pI-VD; Fri, 13 May 2011 15:05:53 +0100 Message-ID: <4DCD3AD0.6040301@gridmerge.com> Date: Fri, 13 May 2011 15:06:08 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Kovatsch Matthias References: <4DCCFA65.2040702@gridmerge.com> <34966E97BE8AD64EAE9D3D6E4DEE36F2294258@szxeml506-mbx.china.huawei.com> <55877B3AFB359744BA0F2140E36F52B508424562@MBX20.d.ethz.ch> <684EB4DE-6A7C-4CC0-ABE6-94B433123F63@tzi.org> <55877B3AFB359744BA0F2140E36F52B508424601@MBX20.d.ethz.ch> <4DCD373D.1090603@gridmerge.com> <55877B3AFB359744BA0F2140E36F52B508424652@MBX20.d.ethz.ch> In-Reply-To: <55877B3AFB359744BA0F2140E36F52B508424652@MBX20.d.ethz.ch> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000900080404020109030301" X-Authenticated-As: robert.cragie@gridmerge.com Cc: core Subject: Re: [core] Block names X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 14:06:16 -0000 This is a cryptographically signed message in MIME format. --------------ms000900080404020109030301 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Which is why is suggested BlockFromReq and BlockFromRsp Robert On 13/05/2011 2:58 PM, Kovatsch Matthias wrote: >> There is no use of 'up(stream/load)' and 'down(stream/load)' in CoAP. >> Hence suggesting using Req (Request) and Rsp (Response), which are of >> course central to CoAP. > But we have servers and clients and upstream usually means client->serv= er and downstream server->client. > > I must +1 Carsten's opinion that Block-Req could be confused with "that= option is to be set in a request and Block-Rsp in a response". > > --------------ms000900080404020109030301 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIREjCC BIowggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w NTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMC VVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l dHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVN NRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQy lbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXq vgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6 hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu 9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0G A1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/ BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9BZGRU cnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8ubmV0L0Fk ZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyispgCi 54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0 g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHd WTBK322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftz Mizpm4QkLdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsy XEFs/vVdoOr/0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIGPjCCBSagAwIBAgIRALZcFI008b3q kGPLKBbwWBIwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEX MBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29y azEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMTAwODMwMDAwMDAw WhcNMTEwODMwMjM1OTU5WjCB5DE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQ RVJTT05BIE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9m IHVzZTogaHR0cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIw MDMgQ29tb2RvIExpbWl0ZWQxFjAUBgNVBAMTDVJvYmVydCBDcmFnaWUxKjAoBgkqhkiG9w0B CQEWG3JvYmVydC5jcmFnaWVAZ3JpZG1lcmdlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALQCfpvU4Hd5YvAYACEbYRrbYd2HAm4Sz43wHJwynBBkq5GamqO/SYNrg1ut iDsDQqvWnt1cHgZb4N1FFbvLqV84A0f4xc+EtWTZNYn+lfUBIsgR3RNajFEHnsrXnZN6sPdw lObJ1ol4FUWnFPB/A7/liT7G+FmAB+DAc2iTCNjfxOVxhmKShY/b8ZxIkO4fN418cNxHtq1w gm4SRHIv7VJfgseNKQd5u55RHQEmPgN7aiSyIhvAK4H9Pm1msZrklIoSqGpIR0K7gMpVmPRF bWyoPEgAmGYXRwsdvmUkq8W2wCkr9HA5NNL0D74B+RhIus0gfUL6lgnQR/6y9F31eY0CAwEA AaOCAh0wggIZMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBRp GoTqjgTJPeVwG/HaXEXWnn/AGDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNV HSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1Ud IAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNv bW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2Eu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRp Y2F0aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDov L2NydC5jb21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC5jb21vZG9jYS5jb20wJgYDVR0RBB8wHYEbcm9iZXJ0LmNyYWdpZUBncmlkbWVy Z2UuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQA3I0iUCoFSHw/yM7Ra4cdmKkfZirA7N12pCneI VKHrpx4LJImjCEGNinH6G+PDrs632O96zXzaGqq+S2cA3lX5TJ2XdKz3EwPawB6uZf6sHUrW t5NMbwbotDQLTq0gXW6guL4ICyrmb6EdqO5km8UkgWR7lSzm8fxORPg+X41gu33zb6/cv7hV 3gmBbDPh3PVTyGfnAGOyUBSRCvzbrYtkByCMXUfdTdrx7jV1iD0TjxTJe8vJbTv3zjcIcTHG NnR+CZAx+qXTczLc8pL7DtDXokR5zZUuCgPGg/UWgUfBTUB6vibrAtrX9danRwaR61QCu3R6 HSg520a9rfVXa1NqMIIGPjCCBSagAwIBAgIRALZcFI008b3qkGPLKBbwWBIwDQYJKoZIhvcN AQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtl IENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDov L3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMTAwODMwMDAwMDAwWhcNMTEwODMwMjM1OTU5WjCB 5DE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05BIE5PVCBWQUxJREFU RUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0cDovL3d3dy5j b21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExpbWl0ZWQx FjAUBgNVBAMTDVJvYmVydCBDcmFnaWUxKjAoBgkqhkiG9w0BCQEWG3JvYmVydC5jcmFnaWVA Z3JpZG1lcmdlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALQCfpvU4Hd5 YvAYACEbYRrbYd2HAm4Sz43wHJwynBBkq5GamqO/SYNrg1utiDsDQqvWnt1cHgZb4N1FFbvL qV84A0f4xc+EtWTZNYn+lfUBIsgR3RNajFEHnsrXnZN6sPdwlObJ1ol4FUWnFPB/A7/liT7G +FmAB+DAc2iTCNjfxOVxhmKShY/b8ZxIkO4fN418cNxHtq1wgm4SRHIv7VJfgseNKQd5u55R HQEmPgN7aiSyIhvAK4H9Pm1msZrklIoSqGpIR0K7gMpVmPRFbWyoPEgAmGYXRwsdvmUkq8W2 wCkr9HA5NNL0D74B+RhIus0gfUL6lgnQR/6y9F31eY0CAwEAAaOCAh0wggIZMB8GA1UdIwQY MBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBRpGoTqjgTJPeVwG/HaXEXWnn/A GDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYL KwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQEC AQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNV HR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL1VUTi1VU0VSRmlyc3Qt Q2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBIoEaGRGh0dHA6Ly9jcmwuY29t b2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3Js MGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5jb21vZG9jYS5jb20v VVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5j b20wJgYDVR0RBB8wHYEbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQA3I0iUCoFSHw/yM7Ra4cdmKkfZirA7N12pCneIVKHrpx4LJImjCEGNinH6G+PD rs632O96zXzaGqq+S2cA3lX5TJ2XdKz3EwPawB6uZf6sHUrWt5NMbwbotDQLTq0gXW6guL4I Cyrmb6EdqO5km8UkgWR7lSzm8fxORPg+X41gu33zb6/cv7hV3gmBbDPh3PVTyGfnAGOyUBSR CvzbrYtkByCMXUfdTdrx7jV1iD0TjxTJe8vJbTv3zjcIcTHGNnR+CZAx+qXTczLc8pL7DtDX okR5zZUuCgPGg/UWgUfBTUB6vibrAtrX9danRwaR61QCu3R6HSg520a9rfVXa1NqMYIEYDCC BFwCAQEwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBM YWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0 cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBB dXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQC2XBSNNPG96pBjyygW8FgSMAkGBSsOAwIaBQCg ggJwMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDUxMzE0 MDYwOFowIwYJKoZIhvcNAQkEMRYEFII8VNJ6QCCTEQfj5PCD6PdwEibJMF8GCSqGSIb3DQEJ DzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG 9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB1QYJKwYBBAGCNxAEMYHHMIHEMIGu MQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4w HAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNl cnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRp b24gYW5kIEVtYWlsAhEAtlwUjTTxveqQY8soFvBYEjCB1wYLKoZIhvcNAQkQAgsxgceggcQw ga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkx HjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51 c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgRW1haWwCEQC2XBSNNPG96pBjyygW8FgSMA0GCSqGSIb3DQEBAQUABIIBAGFr tHMZzANEw5lFnRVjqJAOexWSfdui6SFMw+4S8Wd40POuOkyNgm0AJfs9f7s46w4l5ZK2xtHF y0oDCcO011LocdSxe5rm+tR1eNelNfPBxT2dQDnOKH3NBz6DNdIpU5/vpqNwxi7txxxHjlse Fw8EGtk3DCuZ87zGyt2fi+QFfiLRlp/r7ZVdEegu+Dvyd6EvbHBbfwhiZkFKzL9uZp6wepGO Uewm3Mb+RYQiGgK4r8CCZl/az2ai/cTSs6MeKtzpApmUjKvew0EEyVuP+BD3+MssBGaiTExJ UR9BZlcm7XnJWGpF1EZbqelV8tXPkHlq55A5th0BHoINfC6SThYAAAAAAAA= --------------ms000900080404020109030301-- From zach@sensinode.com Fri May 13 07:10:57 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD196E06D6 for ; Fri, 13 May 2011 07:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2xyPsV2nu8Hk for ; Fri, 13 May 2011 07:10:56 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id E2CD2E069B for ; Fri, 13 May 2011 07:10:55 -0700 (PDT) Received: from [192.168.1.43] (a91-156-92-242.elisa-laajakaista.fi [91.156.92.242]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id p4DEAlrT003197 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 13 May 2011 17:10:48 +0300 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-314-571134596; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: <4DCCF405.2050500@gridmerge.com> Date: Fri, 13 May 2011 17:10:48 +0300 Message-Id: <7B94A27A-A5BE-42C0-9876-9CD44D7666EA@sensinode.com> References: <239072CD-ACC0-454D-8BD6-30AC28D425D9@cisco.com> <720981EA-6411-4A5C-AC8C-675ADA1A2DE5@cisco.com> <8BCD950E-FB93-40EE-848C-466E5152DA7C@cisco.com> <223489D8-F2DC-45D1-A690-13480534C1B2@cisco.com> <-3335568933846752161@unknownmsgid> <005101cc10d5$9697a1e0$c3c6e5a0$@yegin@yegin.org> <4DCC45D3.2020304@gridmerge.com> <00bb01cc110e$8e3cb7e0$aab627a0$@yegin@yegin.org> <4DCCF405.2050500@gridmerge.com> To: robert.cragie@gridmerge.com X-Mailer: Apple Mail (2.1084) Cc: core@ietf.org Subject: Re: [core] draft-ietf-core-coap-06 Security X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 14:10:57 -0000 --Apple-Mail-314-571134596 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This object security discussion is totally orthogonal to the DTLS = security that is default in CoAP (so this really isn't relevant to = core-coap-06). Object security is definitely interesting in this domain, = and for example the JSON signing BOF in Prague was relevant to this. I = would encourage Alper to write a draft about how to do simple object = security for CoAP. Robert is right that the security model in the CoRE = context should be an important part of that, as well as bootstrapping = considerations.=20 Zach On May 13, 2011, at 12:04 PM, Robert Cragie wrote: >=20 >=20 > On 13/05/2011 2:39 AM, Alper Yegin wrote: >>>> I'm not singling out TLS here. I think this is a fundamental >>>> distinction between channel security vs object-level security. >>> It seems fundamentally easier to encrypt on a channel basis as the = same >>> end-point credentials are used to derive keying information which = can >>> encrypt and integrity protect simultaneously, >> Using object-level security does not change that. > Perhaps I misunderstood what you meant by object-level security. The = way you described it seemed to suggest that elements of data transacted = within the channel could be individually encrypted. My questions = surround what security material is used to perform the encryption in = each case. >>> e.g. most efficiently >>> using an AEAD cipher like AES-CCM or AES-GCM. If you start to make = the >>> encryption more granular, what do you then use as the cryptographic >>> basis for secrecy between the transacting objects? Asymmetric or >>> symmetric? >> Symmetric. >>=20 >>> Would you use the same granularity as the channel end >>> points? >>> Or be more granular? >> Not sure I understand. Can you elaborate? > As above - what security material would you use to encrypt? The same = security material as is used for channel encryption? Or something more = granular, i.e. would each distinct element of encrypted data have its = own security material? What is the distinction? If communicating objects = multiplex their transactions on a single channel, this could be the = case. >>> All I'm saying is there is probably more to this than meets the eye. >> Let's find out. >>=20 >> Alper >>=20 >>=20 >>=20 >>=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://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-314-571134596 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 ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDUxMzE0MTA0 OVowIwYJKoZIhvcNAQkEMRYEFObAU5gNkOVCySpVa2N8CaUpzWLxMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAEy2WdrM2Fv3Uzi1WomBtjyhxlsry6Q7kqmyfPBOw+UC/g+B1UD5bBQc hgO7qQbl2i1YZQKdpFIa8eoF2T9A8d1ZFbX9PYZLzn5iVtVwP5+Q7yveDqnao5qZrrqvhYOzzGmM GtGIbhr0RiNVZnCZvTqXmM9EDF5b6DGdxvbXfiVeiDnR2Spbk01Gu63+7hDW0qcXOXedK655he/h EQojwtxGwbvNHN/wyDUTVD1ejkeMaiGEHokXkgYjqP0AnWTBN/ZzqcPPK8AgAoenN13tAGEqX395 dy2e/+hzGmKrxg4tvJ2hou0YdS+bQ78Vz0z1ZF0UVV30DuNszKOE0JR0enYAAAAAAAA= --Apple-Mail-314-571134596-- From robert.cragie@gridmerge.com Fri May 13 07:22:59 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16B51E069B for ; Fri, 13 May 2011 07:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J063spvb-FAd for ; Fri, 13 May 2011 07:22:58 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by ietfa.amsl.com (Postfix) with ESMTP id 21C4EE065A for ; Fri, 13 May 2011 07:22:57 -0700 (PDT) Received: from client-86-23-5-208.brhm.adsl.virginmedia.com ([86.23.5.208] helo=[192.168.1.80]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.73) id 1QKtGZ-00026O-9V; Fri, 13 May 2011 15:22:55 +0100 Message-ID: <4DCD3ECE.2070906@gridmerge.com> Date: Fri, 13 May 2011 15:23:10 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Zach Shelby References: <239072CD-ACC0-454D-8BD6-30AC28D425D9@cisco.com> <720981EA-6411-4A5C-AC8C-675ADA1A2DE5@cisco.com> <8BCD950E-FB93-40EE-848C-466E5152DA7C@cisco.com> <223489D8-F2DC-45D1-A690-13480534C1B2@cisco.com> <-3335568933846752161@unknownmsgid> <005101cc10d5$9697a1e0$c3c6e5a0$@yegin@yegin.org> <4DCC45D3.2020304@gridmerge.com> <00bb01cc110e$8e3cb7e0$aab627a0$@yegin@yegin.org> <4DCCF405.2050500@gridmerge.com> <7B94A27A-A5BE-42C0-9876-9CD44D7666EA@sensinode.com> In-Reply-To: <7B94A27A-A5BE-42C0-9876-9CD44D7666EA@sensinode.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050206030504000200050308" X-Authenticated-As: robert.cragie@gridmerge.com Cc: core@ietf.org Subject: Re: [core] draft-ietf-core-coap-06 Security X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 14:22:59 -0000 This is a cryptographically signed message in MIME format. --------------ms050206030504000200050308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Zach, I wouldn't say totally orthogonal - this spun off from a discussion as=20 to whether DTLS was indeed the right choice for security and whether we=20 could define a CoAP security (for example, like RPL did). However, my=20 view is that DTLS is the right choice. Robert On 13/05/2011 3:10 PM, Zach Shelby wrote: > This object security discussion is totally orthogonal to the DTLS secur= ity that is default in CoAP (so this really isn't relevant to core-coap-0= 6). Object security is definitely interesting in this domain, and for exa= mple the JSON signing BOF in Prague was relevant to this. I would encoura= ge Alper to write a draft about how to do simple object security for CoAP= =2E Robert is right that the security model in the CoRE context should be= an important part of that, as well as bootstrapping considerations. > > Zach > > On May 13, 2011, at 12:04 PM, Robert Cragie wrote: > >> >> On 13/05/2011 2:39 AM, Alper Yegin wrote: >>>>> I'm not singling out TLS here. I think this is a fundamental >>>>> distinction between channel security vs object-level security. >>>> It seems fundamentally easier to encrypt on a channel basis as the s= ame >>>> end-point credentials are used to derive keying information which ca= n >>>> encrypt and integrity protect simultaneously, >>> Using object-level security does not change that. >> Perhaps I misunderstood what you meant by object-level security. The w= ay you described it seemed to suggest that elements of data transacted wi= thin the channel could be individually encrypted. My questions surround w= hat security material is used to perform the encryption in each case. >>>> e.g. most efficiently >>>> using an AEAD cipher like AES-CCM or AES-GCM. If you start to make t= he >>>> encryption more granular, what do you then use as the cryptographic >>>> basis for secrecy between the transacting objects? Asymmetric or >>>> symmetric? >>> Symmetric. >>> >>>> Would you use the same granularity as the channel end >>>> points? >>>> Or be more granular? >>> Not sure I understand. Can you elaborate? >> As above - what security material would you use to encrypt? The same s= ecurity material as is used for channel encryption? Or something more gra= nular, i.e. would each distinct element of encrypted data have its own se= curity material? What is the distinction? If communicating objects multip= lex their transactions on a single channel, this could be the case. >>>> All I'm saying is there is probably more to this than meets the eye.= >>> Let's find out. >>> >>> Alper >>> >>> >>> >>> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core --------------ms050206030504000200050308 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIREjCC BIowggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w NTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMC VVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l dHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVN NRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQy lbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXq vgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6 hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu 9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0G A1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/ BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9BZGRU cnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8ubmV0L0Fk ZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyispgCi 54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0 g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHd WTBK322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftz Mizpm4QkLdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsy XEFs/vVdoOr/0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIGPjCCBSagAwIBAgIRALZcFI008b3q kGPLKBbwWBIwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEX MBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29y azEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMTAwODMwMDAwMDAw WhcNMTEwODMwMjM1OTU5WjCB5DE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQ RVJTT05BIE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9m IHVzZTogaHR0cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIw MDMgQ29tb2RvIExpbWl0ZWQxFjAUBgNVBAMTDVJvYmVydCBDcmFnaWUxKjAoBgkqhkiG9w0B CQEWG3JvYmVydC5jcmFnaWVAZ3JpZG1lcmdlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALQCfpvU4Hd5YvAYACEbYRrbYd2HAm4Sz43wHJwynBBkq5GamqO/SYNrg1ut iDsDQqvWnt1cHgZb4N1FFbvLqV84A0f4xc+EtWTZNYn+lfUBIsgR3RNajFEHnsrXnZN6sPdw lObJ1ol4FUWnFPB/A7/liT7G+FmAB+DAc2iTCNjfxOVxhmKShY/b8ZxIkO4fN418cNxHtq1w gm4SRHIv7VJfgseNKQd5u55RHQEmPgN7aiSyIhvAK4H9Pm1msZrklIoSqGpIR0K7gMpVmPRF bWyoPEgAmGYXRwsdvmUkq8W2wCkr9HA5NNL0D74B+RhIus0gfUL6lgnQR/6y9F31eY0CAwEA AaOCAh0wggIZMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBRp GoTqjgTJPeVwG/HaXEXWnn/AGDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNV HSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1Ud IAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNv bW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2Eu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRp Y2F0aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDov L2NydC5jb21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC5jb21vZG9jYS5jb20wJgYDVR0RBB8wHYEbcm9iZXJ0LmNyYWdpZUBncmlkbWVy Z2UuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQA3I0iUCoFSHw/yM7Ra4cdmKkfZirA7N12pCneI VKHrpx4LJImjCEGNinH6G+PDrs632O96zXzaGqq+S2cA3lX5TJ2XdKz3EwPawB6uZf6sHUrW t5NMbwbotDQLTq0gXW6guL4ICyrmb6EdqO5km8UkgWR7lSzm8fxORPg+X41gu33zb6/cv7hV 3gmBbDPh3PVTyGfnAGOyUBSRCvzbrYtkByCMXUfdTdrx7jV1iD0TjxTJe8vJbTv3zjcIcTHG NnR+CZAx+qXTczLc8pL7DtDXokR5zZUuCgPGg/UWgUfBTUB6vibrAtrX9danRwaR61QCu3R6 HSg520a9rfVXa1NqMIIGPjCCBSagAwIBAgIRALZcFI008b3qkGPLKBbwWBIwDQYJKoZIhvcN AQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtl IENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDov L3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMTAwODMwMDAwMDAwWhcNMTEwODMwMjM1OTU5WjCB 5DE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05BIE5PVCBWQUxJREFU RUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0cDovL3d3dy5j b21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExpbWl0ZWQx FjAUBgNVBAMTDVJvYmVydCBDcmFnaWUxKjAoBgkqhkiG9w0BCQEWG3JvYmVydC5jcmFnaWVA Z3JpZG1lcmdlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALQCfpvU4Hd5 YvAYACEbYRrbYd2HAm4Sz43wHJwynBBkq5GamqO/SYNrg1utiDsDQqvWnt1cHgZb4N1FFbvL qV84A0f4xc+EtWTZNYn+lfUBIsgR3RNajFEHnsrXnZN6sPdwlObJ1ol4FUWnFPB/A7/liT7G +FmAB+DAc2iTCNjfxOVxhmKShY/b8ZxIkO4fN418cNxHtq1wgm4SRHIv7VJfgseNKQd5u55R HQEmPgN7aiSyIhvAK4H9Pm1msZrklIoSqGpIR0K7gMpVmPRFbWyoPEgAmGYXRwsdvmUkq8W2 wCkr9HA5NNL0D74B+RhIus0gfUL6lgnQR/6y9F31eY0CAwEAAaOCAh0wggIZMB8GA1UdIwQY MBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBRpGoTqjgTJPeVwG/HaXEXWnn/A GDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYL KwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQEC AQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNV HR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL1VUTi1VU0VSRmlyc3Qt Q2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBIoEaGRGh0dHA6Ly9jcmwuY29t b2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3Js MGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5jb21vZG9jYS5jb20v VVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5j b20wJgYDVR0RBB8wHYEbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQA3I0iUCoFSHw/yM7Ra4cdmKkfZirA7N12pCneIVKHrpx4LJImjCEGNinH6G+PD rs632O96zXzaGqq+S2cA3lX5TJ2XdKz3EwPawB6uZf6sHUrWt5NMbwbotDQLTq0gXW6guL4I Cyrmb6EdqO5km8UkgWR7lSzm8fxORPg+X41gu33zb6/cv7hV3gmBbDPh3PVTyGfnAGOyUBSR CvzbrYtkByCMXUfdTdrx7jV1iD0TjxTJe8vJbTv3zjcIcTHGNnR+CZAx+qXTczLc8pL7DtDX okR5zZUuCgPGg/UWgUfBTUB6vibrAtrX9danRwaR61QCu3R6HSg520a9rfVXa1NqMYIEYDCC BFwCAQEwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBM YWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0 cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBB dXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQC2XBSNNPG96pBjyygW8FgSMAkGBSsOAwIaBQCg ggJwMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDUxMzE0 MjMxMFowIwYJKoZIhvcNAQkEMRYEFEzNBv4famYyeyMUNn3S4u0gqqB1MF8GCSqGSIb3DQEJ DzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG 9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB1QYJKwYBBAGCNxAEMYHHMIHEMIGu MQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4w HAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNl cnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRp b24gYW5kIEVtYWlsAhEAtlwUjTTxveqQY8soFvBYEjCB1wYLKoZIhvcNAQkQAgsxgceggcQw ga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkx HjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51 c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgRW1haWwCEQC2XBSNNPG96pBjyygW8FgSMA0GCSqGSIb3DQEBAQUABIIBADQW 1wAOcT2XQRO3hYQaT8zfRyeGiEpjWIbsCa8vA5zJ8My2tpKxP1peggYwvOb5Z3F1i9giM0Ip TE7Tv0mRCCRM39NulyqEIvCIZoC1+D16+Xm1Z/BGbk4VKVc14qlTEQqjRQD9T8ta8g0P45YN FJ50CACulAArV0+EZXCGHZVbVeADyj3NzdLRnUmHuz3JtCm8id07OYtZRzG4ARfY+Tz3oure 2z/ovP8hyykiD72h9qlIOALSq9Stv7Y+OesOU7D7DuKnvvfJuSwXlOO1QMblfGJgVH/a9czs s/i/w662vVqciky0BXv/ZJfng0p5t+eaBfeRwVIcAjYkSns2JcIAAAAAAAA= --------------ms050206030504000200050308-- From zach@sensinode.com Fri May 13 07:25:28 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B901E0675 for ; Fri, 13 May 2011 07:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-1.450, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, MANGLED_BEST=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cEcLMgSIpwEp for ; Fri, 13 May 2011 07:25:27 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id B46A2E0734 for ; Fri, 13 May 2011 07:25:26 -0700 (PDT) Received: from [192.168.1.43] (a91-156-92-242.elisa-laajakaista.fi [91.156.92.242]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id p4DEPJOx008989 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 13 May 2011 17:25:20 +0300 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-317-572006892; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: Date: Fri, 13 May 2011 17:25:21 +0300 Message-Id: <129AA012-582C-4426-8E1B-9966AED7F7D0@sensinode.com> References: To: Thomas Herbst X-Mailer: Apple Mail (2.1084) Cc: "core@ietf.org" Subject: Re: [core] draft-ietf-core-coap-06 The CoAP/DTLS/CoAP Turkey Sandwich layer violation train wreck X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 14:25:28 -0000 --Apple-Mail-317-572006892 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 This subject line is really amusing :-)=20 No really, what is being suggested here is two things: 1. Separate ports for CoAP (NoSec mode) and DTLS/CoAP (Anything !=3D = NoSec mode) 2. A separate coaps:// scheme to indicate DTLS/CoAP Originally, the single scheme and port approach really did make sense as = our security modes were pretty varied and could be accomplished by = *either IPsec or DTLS*. In Prague we made an important decision to bind = DTLS support strongly into CoAP. After this change, I don't see any = problem going with the separate port and scheme approach if that is what = the WG wants (definitely seeing support for this change). Besides, I = could remove Section 7.3 all together :-) The caveat though as Carsten pointed out, is that coaps:// will require = more configuration than https:// as we have more possible modes. This = would need to be discussed in the security section. I guess coaps:// = would need to assume some defaults unless otherwise configured.=20 Is there any strong objection to going with this separate port and = scheme model?=20 Zach On May 11, 2011, at 9:28 PM, Thomas Herbst wrote: > +1 >=20 > From: Robert Cragie > Reply-To: "robert.cragie@gridmerge.com" > Date: Tue, 10 May 2011 06:55:52 -0700 > To: "core@ietf.org" > Subject: Re: [core] draft-ietf-core-coap-06 The CoAP/DTLS/CoAP Turkey = Sandwich layer violation train wreck >=20 > I have never seen what the issue is with using two ports like HTTPS: >=20 > =95 One port for CoAP over UDP > =95 One port for CoAP over DTLS over UDP >=20 > 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 >=20 > On 06/05/2011 8:49 AM, Eric Rescorla wrote: >> On Thu, May 5, 2011 at 6:24 PM, Carsten Bormann >> wrote: >>=20 >>> On May 6, 2011, at 02:51, Eric Rescorla wrote: >>>=20 >>>=20 >>>> 1. Use STUN as-is. >>>>=20 >>> Yep, we are doing that. >>> (The escaping stuff is insurance for a case that is rather unlikely. = We could take it out.) >>>=20 >>> What is the status about STUN coexisting with DTLS? >>>=20 >> As far as I know, there's no problem, since the leading bytes plus = cookies make >> collisions very unlikely. >>=20 >>=20 >>=20 >>>> 2. Use a leading framing byte to distinguish DTLS and CoAP from = STUN. >>>> If you're really worried >>>> about compactiness, >>>>=20 >>> (Yes, we are.) >>>=20 >>>=20 >>>> then pick only a single value to distinguish DTLS >>>> (e.g., 0xffffffff) >>>>=20 >>> (That would be a bit long.) >>>=20 >> Sorry, brain failure. 0xff >>=20 >>=20 >>=20 >>>> and use all >>>> the remaining values to give you a little more room in the rest of = the packet. >>>>=20 >>> Sure, we could do that. It would mean spending another byte for all = DTLS packets. >>>=20 >> Right. My argument is that that's not that big a deal because it only >> increases space >> by ~5%. >>=20 >>=20 >>=20 >>> More importantly, it also means DTLS packets no longer look like = DTLS packets, which complicates debugging. >>>=20 >> Yes, I agree that that's suboptimal. That's why I prefer separate = ports... >> The material you're quoting above is just some other thoughts for = dealing with >> the same port if people insist. >>=20 >>=20 >>=20 >>> I would like to learn more about your plans to expand the DTLS = ContentType space. >>> This hasn't changed since 1996. Of course, it could, next month. >>> Again, the escaping stuff is insurance for this case. We could take = it out. >>>=20 >> I don't think there are any immediate plans to do so--though note = that >>=20 >> http://tools.ietf.org/html/draft-seggelmann-tls-dtls-heartbeat-01 >>=20 >> does contemplate one addition. And I would assume that we intend to >> assign the content-types towards the bottom of the range first. That = said, >> I don't think TLS-WG has by any means decided to commit to not >> assigning a bunch more types. >>=20 >> Bes,t >> -Ekr >> _______________________________________________ >> core mailing list >>=20 >> core@ietf.orghttps://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-317-572006892 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 ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDUxMzE0MjUy MVowIwYJKoZIhvcNAQkEMRYEFLlyV+x2bfYHNaUh8PFY6RASGrD/MIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAIdH5U4hcFlABHb8UmiHxj0vO6VZap+ENlqh06f4UiiwhLOs6p6x5Fa6 wbE8AXkCimsNa60Yi8XL/lCuZAYRnvL/LBCU9faXe5CXz/Aj1XApNLSV1VoFpU6xiCLYcv08vewT xVh60Z385fF7O/03K0I4X41NSCttNBKnMFE/xpWVbJOaMd94el7NsJtxD+/v2LxSFB5bXuc7LjqI tS06I559xdmfOGmdJSD+X3SJERf2hEafoeWDCdnJdFxwZO+5dddL5KHPW37IXsvaHvQ4DGoqff8z sqjs0lyNFFVKURcSYGPgmGWFOm6a0/3ZfyTruaBn4Jiv57cCCjICc+twM4wAAAAAAAA= --Apple-Mail-317-572006892-- From zach@sensinode.com Fri May 13 07:31:40 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39844E0735 for ; Fri, 13 May 2011 07:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.874 X-Spam-Level: X-Spam-Status: No, score=-2.874 tagged_above=-999 required=5 tests=[AWL=0.725, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XeFyfefNZUxO for ; Fri, 13 May 2011 07:31:39 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id DB93DE06A6 for ; Fri, 13 May 2011 07:31:38 -0700 (PDT) Received: from [192.168.1.43] (a91-156-92-242.elisa-laajakaista.fi [91.156.92.242]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id p4DEVUFl011429 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 13 May 2011 17:31:32 +0300 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-318-572377902; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: <4DCD3ECE.2070906@gridmerge.com> Date: Fri, 13 May 2011 17:31:32 +0300 Message-Id: <8AA37BD6-4C50-498A-8A8B-92AF4B5E29B4@sensinode.com> References: <239072CD-ACC0-454D-8BD6-30AC28D425D9@cisco.com> <720981EA-6411-4A5C-AC8C-675ADA1A2DE5@cisco.com> <8BCD950E-FB93-40EE-848C-466E5152DA7C@cisco.com> <223489D8-F2DC-45D1-A690-13480534C1B2@cisco.com> <-3335568933846752161@unknownmsgid> <005101cc10d5$9697a1e0$c3c6e5a0$@yegin@yegin.org> <4DCC45D3.2020304@gridmerge.com> <00bb01cc110e$8e3cb7e0$aab627a0$@yegin@yegin.org> <4DCCF405.2050500@gridmerge.com> <7B94A27A-A5BE-42C0-9876-9CD44D7666EA@sensinode.com> <4DCD3ECE.2070906@gridmerge.com> To: robert.cragie@gridmerge.com X-Mailer: Apple Mail (2.1084) Cc: core@ietf.org Subject: Re: [core] draft-ietf-core-coap-06 Security X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 14:31:40 -0000 --Apple-Mail-318-572377902 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 13, 2011, at 5:23 PM, Robert Cragie wrote: > Hi Zach, >=20 > I wouldn't say totally orthogonal - this spun off from a discussion as = to whether DTLS was indeed the right choice for security and whether we = could define a CoAP security (for example, like RPL did). However, my = view is that DTLS is the right choice. Yes, I agree with you. As a default security scheme DTLS is the right = choice, I do not want to start talking about object security in the = core-coap document. But in NoSec mode you can use whatever you want to, = e.g. IPsec or object security.=20 Zach >=20 > Robert >=20 > On 13/05/2011 3:10 PM, Zach Shelby wrote: >> This object security discussion is totally orthogonal to the DTLS = security that is default in CoAP (so this really isn't relevant to = core-coap-06). Object security is definitely interesting in this domain, = and for example the JSON signing BOF in Prague was relevant to this. I = would encourage Alper to write a draft about how to do simple object = security for CoAP. Robert is right that the security model in the CoRE = context should be an important part of that, as well as bootstrapping = considerations. >>=20 >> Zach >>=20 >> On May 13, 2011, at 12:04 PM, Robert Cragie wrote: >>=20 >>>=20 >>> On 13/05/2011 2:39 AM, Alper Yegin wrote: >>>>>> I'm not singling out TLS here. I think this is a fundamental >>>>>> distinction between channel security vs object-level security. >>>>> It seems fundamentally easier to encrypt on a channel basis as the = same >>>>> end-point credentials are used to derive keying information which = can >>>>> encrypt and integrity protect simultaneously, >>>> Using object-level security does not change that. >>> Perhaps I misunderstood what you meant by object-level security. The = way you described it seemed to suggest that elements of data transacted = within the channel could be individually encrypted. My questions = surround what security material is used to perform the encryption in = each case. >>>>> e.g. most efficiently >>>>> using an AEAD cipher like AES-CCM or AES-GCM. If you start to make = the >>>>> encryption more granular, what do you then use as the = cryptographic >>>>> basis for secrecy between the transacting objects? Asymmetric or >>>>> symmetric? >>>> Symmetric. >>>>=20 >>>>> Would you use the same granularity as the channel end >>>>> points? >>>>> Or be more granular? >>>> Not sure I understand. Can you elaborate? >>> As above - what security material would you use to encrypt? The same = security material as is used for channel encryption? Or something more = granular, i.e. would each distinct element of encrypted data have its = own security material? What is the distinction? If communicating objects = multiplex their transactions on a single channel, this could be the = case. >>>>> All I'm saying is there is probably more to this than meets the = eye. >>>> Let's find out. >>>>=20 >>>> Alper >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>> _______________________________________________ >>> 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 --Apple-Mail-318-572377902 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 ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDUxMzE0MzEz MlowIwYJKoZIhvcNAQkEMRYEFLoIsYRnIbYwrA6oJY28u8GTHldoMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBACEzntjGOA46BHfDMVH2efiyUuf0sXyv4CdHUK4UlUO/wiNCwViULer9 E+6j4ow5xh6xsU1RRx98qlp0h2RsSSEsB3hCDVkbtBf5OTScOrovo1/j50J4itZDR8YClQ3EEHxH JQzfMJp/NOdf+Vd20Q/FIL/sWt0hOB0yemg7PVuG9uAq/9tLXEXl1hm47WEUpgBPR1GyD74L+Yd9 NRPdkwalJBzrw5e8YVwJOXiWX+i3UHWSPb5aU3/8sUb4QYT8WYh+WujuAhkYVN4vBR/AYcisvvps uYz9G/xUxXKRVJ/KCJ8f1gap8LsWewESx9K4R1fIzKOuhaWLYX3JsGDozKcAAAAAAAA= --Apple-Mail-318-572377902-- From robert.cragie@gridmerge.com Fri May 13 09:15:59 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E1E1E06A6 for ; Fri, 13 May 2011 09:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DzBGgqFj-BXS for ; Fri, 13 May 2011 09:15:58 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by ietfa.amsl.com (Postfix) with ESMTP id D1B6DE0685 for ; Fri, 13 May 2011 09:15:57 -0700 (PDT) Received: from client-86-23-5-208.brhm.adsl.virginmedia.com ([86.23.5.208] helo=[192.168.1.80]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.73) id 1QKv1w-00053S-Dh; Fri, 13 May 2011 17:15:56 +0100 Message-ID: <4DCD594B.8030208@gridmerge.com> Date: Fri, 13 May 2011 17:16:11 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Carsten Bormann References: <292C0DCB-2B12-4F30-9FCD-370D4D20FD4B@cisco.com> <21B4A96E-6BC1-4E4C-B917-B5C5DBB43F46@tzi.org> In-Reply-To: <21B4A96E-6BC1-4E4C-B917-B5C5DBB43F46@tzi.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090606080206080108050008" X-Authenticated-As: robert.cragie@gridmerge.com Cc: core@ietf.org Subject: Re: [core] draft-ietf-core-coap-06 What protocol X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 16:15:59 -0000 This is a cryptographically signed message in MIME format. --------------ms090606080206080108050008 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Carsten, Comments below, bracketed by Robert On 05/05/2011 7:16 AM, Carsten Bormann wrote: > On May 5, 2011, at 04:48, Cullen Jennings wrote: > >> Given a CoAP URI like coap:1.2.3.4/temp, do I try to connect with DTLS= or UDP? > That depends on your security requirements. > > This is one of the places where CoAP is almost but not entirely unlike = HTTP. > > In HTTP, we have exactly two security models: no security, which we map= to http://, and security based on server certificates with a somewhat vo= latile but well-known set of roots and TLS, which we map to https:// > > This model already breaks in practice with client certificates -- these= require lots of local configuration in the client that supplement the in= formation in the URI, which is one of the reasons client certificates are= rarely used. The mapping of https:// is to distinguish HTTP/TLS, i.e. the client = will initiate with a Client Hello. It has nothing to do with the=20 credentials used, which is determined by the TLS handshake (and further=20 if two-factor auth. is needed) > Where https:// is used with a different security model than the usual g= lobal set of roots, this requires more configuration (often on both sides= ). Indeed, but this is orthogonal to the transport protocol > In CoAP, we have more ways to do security, and in particular more secur= ity models (it is indeed rather unlikely that the usual global set of roo= ts model will be useful for a constrained device). > > So how do we hope to encode the desired selection of security parameter= s in the URI? Having two schemes (a la coap/coaps) is not going to cut i= t here. Why not? > Even if I know that I should be using DTLS, which PSK identity do I = choose? This is negotiated as part of the TLS handshake > As of today, this requires local configuration. I trust that, over = time, we will come up with extensions to the URI model that will relieve = us of some of this need -- but some configuration will always be required= for security. I don't think it will be necessary as it can be handled in the TLS=20 handshake > A related issue is the indication of the port number. > > In HTTP, http:// implies 80 and https:// implies 443, unless the port n= umber is explicitly given. > These are completely separate resource spaces, i.e. http://a/foo is com= pletely unrelated to https://a/foo (even though it is often a good idea t= o populate the spaces in parallel). I disagree. They are effectively different front ends to the same=20 underlying resource. They will typically go through different access=20 control to the resource. > In CoAP, a single resource may be accessible using multiple security mo= dels. If you don't want to multiplex all those protocols on one port, yo= u would need to indicate the set of ports, one choice per security protoc= ol, in the URI. This hasn't been done before. The negotiation would be done as part of the TLS handshake. No=20 different to HTTP access in my opinion > Gruesse, Carsten > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --------------ms090606080206080108050008 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIREjCC BIowggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w NTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMC VVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l dHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVN NRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQy lbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXq vgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6 hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu 9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0G A1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/ BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9BZGRU cnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8ubmV0L0Fk ZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyispgCi 54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0 g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHd WTBK322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftz Mizpm4QkLdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsy XEFs/vVdoOr/0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIGPjCCBSagAwIBAgIRALZcFI008b3q kGPLKBbwWBIwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEX MBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29y azEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMTAwODMwMDAwMDAw WhcNMTEwODMwMjM1OTU5WjCB5DE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQ RVJTT05BIE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9m IHVzZTogaHR0cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIw MDMgQ29tb2RvIExpbWl0ZWQxFjAUBgNVBAMTDVJvYmVydCBDcmFnaWUxKjAoBgkqhkiG9w0B CQEWG3JvYmVydC5jcmFnaWVAZ3JpZG1lcmdlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALQCfpvU4Hd5YvAYACEbYRrbYd2HAm4Sz43wHJwynBBkq5GamqO/SYNrg1ut iDsDQqvWnt1cHgZb4N1FFbvLqV84A0f4xc+EtWTZNYn+lfUBIsgR3RNajFEHnsrXnZN6sPdw lObJ1ol4FUWnFPB/A7/liT7G+FmAB+DAc2iTCNjfxOVxhmKShY/b8ZxIkO4fN418cNxHtq1w gm4SRHIv7VJfgseNKQd5u55RHQEmPgN7aiSyIhvAK4H9Pm1msZrklIoSqGpIR0K7gMpVmPRF bWyoPEgAmGYXRwsdvmUkq8W2wCkr9HA5NNL0D74B+RhIus0gfUL6lgnQR/6y9F31eY0CAwEA AaOCAh0wggIZMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBRp GoTqjgTJPeVwG/HaXEXWnn/AGDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNV HSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1Ud IAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNv bW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2Eu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRp Y2F0aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDov L2NydC5jb21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC5jb21vZG9jYS5jb20wJgYDVR0RBB8wHYEbcm9iZXJ0LmNyYWdpZUBncmlkbWVy Z2UuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQA3I0iUCoFSHw/yM7Ra4cdmKkfZirA7N12pCneI VKHrpx4LJImjCEGNinH6G+PDrs632O96zXzaGqq+S2cA3lX5TJ2XdKz3EwPawB6uZf6sHUrW t5NMbwbotDQLTq0gXW6guL4ICyrmb6EdqO5km8UkgWR7lSzm8fxORPg+X41gu33zb6/cv7hV 3gmBbDPh3PVTyGfnAGOyUBSRCvzbrYtkByCMXUfdTdrx7jV1iD0TjxTJe8vJbTv3zjcIcTHG NnR+CZAx+qXTczLc8pL7DtDXokR5zZUuCgPGg/UWgUfBTUB6vibrAtrX9danRwaR61QCu3R6 HSg520a9rfVXa1NqMIIGPjCCBSagAwIBAgIRALZcFI008b3qkGPLKBbwWBIwDQYJKoZIhvcN AQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtl IENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDov L3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMTAwODMwMDAwMDAwWhcNMTEwODMwMjM1OTU5WjCB 5DE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05BIE5PVCBWQUxJREFU RUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0cDovL3d3dy5j b21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExpbWl0ZWQx FjAUBgNVBAMTDVJvYmVydCBDcmFnaWUxKjAoBgkqhkiG9w0BCQEWG3JvYmVydC5jcmFnaWVA Z3JpZG1lcmdlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALQCfpvU4Hd5 YvAYACEbYRrbYd2HAm4Sz43wHJwynBBkq5GamqO/SYNrg1utiDsDQqvWnt1cHgZb4N1FFbvL qV84A0f4xc+EtWTZNYn+lfUBIsgR3RNajFEHnsrXnZN6sPdwlObJ1ol4FUWnFPB/A7/liT7G +FmAB+DAc2iTCNjfxOVxhmKShY/b8ZxIkO4fN418cNxHtq1wgm4SRHIv7VJfgseNKQd5u55R HQEmPgN7aiSyIhvAK4H9Pm1msZrklIoSqGpIR0K7gMpVmPRFbWyoPEgAmGYXRwsdvmUkq8W2 wCkr9HA5NNL0D74B+RhIus0gfUL6lgnQR/6y9F31eY0CAwEAAaOCAh0wggIZMB8GA1UdIwQY MBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBRpGoTqjgTJPeVwG/HaXEXWnn/A GDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYL KwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQEC AQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNV HR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL1VUTi1VU0VSRmlyc3Qt Q2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBIoEaGRGh0dHA6Ly9jcmwuY29t b2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3Js MGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5jb21vZG9jYS5jb20v VVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5j b20wJgYDVR0RBB8wHYEbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQA3I0iUCoFSHw/yM7Ra4cdmKkfZirA7N12pCneIVKHrpx4LJImjCEGNinH6G+PD rs632O96zXzaGqq+S2cA3lX5TJ2XdKz3EwPawB6uZf6sHUrWt5NMbwbotDQLTq0gXW6guL4I Cyrmb6EdqO5km8UkgWR7lSzm8fxORPg+X41gu33zb6/cv7hV3gmBbDPh3PVTyGfnAGOyUBSR CvzbrYtkByCMXUfdTdrx7jV1iD0TjxTJe8vJbTv3zjcIcTHGNnR+CZAx+qXTczLc8pL7DtDX okR5zZUuCgPGg/UWgUfBTUB6vibrAtrX9danRwaR61QCu3R6HSg520a9rfVXa1NqMYIEYDCC BFwCAQEwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBM YWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0 cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBB dXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQC2XBSNNPG96pBjyygW8FgSMAkGBSsOAwIaBQCg ggJwMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDUxMzE2 MTYxMVowIwYJKoZIhvcNAQkEMRYEFKR0roDEHDyr7KTAz6u4UUB0C/OaMF8GCSqGSIb3DQEJ DzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG 9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB1QYJKwYBBAGCNxAEMYHHMIHEMIGu MQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4w HAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNl cnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRp b24gYW5kIEVtYWlsAhEAtlwUjTTxveqQY8soFvBYEjCB1wYLKoZIhvcNAQkQAgsxgceggcQw ga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkx HjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51 c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgRW1haWwCEQC2XBSNNPG96pBjyygW8FgSMA0GCSqGSIb3DQEBAQUABIIBAGCg 5X5TXOENYtnKyHNt1yDDCnjdQTi6UdILgakKf7CnDoDn2seIf2FrIRC5agvdo/Xjoo6qKgd0 OQmPtUwfsGACL+NrYioaYdwCDLCpnAV6I4czusJGgJgeALvEZ3fulB4ak2ljHSmgbJXHIspg dWiYdcItEpffeQT0gX3ZuGvjQiLj14F3b5BXx1Dl5FmCdOC41U/Ejrhiw1SWxjTvuMxuJp8a 5tv7JO2RDY0rqyusvxvwuF3JZfcA3zvJOO75LaoxxEUVpMGXStW026pFvkpBbBSzFpUWEr4F kEMRkE7meX0DYemrNTJ7smkH7dbN3AEGl6Ms6w44RICC+psnqkkAAAAAAAA= --------------ms090606080206080108050008-- From robert.cragie@gridmerge.com Fri May 13 09:17:28 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD30E067A for ; Fri, 13 May 2011 09:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4BSurH5hIgCP for ; Fri, 13 May 2011 09:17:27 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by ietfa.amsl.com (Postfix) with ESMTP id 288DCE0670 for ; Fri, 13 May 2011 09:17:27 -0700 (PDT) Received: from client-86-23-5-208.brhm.adsl.virginmedia.com ([86.23.5.208] helo=[192.168.1.80]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.73) id 1QKv3M-0006Np-NE; Fri, 13 May 2011 17:17:25 +0100 Message-ID: <4DCD59A3.7060603@gridmerge.com> Date: Fri, 13 May 2011 17:17:39 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Zach Shelby References: <129AA012-582C-4426-8E1B-9966AED7F7D0@sensinode.com> In-Reply-To: <129AA012-582C-4426-8E1B-9966AED7F7D0@sensinode.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090306060600090406060402" X-Authenticated-As: robert.cragie@gridmerge.com Cc: "core@ietf.org" Subject: Re: [core] draft-ietf-core-coap-06 The CoAP/DTLS/CoAP Turkey Sandwich layer violation train wreck X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 16:17:28 -0000 This is a cryptographically signed message in MIME format. --------------ms090306060600090406060402 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Hi Zach, Comments inline... Robert On 13/05/2011 3:25 PM, Zach Shelby wrote: > This subject line is really amusing :-) > > No really, what is being suggested here is two things: > > 1. Separate ports for CoAP (NoSec mode) and DTLS/CoAP (Anything !=3D No= Sec mode) > 2. A separate coaps:// scheme to indicate DTLS/CoAP > > Originally, the single scheme and port approach really did make sense a= s our security modes were pretty varied and could be accomplished by *eit= her IPsec or DTLS*. In Prague we made an important decision to bind DTLS = support strongly into CoAP. After this change, I don't see any problem go= ing with the separate port and scheme approach if that is what the WG wan= ts (definitely seeing support for this change). Besides, I could remove S= ection 7.3 all together :-) There is a difference. If you are using IPsec, it would be=20 CoAP-over-UDP-over-IPsec. So it makes sense to use the same port as=20 CoAP-over-UDP-over-IP. However, using DTLS it would be=20 CoAP-over-DTLS-over-UDP. As TLS records encapsulate the CoAP, the=20 ability to distinguish on the first byte gets lost, hence the suggestion = to use a separate port. > The caveat though as Carsten pointed out, is that coaps:// will require= more configuration than https:// as we have more possible modes. This wo= uld need to be discussed in the security section. I guess coaps:// would = need to assume some defaults unless otherwise configured. I don't agree. I have responded separately to Carten's e-mail --------------ms090306060600090406060402 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIREjCC BIowggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w NTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMC VVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l dHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVN NRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQy lbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXq vgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6 hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu 9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0G A1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/ BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9BZGRU cnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8ubmV0L0Fk ZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyispgCi 54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0 g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHd WTBK322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftz Mizpm4QkLdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsy XEFs/vVdoOr/0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIGPjCCBSagAwIBAgIRALZcFI008b3q kGPLKBbwWBIwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEX MBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29y azEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMTAwODMwMDAwMDAw WhcNMTEwODMwMjM1OTU5WjCB5DE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQ RVJTT05BIE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9m IHVzZTogaHR0cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIw MDMgQ29tb2RvIExpbWl0ZWQxFjAUBgNVBAMTDVJvYmVydCBDcmFnaWUxKjAoBgkqhkiG9w0B CQEWG3JvYmVydC5jcmFnaWVAZ3JpZG1lcmdlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALQCfpvU4Hd5YvAYACEbYRrbYd2HAm4Sz43wHJwynBBkq5GamqO/SYNrg1ut iDsDQqvWnt1cHgZb4N1FFbvLqV84A0f4xc+EtWTZNYn+lfUBIsgR3RNajFEHnsrXnZN6sPdw lObJ1ol4FUWnFPB/A7/liT7G+FmAB+DAc2iTCNjfxOVxhmKShY/b8ZxIkO4fN418cNxHtq1w gm4SRHIv7VJfgseNKQd5u55RHQEmPgN7aiSyIhvAK4H9Pm1msZrklIoSqGpIR0K7gMpVmPRF bWyoPEgAmGYXRwsdvmUkq8W2wCkr9HA5NNL0D74B+RhIus0gfUL6lgnQR/6y9F31eY0CAwEA AaOCAh0wggIZMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBRp GoTqjgTJPeVwG/HaXEXWnn/AGDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNV HSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1Ud IAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNv bW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2Eu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRp Y2F0aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDov L2NydC5jb21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC5jb21vZG9jYS5jb20wJgYDVR0RBB8wHYEbcm9iZXJ0LmNyYWdpZUBncmlkbWVy Z2UuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQA3I0iUCoFSHw/yM7Ra4cdmKkfZirA7N12pCneI VKHrpx4LJImjCEGNinH6G+PDrs632O96zXzaGqq+S2cA3lX5TJ2XdKz3EwPawB6uZf6sHUrW t5NMbwbotDQLTq0gXW6guL4ICyrmb6EdqO5km8UkgWR7lSzm8fxORPg+X41gu33zb6/cv7hV 3gmBbDPh3PVTyGfnAGOyUBSRCvzbrYtkByCMXUfdTdrx7jV1iD0TjxTJe8vJbTv3zjcIcTHG NnR+CZAx+qXTczLc8pL7DtDXokR5zZUuCgPGg/UWgUfBTUB6vibrAtrX9danRwaR61QCu3R6 HSg520a9rfVXa1NqMIIGPjCCBSagAwIBAgIRALZcFI008b3qkGPLKBbwWBIwDQYJKoZIhvcN AQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtl IENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDov L3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMTAwODMwMDAwMDAwWhcNMTEwODMwMjM1OTU5WjCB 5DE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05BIE5PVCBWQUxJREFU RUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0cDovL3d3dy5j b21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExpbWl0ZWQx FjAUBgNVBAMTDVJvYmVydCBDcmFnaWUxKjAoBgkqhkiG9w0BCQEWG3JvYmVydC5jcmFnaWVA Z3JpZG1lcmdlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALQCfpvU4Hd5 YvAYACEbYRrbYd2HAm4Sz43wHJwynBBkq5GamqO/SYNrg1utiDsDQqvWnt1cHgZb4N1FFbvL qV84A0f4xc+EtWTZNYn+lfUBIsgR3RNajFEHnsrXnZN6sPdwlObJ1ol4FUWnFPB/A7/liT7G +FmAB+DAc2iTCNjfxOVxhmKShY/b8ZxIkO4fN418cNxHtq1wgm4SRHIv7VJfgseNKQd5u55R HQEmPgN7aiSyIhvAK4H9Pm1msZrklIoSqGpIR0K7gMpVmPRFbWyoPEgAmGYXRwsdvmUkq8W2 wCkr9HA5NNL0D74B+RhIus0gfUL6lgnQR/6y9F31eY0CAwEAAaOCAh0wggIZMB8GA1UdIwQY MBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBRpGoTqjgTJPeVwG/HaXEXWnn/A GDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYL KwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQEC AQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNV HR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL1VUTi1VU0VSRmlyc3Qt Q2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBIoEaGRGh0dHA6Ly9jcmwuY29t b2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3Js MGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5jb21vZG9jYS5jb20v VVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5j b20wJgYDVR0RBB8wHYEbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQA3I0iUCoFSHw/yM7Ra4cdmKkfZirA7N12pCneIVKHrpx4LJImjCEGNinH6G+PD rs632O96zXzaGqq+S2cA3lX5TJ2XdKz3EwPawB6uZf6sHUrWt5NMbwbotDQLTq0gXW6guL4I Cyrmb6EdqO5km8UkgWR7lSzm8fxORPg+X41gu33zb6/cv7hV3gmBbDPh3PVTyGfnAGOyUBSR CvzbrYtkByCMXUfdTdrx7jV1iD0TjxTJe8vJbTv3zjcIcTHGNnR+CZAx+qXTczLc8pL7DtDX okR5zZUuCgPGg/UWgUfBTUB6vibrAtrX9danRwaR61QCu3R6HSg520a9rfVXa1NqMYIEYDCC BFwCAQEwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBM YWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0 cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBB dXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQC2XBSNNPG96pBjyygW8FgSMAkGBSsOAwIaBQCg ggJwMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDUxMzE2 MTczOVowIwYJKoZIhvcNAQkEMRYEFL7rJqRxm/QfPces0ChWPIwOQRO5MF8GCSqGSIb3DQEJ DzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG 9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB1QYJKwYBBAGCNxAEMYHHMIHEMIGu MQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4w HAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNl cnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRp b24gYW5kIEVtYWlsAhEAtlwUjTTxveqQY8soFvBYEjCB1wYLKoZIhvcNAQkQAgsxgceggcQw ga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkx HjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51 c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgRW1haWwCEQC2XBSNNPG96pBjyygW8FgSMA0GCSqGSIb3DQEBAQUABIIBAAMo UK19Qtix8vuYKY9MAUwkdDtxDRv0GVrs7nBXqw31mqcca1JuVCPhbb7zDBO7mZUglhQv92Ob sqvmjaIrWsNQm3KqOvI3U0HdC8X5N3zoeDTiZeVjau1rpg+N6hGJWN0Pppa1SWhbUYaAngRp jUKOU7mkJryEkcSLikskc2EEtwBzjiaisQsTWFQXCBk1OjXxUxVrr5kWCsVmJhsrBt7TJaed +mn5Yd/pNfZFMmywXaVuV+Why4OJe4xUgGzOAXPyBnErI4FrvR8iwj7nmTyTxLv4j38qBSGb /AGKHhdLfsmHvE1hLil5H1ICsyZVEkrKsLMqIEstqzK+HFnnpJsAAAAAAAA= --------------ms090306060600090406060402-- From rgm@labs.htt-consult.com Fri May 13 10:30:05 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96332E0720 for ; Fri, 13 May 2011 10:30:05 -0700 (PDT) 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_62=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wsZ36T9B6QoB for ; Fri, 13 May 2011 10:30:05 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by ietfa.amsl.com (Postfix) with ESMTP id 9ACCBE071C for ; Fri, 13 May 2011 10:30:04 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 3CE7262A89; Fri, 13 May 2011 17:29:51 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RHP-dv63oE9m; Fri, 13 May 2011 13:29:34 -0400 (EDT) Received: from nc2400.htt-consult.com (nc2400.htt-consult.com [208.83.67.155]) (Authenticated sender: rgm@labs.htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPA id 842CC633A8; Fri, 13 May 2011 13:29:34 -0400 (EDT) Message-ID: <4DCD6A7E.2070901@labs.htt-consult.com> Date: Fri, 13 May 2011 13:29:34 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc14 Thunderbird/3.1.10 MIME-Version: 1.0 To: Cullen Jennings References: <239072CD-ACC0-454D-8BD6-30AC28D425D9@cisco.com> In-Reply-To: <239072CD-ACC0-454D-8BD6-30AC28D425D9@cisco.com> Content-Type: multipart/alternative; boundary="------------010509090709040607070109" Cc: core WG Subject: Re: [core] draft-ietf-core-coap-06 Security X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 17:30:05 -0000 This is a multi-part message in MIME format. --------------010509090709040607070109 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 05/04/2011 10:51 PM, Cullen Jennings wrote: > > I think it will be very hard to leave keying for the security out of scope of this specification. I realize there are other drafts in progress on this and I look forward to their rapid arrival. Even when using DTLS Certificate mode, any connection can have a man in the middle attack as their is not binding of who we are trying to connect to material in the certificate. This seems like a big problem. Related to this, for many protocols the assumption that someone with a keyboard and screen will manually type something into the device as out of band security configuration is reasonable. Give the use cases this WG was formed to solve, it is not an reasonable assumption for this WG. There is also the blacklist/whitelist approach. The first time the device fails to authenticate, and is blacklisted. The admin reviews the 128bit code for the device against the serial # stamped on the device or printed with the documentation, sees the match and moves the # to the whitelist. The next authentication attempt succeeds. Years back, I helped a company develop a product that worked like this and had a reasonable market success (before they were bought up for other value). > > Cullen > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > -- Robert Moskowitz Senior Technical Director ICSA Labs, an Independent Division of Verizon Business Systems W:248-968-9809 F:248-968-2824 VoIP:248-291-0713 E:robert.moskowitz@icsalabs.com There's no limit to what can be accomplished if it doesn't matter who gets the credit --------------010509090709040607070109 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 05/04/2011 10:51 PM, Cullen Jennings wrote: 

I think it will be very hard to leave keying for the security out of scope of this specification. I realize there are other drafts in progress on this and I look forward to their rapid arrival. Even when using DTLS Certificate mode, any connection can have a man in the middle attack as their is not binding of who we are trying to connect to material in the certificate. This seems like a big problem. Related to this, for many protocols the assumption that someone with a keyboard and screen will manually type something into the device as out of band security configuration is reasonable. Give the use cases this WG was formed to solve, it is not an reasonable assumption for this WG.

There is also the blacklist/whitelist approach.

The first time the device fails to authenticate, and is blacklisted.  The admin reviews the 128bit code for the device against the serial # stamped on the device or printed with the documentation, sees the match and moves the # to the whitelist.  The next authentication attempt succeeds.

Years back, I helped a company develop a product that worked like this and had a reasonable market success (before they were bought up for other value).


Cullen <in my role as an individual contributor>

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

--
Standard Robert Moskowitz
Senior Technical Director
ICSA Labs, an Independent Division of Verizon Business Systems
W:      248-968-9809
F:      248-968-2824
VoIP:   248-291-0713
E:      robert.moskowitz@icsalabs.com

There's no limit to what can be accomplished if it doesn't matter who gets the credit
--------------010509090709040607070109-- From zach@sensinode.com Sun May 15 12:18:14 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 978E4E0670 for ; Sun, 15 May 2011 12:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1PMFnIH0ial8 for ; Sun, 15 May 2011 12:18:13 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 2CD87E0674 for ; Sun, 15 May 2011 12:18:12 -0700 (PDT) Received: from [192.168.1.101] (87-95-187-195.bb.dnainternet.fi [87.95.187.195]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id p4FJI3c6021214 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 15 May 2011 22:18:04 +0300 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-337-762372038; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: <4DCD59A3.7060603@gridmerge.com> Date: Sun, 15 May 2011 22:18:06 +0300 Message-Id: References: <129AA012-582C-4426-8E1B-9966AED7F7D0@sensinode.com> <4DCD59A3.7060603@gridmerge.com> To: robert.cragie@gridmerge.com X-Mailer: Apple Mail (2.1084) Cc: "core@ietf.org" Subject: Re: [core] draft-ietf-core-coap-06 The CoAP/DTLS/CoAP Turkey Sandwich layer violation train wreck X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 15 May 2011 19:18:14 -0000 --Apple-Mail-337-762372038 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 13, 2011, at 7:17 PM, Robert Cragie wrote: > Hi Zach, >=20 > Comments inline... >=20 > Robert >=20 > On 13/05/2011 3:25 PM, Zach Shelby wrote: >> This subject line is really amusing :-) >>=20 >> No really, what is being suggested here is two things: >>=20 >> 1. Separate ports for CoAP (NoSec mode) and DTLS/CoAP (Anything !=3D = NoSec mode) >> 2. A separate coaps:// scheme to indicate DTLS/CoAP >>=20 >> Originally, the single scheme and port approach really did make sense = as our security modes were pretty varied and could be accomplished by = *either IPsec or DTLS*. In Prague we made an important decision to bind = DTLS support strongly into CoAP. After this change, I don't see any = problem going with the separate port and scheme approach if that is what = the WG wants (definitely seeing support for this change). Besides, I = could remove Section 7.3 all together :-) > There is a difference. If you are using IPsec, it would be = CoAP-over-UDP-over-IPsec. So it makes sense to use the same port as = CoAP-over-UDP-over-IP. However, using DTLS it would be = CoAP-over-DTLS-over-UDP. As TLS records encapsulate the CoAP, the = ability to distinguish on the first byte gets lost, hence the suggestion = to use a separate port. Yes, this is what I was trying to say. Now that -06 is clearer about the = binding to DTLS, the separate ports and scheme works. >> The caveat though as Carsten pointed out, is that coaps:// will = require more configuration than https:// as we have more possible modes. = This would need to be discussed in the security section. I guess = coaps:// would need to assume some defaults unless otherwise configured. > I don't agree. I have responded separately to Carten's = e-mail Will follow that. For me this is really just an editorial issue in the = security section regarding how much needs to be said about the = configuration needed to make use of a coaps:// scheme. In other words, = how to make SharedKey, MultiKey and Certificate mode work out of the = box. You seem to be saying that TLS will just negotiate 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-337-762372038 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 ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDUxNTE5MTgw NlowIwYJKoZIhvcNAQkEMRYEFLxaxmIabgJ6cPxwbQPYFIZ8rXuLMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAFiU+RsC5m765A9Q7brl+3dycaNrL4fF4gp83CmzhBNPLpc8oSFbM5av WGg/JFhO2t+QFHYuRpm4NaiXIhjtchPNEsvPbDwe4bx4kAPnEYQu91eILYwgFkRu/e4Op4a4yGoS 33VRD9T+SScxkzqvMr/4j2SARvhVTgfBLkP5lvG1Bh+H0v+4qMf4mViqluPMRcvVytkKjMt1XsUg d8apaEDp6PRMD8RMLselHT/wmtk4LK/nP5o4JgMUzI/PRBivqPTZwXw4a+cp270SRzd2zfiVWs+v faYgGac9O9110LLIV5zy6ix6uqqwVuyIyRvY9aQmSqXty49u5rqLVyLsQ2QAAAAAAAA= --Apple-Mail-337-762372038-- From robert.cragie@gridmerge.com Mon May 16 00:40:31 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4A44E0679 for ; Mon, 16 May 2011 00:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oRrzb6geYGer for ; Mon, 16 May 2011 00:40:31 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by ietfa.amsl.com (Postfix) with ESMTP id E4F86E0671 for ; Mon, 16 May 2011 00:40:30 -0700 (PDT) Received: from client-86-23-5-208.brhm.adsl.virginmedia.com ([86.23.5.208] helo=[192.168.1.80]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.73) id 1QLsPe-0007VH-Ko; Mon, 16 May 2011 08:40:23 +0100 Message-ID: <4DD0D4DD.9070103@gridmerge.com> Date: Mon, 16 May 2011 08:40:13 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Zach Shelby References: <129AA012-582C-4426-8E1B-9966AED7F7D0@sensinode.com> <4DCD59A3.7060603@gridmerge.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090903020203020701090908" X-Authenticated-As: robert.cragie@gridmerge.com Cc: "core@ietf.org" Subject: Re: [core] draft-ietf-core-coap-06 The CoAP/DTLS/CoAP Turkey Sandwich layer violation train wreck X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2011 07:40:31 -0000 This is a cryptographically signed message in MIME format. --------------ms090903020203020701090908 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 15/05/2011 8:18 PM, Zach Shelby wrote: > > Will follow that. For me this is really just an editorial issue in the = security section regarding how much needs to be said about the configurat= ion needed to make use of a coaps:// scheme. In other words, how to make = SharedKey, MultiKey and Certificate mode work out of the box. You seem to= be saying that TLS will just negotiate this. If you base those modes on TLS cipher suites, then they can be=20 negotiated as part of the TLS handshake. Let me take a closer look=20 too. Robert --------------ms090903020203020701090908 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIREjCC BIowggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w NTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMC VVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l dHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVN NRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQy lbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXq vgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6 hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu 9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0G A1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/ BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9BZGRU cnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8ubmV0L0Fk ZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyispgCi 54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0 g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHd WTBK322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftz Mizpm4QkLdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsy XEFs/vVdoOr/0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIGPjCCBSagAwIBAgIRALZcFI008b3q kGPLKBbwWBIwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEX MBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29y azEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMTAwODMwMDAwMDAw WhcNMTEwODMwMjM1OTU5WjCB5DE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQ RVJTT05BIE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9m IHVzZTogaHR0cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIw MDMgQ29tb2RvIExpbWl0ZWQxFjAUBgNVBAMTDVJvYmVydCBDcmFnaWUxKjAoBgkqhkiG9w0B CQEWG3JvYmVydC5jcmFnaWVAZ3JpZG1lcmdlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALQCfpvU4Hd5YvAYACEbYRrbYd2HAm4Sz43wHJwynBBkq5GamqO/SYNrg1ut iDsDQqvWnt1cHgZb4N1FFbvLqV84A0f4xc+EtWTZNYn+lfUBIsgR3RNajFEHnsrXnZN6sPdw lObJ1ol4FUWnFPB/A7/liT7G+FmAB+DAc2iTCNjfxOVxhmKShY/b8ZxIkO4fN418cNxHtq1w gm4SRHIv7VJfgseNKQd5u55RHQEmPgN7aiSyIhvAK4H9Pm1msZrklIoSqGpIR0K7gMpVmPRF bWyoPEgAmGYXRwsdvmUkq8W2wCkr9HA5NNL0D74B+RhIus0gfUL6lgnQR/6y9F31eY0CAwEA AaOCAh0wggIZMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBRp GoTqjgTJPeVwG/HaXEXWnn/AGDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNV HSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1Ud IAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNv bW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2Eu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRp Y2F0aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDov L2NydC5jb21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC5jb21vZG9jYS5jb20wJgYDVR0RBB8wHYEbcm9iZXJ0LmNyYWdpZUBncmlkbWVy Z2UuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQA3I0iUCoFSHw/yM7Ra4cdmKkfZirA7N12pCneI VKHrpx4LJImjCEGNinH6G+PDrs632O96zXzaGqq+S2cA3lX5TJ2XdKz3EwPawB6uZf6sHUrW t5NMbwbotDQLTq0gXW6guL4ICyrmb6EdqO5km8UkgWR7lSzm8fxORPg+X41gu33zb6/cv7hV 3gmBbDPh3PVTyGfnAGOyUBSRCvzbrYtkByCMXUfdTdrx7jV1iD0TjxTJe8vJbTv3zjcIcTHG NnR+CZAx+qXTczLc8pL7DtDXokR5zZUuCgPGg/UWgUfBTUB6vibrAtrX9danRwaR61QCu3R6 HSg520a9rfVXa1NqMIIGPjCCBSagAwIBAgIRALZcFI008b3qkGPLKBbwWBIwDQYJKoZIhvcN AQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtl IENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDov L3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMTAwODMwMDAwMDAwWhcNMTEwODMwMjM1OTU5WjCB 5DE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05BIE5PVCBWQUxJREFU RUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0cDovL3d3dy5j b21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExpbWl0ZWQx FjAUBgNVBAMTDVJvYmVydCBDcmFnaWUxKjAoBgkqhkiG9w0BCQEWG3JvYmVydC5jcmFnaWVA Z3JpZG1lcmdlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALQCfpvU4Hd5 YvAYACEbYRrbYd2HAm4Sz43wHJwynBBkq5GamqO/SYNrg1utiDsDQqvWnt1cHgZb4N1FFbvL qV84A0f4xc+EtWTZNYn+lfUBIsgR3RNajFEHnsrXnZN6sPdwlObJ1ol4FUWnFPB/A7/liT7G +FmAB+DAc2iTCNjfxOVxhmKShY/b8ZxIkO4fN418cNxHtq1wgm4SRHIv7VJfgseNKQd5u55R HQEmPgN7aiSyIhvAK4H9Pm1msZrklIoSqGpIR0K7gMpVmPRFbWyoPEgAmGYXRwsdvmUkq8W2 wCkr9HA5NNL0D74B+RhIus0gfUL6lgnQR/6y9F31eY0CAwEAAaOCAh0wggIZMB8GA1UdIwQY MBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBRpGoTqjgTJPeVwG/HaXEXWnn/A GDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYL KwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQEC AQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNV HR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL1VUTi1VU0VSRmlyc3Qt Q2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBIoEaGRGh0dHA6Ly9jcmwuY29t b2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3Js MGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5jb21vZG9jYS5jb20v VVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5j b20wJgYDVR0RBB8wHYEbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQA3I0iUCoFSHw/yM7Ra4cdmKkfZirA7N12pCneIVKHrpx4LJImjCEGNinH6G+PD rs632O96zXzaGqq+S2cA3lX5TJ2XdKz3EwPawB6uZf6sHUrWt5NMbwbotDQLTq0gXW6guL4I Cyrmb6EdqO5km8UkgWR7lSzm8fxORPg+X41gu33zb6/cv7hV3gmBbDPh3PVTyGfnAGOyUBSR CvzbrYtkByCMXUfdTdrx7jV1iD0TjxTJe8vJbTv3zjcIcTHGNnR+CZAx+qXTczLc8pL7DtDX okR5zZUuCgPGg/UWgUfBTUB6vibrAtrX9danRwaR61QCu3R6HSg520a9rfVXa1NqMYIEYDCC BFwCAQEwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBM YWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0 cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBB dXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQC2XBSNNPG96pBjyygW8FgSMAkGBSsOAwIaBQCg ggJwMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDUxNjA3 NDAxM1owIwYJKoZIhvcNAQkEMRYEFN9Q2PYcbHiaeQtYXvKAoP25G/DzMF8GCSqGSIb3DQEJ DzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG 9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB1QYJKwYBBAGCNxAEMYHHMIHEMIGu MQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4w HAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNl cnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRp b24gYW5kIEVtYWlsAhEAtlwUjTTxveqQY8soFvBYEjCB1wYLKoZIhvcNAQkQAgsxgceggcQw ga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkx HjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51 c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgRW1haWwCEQC2XBSNNPG96pBjyygW8FgSMA0GCSqGSIb3DQEBAQUABIIBAF97 RpFRLR3an4d1/ll3Y2VoS/auMkXw+SCSNoVvGZxHQGB+Pn0suP9YOU7dm/S+EEWzjJmGwdcJ STYrAUvPhFpoH6Hj+fUf31utCZNNp2JxilKS284h0A5TQFeo/Mxll9Wh2Bd9dIz1lsCmdzg4 5kaA8qkPaoZLsH4lc6iF70hkiG8qhEdU1+9lMdIqdyZ9v/UlLlqiz2zKlrliVYgFNklqyH6w qYstfL83xz1hxXMRq8BgDqqLBQBNKNDujQpzeRZUMn2jAyH9ffc6J+u2YxKEdZILGx0kVaev UpG8hbzdDA76wM4XPVBvh28hr8JowbRiRcjYaebWv4Q+0dMr02wAAAAAAAA= --------------ms090903020203020701090908-- From trac+core@trac.tools.ietf.org Mon May 16 07:39:02 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2A9DE0748 for ; Mon, 16 May 2011 07:39: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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P3AtHXQms7Nk for ; Mon, 16 May 2011 07:39:01 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 9BCEAE0699 for ; Mon, 16 May 2011 07:39:00 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QLywh-00073G-3m; Mon, 16 May 2011 07:38:55 -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, cabo@tzi.org X-Trac-Project: core Date: Mon, 16 May 2011 14:38:54 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/152 Message-ID: <051.fc4a5a3ccdd31bb197760894c44783b7@trac.tools.ietf.org> X-Trac-Ticket-ID: 152 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] #152: Update link-format for coap-06 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2011 14:39:02 -0000 #152: Update link-format for coap-06 link-format-04: The examples in section 5 show a response code of "200 OK", which should now be "2.05 Content" (unless the examples are HTTP...). (Also, the reference to core-coap needs to be updated to -06, or, better, current in the XML. And the Fielding reference comes out strange.) Thanks, Davide! -- --------------------------------+------------------------------------------- Reporter: cabo@… | Owner: zach@… Type: editorial | Status: new Priority: trivial | Milestone: Component: block | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From Akbar.Rahman@InterDigital.com Mon May 16 08:06:04 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DF9CE0765 for ; Mon, 16 May 2011 08:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QD163z6u1wH0 for ; Mon, 16 May 2011 08:06:03 -0700 (PDT) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by ietfa.amsl.com (Postfix) with ESMTP id DDE7AE0748 for ; Mon, 16 May 2011 08:06:02 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 16 May 2011 11:06:01 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 16 May 2011 11:06:00 -0400 Message-ID: In-Reply-To: <20110516144843.9680.59179.idtracker@ietfa.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: I-D Action: draft-rahman-core-groupcomm-05.txt Thread-Index: AcwT2HVeMYHzdDNDQcS65fN55YCh/AAAU1qw References: <20110516144843.9680.59179.idtracker@ietfa.amsl.com> From: "Rahman, Akbar" To: X-OriginalArrivalTime: 16 May 2011 15:06:01.0581 (UTC) FILETIME=[C4FFF9D0:01CC13DA] Subject: [core] FW: I-D Action: draft-rahman-core-groupcomm-05.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2011 15:06:04 -0000 Hi, Esko and I have made a fairly significant update of the Group Communication I-D. Specifically, we have now made a recommendation for which mechanism to use for CoAP. We still have some updates to complete, but would really appreciate any feedback at this point. http://www.ietf.org/internet-drafts/draft-rahman-core-groupcomm-05.txt Sincerely, Esko and Akbar -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Monday, May 16, 2011 10:49 AM To: i-d-announce@ietf.org Subject: I-D Action: draft-rahman-core-groupcomm-05.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Group Communication for CoAP Author(s) : Akbar Rahman Esko Dijk Filename : draft-rahman-core-groupcomm-05.txt Pages : 27 Date : 2011-05-16 This is a working document intended to trigger discussion and develop draft text for the CoAP protocol specification in the area of group communication (including multicast functionality). Engineering tradeoffs become more challenging in constrained environments, therefore group communication is considered within the context of adjacent topics that may impact or be impacted by design choices in the subject area. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rahman-core-groupcomm-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-rahman-core-groupcomm-05.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From kovatsch@inf.ethz.ch Tue May 17 17:35:12 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B36CDE06E3 for ; Tue, 17 May 2011 17:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T+DZbLHx+POv for ; Tue, 17 May 2011 17:35:12 -0700 (PDT) Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) by ietfa.amsl.com (Postfix) with ESMTP id BFABCE068E for ; Tue, 17 May 2011 17:35:10 -0700 (PDT) Received: from CAS10.d.ethz.ch (172.31.38.210) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.1.289.1; Wed, 18 May 2011 02:35:04 +0200 Received: from MBX20.d.ethz.ch ([fe80::81a7:b7a5:50c0:df0d]) by CAS10.d.ethz.ch ([fe80::cce:fc66:7b56:a06a%11]) with mapi id 14.01.0289.001; Wed, 18 May 2011 02:35:08 +0200 From: "Kovatsch Matthias" To: "zach@sensinode.com" , "cabo@tzi.org" Thread-Topic: Copper-0.6.0 with CoAP-06 support released Thread-Index: AcwU60ScuJ8mRgOZTIK6YeDExn832g== Date: Wed, 18 May 2011 00:35:08 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B508425F9A@MBX20.d.ethz.ch> Accept-Language: en-US, de-CH Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.132.211.38] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "core@ietf.org" Subject: [core] Copper-0.6.0 with CoAP-06 support released X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 18 May 2011 00:35:12 -0000 SGkNCg0KSSBqdXN0IHJlbGVhc2VkIGEgbmV3IENvcHBlciB2ZXJzaW9uIHdpdGggZmlyc3QgQ29B UC0wNiBzdXBwb3J0Og0KaHR0cHM6Ly9hZGRvbnMubW96aWxsYS5vcmcvZW4tVVMvZmlyZWZveC9h ZGRvbi9jb3BwZXItMjcwNDMwL3ZlcnNpb25zLz9wYWdlPTEjdmVyc2lvbi0wLjYuMA0KIA0KQmVz dCByZWdhcmRzDQpNYXR0aGlhcw0K From tianlinyi@huawei.com Tue May 17 18:24:09 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8815DE0686 for ; Tue, 17 May 2011 18:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cAJ6V0kq0rHw for ; Tue, 17 May 2011 18:24:09 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id BCA28E0659 for ; Tue, 17 May 2011 18:24:08 -0700 (PDT) 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 <0LLD00HAEAK4F1@szxga05-in.huawei.com> for core@ietf.org; Wed, 18 May 2011 09:24:04 +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 <0LLD00IPLAK4X4@szxga05-in.huawei.com> for core@ietf.org; Wed, 18 May 2011 09:24:04 +0800 (CST) Received: from T34932F ([10.70.109.57]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LLD00LV5AK3R4@szxml04-in.huawei.com> for core@ietf.org; Wed, 18 May 2011 09:24:03 +0800 (CST) Date: Wed, 18 May 2011 09:24:03 +0800 From: Linyi Tian In-reply-to: <4DCD1F34.5030904@gridmerge.com> To: robert.cragie@gridmerge.com, 'Likepeng' Message-id: <006b01cc14fa$4634d9b0$d29e8d10$@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: AcwRZm/7Gm+lm3POSAewyL3RHovd2wDk6HWw References: <4DCCFA65.2040702@gridmerge.com> <34966E97BE8AD64EAE9D3D6E4DEE36F2294258@szxeml506-mbx.china.huawei.com> <4DCD1F34.5030904@gridmerge.com> Cc: 'core' Subject: Re: [core] Block names X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 18 May 2011 01:24:09 -0000 Hi, All If we agree with Charles Palmer's suggestion ( the size in the first response returns the actual size of the data) then we don't need the SizeFromRsp at all. The requester would know whether it can handle the data. Cheers, Linyi >>-----Original Message----- >>From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of >>Robert Cragie >>Sent: Friday, May 13, 2011 8:08 PM >>To: Likepeng >>Cc: core >>Subject: Re: [core] Block names >> >>I put the 'From' in as both options can be used in either request or >>response, so BlockReq might seem as that's what only you use in a request. >> >>I think the same could apply to your Size option for consistency: >> >>SizeFromRsp in Request -> (expecting) A (maximum) size in response >>SizeFromRsp in Response -> A size in response >>SizeFromReq in Request -> A size in request >>SizeFromReq in Response -> (would not typically occur as it's meaningless) >> >>In this way, the SizeFromRsp option in a request could be used to inform >>the responder that the requester cannot handle any more than the size in >>the option (even if it is sent in blocks) and the responder can then >>simply respond with a 4.13 (Request Entity Too Large) if it knows the >>resource is too large, although it may be better to relax the name to >>just 4.13 (Entity Too Large) in this case. >> >>Robert >> >>On 13/05/2011 10:38 AM, Likepeng wrote: >>>> Block1 and Block2 are not very helpful names. >>> +1. When I read Block draft, I have to take notes to remind me from time to >>time which one is for what purpose. >>> >>>> BlockFromReq for Block1 and BlockFromRsp for Block2 or something? >>> How about BlockReq and BlockRsp? BlockReq is for Put/Pust, and BlockRsp >>for Get. >>> >>> Kind Regards >>> Kepeng >>> -----Original Message----- >>> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of >>Robert Cragie >>> Sent: Friday, May 13, 2011 5:31 PM >>> To: core >>> Subject: [core] Block names >>> >>> Block1 and Block2 are not very helpful names. As they are tied to request and >>response, how about something like BlockFromReq for Block1 and >>BlockFromRsp for Block2 or something? >>> >>> BlockFromRsp in Request -> (expecting) A block in response BlockFromRsp >>in Response -> A block in response BlockFromReq in Request -> A block in >>request BlockFromReq in Response -> (received) A block in request >>> >>> Robert >>> >> >>_______________________________________________ >>core mailing list >>core@ietf.org >>https://www.ietf.org/mailman/listinfo/core From trac+core@trac.tools.ietf.org Thu May 19 13:51:49 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CAB1E06B3 for ; Thu, 19 May 2011 13:51:49 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajmggOofvo9b for ; Thu, 19 May 2011 13:51:48 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id D9C97E0677 for ; Thu, 19 May 2011 13:51:48 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QNAC0-0006WM-7a; Thu, 19 May 2011 13:51:36 -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: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Thu, 19 May 2011 20:51:36 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/153 Message-ID: <051.930a886e6b7e4afd934175bd439cabd5@trac.tools.ietf.org> X-Trac-Ticket-ID: 153 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20110519205148.D9C97E0677@ietfa.amsl.com> Resent-Date: Thu, 19 May 2011 13:51:48 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #153: Make congestion control recommendation more actionable X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2011 20:51:49 -0000 #153: Make congestion control recommendation more actionable As per Cullen's comment, we need to be more specific about how an implementation should limit the number of simultaneous outstanding interactions so we can still argue this is a stop-and-wait protocol. Proposed text: In order not to cause congestion, Clients (including proxies) SHOULD strictly limit the number of simultaneous outstanding interactions that they maintain to a given server (including proxies). An outstanding interaction is either a CON for which an ACK has not yet been received but is still expected (message layer) or a request for which a response has not yet been received but is still expected (which may both occur at the same time, counting as one outstanding interaction). A good value for this limit is the number 1. (Note that {{RFC2616}}, in trying to achieve a similar objective, did specify a specific number of simultaneous connections as a ceiling. While revising {{RFC2616}}, this was found to be impractical for many applications {{I-D.ietf-httpbis-p1-messaging}}. For the same considerations, this specification does not mandate a particular maximum number of outstanding interactions, but instead encourages clients to be conservative when initiating interactions.) -- ----------------------------------+----------------------------------------- Reporter: cabo@… | Owner: draft-ietf-core-coap@… Type: protocol enhancement | Status: new Priority: major | Milestone: Component: coap | Version: Severity: Active WG Document | Keywords: ----------------------------------+----------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Sun May 22 05:53:58 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75FEAE06B6 for ; Sun, 22 May 2011 05:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.6 X-Spam-Level: X-Spam-Status: No, score=-104.6 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tF66rWFxlFzU for ; Sun, 22 May 2011 05:53:55 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) by ietfa.amsl.com (Postfix) with ESMTP id CCC74E0658 for ; Sun, 22 May 2011 05:53:55 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QO8AL-0001xQ-Jt; Sun, 22 May 2011 05:53: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: zach@sensinode.com X-Trac-Project: core Date: Sun, 22 May 2011 12:53:53 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/154 Message-ID: <057.d9676aeeb0b1c844122c71cec07dc9e3@trac.tools.ietf.org> X-Trac-Ticket-ID: 154 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] #154: Separate coaps:// schema and port for DTLS X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2011 12:53:58 -0000 #154: Separate coaps:// schema and port for DTLS In Prague the WG decided to make a strong binding between != NoSec security modes and DTLS, as seen in coap-06. There has been WG interest in a separate "Secure CoAP" scheme and port for use with DTLS instead of multiplexing on the same port. The Prague change makes this more practical. This ticket proposes the following changes: * Separate ports for CoAP (NoSec mode) and DTLS/CoAP (Anything != NoSec mode) * A separate coaps:// scheme to indicate DTLS/CoAP * Removal of Section 7.3 "Multiplexing DTLS and CoAP" * Add a URI scheme and port registration for coaps:// * Discuss how to make use of SharedKey, MultiKey and Certificate modes with DTLS using a single coaps:// scheme in Section 10. -- ----------------------------------+----------------------------------------- Reporter: zach@… | Owner: zach@… Type: protocol enhancement | Status: new Priority: minor | Milestone: Component: coap | Version: Severity: - | Keywords: ----------------------------------+----------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Sun May 22 06:07:30 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D72CCE069E for ; Sun, 22 May 2011 06:07: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=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ptEwVeUtRIj for ; Sun, 22 May 2011 06:07:30 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 4C8F5E066C for ; Sun, 22 May 2011 06:07:29 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QO8NR-0000bY-Kt; Sun, 22 May 2011 06:07:25 -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: Sun, 22 May 2011 13:07:25 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/155 Message-ID: <057.5a5705e0046569ddd481206733703337@trac.tools.ietf.org> X-Trac-Ticket-ID: 155 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+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] #155: If-Match and If-None-Match options X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2011 13:07:30 -0000 #155: If-Match and If-None-Match options Add an If-Match option as defined in Section 3 of draft-bormann-coap- misc-08, and a corresponding If-None-Match option. -- ----------------------------------+----------------------------------------- Reporter: zach@… | Owner: cabo@… Type: protocol enhancement | Status: new Priority: minor | Milestone: Component: coap | Version: Severity: - | Keywords: ----------------------------------+----------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Sun May 22 06:21:38 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6A37E0689 for ; Sun, 22 May 2011 06:21:38 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ym1ZAamseiF9 for ; Sun, 22 May 2011 06:21:38 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 4A7D7E067F for ; Sun, 22 May 2011 06:21:37 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QO8bA-0003cn-T9; Sun, 22 May 2011 06:21:36 -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, 22 May 2011 13:21:36 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/156 Message-ID: <057.dd42b4c72c7d62f11b05f9e63f961a46@trac.tools.ietf.org> X-Trac-Ticket-ID: 156 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] #156: Mandatory to implement security X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2011 13:21:38 -0000 #156: Mandatory to implement security Cullen made a comment that even thought the DTLS binding in coap-06 is clearer, we still aren't explicitly saying what security modes are mandatory to implement (even though each has a mandatory to implement cipher suite defined). This ticket is to add text to Section 10 defining that the NoSec, SharedKey and MultiKey security modes are mandatory to implement. -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: editorial | Status: new Priority: minor | Milestone: Component: coap | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Sun May 22 09:15:19 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40E06E0670 for ; Sun, 22 May 2011 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id csp6xHbsLJOq for ; Sun, 22 May 2011 09:15:18 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 57CC4E065D for ; Sun, 22 May 2011 09:15:17 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QOBJE-0000rs-7Y; Sun, 22 May 2011 09:15:16 -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, 22 May 2011 16:15:16 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/152#comment:1 Message-ID: <060.ca487e98541e879b382624bc3f7ba70c@trac.tools.ietf.org> References: <051.fc4a5a3ccdd31bb197760894c44783b7@trac.tools.ietf.org> X-Trac-Ticket-ID: 152 In-Reply-To: <051.fc4a5a3ccdd31bb197760894c44783b7@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #152: Update link-format for coap-06 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2011 16:15:19 -0000 #152: Update link-format for coap-06 Changes (by zach@…): * component: block => link-format -- --------------------------------+------------------------------------------- Reporter: cabo@… | Owner: zach@… Type: editorial | Status: new Priority: trivial | Milestone: Component: link-format | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Sun May 22 09:18:21 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A937E0670 for ; Sun, 22 May 2011 09:18:21 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SS9KvN9C36QW for ; Sun, 22 May 2011 09:18:20 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 617CBE065D for ; Sun, 22 May 2011 09:18:20 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QOBMC-00069p-Ap; Sun, 22 May 2011 09:18:20 -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, 22 May 2011 16:18:20 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/157 Message-ID: <057.22a02c82868476896a3e5c2492055ddc@trac.tools.ietf.org> X-Trac-Ticket-ID: 157 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] #157: Encoding consideration should be "Binary data" X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2011 16:18:21 -0000 #157: Encoding consideration should be "Binary data" Cullen pointed out that the current encoding consideration for the application/link-format registration is wrong. Should be "Binary data" instead of "8bit (UTF-8)". -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: editorial | Status: new Priority: minor | Milestone: Component: link-format | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Sun May 22 09:20:29 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42626E0696 for ; Sun, 22 May 2011 09:20:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=-0.076, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r9VOV3nP2Xwh for ; Sun, 22 May 2011 09:20:28 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id C71B3E0670 for ; Sun, 22 May 2011 09:20:28 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QOBOF-0001w2-QY; Sun, 22 May 2011 09:20:27 -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, 22 May 2011 16:20:27 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/158 Message-ID: <057.7ebee9da833e9d1913284e276c1425d3@trac.tools.ietf.org> X-Trac-Ticket-ID: 158 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] #158: Reference RFC5988 instead of mentioning UTF-8 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2011 16:20:29 -0000 #158: Reference RFC5988 instead of mentioning UTF-8 This ticket is to remove mention of UTF-8 and NFC from this document, as RFC5988 already defines the links as per RFC3986. -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: editorial | Status: new Priority: trivial | Milestone: Component: link-format | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Sun May 22 09:22:21 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D228E067B for ; Sun, 22 May 2011 09:22:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 98EjSUZkmHHn for ; Sun, 22 May 2011 09:22:20 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 15AC1E0670 for ; Sun, 22 May 2011 09:22:19 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QOBQ3-0006CF-GP; Sun, 22 May 2011 09:22: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: Sun, 22 May 2011 16:22:19 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/159 Message-ID: <057.ae6b827b49985a7f598eb159a0d4f069@trac.tools.ietf.org> X-Trac-Ticket-ID: 159 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] #159: No leading zeros in integer ABNF X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2011 16:22:21 -0000 #159: No leading zeros in integer ABNF Update the integer ABNF not to allow leading zeros. -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: editorial | Status: new Priority: minor | Milestone: Component: link-format | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Sun May 22 09:24:32 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D0D3E067B for ; Sun, 22 May 2011 09:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aSovEMYVrPgc for ; Sun, 22 May 2011 09:24:31 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 8A70AE0670 for ; Sun, 22 May 2011 09:24:30 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QOBSA-0002jU-0z; Sun, 22 May 2011 09:24:30 -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, 22 May 2011 16:24:30 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/160 Message-ID: <057.2841fb0030ce654b672f70e0a42ee388@trac.tools.ietf.org> X-Trac-Ticket-ID: 160 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] #160: Move application/link-format media type code to CoAP document X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2011 16:24:32 -0000 #160: Move application/link-format media type code to CoAP document As core-link-format is ahead of core-coap, the application/link-format media type code should just be included in the initial population table of core-coap and Section 7.4 removed from link-format. -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: task | Status: new Priority: trivial | Milestone: Component: coap | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Sun May 22 09:28:19 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D558DE06B1 for ; Sun, 22 May 2011 09:28:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TsjTfXFCQja3 for ; Sun, 22 May 2011 09:28:19 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 87E39E06AC for ; Sun, 22 May 2011 09:28:19 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QOBVq-0002BC-JW; Sun, 22 May 2011 09:28:18 -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, 22 May 2011 16:28:18 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/160#comment:1 Message-ID: <066.3ffd5129db757d158109827a72aa8e07@trac.tools.ietf.org> References: <057.2841fb0030ce654b672f70e0a42ee388@trac.tools.ietf.org> X-Trac-Ticket-ID: 160 In-Reply-To: <057.2841fb0030ce654b672f70e0a42ee388@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #160: Move application/link-format media type code to CoAP document X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2011 16:28:19 -0000 #160: Move application/link-format media type code to CoAP document Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: Done in coap-07 and link-format-05. -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: task | Status: closed Priority: trivial | Milestone: Component: coap | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Sun May 22 09:45:46 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA2C7E0682 for ; Sun, 22 May 2011 09:45:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.099 X-Spam-Level: X-Spam-Status: No, score=-105.099 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MGiuRqxbB7Hb for ; Sun, 22 May 2011 09:45:46 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) by ietfa.amsl.com (Postfix) with ESMTP id 3A567E067B for ; Sun, 22 May 2011 09:45:46 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QOBmi-0006tg-Nc; Sun, 22 May 2011 09:45:44 -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, 22 May 2011 16:45:44 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/159#comment:1 Message-ID: <066.f39c3b4c337aed56c20ea277234a6768@trac.tools.ietf.org> References: <057.ae6b827b49985a7f598eb159a0d4f069@trac.tools.ietf.org> X-Trac-Ticket-ID: 159 In-Reply-To: <057.ae6b827b49985a7f598eb159a0d4f069@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #159: No leading zeros in integer ABNF X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2011 16:45:47 -0000 #159: No leading zeros in integer ABNF Changes (by zach@…): * status: new => closed * resolution: => fixed -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: editorial | Status: closed Priority: minor | Milestone: Component: link-format | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Sun May 22 09:46:28 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27C20E069D for ; Sun, 22 May 2011 09:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.591 X-Spam-Level: X-Spam-Status: No, score=-102.591 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5a9HhKhpHs+b for ; Sun, 22 May 2011 09:46:27 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 18968E0689 for ; Sun, 22 May 2011 09:46:27 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QOBnO-0007Jg-CF; Sun, 22 May 2011 09:46:26 -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, 22 May 2011 16:46:26 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/157#comment:1 Message-ID: <066.7bb9e37ca3d53f2e252ae5375279d66d@trac.tools.ietf.org> References: <057.22a02c82868476896a3e5c2492055ddc@trac.tools.ietf.org> X-Trac-Ticket-ID: 157 In-Reply-To: <057.22a02c82868476896a3e5c2492055ddc@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #157: Encoding consideration should be "Binary data" X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2011 16:46:28 -0000 #157: Encoding consideration should be "Binary data" Changes (by zach@…): * status: new => closed * resolution: => fixed -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: editorial | Status: closed Priority: minor | Milestone: Component: link-format | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Sun May 22 09:50:43 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2D75E069D for ; Sun, 22 May 2011 09:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.399 X-Spam-Level: X-Spam-Status: No, score=-105.399 tagged_above=-999 required=5 tests=[AWL=1.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n1Q06HCWuJ2B for ; Sun, 22 May 2011 09:50:38 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE8EE0670 for ; Sun, 22 May 2011 09:50:38 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QOBrS-0004nr-Ec; Sun, 22 May 2011 09:50:38 -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, 22 May 2011 16:50:38 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/152#comment:2 Message-ID: <060.cc75f16704f2e6f44612fbd55abb9575@trac.tools.ietf.org> References: <051.fc4a5a3ccdd31bb197760894c44783b7@trac.tools.ietf.org> X-Trac-Ticket-ID: 152 In-Reply-To: <051.fc4a5a3ccdd31bb197760894c44783b7@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #152: Update link-format for coap-06 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2011 16:50:43 -0000 #152: Update link-format for coap-06 Changes (by zach@…): * status: new => closed * resolution: => fixed -- --------------------------------+------------------------------------------- Reporter: cabo@… | Owner: zach@… Type: editorial | Status: closed Priority: trivial | Milestone: Component: link-format | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Sun May 22 09:52:53 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0923FE06B6 for ; Sun, 22 May 2011 09:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.523 X-Spam-Level: X-Spam-Status: No, score=-105.523 tagged_above=-999 required=5 tests=[AWL=0.924, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iAARbuRHNFE4 for ; Sun, 22 May 2011 09:52:52 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB17E06B4 for ; Sun, 22 May 2011 09:52:52 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QOBtb-0004r2-AQ; Sun, 22 May 2011 09:52: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: Sun, 22 May 2011 16:52:51 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/158#comment:1 Message-ID: <066.6b8e0a972f8634d0312c1d1c3883c6f5@trac.tools.ietf.org> References: <057.7ebee9da833e9d1913284e276c1425d3@trac.tools.ietf.org> X-Trac-Ticket-ID: 158 In-Reply-To: <057.7ebee9da833e9d1913284e276c1425d3@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #158: Reference RFC5988 instead of mentioning UTF-8 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2011 16:52:53 -0000 #158: Reference RFC5988 instead of mentioning UTF-8 Changes (by zach@…): * status: new => closed * resolution: => fixed -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: editorial | Status: closed Priority: trivial | Milestone: Component: link-format | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Ticket URL: core From internet-drafts@ietf.org Sun May 22 10:10:47 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D988FE06B4; Sun, 22 May 2011 10:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZFED+hRIsrOs; Sun, 22 May 2011 10:10:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9770E0682; Sun, 22 May 2011 10:10:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.54 Message-ID: <20110522171046.16924.11242.idtracker@ietfa.amsl.com> Date: Sun, 22 May 2011 10:10:46 -0700 Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-link-format-05.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2011 17:10:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Constrained RESTful Environments Work= ing Group of the IETF. Title : CoRE Link Format Author(s) : Zach Shelby Filename : draft-ietf-core-link-format-05.txt Pages : 19 Date : 2011-05-22 This document defines Web Linking using a link format for use by constrained web servers to describe hosted resources, their attributes and other relationships between links. Based on the HTTP Link Header format defined in RFC5988, the CoRE Link Format is carried as a payload and is assigned an Internet media type. A well- known URI is defined as a default entry-point for requesting the links hosted by a server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-core-link-format-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-core-link-format-05.txt From zach@sensinode.com Sun May 22 12:48:43 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E825E06A4 for ; Sun, 22 May 2011 12:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bsaujy1GtdAw for ; Sun, 22 May 2011 12:48:42 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 81DE3E06A0 for ; Sun, 22 May 2011 12:48:40 -0700 (PDT) Received: from 87-95-211-105.bb.dnainternet.fi (87-95-211-105.bb.dnainternet.fi [87.95.211.105]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id p4MHCvmB028440 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 22 May 2011 20:12:58 +0300 From: Zach Shelby Content-Type: multipart/signed; boundary=Apple-Mail-11--787817866; protocol="application/pkcs7-signature"; micalg=sha1 Date: Sun, 22 May 2011 20:13:00 +0300 References: <20110522171046.16924.69512.idtracker@ietfa.amsl.com> To: "core@ietf.org WG" Message-Id: Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [core] Fwd: New Version Notification for draft-ietf-core-link-format-05.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2011 19:48:43 -0000 --Apple-Mail-11--787817866 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii CoRE Link Format -05 is now available: http://www.ietf.org/internet-drafts/draft-ietf-core-link-format-05.txt I closed the minor tickets that resulted from Cullen's helpful review: Changes from ietf-04 to ietf-05: o Removed mention of UTF-8 as this is already defined by RFC5988 (#158) o Changed encoding considerations to "Binary data" (#157) o Updated ABNF to dissallow leading zeros in intergers (#159) o Updated examples and reference for coap-06 (#152) o Removed the applcation/link-format CoAP code registration, now included in the CoAP specification directly (#160) Zach Begin forwarded message: > From: internet-drafts@ietf.org > Date: May 22, 2011 8:10:46 PM GMT+03:00 > To: zach@sensinode.com > Cc: zach@sensinode.com > Subject: New Version Notification for = draft-ietf-core-link-format-05.txt >=20 > A new version of I-D, draft-ietf-core-link-format-05.txt has been = successfully submitted by Zach Shelby and posted to the IETF repository. >=20 > Filename: draft-ietf-core-link-format > Revision: 05 > Title: CoRE Link Format > Creation date: 2011-05-22 > WG ID: core > Number of pages: 19 >=20 > Abstract: > This document defines Web Linking using a link format for use by > constrained web servers to describe hosted resources, their > attributes and other relationships between links. Based on the HTTP > Link Header format defined in RFC5988, the CoRE Link Format is > carried as a payload and is assigned an Internet media type. A = well- > known URI is defined as a default entry-point for requesting the > links hosted by a server. >=20 >=20 >=20 >=20 > The IETF Secretariat --=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-11--787817866 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 ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDUyMjE3MTMw MFowIwYJKoZIhvcNAQkEMRYEFEFOdvV6XDYY81wE1p/2E2c11TDhMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAHVGWNuzg2Fa4sziBtSzELP5+nIlDQGbgaVaA193o+nB+cF2pplxJ+wz FCEno+jLBk+EDe8CGE8H8ZIRFVdcwM+WxhsbfHamFTFKAQbgxxwzvwYJ4fZgc7f5rLXC+iAa2iU6 kaM00lVx6hu3M81TKx/C8KIRUsc8cxt45w/VrfjmPaRvN1HL3fxopHNYKcricYI7mbTIyk84oFgv bh0GeTcR3ZnLnI3123sCZoQT8OENKGMPEOLGNf/GHHG/2Q3gPavR8l8bV1BfldU8BRyxTRjT7UEf SxzfypXSJDbVwWfyeTNFLxPHBju+1MNNRHx6FgRLwduSHc70gts45Hog8ncAAAAAAAA= --Apple-Mail-11--787817866-- From alexey.melnikov@isode.com Tue May 24 14:15:14 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20AD9E078B for ; Tue, 24 May 2011 14:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.299 X-Spam-Level: X-Spam-Status: No, score=-101.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTHfj-py7t5h for ; Tue, 24 May 2011 14:15:13 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 04C85E0786 for ; Tue, 24 May 2011 14:15:13 -0700 (PDT) Received: from [188.28.52.135] (188.28.52.135.threembb.co.uk [188.28.52.135]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 24 May 2011 22:15:10 +0100 Message-ID: <4DDC1D17.8060000@isode.com> Date: Tue, 24 May 2011 22:03:19 +0100 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 , Cullen Jennings References: <9CF83338-EB7C-4831-8A44-8DEEF0C42D54@cisco.com> <9DC0A259-3170-4C40-BAB3-697B30FB548C@sensinode.com> In-Reply-To: <9DC0A259-3170-4C40-BAB3-697B30FB548C@sensinode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: core WG Subject: Re: [core] Comments on draft-ietf-core-link-format-04 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 24 May 2011 21:15:14 -0000 Zach Shelby wrote: >Cullen, > Hi, Sorry for the slow response. >Thanks for the review, comments in-line. Would like to have Alexey's opinion on these too. > >On May 4, 2011, at 8:29 PM, Cullen Jennings wrote: > > >>Mediums sized issue: >> >>I'm confused by the Encoding considerations in link-format-04 which are listed as "8bit (UTF-8 (NFC))". I suspect this should just say "binary". If this is really NFC, then does it mean constrained nodes need to do the canonicalization? Most places in the draft it makes it clear that you processes the data as binary data. Every implementation I have seen treats this as binary data - even section 4.1 describes a bitwise identical comparison. We also have the issue that RFC 2045 says >> >> "8bit data" refers to data that is all represented as relatively >> short lines with 998 octets or less between CRLF line separation >> >>and >> >> "Binary data" refers to data where any sequence of octets whatsoever >> is allowed. >> >>I think what we have here is binary data which seems fine. This is meant to be be machine readable and it's not like we have to enforce that no lines is longer than 1000 octets. Yes, many of the strings in the binary blob of data may happen to be UTF-8 strings that are even in Normalized Form C but unless we get more specific about when and where this gets normalized I don't see how specifying this is NFC data helps. In fact most, if not all, of this is from a far more restricted grammar than UTF-8 NFC. >> > >The 8bit was suggested by Alexey. I would be fine with "Binary data", your point makes sense. I will make a ticket if I don't hear any objections. > If your data can include NULs, or bare LFs or CRs, or consist of long lines, then "binary" is fine. >>Related to this, where it says the CoRE link format MUST be in UTF-8 and SHOULD be NFC. This seems wrong unless we are updating RFC5988. RFC5988 makes it clear the links are as defined in rfc3986. We don't need to say any more or less than RFC5988. Unless someone can tell me how my implementation and interoperability changes by specifying UTF-8 and NFC, I'd like to see that removed. The phrase "MUST be compared as strings" is pretty vague when discussing UTF-8 strings. If people disagree here, I'm going to argue that unicode has a perfectly good symbol for angstrom and if someone wants to use that, I think they should be able to use it. Given this is format is for machine readability, an angstrom is not the same as a character that might look the same when printed on paper and that difference should not be lost. >> >>All in all, the documents this depends on, such as 5988 deal with the right level of using UTF-8. This draft should just be silent on the issue and you can probably remove all mention of UTF-8. Regardless of the UTF-8 issues, it seems the media type registration should have binary not 8bit. >> > >This is how I started out, but in a couple review's a couple versions back it was suggested that we specify UTF-8 and we made a ticket for that. The intention is definitely to be in line with RFC5988, so I would be more than happy to have no mention of UTF-8 in the document and instead just say "the links are as defined in rfc3986". Again, will make a ticket if I hear no objections. > But RFC 3986 only covers URIs and CoRE link format can include other data? I think saying that the format contains UTF-8 is actually useful for future extensibility. From fluffy@cisco.com Thu May 26 09:24:15 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F376EE0750 for ; Thu, 26 May 2011 09:24:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.476 X-Spam-Level: X-Spam-Status: No, score=-110.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vx+gSsCFW5QI for ; Thu, 26 May 2011 09:24:13 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id DD7A2E0618 for ; Thu, 26 May 2011 09:24:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=5411; q=dns/txt; s=iport; t=1306427053; x=1307636653; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=RdAun48R2zyBgBzOkWtjvGAcgkLjARKXD5kEXjsoPEY=; b=lgnRjzqqvm8VFRReXlRDKgk7l4YS8K4M5Oo2k8XC2S6ICe5T8T6qX83M hQasXy1vdnY9maLoTI8zGk+lbfOIQnu58w35SkHblQEpy/cKJPZqXVMHh yBqGI3givlEAFDuATQAh/rfM46p74OIu6eY6pH8hBuQI36vRIjyvlabZi 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAGZ93k2rRDoI/2dsb2JhbABVpjB4iHCgOZ1ehhwEhmGJWIQ5inY X-IronPort-AV: E=Sophos;i="4.65,273,1304294400"; d="scan'208";a="454881051" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-1.cisco.com with ESMTP; 26 May 2011 16:24:13 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p4QGOCmZ032734; Thu, 26 May 2011 16:24:12 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4DDC1D17.8060000@isode.com> Date: Thu, 26 May 2011 10:24:11 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9CF83338-EB7C-4831-8A44-8DEEF0C42D54@cisco.com> <9DC0A259-3170-4C40-BAB3-697B30FB548C@sensinode.com> <4DDC1D17.8060000@isode.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.1084) Cc: core WG Subject: Re: [core] Comments on draft-ietf-core-link-format-04 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 26 May 2011 16:24:15 -0000 On May 24, 2011, at 3:03 PM, Alexey Melnikov wrote: > Zach Shelby wrote: >=20 >> Cullen, >>=20 > Hi, > Sorry for the slow response. >=20 >> Thanks for the review, comments in-line. Would like to have Alexey's = opinion on these too. >>=20 >> On May 4, 2011, at 8:29 PM, Cullen Jennings wrote: >>=20 >>> Mediums sized issue: >>>=20 >>> I'm confused by the Encoding considerations in link-format-04 which = are listed as "8bit (UTF-8 (NFC))". I suspect this should just say = "binary". If this is really NFC, then does it mean constrained nodes = need to do the canonicalization? Most places in the draft it makes it = clear that you processes the data as binary data. Every implementation = I have seen treats this as binary data - even section 4.1 describes a = bitwise identical comparison. We also have the issue that RFC 2045 says=20= >>> "8bit data" refers to data that is all represented as relatively >>> short lines with 998 octets or less between CRLF line separation >>>=20 >>> and >>>=20 >>> "Binary data" refers to data where any sequence of octets whatsoever >>> is allowed. >>>=20 >>> I think what we have here is binary data which seems fine. This is = meant to be be machine readable and it's not like we have to enforce = that no lines is longer than 1000 octets. Yes, many of the strings in = the binary blob of data may happen to be UTF-8 strings that are even in = Normalized Form C but unless we get more specific about when and where = this gets normalized I don't see how specifying this is NFC data helps. = In fact most, if not all, of this is from a far more restricted grammar = than UTF-8 NFC. =20 >>=20 >> The 8bit was suggested by Alexey. I would be fine with "Binary data", = your point makes sense. I will make a ticket if I don't hear any = objections.=20 > If your data can include NULs, or bare LFs or CRs, or consist of long = lines, then "binary" is fine. It can definitely have long lines but I'm can't think of a place that = allows for NUL or other weird control characters. Take for example the = rt attribute. Right now it is defined as RFC 2616 style quoted-string = which means I can not really put UTF-8 data in it yet this is a place = where I may want to call something "Temperature at = house". If Core treated that as any character other than double quote = being allowed, we would be in fine shape for allowing people to put = UTF-8 there.=20 >=20 >>> Related to this, where it says the CoRE link format MUST be in UTF-8 = and SHOULD be NFC. This seems wrong unless we are updating RFC5988. = RFC5988 makes it clear the links are as defined in rfc3986. We don't = need to say any more or less than RFC5988. Unless someone can tell me = how my implementation and interoperability changes by specifying UTF-8 = and NFC, I'd like to see that removed. The phrase "MUST be compared as = strings" is pretty vague when discussing UTF-8 strings. If people = disagree here, I'm going to argue that unicode has a perfectly good = symbol for angstrom and if someone wants to use that, I think they = should be able to use it. Given this is format is for machine = readability, an angstrom is not the same as a character that might look = the same when printed on paper and that difference should not be lost. =20= >>> All in all, the documents this depends on, such as 5988 deal with = the right level of using UTF-8. This draft should just be silent on the = issue and you can probably remove all mention of UTF-8. Regardless of = the UTF-8 issues, it seems the media type registration should have = binary not 8bit. =20 >>=20 >> This is how I started out, but in a couple review's a couple versions = back it was suggested that we specify UTF-8 and we made a ticket for = that. The intention is definitely to be in line with RFC5988, so I would = be more than happy to have no mention of UTF-8 in the document and = instead just say "the links are as defined in rfc3986". Again, will make = a ticket if I hear no objections. >>=20 > But RFC 3986 only covers URIs and CoRE link format can include other = data? > I think saying that the format contains UTF-8 is actually useful for = future extensibility. >=20 I think the part I am getting hung up on is what is allowed, and what = needs to be checked and enforced by everyone. I think most the WG agrees = they want implementation to treat things as just a bunch of bits that is = passed around with no bitwise changes and are compared bit for bit. They = are perfectly happy if these bit strings turn out to be UTF-8 strings = and no desire to limit it to US-ASCII for the stuff that is meant for = humans instead of machines. I suspect you are roughly on the same page = but the question is how to get the specification to say that clearly = enough that implementors don't get confused. Some of this confusion is = introduced by people that don't understand core and are arguing against = it's use - for example I recently saw a draft presentation that claimed = small constrained nodes implement core would need a full XML library and = unicode string process library. I straightened out that presentation but = was I like the specs to be clear enough that I did not see stuff like = that.=20 Thoughts on how to get this clear in the main coap draft as well as = here.=20 From alexey.melnikov@isode.com Thu May 26 10:15:36 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E5B2130057 for ; Thu, 26 May 2011 10:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.413 X-Spam-Level: X-Spam-Status: No, score=-102.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GeEaNgOJlp98 for ; Thu, 26 May 2011 10:15:35 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 256C8130019 for ; Thu, 26 May 2011 10:15:35 -0700 (PDT) Received: from [192.168.1.124] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 26 May 2011 18:15:33 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4DDE8A91.3070202@isode.com> Date: Thu, 26 May 2011 18:14:57 +0100 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: Cullen Jennings References: <9CF83338-EB7C-4831-8A44-8DEEF0C42D54@cisco.com> <9DC0A259-3170-4C40-BAB3-697B30FB548C@sensinode.com> <4DDC1D17.8060000@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] Comments on draft-ietf-core-link-format-04 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 26 May 2011 17:15:36 -0000 Cullen Jennings wrote: >On May 24, 2011, at 3:03 PM, Alexey Melnikov wrote: > > >>Zach Shelby wrote: >> >> >>>On May 4, 2011, at 8:29 PM, Cullen Jennings wrote: >>> [...] >>>>Related to this, where it says the CoRE link format MUST be in UTF-8 and SHOULD be NFC. This seems wrong unless we are updating RFC5988. RFC5988 makes it clear the links are as defined in rfc3986. We don't need to say any more or less than RFC5988. Unless someone can tell me how my implementation and interoperability changes by specifying UTF-8 and NFC, I'd like to see that removed. The phrase "MUST be compared as strings" is pretty vague when discussing UTF-8 strings. If people disagree here, I'm going to argue that unicode has a perfectly good symbol for angstrom and if someone wants to use that, I think they should be able to use it. Given this is format is for machine readability, an angstrom is not the same as a character that might look the same when printed on paper and that difference should not be lost. >>>>All in all, the documents this depends on, such as 5988 deal with the right level of using UTF-8. This draft should just be silent on the issue and you can probably remove all mention of UTF-8. Regardless of the UTF-8 issues, it seems the media type registration should have binary not 8bit. >>>> >>>This is how I started out, but in a couple review's a couple versions back it was suggested that we specify UTF-8 and we made a ticket for that. The intention is definitely to be in line with RFC5988, so I would be more than happy to have no mention of UTF-8 in the document and instead just say "the links are as defined in rfc3986". Again, will make a ticket if I hear no objections. >>> >>> >>But RFC 3986 only covers URIs and CoRE link format can include other data? >>I think saying that the format contains UTF-8 is actually useful for future extensibility. >> > >I think the part I am getting hung up on is what is allowed, and what needs to be checked and enforced by everyone. I think most the WG agrees they want implementation to treat things as just a bunch of bits that is passed around with no bitwise changes and are compared bit for bit. > That is fine. But this doesn't mean that data is binary (for example). >They are perfectly happy if these bit strings turn out to be UTF-8 strings and no desire to limit it to US-ASCII for the stuff that is meant for humans instead of machines. I suspect you are roughly on the same page but the question is how to get the specification to say that clearly enough that implementors don't get confused. Some of this confusion is introduced by people that don't understand core and are arguing against it's use - for example I recently saw a draft presentation that claimed small constrained nodes implement core would need a full XML library and unicode string process library. I straightened out that presentation but was I like the specs to be clear enough that I did not see >stuff like that. > >Thoughts on how to get this clear in the main coap draft as well as here. > I think at least saying that any CORE link format payload is UTF-8 is useful. This tells implementations what they should generate and what they can expect. And if they want to check for UTF-8 and reject invalid data, they can. If you want to say more than "MUST be UTF-8", then you should probably have separate statements about what compliant generators should produce and what consumers should do. NFC or any other form of Unicode normalization is useful for comparison or lookup of values. If UTF-8 data is only used for display, I don't think this is needed. From zach@sensinode.com Sat May 28 06:24:49 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD22E06D9 for ; Sat, 28 May 2011 06:24: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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-4DsDRH7LxO for ; Sat, 28 May 2011 06:24:48 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id BBD0AE0662 for ; Sat, 28 May 2011 06:24:47 -0700 (PDT) Received: from dyn1835.panoulu.local (gw1.panoulu.net [212.50.147.101]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id p4SDOcMI030485 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 28 May 2011 16:24:38 +0300 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-1--283117640; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: <4DDE8A91.3070202@isode.com> Date: Sat, 28 May 2011 16:24:40 +0300 Message-Id: <62F5986E-1060-4A99-9D9B-96067B45D7F4@sensinode.com> References: <9CF83338-EB7C-4831-8A44-8DEEF0C42D54@cisco.com> <9DC0A259-3170-4C40-BAB3-697B30FB548C@sensinode.com> <4DDC1D17.8060000@isode.com> <4DDE8A91.3070202@isode.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.1084) Cc: core WG Subject: Re: [core] Statement about link-format encoding X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 28 May 2011 13:24:49 -0000 --Apple-Mail-1--283117640 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii (changed the subject line) On May 26, 2011, at 8:14 PM, Alexey Melnikov wrote: >> They are perfectly happy if these bit strings turn out to be UTF-8 = strings and no desire to limit it to US-ASCII for the stuff that is = meant for humans instead of machines. I suspect you are roughly on the = same page but the question is how to get the specification to say that = clearly enough that implementors don't get confused. Some of this = confusion is introduced by people that don't understand core and are = arguing against it's use - for example I recently saw a draft = presentation that claimed small constrained nodes implement core would = need a full XML library and unicode string process library. I = straightened out that presentation but was I like the specs to be clear = enough that I did not see stuff like that.=20 >> Thoughts on how to get this clear in the main coap draft as well as = here. >>=20 > I think at least saying that any CORE link format payload is UTF-8 is = useful. This tells implementations what they should generate and what = they can expect. And if they want to check for UTF-8 and reject invalid = data, they can. If you want to say more than "MUST be UTF-8", then you = should probably have separate statements about what compliant generators = should produce and what consumers should do. >=20 > NFC or any other form of Unicode normalization is useful for = comparison or lookup of values. If UTF-8 data is only used for display, = I don't think this is needed. I agree with Cullen here that we should not be doing anything = differently than RFC5988, where the link format is defined as we are = only adding a few link-extentions for it. The RFC5988 format includes = both URIs and quoted strings, and defines a special attribute title* for = use with RFC5987 encoding of different character sets or languages in a = human readable title. In RFC5988 title and title* are the only = attributes meant for human display. None of the new CoRE attributes are = meant for human display.=20 The only difference is that the CoRE Link Format is carried as a = payload, rather than as an HTTP Header. I propose that we just add a = statement that the "CoRE Link Format MUST conform to the rules of the = HTTP header [RFC2616] and [RFC5988]" . The title* attribute defined by = RFC5988 then allows for the use of RFC5987 encoding when an = international title is needed.=20 Zach=20 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 --Apple-Mail-1--283117640 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 ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDUyODEzMjQ0 MFowIwYJKoZIhvcNAQkEMRYEFElBT/uSIvcNadAWI05CUHjzGhUwMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAIIh1A2tIbtL5w44ZZuUWW/xdd55b0yKbc2xNw1hx76LzpCd0FXyodF8 RHhNtuzQpDA5AQoSfbGeiUzYKOW23aDjGD7UCPeTdU7+Ns+q9TFcdteAAzOrw09M4T7x/9/H/Epd inYVNkz5Xac74/vLQY2nL81/wZuCapppj3DY8uhXcxrBnvPFQChoCa5p3WYKUDRIFL2NlW6pBRWz Qa9pP8e8qwVbpW0UH4ICzAh6vLdLZOWZDQbQWCOoH4X8qwBpB0FZrPYDRFK3JRFdypi7vc4XJTIM J+tx1kim0kUu5wX9qxHt8GGjVr1ZPNF1/a3pLhFGgytnvqhPdCyLmOpz8f8AAAAAAAA= --Apple-Mail-1--283117640-- From trac+core@trac.tools.ietf.org Sat May 28 06:47:56 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80CF2E0677 for ; Sat, 28 May 2011 06:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.592 X-Spam-Level: X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YCtVfQXL8glW for ; Sat, 28 May 2011 06:47:56 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 2F5BBE0662 for ; Sat, 28 May 2011 06:47:56 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QQJrq-0004rw-An; Sat, 28 May 2011 06:47:50 -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, 28 May 2011 13:47:50 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/161 Message-ID: <057.b32fa055beb54b0a5bae0f7915fff78c@trac.tools.ietf.org> X-Trac-Ticket-ID: 161 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+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] #161: Registration for 2-byte media type codes X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 May 2011 13:47:56 -0000 #161: Registration for 2-byte media type codes coap-06 currently defines a Media Type Code registry for single byte code values, meant for frequently used media types. The two-byte codes are just reserved for future use. In order to encourage registration of media types, a less restrictive registration for the codes 256-65535 will be added. -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: hartke@… Type: task | Status: new Priority: minor | Milestone: Component: coap | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From cabo@tzi.org Sat May 28 13:28:56 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEF01E06FD for ; Sat, 28 May 2011 13:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.853 X-Spam-Level: X-Spam-Status: No, score=-104.853 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZvesWomIRvVN for ; Sat, 28 May 2011 13:28:55 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 657F2E06EE for ; Sat, 28 May 2011 13:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id p4SKSkGV029951; Sat, 28 May 2011 22:28:46 +0200 (CEST) Received: from [192.168.2.2] (ip-109-45-64-114.web.vodafone.de [109.45.64.114]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 8C9B4FD1; Sat, 28 May 2011 22:28:45 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=utf-8 From: Carsten Bormann In-Reply-To: <62F5986E-1060-4A99-9D9B-96067B45D7F4@sensinode.com> Date: Sat, 28 May 2011 22:28:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9A3E8863-4ADE-482F-983B-1A04E715D8D5@tzi.org> References: <9CF83338-EB7C-4831-8A44-8DEEF0C42D54@cisco.com> <9DC0A259-3170-4C40-BAB3-697B30FB548C@sensinode.com> <4DDC1D17.8060000@isode.com> <4DDE8A91.3070202@isode.com> <62F5986E-1060-4A99-9D9B-96067B45D7F4@sensinode.com> To: Zach Shelby X-Mailer: Apple Mail (2.1084) Cc: core WG Subject: Re: [core] Statement about link-format encoding X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 28 May 2011 20:28:56 -0000 > ... when an international title is needed.=20 I don't know what an international title is. Outdoor Temperature? Au=C3=9Fenthermometer? Bl=C3=A5b=C3=A6rsyltet=C3=B8y? =EC=95=BC=EC=99=B8 =EC=98=A8=EB=8F=84=EA=B3=84? =D8=A8=DB=8C=D8=B1=D9=88=D9=86=DB=8C =D8=AA=D8=B1=D9=85=D8=A7=D9=85=DB=8C=D9= =B9=D8=B1=D8=9F =E5=AE=A4=E5=A4=96=E6=B8=A9=E5=BA=A6=E8=AE=A1? =E5=B1=8B=E5=A4=96=E6=B8=A9=E5=BA=A6=E8=A8=88? I don't think any of these is "international" (well, most of them work = in two or three countries). RFC5987 is solving two problems: -- the legacy mistake of defining ISO-8859-1 encoding for HTTP headers. = We don't have that problem. -- carrying around language tags. That may be a remaining reason to do = RFC 5987. I still think that link-format could simply define the character = encoding to be UTF-8 and outlaw the use of any character encoding other = than UTF-8 even in in RFC5987 usage. There is no point in allowing the old tower of babel for anything new. While it is true that many kinds of processing of data from human = writing systems ("characters") is hideously expensive, I don't think = that the simple act of representing a title in a link-format = representation entails any of that complexity. Entering from a = keyboard, displaying, yes. Carrying it around, no. We don't have to be = afraid of increasing complexity by removing unnecessary choice and = saying it always is UTF-8. Gruesse, Carsten From zach@sensinode.com Mon May 30 09:26:18 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC47DE080E for ; Mon, 30 May 2011 09:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uoGIHh6prmyW for ; Mon, 30 May 2011 09:26:17 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 57667E080D for ; Mon, 30 May 2011 09:26:17 -0700 (PDT) Received: from [172.24.32.20] (h51baff13.k1714.sta.perspektivbredband.net [81.186.255.19]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id p4UGQ47t028245 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 30 May 2011 19:26:05 +0300 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-46--99430823; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: <9A3E8863-4ADE-482F-983B-1A04E715D8D5@tzi.org> Date: Mon, 30 May 2011 18:26:07 +0200 Message-Id: References: <9CF83338-EB7C-4831-8A44-8DEEF0C42D54@cisco.com> <9DC0A259-3170-4C40-BAB3-697B30FB548C@sensinode.com> <4DDC1D17.8060000@isode.com> <4DDE8A91.3070202@isode.com> <62F5986E-1060-4A99-9D9B-96067B45D7F4@sensinode.com> <9A3E8863-4ADE-482F-983B-1A04E715D8D5@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.1084) Cc: Martin Thomson , core WG Subject: Re: [core] Statement about link-format encoding X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2011 16:26:19 -0000 --Apple-Mail-46--99430823 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 28, 2011, at 10:28 PM, Carsten Bormann wrote: > RFC5987 is solving two problems: > -- the legacy mistake of defining ISO-8859-1 encoding for HTTP = headers. We don't have that problem. > -- carrying around language tags. That may be a remaining reason to = do RFC 5987. >=20 > I still think that link-format could simply define the character = encoding to be UTF-8 and outlaw the use of any character encoding other = than UTF-8 even in in RFC5987 usage. > There is no point in allowing the old tower of babel for anything new. Right, this was the original intention by adding the UTF-8 language to = core-link-format. Seems that the application area folks liked that = approach as well, in recollection it was Martin Thomson's suggestion = originally (ticket #84). This also matches the UTF-8 defined for the = text/plain MIME type registry entry in core-coap and for CoAP URI = options. See http://trac.tools.ietf.org/wg/core/trac/ticket/84 > While it is true that many kinds of processing of data from human = writing systems ("characters") is hideously expensive, I don't think = that the simple act of representing a title in a link-format = representation entails any of that complexity. Entering from a = keyboard, displaying, yes. Carrying it around, no. We don't have to be = afraid of increasing complexity by removing unnecessary choice and = saying it always is UTF-8. The text we still had in link-format-04 was=20 "The CoRE link format MUST use UTF-8 encoding [RFC3629], which SHOULD be = in NFC (Unicode Normalization Form C) as per Section 3 of [RFC5198]." So Carsten, what do you suggest the UTF-8 text should be so that it = achieves the intention of carrying around UTF-8 without any added = complexity, or the misunderstandings Cullen is afraid of for readers of = the document.=20 And Cullen, now I am not sure what your intention was of your review = comment about UTF-8. Was your comment that: a) Yes, this should be encoded as UTF-8 but don't say anything about = that as it is already defined by RFC5988 via RFC3986. It turns out those = don't say that, as RFC5988 depends on the HTTP header. I removed the = UTF-8 text from link-format-05 based on this assumption.=20 *or* b) We should be using the HTTP header encoding as is assumed in RFC5988. = If so we would need to define that as it isn't obvious.=20 Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 --Apple-Mail-46--99430823 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 ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDUzMDE2MjYw N1owIwYJKoZIhvcNAQkEMRYEFHDbwBK63Okgcs/0dOFxKCjLbb8AMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBADbMFt4Si/H97BC34sxirmLjQC/55AEFaPXxoSi/mH5ttLL6Qa+bXPaq 0u5f9hzPrILHfVUXyT6sU9r2mu7PUydQaOt0DrLP8ah+jPJ0F7jyxauk/MiSBuolwRmJMenkezm9 tdCWgVw8umCuYyl7rMpkYE0833KP94HWtHrNO8KpfuUTMue6viWxNTnv2N1Ogsr21ZH30Nx0mdBP 2WykMG8ux6DLCKmCxd5TPxyCO+Qzb4kPtyVoa3aIJTKpZO9bMk0RXpyS58UvEbS6Cgy6J/ksEsYj r6MiZZ1CjfeTZeiceApi8clS9ubCJrCyf8JvcLTQbc2wPlEqUyG4aO7ScqAAAAAAAAA= --Apple-Mail-46--99430823-- From alexey.melnikov@isode.com Tue May 31 03:27:04 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9953CE06AE for ; Tue, 31 May 2011 03:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.203 X-Spam-Level: X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h5IUZB8Vlu6T for ; Tue, 31 May 2011 03:27:04 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 8CFAEE06B9 for ; Tue, 31 May 2011 03:27:03 -0700 (PDT) Received: from [188.29.122.43] (188.29.122.43.threembb.co.uk [188.29.122.43]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 31 May 2011 11:27:01 +0100 Message-ID: <4DE4C254.6000902@isode.com> Date: Tue, 31 May 2011 11:26:28 +0100 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: <9CF83338-EB7C-4831-8A44-8DEEF0C42D54@cisco.com> <9DC0A259-3170-4C40-BAB3-697B30FB548C@sensinode.com> <4DDC1D17.8060000@isode.com> <4DDE8A91.3070202@isode.com> <62F5986E-1060-4A99-9D9B-96067B45D7F4@sensinode.com> <9A3E8863-4ADE-482F-983B-1A04E715D8D5@tzi.org> In-Reply-To: <9A3E8863-4ADE-482F-983B-1A04E715D8D5@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: quoted-printable Cc: core WG Subject: Re: [core] Statement about link-format encoding X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 31 May 2011 10:27:04 -0000 Carsten Bormann wrote: >>... when an international title is needed.=20 >> =20 >> > >I don't know what an international title is. > >Outdoor Temperature? >Au=C3=9Fenthermometer? >Bl=C3=A5b=C3=A6rsyltet=C3=B8y? >=EC=95=BC=EC=99=B8 =EC=98=A8=EB=8F=84=EA=B3=84? >=D8=A8=DB=8C=D8=B1=D9=88=D9=86=DB=8C =D8=AA=D8=B1=D9=85=D8=A7=D9=85=DB=8C= =D9=B9=D8=B1=D8=9F >=E5=AE=A4=E5=A4=96=E6=B8=A9=E5=BA=A6=E8=AE=A1? >=E5=B1=8B=E5=A4=96=E6=B8=A9=E5=BA=A6=E8=A8=88? > >I don't think any of these is "international" (well, most of them work in t= wo or three countries). > >RFC5987 is solving two problems: >-- the legacy mistake of defining ISO-8859-1 encoding for HTTP headers. We= don't have that problem. > Agreed. I would think of CORE link-format as a different serialization mechanism=20 for Link values. >-- carrying around language tags. That may be a remaining reason to do RFC= 5987. > >I still think that link-format could simply define the character encoding t= o be UTF-8 and outlaw the use of any character encoding other than UTF-8 eve= n in in RFC5987 usage. >There is no point in allowing the old tower of babel for anything new. > =20 > I tend to agree. >While it is true that many kinds of processing of data from human writing s= ystems ("characters") is hideously expensive, I don't think that the simple = act of representing a title in a link-format representation entails any of t= hat complexity. Entering from a keyboard, displaying, yes. Carrying it aro= und, no. We don't have to be afraid of increasing complexity by removing un= necessary choice and saying it always is UTF-8. > =20 > From alexey.melnikov@isode.com Tue May 31 03:34:40 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94DE5E06B9 for ; Tue, 31 May 2011 03:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[AWL=0.698, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXmQGCOLM4Fd for ; Tue, 31 May 2011 03:34:40 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id A5A26E06AE for ; Tue, 31 May 2011 03:34:39 -0700 (PDT) Received: from [188.29.122.43] (188.29.122.43.threembb.co.uk [188.29.122.43]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 31 May 2011 11:34:36 +0100 Message-ID: <4DE4C41A.50904@isode.com> Date: Tue, 31 May 2011 11:34:02 +0100 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: <9CF83338-EB7C-4831-8A44-8DEEF0C42D54@cisco.com> <9DC0A259-3170-4C40-BAB3-697B30FB548C@sensinode.com> <4DDC1D17.8060000@isode.com> <4DDE8A91.3070202@isode.com> <62F5986E-1060-4A99-9D9B-96067B45D7F4@sensinode.com> <9A3E8863-4ADE-482F-983B-1A04E715D8D5@tzi.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Martin Thomson , core WG Subject: Re: [core] Statement about link-format encoding X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 31 May 2011 10:34:40 -0000 Zach Shelby wrote: >On May 28, 2011, at 10:28 PM, Carsten Bormann wrote: > >>RFC5987 is solving two problems: >>-- the legacy mistake of defining ISO-8859-1 encoding for HTTP headers. We don't have that problem. >>-- carrying around language tags. That may be a remaining reason to do RFC 5987. >> >>I still think that link-format could simply define the character encoding to be UTF-8 and outlaw the use of any character encoding other than UTF-8 even in in RFC5987 usage. >>There is no point in allowing the old tower of babel for anything new. >> >> > >Right, this was the original intention by adding the UTF-8 language to core-link-format. Seems that the application area folks liked that approach as well, > Obviously I am +1. >in recollection it was Martin Thomson's suggestion originally (ticket #84). This also matches the UTF-8 defined for the text/plain MIME type registry entry in core-coap and for CoAP URI options. > As a side note: URIs never contain non-ASCII. >See > >http://trac.tools.ietf.org/wg/core/trac/ticket/84 > > >>While it is true that many kinds of processing of data from human writing systems ("characters") is hideously expensive, I don't think that the simple act of representing a title in a link-format representation entails any of that complexity. Entering from a keyboard, displaying, yes. Carrying it around, no. We don't have to be afraid of increasing complexity by removing unnecessary choice and saying it always is UTF-8. >> >> > > >The text we still had in link-format-04 was > >"The CoRE link format MUST use UTF-8 encoding [RFC3629], which SHOULD be in NFC (Unicode Normalization Form C) as per Section 3 of [RFC5198]." > >So Carsten, what do you suggest the UTF-8 text should be so that it achieves the intention of carrying around UTF-8 without any added complexity, or the misunderstandings Cullen is afraid of for readers of the document. > > As per my earlier message, I suggest dropping ", which SHOULD be in NFC (Unicode Normalization Form C) as per Section 3 of [RFC5198]". >And Cullen, now I am not sure what your intention was of your review comment about UTF-8. Was your comment that: >a) Yes, this should be encoded as UTF-8 but don't say anything about that as it is already defined by RFC5988 via RFC3986. It turns out those don't say that, as RFC5988 depends on the HTTP header. I removed the UTF-8 text from link-format-05 based on this assumption. >*or* >b) We should be using the HTTP header encoding as is assumed in RFC5988. If so we would need to define that as it isn't obvious. > From peter.van.der.stok@philips.com Tue May 31 07:04:06 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60E1EE0685 for ; Tue, 31 May 2011 07:04:06 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uUuWfyAwmElC for ; Tue, 31 May 2011 07:04:05 -0700 (PDT) Received: from VA3EHSOBE009.bigfish.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id 3A75BE0651 for ; Tue, 31 May 2011 07:04:04 -0700 (PDT) Received: from mail154-va3-R.bigfish.com (10.7.14.236) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.22; Tue, 31 May 2011 14:04:04 +0000 Received: from mail154-va3 (localhost.localdomain [127.0.0.1]) by mail154-va3-R.bigfish.com (Postfix) with ESMTP id E828C1AE824C for ; Tue, 31 May 2011 14:04:03 +0000 (UTC) X-SpamScore: -13 X-BigFish: VPS-13(zz217bL15d6O9251Jzz1202hzzz2dh2a8h668h839h65h) X-Spam-TCS-SCL: 4:0 X-Forefront-Antispam-Report: CIP:168.87.56.20; KIP:(null); UIP:(null); IPVD:NLI; H:smtpx.philips.com; RD:smtpx.philips.com; EFVD:NLI Received: from mail154-va3 (localhost.localdomain [127.0.0.1]) by mail154-va3 (MessageSwitch) id 1306850643868381_28320; Tue, 31 May 2011 14:04:03 +0000 (UTC) Received: from VA3EHSMHS011.bigfish.com (unknown [10.7.14.238]) by mail154-va3.bigfish.com (Postfix) with ESMTP id CD14EF80046 for ; Tue, 31 May 2011 14:04:03 +0000 (UTC) Received: from smtpx.philips.com (168.87.56.20) by VA3EHSMHS011.bigfish.com (10.7.99.21) with Microsoft SMTP Server (TLS) id 14.1.225.22; Tue, 31 May 2011 14:03:54 +0000 Received: from NLAMSEXH05.connect1.local (172.16.153.68) by connect1.philips.com (172.16.156.42) with Microsoft SMTP Server (TLS) id 8.3.106.1; Tue, 31 May 2011 16:03:36 +0200 Received: from NLCLUEXM03.connect1.local ([172.16.153.29]) by NLAMSEXH05.connect1.local ([172.16.153.68]) with mapi; Tue, 31 May 2011 16:02:58 +0200 From: "Stok, Peter van der" To: core WG Date: Tue, 31 May 2011 16:03:27 +0200 Thread-Topic: Uri-host option Thread-Index: AcwffTwSy3l+qLi6QwCs0BmTNhLfTQAHUCeQ Message-ID: References: <9CF83338-EB7C-4831-8A44-8DEEF0C42D54@cisco.com> <9DC0A259-3170-4C40-BAB3-697B30FB548C@sensinode.com> <4DDC1D17.8060000@isode.com> <4DDE8A91.3070202@isode.com> <62F5986E-1060-4A99-9D9B-96067B45D7F4@sensinode.com> <9A3E8863-4ADE-482F-983B-1A04E715D8D5@tzi.org> <4DE4C254.6000902@isode.com> In-Reply-To: <4DE4C254.6000902@isode.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: [core] Uri-host option X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 14:04:06 -0000 RGVhciBhbGwsDQoNClRoZSB1cmkgcGFyc2luZyBhbGdvcml0aG0gaW4gc2VjdGlvbiA2LjMgb2Yg Y29hcC02IHNlZW1zIHRvIGltcGx5IHRoYXQgYSB1cmktaG9zdCBvcHRpb24gTVVTVCBiZSBmaWxs ZWQgaW4gd2hlbiB0aGUgdXJpIGNvbnRhaW5zIHRoZSBsaXRlcmFsIG5hbWUgb2YgYSBob3N0Lg0K SSBwcmVmZXIgYSBNQVksIHN1Y2ggdGhhdCB1cmktaG9zdCBjYW4gcmVtYWluIGVtcHR5IHdoZW4g dGhlIGhvc3QgbmFtZSBjYW4gYmUgcmVzb2x2ZWQgdG8gYW4gSVAgYWRkcmVzcy4gV2l0aCBhIE1V U1QgbG90cyBvZiB1bm5lY2Vzc2FyeSBjaGFyYWN0ZXJzIGFyZSB0cmFuc3BvcnRlZC4NCg0KUGV0 ZXIgdmFuIGRlciBTdG9rDQoNClRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtZXNz YWdlIG1heSBiZSBjb25maWRlbnRpYWwgYW5kIGxlZ2FsbHkgcHJvdGVjdGVkIHVuZGVyIGFwcGxp Y2FibGUgbGF3LiBUaGUgbWVzc2FnZSBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSBhZGRyZXNz ZWUocykuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVy ZWJ5IG5vdGlmaWVkIHRoYXQgYW55IHVzZSwgZm9yd2FyZGluZywgZGlzc2VtaW5hdGlvbiwgb3Ig cmVwcm9kdWN0aW9uIG9mIHRoaXMgbWVzc2FnZSBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBt YXkgYmUgdW5sYXdmdWwuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBs ZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgYnkgcmV0dXJuIGUtbWFpbCBhbmQgZGVzdHJveSBhbGwg Y29waWVzIG9mIHRoZSBvcmlnaW5hbCBtZXNzYWdlLg0K From tianlinyi@huawei.com Tue May 31 18:18:28 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 248F5E07FB for ; Tue, 31 May 2011 18:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZbVfXVYb1xnz for ; Tue, 31 May 2011 18:18:26 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id A4D05E07D5 for ; Tue, 31 May 2011 18:18:26 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LM300C1X7MFX0@szxga03-in.huawei.com> for core@ietf.org; Wed, 01 Jun 2011 09:18:15 +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 <0LM3007CI7MF1L@szxga03-in.huawei.com> for core@ietf.org; Wed, 01 Jun 2011 09:18:15 +0800 (CST) Received: from T34932F ([10.70.109.115]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LM300JJR7MF27@szxml06-in.huawei.com> for core@ietf.org; Wed, 01 Jun 2011 09:18:15 +0800 (CST) Date: Wed, 01 Jun 2011 09:18:15 +0800 From: Linyi Tian In-reply-to: To: "'Stok, Peter van der'" , 'core WG' Message-id: <009201cc1ff9$c84ae110$58e0a330$@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: AcwffTwSy3l+qLi6QwCs0BmTNhLfTQAHUCeQABdpZuA= References: <9CF83338-EB7C-4831-8A44-8DEEF0C42D54@cisco.com> <9DC0A259-3170-4C40-BAB3-697B30FB548C@sensinode.com> <4DDC1D17.8060000@isode.com> <4DDE8A91.3070202@isode.com> <62F5986E-1060-4A99-9D9B-96067B45D7F4@sensinode.com> <9A3E8863-4ADE-482F-983B-1A04E715D8D5@tzi.org> <4DE4C254.6000902@isode.com> Subject: Re: [core] Uri-host option X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 01:18:28 -0000 Hi, Peter I believe the section 6.3 is only talking about the URI parsing for Proxy-URI by the proxy. The first sentence implies this as follows: "The steps to parse a request's options from a string /url/ are as follows". In this case, the host MUST be present in the URI regardingless whether it is IP-Literal, IPV4 or reg-name. Then step 5 in section 6.3 is correct. The URI-Host MUST be filled with reg-name if no IP address was present. The purpose of section 6.3 may need to be clarified for better readability. Cheers, Linyi >>-----Original Message----- >>From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Stok, >>Peter van der >>Sent: Tuesday, May 31, 2011 10:03 PM >>To: core WG >>Subject: [core] Uri-host option >> >>Dear all, >> >>The uri parsing algorithm in section 6.3 of coap-6 seems to imply that a uri-host >>option MUST be filled in when the uri contains the literal name of a host. >>I prefer a MAY, such that uri-host can remain empty when the host name can >>be resolved to an IP address. With a MUST lots of unnecessary characters are >>transported. >> >>Peter van der Stok >> >>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 From tianlinyi@huawei.com Tue May 31 19:55:03 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 065F8E068E for ; Tue, 31 May 2011 19:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xel9u2kEcaDb for ; Tue, 31 May 2011 19:55:02 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0A6E0675 for ; Tue, 31 May 2011 19:55:02 -0700 (PDT) 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 <0LM3004UAC20JN@szxga05-in.huawei.com> for core@ietf.org; Wed, 01 Jun 2011 10:54:00 +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 <0LM3005GRC1ZKR@szxga05-in.huawei.com> for core@ietf.org; Wed, 01 Jun 2011 10:54:00 +0800 (CST) Received: from T34932F ([10.70.109.115]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LM3006DHC1ZU6@szxml06-in.huawei.com> for core@ietf.org; Wed, 01 Jun 2011 10:53:59 +0800 (CST) Date: Wed, 01 Jun 2011 10:53:59 +0800 From: Linyi Tian In-reply-to: <4DE4C41A.50904@isode.com> To: 'Alexey Melnikov' , 'Zach Shelby' Message-id: <00a501cc2007$28149840$783dc8c0$@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: AcwffsxALRpU7mxtTm2cHob4ov7+dAAiCSrw References: <9CF83338-EB7C-4831-8A44-8DEEF0C42D54@cisco.com> <9DC0A259-3170-4C40-BAB3-697B30FB548C@sensinode.com> <4DDC1D17.8060000@isode.com> <4DDE8A91.3070202@isode.com> <62F5986E-1060-4A99-9D9B-96067B45D7F4@sensinode.com> <9A3E8863-4ADE-482F-983B-1A04E715D8D5@tzi.org> <4DE4C41A.50904@isode.com> Cc: 'core WG' , 'Martin Thomson' Subject: Re: [core] Statement about link-format encoding X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 02:55:03 -0000 >>>>While it is true that many kinds of processing of data from human writing >>systems ("characters") is hideously expensive, I don't think that the simple act >>of representing a title in a link-format representation entails any of that >>complexity. Entering from a keyboard, displaying, yes. Carrying it around, >>no. We don't have to be afraid of increasing complexity by removing >>unnecessary choice and saying it always is UTF-8. >>>> >>> >>>The text we still had in link-format-04 was >>> >>>"The CoRE link format MUST use UTF-8 encoding [RFC3629], which SHOULD >>be in NFC (Unicode Normalization Form C) as per Section 3 of [RFC5198]." >>> >>>So Carsten, what do you suggest the UTF-8 text should be so that it achieves >>the intention of carrying around UTF-8 without any added complexity, or the >>misunderstandings Cullen is afraid of for readers of the document. >>> >>> >>As per my earlier message, I suggest dropping ", which SHOULD be in NFC >>(Unicode Normalization Form C) as per Section 3 of [RFC5198]". [Linyi Tian] Is UTF8 used by default? Is this behavior defined in other RFC? If yes, it should be fine to drop this but better to have a reference to that RFC. Cheers, Linyi From fluffy@cisco.com Tue May 31 20:47:33 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9769E06A1 for ; Tue, 31 May 2011 20:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.509 X-Spam-Level: X-Spam-Status: No, score=-110.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jwEOtWVxItjK for ; Tue, 31 May 2011 20:47:32 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id E755DE068E for ; Tue, 31 May 2011 20:47:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=4789; q=dns/txt; s=iport; t=1306900052; x=1308109652; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=/wVWG20qaIlp+7VGTLBJa/4DLin83tEaRRbZX13A804=; b=PirgEwKL8l4lUwR2miVcWik/TNge8mVPifxVMIIx5sOvMYH+T1bxYxge JisPmT72Xr8IbkJw7PJi4g72zUa6osCr/wi1TCFpEJRfeg7fos+mK8xXP iXgDutgkWQkMXo0PtzzHXmsiOhN1hgtIesRETlc0SUDhcHxmFueqqY3vs A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EANu15U2rRDoI/2dsb2JhbABTpiB3iHGfKJ1hhiAEhmSJboRDiwE X-IronPort-AV: E=Sophos;i="4.65,301,1304294400"; d="scan'208";a="327463399" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-3.cisco.com with ESMTP; 01 Jun 2011 03:46:53 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p513kqZO032031; Wed, 1 Jun 2011 03:46:52 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4DDE8A91.3070202@isode.com> Date: Tue, 31 May 2011 21:46:51 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9CF83338-EB7C-4831-8A44-8DEEF0C42D54@cisco.com> <9DC0A259-3170-4C40-BAB3-697B30FB548C@sensinode.com> <4DDC1D17.8060000@isode.com> <4DDE8A91.3070202@isode.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.1084) Cc: core WG Subject: Re: [core] Comments on draft-ietf-core-link-format-04 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 03:47:33 -0000 On May 26, 2011, at 11:14 AM, Alexey Melnikov wrote: > Cullen Jennings wrote: >=20 >> On May 24, 2011, at 3:03 PM, Alexey Melnikov wrote: >>=20 >>> Zach Shelby wrote: >>> =20 >>>> On May 4, 2011, at 8:29 PM, Cullen Jennings wrote: >>>>=20 > [...] >=20 >>>>> Related to this, where it says the CoRE link format MUST be in = UTF-8 and SHOULD be NFC. This seems wrong unless we are updating = RFC5988. RFC5988 makes it clear the links are as defined in rfc3986. We = don't need to say any more or less than RFC5988. Unless someone can tell = me how my implementation and interoperability changes by specifying = UTF-8 and NFC, I'd like to see that removed. The phrase "MUST be = compared as strings" is pretty vague when discussing UTF-8 strings. If = people disagree here, I'm going to argue that unicode has a perfectly = good symbol for angstrom and if someone wants to use that, I think they = should be able to use it. Given this is format is for machine = readability, an angstrom is not the same as a character that might look = the same when printed on paper and that difference should not be lost. = All in all, the documents this depends on, such as 5988 deal with the = right level of using UTF-8. This draft should just be silent on the = issue and you can probably remove all mention of UTF-8. Regardless of = the UTF-8 issues, it seems the media type registration should have = binary not 8bit. =20 >>>> This is how I started out, but in a couple review's a couple = versions back it was suggested that we specify UTF-8 and we made a = ticket for that. The intention is definitely to be in line with RFC5988, = so I would be more than happy to have no mention of UTF-8 in the = document and instead just say "the links are as defined in rfc3986". = Again, will make a ticket if I hear no objections. >>>> =20 >>> But RFC 3986 only covers URIs and CoRE link format can include other = data? >>> I think saying that the format contains UTF-8 is actually useful for = future extensibility. >>>=20 >>=20 >> I think the part I am getting hung up on is what is allowed, and what = needs to be checked and enforced by everyone. I think most the WG agrees = they want implementation to treat things as just a bunch of bits that is = passed around with no bitwise changes and are compared bit for bit. >>=20 > That is fine. But this doesn't mean that data is binary (for example). >=20 >> They are perfectly happy if these bit strings turn out to be UTF-8 = strings and no desire to limit it to US-ASCII for the stuff that is = meant for humans instead of machines. I suspect you are roughly on the = same page but the question is how to get the specification to say that = clearly enough that implementors don't get confused. Some of this = confusion is introduced by people that don't understand core and are = arguing against it's use - for example I recently saw a draft = presentation that claimed small constrained nodes implement core would = need a full XML library and unicode string process library. I = straightened out that presentation but was I like the specs to be clear = enough that I did not see stuff like that.=20 >> Thoughts on how to get this clear in the main coap draft as well as = here. >>=20 > I think at least saying that any CORE link format payload is UTF-8 is = useful. This tells implementations what they should generate and what = they can expect. And if they want to check for UTF-8 and reject invalid = data, they can. If you want to say more than "MUST be UTF-8", then you = should probably have separate statements about what compliant generators = should produce and what consumers should do. >=20 > NFC or any other form of Unicode normalization is useful for = comparison or lookup of values. If UTF-8 data is only used for display, = I don't think this is needed. >=20 The stuff I am concerned about is not used for display to humans, but it = is used for comparisons in machine to machine applications. We can ask = the WG but the I think the odds are pretty good no one will want to = implement NFC on a constrained devices. As far as I can tell it's not = UTF-8 as far as these devices are concerned. It's a binary string that = is bit wise compared and is capable of caring a UTF-8 value. I guess = this discussion is helping me get clear on explaining what I think = implementors want. I think they want to treat these as binary strings = and they are fine with requirement that these binary strings be capable = of caring UTF-8 data but there not handling it as UTF-8 data. They are = taking a more generic handling of it and don't want to do the things = UTF-8 processing would require. Does this make any sense or sound = reasonable?